How to Use Lambda Layers with Amplify

When you first start using AWS Lambda, everything feels clean and simple. You write a function. You deploy it. It works.

But then your application grows. You add more Lambdas. You share utilities. You introduce heavier dependencies.

And suddenly…

• Your bundles get bigger.
• Deployments slow down.
• Shared code starts duplicating.
• And strange build issues start appearing.

At that point, every small change starts costing more time than it should.

That’s exactly when Lambda Layers stop being “nice to have” — and become necessary.

Let me show you why…

What Are Lambda Layers (In Simple Terms)?

A Lambda Layer is a separate package that contains shared code or dependencies. A layer is versioned, and you can attach the same layer to multiple functions.

Instead of bundling everything inside every function, you move common logic into a layer and attach it to multiple functions.

Think of it like:

• Your Lambda function → Business logic
• Your Layer → Shared building blocks

AWS mounts the layer into the runtime environment, and your function can import it normally.

The Real Benefits of Using Lambda Layers

Smaller Function Packages

Without layers, every Lambda carries its own dependencies.

If you have:

• PDF libraries
• Template engines
• Database drivers
• Logging utilities
• Shared helper modules

They get bundled repeatedly.

With layers, those dependencies are packaged once and reused.

2. Cleaner Architecture

As your system grows, you naturally separate:

• Business logic
• Infrastructure logic
• Shared utilities
• Platform-level services

Layers help enforce this separation.

Example structure:

amplify/  functions/  layers/

Now shared capabilities live in one place — not scattered across several functions.

A Real Example: Solving a PDF Translation Problem

Let’s look at a practical scenario.

We needed to build a feature that:

• Generates PDF reports
• Supports multiple languages
• Uses Handlebars (.hbs) templates
• Runs inside AWS Lambda
• Is deployed using Amplify Gen 2 (which uses esbuild)

Everything worked; until it didn’t.

**The Problem: **Amplify Gen 2 bundling setup didn’t package .hbs files in a way Lambda could reliably access

Amplify Gen 2 uses esbuild to bundle Lambda functions.

The issue?

It doesn’t natively process .*hbs *template files.

When we tried importing templates directly inside the Lambda function:

• The templates weren’t bundled properly
• The runtime couldn’t find them
• Rendering failed
• Translations broke

We needed a solution that wouldn’t turn into a maintenance hack.

Before

• templates in function bundle
• esbuild doesn’t include .hbs
• runtime can’t find templates

After

• templates in layer
• AWS mounts them in /opt
• rendering becomes predictable

The Solution: Move Templates into a Lambda Layer

Instead of fighting the bundler, we changed the architecture.

We created a dedicated layer for report templates and locales:

amplify/  layers/    report-template-layer/      templates/        summary-report.hbs        analytics-report.hbs        compliance-overview.hbs        activity-summary.hbs      locales/        en/        es/        de/

Then our service layer looked something like:

amplify/  services/    report-data-service.ts    report-generator.ts    report-i18n.ts    template-renderer.ts

The Lambda function simply attached the layer.

When a layer is attached, AWS mounts it under /opt/, so your function can read templates from there at runtime.

Now the rendering flow became:

1. Load template from /opt/templates
2. Apply locale translations
3. Render using Handlebars
4. Generate final PDF

Clean. Stable. Predictable.

Why This Worked So Well

No More Bundling Issues

The templates were no longer part of the esbuild bundle.

2.** Clear Separation**

• Templates → Layer
• Translation files → Layer
• Rendering logic → Service
• Business logic → Lambda

3. Reusability

Any future reporting Lambda could reuse the same layer.

4. Stable Deployments

No hacks. No custom bundler overrides. Just proper structure.

When Lambda Layers Really Shine

Layers are especially useful when you have:

• Static assets (templates, HTML, configs)
• Localization files
• Heavy dependencies
• Native binaries
• Shared logging or monitoring logic
• Bundling constraints in managed environments

When You Might Not Need Them

If you only have:

• A couple of small Lambdas
• Minimal dependencies
• No shared code
• No static assets

You can keep things simple.

Layers are a scaling tool — not a starting requirement.

Final Thought

Lambda Layers aren’t just about reducing package size.

They’re about:

• Architectural clarity
• Separation of concerns
• Reusability
• Stability in complex serverless systems

In our case, they weren’t an optimization. They were the clean architectural fix to a real build limitation. And that’s usually when you know you’re using the right tool.