初級ではクラウドを「借りる／従量課金」と捉えました。中級では、サービスの層・スケール・責任分界という「借り方」を見ます（データセンター・リージョン・AZといった"どこにあるか"の実体は、姉妹ユニット クラウドはどこにあるのか）。
概要 — まず全体をつかむ
詳細 — 1段階ずつ追う
これは何をする係？
クラウドは「どこまで任せるか」で層が分かれます。
- IaaS — 仮想サーバ・ストレージ・ネットワークなど基盤を借りる（OS以上は自分で）
- PaaS — 実行環境を借りる（OS・ミドルウェアはお任せ、アプリに集中）
- SaaS — 完成したアプリを使う（メール・表計算など）
- FaaS／サーバーレス — 関数だけ預け、実行時だけ課金・イベントで起動（サーバの存在を意識しない、任せる範囲のさらに上の層）
これらの土台にある仮想化には、OSごと積むVMと、カーネルを共有するコンテナがあります。
アニメーション『VMとコンテナの違い』を開く
登場人物メモ:
- ※1 マネージドサービス — DB・キューなどの運用を事業者に任せる形
- ※2 リージョン／AZ — 地域と、その中の独立した拠点。分散配置に使う
この部分をもっと深く（上級）
「落ちない」ではなく「落ちても続く」を設計します。
- SLA／SLO／SLI — 約束（SLA）、目標（SLO）、実測（SLI）。エラーバジェットで開発と安定のバランスを取る
- リージョン／AZ／エッジ — 地理的な階層。マルチAZで局所障害に、マルチリージョンで広域障害に備える
- フェイルオーバー — ヘルスチェック＋自動切替。データの複製と整合の設計が肝
やさしく言うと（初級）
家を建てる（オンプレ）のではなく、借りる／ホテルに泊まるイメージ。サーバやストレージを、必要なとき・必要な分だけ借りて使い、使った分だけ払います（※1 従量課金）。
電気や水道のように「蛇口をひねった分だけ」というのが近い感覚です。
登場人物メモ:
- ※1 従量課金 — 使った分だけ払う仕組み
- ※2 マネージドサービス — 運用の一部（更新・バックアップ等）を預けられる借り方
仕事の流れ
- 必要なサービスを選ぶ（層＝IaaS/PaaS/SaaS）
- 設定して即利用（プロビジョニング）
- 負荷に応じてオートスケールで増減
- 使った分だけ課金され、要らなければ破棄
この部分をもっと深く（上級）
- 水平スケール前提 — ステートレス化し、台数で捌く
- オートスケール — メトリクス（CPU・キュー長）や予測でインスタンスを増減
- IaC — インフラを宣言的コードで管理（冪等・再現可能・レビュー可能）
- イミュータブルインフラ — 変更せず作り直して置き換える
- 段階リリース — Blue-Green／カナリアで、リスクを小さく出す
やさしく言うと（初級）
- 必要になったら申し込む（画面やコマンドですぐ）
- すぐ使える（機械を買わなくてよい）
- 混んできたら増やす、要らなくなったら返す
- 使った分だけあとで請求される
設計の勘所
- 責任共有モデル — 基盤は事業者、設定・データ・権限は利用者の責任
- スケール — 水平スケール前提。マルチAZで可用性を上げる
- コスト最適化 — 使わない資源を止める、適切なサイズ、予約割引など
- ロックイン対策 — 事業者独自機能への依存度を意識（ハイブリッド／マルチクラウド）
責任共有の境界は層（IaaS／PaaS／SaaS）で上下しますが、データとアクセス権限は常に利用者の責任です。
アニメーション『クラウドの責任共有モデル』を開く
この部分をもっと深く（上級）
- 責任共有の実像 — 基盤は事業者、設定・データ・権限は利用者。事故の多くは利用者側の設定
- 可観測性 — ログ・メトリクス・トレース＋アラート。SLO違反を早く検知
- コスト最適化 — 適切なサイズ、スポット／リザーブド、使わない資源の停止、データ転送費
- マルチクラウド／ハイブリッド — ロックイン回避と可用性の一方で、運用は複雑化
やさしく言うと（初級）
- メリット — 初期費用が小さい／増減が自在（オートスケール）／運用の一部をお任せできる
- 注意点 — 使いすぎると高額／設定ミスで公開しやすい／預け先（事業者）に依存する
「増減が読めない」「早く始めたい」ならクラウドが向きます。
⚠️ うまくいかないとき
- コスト暴走 — オートスケールや消し忘れで請求が急増
- 設定ミスによる漏洩 — 公開設定・権限の誤り（責任共有の利用者側）
- ベンダーロックイン — 独自サービスに深く依存し乗り換え困難
- 障害の影響範囲 — リージョン障害が広範囲に及ぶことも（分散で緩和）
この部分をもっと深く（上級）
- リージョン／AZ障害の波及 — 依存が集中していると広範囲に影響
- コントロールプレーン障害 — 管理系が止まると、スケールや復旧操作ができない
- コスト暴走 — オートスケールや転送費、消し忘れ
- 設定ドリフト — 手作業の変更が積もり、再現できなくなる（IaCで防ぐ）
- カオスエンジニアリング — わざと壊して、回復力を平時に検証する考え方
やさしく言うと（初級）
- コストが膨らむ — 消し忘れ・使いすぎで想定外の請求
- 設定ミス — ストレージやDBを誤って公開し、情報漏洩
- 事業者依存 — 特定サービスに深く合わせると、乗り換えにくくなる
関連する知識
理解度チェック
そのまま解けます（成績は保存されません）。無料アカウントを作ると、学習の記録と進捗の山登りが始まります。
問1. クラウドの「責任共有モデル」で正しいのは？
問2. OSやサーバの管理を事業者に任せ、アプリの実行環境だけ使うクラウドの層はどれ？
問3. 「完成したアプリをそのまま使う」クラウドの層はどれ？
問4. 「関数だけ預け、実行された時だけ課金・イベントで起動する」層はどれ？
問5. クラウドの土台にある仮想化で、VMとコンテナの違いとして正しいのは？
問6. 層（IaaS/PaaS/SaaS）が変わっても、常に利用者の責任として残るのはどれ？
問7. 負荷（CPUやキュー長など）に応じてインスタンス数を自動で増減させる仕組みを、カタカナで何という？
問8. 特定事業者の独自機能に深く依存し、他社へ乗り換えにくくなる状態を「ベンダー◯◯イン」と呼ぶ。◯◯に入る語は？