AWSマルチアカウント戦略でシンプル＆セキュアな運用へ

はじめに

弊社では長らく、社内サービスを 単一の AWS アカウント に集約して運用してきました。サービス数自体は多くないものの、運用メンバーが増えるにつれて権限の境界が曖昧 となり、「誰がどこまで操作できるのか」を把握しづらい状況に陥っていました。

この課題を解決するため、AWS Organizations を活用した マルチアカウント戦略 を導入し、環境・責務ごとにアカウントを分離する取り組みを開始。本記事では、その背景と具体的なアプローチ、そして得られたメリットを紹介します。

現状の課題

管理アカウント に ALB と 5 台の EC2 が混在

管理アカウントに IAM ユーザーが集中しており、各メンバーに必要以上の権限が与えられている状況が多く、最小権限の原則を実践しにくい
単一アカウントではコストの内訳が分かりにくい
- コスト配分タグを使ってある程度の集計は行っていましたが、集計や可視化の観点ではやや見づらく、タグ運用も属人化しやすい課題がありました。

マルチアカウント構成とは

AWS Organizations を用いて 環境（開発・本番）や目的（ネットワーク・共有サービス）ごとにアカウントを分割 し、ガバナンスを効かせつつスケーラブルに拡張していく方法です。アカウントはそれぞれがセキュリティ境界となり、権限・課金・ログなどを独立して管理できます。

期待するメリット

1. 環境ごとの権限分離

アカウント単位で IAM ロールを限定できるため、操作ミスなどにより特定のサービスが停止するリスクを軽減できます。サービスごとにアカウントを分けることで、影響範囲を明確に分離し、安定した運用が可能になります。

2. コストの可視化と予算管理

コスト配分タグでもある程度の可視化は可能でしたが、マルチアカウント構成によりアカウントごとの使用量が分けて見られるようになり、より直感的かつ明確にサービスごとのコストを把握できるようになります。請求自体は管理アカウントに集約されるものの、各アカウントの使用状況が明確になることで、予算アラートの設定や異常検知にも役立ちます。

対応: ネットワークアカウントとサービスアカウントを分離

ルーティングを担うALB をネットワークアカウントに配置し、そこから別アカウントに移行した EC2 インスタンスへトラフィックを転送する構成とします。
本記事では、実際にHPインスタンスを別アカウントに移行したのでその手順を記載します。

大まかな移行ステップ

新規AWSアカウント作成、作成したAWSアカウントでVPC作成(この記事では割愛)
ネットワーク接続
- 管理アカウントの VPC ↔ 移行先 VPC を VPC ピアリングで接続。
- RAMを使用してセキュリティグループを共有し、ALB からのトラフィックを許可。
AMIを使用し、EC2を移行
- AMI化し、構成を変更せずそのまま移行する想定
- 共有機能で別アカウントで使用できるようにする
- ※ 本構成のEC2は、MySQL をインスタンス内に直接構築しているため、AMI により構成をそのまま保持した移行が可能でした。
ルーティング調整
1. 新EC2へ接続するターゲットグループを作成。
  1. 別アカウントのEC2は参照できないため、IPアドレスでターゲットグループを設置する
2. ALBのターゲットグループを差し替える。