DEV Community: Márcio Coelho

Using an External Authorization Lambda with API Gateway in AWS SAM

Márcio Coelho — Sat, 16 Aug 2025 19:06:59 +0000

In real-world projects, you may already have a centralized Lambda Authorizer. Instead of duplicating the code, you can reuse that existing authorizer in new APIs.

In this post, we’ll create a new SAM project with an API Gateway, and configure it to use an external Lambda Authorizer by referencing its ARN.

Step 1: Define Parameters for the Authorizer ARN

In template.yaml, add a Parameter for the Lambda Authorizer ARN:

Parameters:
  AuthorizerLambdaArn:
    Type: String
    Description: ARN of the external Lambda Authorizer

This makes your SAM stack reusable — you can pass in the ARN during deployment.

🌐 Step 2: Add an API Gateway with Authorizer

Update template.yaml:

Resources:
  MyApi:
    Type: AWS::Serverless::Api
    Properties:
      Name: ExternalAuthorizerApi
      StageName: dev
      Auth:
        DefaultAuthorizer: MyLambdaAuthorizer
        Authorizers:
          MyLambdaAuthorizer:
            FunctionArn: !Ref AuthorizerLambdaArn
            Identity:
              Header: Authorization

  HelloFunction:
    Type: AWS::Serverless::Function
    Properties:
      CodeUri: src/
      Handler: handler.main
      Runtime: nodejs20.x
      Events:
        ApiEvent:
          Type: Api
          Properties:
            Path: /hello
            Method: get
            RestApiId: !Ref MyApi

Here’s what’s happening:

Auth section of MyApi references the external Lambda Authorizer ARN.

HelloFunction is protected automatically since the API has a default authorizer.

📚 Conclusion

By referencing an external Lambda Authorizer in your template.yaml, you can:

Reuse existing centralized authorization logic
Keep new APIs secure without duplicating code
Maintain a clean and consistent authentication strategy

Master Clean Code in AWS SAM: Using Shared Folders

Márcio Coelho — Thu, 29 May 2025 14:54:47 +0000

As projects grow, maintaining a clean structure is essential. In this post, we will:

✅ Create a centralized shared folder
✅ Configure esbuild to support module aliases for cleaner imports
✅ Using TypeScript for development

🗂️ Step 1: Create a shared Folder

Let’s create a folder for all shared utilities and modules.

aws-sam-node-lambda/
├── shared/
│   ├── utils.ts
│   ├── constants.ts
├── functions/
|   ├── function1/
│   |   ├── index.ts
├── tsconfig.json
└── template.yaml

shared/utils.ts

export const greet = (name: string) => `Hello, ${name}!`;

📝 Step 2: Lambda Code to Use Shared Module

In your Lambda handler:

import { greet } from '@shared/utils';

export const handler = async () => {
    const message = greet('AWS Lambda');
    return {
        statusCode: 200,
        body: JSON.stringify({ message })
    };
};

⚙️ Step 3: Configure TypeScript Path Aliases

Edit your tsconfig.json to define path aliases:

{
  "compilerOptions": {
    "baseUrl": ".",
    "paths": {
      "@shared/*": ["shared/*"]
    },
    "module": "ESNext",
    "target": "ES2020",
    "moduleResolution": "Node",
    "outDir": "dist",
    "esModuleInterop": true
  }
}

⚡ Step 4: Configure esbuild

In your template.yaml, configure esbuild under Metadata -> BuildMethod: esbuild:

Resources:
  MyFunction:
    Type: AWS::Serverless::Function
    Properties:
      Handler: index.handler
      Runtime: nodejs22.x
      Architectures:
        - arm64
    Metadata:
      BuildMethod: esbuild
      BuildProperties:
        Minify: true
        Target: "es2020"
        Sourcemap: true
        EntryPoints:
          - functions/function1/handler.ts
        External:
          - "@aws-sdk/*"

🧠 Conclusion

By organizing your code with a shared folder and aliases, you can improve maintainability and scalability for your AWS Lambda projects. Coupled with esbuild and TypeScript, this setup is modern, fast, and production-ready.

Optimizing Lambda Performance with AWS Lambda Power Tuning

Márcio Coelho — Wed, 14 May 2025 15:55:45 +0000

AWS Lambda Power Tuning is a solution provided by AWS that uses Step Functions to test your Lambda function across different memory configurations, helping you determine the optimal power setting for best cost/performance ratio.

🧱 Architecture Overview

Here’s how it works:

A Step Function runs your Lambda with different memory sizes (128MB → 10GB).
It collects duration, cost, and performance metrics.
You get a visual report to decide the best setting.

📦 Prerequisites

AWS CLI configured
AWS SAM CLI installed
Node.js Lambda function ready
Deploy the Lambda Power Tuning Step Function

🧪 Step 1: Deploy Lambda Power Tuning

Clone and deploy using the AWS Serverless Application Repository or SAM:

git clone https://github.com/alexcasalboni/aws-lambda-power-tuning.git
cd aws-lambda-power-tuning
sam deploy --guided

After deploy, take note of the Step Function ARN (e.g. arn:aws:states:us-east-1:123456789012:stateMachine:PowerTuningStateMachine)

🚀 Step 2: Run the Power Tuning

Use the AWS Console or invoke the Step Function programmatically:

{
  "lambdaARN": "arn:aws:lambda:us-east-1:123456789012:function:MyFunction",
  "powerValues": [128, 256, 512, 1024, 2048],
  "num": 10,
  "payload": "{}",
  "parallelInvocation": true,
  "strategy": "cost"
}

Replace with your actual Lambda ARN.

You can start the state machine using AWS Console or CLI:

aws stepfunctions start-execution \
  --state-machine-arn arn:aws:states:us-east-1:123456789012:stateMachine:PowerTuningStateMachine \
  --input file://input.json

📈 Step 3: Analyze the Results

Once completed, the Step Function execution will provide:

Cost vs performance graphs
Recommendations for optimal memory setting
JSON result with metrics

You’ll be able to visually compare:

Execution time
Memory size
Cost (ms × GB × price)

💡 Bonus Tip: Tune for Strategy

Lambda Power Tuning supports different strategies:

cost – minimize price

speed – minimize duration

balanced – tradeoff

Try different strategies depending on your workload.

AWS S3 Triggering Lambda

Márcio Coelho — Sat, 10 May 2025 15:44:32 +0000

We’ll create an event-driven Lambda that listens for new images in an S3 bucket (photos-raw), resizes them using Node.js, and saves the output to another bucket (photos-resized).

You’ll learn how to:

Configure S3 trigger events in AWS SAM
Resize images in Lambda using sharp

📝 template.yml

AWSTemplateFormatVersion: '2010-09-09'
Transform: AWS::Serverless-2016-10-31

Globals:
  Function:
    Timeout: 29
    Runtime: nodejs22.x
    MemorySize: 512

Resources:
  ResizeFunction:
    Type: AWS::Serverless::Function
    Properties:
      Handler: src/resize.handler
      Policies:
        - S3ReadPolicy:
            BucketName: !Sub "photos-raw-${AWS::AccountId}"
        - S3WritePolicy:
            BucketName: !Sub "photos-resized-${AWS::AccountId}"
      Events:
        S3Upload:
          Type: S3
          Properties:
            Bucket: !Sub "photos-raw-${AWS::AccountId}"
            Events: s3:ObjectCreated:Put
      Environment:
        Variables:
          RESIZED_BUCKET: !Sub "photos-resized-${AWS::AccountId}" 

  RawBucket:
    Type: AWS::S3::Bucket
    Properties:
      BucketName: !Sub "photos-raw-${AWS::AccountId}"

  ResizedBucket:
    Type: AWS::S3::Bucket
    Properties:
      BucketName: !Sub "photos-resized-${AWS::AccountId}"

Whenever someone uploads a new file to the photos-raw S3 bucket, automatically trigger (run) the Lambda function.

🧠 Function

import { S3Client, GetObjectCommand, PutObjectCommand } from '@aws-sdk/client-s3';
import sharp from 'sharp';
import { S3Event } from 'aws-lambda';
import { Readable } from 'stream';

const s3 = new S3Client({});
const RESIZED_BUCKET = process.env.RESIZED_BUCKET

const streamToBuffer = async (stream: Readable): Promise<Buffer> => {
  const chunks: Uint8Array[] = [];
  for await (const chunk of stream) chunks.push(chunk);
  return Buffer.concat(chunks);
};

export const handler = async (event: S3Event) => {
  for (const record of event.Records) {
    const bucket = record.s3.bucket.name;
    const key = decodeURIComponent(record.s3.object.key.replace(/\+/g, ' '));

    const { Body } = await s3.send(new GetObjectCommand({ Bucket: bucket, Key: key }));

    if (!Body || !(Body instanceof Readable)) {
      console.error('Invalid body stream');
      return;
    }

    const imageBuffer = await streamToBuffer(Body);
    const resized = await sharp(imageBuffer)
      .resize(800)
      .toBuffer();

    await s3.send(new PutObjectCommand({
      Bucket: RESIZED_BUCKET,
      Key: key,
      Body: resized,
      ContentType: resized.ContentType,
    }));
  }
};

Conclusion

You've now built an event-driven image pipeline using:

🪣 S3 Triggers
🧠 AWS SAM for infrastructure as code
⚙️ Sharp for image processing

Orchestrating Workflows with AWS Step Functions and AWS SAM

Márcio Coelho — Tue, 06 May 2025 20:40:32 +0000

When a serverless application requires orchestration of multiple tasks—such as invoking various Lambda functions, implementing retries, or managing conditional logic—AWS Step Functions provides a robust and reliable solution.

Today, we'll integrate Step Functions into our AWS SAM project using AWS::Serverless::StateMachine.

