DEV Community: iAmSherif 💎

Migrating a Lambda to a Durable Lambda Function

iAmSherif 💎 — Sun, 01 Feb 2026 13:53:04 +0000

I migrated an AWS Lambda function that simulates a patient health insurance verification workflow into a Durable Lambda execution. The function verifies a patient’s insurance and proceeds to schedule a health-check appointment only when the verification succeeds.

At this point, you probably already understand what AWS Lambda is. This article focuses specifically on what changes when you migrate a Lambda function to a Durable Lambda, why those changes are necessary, and the errors you are likely to encounter if anything is misconfigured.

Prerequisite:
You should already understand how AWS Lambda works.

Before discussing durability, it’s important to understand the workflow itself.

In this flow, we can see that the function goes through a series of sequential steps to complete its work:

Validate Patient Information - Checks if patient ID and name are provided
Check Insurance Database - Simulates lookup in insurance database
Verify Insurance Coverage - Gets coverage details and limits
Authorize Health Check Procedures - Determines which procedures are covered
Schedule Health Checks - Creates appointment schedule for authorized procedures.

Each step depends on the successful completion of the previous one. This dependency chain is what makes durability valuable.

Before we dive deep, let's talk a bit about Durable Lambda Function.

What is a Durable Lambda Function?

A Durable Lambda function is still a Lambda function running inside the Lambda runtime. What changes is how execution is managed.

A durable function can run for up to one year, maintaining progress across failures, restarts, and retries, without incurring wait-time charges. This is achieved through a mechanism called a durable execution.

A durable execution uses checkpoints to track progress. If a failure occurs, the function is replayed from the beginning, but completed steps are skipped and their results reused.

Durable Lambda exposes special operations, most notably step and wait.

step executes business logic with built-in progress tracking and replay support.
wait pauses execution without consuming compute, which is useful for long-running or human-in-the-loop workflows.

Lambda vs Durable Lambda?

This is not a replacement. Durable Lambda still runs on Lambda.
What changes is the execution model. Durable Lambda improves:

Visibility into execution flow
Recovery from failures
Retry behavior
Developer experience when working with long or multi-step workflows

You are not switching platforms. You are adopting a stricter execution discipline.

Now that we've had a brief understanding of Durable Lambda function, let's dive into migrating our lambda function to durable lambda.

What the Lambda Function Looked Like

Before durability was introduced, the function followed a familiar sequential pattern. Everything happened inside a single invocation, and the only “state” was whatever lived in memory during execution.

Conceptually, the Lambda looked like this:

exports.handler = async (event) => {
    const body = typeof event.body === 'string' ?JSON.parse(event.body) : event.body;
    const patientId = body.patientId;
    const patientName = body.patientName;

    try {
        // Validate patient information
        if (!patientId || !patientName) {
            throw new Error('Invalid patient information');
        }

        // Check insurance
        const hasInsurance = await checkInsuranceStatus(patientId);

        if (!hasInsurance) {
            return {
                statusCode: 200,
                body: JSON.stringify({
                    patientId,
                    patientName,
                    status: 'REJECTED',
                    message: 'Patient does not have valid health insurance.'
                })
            };
        }

        // Verify coverage
        const coverage = await getInsuranceCoverage(patientId);

        // Authorize procedures
        const authorizedProcedures = await authorizeHealthChecks(coverage);

        // Schedule health checks
        const scheduledAppointments = await scheduleHealthChecks(
            patientId,
            authorizedProcedures
        );

        return {
            statusCode: 200,
            body: JSON.stringify({
                patientId,
                patientName,
                status: 'APPROVED',
                insuranceCoverage: coverage,
                authorizedProcedures,
                scheduledAppointments
            })
        };

    } catch (error) {
        return {
            statusCode: 500,
            body: JSON.stringify({
                patientId,
                patientName,
                status: 'ERROR',
                message: error.message
            })
        };
    }
};

This code is readable and easy to reason about, but it hides a critical weakness.

Every step is tightly coupled to the same execution. If the function times out, crashes, or is retried, everything restarts from the beginning. External systems are called again, and partial progress is lost.

This is the exact problem Durable Lambda solves.

Introducing Durable Execution

Below is the Durable Lambda version of the same function:

exports.handler = withDurableExecution(
    async (event, context) => {
        context.configureLogger({ customLogger, modeAware: false })
        const body = typeof event.body === 'string' ? JSON.parse(event.body) : event.body;
        const patientId = body.patientId;
        const patientName = body.patientName;

        try {
            context.logger.info('Step 1: Validating patient information', { patientId, patientName });

            if (!patientId || !patientName) {
                throw new Error('Invalid patient information');
            }

            const hasInsurance = await context.step('validate-patientid', async (stepContext) => {
                stepContext.logger.info('Validating user claims')
                return await checkInsuranceStatus(patientId);
            })

            if (!hasInsurance) {
                return {
                    statusCode: 200,
                    body: JSON.stringify({
                        patientId,
                        patientName,
                        status: 'REJECTED',
                        message: 'Patient does not have valid health insurance.'
                    })
                };
            }

            const coverage = await context.step('verify-insurance', async (stepContext) => {
                stepContext.logger.info('Verify insurance coverage')
                return await getInsuranceCoverage(patientId);
            })

            const authorizedProcedures = await context.step(
                'authorize-health-checks',
                async (stepContext) => {
                    stepContext.logger.info('Authorize health check procedures')
                    return await authorizeHealthChecks(coverage);
                }
            )

            const scheduledAppointments = await context.step(
                'schedule-health-checks',
                async (stepContext) => {
                    stepContext.logger.info('Schedule health checks')
                    return await scheduleHealthChecks(patientId, authorizedProcedures);
                }
            )

            return {
                statusCode: 200,
                body: JSON.stringify({
                    patientId,
                    patientName,
                    status: 'APPROVED',
                    insuranceCoverage: coverage,
                    authorizedProcedures,
                    scheduledAppointments
                })
            };

        } catch (error) {
            return {
                statusCode: 500,
                body: JSON.stringify({
                    patientId,
                    patientName,
                    status: 'ERROR',
                    message: error.message
                })
            };
        }
    }
);

At first glance, the business logic looks almost identical. That similarity is intentional. Durable Lambda is designed so you do not have to rewrite your domain logic from scratch.

The real change is where durability is introduced.

What Actually Changed?

The most important difference is the withDurableExecution wrapper. This single addition changes the execution model of the function. Instead of treating the handler as a one-shot computation, it turns it into a resumable workflow. The function can now pause, fail, retry, and resume without losing progress.

The second major change is the introduction of context.step from DurableContext. In the Lambda, each async call simply executes and returns. In the durable version, every critical operation is wrapped in a named step. That name is not cosmetic. It becomes the durable checkpoint that allows the runtime to remember, “this work has already been completed.”

For example, insurance validation used to be just this:

await checkInsuranceStatus(patientId);

In the durable version, it becomes:

await context.step('validate-patientid', async () => {
    return await checkInsuranceStatus(patientId);
});

This single change prevents duplicate calls when retries happen. If the function crashes after this step succeeds, Durable Lambda does not re-run it. It replays the stored result and moves forward.

Logging also changes subtly but importantly. Instead of relying on global logging assumptions, logging is now tied to execution context and step context. This is why logging behavior felt different after migration. The function is no longer guaranteed to run once from top to bottom; parts of it may be replayed.

THAT'S ALL FOR THE FUNCTION CODE REFACTORING

Infrastructure Configuration Matters

Durable Lambda is not only about code. It requires explicit infrastructure configuration.
Your lambda function configuration might look like this:

const patientHealthCheckFunction = new Function(this, 'PatientHealthCheckFunction', {
      runtime: Runtime.NODEJS_20_X,
      handler: 'index.handler',
      code: Code.fromAsset('lambda-package'),
      timeout: Duration.seconds(30),
      environment: {
        NODE_ENV: 'production',
        LOG_LEVEL: 'INFO',
      }
    });

In the above configuration, the function uses Lambda's NodeJS 20 runtime, identifies the handler, navigates to the function, set timeout limit, and attaches some env variables that would be used by the function code.
When migrating to Durable Lambda, you must:

Use a supported runtime (Node.js 22 or 24)
Assign a role that allows checkpointing
Configure durableConfig
Use versions and aliases

