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.

Today, we’re very happy to announce the general availability of a new region for Regional Services that allows you to limit your traffic to only ISO 27001 certified data centers inside the EU. This helps customers that have very strict requirements surrounding which data centers are allowed to decrypt and service traffic. Enabling this feature is a one-click operation right on the Cloudflare dashboard.

In 2020, we saw an increase in prospects asking about data localization. Specifically, increased regulatory pressure limited them from using vendors that operated at global scale. We launched Regional Services, a new way for customers to use the Cloudflare network. With Regional Services, we put customers back in control over which data centers are used to service traffic. Regional Services operates by limiting exactly which data centers are used to decrypt and service HTTPS traffic. For example, a customer may want to use only data centers inside the European Union to service traffic. Regional Services operates by leveraging our global network for DDoS protection but only decrypting traffic and applying Layer 7 products inside data centers that are located inside the European Union.

We later followed up with the Data Localization Suite and additional regions: India, Japan, and Australia.

With Regional Services, customers get the best of both worlds: we empower them to use our global network for volumetric DDoS protection whilst limiting where traffic is serviced. We do that by accepting the raw TCP connection at the closest data center but forwarding it on to a data center in-region for decryption. That means that only machines of the customer’s choosing actually see the raw HTTP request, which could contain sensitive data such as a customer’s bank account or medical information.

Traditionally we’ve seen requests for data localization largely center around countries or geographic areas. Many types of regulations require companies to make promises about working only with vendors that are capable of restricting where their traffic is serviced geographically. Organizations can have many reasons for being limited in their choices, but they generally fall into two buckets: compliance and contractual commitments.

More recently, we are seeing that more and more companies are asking about security requirements. An often asked question about security in IT is: how do you ensure that something is safe? For instance, for a data center you might be wondering how physical access is managed. Or how often security policies are reviewed and updated. This is where certifications come in. A common certification in IT is the ISO 27001 certification:

Per the ISO.org:

“ISO/IEC 27001 is the world’s best-known standard for information security management systems (ISMS) and their requirements. Additional best practice in data protection and cyber resilience are covered by more than a dozen standards in the ISO/IEC 27000 family. Together, they enable organizations of all sectors and sizes to manage the security of assets such as financial information, intellectual property, employee data and information entrusted by third parties.”

In short, ISO 27001 is a certification that a data center can achieve that ensures that they maintain a set of security standards to keep the data center secure. With the new Regional Services region, HTTPS traffic will only be decrypted in data centers that hold the ISO 27001 certification. Products such as WAF, Bot Management and Workers will only be applied in those relevant data centers.

The other update we’re excited to announce is a brand new User Interface for configuring the Data Localization Suite. The previous UI was limited in that customers had to preconfigure a region for an entire zone: you couldn’t mix and match regions. The new UI allows you to do just that: each individual hostname can be configured for a different region, directly on the DNS tab:

Configuring a region for a particular hostname is now just a single click away. Changes take effect within seconds, making this the easiest way to configure data localization yet. For customers using the Metadata Boundary, we’ve also launched a self-serve UI that allows you to configure where logs flow:

We’re excited about these new updates that give customers more flexibility in choosing which of Cloudflare’s data centers to use as well as making it easier than ever to configure them. The new region and existing regions are now a one-click configuration option right from the dashboard. As always, we love getting feedback, especially on what new regions you’d like to see us add in the future. In the meantime, if you’re interested in using the Data Localization Suite, please reach out to your account team.

Today, traffic on the Internet stays encrypted through the use of public and private keys that encrypt the data as it's being transmitted. Cloudflare helps secure millions of websites by managing the encryption keys that keep this data protected. To provide lightning fast services, Cloudflare stores these keys on our fleet of data centers that spans more than 150 countries. However, some compliance regulations require that private keys are only stored in specific geographic locations.

In 2017, we introduced Geo Key Manager, a product that allows customers to store and manage the encryption keys for their domains in different geographic locations so that compliance regulations are met and that data remains secure. We launched the product a few months before General Data Protection Regulation (GDPR) went into effect and built it to support three regions: the US, the European Union (EU), and a set of our top tier data centers that employ the highest security measures. Since then, GDPR-like laws have quickly expanded and now, more than 15 countries have comparable data protection laws or regulations that include restrictions on data transfer across and/or data localization within a certain boundary.

