Hvad er en AWS SLA? Oppetid, servicekreditter og sådan gør du krav

En AWS SLA (service level agreement) er den oppetidsforpligtelse, som Amazon Web Services offentliggør for hver tjeneste, med servicekreditter, hvis den ikke overholdes. Amazon EC2 forpligter sig for eksempel til 99,99 % månedlig oppetid pr. region for instanser fordelt på to eller flere Availability Zones. Overholdes den ikke, krediterer AWS en kommende regning. AWS betaler ikke for tabt forretning.

Vigtigste pointer

• AWS oplyser, at det tilbyder SLA'er for alle betalte tjenester, der er generelt tilgængelige. Hver tjeneste har sin egen SLA-side med sin egen oppetidsprocent og sine egne kredittrin.
• Typiske forpligtelser: EC2 99,99 % pr. region (multi-AZ) og 99,5 % pr. instans, RDS Multi-AZ 99,95 %, Lambda 99,95 % og en kredittærskel for S3 Standard på 99,9 %.
• Kompensationen er servicekreditter på 10 %, 25 % eller 30 % og 100 % af den berørte tjenestes månedlige gebyrer, afhængigt af hvor langt oppetiden faldt. SLA'en er dit eneste og udelukkende retsmiddel.
• Kreditter gives ikke automatisk. Du opretter en sag i AWS Support Center, og den skal være modtaget senest ved udgangen af den anden faktureringsperiode efter hændelsen.
• SLA'en dækker AWS' infrastruktur, ikke din applikation. Din egen oppetid afhænger af, hvordan du designer på tværs af Availability Zones og regioner.

Hvad er en AWS service level agreement?

Det er et kort juridisk dokument, der fastsætter et målbart tilgængelighedsmål for én AWS-tjeneste og den kredit, du får af AWS, hvis målet ikke nås. AWS opregner dem alle på sin side om Service Level Agreements, grupperet efter kategori fra analyse til lager, og oplyser, at det forpligter sig til at tilbyde SLA'er "for all paid, generally available services". Preview-funktioner og gratis funktioner er derfor ikke dækket.

Alle tjenesters SLA'er følger samme mønster:

• En serviceforpligtelse: en månedlig oppetidsprocent, målt på en måde, der er defineret for den enkelte tjeneste (for eksempel ekstern forbindelse for EC2 eller fejlraten på forespørgsler for S3).
• En kreditskala: den procentdel af månedens gebyrer, du får tilbage som kredit for hvert niveau af manglende oppetid.
• En kravprocedure: hvordan og inden hvornår du anmoder om kreditten.
• Undtagelser: årsager til nedetid, der ikke tæller, for eksempel din egen konfiguration eller hændelser uden for AWS' rimelige kontrol.

Oppetidsprocenter og kredittrin for centrale AWS-tjenester

Tabellen nedenfor bruger tallene på hver tjenestes SLA-side pr. oktober 2026. AWS opdaterer siderne fra tid til anden, så tjek datoen for seneste opdatering på siden, før du støtter dig til et tal i en kontrakt.

Kilder: Amazon Compute SLA, Amazon S3 SLA, Amazon RDS SLA og AWS Lambda SLA. Bemærk, at EC2's mellemste kredittrin er 30 %, mens S3, RDS og Lambda bruger 25 %. Ældre oversigter, der angiver én skala for alle tjenester, er forkerte.

Hvad procenterne betyder i minutter

I en måned på 30 dage (43.200 minutter) tillader forpligtelserne cirka så meget nedetid, før kreditter træder i kraft:

• 99,99 %: ca. 4,3 minutter
• 99,95 %: ca. 21,6 minutter
• 99,9 %: ca. 43,2 minutter
• 99,5 %: ca. 3,6 timer

Derfor gælder EC2's tal på regionsniveau kun, når du kører instanser i mindst to Availability Zones. En enkelt instans har forpligtelsen på instansniveau på 99,5 %, som tillader timer, ikke minutter, af nedetid pr. måned.

Hvordan fungerer AWS' servicekreditter?

