「AWS の変更が多すぎて、どれが自分の仕事に関係するのか分からない」という声をよく聞きます。この記事は、2026年9月28日〜10月4日に発表されたものから、実務の判断に関わる4件（GuardDuty・Systems Manager・IAM Identity Center・ECS）だけを選び、何が変わったかと、立場ごとの関わり方をまとめたものです。
この記事の結論
- Amazon GuardDuty の有効化を、AWS Organizations の宣言型ポリシーで一元管理できるようになった
- SSM ドキュメントを AWS RAM 経由で、組織や OU 単位に共有できるようになった
- IAM Identity Center のマルチリージョン対応が、オプトインのリージョンなどにも広がった
- Amazon ECS が、VPC Lattice を使うサービスでブルー/グリーン・リニア・カナリアのデプロイを標準でできるようになった
- 同じ週に出た GuardDuty Runtime Monitoring の請求の変更は、別記事で扱っている
何が起きたか
GuardDuty の有効化を Organizations の宣言型ポリシーで一元管理
GuardDuty が、AWS Organizations の宣言型ポリシーに対応しました。委任管理者のアカウントから、組織のルート・OU・個別アカウントに対して「GuardDuty をどう有効にするか」の設定を当てます。全リージョン共通の既定を決め、特定のリージョンだけ上書きすることもできます。ポリシーを当てた設定は、GuardDuty のコンソールや API からは上書きできません。商用リージョンと GovCloud（US）で使えます（AWS What’s New）。
SSM ドキュメントを AWS RAM で組織・OU に共有
Systems Manager のドキュメント（運用手順や自動化を書いたもの）を、AWS RAM のリソース共有に入れて、組織全体や特定の OU に共有できるようになりました。これまでは「公開」か「アカウント ID の列挙」しか選べませんでした。アカウントが組織に加わったり抜けたりすると、共有先も追従します。追加料金はありません（AWS What’s New）。
IAM Identity Center のマルチリージョン対応が拡大
IAM Identity Center の複製先に、オプトインのリージョンと、GovCloud（US）・中国リージョン内のリージョン間が加わりました。以前は、既定で有効な商用リージョンだけが対象でした。使うには組織インスタンスと、マルチリージョンのカスタマー管理キー（KMS）が必要で、KMS の通常料金がかかります。Identity Center 自体は無料です（AWS What’s New）。
ECS が VPC Lattice でブルー/グリーン・リニア・カナリアに対応
VPC Lattice をサービス間通信に使っている ECS サービスで、ブルー/グリーン・リニア・カナリアのデプロイ方式を ECS の機能として選べるようになりました。切り替えの途中に Lambda での検証や一時停止を挟め、CloudWatch アラームやデプロイのサーキットブレーカーで自動ロールバックもできます。新規・既存のサービスどちらにも使え、VPC Lattice が使えるリージョンが対象です（AWS What’s New）。
READ ALSO — プロフェッショナル向け・段3 基盤
GuardDuty Runtime Monitoring が Security Hub に含まれた｜請求先が変わる
CHECK 1ここまでの確認
GuardDuty の組織ポリシー対応で、これまでの運用から変わったことはどれ?
答えと解説
答え: 1. リージョンごとに有効化の設定を揃える作業が、組織のポリシー1つで済む
変わったのは「設定の置き場所」です。ポリシーを組織のルート・OU・アカウントに当て、全リージョンの既定と例外を一箇所で決めます。「仕組みとして何が変わったか」の節を読み直してください。
仕組みとして何が変わったか
4件のうち、GuardDuty と SSM は同じ形の変化です。「各アカウント・各リージョンに個別に設定する」仕事が、「組織に1回当てる」仕事に変わりました。
これまでの GuardDuty は、リージョンごとに有効化の設定を揃える必要があり、時間とともにずれが出ることが課題でした。ポリシーなら、設定の責任がセキュリティ管理者の1箇所に集まり、各アカウントの担当者は手を出せません。 逆に言えば、例外を許す設計はポリシーの側に書いておく必要があります。
SSM ドキュメントも、「共有先の一覧を人が保守する」状態から、「組織の構造に共有が追従する」状態になりました。新しいアカウントを作るたびに共有先を足す作業が要りません。
| 項目 | 変わる前 | 変わった後 |
|---|---|---|
| GuardDuty の有効化 | リージョン・アカウントごとに設定 | 組織のポリシーで一括、例外はリージョン単位で上書き |
| SSM ドキュメントの共有先 | 公開、またはアカウント ID の列挙 | RAM で組織・OU を指定 |
| Identity Center の複製先 | 既定で有効な商用リージョン | オプトインのリージョンなどにも拡大 |
| ECS の段階的デプロイ | VPC Lattice 利用時は自前で組む | ECS の機能として方式を選べる |
CHECK 2ここまでの確認
SSM ドキュメントを組織全体に配りたいとき、今回の変更で使えるようになった方法はどれ?
答えと解説
答え: 2. AWS RAM のリソース共有に入れ、組織または OU を指定する
これまでは公開か個別のアカウント ID の列挙しかありませんでした。RAM を通せば、アカウントの増減に共有先が追従します。「何が起きたか」の節を読み直してください。
どんなものに活用できそうか
- アカウントが増え続けている組織の脅威検知の足並みを揃える。 新しいアカウントが作られても、GuardDuty が最初から有効な状態になるので、「入れ忘れ」の確認作業を減らせます
- 共通の運用手順を全アカウントに配る。 障害時の調査手順や、パッチ適用の自動化ドキュメントを1つ作り、OU 単位で共有すれば、各アカウントが写して使う運用をやめられます
- サービス間通信を VPC Lattice に寄せているマイクロサービスで、リリースの影響範囲を絞る。 カナリアで一部のトラフィックだけ新しいタスクに流し、アラームが鳴ったら戻す、という流れを ECS 側に任せられます
一方で、アカウントが1つか2つの小さな環境で GuardDuty を使っているなら、宣言型ポリシーに急いで移る理由は薄いです。 ポリシーを当てると各アカウントから設定を変えられなくなるため、検証用アカウントで設定をいじりたい場面と衝突することがあります。
立場ごとに何が変わるか
- 未経験: いまは関係ありません。まずは「アカウントを分ける」「脅威を検知する」とは何かを押さえる段階で、組織単位の運用はそのあとです
- 学習中: Organizations のポリシーで組織の設定を縛る考え方は、SCP などと並べて理解すると整理しやすくなります。試験では、セキュリティ専門知識（SCS）やソリューションアーキテクト・プロフェッショナル（SAP）の、複数アカウント管理の分野につながります
- 実務: 複数アカウントを運用しているなら、GuardDuty の有効化状況と SSM ドキュメントの共有方法を見直す価値があります。ECS で VPC Lattice を使っているなら、デプロイ方式の選択肢が増えています
- プロ: 顧客の「アカウントごとのばらつきを無くしたい」という要件に対して、ポリシーで強制する案と、例外を許す案の両方を、責任の置き場所とあわせて提案できます
まとめ
- GuardDuty の有効化が、Organizations の宣言型ポリシーで一元管理できるようになった
- SSM ドキュメントを RAM 経由で、組織や OU に共有できるようになった
- IAM Identity Center のマルチリージョン対応が、オプトインのリージョンなどに広がった
- ECS が、VPC Lattice を使うサービスで段階的なデプロイ方式を標準で提供するようになった
- どれも既存の設定は変わらないので、困りごとがあるところから試せば十分です
参照ソース
- Amazon GuardDuty now supports centralized management using AWS Organizations declarative policies（AWS What’s New）（2026年10月時点）
- AWS Systems Manager now supports sharing documents through AWS Resource Access Manager（AWS What’s New）（2026年9月時点）
- AWS IAM Identity Center extends multi-Region support to more AWS Regions（AWS What’s New）（2026年10月時点）
- Amazon ECS adds Amazon VPC Lattice support for blue/green, linear, and canary deployments（AWS What’s New）（2026年10月時点）
