マルチアカウント運用 Organizations Control Tower Landing Zone Identity Center

1. なぜマルチアカウント運用か — 全6軸からの架橋 + AWS本番運用第7軸結節点

1-1. マルチアカウント運用の必要性 — 単一アカウントの限界と4つの分離

AWS を本格的に活用する組織が最初に直面する壁のひとつが、単一アカウント設計の限界です。スタートアップ時代は「まず1アカウントで動かす」が合理的ですが、組織規模・ワークロード数・規制要件が増えると、単一アカウントは構造的な問題を顕在化させます。

単一アカウントの4つの限界

限界1: ブラスト半径が組織全体に及ぶ

単一アカウントでは、あるチームのオペレーションミス (誤ったポリシー変更・大量リソース削除) が全チームの本番環境に影響します。本番・開発・テスト環境がアカウントレベルで分離されていないため、「開発用スクリプトが本番DBに接続する」類の事故が原因の追跡なしに起きます。アカウント境界は AWS が保証するセキュリティ境界であり、VPC や IAM ポリシーより上位の隔離を実現します。

限界2: IAM ポリシーが複雑化しコスト管理が不透明になる

複数チーム・複数プロジェクトが同一アカウントを共有すると、IAM ポリシーの競合・権限昇格リスク・タグ設計の混在が複合的に発生します。コスト配賦の観点でも、Cost Allocation Tags だけでは部門別・プロジェクト別の正確な集計に限界があり、月次の費用配分に人的コストがかかります。

限界3: 規制・コンプライアンス要件への対応が困難

金融・医療・公共系のワークロードは PCI-DSS や HIPAA 準拠環境を他ワークロードから完全に分離する要件があります。単一アカウントで논理的分離のみに依存すると、監査対応で「本当に分離されているか」の証明コストが大きくなります。アカウント分離は監査証跡としての客観的な証拠になります。

限界4: 組織拡張時のスケーラビリティ不足

チームが増えるたびに IAM ロール・ポリシーを手作業で管理するアプローチはスケールしません。新チームへのアカウント払い出し・標準設定の適用・SCP による制御を自動化する基盤として、AWS Organizations と Control Tower が存在します。

マルチアカウント設計が実現する4つの分離

【4つの分離】

  1. セキュリティ境界の分離
  本番アカウント ↔ 開発アカウント: IAM 権限の完全分離
  アカウント間のブラスト半径を AWS レベルで遮断

  2. 課金境界の分離
  チーム / プロジェクト別アカウント: 正確なコスト配賦
  Cost Explorer の Account別集計で月次費用を自動配分

  3. 運用境界の分離
  本番変更手順 ↔ 開発変更手順: 承認フローの差別化
  SCP により本番アカウントの危険操作をポリシーレベルで禁止

  4. コンプライアンス境界の分離
  規制対象ワークロード専用アカウント: 監査範囲の明確化
  Control Tower Detective Controls でコンプライアンス逸脱を自動検知

中堅エンジニアが陥る3つの誤解

誤解1: 「VPC 分離で十分」→ VPC は L3 分離。アカウント境界は API レベル・課金レベルの分離で次元が異なります。IAM ロールの引き受け操作も、アカウント境界があれば明示的な許可が必要になります。

誤解2: 「アカウント数が増えると管理が複雑」→ Organizations × Control Tower により、アカウント払い出し・ベースライン適用・SCP 管理が自動化され、単一アカウントより運用コストが下がります。

誤解3: 「移行コストが高い」→ Landing Zone の構築は Control Tower が自動化します。既存アカウントの Organizations への参加も登録手順で完結し、ゼロから再構築は不要です。

単一アカウント vs マルチアカウント 比較表

この比較が示すように、マルチアカウント設計の複雑さは「管理の複雑さ」ではなく「設計の複雑さ」です。初期設計コストをかけることで、長期的な運用コストが大幅に下がります。Organizations × Control Tower は、この初期設計コストを自動化するためのサービスです。

1-2. 全6軸からの架橋 — 第7軸の位置付け

これまでの6軸で構築した本番基盤は、マルチアカウント設計なしでは「組織スケール」に対応できません。第7軸のマルチアカウント運用は、前の6軸それぞれと交差点を持つ統合結節点です。

• IAM入門4巻 (特にVol2: マルチアカウント設計) → 本記事で Organizations 全体像・SCP・IAM Identity Center に昇格。IAM Vol2 の Cross-Account Role 設計が本番規模の OU 階層で機能する仕組みを実装します。

• EKS本番運用3巻 → マルチアカウント EKS クラスタ設計: Shared Services アカウントから IRSA ロールを委任し、環境ごとにクラスタアカウントを分離する構成の基礎になります。

• 復旧・運用編4巻 → Cross-Account DR: AWS Backup の Cross-Account コピーポリシー・S3 Cross-Account Replication は Organizations の Trusted Access を前提とします。

• AIシリーズVol1 → マルチアカウント Bedrock 基盤: AI ワークロード専用アカウントを分離し、Bedrock の呼び出し権限を IAM Identity Center で集中管理する設計に発展します。

• セキュリティ本格運用Vol1 → Organizations 全体のセキュリティ統合管理: Delegated Administrator によるセキュリティサービスの集約管理が本記事の前提です。

• コスト最適化Vol1 → マルチアカウントのコスト集約: Organizations 管理アカウントの CUR で全アカウントを一元管理し、Cost Allocation Tags をアカウント境界と組み合わせてチーム別コストを自動配賦します。

【第7軸 マルチアカウント運用 — 全6軸統合結節点】

  IAM設計 ────→ Identity Center Permission Set 統合管理
  EKS設計 ────→ マルチアカウント EKS クラスタ分離
  復旧設計 ───→ Cross-Account Backup / Replication
  AI設計 ─────→ Bedrock 専用アカウント + 権限委任
  セキュリティ→ Delegated Admin / 集約管理
  コスト最適化→ 全アカウント CUR 一元管理
 ↓ すべてがマルチアカウント基盤の上に成立
  Organizations × Control Tower × Landing Zone

1-3. 本記事の到達ゴール5点

本記事を読了し実装を進めることで、以下5点を習得できます。

ゴール1: マルチアカウント設計3本柱 (分離 / 統制 / 集約) を理解できる

Organizations OU 階層の設計原則・SCP の適用範囲・Trusted Access の仕組みを図解で理解し、自社のアカウント構造に当てはめて設計できます。

ゴール2: Organizations OU 階層 + SCP を設計・実装できる

Root → Security / Infrastructure / Workloads の OU 階層を Terraform で実装し、SCP による本番アカウント保護 (リージョン制限・危険 API 拒否) を適用できます。

ゴール3: Control Tower Landing Zone を構築できる

Control Tower の初期セットアップ・Guardrails (予防的/探知的) の設定・Account Factory によるアカウント払い出し自動化を実装できます。

ゴール4: IAM Identity Center Permission Set を設計できる

SSO 統合から Permission Set 設計・グループベースのアカウントアクセス管理・CLIでの一時認証 (aws sso login) を運用できます。

ゴール5: 詰まりポイント7選 + 演習5問でアンチパターンを正解パターンに変換できる

Organizations SCP の order of precedence・Control Tower のカスタマイズ制限・IAM Identity Center の外部 IdP 連携など、実装時に必ず直面する7つの詰まりポイントを先読みし、正しい実装パターンを選択できます。

本記事は第7軸の入口です。マルチアカウント設計の全体像を習得した後、§2以降で Organizations の実装・Control Tower の構築・IAM Identity Center の設計を順に学びます。AWS本番運用の7軸すべてが揃うことで、エンタープライズ規模のクラウド基盤の設計・実装・運用を一貫して担当できるエンジニアになれます。

本記事の章構成と学習マイルストーン

前の13巻でインフラの「6軸」を構築しました。本記事でその統合管理基盤を確立します。単独のサービス設計から、組織全体のガバナンス設計へ。この視点の転換が第7軸学習の核心です。§2の3本柱整理から実装に入りましょう。

