How should a small team set up CI/CD for Amazon ECS?

What does a good CI/CD pipeline for Amazon ECS look like?

A good CI/CD pipeline for Amazon ECS is short and boring: test, build once, migrate, deploy, verify.

Each stage either passes or stops the release, and nothing reaches production that was not built and tested by the pipeline itself.

Which CI/CD tool should a small team use for Amazon ECS?

For a small team whose code already lives on GitHub, GitHub Actions is usually the simplest CI/CD tool for ECS, because AWS publishes official actions for logging in to ECR, rendering task definitions and deploying to ECS.

AWS's own CodePipeline also works well, and makes more sense if you want everything inside AWS.

Whichever you choose, keep the pipeline definition in your repository, so changes to how you deploy are reviewed like any other code.

How should GitHub Actions authenticate to AWS for ECS deploys?

GitHub Actions should authenticate to AWS with OpenID Connect, which gives each workflow run short-lived credentials from an IAM role instead of storing long-lived AWS access keys as GitHub secrets.

Stored keys can leak and keep working until someone rotates them, so this is worth doing before anything else.

Scope the role to what the deploy needs: pushing to one ECR repository, registering task definitions, running the migration task and updating the ECS service. Restrict the role's trust policy to your repository and, ideally, to the main branch.

What does a GitHub Actions workflow for Amazon ECS look like?

A GitHub Actions workflow for ECS checks out the code, assumes the deploy role with OIDC, builds and pushes the image, renders a new task definition with that image, and deploys it while waiting for the service to stabilise.

The outline below shows the shape; add your own test and migration steps.

name: deploy
on:
  push:
    branches: [main]
permissions:
  id-token: write
  contents: read
jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: arn:aws:iam::123456789012:role/deploy
          aws-region: eu-west-2
      - id: ecr
        uses: aws-actions/amazon-ecr-login@v2
      - name: Build and push
        run: |
          IMAGE=${{ steps.ecr.outputs.registry }}/app:${{ github.sha }}
          docker build -t $IMAGE .
          docker push $IMAGE
          echo "IMAGE=$IMAGE" >> $GITHUB_ENV
      - id: render
        uses: aws-actions/amazon-ecs-render-task-definition@v1
        with:
          task-definition: task-definition.json
          container-name: app
          image: ${{ env.IMAGE }}
      - id: deploy
        uses: aws-actions/amazon-ecs-deploy-task-definition@v2
        with:
          task-definition: ${{ steps.render.outputs.task-definition }}
          service: app
          cluster: production
          wait-for-service-stability: true

The account ID, region and names are placeholders. One step is still missing: checking that the deploy really succeeded, which the next section covers.

How do you make Amazon ECS deployments roll back safely?

Make ECS deployments roll back safely by turning on the deployment circuit breaker with rollback, adding CloudWatch alarms for errors, and failing the pipeline when ECS rolls back.

Without that last step, the deploy action can report success after a rollback, because the service ends up stable on the old version.

The guide to automatic ECS rollback with GitHub Actions shows the extra check step, and what a deployment health check should test covers the load balancer health check that decides whether a new task is healthy. Database migrations need their own care, covered in rolling back ECS after a migration.

Should a small team use rolling or blue/green deployments on Amazon ECS?

Most small teams should start with rolling deployments plus the circuit breaker, and move to blue/green when they want to test a new version before it takes real traffic.

Since July 2025, Amazon ECS has built-in blue/green deployments for services behind a load balancer or Service Connect, with lifecycle hooks for checks, a bake time and rollback without downtime.

Is your Amazon ECS pipeline ready for frequent releases?

Tick each item that is true for your pipeline today.