What Startups Should Know about Amazon VPC: Part 2

Design and create your VPC.

This is the second post in a two-part series about creating VPCs with Amazon VPC. In the first post, we cover what a VPC is and what its core components are. In this post, we discuss the considerations for designing and creating your VPC.

Defining Success

One of the first things you should do when developing any cloud strategy is to define what success looks like for your business.

For a VPC, you should carefully consider the number of IP addresses that your business needs today and in the future. This will help to determine your VPC IP CIDR block.

Selecting Your AWS Region and IP CIDR

To create your VPC, the first step is to select the region where your resources will be located. All data that will be generated and stored in your VPC will reside in this region. Data will not go beyond the border of your VPC region without you invoking a request to do so. Currently, AWS has 10 regions across the world, spanning five continents.

AWS Regions

The second step is to define a master IP CIDR block. All future subnets for this VPC will inherit the first two octets of the IP CIDR block that you define.

Once defined, the IP CIDR block is irreversible. It determines the number of subnets and IP addresses that you can create inside your VPC. Therefore, it is important that you chose a CIDR block that allows you to scale according to your needs today and in the future.

You can chose a CIDR block that is as small as a /28 or as large as a /16. A /28 will provide you with 16 IP addresses and a /16 will provide you with 65,536 IP addresses.

The following illustration shows a CIDR block relationship to VPC subnets.

The following screenshot shows how to create a CIDR block in the Amazon VPC console.

As shown in the screenshot, your private subnet should be the default for your resources unless they absolutely must have a public IP address attached to the instance. NAT instances are used to provide Internet access to your private subnet resources. You can use a bastian host to access them from a public domain such as the Internet. Note that you can access resources in the private subnet securely via a hardware VPN between your LAN and your VPC or via AWS Direct Connect.

Avoiding Overlapping Addresses

Traffic that is destined to an overlapping address space is dropped. Therefore, it is important that the IP CIDR block that you define for your VPC does not overlap with the IP CIDR block for your on-premises network or another VPC if you plan on routing between them.

This means that if your plan is to connect two VPCs in the same region, or to connect your VPC to your local data center, then you cannot have the following overlaps:

VPC A — IP CIDR Block: 10.0.0.0/16
VPC B — IP CIDR Block: 10.0.0.0/16

or

VPC A — IP CIDR Block: 10.0.0.0/16
On-premises LAN — IP CIDR Block: 10.0.0.0/8

Here are examples of non-overlapping addressing:

VPC A — IP CIDR Block: 10.0.0.0/16
VPC B — IP CIDR Block: 172.16.0.0/16

or

VPC A — IP CIDR Block: 10.0.0.0/16
On Premise LAN — IP CIDR Block: 10.1.0.0/8

For more information, see IP Overlap.

Decoupling, Fault Tolerance, and High Availability

The AWS approach to a global footprint is to physically and logically isolate its resources into regions and Availability Zones (AZ).

This provides businesses with the ability to design and build highly available and highly redundant environments in which their resources are spread across multiple or all Availability Zones in an AWS region or across regions.

To achieve this kind of design, AWS encourages you to decouple your application and spread the resources/servers on which each piece lives across multiple Availability Zones.

Let’s imagine a scenario of a web server farm environment in which the web servers are stateless. Because of their statelessness, they can be spread across multiple Availability Zones in an AWS region. These web servers sit behind an elastic load balancer that has a private interface in the subnet where the web servers reside and a public interface that accepts HTTP/s or TCP requests from online users. Traffic is distributed evenly across the web server via Elastic Load Balancing load balancers. The availability of these servers is managed by the Auto Scaling service.

In this scenario, stateful information such as session state does not reside on the web servers, thereby making them stateless. User sessions can be stored in Amazon ElastiCache (Redis/Memcached) or Amazon DynamoDB (NoSQL database). This means that a user session will persist even if a web server is lost. Additionally, objects like pictures, videos, and files are not stored on the web server; instead, they are stored in Amazon S3, which carries eleven nines of durability and five nines of availability.

The database that supports the web servers does not reside on the same server as the web application. The database server is deployed on an Amazon RDS instance with a master-read replica configuration. The master resides in one Availability Zone and the read replicas reside in another. The web application is modified so that writes take place on the master and reads are directed to the read replica.

