責任共有モデルとリージョン/AZ

🎓 レベル：標準　|　重要度：A（必須）

📎 前提：クラウドとは・IaaS/PaaS/SaaS　|　関連：コストとスケーリングの考え方・キャパシティと信頼性設計

要点（BLUF）

責任共有モデル：クラウドは「クラウドのセキュリティ（物理・ハード・仮想化）」を守り、利用者は「クラウドの中のセキュリティ（OS設定・権限・データ）」を守る。どこで線が引かれるかは IaaS/PaaS/SaaS で動く。
リージョンは地理的に離れたデータセンター群、**AZ（アベイラビリティゾーン）**はリージョン内で電源・空調・ネットワークを分離した区画。AZ をまたいで配置すれば、片方の障害で全滅しない。
可用性は「祈り」でなく「配置の設計」で作る。単一AZ依存は単一障害点。

概念 ── 「クラウドの安全」と「クラウドの中の安全」

よくある誤解が「クラウドを使えばセキュリティはクラウド任せ」。実際は 責任が共有されます。境界は IaaS/PaaS/SaaS（クラウドとは・IaaS/PaaS/SaaS）で変わり、上のレイヤーほど利用者の責任が減ります。

flowchart TB
    subgraph cloud["クラウドが守る（of the cloud）"]
      c1["物理データセンター・電源・空調"]
      c2["ハードウェア・ネットワーク機器"]
      c3["仮想化基盤（ハイパーバイザ）"]
    end
    subgraph user["利用者が守る（in the cloud）"]
      u1["OS・ミドルウェアの設定とパッチ（IaaS）"]
      u2["アクセス権限（IAM）の設計"]
      u3["データの暗号化・分類・バックアップ"]
      u4["アプリのコードと脆弱性"]
    end
    cloud --> user

肝は「データと権限は常に利用者の責任」という点。クラウドがいくら堅牢でも、権限をガバガバに設定すれば情報は漏れます。クラウド/コンテナセキュリティの深掘りはサイバーセキュリティへ。ここは最小権限・シークレット管理の実務の入口まで（ConfigMap・Secret・ボリューム）。

仕組み ── リージョン・AZ・エッジの三層

クラウドの物理は3つの粒度で広がっています。

flowchart TB
    subgraph region["リージョン（例：東京リージョン）"]
      subgraph az1["AZ-1（独立した電源・空調）"]
        d1["データセンター群A"]
      end
      subgraph az2["AZ-2（独立した電源・空調）"]
        d2["データセンター群B"]
      end
      subgraph az3["AZ-3（独立した電源・空調）"]
        d3["データセンター群C"]
      end
    end
    edge["エッジ拠点（CDN：世界中で利用者に近い配信）"]

リージョン：国・都市単位の大きなまとまり。リージョン間は数十〜数百msの距離。**法令・データ所在地（データレジデンシ）**もここで効く。
AZ：1リージョン内の2〜3以上の独立区画。電源・冷却・物理ネットワークが分離されているので、片方が落ちてももう片方は生きる。AZ間は低遅延（数ms）で結ばれ、同期レプリケーションに使える。
エッジ：CDN の配信拠点。利用者に物理的に近い場所からコンテンツを返して速くする。

可用性設計の基本は「最低2つのAZにまたがって冗長化」。さらに災害対策（DR）で別リージョンに複製します。

動く例 ── マルチAZ配置の考え方

ロードバランサの背後に、2つのAZへ分散してサーバを置く構成（疑似・要最新確認）。片方のAZが落ちても、もう片方で受け続けられます。

# 疑似Terraform：サブネットを2つのAZに分けて作る
resource "cloud_subnet" "app_a" {
  zone = "asia-northeast1-a"   # AZ-1
  cidr = "10.0.1.0/24"
}
resource "cloud_subnet" "app_b" {
  zone = "asia-northeast1-b"   # AZ-2（別の電源系統）
  cidr = "10.0.2.0/24"
}
# ロードバランサが両AZのサーバへ振り分ける → 片AZ障害でも継続

詳しい冗長化・縮退の設計はキャパシティと信頼性設計で扱います。

なぜAZを分けるのか

相関する障害を断ち切るため：同じ電源・同じラックに固めると、停電・冷却故障でまとめて落ちる。AZは「同時には壊れにくいように物理を分けた単位」。冗長化は「独立に壊れる」ことが前提なので、独立性を物理で担保する。
責任の分担を明確にするため：「ハードが壊れたら別AZへ逃がす」のは設計（利用者の責任）で、AZという独立区画を提供するのがクラウドの責任。両者がかみ合って初めて可用性が出る。

⚠️ よくある誤解・落とし穴

「クラウドだから勝手に冗長化される」→ 既定では単一AZのことが多い。マルチAZは利用者が明示的に設計するもの。
「リージョンとAZは同じ」→ リージョン＝地理的まとまり、AZ＝その中の独立区画。リージョン障害に備えるなら別リージョンへのDRが要る。
「セキュリティはクラウド任せ」→ データ・権限・OS設定は利用者の責任。設定ミス由来の漏洩が事故の大半。
「とりあえず一番近いリージョン」→ データレジデンシ（法令上どこに置けるか）・他サービスとの近さ・料金差も効く。要件で選ぶ。
「全AZ・全リージョンに広げれば安心」→ 冗長は金もデータ同期の遅延も増える。要件に対し過剰な冗長はコスト事故（コストとスケーリングの考え方）。

対応ラボ

なし（概念トピック）。マルチAZ配置の実コードはモジュール化と環境分離で扱います。