At Cloudflare, we like to be prepared for the future. We want to give our customers tools that allow them to maintain compliance in this ever-changing environment. That’s why we’re excited to announce a new version of Geo Key Manager — one that allows customers to define boundaries by country, ”only store my private keys in India”, by a region ”only store my private keys in the European Union”, or by a standard, such as “only store my private keys in FIPS compliant data centers” — now available in Closed Beta, sign up here!

Geo Key Manager has been around for a few years now, and we’ve used this time to gather feedback from our customers. As the demand for a more flexible system grew, we decided to go back to the drawing board and create a new version of Geo Key Manager that would better meet our customers’ needs.

We initially launched Geo Key Manager with support for US, EU, and Highest Security Data centers. Those regions were sufficient at the time, but customers wrestling with data localization obligations in other jurisdictions need more flexibility when it comes to selecting countries and regions. Some customers want to be able to set restrictions to maintain their private keys in one country, some want the keys stored everywhere except in certain countries, and some may want to mix and match rules and say “store them in X and Y, but not in Z”. What we learned from our customers is that they need flexibility, something that will allow them to keep up with the ever-changing rules and policies — and that’s what we set out to build out.

The next issue we faced was scalability.  When we built the initial regions, we included a hard-coded list of data centers that met our criteria for the US, EU, “high security” data center regions.  However, this list was static because the underlying cryptography did not support dynamic changes to our list of data centers. In order to distribute private keys to new data centers that met our criteria, we would have had to completely overhaul the system. In addition to that, our network significantly expands every year, with more than 100 new data centers since the initial launch. That means that any new potential locations that could be used to store private keys are currently not in use, degrading the performance and reliability of customers using this feature.

With our current scale, automation and expansion is a must-have. Our new system needs to dynamically scale every time we onboard or remove a data center from our Network, without any human intervention or large overhaul.

Finally, one of our biggest learnings was that customers make mistakes, such as defining a region that’s so small that availability becomes a concern. Our job is to prevent our customers from making changes that we know will negatively impact them.

Cloudflare has significantly grown in the last few years and so has our international customer base. Customers need to keep their traffic regionalized. This region can be as broad as a continent — Asia, for example. Or, it can be a specific country, like Japan.

From our conversations with our customers, we’ve heard that they want to be able to define these regions themselves. This is why today we’re excited to announce that customers will be able to use Geo Key Manager to create what we call “policies”.

A policy can be a single country, defined by two-letter (ISO 3166) country code. It can be a region, such as “EU” for the European Union or Oceania. It can be a mix and match of the two, “country:US or region: EU”.

Our new policy based Geo Key Manager allows you to create allowlist or blocklists of countries and supported regions, giving you control over the boundary in which your private key will be stored. If you’d like to store your private keys globally and omit a few countries, you can do that.

If you would like to store your private keys in the EU and US, you would make the following API call:

curl -X POST "https://api.cloudflare.com/client/v4/zones/zone_id/custom_certificates" \
     -H "X-Auth-Email: user@example.com" \
     -H "X-Auth-Key: auth-key" \
     -H "Content-Type: application/json" \
     --data '{"certificate":"certificate","private_key":"private_key","policy":"(country: US) or (region: EU)", "type": "sni_custom"}'

If you would like to store your private keys in the EU, but not in France, here is how you can define that:

curl -X POST "https://api.cloudflare.com/client/v4/zones/zone_id/custom_certificates" \
     -H "X-Auth-Email: user@example.com" \
     -H "X-Auth-Key: auth-key" \
     -H "Content-Type: application/json" \
     --data '{"certificate":"certificate","private_key":"private_key","policy": "region: EU and (not country: FR)", "type": "sni_custom"}'

Geo Key Manager can now support more than 30 countries and regions. But that’s not all! The superpower of our Geo Key Manager technology is that it doesn’t actually have to be “geo” based, but instead, it’s attribute based. In the future, we’ll have a policy that will allow our customers to define where their private keys are stored based on a compliance standard like FedRAMP or ISO 27001.

By giving our customers the remote control for Geo Key Manager, we want to make sure that customers understand the impact of their changes on both redundancy and latency.

