Summary

  • Cloudflare divulga una amplia huella de ciudades latinoamericanas y 500 Tbps de interconexión externa global, pero no publica el número de servidores, la energía contratada, el margen de puertos en vivo ni las rutas físicamente diversas disponibles en cada sitio latinoamericano.
  • Los registros públicos establecen una empresa costarricense, recursos de dirección costarricenses y un despliegue en San José asociado a NIC.CR, pero no establecen que la empresa costarricense sea propietaria o contrate cada rack, circuito o relación comercial regional que lleve el nombre de Cloudflare.
  • Anycast puede mover la accesibilidad de una ubicación fallida, pero la recuperación exitosa sigue dependiendo de la capacidad de cómputo y red de repuesto, energía independiente de las instalaciones, fibra metropolitana superviviente, interconexiones funcionales y personal autorizado para restaurar el equipo afectado.

El interruptor de transferencia es donde el mapa se detiene

Considere una instalación neutral en el área metropolitana de São Paulo durante una transferencia eléctrica programada. Se retira de servicio la alimentación de la red eléctrica, la alimentación ininterrumpida soporta la carga durante el intervalo entre alimentaciones, y se espera que los generadores o una segunda ruta de la red tomen el relevo. Un técnico observa la distribución de energía de los racks y las interconexiones ópticas mientras los ingenieros de red supervisan las rutas. Este es un caso de estrés, no un informe de un accidente específico de Cloudflare. Es útil porque elimina la facilidad visual de un mapa de borde global.

En el momento de la transferencia, las preguntas relevantes son concretas: qué armarios permanecieron energizados, qué enrutadores mantuvieron la luz, qué pares permanecieron alcanzables, y cuánto trabajo se pudo aceptar en otro lugar.

Los propios avisos operativos de Cloudflare revelan la respuesta de red prevista. Durante el trabajo programado en su ubicación GRU el 3 de julio de 2026, la empresa advirtió que el tráfico podría ser redirigido, los usuarios finales podrían experimentar un ligero aumento de latencia, y las interfaces de interconexión privadas o de clientes en ese centro de datos podrían no estar disponibles temporalmente. Posteriormente, el aviso marcó el trabajo como completado. Esa secuencia es visible en elregistro de mantenimiento de GRU. Es una evidencia limitada: muestra una ventana de mantenimiento anunciada y el comportamiento esperado de las interfaces, no la identidad de un edificio, el motivo del trabajo, un cambio de tráfico medido ni la cantidad de capacidad de reserva utilizada en otro lugar.

Lapágina de estado públicomás amplia separa las ubicaciones latinoamericanas como San José y São Paulo en componentes nombrados y asigna a cada uno una condición actual. Esa es una valiosa visibilidad operativa, pero un componente verde es una instantánea. No revela si el componente representa una sala o varias, si dos salas comparten una subestación, o si un vecino nominalmente disponible podría aceptar una carga regional repentina. Tampoco identifica qué empresa legal compró la energía, alquiló el rack o firmó la orden de interconexión.

La intuición normal es que anycast resuelve el problema de ubicación. Laexplicación de anycastde Cloudflare dice que la misma dirección puede servirse desde múltiples ubicaciones y que desconectar un centro de datos puede hacer que el tráfico fluya a uno cercano. Eso describe la accesibilidad. No fabrica vatios, ciclos de servidor ni puertos no congestionados en la ubicación receptora. Si São Paulo retira rutas, los usuarios pueden terminar en Río de Janeiro, Curitiba, Porto Alegre, Buenos Aires, Santiago, Bogotá, Miami u otra ubicación disponible dependiendo de las rutas que seleccionen sus proveedores de acceso. Cada alternativa añade sus propias condiciones de instalación, operador y capacidad.

Por lo tanto, la transferencia de energía pone a prueba dos sistemas a la vez. El primero es local: alimentación de la red, aparamenta, baterías, generadores, refrigeración, distribución de racks, enrutadores e interconexiones deben permanecer dentro de las tolerancias. El segundo es regional: los cambios de ruta deben propagarse limpia y los destinos que ganan tráfico deben tener margen utilizable. Un mapa de ciudades no representa ninguno de los dos sistemas a esa resolución. Muestra geografía de servicio, no las dependencias eléctricas y comerciales que determinan si la conmutación por error es fluida.

La brecha importa porque los clientes experimentan el resultado como un solo servicio incluso cuando la responsabilidad física está dividida entre Cloudflare, operadores de instalaciones, transportistas, intercambios y contratistas en el sitio.

Un punto de ciudad no es un dominio de fallo

Lapágina de red actualde Cloudflare presenta una gran huella latinoamericana, con docenas de ciudades en Brasil y ubicaciones desde San José hasta Bogotá, Lima, Santiago, Buenos Aires y más allá. La página también dice que cada servicio se ejecuta en cada centro de datos. Esas afirmaciones establecen la amplitud prevista del borde y el diseño de servicios comunes. No establecen que cada ciudad contenga el mismo número o generación de servidores, el mismo número de proveedores ascendentes, la misma capacidad para tomar tráfico de otra ciudad, o la misma protección contra un evento energético local.

Cloudflare mismo ha explicado por qué la ciudad es una unidad demasiado gruesa. En un relato de 2019 sobre laescalabilidad de su red global, la empresa dijo que una ciudad podía contener hasta cinco despliegues distintos. También describió la planificación de capacidad por dirección, no solo por ciudad, y describió el uso de vendedores y manos remotas en el sitio para instalar servidores y cablearlos. La divulgación fue histórica y global; no es un censo actual de América Latina. Su valor analítico continuo es la distinción que hace: una sola etiqueta metropolitana puede ocultar varias direcciones físicas, mientras que un despliegue en una ciudad pequeña puede estar incrustado dentro de un proveedor de servicios de Internet en lugar de un gran campus neutral.

