SLA in der Cloud

„99,99 % Verfügbarkeit" – das verspricht jeder seriöse Cloud-Anbieter. Klingt fast nach „immer verfügbar". Ist es nicht. Hinter jedem Prozentwert steckt eine konkrete Anzahl Minuten Downtime pro Monat, die du als Kunde tolerieren musst. Und wenn dein Cloud-Workload aus mehreren Komponenten besteht, sinkt die Gesamt-Verfügbarkeit unter die jeder einzelnen Komponente. Das Service Level Agreement (SLA) ist der vertragliche Rahmen, der genau diese Zahlen, Messmethoden und Konsequenzen festschreibt. Wer SLAs nicht versteht, baut Anwendungen, die in der Realität viel öfter ausfallen als geplant – und reklamiert dann gegenüber dem Anbieter, der mit Recht auf den Vertrag verweist.

Die Analogie passt zu einer Versicherung. Wenn dein Auto kaputtgeht, zahlt die Versicherung – aber nur, wenn der Schaden gedeckt ist, der Vertrag eingehalten wurde und du innerhalb der Frist gemeldet hast. Ein SLA funktioniert genauso: Wenn die Verfügbarkeit unterschritten wird, bekommst du eine Gutschrift – aber nur unter bestimmten Bedingungen, in begrenzter Höhe und nur, wenn du es rechtzeitig meldest. Niemand erstattet dir den realen Geschäftsschaden eines mehrstündigen Ausfalls. Und genauso wie bei Versicherungen ist das Kleingedruckte entscheidend.

1) Die „Neunen-Rechnung" – was bedeutet 99,9 % wirklich?

Verfügbarkeit wird in Prozent angegeben, fast immer mit mehreren Nachkommastellen voller Neunen. Daher die branchenübliche Kurzform: „three nines" = 99,9 %, „four nines" = 99,99 % usw. Jede zusätzliche Neun verzehnfacht die Anforderungen an die Architektur. Klick eine Stufe für die Konsequenzen:

2) SLA-Bestandteile – was steht drin?

Ein vollständiges SLA besteht aus deutlich mehr als der Verfügbarkeitsangabe. Die wichtigsten Bestandteile, die du in der IHK-Prüfung erkennen können solltest:

Achtung bei den Begriffen RTO und RPO: Beides sind Zeitwerte, aber sie messen Unterschiedliches. RTO ist nach dem Ausfall: Wie lange dauert es, bis der Service wieder läuft? RPO ist vor dem Ausfall: Wie viele Minuten Daten dürfen verloren gehen? Wer eine Datenbank stündlich sichert, hat RPO = 1 Stunde – im schlimmsten Fall ist die letzte Stunde an Transaktionen weg. Tiefer behandelt in RTO und RPO.

3) Composite SLA – wenn mehrere Dienste in Serie hängen

Hier wird's mathematisch und für die Prüfung relevant: Wenn deine Anwendung aus mehreren Cloud-Komponenten besteht und alle funktionieren müssen, multiplizieren sich die Verfügbarkeiten. Die Gesamt-Verfügbarkeit ist schlechter als die jeder einzelnen Komponente:

4) Service Credits – wie viel zahlt der Anbieter zurück?

Wenn der Cloud-Anbieter sein SLA reißt, bekommst du Service Credits – aber keinen echten Schadensersatz. Das ist die wichtigste Erkenntnis: Selbst ein 24-Stunden-Ausfall bringt dir keine vier-, sondern höchstens drei-prozentige Gutschrift auf die Monatsrechnung. Probier es selbst durch:

5) Geplante Wartung & Exclusions – die feinen Tricks

Wenn man genauer in ein SLA schaut, findet man eine lange Liste von Bedingungen, unter denen Downtime nicht zählt. Diese „Exclusions" sind wirtschaftlich entscheidend – sie reduzieren das Risiko des Anbieters massiv:

• Geplante Wartung: Vorher angekündigte Wartungsfenster (z. B. „2 h pro Monat") zählen nicht. Der Anbieter kann theoretisch jede Nacht 2 Stunden ausfallen – im SLA-Sinn 100 % Verfügbarkeit.
• Höhere Gewalt: Naturkatastrophen, Krieg, Cyberangriffe von dritter Seite. Wenn ein Erdbeben das RZ zerstört, kein Anspruch.
• Kundenseitige Fehlkonfiguration: Wenn du deine VM falsch dimensioniert hast und sie überlastet, ist das nicht der Anbieter. Das fällt unter Shared Responsibility.
• DDoS-Angriffe: Bei manchen Anbietern. Premium-Pakete schließen DDoS-Schutz mit ein.
• Beta-Services: Dienste mit „Preview"- oder „Beta"-Label haben oft kein SLA. Vorsicht bei der Auswahl!
• Single-Zone-Setups: Wer nur in einer Verfügbarkeitszone läuft, bekommt oft niedrigere SLAs als bei Multi-AZ-Setups – z. B. nur 99,5 % statt 99,99 %.

Eine besonders wichtige Falle: Manche Anbieter messen die Verfügbarkeit nicht über das ganze Monat hinweg, sondern in 5-Minuten-Intervallen, von denen mindestens X erfolgreich antworten müssen. Ein 4-Minuten-Komplettausfall zählt dann nicht. Steht alles im Kleingedruckten.

6) Eigene SLAs an Endkunden – wenn du selbst Cloud-Anbieter wirst

