VPC Network Design

VPC fundamentals, public/private subnets, the critical difference between Security Groups and NACLs, NAT Gateway, and VPC Endpoints explained with everyday analogies.

VPC (Virtual Private Cloud) is your own private virtual network inside AWS. It might sound complex at first, but think of it like designing an apartment complex. The entire complex is your VPC, each building inside is a subnet, and the main gate is the Internet Gateway. Everything is yours to design and control.

 

What is a VPC and Why Do You Need One?

When you put a server on the internet, you cannot just throw it out there without any planning. You need to decide which IP addresses it will use, who is allowed to connect to it, and how your servers talk to each other. VPC gives you a private network space where you control all of these decisions.

Here is a concrete example. Imagine you run an online shopping platform. Your web servers need to be accessible to customers on the internet. But your order database must never be reachable directly from the internet. With a VPC, you can design exactly this architecture, putting web servers in a public subnet and databases in a private subnet.

 

CIDR Block — Defining Your Address Range

When you create a VPC, you must specify the range of IP addresses it will use. This is called a CIDR block.

Think of it as assigning a range of apartment unit numbers to your complex. You might say apartment numbers 101 through 9999 belong to this complex.

Using 10.0.0.0/16 gives you 65,536 IP addresses to work with. Using 10.0.0.0/24 gives you 256 addresses. The larger the number after the slash, the fewer addresses you have available.

 

Subnets — The Buildings Inside Your Complex

A subnet divides your VPC into smaller networks, just like separate buildings inside an apartment complex, each serving a different purpose.

One critical rule: each subnet must exist in exactly one Availability Zone. For high availability, you should place subnets in multiple AZs so your application survives if one data center has an outage.

Public Subnet is a subnet that can communicate directly with the internet. You place web servers, load balancers, and anything that external users need to reach in a public subnet. Think of it as the ground-floor retail shops in your apartment complex, open and accessible to everyone passing by.

Private Subnet is a subnet that cannot be reached directly from the internet. You place databases, internal application servers, and anything sensitive in a private subnet. Think of it as the residential floors in your apartment complex, where outsiders cannot simply walk in.

 

Routing Tables — Traffic Signposts

A routing table is a set of rules that tells your subnet where to send its traffic. Think of it as road signs at every intersection telling drivers which way to go.

A public subnet routing table looks like this. Traffic destined for 10.0.0.0/16 stays local within the VPC. Traffic destined for 0.0.0.0/0 (everything on the internet) goes to the Internet Gateway. It is this Internet Gateway route that makes a subnet public.

A private subnet routing table looks different. Traffic destined for 10.0.0.0/16 stays local. Traffic destined for 0.0.0.0/0 goes to the NAT Gateway instead of the Internet Gateway. Because there is no direct Internet Gateway route, nothing from the internet can reach this subnet directly.

Each subnet can only be associated with one routing table at a time.

 

Internet Gateway — The Main Entrance

The Internet Gateway is the door between your VPC and the internet. All internet traffic passes through this single entry and exit point. You can attach only one Internet Gateway per VPC.

For a public subnet to actually communicate with the internet, two things must be true. The VPC must have an Internet Gateway attached. The subnet's routing table must have a rule sending 0.0.0.0/0 traffic to that Internet Gateway.

 

Security Group vs Network ACL — The Most Important Comparison on the Exam

Understanding the difference between these two is one of the most tested topics in SOA-C03. You must know this cold.

| Feature | Security Group | Network ACL | |---------|---------------|-------------| | Applied at | Instance level (ENI) | Subnet level | | State | Stateful (remembers connections) | Stateless (treats each packet independently) | | Rule types | Allow rules only | Allow and Deny rules | | Return traffic | Automatically permitted | Must be explicitly permitted | | Default | All inbound denied, all outbound allowed | All traffic allowed | | Rule evaluation | All rules evaluated, most permissive wins | Rules evaluated in number order, first match wins |

!Security Group versus Network ACL

The most confusing concept is Stateful vs Stateless. Here is the clearest way to understand it.

