クラウドサービスの SLA 比較 (AWS, Azure, GCP)

前へ << クラウド破産 ベータ・プレビュー >> 次へ

目次

SLA とは

SLA (Service Level Agreement) とは、クラウドサービス事業者が利用者に対して、 「我々はこのレベルのサービスを提供します」 「それが達成できなかった場合は、こうします」 と約束するものです。 「サービス品質保証契約」などと訳されることもあります。

最初に言っておくと、SLA に対する過度な期待は禁物です。 当ページ管理人は、 「SLA なんて大したものではない」 「SLA にこだわりすぎてはいけない」 と思っています。

AWS の場合、下記のように「サービスコミットメント」と銘打って、 「〜とするため商業的に合理的な努力をする」と表現しています。 ここには「保証」という言葉は出てきません。

サービスコミットメント
AWSは、Amazon Route 53を、100%の使用可能時間の割合(以下に定義する)で使用できるようにするため商業的に合理的な努力をする。

Azure の場合は、「保証する」と言い切っています。

マイクロソフトは、Azure Backup サービスのバックアップおよび復元機能について、99.9% 以上の可用性を保証します。

GCP は下記のように、「提供します」と書いています (翻訳は当ページ管理人)。

対象サービスは顧客に対し、月間稼働率を少なくとも99.95% 提供します。

返金額が少ない

例えば Amazon RDSサービスレベルアグリーメント の抜粋は下記です。

AWSは、Multi-AZインスタンスを毎月の請求期間における月間稼働率(以下に定義する)が99.95%以上で使用できるようにするため、商業的に合理的な努力を尽くす(「サービスコミットメント」)。Amazon RDSが月間稼働率のコミットメントを満たさない場合、サービス利用者は以下に定めるサービスクレジットを受け取ることができる。 (略)

月間稼働率が 99.0% 以上 99.95% 未満: サービスクレジット 10%
月間稼働率が 99.0% 未満: サービスクレジット 25%

つまり、

  • その月の使用不能時間が 0分: 当然ながら返金なし
  • その月の使用不能時間が 0分〜21.6分の場合 (100〜99.95%): 返金なし
  • その月の使用不能時間が 21.6分〜432分(7時間12分) (99.95%〜99.0%): 10% 返金
  • その月の使用不能時間が 432分(7時間12分)以上 (99.0%未満) : 25% 返金
ということです。

1ヶ月で20分止まるというのは業務系システムでは結構な障害です。しかし返金なし。 1ヶ月で8時間止まっても、ようやく25%返金。 それ以上は何時間・何日止まろうと 25% 以上を返金することはなし。

AWS の場合の返金率をまとめます (2017/12 時点)

  • CloudFront: 稼働率 99.9%〜99%: サービスクレジット 10%
  • CloudFront: 稼働率 99.0% 未満: サービスクレジット 25%
  • EC2/ECS/EBS/Fargate: 稼働率 99.99%〜99.0%: サービスクレジット 10%
  • EC2/ECS/EBS/Fargate: 稼働率 99.0% 未満: サービスクレジット 30%
    • 2017/12 に、EC2/EBS に加え、ECS/Fargate も SLA 対象となり、稼働率 99.95% が 99.99% に変更されました。これまで月間 21.6分停止で 10% サービスクレジット発行だったものが、月間 4.32分 (4分19秒) 停止で 10% サービスクレジット発行となりました。さらに 99.0% 未満の場合、サービスクレジット率が 25%→30% に引き上げられました。
  • Amazon RDS: 稼働率 99.95%〜99.0%: サービスクレジット 10%
  • Amazon RDS: 稼働率 99.0% 未満: サービスクレジット 25%
  • Route53: 5〜30分使用不可: サービスクレジット 1日分
  • Route53: 31分〜4時間使用不可: サービスクレジット 7日分
  • Route53: 4時間以上使用不可: サービスクレジット 30日分
  • S3: 稼働率 99.9%〜99.0%: サービスクレジット 10%
  • S3: 稼働率 99.0% 未満: サービスクレジット 25%
  • S3 (標準-IA): 稼働率 99.0%〜98.0%: サービスクレジット 10%
  • S3 (標準-IA): 稼働率 98.0% 未満: サービスクレジット 25%

Azure の場合、SLA をざっと見た限りでは、おおむね最大 25% 返金ですが、 VM のように 100% 返金もあるようです。

  • App Service
    • 稼働率 99.95% 未満 … 返金額 10%
    • 稼働率 99% 未満 … 返金額 25%
  • Traffic Manager
    • 稼働率 99.99% 未満 … 返金額 10%
    • 稼働率 99% 未満 … 返金額 25%
  • VM
    • 稼働率 99.95% 未満 … 返金額 10%
    • 稼働率 99% 未満 … 返金額 25%
    • 稼働率 95% 未満 … 返金額 100%

