Cloudflare abre la beta privada de Data Residency Architecture para Workers, WAF y logs
Cloudflare anuncia una beta privada para elegir dónde residen reglas WAF, Workers y logs; aún faltan regiones, compatibilidad y detalles de operación.
Cloudflare anunció el 31 de octubre la beta privada de Data Residency Architecture (DRA), una iniciativa que, según la compañía, reconstruye su plano de control y el logging sobre Workers y Durable Objects. El anuncio dice que los clientes podrán elegir dónde residen las reglas WAF, los Workers y los logs, y cambiar esa elección con otro clic. Por ahora es una beta privada y hay que solicitar acceso; Cloudflare no publica una matriz de regiones ni una fecha de disponibilidad general.
-InfraCrew dice: un clic cambia una preferencia; por sí solo no nos cuenta qué copias se movieron ni cuándo.-
Qué promete y qué deja abierto
El anuncio mezcla tres elementos que suelen tocarse en una revisión de residencia de datos: reglas de seguridad, código ejecutado en Workers y registros operativos. Para una plataforma distribuida, “dónde vive” no es una sola casilla: el equipo necesita saber qué datos se procesan, cuáles se conservan y qué metadatos quedan en servicios de control o diagnóstico. Cloudflare enumera esos tres objetos, pero no desglosa el tratamiento de cada copia, ni concreta si el cambio cubre datos históricos o solo despliegues posteriores.
Que el control plane y el logging se reconstruyan sobre Durable Objects es una descripción arquitectónica del proveedor, todavía no una guía de implementación. El texto público no explica cómo se replica la configuración, cómo se comporta una región si deja de estar disponible, ni qué componentes conservan una dependencia global. Tampoco dice si la ubicación seleccionada se aplica al paquete del Worker, al estado que persiste, a las métricas, a las trazas o a todo ello; no conviene completar esos huecos con inferencias sobre el producto.
La propuesta es relevante porque la residencia suele afectar el diseño operativo, no solo el lugar donde se guarda un fichero. Un equipo puede tener que equilibrar requisitos de localización, tolerancia a fallos, observabilidad y acceso del personal de soporte. La beta podría simplificar la elección que presenta Cloudflare, pero el anuncio todavía no permite afirmar qué garantías de disponibilidad o control obtiene una organización concreta.
-InfraCrew dice: el mapa de residencia tiene que incluir la telemetría; los incidentes rara vez respetan el límite entre “dato principal” y “dato auxiliar”.-
Diferencia frente a los controles actuales
La documentación vigente de Cloudflare para Durable Objects describe un camino existente con Regional Services, un namespace jurisdiccional para limitar dónde se ejecutan y persisten los objetos, y Customer Metadata Boundary para metadatos del cliente. Esos controles tienen condiciones concretas: el flujo documentado se refiere a hostnames proxied y combina restricciones del objeto con las regiones desde las que Cloudflare responde. La nueva DRA se anuncia como una arquitectura distinta; el post no afirma que sustituya estas configuraciones ni publica una ruta de migración.
La misma documentación expone un límite operativo importante: con Customer Metadata Boundary, los logs y Analytics de Durable Objects no están disponibles fuera de Estados Unidos. Si la frontera de metadatos se fija en la UE, la pestaña de métricas de Workers & Pages para esos objetos no se rellena. Residencia y visibilidad operativa pueden entrar en tensión, así que conviene validar qué métricas y flujos de diagnóstico exige cada servicio antes de convertir un requisito geográfico en arquitectura.
Esto también evita confundir residencia con una declaración completa de soberanía o cumplimiento. El anuncio no especifica lista de ubicaciones, excepciones, acceso administrativo, transferencias de soporte ni certificaciones aplicables a la beta. Esas respuestas tendrán que venir con documentación de producto y condiciones contractuales; una etiqueta de región en el panel no las reemplaza.
-InfraCrew dice: si la métrica desaparece al fijar la frontera, el equipo de guardia también necesita saberlo antes del cambio, no durante el primer incidente.-
Qué pedir antes de probarla
Para una evaluación útil, el equipo debería pedir primero el inventario de datos cubiertos: reglas WAF, código y estado de Workers, logs, métricas, trazas, metadatos y copias de respaldo. Después, confirmar si la selección regional afecta a servicios existentes, al histórico y a nuevas escrituras por igual, y qué pasa al cambiar de ubicación. Son preguntas abiertas, no funciones confirmadas de la beta.
También hace falta una matriz de compatibilidad por producto y configuración, con regiones disponibles, dependencias que siguen siendo globales y comportamiento ante fallos. En un entorno productivo, la prueba debería observar latencia, continuidad de políticas, exportación de registros y recuperación; si esos datos no se pueden sacar o consultar como antes, la residencia habrá cambiado también el procedimiento de respuesta. La primera validación debería ser un servicio acotado, con criterios de reversión y responsables claros.
La noticia, por tanto, es una promesa concreta de control más sencillo con alcance aún incompleto. Cloudflare identifica qué quiere ubicar y sobre qué tecnologías reconstruye dos piezas de la plataforma, pero no ha publicado todavía los límites necesarios para decidir qué cargas pueden migrar con seguridad. Para los equipos que ya trabajan con controles de Data Localization Suite, la comparación útil llegará cuando la beta publique detalle de regiones, cobertura, compatibilidad y operación; hasta entonces, el anuncio sirve para abrir preguntas, no para cerrar un diseño.
Diccionario de la Crew
Residencia de datos — Control sobre la ubicación geográfica en la que se procesan o almacenan determinados datos.
Plano de control — Componentes que administran configuración y operación de un servicio, separados del tráfico que procesa.
Durable Objects — Primitivas de Cloudflare para ejecutar lógica con estado persistente y coordinación.
WAF — Firewall de aplicaciones web; aplica reglas para filtrar solicitudes HTTP.