🧱 Why Step Functions?

💡 Visual workflows
🔁 Built-in retries and error handling
🧩 Easily integrate with Lambda, DynamoDB, SQS, etc.
📉 Great observability via execution history

📦 Project Structure

Example directory layout:

.
├── template.yml
├── functions/
│   ├── taskOne.ts
│   └── taskTwo.ts

🔧 Step 1: Define Your Lambda Functions

In template.yml:

Resources:
  TaskOneFunction:
    Type: AWS::Serverless::Function
    Properties:
      Handler: functions/taskOne.handler
      Runtime: nodejs22.x

  TaskTwoFunction:
    Type: AWS::Serverless::Function
    Properties:
      Handler: functions/taskTwo.handler
      Runtime: nodejs22.x

Example taskOne.ts:

export const handler = async () => {
  console.log("Running Task One");
  return { status: "taskOne done" };
};

🔁 Step 2: Define the State Machine

In template.yml, add a new resource:

  MyStateMachine:
    Type: AWS::Serverless::StateMachine
    Properties:
      Name: MyWorkflow
      Definition:
        StartAt: TaskOne
        States:
          TaskOne:
            Type: Task
            Resource: !GetAtt TaskOneFunction.Arn
            Next: TaskTwo
          TaskTwo:
            Type: Task
            Resource: !GetAtt TaskTwoFunction.Arn
            End: true
      Role: !GetAtt StepFunctionExecutionRole.Arn

This creates a two-step workflow: TaskOne → TaskTwo.

🔐 Step 3: Add IAM Role for Step Functions

  StepFunctionExecutionRole:
    Type: AWS::IAM::Role
    Properties:
      AssumeRolePolicyDocument:
        Version: '2012-10-17'
        Statement:
          - Effect: Allow
            Principal:
              Service: states.amazonaws.com
            Action: sts:AssumeRole
      Policies:
        - PolicyName: StepFunctionInvokeLambda
          PolicyDocument:
            Version: '2012-10-17'
            Statement:
              - Effect: Allow
                Action:
                  - lambda:InvokeFunction
                Resource:
                  - !GetAtt TaskOneFunction.Arn
                  - !GetAtt TaskTwoFunction.Arn

✅ Bonus: Add Retry Logic

TaskOne:
  Type: Task
  Resource: !GetAtt TaskOneFunction.Arn
  Next: TaskTwo
  Retry:
    - ErrorEquals: ["Lambda.ServiceException", "Lambda.AWSLambdaException"]
      IntervalSeconds: 2
      MaxAttempts: 3

🧠 Conclusion

Using Step Functions with AWS SAM makes your serverless apps more modular, resilient, and observable.

Key benefits:

🪄 Clear separation of logic
🔁 Built-in retries and error handling
🧩 Easily scale up workflows

Supercharge Your Lambda Functions with Powertools for AWS Lambda

Márcio Coelho — Fri, 02 May 2025 12:23:09 +0000

Writing clean, observable, and maintainable Lambda functions can be challenging — especially at scale.

That’s where AWS Lambda Powertools for TypeScript comes in. It offers a suite of utilities to help with:

Structured logging
Distributed tracing
Custom metrics
Parameter and secret fetching
Reusable data providers (like DynamoDB)

In today’s post, we’ll walk through how to use some of the most useful features in a real-world Lambda function.

🧰 Installation

First, install Powertools packages:

npm install @aws-lambda-powertools/logger @aws-lambda-powertools/tracer @aws-lambda-powertools/metrics @aws-lambda-powertools/parameters

Optional (for DynamoDB provider):

npm install @aws-sdk/client-dynamodb

📝 Structured Logging with Logger

import { Logger } from '@aws-lambda-powertools/logger';

const logger = new Logger({ serviceName: 'UserService' });

export const handler = async (event) => {
  logger.info('Handling event', { event });

  return {
    statusCode: 200,
    body: JSON.stringify({ message: 'Hello World!' }),
  };
};

✅ Output is JSON-formatted and ready for CloudWatch, Datadog, or other log aggregators.

📦 Tracing with Tracer

import { Tracer } from '@aws-lambda-powertools/tracer';

const tracer = new Tracer({ serviceName: 'UserService' });

export const handler = async (event, context) => {
  const segment = tracer.getSegment();
  const subsegment = segment.addNewSubsegment('my-subtask');

  try {
    // your logic here
  } finally {
    subsegment.close();
  }

  return { statusCode: 200 };
};

💡 Tracer integrates with AWS X-Ray automatically if enabled.

📈 Metrics with Metrics

import { Metrics, MetricUnits } from '@aws-lambda-powertools/metrics';

const metrics = new Metrics({ namespace: 'MyApp' });

export const handler = async () => {
  metrics.addMetric('SuccessfulInvocations', MetricUnits.Count, 1);
  metrics.publishStoredMetrics();

  return { statusCode: 200 };
};

