You add a todo · EC2 + DynamoDB

Your browser sends POST /todos over HTTPS.

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

{"title":"Buy milk"}

todo.io points at the instance's public IP, so the request comes in through the VPC's internet gateway. The public IP changes if the instance is stopped and started (an Elastic IP stays put), 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 around the instance allows HTTPS on port 443, so the request reaches the web server.

• 🛡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 instance profile) from the instance metadata service, which lives on the host itself. No keys are stored in the code.

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

Exam tipNever store access keys on an instance. Attach a role through an instance profile; the SDK fetches its credentials from 169.254.169.254.

The app calls PutItem 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",
  "Item": {
    "userId": {
      "S": "u-123"
    },
    "todoId": {
      "S": "42"
    },
    "title": {
      "S": "Buy milk"
    },
    "done": {
      "BOOL": false
    }
  }
}

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

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

• 🔑IAM todo-app-ec2-role: dynamodb:PutItem 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 saved.

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

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

{
  "QueueUrl": "https://sqs.us-east-1.amazonaws.com/111122223333/todo-events",
  "MessageBody": "{\"type\":\"todo.created\",\"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 201 Created, and "Buy milk" appears in your list.

HTTP/1.1 201 Created

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 POST /todos user=u-123 status=201 14ms

Exam tipEC2 doesn't send logs by itself. You install the CloudWatch agent and give the instance role permission to write logs.