GCP は、各サービスの SLA をざっと見た限りでは、おおむね下記のように、 99% (≒7時間12分) の停止で 25% 返金、 95% (≒1.5日) の停止で 50% 返金となるようです。

  • 稼働率 99.0% 〜 99.95% … 返金額 10%
  • 稼働率 95.0% 〜 99.0% … 返金額 25%
  • 稼働率 〜 95.0% … 返金額 50%

返金は障害があったサービスのみ・逸失利益分の補填などはなし

返金は障害があったサービスのみです。 EC2 の障害であれば EC2 分のみ。 RDS の障害であれば RDS 分のみ。

例えば AWS で、EC2 + RDS + S3 な EC サイトを運営していたとして、 仮に1日 S3 が停止したとします。

サイトの作りにもよるとは思いますが、S3 の停止でサイトが全面停止してしまう可能性は十分あるでしょう。 そして 1日分の停止で、売上が 100万円減ったとしても、100万円の補填が行われることはありません。 EC2 で動かしているアプリが S3 に依存していたとしても EC2 分の返金はありません。 S3 の 1日停止は 30% のサービスクレジットですから、 仮に月間売上 3,000万円のサイトの AWS 費用が 50万/月で、S3 が 10% を占めていたとして、 その 30% はわずか 15,000円分にしかなりません。

これは AWS に限らず、Azure も GCP も同じです。

申告しないと返金されない

AWS・Azure・GCP とも、障害が発生し、返金申告する必要があります。

AWS の RDS の SLA を引用します。

サービスクレジットを受領するには、サービス利用者はAWSサポートセンターにケースを申請することで請求を提出するものとする。サービスクレジットの受領資格を有するとされるためには、クレジットの請求は、当該事由の発生した翌々請求期間の末日までに、アマゾンによって受領されなければならず、請求には以下を記載するものとする。
i. 件名欄に「SLAクレジットの請求」の表記
ii. 請求の対象となる各使用不能の日時
iii. 該当するMulti-AZインスタンスのDBインスタンスIDおよびAWS地域
iv. エラーを記録し、請求対象の停止時間を裏付けるサービス利用者のリクエストログ(ログ中の機密情報は削除するか「*」印に置き換えるものとする)

Azure の SLA は下記です。

マイクロソフトが申し立てを検討するためには、お客様はその申し立てを、マイクロソフトが当該申し立てを検証するために必要なすべての情報と共に Microsoft Corporation のカスタマー サポートに提出しなければなりません。この情報には、(i) インシデントの詳細な説明、(ii) ダウンタイムの発生日時および継続期間に関する情報、(iii) 影響を受けたユーザー (該当する場合) の数および所在地、ならびに (iv) インシデント発生時にお客様がインシデント解決のために講じた措置の説明、を含みますが、これらに限定されません。

GCP の SLA を、Google 翻訳したものは下記です。何を Google に通知すべきかは記載がないように見えます。

お客様は金融クレジットを要求する必要があります。上記の金融クレジットを受け取るには、顧客が金融クレジットの受領資格を得た時点から30日以内に、Googleの技術サポートに通知する必要があります。この要件を遵守しなかった場合、顧客は金融クレジットを受け取る権利を失うことになります。

AWS はログの提示まで要求しており、かなりめんどくさそうです。 ただ、AWS 側も把握している障害も多いでしょうから、本当に毎回ログを出さないと受け付けてくれないのかはわかりません。

「返金」ではないこともある

AWS の場合、そもそも「返金」ではなく「サービスクレジットの発行」と銘打っています。 サービスクレジットとは何かと言うと、例えば RDS の SLA では 「サービスクレジットは、サービス利用者が支払うこととされる将来のAmazon RDSの支払いに対してのみ充当される」 とあります。つまり、RDS の障害発生分は、「翌月または翌々月などの将来の RDS 支払いに使えるクーポン券のようなもの」 というわけです。

ある時点で RDS の利用をやめるとして、その最終月に障害が発生して サービスクレジットを受けたとしても、翌月からは RDS を使わないわけですから、 そのサービスクレジットの使いみちはなくなります。「RDS はもう使っていないから EC2 分で使わせて」 と言っても無理です。

Azure の場合は、実際に返金されるようです。 お金で返ってくる以上は、AWS のように「そのサービスでしか使えない」というものではないでしょう。 基本的には翌月以降の請求から差し引く形であるようですが、 Azure 利用をやめた後の場合は振込等で返金されるかは不明です。

GCP の場合、障害時は "Financial Credit" を付与するとあります。 "FInancial Credit" は「金融債権」「金融クレジット」とのことなので、 文字通り解釈するならば「返金してもらえる」となるのでしょう (たぶん)。 お金で返ってくる以上は、AWS のように「そのサービスでしか使えない」というものではないでしょう。

SLA がないサービスはたくさんある

AWS が結構ひどいのですが、130個程度のサービスを展開しているにもかかわらず、 SLA が規定されているサービスは下記のみです (2018/10 現在)。

  • S3
  • EC2 (EBS, ECS, Fargate 含む)
  • RDS
  • CloudFront
  • Route53
  • DynamoDB
  • AWS Lambda (2018/10 追加)
  • AWS Shield Advanced
