You tick a todo as done · ECS on Fargate + DynamoDB

Your browser sends PATCH /todos/42 over HTTPS.

PATCH /todos/42 HTTP/1.1
Host: todo.io
Cookie: session=eyJ1c2VySWQiOiJ1LTEyMyJ9.Zm9v
Content-Type: application/json

{"done":true}

todo.io points at the task's public IP, so the request comes in through the VPC's internet gateway. A Fargate task gets a new public IP every time it restarts, so the DNS record has to follow it. In Level 2 todo.io points at a load balancer's DNS name instead, which never changes.

Exam tipA subnet is "public" only because its route table sends 0.0.0.0/0 to an internet gateway. Nothing else makes it public.

The security group on the task's own network card allows HTTPS on port 443, so the request reaches the container.

• 🛡Security group todo-app-sg: TCP 443 from 0.0.0.0/0Allowed

Type    Protocol  Port  Source
HTTPS   TCP       443   0.0.0.0/0

Exam tipThe classic way to do HTTPS is a free AWS Certificate Manager (ACM) certificate on a load balancer or CloudFront (Level 2). Since 2025 ACM can also sell you an exportable certificate to install on the instance or container itself.

The app checks your signed session cookie and finds your user id, u-123. This is the app's own login, not AWS.

The app gets temporary credentials for its IAM role (the task role) from the ECS credentials endpoint inside the task. No keys are stored in the code.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "ecs-tasks.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

Exam tipECS has two roles. The task role is what your code may do. The task execution role is what ECS itself needs to pull the image and ship logs.

The app calls UpdateItem on the DynamoDB API over HTTPS, signed with those credentials. It leaves through the internet gateway because DynamoDB is a public AWS service, not something inside your VPC.

{
  "TableName": "Todos",
  "Key": {
    "userId": {
      "S": "u-123"
    },
    "todoId": {
      "S": "42"
    }
  },
  "UpdateExpression": "SET done = :d",
  "ExpressionAttributeValues": {
    ":d": {
      "BOOL": true
    }
  }
}

Exam tipA VPC gateway endpoint (Level 1) keeps this traffic off the internet, and it costs nothing.

DynamoDB checks with IAM: may todo-app-task-role do dynamodb:UpdateItem here? The policy on the role allows it on the table's ARN.

• 🔑IAM todo-app-task-role: dynamodb:UpdateItem on table/TodosAllowed

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "dynamodb:GetItem",
        "dynamodb:Query",
        "dynamodb:PutItem",
        "dynamodb:UpdateItem",
        "dynamodb:DeleteItem"
      ],
      "Resource": [
        "arn:aws:dynamodb:us-east-1:111122223333:table/Users",
        "arn:aws:dynamodb:us-east-1:111122223333:table/Todos"
      ]
    }
  ]
}

Exam tipIAM starts from deny. A request is only allowed if some policy explicitly allows it and nothing explicitly denies it.

DynamoDB confirms the item changed.

The app sends a message to an SQS queue saying a todo was completed, instead of doing the slow work now.

• 🔑IAM todo-app-task-role: sqs:SendMessage on todo-eventsAllowed

{
  "QueueUrl": "https://sqs.us-east-1.amazonaws.com/111122223333/todo-events",
  "MessageBody": "{\"type\":\"todo.completed\",\"userId\":\"u-123\",\"todoId\":\"42\"}"
}

Exam tipA queue decouples the app from the worker. If the worker is slow or broken, messages simply wait (up to 14 days).

You get 200 OK, and the todo shows a tick.

HTTP/1.1 200 OK

Exam tipSecurity groups are stateful: a reply to an allowed request goes back out automatically. No outbound rule needed for it.

The app's log line goes to CloudWatch Logs so Todo.io's engineers can see what happened. Like SQS, it's a public AWS service, so it leaves through the internet gateway.

2026-10-11T18:42:07Z INFO PATCH /todos/42 user=u-123 status=200 14ms

Exam tipFargate ships container output with the awslogs log driver, using the task execution role.