DEV Community: kkkensuke

Automating EC2 Patching with AWS Patch Manager

kkkensuke — Sun, 22 Sep 2024 06:50:40 +0000

As a cloud engineer, managing EC2 patching is critical for security and performance. I’ve developed a solution to automate this process using AWS Patch Manager, encapsulated in this repository: Patch Manager Control.

Key Components:

IAM Roles & Policies: These govern permissions for Patch Manager and Maintenance Window tasks.
SNS Notifications: Used to send patching status updates.
Patch Baseline & Groups: Define the patching rules for Amazon Linux 2 instances.
Maintenance Windows: Scheduled tasks for patch scans and installations using cron expressions, ensuring regular updates without manual intervention.

How It Works:

Patch Baseline: This defines approved patches, installation rules, and compliance levels.
Maintenance Window: The window during which patches are applied, configurable via variables.tf.
Tag-Based Targeting: Instances tagged with a specific PatchGroup are automatically included for patching.

The repository integrates seamlessly into AWS environments using Terraform for infrastructure as code. Simply set up the required variables, apply Terraform, and let AWS take over the heavy lifting of patch management. It includes two primary tasks:

Patch Scanning: Periodically checks instances for missing updates.
Patch Installation: Installs updates based on the predefined schedule.

Repository Structure:

main.tf: Core Terraform configurations for AWS Patch Manager.
variables.tf: Parameterizes the maintenance window schedule and other key details.
outputs.tf: Displays key outputs such as the SNS topic and maintenance window IDs.

Setting Up:

Clone the repository.
Customize the variables.tf file to match your EC2 patching needs (e.g., cron schedule, tags).
Deploy the infrastructure using Terraform.

terraform init
terraform apply

Once deployed, the setup will continuously manage patching without manual oversight, ensuring your instances are always up-to-date with minimal intervention.

Conclusion:

This repository simplifies EC2 patching automation, leveraging AWS native tools and infrastructure-as-code practices. If you’re looking for a robust solution for patch management, this project is designed to save time and reduce operational risk.

Check out the repository here to get started with automating EC2 patching today!

Hosting a Static Site with CloudFront and S3 Using GitHub Actions

kkkensuke — Mon, 16 Sep 2024 08:48:14 +0000

Recently, I worked on a project to host a React application statically using S3 and CloudFront. In this blog, I will explain the architecture and the setup of the CICD pipeline.

Architecture Overview

The architecture I implemented consists of the following components:

S3 Bucket: Hosts the static files of the React application. S3 is ideal for serverless static site hosting.
CloudFront: A CDN (Content Delivery Network) that delivers content from S3 with high performance. It uses edge locations around the world to serve content closer to users, improving performance.
GitHub Actions: Used to build and deploy the React application, automating the CICD pipeline.

Setting Up the CICD Pipeline

The CICD pipeline is built using GitHub Actions. Whenever code is pushed to the repository, the following processes are executed:

Build React App: Build the application using the npm run build command to generate the static files.
Deploy to S3: Upload the built files to S3.
Invalidate CloudFront Cache: Invalidate the CloudFront cache to ensure the new version of the content is served.

GitHub Actions Workflow File

Here is a snippet of the GitHub Actions workflow file used:

name: Upload files to S3

on:
  push:
    branches:
    - main

env:
  MY_AWS_REGION: '<YOUR AWS REGION>'
  AWS_ROLENAME: '<YOUR AWS ROLE>'
  AWS_S3_BUCKET: '<YOUR S3 BUCKET>'
  SOURCE_DIR: './build'

