DEV Community: Eduar Castaño

Serverless image pipeline with aws lambda+node+wasm: from 11.5mb to 91.2kb

Eduar Castaño — Tue, 30 Jun 2026 02:19:07 +0000

A while back I needed to process thousands of images for an e-commerce platform: multiple versions per product, carousel, thumbnail, invoice miniature. Manual processing wasn't an option. The bash scripts I ran from my machine worked, but they depended on me to run them. The solution was clear: a cloud pipeline that triggered automatically every time a new image arrived.

This post is about how I built that pipeline on AWS Lambda using beautiful-image, and why WASM was the key decision that made everything fit together without friction.

The architecture

The flow is simple and completely serverless:

No servers to maintain, no workers to scale, no queues to configure for the basic case. One image comes in, two variants come out, ready to serve from CloudFront.

Why WASM changes everything

beautiful-image has a core written in Rust compiled to WASM. That means:

Single artifact: the 469KB WASM binary goes inside the same Lambda ZIP. No Layers, no Docker images.
Real portability: the same package runs on nodejs22.x with x86_64 or arm64 architecture without recompiling anything.
Zero native dependencies: npm install is enough. Nothing to compile.

The deploy comes down to three commands:

npm install
sam build
sam deploy

The implementation

The handler is straightforward. It downloads the image from S3, generates the variants with beautiful-image, and uploads them to the destination bucket:

import { S3Client, GetObjectCommand, PutObjectCommand } from "@aws-sdk/client-s3"
import { image } from "beautiful-image/node"
import path from "node:path"

const SOURCE_BUCKET = process.env.SOURCE_BUCKET!
const DEST_BUCKET = process.env.DEST_BUCKET!

const s3 = new S3Client({})

const VARIANTS = [
  { folder: "optimized",  width: 800, quality: 80 },
  { folder: "thumbnails", width: 200, quality: 80 },
] as const

const ALLOWED_EXTENSIONS = new Set([".jpg", ".jpeg", ".png", ".webp"])

export const handler = async (event: AWSLambda.S3Event): Promise<void> => {
  for (const record of event.Records) {
    const key = decodeURIComponent(record.s3.object.key.replace(/\+/g, " "))

    const ext = path.extname(key).toLowerCase()
    if (!ALLOWED_EXTENSIONS.has(ext)) {
      console.log(`Skipping unsupported file type: ${key}`)
      continue
    }

    const t0 = performance.now()
    console.log(`Processing: ${key}`)

    let input: Buffer
    try {
      const t1 = performance.now()
      const { Body } = await s3.send(
        new GetObjectCommand({ Bucket: SOURCE_BUCKET, Key: key })
      )
      if (!Body) {
        console.error(`Empty body for key: ${key}`)
        continue
      }
      input = Buffer.from(await Body.transformToByteArray())
      console.log(`[timer] download: ${(performance.now() - t1).toFixed(0)}ms ${input.length}B`)
    } catch (err) {
      console.error(`Failed to download ${key}:`, err)
      continue
    }

    const filename = path.parse(key).name

    for (const { folder, width, quality } of VARIANTS) {
      const tp = performance.now()
      let result: Awaited<ReturnType<ReturnType<typeof image>["toJpeg"]>>
      try {
        result = await image(input).resize(width).toJpeg(quality)
      } catch (err) {
        console.error(`Failed to process variant ${folder} for ${key}:`, err)
        continue
      }
      console.log(`[timer] wasm ${folder} (${width}px): ${(performance.now() - tp).toFixed(0)}ms`)

      const destKey = `${folder}/${filename}.jpg`
      const tu = performance.now()
      try {
        await s3.send(
          new PutObjectCommand({
            Bucket: DEST_BUCKET,
            Key: destKey,
            Body: result.data,
            ContentType: "image/jpeg",
          })
        )
      } catch (err) {
        console.error(`Failed to upload ${destKey}:`, err)
        continue
      }
      console.log(`[timer] upload ${destKey}: ${(performance.now() - tu).toFixed(0)}ms`)

      console.log(
        `Saved ${destKey} - ${result.originalSize}B → ${result.optimizedSize}B (${Math.round(result.compressionRatio * 100)}% smaller)`
      )
    }

    console.log(`[timer] total: ${(performance.now() - t0).toFixed(0)}ms`)
  }
}

