DEV Community: Arpad Toth

Implementing protected Lambda function URLs in user-facing applications

Arpad Toth — Thu, 19 Feb 2026 08:41:57 +0000

TL;DR: When Lambda is configured to return streamed responses from IAM-protected function URLs, we can use Cognito identity pools to allow authenticated users to access the endpoint.

1. The scenario
2. Authorization in API Gateway vs function URL
- 2.1. API Gateway (REST type)
- 2.2. Function URL
3. Architecture diagram
4. Architecture components
- 4.1. Cognito user pool
- 4.2. Cognito identity pool
- 4.3. Amplify
- 4.4. Function URL
5. Considerations
6. Summary
7. Further reading

1. The scenario

The dynamic model selection application currently uses an API Gateway REST API as the entry point. It's because Bedrock returns streamed output from the selected foundation model, and, as of this writing, only REST APIs support streamed responses back to the client.

But API Gateway can be an overkill in some use cases. What if you just have a small function and don't want to configure an API Gateway?

Good news, Lambda function URLs also support streamed responses!

2. Authorization in API Gateway vs function URL

Configuring the function URL for streamed responses is simple. It's only one line of code in CDK (see below).

But how about authorization? How do you ensure that only authorized users can access the endpoint? Wouldn't it be better to still use an API Gateway?

2.1. API Gateway (REST type)

You can protect your API Gateway endpoints in a few different ways.

The most straightforward option is to use a Cognito user pool. The flow is very simple. The user signs in, then the user pool issues tokens (ID and access tokens), and API Gateway validates them.

If you use a custom token or have custom claims, you can implement a Lambda authorizer function. It decodes the token, runs some verification code and returns an IAM policy that allows or denies the invocation to API Gateway, depending on the token validation outcome.

The third option is to use IAM authorization, which is a great and secure way to control access to an API. It's a popular pattern to authorize internal, machine-to-machine requests. IAM validates the requests that must be signed with the Signature V4 algorithm.

2.2. Function URL

But let's say that you want the simplicity of function URLs.

You have two options for your URL. It can be either a public or an IAM protected endpoint.

Public function URLs are - surprise - available for everyone, so unless you're intentionally making it public, you'll eventually want to protect the endpoint and authorize user requests.

You can build custom logic in the Lambda function to authorize requests. It's a workable solution, but it fails to separate responsibilities, i.e., authorization and business logic. Instead, go with IAM authorization.

But here's the challenge. Your users need valid AWS credentials included inside the SigV4 signature header when your application sends the request, otherwise, IAM denies it. That said, your users need lambda:InvokeFunction and lambda:InvokeFunctionUrl permissions to successfully call your IAM-protected function URL.

Now, your application users around the world, Alices, Bobs, Cecils, etc., are not very likely to be your AWS account users, and you don't want them to become ones. So how do you give them AWS credentials so that they can invoke the function URL backing your awesome application?

A good practice in this scenario is to use Cognito identity pools.

3. Architecture diagram

This simplified diagram shows the workflow:

For the sake of simplicity, this solution has a Cognito user pool, but you can integrate any supported identity provider into your architecture. More on that below.

4. Architecture components

Let's review the steps and architecture components.

4.1. Cognito user pool

The user pool contains user authentication data, like username, password, sign-in, and sign-up preferences.

You can also create a user group in the user pool, and add users to it. User groups are actually access control groups since you can assign different IAM roles to different groups. Users belonging to the same groups get the same permissions.

After users successfully authenticate with their username and password (or other sign-in options you configure for them in the user pool), Cognito returns an ID token to the application. The ID token includes the user's group membership and the name of the corresponding role assigned to the user group.

This is where the user pool's responsibility ends in this solution. In this example, each user belongs to only one Cognito group. A future post might cover a scenario when users belong to multiple groups.

4.2. Cognito identity pool

The next step and the solution's critical component is the identity pool.

The ID token issued by the user pool includes the IAM role attached to the group the user is assigned to. The application receives this token from Cognito and calls the identity pool with it (GetId and GetCredentialsForIdentity APIs). After the identity pool verifies the token, it retrieves temporary AWS credentials from STS, and returns them to the application.

The application (in this case, a React app) adds the credentials to the SigV4 signature, signs the request, and attaches the signed headers to the function URL call:

// React component

import { SignatureV4 } from '@aws-sdk/signature-v4';
import { Sha256 } from '@aws-crypto/sha256-js';
import { HttpRequest } from '@smithy/protocol-http';

// ... more component code

const signer = new SignatureV4({
  credentials, // easy to get them with Amplify
  region: REGION,
  service: 'lambda',
  sha256: Sha256,
});

const signedRequest = await signer.sign(request);

const res = await fetch(LAMBDA_FUNCTION_URL, {
  method: 'POST',
  headers: signedRequest.headers,
  body,
});

// ... more code

4.3. Amplify

You can use the Amplify React package to simplify workflows, such as sign-in logic or retrieving AWS credentials from the session object.

The aws-amplify/auth package includes the fetchAuthSession method, where the AWS credentials can be obtained with just two lines of code:

const session = await fetchAuthSession();
const credentials = session.credentials;

The full code is available on my GitHub page in this repo.

4.4. Function URL

You'll need to configure authType to AWS_IAM for IAM authorization on the function URL.

Also, since the response is streamed, I configured the URL accordingly.

Third, since the function URL is invoked from a browser via a React application, I also configured the CORS settings.

modelAbstractionFnForUrl is a Lambda function construct, so you can enable the URL with the addFunctionUrl method:

const modelAbstractionFnUrl = modelAbstractionFnForUrl.addFunctionUrl({
  // configure IAM authorization
  authType: lambda.FunctionUrlAuthType.AWS_IAM,
  // enable browsers to call the function URL
  // narrow it down to the actual domain in production
  cors: {
    allowedOrigins: ['*'],
    allowedMethods: [lambda.HttpMethod.ALL],
    allowedHeaders: ['*'],
    maxAge: cdk.Duration.seconds(300),
  },
  // configure STREAMED response
  invokeMode: lambda.InvokeMode.RESPONSE_STREAM,
});

You now have a protected function URL that returns streamed responses! After your users successfully log in to the application, they can send prompts to the foundation model via the URL.

The entire code (infra and application) can be found in the GitHub repo.

5. Considerations

As stated above, the use case largely influences whether function URLs are a feasible solution. If you need the features of API Gateway, you don't necessarily need an identity pool. But you can design a similar architecture for API Gateway. In that case, you'll need to change the IAM role's permissions attached to the user group and the SigV4 code from lambda to execute-api.

As always, the solution presented in this post is not production-ready, and its feasibility should always be assessed against your use cases.

6. Summary

Lambda function URLs support streaming responses and can be securely restricted to authenticated users via Cognito user pools and identity pools.

The client signs requests using SigV4, which includes the temporary AWS credentials, based on IAM roles attached to Cognito user pool groups.

7. Further reading

Controlling access to resources with Cognito groups and IAM roles - Authenticated users in Cognito Identity pools, Part 1 - Something similar with DynamoDB, and a bit more details on how the identity pool behaves

Building a Dynamic Bedrock Model Selection Serverless Application

Arpad Toth — Thu, 05 Feb 2026 10:16:46 +0000

TL;DR: With the help of Amazon Bedrock, AppConfig, Lambda and API Gateway, we can create a minimalist application that dynamically selects foundation models based on use cases.

1. Context
2. The challenge
3. Architecture diagram
4. Code
- 4.1. Evaluation script
- 4.2. Infrastructure code
- 4.3. Backend code
- 4.4. Front-end code
- 4.5. GitHub
5. Considerations and limitations
- 5.1. Considerations
- 5.2. Limitations
6. Summary
7. Further reading

1. Context

If you are studying for the AWS Certified Generative AI Developer - Professional exam, you might have considered the Exam Prep Plan in AWS Skill Builder as a resource.

The Exam Prep Plan discusses each domain and the corresponding tasks one by one. Tasks in many domains include bonus assignment challenges after covering the required knowledge.

This post presents a solution to the first part of the bonus assignment described in Task 1.2 of the Domain 1 Review section.

2. The challenge

The assignment is about creating an AI application that dynamically selects foundation models in Bedrock based on use cases.

The task is quite complex with many moving parts, so I decided to implement only the dynamic model selection logic for now.

Selecting the right model for a specific use case is critical for cost saving, latency optimization or response correctness. For example, there's no point in using a large, more expensive model for a simple text summarization task, which is better suited to a small text model.

But what if our application covers multiple use cases?

One option is to implement dynamic model selection logic which automatically chooses the right model for a given use case.

This post describes a very basic model selection application using serverless AWS resources.

3. Architecture diagram

The architecture isn't very complex:

Users create a prompt in the UI and select a use case, like balanced or performance optimized, from a dropdown list.

Both the prompt and the selected use case are sent to an API Gateway REST API endpoint, which is integrated with a Lambda function. The function retrieves the model selection strategy configuration object from AppConfig, finds the best model for the use case and invokes it with the prompt.

4. Code

Let's highlight some key elements from the code.

4.1. Evaluation script

To select the right model for a use case, we can evaluate and compare how the models perform.

We can use multiple methods and services to assess model performance, including Bedrock's model evaluation jobs.

The solution in this post follows the bonus assignment suggestion to use custom assessment. I borrowed the main logic from the Exam Prep Plan, made some adjustments, and added test cases and metrics.

Each test case contains a question and a related ground truth answer. The evaluation script compares model responses to the provided ground-truth answers and scores the results in latency, similarity, and cost categories.

I made some modifications to the original code. As an example, the evaluation code provided in the Prep Plan includes a basic keyword check, which I replaced with cosine similarity to capture the semantic similarities between the ground truth and the model response.

I also changed the provided normalization method to min-max normalization to ensure all scores fall between 0 and 1. This way, when the script calculates the weights for each use case, the difference between lower and higher scores will be greater and more readable to the human eye.

Ultimately, the script selects the models that achieve the highest scores in each assessment category and pairs the model IDs with the corresponding use cases.

The last step is to create a JSON file with the model selection strategy configurations, which is then uploaded to AppConfig.

4.2. Infrastructure code

Contrary to the suggested bonus assignment solution, I wanted to use streaming responses in the application. This way, users receive the response token by token as the model generates them. And it looks cool, too.

I used the CDK in TypeScript to create application resources.

First, I want to configure streaming responses in both API Gateway and Lambda. Let's start with API Gateway. For REST APIs, the stream configuration lives inside the method:

// create the "api" before
const generateResource = api.root.addResource('generate');
generateResource.addMethod(
  'POST',
  new apigateway.LambdaIntegration(modelAbstractionFn, {
    proxy: true,
    responseTransferMode: apigateway.ResponseTransferMode.STREAM,
    timeout: cdk.Duration.minutes(2),
  }),
  {
    // options
  }
)

We set STREAM on the responseTranserMode property (which defaults to BUFFER) to enable API Gateway to stream the response to the client. AWS introduced this feature a few weeks ago, and it comes in handy for generative AI and other, long-processing applications.

We can combine the API Gateway streaming response configuration with the increased timeout limit to ensure the client receives the response even if the model takes more than 29 seconds to create the output. The timeout setting allows up to 15 minutes instead of the standard 29 seconds for regional and private REST APIs.

As of this writing, increased timeout and streaming responses in API Gateway HTTP APIs are not supported.

4.3. Backend code

The code sample in the Exam Prep Plan is written in Python. But I wanted to use Lambda function response streaming! Currently, only the Node.js managed runtime supports this feature, so I took a deep breath and migrated the original Python code to TypeScript.

It wasn't just a lift-and-shift job, since I made some minor changes as well. Instead of using the SDK and the (deprecated) GetConfiguration API, the model_abstraction.ts Lambda handler function uses the AppConfig Agent Lambda extension to retrieve the configuration from AppConfig.

The extension is added as a layer to the function and we can include it in the infra code like this:

const modelAbstractionFn = new lambdaNodejs.NodejsFunction(
  this,
  'ModelAbstractionFunction',
  {
    // .. other configurations
    layers: [
      lambda.LayerVersion.fromLayerVersionArn(
        this,
        'AppConfigLayer',
        // modify the URL to match your region
        'arn:aws:lambda:eu-central-1:066940009817:layer:AWS-AppConfig-Extension:261',
      ),
    ],
    environment: {
      APP_CONFIG_APPLICATION_NAME: appConfigApplication.name,
      APP_CONFIG_ENVIRONMENT: appConfigEnvironment.name,
      APP_CONFIG_CONFIGURATION: configProfile.name,
    },
  },
);

If you deploy the stack to a different region, you'll need to select the correct extension ARN for that region.

The function's execution role also needs the appconfig:GetLatestConfiguration and appconfig:StartConfigurationSession permissions, since AWS recommends these APIs over GetConfiguration.

The extension connects to AppConfig through port 2772. Here's my implementation for the retrieveConfig function:

interface AppConfigProps {
  application: string;
  environment: string;
  configuration: string;
}
function retrieveConfig(
  configProps: AppConfigProps,
): Promise<http.IncomingMessage> {
  const { application, environment, configuration } = configProps;
  return new Promise((resolve) => {
    http.get(
      `http://localhost:2772/applications/${application}/environments/${environment}/configurations/${configuration}`,
      resolve,
    );
  });
}

The required values, application, environment and configuration, are provided via environment variables.

The function then parses the input event to get the prompt and use_case properties, extracts the model ID for the use case from the retrieved model selection strategy configuration, and calls the InvokeModelWithResponseStream Bedrock API. As chunks start arriving from Bedrock, we keep writing them to the response stream using responseStream.write. The response stream is created with the built-in awslambda.HttpResponseStream.from() method.