🎯 Automatically flushes metrics to CloudWatch.

🔑 Fetching Parameters with getParameter

import { getParameter } from '@aws-lambda-powertools/parameters/ssm';

export const handler = async () => {
  const dbName = await getParameter('/my-app/db-name');

  return {
    statusCode: 200,
    body: JSON.stringify({ dbName }),
  };
};

✅ You can also cache parameters:

await getParameter('/my-app/db-name', { maxAge: 300 }); // cache for 5 mins

🗃 DynamoDB Provider

import { getDynamoDBProvider } from '@aws-lambda-powertools/parameters/dynamo';

const dynamoDBProvider = getDynamoDBProvider({ tableName: 'Settings' });

export const handler = async () => {
  const setting = await dynamoDBProvider.get('theme'); // get row with PK 'theme'

  return {
    statusCode: 200,
    body: JSON.stringify({ theme: setting?.value }),
  };
};

💡 Great for config-driven apps with DynamoDB as your parameter store.

Conclusion
With Powertools for TypeScript, your Lambdas are:

✅ Easier to debug (thanks to structured logging)
✅ Easier to monitor (custom metrics)
✅ Easier to trace (end-to-end with X-Ray)
✅ Easier to configure (via SSM or DynamoDB)

It’s a must-have for production-grade serverless development.

Securing Your API with a Lambda Authorizer (JWT Validation) in AWS SAM

Márcio Coelho — Sat, 26 Apr 2025 17:56:41 +0000

When building serverless APIs, security is critical. One common way to secure APIs is by requiring clients to present a JWT token.
AWS API Gateway supports Lambda Authorizers, allowing you to write custom authorization logic using a Lambda function.

In today's post, we’ll cover:

What is a Lambda Authorizer?
How to build a simple Lambda Authorizer with Node.js
How to connect it to your API Gateway with AWS SAM

🧠 What Is a Lambda Authorizer?

A Lambda Authorizer is a Lambda function that AWS API Gateway calls before forwarding the request to your main Lambda handler.

It can:

Validate a JWT token
Verify user roles/permissions
Allow or deny access based on custom logic

You can write the logic yourself, giving you maximum flexibility compared to built-in IAM or Cognito authorizers.

🛠 Step 1: Create the Authorizer Lambda

Here’s a simple authorizer.ts example:

import { APIGatewayTokenAuthorizerEvent, APIGatewayAuthorizerResult } from "aws-lambda";
import { Logger } from "@aws-lambda-powertools/logger";
import { SSMClient, GetParameterCommand } from "@aws-sdk/client-ssm";
import jwt from "jsonwebtoken";

const ssmClient = new SSMClient();
const logger = new Logger();

const secretName = process.env.SECRET_NAME!

const generatePolicy = (principalId, effect, resource) => ({
  principalId,
  policyDocument: {
    Version: '2012-10-17',
    Statement: [
      {
        Action: 'execute-api:Invoke',
        Effect: effect,
        Resource: resource,
      },
    ],
  },
});

export const handler = async (event: APIGatewayTokenAuthorizerEvent): Promise<APIGatewayAuthorizerResult> => {
  const token = event.authorizationToken

  if (!token) {
    throw new Error("Unauthorized");
  }

  const command = new GetParameterCommand({ Name: secretName, WithDecryption: true });
  const response = await ssmClient.send(command);
  const secret = response.Parameter!.Value!;

  try {
    const decoded = jwt.verify(token, secret);
    return generatePolicy('user', 'Allow', event.methodArn);
  } catch (error) {
    logger.error("JWT verification failed", err);
    throw new Error("Unauthorized");
  }
};

📜 Step 2: Define the Authorizer in template.yml

Resources:
  AuthorizerFunction:
    Type: AWS::Serverless::Function
    Properties:
      Handler: authorizer.handler
      Runtime: nodejs22.x
      Environment:
        Variables:
          JWT_SECRET: "your-secret-here"
      Policies:
        - Statement:
            Effect: Allow
            Action:
              - ssm:GetParameter
            Resource: "[path-to-resource]"

  HelloWorldFunction:
    Type: AWS::Serverless::Function
    Properties:
      Handler: index.handler
      Runtime: nodejs22.x
      Events:
        HelloWorldApi:
          Type: Api
          Properties:
            Path: /hello
            Method: get
            RestApiId: !Ref MyApi

  MyApi:
    Type: AWS::Serverless::Api
    Properties:
      StageName: prod
      Auth:
        DefaultAuthorizer: LambdaAuthorizer
        Authorizers:
          LambdaAuthorizer:
            FunctionArn: !GetAtt AuthorizerFunction.Arn

⚡️ Bonus Tip: HTTP API + JWT Authorizers

If you're using HTTP API instead of REST API, you can configure a JWT Authorizer without needing a custom Lambda Authorizer — built-in, easier, and faster!

