Skip to content

PRODUCT FIELD GUIDE

Start with the problem.

24 product cards: when to use them, when not to, and how to explain the decision to engineering and finance.

Product descriptions link to official documentation. Examples are hypothetical; CTO/CFO explanations are original advisory framing. Product limits, plans and pricing differ. Validate these for each real proposal.

DNS

DOCUMENTED PRODUCT · ORIGINAL ADVICE

What it is: Authoritative DNS publishes the records that tell resolvers where a domain’s services live. It is distinct from Cloudflare’s public recursive resolver, 1.1.1.1.
Problem it solves: It removes the need to operate authoritative nameservers and gives administrators a central place to manage application, mail, and verification records.
When to use it: Use it when migrating a public zone, managing records through automation, or adopting proxy services for eligible web hostnames.
When not to: Do not expect a DNS-only record to route HTTP through the WAF or CDN. DNS changes also cannot repair an unhealthy application.
How it works: A registrar delegates the zone to authoritative nameservers. Recursive resolvers cache answers according to TTL; eligible proxied records answer with Cloudflare addresses.
Alternatives: Compare managed authoritative DNS and self-operated authoritative servers. Compare operational controls and migration requirements, not only lookup speed.
Tradeoffs: Delegation, DNSSEC, stale resolver caches, and mail records require careful migration. Inventory the zone and retain a rollback plan before changing nameservers.
Customer scenario: Hypothetical: a SaaS team migrates its zone, validates MX and TXT records, proxies its application hostname, and leaves an unsupported service DNS-only.
Explain to a CTO: We can automate resilient name resolution while deciding separately which application traffic should enter the reverse proxy.
Explain to a CFO: The value is reduced DNS operating burden and outage exposure; measure migration success and availability rather than promising a revenue increase.

Official documentation ↗

CDN and Cache

DOCUMENTED PRODUCT · ORIGINAL ADVICE

What it is: A distributed cache keeps reusable HTTP responses closer to users, reducing repeated trips to the application’s origin server.
Problem it solves: It addresses geographic latency and repeated origin work for the same assets, particularly during traffic spikes or widely distributed demand.
When to use it: Use it for public assets and deliberately cacheable pages or API responses, with explicit freshness and invalidation requirements.
When not to: Do not share personalized or sensitive responses without correct cache isolation. A cache cannot make every dynamic database operation faster.
How it works: A request maps to a cache key. A reusable cached response is returned; misses reach origin, and eligible responses can populate the cache.
Alternatives: Alternatives include another CDN, application caching, browser caching, and regional reverse proxies. These operate at different points in the request path.
Tradeoffs: Freshness, hit ratio, key cardinality, cookies, and purge behavior interact. A higher hit ratio is harmful if users receive another user’s response.
Customer scenario: Hypothetical: a WordPress publisher caches versioned images and CSS while bypassing authenticated account pages, then measures origin traffic and regional latency.
Explain to a CTO: We should define which responses are safe to reuse, then test cache correctness alongside latency and origin offload.
Explain to a CFO: Potential value comes from reduced origin demand and better user experience; validate savings against the complete service cost and traffic profile.

Official documentation ↗

Web Application Firewall

DOCUMENTED PRODUCT · ORIGINAL ADVICE

What it is: A WAF evaluates incoming web requests against security rules before the request reaches a protected application.
Problem it solves: It reduces exposure to recognizable application attacks and provides an operational control point while teams investigate or remediate vulnerable code.
When to use it: Use managed rules for common attack patterns and carefully scoped custom rules for application-specific risk and observed abuse.
When not to: Do not treat it as a replacement for secure code, authorization checks, patching, or protecting an origin that attackers can reach directly.
How it works: Cloudflare inspects request attributes and applies configured rule actions. Security events help explain which rule matched and whether legitimate traffic was affected.
Alternatives: Alternatives include another managed WAF, reverse-proxy rules, and application validation. These controls can complement one another rather than being mutually exclusive.
Tradeoffs: Aggressive rules may block legitimate users. Plan availability and capabilities differ; tune narrow exceptions using evidence instead of disabling protection globally.
Customer scenario: Hypothetical: a checkout request triggers a managed rule. Reproduce the request, inspect the matched field, and test a constrained exception before rollout.
Explain to a CTO: We will reduce application attack exposure and operate the policy with measurable false-positive controls and a rollback path.
Explain to a CFO: The investment can reduce disruption and incident effort; validate those outcomes without promising that a WAF prevents every breach.