なお AWS の SLA 一覧は下記にあります。

また、Amazon RDS には SLA は定義されていますが、対象は "Multi-AZ インスタンス" であり、その意味は 「Multi-AZ パラメータが正確に設定されているAmazon RDS for MySQL, MariaDB, Oracle, PostgreSQL のデータベースインスタンスを意味する」と記載があります。 つまり「Single-AZ であれば SLA 対象外」であり、なおかつ、 「Aurora と SQL Server は SLA 対象外 (言及がないので)」ということです。

上記以外のサービスがどれだけ落ちようと、返金はないということです。 例えば SLA が求められがちであろう ELB/ALB、ElastiCache には SLA がありません。

Azure の場合、2017/9 に数えたところ、SLA があるサービスは 79個ありました。 もしかしたら SLA がないサービスがあるかもしれませんが、ざっと流し読みしたところ、 メイン機能は SLA が存在するようです。Azure の SLA 一覧は下記です。SLA へのリンクだけではなくサマリがあるのは素晴らしいことです。

GCP の SLA 一覧は下記です。 GCP は、約 65個のサービスがありますが、SLA は 26個でした (2018/7 調べ。ちなみに 2018/2 時点では 21個)。

Cloud App Engine、Cloud Compute Engine、Cloud Storage、Cloud SQL など、主要サービスには SLA があるようですが、例えば Cloud Load Balancing や Cloud Security Scanner では SLA はないようです。

SLA のまとめ

以上のように、SLA について詳しく調べていくと、 当初思っていたものと大きく乖離していることに気づくでしょう。

特に AWS の逃げ腰な姿勢はどうかと思います。 当ページ管理人は、AWS はクラウドサービス業界のトップリーダーだと思っていますが、 「商業的に合理的な努力をする」とか、SLA 未設定のサービスが多すぎるとか、 もうちょっとなんとかしてほしい。そのくせ、

  • S3 の耐久性は 99.999999999% (イレブンナイン)
  • Route53 の SLA は 100%
といったキャッチーなアピールの仕方をするのは姑息だと思います (たとえば S3 の SLA ではサービスクレジットの付与は月間使用可能時間割合が 99.9% 未満であり、 99.999999999% (イレブンナイン) というのはあくまで S3 へ保存したものが破損で失われる割合の話。 また、Route53 の SLA 100% と言いつつ、 「Amazon Route 53の使用可能時間割合が100%でなかった期間」が 5分以上でないとサービスクレジットの付与はなされない)。

これをもってクラウドサービス各社が「あくどい」と言うつもりはありません。 各クラウドサービスがガチで戦っている中で、「このクラウドサービスは落ちやすい」という悪評は 彼ら自身が最も嫌うところでしょうから、落ちて困るのは彼ら自身です。

そして、SLA の稼働率が低い・返金率が低い=落ちやすい、と限らないのもこれまた事実です。

しかしながら、我々利用者は

  • 「SLA は稼働率を保証するものではない」
  • 「稼働率を下回ったとしても若干の返金があるだけ」
  • 「その閾値は 99.95% といった結構ヌルい稼働率」
  • 「返金申請しないと返金されない。返金申請自体もそれなりの手間がかかる」
ということ、 つまり「SLA があるから大丈夫、なんてことは全くない」 ということを認識した上で、クラウドサービスを利用すべきだと思います。

いっそのこと…

そもそも返金申請などしない、という考え方もよいのではないでしょうか。 よほどの大規模サービスでない限り、 返金される金額よりも、申請に要する工数の方が大きいと思います。 SI だと難しいかもしれませんが、自社サービスであればこの考え方はアリだと思います。

余談: SLA の和訳について

2018/07/06 現在、Amazon RDS の SLA の 日本語版 は 2013/06/01 付ですが、 英語版 は 2016/03/25 付です。2年3ヶ月経っても和訳されていません。 さらに Route 53 の SLA の日本語版は 2015/05/15 付ですが、 英語版は 2016/12/01 付。こちらは 7ヶ月経っても和訳されていない (なお、各国語版を見るには、ページヘッダに言語選択プルダウンがあるので、そこで切り替えると便利です)。

SLA に限らず、「日本語訳は単なる参考資料であって、英語が正式資料である」 というのはよく言われることですが、それにしても Amazon RDS の SLA が 少なくとも 2年以上の遅れとは恐れ入りました。 ここまで遅れるなら「最新版はこちら」とリンクを張ってほしいですね。

ちなみに Azure はざっと 20個程度確認しましたが、 すべて英語版と日本語版の更新年月は一致していました。 地味なところではありますが、真面目にビジネスをやろうとしている感が伝わってきます。

なお、GCP の SLA は英語版しかないので、 Google 様、何卒よろしくお願いいたします。

前へ << クラウド破産 ベータ・プレビュー >> 次へ

ご意見・ご指摘は Twitter: @68user までお願いします。