A NAT Gateway solves this by providing outbound internet access without exposing the private instance directly to the internet.

What it does

A NAT Gateway sits in the public subnet. Private instances send their outbound requests to the NAT Gateway, which forwards the traffic to the internet and returns the responses to the originating instance. External systems cannot initiate unsolicited inbound connections through the NAT Gateway— only your instance can start one going out.

How to set it up

1. Use a VPC with a public subnet and a private subnet.

2. Allocate an Elastic IP.

3. Create a NAT Gateway in the public subnet and attach the Elastic IP to it.

4. In the private subnet’s route table, add a route: 0.0.0.0/0 → NAT Gateway.

5. Test from the private instance with curl or your distribution's package manager, such as dnf or yum.

Resources in this architecture

• 1 VPC

• Public subnet + private subnet

• 1 NAT Gateway

• 1 Internet Gateway

• 1 Elastic IP

• 2 route tables

• EC2 in the private subnet

Traffic flow

Private EC2 → private route table → NAT Gateway → Internet Gateway → Internet.

A few things worth knowing

A NAT Gateway is a common AWS pattern for providing outbound internet access to resources in private subnets without exposing them directly to the internet.

It does cost money — an hourly rate plus a per-GB charge for data passing through it. For AWS services such as S3, a VPC endpoint can be more cost-effective than routing the traffic through a NAT Gateway.

Next: Day 3 — Multi-AZ High Availability VPC.

Let me tell you a scenario.

You’ve just set up your first EC2 instance on AWS. It’s running your application. You gave it a public IP because — So you can SSH into it. Then you set up a database on another EC2. Same thing. Public IP.

And now in similar way you’ve got five servers, all publicly reachable, all sitting there on the open internet with port 22 exposed, waiting.

That’s the moment a Bastion Host starts making a lot of sense.

What Actually Is a Bastion Host?

A Bastion Host — also called a Jump Server — is a single, hardened EC2 instance that sits in your public subnet and acts as the only SSH entry point into everything else. Your other servers live in a private subnet. No public IPs. Not visible to the internet at all. You want to get into them? You go through the Bastion. That’s it. That’s the whole idea.

The term “bastion” comes from military architecture. It’s the protruding part of a fortification specifically designed to defend the main walls. One strong point. Everything behind it is protected.

AWS brought this concept into the cloud era, and for years, it’s been a go-to solution for DevOps engineers. While modern tools are starting to change how we handle remote access, the bastion host remains a essential mental model for understanding secure networking.

How to Build One — For Real

Here’s the actual sequence.

Step 1: Create a VPC

Create a VPC with a private CIDR block (e.g., 10.0.0.0/16). Your VPC is your private network in the cloud. Think of it as your own fenced piece of AWS real estate. Inside this VPC, you'll have to create two subnets.

Step 2: Create a Public Subnet and a Private Subnet

Public subnet: something like 10.0.1.0/24. This is where your Bastion lives.

Private subnet: something like 10.0.2.0/24. This is where your actual application or database servers live. Nothing here will ever be directly reachable from outside.

Step 3: Attach an Internet Gateway

Without this, nothing in your VPC can talk to the internet — not even your Bastion. Create an Internet Gateway (IGW) and attach it to your VPC.

Then update the public subnet’s route table to add a route: 0.0.0.0/0 → IGW. This tells AWS: "Any traffic heading out to the internet from this subnet? Send it through the gateway."

The private subnet’s route table gets no such route. That’s intentional. Private means private.

Step 4: Launch the Bastion (EC2 #1)

Put it in the public subnet. Enable auto-assign public IP. Use Amazon Linux 2 or Ubuntu — keep it minimal. No web server, no application, no extra packages. Less software means fewer vulnerabilities.

Security Group for the Bastion: allow SSH (port 22) from your IP only. Not 0.0.0.0/0. Not your office's entire range if you can help it. Your specific IP. Something like 203.0.113.42/32. Yes, this will break if your IP changes. That's a trade-off you accept for a tighter perimeter.

Step 5: Launch the Private Server (EC2 #2)

Put it in the private subnet. No public IP — uncheck that option. This machine gets a private IP only, like 10.0.2.15.

Security Group for the private server: allow SSH (port 22) from the Bastion’s security group ID only. This is neater than using the Bastion’s IP, because if you ever swap the Bastion instance, you don’t have to update this rule.

Step 6: SSH In

From your laptop:

• SSH into the Bastion

ssh -i "my-key.pem" ec2-user@<BASTION_PUBLIC_IP>

• Then, SSH into the private instance

ssh -i "my-key.pem" ec2-user@<PRIVATE_INSTANCE_IP>

You’re now on the private server. Two hops. That’s what “jump server” means.

One practical note: if you don’t want your private key sitting on the Bastion (you shouldn’t), look up SSH Agent Forwarding (ssh -A). It lets you authenticate to the private server using the key on your local machine, forwarded through the Bastion. Cleaner and more secure.

What You’ve Actually Built

• 1 VPC

• 1 Public Subnet + 1 Private Subnet

• 2 Route Tables (one with internet access, one without)

• 1 Internet Gateway

• 2 Security Groups (one strict, one stricter)

• 2 EC2 instances

The traffic flow is simple:

That arrow between Your Laptop and the Bastion? It crosses the public internet. That arrow between the Bastion and the Private EC2? It never leaves your VPC. Completely internal.

Why This Matters Beyond the Lab

While the manual bastion host is a classic, it is not the only way to manage secure access today. Many organizations have migrated to AWS Systems Manager (SSM) Session Manager. This service allows you to connect to private instances directly through the AWS API.

Session Manager is generally preferred because:

• No Inbound Ports: You do not need to open port 22 (SSH) in your security groups.

• No Key Management: You no longer need to manage and distribute SSH keys across your team.

• Granular Control: Access is managed through AWS IAM policies, allowing you to audit exactly who accessed which server and when.

However, the manual process remains relevant. Building a bastion host manually forces you to confront the fundamentals: VPC segmentation, route table configurations, and security group chaining. These are not just “bastion tasks” — they are the core building blocks of cloud networking.

If you don’t understand how to manually secure a network, you won’t fully grasp the security posture that tools like Session Manager provide. Master the manual architecture first; it provides the mental model you will rely on for the rest of your career, regardless of which tools you choose to deploy.