En servicekredit er en procentdel af det, du har betalt for den berørte tjeneste inden for det berørte omfang den måned. For EC2 på regionsniveau er det en procentdel af din månedlige EC2-regning i den region, ekskl. engangsbetalinger som forudbetalte Reserved Instance-gebyrer. Ved et krav på instansniveau er det en procentdel af den ene instans' regning.

Et regneeksempel: du bruger 8.000 USD på EC2 i eu-north-1 (Stockholm) på en måned, og oppetiden på regionsniveau for dine multi-AZ-instanser bliver 99,95 %. Det er under 99,99 %, men over 99,0 %, så kreditten er 10 %, eller 800 USD, som modregnes i fremtidige EC2-betalinger.

Andre regler i EC2's SLA, som mange overser:

• Kreditter modregnes i fremtidige betalinger for samme tjeneste. De giver ikke ret til refusion eller kontant betaling.
• AWS udsteder kun en kredit, hvis den er mere end 1 USD værd for faktureringsperioden.
• Du kan gøre krav gældende efter SLA'en på regionsniveau eller på instansniveau for en instans, ikke begge.
• SLA'en er dit "sole and exclusive" retsmiddel ved manglende tilgængelighed, medmindre din aftale med AWS siger andet.

Sådan gør du krav på en servicekredit hos AWS

1. Indsaml dokumentation. Notér datoer og tidspunkter for hændelsen, den berørte region (og Availability Zone ved krav på instansniveau), ressource-id'er og logs, der viser udfaldet. Slør følsomme data.
2. Opret en sag i AWS Support Center. Brug den emnelinje, SLA'en kræver. For EC2 er det "Amazon Compute SLA Credit Request – Region-Level Claim" eller "– Instance-Level Claim", og for S3 skal emnet indeholde "SLA Credit Request".
3. Indsend i tide. For EC2 og S3 skal AWS have modtaget anmodningen senest ved udgangen af den anden faktureringsperiode efter hændelsen.
4. Følg udfaldet. AWS bekræfter, om nedetiden kvalificerer, og modregner kreditten i en senere faktura.

Teams, der driver mange konti, misser ofte kreditter, fordi ingen har ansvaret for processen. Arbejder du med en managed service provider, så gør håndteringen af krav til en del af kontrakten.

Hvad dækker AWS' SLA'er ikke?

Undtagelserne ligner hinanden på tværs af tjenester. Nedetid tæller ikke med i SLA'en, hvis den skyldes:

• forhold uden for AWS' rimelige kontrol, herunder internetproblemer uden for kanten af AWS' netværk;
• dine egne handlinger eller manglende handlinger, for eksempel at ignorere sundhedsmeddelelser eller fejlkonfigurere ressourcer;
• dit eget udstyr, din egen software eller anden teknologi hos dig;
• at AWS suspenderer eller bringer din brug af tjenesten til ophør i henhold til aftalen.

To andre ting bliver ofte blandet sammen med SLA'en:

• Ydeevne. De centrale SLA'er måler tilgængelighed (forbindelse eller fejlrater), ikke latenstid eller gennemløb. En langsom, men tilgængelig tjeneste er generelt ikke "utilgængelig".
• Svartider i support. De ligger i din AWS Support-plan, ikke i en tjenestes SLA, og AWS beskriver dem som mål, det vil gøre "every reasonable effort" for at nå. Gældende planer angiver for eksempel under en time for en sag om nedbrud i et produktionssystem på Business Support+ og under 15 minutter for en sag om nedbrud i et forretningskritisk system på Enterprise Support. Hvis de ikke overholdes, udløser det ikke servicekreditter.

Hvorfor din applikations oppetid er dit ansvar

SLA'en fortæller, hvad AWS lover for én tjeneste. Dine brugere oplever hele kæden: load balancer, compute, database, lager, DNS og din egen kode. Hvis hver del svigter uafhængigt, er kædens tilgængelighed omtrent produktet af delene. En applikation, der kræver EC2 med 99,99 % og en RDS Multi-AZ-database med 99,95 %, har et forventet loft på ca. 99,94 %, før du medregner din egen kode og dine udrulninger.

