Cloudflare vs AWS, Alibaba Cloud and Tencent Cloud: Do You Need Both?

Short answer: They answer different questions. AWS, Alibaba Cloud and Tencent Cloud answer where your application runs, where its data lives and how much compute it gets. Cloudflare sits in front of whichever of those you already use and answers how users everywhere reach it — DNS and routing, TLS, caching, attack absorption, bot filtering, and identity-based access to internal tools. Your servers do not move; the Cloudflare documentation even defines the origin server as “a physical or virtual machine that is not owned by Cloudflare”. Overlap does exist at the delivery layer, and Cloudflare ships compute and storage too, so the honest answer is “mostly complementary, partly duplicative — decide based on your actual architecture and requirements”.

Two different questions, two different layers

Look at what you actually buy from each side.

A cloud platform exists to answer four questions: where does this application execute, where does its data live, how much compute does it receive, and who inside the organisation is allowed to administer it. Everything in the console — instances, object buckets, managed databases, VPCs, IAM roles, backup policies — is there to answer those four questions.

An edge network exists to answer a different set: can a user in Bangkok or Bogotá actually reach that application quickly, does the connection survive when someone attacks it, is it encrypted the whole way, does it stay reachable when one region is unhealthy, and can a staff member open the admin panel without tunnelling into a VPC?

Those are not two vendors doing one job. They are two halves of one request path. The split is visible even in how each side defines itself: the Cloudflare fundamentals documentation describes the origin server as “a physical or virtual machine that is not owned by Cloudflare”, and describes the service as reverse-proxying traffic “on its way between the client and the origin server”. Your EC2 instance, your Alibaba Cloud ECS cluster, your Tencent Cloud CVM — none of them move. This is why “we already bought a cloud” and “we need an edge network” are not contradictory statements.

One thing this section is not saying: that your cloud’s own CDN, WAF or DDoS products are somehow lacking. Amazon CloudFront, Alibaba Cloud’s edge offerings and Tencent Cloud EdgeOne are mature, well-resourced products that are absolutely the right answer for a large number of estates. The question in front of you is narrower: given the architecture you already have, is there value in a third-party edge that is independent of where any single workload lives — its anycast network reach, the ability to front origins on different clouds, the way its products are bundled, and one control plane across all of them. Sometimes the honest answer is no, and Section “A short selection table” below says so explicitly.

Question being answered	Run layer (the cloud you already pay for)	Reach layer (the edge in front)
Owns	Compute, storage, databases, VPC topology, IAM, backups	DNS resolution, TLS, anycast routing, caching, DDoS absorption, WAF, bot controls, Zero Trust access
Unit you buy	vCPU, GB-months, IOPS, request volume	Plan plus selected add-ons; unmetered L3/4/7 DDoS protection on every plan, including Free
Failure looks like	Application errors, slow queries, capacity ceilings	Users cannot connect at all, or something in front of the origin is saturated
Where it must live	Near the data and inside your compliance boundary	Near the user
Cost of changing	Migrating workloads is a project measured in months	Usually lower, but never a single DNS change: DNS or CNAME adjustments, certificate issuance and deployment, origin access-control changes, rebuilding cache policy, application compatibility checks, staged cutover with a rollback plan, then per-hostname regression testing

Those two tiers can be arranged in more than one way. Figure 2 shows the two that matter most in practice — and neither is universally better.

In pattern A, adding anything in front tends to add cost and failure modes without changing much: there is one origin estate, one set of credentials, one support relationship, and usually one dominant user geography. In pattern B the same edge can be reasoned about once instead of once per environment, which is where it pays for itself — and even then, only for the hostnames actually proxied and the products actually enabled on them.

Where they genuinely overlap

Three points worth stating up front, so the rest of the discussion starts from shared facts.