Misconfigurations lead directly to runtime errors.

I will walk you through actual errors that occurs when your durable function isn't configured properly and also we going to discuss each of their fixes.

Error #1: Durable Execution Would Not Start

The first failure happened immediately after deployment:

Unexpected payload provided to start the durable execution. Check your resource configurations to confirm the durability is set.

This error had nothing to do with business logic. Durable Lambda requires its configuration to be explicitly enabled in infrastructure. Without that configuration, the runtime treats the function like a normal Lambda and rejects the durable execution payload.

durableConfig: { executionTimeout: Duration.hours(1), retentionPeriod: Duration.days(30) }

Once configured with an execution timeout and retention period, the function was able to start durable execution correctly.

This was the first signal that Durable Lambda is not just a code change; it is an execution contract enforced at the infrastructure level.

Error #2: Synchronous Invocation Still Has Limits

After enabling durability, the next error appeared:

You cannot synchronously invoke a durable function with an executionTimeout greater than 15 minutes.

When invoked synchronously, a durable function must still complete within 15 minutes. Reducing the execution timeout resolved the issue.

durableConfig: { executionTimeout: Duration.minutes(10), retentionPeriod: Duration.days(30) }

This reinforced an important point: Durable Lambda adds persistence, not infinite runtime.

Error #3: Permission Error

The next failure was caused by permission error:

Failed to checkpoint durable execution. User is not authorized to perform lambda:CheckpointDurableExecution on resource arn:aws:… because no identity-based policy allows the lambda:CheckpointDurableExecution action

Durable Lambda requires explicit IAM permissions to store and retrieve execution state.

    lambdaRole.addToPolicy(
      new iam.PolicyStatement({
        actions: [
          'lambda:CheckpointDurableExecution',
          'lambda:GetDurableExecutionState',
          'lambda:InvokeFunction',
        ],
        resources: [
          `arn:aws:lambda:${this.region}:${this.account}:function:PatientHealthCheckStack*`,
        ],
      })
    );

Without these permissions, durability silently fails.

What changed after migration

Area	Before	After Durable Lambda
State handling	Stateless	Persistent
Retries	Restart entire flow	Resume from failure
Invocation rules	Flexible	Strict but safer
Versioning	Optional	Required
Observability	Simple	Needs discipline

Conclusion

Migrating to Durable Lambda did not make the system simpler; it made it more explicit.

Failures stopped being destructive. Retries stopped being accidental. Progress became something the system could reason about instead of guess. The workflow shifted from “hope this finishes” to “this will eventually complete correctly.”

Durable Lambda is not something you reach for by default. But when your Lambda function starts behaving like a workflow—multi-step, failure-prone, and externally dependent, durability stops being optional.

At that point, it becomes a design decision about correctness.

And in systems like healthcare workflows, correctness is the only acceptable outcome.

——————————————

For more articles, follow my social handles:

A Step-by-Step Guide to Deploying CrewAI on Amazon Bedrock AgentCore

iAmSherif 💎 — Sun, 03 Aug 2025 21:12:02 +0000

In 2024, I built Curiouser an agent-to-agent (A2A) application using CrewAI with the Ollama LLM. It was my first real experience orchestrating multiple agents in a single app. As someone curious about agentic frameworks, CrewAI felt intuitive and developer-friendly.

But I ran into limitations. I was running the application locally on my 8GB RAM AMD Ryzen laptop with a 256GB SSD, and it will take an average of 2–3 hours to complete a run (no bluff). Plus, I couldn’t take it beyond my local machine.

Then AWS announced Amazon Bedrock AgentCore at the New York Summit — and it felt like it was built for people like me. It's a serverless runtime for deploying and operating AI agents securely at scale, using any framework, including CrewAI, LangGraph, LlamaIndex, and Strands Agents, as well as any foundation model in or outside of Amazon Bedrock, without managing infrastructure. So I decided to migrate my local CrewAI app to production using this new service.

This blog post is a step-by-step guide for doing exactly that.

Note: This guide assumes you already have a working CrewAI application. I’ll only walk you through the changes needed to get it running on Bedrock AgentCore.

What I Built

I built Curiouser — a multi-agent AI application designed for curious minds.

It provides detailed yet concise summaries of tech topics.
It generates test questions to help you evaluate your understanding.
It uses three cooperating agents, each with a different role.
I switched from Ollama to the Amazon Bedrock Nova Pro model.
It also stores user-generated content in Amazon S3.

Prerequisites

To follow along, you'll need:

A working CrewAI app
An AWS account with access to:
- Amazon Bedrock
- Bedrock AgentCore
- S3
Python 3.10+
Docker installed and running
AWS CLI installed and configured
bedrock-agentcore and bedrock-agentcore-starter-toolkit Python packages

Step 1 - Update Your Agents to Use a Bedrock-Supported LLM

Bedrock AgentCore supports only Amazon Bedrock-compatible foundational models. You’ll need to update your CrewAI agents to use one of these.

Check out the supported models here.

Step 2 - Create a Remote Entrypoint for Bedrock AgentCore

We'll convert your local app into a remote one by modifying the entrypoint. Here's what to do:

Import AgentCore:

   from bedrock_agentcore.runtime import BedrockAgentCoreApp

Initialize the runtime app:

   app = BedrockAgentCoreApp()

Define the entrypoint handler:

   @app.entrypoint
   def app_entry(payload, context):
       """Handle agent invocations"""
       try:
           user_message = payload.get("prompt", "Web3")
           result = crew.kickoff(inputs={'topic': user_message})
           return {"result": result.raw}
       except Exception as e:
           return {"error": str(e)}

Run the app:

   if __name__ == "__main__":
       app.run()

AgentCore automatically:

Sets up an HTTP server on port 8080
Exposes /invocations and /ping endpoints
Manages content types, responses, and errors

Step 3 - Configure IAM Role for AgentCore

You’ll need a dedicated IAM role that allows your agent to run in the cloud. Below is a Bash script I wrote to:

Create a trust policy
Create permissions policy
Attach the permissions policy
Grant access to ECR, Bedrock Agentcore, and Bedrock

The script also configures your agent with AgentCore:
agentcore configure --entrypoint src/curiouser/main.py -er <ROLE_ARN>


#!/bin/bash

# Setup script for CrewAI with Amazon Bedrock AgentCore
# This script creates the necessary IAM role and configures agentcore

set -e  # Exit on any error

# Configuration variables
ROLE_NAME="Curioser-CrewAI-BedrockAgentCore-Role"
POLICY_NAME="Curioser-CrewAI-BedrockAgentCore-Policy"
TRUST_POLICY_FILE="trust-policy.json"
PERMISSIONS_POLICY_FILE="permissions-policy.json"
ENTRYPOINT_FILE="src/curiouser/main.py"


NC='\033[0m'

echo -e "Setting up CrewAI with Amazon Bedrock AgentCore${NC}"

# Check if AWS CLI is installed and configured
if ! command -v aws &> /dev/null; then
    echo -e "❌ AWS CLI is not installed. Please install it first.${NC}"
    exit 1
fi

# Get AWS account ID and region
echo -e "📋 Getting AWS account information...${NC}"
ACCOUNT_ID=$(aws sts get-caller-identity --query Account --output text)
REGION=$(aws configure get region)

if [ -z "$REGION" ]; then
    echo -e "⚠️  No default region set. Using us-east-1${NC}"
    REGION="us-east-1"
fi

echo -e "✓ Account ID: $ACCOUNT_ID"
echo -e "✓ Region: $REGION"

# Create trust policy for the IAM role
echo -e "📝 Creating trust policy..."
cat > $TRUST_POLICY_FILE << EOF
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AssumeRolePolicy",
      "Effect": "Allow",
      "Principal": {
        "Service": "bedrock-agentcore.amazonaws.com"
      },
      "Action": "sts:AssumeRole",
      "Condition": {
            "StringEquals": {
                "aws:SourceAccount": "$ACCOUNT_ID"
            },
            "ArnLike": {
                "aws:SourceArn": "arn:aws:bedrock-agentcore:$REGION:$ACCOUNT_ID:*"
            }
       }
    }
  ]
}

EOF

