ECS Blue/Green Deployment Platform
A multi-service application platform on AWS ECS Fargate, featuring automated infrastructure, native canary deployments and tested automatic rollback.
Technologies
The project
Overview
I built a multi-service URL shortening platform on Amazon ECS Fargate, with infrastructure provisioned through Terraform and application delivery automated using GitHub Actions.
The platform consists of a React frontend, a FastAPI API, a background worker processing asynchronous click events through Amazon SQS, and an analytics dashboard. PostgreSQL provides persistent storage, while Redis supports caching.
The central engineering focus was deployment reliability: introducing application changes gradually, monitoring their health and automatically recovering when a release fails.
System design
Architecture
Architecture diagram from the project.
The challenge
A deployment pipeline is only reliable if it can detect a faulty release and recover without leaving the application in an unhealthy state.
I needed to combine progressive traffic shifting, meaningful health checks and automatic rollback while maintaining secure CI/CD authentication and reproducible infrastructure.
The platform also required private application networking, controlled access to AWS services and an infrastructure lifecycle that would allow the environment to be recreated without extensive manual configuration.
How the architecture works
Application services
Four independent services provide the frontend, URL shortening API, asynchronous event processing and analytics dashboard. ECS Fargate runs the containerised workloads.
Networking and security
A custom multi-AZ VPC isolates application workloads in private subnets. An internet-facing Application Load Balancer handles ingress, with AWS WAF and ACM protecting the public entry point.
Data and messaging
Amazon RDS for PostgreSQL stores persistent application data, ElastiCache Redis provides caching, and Amazon SQS decouples click-event processing from API requests.
Infrastructure automation
Terraform provisions the networking, compute, databases, messaging, IAM and supporting AWS resources through reusable modules. Remote state is stored in Amazon S3.
Continuous delivery
GitHub Actions builds, scans and publishes container images to Amazon ECR. OIDC provides temporary AWS credentials without storing long-lived access keys.
Deployment reliability
Native ECS canary deployments initially shift 10% of production traffic to a new task revision. CloudWatch deployment alarms support automatic rollback when health checks fail.
Behind the build
Implementation
Designing the application architecture
I separated the platform into independently deployed services rather than placing the entire application inside one container. The API handles URL shortening and redirects, while a worker processes click events asynchronously through SQS.
PostgreSQL provides durable storage, with Redis used for caching. This separation keeps background processing outside the request path and gives each service a clearly defined responsibility.
Provisioning private infrastructure with Terraform
Terraform provisions the custom VPC, ECS services, Application Load Balancer, RDS, ElastiCache, SQS, IAM, WAF and supporting resources across multiple Availability Zones.
Application workloads run in private subnets. I used VPC endpoints instead of NAT Gateways to provide private connectivity to supported AWS services while reducing networking costs.
The infrastructure can be created and destroyed on demand, which was important for controlling the cost of a development environment.
Implementing native ECS canary deployments
I configured native Amazon ECS canary deployments to direct 10% of production traffic to a replacement task revision before promoting the release.
The deployment uses a five-minute bake period, allowing health signals to be evaluated before the remaining traffic is shifted.
CloudWatch deployment alarms are integrated with the release process so an unhealthy revision can trigger automatic rollback to the previous healthy version.
Validating automatic rollback
I tested the recovery mechanism by deliberately modifying the application's /healthz endpoint to return an unhealthy response during deployment.
The new revision entered the canary phase, but its failing ALB health checks caused the associated CloudWatch alarm to enter the ALARM state.
Amazon ECS cancelled the deployment and restored traffic to the previous healthy revision without manual intervention. This verified the rollback behaviour under an intentionally introduced failure.
Securing and automating CI/CD
GitHub Actions automates container builds, vulnerability scanning, image publishing and infrastructure deployment. The container build workflow uses a matrix strategy to build the API, worker and dashboard images.
AWS authentication uses OIDC role assumption instead of static IAM access keys. Configuring the trust relationship required debugging GitHub identity claims and ensuring that AWS accepted only the intended workflow identity.
Trivy scans container images, while pre-commit checks include Gitleaks and Terraform validation. Application containers run as non-root users.
Key takeaways
Deployment reliability needs to be tested through failure, not inferred from successful releases.
A canary rollout reduces exposure to a faulty revision, but its effectiveness depends on the health signals used to evaluate the deployment.
Separating API requests from asynchronous event processing creates clearer service boundaries.
OIDC removes the need for static CI/CD credentials, while IAM trust policies determine which workflows can assume a role.
Infrastructure design involves trade-offs between security, availability, reproducibility and operating cost.
Reflection
What this project taught me
The most valuable part of this project was validating the deployment recovery path. Building the infrastructure and automating releases established the platform; deliberately introducing a failure demonstrated how it behaves when a deployment goes wrong.
Explore the source code