A Primer on AWS VPC and Connectivity Patterns

A Primer on AWS VPC and Connectivity Patterns

For an AWS newbie or a veteran, I hope this article serves the purpose of summarizing the foundational concepts of AWS VPC like Regions, Availability Zones (AZs), Virtual Private Cloud (VPC), Subnets, Route tables, Gateways, and Endpoints. By reading this article, you will also be gaining a better understanding of VPC Connectivity patterns to the outside world – public Internet, on-premise data centers, other AWS VPCs, AWS services like S3, DynamoDB, etc. Leveraging the discussion on connectivity patterns, you would be introduced to some of the other AWS networking services like Peering, Site-to-Site VPN, PrivateLink and DirectConnect. So let’s jump into it.

Regions and Availability Zones

AWS physical Data Centers which process and store our data are located in multiple geographical locations across the globe.Each of these Data Centers come with redundant power, networking, and connectivity, and are housed in separate facilities. In simple words, the nomenclature of Regions and AZs is a categorization of different physical locations where the Data Centers are located. 

AWS Regions are large and widely dispersed geographic locations, for example North California, Oregon, Ireland, Singapore, Mumbai, etc. At the time of writing of this article, there were 31 geographic AWS Regions around the world. 

An Availability Zone (AZ) is a grouping of one or more Data Centers within a particular Region. AWS does not provide the geographical names of AZs, but provides a way for us to distinguish between them by appending characters to the region name. For example, the North California region (us-west-1) has three AZs within it – us-west-1a, us-west-1b, and us-west-1c. At the time of writing this article, there were 99 Availability Zones within 31 geographic AWS Regions around the world. 

So what is the relevance of this if you are deploying to AWS? The concept of Regions and AZs allow us to create highly available and redundant applications on AWS. If we have an app deployed in one AZ and there is a power outage due to a natural calamity, our customers would benefit from a replica of the app running in a different AZ. Similarly for more critical apps, we might want to have redundant resources in multiple AWS regions. Some AWS services provide redundancies by default e.g. AWS S3 redundantly stores objects on multiple devices across a minimum of three Availability Zones in an AWS Region. But for some AWS services like AWS EC2, we have to create these highly available configurations on our own

In this figure, you could see that a Region consists of multiple AZs, and AZs can contain one or more Data Centers.

AWS Virtual Private Cloud (VPC), Subnets and Route Tables

VPC is an isolation boundary for our AWS resources in a particular AWS region and it’s similar in concept to the private network that we would create in our private Data Centers to house IT resources. A VPC allows us to create network boundaries around AWS resources and also define traffic routing policies. When we create a VPC, we specify an IP address range (using the CIDR notation) which is the set of IP addresses that will be used by resources within that VPC.

Once the VPC is created, we would want to segregate the VPC network into sub-networks which are called Subnets in AWS. For subnets, obviously IP address range would be a sub-range within the VPC IP range for the distribution of IP addresses. Important thing to note here is that a VPC can only be created for a particular AWS region and subnets within that VPC can be created for only a particular AZ within the VPC’s region. There are multiple implications of this, but an important one is that, if we need to create multi-regional apps in AWS, we can’t do that with a single VPC, we would have to create another VPC in a different region. 
Each subnet must have a AWS Route table attached to it which determines the route that a network packet takes either when coming into the subnet or being directed outwards. If we want one subnet to have routes to another subnet but not to a third one, we can have those specific traffic routing rules as part of the AWS Route table which are mandatory to be attached to each of the subnets within the VPC.

In this AWS diagram, you can see a VPC created in a particular AWS region and Subnets within that VPC created in a particular AZ within the VPC’s Region.  

VPC Connectivity patterns

We have discussed Regions, AZs, VPC, subnets and route tables, let’s now focus our attention on how resources created within a VPC can talk to the outside world – public Internet, on-premise data centers, other AWS VPCs, AWS services like S3, DynamoDB, etc. Using these connectivity patterns, you would also be introduced to a variety of AWS Gateways, Endpoints and other AWS network supporting services like Peering, Site-to-Site VPN, Direct Connect and PrivateLink. 

A list of the network connectivity patterns that we will be covering along with the AWs endpoints, gateways and supporting services used to accomplish the pattern are mentioned below: 

