Skip to main content
Back to path

Welcome to a Grasp lesson

Create a free account to keep studying and create your own study path.

Lesson 5

Building Your Custom AWS VPC

Recommended resources

Hello! Welcome to our next lesson on AWS core infrastructure.

In our previous session, we established the two fundamental layers of network security that protect your EC2 instances: stateful Security Groups and stateless Network ACLs. We learned how they function as firewalls at the instance and subnet levels, respectively. Now, we're going to zoom out and construct the entire network neighborhood—the Virtual Private Cloud (VPC)—where those subnets and instances will reside.

Today's lesson is pivotal. We will focus on designing and building a custom VPC from scratch. This includes creating public and private subnets, configuring route tables to direct traffic, and setting up the necessary gateways for internet connectivity. Mastering VPC design is a non-negotiable skill for any serious DevOps engineer, especially for roles at companies like Google or Amazon, where scalable, secure, and resilient network architecture is the bedrock of every service.

1. The Blueprint: Designing a VPC

Before creating a single resource in AWS, a senior engineer thinks about the design. A well-designed VPC provides security, scalability, and logical isolation. It starts with understanding the application's needs and planning for future growth.

A great article from DevOpsCube, "AWS VPC Design: A Practical Approach For Beginners," frames this process perfectly. It emphasizes starting with requirements and creating documentation, which are hallmarks of a professional engineering culture.

AWS VPC Design: A Practical Approach For Beginners

This article will guide you through the thought process of designing a VPC before building it.

First, read the section to appreciate the importance of architectural planning. Then, focus on the section about choosing a CIDR block. Pay attention to the advice on planning for future expansion and avoiding IP conflicts with on-premise networks—a common real-world constraint. Finally, review the tables under the documentation section to see how a professional subnetting plan is documented.

As you've just read, the first two critical decisions are the overall VPC CIDR block and the subnetting strategy.

  • VPC CIDR Block: This defines the entire private IP address space for your network. Choosing /16 (e.g., 10.0.0.0/16) is common as it provides 65,536 private IP addresses, offering ample room for growth. Your networking background tells you this is a Class A private range, but the key here is giving yourself enough space so you don't have to re-architect your network later.
  • Subnetting Strategy: The VPC is then carved into smaller IP ranges called subnets. The most fundamental design pattern is to create:
    • Public Subnets: For resources that must be directly reachable from the internet, like web servers (often behind a load balancer) or bastion hosts.
    • Private Subnets: For backend resources that should be shielded from the internet, such as application servers, databases, and container tasks. This is a core security principle.

For resilience and high availability—a key concern in FAANG interviews—you will always distribute these subnets across multiple Availability Zones (AZs).

This diagram illustrates a common multi-AZ architecture. Instances are placed in subnets across different AZs to ensure the application remains available even if one AZ experiences an outage. The public subnets house internet-facing resources, while the private subnets protect backend services like databases.

2. The Building Blocks

To bring our design to life, we need to understand the key AWS components that form a custom VPC.

Internet Gateway (IGW)

An Internet Gateway is a horizontally scaled, redundant, and highly available VPC component that allows communication between your VPC and the internet. Think of it as the single, managed entry/exit point for your entire virtual network. A VPC can have only one IGW attached.

NAT (Network Address Translation) Gateway

A NAT Gateway is an AWS managed service that enables instances in a private subnet to connect to the internet or other AWS services, but prevents the internet from initiating a connection with those instances.

This solves a critical problem: How do your private database servers download security patches or connect to a third-party API without having a public IP address? The NAT Gateway lives in a public subnet and provides this outbound-only internet access for your private subnets.

In this setup, web servers in the public subnet can be accessed from the internet. The database servers in the private subnet cannot be accessed from the internet. However, they can initiate outbound connections (e.g., for updates) through the NAT Gateway, which routes the traffic via the Internet Gateway.

Route Tables

