You delete a todo · ECS on Fargate + DynamoDB

Your browser sends DELETE /todos/42 over HTTPS.

DELETE /todos/42 HTTP/1.1
Host: todo.io
Cookie: session=eyJ1c2VySWQiOiJ1LTEyMyJ9.Zm9v

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 DeleteItem 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"
    }
  }
}

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:DeleteItem here? The policy on the role allows it on the table's ARN.

• 🔑IAM todo-app-task-role: dynamodb:DeleteItem 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 is gone.

The app looks up your connection id in the database and posts a message to it through the WebSocket API.

• 🔑IAM todo-app-task-role: execute-api:ManageConnectionsAllowed

POST /prod/@connections/Ab3xYzEXAMPLE= HTTP/1.1
Host: ws123.execute-api.us-east-1.amazonaws.com

{"type":"todo.deleted","todoId":"42"}

Exam tipYour browser never asked for this. Anything with permission can push to a connection id through the @connections API.

Every Todo.io tab you have open, on any device, shows the change without a refresh.

You get 204 No Content, and the todo disappears.

HTTP/1.1 204 No Content

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 DELETE /todos/42 user=u-123 status=204 14ms

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