クラウドのSLA（稼働率の保証）の読み方

クラウドの SLA（サービスレベル合意）とは、事業者が約束する稼働率と、その水準を下回ったときに利用料の一部を返す取り決めです。数字だけを見ると「99.99% なら安心」と思いがちですが、その数字がどんな構成を前提にし、何を「止まった」と数え、下回ったときに何が返ってくるのかを読まないと、実際の守りの水準は分かりません。

この記事では、AWS の Amazon EC2 と Google Cloud の Compute Engine の公開の SLA を例に、読むときに確かめる点を説明します。数字は 2026年11月時点で各社のページに載っていたものです。SLA は改定されることがあるため、使うときは最新のページで確かめます。

SLA とは

SLAは、稼働率などの水準を、提供する側と使う側の間で取り決めたものです。クラウドの事業者は、サービスごとに SLA を公開しています。

SLA の考え方そのものや、自社で SLA を決めるときの手順は、SLA（サービスレベル合意）の決め方で説明しています。この記事では、クラウドの事業者が公開している SLA を「読む」側の視点で扱います。

数字には、構成の前提がある

SLA の稼働率は、どんな構成で使っているかによって変わります。高い数字は、複数のゾーンに分けて置くことを前提にしていることが多くあります。

AWS の Amazon EC2 の SLA は、同じリージョンの2つ以上のアベイラビリティゾーンで同時に動かしているサーバーについて、月の稼働率 99.99% を約束しています（リージョン単位の SLA）。一方、1台ずつのサーバーについては、99.5% を約束しています（インスタンス単位の SLA）。

出典：Amazon Compute Service Level Agreement（AWS）

Google Cloud の Compute Engine の SLA も、複数のゾーンに置いたサーバーは 99.99% 以上（Premium ティアのネットワークの場合）、1台のサーバーは種類によって 99.9% 以上などと、構成ごとに数字を分けています。

出典：Compute Engine Service Level Agreement（Google Cloud）

Microsoft Azure の SLA は、Microsoft のオンラインサービスの SLA として、文書の形で公開されています。

出典：Service Level Agreements (SLA) for Online Services（Microsoft）

ゾーンへの分け方は、リージョンとアベイラビリティゾーン。障害に備えた配置の考え方で説明しています。

稼働率を、止まってよい時間に直す

稼働率の数字は、月に何分止まってよいかに直すと、業務への影響を考えやすくなります。30日の月（43,200分）で計算すると、次のようになります。

1台のサーバーで動かしているシステムなら、月に3時間半ほど止まっても SLA の範囲に収まりうる、ということです。業務に照らして、この時間を許せるかを考えます。

「止まった」の定義と、対象外になる場合を読む

SLA で何を「止まった」と数えるかは、事業者が定義しています。自分の感覚の「使えなかった」と一致するとは限りません。

AWS の EC2 のリージョン単位の SLA では、同じリージョンの2つ以上のゾーンに置いた、動いているすべてのサーバーが、同時に外部と通信できない状態を「利用できない」と定義しています。1台だけが止まっても、ほかのゾーンのサーバーが動いていれば、リージョン単位の SLA の上では止まったことになりません。

対象外になる場合も書かれています。AWS は、事業者の合理的な管理の及ばない出来事、利用者の作為や不作為、利用者の機器やソフトウェアによる停止などを除いています。Google Cloud も、利用者や第三者のソフトウェア・機器による誤り、一般提供の前の機能などを対象外としています。自社のアプリケーションの不具合で止まった時間は、事業者の SLA の対象にはなりません。

出典：Amazon Compute Service Level Agreement（AWS）、Compute Engine Service Level Agreement（Google Cloud）

下回ったときに受けられるもの

稼働率が約束を下回ったときに受けられるのは、多くの場合、その月の利用料の一定の割合を、今後の支払いに充てるクレジットです。受けるには、期限までの申請が要ります。

AWS の EC2 では、稼働率に応じて月の利用料の 10%・30%・100% がクレジットになり、今後の支払いに充てられます。申請は、障害が起きた後の2回目の請求の期間の終わりまでに、サポートセンターで行う必要があります。Google Cloud の Compute Engine では、クレジットを受けられるようになってから60日以内に技術サポートへ知らせ、停止した時間を示すログを出す必要があり、守らないとクレジットを受ける権利を失う、とされています。

また、両社とも、SLA に書かれた補いが、約束を守れなかった場合の唯一の救済であるとしています。つまり、SLA の上では、クレジットのほかに補いを求めることは想定されていません。契約の個別の判断は、弁護士などの専門家にご確認ください。

出典：Amazon Compute Service Level Agreement（AWS）、Compute Engine Service Level Agreement（Google Cloud）

SLA では補われないもの

SLA が補うのは利用料の一部であり、システムが止まったことで生じた売上の減少や、取引先への対応の費用は補われません。SLA は「事業者の基盤がどれだけ動くか」の約束であって、「自社のシステムがどれだけ動くか」の約束ではない、と考えておきます。

自社のシステムとしての目標は、別に決めます。止まったときの業務への影響から、許せる停止の時間と目標の稼働率（SLO）を決め、それに見合う構成（複数のゾーン、バックアップ、切り替えの手順）と運用（監視と障害の対応の体制）を用意します。事業者の SLA は、その構成を選ぶときの材料の一つとして読みます。

障害のときに慌てないよう、SLA の申請の期限や必要な記録も、障害の対応の手順に入れておくと安心です。

当社のご支援

当社のクラウドの構築と運用管理では、システムごとの許せる停止の時間を伺い、事業者の SLA の前提を踏まえて、ゾーンの配置、監視、障害の対応の手順を設計しています。運用をお任せいただく場合は、障害の記録を残し、月ごとの報告でお伝えしています。いまの構成が SLA の前提を満たしているかを確かめたい方は、クラウドの現状チェックをご利用ください。