Latest posts

![service](/images/profilepic.png "Andrzej photo")

<dd> By Andrzej Komarnicki Cloud DevOps @ [smallfries.digital](https://smallfries.digital) 
Date: 2024-07-01 </dd>

Pre-signed URLs are a powerful S3 feature that lets you grant temporary, scoped access to upload or download objects without exposing your AWS credentials or making a bucket public. When combined with a scheduled Lambda function, you can automate the generation and delivery of these URLs on a recurring basis — useful for scenarios like periodic data ingestion from external partners, scheduled report uploads, or any workflow where a third party needs time-limited write access to your S3 bucket.

In this post we'll build a solution where Amazon EventBridge triggers an AWS Lambda function on a schedule, the function generates a pre-signed PUT URL for a specific S3 key, and then publishes that URL to an Amazon SNS topic so it can be delivered via email, Slack or any other subscriber.

![architecture](/images/presigned-url-architecture.svg "architecture")

#### How pre-signed URLs work

When you call `generate_presigned_url()` via Boto3, the S3 client signs the request using your Lambda function's IAM credentials. The resulting URL encodes the bucket, key, expiration and signature as query parameters. Anyone with the URL can perform the allowed operation (in our case `put_object`) until the URL expires — no AWS credentials required on their end.

> **Security note:** The pre-signed URL inherits the permissions of the IAM principal that generated it. Make sure your Lambda execution role has only the minimum required S3 permissions, and keep expiration times as short as practical.

#### The Lambda function

Let's start with the Lambda handler. This function generates a pre-signed PUT URL and publishes it to an SNS topic.

```python
import os
import json
import boto3
from datetime import datetime, timezone

s3_client = boto3.client("s3")
sns_client = boto3.client("sns")

BUCKET_NAME = os.environ["BUCKET_NAME"]
SNS_TOPIC_ARN = os.environ["SNS_TOPIC_ARN"]
URL_EXPIRATION = int(os.environ.get("URL_EXPIRATION", 3600)) # seconds
UPLOAD_PREFIX = os.environ.get("UPLOAD_PREFIX", "uploads")


def handler(event, context):
 """Generate a pre-signed S3 upload URL and publish it via SNS."""

 # Build a unique object key using the current UTC timestamp
 timestamp = datetime.now(timezone.utc).strftime("%Y-%m-%d_%H%M%S")
 object_key = f"{UPLOAD_PREFIX}/{timestamp}.dat"

 # Generate the pre-signed PUT URL
 presigned_url = s3_client.generate_presigned_url(
 ClientMethod="put_object",
 Params={
 "Bucket": BUCKET_NAME,
 "Key": object_key,
 "ContentType": "application/octet-stream",
 },
 ExpiresIn=URL_EXPIRATION,
 )

 # Publish the URL to SNS
 message = (
 f"A new pre-signed upload URL has been generated.\n\n"
 f"Bucket: {BUCKET_NAME}\n"
 f"Key: {object_key}\n"
 f"Expires in: {URL_EXPIRATION // 60} minutes\n\n"
 f"Upload URL:\n{presigned_url}\n\n"
 f"Example upload with curl:\n"
 f'curl -X PUT -H "Content-Type: application/octet-stream" '
 f'--data-binary @yourfile.dat "{presigned_url}"'
 )

 sns_client.publish(
 TopicArn=SNS_TOPIC_ARN,
 Subject=f"S3 Upload URL - {timestamp}",
 Message=message,
 )

 return {
 "statusCode": 200,
 "body": json.dumps({
 "bucket": BUCKET_NAME,
 "key": object_key,
 "expires_in": URL_EXPIRATION,
 }),
 }
```

A few things to note:

- We use `put_object` as the `ClientMethod` because we want to grant upload (write) access, not download.
- The `ContentType` parameter in `Params` ensures the uploader must send the correct content type header.
- The object key includes a UTC timestamp so each scheduled invocation produces a unique key.
- `URL_EXPIRATION` defaults to 3600 seconds (1 hour) but is configurable via environment variable.

#### The EventBridge schedule

Amazon EventBridge (formerly CloudWatch Events) lets you trigger Lambda functions on a cron or rate schedule. For example, to generate a new upload URL every day at 8:00 AM UTC:

```bash
aws events put-rule \
 --name "daily-presigned-url" \
 --schedule-expression "cron(0 8 * * ? *)" \
 --state ENABLED \
 --description "Trigger pre-signed URL generation daily at 08:00 UTC"
```

Then add the Lambda function as a target:

```bash
aws events put-targets \
 --rule "daily-presigned-url" \
 --targets "Id"="1","Arn"="arn:aws:lambda:us-east-1:123456789012:function:presigned-url-generator"
```

Don't forget to grant EventBridge permission to invoke your Lambda:

```bash
aws lambda add-permission \
 --function-name presigned-url-generator \
 --statement-id eventbridge-daily \
 --action lambda:InvokeFunction \
 --principal events.amazonaws.com \
 --source-arn arn:aws:events:us-east-1:123456789012:rule/daily-presigned-url
```

You can also use a simple rate expression if you prefer:

```bash
--schedule-expression "rate(12 hours)"
```

#### IAM policy for the Lambda execution role

The Lambda function needs permission to generate pre-signed URLs (which requires `s3:PutObject` on the target bucket/prefix) and to publish to the SNS topic:

```json
{
 "Version": "2012-10-17",
 "Statement": [
 {
 "Effect": "Allow",
 "Action": "s3:PutObject",
 "Resource": "arn:aws:s3:::my-upload-bucket/uploads/*"
 },
 {
 "Effect": "Allow",
 "Action": "sns:Publish",
 "Resource": "arn:aws:sns:us-east-1:123456789012:presigned-url-topic"
 }
 ]
}
```

> **Important:** Pre-signed URLs will only work if the IAM role that generated them still has the required permissions at the time the URL is used. If you revoke `s3:PutObject` from the role, all outstanding pre-signed URLs become invalid immediately.

#### Testing locally

You can invoke the function locally with a test event to verify it works before deploying the schedule:

```bash
aws lambda invoke \
 --function-name presigned-url-generator \
 --payload '{}' \
 response.json

cat response.json
```

You should receive an SNS notification with the pre-signed URL. Test the upload with curl:

```bash
curl -X PUT \
 -H "Content-Type: application/octet-stream" \
 --data-binary @testfile.dat \
 "<presigned-url-from-notification>"
```

Then verify the object landed in S3:

```bash
aws s3 ls s3://my-upload-bucket/uploads/
```

#### Considerations

- **URL expiration:** Keep it as short as practical. For a daily schedule, 1-2 hours is usually sufficient. Longer expirations increase the window of exposure.
- **Object key collisions:** The timestamp-based key pattern avoids collisions for schedules down to one-second granularity. For sub-second invocations, consider adding a UUID.
- **Encryption:** If your bucket uses SSE-KMS, the pre-signed URL signer also needs `kms:GenerateDataKey` permission, and the uploader's request will be encrypted transparently.
- **CORS:** If the upload will happen from a browser, configure CORS on the S3 bucket to allow PUT requests from the appropriate origin.
- **Monitoring:** Add CloudWatch alarms on Lambda errors and SNS delivery failures to catch issues early.

#### Conclusion

Combining EventBridge schedules with Lambda and Boto3's `generate_presigned_url()` gives you a clean, serverless pattern for recurring secure file uploads. The entire solution runs without servers to manage, scales automatically, and costs virtually nothing at low invocation volumes. You can extend this pattern by adding S3 event notifications to trigger downstream processing when the upload completes, or by integrating with Step Functions for more complex workflows.

Use Amazon EventBridge and AWS Lambda with Python Boto3 to generate time-limited pre-signed S3 upload URLs on a schedule and deliver them via Amazon SNS

Scheduled generation of a pre-signed upload URL with AWS Lambda, EventBridge and Boto3

![service](/images/profilepic.png "Andrzej photo")

<dd> By Andrzej Komarnicki Cloud DevOps @ [smallfries.digital](https://smallfries.digital) 
Date: 2024-07-01 </dd>

In modern cloud architectures, it's essential to secure communication between your resources within a Virtual Private Cloud (VPC) and other AWS services. VPC Endpoints provide a secure and scalable way to connect your VPC to AWS services without traversing the public internet, reducing the risk of data exposure and improving network performance.

This blog post will walk you through a CloudFormation template that creates multiple VPC Endpoints for popular AWS services like Amazon S3, DynamoDB, CloudWatch Logs, and AWS Systems Manager (SSM). We'll also cover the necessary security groups and policies to control access to these endpoints.

#### [The CloudFormation Template](https://github.com/AndrzejKomarnicki/cloudformation_utils/blob/main/vpc-endpoints/vpcendpoints.yaml)

The provided YAML template creates the following resources:

- Gateway VPC Endpoints: For Amazon S3 and DynamoDB, allowing private connectivity from your VPC to these services.

- Interface VPC Endpoints: For CloudWatch Monitoring, CloudWatch Logs, SSM, and SSM Messages, enabling private access to these services from your VPC.

- Security Groups: A default security group for the interface endpoints, and a separate security group for EC2 Instance Connect.

Here's a breakdown of the key sections in the template:

```yaml
Parameters:
 VpcId:
 Type: String
 Description: VPC ID
 VpcCIDR:
 Type: String
 Description: VPC CIDR to associate with VPC Endpoint security group
 SubnetIds:
 Type: List<String>
 Description: Comma-separated list of subnet IDs
 RouteTableIds:
 Type: List<String>
 Description: Comma-separated list of route table IDs
```

The template accepts four parameters: the VPC ID, the VPC CIDR block (optional), a list of subnet IDs, and a list of route table IDs. These parameters allow you to customize the deployment to your specific VPC and network configuration.

```yaml
Resources:
 VPCEndpointSecurityGroup:
 Type: AWS::EC2::SecurityGroup
 Properties:
 GroupDescription: VPC Endpoint Security Group
 VpcId: !Ref VpcId
```

This section creates a security group for the interface VPC Endpoints. You can modify the security group rules to control inbound and outbound traffic to these endpoints.

```yaml
S3Endpoint:
 Type: AWS::EC2::VPCEndpoint
 Properties:
 PolicyDocument:
 Version: 2012-10-17
 Statement:
 - Effect: Allow
 Principal: "*"
 Action:
 - s3:*
 Resource:
 - "*"
 RouteTableIds: !Ref RouteTableIds
 ServiceName: !Sub "com.amazonaws.${AWS::Region}.s3"
 VpcId: !Ref VpcId
 VpcEndpointType: Gateway
 PrivateDnsEnabled: false
```

This resource creates a Gateway VPC Endpoint for Amazon S3. Note the PolicyDocument property, which allows all actions _(s3:\*)_ on all S3 resources _(\*)_. You can modify this policy to restrict access as needed.

The template includes similar resources for creating VPC Endpoints for DynamoDB, CloudWatch Monitoring, CloudWatch Logs, SSM, and SSM Messages.

##### Deploying the Template

To deploy this CloudFormation template, you'll need to provide the required parameters (VPC ID, subnet IDs, and route table IDs) specific to your AWS account and VPC configuration. You can deploy the template using the AWS Management Console, AWS CLI, or AWS CloudFormation APIs.

Once deployed, your VPC will have secure, private connectivity to the specified AWS services, without the need for internet gateways, NAT gateways, or public IP addresses.

#### Conclusion

VPC Endpoints are a powerful tool for securing communication between your VPC resources and AWS services. By using CloudFormation templates like the one provided, you can streamline the deployment of VPC Endpoints across multiple accounts and environments, ensuring consistent and secure network configurations.

Remember to review and customize the security group rules and endpoint policies to align with your organization's security requirements and access controls. Additionally, consider automating the deployment process using CI/CD pipelines or infrastructure-as-code tools for efficient and repeatable infrastructure provisioning.

##### Original Complete Template:

```yaml
AWSTemplateFormatVersion: 2010-09-09
Description: Create Gateway VPC Endpoints for S3 and DynamoDB. Interface VPC Endpoints for CloudWatch Monitoring/Logs, EC2 Instance Connect and SSM with a default SG.
Parameters:
 VpcId:
 Type: String
 Description: VPC ID
 VpcCIDR:
 Type: String
 Description: VPC CIDR to associate with VPC Endpoint security group (if not provided 0.0.0.0/0 will be used instead)
 SubnetIds:
 Type: List<String>
 Description: Comma separated list of subnet IDs
 RouteTableIds:
 Type: List<String>
 Description: Comma separated list of route table IDs
Conditions:
 HasVpcCIDR: !Not
 - !Equals
 - ""
 - !Ref VpcCIDR
Resources:
 VPCEndpointSecurityGroup:
 Type: AWS::EC2::SecurityGroup
 Properties:
 GroupDescription: VPC Endpoint Security Group
 VpcId: !Ref VpcId
 VPCEndpointSecurityGroupIngress:
 Type: AWS::EC2::SecurityGroupIngress
 Properties:
 GroupId: !Ref VPCEndpointSecurityGroup
 FromPort: 443
 ToPort: 443
 IpProtocol: tcp
 SourceSecurityGroupId: !Ref VPCEndpointSecurityGroup
 VPCEndpointSecurityGroupIngress2:
 Type: AWS::EC2::SecurityGroupIngress
 Properties:
 GroupId: !Ref VPCEndpointSecurityGroup
 FromPort: 443
 ToPort: 443
 IpProtocol: tcp
 CidrIp: !If
 - HasVpcCIDR
 - !Ref VpcCIDR
 - "0.0.0.0/0"
 S3Endpoint:
 Type: AWS::EC2::VPCEndpoint
 Properties:
 PolicyDocument:
 Version: 2012-10-17
 Statement:
 - Effect: Allow
 Principal: "*"
 Action:
 - s3:*
 Resource:
 - "*"
 RouteTableIds: !Ref RouteTableIds
 ServiceName: !Sub "com.amazonaws.${AWS::Region}.s3"
 VpcId: !Ref VpcId
 VpcEndpointType: Gateway
 PrivateDnsEnabled: false
 DynamoDbEndpoint:
 Type: AWS::EC2::VPCEndpoint
 Properties:
 PolicyDocument:
 Version: 2012-10-17
 Statement:
 - Effect: Allow
 Principal: "*"
 Action:
 - dynamodb:*
 Resource:
 - "*"
 RouteTableIds: !Ref RouteTableIds
 ServiceName: !Sub "com.amazonaws.${AWS::Region}.dynamodb"
 VpcId: !Ref VpcId
 VpcEndpointType: Gateway
 PrivateDnsEnabled: false
 CloudWatchEndpoint:
 Type: AWS::EC2::VPCEndpoint
 Properties:
 PolicyDocument:
 Version: 2012-10-17
 Statement:
 - Effect: Allow
 Principal: "*"
 Action:
 - logs:*
 Resource:
 - "*"
 SubnetIds: !Ref SubnetIds
 SecurityGroupIds: !Split
 - ","
 - !Join
 - ","
 - - !GetAtt VPCEndpointSecurityGroup.GroupId
 VpcId: !Ref VpcId
 ServiceName: !Sub "com.amazonaws.${AWS::Region}.logs"
 VpcEndpointType: Interface
 PrivateDnsEnabled: false
 MonitoringEndpoint:
 Type: AWS::EC2::VPCEndpoint
 Properties:
 PolicyDocument:
 Version: 2012-10-17
 Statement:
 - Effect: Allow
 Principal: "*"
 Action:
 - cloudwatch:*
 Resource:
 - "*"
 SubnetIds: !Ref SubnetIds
 SecurityGroupIds: !Split
 - ","
 - !Join
 - ","
 - - !GetAtt VPCEndpointSecurityGroup.GroupId
 VpcId: !Ref VpcId
 ServiceName: !Sub "com.amazonaws.${AWS::Region}.monitoring"
 VpcEndpointType: Interface
 PrivateDnsEnabled: false
 SsmEndpoint:
 Type: AWS::EC2::VPCEndpoint
 Properties:
 PolicyDocument:
 Version: 2012-10-17
 Statement:
 - Effect: Allow
 Principal: "*"
 Action:
 - ssm:*
 Resource:
 - "*"
 SubnetIds: !Ref SubnetIds
 SecurityGroupIds: !Split
 - ","
 - !Join
 - ","
 - - !GetAtt VPCEndpointSecurityGroup.GroupId
 VpcId: !Ref VpcId
 ServiceName: !Sub "com.amazonaws.${AWS::Region}.ssm"
 VpcEndpointType: Interface
 PrivateDnsEnabled: false
 SsmMessagesEndpoint:
 Type: AWS::EC2::VPCEndpoint
 Properties:
 PolicyDocument:
 Version: 2012-10-17
 Statement:
 - Effect: Allow
 Principal: "*"
 Action:
 - ssmmessages:*
 Resource:
 - "*"
 SubnetIds: !Ref SubnetIds
 SecurityGroupIds: !Split
 - ","
 - !Join
 - ","
 - - !GetAtt VPCEndpointSecurityGroup.GroupId
 VpcId: !Ref VpcId
 ServiceName: !Sub "com.amazonaws.${AWS::Region}.ssmmessages"
 VpcEndpointType: Interface
 PrivateDnsEnabled: false
 VPCEndpointEC2ICSecurityGroup:
 Type: AWS::EC2::SecurityGroup
 Properties:
 GroupDescription: VPC Endpoint Security Group for EC2 Instance Connect
 VpcId: !Ref VpcId
 VPCEndpointEC2ICSecurityGroupEgress:
 Type: AWS::EC2::SecurityGroupEgress
 Properties:
 GroupId: !Ref VPCEndpointEC2ICSecurityGroup
 FromPort: 22
 ToPort: 22
 IpProtocol: tcp
 DestinationSecurityGroupId: !Ref VPCEndpointEC2ICSecurityGroup
 VPCEndpointEC2ICSecurityGroupEgress2:
 Type: AWS::EC2::SecurityGroupEgress
 Properties:
 GroupId: !Ref VPCEndpointEC2ICSecurityGroup
 FromPort: 22
 ToPort: 22
 IpProtocol: tcp
 CidrIp: !If
 - HasVpcCIDR
 - !Ref VpcCIDR
 - "0.0.0.0/0"
 EC2InstanceConnectEndpoint:
 Type: AWS::EC2::InstanceConnectEndpoint
 UpdateReplacePolicy: "Delete"
 Properties:
 SubnetId: !Select
 - 0
 - !Ref SubnetIds
 SecurityGroupIds: !Split
 - ","
 - !Join
 - ","
 - - !GetAtt VPCEndpointEC2ICSecurityGroup.GroupId
 PreserveClientIp: false
```

VPC Endpoints on-demand with CloudFormation

![service](/images/profilepic.png "Andrzej photo")

<dd> By Andrzej Komarnicki Cloud DevOps @ [smallfries.digital](https://smallfries.digital) 
Date: 2023-11-02 </dd>

Cloud Development Kit for Kubernetes (**cdk8s**) is a software development framework for defining Kubernetes applications and reusable abstractions using familiar programming languages and rich object-oriented APIs. cdk8s generates pure Kubernetes YAML - you can use cdk8s to define applications for any Kubernetes cluster running anywhere.

Recently the cdk8s team has expanded the capabilities of the "cdk8s import" command, simplifying the process to incorporate Helm charts. Providing a Helm Chart URL to the "cdk8s import" command will auto-generate a custom type-safe construct for you that represents the Helm Chart in question.

Let's start by initializing a new cdk8s project in an empty directory:

```bash
mkdir cdk8simporthelm && cd cdk8simporthelm
```

```bash
cdk8s init typescript-app
```

You should see the following basic structure of a cdk8s application with the _constructs_ and _cdk8s_ libraries:

```typescript
import { Construct } from 'constructs';
import { App, Chart, ChartProps } from 'cdk8s';

export class MyChart extends Chart {
 constructor(scope: Construct, id: string, props: ChartProps = { }) {
 super(scope, id, props);

 // define resources here

 }
}

const app = new App();
new MyChart(app, 'cdk8simporthelm');
app.synth();
});
```

Now let's go ahead and import the Bitnami Redis chart:

```bash
cdk8s import helm:https://charts.bitnami.com/bitnami/redis@18.2.0
```

Moving back to our **main.ts** file we can now import the new Redis module that was generated in the previous step:

```typescript
import { Construct } from "constructs";
import { App, Chart, ChartProps } from "cdk8s";
import { Redis, RedisArchitecture } from "./imports/redis";

export class MyChart extends Chart {
 constructor(scope: Construct, id: string, props: ChartProps = {}) {
 super(scope, id, props);

 new Redis(this, "Redis", {
 values: {
 architecture: RedisArchitecture.REPLICATION, // <------- type safe property
 },
 });
 }
}

const app = new App();
new MyChart(app, "cdk8simporthelm");
app.synth();
```

After we're done adding anything else we need in addition to what's above, let's synthesize the k8s YAML manifest:

```bash
cdk8s synth
```

You should now have your manifest generated in the **dist** subfolder and you can run kubectl apply as you would with any other manifest.

![redisdeployment](/images/cdk8sredisdeploy.png "redisdeployment")

You can find the source code repo for this blog post here: https://github.com/smallfriesdigital/cdk8s-helm-import

To access more info about Values Schema, Additional Values, Globals and Dependencies visit https://cdk8s.io/docs/latest/cli/import/#helm-charts

Use the new cdk8s import function to generate code for existing Kubernetes Helm Charts

Generate a custom type-safe Helm Chart construct with cdk8s

![service](/images/profilepic.png "Andrzej photo")

<dd> By Andrzej Komarnicki Cloud DevOps @ [smallfries.digital](https://smallfries.digital) 
Date: 2023-04-17 </dd>

With the rising popularity of Function URLs, which are dedicated HTTP(S) endpoints for your Lambda function, we can avoid many of the complexities, costs and limitations associated with Amazon API Gateway. The downside is we also lose some of the nice features of an API Gateway that we get out of the box, one key feature being API routing based on method and path of an http event. This is where Middy, a Node.js middleware engine for AWS Lambda really comes in handy.

In particular, we can achieve nested http routing within our Lambdas by leveraging Middy's [http-router](https://middy.js.org/docs/routers/http-router) handler. Let's start by cloning the starter project repo:

```bash
git clone https://github.com/AndrzejKomarnicki/awscdk-nodejsfunction-middy
```

Next let's install the npm packages and run some AWS CDK CLI commands from the root working directory of our cloned repo.

```bash
npm install
cdk synth && cdk diff
```

By default AWS CDK CLI will check your environment variables for your AWS creds and region first, if not found it will default back to your AWS credentials and config files. You can of course also specify the AWS CLI profile of choice. For more info on how to setup environments for your Stack instance head over to https://docs.aws.amazon.com/cdk/v2/guide/environments.html.

Anyway, if everything checks out let's proceed to deploy the Stack as part of our CDK app:

```bash
cdk deploy
```

After deployment, you should see output similar to below:

![functionurl](/images/functionurl-blog2.png "functionurl")

Next let's dive into the Lambda function source code before we test the endpoints... 
Open up **index.ts** from _/services/node-lambda/_

```javascript
import middy from "@middy/core";
import jsonBodyParser from "@middy/http-json-body-parser";
import httpErrorHandler from "@middy/http-error-handler";
import httpSecurityHeaders from "@middy/http-security-headers";
import httpRouterHandler from "@middy/http-router";
import { APIGatewayProxyEventV2, APIGatewayProxyResultV2 } from "aws-lambda";
import { Logger, injectLambdaContext } from "@aws-lambda-powertools/logger";

const logger = new Logger({
 logLevel: "INFO",
 serviceName: "middy-example-api",
});

async function getHandler(
 event: APIGatewayProxyEventV2,
 context: any
): Promise<APIGatewayProxyResultV2> {
 // the returned response will be checked against the type `APIGatewayProxyResultV2`
 logger.info("This is a INFO log with some context");
 console.log("event 👉", event);
 return {
 statusCode: 200,
 body: JSON.stringify(`Hello from ${event.rawPath}`),
 };
}

async function postHandler(
 event: APIGatewayProxyEventV2,
 context: any
): Promise<APIGatewayProxyResultV2> {
 // the returned response will be checked against the type `APIGatewayProxyResultV2`
 logger.info("This is a INFO log with some context");
 console.log("event 👉", event);
 return {
 statusCode: 200,
 body: JSON.stringify(event.body),
 };
}

// routes served by httpRouterHandler middleware
// you can add more nested handlers for routes (method and path) as needed
const routes = [
 {
 method: "GET",
 path: "/user/{id}",
 handler: getHandler,
 },
 {
 method: "POST",
 path: "/user",
 handler: postHandler,
 },
];

export const handler = middy()
 .use(jsonBodyParser())
 .use(httpSecurityHeaders())
 .use(httpErrorHandler())
 .use(injectLambdaContext(logger)) // Change to (logger, { logEvent: true }) to log the incoming event
 .handler(httpRouterHandler(routes));
```

As you can tell we import **httpRouterHandler** from **@middy/http-router**, and we define two async node.js functions - _getHandler()_ and _postHandler()_, which are referenced by the routes object as part of its handler property depending on http path and method in the http event.

Of course you can re-organize these nested Lambda handlers to be exported as modules instead of having everything in one monolithic index.ts file, this only serves as a starting point for demonstration purposes.

Let's proceed to test our endpoints with the different paths and methods we defined. You can go back to the outputs generated by "CDK deploy" and test against both the _Function URL_ and _CloudFront URL_.

```json
GET method on /user/{userid}
```

![getmethod](/images/getmethod-blog2.png "getmethod")

```json
POST method on /user
```

![postmethod](/images/postmethod-blog2.png "postmethod")

Using AWS CDK with TypeScript to deploy and manage AWS Lambda functions that support nested HTTP routes served through function URL and CloudFront

Latest posts

Scheduled generation of a pre-signed upload URL with AWS Lambda, EventBridge and Boto3

VPC Endpoints on-demand with CloudFormation

Generate a custom type-safe Helm Chart construct with cdk8s

Nested API routes with Node.js AWS Lambda Function URL, Middy HTTP router and AWS CDK