Personal study reference, not customer-facing. DLS is a compliance tool, not a performance feature — it exists purely to answer "where exactly does my data get processed, stored, and decrypted," and every answer below is sourced from live Cloudflare docs (full list at the bottom).
Data Localization Suite (DLS) is an Enterprise-only paid add-on made of three independently licensed, independently configured components. Most customers only need one, depending on exactly what their compliance requirement is actually about.
| If the requirement is about... | ...use this component | Controls where... |
|---|---|---|
| Where HTTPS traffic gets decrypted/inspected | Regional Services | your live traffic is processed |
| Where request logs and analytics are stored | Customer Metadata Boundary | your logs are stored |
| Where your private TLS/SSL keys are stored | Geo Key Manager | your certificate private key lives |
Set expectations correctly up front: this is a compliance tool, not a speed booster. Deliberately restricting where traffic can be processed means it's sometimes NOT routed to the geographically closest data center — only the closest in-region one. Some latency cost is the expected trade, not a bug. It's also genuinely expensive and Enterprise-only — not something a small business buys without a specific legal or contractual reason (GDPR, government contracts, banking, healthcare, or a client contract mandating data residency).
Controls which Cloudflare data centers are allowed to decrypt and process your HTTPS traffic. Traffic is still accepted anywhere worldwide for basic network-layer DDoS protection, but if it arrives outside your region, it's forwarded still encrypted and only decrypted once it reaches an in-region data center. Everything that needs to read decrypted traffic — WAF, Bot Management, Cache, Workers, Load Balancing — only runs inside that region.
These three options used to be labeled with version numbers. Cloudflare has moved away from that naming because it wrongly implied each one supersedes the last — in reality each is a distinct approach with its own tradeoffs, and the right one depends entirely on how your traffic reaches Cloudflare.
| Current name | Previously known as |
|---|---|
| Regional Hostnames | Regional Services v2 (RSv2) |
| Regionalized Spectrum Applications | Regional Services v1 (RSv1) |
| Regionalized IP Bindings | Regional Services for BYOIP / regionalized address maps |
| Method | Traffic addressed by | Granularity | Static IP/BYOIP | Best for |
|---|---|---|---|---|
| Regional Hostnames | Cloudflare shared IPs | Per hostname | Not supported | Most deployments — the default choice |
| Regionalized Spectrum Applications | Dedicated IP via Spectrum app | Per zone (all Spectrum HTTP/S apps share one region) | Supported | IP-addressed traffic needing Static IPs or BYOIP |
| Regionalized IP Bindings | BYOIP prefix at the IP layer | Per CIDR — scales to whole prefixes | BYOIP only | Broad, fully self-serve regionalization via address maps |
All three require the base Regional Services entitlement from your account team. Spectrum Applications additionally need the Spectrum entitlement; IP Bindings additionally need the Regional Services for BYOIP entitlement. None of this is self-serve out of the box for Hostnames or Spectrum — only IP Bindings becomes fully self-serve via API once entitlements are enabled.
Every Cloudflare HTTP response's CF-RAY header ends with a 3-letter IATA airport code identifying the data center that terminated TLS. This is a fast, concrete way to prove regionalization is actually working, not just configured:
curl --head https://www.example.com 2>&1 | grep -i cf-ray
// cf-ray: 80cc9e64fd8a1519-MUC
// MUC = Munich -> confirms this request was processed inside the EUA request sent from outside the configured region still returns an in-region airport code, because out-of-region traffic gets forwarded to the region for processing — that's the whole point. You can also check the IngressColoName field in Zero Trust Network Session logs for the same confirmation.
A real operational gotcha with IP Bindings: creating or changing a binding can take 4-6 hours to propagate across Cloudflare's network. If the IP addresses are already carrying live traffic when you do this, clients get TCP resets during propagation. Always bind unused addresses and wait for the binding to show active before pointing production traffic at them. Separately: Spectrum regionalization has its own quota — by default, an account is limited to 10 unique Spectrum hostnames using Cloudflare-managed IPv4 addresses, account-wide, not per zone.
Regionalizing to a single-country region other than the US removes Cloudflare's standard automatic failover for that traffic, since it literally can't fail over to data centers outside that one country — confirmed as an explicit SLA exclusion. Multi-country regions (like the European Union) keep the standard SLA and failover behavior. If a customer wants strict data residency AND full failover resilience, that tension needs to be named explicitly — they usually can't have the strictest possible single-country residency without giving up some failover guarantee.
Controls where your logs live — not live traffic. A simpler, account-wide setting: choose EU or US as the boundary; by default, no boundary applies and logs can be stored anywhere globally.
eu, us, or Global (removes any boundary — the default)Scope limitation to lead with: CMB applies at the account level only, never per-zone. If a customer wants it on some zones but not others, those zones need to move to a separate account first — there's no partial application within one account. Only SuperAdmin and Admin roles can change this setting.
Once a boundary is set, dashboard analytics/log views are only visible to users whose sessions happen to route to the configured region's core data center — this is based on network routing, not the user's physical location, so someone can see "no data" unexpectedly even sitting right next to a colleague who can see it fine. Fix: enable Allow out-of-region access, which keeps the actual data stored in-region but lets authorized users view it regardless of where their own session happens to route. This single setting resolves a large share of "CMB is broken" tickets that are actually working as designed.
FedRAMP customers specifically set CMB to the United States boundary. Logpull (legacy) is only available when CMB = US; Logpush is the recommended path and supports a defined set of datasets under a CMB boundary — anything outside that list needs your account team.
Controls where your TLS private keys are stored. By default, keys are encrypted and distributed to every Cloudflare data center for fast local decryption — Geo Key Manager restricts that distribution to specific countries or regions.
Hard limitation to state up front: Geo Key Manager only works with custom (uploaded) certificates — never Cloudflare-managed Universal SSL certificates. The newer version (v2) is configured entirely through the API; there is no v2 dashboard option today.
| v1 (dashboard-available) | v2 (API-only, Closed Beta) | |
|---|---|---|
| Regions | US, EU, or Highest-security data centers only — a fixed choice | Configurable allow/block lists of specific countries/regions |
| Example policy | "EU data centers only" | "Store in EU and US" or "store in EU but never France" |
| Setup | Standard custom-cert upload, pick a Private Key Restriction option | Same upload flow via API, with a policy parameter instead of the older geo_restrictions parameter (mutually exclusive — pick one) |
If a data center near your visitor doesn't hold a copy of your private key, it has to request a temporary session key from a data center that does before it can decrypt traffic — adding up to roughly a second of latency on the first connection if the key-holding data center is far away. This is the direct cost of restricting key distribution, same spirit as Regional Services' latency trade.
Not every region is available for every component — and regions come in two fundamentally different flavors.
| Type | What it is | Available for |
|---|---|---|
| Managed | Predefined regions Cloudflare maintains (e.g. eu, us) — available to all accounts, some requiring specific entitlements | All three Regional Services methods |
| Custom | Bespoke region restricting processing to a specific data center set, set up with your account team, for when managed regions don't meet the requirement | Regionalized Spectrum Applications and IP Bindings only — not Regional Hostnames |
Regional Services supports by far the widest range — individual countries, every compliance framework above, and "exclusive of" regions. Customer Metadata Boundary is limited to just US or EU (countries within the EU can use the EU boundary; FedRAMP uses the US boundary). Geo Key Manager's list depends entirely on v1 (US/EU/High-Security only) vs. the v2 Closed Beta (broader country list).
The --region parameter in cloudflared controls where the tunnel connector establishes its own connection to Cloudflare — this is completely separate from Regional Services, which controls where end-user traffic is decrypted and processed. For public hostnames served through a tunnel, Regional Services is configured at the DNS record level, same as any other hostname — the tunnel connector region and the Regional Services region operate independently of each other. Don't conflate the two when a customer asks about tunnel + data residency together.
To ensure all reverse-proxy requests for Access-protected applications only occur in FedRAMP-compliant data centers, use Regional Services (Regional Hostnames) with the region set to FedRAMP. Note: Access App SSL keys can use Geo Key Manager, but the Access JWT itself is not yet localized — a real gap to flag if asked specifically about JWT data residency.
By default, Cloudflare stores and delivers logs from data centers across the whole network. CMB restricts this the same way it does for any other logs. Customers can further reduce what's logged at all — excluding PII from Gateway logs, or disabling/limiting logging to only blocked requests — independent of CMB.
| Customer says... | They need... |
|---|---|
| "Our regulator requires traffic to be decrypted only within [country/region]" | Regional Services |
| "Our logs/analytics can't leave the EU" | Customer Metadata Boundary |
| "Our private key can never touch a data center outside [US/EU]" | Geo Key Manager |
| "We need all three because of a broad data-sovereignty mandate" | All three, independently licensed and configured — there's no bundled "turn it all on" switch |
| "We're a FedRAMP customer" | Regional Services (FedRAMP region) + CMB set to US + Geo Key Manager scoped to US FedRAMP Moderate Domestic |
Always name the latency/failover trade-off explicitly when recommending Regional Services for a single-country (non-US) region — it's a real, documented SLA exclusion, not a minor footnote.
"If we turn on Regional Services, does ALL our traffic get processed in-region, even from visitors on the other side of the world?"
Yes — out-of-region traffic is forwarded to your configured region still encrypted and only decrypted there. Basic network-layer DDoS protection still happens at whichever data center first receives the packet, but anything requiring decrypted traffic (WAF, Bot Management, Workers, etc.) only runs in-region.
"One of our admins can't see our EU-boundary logs from the US office — is something broken?"
Almost certainly not broken — this is the expected behavior of Customer Metadata Boundary without "Allow out-of-region access" enabled. Visibility depends on which region their session happens to route to, not their physical location. Enable that setting to let authorized users view in-region data from anywhere.
"Can we apply Customer Metadata Boundary to just our EU zones and leave the rest global?"
Not within one account — CMB is account-level only. The EU zones would need to move into a separate Cloudflare account first.
"We want our TLS key locked to France specifically, not just the EU generally."
That needs Geo Key Manager v2 (API-only, Closed Beta) — v1 only offers fixed US/EU/Highest-security options, no individual-country granularity.
"How do we prove to an auditor that traffic is actually staying in-region, not just configured to?"
Pull the CF-RAY header from a real response and decode the trailing airport code, or check IngressColoName in Zero Trust Network Session logs — both show the actual data center that handled the request, which is concrete, auditable evidence rather than a configuration screenshot.
Click a question to reveal the answer. No peeking before you commit to one.
Customer Metadata Boundary only — Regional Services controls live traffic decryption location, which isn't their requirement here. No need to buy/configure all three components just because one is needed.
False — that's the old name. The current name is Regional Hostnames. Cloudflare moved away from version-number naming because it wrongly implied one option supersedes another.
Regionalized IP Bindings — scales to whole CIDR prefixes and is fully self-serve via API once entitlements are enabled, unlike the other two methods.
Propagation takes 4-6 hours, and if the IP is already in use during that window, clients receive TCP resets. Always bind unused addresses and wait for "active" status before pointing production traffic at them.
Automatic failover is excluded for that traffic — it can't fail over to data centers outside that one country. Multi-country regions (like the EU) keep the standard SLA and failover behavior.
No — this is expected default behavior. Visibility depends on which region the admin's session happens to route to (network routing, not physical location). Enable "Allow out-of-region access" to fix it while keeping data stored in-region.
No — CMB is account-level only. Zones needing a different boundary (or no boundary) must be moved to a separate Cloudflare account.
It only works with custom (uploaded) certificates — never Cloudflare-managed Universal SSL certificates.
v2 (API-only, Closed Beta) — it supports configurable allow/block lists of specific countries. v1 only offers fixed US/EU/Highest-security options with no individual-country exclusion.
False — it's an energy-sourcing constraint (restricts to renewable-powered data centers), not a geographic restriction at all.
The opposite of a normal restriction — it allows any data center worldwide except those two countries, rather than restricting processing to a specific set.
No — cloudflared --region only controls where the tunnel connector itself connects to Cloudflare. End-user traffic regionalization for a public hostname through a tunnel is configured separately via Regional Services at the DNS record level. The two operate independently.
No — Custom regions are only available for Regionalized Spectrum Applications and Regionalized IP Bindings, not Regional Hostnames.
Pull the CF-RAY header from a real response and decode its trailing 3-letter IATA airport code (or check IngressColoName in Zero Trust Network Session logs) — both show the real data center that handled the request, concrete auditable evidence rather than a dashboard screenshot.
No — Access App SSL keys can use Geo Key Manager, but the Access JWT itself is not yet localized. Worth flagging explicitly if a customer asks about JWT-specific data residency.