2. マルチアカウント設計3本柱整理 — 分離 / 統制 / 集約 + Organizations全体像

マルチアカウント設計は「分離 / 統制 / 集約」の3本柱で体系化できます。単一アカウントで全ワークロードを運用すると、1つのセキュリティ事故が全環境に波及し、IAM 権限管理も複雑化します。AWS Organizations を中核として3本柱を実装することで、ブラスト半径最小化・ガバナンス一元化・可視化集約を同時に実現します。

2-1. マルチアカウント設計3本柱の全体像

3本柱はそれぞれ独立した価値を持ちますが、分離が基盤となり、統制が分離を強化し、集約が全体を可視化するという依存関係があります。

【3本柱の依存関係】

  分離 (Isolation)
 ↓ アカウント境界ができて初めて
  統制 (Control)
 ↓ SCP / Guardrails が意味を持ち
  集約 (Aggregation)
 ↓ 全アカウントを横断して可視化できる

アカウント数の目安: 小規模チーム (5〜20名) でも最低8アカウント (Management / Log Archive / Security / Network / Production / Staging / Development / Sandbox) の構成を推奨します。アカウント数を増やすコストよりも、単一アカウントの管理コスト・リスクの方が大きくなります。

単一アカウントで全ワークロードを運用した場合の主な問題点:

柱1: 分離 (Isolation) — ブラスト半径の最小化

アカウント分離の最大の目的はブラスト半径 (Blast Radius) の最小化です。本番環境で不審なアクティビティが発生しても、開発・ステージング・セキュリティの各アカウントには影響が波及しません。

推奨アカウント最小構成:

Management Account→ 請求一括 / Organizations / SCP 管理のみ (ワークロード禁止)
Log Archive Account  → CloudTrail / Config / CUR の S3 バケット集約専用
Security Account  → セキュリティツール / 集約専用 (本記事では1行架橋)
Network Account→ VPC / Transit Gateway / Direct Connect 集中管理
Production Account→ 本番ワークロード
Staging Account→ ステージング環境
Development Account  → 開発環境 (開発者全員共用 または チーム別)
Sandbox Account→ 個人実験用 (SCP で本番相当リソース禁止)

柱2: 統制 (Control) — ガバナンスの一元化

Service Control Policy (SCP) は Organizations 階層に適用できる IAM ポリシーで、Member アカウントの管理者でさえ SCP の禁止範囲外のアクションを実行できません。

SCP 評価ロジック:

【SCP 評価ロジック】

有効な権限 = 管理ポリシー (IAM ポリシー) ∩ SCP

例1: SCP が Allow (全サービス許可) + IAM が Allow (S3) → S3 操作 ✅
例2: SCP が Deny (ap-southeast-1 禁止) + IAM が Allow → ap-southeast-1 操作 ❌
例3: Management Account → SCP が適用されない → IAM ポリシーのみ有効

重要: SCP は「最大許容範囲」を制限する。
  SCP が許可しても、IAM ポリシーが許可しなければ実行不可。
  SCP だけでは権限付与できない。必ず IAM ポリシーが必要。

柱3: 集約 (Aggregation) — 組織全体の可視化

集約により、複数アカウントにまたがるログ・セキュリティ状態・コストを単一のダッシュボードで把握できます。

2-2. AWS Organizations 全体像

OU 階層3-tier 基本形

【Organizations OU 階層構造 (推奨基本形)】

Root
├── Management (管理)
│  └── Management Account (SCP 管理 / 請求 / Config 一括)
│
├── Core (インフラ基盤)
│  ├── Log Archive Account
│  ├── Security Account
│  └── Network Account
│
├── Workload (ワークロード)
│  ├── Production OU
│  │  └── Production Account(s)
│  ├── Staging OU
│  │  └── Staging Account(s)
│  └── Development OU
│  └── Development Account(s)
│
└── Sandbox (実験)
└── Sandbox Account(s) (各開発者または試験用)

SCP 設計パターン — Deny List vs Allow List

本記事では Deny List を基本とし、段階的に禁止ルールを追加する設計を推奨します。全サービスを Allow List で管理すると、新しい AWS サービスを使うたびに SCP 更新が必要になり運用負荷が高くなります。

Terraform で SCP を作成し OU に適用する基本例:

# 必須ガードレール: CloudTrail 無効化禁止 + Organizations 離脱禁止
resource "aws_organizations_policy" "deny_critical" {
  name  = "DenyCriticalActions"
  description = "全OUに適用する必須ガードレール"
  type  = "SERVICE_CONTROL_POLICY"

  content = jsonencode({
 Version = "2012-10-17"
 Statement = [
{
  Sid = "DenyCloudTrailDisable"
  Effect = "Deny"
  Action = [
 "cloudtrail:StopLogging",
 "cloudtrail:DeleteTrail",
 "cloudtrail:UpdateTrail"
  ]
  Resource = "*"
},
{
  Sid= "DenyLeaveOrganization"
  Effect= "Deny"
  Action= ["organizations:LeaveOrganization"]
  Resource = "*"
}
 ]
  })
}

# Workload OU にアタッチ
resource "aws_organizations_policy_attachment" "deny_critical_workload" {
  policy_id = aws_organizations_policy.deny_critical.id
  target_id = aws_organizations_organizational_unit.workload.id
}

§3 では OU 階層設計・Account Vending Machine の自動化・SCP の詳細設計パターンを解説します。

Control Tower を使うと、上記のアカウント・OU・SCP の初期構成を Landing Zone として自動セットアップできます。§4 で詳解します。

3. Organizations実践 (山場1) — OU階層 / SCP / Account Vending Machine / Account Closure

3-1. OU階層設計 — 3-tier基本形と規模別パターン

OU (Organizational Unit) はアカウントをグループ化する論理コンテナだ。SCP はOU単位で継承され、配下のすべてのアカウントに適用される。OU階層の設計はSCP適用範囲・アカウント分離・運用負荷に直結するため、後からの変更コストが高い。最初の設計を慎重に行うことが第一原則だ。

3-tier基本形 — AWS推奨のOU設計

Root
├── Security OU  ← セキュリティ基盤 (ログ集約 / 監査専用)
│├── Log Archive Account
│└── Audit Account
│
├── Infrastructure OU  ← 共有インフラ (ネットワーク / 共有サービス)
│├── Network Account(VPC / Transit Gateway / Direct Connect)
│└── Shared Services Account (CI/CD / Container Registry 等)
│
├── Workloads OU ← ビジネスワークロード (環境別に分割)
│├── Production OU
││└── Production Account(s)
│├── Staging OU
││└── Staging Account(s)
│└── Development OU
│ └── Development Account(s)
│
└── Sandbox OU← 個人実験用 (高コストリソース制限SCP適用)
 └── Sandbox Account(s)

OUを移動するとSCPが再評価され、アカウントのリソースアクセス権限が変わる可能性がある。移動前に適用SCP差分を必ず確認すること。

規模別 OU パターン

大規模組織では、事業部門 (Business Unit) × 環境 (SDLC) の2軸でOU階層を設計するAWS推奨パターンが有効だ。OU命名規則は「プレフィックス + 目的 + 環境」で統一する (例: prod-ecommerce-workload / dev-platform-sandbox)。

EKS本番運用Vol1のクラスター設計では、本番/ステージング/開発をOU単位で分離することで爆発半径を制御できる。ProductionアカウントのIRSAロール信頼ポリシーが本番OUのアカウントIDのみを参照するよう設計すれば、開発アカウントのワークロードが誤って本番リソースにアクセスするリスクをアカウント境界でゼロにできる。

Terraform による OU 階層管理

resource "aws_organizations_organizational_unit" "security" {
  name= "Security"
  parent_id = data.aws_organizations_organization.main.roots[0].id
}

resource "aws_organizations_organizational_unit" "workloads" {
  name= "Workloads"
  parent_id = data.aws_organizations_organization.main.roots[0].id
}

