Back to projects

Project

AWS Fargate Lab

Modular IaC + OIDC CI/CD

A personal AWS lab built to validate a reusable pattern for containerized deploys on ECS Fargate, with infrastructure managed through modular Terraform and application deploys handled by GitHub Actions over OIDC.

01

Context

Personal lab created to validate a reusable pattern for containerized deploys on AWS, and to serve as a base for future projects.

02

Goal

Provision a frontend + backend stack on ECS Fargate with modular Infrastructure as Code, controlled cost, and application deploys decoupled from the infrastructure itself.

03

Architecture

Cloudflare DNS
↓Application Load Balancer (host-based routing)
↓ECS Fargate, frontend / backend
↓Security Groups
↓RDS PostgreSQL (private, optional)

Also present: ECR, CloudWatch Logs, IAM, and GitHub Actions with OIDC.

04

What I built

  • • Reusable Terraform module for ECS Fargate
  • • Thin per-project template that references an existing VPC via data sources
  • • Separate infrastructure for frontend and backend services
  • • GitHub Actions pipeline authenticating to AWS through OIDC
  • • Docker image deploys to ECR
  • • ECS service updates without the CI pipeline touching Terraform state directly

05

Terraform approach

  • • Split between a reusable module and a per-project template
  • • count and conditionals for optional features such as RDS and OIDC
  • • lifecycle.ignore_changes where needed to avoid conflicts between Terraform and CI-driven deploys
  • • Consistent tagging through locals
  • • Existing VPC referenced via data sources instead of being managed by this Terraform

06

Deployment workflow

Two separate cycles, infrastructure and application:

Infrastructure

terraform init
→ plan
→ apply

Application

GitHub Actions
→ AWS auth via OIDC
→ Docker multi-arch build
→ push to ECR
→ new task definition
→ update ECS service
→ wait until stable

07

Trade-offs

  • • Single-AZ reduces cost but reduces resilience
  • • RDS without a final snapshot is acceptable for a lab, not for production
  • • ECS tasks can scale to 0 by default to minimize cost when the lab is idle
  • • Tasks with public IPs simplify networking and avoid a NAT Gateway, at the cost of less isolation
  • • Local state is enough for a solo lab, but a team should use remote state with locking
  • • force_delete on ECR and skip_final_snapshot on RDS make destroy cheap and simple, explicitly destructive choices

08

Result

  • • A functional, reusable stack
  • • Infrastructure and application deploys on separate lifecycles
  • • Minimal cost when the lab is not in use

09

Key technologies

  • • Terraform
  • • AWS ECS Fargate
  • • Application Load Balancer
  • • Amazon ECR
  • • RDS PostgreSQL
  • • IAM OIDC
  • • GitHub Actions
  • • CloudWatch
  • • Docker Buildx / QEMU

Type

Infrastructure lab

Scope

AWS ECS Fargate + Terraform

Role

Solo build

Status

Active personal lab

Focus

Modular IaC and OIDC-based CI/CD