1. Internet Gateway – Connectivity between public resources in VPC and public Internet
2. Public NAT Gateway – Connectivity from private resources in VPC to the public Internet
3. AWS Site-to-Site VPN (Virtual Private Gateway, Customer Gateway) – Connectivity between private resources in VPC and on-premise Data Centers
4. AWS Direct Connect – Connectivity between private resources in VPC and on-premise Data Centers using physical dedicated connection bypassing Internet service providers
5. AWS Client VPN – Connectivity between private resources in VPC and Client Endpoints using VPN
6. VPC Peering – Connectivity to other VPCs in same AWS account or different AWS account
7. AWS Transit Gateway – Hub and spoke Connectivity between multiple VPCs and on-premise networks
8. Gateway VPC Endpoints, Interface Endpoints (powered via AWS PrivateLink) – Connectivity to AWS services like S3, DynamoDB, and SNS via AWS backbone network
9. AWS PrivateLink – Connecting from a service in one VPC (Service Consumer) to a service in another VPC (Service Provider) via AWS backbone network

1. Connectivity between public resources in VPC and public Internet

A resource with a public ip address within the VPC does not automatically get a connection to the public Internet. The VPC needs to have an Internet Gateway  attached to it to be able to facilitate connection of a VPC resource to the public Internet. Once it’s attached to a VPC, we would need to add a route table rule to a particular subnet from 0.0.0.0 (signifies public Internet) via the Internet Gateway. Adding this route to a subnet makes it a public subnet and if that route is not available, then the subnet becomes a private subnet.  

In this diagram, the subnet in AZ A is called a Public Subnet since it has a route to the Internet Gateway and the resources created within it can connect with public Internet via public ip address. 

2. Connectivity from private resources in VPC to the public Internet

You might want to create resources in a VPC which do not need a public ip address, but they need to connect to the public Internet to grab stuff like software upgrades. In such situations, Public NAT Gateway facilitates the connection of resources in private subnets to connect to resources outside the VPC like the internet, other VPCs, or on-premises networks. Using NAT Gateway, private resources can communicate with services outside the VPC, but they cannot receive unsolicited connection requests. The NAT gateway replaces the source private IPv4 address of the VPC resources with the address of the NAT gateway. When sending response traffic to the private resources, the NAT Gateway translates the addresses back to the original private source IPv4 addresses.

In this diagram, resources in the Public subnet can connect directly to the Internet if they have public ip addresses via the Internet Gateway. And the resources in the Private subnet of AZ B can connect to the Internet via the Public NAT Gateway in the Public subnet in AZ B but they cannot receive unsolicited connection requests from the Internet.

3. Connectivity between private resources in VPC and on-premise Data Centers

If you have a hybrid cloud environment with an on-premise Data Center and you need to have a dedicated virtual connection between the private resources in both environments, then AWS offers the Site-to-Site VPN service. This facilitates a VPN tunnel between a virtual private gateway on the AWS side, and a customer gateway (which represents a VPN device) on the on-premises side.

In this diagram, a AWS VPC network is connected via VPN to an on-premise network via AWS Site-to-Site VPN. Resources in AWS VPC can talk to resources in the on-premises network via private IP addresses, and vice-versa. 

4. Connectivity between private resources in VPC and on-premise Data Centers using physical dedicated connection bypassing Internet service providers

With the previous connectivity pattern between VPC and the on-premise Data Centers using Site-to-Site VPN, the traffic still goes through the public Internet. If you need a connection between on-premise and AWS which is truly private i.e. it does not go through the Internet service providers, AWS Direct Connect can be used to link your internal network to an AWS Direct Connect location over a standard Ethernet fiber-optic cable. One end of the cable is connected to your router, the other to an AWS Direct Connect router. With this connection, you can create virtual interfaces directly to public AWS services (for example, to Amazon S3) or to Amazon VPC, bypassing internet service providers in your network path.

In this diagram, an on-premise network is connected to AWS VPC and public AWS services like S3, Glacier, etc. via AWS Direct Connect. The connection goes through the AWS backbone network and does not go through the Public Internet at all. 

5. Connectivity between private resources in VPC and Client Endpoints using VPN

If you have users who are working from home remotely, and need a way to privately and securely access AWS resources using VPN, then AWS Client VPN can be used to provide an AWS-managed OpenVPN-based VPN client.

In this diagram, Clients from CIDR range 10.0.0.0/22 are able to access AWS resources in subnet 172.31.0.0/20 via VPN using AWS Client VPN service. 

