AWS M&G Vol1｜Organizations×Control Tower×Service Catalog

なぜ Management & Governance Vol1 か — ガバナンス4層アーキテクチャ概観

ガバナンスなきマルチアカウントが招く混乱

AWSの利用が組織全体に拡大するにつれ、プロジェクト・チーム・環境ごとにアカウントを分割するマルチアカウント構成は今や標準アーキテクチャです。本番/ステージング/開発の分離、本番サービスごとの爆発半径（Blast Radius）の限定、コストの可視化——マルチアカウントはこれらを実現する最善の構造です。

しかし「とにかくアカウントを分けた」だけでは、次のような混乱に直面します。

• 管理不能な増殖: フラットに配置された50アカウントはどのアカウントが何の目的で存在するか追跡不能になります
• 権限の野放図な拡大: SCP未設定では開発者が誤って本番データを削除するコマンドを実行できてしまいます
• 設定漏れによるリスク: 手動で作成したアカウントはCloudTrailが未設定・S3パブリックアクセスが許可された状態で稼働し続けることがあります
• 標準化されないリソース展開: チームごとに異なる構成・ネーミング規則でリソースが作成され、コスト管理もセキュリティ監査も困難になります

これらは「気をつければ防げる」問題ではなく、仕組みとして構造的に防ぐ必要があります。AWS Management & Governanceサービス群が提供するのは、この「ガバナンスの仕組み」そのものです。

本記事では4つのコアサービス（Organizations・Control Tower・Service Catalog・CloudTrail Lake）が連携して形成するガバナンスフレームワークを、設計判断の根拠と実装コードも含めて体系的に解説します。個々のサービスドキュメントに分散した情報を「本番で使えるひとつの設計パターン」として統合することが、本記事の目的です。

ガバナンス4層アーキテクチャとは

AWSガバナンス基盤を4つの機能層として捉えると、各サービスの役割と依存関係が明確になります。

4層は独立したサービスの集合ではなく、下位層の上に上位層が成立する依存関係を持ちます。第1層（Organizations）でOU/SCP体系が整備されていなければ、第2層（Control Tower）のGuardrails適用対象が不明確になります。第2層でアカウントプロビジョニングが自動化されていなければ、第3層（Service Catalog）の製品展開先が統制されません。そしてすべての層での操作が第4層（CloudTrail Lake）によって監査されます。

ガバナンス基盤の強化は第1層から順に積み上げていくことが原則です。まずOrganizationsでOU構造とSCPを確立し、その上にControl TowerのLanding Zoneを構築します。

各サービスが担う機能

AWS Organizations — 権限統制の最強の防壁

OrganizationsはマルチアカウントAWS環境の管理基盤です。OU（Organizational Unit）と呼ばれる組織単位を階層的に設計し、SCP（Service Control Policy）をOU・アカウントに割り当てることで、アカウント内のポリシーがどれだけ強力でも超えることができない「権限の上限」を設定できます。

アカウントファクトリ（Account Factory）では、新規AWSアカウントの作成→適切なOUへの配置→初期設定の適用を標準化フローで実行でき、手動作業による設定漏れを構造的に排除します。

AWS Control Tower — 自動化されたLanding Zone

Control Towerは、OrganizationsのOU構造の上にセキュリティベースライン（Landing Zone）を自動構築するマネージドサービスです。Guardrails（ガードレール）として定義された予防的・検出的コントロールを3種類（Mandatory/Strongly Recommended/Elective）に分類し、全アカウントに自動適用します。

AFT（Account Factory for Terraform）を導入すると、アカウント申請→作成→OU配置→Guardrails適用→カスタムTerraform適用までをGitOpsフローで完全自動化できます。5アカウント以上の環境では手動運用は現実的でなく、AFT導入が標準解です。

AWS Service Catalog — 標準化リソースのセルフサービス

Service Catalogは、プラットフォームチームが承認・管理するCloudFormationテンプレートやTerraformモジュールを「製品（Product）」として登録し、エンドユーザー（開発チーム）がセルフサービスで安全に起動できる仕組みを提供します。ポートフォリオ（製品群）→製品（IaCテンプレート）→制約（Launch Constraint/Template Constraint）の3階層で、自由度と統制のバランスを保ちます。

AWS CloudTrail Lake — 組織横断の監査分析基盤

CloudTrail LakeはAWS全アカウントのAPI操作ログをマネージドなイベントデータストアに集約し、標準SQLで直接分析できるサービスです。従来のCloudTrail→S3→Athenaという分析パスと比較して、パーティション管理不要・組織横断クエリ対応・最大7年間のログ保持が大きなメリットです。「誰が・いつ・どのリソースに・何の操作をしたか」を秒単位で追跡できるガバナンス監査の中核を担います。

本記事を読み終えると達成できること

• (a) OrganizationsでOU階層設計・SCP継承・Delegated Administratorを確立し、マルチアカウントの権限統制基盤を構築できる
• (b) Control TowerでLanding Zone・Guardrails 3種・AFT自動化を実装し、セキュアなアカウント自動プロビジョニングパイプラインを構築できる
• (c) Service Catalogでポートフォリオ→製品→制約の標準化パイプラインを設計し、承認済みリソースのセルフサービス提供を実現できる
• (d) CloudTrail LakeでイベントデータストアのSQL分析・組織横断監査・コスト最適化を実装できる
• (e) 詰まりポイント7選とアンチパターン演習5問で、本番ガバナンス設計の落とし穴を体感し、実務に直結する判断力を習得できる

AWS Organizations 本番運用

マルチアカウント環境でのガバナンスを実現する上で、AWS Organizationsは第1層の基盤サービスです。OU（Organizational Unit）の設計とSCP（Service Control Policy）の継承構造を正しく設計することで、数十〜数百アカウントを一元的に統制できます。

OU階層設計 — Security・Infrastructure・Workloads・Sandboxの4本柱

OU設計の基本原則は機能別の第1軸・環境別の第2軸で階層を構成することです。AWSが推奨するOU構造は以下の4種類のOUを起点とします。

Security OU（セキュリティ専用）

セキュリティ監査・ログ集約に特化したアカウントを配置するOUです。このOUには必ず以下の2種類のアカウントを配置します。

• Log Archive Account: 全アカウントのCloudTrail・Config・VPCフローログの集約先。書き込みは各アカウントのサービスのみに制限し、人間の直接アクセスは禁止します
• Audit Account: セキュリティ審査・コンプライアンス確認を行うアカウント。読み取り専用アクセスで全アカウントの設定状態を確認できます

Security OUは「変更禁止」のSCPで保護します。Security OU配下のアカウントでのリソース変更は、指定された自動化パイプライン経由のみに制限することがベストプラクティスです。

Infrastructure OU（共有インフラ）

全アカウントが共用するネットワーク・共有サービスを管理するOUです。

• Network Account: Transit Gateway・Direct Connect・VPN・共有VPCのハブアカウント
• Shared Services Account: Active Directory連携・内部DNS・共有ツール類のアカウント

