Skip to main content
Welcome back. In the previous module we used the Terraform local provider to build a simple app. In this lesson we’ll use the AWS provider with CDK for Terraform (CDKTF) to deploy resources into Amazon Web Services and manage them as code. What you’ll learn
  • 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.
Use case summary — the NamePicker app Arthur needs a small service to decide who does the washing up each night. The NamePicker app exposes a simple HTTP endpoint. A client calls API Gateway, which invokes a Lambda function. The Lambda returns a randomly selected family member (either a pure random pick or a shuffled sequential draw so names don’t repeat until the list is exhausted). High-level architecture:
A high-level architecture diagram showing an Author (client/developer) sending requests to an API Gateway which forwards them to an AWS Lambda function. Icons depict a person at a computer, a cloud/API gateway, and the AWS Lambda logo with arrows between them.
Manual deployment (console demo) The manual approach is useful to visualize the pieces before automating them with CDKTF. We’ll:
  1. Create and deploy the AWS Lambda.
  2. Create an API Gateway REST API that proxies requests to the Lambda.
  3. Test the endpoint.
  1. 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.
Example NamePicker handler (Node.js). This simple implementation supports two modes:
  • 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).
After deploying, you can test the function in the Lambda console. Example test output:
Once deployed you should see the function in the Lambda console:
A screenshot of the AWS Lambda console showing the function "console-name-picker" with its overview diagram, ARN and execution status. A green banner at the top indicates the function was successfully updated.
  1. 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.
When creating the API, choose Lambda function as the integration and enable Lambda proxy integration:
Screenshot of the AWS API Gateway "Create REST API" console showing the API details form. The "New API" option is selected, the API name field contains "console-name", and a "Create API" button is visible.
A screenshot of the AWS API Gateway "Method details" integration type panel showing options like Lambda function (selected), HTTP, Mock, AWS service, and VPC link. The lower area shows the Lambda proxy toggle and a dropdown to choose a Lambda function/region.
Enable the proxy resource so the Lambda receives any URL path:
A screenshot of the AWS API Gateway console showing the "Create resource" page with a proxy resource enabled (resource path "/", name "{proxy+}") and CORS checked. A green banner at the top confirms a method was successfully created.
After wiring the Lambda integration you may see an integration status message or warning while the console creates permissions and links:
A screenshot of the AWS API Gateway console showing the Resources page for an API with the /{proxy+} ANY method selected, displaying the method → integration flow and an "Undefined integration" warning. The left sidebar shows API navigation items and a green success banner appears at the top.
Deploy the API:
A screenshot of the AWS API Gateway console showing a "Deploy API" dialog. The modal contains a Stage dropdown, a Deployment description text box, and Cancel and Deploy buttons.
After deployment you receive an invoke URL (for example): 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.
Prerequisites Authenticate locally (if needed)
  • Create an IAM user with programmatic access (access key + secret) or use an existing role.
  • Configure credentials locally:
Verify the credentials being used:
Example output:
If 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:
Install the AWS provider for CDKTF (example using yarn):
To deploy:
Deploying the Lambda’s execution role Every Lambda function must assume an IAM role. The role must include an assume role policy that allows lambda.amazonaws.com to assume the role. Example CDKTF TypeScript snippet to create a minimal role:
You will typically attach either managed policies (for example, 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:
A screenshot of the AWS Identity and Access Management (IAM) console showing the role "cdktf-name-picker-api-execution-role." The page displays the role summary (creation date, ARN, max session duration) and the Permissions tab with no attached policies.
Recap
  • 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.
A slide titled "Connecting to AWS – Recap" showing a simple diagram where a rounded "CDKTF App" box points with an arrow to a rounded "AWS Provider" box. (© KodeKloud in the corner.)
References We’ll now expand the CDKTF stack to create the Lambda deployment package, Lambda resource, API Gateway resources, and the necessary IAM policies — all as code so Arthur can share the project and reproduce the setup reliably.

Watch Video