Each cloud already ships an edge. Amazon CloudFront is documented as a CDN with hundreds of points of presence plus regional edge caches; Alibaba Cloud ESA is described as an upgrade over DCDN with thousands of nodes and 180 Tbps of capacity; Tencent Cloud EdgeOne is documented as one platform bundling CDN, DDoS mitigation, WAF, bot management, layer-4 proxying, edge functions and DNS. None of these are weak products. If your entire estate lives inside one cloud and your users are concentrated near whichever regions you already use, adding a second edge for delivery alone is usually unnecessary — whether an extra layer is worthwhile depends on your actual architecture and requirements.

Cloudflare also sells compute and storage. Workers, R2, D1 and KV mean the sentence “Cloudflare is only delivery” is not strictly true. R2 in particular is marketed on zero egress fees and S3-compatible APIs, and teams do move object storage onto it. The useful distinction is centre of gravity, not absolutes: nobody moves a primary transactional database off a hyperscaler to an edge network, and Cloudflare’s developer platform is optional rather than a prerequisite — you can adopt the delivery and security layer and never deploy a Worker.

Pricing differs per product, and the useful question is what each one meters. One fact is real and worth stating precisely: every plan, including Free, includes basic DDoS protection, and unmetered layer 3/4 and HTTP DDoS protection is not billed per attack packet or per attack request. That alone does not justify extending it to “Cloudflare is a flat subscription” or “the bill stays the same during an attack” — nothing about other product lines follows from it. Managed rules and the WAF arrive inside paid plans rather than being priced per rule, while Bot Management, API Shield, Load Balancing, Zero Trust seats, Log Explorer retention, Spectrum, Magic Transit and several others each carry their own plan availability, metering basis, add-on status and contract terms. The same applies in reverse on your cloud bill. So compare line by line: which plan includes it, what it meters, and what the bill does during an incident. It is the reason high-end DDoS tiers tend to be sold as fixed commitments with large included allowances — nobody wants attack volume arriving as a variable charge.

Four things the cloud’s own edge products usually aren’t the answer to

Framed carefully: not “cannot”, but “not what they were designed for”.

1. One policy across several places. Real estates are messy — web tier on AWS, something else running in an Alibaba Cloud region for a specific market, an ERP in your own data centre, two services you acquired still on whoever’s account they came with. A per-resource control surface means you repeat every decision in every environment, each with its own console, log format and bill, and each is one forgotten resource away from an unprotected entry point. An inspecting proxy gives you one place every request goes through, regardless of what sits behind it. That said, the scope has to be stated honestly: it is one place for the traffic that actually flows through Cloudflare, with the products you have actually enabled. It does not reach into anything inside your clouds — IAM policies, VPC security groups, database accounts and object-bucket permissions stay under each provider’s own control plane, and their native audit logs (CloudTrail, action trails and equivalents) are not collected or unified by it. Exactly what you can unify also depends on which hostnames are proxied and which products are enabled and available on your plan; log retention, field sets, permissions and analytics still differ per product.

2. Stop publishing your origin. If the origin still answers the public internet directly, an attacker does not need to go through your controls at all. The documentation offers more than one answer here, and the strength differences matter:

• Allowlisting Cloudflare’s IP ranges at the origin firewall is the simplest, but Cloudflare’s own documentation rates it only moderately secure and notes that it remains vulnerable to IP spoofing.

• Authenticated Origin Pulls is mutual TLS from the edge to your origin, available on all plans. Use zone-level or per-hostname configuration with your own certificate rather than the shared global certificate, which is what actually binds it to your account. Note it only applies under Full or Full (strict) encryption modes, and it does not apply when you use a tunnel, because there is no inbound listener to present a certificate to.

