A NAT gateway is managed by AWS.
That removes several jobs from my list.
I do not need to:
- patch a NAT appliance
- replace a failed EC2 instance
- maintain forwarding software
- configure an Auto Scaling group
- manage operating-system availability
It does not remove the architectural questions.
I still need to decide:
- whether the gateway is zonal or regional
- which workloads route through it
- what happens when the path is unavailable
- how much cross-zone traffic it creates
- which data genuinely needs NAT
- who pays for the gateway and its traffic
- how the exit is monitored
This article primarily discusses IPv4 egress.
Native outbound IPv6 can use an egress-only internet gateway. When an IPv6-only workload must reach an IPv4 destination, DNS64 and NAT64 can provide that translation through a NAT gateway.
MANAGED SERVICE
AWS operates the gateway
│
▼
ARCHITECTURE
I still choose its scope,
routes, consumers and failure impact
Managed does not mean outside the failure model. It means AWS operates the component while I remain responsible for how dependent the platform becomes on it.
The same applies to the bill.
AWS manages the gateway.
AWS also remembers that it was running.
A zonal NAT gateway belongs to one Availability Zone
A zonal NAT gateway is created in a specific Availability Zone and is implemented with redundancy inside that zone.
That protects it from the failure of one underlying appliance.
It does not make the gateway independent of the Availability Zone containing it.
AWS states that when resources across several Availability Zones share one zonal NAT gateway, an outage affecting the gateway’s zone can remove internet access from resources in the other zones as well. AWS recommends one zonal NAT gateway per active Availability Zone when zone-independent egress is required.
Consider three private application subnets:
AZ A application ─┐
│
AZ B application ─┼──► NAT gateway in AZ A ───► internet
│
AZ C application ─┘
The application may run successfully in all three zones.
Its public IPv4 exit still depends on AZ A.
If AZ A becomes unavailable:
application-a unavailable
NAT gateway-a unavailable
application-b running, but public egress lost
application-c running, but public egress lost
The compute tier is multi-AZ.
The external dependency path is not.
This is how a resilient-looking diagram acquires one very influential hinge.
One NAT gateway per zone narrows the failure domain
The ordinary zone-independent zonal pattern is:
AZ A application ───► NAT A ───► internet
AZ B application ───► NAT B ───► internet
AZ C application ───► NAT C ───► internet
Each private subnet uses a route table whose default route points to the NAT gateway in the same Availability Zone.
A failure in AZ A then affects the AZ A egress path without automatically removing egress from AZ B and AZ C.
This design also avoids sending normal outbound traffic across Availability Zones before it reaches NAT. AWS recommends keeping resources and their NAT gateway in the same zone where practical, both for resilience and to avoid unnecessary cross-zone data-transfer charges.
The resilience improvement has an obvious cost:
ONE NAT GATEWAY
one hourly gateway charge
THREE NAT GATEWAYS
three hourly gateway charges
The correct comparison is not:
one is cheap
three is expensive
It is:
What availability does the workload require?
What outage does one gateway create?
What does that resilience cost?
A production payment path and a temporary development environment may reach different answers.
That is healthy architecture, not inconsistency.
Regional NAT gateways change the shape of the choice
AWS also offers NAT gateways in regional availability mode.
A regional NAT gateway presents one gateway resource and one gateway ID to route tables while providing NAT capacity across several Availability Zones.
Conceptually:
REGIONAL NAT GATEWAY
one gateway identity
│
┌─────────────┼─────────────┐
│ │ │
▼ ▼ ▼
AZ A path AZ B path AZ C path
One identity does not mean one hourly charge.
ONE REGIONAL NAT GATEWAY ID
does not mean
ONE NAT GATEWAY-HOUR
REGIONAL GATEWAY ACTIVE IN 3 AZs
3 hourly AZ charges
+
data processing
+
public IPv4 addresses
+
applicable data transfer
AWS charges for each hour that the regional gateway is provisioned in each Availability Zone.
When a regional gateway contracts and removes support from an unused zone, billing for that zone stops.
Regional NAT gateways support two operating models.
Automatic mode
AWS detects the VPC’s elastic network interface footprint and expands or contracts the gateway’s Availability Zone presence.
AWS manages:
- zonal expansion
- zonal contraction
- public address allocation
- the gateway’s zonal capacity
Automatic expansion can take up to 60 minutes after an elastic network interface first appears in a new zone. During that interval, traffic may be processed through an existing zone.
This detail matters for:
- launching into a previously unused zone
- disaster-recovery automation
- rapid zonal expansion
- ephemeral environments
- same-zone cost assumptions
Automatic expansion follows the VPC’s ENI footprint, not a manually maintained list of NAT-consuming subnets.
A team should therefore monitor which zones the gateway has expanded into and which per-zone hourly charges are active.
Manual mode
In manual mode, the customer chooses and maintains:
- supported Availability Zones
- public addresses
- expansion and contraction timing
Manual mode provides more explicit control.
It also returns some lifecycle work to the platform team.
AUTOMATIC MODE
AWS manages AZ expansion
and public address allocation
MANUAL MODE
customer manages AZ coverage
and addresses explicitly
Regional mode also changes the routing model.
ZONAL NAT
private subnet route
→ NAT in public subnet
→ public-subnet route table
→ internet gateway
REGIONAL NAT
private subnet route
→ regional NAT gateway ID
→ gateway-owned route table
→ internet gateway
A regional NAT gateway is a standalone VPC resource rather than a gateway placed in one public subnet. AWS creates a route table for the gateway and configures its path towards the internet gateway.
This reduces much of the subnet and route-table lifecycle work involved in maintaining one zonal gateway per Availability Zone.
It does not make egress architecture disappear.
A regional gateway remains:
- a shared exit for its consumers
- a metered service
- dependent on correct routes
- constrained by public destination behaviour
- part of the application’s connection and retry model
Regional NAT gateways support public egress. They do not support private NAT. Where private NAT connectivity is required, AWS recommends zonal NAT gateways.
Regional mode simplifies multi-AZ operation.
It does not remove the need to test how the gateway behaves while the VPC is changing shape.
Regional NAT decisions
automatic or manual mode
which AZs are active
how expansion is observed
which public addresses are used
whether 60-minute expansion fits recovery
how per-AZ charges are attributed
whether private NAT is required
Zonal and regional are different operating choices
The choice is no longer simply:
one NAT gateway
or
one NAT gateway per Availability Zone
It now includes:
| Design | Main advantage | Fixed charge shape | Main concern |
|---|---|---|---|
| One shared zonal gateway | Lowest fixed gateway count | One zonal gateway-hour | One Availability Zone becomes the egress dependency |
| Zonal gateway per AZ | Explicit zone isolation and routing | One gateway-hour per deployed gateway | More gateways, routes and hourly charges |
| Regional NAT gateway | Automatic or simplified multi-AZ coverage | One gateway-hour per active Availability Zone | Shared regional service, expansion behaviour and zonal billing |
| Centralised egress | Shared policy, inspection and public addresses | Depends on the egress VPC’s NAT and transit path | Larger organisational blast radius and additional transit costs |
There is therefore no universal nat_gateway_count variable that deserves to be copied into every VPC module.
The correct implementation depends on:
- public or private NAT
- availability requirements
- zone strategy
- expected traffic
- central inspection
- external allow-listing
- cost ownership
The bill has more than one layer
AWS charges for each hour a NAT gateway is available and for every gigabyte it processes.
The practical bill may also include:
- public IPv4 address charges
- cross-AZ data transfer
- Transit Gateway processing
- firewall processing
- internet data transfer
- downstream service charges
EGRESS COST
NAT gateway time
+
NAT data processing
+
public IPv4 addresses
+
cross-zone movement
+
transit or inspection
+
internet transfer
The gateway’s data-processing charge applies to traffic passing through it.
That includes traffic sent through NAT towards an AWS service when a private endpoint could have avoided the path.
AWS specifically recommends considering gateway or interface VPC endpoints for high-volume AWS-service traffic and keeping resources in the same Availability Zone as a zonal NAT gateway where possible.
The cost question is therefore not merely:
How many NAT gateways do we have?
It is also:
Which bytes are we making them process?
Gateway count and processed-byte volume are separate cost dimensions.
Three zonal gateways increase fixed hourly cost but do not inherently increase or reduce the aggregate processing charge for the same traffic.
Endpoints, caching and private routing reduce cost by removing bytes from the NAT path.
The diagram counts resources.
The bill counts journeys.
An unused NAT gateway still has a hobby: invoicing
A NAT gateway does not need to process traffic to incur its hourly charge.
This makes abandoned development environments particularly effective at converting silence into spend.
Possible causes include:
- a VPC was replaced
- route tables moved to another gateway
- a test environment was never destroyed
- VPC endpoints removed most traffic
- a migration left the old gateway behind
- a backup gateway exists but is not documented as such
AWS cost-optimisation services can identify idle or underused NAT gateways and estimate potential savings.
The useful distinction is:
UNUSED
no longer required
STANDBY
intentionally retained for recovery
A standby component may be worth paying for.
An unused component is merely a very punctual subscription to nothing.
Each gateway should therefore have:
- an owner
- an environment
- an availability purpose
- route-table consumers
- a deletion condition
- cost attribution
Centralised egress trades gateway count for shared consequence
In a larger bfstore estate, workload VPCs may send internet-bound traffic through Transit Gateway to an egress VPC in the bfstore-network account.
WORKLOAD VPCs
│
▼
TRANSIT GATEWAY
│
▼
CENTRAL EGRESS VPC
│
├── inspection
├── NAT
└── internet gateway
This can reduce the number of NAT gateways distributed across many spoke VPCs and provide:
- central inspection
- shared public egress addresses
- common logging
- one egress policy boundary
- easier vendor allow-listing
The traffic now incurs Transit Gateway processing in addition to relevant NAT and data-transfer charges. AWS notes that centralised and decentralised designs can have different cost outcomes depending on traffic volume and architecture.
Centralisation also changes the failure domain.
A route error or capacity problem in the central egress service can affect:
- development
- staging
- production
- shared services
- operational tooling
The central egress VPC is therefore not simply where the NAT gateways have been tidied away.
It is a shared platform service.
It needs:
- SLOs
- zonal or regional resilience
- route-change controls
- capacity alarms
- recovery testing
- cost allocation
- a clear owner
Reducing the number of gateways can increase the importance of each remaining gateway.
Endpoints remove traffic from the NAT dependency
Amazon S3 and DynamoDB support gateway VPC endpoints, allowing suitable traffic to avoid a NAT gateway. Gateway endpoints do not require an internet gateway or NAT device.
Many other AWS services support interface endpoints through AWS PrivateLink.
Replacing NAT paths with endpoints can remove:
- NAT data processing
- dependence on the general egress path
- public routing for the selected service
- NAT failure as a dependency for that traffic
It may introduce:
- endpoint routing
- endpoint policy
- endpoint hourly charges
- endpoint data processing
- subnet address consumption
- security groups
- private DNS dependencies
The decision should compare the complete paths.
PATH A
workload
→ NAT
→ internet gateway
→ AWS public endpoint
PATH B
workload
→ VPC endpoint
→ AWS service
A gateway endpoint for substantial S3 traffic is often cost-effective, provided its route-table and endpoint-policy effects are tested.
Deploying three interface endpoints for a service contacted twice a month may not be.
Cost optimisation remains architecture with arithmetic attached.
Failure should be tested at the dependency level
A NAT gateway outage does not affect every workload equally.
A service that needs public egress only for nightly updates may continue serving customers.
A service that calls an external payment provider during checkout may lose a core business capability.
A useful failure exercise therefore asks:
NAT EGRESS UNAVAILABLE
Which requests fail immediately?
Which work queues safely?
Which calls retry?
Which dependencies have private paths?
Which dashboards show the failure?
Which user-facing capability is degraded?
For bfstore:
| Workload action | NAT dependency | Expected behaviour |
|---|---|---|
| Serve catalog data from internal systems | Possibly no | Continue |
| Export telemetry to self-hosted observability | Should use private path | Continue |
| Read from S3 through gateway endpoint | No | Continue |
| Call external payment API | Yes | Fail or queue according to checkout design |
| Pull an uncached public image | Possibly | Deployment may fail |
| Contact external shipping provider | Yes | Retry or delay fulfilment workflow |
This tells me whether NAT egress belongs in:
- the customer-request SLO
- deployment availability
- background-processing reliability
- disaster-recovery plans
The gateway’s health is not the business outcome.
The dependencies behind it are.
The metrics should reveal pressure before failure
AWS publishes NAT gateway metrics through CloudWatch, including:
- bytes and packets processed
- active and established connections
- connection attempts
- port-allocation errors
- idle timeouts
- dropped packets
ErrorPortAllocation indicates that the gateway could not allocate a source port, while IdleTimeoutCount records connections becoming idle after 350 seconds without activity. PacketsDropCount records packets dropped by the gateway.
A practical monitoring set includes:
| Signal | What it may reveal |
|---|---|
ErrorPortAllocation > 0 |
Port exhaustion for one or more popular destinations |
| Dropped-packet percentage above baseline | NAT or VPC service-path trouble |
Rising IdleTimeoutCount |
Clients reusing stale or excessively idle connections |
| Bytes processed | Cost and traffic growth |
| Active connections | Capacity and dependency behaviour |
| Cross-AZ flow evidence | Misaligned zonal routing |
AWS recommends an alarm when ErrorPortAllocation rises above zero.
Dropped packets are more useful as a percentage of packet volume than as an isolated count.
PacketsDropCount
/
(PacketsInFromSource + PacketsInFromDestination)
× 100
A value above the gateway’s normal baseline deserves investigation. AWS documents 0.01% as a level that may indicate a VPC service issue, but the alarm should also reflect traffic volume and historical behaviour.
For a regional NAT gateway, dashboards and alarms should preserve the Availability Zone dimension.
A healthy regional aggregate can hide one zone experiencing unusual connection pressure, packet loss or unexpected traffic.
I would compare:
NAT metrics
with
VPC Flow Logs
application errors
DNS query logs
external API failures
deployment events
A spike in bytes is interesting.
A spike in bytes caused by every EKS node repeatedly pulling the same image is actionable.
My bfstore decision record
For each environment, I would record:
nat_egress:
availability_mode: regional
consumers:
- private-application-subnets
required_destinations:
- payment-provider
- shipping-provider
- approved-public-repositories
bypass_paths:
s3: gateway-endpoint
internal-observability: transit-gateway
aws-apis: approved-interface-endpoints
availability:
business_critical: true
tested_failure: required
cost_owner: bfstore-platform
monitoring:
dimensions:
- NatGatewayId
- AvailabilityZone
signals:
- ErrorPortAllocation
- PacketsDropPercentage
- IdleTimeoutCount
- ActiveConnectionCount
- BytesOutToDestination
A small development environment may instead record:
nat_egress:
availability_mode: zonal
gateway_count: 1
accepted_risk:
- zonal loss removes internet egress
lifecycle:
destroy_with_environment: true
The variation is deliberate.
Production pays for reliability.
Development pays attention to whether it remembered to switch the lights off.
The mental model I am keeping
My earlier model was:
NAT GATEWAY
managed
highly available
therefore finished
The stronger model is:
NAT EGRESS
│
┌───────────────┼───────────────┐
│ │ │
▼ ▼ ▼
AVAILABILITY TRAFFIC COST
│ │ │
zonal or regional what must pass hours and bytes
│ │ │
└───────────────┼───────────────┘
▼
FAILURE DOMAIN
│
┌───────────────┼───────────────┐
│ │ │
▼ ▼ ▼
ONE SUBNET ONE VPC MANY VPCS
│
▼
BUSINESS DEPENDENCY
Availability mode defines the zonal shape of the exit.
Routes define who depends on it.
Endpoints define which traffic can avoid it.
Metrics reveal pressure.
Billing reveals which paths the architecture made expensive.
A NAT gateway is a useful managed service.
It is not a free-floating cloud rune that grants private workloads safe internet access.
Every NAT gateway has an availability shape, a consumer blast radius and a meter attached to the side.
One shared zonal gateway can make a multi-AZ application dependent on one zone.
One gateway per zone narrows failure and multiplies fixed cost.
A regional gateway simplifies multi-AZ operation, but one gateway ID is still billed per active Availability Zone.
Centralised egress can reduce duplicated infrastructure while creating a larger platform dependency.
Endpoints can remove selected traffic from the general exit.
The correct design is the one whose failure and bill both match the workload’s value.
Managed means I do not repair the gateway.
Architecture means I still need to know what breaks when it disappears.
FinOps means I also need to know what happens when it does not.
References and further reading
-
NAT gateway basics Describes zonal redundancy, Availability Zone failure behaviour, capacity and the recommendation to use same-zone gateways for zonal independence.
-
Regional NAT gateways Explains regional availability mode, automatic and manual Availability Zone coverage, expansion timing, routing and supported connectivity modes.
-
Amazon VPC pricing Documents regional per-Availability-Zone gateway-hour billing, data-processing charges and related VPC costs.
-
NAT gateway pricing guidance Documents hourly and per-gigabyte processing charges and recommends same-zone placement and VPC endpoints where appropriate.
-
NAT gateway metrics and dimensions Defines connection, byte, timeout, dropped-packet and port-allocation metrics, including regional Availability Zone dimensions.
-
CloudWatch recommended NAT gateway alarms Includes recommended monitoring for port-allocation errors and dropped packets.
-
Centralised NAT gateway egress Discusses cost and availability trade-offs when shared egress is combined with Transit Gateway and inspection.
-
Gateway VPC endpoints Explains private S3 and DynamoDB connectivity without requiring NAT.
-
Egress-only internet gateways Describes outbound-only native IPv6 internet access.
-
DNS64 and NAT64 Explains how IPv6-only workloads can reach IPv4 destinations through a NAT gateway.