Wat is een AWS SLA? Uptime-toezeggingen, servicecredits en hoe u claimt

Een AWS SLA (service level agreement) is de uptime-toezegging die Amazon Web Services voor elke dienst publiceert, met servicecredits als die wordt gemist. Amazon EC2 zegt bijvoorbeeld 99,99% maandelijkse uptime per regio toe voor instances die over twee of meer Availability Zones zijn verdeeld. Wordt dat gemist, dan schrijft AWS een toekomstige factuur bij; gederfde bedrijfsinkomsten vergoedt het niet.

Belangrijkste punten

• AWS zegt SLA's aan te bieden voor alle betaalde, algemeen beschikbare services. Elke service heeft een eigen SLA-pagina met een eigen uptimepercentage en creditniveaus.
• Typische toezeggingen: EC2 99,99% per regio (multi-AZ) en 99,5% per instance, RDS Multi-AZ 99,95%, Lambda 99,95% en een creditdrempel van 99,9% voor S3 Standard.
• Vergoedingen bestaan uit servicecredits van 10%, 25% of 30% en 100% van de maandelijkse kosten van de getroffen service, afhankelijk van hoe ver de uptime daalde. De SLA is uw enige en exclusieve rechtsmiddel.
• Credits zijn niet automatisch. U opent een case in het AWS Support Center, en die moet uiterlijk aan het eind van de tweede factureringscyclus na het incident binnen zijn.
• De SLA dekt de infrastructuur van AWS, niet uw applicatie. Uw eigen uptime hangt af van hoe u ontwerpt over Availability Zones en regio's.

Wat is een AWS service level agreement?

Het is een kort juridisch document dat een meetbaar beschikbaarheidsdoel vastlegt voor één AWS-service en het credit dat AWS u geeft als dat doel niet wordt gehaald. AWS toont ze allemaal op zijn pagina Service Level Agreements, gegroepeerd per categorie van analytics tot opslag, en stelt dat het zich ertoe verbindt SLA's aan te bieden "voor alle betaalde, algemeen beschikbare services". Preview- en gratis functies vallen er dus niet onder.

Elke service-SLA volgt hetzelfde patroon:

• Een servicetoezegging: een maandelijks uptimepercentage, gemeten op een manier die voor die service is gedefinieerd (bijvoorbeeld externe connectiviteit voor EC2, of het foutpercentage van verzoeken voor S3).
• Een creditschema: het percentage van de kosten van die maand dat u als credit terugkrijgt voor elke band van gemiste uptime.
• Een claimprocedure: hoe en binnen welke termijn u het credit aanvraagt.
• Uitsluitingen: oorzaken van uitval die niet meetellen, zoals uw eigen configuratie of gebeurtenissen buiten de redelijke macht van AWS.

Uptimepercentages en creditniveaus voor kern-AWS-services

De onderstaande tabel gebruikt de cijfers op de SLA-pagina van elke service per oktober 2026. AWS werkt deze pagina's van tijd tot tijd bij, controleer dus de datum "laatst bijgewerkt" op de pagina voordat u op een getal in een contract vertrouwt.

Bronnen: de Amazon Compute SLA, de Amazon S3 SLA, de Amazon RDS SLA en de AWS Lambda SLA. Let op: de middelste creditband van EC2 is 30%, terwijl S3, RDS en Lambda 25% gebruiken. Oudere samenvattingen die één schema voor alle services noemen, kloppen niet.

Wat de percentages in minuten betekenen

In een maand van 30 dagen (43.200 minuten) staan de toezeggingen ongeveer de volgende hoeveelheid uitval toe voordat credits gelden:

• 99,99%: ongeveer 4,3 minuten
• 99,95%: ongeveer 21,6 minuten
• 99,9%: ongeveer 43,2 minuten
• 99,5%: ongeveer 3,6 uur

Daarom geldt het EC2-cijfer op regioniveau alleen als u instances in minstens twee Availability Zones draait. Een enkele instance valt onder de toezegging van 99,5% op instanceniveau, die per maand uren in plaats van minuten uitval toestaat.

Hoe werken AWS-servicecredits?