resource "aws_organizations_organizational_unit" "production" {
  name= "Production"
  parent_id = aws_organizations_organizational_unit.workloads.id
}

resource "aws_organizations_organizational_unit" "development" {
  name= "Development"
  parent_id = aws_organizations_organizational_unit.workloads.id
}

resource "aws_organizations_organizational_unit" "sandbox" {
  name= "Sandbox"
  parent_id = data.aws_organizations_organization.main.roots[0].id
}

3-2. SCP 設計実践 — 評価ロジックとポリシー例

SCP評価ロジック — Allow = 管理ポリシー ∩ SCP

SCP は IAM ポリシーより上位の制約として機能する。SCP が許可しない API コールは、IAM ポリシーが許可していても拒否される。重要な特性を整理する。

【SCP 評価の3原則】

原則1: 有効な権限 = IAM 管理ポリシー ∩ SCP
  → 両方でAllowされて初めて操作可能

原則2: SCP の Deny は絶対優先
  → IAM Administrator でも SCP Deny は上書き不可

原則3: Management Account は SCP 対象外
  → 管理アカウントに SCP を適用しても効果がない
  (管理操作専用アカウントにワークロードを置かない理由)

代表的な SCP パターン

リージョン制限SCP (承認リージョン以外を Deny):

{
  "Version": "2012-10-17",
  "Statement": [
 {
"Sid": "DenyNonApprovedRegions",
"Effect": "Deny",
"NotAction": [
  "iam:*",
  "organizations:*",
  "support:*",
  "sts:*"
],
"Resource": "*",
"Condition": {
  "StringNotEquals": {
 "aws:RequestedRegion": ["ap-northeast-1", "us-east-1"]
  }
}
 }
  ]
}

NotAction に iam:* / organizations:* / support:* / sts:* を指定するのは、これらがグローバルサービスでありリージョン指定ができないためだ。除外しないとIAM操作が全面禁止になる。

S3パブリックアクセス禁止SCP:

{
  "Version": "2012-10-17",
  "Statement": [
 {
"Sid": "DenyS3PublicAccess",
"Effect": "Deny",
"Action": [
  "s3:PutBucketPublicAccessBlock",
  "s3:DeletePublicAccessBlock"
],
"Resource": "*"
 },
 {
"Sid": "DenyS3ACLPublic",
"Effect": "Deny",
"Action": "s3:PutBucketAcl",
"Resource": "*",
"Condition": {
  "StringEquals": {
 "s3:x-amz-acl": ["public-read", "public-read-write", "authenticated-read"]
  }
}
 }
  ]
}

Terraform で SCP を管理し OU にアタッチする:

resource "aws_organizations_policy" "deny_non_approved_regions" {
  name  = "DenyNonApprovedRegions"
  description = "承認リージョン (ap-northeast-1/us-east-1) 以外を禁止"
  type  = "SERVICE_CONTROL_POLICY"
  content  = file("policies/deny-non-approved-regions.json")
}

resource "aws_organizations_policy_attachment" "deny_regions_workload" {
  policy_id = aws_organizations_policy.deny_non_approved_regions.id
  target_id = aws_organizations_organizational_unit.workloads.id
}

resource "aws_organizations_policy_attachment" "deny_regions_sandbox" {
  policy_id = aws_organizations_policy.deny_non_approved_regions.id
  target_id = aws_organizations_organizational_unit.sandbox.id
}

terraform-aws-modules/organizations モジュールを使えば、OU・SCP・アカウント管理を1つのモジュールで宣言的に管理できる。SCP JSONはポリシーファイルとして分離し、バージョン管理することで変更履歴を追跡可能にする。

AIシリーズVol1: Bedrock AgentsをCross-Accountで利用する場合は、SCPでBedrockのAPIコール (bedrock:InvokeModel / bedrock:InvokeModelWithResponseStream) を本番OUのみ許可し、SandboxアカウントからのBedrockアクセスをポリシーレベルで制限することでコスト制御とアカウント分離を両立できる。

3-3. Account Vending Machine — 自動プロビジョニング

Account Vending Machine (AVM) とは、新規AWSアカウントを標準化されたプロセスで自動プロビジョニングする仕組みだ。手作業でのアカウント作成はOU配置ミス・SCP適用漏れ・初期設定忘れが生じやすい。AVMはこれをコードと自動化で解決する。

Account Factory (Service Catalog) の仕組み

Control TowerのAccount Factoryは、Service CatalogのProductとして提供され、申請フォームの入力だけで新規アカウントを標準設定込みで払い出す。

sequenceDiagram
  participant Dev as 開発チーム
  participant SC as Service Catalog
  participant AF as Account Factory
  participant Org as Organizations
  participant CT as Control Tower
  Dev->>SC: 新規アカウント申請<br/>(アカウント名/OU/メール)
  SC->>AF: Account Factory 起動
  AF->>Org: CreateAccount API
  Org-->>AF: アカウントID 発行
  AF->>CT: Account Enrollment<br/>(Landing Zone 適用)
  CT-->>AF: Baseline設定完了<br/>(CloudTrail/Config/IAM)
  AF-->>Dev: アカウント払い出し完了<br/>(Login URL / 初期権限)
  Note over AF,CT: 全工程を自動化 / 承認フロー付きで2-5分で完了

Account Factory が払い出すアカウントには、Landing Zone のベースライン設定 (CloudTrail全リージョン有効化 / Config有効化 / Log Archiveへのログ転送) が自動適用される。手動での初期設定は不要になる。

Terraform による AVM — Account Factory for Terraform (AFT)

AFTを使えば、アカウント作成リクエスト自体をTerraformコードで管理できる。GitOpsフローでコードレビューを経てからアカウントが自動作成される。

module "new_product_account" {
  source = "./modules/aft-account-request"

  control_tower_parameters = {
 AccountEmail  = "product-team@example.com"
 AccountName= "product-team-production"
 ManagedOrganizationalUnit = "Production"
 SSOUserEmail  = "product-admin@example.com"
 SSOUserFirstName = "Product"
 SSOUserLastName  = "Admin"
  }

  account_tags = {
 Environment = "production"
 Team  = "product"
 CostCenter  = "product-division"
  }

  change_management_parameters = {
 change_requested_by = "platform-team"
 change_reason = "New production account for product team"
  }

  account_customizations_name = "production-customizations"
}

AFTのアカウントリクエストがApplyされると、CodePipelineが起動してアカウントを作成し、account_customizations_nameに対応するカスタマイズ (Budget設定 / IAMロール / Config Rules) が自動適用される。アカウント作成からIAM Identity Center権限の付与まで、すべてコードで管理できる状態になる。

3-4. Account Closure — 90日ルールと事前整理

AWSアカウントを閉鎖 (Close Account) する場合、即時削除されないことを必ず理解しておく。

Account Closure の3段階プロセス:

1. Close Account 実行
→ アカウントは「Suspended」状態に移行
→ 90日間はリソースへのアクセス不可 (再有効化は可能)

2. 90日間の Suspended 期間
→ 残存リソースにコストが発生し続ける場合がある
→ S3 ストレージ費用 / RDS スナップショット保管料等

3. 90日経過後
→ アカウントが完全削除
→ 再有効化不可 / 同一メールアドレスで再登録不可

Account Closure 前の必須整理リスト:

Organizations管理下のアカウントをCloseする場合は、Management Accountからのみ実行可能だ (organizations:CloseAccount アクション)。Member Accountの管理者コンソールからではアカウントを閉鎖できない点に注意する。

4. Control Tower実践 (山場2) — Landing Zone / Guardrails / Account Factory / Customizations for CT

AWS Control Tower は Landing Zone を自動構成し、Organizations・CloudTrail・Config・IAM Identity Center を統合的にセットアップするマルチアカウント管理サービスだ。§3 の Organizations + SCP で「拒否リスト型の制御」を実装したなら、Control Tower はその上に「標準化された環境構築とガバナンス自動化」を追加する。本セクションでは Landing Zone の設計から Guardrails 管理、Customizations for Control Tower (CfCT) による IaC 化まで実践的に解説する。

復旧・運用編 Vol4 (Multi-Region A/A 構成)の Cross-Region DR 設計は、Control Tower の Landing Zone マルチリージョン展開と組み合わせることで、DR 対象アカウントを Organizations の適切な OU に自動配置し、DR コストを最適化できる。

4-1. Control Tower 全体像 — Landing Zone と Guardrails

Landing Zone の構成要素:

Guardrails の 3 分類:

必須 (Mandatory) Guardrails は Landing Zone 有効化と同時に全 OU に自動適用され、変更不可だ。CloudTrail の全リージョン有効化・Log Archive Account への S3 集約・Config の有効化などが含まれる。強く推奨 (Strongly Recommended) Guardrails は MFA の強制・Root MFA・IAM Access Analyzer の有効化など、追加適用を強く推奨するものだ。

4-2. Landing Zone セットアップ実践

前提条件チェックリスト:

前提条件チェック:
├── Management Account に Organizations が有効化されているか
│└── 推奨: 新規 Organizations から構築 (既存への後付けは競合リスクあり)
├── 対応リージョンが設定されているか (Home Region + Governed Regions)
├── IAM Identity Center が未設定か
│└── 既存設定がある場合は事前削除が必要
├── CloudTrail が Management Account で未設定か
│└── Landing Zone が上書き設定するため、事前確認が必要
└── 管理者権限を持つ IAM ユーザー or Role でログインしているか
 └── Landing Zone の有効化には AdministratorAccess 相当の権限が必要

Terraform で Landing Zone を管理する:

resource "aws_controltower_landing_zone" "main" {
  manifest_json = jsonencode({
 governedRegions = ["ap-northeast-1", "us-east-1"]
 organizationStructure = {
security = { name = "Security" }
sandbox  = { name = "Sandbox" }
 }
 centralizedLogging = {
accountId = var.log_archive_account_id
configurations = {
  loggingBucket = {
 retentionDays = 365
  }
  kmsKeyArn = var.kms_key_arn
}
enabled = true
 }
 securityRoles = {
accountId = var.audit_account_id
 }
 accessManagement = {
enabled = true
 }
  })
  version = "3.3"
}

governedRegions に複数リージョンを指定することで、Landing Zone がマルチリージョンで CloudTrail・Config を自動有効化する。centralizedLogging の retentionDays はコンプライアンス要件に応じて設定すること — PCI DSS では 1 年以上が必要だ。

4-3. Guardrails 管理 — OU 別適用パターン

Guardrails は OU 単位で適用する。全 OU に同一の Guardrails を適用するのではなく、OU の用途に合わせて適用範囲を設計するのが実践的だ。

SCP ポリシー評価シーケンス (mermaid02):

sequenceDiagram
  participant IAM as IAM リクエスト
  participant SCP as SCP 評価
  participant Policy as IAM ポリシー評価
  participant Action as アクション実行
  IAM->>SCP: API コール発生
  alt SCP に Deny が存在
 SCP-->>IAM: 明示的 Deny → 即時拒否
  else SCP に Allow なし (implicit Deny)
 SCP-->>IAM: 暗黙的 Deny → 拒否
  else SCP に Allow あり
 SCP->>Policy: IAM ポリシー評価へ
 alt IAM ポリシーに Deny
Policy-->>IAM: 明示的 Deny → 拒否
 else IAM ポリシーに Allow
Policy->>Action: アクション実行許可
Action-->>IAM: 成功
 else IAM ポリシーに Allow なし
Policy-->>IAM: 暗黙的 Deny → 拒否
 end
  end
  Note over SCP,Policy: SCP は IAM ポリシーの上位制約 / 両方で Allow が必要

SCP の評価は IAM ポリシーよりも先に行われる。SCP で Allow されていない API コールは IAM ポリシーが Allow していても拒否される。この「上位制約」という特性を理解することが、Guardrails 設計の核心だ。

Terraform で Control Tower Guardrail を有効化する:

強制 (Preventive) Guardrail の有効化は aws_controltower_control リソースで管理できる。

data "aws_organizations_organizational_unit" "workload" {
  parent_id = data.aws_organizations_organization.main.roots[0].id
  name= "Workload"
}

resource "aws_controltower_control" "deny_root_access" {
  control_identifier = "arn:aws:controltower:ap-northeast-1::control/AWS-GR_RESTRICT_ROOT_USER"
  target_identifier  = data.aws_organizations_organizational_unit.workload.arn
}

resource "aws_controltower_control" "enable_mfa" {
  control_identifier = "arn:aws:controltower:ap-northeast-1::control/AWS-GR_MFA_ENABLED_FOR_IAM_CONSOLE_ACCESS"
  target_identifier  = data.aws_organizations_organizational_unit.workload.arn
}

resource "aws_controltower_control" "enable_s3_versioning" {
  control_identifier = "arn:aws:controltower:ap-northeast-1::control/AWS-GR_S3_VERSIONING_ENABLED"
  target_identifier  = data.aws_organizations_organizational_unit.workload.arn
}

control_identifier には Control Tower が管理する Guardrail の ARN を指定する。ARN は AWS コンソールの Control Tower > Controls から各 Control の詳細を確認することで取得できる。OU を指定する target_identifier には OU の ARN を使う。

Guardrail のドリフト検出:

Control Tower は Guardrails のドリフト (コンソール外での意図しない変更) を定期的に検出し、Organizations の委任管理者アカウント (Audit Account) に SNS で通知する。ドリフトが検出された場合は Control Tower コンソールの「Noncompliant」ステータスから対象 Guardrail を再適用できる。Terraform で管理している場合は terraform plan でドリフトを検出し terraform apply で修正する。

4-4. Customizations for Control Tower (CfCT) による IaC 化

Customizations for Control Tower (CfCT) は、AWS Service Catalog・SCP・Config Rules を YAML マニフェストでコード管理するソリューションだ。新規アカウントが Organizations に参加した際に、CfCT が自動的に CloudFormation テンプレート・SCP を適用する。

CfCT の自動適用フロー:

新規アカウント作成 (Account Factory)
 ↓
Organizations への参加
 ↓
Control Tower の Account Enrollment イベント
 ↓
CfCT の CodePipeline トリガー
 ↓
manifest.yaml を読み込み
 ↓
対象 OU に CloudFormation / SCP / Config Rules を自動適用

manifest.yaml 例:

region: ap-northeast-1
version: 2021-03-15

cloudformation-rules:
  - name: budget-alarm
 description: Budget alarm per account
 resource_file: templates/budget-alarm.yaml
 deployment_targets:
organizational_units:
  - Workload
 regions:
- ap-northeast-1

scp-rules:
  - name: deny-non-approved-regions
 description: Restrict to approved regions only
 policy: policies/deny-non-approved-regions.json
 deployment_targets:
organizational_units:
  - Workload
  - Sandbox

cloudformation-rules セクションで各アカウントに適用する CloudFormation テンプレートを定義する。Budget アラーム・IAM Roles・Config Rules など、アカウント初期設定をコードで宣言的に管理できる。コンソールでの手動変更は行わず、すべて manifest.yaml 経由で変更することでドリフトを防ぐ。

Account Factory for Terraform (AFT) を使えば Terraform でアカウント作成を自動化できる。

module "aft" {
  source  = "aws-ia/control_tower_account_factory/aws"
  version = "~> 1.0"

  ct_management_account_id = var.management_account_id
  log_archive_account_id= var.log_archive_account_id
  audit_account_id= var.audit_account_id
  aft_management_account_id= var.aft_management_account_id
  ct_home_region  = "ap-northeast-1"
  tf_backend_secondary_region = "us-east-1"
}

AFT を使うことで、Terraform のコードレビューを経て新規アカウントが自動作成され、CfCT のカスタマイズが自動適用される。アカウント作成から初期設定完了まで全自動化できる。

AFT Account Request — アカウント作成の Terraform 宣言:

AFT を導入すると、新規アカウントの作成も Terraform コードで宣言できる。

