Internet Gateway and NAT Gateway

AWS 030

Two servers can both need internet access, but giving both public IP addresses is often the wrong answer. One may need to accept public traffic; the other may only need to download updates or call an external API. Internet gateways and NAT gateways solve different parts of that problem.

What You Will Learn

• What Is an Internet Gateway?
• What Makes a Subnet Public?
• Public IPv4 Requirement
• What Is a NAT Gateway?
• Public NAT Gateway Placement
• NAT Is Not an Inbound Firewall
• High Availability and NAT
• Private NAT Gateway
• Troubleshooting
• Production architecture
• Practical exercise
• Learning progression

1. What Is an Internet Gateway?

An internet gateway is a VPC component that enables communication between the VPC and the internet. It is attached to the VPC and becomes a route-table target.

2. What Makes a Subnet Public?

A subnet is considered public when its route table has a route to an internet gateway. That route alone does not magically expose every resource; addressing and security controls still matter.

At a Glance

3. Public IPv4 Requirement

For direct IPv4 internet communication, an EC2 resource needs a public IPv4 address or Elastic IP along with correct routing and security configuration.

4. What Is a NAT Gateway?

A NAT gateway lets resources in private subnets initiate connections to destinations outside the VPC without allowing unsolicited inbound internet connections to those private resources.

Example Architecture

Public tier
Internet
   ↕
Internet Gateway
   ↕
Public Subnet
   └── NAT Gateway

Private tier
Private Subnet
   ↓
NAT Gateway
   ↓
Internet Gateway
   ↓
Internet

5. Public NAT Gateway Placement

A public NAT gateway is created in a public subnet and uses an Elastic IP address. Private subnet route tables send internet-bound IPv4 traffic to it.

6. NAT Is Not an Inbound Firewall

NAT does not replace security groups, network ACLs, or application security. It provides address translation and a connectivity path; access still depends on other controls.

7. High Availability and NAT

For resilient multi-AZ architectures, consider the placement and failure implications of NAT gateways. A design that sends all private-subnet traffic through one AZ may create a dependency on that AZ.

8. Private NAT Gateway

AWS also supports private NAT gateways for private connectivity patterns. A private NAT gateway is not an internet gateway replacement and cannot be used to send traffic to the internet through an internet gateway.

9. IPv6 Considerations

IPv6 uses globally unique addresses and has different egress patterns. An egress-only internet gateway can support outbound-only IPv6 communication from instances without allowing unsolicited inbound connections.

10. Cost and Architecture Tradeoffs

NAT gateways have costs, including processing and data transfer considerations. Avoid blindly creating them everywhere; use service-specific private connectivity such as VPC endpoints when it makes architectural and economic sense.

11. Troubleshooting

If private instances cannot reach the internet, verify the private route table points to the NAT gateway, the NAT gateway is in a public subnet, the public subnet route points to the internet gateway, the NAT gateway has the required connectivity, and security controls permit traffic.

12. Common Mistakes

Frequent mistakes include putting NAT gateways in private subnets, forgetting the public route behind the NAT, assuming NAT allows inbound connections, giving every server a public IP, and ignoring NAT cost.

13. Practical Exercise

Build a public load balancer and private application tier. Allow application servers to download a package through NAT without assigning public IP addresses. Then test that the internet cannot initiate a new connection directly to the application server.

14. Learning Progression

Next, connect this knowledge with route tables, security groups, VPC endpoints, load balancers, and DNS. The goal is to understand the entire packet path.

Advantages

• Separates public and private access patterns
• Supports outbound-only private IPv4 access
• Works with layered architectures
• Provides clear network paths

Limitations and Considerations

NAT gateways and data transfer can add cost, and highly available designs may require multiple NAT gateways.

Common Production Mistakes

• Changing several networking settings at once and then losing track of which change fixed or caused the problem.
• Using broad access rules because they are faster during troubleshooting, then forgetting to narrow them.
• Designing for the happy path without considering AZ failure, dependency failure, retries, or partial outages.
• Treating AWS service names as architecture instead of tracing the actual request or traffic flow.
• Skipping documentation of why a route, rule, queue, or subscription exists.

Interview and Architecture Perspective

A strong AWS engineer should be able to explain not only what the service does, but why it was selected, what failure it prevents, what dependency it introduces, and how the system behaves when something goes wrong. For this topic, practice drawing the traffic or message path from source to destination and naming every control point.

Practical Review Checklist

☐ Can you explain the request or traffic path without opening the AWS console?

☐ Can you identify the component that controls routing?

☐ Can you distinguish availability, security, and application-level failures?

☐ Can you explain what happens when a dependency fails?

☐ Can you troubleshoot the issue layer by layer instead of opening everything?

FAQs

Can a NAT gateway accept unsolicited inbound connections?