# Create permissions policy with dynamic values
echo -e "📝 Creating permissions policy..."
cat > $PERMISSIONS_POLICY_FILE << EOF
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "ECRImageAccess",
            "Effect": "Allow",
            "Action": [
                "ecr:BatchGetImage",
                "ecr:GetDownloadUrlForLayer"
            ],
            "Resource": [
                "arn:aws:ecr:$REGION:$ACCOUNT_ID:repository/*"
            ]        
        },
        {
            "Effect": "Allow",
            "Action": [
                "logs:DescribeLogStreams",
                "logs:CreateLogGroup"
            ],
            "Resource": [
                "arn:aws:logs:$REGION:$ACCOUNT_ID:log-group:/aws/bedrock-agentcore/runtimes/*"
            ]
        },
        {
            "Effect": "Allow",
            "Action": [
                "logs:DescribeLogGroups"
            ],
            "Resource": [
                "arn:aws:logs:$REGION:$ACCOUNT_ID:log-group:*"
            ]
        },
        {
            "Effect": "Allow",
            "Action": [
                "logs:CreateLogStream",
                "logs:PutLogEvents"
            ],
            "Resource": [
                "arn:aws:logs:$REGION:$ACCOUNT_ID:log-group:/aws/bedrock-agentcore/runtimes/*:log-stream:*"
            ]
        },
        {
            "Sid": "ECRTokenAccess",
            "Effect": "Allow",
            "Action": [
                "ecr:GetAuthorizationToken"
            ],
            "Resource": "*"
        },
        {
            "Effect": "Allow", 
            "Action": [ 
                "xray:PutTraceSegments", 
                "xray:PutTelemetryRecords", 
                "xray:GetSamplingRules", 
                "xray:GetSamplingTargets"
            ],
            "Resource": [ "*" ] 
        },
        {
            "Effect": "Allow",
            "Resource": "*",
            "Action": "cloudwatch:PutMetricData",
            "Condition": {
                "StringEquals": {
                    "cloudwatch:namespace": "bedrock-agentcore"
                }
            }
        },
        {
            "Sid": "GetAgentAccessToken",
            "Effect": "Allow",
            "Action": [
                "bedrock-agentcore:GetWorkloadAccessToken",
                "bedrock-agentcore:GetWorkloadAccessTokenForJWT",
                "bedrock-agentcore:GetWorkloadAccessTokenForUserId"
            ],
            "Resource": [
                "arn:aws:bedrock-agentcore:$REGION:$ACCOUNT_ID:workload-identity-directory/default",
                "arn:aws:bedrock-agentcore:$REGION:$ACCOUNT_ID:workload-identity-directory/default/workload-identity/agentName-*"
            ]
        },
        {
            "Sid": "BedrockModelInvocation", 
            "Effect": "Allow", 
            "Action": [ 
                "bedrock:InvokeModel", 
                "bedrock:InvokeModelWithResponseStream"
            ], 
            "Resource": [
                "arn:aws:bedrock:*::foundation-model/*",
                "arn:aws:bedrock:$REGION:$ACCOUNT_ID:*"
            ]
        }
    ]
}
EOF

# Check if role already exists
echo -e "🔍 Checking if IAM role exists...${NC}"
if aws iam get-role --role-name $ROLE_NAME &> /dev/null; then
    echo -e "⚠️  Role $ROLE_NAME already exists. Updating policies...${NC}"

    # Update the role's trust policy
    aws iam update-assume-role-policy --role-name $ROLE_NAME --policy-document file://$TRUST_POLICY_FILE

    # Delete existing inline policy if it exists
    aws iam delete-role-policy --role-name $ROLE_NAME --policy-name $POLICY_NAME &> /dev/null || true
else
    echo -e "🔨 Creating IAM role..."
    aws iam create-role \
        --role-name $ROLE_NAME \
        --assume-role-policy-document file://$TRUST_POLICY_FILE \
        --description "IAM role for CrewAI with Bedrock AgentCore"
fi

# Attach the permissions policy
echo -e "${YELLOW}📎 Attaching permissions policy...${NC}"
aws iam put-role-policy \
    --role-name $ROLE_NAME \
    --policy-name $POLICY_NAME \
    --policy-document file://$PERMISSIONS_POLICY_FILE

# Get the role ARN
ROLE_ARN=$(aws iam get-role --role-name $ROLE_NAME --query 'Role.Arn' --output text)
echo -e "✓ IAM Role ARN: $ROLE_ARN"

# Check if src/curiouser/main.py exists
if [ -f "$ENTRYPOINT_FILE" ]; then
    echo -e "✓ Entrypoint file $ENTRYPOINT_FILE already exists and is configured for Bedrock AgentCore"
else
    echo -e "❌ Entrypoint file $ENTRYPOINT_FILE not found. Please ensure your CrewAI project structure is correct."
    exit 1
fi

# Wait a moment for IAM role to propagate
echo -e "⏳ Waiting for IAM role to propagate..."
sleep 10

# Configure agentcore
echo -e "🔧 Configuring agentcore..."
if command -v agentcore &> /dev/null; then
    agentcore configure --entrypoint $ENTRYPOINT_FILE -er $ROLE_ARN
    echo -e "✓ AgentCore configured successfully!"
else
    echo -e "❌ agentcore command not found. Please install the Bedrock AgentCore CLI first."
    echo -e "💡 You can install it with: pip install bedrock-agentcore-cli"
    echo -e "📋 Manual configuration command:"
    echo -e "agentcore configure --entrypoint $ENTRYPOINT_FILE -er $ROLE_ARN"
fi

Attach the policy that your project needs

Step 4 - Generate Docker Configuration with AgentCore command

The command:

agentcore configure --entrypoint src/curiouser/main.py -er <ROLE_ARN>

This will:

Generate a Dockerfile and .bedrock_agentcore.yaml
Create a .bedrock_agentcore.yaml configuration file
Prepare our application for containerization

Important Fix

The generated Dockerfile doesn’t install bedrock_agentcore, so be sure to add else you will run into a dependency error:

RUN pip install bedrock_agentcore

Your Dockerfile should look like this:

FROM public.ecr.aws/docker/library/python:3.10-slim
WORKDIR /app

COPY . .

RUN pip install .
RUN pip install bedrock_agentcore
RUN pip install aws-opentelemetry-distro>=0.10.0

ENV AWS_REGION=<your-region>
ENV AWS_DEFAULT_REGION=<your-region>
ENV DOCKER_CONTAINER=1

RUN useradd -m -u 1000 bedrock_agentcore
USER bedrock_agentcore

EXPOSE 8080
CMD ["opentelemetry-instrument", "python", "-m", "src.app.main"]

Step 5 - Launch the Agent to the Cloud

Once everything is ready, run:

agentcore launch

This command will:

Build the Docker image
Push it to Amazon ECR
Create a Bedrock AgentCore runtime
And deploy your agent to the cloud

Step 6 - Test Your Deployed Agent

Use the CLI to invoke your agent:

agentcore invoke '{"prompt": "Hello"}'

Or test directly from the AWS Console.

Final Thoughts

That’s it, you’ve just seen how to take a multi-agent CrewAI application from local development to a cloud-native, production-ready deployment using Amazon Bedrock AgentCore.

Personally, moving from a painfully slow, local setup on limited hardware to a serverless runtime that scales, monitors, and secures my workload automatically was a game-changer. No more babysitting long processes or worrying about whether my laptop will crash before the task finishes. With Amazon Bedrock AgentCore, deployment is fast, observability is built-in, and your agentic logic becomes accessible from anywhere, anytime.

For developers building serious agentic applications, especially multi-agent systems with orchestration and external data workflows. Amazon Bedrock AgentCore unlocks scalability and reliability without the traditional ops overhead. And because it’s part of the AWS ecosystem, integrating other services like S3, CloudWatch, and IAM is straightforward and secure.

Whether you’re:

Building a knowledge assistant like Curiouser,
Orchestrating tools and LLMs across complex workflows,
Experimenting with autonomous agents in a safe and scalable environment,

Amazon Bedrock AgentCore gives you a strong foundation to focus on the intelligence of your application, not the plumbing.

If you’ve already got a local CrewAI project up and running, there’s no better time to bring it to life in the cloud.

Let me know if you try this out or run into any blockers — always happy to connect with fellow builders.

