AWS VPC Support
Private subnet cannot reach the internet: a step-by-step fix.
Outbound connectivity from a private subnet depends on several things all being right: route table, NAT gateway, security group, network ACL and DNS. We check them in the order that finds the fault fastest, instead of changing settings at random.
When You Need This
The situations where this work pays for itself.
Signs it is time
- An instance in a private subnet cannot run yum, apt or pip install
- A Lambda in a VPC times out calling an external API
- ECS or EKS tasks cannot pull images
- Connectivity worked until a route or subnet was changed
- A new subnet or VPC does not behave like the old one
What you get
- The root cause and the exact configuration fix
- A Reachability Analyzer path saved for future checks
- Route and NAT settings corrected in infrastructure as code
- A short checklist for new subnets
How we do it
A clear, safe process you can follow along with.
1. Confirm the symptom
We separate a DNS failure from a timeout from a refused connection by testing name resolution and then a TCP connection to a known IP on port 443. Each points to a different layer.
2. Check the subnet's route table
The private subnet needs 0.0.0.0/0 pointing to a NAT gateway. A missing route, or one pointing to a deleted or wrong NAT, is the most common cause. Make sure the subnet is actually associated with the table you edited.
3. Check the NAT gateway itself
The NAT must be in a public subnet whose route table sends 0.0.0.0/0 to an internet gateway, must be in the Available state, and needs an Elastic IP. A NAT in a private subnet cannot work.
4. Check security groups and network ACLs
Security groups are stateful and must allow the outbound traffic. Network ACLs are stateless, so both outbound rules and inbound return traffic on ephemeral ports must be allowed.
5. Check DNS settings
If names fail to resolve, we verify enableDnsSupport and enableDnsHostnames on the VPC, DHCP options and any custom resolver or Route 53 Resolver rules.
6. Prove the path and fix
We run VPC Reachability Analyzer from the source network interface to the destination, read which component blocks the path, correct it and retest. If cost is a concern we also review endpoints that avoid NAT.
Mistakes we help you avoid
Common ways this goes wrong, and what we do instead.
Putting the NAT gateway in a private subnet
It must sit in a subnet routed to an internet gateway.
Editing the wrong route table
A subnet uses the main table unless explicitly associated with another. We confirm the association.
Opening security group inbound to fix outbound
Outbound failures are not fixed by inbound rules. Follow the traffic direction.
One NAT for several AZs without thinking
It works, but an AZ failure takes out egress and adds cross-AZ data charges.
Frequently Asked Questions
Why can't my private EC2 instance reach the internet?
Usually the private subnet has no route to a NAT gateway, or the NAT is misplaced or unhealthy. Security groups, NACLs and DNS settings are the next suspects.
Does a Lambda in a VPC have internet access?
Not by default. Lambda in a VPC needs a NAT gateway route in a private subnet, or VPC endpoints for AWS services. A public subnet does not give Lambda internet access.
Can I avoid NAT for AWS services?
Yes. Gateway endpoints for S3 and DynamoDB are free to use, and interface endpoints cover many other services, which also reduces NAT data processing charges.
Want Help With Private subnet cannot reach the internet: a step-by-step fix?
Schedule an appointment. Tell us about your environment and we will outline the safest, highest-value approach.
Schedule Appointment › No commitment required