No. It is designed for outbound connectivity from private resources.

Where should a public NAT gateway be placed?

In a public subnet with a path to an internet gateway.

A NAT Failure That Looks Like an Application Failure

A private EC2 instance cannot install a package during deployment. The deployment script reports a network error, so the team initially blames the package repository. The real problem is that the private subnet's default route points nowhere useful. In another case, the route is correct but the NAT gateway is placed in a subnet that does not have a working internet-gateway path. These failures are frustrating because the application itself may be completely healthy. The fix is to trace the path from the private instance to the NAT gateway, then from the NAT gateway to the internet gateway and destination.

Public Does Not Mean “Less Secure by Definition”

Public infrastructure can be intentionally exposed while still being tightly controlled. The real question is whether a resource needs unsolicited inbound traffic. A public load balancer may need to accept HTTPS from the internet. A database usually does not. A private application server may need outbound access but not inbound internet access. NAT allows that outbound requirement without making the private server a direct internet destination. This distinction helps architects avoid the shortcut of assigning public IP addresses to every component.

Cost and Resilience Decisions

NAT gateways provide managed connectivity, but they are not free. High-volume architectures should consider data-processing charges and whether private service endpoints can keep traffic inside AWS. Resilience also matters: routing every private subnet through one NAT gateway can create a dependency on one Availability Zone. A multi-AZ design can use a NAT gateway strategy aligned with the required failure tolerance and budget. The correct answer is a tradeoff, not a universal rule.

Design Decisions That Matter

The decision between direct internet access, NAT, and private service endpoints should be based on the workload's actual communication requirement. A public-facing load balancer may need direct internet connectivity. A private application server may need outbound package downloads. A backend that only needs S3 may be better served through a VPC endpoint where appropriate. Separating these cases reduces unnecessary exposure and can improve traffic efficiency. NAT should be treated as a controlled egress path, not as a universal answer for every AWS service connection.

Failure Modes and Recovery

NAT incidents are often cross-resource failures. The private subnet route may be correct while the NAT gateway's public subnet route is broken. The NAT gateway may be healthy while the destination is unavailable. A security group or NACL may block the traffic. Recovery therefore requires checking both sides of the NAT path. For multi-AZ systems, also verify that an AZ-local dependency has not turned a local failure into a broader outage. Keep the intended route pattern documented so recovery is based on architecture rather than memory.

Hands-on Practical Lab

Hands-on lab: build a public subnet containing an internet-facing load balancer and a public NAT gateway, plus a private application subnet. Give the private workload no public IPv4 address. Configure the private route table so IPv4 internet traffic goes to the NAT gateway, and configure the public subnet so the NAT gateway has a path through the internet gateway. Test an outbound request from the private workload. Then remove the NAT route and verify that the application loses outbound access while its internal VPC connectivity remains. Restore the route. Next, compare the architecture with a VPC endpoint for a supported AWS service. Ask whether the workload really needs the general internet or only a specific AWS service. This exercise builds an important production habit: provide the narrowest connectivity path that satisfies the requirement. For high-availability practice, create the same pattern across two Availability Zones and reason about what happens if one NAT gateway or AZ becomes unavailable. Document the availability and cost tradeoff before choosing the final design.

Operational Deep Dive

Operational deep dive: private outbound access should be treated as an explicit dependency. An application may require the internet for package installation, third-party APIs, or license validation, but that does not mean the application should be publicly reachable. Trace the egress path from the private subnet to the NAT gateway, from the NAT gateway's public subnet to the internet gateway, and then to the destination. Check the route table at each stage. Also inspect security-group egress and NACL behavior. If the workload only needs an AWS service such as S3, evaluate a private endpoint rather than automatically sending traffic through NAT. For production resilience, document which AZ contains each NAT gateway and which private subnets depend on it. If one AZ fails, know whether traffic should fail over, remain local, or use another egress path. Cost review matters too: high-volume traffic through NAT can become a material operational expense. The best design balances security, availability, simplicity, and cost.

Architecture Review Exercise

A useful architecture review is to classify every outbound dependency as either general internet access, a specific AWS service, another VPC, or an on-premises network. Each category may require a different path. This prevents the common design where every private workload uses NAT for everything. Review the security, availability, and cost of each path, then document the expected route. When an outage occurs, this map gives the on-call engineer a fast way to determine whether the failure is local to the workload or part of the shared egress layer.

Conclusion

AWS Internet Gateway and NAT Gateway: Internet Access Explained is most useful when treated as an engineering concept rather than a service definition. The goal is to understand the problem, the traffic or request flow, the configuration decisions, the failure modes, and the operational tradeoffs. That mindset is what turns AWS documentation knowledge into production-ready cloud skills.

Canonical URL: https://kodestree.com/internet-gateway-and-nat-gateway/