The Secret Life of AWS: VPCs and Subnets Explained
.jpeg)
The Secret Life of AWS: VPCs and Subnets Explained
Public and private subnets, security groups, and why drawing the boxes isn't enough
#AWS #CloudComputing #VPC #NetworkingBasics
Margaret is a senior software engineer. Timothy is her junior colleague. They meet in a grand Victorian library in London — and in every episode, they work through the tools, ideas, and infrastructure that power modern software. Today, Timothy discovers that the cloud has an address.
Episode 7
Timothy arrived with a diagram. He had drawn it himself — on paper, in pencil, with the careful precision of someone who preferred to think visually. He set it on the table between them without preamble.
It showed boxes. EC2 instances, an S3 bucket, a database. Arrows connecting them. A cloud shape around the outside, labeled, in Timothy's neat handwriting: AWS.
Margaret studied it for a moment.
"This is how you think about your architecture," she said.
"It's how I've been thinking about it, yes." He sat down. "Services. Connections between them. The region they live in." He paused. "Something is missing. I can feel it but I can't name it."
Margaret tapped the space between the boxes — the unnamed territory his pencil had left blank.
"The network," she said. "Everything you have drawn lives inside a network. You didn't draw it because you haven't defined it. But it is there regardless — and the decisions you have made about it, or haven't made, shape everything your architecture can and cannot do."
Timothy looked at the diagram differently. "I've been thinking about the services. Not what they sit inside."
"Most developers do," Margaret said. "Until the network stops them."
What a VPC Actually Is
"VPC," Margaret said. "Virtual Private Cloud. The name is more descriptive than it sounds."
"A private network," Timothy said.
"Your private network. Inside AWS, logically isolated from every other customer's resources. When you create a VPC, you define an IP address range — a block of addresses that belong to that network. Everything you create inside the VPC gets an address from that range. Nothing outside the VPC can reach inside unless you explicitly permit it." She paused. "Think of it as the walls of your building, before you add any doors or windows. The building exists. It is enclosed. Nothing gets in or out until you decide otherwise."
"And every AWS account gets one automatically."
"Every AWS account gets a default VPC in every region," Margaret said. "Already configured, already working, ready to use. Which is convenient — and which is also the source of a particular set of problems."
"The default isn't designed for anything specific."
"The default is designed to work," she said. "Which is different from being designed well. We will come back to that." She folded her hands. "First — what a VPC contains."
Subnets — Dividing the Network
"A VPC is a range of IP addresses," Margaret said. "A subnet is a subdivision of that range — a smaller block of addresses, associated with a specific availability zone, where you actually place your resources."
"So the VPC is the whole building," Timothy said. "And subnets are the rooms."
"The rooms, yes. And the rooms have a critical distinction that the building analogy handles well — some rooms face the street, and some don't." She looked at him. "A public subnet has a route to the internet. A resource placed in a public subnet — an EC2 instance, a load balancer — can, if you permit it, be reached from outside. A private subnet has no such route. A resource placed in a private subnet is reachable only from within the VPC — not from the internet, not from your laptop unless you have established a private connection into the VPC. Only from other resources inside the same network."
"And the default VPC?"
"The default VPC has only public subnets," Margaret said. "Everything you place in it is, by default, in a room that faces the street."
Timothy was quiet for a moment. "That seems like the wrong default."
"For getting started quickly, it is convenient. For running anything you care about — a database, an internal service, anything that should not be directly reachable from the internet — it is the wrong default." She paused. "The correct pattern is a layered architecture. Your load balancer in a public subnet — it needs to receive traffic from the internet. Your application servers in a private subnet — they receive traffic from the load balancer, not directly from the internet. Your database in a private subnet — it receives traffic from the application servers, and from nothing else. Each layer reachable only by the layer directly above it."
"Defence in depth," Timothy said.
"Defence in depth. The principle that security should not depend on a single barrier. If the load balancer is compromised, the attacker reaches the application servers — but they are in a private subnet, not directly exposed. If the application servers are compromised, the attacker reaches the database — but only if they have also compromised the security controls between the two." She looked at him steadily. "The default VPC collapses all of those layers into one. Everything in public subnets. Everything facing the street."
Getting Out — The Internet Gateway and NAT
"A public subnet," Margaret said, "has a route to an internet gateway. The internet gateway is exactly what it sounds like — a door between your VPC and the public internet. Traffic flows both ways. Resources in public subnets can receive inbound connections and make outbound ones."
"And private subnets have no door."
"Private subnets have no inbound door. But they frequently need to make outbound connections — a server needs to download a software update, call an external API, reach an AWS service." She paused. "For that, you use a NAT gateway. Network Address Translation. It sits in a public subnet and allows resources in private subnets to make outbound connections to the internet, without allowing the internet to initiate inbound connections to them."
Timothy worked through the logic. "So the private subnet resource sends traffic out through the NAT gateway — which is in the public subnet — which goes through the internet gateway. But inbound traffic from the internet hits the internet gateway, finds no route to the private subnet, and stops."
"Precisely," Margaret said. "Outbound permitted. Inbound blocked. The private resource can reach the world. The world cannot reach the private resource." She paused. "The NAT gateway costs money — it is a managed service, billed by the hour and by data processed. For production environments it is the right answer. For experimentation and non-production work, lighter alternatives exist — but the NAT gateway is what you reach for when it matters." She looked at him. "This is one of the places where the cloud's operational expense model requires attention. Developers who forget a NAT gateway running in a non-production environment will find it on their bill at the end of the month."
"The meter," Timothy said.
"The meter," Margaret agreed.
Two Layers of Security
"The VPC gives you two mechanisms for controlling network traffic," Margaret said. "Security groups and network access control lists. They operate at different levels and they work together."
"Security groups first," Timothy said. He had learned to let her set the order.
"Security groups are attached to individual resources — an EC2 instance, a database, a load balancer. They define what traffic is allowed in and what traffic is allowed out, at the resource level. They are stateful — if you allow an inbound connection, the response traffic is automatically allowed out, without a separate rule." She looked at him. "A security group is the lock on a specific door. You define who can knock, and from where."
"And network access control lists?"
"NACLs operate at the subnet level. Every subnet has one. They define what traffic is allowed into the subnet and out of the subnet, before it reaches any individual resource. They are stateless — inbound and outbound rules are evaluated independently, so you must explicitly allow both directions." She paused. "A NACL is the gate at the entrance to the room, before anyone reaches the individual doors inside."
"So traffic has to pass through both."
"Inbound traffic hits the NACL first, then the security group. Both must permit it. Either can block it." She folded her hands. "In practice, most of the nuanced work happens at the security group level — NACLs are often left at their default permissive settings and security groups carry the specific rules. But understanding both layers matters, because when something is blocked and you cannot determine why — the answer is usually in one of those two places."
"Or both," Timothy said.
"Or both," Margaret said. "Networking problems have a particular quality. They are binary — traffic either arrives or it doesn't — but the cause can be in many places. Methodical elimination is the only reliable approach."
The Default VPC — When It's Fine and When It Isn't
"I want to be fair to the default VPC," Margaret said. "Because it is not without value."
Timothy looked up, slightly surprised. Margaret rarely defended defaults.
"For development. For experimentation. For following a tutorial, spinning up a quick test, trying something new — the default VPC is perfectly adequate. It works. It removes the configuration burden when the configuration is not the point." She paused. "The problem is not that it exists. The problem is when it persists — when something that was built quickly for testing gradually becomes something that matters, without the network ever being reconsidered."
"The pet that wasn't supposed to become a pet."
"Exactly that instinct, applied to infrastructure." She looked at him. "A production application — one handling real users, real data, real traffic — should have a VPC that was designed for it. Public and private subnets, correctly layered. Security groups with specific, minimal rules. A NAT gateway for outbound private traffic. An internet gateway only where genuinely needed." She paused. "None of this is complicated to build. It requires perhaps an hour of thought and configuration. The default VPC requires none — which is its appeal, and its limitation."
"An hour now or a problem later."
"Almost always," Margaret said. "The defaults in AWS are designed to remove friction at the beginning. Your job is to know when removing friction is the right call and when it is deferring a decision that will cost you later." She looked at him directly. "The network is not someone else's problem. It is the foundation your application runs on. Understand it before you build on it."
Before Next Time
He looked at his diagram again — the boxes, the arrows, the cloud shape around the outside.
"I need to draw this again," he said.
"You do," Margaret said.
He picked up his pencil and, on the back of the same sheet of paper, began again. This time the cloud shape had an interior. A rectangle labeled VPC. Inside it, subnets — some marked public, some private. An internet gateway at the edge. A NAT gateway in the public subnet, an arrow from the private subnet pointing toward it. The EC2 instances in private subnets. The load balancer in public. The database deepest in — private subnet, no outbound arrow at all.
He set down the pencil and looked at it.
"That's what it should have looked like," he said.
"That," Margaret said, "is what every architecture diagram should start with. Before the services. Before the logic. The network first, because everything else sits inside it."
He left the new diagram on the table — an offering, or perhaps a reminder — and went out into the London afternoon.
She looked at it for a moment after he had gone, then turned back to her book, satisfied in the particular way of a teacher whose student has stopped drawing the map and started reading it.
Next episode: S3 in Depth — Timothy has met S3 as one of the first three services. Now he goes deeper. Versioning, lifecycle policies, access control, and the moment he realizes that S3 is not just a place to put files — it is an architectural decision.
Aaron Rose is a software engineer and technology writer at tech-reader.blog.
Catch up on the latest explainer videos, podcasts, and industry discussions below.