module "sandbox_account" {
  source = "./modules/aft-account-request"

  control_tower_parameters = {
 AccountEmail  = "sandbox-team@example.com"
 AccountName= "sandbox-team-01"
 ManagedOrganizationalUnit = "Sandbox"
 SSOUserEmail  = "sandbox-admin@example.com"
 SSOUserFirstName = "Sandbox"
 SSOUserLastName  = "Admin"
  }

  account_tags = {
 Environment = "sandbox"
 Team  = "platform"
 CostCenter  = "engineering"
  }

  change_management_parameters = {
 change_requested_by = "platform-team"
 change_reason = "New sandbox account for testing"
  }

  account_customizations_name = "sandbox-customizations"
}

AFT のアカウントリクエストが Terraform Apply されると、CodePipeline が起動してアカウントを作成し、指定した account_customizations_name に対応する CfCT カスタマイズが自動適用される。アカウントの作成から IAM Identity Center 権限の付与まで、すべてコードで管理できる状態になる。

CfCT と AFT の使い分け:

小規模な環境や既存アカウントのカスタマイズ適用には CfCT が適している。大規模な環境でアカウント作成からすべてコード管理したい場合は AFT を採用する。両者を組み合わせることも可能だ。

5. IAM Identity Center統合 — Permission Set / Account Assignment / SAML/SCIM (IAM Vol2発展)

5-1. IAM Identity Center の全体像

IAM Multi-Account設計 Vol2 で学んだ Cross-Account Role は、各アカウントに IAM Role を個別作成する手間がかかる。IAM Identity Center (旧 AWS SSO) はこの課題を解決し、Permission Set と Account Assignment の組み合わせで一元的なアクセス管理を実現する。

IAM Role 直接管理 vs Identity Center

Identity Center のコンポーネントは3つ:

• Identity Store: ユーザー・グループのリポジトリ (ローカルまたは外部 IdP と同期)
• Permission Set: IAM ポリシー + セッション期間 の組み合わせ定義
• Account Assignment: どのユーザー/グループが、どのアカウントに、どの Permission Set で入れるかのマッピング

Identity Center を使う利点は、ユーザーがアクセスするたびに一時認証情報 (STS トークン) を発行する点だ。長期の IAM アクセスキーを各開発者に配布する必要がなく、ポータル (my.awsapps.com/start) 経由でブラウザログイン → アカウント選択 → コンソール/CLI 認証を統一して行える。

# AWS CLI v2 による Identity Center 認証設定
aws configure sso
# → SSO start URL: https://d-xxxxxxxxxx.awsapps.com/start
# → SSO Region: ap-northeast-1
# → アカウント選択 → Permission Set選択 → プロファイル名入力

# 設定後のログイン
aws sso login --profile my-sso-profile

# プロファイルを使用してコマンド実行
aws s3 ls --profile my-sso-profile

5-2. Permission Set 設計実践

Permission Set は「誰が何をできるか」を定義する設計の核心だ。役割 × 環境の組み合わせでパターン化すると最小権限を維持しやすい。

Permission Set 設計パターン

Terraform では aws_ssoadmin_permission_set リソースで定義する:

data "aws_ssoadmin_instances" "main" {}

locals {
  sso_instance_arn = tolist(data.aws_ssoadmin_instances.main.arns)[0]
}

resource "aws_ssoadmin_permission_set" "admin" {
  name = "AdminAccess"
  instance_arn  = local.sso_instance_arn
  session_duration = "PT4H"
  relay_state= "https://console.aws.amazon.com/"
  tags = { ManagedBy = "terraform" }
}

resource "aws_ssoadmin_managed_policy_attachment" "admin" {
  instance_arn = local.sso_instance_arn
  permission_set_arn = aws_ssoadmin_permission_set.admin.arn
  managed_policy_arn = "arn:aws:iam::aws:policy/AdministratorAccess"
}

resource "aws_ssoadmin_permission_set" "dev_readonly" {
  name = "DevReadOnly"
  instance_arn  = local.sso_instance_arn
  session_duration = "PT8H"
  tags = { ManagedBy = "terraform" }
}

resource "aws_ssoadmin_managed_policy_attachment" "dev_readonly" {
  instance_arn = local.sso_instance_arn
  permission_set_arn = aws_ssoadmin_permission_set.dev_readonly.arn
  managed_policy_arn = "arn:aws:iam::aws:policy/ReadOnlyAccess"
}

カスタムポリシーを Permission Set に付与する場合は aws_ssoadmin_customer_managed_policy_attachment を使う。インラインポリシーは aws_ssoadmin_permission_set_inline_policy で定義できる。

Permission Set とカスタムポリシーの組み合わせ例

# カスタムインラインポリシーで特定 S3 バケットのみ許可する Permission Set
resource "aws_ssoadmin_permission_set" "s3_limited" {
  name = "S3LimitedAccess"
  instance_arn  = local.sso_instance_arn
  session_duration = "PT8H"
}

resource "aws_ssoadmin_permission_set_inline_policy" "s3_limited" {
  instance_arn = local.sso_instance_arn
  permission_set_arn = aws_ssoadmin_permission_set.s3_limited.arn
  inline_policy = jsonencode({
 Version = "2012-10-17"
 Statement = [{
Effect= "Allow"
Action= ["s3:GetObject", "s3:PutObject", "s3:ListBucket"]
Resource = [
  "arn:aws:s3:::my-project-bucket",
  "arn:aws:s3:::my-project-bucket/*"
]
 }]
  })
}

Permission Set に複数のポリシー (マネージド + インライン + カスタムマネージド) を組み合わせることもできる。ただし Permission Set 単体に付与できるマネージドポリシーは最大10件、インラインポリシーは1件に制限されるため、複雑な権限要件はカスタムマネージドポリシーに集約するのが望ましい。

5-3. Account Assignment 自動化

Account Assignment は「どのグループが、どのアカウントに、どの Permission Set で入れるか」のマッピングだ。手動 GUI 操作は漏れが生じるため、Terraform で全件管理する。

# 管理者グループを本番アカウントへ割り当て
resource "aws_ssoadmin_account_assignment" "admin_to_prod" {
  instance_arn = local.sso_instance_arn
  permission_set_arn = aws_ssoadmin_permission_set.admin.arn

  principal_id= data.aws_identitystore_group.admins.group_id
  principal_type = "GROUP"

  target_id= var.production_account_id
  target_type = "AWS_ACCOUNT"
}

# 開発者グループを開発アカウントへ割り当て
resource "aws_ssoadmin_account_assignment" "dev_to_dev" {
  instance_arn = local.sso_instance_arn
  permission_set_arn = aws_ssoadmin_permission_set.dev_readonly.arn

  principal_id= data.aws_identitystore_group.developers.group_id
  principal_type = "GROUP"

  target_id= var.development_account_id
  target_type = "AWS_ACCOUNT"
}

OU 配下の全アカウントに一括適用する場合は、aws_organizations_organizational_unit データソースで子アカウント一覧を取得し、for_each で Account Assignment を生成する:

data "aws_organizations_organizational_unit_child_accounts" "workload" {
  parent_id = var.workload_ou_id
}

resource "aws_ssoadmin_account_assignment" "dev_all_workload" {
  for_each = {
 for acct in data.aws_organizations_organizational_unit_child_accounts.workload.accounts :
 acct.id => acct
  }

  instance_arn = local.sso_instance_arn
  permission_set_arn = aws_ssoadmin_permission_set.dev_readonly.arn
  principal_id = data.aws_identitystore_group.developers.group_id
  principal_type  = "GROUP"
  target_id = each.key
  target_type  = "AWS_ACCOUNT"
}

5-4. SAML 2.0 / SCIM 連携

外部 IdP (Okta / Azure AD / Google Workspace) と Identity Center を SAML 2.0 で連携することで、企業の既存認証基盤をそのまま AWS アクセス管理に活用できる。

IdP 別 SAML 連携手順

SCIM 自動プロビジョニング

