Since its inception, the Amazon Virtual Private Cloud (VPC) has acted as the embodiment of security and privacy for customers who are looking to run their applications in a controlled, private, secure, and isolated environment.

This logically isolated space has evolved, and in its evolution has increased the avenues that customers can take to create and manage both multi-tenant environments and global VPC networks with multiple integration points for access to resources on-premises.

This blog is a two-part series that begins with a look at the Amazon VPC as a single unit of networking in the AWS Cloud but eventually takes you to a world in which simplified architectures for establishing a global network of VPCs are possible.

From One VPC: Single Unit of Networking

To be successful with the AWS Virtual Private Cloud you first have to define success for today and what success might look like as your organization of the AWS Cloud increases and matures. In essence, your VPC should be designed to satisfy the needs of your applications today and must be scalable to accommodate future needs.

Classless Inter-Domain Routing (CIDR) notations are used to denote the size of your VPC. AWS allows you specify a CIDR block between /16 and /28. The largest, /16, provides you with 65,536 IPs and the smallest possible allowed CIDR block, /28, provides you with 16 IPs.

AWS VPC supports both IPv4 and IPv6. It is required that you specify an IPv4 CIDR range when creating a VPC. Specifying an IPv6 range is optional. The supported IPv4 addresses fall within the RFC1918 range. It is also possible to specify publicly routable IP addresses that fall within a non-RFC1918 range. These addresses are a CIDR block from the 100.64.0.0/10 range.

After creating your VPC, you divide it into subnets. In an AWS VPC, subnets are not isolation boundaries around your application. Rather, they are containers for routing policies.

Isolation is achieved by attaching an AWS Security Group (SG) to the EC2 instance that hosts your application. SGs are stateful firewalls. They control inbound and outbound access to the elastic network interface that is attached to your EC2 instance. These should be tightly configured, only allowing access as needed.

It is best practice that subnets should be created in categories. These are Public-Subnets, Private-Subnets and Hybrid-Subnets. At minimum they should be designed as outlined in the below diagrams for IPv4 and IPv6 Subnet design.

Recommended IPv4 Subnet Design Pattern

Recommended IPv4 Subnet Design Pattern

 

Recommended IPv6 Subnet Design Pattern

Recommended IPv6 Subnet Design Pattern

Subnet types are differentiated by the way they access resources that are external to the VPC.

Public Subnets

Subnets that are attached to a route table that have a default route to the Internet via an Internet Gateway are considered to be public subnets.

Resources in a public subnet have a public IP or Elastic IP (EIP) NAT’ted to the Elastic Network Interface (ENI) of the virtual machine or micro VM that houses your application(s). This is an intrinsic NAT whose awareness is managed by the Internet Gateway (IGW).

Illustration of Public Subnet Access Path to the Internet through the Internet Gateway (IGW)

Illustration of Public Subnet Access Path to the Internet through the Internet Gateway (IGW)

Hybrid Subnets

Hybrid subnets differ slightly in that the route table(s) that supports these subnets do not have an Internet Gateway as a next hop to the Internet. Instead, it has a NAT infrastructure of sorts. AWS natively provides two types of NAT infrastructure: NAT Gateway (NAT GW) and NAT Instance. Customers also have the option to deploy third party NAT appliances from the AWS Marketplace.

In most scenarios, it is recommended to use the AWS NAT Gateway (NAT GW) as it is highly available (in a single Availability Zone) and completely managed by AWS. It also provides 5Gbps of bandwidth per NAT GW and automatically scales up to 45Gbps.

NAT GWs high availability is confined to a single Availability Zone. It is recommended to have a minimum of two NAT-GWs spread across multiple/all Availability Zones. This allows you to switch to an available NAT Gateway in the event that one should become unavailable.

This approach allows you to zone your Internet traffic, reducing cross Availability Zone connections to the Internet. More details on NAT GWs are available here.

Illustration of an Environment with a single NAT Gateway (NAT-GW)

Illustration of an Environment with a single NAT Gateway (NAT-GW)

 

Illustration of an Environment with a Multiple NAT Gateways (NAT-GW) and a Single Route Table

Illustration of an Environment with a Multiple NAT Gateways (NAT-GW) and a Single Route Table

 

Illustration of High Availability with a Multiple NAT Gateways (NAT-GW) Attached to their own Route Table

Illustration of High Availability with a Multiple NAT Gateways (NAT-GW) Attached to their own Route Table

 

