こんにちは、Platform Engineering部 SRE/インフラ マネージャーの布田です。
本記事では、M&Aを成長戦略の柱の一つとしているGENDAにおいて、AWS管理者である私たちのチームがM&A時に何をしているのかをお伝えします。元々は他社が管理していたAWS環境をグループに移管する際に、私たちが実際にやっていることを六つのフェーズに分けて紹介します。マルチアカウント統制に向き合っている方の参考になれば幸いです。
なお、M&Aで受け入れるシステム環境は都度異なり、AWS以外のクラウドやオンプレミス環境が対象となる場合もあります。今回は、そのなかでも多かったAWSの受け入れのケースをご紹介します。
すべてのAWS環境を同じガバナンスで運用できる状態にする
私たちが目指しているのは「グループ内のどのAWS環境も、同じガバナンス・同じセキュリティレベルで運用できる状態」にすることです。
新しくグループインした企業のAWSアカウントが何個であっても、AWS OrganizationsとAWS Control Towerの統制対象とし、既存の環境と同じように管理できるようにすることを目指します。
そこで、以下のようなフローで対応を進めていきます。
- 状況確認
- Payerアカウントの準備
- ガバナンスの土台構築
- 既存アカウント招待
- セキュリティ統制の適用
- 運用に乗せる
ここからは、それぞれのフェーズで何をしているかの詳細を説明します。
フェーズ1：引き継ぐ前に状況を確認する
最初にやることは現状の把握です。ここを飛ばすと後で手戻りが発生する可能性が高いです。
主に三つの確認事項があります。
| No | 項目 | 確認内容 |
|---|---|---|
| 1 | 請求・アカウント管理の担当者の確認 | 請求の担当者は誰か、クレジットカードを管理しているのは誰かを確認します。お金の流れは早めに押さえておきましょう。また、後続のフェーズで既存AWSアカウントへのログインが必要になるため、現在アカウントを管理している担当者が誰なのかも確認します。 |
| 2 | 利用リージョンの確認 | どのリージョンを利用しているかを確認します。これは後続のフェーズでAWS Control Towerの統制対象リージョンを決める際に必要な情報になります。 |
| 3 | 既存の統制が制約にならないかの確認 | リージョン制限などのSCP（サービスコントロールポリシー）をかけた際に、既存システムに影響がでないかを確認します。これは、AWS Control Towerで有効になっているコントロールがあればそれがブロッカーにならないかという点で確認を進めます。 |
地味な確認に見えますが、最初の段階でこれらを確認することで後続のフェーズをスムーズに進めることができます。
フェーズ2：Payerアカウントを準備する
ここでは「どのAWS Organizationsにも所属していないAWSアカウントを移管する」ケースを想定しています。
単一のAWSアカウントあるいは複数のAWSアカウントでシステムを動かしており、統制の土台をこれから用意する必要があるという状況を想定した流れを説明していきます。そして、同じグループであっても、AWSアカウントの利用料は、各社のクレジットカードで支払う構図です。
AWSのマルチアカウント管理をスタートするには、請求をまとめるPayerアカウントとなるアカウントが必要です。まずはPayerアカウントを自分たちの管理下、つまりAWSアカウントを受け取る側に作成することから始めます。
このアカウント作成は、クレジットカードの番号を含む支払い情報を入力する必要があるため、M&Aでグループインしてきたグループ企業側の担当者に対応を依頼します。企業によっては、これまで管理を担当されていた方が、日常的にAWSを触っていないケースもあります。そのため、入力すべきアカウント名の命名規則だけでなく、操作方法なども具体的に伝えながらアカウント作成を進めます。
アカウント作成が完了したら、認証情報を引き継ぎます。まず、認証情報は不特定多数の目に触れない経路で共有してもらう必要があります。さらに、初回ログイン時は多要素認証のワンタイムパスワードとなるコードをグループ企業側の担当者に確認してもらう必要があるので、コードを同期的に受け取れるよう、事前にコミュニケーションをとってから進めます。
ログインできたら、該当AWSアカウントのメールアドレスを今後管理主体となる部門のものに変更し、パスワードを再設定します。ここで、MFAデバイスの登録も行います。MFAデバイスは属人化を避けるために、1Passwordを使ってチームメンバーが共有管理できるようにしています。
GENDAでは、以下の請求まわりの初期設定も同時に行っています。
- 月次請求書メールにPDFを添付させる設定を有効化
- IAMユーザー/ロールから請求情報にアクセスできるよう「IAMアクセスのアクティブ化」を有効化
- 住所・連絡先名・請求連絡先メールアドレスが正しいかを確認（仮の値が入っていれば修正）
フェーズ3：ガバナンスの土台を作る
Payerアカウントが手元に来たら、統制の土台を組み立てます。
AWS Organizationsの作成
基本的にグループ企業単位でOrganizationを分離しています。もし、複数社を同一のOrganizationに含んでしまうと、グループ内での費用按分処理が発生してしまいます。そのような処理も考慮すると、企業単位でのOrganizationにする構成が管理の上でも都合がよくなります。
そのため、まずはグループインした企業のOrganizationを作成します。これによりその企業が保有しているAWSアカウント群を束ねることができます。
構成のイメージを下図に示します。M&A時はこの構成に対し、新たなOrganizationが加わります。
AWS IAM Identity Centerの有効化
AWSアカウントへのユーザーアクセスを一元管理するために、AWS IAM Identity Centerを有効化します。GENDAでは国内にサービスを提供することが多いため、基本的に東京リージョンでセットアップしています。なお、海外の環境であれば適宜読み替えて実施します。
AWS Control Towerの有効化
ホームリージョンには東京を選択し、ガバナンス対象とするリージョンには東京と米国東部（バージニア北部）を基本的に選択しています。フェーズ1で確認した利用リージョンがこれ以外にあれば、それも追加します。実際に、大阪リージョンや海外のリージョンを使っているケースもあります。
このとき、セキュリティ専用の監査（Audit）アカウントと、ログ集約用のログアーカイブアカウントを作成します。AWS Security Hubなどの集約は監査アカウント、AWS CloudTrailなどのログ集約はログアーカイブアカウントが担います。
OU（組織単位）の設計
OUに関しては事前にAWSアカウントの利用用途を加味して基本構成を考えておきます。そのOUの基本構成に沿って、実際に用途ごとのOUを作成します。Infrastructure（Prod/Stg）、Workloads（Prod/Stg）などです。
フェーズ4：既存アカウントを組織に招待する
グループ企業が持っていたAWSアカウントを、新しいOrganizationに招待します。その際は以下の流れで進めます。
- Payerアカウントから既存アカウントへ招待を送る
- 招待されたアカウント側で招待を承認する
- 承認後、Payerアカウントに戻り、用途に合ったOUにアカウントを配置する
3番目のOU配置がポイントです。OUに配置することで、そのOUに定義されたリージョン制限などのSCPが適用されます。配置して終わりではなく、AWS Control Towerのベースラインが有効になっていることまで確認します。
特に、SCPの適用のように、既存システムに影響が及ぶ可能性のある作業は、配置の前にグループ企業側と影響範囲を確認し、合意のうえで進めます。
フェーズ5：セキュリティ統制の適用
統制の仕上げとして、GENDAのSRE/インフラが独自に設計した「SecurityBaseline」を適用します。これは、脅威を検知して通知が届く状態を、すべてのグループ企業の環境で再現するための仕組みとして構築しました。
SecurityBaselineの仕組み
SecurityBaselineは、Amazon GuardDuty・Amazon Inspector・AWS Security Hub CSPMの3サービスを組織全体で有効化し、検知結果を集約・通知します。
マルチアカウント環境でSecurity Hubの運用！導入の苦労とポイント / JAWS DAYS 2026 p.12
検知は各リージョン・各アカウントで動きますが、結果は監査アカウントのAWS Security Hubに集約し、そこから通知が飛ぶようにします。
Terraformのモジュール化による再現性の担保
ここまでの設定は手作業で終わらせず、Terraformでコード管理しています。
SecurityBaselineはグループ企業が増えるたびに同じものを適用するため、下図のようにモジュールを再利用して同じ統制を適用しています。
マルチアカウント環境でSecurity Hubの運用！導入の苦労とポイント / JAWS DAYS 2026 p.15
また、SecurityBaselineの適用と同時に、以下の整備も実施します。
- 許可セットの作成：AdministratorAccess・PowerUserAccess・ReadOnlyAccess以外にも、SRE/インフラで用意している許可セットが複数あるためデプロイする
- AWS Configの記録頻度変更：AWS Control Tower配下のAWS Configはコストを考慮し記録頻度を見直しているため、他Organizationと同様に設定する
フェーズ6：運用に乗せる
フェーズ5までで技術的な統制が整ったので、最後に継続して運用できる状態に落とし込みます。
主な実施内容は以下のとおりです。
- 申請ワークフローへの追加：権限申請・アカウント申請のSlackワークフローや、権限付与の自動承認の仕組みに、新しいグループ企業を追加する
- ドキュメントの更新：AWS利用ガイドライン、アカウント申請フロー、IAMユーザー申請フローなどの利用者向けの手順書に新しいグループ企業を追記する
- アカウント台帳への追記：アカウントの所有企業や用途を追記する
- 利用者の招待：開発担当のエンジニアなど、必要な利用者に対しアクセス権を付与する
- 連絡ルートの確立：AWS環境の通知・契約・請求などでグループ企業側の担当者と確実に連絡が取れるよう、専用のコミュニケーションチャネルを用意する（将来的な担当者変更に備え、窓口を明確にしておく）
このフェーズを丁寧にやっておくと、引き継ぎ後の対応がスムーズになります。
スムーズな移管のために重要なこと
実際に何度かの移管作業を体験し、スムーズな移管のために大切だと感じたポイントを紹介します。
- 事前確認を怠らない：誰が費用支払いを実施しているのか、どのリージョンを使っているのか、管理しているのは誰なのか。最初の現状把握がプロジェクト全体の見通しを良くするための重要ポイントです。
- グループ企業との連絡ルートを確保する：グループインした企業の方々と会話できる場を用意しておくことは重要です。先方からの問い合わせだけではなく、こちらからのお願いごとも継続して発生するため「ここでコミュニケーションをとる」と決めておくと認知負荷が軽減できます。Slackでチャンネルを一つ作るだけですが、それだけでも非常に効果があります。
- 相手に伝わる言葉を使う：移管には立場や専門領域の異なる方々が関わるため、「何を決めてほしいか」を分かりやすく伝えることが重要です。そうすることで認識のズレが減り、判断もしやすくなって、全体の作業がスムーズに進みます。
- 移管がゴールではない：移管が終わったあとも、環境構築のレビューや運用上の問い合わせ対応やサポートはしばらく続きます。自走できる姿がゴールだという認識を揃えつつも、そのためのサポートを継続することをお伝えしておきます。
「M&A」という言葉だけを聞くと、経営の話のように聞こえるかもしれません。しかし、実際にはその裏側ではSRE/インフラを始めとした多くの関係者が動いています。そのなかで、SRE/インフラはすべての環境をグループ標準に揃える役割を担っています。新しいグループ企業も、そして受け入れる側も、双方が安心して同じ統制の上で動けることは重要です。だからこそ、環境をグループ標準に揃えることは、信頼性を支えるSREの大切な仕事の一つだと感じています。
おわりに
M&Aに伴って増加するAWS環境を統制下に置くまでの流れを、フェーズに分けて紹介しました。
一つひとつは地味な作業にも見えますが、「どの環境も同じ目線で運用できる」状態を積み上げていくことが、グループ全体の信頼性とガバナンスにつながっていきます。本記事が同様にマルチアカウント統制の仕組みづくりに取り組む方の手がかりになれば幸いです。
Discussion