DEV Community

Cover image for 🌐 AWS 145: Private Subnet Internet Access - Implementing NAT Gateways
Hritik Raj
Hritik Raj

Posted on

🌐 AWS 145: Private Subnet Internet Access - Implementing NAT Gateways

#aws #networking #vpc #100daysofcloud

🚀 Bridge to the Cloud: Enabling Secure Outbound Traffic with NAT Gateway

Hey Cloud Architects 👋

AWS Networking

Welcome to Day 45 of the #100DaysOfCloud Challenge!
Today, we are solving a classic networking puzzle. The Nautilus DevOps team has an EC2 instance isolated in a private subnet. It needs to upload data to an S3 bucket, but it has no path to the internet. Our job is to build the "bridge" a NAT Gateway to allow secure, one-way outbound communication.

This task is part of my hands-on practice on the KodeKloud Engineer platform, which is perfect for mastering VPC routing and connectivity.

🎯 Objective

  • Provision a Public Subnet and an Internet Gateway (IGW) for the VPC.
  • Create a Public Route Table to enable external connectivity for the NAT Gateway.
  • Deploy a NAT Gateway with an Elastic IP in the public subnet.
  • Configure the Private Route Table to point all outbound traffic (0.0.0.0/0) to the NAT Gateway.
  • Verify success by checking the S3 bucket nautilus-nat-18582 for the automated upload.

💡 Why Private Subnets Need NAT

A private subnet has no direct route to an Internet Gateway. To allow instances to reach the internet (for patches or S3 uploads) while staying hidden from hackers, we use a NAT (Network Address Translation) Gateway. It acts as a middleman that sends requests on behalf of the private instance.

🔹 Key Concepts

  • Internet Gateway (IGW): The VPC's gate to the public internet.
  • NAT Gateway: Lives in a public subnet and allows private instances to connect to the internet but prevents the internet from initiating a connection with those instances.
  • Elastic IP (EIP): A static, public IPv4 address required by the NAT Gateway so it can be identified on the web.
  • Route Tables: The "GPS" of your VPC that tells packets where to go based on their destination IP.

🛠️ Step-by-Step: Connectivity Workflow

🔹 Phase A: Establishing the Public Infrastructure

For a NAT Gateway to work, it must reside in a subnet that has a direct path to an Internet Gateway.

  • Create Public Subnet: Name it nautilus-pub-subnet within the nautilus-priv-vpc.
  • Internet Gateway: Create a new IGW and attach it to your VPC.
  • Public Route Table: Create nautilus-pub-rt, add a route for 0.0.0.0/0 targeting the Internet Gateway, and associate it with nautilus-pub-subnet.

🔹 Phase B: Deploying the NAT Gateway

Now we set up the translation service that the private subnet will use.

  • Allocate Elastic IP: Request a new EIP from the Amazon pool.
  • Create NAT Gateway: Name it nautilus-natgw, place it in the nautilus-pub-subnet, and associate it with the EIP you just allocated.

🔹 Phase C: Updating the Private Route

This is the "handshake" that connects the private instance to the new gateway.

  • Modify Private RT: Locate the route table associated with nautilus-priv-subnet.
  • Add Route: Add a destination for 0.0.0.0/0 (all internet traffic) and select NAT Gateway as the target, picking the nautilus-natgw you created.

🔹 Phase D: Verification & S3 Check

The EC2 instance has a cron job waiting for this connection.

  • Wait Period: Give the system 2–3 minutes for the NAT Gateway to initialize and the cron job to fire.
  • S3 Validation: Open the S3 console, navigate to bucket nautilus-nat-18582, and verify that the test file has been successfully uploaded.

✅ Verify Success

  • Route Check: The private subnet now has a valid path to the internet via the NAT Gateway.
  • EIP Association: The NAT Gateway is correctly mapped to a static public IP.
  • Data Flow: The presence of the file in S3 confirms that outbound traffic is successfully traversing the VPC.

📝 Key Takeaways

  • 🚀 Public/Private Balance: Always place NAT Gateways in Public subnets; placing them in Private subnets will result in no connectivity.
  • 🛡️ One-Way Traffic: NAT Gateways provide a massive security boost because they don't allow "Inbound" connections from the internet to your servers.
  • 📦 Cost Awareness: NAT Gateways are billed per hour and per GB of data processed; for large S3 transfers, consider using a VPC Endpoint for S3 to save on data costs!

🚫 Common Mistakes

  • Missing IGW: If the Public Subnet doesn't have a route to an Internet Gateway, the NAT Gateway will fail to reach the web.
  • Wrong Subnet Association: Attaching the public route table to the private subnet would make the subnet public, violating security requirements.
  • EIP Requirement: Forgetting to allocate an Elastic IP NAT Gateways cannot function without a static public identity.

🌟 Final Thoughts

Configuring NAT Gateways is a fundamental skill for securing cloud workloads. By mastering this, you ensure your databases and backend servers stay private and protected while still having the ability to communicate with the outside world when necessary.

🌟 Practice Like a Pro

Ready to build your own secure VPC architectures? Practice here:
👉 KodeKloud Engineer - Practice Labs

🔗 Let’s Connect

Top comments (0)