AWS allocated IPv6 addresses are Global Unicast Addresses by default. In order to make your IPv6 address space act like your hybrid IPv4 subnet, simply add an Egress-only Internet Gateway to the route table that supports your IPv6 subnet(s). This allows IPv6 addresses to initiate access to resources and users on the Internet but prevents these entities from initiating access.

Illustration of Internet Access for Hybrid IPv6 Subnets Through an Egress Only Internet Gateway (E-IGW)

Illustration of Internet Access for Hybrid IPv6 Subnets Through an Egress Only Internet Gateway (E-IGW)

 

Private Subnets

A Private subnet’s route table has no next hop infrastructure for Internet access. Instead, this route table contains the mandatory Local Route and routes to resources external to the existing VPC. These could be routes to another VPC via the VPC Peering infrastructure or to a customer’s on-premises data center or network via the AWS Transit Gateway (TGW) or a Virtual Gateway (VGW).

Illustration of Private Subnets Connecting to Data Center via a Virtual Gateway (VGW)

Illustration of Private Subnets Connecting to Data Center via a Virtual Gateway (VGW)

 

Illustration of Private Subnets Connecting to Data Center via a VGW that’s acting as a Cloud Hub

Illustration of Private Subnets Connecting to Data Center via a VGW that’s acting as a Cloud Hub

 

Illustration of Private Subnets Connecting to Data Center using Direct Connect as primary and IPsec as backup

Illustration of Private Subnets Connecting to Data Center using Direct Connect as primary and IPsec as backup

 

The above diagram illustrates a WAN connection between a VPCs Private Subnets and a customer’s data center.

AWS provides two options for establishing a WAN between your VPC and on-premises network: Direct Connect and Site-to-Site VPN.

AWS Site-to-Site VPN configuration leverages IPSec and each successful configuration provides two IPSec tunnels. AWS allows two routing protocols across these tunnels: Static and BGP.

BGP is recommended, as it has a richer feature set that allows for dynamic route advertisement, high availability through failure detection and fail over between tunnels and less management overhead.

VPC Endpoints: Gateway & Interface Endpoints

Applications running inside your subnet(s) may need to connect to AWS public services (like S3, SNS, SQS, API Gateway, etc.) or applications in another VPC that lives in another account. For example, you may have a database in another account that you would like to expose applications that lives in a completely different account and subnet.

For scenarios like these you have the option to leverage an Amazon VPC Endpoint. This is the recommended path for services that are supported by Amazon VPC Endpoints.

There are two types of VPC Endpoints: Gateway Endpoint and Interface Endpoints.

  • Gateway Endpoints are estate and only support Amazon S3 and DynamoDB. Up on creation, a gateway is added to your specified route table(s) and acts as the preferred infrastructure for all requests to the service it is created for.
  • Interface Endpoints differ significantly and can only be created for services that are powered by AWS PrivateLink.

Upon creation, AWS creates a requester-managed Elastic Network Interface (ENI) in a subnet you specified. This acts as a point of entry for all traffic destined to the AWS service in focus.

The IP address of the requester-managed ENI is mapped to a set of DNS hostnames that AWS generates during creation. To access the AWS service in focus, you must send your request to one of these hostnames.

As illustrated below, ensure the Private DNS feature is enabled for AWS public and Marketplace services:

The ENI approach to Interface Endpoints allows customers to leverage cloud techniques they are already familiar; like securing their ENIs with a tightly configured Security Group and accessing the ENI’s private IP easily, inside and outside the VPC. That said, customers can access their Interface Endpoints across Direct Connect and AWS Site-to-Site VPNs.

 

 

The reverse is also true; likewise, customers can create AWS Endpoint services to their applications or services running on-premises. Then, create an Interface Endpoint to these services in the accounts that need to access these on-premises services (even if the account themselves do not have Direct Connect configured.

VPC Sharing

AWS has decoupled accounts from networking using a combination of AWS Organizations, Resource Access Manager, and VPC Sharing.

VPC sharing allows customers to share subnets with other AWS accounts within the same AWS Organization. This is a very powerful concept that allows for a centrally controlled VPC structure, routing, IP address allocation.

Cost & time reduction through the reuse of NAT Gateways, VPC Interface Endpoints, intra-Availability Zone traffic, Direct Connect VIFs and Site-to-Site VPNs config.

Networking can now be centralized resulting in better IP space management and a reduction in complexity and management overhead.

from AWS Architecture Blog