View Full Version : Colpiti i data center Amazon: irrecuperabili i dati per milioni di utenti
Redazione di Hardware Upg
17-09-2026, 17:42
Link alla notizia: https://www.hwupgrade.it/news/server-workstation/colpiti-i-data-center-amazon-irrecuperabili-i-dati-per-milioni-di-utenti_159342.html
Amazon Web Services ha confermato la perdita permanente di alcuni dati dei clienti dopo gli attacchi iraniani contro i data center in Bahrain ed Emirati Arabi Uniti. La distruzione ha interessato più Availability Zone, superando le capacità previste dall'infrastruttura multi-AZ
Click sul link per visualizzare la notizia.
Lavoravo in AWS al tempo degli attacchi ed ho personalmente supportato da remoto i tecnici coinvolti nel recupero dei DC bombardati. Era veramente impressionante vedere crateri di diversi metri nel mezzo della datahall, soffitti collassati, porte blindate divelte dalle esplosioni e conficcate nei rack dall'altro lato della stanza. Non era oggettivamente possibile recuperare tutto, un grande plauso ai tecnici locali per il lavoro in condizioni estreme che hanno dovuto svolgere.
mmorselli
17-09-2026, 19:14
Però bella Availability Zone se sei così vulnerabile, i dati dovrebbero essere geograficamente delocalizzati, se faccio un datacenter a Milano e uno a Torino non sto delocalizzando molto. Io stesso che non sono nessuno scelgo sempre server di backup in Paesi diversi rispetto al server di origine, non che mi aspetti delle bombe, ma anche solo dei problemi alle dorsali o qualche evento naturale inaspettato.
Però bella Availability Zone se sei così vulnerabile, i dati dovrebbero essere geograficamente delocalizzati, se faccio un datacenter a Milano e uno a Torino non sto delocalizzando molto. Io stesso che non sono nessuno scelgo sempre server di backup in Paesi diversi rispetto al server di origine, non che mi aspetti delle bombe, ma anche solo dei problemi alle dorsali o qualche evento naturale inaspettato.
Ed eccone uno che non sa cosa sia una AZ e come si fa HA in AWS :rolleyes:
mmorselli
18-09-2026, 03:05
Ed eccone uno che non sa cosa sia una AZ e come si fa HA in AWS :rolleyes:
Sì, ho un cattivo rapporto con AWS, non prendono la mia carta di credito. La ragione è che secondo loro il CVV è opzionale e per questo non lo mettono nel form di pagamento (almeno fino ad un paio d'anni fa), mentre per me e per l'Unione Europea è obbligatorio. Quando l'assistenza ha detto, letteralmente, "devi telefonare alla tua banca per fartelo disattivare" ho capito con che gente avevo a che fare e non mi sono più interessato a loro.
Ciò non toglie che questi hanno perso dati e in teoria gli era stata promessa la HA, o sbaglio?
A me (ovvero ad un mio cliente) non sarebbe capitato in questo caso. Mors 1 : AWS 0
DelusoDaTiscali
18-09-2026, 05:51
Una mia amica ha 2-3mila euro di libri (è medico, ci vuole poco ad arrivare a quella cifra) in un caso del genere avrebbe perso tutto?
DelusoDaTiscali
18-09-2026, 05:54
Aggiungo: non sarà il caso di conservare copie cartacee degli estratti conto per fare eventualmente causa alla banca se dovesse subire un attacco simile?
IMPORTANTE: risparmiatevi di dire che è una assurdità perché l' Italia non è in guerra con nessuno, prché è esattamente il ragionamento che temo facciano i tecnici delle banche italiane.
Il backup è superato, mettete tutto sul cloud che è sicuro :O
Aggiungo: non sarà il caso di conservare copie cartacee degli estratti conto per fare eventualmente causa alla banca se dovesse subire un attacco simile?
IMPORTANTE: risparmiatevi di dire che è una assurdità perché l' Italia non è in guerra con nessuno, prché è esattamente il ragionamento che temo facciano i tecnici delle banche italiane.
Ti basta un pdf dell'ultimo estratto conto.
E dei titoli. Ha validità comunque 2 mesi per contestazioni.
Meglio quello analitico semestrale.
Volendo puoi aggiungerci l'estratto della carta/bancomat.
Il punto è che se la banca online è irraggiungibile per i motivi più catastrofici (che in banca testano periodicamente) anche lo sportello fisico potrebbe avere operatività molto limitata. Nel frattempo come ti arrangi?
Nella fattispecie, vale AWS come per altro, mai tenere le uova nello stesso paniere, anche se i panieri costano
Sì, ho un cattivo rapporto con AWS, non prendono la mia carta di credito. La ragione è che secondo loro il CVV è opzionale e per questo non lo mettono nel form di pagamento (almeno fino ad un paio d'anni fa), mentre per me e per l'Unione Europea è obbligatorio. Quando l'assistenza ha detto, letteralmente, "devi telefonare alla tua banca per fartelo disattivare" ho capito con che gente avevo a che fare e non mi sono più interessato a loro.
Ciò non toglie che questi hanno perso dati e in teoria gli era stata promessa la HA, o sbaglio?
A me (ovvero ad un mio cliente) non sarebbe capitato in questo caso. Mors 1 : AWS 0
Ma promesso cosa?!??
AWS è chiara, la AZ è uno SPOF e ne vanno usate almeno 2 per avere HA. Se non sapete le cose perché seminate disinformazione?
Se non credete a me, leggete la documentazione o fate una ricerca veloce dove vi pare.
Quello di mettere tutto su una singola AZ è il tipico errore da neofiti che si fa con AWS o qualsiasi Cloud in generale.
Quando l'assistenza ha detto, letteralmente, "devi telefonare alla tua banca per fartelo disattivare" ho capito con che gente avevo a che fare e non mi sono più interessato a loro.
Posso dubitare di questa cosa? Come te lo chiedono su Amazon, te lo chiedono anche su AWS. Lo so perchè l'ho fatto...
Ciò non toglie che questi hanno perso dati e in teoria gli era stata promessa la HA, o sbaglio?
"They [le AZ, ndr] are designed not to be simultaneously impacted by a shared fate scenario like utility power, water disruption, fiber isolation, earthquakes, fires, tornadoes, or floods."
Non leggo "bombardamenti mirati a distruggere l'infrastruttura".
A me (ovvero ad un mio cliente) non sarebbe capitato in questo caso. Mors 1 : AWS 0
Questo indipendentemente dal fatto che usi AWS: bastava distribuire le risorse su region diverse...
mmorselli
18-09-2026, 11:16
Posso dubitare di questa cosa?
Io non le capisco queste accuse, vi fidate così poco del prossimo? Vivete in un mondo di cazzari che inventano cose random?
Che ragione avrei di inventare una cosa del genere?
24 ott 2023
Hello there,
Thank you for writing back to us.
I understand your concern regarding not being able to pay your bills.
AWS doesn’t support card verification value (CVV) or 3D Secure authentication. If your card issuer requires the use of CVV, then check with the card issuer to waive the requirement.
That said, to best help you at the moment, I can waive off the past due bill on your account as a one time exception.
However, please know that the issue will persist again the next month if the root cause isn't fixed. Hence, I request you to kindly contact your bank or add a new credit card to your account as per the guidelines.
Kindly contact the issuing institution for your card , share the Signature ID ************************ and ask them to approve charge requests from AWS. Once the issue is resolved from the bank's end, then kindly try to add your card to your AWS account again
Sai com'è proseguita? Che gli ho detto "ma non c'è problema, datemi un IBAN e vi pago la fattura con un bonifico"
Risposta: non puoi.
Ma come cazzo sono messi, posso dirlo?
Hanno preferito annullare la fattura che trovare un modo per farmela pagare, rendendomi però impossibile ogni altra transazione.
Questo indipendentemente dal fatto che usi AWS: bastava distribuire le risorse su region diverse...
Bastava anche solo usare 2 AZ diverse nella stessa region, cosa non fatta da chi ha perso i dati. :rolleyes:
Contando che devi essere pazzo a tenere dati di produzione solo su una AZ, queste aziende che hanno perso dati preziosi, non conoscono il concetto di offsite backup? Ma sanno cosa sia un DR Plan?
Anche se hai i soli backup e non tutta l'infra replicata cross region Active-Active o Active-Standby, se hai i dati replicati al massimo perdi X ore di dati, non tutto.
Quelli persi saranno i "preziosi dati" del salumiere o di aziende che hanno assunto salumieri al posto di DevOps. Con tutto il rispetto per i salumieri.
Per quanto riguarda la questione carta di credito mmorselli ha detto il vero.
AWS NON SUPPORTAVA il CVV.
Confermo.
Ora lo supporta.
Basta una ricerca di secondi tre, per verificare.
Per tutto il resto concordo invece con chi scrive che i servizi vanno saputi usare, soprattutto i contratti vanno letti a fondo.
Pena, ritrovarsi con una mano davanti e una di dietro.
mmorselli
18-09-2026, 11:26
Non leggo "bombardamenti mirati a distruggere l'infrastruttura".
Al di là delle clausole, un sistema ben progettato dovrebbe resistere anche a questo, no?
Capisco il discorso per cui è l'utente che deve mettere in piedi un sistema ben progettato usando i servizi a disposizione, ma mentre quando prendo un server barebone è chiarissimo che i tuoi dati sono in un luogo fisico ben preciso e quindi andrebbero perduti anche a causa di un semplice guasto elettrico, quando usi un servizio in cloud si punta molto su questa percezione per cui i tuoi dati essendo distribuiti sono al sicuro. Colpevolizzare solo la vittima raramente ha senso, la vittima dovrebbe essere più accorta, ma un po' di proattività da parte del fornitore di servizi non guasterebbe.
mmorselli
18-09-2026, 11:30
AWS NON SUPPORTAVA il CVV.
In un periodo in cui in Europa era obbligatorio da anni. Ma non è la mancanza che mi ha fatto ribollire il sangue, quanto la stupidità dell'assistenza nel proporre come soluzione di contattare la mia banca e farmi approvare una transazione che non ha passato la verifica 2FA. Consiglierei di cambiare banca se lo facessero.
Krusty93
18-09-2026, 11:46
Bastava anche solo usare 2 AZ diverse nella stessa region, cosa non fatta da chi ha perso i dati. :rolleyes:
Vero negli Emirati, non in Bahrain dove TUTTE le AZ sono state tirate giù. In quel caso serviva un multi region.
Detto ciò, dipende anche di che dati si sta parlando. Anche noi abbiamo diversi dati non replicati, ma sono per istanze di test o molto secondarie. E' chiaro che al CSP importa poco, verrebbero comunque classificati come dati persi
Vero negli Emirati, non in Bahrain dove TUTTE le AZ sono state tirate giù. In quel caso serviva un multi region.
Detto ciò, dipende anche di che dati si sta parlando. Anche noi abbiamo diversi dati non replicati, ma sono per istanze di test o molto secondarie. E' chiaro che al CSP importa poco, verrebbero comunque classificati come dati persi
After the first availability zone in Bahrain was damaged in March, AWS began recommending that customers migrate their workloads to other regions, it said in Tuesday's update. Most did so before the Bahrain region became unavailable following disruption to a second availability zone in April.
Ti bombardano una AZ a marzo, ne resta solo una in piedi. Io il giorno dopo avrei migrato tutto il più lontano possibile da lì. Ti bombardano la seconda ad Aprile e non avevi migrato? Allora sei pirla tu :mbe:
Fermo restando che, se hai piano di DR, e backup parcheggiato in altra regione, non perdi nulla a livello di dato, vai solo offline fintanto che non ritiri su tutto.
Tasslehoff
18-09-2026, 15:23
Al di là delle clausole, un sistema ben progettato dovrebbe resistere anche a questo, no?
Capisco il discorso per cui è l'utente che deve mettere in piedi un sistema ben progettato usando i servizi a disposizione, ma mentre quando prendo un server barebone è chiarissimo che i tuoi dati sono in un luogo fisico ben preciso e quindi andrebbero perduti anche a causa di un semplice guasto elettrico, quando usi un servizio in cloud si punta molto su questa percezione per cui i tuoi dati essendo distribuiti sono al sicuro. Colpevolizzare solo la vittima raramente ha senso, la vittima dovrebbe essere più accorta, ma un po' di proattività da parte del fornitore di servizi non guasterebbe.No mi spiace ma non funziona così, ne con AWS ne con nessun altro fornitore.
AWS (come qualsiasi altro fornitore) ti mette a disposizione tutti gli strumenti di questo mondo per ridondare persino su diverse regioni con due click (ovviamente sto banalizzando ma per dire su AWS Backup e S3 bastano veramente due click).
Ovviamente ridondare vuol dire occupare il doppio delle risorse, e quindi pagare il doppio, o quantomeno pagare il doppio sulle risorse che replichi.
Quindi se replichi in un altra AZ della stessa regione avrai il doppio delle risorse occupate (es doppio dei volumi EBS, doppio del bucket, doppie instances per i worker nodes e doppio control plane di un cluster EKS, etc etc...
Se replichi tra regioni diverse avrai il doppio delle risorse occupate più i costi di traffico tra regioni differenti.
Nessuno, e dico NESSUNO replica nulla in modo automatico o automagico, e soprattutto non lo fa a costo zero.
Al massimo ti mette a disposizione le risorse e gli strumenti per farlo, ma sta a te decidere se vuoi farlo e pagare per farlo.
Stessa identica storia di quando è andato a fuoco il datacenter di OVH in Francia, orde di imbecilli che gridavano allo scandalo perchè l'infrastruttura non era ridondata, o che non avevano letto nemmeno tre righe dei contratti per i servizi che avevano acquistato dando per scontato tutto e il contrario di tutto...
E lo dico da utente OVH che è stato direttamente impattato dall'incendio e ha perso il suo vps (per carità una cazzata ad uso privato) ma che l'ha ripristinato nel giro di mezz'ora perchè aveva backup funzionanti, una architettura ben documentata, semplice e pulita, e i backup venivano replicati anche offsite presso un differente provider in una regione diversa.
Una AZ è sostanzialmente un datacenter. Se uno memorizza dati in una AZ non ha alcuna ridondanza. Se uno usa servizi regionali questi sono spesso multi-AZ, che significa sopravvivono ad un disastro che accade ad 1 datacenter nella regione. Se tutte le AZ sono attaccate la regione non regge chiaramente e questo è sempre stato chiaramente detto da Amazon. I clienti che sono preoccupati da disastri cosi devono fare copie e architetture cross region, che non sono ne banali ne economiche ne spesso legali da un punto di vista di compliance e data residency.
Ma quale è l alternativa? Farsi i datacenter a casa? Beh magari non ve li bombardano se siete dei mr nessuno, ma direi che allagamenti incendi e perdite di energia elettrica o cooling o rete sono molto piu frequenti che un missile sul tetto di un hyperscaler quindi ci penserei bene prima di osannare chi si tiene i dati on prem
mmorselli
19-09-2026, 19:51
Ma quale è l alternativa? Farsi i datacenter a casa?
Magari il datacenter no,ma una replica locale dei dati fa così schifo?
Magari il datacenter no,ma una replica locale dei dati fa così schifo?
Spetta al cliente e non ad Amazon. Amazon ti dice chiaramente come fa la replica dei dati (ad esempio di S3) a seconda di come configuri le cose e ti da modo di costruirti un'infrastruttura geodistribuita.
Io non voglio assolutamente che tutto sia ridondato automaticamente, primo perché Amazon non può sapere cosa ci faccio girare sulla sua infra e che tipo di replica necessitano i dati; secondo, perché mi costerebbe il doppio.
Se usi CDN, AWS Lambda, DynamoDB Global Tables e S3 con replica multi-region, puoi sviluppare un prodotto distribuito in 10 regioni con costo iniziale pari a ZERO e con la replica dei dati gestita da AWS (chiaro che poi devi sapere come funziona eventual consistency & Co, se sei una capra farai solo un gran casino)
Se hai applicativi legacy (non nati per il cloud) e non sei capra, fai un piano di backup e DR in base al budget e lo spieghi al cliente. Se al cliente va bene andare al risparmio e non vuole backup off-region, saranno problemi suoi.
mmorselli
20-09-2026, 20:37
Spetta al cliente e non ad Amazon.
E questo è assodato, la mia obbiezione però è che il cloud rischia di trasmettere una sensazione di falsa sicurezza. Spetta al cliente, ma per tante ragioni al cliente possono sfuggire dei dettagli, come il fatto che avere i dati in cloud non basta.
Posto che Amazon avrà i suoi avvocati schierati a tutelarla da ogni responsabilità, io definisco un sistema in cui non nascono questi equivoci preferibile da uno in cui possono nascere.
E questo è assodato, la mia obbiezione però è che il cloud rischia di trasmettere una sensazione di falsa sicurezza. Spetta al cliente, ma per tante ragioni al cliente possono sfuggire dei dettagli, come il fatto che avere i dati in cloud non basta.
Posto che Amazon avrà i suoi avvocati schierati a tutelarla da ogni responsabilità, io definisco un sistema in cui non nascono questi equivoci preferibile da uno in cui possono nascere.
oh ma se uno gestisce una infrastruttura che potenzialmente necessiterebbe di un multi AZ o addirittura region
sarà ben colpa di quello che la gestisce, e non del fornitore dei servizi
no?
se ti improvvisi tecnico, allora paghi le conseguenze
se sei un professionista, metti in campo tutto quanto necessario per garantire continuità, al netto di consapevoli compromessi (che patteggi con i proprietari)
Ripper89
22-09-2026, 12:59
Cioè abbiamo datacenters su territorio musulmano ? Cosa ci fanno lì ? :doh:
mmorselli
22-09-2026, 13:59
oh ma se uno gestisce una infrastruttura che potenzialmente necessiterebbe di un multi AZ o addirittura region
sarà ben colpa di quello che la gestisce, e non del fornitore dei servizi
no?
Tutti avrebbero bisogno di delocalizzare regionalmente almeno i backup.
Prendi per esempio la realtà Italiana, sono migliaia di PMI che non hanno il budget per avere dei responsabili IT interni, per cui si affidano a fornitori esterni che potrebbero essere competenti come no. Si fidano, e pensano che AWS implichi una sicurezza intrinseca. Senza questa convinzione magari ti sbatteresti di più per verificare se davvero questa sicurezza ti viene fornita. D'altra parte stiamo commentando un articolo che dice "irrecuperabili dati per milioni di utenti", magari il titolo esagera come sempre, però quando un problema è molto comune sarebbe più saggio analizzare le cause e pensare a soluzioni reali, rispetto a dire che le persone sono tutte stupide e che la soluzione è smettere di essere stupidi.
mmorselli
22-09-2026, 14:02
Cioè abbiamo datacenters su territorio musulmano ? Cosa ci fanno lì ? :doh:
Ragebaiting at its finest
Tutti avrebbero bisogno di delocalizzare regionalmente almeno i backup.
Prendi per esempio la realtà Italiana, sono migliaia di PMI che non hanno il budget per avere dei responsabili IT interni, per cui si affidano a fornitori esterni che potrebbero essere competenti come no. Si fidano, e pensano che AWS implichi una sicurezza intrinseca. Senza questa convinzione magari ti sbatteresti di più per verificare se davvero questa sicurezza ti viene fornita. D'altra parte stiamo commentando un articolo che dice "irrecuperabili dati per milioni di utenti", magari il titolo esagera come sempre, però quando un problema è molto comune sarebbe più saggio analizzare le cause e pensare a soluzioni reali, rispetto a dire che le persone sono tutte stupide e che la soluzione è smettere di essere stupidi.
che vuol dire "si fidano"
:D
è semplice ignoranza, tutto qui
il cloud era ed è sempre il pc di un altro
mmorselli
22-09-2026, 14:49
è semplice ignoranza, tutto qui
Sì, ma bisognerebbe considerare l'ignoranza come un problema da affrontare e risolvere, non come una colpa da espiare.
Prendi per esempio le passkey su cui i principali attori si stanno spendendo molto. Nascono dalla presa di coscienza che le persone non sanno gestire le password. Si farebbe prima a derubricare il tutto come ignoranza, ma l'ignoranza diffusa crea problemi condivisi, le persone non sono isole.
Sì, ma bisognerebbe considerare l'ignoranza come un problema da affrontare e risolvere, non come una colpa da espiare.
Prendi per esempio le passkey su cui i principali attori si stanno spendendo molto. Nascono dalla presa di coscienza che le persone non sanno gestire le password. Si farebbe prima a derubricare il tutto come ignoranza, ma l'ignoranza diffusa crea problemi condivisi, le persone non sono isole.
sono perfettamente d'accordo
ma in questo caso il nesso con AWS non c'è
se ci limitiamo a parlare di responsabilità legate al non aver gestito la ridondanza su intere AZ di sua sponte, non c'è responsabilità, per me
per quanto riguarda l'ignoranza di chi gestisce queste cose, sfondi una porta aperta
vBulletin® v3.6.4, Copyright ©2000-2026, Jelsoft Enterprises Ltd.