Case study · Containers
Automating Container Deployments on Amazon ECS
The customer operates dozens of containerised microservices on Amazon ECS. The architecture was modern, but the way software reached production was not: every release depended on a chain of manual steps carried out by the DevOps team, making deployments slow, fragile, and difficult to reverse. We replaced that process end to end with a fully automated CI/CD pipeline built on AWS managed services, taking the team from hours-long manual releases to safe, automated deployments measured in minutes.
The challenge
Developers pushed code to GitHub, after which the DevOps team pulled the latest code manually, built Docker images locally, and tagged and pushed them to Amazon ECR by hand. Creating a new ECS task definition revision was equally hands-on — editing the task definition JSON, updating the container image URI, registering the revision, and updating ECS services to point at it. Rollback meant manually identifying and reverting to a previous task definition, which extended incidents well beyond what the business could afford.
Each release consumed hours of engineering time and left constant room for human error, while staging and production regularly drifted out of sync. With no controlled traffic shifting or automated health validation, releases carried real downtime risk; without automated testing, bugs reached production regularly. Logs and metrics were scattered across services, and with no consistent record of who deployed what and when, auditability was effectively non-existent. The result was frequent firefighting, delayed feature delivery, and low confidence in the release process.
Our approach
The goal was to eliminate manual intervention entirely between a developer pushing to the main branch and a validated change serving production traffic — while making that path safer than the manual one it replaced. Docker image creation, security scanning, ECS deployment, health validation, monitoring, and rollback all happen automatically, with no human in the loop.
The solution in practice
Standardised containerisation and continuous integration
Dockerfile standards were defined across all services: multi-stage builds to keep images small, non-root container users, and minimal base images using Alpine or distroless variants. Amazon ECR image scanning detects CVEs on push, and lifecycle policies clean up old images automatically. A buildspec file defines each service’s CodeBuild process — image build steps, unit and integration tests, and a tagging strategy combining commit hash and environment tag so every image traces back to the exact commit that produced it. On every push to the GitHub main branch, CodePipeline triggers automatically, CodeBuild builds in a controlled environment and pushes to ECR, and the pipeline fails if high-severity vulnerabilities are detected.
Continuous deployment and blue/green releases
ECS task definitions are parameterised so the image URI is injected dynamically rather than edited by hand, secrets are fetched at runtime from AWS Secrets Manager or SSM Parameter Store, and containers run with read-only root file systems. Services are integrated with Application Load Balancers, using rolling updates for non-critical workloads and blue/green deployments for customer-facing ones. For critical services, two target groups are configured per service and CodeDeploy manages traffic shifting between them, with validation hooks — Lambda functions or ECS tasks — verifying health before traffic moves. Traffic shifts gradually only after validation succeeds, and rollback triggers automatically if health checks fail or error rates cross defined thresholds.
Observability and operations
Logging was centralised with one CloudWatch log group per microservice, replacing the scattered arrangement that had made troubleshooting difficult, and proactive alarms cover CPU, memory, HTTP 5xx errors, and latency. EventBridge notifications push deployment alerts to Slack or email, and CodePipeline history provides a complete audit trail of what was deployed, by whom, and when.
Infrastructure as code
The ECS clusters and services, task definitions, Application Load Balancers and target groups, CodePipeline and CodeBuild resources, ECR repositories, and all IAM roles and permissions were defined using CloudFormation — giving the customer environments that are provisioned consistently and can be recreated reliably, directly addressing the environment drift that had plagued the previous process.
Outcome
- Build-to-deploy time reduced from hours to minutes.
- Zero or near-zero downtime achieved for production deployments.
- Manual errors and environment drift eliminated.
- Rollbacks are now instant and automated, rather than a manual recovery effort.
- Repeatable, auditable, secure, and scalable deployments by design.
Technologies used
- AWS CodePipeline
- AWS CodeBuild
- AWS CodeDeploy
- Amazon ECS
- Amazon ECR
- Application Load Balancer
- AWS CloudFormation
- AWS Secrets Manager
- SSM Parameter Store
- Amazon CloudWatch
- Amazon EventBridge
- AWS Lambda
- IAM
- Docker
- GitHub
Running containers on ECS and still deploying by hand? We automate the path from commit to production, safely.