The Secret Life of AWS: Network Isolation (VPC & Security Groups)

Why your database shouldn't have a public IP address.

Part 42 of The Secret Life of AWS

Timothy was proud of his new microservice. He had successfully connected his serverless application to an Amazon RDS PostgreSQL database.

"The latency is great," Timothy told Margaret, bringing up his dashboard. "I can query the database directly from my local machine using pgAdmin, and the application connects perfectly."

Margaret leaned in and looked at the connection string on his screen.
Host: checkout-db.c3x...us-east-1.rds.amazonaws.com

She opened the AWS Console, navigated to the RDS instance, and checked the network settings.
Publicly Accessible: Yes
Security Group Inbound Rules: PostgreSQL (5432) | Source: 0.0.0.0/0

Margaret sighed. "Timothy, your database is sitting on the public internet."

"I know," Timothy said. "I had to set it to 'Publicly Accessible' so I could connect to it from my laptop to run migrations. It's fine, though—it has a strong password."

"A strong password is an application-level defense," Margaret corrected. "But you have completely bypassed the network-level defense. If a vulnerability is found in the PostgreSQL engine tomorrow, anyone on Earth can run a port scan, find your database, and attack it directly."

"We need to implement Network Isolation."

The Network Boundary (VPC & Subnets)

Margaret pulled up an architecture diagram tool.

"When you build in AWS, your resources live inside a Virtual Private Cloud (VPC)," she explained. "A VPC is a logically isolated section of the AWS network. But inside that VPC, you divide the space into Subnets."

She drew two boxes inside the VPC.

Public Subnet: "This subnet has a route to the Internet Gateway. Things placed here—like Load Balancers—can be reached from the outside world."
Private Subnet: "This subnet has no route to the internet. Things placed here cannot be accessed from the outside, period."

"Right now," Margaret said, "your database is in a public subnet. We are moving it to a private subnet."

"But how will the application talk to it?" Timothy asked. "And how will I run migrations?"

"Your application will run inside the same VPC," Margaret explained. "Resources inside the same VPC can route traffic to each other privately, without ever crossing the public internet. As for your migrations, we will use AWS Systems Manager Session Manager to securely access a private bastion host—no open ports or direct Wi-Fi connections required."

The Instance Firewall (Security Groups)

Margaret initiated the subnet migration. "RDS allows us to modify the instance and change its subnet group. It handles the DNS updates behind the scenes, so there is minimal disruption."

"Moving it to a private subnet stops the public internet," she continued. "But we still need to control traffic inside the VPC. We do that using Security Groups."

"A Security Group is a stateful, instance-level firewall. For subnet-level rules, we would use Network ACLs, but the instance boundary is our primary control point. By default, a Security Group denies all inbound traffic."

She opened the Security Group attached to the database. Timothy had set the source to 0.0.0.0/0, which meant "allow traffic from any IP address."

"We are removing this," Margaret said, deleting the rule.

"Now the database is completely isolated," Timothy noted. "Even the application will get a connection timeout."

"Exactly. Now we explicitly grant access using Security Group Referencing."

Instead of typing an IP address into the source field, Margaret typed the ID of the Security Group attached to Timothy's application: sg-0abc1234app.

"This is the cornerstone of AWS network security," Margaret emphasized. "We don't authorize IP addresses, because IP addresses change. We authorize identities. This rule states: 'Allow inbound traffic on port 5432, but only if that traffic originates from a resource wearing the Application Security Group'."

The Layers of Defense

Timothy reviewed the new architecture.

"If I try to connect from my laptop now, it drops the packet immediately," he observed. "It doesn't even ask for a password."

"Correct," Margaret nodded. "You have established Defense in Depth. To compromise this database, an attacker would have to:

Infiltrate the VPC.
Compromise a resource that belongs to the specific Application Security Group.
Guess or steal the database password."

"Security isn't just about IAM policies and strong passwords," she concluded. "It is about making sure that even if the front door is unlocked, there are no roads leading to the building."

Timothy looked at the diagram. "What if I build a second microservice in a completely different VPC? How do they talk to each other without using the public internet?"

Margaret smiled. "That requires VPC Peering. But that is an architecture lesson for another day."

Key Concepts

Virtual Private Cloud (VPC): A logically isolated virtual network where you launch your AWS resources.
Public Subnet: A subnet whose route table directs subnet traffic to an Internet Gateway, allowing external access.
Private Subnet: A subnet without a direct route to the internet. Backend systems like databases should always reside here.
Security Group: A virtual firewall that controls inbound and outbound traffic for associated resources at the instance level.
Network ACL (NACL): An optional layer of security for your VPC that acts as a firewall for controlling traffic in and out of one or more subnets.
Security Group Referencing: The practice of using a Security Group ID as the source in an inbound rule, rather than a static IP address or CIDR block, ensuring dynamic and tightly coupled security.
Defense in Depth: The strategy of using multiple, layered security mechanisms so that if one fails, another stands in the way.

Aaron Rose is a software engineer and technology writer at tech-reader.blog and the author of Think Like a Genius.

Search This Blog

Tech-Reader.blog