On the redundancy side, one of our biggest concerns is allowing customers to choose a region small enough that if a data center is removed for maintenance, for example, then availability is drastically impacted. To protect our customers, we’ve added redundancy restrictions. These prevent our customers from setting regions with too few data centers, ensuring that all the data centers within a policy can offer high availability and redundancy.

Not just that, but in the last few years, we’ve significantly improved the underlying networking that powers Geo Key Manager. For more information on how we did that, keep an eye out for a technical deep dive inside Geo Key Manager.

With the original regions (US, EU, and Highest Security Data Centers), we learned customers may overlook possible latency impacts that occur when defining the key manager to a certain region. Imagine your keys are stored in the US. For your Asia-based customers, there’s going to be some latency impact for the requests that go around the world. Now, with customers being able to define more granular regions, we want to make sure that before customers make that change, they see the impact of it.

If you’re an E-Commerce platform then performance is always top-of-mind. One thing that we’re working on right now is performance metrics for Geo Key Manager policies both from a regional point of view — “what’s the latency impact for Asia based customers?” and from a global point of view — “for anyone in the world, what is the average impact of this policy?”.

By seeing the latency impact, if you see that the impact is unacceptable, you may want to create a separate domain for your service that’s specific to the region that it’s serving.

Interested in trying out the latest version of Geo Key Manager? Fill out this form.

Geo Key Manager is only available via API at the moment. But, we are working on creating an easy-to-use UI for it, so that customers can easily manage their policies and regions. In addition, we’ll surface performance measurements and warnings when we see any degraded impact in terms of performance or redundancy to ensure that customers are mindful when setting policies.

We’re also excited to extend our Geo Key Manager product beyond custom uploaded certificates. In the future, certificates issued through Advanced Certificate Manager or SSL for SaaS will be allowed to add policy based restrictions for the key storage.

Finally, we’re looking to add more default regions to make the selection process simple for our customers. If you have any regions that you’d like us to support, or just general feedback or feature requests related to Geo Key Manager, make a note of it on the form. We love hearing from our customers!

We announced the Data Localization Suite in 2020, when requirements for data localization were already important in the European Union. Since then, we’ve witnessed a growing trend toward localization globally. We are thrilled to expand our coverage to these countries in Asia Pacific, allowing more customers to use Cloudflare by giving them precise control over which parts of the Cloudflare network are able to perform advanced functions like WAF or Bot Management that require inspecting traffic.

In 2020, we introduced (Regional Services), a new way for customers to use Cloudflare. With Regional Services, customers can limit which data centers actually decrypt and inspect traffic. This helps because certain customers are affected by regulations on where they are allowed to service traffic. Others have agreements with their customers as part of contracts specifying exactly where traffic is allowed to be decrypted and inspected.

As one German bank told us: "We can look at the rules and regulations and debate them all we want. As long as you promise me that no machine outside the European Union will see a decrypted bank account number belonging to one of my customers, we're happy to use Cloudflare in any capacity".

Under normal operation, Cloudflare uses its entire network to perform all functions. This is what most customers want: leverage all of Cloudflare’s data centers so that you always service traffic to eyeballs as quickly as possible. Increasingly, we are seeing customers that wish to strictly limit which data centers service their traffic. With Regional Services, customers can use Cloudflare's network but limit which data centers perform the actual decryption. Products that require decryption, such as WAF, Bot Management and Workers will only be applied within those data centers.

You might be asking yourself: how does that even work? Doesn't Cloudflare operate an anycast network? Cloudflare was built from the bottom up to leverage anycast, a routing protocol. All of Cloudflare's data centers advertise the same IP addresses through Border Gateway Protocol. Whichever data center is closest to you from a network point of view is the one that you'll hit.

This is great for two reasons. The first is that the closer the data center to you, the faster the reply. The second great benefit is that this comes in very handy when dealing with large DDoS attacks. Volumetric DDoS attacks throw a lot of bogus traffic at you, which overwhelms network capacity. Cloudflare's anycast network is great at taking on these attacks because they get distributed across the entire network.

Anycast doesn't respect regional borders, it doesn't even know about them. Which is why out of the box, Cloudflare can't guarantee that traffic inside a country will also be serviced there. Although typically you’ll hit a data center inside your country, it’s very possible that your Internet Service Provider will send traffic to a network that might route it to a different country.

