最終更新
SLA (サービス品質保証契約) について説明します。どこまでは保証の範囲か、返金はどうなるか、など注意すべき点を解説します。
2019/3 に AWS の SLA が大幅改善されました。これまでわずか8個しかなかったSLA が 102個と大幅増加しました。さらに返金ルールも稼働率 95% 未満で 100% 返金と、利用者に有利になりました。
目次
SLA とは
SLA (Service Level Agreement) とは、クラウドサービス事業者が利用者に対して、 「我々はこのレベルのサービスを提供します」 「それが達成できなかった場合は、こうします」 と約束するものです。 「サービス品質保証契約」などと訳されることもあります。
最初に言っておくと、SLA に対する過度な期待は禁物です。 当ページ管理人は、 「SLA なんて大したものではない」 「SLA にこだわりすぎてはいけない」 と思っています。
AWS の場合、下記のように「サービスコミットメント」と銘打って、 「〜とするため商業的に合理的な努力をする」と表現しています。 ここには「保証」という言葉は出てきません。
サービスコミットメント
ＡＷＳは、Amazon Route 53を、100％の使用可能時間の割合（以下に定義する）で使用できるようにするため商業的に合理的な努力をする。
Azure の場合は、「保証する」と言い切っています。
マイクロソフトは、Azure Backup サービスのバックアップおよび復元機能について、99.9% 以上の可用性を保証します。
GCP は下記のように、「提供します」と書いています (翻訳は当ページ管理人)。
対象サービスは顧客に対し、月間稼働率を少なくとも99.95% 提供します。
返金額が少ない (場合もある)
まずは AWS の SLA ですが、2019/3 以降の SLA での基本ルールは下記となっているようです。なお、この「基本ルール」は当ページ管理人が SLA を見て推測したもので、AWS が「これが基本ルールです」と公表しているものではありません。
| 月間稼働率 | ダウンタイム | 返金率 |
| 99.0%以上、99.9%未満 | 43分～7.2時間 | 10% |
| 95.0%以上、99.0% | 7.2時間～1.5日停止 | 25% |
| 95.0%未満 | 1.5日以上停止 | 100% |
ただし、一部例外があります。基本ルールより厳しい SLA が設定されているものもあれば、基本ルールより緩い SLA になっているものもあります。
- 基本ルールより厳しいもの
- Aurora：月間稼働率 99.99% (ダウンタイム 4.3分) 未満で返金
- EC2/EBS/ECR/fargate/ELB：月間稼働率 99.99% 未満で返金。さらに 95～99% の場合、30% 返金 (基本ルールでは 25%)
- RDS：月間稼働率 99.95% (ダウンタイム 21.6分) 未満で返金
- 基本ルールより緩いもの
- Connect：月間稼働率 99.99% (ダウンタイム 4.3分) 未満で返金だが、返金率は 5% (基本ルールでは 10%)。さらに 95～99% の場合、15% 返金 (基本ルールでは 25%)
2019/3 より前は、例えば Amazon RDS は下記のとおりでしたので利用者にとって有利になりました。
- Amazon RDS: 稼働率 99.95%〜99.0%: サービスクレジット 10%
- Amazon RDS: 稼働率 99.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%
稼働率とダウンタイム
以下に稼働率とダウンタイムをまとめておきます。
| 稼働率 | ダウンタイム |
| 99.99% | 4.3分 |
| 99.95% | 21.6分 |
| 99.9% | 43分 |
| 99.0% | 7.2時間 |
| 95% | 1.5日 |
なお細かいことを言うと、毎月の日数は異なりますので、例えば稼働率 99.9% は、29日の月ならダウンタイム 41.7分、31日の月なら 44.6分になります。 上記の表は、月の日数を 30日で計算した場合の表です。
返金は障害があったサービスのみ・逸失利益分の補填などはなし
返金は障害があったサービスのみです。 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 も同じです。
より一般化すると、個別サービスの稼働率がそれぞれ 99.99% だったとして、あるシステムが 5種類のサービスを使って構成されていて、どのサービスがダウンしてもシステムとしては動かなくなる場合、システム全体の稼働率は 0.9999×0.9999× 0.9999× 0.9999× 0.9999＝0.9995、つまり 99.95% です。
申告しないと返金されない
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 は 2019/3 までは 8個しか SLA がなかったのですが、2019/3 に SLA 対象サービスが大幅に増えました。ぱっと見ですが 90% 以上は SLA が規定されているようです。これまたぱっと見で、SLA がないように見えるサービスは下記です。
- Amazon Lex
- Amazon Forecast
- Amazon Polly
- Amazon Timestream
- Amazon Translate
- Amazon Transcribe
- AWS Cloud9
- AWS Storage Gateway
なお AWS の SLA 一覧は下記にあります。
Azure の場合、2017/9 に数えたところ、SLA があるサービスは 79個ありました。 もしかしたら SLA がないサービスがあるかもしれませんが、ざっと流し読みしたところ、 主要サービスにには SLA が存在するようです。Azure の SLA 一覧は下記です。SLA へのリンクだけではなくサマリがあるのは素晴らしいことです。
GCP の SLA 一覧は下記です。 GCP は、約 80個のサービスがありますが、SLA は 34個でした (2019/4 調べ。ちなみに 2018/7 時点では 26個、2018/2 時点では 21個)。
Cloud App Engine、Cloud Compute Engine、Cloud Storage、Cloud SQL など、主要サービスには SLA があるようですが、例えば Cloud Load Balancing や Cloud Security Scanner では SLA はないようです。
使い方によっては SLA 対象・返金対象とならない
例えば Amazon RDS の SLA では、対象は “Multi-AZ インスタンス” です。つまり複数台構成にした場合は SLA の対象になりますが、Single-AZ (単一インスタンス構成) では RDS の SLA 対象外です。
例えば Azure Virtual Machine では、
- すべての仮想マシンに、同じ可用性セットにデプロイした 2 つ以上のインスタンスがある場合、マイクロソフトは、99.95% 以上の時間において少なくとも 1 つのインスタンスに対する仮想マシン接続が確保されることを保証します。
- すべてのオペレーティング システム ディスクおよびデータ ディスクについて Premium Storage を使用する単一インスタンス仮想マシンについては、マイクロソフトは 99.9% 以上の時間において仮想マシン接続が確保されることを保証します。
とあります。つまり、複数台インスタンスで可用性セットを使っていたら 99.95% を保証する、単一インスタンスでも Premium Storage を使っていれば 99.9% を保証する、単一インスタンス + Premium Storage 以外のストレージはSLA 対象外ということです。
例えば Google Compute Engine (GCE) では、
- “Downtime” means:
- For virtual machine instances: Loss of external connectivity or persistent disk access for all running Instances, when Instances are placed across two or more Zones in the same Region.
とあります。「同一リージョンで複数ゾーンに配置したすべてのインスタンスから、外部接続または永続ディスクにアクセスできない場合」をダウンタイムとして計算する、と定義しています。
つまり、1つのゾーン内にしか GCE インスタンスがない場合、ダウンタイムとはみなさない、ということです (と思うんだけどこの解釈でいいんだろうか)。
SLA のまとめ
以上のように、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 様、何卒よろしくお願いいたします。