Designing AWS Cloud Environment


So far we know the basic things of AWS, now we are going to be a little bit advanced. In this article, we will learn how to choose a proper region, use multiple AZs, use multiple VPCs, divide VPCs into subnets, manage VPC traffic, connect multiple VPCs, integrate on-premises components and default VPCs and subnets.

Choosing a Region

Before choosing a region, please ask 4 questions to yourselve.

  1. Does the region meet your environment’s data sovereignty and compliance requirements?

Do you meet data security laws of the country and locality in which your data is stored?

Can your customer’s data legally exist outside of the country that you use?

Will you be able to meet your governance requirements by placing your environment in the region where you plan to place it?

2. How close is the region to your users or data centers?

Every 100 ms delay on costs 1% in sales on the website.

Most organizations choose an initial region closest to data centers or customers e.g. US East for New York, EU Netherlands and Asia Pacific for Philippines.

In case there are two equidistant regions, choose the lower costs.

3. Does the region you are considering offer all of the services and features your environment might require?

Not all services and features are available in all regions.

Even though some services are not available in your region, typically you can still use those services within your environment. However, they may experience increased latency.

In fact, new services typically launch in a limited number of regions, with more regions added regularly.

4. Are you choosing the most cheapest region?

Some services have costs when you transfer data out of their region.

Service costs vary by region.

If you want to replicate your environment across more than one region, is that the most cost-effective solution?

How Many AZs Should you use?

For best practice, it is good to start with two AZ per region. In this way, if resources in one AZ are unreachable, the application should not fail. Most applications can support two AZs. Using more than two AZs for HA is not usually cost-effective.

Should you Just fit Everything Into one VPC?

There are limited use cases where one VPC could be appropriate:

  1. High-performance computing
  2. Identity management
  3. Small, single applications managed by one person or very small team

For most use cases, there are two primary patterns for organizing your infrastructure: multi-VPC and multi-Account.

The primary factors for determining this are the complexity of your organization and your workload isolation requirements.

For example, multi-VPC for single IT team, multi-account for large organization with many IT teams or high workload isolation required.

How Should you Divide Your VPCs Into Subnets?

As mentioned before, subnets are segments or partitions of a network, divided by CIDR range.

We recommend to use subnets to define internet accessibility by public and private subnet. Normally, we start with one public and one private subnet per AZ.

We also recommend to consider larger subnets over smaller ones.

Above are the simple examples of using public and private subnets.

How do you Control Your VPC Traffic?

We can use route tables to direct traffic between VPC resources. For best practice, we use custom route tables for each subnet to enable granular routing for destinations.

In addition, we use security groups to control traffic into, out of , and between resources.

Can you Connect Multiple VPCs to each other?

VPC peering connection allows us to route traffic between the peer VPCs. Instances in either VPC can communicate with each other as it they are within the same network.

VPC peering does not need internet gateway or virtual gateway. It has no single point of failure and no bandwidth bottlenecks.

How do you Integrate On-premises Components Into Your Environment?

The most simplest solution to integrate on-premises to AWS is to use AWS Direct Connect.

What are Default VPCs and Default Subnets, and When Should you use Them?

Default VPCs are:

  1. Each region in your account has a default VPC.
  2. Default CIDR is
  3. If you create a VPC-based resources (EC2, RDS, ELB, etc) but don’t specify a custom VPC, it will be placed in your default VPC in that region.
  4. Includes a default subnet, IGW, main route table connecting default subnet to the IGW, default, security group, and default NACL.
  5. Configurable the same as other VPCs e.g. adding more subnets.

Default subnets are:

  1. Created within each AZ for each default VPC.
  2. Public subnet with a CIDR block of /20 (4,096 IPs).
  3. You can convert it into a private subnet by removing its route to the IGW.
  4. When a new AZ is added to a region, your default VPC in that region gets a subnet placed in the new AZ.

We recommend to use default VPCs and their subnets only for experimenting in your AWS account. Default VPCs are a quick start solution. For real-world applications, please create your own VPCs and subnets.


  1. Choose a region based on data sovereignty, distance to users, services/features and cost efficiency.
  2. Start with 2 AZs per region.
  3. Use multi-VPC and multi-account instead of single VPC.
  4. Start with one public and one private subnet per AZ.
  5. Use route tables, security groups, network ACLs and internet gateways to control your VPC traffic.
  6. Use VPC peering to route traffic between the peer VPCs.
  7. AWS Direct Connect provides you with a private network connection between AWS and your data center.

Leave a Reply