Regional Services solves that: when turned on, each data center becomes aware of which region it is operating in. If a user from a country hits a data center that doesn't match the region that the customer has selected, we simply forward the raw TCP stream in encrypted form. Once it reaches a data center inside the right region, we decrypt and apply all Layer 7 products. This covers products such as CDN, WAF, Bot Management and Workers.

Let's take an example. A user is in Kerala, India and their Internet Service Provider has determined that the fastest path to one of our data centers is to Colombo, Sri Lanka. In this example, a customer may have selected India as the sole region within which traffic should be serviced. The Colombo data center sees that this traffic is meant for the India region. It does not decrypt, but instead forwards it to the closest data center inside India. There, we decrypt and products such as WAF and Workers are applied as if the traffic had hit the data center directly.

Historically, we’ve seen most interest in Regional Services in geographic regions such as the European Union and the Americas. Over the past few years, however, we are seeing a lot of interest from Asia Pacific. Based on customer feedback and analysis on regulations we quickly concluded there were three key regions we needed to support: India, Japan and Australia. We’re proud to say that all three are now generally available for use today.

But we’re not done yet! We realize there are many more customers that require localization to their particular region. We’re looking to add many more in the near future and are working hard to make it easier to support more of them. If you have a region in mind, we’d love to hear it!

India, Japan and Australia are all live today! If you’re interested in using the Data Localization Suite, contact your account team!

We operate a global network spanning more than 200 cities. Each data center runs servers with the exact same software stack. This has enabled Cloudflare to quickly and efficiently add capacity where needed. It also allows our engineers to ship features with ease: deploy once, and it's available globally.

The same benefit applies to our customers: configure once and that change is applied everywhere in seconds, regardless of whether they’re changing security features, adding a DNS record or deploying a Cloudflare Worker containing code.

Having a homogenous network is great from a routing point of view: whenever a user performs an HTTP request, the closest datacenter is found due to Cloudflare's Anycast network. BGP looks at the hops that would need to be traversed to find the closest data center. This means that someone near the Canadian border (let's say North Dakota) could easily find themselves routed to Winnipeg (inside Canada) instead of a data center in the United States. This is generally what our customers want and expect: find the fastest way to serve traffic, regardless of geographic location.

Some organizations, however, have expressed preferences for maintaining regional control over their data for a variety of reasons. For example, they may be bound by agreements with their own customers that include geographic restrictions on data flows or data processing. As a result, some customers have requested control over where their web traffic is serviced.

Regional Services gives our customers the ability to accommodate regional restrictions while still using Cloudflare’s global edge network. As of today, Enterprise customers can add Regional Services to their contracts. With Regional Services, customers can choose which subset of data centers are able to service traffic on the HTTP level. But we're not reducing network capacity to do this: that would not be the Cloudflare Way. Instead, we're allowing customers to use our entire network for DDoS protection but limiting the data centers that apply higher-level layer 7 security and performance features such as WAF, Workers, and Bot Management.

Traffic is ingested on our global Anycast network at the location closest to the client, as usual, and then passed to data centers inside the geographic region of the customer’s choice. TLS keys are only stored and used to actually handle traffic inside that region. This gives our customers the benefit of our huge, low-latency, high-throughput network, capable of withstanding even the largest DDoS attacks, while also giving them local control: only data centers inside a customer’s preferred geographic region will have the access necessary to apply security policies.

The diagram below shows how this process works. When users connect to Cloudflare, they hit the closest data center to them, by nature of our Anycast network. That data center detects and mitigates DDoS attacks. Legitimate traffic is passed through to a data center with the geographic region of the customers choosing. Inside that data center, traffic is inspected at OSI layer 7 and HTTP products can work their magic:

• Content can be returned from and stored in cache

• The WAF looks inside the HTTP payloads

• Bot Management detects and blocks suspicious activity

• Workers scripts run

• Access policies are applied

• Load Balancers look for the best origin to service traffic

Today's launch includes preconfigured geographic regions; we'll look to add more depending on customer demand. Today, US and EU regions are available immediately, meaning layer 7 (HTTP) products can be configured to only be applied within those regions and not outside of them.

The US and EU maps are depicted below. Purple dots represent data centers that apply DDoS protection and network acceleration. Orange dots represent data centers that process traffic.

We're very excited to provide new tools to our customers, allowing them to dictate which of our data centers employ HTTP features and which do not. If you're interested in learning more, contact sales@cloudflare.com.