【重要サービス】AWS Organizationsってどんなサービスで、どんな時使うの？ ～AWS100本ノック～ 25/100

はじめに

AWS Organizationsって知っていますか？
一言で言うと、簡単に、マルチアカウントの管理・運用を出来るようにするサービスです。

S3やLambdaなどと違い、開発者の方が触ることはほとんどなかったりするんですが、非常に重要なサービスなのでご紹介します。

ちなみに、AWS Organizationsは無料で利用できます

アカウント管理(シングルアカウント戦略/マルチアカウント戦略)

まず、Organizationsの説明へ入る前に、アカウント管理について説明していきます。
アカウント管理方法としては、大きく分けて

• シングルアカウント戦略
• マルチアカウント戦略 ※個人利用じゃない場合は、基本こっちのはずです

の2つがあります。

シングルアカウント戦略とは

その名の通り、1つのAWSアカウントで複数環境(開発/ステージング/本番etc)のAWSリソースを作成するやり方です。
※流石にクライアントの会社が違う場合は、AWSアカウントはみなさん分けていると思いますが...

以下のように環境毎にVPCを分けたりして運用していきます。

メリットとしては、全てのAWSリソースを1つのAWSアカウントで管理するため、シンプルで導入が楽という点になります。

ただ、以下のようにデメリットが非常に多いです。

• リソース名の衝突などを意識しないといけない
• (タグ付けでなんとかなりはするが)各環境でかかったコストがわかりにくい
• AWSアカウントの上限のquotaを食いつぶし合うため、ステージング環境で過度に負荷をかけた際に本番環境で影響が出るかもしれない
• 開発環境のAWSリソースを削除しようとして、誤って本番環境のAWSリソースを削除してしまうなどのリスクがある
• 権限周りなど、セキュリティの統制が取りづらくなる

マルチアカウント戦略とは

マルチアカウント戦略では、プロジェクト毎・環境毎などでAWSアカウントを分離します。
シングルアカウントであげたデメリットが解消され、安心・安全に構築することが可能になります。

ただ、AWSアカウントが増えれば増えるほど以下のデメリットが出てきます。

• アカウント毎のアクセス・権限管理を修正する際に、手間がかかる
• アカウントごとのコストを各AWSアカウントに入らないと見られない
• ログなどが各AWSアカウントに存在するため、運用が手間

※CloudFormation StackSets(複数のアカウント・リージョンにCloudFormationsを展開し、AWSリソースデプロイするサービス)を利用すればある程度は楽になる部分はあります

こういったマルチアカウント戦略のデメリットを解消するためのサービスがAWS Organizationsになります！

AWS Organizationsの全体像

AWS Organizationsを構成する主要な概念は以下になり、これらをまとめて組織と呼びます。
組織は、AWS Organizations内で1つのみ作成することが出来ます。

• 管理ルート
• OU
• 管理アカウント
• メンバーアカウント
• ポリシー

では、それぞれについて説明していきます。

管理ルート

組織階層の最上位に当たり、AWSアカウントを整理するための出発点です。
管理ルートを起点に、OUを作成してグルーピングしていきます。

OU

Organizational Unitの略で、組織内のメンバーアカウントのグループになります。
OUには、メンバーアカウントを含めることが出来るのに加えて、OUも含めることが出来ます。
例えば、営業部・総務部のグループを作り各グループにAWSアカウントを所属させ、開発部のグループには開発部1課・開発部2課と子OUを作ったりします。
実際の会社・プロジェクトの構造、環境(開発/検証/本番)で階層化するイメージです。

管理アカウント

組織を管理するアカウントになります。AWS Organizationsで組織を作成したアカウントがこれに当たります。
メンバーアカウントと違い、管理アカウントは組織内で1つのみ存在します。

管理アカウントでは、様々なことが出来るので、最小限のメンバーのみがアクセスできる形が望ましいです。
管理アカウントで出来ることについては、以降で説明します。

管理アカウントを組織内の別メンバーアカウントに変更することは出来ません

メンバーアカウント

メンバーアカウントは、今まで使っていた各AWSアカウントのことを指します。
管理ルート直下、または、OU配下にメンバーアカウントを作ります。

メンバーアカウントは1つの組織にのみ所属できます

ポリシー

組織内のグループ・アカウントに適用するポリシーのことで、管理ポリシーと承認ポリシーの2つがあり、それぞれ以下のポリシーから用途に応じて利用します。

