はじめに
「おひとりさまAWS Organizations」とは、その名の通りAWS Organizationsを一人で使うことです。
AWS Organizationsは複数のAWSアカウントを一元管理する機能なので、主に企業等が利用することを想定されたサービスです。
ですが、これをあえて一人で使います。
ハンズオン用アカウントなどで一人で複数アカウント発行することもあるのと、Organizationsについて学んでおきたかった、というのが主な理由です。
用語
まずは用語のお勉強です。
AWS Organizations(以下Organizationsと呼ぶ)
- 複数のAWSアカウントを一元管理することのできるサービス
- 利用料金無料
管理アカウント
- Organizationsの管理を行うアカウント
- 後述するOUの作成・削除、メンバーアカウントをOUに移動させたりなどを行う
Organizational Unit(以下OUと呼ぶ)
- 組織単位とも呼ばれる
- Organizationsを親とする子単位
- 管理アカウントと1対Nの関係
メンバーアカウント
- Organizationsに属するアカウント
- OUと1対Nの関係
サービスコントロールポリシー(以下SCPと呼ぶ)
- OUやアカウントに対して適用するポリシー
- 複数のアカウントに対して一括で適用できる点がメリット
- ポリシーはJSONで定義する
- 例:下記は
FullAWSAccess ポリシー
のJSON
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "*",
"Resource": "*"
}
]
}
IAM Identity Center(以下IdCと呼ぶ)
- 利用料金無料
- IdC内でユーザー・グループを作成して、AWSアカウントに紐づける事ができる
- 作成したユーザーで、AWSへのSSOログインを可能にする
許可セット
- 1つ以上のIAMポリシーを複数のIdCユーザー・グループに適用するテンプレート
SCPと許可セットの違い
SCPと許可セットはどちらもポリシーを設定するが、両者には違いがあります。
SCPは組織アカウントやOUに対して適用され、許可セットはIdCの個々のユーザーやグループに対して適用されます。
マネコンで操作するときも、SCPはOrganizationsの画面から設定し、許可セットはIdCの画面から設定します。
SCPと許可セットの違いを表にまとめたものが以下です。
SCP | 許可セット | |
---|---|---|
適用範囲 | 組織全体のアカウントやOUに対して適用され、全体のアクセス制御を強化する。 | 個々のユーザーやグループに対して適用され、特定のアカウント内での権限を管理する。 |
目的と使用方法 | 組織全体のセキュリティポリシーを強制し、各アカウントのIAMポリシーに対する上位の制約として機能する。 | ユーザーやグループに特定のアクセス権限を割り当て、日常の操作やリソース管理を簡単にする。 |
できたもの
Organizations開始前に使っていたメインのアカウントをRoot配下に管理アカウントとして配置しました。
また、SandboxというOUを作りその配下にsandbox-accountというアカウントを追加しました。
画像には写ってませんが、IdCで作ったユーザー・グループが各AWSアカウントにぶら下がっています。
Organizations, IdCでの操作
Organizations, IdCで行う操作について説明します。
AWS Organizationsの開始
Organizationsはデフォルト状態では無効になっているため、有効化する必要があります。
マネコンから「Organizations」と検索し、Organizationsの画面から有効化を行いましょう。
AWSアカウント新規追加とスイッチロール
AWSアカウントを新規に追加する際は、Organizationsの画面から行います。
アカウント名メールアドレスなどを入力して作成することができます。
メールアドレスの注意点
一度AWSアカウントに利用したメールアドレスは、そのアカウントを削除したとしてもメールアドレスの再利用ができません。
公式ドキュメントにも明記されています。
https://docs.aws.amazon.com/accounts/latest/reference/manage-acct-closing.html
You can't use the same email address that was registered to your AWS account at the time of its closure as the primary email of another AWS account. If you want to use the same email address for a different AWS account, we recommend updating it before closure. See Update the AWS account name, email address, or password for the root user for instructions on updating your email address.
sandbox用アカウントやハンズオンアカウントを作成する際は拡張メールアドレスやエイリアスアドレスなどを使ってテスト用のアドレスを取得することをおすすめします。
私はGmailのエイリアスアドレスを使いました。
アカウントが作成されたら、スイッチロールでそのアカウントにサインインします。
IdCユーザー・グループ・許可セットの追加
AWSアカウントが作成できたら、その配下にIdCのユーザー・グループを紐づけていきます。
こちらの記事を参考に実施しました。
UIに沿って操作すれば、詰まるところはなかったです。
ユーザー作成時に指定するメールアドレスは、アカウント作成時と同じくエイリアスアドレスを使いました。
許可セットは任意のポリシーを選びましょう。自分はAdministratorAccessとPowerUserAccessを作成しました。
ユーザー作成するとサインインURLがメールで送られてきます。アクセスすると以下のような画面になります。
サインイン後は以下のように、自身の親のアカウント名と許可セット名が表示されます。
さいごに
最後に、おひとりさまAWS Organizationsを実際に行ってみて感じたメリット・デメリットを挙げます。
メリット
- ハンズオン・個人開発など用途に応じたAWSアカウントを一元管理できる
- Organizationsの勉強を一人でできる
- Organizations, IAM Identity Centerはどちらも追加料金無しのためコスパ良し
デメリット
- 漢のシングルアカウント運用と比べるとどうしても複雑さは増す
参考