examples/lambda-demo

The beautiful-image API is chainable and reads like what it does: download, resize, compress, done.

const result = await image(input).resize(800).toJpeg(80)
// result.data            Buffer ready to upload
// result.originalSize    original size in bytes
// result.optimizedSize   new size in bytes
// result.compressionRatio  0.99 = 99% smaller

The SAM template

The entire stack in ~64 lines of YAML. The Lambda fires on any s3:ObjectCreated event in the source bucket:

AWSTemplateFormatVersion: '2010-09-09'
Transform: AWS::Serverless-2016-10-31
Description: Beautiful Image processor Lambda triggered by S3 uploads using beautiful-image

Parameters:
  SourceBucketName:
    Type: String
    Default: "my-raw-images"
    Description: S3 bucket where raw images are uploaded (trigger source)
  DestBucketName:
    Type: String
    Default: "my-processed-images"
    Description: S3 bucket where processed variants are saved
  Environment:
    Type: String
    Default: sandbox
    Description: Deployment environment name

Resources:
  ImageProcessorFunction:
    Type: AWS::Serverless::Function
    Metadata:
      BuildMethod: esbuild
      BuildProperties:
        Minify: true
        Target: es2020
        Sourcemap: true
        EntryPoints:
          - handler.ts
        External:
          - '@aws-sdk/*'
    Properties:
      FunctionName: !Sub "ImageProcessorFunction-${Environment}"
      CodeUri: ./
      Handler: handler.handler
      Runtime: nodejs22.x
      Timeout: 60
      MemorySize: 1769
      Environment:
        Variables:
          SOURCE_BUCKET: !Ref SourceBucketName
          DEST_BUCKET: !Ref DestBucketName
      Policies:
        - Statement:
            - Effect: Allow
              Action:
                - s3:GetObject
              Resource: !Sub "arn:aws:s3:::${SourceBucketName}/*"
            - Effect: Allow
              Action:
                - s3:PutObject
              Resource: !Sub "arn:aws:s3:::${DestBucketName}/*"

  ImageProcessorFunctionS3Permission:
    Type: AWS::Lambda::Permission
    Properties:
      FunctionName: !GetAtt ImageProcessorFunction.Arn
      Action: lambda:InvokeFunction
      Principal: s3.amazonaws.com
      SourceArn: !Sub "arn:aws:s3:::${SourceBucketName}"
      SourceAccount: !Ref AWS::AccountId

examples/lambda-demo

The MemorySize of 1769MB is not arbitrary: it's exactly 1 vCPU on Lambda. WASM is single-threaded, so adding more memory doesn't speed up processing, but going below that threshold does slow it down.

The S3 SDK is marked as External because the nodejs22.x runtime already includes it, so there's no need to bundle it.

The result

github-production-user-asset-6210df.s3.amazonaws.com

<video src="https://github.com/user-attachments/assets/5a3bc4b0-c88d-4504-965e-6c54bea3b6d7" autoplay="" muted="" loop="" playsinline=""></video>

One image lands in the bucket. The pipeline generates:

optimized/: 800px, ready for the product detail page
thumbnails/: 200px, ready for the carousel and invoices
...others/: additional variants (e.g. 400px, 600px)

No manual intervention, no servers to maintain.

When to use beautiful-image vs Sharp?

The de facto library for this in Node.js is Sharp. Excellent tool, but it introduces friction on Lambda: it uses native binaries compiled against libvips (~20MB), those binaries must match the exact Lambda architecture, and deploying the wrong binary means a runtime failure. The official Sharp docs for Lambda dedicate entire sections to platform flags, cross-compilation, and pnpm symlink issues. The practical solution the docs end up suggesting: use a community-maintained Lambda Layer.

beautiful-image doesn't compete with Sharp on raw speed. Sharp delegates to libvips, a C library with decades of architecture-specific optimizations that WASM can't fully match.