The data on the master is synchronously written to the replicas. The database instances interface resides only in the private subnet of the VPC, with no interface to any external resource. Therefore, only servers inside the VPC can communicate with the database servers.

The following diagram illustrates this solution.

MTU Support Within the VPC

Cisco, in their whitepaper “Understanding Maximum Transmission Unit (MTU) on ATM Interfaces,” offers this definition of an MTU:

“Maximum transmission unit (MTU) defines the largest size of packets that an interface can transmit without the need to fragment.”

In the AWS cloud environment, the largest MTU supported depends on the instance type. Today, all instances within the AWS cloud support a frame size of 1500 MTU, and some instance types even support jumbo frames or 9001 MTU. The largest frame supported by most of the Internet today is 1500 MTU. For more information, see Network MTU for Your EC2 Instance.

Security at Every Tier

A best practice when designing environments with Amazon VPC is to place security groups, or stateful firewalls, between every tier of your environment. This means that you should create a stateful firewall for each category of resource based on their application communication needs. By looking at the communication needs of the application, you will easily identify which traffic type and their respective ports need to be open and what resource needs to access them.

There are two specific tools that AWS provides for securing your workload: security groups and network access control lists (NACLs).

Security groups are stateful firewalls that operate at the instance level (virtual machines/EC2). This means that you can build them into every tier of your environment. A stateful firewall lets you specify the type of ingress and egress traffic that is allowed and by which resource.

For example, let’s say you have a web server environment that is made up of an elastic load balancer and a web server farm inside an Auto Scaling group. The web servers have their own firewall with port 3000 open. Port 3000 is the port that the elastic load balancer listens on. The elastic load balancer has port 80 (HTTP traffic), Port 443 (HTTPS traffic) and port 3000 (TCP port for passing traffic to the web servers). Ports 80 and 443 accept traffic from anywhere (0.0.0.0/0), and port 3000 accept traffic only from the web application server farm. The following illustration shows this type of environment.

A network access control list (NACL) is a stateless firewall that operates at the subnet level. This is an optional layer of security that acts as a firewall for controlling traffic in and out of a subnet. The best practice is to set up NACLs with rules similar to your security groups in order to add an additional layer of security to your VPC environment.

Unlike security groups, you can use NACLs to blacklist IP addresses so that specific address ranges are blocked from accessing your environment.

The following illustration shows the recommended placement of security groups and NACLs in a VPC.

Using VPC Endpoints

AWS introduced the concept of VPC endpoints in 2015 as a means to reduce latency and improve the security of your traffic between your VPC and other AWS services like Amazon S3.

An endpoint is created and lives within your VPC. It accepts traffic from the EC2 instances and passes it on to your AWS service of choice. This request does not traverse the Internet. Instead, it is sent over Amazon Web Services internal networking infrastructure to the appropriate AWS service.

VPC endpoints are a single instance of a particular thing. They are highly available clusters of resources that are managed by AWS, and they scale according to your needs.

Today, we only have VPC Endpoints for Amazon S3. Once you have created a VPC Endpoint, a default route is added to the Route table you specified during the Endpoint creation. This default route accepts and automatically route all S3 request to S3 buckets in the same Region as your VPC. All outer Region S3 requests are routed via your NAT Instance, Internet Gateway or via any other route you have specified for Internet Access.

Therefore, VPC Endpoints for S3 allows you to make your HTTP/HTTPS request to your S3 buckets (in the same Region as your VPC) without traversing the Internet.

This adds another layer of security that you didn’t have before.

The following illustration shows VPC endpoints.

It is important to note that transient routing of requests from a network outside of your VPC to an AWS endpoint is not allowed. However, you can set up a proxy farm within your VPC whose subnet is allowed to route requests to the VPC endpoint. With this set up, you can route requests to the proxy farm, which in turn will hand your request off to the VPC endpoint.

For more information, see VPC Endpoint.

Conclusion

In this post, we provided recommendations on how the Amazon VPC can be leveraged to help you to build highly available and secure environments with the latency requirements that your application requires to work efficiently.

For a deeper look at Amazon VPC, see the Amazon Virtual Private Cloud User Guide.