【イベントレポート】Ops-JAWS Meetup34 Organizations & ControlTower #opsjaws

いつも記事を読んでいただきありがとうございます！
モブエンジニア（@mob-engineer)です！

今回は2025.04.16（水）に開催したOps-JAWS Meetup34 Organizations & ControlTowerへ参加しましたので、アウトプットとしてイベントレポートを執筆しました。

初見の方でもサクッと読めるように平易な表現で執筆しておりますので、お気軽にお読みいただければ幸いです。

誤字脱字、わかりづらい表現、認識相違などは極力なくすように心がけています。そのうえで、リアルタイムで執筆しておりますので、誤字脱字、わかりづらい表現、認識相違などがあるかもしれません。

イベントページ

目次

• LT
  • AWSのマルチアカウント管理 ベストプラクティス最新版 2025
  • AWSのマルチアカウント管理 実践編
  • クォータ監視、AWS Organizations環境でも楽勝です✌️
  • AWS Control Towerを数年運用してきての気づきとこれから
  • コスト、カオス、権限　AWS Organizations 小ネタ3選
  • Organizations環境の証跡管理に「CloudTrail Lake」をおすすめする理由
  • AWS Organizations下でのカスタムリソースの使い方
• まとめ

LT

AWSのマルチアカウント管理 ベストプラクティス最新版 2025

参考サイト

• 前置き
  • 今回のAWS Summitのセッションでガバナンス部門がない
  • さわりとして本セッションを取り上げている
• 自己紹介
  • AWS Japanのシニアソリューションアーキテクトの方
• スタートライン
  • ガバナンスの管理はお客様が求めているものから
  • AWSアカウントはリソースのコンテナ
    • アカウント単位で分けることで開発が好き放題しても他へ影響がない
• マルチアカウント管理
  • ランディングゾーンを用意することが大切
    • スケーラブルでセキュアなマルチアカウント環境
    • Control Towerは実装方法の一つ
    • （個人的意見）Control Towerはそういった役割だったのね
  • ランディングゾーンで実現する機能・実装方法はここ数年変わっていない
    • 2025年も変わっていかないと予想される
  • 新機能はより高度はガバナンスが求められる場合利用すればいい
    • 一部（Root Access Managerなど）は利用したほうがいい場合も
• 進め方のベストプラクティス
  • 小さく始めていく
    • （個人的意見）小さく始めるのは開発の基本だったりしますよね
  • アカウント払い出しを積極的に行う
    • 中央管理者がアカウントを払い出す
    • セルフサービス化・ダッシュボード化に伴う開発が必須
      • （個人的意見）GCASもその一種だったんですね
  • セキュリティベースラインを見極める
    • AWS SRAをもとに実装することが大切
    • 最低限の実装であればBLEAのベースラインが妥当
  • ログ集約をどうするか
    • CloudTrail・CloudWatchで行うのがベター
    • （個人的意見）オブザーバビリティの考えが使えそうですね
  • コスト管理
    • コスト管理については既存のダッシュボードを利用することがベター
    • （個人的意見）FinOps対応してみるとよいのかなぁと思いつつ実装が難しいですよね

AWSのマルチアカウント管理 実践編

参考サイト

• 自己紹介
  • AWS Japan所属のシニアセキュリティコンサルタント方
  • AWSプロフェッショナルサービスを担当されている
• AWSプロフェッショナルサービス
  • ソリューションアーキテクトよりビジネス視点で提案を行う
  • 内製化支援をメインにアウトプットを行っている
    • （個人的意見）ユーザへ委任していくは本当に大切
• マルチアカウント統制あれこれ
  • 事業者によって抱えている課題は多種多様
    • 「統制基盤を構築したが運用をどうするか」など
  • 理想的なセキュリティ統制を実現するためのフレームワークはそろっている
    • （個人的意見）理想的なセキュリティ統制を実現するのは現実的に...
  • セキュリティ方針を定めることが大切
    • とはいえ、セキュリティ方針をガチガチにするとビジネスが進められない場合も
  • 理想的なセキュリティ統制を実現するためには段階的な実行が必要
    • 全てを行うのではなく企業特性に応じて実施することが大切
  • 進め方としてゴール定義から行っていく
    • （個人的意見）提案もその流れですよね