If you need compositing, SVG rendering, RAW formats, or color space conversion: Sharp is the right tool and nothing comes close. If you need resize and web optimization with a handful of filters and want the deploy to be a non-issue, beautiful-image gets you there with a fraction of the weight and zero operational friction.

The full code with SAM template, test event, and configuration is at examples/lambda-demo.

AWS Authentication: IAM Identity Center (SSO) - The right way in 2026

Eduar Castaño — Fri, 13 Mar 2026 01:26:44 +0000

The right way to authenticate in AWS in 2026. Goodbye access keys, hello temporary credentials.

The problem with access keys

For years, the "normal" way to use the AWS CLI was:

aws configure
# Access Key: AKIAIOSFODNN7EXAMPLE
# Secret Key: wJalrXUtnFEMI/K7MDENG/bPxRfiCY...

Problems:

Credentials never expire (until you delete them manually)
If you push them to Git by mistake → serious security breach
Each dev has different credentials → hard to manage
When someone leaves the company, you have to delete their keys manually

AWS no longer recommends this method for humans.

The solution: IAM Identity Center (SSO)

Previously called "AWS SSO". It's the recommended method since 2022 and the standard in 2026.

Advantages:

Temporary credentials (expire automatically every 8-12 hours)
Single login for multiple AWS accounts
Integration with identity providers (Google Workspace, Okta, Azure AD)
Built-in MFA
When someone leaves, they lose access automatically

Prerequisites

