Stop 10 · Cloud Platforms (AWS / GCP / Azure)Topics · 3/11

AWS Networking & Security

In short

Most cloud breaches aren't clever hacks. They're a public database, a security group open to the internet, or a server in the wrong subnet. Good VPC design prevents them.

Applying Phase 3's networking fundamentals specifically within AWS — security groups, network ACLs, and VPC design patterns for isolating public-facing and internal resources correctly.

The mascot walks through a gated society with a guard at the main gate and a lock on each flat door.

Think of it like this

The gated society

A gated society has a guard at the main gate checking everyone entering the compound, and a separate lock on every flat door. Network ACLs are the main gate, checking traffic at the subnet edge. Security groups are the flat locks, guarding each server.

Watch it happen

A typical VPC layout

VPC 10.0.0.0/16

Public subnet

Private subnet

Load balancer

NAT gateway

App servers

Database

1/5The VPC is your private address space. Nothing gets in or out unless routes and rules allow it.

The big ideas

What you need to know

Security groups are stateful

Allow inbound on a port and the reply is allowed back out automatically. They only have allow rules.

NACLs are stateless

Subnet-level rules checked in both directions, with allow and deny. Useful as a coarse second layer.

Private by default

Put servers and databases in private subnets. Only load balancers and NAT gateways belong in public ones.

Reference groups, not IPs

Let the database allow 'the app security group', not a list of IPs that change whenever servers scale.

See it in code

Walk through the code

hcl

1resource "aws_security_group" "db" {2  name   = "db-sg"3  vpc_id = aws_vpc.main.id4 5  ingress {6    description     = "Postgres from app servers only"7    from_port       = 54328    to_port         = 54329    protocol        = "tcp"10    security_groups = [aws_security_group.app.id]11  }12}

1/3A security group for the database, inside your VPC.

This assumes an aws_vpc.main and an aws_security_group.app defined elsewhere. Newer provider versions also offer separate ingress rule resources.

Save yourself the pain

Common mistakes

Oops

Opening SSH (port 22) to 0.0.0.0/0 so you can log in from anywhere.

Do this instead

Use AWS Systems Manager Session Manager, or allow only your own IP. Open SSH ports get brute-forced constantly.

Oops

Giving the database a public IP 'just for debugging'.

Do this instead

Keep it private. Reach it through a bastion, Session Manager port forwarding or a VPN.

Your mission

Audit a security group

~30 min

Quick check

An app server's security group allows inbound 443. Do you need an outbound rule for the reply to reach the user?

Go deeper

1Design a basic VPC architecture with public and private subnets for a hypothetical application.
2Configure security groups to allow only necessary traffic to each resource.
3Learn the difference between security groups (stateful, instance-level) and network ACLs (stateless, subnet-level).