Hva er en AWS SLA? Oppetidsforpliktelser, servicekreditter og hvordan du krever dem

En AWS SLA (service level agreement, servicenivåavtale) er oppetidsforpliktelsen Amazon Web Services publiserer for hver tjeneste, med servicekreditter hvis den ikke overholdes. Amazon EC2 forplikter seg for eksempel til 99,99 % månedlig oppetid per region for instanser fordelt på to eller flere tilgjengelighetssoner (Availability Zones). Hvis det ikke overholdes, krediterer AWS en fremtidig regning; AWS betaler ikke for tapt forretning.

Viktigste punkter

• AWS sier at de tilbyr SLA-er for alle betalte, generelt tilgjengelige tjenester. Hver tjeneste har sin egen SLA-side med egen oppetidsprosent og egne kredittnivåer.
• Typiske forpliktelser: EC2 99,99 % per region (multi-AZ) og 99,5 % per instans, RDS Multi-AZ 99,95 %, Lambda 99,95 %, og en kredittgrense for S3 Standard på 99,9 %.
• Kompensasjonen er servicekreditter på 10 %, 25 % eller 30 %, og 100 % av den berørte tjenestens månedlige kostnader, avhengig av hvor langt oppetiden falt. SLA-en er ditt eneste og eksklusive rettsmiddel.
• Kreditter er ikke automatiske. Du åpner en sak i AWS Support Center, og den må være mottatt innen utgangen av den andre faktureringssyklusen etter hendelsen.
• SLA-en dekker AWS sin infrastruktur, ikke applikasjonen din. Din egen oppetid avhenger av hvordan du designer på tvers av tilgjengelighetssoner og regioner.

Hva er en AWS-servicenivåavtale?

Det er et kort juridisk dokument som fastsetter et målbart tilgjengelighetsmål for én AWS-tjeneste og kreditten AWS gir deg hvis målet ikke nås. AWS lister dem alle på siden Service Level Agreements, gruppert etter kategori fra analyse til lagring, og oppgir at de forplikter seg til å tilby SLA-er «for all paid, generally available services». Forhåndsversjoner og gratisfunksjoner er derfor ikke dekket.

Hver tjenestes SLA følger samme mønster:

• En tjenesteforpliktelse: en månedlig oppetidsprosent, målt på en måte som er definert for den tjenesten (for eksempel ekstern tilkobling for EC2, eller feilraten for forespørsler for S3).
• En kredittplan: hvor stor prosentandel av månedens kostnader du får tilbake som kreditt for hvert nivå av manglende oppetid.
• En kravprosess: hvordan og innen når du må be om kreditten.
• Unntak: årsaker til nedetid som ikke teller, som egen konfigurasjon eller hendelser utenfor AWS sin rimelige kontroll.

Oppetidsprosenter og kredittnivåer for sentrale AWS-tjenester

Tabellen nedenfor bruker tallene på hver tjenestes SLA-side per oktober 2026. AWS oppdaterer disse sidene fra tid til annen, så sjekk datoen for «last updated» på siden før du bruker et tall i en kontrakt.

Kilder: Amazon Compute SLA, Amazon S3 SLA, Amazon RDS SLA og AWS Lambda SLA. Merk at EC2 har 30 % i det midterste kredittnivået, mens S3, RDS og Lambda bruker 25 %. Eldre oppsummeringer som oppgir én plan for alle tjenester, er feil.

Hva prosentene betyr i minutter

I en måned på 30 dager (43 200 minutter) tillater forpliktelsene omtrent denne nedetiden før kreditter gjelder:

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

Derfor gjelder tallet for EC2 på regionnivå bare når du kjører instanser i minst to tilgjengelighetssoner. En enkelt instans har forpliktelsen på 99,5 % på instansnivå, som tillater timer, ikke minutter, med nedetid i måneden.

Hvordan fungerer AWS-servicekreditter?