Transit Gatewayによるハブ＆スポーク型のネットワーク構成において、Network Accountは中心的な役割を担います。複数のWorkloads OUアカウントからの通信はすべてNetwork Accountを経由させる設計が標準です。

Workloads OU（業務アプリケーション）

実際のビジネスアプリケーションを稼働させるアカウントを配置するOUです。環境ごとにサブOUを設けます。

• Production OU: 本番環境アカウント群（各サービスごとに独立したアカウント）
• Staging OU: ステージング/UAT環境アカウント群
• Development OU: 開発・実験用アカウント群

Workloads OUでは環境別にSCPの強度を変え、本番アカウントはより厳格なSCPを適用します。開発アカウントは実験を許容するため、一部の制限を緩和することも可能です。

Sandbox OU（自由実験環境）

開発者が自由に実験・学習できる短命なアカウントを配置するOUです。本番データへのアクセスは全て遮断するSCPを必ず設定します。Sandbox OUのアカウントは最長3ヶ月でクローズし、リソースをリセットする運用サイクルを設けることが推奨されます。コスト上限もSCPでのBudgetsアラート強制と組み合わせて制御します。

SCP設計 — Deny優先の多層防御アーキテクチャ

SCPはポリシーで付与された権限の上限を設定するメカニズムです。SCPが「拒否」しているアクションは、アカウント内のポリシーがどれだけ強力な「許可」を持っていても実行できません。

SCP継承のルール

SCPはRoot OU → 子OU → アカウントの順に継承され、上位層での拒否は下位層では上書きできません。Root OUに設定したSCPは全メンバーアカウントに自動的に適用されます。

重要な注意点として、管理アカウント（Management Account）にはSCPが適用されません。メンバーアカウントのみが対象です。このため管理アカウント自体のポリシー設計は特別に厳格にする必要があります。

リージョン制限SCP

日本のエンタープライズ環境では、利用リージョンを東京（ap-northeast-1）、大阪（ap-northeast-3）、グローバルサービス用の米国東部（us-east-1）に限定するSCPが多く採用されています。

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

NotActionを使ってIAM・Organizations・Support・Budgetsをリージョン制限の対象外とするのがポイントです。これらはグローバルサービスであり、リージョン指定での制限が機能しない、または制限すると運用に支障をきたします。

ルートユーザー操作禁止SCP

メンバーアカウントのルートユーザーによる操作を全て禁止するSCPです。

{
  "Version": "2012-10-17",
  "Statement": [
 {
"Sid": "DenyRootUser",
"Effect": "Deny",
"Action": "*",
"Resource": "*",
"Condition": {
  "StringLike": {
 "aws:PrincipalArn": "arn:aws:iam::*:root"
  }
}
 }
  ]
}

ルートユーザーによる操作は監査ログに残りにくく、多要素認証なしでの実行リスクもあります。SCPでメンバーアカウントのルートユーザー操作を全面禁止し、緊急時はBreak Glass手順でのみ対応することが推奨されます。

危険操作禁止SCP（Organizations構造保護）

OU構造やSCPの設定変更を一般メンバーアカウントから禁止するSCPです。

{
  "Version": "2012-10-17",
  "Statement": [
 {
"Sid": "DenyOrgStructureModification",
"Effect": "Deny",
"Action": [
  "organizations:LeaveOrganization",
  "organizations:DeleteOrganizationalUnit",
  "organizations:DetachPolicy"
],
"Resource": "*"
 }
  ]
}

アカウントファクトリ — 新規アカウント作成の標準化

Account Factoryは、Organizations管理下でのAWSアカウント作成を標準化するコンポーネントです。手動でのアカウント作成は以下のリスクを持ちます。

• OU配置の誤り（Workloads OUに入れるべきアカウントをRoot直下に配置）
• CloudTrailの設定漏れ（新アカウントのAPI操作が記録されない）
• 初期セキュリティ設定の未適用（S3パブリックアクセスブロックが無効のまま）
• タグの不統一（コスト配賦・リソース管理が不能になる）

Account Factoryでは、アカウント作成時のOU配置・初期設定・タグ付けを標準テンプレートで統一します。Control Tower環境ではAFT（Account Factory for Terraform）と組み合わせ、GitOpsフローでの完全自動化が実現します（詳細は§3で解説）。

Delegated Administrator — 管理アカウントからの権限委任

Organizations環境では、管理アカウントに全ての管理権限が集中しますが、これはリスク集中を招きます。Delegated Administrator機能を使い、特定のサービス管理を指定メンバーアカウントに委任することが推奨されます。

Delegated AdministratorアカウントはSCPの適用対象であり、管理アカウントとは異なりSCPによる制限を受けます。これはセキュリティ観点では好ましい特性であり、委任先アカウントでの誤操作・意図しない操作をSCPで制限できます。

組織ポリシー — タグ・バックアップ・AIオプトアウト

OrganizationsはSCP以外にも複数の組織ポリシーをサポートしています。

タグポリシー（Tag Policy）

全アカウントのリソースに適用するタグの命名規則・必須タグキーを強制するポリシーです。コスト配賦・セキュリティ分類・運用自動化の前提となるタグ（Project・Environment・Owner・CostCenter等）を組織レベルで標準化します。

{
  "tags": {
 "Environment": {
"tag_value": {
  "@@assign": ["production", "staging", "development", "sandbox"]
},
"enforced_for": {
  "@@assign": ["ec2:instance", "rds:db", "s3:bucket"]
}
 }
  }
}

バックアップポリシー（Backup Policy）

AWS Backupを使用したバックアップ計画を組織レベルで強制するポリシーです。特定のOUやアカウント配下のリソースに対して、定期バックアップのスケジュール・保持期間・バックアップボールトを自動適用します。RDSデータベースやEBSボリュームへのバックアップポリシーを組織全体で一元管理できます。

AIサービスオプトアウトポリシー（AI Services Opt-out Policy）

Amazon Rekognitionなどのサービスがユーザーデータをモデルの改善に使用することを組織全体でオプトアウトするポリシーです。個人情報を扱う企業・医療・金融分野では必須の設定として検討が必要です。optOutTypeをALLに設定することで、対象AIサービスの全機能でのデータ利用を停止できます。

flowchart TD
 A["Root OU\n[DenyRootUser SCP]\n[DenyRegionRestriction SCP]"] --> B["Security OU\n[DenyResourceMutation SCP]"]
 A --> C["Infrastructure OU"]
 A --> D["Workloads OU"]
 A --> E["Sandbox OU\n[DenyProductionAccess SCP]"]

 B --> F["Log Archive Account\n（全ログ集約先）"]
 B --> G["Audit Account\n（読み取り専用審査）"]

 C --> H["Network Account\n（TGW・VPN・共有VPC）"]
 C --> I["Shared Services Account\n（AD・DNS・共有ツール）"]

 D --> J["Production OU\n[DenyNonCriticalActions SCP]"]
 D --> K["Staging OU"]
 D --> L["Development OU\n（一部制限緩和）"]

 J --> M["App-A 本番Account"]
 J --> N["App-B 本番Account"]

 style A fill:#ff6b6b,color:#fff
 style B fill:#ffd93d
 style C fill:#6bcb77
 style D fill:#4d96ff,color:#fff
 style E fill:#c0c0c0
 style J fill:#ff9999