• A tunnel removes inbound entirely. cloudflared dials out and holds long-lived connections to the nearest data centres, and the official material is explicit: no public IP required, no open inbound ports, no inbound attack surface. It is available on all plans, and the documentation covers HTTP, SSH, RDP and raw TCP — but those four sit in three genuinely different usage modes, which is where readers get misled:

  • HTTP services are published with a public hostname plus ingress rules; a browser or API client reaches them directly. Straightforward, available on every plan.
  • SSH, RDP and similar client-side protocols are not “a TCP port published at a URL”. Either the connection runs through Zero Trust policy with browser rendering, or the accessing machine runs cloudflared locally and connects through it (commonly mapping user identity to a short-lived certificate). Write the runbook accordingly — operations staff who expect ssh app.example.com will not get what they imagine.
  • Arbitrary TCP normally means the client runs cloudflared locally, or uses a WARP client together with the tunnel’s private-network routes, and then connects to a local port. Nothing appears as a plain public endpoint that anyone can address.
  • Whole-private-network reachability — tunnel plus WARP client plus CIDR routes — is again a different configuration from publishing a single hostname.

  All of them depend on outbound connectivity: the daemon has to dial out, which is where cloud security groups, NAT gateways and proxy settings either cooperate or quietly break the design.

Three things teams get wrong here. Hiding an origin is not the same as making it undiscoverable. Historic DNS records, certificate transparency logs, third-party integrations that were given the address years ago, YAML committed to the wrong repository, and even your own applications making outbound calls can all leak it. Assume discovery is possible eventually and keep control at the origin too: a firewall that only accepts what it should, IP allowlisting where you rely on it, or — with a tunnel — simply no inbound listener at all. Second, do not confuse the two authentication halves. Who the user is to Cloudflare is decided at the edge (Zero Trust policy, mTLS to visitors, certificates issued to clients); who Cloudflare is to your origin is decided by Authenticated Origin Pulls or by tunnel credentials. They are different credentials with different lifetimes, and mixing them up is how teams end up hardening one connection while leaving the other wide open. Third, none of this substitutes for the origin’s own controls — an allowlist that nobody reviews drifts, and a tunnel that bypasses the edge for DNS-only records protects nothing.

3. Internal applications, which is usually where the real risk sits. The public web tier tends to be well defended; what bites is an admin backend, Jenkins, Grafana, a support console, a staging site with production credentials. That is an access-control problem wearing a networking costume, and adding CDN features to the public site does nothing for it. Identity-aware policies, per-application rules and short-lived sessions address it directly.

4. What happens when one origin has a bad day. If all your traffic goes to a single region, no amount of front-door engineering helps when that region is unhealthy. With Load Balancing configured with health-checked origin pools, an endpoint is documented simply as anything that intercepts and processes traffic — another cloud, another region, or a host reachable only through a tunnel — so a provider incident becomes a routing event instead of an outage. Treat it as its own line item: Load Balancing is a separately purchased add-on with its own pricing and configuration surface, not a feature that arrives automatically with DNS hosting, and the same caution applies to Argo Smart Routing, which is likewise a metered paid service rather than a plan default.

Three ways to put it in front of what you already have

Pick the access model before arguing about features, because this choice constrains everything else.

Setup	What actually changes	Plan requirement
Full setup (Cloudflare as primary DNS)	Cloudflare manages authoritative DNS for the zone; proxying is switched on per hostname, one record at a time	All plans. Free and Pro zones can only use this mode
Partial setup (CNAME)	Your existing authoritative DNS provider stays authoritative; only the hostnames you point at Cloudflare are proxied	Business and Enterprise. Not supported for domains registered with Cloudflare Registrar
Zone transfers	Enables AXFR/IXFR between Cloudflare and another DNS provider across the whole zone. Configurable with Cloudflare as either primary or secondary — secondary is one option, not the definition	Enterprise
Subdomain setup	A delegated subdomain is managed as its own zone, with its own settings and potentially its own account, separately from the apex	Enterprise

Plan requirements change: treat the table as a summary of what the zone-setups documentation said at the time of writing and verify the current wording before you commit to an architecture that depends on it.

Four clarifications that prevent most design arguments later:

