AWSでマルチアカウント管理を考える（その１）

投稿日: 2022/06/24

はじめに

こんにちは、園田です。
AWS利用において、どんどんアカウントが増えてきて困っている、逆に増やした際の統制等が気になってなかなかアカウントを増やせない、などの悩みを抱えている管理者の方も多いのではないでしょうか。

AWSではマルチアカウントの管理としてOrganization、およびそれに付随する様々なサービスを用意して、マルチアカウントでのAWS管理、運用、統制を実施することが可能です。

とはいえ、あくまでサービス（機能）は機能でしかないため、自分たちの組織で利用するにあたってどのようなことを考慮する必要があるのだろう。ということに悩まれている管理者の方もおられると思います。

本ブログでは、AWSでマルチアカウント管理を行う際の設計を行う際に、どんなことを考慮する必要があるよ。というのを記載したいと思います。

上記に該当する管理者の方は是非確認ください。

AWSアカウントとは

そもそもの話になりますが、AWSアカウントとはどのようなものかをおさらいしましょう。

AWSアカウントとは

お客様が、AWSと契約を行った際、払い出されるものになります。
AWSアカウントは、複数保持することが出来ます。通常AWSアカウントを契約した場合、クレジットカードでの支払いとなります。請求書払いとすることもできるが、その場合1つの契約につき1つの請求書が送られます。
AWSを再販する業者（リセラーと呼びます。CTCもリセラーの1つになります。）からAWSアカウントを契約することにより、複数アカウントがあった場合も請求書をまとめるなど対応が一般的に可能です。
AWSアカウントにはAWSすべての機能が紐つく。アカウント間は通常利用の際は完全に独立しており、以下の管理をそれぞれ別々に実施する必要があります。

• 請求情報
• ユーザの権限（IAMにて）
• NW
• コンピュートリソース

上記で記載した通り、AWSアカウントは簡単に増やすことができますが、NWやコンピュートリソースリソース、ユーザ（IAM）情報がすべて別々で管理する必要があります。そのため、管理の視点からはなるべく作りたくない（できれば1つにまとめたい）。というのが本音ではないでしょうか。

とはいえ、以下の観点からやはりアカウントを1つで管理というのは現実的ではなく、実際には複数のアカウントを持つという形にならざるを得ません。

マルチアカウントの必要性

ではどのようなケースの際にAWSのアカウントを分割する必要があるのかを整理しましょう。
一般的にアカウントを分ける必要があるのは以下のケースです。

１． システムごとに権限の分離を実施したい

多分これが1番発生するケースとなります。
AWSでは権限の分離が難しいため、同一アカウント内で複数のベンダーがシステムを構築することが出来ません。
（各ベンダーに構築権限を付与すると、他のベンダーのシステムを触ることが可能となります。（他のシステムを削除可能。））

そのためセキュリティの観点から、システムや管理者毎にAWSアカウントを分割し、権限を独立させる必要があります。

２． システムごとに費用を分割したい

アカウントに費用が紐つくため、完全にシステム単位、部署単位に費用を分割したい場合、アカウントを分離する必要があります。

実際には、アカウントを統合した場合でも「タグ」と呼ばれる機能を利用することにより、どのリソースに、どの程度の費用が掛かったか集計することは可能です。ただし、NWなどの利用料はシステムごとに分割することができません。 実際には事前に1年、もしくは3年の利用をコミットするリザーブドインスタンス（以下、RI）の機能を利用したい場合、特定のシステムサーバに対し、RIを適用するということができないため、RI利用のため、アカウントを分割するケースが多いです。

Aシステムの担当者が費用を出した場合、Bシステムに適用されると損をしてしまうため、システム担当者への費用をチャージする場合、RIの購入は難しい （その場合は、システム単位でアカウントを分割する必要があり）

「１．システムごとに権限の分離を実施したい」、「２．システムごとに費用を分割したい」という要件からAWS環境を大規模に利用するにあたり、アカウント数が増える傾向にあります。
また、AWSとしては、本番、ステージング、開発などについては権限の観点からアカウントを分割したほうが良いとしているため、その定義に従う場合より一層たくさんのアカウントが必要となります。

マルチアカウントの課題と対策

特に複数アカウントを保持しても問題が無ければよいのですが、数が増えれば課題も出てきます。課題の代表例は以下のケースと考えています。

• １．アカウントが適切に管理できていない
  各部門が独自にAWSを契約しているため、そもそもどの程度のアカウントを管理しているのか管理できていない

• ２．ユーザ、およびユーザの権限が管理できていな
  アカウント毎にユーザ（IAMユーザ）、および権限が付与されているため、どのアカウントにどのようなユーザが存在し、どのような権限を持っているのか把握できていない。

• ３．セキュリティルールを管理できていない
  各アカウントの管理者が独自でAWSの設定を行っているため、システム構築にあたってのセキュリティルールが管理できていない（どのようなセキュリティ設定となっているかアカウント毎に差異がある。）

上記の課題に対応するため、AWSでは以下のような機能を提供しています。
これらの機能を適切に利用（頑張って設計）することで、利便性を保ちながら管理の強化が可能となります。

