トップ > AWS Organizations > AWS OrganizationsとCFn StackSetsを実際に運用して判明した現場に即したOU構成

AWS OrganizationsとCFn StackSetsを実際に運用して判明した現場に即したOU構成

AWS Organizations
記事タイトルとURLをコピーする

こんにちは。AWS CLIが好きな福島です。

はじめに

今回は、タイトル通り、AWS OrganizationsとCFn StackSetsを実際に運用して判明した現場に即したOU構成をご紹介いたします。

AWSのホワイトペーパーに記載のOUのベストプラクティスについて、まとめたブログもあるため、ご紹介しておきます。

blog.serverworks.co.jp

結論

結論から記載すると、以下の構成図にて黄色い枠で囲った Foundation OU および Suspended OU を導入することを推奨いたします。
※Foundation OU は、AWS のホワイトペーパーに記載のされていないサーバーワークスが考える独自の OU です

構成図

f:id:swx-fukushima:20211005162654p:plain

Foundation OU とは

本OUは、AWSのホワイトペーパーに記載がないため、勝手に付けた名前となります。 用途としては、Root直下に作成するOUで、後述するSuspended OU以外のOUを所属させるOUとなります。

Suspended OU とは

本OUはホワイトペーパーにも記載があり、一時的または恒久的に使用を停止する必要のあるアカウントの一時的な保管場所として使用します。

導入した理由

Foundation OU および Suspended OU を導入する理由は、以下を可能にするためです。

①RootにアタッチできるSCPの擬似的な制限緩和

RootにアタッチできるSCPには制限があるため、上記OUを導入することで、疑似的な制限緩和が可能です。
※Foundation OUのみ導入することで実現可能です。

補足
  • RootおよびOUにアタッチできるSCPは5個という制限があり、かつ、FullAccessというSCPのアタッチはほぼ必須になるため、実質4個になります。
  • 1つのSCPに記載できるバイト数は、5120 バイトとなります。
  • 今回は、実際に運用していく中でSCPで制御をかける要件が増え、4つでは足りなくなったため、Foundation OUを導入いたしました。
  • 4つ全てが5120バイトの制限でポリシーを書けなくなった訳ではないのですが、ある程度、用途ごとにSCPを書いていたため、バイト制限を受けてないSCPにポリシーを追加することはしませんでした。

②CloudFormaion StackSetsのエラー回避

StackSetsは、デプロイ範囲に停止しているAWSアカウントが含まれているとエラーとなりますが、上記OUを導入することで、エラーを回避できます。
※FoundationおよびSuspended OUを導入することで実現可能です。

具体的には、Suspended OUへ停止しているAWSアカウントを移動し、StackSetsのデプロイ範囲をFoundation OUとします。

補足

  • StackSetsの実行エラーは、StackSetsをデプロイする際に耐障害性の設定(許容できるスタックの失敗数)を増やすことで回避は可能ですが、StackSetsの実行結果にエラーが表示されるため、エラーが正常なものか、それとも異常なものなのか、デプロイ状況を確認するのに手間がかかります。

  • CloudFormationのStackSetsでは、ドリフトを実行することが可能ですが、マネジメントコンソールから実施する場合、耐障害性を設定できないため、停止しているAWSアカウントが存在する場合、確実に処理が失敗します。(AWS CLIを使えば、耐障害性の設定が可能です。)

  • AWSアカウントを解約する際にOrganizationsの組織から抜けることも可能なため、実際に試してはないのですが、これを実施することでも問題は解決できる可能性はあります。 ただし、組織から抜ける場合、請求情報などを個別に設定する必要があるおよびOrganizationsの管理外になるため、おすすめはしません。

ポイント

  • OUはRootや別のOUへ移動することができなく、OU構成の変更は少し手間がかかるため、Organizationsを導入した段階で上記OUを導入することをおすすめいたします。

  • 既にOrganizationsを導入している場合、新規にOUを作成し、AWSアカウントを移動させることで対応可能です。

  • StackSetsを利用している環境でOU構成を変更する場合、StackSetsがどのOUを指定してデプロイしているか要確認です。 Root以外のOUを指定している場合、設定にもよりますが、OUを移動した際にStackSetsでデプロイしているリソースが削除されます。

備考

  • Foundation OUにアタッチしたSCPは、Suspended OUに反映されませんが、そもそも、Suspended OUには停止しているアカウントを格納するため、特に問題ないと考えております。
    また、Suspended OUのFullAccess(SCP)をデタッチすることも考えましたが、間違えてAWSアカウントのOUを移動した場合、移動したAWSアカウントの権限が全て失われ、何もできなくなるため、その影響が大きいと考え、辞めました。

終わりに

今回は、実際の運用に基づいたOU構成をご紹介いたしました。 もちろん、このOU構成が正しいという訳ではないため、実際の運用に基づいてOU構成をご検討いただければと存じますが、このOU構成が参考になれば幸いです。

また、今後も運用していく中でより最適なOU構成が探していきたいと思います。

それでは、またお会いしましょう。

福島 和弥 (記事一覧)

2019/10 入社

AWS CLIが好きです。