4.4. Front-end code

The minimalistic UI is also written in TypeScript using React.

We must ensure that the component (App.tsx) handles streaming responses and processes the incoming chunks. The user will now see the response appear on the screen gradually as pieces arrive from the backend.

4.5. GitHub

The code is available on my GitHub page in this repo.

5. Considerations and limitations

The project's purpose is to present an idea. The solution is definitely not production-ready!

5.1. Considerations

Nova models

I use Amazon Nova models in the application. Feel free to add models from different vendors. In that case, you may need to modify the Lambda function's code because the inference parameter configurations can differ.

Basic assessments

The custom model assessment presented in the code is very basic. Real-life assessments should consider more metrics and more complex business logic. Again, the idea is to have some basic metrics that can be used the generate a model selection strategy file, then select the model based on the configuration.

AppConfig

Using AppConfig isn't mandatory, although it's a good practice. It lets us modify the configuration without redeploying the application. This way, we delegate individual responsibilities to dedicated resources, following the separation of concerns principle.

Evaluation script

We can also run the evaluation script in the cloud instead of locally on the laptop. Since it takes time to invoke all models with all test cases, an asynchronous, event-driven workflow would work well here. I didn't implement this pattern, as the project's focus was the model selection logic itself.

Streaming

Most models support streaming operations, but not all of them. You can verify if your selected models support this feature before adding them to the pool.

5.2. Limitations

Authentication

The application doesn't implement any authentication or access control for the API. Feel free to add a Cognito user pool or a similar service to protect the endpoint.

Prompt filtering

Prompt inputs aren't validated, and sensitive data aren't handled. You should implement this, for example, by using Bedrock Guardrails to filter model input and output.

Production environment

Other important production components, such as scaling and monitoring/observability, aren't implemented either.

Correctness

As pointed out above, the bonus assignment code sample counts keywords in the model response and compares them to the ground truth. This method fails when the response is semantically correct but uses different wording from the ground truth, which is why I replaced it with a basic semantic similarity calculation in the code.

In real-world applications, both methods, individually and combined (in a hybrid approach), can have their place. For example, legal text usually requires exact word matching, so pure semantic similarity may not work well there. Always consider your specific use case when choosing an accuracy measurement method.

6. Summary

Task 1.2 in Domain 1 is about selecting and configuring foundation models. The solution described here implements a basic model assessment and selection logic that generates the model selection strategy configuration file.

AppConfig stores the file, while an API Gateway REST API provides the entry point to the application. REST APIs now support streaming responses, which, together with Lambda's support for streaming, are handy features for generative AI applications.

7. Further reading

Exam Prep Plan: AWS Certified Generative AI Developer - Professional (AIP-C01 - English) - Exam preparation plan

Scale AI application in production: Build a fault-tolerant AI gateway with SnapSoft - A more robust architecture for production

Building an end-to-end insurance claims app with Amazon Bedrock

Arpad Toth — Thu, 29 Jan 2026 08:56:46 +0000

TL;DR: Task 1.1 assignment in the AWS Skill Builder Generative AI Developer Professional Exam Prep Plan asks you to build a simple insurance claims application that uses Bedrock models to extract and summarize claims.

1. Context
2. The challenge
3. Architecture diagram
- 3.1. Uploading the claim
- 3.2. Extracting the information
- 3.3. Summarizing the claim
- 3.4. Returning the response to the client
4. Code
- 4.1. Application code
- 4.2. Infrastructure code
- 4.3. Front end
- 4.4. GitHub
5. Considerations and limitations
6. Summary
7. Further reading

1. Context

If you are studying for the AWS Certified Generative AI Developer - Professional exam, you might have considered the Exam Prep Plan in AWS Skill Builder as a resource.

The Exam Prep Plan discusses each domain and the tasks within the domains one by one. Each task in a domain contains a bonus assignment challenge after covering the required knowledge.

This post presents a solution to the assignment described in Task 1.1 of the Domain 1 Review section.

2. The challenge

The assignment is about creating a simple insurance claims application built around the task's exam requirements.

The app accepts insurance claims from users and summarizes their most important parts using Amazon Bedrock models.

The flow should include two Bedrock calls: the first to extract the most important pieces from the claim, and the second to summarize it in natural language.

The assignment describes some optional elements, several of which are implemented in this solution.

3. Architecture diagram

The diagram below shows the entire flow of the solution, which includes some additional, non-required elements.

3.1. Uploading the claim

When the user clicks the Upload Claim button in the UI, an API Gateway REST API endpoint accepts the request. A Lambda function generates a presigned URL, which the client then uses to upload the file to the claims S3 bucket.

3.2. Extracting the information

The claims processor Lambda function receives an Event Notification from S3 when a new object is uploaded to the bucket.

The function then calls the InvokeModel API in Bedrock to use a small text model, Amazon Nova Micro, to extract the key properties from the claim. Cost efficiency is key here. This task isn't complex, so it's more cost-effective to use a smaller model. The prompt includes the required JSON response format.

Optionally, you can apply a Bedrock Guardrail to the LLM call to remove sensitive information from both the model input and output.

3.3. Summarizing the claim

The next step is to ask the model to summarize the claim information based on the extracted data.

If you want the fictional insurance company's proprietary policy information to be considered in the model's response, you can use AWS's managed RAG service, Bedrock Knowledge Base.

This solution includes a knowledge base with a source S3 bucket that stores the policy files, an embedding model that converts documents into vectors, and an S3 Vectors vector bucket to store the vectors.

The claims processor function uses the RetrieveAndGenerate Bedrock API to add the relevant policy documentation parts to the summarization model's input.

3.4. Returning the response to the client

The claims processor Lambda function persists the summary returned by the summarization model, as well as some other data like claim ID, model ID, and the time it took the model to summarize the claim, to a DynamoDB table.

The next step is to capture the data changes (e.g., new items in the table) through DynamoDB Streams. The stream handler Lambda function takes the new item from the stream event and forwards it to an API Gateway WebSocket API.

The client connected to the WebSocket API should receive the summary within 2–3 seconds, giving the user real-time confirmation of their claim submission.

4. Code

I split the code into three parts (all in the same repo for convenience).

4.1. Application code

The application code, written in Python, largely relies on the code samples provided by the training material in Skill Builder.

4.2. Infrastructure code

I created and deployed the resources using CDK in TypeScript for easy deployment and stack deletion.

4.3. Front end

The minimalistic UI is also written in TypeScript. The web interface uses React instead of the Flask approach recommended in the Skill Builder assignment.

4.4. GitHub

Deployment and app-running information is available in this GitHub repo if you want to take a look.

5. Considerations and limitations

The project is not production-ready! It's simply a possible solution to the assignment and lacks some important features. See the README for more information.

The application in its current form only accepts .txt files. It assumes that claims are already converted from PDF, DOC, or image files. Handling multiple file extensions is a possible extension to the project. You could add packages in the code, or use Bedrock models or Textract to extract information from the uploaded claims. The solution's stack doesn't include any of these since the purpose of the project was different.

Also, feel free to add more checks to the guardrail, protect the API endpoint with a token, use different models, or keep the WebSocket connection alive in the client with some custom logic.

6. Summary

That's it! Above is a solution to the Task 1 bonus assignment in Domain 1 in the Skill Builder Exam Prep Plan for the Generative AI Developer Professional certification exam.

The application extracts and summarizes insurance claims and uses Bedrock foundation models, Bedrock Knowledge Bases, and Bedrock Guardrails.

7. Further reading

Exam Prep Plan: AWS Certified Generative AI Developer - Professional (AIP-C01 - English) - Exam preparation plan

16 hands-on exercises to prepare for the AWS Certified CloudOps Engineer - Associate certification exam

Arpad Toth — Thu, 18 Dec 2025 12:08:29 +0000

TL;DR: The AWS Certified CloudOps Engineer - Associate certification exam is a practical exam. Combining theory with hands-on experience will increase your chances of achieving a pass result.

1. About the exam
2. Considerations and prerequisites
- 2.1. AWS Organizations
- 2.2. Domain name
- 2.3. Cost considerations
- 2.4. On-premise environment
- 2.5. Bulk exercises
3. Disclaimer
4. The exercises
5. Summary
6. Further reading and learning

1. About the exam

The popular AWS Certified SysOps Administrator - Associate certification was renamed as AWS Certified CloudOps Engineer - Associate (SOA-C03) recently. The new gown reflects the change in both the available AWS technologies and job roles.

As such, new services were added to the exam topic list, and AWS reorganized some of the task statements.

The certification exam now heavily tests your deployment, operation, and maintenance skills both in single and multi-account environments. As it has been the case with the previous version, the renamed certification has a large focus on settings, configurations and automations.

I believe that learning only theory or cramming these configuration options might not be enough to pass the exam. Also, and let's put your hand over your heart, memorizing EC2 or S3 settings will not make you a better cloud professional.

Bottom line: get your hands dirty and do some hands-on exercises before sitting the exam. This post will list 16 such exercises if you run out of ideas.

2. Considerations and prerequisites

Before diving into the exercises, consider the following.

2.1. AWS Organizations

Create multiple accounts to simulate real-world scenarios. It's free to create AWS accounts, and the exam has many AWS Organizations-related questions. If you only have one account, do yourself a favour, set up AWS Organizations (link below), and create at least a second account.

2.2. Domain name

2.3. Cost considerations

Be mindful of potential costs associated with provisioning resources. For example, a t3-micro EC2 instance is sufficient. The exercises won't require you to run a heavy workload. Also, don't forget to delete any CloudWatch log groups created or set the retention period to a low value, like 3 days.

2.4. On-premise environment

You can do your best to cover as many services as possible with hands-on exercises and labs, but you might face some obstacles along the way. If you don't have access to an on-premise environment in your current role, you probably won't be able to test Direct Connect or Site-to-Site VPN. Alternatively, you can try simulating these connections with VPC peering.

The number of related questions is limited, so you should be OK in the exam if you focus on the core services.

2.5. Bulk exercises

Some exercises can be built on previous ones. For example, if you create an EC2 Auto Scaling group, you can use it to add an Application Load Balancer when an exercise needs that set-up.

3. Disclaimer

While these exercises cover the majority of the concepts tested in the exam, they are not enough to pass it. You will need a comprehensive study and practice beyond these exercises.

4. The exercises

Now, onto the theme of this post: Let's see the exercises!

Launch an EC2 instance in a private subnet. Use Session Manager to connect to the instance. What permissions does the IAM role in the instance profile need? What other VPC resource do you need to provision if the VPC has an Internet Gateway?
Create two VPCs, VPC A and VPC B. Set up a VPC peering connection between them. Start an EC2 instance in each VPC. Use Session Manager to connect to the instance in VPC A. Ping the instance deployed to VPC B and observe the configurations (route table, security groups) necessary for the connection to work.
Create an isolated subnet (a private subnet with no NAT Gateway). Provision an EC2 instance in the subnet. Try connecting to the instance with Session Manager. What VPC interface endpoints do you need to create?
Provision an EC2 instance to a VPC. Configure VPC Flow Logs with CloudWatch Logs destination. How many different levels can you configure the flow logs? Ping the instance and observe the flow logs in CloudWatch.
Here's the classic firewall problem! Provision one EC2 instance each in two different subnets, Subnet A and Subnet B. Configure security groups that allow ICMP ping from the instance in Subnet A to the instance in Subnet B. Have VPC Flow Logs configured. Remove the default outbound rule that allows all traffic from all destinations (rule number 100) from the Network ACL attached to subnet B. What do you notice in the flow logs?
Configure an Auto Scaling group with 2 EC2 instances. Observe the steps. What settings are available in the launch template? What scaling policies are available?
Use AWS Certificate Manager to create a certificate to your custom domain. What steps need to be taken to validate domain ownership?
Launch an EC2 Auto Scaling group with at least 2 instances and add an Application Load Balancer to the infrastructure. Configure a CloudFront distribution with the load balancer being the origin. Add a certificate to the distribution. Which region do you need to create the certificate in? Configure a record with simple routing in Route 53. Which record type should you use? Could you use an alias?
Create a Lambda function with the default settings. Replace the // TODO implement line with the following: console.log('Hello world!'). Deploy and invoke the function. Head over to CloudWatch and create a metric filter in the function's log group. Filter for the word world. Configure an alarm on this custom metric that sends you an email notification when the word world occurs in the function logs.
Configure failover routing in Route 53. Use two Application Load Balancers with EC2 instance targets in two different regions.
Launch two EC2 instances in a VPC. Create a private hosted zone and assign it to the VPC. Ping one instance from the other using a custom private domain name.
Configure centralized notification for the Health Dashboard for all your accounts in AWS Organizations. (You might want to do this anyway to prevent Amazon from sending you an email for each active region in each account when, for example, a Lambda runtime becomes end-of-life.)
Set up an email notification automation when an EC2 instance is terminated. Hint: You can use EventBridge.
Create a tag-based resource group that collects resources with the Project: demo tag. Add the EC2 instance resource type (optionally, you can add other resource types).
Provision 3 EC2 instances and add them the Project: demo tag. Install an Apache server on all of them at once using tags or a resource group.
Create a simple portfolio in Service Catalog in Account A. Share the portfolio with Account B. What can and cannot users of Account B do with the portfolio and the products in it?

5. Summary

These exercises will help you get an idea about the expectations in the AWS Certified CloudOps Engineer - Associate certification exam.

I hope you'll find them useful.

Enjoy!

6. Further reading and learning

AWS Certified CloudOps Engineer - Associate - Everything official about the exam

AWS Certified CloudOps Engineer - Associate (SOA-C03) - Exam preparation plan

