El teu núvol aguanta perdre una zona. AWS acaba de perdre una regió

El dimarts 15 de setembre AWS va actualitzar el seu panell d'estat del servei. No va ser una nota de premsa ni una anàlisi posterior: va ser una línia de text administratiu. Deia que, després d'una avaluació a fons, no pot restaurar l'accés als recursos i dades allotjats exclusivament en aquella regió. Aquella paraula —exclusivament— és la que separa els clients que han perdut dades de manera permanent dels que s'han endut un ensurt llarg.

Fins on arriba la cobertura pública, és la primera vegada que un hiperescalador dona per perduda una regió sencera a causa d'un atac militar. Convé llegir a poc a poc què va dir exactament, perquè gairebé tot el que cal saber per revisar la teva pròpia casa ja estava publicat abans que passés res.

Què va passar, en sec

El març del 2026, durant la guerra amb l'Iran, hi va haver atacs amb drons que van arribar a instal·lacions d'AWS als Emirats Àrabs Units i van danyar físicament infraestructura a Bahrain. A l'abril va caure una segona zona a Bahrain. Sis mesos després, el 15 de setembre, AWS va publicar el resultat: la regió de Bahrain (me-south-1) no es recupera, i als Emirats tampoc no es recupera una de les tres zones de disponibilitat, la identificada com a mec1-az2.

La frase tècnica d'AWS, la que explica el perquè, és aquesta: «The damage to our infrastructure spanned multiple Availability Zones and exceeded what our regional and multi-AZ services are designed to withstand.» El dany va abastar diverses zones de disponibilitat i va superar el que els serveis regionals i multi-AZ estan dissenyats per suportar.

Una guerra no es compta en zones de disponibilitat, i el primer que deixa darrere no són dades. No opinarem aquí sobre el conflicte, ni sobre qui va disparar: no és el nostre tema i no ens correspon. El que sí que ens correspon és el que ve just després d'aquella frase tècnica, perquè és literalment el nostre ofici: mirar una infraestructura i dir què passa si desapareix un tros. I aquí hi ha una lliçó que aplica igual a una empresa de Sabadell amb dos servidors que a un banc del Golf.

Perquè AWS també va dir això: la majoria de clients van reprendre operacions en un altre lloc, restaurant des de còpies o accedint a les dades que continuaven sent accessibles. Els qui no han perdut res no van tenir més sort. Tenien alguna cosa a fora.

El perímetre estava publicat des del principi

Tothom del sector es coneix el número de la durabilitat de S3: onze nous, 99,999999999%. Se cita en reunions com si fos una propietat de la dada, igual que la seva mida o el seu format. Gairebé ningú obre la pàgina d'on surt, i aquí hi ha el problema: les dues frases que l'acompanyen són les que defineixen de què parla aquell número.

La primera: les classes d'emmagatzematge estàndard «redundantly store objects on multiple devices across a minimum of three Availability Zones in an AWS Region». Un mínim de tres zones de disponibilitat dins d'una regió d'AWS. La segona, l'objectiu de disseny, en singular: estan «designed to sustain data in the event of the loss of an entire Amazon S3 Availability Zone». La pèrdua d'una zona sencera. Una.

I hi ha una tercera dada al mateix paràgraf que gairebé ningú cita, i és la més reveladora de les tres. Les zones «are physically separated by a meaningful distance, many kilometers, from any other Availability Zone, although all are within 100 km (60 miles) of each other». Estan separades per una distància significativa, uns quants quilòmetres, però totes a menys de 100 quilòmetres les unes de les altres.

Cent quilòmetres és una distància excel·lent contra un incendi, una inundació, un tall de subministrament o un paleta amb una radial. És una distància raonable contra un terratrèmol local. I és una distància que, contra certs tipus de succés, no significa res, perquè el succés és més gran que el radi. Això no és una errada d'AWS: és exactament el que AWS va escriure que feia. La frase del panell d'estat tanca el cercle amb una precisió gairebé incòmoda: el dany va superar el que els serveis regionals i multi-AZ estan dissenyats per suportar. El disseny no va fallar. Es va sortir del perímetre que el mateix disseny publica.