AWSアカウントの利用方針（分割）について

そもそもの話に戻りますが、AWSアカウントをどの単位で分割するのか、しないのかというのをきちんと定義しておく必要があります。
この定義は利用者によって異なるため、特にどのようにするのが正解。というものはありません。
自分たちの利用状況を鑑み、定義していく必要があります。

とはいえ、こんな感じの定義はできるよねというのはあるので、その辺について一般例として記載します。

■基本的な考え方

基本的には「システム」毎にアカウントを分割するのが望ましいです。
アカウントを分割すれば、システムごとにRIの購入も可能ですし、外部ベンダー等に依頼する際も権限でもめることはありません。
また、可能であれば、「本番」、「ステージング」、「開発」の環境でアカウントを分けることで、開発担当者が間違って本番を触ってしまう。というケースを回避できます。

とはいえ、この環境で分割については、システム重要度で定義する、開発ベンダーに任せる、「本番・ステージング」、「開発」の2環境にする。でも良いと思います。

■対応レイヤでアカウントを検討

基本的にはアカウントを分けると記載しましたが、小規模のシステムにおいてアカウントを分割するのは過剰ということで、作業レイヤで分割するという方針もあるかなと思います。

具体的にはAシステムについては「サーバとDBのみが必要」で特にAWSの操作を行わない。といった場合（従来のオンプレミスのようにインフラとアプリが明確に分離されている場合）においては管理者が、EC2とRDSを作成しSSHのキーをアプリ担当者に渡すだけで問題ありません。

この場合はRIを購入したいという要望が無ければ、わざわざアカウントを分割する必要はありません。今後、マルチアカウントの設計をするとはいえ、分ける必要が無ければ分けないのが一番手間がかかりません。

これらを踏まえると、アプリ担当者がAWS操作をする必要がない（設計、構築、運用上の操作）場合は、システム管理者が保有するアカウントにシステムを構築。ベンダーが設計、構築、運用を行う場合は、アカウントを分割するというケースが多いのではないかと思います。

ただ、この場合、システム管理者の方がどのようなサービスまで対応可能か（たとえば、EC2、ELB、RDS、ACMまで、など）などは定義しておく必要があるかと思います。この辺の定義がぶれるとアカウントの払い出しをする、しない、で揉める。システム導入後に想定と違ったということになってしまいます。

アカウント分離時の特徴と課題

繰り返しになりますが、アカウント分離時の特長と課題について再度触れておきます。

■アカウント分割時の特長

• １．システムごとに権限の分離が可能
  ユーザにどのような操作権限を付与するかについては、アカウント毎に設定が可能
  そのため、アカウントを分割した場合、各ベンダーに自由な（適切な）権限を付与することが可能　　（アカウント毎に、作成できる権限、ReadOnlyのみなどを設定可能）

• ２．システムごとに費用の分離が可能
  アカウントに費用が紐つくため、アカウントを分割することでシステムごとに完全に費用（請求）の分離が可能となる。
  アカウントを統合した場合でも「タグ」と呼ばれる機能を利用することにより、どのリソースに、どの程度の費用が掛かったか集計することは可能であるが、NWなどの利用料はシステムごとに分割することが出来ない。
  また、事前に1年、もしくは3年の利用をコミットするリザーブドインスタンス（以下、RI）の機能を利用した場合、タグを利用した費用の分割が出来なくなるため、RIを利用する予定がある場合はアカウントの分離を推奨。

■アカウント分割時の課題

• １．NWのリーチャビリティ
  アカウントを分けた場合、NWがアカウント毎に作成する必要がある。
  それぞれのNWは独立しているため、オンプレミスや他のクラウド、およびAWSアカウント間の通信をどのように確保するかを検討する必要がある。
  （AWSアカウントのVPC間の通信を行う場合、VPCピアリングを利用する場合、すべてのVPCとフルメッシュにてピアリングを行う必要あり。）
  →　NWの設計を定義する必要あり

• ２．ユーザ管理の工数増加
  アカウントを分けた場合、基本的にアカウント毎にユーザの作成が必要となる。
  アカウント増加に伴い、管理するユーザ数が増え、管理が煩雑になることが想定される。
  →　 IAMの設計を明確に定義する。また、AW SSOを利用し、運用の省略化を図る

AWS Organizationsを利用しての基本統制について

これまで記載した内容を踏まえて、ようやくOrganizationsの設計に入ります。
だいぶ長くなりましたが、設計に入る前に「抑えるべきところ」、また「自身の利用状況と課題」をきちんと定義しておくことが必要です。

というわけで、次回からOrganizationsの設計を行います。
ずいぶん長くなってしまったのでいったんここで切らせていただきます。

では、「AWSでマルチアカウント管理を考える（その２）」でお会いしましょう。

おわりに

CTCは、AWSのビジネス利活用に向けて、お客様のステージに合わせた幅広い構築・運用支援サービスを提供しています。
経験豊富なエンジニアが、ワンストップかつ柔軟にご支援します。
ぜひ、お気軽にお問い合わせください。