References

——————————————

For more articles, follow my social handles:

How to capture data changes in DynamoDB using Streams and Lambda (Node.js + AWS CDK)

iAmSherif 💎 — Tue, 15 Jul 2025 00:18:34 +0000

One of the biggest advantages of serverless services is their event-driven nature. When something (an event) happens, another service reacts. DynamoDB is a serverless NoSQL database that fits perfectly into this pattern. It allows you to build scalable, event-driven applications that respond to changes in your data in near real time.

In this article, I’ll show you how to capture data changes in DynamoDB using DynamoDB Streams, and then use the stream as an event source to a Lambda function, which then logs the stream information to CloudWatch Logs, all implemented using Node.js and AWS CDK as Iac.

Why Capture Data Changes?

Before we dive into the implementation, let’s consider a few use cases where capturing data changes can be valuable:

Audit logging: Keep track of item-level changes for compliance or debugging.
Triggering side effects: Send notifications, update search indexes, or replicate data in real time.
Analytics: Track user behavior or system events as they happen.
Data synchronization: Sync changes between microservices or external systems.

How DynamoDB Streams Work

When you enable Streams on a DynamoDB table, DynamoDB records every item-level change (creates, updates, and deletes) in a time-ordered sequence.

Each stream record contains:

The primary key of the modified item
Metadata about the operation (INSERT, MODIFY, REMOVE)
Optional “before” and “after” images of the data (if configured)

These stream records are stored for up to 24 hours and can be read by AWS services like Lambda, which you can set up to react to each change automatically.

What We’ll Build

We’ll create:

A DynamoDB table with Streams enabled
A Lambda function that listens to the stream
Logging of the change details to CloudWatch Logs

So Let’s Get Started

1. Define a DynamoDB Table with Stream Enabled

import { AttributeType, StreamViewType, Table } from 'aws-cdk-lib/aws-dynamodb';

const table = new Table(this, 'MyTable', {
  partitionKey: { name: 'id', type: AttributeType.STRING },
  stream: StreamViewType.NEW_AND_OLD_IMAGES, // Enables streams with both before/after images
  // Other configuration
});

Stream View Types

The StreamViewType determines what data is recorded in the stream for each item change:

KEYS_ONLY – Only the primary key attributes are written to the stream.
NEW_IMAGE – The entire item, as it appears after the modification, is written to the stream.
OLD_IMAGE – The item as it appeared before the modification is written to the stream.
NEW_AND_OLD_IMAGES – Both the new and old versions of the item are included.

2. Create a Lambda Function to Handle Stream Events

import { Function, Runtime, Code } from 'aws-cdk-lib/aws-lambda';
import { LambdaIntegration } from 'aws-cdk-lib/aws-apigateway';
import * as path from 'path';

const streamHandler = new Function(this, 'StreamHandlerFunction', {
  runtime: Runtime.NODEJS_20_X,
  handler: 'index.handler',
  code: Code.fromAsset(path.join(__dirname, '../lambda')),
});

Sample index.js Lambda code:

import { unmarshall } from '@aws-sdk/util-dynamodb';

export const handler = async (event) => {
  for (const record of event.Records) {
    const newImage = record.dynamodb.NewImage
      ? unmarshall(record.dynamodb.NewImage)
      : null;
    const oldImage = record.dynamodb.OldImage
      ? unmarshall(record.dynamodb.OldImage)
      : null;

    console.log('Event Type:', record.eventName);
    console.log('New Image:', JSON.stringify(newImage));
    console.log('Old Image:', JSON.stringify(oldImage));
  }

  return { statusCode: 200 };
};

Why do we use `unmarshall`?

When DynamoDB Streams triggers our Lambda function, it passes the item images in DynamoDB JSON format, which looks like this:

{
  "id": { "S": "asdf" },
  "uuid": { "S": "foo" },
  "status": { "S": "new" }
}

To work with standard JavaScript objects, we use the unmarshall utility from @aws-sdk/util-dynamodb. This transforms the DynamoDB JSON into a regular JavaScript object:

{
  "id": "asdf",
  "uuid": "foo",
  "status": "new"
}

This makes it easier to log or manipulate the data in our code.

3. Connect the Stream to Lambda

To allow our Lambda function to process events from the DynamoDB stream, we need to do two things:

Grant the Lambda the proper execution role permission to read from the stream
Register the DynamoDB table as an event source

// Grant the Lambda the proper execution role permission to read from the stream
table.grantStreamRead(streamHandler);

// Attach DynamoDB stream as an event source
streamHandler.addEventSource(new DynamoEventSource(table, {
  startingPosition: StartingPosition.LATEST,
  batchSize: 5,
  retryAttempts: 2,
}));

Configuration Options

startingPosition – Defines where the Lambda function should start reading the stream (e.g., LATEST for new records only).
batchSize – The maximum number of records to send to the function in a single invocation. The Lambda will receive all these records in the event payload.
retryAttempts – The maximum number of times Lambda will retry a failed batch before discarding or sending it to a dead-letter destination (if configured).

Conclusion

By using DynamoDB Streams, you can build powerful real-time event-driven systems with minimal operational overhead. In this example, we simply logged data changes to CloudWatch, but you can extend this to trigger notifications, sync systems, or persist audit logs to S3.

——————————————

For more articles, follow my social handles:

Deploying a Static E-commerce Site to AWS Using Pulumi

iAmSherif 💎 — Sat, 05 Apr 2025 20:47:40 +0000

This is a submission for the Pulumi Deploy and Document Challenge: Fast Static Website Deployment

What I Built

I built and deployed Ticaz Bags & Luggage, a sleek and modern static e-commerce website where users can browse and shop for stylish bags and durable luggage. The website features clean UI, responsive design, and smooth navigation, all tailored to create an enjoyable online shopping experience.

To bring this project to life, I used Pulumi to set up the entire cloud infrastructure on AWS from scratch. This includes:

An S3 bucket for hosting the static build
A CloudFront distribution for fast and secure global content delivery
Proper IAM roles and bucket policies for access control and caching
A well-structured Pulumi stack for consistent, repeatable deployments All of which are fully-managed by Pulumi

The site was developed using React, Vite, and Tailwind CSS, offering fast performance and responsive design.

This project was both a dev and DevOps learning experience, combining frontend polish with cloud-native deployment!

In this post, I’ll walk you through my journey and how you, too, can deploy a static website to AWS using Pulumi as Infrastructure as Code (IaC).

Live Demo Link

Access the live site via the CDN link below:
-> https://dyk9aqch11ytc.cloudfront.net/

Project Repo

🔗 GitHub – Ticaz Bags & Luggage

The repo includes the full frontend source code and the Pulumi configuration used to deploy it. The README includes setup instructions and deployment steps.

My Journey

Before this challenge, I already had the Ticaz Bags & Luggage website built, but it hadn’t yet been deployed to AWS. I discovered the Pulumi Static Website Template for AWS and followed the guide to get everything deployed smoothly.

Along the way, I learned that there are two main ways to connect your static build to your Pulumi project:

✅ Option 1: Use `pulumi config set path` via CLI

This method lets you set the path to your static build folder (like dist/) using the CLI. For example:

pulumi config set path /home/user/Documents/codes/frontend/dist

💡 In my case, I first ran npm run build inside the frontend project, which generated the /dist folder.

This command updates your Pulumi.<stack-name>.yaml file, and Pulumi uses that path when deploying to S3.

It’s quick and easy, but note that your frontend code stays outside the Pulumi project. So while your build is deployed, your local project structure remains disconnected.

✅ Option 2: Move the frontend into your Pulumi project

With this approach, I moved the built frontend folder into the Pulumi project directory (e.g., www/frontend/dist) and manually edited the Pulumi YAML config like this:

<stack-name>:path: www/frontend/dist

This allowed me to keep my infrastructure and app code together, making it easier to maintain and understand everything in one place.

🧠My Decision

I tested both approaches, and while they both worked, I ultimately chose the second method. Here's why:

I had better control over the deployment
My infrastructure and frontend code lived together in one repo
I could track everything more cleanly with version control

It gave me a clearer understanding of how Pulumi interacts with the application build and made debugging and updating easier going forward.

Using Pulumi