SCIM (System for Cross-domain Identity Management) を有効化すると、IdP でのユーザー追加・削除・グループ変更が Identity Center に自動同期される。手動でユーザーを管理する必要がなくなり、人事異動時の権限剥奪漏れを防止できる。

SCIM 設定手順:
1. Identity Center の設定 → 自動プロビジョニング → 有効化
2. SCIM エンドポイント URL とアクセストークンをコピー
3. IdP (例: Okta) の SCIM 設定に URL とトークンを入力
4. グループ同期対象を選択 → プロビジョニング開始

SCIM 連携後は IdP グループと Identity Center グループが自動同期し、Account Assignment に反映される。結果として、IdP でのグループ追加 → 自動的に AWS アカウントへのアクセス権が付与される、というフローが完成する。

SCIM 同期状態の確認

SCIM プロビジョニングのステータスは AWS CLI で確認できる:

# Identity Center インスタンス ARN を取得
INSTANCE_ARN=$(aws sso-admin list-instances--query 'Instances[0].InstanceArn' --output text)

# 全 Permission Set を一覧表示
aws sso-admin list-permission-sets--instance-arn "$INSTANCE_ARN"--query 'PermissionSets[]' --output table

# 特定アカウントへの Account Assignment を確認
aws sso-admin list-account-assignments--instance-arn "$INSTANCE_ARN"--account-id "123456789012"--permission-set-arn "arn:aws:sso:::permissionSet/ssoins-xxx/ps-yyy"--query 'AccountAssignments[]' --output table

Identity Center のアクセスログは CloudTrail に記録される。sso-admin.amazonaws.com イベントソースでフィルタリングすると、Permission Set の変更や Account Assignment の追加/削除を監査できる。

IAM Identity Center 公式ドキュメント

6. 詰まりポイント7選 図解

6-1. OU 設計ミス（OU 移動後の SCP 再評価で意図せぬアクセス制限）

Organizations で OU 構造を変更すると、移動先の OU に適用されている SCP がそのアカウントに即時適用される。テスト環境アカウントを本番 OU に誤って移動すると、本番 SCP の Deny ルールがテスト環境の許可済み操作をブロックし、デプロイが止まる。

根本原因: OU 移動の影響範囲（どの SCP が新たに適用されるか）を事前に確認せずに移動を実行してしまう。

OU 設計のベストプラクティス（Terraform）:

resource "aws_organizations_organizational_unit" "workloads" {
  name= "Workloads"
  parent_id = data.aws_organizations_organization.main.roots[0].id
}

resource "aws_organizations_organizational_unit" "production" {
  name= "Production"
  parent_id = aws_organizations_organizational_unit.workloads.id
}

resource "aws_organizations_organizational_unit" "staging" {
  name= "Staging"
  parent_id = aws_organizations_organizational_unit.workloads.id
}

resource "aws_organizations_account" "app_prod" {
  name= "app-production"
  email  = "aws+app-prod@example.com"
  parent_id = aws_organizations_organizational_unit.production.id

  tags = {
 Environment = "production"
 Team  = "platform"
  }
}

6-2. SCP 評価優先度の誤解（Deny 優先 / Allow 要件 / Implicit Deny）

SCP は IAM ポリシーと評価ロジックが異なる。「SCP で Allow すれば操作できる」と誤解し、SCP のみに Allow を書いて IAM ポリシーを忘れるケースや、逆に「SCP で Allow していれば IAM の Deny は無効」と誤解するケースが頻発する。

根本原因: SCP は「何を許可しないか」を定義するガードレールであり、単独では権限を付与しない。SCP Allow + IAM Allow の AND 条件で実効権限が決まる。

SCP 設計例（Deny ベース設計）:

{
  "Version": "2012-10-17",
  "Statement": [
 {
"Sid": "DenyNonApprovedRegions",
"Effect": "Deny",
"Action": "*",
"Resource": "*",
"Condition": {
  "StringNotEquals": {
 "aws:RequestedRegion": [
"ap-northeast-1",
"us-east-1"
 ]
  }
}
 },
 {
"Sid": "DenyRootUser",
"Effect": "Deny",
"Action": "*",
"Resource": "*",
"Condition": {
  "StringLike": {
 "aws:PrincipalArn": "arn:aws:iam::*:root"
  }
}
 }
  ]
}

6-3. Account Closure 90 日ルール（コスト発生リソース残留）

AWS アカウントを閉鎖（Close）しても、90 日間はアカウントが「Suspended」状態で残存する。この期間中も閉鎖前に作成されたリソース（S3、RDS スナップショット等）の費用が継続して発生する場合があり、予想外の請求が来る。

根本原因: Account Closure = 即時リソース削除ではない。Suspended 期間中もストレージコストが発生し続けることを知らない。

閉鎖前クリーンアップスクリプト（Python）:

import boto3

def cleanup_account_before_closure(regions):
 """アカウント閉鎖前に課金リソースを削除する"""
 for region in regions:
  session = boto3.Session(region_name=region)

  s3 = session.client('s3')
  for bucket in s3.list_buckets().get('Buckets', []):
bucket_name = bucket['Name']
paginator = s3.get_paginator('list_object_versions')
for page in paginator.paginate(Bucket=bucket_name):
 objects = page.get('Versions', []) + page.get('DeleteMarkers', [])
 if objects:
  s3.delete_objects(Bucket=bucket_name, Delete={
'Objects': [{'Key': o['Key'], 'VersionId': o['VersionId']}
for o in objects]
  })
s3.delete_bucket(Bucket=bucket_name)
print(f"S3 バケット削除: {bucket_name}")

  rds = session.client('rds')
  for snap in rds.describe_db_snapshots(SnapshotType='manual').get('DBSnapshots', []):
rds.delete_db_snapshot(DBSnapshotIdentifier=snap['DBSnapshotIdentifier'])
print(f"RDS スナップショット削除: {snap['DBSnapshotIdentifier']}")

if __name__ == '__main__':
 cleanup_account_before_closure(['ap-northeast-1', 'us-east-1'])

6-4. CfCT（Customizations for Control Tower）更新時のドリフト

Control Tower で Landing Zone をカスタマイズするために CfCT（AWS Customizations for Control Tower）を導入すると、manifest.yaml を更新するたびにパイプラインが走る。このとき、コンソールで手動変更した StackSet が CfCT の定義と競合し、ドリフトが発生してパイプラインが失敗する。

根本原因: コンソールでの手動変更を「後で manifest.yaml に反映する」つもりが、反映前に次の CfCT 更新を実行してしまう。

manifest.yaml 正しい記述例:

region: ap-northeast-1
version: 2021-03-15

cloudformation-resources:
  - name: GuardrailCustom
 template-file: templates/guardrail-custom.yaml
 parameter-file: parameters/guardrail-custom.json
 deploy-to-ou:
- OU: Workloads
 regions:
- ap-northeast-1
- us-east-1
 deploy-method: stack_set
 wave: 1

6-5. Permission Set ドリフト（コンソール手動変更 vs Terraform 管理）

IAM Identity Center（旧 SSO）の Permission Set を Terraform で管理しているにもかかわらず、コンソールで緊急対応として手動変更する。次回 terraform apply で手動変更が上書きされ、緊急対応が消える事故が発生する。

根本原因: 緊急時にコンソールで変更した後、Terraform コードを更新し忘れる。

Permission Set の Terraform 管理例:

resource "aws_ssoadmin_permission_set" "developer" {
  name = "DeveloperAccess"
  instance_arn  = tolist(data.aws_ssoadmin_instances.main.arns)[0]
  session_duration = "PT8H"
  relay_state= "https://console.aws.amazon.com/"

  tags = {
 Team= "engineering"
 ManagedBy = "terraform"
  }
}

resource "aws_ssoadmin_managed_policy_attachment" "developer_readonly" {
  instance_arn = tolist(data.aws_ssoadmin_instances.main.arns)[0]
  managed_policy_arn = "arn:aws:iam::aws:policy/ReadOnlyAccess"
  permission_set_arn = aws_ssoadmin_permission_set.developer.arn
}