Official documentation ↗

DDoS protection

DOCUMENTED PRODUCT · ORIGINAL ADVICE

What it is: Distributed denial-of-service protection detects and mitigates malicious traffic intended to exhaust network or application resources.
Problem it solves: It addresses availability attacks that may overwhelm a local link, connection table, or expensive application endpoint before administrators can respond manually.
When to use it: Use the appropriate protection path for HTTP applications or network traffic, and confirm that the customer’s actual traffic traverses that path.
When not to: Do not equate an HTTP service configuration with protection of every public IP or protocol. Legitimate overload still needs capacity and application controls.
How it works: Cloudflare’s network applies automated detection and mitigation. Application-layer attacks and network-layer floods require different signals and enforcement mechanisms.
Alternatives: Alternatives include upstream-provider scrubbing, other managed mitigation services, and application rate controls. Local filtering alone may be too late for link saturation.
Tradeoffs: Tuning must preserve legitimate traffic. Confirm architecture, supported protocols, escalation process, monitoring, and commercial entitlement rather than assuming identical coverage everywhere.
Customer scenario: Hypothetical: a SaaS API sees a request flood while its origin link remains healthy. Compare edge mitigation events, request patterns, and origin CPU.
Explain to a CTO: Protect the availability boundary appropriate to the attack layer, then test visibility and response procedures with the operations team.
Explain to a CFO: Value is business continuity and reduced disruption risk. Frame impact using customer-owned downtime assumptions, with uncertainty clearly shown.

Official documentation ↗

Workers

DOCUMENTED PRODUCT · ORIGINAL ADVICE

What it is: Workers is Cloudflare’s serverless application runtime for running code on its network without managing individual application servers.
Problem it solves: It reduces infrastructure setup for APIs, request transformations, and application backends while integrating with Cloudflare storage and developer services.
When to use it: Use it for compatible application workloads, edge request handling, and new full-stack projects that fit the runtime and execution model.
When not to: Do not assume an arbitrary existing server process, native binary, or Node.js package works unchanged. Validate required APIs and runtime limits first.
How it works: Event handlers receive requests or other events. Bindings provide configured access to services such as D1, R2, KV, and Queues.
Alternatives: Compare managed functions, containers, and conventional servers using workload requirements, ecosystem compatibility, placement, observability, and team operating skills.
Tradeoffs: Runtime compatibility, CPU consumption, data location, and remote service latency matter. Moving compute nearer users does not automatically move a regional database.
Customer scenario: Hypothetical: a developer builds an API that validates requests in Workers, stores files in R2, and queues background processing after accepting an upload.
Explain to a CTO: We can prototype the critical request path quickly, then measure compatibility, latency, and failure behavior before expanding the migration.
Explain to a CFO: The business case is faster delivery and less server operation; estimate actual request, compute, storage, and downstream costs from measured usage.

Official documentation ↗

Pages

DOCUMENTED PRODUCT · ORIGINAL ADVICE

What it is: Pages hosts frontend projects and supports dynamic behavior through Pages Functions, with Git integration and direct upload deployment workflows.
Problem it solves: It simplifies publishing frontend assets and managing deployments for existing Pages applications without maintaining a traditional web-hosting server.
When to use it: Use this knowledge to support existing Pages customers, evaluate their deployment workflow, and understand preview and rollback needs.
When not to: For a new application, start by evaluating Workers: current Pages documentation explicitly recommends Workers as Cloudflare’s primary application platform.
How it works: A project receives built assets from a Git-based build or direct upload. Pages Functions can provide server-side request handling where configured.
Alternatives: Workers is the first Cloudflare comparison for new projects; other alternatives include static hosting and frontend platforms with managed serverless functions.
Tradeoffs: Migration is a workflow and compatibility exercise. Inventory routes, redirects, bindings, build settings, and deployment behavior before promising a seamless move.
Customer scenario: Hypothetical: a customer already runs documentation on Pages. Keep its working workflow while testing a new dynamic feature on the recommended Workers path.
Explain to a CTO: We should preserve existing deployment reliability and compare the target platform against concrete application requirements before choosing a migration schedule.
Explain to a CFO: Avoid paying for an unnecessary rewrite. Measure maintenance effort and feature delivery benefits before allocating engineering time to migration.