AWS Control Tower 本番運用

AWS Control Tower は、Organizations の上にランディングゾーン（Landing Zone）を自動構築し、マルチアカウント環境のガバナンスを一元管理するサービスです。初期セットアップはわずか1時間以内に完了し、数百〜数千アカウントの規模まで対応できます。Control Tower は Organizations・Service Catalog・IAM Identity Center を内部でオーケストレーションし、「マルチアカウントのベストプラクティス基盤」を宣言的に構築します。

ランディングゾーンの構造

Control Tower がランディングゾーンをセットアップすると、3つの専用アカウントと2つのOUが自動作成されます。

ランディングゾーンはあくまで「最初の安全な足場」です。この3アカウント構造を基盤として、Workloads OU・Infrastructure OU・Data OU などの業務用OUを追加構築していきます。

ランディングゾーン設計の重要ポイント:

• Log Archive Account は隔離が原則: 本番アカウントのエンジニアが Log Archive アカウントへのアクセス権を持つとログ改ざんリスクが生まれます。アクセスはセキュリティ/Audit チームのみに限定してください。
• 管理アカウントへの直接ログイン禁止: 日常業務での管理アカウント直接利用はリスクが高いため、IAM Identity Center 経由のフェデレーションアクセスに一本化することを推奨します。
• ホームリージョン選択: ランディングゾーンのホームリージョンは後から変更が困難です。東京リージョン（ap-northeast-1）など、組織のメインリージョンを初回設定時に慎重に選択してください。
• バージョンアップデートの定期適用: Control Tower は定期的にランディングゾーンの新バージョンをリリースします。ドリフトを防ぐため、四半期ごとに「ランディングゾーンの更新」を計画的に実施してください。

Guardrails（ガードレール）3種の詳細

Control Tower の Guardrails は「ガイダンスレベル（Mandatory / Strongly Recommended / Elective）」と「実装方式（Preventive / Detective / Proactive）」の2軸で分類されます。

ガイダンスレベルの分類:

実装方式の分類:

Account Factory によるアカウント標準化作成

Account Factory は、事前定義したテンプレートに基づいてメンバーアカウントを標準化作成する Control Tower の機能です。アカウント作成時に以下の設定が自動適用されます。

• 指定OUへの自動配置
• 有効化された Guardrails の自動適用
• 上位OUからの SCP 継承適用
• IAM Identity Center への自動登録
• CloudTrail の自動有効化

Account Factory の利用方法（AWS CLI）:

aws servicecatalog provision-product \
  --product-name "AWS Control Tower Account Factory" \
  --provisioning-artifact-name "AWS Control Tower Account Factory" \
  --provisioned-product-name "app-prod-account" \
  --provisioning-parameters \
 Key=AccountName,Value=app-prod-account \
 Key=AccountEmail,Value=app-prod@example.com \
 Key=OUName,Value=Production \
 Key=ManagedOrganizationalUnit,Value="Production (ou-xxxx-xxxxxxxx)" \
 Key=SSOUserEmail,Value=admin@example.com \
 Key=SSOUserFirstName,Value=Admin \
 Key=SSOUserLastName,Value=User

コンソールからは「Control Tower → アカウントファクトリー → アカウントのプロビジョニング」で同等の操作が可能です。ただし、アカウント数が増えるにつれて手動操作は管理コストが増大するため、次に解説する AFT への移行を強く推奨します。

AFT（Account Factory for Terraform）による GitOps 完全自動化

AFT（Account Factory for Terraform）は、アカウント作成から Guardrails 適用・カスタマイズまでをTerraformの GitOps フローで完全自動化します。git push するだけでアカウントが作られ、標準設定が適用されます。

AFT の構成要素:

flowchart LR
 A["開発者がアカウント申請\naccount-request.tf を git push"] --> B["AFT アカウントリクエスト\nCodePipeline 起動"]
 B --> C["Account Factory\nアカウント作成 + OU配置"]
 C --> D["Guardrails 自動適用\nSCP 継承"]
 D --> E["グローバルカスタマイズ\nTerraform 適用（全アカウント共通）"]
 E --> F["アカウント固有カスタマイズ\nTerraform 適用"]
 F --> G["新アカウント\n利用開始（約20〜30分）"]

AFT の Terraform ディストリビューション選択:

module "app_prod_account" {
  source = "github.com/aws-ia/terraform-aws-control_tower_account_factory//modules/aft-account-request"

  control_tower_parameters = {
 AccountEmail  = "app-prod@example.com"
 AccountName= "app-prod-account"
 ManagedOrganizationalUnit = "Production (ou-xxxx-xxxxxxxx)"
 SSOUserEmail  = "admin@example.com"
 SSOUserFirstName = "Platform"
 SSOUserLastName  = "Team"
  }

  account_tags = {
 Environment = "production"
 Team  = "platform"
 CostCenter  = "platform-001"
  }

  change_management_parameters = {
 change_requested_by = "platform-team"
 change_reason = "New application account provisioning"
  }
}

ドリフト検出と修復

Control Tower の「ドリフト（Drift）」とは、Control Tower が管理するリソースが Tower 外で手動変更され、期待状態からズレることを指します。

ドリフトが発生する主なパターン:

ドリフトを検出した場合、Control Tower コンソールの「ランディングゾーン設定」→「ランディングゾーンの再設定（Re-register）」を実行することで修復できます。

# Control Tower ランディングゾーンのドリフトステータス確認
aws controltower get-landing-zone \
  --landing-zone-identifier "arn:aws:controltower:ap-northeast-1::landingzone/XXXX" \
  --query 'landingZone.driftStatus'

# 出力例: "IN_SYNC" (正常) / "DRIFTED" (ドリフト発生)

定期的なドリフトチェックをパイプラインに組み込み（週次または月次）、検出時は速やかに Re-register を実行する運用フローを確立してください。

IAM Identity Center 統合 — シングルサインオンとアクセス管理

Control Tower は IAM Identity Center（旧 AWS SSO）と深く統合されており、Landing Zone セットアップと同時に IAM Identity Center が有効化されます。これにより、全メンバーアカウントへのアクセスをシングルサインオンで一元管理できます。

IAM Identity Center × Control Tower の統合ポイント:

Permission Set の設計例:

# Terraform で Permission Set を定義する例
resource "aws_ssoadmin_permission_set" "platform_admin" {
  name = "PlatformAdmin"
  instance_arn  = data.aws_ssoadmin_instances.main.arns[0]
  session_duration = "PT8H"
  description= "プラットフォームチーム用管理者権限"
}