La divulgación anual más reciente de la empresa proporciona la otra mitad del límite. ElFormulario 10-K de 2025de Cloudflare dice que su red estaba alojada en instalaciones de coubicación y de socios proveedores de servicios de Internet en más de 330 ciudades y más de 125 países al final de 2025. Dice que Cloudflare tiene acceso electrónico y, en menor medida, físico a los equipos alojados por terceros, pero no controla la operación de esas instalaciones. El mismo informe identifica la pérdida de energía, las decisiones del operador, el cierre de instalaciones, el error humano y los límites de ancho de banda como riesgos. Esos no son adornos teóricos alrededor de un punto; son el límite operativo del punto.

La amplitud también se presenta en diferentes formas físicas. Un relato de expansión de 2023 dijo que Cloudflare había llegado a más de 300 ciudades y describió un nuevo sitio en Campos dos Goytacazes, Brasil, interconectado con un proveedor regional que atiende a más de 100 proveedores locales de servicios de Internet. La empresa informó que las mediciones de latencia mejoraron materialmente después de la apertura del sitio. Eserelato de expansión de ciudadesrespalda la presencia de un borde liderado por socios cerca de los usuarios. No revela la energía del rack, la cantidad de servidores, la utilización del puerto ni la ruta que transportaría la carga si el sitio del socio falla.

Un dominio de fallo útil debe dibujarse en torno a las dependencias compartidas. Dos despliegues en diferentes direcciones pueden depender de la misma subestación eléctrica, conducto de operador, tejido de intercambio, salida de larga distancia o proveedor de soporte local. Por el contrario, dos armarios en un gran campus pueden tener trenes de energía significativamente separados y entradas de fibra diversas. Las listas de ciudades públicas no resuelven ninguno de los dos casos.

Incluso una instalación nombrada no prueba que dos circuitos de un cliente particular terminen en dispositivos separados o que exista capacidad de reserva detrás de cada uno.

Esta es la razón por la que un recuento de ciudades no es un recuento de opciones de recuperación independientes. Es una medida de alcance geográfico. Para convertirlo en una afirmación de resiliencia, un lector necesitaría el número de sitios activos por área metropolitana, su correlación de energía y fibra, las cargas de trabajo habilitadas en cada uno, la utilización normal y de emergencia de cada puerto, y la política para retirar o restaurar rutas. Ninguno de esos elementos puede inferirse solo porque São Paulo, San José y Bogotá aparecen en el mismo mapa.

La empresa costarricense es un límite, no una etiqueta de activos regional

CloudFlare Latin America S.R.L es una presencia legal costarricense real, no un apodo geográfico. La gaceta oficial de Costa Rica registró una acción corporativa de "Cloudflare Latin America S.R.L." en enero de 2026 y le asignó el número de persona jurídica 3-102-651761. La noticia se refería a su dirección electrónica oficial y representación residente, no a activos de red, pero laentrada de la gacetaes evidencia pública reciente de que la empresa existe dentro del sistema corporativo de Costa Rica.

Los registros de números de Internet proporcionan un vínculo separado. Elregistro público de LACNICpara 190.93.240.0/20 nombra a CloudFlare Latin America S.R.L como el registrante y proporciona una dirección en el área de San José, mientras que los contactos operativos se refieren a las operaciones de red de Cloudflare en San Francisco. Esto respalda una relación entre la empresa costarricense y los recursos de dirección utilizados bajo la operación más amplia de Cloudflare. No prueba que cada dirección se sirva solo en Costa Rica. Anycast permite deliberadamente que las mismas direcciones de servicio se anuncien desde múltiples lugares, y un registro de dirección no es un inventario de racks ni un título de propiedad.

La superficie contractual con clientes apunta en una dirección diferente. ElAcuerdo de Suscripción Empresarialestándar de Cloudflare establece que el acuerdo público es entre el cliente y Cloudflare, Inc., una empresa de Delaware. También permite el uso de afiliados y formularios de pedido de afiliados separados. La conclusión correcta es limitada: los términos públicos estándar no asignan suscripciones empresariales ordinarias a la empresa costarricense. No descartan un formulario de pedido diferente, un acuerdo fiscal local, un arrendamiento de propiedad, un contrato laboral, un acuerdo de operador o una transacción de afiliado. Esos documentos no son públicos en el material revisado aquí.

La misma precaución se aplica en toda América Latina. Un rack con la marca Cloudflare en Brasil podría ser propiedad de Cloudflare, Inc., otro afiliado, un socio de servicio o una contraparte de alojamiento bajo términos no visibles para externos. La empresa costarricense puede tener recursos numéricos particulares u obligaciones locales sin ser la parte contratante de una sala en São Paulo. Por el contrario, la ausencia de su nombre en una página de instalación no mostraría que no tiene ningún rol financiero u operativo.

Los registros públicos de instalaciones y enrutamiento normalmente identifican la red o la marca, no la asignación interna de derechos entre afiliados.

Este límite importa durante un fallo. La parte que puede pedir a un operador que pruebe los niveles de luz, autorizar una visita de manos remotas, aprobar un gasto de emergencia o hacer cumplir un compromiso de servicio puede no ser la misma parte nombrada en un registro IP público. Las demandas regulatorias también pueden recaer sobre la empresa local incluso cuando las decisiones operativas se toman en otro lugar. Sin contratos, actas del consejo o divulgaciones explícitas de afiliados, atribuir el control regional a CloudFlare Latin America S.R.L iría más allá de la evidencia.

