Guide to Implementing a 3-Tier Architecture on AWS with Terraform

Most production applications are not single servers anymore. They are split into layers so that each part can scale, fail, and evolve independently. A 3 tier architecture is the most common and proven way to do this.

In this blog, we build a Goal Tracker application using a full 3 tier architecture on AWS, provisioned end to end using Terraform. The stack includes a Node.js frontend, a Go backend, and a PostgreSQL database, all designed for high availability.

---

What Is a 3 Tier Architecture

A 3 tier architecture separates an application into three logical layers.

• Presentation tier
  The frontend that users interact with

• Application tier
  The backend that handles business logic

• Data tier
  The database that stores application data

Each tier is isolated, secured, and scaled independently. Users never talk directly to the database, and the backend is never exposed to the internet.

---

High Level Architecture

Users
  |
  | HTTPS
  v
Public Application Load Balancer
  |
  v
Frontend Auto Scaling Group (Node.js)
  |
  | Internal traffic
  v
Internal Application Load Balancer
  |
  v
Backend Auto Scaling Group (Go)
  |
  v
RDS PostgreSQL (Multi AZ)

This design removes single points of failure and supports traffic growth without manual effort.

---

Components Deployed by Terraform

This Terraform setup provisions the following resources.

• VPC with 8 subnets across 2 Availability Zones

• Public subnets for load balancers and bastion host

• Private subnets for frontend and backend tiers

• Isolated subnets for the database

• Public ALB for internet facing traffic

• Internal ALB for backend communication

• Auto Scaling Groups

  • Frontend: 2 to 4 instances

  • Backend: 2 to 6 instances

• RDS PostgreSQL with optional Multi AZ

• NAT Gateway for outbound internet access

• Bastion host for secure SSH access

• Secrets Manager for credentials

• CloudWatch for logs and monitoring

All of this is defined and managed using Terraform.

---

Application Container Strategy

Both frontend and backend run as Docker containers.

• Frontend
  Node.js application served from EC2 instances

• Backend
  Go based API running behind an internal load balancer

Docker images are built locally and pushed to Docker Hub.

docker build -t yourname/goal-tracker-frontend:latest .
docker push yourname/goal-tracker-frontend:latest

Terraform pulls these images during instance startup using user data scripts.

---

Terraform Configuration

Environment specific values are defined using variables.

region      = "us-east-1"
environment = "dev"
project     = "goal-tracker"

frontend_docker_image = "yourname/goal-tracker-frontend:latest"
backend_docker_image  = "yourname/goal-tracker-backend:latest"

single_nat_gateway = false
db_multi_az        = true

This makes it easy to reuse the same code for dev, staging, and production.

---

Deployment Flow

Infrastructure deployment is fully automated.

terraform init
terraform plan
terraform apply -auto-approve

Deployment takes around 15 to 20 minutes as AWS provisions networking, compute, and database resources.

After deployment, Terraform outputs the application URL and bastion IP.

---

High Availability Design

This architecture achieves high availability through:

• Multi AZ subnets

• Load balancers performing health checks

• Auto Scaling replacing unhealthy instances

• Optional Multi AZ RDS for database failover

• Multiple NAT gateways for network resilience

If one Availability Zone fails, traffic is automatically routed to healthy resources.

---

Updating the Application

To deploy a new version:

1. Build and push updated Docker images

2. Trigger an instance refresh on the Auto Scaling Group

aws autoscaling start-instance-refresh \
  --auto-scaling-group-name dev-goal-tracker-frontend-asg \
  --region us-east-1

This replaces instances gradually without downtime.

---

Observability and Access

Logs are available in CloudWatch.

aws logs tail /aws/ec2/dev-goal-tracker/frontend --follow

SSH access is done securely through the bastion host. Private instances are never exposed to the internet.

---

Cost and Cleanup

This setup balances cost and resilience. You can reduce cost by:

• Using a single NAT gateway

• Disabling Multi AZ for RDS in non prod

To clean up everything:

terraform destroy -auto-approve

---

Final Thoughts

This Goal Tracker project shows how a real world 3 tier architecture is built on AWS using Terraform. It is secure, scalable, and production ready.

More importantly, it mirrors how modern teams design systems in the real world. Clean separation of tiers, infrastructure as code, and automation are no longer optional. They are the baseline.

YouTube : https://youtu.be/9_l_AplELi4?si=UafPx47HIOQgRD2E