• Full setup is about DNS delegation, not automatic proxying. Moving authoritative DNS to Cloudflare gives you the option to proxy a hostname; only records whose proxy status is enabled actually send traffic through Cloudflare. Records left DNS-only are answered by Cloudflare’s nameservers and then connect straight to your origin, seeing none of the CDN, WAF or bot features. Inventory your records with that in mind — “we migrated to Cloudflare” and “everything is protected” are not the same sentence.
• Not every DNS record type can be proxied at all. Only A, AAAA and CNAME records support proxying. Anything else — MX, TXT, SRV, NS, and most non-web record types — stays DNS-only by definition, which is also the reason a security review should start from the list of proxyable records rather than from “the domain is on Cloudflare”.
• Partial (CNAME) setup is not full DNS hosting. Your existing DNS provider remains authoritative for the zone. Consequences worth knowing before you pick it: DNS-level DDoS protection for the zone’s infrastructure is documented as available only on Full setup, because partial zones do not use Cloudflare’s authoritative nameservers; and proxying the zone apex requires your authoritative provider to support CNAME flattening, since RFC-compliant CNAME records cannot sit at the apex. Confirm which of those you actually need before treating the two setup modes as interchangeable.
• Zone transfers are a spectrum, not a single role. You configure one side as primary and the other as secondary via AXFR/IXFR; if a registrar or another provider must remain authoritative, that is a different configuration from Cloudflare serving as secondary. Write down which one you are buying before procurement writes down something else.

The second decision is how connections to the origin work: keep a public origin that answers only validated traffic, or use a tunnel so the origin has no inbound ports at all. Treat that as its own decision rather than a preference — it depends on how your network is segmented, whether outbound-only connectivity is acceptable, and how much operational change your team can absorb.

Three rules of thumb follow directly from that table:

• DNS cannot be touched (change control, a parent zone you do not control, a registrar policy): you need Partial (CNAME) setup, which means Business or above.
• Hiding the origin is the priority: a tunnel, which works on every plan and is documented for the AWS private-subnet case.
• You are also missing cross-origin failover: treat it as a separate line item rather than a feature that comes along with everything else.

A worked example: AI SaaS on GPU infrastructure

Nothing below is a customer case, and there are no performance numbers in it. It is a shape that shows up often enough to be worth sketching, offered as a reference architecture rather than a result anyone should quote.

• Workload. An image- or video-generation API. GPU inference runs on AWS instances or a managed inference platform, artefacts sit in object storage, and users are distributed across several overseas markets rather than concentrated next to one region.
• What actually hurts. Not raw bandwidth — unit economics. Scripted signups drain trial credits, expensive endpoints get called harder than any per-request threshold catches, a handful of concurrent callers can fill the GPU queue before request counts look anomalous, and one leaked trial key turns into a bill rather than an incident.
• What belongs at the edge. Rate limiting tied to expensive endpoints and to identities rather than source IPs alone; bot controls that separate automated callers from your own SDK traffic, CLI tools and partner integrations; WAF logic tuned to the parameter shapes your API actually accepts; and, where it fits your plan and budget, API discovery with schema validation so requests that do not match the contract are rejected before inference starts. Cache what is genuinely cacheable instead of recomputing it.
• What stays in your own stack. Application-side authentication and authorisation, per-tenant quotas, usage accounting and billing, and business risk rules — refund abuse, trial farming, account reselling. These read your own state and encode decisions only your product can make. A proxy sees requests; it does not know who owes you money.
• The honest framing for review. The edge lowers the volume of obviously bad traffic and gives you request-side control near the caller; quota semantics and any genuine abuse economics have to exist in your own API layer. Buying the first and expecting the second is the most common way this kind of evaluation goes wrong.

A short selection table

Read this as a triage aid, not a buying recommendation. Every row still has to be tested against your real architecture, measured traffic and user geography.

Your situation	Worth evaluating Cloudflare?	Why
One cloud, users concentrated in one region	Not necessarily	The cloud’s own CDN, WAF and edge are usually sufficient; a second edge for delivery alone is often duplicate spend
Multi-cloud, users distributed globally	Worth evaluating	Cross-cloud traffic management and one place to apply edge policy across different origins
AI SaaS with high-frequency API traffic	Worth evaluating	API abuse and anomaly control, bot management, rate limiting close to the user
AI image or video generation with costly inference	Worth evaluating	Blocking automated abuse and anomalous traffic before it reaches expensive compute
Already have a CDN, but the origin is still reachable from the internet	Worth evaluating	Origin access control, Authenticated Origin Pulls and tunnels

