[Chalk talk] New capabilities for achieving effective governance at scale に参加しました #COP365 #AWSreInvent

こんにちは、クラウド事業本部 コンサルティング部のいたくらです。
AWS re:invent 2025 は現地参加してきました！

2025 年はそろそろ終わりますが、現地で受けてきたセッション「New capabilities for achieving effective governance at scale」を紹介します。
Chalk talk セッションはスピーカーと参加者がインタラクティブにやりとりするため、聞き取れなかった部分もありますがご了承ください。

3 行まとめ

• AWS Organizations のアカウント移行が 7 ステップから 2 ステップに簡素化され、サポートプランなどの特典も維持されるようになった
• Control Tower の新しいコントロール専用エクスペリエンスにより、ランディングゾーン全体を構築せずにコントロールのみを適用できる
• 自動アカウント登録機能により、OU にアカウントを移動するだけでベースラインとコントロールが自動的に適用される

セッション概要

• セッションID: COP365
• タイトル: New capabilities for achieving effective governance at scale
• スピーカー
  • Alpna Daniels, GTM Leader, Cloud Governance, Amazon
  • Irina Masroor, Senior Technical Product Manager, Amazon
• レベル: 300 – Advanced

Organizations often struggle to scale effective governance during rapid cloud adoption and complex transitions. This session introduces new governance capabilities and controls that can help customers secure and manage their multi-account environments and scale operations with governance and compliance. Learn how to transfer accounts, establish and manage controls quickly, enforce policies, or understand potential standards so you can meet compliance standards and enforce your organization’s best practices.

（機械翻訳）
組織は、急速なクラウド導入や複雑な移行の過程で、効果的なガバナンスをスケールさせることに苦労することがよくあります。このセッションでは、マルチアカウント環境を安全に管理し、ガバナンスとコンプライアンスを維持しながら運用をスケールさせるための新しいガバナンス機能とコントロールを紹介します。アカウントの移管方法、コントロールの迅速な確立と管理、ポリシーの適用、コンプライアンス基準を満たし組織のベストプラクティスを実施するための潜在的な標準方法について学びます。

セッション内容

アジェンダ

AWS Organizations のアカウント移行機能

セッションの冒頭で、参加者への質問がありました。「アカウントをある組織から別の組織へ移行したことがある人はいますか？」という問いかけに対し、会場からは以下のような理由が挙げられました。

• グローバル展開のため
• 新規買収（M&A）のため
• セキュリティ体制の強化のため
• 間接費の削減のため（アカウント統合）

従来のアカウント移行プロセス

従来のアカウント移行には 7 つのステップが必要でした。まずアカウントをメンバーアカウントから削除してスタンドアロン状態にし、支払い情報などの前提条件を満たし、本人確認を行い、サポートプランを一度解約します。その後、新しい組織への招待を送信し、招待を受け入れるという流れです。

この従来のプロセスは、複数のステップがあるだけでなく、各ステップで失敗する可能性があり、さらにサポートプランなどの特典を放棄しなければなりませんでした。

新しいアカウント移行機能

新しいアカウント移行機能では、この 7 ステップが 2 ステップに簡素化されました。移行先の組織から招待を送信し、移行元の組織で招待を受け入れるだけです。

デモでは、AWS Organizations コンソールから操作が行われました。AWS アカウントページで「Add an AWS account」から「Invite an existing AWS account」を選択し、移行するアカウントの ID またはメールアドレスを入力して招待を送信します。移行するアカウントでは 14 日以内に招待を受け入れる必要があります。

新しいプロセスでは、時間の節約だけでなく、プロセスの標準化も実現されています。アカウントの設定方法に関係なく、前提条件が不要になり、サポートプランなどの特典も移行時に維持されます。

アカウント移行の注意点

招待にはクォータ（上限）があり、送信された招待や保留中の招待もカウントされます。招待の有効期限は 14 日間です。

権限については、管理アカウントには招待を送信する IAM 権限が、メンバーアカウントには招待を受け入れる権限が必要です。また、アカウントが委任管理者（Delegated Administrator）に設定されている場合は、移行前に解除が必要です。

