Skip to main content

Building a Secure VPC Architecture on AWS Using Terraform

Updated 6 min readMarkdown

Github repo: https://github.com/HashimZaffar/Asignment-3

When applications move to the cloud, security becomes just as important as availability and scalability. One of the biggest mistakes beginners make is exposing everything to the internet. In real-world cloud environments, sensitive systems are never directly accessible.

In this project, I built a secure VPC architecture on AWS using Terraform, following best practices like private subnets, Bastion Host access, NAT Gateway routing, and restrictive security groups.

This is a portfolio-level DevOps project that demonstrates how secure cloud networking is actually designed in production environments.


Project Objective

The goal of this assignment was to design a secure architecture with:

  • Public and private subnets

  • NAT Gateway for outbound internet access

  • Bastion Host for controlled SSH access

  • Private EC2 instances (not publicly exposed)

  • Restrictive security groups

  • Clearly defined traffic flow

The main idea is simple:

Nothing sensitive should be directly accessible from the internet.


What Problem Are We Solving?

A basic setup might look like this:

Internet → EC2 Instance

This is risky because:

  • Anyone can try to access your server

  • SSH may be exposed

  • Attack surface is large

Instead, we design a secure architecture:

Internet
   ↓
Bastion Host (Public Subnet)
   ↓
Private EC2 Instances (Private Subnets)

Now:

  • Only the Bastion Host is exposed

  • Private servers are hidden

  • Access is controlled


High-Level Architecture

Internet
   ↓
Internet Gateway
   ↓
Public Subnet (Bastion Host)
   ↓
Private Subnets (EC2 Instances)
   ↓
NAT Gateway (Outbound only)
   ↓
Internet

Project Structure

The project follows a modular Terraform design:

Asignment-3/
├── modules/
│   ├── network/
│   ├── security/
│   └── compute/
└── environments/
    └── dev/

This structure is important because:

  • Modules = reusable components

  • Environments = separate configurations

This is how real DevOps teams organize infrastructure code.


Core Concepts Explained (Simple Words)

VPC (Virtual Private Cloud)

A VPC is your private network in AWS.

Think of it like your company’s internal network, but in the cloud.


Public vs Private Subnets

Public Subnet

  • Connected to the internet

  • Resources can have public IPs

In this project:

Bastion Host lives here

Private Subnet

  • Not directly accessible from the internet

  • No public IPs

In this project:

Application EC2 instances live here

Internet Gateway

Internet Gateway connects your VPC to the internet.

Without it, nothing inside the VPC can talk to the outside world.


NAT Gateway

NAT Gateway is one of the most important concepts.

It allows:

Private EC2 → Internet (allowed)
Internet → Private EC2 (blocked)

So private servers can:

  • Install packages

  • Download updates

But cannot be accessed directly from outside.


Bastion Host (Jump Server)

A Bastion Host is a secure entry point.

Instead of connecting directly to private EC2, you do:

Your Laptop → Bastion → Private EC2

This ensures:

  • Only one controlled entry point

  • Better auditing and logging

  • Reduced attack surface


Security Groups (Firewall)

Security groups control traffic.

In this project:

Bastion Host:

Allow SSH only from your IP

Private EC2:

Allow SSH only from Bastion Host

This is called restrictive security design.


Terraform Implementation Overview

This project uses three main modules:

1. Network Module

Creates:

  • VPC

  • Public subnets

  • Private subnets

  • Internet Gateway

  • NAT Gateway

  • Route tables

This defines how traffic flows inside the network.


2. Security Module

Creates:

  • Bastion security group

  • Private EC2 security group

Key idea:

Private EC2 does NOT allow SSH from internet
Only from Bastion

3. Compute Module

Creates:

  • Bastion Host (public)

  • Private EC2 instances

Private EC2 instances:

  • No public IP

  • Fully isolated


Traffic Flow Explained (Most Important Part)

1. Admin Access Flow

Admin Laptop
   ↓ SSH
Bastion Host
   ↓ SSH
Private EC2

Explanation:

  • You cannot directly SSH into private EC2

  • You must go through Bastion


2. Internet Access from Private EC2

Private EC2
   ↓
NAT Gateway
   ↓
Internet

Explanation:

  • Private EC2 can download updates

  • But cannot be accessed from outside


3. Public Internet Access

Internet → Bastion Host only

Explanation:

  • Only Bastion is exposed

  • Everything else is protected


Deployment Steps

Run Terraform:

cd environments/dev

terraform init
terraform fmt -recursive
terraform validate
terraform plan
terraform apply

After deployment, you get:

  • Bastion public IP

  • Private EC2 private IPs


SSH Access

Step 1: Connect to Bastion

ssh -i your-key.pem ubuntu@<bastion-ip>

Step 2: Connect to Private EC2

ssh ubuntu@<private-ip>

Better approach:

ssh -A -i your-key.pem ubuntu@<bastion-ip>

Why This Architecture is Important

This design is used in real-world production systems.

It provides:

  • Isolation of sensitive systems

  • Controlled access

  • Reduced exposure to internet

  • Better compliance and auditing


DevSecOps Thinking

To make this even stronger:

  • Restrict SSH to your IP (not 0.0.0.0/0)

  • Use AWS SSM instead of Bastion

  • Enable VPC flow logs

  • Use IAM roles instead of static credentials

  • Add monitoring and alerting


What This Project Demonstrates

This project proves that you understand:

  • Secure AWS network design

  • Public vs private architecture

  • NAT Gateway usage

  • Bastion Host pattern

  • Terraform modular structure

  • Infrastructure as Code

  • Cloud security basics

This is not a beginner-level project.

This is real-world cloud architecture knowledge.


Conclusion

This assignment shows that cloud infrastructure is not just about launching servers. It is about designing systems that are secure, controlled, and scalable.

By using Terraform, we made the infrastructure:

  • Reproducible

  • Version-controlled

  • Automated

And by using proper AWS architecture, we made it:

  • Secure

  • Isolated

  • Production-ready

In simple words:

We built a cloud network where everything important is protected, and access is tightly controlled, exactly how real systems should be designed.

8 views

No comments yet. Be the first to comment.