いう二つのメンバーアカウントが追加されています。デフォルトでは、アカウントは組織のルート直下に配置されます。次の図に示されている通り、ルートとは組織構造のベースで、全ての組織単位(OU)やアカウントはそこから分岐します。コマンドで、組織内の全てのアカウントを参照できます。コマンドは、アカウント一覧とどのように組織に参加したかの詳細を返します。マスターアカウントはメンバーアカウントと一緒の組織であることに注意してください。アクセスできるかを統制できます。設定しようとしています。ポリシーと連携して動作することに注意してください。ポリシーを設定することも可能です。制限されたポリシーの組み合わせを実施します。適用のされ方は、マスターアカウントとその他のアカウントで異なります。マスターアカウントには適用されません。ポリシーを作成します。アクセスを許可します。中身は以下の通りです。ポリシーと同じ構造に従います。ポリシーも同様に記述できます。コマンドは作成されたポリシーを返します。保存しておいてください。}}ポリシーのアタッチポリシーを作成した後は、組織のエンティティにそれをアタッチします。ルートアカウントにも、組織単位(OU)にも個々のアカウントにもアタッチできます。アカウントは組織ツリーの上位にある全てのポリシーを継承します。組織全体に適用するためルートにポリシーを適用しましょう。ルートは組織ツリーの最上位要素のため、ツリーに適用されたポリシーは組織の全メンバーに適用されます。取得する必要があります。p-yyy12346それではルート上のポリシーを確認してみましょう。呼び出すと、組織のルートにアタッチされている全てのポリシーが表示されます。いう二つのポリシーが返されました。管理ポリシーで、組織内で全ての要素にデフォルトで適用されています。削除しなければなりません。サービスアクセスへのアクセスを許可しています。削除する必要があります。これを以下のように行います。一つになったことが確認できます。規制に準拠したサービスに制限することで、保護を強化することできました。組織を更に細分化したなら、組織単位とポリシーを追加することもできます。必要ないことになります。サービスを試す必要がある開発チームがいるとします。この場合、規制された顧客情報にアクセスできるアカウントよりも、これらのアカウントの統制を緩くすることになるでしょう。あれば、たとえば本番環境で稼働させる医療ソフトウェアを扱う組織単位(OU)を作成する一方、開発者アカウントを有する組織単位(OU)も作成することができます。すれば、それぞれの組織単位(OU)に異なるセキュリティの制限を適用できます。組織単位(OU)に3つの開発者アカウントが示されています。組織単位(OU)にいます。組織単位(OU)にアタッチしました。ポリシーに配置することでルートレベルで引き続き有効となっています。