AWS CLI v2 (v1 doesn't support SSO)
An AWS account with admin permissions (for initial setup)
Browser for login

Setup: Step by step

1. Enable IAM Identity Center

In AWS Console:

Go to: IAM Identity Center
Click "Enable" (it's free, no cost)
Confirm the region (recommended: us-east-1 or your primary region)

AWS will automatically create the necessary infrastructure.

2. Choose identity source

You have 3 options:

Option A: IAM Identity Center directory (for general purposes)

AWS creates its own directory
You manage users directly in AWS

Option B: Active Directory (for companies with on-premise AD)

Connects with an existing AD
Users and groups sync automatically

Option C: External Identity Provider (most common in companies)

Google Workspace, Okta, Azure AD, etc.
True Single Sign-On
Ideal for: teams already using an IdP

For this guide, we'll use Option A (simplest).

3. Create first user

Using IAM Identity Center directory:

IAM Identity Center → Users → Add user
Fill in:

   Username: ed.developer
   Email: ed@example.com
   First name: Ed
   Last name: Dev
   Display name: Ed Developer

Click Add user
An activation link will be sent by email

Activate user:

Open the email
Click the link
Create a password
Set up MFA (recommended: authenticator app like Google Authenticator)

4. Create a group

Best practice: assign permissions to groups, not individual users.

IAM Identity Center → Groups → Create group
Name: Developers
Description: Development team with PowerUser access
Click Create group
Add users to group → select the user → Add users

5. Assign permissions

IAM Identity Center → AWS accounts
Select your AWS account
Click Assign users or groups
Tab Groups → select Developers
Click Next
Permission sets → select PowerUserAccess (allows almost everything except IAM)
- For full admin: AdministratorAccess
- For readonly: ViewOnlyAccess
Click Next → Submit

The process takes 1-2 minutes to apply.

6. Get SSO Start URL

The "SSO Start URL" is the gateway to AWS.

IAM Identity Center → Dashboard
Copy the AWS access portal URL
- It looks like: https://d-9067xxxxxx.awsapps.com/start

Configure AWS CLI with SSO

Install AWS CLI v2

aws cli

Configure SSO profile

aws configure sso

It will ask:

SSO session name (Recommended): my-sso

A name for the session
Example: work, personal, company-name

SSO start URL: https://d-9067xxxxxx.awsapps.com/start

The one generated from the Dashboard

SSO region: us-east-1

The region where IAM Identity Center was enabled

SSO registration scopes: (Enter for default)

Leave the default: sso:account:access

The browser will open → authorize access → available AWS accounts will be shown.

Select:

AWS account: account (12-digit number)
IAM role: PowerUserAccess

Back in the terminal:

CLI default client Region: us-east-1

Region for resources

CLI default output format: json

Options: json, yaml, text, table

CLI profile name: dev

Profile name
Examples: dev, work, personal, default

Done! The profile is configured.

Using SSO day to day

Login

# First time or when credentials expire
aws sso login --profile dev

The browser opens, you log in (with MFA if applicable), and you're done.

Credentials valid for ~8 hours. When they expire, run aws sso login again.

Running commands

Option 1: Specify profile in each command

aws s3 ls --profile dev
aws lambda list-functions --profile dev

Option 2: Set default profile for the session

export AWS_PROFILE=dev
aws s3 ls
aws lambda list-functions

Verify credentials

aws sts get-caller-identity --profile dev

# Output:
# {
#   "UserId": "AROAXXXXX:ed.developer",
#   "Account": "123456789012",
#   "Arn": "arn:aws:sts::123456789012:assumed-role/..."
# }

Logout

aws sso logout --profile dev

Multiple profiles (work + personal)

You can have several profiles configured:

# Configure work profile
aws configure sso
# ... follow wizard, name profile: work

# Configure personal profile
aws configure sso
# ... follow wizard, name profile: personal

# Use each one
aws s3 ls --profile work
aws s3 ls --profile personal

# Or switch between them
export AWS_PROFILE=work
aws s3 ls

export AWS_PROFILE=personal
aws s3 ls

View configuration

Profiles are stored in ~/.aws/config:

cat ~/.aws/config

It looks like this:

[profile dev]
sso_session = my-sso
sso_account_id = 123456789012
sso_role_name = PowerUserAccess
region = us-east-1
output = json

[sso-session my-sso]
sso_start_url = https://d-9067xxxxxx.awsapps.com/start
sso_region = us-east-1
sso_registration_scopes = sso:account:access

Common troubleshooting

Error: "Token has expired"

# Solution: Login again
aws sso login --profile dev

Error: "No credentials"

# Check that the profile exists
cat ~/.aws/config

# Make sure to specify the profile
aws s3 ls --profile dev

# Or set it as default
export AWS_PROFILE=dev

Browser doesn't open

# Use device code flow (manual)
aws configure sso --use-device-code

It will generate a code to enter manually in the browser.

"Profile not found"

# List profiles
aws configure list-profiles

# Reconfigure the profile
aws configure sso

Credentials expire too fast

This is normal (security). AWS rotates credentials every 8-12 hours.

Tip: Create an alias:

# In .bashrc or .zshrc
alias awsl='aws sso login --profile dev'

# Now just:
awsl

When to use access keys

Only in these cases:

1. CI/CD pipelines

GitHub Actions, GitLab CI, Jenkins, etc.

# GitHub Actions example
- name: Configure AWS Credentials
  uses: aws-actions/configure-aws-credentials@v4
  with:
    aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
    aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
    aws-region: us-east-1

2. Serverless applications

Lambdas, ECS containers → use IAM roles, not access keys.

Best Practices

Always use SSO for humans
MFA enabled in IAM Identity Center
Least privilege: assign only the necessary permissions
Groups, not users: permissions at the group level
Audit access: review logs in CloudTrail
Don't share access keys between people
Don't use root account for daily tasks

Quick reference commands

# SSO Login
aws sso login --profile dev

# Verify identity
aws sts get-caller-identity --profile dev

# List profiles
aws configure list-profiles

# View profile configuration
aws configure list --profile dev

# Set default profile for current session
export AWS_PROFILE=dev

# Logout
aws sso logout --profile dev

# Reconfigure profile
aws configure sso

Advanced configuration

Profile with different roles

# In ~/.aws/config

[profile dev]
sso_session = my-sso
sso_account_id = 111111111111
sso_role_name = PowerUserAccess
region = us-east-1

[profile dev-readonly]
sso_session = my-sso
sso_account_id = 111111111111
sso_role_name = ViewOnlyAccess
region = us-east-1

[profile prod]
sso_session = my-sso
sso_account_id = 222222222222
sso_role_name = ReadOnlyAccess
region = us-east-1

Resources

TL;DR:

Enable IAM Identity Center
Create user/group
Assign permissions (PowerUserAccess)
aws configure sso
aws sso login --profile dev
Profit

Access keys only for CI/CD. For everything else: SSO.