Pulumi made the deployment process seamless, structured, and developer-friendly. I didn’t have to worry about manually setting up S3 buckets, configuring IAM permissions, or writing extensive boilerplate IaC code from scratch.

Here’s how I used Pulumi in this project:

Infrastructure as Code: I provisioned AWS resources like S3 and CloudFront using Pulumi’s TypeScript SDK. Everything was version-controlled and easy to manage.
Simple Configuration: My main task was linking the application’s build folder (the /dist directory) to the Pulumi project. Once connected, Pulumi handled the rest—uploading the files, configuring the CDN, and setting proper access.
Automation: With just one command (pulumi up), I could deploy changes, test updates, or even roll back pulumi cancel when needed—no AWS Console clicking required.

Conclusion: Pulumi enabled me to streamline deployment without getting entangled in low-level infrastructure tasks. It’s a powerful tool for full-stack and solo developers who want to manage cloud infrastructure with familiar programming languages and clean, version-controlled code.

How to set up CORS in AWS Lambda and API Gateway (RestApi)

iAmSherif 💎 — Thu, 06 Feb 2025 15:25:47 +0000

Cross-Origin Resource Sharing (CORS) is a security feature implemented by web browsers that restricts how resources on a web server can be requested from a different domain. When building serverless applications using AWS Lambda and API Gateway, you need to configure CORS properly to allow client applications from different origins to access your API.

CORS is enforced at the browser level. When you deploy a REST API service to a domain, the browser must agree to the service's terms before communicating with it.

Imagine you have a Lambda backend service exposed through API Gateway's REST API. You integrate this API into your client application using communication services like Axios or JavaScript's fetch. You expect it to work smoothly because you've tested it with API testing tools such as Postman or even the AWS Management Console. But then poof! a strange 403 error appears. Why is this happening?

Why Do You Get a CORS Error from the Browser?

The reason is simple: unlike tools like Postman that make direct requests, browsers enforce the same-origin policy as a security measure. If your frontend is hosted on https://frontend.com and it tries to fetch data from https://api.com, the browser blocks the request unless the API explicitly allows it.

CORS settings in API Gateway define whether such cross-origin requests should be permitted. The key configurations involve setting allowed origins, HTTP methods, and headers.

Understanding the Request Flow: Preflight and Actual Requests

When a client’s browser makes a request to an API hosted on a different origin, the process typically involves two steps: The Preflight Request and the Actual Request.

Preflight Request:

Before sending the actual request, the browser sends an OPTIONS request to the API.

This request asks the server: “Am I allowed to send this request? If so, what methods and headers can I use?”

API Gateway (if configured correctly) responds with the allowed origins, methods, and headers.

Actual Request:

Once the browser receives a successful response from the preflight check, it proceeds to send the actual request (GET, POST, etc.) to the API.

If the API response includes the required CORS headers, the browser allows the data to be accessed by the client application.

Without proper CORS settings, the browser will block the request at the preflight stage, preventing the client from communicating with the API.

Setting Up CORS in AWS API Gateway and Lambda in (CDK)

There are two places you are required to set your headers in other for the two requests (Preflight and Actual) to be successful.

First, Set up defaultCorsPreflightOptions in your API-Gateway.

const restApi = new RestApi(this, `YourApi`, {
      defaultCorsPreflightOptions: {
        allowOrigins: 'https://frontend.com',
        allowMethods: ['GET', 'POST', 'OPTIONS'],
        allowHeaders: [
          'Content-Type',
          'Authorization',
          'Accept',
          'X-Requested-With'
        ],
        allowCredentials: true,
      },
    });

defaultCorsPreflightOptions: adds a CORS preflight configuration to this resource and all child resources.

allowOrigins: Defines the permitted origins for requests to this resource. To allow all origins, use Cors.ALL_ORIGINS or [*]. The response will include the Access-Control-Allow-Origin header, and if Cors.ALL_ORIGINS is used, the Vary: Origin header will also be included.
allowMethods: The Access-Control-Allow-Methods response header defines the permitted HTTP methods for a resource in response to a preflight request. Here, only GET, POST, and OPTIONS are allowed, enforcing the principle of least privilege by restricting access to necessary methods. If ANY is specified, it will be expanded to Cors.ALL_METHODS.
allowHeaders: The Access-Control-Allow-Headers response header specifies the allowed HTTP headers in response to a preflight request, based on the Access-Control-Request-Headers.

allowCredentials: The Access-Control-Allow-Credentials response header determines whether the response is accessible to frontend JavaScript when the request's credentials mode is set to "include". If true, browsers expose the response only when credentials (cookies, authorization headers, or TLS client certificates) are included.

In API Gateway, this ensures a successful preflight request but does not guarantee the actual request's success.

Why? Because the API response does not include the necessary CORS headers. How can we fix that?

Second, Add CORS headers to your lambda response.

exports.handler = async (event) => {
  return {
    statusCode: 200,
    headers: {
      "Access-Control-Allow-Origin": "*", // Allow all origins
      "Access-Control-Allow-Methods": "GET,OPTIONS",
      "Access-Control-Allow-Headers": "Content-Type,Authorization",
    },
    body: JSON.stringify({ message: "We Are Fixing CORS!" }),
  };
};

We added CORS headers to the Lambda response. After a successful preflight request, the browser verifies these headers in the actual response. If present, the data becomes accessible.

Conclusion

Setting up CORS for AWS Lambda and API Gateway is crucial when exposing APIs to frontend applications hosted on different domains. By configuring API Gateway’s preflight options and ensuring Lambda responses include CORS headers, you can successfully enable cross-origin access.

——————————————

For more articles, follow my social handles:

How to validate requests when using AWS Lambda Function Url

iAmSherif 💎 — Sun, 08 Dec 2024 07:57:31 +0000

Introduction

A Lambda function URL is a built-in HTTPS endpoint for an AWS Lambda function. It allows you to directly invoke a Lambda function over HTTP without needing an intermediary service like API Gateway. This simplifies deployments when your function needs to be publicly accessible or integrated into web applications. Validating requests with Lambda Function URLs offers unique challenges and nuances, unlike API Gateway where you can use Model and RequestValidator See.

In this article, I will guide you on how you can simply validate your event object and as well return appropriate error if there is mismatch in received event payload.

Why do you need Lambda Function Url

A Lambda function URL is a dedicated endpoint with a unique URL that provides a straightforward way to call a Lambda function over HTTP. When you create a Lambda function URL, AWS automatically generates a URL for the function, and you can configure IAM-based authentication or leave it public (for open access).

Importance of Lambda Function Url are:

Simplicity: Removes the need to set up and manage an API Gateway when you only need a simple HTTP endpoint.
Cost-Effective: Reduces costs compared to using API Gateway for basic use cases since Lambda function URLs have no additional charges beyond standard Lambda pricing.
Quick Deployment: Ideal for rapid prototyping or use cases where setting up API Gateway is unnecessary.
Native HTTPS Support: Provides secure communication without extra configuration.
Authentication Control: Supports IAM-based authentication for secure access or can be set to public for open endpoints.

When would you need Lambda Function Url

Microservices and Webhooks:
- Easily create microservices that respond to HTTP requests.
- Use Lambda function URLs to handle webhook callbacks from third-party services (e.g., payment systems, notifications).
Prototyping and Demos:
- Quickly expose a backend function for demo purposes without setting up API Gateway.
Automation and Internal Tools:
- Create internal tools that employees can access directly via a simple URL.
Static Website Backends:
- Pair a static website hosted on Amazon S3 or CloudFront with a Lambda function URL for dynamic functionality (e.g., form submissions).
IoT Integrations:
- Allow IoT devices to trigger serverless functions directly via HTTP endpoints.

How to validate requests in Lambda Function Url

Steps:

Define your request model
Use the reusable request model to validate your event body data(payload)
Plug the model to your handler method

Define your request model

Define the model for your event body. Say you want name, email, and an optional mobileNumber. We are going to create a model that matches the expected event body.

Prerequisite: Install Joi --> npm install Joi

const Joi = require('joi');

const eventModel = Joi.object({
    name: Joi.string().required(),
    email: email: Joi.string().email({ minDomainSegments: 2, tlds: { allow: ['com', 'net'] } }),
    mobileNumber: Joi.string().optional()
})

Use the request model to validate your event

