Design Security Groups for a 3-Tier VPC — UprootSecurity Bootcamp

Reading network controls is one skill; designing them is the one auditors actually trust. In this exercise you'll design the security group rules for a classic three-tier web application — an internet-facing load balancer, private application servers, and a private database — and enforce the least-privilege pattern from the last lesson: each tier accepts traffic only from the tier directly above it, and the database is unreachable from the internet. First work through three scoping decisions, then build the rule set itself.

The architecture

The app runs in a single VPC (10.0.0.0/16) with three tiers, each in its own subnet:

web — an Application Load Balancer in a public subnet, terminating HTTPS from the internet.
app — application servers in a private subnet, listening on port 8080.
data — a PostgreSQL database in a private subnet, listening on port 5432.

The goal: public users reach the load balancer on 443 and nothing else; the app tier accepts traffic only from the load balancer; the database accepts traffic only from the app tier.

Decision 1: How should the app tier accept traffic?

Quick check

The application servers need to receive forwarded requests from the load balancer on port 8080. What is the best way to write the app tier's inbound rule?

Allow 8080 from 0.0.0.0/0 so the load balancer can always reach it

Allow 8080 inbound only from the load balancer's security group (SG-to-SG reference), so only the web tier can reach the app tier and the rule keeps working as instances scale

Allow 8080 from the entire VPC CIDR 10.0.0.0/16

Allow all ports from the load balancer to avoid future permission errors

Decision 2: How should the database accept traffic?

Quick check

The PostgreSQL database should be reachable only by the application servers on 5432. Which rule set is correct?

Allow 5432 from the app tier security group; rely on the private subnet (no internet route) so no internet path exists

Allow 5432 from 0.0.0.0/0 but require a strong database password

Allow 5432 from the load balancer security group so traffic can reach the database faster

Allow 5432 from the web tier and the app tier, to be safe

Decision 3: Do you need an explicit deny for internet-to-database?

Quick check

Security groups are allow-only and deny everything not explicitly permitted. Given that, why might you still document an explicit 'deny internet → database' control, and where does it actually live?

You must add a deny rule to the database security group or the database is exposed

The security group already implicitly denies it (allow-only), so the real enforcement is keeping the database in a private subnet with no internet gateway route; you document the control as "no internet path to data tier" and evidence it with the route table and a config scan

Explicit denies are required on every security group by SOC 2

You should move the database to a public subnet and add a deny rule instead

Build it: the security group rules

Now design the rule set. Add an inbound rule for each tier that should accept traffic, naming the source (a CIDR, or a tier name to mean "that tier's security group"), the destination tier, the port, the protocol, and the action — plus the rationale an auditor reads. Aim for least privilege: each tier accepts only what the tier above it needs to send, and the database has no internet path.

Exercise

~20 min

Design least-privilege security group rules for the 3-tier VPC

Scenario

3-tier web application in VPC 10.0.0.0/16

Design the inbound security group rules so public users reach only the load balancer on 443, the app tier accepts traffic only from the load balancer, and the database accepts traffic only from the app tier. Use a tier name as the source to mean 'that tier's security group'.

VPC CIDR: 10.0.0.0/16
web — Application Load Balancer, public subnet, terminates HTTPS (443)
app — application servers, private subnet, listen on 8080
data — PostgreSQL database, private subnet, listens on 5432
No tier may be reachable from the internet except the load balancer on 443
Private tiers reach the internet outbound only via a NAT gateway

Write 4–8 rules. For each: set the source, destination tier, port range, protocol, and whether to allow or deny, and explain why the rule exists.

Rule 1

Direction

Action

Source

Destination

Port range

Protocol

Rule 2

Direction

Action

Source

Destination

Port range

Protocol

Rule 3

Direction

Action

Source

Destination

Port range

Protocol

Rule 4

Direction

Action

Source

Destination

Port range

Protocol

Tier topology

web

Internet-facing ALB (443)

no rules target this tier

app

Private app servers (8080)

no rules target this tier

data

PostgreSQL (5432)

no rules target this tier

What to carry forward

The whole design is one idea applied three times: each tier accepts traffic only from the tier directly above it, expressed as a security-group-to-security-group reference rather than a wide CIDR. The load balancer is the sole internet-facing surface; the app and data tiers live in private subnets with no inbound internet path. When you review a real VPC, you're checking for exactly the failure modes this exercise designs around — a 0.0.0.0/0 source on a sensitive port, a tier that accepts from the whole VPC CIDR instead of one group, or a database that somehow has a public route. The evidence is the security group configuration, the route tables, and VPC flow logs confirming the traffic actually matches the design.