TechOps Examples

Hey — It's Govardhana MK 👋

Welcome to another technical edition.

Every Tuesday – You’ll receive a free edition with a byte-size use case, remote job opportunities, top news, tools, and articles.

Every Thursday and Saturday – You’ll receive a special edition with a deep dive use case, remote job opportunities and articles.

Upgrade your AI knowledge with The CODE! Dive into a newsletter trusted by 200,000+ readers for its comprehensive, 5-minute snapshot of everything happening in AI. We navigate through hundreds of sources to bring you the latest AI trends, tools, and resources—so you can stay ahead, absolutely free.

Powered by: Jobsurface.com

Browse 648 Worldwide Jobs Here →

If you’re not a subscriber, here’s what you missed last week.

How Kubernetes Admission Control Works Behind the Scenes

Helm Guide for DevOps Engineers in Kubernetes

To receive all the full articles and support TechOps Examples, consider subscribing:

One-time 25% OFF on all annual plans of memberships. Closes Soon.

ForgeMT - Secure, scalable GitHub Actions runner platform for ephemeral workloads.

Designed for multi-tenant environments, it automates isolated runner provisioning on Kubernetes or EC2, with built-in OIDC, IAM, cost optimization, and deep observability.

Every AWS workload that needs to talk to the internet or receive traffic from it passes through one of two components: an Internet Gateway or a NAT Gateway. They look similar on the surface. Both sit at the edge of a VPC. Both touch the internet. But they solve fundamentally different problems, and using the wrong one is one of the most common and consequential VPC design mistakes teams make.

Understanding the difference is not just an exam question. It is the foundation of every AWS network security decision you will ever make.

A Virtual Private Cloud is your private, isolated network inside AWS. When you create a VPC, you define a CIDR block like 10.0.0.0/16, and AWS carves out that address space exclusively for you. Nothing enters or leaves that network unless you explicitly configure it to.

Inside a VPC, you create subnets, which are subdivisions of your address space tied to specific Availability Zones. A subnet becomes public or private based entirely on its route table and whether it has a path to an Internet Gateway. Those terms are not inherent properties of the subnet itself. They describe its routing configuration.

Every subnet has a route table that controls where traffic goes based on its destination address. It also has a Network ACL (NACL) sitting at the subnet boundary, which is a stateless firewall that filters traffic in and out of the subnet. Inside each subnet, individual resources like EC2 instances have Security Groups, which are stateful firewalls operating at the instance level.

This layered model matters because the Internet Gateway and NAT Gateway both operate within this routing and security framework.

An Internet Gateway is a horizontally scaled, redundant, highly available VPC component that AWS manages for you. You attach exactly one to a VPC. It does two things.

First, it provides a route target. When you add a route to a subnet's route table pointing 0.0.0.0/0 to the Internet Gateway, that subnet becomes a public subnet. Any resource in that subnet with a public IP address or an Elastic IP can now send and receive traffic from the internet.

Second, it performs NAT for resources with public IPs. When a public EC2 instance with an Elastic IP sends traffic to the internet, the Internet Gateway translates the private IP in the packet to the Elastic IP. When a response comes back, it translates the Elastic IP back to the private IP and delivers it. This 1-to-1 NAT is transparent to the instance.

The defining characteristic of an Internet Gateway is bidirectionality. Traffic can flow in both directions. The internet can initiate a connection to your EC2 instance, and your EC2 instance can initiate a connection to the internet. This makes it suitable for anything that needs to be publicly reachable: web servers, load balancers, bastion hosts, and public-facing APIs.

The route table entry 0.0.0.0/0 → igw-xxxxx is what makes a subnet public. Without that entry, even an EC2 instance with a public IP has no path to the internet, because the router does not know where to send the packet.

A NAT Gateway is a managed AWS service that lives in a public subnet and provides outbound-only internet access for resources in private subnets. It is assigned an Elastic IP, which is the public address the internet sees when private resources make outbound calls.

The mechanics work like this. A private EC2 instance has a route table entry pointing 0.0.0.0/0 to the NAT Gateway. When the instance makes an outbound request, such as pulling a package update from the internet, the packet travels from the private subnet to the NAT Gateway in the public subnet. The NAT Gateway rewrites the source IP from the instance's private IP to its own Elastic IP and forwards the packet to the Internet Gateway, which sends it to the internet. When the response comes back, the NAT Gateway translates the destination back to the private IP and delivers it to the instance.

The critical property here is that this translation is not reversible from the outside. The internet sees only the NAT Gateway's Elastic IP. There is no way for an external actor to initiate a connection to a private EC2 instance through the NAT Gateway because no mapping exists until the private instance creates one by initiating the connection first. This is the security guarantee that makes private subnets genuinely private.

The NAT Gateway itself does not terminate traffic or inspect it. It is purely a network address translation device. It also does not require you to manage its availability or scaling. AWS handles that.

This is the point that needs to be stated clearly, because confusing these two components leads to either exposed resources or broken connectivity.

With an Internet Gateway and a public subnet, the internet can initiate a connection to your resource, and your resource can initiate a connection to the internet. The Security Group on the instance is your primary defense against unwanted inbound connections. If you open port 22 to 0.0.0.0/0, anyone on the internet can attempt to reach your instance.

With a NAT Gateway and a private subnet, your resource can initiate a connection to the internet, but the internet cannot initiate a connection back to your resource. There is no public IP. There is no entry point. Even if a Security Group had a rule permitting inbound connections, the packet would never arrive because there is no route for it to follow.

This asymmetry is the entire point of the design. It lets you run backend infrastructure like databases, application servers, Kubernetes worker nodes, and internal services without exposing them to the internet, while still giving those resources the outbound access they need to download software updates, call external APIs, or send logs to a cloud service.

Use an Internet Gateway when the resource must be reachable from the internet. Public-facing load balancers, web servers handling direct traffic, bastion hosts you SSH into, and NAT Gateways themselves (they must be in a public subnet with IGW access) all belong in a public subnet behind an Internet Gateway.

Use a NAT Gateway when a private resource needs outbound internet access but must not be reachable from the internet. Application servers that call third-party APIs, database instances running yum update, EKS worker nodes pulling container images, Lambda functions in a VPC reaching external services, and any backend service following a three-tier architecture model all belong in a private subnet with a route to a NAT Gateway.

If a resource needs neither inbound nor outbound internet access, it needs neither. Databases and internal caches that only communicate with other resources inside the VPC can omit both. The private subnet with local routing only is the most secure configuration possible.

🔴 Get my DevOps & Kubernetes ebooks! (free for Premium Club and Personal Tier newsletter subscribers)

Looking to promote your company, product, service, or event to 55,000+ DevOps and Cloud Professionals? Let's work together.