DEV Community

Cover image for Building Production-Ready AWS Three-Tier Architecture with Terraform and GitOps
Renato Mendoza
Renato Mendoza

Posted on

Building Production-Ready AWS Three-Tier Architecture with Terraform and GitOps

Modern web applications demand scalable, secure, and maintainable infrastructure. This project demonstrates how to deploy a complete three-tier architecture on AWS using Terraform with professional CI/CD workflows.

What You'll Build

A production-ready architecture featuring:

  • Web Tier: Application Load Balancer with SSL termination and Auto Scaling Groups
  • Application Tier: EC2 instances running PHP web application in private subnets
  • Database Tier: RDS MySQL with Multi-AZ support and encrypted storage

Key Features

πŸ”’ Security First

  • Private subnets for application and database tiers
  • AWS Secrets Manager integration for database credentials
  • OIDC authentication (no long-term AWS keys)
  • Security groups with least-privilege access

πŸš€ GitOps Workflow

  • Environment-specific branches (env/dev, env/staging, env/prod)
  • Automated Terraform validation and planning on PRs
  • Manual approval gates for production deployments
  • Safe destroy workflows with confirmation requirements

πŸ“Š Infrastructure as Code

  • Modular Terraform design for reusability
  • Remote state management with S3 and DynamoDB
  • Environment-specific configurations
  • Comprehensive output values

Project Structure

aws-three-tier-terraform-cicd/ β”œβ”€β”€ .github/workflows/ β”‚ └── terraform.yaml # CI/CD pipeline β”œβ”€β”€ docs/ β”‚ └── MANUAL_WORKFLOWS.md # Manual workflow documentation β”œβ”€β”€ infra/envs/ β”‚ β”œβ”€β”€ dev/ # Development environment config β”‚ β”‚ └── terraform.tfvars # Dev-specific variables β”‚ β”œβ”€β”€ staging/ # Staging environment config β”‚ β”‚ └── terraform.tfvars # Staging-specific variables β”‚ β”œβ”€β”€ prod/ # Production environment config β”‚ β”‚ └── terraform.tfvars # Production-specific variables β”‚ β”œβ”€β”€ main.tf # Main infrastructure configuration β”‚ β”œβ”€β”€ variables.tf # Input variables β”‚ β”œβ”€β”€ locals.tf # Local values β”‚ └── versions.tf # Terraform and provider versions β”œβ”€β”€ modules/ β”‚ β”œβ”€β”€ application/ # Application tier module β”‚ β”‚ β”œβ”€β”€ main.tf # Application module implementation β”‚ β”‚ β”œβ”€β”€ variables.tf # Application module variables β”‚ β”‚ └── outputs.tf # Application module outputs β”‚ └── network/ # Network tier module β”‚ β”œβ”€β”€ main.tf # Network module implementation β”‚ β”œβ”€β”€ variables.tf # Network module variables β”‚ └── outputs.tf # Network module outputs └── scripts/ # Helper scripts 
Enter fullscreen mode Exit fullscreen mode

Quick Start

  1. Fork the repository and configure GitHub secrets:
 DB_PASSWORD # Database password AWS_ROLE_ARN # OIDC role ARN 
Enter fullscreen mode Exit fullscreen mode

For detailed instructions on setting up OIDC authentication and configuring the Terraform backend, see: one-click-aws-terraform-backend-gitops-oidc

  1. Set GitHub variables:
 AWS_REGION # Target AWS region TF_BACKEND_* # Terraform backend config 
Enter fullscreen mode Exit fullscreen mode
  1. Configure environment by copying terraform.tfvars.example:
 region = "us-west-2" env_name = "dev" certificate_arn = "arn:aws:acm:..." domain_name = "yourdomain.com" 
Enter fullscreen mode Exit fullscreen mode
  1. Deploy using GitOps:
    • Create PR to environment branches β†’ Terraform format check, validation, and plan
    • Merge to env/dev β†’ Deploy to development
    • Merge to env/staging β†’ Deploy to staging
    • Merge to env/prod β†’ Deploy to production (with manual approval)

CI/CD Pipeline Highlights

The GitHub Actions workflow provides:

  • Automated Planning: Terraform plans run on every PR with results commented
  • Environment Isolation: Separate workspaces for dev/staging/prod
  • Security Gates: Manual approval required for production changes
  • Safe Destruction: Multi-step confirmation for infrastructure teardown

Database Security

Credentials are handled through multiple security layers:

  1. GitHub Secrets store the master password
  2. AWS Secrets Manager receives the password via CI/CD
  3. IAM Roles allow EC2 instances to retrieve credentials
  4. No Hardcoding - passwords never appear in code or state

Production Considerations

  • Configure DNS manually (project doesn't create Route53 records)
  • Enable VPC Flow Logs for network monitoring
  • Use remote state backend for team collaboration

Why This Approach Works

This architecture pattern provides:

  • Scalability: Auto Scaling Groups handle traffic spikes
  • Security: Multi-layered security with private networking
  • Reliability: Multi-AZ deployment with load balancing
  • Maintainability: Modular Terraform with GitOps workflows
  • Cost Efficiency: Environment-specific scaling configurations

Ready to deploy enterprise-grade infrastructure? Check out the full repository for complete implementation details.


Top comments (0)