• ユースケース
  • 事業者A：統制基盤を構築したが運用がうまくできていない
    • マネージドサービスを組み合わせるだけでも運用改善につながる場合も
    • 社員数が少ない場合のマルチアカウント統制として外部事業者を利用した
      • 外部事業者にすべてを丸投げせず統制管理は社員が行った
      • （個人的意見）おっしゃる通りですね
  • 事業者B：統一されたOrganizationsがない状況だった
    • BLEAのオプションであるAWS Service Catalogを利用して設定簡素化した
    • メンバーアカウントへの設定流し込みのみBLEAに任せた
  • 事業者C：CfCT・コードへの抵抗感は少ないが柔軟性を持たせたい
    • Control Towerのログ集約機能を利用して管理
    • すでにCloudTrailリソースが作成されている場合、その分追加でコストが発生する
• 議論ポイント
  • OU構成をどうするか
    • 第1階層は統制要件に応じて作っていく
    • AWSアカウントを分類し、セキュリティベースラインのパターン分けが必要か検討する
      • （個人的意見）パターン分けするとシンプルに考えられるので大切ですね
  • アカウント移行をどうするか
    • 別Organizationsに移行するのは大変
    • すでに統制移行がある場合は注意して考える必要がある
  • ID管理をどうするか
    • 認証・権限ふくめすべて一元管理するのがベターというわけではない
    • 場合によっては認証のみ一元管理する場合もある
  • ランディングゾーンをどうするか
    • ワークロードに応じてコストが変動するため予測は厳しい
    • 予実分析を行いつつ改善していくことが大切
• まとめ
  • マルチアカウント管理は状況に応じてベストプラクティスが変わってくる

質疑応答

• CTが導入される前からOrganizationsを活用している環境でCT導入する方法
  • あえてCTを導入する必要はない場合もある
  • CTを入れることで得られるベネフィットを考えたほうがいい
  • 既存Organizationsを塩漬けにして、新規Organizationsで運用するという手も
• 自前でConfigを展開している場合は
  • Config機能が強いため実装するとしても考えることが大切
• CTを導入していない組織で初期設定を行う良い方法は
  • BLEAを利用するのがおススメ
• IAMで各アカウントごとに利用している場合、IAM Identity Centerに移行する注意点
  • AWS Identity and Access Management Access Analyzerを利用して分析するのがいい
• CT運用開始後に管理対象のリージョンを追加したい場合は
  • 追加するのはやめたほうがいい
  • 新しくCT環境を構築するのがベター

クォータ監視、AWS Organizations環境でも楽勝です✌️

登壇資料

参考サイト

• 自己紹介
  • ENECHANGE所属のVPoT・CTO室マネージャー
  • 直近ではcollmboを開発されている
• クォータあれこれ
  • リソース構築時にクオータ上限に引っかかって構築できない場合も
    • （個人的意見）毎日AWSサポートにクォータ上限緩和申請を行っていたなぁ
  • クォータ管理を行うことでW-A信頼性の柱を達成できる
  • 実装ガイドが公開されているのでそちらを参照に実装していく
• 進め方
  • 基本的に手順通り進めていけば問題ない
    • （個人的意見）Webhookの設定は悩みそうですね
  • 設定を行えば引き上げ通知もきちんと来る
    • 引き上げ対象外のリソースをチューニングすることも可能
• まとめ
  • Organizations環境でも楽に設定できる
    • （個人的意見）おうちOrganizaitons環境を構築しないとなぁ

AWS Control Towerを数年運用してきての気づきとこれから

参考サイト

• 自己紹介
  • 2021年からCCoEを担当している方
  • その前はインフラエンジニアとして活動していた
  • 今年度はAWS全冠を目指している
  • 社内外でもクラウド普及・推進活動を行っている
• Control Towerとは
  • 2021年にGAした統制的・予防的管理を行えるサービス
  • AWSベストプラクティスに沿った環境構築を実現できる
  • 利用するのであればTerraformで管理したほうがいい
    • （個人的意見）手運用だと厳しいですからね
• Control Towerのつらさ
  • Orgainizationsが多いとランディングゾーンのアップデートに時間がかかる
  • アップデート直後に予期せぬ課金が発生する
  • 作業前に関係各所とのネゴを取っておくことが大切
    • （個人的意見）分かりみが深い話ですね
  • マネージドサービスとしてのSIEMが存在しない
    • OSSは存在するがマネージドサービスでないのはちょっと
  • 既存アカウントを別の組織から組織編入すると請求情報が消えてしまう
    • （個人的意見）胃が痛くなるトラップですね
  • マルチアカウントだと請求管理がなかなか大変
