Day 78 of 90 Days of DevOps Challenge: VPC Components in detail

Yesterday, I learned that a VPC provides you with your own private, isolated section of the AWS cloud, where you can launch resources securely. And hypervisors, although invisible to most of us, are the virtual engine room that powers the entire cloud, enabling multiple virtual machines to run on a single piece of hardware. It helped me understand what’s happening behind the scenes when I launch an EC2 instance or scale a container.

Today, building on that, I wanted to understand what makes a VPC functional. While creating a VPC is straightforward, the real power lies in how you configure its components: subnets, route tables, gateways, security layers, and more. These aren't just technical pieces; they define how safe, efficient, and flexible your entire cloud environment is.

A Closer Look at the Core VPC Components

Here’s a breakdown of the most important VPC components and how each one fits into the larger picture.

CIDR (Classless Inter-Domain Routing)

At the heart of any VPC setup is its CIDR block, which defines the IP address range for your network.

For example: 10.0.0.0/16

• This means the VPC has IP addresses from 10.0.0.0 to 10.0.255.255, allowing for 65,536 IPs.

• The /16 indicates the prefix length: how many bits are fixed for the network. The smaller the number, the larger the range.

You can split this range into smaller CIDRs for subnets, like:

• 10.0.1.0/24 (256 IPs)

• 10.0.2.0/24, etc.

AWS reserves 5 IP addresses per subnet, so keep that in mind when calculating.

Subnets

Subnets let you divide your VPC into smaller, manageable sections. This is where you decide what goes public and what stays private.

• Public subnets are designed for resources that need internet access, like web servers or load balancers.

• Private subnets are for internal components like databases or backend services that should not be exposed directly to the internet.

Each subnet is tied to one availability zone, which helps with high availability and fault tolerance.

Route Tables

Route tables control how traffic moves in and out of your VPC.

Every subnet is associated with a route table, and each table contains a set of rules that determine where traffic should go, whether it's to another subnet, to the internet, or to a NAT gateway.

For example, to allow internet access from a public subnet, you’d add a route that sends all outbound traffic (0.0.0.0/0) to an internet gateway.

Internet Gateway

An internet gateway is what connects your VPC to the internet.

Once you attach it to your VPC and update your route tables accordingly, resources in public subnets can send and receive traffic from the internet. This is typically used for web servers or public-facing APIs.

NAT Gateway

If you want instances in private subnets to access the internet (say, to download updates or install packages), but you don’t want them to be directly exposed, that’s where a NAT Gateway comes in.

It allows outbound traffic but blocks any unsolicited inbound traffic. You usually deploy it in a public subnet and then route private subnet traffic through it.

Security Groups

Security groups are your instance-level firewalls.

They define what kind of traffic is allowed in or out of an EC2 instance. Unlike traditional firewalls, security groups are stateful, if you allow outbound traffic, the response traffic is automatically allowed back in, which simplifies configuration in many cases.

Typical use cases include allowing SSH from your IP, or HTTP/HTTPS from anywhere.

Network ACLs (NACLs)

Network ACLs work at the subnet level and offer an extra layer of security.

They are stateless, meaning you have to manually allow both inbound and outbound traffic. They’re especially useful when you want to block a specific IP range or enforce more granular subnet-wide rules.

VPC Peering

VPC Peering lets you connect two VPCs privately so that resources can talk to each other using internal IP addresses.

This is useful when you have microservices or environments (like dev and prod) running in separate VPCs but need to share data or communicate securely. Just note that peering connections are not transitive; you can’t use one peering connection to reach another VPC through a third.

VPC Endpoints

Endpoints allow private connections from your VPC to supported AWS services without ever touching the public internet.

There are two types:

• Gateway endpoints (for services like S3 and DynamoDB)

• Interface endpoints (for most other services, using network interfaces)

This boosts both security and performance, especially when your private subnet resources need to access AWS services.

Elastic IPs

An Elastic IP is a static public IP address you can assign to an instance or NAT gateway.

This is handy when you want your instance to have a consistent public IP, even after restarts or reboots. It also helps in scenarios where you need to whitelist your IP with external services or configure DNS routing.

DHCP Options Set

This is where you define how name resolution works within your VPC.

You can specify domain names and DNS servers, either using AWS’s built-in resolver or your own. This becomes especially useful in hybrid cloud setups or when integrating with on-premise environments.

Final Thoughts

Today helped me understand that a VPC isn’t just a box where things run; it’s the framework that controls how your applications talk to each other, how they connect to the outside world, and how they stay secure.

Each component plays a specific role, and when designed thoughtfully, your VPC becomes a powerful, flexible, and secure environment to run virtually anything in the cloud.

Tomorrow, I’ll be looking into VPC Flow Logs, a tool that helps you monitor and troubleshoot traffic in and out of your VPC. It’s a big part of keeping your infrastructure observable and secure, and I’m excited to see what insights it can offer.