Cloudflare Edge Platform Boundaries: DNS, WAF, Access, Workers, Pages, and Storage

Cloudflare is a collection of services that can share network paths, accounts, DNS zones, and developer bindings, but they are not one universal security or compute feature. The operational question is where each request enters, which products actually see it, what identity or policy decision is applied, which runtime executes code, and where state is stored. This is a scoped architecture map of commonly combined edge and application services, not an exhaustive inventory of every Cloudflare product, plan, or integration.

Start with DNS and proxy status

Cloudflare DNS records describe how a hostname resolves. For eligible A, AAAA, and CNAME records, proxy status determines whether HTTP/HTTPS traffic is routed through Cloudflare or directly to the origin. A proxied record returns Cloudflare anycast addresses and sends web requests through Cloudflare’s reverse proxy, allowing applicable caching and security configurations to process them. A DNS-only record returns the record’s origin address or CNAME target and does not send web traffic through the HTTP proxy. MX and TXT records are DNS-only.

This setting is a major security boundary, not a cosmetic dashboard toggle. If a web hostname is DNS-only, do not assume that Cloudflare WAF, HTTP caching, or proxy-based protection is on the request path. If a hostname is proxied, the origin can still be reachable directly if its address is exposed elsewhere and the origin accepts arbitrary Internet traffic. Restrict origin ingress to intended Cloudflare paths or use a documented private connectivity design, then test direct-origin access independently.

DNS routing and application deployment are separate control planes. Changing a DNS target does not publish a Worker or Pages build; deploying code does not automatically make every hostname proxied. Record the zone, hostname, proxy setting, origin target, and TLS mode in the same service inventory so a release cannot rely on an unstated DNS assumption.

Apply HTTP security and identity controls for different reasons

Cloudflare WAF evaluates incoming web and API requests using rulesets. Managed rules, custom rules, and rate-limiting rules answer questions about request shape, reputation, or traffic volume. WAF only protects traffic that reaches the relevant Cloudflare inspection path, and the WAF documentation lists feature availability by plan. A displayed product name does not mean every detection, ruleset, logging option, or account-wide control is included in every plan.

Cloudflare Access is an identity and application authorization layer. Its policies use actions such as Allow, Block, Bypass, or Service Auth and combine selectors and values such as an email identity, group, country, or device posture. This answers who may reach an application; it is not a replacement for a WAF rule that screens hostile public HTTP requests. Conversely, a WAF allow rule is not proof that the requester is an authorized employee. Use both only when their responsibilities and interactions are explicit.

For a protected private service, test the full request path from an unauthenticated client, an approved identity, an unapproved identity, and a service-authenticated client if that mode is configured. Test custom hostnames, preview URLs, and alternate routes because they may be covered by different Access applications or policies. Confirm that an origin cannot be reached by bypassing the policy path. Do not infer that enabling Access protects every hostname or Worker in an account unless the configured policy scope says so.

Place Workers and Pages in the compute plane

Workers is Cloudflare’s serverless execution platform. A Worker can handle an HTTP request, call bindings to Cloudflare or external services, and use runtime APIs subject to the configured compatibility date and flags. The runtime is not a general-purpose server with an unrestricted host operating system. Review its runtime and security documentation when porting code that expects native Node.js behavior, long-lived process state, or arbitrary system access.

Pages combines static site deployments with optional Pages Functions. A static Pages deployment serves generated assets; a Function adds server-side handlers to selected routes, with file-based routing or an advanced _worker.js mode. Cloudflare’s current Pages overview notes that Workers now supports most Pages use cases and recommends Workers for new projects, while Pages remains a documented deployment path. Treat that as product guidance, not as a claim that an existing Pages project is automatically migrated or that both deployment models have identical behavior.

Workers and Pages deployments have their own configuration, preview, production, and rollback workflows. A successful asset preview does not prove that production bindings or Access policies match. Keep code versioning separate from data recovery: reverting a deployment restores code/configuration history, not writes already made to D1, KV, R2, Durable Objects, or an external database.

Choose storage by consistency and access pattern

Workers bindings make data services available to application code, but they do not make those services interchangeable. Cloudflare’s storage guidance distinguishes products by workload:

Product	Useful mental model	Boundary to test
Workers KV	Distributed key-value reads with eventual consistency	A write may not be visible everywhere immediately; avoid treating it like a strongly consistent lock or transactional database
D1	Managed SQLite-backed relational SQL	Plan schema changes, transaction behavior, read/write shape, limits, and point-in-time recovery separately
R2	S3-compatible object storage	Object read-after-write and list consistency differ from CDN cache behavior; a cached public response is a separate layer
Durable Objects	Globally unique stateful objects with per-object transactional storage	Route a key to its owning object and persist durable state rather than relying on in-memory state across eviction or restart
Queues	Asynchronous message delivery and background work	Design consumers for the documented delivery semantics and make handlers safe against duplicate processing where required

The consistency notes are application contracts. For example, a globally cached KV read may be an excellent fit for configuration while being an unsafe source of immediate revocation truth. A Durable Object can serialize state for one object identity, but it is not a substitute for every relational workload. R2 object consistency does not mean a browser cache has been purged. Select a product from the required read/write semantics, region behavior, transaction model, retention, and recovery objective, not from the phrase “at the edge.”

Trace a request end to end

For a public application, a useful review sequence is:

Resolve the hostname and confirm the DNS record’s proxy status.
Verify that the request reaches the expected zone and that TLS terminates on the intended path.
Confirm which WAF, rate-limit, cache, and redirect rules apply to that hostname and route.
If the application is private, validate the Access policy separately for workforce and service identities.
Identify whether the response comes from a static Pages asset, a Pages Function, a Worker route, or an origin server.
Trace each binding to its actual environment-specific resource and document its consistency and backup behavior.
Test origin bypass, preview routes, policy exceptions, and recovery procedures before treating the path as production-ready.

Do not assume that products execute in a particular order just because they are enabled in a dashboard. Verify the request path and rule phases for the selected integration, inspect request/security logs for a controlled test, and retain evidence connecting the hostname, deployment, ruleset, identity decision, and data resource.

Keep plan, scope, and failure behavior explicit

Cloudflare product capabilities can vary by plan, zone versus account scope, and whether traffic is proxied. A feature page may list custom rules or managed rules but still show plan-specific constraints for particular detections, analytics, or account-level controls. Check the current feature availability and limits for the tenant before writing an architecture requirement as though it were universal.

Finally, decide what happens when each dependency is unavailable. DNS resolution, origin connectivity, an Access identity provider, Worker bindings, WAF rule deployment, and storage recovery are separate failure cases. Use controlled failure tests to learn whether the request is blocked, bypassed, served stale, or fails with an application error. A layered edge architecture is only as clear as its exception paths and rollback plans.

Related:

Sources: