August 22, 2019

Designing Scalable VPCs in AWS (Part 1)

It seems like no one has a "perfect" AWS design solution, which is understandable. Every company has different requirements for their own environments. Application stacks are built one way when a team decides to move their product to the cloud, only to eventually have someone come and deem the build obsolete. This is inevitable with the rate at which applications develop in an agile environment. However, building a sustainable VPC infrastructure to support the different applications within AWS will significantly reduce headache when the time comes to change directions with an application.

Let's start with a simple example of how a physical data center would be configured from a network point-of-view:

High-Level Data Center Design

Multiple products hosted in one location are usually separated by subsets, and then subnets within subnets are created to separate the functions within the product. This type of segmentation is achieved using VLANs and can be secured separately with firewalling as necessary. The most common mistake I see in AWS infrastructure is using VPCs to segment not only products, but the functions within each product. Below is a model of what the example data center should look like in AWS:

Data Center Design in AWS

Network segmentation should be achieved using the same methods we use in on-prem data centers, subnetting. If you liken a VPC network to a data center supernet, it doesn't make sense to create multiple in one region; subnetting in AWS is equivalent to using VLANs in a physical data center. What does this actually look like?

AWS Design with Subnets

In the example above, the VPC is configured for a /16 network (in excess of 65,000 usable IPs) and each of the three products has a /24 (~250 usable IPs) for each function. Depending on your application needs, this is an extremely generous amount of IP space, and we only created subnets for one availability zone. An availability zone provides another layer of redundancy within a region. With using AWS best practices, Let's re-arrange this network with availability zones factored in:

AWS Design Including Availability Zones

We now have our products divided by function and availability zones. For the example, we left extra space for cleaner subnetting rules should we need to build complex routing tables in the future.

In part 2, we will explore managing internet access for the newly-created VPCs.