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 discuss the differences between public and private subnets, and how they are defined. Now we have seen what a subnet looks like, I want to talk to you about both public and private subnets. In a nutshell, public subnets have direct access to the Internet, whereas your private instances do not.
So what makes a subnet public? There are essentially 2 components required to make any one of your subnets classed as a public subnet. Firstly, you need to create and attach an Internet gateway to your VPC. This Internet gateway is a managed service, controlled, configured, and maintained by AWS. It scales horizontally automatically, and is classified as a highly valuable component of your VPC infrastructure.
Once your Internet gateway is attached to your VPC, you have a gateway to the Internet. However, at this point, your instances have no idea how to get out to the Internet. As a result, you need to add a default route to the route table associated with your subnet. The route could have a destination value of 0.0. 0. 0/0, and the target value will be set as your Internet gateway ID.
The destination value of 0.0.0.0/0 essentially says for any destinations not already known to the route table, then use this route, which points to the target of the Internet gateway. With an Internet gateway attached, and a route in place, the subnet is now considered to be a public subnet.
There are, however, additional elements required before your instances within that public subnet can access the outside world. Any instance that you're required to communicate with external resources on the Internet and beyond, will require a public IP address. Also, you'll need to ensure that your public subnet NACL is not restricting or blocking expected ingress and egress traffic.
For example, if you are using http, and the NACL denied all traffic going over port 80, then you would run into problems very quickly. So to quickly recap, to enable the instances to communicate with the Internet, the following conditions must be true. The VPC must have an Internet gateway attached. The subnet must have a route, for example, 0.0.0.0/0, with a target of the attached Internet gateway. The instances must have a public IP address assigned. And the associated NACL must allow ingress and egress traffic. Before moving on from this section, I just want to revisit a point I made about the public IP address allocation for the instances.
Depending on the IP addressing behavior of the subnet, these can either be automatically assigned to new instances launched within the subnet, or you must manually choose to have a public IP address for your instance. By default, all subnets have the automatic assigned of public IP addresses turned off.
Even when a subnet is considered a public subnet. The assignment remains as a manual process for instances. To modify the subnet IP addressing behavior from within the management console, you must first select the subnet within the VPC service, select subnet actions, then select Modify Auto Assign IP Settings.
Select the Tick box to enable auto assign public IPV4 addresses, and then click Save. The subnet will then automatically assign a public IP address to any instances that are launched within that subnet. Do be aware that for each instance created, you can overrule this decision. As you can see, although the default is Enable, it's possible to select Disable for the instance.
Any public IP address assigned by this method is not directly associated to your AWS account. Instead it's taken from a pull of addresses owned by AWS, and when the instance is no longer required, the IP address is released back into the AWS pull. You can't request the same public IP address if you need to use it again.
If you acquire this functionality of being able to reuse, and reassign a public IP address, then you would need to use an elastic IP address, an EIP. Using an EIP is another option we have to give instances public IP addresses. So far, we have looked at VPC CIDR Block Ranges, and subnetting of these blocks into smaller side blocks for subnets, Subnet IP reservation addresses, why you would want and need to subnet your VPC, Public and private subnets within your VPC and subnet IP addressing behavior. However, does any of this change if you have multiple VPCs? What considerations need to be made if you are looking to peer multiple VPCs together?
In the next lecture, we will take a look at VPC peering subnet considerations.
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.