En servicekreditt er en prosentandel av det du betalte for den berørte tjenesten i det berørte omfanget den måneden. For EC2 på regionnivå er det en prosentandel av den månedlige EC2-regningen i den regionen, unntatt engangsbetalinger som forhåndsavgifter for Reserved Instances. For et krav på instansnivå er det en prosentandel av regningen for den ene instansen.

Et regneeksempel: du bruker 8 000 USD på EC2 i eu-north-1 (Stockholm) i en måned, og oppetiden på regionnivå for multi-AZ-instansene dine ender på 99,95 %. Det er under 99,99 % men over 99,0 %, så kreditten er 10 %, eller 800 USD, som trekkes fra fremtidige EC2-betalinger.

Andre regler fra EC2-SLA-en som overrasker mange:

• Kreditter trekkes fra fremtidige betalinger for samme tjeneste. De gir ikke rett til refusjon eller kontantutbetaling.
• AWS utsteder en kreditt bare hvis den er verdt mer enn 1 USD for faktureringssyklusen.
• Du kan kreve under SLA-en for regionnivå eller instansnivå for en instans, ikke begge.
• SLA-en er din «sole and exclusive» rettsmiddel ved utilgjengelighet, med mindre avtalen din med AWS sier noe annet.

Slik krever du en servicekreditt fra AWS

1. Samle bevis. Registrer datoer og tidspunkter for hendelsen, den berørte regionen (og tilgjengelighetssonen for krav på instansnivå), ressurs-ID-ene og logger som viser avbruddet. Fjern sensitive data.
2. Åpne en sak i AWS Support Center. Bruk emnelinjen SLA-en ber om. For EC2 er den «Amazon Compute SLA Credit Request – Region-Level Claim» eller «– Instance-Level Claim»; for S3 må emnet inneholde «SLA Credit Request».
3. Send inn i tide. For EC2 og S3 må AWS ha mottatt kravet innen utgangen av den andre faktureringssyklusen etter hendelsen.
4. Følg opp utfallet. AWS bekrefter om nedetiden kvalifiserer og legger kreditten på en senere faktura.

Team som driver mange kontoer går ofte glipp av kreditter fordi ingen eier denne prosessen. Hvis du samarbeider med en leverandør av administrerte tjenester, bør håndtering av krav inngå i kontrakten.

Hva dekker ikke AWS SLA-er?

Unntakene er like på tvers av tjenester. Nedetid teller ikke med i SLA-en hvis den skyldes:

• forhold utenfor AWS sin rimelige kontroll, inkludert internettproblemer utenfor kanten av AWS sitt nettverk;
• egne handlinger eller unnlatelser, som å ignorere helsevarsler eller feilkonfigurere ressurser;
• eget utstyr, egen programvare eller annen teknologi;
• at AWS suspenderer eller avslutter bruken av tjenesten i henhold til avtalen.

To andre ting blandes ofte sammen med SLA-en:

• Ytelse. Kjerne-SLA-ene måler tilgjengelighet (tilkobling eller feilrater), ikke latens eller gjennomstrømning. En treg, men tilgjengelig tjeneste er som regel ikke «utilgjengelig».
• Responstider i support. Disse hører til i AWS Support-planen din, ikke i en tjeneste-SLA, og AWS beskriver dem som mål de vil gjøre «every reasonable effort» for å nå. Gjeldende planer oppgir for eksempel under én time for en sak med produksjonssystem nede på Business Support+ og under 15 minutter for en sak med forretningskritisk system nede på Enterprise Support. Brudd på dem utløser ikke servicekreditter.

Hvorfor oppetiden til applikasjonen er ditt ansvar

SLA-en forteller hva AWS lover for én tjeneste. Brukerne dine opplever hele kjeden: lastbalanserer, beregning, database, lagring, DNS og din egen kode. Hvis hver del svikter uavhengig, er tilgjengeligheten for kjeden omtrent produktet av delene. En applikasjon som trenger EC2 på 99,99 % og en RDS Multi-AZ-database på 99,95 % har et forventet tak på omtrent 99,94 % før du regner med egen kode og utrullinger.

For å komme forbi det én enkelt tjeneste tilbyr, må du designe for svikt:

• kjør beregning i minst to tilgjengelighetssoner bak en lastbalanserer;
• bruk Multi-AZ-utrullinger for databaser;
• automatiser gjenoppretting og test den, inkludert gjenoppretting fra backup;
• for de mest kritiske systemene, vurder en andre region med en testet plan for failover.

Pilaren Reliability i AWS Well-Architected Framework dekker disse mønstrene i detalj. Veiledningen vår om SLA-er i skyen generelt forklarer hvordan du sammenligner forpliktelser på tvers av leverandører, og artikkelen om Azure SLA tar for seg Microsofts tilsvarende.

Eksempel: multi-AZ-design i praksis

Da Opsio flyttet den svenske skidestinasjonsgruppen Branäsgruppen fra VMware til AWS, ble kritiske applikasjoner plassert i flere tilgjengelighetssoner med autoskalering og administrerte databaser for å håndtere trafikken i høysesongen. Caset oppgir over 99,9 % oppetid for applikasjonene og 40 % lavere totale eierkostnader (TCO) etter migreringen.

AWS SLA-er og SLA-en til en leverandør av administrerte tjenester

En AWS SLA dekker plattformen. SLA-en til en leverandør av administrerte tjenester dekker arbeidet som gjøres oppå den: hvor raskt noen reagerer på en alarm, hvor fort de begynner å rette den, og hvilken tilgjengelighet de forplikter seg til for miljøet de drifter. De to utfyller hverandre. Opsios standard-SLA for administrerte skytjenester omfatter for eksempel 15 minutters triage for kritiske alarmer og 1 times aktiv utbedring, med servicekreditter hvis responstidene ikke overholdes. Les detaljene i en leverandørs SLA, inkludert vår på siden om Opsios sky-SLA, på samme måte som du leser AWS sin: hva som måles, hvordan, og hva du får når målet ikke nås.

Ofte stilte spørsmål

Hva er oppetiden i AWS SLA?

Det avhenger av tjenesten. EC2 forplikter seg til 99,99 % per region for instanser i to eller flere tilgjengelighetssoner og 99,5 % per enkelt instans. RDS Multi-AZ og Lambda forplikter seg til 99,95 %. Kreditter for S3 Standard starter når oppetiden faller under 99,9 %.

Garanterer AWS 100 % oppetid?

Nei. Ingen AWS-tjeneste-SLA lover 100 %. Den høyeste vanlige forpliktelsen er 99,99 %, som fortsatt tillater omtrent fire minutter nedetid i en måned på 30 dager. Høyere tilgjengelighet må komme fra din egen arkitektur.

Hva skjer hvis AWS ikke oppfyller SLA-en?

Du kan kreve en servicekreditt på 10 % til 100 % av den berørte tjenestens månedlige kostnader, avhengig av hvor lavt oppetiden falt. Kreditter gjelder fremtidige regninger, utbetales ikke kontant og er ditt eneste rettsmiddel med mindre avtalen sier noe annet.

Hvor lang tid har jeg på å kreve en SLA-kreditt fra AWS?

For EC2 og S3 må AWS ha mottatt kravet innen utgangen av den andre faktureringssyklusen etter hendelsen. Du sender det inn som en sak i AWS Support Center med emnelinjen SLA-en angir.

Er responstiden i AWS Support en del av SLA-en?

Nei. Responstider hører til AWS Support-planen din og beskrives som mål. Tjeneste-SLA-ene dekker bare tilgjengelighet, og bare tjeneste-SLA-er gir kreditter.

Er alle AWS-tjenester dekket av en SLA?

AWS sier at de tilbyr SLA-er for alle betalte, generelt tilgjengelige tjenester. Tjenester i forhåndsversjon er ikke dekket, og hver tjeneste har egne vilkår, så sjekk den enkelte SLA-siden for hver tjeneste applikasjonen din avhenger av.

Relatert lesning

• Hva er Azure SLA? En praktisk veiledning til pålitelighet og oppetid i Azure
• Hva er en Azure SLA, og hvorfor er den kritisk?
• SLA-er for skytjenester forklart