Building a Modular and Scalable Virtual Network Architecture with Amazon VPC
VPC Quick Start

Architecture

Deploying this Quick Start with the default parameters builds the following virtual networking environment in the AWS Cloud.


          Modular Amazon VPC architecture on AWS

* Note that the IP addresses exclude five addresses from each subnet that are reserved and unavailable for use.

Figure 1: Modular Amazon VPC architecture on AWS (full-screen view)

 

The AWS CloudFormation template sets up the virtual network and creates networking resources.

The template creates a Multi-AZ, multi-subnet VPC infrastructure with managed NAT gateways in the public subnet for each Availability Zone. You can also create additional private subnets with dedicated custom network access control lists (ACLs). If you deploy the Quick Start in a region that doesn’t support NAT gateways, NAT instances are deployed instead. Default subnet sizes are based on a typical deployment but can be reconfigured, as discussed in the Subnet Sizing section.

The Quick Start also includes VPC endpoints, which provide a secure, reliable connection to Amazon S3 without requiring an Internet gateway, a NAT device, or a virtual private gateway. With these endpoints, you can access S3 resources from within the VPC created by the Quick Start. These endpoints are valid only for the AWS Region in which you launch the Quick Start.

The Quick Start uses the default endpoint policy, which gives any user or service within the VPC full access to Amazon S3 resources. This policy supplements any IAM user policies or S3 bucket policies that you may have in place.

The Quick Start also enables Domain Name System (DNS) resolution in the VPC. For more information about VPC endpoints, see the AWS documentation.

AWS Services

The core AWS components used by this Quick Start include the following AWS services. (If you are new to AWS, see the Getting Started section of the AWS documentation.)

  • Amazon VPC – The Amazon Virtual Private Cloud (Amazon VPC) service lets you provision a private, isolated section of the AWS Cloud where you can launch AWS services and other resources in a virtual network that you define. You have complete control over your virtual networking environment, including selection of an IP address range, creation of subnets, and configuration of route tables and network gateways.

  • Amazon EC2 – The Amazon Elastic Compute Cloud (Amazon EC2) service enables you to launch virtual machine instances with a variety of operating systems. You can choose from existing Amazon Machine Images (AMIs) or import your own virtual machine images.

  • Amazon EBS – Amazon Elastic Block Store (Amazon EBS) provides persistent block-level storage volumes for use with Amazon EC2 instances in the AWS Cloud. Each Amazon EBS volume is automatically replicated within its Availability Zone to protect you from component failure, offering high availability and durability. Amazon EBS volumes provide the consistent and low-latency performance needed to run your workloads.

  • NAT Gateway – NAT gateways are network address translation (NAT) devices, which provide outbound Internet access to instances in a private subnets, but prevent the Internet from accessing those instances. NAT gateways provide better availability and bandwidth than NAT instances. The NAT Gateway service is a managed service that takes care of administering NAT gateways for you. NAT gateways aren’t supported in all AWS Regions. This Quick Start deploys NAT instances in regions where NAT gateways aren’t available.

Best Practices

The architecture built by this Quick Start supports AWS best practices for high availability and security. The Quick Start provides:

  • Up to four Availability Zones for high availability and disaster recovery. (AWS recommends maximizing your use of Availability Zones to isolate a data center outage.) Availability Zones are geographically distributed within a region and spaced for best insulation and stability in the event of a natural disaster.

  • Separate subnets for unique routing requirements. AWS recommends using public subnets for external-facing resources and private subnets for internal resources. For each Availability Zone, this Quick Start provisions one public subnet and one private subnet by default. (If you need public subnets only, you can disable the creation of the private subnets.) For subnet sizing strategies, see the next section.

  • Additional layer of security. AWS recommends using network ACLs as firewalls to control inbound and outbound traffic at the subnet level. This Quick Start provides an option to create a network ACL protected subnet in each Availability Zone. These network ACLs provide individual controls that you can customize as a second layer of defense.

    We recommend that you use network ACLs sparingly for the following reasons: they can be complex to manage, they are stateless, every IP address must be explicitly opened in each (inbound/outbound) direction, and they affect a complete subnet. We recommend that you use security groups more often than network ACLs, and create and apply these based on a schema that works for your organization. Some examples are server roles and application roles. For more information about security groups and network ACLs, see the Security section later in this guide.

  • Independent routing tables configured for every private subnet to control the flow of traffic within and outside the Amazon VPC. The public subnets share a single routing table, because they all use the same Internet gateway as the sole route to communicate with the Internet.

  • Highly available NAT gateways, where supported, instead of NAT instances. NAT gateways offer major advantages in terms of deployment, availability, and maintenance. For more information see the comparison provided in the Amazon VPC documentation.

  • Spare capacity for additional subnets, to support your environment as it grows or changes over time.

For additional information about these best practices, see the following documentation:

Subnet Sizing

In this Quick Start, the sizing of CIDR blocks used in the subnets is based on a typical deployment, where private subnets would have roughly double the number of instances found in public subnets. However, during deployment, you can use the CIDR block parameters to resize the CIDR scopes to meet your architectural needs.

In the default subnet allocation, the VPC is divided into subnet types and then further segmented per Availability Zone, as illustrated in Figure 1. The Quick Start provides the following default CIDR block sizes to maximize capacity:

VPC 10.0.0.0/16
Private subnets A 10.0.0.0/17
  Availability Zone 1          10.0.0.0/19         
  Availability Zone 2 10.0.32.0/19
  Availability Zone 3 10.0.64.0/19
  Availability Zone 4 10.0.96.0/19
Public subnets 10.0.128.0/18
  Availability Zone 1 10.0.128.0/20
  Availability Zone 2 10.0.144.0/20
  Availability Zone 3 10.0.160.0/20
  Availability Zone 4 10.0.176.0/20
Private subnets B with dedicated custom network ACL 10.0.192.0/19
  Availability Zone 1 10.0.192.0/21
  Availability Zone 2 10.0.200.0/21
  Availability Zone 3 10.0.208.0/21
  Availability Zone 4 10.0.216.0/21
Spare subnet capacity 10.0.224.0/19
  Availability Zone 1 10.0.224.0/21
  Availability Zone 2 10.0.232.0/21
  Availability Zone 3 10.0.240.0/21
  Availability Zone 4 10.0.248.0/21

Alternatively, there may be situations where you would want to separate the CIDR scopes by dividing the VPC into Availability Zones and then into subnet types. The recommended CIDR blocks to maximize capacity for this scenario are as follows:

VPC 10.0.0.0/16
Availability Zone 1          10.0.0.0/18
  Private subnet A 10.0.0.0/19         
  Public subnet 10.0.32.0/20
  Private subnet B 10.0.48.0/21
  Spare subnet capacity          10.0.56.0/21
Availability Zone 2 10.0.64.0/18
  Private subnet A 10.0.64.0/19
  Public subnet 10.0.96.0/20
  Private subnet B 10.0.112.0/21
  Spare subnet capacity 10.0.120.0/21
Availability Zone 3 10.0.128.0/18
  Private subnet A 10.0.128.0/19
  Public subnet 10.0.160.0/20
  Private subnet B 10.0.176.0/21
  Spare subnet capacity 10.0.184.0/21
Availability Zone 4 10.0.192.0/18
  Private subnet A 10.0.192.0/19
  Public subnet 10.0.224.0/20
  Private subnet B 10.0.240.0/21
  Spare subnet capacity 10.0.248.0/21

To customize the CIDR ranges for this scenario or to implement your own segmentation strategy, you can configure the Quick Start parameters described in step 2. For more information about VPC and subnet sizing, see the AWS documentation.