AWS y Cloudflare: el costo oculto de la nube centralizada

La nube es un edificio, y a veces se calienta demasiado

Un solo centro de datos de AWS en el norte de Virginia se sobrecalentó y Coinbase se quedó sin servicio. Un error de escritura en un script de Cloudflare dejó a miles de sitios web invisibles. La nube no es ese lugar etéreo y sin peso que nos vendieron durante la última década: es un edificio con paredes, tuberías de refrigeración y cables de alimentación. Y cuando ese edificio se calienta, se cae mucho más que un servidor.

Para un founder, la lección no es volver al servidor en el garaje. Es más incómoda: la resiliencia que crees tener contratada no siempre es la resiliencia que tienes. Y eso se decide en la arquitectura, no en el contrato.

¿Qué pasó con AWS y Cloudflare?

La pieza original describe dos incidentes que, juntos, explican el problema. El primero: un centro de datos de AWS se sobrecalentó y, según el relato, un aire acondicionado averiado en Virginia bastó para que Coinbase se fuera a negro. El segundo: un error de escritura en un script de Cloudflare hizo que miles de sitios web desaparecieran de la vista de sus usuarios.

¿Y esto cómo se aplica en tu negocio?

Dueños de negocio de Latinoamérica y España usan un agente de IA para ganar más y recuperar su tiempo. El Kit «tu mano derecha con IA» te muestra cómo en un video de 11 minutos, con una ficha para armar el tuyo. CAR está cerrada por ahora; al anotarte, te avisamos cuando abra.

👥 Quiero el Kit →

El incidente de AWS no fue un caso aislado de mala suerte. IBTimes reportó que las temperaturas elevadas en un centro de datos de US-East-1, en el norte de Virginia, obligaron a Amazon a limitar servicios y priorizar la recuperación, con afectación a plataformas de streaming, aplicaciones financieras y retailers. Entre los servicios que sufrieron problemas intermitentes aparecen Coinbase, FanDuel y varias plataformas de analítica. La compañía aclaró que ningún dato de cliente se vio comprometido y que el problema quedó aislado a factores ambientales dentro de una instalación.

Dos detalles de esa cobertura importan más que el titular. Primero, US-East-1 sigue siendo una de las regiones de AWS más usadas del mundo y sostiene buena parte de la infraestructura de internet, según IBTimes. Segundo, la recomendación oficial para cargas críticas fue la de siempre: usar arquitecturas multi-región o activar sistemas de respaldo. Es decir, la redundancia existe, pero hay que pagarla y configurarla.

El 20% de la web pasa por la misma tubería

Cloudflare no es un proveedor más. Según Mike Chapple, profesor de tecnología de la información en la Mendoza College of Business de la Universidad de Notre Dame, citado por Spectrum Local News, Cloudflare es una red de distribución de contenido que toma el contenido del 20% de los sitios web del mundo y lo replica en miles de servidores.

«Cuando accedes a un sitio protegido por Cloudflare, tu computadora no se conecta directamente a ese sitio», explicó Chapple. «Se conecta al servidor de Cloudflare más cercano. Es una situación en la que todos ganan, hasta que falla, y el 20% de internet se cae al mismo tiempo.»

Ese apagón, cubierto por Spectrum Local News, dejó fuera de servicio a ChatGPT, X, Shopify, Dropbox, Coinbase, el servicio de calificaciones Moody’s, el sistema de transporte de New Jersey Transit y la web de la ferroviaria francesa SNCF. No fue el problema de un cliente: fue un cuello de botella compartido por millones.

Y no es el único episodio que la misma cobertura pone en la misma serie. Microsoft tuvo que desplegar un parche por una caída de su portal de Azure que dejó sin acceso a Office 365 y Minecraft; la compañía atribuyó el problema a un cambio de configuración en su infraestructura. Amazon también sufrió un apagón masivo de su servicio de nube en octubre que tumbó redes sociales, gaming, delivery de comida, streaming y plataformas financieras.

¿Por qué el bare metal vuelve a la conversación?

La tesis de la pieza original es que los ingenieros más listos están volviendo silenciosamente al bare metal —servidores propios, sin capas de abstracción de por medio—. Vale la pena separar la parte razonable de la parte romántica.

La parte razonable: cada capa que agregas entre tu producto y el hardware es una dependencia que no controlas, y esas capas tienen costo de salida. Google Cloud lista en su página de precios de Cloud Storage la transferencia general de datos saliente desde US$0,08 por GiB, además del almacenamiento estándar desde US$0,02 por GiB al mes. Ese tipo de tarifa es exactamente lo que hace caro irse: no pagas por entrar, pagas por salir.

La parte romántica: no se encontraron datos públicos verificables en esta investigación sobre cuánto del gasto empresarial en nube está migrando de vuelta a infraestructura propia. Sin ese dato, conviene tratar el regreso al bare metal como una tendencia que se discute, no como una corriente medida.

¿Qué significa esto para tu startup?

Para la mayoría de las startups hispanohablantes, salir de la nube no es una opción realista: el costo de oportunidad de administrar hardware es brutal cuando tu equipo son ocho personas. Pero eso no significa aceptar la fragilidad. Significa tratar la dependencia como una decisión de producto.

Hay tres preguntas que casi ningún equipo temprano puede responder hoy:

¿Qué parte de tu producto deja de funcionar si Cloudflare cae?
¿Qué pasa si tu región principal de AWS se degrada durante seis horas?
¿Cuántos de tus proveedores críticos comparten el mismo punto único de fallo?

Si no tienes respuesta, no tienes un plan de continuidad: tienes una esperanza.

Acciones concretas para esta semana

1. Mapea tus dependencias reales. Haz una lista de todo lo que se interpone entre tu usuario y tu base de datos: CDN, DNS, pasarela de pago, proveedor de autenticación, APIs de terceros. Marca cuáles son «si cae, no facturo». Esa lista es tu mapa de riesgo, y suele ser más larga de lo que el equipo cree.

2. Prueba el failover, no lo documentes. Un plan de recuperación que nunca se ejecutó no es un plan. Corre un ejercicio de una hora: apaga la ruta principal en un entorno de staging y mide cuánto tardas en volver. AWS recomienda arquitecturas multi-región para cargas críticas, pero la única forma de saber si la tuya funciona es romperla a propósito.

3. Documenta el impacto para reclamar créditos. En el incidente de AWS, IBTimes reportó que se esperaban créditos de servicio para las cuentas afectadas, aunque los detalles formales no se habían anunciado. Llevar un registro de horas de indisponibilidad y de tickets de clientes te da munición concreta cuando llegue el momento de pedir compensación.

4. Define quién comunica. El apagón de Cloudflare afectó a sistemas de transporte público y a webs de medios. La diferencia entre un incidente y una crisis de reputación suele ser la velocidad del primer mensaje a tus clientes. Ten una plantilla lista antes de necesitarla.

Conclusión

La nube sigue siendo la mejor decisión para casi cualquier startup en etapa temprana: pagas por elasticidad y por no administrar racks. Pero la concentración tiene un precio que no aparece en la factura. Dos incidentes —un aire acondicionado en Virginia y un script mal escrito— bastaron para tumbar servicios que millones de personas usan a diario.

La conclusión práctica no es migrar todo a servidores propios. Es saber exactamente qué se cae contigo cuando se cae otro, y tener un plan que ya hayas probado. La resiliencia no es una característica que se contrata: es una decisión de arquitectura que se toma antes del incidente.