Official documentation ↗

R2

DOCUMENTED PRODUCT · ORIGINAL ADVICE

What it is: R2 is object storage for unstructured data such as documents, media, backups, and application-generated files.
Problem it solves: It separates file durability and access from application servers, allowing compute to scale without treating local disks as a durable data store.
When to use it: Use it when the unit of storage is an object addressed by a key, especially alongside Workers applications and supported S3-compatible integrations.
When not to: Do not use object storage as a relational database, a block device, or an implicit replacement for transactional updates across multiple business records.
How it works: Applications read and write objects through supported APIs or Workers bindings. Access design determines whether objects stay private or are served publicly.
Alternatives: Compare other object stores and existing enterprise storage on API compatibility, operational integration, residency requirements, and complete workload cost.
Tradeoffs: S3 compatibility does not imply every S3 feature is identical. Design authorization, lifecycle, object naming, caching, and recovery around documented capabilities.
Customer scenario: Hypothetical: a quotation service stores PDF exports in R2 and metadata in SQL, issuing access only after validating the requesting tenant.
Explain to a CTO: Keep binary objects out of the application database while making ownership, retention, and access explicit in the architecture.
Explain to a CFO: Evaluate storage and operation charges together with delivery patterns. The documented absence of R2 egress bandwidth fees does not make the entire application free.

Official documentation ↗

D1

DOCUMENTED PRODUCT · ORIGINAL ADVICE

What it is: D1 is a managed serverless database with SQLite SQL semantics and access from Workers or an HTTP API.
Problem it solves: It supplies relational persistence without requiring a team to operate its own database server for compatible application workloads.
When to use it: Use it for structured application data where tables, indexes, joins, and SQL queries fit the workload and documented scaling model.
When not to: Do not assume it is a drop-in PostgreSQL replacement or an unrestricted distributed write database. Test schema and transaction requirements.
How it works: A Worker binding executes database queries. D1 provides recovery tooling and read-replication capabilities; correct use depends on the documented API and consistency model.
Alternatives: Compare a managed PostgreSQL or MySQL service, Durable Objects for coordinated state, and KV for read-heavy key-value access.
Tradeoffs: Indexes, query shapes, database size, and write pressure influence suitability. Read replication does not eliminate the need to reason about write location and consistency.
Customer scenario: Hypothetical: a multi-tenant quoting application prototypes tenant-scoped SQL queries, tests index plans, and exercises recovery before storing business-critical records.
Explain to a CTO: We can use familiar relational modeling in a managed Workers-integrated service, provided the workload passes compatibility and capacity tests.
Explain to a CFO: The value is reduced administration and faster application delivery; benchmark queries and storage so operational simplicity does not hide inefficient data access.

Official documentation ↗

Workers KV

DOCUMENTED PRODUCT · ORIGINAL ADVICE

What it is: Workers KV is a distributed key-value store optimized for frequently read, cacheable data rather than tightly coordinated writes.
Problem it solves: It reduces repeated remote reads for small values such as configuration, routing information, or reference data used by global applications.
When to use it: Use it when many requests read the same keys and the application can tolerate propagation delay after updates.
When not to: Do not use it for authoritative balances, inventory reservations, or immediate global revocation when stale reads would violate correctness or security.
How it works: Values are cached across Cloudflare locations. Updates are eventually consistent; even immediate visibility at the writing location is not a correctness guarantee.
Alternatives: Use Durable Objects for strongly consistent coordination, SQL for relational transactions, or a cache backed by an authoritative database.
Tradeoffs: Cached old values and cached negative lookups affect freshness. More caching can improve reads while increasing the duration of stale observations.
Customer scenario: Hypothetical: a documentation router stores infrequently updated redirect metadata in KV, while urgent access revocation uses an authoritative policy path.
Explain to a CTO: KV is useful when we deliberately accept stale reads; we should write that tolerance into the application contract.
Explain to a CFO: It can lower latency and origin work for read-heavy data, but correctness failures cost more than a marginal reduction in storage operations.