After creating the model, next we will need to validate the event body data with the model; this step also ensures error is properly handled.

const validateEventData = async (data) => {
    try{
        const value = await eventModel.validateAsync(data);
        return value;
    }catch(error){
        throw new Error( error.message || error);
    }
}

Plug-in the model to your handler method

module.exports.handler = async (event, context) => {
  try{
    const body = validateEventData(event.body);
    return { statusCode: "200", body };
    }
  }catch (err) {
    return {
        statusCode: 400,
        body: { message: 'Invalid request body', error: err.message || err },
    };
  }
}

Sample Error

Say we send a mismatch event object like:

{
    "email": "value3@gmail.com"
    "mobileNumber": "234567890"
}

Note that we took out a required field name.

  "statusCode": 400,
  "body": { "message": "Invalid request body", "error": "\"name\" is required"
  }

Here's a refactored and expanded version of your conclusion section to provide more depth and reinforce key takeaways:

Conclusion

Properly validating incoming requests is a critical step in safeguarding your AWS Lambda functions from potential vulnerabilities such as SQL injection, script injection, and other forms of malicious input. By implementing robust validation practices, you can ensure that your application remains secure, reliable, and resilient.

In this article, we demonstrated how to use Joi library to perform request validation in AWS Lambda functions. With Joi, you can define clear validation schemas, enforce data integrity, and provide informative error messages to users when inputs do not meet your requirements. This approach not only fortifies your application against security threats but also enhances maintainability by keeping your validation logic structured and reusable.

By following the steps outlined, you can seamlessly integrate input validation into your Lambda functions and handle validation errors gracefully. As a result, your serverless applications can operate more securely, giving you confidence that only well-formed, valid data is processed.

Remember, validation is just one layer of a comprehensive security strategy. Pairing it with practices such as proper error logging, input sanitization, and authentication mechanisms (like AWS Cognito) will further bolster the security of your application.

Secure coding practices like these are essential for building robust serverless architectures. Start implementing input validation today to protect your AWS Lambda endpoints and provide a safer experience for your users.

——————————————

For more articles, follow my social handles:

Schema Validation in Amazon DynamoDB

iAmSherif 💎 — Fri, 08 Nov 2024 22:03:14 +0000

Introduction

Validating data in DynamoDB is crucial for maintaining data integrity, ensuring application reliability, and reducing errors. Unlike relational databases, DynamoDB does not enforce strict schema constraints, giving you the flexibility to store a variety of data formats. However, this flexibility means you must take responsibility for validating data before it is written to the database. In this article, we’ll go through an approach to validate data in DynamoDB using AWS Lambda.

Why Data Validation Matters in DynamoDB

Without strict schema enforcement, data in DynamoDB can end up in inconsistent or incorrect formats. If validation is neglected, problems may arise, such as:

Application Errors: Missing or incorrectly formatted data can lead to errors and application crashes.
Data Inconsistencies: Querying inconsistent data formats can complicate analytics and reporting.
Scalability Issues: Unvalidated data may lead to inefficient data structure and increased storage costs.

To avoid these issues, validating data before saving it to DynamoDB is essential.

How to validate schema using AWS Lambda

In serverless architectures, AWS Lambda is a common approach for server-side validation. By implementing validation within Lambda functions, you can control data before it reaches DynamoDB.

Here’s how you can incorporate validation in a Lambda function with Node.js:

const Joi = require('joi');

// The schema definition using Joi
const tableSchema = Joi.object({
    id: Joi.string().required(),
    name: Joi.string().required(),
    email: Joi.string().pattern(new RegExp("^[\\w-\\.]+@([\\w-]+\\.)+[\\w-]{2,4}$")).required(),
    phone: Joi.string().optional()
})

const validateObject = async (data) => {
    try{
        const value = await tableSchema.validateAsync(data);
        return value;
    }catch(error){
        return {
            body: JSON.stringify({ message: "Invalid request body", error: err.message || err }),
        }
    }
}

module.exports.lambdaHandler = async (event, context) => {
  try{
    const body = event.body
    const result = await writeToDynamodbTable(body);
    return result;
    }
  }catch (err) {
    return {
        statusCode: 400,
        body: JSON.stringify({ message: "Invalid request body", error: err.message || err }),
    };
  }
}

const writeToDynamodbTable = async (data) => {
  try{
    const value = await validateObject(data)
    const params = {
        TableName: 'YourTableName',
        Item: {
          id: value.id,
          name: value.name,
          email: value.email,
          phone: value.phone
        },
        ConditionExpression: "attribute_not_exists(id)"
  };;
    const res = await dynamodbClient.send(new PutCommand(params));
    return res;
  }catch(error){
    throw error
  }
};

In the code snippet above we:
1- Define the schema using Joi Schema
2- Validate our object in the validateObject function
3- Configure our params object
3- Send request to DynamoDB using AWS Lambda

SAMPLE ERROR:

If we send a mismatch object like this:


{
  "body": {
    "id": "value1",
    "name": "value2",
    "email": "value3@gmail.com"
  }
}

Note: phone is not included in the object but it is a required key in the schema we defined.
We will get an error like

{ statusCode: 400,
  body: { message: "Invalid request body",
          error: ""phone" is required"
        }
}

Conclusion

Validating data in DynamoDB is a fundamental step to ensure data quality and avoid issues down the line. Whether you choose to validate data on the client, the server, or both, using a structured approach with reusable validation schemas will streamline the process. By following best practices, you can improve the reliability and performance of your DynamoDB-backed applications.

——————————————

Follow my social handles for more articles:
Click and follow on

How to Pull Resources from AWS SSM Parameter Store in AWS SAM

iAmSherif 💎 — Fri, 11 Oct 2024 23:09:35 +0000

Introduction

In this article, I'll guide you through the process of retrieving a DynamoDB table name stored in AWS Systems Manager Parameter Store (SSM Parameter Store) using an AWS SAM template (template.yml). Additionally, I’ll show how to use this parameter in our code and how to add the required IAM permissions to the function.

What is AWS Systems Manager Parameter Store?

AWS Systems Manager Parameter Store is a service that provides secure, hierarchical storage for managing configuration data and secrets. It allows you to store values like passwords, database strings, Amazon Machine Image (AMI) IDs, and other sensitive information as parameters. These values can be stored as plain text or encrypted, and referenced in scripts, AWS Lambda functions, and other AWS services by their unique parameter names.

Creating a Parameter in AWS Systems Manager Parameter Store

We will create a parameter to hold our DynamoDB table name in the SSM Parameter Store.

Steps:

In the AWS Management Console, search for Systems Manager.
Under the Application Management section, select Parameter Store.
Click the Create Parameter button on the left side. 4- Name the parameter /my/database/name. 5- Set the type to String, and enter the DynamoDB table name as the value. 6- Click Create Parameter to save.

Note: In this example, the parameter name is /my/database/name, and its value is the name of your DynamoDB table.

Retrieving the Parameter in Your AWS SAM Template

In the template.yml file, we'll reference the DynamoDB table name stored in SSM. The Lambda function, MyFunction, needs both read permissions for the DynamoDB table and permission to access the SSM Parameter Store.

The SSM parameter is retrieved using the syntax {{resolve:ssm:/my/database/name}}, which fetches the value dynamically during resource creation. Additionally, we must assign the necessary IAM roles to allow the Lambda function to read the parameter.

AWSTemplateFormatVersion: '2010-09-09'
Transform: AWS::Serverless-2016-10-31
Description: Url Sample SAM Template for url

Globals:
  Function:
    Timeout: 3
    LoggingConfig:
      LogFormat: JSON
Resources:
  MyFunction:
    Type: AWS::Serverless::Function
    Properties:
      Handler: redirect.handler
      Runtime: nodejs18.x
      FunctionUrlConfig:
        AuthType: NONE
      Policies:
        - DynamoDBCrudPolicy:
            TableName: "{{resolve:ssm:/my/database/name}}"
        -  SSMParameterReadPolicy:
            ParameterName: "my/database/name"
      Architectures:
        - x86_64
      Environment:
        Variables:
          TABLE_NAME: "/my/database/name"

Here, the Lambda function retrieves the DynamoDB table name using the resolve function from SSM and assigns the necessary policies to access both DynamoDB and the SSM Parameter Store.