A route table contains a set of rules, called routes, that are used to determine where network traffic from your subnet or gateway is directed.

  • Each VPC has a Main Route Table by default.
  • Best practice is to create Custom Route Tables and explicitly associate them with your subnets for granular control.
  • A subnet is considered public if its associated route table has a route to an Internet Gateway (0.0.0.0/0 -> igw-id).
  • A subnet is considered private if its route table does not have a route to an IGW. For outbound internet access, its default route would point to a NAT Gateway (0.0.0.0/0 -> nat-id).

3. The Build: From Design to Reality

Now, let's put theory into practice. The following video from Digital Cloud Training provides a clear, step-by-step walkthrough of creating a custom VPC in the AWS console. We'll follow along to build a network with public and private subnets, an IGW, and a NAT Gateway.

Create a Custom VPC on AWS

This video is a comprehensive hands-on guide to building the exact architecture we've been discussing.

Watch the entire video, but I'll break down the key stages for you to focus on: Introduction and Planning (The configuration): The instructor lays out the plan, which closely matches our design goals. VPC and Subnet Creation (The build): Observe the manual creation of the VPC and the four subnets (two public, two private across two AZs). Note the crucial step of enabling "Auto-assign public IPv4 address" for the public subnets. Internet Gateway & Public Routing (The IGW): See how the IGW is created, attached to the VPC, and how a route is added to the main route table to make it "public". Private Route Table Configuration (Private routing): This is a critical step demonstrating best practices. A new, custom route table is created for the private subnets, explicitly associating them and isolating them from the public route table. NAT Gateway & Private Outbound Access (The NAT Gateway): Watch how the NAT Gateway is created in a public subnet and how the private route table is modified to route outbound traffic through it. Cleanup (Very Important!) (The cleanup): Pay close attention here. NAT Gateways incur costs. The video shows how to correctly delete the NAT Gateway and, crucially, release its associated Elastic IP to avoid unexpected charges.

For another perspective, the video below by Travis Media explains these same concepts with a narrative that is particularly helpful for those with a programming background. It builds the network piece by piece, explaining the "why" at each step as it resolves connectivity issues.

AWS Networking Basics For Programmers | Hands On

This video walks through the same process but with a focus on why each component is necessary, which will help solidify your understanding.

You don't need to perform the steps again, but watch these sections to reinforce the concepts: VPC and CIDR (Creating the VPC): Provides a great practical explanation of CIDR ranges. Subnets (Creating subnets): Shows the logic of splitting the VPC's CIDR into smaller subnets. IGW and Public Routing (The IGW section): Excellent demonstration of "why can't I connect?" leading to the need for an IGW and a corresponding route. NAT Gateway and Private Routing (The NAT Gateway section): Clearly shows why a private instance can't access the internet and how a NAT Gateway solves this.

By completing these steps, you have manually built the most common and foundational VPC architecture used in AWS. As someone with a background in Infrastructure as Code, you can already imagine how defining these resources—the VPC, subnets, gateways, and routes with their explicit dependencies—is a perfect fit for a declarative tool like Terraform, which we will cover in a future module.

Conclusion

Today, we've moved from network security rules to network architecture. You've learned not just how to build a VPC, but how to design one based on principles of security, scalability, and high availability.

Key Takeaways:

  • Design First: A robust VPC starts with planning your CIDR range and subnetting strategy based on application requirements and future growth.
  • Public vs. Private: Isolate resources using public and private subnets. Public subnets are for internet-facing components; private subnets protect your backend infrastructure.
  • Gateways for Connectivity: The Internet Gateway (IGW) provides two-way communication with the internet for public subnets. The NAT Gateway provides one-way, outbound-only internet access for private subnets.
  • Route Tables Direct Traffic: Route tables act as the traffic controllers of your VPC. A subnet's connectivity is defined by the routes in its associated route table.

Now that we have a secure, custom network, we can start deploying services into it. In our next lesson, we will provision a managed database using Amazon RDS and learn how to place it securely within the private subnets of the VPC we designed today, demonstrating a real-world multi-tier application architecture.