こんにちは。仕事でAWSの構築し、プライベートでAWSの研究と技術書の執筆をし、Amazonで本を売っているAmazon依存症の佐々木です。
今回のテーマはAWS Organizationsです。AWS Organizationsには様々な機能があるので、ここではAWS Organizationsの概要と、今1アカウントでAWSを利用している場合に、どうやってAWS Organizationsを導入すればよいのかのお勧めの方法を紹介します。
AWS Organizationsとは?
AWS Organizationsは、AWSアカウントを一元管理するためのサービスです。もともとは請求を一元管理するための一括請求 (コンソリデーティッドビリング)という仕組みがあったのですが、それがAWS Organizationsというサービスに昇格し、さらにシングルサインオンや複数アカウントの監査など様々な機能と連携するようになりました。
2021年4月現在では、AWS Organizationsには3つの機能があります。また、AWS Organizationsと連携可能な多数のサービスと、AWS Organizationsを前提とした幾つかのサービスがあります。
AWS Organizationsの機能
- 一括請求(コンソリデーティッドビリング)
- 複数のAWSアカウントの管理
- サービスコントロールポリシー(SCP)によるAWSアカウントに対しての統制
一括請求(コンソリデーティッドビリング)
AWS Organizationsのもともとの機能として、一括請求(コンソリデーティッドビリング)があります。その名の通り、複数のアカウント請求を1つにまとめることができます。一括請求を使わない場合は、個々のアカウントにクレジットカードの設定をし、それぞれ請求されることになります。イメージ的には、それぞれ請求される形ですね。これが、一括請求機能を使うと、1枚の請求書にまとめることができます。
一括請求のメリットは、請求書が1枚になるだけではありません。AWSにはボリュームディスカウントという仕組みがあり、これはサービスごとに設定され、一定以上の利用料(量)がある場合は、段階的な料金テーブルが適用されるという仕組みです。例えば、EC2のデータ転送料は、東京リージョンだと10TB未満は1GBあたり0.114USDですが、月150 TB以上利用している場合は0.084USDとなります。一括請求を利用していない場合は、これがアカウント単位で利用料が計算されます。一括請求を利用していると、傘下のアカウントのすべての利用料を元に計算されます。当然、単一アカウントの場合より、ボリュームディスカウントが効く可能性が高くなりますね。
ボリュームディスカウント以外にも、リザーブドインスタンスやSavings Plansを請求アカウント(管理アカウント)で購入すると、傘下のアカウントに自動的に適用させる事も可能です。特定のインスタンスに適用されるリザーブドインスタンスより、EC2等の利用料に対して適用されるSavings Plansは、特に有効です。これだけみても、Organizationsを利用して一括請求するメリットは大きいです。
複数のAWSアカウントの管理
次に複数のAWSアカウントの管理についてです。一括請求からAWS Organizationsに進化した際に利用できるようになった機能です。AWS Organizationsでは、組織単位 (OU:Organization Unit)という機能を使ってアカウントをグループ化できます。また、階層化も可能です。
組織化・グループ化する以外にも、APIや画面コンソールを利用して、AWSアカウントの発行ができます。アカウント発行時に、いちいちクレジットカードの用意が不要なのは大きいですね。
サービスコントロールポリシー(SCP)によるAWSアカウントに対しての統制
AWS Organizationsの注目すべき機能の一つに、サービスコントロールポリシー(SCP)があります。SCPは、アカウント全体に対して利用できるサービスの制限ができます。セキュリティの世界では、予め制限・禁止することによる予防的統制と、何か問題のある行為を検知する発見的統制の2つを使って、セキュリティを担保していきます。
SCPの登場前は、IAMを使って予防的統制を実現してきました。しかし、あくまでユーザー単位であり、ルートアカウントの統制が取れないこと、またアカウント全体に対しての統制は実現できませんでした。SCPが出たことにより、より上位のレベルでの統制ができるようになりました。
AWS Organizationsと連携するサービス
次にAWS Organizationsと連携するサービスです。現時点で10以上のサービスがあり、今後ますます増えてくるのではないかと思います。また、AWS Single Sign-On(SSO)やAWS Control Towerなど、AWS Organizationsが前提となっているサービスもあります。
- AWS リソースグループのタグポリシー
- AWS Artifact
- AWS Backup
- AWS CloudFormation StackSets
- AWS CloudTrail
- AWS Compute Optimizer
- AWS Config
- AWS Directory Service
- AWS Firewall Manager
- AWS License Manager
- AWS Marketplace - ライセンス管理
- AWS Resource Access Manager
- AWS Service Catalog
- AWS Single Sign-On
- AWS Systems Manager
- S3 Storage Lens
- AWS Control Tower
一つ一つの機能をとっても、非常に有用なサービスです。個々の説明をしていくと、それだけで1冊の本になる分量になるので、またの機会で紹介したいと思います。
1アカウントで既に運用している場合に、AWS Organizationsを利用開始するには?
さて、ここからが本題です。既にAWSを1アカウントで運用している場合に、AWS Organizationsの利用開始するにはどうしたら良いのでしょうか?一番の悪手は、既存のAWSアカウントでAWS Organizationsを作成し、管理アカウント化することです。
AWSのアカウント管理のベストプラクティスの一つに、「管理アカウントからリソースを分離する」というのがあります。管理アカウントはルートにあたるため、SCP等の統制がとれません。また、組織の管理という重要な責務があるため、ここにログインできるユーザーは制限すべきです。
それでは、どうすれば良いのでしょうか?お勧めの方法としては、新規のAWSアカウントを1つ作り、そこでOrganizationを作成することです。その上で、既存AWSアカウントを、そのOrganizationsに参加させるという方法です。
この方法であれば、既存のサービスには一切の影響を与えることなく、Organization化することが可能となります。簡単だけど有効な方法ですよね。その次は必要に応じて、1アカウント内に存在するAWSリソースを、更に追加で作成したメンバーアカウントに移行していくといった作業を行います。EC2やEBS等の主要サービスには、AMIやEBSスナップショットを他のAWSアカウントに共有するといった機能があります。それを使うと、比較的簡単にシステムの移行も可能になります。
まとめとAWS Organizationsの勧め
駆け足でしたが、AWS Organizationsの概要の紹介と、単一AWSアカウントで運用している場合のOrganization化についてでした。AWSのサービス自体がAWS Organizationsを前提としたものになりつつあります。利用が増えてから対応するのは大変なので、早いうちにOrganization化しておきましょう。
請求代行を使っているので、AWS Organizationsが使えないよというところもあるかと思います。そんな場合にお勧めなのが、Organizationsが利用可能な支払い代行サービスです。
NRIネットコムでは、AWSアカウン管理 & AWS 支払い代行サービスとして提供しています。一般的な請求代行機能や利用料の5%オフに加えて、Organizationの利用やアカウントセキュリティを支援するためのテンプレートの提供まで行っています。興味がある方は、ぜひお問い合わせください。