How I built this serverless API with the new AWS

A developer used AWS's new agent toolkit to turn a short prompt into a working serverless Python API built on Amazon API Gateway, AWS Lambda, and Amazon DynamoDB. The coding agent proposed an architecture for an atomic GET /counter endpoint, deployed it via a CloudFormation stack in us-east-2, and verified it with test calls returning incrementing values, with the developer approving the plan and confirming the results.

AI coding agents have shortened the path from an idea to working code. The updated AWS experience https://signin.aws.amazon.com/signup?request type=builderId&trk=0a3e63d3-e29a-4c69-b70d-caa08a783f72&sc channel=el is designed to make deployment keep pace. It connects your agent to an AWS project, configures the AWS tools it needs, and handles permissions between the resources it creates. I used that workflow to turn a short prompt into a Python API using Amazon API Gateway, AWS Lambda, and Amazon DynamoDB. The build starts by connecting the agent to AWS and ends with a working endpoint that I call from my terminal. After signing in, I followed the instructions in the Setup Agent Toolkit for AWS dialog and pasted its setup prompt into my coding agent. The agent then: aws login to sign me in, With the agent connected, I described the service I wanted: I specified Python, asked for a stateful response I could test, and told the agent to show me the architecture before deploying. I left the AWS service choices open. Before creating resources, the agent proposed this architecture: The detailed proposal defined GET /counter as an atomic increment of a value stored in DynamoDB. API Gateway would expose the public endpoint, a Python Lambda function would handle each request, and an on-demand DynamoDB table would maintain state across calls. The atomic update would prevent duplicate values during concurrent requests. The plan also included conservative throttling, a least-privilege IAM role for the table update and function logging, CloudWatch log retention, local tests, and deployment through an AWS CloudFormation stack. The agent explicitly said that no AWS resources had been changed and asked me to approve the architecture and public endpoint before continuing. After I approved the plan, the agent deployed the serverless-counter-api CloudFormation stack in us-east-2 . The deployment included: The API was intentionally public for this demo. Anyone with the URL could invoke it and generate usage, so a production API should use authorization appropriate to its callers and data. The agent verified the deployment by calling the endpoint three times. Each call returned HTTP 200 with {"value": 1} , {"value": 2} , and {"value": 3} . A consistent DynamoDB read confirmed that the stored value was 3 . Later, I set API URL to the /prod/counter invoke URL and called it three times in a loop: Those calls returned {"value": 7} , {"value": 8} , and {"value": 9} . The increasing values confirmed that the service was live and maintaining state across requests. I chose what the API should do, reviewed the proposed architecture, and approved the public deployment. The agent handled the tooling setup, implementation, deployment, and first tests. Before wrapping up, I verified the result myself: Lambda updated DynamoDB atomically and returned the new value, the permissions were limited to what the function needed, and GET /counter worked. The agent reported success, but the final call was mine. Try this with a coding agent you already use. Get started here https://signin.aws.amazon.com/signup?request type=builderId&trk=0a3e63d3-e29a-4c69-b70d-caa08a783f72&sc channel=el , then give your agent a small AWS project and ask to see the plan before it deploys anything. You make the calls and check the result. Let the agent handle the setup and get the first version running. Now go build something 😄.