Note: We removed the starting / before the parameter name.

-  SSMParameterReadPolicy:
            ParameterName: "my/database/name"

If we don't, we will get an Unauthorized error.

Retrieving the Parameter Value in your Code

In your code, you can retrieve the DynamoDB table name from the SSM Parameter Store like this:

const { SSMClient, GetParameterCommand } = require("@aws-sdk/client-ssm");

const table_name_path = process.env.TABLE_NAME;

const retrieveTable = async () => {
    const input = {
        Name: table_name_path,
        WithDecryption: false,
    };
    const command = new GetParameterCommand(input);
    const response = await ssmClient.send(command);

    return response.Parameter.Value;
}

This JavaScript code initializes an SSM client, and retrieves the DynamoDB table name using the GetParameterCommand.

Note: Ensure you install the @aws-sdk/client-ssm package using npm install @aws-sdk/client-ssm

Best Practice: Notice that we didn't retrieve the parameter value directly within our Lambda function. We avoid adding extra latency during Lambda's cold start. This approach improves performance by reducing the number of external API calls made during execution.

Conclusion

In this article, we explored how to securely store and retrieve a DynamoDB table name from AWS Systems Manager Parameter Store and use it within an AWS Lambda function. By utilizing the {{resolve:ssm}} syntax in the AWS SAM template, we demonstrated how to dynamically reference parameters during resource deployment. Additionally, we showed how to configure the necessary IAM permissions and retrieve the parameter value within our code using AWS SDK.

Leveraging AWS Systems Manager Parameter Store not only helps in managing configuration data and secrets efficiently, but also enhances the security and flexibility of your serverless applications. With these steps, you can easily scale this approach to manage other sensitive configuration values across your AWS infrastructure.

Follow my social handles for more articles:
Click and follow on

How to make authenticated HTTP POST and GET requests to third-party APIs in SpringBoot

iAmSherif 💎 — Thu, 26 Sep 2024 00:22:40 +0000

Introduction

Spring Boot is a powerful Java framework that simplifies software development process by providing a comprehensive suite of tools and conventions. Its ease of use, along with powerful features, makes it a popular choice for both small and large applications. In building applications, at times there is a need to consume third-party APIs within your application.

There are several ways to make requests to APIs in Spring Boot which include using RestTemplate, WebSocket, Apache HttpClient, OkHttp, and FeignClient. The choice of method often depends on the specific requirements of your application. In this article, we will focus on how to make authenticated POST and GET requests to third-party APIs using RestTemplate.

What is RestTemplate?

RestTemplate is a synchronous client provided by Spring that provides a straightforward and intuitive API for sending HTTP requests and handling responses. It is a package in Spring that is included in the Spring Web dependency. Its methods are easy to understand, making it accessible for developers of all skill levels.

How to make an Authenticated POST request

To demonstrate how to make an authenticated POST request, let's consider a scenario where we are building a wallet application that needs to create an account via a third-party API at https://api.example.com/create.

Requirements:

The API requires the following:

Headers: Authorization bearer <token>
Body Parameters: name, email, bvn

Steps

Create a RestTemplate object.
Set Up the HTTP Headers: Create a header that carries the authorization token using HttpHeaders.
Create the HttpEntity: Construct an HttpEntity object using the expected request body and the HTTP header.
Make the POST Request: Use the postForObject method of RestTemplate to send the request.

Example Code

String url = "https://api.example.com/create";

RestTemplate restTemplate = new RestTemplate();

HttpHeaders httpHeaders = new HttpHeaders();

httpHeaders.setBasicAuth(token);

HttpEntity<Object> httpEntity = new HttpEntity<>(requestBody, httpHeaders);

// Response from the API server
String responseObject = restTemplate.postForObject(url, httpEntity, String.class);

With this setup, you can successfully make a POST request to the API, provided that the token is valid.

How to make an Authenticated GET request

To make the authenticated GET request, we are going to make use of the exchange method in RestTemplate.

Example Code

String url = "https://api.example.com/balance";

HttpHeaders httpHeaders = new HttpHeaders();

httpHeaders.setBasicAuth(token);

HttpEntity<Object> httpEntity = new HttpEntity<>(httpHeaders);

// Response from the API server
String responseObject = restTemplate.exchange(url, HttpMethod.GET, httpEntity, String.class).getBody();

By following these steps, you will be able to make the GET request to the API provided your token is valid.

Conclusion

In this article, we covered how to make authenticated POST and GET requests to third-party APIs using SpringBoot's RestTemplate. By leveraging RestTemplate, you can easily configure your requests to include necessary authentication headers.

Additional Notes

Always ensure that sensitive data such as API keys and passwords are stored securely, using environment variables or encrypted configuration files.
Consider exploring other options like WebClient for reactive programming or FeignClient for declarative API clients in more complex applications.

Follow my social handles for more articles:
Click and follow on

Securing Data at Rest: The Importance of Encryption and How to Implement It

iAmSherif 💎 — Sun, 14 Jul 2024 17:30:56 +0000

Introduction

Keeping your data safe is essential for any organization to prevent unauthorized access and breaches. In AWS's shared security responsibility model, customers are responsible for anything they put in the cloud or connect to the cloud, while AWS is responsible for the security of the cloud. For more details, you can read more information about AWS shared responsibility model.

Data at rest refers to data stored in AWS data stores, such as Amazon S3 buckets and DynamoDB. In this article, I will highlight the importance of encrypting data at rest and provide a guide on how to encrypt an Amazon DynamoDB table using a Customer Managed key (CMK).

Why do we need to encrypt data at rest?

AWS data stores offer encryption at rest using configurable options that we control. These encryption options leverage the AWS Key Management Service (AWS KMS) and keys that either we or AWS manage. By default, data on Amazon DynamoDB tables is fully encrypted. AWS offers several encryption tools, including AWS Cryptographic Services and Tools, and AWS KMS. In this article, we will focus on adding encryption to DynamoDB using a AWS KMS CMK.

The importance of encrypting data at rest includes:

Ensuring sensitive data stored on disks is not readable by any user or application without a valid key.
Maintaining the confidentiality and protection of sensitive information from unauthorized access.
Enhancing customer trust by demonstrating a commitment to data security and privacy.
Minimizing the impact of data breaches on business operations and reputation.

How to Encrypt a DynamoDB Table Using AWS KMS CMK

The steps below guides on how to encrypt a DynamoDB table using AWS KMS CMK from AWS Management Console:

Step 1: Create an AWS KMS Customer Managed Key

Log in to your AWS Management Console.
Navigate to AWS Key Management Service (KMS) and click on Create key.
Configure Key.
Configure Add Labels: Name the key "mykey".
Define Key Administrative Permissions and Usage Permissions. Read more about assigning roles for administrative and usage permissions.
Review your configurations and click Finish.

Step 2: Encrypt DynamoDB Table Data Using the Key

Go to the DynamoDB console and select Tables.
Click on Create table.
On the next page, name your table "myTable" and add a partition key.
In Table Settings, click on Customize settings.
Scroll down to Encryption at rest and add your custom key.

Choose the key you created named "mykey".
Click Create table.

Your table will now be encrypted using the selected CMK.

Conclusion

Encrypting data at rest in AWS is a critical step in ensuring the security and integrity of your organization's sensitive information. By leveraging AWS KMS Customer Managed Keys (CMK), you can maintain control over your encryption keys and meet compliance requirements. This guide has walked you through the process of creating a custom key and using it to encrypt a DynamoDB table. Implementing these encryption practices not only protects your data from unauthorized access but also enhances customer trust and minimizes the impact of potential data breaches. Prioritizing data security is essential for safeguarding your business operations and reputation.

Follow my social handles for more on AWS Serverless services:
Click to follow on

How to validate requests in Amazon API Gateway using Request Validator and Validator Model in AWS CDK

iAmSherif 💎 — Sun, 30 Jun 2024 21:39:19 +0000

In this article, I will share my experience validating requests in Amazon API Gateway. First, let's start with why you need to validate requests at the API Gateway level.
One of the key features of Serverless architecture is its cost-efficient model (pay-per-use). By following best practices, validating requests at the API Gateway level is a good idea for efficiency and security. It's also worth noting that API Gateway does not charge for unauthorized or invalid requests. When an endpoint is invoked with a bad request, API Gateway intercepts and rejects the request, returning a 400 status code to the user.

