(レポート) SAC323 – NEW SERVICE: Centrally Manage Multiple AWS Accounts with AWS Organizations #reinvent

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

こんにちは、菊池です。

re:Inventで発表された新サービス、AWS Organizationsについて早速セッションに参加しましたのでレポートします。

レポート

セッションは以下の内容で構成されていました。

  • OverView
  • デモ
  • Best Practices

Overview

Service highlight

  • 複数のAWSアカウントを集中管理するための管理機能
    • AWSアカウントの論理グループ(Organization)
    • Organizationに管理ポリシーを適用する(OCP:Organizational Control Policies)
    • 新しいAWSアカウントを簡単に作成できる
    • 簡素化された費用請求
  • 1つのAWSアカウントはただ1つのOrganizationに所属する
  • マネジメントコンソール/SDK/CLIで全ての管理タスクをサポート

Key concepts

  • Organization
    • 一元的に管理できる連結されたAWSアカウントの集まり
  • AWS account
    • S3バケット/EC2インスタンスなどのようなAWSリソースのコンテナ
    • IAMユーザ/ロールにてアクセス制御を行う
    • AWS Organizationの最小管理単位
  • Master account
    • Organization内の他の全てのアカウントの費用支払いをする
    • Organizationを管理するManagement Hub
  • Organization Unit (OU)
    • Organizationに所属するのAWSアカウントの論理グループ
  • Administrative root
    • OUの階層構造の最上位
  • Organization conrtol policy (OCP)
    • アカウントに適用される制御ポリシー
    • ユースケースが異なればOCPも異なる

新しいAWSアカウントを簡単に作成できる

  • 新しいアカウントはMaster accountからのみ作成される
  • 作成プロセス
    • Emailアドレス(必須)
    • アカウント名(必須)
    • IAMロール名(オプション:デフォルトではOrganizationAccountAccessRole)
      • Master AccountからのAssumeRoleが許可される
      • フルコントロール権限
    • IAMユーザのBillingへのアクセス権(オプション)
  •  新しいアカウント
    • 自動的にOrganizationの1つとなり、抜けることはできない

CLI sample

aws organizations create-account
 --email hoge@example.com
 --account-name "test-account"
 --role-name test-role

既存のアカウントをOrganizationへ追加

  • Master accountからのみInvitationを発行可能
  • 招待されたアカウントは受諾または拒否を選択
    • デフォルトでは拒否
    • IAMで制御可能
  • 受諾すると
    • アカウントはOrganizationのメンバーになる
    • 適用可能なOCPが自動で適用される
  •  招待されたアカウントはOrganizationを抜けることができる

アカウントの論理グループ

  • グループ内のアカウントは簡単にorganization unit (OUs)に追加可能
  • アカウント/OUsは他のOUのメンバーになれる
  • アカウントは複数のOUのメンバーになれる

Organization Control Policies (OCP)の適用

  • 制御内容を記述する
  • ユースケースごとにOCPを作成する
  • OCPはOrganization/OU/アカウントに適用可能
  • OCPは階層構造(Organization/OU/アカウント)で継承される

OCPはService Control Policies (SCPs)をサポート

  • どのAWSサービスのAPIへアクセス可能か、ホワイトリストかブラックリストで制御
  • ローカル管理者が上書きすることは不可
  • IAMポリシーとSCPで許可されたものが最終的にアクセス可能
  • 必要条件であり、十分条件ではない

費用請求

  • 全てのアカウントを1つの支払いアカウントに集約
  • Organizationのアカウントの全ての利用料でボリュームディスカウントは適用される
  • 既存のConsolidated Billingのアカウントは、1つのOrganizationのBillingモードへマイグレーションされる

2つの管理レベルを設定可能

  • Billingモード
    • 既存のConsolidated Billingとの互換モード
    • 既存のConsolidated Billingからは自動でBillingモードのOrganizationが作成される
  • フルコントロールモード
    •  Billingモードの機能は全て含まれる
    • 全てのタイプのOCPが利用可能
    • Billingモードからの変更には、Organizationに含まれる全てのアカウントの同意が必要

Organizationを管理するための最小権限

  • 全てのAWS Organizations actionに対するIAM権限
  • IAMロールを使って他のアカウントのOrganizationへのアクセス
  • 全てのOrganization管理アクティビティはCloudTrailに記録される

Best Practices

  1. Master accountのアクティビティはCloudTrailでモニタすること
  2. Master accountでAWSリソースを管理しない
  3. Organizationへは最小権限で管理する
  4. アクセス制御にはOUを使う
  5. root of Organizationには必要な時のみ権限を付与する
  6. まずはシングルアカウントで権限をテストすること
  7. SCPにホワイトリストとブラックリストの混在を避けること
  8. 新しいアカウントは必要がある場合のみ作成する(むやみに作成しない)

まとめ

新サービスのAWS Organizationsの概要でした。これまでに、Consolidated BillingやIAMを使っていれば、比較的すぐ理解できるサービスかと思います。特に、ベストプラクティスで語られていることは、これまでのIAM管理と通じるものです。

まだプレビューですが、しっかりと予習して適切にアカウント管理をできるようにしておきたいと思います。