Interruzione di AWS del 21.02.2026: problemi di routing Direct Connect dopo US-EAST-1 – cosa è successo?
Il 21 febbraio 2026 (CET) si è verificata un'interruzione in AWS Direct Connect nella regione US-EAST-1 (North Virginia), che è stata percepita molto concretamente da alcuni clienti: percorsi precedentemente annunciati tra VPC e On-Prem non erano temporaneamente disponibili (o non più). Il risultato: problemi di connessione dai carichi di lavoro nel VPC verso il proprio data center o le reti On-Prem.
Questo è uno di quegli incidenti che non sembrano spettacolari come "tutto è giù" – ma che nelle architetture ibride causano comunque danni reali quasi immediatamente, perché la connettività è la base di tutto: database, autenticazione, integrazioni legacy, fallback VPN, monitoraggio, deploy.
Fonte: Rappresentazione simbolica dell'infrastruttura cloud e di rete – adatta ai temi Direct Connect e Routing.
Breve riassunto
- Cosa: Problemi di connettività con AWS Direct Connect verso la regione US-EAST-1.
- Quando: 21.02.2026 (CET; notte/prime ore del mattino).
- Sintomo: Alcuni clienti hanno riscontrato la mancanza di percorsi precedentemente annunciati tra VPC e On-Prem, il che ha portato a interruzioni/timeout della connessione.
- Ambito: Coinvolti erano alcuni clienti Direct Connect / non "AWS nel suo complesso".
- Stato (secondo gli aggiornamenti): Causa identificata; AWS ha lavorato parallelamente alle mitigazioni, ripristinato i percorsi e osservato un netto recupero.
- Durata: circa da 1 a 2 ore (a seconda del cliente/percorso; gli aggiornamenti di stato mostrano un recupero graduale).
- Takeaway: La resilienza ibrida richiede ridondanza DX e un fallback VPN, oltre a una strategia di routing pulita.
Cosa è successo?
Secondo gli aggiornamenti di stato pubblicamente accessibili, inizialmente è stata esaminata un'interruzione della connettività Direct Connect in US-EAST-1. Poco dopo, AWS ha confermato che alcuni clienti erano interessati. Nello specifico: "missing previously advertised routes" – cioè percorsi che erano precedentemente disponibili non venivano più annunciati (correttamente). AWS ha identificato la causa e ha lavorato "su più percorsi paralleli" alla risoluzione, inclusa il ripristino degli annunci di percorso interessati.
Timeline (dagli aggiornamenti di stato)
Nota: gli orari sono tratti dagli aggiornamenti di stato pubblicamente visibili; a seconda della visualizzazione, potrebbero essere presentati in fusi orari diversi.
| Ora (Aggiornamento di stato) | Aggiornamento | Significato pratico |
|---|---|---|
| 21.02.2026 00:38 | Investigating (Direct Connect Connectivity Issues) | Prima conferma: il problema riguarda la connettività DX verso US-EAST-1. |
| 21.02.2026 00:59 | Confirmed – mancanza di percorsi precedentemente annunciati | Il traffico ibrido (VPC → On-Prem) può interrompersi, anche se i servizi AWS interni appaiono "verdi". |
| 21.02.2026 01:22 | Ripristino dei percorsi non più annunciati in corso, causa identificata | Il recupero è guidato dal piano di controllo/percorso: può tornare operativo in modo diverso per ciascuna connessione/VIF. |
| 21.02.2026 01:33 | Early signs of recovery | I primi clienti vedono la stabilizzazione – altri potrebbero essere ancora interessati. |
| 21.02.2026 01:50 | Significant recovery | La maggior parte dei percorsi/annunci sembra essere tornata; continuare il monitoraggio. |
Inquadramento tecnico: perché la "mancanza di percorsi" è così pericolosa
Direct Connect si basa fondamentalmente sul routing (BGP) più percorsi fisici/virtuali. Quando i percorsi "spariscono" o non vengono più annunciati correttamente, nel funzionamento appare spesso come un classico errore di rete: timeout, fallimenti sporadici, routing asimmetrico, blackholing – e i sintomi possono variare molto a seconda dell'applicazione.
È importante notare: tali eventi possono verificarsi senza che le tue istanze EC2 o i servizi gestiti da AWS siano essi stessi danneggiati. I tuoi carichi di lavoro funzionano, ma non raggiungono temporaneamente ciò di cui hanno bisogno (ad es. DB On-Prem, AD/LDAP, integrazioni legacy, reti MPLS).
Cosa puoi fare concretamente (ora) – Checklist
- Mantenere attivo il fallback VPN: VPN Site-to-Site come percorso "Break-Glass" che può subentrare in caso di problemi DX (automatizzato tramite priorità di routing).
- Ridondanza Direct Connect: Due connessioni fisiche/posizioni, dispositivi/provider separati, VIF separate. Evitare il destino "single cable".
- Verificare il design del routing: Definire chiaramente le comunità BGP/LocalPref/AS-Path-Prepending, in modo che il failover non "si blocchi".
- Monitoraggio blackbox: Non solo CloudWatch, ma controlli sintetici attraverso il percorso ibrido (VPC → On-Prem e ritorno).
- Runbook per incidenti: "DX down / Routes missing" come categoria di runbook separata – inclusa commutazione rapida e blocchi di comunicazione chiari.
Se utilizzi regolarmente l'ibrido: vale la pena testare consapevolmente le tabelle di routing, la propagazione e il failover (stile Chaos, ma controllato). Perché proprio lì i minuti fanno la differenza – non le ore.
Inquadramento: cosa è successo in passato
L'incidente Direct Connect di ieri è di una classe diversa rispetto alle grandi interruzioni "Internet in fiamme" – ma rientra in uno schema: molte interruzioni non sono "Compute down", ma problemi di rete/control plane, che poi generano secondariamente sintomi ovunque.
Esempi (in breve) – a confronto
| Data | Ambito | Di cosa si trattava approssimativamente? |
|---|---|---|
| 21.02.2026 | AWS Direct Connect (US-EAST-1) | Mancanza di percorsi precedentemente annunciati (VPC ↔ On-Prem) → problemi di connettività ibrida. |
| Okt 2025 | Molteplici servizi AWS (US-EAST-1) | Grande incidente multi-servizio con effetti a cascata (tra cui dipendenze DNS/Load Balancer) – ampiamente percepito. |
| Dez 2025 | Un singolo servizio (regioni Cina) | Segnalata interruzione di una funzionalità di gestione dei costi; discussione su strumenti interni di AI per codice (Kiro) e questioni di processo/autorizzazione. |
Questi ritorni non servono a creare dramma – ma a mostrare: la resilienza è quasi sempre architettura. E negli allestimenti ibridi "Rete + Routing" è l'area in cui un incidente apparentemente piccolo ha immediatamente un grande impatto.
Domande frequenti
È stato "AWS down" o solo Direct Connect?
Gli aggiornamenti pubblici descrivono un problema con AWS Direct Connect verso la regione US-EAST-1. Coinvolti alcuni clienti/connessioni – non necessariamente tutti i servizi AWS a livello globale.
Perché la mancanza di percorsi si nota così tanto?
Perché molti sistemi ibridi hanno dipendenze centrali On-Prem (AD/LDAP, DB legacy, condivisioni file, API centrali). Quando mancano gli annunci BGP, le applicazioni continuano a funzionare ma non raggiungono in modo affidabile le loro dipendenze.
Qual è la migliore protezione?
Direct Connect ridondante (percorsi separati) più fallback VPN, oltre a monitoraggio sintetico attraverso il percorso ibrido effettivo e un runbook chiaro per la commutazione.
Ha qualcosa a che fare con gli "strumenti AI"?
Per l'incidente Direct Connect, negli aggiornamenti pubblici non vi è alcuna indicazione di strumenti AI. Il riferimento all'AI proviene da rapporti separati su altri incidenti (ad es. Dicembre 2025) ed è qui solo per contesto.
Conclusione
L'incidente del 21.02.2026 è un buon esempio del perché non si debbano intendere le interruzioni solo come "servizio down": nelle architetture ibride, un'interruzione negli annunci di percorso è sufficiente e improvvisamente un intero flusso di business si blocca. Se dovessi trarre una sola cosa da questo incidente, questa sarebbe: pianifica il percorso (routing) con la stessa ridondanza dei carichi di lavoro.