トップ > AWS > AWSのSLAについて調べてみた(2016/10/12時点)

AWSのSLAについて調べてみた(2016/10/12時点)

AWS データベース カルチャー
記事タイトルとURLをコピーする

この記事は記事の公開された日(2016/10/12)時点での情報です。また、各詳細情報についてはAWS公式ドキュメントを参照してください。ここでの情報は、注意して記載しておりますが、サマライズですので、正確ではない部分が含まれている場合があります。

今回は、ちょっと気になるSLAについて書いてみました。

SLAが提供されているサービス

さて、本題のAWSでのSLAですが、 SLAが決められているのは以下のサービスになります。

  • Amazon EC2 (Amazon Elastic Compute Cloud)
  • Amazon EBS (Amazon Elastic Block Store)
  • Amazon RDS (Amazon Relational Database Service)
  • Amazon S3(Amazon Simple Storage Service)
  • Amazon Cloud Front
  • Amazon Route53

上記以外のサービスについては、SLAという形で公式に謳っているものはありません、今回は、記載のある各サービスのSLAについて見ていきます。

SLAという名前の公式ドキュメントは存在せず、それぞれのサービスごとにドキュメントがまとめられています。ドキュメントへのリンクは、各サービスの項に掲載しています。

この、公式ドキュメントでは、冒頭に

以下の翻訳は、便宜上提供されているにすぎず、翻訳版および英語版の間で齟齬または矛盾がある場合（翻訳版の提供の遅滞による場合を含みますが、これに限られません）、英語版が優先します。

とある通り英語版が正式版となります。 もし、SLAについて調べる場合は、ザクっと日本語で調べた後、最終チェックは英語のドキュメントでする必要があります。

AWSのSLAの基本

SLAを満たさなかった場合は、以下の表で表わされるように、 使用不可な時間に対応して、AWS利用量の返金処理を申請できます。 以下の表のサービスクレジット率が、返金の割合のことです。

EC2の利用可能な時間と、返金の割合は以下のようになります。

月間使用可能時間割合サービスクレジット率
99.0%以上99.95％未満10%
99.0％未満30%

この99.95%というのは、1ヶ月あたり、約22分となります。 同じく99%は、約7.2時間です。 これだけの間、サービスが止まっていれば、1ヶ月あたりのサービス利用料から、サービスクレジット率の返金が受けれます。

同じくRDS, S3, CloudFrontの利用可能な時間と、返金の割合は以下のとおりです。

月間使用可能時間割合サービスクレジット率
99.0%以上99.95％未満10%
99.0％未満25%

となります。サービスクレジット率が微妙に違う点は注意が必要です。

最後に、Route53だけは、公式でSLA100%となっていますので、 使用不可能な時間と、サービスクレジットの対応は以下の表となります。

使用可能時間割合が100％でなかった期間サービスクレジット
5～30分1日分のサービスクレジット
31分～4時間7日分のサービスクレジット
4時間以上30日分のサービスクレジット

SLA100%を謳っていますが、1分でも落ちたらということで無いことには注意が必要です。

上に書いた表のサービスクレジット率は、月々の該当サービスの利用料しだいとなりますので、利用料が大きければ、返金額も大きくなります。
ただし、サービス停止で利用者が被った金額を保証してくれるわけではありません。 あくまで、AWSの該当サービスの月々の利用料の割合です。
また、返金処理には、エラーが出ていることが確認できること、というのが必須となります。 エラー原因があくまでAWSだけにあるということをユーザーが証明する必要が出てくるということになります。 (流石に1日以上継続して止まった場合は、ニュースになると思います)

基本的に各サービスがリージョン単位で停止した場合に、返金処理となります。しかし、リージョンで停止していたすべての時間がカウントされるわけではなく、使用可能時間の例外はまとめるとだいたい以下のように書かれています。(詳しくはAWSのドキュメントを参照してください)

  • AWSの利用規約に反し、サービスが停止されている状態
  • AWSの努力以外のところで起こった問題(回線業者の問題など)
  • AWS以外の起因として考えられるところ(ソフトウェアの問題など)

