Was ist ein AWS SLA? Verfügbarkeitszusagen, Service Credits und Antrag

Ein AWS SLA (Service Level Agreement) ist die Verfügbarkeitszusage, die Amazon Web Services für jeden Dienst veröffentlicht, samt Service Credits, falls sie verfehlt wird. Amazon EC2 sagt zum Beispiel 99,99 % monatliche Verfügbarkeit pro Region für Instanzen zu, die auf mindestens zwei Availability Zones verteilt sind. Wird sie verfehlt, schreibt AWS eine künftige Rechnung gut; entgangene Geschäfte ersetzt es nicht.

Das Wichtigste in Kürze

• AWS gibt an, SLAs für alle kostenpflichtigen, allgemein verfügbaren Dienste anzubieten. Jeder Dienst hat eine eigene SLA-Seite mit eigenem Verfügbarkeitsprozentsatz und eigenen Gutschriftstufen.
• Typische Zusagen: EC2 99,99 % pro Region (Multi-AZ) und 99,5 % pro Instanz, RDS Multi-AZ 99,95 %, Lambda 99,95 % und für S3 Standard eine Gutschriftsschwelle von 99,9 %.
• Als Abhilfe gibt es Service Credits von 10 %, 25 % oder 30 % sowie 100 % der monatlichen Gebühren des betroffenen Dienstes, je nachdem, wie weit die Verfügbarkeit gefallen ist. Das SLA ist Ihr einziger und ausschließlicher Rechtsbehelf.
• Gutschriften erfolgen nicht automatisch. Sie eröffnen einen Fall im AWS Support Center, und er muss bis zum Ende des zweiten Abrechnungszyklus nach dem Vorfall eingehen.
• Das SLA deckt die Infrastruktur von AWS ab, nicht Ihre Anwendung. Ihre eigene Verfügbarkeit hängt davon ab, wie Sie über Availability Zones und Regionen hinweg entwerfen.

Was ist ein AWS Service Level Agreement?

Es ist ein kurzes rechtliches Dokument, das für einen AWS-Dienst ein messbares Verfügbarkeitsziel festlegt und die Gutschrift, die AWS Ihnen gewährt, wenn es verfehlt wird. AWS führt alle auf seiner Seite Service Level Agreements auf, gegliedert nach Kategorien von Analytics bis Storage, und erklärt, SLAs „for all paid, generally available services“ anzubieten, also für alle kostenpflichtigen, allgemein verfügbaren Dienste. Preview- und kostenlose Funktionen sind daher nicht abgedeckt.

Jedes Dienst-SLA folgt demselben Muster:

• Eine Dienstzusage: ein monatlicher Verfügbarkeitsprozentsatz, gemessen auf eine für den jeweiligen Dienst definierte Weise (zum Beispiel externe Konnektivität bei EC2 oder die Fehlerrate von Anfragen bei S3).
• Eine Gutschriftstabelle: der Prozentsatz der Monatsgebühren, den Sie für jede Stufe verfehlter Verfügbarkeit als Guthaben zurückerhalten.
• Ein Antragsverfahren: wie und bis wann Sie die Gutschrift beantragen.
• Ausschlüsse: Ursachen für Ausfälle, die nicht zählen, etwa Ihre eigene Konfiguration oder Ereignisse außerhalb der zumutbaren Kontrolle von AWS.

Verfügbarkeitsprozentsätze und Gutschriftstufen für zentrale AWS-Dienste

Die Tabelle unten verwendet die Angaben auf der SLA-Seite des jeweiligen Dienstes, Stand Oktober 2026. AWS aktualisiert diese Seiten von Zeit zu Zeit. Prüfen Sie daher das Datum „zuletzt aktualisiert“ auf der Seite, bevor Sie sich in einem Vertrag auf eine Zahl stützen.

Quellen: das Amazon Compute SLA, das Amazon S3 SLA, das Amazon RDS SLA und das AWS Lambda SLA. Beachten Sie, dass die mittlere Gutschriftstufe bei EC2 30 % beträgt, bei S3, RDS und Lambda dagegen 25 %. Ältere Zusammenfassungen, die für alle Dienste einen einzigen Plan nennen, sind falsch.

Was die Prozentsätze in Minuten bedeuten

In einem Monat mit 30 Tagen (43.200 Minuten) erlauben die Zusagen ungefähr so viel Ausfallzeit, bevor Gutschriften greifen:

• 99,99 %: etwa 4,3 Minuten
• 99,95 %: etwa 21,6 Minuten
• 99,9 %: etwa 43,2 Minuten
• 99,5 %: etwa 3,6 Stunden

Deshalb gilt die EC2-Zahl auf Regionsebene nur, wenn Sie Instanzen in mindestens zwei Availability Zones betreiben. Eine einzelne Instanz unterliegt der Zusage von 99,5 % auf Instanzebene, die pro Monat Stunden statt Minuten Ausfallzeit erlaubt.

Wie funktionieren AWS Service Credits?

