AWS Organization マルチアカウント管理への道 SandBox環境

2024 1/14

January 10, 2024 January 14, 2024

AWSを色々といじっていく中でブログを立ち上げている環境とterraformで遊ぶ環境が同じ環境にあるのが怖くなってきました。
また権限管理の特性上用途に合わせてiamユーザーを作成していると、アカウントが複数になってきて管理が大変です。

ブログ環境を汚さないようにお遊び環境が欲しい。。。。
、、、ということで勉強もかねて、AWS OrganizationsでSandBox環境を作ってみます。

AWS Organization OUとは

AWS Organizationでまず第一に覚えないといけない単語が、「OU」です。
OUは、Organization Unitの略称で日本語では「組織単位」と呼ばれています。

OUを適切に設定することでAWSのユーザをグループ管理することが可能になります。
OUにポリシーをアタッチすることでグループごとの権限管理も容易に実施することが可能です。

あわせて読みたい

組織単位の管理 - AWS Organizations AWS Organizations を使用して、をグループ化および整理します AWS アカウント。組織単位 (OU) を使用すると、管理目的で一連のアカウントを単一エンティティとして扱うこ...

AWS Organization OU設計

OU構成はまず公式のbasicを真似てみるのが良いと思います。

あわせて読みたい

Basic organization - Organizing Your AWS Environment Using Multiple Accounts The following example incorporates a security tooling environment for common security services, a second workload, and support for sandbox and development envir...

今回は個人用途＋SandBox環境を作れたら十分のため、公式の構成を参考に、必要最低限な以下の構成としました。

--- Root/
  |-- management(Account)
  |-- Sandbox/
  |-- Workloads/
        - Prod/
        - (Dev/)

management 　　　・・・ AWS Organizationを管理するユーザー
Sandbox　　　　　・・・　お遊び環境、terraformいじくり環境
Workloads/Prod　　・・・　ブログ環境
Workloads/(Dev)　・・・　ブログ開発環境

AWSのOUはマネジメントコンソール画面から容易に作成することが可能です。

組織構造で親要素を選択した状態で、
「アクション」＞「組織単位」＞「新規作成」
をクリックし、組織単位名を指定するだけで作成可能です。

SandBox環境

SandBox環境はお遊び環境とは言うものの、権限が弱いと任意のサービスを好きなように使用できないため効率が悪いです。

ただAccess Tokenの流出の影響で超過請求が来るのも困るのである程度のルール決めが必要に思えます。
AWS使用者の治安が良ければいいのですが、だからといって管理者が無法地帯にすると悪者が来た時に力を抑えられなくなります。

規律は公式にも記載ありました。

あわせて読みたい

Sandbox OU - Organizing Your AWS Environment Using Multiple Accounts The Sandbox OU contains accounts in which your builders are generally free to explore and experiment with AWS services and other tools and services subject to y...

ざっくり抽出すると以下です。

最高金額を設定する
定期的なリソースの自動削除
管理者権限の付与
企業独自のソースコードアップロード禁止（あくまでもAWSのお触り環境）
開発環境とは明確な区別が必要

最高金額を設定する

OrganizationのOU単位・SandBox OUはいくらまでという予算上限を設定することは出来なさそうでした。
AWS Budgetを使用することでアカウント全体で特定の金額を超えた時にアラートメールを飛ばすことは可能です。

以下のリンクから予算を設定します。

あわせて読みたい

Creating a budget - AWS Cost Management Create a budget with AWS Budgets to track and take action on your AWS costs, usage, and Savings Plans coverage.

以下のように特定の金額を設定可能です。$6、安い。

予算を超えてくると以下のようなメールが来るため、検知可能になります。

定期的なリソースの自動削除

ここのブログ記事では毎日1日に定期削除しているけども、流石にそれは頻度高すぎじゃない？と思いました。
学習期間中終わり次第SandBox環境のリソース削除でよいと思います。

AWS CDKやTerraformが日々進歩し、リソースのIaC化も進んでいるためにリソースの削除も容易に実施できるはずです。
利用者を想定してルール決めが出来たらよいですね。

管理者権限付与

AWS Organizationで作成したメンバーアカウントは、メンバーアカウントのAWS環境でデフォルトで管理者権限相当の権限を持ちます。
正確に言うとOrganizationAccountAccessRoleが作成され、このロールにAdministratorAccessポリシーがアタッチされています。

AWS Organizationで作成したメンバーアカウントは何しても良い環境かつ、請求先はAWS Organization管理アカウントに飛ぶため、SandBox使用者目線で見ると夢のような環境なわけです。

ただ管理アカウント目線では払い出したメンバーアカウントに費用が高いサービスを使われるととんでもない請求になるためそういったサービスは使ってほしくないですよね。

ここでService Control Policy(SCP)の登場です。
SCPを設定すると管理アカウント目線ではお金がかかるやってほしくないやセキュリティ的にやってほしくないなどを定義できます。
AWSのリソースに対するアクションに制限をかけられるものです。
これはOU単位で設定可能です。

以下はec2の操作をすべて禁止にしたポリシーの例です。