“Not necessarily” in the first row is doing real work: if your estate genuinely lives in one place, the honest answer is often to stay there. Once the requirement crosses an origin boundary, a policy boundary or an access-control boundary, the reasoning changes.

When does Cloudflare Enterprise make sense?

Not as a status purchase, and not because headcount passed some threshold. Enterprise becomes relevant when a specific, nameable requirement lands on the Enterprise-only side of the plan table:

• Deeper rule customisation. More complex WAF expressions, custom rules at greater depth, tuned managed rulesets and bespoke logic for business-specific flows.
• Enterprise-grade bot management and API security. Behavioural bot detection with tuned feedback loops, and API discovery, schema validation and positive security for APIs — current capability and licensing depend on the contract, not on a generic tier name.
• Governance across many domains, business units and teams. Multiple accounts and teams under one organisation, delegated permissions, separation between production and staging, and audit expectations that span all of it.
• Support, response commitments and contract terms. Named support paths, response targets, escalation routes and commercial terms negotiated rather than clicked.
• Products with an explicit plan floor. Magic Transit is an example: it is not available by default and carries a separate subscription with separate conditions.
• Architecture work in complex environments. Design review, migration planning and ongoing tuning when several clouds, legacy networks and internal applications are involved.

Two things to keep straight. Plenty of capability exists below Enterprise — Full DNS setup, tunnels, Authenticated Origin Pulls, unmetered L3/4/HTTP DDoS protection and a large part of the WAF are not Enterprise-exclusive — so starting there and upgrading later is a legitimate path. And Enterprise is not a bundle in which everything is included automatically: bots, API security modules, analytics depth and some support elements are frequently separate line items. Confirm them against a quote rather than a plan page.

A practical way to frame the three paths:

• Baseline. Nothing is visibly wrong with the current architecture; you need caching and fundamental protection. Cloud-native edge services may be enough, or a lower Cloudflare tier with handful of features enabled. Do not buy more than the requirement.
• Advanced. you need serious WAF tuning, bot controls, API security, access policy, Partial (CNAME) setup because DNS cannot move. This is where many companies land, whatever plan name it maps to in your case.
• Enterprise. There is a concrete requirement — customised rules at depth, large-scale bots and API programmes, multi-team governance, negotiated SLA terms, or Magic Transit. Evaluate it when the requirement appears; skip it when it does not.

A rollout sequence that avoids the usual mistakes

1. Inventory every origin you actually have — cloud, region, public IP, owning team. Most organisations find one nobody remembered, and in incidents that is usually the one hit first.
2. Decide DNS first. Everything downstream depends on this one choice, and reversing it later is more disruptive than getting it right early.
3. Choose how the origin will validate who it is talking to — allowlist, mutual TLS, or tunnel — and implement it before cutover. Whitelisting afterwards means there was a window where the protection was decorative.
4. Cut over one hostname, then the rest. Single change, observable blast radius, no heroics at midnight.
5. Verify from outside that the origin cannot be reached directly. If it can, none of the above is load-bearing.
6. If you keep a per-cloud edge somewhere, decide which layer logs authoritatively — and confirm the other layer preserves the client IP your rules depend on. Two independent layers that each rewrite headers is a debugging tax that never expires.

Boundaries and non-applicable cases

• None of this makes your application secure. Input validation, authorisation, parameterised queries and secrets handling are still yours. A CDN in front of an application with a broken authorisation check will happily cache and deliver the same result faster.
• One governance boundary is a legitimate choice. If your organisation requires a single IAM model, one audit trail and one procurement relationship, keeping inspection inside the cloud you already use can be the right answer even when it is technically less convenient. Say it out loud in the review meeting.
• Data residency can force a regional answer. Some requirements genuinely point at inspection inside a specific jurisdiction rather than at a global anycast edge.
• Stacking two edges is a decision, not a default. Double termination, competing cache policies and two layers of bot challenges are real costs, and the users who suffer are the legitimate ones.
• Plan thresholds move. Everything above is per current documentation; confirm terms at purchase time rather than from an article.

