こんにちは。AWS CLIが好きな福島です。
- はじめに
- 共通インフラアカウントを作る目的
- 共通インフラアカウント一覧
- ①マネジメントアカウント(必須)
- ②監査アカウント(ほぼ必須)
- ③ログアーカイブアカウント(ほぼ必須)
- ④IAMアカウント(ほぼ必須)
- ⑤ネットワークアカウント(ほぼ必須)
- ⑥踏み台アカウント(環境による)
- ⑦コスト最適化アカウント(環境による)
- ⑧監視アカウント(環境による)
- ⑨可視化アカウント(環境による)
- ⑩自動化アカウント(環境による)
- ⑪ADアカウント(環境による)
- 終わりに
はじめに
昨今、AWSを利用するにあたり、複数のAWSアカウントを利用したマルチアカウント構成が主流になってきているかと存じます。
また、マルチアカウント構成では、監査アカウントやログアーカイブアカウントといった共通インフラとなるアカウントを作ることが一般的かと存じます。 (このようなアカウントのことを本ブログでは、共通インフラアカウントと呼称いたします。
そこで今回は、どういった共通インフラアカウントを用意するケースがあるのか、私の妄想も込みでご紹介いたいます。
念のため、本ブログに記載しているアカウントは必ず作る必要はないかつ、この通り分割する必要もないため、環境に合わせて適切な共通インフラアカウントを作成いただければと存じます。 その検討の際に本ブログがお役に立てば幸いです。
共通インフラアカウントを作る目的
共通インフラアカウントを作るのは、マルチアカウント構成を組むメリットとほぼ同様ですが、大きく以下の2つの目的があるかと存じます。
- 1.容易な権限分離
1つのAWSアカウントに様々なリソースを作成した場合、IAMポリシーで権限を制限することを考えると、 設定が煩雑化したり、そもそも制限が上手くできないケースもあるかと存じます。 そのため、AWSアカウントを分離することで容易な権限分離を実現します。 - 2.リソースの一元管理
複数のアカウントで共通して作成または利用するリソースがあるかと存じますが、 これらのリソースを個々のアカウントに作成しては運用や管理が煩雑化してしまいます。 そのため、専用のAWSアカウントを作成し、リソースの一元管理を行います。
共通インフラアカウント一覧
- ①マネジメントアカウント(必須)
- ②監査アカウント(ほぼ必須)
- ③ログアーカイブアカウント(ほぼ必須)
- ④IAM(踏み台)アカウント(ほぼ必須)
- ⑤ネットワークアカウント(ほぼ必須)
- ⑥踏み台アカウント(環境による)
- ⑦コスト最適化アカウント(環境による)
- ⑧監視アカウント(環境による)
- ⑨可視化アカウント(環境による)
- ⑩自動化アカウント(環境による)
- ⑪ADアカウント(環境による)
※上記には、AWSのドキュメントでは見かけないアカウントもあるため、その点はお含みおきください。
①マネジメントアカウント(必須)
マネジメントアカウントとは？
マネジメントアカウントは、複数アカウントの管理や請求の一元管理ができるアカウントとなり、最も重要なアカウントになります。
共通インフラアカウントとして考えた場合、①-⑪は同じ括りにしているのですが、AWSの概念としても存在する親子関係という括りで分けた場合、 ①が親(マネジメント)アカウントとなり、②-⑪は子(メンバー)アカウントと呼称されます。
親アカウントと呼ばれていることからも分かる通り、マネジメントアカウントは他のアカウントとは別格の存在で呼び方だけではなく、マネジメントアカウントだけが利用できる機能も複数あります。
そうなると、様々な担当者がマネジメントアカウントにログインする必要が出てきそうですが、冒頭にも記載した通り、マネジメントアカウントは最も重要なアカウントのため、ログインできるメンバーは絞るべきと考えております。
そういった要望を叶えるためか、マネジメントアカウントには、委任という機能があり、本来はマネジメントアカウントしか利用できない機能を子(メンバー)アカウントに委任することができます。
マネジメントアカウントだけが利用できる機能や委任についての説明は割愛するのですが、詳細が気になる方は、以下をご確認ください。
最後に余談ですが、AWS Control Towerというサービス上では、マネジメントアカウントは共有アカウントまたはコアアカウントと呼ばれます。 (②監査アカウント、③ログアーカイブアカウントも共有アカウントまたはコアアカウントと呼ばれます。)
マネジメントアカウントに持たせる役割例
基本的には、委任できるものは別のメンバーアカウントに委任し、委任できない機能だけをマネジメントアカウントの役割にするのが良いかと存じます。
とはいえ、委任先として適切なメンバーアカウントがない場合や、そのためだけにアカウントを作るのも悩ましいケースもあるかと存じますため、 そういった機能は、マネジメントアカウントに持たせても良いと存じます。
マネジメントアカウントに持たせる役割例としては、以下が考えられます。
- AWS Organizations の一括請求機能
- OU管理
- SCP管理
上2つは委任ができないため、マネジメントアカウントで管理せざるを得ないです。
3つ目は委任ができるのですが、個人的にOUとSCP管理はセットで運用した方が良いと考えているため、マネジメントアカウントに持たせてもいいのかなと思っております。
②監査アカウント(ほぼ必須)
監査アカウントは、マネジメントアカウントが利用できるセキュリティ系の機能を委任するアカウントとして利用することが多いかと存じます。 委任する役割例は、以下が考えられます。
- AWS Config
- AWS CloudTrail
- Amazon GuardDuty
- AWS Security Hub
- IAM Access Analyzer
- Amazon Inspector
- Amazon Detective
- Amazon Macie
- Amazon S3 Storage Lens
上記全てを使うケースは少ないかもしれませんが、上から5つよく利用するサービスかなと存じます。
また、余談でAWSドキュメントに記載されている用語ではないと思われますが、監査アカウントのことをセキュリティアカウントと呼称したりします。
③ログアーカイブアカウント(ほぼ必須)
ログアーカイブアカウントは、特にマネジメントアカウントから委任を受ける機能はなく、各AWSサービスのログを集約するアカウントとして利用することになるかと存じます。 また、作成するリソースは、S3だけになることが多く、よく集約するログは、以下が考えられます。
- AWS Config
- AWS CloudTrail
上記は、AWSの設定や操作履歴という重要なログとなり、改ざんの防止であったり、 AWSアカウント横串しでログの分析ができるようにしておくことを目的に、個々のアカウントでログを管理するのではなく、 ログアーカイブアカウントで管理することが多いかと存じます。
もちろん、上記以外にも、Amazon GuardDuty,VPC/TGW,ELBなどのログも集約することが考えられますが、 何を目的として集約するかを考えた上で集約することが大切かと存じます。(SIEMの実装など)
ログ出力先を複数設定できるAWSサービスであれば、ログアーカイブアカウントにログを集約しつつ、 トラブルシューティングのために、個々のアカウントにログを出力することも考えられます。
また、その逆にログの出力先を1つしか設定できないAWSサービスもありますが、 そういったログは、セキュリティと利便性をしっかり考え、集約する/しない、を決定することが大切です。
もしセキュリティも利便性も必要な場合は、個々のアカウントにログを出力しつつ、何かしらの手段でログアーカイブアカウントにログをレプリケーションする構成も考えられます。
④IAMアカウント(ほぼ必須)
IAMアカウントは、組織のAWSアカウントにログインするアクセス権を管理するためのアカウントとなります。 具体的には、IAM Userの集約先であったり、マネジメントアカウントからIAM Identity Centerの委任を受けるアカウントになるかと存じます。
詳細は以下をご確認ください。
⑤ネットワークアカウント(ほぼ必須)
ネットワークアカウントは、名前の通り、ネットワーク系のリソースを管理するアカウントになります。 具体的には以下のリソースが考えられます。
- Direct Connect
- Direct Connect Gateway
- Transit Gateway
- Route 53 Public/Private HostZone
- AWS Firewall Manager
- AWS Network Manager
- Network Firewall + Nat Gateway(インターネットの出口を集約する場合)
- Route 53 Inboud/Outboud Endpoint(オンプレミスにあるDNSサーバとRoute 53 Resolver同士を連携する場合)
補足ですが、Transit Gatewayは、個別のアカウントでも必要なリソースとなるため、RAMを利用し共有する運用が一般的かと存じます。 また、Route 53 Public HostZoneについて、レコードを一元管理するのも良いかと存じますが、サブドメインを個々のアカウントのRoute 53に委任する運用も良いかと存じます。
⑥踏み台アカウント(環境による)
IAMアカウントのことを踏み台アカウントと呼称するケースがありますが、 本ブログでご紹介する踏み台アカウントはIAMアカウントとは別となります。
ここで紹介したい踏み台アカウントとは、踏み台サーバを集約する用のアカウントになります。
踏み台サーバは、個々のアカウントのVPCに作成するケースが多いかと存じますが、これらのサーバの集約によりコスト削減に繋げたり、 一元管理によるセキュリティ強化に繋げることが可能かと存じます。(サーバを集約するにあたっては、合わせて、ネットワークの構成もしっかり考える必要があるかと存じます。)
⑦コスト最適化アカウント(環境による)
コスト最適化アカウントとは、名前の通り、組織全体のAWSのコストを最適化するためのアカウントになります。 例えば、SPの購入を行ったり、マネジメントアカウントからAWS Compute Optimizerの委任を受けたりするアカウントとして利用できると存じます。
マルチアカウント統制下のSP購入戦略についての詳細は、以下をご確認いただければと存じます。
⑧監視アカウント(環境による)
監視アカウントとは、自社で運用している監視サーバの配置や全てのAWSアカウントのCloudWatchのデータを集約するアカウントになります。
⑨可視化アカウント(環境による)
可視化アカウントとは、リソース情報を可視化ためのリソースを構築する用のアカウントになります。 詳細は以下をご確認ください。
⑩自動化アカウント(環境による)
マルチアカウント構成になると新規のアカウント払い出し時に実施している処理を自動化したいケースがあるかと存じます。 自動化アカウントとは、そういった自動化関連のリソースの配置やCloudFormation StackSetsの委任を受けるアカウントになります。
⑪ADアカウント(環境による)
Active DirectoryをAWSで実装する(on EC2やMSAD)場合、専用のAWSアカウントを作成するのも良いかと存じます。
終わりに
今回は、マルチアカウント構成における共通インフラアカウントについて、私の妄想込みでご紹介いたしました。
主要なアカウントは分割をすることが大切かと存じますが、細かく共通インフラアカウントを用意するのも管理が大変になるケースもあるかと存じますため、 アカウントを分割する際は、しっかり考慮した上で分割をご検討いただければ幸いです。
本ブログがどなかたのお役に立てれば幸いです。
