Today, we're taking two major steps forward: First, we’re expanding the pre-defined regions for Regional Services to include Turkey, the United Arab Emirates (UAE), IRAP (Australian compliance) and ISMAP (Japanese compliance). Second, we’re introducing the next evolution of our platform: Custom Regions.

Before we dive into what’s new, let’s revisit how Regional Services provides the best of both worlds: local compliance and global-scale security. Our approach is fundamentally different from many sovereign cloud providers. Instead of isolating your traffic to a single geography (and a smaller capacity for attack mitigation), we leverage the full scale of our global network for protection and only inspect your data where you tell us to.

Here’s an overview of how it works:

1. Global ingestion & L3/L4 DDoS defense: Traffic is ingested at the closest Cloudflare data center, wherever in the world that may be. At this initial entry point, we apply our massive-scale DDoS mitigation to block volumetric attacks at the network and transport layers. This happens outside your designated region, ensuring only clean traffic is forwarded.

2. Intelligent in-region routing: Before any decryption occurs, we inspect the request's metadata. If it has arrived at a data center outside your specified region, we route it across our secure, private backbone to a data center within your boundaries, using the most performant pathway.

3. In-region TLS termination & L7 processing: Only once the traffic is confirmed to be within your chosen region do we decrypt the request. It is only then that we apply our application-layer security services, like our Web Application Firewall (WAF) or Bot Management, and execute any Cloudflare Workers logic.

4. Secure transit to origin: Once processed, the request is re-encrypted and securely sent to your origin server.

This unique architecture means you can localize data inspection as needed to meet your legal obligations without sacrificing the robust DDoS protection that only a massive global network can provide.

When we launched Regional Services in 2020, we started with just three regions: EU, UK, and U.S. Over time we have added regions that are shared across all accounts — we refer to these as Cloudflare Managed Regions.

A few more are newly available: Turkey, the United Arab Emirates (UAE), and IRAP (Australian compliance), bringing our total to 35 regions.

In addition, we are now giving our customers the ability to request a custom region that meets their account needs. These are Custom Regions, launching today.

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.

That's why we're excited to announce the next evolution of Regional Services: Custom Regions.

Simply put, Custom Regions give you the power to define your own geographical boundaries for traffic processing. Instead of choosing from a list of regions defined by us, you tell us precisely which locations constitute your region.

This flexibility unlocks a new level of control. Our early-access customers have already used Custom Regions to:

• Regionalize AI inference: Keep LLM prompts and responses within a specific set of countries to optimize for performance and data localization legal obligations.

• Launch hyper-targeted promotions: Serve marketing campaigns and content that are optimized for a unique combination of countries.

• Scale government operations: Build regions that align with contractual commitments with government entities.

• Mirror your corporate structure: Build regions that match your internal business units, like EMEA, MENA, or APAC, for perfectly aligned governance.

The core mechanism is the same; the only thing that changes is the boundary. Instead of Cloudflare defining the region, you do.

The possibilities are endless. For example, your region could be:

• North America: Canada, United States, Mexico

• Everywhere except North America: Not Canada, not United States, not Mexico

• Countries that use Fahrenheit: USA, Bahamas, Cayman Islands, Marshall Islands, Liberia

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 Managed Regions and Custom Regions rely on three building blocks: defining region membership, selecting an in-region destination, and enforcing the boundary at the edge.

A region is ultimately a set of Cloudflare data centers.

• Cloudflare managed regions use a pre-defined membership set.

• Custom Regions define membership with an expression. The most common field is country_code: the ISO code where each data center is located:

That expression is evaluated against data centers' metadata. Matches become your region's membership set and are distributed globally, so every data center can quickly answer: "Am I in this region?"

As Cloudflare's infrastructure evolves, membership updates, so new matching data centers can join automatically. You do not need to worry about when data centers are added or removed from the definition; Cloudflare takes care of that for you. 

If a request enters Cloudflare outside your region, the next step is choosing the best in-region destination for that ingress location.

Cloudflare's selection is a two-step process:

1. Allowed destinations: the region's membership set (which data centers are in-region)

2. Best destination for this ingress: a performance-ranked list tailored to the data center where the request entered our network

These per-ingress rankings are computed centrally and distributed to the edge via Quicksilver. They are built from measured path quality across our network (not just physical distance), using signals like:

• Network performance: Latency and reliability indicators (for example, loss and timeouts)

• Capacity and load: Available resources and current utilization

• Operational status: Health and availability

At routing time, we intersect the ranked list with the region membership set and choose from the top candidates. The final choice is validated against live availability: destinations that are disabled or otherwise unreachable are skipped, so traffic can fail over to the next best in-region option.

This is the process when a request arrives at Cloudflare:

1. Ingress. The request lands at the nearest data center. Layer 3/4 DDoS mitigation is applied immediately.

2. Configuration lookup. Is a region configured for this zone?

3. Membership check. Is this data center in the configured region?

4. Routing decision.

   • In region: Process locally. TLS termination and all Layer 7 services run here.

   • Out of region: An in-region data center is selected, and the request is forwarded over Cloudflare's private backbone.

5. In-region processing. TLS is terminated for the first time. Layer 7 services run here.

6. Origin connection. The processed request is sent to your origin.

As noted above, Cloudflare does not decrypt the request outside your defined region. Instead, we forward it to the closest data center inside your region, where decryption and Layer 7 services occur. 

Resilience is built in at multiple layers:

• Multiple candidates: Routing considers multiple in-region options and selects an available destination in real time.