つまり返金対象となるのは、あくまでAWSのDCで起こったAWS起因のリージョン単位での障害、となります。それ以外が起因のものについては返金対象とはなりません。

EC2とEBS

まず、EC2のSLAです。 また、EC2で使用するブロックストレージである、EBSもこちらに合わせて記載があります。

EC2,EBSの使用ができない時間については、 以下のように定義されています。

  • 複数AZにおいて
    • 利用者が実行するすべてのEC2にアクセス出来ない場合
    • EBSに書き込みが不可能で、EC2にキューが残っている場合

返金を念頭に入れて、EC2を用いる場合は、 かならずシステム構成として、AZ跨ぎの冗長構成である必要があります。

RDS

RDSでSLAの条件となっているのは、Multi-AZが必須で、かつエンジンが限定的だという点です。

  • DBエンジンは、MySQL, MariaDB, Oracle, PostgreSQLのいずれかである必要があります。
  • 構成はMulit-AZが必須となります。

RDSには他に、AuroraとSQL Serverが存在しますが、 たとえ、リージョン障害で全て止まったとしても、上記事項を満たさない場合は保証が受けられないことに注意してください。 (ちなみに、日本語版の資料はMySQLとOracleしか記載がありませんが、英語版にはもう2つの記載があります。)

S3

S3だけの事項と言うのは特にありません。 ただし、S3のエラーログの取得というのは、通常行っていない部分ですので、 ここの実証というのはかなりハードルが高いかもしれません。

Cloud Front

Cloud Frontだけの事項として、(vii)に記載の

Amazon S3以外の、カスタムオリジンサーバの使用の結果である場合 というのがあります。

これは、公式ドキュメントのAmazon S3 オリジンおよびカスタムオリジンを使用したウェブディストリビューション 公式ドキュメントの Amazon S3 オリジンおよびカスタムオリジンを使用したウェブディストリビューションに記載があるものと考えるのが良さそうです。 簡単に言えば、S3に入っているコンテンツ以外でエラーが出ても保証はしないよというところでしょうか。

Route53

Route53はSLA100%ですので、 最初に書いたように、返金するための条件が変わってきます。
またRoute53だけのSLA保証外になる条件として、(vii)に記載がありますが

サービス利用者の「ホストゾーン」に割り当てられた、4つすべての仮想ネームサーバーを使用していなかった期間中は保証の対象外となる

というのがあります。 これは、4つのホストゾーンを使って冗長化をしているためであると推測され、 Route53のレジストラで取得したドメインではない、ドメイン用いる際は注意してください。
たとえば、レジストラの制約で、2つしか登録できないとか言った場合であっても、DNSとしては動きますが、保証はしないということになります。

まとめ

意外とSLAの定義されているサービスが少ないことに驚く人もいるかもしれません。また、返金を受けるための条件も厳し目です。 ただ、これを気にして"AWSを使わない"という結論に達する前に、 一度、どの程度の可用性が必要でどの程度コストがかけられるかについて、考えていただくのが吉かと思います。

AWSにかぎらずですが、パブリッククラウドのメリットは、 自前でデータセンターの契約、ネットワークの契約、機器の購入などの手続きを行わなくても、 すぐさまにサーバーを利用可能になることにあります。オンプレでデータセンターを冗長化し、更には国をまたいで冗長化するときのコストを考えると、非現実的なコストになってくるかと思います。 もちろん、サービスが止まらないのが一番ではありますが、オンプレだからといって、機器が故障しない、ネットワークが止まらない、停電しないと言うものでもありません。

また、もちろんAWSとして公式に謳っているのは上記のSLAですが、AWSが内部のシステムの冗長化を行っているわけではなく、複数の冗長化を行った上で、それでも止まった際の事項となります。

実際にサーバーワークスでは、相当な数のAWS上で動くシステムを扱っていますが、ここ1年では東京リージョンにおいて、私の知る限りでは上記SLAに該当するような事項に遭遇したことはありません。 是非、ここで億劫にならずにAWSを利用してもらえればと思います。

その際は、サーバーワークスへのAWS環境構築のご依頼もお忘れなく！