Een servicecredit is een percentage van wat u die maand hebt betaald voor de getroffen service in de getroffen scope. Voor EC2 op regioniveau is dat een percentage van uw maandelijkse EC2-rekening in die regio, exclusief eenmalige betalingen zoals vooruitbetaalde Reserved Instance-kosten. Bij een claim op instanceniveau is het een percentage van de rekening van die ene instance.

Een rekenvoorbeeld: u geeft in een maand USD 8.000 uit aan EC2 in eu-north-1 (Stockholm) en de uptime op regioniveau voor uw multi-AZ-instances komt uit op 99,95%. Dat is lager dan 99,99% maar hoger dan 99,0%, dus het credit is 10%, oftewel USD 800, te verrekenen met toekomstige EC2-betalingen.

Andere regels uit de EC2-SLA waar mensen over struikelen:

• Credits worden verrekend met toekomstige betalingen voor dezelfde service. Ze geven geen recht op terugbetaling of betaling in contanten.
• AWS geeft alleen een credit uit als het voor de factureringscyclus meer dan USD 1 waard is.
• Voor een instance kunt u claimen onder de SLA op regioniveau of op instanceniveau, niet beide.
• De SLA is uw "enige en exclusieve" rechtsmiddel bij onbeschikbaarheid, tenzij uw overeenkomst met AWS iets anders zegt.

Een servicecredit bij AWS claimen

1. Verzamel bewijs. Leg de data en tijdstippen van het incident vast, de getroffen regio (en Availability Zone bij claims op instanceniveau), de resource-ID's en logs die de storing aantonen. Maak gevoelige gegevens onleesbaar.
2. Open een case in het AWS Support Center. Gebruik de onderwerpregel die de SLA vraagt. Voor EC2 is dat "Amazon Compute SLA Credit Request – Region-Level Claim" of "– Instance-Level Claim"; voor S3 moet het onderwerp "SLA Credit Request" bevatten.
3. Dien op tijd in. Voor EC2 en S3 moet AWS het verzoek uiterlijk aan het eind van de tweede factureringscyclus na het incident ontvangen.
4. Volg de uitkomst. AWS bevestigt of de uitval in aanmerking komt en verrekent het credit met een latere factuur.

Teams met veel accounts missen credits vaak omdat niemand dit proces beheert. Als u met een managed service provider werkt, maak de afhandeling van claims dan onderdeel van het contract.

Wat dekken AWS-SLA's niet?

De uitsluitingen lijken per service op elkaar. Uitval telt niet mee voor de SLA als die wordt veroorzaakt door:

• factoren buiten de redelijke macht van AWS, waaronder internetproblemen buiten de netwerkrand van AWS;
• uw eigen handelen of nalaten, zoals het negeren van gezondheidsmeldingen of het verkeerd configureren van resources;
• uw eigen apparatuur, software of andere technologie;
• AWS dat uw gebruik van de service op grond van de overeenkomst opschort of beëindigt.

Twee andere zaken worden vaak met de SLA verward:

• Prestaties. De kern-SLA's meten beschikbaarheid (connectiviteit of foutpercentages), niet latentie of doorvoer. Een trage maar bereikbare service is in het algemeen niet "onbeschikbaar".
• Reactietijden van support. Die staan in uw AWS Support-plan, niet in een service-SLA, en AWS beschrijft ze als doelen die het "alle redelijke inspanningen" zal leveren te halen. Huidige plannen noemen bijvoorbeeld minder dan een uur voor een case waarin een productiesysteem uitvalt bij Business Support+ en minder dan 15 minuten voor een case waarin een bedrijfskritiek systeem uitvalt bij Enterprise Support. Het missen ervan geeft geen servicecredits.

Waarom de uptime van uw applicatie uw eigen verantwoordelijkheid is

De SLA vertelt wat AWS voor één service belooft. Uw gebruikers ervaren de hele keten: load balancer, rekenkracht, database, opslag, DNS en uw eigen code. Als elk onderdeel onafhankelijk uitvalt, is de beschikbaarheid van de keten ruwweg het product van de onderdelen. Een applicatie die EC2 op 99,99% en een RDS Multi-AZ-database op 99,95% nodig heeft, heeft een verwacht plafond van ongeveer 99,94%, nog voordat u uw eigen code en uitrol meetelt.

