要約

  • Cloudflare の公開 Enterprise SLA を、30 日の月、予定可用時間 43,200 分、60 分の予定外停止、影響顧客比率 100%、顧客予定停止と不可抗力による控除なしという前提で再計算すると、サービスクレジット比率は ((60 × 5) × (1 × 5)) / 43,200 = 0.0347222、すなわち該当する Service の月額経常料金の約 3.47%になる。これは実顧客の請求額でも、売上逸失や復旧費を含む事業損失の推計でもない。31 日の月を分母にすると同じ 60 分でも約 3.36%になる。
  • AWS、Google Cloud、Oracle、IBM の公開条件を並べると、SLA の経済的意味は名目可用性だけでは決まらない。複数 AZ・複数ゾーン配置などの構成条件、リージョン・プロジェクト・インスタンス・Service といった測定単位、クレジット対象料金、申請期限、ログや資源 ID の証拠、除外、上限、同一事故に対する重複不可が、実際に移転されるリスクを決める。
  • したがって、クラウド調達で比較すべきなのは「どの会社の数字が高いか」ではない。「どの故障面を誰が支配し、何を測り、違反時にどの損失まで契約上移転され、残りを誰が構成・保険・調達・退出で負担するのか」である。

60 分の停止を、契約はどう金額に変えるか

Cloudflare が公開している Enterprise SLA は、対象となる Service について 100% uptime を掲げる。その一方で、違反時のクレジットは単純に「停止したから月額料金を全額返す」という形ではない。まず予定外停止で影響を受けたユニーク訪問者数を、ユニーク訪問者総数で割って Affected Customer Ratio を求める。公開式では、その比率と停止時間の双方に係数 5 を掛け、Scheduled Availability の分数で割る。Scheduled Availability は月間総分数から Customer Planned Downtime と Force Majeure による停止を除いたものだ。

前提を固定すると、契約の機構が見えやすい。30 日の月なら月間総分数は 43,200 分。顧客予定停止も不可抗力停止もないと仮定すれば、Scheduled Availability も 43,200 分である。予定外停止が 60 分、影響顧客比率が 100%、つまり 1.0 なら、

((60 × 5) × (1 × 5)) / 43,200 = 0.0347222

となる。約 3.47%である。

ここで重要なのは単位だ。この 3.47%は、顧客企業が障害で失った売上の 3.47%でも、障害時間の 3.47%でもない。公開条件上、検証された Claim に対して、該当 Service に関連する月額経常料金を基礎として算出される Service Credit の比率である。しかも実際の Claim には通知、証拠、除外条件、Cloudflare による検証が伴う。したがって、この計算は契約式を理解するための例示であり、実顧客の請求結果ではない。(Cloudflare)

分母も固定ではない。31 日の月なら、同じ仮定で Scheduled Availability は 44,640 分になる。分子は 1,500 のままなので、1,500 / 44,640 は約 0.03360、つまり約 3.36%だ。同じ 60 分の全面停止でも、月の長さが変わればクレジット比率がわずかに変わる。予定停止や不可抗力の扱いが入れば、さらに分母が変わる。

この程度の算数で、SLA の本質のかなりの部分が見える。「100%」という見出しはサービスレベルの名目を示すが、損失を金銭に変換する機械はその下にある。実際のリスク移転量を決めるのは、停止分数、影響比率、分母、対象料金、請求手続、上限である。

SLA は信頼性ランキングではない

この区別を外すと、クラウド SLA はすぐにランキング表に変わる。100% は 99.99% より優れ、99.99% は 99.9% より優れる、という読み方だ。しかし契約上の可用性は、異なる測定対象、異なるアーキテクチャ、異なる時間粒度の上で定義されている。

同じ「99.99%」でも、単一インスタンスの可用性なのか、リージョン内で複数ゾーンに配置された一群のインスタンスなのかで意味は異なる。停止時間を秒単位で拾うのか、1 分未満の断続停止を数えないのかでも異なる。さらに違反が認められても、クレジットの基礎がアカウント全体の請求額なのか、障害を起こしたリージョンなのか、単一インスタンスなのか、特定 Service の実使用純料金なのかで金額は変わる。

したがって SLA を読む順序は、見出しの数字からではなく、少なくとも九つの問いから始める方がよい。何を測るのか。どの配置を前提とするのか。停止をどの時間粒度で数えるのか。クレジット比率の分母は何か。どの資源の料金が対象か。顧客はいつまでに何を申請するのか。何を証拠として保存する必要があるのか。何が除外されるのか。そして上限と重複不可はどう定められているのか。

