13
11

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

AWSのSLAについて覗いてみよう

Last updated at Posted at 2025-09-28

はじめ

ITサービスを使用するとき、SLA意識していますか?
もちろん、個人で、プライベートとしてITサービスを使用するときに意識するなんてことはほぼほぼ無いように思います。

しかし、業務として、企業として使用するとき、SLAは意識する必要があります。
業務で使っているITサービスが突然使えなくなってしまい、さらにエンドユーザーに提供しているサービスが止まってしまう...なんてことになったら大変ですからね。

この記事を読んでいる方は、きっと毎分1億以上の利益をもたらすサービスを運用されているでしょうから、たかだか30分のサービス停止であっても被害は甚大です。

自分たちが運用しているシステムであれば、そういった被害を受けないよう、例えば冗長化しておく、分散しておくなどの対策が考えられます。
ただ、自分たちが運用していない、利用者であるサービスの場合、そのサービスを直接制御することはできません。

ではどうするか?
SLAに照らして、それが実際の利用に足るか?を考えることが多い印象です。

本記事では、SLAに注目しつつ、それがAWSではどう定義されているかをいくつかの例でみていこうと思います。

SLAとその周辺

SLAとは

AWSでは、SLAは以下のように説明されています。

サービスレベルアグリーメント (SLA) とは何ですか?

サービスレベルアグリーメント (SLA) は、サプライヤーが顧客に提供することを約束するサービスのレベルの概要を規定する、アウトソーシングおよびテクノロジーベンダーの契約です。稼働時間、配信時間、応答時間、解決時間などの指標の概要を規定します。SLA には、追加のサポートや料金割引など、要件が満たされていない場合の一連の対応も詳述されています。通常、SLA はクライアントとサービスプロバイダーの間で合意されますが、同じ会社内のビジネスユニット同士で SLA を締結することもできます。

ちなみにSLOとは

サービスレベル目標

サービスレベル目標 (SLO) は、応答時間やアップタイムなどの特定の指標に関する SLA 内の合意内容です。両当事者は、データに基づく主要なサービスパフォーマンスの指標に合意します。 

つまりどういうこと?

SLAとは、アグリーメントとあるように、契約です。
このレベルまで使えることをサービス提供元は保証します。もし使えないなんてことが発生したら、規定の金額まで、金銭的な対応をします、と宣言するものです。

一方で、SLOとは、目標とあるように、契約的なものではありません。
あくまで、サービス提供元がこのレベルまで使える状態にするよう頑張ります!と宣言するものです。そのため、SLOとして定められたレベルまで使えなかったとしても、それを理由に返金を迫る...ということはできません。

SLAを評価するうえで大事なこと

その1

後述しますが、AWSで唯一SLA100%を宣言しているサービスがあります。
それがRoute53という、名前解決を司るサービスです。

Route53におけるSLA、Route53に絡むすべてに対して100%を定めているのでしょうか?
残念ながら違います。

では何に対して定められているのか、この何に対してどのレベルのSLAが定められているのか、正しく把握しておくことが大切です。
Route53だと実際どうなのかについては後述します。

その2

SLAは、あくまで、定められた時間以上使えることを保証しますよ。使えなかったら金銭的に対応しますよ、というものです。

何があっても使えない状態にはしませんよ、というものではありません。

SLAが定められているからすべてにおいて安心ではない点は理解しておく必要があります。

AWSにおけるSLA

AWSでは、以下のページに各種サービスのSLAが定められています。

今回は個人的によく関わるRoute53、EC2、S3についてみていきます。

Route53

Route53は、前述の通りSLA100%が定義されていますが、それはRoute53のすべてにおいてではありません。
具体的には以下の通りです。

ホストゾーンの月次稼働率 サービスクレジット率
100%未満かつ99.99%以上 10%
99.99%未満かつ99.95%以上 25%
99.95%未満 100%

そう、SLAが定められているのは、ホストゾーンと呼ばれるものだけなんですね。
このホストゾーンとは、Amazon Route 53が特定のドメインのトラフィックをどのようにルーティングすべきかを示すDNSレコードのコンテナと紹介されています。