jobs:
  deploy:
    runs-on: ubuntu-latest
    permissions:
      id-token: write
      contents: read
    steps:
    - name: Checkout
      uses: actions/checkout@master

    - name: Set up Node.js
      uses: actions/setup-node@v3
      with:
        node-version: '16'

    - name: Install dependencies
      run: npm install

    - name: Build project
      run: npm run build

    - name: Configure AWS credentials with IAM Role
      uses: aws-actions/configure-aws-credentials@v4
      with:
        role-to-assume: arn:aws:iam::${{ secrets.AWS_ACCOUNT_ID }}:role/${{ env.AWS_ROLENAME }}
        aws-region: ${{ env.MY_AWS_REGION }}
    - name: Sync files to S3
      run: |
          aws s3 sync ${{ env.SOURCE_DIR }} s3://${{ env.AWS_S3_BUCKET }}/ --delete --exclude '.*git*'
    - name: Invalidate CloudFront Cache
      run: |
          aws cloudfront create-invalidation \
            --distribution-id ${{ secrets.CLOUDFRONT_DISTRIBUTION_ID }} \
            --paths "/*"

Configuring S3 and CloudFront

Creating an S3 Bucket: Create a bucket and enable static website hosting. Configure the bucket to be accessible only through CloudFront for security.
Setting Up CloudFront: Specify the S3 bucket as the origin and configure custom domains and SSL certificates as needed.

Conclusion

With this setup, you can host a React application on S3 and CloudFront, providing fast and secure static site hosting. Additionally, the CICD pipeline with GitHub Actions automates the build and deployment process.

For detailed code and configuration, check out the GitHub repository. GitHub Repository Here

I hope this blog helps you with your projects. If you have any questions or feedback, feel free to leave a comment!

AWS CDK with Automate Testing and TDD

kkkensuke — Tue, 14 Feb 2023 05:48:33 +0000

This post is third post after this(Part2).

Environment

AWS Cloud9
CDK Version : 2.63.2

What we do

This time, we will perform the Fine-Grained Assertions test (Assertion Test) as described in the official AWS documentation.
In this test script, we will mainly use the hasResourceProperties function. This helper function is used when creating a resource in CDK to check "whether the resource has been created" and "the property values set for the resource.

Assertion Tests

Create a test that the DynamoDB table has been created

First, delete the unnecessary test/cdk-workshop.test.ts file. Then create the file test/hitcounter.test.ts and write the following code.

import { Template, Capture } from 'aws-cdk-lib/assertions';
import * as cdk from 'aws-cdk-lib';
import * as lambda from 'aws-cdk-lib/aws-lambda';
import { HitCounter } from '../lib/hitcounter';

test('DynamoDB Table Created', () => {
  const stack = new cdk.Stack();

  // WHEN
  new HitCounter(stack, 'MyTestConstruct', {
    downstream: new lambda.Function(stack, 'TestFunction', {
      runtime: lambda.Runtime.NODEJS_14_X,
      handler: 'hello.handler',
      code: lambda.Code.fromAsset('lambda')
    })
  });

  // THEN
  const template = Template.fromStack(stack);
  template.resourceCountIs("AWS::DynamoDB::Table", 1);
});

This test simply tests that the stack contains a DynamoDB table.
Run the test.

$ npm run test

The following results will be displayed

$ npm run test

> cdk-workshop@0.1.0 test
> jest

 PASS  test/hitcounter.test.ts (12.242 s)
  ✓ DynamoDB Table Created (177 ms)

Test Suites: 1 passed, 1 total
Tests:       1 passed, 1 total
Snapshots:   0 total
Time:        12.439 s
Ran all test suites.

Create a test that Lambda Function has been created

Next, we will add a test case for the Lambda function. This time, in addition to test the creation of the Lambda function, we will also test the values of two environment variables (DOWNSTREAM_FUNCTION_NAME and HITS_TABLE_NAME). You specified these two environment variables when creating the Lambda function in Part 2.
At this point, we do not know which values will be set for these two environment variables (these values were determined at the time of deployment), so we set dummy values for them. Therefore, the first test will fail, but the actual values of the environment variables are output in the failure log, so we will use those values later.
Add a new test case as follows.