Resources:
  MyHttpApi:
    Type: AWS::Serverless::HttpApi
    Properties:
      Auth:
        Authorizers:
          MyJwtAuthorizer:
            JwtConfiguration:
              issuer: https://your-issuer.com
              audience:
                - your-audience
            IdentitySource: "$request.header.Authorization"
        DefaultAuthorizer: MyJwtAuthorizer

✅ Benefits:

No Lambda function to maintain
Faster authentication (native integration)
Lower cost

Conclusion

Using Lambda Authorizers with JWT gives you powerful, flexible API security.

✅ Now your API is secured with a custom Lambda Authorizer that verifies JWT tokens.
✅ Full control over authentication and authorization.
✅ For simple cases, prefer HTTP API + Native JWT authorizers for speed and simplicity

Creating an API Gateway with AWS SAM and Node.js

Márcio Coelho — Thu, 24 Apr 2025 19:54:22 +0000

If you're building a serverless application with Lambda, chances are you need to expose your functions as APIs. That's where Amazon API Gateway comes in — and AWS SAM makes it incredibly easy to define and deploy them.

In this post, you’ll learn how to:

Define an API Gateway in template.yml
Connect it to a Lambda function
Understand the difference between REST API and HTTP API in terms of performance and cost

🧱 Step 1: Define the Lambda Function

Here’s a simple function that responds to HTTP requests:

Resources:
  HelloWorldFunction:
    Type: AWS::Serverless::Function
    Properties:
      Handler: index.handler
      Runtime: nodejs22.x
      Events:
        HelloWorldApi:
          Type: Api
          Properties:
            Path: /hello
            Method: get

This tells SAM to automatically provision an API Gateway and connect it to your Lambda. The Path and Method define the route.

💡 Optional: Define the API Resource Explicitly

To configure advanced settings (like CORS or API type), you can explicitly define an API Gateway:

Globals:
  Api:
    Name: MyApi
    Cors:
      AllowMethods: "'GET,POST,OPTIONS'"
      AllowHeaders: "'Content-Type'"
      AllowOrigin: "'*'"

Or define the resource yourself:

Events:
  HelloWorldApi:
    Type: Api
    Properties:
      RestApiId: !Ref MyApi
      Path: /hello
      Method: get

Then connect it to your function like this:

Events:
  HelloWorldApi:
    Type: Api
    Properties:
      RestApiId: !Ref MyApi
      Path: /hello
      Method: get

🧪 Step 2: Write the Handler Code

Here’s your basic index.ts (or index.js):

export const handler = async (event) => {
  return {
    statusCode: 200,
    body: JSON.stringify({ message: "Hello from Lambda!" }),
  };
};

⚔️ REST API vs HTTP API: Which Should You Use?

AWS offers two types of API Gateway APIs:

🚀 HTTP API (Recommended for Most Use Cases)

Faster cold starts
Lower cost (~70% cheaper than REST API)
Supports most common use cases (JWT auth, CORS, etc.)
Limited advanced features (e.g., direct VPC integration)

🧱 REST API

More mature, full feature set
Supports API keys, usage plans, request validation
More expensive and slightly higher latency

TL;DR:

Use HTTP API for most web or mobile apps
Use REST API if you need advanced API Gateway features

To switch to HTTP API in SAM:

Events:
  HelloWorldApi:
    Type: HttpApi
    Properties:
      Path: /hello
      Method: get

Conclusion

Creating APIs with AWS SAM is incredibly simple — just define an event and SAM handles the rest. Now you can:

✅ Connect Lambda to API Gateway
✅ Choose between REST or HTTP API based on needs

Boosting Node.js Performance on AWS Lambda

Márcio Coelho — Fri, 18 Apr 2025 21:04:01 +0000

Serverless is awesome — but performance matters. Cold starts, heavy bundles, or noisy logs can hurt your Lambda’s speed and cost. Today, we’ll explore practical ways to improve Node.js performance in AWS Lambda using AWS SAM.

Whether you're building APIs or event-driven apps, these tips will help you write faster, leaner, and more cost-effective serverless functions.

🚀 1. Initialize Services Outside the Handler

This is the golden rule. Anything that can be reused between invocations should be initialized outside the handler.

// Good ✅
import { DynamoDBClient } from "@aws-sdk/client-dynamodb";

const dbClient = new DynamoDBClient({});

export const handler = async (event) => {
  // Use dbClient
};

Why? Because AWS reuses Lambda containers during warm starts, and re-initializing things like database clients inside the handler adds unnecessary overhead.

🧠 2. Use the Latest Node.js Runtime

Always use the latest supported Node.js version in AWS Lambda (at the time of writing: nodejs22.x).

Benefits:

Faster startup time
Better performance and memory handling
Access to newer language features

Runtime: nodejs22.x

💪 3. Choose ARM Architecture (Graviton)

Graviton-based Lambdas (arm64) offer up to 34% better performance at 20% lower cost compared to x86_64.

In your template.yml

Properties:
  Architectures:
    - arm64

