Securing Private AWS Environments with a Bastion Host — The DevOps Gateway Explained

[Sascha]

What is a Bastion Host in AWS?

A Bastion Host (also called a Jump Server) is a special-purpose EC2 instance that acts as a secure entry point (gateway) to your private AWS resources (like EC2 instances in private subnets) that cannot be accessed directly from the Internet.

It’s typically placed in the public subnet of a VPC, while your application and database servers stay in private subnets.

Think of it as:

“A secure door into your private cloud environment.”

Why Do We Need a Bastion Host?

In a secure AWS setup:

You never expose private EC2 instances directly to the internet.

But engineers still need SSH access for maintenance or troubleshooting.

So, instead of opening SSH to everyone, we allow only the bastion host to SSH into private servers.

Benefits:

1. 
   Security:
   Only the bastion host has inbound SSH (port 22) open to the world (or restricted IPs).
   All private EC2s deny direct access from the internet.
   
   
2. 
   Centralized Access Point:
   All SSH activity passes through a single host — easier to monitor & log.
   
   
3. 
   Auditability:
   You can track who accessed what and when using CloudWatch or CloudTrail.
   
   
4. 
   Reduced Attack Surface:
   Only one public IP (bastion) is exposed.
   

How to Configure a Bastion Host (Step-by-Step Practical Example)

Let’s take a real DevOps environment setup example

Step 1: VPC Setup

Create a VPC with:

1 Public Subnet (e.g., 10.0.1.0/24)

1 Private Subnet (e.g., 10.0.2.0/24)

Step 2: Launch Bastion Host

1. 
   Go to EC2 Console → Launch Instance
   
   
2. 
   Select Amazon Linux 2 (or Ubuntu)
   
   
3. 
   Place it in the Public Subnet
   
   
4. 
   Assign a Public IP
   
   
5. 
   Attach a Security Group with:
   

Inbound: SSH (22) allowed only from your office/home IP

Outbound: Allow all traffic (default)

Step 3: Launch Private Instance

1. 
   Launch another EC2 in the Private Subnet
   
   
2. 
   No Public IP
   
   
3. 
   Security Group rules:
   

Allow SSH (22) only from Bastion Host’s security group

Step 4: Connect

Now, you can connect like this:

ssh -i mykey.pem ec2-user@

ssh ec2-user@

Step 5: (Optional) SSH Agent Forwarding

Instead of storing your private key on the bastion, you can forward your local SSH key:

ssh -A ec2-user@
ssh ec2-user@

This ensures credentials stay on your local machine.

Step 6: Enable Logging & Hardening

Enable CloudWatch Logs for session monitoring.

Restrict Bastion access to specific IAM users or roles.

Rotate SSH keys regularly.

Use AWS Systems Manager Session Manager as a modern, keyless alternative.

Practical Understanding Scenario (DevOps View)

Let’s say you manage a 3-tier web app:

Frontend (ALB) in public subnet

App servers in private subnet

DB (RDS) in private subnet

When debugging app servers, you can’t SSH directly into them (no public IPs).
So you:

1. 
   SSH into the bastion host (public subnet).
   
   
2. 
   From there, SSH into app servers or database EC2s in private subnet.
   

This design ensures:

Security (no direct exposure)

Controlled access

Central monitoring

Modern Alternative (Without Bastion Host)

You can replace the bastion host with AWS Systems Manager (SSM) Session Manager, which allows:

Browser-based or CLI-based access.

No SSH ports required.

Fully auditable session logs.

But still, many companies use bastion hosts for flexibility or hybrid setups

Источник:

Пожалуйста Авторизируйтесь или Зарегистрируйтесь для просмотра скрытого текста.