はじめに
AWSが登場した当初、AWS上のリソースは誰でもインターネット経由で接続可能なパブリックネットワーク上に配置されていました。
ネットワークの到達性というセキュリティ観点においては、インターネットと同じオープンな状態だったのです。
今では当然となっていますが、このオープンな状態からネットワーク区画を分断し、独立して利用可能としたサービスがVPC（仮想プライベートクラウド）です。
VPCで仮想的なネットワーク区画を区切ることで、AWS内の特定の場所（リージョン、アベイラビリティゾーン）において、サービス契約者のリソースに契約者自身だけがアクセスできることを実現しています。
VPCをインターネットと接続するためには、インターネットゲートウェイ、またはEgress-onlyインターネットゲートウェイをVPCにアタッチして経路を作成します。
このVPCとインターネット間の通信を強力に制御する、VPC Block Public Accessが利用可能となりました。
VPCとインターネット間のネットワーク到達性を、AWSアカウントのリージョン単位で制御することができます。
※執筆時点では、AWSアカウントのリージョン単位で設定する必要があります
※なお、近い将来Organizationsもサポートされ、OUへの一括適用も可能となるようです
このVPC Block Public Accessについて、構成図で見ていきたいと思います。
どこで制御がかかるのか
VPC Block Public Accessは、インターネットゲートウェイ、またはEgress-onlyインターネットゲートウェイを経由する通信のみを制御します。
構成図の右側にある、Direct Connect、Transit Gateway、VPN、Cloud WAN、Verified Accessなど、プライベート接続に関連する通信は制御されません。
Site-to-Site VPN、Client VPN、Verified Accessはインターネットを経由する通信となりますが、インターネットゲートウェイは経由しない、サービス個別のエンドポイントなどを経由した通信となります。
VPC Block Public Accessの制御対象とはなりません。
一方、CloudFront、Global Acceleratorなどインターネットゲートウェイを経由する通信は制御されます。
また、CloudFront VPC Originsについても、インターネットゲートウェイを経由するため制御対象となります。
CloudFront VPC Originsは、CloudFrontを経由して、プライベートサブネット内のALB、NLB、EC2などのリソース（オリジン）からコンテンツ配信が可能となる、VPC Block Public Accessと同時期に発表されたアップデートとなります。
CloudFront VPC Originsについては下記で紹介しておりますので、概要を把握したい方は下記をご確認ください。
これまでのネットワークアクセス制御との違い
これまでネットワークアクセス制御が可能であったSecurityGroup、NetworkACL、Network Firewallとの違いを見てみます。
VPC Block Public Accessは、インターネット間の全通信を制御可能な点が特徴となり、制御方向を双方向制御 or 受信（Ingress）のみ制御から選択します。
一方、細かな宛先IPやドメイン、ポート番号は制御できませんので、そのような要件がある場合は、既存のネットワークアクセス制御サービスを利用する必要があります。
| VPC Block Public Access | SecurityGroup | Network ACL | Network Firewall | |
|---|---|---|---|---|
| 制御対象 | インターネットゲートウェイを経由する通信 | アタッチしたリソース間の通信 | アタッチしたサブネット間の通信 | Network Firewallを経由する通信 |
| 制御方向 | 双方向 or 受信（Ingress）のみから選択 | 送信（Egress）、受信（Ingress）それぞれで個別ルールを設定 | 送信（Egress）、受信（Ingress）それぞれで個別ルールを設定 | 送信（Egress）、受信（Ingress）それぞれで個別ルールを設定 |
| 制御単位 | インターネット間の全通信制御 | IP、ポート番号での制御 | IP、ポート番号での制御 | IP、ポート番号での制御/ドメインベースでの制御 |
| Firewallタイプ | ステートフル（受信（Ingress）のみの場合）/ステートレス（双方向の場合） | ステートフル | ステートレス | ステートフル/ステートレス |
| OSIレイヤー | レイヤ3 | レイヤ3-4 | レイヤ3-4 | レイヤ3-7 |
| 料金 | なし | なし | なし | あり |
SecurityGroup、NetworkACL、Network Firewallなどで許可された通信であっても、VPC Block Public Accessが有効であれば通信はドロップされますので、予期しないインターネット間の通信を一元的にブロックできます。
なお、制御方向に受信（Ingress）のみを選択した場合は、受信トラフィックは全てドロップされます。
送信トラフィックは、NATGWまたはEgress-onlyインターネットゲートウェイを経由する通信のみが許可され、ステートフルとなりますので、戻り通信も自動的に許可されます。
VPC Block Public Accessを受信（Ingress）のみを指定して有効化する場合、NATGWを経由しない送信トラフィックも許可されると思ってしまいそうですが、NATGWまたはEgress-onlyインターネットゲートウェイを経由する送信トラフィックのみが許可されます。IPv4においては、パブリックサブネットからNATGWを経由しない通信、IPv6においてはEgress-onlyインターネットゲートウェイを経由しない通信は全てブロックされる点には注意が必要です。
一部の通信は除外したい
セキュリティ製品のシグネチャアップデート、踏み台（Bastion）サーバーがどうしても必要など、特定の通信を除外することも可能です。
その場合は、VPCまたはサブネット単位で除外設定を行います。
次の図は、VPC AのPublic subnet 1、またVPC Bについて、それぞれサブネット単位、VPC単位で除外設定を行った場合のイメージとなります。
除外する場合は、除外する対象の制御方向を双方向 or 送信（Egress）のみから選択します。
この除外設定については、少し直感的に理解しづらい仕様となっているようです。
ひとつ事例を記載します。
VPC Block Public Accessを双方向を指定して有効化し、特定のパブリックサブネットのみインターネットアウトバウンド通信を許可したいケース
上記のケースの場合、特定のパブリックサブネットで送信（Egress）のみを選択し除外すればよいと考えられますが、Public subnet 1の送信（Egress）のみを除外設定した場合も通信はブロックされます。
今後仕様が変更となる可能性もありますが、事前にテスト環境での動作検証をしたうえで、本番環境に適用することが望ましいでしょう。
まとめ
構成図でVPC Block Public Accessを見てみました。
VPC Block Public Accessは、VPCのインターネットアクセスを一元的にブロックすることができるため、セキュリティとコンプライアンスの要件を容易に満たすことができます。
VPC Block Public Accessを有効化した後には、IAMを利用してVPC Block Public Accessへのアクセスは制御し、CloudTrailを利用してVPC Block Public Accessの無効化、除外設定の変更などをモニタリングすることが望ましいでしょう。
また、既存のVPCで有効化する場合は、必要な通信がブロックされてしまう可能性があります。
事前にNetwork Access AnalyzerやVPCフローログを用いて確認し、必要な要件があればサブネットやVPC単位で除外してからVPC Block Public Accessを有効化する必要があります。
除外設定は、少し直感的に理解しづらい仕様となっているようですので、事前の確認を行いましょう。
設定手順などの詳細については、下記をご確認ください。