AWS Organizations連携サービス最新情報＆セットアップのコツ 第18回 AWS Organizations関連の注目の最新アップデート

（12）作成した宣言型ポリシーを選択し、「ポリシーのアタッチ」ボタンをクリックします。

宣言型ポリシーの動作確認

それでは、宣言型ポリシーの動作確認もしていきましょう。上記の宣言型ポリシーをアタッチしたOU配下のAWSアカウントでEC2のサービスへ移動します。サイドメニューの「設定」をクリックします。

「データ保護とセキュリティ」タブの「IMDS デフォルト」の「管理」ボタンが無効化されていると思います。

EC2の宣言型ポリシーでは、EC2インスタンスレベルでのインスタンスメタデータの設定ではなく、AWSアカウントレベルでのインスタンスメタデータの設定であることに注意してください。インスタンスメタデータの優先順位はこちらに記載の通り、インスタンス起動時に設定したものが最も優先されるため、この宣言型ポリシーを適用するだけでは、完全にv1の利用を禁止することはできません。

インスタンスメタデータv1の利用を完全に禁止するには、サービスコントロールポリシーの利用が必要となります。本稿執筆時点におけるEC2の宣言型ポリシーでは、以下の6つの制御がサポートされています。

VPCブロックパブリックアクセス
シリアルコンソールアクセス
AMIブロックパブリックアクセス
許可されたANIの設定
インスタンスメタデータのデフォルト
スナップショットブロックパブリックアクセス

VPCブロックアクセス以外を適応すると、下記のようにアカウントレベルでの設定変更ができないように強制されます。

それでは、VPCブロックアクセスの挙動も確認してみましょう。まず下記のようにインターネットゲートウェイが存在するVPCを用意しておきます。

下記のようなインターネットの行きと戻りの両方を禁止する宣言型ポリシーを用意しておき、アタッチします。

少し待つと、「パブリックアクセスをブロック」がオンとなります。

またこの状態で新規にVPCを作成すると、作成後には必ず「パブリックアクセスをブロック」がオンとなり、適切に制御がされていることが確認できます。

筆者の考える各種ポリシーの使い分け

ここまでOrganizationsレベルでのアクセス制御の新機能であるリソースコントロールポリシーと宣言型ポリシーを紹介してきました。ではこれらのポリシーに加えてこれまでのサービスコントロールポリシーはどのように使い分けていくべきでしょうか。

筆者は本稿執筆時点では、急いで今までの制御方法（サービスコントロールポリシーやConfigルールなど）を変える必要はないと考えています。