Om verder te komen dan wat één service biedt, ontwerpt u voor uitval:

• draai rekenkracht in minstens twee Availability Zones achter een load balancer;
• gebruik Multi-AZ-implementaties voor databases;
• automatiseer herstel en test het, inclusief het terugzetten van back-ups;
• overweeg voor de meest kritieke systemen een tweede regio met een geteste failoverprocedure.

De Reliability-pijler van het AWS Well-Architected Framework behandelt deze patronen uitgebreid. Onze gids over cloud-SLA's in het algemeen legt uit hoe u toezeggingen tussen providers vergelijkt, en het artikel over de Azure SLA behandelt het equivalent van Microsoft.

Voorbeeld: multi-AZ-ontwerp in de praktijk

Toen Opsio de Zweedse skiresortgroep Branäsgruppen van VMware naar AWS verhuisde, werden kritieke applicaties in meerdere Availability Zones geplaatst met auto scaling en beheerde databases om het verkeer in het hoogseizoen aan te kunnen. De case meldt na de migratie 99,9%+ applicatiebeschikbaarheid en 40% lagere total cost of ownership.

AWS-SLA's versus de SLA van een managed service provider

Een AWS SLA dekt het platform. De SLA van een managed service provider dekt het werk dat erbovenop wordt gedaan: hoe snel iemand op een alarm reageert, hoe snel die begint met oplossen en welke beschikbaarheid hij toezegt voor de omgeving die hij beheert. De twee vullen elkaar aan. De standaard-SLA van Opsio voor cloud managed services bevat bijvoorbeeld 15 minuten triage voor kritieke alarmen en 1 uur actief herstel, met servicecredits als de reactietijden worden gemist. Lees de details van de SLA van elke provider, ook de onze op de cloud-SLA-pagina van Opsio, op dezelfde manier als die van AWS: wat wordt gemeten, hoe, en wat u krijgt als het wordt gemist.

Veelgestelde vragen

Wat is de AWS SLA-uptime?

Dat hangt van de service af. EC2 zegt 99,99% per regio toe voor instances in twee of meer Availability Zones en 99,5% per afzonderlijke instance. RDS Multi-AZ en Lambda zeggen 99,95% toe. Voor S3 Standard beginnen credits wanneer de uptime onder 99,9% daalt.

Garandeert AWS 100% uptime?

Nee. Geen enkele AWS-service-SLA belooft 100%. De hoogste gangbare toezegging is 99,99%, wat in een maand van 30 dagen nog steeds ongeveer vier minuten uitval toestaat. Hogere beschikbaarheid moet uit uw eigen architectuur komen.

Wat gebeurt er als AWS zijn SLA niet haalt?

U kunt een servicecredit claimen van 10% tot 100% van de maandelijkse kosten van de getroffen service, afhankelijk van hoe laag de uptime was. Credits gelden voor toekomstige facturen, worden niet in contanten uitbetaald en zijn uw enige rechtsmiddel, tenzij uw overeenkomst anders bepaalt.

Hoe lang heb ik om een SLA-credit bij AWS te claimen?

Voor EC2 en S3 moet AWS uw verzoek uiterlijk aan het eind van de tweede factureringscyclus na het incident ontvangen. U dient het in als case in het AWS Support Center met de onderwerpregel die de SLA voorschrijft.

Is de reactietijd van AWS Support onderdeel van de SLA?

Nee. Reactietijden horen bij uw AWS Support-plan en worden als doelen beschreven. Service-SLA's dekken alleen beschikbaarheid, en alleen service-SLA's geven credits.

Valt elke AWS-service onder een SLA?

AWS zegt SLA's aan te bieden voor alle betaalde, algemeen beschikbare services. Services in preview vallen er niet onder en elke service heeft eigen voorwaarden, dus controleer de specifieke SLA-pagina voor elke service waarvan uw applicatie afhangt.

Verder lezen

• Wat is Azure SLA? Een praktische gids over betrouwbaarheid en uptime in Azure
• Wat is een Azure SLA en waarom is die cruciaal?
• Cloud-SLA's uitgelegd