Amazon CloudFront e VPC Origins: cosa insegna l’incidente del 16 luglio 2026
Il 16 luglio 2026 un incidente Amazon CloudFront ha causato un aumento degli errori HTTP 5xx a livello globale. Il problema non ha coinvolto tutte le distribuzioni CloudFront, ma esclusivamente quelle configurate per utilizzare la funzionalità VPC Origins.
Il disservizio è durato circa tre ore e mezza: secondo gli aggiornamenti pubblicati sull’AWS Health Dashboard, gli errori sono iniziati alle 00:45 PDT, corrispondenti alle 09:45 in Italia, mentre i primi segnali di ripresa sono stati osservati alle 04:18 PDT, le 13:18 italiane. Il ripristino è poi proseguito progressivamente.
Un evento circoscritto dal punto di vista tecnico, ma significativo per comprendere quanto la disponibilità di un’applicazione dipenda non soltanto dal cloud provider, ma anche dalle scelte effettuate durante la progettazione dell’architettura.
Cosa sono le VPC Origins di Amazon CloudFront
Amazon CloudFront è il servizio CDN di AWS: distribuisce contenuti e applicazioni attraverso una rete globale di edge location, avvicinando le risorse agli utenti finali e riducendo la latenza e il carico sui sistemi di origine.
Con le CloudFront VPC Origins, CloudFront può collegarsi direttamente a risorse ospitate all’interno di subnet private Amazon VPC, come:
- Application Load Balancer;
- Network Load Balancer;
- istanze Amazon EC2.
AWS supporta inoltre configurazioni in cui le distribuzioni CloudFront e le VPC Origins appartengono ad account AWS differenti.
Questa configurazione permette di mantenere l’origine non esposta direttamente su Internet e di utilizzare CloudFront come unico punto di ingresso pubblico dell’applicazione. Le richieste vengono instradate dall’infrastruttura edge verso l’origine attraverso una connessione privata gestita da AWS.
Il vantaggio è rilevante soprattutto in termini di sicurezza: load balancer e server applicativi possono rimanere nelle subnet private, riducendo la superficie di attacco e semplificando la gestione degli accessi.
Proprio il componente incaricato di gestire questa connettività privata è stato coinvolto nell’incidente del 16 luglio.
La cronologia dell’incidente Amazon CloudFront
AWS ha rilevato un aumento degli errori HTTP 5xx per i clienti che utilizzavano CloudFront con VPC Origins.
La prima comunicazione pubblica è arrivata alle 01:44 PDT, le 10:44 in Italia, quando AWS ha dichiarato di avere avviato le indagini. Nel successivo aggiornamento, il provider ha precisato che il problema era in corso dalle 00:45 PDT, le 09:45 italiane, e che le distribuzioni configurate con altri tipi di origine non risultavano coinvolte.
Durante le indagini, AWS ha progressivamente ristretto il perimetro del problema:
- inizialmente verso il sottosistema di elaborazione dei pacchetti utilizzato per instradare le richieste dalle edge location alle VPC dei clienti;
- successivamente verso la capacità delle tabelle di routing gestite da questo sottosistema;
- infine verso un limite interno della flotta responsabile delle connessioni alle origini VPC private.
Le prime azioni di mitigazione sono state avviate alle 03:52 PDT, le 12:52 italiane. AWS ha osservato i primi segnali di ripresa alle 04:18 PDT, le 13:18 italiane, procedendo successivamente con il progressivo ripristino del servizio.
La causa tecnica degli errori 5xx
La causa principale è stata descritta da AWS come un vincolo interno di capacità nella flotta che gestisce le connessioni verso le VPC Origins private.
Una volta raggiunto questo limite, il sistema incaricato di distribuire le configurazioni di routing ai network processor non è riuscito a caricare correttamente i dati aggiornati.
Il risultato è stato un problema di instradamento: CloudFront continuava a ricevere le richieste degli utenti nelle proprie edge location, ma alcune di queste non potevano essere inoltrate correttamente alle risorse private presenti nelle VPC dei clienti.
Dal punto di vista dell’utente finale, il problema si manifestava attraverso risposte HTTP appartenenti alla famiglia 5xx, utilizzate per indicare errori lato server o l’impossibilità temporanea di completare una richiesta.
Non si è trattato di un problema degli Application Load Balancer, delle istanze EC2 o delle applicazioni ospitate nelle VPC dei clienti. Il malfunzionamento si trovava nel livello di connettività gestito da AWS tra CloudFront e le origini private.
Perché le altre origini CloudFront non sono state interessate.
Il problema ha coinvolto esclusivamente il percorso di rete utilizzato dalle VPC Origins, lasciando indenni le distribuzioni configurate con altri tipi di origine. Per questo AWS ha potuto confermare fin dai primi aggiornamenti un perimetro di impatto specifico.
Durante il disservizio è stato suggerito, dove possibile, di passare temporaneamente a un’origine differente. Una soluzione non sempre praticabile, soprattutto per architetture progettate per esporre le risorse esclusivamente tramite connessioni private.
Questo aspetto dimostra quanto sia importante conoscere non soltanto i servizi utilizzati, ma anche i percorsi di rete e le dipendenze gestite sui quali si basa il funzionamento dell’applicazione.
Impatto selettivo e indicazioni architetturali
Nonostante la classificazione “Global”, l’incidente Amazon CloudFront ha colpito solo le distribuzioni con VPC Origins: un promemoria che l’impatto reale dipende dalle dipendenze specifiche del workload.
Punti chiave
- Dipendenze gestite: anche i componenti fully managed restano punti critici. Mappare le dipendenze aiuta a isolare rapidamente i problemi.
- Percorsi alternativi: valutare origini secondarie o meccanismi di failover, come gli origin group, evitando dipendenze comuni tra primario e secondario.
- Procedure di emergenza: predisporre e testare in anticipo eventuali cambi di origine, con attenzione a sicurezza e automazione.
- Monitoraggio end-to-end: affiancare le metriche interne a controlli esterni per rilevare errori che si verificano prima che le richieste raggiungano l’origine.
La resilienza cloud resta una scelta architetturale
AWS ha identificato il problema, applicato diverse azioni di mitigazione e ripristinato il servizio. I clienti che avevano modificato temporaneamente il tipo di origine hanno potuto successivamente ripristinare la configurazione VPC Origin.
L’incidente del 16 luglio dimostra però ancora una volta che nessun servizio gestito può essere considerato completamente immune da guasti.
La questione non è eliminare ogni possibile malfunzionamento, obiettivo difficilmente raggiungibile in un sistema distribuito, ma progettare applicazioni capaci di assorbirne gli effetti.
Conoscere le dipendenze, distinguere i reali domini di errore, predisporre percorsi alternativi e verificare periodicamente le procedure di ripristino permette di trasformare un incidente del provider da interruzione critica a evento gestibile.
Nel cloud, la disponibilità non dipende soltanto dall’affidabilità dei singoli servizi. Dipende soprattutto dal modo in cui questi servizi vengono combinati all’interno dell’architettura.