これらを答えて初めて、パーセントに経済的な意味が生まれる。

Cloudflare――利用者への影響まで式に入れる

Cloudflare の方式で特徴的なのは、停止時間だけでなく Affected Customer Ratio が式に入る点である。予定外停止によって影響を受けた、IP アドレスで測定されるユニーク訪問者数を、ユニーク訪問者総数で割る。全面的な影響なら 1.0 だが、影響が一部に限られるなら分子側も小さくなる。

この設計は、単なる「何分落ちたか」よりも利用者影響に近づこうとする一方、測定を契約上の重要問題にする。Cloudflare は顧客コンテンツの包括的監視を自らの責任とはせず、その責任は顧客にあるとする。また、顧客が用いる商業上合理的な独立測定システムのデータをレビューし、Cloudflare 自身も利用可能な情報や停止直前の Service Data などを用いて影響比率を算出するとしている。(Cloudflare)

つまり、SLA を実際に使える権利にするには、顧客側の観測能力が必要になる。事故後 5 営業日以内に Customer Support へ通知し、事故の期間、ネットワークの traceroute、影響 URL、解決のために試みたことなどを示す。その後、事故が発生した請求月の次の請求月末までに、Claim を裏付ける十分な証拠を提出する必要がある。Cloudflare は利用可能な情報で Claim を検証し、SLA が適用されるかを判断する。(Cloudflare)

救済にも境界がある。公開条件上、Service Credit は SLA 違反に対する唯一の救済であり、年間の Service Credit 総額には累積月額サービス料金 6 か月分という上限がある。また、計算対象となるのはその SLA に関連する Service の月額経常料金である。(Cloudflare)

ここから分かるのは、100% uptime と 100% の経済損失移転は同義ではないということだ。前者はサービスレベルの契約上の基準であり、後者はこの SLA が約束していない。障害で顧客に生じる売上逸失、従業員の復旧工数、他社への違約金、ブランド毀損などを、この公開式から推計することはできない。

AWS――99.99% は配置条件でもある

AWS EC2 では、リージョン水準の 99.99% は無条件の属性ではない。同一リージョン内で、稼働中の全インスタンスが少なくとも二つの Availability Zone に同時配置されていることが前提になる。単一 EC2 インスタンスについては別の Instance-Level SLA があり、基準は 99.5% だ。(Amazon Web Services, Inc.)

これは「高い可用性を買う」という行為の一部が、顧客側の構成に移っていることを示す。リージョンレベルの数字は、単に EC2 を契約した結果として得られるのではなく、複数 AZ にまたがる配置を行った状態で意味を持つ。したがって数字を比較するときは、その数字を成立させるために追加インスタンス、ロードバランシング、データ複製、フェイルオーバー設計などの費用を誰が負担するのかまで含めなければならない。

AWS の公開クレジット段階は 10%、30%、100% だが、ここでも百分率だけでは不十分である。Region-Level SLA なら対象リージョンの Amazon EC2 月額請求、Instance-Level SLA なら対象 Single EC2 Instance の請求が計算基礎になり、Reserved Instance の一回限りの前払いなどは除外される。クレジットは通常、将来 AWS に支払う Amazon EC2 料金に充当される。(Amazon Web Services, Inc.)

同じ Single EC2 Instance について、リージョン水準とインスタンス水準の Claim を重ねることもできない。請求は事故後、第 2 請求周期の末までに行い、日時、リージョンや AZ、Resource ID、障害を裏付ける request log などが必要になる。必要情報を提出できなければクレジットを受けられない。(Amazon Web Services, Inc.)

ここでも「100% credit」という語が、事業損失全額の補償を意味しない。100% は、定義された請求基礎に対する 100% である。分母を見ずにクレジット比率だけを見るのは、保険金額を見ずに補償率だけを比べることに近い。

Google Compute Engine――一分の境界が測定を変える

Google Compute Engine の SLA は、Monthly Uptime Percentage と Financial Credit を、複数ゾーン構成では Project・Region 単位、Single Instance ではインスタンス単位で測定する。約束される水準は配置方法や Network Service Tier によって異なる。(Google Cloud)

