Un AWS SLA (service level agreement) è l'impegno di uptime che Amazon Web Services pubblica per ciascun servizio, con crediti di servizio se non viene rispettato. Amazon EC2, ad esempio, si impegna a un uptime mensile del 99,99% per regione per le istanze distribuite su due o più Availability Zone. Se l'impegno non è rispettato, AWS accredita una fattura futura; non risarcisce il mancato guadagno.
Punti chiave
- AWS dichiara di offrire SLA per tutti i servizi a pagamento e disponibili in via generale. Ogni servizio ha una propria pagina SLA con una propria percentuale di uptime e propri livelli di credito.
- Impegni tipici: EC2 99,99% per regione (multi-AZ) e 99,5% per istanza, RDS Multi-AZ 99,95%, Lambda 99,95% e una soglia di credito di 99,9% per S3 Standard.
- I rimedi sono crediti di servizio del 10%, 25% o 30% e del 100% degli addebiti mensili del servizio interessato, a seconda di quanto è sceso l'uptime. L'SLA è il vostro unico ed esclusivo rimedio.
- I crediti non sono automatici. Aprite un caso nell'AWS Support Center, che deve arrivare entro la fine del secondo ciclo di fatturazione successivo all'incidente.
- L'SLA copre l'infrastruttura di AWS, non la vostra applicazione. Il vostro uptime dipende da come progettate tra Availability Zone e regioni.
Che cos'è un service level agreement di AWS?
È un breve documento legale che fissa un obiettivo di disponibilità misurabile per un servizio AWS e il credito che AWS vi riconosce se non viene raggiunto. AWS li elenca tutti nella sua pagina dei Service Level Agreement, raggruppati per categoria dall'analytics allo storage, e afferma di impegnarsi a offrire SLA "per tutti i servizi a pagamento e disponibili in via generale". Le funzionalità in anteprima e gratuite quindi non sono coperte.
Ogni SLA di servizio segue lo stesso schema:
- Un impegno di servizio: una percentuale di uptime mensile, misurata nel modo definito per quel servizio (ad esempio la connettività esterna per EC2 o il tasso di errore delle richieste per S3).
- Una tabella dei crediti: la percentuale degli addebiti di quel mese che vi viene restituita come credito per ogni fascia di uptime mancato.
- Una procedura di richiesta: come e entro quando chiedere il credito.
- Esclusioni: cause di indisponibilità che non contano, come la vostra configurazione o eventi al di fuori del ragionevole controllo di AWS.
Percentuali di uptime e livelli di credito per i principali servizi AWS
La tabella seguente usa le cifre riportate nella pagina SLA di ciascun servizio a ottobre 2026. AWS aggiorna queste pagine di tanto in tanto, quindi verificate la data di "ultimo aggiornamento" sulla pagina prima di fare affidamento su un numero in un contratto.
| Servizio e ambito | Impegno di uptime mensile | Credito di servizio se non rispettato | Ultimo aggiornamento della pagina SLA |
|---|---|---|---|
| Amazon EC2, livello regione (istanze in 2+ AZ in una regione) | 99,99% | 10% sotto 99,99%; 30% sotto 99,0%; 100% sotto 95,0% | 25 maggio 2022 |
| Amazon EC2, livello istanza (ogni singola istanza) | 99,5% | 10% sotto 99,5%; 30% sotto 99,0%; 100% sotto 95,0% | 25 maggio 2022 |
| Amazon S3 Standard, Express One Zone, Glacier Flexible Retrieval, Glacier Deep Archive | I crediti iniziano sotto 99,9% | 10% sotto 99,9%; 25% sotto 99,0%; 100% sotto 95,0% | 28 nov 2023 |
| Amazon S3 Intelligent-Tiering, Standard-IA, One Zone-IA, Glacier Instant Retrieval | I crediti iniziano sotto 99,0% | 10% sotto 99,0%; 25% sotto 98,0%; 100% sotto 95,0% | 28 nov 2023 |
| Amazon RDS istanza o cluster Multi-AZ | 99,95% | 10% sotto 99,95%; 25% sotto 99,0%; 100% sotto 95,0% | 22 gen 2024 |
| Amazon RDS istanza Single-AZ | 99,5% | 10% sotto 99,5%; 25% sotto 99,0%; 100% sotto 95,0% | 22 gen 2024 |
| AWS Lambda, per regione | 99,95% | 10% sotto 99,95%; 25% sotto 99,0%; 100% sotto 95,0% | 5 maggio 2022 |
Fonti: l'Amazon Compute SLA, l'Amazon S3 SLA, l'Amazon RDS SLA e l'AWS Lambda SLA. Notate che la fascia di credito intermedia di EC2 è il 30%, mentre S3, RDS e Lambda usano il 25%. I riepiloghi più vecchi che citano un'unica tabella per tutti i servizi sono errati.
Che cosa significano le percentuali in minuti
In un mese di 30 giorni (43.200 minuti), gli impegni consentono approssimativamente questa quantità di indisponibilità prima che scattino i crediti:
- 99,99%: circa 4,3 minuti
- 99,95%: circa 21,6 minuti
- 99,9%: circa 43,2 minuti
- 99,5%: circa 3,6 ore
Per questo la cifra di EC2 a livello regione vale solo quando eseguite istanze in almeno due Availability Zone. Una singola istanza ha l'impegno del 99,5% a livello istanza, che consente ore, non minuti, di indisponibilità al mese.
Come funzionano i crediti di servizio AWS?
Un credito di servizio è una percentuale di quanto avete pagato per il servizio interessato, nell'ambito interessato, in quel mese. Per EC2 a livello regione è una percentuale della vostra fattura mensile EC2 in quella regione, esclusi i pagamenti una tantum come le quote anticipate delle Reserved Instance. Per una richiesta a livello istanza è una percentuale della fattura di quella singola istanza.
Un esempio pratico: spendete 8.000 USD per EC2 in eu-north-1 (Stoccolma) in un mese e l'uptime a livello regione delle vostre istanze multi-AZ risulta del 99,95%. È inferiore a 99,99% ma superiore a 99,0%, quindi il credito è del 10%, cioè 800 USD, applicato ai futuri pagamenti EC2.
Altre regole dell'SLA di EC2 che spesso sorprendono:
- I crediti vengono applicati ai pagamenti futuri per lo stesso servizio. Non danno diritto a un rimborso né a un pagamento in contanti.
- AWS emette un credito solo se vale più di 1 USD per il ciclo di fatturazione.
- Per un'istanza potete richiedere il credito in base all'SLA a livello regione o a quello a livello istanza, non a entrambi.
- L'SLA è il vostro rimedio "unico ed esclusivo" per l'indisponibilità, salvo diversa indicazione nel vostro accordo con AWS.
Come richiedere un credito di servizio ad AWS
- Raccogliete le prove. Annotate date e orari dell'incidente, la regione interessata (e l'Availability Zone per le richieste a livello istanza), gli ID delle risorse e i log che mostrano l'interruzione. Oscurate i dati sensibili.
- Aprite un caso nell'AWS Support Center. Usate l'oggetto richiesto dall'SLA. Per EC2 è "Amazon Compute SLA Credit Request – Region-Level Claim" oppure "– Instance-Level Claim"; per S3 l'oggetto deve includere "SLA Credit Request".
- Inviate in tempo. Per EC2 e S3, AWS deve ricevere la richiesta entro la fine del secondo ciclo di fatturazione successivo all'incidente.
- Seguite l'esito. AWS conferma se l'indisponibilità è ammissibile e applica il credito a una fattura successiva.
I team che gestiscono molti account spesso perdono dei crediti perché nessuno è responsabile di questo processo. Se lavorate con un managed service provider, inserite la gestione delle richieste nel contratto.
Che cosa non coprono gli SLA di AWS?
Le esclusioni sono simili tra i servizi. L'indisponibilità non conta ai fini dell'SLA se è causata da:
- fattori al di fuori del ragionevole controllo di AWS, compresi i problemi di internet oltre il bordo della rete AWS;
- vostre azioni o omissioni, come ignorare gli avvisi sullo stato o configurare male le risorse;
- vostre apparecchiature, software o altre tecnologie;
- sospensione o cessazione, da parte di AWS, del vostro uso del servizio ai sensi dell'accordo.
Altre due cose vengono spesso confuse con l'SLA:
- Prestazioni. Gli SLA principali misurano la disponibilità (connettività o tassi di errore), non latenza o throughput. Un servizio lento ma raggiungibile in genere non è "indisponibile".
- Tempi di risposta del supporto. Rientrano nel vostro piano AWS Support, non in un SLA di servizio, e AWS li descrive come obiettivi che si impegna a rispettare con "ogni ragionevole sforzo". I piani attuali indicano, ad esempio, meno di un'ora per un caso di sistema di produzione fermo con Business Support+ e meno di 15 minuti per un caso di sistema critico per il business fermo con Enterprise Support. Il mancato rispetto non fa scattare crediti di servizio.
Perché l'uptime della vostra applicazione è una vostra responsabilità
L'SLA vi dice che cosa AWS promette per un singolo servizio. I vostri utenti sperimentano l'intera catena: load balancer, calcolo, database, storage, DNS e il vostro codice. Se ogni componente si guasta in modo indipendente, la disponibilità della catena è approssimativamente il prodotto di quella dei componenti. Un'applicazione che richiede EC2 al 99,99% e un database RDS Multi-AZ al 99,95% ha un tetto atteso di circa il 99,94%, prima di considerare il vostro codice e i rilasci.
Per andare oltre quanto offre un singolo servizio, progettate per il guasto:
- eseguite il calcolo in almeno due Availability Zone dietro un load balancer;
- usate distribuzioni Multi-AZ per i database;
- automatizzate il ripristino e testatelo, compresi i ripristini dei backup;
- per i sistemi più critici, valutate una seconda regione con un piano di failover testato.
Il pilastro Reliability dell'AWS Well-Architected Framework tratta questi schemi in dettaglio. La nostra guida agli SLA cloud in generale spiega come confrontare gli impegni tra provider e l'articolo sull'SLA di Azure tratta l'equivalente di Microsoft.
Esempio: progettazione multi-AZ in pratica
Quando Opsio ha portato il gruppo svedese di impianti sciistici Branäsgruppen da VMware ad AWS, le applicazioni critiche sono state collocate su più Availability Zone con auto-scaling e database gestiti per gestire il traffico della stagione di punta. Il caso riporta un uptime applicativo superiore al 99,9% e una riduzione del 40% del costo totale di proprietà dopo la migrazione.
SLA di AWS e SLA di un managed service provider
Un SLA di AWS copre la piattaforma. L'SLA di un managed service provider copre il lavoro svolto sopra di essa: la rapidità con cui qualcuno risponde a un alert, la velocità con cui inizia a risolverlo e quale disponibilità garantisce per l'ambiente che gestisce. I due si completano. Ad esempio, l'SLA standard dei servizi cloud gestiti di Opsio prevede un triage in 15 minuti per gli alert critici e una remediation attiva in 1 ora, con crediti di servizio se i tempi di risposta non vengono rispettati. Leggete i dettagli dello SLA di qualsiasi provider, compreso il nostro nella pagina SLA cloud di Opsio, come leggete quello di AWS: che cosa viene misurato, come e che cosa ottenete quando non viene rispettato.
Domande frequenti
Qual è l'uptime dell'SLA di AWS?
Dipende dal servizio. EC2 si impegna al 99,99% per regione per le istanze in due o più Availability Zone e al 99,5% per singola istanza. RDS Multi-AZ e Lambda si impegnano al 99,95%. I crediti di S3 Standard iniziano quando l'uptime scende sotto il 99,9%.
AWS garantisce il 100% di uptime?
No. Nessun SLA di servizio AWS promette il 100%. L'impegno comune più alto è il 99,99%, che consente comunque circa quattro minuti di indisponibilità in un mese di 30 giorni. Una disponibilità superiore deve venire dalla vostra architettura.
Che cosa succede se AWS non rispetta il proprio SLA?
Potete richiedere un credito di servizio dal 10% al 100% degli addebiti mensili del servizio interessato, a seconda di quanto è sceso l'uptime. I crediti si applicano alle fatture future, non vengono pagati in contanti e sono il vostro unico rimedio salvo diversa indicazione nel vostro accordo.
Di quanto tempo dispongo per richiedere un credito SLA ad AWS?
Per EC2 e S3, AWS deve ricevere la richiesta entro la fine del secondo ciclo di fatturazione successivo all'incidente. La inviate come caso nell'AWS Support Center con l'oggetto specificato dall'SLA.
Il tempo di risposta di AWS Support fa parte dell'SLA?
No. I tempi di risposta rientrano nel vostro piano AWS Support e sono descritti come obiettivi. Gli SLA di servizio coprono solo la disponibilità e solo gli SLA di servizio danno diritto a crediti.
Tutti i servizi AWS sono coperti da un SLA?
AWS dichiara di offrire SLA per tutti i servizi a pagamento e disponibili in via generale. I servizi in anteprima non sono coperti e ogni servizio ha condizioni proprie, quindi verificate la pagina SLA specifica di ogni servizio da cui dipende la vostra applicazione.
Letture correlate
Scritto da
Direttore dell'Innovazione
Jacob guida l'innovazione di Opsio, specializzandosi in trasformazione digitale, IA, IoT e soluzioni guidate dal cloud che trasformano tecnologia complessa in valore di business misurabile. Con quasi 15 anni di esperienza, lavora a stretto contatto con i clienti per progettare soluzioni IA e IoT scalabili, ottimizzare i processi di consegna e creare strategie tecnologiche che alimentano una crescita sostenibile e un impatto di lungo termine.
Standard editoriali: Questo articolo è stato scritto dal professionista cloud indicato sopra. Lo aggiorniamo quando cambiano la tecnologia o la normativa di cui tratta; le date in questa pagina indicano l'ultimo aggiornamento. Opsio è editorialmente indipendente.