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 want to look at how to configure routing for both internet gateways and NAT gateways. In a previous lecture, I talked about public and private subnets and how a public subnet is defined. A part of this public subnet definition is an association of an internet gateway.
This internet gateway, or IGW, as it's known, provides a means of communicating out to the internet. This internet gateway is aservice, controlled, configured, and maintained by AWS. It scales horizontally automatically and is classified as a highly available component of your VPC infrastructure. Once your internet gateway's attached to your VPC, you have a gateway to the internet.
Now you need to configure the subnet's route table to point to this internet gateway, and therefore, makin' it a public subnet. Often, the route is configured as follows. The destination value of 0.0.0. 0/0 essentially implies that for any destinations that are not known by the route table, then use this route, which has a target pointing out to the internet gateway.
It's essentially used as a catch-all, if no other route exists. However, the destination for the internet gateway doesn't always have to point to all other destinations. You can have a destination pointing to a specific IP out on the internet, or to a specific range if required. You may need to do this for security and compliance reasons.
Any subnet which has a route table associated that points to an internet gateway is considered a public subnet, as it has connectivity out to the internet. Routing for a NAT gateway is slightly different, but also requires the use of a public subnet to be configured. To briefly explain, a NAT gateway allows instances within a private subnet access out to the internet; however, access to the instances within these private subnets cannot be initiated from the internet.
This diagram shows a VPC with two subnets, one public, 10.0.1.0/24 and one private, 10.0.2.0/24. The public subnet is configured with a route to the internet gateway and can access the internet as required. Instances in the private subnet, which are kept private for security reasons, but still need access to the internet for important operating system updates, and so need to be able to initiate a route to the internet.
The route table for the private subnet has a very similar route to the public subnet, in that they both have a destination route to 0.0.0.0/0. The private subnet, however, has a route to the NAT gateway instead, which is located within the public subnet. From here, the NAT gateway will provide internet connectivity.
From a design perspective, if you had multiple availability zones but only one NAT gateway configured, and the AZ went down which held the NAT gateway, all of your other private subnets across all AZs would not be able to connect to the internet. To resolve this, configure a public subnet in each AZ and update the route tables for all the private subnets in that availability zone to point to the new NAT gateway.
That way, if any AZ goes down, it will not affect the internet access for private instances within other AZs, as this will now be AZ-independent.
Coming up in the next lecture, routing configurations for VPC endpoints.
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.