resource "aws_ssoadmin_managed_policy_attachment" "platform_admin_policy" {
  instance_arn = data.aws_ssoadmin_instances.main.arns[0]
  permission_set_arn = aws_ssoadmin_permission_set.platform_admin.arn
  managed_policy_arn = "arn:aws:iam::aws:policy/AdministratorAccess"
}

アクセス権付与のライフサイクル管理:

Control Tower 環境でのアクセス権管理は「誰がどのアカウントにどの Permission Set でアクセスできるか」を Terraform または CloudFormation で宣言的に管理することを推奨します。Account Factory（AFT）のカスタマイズリポジトリにアクセス権付与の設定を含めることで、アカウント作成時から適切な権限が付与された状態でエンジニアが作業を開始できます。

Control Tower 運用上の注意点とベストプラクティス

スケール時の設計考慮点:

Control Tower は数千アカウントを管理できますが、以下の設計上の制約に注意してください。

ランディングゾーン更新手順（定期メンテナンス）:

Control Tower の新バージョンがリリースされたら、以下の手順でランディングゾーンを更新します。

1. Control Tower コンソールで「更新が利用可能」の通知を確認
2. 「ランディングゾーンの設定」→「更新」をクリック
3. 影響を受ける OU・アカウントを確認してから実行
4. 更新完了後、ドリフトステータスが IN_SYNC であることを確認

更新は通常30分〜2時間かかります。更新中も既存アカウントの通常業務への影響は最小限ですが、メンテナンスウィンドウを設定して業務時間外に実施することを推奨します。

AWS Service Catalog 本番運用

AWS Service Catalog は「誰でも・素早く・正しい設定で」AWSリソースをプロビジョニングできるセルフサービスポータルを組織内に構築するサービスです。CloudFormation テンプレートや Terraform モジュールを製品（Product）としてカタログ化し、ポートフォリオ（Portfolio）で管理・配布することで、インフラのセルフサービス化と標準化を同時に実現します。

エンドユーザーはポータルから製品を選択しパラメータを入力するだけでリソースを作成でき、管理者は制約（Constraint）によって承認済みの設定値以外での起動を防止できます。Organizations との統合により、このカタログを組織全体・OU単位で配布することも可能です。

ポートフォリオ設計：チーム × 環境マトリクス

ポートフォリオは「誰に」「何を」提供するかを定義する器です。設計の基本はチーム（開発/インフラ/データ/セキュリティ）× 環境（本番/ステージング/開発）のマトリクスです。

ポートフォリオ設計例:

ポートフォリオ設計のアンチパターンと正解パターン:

製品バージョン管理

製品（Product）は CloudFormation テンプレートまたは Terraform モジュールとして定義します。ポートフォリオ内の各製品は複数バージョンを保持でき、エンドユーザーはバージョンを選択して起動できます。

v1.0.0-cfn  → 初版（CloudFormation）
v1.1.0-cfn  → マイナーアップデート（後方互換あり）
v2.0.0-cfn  → 破壊的変更（パラメータ変更等）
v1.0.0-tf→ Terraform 版

aws servicecatalog create-provisioning-artifact \
  --product-id prod-xxxxxxxxxxxx \
  --parameters '{
 "Name": "v2.0.0",
 "Description": "VPC構成をシングルNATからマルチNATに変更",
 "Info": {
"LoadTemplateFromURL": "https://s3.amazonaws.com/my-catalog-templates/vpc-v2.0.0.yaml"
 },
 "Type": "CLOUD_FORMATION_TEMPLATE"
  }'

# Organizations 全体へポートフォリオを共有
aws servicecatalog create-portfolio-share \
  --portfolio-id port-xxxxxxxxxxxx \
  --organization-node '{"Type": "ORGANIZATION", "Value": "o-xxxxxxxxxxxx"}'

# 特定OU へのみ共有する場合
aws servicecatalog create-portfolio-share \
  --portfolio-id port-xxxxxxxxxxxx \
  --organization-node '{"Type": "ORGANIZATIONAL_UNIT", "Value": "ou-xxxx-xxxxxxxx"}'

制約設計：Launch / Template / Notification Constraint

制約（Constraint）は製品の起動時に適用されるビジネスルールです。3種類の制約を組み合わせてセキュリティと利便性を両立します。

Launch Constraint の設定（最重要制約）:

Launch Constraint を設定しない場合、エンドユーザーが CloudFormation を実行するには cloudformation:* 等の広範な権限が必要です。Launch Constraint を設定すると、Service Catalog が指定 IAM ロールを assume して CloudFormation を実行するため、エンドユーザーの権限を最小化できます。

# Launch Constraint の設定（製品起動時に assume するロールを指定）
aws servicecatalog create-constraint \
  --portfolio-id port-xxxxxxxxxxxx \
  --product-id prod-xxxxxxxxxxxx \
  --type LAUNCH \
  --parameters '{"LocalRoleName": "ServiceCatalogLaunchRole"}'

Template Constraint の設定（パラメータ制限）:

# EC2 インスタンスタイプを t3.micro と t3.small のみに制限
aws servicecatalog create-constraint \
  --portfolio-id port-xxxxxxxxxxxx \
  --product-id prod-xxxxxxxxxxxx \
  --type TEMPLATE \
  --parameters '{
 "Rules": {
"rule-instance-type": {
  "Assertions": [{
 "Assert": {
"Fn::Contains": [["t3.micro", "t3.small"], {"Ref": "InstanceType"}]
 },
 "AssertDescription": "開発環境では t3.micro または t3.small のみ利用可能です"
  }]
}
 }
  }'

組織共有とOU単位の製品配布

Organizations との統合により、ポートフォリオを組織全体または特定OU単位で一括配布できます。

Organizations Root
├── Security OU← Security-Baselines ポートフォリオのみ
├── Infrastructure OU← Platform-Common + Network ポートフォリオ
└── Workloads OU
 ├── Production OU← App-Service-Prod ポートフォリオ（制約強め）
 ├── Staging OU← App-Service-Staging ポートフォリオ
 └── Development OU  ← App-Service-Dev ポートフォリオ（制約緩め）

OU 単位でポートフォリオを分けることで、本番環境では承認済みのインスタンスタイプ・サイズのみに制限し、開発環境では柔軟な選択肢を提供するといった環境差異のある制約設計が実現できます。

Terraform 対応：Service Catalog × Terraform の実装

# 1. Terraform 設定を tar.gz にアーカイブ
tar -czf vpc-module-v1.0.0.tar.gz ./vpc-module/

# 2. S3 バケットにアップロード
aws s3 cp vpc-module-v1.0.0.tar.gz \
  s3://my-service-catalog-artifacts/vpc-module-v1.0.0.tar.gz

