概要

AWS OrganizationsはAWS認定Professionalの「組織の複雑さに対応する設計」ドメインの問題を解くための重要な要素だが、個人では利用する機会がなく、エンタープライズでも社内のAWS全体を管理するような部署でなければなかなか触れることができない。
仕方がないので、資料を見ながらアウトプットすることで少しでも理解を深める。
※なので、これはただの勉強ノート兼備忘録ですという言い訳
参考にした資料(SlideShare)(公式)：AWS Black Belt Online Seminar AWS Organizations

AWS Organizations(AWS組織)とは

企業でAWSを利用する場合、環境やシステムごとに権限の分離のためアカウントを複数作成することが推奨される。
アカウント間では権限は完全に分離されているため、複数アカウントにまたがった管理・制限や請求の一元化を行うための機能としてAWS Organizationsが存在する。
AWS Organizationsを利用することで主に下記の3点が実現できる。

複数のAWSアカウントの一元管理
AWSアカウント新規作成の自動化
請求の簡素化

AWS Organizationsの機能セット

AWS Organizationsには2つの機能セットがある。

機能セット	マスターアカウントへの一括請求	アカウントの新規作成・招待・削除	サービスコントロールポリシーによる一元管理
Consolidated Billing Only (一括請求のみ)	◯	◯	☓
All Feature(すべての機能)	◯	◯	◯

一括請求のみでも、アカウントの作成・招待や削除はできる。

OU(Organization Unit: 組織単位)

組織内にある複数AWSアカウントのグループで、OUにAWSアカウントを追加することでポリシーを一括適用できる。
OUには階層があり、下の階層にはSCPやタグポリシーなどのポリシーが継承される。

引用元：https://www.aws.training/Details/eLearning?id=42403

SCP(Service Control Policy: サービス管理ポリシー)

AWS Organizationsを利用する主たる目的の一つ。
組織内の権限の上限を定義することができる。(IAMの「アクセス許可の境界(Permission Boundary)」と似ている)
組織内のアカウントやOUに対して事前に「このサービスは利用させない」「これ以上の権限レベルは与えない」という制限をかけるのに利用する。

引用元：【AWS Black Belt Online Seminar】AWS Identity and Access Management (AWS IAM) Part1

SCPの適用対象

以下の3つに割り当てることができる(マスターアカウントは適用対象外)

組織ルート
OU(組織単位)
アカウント

SCPによるアクセス可否の決定ロジック

基本的なアクセス可否の決定ロジックはIAMと同じだが、SCPは制限をかけるためのものなのでDenyは1つでもついていれば有効、AllowはSCPとIAMポリシーの両方で指定されて初めて有効。

引用元：【AWS Black Belt Online Seminar】AWS Identity and Access Management (AWS IAM) Part1

引用元：【AWS Black Belt Online Seminar】AWS Identity and Access Management (AWS IAM) Part1

SCPの構文ルール

基本的にはIAMのポリシーと同一の構文ルール。
違いは以下2点のみ。

Principalは指定できない
(アイデンティティベースポリシーと同様、付与先がPrincipalとなるため)
Resourceには"*"以外指定できない

SCP記述例

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

Consolidated Billing(一括請求)

SCPと並び、AWS Organizationsを利用するもう一つの目的。
その名の通り、組織内の利用料がマスターアカウントに集約される。
ボリュームディスカウントやリザーブドインスタンスの割引が組織内で共有できる。
(勘違いしがちだが、リザーブドインスタンスは1つの同一のインスタンスである必要はない、1時間単位で合計3600秒のインスタンスの起動に対し1インスタンス分の請求、この範囲内であれば同時に複数インスタンス起動でも問題ない)

例：
同一組織内にAWSアカウントAとBがあったとする。
この組織ではt3.microのリザーブドインスタンスを1年分購入している。
AWSアカウントAで1:00にt3.microインスタンスを起動、1:30に停止、AWSアカウントBで1:30にt3.micoインスタンスを起動、2:00に停止した場合、購入済みのリザーブドインスタンスの利用料以上に追加で請求は行われない。

タグポリシー

組織内のタグ付けに関するポリシーを定義し、タグを標準化するための仕組み。
大文字小文字や値として利用できる文字列などを定義し、このルールに準拠しないタグの付与を防ぐ。
例：タグEnvキーの値にはDev, Stg, Prd以外付けさせない

詳しくは下記参照
https://blog.serverworks.co.jp/tag-policies