Els darrers dies, el món digital ha tornat a tremolar. Una nova incidència a la infraestructura d’Amazon Web Services (AWS) —el proveïdor de serveis al núvol més utilitzat del planeta— va provocar una caiguda parcial que, tot i originar-se en una regió dels Estats Units, va acabar afectant serveis i aplicacions arreu del món.
L’origen del problema? Tal com diu la dita entre professionals de la xarxa, “it’s always DNS”.
En aquest cas, no era només una broma: errors i latències de xarxa del sistema de resolució DNS van ser el primer efecte d’una cadena que va anar degradant serveis crítics dins de la mateixa infraestructura d’AWS. El mal funcionament inicial va impactar DynamoDB, i a partir d’aquí es van veure afectats serveis “core” com IAM (Identity and Access Management), responsable de l’autenticació i gestió d’identitats, i altres API's de control. Quan IAM o les API's de control cauen, tot allò que depèn de credencials, permisos o elements globals de configuració, deixa de funcionar: API internes, consoles d’administració, i serveis essencials que sustenten centenars de milers d’aplicacions a nivell global.
El resultat va ser una cascada d’interrupcions que va arribar molt més enllà de l’àmbit tècnic. Plataformes de comerç electrònic, serveis de streaming, aplicacions corporatives i fins i tot dispositius domòtics van quedar inoperatius.
La dependència dels grans proveïdors del núvol
Aquesta incidència ens convida a reflexionar sobre una realitat sovint ignorada: la concentració de poder tecnològic en poques mans i la importància de dissenyar serveis cloud més resilients i independents. Avui dia, gran part d’Internet —tant a nivell d’empreses com d’usuaris finals— descansa sobre els serveis d’AWS, Google Cloud o Microsoft Azure. Aquesta concentració facilita l’escala i la innovació, però també genera un risc sistèmic: quan un d’aquests proveïdors té un problema, l’impacte es propaga de manera global i immediata.
Moltes organitzacions han apostat per migrar al núvol per millorar la disponibilitat i reduir la complexitat de la seva infraestructura. Tanmateix, aquesta transició sovint s’ha fet sense valorar prou la dependència directa que s’adquireix del proveïdor. Quan tot el nostre negoci depèn d’un únic entorn, una simple fallada externa pot aturar processos crítics sense que tinguem capacitat d’actuar.
Aquesta caiguda ha estat un bon recordatori de fins a quin punt hem cedit el control a aquests gegants. I no només les empreses: fins i tot la domòtica de casa nostra —amb Alexa al capdavant— depèn d’un servidor a milers de quilòmetres. En alguns casos, usuaris reportaven que no podien aturar el despertador, encendre els llums o obrir les portes intel·ligents de casa seva. Una situació que, tot i anecdòtica, il·lustra fins a quin punt la nostra vida digital i quotidiana depèn d’una infraestructura gestionada per uns pocs actors globals.
La redundància no és sinònim de resiliència
AWS disposa d’una arquitectura altament redundant: múltiples zones de disponibilitat (AZ), regions geogràficament distribuïdes i una llarga llista de mecanismes de tolerància a errors. Tot i això, aquesta incidència ha demostrat que la redundància per si sola no garanteix la resiliència.
El problema no va ser que fallessin els servidors o les regions, sinó que un component centralitzat, com IAM, es va convertir en el punt únic de fallada. Quan un servei essencial per a l’autenticació deixa de funcionar, la resta de la infraestructura pot quedar paralitzada, encara que les instàncies físiques o les bases de dades estiguin disponibles. És una lliçó clàssica en arquitectura distribuïda: no n’hi ha prou amb tenir còpies o rèpliques, cal dissenyar sistemes que puguin funcionar de manera autònoma o degradada quan els serveis centrals fallen.
Aquest episodi reforça la importància de pensar la resiliència més enllà de la infraestructura. És a dir, no només duplicar recursos, sinó també evitar dependències excessives de components únics, especialment en àmbits com la identitat, la seguretat o la gestió de configuracions globals.
Cap a un model de responsabilitat compartida més real
Un altre aspecte que sovint es passa per alt és el concepte de responsabilitat compartida. Els proveïdors com AWS asseguren la disponibilitat de la seva infraestructura, però la responsabilitat d’assegurar la continuïtat dels serveis propis recau en el client. En altres paraules: el núvol pot fallar, i és feina de cada empresa estar preparada perquè això no comporti una parada total.
Això implica repensar com es dissenyen i despleguen les aplicacions:
- Implementar estratègies multi-regió o multi-núvol allà on tingui sentit.
- Garantir que els sistemes crítics puguin funcionar, almenys parcialment, sense dependències externes immediates.
- Automatitzar la detecció i recuperació d’errors.
- I sobretot, provar regularment aquests mecanismes —no només confiar que la redundància farà la seva màgia.
Un factor sovint ignorat: el talent humà darrere la infraestructura
Més enllà de la tecnologia, hi ha un altre element que cal considerar: les persones que mantenen el núvol en funcionament.
En els darrers anys, Amazon ha viscut una onada de canvis interns que no han deixat indemne la seva divisió de serveis al cloud. Des del 2022 fins al 2024, més de 27.000 empleats de la companyia han estat afectats per acomiadaments, i encara avui el procés continua. Tot i que no se sap amb precisió quina part correspon a AWS, és evident que aquesta reducció de plantilla ha impactat equips clau de desenvolupament i operacions.
A més, segons informes interns filtrats, Amazon ha registrat entre un 69 % i un 81 % de professionals que marxen i que l’empresa voldria haver retingut. Aquesta pèrdua de talent s’ha vist agreujada per les tensions internes associades al retorn al treball presencial, una política que molts empleats —especialment perfils tècnics i d’alt nivell— han percebut com una mesura poc flexible i desconnectada de la realitat del sector.
El resultat és un ecosistema on la pressió operativa augmenta mentre el coneixement intern es dilueix. En una infraestructura tan complexa i interdependent com la d’AWS, la pèrdua d’experiència i cohesió pot acabar traduint-se en major risc d’incidències, temps de resposta més lents i, en definitiva, un descens de la resiliència global del sistema.
Fins a quin punt això ha afectat en la prevenció o la capacitat de reacció d'aquest incident concret, ho desconeixem, però és un factor a tenir en compte.
Una oportunitat per repensar la nostra arquitectura
Aquest tipus d’incidents són inevitables, però també una oportunitat per aprendre i millorar. A la nostra empresa, ens recorda la importància de construir infraestructures robustes, observables i amb plans de recuperació reals, no teòrics.
Perquè, al final, el núvol no és un concepte abstracte: són servidors, protocols i persones que treballen per mantenir-lo en marxa. I com tot sistema complex, pot fallar. La diferència entre un servei que cau i un servei que sobreviu està en com d’intel·ligentment ha estat dissenyat —i també en com de ben cuidat està el talent que el sustenta.
La caiguda recent d’AWS és un recordatori que la tecnologia que sosté el nostre dia a dia és tant poderosa com fràgil. Ens obliga a replantejar la nostra confiança en els grans proveïdors i a redoblar els esforços per dissenyar arquitectures realment resilients.
Per molt que el núvol prometi disponibilitat infinita, la resiliència continua sent una responsabilitat compartida —tant tècnica com humana.
I, com sempre, quan alguna cosa falla… bé, ja ho sabem: “it’s always DNS”.
