Deploy a Containerized Application on AWS ECS Fargate

Deploy an immutable container through ECR to an ECS Fargate service with health checks, least-privilege IAM and rollback. This guide treats the change as an operational procedure that must be verified, monitored and reversible.

Scope and assumptions#

Use a production-style test environment. Replace all placeholders and rehearse state-changing commands before production.

Prerequisites#

• AWS CLI, Docker and a test AWS environment
• A current backup or documented rollback point
• Access to logs, health checks and monitoring

Define the safe outcome#

Record expected behavior, acceptable interruption and rollback signals. Capture a baseline so the result is measured rather than guessed.

Implement the change#

aws ecr get-login-password --region YOUR_REGION | docker login --username AWS --password-stdin YOUR_ECR_HOST

docker build -t app:GIT_SHA .
docker tag app:GIT_SHA YOUR_ECR_URI:GIT_SHA
docker push YOUR_ECR_URI:GIT_SHA

aws ecs update-service --cluster production --service app --force-new-deployment

Keep credentials outside source control and use the smallest permissions required.

Verify before real traffic#

Confirm new tasks become healthy, old tasks drain, logs reach CloudWatch and the previous image can be restored.

Check the user-visible path and its dependencies. A running process is not proof of a healthy system.

Failure modes to test#

• The new process never becomes ready.
• A dependency is slow or unavailable.
• Two operations run concurrently.
• Rollback is required after traffic or data moves.
• Logs leak sensitive data or lack request context.

Rollback plan#

Preserve the previous artifact or configuration. Keep schema changes backward compatible and document the exact restoration command or traffic switch.

Monitoring and alerting#

Monitor latency, errors, saturation and the domain outcome affected by the change. Every alert should point to an actionable runbook.

Security considerations#

• Use encrypted transport and least-privilege identities.
• Never log passwords, tokens or complete private payloads.
• Allow-list client-controlled options.
• Patch runtimes and dependencies on a documented schedule.

Common problems#

It works manually but not as a service#

Compare user, working directory, environment, network access and filesystem permissions.

The change cannot be reversed#

Split incompatible work into expand, migrate and contract phases.

Health checks pass while users see errors#

Add readiness checks for critical dependencies and synthetic checks for the complete external path.

Production checklist#

• Configuration reviewed and versioned
• Secrets supplied through the approved store
• Rollback artifact verified
• Health checks passing
• Dashboards open during rollout
• Rollback owner identified

Conclusion#

The work is complete only when behavior is measured, failure paths are understood and rollback remains available. Record the final state in the runbook.