The course is part of these learning pathsSee 2 more
Creating 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.
- 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
- 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, where I shall be discussing subnets when used for VPC peering.
Let me start by explaining what VPC peering is at a high level. VPC peering allows you to connect two or more VPCs together, using IPV4 or IPV6, as if they were a part of the same network.
Once the peer connectivity is established, resources in one VPC can access resources in the other. The connectivity between the VPCs is implemented through the existing AWS network infrastructure, and so it is highly available with no bandwidth bottleneck. As peered connections operate as if they were part of the same network, there are restrictions when it comes to your CIDR block ranges that can be used.
If you have overlapping or duplicate CIDR ranges for your VPC, then you'll not be able to peer the VPCs together. So this is a design consideration if you plan on setting up multiple VPCs that you want to peer. Also from a design perspective, you are not able to daisy-chain VPCs together expecting them all to talk across one large network.
Each AWS VPC will only communicate with its peer. As an example, if you have a peering connection between VPC 1 and VPC 2, and another connection between VPC 2 and VPC 3 as shown, then VPC 1 and 2 could communicate with each other directly, as can VPC 2 and VPC 3, however, VPC 1 and VPC 3 could not. You can't route through one VPC to get to another.
To allow VPC 1 and VPC 3 to talk directly, you would have to implement a separate peering connection, between VPC 1 and VPC 3 as shown. Interestingly, the daisy-chain diagram allows the possibility of having two of the VPCs to have overlapping or even identical VPC CIDR blocks.
Let's say VPC 1 and VPC 3 have exactly the same CIDR block, which both connect to VPC 2. As the peer does not exist between VPC 1 and VPC 3, this is allowed without causing an issue. You may be wondering how this works from a routing perspective, if VPC 2 has two VPCs with the same CIDR block range, where does it know where to send traffic? I shall be covering VPC routing in an upcoming lecture, where this scenario will be discussed and explained.
Now, if we applied the same CIDR block settings in this example to the second scenario, where VPC 1 and VPC 3 were also peered, we would encounter configuration issues, and the peer connection would not be allowed due to overlapping CIDR blocks. We have now come to the end of this lecture covering VPC peering subnet considerations,
in the next lecture I shall be discussing flow logs, and how these can be used to monitor network traffic in and out of your subnets.
About the Author
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 80+ courses relating to Cloud, mostly within the AWS category and with a heavy focus on security and compliance.
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.