# Exercise 3 — Designing a Cloud VPC's Subnet Layout (hardest)

## Scenario

You're designing the subnet layout for a new cloud VPC, `10.30.0.0/16`, that must span **2 availability zones** for redundancy, with **3 tiers** in each zone: a public tier (load balancers), a private application tier (app servers), and a private data tier (databases). Public-tier subnets need internet-facing addressing capacity for maybe a dozen load balancer nodes; app tiers need room for up to 200 instances each with headroom for autoscaling; data tiers need room for a handful of database instances only.

## Deliverables

1. **Tier sizing.** For each of the 3 tiers, choose the smallest CIDR prefix that comfortably fits the stated capacity (with at least 20% headroom for the app tier specifically), and justify the choice with the usable-host arithmetic from theory section 5.

2. **Full layout table.** Lay out 6 non-overlapping subnets (3 tiers × 2 AZs) entirely within `10.30.0.0/16`, using a consistent, explainable pattern (e.g. AZ-a gets the first half of the space, AZ-b the second, or some other scheme you name explicitly). Produce a table: Subnet name | CIDR | AZ | Tier | Usable host range.

3. **Routing implications.** State which tiers should have a route to an internet gateway (0.0.0.0/0) and which should not, and explain — using theory section 7's point that inter-subnet traffic always crosses a router where policy is enforced — why keeping the data tier on its own subnet (rather than merging it with the app tier) is a meaningful security boundary, not just an organizational nicety.

4. **Growth scenario.** Six months later, the app tier in AZ-a needs to grow past its subnet's capacity. Given that cloud VPC subnet CIDR blocks generally cannot be resized in place once created, describe one realistic way to handle this that doesn't require re-IPing the entire VPC (e.g. reserved headroom blocks, adding an additional subnet for the same tier/AZ, etc.), and explain why leaving deliberately unused CIDR space during the initial layout (part 2) makes this easier.

## Constraints

- All 6 subnets must fit inside `10.30.0.0/16` with no overlaps — show that they don't overlap.
- State your prefix-length choices as concrete `/N` values, not ranges.