Custom Regions provide a mechanism for customers to define the exact geographic boundaries where Cloudflare performs TLS termination and application‑layer processing.
Why Custom Regions Matter
Organizations face a growing number of jurisdictional rules that dictate where personal or operational data may be inspected. By allowing a customer to name the exact set of countries or data centers that constitute a region, the platform gives direct control over the legal footprint of every request. This control is especially valuable for regulated sectors such as finance, health, or government, where a single misplaced inspection could trigger compliance breaches.
Traditional sovereign cloud offerings often force customers to adopt a broad, pre‑defined region that may include locations they do not need. Custom Regions eliminate that mismatch, letting each business align the technical perimeter with its contractual obligations. The result is a tighter fit between policy and architecture, reducing audit friction.
Beyond legal alignment, precise region definitions help performance tuning. When a request is processed inside a location that is both compliant and close to the user, latency is reduced. This dual benefit of compliance and speed makes Custom Regions a practical choice for global enterprises that must respect local rules without sacrificing user experience.
Finally, the approach supports future expansion. As new jurisdictions emerge, a customer can simply edit the region definition to include or exclude the relevant data centers, avoiding the need for a complete migration or a new service contract.
Architecture Overview
At the edge, traffic first arrives at the nearest Cloudflare data center. At this point, high‑capacity network‑layer DDoS mitigation is applied. The system then checks whether the entry point belongs to the customer‑defined region. If it does, the request proceeds directly to TLS termination if not, the request is forwarded over a private backbone to a data center that does belong to the region.
The forwarding decision is made using a ranking that reflects real‑time network quality, not just geographic distance. Metrics such as round‑trip latency, packet loss, and current load inform the ranking. By selecting the best available in‑region node, the platform ensures that traffic follows the most efficient path while staying inside the defined boundaries.
Once the request reaches an in‑region node, TLS termination occurs and all application‑layer services-Web Application Firewall, Bot Management, Workers scripts-are executed. After processing, the response is re‑encrypted and sent to the origin server, preserving confidentiality across the entire journey.
This architecture isolates data inspection to the customer‑specified geography while still benefitting from a global network that absorbs large‑scale attacks before traffic reaches the protected region.
Membership Expression Mechanics
Custom Regions are built from a logical expression that evaluates the metadata of each data center. The most common attribute is country_code, the ISO‑3166 identifier of the data centers location. An expression such as country_code in ["TR", "AE", "AU", "JP"] creates a region that includes Turkey, the United Arab Emirates, Australia, and Japan.
Expressions can also combine inclusion and exclusion rules. For example, country_code not in ["US", "CA", "MX"] defines a region that covers every location except North America. The evaluation happens continuously when a new data center is added to the network, its metadata is checked against existing expressions, and it automatically becomes a member of any matching region.
Customers interact with the expression language through a structured API or management console. The system validates syntax, checks for unsupported codes, and provides immediate feedback on the resulting membership count, helping administrators understand the scope of their definition before activation.
Because the membership set is distributed to every edge location, each node can answer the question Am I in this region? locally, without needing a round‑trip to a central database. This locality reduces decision latency and keeps the routing path fast.
In‑Region Destination Selection
When a request arrives outside the defined region, the platform must choose an in‑region destination for forwarding. The selection algorithm starts with a pre‑computed list that ranks all member data centers for the originating edge location. Rankings are derived from measured path quality, taking into account latency, jitter, and recent availability signals.
The list is intersected with the regions membership set, producing a shortlist of viable targets. The algorithm then scans the shortlist from best to worst, discarding any node that is currently disabled, overloaded, or otherwise unreachable. The first remaining candidate becomes the forward destination.
These rankings are refreshed periodically and propagated to edge nodes via the Quicksilver distribution system. The frequency of refresh balances freshness of network measurements with the bandwidth cost of distribution, ensuring that routing decisions stay aligned with current network conditions.
In practice, this mechanism yields a deterministic yet adaptable path: traffic consistently follows the optimal in‑region route, but can quickly switch to a secondary node if the primary target experiences a transient issue.
Traffic Flow and Security Controls
The end‑to‑end flow begins with Layer‑3/4 DDoS protection at the edge of the global network. After this protection, the system performs a region membership check. If the check passes, TLS termination and all subsequent security services run at that location. If the check fails, the request is relayed to the selected in‑region node before any decryption occurs.
Because decryption only happens inside the approved region, plaintext data never traverses a data center that lies outside the customers compliance boundary. This guarantees that inspection, logging, and any content‑based policies are applied solely within the allowed geography.
After processing, the response is encrypted again and sent back through the same private backbone to the original ingress point, then out to the client. This round‑trip design preserves confidentiality and ensures that the client sees a consistent latency profile, regardless of whether the request was processed locally or forwarded.
The architecture also supports optional features such as custom Workers scripts or region‑specific firewall rules, giving customers fine‑grained control over behavior that is scoped to their defined geography.
Operational Considerations and Best Practices
When creating a Custom Region, start with a clear inventory of legal requirements. Map each jurisdiction to the corresponding ISO country code and verify that Cloudflare has at least one data center in that country. If a required country lacks coverage, consider using a nearby region that satisfies the same regulatory framework.
Regularly review the membership expression as your business expands or contracts. Adding or removing a country code is a lightweight operation, but it can affect routing latency and capacity. Use the provided membership preview to understand the impact before committing to changes.
Monitor the health of in‑region nodes through the platforms dashboard. The system automatically avoids unhealthy nodes, but visibility into node performance helps you anticipate capacity constraints and plan for scaling.
Finally, incorporate region‑aware logging into your security operations. Knowing exactly which data center performed TLS termination allows auditors to trace inspection points, simplifying compliance reporting and incident investigation.