AWS Organizationsとは?IAMとの関係をしっかり理解する

Solutions Architect - Professionalを取得してからAWSのベーシックな部分を触る機会が減ってしまったので、改めて知識を整理するために記事にまとめました。

今まで『理解しているようでよくわかっていなかった』Organizations周りを『理解できた!』と思えるようになると思います。

全体概要図

AWS Organizations と 各種IAM との関係性を整理した図がこちらになります。
細かく書き出すと書ききれないですが概要を理解する上ではこの内容で十分です。

AWS Organizations と IAMの概要図

まず、Organizations とは複数のAWSアカウントを統合管理するためのサービスです。

図の右側に記載の通りAWSアカウントごとにIAMユーザやEC2などのリソースを持っていますが、Organizations を使う事で「AWSアカウントそのものに対して権限を制限」「請求を一元化」できるメリットがあります。

Organizationsコンソール画面

Organizationsには1つの管理アカウントと複数のメンバーアカウントを持つことができます。
このキャプチャではsyun03が「管理アカウント」、memberが「メンバーアカウント」です。
もちろんそれぞれがAWSアカウントに紐付いていますので、それぞれ環境やリソースを持っています。

メンバーアカウントからOrganizations を操作することはできません。

各項目の説明

登場するポイントは9つです。

  1. 組織
  2. 組織単位(OU)
  3. 管理アカウント
  4. メンバーアカウント
  5. AWSアカウント
  6. IAMユーザ
  7. IAMポリシー
  8. IAMロール
  9. SCP

ちなみに「IAMアカウント」「AWSユーザ」という単語は存在しません。AWSを学んでいく上でこのような造語があると混乱ポイントになりますよね。

それでは各ポイントについて解説していきます。

組織

AWSアカウントを統合して管理するための管理単位です。AWS Organizations コンソールを使用して、組織内のすべてのアカウントを一元的に表示および管理できます。組織には、1 つの管理アカウントと、ゼロ以上のメンバーアカウントを含みます。
コンソリビューテッドビリングにより請求をまとめることが可能です。

組織単位(OU)

組織内に定義する下位の組織です。組織単位をネストすることも可能です。

管理アカウント

管理アカウントには、支払いアカウントだけでなく、メンバーアカウントによって発生したすべての料金を支払う責任があります。組織の管理アカウントを変更することはできません。

メンバーアカウント

組織に招待されるか組織の中で作成されたAWSアカウントです。メンバーアカウントは存在することができます。

メンバーアカウントはOUの中に所属することもroot直下に所属することもできます。

TIPS

組織内でのリソース共有を有効にするには

AWS Resource Access Manager を使います。

AWS RAM コンソールの Settings ページを開きます。
Enable sharing with AWS Organizations を選択してから Save settings を選択します。
https://docs.aws.amazon.com/ja_jp/ram/latest/userguide/getting-started-sharing.html

AWS Resource Access Manager を入れた構成

部署ごとにリソース利用料の請求分ける

コスト配分タグを利用してOUごとに請求を分ける必要があります。
OUごとに費用を分ける機能はございません。

メンバーアカウントを削除するには

メンバーアカウントを組織から除外するためには、スタンドアロンアカウントである必要あり請求情報が登録されているなどの条件があります。
https://docs.aws.amazon.com/ja_jp/organizations/latest/userguide/orgs_manage_account-before-remove.html

AWSアカウントごとにIAMユーザを作成しなくてもいい

開発環境のIAMユーザから本番環境を操作したい場合はassume roleにより本番環境用のIAMユーザに昇格して運用します。

この考え方がAWSにおけるマルチアカウント戦略の基本です。

本番環境へのアクセスをIPアドレスで制限したい

本番環境などでIP制限が必要な場合には、assume roleされるのIAMにIAMポリシーを設定する形で制限を行います。

本番用のIAMポリシーに下記の通り記述する。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::xxxxxxxxxxxx:user/Operator"
      },
      "Action": "sts:AssumeRole"
    },
    {
      "Effect": "Deny",
      "Principal": {
        "AWS": "arn:aws:iam::xxxxxxxxxxxx:user/Operator"
      },
      "Action": "sts:AssumeRole",
      "Condition": {
        "NotIpAddress": {
          "aws:SourceIp": "xxx.xxx.xxx.xxx/32"
        }
      }
    }
  ]
}

コメントを残す