Cloudflare recently introduced Custom Regions, an expansion of its Regional Services that lets customers precisely define where their data is processed. By selecting specific groups of data centers by country or region, customers can ensure that TLS termination and application-layer processing remain within chosen geographic boundaries for compliance and control.
The new option requires customers to define region membership, routing traffic to in-region destinations, and enforcing those limits at the edge. Andrew Berglund, systems engineer at Cloudflare, andErik Engstrom, product leader at Cloudflare, explain:
> While our 35 pre-defined regions serve many of our customers’ needs, the digital world isn't one-size-fits-all. We've heard you loud and clear: you've asked for a specific country, unique combinations of countries, and the ability to exclude a set of countries from a region.
According to the announcement, Custom Regions can be defined using arbitrary geographic groupings. For example, a region may include North America (Canada, the United States, and Mexico) or exclude those three countries. It could also be based on other arbitrary criteria, such as countries that use Fahrenheit, including the United States, the Bahamas, the Cayman Islands, the Marshall Islands, and Liberia. Berglund and Engstrom add:
> At the core of Regional Services is enforcement of a simple rule: TLS termination and Layer 7 processing only happen inside your chosen region. Custom Regions expands this capability by allowing you to choose your own region definitions.
Cloudflare takes a different approach to regional traffic than Azure or AWS. Instead of defining a fixed geographic area (region-first cloud) with resources in a specific subset of data centers, it runs workloads on a global edge network (edge-first cloud). Still, it processes traffic within certain regions for customers who need to meet regional compliance requirements or want to maintain regional control over their data.
Cloudflare enforces regional boundaries by initially receiving and protecting traffic at the nearest data center (global ingestion and L3/L4 DDoS defense), then checking whether it belongs to the configured region. Requests are then either processed locally or forwarded to the data center, where TLS termination and Layer 7 processing will occur.
While generally developers value Cloudflare’s global-by-default simplicity, the need for features that introduce regional constraints is often viewed as a compliance-driven trade-off. On LinkedIn, R5 Inteligência Digital comments:
> Fine-grained regional boundaries are becoming a board-level requirement where compliance and latency both matter. Custom Regions should help teams move from policy intent to enforceable operating controls.
_!Image 1: Cloudflare Custom Regions/filters:no\_upscale()/news/2026/03/cloudflare-custom-regions/en/resources/11image1-1773937334543.jpg)_
_Source: Cloudflare blog_
The setup process of Custom Regions is based on three building blocks: defining region membership, selecting an in-region destination, and enforcing the boundary at the edge.
While Cloudflare managed regions use a pre-defined membership set, Custom Regions define region membership using an expression, for example, a country_code, the ISO code where each data center is located. Engineers can define inclusion rules such as country_code == "TR" or country_code in ["DE", "FR", "NL"], or exclusion rules such as !(country_code in ["US", "CA", "MX"]), to define the boundaries, with the expression being evaluated against the data centers' metadata.
To determine the optimal in-region destination, Cloudflare selects the best available option by intersecting a predefined set of allowed data centers with a per-ingress, performance-ranked list based on real-time network quality, capacity, and health metrics.
Currently, the new option is not self-serve, and customers must contact their account team.