You add a todo · Lambda + DynamoDB

Your browser sends POST /todos over HTTPS.

POST /todos HTTP/1.1
Host: abc123.execute-api.us-east-1.amazonaws.com
Cookie: session=eyJ1c2VySWQiOiJ1LTEyMyJ9.Zm9v
Content-Type: application/json

{"title":"Buy milk"}

The request arrives at API Gateway, a managed HTTPS front door. There's no server or firewall for you to look after.

API Gateway invokes your Lambda function and hands it the request as an event.

• 🔑IAM Lambda resource policy: API Gateway may invoke todo-apiAllowed

{
  "Effect": "Allow",
  "Principal": {
    "Service": "apigateway.amazonaws.com"
  },
  "Action": "lambda:InvokeFunction",
  "Resource": "arn:aws:lambda:us-east-1:111122223333:function:todo-api",
  "Condition": {
    "ArnLike": {
      "AWS:SourceArn": "arn:aws:execute-api:us-east-1:111122223333:abc123/*"
    }
  }
}

Exam tipThis is a resource-based policy. It lives on the function and says who may call it, the opposite of a policy attached to a role.

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 execution role) which Lambda already put in its environment variables. No keys are stored in the code.

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

Exam tipEvery Lambda function has exactly one execution role. Its permissions are everything your code can do in AWS.

The function calls PutItem on the DynamoDB API over HTTPS, signed with those credentials.

{
  "TableName": "Todos",
  "Item": {
    "userId": {
      "S": "u-123"
    },
    "todoId": {
      "S": "42"
    },
    "title": {
      "S": "Buy milk"
    },
    "done": {
      "BOOL": false
    }
  }
}

Exam tipThis function isn't attached to a VPC, so it reaches DynamoDB directly. No VPC, no security groups.

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

• 🔑IAM todo-app-lambda-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 looks up your connection id in the database and posts a message to it through the WebSocket API.

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

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

{"type":"todo.created","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 201 Created, and "Buy milk" appears in your list.

HTTP/1.1 201 Created

Lambda sends what the function printed to CloudWatch Logs, so Todo.io's engineers can see what happened.

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

Exam tipLambda sends whatever your function prints to CloudWatch Logs automatically, as long as the execution role allows logs:PutLogEvents.