Building a Secure Two-Tier AWS Network Using a Bastion Host

Introduction

As part of my AWS Cloud Engineering learning journey, I built a two-tier network using Amazon Web Services (AWS). The goal was to deploy a public bastion host and a private EC2 instance while restricting SSH access to improve the security of the environment.

A bastion host is a specially configured server that acts as a controlled entry point into a private network. Instead of exposing a private server directly to the internet, an administrator first connects to the bastion host and then uses it to access the private server.

Network Architecture

I completed the lab in the Europe (Ireland) AWS Region (eu-west-1). I created a custom VPC named assessment3-vpc with the IPv4 CIDR block 10.0.0.0/16.

Within the VPC, I created two subnets in the same Availability Zone:

• Public subnet: assessment3-public-subnet, using 10.0.1.0/24.
• Private subnet: assessment3-private-subnet, using 10.0.2.0/24.

I attached an Internet Gateway to the VPC and configured the public route table with a default route (0.0.0.0/0) pointing to the Internet Gateway. I associated this route table with the public subnet.

For the private subnet, I created a separate route table containing only the local VPC route. I did not create a NAT Gateway, in accordance with the lab requirements.

Security Configuration

I created two security groups to control SSH access.

The assessment3-bastion-sg security group allows inbound SSH traffic on TCP port 22 only from my own public IP address. This reduces exposure compared with allowing SSH from anywhere.

The assessment3-private-sg security group allows inbound SSH on port 22 only from the bastion security group. The private EC2 instance has no public IPv4 address, so it cannot be accessed directly through a public IP address.

These rules implement a controlled access path: my computer connects to the bastion, and the bastion provides the route to the private instance.

Connecting to the Private Instance

I created a key pair named bastion-key and stored the private key on my local Linux environment. I set restrictive file permissions on the key and used the SSH agent to load it.

I then used SSH ProxyJump to connect through the bastion to the private EC2 instance. After connecting, I ran commands such as hostname and hostname -I to verify that I had reached the private machine. I captured a screenshot of the successful connection as evidence of the working configuration.

Challenges and Solutions

During instance creation, I encountered a security-group error because I attempted to create a group that already existed in the VPC. I resolved this by selecting the existing security group instead of creating another one.

I also initially had difficulty locating an EC2 instance in the console. After clearing the active filter, I was able to find the running instance.

Finally, I worked through the SSH connection process from my local Linux environment and successfully connected to the private server using ProxyJump. This helped me understand how a bastion host provides controlled access without requiring a public IP address on the private instance.

Conclusion

This lab strengthened my understanding of VPCs, public and private subnets, route tables, Internet Gateways, security groups, SSH keys, and bastion-host access. Most importantly, it demonstrated how network design and restrictive access rules can reduce the attack surface of cloud infrastructure.

The project gave me practical experience building and troubleshooting a secure AWS network rather than relying only on theoretical explanations.