És el mateix parany que ja hem explicat amb una altra roba: dues coses duplicades només són dues si no comparteixen el punt que pot fallar. La redundància no és un nombre de còpies: és una llista de coses que poden passar sense que te n'assabentis.

El repartiment de la feina és al contracte, amb títol propi

La documentació d'Amazon EBS obre el capítol de snapshots amb un requadre marcat com a Important que no admet interpretació: «AWS does not automatically back up the data stored on your EBS volumes. For data resiliency and disaster recovery, it is your responsibility to create EBS snapshots on a regular basis, or to set up automatic snapshot creation by using Amazon Data Lifecycle Manager or AWS Backup.» AWS posa les eines per automatitzar-ho; posar la còpia en marxa és teu.

I quan explica on viu aquell snapshot, repeteix el perímetre: «Snapshot data is automatically replicated across all Availability Zones in the Region.» Per totes les zones de la regió. L'snapshot que fas cada nit, el que et dona tranquil·litat, és per defecte dins del mateix perímetre que la dada original. Et protegeix de l'error humà, de l'esborrat, del ransomware i de perdre una zona. No et protegeix de perdre la regió, llevat que el copiïs a una altra expressament.

El contracte diu el mateix amb llenguatge d'advocat. L'AWS Customer Agreement té una secció sencera, la 2.3, titulada «Your Security and Backup»: «You are responsible for properly configuring and using the Services and otherwise taking appropriate action to secure, protect and backup your accounts and Your Content in a manner that will provide appropriate security and protection, which might include use of encryption to protect Your Content from unauthorized access and routinely archiving Your Content.»

I la secció 11.3, Force Majeure, llista quins esdeveniments eximeixen de responsabilitat. Entre acts of God, terratrèmols, talls elèctrics i disturbis, al final de l'enumeració, amb totes les lletres: «acts of terrorism, or war». La paraula estava escrita al contracte anys abans que fes falta.

Per si quedava dubte de què es cobra quan alguna cosa va malament, l'SLA de còmput ho tanca pels dos costats. D'una banda, el remei: «Unless otherwise provided in the Agreement, this SLA sets forth your sole and exclusive remedies, and AWS' sole and exclusive obligations, for any unavailability, non-performance, or other failure by us to provide Amazon EC2.» Crèdits de servei, i res més. De l'altra, l'exclusió, que a l'original enumera els dos SLA i els seus supòsits: els SLA «…do not apply to any unavailability, suspension or termination of Amazon EC2… caused by factors outside of our reasonable control, including any force majeure event…» En un cas de força major, l'SLA directament no aplica.

AWS ha estat generós al marge de tot això: va condonar la facturació d'ús de març a les regions afectades i va suspendre el cobrament mentre va durar la situació, un gest que Forbes va estimar a l'abril en uns 150 milions de dòlars —és una estimació periodística, no una xifra que AWS hagi publicat—. No ho expliquem com a retret, sinó pel contrast: un crèdit compensa una factura. No compensa una dada. I ningú no ha pretès mai que ho fes; està escrit que no ho fa.

Això no va d'AWS

La lectura fàcil d'aquesta notícia és «ho veus, el núvol». És una lectura dolenta i a més còmoda, perquè estalvia a qui la fa haver de mirar el que té. Un hiperescalador publica el seu perímetre de disseny amb nom, quilòmetres i objectiu de durabilitat. La teva sala de servidors no publica res d'això, i això no vol dir que no tingui perímetre: vol dir que no l'has escrit.

Els perímetres que més ens trobem en visites reals: el NAS de còpies al mateix armari que el servidor que copia. El segon node del clúster al rack del costat, connectat al mateix quadre elèctric. La còpia externa que surt, sí, però a un disc que viu al mateix edifici dins d'un calaix. I el cas més comú de tots, que ni tan sols es percep com una decisió: el correu i els fitxers a Microsoft 365, sense cap còpia fora de Microsoft, perquè «ja és al núvol».