さらに重要なのが時間粒度だ。Downtime Period は一分以上連続する Downtime と定義され、部分的な一分や、一分未満の断続的な Downtime は Downtime Period に算入されない。(Google Cloud)

この一文は、監視システムの「障害」と SLA 上の「障害」が一致するとは限らないことを端的に示す。顧客のメトリクスが数秒単位の接続失敗を大量に検知したとしても、そのまま契約上の Downtime Period に変換できるわけではない。SRE のアラートと財務上のクレジット請求には、別の定義層がある。

公開されている Financial Credit は 10%、25%、100% の段階制で、顧客は受給資格が生じた時点から 60 日以内に Google technical support へ通知し、Downtime Period とその日時を示すログを提出する必要がある。月間の最大 Financial Credit は、SLO を満たさなかった Region における該当 Covered Services の当該月の料金を超えず、将来の Covered Service 利用に充当される。また、同一の停止について Single Instance と Instances in Multiple Zones の双方から重複してクレジットを得ることはできない。(Google Cloud)

現行ページは Previous versions の箇所で 2025 年 3 月 4 日を最終更新日として表示している。契約評価では、数字だけでなく参照した版を残すことにも意味がある。(Google Cloud)

Oracle――複数条項が当たっても足し算にはならない

Oracle の PaaS/IaaS Public Cloud Services Pillar では、Service によって Availability、Manageability、Performance の SLA が設定され得る。一見すると評価軸が増えるため救済も積み上がるように見えるが、公開条件はそう単純ではない。

Service Credit は、Service Commitment を満たさなかった具体的な Cloud Service に限定される。計算基礎も、Measured Period に実際に使用した該当 Non-Compliant Service の数量について顧客が支払った純料金である。したがって「Oracle Cloud 全体への支払額」が自動的に分母になるわけではない。(甲骨文)

Claim には、対象 Service、事故の状況、停止時間、Region、tenancy・compartment・affected resource の OCID、解決のために試みたこと、監査コンソールや OS event/log などの関連資料を含める。Oracle が Claim を検討するには、原因となった問題の発生から 60 暦日以内に受領されなければならない。(甲骨文)

さらに、一つの事故について複数の Service Level Agreement からクレジットを受ける権利が発生し得る場合、原則として最も高い Service Credit を提供する条項のみが適用され、同一事故について複数 SLA のクレジットを重ねて回収することはできない。購入モデルによってクレジットの付与先や利用期間、失効の扱いも異なる。

この重複不可は小さな契約技術に見えるが、経済的には重要だ。一事故が可用性、管理性、性能という複数の契約面に同時に触れたとしても、顧客が各割合を単純に合算できるとは限らない。契約は障害を複数のラベルで説明する一方、救済額が倍増しないよう境界を置いている。

IBM――SLO と SLA を分けると、構成費用が見える

IBM の resiliency 文書は、SLO と SLA を明確に分けて説明する。SLO は目標であり、契約上の保証そのものではない。一方、SLA は最低可用性と、その水準を下回った場合に顧客が受け得る Service Credit に関わる契約装置である。(IBM Cloud)

IBM Cloud VPC の例では SLO が 99.999% とされるが、その水準をワークロード側で十分に生かすためには、マルチゾーンリージョンの三つのゾーンそれぞれに一台、最低三台の virtual server instance と load balancer が必要だと説明する。二ゾーン二台に減らせば resiliency は下がり、さらに単一サーバーにすれば実効的な水準は下がる。(IBM Cloud)

ここで数字の裏側にある価格が露出する。高可用性はクラウド事業者の内部設備だけで作られるのではない。顧客も冗長な資源を購入し、複数ゾーンに配置し、アプリケーションをフェイルオーバー可能に設計する必要がある。その費用は SLA のクレジット表には載らないが、高い可用性を実際のワークロードで得るための価格の一部である。

IBM はその境界を shared responsibility として、クラウドそのものの resiliency と recovery は IBM 側、ワークロードの resiliency と recovery は顧客側の責任と説明する。(IBM Cloud)

これは他社より信頼できるという順位付けではない。重要なのは、サービスの可用性とワークロードの可用性が別物だという構造を明示している点である。

クレジット率より、分母を見る

SLA の経済分析で最も見落とされやすい変数は、クレジット率ではなく分母である。

