La última gran incidencia de Amazon Web Services (AWS), ocurrida el lunes 20 de octubre, volvió a poner sobre la mesa una realidad incómoda: gran parte de Internet se sostiene sobre muy pocos proveedores de infraestructura. Páginas web, plataformas y servicios —incluidos datáfonos y cajeros— quedaron afectados por un fallo masivo que, según se ha señalado, tuvo su origen en Amazon DynamoDB. En ese contexto, Signal, la app de mensajería centrada en la privacidad, se vio salpicada por críticas en redes sociales por su dependencia de AWS.
Lejos de eludir el debate, la presidenta de la organización, Meredith Whittaker, ha explicado por qué Signal opera parcialmente sobre la nube de Amazon y ha pedido mirar el problema de fondo: la concentración de poder en la infraestructura digital global.
“No hay otra opción”: requisitos técnicos y escala global
Whittaker ha sido clara: casi nadie fuera del reducido grupo de hiperescalares puede ofrecer servicios de nube con cobertura global, capacidad de crecimiento inmediato y un catálogo completo de funcionalidades —desde almacenamiento y bases de datos a redes de entrega de contenidos y control de picos de tráfico—. En la práctica, para una plataforma de comunicación masiva en tiempo real, la elección termina recayendo en AWS, Microsoft Azure o Google Cloud Platform, con escasas alternativas comparables en el entorno occidental.
La ejecutiva se mostró sorprendida por la reacción de quienes descubrieron que Signal usa AWS “en parte” y subrayó que ello no afecta a la privacidad: la aplicación emplea cifrado extremo a extremo, de forma que ni AWS ni terceros pueden leer los contenidos de los usuarios. El proveedor de infraestructura aporta capacidad y disponibilidad, pero no acceso a los mensajes.
Un fallo masivo que destapó la dependencia de la red
El incidente del 20 de octubre dejó una estampa preocupante: cientos de servicios fuera de juego durante horas, con un efecto dominó en pagos y operaciones cotidianas. En paralelo, se avivó el debate público sobre la excesiva dependencia tecnológica de unos pocos actores. Incluso perfiles con gran altavoz —como Elon Musk— cuestionaron la robustez de sistemas críticos apoyados en la nube de Amazon.
Más allá de las réplicas en redes, los datos ayudan a dimensionar el fenómeno: se estima que AWS está detrás de 76,8 millones de webs en el mundo, con alrededor de 200.000 en España. La cifra no es solo un indicador de éxito comercial; también es la medida de un riesgo sistémico cuando algo falla en la base.
Privacidad vs. infraestructura: dos planos distintos
La polémica en torno a Signal mezcló privacidad con infraestructura, dos planos que conviene separar:
- Privacidad: Signal diseña su servicio para que los metadatos se reduzcan al mínimo y los mensajes estén cifrados de extremo a extremo. El proveedor de nube no ve el contenido ni puede descifrarlo.
- Infraestructura: para que una mensajería global funcione con baja latencia, se necesitan centros de datos distribuidos, orquestación y servicios gestionados capaces de soportar picos imprevisibles. Construir y operar todo eso en solitario está fuera del alcance de la mayoría de organizaciones sin inversión multimilmillonaria y años de despliegue.
Se puede —y se debe— discutir cómo reducir dependencias, pero usar AWS no invalida el diseño de seguridad de una app si este está correctamente planteado.
Una lección de resiliencia: monocultivo digital y efecto dominó
Para Whittaker, la caída de AWS debería verse como una lección: cuando el “sistema nervioso” de la economía digital se concentra en tres o cuatro proveedores, los fallos se magnifican. Si una pieza crítica se resiente, el impacto no se queda en una empresa; salta de servicio en servicio, de sector en sector, y afecta al ciudadano en tareas tan básicas como pagar o verificar su identidad.
La resiliencia —concepto cada vez más presente en reguladores y operadores— implica diversificación, planes de contingencia y arquitecturas multicloud o híbridas capaces de conmutar cuando un proveedor falla. Pero esa transición tiene costes técnicos y operativos que no todas las organizaciones pueden asumir de inmediato.
¿Qué alternativas hay de verdad?
Más allá del diagnóstico, cabe preguntarse por las salidas realistas:
- Multicloud y portabilidad: diseñar aplicaciones con abstracciones de infraestructura, usar bases de datos y colas compatibles y mantener paridad de entornos entre proveedores para poder migrar o balancear.
- Estandarización abierta: apostar por protocolos, APIs y herramientas open source que reduzcan el encierro y faciliten la interoperabilidad (observabilidad, despliegues, seguridad).
- Proveedores regionales y soberanía: en algunos casos, combinar hiperescalares con nubes locales o sectoriales mejora la proximidad, el cumplimiento y crea competencia adicional.
- Arquitecturas edge: acercar parte del servicio al borde —cuando es posible— para reducir dependencia de rutas centralizadas y mejorar la continuidad.
Ninguna de estas medidas es gratis ni inmediata, pero dispersan el riesgo y reducen el impacto de incidentes de un solo proveedor.
Un debate que va más allá de Signal
La intervención de Whittaker trasciende el caso particular. No se trata de si una app concreta “debería” usar AWS, sino de cómo ha derivado Internet hacia un modelo en el que “no hay otra opción” práctica para quien quiera escalar rápido, global y con alta disponibilidad. El problema —sostiene— no es que Signal use la nube, sino que demasiadas piezas críticas dependen de muy pocos.
Mientras el mercado se reorganiza y los reguladores estudian mecanismos de competencia y resiliencia, la reflexión inmediata para empresas y administraciones es pragmática: mapear dependencias, ensayar fallos y diseñar planes B. El objetivo es simple de enunciar y difícil de ejecutar: que la próxima caída no pare el mundo.
