Network Tiering and Perimeter Design
Defense in depth across trust tiers
Well-designed clouds look like layers: DMZ, app, data. Each tier has its own subnet, SG/NSG posture and access path, with ingress funneled through load balancers and public exposure minimized.
What you will learn
- Build tiered subnets with escalating security
- Funnel ingress through load balancers and WAF
- Apply micro-segmentation and identity-aware access
Tiering = separate subnets/SGs for edge (LB/WAF), app, and data, each with strictest rules. The perimeter funnels all public ingress through one hardened entry (WAF + LB), and identity-aware (Zero Trust) gates authenticate before routing.
What is this?
Network tiering creates trust domains: edge tier (public-facing LB, WAF), app tier (internal services), data tier (DBs/caches with the strictest rules). Public exposure is minimized — only LB targets are internet-reachable. Defense in depth layers SG/NSG/NACL, WAF, identity-aware proxy. Micro-segmentation isolates per-application network islands; service mesh or a hub enforces. Egress is similarly tiered: only required destinations.
Why do you need it?
- Compromise of a web server shouldn't hand an attacker the database.
- Funneling ingress through a hardened perimeter concentrates where you spend security.
- Tiering makes audit easy: 'why does the DB subnet accept port 5432 from anywhere?'
- Zero Trust (identity-aware) beats 'all inside trusted' endlessly.
Mental model
A bank: lobby, vault room, safe
Network tiers
Clients enter the lobby (edge). Teller desks (app tier) handle requests. The safe (data) has its own room, its own door, its own rules — nobody reaches the safe except with an appointment. Security is layered per room.
How it works
- Edge tier: public subnet with LB + WAF + CDN; only ports 80/443 (or minimal) exposed.
- App tier: private subnet; reached only from edge; SG allows the LB's SG.
- Data tier: private/isolated; reached only from app tier; encrypted at rest; no egress.
- Micro-segmentation: per-team/app subnets + identity-aware proxies (BeyondCorp style) for internal APIs.
- Egress tier: single egress path with allowlists (NAT + IP filter) or endpoint-only where possible.
Tiered perimeter.
In production
- A retail platform: CDN/WAF → ALB in edge subnets → ECS app tier → RDS in isolated subnets, egress only via NAT.
- A bank uses identity-aware proxies in front of internal admin APIs; each service's own micro-segment.
- A healthcare org runs hanging perimeter audits that fail open internet ingress to the data tier.
Best practices
- Only the edge tier gets public exposure; everything else routes through it.
- SG/NSG rules reference other SGs, not bare internet CIDRs.
- Funnel admin traffic through an identity-aware path (bastion or IAP).
- Log and alert on ICMP/port-scan evasion; monitor flow logs for east-west confidence.
Common mistakes
- Opening a service on the app tier 'temporarily' and forgetting.
- Relying on a single perimeter (WAF) without underlying SG posture.
- Allowing DB subnets to reach the internet via the same NAT.
- Equals trusts: all internal traffic implicitly trusted.
Common issues
WAF blocks legitimate trafficOver-aggressive rule set or managed rule
Log-match in WAF, add exceptions carefully, or move to challenge/rate-limit rules.
App tier reaches internet egress unintentionallyShared NAT across tiers
Segregate NAT or endpoints per tier and enforce egress allowlists.
Debugging tips
- Use flow logs to red-team/verify your own assumptions about east-west traffic.
- For a dropped connection, step tier by tier with reachability analyzer.
- A host in the data tier phoning home is a red flag — enforce egress allowlists.
- Audit WAF/LB logs for the ingress path; most attacks stop at L3/L7 layers you control.
Interview checkpoint
Quick quiz
What's the safest way to expose a web app tier?