AWS を複数のアカウントで利用する場合、AWS Organizations や AWS CloudFormation 等のサービスを使用して、アカウントの一元管理と運用自動化、課金管理の簡素化を行うのが昨今のトレンドかもしれません。

しかし、当社では諸般の事情で AWS Organizations と AWS CloudFormation の一部機能を使用できず、この制約のもとでマルチアカウント管理環境を整えました。設定や実装アプローチを2回に分けて紹介します。この記事では、「当社がマルチアカウントでの運用に至った経緯」と「ログイン管理」にフォーカスします。

マルチアカウントでの運用に至った経緯

当社のマルチアカウント管理環境について紹介する前に、当社が AWS をマルチアカウントで運用するに至った経緯を説明します。

1つのアカウントに複数のプロジェクト

AWS の利用開始当初は、複数のプロジェクトを1つの AWS アカウントで管理していました。このアカウントは、統合認証基盤を利用して Active Directory (AD) と AWS の連携を行っているため、AD のユーザーで AWS を利用できます。そのため、「誰が AWS を利用しているのか」を把握しやすい管理体制となっています。AD のユーザーでログインするため、利用者ごとに IAM ユーザーを用意してパスワードを管理する必要がありません。

この形式で AWS を利用する方法については、当ブログの記事である AWS/Azure/GCPサービス比較 シングルサインオン編もご参照ください。

プロジェクトごとの管理は、以下の運用でした。

• 各プロジェクトの利用者に対し、異なるプロジェクトのリソースを操作できないように権限を制御
• 利用者に与えられた権限でできない操作は、管理部門が代行するか権限を新たに割り当てることで対応

この方法でしばらく運用していたのですが、以下のような課題が見えてきました。

• プロジェクトの数や、プロジェクトで使用するサービスが増えるごとに権限の制御が複雑化
• プロジェクトごとのコスト管理が困難

1つのプロジェクトに1つのアカウント

上記の課題を解決するために、「プロジェクトに対して1つの AWS アカウント（プロジェクトアカウント）を払い出す運用」に方針転換しました。これには、以下の利点があります。

• 利用者 : 他のプロジェクトを意識することなく、自由に AWS を利用可能
• 権限制御 : 利用者が自由に設定しても他のプロジェクトには影響がないため、管理側による制御は不要
• コスト管理 : アカウント単位の利用料金がそのままプロジェクトごとのコストとなる

マルチアカウント運用開始時の課題

このような経緯で開始したマルチアカウントでの運用ですが、マルチアカウントならではの課題も見えてきました。

AD のユーザーで AWS を利用できない

当社の運用している統合認証基盤と AWS の仕様上、複数の AWS アカウントと統合認証基盤を連携させることができないため、プロジェクトアカウントでは AD のユーザーで AWS を利用できません。そのため、各アカウントで利用者ごとに IAM ユーザーを作成して、それぞれがパスワードを管理する必要があります。また、「誰が AWS を利用しているのか」の確認も困難でした。

利用者の操作が見えない

権限制御を行っていないため、各プロジェクトアカウントの運用が組織のポリシーに反していないかなどを確認する必要があります。しかし、各アカウントでどのような操作をしているかは、そのアカウントにログインしないと確認できず、調査工数がかかります。

設定の適用が困難

共通ルール・ポリシーを全アカウントに設定したい場合、すべての AWS アカウントにログインして設定する必要があります。この先、アカウントが増えていくことを考えると、各アカウントにログインして設定するのは現実的ではありません。リージョンごとに設定をしなければならない場合は、なおさらです。

ログイン管理

「誰が AWS を利用しているのか」を管理するために、ログイン方法を整備しました。マルチアカウントの運用でも、AD のユーザーですべての AWS アカウントを利用できれば、ログインの管理はシンプルです。しかし、前述の通り、当社の運用している統合認証基盤は1つの AWS アカウントとしか連携できません。

そのため、認証基盤と連携してログインを管理するための AWS アカウント「Jump アカウント」を作成し、すべての利用者はこのアカウントを経由して、プロジェクトのアカウントを利用してもらうことにしました。AD のユーザーと AWS の IAM ロールを紐付けることで権限を割り当てるため、AD のユーザーはログインの際に IAM ロールを選択し、その権限で AWS を利用します。Jump アカウント内で可能な操作は「スイッチロール（ロールの切り替え）」のみとしています。

スイッチロール（ロールの切り替え）

スイッチロールとは、AWS のユーザーの権限を IAM ロールの権限に切り替えることができる機能です。別のアカウントのロールを指定することで、そのアカウント内で操作が行えます。

ログインした後、Jump アカウントの IAM ロール A から、プロジェクトアカウントの IAM ロール B にスイッチロールするには、それぞれのロールに以下の権限が必要になります。

Jump アカウント側の権限

ロール A では、ロール B へのスイッチロールができるような権限を付与するために、ロールのアクセス権限に以下のポリシーを追加する必要があります。

1
{
2
  "Effect": "Allow",
3
  "Action": "sts:AssumeRole",
4
  "Resource": "｛ロール B の ARN｝"
5
}

プロジェクトアカウント側の権限

ロール B では、ロール A からのスイッチロールを許可するために、ロールの信頼関係に以下のポリシーを追加する必要があります。

1
{
2
  "Effect": "Allow",
3
  "Action": "sts:AssumeRole",
4
  "Principal": {
5
    "AWS": [
6
      "｛ロール A の ARN｝"
7
    ]
8
  }
9
}

このように設定することで、Jump アカウントでログインの管理を行いつつ、利用者は AD のユーザーでプロジェクトアカウントを利用できます。各アカウントでのロールの作成は、AWS CloudFormation や AWS Systems Manager オートメーションなど、ユーザーの代わりにリソースを作成できるサービスを利用することで簡易化できます。

今回のまとめ

今回は、当社が AWS をマルチアカウントで運用するに至った経緯と、ログイン管理について紹介しました。これで、マルチアカウントでの運用開始時の「AD のユーザーで AWS を利用できない」という課題を解決できました。他の2つの課題については、次回の「セキュリティ編」で紹介します。

参考文献

• ロールを切り替えるユーザーアクセス許可の付与 ⧉