# 3. Service Catalog 製品を作成
aws servicecatalog create-product \
  --name "Standard VPC Module" \
  --product-type TERRAFORM_OPEN_SOURCE \
  --provisioning-artifact-parameters '{
 "Name": "v1.0.0",
 "Description": "標準VPC（パブリック/プライベートサブネット/NAT Gateway）",
 "Info": {
"LoadFromS3Bucket": "my-service-catalog-artifacts",
"LoadFromS3Key": "vpc-module-v1.0.0.tar.gz"
 },
 "Type": "TERRAFORM_OPEN_SOURCE"
  }'

Service Catalog の承認フロー設計

本番環境では、エンドユーザーが製品を起動する前に承認フローを設けることが重要です。Notification Constraint と AWS Step Functions を組み合わせることで、承認ワークフローを構築できます。

承認フローの構成例:

エンドユーザーが製品起動 → SNS通知 → Lambda起動 → 管理者にSlack/メール通知
  ↓
  管理者が承認
  ↓
  Service Catalog が起動を継続 または キャンセル

Notification Constraint の設定:

aws servicecatalog create-constraint--portfolio-id port-xxxxxxxxxxxx--product-id prod-xxxxxxxxxxxx--type NOTIFICATION--parameters '{"NotificationArns": ["arn:aws:sns:ap-northeast-1:123456789012:sc-approval-topic"]}'

SNS トピックにサブスクライブした Lambda がSlackや Teams に通知を送り、管理者が承認することで起動が完了するフローを構築できます。

Service Catalog の監査とコンプライアンス確認

Service Catalog は AWS CloudTrail と統合されており、全ての操作ログが記録されます。定期的な監査でコンプライアンス状態を確認してください。

CloudTrail での Service Catalog 監査クエリ（SQL）:

SELECT
  eventTime,
  userIdentity.arn,
  eventName,
  requestParameters,
  responseElements
FROM <cloudtrail-lake-store-id>
WHERE eventTime > '2024-01-01 00:00:00'
  AND eventTime < '2024-01-31 23:59:59'
  AND eventSource = 'servicecatalog.amazonaws.com'
  AND eventName IN (
 'ProvisionProduct',
 'TerminateProvisionedProduct',
 'UpdateProvisionedProduct'
  )
ORDER BY eventTime DESC

コンプライアンス確認チェックリスト:

月次で以下を確認することを推奨します。

• 全製品に Launch Constraint が設定されているか
• 廃止バージョンが残っている製品はないか（移行猶予期間を超えたもの）
• Organizations 共有ポートフォリオで権限の過剰付与がないか
• Provisioned Products のステータスに ERROR や TAINTED がないか

Provisioned Products のヘルスチェック:

# ステータスが AVAILABLE 以外の製品を一覧表示
aws servicecatalog scan-provisioned-products--query 'ProvisionedProducts[?Status!=`AVAILABLE`].[Name,Status,StatusMessage]'--output table

TAINTED は前回の更新に失敗した状態を示します。原因を調査し、製品テンプレートを修正してから再更新を実施してください。

AWS CloudTrail Lake 本番運用

AWS CloudTrail Lake は、CloudTrail イベントをマネージドなイベントデータストアに集約し、SQL クエリで直接分析できるサービスです。従来の S3 + Athena を組み合わせた分析アーキテクチャと比較して、パーティション管理が不要でクエリ準備コストがゼロになる点が最大の強みです。本番環境では、管理イベントとデータイベントを分離したイベントデータストア設計と、組織横断トレイルの設定が運用品質を左右します。

イベントデータストア作成と保持期間設定

イベントデータストアはリージョン単位で作成します。マルチリージョン環境では、--multi-region-enabled オプションで全リージョンのイベントを1つのデータストアに集約できます。

# イベントデータストアの作成（管理イベント専用）
aws cloudtrail create-event-data-store \
  --name "management-events-store" \
  --retention-period 365 \
  --multi-region-enabled \
  --organization-enabled \
  --advanced-event-selectors '[
 {
"Name": "Management Events",
"FieldSelectors": [
  {"Field": "eventCategory", "Equals": ["Management"]}
]
 }
  ]'

保持期間は2つのモードがあります。1年保持（デフォルト）は通常運用・コスト重視の環境に適しています。7年保持はコンプライアンス要件（SOC 2、PCI DSS、HIPAA など）で長期保持が義務付けられる場合に選択します。

管理イベント vs データイベントの分離設計

イベントデータストアは用途に応じて分離して設計することがベストプラクティスです。全てのイベントを1つのデータストアに集約すると、S3 オブジェクトレベルのデータイベントがコストを急増させるリスクがあります。

推奨構成（3ストア分離）:

• 管理イベントストア: IAM変更・EC2起動停止・ネットワーク変更など。コストが予測しやすく、全環境で必須。
• S3データイベントストア: 特定バケットのオブジェクトアクセスログ。対象バケットを限定してコスト抑制。
• Lambda/DynamoDBデータイベントストア: 重要アプリケーションの呼び出しログ。対象関数・テーブルを絞って運用。

# データイベントストアの作成（S3特定バケット限定）
aws cloudtrail create-event-data-store \
  --name "s3-data-events-store" \
  --retention-period 90 \
  --advanced-event-selectors '[
 {
"Name": "S3 Data Events - Critical Buckets Only",
"FieldSelectors": [
  {"Field": "eventCategory", "Equals": ["Data"]},
  {"Field": "resources.type", "Equals": ["AWS::S3::Object"]},
  {"Field": "resources.ARN", "StartsWith": [
 "arn:aws:s3:::critical-bucket-prod/"
  ]}
]
 }
  ]'

クエリ最適化

CloudTrail Lake の SQL クエリは標準 SQL に近い構文で記述できます。eventTime による範囲絞り込みと eventSource フィルタを組み合わせることで、クエリコストを大幅に削減できます。

基本構文:

SELECT
  eventTime,
  eventSource,
  eventName,
  awsRegion,
  userIdentity.principalId,
  userIdentity.arn,
  sourceIPAddress,
  errorCode,
  errorMessage
FROM <event-data-store-id>
WHERE eventTime > '2024-01-01 00:00:00'
  AND eventTime < '2024-01-31 23:59:59'
  AND eventSource = 'iam.amazonaws.com'
ORDER BY eventTime DESC
LIMIT 100

eventTime 範囲指定（必須の最適化）:

クエリには必ず eventTime の範囲を指定してください。範囲未指定のクエリは全データストアをスキャンしてコストが急増します。調査対象期間の ±1 日を範囲として指定するのが基本です。

頻出クエリテンプレート — 不正アクセス調査（認証失敗集計）:

SELECT
  sourceIPAddress,
  userIdentity.principalId,
  COUNT(*) AS attempt_count,
  MIN(eventTime) AS first_attempt,
  MAX(eventTime) AS last_attempt
FROM <event-data-store-id>
WHERE eventTime > '2024-01-01 00:00:00'
  AND eventTime < '2024-01-07 23:59:59'
  AND errorCode IN ('AccessDenied', 'UnauthorizedAccess', 'InvalidClientTokenId')
