Amazon VPCのパブリックサブネットからプライベートサブネットへの移行に向けて検討しておきたいこと

【復習】2025年末のアップデートの概要

2025年末において、インターネットとAmazon VPCとの接続周りにおいては下記のようなアップデートがありました。

• Amazon CloudFront が VPC オリジンのクロスアカウントサポートを発表
• AWS NAT ゲートウェイがリージョン別の可用性をサポート
• Amazon API Gateway の REST API が Application Load Balancer とのプライベート統合をサポート

他にもNetwork FirewallのProxy機能（プレビュー）やCloudFrontによる相互TLSなどインターネットとVPC間の接続点における機能アップデートが多数ありましたが、本コラムでは省略いたします。

これらのアップデートによりVPCの利用状況にもよりますがインターネット接続が必要であってもパブリックサブネットを使わない構成を検討できるようになってきました。

AWSのネットワーク設計に関するご相談、お悩みなどありましたらNTT東日本のクラウドエンジニアがご相談にお応えします。お気軽にお問い合わせください。

【復習】パブリックサブネットとは？

ここで、簡単にパブリックサブネットについて復習しておきましょう。

パブリックサブネットとは、VPC内のサブネットで、インターネットゲートウェイに対して直接ルートテーブルが設定されたサブネットとなります。パブリックIPアドレス（グローバルIPアドレス）が付与されているかは問われません。

AWSの基本的な構成としては、パブリックサブネットにNATゲートウェイやALB、踏み台サーバーなどを配置し、ほかのリソースをプライベートサブネットで構築する、ということが行われていました。

しかしながら、先日のアップデートによりリージョナルNATゲートウェイが追加され、ALBをプライベートサブネットに配置し、CloudFrontによるVPCオリジン構成といった形を行うことでパブリックサブネットを利用しない構成が実現できるようになります。

パブリックサブネットを利用しないメリット

パブリックサブネットを利用しないメリットは、セキュリティとコストの2点となります。

セキュリティ観点

インターネットに直接接続可能なネットワークを持たないことで、VPCに構築されたリソースへのネットワーク層での到達性を防止できることと、インターネットへ直接公開したくないリソースを誤ってパブリックサブネットに配置することを防ぐことができるようになります。

また、パブリックIPアドレスを持った状態で不要なポートやアドレスからの利用を可能にしていた場合、そこが攻撃者のポイントとなり全体への波及リスクを伴うため必要最小限にしておく必要があります。

コスト観点

パブリックサブネット自体の利用料金はかかりませんが、パブリックIPv4アドレスの利用料金がかかります。これは通信していなくても課金されているため、できるだけVPCで保持しているパブリックIPv4アドレスを減らしていくのがポイントとなります。

AWSのネットワーク設計に関するご相談、お悩みなどありましたらNTT東日本のクラウドエンジニアがご相談にお応えします。お気軽にお問い合わせください。

移行検討時に考慮すること

では、具体的にパブリックサブネットをプライベートサブネットに移行していくにあたり検討する項目を考えてみたいと思います。

通信方向（Amazon VPC⇔インターネット）ごとに各観点を考えてみたいと思います。

Amazon VPCからインターネットへの通信（Egress方向）

Egress方向の通信については、各パブリックサブネットに配置されたNATゲートウェイをリージョナルNATゲートウェイに置き換えることができるかどうか？の観点になります。

リージョナルNATゲートウェイは個別のサブネットにはおかれず、インターネットゲートウェイの手前に置かれる形となります。

通信経路

これまでNATゲートウェイ経由だった通信がリージョナルNATゲートウェイとなります。そのため、ルートテーブルをリージョナルNATゲートウェイ経由に変更する必要があります。

これまで各アベイラビリティーゾーンにNATゲートウェイを構築していた場合は各アベイラビリティーゾーンのNATゲートウェイを使っていたように、基本は同じアベイラビリティーゾーンからインターネットへ通信します。万が一、いずれかのアベイラビリティーゾーンのNATゲートウェイで障害があった場合も、AWS側で対応を行うためルートテーブルを変更することなく通信させることが可能です。

