Lambda@Edge to Cloudflare Workers migration guide
Use this guide to plan migration from Lambda@Edge or CloudFront Functions to Cloudflare Workers. It covers behavior inventory, deciding what should become native Cloudflare Rules, Workers runtime differences, cache and origin validation, CI/CD, observability, and rollback.
Use this guide to plan migration from Lambda@Edge or CloudFront Functions to Cloudflare Workers. It covers behavior inventory, deciding what should become native Cloudflare Rules, Workers runtime differences, cache and origin validation, CI/CD, observability, and rollback.
Topics: cloudflare, resource, lambda, edge, cloudflare, workers
Machine-readable context: /ai-index.json
Step by step
Implementation steps
- 1
Inventory every Lambda@Edge and CloudFront Functions deployment by the CloudFront event it binds to: viewer-request, viewer-response, origin-request, and origin-response.
- 2
Capture what each function actually does — header rewrites, redirects, URL normalization, auth/token checks, A/B routing, origin selection, or response shaping — and the runtime and trigger it depends on.
- 3
Decide per behavior whether it should become a native Cloudflare Rule or a Worker: simple header edits, redirects, and routing map to Transform, Redirect, Cache, and Origin Rules; only code-grade logic stays as a Worker.
- 4
For behaviors that remain code, account for runtime differences: Workers run on the V8 isolates model with the Fetch API and Wrangler, not Node-style Lambda handlers, so rewrite request/response handling rather than porting line-by-line.
- 5
Rebuild origin-event logic against Cloudflare's request lifecycle — origin selection, Host header, and SNI behavior — and configure bindings (KV, secrets) the function needs instead of Lambda environment assumptions.
- 6
Validate cache and origin parity on a test hostname: compare cache status, TTLs, redirect chains, rewritten headers, and origin requests against the CloudFront behavior before shifting traffic.
- 7
Set up CI/CD and observability with Wrangler: preview environments, versioned and gradual deployments, Workers logs/Logpush, and tail consumers for errors.
- 8
Cut over per behavior with a defined rollback — keep the previous Worker version instantly deployable and, where a rule replaced a function, keep the rule revertible.
Risk register
Risks to control
Lambda@Edge functions are ported one-to-one into Workers when many were only doing header edits, redirects, or routing.
Classify each behavior first; move simple logic to Transform, Redirect, Cache, and Origin Rules and reserve Workers for logic that genuinely needs code.
Code is migrated assuming the Lambda/Node execution model and breaks on the Workers runtime.
Rewrite against the V8 isolates model and Fetch API using Wrangler; do not assume Node built-ins, the Lambda handler signature, or full Node compatibility.
Behavior bound to a specific CloudFront event is reattached to the wrong stage of Cloudflare's request lifecycle.
Map each viewer/origin request/response trigger to the equivalent point in Cloudflare's pipeline and test request- and response-side behavior separately.
Origin-request logic changes Host header, SNI, or origin selection and breaks routing.
Validate Host header and SNI handling and origin selection on a test hostname, comparing against the CloudFront behavior before production traffic moves.
Cache behavior diverges after migration and origin load rises.
Compare cache status, TTLs, and bypass conditions between CloudFront and Cloudflare on critical paths during parallel validation before cutover.
A regressed Worker deploy has no fast way back.
Use Wrangler versioned and gradual deployments so the prior version can take all traffic immediately, and keep rule-based replacements revertible.
Output
Useful deliverables
- Edge-function inventory mapping each Lambda@Edge/CloudFront Functions deployment to its CloudFront event and purpose.
- Native-Rule-versus-Worker decision register per behavior.
- Cloudflare target design: Transform/Redirect/Cache/Origin Rules for declarative logic and Workers (with bindings and secrets) for code.
- Runtime migration notes covering the V8 isolates model, Fetch API, and Wrangler differences from Lambda.
- Cache and origin parity matrix comparing CloudFront and Cloudflare on critical paths.
- CI/CD and observability setup: Wrangler preview/gradual deploys, Workers logs/Logpush, and tail consumers.
- Per-behavior cutover and rollback plan with versioned Worker deployments and revertible rules.
Keep reading
Related resources
FAQ
Frequently asked questions
Common questions teams ask when putting this resource into practice.
Does every Lambda@Edge function need to become a Cloudflare Worker?
No. A large share of edge functions only rewrite headers, issue redirects, normalize URLs, or pick an origin — those map to native Transform, Redirect, Cache, and Origin Rules. Workers are reserved for logic that genuinely needs code, external calls, or state.
How different is the Workers runtime from Lambda@Edge?
Substantially. Workers run on V8 isolates with the standard Fetch API and are managed with Wrangler, rather than the Node-based Lambda handler model. Code is rewritten to the Workers request/response style and bindings rather than ported line-by-line.
How do CloudFront triggers map to Cloudflare?
CloudFront viewer-request/response and origin-request/response events map onto stages of Cloudflare's request pipeline. Each behavior is reattached at the equivalent point and request- and response-side logic is validated separately on a test hostname.
How is cache and origin behavior validated after migration?
On a test hostname before cutover, compare cache status, TTLs, bypass conditions, redirect chains, rewritten headers, and origin request volume against the CloudFront baseline so behavior matches and origin load does not spike.
Can a Workers deploy be rolled back if it regresses?
Yes. Wrangler versioned and gradual deployments let a known-good version take all traffic immediately. Where a native rule replaced a function instead of a Worker, that rule is kept revertible so either path can be undone quickly.
Nanosek
Plan an edge migration
Nanosek can turn this resource into a practical delivery plan for your environment — with rollback planning, stakeholder alignment, and 24/7 managed operations support.