Security Group acts like a smart security guard with a perfect memory. When a guest enters the building, the guard checks their ID. When that same guest leaves, the guard thinks "oh, that is the person I let in earlier" and waves them through automatically. You do not need to separately configure the exit. In networking terms, if an inbound request is permitted, the response goes out automatically without needing an explicit outbound rule.

Network ACL acts like a security guard with no memory at all. When a guest enters, the guard checks their ID. When that same guest tries to leave, the guard has completely forgotten them and checks their ID again from scratch. In networking terms, you must explicitly configure both inbound and outbound rules, including rules for response traffic.

When you configure NACL outbound rules, you must allow the ephemeral port range (1024-65535). Here is why. When your browser connects to a server on port 443, the server sends its response back to a random high port on your computer (say port 52341). The NACL at the subnet boundary must explicitly allow traffic to those high ports, otherwise responses never make it back to your browser.

 

NAT Gateway — The Private Zone's Internet Window

Sometimes instances in a private subnet need to reach the internet. For example, an application server might need to download software updates or call an external API. But you do not want the internet to be able to reach those instances directly.

NAT Gateway solves this perfectly. It allows outbound traffic from private instances to reach the internet, but blocks any inbound connections from the internet to those instances.

Using the apartment analogy: residents (private instances) can order delivery (outbound allowed). But strangers cannot walk up and knock on apartment doors directly (inbound blocked).

Key rules for NAT Gateway. It must be placed in a public subnet, not a private subnet. It requires an Elastic IP (a static public IP address). For high availability, deploy one NAT Gateway per Availability Zone.

 

VPC Endpoints — Access AWS Services Without the Internet

Suppose an instance in a private subnet needs to save files to S3. Without a VPC Endpoint, the traffic would go out through the NAT Gateway, across the public internet, and then into S3. This creates both a security risk (data traveling the public internet) and unnecessary cost (NAT Gateway data processing fees).

A VPC Endpoint lets your instances connect to AWS services through AWS's internal private network, never touching the public internet.

| Type | Supported Services | How It Works | Cost | |------|-------------------|--------------|------| | Gateway Endpoint | S3 and DynamoDB only | Adds a route to your routing table | Free | | Interface Endpoint | Most other AWS services | Creates an ENI in your subnet | Hourly + data charges |

When accessing S3 or DynamoDB from within a VPC, always prefer the free Gateway Endpoint.

 

VPC Flow Logs — Recording All Network Traffic

VPC Flow Logs captures information about the IP traffic going to and from network interfaces in your VPC. You can send these logs to CloudWatch Logs or S3 for analysis.

Each log entry tells you: source IP and port, destination IP and port, protocol used (TCP or UDP), whether the traffic was accepted (ACCEPT) or blocked (REJECT), and how many bytes were transferred.

Here is a real troubleshooting scenario. Your developer says "I cannot SSH into my EC2 instance." You check VPC Flow Logs and find REJECT entries for traffic on port 22. You then look at the Security Group and realize someone accidentally deleted the inbound port 22 rule. You add the rule back and the connection works.

VPC Flow Logs are also invaluable for security auditing. You can see which external IPs have attempted to connect to your servers and whether data is leaving your network in unexpected ways.

 

Accessing Private Instances

How do you connect to an EC2 instance sitting in a private subnet with no direct internet access?

The Bastion Host approach is the traditional method. You place a small EC2 instance (the bastion) in a public subnet and SSH into it first. From there you SSH again to reach your private instance. The downside is that you must manage SSH keys and keep the bastion host itself secure and patched.

The Session Manager approach is the modern, more secure method. It is a feature of AWS Systems Manager that lets you open a terminal session to any EC2 instance directly from the AWS console or AWS CLI, with no SSH keys required and no need to open port 22 at all. Every session is recorded in CloudTrail for audit purposes.

On the exam, whenever you see phrases like "without SSH keys" or "without opening port 22," Session Manager is the answer.

 

Back to blog list