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 covering AWS VPC Subnets.
So what does a subnet look like with an AWS, and what information does it contain? Well when the subnet is configured and created within the management console, it contains the data around the following components. Summary, Route Table, Network ACL, Flow Logs, and Tags.
Let's look at the summary. The summary is just that, a summary of all the elements and metadata associated with the subnet. The Subnet-ID shows the automatically generated ID of the subnet along with its tag name. The Subnet-ID is a unique identifier for that subnet. You can use this value when configuring AWS through a command line interface, such as the AWS CLI.
For example, you could issue a following command to run an EC2 instance in this particular subnet. The IPv4 CIDR section shows the CIDR Block associated to that subnet using IPv4. And the same applies for the IPv6 CIDR Block section too. The state of the subnet will either show as pending or available.
The VPC section shows the VPC that the subnet belongs to using its VPC ID, which again, is a unique identifier of the VPC, similar to that of the Subnet-ID. The available IPs list how many IP available addresses you have for your resources left within that subnet. If you try to launch an EC2 instance in your subnet, and it does not have enough free addresses, then you'll get the following error.
Remember, in addition to the network and broadcast address of the subnet, three other IP addresses are reserved within the subnet for AWS purposes. The Availability Zone shows which AZ the subnet belongs in. And again, subnets cannot span more than one Availability Zone. The Route Table shows which Route Table the subnet is using and is shown by its Route Table ID and Tag name. More on AWS routing will be covered in an upcoming lecture.
The Network ACL, or NACLs, as I refer to, shows the subnet's associated NACL. And again, by using its NACL ID. During the creation of a new VPC, the default Route Table and the default NACL are also created. These defaults are then associated to any subnet that did not have a custom Route Table or NACL associated.
The Default Subnet section identifies if the subnet was created by default from the default VPC that comes with your AWS account. The Auto-assign Public IP value can either be set to as yes or no, but I'll talk more about this setting later in this lecture. And finally, the Auto-assign-IPv6 addresses again can be either set to yes or no.
The Route Table tab shows the Route Table that the subnet is using along with the route's destinations and targets for that route. Further details on configuration of routes will be provided in an upcoming lecture so I won't go into detail on this section right now.
The Network ACL, or NACL, shows the current NACL associated to the subnet and it will display both inbound and outbound rule sets.
If you haven't created a custom NACL, then your subnet will automatically be associated with your VPC's default NACL, which allows all traffic to flow in and out which, by default, provides no level of security, and so I highly recommend you either modify your default NACL or even better, create a custom NACL for each subnet.
NACLs provide a rule-based tool for controlling ingress and egress network traffic at the protocol and subnet level. In other words, NACLs monitor and filter traffic moving in and out of your subnet. NACLs are stateless by their design, meaning that any response traffic generated from a request will have to be specified in either the inbound or outbound rule set depending on the direction of response expected.
The rule set itself is very simple, and has both inbound and outbound list of rules, and these rules are comprised of just six different fields. These being, Rule Number, ACL rules are read in the ascending order, and as soon as a network packet is received, it reads each rule in ascending order until a match is found.
For this reason, you'll want to carefully sequence your rules with an organized numbering system. I would suggest that you leave a gap of at least 50 between each of your rules to allow you to more easily add new rules in sequence later if it becomes necessary. Type, this dropdown list allows you to select from a list of common protocol types, including SSH, RDP, HTTP, and POP3.
You can alternatively specify custom protocols such as varieties of ICMP. Protocol, based on your choice for type, the protocol option might be grayed out. For custom rules like TCP/UDP, however, you should provide a value. Port Range, if you do create a custom rule, you'll need to specify the port range for the protocol to use.
Source, this can be a network subnet range, a specific IP address, or even left open to traffic from anywhere using the value of 0.0.0.0/0.
Allow/Deny, each rule must include an action, specifying whether the traffic will be permitted to either enter or leave the associated subnet or not.
The Flow Logs tab shows you any Flow Logs that you have set up and created for the subnet to capture IP traffic flow information. More information on Flow Logs will be covered in a later lecture.
Finally, the Tags tab allows you to add custom key value pairs to help with the tagging of your subnet. In this example, I added a Key of Name with a Value of Subnet A.
That brings us to the end of this lecture. Following this, I shall be talking about the differences between a public and private subnet.
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.