GROUP BY sourceIPAddress, userIdentity.principalId
HAVING COUNT(*) > 10
ORDER BY attempt_count DESC

IAM ロール使用状況分析クエリ:

SELECT
  userIdentity.sessionContext.sessionIssuer.arn AS assumed_role,
  eventName,
  eventSource,
  awsRegion,
  COUNT(*) AS call_count
FROM <event-data-store-id>
WHERE eventTime > '2024-01-01 00:00:00'
  AND eventTime < '2024-01-31 23:59:59'
  AND userIdentity.type = 'AssumedRole'
GROUP BY
  userIdentity.sessionContext.sessionIssuer.arn,
  eventName,
  eventSource,
  awsRegion
ORDER BY call_count DESC
LIMIT 50

リソース変更追跡クエリ（変更操作の特定）:

SELECT
  eventTime,
  userIdentity.arn,
  eventName,
  requestParameters,
  responseElements,
  errorCode
FROM <event-data-store-id>
WHERE eventTime > '2024-01-01 00:00:00'
  AND eventTime < '2024-01-31 23:59:59'
  AND eventName IN (
 'DeleteBucket', 'PutBucketPolicy',
 'CreateRole', 'AttachRolePolicy', 'DeleteRole',
 'ModifyInstanceAttribute', 'TerminateInstances'
  )
  AND errorCode IS NULL
ORDER BY eventTime DESC

組織トレイルと組織レベルのイベントデータストア

組織トレイルを使用すると、Organizations 配下の全メンバーアカウントのイベントを1つのイベントデータストアに集約できます。新規アカウントが Organizations に参加した時点から自動的にログ収集が開始されるため、手動設定漏れがなくなります。

# 組織レベルのイベントデータストア（管理アカウントで実行）
aws cloudtrail create-event-data-store \
  --name "org-wide-management-events" \
  --retention-period 365 \
  --organization-enabled \
  --multi-region-enabled \
  --advanced-event-selectors '[
 {
"Name": "All Management Events",
"FieldSelectors": [
  {"Field": "eventCategory", "Equals": ["Management"]}
]
 }
  ]'

組織トレイルの運用ポイント:

• 組織レベルのイベントデータストアは管理アカウントでのみ作成可能です。
• 組織全体クエリはアカウント数 × イベント量に比例してコストが増大するため、recipientAccountId フィルタで対象アカウントを絞ることを強く推奨します。
• 分析用クエリは Log Archive アカウントまたは Audit アカウントから実行する設計が標準的なパターンです。

-- 特定アカウントのみを対象に絞るフィルタ（コスト削減）
SELECT eventTime, eventName, userIdentity.arn
FROM <org-event-data-store-id>
WHERE eventTime > '2024-01-01 00:00:00'
  AND eventTime < '2024-01-07 23:59:59'
  AND recipientAccountId = '123456789012'
  AND eventSource = 'iam.amazonaws.com'
ORDER BY eventTime DESC

CloudTrail Insights — 異常 API 呼び出しパターンの検出

CloudTrail Insights は、通常の API 呼び出しパターンと比較して異常なアクティビティを自動検出する機能です。機械学習ベースのベースライン分析により、突発的な API 呼び出し急増（リソース大量作成・認証試行の急増など）を検知してアラートを発報します。

Insights の有効化:

Insights はイベントデータストア単位ではなく、CloudTrail トレイル単位で有効化します。ApiCallRateInsight（API 呼び出し件数の異常増加）と ApiErrorRateInsight（エラー率の異常上昇）の2種類があります。

# 既存トレイルへの Insights 有効化
aws cloudtrail update-trail \
  --name my-org-trail \
  --insight-selectors '[
 {"InsightType": "ApiCallRateInsight"},
 {"InsightType": "ApiErrorRateInsight"}
  ]'

Insights 分析フロー:

1. Insights イベントが S3 バケット（トレイル設定先）に出力される
2. EventBridge ルールで Insights イベントを検知
3. SNS または Lambda でアラート通知（Slack・メール等）
4. CloudTrail Lake で通常イベントと突き合わせて原因を特定

Insights が検知する代表的な異常パターン:

詰まりポイント7選 図解

AWSマルチアカウント・ガバナンス運用で頻出する7つの詰まりパターンを、症状・原因・解決策のセットで体系化します。本番環境で実際に発生した設計ミスをもとに、再発防止のポイントをまとめています。

詰まり1: SCPが意図しないアカウントにも継承されて業務停止

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

詰まり2: Control Towerドリフトを放置してGuardrails無効化

詰まり3: Service Catalog製品バージョン管理の欠如で古い構成が展開される

import boto3

sc = boto3.client('servicecatalog', region_name='ap-northeast-1')

def deprecate_old_versions(product_id: str, keep_version_name: str):
 response = sc.list_provisioning_artifacts(ProductId=product_id)
 for artifact in response['ProvisioningArtifactDetails']:
  if artifact['Name'] != keep_version_name:
sc.update_provisioning_artifact(
 ProductId=product_id,
 ProvisioningArtifactId=artifact['Id'],
 Active=False
)
print(f"廃止完了: {artifact['Name']}")

詰まり4: CloudTrail Lakeのコストが想定外に膨張

{
  "EventSelectors": [
 {
"ReadWriteType": "WriteOnly",
"IncludeManagementEvents": false,
"DataResources": [
  {
 "Type": "AWS::S3::Object",
 "Values": ["arn:aws:s3:::critical-bucket-name/"]
  }
]
 }
  ]
}

詰まり5: 管理アカウントに全機能を集中させてリスク増大

# Delegated Administratorの登録例（管理アカウントから実行）
aws organizations register-delegated-administrator \
  --account-id 123456789012 \
  --service-principal config.amazonaws.com

aws organizations register-delegated-administrator \
  --account-id 123456789012 \
  --service-principal servicecatalog.amazonaws.com

詰まり6: Account Factory手動運用でOU配置ミス

# AFTアカウント作成リクエスト例
module "new_workload_account" {
  source = "./modules/aft-account-request"

  control_tower_parameters = {
 AccountEmail  = "workload-app-a@example.com"
 AccountName= "App-A Production"
 ManagedOrganizationalUnit = "Workloads/Production"
 SSOUserEmail  = "admin@example.com"
 SSOUserFirstName = "Admin"
 SSOUserLastName  = "User"
  }

  account_tags = {
 Environment = "production"
 Team  = "app-a"
 CostCenter  = "CC-1234"
  }
}

詰まり7: 組織トレイルの未設定で新アカウントのログが欠落

# 組織トレイルの作成（管理アカウントから実行）
aws cloudtrail create-trail \
  --name org-trail \
  --s3-bucket-name org-cloudtrail-logs-123456789012 \
  --is-multi-region-trail \
  --include-global-service-events \
  --is-organization-trail \
  --enable-log-file-validation

aws cloudtrail start-logging --name org-trail