Por lo tanto, la descripción más defendible es por capas. Cloudflare, Inc. informa la red global consolidada y sus dependencias de instalaciones de terceros. AS13335 es la identidad de enrutamiento global. CloudFlare Latin America S.R.L es una empresa costarricense asociada con recursos LACNIC y un registro legal costarricense actual. NIC.CR fue nombrado como el socio para el primer despliegue en San José. Estas capas claramente se relacionan con un solo servicio, pero no son intercambiables.

Una historia de borde regional que las colapse en "la empresa costarricense opera América Latina" convertiría asociación en propiedad y propiedad en control sin prueba pública.

San José prueba presencia, no control

Cloudflare anunció su primer despliegue en Costa Rica en junio de 2021. Surelato de expansión en San Josédijo que la ubicación se estableció con NIC.CR, administrado por la Academia Nacional de Ciencias. Esta es una evidencia directa de la empresa de una presencia desplegada y un socio local nombrado en ese momento. El mapa de red actual y el componente de estado indican que San José sigue representado en la huella activa. Ninguna de las divulgaciones nombra el edificio, el número de servidores, la asignación de energía, la lista de operadores, el stock de piezas de repuesto ni el propietario contractual del equipo.

NIC Costa Rica describe CRIX como un intercambio de Internet neutral que permite a las redes locales intercambiar tráfico en un punto común dentro del país en lugar de depender de enlaces internacionales. Esadescripción de infraestructura de NIC.CRestablece por qué un borde en San José puede importar: el peering local puede mantener parte del tráfico costarricense local, reducir la dependencia del tránsito internacional para ese intercambio, y reducir la distancia al contenido en caché o procesado. No establece el tamaño actual del puerto de Cloudflare ni si todos los proveedores de acceso costarricenses llegan a Cloudflare a través de CRIX.

Elregistro de red en PeeringDBactual autoinformado de Cloudflare identifica AS13335 como una red anycast global y enumera sus relaciones de peering público e instalaciones. El registro incluye una conexión CRIX activa e informa un puerto de intercambio de 200 Gbps para esa entrada en el momento examinado. PeeringDB es una evidencia operativa importante porque Cloudflare dice que utiliza el servicio para el aprovisionamiento de peering. Sin embargo, sus valores siguen siendo autoinformados y mutables. La velocidad de puerto listada es la tasa nominal de la interfaz, no el tráfico observado, el rendimiento comprometido, la capacidad disponible ni la prueba de un segundo puerto físicamente diverso.

Esto produce una imagen precisa pero modesta de San José. Hay una presencia en la ciudad anunciada con NIC.CR, un componente de estado actual, una conexión de intercambio público y recursos de dirección registrados a la empresa costarricense. No hay dirección de instalación pública en esas fuentes. No hay recuento revelado de despliegues independientes dentro del área metropolitana. No hay dibujo unifilar de energía, ninguna cifra de autonomía de generador vinculada a los armarios de Cloudflare, ni declaración de diversidad de rutas que muestre entradas de fibra separadas o rutas ascendentes.

La distinción entre localidad y control es especialmente importante aquí. CRIX puede localizar el tráfico entre redes conectadas, pero el propio tejido de intercambio se convierte en un elemento de la ruta del servicio. Una interconexión del enrutador de Cloudflare al intercambio puede fallar mientras los servidores permanecen alimentados. El borde también puede permanecer accesible a través de tránsito mientras una sesión de peering local está caída, a costa de una ruta más larga. Una instalación puede permanecer operativa mientras un operador sufre un corte metropolitano.

Por lo tanto, un componente de ciudad puede degradarse de varias maneras que un punto binario de ciudad no puede describir.

San José tampoco puede representar a la red regional. Incluso si su tráfico local es lo suficientemente pequeño para un puerto de intercambio y un despliegue, eso no dice nada sobre la capacidad de absorber tráfico de Guatemala, Panamá, el norte de Sudamérica o Brasil. La ausencia de una serie publicada de servidores y utilización impide una comparación entre hardware instalado y margen de emergencia.

La interfaz de intercambio visible de 200 Gbps no debe añadirse a las cifras de capacidad global como si fuera una reserva utilizable independientemente; es una interfaz en un conjunto más grande de conexiones de tránsito, privadas y públicas, y su demanda en vivo no se divulga.

Lo que San José prueba es significativo: Cloudflare acercó el servicio a los usuarios costarricenses y estableció una relación de interconexión local. Lo que deja sin respuesta es la pregunta del título de este artículo. Cuando una gran área metropolitana latinoamericana pierde energía o retira rutas, el registro público no muestra cuánto tráfico podría tomar San José, qué aplicaciones podría procesar bajo configuraciones de localidad del cliente, ni qué empresa dirigiría la recuperación física.

São Paulo son varias salas, puertos y dependencias comerciales

São Paulo es la ilustración pública más sólida de por qué una etiqueta de ciudad puede ocultar varias superficies operativas distintas. El registro de PeeringDB de Cloudflare enumera la red en Equinix SP2 y SP4 en Barueri, en Ascenty SPO02 y SPO03 en Osasco, y en Elea SPO1 en São Paulo. Esto no es necesariamente un inventario en vivo completo, y un listado de instalación no revela cuánto equipo está activo allí. Muestra que el área metropolitana no puede tratarse responsablemente como una sola sala.

