Bajada: Cloudflare amplió Regional Services con nuevas regiones gestionadas y presentó Custom Regions, una capacidad que permite definir fronteras geográficas propias para inspección TLS y procesamiento L7. El cambio impacta directamente en compliance, arquitectura de edge security y operación multirregional.
Introducción
La discusión sobre soberanía de datos dejó de ser un tema exclusivamente legal para convertirse en una decisión de arquitectura. Equipos de plataforma, seguridad y SRE que operan servicios globales necesitan cumplir restricciones geográficas sin degradar protección ni performance. En ese contexto, Cloudflare anunció la expansión de Regional Services y el lanzamiento de Custom Regions, una opción para definir límites geográficos personalizados en dónde se termina TLS y se ejecutan servicios de capa 7.
Qué ocurrió
El anuncio incorpora dos cambios. Primero, Cloudflare sumó nuevas regiones administradas para Regional Services, incluyendo Turquía, Emiratos Árabes Unidos e IRAP para cumplimiento en Australia. Segundo, habilitó Custom Regions, que permite a clientes enterprise construir su propia región lógica con reglas de pertenencia por país (por ejemplo incluir o excluir conjuntos específicos de países).
El modelo operativo se mantiene: el tráfico entra por el PoP más cercano para mitigación L3/L4 y luego, si corresponde, se enruta por backbone privado a un PoP dentro de la región definida antes de terminar TLS y aplicar WAF, Bot Management, Workers o balanceo. Es decir, la inspección de contenido se mantiene en el perímetro geográfico configurado.
Impacto para DevOps / Infraestructura / Cloud / Seguridad
Para equipos DevOps y de infraestructura, el cambio reduce fricción entre objetivos que suelen competir: resiliencia global y cumplimiento local. En lugar de operar arquitecturas separadas por geografía o depender de soberign clouds aisladas, se puede mantener un plano de protección global con controles de procesamiento regionalizados.
En seguridad, la ventaja es que no se pierde absorción de DDoS en el borde global mientras se controla dónde ocurre la decriptación. En cloud y plataformas, habilita estrategias multi-país más finas (por ejemplo EMEA sin ciertos territorios, o un conjunto exacto de países para cargas sensibles). En operaciones, mejora gobernanza porque la frontera de datos queda definida como política y no como excepción manual por aplicación.
Detalles técnicos
Cloudflare describe tres componentes técnicos detrás de la funcionalidad:
1) **Definición de membresía de región**: en regiones administradas Cloudflare define el conjunto de data centers; en Custom Regions el cliente define una expresión (por ejemplo `country_code in [«DE»,»FR»,»NL»]` o exclusiones).
2) **Selección de destino in-region**: cuando el ingreso ocurre fuera de región, el sistema calcula candidatos in-region y elige rutas con mejor calidad real (latencia, pérdida, capacidad y estado operativo), no solo distancia geográfica.
3) **Enforcement de frontera**: la terminación TLS y servicios L7 se ejecutan únicamente dentro de región. Si no existe destino válido in-region, el diseño es fail-close para evitar procesamiento fuera de la frontera definida.
Desde el punto de vista de ingeniería de plataforma, esto permite convertir requisitos regulatorios en configuración declarativa, con menor dependencia de topologías rígidas por país.
Qué deberían hacer los administradores o equipos técnicos
1. **Mapear flujos sensibles**: identificar hostnames, APIs y workloads que requieren residencia o inspección regional.
2. **Definir políticas por criticidad**: no todo tráfico necesita la misma regionalización; separar datos personales, credenciales, logs y telemetría.
3. **Probar impacto de latencia**: medir p95/p99 con y sin regionalización para rutas transcontinentales.
4. **Ajustar observabilidad**: validar que trazas, logs y alertas respeten la frontera de datos establecida.
5. **Revisar fallas controladas**: ensayar escenarios sin destino válido in-region para confirmar comportamiento fail-close y playbooks de contingencia.
6. **Formalizar gobernanza**: documentar las reglas de región como artefactos versionados (IaC/políticas) y vincularlas a controles de compliance.
Conclusión
Custom Regions no es solo una mejora de producto: es una pieza de diseño operativo para organizaciones que necesitan seguridad global con control geográfico preciso. Para equipos técnicos, la oportunidad está en estandarizar políticas de residencia de datos sin sacrificar protección de borde ni capacidad de escalar. El valor real aparecerá en la ejecución: observabilidad, pruebas de latencia, y gobernanza continua de esas fronteras.
Fuentes
- https://blog.cloudflare.com/custom-regions/
- https://developers.cloudflare.com/data-localization/
- https://developers.cloudflare.com/data-localization/regional-services/