Private subnets depend on a NAT gateway in another Availability Zone
- Severity
- Low
- Service
- EC2
- Check ID
- NAT_AZ_NOT_REDUNDANT
What this check finds
Private subnets in one Availability Zone route their internet egress through a NAT gateway located in a different AZ. If that other AZ fails, every private subnet depending on its NAT loses outbound connectivity. Deploy a NAT gateway in each AZ that has private subnets and point each AZ's route table at its local NAT.
Passing looks like: NAT gateways are redundant across Availability Zones.
How to fix it
Create a NAT gateway in each Availability Zone that has private subnets, then update that AZ's route table 0.0.0.0/0 route to target the local NAT gateway.
AWS console
VPC → NAT Gateways → Create NAT gateway (in the uncovered AZ's public subnet) → then VPC → Route Tables → edit the private route table for that AZ.
Compliance controls it is evidence for
A failing result counts against these controls in KloudLytics; a passing one is evidence towards them. How compliance mapping works
| Framework | Controls |
|---|---|
| NIST SP 800-53 Rev5 (Moderate) |
|
| NIST Cybersecurity Framework 2.0 |
|
| ISO/IEC 27001:2022 Annex A |
|
Checked on every scan
KloudLytics runs this check each time it scans a connected AWS account, through a read-only role, and lists every affected resource with its region. On Pro and Business a fix is written for the specific resource rather than the general case above. The exact access it needs
More EC2 checks
- HighAccount does not block public sharing of EBS snapshots
- HighAMI is publicly shared
- HighEBS snapshot is public
- HighEC2 instance CPU spiked abnormally — possible compromise or runaway process
- HighEC2 instance has an IAM role with admin privileges
- MediumAccount default for instance metadata does not require IMDSv2
- MediumEBS default encryption is not enabled for this region
- MediumEBS volume is not encrypted at rest