Cloudflare の例では、冒頭の 3.47% は該当 Service の月額経常料金に掛かる。AWS の段階制は、影響したリージョンの EC2 月額請求または対象 Single Instance を基礎にする。Google は該当 Region の Covered Service または Single Instance を基礎にし、Oracle は不適合となった具体的 Service の実使用純料金を基礎にする。

だから「100% credit」という表示が複数社に存在しても、100% が指している金額は同じではない。

仮に、ある企業がクラウド事業者へ月に 100 万円を支払っていても、障害対象として認定されたサービスやリージョン、資源に対応する料金が 10 万円なら、100% のクレジット段階に入ったとしても、それだけで企業全体の 100 万円や、障害で生じた事業損失全体が返ることを意味しない。これは特定社の Claim の推計ではなく、「クレジット率 × 対象料金」という契約構造から出る一般的な含意だ。

契約のリスク移転量を考えるなら、

回収可能なクレジット ≒ 適格な料金基礎 × 適用クレジット率

と、その後に検証、除外、上限、重複不可を置く方が、見出しの可用性だけを見るより正確である。

そして事業側で残るリスクは別にある。障害による売上逸失、復旧費、顧客補償、信用低下などから、実際に回収できたクレジットや別途移転したリスクを差し引いた残りだ。SLA はその全額を消すためのものではない。

請求権には有効期限がある

SLA の Service Credit は、自動的に現金化される資産ではない。公開条件を見る限り、多くの場合、顧客が一定の期間内に手続きを行い、対象事故を特定し、証拠を提出し、事業者による検証を受けることで初めて利用できる条件付きの権利である。

Cloudflare では事故後 5 営業日以内の通知が必要で、その後の証拠提出にも期限がある。AWS は事故後、第 2 請求周期末まで。Google は受給資格発生から 60 日以内。Oracle は問題発生から 60 暦日以内だ。要求される内容には時間、Region や Zone、URL、traceroute、Resource ID、OCID、request log、監査ログ、OS event などが並ぶ。(Cloudflare)

これは可観測性を単なるエンジニアリング設備ではなく、契約を行使するための設備に変える。

障害をリアルタイムに検知できても、数週間後に正確な timestamp、対象資源、エラー、利用者影響を再現できなければ、インシデント対応としては十分でも、Claim の証拠としては弱いことがある。逆に、SLA に合わせて証拠を保存するなら、ログ保持期間、タイムゾーンの統一、資源 ID の履歴、外形監視の保存、チケットとの紐付けまでが財務統制の一部になる。

「99.99% を契約した」だけでは足りない。その違反を後から再現できるようにして初めて、クレジット請求権は実務的な価値を持つ。

誰が故障面を支配し、誰が証明するのか

ここには情報の非対称性がある。

クラウド事業者は自社ネットワークやハイパーバイザー、内部制御面について顧客より多くのテレメトリを持つ。一方、顧客は自社アプリケーション、利用者影響、エンドツーエンドのトランザクション失敗を事業者よりよく知る。障害の境界が両者をまたぐほど、どちらか一方のログだけで全体像を作るのは難しくなる。

だから共同測定は厚大な仕組みである必要はないが、決定的で再現可能である必要がある。いつ始まり、いつ終わったか。どの Region、Zone、Service、resource が対象だったか。どの利用者が影響を受けたか。事業者の障害情報と顧客の外形監視は一致するか。この共通の最小記録があれば、Claim は「感じた障害」から「検証できる事故」へ変わる。

また、故障面を支配する側にどの証拠があり、顧客側に何を要求するのかを見える化することも重要だ。公開標準条件が顧客にログ提出義務を置くことと、障害原因に関する情報をどちらがより多く保有しているかは別の問題である。調達時には、クレジット率だけでなく、事故時に取得できるログ、事後レポート、タイムライン、外部測定の扱いを確認する方が実務的だ。

重複不可は、補償の膨張を止める

AWS では同じ Single EC2 Instance について Region-Level と Instance-Level の Claim を積み重ねられない。Google では同一 Downtime を Single Instance と Instances in Multiple Zones の双方としてクレジット化できない。Oracle では同一事故に複数 SLA が適用可能でも、原則として最高額となる一つの救済に限定される。Cloudflare は SLA 違反に対する Service Credit を唯一の救済とし、年間上限も設けている。(Amazon Web Services, Inc.)

これらは契約の周辺条項ではない。リスクの価格を決める中心部である。