Tutorial: Creating and configuring an organization - Getting started with AWS Organizations

Updating data status with API Gateway WebSocket API

Arpad Toth — Thu, 04 Dec 2025 10:58:04 +0000

TL;DR: We can use Amazon API Gateway's WebSocket API to keep the front-end up to date with the latest data, providing a near-real-time alternative to polling a REST API endpoint for status notifications.

1. The scenario
2. Solution overview
- 2.1. Requirements
- 2.2. Options
- 2.3. Diagram
3. Pre-requisites
4. Main steps
- 4.1. Ingestion
- 4.2. Click data persistence
- 4.3. Dashboard connection
- 4.4. Persisting connection IDs
- 4.5. Retrieving data from the table
- 4.6. Broadcasting click data
- 4.7. Receiving click results
5. Considerations
- 5.1. No need for a REST API?
- 5.2. Asynchronous workflows
- 5.3. Flexibility
6. Summary
7. Further reading

1. The scenario

Suppose we operate a click data processing application. Customers interact with links and buttons on our page, and the application records the number and type of clicks.

Our application also features a dashboard where authorized users monitor current click counts. The dashboard is browser-based, and, as expected, the front-end exclusively displays data with no business logic involved.

The application persists click results in a database, and the client retrieves them from the backend. But here's a question: How should we display the current click count status?

2. Solution overview

First, let's review the options briefly.

2.1. Requirements

Some of the requirements are:

The dashboard should display the clicks real or near real time.
Minimize human interaction. The solution should be as automated as possible.
Click results should be persisted in a database.
The solution should scale.
The architecture needs to be extendable and its elements should be transferrable to other business scenarios.
The infrastructure must be hosted on AWS and be serverless.

2.2. Options

We can basically consider two solutions: polling and websockets.

After testing the polling solution, we might found it reasonable but expensive. The client must send a request to a REST API every few seconds to get the current state of the click results.

Frequent network calls increase the application's response time. Also, polling logic in the client requires work, like managing the poller’s status and clearing intervals. Still, polling can be useful in some cases.

Instead, we can implement a WebSocket API, rather than writing poller code that would invoke an endpoint every few seconds.

2.3. Diagram

The following diagram summarizes the architecture.

This post focuses on keeping the client (the browser application) synchronised with the current click status. The Considerations section discusses variations to the diagrammed architecture.

3. Pre-requisites

This post is not a comprehensive tutorial, instead, it highlights key steps. It does not explain how to

create API Gateways (REST and WebSocket)
create Lambda functions
create a DynamoDB table
enable and work with DynamoDB streams.

Links to relevant documentation will be provided at the end for those who need them.

4. Main steps

Let's quickly review the main steps in the flow.

4.1. Ingestion

When users click any elements (links or buttons) on the page, the client sends click data to the /ingest REST endpoint created in API Gateway. The IngestClickData Lambda function receives, validates and possibly transforms the data.

4.2. Click data persistence

We persist click stream data in a DynamoDB table. The IngestClickData function persists click data to the table using the PutItem operation.

Alternatively, some business cases may justify direct integration between API Gateway and DynamoDB. If the input does not require validation or transformation, we can omit the Lambda function. Choosing this approach saves costs and improves performance by a few dozen (or even hundreds) of milliseconds.

4.3. Dashboard connection

On the dashboard, administrators monitor the status of click data.

As soon as the dashboard page is loaded, the client connects to the WebSocket API. The connectWebSocket function in the front-end code might look like this:

function connectWebSocket() {
  // 1. Use the WebSocket object
  ws = new WebSocket(WEBSOCKET_URL);

  // 2. When the connection is open
  ws.onopen = () => {
    // If we want to display the connection status
    // in the UI:
    updateConnectionStatus(ConnectionStatus.CONNECTED);
  };

  // 3. When a click data message is received,
  // `handleMessage` is invoked
  ws.onmessage = handleMessage;

  // 4. When the connection is closed
  ws.onclose = (event) => {
    // If we want to display the connection status
    // in the UI:
    updateConnectionStatus(ConnectionStatus.DISCONNECTED);

    // We can implement reconnection logic
    // here if it wasn't an intentional close
  };

  // 5. Error occurred
  ws.onerror = (error) => {
    updateConnectionStatus(ConnectionStatus.DISCONNECTED);

    // The onerror event is always followed by onclose, so
    // reconnection will be handled in the onclose handler
  };
}

The code uses the native WebSocket API (1). The WEBSOCKET_URL's form is similar to REST-type APIs:

wss://<API_ID>.execute-api.eu-central-1.amazonaws.com/<STAGE>/

If we use infrastructure-as-code tools, like the CDK, we can inject the WebSocket URL into the client code dynamically.

Then, we listen to the available WebSocket events. The open event (2) is fired when a connection to the API is established. If we implement any reconnection logic (possibly with exponential backoff), we can clear any pending timeout here. We can also update the connection status here if we want to display it in the UI.

The message event (3) indicates a new click status from the backend (see below). The handleMessage function performs the logic to update a counter or display the current count in a chart.

For closed connections (4) and errors (5), we can implement reconnection logic when reasonable, for example, when the connection closure was unintentional.

4.4. Persisting connection IDs

When we create a WebSocket API in API Gateway, three pre-defined routes are available: $connect, $disconnect and $default.

$connect triggers when the client (the dashboard page) opens a new WebSocket connection to the API. As with the REST-type APIs, we can assign a Lambda integration to the route, specifically the PersistConnectionIds function. As its name suggests, this function stores the WebSocket connection IDs (issued by API Gateway) in the DynamoDB table. The stream processor function will need the connection IDs to broadcast click data statuses to the connected clients (see below).

The $disconnect route is wired to the DeleteConnectionIDs function, which, however unbelievable it may sound, removes the corresponding connection ID from the table. This Lambda function runs when an admin user leaves the dashboard page or closes the browser tab. With the DeleteConnectionIDs function removing the unused connection IDs, the stream processor will not broadcast click data results to unconnected dashboard clients.

$default serves as a fallback if no routes match. This route is not implemented here.

4.5. Retrieving data from the table

When IngestClickData saves a new piece of data to the DynamoDB table, a DynamoDB Streams event is triggered. DynamoDB Streams capture data modification events, and here, whenever data in the table changes, related services can respond in near real time.

Although the diagram uses only one table, another approach could be to split the click data and connection IDs into separate tables.

The StreamProcessor function only cares about changes to click data statuses. With a single table storing both click data and connection IDs, we might want to implement an event filter here to optimize cost. The function doesn't need to run when PersistConnectionIDs saves the connection IDs to the table.

We can easily write a filter in the CDK infrastructure code that monitors a dedicated attribute of the item. Assuming that click data items have an entityType: CLICK attribute, we can write a filter similar to this:

// CDK code!!
// `streamProcessorLambda` is a Lambda Function
// construct defined earlier
streamProcessorLambda.addEventSource(
  new lambdaEventSources.DynamoEventSource(clickstreamTable, {
    // ... other properties
    filters: [
      lambda.FilterCriteria.filter({
        dynamodb: {
          NewImage: {
            entityType: {
              S: lambda.FilterRule.isEqual('CLICK'),
            },
          },
        },
      }),
    ],
  })
);

Now, the processor function runs only when click data is persisted, not when a connection ID is stored.

The StreamProcessor function's handler can be similar to this:

// stream-processor.ts

export async function handler(event: DynamoDBStreamEvent): Promise<void> {
  // Process each stream record
  for (const record of event.Records) {
    try {
      // 1. Extract click data from NEW_IMAGE
      const clickData = extractClickData(record);

      // 2. Broadcast to all active connections
      await broadcastClickEvent(clickData);
    } catch (error) {
      // handle errors here
    }
  }
}

First, the handler extracts the data from the stream event record (1) containing the current status. I don't show this code for brevity, but I have attached some links below that describe how to do it.

Then, StreamProcessor's broadcastClickEvent function will query all connection IDs from the table. Then, it iterates over the array of connection IDs, and invokes the broadcastToConnection utility function for each connection ID (2).

4.6. Broadcasting click data

An extract of the broadcastToConnection function may look like this:

import {
  ApiGatewayManagementApiClient,
  PostToConnectionCommand,
} from '@aws-sdk/client-apigatewaymanagementapi';
// more import statements

const apiGatewayClient = new ApiGatewayManagementApiClient({
  endpoint: WEBSOCKET_API_ENDPOINT,
});

// more code

async function broadcastToConnection(
  connectionId: string,
  message: WebSocketMessage
): Promise<void> {
  try {
    const messageData = JSON.stringify(message);

    await apiGatewayClient.send(
      new PostToConnectionCommand({
        ConnectionId: connectionId,
        Data: Buffer.from(messageData),
      })
    );
  } catch (error) {
    // handle errors here
  }
}

This function receives the message (i.e., the click data status) and a single connection ID. The parent function, broadcastClickEvent (see above) invokes this function for each connection ID.

We create an ApiGatewayManagementClient instance with the WebSocket endpoint, and use the PostToConnection action to send the stringified message to the client connected to the WebSocket API with the connectionId.

4.7. Receiving click results

Finally, the dashboard client receives the click data that StreamProcessor sends to the WebSocket API. When this happens, the message event available via the onmessage property is emitted. As discussed above, the handleMessage front-end function manages the data updates in the UI.

5. Considerations

The solution described here updates the click data status in near real-time. There's no expensive polling involved in the architecture. The browser application will automatically receive the new data through the WebSocket API.

5.1. No need for a REST API?

If there's no requirement for REST APIs, we can simplify the architecture by sending click data to the WebSocket API. We can create a custom route (or use the $default route) and integrate it with the IngestClickData function directly.

If, for example, we want to integrate external systems with a webhook or work with clients that depend on REST endpoints, the solution presented here can be viable.

5.2. Asynchronous workflows

The architecture works particularly well for asynchronous workflows, like order processing or booking. Typically, we don't want users to wait for every step of the workflow to finish. It would result in a suboptimal user experience. Instead, we return an Accepted response after the user has placed the order.

In this case, we probably want to connect the REST-type API Gateway to an SQS queue. A Lambda function can poll the queue for messages and process them at a pace that doesn't overload the backend.

The front-end application can then connect to a WebSocket API and receive the updated order status from the server as described above.

5.3. Flexibility

The architecture is flexible and extendable. In case of steadily heavy volume, API Gateway can directly integrate with Kinesis Data Streams, as described in the documentation. As with SQS queues, Lambda functions can poll the stream and process the records at their own pace.

As always, the solution presented here is not production ready, and cannot be taken as is. You always need to test your solutions before deploying them to production.

6. Summary

WebSocket APIs can be a good choice when we don't want to frequently poll a REST API for status data. API Gateway supports WebSocket APIs.

A key element in WebSocket API architectures is to persist connection IDs in a database, so that the resource (e.g., a Lambda function) broadcasting data to the API is aware of the active connections. Connected clients then automatically receive the current status through the WebSocket API.

7. Further reading

Getting started with Lambda - How to create a Lambda function

Creating a REST API in Amazon API Gateway - The title says it all

Getting started with DynamoDB - DynamoDB basics

Change data capture for DynamoDB Streams - AWS documentation page for DynamoDB Streams

Triggering multiple workflows with DynamoDB Streams - A more subjective and definitely more biased article on DynamoDB Streams

Building event-driven workflows with DynamoDB Streams - Another example of my emotionless self-promotion

Change data capture for DynamoDB Streams - AWS documentation page for DynamoDB Streams

Triggering multiple workflows with DynamoDB Streams - A more subjective and definitely more biased article on DynamoDB Streams

Building event-driven workflows with DynamoDB Streams - Another example of my emotionless self-promotion

Choosing between EventBridge, SNS, and SQS for event-driven patterns

Arpad Toth — Mon, 02 Jun 2025 08:29:50 +0000

TL;DR: AWS offers multiple services for decoupling business domains in event-driven patterns. The three main ones are EventBridge, SNS, and SQS. Use EventBridge for targeted content-based routing when you need to match complex rules. When multiple services or users need real-time notifications, SNS is a reasonable choice. Use SQS to buffer events when you want to protect downstream resources.

1. The scenario
2. EventBridge
- 2.1. Two short paragraphs on EventBridge
- 2.2. EventBridge rule
- 2.3. EventBridge use cases
3. SNS
- 3.1. About SNS - you can skip this if you're a pro
- 3.2. Fanout
- 3.3. SNS use cases
4. SQS
- 4.1. SQS basics
- 4.2. FIFO queues for order
- 4.3. When to use SQS
5. Considerations
- 5.1. SNS message filtering
- 5.2. EventBridge Pipes
- 5.3. Cost
6. Summary
7. Wrap up
8. Further reading

Well, not everything in life is a win. Unfortunately, dev.to hasn't let me upload the article images for days, so, although there are references to them, no diagrams can be found in this post. Please read the article here if you want to view them.

1. The scenario

EventBridge, SNS, and SQS can all be used to decouple services and provide the foundation for an event-driven architecture.

Our scenario involves Alice's e-commerce application, which consists of several microservices. This article focuses on a small portion of the system, specifically order processing.

I’ll explore three specific tasks or challenges from the order processing business requirements and discuss which of the three AWS services is the most suitable choice for each.

2. EventBridge

Users can place three types of orders in this application: standard, express, and international. Alice decided to create different workflows for each order type, as they require distinct handling.

Express orders need immediate processing. Standard orders are less urgent and can be processed in batches at the end of the day. International orders require manual intervention.

Alice’s challenge is to route orders to their corresponding workflows based on the type property of the order event object.

A simplified version of the order event might look like this:

{
  "type": "express",
  "customerId": "12345",
  "items": [{
    "itemId": 12345,
    "itemName": "Fitness bar",
    "quantity": 1,
    "unitPrice": 129.99
  }],
  "totalAmount": 129.99
  // many more properties
}

EventBridge excels in this scenario!

2.1. Two short paragraphs on EventBridge

EventBridge is a serverless event router that performs content-based routing to assigned targets (up to five). We create rules that define the desired event pattern for each target. When a matching event arrives at the event bus (default or custom), EventBridge invokes the target with the event.

AWS services send events to the default event bus. You can create custom event buses for custom application events (non-AWS service events). While you can use the default event bus for custom events, I prefer separating the two, keeping the default event bus for AWS events only.

2.2. EventBridge rule

Consider the express order flow. We want to match every order event where the order originates from the order-placement-service, is newly placed, and has a type of express.

The event pattern for this looks as follows:

{
  "source": ["order-placement-service"],
  "detail-type": ["order.placed"],
  "detail": {
    "type": ["express"]
  }
}

The source, detail-type, and detail fields enable the creation of complex rules for specific use cases.

In Alice’s application, the source property represents service names, while detail-type indicates the order status. The detail field specifies the required property values in the order event object that must be matched.

When the event bus receives a matching event, EventBridge routes it to the assigned target, in this case, a Lambda function.

2.3. EventBridge use cases

EventBridge is a great choice for decoupling services when:

You need to match complex event patterns.
You want to react to AWS service and support third-party events in real time.
You’re designing multi-region or multi-account event-driven architecture.
You need to run scheduled jobs.

3. SNS

Alice’s next event-driven challenge is to notify multiple services (e.g., user notification service, order processing service) when a new order is placed.

The diagram shows only three services for simplicity, but in reality, many more services (e.g., warehouse, delivery, or marketing) may be interested in the order.placed event.

Alice chooses SNS to meet these business requirements.

3.1. About SNS - you can skip this if you’re a pro

Simple Notification Service (SNS), as its name suggests, focuses on notifications.

The publisher (here, the order placement service) publishes a message to an SNS topic. The topic receives messages of the same type. Services interested in these messages can subscribe to the topic. Whenever a publisher sends a message to the topic, SNS broadcasts it to all subscribers.

SNS supports multiple subscriber protocols: email, text messages, HTTP, SQS, Lambda, and more. This allows direct notifications to users’ phones or email addresses, though I would prefer a dedicated notification service in this case.

If message order is critical, you can use a FIFO (first-in-first-out) topic. FIFO topics guarantee message order and exactly-once delivery, but they have lower throughput compared to standard topics.

3.2. Fanout

The diagram illustrates a scenario where a publisher sends a message to the topic, and SNS delivers it to multiple subscribers, including SMS, SQS, and Lambda protocols.

This is called the fanout pattern, a key tool in event-driven design. Standard topics support millions of subscribers, enabling wide fanouts with SNS.

In Alice’s application, the EventBridge target Lambda function publishes the event to the express workflow topic, and SNS notifies relevant services in real time.

The Lambda function requires the sns:Publish permission in its execution role.

3.3. SNS use cases

Use SNS when:

You need to notify a large number of subscribers in real time.
You’re creating alarms, for example, in CloudWatch.
You’re designing a pub/sub (publisher/subscriber) pattern with known targets (subscribers).

4. SQS

Alice’s final challenge is protecting a third-party API endpoint called by one of the services. Like many third-party integrations, the endpoint is rate-limited, say, to one request per second.

Issues arise when more orders flood the system than the API can handle. Alice wants to minimize throttling errors from the external service.

She needs a temporary message store to buffer messages, allowing the consumer compute resource to process them at a pace suitable for the downstream API.

One of AWS’s earliest services, SQS, serves this purpose.

4.1. SQS basics

Simple Queue Service (SQS) is a serverless queue service that decouples services by buffering messages. Messages can be stored in queues for up to 14 days.

Unlike SNS, SQS is a point-to-point service.

Typically, there is one producer and one consumer.

While multiple producers can technically send to the same queue, I recommend creating separate queues for each producer to maintain clear responsibilities. Multiple producers for a single queue can complicate debugging and tracing. As a serverless service, SQS is billed by the number of requests, and you pay nothing when it’s unused. SQS also offers a generous free tier, so there’s little reason not to create multiple queues in these scenarios.

Similarly, multiple consumers can be assigned to a queue, but they will compete for messages, meaning not every consumer processes every message. This can cause issues if the consumers implement different business logic.

The consumer must delete a message from the queue after successful processing; otherwise, it becomes visible again for reprocessing.

SQS has a default retry policy, delivering unsuccessfully processed messages to a dead-letter queue (DLQ) after the maximum retry attempts. Teams can configure alarms on queue length and investigate issues when messages reach the DLQ.

4.2. FIFO queues for order

SQS queues come in two types: standard and FIFO, with principles similar to SNS FIFO topics.

Standard queues offer higher throughput but don’t guarantee message order and provide at-least-once delivery, requiring consumers to implement idempotency mechanisms.

FIFO queues ensure that messages enter and leave in the same order and guarantee exactly-once delivery.

Alice’s application uses an SQS queue to protect the third-party (e.g., delivery partner) endpoint in the scenario described.

4.3. When to use SQS

SQS is ideal for:

Temporarily storing messages to protect downstream resources.
Implementing reliable message delivery and processing with retries.
Isolating unprocessed messages for debugging.

SQS pairs well with Lambda functions. Lambda polls the queue for messages (polling invocation model) and automatically deletes processed messages.

5. Considerations

Let’s discuss some additional considerations.

5.1. SNS message filtering

SNS supports message filtering, allowing subscribers to receive only messages matching specific attributes. By attaching a filter policy to a subscription, subscribers receive a subset of messages. Without a filter policy, subscribers receive all messages published to the topic.

I have seen using SNS and EventBridge interchangeably, especially with the SNS message filtering feature. It's not easy to decide which one to use in some cases. I prefer EventBridge when the problem is more routing-focused, like the one with the different order types. I choose SNS when I want the message to be broadcast and received by other interested entities.

5.2. EventBridge Pipes

EventBridge Pipes combines aspects of EventBridge and SQS. It reacts to AWS service events in a point-to-point manner and offers filtering and message enrichment capabilities. It can provide a good alternative solution for these services in some cases.

5.3. Cost

Since EventBridge, SNS, and SQS serve different use cases — while all help decouple (micro)services — I don’t find it relevant to compare their costs.

Cost management for each service could be the topic of a separate article (or three, one for each), so I won’t discuss it here.

I’ve linked the corresponding pricing pages at the bottom of the post. You can also use the Pricing Calculator to estimate costs for your workload if needed.

6. Summary

The following table summarizes the key differences between EventBridge, SNS, and SQS.

Feature	EventBridge	SNS	SQS
Primary purpose	Content-based event routing	Real-time notifications	Message buffering
Communication pattern	Many-to-many with filtering	One-to-many (fanout)	Point-to-point
Use cases	Complex event pattern matching, AWS service events, scheduled jobs	Notifying multiple subscribers in real time, alarms, pub/sub pattern	Protecting downstream resources, reliable message delivery with retries
Delivery guarantee	At-least-once	At-least-once (standard), exactly-once (FIFO)	At-least-once (standard), exactly-once (FIFO)
Message retention	No retention (unless archived)	No retention	Up to 14 days
Integration with Lambda	Asynchronous invocation model	Asynchronous invocation model	Polling invocation model
Special capabilities	Event pattern matching, cross-account/region routing	Message filtering with subscription policies	Message buffering, throttling protection

7. Wrap up

EventBridge, SNS, and SQS are core AWS services that enable architects and developers to design and implement event-driven architectures.

This post discussed when to use each service and provided examples for each use case in a fictional application.

8. Further reading

Event bus concepts in Amazon EventBridge - Everything about event buses

Event bus targets in Amazon EventBridge - Targets supported by EventBridge

Creating rules that react to events in Amazon EventBridge - How to create EventBridge rules

Creating a subscription to an Amazon SNS topic - Straightforward guidance from the documentation

Amazon SNS message filtering - More details on message filtering

Amazon EventBridge pricing - Pricing details for EventBridge

Amazon SNS pricing - Pricing details for SNS

Amazon SQS pricing - Pricing details for SQS

Building MongoDB-based event-driven applications with DocumentDB

Arpad Toth — Thu, 22 May 2025 10:06:36 +0000

TL;DR: We can create event-driven architectures that react to changes in MongoDB. Change streams are supported in the latest DocumentDB engine, and we can trigger a Lambda function when a change occurs in the database. Although this article discusses how to send new MongoDB documents to OpenSearch, this is not the only use case. We can publish a message to SNS or EventBridge and inform other services of the database changes.

1. MongoDB vs DynamoDB
2. The scenario
3. MongoDB change streams
4. Architecture
- 4.1. Overview
- 4.2. Detailed view
5. Considerations
- 5.1. Not production-ready
- 5.2. Testing the app
- 5.3. Connecting to the database cluster
- 5.4. Direct integration
- 5.5. Other event-driven options
6. Summary
7. Further reading

1. MongoDB vs DynamoDB

I like DynamoDB and use it where it makes sense. I like the fast speed, the elasticity and the fact that it often has a negligible cost compared to other database options.

But sometimes we have to consider other NoSQL options, like MongoDB. Why do we want to choose MongoDB over DynamoDB? Here are some reasons:

The application needs to store items as JSON documents.
Documents are deeply nested, and it would be a lot of effort to transform them into simple attributes that DynamoDB expects.
MongoDB has a simple JavaScript syntax. DynamoDB has a steeper learning curve.
Your team lead or line manager is afraid of anything new, and they want you to use the good old MongoDB.

There might be other reasons (feel free to write them in a comment), but these ones come to mind now.

2. The scenario

So, MongoDB is the chosen database. Do we have to abandon the event-driven patterns we can implement with DynamoDB Streams?

The good news is no, we don't.

MongoDB supports change streams, which applications can use to react to real-time data changes.

Luckily, AWS has a MongoDB-compatible NoSQL database called DocumentDB, and the latest engine version (5.0.0) now supports change streams.

3. MongoDB change streams

Change streams store event objects for 3 hours by default, but we can extend the duration up to 7 days. We must explicitly enable change streams on a database or specific collections in the database.

A good spot for the change stream code is where we write (and probably cache) the MongoDB client code:

// Create the connection and get the client
const client = await connectToDatabase();

// Enable change streams on the collection
const adminDb = client.db('admin');
await adminDb.command({
  modifyChangeStreams: 1,
  database: DB_NAME,
  collection: COLLECTION_NAME,
  enable: true
});

Part of the connectToDatabase() function may be similar to this:

const secretsManager = new SecretsManagerClient();

export async function connectToDatabase(): Promise<MongoClient> {
  // Get credentials from Secrets Manager
  const secretCommandInput: GetSecretValueCommandInput = {
    SecretId: process.env.DOCDB_SECRET_ARN,
  };

  const secretData = await secretsManager.send(
    new GetSecretValueCommand(secretCommandInput)
  );

  if (!secretData.SecretString) {
    throw new Error('Missing database credentials in config');
  }

  const secret = JSON.parse(secretData.SecretString);

  const encodedUsername = encodeURIComponent(secret.username);
  const encodedPassword = encodeURIComponent(secret.password);
  const port = DOCDB_PORT || '27017';
  const database = DOCDB_DATABASE || 'products';

  const uri = `mongodb://${encodedUsername}:${encodedPassword}
  @${DOCDB_ENDPOINT}:${port}/${database}?tls=true&replicaSet=rs0
  &readPreference=secondaryPreferred&retryWrites=false`;

  const client = new MongoClient(uri, {
    tlsCAFile: <PATH_TO_ROOT_CERTIFICATE_PEM_FILE>,
    tls: true,
  });

  await client.connect();
  cachedClient = client;

  return client;
}

As you can see, it's a standard MongoDB connection function.

I want to highlight one thing in the code. DocumentDB integrates with Secrets Manager, where database secrets (username and password) are stored. The function must fetch these credentials before it can create the connection URI.

Now that we have enabled the change streams, let's look at the architecture. How can we use the change stream feature in our applications?

4. Architecture

This article will present the simple design of an application where admin users can add products, and users can search for them.

4.1. Overview

The connection point to the application is an API Gateway, which has two endpoints: POST /product and GET /search.

Administrators upload the new product info by sending the product object in the request body to the /product endpoint. In this sample project, part of the product schema looks like this:

{
  "productId": 1001,
  "productName": "Wireless Headphones",
  "description": "Noise-cancelling wireless headphones",
  "brand": "SoundPro",
  "category": "Electronics",
  "price": 199.99,
  "currency": "USD",
  "ratings": {
    "averageRating": 4.7
  },
  // other product-related properties, many of which are nested
}

A Lambda function will act as the endpoint integration and save new products to the database.

As discussed above, I chose DocumentDB for the project because of the many nested properties in the document, and I want to store the document as is. I didn't bother making the database and collection names very complex, and named both products.

A second Lambda function called changeStreamHandler watches the MongoDB change stream and indexes the new product documents in OpenSearch Serverless service. The function iterates over the events records and adds them to OpenSearch.

Finally, users can invoke the /search endpoint with a search expression to fetch matching product details. The search function in my little POC performs a multi_match query:

// ...other function code
// Search in OpenSearch
const response = await opensearchClient.search({
  index: 'products',
  body: {
    query: {
      multi_match: {
        query, // User's search expression
        fields: [
          'productName^3',
          'description^2',
          'brand',
          'category',
          'ratings.averageRating',
        ],
      },
    },
    sort: [{ _score: { order: 'desc' } }],
  },
});

