Add Regional Services setup guides and align version naming#31507
Add Regional Services setup guides and align version naming#31507mathew-cf wants to merge 10 commits into
Conversation
…ion naming - Add "Ways to use Regional Services" section clarifying the three options (Regional Hostnames, Regionalized Spectrum Applications, Regionalized IP Bindings) and retiring the v1/v2/v3 labels in favor of descriptive names - Add Regionalized Spectrum Applications (RSv1) setup guide - Add Regionalized IP Bindings setup guide, including the DLS regions API - Add FAQ entries on partial-traffic regionalization, out-of-region handling, and Static IP/BYOIP support per option - Update Static IP/BYOIP compatibility footnote
Review⏸️ Automatic reviews for this PR are paused. This PR has already received 2 automatic reviews. To run another review, a codeowner can comment
Code ReviewThis code review is in beta and may not always be helpful — use your judgment. ❌ This review could not complete this run; results may be incomplete. It will retry on the next push. Warnings (1)
Style Guide ReviewWarnings (8)
Suggestions (11)
CommandsOnly codeowners can run commands. Post a comment with the command to trigger it.
|
- Fix Spectrum Static IP/BYOIP setup: customer addresses go in edge_ips (type: static), not origin_direct (which is the origin server) - Use 'refer to' instead of 'see' for links (style guide) - Split semicolon-joined clause in ip-bindings into two sentences - Use active voice in the Static IP/BYOIP compatibility footnote
…ervices - Rename get-started.mdx to regional-hostnames.mdx (titled "Regional Hostnames"), add 301 redirect, and repoint all internal links so the three RS options each have a consistently named guide - Add a 3-offering comparison table and an action-oriented "Get started" section to the Regional Services overview - ip-bindings: clarify managed vs custom regions, explain the propagation window behavior, and document the required API token permissions (DLS Read for reads; DLS Write + IP Prefixes Write for binding writes) - spectrum-applications: correct the zone model (multiple apps per zone, one region applies zone-wide), add Spectrum-in-contract prerequisite, document the Spectrum hostname limit and workarounds, emphasize account-team coordination, and link the shared verification guide and custom-regions blog - faq: note Spectrum regionalization is zone-wide, link the comparison table and RS overview, and add a global assets.example.com example - changelog: reword IP Bindings use case so it doesn't steer away from address maps
Reflect that IP Bindings suit broad configurations and are fully self-serve via address maps (no per-zone account-team setup), which many customers find simpler than Regionalized Spectrum Applications.
A binding must become active (after propagation) before its addresses can be added to an address map; addr-api rejects the operation otherwise. Traffic routing is uninterrupted, but address-map management is gated on an active binding. Add ordering guidance: create the binding first, then configure address maps once it is active.
Establish region-support.mdx as the canonical reference with a new "Region types" section defining managed vs custom regions, and clarify that the four DLS region concepts are distinct: - Managed regions: Cloudflare-defined, all RS options - Custom regions: per-account via account team; Spectrum + IP Bindings only, not Regional Hostnames - CMB: US or EU only (Global = unset, no boundary; FedRAMP uses US) - Geo Key Manager: own country-based model Standardize "standard region" -> "managed region", add a CMB-column legend to the region table, cross-link all RS/CMB/GKM guides to the Region types section, fix the CMB dashboard "Global" description, and add a managed-vs-custom FAQ entry. No internal request processes exposed; RSv3/SNI remains undocumented.
The CMB config/API values are lowercase (eu, us); align the prose and dashboard references to match the API examples.
| - [Spectrum](/spectrum/) is included in your Enterprise contract. Spectrum is an add-on, so it must be part of your contract before it can be enabled. | ||
| - Your account has the **Regional Services** and **Spectrum** entitlements enabled. Contact your account team to enable them. | ||
| - You have a hostname proxied through Cloudflare that you want to regionalize. | ||
| - If you want to use your own addresses, you have onboarded [Static IPs](/byoip/concepts/static-ips/) or a [BYOIP](/byoip/) prefix. |
There was a problem hiding this comment.
We should clarify here that Static IPs specifically for Spectrum are required: https://developers.cloudflare.com/spectrum/about/static-ip/
|
|
||
| ## What is the difference between managed and custom regions? | ||
|
|
||
| **Managed regions** are predefined regions that Cloudflare maintains (for example, `eu` or `us`) and are available to all accounts. **Custom regions** are tailored to your account, restricting processing to a specific set of data centers when the managed regions do not meet your compliance requirements. Custom regions are set up through your account team and are available for Regionalized Spectrum Applications and Regionalized IP Bindings, but not for Regional Hostnames. |
There was a problem hiding this comment.
[nit] This is a essentially a repeat of the Region Types section. Ideally we'd have a single source for these details.
| - **Customer Metadata Boundary** can be set to the **United States** or the **European Union**. By default no boundary is applied. FedRAMP customers set it to the United States. | ||
| - **Geo Key Manager** controls where TLS private keys are stored using its own set of locations. | ||
|
|
||
| The tables below show which managed regions each feature supports. |
There was a problem hiding this comment.
More consistent with the table description.
| The tables below show which managed regions each feature supports. | |
| The tables below show which managed regions each product supports. |
|
|
||
| | Offering | How traffic is addressed | Granularity | Static IP / BYOIP | API | Availability | Best for | | ||
| | ------------------------------------------------------------------------------------- | ------------------------------ | ---------------------------------- | ------------------------ | ---------------------------- | ------------ | -------------------------------------------------------------- | | ||
| | [Regional Hostnames](/data-localization/regional-services/regional-hostnames/) | Cloudflare shared anycast IPs | Per hostname | Not supported | Regional Hostnames API | GA | Most deployments; regionalizing specific proxied hostnames | |
There was a problem hiding this comment.
[nit] All methods use anycast, noting it here raises the question if the other aren't.
| | [Regional Hostnames](/data-localization/regional-services/regional-hostnames/) | Cloudflare shared anycast IPs | Per hostname | Not supported | Regional Hostnames API | GA | Most deployments; regionalizing specific proxied hostnames | | |
| | [Regional Hostnames](/data-localization/regional-services/regional-hostnames/) | Cloudflare shared IPs | Per hostname | Not supported | Regional Hostnames API | GA | Most deployments; regionalizing specific proxied hostnames | |
| | ------------------------------------------------------------------------------------- | ------------------------------ | ---------------------------------- | ------------------------ | ---------------------------- | ------------ | -------------------------------------------------------------- | | ||
| | [Regional Hostnames](/data-localization/regional-services/regional-hostnames/) | Cloudflare shared anycast IPs | Per hostname | Not supported | Regional Hostnames API | GA | Most deployments; regionalizing specific proxied hostnames | | ||
| | [Regionalized Spectrum Applications](/data-localization/regional-services/spectrum-applications/) | Dedicated IP via Spectrum app | Per zone (all Spectrum HTTP/S apps) | Static IPs and BYOIP | Spectrum API | GA | Traffic addressed by IP that needs Static IPs or BYOIP | | ||
| | [Regionalized IP Bindings](/data-localization/regional-services/ip-bindings/) | BYOIP prefix at the IP layer | Per CIDR / IP prefix (scales to whole prefixes) | BYOIP only | Data Localization Suite API | GA | Broad, self-serve regionalization managed simply via address maps | |
There was a problem hiding this comment.
| | [Regionalized IP Bindings](/data-localization/regional-services/ip-bindings/) | BYOIP prefix at the IP layer | Per CIDR / IP prefix (scales to whole prefixes) | BYOIP only | Data Localization Suite API | GA | Broad, self-serve regionalization managed simply via address maps | | |
| | [Regionalized IP Bindings](/data-localization/regional-services/ip-bindings/) | BYOIP prefix at the IP layer | Per CIDR / IP prefix (scales to whole prefixes) | BYOIP only | Data Localization Suite API | GA | Broad, self-serve regionalization managed via address maps | |
|
|
||
| - **Regionalized Spectrum Applications** — Regionalize [Spectrum](/spectrum/) HTTP/S applications. Spectrum applications use a separate regionalization mechanism from the Regional Hostnames API, and work with both [Static IPs](/byoip/concepts/static-ips/) and [Bring Your Own IP (BYOIP)](/byoip/). To set it up, refer to [Regionalized Spectrum Applications](/data-localization/regional-services/spectrum-applications/). | ||
|
|
||
| - **Regionalized IP Bindings** — Bind a [BYOIP](/byoip/) prefix to a region so that traffic destined for those IP addresses is processed in-region. Because bindings are managed through the API as address maps, this option is well suited to broad configurations (whole prefixes, zones, or accounts) and is fully self-serve once entitlements are enabled — many customers find it simpler to manage than Regionalized Spectrum Applications. This option requires the Regional Services and Regional Services for BYOIP entitlements. To set it up, refer to [Regionalized IP Bindings](/data-localization/regional-services/ip-bindings/). |
There was a problem hiding this comment.
[nit] Seems unnecessary, the use cases are well described.
| - **Regionalized IP Bindings** — Bind a [BYOIP](/byoip/) prefix to a region so that traffic destined for those IP addresses is processed in-region. Because bindings are managed through the API as address maps, this option is well suited to broad configurations (whole prefixes, zones, or accounts) and is fully self-serve once entitlements are enabled — many customers find it simpler to manage than Regionalized Spectrum Applications. This option requires the Regional Services and Regional Services for BYOIP entitlements. To set it up, refer to [Regionalized IP Bindings](/data-localization/regional-services/ip-bindings/). | |
| - **Regionalized IP Bindings** — Bind a [BYOIP](/byoip/) prefix to a region so that traffic destined for those IP addresses is processed in-region. Because bindings are managed through the API as address maps, this option is well suited to broad configurations (whole prefixes, zones, or accounts) and is fully self-serve once entitlements are enabled. This option requires the Regional Services and Regional Services for BYOIP entitlements. To set it up, refer to [Regionalized IP Bindings](/data-localization/regional-services/ip-bindings/). |
Summary
Screenshots (optional)
Documentation checklist