Ho repetim sovint perquè és l'eix de tot el que fem: la fallada és inevitable, l'avaria és una decisió de disseny. Un disc que es mor és una fallada. Que per això el teu magatzem no tregui comandes és una avaria, i la diferència entre les dues coses la va decidir algú fa anys, quan va triar on posar la segona còpia. La redundància es construeix per capes —disc, màquina, sala— i cada capa cobreix la de sota. El que ha fet AWS aquesta setmana és ensenyar la capa de sobre, la que gairebé ningú dibuixa perquè semblava teòrica: la regió.

Les quatre preguntes que escrivim en un full

No és una llista de bones pràctiques. És literalment el que apuntem, en aquest ordre, quan entrem en una empresa a revisar continuïtat. Quatre preguntes, i les quatre es contesten amb un nom propi o amb un número, mai amb un adjectiu.

1. Si desapareix la SALA sencera, què es queda sense tornar? No el disc, no el servidor, no el node: la sala, l'edifici, el lloc. És la pregunta que gairebé ningú es fa en veu alta perquè sona catastrofista, i és l'única que ordena totes les altres. La resposta és una llista de sistemes, no un «bé, tindríem les còpies».
2. On és la còpia que NO comparteix aquella sala? Nom del lloc, a quants quilòmetres, en quin proveïdor, qui té les credencials per llegir-la. Si la resposta és «és al núvol», la pregunta continua dempeus: a quina regió, i si aquella regió és la mateixa on corre el sistema. Si totes dues respostes coincideixen, tens una còpia, no dos llocs.
3. Quant es triga a estar operatiu des d'allà? Cronometrat, no estimat. I amb data: quan va ser l'últim cop que algú va posar el cronòmetre. Una restauració que ningú no ha fet no té RTO, té una esperança. Un pla de continuïtat que ningú no ha assajat és un document, i els documents no arrenquen servidors.
4. Si el perímetre es trenca, qui respon? Aquesta és de contracte, no d'arquitectura, i és la que sol estar sense contestar. Obre l'acord del teu proveïdor —el que sigui— i busca dues paraules: backup i força major. Trobaràs, gairebé segur, que la primera t'assenyala a tu i que la segona l'eximeix a ell. Això no és una estafa: és el repartiment de la feina, i convé conèixer-lo el dia que signes i no el dia que falla alguna cosa.

El que AWS recomana als seus propis clients

Convé dir-ho perquè desmunta la caricatura: res d'això no és un descobriment nostre ni una crítica al proveïdor. És al document tècnic de recuperació davant de desastres que publica el mateix AWS, i la frase és explícita: «If your definition of a disaster goes beyond the disruption or loss of a physical data center to that of a Region or if you are subject to regulatory requirements that require it, then you should consider Pilot Light, Warm Standby, or Multi-Site Active/Active.»

És a dir: si per a tu un desastre pot ser perdre una regió sencera, còpia i restauració dins de la regió no és la teva estratègia. I el mateix document avisa que la més ambiciosa de les quatre, multi-site actiu/actiu, «is the most complex and costly approach to disaster recovery». Aquell matís és tan important com l'anterior: la majoria de les empreses amb què treballem no necessita actiu/actiu, i vendre-ho seria vendre fum. El que sí que necessita tothom és saber en quina casella és i haver-ho decidit, en lloc d'acabar en una casella per acumulació de decisions petites.

I una nota del mateix document, en un requadre, que podríem haver signat nosaltres: «Your backup strategy must include testing your backups.»

El que fem nosaltres, i el que no et prometrem

Als sistemes que operem, la recuperació es cronometra. L'últim simulacre de recuperació completa que vam fer es va resoldre en 14 minuts. És una dada interna d'una prova nostra, sobre una infraestructura concreta i amb un procediment concret: és una prova, no una promesa, i no vol dir que el teu cas hagi de trigar això. Vol dir que el número existeix i té data, que és exactament el que falta a la majoria de plans de continuïtat que ens trobem.

