You delete a todo · Lambda + DynamoDB

Your browser sends DELETE /todos/42 over HTTPS.

DELETE /todos/42 HTTP/1.1
Host: abc123.execute-api.us-east-1.amazonaws.com
Cookie: session=eyJ1c2VySWQiOiJ1LTEyMyJ9.Zm9v

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 DeleteItem on the DynamoDB API over HTTPS, signed with those credentials.

{
  "TableName": "Todos",
  "Key": {
    "userId": {
      "S": "u-123"
    },
    "todoId": {
      "S": "42"
    }
  }
}

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

• 🔑IAM todo-app-lambda-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-lambda-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

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

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

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