アンチパターン→正解パターン変換（5問）

AWSガバナンス設計で実際によく見られるアンチパターンと、その正解パターンを演習形式で学びます。各問題は「NG構成」と「OK構成」のペアで示します。

AP1: 全アカウントをRoot OU直下にフラット配置

NG構成 — 全アカウントをRoot OU直下にフラット配置

Root OU
├── Account-A (本番)
├── Account-B (開発)
├── Account-C (ステージング)
├── Account-D (ログアーカイブ)
└── Account-E (ネットワーク)

この構成では全アカウントに同じSCPしか適用できず、本番環境と開発環境のセキュリティ要件を分離できません。機能別・環境別の柔軟なポリシー管理が不可能になります。

OK構成 — 機能別・環境別のOU階層設計

Root OU（組織共通SCP: リージョン制限・危険操作禁止）
├── Security OU（セキュリティ特化SCP）
│├── Log Archive Account（ログ長期保存）
│└── Audit Account（コンプライアンス監視）
├── Infrastructure OU（インフラ共通SCP）
│├── Network Account（Transit Gateway・DNS）
│└── Shared Services Account（Service Catalog）
├── Workloads OU（業務系SCP）
│├── Production OU（本番強化SCP）
││└── App-A Prod Account
│├── Staging OU
││└── App-A Staging Account
│└── Development OU（開発者フレンドリーSCP）
│ └── App-A Dev Account
└── Sandbox OU（SCP最小限: 学習・検証用）
 └── Sandbox Account

環境ごとにOUを分離することで、本番環境への厳格なSCPと開発環境への柔軟なSCPを同時に実現できます。セキュリティOU配下のLog Archiveアカウントは、全アカウントからのCloudTrailログ集約先として機能します。

AP2: SCPでAllow型ポリシーのみ使用

NG構成 — Allow型SCPのみで権限管理

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

問題点: SCPのAllow型は「この操作を上限として認める」という意味であり、IAMポリシーとのAND条件になります。Allow型SCPだけでは記載外のサービス（Lambda等）の制限ができず、危険な操作（Organizations離脱・CloudTrail削除）も防止できません。

OK構成 — Deny型優先 + 最小権限の多層防御

{
  "Version": "2012-10-17",
  "Statement": [
 {
"Sid": "DenyLeaveOrganization",
"Effect": "Deny",
"Action": "organizations:LeaveOrganization",
"Resource": "*"
 },
 {
"Sid": "DenyNonApRegions",
"Effect": "Deny",
"NotAction": ["iam:*", "route53:*", "support:*", "sts:*"],
"Resource": "*",
"Condition": {
  "StringNotEquals": {
 "aws:RequestedRegion": ["ap-northeast-1", "us-east-1"]
  }
}
 },
 {
"Sid": "DenyDisableCloudTrail",
"Effect": "Deny",
"Action": [
  "cloudtrail:DeleteTrail",
  "cloudtrail:StopLogging",
  "cloudtrail:UpdateTrail"
],
"Resource": "*"
 }
  ]
}

Deny型SCPは「何が起きても絶対禁止」する操作を明示します。Organizations離脱禁止・リージョン外操作禁止・CloudTrail無効化禁止を最低限のDeny SCPとして設定し、IAMポリシー側で必要な権限を付与する多層防御を構築します。

AP3: Control Tower無しで手動Landing Zone構築

NG構成 — Control Towerを使わず手動でマルチアカウント環境を構築

# 各アカウントに手動でCloudTrailを個別設定
aws cloudtrail create-trail \
  --name account-trail \
  --s3-bucket-name logs-bucket-123

# Config Rulesをアカウントごとに手作業で設定
aws configservice put-config-rule \
  --config-rule file://config-rule.json

手動Landing Zone構築の問題点:
– Guardrails（Config Rules・SCP）の適用漏れが発生しやすい
– アカウント追加のたびに同じ作業を繰り返す（ヒューマンエラーリスク）
– ドリフト検出・自動修復の仕組みがない
– 構成のバージョン管理ができない

OK構成 — Control Tower + AFT による完全自動化

# AFTでアカウント作成リクエストをコード管理
module "control_tower_account" {
  source = "./modules/aft-account-request"

  control_tower_parameters = {
 AccountEmail  = "new-app@company.com"
 AccountName= "New Application"
 ManagedOrganizationalUnit = "Workloads/Production"
 SSOUserEmail  = "app-admin@company.com"
 SSOUserFirstName = "App"
 SSOUserLastName  = "Admin"
  }

  account_customizations_name = "workload-customizations"
}

Control TowerはMandatory Guardrails（CloudTrail・Config等）を自動で全アカウントに適用します。AFTはGitOpsフローでアカウントライフサイクルを管理し、人手を介さずに一貫した設定が展開されます。

AP4: Service Catalog未使用で各チームが自由にリソース作成

NG構成 — 各チームが直接AWSコンソールやCLIでリソースを自由に作成

開発チームがEC2インスタンスを直接起動する場合の問題点:
– インスタンスタイプが不統一（コスト管理困難）
– セキュリティグループが各自の設定（インターネット開放等のリスク）
– タグ付けの欠如（コスト配賦が不明確）
– 最新のAMI・パッチ適用済みテンプレートが使われない

OK構成 — Service Catalog ポートフォリオ → 製品 → 制約 の標準化

AWSTemplateFormatVersion: "2010-09-09"
Description: "標準化EC2インスタンス — コスト最適化タイプのみ許可"

Parameters:
  InstanceType:
 Type: String
 AllowedValues:
- t3.medium
- t3.large
- m6i.large
 Default: t3.medium

  Environment:
 Type: String
 AllowedValues: [development, staging, production]

Resources:
  WebInstance:
 Type: AWS::EC2::Instance
 Properties:
InstanceType: !Ref InstanceType
ImageId: "{{resolve:ssm:/golden-ami/latest-id}}"
Tags:
  - Key: Environment
 Value: !Ref Environment
  - Key: ManagedBy
 Value: ServiceCatalog

Service Catalogの制約（Launch Constraint）により、エンドユーザーはパラメータの選択肢が制限された製品のみを利用できます。最新のゴールデンAMI（SSMパラメータストア参照）が自動的に使われるため、パッチ適用済み環境が常に展開されます。

AP5: CloudTrailログをS3に放置して分析なし

NG構成 — CloudTrailログをS3に蓄積するだけで分析基盤なし

# ログはS3にあるが分析には長い前処理が必要
aws s3 ls s3://cloudtrail-logs/AWSLogs/123456789012/CloudTrail/ap-northeast-1/

# Athenaで分析する場合、パーティション管理・スキーマ定義が別途必要
# 調査開始まで30分以上かかることも

問題点: ログは存在するが分析クエリ実行まで時間がかかる。パーティション管理・スキーマ管理が必要。組織横断のクエリが困難。異常検出のリアルタイム通知がない。

OK構成 — CloudTrail Lake + SQLクエリ + Insights による即時分析