• 管理ポリシー
  • 宣言型ポリシー：組織全体で特定のAWSサービスに対して必要な設定を一元的に宣言して適用できるようにするポリシー
  • バックアップポリシー：バックアッププランを一元管理し、組織のアカウント全体のAWSリソースに適用できるようにするポリシー
  • タグポリシー：組織のアカウントのAWSリソースにアタッチされたタグを標準化できるポリシー
  • チャットボットポリシー：SlackやTeamsなどのチャットアプリケーションから組織のアカウントへのアクセスを制御できるようにするポリシー
  • AIサービスのオプトアウトポリシー：組織内の全てのアカウントのAIサービスのデータ収集を制御できるポリシー
• 認可ポリシー
  • SCP(サービスコントロールポリシー)：組織内のIAMユーザーとIAMロールが利用できるアクセス許可の最大数を一元的に制御できるポリシー
  • RCP(リソースコントロールポリシー)：組織内のリソースに対して使用可能なアクセス許可の最大数を一元的に制御できるポリシー

色々ポリシーの種類があるのですが、この中で一番よく使うSCPについて説明します

管理ルートにポリシーをアタッチした場合は、

• 管理ポリシーをアタッチすると、管理アカウントを含む全てのOUとアカウント
• 認可ポリシーをアタッチすると、管理アカウント以外の全てのOUとアカウント

に適用されます。

SCP(サービスコントロールポリシー)とは

SCPは、IAM Policyと同様にjson形式のステートメントで定義し、管理ルート・OU・アカウントのいずれかにアタッチします。
デフォルトだと、FullAWSAccessというポリシーが全て(管理ルート・OU・アカウント)にアタッチされています。
FullAWSAccessでは、全てのリソースに対する全てのアクションを許可しています。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "*",
            "Resource": "*"
        }
    ]
}

ここでIAMポリシーと何が違うんだ？って思う方もいるかもしれませんね
SCPとIAMポリシーでは目的や対象が違います。

IAMポリシーは、

• AWSアカウント内のIAMユーザ・グループ・ロールなど特定のIAMアイデンティティを対象
• 対象に許可/拒否の権限の付与をすることを目的

とします。一方、SCPは

• 管理ルート・OU・アカウント内の全てのリソースを対象とする
• 対象に権限の境界設定をすることを目的とする

となり、SCPの方が上位で設定されることになります。

以下の例だと、

• 管理ルート・OU・アカウントに全てのリソース・全てのアクションを許可する境界のFullAWSAccessがアタッチ
• 開発部1課(OU)にEC2の全てのアクションを拒否するSCP-EC2Denyがアタッチ
• AシステムアカウントのIAMユーザには、全てのリソース・全てのアクションを許可するポリシーがアタッチされています

この場合はどのような動きになるでしょうか？

Lambda関数の作成は、SCP・IAMポリシーの両方で許可されているため作成することが出来ます。
しかし、EC2インスタンスの作成はSCP-EC2Denyで拒否されているため、例えIAMポリシーで許可していても作成することは出来ません。

このようなSCPとIAMポリシーの違いがあるのですが、FullAWSAccessが全てのOU・アカウントにデフォルトでアタッチされていることから想像するに、基本的にはSCPではFullAWSAccessで全てを許可しつつ、必要に応じて拒否のSCPをアタッチするのが良いと思います。
例：本番環境(OU)では、ログの削除は行えないようにする、CloudTrailの設定は特定のIAMユーザ以外は行えないようにする、など

Organizationsのベストプラクティスとしては、OU単位でSCPのアタッチを行い、アカウントにはFullAWSAccessのみアタッチすることが推奨されています。

また、管理アカウントはSCPの影響を受けません。

SCPには、継承という概念があるのですが、そちらに関しては別記事を書くようにいたします

AWS Organizationsで出来ること

全体像を説明したところで、管理アカウントで出来るAWS Organizationsの機能について説明します。
主に、以下のことが出来ます。

• AWSアカウントの一元管理
• 組織外AWSアカウントの組織への招待
• 管理ルート・OU・メンバーアカウントへのポリシーのアタッチ
• 請求とコストの一元管理
• アカウント間のリソース共有
• サービスの統合
• サービス統合における管理者権限のメンバーアカウントへの委任

AWSアカウントの一元管理

OUの作成と削除を行い、組織構造を作ることが可能です。

また、各OUに所属するメンバーアカウントの作成/削除が行えます。
通常のアカウント追加と違い、メンバーアカウント追加時にクレカ情報などが不要で簡単に追加することが出来るのは良い点です。
別OUへの移動/組織からの除外も可能です。

組織外AWSアカウントの組織への招待

今までAWS Organizationsを使っていないで運用していた場合は、組織外のAWSアカウントが複数あることになります。これを組織に後から加えたい場合は組織へ追加するための招待を送ることが出来ます