Lalista de ubicaciones de interconexión de clientesde Cloudflare de mayo de 2026 hace que la multiplicidad sea aún más explícita. Nombra varias instalaciones en São Paulo para la interconexión de clientes, incluyendo Equinix SP2 y SP4, Ascenty SPO02 y SPO03, y Elea SPO1. El documento es una lista de ubicaciones de servicio, no un mapa del borde interno o la red troncal de la empresa. Muestra dónde puede terminar una conexión de cliente; no muestra que cada sitio listado tenga cómputo de borde idéntico, que las conexiones en dos edificios utilicen rutas de operador separadas, o que cada ubicación pueda sustituir a cualquier otra.

Las divulgaciones de instalaciones añaden contexto físico sin cerrar la brecha específica de Cloudflare. Equinix dice queSP4tiene redundancia UPS y generador N+1, al menos 30 horas de autonomía del generador a plena carga, refrigeración N+1 y servicios de manos inteligentes. Esas son especificaciones del operador para el edificio. No revelan qué tren de energía alimenta a Cloudflare, la carga de sus armarios, el estado de mantenimiento de un componente particular, la cantidad de combustible presente en un día dado o si un circuito de Cloudflare cruza un punto compartido antes de entrar a la instalación.

El aviso de mantenimiento de GRU proporciona una pista de comportamiento en vivo. Trató la ubicación de São Paulo como un componente desde el cual el tráfico y las interfaces privadas podrían conmutar por error. No identificó cuál de los varios edificios estaba involucrado. "GRU" puede representar una agrupación operativa más grande que una instalación, o el aviso puede haber abstraído deliberadamente el detalle de la instalación. En cualquier caso, la etiqueta del componente no debe leerse como una dirección física.

La diversidad metropolitana solo ayuda cuando las dependencias son genuinamente independientes. SP2 y SP4 pueden ser instalaciones separadas, pero los caminos decisivos incluyen el suministro eléctrico, los trenes de generador y UPS, las salas de reuniones, los conductos, los anillos de operadores, los tejidos de intercambio y las salidas de red troncal que conectan el área metropolitana con otras ciudades. Dos interconexiones de clientes ordenadas en dos edificios aún pueden converger en una ruta de operador. Dos despliegues de Cloudflare aún pueden compartir autoridad de cambio o una dependencia de control regional.

Ninguna de las fuentes públicas mapea estas correlaciones.

La concentración comercial añade otra capa. El 10-K dice que un número significativo de acuerdos importantes de coubicación son con una empresa no nombrada. Equinix es visible en la lista pública de instalaciones de São Paulo, pero el informe no identifica al proveedor concentrado, y sería no respaldado asumir el nombre. El punto relevante es que la distribución física entre ciudades o salas no elimina automáticamente la concentración contractual. Una disputa con un vendedor, un fallo de soporte o un cambio de precios adverso puede afectar las decisiones de expansión y restauración incluso cuando la red sigue siendo técnicamente enrutable.

Por lo tanto, São Paulo se describe mejor como un área metropolitana con varias opciones de instalaciones e interconexión públicamente visibles, no como un conjunto cuantificado de capacidad intercambiable. La evidencia respalda más que un punto pero menos que un diagrama de resiliencia. Muestra salas y servicios que podrían participar en la diversidad; no prueba la independencia, asignación o capacidad de emergencia requerida para que lo hagan.

El peering localiza el tráfico pero puede concentrar el área metropolitana

Lapolítica de peeringde Cloudflare de diciembre de 2025 dice que AS13335 abarca más de 335 ciudades, pide a los pares que establezcan sesiones en todas las ubicaciones mutuas y admite interconexiones privadas en múltiplos de 100 Gbps para redes por encima de un umbral de tráfico. También recomienda usar todas las direcciones disponibles cuando haya más de una presente en un intercambio. Estas prácticas pueden mejorar la diversidad de rutas y facilitar el movimiento de tráfico entre puertos. Siguen siendo condiciones de política, no prueba de que un par latinoamericano determinado haya ordenado interconexiones diversas o haya mantenido suficiente capacidad no utilizada.

El despliegue histórico muestra cuán diferentes pueden ser los acuerdos locales. En Medellín, Cloudflare dijo que su lanzamiento en 2014 dependía de Internexa y que el servicio local se transportaba sobre la red terrestre del socio. Elanuncio de Medellíndescribió una importante ventaja de alcance, pero también hace visible la dependencia: la localidad del tráfico estaba conectada a la red troncal de un socio. La red actual puede ser más amplia; el relato antiguo no puede tratarse como una topología actual.

En Quito, la empresa dijo que su sitio de 2017 fue posible gracias al intercambio NAP.EC y que los pares locales adicionales podían desviar tráfico que antes se servía desde Miami. Elrelato de Quitodemuestra el valor de un intercambio local y la dependencia previa de un centro en el extranjero. Nuevamente, no muestra los racks, puertos o destinos de respaldo actuales. También ilustra que "local" es relacional: un despliegue es local solo para las redes que pueden alcanzarlo a través de rutas aceptables.

Bogotá comenzó con otro acuerdo físico revelado. Elrelato de Bogotá de 2018de Cloudflare dijo que el despliegue estaba en una instalación Tier III en la zona franca de la ciudad. Los registros públicos actuales listan a Cloudflare en Equinix BG2, pero la descripción histórica no nombra ese sitio, por lo que los dos registros no pueden unirse en un historial de instalaciones ininterrumpido sin más evidencia. Lo que se puede decir es que Bogotá ha tenido una presencia física revelada y ahora tiene un listado de instalación actual.

