Migrating an AI-Native Cloudflare Stack to AWS: An Agent-Led Playbook
A vendor-neutral, end-to-end playbook for moving a full Cloudflare estate — WAF/DDoS/Zero-Trust, Workers, D1, Durable Objects, KV, R2, Queues, Vectorize, Workers AI, and AI Gateway — to AWS. Includes a primitive-by-primitive service mapping, before/after reference architectures, a three-wave sequencing plan, an AI-layer deep-dive, and the agent-driven tooling that makes the migration economical.
Migrating an AI-Native Cloudflare Stack to AWS: An Agent-Led Playbook
About this guide. This is architecture guidance for replacing Cloudflare primitives on AWS for AI-native workloads. It is a vendor-neutral technical reference; all examples are generic and illustrative.
1. Overview
Modern AI-native startups increasingly build their entire application, edge, and AI stack on Cloudflare: Workers for compute, D1 for relational data, Durable Objects for coordination state, KV for config and cache, R2 for object storage, Queues for async work, Vectorize for embeddings, Workers AI for inference, AI Gateway for cross-provider model routing, and the Cloudflare WAF/DDoS/Zero-Trust layer for the edge. It is a coherent, tightly integrated platform — and that integration is exactly what makes moving off it feel daunting.
This playbook describes how to migrate a full Cloudflare estate to AWS with an agent-led approach. It uses an open-source CDN/WAF config converter to produce deployment-ready CloudFront + WAFv2, and Kiro + AWS Transform to port the Workers compute and rebuild the data and AI layers — sequenced so the riskiest, most fragile pieces move first. It provides a primitive-by-primitive service mapping, before/after reference architectures, a wave-based sequencing plan, a deep-dive on the AI layer, and the tooling that makes an agent-led migration economical rather than a multi-million-dollar systems-integrator engagement.
2. Background and motivation
Teams increasingly weigh moving off Cloudflare for a few recurring reasons: consolidating onto a single cloud they already use, hitting platform ceilings (per-object size limits, throughput caps, consumer limits) as they scale, or wanting deeper integration between their edge and their data and AI services. Published guidance for the AI/Workers case is thin — most available content covers CDN-and-DNS swaps or single applications. An end-to-end architecture playbook that also covers Workers compute, the data tier, and the AI layer is the gap this document fills.
What makes this migration genuinely hard is that most of the estate is not a rehost. A Worker is not a container you lift; Durable Objects have no one-to-one AWS primitive; AI Gateway bundles routing, key management, and spend caps that map to several AWS services rather than one. The migration is a mix of replatform, re-architecture, and rebuild — and the goal of this playbook is to turn that into a repeatable pattern.
Example in practice. A typical AI-native estate runs a fleet of Worker microservices plus one or more larger monoliths also running on Workers (for example, an LLM-gateway monolith), several relational databases on D1, coordination state in Durable Objects, and model inference on Workers AI — all behind Cloudflare's WAF. The common trigger is a decision to standardize on AWS and remove platform ceilings the team is beginning to hit (for instance, D1 write throughput or Vectorize index size).
3. Reference architecture: before migration
A representative Cloudflare estate has three tiers:
- Edge / app tier (Cloudflare): a fleet of Worker microservices plus one or more monoliths running on Workers (such as an LLM-gateway monolith) front the whole system, with the Cloudflare WAF, DDoS protection, and Zero-Trust access controls as the security spine.
- Data tier (Cloudflare): D1 (relational), Durable Objects (strongly-consistent coordination state), KV (config, cache, session), R2 (object storage), and Queues (async fan-out).
- AI tier (Cloudflare): Vectorize for embeddings/retrieval, Workers AI for model inference, and AI Gateway providing cross-provider routing, bring-your-own-key billing, and per-tenant spend caps.
The defining characteristic to capture is the tight coupling between the edge and the data/AI primitives: a single request path commonly reads KV, writes a Durable Object, queries Vectorize, and calls AI Gateway. Unpicking that coupling safely is what drives the sequencing in Section 7.
4. Guiding principles
- Measure, don't debate. Validate each workload in a short, paid proof-of-concept using parallel-run diffing — run the AWS target and the Cloudflare original side by side on mirrored traffic and compare p99 latency, cost per million reads, and consistency under load. This converts estimate disputes into observed numbers both sides trust.
- Sequence by risk. Move homogeneous, low-risk workloads first to establish the landing zone and build team familiarity; defer the AI-native rebuilds (Durable Objects, AI Gateway) until the team is confident.
- Retire fragile dependencies early. Any brittle glue — a cross-service tunnel, a hand-rolled failover — should be removed in the first wave so later work builds on a stable base.
- Apply agents where the line count is large. Use coding agents (Kiro, AWS Transform) for the high-volume, mechanical porting of Workers to Lambda, and reserve human engineering judgment for the genuine re-architecture decisions, such as how to decompose Durable Objects or shape the gateway replacement.
Example in practice. The first principle settles the inevitable latency debate. When a team is concerned that moving a model-inference path to Bedrock will raise latency, a short parallel run on a small slice of mirrored traffic produces the actual p99 numbers, and the decision is made on data rather than opinion.
5. Service mapping
The following primitive-by-primitive mapping is the core reference artifact. It is split into three sub-tables by tier.
5.1 Front door (edge and security)
| Cloudflare primitive | AWS target | Migration type | Notes |
|---|---|---|---|
| CDN / DNS / TLS | CloudFront + Route 53 + ACM | Replatform | Generate the baseline with the open-source config converter (see Section 8) |
| WAF | AWS WAF (WAFv2) | Replatform | The converter exports and converts Cloudflare WAF rules to CloudFormation |
| DDoS / Zero Trust | AWS Shield Advanced (+ Verified Access where needed) | Replatform | Shield Advanced for parity on managed DDoS response |
5.2 Compute and data
| Cloudflare primitive | AWS target | Migration type | Notes |
|---|---|---|---|
| Workers (microservices) | Lambda (Graviton) + API Gateway/ALB | Replatform | Kiro + AWS Transform port; preserve the Node.js async model |
| Workers (monolith, e.g. LLM-gateway) | Lambda + ECS Fargate (split by workload shape) | Re-architect | Stateless routing to Lambda; long-running paths to Fargate |
| D1 | Aurora Serverless v2 (PostgreSQL) | Replatform | DMS + SCT; dual-write cutover |
| Durable Objects | DynamoDB (conditional writes) + ElastiCache Valkey | Rebuild | No 1:1 primitive; Valkey for live counters, DynamoDB for audit state |
| KV | DynamoDB / ElastiCache Serverless | Replatform | Stronger consistency than Cloudflare KV's eventual model |
| R2 | S3 (+ CloudFront) | Replatform | Budget one-time egress on exit |
| Queues | SQS + EventBridge (+ Step Functions) | Replatform | Removes Cloudflare throughput / consumer ceilings |
| Cron Triggers | EventBridge Scheduler | Replatform | Functional parity |
5.3 AI layer
| Cloudflare primitive | AWS target | Migration type | Notes |
|---|---|---|---|
| Vectorize | S3 Vectors (bulk) + OpenSearch Serverless (hot) | Rebuild | Validate retrieval recall after re-index |
| Workers AI (inference) | Amazon Bedrock (open-weight + frontier models) | Replatform | Batch/flex + prompt caching for cost |
| AI Gateway (routing, BYOK, caps) | Bedrock-native + self-managed LiteLLM (+ Guardrails AI OSS) | Rebuild | No first-party cross-provider gateway; phase it |
Example in practice. The hardest mapping is Durable Objects. A common pattern is a single Durable Object class performing two jobs at once — for example, a live per-tenant rate counter and a durable audit log. The rebuild separates them: the counter moves to ElastiCache Valkey (sub-millisecond
INCR), and the audit log moves to DynamoDB with conditional writes for optimistic locking. Forcing both into a single AWS service is the common mistake.6. Reference architecture: after migration
With the mapping settled, the AWS target state places each Cloudflare primitive by tier. The front door is CloudFront + AWS WAF + Shield; compute moves to Lambda and ECS Fargate; the data tier spreads across Aurora Serverless v2, DynamoDB, ElastiCache Valkey, and S3; and the AI layer lands on Bedrock, S3 Vectors / OpenSearch Serverless, and a self-managed LiteLLM gateway. The agentic tooling — Kiro + AWS Transform for compute, DMS + SCT for data, and the open-source converter for the CDN/WAF front door — carries each tier across.
7. Sequencing: a wave plan
The migration proceeds in three waves, each ending in a parallel-run validation gate before cutover.
Wave 1 — Front door and foundations. Stand up the AWS landing zone (Control Tower, VPC, IAM, KMS). Run the config converter against the exported Cloudflare config to generate the CloudFront + WAFv2 baseline, deploy it, and move DNS to Route 53. This establishes a stable, AWS-owned front door on the lowest-risk layer. If any models are already called through AI Gateway, add Bedrock as a provider behind the existing gateway at this stage — a one-line config change that de-risks the later AI cutover.
Wave 2 — Data tier. Migrate D1 to Aurora Serverless v2 with DMS and a dual-write cutover window; rebuild Durable Objects and KV onto DynamoDB + ElastiCache Valkey; move R2 to S3; convert Queues to SQS + EventBridge; and re-index Vectorize into S3 Vectors + OpenSearch Serverless. Point inference at Bedrock. This is the wave where platform ceilings disappear — Aurora removes the D1 write-rate and per-database size limits, and OpenSearch removes the Vectorize index-size ceiling.
Wave 3 — Edge and compute. Use Kiro / AWS Transform to port the Worker microservices to Lambda, preserving the Node.js async model; split each Workers monolith (stateless routing to Lambda, long-running paths to Fargate); and replace AI Gateway with LiteLLM + Guardrails AI OSS. Roll out across regions, and optionally replatform the agent layer onto AgentCore. This wave is last because it is the highest-complexity, highest-line-count work and benefits most from a stabilized foundation beneath it.
Example in practice. Completing Wave 1 first means that if a bot-attack spike occurs mid-migration, traffic is already behind AWS WAF + Shield rather than split across two providers in the middle of a cutover.
8. Tooling
An open-source converter handles the CDN/WAF front door, Kiro + AWS Transform handle the compute and data port, and the standard AWS migration services support the rest.
8.1 Open-source CDN/WAF config converter
- What it is: an open-source, agent-driven tool that converts a Cloudflare configuration backup into ready-to-deploy AWS edge configurations — AWS WAF as CloudFormation and CloudFront as Terraform + JavaScript (cache policies, CloudFront Functions, Lambda@Edge, and KeyValueStore data). The conversion pipeline is deterministic Python with zero LLM calls; the AI agent only orchestrates (reads intent, runs the scripts, translates the deploy guide).
- How it runs: no install. Clone the repo and let a coding agent (Kiro CLI, Claude Code, Codex, Cursor) drive it — skill-aware agents auto-discover
converter/SKILL.md, others readAGENTS.md. First produce a Cloudflare config backup with the bundledbackup/script (your API credentials stay local; the agent never sees them), then point the agent at the backup root and tell it to convert WAF, CDN, or everything. Each run writes a report (conversion_report.mdfor CDN,README_aws-waf-deployment.mdfor WAF) listing every deploy step, quota concern, and non-convertible item — nothing is silently dropped. - What it converts: WAF rules, rate limiting, and IP access lists to an AWS WAF Web ACL; cache/origin/redirect/URL-rewrite rules, bulk redirects, header transforms, compression, and custom error rules to CloudFront policies, CloudFront Functions, and KVS. It packs rule groups to stay under AWS WAF's hard per-WebACL caps, and at deploy time a resolver script matches your ISSUED us-east-1 ACM certificates to each host by SAN coverage.
- Note: this is a community/open-source project (not an official AWS tool), so validate its output against the generated reports before deploying.
- Link: https://github.com/chenghit/cloudflare-aws-edge-config-converter
8.2 Kiro + AWS Transform — the agentic compute/data port
- Kiro: an agentic IDE with a documented Cloudflare-to-AWS use case — spec-driven porting of Workers to Lambda. It covers what the front-door converter does not: the microservices, the monoliths, and the data-layer rebuilds.
- AWS Transform: AI-driven code transformation, language upgrades, and IaC generation for the high-line-count Worker fleet.
- Why it matters: agent-led transformation is what turns a multi-hundred-thousand-line port from a multi-million-dollar SI project into something a small team can drive.
8.3 Supporting AWS migration services
- AWS DMS + SCT — D1 to Aurora Serverless v2 (near-homogeneous SQL), with change-data-capture for a low-downtime, dual-write cutover.
- AWS Application Discovery Service / Migration Hub — portfolio discovery, dependency mapping, and single-pane tracking across the three waves.
- AWS Application Migration Service (MGN) — optional, for any component that is a straight lift-and-shift rather than re-containerized or rebuilt.
- AgentCore (optional) — Runtime, Memory, Gateway, Identity, and Policy if the application's agent layer is replatformed in Wave 3.
9. AI layer deep-dive
Replacing AI Gateway. Cloudflare's AI Gateway bundles three capabilities: cross-provider routing, bring-your-own-key billing, and per-tenant spend caps. AWS has no first-party equivalent, so the replacement is built in two phases. In Phase 1 (Wave 1), keep the Cloudflare AI Gateway running and add Bedrock as one more provider behind it — this decouples the model-cost win from the full migration and can begin paying off immediately. In Phase 2 (Wave 3), stand up LiteLLM on ECS Fargate as a self-managed cross-provider gateway, migrate the BYOK billing and per-tenant spend caps into it, and retire the Cloudflare gateway.
Guardrails economics. This is a common area of overspend. Use Bedrock Guardrails (Classic tier) only for controls that genuinely require a managed, audited service — PII, HIPAA, and GDPR redaction. For the semantic layer (prompt-injection detection, topic policy), run an open-source classifier such as Guardrails AI OSS (a DeBERTa-based model) on your own compute. At high interaction volumes the Bedrock Standard guardrail tier can become cost-prohibitive, and the OSS semantic layer performs the same job at substantially lower cost.
Model hosting and cost control. Host the open-weight and frontier models on Bedrock, and control cost with batch/flex pricing and prompt caching (which heavily discounts repeated context such as a long system prompt).
Example in practice. A per-tenant cost cap combined with model routing is the most frequently requested pattern. A low-effort request (for example, "show my saved search") routes to a small, inexpensive model, while a heavy request (for example, "analyze this long document") routes to a frontier model — and LiteLLM enforces a hard monthly dollar cap per tenant so that a single high-volume customer cannot run up the bill. Routing by request difficulty and capping by tenant together form the most reusable idea in this guide.
10. Lessons learned
- Cloudflare config exports can require parse fixups before the converter ingests them cleanly — budget a retry loop.
- Durable Objects have no clean one-to-one mapping — plan the DynamoDB + Valkey composition up front rather than discovering it mid-cutover.
- The R2-to-S3 one-time egress is a real line item; sequence it to minimize cost.
- Validate vector retrieval recall after re-indexing Vectorize; do not assume parity with the previous index.
- Keep AI Gateway running in parallel during Phase 1 so the model-cost win and the gateway rebuild remain decoupled.
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article