Deploy a container end to end

Build the image and push it to ECR

Why does this matter before you touch ECS or App Runner? Because every failure mode in the deploy pipeline is silent until runtime — nothing in the toolchain will stop you from shipping the wrong architecture, pushing to a non-existent repo, or authenticating with an expired token. Knowing each hop’s quiet failure mode is what separates a first deploy from a reliable CI pipeline.

ECR (Elastic Container Registry) is AWS’s private Docker registry. Before you can docker push, you authenticate: aws ecr get-login-password mints a short-lived token that you pipe into docker login. Then you tag the local image with the registry’s fully-qualified name and push.

# 1. Authenticate Docker to your private ECR registry (token is valid ~12h)
aws ecr get-login-password --region eu-central-1 \
  | docker login --username AWS \
      --password-stdin 123456789012.dkr.ecr.eu-central-1.amazonaws.com

# 2. Build for the architecture the runtime expects — this is the trap.
#    On an Apple Silicon Mac, --platform is mandatory or you ship arm64 to amd64 Fargate.
docker build --platform linux/amd64 -t myapp:1.0 .

# 3. Tag with the full ECR repo URI, then push
docker tag myapp:1.0 123456789012.dkr.ecr.eu-central-1.amazonaws.com/myapp:1.0
docker push   123456789012.dkr.ecr.eu-central-1.amazonaws.com/myapp:1.0

Two things bite people here. First, the repository must already exist — aws ecr create-repository --repository-name myapp — push does not create it. Second, the architecture: an image is built for a specific CPU, and docker push happily uploads an arm64 image to a repo that an amd64 task will pull. The failure is deferred to runtime as exec format error. Build with an explicit --platform, or use docker buildx to produce a multi-arch manifest, and pick a Fargate runtimePlatform (X86_64 or ARM64) that matches.

Together these four hops form a single failure chain: skip any one of them and the error you get is silent until the container tries to run. The architecture mismatch is the nastiest because it passes every validation step before the kernel refuses the binary.

Route A — ECS on Fargate behind an ALB

Fargate runs your container without you managing servers, but you assemble several objects yourself. The task definition is the blueprint: which image, how much CPU/memory, which port, what roles, where logs go.

{
  "family": "myapp",
  "requiresCompatibilities": ["FARGATE"],
  "networkMode": "awsvpc",
  "cpu": "512",
  "memory": "1024",
  "runtimePlatform": { "cpuArchitecture": "X86_64", "operatingSystemFamily": "LINUX" },
  "executionRoleArn": "arn:aws:iam::123456789012:role/ecsTaskExecutionRole",
  "taskRoleArn":      "arn:aws:iam::123456789012:role/myappTaskRole",
  "containerDefinitions": [
    {
      "name": "myapp",
      "image": "123456789012.dkr.ecr.eu-central-1.amazonaws.com/myapp:1.0",
      "portMappings": [ { "containerPort": 8080, "protocol": "tcp" } ],
      "logConfiguration": {
        "logDriver": "awslogs",
        "options": {
          "awslogs-group": "/ecs/myapp",
          "awslogs-region": "eu-central-1",
          "awslogs-stream-prefix": "myapp"
        }
      }
    }
  ]
}

The two roles are the most-confused part of ECS, and they are not interchangeable:

• Execution role (executionRoleArn) — used by the ECS agent at launch, before your code runs, to pull the image from ECR and write logs to CloudWatch. The AWS-managed AmazonECSTaskExecutionRolePolicy covers exactly this. If it is missing, the task never starts: you see CannotPullContainerError or no log group.
• Task role (taskRoleArn) — the identity your application code assumes at runtime. This is what your SDK calls use to read an S3 bucket, a DynamoDB table, or a secret. Scope it least-privilege to the few actions the app actually needs; it has nothing to do with pulling the image.

Then a service keeps N copies running and ties them to a load balancer:

aws ecs create-service \
  --cluster prod \
  --service-name myapp \
  --task-definition myapp \
  --desired-count 2 \
  --launch-type FARGATE \
  --network-configuration 'awsvpcConfiguration={
      subnets=[subnet-aaa,subnet-bbb],
      securityGroups=[sg-app],
      assignPublicIp=DISABLED }' \
  --load-balancers 'targetGroupArn=arn:...:targetgroup/myapp/abc,
      containerName=myapp,containerPort=8080'

Spread the subnets across two Availability Zones so an AZ outage does not take you fully down. An Application Load Balancer sits in front with a target group whose health check probes a path (e.g. GET /healthz). The ALB only sends traffic to targets that pass, and rolling deploys lean on this: ECS starts new-version tasks, waits for them to pass the health check, registers them, then drains and stops old tasks. A health check that is too strict, too fast, or points at a path your app does not serve will make every deploy roll back — the new tasks “fail,” ECS keeps the old ones, and you wonder why your change never shipped.

Route B — App Runner: the managed shortcut

If you do not need the control of ECS, App Runner collapses most of route A into one service. You point it at the ECR image and it provisions the load balancer, TLS certificate, autoscaling, and a public HTTPS URL for you — no task definition JSON, no target group, no subnets to wire.

aws apprunner create-service \
  --service-name myapp \
  --source-configuration '{
    "ImageRepository": {
      "ImageIdentifier": "123456789012.dkr.ecr.eu-central-1.amazonaws.com/myapp:1.0",
      "ImageRepositoryType": "ECR",
      "ImageConfiguration": { "Port": "8080" }
    },
    "AutoDeploymentsEnabled": true,
    "AuthenticationConfiguration": {
      "AccessRoleArn": "arn:aws:iam::123456789012:role/AppRunnerECRAccessRole"
    }
  }' \
  --health-check-configuration '{ "Protocol": "HTTP", "Path": "/healthz" }'

App Runner still has the same two-identity idea: an access role to pull from ECR (the equivalent of the execution role) and an optional instance role for your app’s own AWS calls (the task role). It still runs a health check. And it still cares about architecture — App Runner runs the image as-is, so an arm64 image will not start. The trade is control for convenience: you give up fine-grained networking, custom load-balancer rules, and per-task placement, and you get a working HTTPS service in one call. Reach for ECS/Fargate when you need VPC integration, sidecars, or precise scaling; reach for App Runner when you just want a container on the internet.