SLA för molntjänster: så förhandlar du rätt avtal
Group COO & CISO
Operational excellence, governance, and information security. Aligns technology, risk, and business outcomes in complex IT environments
SLA för molntjänster: så förhandlar du rätt avtal
Ett tjänstenivåavtal (SLA) för molntjänster definierar exakt vilken drifttid, svarstid och supportnivå din leverantör förbinder sig att leverera — och vilka konsekvenser det får om de misslyckas. Trots det behandlar många organisationer SLA som en kryssruta snarare än ett styrverktyg. Rätt förhandlat skyddar ett SLA din verksamhet. Fel hanterat ger det en falsk trygghet medan kostsamma avbrott ackumuleras.
Viktiga slutsatser
- Ett SLA är inte bara ett juridiskt dokument — det styr hur snabbt problem åtgärdas och vem som bär ansvaret
- Drifttid på 99,9 % innebär fortfarande nästan 9 timmar planerat eller oplanerat avbrott per år
- Tjänstekrediter kompenserar sällan den verkliga affärskostnaden vid avbrott — komplettera med egen övervakning
- NIS2-direktivet ställer nya krav på att dokumentera leverantörsansvar, inklusive SLA-villkor
- Förhandla alltid om eskaleringsrutiner, mätmetod och undantag — inte bara upptidsprocent
Vad ett SLA för molntjänster faktiskt innebär
Ett SLA (Service Level Agreement) är ett avtal mellan molnleverantören och kunden som specificerar mätbara åtaganden kring tjänstens kvalitet. Det handlar inte om vaga löften utan om konkreta mätvärden: procentuell drifttid, maximal svarstid vid incidenter, lösningstider per prioritetsnivå och ekonomiska påföljder om leverantören inte lever upp till åtagandena.
Vad vi på Opsio ser i praktiken är att standardavtal från hyperscalers — AWS, Azure och Google Cloud — primärt skyddar deras infrastruktur. De täcker beräkningstjänster, lagring och nätverk på plattformsnivå, men säger ingenting om din applikations tillgänglighet, dina backuprutiner eller hur snabbt en felkonfigurerad brandväggsregel åtgärdas klockan tre på natten. Det är i det mellanrummet en managerad tjänsteleverantör (MSP) tillför verkligt värde.
Skillnaden mellan plattforms-SLA och operativt SLA
Det finns en fundamental distinktion som många organisationer missar:
- Plattforms-SLA (från AWS, Azure, Google Cloud): Garanterar att den underliggande infrastrukturen — virtuella maskiner, objektlagring, databastjänster — är tillgänglig enligt avtal. Om en EC2-instans i eu-north-1 (Stockholm) inte går att nå på grund av ett infrastrukturfel, kan du begära tjänstekrediter.
- Operativt SLA (från din MSP eller interna driftorganisation): Täcker hela stacken — applikationsövervakning, konfigurationshantering, patchning, incidentrespons och eskalering. Det är här verksamhetskritiska garantier bor.
Att förlita sig enbart på plattforms-SLA är som att lita på att fastighetsägaren ansvarar för allt som händer i din kontorslokal bara för att byggnaden har en brandförsäkring.
Vill ni ha expertstöd med sla för molntjänster: så förhandlar du rätt avtal?
Våra molnarkitekter hjälper er med sla för molntjänster: så förhandlar du rätt avtal — från strategi till implementation. Boka ett kostnadsfritt 30-minuters rådgivningssamtal utan förpliktelse.
Drifttidsnivåer: vad siffrorna verkligen betyder
Drifttidsprocenten är det mest citerade men också mest missförstådda måttet i ett SLA. Skillnaden mellan 99,9 % och 99,99 % ser marginell ut — men i praktiken handlar det om en tiopotens i tillåten nedtid.
| Drifttidsnivå | Tillåten nedtid/år | Tillåten nedtid/månad | Typisk tillämpning |
|---|---|---|---|
| 99 % | 3 dagar 15 h 36 min | 7 h 18 min | Interna utvecklingsmiljöer |
| 99,9 % | 8 h 46 min | 43 min 50 s | Standardapplikationer |
| 99,95 % | 4 h 23 min | 21 min 55 s | Affärskritiska system |
| 99,99 % | 52 min 36 s | 4 min 23 s | Finansiella transaktionssystem |
| 99,999 % | 5 min 15 s | 26 s | Telekom, hälso- och sjukvård |
Hur hyperscalers definierar drifttid — och var det brister
AWS definierar drifttid för EC2 som "Regional Unavailability" — alltså att hela regionen måste vara nere för att SLA ska triggas. Om en enskild Availability Zone i eu-north-1 faller bort men de andra fungerar, klassificeras det inte som SLA-brott. Azure använder en liknande modell per tjänsteinstans, medan Google Cloud ibland tillämper per-projekt-mätning.
I vårt NOC i Karlstad ser vi regelbundet situationer där en kund upplever fullständigt avbrott — deras applikation ligger nere — men leverantörens statusdashboard visar grönt. Anledningen? Avbrottet beror på en kedja av händelser: en automatiserad skalningsregel som inte triggar, en certifikatförnyelse som misslyckas, en DNS-propagering som fastnar. Ingen enskild komponent bryter sitt SLA, men slutresultatet är detsamma: verksamheten står still.
Det är därför vi alltid rekommenderar att komplettera leverantörens SLA med extern syntetisk övervakning och tydliga operativa avtal. Managerade molntjänster
Nyckelkomponenter i ett starkt molntjänst-SLA
Ett SLA som faktiskt skyddar din verksamhet innehåller betydligt mer än en drifttidsprocent. Här är de komponenter vi anser vara icke-förhandlingsbara:
1. Tydligt definierade mätvärden med mätmetod
Varje mätvärde (KPI) måste specificera hur det mäts, vem som mäter och vilken datakälla som gäller vid tvist. Om leverantören mäter drifttid med sin egen interna övervakning och du mäter med din egen, kommer ni oundvikligen att komma till olika slutsatser. Bestäm i förväg vilken källa som är avgörande.
2. Incidentklassificering och svarstider
Alla incidenter är inte lika kritiska. Ett robust SLA definierar minst tre till fyra prioritetsnivåer:
| Prioritet | Beskrivning | Svarstid | Lösningsmål |
|---|---|---|---|
| P1 — Kritisk | Tjänsten helt nere, ingen workaround | ≤ 15 min | ≤ 4 h |
| P2 — Hög | Allvarlig funktionsnedsättning | ≤ 30 min | ≤ 8 h |
| P3 — Medium | Begränsad påverkan, workaround finns | ≤ 2 h | Nästa arbetsdag |
| P4 — Låg | Kosmetiskt eller informationsfråga | ≤ 8 h | Planerad release |
Svarstid och lösningstid är inte samma sak. En leverantör som svarar inom 15 minuter med "vi undersöker" men inte löser problemet förrän efter 12 timmar har tekniskt sett uppfyllt svarstids-SLA men totalt misslyckats ur verksamhetsperspektiv.
3. Eskaleringsrutiner och kontaktvägar
Avtalet ska specificera vem som kontaktas vid P1-incidenter, hur eskalering sker om första nivån inte löser problemet inom angiven tid och vilka beslutsfattare som kan involveras. I Opsios 24/7 SOC/NOC har vi dedikerade eskaleringskedjor per kund — något som ett standard-SLA från en hyperscaler aldrig erbjuder. Molnsäkerhet
4. Undantag och force majeure
Varje SLA har undantag. De vanligaste är planerat underhåll, force majeure och avbrott orsakade av kundens egen konfiguration. Granska dessa noggrant — vissa leverantörer definierar "planerat underhåll" så brett att de kan ta ner tjänster under kontorstid med bara 24 timmars förvarning utan att det räknas som SLA-brott.
5. Tjänstekrediter och faktiska påföljder
De flesta hyperscalers erbjuder tjänstekrediter — typiskt 10–30 % av månadskostnaden för den drabbade tjänsten. Låt oss vara tydliga: om din e-handelsplattform ligger nere i fyra timmar under Black Friday och du förlorar intäkter motsvarande hundratusentals kronor, kompenserar en tjänstekredit på några hundralappar ingenting. Tjänstekrediter är ett incitament för leverantören att hålla hög kvalitet, inte en försäkring för din verksamhet.
SLA-krav i ljuset av NIS2 och GDPR
NIS2-direktivet, som trädde i kraft i EU:s medlemsstater under 2024–2025, ställer explicita krav på att organisationer inom väsentliga och viktiga sektorer hanterar säkerhetsrisker i sina leverantörskedjor. I praktiken innebär det att ditt SLA med molnleverantörer och MSP:er måste inkludera:
- Krav på incidentrapportering inom definierade tidsramar (NIS2 kräver initial rapportering inom 24 timmar)
- Dokumenterade säkerhetskrav som leverantören ska uppfylla
- Rätt till revision — möjligheten att granska leverantörens efterlevnad
- Krav på databehandling inom EU/EES i enlighet med GDPR och Schrems II-praxis
Integritetsskyddsmyndigheten (IMY) har tydliggjort att personuppgiftsbiträdesavtal inte ersätter SLA-villkor — de kompletterar varandra. Ett robust avtal med en molnleverantör behöver bägge delarna. Molnmigrering
Så förhandlar du ett SLA som faktiskt skyddar dig
Baserat på hundratals kundavtal vi på Opsio har granskat och förhandlat, ser vi samma misstag upprepas. Här är vår rekommendation:
Definiera dina verksamhetskrav först. Börja inte med leverantörens standardmall. Kartlägg vilka system som är verksamhetskritiska, vilken maximal nedtid verksamheten tål (RTO) och hur mycket data ni kan förlora (RPO). Låt dessa siffror styra SLA-förhandlingen.
Mät själv. Implementera oberoende övervakning innan du signerar avtalet. Verktyg som Datadog, Grafana Cloud eller AWS CloudWatch (konfigurerat rätt) ger dig en egen sanningskälla vid tvister.
Förhandla om det som spelar roll. Drifttidsprocenten är sällan förhandlingsbar hos hyperscalers. Men eskaleringsrutiner, dedikerad teknisk kontaktperson, utökade supportnivåer (Enterprise Support hos AWS, Unified Support hos Microsoft) och rapporteringsfrekvens — det går nästan alltid att påverka. Managerad DevOps
Granska årligen. Din molnmiljö förändras. Nya tjänster tillkommer, arbetsbelastningar flyttas, regulatoriska krav skärps. Ett SLA som var rätt dimensionerat för två år sedan kan vara helt otillräckligt idag. Vi rekommenderar kvartalsvis genomgång av SLA-efterlevnad och årlig omförhandling. Cloud FinOps
Opsios perspektiv: SLA som levande styrverktyg
Ett SLA ska inte vara ett dokument som plockas fram vid tvister. I vårt SOC/NOC använder vi SLA-mätvärden aktivt — de styr alerting-trösklar, eskaleringsautomatik och kapacitetsplanering. När en kunds svarstidsmål börjar närma sig gränsvärdet triggar våra system åtgärder innan ett brott inträffar, inte efter.
Det är skillnaden mellan att använda SLA reaktivt (som bevis efter skadan) och proaktivt (som operativt styrverktyg). Organisationer som gör den förflyttningen ser konsekvent bättre driftstabilitet och lägre incidentkostnader.
Vanliga frågor
Vad innebär 99,9 % drifttid i praktiken?
99,9 % drifttid tillåter cirka 8 timmar och 46 minuter oplanerad nedtid per år, eller ungefär 44 minuter per månad. Det låter lite, men ett enda avbrott under kritisk verksamhetstid kan kosta betydligt mer än vad tjänstekrediterna kompenserar. Många organisationer behöver 99,95 % eller högre för verksamhetskritiska system.
Hur skiljer sig SLA mellan AWS, Azure och Google Cloud?
Alla tre erbjuder liknande grundnivåer runt 99,9–99,99 % beroende på tjänst, men de skiljer sig i hur nedtid mäts, vilka undantag som gäller och hur tjänstekrediter beräknas. Azure mäter ofta per tjänsteinstans, AWS per region, och Google Cloud har i vissa fall mer generösa kreditmodeller. Detaljerna varierar per enskild tjänst.
Räcker molnleverantörens standard-SLA för mitt företag?
Sällan. Standard-SLA täcker leverantörens infrastruktur men inte din applikationslogik, konfiguration eller dataförlust orsakad av användarfel. Du behöver komplettera med en managerad tjänsteleverantör (MSP) som ansvarar för den operativa nivån ovanpå molnplattformen.
Hur påverkar NIS2-direktivet SLA-krav?
NIS2 kräver att organisationer inom väsentliga och viktiga sektorer dokumenterar sina leverantörskedjor och säkerställer att avtal med IT-leverantörer inkluderar tydliga säkerhets- och incidenthanteringskrav. Det innebär att SLA-villkor kring incidentsvar, rapportering och eskalering måste formaliseras och granskas regelbundet.
Vad bör jag göra om leverantören bryter mot SLA?
Dokumentera avbrottet med egen övervakningsdata — förlita dig inte enbart på leverantörens statusrapporter. Begär tjänstekrediter enligt avtalet, men utvärdera också om avtalet behöver omförhandlas. Upprepade SLA-brott är en tydlig signal att byta leverantör eller komplettera med ett NOC som övervakar dygnet runt.
Relaterade artiklar
Om författaren
Group COO & CISO at Opsio
Operational excellence, governance, and information security. Aligns technology, risk, and business outcomes in complex IT environments
Editorial standards: This article was written by a certified practitioner and peer-reviewed by our engineering team. We update content quarterly to ensure technical accuracy. Opsio maintains editorial independence — we recommend solutions based on technical merit, not commercial relationships.