Wer einen Service auf Basis der Cloud anbietet, muss seinen eigenen Kunden gegenüber ebenfalls ein SLA versprechen – und das kann nicht besser sein als die Kette darunter. Beispiel: Deine SaaS-Anwendung läuft auf AWS, das 99,99 % verspricht. Deine eigene Anwendungslogik bringt zusätzlich 0,1 % Downtime durch Deployments, Bugs und Wartung. Du kannst deinen Kunden also höchstens 99,89 % zusagen – realistisch eher 99,5 %.

Das ist ein häufiger Streitpunkt: Ein Kunde fordert „99,99 %", aber unter der Haube nutzt du Dienste, die nur 99,9 % garantieren. Was tun?

• Höhere SLAs des Anbieters einkaufen (Premium-Tier mit besserem SLA, oft sehr teuer)
• Redundanzen schaffen: Multi-Region, Multi-Cloud, Fallback-Setups
• Den Kunden über die Kette informieren und Erwartungen managen
• Den eigenen Vertragsstandard ehrlich an dem ausrichten, was technisch möglich ist

Wer ein SLA zusagt, das er nicht halten kann, riskiert nicht nur Service Credits, sondern auch Vertragsbruch, Schadensersatzklagen und Image-Schaden. Mehr dazu in Service Level Agreement im IT-Recht-Kurs.

7) Monitoring der eigenen SLA-Einhaltung

Verlass dich nicht darauf, dass der Anbieter seine SLA-Verletzungen freiwillig zugibt. Eigenes Monitoring ist Pflicht:

• Synthetic Monitoring: Regelmäßige (alle 1-5 Minuten) automatisierte Requests von verschiedenen Standorten der Welt. Tools: Datadog Synthetics, Pingdom, UptimeRobot, AWS CloudWatch Synthetics.
• Real User Monitoring (RUM): Echte Benutzererfahrungen tracken – sind Seitenladezeiten ok? Funktionieren API-Aufrufe?
• Alerting: Bei Schwellwert-Überschreitung sofort benachrichtigen. Eskalationspfad muss klar sein (Bereitschaftsdienst!).
• Reporting: Monatlicher Verfügbarkeitsbericht für Stakeholder. Macht Probleme sichtbar und führt zu architekturellen Verbesserungen.

Damit hast du nicht nur Daten für den Service-Credit-Antrag, sondern auch Argumente für Architekturentscheidungen: „Wir brauchen Multi-AZ, weil wir letzten Monat 4 Stunden Ausfall in einer einzelnen Zone hatten." Ohne Zahlen wird so eine Entscheidung schwer.

Zusammenfassung

Ein SLA regelt vertraglich Verfügbarkeit, Performance und Konsequenzen bei Verstoß. Jede „Neun" verzehnfacht den Aufwand: 99 % = 7 h/Monat Downtime, 99,9 % = 44 min, 99,99 % = 4,4 min, 99,999 % = 26 s. Wichtige Bestandteile: Availability, Latency, RTO (Recovery Time), RPO (Recovery Point), Response Time, Service Credits, Exclusions, Measurement-Methode. Composite SLA: Bei Komponenten in Serie multiplizieren sich die Verfügbarkeiten → Gesamt-SLA < einzelne SLAs. Redundanz dagegen erhöht Verfügbarkeit massiv (Parallel-Formel). Service Credits sind Gutschriften auf die Monatsrechnung, kein Schadensersatz; müssen innerhalb 30 Tagen beantragt werden, sonst verfallen sie. Exclusions sind die wichtigste Stolperfalle: geplante Wartung, höhere Gewalt, Kundenfehler, DDoS, Beta-Services zählen oft nicht. Wer selbst Cloud-Service anbietet, kann sein SLA nicht besser machen als die genutzte Cloud-Kette darunter. Eigenes Monitoring (Synthetic + RUM) ist Pflicht, sonst entgehen einem SLA-Verstöße.

Verwandte Lektionen: Shared Responsibility Model · Verfügbarkeit berechnen · SLA im IT-Recht · und mehrWeitere relevante LektionenRTO und RPOMTBF und MTTRSingle Point of FailureClusteringMonitoring-KonzeptITIL Service Level ManagementIHK-Aufgaben Cloud