Ein Service Credit ist ein Prozentsatz dessen, was Sie in diesem Monat für den betroffenen Dienst im betroffenen Geltungsbereich gezahlt haben. Bei EC2 auf Regionsebene ist es ein Prozentsatz Ihrer monatlichen EC2-Rechnung in dieser Region, ohne Einmalzahlungen wie Vorauszahlungen für Reserved Instances. Bei einem Antrag auf Instanzebene ist es ein Prozentsatz der Rechnung dieser einen Instanz.

Ein durchgerechnetes Beispiel: Sie geben in einem Monat 8.000 USD für EC2 in eu-north-1 (Stockholm) aus, und die Verfügbarkeit Ihrer Multi-AZ-Instanzen auf Regionsebene liegt bei 99,95 %. Das ist weniger als 99,99 %, aber mehr als 99,0 %, die Gutschrift beträgt also 10 % oder 800 USD und wird auf künftige EC2-Zahlungen angerechnet.

Weitere Regeln aus dem EC2-SLA, über die man leicht stolpert:

• Gutschriften werden mit künftigen Zahlungen für denselben Dienst verrechnet. Sie begründen keinen Anspruch auf Erstattung oder Barzahlung.
• AWS stellt eine Gutschrift nur aus, wenn sie für den Abrechnungszyklus mehr als 1 USD wert ist.
• Für eine Instanz können Sie entweder nach dem SLA auf Regionsebene oder auf Instanzebene Ansprüche geltend machen, nicht nach beiden.
• Das SLA ist Ihr „sole and exclusive“ Rechtsbehelf, also der einzige und ausschließliche, bei Nichtverfügbarkeit, sofern Ihre Vereinbarung mit AWS nichts anderes vorsieht.

So beantragen Sie einen Service Credit bei AWS

1. Belege sammeln. Halten Sie Datum und Uhrzeit des Vorfalls, die betroffene Region (bei Anträgen auf Instanzebene auch die Availability Zone), die Ressourcen-IDs und Logs fest, die den Ausfall zeigen. Schwärzen Sie sensible Daten.
2. Einen Fall im AWS Support Center eröffnen. Verwenden Sie den Betreff, den das SLA verlangt. Bei EC2 lautet er „Amazon Compute SLA Credit Request – Region-Level Claim“ oder „– Instance-Level Claim“; bei S3 muss der Betreff „SLA Credit Request“ enthalten.
3. Rechtzeitig einreichen. Bei EC2 und S3 muss AWS den Antrag bis zum Ende des zweiten Abrechnungszyklus nach dem Vorfall erhalten.
4. Das Ergebnis verfolgen. AWS bestätigt, ob der Ausfall anspruchsberechtigt ist, und verrechnet die Gutschrift mit einer späteren Rechnung.

Teams mit vielen Konten verpassen Gutschriften oft, weil niemand für diesen Prozess zuständig ist. Wenn Sie mit einem Managed Service Provider arbeiten, machen Sie die Bearbeitung von Anträgen zum Vertragsbestandteil.

Was decken AWS SLAs nicht ab?

Die Ausschlüsse sind bei den Diensten ähnlich. Ausfallzeit zählt nicht für das SLA, wenn sie verursacht wird durch:

• Faktoren außerhalb der zumutbaren Kontrolle von AWS, einschließlich Internetproblemen jenseits des Netzwerkrands von AWS;
• Ihr eigenes Handeln oder Unterlassen, etwa das Ignorieren von Health-Hinweisen oder falsch konfigurierte Ressourcen;
• Ihre eigene Ausrüstung, Software oder andere Technik;
• die Sperrung oder Beendigung Ihrer Nutzung des Dienstes durch AWS nach der Vereinbarung.

Zwei weitere Dinge werden oft mit dem SLA verwechselt:

• Performance. Die zentralen SLAs messen Verfügbarkeit (Konnektivität oder Fehlerraten), nicht Latenz oder Durchsatz. Ein langsamer, aber erreichbarer Dienst gilt im Allgemeinen nicht als „nicht verfügbar“.
• Reaktionszeiten des Supports. Diese stehen in Ihrem AWS-Support-Plan, nicht in einem Dienst-SLA, und AWS beschreibt sie als Ziele, die es mit „every reasonable effort“ zu erreichen versucht. Aktuelle Pläne nennen zum Beispiel weniger als eine Stunde für einen Fall „Produktionssystem ausgefallen“ bei Business Support+ und weniger als 15 Minuten für einen Fall „geschäftskritisches System ausgefallen“ bei Enterprise Support. Werden sie verfehlt, entstehen keine Service Credits.

Warum die Verfügbarkeit Ihrer Anwendung in Ihrer Verantwortung liegt

Das SLA sagt Ihnen, was AWS für einen Dienst zusagt. Ihre Nutzer erleben die gesamte Kette: Load Balancer, Compute, Datenbank, Storage, DNS und Ihren eigenen Code. Fällt jeder Teil unabhängig aus, entspricht die Verfügbarkeit der Kette ungefähr dem Produkt der Einzelwerte. Eine Anwendung, die EC2 mit 99,99 % und eine RDS-Multi-AZ-Datenbank mit 99,95 % braucht, hat eine zu erwartende Obergrenze von etwa 99,94 %, noch bevor Ihr eigener Code und Ihre Deployments eingerechnet sind.