管理ルート・OU・メンバーアカウントへのポリシーのアタッチ

先ほど説明したポリシー(SCPなど)を管理ルート・OU・アカウントにアタッチして境界を設定できます。

請求とコストの一元管理

今までは各アカウントで請求を管理していましたが、AWS Organizationsで一元管理することが可能です。
これによって、各AWSアカウントで支払設定をしたり請求情報を閲覧することが無くなり、請求処理や各アカウントの請求閲覧を管理アカウントのみで行うことができるようになります。

請求処理を同一クレジットカードによって、一括で行うことによるクレジットカード上限オーバーには注意しましょう

また、一括請求にすることによってEC2やRDSなどで使用量による割引のボリュームディスカウントを適用できる可能性があります。

今までは単一アカウントの使用量でしたが、Organizations配下のアカウント合計の使用量で、ボリュームディスカウントが適用されるか決まるためです。
さらに、リザーブドインスタンスとSavingPlansに関しても別アカウントと割引の共有を行うことも可能です。

アカウント間のリソース共有

AWS RAM(Resource Access Manager)を利用して、組織全体・OU・アカウント内でリソースの共有・管理を行うことが出来ます。
S3バケットだったり、VPCだったり、DBだったりで本当は各アカウントで作る必要がなかったものがあれば、リソース共有することでランニングコスト・運用コストを削減することが出来ます

サービスの統合

通常、各AWSサービスの管理やログは、各AWSアカウントで行いますがアカウントが増えれば増えるほど運用の手間が増えてきます。
そこで、サービスの統合を利用して、AWS Organizations配下のAWSアカウントで利用するAWSサービスのタスクをメンバーアカウントに変わって代理実行し、集約管理することができます。

統合できるサービス一覧はこちらに記載があるのですが、以下のサービスはみなさん統合しているようです。

• CloudFormation StackSets
  • 組織内の複数アカウント・リージョンにCloudFormationスタックを展開できる機能
  • 各環境で作りたいリソースを組織全体、または、指定したOS配下のアカウントに一括で作成することが可能
  • アカウント追加・削除時の、自動デプロイ/削除機能も利用可能
• GuardDuty
  • 組織内のログを分析して抽出された脅威検出イベントを集中管理
• Secuity Hub
  　- 組織内の複数のセキュリティサービスの検出結果を集中管理
• AWS Config
  • 組織内のAWSリソース情報と、ルールやコンプライアンスチェックの集中管理
• CloudTrail
  • 組織内の証跡(AWSアカウント内で実行されたアクションやイベント)の集中管理

なお統合を有効化する際は、Organizationsのコンソール画面ではなく、各AWSサービスのコンソール画面かAWS CLIで行うのが良いそうです
参考

サービス統合における管理者権限のメンバーアカウントへの委任

サービスを統合して集約出来るようになって、管理は非常に楽になりました。
しかし、管理アカウントは非常に強い権限を持っているため、管理アカウントにアクセスできる人は限定したほうが良いとされています。

しかし、これだけのサービスを少人数で管理するのは難しいかもしれませんし、CloudTrailやGuardDutyなどの監査・監視系の担当は別の人を立てたり外部の会社に頼むかもしれません。
そういった場合に、別のメンバーアカウントに対象AWSサービスの管理を委任することが出来ます。
これによって、不必要に管理アカウントにログイン出来るユーザを増やす必要もなく、責任を分離して安全に作業することが出来ます。

AWS Organizations利用が前提のサービス

以下のサービスは、AWS Organizationsを利用していないと利用することが出来ません。
簡単に紹介します！

Control Tower

Control Towerは、AWS Organizationsや各種セキュリティサービスなどを自動的にセットアップし、マルチアカウント統制環境(Landing Zone)を簡単に構築できます

IAM Identity Center(旧名称：AWS SSO)

IAM Identity Centerでは、以下のことが出来ます。

• 組織内アカウントへのログインの簡素化(SaaSも可)
• 複数アカウントのアクセス制御の一元管理
• ユーザ管理(外部ID管理と連携可能)

AWS Firewall Manager

AWS Firewall Managerでｈ、AWS WAFやAWS Shield、セキュリティーグループなどを一元管理することが出来ます。
また、ベースラインを作成して監視し、違反した場合には自動的に更新するようなことも出来ます。

おわりに

今回はマルチアカウントの管理・運用を簡単にする、AWS Organizationsについて説明しました。
複数アカウントを利用しているのにまだ使ってない、って方は是非利用することをお勧めします