マルチAWSアカウント運用の始め方 2020
AWSを企業環境で利用する場合、AWSアカウントを複数使って運用していくことになります。ここではAWSアカウントを複数利用する場合における考え方をご紹介します。
なおこのストーリーは、JAWS-UG初心者支部 #22 Fin-JAWSコラボ&ミニハンズオンのセッションにて紹介したものをベースにしています。
マルチアカウント運用とは
AWSアカウントのマルチアカウント運用とは、1つの組織(会社)でAWSアカウントを複数使うことをここでは指しています。よく耳にするアカウント運用では、部署単位、経費の精算単位、開発環境とサービス提供環境で、AWSアカウントを分ける、といったようなケースがあります。
このように、一定規模の組織でAWS環境を使っていく場合、AWSアカウントを複数作成して使い分けていくことになります。
その際、このAWSアカウントをどのように分割し、管理していくかの方針を決めていく必要があります。このAWSアカウントを分割するポリシーを決めておかないと、管理すべきAWSアカウントが散逸して、会社内でどのようなAWS環境があるのか全体がわからなくなる、というようなことが起こりえます。
AWS Organizations
マルチアカウント運用のために、AWSはOrganizationsというサービスを提供しています。このAWS Organizationsは、組織が持つAWSアカウントをまとめ、OU(組織単位)という仕組みでAWSアカウントを階層的に整理し、管理可能にする仕組みを持っています。
また、同じ組織が保有するAWSアカウントの利用料請求を1つにまとめ、一括請求・支払いが可能になります。
AWS Organizationsは、ルートAWSアカウントという組織のAWSアカウントを取りまとめるAWSアカウントを1つ定め、そのルートAWSアカウントの子アカウントとして、多数のAWSアカウントを管理できるようにしています。利用料請求はルートAWSアカウントに集約されるため、組織全体での利用料の把握や支払いが簡単に行えるようになります。
なお組織全体での請求書のほか、アカウントごとの明細も確認できるため、必要に応じて費用を適切に仕分けすることも可能です。
またOU(組織単位)を利用すれば、多数のAWSアカウントを階層構造に整理し、管理することができます。
マルチアカウントの始め方
AWS Organizationsを使ったマルチAWSアカウント運用のはじめかたとして、以下のようなステップで進めていくのが、よいと考えています。
- ルートになるAWSアカウントを決める
- AWS Organizationを有効化する
- 既存のAWSアカウントを子アカウントに招待
- OUでAWSアカウントを整理
- 新しいAWSアカウント追加時はルートで行う
ここからは、順を追ってマルチAWSアカウント運用を始めるためのステップをご紹介します。
ルートになるAWSアカウントを決める
ルールになるAWSアカウントは強い権限を持ちます。組織全体の課金管理ができるほか、子アカウントへのスイッチロール権限も同時に得ます。これは OrganizationAccountAccessRole というIAMロールが自動的に組織内のAWSアカウントに作成され、ルートAWSアカウントから子アカウントに AdministratorAccess ポリシーを持った管理者としてスイッチロールできるようになります。
組織全体のAWSアカウントに強い権限を持ちますので、ルートAWSアカウントは通常利用しない前提となります。そのため、マルチアカウント運用を始める際には、新しいAWSアカウントを作成し、このアカウントをルートAWSアカウントとして利用することがおすすめされます。
このルートAWSアカウントは、最小限の管理者IAMユーザーのみで運用することが推奨されます。
AWS Organizationsを有効化する
さきほど作成したAWSアカウントをルートとして、AWS Organizationsを有効化します。ルートにするAWSアカウントにサインインし、AWS Organizationsの組織を作成して、Organizationsを有効化します。
既存アカウントの招待
すでに利用しているAWSアカウントを、作成したAWS Organizationsの子アカウントにするため、組織に招待を行います。
ルートAWSアカウントのOrganizationsの管理画面から、アカウントの招待を行います。ルートAWSアカウントからアカウントの招待を行い、招待されたAWSアカウントでそれを承諾すると、Organizationsの子アカウントになります。子アカウントになると、そのAWSアカウントの請求も、ルートAWSアカウントの一括請求になります。
OU(組織単位)によるアカウントの整理
AWS Organizationsでは子アカウントを一覧で確認できるだけではなく、OU(組織単位)という仕組みで、アカウントを階層構造にして管理しやすく整理することができます。
AWS Organizationsの管理画面から、OUの作成やアカウントが所属するOUを変更することができます。
また最近はAWS Organizationsと各サービスの連携が進み、組織やOU単位でポリシーの適用など、複数のAWSアカウントを一括して指定してコントロールできる機能も実装されてきています。
新しいAWSアカウントの作成
AWS Organizationsを有効化した後、新しいAWSアカウントを作成したい場合には、AWS Organizationsの管理画面からAWSアカウントを作成できます。
AWS OrganizationsからAWSアカウントを作成すると、自動的に組織の子アカウントとして登録済みの状態で、AWSアカウントが作成されます。
AWS OrganizationsのAPIやAWS CLI等を使うと、新しいAWSアカウントの作成などを自動化することも可能です。
なお、AWS Organizationsの機能を使って新しいAWSアカウントを作成する場合、ルートユーザーのパスワードを作成時に指定することはできません。初回サインイン時にパスワードリカバリー機能を使って、パスワードをリセットしたうえで、新しいAWSアカウントにサインインします。
(OrganizationsAccountAccessRoleを使うと、ルートユーザーでサインインしなくとも利用し始めることは可能です)
マルチAWSアカウントの分けかた
AWS Organizationsで複数のAWSアカウントを利用していく場合に、どのようにAWSアカウントを分割していくについては、正解はありません。
しかしながら、AWS環境をよりよく管理していくために必要な要素をベースに、現時点でよい始めかたと考えられる方法をご紹介します。
1つのAWSアカウントを共有するデメリット
マルチAWSアカウントの運用をする理由にもなりますが、1つのAWSアカウントを共有して利用するデメリットを考えてみます。
1つのAWSアカウントを利用する場合の最大のデメリットは、権限の制限が難しくなることです。
オンプレミスの世界では、サーバールームに入ってなにか間違いを起こしてしまい、例えばサーバーの電源ケーブルを抜いてしまったり、HDDを引き抜いてしまっても、電源を入れなおせば復旧できるかもしれません。
しかしパブリッククラウドの世界では、間違ってリソース(インスタンスなど)を削除してしまったら、もう復活させることはできません。
そのためオンプレミスの世界と同じ考えで、サーバールームにはIT部門の全員が入れるので、AWSの環境も全員が管理者でいい、というやりかたは危険です。
AWSの世界では、AWSの世界で必要な権限の分けかたをしていく必要があります。
AWSの世界で使いやすいアカウントの分けかた
AWSアカウントを分割するにあたっては、AWSの世界で使いやすいことを念頭にして考える必要があります。
ここで会社の組織構造によって、AWSアカウントを分けることはお勧めできません。会社の組織構造は頻繁に変わります。しかしながら、会社の組織と、AWSの管理方法・単位は一致しません。
AWSの管理がやりやすい単位でAWSアカウントを分けながら、会社の組織に基づいた権限の付与は、AWSアカウントの分割ではなく、IAMを使って制御することをお勧めします。
マルチAWSアカウント First Step
AWS Organizationsを利用して組織でマルチAWSアカウントを始める、おすすめの始めかたをご紹介します。
AWSアカウントを分割する際の最初の考えかたとして、1つのAWSアカウントは1つの用途にする、を基本コンセプトにします。
1つのAWSアカウントのリソースを、あとから複数のAWSアカウントに分割するのは大変な苦労がかかりますが、複数のAWSアカウントに分割されたリソースを、まとめて管理することは比較的容易です。
まずはAWSアカウントごとに1つの用途を決めて、違う用途には別のAWSアカウントを用意して利用していくことが、あとで困らないマルチAWSアカウントの始めかたであると考えています。
マルチAWSアカウントの最小セット
1つの用途で1つのAWSアカウントで利用してく場合、AWS Organizationsを有効活用して複数のAWSアカウントを管理していく際の最小セットと考えられる分けかたは、以下のようになります。
- ルートAWSアカウント
Organizations 管理専用 (+ルート必須のサービス利用) - IAMユーザー認証アカウント
会社内のユーザーのIAMをまとめて作成する
他のアカウントは、このアカウントにサインイン後、ロール切り替えをして使う - セキュリティ通知用アカウント
GuardDutyやAWS Configの通知を集約
ルートAWSアカウント以外に集約できるものはここに集約 - 検証環境
普段使う開発環境用のAWSアカウント - 運用環境
サービス提供のためのAWSアカウント
規模によりシステムごとに複数、または1つのアカウントに複数システム混在もありうる
ルートAWSアカウント
ルートAWSアカウントは、組織全体の管理のために利用します。
課金管理は、ルートAWSアカウントにIAMユーザーを用意するのでは区、課金管理用IAMロールを作成して、IAMユーザー認証AWSアカウントからスイッチロールできるようにします。
AWS Organizationsでは組織のCloudTrailという機能が利用可能になり、Organizationsにある全AWSアカウントに一括設定可能になります。組織CloudTrailを有効化し、セキュリティアカウントに作ったS3バケットにログを保存します。
また子アカウントにOrganizationAccountAccessRoleというロールができ、ルートAWSアカウントからスイッチロールできるようになります。ルートAWSアカウントのユーザーはすべての子アカウントで管理者権限を持つようになるため、ルートAWSアカウントを利用するユーザーを限定して、不用意に子アカウントの管理者権限を渡さないよう管理します。
IAM認証アカウント
組織で使うIAMユーザーを作成します。ここに登録されているユーザーが、組織内でAWSを使っているユーザーと一致することになります。
IAM認証アカウントにIAMユーザーを集約することで、入退社に合わせたアカウント管理などが楽になります。グループを使って各ユーザーが利用できるIAMロール/AWSアカウントを制御することで、権限の管理をグループをベースに制御できるようになります。
またもっと高度なアカウント管理方法として、AWS SSOやSAML連携を組み合わせる方法もありますが、最初の始めかたとしてIAM認証AWSアカウントを準備しておくことは重要と考えています。
セキュリティアカウント
セキュリティ系通知を集約するアカウントとして、GuardDutyのマスターアカウントにする、組織のCloudTrailログをS3に保存する、AWS Configやその他の管理系通知を集約します。
これらを1つのアカウントに集約することによって、AWS運用管理者が組織全体の通知を一括して管理・確認することができるようになります。
検証・運用環境
検証環境用AWSアカウントとして、AWSのサービスを試したり開発する環境を用意し、AWSサービスを迅速に検証できるようにするとともに、運用環境の監視や権限から分離し、サービス影響を最小化するようにします。
開発者ごとにAWSアカウントを用意するケースと、共用のアカウントを用意するケースどちらもありえます。検証環境を共用アカウントとすると、AWSサポートを共有できるメリットがあります。
運用環境AWSアカウントは、そのサービス運用に携わるユーザーだけが使えるようにします。サービスごとにAWSアカウントを分けると、特定の運用メンテナンス作業による影響を、アカウント内に限定できます。
またAWS利用方法が発展していくと、1つのシステムを複数のAWSアカウントで構成するようなこともでてきます。
最後に
組織で複数のAWSアカウントを利用していくための考えかたをご紹介しました。
マルチAWSアカウントは、それぞれの組織によってベストな使い方は変わってきます。しかしながら、1つ1つのAWSアカウントをシンプルに使うという点については、不変のベストプラクティスだと考えています。
AWSアカウントを作るだけなら無料です。AWSアカウントの作成をためらう必要はありません。利用料金も一括請求になりますが、明細をアカウント単位で管理ことは可能です。
このストーリーが、より柔軟かつよりよくAWSを活用していくための助けになればと思います。
AWS Organizations ドキュメント
https://aws.amazon.com/jp/organizations/
