AWS アカウント管理：Health ダッシュボード、Organizations、SCP、Control Tower

SysOps / CloudOps 向けの要点：AWS Health がインシデントをどう見せるか、Organizations がアカウントをどう束ね SCP がどう制限するか、Control Tower が統制されたマルチアカウント環境をどう立ち上げるか。コースでは Billing（一括請求先、コストツール）を組織の management アカウントとセットで扱います。請求書と配賦には請求側の Billing コンソールを使う一方、以下は主に Health、Organizations、Control Tower です。Service Catalog、CloudWatch 請求アラーム、Budgets、Cost Explorer、コスト配分タグ、CUR、Compute Optimizer、Billing Conductor については AWS Service Catalog, Billing Alarms, Cost Explorer, Budgets, and Cost Tools を参照。

AWS Health ダッシュボード（二面）

サービスヘルス（公開／「Service History」）

旧称 AWS Service Health Dashboard — 時系列の リージョン × サービス ステータス、RSS、多数の顧客に影響する オープン なグローバル障害。
一般的な可用性の絵で、あなたのリソース専用ではない。

アカウントヘルス（パーソナライズ）

旧称 Personal Health Dashboard (PHD)。現在はコンソールの Health（ベル → Event log / Health）。
オープン／最近の問題、スケジュールされた変更（例：EBS メンテ）、影響を受けるリソース、修復のヒント、実際に使うリソースに触れる問題のイベントログ（発生／解消時刻）。
グローバルな体験：公開のサービスヘルスが広く見えても、あなたの利用（例：us-east-2 の EC2）に関係するインシデントを表示。

組織ヘルス

AWS Organization 内のすべてのアカウントにわたる Health の集約ビュー（組織コンテキストで設定）。
その上に EventBridge で自動化（下記）。

AWS Health → EventBridge

AWS Health は EventBridge ルールでマッチさせ、SNS、Lambda、SQS、Kinesis などに送れます。

アカウント固有のイベント（利用リソース）と、必要ならパブリックなサービスイベント。
ユースケース： EC2 のプラットフォーム更新が予定されたらメール；「IAM キー露出」系の検知でキーを無効化する Lambda；リタイア予定インスタンス向けの EC2 再起動などターゲットで、強制停止を待たずに回復。

注：他の AWS コントロールプレーン連携と同様、オーケストレーションは非同期とみなし、リトライと冪等性を設計する。

AWS Organizations

複数アカウントを一つの organization にまとめるグローバルサービス。

Management アカウント（請求／「マスター」）— 一括請求（一つの支払方法で全メンバー支払い）。メンバーは招待で参加（子で承認；招待は期限切れになり得る — コースでは約 2 週間）か、組織が作成（メール + OrganizationAccountAccessRole 型の IAM ロール名）。
AWS アカウントは同時に一つの organization にしか属さない。
料金上の利点： 集約利用量でボリューム割引（EC2、S3 など）；Reserved Instance と Savings Plans の割引は共有が両方（または関係アカウントすべて）で有効なときに横断で使える — 請求アカウントを含め共有オフでコミットメント効果を分離できる。

組織単位（OU）

ルート OU に management アカウント。ネストした OU（dev / test / prod、事業部、プロジェクトなど）を作成。
SCP と運用境界に合わせてメンバーアカウントを移動。ベストプラクティス： 強い理由がなければ management はルートに置く。

マルチアカウントの理由（1 アカウント多 VPC との比較）

VPC だけよりブラスト半径の分離が強い。
コスト配賦のタグ標準；組織全体の CloudTrail を中央 S3 バケットへ；CloudWatch Logs の中央ログアカウント；management からの break-glass / 自動化用クロスアカウント IAM ロール。

一括請求（SysOps 視点）

料金は management に集約。Billing と Cost Management で請求書、予算、配賦（タグ、CUR など）。

サービスコントロールポリシー（SCP）

