The article titled Can Cloudflare Replace AWS? A Technology Selection Guide for Experienced Infrastructure Engineers (Zenn) attracted wide attention. Aimed at engineers who understand AWS fundamentals like VPCs, load balancers, Lambda, S3, and RDS but lack experience with Cloudflare's developer platform, it emphasizes the importance of determining whether Cloudflare fits your project based on design philosophies rather than memorization.
From our perspective supporting system development and infrastructure in custom development, we view this not as a binary question of Cloudflare vs. AWS, but as an architectural challenge of determining which platform to favor, how far to go, and how to migrate based on latency requirements, costs, data residency, and operational structure. Whether you need edge-first, globally fast, low-cost delivery, or full-stack managed services with an extensive ecosystem—making the wrong choice makes future rebuilds expensive. Connecting with the edge implementations covered in Hono + Cloudflare Workers Edge API Development for Clients (GH Media), the cloud selection criteria covered in Cloud Selection in the Age of Cloudflare and AI Agents (GH Media), and the single-dependency risks covered in Business Continuity Design Lessons from Railway and GCP Outages (GH Media), this article organizes our approach to delivering “infrastructure technology selection and migration” in custom development.
Why selecting between Cloudflare and AWS matters right now
| Dimension | AWS (full-stack) | Cloudflare (edge-first) |
|---|---|---|
| Design philosophy | Region-centric, rich service ecosystem | Edge-distributed, single global network |
| Compute | Lambda / ECS / EC2 | Workers (edge execution) |
| Storage | S3 + egress billing | R2 (zero egress fees) |
| DB | RDS / Aurora / DynamoDB | D1 / Durable Objects |
| Strengths | Ecosystem and existing assets | Low latency and transfer costs |
| Learning | Broad and deep | Requires a shift in design philosophy |
Ultimately, this question is not about “which feature set is superior,” but rather “how to apply differing design philosophies to project requirements.” In custom development, providing suitability assessments and phased migrations enables an optimal cost structure while avoiding over-investment and rewrites.
Three structural changes beneficial to custom development projects
Structure 1: Moving from trend-driven choices to project-driven decisions
Choosing a platform simply because “everyone uses it” invites failure. In custom development, we evaluate projects against latency requirements, transfer volumes, data residency, and operational structures to recommend the optimal platform for each project backed by clear rationale.
Structure 2: Moving from full migrations to right-tool-for-the-job hybrid setups
You don't have to move everything. In custom development, we allocate workloads by putting static delivery and edge APIs on Cloudflare while keeping heavy compute and existing assets on AWS, designing hybrid architectures that maximize the strengths of both.
Structure 3: Moving from unmanaged vendor lock-in to built-in exit strategies
Relying deeply on vendor-specific proprietary features makes future migrations difficult. Drawing on insights from Business Continuity Design Lessons from Railway and GCP Outages (GH Media), we deliver designs that clearly define degrees of lock-in and exit costs.
The 5 phases of infrastructure technology selection and migration delivered in custom development
Phase 1: Suitability assessment (1–2 weeks)
- Audit current configuration, costs, and operational effort
- Organize requirements for latency, transfer volume, and data residency
- Evaluate lock-in degree and exit costs
- Score platform suitability
Phase 2: Architecture design (1–2 weeks)
- Placement design (edge / region / hybrid)
- Data tier design (R2 / S3 / D1 / RDS)
- Authentication, networking, and security design
- Cost estimates (transfer, compute, operations)
Phase 3: Migration setup (3–6 weeks)
- Make infrastructure reproducible using IaC (Terraform / Wrangler / CDK)
- Phased migration (parallel runs → weighted routing cutover)
- Establish CI/CD, monitoring, and logging
- Benchmark performance and actual costs
Phase 4: Validation & cutover (1–2 weeks)
- Comparative validation of performance, latency, and costs
- Fault tolerance and failover testing
- Phased traffic switching and rollback testing
Phase 5: Operational optimization (ongoing)
- Cost monitoring and optimization
- Review multi-cloud and redundancy strategies
- Track platform updates
Standard technology stack set for custom development
| Layer | Favoring Cloudflare | Favoring AWS |
|---|---|---|
| Compute | Workers | Lambda / ECS Fargate |
| Static delivery | Pages + CDN | CloudFront + S3 |
| Storage | R2 (zero egress fees) | S3 |
| DB | D1 / Durable Objects | Aurora / DynamoDB |
| IaC | Wrangler / Terraform | CDK / Terraform |
| Perimeter | WAF / Zero Trust | WAF / various managed services |
Which projects suit Cloudflare vs. AWS
| Suited for Cloudflare | Suited for AWS |
|---|---|
| Global low-latency delivery | Heavy compute and large-scale batch jobs |
| High transfer volumes and heavy egress costs | Substantial existing AWS assets |
| Centered on static assets + edge APIs | Heavy use of managed databases and analytics |
| Need to launch small and fast | Complex enterprise requirements |
| Desire to keep operations as lean as possible | Dedicated infrastructure team in place |
Six clauses to include in client contracts
| Clause | Details | What the client should verify |
|---|---|---|
| Selection rationale | Evaluation axes and scores | Agreement on prerequisites |
| Target scope | Migration scope / number of environments | Handling of peripheral systems |
| Cost premises | Transfer and compute estimates | Surge caps and alerts |
| Exit design | Degree of lock-in | Migration cost to another provider |
| Cutover approach | Phased cutover / rollback | Downtime tolerance |
| Handover | IaC / runbooks / training | Internal operational continuity |
Client-side ROI estimate (assuming high-traffic web service / partial edge migration)
| Item | Current (AWS standalone) | Needs-based hybrid | Difference |
|---|---|---|---|
| Monthly transfer and delivery costs | ¥220,000 | 90,000 yen | -130,000 yen |
| Global response | Region-dependent | Accelerated at the edge | Improved experience |
| Operational workload (monthly) | 36 hours | 18 hours | -18 hours |
| Blast radius during outages | Single point of dependency | Distributed and redundant | Enhanced business continuity |
| Annual benefit | — | — | Approx. 1.56 million yen delivery cost reduction + improved UX and continuity |
Even factoring in upfront migration costs and ongoing operational expenses, the savings in delivery costs and reduced operational overhead provide ample justification in many cases.
Five common pitfalls
Pitfall 1: Migrating entirely just because it's “fast and cheap”
Architectural differences will force rewrites. Allocate workloads appropriately based on project characteristics.
Pitfall 2: Placing heavy workloads without considering edge constraints
You will hit execution limits. Offload heavy compute to regional architectures.
Pitfall 3: Neglecting data residency and compliance
This risks regulatory violations. Confirm data residency during early design stages.
Pitfall 4: Overlooking vendor lock-in
Exiting will become impossible. Design with explicit exit costs in mind.
Pitfall 5: Failing to implement cost caps and monitoring
Transfer and execution spikes can inflate bills. Cost alerts must be mandatory.
90-day action plan
| Week | Action |
|---|---|
| Week 1〜2 | Suitability assessment + requirement definition + cost estimation |
| Week 3〜4 | Architecture design + exit design |
| Week 5〜10 | IaC setup + phased migration + parallel runs |
| Week 11〜12 | Performance / cost validation + cutover |
| Week 13 | Monitoring setup + start of maintenance |
Conclusion — Moving from a binary choice to the right tool for the job based on project characteristics
The essence of whether Cloudflare can replace AWS lies in how you map differing design philosophies to your specific project. In custom development, supporting infrastructure by evaluating fit across latency, cost, data residency, and operations, assembling a right-tool-for-the-job hybrid architecture, and delivering it with exit strategies included via “infrastructure technology selection and migration” serves as the realistic answer to avoid over-investment and costly rework.
Whether you want to “determine if shifting to Cloudflare makes sense,” “lower transfer and operational costs,” or “mitigate dependency on a single cloud provider,” our approach adapts to the scale of your current setup and migration scope. We provide tailored estimates upon discussing your requirements, so please feel free to start by reaching out via our contact form.
Sources
- Can Cloudflare Replace AWS? A Technology Selection Guide for Experienced Infrastructure Engineers (Zenn 2026-06-01)
- Hono + Cloudflare Workers Edge API Development (GH Media)
- Cloud Selection in the Age of Cloudflare and AI Agents (GH Media)
- Business Continuity Design Lessons from Railway and GCP Outages (GH Media)
- AWS Interconnect Multi-Cloud and Private Network Design for Clients (GH Media)