コスト

コストについては、改めての検討が必要です。公式の料金ガイドにこのような記載があります。

VPC でリージョンレベルでの可用性を備えた NAT ゲートウェイを作成する場合、各アベイラビリティーゾーンで NAT ゲートウェイが設定されている各時間について課金されます

引用：Amazon VPC の料金

VPCで利用しているすべてのアベイラビリティーゾーンでNATゲートウェイの課金が行われるため、これまでNATゲートウェイをすべてのアベイラビリティーゾーンで利用していた場合は変わりませんが、単一のサブネットに集約していた場合など一部のアベイラビリティーゾーンに構築していた場合は改めてコスト計算が必要となります。

インターネットからAmazon VPCへの通信（Ingress方向）

Ingress方向については、主に2点の変更を検討することになります。

• ALB経由の通信
• 踏み台サーバーを利用した通信

通信経路

インターネットからの接続点はCloudFrontが担うことになります。CloudFrontを使い、VPCオリジンを使って内部ALBへ接続します。

また、踏み台サーバーについてはSystems Manager Session ManagerやEC2 Instance Connect Endpointへの変更を検討します。EC2への接続が管理トラフィックのみであり、データ転送を行っていない場合は変更を検討したほうが良いでしょう。

セキュリティ

CloudFrontのセキュリティ要件を改めて検討する必要があります。TLS1.3対応やAWS WAFによるWebACL、ALBに対するセキュリティグループの見直しなど、最新のセキュリティレベルへのアップデートを行っておきましょう。

コスト

CloudFrontを使用していなかった場合は、CloudFrontの料金が追加となります。ただ、小規模なアクセスの場合は、Freeプランも追加されているため、追加とならないケースもありアクセス数に応じて再度検討する必要があります。

踏み台サーバーの停止にあたり、EC2の利用料分の減額となります。EC2 Instance Connect Endpointの追加料金はかからないため、管理トラフィックのみであればパブリックサブネットを残す場合でも検討することをおすすめします。

AWSのネットワーク設計に関するご相談、お悩みなどありましたらNTT東日本のクラウドエンジニアがご相談にお応えします。お気軽にお問い合わせください。

パブリックサブネットを引き続き利用するケース

本日時点で下記に該当する要件が残る場合は、引き続きパブリックサブネットを使用することをおすすめします。

• Egress方向
  • Transit Gatewayを使い、インターネットへの通信を集約している場合
  • コスト都合でNATゲートウェイを1つのみ設置し、SPOFが許容できる場合
• Ingress方向
  • HTTP/HTTPS以外の通信が必要な場合（CloudFrontが利用できないケース）
  • NLBを使いパブリックIPアドレスを固定する必要となる場合
  • 踏み台サーバーを使って大量のデータ転送を行っている場合

まとめ

今回はパブリックサブネットからプライベートサブネットの移行検討を行ってみました。パブリックサブネットからの移行は単一のパターンではなく、個別のユースケースや通信要件に応じて検討する必要があります。

また、実際の移行作業においても通信停止の許容時間等、ネットワークの利用状況に応じて検討する必要があります。この辺りも実際の状況に合わせて検討したほうが良いでしょう。

NTT東日本では、AWSの構築保守だけではなく、ネットワーク設計なども含めたエンドツーエンドでのソリューション提供をおこなっております。AI時代における伴走支援もぜひ一緒に行わせていただければと思います。

経験値豊かなメンバーがご担当させていただきますので、是非お気軽にお問い合わせください！

AWSのネットワーク設計に関するご相談、お悩みなどありましたらNTT東日本のクラウドエンジニアがご相談にお応えします。お気軽にお問い合わせください。

• Amazon Web Services(AWS)および記載するすべてのAmazonのサービス名は、米国その他の諸国における、Amazon.com, Inc.またはその関連会社の商標です。