- Define the problem that informs the sample app we’ll build.
- Review prerequisites and the essential tools for deploying to AWS.
- Demonstrate a manual (console) deployment to show the moving parts.
- Recreate the same setup with CDKTF (TypeScript) for repeatable, version-controlled deployments.

- Create and deploy the AWS Lambda.
- Create an API Gateway REST API that proxies requests to the Lambda.
- Test the endpoint.
- Create the Lambda function
- Open the AWS Lambda console and create a function (for example,
console-name-picker) using Node.js 20 runtime. - Paste your business logic (the NamePicker handler) into the Lambda function code and deploy.
- random pick from an array, or
- shuffled sequential draw (no repeats until list exhausted).
This implementation uses in-memory state (
shuffledNames and currentIndex) inside the Lambda execution environment. That memory can persist between warm invocations but will be lost on cold starts or when the execution environment is replaced. For durable or shared state across invocations or multiple concurrent instances, store state externally (for example, DynamoDB, S3, or ElastiCache).
- Create an API in API Gateway and connect it to the Lambda
- In API Gateway create a REST API (for example,
console-name). - Create the root resource and add a method such as
ANY. Choose “Lambda Function” as the integration and enable Lambda proxy integration so the Lambda receives the full request data. - Add a proxy resource (
/{proxy+}) to route any path to the Lambda (so requests to/hello,/goodbye, etc. are all handled). - Deploy the API to a stage (for example
dev) and use the invoke URL.





https://0ik9wc8zpj.execute-api.us-east-1.amazonaws.com/dev
Open that in a browser or call it with curl and you should receive a JSON response with a name on each request.
Why the console approach is not ideal:
- Manual steps are error-prone and hard to reproduce.
- Not easily shareable or automatable across teams.
- Difficult to version-control and review infrastructure changes. Use CDKTF to express this architecture as code so it can be committed, reviewed, and redeployed reliably.
Authenticate locally (if needed)
- Create an IAM user with programmatic access (access key + secret) or use an existing role.
- Configure credentials locally:
get-caller-identity returns your expected user or role, CDKTF (using the AWS provider) will pick up those credentials and deploy into that account.
Getting started with CDKTF and the AWS provider
Create a minimal TypeScript CDKTF app that configures the AWS provider and emits a Terraform output to validate the stack:
lambda.amazonaws.com to assume the role. Example CDKTF TypeScript snippet to create a minimal role:
arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole for CloudWatch Logs) or inline policies to grant the Lambda the permissions it needs.
Once the role is created you can confirm it in the IAM console:

- We performed a manual console deployment of a Lambda + API Gateway NamePicker app to illustrate the components and how they interact.
- We validated AWS credentials with
aws sts get-caller-identity. - We created a basic CDKTF app and configured the AWS provider.
- We defined an IAM role for Lambda using CDKTF code.
- Next, we’ll expand the CDKTF stack to provision the Lambda function code package, the Lambda resource, the API Gateway REST API and proxy configuration, the IAM policies, and related outputs — all fully defined as code so Arthur can share and reproduce the environment reliably.

- CDKTF documentation: https://developer.hashicorp.com/terraform/cdktf
- AWS Lambda docs: https://docs.aws.amazon.com/lambda/latest/dg/welcome.html
- Amazon API Gateway docs (REST APIs): https://docs.aws.amazon.com/apigateway/latest/developerguide/rest-api.html
- Terraform AWS provider: https://registry.terraform.io/providers/hashicorp/aws/latest/docs