AWS SLA (umowa o poziomie usług, service level agreement) to zobowiązanie dostępności, które Amazon Web Services publikuje dla każdej usługi, wraz z kredytami usługowymi na wypadek jego niedotrzymania. Na przykład Amazon EC2 zobowiązuje się do 99,99% miesięcznej dostępności w regionie dla instancji rozłożonych na co najmniej dwie strefy dostępności (Availability Zones). Jeśli AWS tego nie dotrzyma, przyzna kredyt na przyszły rachunek; nie pokryje utraconych przychodów.
Najważniejsze wnioski
- AWS deklaruje, że oferuje SLA dla wszystkich płatnych usług dostępnych ogólnie (generally available). Każda usługa ma własną stronę SLA z własnym procentem dostępności i progami kredytów.
- Typowe zobowiązania: EC2 99,99% w regionie (multi-AZ) i 99,5% na instancję, RDS Multi-AZ 99,95%, Lambda 99,95%, a próg kredytów dla S3 Standard to 99,9%.
- Rekompensatą są kredyty usługowe w wysokości 10%, 25% lub 30% oraz 100% miesięcznych opłat za dotkniętą usługę, w zależności od tego, jak nisko spadła dostępność. SLA jest Twoim jedynym i wyłącznym środkiem zaradczym.
- Kredyty nie są automatyczne. Zgłaszasz sprawę w AWS Support Center, a zgłoszenie musi dotrzeć do końca drugiego cyklu rozliczeniowego po incydencie.
- SLA obejmuje infrastrukturę AWS, a nie Twoją aplikację. Dostępność Twojego systemu zależy od tego, jak zaprojektujesz go w strefach dostępności i regionach.
Czym jest umowa o poziomie usług AWS?
To krótki dokument prawny, który wyznacza mierzalny cel dostępności dla jednej usługi AWS oraz kredyt, jaki AWS Ci przyznaje, gdy go nie osiągnie. AWS wymienia je wszystkie na stronie Service Level Agreements, pogrupowane według kategorii, od analityki po przestrzeń dyskową, i deklaruje, że zobowiązuje się oferować SLA „dla wszystkich płatnych usług dostępnych ogólnie". Funkcje w wersji podglądowej (preview) i bezpłatne nie są więc objęte.
Każde SLA usługi ma ten sam układ:
- Zobowiązanie usługowe: miesięczny procent dostępności, mierzony w sposób zdefiniowany dla danej usługi (na przykład łączność zewnętrzna dla EC2 lub odsetek błędów żądań dla S3).
- Tabela kredytów: procent opłat za dany miesiąc, który odzyskujesz jako kredyt dla każdego przedziału niedotrzymanej dostępności.
- Procedura zgłoszenia: jak i do kiedy poprosić o kredyt.
- Wyłączenia: przyczyny przestoju, które się nie liczą, takie jak Twoja własna konfiguracja lub zdarzenia poza uzasadnioną kontrolą AWS.
Procenty dostępności i progi kredytów dla kluczowych usług AWS
Poniższa tabela korzysta z danych ze strony SLA każdej usługi według stanu na październik 2026 r. AWS od czasu do czasu aktualizuje te strony, więc przed oparciem umowy na jakiejś liczbie sprawdź datę „last updated" na stronie.
| Usługa i zakres | Miesięczne zobowiązanie dostępności | Kredyt usługowy w razie niedotrzymania | Ostatnia aktualizacja strony SLA |
|---|---|---|---|
| Amazon EC2, poziom regionu (instancje w 2+ AZ w jednym regionie) | 99,99% | 10% poniżej 99,99%; 30% poniżej 99,0%; 100% poniżej 95,0% | 25 maja 2022 |
| Amazon EC2, poziom instancji (każda pojedyncza instancja) | 99,5% | 10% poniżej 99,5%; 30% poniżej 99,0%; 100% poniżej 95,0% | 25 maja 2022 |
| Amazon S3 Standard, Express One Zone, Glacier Flexible Retrieval, Glacier Deep Archive | Kredyty zaczynają się poniżej 99,9% | 10% poniżej 99,9%; 25% poniżej 99,0%; 100% poniżej 95,0% | 28 listopada 2023 |
| Amazon S3 Intelligent-Tiering, Standard-IA, One Zone-IA, Glacier Instant Retrieval | Kredyty zaczynają się poniżej 99,0% | 10% poniżej 99,0%; 25% poniżej 98,0%; 100% poniżej 95,0% | 28 listopada 2023 |
| Amazon RDS, instancja lub klaster Multi-AZ | 99,95% | 10% poniżej 99,95%; 25% poniżej 99,0%; 100% poniżej 95,0% | 22 stycznia 2024 |
| Amazon RDS, instancja Single-AZ | 99,5% | 10% poniżej 99,5%; 25% poniżej 99,0%; 100% poniżej 95,0% | 22 stycznia 2024 |
| AWS Lambda, w regionie | 99,95% | 10% poniżej 99,95%; 25% poniżej 99,0%; 100% poniżej 95,0% | 5 maja 2022 |
Źródła: Amazon Compute SLA, Amazon S3 SLA, Amazon RDS SLA i AWS Lambda SLA. Zwróć uwagę, że środkowy przedział kredytu dla EC2 to 30%, podczas gdy S3, RDS i Lambda stosują 25%. Starsze zestawienia, które podają jedną tabelę dla wszystkich usług, są błędne.
Co oznaczają te procenty w minutach
W 30-dniowym miesiącu (43 200 minut) zobowiązania dopuszczają mniej więcej taki przestój, zanim zaczną obowiązywać kredyty:
- 99,99%: około 4,3 minuty
- 99,95%: około 21,6 minuty
- 99,9%: około 43,2 minuty
- 99,5%: około 3,6 godziny
Dlatego wartość regionalna dla EC2 obowiązuje tylko wtedy, gdy uruchamiasz instancje w co najmniej dwóch strefach dostępności. Pojedyncza instancja podlega zobowiązaniu 99,5% na poziomie instancji, które dopuszcza miesięcznie godziny, a nie minuty przestoju.
Jak działają kredyty usługowe AWS?
Kredyt usługowy to procent tego, co zapłaciłeś za dotkniętą usługę w dotkniętym zakresie w danym miesiącu. Dla EC2 na poziomie regionu jest to procent miesięcznego rachunku za EC2 w tym regionie, z wyłączeniem płatności jednorazowych, takich jak opłaty z góry za Reserved Instances. W przypadku zgłoszenia na poziomie instancji jest to procent rachunku za tę jedną instancję.
Przykład obliczeń: wydajesz 8 000 USD miesięcznie na EC2 w eu-north-1 (Sztokholm), a dostępność na poziomie regionu dla Twoich instancji multi-AZ wynosi 99,95%. To mniej niż 99,99%, ale więcej niż 99,0%, więc kredyt wynosi 10%, czyli 800 USD, zaliczane na poczet przyszłych płatności za EC2.
Inne zasady z SLA dla EC2, które zaskakują użytkowników:
- Kredyty zaliczane są na poczet przyszłych płatności za tę samą usługę. Nie dają prawa do zwrotu ani wypłaty gotówki.
- AWS przyznaje kredyt tylko wtedy, gdy jest wart więcej niż 1 USD za dany cykl rozliczeniowy.
- Dla instancji możesz zgłosić roszczenie na podstawie SLA regionalnego albo SLA na poziomie instancji, nie obu.
- SLA jest Twoim „jedynym i wyłącznym" środkiem zaradczym na niedostępność, chyba że Twoja umowa z AWS stanowi inaczej.
Jak zgłosić kredyt usługowy w AWS
- Zbierz dowody. Zapisz daty i godziny incydentu, dotknięty region (oraz strefę dostępności przy zgłoszeniach na poziomie instancji), identyfikatory zasobów i logi pokazujące awarię. Zanonimizuj dane wrażliwe.
- Otwórz sprawę w AWS Support Center. Użyj tematu, którego wymaga SLA. Dla EC2 jest to „Amazon Compute SLA Credit Request – Region-Level Claim" lub „– Instance-Level Claim"; dla S3 temat musi zawierać „SLA Credit Request".
- Zgłoś w terminie. W przypadku EC2 i S3 AWS musi otrzymać zgłoszenie do końca drugiego cyklu rozliczeniowego po incydencie.
- Śledź wynik. AWS potwierdza, czy przestój się kwalifikuje, i zalicza kredyt na późniejszą fakturę.
Zespoły prowadzące wiele kont często tracą kredyty, bo nikt nie odpowiada za ten proces. Jeśli współpracujesz z dostawcą usług zarządzanych, uwzględnij obsługę zgłoszeń w umowie.
Czego AWS SLA nie obejmują?
Wyłączenia są podobne w różnych usługach. Przestój nie liczy się do SLA, jeśli jest spowodowany przez:
- czynniki poza uzasadnioną kontrolą AWS, w tym problemy z internetem poza brzegiem sieci AWS;
- Twoje własne działania lub zaniechania, takie jak ignorowanie powiadomień o stanie lub błędna konfiguracja zasobów;
- Twój własny sprzęt, oprogramowanie lub inną technologię;
- zawieszenie lub zakończenie przez AWS Twojego korzystania z usługi zgodnie z umową.
Z SLA często mylone są jeszcze dwie rzeczy:
- Wydajność. Podstawowe SLA mierzą dostępność (łączność lub odsetek błędów), a nie opóźnienia czy przepustowość. Usługa wolna, ale osiągalna, zasadniczo nie jest „niedostępna".
- Czasy reakcji wsparcia. Należą do Twojego planu AWS Support, a nie do SLA usługi, i AWS opisuje je jako cele, które dołoży „wszelkich uzasadnionych starań", by spełnić. Obecne plany podają na przykład poniżej godziny dla zgłoszenia awarii systemu produkcyjnego w Business Support+ i poniżej 15 minut dla zgłoszenia awarii systemu krytycznego dla biznesu w Enterprise Support. Ich niedotrzymanie nie uruchamia kredytów usługowych.
Dlaczego dostępność Twojej aplikacji to Twoja odpowiedzialność
SLA mówi, co AWS obiecuje dla jednej usługi. Twoi użytkownicy doświadczają całego łańcucha: load balancera, mocy obliczeniowej, bazy danych, przestrzeni dyskowej, DNS i Twojego własnego kodu. Jeśli każdy element zawodzi niezależnie, dostępność łańcucha jest w przybliżeniu iloczynem dostępności elementów. Aplikacja, która potrzebuje EC2 na poziomie 99,99% i bazy RDS Multi-AZ na poziomie 99,95%, ma oczekiwany pułap około 99,94%, zanim doliczysz własny kod i wdrożenia.
Aby przekroczyć to, co oferuje pojedyncza usługa, projektuj z myślą o awariach:
- uruchamiaj moc obliczeniową w co najmniej dwóch strefach dostępności za load balancerem;
- używaj wdrożeń Multi-AZ dla baz danych;
- automatyzuj odtwarzanie i je testuj, w tym przywracanie kopii zapasowych;
- dla najbardziej krytycznych systemów rozważ drugi region z przetestowanym planem przełączenia awaryjnego.
Filar Reliability w AWS Well-Architected Framework opisuje te wzorce szczegółowo. Nasz przewodnik po umowach SLA w chmurze w ogólności wyjaśnia, jak porównywać zobowiązania różnych dostawców, a artykuł o Azure SLA omawia odpowiednik Microsoftu.
Przykład: projekt multi-AZ w praktyce
Gdy Opsio przenosiło szwedzką grupę ośrodków narciarskich Branäsgruppen z VMware do AWS, krytyczne aplikacje umieszczono w wielu strefach dostępności z automatycznym skalowaniem i zarządzanymi bazami danych, aby obsłużyć ruch w sezonie szczytowym. Studium przypadku podaje dostępność aplikacji na poziomie 99,9%+ i 40% redukcję całkowitego kosztu posiadania po migracji.
AWS SLA a SLA dostawcy usług zarządzanych
AWS SLA obejmuje platformę. SLA dostawcy usług zarządzanych obejmuje pracę wykonywaną na jej szczycie: jak szybko ktoś reaguje na alert, jak szybko zaczyna naprawę i jaką dostępność gwarantuje dla środowiska, które prowadzi. Oba uzupełniają się nawzajem. Na przykład standardowe SLA zarządzanych usług chmurowych Opsio obejmuje 15-minutową triage alertów krytycznych i 1 godzinę aktywnej naprawy, z kredytami usługowymi w razie niedotrzymania czasów reakcji. Szczegóły SLA każdego dostawcy, w tym naszego na stronie Opsio cloud SLA, czytaj tak samo jak SLA AWS: co jest mierzone, jak i co otrzymujesz, gdy zobowiązanie nie zostanie dotrzymane.
Najczęściej zadawane pytania
Jaka jest dostępność w AWS SLA?
Zależy od usługi. EC2 zobowiązuje się do 99,99% w regionie dla instancji w dwóch lub więcej strefach dostępności i 99,5% dla pojedynczej instancji. RDS Multi-AZ i Lambda zobowiązują się do 99,95%. Kredyty dla S3 Standard zaczynają się, gdy dostępność spadnie poniżej 99,9%.
Czy AWS gwarantuje 100% dostępności?
Nie. Żadne SLA usługi AWS nie obiecuje 100%. Najwyższe powszechne zobowiązanie to 99,99%, co nadal dopuszcza około czterech minut przestoju w 30-dniowym miesiącu. Wyższą dostępność musi zapewnić Twoja własna architektura.
Co się stanie, jeśli AWS nie dotrzyma swojego SLA?
Możesz zgłosić kredyt usługowy w wysokości od 10% do 100% miesięcznych opłat za dotkniętą usługę, w zależności od tego, jak nisko spadła dostępność. Kredyty dotyczą przyszłych rachunków, nie są wypłacane w gotówce i są Twoim jedynym środkiem zaradczym, chyba że Twoja umowa stanowi inaczej.
Ile mam czasu na zgłoszenie kredytu SLA w AWS?
W przypadku EC2 i S3 AWS musi otrzymać zgłoszenie do końca drugiego cyklu rozliczeniowego po incydencie. Zgłaszasz je jako sprawę w AWS Support Center z tematem określonym w SLA.
Czy czas reakcji AWS Support jest częścią SLA?
Nie. Czasy reakcji należą do Twojego planu AWS Support i są opisane jako cele. SLA usług obejmują wyłącznie dostępność i tylko SLA usług dają kredyty.
Czy wszystkie usługi AWS są objęte SLA?
AWS deklaruje, że oferuje SLA dla wszystkich płatnych usług dostępnych ogólnie. Usługi w wersji podglądowej nie są objęte, a każda usługa ma własne warunki, więc sprawdź konkretną stronę SLA dla każdej usługi, od której zależy Twoja aplikacja.
Powiązane artykuły
Autor

Dyrektor ds. Innowacji
Jacob kieruje innowacjami w Opsio, specjalizując się w transformacji cyfrowej, AI, IoT i rozwiązaniach opartych na chmurze, które przekształcają skomplikowaną technologię w mierzalną wartość biznesową. Z prawie 15-letnim doświadczeniem ściśle współpracuje z klientami przy projektowaniu skalowalnych rozwiązań AI i IoT, optymalizacji procesów dostaw i tworzeniu strategii technologicznych, które napędzają trwały wzrost i długoterminowy wpływ biznesowy.
Zasady redakcyjne: Artykuł napisał wskazany powyżej specjalista od chmury. Aktualizujemy go, gdy zmienia się opisywana technologia lub regulacja; daty na tej stronie pokazują ostatnią aktualizację. Opsio zachowuje niezależność redakcyjną.