test('Lambda Has Environment Variables', () => {
  const stack = new cdk.Stack();

  // WHEN
  new HitCounter(stack, 'MyTestConstruct', {
    downstream: new lambda.Function(stack, 'TestFunctioin', {
      runtime: lambda.Runtime.NODEJS_14_X,
      handler: 'hello.handler',
      code: lambda.Code.fromAsset('lambda')
    })
  });

  // THEN
  const template = Template.fromStack(stack);
  const envCapture = new Capture();
  template.hasResourceProperties("AWS::Lambda::Function", {
    Environment: envCapture,
  });

  expect(envCapture.asObject()).toEqual(
    {
      Variables: {
        DOWNSTREAM_FUNCTION_NAME: {
          Ref: "TestFunctionXXXX",
        },
        HITS_TABLE_NAME: {
          Ref: "MyTestConstructHitsXXXX",
        }
      },
    }
  );
});

After saving the file, run the test.

$ npm run test

One error is included in the test results as follows. The error contains the value of an environment variable that should be specified, so we will use this one.

$ npm run test

> cdk-workshop@0.1.0 test
> jest

 FAIL  test/hitcounter.test.ts (13.577 s)
  ✓ DynamoDB Table Created (198 ms)
  ✕ Lambda Has Environment Variables (99 ms)

  ● Lambda Has Environment Variables

    expect(received).toEqual(expected) // deep equality

    - Expected  - 2
    + Received  + 2

      Object {
        "Variables": Object {
          "DOWNSTREAM_FUNCTION_NAME": Object {
    -       "Ref": "TestFunctionXXXX",
    +       "Ref": "TestFunctioin03257049",
          },
          "HITS_TABLE_NAME": Object {
    -       "Ref": "MyTestConstructHitsXXXX",
    +       "Ref": "MyTestConstructHits24A357F0",
          },
        },
      }

      41 |   });
      42 |   
    > 43 |   expect(envCapture.asObject()).toEqual(
         |                                 ^
      44 |     {
      45 |       Variables: {
      46 |         DOWNSTREAM_FUNCTION_NAME: {

      at Object.<anonymous> (test/hitcounter.test.ts:43:33)

Test Suites: 1 failed, 1 total
Tests:       1 failed, 1 passed, 2 total
Snapshots:   0 total
Time:        13.766 s
Ran all test suites.

Now rewrite the contents of the test case using the values displayed in the above error.

...
expect(envCapture.asObject()).toEqual(
    {
      Variables: {
        DOWNSTREAM_FUNCTION_NAME: {
          Ref: "UPDATE Value from error log",
        },
        HITS_TABLE_NAME: {
          Ref: "UPDATE Value from error log",
        }
      },
    }
  );
...

I ran the test again, and this time it worked!

 $ npm run test

> cdk-workshop@0.1.0 test
> jest

 PASS  test/hitcounter.test.ts (12.738 s)
  ✓ DynamoDB Table Created (150 ms)
  ✓ Lambda Has Environment Variables (94 ms)

Test Suites: 1 passed, 1 total
Tests:       2 passed, 2 total
Snapshots:   0 total
Time:        12.942 s, estimated 14 s
Ran all test suites.

TDD (Test Driven Development）

It is also possible to use the TDD methodology when creating a stack in CDK. As a simple example, suppose we have a new requirement to encrypt an existing DynamoDB table.
The TDD approach would first reflect this requirement in a test script.

test('DynamoDB Table Created With Encryption', () => {
  const stack = new cdk.Stack();

  // WHEN
  new HitCounter(stack, 'MyTestConstruct', {
    downstream: new lambda.Function(stack, 'TestFunction', {
      runtime: lambda.Runtime.NODEJS_14_X,
      handler: 'hello.handler',
      code: lambda.Code.fromAsset('lambda')
    })
  });

  // THEN
  const template = Template.fromStack(stack);
  template.hasResourceProperties("AWS::DynamoDB::Table", {
    SSESpecification: {
      SSEEnabled: true
    }
  });
});

When I run the test, I think it will be an error. This is to be expected since we did not include the encryption setting in the constructor.
So let's update the constructor to state that it will be encrypted for the DynamoDB table.

...
 constructor(scope: Construct, id: string, props: HitCounterProps) {
    super(scope, id);

    const table = new dynamodb.Table(this, 'Hits', {
      partitionKey: { name: 'path', type: dynamodb.AttributeType.STRING },
      encryption: dynamodb.TableEncryption.AWS_MANAGED
    });
...

Run the test again and see if it succeeds this time.
So this is how CDK could be used to approach TDD!

Summary

What do you think? I think there are many projects where visual checks are done on the console, but with the CDK, we can test whether the AWS services are being built as expected, and the DevOps cycle will be faster.

Reference

https://cdkworkshop.com/20-typescript/70-advanced-topics/100-construct-testing.html

AWS CDK for Lambda and DynamoDB

kkkensuke — Mon, 13 Feb 2023 07:04:19 +0000

This post is second post after this(Part1).

Environment

AWS Cloud9
CDK Version : 2.63.2

Image Diagram

Create a HitCounter Lambda in front of the Lambda (Hello Lambda) created in Part 1. The Hit Counter Lambda accesses DynamoDB and counts up the number of hits.

So let's get your hands dirty!

Create HitCounter

Define HitCounter Construct

Create a hitcounter.ts file under the lib folder and write the following code.

import * as cdk from 'aws-cdk-lib';
import * as lambda from 'aws-cdk-lib/aws-lambda';
import { Construct } from 'constructs';

export interface HitCounterProps {
  /** the function for which we want to count url hits **/
  downstream: lambda.IFunction;
}

export class HitCounter extends Construct {
  constructor(scope: Construct, id: string, props: HitCounterProps) {
    super(scope, id);

    // TODO
  }
}

A new construct class HitCounter is defined.
The constructor arguments are scope, id, and props as usual, and we expand it into a cdk.Construct base class.
A new construct class HitCounter is defined.
The constructor arguments are scope, id, and props as usual, and we expand it into a cdk.Construct base class.The props argument is of the same type as HitCounterProps and contains one property, downstream of lambda.IFunction, to "plug in" the Hello Lambda function created in Part 1 to this props and count hits.

Create HitCounter Lambda Function

Next, we will create a Lambda function for the hit counter: lambda/hitcounter.js.

const aws = require('aws-sdk')

exports.handler = async function(event) {
  console.log("request:", JSON.stringify(event, undefined, 2));

  // create AWS SDK clients
  const dynamo = new aws.DynamoDB();
  const lambda = new aws.Lambda();

  // update dynamo entry for "path" with hits++
  await dynamo.updateItem({
    TableName: process.env.HITS_TABLE_NAME,
    Key: { path: { S: event.path } },
    UpdateExpression: 'ADD hits :incr',
    ExpressionAttributeValues: { ':incr': { N: '1' } }
  }).promise();

  // call downstream function and capture response
  const resp = await lambda.invoke({
    FunctionName: process.env.DOWNSTREAM_FUNCTION_NAME,
    Payload: JSON.stringify(event)
  }).promise();

  console.log('downstream response:', JSON.stringify(resp, undefined, 2));

  // return response back to upstream caller
  return JSON.parse(resp.Payload);
};

HITS_TABLE_NAME is the name of the DynamoDB table.
DOWNSTREAM_FUNCTION_NAME is the downstreamed AWS Lambda function name.

Since the table names and downstream function names are determined when the app is deployed, these values must be tied to the constructor code. We will implement this in next sections.

Add resource to Hit Counter constructor

Now we will add the AWS Lambda function and DynamoDB we created to the Hit Counter constructor. lib/hitcounter.ts will look like this

import * as cdk from 'aws-cdk-lib';
import * as lambda from 'aws-cdk-lib/aws-lambda';
import * as dynamodb from 'aws-cdk-lib/aws-dynamodb';
import { Construct } from 'constructs';

export interface HitCounterProps {
  /** the function for which we want to count url hits **/
  downstream: lambda.IFunction;
}

export class HitCounter extends Construct {

  /** allows accessing the counter function */
  public readonly handler: lambda.Function;

  constructor(scope: Construct, id: string, props: HitCounterProps) {
    super(scope, id);

    const table = new dynamodb.Table(this, 'Hits', {
        partitionKey: { name: 'path', type: dynamodb.AttributeType.STRING }
    });

    this.handler = new lambda.Function(this, 'HitCounterHandler', {
        runtime: lambda.Runtime.NODEJS_14_X,
        handler: 'hitcounter.handler',
        code: lambda.Code.fromAsset('lambda'),
        environment: {
            DOWNSTREAM_FUNCTION_NAME: props.downstream.functionName,
            HITS_TABLE_NAME: table.tableName
        }
    });
  }
}

Partition keys for DynamoDB tables are defined as 'path'.
Defines a Lambda function associated with lambda/hitcounter.handler.
Lambda environment variables functionName and tableName are associated with this resource.

Add Hit Counter constructor to out stack

Now that the Hit Counter constructor is ready, the next step is to add the constructor to the stack.

import * as cdk from 'aws-cdk-lib';
import * as lambda from 'aws-cdk-lib/aws-lambda';
import * as apigw from 'aws-cdk-lib/aws-apigateway';
import { HitCounter } from './hitcounter';

export class CdkWorkshopStack extends cdk.Stack {
  constructor(scope: cdk.App, id: string, props?: cdk.StackProps) {
    super(scope, id, props);

    const hello = new lambda.Function(this, 'HelloHandler', {
      runtime: lambda.Runtime.NODEJS_14_X,
      code: lambda.Code.fromAsset('lambda'),
      handler: 'hello.handler'
    });

    const helloWithCounter = new HitCounter(this, 'HelloHitCounter', {
      downstream: hello
    });

    // defines an API Gateway REST API resource backed by our "hello" function.
    new apigw.LambdaRestApi(this, 'Endpoint', {
      handler: helloWithCounter.handler
    });
  }
}

The API Gateway handler has been changed to helloWithCounter.handler. Now when a URL is hit, the Hit Counter Lambda is called first, and the Hit Counter Lambda specifies the helloLambda function in the downstream.

Deploy

cdk deploy

It will take some time. You should see something like the following as an output

Outputs:
CdkWorkshopStack.Endpoint8024A810 = https://xxxxxxxxxx.execute-api.ap-northeast-1.amazonaws.com/prod/

Test

curl -i https://xxxxxxxxxx.execute-api.ap-northeast-1.amazonaws.com/prod/

A 502 Bad Gateway error was returned. We will fix what went wrong.

HTTP/2 502 
...

{"message": "Internal server error"}

When I refer to the error log from CloudWatch, I see that Lambda is throwing an AccessDeniedException against DynamoDB. It is true that we did not give Lambda permission to access DynamoDB. I will add the following to hitcounter.ts.

    // grant the lambda role read/write permissions to our table
    table.grantReadWriteData(this.handler);

Now, retest!
I got a 502 error again... Another 502 error. This time, I get an AccessDeniedException and an error saying "You don't have enough privileges to invoke!". Add the following to hitcounter.ts.

    // grant the lambda role invoke permissions to the downstream function
    props.downstream.grantInvoke(this.handler);

Now the third time's the charm! We finally succeeded!
(It may take a while for API Gateway to flip the endpoint, so if you get the 502 error again, wait a bit and try again.)

HTTP/2 200 OK
...

Hello, CDK! You've hit /

Try it several times.

curl https://xxxxxxxxxx.execute-api.ap-northeast-1.amazonaws.com/prod/
curl https://xxxxxxxxxx.execute-api.ap-northeast-1.amazonaws.com/prod/
curl https://xxxxxxxxxx.execute-api.ap-northeast-1.amazonaws.com/prod/hello
curl https://xxxxxxxxxx.execute-api.ap-northeast-1.amazonaws.com/prod/hello/world
curl https://xxxxxxxxxx.execute-api.ap-northeast-1.amazonaws.com/prod/hello/world

Let's check dynamoDB table.

It looks good! It counts how many hits against each path.

Summary

I think the Hit Counter created this time is a useful service that can be attached to various Lambdas to count how many URLs have been hit for each URL. I think it can be used in actual operations as well!

Reference

https://cdkworkshop.com/20-typescript/40-hit-counter.html

Thank you!

Starting AWS CDK with TypeScript. AWS Lambda + API Gateway

kkkensuke — Sun, 12 Feb 2023 00:47:58 +0000

Environment

AWS Cloud9
CDK Version : 2.63.2

Image Diagram

I would like to create a demo of a Lambda service that can be called via Amazon API Gateway using AWS CDK. The demo image is below.

So let's get your hands dirty!

Creating a new CDK Project

We will be using AWS Cloud9 as our working environment. As the title says, we will create a project using TypeScript.
First, create a directory for the project we will use this time.

mkdir cdk-workshop && cd cdk-workshop

Create a TypeScript CDK project. (This will take a bit of time.)

cdk init sample-app --language typescript

You will see useful cdk commands like this. We will use these later.

## Useful commands

* `cdk deploy`      deploy this stack to your default AWS account/region
* `cdk diff`        compare deployed stack with current state
* `cdk synth`       emits the synthesized CloudFormation template

You will see the project directory created as shown in the figure below.

lib/cdk-workshop-stack.ts:This file defines the main stack of the CDK application. This file is the main file to edit.
bin/cdk-workshop.ts:This will be the entry point for the CDK application, loading the stack defined in lib/cdk-workshop-stack.ts.
cdk.json:It defines how to RUN the app for the toolkit. In this case, it is written as npx ts-node bin/cdk-workshop.ts.

Creating Lambda Function, API Gateway

Clean up unnecessary code and deploy first time

The first step is to clean up some existing code that is not needed.
Open lib/cdk-workshop-stack.ts and clean up as follows, since SQS Queue and SNS topic are not needed for this demo.

import * as cdk from 'aws-cdk-lib';

export class CdkWorkshopStack extends cdk.Stack {
  constructor(scope: cdk.App, id: string, props?: cdk.StackProps) {
    super(scope, id, props);

    // nothing here!
  }
}

The contents of the CDK are empty, but the AWS CloudFormation template is created (synthesize) from the contents described in the CDK, and when deploying to an AWS environment, even if the CDK is used, the CloudFormation template is deployed in the form of a CloudFormation template.

cdk synth

The CloudFormation template has been created in the checkout folder.

Next, you can install a stack called "bootstrap" only for the first deployment. This stack contains resources used by the CDK Toolkit, such as the S3 bucket that holds the CloudFormation templates.

cdk bootstrap

Now, let's deploy it!

cdk deploy

If you look at the CloudFormation console after a successful deployment, you see that the stack you created exists! (It means that the template created with cdk synth has been applied)

Creating Hello Lambda function

Let's write the code for the Lambda function. We will do the following

Create a lambda directory in the same hierarchy as the bin and lib directories.
If a .gitignore file exists, add !lambda/*.js in the file.
Create the file lambda/hello.js and write the following code

exports.handler = async function(event) {
  console.log("request:", JSON.stringify(event, undefined, 2));
  return {
    statusCode: 200,
    headers: { "Content-Type": "text/plain" },
    body: `Hello, CDK! You've hit ${event.path}\n`
  };
};

Add the created Lambda function to the stack

Add the lambda function you just created to the stack. import the CDK Library for Lambda, which is also needed to add the Lambda stack.

import * as cdk from 'aws-cdk-lib';
import * as lambda from 'aws-cdk-lib/aws-lambda';

export class CdkWorkshopStack extends cdk.Stack {
  constructor(scope: cdk.App, id: string, props?: cdk.StackProps) {
    super(scope, id, props);

    // defines an AWS Lambda resource
    const hello = new lambda.Function(this, 'HelloHandler', {
      runtime: lambda.Runtime.NODEJS_16_X,
      code: lambda.Code.fromAsset('lambda'),
      handler: 'hello.handler'
    });
  }
}

A few additional details about the above code

The NodeJS (version 16) runtime is used.
The handler of the Lambda function is written to be read from the lambda directory.
The name of the handler is also the same as the handler in the created function.

Before deploying, take a look at the differences in the code. You can see the differences.

cdk diff

Deploy

cdk deploy

If you look at the console after deploy, you will see that the hello.js Lambda function has been created and that the asset folder has also been created in the S3 bucket.

Test

To test the created Lambda function, create and run a test using the "Amazon API Gateway AWS Proxy" template from the Lambda console.

Looks it works!

Creating a API Gateway

Next, we will create an API Gateway, a service that publishes a public endpoint on the Internet, and connect the API Gateway to Lambda so that it can receive requests from browsers and other devices.
The following is a code of the API Gateway.

import * as cdk from 'aws-cdk-lib';
import * as lambda from 'aws-cdk-lib/aws-lambda';
import * as apigw from 'aws-cdk-lib/aws-apigateway';

export class CdkWorkshopStack extends cdk.Stack {
  constructor(scope: cdk.App, id: string, props?: cdk.StackProps) {
    super(scope, id, props);

    // defines an AWS Lambda resource
    const hello = new lambda.Function(this, 'HelloHandler', {
      runtime: lambda.Runtime.NODEJS_16_X,
      code: lambda.Code.fromAsset('lambda'),
      handler: 'hello.handler'
    });

    // defines an API Gateway REST API resource backed by "hello" function.
    new apigw.LambdaRestApi(this, 'Endpoint', {
      handler: hello
    });
  }
}

Let's look at the differences in the stack.

cdk diff

You can see that a lot of resources are created at once, which shows the convenience of the CDK.

Resources
[+] AWS::ApiGateway::RestApi Endpoint EndpointEEF1FD8F 
[+] AWS::ApiGateway::Deployment Endpoint/Deployment EndpointDeployment318525DA5f8cdfe532107839d82cbce31f859259 
[+] AWS::ApiGateway::Stage Endpoint/DeploymentStage.prod EndpointDeploymentStageprodB78BEEA0 
[+] AWS::ApiGateway::Resource Endpoint/Default/{proxy+} Endpointproxy39E2174E 
[+] AWS::Lambda::Permission Endpoint/Default/{proxy+}/ANY/ApiPermission.CdkWorkshopStackEndpoint018E8349.ANY..{proxy+} EndpointproxyANYApiPermissionCdkWorkshopStackEndpoint018E8349ANYproxy747DCA52 
[+] AWS::Lambda::Permission Endpoint/Default/{proxy+}/ANY/ApiPermission.Test.CdkWorkshopStackEndpoint018E8349.ANY..{proxy+} EndpointproxyANYApiPermissionTestCdkWorkshopStackEndpoint018E8349ANYproxy41939001 
[+] AWS::ApiGateway::Method Endpoint/Default/{proxy+}/ANY EndpointproxyANYC09721C5 
[+] AWS::Lambda::Permission Endpoint/Default/ANY/ApiPermission.CdkWorkshopStackEndpoint018E8349.ANY.. EndpointANYApiPermissionCdkWorkshopStackEndpoint018E8349ANYE84BEB04 
[+] AWS::Lambda::Permission Endpoint/Default/ANY/ApiPermission.Test.CdkWorkshopStackEndpoint018E8349.ANY.. EndpointANYApiPermissionTestCdkWorkshopStackEndpoint018E8349ANYB6CC1B64 
[+] AWS::ApiGateway::Method Endpoint/Default/ANY EndpointANY485C938B

now, deploy it.

cdk deploy

You will see the following URL endpoints as output.

Outputs:
CdkWorkshopStack.Endpoint8024A810 = https://XXXXXXXXXX.execute-api.ap-northeast-1.amazonaws.com/prod/

If you hit this endpoint with the crul command, you'll see the response come back from the Lambda function! You can also try it from your browser.

$ curl https://XXXXXXXXXX.execute-api.ap-northeast-1.amazonaws.com/prod/
Hello, CDK! You've hit /

Summary

This time, we created a simple backend app using CDK with API Gateway + Lambda configuration.
Compared to the case where you have to configure it in the console or by writing CloudFormation, it seems that you can complete the creation in a much shorter time. I would like to continue publishing the CDK series in the future.

Finally, if you want to delete the app you created this time, the following command will clean it up nicely.

cdk destroy

Reference

https://cdkworkshop.com/20-typescript.html

Thank you!