Serverless architectures bring speed and agility, but authorization often remains a weak point. With this release, you can now run Cerbos PDP inside AWS Lambda - either as a standalone Lambda function or as a Lambda extension layer, and pair it with Cerbos Hub as the central control plane for policy and audit-log management.

This dual-layer model means you get a unified policy platform via Cerbos Hub, and a distributed decision engine in Lambda, giving you consistent authorization everywhere, from containers and VMs to serverless Lambdas.

Documentation.

Two flexible deployment options

Lambda function

Deploy Cerbos as its own Lambda function (cerbosfunc). Ideal when you want a central authorization service that many functions or micro-services call into.

• Binary: Use the provided cerbosfunc binary.
• Distribution: Available as a ZIP package
• APIs: Supports /v1/check/resources and /v1/plan/resources endpoints via API Gateway.
• Resource: For production use, tune memory allocation and consider provisioned concurrency to mitigate cold-start latency

Lambda extension (Layer)

Deploy Cerbos as an extension layer (cerbosext) that runs alongside your application function. This gives you the “sidecar style” enforcement inside the same execution environment.

• Binary: Provided cerbosext binary.
• Distribution: Distributed as a ZIP package layer.
• APIs: Same /v1/check/resources and /v1/plan/resources endpoints.
• Resource: Shares the same runtime as your app Lambda, so ensure the memory/CPU profile supports both your business logic and the authorization engine

Comparison: Function vs extension

If you are comparing the two deployment patterns, here’s how they differ:

Deployment pattern

• Function: Centralised service
• Extension: Embedded sidecar with your function

Resource sharing

• Function: Dedicated Lambda execution
• Extension: Shares your application’s Lambda execution

Cold-start

• Function: Its own cold-start overhead
• Extension: Cold-start is shared with your app function

Network overhead

• Function: API Gateway + Lambda invocation to Cerbos
• Extension: Local process call within the Lambda environment

Use-case fit

• Function: A central PDP servicing many Lambdas
• Extension: High-throughput or low-latency enforcement inside specific Lambdas

Scaling

• Function: Scales independently
• Extension: Scales exactly with your app Lambda

In both cases, policies are authored and managed in Cerbos Hub, then distributed to each PDP (whether function or extension) via the Hub’s control plane.

Use cases for Cerbos in AWS Lambda

Event-driven microservices with dynamic access checks

When you build a serverless architecture using AWS Lambda, functions often process events (API requests, S3 uploads, DynamoDB streams). Teams we’ve spoken with often embed authorization logic inside each handler, leading to duplicated logic, inconsistent enforcement, and slow change cycles.

By deploying Cerbos in Lambda (either as a function or an extension) and using Cerbos Hub for central policy management, you can:

• Evaluate fine-grained policies at runtime (for example: “user A can edit resource X if they are the owner or a member of team Y and the current time is within business hours”).
• Decouple policy logic from your business code, so you don’t need to redeploy every Lambda when permissions change.
• Scale enforcement in line with your function scaling (especially with extension mode) or decoupled via the PDP function.

Multi-tenant serverless platforms

If you operate a serverless platform where each tenant runs Lambda functions, you’ll often need per-tenant policies, policy isolation, and audit-trail capability.

In this scenario:

• Use Cerbos Hub as your central policy admin layer where you manage policies by tenant, environment, team, or workload.
• Deploy Cerbos in each tenant’s Lambda via extension (co-located enforcement) or via a shared PDP function (central enforcement).
• Use attributes like tenant-id, principal metadata, and resource tags to implement RBAC, ABAC, or PBAC.
• Use Cerbos Hub’s audit trail and logs to get full visibility into “who did what, when, why” across all tenants.

Serverless APIs with externalized authorization

When teams build APIs via Lambda + API Gateway, often the authorization logic is tightly coupled inside each handler (“if user.role == ‘admin’ then …”). Over time, this leads to inconsistencies and error-prone code.

With Cerbos PDP + Cerbos Hub:

• You have a single “authorization control plane” (Cerbos Hub) for policy versioning, testing, and rollout.
• Lambdas enforce via the PDP (function or extension), so your app code only needs to call Cerbos to ask “is this allowed?” or “what actions are allowed?”
• You can push policy changes from Cerbos Hub to your PDP fleet without changing your Lambdas.
• You capture audit logs centrally in Cerbos Hub for compliance, incident response, and traceability.

Hybrid serverless + containerized workloads

Many organisations operate mixed environments: some services in Kubernetes/ECS, some in Lambda. A common problem is “authorization drift” - policy enforcement logic differs between environments.

Using Cerbos:

• Cerbos Hub remains the single source of truth for policies across all workloads.
• The PDPs (in containers, VMs, or Lambdas) run the same policy bundles generated by Cerbos Hub.
• This ensures consistent enforcement, unified logging, and test workflows across serverless and containerized services. From our experience, this drastically reduces inconsistencies and improves audit readiness.

Low-latency / edge / regional workloads

Some architectures deploy Lambdas in multiple regions or need ultra-low latency (e.g., personalization, fraud detection, IoT ingestion). In such cases:

• Use the extension model so the PDP runs inside the same Lambda execution environment, yielding very low latency.
• Or run the PDP function in the same region as your application Lambdas and use Cerbos Hub to coordinate policy distribution globally. Because the PDP is stateless and does not require a remote database for each decision, it fits neatly into Lambda.

What we hear from Cerbos users

• Security and product teams frequently told us that “pulling authorization logic into separate services or functions” in serverless was a blocker because of added latency or complexity. The extension mode (with local PDP) often resolved this by making policy enforcement feel like a library call inside Lambda.
• A common mistake we see: embedding complex authorization logic across many Lambdas. This leads to inconsistent behavior, inferior testability, and difficult audits. Using Cerbos Hub to centralize policy management, plus distributed PDPs, improved traceability and compliance.
• Teams using the central PDP function appreciated the ability to monitor request volumes, manage policy from many application teams, and support per-tenant customisation. Still, they noted they also needed to manage concurrency, warm-start strategies, and cold-start behavior.
• Cerbos Hub now serves as the central administration point, policy store, test pipeline, and audit log collector across all environments.

“We’ve seen more teams adopt Lambda for edge and event-driven workloads,” said Alex Olivier, CPO of Cerbos. “Now you can bring the same policy-as-code model to those environments without external dependencies or vendor lock-in.”

Key takeaways

• Use Cerbos in AWS Lambda via either a standalone function or extension layer.
• Use Cerbos Hub as the central control plane for policy authoring, versioning, testing, distribution, and audit logs.
• Choose the deployment pattern that fits your latency, scale, and operational model: central PDP vs embedded extension.
• Maintain a unified policy architecture across serverless, containers, and hybrid workloads.
• Capture full audit trails and policy lineage via Cerbos Hub for compliance, incident response, and governance.