Why Subnet your VPC?
Start course
1h 19m

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.

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, where I try to answer the question of why we may want to Subnet our VPCs and what the benefits are by doing so.

Starting with logical network division. Creating multiple Subnets allows you to create logical network divisions between your resources. By doing so, you could have a Subnet for database instances, another for application servers, and another for web infrastructure.

By splitting up your Subnets this way, helps to enforce a greater level of security. Logical grouping of similar resources also helps you to maintain an ease of management across your infrastructure.

On this point, I remember being in a meeting with a network engineer many years ago. And someone around the table asked, "Why do we need to Subnet?" He responded with a question. "Does your house have more than one room? " He then continued by saying, "It's a similar thought process, your house has more than one room, as each room serves a different purpose, A kitchen, a lounge, a dining room, etc. Think of these as Subnets. The space in your house, your CIDR block, has been divided into smaller more manageable purpose specific rooms rather than one large room in which you can cook, clean and sleep in, which would soon become very disjointed."

Security. By having multiple Subnets with similar resources grouped together, as per the previous point, it allows for greater security management. By implementing network level virtual firewalls, called network access control lists, or NACLs, it's possible to filter traffic on specific ports from both an ingress and egress point at the Subnet level.

For example, if you had a Subnet that only held my SQL RTS databases within it, you could allow communication between your application service Subnet to talk to your database Subnet on port 1443 for my SQL. And then block and drop all other packets that do not meet this criteria. If you had web servers and application servers within the same Subnet as your RTS instances, you would have to open up a lot of other ports, reducing the level of security within that Subnet.

Having multiple Subnets allows you to create both private and public Subnets. Public Subnets allows the resources within it to access and connect to the internet, and the outside world to connect to those resources, depending on certain security controls. Private Subnets are not directly accessible from the internet. And so private Subnets are protected from the outside world, providing a greater level of security by its very nature.

You may want some of your Subnets to route out to the internet, some to remain private, and some to communicate back to your corporate on premise network over a VPN link. Through the use of routing tables associated to each specific Subnet, you can route traffic as required to cater for these communication paths.

A Subnet can only belong to one route table at any time. Therefore, by creating multiple Subnets, you can restrict some resources in those Subnets to specific routes. If your solution requires a level of high availability, and it most likely will, then it's best practice to deploy services across multiple availability zones within a region.

Here becomes a restriction of VPC Subnets in that a single Subnet cannot span across two availability zones. As a result, this best practice forces you to create an additional Subnet in the second availability zone. So if you want high availability within your environment, you'll need Subnets in at least two availability zones in any region.

As we go through this course, you'll see the benefits that this provides. As you can see, there are many advantages over creating multiple Subnets within your VPC. And as you design, architect and secure your infrastructure, you will quickly see how multiple Subnets enables ease of network management, rooting and security.

In the next lecture, I want to look at what a VPC Subnet actually looks like and what its configurable components are.

About the Author
Learning Paths

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.