La ruta de larga distancia entre estas áreas metropolitanas es igualmente importante. Cloudflare dice que su red troncal utiliza fibra oscura propia o servicios de longitud de onda densa arrendados dentro y entre ciudades, comprados a operadores asociados globales. Ladescripción de la red troncalde la empresa explícitamente llama a su mapa ilustrado una simplificación que no muestra cada ruta. Esa precaución debe regir cualquier lectura de líneas entre puntos latinoamericanos. Una línea dibujada no identifica un operador, estación de aterrizaje, conducto, longitud de onda, ruta de protección ni ancho de banda disponible.

El peering puede reducir el costo de tránsito y evitar enviar tráfico local a Miami, pero también puede concentrar el tráfico en las instalaciones donde el intercambio está disponible. Si el intercambio de Internet local de un país y un despliegue importante del borde comparten un edificio o conducto metropolitano, el rendimiento local mejora durante la operación normal mientras que el riesgo físico correlacionado puede persistir. Múltiples sesiones bilaterales en un solo tejido de conmutación no protegen contra un evento en todo el tejido o en todo el edificio. Múltiples operadores en una sala de reuniones no prueban entradas diversas.

La evidencia deseada es específica de la ruta. Para cada área metropolitana importante, una evaluación de resiliencia identificaría los puertos de intercambio, las interconexiones privadas y los enlaces de tránsito; si sus interconexiones aterrizan en enrutadores separados; si los operadores salen a través de conductos separados; y qué sitios regionales pueden anunciar las rutas afectadas después de la retirada. Los registros públicos revelan piezas de esa imagen. No revelan la cadena completa, por lo que las afirmaciones de conmutación por error regional sin problemas siguen siendo condicionales.

Anycast redirige la accesibilidad, no la electricidad ni la capacidad de repuesto

Anycast es poderoso porque separa una dirección de servicio de un destino físico. Cuando una ubicación deja de anunciar una ruta, las redes ascendentes pueden seleccionar otro anuncio. Pero el destino seleccionado es la mejor ruta según la política de enrutamiento, no necesariamente la ciudad más cercana geográficamente ni la ubicación con el grupo de servidores no utilizados más grande. Laguía de enrutamiento geográficode Cloudflare reconoce que las solicitudes pueden no alcanzar el centro de datos físicamente más cercano y dice que la fiabilidad puede tener prioridad sobre la localidad.

Hay tres pasos de recuperación distintos. Primero, la ubicación afectada debe eliminarse de la ruta entrante, ya sea mediante retirada de ruta, ingeniería de tráfico o cambio ascendente. Segundo, Internet debe converger en anuncios alternativos. Tercero, las ubicaciones receptoras deben aceptar las conexiones añadidas sin agotar los recursos de cómputo, memoria, caché, enrutador, interconexión o tránsito. Los dos primeros son acciones de enrutamiento. El tercero es una condición de capacidad.

Dentro de una ubicación superviviente, Cloudflare utiliza otra capa de distribución. Su relato deUnimogexplica cómo las conexiones se distribuyen entre servidores, cómo se eliminan los servidores no saludables y por qué la carga debe ajustarse para máquinas de diferente rendimiento. Esto puede sortear un servidor fallido o un host sobrecargado dentro de un centro de datos. No puede ayudar si toda la sala pierde energía, el enrutador de borde se oscurece o todas las rutas externas se cortan. En ese caso, la capa anycast regional debe llevar la recuperación.

Los clientes de interconexión privada tienen una dependencia adicional. Laguía operativa de interconexiónactual de Cloudflare dice que un despliegue de cliente debe tolerar la pérdida no planificada de cualquier circuito individual y que la conmutación por error entre circuitos redundantes debe ser automática. También señala que el mantenimiento no se coordina entre diferentes ubicaciones. Esto asigna parte de la resiliencia al diseño del cliente: un cliente con una interconexión física en GRU puede perder esa ruta directa incluso si el borde público de Cloudflare sigue disponible en otro lugar.

La diferencia importa para los servicios afectados. Una conexión a un sitio web público a menudo puede seguir otra ruta anycast sin acción del cliente, aunque la latencia y el comportamiento de caché pueden cambiar. Una interconexión de red privada puede requerir un segundo circuito, una política de ruta adecuada y suficiente capacidad en su terminación alternativa. Una conexión de larga duración puede romperse incluso cuando una nueva conexión tiene éxito en otro lugar. Una aplicación regionalizada puede estar restringida a un subconjunto de ubicaciones.

La ruta de origen de un cliente también puede permanecer afectada después de que el borde se mueva, particularmente si el origen está conectado a través del mismo área metropolitana.

La recuperación anycast es, por lo tanto, una transferencia de demanda, no la desaparición de la demanda. Si GRU procesa normalmente un gran volumen y se retira, alguna combinación de otros sitios debe procesarlo. El registro público no revela la carga normal de GRU, la proporción que puede servirse desde caché, la combinación de productos, la distribución de destinos ni la utilización de los sitios receptores. La frase "el tráfico podría ser redirigido" es precisa pero incompleta; describe el movimiento sin cuantificar el aterrizaje.

La afirmación creíble de resiliencia es condicional: la accesibilidad puede moverse si las rutas se retiran limpiamente, y el servicio puede continuar si las rutas y ubicaciones alternativas tienen los recursos necesarios y tienen permitido manejar el trabajo. La electricidad sigue siendo local. El margen de repuesto sigue siendo finito. Una ruta de Internet puede apuntar alrededor de un edificio oscuro, pero no puede hacer que el edificio alternativo esté listo.

La capacidad instalada no es capacidad de conmutación por error utilizable

Cloudflare anunció en abril de 2026 que había superado los 500 Tbps de interconexión externa. De manera crucial, la empresa definió el número. Surelato de 500 Tbpsdice que la cifra es la suma de puertos aprovisionados frente a proveedores de tránsito, pares privados, intercambios de Internet e interconexiones de clientes en más de 330 ciudades. También dice que el número no es tráfico pico y que la diferencia respalda la absorción de denegación de servicio.