Official documentation ↗ · Official documentation ↗

Durable Objects

DOCUMENTED PRODUCT · ORIGINAL ADVICE

What it is: A Durable Object combines addressable compute with durable storage, providing a coordination point for a particular object identity.
Problem it solves: It solves state coordination problems that ordinary stateless request handlers cannot safely resolve with independent local memory.
When to use it: Use it for collaboration rooms, per-entity coordination, WebSocket sessions, or other workloads with a clear partitioning key.
When not to: Do not route every customer through one object or assume transactions span arbitrary objects. A hot coordination key can become a bottleneck.
How it works: Clients address the same object identity from different locations. Its attached storage provides strong consistency, and the object coordinates access to its state.
Alternatives: Compare actors, transactional databases, and dedicated coordination services. KV is appropriate only when eventual consistency satisfies the application contract.
Tradeoffs: Partition design governs scale and cross-object complexity. Users far from an object still experience network latency; global addressability is not zero-distance state.
Customer scenario: Hypothetical: a shared quoting workspace uses one object per collaboration room, while durable document exports live in R2.
Explain to a CTO: Place coordination at a well-defined entity boundary, and test the hottest expected object rather than only average throughput.
Explain to a CFO: The value is simpler stateful application delivery, balanced against workload concentration and the cost of operating an equivalent coordination service.

Official documentation ↗

Queues

DOCUMENTED PRODUCT · ORIGINAL ADVICE

What it is: Queues is a managed messaging service that decouples producers from asynchronous consumers and supports delivery retries.
Problem it solves: It lets a request accept work without waiting for slow downstream processing, while providing a durable handoff between application components.
When to use it: Use it for background processing, ingestion, notifications, and workloads where temporary downstream failure should not block the interactive request.
When not to: Do not assume exactly-once business effects or use a queue to conceal an unbounded backlog with no capacity plan.
How it works: A producer sends messages; consumers process and acknowledge them. Delivery is at least once, so a consumer may see the same message again.
Alternatives: Compare other managed queues, a durable workflow engine for multi-step state, and synchronous calls where immediate completion is actually required.
Tradeoffs: Retries improve delivery resilience but can amplify load. Use idempotency, bounded retries, dead-letter handling, and age-of-oldest-message monitoring.
Customer scenario: Hypothetical: an accepted document upload enqueues extraction. A duplicate delivery reuses the job’s idempotency key instead of charging the customer twice.
Explain to a CTO: We will separate acceptance from completion and make failure recovery explicit through deduplication, retry policy, and backlog monitoring.
Explain to a CFO: The business value is resilient throughput and a responsive user experience; capacity and processing cost must still track demand.

Official documentation ↗ · Official documentation ↗

Hyperdrive

DOCUMENTED PRODUCT · ORIGINAL ADVICE

What it is: Hyperdrive accelerates access from Workers to existing PostgreSQL and MySQL databases through managed connection handling and query caching.
Problem it solves: It reduces repeated connection establishment and reusable-query latency when a global application accesses a database in a particular region.
When to use it: Use it when retaining an existing compatible database while moving application request handling to Workers.
When not to: Do not describe it as migrating the database or making every write local worldwide. It cannot fix slow SQL or inadequate database capacity.
How it works: Workers use Hyperdrive connection details with supported drivers. Hyperdrive manages pooled database connections and can cache eligible query results.
Alternatives: Compare direct database connections, regional application placement, database-native replicas, and purpose-built caching based on measured bottlenecks.
Tradeoffs: Query freshness, supported database features, connection limits, and network reachability remain architectural concerns. Benchmark representative reads and writes separately.
Customer scenario: Hypothetical: a SaaS team retains PostgreSQL but moves an API to Workers. It measures connection overhead, cacheable reads, and write latency before rollout.
Explain to a CTO: Hyperdrive is a database-access optimization layer; we should validate compatibility and latency while keeping the existing database’s ownership and recovery model.
Explain to a CFO: It may reduce migration scope and improve responsiveness. Compare those benefits with service charges and the continuing cost of the underlying database.

Official documentation ↗

