Regional Services expands with customer-defined data boundaries
Cloudflare has extended its Regional Services offering with two updates: four new pre-defined regions and a new Custom Regions capability that lets customers specify exactly which locations can process their traffic.
Regional Services works by combining the full scale of Cloudflare's global network for attack mitigation with strict localization of data inspection. Traffic is ingested at the nearest data center and immediately filtered for Layer 3/4 DDoS attacks. If the request arrives outside the customer's designated region, it is forwarded over Cloudflare's private backbone to a data center within the region before any decryption occurs. TLS termination and all application-layer processing — including WAF, Bot Management, and Workers logic — happen only inside the specified boundaries.
New managed regions
Cloudflare first launched Regional Services in 2020 with three regions (EU, UK, and U.S.) and has since added pre-defined regions shared across all accounts. Three more are now available:
- Turkey
- United Arab Emirates (UAE)
- IRAP (Australian compliance)
- ISMAP (Japanese compliance)
These additions bring the total to 35 Cloudflare Managed Regions.
Custom Regions: defining your own processing boundaries
For customers whose requirements don't fit a pre-defined region, Custom Regions allow the region membership to be defined per account. Instead of selecting from Cloudflare's list, customers specify precisely which locations constitute their region. The enforcement mechanism is identical to managed regions — only the boundary definition changes.
Early-access customers have used Custom Regions for use cases including regionalizing AI inference workloads, serving hyper-targeted marketing campaigns, building regions aligned with government contractual commitments, and mirroring internal business unit structures like EMEA or APAC.
Custom region definitions are flexible. A region could be a single country, a group of countries, or an exclusion set — for example "everywhere except North America."
How the region membership and routing work
A region is ultimately a set of Cloudflare data centers. Managed regions use pre-defined membership sets. Custom Regions define membership with an expression, commonly based on the country_code field — the ISO code associated with each data center's location:
Use case | Expression | Definition |
|---|---|---|
Single country | country_code == "TR" | Turkey |
Multiple countries | country_code in ["DE", "FR", "NL"] | Germany, France, and the Netherlands |
Exclude countries | !(country_code in ["US", "CA", "MX"]) | Everything except the U.S., Canada, and Mexico |
The expression is evaluated against data center metadata, and matching data centers become the region's membership set. This membership list is distributed globally so any data center can quickly determine whether it belongs to a given region. The set updates automatically as Cloudflare's infrastructure evolves, so newly added data centers that match the definition join without customer action.
When a request enters outside the region, Cloudflare selects an in-region destination via a two-step process. First, the region's membership set defines the allowed destinations. Then, a performance-ranked list tailored to the ingress location is intersected with that set. Rankings are computed centrally and distributed via Quicksilver, based on measured path quality signals such as:
- Network performance (latency, loss, timeouts)
- Capacity and load
- Operational health
At routing time, unavailable destinations are skipped, allowing traffic to fail over to the next best in-region candidate.
Request flow and error handling
The processing sequence when a request arrives is:
- Ingress: The request lands at the nearest data center. Layer 3/4 DDoS mitigation runs immediately.
- Configuration lookup: The system checks whether a region is configured for the zone.
- Membership check: It determines whether the ingress data center is in the configured region.
- Routing decision: If in region, TLS termination and all Layer 7 services run locally. If out of region, an in-region data center is selected and the request is forwarded.
- In-region processing: TLS is terminated for the first time, and application-layer services execute.
- Origin connection: The processed request is sent to the origin.
Resilience is handled at multiple layers. Multiple in-region candidates are considered, unhealthy data centers are excluded from selection, and routing inputs are published only when sufficient monitoring data is available. If no valid in-region destination exists, connections fail closed rather than processing traffic outside the defined region.
Availability and getting started
The new managed regions (Turkey, UAE, IRAP, ISMAP) are available now via the standard dashboard or API process. Custom Regions follow a different path: initial setup is collaborative, and customers interested in the capability should contact their account team to define and deploy a region. The feature is not yet self-serve, and some technical limitations may apply.