• Health-aware routing: Unhealthy or disabled data centers are excluded.

• Data quality gates: Fresh routing inputs are only published when sufficient monitoring data is available. 

• Fail-close design: If no valid in-region destination exists, the connection fails rather than processing outside your region.

The new Cloudflare managed regions are available now for customers using Regional Services. If you would like to use these, just follow the standard process to enable it via the Cloudflare Dashboard or via the Cloudflare API. Custom Regions are new and follow a different process.

To ensure a perfect fit for your needs, the initial setup for Custom Regions is a collaborative process. To get started, simply reach out to your account team. They will work with you to define your region and get it deployed. While the service is not yet self-serve, we are continuously developing the technology and will revisit this as the feature matures. Please note that some technical limitations may apply, and your solutions engineer is the perfect person to discuss the details with.

If you are interested in learning more about Regional Services, please contact your account team. If you’re not yet a Cloudflare customer, we would love to have you. Fill out this form, and we’ll be in touch with you soon.

At Cloudflare, we believe that deploying effective cybersecurity measures is the best way to protect the privacy of personal information and can be more effective than making sure that information stays within a particular jurisdiction. Yet, we hear from customers in Europe, India, Australia, Japan, and many other regions that, as part of their privacy programs, they need solutions to localize data in order to meet their regulatory obligations.

So as we think about Data Privacy Day, which is coming up on January 28, we are in the interesting position of disagreeing with those who believe that data localization is a proxy for better data privacy, but of also wanting to support our customers who have to comply with certain regulations.

For this reason, we introduced our Data Localization Suite (DLS) in 2020 to help customers navigate a data protection landscape that focuses more and more on data localization. With the DLS, customers can use Cloudflare’s powerful global network and security measures to protect their businesses, while keeping the data we process on their behalf local. Since its launch, we’ve had many customers adopt the Data Localization Suite. In this blog post we want to share updates about how we’re making the DLS more comprehensive and easier to use.

We frequently field questions from customers who hear about new local laws or interpretations of existing regulations that seem to limit what they can do with data. This is especially confusing for customers doing business on the global Internet because they have to navigate regulations that suggest customers based in one country can’t use products from companies based in another country, unless extensive measures are put in place.

We don’t think this is any way to regulate the Internet. As we’ll talk more about in our blog post tomorrow about cross-border data transfers, we’re encouraged to see new developments aimed at establishing a common set of data protections across jurisdictions to make these data transfers more seamless.

In the meantime, we have the Data Localization suite to help our customers navigate these challenges.

We developed DLS to address three primary customer concerns:

1. How do I ensure my encryption keys stay in my jurisdiction?

2. How can I ensure that application services like caching and WAF only run in my jurisdiction?

3. How can I ensure that logs and metadata are never transferred outside my jurisdiction?

To address these concerns, our DLS has an encryption key component, a component that addresses where content in transit is terminated and inspected, and a component that keeps metadata within a customers’ jurisdiction:

1. Encryption KeysCloudflare has long offered Keyless SSL and Geo Key Manager, which ensure that private SSL/TLS key material never leaves the EU. Customers using our Geo Key Manager can choose for encryption keys to be stored only in data centers in the region the customer specifies. Keyless SSL ensures that Cloudflare never has possession of the private key material at all; Geo Key Manager ensures that keys are protected with cryptographic access control, so they can only be used in specified regions.

2. Regional Services:Regional Services ensures that Cloudflare will only be able to decrypt and inspect the content of HTTPS traffic inside a customer’s chosen region. When Regional Services is enabled, regardless of which data center traffic first hits on our global network, rather than decrypting it at the first data center, we forward the TCP stream in encrypted form. Once it reaches a data center inside the customer’s chosen region, we decrypt and apply our Layer 7 security measures to prevent malicious traffic from reaching our customers’ websites.

3. Customer Metadata Boundary:With this option enabled, no end user traffic logs (which contain IP addresses) that Cloudflare processes on behalf of our customers will leave the region chosen by the customer. (Currently available only in the EU and US.)

Although we launched the Data Localization Suite with Europe and America in mind at first, we quickly realized a lot of our customers were interested in versions specific to the Asia-Pacific region as well. In September of last year, we added support for Regional Services in Japan, Australia, and India.

Then in December 2022 we announced that Geo Key Manager is now accessible in 15 regions. Customers can both allow- and deny-list the regions that they want us to support for fine-grained control over where their key material is stored.

See also our technical deep dive about how we built Geo Key Manager v2.

Regional Services and the Customer Metadata Boundary offer important protections for our customers — but they’ve been too hard to use. Both have required manual steps taken by teams at Cloudflare, and have had confusing (or no) public APIs.

Today, we’re fixing that! We’re excited to announce two big improvements to usability:

1. Regional Services customers now have a dedicated UI and API for enabling Regional Services, accessible straight from the DNS tab. Different regions can now be set on a per-hostname basis

2. Customers who want to use the Metadata Boundary can use our self-service API to enable it.

We’re excited about making it easier to use the Data Localization Suite and give customers more control over exactly how to localize which parts of their traffic.

The Data Localization Suite is accessible today for enterprise customers. Please chat with your account representative if you’re interested in using it, and you can find more information here about configuring it in our developer docs.

We have lots more planned for the Data Localization Suite this year. We plan to support many more regions for Regional Services and the Metadata Boundary. We also plan to have full data localization support for all of our Zero Trust products. Stay tuned to the blog for more!