As the code above shows, the search expression looks for matching data in five fields.

Requests to OpenSearch must be signed with AWS Signature V4. The OpenSearch project npm package contains the AwsSigv4Signer method, which makes the signature simple:

import { Client } from '@opensearch-project/opensearch';
import { AwsSigv4Signer } from '@opensearch-project/opensearch/aws';

// ...

const client = new Client({
  node: endpoint,
  ...AwsSigv4Signer({
    region: 'eu-central-1',
    service: 'aoss', // Amazon OpenSearch Serverless
  }),
});

Let's take a closer look at some key elements.

4.2. Detailed view

Functions in the VPC. It's a shame, but as of today, DocumentDB is only available in a cluster format that runs managed instances. The cluster must be provisioned in at least two - preferably private - subnets in a VPC. There's currently no serverless version available!

The product and changeStreamHandler Lambda functions interact with the database. As such, we must provision them, possibly in the same VPC private subnets. (Let's not go into other VPC design options here.)

Security groups. The functions' security groups must allow outbound rules to the security group assigned to the DocumentDB cluster. The DocumentDB security group must allow inbound traffic on port 27017 (the MongoDB default port) from the Lambda functions' security group.

Event source mapping. Since the changeStreamHandler reads events from the change stream, Lambda will use the polling invocation model. We must configure an event source mapping, where, besides the usual stream settings, like batchSize or startingPosition, we must set the authentication option and specify the database and collection names the function will read events from. A sample CDK code with a low-level construct may look like this:

const eventSourceMapping = new cdk.CfnResource(
  this,
  'ChangeStreamEventSourceMapping',
  {
    type: 'AWS::Lambda::EventSourceMapping',
    properties: {
      FunctionName: changeStreamLambda.functionArn,
      EventSourceArn: docdbClusterArn,
      StartingPosition: 'LATEST',
      BatchSize: 10,
      Enabled: true,
      SourceAccessConfigurations: [
        {
          Type: 'BASIC_AUTH',
          // The ARN of the Secrets Manager secret
          // that holds the connection info
          URI: docdbSecret.secretArn,
        },
      ],
      DocumentDBEventSourceConfig: {
        DatabaseName: 'products',
        CollectionName: 'products',
      },
    },
  }
);

We must also specify the Secret Manager secret's ARN containing the DocumentDB cluster connection information (username and password).

NAT Gateway. For the functions to interact with DocumentDB via the event source mapping, we need to provision either a NAT Gateway or some VPC interface endpoints. The documentation will describe what endpoints are required in more detail. For the sake of simplicity, I created a NAT Gateway, but it might not be the best option for some industries where companies need to comply with strict regulations.

OpenSearch Serverless. Great option for proofs-of-concept (like this one) or teams that don't want to manage OpenSearch clusters. It's a fully managed service where we don't have to worry about VPCs, security groups and NAT Gateways. The search function connects to OpenSearch Serverless through an https endpoint.

Permissions. Lambda functions provisioned in a VPC must have specific permissions other than those they use to connect to DocumentDB. The Lambda service needs to create ENIs - Elastic Network Interfaces, virtual network cards in the VPC -, so we must add the required permissions to the function's execution role.

The product function also needs Secrets Manager (secretsmanager:GetSecretValue and secretsmanager:DescribeSecret) and KMS (kms:Decrypt) permissions since it needs to authenticate to DocumentDB.

5. Considerations

The result is a simple event-driven application, where we use streams to react to MongoDB data changes.

I want to highlight a couple of things, though.

5.1. Not production-ready

As it might be clear from the discussion above, this article does not cover the entire application.

The application is only a POC and is not production-ready. It only contains some core infrastructure elements.

Error handling, retries and monitoring should also be implemented in production workloads.

5.2. Testing the app

Besides the basic let's call the endpoint and see what happens method, I tested the application with a script, which made a batch of 5 parallel requests per second to the POST /product endpoint until 500 documents got uploaded to the database.

The architecture elements scaled well when needed, and I didn't experience any bottlenecks.

5.3. Connecting to the database cluster

If you are like me and prefer connecting to databases from the terminal vs using a GUI, you are probably familiar with the MongoDB Shell.

But how can we connect to the DocumentDB cluster, which is provisioned in a private network, from outside?

We have a couple of options. One of them is to launch an EC2 instance in the same VPC, install mongosh on the instance, and copy the cluster connection command from the DocumentDB page in the console.

For example, we can then check which databases and collections have the change streams setting enabled:

db.runCommand({
  aggregate: 1,
  pipeline: [{$listChangeStreams: 1}],
  cursor: {}
})

The response will look like this:

{
  waitedMS: Long('0'),
  cursor: {
    firstBatch: [ { database: 'DB_NAME', collection: 'COLLECTION_NAME' } ],
    id: Long('0'),
    ns: 'test.$cmd'
  },
  operationTime: Timestamp({ t: 1747661570, i: 1 }),
  ok: 1
}

Alternatively, you can use the usual GUI solutions like Studio 3T. Instructions on connecting to DocumentDB can be found in the official documentation.

5.4. Direct integration

I discussed one possible solution to connect OpenSearch and DocumentDB.

OpenSearch Ingestion pipelines support DocumentDB as source and keep the database in sync with OpenSearch without using an intermediary compute resource, like the changeStreamHandler function in this example. Ingestion pipelines support filtering, data transformation and enrichment, replacing the Lambda function with a managed feature.

The need to control the business logic and cost considerations (ingestion pipelines vs running a Lambda function) can help make the right architecture decision.

5.5. Other event-driven options

Indexing documents in OpenSearch is not the only action we can perform by building on change streams.

We can create fanout patterns by having the Lambda function publish a message to an SNS topic or an EventBridge event bus, allowing other (micro)services to react to the MongoDB state changes.

6. Summary

MongoDB change streams offer the option to implement event-driven patterns that react to document changes in the database.

DocumentDB is a NoSQL database with MongoDB compatibility, where version 5.0.0 supports change streams.

One implementation pattern is to index the newly created document in OpenSearch and provide users with a search box to perform advanced searches.

7. Further reading

Amazon OpenSearch Service Pricing - Ingestion pipelines pricing included

Create your first Lambda function - If you need help in creating Lambda functions

Creating an Amazon DocumentDB cluster - I can't add more to the title

Triggering multiple workflows with DynamoDB Streams

Arpad Toth — Thu, 15 May 2025 06:50:34 +0000

How can we trigger multiple workflows in response to database changes? One way is to design an event-driven architecture with a fanout pattern. DynamoDB Streams makes it easy to implement these architectures.

1. The scenario

I love event-driven architectures. They have a natural flow, require minimal code, and are well-suited for microservices.

A common use case I have encountered is that after a write is committed to the database, other services in the application need to trigger their business logic based on the new data.

Developers often write code to make this work. A typical solution looks like this (pseudo-code):

async function writeData(data) {
  // 1. Write data and wait for the success response
  const databaseResponse = await db.write(data);

  // 2. Publish a message to SNS
  await snsClient.send(new PublishCommand({
    Message: data, TopicArn: TOPIC_ARN,
  }));
}

First, the function persists the data to the database and waits for a success response. Then, it publishes a message to a service like SNS, where multiple subscribers can process the information.

Alternatively, the function might try to handle everything:

async function fanout(data) {
  // Send a message to an SQS queue
  await sqsClient.send(new SendMessageCommand({
    QueueUrl: QUEUE1_URL,
    MessageBody: JSON.stringify(data),
  }));

  // Send a message to another SQS queue
  await sqsClient.send(new SendMessageCommand({
    QueueUrl: QUEUE2_URL,
    MessageBody: JSON.stringify(data),
  }));

  // Start a Step Functions state machine execution
  await sqsClient.send(new SendMessageCommand({
    QueueUrl: QUEUE3_URL,
    MessageBody: JSON.stringify(data),
  }));

  // etc.
}

I would avoid code like this. Whether these calls run in parallel or sequentially, you will need to implement robust error handling and retry mechanisms, and the code can quickly become complex, requiring significant debugging time.

Sometimes, writing such code is unavoidable. However, some AWS database services offer excellent support for event-driven solutions. With DynamoDB, you can capture data changes by enabling streams.

DynamoDB offers two streaming models: DynamoDB Streams and Kinesis Data Streams for DynamoDB.

This article focuses on DynamoDB Streams and how to implement streamlined event-driven architectures by capturing data changes.

2. DynamoDB Streams

Wouldn’t it be great if the writeData function’s only responsibility were to save new or updated items to DynamoDB, and other services in the application could receive notifications about new data and react independently?

I’ll answer my own question: Yes, it would be great.

DynamoDB Streams is designed for this purpose. Here are some key features:

Stores records for up to 24 hours.
Records appear exactly once and leave the stream in the same order they entered.
Lambda reads from the stream are free (this alone makes DynamoDB Streams appealing).
Supports up to two concurrent consumers per shard for single-region (not global) tables via the DynamoDB Streams GetRecords API. Reads from additional consumers may be throttled.

This sounds promising, except for the last point. Only two consumers? That limits us to basic fanout-like solutions.

Despite the API read restriction, we can still use streams to trigger multiple downstream services and design fanout architectures.

Let’s explore some solutions.

3. Using Lambda functions

I use Lambda functions whenever possible, so I’m excited that pairing DynamoDB Streams with Lambda presents many opportunities.

3.1. Lambda as a consumer

When Lambda is added as a stream consumer, the Lambda service handles everything through event-source mapping settings. You can configure options like batch size or an on-failure destination. Lambda uses a polling invocation model, querying the stream four times per second.

You can also configure up to five filter criteria per Lambda function to match specific item attributes. Lambda only invokes the function when a matching record appears in the stream, eliminating the need for filtering logic in your code. This can save significant costs by avoiding invocations for irrelevant events.

3.2. Fanout with Lambda

How can we run multiple business logic processes on database change records?

You can configure multiple Lambda functions (more than two) to be triggered by the same DynamoDB stream. Each function receives and processes the same records.

Lambda functions don’t count as separate consumers, as the Lambda service acts as the consumer. When a new record is available (which is almost always, given the use cases of streams), Lambda invokes the functions simultaneously, scaling their concurrency as needed (and configured).

DynamoDB automatically adjusts the number of shards, and you have no control over this.

Fanout with Lambda functions? Absolutely!

4. Other fanout options

Not every use case suits Lambda functions, and not everyone prefers Lambda. How can we trigger multiple workflows that don’t rely on Lambda?

4.1. Intermediary service

The two-concurrent-consumers-per-shard limit can be a bottleneck. A solution can be an intermediary service that receives records from the stream and forwards them to another service responsible for triggering interested parties.

4.2. Fanout with EventBridge Pipes

A great candidate for an intermediary service is EventBridge Pipes.

EventBridge Pipes connects a source to a target.

DynamoDB Streams is a supported source for a pipe, with direct integration, so no external tools (like a Lambda function) are needed. EventBridge polls the stream shards at four requests per second.

For a fanout architecture, you can choose an SNS topic or an EventBridge event bus as the target.

SNS supports a wide range of subscribers, including SQS queues, Lambda functions, or email addresses.

EventBridge buses support up to five targets per rule, offering a smaller fanout than SNS.

A Step Functions state machine is also a valid target for EventBridge Pipes. You can create fanout-like solutions using the Parallel state, where different workflows run independently.

This is an interesting solution worth exploring.

4.3. Fanout with a Lambda function

Lambda functions can also serve as intermediary services. A router function can act as the stream consumer, forwarding events to services like SNS or EventBridge after receiving a record.

Advantages of using Lambda as an intermediary include simplicity and the control provided by custom code. It may also be more cost-effective than EventBridge Pipes.

4.4. If none of these work

If none of these solutions fit your use case, I’m sorry to hear that!

I believe a small Lambda intermediary function should suit most architectures. If not, you can retrieve stream records directly using the GetRecords API and deploy code to poll the stream on any AWS compute service. Be mindful of the two-concurrent-consumers-per-shard rule when implementing custom solutions.

5. Summary

You can react to database changes in an event-driven way using DynamoDB Streams.

The simplest approach is to use streams with Lambda functions. If Lambda isn’t suitable, EventBridge Pipes or a Lambda intermediary function can distribute data change events to an SNS topic or EventBridge event bus, where you can add multiple subscribers or targets.

6. Further Reading

Change data capture with Amazon DynamoDB - DynamoDB stream options

DynamoDB Streams limits - Throttling considerations

Using event filtering with a DynamoDB event source - Event filtering options in Lambda

4 Cognito User Pools features you might not know about

Arpad Toth — Thu, 10 Apr 2025 19:01:25 +0000

Cognito User Pools is more than just a user directory. It's an ecosystem that tackles authentication edge cases and boosts development efficiency.

1. Cognito User Pools - beyond a simple user directory

Cognito User Pools is a fully managed, OpenID Connect-compatible identity provider. It serves as a user directory service that handles authentication and authorization for application users.

Importantly, Cognito User Pools doesn’t manage access to AWS resources like S3 or DynamoDB. It’s designed for the mobile and web applications we build. With a user pool integrated into an app, our users can sign up, log in, and change passwords effortlessly, requiring minimal work on our end.

Having a service like Cognito User Pools is a game-changer. Before using it, I built authentication workflows manually, and trust me, it was far from enjoyable. It’s much simpler to rely on a dedicated service that handles all the flows right out of the box.

2. Lesser-known features

Beyond the basics, Cognito User Pools offers some lesser-known features that enhance the experience for both users and administrators.

In this post, I’ll highlight four of them.

2.1. Modifying tokens

As mentioned, Cognito User Pools aligns with the OpenID Connect standard, issuing an ID token once a user successfully authenticates. It also provides access tokens, making it compliant with OAuth 2.0 standards.

Tokens are expected, but did you know you can intercept the authentication flow and add custom properties to them?

We can set up Cognito to trigger a Lambda function at various stages of the sign-up and sign-in processes. These functions can enrich both the ID token and the access token.

This opens up a world of customization options for controlling app access. For example, we can embed custom data in the ID token for the front-end client to use, enabling guards to restrict content. Alternatively, we can add custom scopes to the access token and implement fine-grained access control in an API Gateway API. All it takes is some Lambda function code, and Cognito triggers it at the right time.

2.2. Passkeys for login

Cognito also lets us integrate passwordless login into our applications!

One option is using passkeys. YubiKeys are a popular choice, but password managers and operating system key storage options work seamlessly with Cognito too.

Passwordless sign-in is getting more popular, and with Cognito, we can keep our apps ahead of the curve.

2.3. User existence error masking

How does your app respond when someone tries to log in with a nonexistent username?

One approach is to return a “User not found” error, but this tells the user they can keep guessing with different usernames.

By enabling the Prevent user existence errors feature in the App client settings, Cognito displays a vague error like “The username or password is incorrect” when someone tries to log in with a nonexistent username.

This feature extends to passwordless sign-in too. When I set up the email verification code option and entered a nonexistent username, Cognito displayed the standard, expected message on the next page:

So, what’s happening here? How does the “Prevent user existence errors” feature play out?

It’s all about the email address - it’s fake.

At first, I thought this was a bug and that Cognito might have sent a verification code to some random stranger’s email. But the truth is, when the user doesn’t exist, Cognito shows a simulated message with a dummy email address and never sends the validation code.

Big thanks to AWS technical support and the Cognito team for clearing this up! 🙌

2.4. Customizable login page

Cognito offers hosted authentication pages known as the hosted UI. Recently, they rolled out managed login, an updated version of the classic hosted UI.

This managed authentication page is a lifesaver. It means we don’t have to build login and sign-up forms from scratch on the front end.

But there’s more! We can customize the managed login page using a no-code visual editor called the branding designer, which lets us tweak every element of the login form.

We can adjust spacing and border-radius, and add custom logos or background images, among other options. If you prefer, you can still upload a custom CSS file with the classic hosted UI. Switching between the two is easy if needed.

3. Summary

This short post explored four lesser-known Cognito User Pools features: token modification, passkey-based passwordless authentication, user existence error masking, and customizable managed login pages.

These features have made my life easier when integrating Cognito into my applications. How about you?

Verifying Cognito access tokens - Comparing three JWT packages for Lambda authorizers

Arpad Toth — Thu, 03 Apr 2025 07:08:06 +0000

When using Cognito access tokens to secure our API, we can choose from several JSON Web Token packages to verify tokens in Lambda authorizer functions.

1. The scenario

When the built-in Amazon API Gateway authorization methods don’t fully meet our needs, we can set up Lambda authorizers to manage the access control process. Even when using Cognito user pools and Cognito access tokens, there may still be a need for custom authorization logic.

The Lambda authorizer code decodes and verifies the token, and its business logic determines whether the request should proceed to the backend or be denied. Cognito access tokens are JSON Web Tokens (JWTs), and to simplify our coding, we might opt for an external package to handle token verification.

This article compares three JWT packages designed for Node.js and TypeScript.

2. Requirements

The comparison and final verdict are based on my specific requirements:

Lambda authorizers are necessary due to unique validation needs.
I use Cognito access tokens with scopes, which I verify in the authorizer (not covered in this article).
The authorizer should immediately return a deny policy if called with invalid, expired, or non-access tokens.
I rely on certain token properties in the authorizer logic, so decoding and verification are required.

3. Pre-requisites

This post will not go into the details of setting up the following:

A Cognito user pool.
A REST-type API Gateway.
A Lambda authorizer.

Links to relevant documentation will be provided at the end for those who need them.

As always, the solution I have chosen works for my use case, but your opinion or experience might differ.

4. Comparison

I explored three packages: AWS JWT Verify, jose, and jsonwebtoken.

The code examples I provide focus solely on the verification process. The custom logic for why the authorizer exists is omitted - you can substitute it with your logic. I also use utility functions to group similar logic, but I have left them out to keep things concise, so some snippets include pseudo-code.

Results in the Performance sections are based on tests with a 512 MB Lambda authorizer memory configuration.

After this necessary but lengthy introduction, let’s dive into the packages.

4.1. aws-jwt-verify

Since I’m working with Cognito tokens, I started with AWS JWT Verify.

Purpose

Maintained by AWS, this package is specifically designed to verify JWTs issued by Cognito.

Code

Here’s how the token verification flow might look with aws-jwt-verify:

import { CognitoJwtVerifier } from 'aws-jwt-verify';
import { APIGatewayRequestAuthorizerEvent } from 'aws-lambda';
import { CognitoAccessTokenPayload } from 'aws-jwt-verify/jwt-model';

// import util methods

// 1. Instantiate the verifier outside the handler
const verifier = CognitoJwtVerifier.create({
  userPoolId: process.env.USER_POOL_ID!,
  tokenUse: 'access',
  clientId: process.env.APP_CLIENT_ID!,
});

export async function handler(event: APIGatewayRequestAuthorizerEvent, context: Context) {
  const { headers, methodArn: resource } = event;

  // util function to extract the JWT from the header
  const token = extractAuthorizationToken(headers);
  if (!token) {
    // util function to generate the DENY IAM policy
    return generatePolicy({
      resource,
      effect: 'Deny',
      principalId: 'principal_id',
      message: 'Some error message',
    });
  }

  let payload: CognitoAccessTokenPayload;
  try {
    // 2. Use the verifier's "verify" method
    payload = await verifier.verify(token);
  } catch (error) {
    return generatePolicy({
      resource,
      effect: 'Deny',
      principalId: 'principal_id',
      message: 'Some error message',
    });
  }

  const { sub: userId, scope } = payload;

  // custom endpoint access control logic to verify scope here
}

Some key points to note.

First, we create a Cognito JWT verifier (1) by specifying the user pool ID, app client ID, and the token type to verify (access, id, or null). Setting null skips checking the token_use property. The authorizer pulls the user pool and app client ID from environment variables.

It’s best to instantiate the verifier outside the handler function. Since the user pool and app client ID are static and their values don’t depend on the event payload, this approach improves the Lambda function’s runtime. Code outside the handler is pre-loaded in the execution environment.

The core logic relies on the verifier’s verify method (2), which returns the token payload upon successful verification. As shown, no extra logic is needed. The package handles everything internally, keeping the code clean and readable.

Performance

My tests showed an initial cold start of 650–670 milliseconds. The first invocation took around 200 milliseconds, with subsequent calls typically under 100 ms, regardless of the verification result. I even saw a few single-digit durations, which was impressive!

Pros

Handles all Cognito-specific validation
Built-in TypeScript support
Minimal configuration and no extra methods required
Fetches and caches JSON Web Key Set under the hood

Cons

Limited to AWS tokens
Limited algorithm support (AWS use cases)
Restrictions apply when used with non-AWS identity providers

Best to use it

The aws-jwt-verify package shines when your application relies on Cognito as an identity provider.

Experience

I found this package fast and straightforward to use. It handles common verification scenarios (expired tokens, an ID token is sent instead of the access token) effectively and manages caching internally.

4.2. jose

Next up, I tested jose.

Purpose

jose is a well-maintained package that fully implements the JavaScript Object Signing and Encryption (JOSE) specification. It’s larger than aws-jwt-verify and offers more features.

Code

Here’s how I implemented jose for Cognito access tokens:

import { APIGatewayRequestAuthorizerEvent, Context } from 'aws-lambda';
import { createRemoteJWKSet, jwtVerify, errors } from 'jose';
import { CognitoAccessTokenPayload } from 'aws-jwt-verify/jwt-model';

// import util methods

const { JSON_WEB_KEY_SET_URL, ISSUER_URL } = process.env;

// 1. Cache the JSON Web Key Set
let cachedJWKS: ReturnType<typeof createRemoteJWKSet> | null = null;

export async function handler(event: APIGatewayRequestAuthorizerEvent) {
  const { headers, methodArn: resource } = event;

  // util function to extract the JWT from the header
  const token = extractAuthorizationToken(headers);
  if (!token) {
    return generatePolicy({
      resource,
      effect: 'Deny',
      principalId: 'principal_id',
      message: 'Some error message',
    });
  }

  // 2. Don’t feed the verifier with the token if it’s not an access token
  const decodedPayload = JSON.parse(
    Buffer.from(token.split('.')[1], 'base64').toString()
  );
  if (decodedPayload.token_use !== 'access') {
    return generatePolicy({
      resource,
      effect: 'Deny',
      principalId: 'principal_id',
      message: 'Some error message',
    });
  }

  let payload: CognitoAccessTokenPayload;
  try {
    // 3. Verifier util method is created to make the code
    // more readable
    payload = await verifyToken(token, {
      jwkUrl: JSON_WEB_KEY_SET_URL,
      issuerUrl: ISSUER_URL,
    });
  } catch (error) {
    // util method to handle different types of verification errors
    return tokenVerificationError(error);
  }

  const { sub: userId, scope } = payload;

  // custom endpoint access control logic to verify scope here
}

// Verifier utility function
interface VerifyTokenProps {
  jwkUrl: string;
  issuerUrl: string;
}
async function verifyToken(token: string, props: VerifyTokenProps) {
  if (!cachedJWKS) {
    cachedJWKS = createRemoteJWKSet(new URL(props.jwkUrl));
  }

  const verifyResult = await jwtVerify<CognitoAccessTokenPayload>(
    token,
    cachedJWKS,
    {
      issuer: props.issuerUrl, // the user pool’s
      maxTokenAge: 3600, // (4)
    }
  );

  return verifyResult.payload;
}

First, we cache the function that resolves the JSON Web Key Set (JWKS) from the Cognito JWKS endpoint (1). This prevents repeated calls to the endpoint for every authorizer invocation.

Next, I ensured the authorizer exits early if the token is not an access token (2). Since only access tokens include the scope property, there’s no point in proceeding with an incorrect token type.

The token verification happens in the verifyToken utility function (3). It checks for a local JWKS cache and downloads it from the remote endpoint if needed.

The jwtVerify function validates the token and returns the decoded payload on success. I discovered that without specifying maxTokenAge, the verifier hangs until the authorizer times out when given an expired token (4).

Performance

The Lambda cold start was similar to aws-jwt-verify. The first call took about 3.5 seconds due to the external API call to the Cognito JWKS endpoint. Subsequent calls ranged from 150–250 milliseconds.

Pros

Complete implementation of JOSE specifications
Supports a wide range of algorithms
TypeScript support
Supports both JWS (signing) and JWE (encryption)

Cons

Larger package
May be overkill for simple JWT use cases
More complex API, requiring additional configuration

Best to use it

The jose package excels with complex security needs, token creation, or non-AWS JWT implementations.

Experience

Initially, the authorizer timed out after 6 seconds with invalid or missing tokens. I realized I needed more memory. Calls consistently used over 300 MB of RAM, so configure the Lambda accordingly.

4.3. jsonwebtoken

The final package I evaluated was jsonwebtoken.

Purpose

The last commit to the jsonwebtoken repository was two years ago. I didn’t dig into the source code to assess the need for updates. With nearly 20 million weekly downloads, this popular package maintains the strong trust of developers and other libraries.

Code

Here’s how I implemented the logic with jsonwebtoken:

import {
  APIGatewayAuthorizerResult,
  APIGatewayRequestAuthorizerEvent,
} from 'aws-lambda';
import { decode, verify } from 'jsonwebtoken';
import jwkToPem from 'jwk-to-pem';
import axios from 'axios';
import { CognitoAccessTokenPayload } from 'aws-jwt-verify/jwt-model';

// import util methods

type JSONWebKey = jwkToPem.JWK & {
  kid: string;
  use: string;
};
interface JWKSResponse {
  keys: JSONWebKey[];
}

// 1. Implement caching for better performance
let jwksCache: JSONWebKey[] | null = null;
const jwksPemCache: { [key: string]: string } = {};

export const handler = async (
  event: APIGatewayRequestAuthorizerEvent
): Promise<APIGatewayAuthorizerResult> => {
  const { headers, methodArn: resource } = event;

  // util function to extract the JWT from the header
  const token = extractAuthorizationToken(headers);
  if (!token) {
    return generatePolicy({
      resource,
      effect: 'Deny',
      principalId: 'principal_id',
      message: 'Some error message',
    });
  }

  // built-in method to decode the JWT
  const decodedToken = decode(token, { complete: true });

  // Get the issuer from environment variables
  const issuer = 'https://cognito-idp.eu-central-1.amazonaws.com/USER_POOL_ID';

  let publicKey: string;
  try {
    // 2. Get the public key using a util function
    publicKey = await getPublicKey(decodedToken.header.kid, issuer);
  } catch (error) {
    return generatePolicy({
      resource,
      effect: 'Deny',
      principalId: 'principal_id',
      message: 'Some error message',
    });
  }

  // 3. Verify the token
  const verified = verify(token, publicKey, {
    issuer: issuer,
    algorithms: ['RS256'],
  }) as CognitoAccessTokenPayload;
  if (!verified) {
    return generatePolicy({
      resource,
      effect: 'Deny',
      principalId: 'principal_id',
      message: 'Some error message',
    });
  }

  const { sub: userId, scope } = verified;

  // custom endpoint access control logic to verify scope here
};

We can implement in-memory caching to enhance the authorizer’s performance (1).

Then, we fetch the public key from the Cognito JWKS endpoint using a utility function (2). Here’s what getPublicKey might look like:

async function getJwks(issuer: string) {
  if (jwksCache) {
    return jwksCache;
  }

  try {
    const response = await axios.get<JWKSResponse>(issuer);
    jwksCache = response.data.keys;
    return jwksCache;
  } catch (error) {
    throw error;
  }
}

async function getPublicKey(kid: string, issuer: string): Promise<string> {
  if (jwksPemCache[kid]) {
    return jwksPemCache[kid];
  }

  const jwks = await getJwks(issuer);
  const key = jwks.find((k) => k.kid === kid);
  if (!key) {
    throw new Error('Public key not found');
  }

  const publicKey = jwkToPem(key);
  jwksPemCache[kid] = publicKey;

  return publicKey;
}

We use axios, a popular HTTP client, to retrieve the key set.

Finally, the built-in verify method checks the token’s validity (3).

Performance

The Lambda cold start was comparable to the other packages. The first call lasted 250–300 milliseconds, with subsequent (cached) calls often under 100 milliseconds. Peak memory usage hovered around 180 MB.

Pros

Widely used, popular package with strong community support
General-purpose JWT library flexible enough for custom JWT implementations
Built-in methods for token decoding and verification
Offers greater control over the verification process

Cons

In-memory caching is recommended to boost performance
Requires extra code for full functionality
You need to implement logic to fetch the key set

Best to use it
Use jsonwebtoken for simple JWTs from Cognito or non-AWS identity providers. It’s ideal if you want a lightweight, general-purpose package with built-in methods.

Experience

I used jsonwebtoken before, so its methods were familiar. It’s popular across frontend and backend development, and many packages depend on it. It performed reliably, though I had to invest some effort to match the logic of the other packages.

5. The verdict

After testing all three packages, I chose aws-jwt-verify for my project with Cognito access tokens.

The deciding factor was its minimal code requirements. It also proved fastest in my tests, though for my use case, the difference between an 80-millisecond and a 200-millisecond response is negligible.

For all packages, allocate sufficient memory to the authorizer function. I found 256 MB insufficient as functions often timed out with invalid tokens. I recommend at least 512 MB of RAM for each package.

These packages are not limited to Lambda. You can use them to validate tokens in Express servers running on EC2 instances or containers, for example.

6. Summary

Multiple npm packages can verify JWTs.

For a Cognito user pool as an identity provider, aws-jwt-verify offers a simple, lightweight solution.

For general JWT verification, jsonwebtoken is a solid choice. For advanced verification logic, consider jose.

7. Further reading

Getting started with user pools - How to create a user pool with an app client

Get started with API Gateway - How to create an API Gateway resource

Create your first function - AWS Lambda "Getting started"

Verifying a JSON Web Token - What aws-jwt-verify does for token validation

Implementing advanced authorization with AWS Lambda for endpoint-specific access

Arpad Toth — Thu, 27 Mar 2025 15:12:38 +0000

When handling more complex authorization patterns, we can implement the necessary logic using Cognito Lambda triggers and authorizer functions.

1. The scenario

I’m working on a maths contest application where participants move from one checkpoint to another, solving engaging maths puzzles. Each checkpoint has a task assigned to teams based on their year group.

Checkpoints are staffed by invigilators or supervisors who give the tasks to participants. Students step aside to solve the task, then share their - hopefully - correct answer with the supervisor, who logs it into the application.

Naturally, the application runs on AWS serverless infrastructure. 😄

One key requirement is that supervisors at any checkpoint can only access tasks assigned to their specific checkpoint. They should not see puzzles from other checkpoints.

The API Gateway includes an endpoint structured like this:

API_URL/checkpoints/:id

This endpoint returns data for the application to display about the corresponding checkpoint. The application has many endpoints, but, in this article, I will focus on the /checkpoints/:id endpoint to explain the solution.

So, supervisors at Checkpoint 1 can only call /checkpoints/1, those at Checkpoint 2 can call /checkpoints/2, and so forth.

The application uses a Cognito user pool to manage users, including the supervisors.

2. Challenges

As I planned the solution for this scenario, I encountered several challenges. I will address the following ones below.

2.1. Endpoint protection

Supervisors, regardless of the checkpoint, call the same endpoint, with the :id path parameter being the only difference. How can I implement endpoint authorization to reject calls when the path parameter does not match the supervisor’s assigned checkpoint?

2.2. Client-side

The client dynamically adds the path parameter to the URL based on the supervisor’s checkpoint. How does the client determine which path parameter to use when making the call?

2.3. Consistency

The client needs to call all endpoints, including /checkpoints/:id, using an access token as outlined by OAuth 2.0.

3. Pre-requisites

This post won't go into detail about how to create and configure the following:

A Cognito user pool, groups and a pre-token generation trigger.
An app client with resource servers and scopes.
A REST-type API Gateway and its integrations.
Lambda functions.

Links to the relevant documentation pages will be provided at the end of the post for those who need them.

4. Solution

Here’s one solution that works for my scenario.

4.1. Overview

The solution relies on two Lambda functions.

The first function triggers after user authentication, but before the user pool issues tokens. The second serves as the endpoint authorizer.

Before implementing these, though, we need to assign supervisors to the appropriate Cognito groups.

4.2. Groups

I opted for straightforward group names for supervisor assignments: checkpoint-1, checkpoint-2, and so on. Cognito allows up to 10,000 groups per user pool, which should be plenty unless our maths contest grows to an enormous scale.

Supervisors at Checkpoint 1 are added to the checkpoint-1 group, and the same pattern applies until all supervisors are assigned to their respective groups.

4.3. Resource servers

I configured a dedicated resource server and custom scopes in the user pool for supervisor authorization management.

I won’t explain the setup process here - I covered resource servers and custom scopes in a separate article.

The custom scopes follow this format: checkpoint/1, checkpoint/2, and so on. Supervisors at Checkpoint 1 receive the checkpoint/1 scope, those at Checkpoint 2 get checkpoint/2, and the pattern continues for all checkpoints.

4.4. Pre-token generation trigger

We should tackle two tasks: let the client know the correct path parameter and attach the matching scope to the access token.

A pre-token generation Lambda trigger can handle both. Once connected to the user pool, Cognito calls the Lambda function with a payload like this:

{
  // Some properties are omitted for brevity
  "region": "eu-central-1",
  "userPoolId": "USER_POOL_ID",
  "userName": "USER_NAME",
  "request": {
    "userAttributes": {
      "sub": "USER_ID_IN_COGNITO",
    },
    "groupConfiguration": {
      "groupsToOverride": [
        // WE NEED THIS:
        "checkpoint-1",
      ],
    },
    "scopes": [
      "openid"
    ]
  },
  "response": {
    "claimsAndScopeOverrideDetails": null
  }
}

As you can see, the pre-token generation Lambda trigger receives the supervisor’s assigned checkpoint! The function can then add this information to the ID and access tokens.

ID tokens carry details about the authenticated user. We can include a custom checkpoint_id variable to store the checkpoint ID. The front-end client can pull this ID from the token and dynamically insert it as a path parameter in the URL.

Access tokens contain authorization details in the scope property. The pre-token generation trigger can add the relevant scope to the access token.

Here’s what the function’s (pseudo) code might look like:

export async function handler(event) {
  // 1. Generate scopes
  const groups = event.request.groupConfiguration.groupsToOverride;
  const userScopes = generateUserScopesFromCognitoGroups(groups);

  // 2. Get the checkpoint ID for supervisors
  const checkpointId = extractCheckpointIdFromScope(userScopes);

  // 3. Add the info to the tokens
  return {
    ...event,
    response: {
      claimsAndScopeOverrideDetails: {
        // 3.a. Checkpoint ID to the ID token
        idTokenGeneration: {
          claimsToAddOrOverride: {
            checkpoint_id: checkpointId.toString(),
          },
        },
        // 3.b. Scopes to the access token
        accessTokenGeneration: {
          scopesToAdd: ['openid', ...userScopes],
        },
      },
    },
  };
}

The generateUserScopesFromCognitoGroups utility converts a Cognito group name like checkpoint-1 into a scope format, checkpoint/1.

The extractCheckpointIdFromScope utility pulls the checkpoint ID 1 from checkpoint-1.

Once the function runs, the ID token includes this property:

"checkpoint_id": "1"
// other ID token properties

The access token reflects the corresponding checkpoint scope:

"scope": "openid checkpoint/1"
// other access token properties

With these enriched tokens, the client can extract the checkpoint_id from the ID token, append it to the URL path, and call the endpoint with the access token.

4.5. Lambda authorizer

Now, the client calls the correct URL with the checkpoint ID in the path and the access token in the Authorization header. The final step is to confirm that the checkpoint ID in the endpoint matches the scope in the token.

Cognito authorizers are too rigid for this case. Using one would require attaching all checkpoint scopes to the endpoint, allowing any supervisor to call it with any checkpoint ID.

Lambda authorizers work well for custom authorization logic. They are standard Lambda functions that receive specific authorizer payloads from API Gateway.

Of the two payload types, TOKEN and REQUEST, I chose REQUEST for this scenario. I have covered TOKEN-type payloads elsewhere, so I will focus on REQUEST payloads here.

A Lambda authorizer with a REQUEST payload gets an event object like this:

{
  // properties are omitted for brevity
  "type": "REQUEST",
  "methodArn": "arn:aws:execute-api:eu-central-1:ACCOUNT_ID:API_ID/STAGE_NAME/GET/checkpoints/1",
  "resource": "/checkpoints/{id}",
  "path": "/checkpoints/1",
  "httpMethod": "GET",
  "headers": {
    // WE NEED THIS
    "Authorization": "Bearer ACCESS_TOKEN",
  },
  "pathParameters": {
    // AND THIS
    "id": "1"
  },
  "stageVariables": {},
  "requestContext": {
    // lots of properties
  }
}

The event includes everything the authorizer needs to compare the :id path parameter with the access token’s scope.

Here’s a snippet of the authorizer’s (pseudo) code:

export async function handler(event) {
  const { headers, pathParameters, methodArn: resource } = event;

  // 1. Get the token from the Authorization header
  const token = extractAuthorizationToken(headers);
  // 2. Verify and decode the token
  const tokenPayload = verifyAccessToken(token);

  // 3. Get the "sub" and "scope" properties from the token
  const { sub: userId, scope } = payload;
  // 4. Get the checkpoint ID from the invoked URL path
  const checkPointIdInPath =
    extractCheckpointIdFromPathParameters(pathParameters);

  // 5. Compare the checkpoint IDs from the path and the token
  const matchingCheckpointIds =
    matchPathParameterIdToScope(checkPointIdInPath, scope);
  // 6. Return IAM policies as per the result
  return matchingCheckpointIds
    ? generatePolicy({ resource, effect: Effect.ALLOW, principalId: userId })
    : generatePolicy({ resource, effect: Effect.DENY, principalId: userId });
}

// Util function to generate the policy
function generatePolicy({ resource, effect, principalId }) {
  return {
    policyDocument: {
      Version: '2012-10-17',
      Statement: [
        {
          Action: 'execute-api:Invoke',
          Resource: resource,
          Effect: effect,
        },
      ],
    },
    principalId,
  };
}

These steps outline the logic described earlier.

The authorizer function must return an IAM policy. If the checkpoint IDs match, the policy will Allow the request to proceed. If not, it will Deny it.

The principalId that identifies the user making the call is a mandatory attribute. The sub property from the token, the user’s unique ID in the user pool, serves this purpose and identifies the supervisor.

5. Considerations

As noted, Cognito groups are a practical way to organize supervisors by their checkpoint assignments.

If we wanted to adapt this approach for an application with a larger user base, creating and managing groups might become impractical.

In that case, we could store user details and their properties in a separate database like DynamoDB. The pre-token trigger function could then fetch the user’s profile from the database.

This setup might be easier to manage in a rapidly changing environment, though it adds an extra API call to the database, which could slow down the response time.

6. Summary

Combining a pre-token generation trigger with a custom API Gateway authorizer function allows for more sophisticated authorization flows.

The pre-token generation function adds custom details to the ID and access tokens. Then, a Lambda authorizer can enforce the custom authorization logic.

7. Further reading

Getting started with user pools - How to create a user pool with an app client

Adding groups to a user pool - The title says it all

Pre token generation Lambda trigger - Detailed reference for adding a trigger

Creating an app client - How to create an app client for a user pool

Get started with API Gateway - How to create an API Gateway resource

Create your first function - AWS Lambda "Getting started"

Manual Cognito user registration approvals with Step Functions

Arpad Toth — Thu, 13 Mar 2025 10:12:56 +0000

New user registration for an application that serves multiple users from the same organization might need manual approval. We can use Step Functions to build a serverless workflow for user confirmation.

1. Problem statement

Let’s say we have launched Awesome Application, a tool that stores documents for companies that subscribe to it. Multiple users from the same company can sign up and access shared company documents.

We’re using a Cognito user pool to manage users and issue tokens. The ID and access tokens from the user pool work with API Gateway, the entry point to Awesome Application, to authorize requests to endpoints.

Self-sign-up is enabled in Cognito. When new users register for Awesome Application, they provide:

Their email address, which doubles as their username for logging in later.
A strong password.
The name of the company they work for.

After signing up, users log in with their email address and password. The company name is not used in user login.

But there is an issue.

With an automated sign-up process, users could enter any company name and pretend to be an employee of that company. This would give them access to sensitive documents from any company they choose.

To address this, we set these rules:

Every user must be manually approved by an admin from their company. The admin verifies that the user works there.
There’s no automatic sign-up allowed.
Users must be added to their company’s Cognito group. When they log in, the tokens issued by the user pool will include the company name for authorization.

With these requirements in mind, let’s explore a possible solution.

2. Pre-requisites

This post will not cover the following:

Setting up a user pool with an app client and Lambda triggers in Cognito.
Creating IAM roles.
Building Lambda functions and configuring API Gateway.
Setting up SES to send emails.
Creating a DynamoDB table and adding data.
Designing a Step Functions state machine.
Writing front-end code with React and Amplify.

I will include links to relevant documentation below for anyone who needs them.

Also, the solution here is not ready for production. It’s meant for learning purposes, showing an idea and some patterns.

3. Architecture

This architecture focuses on the sign-up workflow.

We use a single Cognito user pool to store users and their companies. Once a company admin approves a user registration, the workflow adds the user to the right Cognito group. If the admin rejects the request or the company name is invalid, the user's directory status stays unconfirmed. Cognito blocks unconfirmed users from logging into the application.

The core of this setup is a Step Functions standard state machine that handles the manual approval step.

4. Digging deep

Let’s break down each part of the process.

4.1. User registration

Since self-sign-up is enabled, users can go to the Sign up page in Awesome Application and fill out the Create account form. They enter their email address, a password, and the name of the company they work for. To use the email as the username, we mark email as a Required attribute in the user pool.

If we want the company name in the tokens, we need a custom attribute in the user pool. Let’s call it company_name. This means the token will include a property called custom:company_name with the relevant value.

We also turn off Cognito’s automatic verification emails. With this feature enabled, Cognito sends new users an email to confirm their address, but we are handling approvals manually instead.

Unfortunately, Cognito does not allow us to make company_name a required attribute. We will need a workaround, like the one in this post, to handle that.

We set Email as the Cognito user pool sign-in option since users log in with their email addresses. Note that sign-in options and required attributes can’t be changed after we have created the user pool.

4.2. Using Amplify

Amplify’s built-in UI and login features don’t support our custom company_name field in the sign-up form, so we have to build the form ourselves.

That said, we can still use Amplify. It offers methods for sign-up, sign-in, and sign-out that handle Cognito API calls behind the scenes.

Here is part of a possible SignUp React component’s handleSignUp function, triggered when the user submits the form:

import { signUp } from "aws-amplify/auth";
// Other imports

// SignUp React component
function SignUp() {
  // ... set states here

  const handleSignUp = async (event) => {
    // Omitted for brevity
    await signUp({
      username: email, // Use email as the username
      password,
      options: {
        userAttributes: {
          email,
          "custom:company_name": companyName, // Our custom attribute
        },
      }
    });
  }

  // Create the form here
}

export default SignUp;

There are similar methods for sign-in and sign-out flows.

4.3. Pre-sign-up Lambda trigger

When the user submits the form, Amplify’s signUp method adds them to the Cognito user pool with an Unconfirmed status.

At this point, Cognito can trigger a pre-sign-up Lambda function. We use it to start the Step Functions workflow:

import { SFNClient, StartExecutionCommand } from "@aws-sdk/client-sfn";

const sfnClient = new SFNClient();

const { STATE_MACHINE_ARN } = process.env;

export const handler = async (event) => {
  const {
    userName, // This is the sub from the user pool
    userPoolId,
    request: {
      userAttributes: {
        "custom:company_name": companyName,
        email
      }
    }
  } = event;

  const stateMachineInput = {
    userName,
    companyName,
    email,
    userPoolId
  };

  const startExecutionCommand = new StartExecutionCommand({
    stateMachineArn: STATE_MACHINE_ARN,
    input: JSON.stringify(stateMachineInput),
    name: `NewUserRegistration-${userName}-${Date.now()}`
  });

  try {
    // Start the state machine execution asynchronously
    await sfnClient.send(startExecutionCommand);

    // Return the event object to allow sign-up to proceed
    // The user stays unconfirmed until approved
    return event;
  } catch (error) {
    throw error;
  }
};

The event object has everything we need to start the state machine and looks like this:

{
    "region": "eu-central-1",
    "userPoolId": "USER_POOL_ID",
    "userName": "029f515c-97db-4e3f-8905-f7b5b82db993", // Cognito user name (sub)
    "triggerSource": "PreSignUp_SignUp",
    "request": {
        "userAttributes": {
            "custom:company_name": "MyCompany",
            "email": "john.doe@mycompany.com"
        }
    }
    // ...other properties here
}

4.4. The state machine

The state machine uses JSONata syntax to manage variables and state inputs/outputs.

The StoreVariables state sets up variables that are available for each state in the workflow:

{
  "userName": "{% $states.input.userName %}",
  "companyName": "{% $states.input.companyName %}",
  "userPoolId": "{% $states.input.userPoolId %}",
  "userEmail": "{% $states.input.email %}"
}

This keeps us from passing these variables through every state, unlike with JSONPath.

Here are the main workflow steps.

4.4.a

The GetAdminsForCompany Lambda function queries a DynamoDB table that lists admins who can approve or deny registration requests for a company. A company might have multiple admins. In this case, all of them get the approval email.

The HasAdmin Choice state checks if there are admin emails for the company provided.

If there are none, say, because the user entered an invalid company name, the workflow deletes the user from the user pool using the AdminDeleteUser Cognito API. It also sends the user an email via SES saying the registration failed.

4.4.b

If GetAdminsForCompany finds admin emails, Step Functions calls the SendApprovalEmail function. Here is what that might look like:

import { SESClient, SendEmailCommand } from "@aws-sdk/client-ses";

const sesClient = new SESClient();

const { API_ENDPOINT, FROM_EMAIL } = process.env;

export const handler = async (event) => {
  const {
    userName,
    userPoolId,
    userEmail: email,
    adminEmails,
    executionContext
  } = event;
  const taskToken = executionContext.Task.Token;

  // Create approve/deny URLs
  const approveUrl = `${API_ENDPOINT}/confirm-registration?action=approve&token=${encodeURIComponent(taskToken)}`;
  const denyUrl = `${API_ENDPOINT}/confirm-registration?action=deny&token=${encodeURIComponent(taskToken)}`;

  const textBody = `
    New User Registration Requires Approval

    User Details:
    Username: ${userName}
    User Pool ID: ${userPoolId}
    Email: ${email}

    Actions:
    To approve: ${approveUrl}
    To deny: ${denyUrl}
  `;

  // Send email using SES
  const emailParams = {
    Destination: {
      ToAddresses: adminEmails,
    },
    Message: {
      Body: {
        Text: {
          Charset: "UTF-8",
          Data: textBody
        }
      },
      Subject: {
        Charset: "UTF-8",
        Data: `New User Registration - ${userName}`
      }
    },
    Source: FROM_EMAIL
  };

  const sendEmailCommand = new SendEmailCommand(emailParams);

  try {
    await sesClient.send(sendEmailCommand);
  } catch (error) {
    console.error("Error sending approval email:", error);
    throw error;
  }
};

The function’s event input looks like this:

{
  // From the previous state
  "adminEmails": "{% $states.input.adminEmails %}",
  // Variables from StoreVariables
  "userName": "{% $userName %}",
  "userPoolId": "{% $userPoolId %}",
  "userEmail": "{% $userEmail %}",
  // From the state’s context
  "executionContext": "{% $states.context %}"
}

This state handles the manual approval. We use Step Functions’ Wait for callback feature in this Task state, which adds a task token to the execution context.

The function builds approve and deny URLs with the task token, then sends an email to the admins via SES with those links.

4.4.c

The URLs point to an API Gateway endpoint backed by a Lambda function.

The SendApprovalEmail function included the task token in the URLs as a query parameter. The backend Lambda extracts it - along with the action parameter (approve or deny) - from the API Gateway event:

export const handler = async (event) => {
  const action = event.queryStringParameters.action;
  const taskToken = event.queryStringParameters.token;

  const message = action === "approve"
    ? { "Status": "Approved" }
    : { "Status": "Denied" };

  const input = {
    output: JSON.stringify(message),
    taskToken,
  };

  try {
    await sfnClient.send(new SendTaskSuccessCommand(input));
    return {
      statusCode: 200,
      body: JSON.stringify({ message: "Success!" }),
    };
  } catch (error) {
    throw error;
  }
};

Here is a key step: the function calls Step Functions’ SendTaskSuccess API with the task token and an output field. That output becomes the input for the next state - here, it’s just Approved or Denied. When Step Functions gets the task token, the workflow execution will resume.

4.5. Manual approval

The admin approves or denies the request by clicking the appropriate link in the email.

4.6. Approved or denied?

If the admin approves, Step Functions calls the AdminConfirmSignUp Cognito API to confirm the user, changing their status to Confirmed.

If the admin denies, this example uses a simple Pass state. You could replace it with a state to delete the user with AdminDeleteUser, as we did earlier, and notify them.

4.7. Post-confirmation Lambda trigger

Once the user is Confirmed, Cognito can trigger a post-confirmation Lambda function. This adds the user to their company’s group in the user pool:

import { CognitoIdentityProviderClient, AdminAddUserToGroupCommand } from "@aws-sdk/client-cognito-identity-provider";

const cognitoClient = new CognitoIdentityProviderClient();

export const handler = async (event) => {
  const userPoolId = event.userPoolId;
  const username = event.userName;
  const companyName = event.request.userAttributes["custom:company_name"];

  const command = new AdminAddUserToGroupCommand({
    UserPoolId: userPoolId,
    Username: username,
    GroupName: companyName,
  });

  try {
    await cognitoClient.send(command);
  } catch (error) {
    console.error("Error adding user to group:", error);
    // Retry or send a notification
  }

  return event;
};

That’s it! Next time the user logs in with their email and password, their tokens will include custom:company_name, ready for authorization.

5. Considerations

This solution doesn’t cover every detail of a production-ready system. Here are some things to keep in mind.

5.1. Permissions

Ensure the Step Functions state machine and Lambda functions have the right permissions for Cognito, DynamoDB, and SES.

5.2. Admin items and groups

This solution assumes admin emails and company groups already exist in DynamoDB and Cognito. Setting those up could be a separate process, maybe with API Gateway and Lambda endpoints for admins to add them before users sign up.

5.3. Error handling and retries

To keep things concise, I skipped error handling. In practice, you would need to add error checks and retries in the code, use Step Functions for retries, or send alerts via SNS, depending on your needs.

5.4. Company name spelling

Users might misspell their company name during sign-up. If so, the workflow rejects them because the input won’t match the corresponding items in the database.

You could leave it as is or add something like a type-ahead search to help.

5.5. Manual addition

Alternatively, admins could manually add users to Cognito and their company group via admin endpoints. Users would get a username and temporary password, which they would change on the first login. Tokens would still include company info, but you would skip the Step Functions workflow entirely.

This simpler approach cuts automation but might make sense if time is tight or explaining Step Functions to new developers feels tricky. I would still go with the workflow, though.

6. Summary

When users from the same company need access to shared documents in our app, automatic sign-ups might not be the best fit.

Instead, we can use Step Functions and Cognito Lambda triggers to build a workflow that includes manual approval for new users.

7. Further reading

Getting started with user pools - How to create a user pool with an app client

IAM role creation - How to create IAM roles

Create your first Lambda function - How to create Lambda functions

Set up your SES account - Using the SES Wizard to quickly set up the account

Set up email sending with Amazon SES - Different ways of sending emails with SES

Getting started with DynamoDB - DynamoDB basics

Learn how to get started with Step Functions - Step Functions tutorial

Authentication - Use Amplify with Cognito for authentication

DEV Community: Arpad Toth

Implementing protected Lambda function URLs in user-facing applications

Table of contents

1. The scenario

2. Authorization in API Gateway vs function URL

2.1. API Gateway (REST type)

2.2. Function URL

3. Architecture diagram

4. Architecture components

4.1. Cognito user pool

4.2. Cognito identity pool

4.3. Amplify

4.4. Function URL

5. Considerations

6. Summary

7. Further reading

Building a Dynamic Bedrock Model Selection Serverless Application

Table of contents

1. Context

2. The challenge

3. Architecture diagram

4. Code

4.1. Evaluation script

4.2. Infrastructure code

4.3. Backend code

4.4. Front-end code

4.5. GitHub

5. Considerations and limitations

5.1. Considerations

5.2. Limitations

6. Summary

7. Further reading

Building an end-to-end insurance claims app with Amazon Bedrock

Table of contents

1. Context

2. The challenge

3. Architecture diagram

3.1. Uploading the claim

3.2. Extracting the information

3.3. Summarizing the claim

3.4. Returning the response to the client

4. Code

4.1. Application code

4.2. Infrastructure code

4.3. Front end

4.4. GitHub

5. Considerations and limitations

6. Summary

7. Further reading

16 hands-on exercises to prepare for the AWS Certified CloudOps Engineer - Associate certification exam

Table of contents

1. About the exam

2. Considerations and prerequisites

2.1. AWS Organizations

2.2. Domain name

2.3. Cost considerations

2.4. On-premise environment

2.5. Bulk exercises

3. Disclaimer

4. The exercises

5. Summary

6. Further reading and learning

Updating data status with API Gateway WebSocket API

Table of contents

1. The scenario

2. Solution overview

2.1. Requirements

2.2. Options

2.3. Diagram

3. Pre-requisites

4. Main steps

4.1. Ingestion

4.2. Click data persistence

4.3. Dashboard connection

4.4. Persisting connection IDs

4.5. Retrieving data from the table

4.6. Broadcasting click data

4.7. Receiving click results

5. Considerations

5.1. No need for a REST API?