クラウドインテグレーション事業部 セキュリティセクションの村上です。米国フィラデルフィアにて開催中の AWS re:Inforce 2025 に参加しています。
昨日深夜、”Welcome to Philly!” の機内アナウンスとともにフィラデルフィアに降り立ってから12時間足らずでイベント開始という慌ただしいスケジュールですが、色々学んで帰りたいと思います！

セッション概要

項目 内容
セッションタイトル APS332: Governance tradeoffs in enterprise CI/CD: Central vs. distributed
セッションタイプ Chalk Talk
スピーカー Vijay Kamath 氏, Matt Laver 氏

このセッションでは、マルチアカウントの AWS 環境における CI/CD パイプラインアーキテクチャについて、中央集権型と分散型の比較、それらを組み合わせたハイブリッド型の紹介が行われました。
また、Chalk Talk ということで参加者の CI/CD パイプライン運用状況共有や意見交換も交えながら進みました。

中央集権型 CI/CD と分散型 CI/CD のメリット・デメリット

実際のセッションの説明の流れとは少し順序入れ替えて、まず初めにマルチアカウント環境における Centralized (中央集権型) CI/CD と Decentralized (分散型) CI/CD がそれぞれどういったものを指すのかと、それぞれのメリット・デメリットを整理しておきます。

中央集権型CI/CD

すべてのパイプラインを中央のアカウントで運用し、各アカウントにデプロイするようなモデルです。
標準化されたテンプレートやセキュリティチェックを適用しやすく、コンプライアンス要件を満たしやすいメリットがあります。
一方で、開発チームの自律性を損ない、柔軟性をもたせるのが難しく、クロスアカウントの IAM 管理が複雑になるなどのデメリットがあります。

分散型CI/CD

各開発チームや環境毎に CI/CD パイプラインを構築・運用するモデルです。
開発速度の向上や新技術の採用がしやすいメリットがあります。
しかし、組織全体でのセキュリティレベルを均一に保つことが難しくなる、環境毎にパイプライン開発工数が重複してかかるなどのデメリットがあります。

マルチアカウント環境におけるCI/CDの設計の難しさ

セッションは CI/CD の基本的な流れの説明から始まり、なぜエンタープライズ環境でマルチアカウント構成になるのか、その背景が語られました。
部署ごとのガバナンス、請求の分離、技術的な理由、さらには買収や分社といった組織的な要因が挙げられます。
このようなマルチアカウント環境では、CI/CD パイプラインのコスト、セキュリティ、管理、アクセス管理といった課題が発生します。

参加者の中には、「インフラは集中型、アプリケーションは分散型にしている」という方や、「まだ正解を模索中」という方もいらっしゃいました。
中央集権型はガバナンスに優れる反面、柔軟性や開発速度が犠牲になることがあります。
一方、分散型は迅速な開発を可能にするものの、同じコンポーネントの重複によるコスト増大や、全体のメンテナンス工数が増える傾向があることが指摘されました。

AWS では以前、リポジトリが中央集権的だったが、現在はプロダクト別に分散されており、これは開発速度を重視した変化であるとの言及もありました。
コンテナ環境などでは、GitOps のアプローチとしてブランチやタグの活用が有効であるとの意見もありました。

ハイブリッドアプローチによるガバナンスとアジリティの両立

本セッションの主題であるハイブリッドアプローチとして、ガバナンスとチームの柔軟性を両立させる方法が議論されました。

一つの例として挙げられたのが、GitLab などの共通プラットフォーム上に共有のパイプラインコードを置き、それを各AWSアカウントの CodeBuild Runner (Managed Runner) で実行する方式です。

これにより、パイプラインの標準化を図りつつ、実行環境は各チームのアカウントで分離できるため、シークレット管理などを各アカウントの責任で安全に行うことができます。

また、最近注目されている AI Driven SecOps についても触れられました。GitLab Duo with Q を例に、AI がプルリクエストに基づいてテストケースを生成したり、パイプラインの失敗要因を調査したりする機能が紹介されました。

セッションの終わりには、CI/CD の方針決定フレームワークとして、以下の考慮事項が提示されました。

  • 戦略的目標 (Strategic goals)
  • 組織構造 (Org structure)
  • コンプライアンス (Compliance)
  • 成長軌道 (Growth trajectory)
  • リソース制約 (Resource constraints)

特に、買収などで新しい組織が加わり、分散型になりがちな企業からの対策の質問に対しては、Platform Engineering の必要性が挙げられました。また、再利用可能なパイプラインを用意してオンボーディング時に提供するなど、組織全体での効率化とガバナンス強化に向けたアプローチが示されました。

おわりに

マルチアカウント環境における CI/CD パイプラインの設計は、ガバナンスとアジリティのバランスを取る必要があります。
今回のセッションを通じて、ニーズに合わせてどのようにハイブリッドなアプローチを採用していくべきかのヒントを得ることができました。

私の所属するセキュリティチームのサービスでも CI/CD パイプラインによる自動化を進めていますが、再利用可能なパイプラインを用意するなど、効率的なアプローチを進めていきたいと思います。