Unless you have specific native dependencies that don't support ARM, this is a smart switch.

📦 4. Keep Lambda Package Size Small

Smaller packages = faster cold starts. Here's how to shrink things down:

Use esbuild with minification and tree-shaking
Split shared code into Layers
Only include what you need — use External in your template.yml to exclude AWS SDK packages (they're included in the Lambda runtime)

Metadata:
  BuildMethod: esbuild
  BuildProperties:
    Minify: true
    Target: "es2020"
    External:
      - "@aws-sdk/*"

🚫 5. Avoid Wildcard Imports

Avoid doing this:

// Bad ❌
import * as AWS from "aws-sdk";

Use specific imports instead:

// Good ✅
import { S3Client } from "@aws-sdk/client-s3";

📊 6. Adjust Your Lambda Memory

Memory = power in AWS Lambda. Increasing memory also gives you more CPU.

Run performance tests at different memory levels to find the sweet spot. Sometimes doubling memory cuts execution time in half — and reduces cost.

In your template.yml:

MemorySize: 1024

🧹 7. Don't Log Everything

Logging too much (especially in loops or high-frequency Lambdas) adds latency and cost.

Guidelines:

Use debug level only when actively troubleshooting
Keep info logs minimal
Reserve error logs for actual failures

If you're using structured loggers like Powertools Logger, you can control verbosity via environment variables.

const logger = new Logger({
  logLevel: process.env.LOG_LEVEL || "INFO",
});

Conclusion

Performance in Lambda isn’t just about speed — it’s about cost, cold start time, and developer experience.

✅ Recap:

Move services outside your handler
Use the latest Node.js runtime
Choose ARM64 for better performance
Keep packages small and clean
Avoid wildcard imports
Tune memory settings
Log wisely

With these techniques, your Node.js Lambdas will be lean, fast, and production-ready.

Using Conditionals in AWS SAM to Customize Deployments

Márcio Coelho — Mon, 14 Apr 2025 12:50:06 +0000

As your serverless application evolves, you’ll often need to toggle resources, features, or settings based on the environment (e.g., dev, staging, production).

With AWS SAM, you can do this using CloudFormation-style conditionals, allowing you to dynamically include or exclude resources at deploy time.

In this post, we’ll cover:

Defining parameters and conditions
Using Conditions in your SAM template
Real-world examples like enabling the Powertools logger only in production

🧱 Step 1: Define Parameters

Start by adding environment-based parameters in your template.yml:

Parameters:
  Environment:
    Type: String
    Default: dev
    AllowedValues:
      - dev
      - staging
      - prod

⚙️ Step 2: Define Conditions

Now use those parameters to define conditional logic:

Conditions:
  IsProd: !Equals [ !Ref Environment, prod ]
  IsLowEnv: !Or 
    - !Equals [ !Ref Environment, dev ]
    - !Equals [ !Ref Environment, qa ]

You can now use these conditions to control resources, properties, or behaviors in your SAM app.

🔧 Step 3: Use Conditions in Resources

Here’s an example of conditionally including a Powertools Logger layer only in production:

Resources:
  HelloWorldFunction:
    Type: AWS::Serverless::Function
    Properties:
      Handler: index.handler
      Runtime: nodejs22.x
      Environment:
        Variables:
          ENV: !Ref Environment
      Layers:
        - !If
          - IsProd
          - arn:aws:lambda:${AWS::Region}:094274105915:layer:AWSLambdaPowertoolsTypeScriptV2:24
          - !Ref "AWS::NoValue"

💡 AWS::NoValue tells CloudFormation to omit the property entirely when the condition is false.

✅ Optional: Enable/Disable Features

You can also toggle entire resources or outputs:

Resources:
  TestFunction:
    Type: AWS::Serverless::Function
    Properties:
      Handler: index.handler
      Runtime: nodejs22.x
    Condition: IsLowEnv

Conclusion

With AWS SAM Conditionals, you can:

Make templates more reusable across environments
Toggle resources, settings, and layers cleanly
Keep infrastructure lean and purposeful

Whether you're turning on debug logs in dev or enabling global tracing in prod, conditionals help you build smart, environment-aware serverless apps.

Creating and Using Lambda Layers with AWS SAM and Node.js

Márcio Coelho — Thu, 10 Apr 2025 16:30:34 +0000

As your Lambda functions grow, you’ll want to avoid duplicating code or dependencies across functions. AWS Lambda Layers solve this by letting you package shared code (like libraries or utilities) once and reuse them across multiple Lambdas.

In this post, you’ll learn:

How to create a custom Lambda Layer with AWS SAM using Node.js
How to bundle it with esbuild using a Makefile
How to use AWS Lambda Powertools for TypeScript as a global logging layer

What is a Lambda Layer?

A Lambda Layer is a ZIP archive containing libraries, a runtime, or other dependencies. It’s extracted to the /opt directory in the Lambda runtime, making it perfect for sharing utility code or dependencies across functions.

Step 1: Create a Layer in Your SAM Project

Let’s create a utility layer (e.g., utils) to share code.

Directory structure:

my-sam-app/
├── layers/
│   └── utils/
│       └── utils.js
│       └── package.json
│       └── tsconfig.json
│       └── Makefile

Your utils.js could be something like:

export const greet = (name: string) => {
  return `Hello, ${name}!`;
};

Step 2: Use a Makefile with esbuild

The tsconfig.json:

{
  "compilerOptions": {
    "strict": true,
    "target": "es2023",
    "preserveConstEnums": true,
    "resolveJsonModule": true,
    "noEmit": false,
    "sourceMap": false,
    "module": "commonjs",
    "moduleResolution": "node",
    "esModuleInterop": true,
    "skipLibCheck": true,
    "forceConsistentCasingInFileNames": true,
    "outDir": "./utils"
  },
  "exclude": ["node_modules", "**/*.test.ts"]
}

Create a Makefile inside the utils/ folder:

build-Utils:
        ./node_modules/.bin/esbuild utils.ts --bundle --platform=node --target=node22 --outfile=$(ARTIFACTS_DIR)/nodejs/node_modules/utils/index.js --format=cjs --minify

SAM will automatically pick this up when you run sam build.

Step 3: Define the Layer in `template.yml`

Resources:
  UtilsLayer:
    Type: AWS::Serverless::LayerVersion
    Properties:
      LayerName: utils-layer
      Description: Common utility functions
      ContentUri: layers/utils
      CompatibleRuntimes:
        - nodejs22.x
      RetentionPolicy: Retain
      Metadata:
        BuildMethod: makefile

Step 3: Attach Layer to Lambda Function

Now add it to your Lambda function:

Resources:
  HelloWorldFunction:
    Type: AWS::Serverless::Function
    Properties:
      Handler: index.handler
      Runtime: nodejs22.x
      Layers:
        - !Ref UtilsLayer
    Metadata:
      BuildMethod: esbuild
      BuildProperties:
        Minify: true
        Target: "es2020"
        Sourcemap: false
        EntryPoints:
          - index.ts
        External:
          - utils
          - "@aws-sdk/*"

Step 4: Use Layer in Lambda Code

In your index.js or index.ts:

import { greet } from 'utils';

export const handler = async () => {
  return {
    statusCode: 200,
    body: JSON.stringify({ message: greet("SAM Developer") })
  };
};

🌟 BONUS: Using Powertools Logger as a Global Layer

If you want structured logging, tracing, and metrics — use AWS Lambda Powertools for TypeScript as a global layer. AWS provides it as a public layer:

Resources:
  HelloWorldFunction:
    Type: AWS::Serverless::Function
    Properties:
      Handler: index.handler
      Runtime: nodejs18.x
      Layers:
        - !Sub 
arn:aws:lambda:${AWS::Region}:094274105915:layer:AWSLambdaPowertoolsTypeScriptV2:24
    Metadata:
      BuildMethod: esbuild
      BuildProperties:
        Minify: true
        Target: "es2020"
        Sourcemap: false
        EntryPoints:
          - index.ts
        External:
          - "@aws-lambda-powertools/*"
          - "@aws-sdk/*"

or globally:

Globals:
  Function:
    Layers:
      - !Sub arn:aws:lambda:${AWS::Region}:094274105915:layer:AWSLambdaPowertoolsTypeScriptV2:24

Example Use

import { Logger } from "@aws-lambda-powertools/logger";

const logger = new Logger({ serviceName: "MyApp" });

export const handler = async () => {
  logger.info("Lambda invoked");
  return {
    statusCode: 200,
    body: JSON.stringify({ message: "Logged with Powertools" })
  };
};

Conclusion

You now know how to:

Create a reusable Lambda Layer with esbuild
Structure a Makefile build process for SAM
Use AWS Lambda Powertools for structured logging

Managing Environment Variables and Secrets in AWS Lambda (Node.js + SAM)

Márcio Coelho — Tue, 08 Apr 2025 11:54:35 +0000

We’ll dive into configuring environment variables and securely managing secrets using AWS Secrets Manager in an AWS Lambda function built with Node.js and AWS SAM.

You'll learn how to:

Define environment variables using Parameters in template.yml
Access them inside your Lambda function
Securely retrieve secrets from Secrets Manager
Add necessary IAM permissions to your Lambda role

Step 1: Define Parameters in template.yml

Add environment-specific parameters at the top of your SAM template:

Parameters:
  ENVIRONMENT:
    Type: String
    Default: dev

  SecretName:
    Type: String
    Description: Name of the AWS Secrets Manager secret

Step 2: Add Environment Variables and IAM Permissions

Update your Lambda function configuration:

Resources:
  HelloWorldFunction:
    Type: AWS::Serverless::Function
    Properties:
      Handler: index.handler
      Runtime: nodejs22.x
      Environment:
        Variables:
          ENV: !Ref ENVIRONMENT
          SECRET_NAME: !Ref SecretName
      Policies:
        - AWSSecretsManagerGetSecretValuePolicy:
            SecretArn: !Sub arn:aws:secretsmanager:${AWS::Region}:${AWS::AccountId}:secret:${SecretName}*

🔐 What This Does

Sets ENV and SECRET_NAME as environment variables
Grants the Lambda function permission to fetch secrets using the Secrets Manager policy

Step 3: Access Environment Variables in Your Code

In your index.js or index.ts:

const env = process.env.ENV;
const secretName = process.env.SECRET_NAME;

console.log(`Running in ${env} environment`);

Step 4: Fetch a Secret from AWS Secrets Manager

Install the AWS SDK v3 module if not already installed:

npm install @aws-sdk/client-secrets-manager

In your Lambda code:

import {
  SecretsManagerClient,
  GetSecretValueCommand
} from "@aws-sdk/client-secrets-manager";

const getSecretValue = async (secretName: string) => {
  const client = new SecretsManagerClient({});
  const command = new GetSecretValueCommand({ SecretId: secretName });
  const response = await client.send(command);
  return response.SecretString ? JSON.parse(response.SecretString) : null;
};

export const handler = async () => {
  const secret = await getSecretValue(process.env.SECRET_NAME!);
  console.log("Fetched secret:", secret);
};

Conclusion

You've now learned how to:

✅ Use Parameters in template.yml for dynamic environment configuration
✅ Inject environment variables into our Lambda function
✅ Securely fetch secrets from AWS Secrets Manager
✅ Grant minimal IAM access for secrets usage

DEV Community: Márcio Coelho

Using an External Authorization Lambda with API Gateway in AWS SAM

Master Clean Code in AWS SAM: Using Shared Folders

🗂️ Step 1: Create a shared Folder

📝 Step 2: Lambda Code to Use Shared Module

⚙️ Step 3: Configure TypeScript Path Aliases

⚡ Step 4: Configure esbuild

🧠 Conclusion

Optimizing Lambda Performance with AWS Lambda Power Tuning

🧱 Architecture Overview

📦 Prerequisites

🧪 Step 1: Deploy Lambda Power Tuning

🚀 Step 2: Run the Power Tuning

📈 Step 3: Analyze the Results

AWS S3 Triggering Lambda

📝 template.yml

🧠 Function

Conclusion

Orchestrating Workflows with AWS Step Functions and AWS SAM

🧱 Why Step Functions?

📦 Project Structure

🔧 Step 1: Define Your Lambda Functions

🔁 Step 2: Define the State Machine

🔐 Step 3: Add IAM Role for Step Functions

✅ Bonus: Add Retry Logic

🧠 Conclusion

Supercharge Your Lambda Functions with Powertools for AWS Lambda

🧰 Installation

📝 Structured Logging with Logger

📦 Tracing with Tracer

📈 Metrics with Metrics

🔑 Fetching Parameters with getParameter

🗃 DynamoDB Provider

Securing Your API with a Lambda Authorizer (JWT Validation) in AWS SAM

🧠 What Is a Lambda Authorizer?

🛠 Step 1: Create the Authorizer Lambda

📜 Step 2: Define the Authorizer in template.yml

⚡️ Bonus Tip: HTTP API + JWT Authorizers

Conclusion

Creating an API Gateway with AWS SAM and Node.js

🧱 Step 1: Define the Lambda Function

💡 Optional: Define the API Resource Explicitly

🧪 Step 2: Write the Handler Code

⚔️ REST API vs HTTP API: Which Should You Use?

Conclusion

Boosting Node.js Performance on AWS Lambda

🚀 1. Initialize Services Outside the Handler

🧠 2. Use the Latest Node.js Runtime

💪 3. Choose ARM Architecture (Graviton)

📦 4. Keep Lambda Package Size Small

🚫 5. Avoid Wildcard Imports

📊 6. Adjust Your Lambda Memory

🧹 7. Don't Log Everything

Conclusion

Using Conditionals in AWS SAM to Customize Deployments

🧱 Step 1: Define Parameters

⚙️ Step 2: Define Conditions

🔧 Step 3: Use Conditions in Resources

Conclusion

Creating and Using Lambda Layers with AWS SAM and Node.js

What is a Lambda Layer?

Step 1: Create a Layer in Your SAM Project

Step 2: Use a Makefile with esbuild

Step 3: Define the Layer in template.yml

Step 3: Attach Layer to Lambda Function

Step 4: Use Layer in Lambda Code

Conclusion

Managing Environment Variables and Secrets in AWS Lambda (Node.js + SAM)

Step 1: Define Parameters in template.yml

Step 2: Add Environment Variables and IAM Permissions

Step 3: Access Environment Variables in Your Code

Step 4: Fetch a Secret from AWS Secrets Manager

Conclusion

Step 3: Define the Layer in `template.yml`