AWSのSLA（サービスレベルアグリーメント）は、AWS全体で1本ではなく、EC2やS3、RDSといったサービスごとに別の文書で定められています。EC2は2つ以上のアベイラビリティーゾーン（AZ）に配置したときに月間稼働率99.99%、単一のインスタンスでは99.5%が保証の水準です。この記事では、主要サービスのSLAの数値とクレジット率を各文書の原文から整理し、構成全体の複合SLAをPythonで計算する方法、サービスクレジットの申請手順と期限、対象外になる条件までを扱います。数値は2026年10月1日時点で各SLAページを確認したものです。
まとめ：AWSのSLAで確認すべき保証値・適用条件・申請期限の3点
AWSのSLAが約束するのは、稼働率を下回ったときに翌月以降の利用料から差し引くサービスクレジットです。停止による売上の損失は補償されません。
読むべき箇所は3つあります。1つ目はサービスごとの保証値で、EC2・EBS・ELB・ECSは複数AZ構成で99.99%、RDSのマルチAZは99.95%、S3 Standardは99.9%です。2つ目は適用条件で、単一AZの構成は低い保証値の側に入ります。3つ目は申請期限で、障害が起きた請求サイクルの2つ後のサイクルが終わるまでに、ログを添えて自分で申請しなければクレジットは付きません。
サービスを直列につなぐと、構成全体の稼働率は各SLAの掛け算で下がります。ALB・Fargate・RDSマルチAZの構成では99.93%前後になり、月30分程度の停止がSLAの範囲内に収まる計算です。
AWSのSLAはサービスごとに別文書で定める契約上の稼働率保証
AWSの各サービスには「Service Level Agreement」というページがあり、AWSカスタマーアグリーメントに優先する個別の取り決めとして読みます。
AWSのSLAが約束するのは無停止でなく未達時のサービスクレジット返還
Amazon Compute Service Level Agreementは、AWSが「商業的に合理的な努力」で稼働率を保つと書いたうえで、未達のときの唯一の救済をサービスクレジットと定めています。クレジットは翌月以降のEC2の支払いにだけ充当され、別のアカウントへは移せません。1請求サイクルのクレジットが1ドルを超えない場合は付与されない点も条文にあります。
つまりSLAは、障害の損失を埋める保険ではありません。利用料の一部が戻るだけで、停止を許容できるかどうかはSLAの数値ではなく自社の構成で決まります。SLA・SLO・SLIの関係そのものはSLAとSLO・SLIの違いと稼働率の決め方で整理しています。
月間稼働率の数え方はサービスごとに違い5分間隔や1分単位で判定
稼働率の分母と判定の単位は、各サービスの文書ごとに異なる定義です。Amazon S3のSLAは、5分ごとに「内部エラーの件数÷リクエスト総数」でエラー率を出し、その平均を100%から引いた値を月間稼働率とします。EC2は、外部との通信ができない状態を「利用不可」として時間で数えます。
Amazon EKSのSLAは2026年3月20日に改定され、標準のコントロールプレーンは5分間隔で99.95%、Provisioned Control Planeは1分間隔で99.99%という2本立てになりました。同じ99.99%でも判定の粒度が違うため、短い瞬断が数に入るかどうかが変わります。英語版が正本で、EC2には日本語の参考訳（2022年5月25日版）もあります。
主要AWSサービスのSLA一覧と99.99%が適用されるマルチAZの条件
ここでは、Webシステムでよく組み合わせるサービスの保証値と、最も軽い段階のクレジット率を並べます。
EC2・EBS・ELB・ECSは2つ以上のAZへの配置で99.99%の対象
| サービス | 複数AZ・リージョン単位 | 単体（1台・1ボリューム等） | クレジット率の段階 |
|---|---|---|---|
| EC2 | 99.99% | 99.5% | 10%・30%・100% |
| EBS | 99.99% | 99.9% | 10%・30%・100% |
| ELB（ALB・NLB等） | 99.99% | 99.9% | 10%・30%・100% |
| ECS・Fargate | 99.99% | 99.5%（タスク・Pod単位） | 10%・25%・100% |
| RDS | 99.95%（マルチAZ） | 99.5%（シングルAZ） | 10%・25%・100% |
EC2のリージョン単位のSLAで「利用不可」と数えられるのは、同じリージョンの2つ以上のAZに配置した稼働中のインスタンスが、すべて外部と通信できなくなった場合です。1つのAZにしか置いていなければ、AZ全体が止まってもこの99.99%の対象にはなりません。Elastic Load BalancingのSLAとECS・FargateのSLAも、複数AZへの配置を99.99%の条件にしています。EBSのSLAはリージョン単位と1ボリューム単位の2本です。
クレジット率の段階は、EC2・EBS・ELBが「99.0%以上で10%、95.0%以上で30%、95.0%未満で100%」、ECS・RDSは中間が25%です。ロードバランサーの種類ごとの違いはELBとALBの違いと4種類の使い分けを参照してください。
単一インスタンスは99.5%で月216分の停止まで保証の範囲内
EC2のインスタンス単位のSLAは99.5%です。30日の月なら216分、3時間半を超える停止まではクレジットの対象になりません。Amazon RDSのSLAも、シングルAZのDBインスタンスは同じ99.5%です。
EC2には別の規定もあります。1台のインスタンスが1時間のうち6分を超えて利用不可になった場合、その1時間分は申請しなくても課金されません。ただしリージョン単位とインスタンス単位の申請は、同じインスタンスについて重ねて行えない決まりです。マルチAZ構成のRDSの仕組みはAmazon RDSの仕組みと構築手順で解説しています。
S3・Lambda・DynamoDB・EKS・Route 53の種別・構成別の保証値
| サービス | 保証値 | 条件 |
|---|---|---|
| S3 | 99.9% | Standard等（注1） |
| S3 | 99.0% | 低頻度アクセス系等（注2） |
| Lambda | 99.95% | リージョン単位 |
| DynamoDB | 99.99%・99.999% | 標準テーブル・グローバルテーブル |
| EKS | 99.95%・99.99% | 標準・事前確保型（注3） |
| Route 53 | 100% | ホストゾーン単位（クレジットはクエリ料金が対象） |
表の注1はStandard・Express One Zone・Glacier Flexible Retrieval等、注2はIntelligent-Tiering・Standard-IA・One Zone-IA・Glacier Instant Retrievalを指します。注3の事前確保型はProvisioned Control Planeのことで、EKSの標準と区別した表記です。
S3は低頻度アクセス系のストレージクラスほど保証値が下がり、99.0%を下回って初めて10%のクレジットになります。LambdaのSLAは99.95%、DynamoDBのSLAはグローバルテーブルにすると99.999%へ上がります。
Route 53のSLAは100%ですが、クレジットの対象はホストゾーンのクエリ料金だけです。月に数ドルのクエリ料金しか払っていなければ、戻る額も数ドルにとどまります。保証値の高さとクレジットの額は別物です。
構成全体の複合SLAをPythonで計算し月間の許容停止時間を出す
利用者から見た稼働率は、通り道にあるサービスのどれか1つが止まれば下がります。個々のSLAより、つないだ結果の数値で判断します。
直列につながるサービスの稼働率は掛け算で下がる複合SLAの考え方
DNS、ロードバランサー、アプリケーション、データベースの順にリクエストが通る構成では、すべてが動いている確率が全体の稼働率です。各SLAの値を小数にして掛け合わせると、構成全体が保証として期待できる下限の目安になります。99.99%を2つ、99.95%を1つ掛けると99.93%で、最も低いRDSの99.95%よりさらに下がります。
逆に、同じ役割のものを並列に置けば稼働率は上がります。並列の計算式と冗長化の一般論は可用性の計算と高可用性の設計にまとめています。
公開SLA値からクレジット率まで求めるPythonの計算コード
次のコードは、各サービスのSLA値とクレジット表を入れて、許容停止時間と複合値、障害時のクレジット率を出します。標準ライブラリだけで動きます。
# AWSの公開SLA値から、構成全体の複合稼働率と月間の許容停止時間、サービスクレジット率を計算する
from math import prod
MINUTES_30D = 30 * 24 * 60 # 30日の月を基準にする
# (名前, SLAの月間稼働率%, クレジット表[(下限%, 率%)]) ※2026-10-01時点の各SLAページから転記
services = [
("Route 53 hosted zone", 100.0, [(99.99, 10), (99.95, 25), (0, 100)]),
("ALB (Multi-AZ)", 99.99, [(99.0, 10), (95.0, 30), (0, 100)]),
("ECS on Fargate (Multi-AZ)", 99.99, [(99.0, 10), (95.0, 25), (0, 100)]),
("RDS (Multi-AZ)", 99.95, [(99.0, 10), (95.0, 25), (0, 100)]),
]
def credit_rate(uptime, sla, table):
"""実測の月間稼働率から、SLAに定められたクレジット率（%）を返す"""
if uptime >= sla:
return 0
for lower, rate in table:
if uptime >= lower:
return rate
return 100
for name, sla, _ in services:
allowed = MINUTES_30D * (100 - sla) / 100
print(f"{name:28s} SLA {sla:7.3f}% 許容停止 {allowed:6.1f} 分/月")
composite = prod(sla / 100 for _, sla, _ in services) * 100
print(f"{'直列の複合値':26s} {composite:7.3f}% 許容停止 {MINUTES_30D * (100 - composite) / 100:6.1f} 分/月")
# 例: RDSが月に45分止まった場合のクレジット
down = 45
uptime = 100 - down / MINUTES_30D * 100
name, sla, table = services[3]
print(f"{name}: 停止{down}分 → 稼働率 {uptime:.3f}% → クレジット {credit_rate(uptime, sla, table)}%")
# 出力（2026-10-01に実行）
# Route 53 hosted zone SLA 100.000% 許容停止 0.0 分/月
# ALB (Multi-AZ) SLA 99.990% 許容停止 4.3 分/月
# ECS on Fargate (Multi-AZ) SLA 99.990% 許容停止 4.3 分/月
# RDS (Multi-AZ) SLA 99.950% 許容停止 21.6 分/月
# 直列の複合値 99.930% 許容停止 30.2 分/月
# RDS (Multi-AZ): 停止45分 → 稼働率 99.896% → クレジット 10%RDSが月に45分止まっても、クレジットはRDS利用料の10%です。月の利用料が500ドルなら50ドルが翌月以降に充当されるだけで、45分間の受注停止の損失とは桁が合いません。この差を見せることが、構成の冗長化に予算を割く根拠になります。
サービスクレジットの申請手順と請求期限・障害時に必要な証跡の準備
AWSのSLAクレジットは、障害が起きても自動では付きません。EC2の「1時間に6分超」の規定を除き、利用者が申請して初めて審査されます。
Support Centerで件名を指定し2請求サイクル以内に申請する流れ
Compute SLAの申請手続きでは、AWS Support Centerでケースを作成し、障害が起きた請求サイクルの2つ後のサイクルが終わるまでに届くように出すと定めています。
- 件名に「Amazon Compute SLA Credit Request – Region-Level Claim」（インスタンス単位なら末尾が Instance-Level Claim）を入れる
- 利用不可だった日時と、影響を受けたリージョン（インスタンス単位ならAZも）を書く
- 影響を受けたリソースIDを並べる
- 障害を裏付けるリクエストログを添付する
SLA本文が求めているのはSupport Centerでのケース作成で、サポートプランの条件は書かれていません。AWS Supportのケース管理によれば、Basicプランでは技術サポートのケースを作れない一方、アカウントと請求のケースは全利用者が作成できます。9月の障害なら11月の請求サイクル末までが期限です。
申請に添えるリクエストログと障害時刻をCLIで残しておく方法
審査で使われるのは、利用者側のログとAWS側の障害記録の両方です。ALBのアクセスログやアプリケーションのエラーログは、保存期間を最低でも3か月にしておかないと、期限内に申請しても証跡が足りなくなります。
# 東京リージョンで発生したEC2の障害イベントを、AWS Healthから期間指定で取得する
# （Health APIはus-east-1のエンドポイントで呼ぶ。対象サポートプランが必要）
aws health describe-events --region us-east-1 \
--filter "services=EC2,regions=ap-northeast-1,eventTypeCategories=issue,startTimes=[{from=2026-09-01T00:00:00Z,to=2026-09-30T23:59:59Z}]" \
--query "events[].[arn,eventTypeCode,startTime,endTime,statusCode]" \
--output tableAWS Health APIはBusiness Support+、Enterprise Support、Unified Operationsのいずれかのプランが必要で、対象外のアカウントで返るエラーは SubscriptionRequiredException です。describe-eventsで取ったイベントのARNと時刻を申請文に書けば、AWS側の記録と照合しやすくなります。EventBridgeで障害通知を自動で残す設定はAWS Health Dashboardの通知自動化で扱っています。
クレジットの対象外になる除外条項とユーザーの操作・設定に起因する停止
Compute SLAの除外条項には、不可抗力、AWSの責任範囲外のインターネット接続の問題、利用者の操作や設定、利用者側の機器やソフトウェアによる停止、契約に基づく利用停止が並びます。セキュリティグループの設定ミスでの通信断や、アプリケーションの不具合による応答停止は、AWSのSLAでは数えられません。
実際の申請で多いのは、アプリのエラーを障害と思い込んで出してしまう失敗です。AWS Healthにイベントが無く、自社のログにもAWS側のエラー（S3なら InternalError や ServiceUnavailable）が残っていない場合は、申請しても通らないと考えてください。
AWSのSLAを自社サービスの顧客向けSLAへそのまま転記しない判断
受託開発や自社SaaSの契約でSLAを書くとき、AWSの数値を根拠にしたくなります。転記は避けるべきです。
AWSのSLA値を顧客向けSLAに書いてはいけない理由と差の埋め方
AWSが保証するのは個々のサービスの稼働率で、その上で動くアプリケーション、デプロイ作業、外部APIの停止は含まれません。ALB・Fargate・RDSマルチAZの複合値が99.93%なら、アプリ側の停止を足した実際の稼働率はそれより下がります。顧客向けには99.9%（月43分）程度から始め、計画メンテナンスを分母から除く条件を書くのが現実的です。
差を埋める手段は、AWSのSLAではなく自社の構成と運用です。RDSをAuroraに替えてフェイルオーバーを短くする、リージョン切り替えをApplication Recovery Controllerの機能と料金で組むといった対策を、停止コストと比べて選びます。顧客と合意するSLAの水準からAWSの構成を逆算したい場合は、AWS・Google Cloud・Azureのインフラ構築でご相談ください。
マルチリージョンまで進むべき条件と99.99%で止めてよい場面
マルチAZ構成の99.99%は、1つのAZの障害には耐えますが、東京リージョン全体の障害には耐えません。リージョンをまたいだ構成に進むべきなのは、1時間の停止で失う売上や違約金が、2リージョン分のインフラ費と運用工数を上回る場合です。決済や予約など止まると直接売上が消える業務がこれに当たります。
社内向けの業務システムや、夜間に止まっても翌朝の業務で取り戻せるシステムなら、マルチAZで止めてよいと判断します。災害対策としての置き場所の考え方はBCP対策の責任分界とSLAで決める判断基準が参考になります。
よくある質問
AWSのSLAについて、設計と契約の場面でよく出る質問に答えます。
AWSのSLAの一覧はどこで確認できますか？
AWSの各サービスのページに「SLA」のリンクがあり、URLは「aws.amazon.com」のあとにサービス名と「sla」が続く形式です。EC2は「compute」、ECSとFargateは「ecs」のページにまとまっています。各文書の冒頭に「Last Updated」の日付があるので、引用するときは日付も控えてください。EKSのように2026年に改定された文書もあり、数年前の一覧記事の数値は古くなっていることがあります。
EC2を1台だけで動かした場合のSLAはいくつですか？
インスタンス単位のSLAで99.5%です。30日の月なら216分までの停止は保証の範囲内で、それを下回った場合にそのインスタンスの料金の10%以上がクレジットになります。これとは別に、1時間のうち6分を超えて利用不可だった時間は申請なしで課金されません。リージョン単位の99.99%を受けるには、2つ以上のAZにインスタンスを置く必要があります。
SLAを下回ったら返金されますか？
現金の返金ではなく、翌月以降の同じサービスの支払いに充当されるクレジットです。AWSの判断で、障害があった請求サイクルの支払いに使ったクレジットカードへ戻す場合もあると条文に書かれています。いずれも申請が必要で、障害のあった請求サイクルの2つ後のサイクルが終わるまでに、件名・日時・リソースID・ログをそろえてSupport Centerに出します。
SLAのクレジット申請にサポートプランの契約は必要ですか？
SLAの条文はSupport Centerでのケース作成を求めているだけで、プランの条件は書かれていません。アカウントと請求のケースはBasicプランを含む全利用者が作成できます。ただし障害時刻を取りにいくAWS Health APIはBusiness Support+以上が必要です。旧Business Supportは2027年1月1日で提供を終え、Business Support+はアカウントあたり月29ドルからとAWS Supportの説明にあります。
S3の耐久性99.999999999%とSLAの稼働率は何が違いますか？
耐久性は保存したデータが失われない確率の設計目標で、S3のストレージクラスの説明に「11 nines」として書かれていますが、S3のSLAには含まれていません。SLAが扱うのは稼働率、つまりリクエストが内部エラーで失敗しなかった割合です。S3 Standardの稼働率の保証は99.9%で、5分ごとのエラー率の平均で判定します。データが消えないことと、いつでも読み書きできることは別に設計する必要があります。
関連記事
- SLAとは？SLO・SLIとの違いと稼働率の決め方・監視実装をエンジニア視点で解説：SLAという仕組みそのものの解説
- 可用性とは？稼働率の計算と高可用性の設計をインフラ実装目線で解説【2026年版】：直列・並列の稼働率計算と冗長化
- AWS Health Dashboardの使い方｜障害通知の自動化とAPI実装：クレジット申請の証跡になる障害イベントの取得
- SLOとは？SLA・SLIとの違いと設定方法をわかりやすく解説：顧客向けSLAの手前に置く内部目標
- Amazon RDSとは？仕組み・対応エンジン・料金とAWS CLIでの構築手順を実装者目線で解説：99.95%の対象になるマルチAZ構成
