🚀 Building a Production-Style AWS 3-Tier Architecture using Terraform

 From zero to a fully automated AWS infrastructure using Infrastructure as Code.

👋 Introduction

In modern cloud environments, manually creating infrastructure is no longer scalable or reliable.
This is where Infrastructure as Code (IaC) plays a critical role.

In this blog, I’ll walk you through how I designed and deployed a production-style AWS 3-Tier Architecture using Terraform, following real-world DevOps practices such as network isolation, secure routing, NAT Gateway usage, and remote state management.

This project is not just for learning — it reflects how infrastructure is built in real companies.

🧱 Architecture flow design




What is a 3-Tier Architecture?

A 3-Tier Architecture separates an application into three logical layers:-

1️⃣ Web Tier (Public)

  • Faces the internet
  • Handles user requests
  • Hosted in a public subnet

2️⃣ Application Tier (Private)

  • Contains business logic
  • Not exposed to the internet
  • Hosted in a private subnet

3️⃣ Database Tier (Private)

  • Stores application data
  • Fully isolated from public access
  • Hosted in a private subnet

This separation improves security, scalability, and maintainability.

Tools & Technologies Used:-

  • Terraform — Infrastructure as Code
  • AWS EC2 — Compute layer
  • AWS VPC — Networking
  • Internet Gateway (IGW) — Public access
  • NAT Gateway — Secure outbound internet for private subnets
  • S3 Backend — Remote Terraform state
  • SSH Key Pair — Secure EC2 access

High-Level Architecture Overview

Here’s what the infrastructure looks like:

  • Custom VPC
  • Public Subnet (Web EC2 + NAT Gateway)
  • Private App Subnet (App EC2)
  • Private DB Subnet (DB EC2)
  • Internet Gateway attached to VPC
  • NAT Gateway in Public Subnet
  • Separate Route Tables for Public & Private subnets
  • Terraform state stored securely in S3

This setup closely mirrors real production architectures.

Why Terraform?

I chose Terraform because:

  • It provides declarative infrastructure
  • Infrastructure can be version-controlled
  • Easy to recreate, modify, and destroy
  • Cloud-agnostic (not AWS-only)
  • Widely used in DevOps teams

Terraform Remote Backend (S3)

Instead of storing terraform.tfstate locally, I configured an S3 remote backend.

Why S3 Backend?

  • Prevents accidental state loss
  • Enables team collaboration
  • Industry-standard best practice

This ensures Terraform state remains secure, consistent, and centralized.

Networking Design

VPC

A custom VPC provides complete network isolation.

Subnets

  • Public Subnet → Web Server + NAT Gateway
  • Private Subnets → App & DB Servers

Internet Gateway

Allows public subnet resources to communicate with the internet.

NAT Gateway (Very Important)

Private EC2 instances cannot access the internet directly.
To allow them to:

  • Download updates
  • Install packages
  • Reach external services

I implemented a NAT Gateway in the public subnet.

Private instances can go out to the internet, but the internet cannot reach them.

This is a key production-level security concept.

Route Tables & Traffic Flow

Public Route Table

  • 0.0.0.0/0 → Internet Gateway

Private Route Table

  • 0.0.0.0/0 → NAT Gateway

Traffic Flow

  • User → Internet → Web EC2
  • Web EC2 → App EC2
  • App EC2 → DB EC2
  • App/DB → Internet via NAT Gateway (outbound only)

EC2 Deployment Strategy

  • Web EC2
  • Public subnet
  • Has public IP
  • Accessible via SSH
  • App EC2
  • Private subnet
  • No public IP
  • DB EC2
  • Private subnet
  • Completely isolated

All EC2 instances are launched using Terraform-managed configuration, ensuring consistency.

Security Considerations

  • SSH access via key pair only
  • No public access to App & DB servers
  • Private subnet isolation
  • Controlled routing via NAT Gateway

Security was treated as a design principle, not an afterthought.

🚀 Deployment Workflow

Here’s how the entire infrastructure is deployed:-

terraform init -reconfigure
terraform validate
terraform plan
terraform apply --auto-approve

Within minutes, the entire AWS infrastructure is ready.

Verification

After deployment, I verified:

  • EC2 instances running successfully


  • NAT Gateway in Available state


  • Correct route table associations



Press enter or click to view image in full siz
  • Terraform outputs showing IP addresses





👤 About Me

Mahesh Shelke
Cloud & DevOps Engineer (Fresher)
Skills: AWS | Terraform | Linux | Git | CI/CD

If you’re learning cloud or DevOps, feel free to connect or fork the project.


















































































MAHIBLOG

Posted by MAHIBLOG