Workers AI

DOCUMENTED PRODUCT · ORIGINAL ADVICE

What it is: Workers AI runs supported machine-learning models on Cloudflare-managed serverless GPUs, accessible from Workers or an API.
Problem it solves: It removes the need to provision and operate GPU servers for supported inference workloads and integrates inference with application services.
When to use it: Use it when an available model meets the application’s quality, latency, task, and governance requirements after evaluation.
When not to: Do not assume every model, arbitrary model weight, or training workload is automatically supported. A convenient API does not establish answer quality.
How it works: Application code invokes a model from the catalog and processes its output. Model selection and task-specific input/output formats remain application responsibilities.
Alternatives: Compare direct model-provider APIs, managed inference elsewhere, and self-hosted inference using the same evaluation set and operational requirements.
Tradeoffs: Model behavior, throughput, latency, limits, and data handling vary. Evaluate quality and failure behavior before replacing an existing model.
Customer scenario: Hypothetical: a support assistant uses a selected embedding model and generation model, with tenant-aware retrieval and a refusal path for unsupported answers.
Explain to a CTO: We can avoid GPU administration, but we still own evaluation, authorization, retrieval quality, and safe application behavior.
Explain to a CFO: The business case depends on useful outputs per unit cost, not raw token price; include human review and failed-task costs in the comparison.

Official documentation ↗

AI Gateway

DOCUMENTED PRODUCT · ORIGINAL ADVICE

What it is: AI Gateway is an observation and control layer between an application and supported model providers, including Workers AI.
Problem it solves: It centralizes visibility into AI requests and provides controls for caching, rate limiting, retries, and fallback behavior.
When to use it: Use it when teams need consistent request telemetry and operational policies across AI application traffic or multiple providers.
When not to: Do not confuse a gateway with a model, a full application evaluator, or an automatic guarantee that fallback answers are equally correct.
How it works: Applications route inference requests through a configured gateway. The gateway applies supported policies and records telemetry for investigation and usage analysis.
Alternatives: Compare direct provider integrations with application-owned middleware, other AI gateways, and existing API-management controls for the actual feature requirements.
Tradeoffs: Logging can contain sensitive prompts. Cache keys must preserve tenant and context boundaries; retries and fallbacks need bounded latency and spending.
Customer scenario: Hypothetical: an agent service records provider errors, retries a transient failure, then uses an evaluated fallback while preserving an overall request deadline.
Explain to a CTO: Centralize inference operations while keeping model quality, data governance, and authorization in the application’s explicit design.
Explain to a CFO: Use telemetry to understand spend and failed requests; potential savings from caching must be validated against freshness requirements and actual repeat traffic.

Official documentation ↗

Vectorize

DOCUMENTED PRODUCT · ORIGINAL ADVICE

What it is: Vectorize is a managed vector database for storing embeddings and querying similarity, integrated with the Workers platform.
Problem it solves: It enables semantic retrieval without operating a dedicated vector-search cluster, helping applications find related content rather than only exact keywords.
When to use it: Use it for retrieval-augmented generation, recommendations, and similarity search when embeddings represent the relevant meaning of your data.
When not to: Do not use nearest-neighbor similarity as an authorization check or assume it is a replacement for a transactional source of truth.
How it works: An embedding model converts content into vectors. The application stores vectors with identifiers, queries with compatible embeddings, and retrieves associated source records.
Alternatives: Compare SQL vector extensions, managed vector databases, and lexical or hybrid search using a representative retrieval evaluation set.
Tradeoffs: Embedding dimensions, model changes, metadata filtering, ingestion freshness, and retrieval quality matter. Re-embedding can be a substantial migration task.
Customer scenario: Hypothetical: a documentation assistant retrieves tenant-eligible passages, fetches the source documents, and cites evidence while declining questions unsupported by the retrieved material.
Explain to a CTO: Vectorize supplies similarity retrieval; our ingestion, access control, and evaluation determine whether the resulting assistant is trustworthy.
Explain to a CFO: Assess improved task completion and reduced support effort against indexing, inference, and maintenance costs; similarity scores alone are not business outcomes.

Official documentation ↗

Cloudflare One

DOCUMENTED PRODUCT · ORIGINAL ADVICE

