Regional NAT Gatewayを使用している環境においてはVPC Block Public Accessをどのように設定すれば良いか確認してみた
Regional NAT Gatewayを使用している環境において、VPC Block Public Accessでどのように除外すれば良いのか気になる
こんにちは、のんピ(@non____97)です。
皆さんはRegional NAT Gatewayを使用している環境において、VPC Block Public Access(以降、VPC BPA)でどのように除外すれば良いのか気になったことはありますか? 私はあります。
VPC BPAとはVPCもしくはサブネット単位でインターネットへのインバウンド/アウトバウンド通信を制御する仕組みです。これを適切に設定することで、意図せずに通信できるようになる可能性を緩和することができるため、ガードレールのような印象です。
設定をする際には
- 双方向でブロック
- サブネットレベルで双方向、もしくはEgressで除外
とすることが多いのではないでしょうか。
双方向で除外の対象となるのはInternet facingのALBなどPublic Subnetのうちインターネットからのインバウンド通信が発生するサブネットです。
一方、Egressで除外するのはNAT Gatewayのようなインターネットへのアウトバウンド通信のみ発生するサブネットが対象です。
では、Regional NAT Gatewayの場合はどうでしょうか。
Regional NAT Gatewayはサブネットに紐づいていません。
VPC単位で制御するしかないでしょうか。
実際に試してみます。
いきなりまとめ
- VPC Block Public Accessを使用する場合は以下の対応が必要
- 双方向でブロックしている場合は、VPC単位でEgressの除外をする
- Ingressでブロックする
やってみた
実際にやってみます。
検証環境のVPCは以下のとおり、Public SubnetとRegional NAT Gatewayを介してインターネットへのアウトバウンドリクエストを投げれるPrivate Subnetが存在しています。

現在のVPC BPAは以下のとおり、双方向でブロックしており、全サブネットで双方向で除外をしています。

つまりは、全サブネットはルートテーブルやセキュリティグループなど、他の各種設定が正しく行われていれば自由にインターネット間と通信することが可能です。
このとき、Public Subnetに存在しているEC2インスタンスにSSM Session Managerで接続しようとしてみます。

はい、ping statusがオフラインになっていますね。
Regional NAT Gatewayにのみ効いていることを確認するために、Public SubnetにもEC2インスタンスを配置しましたが、こちらはping statusはオンラインでした。

EC2 Instance Connect EndpointでPrivate SubnetのEC2インスタンスに接続して、インターネットに抜けられるかも確認します。
$ hostname -i
10.0.152.102
$ ping 1.1.1.1 -c 4
PING 1.1.1.1 (1.1.1.1) 56(84) bytes of data.
--- 1.1.1.1 ping statistics ---
4 packets transmitted, 0 received, 100% packet loss, time 3104ms
$ dig ssm.ap-northeast-1.amazonaws.com +short
52.195.200.154
ということでRegional NAT Gatewayを介してのインターネットへの通信がVPC BPAで制御されていそうです。
VPC Reachability AnalyzerでEC2インスタンスから、SSMのサービスエンドポイントのIPアドレスへのパスを分析してみます。

Outbound traffic through an internet gateway is blocked due to the configuration of VPC Block Public Access at the account level. You can exclude vpc-0d18f26f4ca2dd1c5 from VPC Block Public Access if needed. Note that if you set an 'allow-egress' exclusion, you must have a NAT gateway in the VPC.と以下にもな説明とともに到達不可能であることが示されました。
除外を設定してみましょう。
Regional NAT Gatewayはサブネットに紐づいていないことから、VPC単位で除外するしかありません。
VPCレベルでEgressの除外をします。

除外されたことを確認します。

除外追加後に再度VPC Reachability Analyzerでパスを分析します。

何もエラーにならず、到達可能になりましたね。
SSM Session Managerからping statusを確認しましたが、こちらもオンラインになっていました。

SSM Session Managerで接続し、以下のようにインターネットと通信できることも確認しました。
$ ping 1.1.1.1 -c 4
PING 1.1.1.1 (1.1.1.1) 56(84) bytes of data.
64 bytes from 1.1.1.1: icmp_seq=1 ttl=53 time=2.67 ms
64 bytes from 1.1.1.1: icmp_seq=2 ttl=53 time=2.37 ms
64 bytes from 1.1.1.1: icmp_seq=3 ttl=53 time=2.43 ms
64 bytes from 1.1.1.1: icmp_seq=4 ttl=53 time=2.50 ms
--- 1.1.1.1 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3005ms
rtt min/avg/max/mdev = 2.370/2.493/2.672/0.113 ms
VPC単位でEgressの除外をする必要がある
Regional NAT Gatewayを使用している環境においてはVPC Block Public Accessをどのように設定すれば良いか確認してみました。
結論、以下と理解しました。
- 双方向でブロックしている場合は、VPC単位でEgressの除外をする
- Ingressでブロックする
双方向ブロックと除外を行うパターンについては、サブネット単位の除外と比べて制御の粒度が粗くなる点は意識しておくと良いでしょう。
とはいえ、VPC BPAはインターネットとの境界線となるコンポーネントが存在しているサブネットに対して作用します。そのため、VPC単位でのEgressの除外を設定したとしても、Egressのサブネット単位の除外 + Zonal NAT Gatewayの場合と実質的な影響範囲は変わらないように感じています。
意図せずインターネットに抜けてしまうことを回避したいのであれば、VPC BPAだけに頼るのではなく、Network Firewallで通信を制御したり、デフォルトゲートウェイとしてNAT Gatewayを指定されないようにルートテーブルをコントロールしたりする方が重要でしょう。
この記事が誰かの助けになれば幸いです。
以上、クラウド事業本部 コンサルティング部の のんピ(@non____97)でした!