Esa es una medida de escala global significativa. No es una tabla de capacidad latinoamericana. Sumar tasas de puertos cuenta las interfaces instaladas dondequiera que estén, aunque algunos puertos no pueden sustituir a otros. Una interconexión de cliente en Bogotá no puede transportar automáticamente tráfico de caché público desplazado de São Paulo. Un puerto conectado a un par llega al tráfico de ese par, no a todos los usuarios. Dos enlaces de 100 Gbps en el mismo enrutador o ruta de fibra son menos independientes que dos enlaces en instalaciones separadas.

La capacidad del puerto tampoco dice nada directamente sobre los ciclos del servidor, el almacenamiento, el calor de caché o la energía eléctrica detrás de los enrutadores.

La política de peering de Cloudflare refuerza el problema de la unidad. Admite conexiones privadas Nx100G y establece umbrales de tráfico para solicitarlas, pero no publica la utilización actual. PeeringDB marca el nivel de tráfico general de la red como no revelado. La evidencia pública resultante puede mostrar que existen interfaces grandes y nombrar algunas ubicaciones; no puede mostrar cuántos gigabits siguen siendo utilizables de forma segura durante un evento regional.

La divulgación financiera es igualmente agregada. El 10-K reporta $179.357 millones en compromisos no cancelables de ancho de banda y otras coubicaciones al final de 2025, distribuidos en períodos futuros. Eso prueba que la empresa compra capacidad de red y espacio a largo plazo a escala significativa. No puede asignarse a América Latina a partir del informe, y el gasto no es rendimiento. Un contrato puede reservar espacio que aún no está en servicio, cubrir un plazo fijo en lugar de una reserva de emergencia, o incluir productos cuya capacidad no es intercambiable.

Las cifras de instalaciones deben mantenerse en su propia categoría. La disposición de energía N+1 de SP4 y la autonomía declarada del generador describen el edificio. Equinix dice queBogotá BG2tiene redundancia UPS y generador N+1, 72 horas de autonomía del generador y soporte 24 horas. Laespecificación de Lima LIM1de Cirion describe energía 2N, refrigeración N+1 y más de 2.200 metros cuadrados de coubicación en piso elevado. Los registros públicos actuales asocian a Cloudflare con estas instalaciones o ubicaciones de interconexión de clientes, pero las calificaciones de las instalaciones no son asignaciones de Cloudflare. Dicen lo que el operador diseñó, no cuánta energía o espacio de piso compró Cloudflare.

La capacidad de conmutación por error utilizable es más estrecha que cada una de estas medidas instaladas. Es la parte de los recursos alternativos de cómputo, energía y red que están saludables, alcanzables, contractualmente disponibles, compatibles con el servicio afectado y no consumidos en el momento del fallo. Debe permitir el crecimiento del tráfico durante la convergencia, las fallas de caché, la carga de ataques y la posibilidad de que una segunda dependencia esté degradada. Por lo tanto, una reserva prudente no es simplemente "tasa de puerto no utilizada".

Ninguna fuente pública revisada aquí proporciona ese número por área metropolitana latinoamericana. Esa ausencia impide una afirmación cuantitativa de que el tráfico de São Paulo podría ser absorbido completamente dentro de la región. La cifra global de 500 Tbps hace que dicha absorción sea plausible para muchos eventos ordinarios, pero la plausibilidad no es medición. Hasta que se publiquen la utilización por sitio, la elegibilidad del servicio y los límites de fallo correlacionados, la conclusión correcta es que la escala instalada es sólida mientras que el margen regional utilizable permanece no revelado.

La recuperación pasa por manos remotas, operadores y autoridad de cambios

Cuando una sala pierde energía, la retirada de ruta es solo el comienzo. Alguien debe determinar si las alimentaciones de la red, la aparamenta, el UPS, los generadores, la refrigeración y la distribución de racks son estables. Alguien debe inspeccionar la energía del enrutador y del servidor, verificar la luz óptica, reemplazar componentes fallidos, restaurar circuitos y secuenciar el equipo de vuelta al servicio. En una instalación de terceros, esas tareas cruzan fronteras organizativas.

Elrelato de fallo de energía en Oregónde Cloudflare de noviembre de 2023 está fuera de América Latina y se refería a servicios centrales en lugar de un sitio de borde latinoamericano. Sigue siendo un ejemplo valioso revelado de la cadena de recuperación física. La instalación perdió energía de la red y del generador después de una falla a tierra; las baterías se agotaron; el acceso y la dotación de personal complicaron el reinicio del generador; Cloudflare se enteró del problema cuando los enrutadores se desconectaron; luego, los interruptores automáticos tuvieron que ser reemplazados; y los servidores se reactivaron en una secuencia controlada. La empresa separó claramente los hechos confirmados de la especulación informada cuando el operador de la instalación no había proporcionado respuestas.

La misma instalación falló nuevamente en marzo de 2024. Elsegundo relato de evento de energíade Cloudflare dijo que los cambios anteriores mejoraron la respuesta y redujeron el impacto. La comparación muestra que la calidad de la recuperación depende de la preparación, las dependencias probadas y los criterios de activación claros, no solo del equipo redundante en una hoja de especificaciones de la instalación.