What it is: Cloudflare One is a SASE platform combining connectivity and security services for users, applications, and enterprise networks.
Problem it solves: It addresses fragmented access controls and traffic backhaul by applying security through a shared network and policy architecture.
When to use it: Use it when a customer needs coordinated application access, Internet traffic filtering, device context, and network connectivity across locations.
When not to: Do not treat the platform name as one switch or presume that purchasing it instantly replaces every legacy security and networking capability.
How it works: Connectors and device clients bring relevant traffic to Cloudflare. Services such as Access and Gateway enforce different policies for application access and outbound traffic.
Alternatives: Compare integrated SASE platforms and a deliberately composed set of ZTNA, SWG, WAN, and identity services against customer requirements.
Tradeoffs: Identity integration, endpoint rollout, traffic steering, legacy applications, exceptions, and continuity planning determine migration complexity more than a product diagram.
Customer scenario: Hypothetical: an enterprise first protects one internal app with Access, then pilots Gateway with a device cohort before migrating branch connectivity.
Explain to a CTO: Design a staged architecture around identities, applications, traffic paths, and measurable policy outcomes rather than a wholesale overnight replacement.
Explain to a CFO: Potential value includes less tool fragmentation and faster onboarding; validate contract overlap, migration effort, and measurable support or risk reduction.

Official documentation ↗

Access

DOCUMENTED PRODUCT · ORIGINAL ADVICE

What it is: Access applies identity-aware policies to determine who or what may reach a protected application.
Problem it solves: It reduces dependence on broad network membership as permission and provides a consistent access boundary for supported application types.
When to use it: Use it for employee or contractor application access, service authentication, and policies incorporating identity and available device posture signals.
When not to: Do not assume successful authentication grants every application privilege. Business authorization inside the application remains necessary, and origin bypass must be addressed.
How it works: Policies combine actions, rule types, selectors, and values. Cloudflare evaluates the relevant identity and context before allowing access through the protected path.
Alternatives: Compare ZTNA products, an identity-aware reverse proxy, and carefully scoped VPN access, considering application protocols and user experience.
Tradeoffs: IdP availability, session behavior, policy ordering, device enrollment, and emergency access need deliberate testing. Broad bypass policies can undermine the intended control.
Customer scenario: Hypothetical: a contractor gets access to one internal dashboard after identity checks, while unrelated internal applications remain unavailable.
Explain to a CTO: We can enforce application-specific entry policies while preserving the application’s own role and data-access checks.
Explain to a CFO: The value is controlled access and potentially faster onboarding; measure provisioning time and support friction while validating the reduction in unnecessary access.

Official documentation ↗

Gateway

DOCUMENTED PRODUCT · ORIGINAL ADVICE

What it is: Gateway is Cloudflare’s secure web gateway capability for controlling and inspecting organizational traffic headed toward Internet services.
Problem it solves: It helps enforce acceptable-use and threat policies consistently when users work outside a traditional office security perimeter.
When to use it: Use DNS, network, and HTTP controls according to the visibility and enforcement required, with traffic steered through supported connectivity methods.
When not to: Do not assume DNS filtering inspects URLs or encrypted request bodies. Do not confuse outbound user protection with a WAF protecting a public server.
How it works: Traffic reaches Cloudflare through configured paths. Policies evaluate available attributes at the applicable layer; HTTP inspection may require TLS decryption setup.
Alternatives: Compare secure web gateways, protective DNS, and endpoint controls. They offer different depth of inspection and operational requirements.
Tradeoffs: Certificate trust, privacy, pinned applications, exceptions, and client rollout affect deployment. Test policies with a pilot cohort before organization-wide enforcement.
Customer scenario: Hypothetical: a company blocks known malicious domains, then pilots HTTP policies on managed devices with documented inspection exceptions.
Explain to a CTO: Choose the inspection layer that answers the security requirement and validate routing, certificate trust, and policy behavior end to end.
Explain to a CFO: The value is more consistent protection for distributed users; account for deployment effort, help-desk impact, and the customer’s actual threat exposure.

Official documentation ↗

Tunnel

DOCUMENTED PRODUCT · ORIGINAL ADVICE