つまり、Route53に求められているDNSクエリへの応答、すなわち名前解決の部分がSLAの対象とされている、ということです。

あれ?では何がSLA対象外なのでしょうか。
それは、DNS登録を含むRoute53のコンソール操作です。

SLA定義には以下のように記載されています

サービスコミットメントは、以下には適用されません:Amazon Route 53 APIやコンソールの可用性や信頼性を含む、その他のAmazon Route 53機能

基本的には企業が提供しているサービスを運用するということを考える場合、最も意識しなければいけないのは名前解決の部分であり、ここがSLA100%と定めてあることは安心ですね。
ただし、Route53で障害が発生しているタイミングでは、追加の登録ができないことは意識しておく必要があります。

Amazon Route 53 Service Level Agreement翻訳
**Amazon Route 53 サービスレベルアグリーメント**

最終更新日:2025年4月16日

このAmazon Route 53サービスレベルアグリーメント(以下「SLA」)は、Amazon Route 53権威DNSの使用を規定するポリシーであり、Amazon Route 53を使用する各アカウントに個別に適用されます。このSLAの条件と、当社サービスの使用を規定する[AWSカスタマーアグリーメント](https://aws.amazon.com/agreement/)またはその他の契約(以下「本契約」)の条件との間に矛盾がある場合は、その矛盾の範囲においてのみ、このSLAの条件が適用されます。本SLAで使用される大文字表記の用語で本SLAで定義されていないものは、本契約で定められた意味を持つものとします。

**サービスコミットメント**

AWSは、各Amazon Route 53ホストゾーンを、以下の表に記載された月次稼働率で利用可能にするために、商業的に合理的な努力を行います。Amazon Route 53ホストゾーンがサービスコミットメントを満たさない場合、以下に説明するサービスクレジットを受け取る資格があります。

**定義**

- **「ホストゾーン」**とは、Amazon Route 53が特定のドメインのトラフィックをどのようにルーティングすべきかを示すDNSレコードのコンテナです。
- 特定のホストゾーンの**「月次稼働率」**は、100%からホストゾーンが利用不可能であった月内の分数の割合を差し引いて計算されます。月次稼働率の測定では、Amazon Route 53 SLA除外事項に直接的または間接的に起因する利用不可能時間は除外されます。
- **「サービスクレジット」**とは、上記のように計算され、当社が対象アカウントにクレジットとして付与する可能性のあるドル建てのクレジットです。
- ホストゾーンに割り当てられた4つの仮想ネームサーバーすべてが、その分の間ずっとホストゾーンに対するすべてのDNSクエリへの応答に失敗した場合、そのホストゾーンは特定の分において**「利用不可能」**となります。

**サービスクレジット**

サービスクレジットは、サービスコミットメントが満たされなかった月次請求サイクルにおいて、影響を受けたホストゾーンに対してお客様が支払ったAmazon Route 53クエリ料金総額のパーセンテージとして、以下のスケジュールに従って計算されます:


| ホストゾーンの月次稼働率(GovCloudリージョン以外のホストゾーン)  | サービスクレジット率 |
|---|---|
| 100%未満かつ99.99%以上 | 10% |
| 99.99%未満かつ99.95%以上 | 25% |
| 99.95%未満 | 100% |

| GovCloudリージョンのホストゾーンの月次稼働率 | サービスクレジット率 |
|---|---|
| 99.995%未満かつ99.99%以上 | 10% |
| 99.99%未満かつ99.95%以上 | 25% |
| 99.95%未満 | 100% |

当社は、サービスクレジットをお客様から今後支払われるAmazon Route 53の支払いに対してのみ適用します。当社の裁量により、利用不可能が発生した請求サイクルの支払いに使用されたクレジットカードにサービスクレジットを発行する場合があります。サービスクレジットは、AWSからの払い戻しやその他の支払いを受ける権利を付与するものではありません。サービスクレジットは、該当する月次請求サイクルのクレジット額が1米ドルを超える場合にのみ適用され、発行されます。サービスクレジットは譲渡できず、他のアカウントに適用することもできません。AWS契約で別途規定されていない限り、利用不可能、パフォーマンス不足、またはAmazon Route 53の提供に関する当社のその他の不履行に対するお客様の唯一かつ排他的な救済手段は、このSLAの条件に従ってサービスクレジットを受け取ること(資格がある場合)です。

**クレジット請求および支払い手続き**

サービスクレジットを受け取るには、[AWSサポートセンターでケースを開く](https://aws.amazon.com/support/createCase?type=account_billing/)ことで請求を提出する必要があります。資格を得るには、クレジット請求はインシデント発生後2回目の請求サイクルの終了までに当社が受領する必要があり、以下を含める必要があります:

i. 件名に「SLA Credit Request」という文言
ii. 請求している各利用不可能インシデントの日付、時刻、リソースID
iii. エラーを文書化し、主張する障害を裏付けるリクエストログ(これらのログ内の機密情報や機密性の高い情報は削除するか、アスタリスクに置き換える必要があります)

当該請求の月次稼働率が当社によって確認され、サービスコミットメント未満である場合、請求が発生した月の翌請求サイクル内にサービスクレジットを発行します。上記の要求およびその他の情報を提供しない場合、サービスクレジットを受け取る資格を失います。

**Amazon Route 53 SLA除外事項**

サービスコミットメントは、以下には適用されません:(a)Amazon Route 53 APIやコンソールの可用性や信頼性を含む、その他のAmazon Route 53機能、または(b)以下の原因によるAmazon Route 53の利用不可能、停止、終了、またはその他のパフォーマンス問題:(i)不可抗力イベントやAmazon Route 53の境界点を越えたインターネットアクセスや関連問題を含む、当社の合理的な制御を超える要因による場合、(ii)お客様の作為または不作為に起因する場合、(iii)お客様の機器、ソフトウェア、またはその他の技術に起因する場合、(iv)本契約に従ってAmazon Route 53を使用する権利を当社が停止または終了したことから生じる場合、(v)使用制限の超過を含む、Amazon Route 53ドキュメントに記載されたガイドラインやベストプラクティスに従わなかったことに起因する場合、または(vi)パブリックDNSに関してのみ、ホストゾーンに割り当てられた4つの仮想ネームサーバーすべて(例えば、AWS商用パーティションに関しては、ns123.awsdns.com、ns123.awsdns.net、ns123.awsdns.co.uk、ns123.awsdns.org)を使用していなかった期間中に発生した場合(これらを総称して「Amazon Route 53 SLA除外事項」)。月次稼働率の計算に使用される要因以外の要因によって可用性が影響を受けた場合、当社はそのような要因を考慮して、裁量によりサービスクレジットを発行することがあります。

EC2

EC2の場合、2つのSLAが定義されています

  • 複数のAZまたはリージョンにわたってデプロイされたAmazon EC2
  • シングルAZにデプロイされたAmazon EC2

複数のAZまたはリージョンにわたってデプロイされたAmazon EC2

複数のAZまたはリージョンにわたってデプロイされた...すなわち、利用者側でマルチAZ以上の冗長構成をしている場合が対象です。
この場合の利用不可とは、複数デプロイしているどれかのEC2がではなく、すべてのEC2に問題がある場合が対象になります。

月間稼働率 サービスクレジット率
99.99%未満かつ99.0%以上 10%
99.0%未満かつ95.0%以上 30%
95.0%未満 100%

シングルAZにデプロイされたAmazon EC2

このシングルAZのEC2は、マルチAZ化されていないEC2はもちろん該当しますが、前述の複数のAZまたはリージョンにわたってデプロイされたEC2の中の一つ辺りのEC2も対象になります。

一個一個にも細かくSLAが定義されているのは良いですね。

更には、1時間当たり6分を超えて利用不可になった場合、6分以上の利用部分は課金されないというSLAも面白いですね。

インスタンスレベル稼働率 サービスクレジット率
99.5%未満かつ99.0%以上 10%
99.0%未満かつ95.0%以上 30%
95.0%未満 100%
Amazon Compute Service Level Agreement 翻訳
**Amazon Computeサービスレベル契約**

最終更新日:2022年5月25日

このAmazon Computeサービスレベル契約(以下「本SLA」)は、Amazon Elastic Compute Cloud(「Amazon EC2」)*の使用を規定するポリシーであり、Amazon EC2を使用する各アカウントに個別に適用されます。本SLAの条項とAWSカスタマーアグリーメントまたは当社サービスの使用を規定するその他の契約(「契約」)の条項との間に矛盾が生じた場合、その矛盾の範囲においてのみ本SLAの条項および条件が適用されます。本書で使用され定義されていない大文字表記の用語は、契約で定義された意味を持ちます。

*本SLAの目的上、Amazon EC2には、関連するAmazon EC2インスタンスと共に購入されたAmazon Elastic Graphics、Amazon Elastic Inference、およびElastic IPアドレスリソースが含まれます。

**SLA**

AWSはAmazon EC2に対して2つのSLAコミットメントを行います:(1)複数のAZまたはリージョンにわたってデプロイされたAmazon EC2を対象とするリージョンレベルSLA、および(2)Amazon EC2インスタンスを個別に対象とするインスタンスレベルSLA。

**リージョンレベルSLA**

同じリージョン内の2つ以上のAZ(または特定のリージョンにAZが1つしかない場合は少なくとも2つのリージョン)にわたって同時にデプロイされたすべての実行中インスタンスを持つAmazon EC2について、AWSは商業的に合理的な努力を払い、各AWSリージョンにおいて月間稼働率99.99%以上でAmazon EC2を利用可能にします(「リージョンレベルSLA」)。Amazon EC2がリージョンレベルSLAを満たさない場合、以下に説明するサービスクレジットを受け取る資格があります。

| 月間稼働率 | サービスクレジット率 |
|---|---|
| 99.99%未満かつ99.0%以上 | 10% |
| 99.0%未満かつ95.0%以上 | 30% |
| 95.0%未満 | 100% |

**インスタンスレベルSLA**

各個別のAmazon EC2インスタンス(「シングルEC2インスタンス」)について、AWSは商業的に合理的な努力を払い、各月次請求サイクル中、インスタンスレベル稼働率99.5%以上でシングルEC2インスタンスを利用可能にします(「インスタンスレベルSLA」)。いずれかのシングルEC2インスタンスがインスタンスレベルSLAを満たさない場合、以下に説明するサービスクレジットを受け取る資格があります。

| インスタンスレベル稼働率 | サービスクレジット率 |
|---|---|
| 99.5%未満かつ99.0%以上 | 10% |
| 99.0%未満かつ95.0%以上 | 30% |
| 95.0%未満 | 100% |

注:インスタンスレベルSLAに加えて、AWSは1時間のうち6分を超えて利用不可となったシングルEC2インスタンスについては課金しません。これは自動的に適用され、6分を超える利用不可時間があった時間のクレジットを要求する必要はありません。

**SLAクレジット**

サービスクレジットは、リージョンレベルSLAを満たさなかった影響を受けたAWSリージョンのAmazon EC2の月額料金、またはインスタンスレベルSLAを満たさなかったAWSリージョンのシングルEC2インスタンスの月額料金(それぞれ、リザーブドインスタンスの前払いなどの一回限りの支払いを除く)のパーセンテージとして計算されます。

サービスクレジットは、お客様から支払われるべきAmazon EC2の将来の支払いに対してのみ適用されます。当社の裁量により、利用不可が発生した請求サイクルの支払いに使用されたクレジットカードにサービスクレジットを発行する場合があります。サービスクレジットはAWSからの返金やその他の支払いを受ける権利を与えるものではありません。サービスクレジットは、該当する月次請求サイクルのクレジット額が1米ドルを超える場合にのみ適用され発行されます。サービスクレジットは譲渡できず、他のアカウントに適用することもできません。

**クレジット要求および支払い手続き**

サービスクレジットを受け取るには、AWSサポートセンターでケースを開いて請求を提出する必要があります。リージョンレベルSLAまたはインスタンスレベルSLAのいずれかでのみ請求を提出でき、特定のシングルEC2インスタンスについてこれらの請求を組み合わせたり積み重ねたりすることはできません。クレジット要求は、インシデントが発生した後の2番目の請求サイクルの終了までに当社が受け取る必要があり、リージョンレベルSLAおよびインスタンスレベルSLAについてそれぞれ以下に指定された情報を含める必要があります。

**リージョンレベルSLA**の要求には以下を含める必要があります:
- 件名に「Amazon Compute SLA Credit Request – Region-Level Claim」という文言
- 請求する各利用不可インシデントの日付、時刻、および影響を受けたAWSリージョン
- Amazon EC2のリソースID
- エラーを文書化し、主張する停止を裏付けるリクエストログ**

**インスタンスレベルSLA**の要求には以下を含める必要があります:
- 件名に「Amazon Compute SLA Credit Request – Instance-Level Claim」という文言
- 請求する各利用不可インシデントの日付、時刻、および影響を受けたAWSリージョンとAZ
- 影響を受けたシングルEC2インスタンスのリソースID
- 主張する停止を検証するために必要なリクエストログおよびその他のデータ**

**機密情報や機微な情報はアスタリスクに置き換えてください。

リージョンレベルまたはインスタンスレベルSLAでの請求が当社によって有効であると確認された場合、要求が確認された月の翌請求サイクル内にサービスクレジットを発行します。

上記の要求された情報およびその他の情報を提供しなかった場合、サービスクレジットを受け取る資格を失います。契約で別段の定めがない限り、本SLAは、Amazon EC2の利用不可、非パフォーマンス、またはその他の当社による提供の失敗に対するお客様の唯一かつ排他的な救済手段、およびAWSの唯一かつ排他的な義務を定めます。

**Amazon Compute SLA除外事項**

リージョンレベルSLAおよびインスタンスレベルSLAは、それぞれ、以下のいずれかに直接的または間接的に起因するAmazon EC2の利用不可、停止または終了、またはその他のAmazon EC2パフォーマンス問題には適用されません:(i)不可抗力イベントやAmazon EC2の境界点を超えるインターネットアクセスまたは関連問題を含む、当社の合理的な制御範囲外の要因によって引き起こされたもの、(ii)復旧ボリュームの承認の失敗やリソースの健全性に関する懸念への対応の失敗を含む、お客様の作為または不作為に起因するもの、(iii)お客様の機器、ソフトウェア、またはその他の技術に起因するもの、または(iv)契約に従ってお客様の該当するAmazon EC2の使用権を当社が停止または終了したことに起因するもの(総称して「Amazon Compute SLA除外事項」)。月間稼働率またはインスタンスレベル稼働率の計算に使用される要因以外の要因によって可用性が影響を受ける場合、当社の裁量により、そのような要因を考慮してサービスクレジットを発行することがあります。

**SLA定義**

- 「アベイラビリティゾーン」および「AZ」とは、AWSリージョンコードに続く文字識別子によって識別されるAWSリージョン内の隔離された場所を意味します(例:us-west-1a)。
- 「月間稼働率」は、100%から、その月にAmazon EC2が利用不可状態にあった分数のパーセンテージを差し引いて計算されます。
- 「インスタンスレベル稼働率」は、100%から、その月にシングルEC2インスタンスが利用不可状態にあった分数のパーセンテージを差し引いて計算されます。
- 「サービスクレジット」とは、上記のように計算され、適格なアカウントにクレジットとして付与される可能性のあるドルクレジットです。
- 「利用不可」および「利用不可状態」とは:
  - インスタンスレベルSLAの場合、シングルEC2インスタンスに外部接続がないこと。
  - Amazon EC2に適用されるリージョンレベルSLAの場合、同じAWSリージョン内の2つ以上のAZ(または、AWSリージョンにAZが1つしかない場合は、そのAZと別のAWSリージョンのAZ)にデプロイされた実行中のすべてのインスタンスが同時に外部接続を持たないこと。

S3

S3は99.999999999% (イレブンナイン) のデータ耐久性を実現できるように設計されている、という表現をされていますが、SLAは99.999999999%で定められているわけではありません。
これは、99.999999999%は耐久性に対しての数値であり、可用性に対する数値であるSLAとは異なることに起因します。

耐久性 vs 可用性の違い

  • 耐久性 (Durability)
    • データが失われない確率。
    • S3は99.999999999%の耐久性を持ち、これは「1年間に10,000,000,000個のオブジェクトを保存した場合、平均して1個のオブジェクトが失われる可能性がある」ことを意味します。
  • 可用性 (Availability)
    • サービスにアクセスできる時間の割合。
    • これがSLAで規定され、停止時間に関連します。

ちなみに...SLAが99.999999999%の場合、許される年間の停止時間は約0.03秒です。
そんなもん気が付くかい!!!って思ってしまいますね。

S3のSLA

S3にはStandardやOneZone-IA、Glacierなど複数のストレージクラスが用意されています。SLAはストレージクラスごとに2つのグループに分類されているため、使用したいストレージクラスがどちらに分類されているかを確認する必要があります。

以下はS3で主に使用される、Standardクラスを含むグループのSLAです。
S3へのアクセスは、Route53やEC2へのアクセスと異なりすべてAPIで行われます。API接続の場合、HTTPステータスコードにおけるエラーは400番台と500番台がありますが、SLAの対象となっているのは500番台、すなわちサーバ側のエラーのみです。400番台であるクライアント側のエラーは当然ながら対象外となる点は認識しておきましょう。

また、500番台のエラーのうち、500(InternalError)並び503(ServiceUnavailable)のみが対象です。

月間稼働率 サービスクレジット率
99.9%未満かつ99.0%以上 10%
99.0%未満かつ95.0%以上 25%
95.0%未満 100%
Amazon S3 Service Level Agreement 翻訳
**Amazon S3サービスレベル契約**

最終更新日:2023年11月28日

このAmazon S3サービスレベル契約(「本SLA」)は、Amazon S3の使用を規定するポリシーであり、Amazon S3を使用する各アカウントに個別に適用されます。本SLAの条項とAWSカスタマーアグリーメントまたは当社サービスの使用を規定するその他の契約(「契約」)の条項との間に矛盾が生じた場合、その矛盾の範囲においてのみ本SLAの条項および条件が適用されます。本書で使用され定義されていない大文字表記の用語は、契約で定義された意味を持ちます。

**サービスコミットメント**

AWSは商業的に合理的な努力を払い、各月次請求サイクル中、以下に説明する月間稼働率でAmazon S3を利用可能にします(「サービスコミットメント」)。Amazon S3がサービスコミットメントを満たさない場合、以下に説明するサービスクレジットを受け取る資格があります。

**サービスクレジット**

サービスクレジットは、月間稼働率が以下の表に示す範囲内に該当した請求サイクルにおいて、影響を受けたAWSリージョン(またはS3 Express One Zoneの場合はAWSアベイラビリティゾーン(AZ))の該当するAmazon S3ストレージクラスについてお客様が支払った合計料金のパーセンテージとして計算されます。

**S3 Standard、S3 Express One Zone、S3 Glacier Flexible Retrieval、S3 Glacier Deep Archive、および以下に指定されていないその他すべてのリクエストの場合:**

| 月間稼働率 | サービスクレジット率 |
|---|---|
| 99.9%未満かつ99.0%以上 | 10% |
| 99.0%未満かつ95.0%以上 | 25% |
| 95.0%未満 | 100% |

**S3 Intelligent-Tiering、S3 Standard-Infrequent Access、S3 One Zone-Infrequent Access、およびS3 Glacier Instant Retrievalへのリクエストの場合:**

| 月間稼働率 | サービスクレジット率 |
|---|---|
| 99.0%未満かつ98.0%以上 | 10% |
| 98.0%未満かつ95.0%以上 | 25% |
| 95.0%未満 | 100% |

サービスクレジットは、お客様から支払われるべきAmazon S3の将来の支払いに対してのみ適用されます。当社の裁量により、Amazon S3がサービスコミットメントを満たさなかった請求サイクルの支払いに使用されたクレジットカードにサービスクレジットを発行する場合があります。サービスクレジットはAWSからの返金やその他の支払いを受ける権利を与えるものではありません。サービスクレジットは、該当する月次請求サイクルのクレジット額が1米ドルを超える場合にのみ適用され発行されます。サービスクレジットは譲渡できず、他のアカウントに適用することもできません。契約で別段の定めがない限り、Amazon S3の利用不可、非パフォーマンス、またはその他の当社による提供の失敗に対するお客様の唯一かつ排他的な救済手段は、本SLAに従ったサービスクレジットの受領(資格がある場合)です。

**クレジット要求および支払い手続き**

サービスクレジットを受け取るには、AWSサポートセンターでケースを開いて請求を提出する必要があります。資格を得るには、クレジット要求がインシデント発生後の2番目の請求サイクルの終了までに当社が受け取る必要があり、以下を含める必要があります:

1. 件名に「SLA Credit Request」という文言
2. サービスクレジットを請求する請求サイクルとAWSリージョン、および請求する各エラー率がゼロでないインシデントの日付と時刻
3. Amazon S3がサービスコミットメントを満たさなかった際の主張するインシデントを文書化したリクエストログ(これらのログ内の機密情報や機微な情報は削除またはアスタリスクに置き換える必要があります)

当該要求の月に適用される月間稼働率が当社によって確認され、該当するサービスコミットメント未満である場合、要求が確認された月の翌請求サイクル内にサービスクレジットを発行します。上記の要求およびその他の情報を提供しなかった場合、サービスクレジットを受け取る資格を失います。

**Amazon S3 SLA除外事項**

サービスコミットメントは、以下のいずれかに起因するAmazon S3の利用不可、停止または終了、またはその他のAmazon S3パフォーマンス問題には適用されません:(i)不可抗力イベントやAmazon S3の境界点を超えるインターネットアクセスまたは関連問題を含む、当社の合理的な制御範囲外の要因によって引き起こされたもの、(ii)お客様の作為または不作為に起因するもの、(iii)お客様の機器、ソフトウェア、またはその他の技術に起因するもの、または(iv)契約に従ってお客様のAmazon S3の使用権を当社が停止または終了したことに起因するもの(総称して「Amazon S3 SLA除外事項」)。月間稼働率の計算に使用される要因以外の要因によって可用性が影響を受ける場合、当社の裁量により、そのような要因を考慮してサービスクレジットを発行することがあります。

**定義**

- 「エラー率」とは、Amazon S3ストレージクラスへの各リクエストタイプについて:(i)該当するAmazon S3ストレージクラスへの当該リクエストタイプについてAmazon S3が返したエラーステータス「InternalError」または「ServiceUnavailable」の内部サーバーエラーの総数を、(ii)月次請求サイクルの該当する5分間隔における当該リクエストタイプの総リクエスト数で割ったものです。各AWSアカウントのエラー率を、月次請求サイクルの各5分間隔についてパーセンテージとして計算します。内部サーバーエラー数の計算には、Amazon S3 SLA除外事項のいずれかに直接的または間接的に起因するエラーは含まれません。

- 「月間稼働率」は、100%から月次請求サイクルの各5分間隔のエラー率の平均を差し引いて計算されます。特定の5分間隔にリクエストを行わなかった場合、その間隔はエラー率0%と見なされます。

- 「サービスクレジット」とは、上記のように計算され、適格なAmazon S3アカウントにクレジットとして付与される可能性のあるドルクレジットです。

おわりに

SLAは、何に対してどのレベルのSLAが定められているかを理解することが重要です。
どんなサービスを使い、それが止まるとどれくらいのビジネスインパクトが出るかを計算し、最悪停止を許容するのか、停止が許されないからどの程度冗長化するかを考えながら設計していきましょう。

参考

13
11
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
13
11

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?