はじめに：本記事の概要（TL;DR）
本記事では、パブリックサブネット不要なAWSのVPC構成を、インバウンドはCloudFront VPCオリジン、アウトバウンドはリージョナルNATGWを利用して実現しています。
そのうえで、VPCのネットワークセキュリティ機能の俯瞰と選定を軸に取り上げ、構成図と比較表で意思決定を支援することを目指しています。
こんにちは。
AWSのVPCからインターネットへ接続するために、パブリックサブネットが不要となったことをご存知でしょうか。
パブリックサブネットとは、インターネットGWへのルーティングが設定されており、インターネットと直接通信できる、到達性があるサブネットとなります。
下記2つのアップデートにより、パブリックサブネット不要でインターネットへ接続できるようになりました。
| 機能 | 一般提供された時期 | 通信方向とパブリックサブネット |
|---|---|---|
| CloudFront VPCオリジン | 2024年11月の アップデート |
CloudFrontを経由するインターネットからのインバウンド通信が パブリックサブネット不要で可能になった |
| リージョナルNATGW | 2025年11月の アップデート |
NATGWを経由するインターネットへのアウトバウンド通信が パブリックサブネット不要で可能になった |
CloudFrontがサポートするプロトコルは、HTTP/HTTPSのみです。
それ以外のプロトコルを利用するインバウンド通信要件がある場合は、パブリックサブネットが必要となります。
本記事では、これらの最新アップデートも含めたVPCのネットワークセキュリティ機能について、構成図と比較表で一覧化し見ていきたいと思います。
本記事では、各機能の詳細の紹介は対象外としています。
これは、「パブリックサブネットが不要となった、2025年12月時点の最新のVPCの構成、セキュリティサービスを俯瞰したい」読者を主なターゲットとしているためです。
各サービスの機能や特徴を比較し、構成図、一覧表にまとめることで、VPCのネットワークセキュリティサービスの構成や特徴を把握できることを目指しています。
ただし、比較的新しい次の3つのサービスについては、概要を本記事の中で確認いただける構成にしています。
1. CloudFront VPCオリジン
2. リージョナルNATGW
3. Network Firewall Proxy（本記事執筆時点でプレビュー）
より詳細を知りたい方は、各サービスのAWSブログを記載していますので、そちらを確認ください。
また、各セキュリティ機能については、比較表で各機能のポイントや差異を記載します。
対象とするVPCネットワークセキュリティ機能
本記事は、以下のVPCネットワークセキュリティ機能を対象とし一覧化します。
・NetworkACL
・SecurityGroup（SG）
・Network Firewall
・Gateway Load Balancer
・VPC Block Public Access
WAFやShield、IAMなどのセキュリティ機能は対象外としていますが、セキュリティは、複数の制御と組み合わせ多層構造で防御することが望ましいものです。
設計、管理負荷とのトレードオフとなりますが、可能な限り複数のサービスを用いた多層なセキュリティ対策を採ることが望ましいでしょう。
対象読者
本記事は、以下の方を対象読者として想定しています。
・パブリックサブネットが不要となった、最新（2025年12月時点）のVPCのセキュリティ機能を一覧で俯瞰したい方
・構成図でVPCのネットワークセキュリティ構成を理解したい方
・パブリックサブネット不要な構成で、VPCとインターネットを接続したい方
・VPCのネットワークセキュリティ機能の特徴や差異を一覧表で確認したい方
なぜパブリックサブネット不要が重要なのか
パブリックサブネットが不要となることで、なにが嬉しいのか、について見ていきます。
①セキュリティリスクの削減
これまでのパブリックサブネット構成では、インターネットGWを経由してVPCへ直接到達可能な状態でした。
結果として、予期しない通信やスキャン、DDoS攻撃といった外部からの脅威に直面するリスクが存在しました。
パブリックサブネット不要構成（CloudFront VPCオリジン＋リージョナルNATGW）により、インバウンド通信はCloudFrontを必ず経由し、アウトバウンド通信もNATGWで集約される構成となります。
これにより、インターネットからのランダムスキャンやDDoS攻撃が、VPC内リソースへ到達する前に遮断される可能性が大幅に高まります。
②運用コスト削減
従来のパブリックサブネット構成では、各AZごとにゾーナルNATGWをデプロイし、EIP（Elastic IP）を割り当て、ルートテーブルをAZ単位で管理する必要がありました。
一方、リージョナルNATGWは、AWSが自動でAZ拡張・縮退を行い、EIPもAWS自動割り当てオプションで管理できます。加えて、パブリックサブネット自体が不要になるため、サブネット数を削減でき、ルートテーブルやNACL、SGの管理対象を減らせます。
また、CloudFrontのオリジンとなるリソースには、EIPが不要になるため、EIPのコストが削減できます。
結果として、構成がシンプルになり、設定ミスのリスクや管理工数も削減できます。
③コンプライアンス要件の簡易化
多くのコンプライアンス基準（PCI-DSSなど）では、「インターネットからの直接到達性の最小化」や「ネットワーク分離の実装」が求められます。
パブリックサブネット不要構成により、「インターネットと接続するのはCloudFrontとNATGWの2つのエントリーポイントのみ」という明確な構造になり、アクセス制御やモニタリングの対象が絞られます。
これにより、セキュリティ監査時の説明責任が容易になり、コンプライアンス達成までのステップが簡潔化できます。
VPCとインターネットとの通信をパブリックサブネット不要とした2つのサービス
以下の2つが、VPCとインターネットとの通信にパブリックサブネットを不要としたサービスです。
- CloudFront VPCオリジン（インバウンドで利用。ただし、HTTP/HTTPSのみサポート）
- リージョナルNATGW（アウトバウンドで利用）
それぞれのサービスについて見ていきましょう。
CloudFront VPCオリジン
こちらは、2024年11月にGA (General Availability) された、インターネットからVPCへのインバウンド通信をパブリックサブネット不要で実現できるサービスです。
CloudFrontを経由して、プライベートサブネット内のALB、NLB、EC2などのリソース（オリジン）からコンテンツ配信が可能となりました。
それまでのCloudFrontを利用するケースでは、パブリックサブネットにリソース（オリジン）を配置する必要がありましたが、CloudFront VPCオリジンを利用することで、最小限の作業で以下が実現できます。
・パブリックIP、パブリックサブネット不要で、プライベートサブネットからインターネットにコンテンツが配信できる
・プライベートサブネット内のリソース（オリジン）へのアクセスは、CloudFront経由のみに制限できる
利用の流れは、まずVPCオリジンを作成し、次にそれをCloudFrontディストリビューションのオリジンに設定します。
VPCオリジンを作成すると、NW構成のコンポーネントとして以下2つのリソースが作成されます。
・CloudFrontマネージドのENIがオリジンのプライベートサブネットに作成される
・ENIへアタッチされる、CloudFrontマネージドのSecurityGroupも合わせて作成される
CloudFrontとオリジンは、このCloudFrontが作成したプライベートサブネット内のENIを経由して通信する経路となります。
プライベートサブネットには、このENIが利用するため、少なくとも1つのIPアドレスが必要です。プライベートIPとなるため追加コストはかからず、パブリックIP、パブリックサブネット不要でインターネットからのインバウンド通信をVPCに到達させることができます。
構成図でみると以下のようになり、パブリックサブネットは不要であることが分かります。
CloudFront VPCオリジンについてより詳しく知りたい方は、以下のAWSブログをご確認ください。
リージョナルNATGW
こちらは、2025年11月にGAされた、VPCからインターネットへのアウトバウンド通信をパブリックサブネット不要で実現できるサービスです。
NATGWを各AZのパブリックサブネットに構築することなく、AWSが自動で必要なAZに構築してくれるリージョナルNATGWを利用することで、プライベートサブネット内のリソースからインターネットに到達可能となりました。
まず、マネジメントコンソールでこれまでのNATGWとの違いを見ていきます。
これまでの利用者でVPC内のパブリックサブネットにデプロイするNATGWは「ゾーナル」と呼ばれるようになり、新たにGAされたNATGWは「リージョナル」と呼ばれます。
リージョナルNATGWが利用するパブリックIP（EIP）については、AWSが自動で割り当てる方法と、利用者が手動で割り当てる方法から選択できます。厳密なIP制限を行っている場合は手動を選択しましょう。
また、リージョナルNATGWは、AZ単位ではなくリージョン単位で管理されます。
これまでのゾーナルNATGWはAZごとにデプロイし、ルーティングも各AZのNATGWを設定する必要がありましたが、リージョナルNATGWではリソース（具体的にはENI）が存在するAZをAWS側で自動検出し、該当のAZでもNATGWが利用できるよう拡張されます（該当AZのNATGWが利用するEIPの割り当ても行われます）。
リソースが存在しなくなったAZのNATGWは縮退もされますし、リージョナルNATGWとして一意のIDを持つため、各AZのNATGWをルートテーブルで指定する必要もありません。
リージョナルNATGWのAZ拡張は、平均で15-20分程度、最大で60分程度の時間がかかるとされています。
本記事執筆時点では即時に拡張されるものではないため、実際にワークロードで利用される前に余裕を持って利用AZにリソースをデプロイするなどの注意が必要です。
リージョナルNATGWと、これまでのゾーナルNATGWとの違いは次の通りです。
まず、AWSドキュメントの構成図で見てみます。左がこれまでのゾーナルNATGW、右が新しいリージョナルNATGWです。
以下のように、右図のリージョナルNATGWは、パブリックサブネット不要でデプロイされ、一意のIDを持つことが分かります。
次に、リージョナルNATGWとゾーナルNATGWの差異について、表でまとめてみます。
| リージョナルNATGW | ゾーナルNATGW | |
|---|---|---|
| 管理 | リージョン単位 | AZ単位 |
| デプロイ方法 | AWSによる自動 | 利用者による手動 |
| AZへの拡張、縮退 | AWSによる自動 | 利用者による手動 |
| EIP割り当て | AWSによる自動 or 利用者による手動 | 利用者による手動 |
| 接続タイプ | パブリック | パブリック or プライベート |
| 料金 | 差異なし | 差異なし |
ゾーナルNATGWのプライベート接続とは、インターネットではなくオンプレミスや他のVPCとNATGWを経由して接続したい場合に利用します。
プライベート接続でゾーナルNATGWを経由させることで、オンプレミスや他のVPCから見た接続元のIPを集約し、固定化させることができます。
また、IP重複の回避にも利用できます。
料金に差異はなく、プライベート接続を利用する場合以外は、AWSからもリージョナルNATGWが推奨とされています。
また、リージョナルNATGWのEIP割り当てについては、AWSによる自動割り当てが推奨とされています。
ゾーナルNATGW、リージョナルNATGWの東京リージョンでの料金は以下で確認できます。
https://aws.amazon.com/jp/vpc/pricing/?nc1=h_ls
リージョナルNATGWについてより詳しく知りたい方は、以下のAWSブログを確認ください。
補足：Network Firewall Proxy
これまでのNetwork FirewallにはなかったProxy機能、セキュリティ強化機能を持ったサービスです。
本記事執筆時点では、オハイオリージョンでのみ利用可能なプレビュー機能でもあるため詳細は割愛しますが、いくつかのAWSブログの構成図を引用しながらポイントを記載します。
Network Firewall Proxyは、ゾーナルNATGWと直接統合される
Network Firewall ProxyはゾーナルNATGWと直接統合して提供されます。本記事執筆時点では、リージョナルNATGWとの統合はサポートされていません。
一方、ゾーナルNATGWはインターネットへのパブリック接続以外にも、オンプレミスや他VPCへのプライベート接続にも対応しています。
これまでEC2やECSでSquidなどをproxyとして利用していた利用者は、インターネット接続、プライベート接続ともにマネージドなNetwork Firewall Proxyへ移行できる可能性があります。
Network Firewall Proxyは、正規の宛先ドメイン、悪意のある宛先IPアドレスが指定された通信もブロックできる
Network Firewall Proxyの最も大きなセキュリティ強化ポイントは、これまでのNetwork Firewallではできていなかった、正規の宛先ドメイン、悪意のある宛先IPアドレスが指定された通信もブロックできることにあると考えられます。
これまでのNetwork Firewallにおける宛先ドメインを利用したフィルターは、HTTPではホストヘッダー、HTTPSではSNIの値に基づいて動作し、送信元が指定したIPアドレスはそのまま利用されます。
そのため、たとえばホストヘッダーを正規の許可されている宛先ドメインとして、宛先IPアドレスを悪意のあるサイトに設定された場合は通信を拒否することができませんでした。
このような通信を拒否するには、ファイアウォールが送信元の指定したIPを利用せず、自ら名前解決により通信先を決定し、名前解決した宛先IPを利用するプロキシサーバーや名前解決機能を備えたセキュリティアプライアンスを利用する必要がありました。
Network Firewall ProxyがGAされると、この課題が解消されることが期待されます。
Network Firewall Proxyは、送信元の指定したIPを利用せず、自ら名前解決により通信先を決定し、名前解決した宛先IPを利用する動作をします。
Network Firewall Proxyについて詳しく知りたい方は、以下のAWSブログを確認ください。
VPCのネットワークセキュリティ機能
ここから、これらの機能も踏まえたVPCのネットワークセキュリティ機能についてまとめていきます。
VPCとインターネット接続のセキュリティ
まず、VPCとインターネット接続のセキュリティ機能についてです。
CloudFront VPCオリジン ＋ リージョナルNATGWを組み合わせた構成図を見てみましょう。
パブリックサブネット不要で、インターネットとの送受信通信が可能となります。
これまでのパブリックサブネットを利用する構成と比較してみます。
CloudFront VPCオリジン ＋ リージョナルNATGWを利用することで、インバウンドはCloudFrontに集約し、アウトバウンドはリージョナルNATGWで管理対象を減らすことができます。
また、必要なリソース・コストを削減でき、インターネットからVPCへの到達性・セキュリティ・運用性を最適化することが可能となります。
| 項目 | パブリックサブネットを利用する構成 | パブリックサブネットを利用しない構成 （CloudFront VPCオリジン ＋ リージョナルNATGW） |
|---|---|---|
| パブリックサブネット | 必要（◯） | 不要（✕） |
| パブリックIP | 必要（◯） | 必要（◯） ※リージョナルNATGWで利用 |
| インターネットGW | 必要（◯） | 必要（◯） |
| セキュリティ | インターネットからの直接到達性あり | インターネットからの直接到達性なし |
| コスト | CloudFrontのオリジンに対して、パブリックIP（EIP）利用料金あり | CloudFrontのオリジンに対して、パブリックIP（EIP）利用料金なし |
| 構成、運用の複雑さ | 比較すると高い | 比較すると低い |
| コンプライアンス要件充足 | 比較すると難易度高 | 比較すると難易度低 |
CloudFront VPCオリジン、リージョナルNATGWの利用にはインターネットGWが必要です。
これは私見ですが、インターネット接続のあるVPCであることを明確にするため、また、後述するVPC Block Public Accessを利用可能とするため、であると考えます。
Lambdaについては、Lambda関数URL（Lambda Function URL）を利用することで、プライベートサブネットのLambdaもインターネットからアクセスさせることができます。
https://docs.aws.amazon.com/ja_jp/lambda/latest/dg/urls-configuration.html
なお、CloudFront VPCオリジン、リージョナルNATGWとは、インターネットGWが不要であるという点に差異があります。
こちらも私見ですが、インターネット接続ができるのにインターネットGWが不要という点の評判が良くなかったため、CloudFront VPCオリジンやリージョナルNATGWにはインターネットGWが必要、としたのかもしれません。
VPC内のネットワークセキュリティ機能
次に、VPC内のネットワークセキュリティ機能についてです。以下の機能を利用して多層防御が可能です。それぞれの機能について概要を記載します。
①Network ACL
アタッチしたサブネット間の通信を制御するサービスとなり、IPとポート番号を利用してステートレスで動作します。
②Security Group(SG)
アタッチしたリソース間の通信を制御するサービスとなり、IPとポート番号を利用してステートフルで動作します。ステートフルですので、戻りの通信定義は不要となります。
③Network Firewall
VPC内にNetwork Firewallのエンドポイントを設定し、エンドポイントを通じてNetwork Firewallを経由する通信を制御するサービスとなります。
IP、ポート番号での制御に加えて、ドメインベース、L3-7レイヤーのヘッダーなどでの制御が可能なマネージドなファイアウォールとなります。
④Gateway Load Balancer
Network Firewallと類似するサービスにGateway Load Balancer（GWLB）があります。
VPC内のサブネットにエンドポイントを作成しネットワークトラフィックを制御する点や構成は同じとなります。
異なる点は、エンドポイントの先のセキュリティアプライアンスがAWS提供のNetwork Firewallであるか、AWSパートナーである各ベンダーが提供するアプライアンスから選択可能であるかという点となります。
なお、GWLBで利用するアプライアンスはセキュリティアプライアンスベンダーが提供するVPCにあります。
⑤VPC Block Public Access
2024年11月に発表された比較的新しいサービスとなり、インターネットGWを経由する通信を制御するサービスとなります。
VPCとインターネット間の通信を強力に制御するサービスとなり、インターネットへのネットワーク到達性をAWSアカウントのリージョン単位で制御できます。制御する方向は、「双方向通信を制御」 or 「受信(Ingress) のみ制御」から選択でき、特定のVPCやサブネットを制御外としたい場合は、除外することもできます。
また、リージョナルNATGWを経由する通信でも利用可能です。
VPC Block Public Accessについては、過去に私が記載した記事もありますので、もう少し詳しく知りたい方は以下もご確認ください。
これら5つの機能を、CloudFront VPCオリジン ＋ リージョナルNATGWを利用した構成図で見てみましょう。
図を簡略化するため、プライベートサブネットは1つとしていますが、システム特性や要件に合わせて、ALBやターゲット、DBなどの単位でサブネットは分割してください。
また、Network Firewall、Gateway Load Balancerはインバウンド通信にも利用できます。
①Network ACL
リソースがサブネットをまたいで通信する場合に機能するサービスがNetwork ACLです。制御はステートレスとなるので、利用する場合は戻り通信も定義する必要があります。
管理負荷とのバランスを考慮して、リモートアクセスとなるSSHのみ多層防御として拒否設定を実装するなど、ポイントを絞って利用するケースが多いサービスと考えられます。
②Security Group(SG)
最もリソースに近い位置で機能し、ステートフルなネットワーク制御を提供するサービスはSecurity Group（SG）となります。EC2はもちろん、ALBやAurora、ENIなど多様なリソースに適用できます。IPアドレス指定ではなく、他のSecurity Groupを送信元や送信先に設定することで、対象のSecurity Groupをアタッチしているリソースがまとめて選択できる点も特徴となります。
③Network Firewall/④Gateway Load Balancer
レイヤー7までのきめ細かな制御やさまざまな通信を集約して制御したいケースではNetwork Firewallを利用し、AWSパートナーが提供するセキュリティアプライアンスで制御したい場合はGateway Load Balancerを利用しましょう。
⑤VPC Block Public Access
また、VPCのインターネットアクセスを一元的に制御したいケースは、VPC Block Public Accessを利用しましょう。
これらのサービスを組み合わせ、運用管理負荷とのバランスを考慮しつつ、可能な限り多層なネットワーク制御を検討頂ければと思います。
最後に、AWSのネットワーク制御サービスの比較表を記載します。それぞれのサービスの制御対象や機能、特徴を押さえておきましょう。
| 項目 | ①Network ACL | ②Security Group | ③Network Firewall | ④Gateway Load Balancer | ⑤VPC Block Public Access |
|---|---|---|---|---|---|
| 制御対象 | アタッチしたサブネットに出入りする通信 | アタッチしたリソース間の通信 | Network Firewallを経由する通信 | GWLBを経由する通信 | インターネットGWを経由する通信 |
| 制御方向 | 送信(Egress)、受信(Ingress)それぞれで個別ルールを設定 | 送信(Egress)、受信(Ingress)それぞれで個別ルールを設定 | 送信(Egress)、受信(Ingress)それぞれで個別ルールを設定 | アプライアンスに準ずる | 双方向 or 受信(Ingress) のみから選択 |
| 制御種別 | 許可、拒否 | 許可のみ | 許可、拒否(Drop/Reject)、通知 | アプライアンスに 準ずる |
拒否、拒否の除外 |
| 制御単位 | IP、ポート番号での制御 | IP、ポート番号での制御 ※他のSecurityGroupを送信元、送信先として設定することも可能 |
IP、ポート番号での制御、L3-7レイヤーのヘッダーなどでの制御 | アプライアンスに準ずる | インターネット間の全通信制御 |
| ファイアウォールタイプ | ステートレス | ステートフル | ステートフル/ステートレス | アプライアンスに 準ずる |
適用範囲が異なる ため該当なし |
| OSIレイヤー | レイヤー3-4 | レイヤー3-4 | レイヤー3-7 | レイヤー3-7 | レイヤー3 |
| 料金 | なし | なし | あり | あり | なし |
まとめ
パブリックサブネットを不要とできる、CloudFront VPCオリジン ＋ リージョナルNATGWを利用するケースにおいて、構成図と比較表でネットワークセキュリティ機能をまとめてみました。
AWSの設計思想であるパーパスビルドに基づき、今後も機能の追加やアップデートが行われていくと思われますが、2025年12月時点のVPC構成、ネットワークセキュリティ機能一覧として、ご参考にして頂ければと思います。
パーパスビルドとは、「1つの汎用的なツールで対応する」のではなく、それぞれの課題やユースケースに最も適した専用サービスやソリューションを提供するという、AWSの設計思想です。