VPC ブロックパブリックアクセスの宣言型ポリシーを適用してみた
2025.02.19カスタマーサクセス部 運用支援チームのいたくらです。
はじめに
先月、今月と以下の宣言型ポリシー適用に関するブログを公開しました。
- 許可された AMI
- EC2 シリアルコンソールアクセス
- EBS スナップショットブロックパブリックアクセス
- AMI ブロックパブリックアクセス
今回は VPC ブロックパブリックアクセスの宣言型ポリシーの適用と挙動の変化を確認してみました。
前提
前提として、自分が検証した環境について補足します。
- AWS Organizations を有効化済みで、以下の OU 構成
- SandboxOU 配下には itkr_mem02（以降、アカウントA と表記）が存在
- AWS Control Tower は有効化していない
- 宣言型ポリシーは有効化済み
- 有効化手順はこちらを参照ください
- もしも本番環境で試そうとしている方は、宣言型ポリシーのアカウントステータスレポートを生成することをおすすめします
- 生成手順はこちらを参照ください
やってみた
宣言型ポリシーを作成する
AWS Organizations のサービスページより、「ポリシー」＞「EC2 の宣言型ポリシー」＞「ポリシーを作成」の順にクリックすると、以下のような入力画面が表示されます。
サービス属性は「VPC ブロックパブリックアクセス」を選択します。
ポリシー名、ポリシーの説明を入力します。
VPC ブロックパブリックアクセスの場合は、インターネットゲートウェイの状態を選択する箇所と、除外を許可 する / しない のチェックボックスがあります。
今回は インターネットゲートウェイの状態：進入をブロック 、除外を許可 しない （チェックボックスのチェックなし）で設定します。
ちなみに、インターネットゲートウェイの状態は 無効 / 進入をブロック / 双方向をブロック のいずれかを選択します。
- 無効：VPC ブロックパブリックアクセスを有効にしない
- 進入をブロック：VPC 内へ向かうすべてのパブリックインバウンドトラフィックがブロックされる
- 双方向をブロック：すべてのパブリックインバウンド/アウトバウンドトラフィックがブロックされる
最後にカスタムエラーメッセージを設定し、「ポリシーを作成」をクリックします。
※ カスタムエラーメッセージは日本語で設定したらエラーが出たので、英語で設定しましょう
作成が完了すると、利用可能なポリシー一覧に表示されます。
宣言型ポリシーをアタッチする
作成した宣言型ポリシーを SandboxOU にアタッチします。
作成した宣言ポリシーの詳細画面の「ターゲット」タブに、ポリシーをアタッチした SandboxOU が表示されていれば OK です。
宣言型ポリシーによる挙動の変化を確認する
■ 宣言型ポリシー アタッチ前
SandboxOU 配下にある アカウント A のパブリックサブネット上に、パブリック IP アドレスを持つ EC2 を起動します。
以下のようなセキュリティグループをアタッチし、0.0.0.0/0 から ICMP を許可します。
ローカル端末でコマンドプロンプトを開き、EC2 に対して ping を飛ばしてみます。
C:\Users\xxxx>ping 13.231.xxx.xxx
13.231.xxx.xxx に ping を送信しています 32 バイトのデータ:
13.231.xxx.xxx からの応答: バイト数 =32 時間 =21ms TTL=120
13.231.xxx.xxx からの応答: バイト数 =32 時間 =26ms TTL=120
13.231.xxx.xxx からの応答: バイト数 =32 時間 =27ms TTL=120
13.231.xxx.xxx からの応答: バイト数 =32 時間 =20ms TTL=120
13.231.xxx.xxx の ping 統計:
パケット数: 送信 = 4、受信 = 4、損失 = 0 (0% の損失)、
ラウンド トリップの概算時間 (ミリ秒):
最小 = 20ms、最大 = 27ms、平均 = 23ms
C:\Users\xxxx>
EC2 に付与されているパブリック IP アドレスを使用して通信できることが確認できます。
■ 宣言型ポリシー アタッチ後
宣言型ポリシーアタッチ後、再度ローカル端末から ping を飛ばしてみます。
C:\Users\xxxx>ping 13.231.xxx.xxx
13.231.xxx.xxx に ping を送信しています 32 バイトのデータ:
要求がタイムアウトしました。
要求がタイムアウトしました。
要求がタイムアウトしました。
要求がタイムアウトしました。
13.231.xxx.xxx の ping 統計:
パケット数: 送信 = 4、受信 = 0、損失 = 4 (100% の損失)、
C:\Users\xxxx>
宣言型ポリシーのアタッチ以外 AWS 側の変更は加えていませんが、通信できない状態となったことが確認できます。
ちなみに、いま除外設定は 除外を許可しない としているので、アカウント A の VPC の設定ページ（https://ap-northeast-1.console.aws.amazon.com/vpcconsole/home?region=ap-northeast-1#Settings:）で除外を作成しようとすると、「この機能は、宣言型のポリシーにより管理されています。」と表示されるようになっていました。
その下の「除外を作成」はクリックできそうじゃん？と思いましたよね。
私もそう思ってクリックしてみたら除外を作成する画面に遷移できたので、必要な項目を入力して除外を作成してみましたが、エラーとなり作成できませんでした。
■ 除外設定を許可するを試してみる
管理アカウント上で、宣言型ポリシーの編集画面を開き、除外を許可のチェックボックスにチェックを入れて、変更を保存します。
アカウント A で除外設定を作成します。
先ほどグレーアウトになっていた「除外を作成」が有効になるので、こちらをクリックします（下にある方でも問題ないです）。
名前、インターネットゲートウェイの許可方向、許可するリソースを選択し、「除外を作成」をクリックします。
「作成が進行中」と表示されるので、少し待ちます。
1～2 分後、アクティブになりました。
再度ローカル端末から ping を飛ばしてみます。
C:\Users\xxxx>ping 13.231.xxx.xxx
13.231.xxx.xxx に ping を送信しています 32 バイトのデータ:
13.231.xxx.xxx からの応答: バイト数 =32 時間 =18ms TTL=120
13.231.xxx.xxx からの応答: バイト数 =32 時間 =8ms TTL=120
13.231.xxx.xxx からの応答: バイト数 =32 時間 =7ms TTL=120
13.231.xxx.xxx からの応答: バイト数 =32 時間 =8ms TTL=120
13.231.xxx.xxx の ping 統計:
パケット数: 送信 = 4、受信 = 4、損失 = 0 (0% の損失)、
ラウンド トリップの概算時間 (ミリ秒):
最小 = 7ms、最大 = 18ms、平均 = 10ms
C:\Users\xxxx>
除外設定が適用されて、ポリシーをアタッチしていないときと同様に通信できるようになりました。
カスタムエラーメッセージを確認してみる
アカウント A にて CloudShell を起動して、以下コマンドを実行して確認します。
~ $ aws ec2 describe-vpc-block-public-access-options
{
"VpcBlockPublicAccessOptions": {
"AwsAccountId": "5XXXXXXXXXXX",
"AwsRegion": "ap-northeast-1",
"State": "update-complete",
"InternetGatewayBlockMode": "block-ingress",
"Reason": "Organization Change",
"LastUpdateTimestamp": "2025-02-19T07:50:31.764000+00:00",
"ManagedBy": "declarative-policy",
"ExclusionsAllowed": "allowed"
}
}
~ $
~ $ aws ec2 modify-vpc-block-public-access-options --internet-gateway-block-mode off
An error occurred (DeclarativePolicyViolation) when calling the ModifyVpcBlockPublicAccessOptions operation: This functionality has been disabled by a Declarative Policy. Custom Message: This action was denied by the declarative policy: test-vpc-block-public-access-dp
~ $
aws ec2 describe-vpc-block-public-access-options で このアカウントの VPC ブロックパブリックアクセスのステータスを確認できます。
上記の実行結果より「宣言型ポリシーによって管理されていて、パブリックインバウンドトラフィックをブロックしている」ということが分かります。
aws ec2 modify-vpc-block-public-access-options --internet-gateway-block-mode off で VPC ブロックパブリックアクセスを無効に変更しようとすると、エラーメッセージが表示されて実行できません。
「Custom Message:」以降の文章が、先ほど宣言型ポリシー作成時に入力したカスタムエラーメッセージになっていることが分かります。
また、除外設定が許可されていないときに除外を作成しようとした際のエラー画面にも、カスタムエラーメッセージが表示されていました。
さいごに
VPC ブロックパブリックアクセスの宣言型ポリシーの適用と挙動の変化を確認してみました。
Direct Connect 接続等の閉域網を絶対に利用しなければならないなど、パブリックな通信が可能な状態が認められない環境の場合はこのポリシーが有用だと思いました。
また、この設定はパブリックな通信に影響が出るため、本番環境で設定する際は影響を受ける通信が存在しないか事前に AWS 環境を調査することをおすすめします。
この記事がどなたかのお役に立てれば幸いです。
アノテーション株式会社について
アノテーション株式会社はクラスメソッドグループのオペレーション専門特化企業です。
サポート・運用・開発保守・情シス・バックオフィスの専門チームが、最新 IT テクノロジー、高い技術力、蓄積されたノウハウをフル活用し、お客様の課題解決を行っています。
当社は様々な職種でメンバーを募集しています。
「オペレーション・エクセレンス」と「らしく働く、らしく生きる」を共に実現するカルチャー・しくみ・働き方にご興味がある方は、アノテーション株式会社 採用サイトをぜひご覧ください。
![[アップデート] AWS Elastic Beanstalk が Windows Server 2025 / Windows Server Core 2025 をサポートしました](https://images.ctfassets.net/ct0aopd36mqt/wp-thumbnail-2a940a5c003faa8b46bee141357d4855/6f3d6855be0706e2bd41c5033f53469f/aws-elastic-beanstalk)