What it is: Cloudflare Tunnel connects services to Cloudflare using an outbound connector, avoiding the need for a publicly reachable origin address.
Problem it solves: It reduces exposure from opening inbound network paths and supplies connectivity between Cloudflare and applications in private infrastructure.
When to use it: Use it to publish supported applications or connect private resources, choosing the matching client and policy architecture for the intended protocol.
When not to: Do not treat connectivity as authorization. A published application still needs appropriate Access or application controls, and the connector must remain healthy.
How it works: The cloudflared process establishes outbound connections and forwards configured traffic to local services or routed private resources.
Alternatives: Compare VPN connectivity, reverse proxies with controlled ingress, private interconnects, and other outbound connector approaches against protocol and operational requirements.
Tradeoffs: Connector placement, replicas, origin reachability, DNS, and network restrictions determine reliability. A healthy connector does not prove the downstream application is healthy.
Customer scenario: Hypothetical: an internal dashboard is reached through Tunnel and Access, with replicas on separate hosts and monitored application health.
Explain to a CTO: We can remove direct public ingress while explicitly designing the identity boundary and connector failure behavior.
Explain to a CFO: Potential value is simpler connectivity and reduced exposed infrastructure, balanced against connector operations and the availability requirements of the protected workflow.

Official documentation ↗

Magic Transit

DOCUMENTED PRODUCT · ORIGINAL ADVICE

What it is: Magic Transit protects customer networks against DDoS attacks and provides network security through Cloudflare’s global infrastructure.
Problem it solves: It addresses network-layer attacks that can overwhelm customer infrastructure or upstream capacity before local defenses can help.
When to use it: Use it when protecting public network traffic and IP space requires a network-level architecture, including on-premises, hosted, or hybrid environments.
When not to: Do not position it as a substitute for application authentication, a full WAN design, or automatically enabled protection for every customer address.
How it works: Traffic is directed through Cloudflare for mitigation and then forwarded to customer infrastructure using the configured connectivity and routing design.
Alternatives: Compare managed network scrubbing, upstream-provider protection, and other network security architectures with equivalent traffic coverage and response commitments.
Tradeoffs: Onboarding requires address, routing, tunnel, return-path, MTU, and operational planning. Eligibility and connectivity choices must be confirmed for the specific network.
Customer scenario: Hypothetical: a company protects a public network serving multiple protocols, validates routing and failover, and rehearses escalation with network operations.
Explain to a CTO: Protect the network before attack traffic reaches constrained infrastructure, while validating routing symmetry, reachability, and failure recovery.
Explain to a CFO: Use the customer’s outage exposure to assess continuity value and compare service cost with the risk and effort of maintaining equivalent mitigation.

Official documentation ↗

Cloudflare WAN (formerly Magic WAN)

DOCUMENTED PRODUCT · ORIGINAL ADVICE

What it is: Cloudflare WAN connects offices, data centers, and cloud networks through Cloudflare. Current documentation uses Cloudflare WAN rather than Magic WAN.
Problem it solves: It addresses complex site connectivity and centralized backhaul architectures, offering a network service that can support a staged WAN transformation.
When to use it: Use it when site-to-site connectivity and network-layer policy are requirements, with identity-aware Cloudflare One capabilities added where needed.
When not to: Do not equate WAN connectivity with user-level authorization or claim that Internet underlay circuits become unnecessary.
How it works: Sites connect through supported on-ramps such as GRE or IPsec tunnels, an appliance, or Network Interconnect. Routes direct traffic between connected networks.
Alternatives: Compare MPLS, SD-WAN overlays, cloud transit networking, and other WAN services against site coverage, routing control, and operating requirements.
Tradeoffs: Underlay quality, overlapping addresses, routing, MTU, failover, and segmentation remain design responsibilities. Current documentation describes the service as enterprise-only.
Customer scenario: Hypothetical: a company pilots two branches, validates route propagation and application latency, then adds sites only after failover and support procedures pass.
Explain to a CTO: We can redesign site connectivity incrementally while making routing, segmentation, and failure ownership explicit.
Explain to a CFO: Compare circuit and appliance costs, migration effort, and ongoing operations using a full baseline; do not promise blanket savings from a changed topology.

Official documentation ↗

Analytics and observability