6. Connectivity to other VPCs in same AWS account or different AWS account

If you have VPCs in different regions within a same AWS account or VPCs in different accounts, and you wish to be able to connect resources within those VPCs, the simplest way to do so is via VPC Peering. Peering creates anetworking connection between two VPCs that enables you to route traffic between them privately. Since resources in peered VPCs can communicate with each other as if they are within the same network, the peered VPCs should not have conflicting private IP addresses. Traffic between peered VPCs never traverses the public internet.

In this diagram, VPC A is VPC peered with VPC B. If the route tables have appropriate routes, then resources in Subnets of peered VPCs can talk to each other using private IP addresses over a private network. 

7. Hub and spoke Connectivity between multiple VPCs and on-premise networks

In a typical large cloud organization there are thousands of AWS accounts and VPCs. In such a vast environment, organizing connectivity between VPCs and the on-premise network can become a nightmare quickly. With AWS Transit Gateway, one central VPC (the hub VPC) connects with every other VPC (spoke VPC) and on-premise network through a VPN connection, consolidating and controlling your organization’s entire AWS routing configuration in one place. This hub-and-spoke model simplifies management and reduces operational costs because VPCs only connect to the Transit Gateway instance to gain access to the connected networks.

In this diagram, 4 VPCs and on-premise VPN Gateway are attached to a single  Transit Gateway. If the Transit gateway route table has appropriate routes, then connection requests from any VPC to other VPC or on-premise networks would first go to the Transit Gateway and then go to the destination from there.

8. Connectivity to AWS services like S3, DynamoDB and SNS via AWS backbone network

By default, all connections from VPC resources to public AWS services like S3, DynamoDB, etc. go via the public Internet using the public DNS name of these services. If we wish to protect our data on route going to these services, there are 2 ways to choose a safer medium for transport: 

• Gateway VPC Endpoints creates a gateway for accessing these public services from the VPC via the AWS backbone network meaning the connection does not traverse the public Internet. But the connection requests are still sent to the public DNS name of these services. As of the writing of this document, Gateway VPC Endpoints are only available for AWS S3 and DynamoDB. For any other service, we would have to use Interface Endpoints.  

• Interface endpoints enable private connectivity to AWS services powered using AWS PrivateLink (we will cover PrivateLink in the next section).  An interface endpoint creates an elastic network interface with a private IP address that serves as an entry point for traffic destined to a supported service. When you create an interface endpoint, AWS also generates an endpoint-specific private DNS hostname that you can use to communicate with the service over a private network.

In this diagram, if the EC2 instances in the subnet use the public DNS names of S3 for connection, the connection goes through the Gateway VPC Endpoints via AWS Backbone network (not via Public Internet). And if the EC2 instances use the endpoint-specific private DNS hostnames created via Interface VPC Endpoints, then the traffic is completely private using the private IP address of the ENI. 

9. Connecting from a service in one VPC (Service Consumer) to a service in another VPC (Service Provider) via AWS backbone network

Service in this context means an application that one of your internal teams may have hosted in an AWS account or a third-party may have created in their own AWS account. Service Provider provides this service from their AWS account and Service Consumer consumes the service in their AWS account, and the traffic is kept within the AWS backbone network via AWS PrivateLink.

In this diagram, the service provider on the right creates an Endpoint Service to make their service available in a region. A Load balancer is created to be able to route the traffic to the service. Service provider lets the Consumer know the service name of the Endpoint Service. Then, the service consumer on the left creates a VPC endpoint to connect their VPC to the Endpoint Service by specifying the provided endpoint service name. Traffic between a VPC endpoint and an Endpoint Service stays within the AWS network, without traversing the public internet.

Concluding thoughts

If you are with me till here, congratulations on understanding some of the foundational concepts of VPCs. We learned about how AWS categorizes its Data Centers based on geographical locations using the concept of Regions and Availability Zones (AZs). We also learned the three basic building blocks of a VPC – VPC, subnet and routing table. In the final and the biggest section of the article, we discussed 9 networking patterns to connect VPC to the outside world using a variety of gateways, endpoints and other AWS networking services. This is the first article in the Network Security section of AWS Cloud Security Masterclass, we will cover more networking concepts like Security groups, NACLs, Flow logs, etc. in the later articles.

References

The diagrams for this article and description of some services have been borrowed from AWS support articles on the related subjects.