A small township VPC has private-subnet workloads that need occasional outbound internet access. Leadership wants to limit NAT cost while understanding HA trade-offs. Which guidance is most accurate?

Small township workloads in private subnets often need occasional outbound internet access for OS patches, API calls, or package mirrors. A single shared NAT Gateway lowers hourly NAT charges and can reduce complexity for modest environments, which matches leadership's desire to limit NAT cost. The accurate guidance also states the HA trade-off: if that NAT's Availability Zone fails, private-subnet egress in other AZs that depended on it can be impacted. Per-AZ NAT Gateways improve AZ isolation and blast-radius control at higher hourly and often data-processing cost. Architects should document which trade-off the township accepts.

Deploying one NAT Gateway in every AZ plus every Region to minimize hourly charges fails by concept: more NAT Gateways increase hourly spend. Replacing NAT with public IPs on every private-subnet instance undermines private addressing and expands the attack surface. Disabling outbound access and using Snowmobile for every OS patch is absurd for routine patch egress—Snowmobile is an exabyte-scale migration service.

Exam caveat: "single NAT to save money" is valid for small or non-critical egress patterns; regulated or highly available citizen services often justify per-AZ NAT. Also consider VPC endpoints for AWS APIs to reduce NAT dependence entirely for S3/DynamoDB and other supported services.

Operational check: inventory outbound destinations, add Gateway/Interface endpoints for heavy AWS API traffic, choose single versus per-AZ NAT based on RTO for patch/egress dependency, tag NAT resources for chargeback, and review NAT Gateway Hours and Bytes in Cost Explorer after a month of township traffic.