A greenfield VPC design places many private subnets across AZs, each expected to reach AWS APIs and limited internet destinations. NAT Gateway spend projections are high. What networking cost control should architects prioritize?
Select an answer to reveal the explanation.
Short Explanation
Every NAT Gateway is a meter running in the basement—use endpoints for AWS APIs and don’t plant a NAT in every empty closet. Cutting all egress or bouncing APIs through on-prem over the public net isn’t clever thrift.
Full Explanation
Greenfield VPCs with many private subnets often overspend on NAT Gateways when every path assumes public egress for AWS APIs. Preferring VPC endpoints for AWS service traffic and consolidating NAT Gateway placement to real internet egress needs reduces data-processing charges while keeping private subnets operable. Interface and gateway endpoints keep API calls on the Amazon network; NAT remains for true external destinations rather than default hairpins. Deploying a NAT Gateway in every private subnet including empty lab subnets fails by multiplying hourly and processing meters without demand. Disabling all private subnet egress permanently fails conceptually because patching, telemetry, and legitimate external calls cannot proceed—cost control cannot equal total isolation without another approved path. Hairpinning all AWS API calls through an on-premises proxy over the public internet fails on latency, cost, and risk compared with Regional VPC endpoints. Exam caveat: HA designs often place NAT per AZ for zonal independence; consolidation should not create a single NAT that becomes an availability bottleneck—balance thrift with AZ resilience. Operational check: inventory which prefixes need AWS APIs versus true internet, enable the corresponding endpoints, remove unused NAT routes from lab subnets, and compare NAT Gateway cost and packet drops for one sprint before/after.