El que no et direm és «amb nosaltres estàs fora de perill». El nostre datacenter també és un lloc. És una sala amb una adreça postal, un quadre elèctric i una teulada, igual que la teva i que la d'AWS. Un colocation no deixa de ser un punt en un mapa pel fet que l'operem nosaltres. Per això, als dissenys que signem, la segona còpia també surt del nostre perímetre: una altra ubicació, i quan el cas ho demana, un altre proveïdor i una altra tecnologia. No venem la desaparició del risc, que no existeix. Venem que el risc estigui escrit, repartit i assajat.

Hi ha una frase que diem molt: un backup sense provar no és un backup, és un amulet. Els clients d'AWS que han tornat són els que tenien alguna cosa a fora i sabien com llegir-la. I hi ha una altra lliçó incòmoda que ja vam veure amb el cas de l'empresa a qui desconnectar li va costar 101 minuts i reconnectar-se nou dies: trencar és ràpid; tornar, no. Per això la pregunta útil no és quant trigues a perdre alguna cosa, sinó quant trigues a tornar-la a tenir.

El que no afirmem

No diem que AWS hagi incomplert res, ni que els seus serveis siguin poc fiables: diem que el perímetre del seu disseny està publicat i que el succés el va superar, que és el que la mateixa AWS va escriure. No sabem quins clients concrets van perdre dades, ni quants, ni de quin tipus; AWS no ho ha publicat i nosaltres no ho suposarem. No sabem si els afectats tenien o no còpies fora de la regió, tret de l'afirmació general d'AWS que la majoria de clients va reprendre operacions en un altre lloc. No hem operat càrregues a me-south-1 ni a la regió dels Emirats, així que no expliquem experiència pròpia d'aquelles regions. Tampoc no hem llegit el contracte concret de cap client afectat: les clàusules que citem són les públiques i generals, i un acord empresarial negociat pot dir una altra cosa. I no som part interessada en l'elecció de proveïdor: no revenem AWS, ni Azure, ni Google Cloud, ni llicències de cap.

Nota de fonts

Tot consultat el 19 de setembre del 2026. Un, el succés: l'actualització del panell d'estat del servei d'AWS del 15 de setembre del 2026, recollida per Reuters i per la premsa tècnica internacional, d'on surten les dues cites literals —«The damage to our infrastructure spanned multiple Availability Zones and exceeded what our regional and multi-AZ services are designed to withstand» i «we are unable to restore access to the resources and data hosted exclusively in…»—, la identificació de la regió de Bahrain (me-south-1) i de la zona mec1-az2 als Emirats, les dates de març i abril del 2026, i l'afirmació que la majoria de clients va reprendre operacions en un altre lloc restaurant des de còpies. L'estimació dels 150 milions de dòlars prové de Forbes, l'abril del 2026, sobre la condonació de la facturació de març. Dos, el perímetre de disseny: la pàgina Data protection in Amazon S3 de la documentació oficial (els onze nous, el mínim de tres zones dins d'una regió, l'objectiu de sostenir la pèrdua d'una zona sencera i la distància de menys de 100 km entre zones) i la pàgina Amazon EBS snapshots (l'avís que AWS no fa còpia automàtica i que la responsabilitat és del client, i la replicació de l'snapshot per totes les zones de la regió). Tres, el contracte: l'AWS Customer Agreement, seccions 2.3 Your Security and Backup i 11.3 Force Majeure, i l'Amazon Compute Service Level Agreement, apartats Credit Request and Payment Procedures i Amazon Compute SLA Exclusions. Quatre, la recomanació del fabricant: el document tècnic Disaster Recovery of Workloads on AWS, capítol Disaster recovery options in the cloud. El que és opinió nostra, i va marcat com a tal al cos: la lectura que el problema no és el disseny sinó que gairebé ningú llegeix el perímetre publicat; la llista de perímetres que ens trobem en visites; les quatre preguntes; i la insistència que el nostre propi datacenter és també un punt en un mapa. Les dades d'everyWAN —el simulacre de 14 minuts i la distinció entre fallada i avaria— surten del nostre material intern de resiliència.

Imatge de portada: fotografia aèria del corredor de centres de dades d'Ashburn (Virgínia), de Wikimedia Commons, domini públic / CC0, retallada per nosaltres. Els textos i la marca els afegim a sobre.