Para los sitios de borde latinoamericanos, el 10-K dice que contratistas externos pueden instalar y mantener hardware en el extranjero y que Cloudflare no controla las operaciones de instalaciones de terceros. La información pública de soporte de las instalaciones ayuda a identificar una dependencia humana. Ladisponibilidad de soporte de coubicaciónde Equinix enumera cobertura operativa en el sitio las 24 horas para Bogotá BG2, mientras que la cobertura difiere en otros sitios. Eso no revela el derecho de servicio de Cloudflare, el objetivo de respuesta, el inventario de repuestos ni si un técnico está autorizado a tocar un dispositivo en particular. Muestra por qué la dotación de personal pertenece a la evaluación física.

La recuperación del operador tiene su propia cadena. Una falla de interconexión requiere coordinación entre Cloudflare, la instalación y el par o el operador. La luz óptica baja puede resultar de un conector sucio, fibra dañada, óptica fallida o un problema de ruta más larga. Restaurar un lado sin confirmar el otro puede dejar la sesión caída. Para una interconexión de cliente, el cliente también debe tener conmutación por error automática y suficiente capacidad alternativa. Para una falla de intercambio, las sesiones pueden necesitar moverse a rutas privadas o de tránsito.

La autoridad de cambios puede convertirse en la dependencia más lenta. La persona que ve un problema de ruta puede no estar autorizada para aprobar el acceso a la instalación. La instalación local puede requerir una carta de autorización antes de mover una interconexión. Un contratista puede necesitar un número de despacho. Un operador puede insistir en pruebas en un punto de demarcación antes de escalar. Un afiliado puede tener el contrato mientras un equipo de operaciones global dirige la reparación. Ninguno de estos pasos es visible en un color de estado.

La ruta de restauración segura también es más lenta que simplemente aplicar energía. Una instalación que regresa después de un evento inestable puede necesitar que los circuitos se energicen en etapas para evitar la sobrecarga de irrupción. Los dispositivos de red deben verificarse antes de que los servidores atraigan tráfico. La salud y la capacidad deben confirmarse antes de que las rutas regresen; de lo contrario, la demanda puede oscilar entre sitios o sobrecargar una sala parcialmente restaurada. El comportamiento de caché y las conexiones de larga duración pueden tomar tiempo adicional para normalizarse.

La evidencia pública respalda la capacidad de Cloudflare para aprender de eventos de energía severos y operar una respuesta global. No revela manuales de sitio latinoamericanos, repuestos locales, objetivos de tiempo de recuperación ni mapas de autoridad. Esas omisiones no prueban debilidad. Significan que la parte humana y contractual de la resiliencia no puede verificarse independientemente a partir de la huella de ciudades.

Quién siente el fallo primero

La primera población afectada depende de qué capa falla. Si un servidor falla pero el enrutador y la sala permanecen saludables, la distribución de carga local puede eliminarlo con poco efecto visible. Si un puerto de intercambio falla, los usuarios de pares que dependían de ese puerto pueden tomar rutas más largas mientras los usuarios que llegan a través de otros operadores permanecen locales. Si todo un sitio se retira, muchas redes de acceso pueden cambiar juntas. Si un área metropolitana pierde varias rutas correlacionadas, una región mucho más grande puede enviarse a ciudades más distantes.

Los usuarios finales notan latencia, reinicios de conexión, menor rendimiento o errores. El patrón no será uniforme en todo un país. Un proveedor de servicios de Internet con una sesión directa en San José puede seguir una ruta diferente de uno que compra tránsito ascendente. Las redes móviles y fijas pueden tomar diferentes decisiones de enrutamiento. Un acierto de caché puede completarse localmente mientras que una solicitud no almacenada en caché aún depende de un origen en el área metropolitana fallida. Por lo tanto, el estado de "San José" o "São Paulo" no se traduce en una experiencia nacional única.

Los clientes de Cloudflare que utilizan interconexiones privadas enfrentan un límite más explícito. El aviso de GRU les dijo que esperaran que las interfaces no estuvieran disponibles y que organizaran la conmutación por error en otro lugar. Si su circuito alternativo está en el mismo área metropolitana o utiliza la misma ruta de operador, la redundancia nominal puede no ayudar. Si termina en otra ciudad, debe dimensionarse para la demanda transferida y su enrutamiento debe activarse sin demora manual. La continuidad del borde público no restaura por sí misma una ruta privada.

Las elecciones de localidad de datos reducen el conjunto receptor. Ladescripción de Servicios Regionalesde Cloudflare dice que las conexiones cifradas pueden aceptarse globalmente mientras que el descifrado HTTPS y el procesamiento a nivel de aplicación ocurren solo en la región seleccionada. Esto significa que una ubicación fuera del conjunto seleccionado puede absorber la conexión de red pero no puede necesariamente realizar todo el trabajo. La capacidad de conmutación por error debe contarse dentro de la región de procesamiento permitida, no en cada punto del mapa mundial.

Latabla de soporte de regionesactual lista a Brasil como una región de Servicios Regionales administrada. No lista una sola región administrada que cubra toda América Latina, aunque pueden estar disponibles configuraciones personalizadas para algunas opciones. Por lo tanto, un compromiso de localidad brasileña puede hacer que el número y la distribución de sitios brasileños saludables sean especialmente importantes. La capacidad en Miami, Bogotá o San José puede ser físicamente alcanzable pero no elegible para descifrado bajo esa configuración. La configuración del producto de cada cliente importa.

Los servicios del sector público, bancos, minoristas, proveedores de salud, medios, servicios de software y sitios web pequeños pueden estar todos detrás del mismo borde, pero sus costos de fallo difieren. Un breve retraso en una página estática no es lo mismo que la pérdida de una conexión de pago, una ruta de acceso de empleados o un servicio de información pública. Los clientes con un segundo proveedor o una ruta de derivación pueden recuperarse independientemente; los clientes que dependen exclusivamente de Cloudflare necesitan que el borde de Cloudflare y sus propios orígenes permanezcan conectados.

