IaC で「何を1つのスタック（＝デプロイ / state の単位）に閉じ込めるか」は、ツールが変わっても通用する設計判断です。本記事では 変更頻度・影響範囲（blast radius）・分離境界 の3軸で、AWS / Azure / GCP 横断のベストプラクティス構造をパターンに分けて整理します。
クラウド横断の「スタック」対応関係
同じ「スタック」でも、state の持ち方と分離境界がクラウドごとに違います。まずこの粒度の差を押さえます。
| 概念 | AWS | Azure | GCP |
|---|---|---|---|
| 標準IaC | CloudFormation / CDK | Bicep / ARM | Terraform（+ CFT） |
| デプロイ単位 | CloudFormation Stack | Deployment Stack | Terraform state（root module） |
| state管理 | CFNサービスが保持 | Azure側が保持 | リモートbackend（GCS等）を自前管理 |
| 分離境界 | Account + Region | Subscription + Resource Group | Project |
| 組織階層 | Organizations → OU → Account | Management Group → Subscription → RG | Organization → Folder → Project |
| ランディングゾーン | Control Tower / LZA | ALZ + Azure Verified Modules | Cloud Foundation Toolkit |
| スタック間参照 | Outputs/Export-Import・CDK props | module outputs・既存リソースID参照 | remote_state・linked stacks |
2026時点の補足：Terraform Stacks は GA 済みで linked stacks によりスタック間依存を構成として宣言可能。Azure は ALZ が AVM + Deployment Stacks 前提へ刷新され、Blueprint は廃止方向。GCP は Deployment Manager が実質終息し、Terraform / CFT が事実上の標準。
パターンA：レイヤード分割（変更頻度 × 影響範囲）
最も基礎となる分割軸です。下層ほど「めったに変わらない／壊れると広範囲」、上層ほど「頻繁に変わる／影響は局所」。この順に依存方向を一方向へ固定します。
矢印は「上層が下層の出力に依存する」方向です。各レイヤーを実装するスタック単位の対応は次のとおり。
| レイヤー | AWS | Azure | GCP |
|---|---|---|---|
| L0 Foundation | Org/Account Stack（LZA） | Mgmt Group / Subscription vending | 0-bootstrap / 1-org |
| L1 Security | SecurityStack（IAM/KMS/SCP） | Policy + Identity（AVM） | iam / org-policy module |
| L2 Network | NetworkStack | Connectivity（Hub/Spoke） | 3-networks |
| L3 Data | Database/StorageStack | Data RG（AVM resource） | data project + module |
| L4 App | AppStack | Workload RG | 5-app-infra |
| L5 Ops | OpsStack | Management（Log Analytics） | logging / monitoring module |
- 依存は一方向のみ。 L4 が L2 の VPC ID を参照するのは可、L2 が L4 を参照するのは禁止（循環防止）。
-
stateful と stateless を必ず分離。 DB を含む L3 は誤って
destroyされないよう独立スタック＋削除保護を付ける。 - 参照は疎結合を優先。 AWS は Export/Import より CDK props 受け渡し、Terraform は remote_state より明示的 input／linked stacks が壊れにくい。
パターンB：環境分離（dev / stg / prd）
レイヤー構造（パターンA）は固定したまま、同一コードを型付き設定で環境ごとに複製します。差分はコードでなく設定値に閉じ込めます。
「環境境界」をどこに置くかが設計判断。強い分離（推奨）ほど事故波及が小さくなります。
| 分離強度 | AWS | Azure | GCP |
|---|---|---|---|
| 強（推奨） | 環境ごとに 別Account | 環境ごとに 別Subscription | 環境ごとに 別Project |
| 中 | 同Account・別Stack/Region | 同Sub・別Resource Group | 同Project・別module/workspace |
| 弱（小規模のみ） | 同Stack・パラメータ差替 | 同Deployment・param差替 | 同state・var差替 |
本番(prd)は必ず最強の分離境界（別アカウント / サブスク / プロジェクト）に置く。dev/stg はコスト都合で1段緩めても可だが、prd と non-prd の間だけは絶対に境界を割る。
パターンC：エンタープライズ組織階層（ランディングゾーン）
規模が増えたら、プラットフォーム（共通基盤）とワークロード（個別アプリ）を組織階層レベルで分離します。各クラウドの公式LZの形がほぼ正解です。
AWS（Organizations + Control Tower / LZA）
- Platform と Workload を階層で分ける：共通基盤チームと各アプリチームの権限境界を組織構造そのものに落とす。
- 監査 / ログは独立アカウント（プロジェクト）へ隔離：ワークロード側の権限ではログを改ざんできないようにする。
- 新環境の払い出しを自動化（account / subscription / project vending）：手動で境界を増やさない。
どこまで適用するか
| 規模 | 適用範囲 | 境界戦略 |
|---|---|---|
| 個人 / 小規模PoC | パターンA（軽量版）。L0-L1 省略可、L2-L5 を分割 | 1アカウント内・env は設定差替〜RG/module分割 |
| SMB / 単一プロダクト | パターンA + B | prd と non-prd だけ境界を割る |
| マルチチーム / 規制下 | A + B + C（公式LZ準拠） | 環境×ワークロードで境界、払い出し自動化 |
共通の鉄則：① 依存は下→上の一方向 ② stateful は隔離して削除保護 ③ 環境差はコードでなく型付き設定へ ④ prd 境界は最強の分離単位に ⑤ ログ / 監査は別境界へ。クラウドが変わっても、この5点は同じ。