API Gateway is a fully managed AWS service that makes it easy for developers to create, publish, maintain, monitor, and secure APIs at any scale.

API Gateway Model and RequestValidator Class

We can request validation from API Gateway by using the RequestValidator in api-gateway module from the aws-cdk-lib library.

Code Sample:

const requestValidator = new RequestValidator(
      this,
      "RequestValidator",
      {
        restApi: api,
        requestValidatorName: "requestBodyValidator",
        validateRequestBody: true,
        validateRequestParameters: false,
      }
    );

The props:

restApi: The string identifier of the associated RestApi. (api) is a reference to the API Gateway instance.
requestValidatorName: The name of this RequestValidator.
validateRequestBody: A Boolean flag indicating whether to validate the request body according to the configured Model schema.
validateRequestParameters: A Boolean flag indicating whether to validate request parameters (true) or not (false).

The RequestValidator helps set up basic validation rules for incoming requests to the API. To validate the request body, we need to set up a Model schema. The Model schema defines the structure of a request or response payload for an API method.

Creating a Model Schema

Let's create a Model schema for an API Gateway request validator that includes firstName, lastName, and portfolioLink as properties.

Code Sample:

const validatorModel = new Model(this, "RequestValidatorModel", {
      restApi: api,
      contentType: "application/json",
      description: "Validate Long Url",
      modelName: "ValidatorModel",
      schema: {
        schema: JsonSchemaVersion.DRAFT4,
        title: "ModelValidator",
        type: JsonSchemaType.OBJECT,
        properties: {
          firstName: {
            type: JsonSchemaType.STRING,
            minLength: 1,
          },
          lastName: {
            type: JsonSchemaType.STRING,
            minLength: 1,
          },
          portfolioLink: {
            type: JsonSchemaType.STRING,
            pattern: "^(http://|https://|www\\.).*",
          }
        },
        required: ["firstName", "lastName"],
      },
    });

In this Model, we defined firstName and lastName as required properties in the request payload with a minimum length of 1. We also defined portfolioLink of type String and enforced a specific regex pattern.

The Props:

restApi: The string identifier of the associated RestApi - (api) is a reference to API Gateway instance.
contentType: The content type for the model. By default, it is 'application/json', so if you are configuring for text, it will be 'text/HTML'.
description: A string that identifies the model.
modelName: A name for the model. By default, AWS CloudFormation generates a unique physical ID and uses that ID for the model name.
schema: The schema to use to transform data to one or more output formats. In API Gateway models are defined using the JSON schema draft 4.
title: Defines the schema title.
type: Specifies that the root of the JSON document must be an object.
properties: Defines the properties the object must have.
required: A list of properties that must be present in the object. In our case, firstName and lastName.

Attaching the Model and Validator to an API Gateway Method

Next, we need to attach our Model and RequestValidator to an API Gateway method.

Code Sample:

api.root
      .addResource("/user")
      .addMethod("POST", user, {
        requestModels: {
          "application/json": validatorModel,
        },
        requestValidator: requestValidator,
      });

By following these steps, you can efficiently validate requests at the API Gateway level, ensuring that only properly structured requests reach your backend services. This not only improves security but also reduces unnecessary processing and potential costs.

Getting started with AWS Serverless architecture: A Paradigm Shift in Cloud Computing

iAmSherif 💎 — Tue, 28 Nov 2023 23:26:11 +0000

Let’s delve into the realm of Serverless architecture, where traditional deployment challenges find a transformative solution.

In the past, deploying a web application on AWS often meant relying on a single server, typically an AWS EC2 instance. While EC2 instances can scale vertically to an extent, accommodating increased demand, they face limitations as traffic surges.

Enter the Load Balancer👽 — a solution to handle escalating traffic by dynamically adding more servers, a concept known as horizontal scaling. However, this approach poses cost challenges. Picture this: a traffic spike on Monday prompts the Load Balancer to provision additional instances, incurring costs even during idle periods when the traffic subsides.

To address this, the Auto Scaling Group comes into play, efficiently managing server instances based on demand. This ensures optimal resource utilization and cost savings, especially during periods of reduced traffic.

Yet, the intricacies of manual configurations for server health and high availability raise a pertinent question: Isn’t this a lot of work?🤯🤯

This is where Serverless steps in, a veritable knight in shining armor 💂.

The Serverless platform helps deal with:

how to manage the infrastructure
how to make provision of instances
how to ensure the servers are healthy
what metrics to use when it’s time to scale out or scale in.

Then we say “SERVERLESS” means

No server management
Flexible scaling
Automated high availability
No idle capacity

With Serverless architecture, powered by AWS Lambda functions, you can run code without the hassle of provisioning or managing servers. It is an event-driven, Serverless compute service that not only reduces operational burdens but also provides flexible scaling, automated high availability across multiple zones, and substantial cost savings through its “pay-per-execution” model.

In essence, AWS Serverless architecture streamlines your deployment process, decreases time to complete processes, and offers an environment that closely mimics production — all with the ease of AWS Lambda functions at its core. It makes it easier to set up your app, saves you money, and takes away the hassle of managing servers. It's like having your own tech assistant handling the tough stuff.

Follow on LinkedIn and Twitter for more on AWS Serverless architecture:

click to follow on LinkedIn

click to follow on Twitter

DEV Community: iAmSherif 💎

Migrating a Lambda to a Durable Lambda Function

What is a Durable Lambda Function?

Lambda vs Durable Lambda?

What the Lambda Function Looked Like

Introducing Durable Execution

What Actually Changed?

Infrastructure Configuration Matters

What changed after migration

Conclusion

A Step-by-Step Guide to Deploying CrewAI on Amazon Bedrock AgentCore

What I Built

Prerequisites

Step 1 - Update Your Agents to Use a Bedrock-Supported LLM

Step 2 - Create a Remote Entrypoint for Bedrock AgentCore

Step 3 - Configure IAM Role for AgentCore

Step 4 - Generate Docker Configuration with AgentCore command

Important Fix

Step 5 - Launch the Agent to the Cloud

Step 6 - Test Your Deployed Agent

Final Thoughts

References

How to capture data changes in DynamoDB using Streams and Lambda (Node.js + AWS CDK)

Why Capture Data Changes?

How DynamoDB Streams Work

What We’ll Build

So Let’s Get Started

1. Define a DynamoDB Table with Stream Enabled

Stream View Types

2. Create a Lambda Function to Handle Stream Events

Why do we use unmarshall?

3. Connect the Stream to Lambda

Configuration Options

Conclusion

Deploying a Static E-commerce Site to AWS Using Pulumi

What I Built

Live Demo Link

Project Repo

My Journey

✅ Option 1: Use pulumi config set path via CLI

✅ Option 2: Move the frontend into your Pulumi project

🧠My Decision

Using Pulumi

How to set up CORS in AWS Lambda and API Gateway (RestApi)

Why Do You Get a CORS Error from the Browser?

Understanding the Request Flow: Preflight and Actual Requests

Setting Up CORS in AWS API Gateway and Lambda in (CDK)

Conclusion

How to validate requests when using AWS Lambda Function Url

Introduction

Why do you need Lambda Function Url

Importance of Lambda Function Url are:

When would you need Lambda Function Url

How to validate requests in Lambda Function Url

Steps:

Define your request model

Use the request model to validate your event

Plug-in the model to your handler method

Sample Error

Conclusion

Schema Validation in Amazon DynamoDB

Introduction

Why Data Validation Matters in DynamoDB

How to validate schema using AWS Lambda

SAMPLE ERROR:

Conclusion

How to Pull Resources from AWS SSM Parameter Store in AWS SAM

Introduction

What is AWS Systems Manager Parameter Store?

Creating a Parameter in AWS Systems Manager Parameter Store

Retrieving the Parameter in Your AWS SAM Template

Retrieving the Parameter Value in your Code

Conclusion

How to make authenticated HTTP POST and GET requests to third-party APIs in SpringBoot

Introduction

What is RestTemplate?

How to make an Authenticated POST request

Requirements:

Steps

Example Code

Why do we use `unmarshall`?

✅ Option 1: Use `pulumi config set path` via CLI