複雑なクラウド障害は、単一の症状だけを生むとは限らない。可用性低下、API の失敗、管理操作不能、性能悪化が同じ事故から生じ得る。しかし契約が事故単位、資源単位、SLA 単位で重複を制限すれば、技術的には複数の故障面が存在しても、財務的な救済は一つに束ねられる。

買い手が各 SLA の最大クレジットを足し算して「最悪時にはこれだけ戻る」と見ると、実際の契約上限を過大評価する可能性がある。

ワークロードの停止は、単一 SLA の外側で起きる

エンドツーエンドのワークロードには、compute だけでなく、network、load balancing、storage、DNS、identity、database、顧客自身のアプリケーション、外部 API など複数の依存関係がある。

そのうち一つのサービスが自らの SLA を満たしていることと、ワークロード全体が利用可能であることは同義ではない。逆に、一つのサービスが SLA に違反したとしても、そのサービスの料金クレジットがワークロード全体の損害と同額になるわけでもない。

IBM が cloud resiliency と workload resiliency を分けていることは、この境界を理解するうえで有用だ。(IBM Cloud)

したがって企業が本当に買っているものを評価するには、名目ラベルと依存関係を分けなければならない。「99.99% の compute」を買っているのではなく、特定の配置要件、ネットワーク、ストレージ、運用手順、監視、復旧方式を含む依存グラフを買っている。

SLA はそのグラフの一部について、どの故障を事業者側の契約責任とし、違反時にどの金額までクレジットとして返すかを記述しているにすぎない。

高い SLA は、顧客側の支出を増やすことがある

AWS の Region-Level SLA が複数 AZ 配置を前提とし、IBM が 99.999% の VPC SLO を十分に生かす例として三ゾーン三サーバーとロードバランサーを示すことは、可用性の経済学にもう一つの論点を加える。(Amazon Web Services, Inc.)

より強い可用性を得るためには、顧客自身がより多くの資源を購入する場合がある。

これは矛盾ではない。冗長性には費用がかかる。だが、SLA の数字だけを調達比較に使うと、その費用が見えなくなる。99.99% を成立させる構成の月額総費用と、99.5% の単一インスタンス構成の月額総費用は異なる。さらにデータ複製、監視、運用複雑性、障害訓練、アプリケーション改修まで含めれば差は広がる。

つまり高可用性の価格は、クラウド料金表の一行にも SLA の一行にも収まらない。

買い手が比較すべきなのは、SLA の数字ではなく、その SLA が意味を持つ構成の総費用と、それでも移転されずに残る損失である。

移転されない損失には、別の値札が必要だ

SLA がカバーしない損失は、消えるわけではない。顧客のバランスシートに残る。

その残余リスクは、少なくとも四つの方法で扱える。アーキテクチャで停止確率や復旧時間を下げる。保険など別の契約で金銭リスクを移転する。調達交渉で測定、上限、証拠、救済を変更する。そして障害や価格変更、契約変更に耐えられない依存関係については、退出可能性を設計しておく。

ここで重要なのは、全部を SLA に押し込まないことだ。

クラウド SLA は、サービス事業者が受け入れる限定されたリスクを価格とともに示す道具として読む方が正確である。事業損失全体の補償契約として読むと、期待と契約の間に大きな空白ができる。

買うべきなのは数字ではなく、境界だ

したがって調達時には、各 SLA を一枚の比較表に落とすなら、可用性パーセントは一列で十分だ。その隣に、測定単位、必要構成、停止時間の定義、クレジットの基礎料金、対象資源、申請期限、証拠、除外、上限、重複不可、版変更の条件を並べるべきである。

Cloudflare の冒頭の 60 分をもう一度見ると、この考え方がよく分かる。

「100% uptime のサービスで 60 分落ちた」という文章だけなら、大きな契約違反に見える。しかし公開式を使えば、30 日の月、全面影響、控除なしという例で、クレジット比率は約 3.47%になる。31 日なら約 3.36%だ。それを掛けるのも、事業損失ではなく対象 Service の月額経常料金である。そして Claim を成立させるには期限と証拠と検証がある。

この差が SLA の本体だ。

クラウド SLA が約束しているのは「障害が起きない世界」ではない。障害が起きたとき、その一部をどう測定し、誰が証明し、いくらまで料金リスクとして事業者側へ移すのかという、限定された制度である。

見出しのパーセントは入口にすぎない。契約として本当に買っているものは、その下に書かれた境界である。

出典