El 10-K de Cloudflare reconoce que los clientes pueden perder el acceso a sus redes o a Internet hasta que el servicio regrese o invoquen una derivación.

Por lo tanto, los primeros usuarios en sentir un fallo no son necesariamente los más cercanos a la sala oscura. Son los usuarios cuyo proveedor de acceso, producto, regla de localidad, circuito privado y ruta de origen dejan menos alternativas. Esa distribución no puede derivarse solo de la geografía. Requiere datos de tráfico y configuración de clientes que no son públicos.

La evidencia aún faltante para una afirmación creíble de resiliencia

La evidencia pública es suficiente para establecer una superficie operativa latinoamericana sustancial. Cloudflare lista una amplia huella de ciudades. Reporta un despliegue en San José con NIC.CR y un componente de estado activo allí. Su registro de PeeringDB muestra relaciones de intercambio e instalaciones presentes. El material de interconexión de clientes identifica instalaciones nombradas desde São Paulo hasta Bogotá y Lima. Los operadores de instalaciones publican características de energía, refrigeración y soporte.

Cloudflare reporta interconexión externa global a 500 Tbps y describe abiertamente los riesgos de instalaciones de terceros, operadores y energía.

No es suficiente para probar que la región puede absorber la pérdida de un área metropolitana importante sin impacto material. La evidencia faltante comienza con un inventario fechado: instalaciones activas por ciudad, los servicios habilitados en cada una, generaciones de servidores, cómputo utilizable, energía de rack contratada y capacidad de puerto externo. La siguiente necesidad es la utilización: carga normal y de alto percentil, política de reserva, margen de ataque y la transferencia máxima probada desde cada dominio de fallo importante. Los totales globales no pueden responder esas preguntas locales.

La independencia física también necesita prueba. Para cada par de sitios nominalmente diversos, una divulgación útil identificaría suministro eléctrico separado, trenes de UPS y generador, entradas de fibra, salas de reuniones, tejidos de intercambio, rutas de operador y salidas de larga distancia. Indicaría dónde convergen dos circuitos "diversos". Distinguiría un edificio separado de un área metropolitana separada y un área metropolitana separada de una ruta de aterrizaje internacional separada.

La ilustración actual de la red troncal explícitamente no muestra todas las rutas, y el marketing de instalaciones no mapea circuitos específicos de clientes.

El límite legal y comercial sigue siendo incompleto. El registro legal reciente de la empresa costarricense y el registro LACNIC son evidencia sólida de presencia local, pero no hay un cronograma público que asigne instalaciones regionales, contratos de operador, propiedad de equipo o autoridad de emergencia entre los afiliados de Cloudflare. El acuerdo de cliente estándar nombra a la matriz de Delaware. Por lo tanto, un relato creíble debe nombrar a la entidad contratante solo cuando un documento público lo haga y evitar tratar el nombre costarricense como una etiqueta de operador regional genérica.

La evidencia de recuperación incluiría la ruta de alerta desde la instalación a Cloudflare, los compromisos de respuesta de manos remotas, la ubicación de piezas de repuesto, la escalada del operador, los umbrales de retirada de ruta, el orden de reinicio y la prueba de ejercicios en todo el sitio. Los incidentes de Oregón muestran por qué estos detalles importan, pero no establecen el rendimiento latinoamericano. Una calificación N+1 o 2N de una instalación es una entrada, no un resultado.

Las pruebas deben incluir la pérdida de toda la sala, la pérdida de una ruta de operador metropolitana y la pérdida de una región de localidad permitida, no solo dispositivos individuales.

El impacto en el cliente necesita su propia medición. Los informes públicos podrían mostrar, sin exponer a los clientes, cuánto tráfico se movió, dónde aterrizó, cómo cambió la latencia, si las interconexiones privadas conmutaron por error, si los servicios regionalizados permanecieron dentro de sus ubicaciones permitidas y cuánto tiempo tomaron estabilizarse las cachés y las sesiones de larga duración. El aviso de mantenimiento de GRU indica la dirección esperada del viaje pero no publica ninguno de esos resultados.

Ninguno de los elementos faltantes prueba que Cloudflare carece de resiliencia. El secreto en torno a los sitios exactos y la capacidad puede proteger la seguridad y el poder de negociación. El punto es más estrecho: el mapa público y la cifra de capacidad global no pueden respaldar una promesa cuantitativa de conmutación por error regional por sí solos. Lo que se puede defender es una cadena condicional.

Cloudflare tiene muchas ubicaciones y múltiples formas de interconexión; anycast y la distribución de carga local pueden mover el trabajo; las instalaciones de terceros y los operadores proporcionan la plataforma física; y la recuperación exitosa depende de energía, rutas, capacidad y acción humana independientes que solo son parcialmente visibles.

Regrese, finalmente, al interruptor de transferencia de São Paulo. Si la segunda alimentación se mantiene, los enrutadores conservan la luz y la instalación se mantiene fría, los usuarios pueden nunca saber que se movió. Si la sala se oscurece, las rutas pueden irse. Que el servicio sobreviva con fluidez se decide en las salas receptoras: sus vatios de repuesto, ciclos de servidor, puertos, cargas de trabajo permitidas y rutas de trabajo. Esas son las cantidades que un punto de ciudad oculta.

Hasta que se divulguen o se midan independientemente, la lectura honesta del borde latinoamericano de Cloudflare no es "el mapa se cura a sí mismo", sino "el mapa muestra dónde se espera que responda una cadena física cuidadosamente mantenida".