• 今後やっていきたいこと
  • リソースコントロールポリシー・宣言型ポリシーの導入
    • SSE-C暗号化の防止など
    • （個人的意見）予防的統制だからConfigだと難しいですよね
  • EC2インスタンスIMDSv1の撲滅を行う
• まとめ
  • AWS Control Towerは素晴らしいサービス
    • ぜひ利用しましょう

コスト、カオス、権限　AWS Organizations 小ネタ3選

参考サイト

• 自己紹介
  • アイレット所属のエンジニアの方
• OU単位でコスト分析
  • AWS Cost Catogoriesを利用すればコスト分析をカスタマイズ可能
  • Organization単位でコスト分析も可能
    • そのまま利用できないためスクリプト処理が必要
• SCPでお手軽カオスエンジニアリング
  • 権限を奪うSCPをアタッチ⇒ワークロードの挙動を見てみる
  • 開発環境用のアカウントで実装してみた
    • エラーとしてLambdaからS3のアクセスが失敗した
    • （個人的意見）SCPの挙動を調べるために自環境で検証してみたいですね
• 管理アカウント上の権限抑制
  • 委任できるものはできるだけメンバーアカウントに委任する
  • 管理アカウントのアクセスは最小限にとどめる
  • できない場合もいくつかある、、、
  • 例）ソリューションを構築するためのIAMロールの権限を渡したいが制限のないロールは差くせしない
    • CreateRole経由であれば制限をかけられる
• まとめ
  • 今日のできないを明日のできるにする

Organizations環境の証跡管理に「CloudTrail Lake」をおすすめする理由

参考サイト

• 自己紹介
  • クラスメソッド所属のエンジニアの方
  • 前職は独立系SIerでインフラエンジニアをされていた
  • Organizations関連のブログを執筆されているTopEの方
• AWS CloudTrailとは
  • APIアクティビティを監視・管理することができる
    • （個人的意見）ざっくり言えば、APIの動きを見える化できるサービスですね
  • よく使う設定として証跡と組織の証跡がある
    • 証跡：S3などのストレージで出力させる
    • 組織の証跡：設定を他の組織へコピーできる
• 証跡管理
  • 統制：設定によっては勝手に変更される
  • コスト：ログ保存コストがかかる
  • 運用：ログ管理の工数増加がかかる
  • 組織の証跡を利用すると管理外で予期せぬログ発生が
• CloudTrail Lake
  • ざっくり言えば、ログの可視化を簡単に行えるサービス
  • イベントデータストアを管理しているアカウントのみで設定すれば問題ない
    • 統制問題：勝手に設定を変えられることがない
    • コスト問題：管理アカウントのみにコストがかかるため削減
    • 運用管理：クエリエディアもできるため可視化が容易
• 改善ポイント
  • コストをもう少しお安く
  • 生成AIによるクエリ生成機能の日本語対応をしてもらいたい

AWS Organizations下でのカスタムリソースの使い方

参考サイト

• はじめに
  • Organization周りのカスタムリソースの利用方法について
• 自己紹介
  • NRIネットコム所属のエンジニアの方
  • インフラ構築・顧客提案などをされている方
• カスタムリソースとは
  • ざっくり言えばCloudFormation単体で対応できないリソース構築に対応するサービス
  • 複雑なアーキテクチャ構築に向いている
• ユースケース
  • テンプレート内のIAM Access Analyzerのアーカイブルール更新する必要がある場合
    • 都度APIを実行する必要があるため最新化が難しい
• 注意事項
  • 削除時の依存関係を考慮する必要がある
    • DependsOnを明記する必要がある
    • （個人的意見）Terraformでもありますよね
  • 更新時に動作するか考慮する必要がある
    • カスタムリソースを動かす部分のみを更新してもう個かない場合がある
  • レスポンスの設定,タイムアウト設定を必ず行う必要がある
    • （個人的意見）Lambdaの15分ルールもありそうですね
    • プロパティでタイムアウト値を設定することができる
  • クロスアカウントでの設定を考慮する
    • 実行ロールを適切に管理することが重要
• まとめ
  • カスタムリソースを使うことでうまく管理できる場合もある

まとめ

Organizationsまわりについてはきちんとキャッチアップできていなかったので、今回のセミナーでOrganizationsを考えたガバナンス統制をどうやって進めればいいのかを考えることができました。

個人的にBLEAをきちんと読み込んで、アウトプットしたいと思いました。
最後まで記事をお読みいただきありがとうございました！！