--- title: "クラウドのSLA（稼働率の保証）の読み方｜アメリア・テクノロジー株式会社" url: https://www.ameliatechnology.co.jp/blog/cloud-sla-reading/ description: "クラウドのSLAは、事業者が約束する稼働率と、下回ったときのクレジットの取り決めです。Amazon EC2 と Compute Engine の SLA を例に、前提、止まった状態の定義、クレジットの受け方、補われないものを説明します。" updated: 2026-11-14 publisher: "アメリア・テクノロジー株式会社" --- # クラウドのSLA（稼働率の保証）の読み方 クラウドのSLAは、事業者が約束する稼働率と、下回ったときのクレジットの取り決めです。Amazon EC2 と Compute Engine の SLA を例に、前提、止まった状態の定義、クレジットの受け方、補われないものを説明します。 2026.11.14 [クラウドと運用](https://www.ameliatechnology.co.jp/blog/category/cloud/) 執筆 [石田誠](https://www.ameliatechnology.co.jp/blog/author/ishida/)（グループCTO） クラウドと運用（CLOUD & OPERATIONS）のコラム ## この記事の要点 - SLA の数字には「複数のゾーンに分けて置く」などの前提があり、1台だけの構成では、より低い数字か対象外になることがあります - 下回ったときの補いは、多くの場合、今後の利用料に充てるクレジットで、受けるには期限までの申請が要ります - SLA が補うのは利用料の一部で、業務が止まった損失は補われないため、自社のシステムとしての目標は別に決めます クラウドの SLA（サービスレベル合意）とは、事業者が約束する稼働率と、その水準を下回ったときに利用料の一部を返す取り決めです。数字だけを見ると「99.99% なら安心」と思いがちですが、その数字がどんな構成を前提にし、何を「止まった」と数え、下回ったときに何が返ってくるのかを読まないと、実際の守りの水準は分かりません。 この記事では、AWS の Amazon EC2 と Google Cloud の Compute Engine の公開の SLA を例に、読むときに確かめる点を説明します。数字は 2026年11月時点で各社のページに載っていたものです。SLA は改定されることがあるため、使うときは最新のページで確かめます。 ## SLA とは [SLA](https://www.ameliatechnology.co.jp/glossary/availability-sla/)は、稼働率などの水準を、提供する側と使う側の間で取り決めたものです。クラウドの事業者は、サービスごとに SLA を公開しています。 SLA の考え方そのものや、自社で SLA を決めるときの手順は、[SLA（サービスレベル合意）の決め方](https://www.ameliatechnology.co.jp/blog/sla-how-to-decide/)で説明しています。この記事では、クラウドの事業者が公開している SLA を「読む」側の視点で扱います。 ## 数字には、構成の前提がある SLA の稼働率は、どんな構成で使っているかによって変わります。高い数字は、複数のゾーンに分けて置くことを前提にしていることが多くあります。 AWS の Amazon EC2 の SLA は、同じリージョンの2つ以上のアベイラビリティゾーンで同時に動かしているサーバーについて、月の稼働率 99.99% を約束しています（リージョン単位の SLA）。一方、1台ずつのサーバーについては、99.5% を約束しています（インスタンス単位の SLA）。 出典：[Amazon Compute Service Level Agreement（AWS）](https://aws.amazon.com/compute/sla/) Google Cloud の Compute Engine の SLA も、複数のゾーンに置いたサーバーは 99.99% 以上（Premium ティアのネットワークの場合）、1台のサーバーは種類によって 99.9% 以上などと、構成ごとに数字を分けています。 出典：[Compute Engine Service Level Agreement（Google Cloud）](https://cloud.google.com/compute/sla) Microsoft Azure の SLA は、Microsoft のオンラインサービスの SLA として、文書の形で公開されています。 出典：[Service Level Agreements (SLA) for Online Services（Microsoft）](https://www.microsoft.com/licensing/docs/view/Service-Level-Agreements-SLA-for-Online-Services) ゾーンへの分け方は、[リージョンとアベイラビリティゾーン。障害に備えた配置の考え方](https://www.ameliatechnology.co.jp/blog/region-availability-zone-design/)で説明しています。 ### 稼働率を、止まってよい時間に直す 稼働率の数字は、月に何分止まってよいかに直すと、業務への影響を考えやすくなります。30日の月（43,200分）で計算すると、次のようになります。 | 稼働率 | 月に止まってよい時間の目安（30日の月） | |---|---| | 99.99% | 約4.3分 | | 99.9% | 約43分 | | 99.5% | 約216分（約3.6時間） | 1台のサーバーで動かしているシステムなら、月に3時間半ほど止まっても SLA の範囲に収まりうる、ということです。業務に照らして、この時間を許せるかを考えます。 ## 「止まった」の定義と、対象外になる場合を読む SLA で何を「止まった」と数えるかは、事業者が定義しています。自分の感覚の「使えなかった」と一致するとは限りません。 AWS の EC2 のリージョン単位の SLA では、同じリージョンの2つ以上のゾーンに置いた、動いているすべてのサーバーが、同時に外部と通信できない状態を「利用できない」と定義しています。1台だけが止まっても、ほかのゾーンのサーバーが動いていれば、リージョン単位の SLA の上では止まったことになりません。 対象外になる場合も書かれています。AWS は、事業者の合理的な管理の及ばない出来事、利用者の作為や不作為、利用者の機器やソフトウェアによる停止などを除いています。Google Cloud も、利用者や第三者のソフトウェア・機器による誤り、一般提供の前の機能などを対象外としています。自社のアプリケーションの不具合で止まった時間は、事業者の SLA の対象にはなりません。 出典：[Amazon Compute Service Level Agreement（AWS）](https://aws.amazon.com/compute/sla/)、[Compute Engine Service Level Agreement（Google Cloud）](https://cloud.google.com/compute/sla) ## 下回ったときに受けられるもの 稼働率が約束を下回ったときに受けられるのは、多くの場合、その月の利用料の一定の割合を、今後の支払いに充てるクレジットです。受けるには、期限までの申請が要ります。 AWS の EC2 では、稼働率に応じて月の利用料の 10%・30%・100% がクレジットになり、今後の支払いに充てられます。申請は、障害が起きた後の2回目の請求の期間の終わりまでに、サポートセンターで行う必要があります。Google Cloud の Compute Engine では、クレジットを受けられるようになってから60日以内に技術サポートへ知らせ、停止した時間を示すログを出す必要があり、守らないとクレジットを受ける権利を失う、とされています。 SLA のクレジットを受けるまで（Amazon EC2・Compute Engine の SLA より） - **稼働率が約束を下回る**：その月の稼働率に応じて、クレジットの割合が決まる（EC2 は月の利用料の 10%・30%・100%） - **期限までに申請する**：EC2：障害の後の2回目の請求の期間の終わりまでに、サポートセンターで。Compute Engine：受けられるようになってから60日以内に技術サポートへ知らせ、停止した時間を示すログを出す - **クレジットを受ける**：原則として、**今後の支払いに充てる**形で受ける **申請しなければ受けられません** また、両社とも、SLA に書かれた補いが、約束を守れなかった場合の唯一の救済であるとしています。つまり、SLA の上では、クレジットのほかに補いを求めることは想定されていません。契約の個別の判断は、弁護士などの専門家にご確認ください。 出典：[Amazon Compute Service Level Agreement（AWS）](https://aws.amazon.com/compute/sla/)、[Compute Engine Service Level Agreement（Google Cloud）](https://cloud.google.com/compute/sla) ## SLA では補われないもの SLA が補うのは利用料の一部であり、システムが止まったことで生じた売上の減少や、取引先への対応の費用は補われません。SLA は「事業者の基盤がどれだけ動くか」の約束であって、「自社のシステムがどれだけ動くか」の約束ではない、と考えておきます。 自社のシステムとしての目標は、別に決めます。止まったときの業務への影響から、許せる停止の時間と目標の稼働率（[SLO](https://www.ameliatechnology.co.jp/glossary/slo/)）を決め、それに見合う構成（複数のゾーン、バックアップ、切り替えの手順）と運用（[監視](https://www.ameliatechnology.co.jp/glossary/monitoring/)と障害の対応の体制）を用意します。事業者の SLA は、その構成を選ぶときの材料の一つとして読みます。 障害のときに慌てないよう、SLA の申請の期限や必要な記録も、障害の対応の手順に入れておくと安心です。 ## 当社のご支援 当社の[クラウドの構築と運用管理](https://www.ameliatechnology.co.jp/service/cloud/)では、システムごとの許せる停止の時間を伺い、事業者の SLA の前提を踏まえて、ゾーンの配置、監視、障害の対応の手順を設計しています。運用をお任せいただく場合は、障害の記録を残し、月ごとの報告でお伝えしています。いまの構成が SLA の前提を満たしているかを確かめたい方は、[クラウドの現状チェック](https://www.ameliatechnology.co.jp/pricing/#cloud)をご利用ください。 - SLA - 稼働率 - クラウド - 可用性 ## この記事に出てくる用語 - [クラウド](https://www.ameliatechnology.co.jp/glossary/cloud/) - [可用性・SLA](https://www.ameliatechnology.co.jp/glossary/availability-sla/) - [AWS（Amazon Web Services）](https://www.ameliatechnology.co.jp/glossary/aws/) - [Google Cloud](https://www.ameliatechnology.co.jp/glossary/google-cloud/) - [リージョンとアベイラビリティゾーン](https://www.ameliatechnology.co.jp/glossary/region-availability-zone/) - [サーバー](https://www.ameliatechnology.co.jp/glossary/server/) - [Microsoft Azure](https://www.ameliatechnology.co.jp/glossary/azure/) - [ログ](https://www.ameliatechnology.co.jp/glossary/log/) この記事を書いた人 [石田誠](https://www.ameliatechnology.co.jp/blog/author/ishida/) グループCTO インターネットの黎明期から、ホスティング事業の立ち上げや、インフラ・セキュリティのプロジェクトに携わってきました。現在は、AWS・Azure へのクラウド移行の支援と、業務アプリケーションの要件定義から実装までを担っています。 このコラムは一般的な情報の提供を目的としたもので、個別の状況への助言ではありません。製品・サービスの名前と内容は、記事の更新日の時点のものです。 ## あわせて読みたい - [Windowsサーバーと Active Directory を Azure へ移すときの考え方](https://www.ameliatechnology.co.jp/blog/windows-ad-to-azure/) - [Google Cloud を選ぶ場面。データ分析と Google Workspace とのつながり](https://www.ameliatechnology.co.jp/blog/when-to-choose-google-cloud/) - [Well-Architected の柱で、いまの構成を確かめる](https://www.ameliatechnology.co.jp/blog/well-architected-review/) [クラウドと運用のコラムを見る](https://www.ameliatechnology.co.jp/blog/category/cloud/) [コラムの一覧に戻る](https://www.ameliatechnology.co.jp/blog/) ## 次の一歩 ### クラウドの構築と運用を任せる AWS・Microsoft Azure・Google Cloud の設計・構築・移行から、監視・運用・セキュリティまでを一つのチームで受け持ちます。監視は仕組みで24時間365日自動に回し、原因の調査と再発の防止は当社が担います。 [クラウドの構築と運用管理を見る](https://www.ameliatechnology.co.jp/service/cloud/) ### クラウドの状態を、無料で確かめる 15の設問に答えると、構成と管理・権限・守り・障害への備え・費用と体制の5つの分野の点数と、最初に取り組むことをまとめたレポートをその場でお届けします。 [クラウドの自己診断（無料）を受ける](https://www.ameliatechnology.co.jp/diagnosis/cloud/) ## ご関心に合わせて、お選びください。 [情報を集めている方へ会社案内、AI開発の例、セキュリティ診断の報告書の見本をお送りします。資料をダウンロード](https://www.ameliatechnology.co.jp/download/)[課題が見えている方へオンラインで30分、お話をうかがいます。費用はかかりません。無料で相談する](https://www.ameliatechnology.co.jp/contact/)[進め方を決めたい方へ2〜4週間で、優先順位と計画をまとめるAI活用の診断です。診断について見る](https://www.ameliatechnology.co.jp/pricing/#diagnosis) --- 出典：アメリア・テクノロジー株式会社「クラウドのSLA（稼働率の保証）の読み方｜アメリア・テクノロジー株式会社」 https://www.ameliatechnology.co.jp/blog/cloud-sla-reading/