resource "aws_ssoadmin_permission_set_inline_policy" "developer_custom" {
  instance_arn = tolist(data.aws_ssoadmin_instances.main.arns)[0]
  permission_set_arn = aws_ssoadmin_permission_set.developer.arn
  inline_policy = jsonencode({
 Version = "2012-10-17"
 Statement = [{
Sid= "AllowECRPush"
Effect= "Allow"
Action= ["ecr:GetAuthorizationToken", "ecr:BatchCheckLayerAvailability",
"ecr:PutImage", "ecr:InitiateLayerUpload", "ecr:UploadLayerPart",
"ecr:CompleteLayerUpload"]
Resource = "*"
 }]
  })
}

6-6. 委任管理者未設定（Delegated Administrator 未設定で管理操作が集中）

AWS Organizations の一部サービス（Security Hub、Config、GuardDuty 等）は、管理アカウントが直接操作するのではなく、Delegated Administrator アカウントに権限を委任する設計が推奨される。Delegated Administrator を設定しないと、管理アカウントでしか一元管理できず、管理アカウントのアクセスが集中してセキュリティリスクが高まる。

根本原因: Organizations の委任管理者の仕組みを知らず、管理アカウントの IAM ユーザーで全管理操作を行っている。

Delegated Administrator 設定（Terraform）:

resource "aws_organizations_delegated_administrator" "security_hub" {
  account_id  = var.audit_account_id
  service_principal = "securityhub.amazonaws.com"
}

resource "aws_organizations_delegated_administrator" "config" {
  account_id  = var.audit_account_id
  service_principal = "config.amazonaws.com"
}

resource "aws_organizations_delegated_administrator" "backup" {
  account_id  = var.audit_account_id
  service_principal = "backup.amazonaws.com"
}

6-7. 監査ログ集約（CloudTrail / Config 集約設定漏れ）

Organizations に新しいアカウントが追加されるたびに、そのアカウントの CloudTrail・AWS Config を手動で有効化する必要があると思い込み、設定漏れが発生する。実際には Organizations レベルで一括有効化できる仕組みがある。

根本原因: CloudTrail の「Organizations Trail」と Config の「Organizations Conformance Pack」の存在を知らず、アカウントごとに個別設定している。

Organizations Trail 設定（Terraform）:

resource "aws_cloudtrail" "organization_trail" {
  name  = "organization-trail"
  s3_bucket_name = aws_s3_bucket.audit_logs.bucket
  is_organization_trail= true
  is_multi_region_trail= true
  enable_log_file_validation = true
  include_global_service_events = true

  event_selector {
 read_write_type  = "All"
 include_management_events = true

 data_resource {
type= "AWS::S3::Object"
values = ["arn:aws:s3:::"]
 }
  }
}

resource "aws_config_organization_conformance_pack" "security_baseline" {
  name = "security-baseline-pack"
  template_body = file("${path.module}/config-conformance-pack.yaml")

  excluded_accounts = [var.management_account_id]
}

復旧・運用編 Vol1: Multi-Region Backup/DR の Backup 集約と合わせて CloudTrail 集約を設計することで、監査ログと DR 証跡を一元管理できます。

AI シリーズ Vol1: Bedrock Agents の API 呼び出しも CloudTrail に記録されます。管理アカウントで集約モニタリングすることで、AI ワークロードのコスト・セキュリティを横断的に把握できます。

セキュリティ本格運用 Vol1 の Audit Manager と連携すると、自動監査証跡が取得可能になります。CloudTrail + Config + Audit Manager の三点セットで規制対応・内部統制を効率化できます。

7. アンチパターン→正解パターン変換演習 (Terraform + SCP json + Identity Center yaml 3形式)

本セクションでは「壊れたコードを直せ」方式で、Organizations・Control Tower・Identity Center 設定のよくあるミスを修正する演習を 5 問用意しました。

演習解答セクションへ

演習 1: OU 移動後の SCP Deny ブロック（Terraform）

❌ 問題のコード（どこが問題か？）

# 問題: Production OU の SCP に us-east-1 以外の Deny がある
# テスト環境アカウントを誤って Production OU に移動してしまった
resource "aws_organizations_account" "dev_app" {
  name= "dev-application"
  email  = "aws+dev@example.com"
  parent_id = aws_organizations_organizational_unit.production.id  # 問題: production OU
}

# Production OU の SCP (us-east-1以外をDeny)
# → dev_app は ap-northeast-1 でも作業するので操作がブロックされる

✅ 正解コード

# 修正: dev アカウントは Development OU に配置
resource "aws_organizations_account" "dev_app" {
  name= "dev-application"
  email  = "aws+dev@example.com"
  parent_id = aws_organizations_organizational_unit.development.id  # 修正: development OU

  # OU 移動前に aws organizations list-policies-for-target で SCP 確認必須
  lifecycle {
 ignore_changes = [parent_id]  # 誤移動防止: 手動移動後に terraform apply が上書きするのを防ぐ
  }
}

ポイント解説: OU 移動は即時 SCP 再評価を引き起こします。移動先の SCP を事前に aws organizations list-policies-for-target --target-id <ou-id> で確認してから実行してください。Terraform では lifecycle.ignore_changes = [parent_id] でアカウント移動の誤上書きを防止できます。

演習 2: SCP の Allow ベース設計ミス（SCP JSON）

❌ 問題のコード

{
  "Version": "2012-10-17",
  "Statement": [
 {
"Sid": "AllowEC2Only",
"Effect": "Allow",
"Action": "ec2:*",
"Resource": "*"
 }
  ]
}

✅ 正解コード

{
  "Version": "2012-10-17",
  "Statement": [
 {
"Sid": "AllowAll",
"Effect": "Allow",
"Action": "*",
"Resource": "*"
 },
 {
"Sid": "DenyNonEC2Services",
"Effect": "Deny",
"NotAction": [
  "ec2:*",
  "iam:*",
  "sts:*",
  "organizations:*",
  "cloudformation:*",
  "s3:*",
  "logs:*"
],
"Resource": "*"
 }
  ]
}

ポイント解説: 問題のコードは Allow ec2:* のみの SCP ですが、SCP は IAM ポリシーとの AND 条件で評価されるため、この SCP 単独では EC2 操作が「許可」されるわけではありません。SCP は FullAWSAccess（Allow All）を基盤に、不要なサービスを Deny + NotAction パターンで制限する設計が正解です。また IAM・STS・organizations などのコアサービスを除外（NotAction リストに追加）する必要があります。

演習 3: Control Tower Landing Zone のリージョン設定漏れ（Terraform）

❌ 問題のコード

resource "aws_controltower_landing_zone" "main" {
  manifest_json = jsonencode({
 governedRegions = ["us-east-1"]  # 問題: ap-northeast-1 が未設定
 organizationStructure = {
security = {
  name = "Security"
}
sandbox = {
  name = "Sandbox"
}
 }
 centralizedLogging = {
accountId = var.log_archive_account_id
configurations = {
  loggingBucket = {
 retentionDays = 365
  }
}
enabled = true
 }
 accessManagement = {
enabled = true
 }
  })
  version = "3.3"
}

✅ 正解コード

resource "aws_controltower_landing_zone" "main" {
  manifest_json = jsonencode({
 governedRegions = [
"us-east-1",
"ap-northeast-1"# 修正: 東京リージョンを追加
 ]
 organizationStructure = {
security = {
  name = "Security"
}
sandbox = {
  name = "Sandbox"
}
 }
 centralizedLogging = {
accountId = var.log_archive_account_id
configurations = {
  loggingBucket = {
 retentionDays = 365
  }
  accessLoggingBucket = {
 retentionDays = 365
  }
}
enabled = true
 }
 accessManagement = {
enabled = true
 }
  })
  version = "3.3"
}

ポイント解説: governedRegions に含まれていないリージョンは Control Tower の Guardrail（SCPs）が適用されません。東京リージョンで作業する場合は ap-northeast-1 を必ず含めてください。追加後に既存アカウントへの適用が自動的に行われます（数時間かかる場合あり）。