For at nå længere, end en enkelt tjeneste tilbyder, skal du designe for fejl:

• kør compute i mindst to Availability Zones bag en load balancer;
• brug Multi-AZ-udrulninger til databaser;
• automatisér genetablering og test den, herunder gendannelse fra backup;
• overvej en anden region med en afprøvet failover-plan til de mest kritiske systemer.

Pillaren Reliability i AWS Well-Architected Framework gennemgår disse mønstre i detaljer. Vores guide til cloud-SLA'er generelt forklarer, hvordan du sammenligner forpligtelser på tværs af udbydere, og artiklen om Azure SLA dækker Microsofts tilsvarende.

Eksempel: multi-AZ-design i praksis

Da Opsio flyttede den svenske skiresortgruppe Branäsgruppen fra VMware til AWS, blev kritiske applikationer placeret i flere Availability Zones med auto scaling og managed databaser for at klare trafikken i højsæsonen. Casen rapporterer over 99,9 % oppetid for applikationen og 40 % lavere samlede ejeromkostninger efter migreringen.

AWS' SLA'er og en SLA fra en managed service provider

En AWS SLA dækker platformen. En managed service providers SLA dækker det arbejde, der udføres oven på den: hvor hurtigt nogen reagerer på en alarm, hvor hurtigt de begynder at rette den, og hvilken tilgængelighed de forpligter sig til for det miljø, de driver. De to supplerer hinanden. Opsios standard-SLA for cloud managed services omfatter for eksempel 15 minutters triage af kritiske alarmer og 1 times aktiv afhjælpning, med servicekreditter, hvis svartiderne ikke overholdes. Læs detaljerne i enhver udbyders SLA, også vores på Opsios side om cloud-SLA, på samme måde som du læser AWS': hvad der måles, hvordan, og hvad du får, hvis målet ikke nås.

Ofte stillede spørgsmål

Hvad er AWS' SLA-oppetid?

Det afhænger af tjenesten. EC2 forpligter sig til 99,99 % pr. region for instanser i to eller flere Availability Zones og 99,5 % pr. enkelt instans. RDS Multi-AZ og Lambda forpligter sig til 99,95 %. Kreditter for S3 Standard starter, når oppetiden falder under 99,9 %.

Garanterer AWS 100 % oppetid?

Nej. Ingen AWS-tjenestes SLA lover 100 %. Den højeste almindelige forpligtelse er 99,99 %, hvilket stadig tillader omkring fire minutters nedetid i en måned på 30 dage. Højere tilgængelighed skal komme fra din egen arkitektur.

Hvad sker der, hvis AWS ikke overholder sin SLA?

Du kan gøre krav på en servicekredit på 10 % til 100 % af den berørte tjenestes månedlige gebyrer, afhængigt af hvor lavt oppetiden faldt. Kreditter modregnes i fremtidige regninger, udbetales ikke kontant og er dit eneste retsmiddel, medmindre din aftale siger andet.

Hvor lang tid har jeg til at kræve en SLA-kredit hos AWS?

For EC2 og S3 skal AWS have modtaget din anmodning senest ved udgangen af den anden faktureringsperiode efter hændelsen. Du indsender den som en sag i AWS Support Center med den emnelinje, som SLA'en angiver.

Er svartiden i AWS Support en del af SLA'en?

Nej. Svartider hører til din AWS Support-plan og beskrives som mål. Tjenesternes SLA'er dækker kun tilgængelighed, og kun tjenesternes SLA'er giver kreditter.

Er alle AWS-tjenester dækket af en SLA?

AWS oplyser, at det tilbyder SLA'er for alle betalte tjenester, der er generelt tilgængelige. Tjenester i preview er ikke dækket, og hver tjeneste har sine egne vilkår, så tjek den konkrete SLA-side for hver tjeneste, din applikation afhænger af.

Relateret læsning

• Hvad er Azure SLA? En praktisk guide til pålidelighed og oppetid i Azure
• Hvad er en Azure SLA, og hvorfor er den kritisk?
• Cloud computing-SLA'er forklaret