なお、SCP でアカウントの招待受け入れ権限を制限することで、フィッシング対策が可能です。

Control Tower の新しいコントロール専用エクスペリエンス

Control Tower 導入の課題

参加者からは、Control Tower の導入に関して、レガシーな組織構造がある場合の対応、既存のポリシーの再設定、Config との連携設定、アカウント登録にかかる時間といった課題が挙げられました。

従来の Control Tower セットアップ

従来の Control Tower を有効化するには、Organizations への信頼されたアクセスの確立、リージョンの設定、OU とアカウント構造の定義、ガバナンス下のすべてのアカウントへの AWS Config のデプロイ、オプションサービス（SSOログイン、暗号化など）の設定といった手順が必要でした。さらに、Control Tower がリソース保護のための必須コントロールを自動的にデプロイします。

これらの必須コントロールは SCP の容量を消費するため、カスタム SCP に使用できる容量が減少するという課題もありました。また、この登録が完了してはじめて Control Catalog を閲覧できました。

新しいコントロール専用エクスペリエンス

新しいコントロール専用エクスペリエンスでは、Control Tower に登録する前でも Control Catalog を閲覧できるようになりました。また、ランディングゾーン全体を構築せずにコントロールのみをオンボードできるため、レガシー環境の組織構造を変更せずにコントロールを適用できます。

必須の設定ステップは、Organizations への信頼されたアクセスの確立とリージョンの定義のみです。Detective コントロールを使用する場合のみ、対象の OU に AWS Config をデプロイするオプションステップがあります。

Control Catalog の活用

Control Catalog では、他の顧客がよく使用しているコントロール（Top enabled controls）、規制フレームワーク別、コントロールの動作別といったカテゴリでコントロールを検索できます。

コントロールの動作は 3 種類あります。Preventative（予防的）は SCP や RCP で、特定のアクションを事前に防止します。Detective（検知的）は AWS Config ルールで、アクションが実行された後に検知します。Proactive（プロアクティブ）は CloudFormation Hooks で、開発者がテンプレート作成時に許可・禁止を事前に確認できます。

自動アカウント登録機能

新しい機能として、Auto Account Enrollment が紹介されました。この機能を有効にすると、アカウントを OU に移動した際に自動的に登録され、その OU のベースラインとコントロールが自動的に適用されます。逆に、ガバナンスから外すとコントロールが自動的にロールバックされます。

スピーカーとオーディエンスの Q&A から得られた情報

• Proactive コントロールと Terraform について質問がありました。Proactive コントロールは CloudFormation Hooks ベースのため、CloudFormation 経由でリソースを作成した場合にのみ適用され、Terraform 経由では適用されません。
• AWS Config のリソース記録については、特定の OU でのリソース記録数を減らす方法は現時点ではありません。Control Tower はコンプライアンスデータの正確性を重視しているためです。
• コントロールのテスト方法については、特定のコントロールの有効化をテストする場合はテスト用 OU を作成し、ランディングゾーンのアップグレードのような大きな変更をテストする場合は別の Test Organization を構築することが推奨されていました。

さいごに

2025年10月から11月にかけて、このセッションで紹介されていた自動アカウント登録機能、アカウント移行機能、コントロール専用エクスペリエンスの発表があったのは認識していたので、知っている機能ではあったものの、改めて前後比較してみると便利になったなという印象を受けました。

このセッションをベースに弊社の振り返り勉強会（re:Growth 2025 東京）で登壇しました。本 Chalk Talk 終了後、スピーカーの方に色々と質問してみた内容や回答をプラスした内容で登壇しましたので、内容に興味がある方は是非ご一読いただければと思います。
https://dev.classmethod.jp/articles/202512-regrowth2025-tokyo-aws-control-tower/

この記事がどなたかのお役に立てれば幸いです。
以上、クラウド事業本部 コンサルティング部のいたくら（＠itkr2305）でした！