During VPC design for a growing municipality, the network team proposes /28 subnets for every application tier to “save” addresses. What IP planning guidance should the solutions architect give for future scale?
Select an answer to reveal the explanation.
Short Explanation
Tiny /28 pockets fill up the week before go-live when load balancers and managed ENIs each take a bite. Plan room to grow—re-IP mid-project is the expensive kind of civic construction.
Full Explanation
During VPC design for a growing municipality, proposing /28 subnets for every application tier to “save” addresses is false economy. Tiny subnets exhaust quickly once you account for load balancers, Lambda ENIs, VPC endpoints, NAT gateways, and fleet growth—AWS also reserves addresses in each subnet—blocking scale just when a civic app becomes popular. Solutions architects should choose CIDR blocks large enough for projected growth of instances, load balancers, and managed ENIs, reserving expansion space rather than optimizing for the smallest possible mask on day one.
Always using /28 because “AWS cannot support larger subnets” is factually wrong; larger subnets are normal and recommended for growth. Ignoring IP planning because Elastic IPs remove all private address constraints confuses a scarce public EIP with private RFC1918 capacity inside subnets. Overlapping the same 10.0.0.0/16 in every VPC creates future peering/Transit Gateway pain and does not eliminate the need for adequate per-subnet sizing.
Exam caveat: plan across AZs—each AZ’s subnet needs its own capacity. IP exhaustion symptoms include failed ENI attachments and scale-out errors, not only “we ran out of EC2.” Secondary CIDRs can help later but are harder than sizing reasonably up front.
Operational check: inventory current and 2–3 year ENI counts per tier; size subnets with headroom; avoid overlapping CIDRs across VPCs that will connect; and test an Auto Scaling surge to ensure new tasks/instances still receive addresses during emergency declaration workloads.