This allows engineers to meet strict data sovereignty and compliance requirements without losing global DDoS protection. By decoupling ingestion from processing, teams can precisely control where TLS termination and L7 logic occur, which is critical for regulated industries and AI data privacy.
A key part of our mission to help build a better Internet is giving our customers the tools they need to operate securely and efficiently, no matter their compliance requirements. Our Regional Services product helps customers do just that, allowing them to meet data sovereignty legal obligations using the power of Cloudflare’s global network.
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:
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.
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.
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.
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:
Use case | Expression | Definition |
Single country |
| Turkey |
Multiple countries |
| Germany, France, and the Netherlands |
Exclude countries |
| Everything except the U.S., Canada, and Mexico |
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:
Allowed destinations: the region's membership set (which data centers are in-region)
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:
Ingress. The request lands at the nearest data center. Layer 3/4 DDoS mitigation is applied immediately.
Configuration lookup. Is a region configured for this zone?
Membership check. Is this data center in the configured region?
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.
In-region processing. TLS is terminated for the first time. Layer 7 services run here.
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.
Continue reading on the original blog to support the author
Read full articleMonitoring global disruptions helps engineers distinguish between application bugs and systemic infrastructure failures. These events underscore the importance of multi-region redundancy and the technical mechanisms, like BGP and filtering, that govern global internet reachability.
This feature allows AI-generated or user-provided code to have its own persistent, low-latency database without manual provisioning. It bridges the gap between ephemeral serverless execution and stateful application needs in a secure, sandboxed environment.
Security teams are overwhelmed by data noise. This architecture demonstrates how to transform massive telemetry into prioritized, actionable insights using a distributed system of specialized microservices, reducing incident response times and closing critical configuration gaps.
This architecture demonstrates how to build high-scale, low-latency platforms by moving compute and storage to the edge. By eliminating ETL and using sharded SQLite via Durable Objects, engineers can gain real-time insights from massive datasets without centralized database bottlenecks.