-- CloudTrail Lake: 過去7日間に特定ユーザーが行った操作一覧
SELECT
  eventTime,
  eventSource,
  eventName,
  awsRegion,
  sourceIPAddress,
  userIdentity.arn
FROM <event_data_store_arn>
WHERE userIdentity.arn LIKE '%target-user%'
  AND eventTime > DATE_ADD('day', -7, NOW())
ORDER BY eventTime DESC;

-- CloudTrail Lake: ルートアカウントのコンソールログイン検出
SELECT
  eventTime,
  sourceIPAddress,
  userAgent
FROM <event_data_store_arn>
WHERE userIdentity.type = 'Root'
  AND eventName = 'ConsoleLogin';

CloudTrail Lakeはパーティション管理不要で即座にSQLクエリが実行できます。CloudTrail Insightsを有効化すると、異常な操作パターンを自動検出してアラートを発報します。組織トレイルとCloudTrail Lakeを組み合わせることで、全アカウントのイベントを単一クエリで横断分析できます。

まとめ — Management & Governance Vol1起点・58記事化達成

Management & Governance Vol1では、AWSのガバナンス基盤を構成する4つのサービス — AWS Organizations・AWS Control Tower・AWS Service Catalog・AWS CloudTrail Lake — を体系的に解説しました。

ガバナンス4層 — 統制・確立・標準化・監査の統合

第1層: 統制する（Organizations + SCP）

AWS Organizationsは組織のアカウント構造を定義し、SCPでアカウントの行動範囲を強制します。OU階層設計とDeny型SCPの組み合わせが、全アカウント共通のセキュリティベースラインを保証します。Delegated Administratorにより管理アカウントへの権限集中を回避し、機能別アカウントへの委任を推進します。

第2層: 確立する（Control Tower）

Control TowerはLanding Zoneというベストプラクティス準拠の基盤環境を構築し、Guardrails（3種）でコンプライアンスを継続的に保証します。AFT（Account Factory for Terraform）により、アカウントのライフサイクル管理をGitOpsフローに乗せ、人的ミスを排除した標準化を実現します。ドリフト検出・自動修復により、Control Tower管理外の手動操作によるコンプライアンス逸脱を検知・修正できます。

第3層: 標準化する（Service Catalog）

Service Catalogはポートフォリオ→製品→制約の階層でリソースプロビジョニングを標準化します。開発者はAWSコンソールで承認済みの製品のみを起動でき、セキュリティ要件・コスト要件を満たしたリソースが常に展開されます。バージョン管理と廃止ポリシーにより、パッチ適用済みの最新テンプレートが常用されます。

第4層: 監査する（CloudTrail Lake）

CloudTrail Lakeは全アカウントのAPIコールを組織横断で収集し、SQLクエリで即座に分析できるマネージドな監査基盤を提供します。CloudTrail Insightsによる異常検出、7年間の長期保持、組織トレイルとの連携により、本番環境のセキュリティ監査とコンプライアンス証跡を一元管理します。

ガバナンス4層の統合フロー

新アカウント申請
 ↓
AFT（GitOps）でアカウント作成リクエスト → PR承認
 ↓
Control Tower Account Factoryがアカウント作成
 ↓ Mandatory Guardrails 自動適用（CloudTrail・Config等）
組織トレイルにより CloudTrail Lake へログ自動連携
 ↓
OU配置に応じたSCP自動継承（Organizations）
 ↓
Service Catalogポートフォリオ共有（承認済み製品の標準化）
 ↓
全APIコールがCloudTrail Lakeに記録・SQLで即時分析可能

次のアクション:
1. AWS OrganizationsでOU階層を設計し、SCPをDeny型で実装する
2. Control TowerでLanding Zoneを構築し、AFTを導入する
3. Service CatalogでTerraform製品の第1号ポートフォリオを作成する
4. CloudTrail Lakeでイベントデータストアを作成し、組織トレイルと連携する

ガバナンス統合チェックリスト — 本番環境リリース前の必須確認事項

Management & Governance本番環境を構築する際の最終確認リストです。全項目をクリアしてからリリースしてください。

Organizations設計チェック

• [ ] OU階層設計: Security / Infrastructure / Workloads / Sandbox OUが構成されているか
• [ ] Root SCP: リージョン制限・Organizations離脱禁止・CloudTrail削除禁止が設定されているか
• [ ] グローバルサービス除外: IAM・Route 53・Support操作がSCPのNotActionで除外されているか
• [ ] Delegated Administrator: コンプライアンス・コスト管理が専用アカウントへ委任されているか
• [ ] タグポリシー: Environment・CostCenter・Teamが組織レベルで強制されているか

Control Tower設計チェック

• [ ] Landing Zone: v3.3以上のバージョンで構築されているか
• [ ] Mandatory Guardrails: 全て有効かつ機能しているか（Config Rulesで確認）
• [ ] Strongly Recommended Guardrails: 本番OUに全て適用されているか
• [ ] AFT: アカウント作成フローがGitOps化されているか
• [ ] ドリフト検出: 月次確認スケジュールが設定されているか

Service Catalog設計チェック

• [ ] ポートフォリオ: チーム別・環境別で分割されているか
• [ ] 製品バージョン: 廃止ポリシー（旧バージョン自動Inactive化）が実装されているか
• [ ] Launch Constraint: 専用IAMロールでプロビジョニング権限が最小化されているか
• [ ] 組織共有: 必要なOUに製品が共有されているか

CloudTrail Lake設計チェック

• [ ] 組織トレイル: 全アカウント・全リージョンが対象になっているか
• [ ] イベントデータストア: 管理イベント用とデータイベント用が分離されているか
• [ ] ログファイル検証: 有効化されているか
• [ ] KMS暗号化: Log ArchiveアカウントのS3バケットにSSE-KMSが適用されているか
• [ ] CloudWatch Logs連携: リアルタイムアラートが設定されているか
• [ ] Insights: 異常検出が有効化されているか

関連シリーズで知識を深める

IAM（第1軸）との統合

SCP × IAMポリシーの多層防御アーキテクチャは、第1軸のIAM本番運用シリーズで詳しく解説しています。Permission Boundary・SCPの相互作用と、Identity Centerを活用したシングルサインオン設計は、Organizationsと組み合わせることで真価を発揮します。

CloudTrail・Config（第18軸）との統合

CloudTrail Lakeの監査基盤に加え、Config Rulesによるリソースコンプライアンス継続評価、Auto Remediationによる非準拠リソースの自動修復は第18軸で解説しています。両シリーズを組み合わせることで、包括的なガバナンス・コンプライアンス基盤を構築できます。

Cost Optimization（第23軸）との統合

Budgets Actionsを用いたOU単位のコスト制御、Cost Explorerによる組織横断のコスト分析は第23軸で解説しています。Organizationsの組織タグポリシーと組み合わせることで、アカウント・チーム・プロジェクト単位の精密なコスト管理が実現します。