DOCUMENTED PRODUCT · ORIGINAL ADVICE

What it is: Cloudflare Analytics exposes product telemetry through dashboards and APIs; observability also includes logs, traces, and application-specific instrumentation.
Problem it solves: It helps teams understand traffic, security, performance, and usage rather than diagnosing incidents solely from individual user complaints.
When to use it: Use dashboards to identify patterns, query APIs for repeatable analysis, and correlate Cloudflare evidence with origin and application telemetry.
When not to: Do not assume a dashboard contains every request or proves root cause. Availability, retention, aggregation, and sampling depend on the dataset.
How it works: Products emit metadata that is aggregated and exposed in relevant views. Workers Analytics Engine supports custom application analytics with SQL querying.
Alternatives: Compare existing monitoring and analytics platforms, generally integrating Cloudflare signals with them rather than replacing all application observability.
Tradeoffs: Define time windows, denominators, sampling, and identifiers before comparing graphs. Average latency can conceal an important regional or tail-latency failure.
Customer scenario: Hypothetical: an error spike is segmented by hostname and region, then matched with deployment timing and origin traces to isolate the failing dependency.
Explain to a CTO: We need a shared evidence model across edge and origin, with dashboards that answer operational questions and lead to testable hypotheses.
Explain to a CFO: The business value is quicker diagnosis and visible customer outcomes; track restoration time and support effort instead of treating dashboard count as success.

Official documentation ↗

Load Balancing

DOCUMENTED PRODUCT · ORIGINAL ADVICE

What it is: Cloudflare Load Balancing distributes traffic across configured endpoints and supports health-based failover and routing policies.
Problem it solves: It reduces reliance on one endpoint and helps steer demand toward available infrastructure during failure or uneven load.
When to use it: Use it when multiple viable origins exist and the application’s data and session design can support the intended traffic distribution.
When not to: Do not expect it to create capacity, replicate a database, or make two unhealthy origins healthy. Failover needs a working destination.
How it works: Endpoints are organized into pools. Health monitors and configured steering determine which destinations receive traffic under the selected operating mode.
Alternatives: Compare DNS load balancing, regional cloud load balancers, and application-aware routing, distinguishing local distribution from global endpoint selection.
Tradeoffs: Monitor thresholds, session affinity, DNS behavior, data consistency, and fallback capacity affect recovery. An HTTP success code alone may hide a broken business workflow.
Customer scenario: Hypothetical: a SaaS service tests a regional failover with realistic sessions and confirms that the secondary region can handle the displaced load.
Explain to a CTO: We should validate the entire failover path, including application state and usable capacity, rather than only demonstrating traffic switching.
Explain to a CFO: Value comes from reduced outage impact and better use of existing infrastructure; include standby capacity and the separately scoped service cost in the analysis.

Official documentation ↗

Logs and Logpush

DOCUMENTED PRODUCT · ORIGINAL ADVICE

What it is: Cloudflare Logs provides detailed product metadata; Logpush exports supported request or event datasets to a configured destination.
Problem it solves: It gives investigators event-level evidence and lets teams combine Cloudflare activity with application, infrastructure, or security records.
When to use it: Use it for incident correlation, security investigation, and retention workflows when the appropriate dataset and entitlement meet the requirement.
When not to: Do not assume all products expose identical fields or that every account receives the same logging capabilities. Export alone is not an alerting program.
How it works: A configured Logpush job delivers selected dataset records to a supported destination. Teams parse and correlate them with other evidence using timestamps and identifiers.
Alternatives: Compare dashboard investigation, supported query tools, and existing log pipelines; choose the route that meets detail, latency, retention, and access needs.
Tradeoffs: Field selection, sensitive information, delivery health, volume, destination permissions, and retention cost must be designed. Monitor the pipeline as well as the application.
Customer scenario: Hypothetical: a support engineer correlates an edge request identifier and timestamp with origin logs to distinguish a security block from an application exception.
Explain to a CTO: Build a reliable evidence path from edge to origin, with explicit fields, access controls, and checks for missing delivery.
Explain to a CFO: Better evidence can reduce investigation time; balance that benefit against ingestion and retention costs instead of collecting every available field indefinitely.

Official documentation ↗