The course is part of these learning paths
See 2 moreCreating and configuring a Virtual Private Cloud (VPC) within AWS can be a simple or difficult process. It all very much depends on the complexity of your requirements. For example, how many subnets and hosts will you require? Will you be using one VPC or peering multiple VPCs together? Do you need to establish connectivity back to your on-premise network? Do you need internet connectivity for your Private instances? These and many more questions need to be asked and answered before you start to design your VPC infrastructure.
As a part of this process, you will need to understand VPC Subnet configurations and VPC routing to ensure you architect your solution correctly and efficiently.
This AWS Virtual Private Cloud: Subnets and Routing course looks and VPC Subnets and VPC Routing in detail, providing examples of both across different configurations and solutions and how to best implement your network design.
Course lectures
VPC Subnets:
- VPC CIDR Blocks - This lecture focuses on the effect of subnetting your VPC CIDR Block
- Why Subnet your VPC - This lecture looks at some of the reasons why you may want to subnet your VPC, by looking at the advantages and benefits
- VPC Subnets - This lecture dives into at what a VPC Subnet looks like within the Management Console and its associated components such as Network Access Control Lists (NACLs)
- Public & Private Subnets - This lecture looks at the differences between both Public and Private subnets within a VPC
- VPC Peering: Subnet Considerations - This lecture focuses on some of the considerations when architecting your subnets in different VPC Peering configurations
- Flow Logs: VPC Subnets - This lecture dives into at what a VPC Subnet looks like within the Management Console and its associated components such as Network Access Control Lists (NACLs)
- Demonstration: Creating a VPC & Subnets - This lecture provides a demonstration on how to set up and configure a VPC with both Public and Private subnets
VPC Routing:
- Routing Fundamentals & Route Tables - This lecture introduces AWS routing and its Routing tables by breaking down all the components within it
- Routing Priorities - This lecture explains how the routing priorities are defined for overlapping routes within the same route table
- Routing: VPC Peering - This lecture looks are different routing configurations for multiple VPC peering scenarios
- Routing: VPN Connection via a Virtual Private Gateway - This lecture looks at routing configurations for virtual Private Gateways
- Routing: Internet Gateways & NAT Gateways - This lecture looks at the routing configurations for both IGWs and NAT Gateways and the dependencies involved
- Routing: VPC Endpoints - This lecture looks at the automatic routing configuration when creating a VPC Endpoint
Hello, and welcome to this lecture. We're on to cover some example scenarios of routine configurations in different VPC peering solutions.
For connectivity to exist between VPCs over a peered connection, abbreviated as a pcx, then specific routing must be set up on each side of the peer in the relevant subnets of the VPC to allow each VPC to know where to route traffic to.
Setting up routing on peered VPCs can only exist if the IP CIDR blocks do not overlap in any way. In each peered subnet that you want to communicate with, you must ensure that the route table being used in that subnet has a static route to either the peered VPC CIDR block or the CIDR block of the subnet in the peered VPC.
From this diagram, you can see that we have two subnets in each VPC. In VPC 1, we have a subnet A and B, and in VPC 2, subnet C and D. Subnet A in this VPC 1 has a static route in the table with a destination of the CIDR block of VPC 2 and a target of pcx-abcd1234, which is the peered gateway between the two VPCs.
Subnet B in the same VPC does not have a route pointing to the pcx. Similarly, in VPC 2, subnet C also has a route to VPC 1's CIDR block by the pcx, and subnet D does not. In this scenario, subnet A and VPC 1 has a route to the entire IP address space of VPC 2, and subnet C and VPC 2 has a route to the entire IP address space of VPC 1.
Therefore, these two subnets have a route to each other to enable connectivity. Although VPC 1 can route to the entire IP address space of VPC 2, which would include subnet D, subnet D does not have a route in its routing table to enable traffic to route to VPC 1. This is also true for VPC 2 communicating with subnet B.
For every subnet that requires connectivity to a peered VPC, a route must exist in the route table for that subnet pointing to the pcx. Let's now look at another example configuration of peering connections between VPCs. This time between three VPCs.
The peering connection between these VPCs offers connectivity to all VPCs from every other VPC. VPC 1 can communicate with 2 and 3, VPC 2 can communicate with 1 and 3, and VPC 3 can communicate with 1 and 2. In this scenario, three different peering connections are in place. As such, different pcx's are used to connect the same VPC from every other VPC. For example, the route table in VPC 3 uses pcx-wxyz6789 to communicate with VPC 1, whereas VPC 2 uses pcx-abcd1234 to communicate with VPC 1.
Care must be taken when configuring your route tables to ensure you use the correct pcx to route your traffic to peered VPCs in a multiple VPC peering scenario such as this. One final example of VPC peering. Again with three VPCs, but this time, not all the VPCs can communicate with all others plus two of the VPCs have identical CIDR blocks.
So, let's take a look at the routing in this scenario. Both VPC 1 and 3 have a peering with VPC 2. You will notice that VPC 1 and VPC 3 have identical VPC CIDR blocks as well as the same subnet CIDR range. The route table for the subnet in VPC 1 is set up correctly to point to VPC 2 via the correct target of the pcx.
However, the route table of the subnet in VPC 2 poses a problem. It states that for any traffic destined for the 10.0.0.0/16 network, then use the pcx which points to VPC 3 only. So, if a request comes from VPC 1 and a response is required, the response will be sent to VPC 3. Currently, VPC peering does not support unicast reverse path forwarding, which checks the source IP of packets and routes response packets back to the correct source.
To resolve this, you could rely on the longest periphics match roll when looking at route priorities. The route table of the 192.168.1.0/24 subnet could be changed to the following to include a new route. Now if any traffic from VPC 1 in the subnet 10.0.1.0/24 was destined for VPC 2, VPC 2 would respond correctly using the correct pcx of pcx-abcd1234, as this route has the longest periphics match.
For any other traffic on the 10.0.0.0/16 network, it will route to VPC 3. You could be more specific with your route table on VPC 2 to route to different subnets within VPC 1 and VPC 3 as shown on the route tables.
Coming up in the next lecture, I'm going to look at routing configuration when using a virtual product gateway for VPN connectivity.
Stuart has been working within the IT industry for two decades covering a huge range of topic areas and technologies, from data center and network infrastructure design, to cloud architecture and implementation.
To date, Stuart has created 150+ courses relating to Cloud reaching over 180,000 students, mostly within the AWS category and with a heavy focus on security and compliance.
Stuart is a member of the AWS Community Builders Program for his contributions towards AWS.
He is AWS certified and accredited in addition to being a published author covering topics across the AWS landscape.
In January 2016 Stuart was awarded ‘Expert of the Year Award 2015’ from Experts Exchange for his knowledge share within cloud services to the community.
Stuart enjoys writing about cloud technologies and you will find many of his articles within our blog pages.