Um über das hinauszukommen, was ein einzelner Dienst bietet, entwerfen Sie für den Ausfall:

• Betreiben Sie Compute in mindestens zwei Availability Zones hinter einem Load Balancer;
• nutzen Sie Multi-AZ-Deployments für Datenbanken;
• automatisieren Sie die Wiederherstellung und testen Sie sie, einschließlich Backup-Restores;
• erwägen Sie für die kritischsten Systeme eine zweite Region mit getestetem Failover-Plan.

Die Säule Reliability des AWS Well-Architected Framework behandelt diese Muster im Detail. Unser Leitfaden zu Cloud-SLAs im Allgemeinen erklärt, wie Sie Zusagen verschiedener Anbieter vergleichen, und der Artikel zum Azure SLA behandelt das Pendant von Microsoft.

Beispiel: Multi-AZ-Design in der Praxis

Als Opsio die schwedische Skigebietsgruppe Branäsgruppen von VMware auf AWS migrierte, wurden kritische Anwendungen mit Auto Scaling und verwalteten Datenbanken auf mehrere Availability Zones verteilt, um den Datenverkehr der Hochsaison zu bewältigen. Die Fallstudie nennt nach der Migration eine Anwendungsverfügbarkeit von über 99,9 % und eine Senkung der Gesamtbetriebskosten (TCO) um 40 %.

AWS SLAs im Vergleich zum SLA eines Managed Service Providers

Ein AWS SLA deckt die Plattform ab. Das SLA eines Managed Service Providers deckt die Arbeit darauf ab: wie schnell jemand auf einen Alarm reagiert, wie schnell er mit der Behebung beginnt und welche Verfügbarkeit er für die von ihm betriebene Umgebung zusagt. Beide ergänzen einander. Das Standard-SLA von Opsio für Cloud Managed Services enthält zum Beispiel eine Triage kritischer Alarme innerhalb von 15 Minuten und eine aktive Behebung innerhalb von 1 Stunde, mit Service Credits, falls Reaktionszeiten verfehlt werden. Lesen Sie das SLA jedes Anbieters, auch unseres auf der Opsio-Seite zum Cloud SLA, so wie Sie das von AWS lesen: was gemessen wird, wie, und was Sie bei einer Verfehlung erhalten.

Häufig gestellte Fragen

Welche Verfügbarkeit sichert das AWS SLA zu?

Das hängt vom Dienst ab. EC2 sagt 99,99 % pro Region für Instanzen in zwei oder mehr Availability Zones zu und 99,5 % pro einzelne Instanz. RDS Multi-AZ und Lambda sagen 99,95 % zu. Bei S3 Standard beginnen die Gutschriften, wenn die Verfügbarkeit unter 99,9 % fällt.

Garantiert AWS 100 % Verfügbarkeit?

Nein. Kein AWS-Dienst-SLA verspricht 100 %. Die höchste übliche Zusage ist 99,99 %, was in einem Monat mit 30 Tagen immer noch rund vier Minuten Ausfallzeit erlaubt. Höhere Verfügbarkeit muss aus Ihrer eigenen Architektur kommen.

Was geschieht, wenn AWS sein SLA nicht einhält?

Sie können einen Service Credit von 10 % bis 100 % der monatlichen Gebühren des betroffenen Dienstes beantragen, je nachdem, wie tief die Verfügbarkeit gefallen ist. Gutschriften werden auf künftige Rechnungen angerechnet, nicht bar ausgezahlt und sind Ihr einziger Rechtsbehelf, sofern Ihre Vereinbarung nichts anderes sagt.

Wie lange habe ich Zeit, einen SLA-Credit bei AWS zu beantragen?

Bei EC2 und S3 muss AWS Ihren Antrag bis zum Ende des zweiten Abrechnungszyklus nach dem Vorfall erhalten. Sie reichen ihn als Fall im AWS Support Center mit dem im SLA vorgegebenen Betreff ein.

Gehört die Reaktionszeit des AWS Supports zum SLA?

Nein. Reaktionszeiten gehören zu Ihrem AWS-Support-Plan und werden als Ziele beschrieben. Dienst-SLAs decken nur die Verfügbarkeit ab, und nur Dienst-SLAs gewähren Gutschriften.

Sind alle AWS-Dienste durch ein SLA abgedeckt?

AWS gibt an, SLAs für alle kostenpflichtigen, allgemein verfügbaren Dienste anzubieten. Dienste in der Preview sind nicht abgedeckt, und jeder Dienst hat eigene Bedingungen. Prüfen Sie daher für jeden Dienst, von dem Ihre Anwendung abhängt, die jeweilige SLA-Seite.

Weiterführende Artikel

• Was ist das Azure SLA? Ein praktischer Leitfaden zu Zuverlässigkeit und Verfügbarkeit in Azure
• Was ist ein Azure SLA und warum ist es so wichtig?
• Cloud-Computing-SLAs erklärt