演習 4: Permission Set の過剰権限（Identity Center YAML）

❌ 問題のコード

# permission-sets.yaml — 問題: 全員に AdministratorAccess
PermissionSets:
  - Name: AllUsersAccess
 Description: "全ユーザー共通アクセス"
 SessionDuration: PT12H
 ManagedPolicies:
- arn:aws:iam::aws:policy/AdministratorAccess  # 問題: 過剰権限

AccountAssignments:
  - AccountId: "123456789012"
 PermissionSetName: AllUsersAccess
 PrincipalType: GROUP
 PrincipalId: "all-users-group-id"  # 問題: 全員に割り当て

✅ 正解コード（最小権限原則）

PermissionSets:
  - Name: DeveloperAccess
 Description: "開発者向けアクセス (読み取り + EC2/ECS/S3)"
 SessionDuration: PT8H
 ManagedPolicies:
- arn:aws:iam::aws:policy/ReadOnlyAccess
 InlinePolicy: |
{
  "Version": "2012-10-17",
  "Statement": [
 {
"Effect": "Allow",
"Action": ["ec2:Describe*", "ecs:Describe*", "ecs:List*",
  "s3:GetObject", "s3:PutObject", "ecr:*"],
"Resource": "*"
 }
  ]
}

  - Name: ReadOnlyAccess
 Description: "読み取り専用 (監査・ログ確認)"
 SessionDuration: PT4H
 ManagedPolicies:
- arn:aws:iam::aws:policy/ReadOnlyAccess

AccountAssignments:
  - AccountId: "123456789012"
 PermissionSetName: DeveloperAccess
 PrincipalType: GROUP
 PrincipalId: "dev-team-group-id"

  - AccountId: "123456789012"
 PermissionSetName: ReadOnlyAccess
 PrincipalType: GROUP
 PrincipalId: "audit-team-group-id"

ポイント解説: AdministratorAccess を全員に付与することは最小権限原則に反します。役割別（Developer / ReadOnly / Admin）に Permission Set を分割し、グループ（IdP の AD グループや Okta グループ）単位で割り当てます。AdministratorAccess は Break Glass アカウントと PlatformAdmin グループのみに限定してください。

演習 5: SCIM グループ同期前の手動割り当てで重複（Terraform）

❌ 問題のコード

# 問題: SCIM 同期設定前に手動でアカウント割り当てをしている
# → SCIM 同期後に同じグループが重複割り当てになる
resource "aws_ssoadmin_account_assignment" "manual" {
  instance_arn = tolist(data.aws_ssoadmin_instances.main.arns)[0]
  permission_set_arn = aws_ssoadmin_permission_set.developer.arn
  principal_id = "manually-created-group-id"  # 問題: SCIM前に手動作成
  principal_type  = "GROUP"
  target_id = var.account_id
  target_type  = "AWS_ACCOUNT"
}

# 後でSCIMを有効化すると同じグループが再度同期されて重複が発生する

✅ 正解コード

# 修正: SCIM 有効化後、IdP から同期されたグループ ID を使用
# Step 1: SCIM を先に有効化して IdP グループを同期
# Step 2: 同期されたグループ ID を Data Source で取得
data "aws_identitystore_group" "developers" {
  identity_store_id = tolist(data.aws_ssoadmin_instances.main.identity_store_ids)[0]

  alternate_identifier {
 unique_attribute {
attribute_path  = "DisplayName"
attribute_value = "aws-developers"  # IdP (Okta/AD) のグループ名
 }
  }
}

# Step 3: 同期済みグループ ID でアカウント割り当て
resource "aws_ssoadmin_account_assignment" "developers" {
  instance_arn = tolist(data.aws_ssoadmin_instances.main.arns)[0]
  permission_set_arn = aws_ssoadmin_permission_set.developer.arn
  principal_id = data.aws_identitystore_group.developers.group_id
  principal_type  = "GROUP"
  target_id = var.account_id
  target_type  = "AWS_ACCOUNT"
}

ポイント解説: SCIM 同期を有効化すると IdP のグループが自動的に Identity Center に同期されます。同期前に手動でグループを作成してアカウント割り当てすると、SCIM 同期後に同じグループが別の ID で再登録され、重複割り当てが発生します。SCIM を先に有効化してグループを同期してから、aws_identitystore_group Data Source で取得した ID を使って割り当てを行うのが正しい順序です。

まとめ・落とし穴10選を確認する

8. まとめ + Vol2予告 + 落とし穴10選 + 全6軸クロスリンク + 第7軸結節点完結宣言

8-1. 本記事で学んだこと

本記事では、AWS マルチアカウント運用の基礎として Organizations・Control Tower・IAM Identity Center の 3 つのコアサービスを実践的に解説しました。

• AWS Organizations: OU 階層設計・SCP によるガードレール・管理アカウントの役割分担
• Control Tower Landing Zone: 自動化されたマルチアカウント基盤の構築と Guardrail 管理
• IAM Identity Center: SCIM 連携による一元的な SSO・Permission Set の最小権限設計
• SCP 設計: Deny ベース設計と FullAWSAccess の組み合わせによる効果的なガードレール
• Delegated Administrator: 管理アカウントへのアクセス集中を防ぐ委任管理者パターン
• CloudTrail Organizations Trail: 全アカウントの監査ログを一括有効化・Audit アカウントに集約
• CfCT（Customizations for Control Tower）: manifest.yaml 一元管理で Landing Zone をコードとして管理
• Account Closure 90 日ルール: 閉鎖前のリソース削除と Suspended 期間中のコスト監視

8-2. 落とし穴 10 選

8-3. Vol2 予告: Service Catalog × Config × Organizations Policy Types 完全ガイド

8-4. マルチアカウント成熟度ロードマップ

フェーズ 1: 基盤構築（導入初期）
– Organizations で OU 階層を設計し、SCP（Deny ベース）でガードレールを設定
– Control Tower Landing Zone でマルチアカウント基盤を自動構築
– IAM Identity Center で SCIM 連携 SSO を有効化
– CloudTrail Organizations Trail で全アカウントの監査ログを集約

フェーズ 2: ガバナンス強化（3 か月後）
– Config Organizations Conformance Pack でコンプライアンスを自動チェック
– Delegated Administrator を Audit アカウントに設定し、管理アカウントへのアクセスを最小化
– CfCT（Customizations for Control Tower）でランディングゾーンをカスタマイズ
– Permission Set を役割別に細分化し、最小権限を徹底

フェーズ 3: 自動化・スケール（6 か月後）
– Organizations Tag Policy で全アカウントのタグ命名を強制
– Service Catalog で承認済みリソースのみデプロイ可能にする
– EventBridge + Lambda で新規アカウント追加時の自動セットアップ（ベースライン適用）
– Cost Explorer Organizations 集約ビューでアカウント別コストを一元管理

8-5. 本番移行前マルチアカウント設計チェックリスト

本番環境のマルチアカウント構成を展開する前に、以下の項目を確認してください。

• [ ] Organizations の OU 階層が確定し、各 OU に適切な SCP が適用されている
• [ ] Control Tower Landing Zone が有効化され、全ガバナンスリージョンが設定されている
• [ ] CloudTrail Organizations Trail が有効化され、Audit アカウント S3 バケットにログが集約されている
• [ ] IAM Identity Center に SCIM 連携が設定済みで、IdP グループが同期されている
• [ ] Permission Set が役割別（Developer / ReadOnly / Admin）に分割され、最小権限が徹底されている
• [ ] 管理アカウントへの日常的なアクセスが禁止され、Break Glass 手順が整備されている
• [ ] 各サービス（Security Hub / Config / GuardDuty）の Delegated Administrator が Audit アカウントに設定されている
• [ ] AWS Config Organizations Conformance Pack でコンプライアンスルールが全アカウントに適用されている

8-6. 第7軸完結宣言 + 全シリーズクロスリンク