FAQ

We already pay for CloudFront, ESA or EdgeOne. Isn’t paying another vendor duplication? At the delivery layer, sometimes genuinely yes — if your estate is inside one cloud, your users sit near its regions, and your only goal is caching and static delivery, adding a second edge is hard to justify. The argument returns when the requirement crosses boundaries: multiple origins in different places, stopping the origin from being publicly reachable, attack economics that should not appear on a usage bill, or access policy for internal applications. Decide on those four, not on performance alone.

Does adding Cloudflare mean migrating away from AWS, Alibaba Cloud or Tencent Cloud? No. It sits in front of what you have. Nothing about it moves your compute, your data or your accounts, and with Partial (CNAME) setup it does not even move your DNS.

Can we keep DNS where it is today? Yes, with Partial (CNAME) setup, which requires Business or above. Free and Pro plans use Full setup, where authoritative DNS is delegated to Cloudflare.

Will an extra hop make latency worse? For users far from a single-region origin, it usually improves: cached responses, fewer round trips and better routing beat the addition of one hop. If your users and your origin are already in the same country and already served by that cloud’s own edge, the gain shrinks and can go negative. Measure it per market before committing.

We are multi-cloud. Where does it actually help? Within the traffic it proxies and the products you have enabled, it lets you manage part of your edge security and traffic policy from one place instead of repeating every decision in every cloud account — that is the honest scope, not “one policy, one log, one bill” for your entire estate. Log retention, permissions, available features and analytics still differ per product, and per plan. Failover is the other side: health-checked origin pools can mix providers, so trouble at one becomes a routing event rather than an outage.

Do we need Enterprise for this? Usually not to begin with. Full DNS setup, tunnels, Authenticated Origin Pulls and unmetered L3/4 and HTTP DDoS protection are available below Enterprise, and much of the WAF is too; Business is what unlocks Partial (CNAME) setup, regular expressions and richer rate-limiting options. Enterprise becomes relevant for a specific requirement — customised rule depth, behavioural bot management and API security at scale, governance across many teams and domains, negotiated SLA and response terms, or a plan-gated service like Magic Transit. Treat it as requirement-driven rather than size-driven; see the Enterprise section above for the full list, and confirm line items against a quote.

Does adding Cloudflare mean turning off CloudFront, ESA or EdgeOne? Not automatically. Some estates run both during migration, or keep a cloud CDN for specific workloads while Cloudflare fronts public entry points. Running two layers is not free: each one adds TLS termination, header rewriting and another place configuration can drift, so decide which hostnames go through which layer and document it. Above all, confirm the downstream layer preserves and validates the real client IP — otherwise your rules, rate limits and logs are reasoning about the previous proxy instead of the user.

Is this just another way of asking “CDN or cloud-native edge first”? No, and the distinction matters for the review meeting. “CDN or cloud CDN” is a delivery question that “how many points of presence, what cache-hit ratio” can settle with measurements. This question is about who owns which half of the request path, and it is settled by architecture — how many origins you have, whether any of them need to stop answering the internet, and where access control belongs.

Isn’t this the same question as Cloudflare WAF vs AWS WAF? Related but narrower. That comparison is about which layer inspects a request; this one is about who owns which half of the request path.

Related reading

• Cloudflare WAF vs AWS WAF: which layer inspects the request?
• Can a CDN Protect Your Website from DDoS Attacks?
• How to Choose DDoS Protection for Global Businesses
• Telling legitimate bots and real users apart
• What to do when an API key leaks
• AI SaaS API abuse: what changes when callers are scripts
• CDN capabilities
• Network performance solution