Cloudflare alternatives depend on which part of Cloudflare you need to replace. For CDN delivery and programmable cache behavior, compare Fastly, Akamai, and the cloud CDNs. For an existing AWS, Google Cloud, or Azure application, the matching cloud-edge stack may simplify ownership. For CDN-led sites, Gcore and bunny.net are worth testing. For security-led projects, include Akamai and Imperva. None is automatically a one-for-one replacement for Cloudflare's combination of authoritative DNS, CDN, WAF, DDoS protection, Workers, and logs. Cloudflare lists these as distinct products in its product documentation.
The eight options below are current products, not a ranking by speed or price. Check the named products and entitlements, then pilot the exact workload. The right result can be a combination—for example, a CDN from one provider and authoritative DNS from another—if that is easier to operate than recreating every Cloudflare feature under one logo. If the requirement is specifically no-cost service, use the separate free Cloudflare alternatives guide; this comparison covers product fit, not free-plan limits.
| Option | Starting point | Check before calling it a replacement |
|---|---|---|
| Akamai | CDN plus separately selected security, DNS, and edge products | Which Akamai products and contracts cover your existing rules and traffic |
| Fastly | CDN, Compute, and optional Next-Gen WAF | Authoritative DNS stays with another provider; confirm WAF deployment and entitlement |
| AWS CloudFront | CDN with AWS WAF, Shield, Route 53, and edge-function options | Several AWS services and log destinations must be designed together |
| Google Cloud CDN | CDN behind a Google external Application Load Balancer, paired with Cloud Armor | Load-balancer, CDN, Armor policy, and DNS are distinct decisions |
| Azure Front Door | CDN and global HTTP entry point with tier-dependent WAF | Standard has custom WAF rules; Premium has managed-rule capabilities |
| Imperva | Application and API protection, with CDN delivery available | Validate the CDN, WAF, DDoS, and bot scope in the proposed package |
| Gcore | CDN with separately described WAAP and DNS products | Confirm which security functions and exports your plan includes |
| bunny.net | CDN, DNS, and Bunny Shield | Shield features vary by tier; test edge-code and log-export needs |
The table describes a starting architecture, not a feature parity score. A product page saying “WAF available” does not tell you whether the required rule type is included in the proposed tier, whether its logs are enabled, or whether the same request headers reach your origin. Those details decide whether a migration works.
Akamai: broad delivery and security portfolio
Akamai is a candidate when the replacement spans delivery and protection rather than a single static-assets CDN. Its CDN portfolio, App & API Protector, Edge DNS, and Prolexic address different pieces of the Cloudflare setup. Akamai also offers EdgeWorkers for edge logic. Do not treat those names as one automatically included bundle.
This is a practical shortlist for a large multi-origin application that needs a CDN, application-layer policy, and an explicit DDoS design. The evaluation work is mapping Cloudflare rules and request behavior to the particular Akamai products being purchased. Ask how each origin is onboarded, which DNS changes are required, how certificates are managed, and where request and security logs go. If only one cacheable site needs delivery, this breadth may introduce more procurement and configuration work than the use case needs; that is an operating-model trade-off, not a performance verdict.
Fastly: CDN and programmable edge behavior
Fastly's CDN and Compute are relevant when request handling, caching, and edge code are part of application releases. Its Next-Gen WAF can be deployed at the edge or through other supported architectures; the documentation says the WAF is purchased for an account. Real-Time Log Streaming offers configurable destinations for delivery logs.
Fastly is not a simple DNS-for-DNS move: its traffic-routing documentation says it does not provide a managed authoritative DNS service. Keep your current DNS if appropriate, or choose a separate provider. Its HTTPS log destination also requires a domain-control verification challenge; it is not automatically compatible with an arbitrary log receiver. Before moving Workers-style logic, compare the actual APIs, execution limits, storage dependencies, and deployment process; “edge compute” is a category, not code compatibility. A short pilot with representative cache keys and WAF rules will reveal more than a generic speed claim.
AWS: CloudFront with WAF, Shield, and Route 53
For an AWS-operated application, CloudFront can deliver static and dynamic HTTP content from AWS or custom origins. AWS WAF can be attached to a distribution, while AWS Shield covers DDoS protection with Standard and Advanced offerings. Route 53 is the separate authoritative DNS choice. CloudFront Functions and Lambda@Edge cover different edge-code needs, not an automatic port of Workers code.
The attraction is keeping identity, deployment, and billing inside an AWS estate. The trade-off is coordinating several services: a CloudFront cache behavior is not a WAF rule; a Route 53 zone is not created merely by enabling the CDN; Shield Advanced is not the same entitlement as Shield Standard. Check log types and destinations separately, including CloudFront access data and WAF events, before declaring observability complete. The cost model should use your own traffic, requests, rules, functions, and exported-log volume, rather than a single CDN rate.
Google Cloud: Cloud CDN with Cloud Armor
Cloud CDN caches HTTP content behind a supported external Application Load Balancer. Cloud Armor adds edge security policies, including WAF and DDoS controls. This combination is a sensible starting point for a site already using Google load balancing and Cloud Logging, but the load balancer, caching configuration, security policy, and Cloud DNS are distinct components.
One detail matters when migrating WAF rules: Google's Cloud CDN overview distinguishes edge security policies, evaluated before the CDN cache lookup, from backend security policies, which apply to requests destined for the origin, such as cache misses. A policy attached at the wrong boundary may not inspect the traffic you expected. Test cache hits and misses, signed content if used, origin headers, and rule actions. Avoid assuming that a Google edge extension is a drop-in replacement for Workers; inventory the actual logic first.
Azure: Front Door Standard or Premium
Azure Front Door combines global HTTP routing, CDN capabilities, and origin protection. Its WAF capability depends on tier: Microsoft's Front Door WAF documentation says Standard supports custom rules, while Premium supports full WAF capabilities and managed rule sets. A recommendation that simply says “Front Door includes WAF” hides a material difference.
Microsoft also describes built-in platform-level network DDoS protection for Front Door. A separate Azure DDoS Network Protection plan is not a universal Front Door prerequisite; evaluate that separately for public-IP origins or other Azure resources that need it. This option fits an Azure-centered application when Front Door routes, certificates, WAF policies, and diagnostics can follow existing Azure operations. Note that access, health-probe, and WAF diagnostic logs are not enabled by default. Enable and test the required categories during a pilot, not after cutover.
Imperva: security-led application delivery
Imperva's Cloud WAF and DDoS protection make it worth evaluating when application protection leads the purchase. Imperva also documents a CDN product, so it should not be dismissed as WAF-only. Its fit depends on the proposed combination of delivery, WAF, bot, API, and DDoS services—not on the broad “application security” label.
Start with the attacks and application paths you actually need to handle: login abuse, API rules, false-positive review, origin exposure, and incident log access. Then verify which Imperva deployment mode and service package inspects those paths. If your main reason to leave Cloudflare is a large Workers codebase, a security-led evaluation does not answer the compute migration on its own. Conversely, if the core problem is WAF policy ownership, comparing JavaScript runtimes first would miss the decision.
Gcore: CDN plus optional security scope
Gcore CDN is a delivery candidate for websites, downloads, and media. Gcore separately describes WAAP, which includes WAF, bot, API, and application-layer DDoS capabilities, and DNS. Its product pages show that some security capabilities depend on the selected plan or add-on, so verify the actual proposal instead of calling all of them “built in.”
Test the same static and dynamic URLs you serve today. Check origin fetches, cache-key controls, TLS, security rule actions, and request-log export. Gcore's CDN page confirms current delivery and security offerings, but that does not establish how every log field reaches your chosen destination. Ask for the current export method and a sample event from the plan you intend to use. Older blog posts about raw-log export are not enough to prove current entitlement or format.
bunny.net: CDN-first with DNS and Bunny Shield
bunny.net CDN centers on pull zones and content delivery. Bunny DNS and Bunny Shield cover separate DNS and security needs. This makes bunny.net a candidate when the Cloudflare use case is mainly web assets or straightforward site delivery. It is not proof that an existing Workers application or complex WAF policy can be transplanted unchanged.
Security scope is tier-dependent. For example, bunny.net's custom WAF rule documentation requires an Advanced Shield plan or above. Its CDN log-forwarding documentation describes a Syslog path but also warns that UDP forwarding can lose events and is unencrypted. Do not make that path the sole source of a complete security audit trail without examining the transport and requirements. Test cache behavior, Shield actions, and the precise log format before moving production traffic.
Why Edgio is not on this list
Older Cloudflare alternatives lists still recommend Edgio as a live CDN choice. That is outdated. In December 2024, Akamai said it acquired selected Edgio assets and customer contracts, not Edgio's network, and described customer migration before Edgio's content-delivery network ceased operations. Edgio should not be presented as a current standalone CDN candidate. Its legacy features are not a reason to start a new evaluation there.
Check the migration boundary before changing traffic
A useful comparison starts with your current Cloudflare configuration, not eight vendor demos. Record the functions you actually use and the traffic they touch:
- DNS and certificates: Identify the authoritative DNS provider, all zones and records, DNSSEC if enabled, certificate ownership, and whether the CDN move requires any nameserver change. A CDN switch does not always require moving authoritative DNS.
- CDN behavior: List origins, cache rules and keys, redirects, query-string and cookie handling, signed content, purge process, and which pages must never be cached. Compare responses on cache hits and misses.
- Security controls: Inventory WAF and rate rules, bot challenges, API policies, origin allowlists, and network-layer DDoS requirements. Map each rule to a product and tier. Test false positives with legitimate users before enforcing a new blocking policy.
- Edge code: List each Worker route, runtime API, binding, storage dependency, and deployment step. Rebuild or replace behavior deliberately; a product with “edge compute” is not source-compatible by default.
- Logs and cost: Choose the request, WAF, and origin events needed for incident review. Verify that each export is enabled, arrives in the expected format, and does not capture unnecessary credentials or personal data. Estimate CDN egress, requests, security inspection, functions, and log delivery using your own traffic sample.
Use a staging hostname or a controlled traffic slice to compare an actual page, an API request, a cache miss, and a deliberately triggered WAF rule. Record what the client sees, what reaches the origin, and what each log source records. This exposes header, cache, and policy differences that a feature matrix cannot show. It also keeps “same features” from being mistaken for “same behavior.”
Fluxtail is a paid log-search product, not a Cloudflare replacement or a CDN/WAF. It can search edge and origin logs only after they are sent through a supported ingest path and associated with the right account. Do not assume a native pull integration with Cloudflare or any provider here. If centralized investigation is part of the migration, plan and verify the export path alongside the edge configuration; log management is the separate job.