SCP は ルート、OU、アカウントに付く組織ポリシー。メンバーアカウントの IAM プリンシパルがこれ以上持てない権限の上限を制限する — 単体では権限を付与しない。

Management は除外 — SCP は management を制限しない（組織ロックアウト防止）。
メンバーでの実効アクセス = アイデンティティポリシーと OU パス上継承したすべての SCP の積；スコープ内の明示的 Deny が勝つ。
通常は上位に FullAWSAccess（全サービス許可）を付け、Deny SCP を足す（または列挙だけ許可する許可リスト SCP — ずっと厳しい）。
実演効果： OU に Deny S3 すると メンバーのアカウント root でも S3 がブロックされる。

SCP パターン（試験風）

aws:RequestTag/department が存在しない限り ec2:RunInstances を Deny（起動時タグ強制）。
business-unit タグが infra- で始まらない限り RunInstances を Deny（存在だけでなく形）。
deployment-type タグが in-region か edge のみなど、列挙のみ許可する RunInstances Deny。
リージョン許可リスト： */* に対する Deny * と aws:RequestedRegion の StringNotEquals で eu-central-1、eu-west-1 など以外を拒否。

その他の組織ポリシー種別（把握）

Backup policies — 組織単位の AWS Backup プラン。
Tag policies — 監査とコスト配賦のため タグキー／値を標準化；非準拠リソースの一覧；タグ準拠シグナルで EventBridge から反応。

`aws:PrincipalOrgID`

リソースポリシー（例：S3 バケット）で、すべての account ID を列挙せず組織内任意アカウントのプリンシパルを許可できる。

AWS Control Tower

Organizations の上の、意見がはっきりしたランディングゾーン：マルチアカウント構成、ガードレール、ダッシュボードを手配線ほぼなしで。

ランディングゾーンウィザード：ホームリージョン、未承認リージョン向けオプションの Region deny、ガバナンス対象の追加リージョン。
OU を作成（コースデモ：Security + Sandbox；構築後は Core / Custom と audit / log archive が Core 下、などの表示）。
専用アカウント： Log archive（不変に近いログ）、Audit（セキュリティツール）、management / ワークロードの型 — アカウントごとにメールが必要。
アカウントアクセス： 登録済みすべてに一つのポータルから入るデフォルトは IAM Identity Center（SSO の後継）；自己管理は可能だが重い。
ランディングゾーンで CloudTrail 有効；オプションで S3 配信と KMS 暗号化。
ガードレール： 予防（SCP — 例：log archive 削除禁止、ログバケット公開読取禁止、CloudTrail 無効化禁止）と検知（多くは Config ルール）。コースではデフォルト束に約 20 予防と約 2 検知 — 数は変わり得る。
運用の目安： 登録後、Control Tower フロー（Account Factory、OU 登録）でガバナンス下に置きたいアカウント・構造を扱う；そのリソースを生の Organizations と争わない。
コスト／時間： プロビジョニングは遅い（コース：約 60 分）かつ有料 — 個人アカウントでフル構築は避けるかコストを受け入れる。

要点

Service Health = 広い リージョン／サービスの時系列；Account Health = あなたのリソース、影響資産、メンテ、修復；Org Health = 集約ビュー；ベル / Event log。
Health → EventBridge で SNS アラート、Lambda 修復、EC2 アクションなど、計画作業とリスクイベント向け。
Organizations = グローバル、アカウントあたり 1 org、management 請求、一括請求、ボリューム割引と RI / Savings Plans 共有（アカウントごとの共有トグル）、ネスト OU、組織トレイル / 中央ログ。
SCP はメンバーのみ制約；Deny と許可リストが強力；タグとリージョン条件は試験でよく出る；aws:PrincipalOrgID がリソースポリシーでのクロスアカウント信頼を簡素化。
Control Tower = ランディングゾーン + ガードレール（SCP + Config）+ Identity Center ポータル + Security/Audit/Log アカウント；高コストで時間がかかる — 何が作られるかを知ることが、prod でのクリックだけより重要。

Claudeによる翻訳