Automate ECS Blue/Green Deployments with GitHub Actions and OIDC

In this build session, I connect the ECS blue/green deployment setup from the previous video with a GitHub Actions CI/CD pipeline using OIDC federation — no AWS access keys. In the last video, we built native ECS blue/green deployments on Fargate with Terraform — dual ALB listeners, a bake period, and zero-downtime traffic shifting. But triggering a deploy meant building the image locally, updating tfvars, and running terraform apply by hand. In this session, a push to main handles everything automatically. 🧱 What We're Building A GitHub Actions pipeline that builds, pushes, and deploys on every push to main: ➜ OIDC federation — short-lived AWS credentials, no stored secrets ➜ Docker image built and pushed to ECR with commit SHA tag ➜ terraform apply triggers the ECS blue/green deployment ➜ services-stable wait confirms deployment completes before pipeline exits ➜ S3 backend for Terraform state with native locking git push → GitHub Actions → OIDC → AWS STS → ECR push → terraform apply → Blue/Green deploy 🔍 What We Covered ✅ S3 backend with use_lockfile for Terraform state in CI ✅ OIDC provider + trust policy scoped to a single repo and branch ✅ GitHub Actions workflow: build, push to ECR, terraform apply ✅ Passing container_image as a -var to Terraform from CI ✅ aws ecs wait services-stable for deployment confirmation ✅ Lifecycle ignore_changes to prevent CI from reverting listener targets ✅ Full cleanup: OIDC role, ECS infra, S3 state bucket 🧩 Why This Matters ➜ No access keys stored in GitHub — OIDC handles auth at runtime ➜ App changes and infra changes flow through the same pipeline ➜ Commit SHA tags give full traceability from Git to running container ➜ Rollback = git revert + push — the pipeline handles the rest ➜ Same blue/green, fully automated Full blog + code walkthrough: https://brainyl.cloud/ecs-blue-green-... — Build with Brainyl