脱レガシーで変化に強い基幹システムの基盤を実現
Azureクラウドへの移行で、俊敏な経営と業務改革を支える
はじめに
こんにちは。クラウド活用推進担当 榊原です。今回もよろしくお願いします。
先日「パブリックサブネット無しでもWebサイト構築できる」という話を小耳にはさみ、
本当にできるのか気になったので試してみました。
私の思い描くよくあるWebシステム構成は、ALBや踏み台がパブリックサブネットに置かれ、
そこが外部公開点になるものです。
これをプライベートサブネットだけで完結できるなら、
公開面を減らせてセキュリティ的にとってもハッピーです。
というわけで、実際に構成を整理してみました。
目次
- パブリックサブネットがあるWebシステム
- パブリックサブネットありの問題
- パブリックサブネット、無くしたくないですか？
- プライベートサブネットのみのWebシステム
- プライベートサブネットだけで構成するためのコア技術
- 比較
- まとめ
- 参考
パブリックサブネットがあるW/ebシステム
構成例
あくまで例ですが、今回は上記のような構成を考えてみます。
この構成は、主に以下の3つの通信経路に分解することができます。
1. 一般ユーザがVPC内のWebリソースを閲覧するための経路
インターネットからCloudFrontにアクセスし、CloudFrontはオリジンとしてパブリックなALBを指定することで、コンテンツ配信を行います。
2. プライベートサブネット内のリソースがインターネットへ通信する経路
プライベートサブネット内のEC2インスタンスが、同じAZ内にあるパブリックサブネットに配置されたNAT Gatewayを利用してインターネット通信を行います。
インスタンス内のパッケージ更新や外部APIアクセスなど、アウトバウンドな通信の際に使われます。
3. 管理者 → プライベートリソース
管理者が、リソースの管理や運用のためにプライベートサブネット内のリソースにアクセスする経路です。
踏み台サーバを用いてSSH等でプライベートリソースにアクセスします。
パブリックサブネットありの問題
ここからは、パブリックサブネットを含む構成にすることで発生する問題点を整理します。
攻撃面の問題
インターネット向けALBや踏み台サーバは、外部から直接アクセス可能なリソースです。
公開リソースが増えるほど、設定ミスや脆弱性の影響範囲が大きくなります。具体的には以下のような懸念があります。
・ALBや踏み台が外部公開になり、攻撃対象が増える
・公開範囲が広がるほど、セキュリティ設定の管理コストが増える
経路の問題
今回の構成ではCloudFrontを利用してコンテンツ配信を行っています。
こうした構成の場合、入り口をCloudFrontだけに限定し、オリジンであるALBへはアクセスできないようになっていることが理想的です。
しかしALBが公開リソースなため、何かしらの対策が必須になります。
WAFやALB側の制限、IP制限などで対処できますが、制限を設計・運用する負荷が発生してしまいます。
・CloudFront経由に限定したいのに、ALB直アクセスの経路が残る
・直アクセス制限のための追加設定（運用負荷）が必要
踏み台サーバの管理負荷
踏み台は管理上便利ですが、公開点が増えるという意味ではデメリットもあります。さらに運用面では、サーバ管理やSSH鍵管理などの負荷につながります。
・踏み台が攻撃面の一部になる
・SSH鍵の管理など、認証方式に合わせた管理が必要
・パッチ適用などサーバ自体の管理が必要
コスト面の問題
パブリックサブネットを持つ構成は、公開リソースに起因するコストが目立ちやすくなります。特に分かりやすいのが公開IPv4と踏み台サーバです。
・公開IPv4アドレスに対する課金が発生する
・踏み台サーバの常時稼働により、インスタンス費用や運用コストが発生する
パブリックサブネット、無くしたくないですか？
ここまででパブリックサブネットに起因する問題をいくつか見てきました。
ここで挙げたものはあくまで一例であり、他にも様々な問題があることと思います。
そんなパブリックサブネット……無くしたくないですか？
プライベートサブネットのみのWebシステム
目指すゴール
ここまでの問題は共通して、外部公開のリソースが増えることで発生しています。
対策として、入口をCloudFrontに限定し、ALBや踏み台サーバなど外部公開リソースを極力減らす構成を目指します。
そのために、内部の構成はすべてプライベートサブネットに閉じ、外向きの通信や管理の経路も別の仕組みで確保します。
それを踏まえ、今回は次のような構成にしてみました。
構成例
プライベートサブネットだけで構成するためのコア技術
ここからは、上記構成を実現するために使用した重要な3つのサービスを紹介します。
CloudFront VPCオリジン
1つ目はCloudFrontの VPCオリジン という機能です。
この機能を使うことで、CloudFrontのオリジンとしてVPC内のプライベートリソースを直接指定できます。
指定可能なオリジンは Internal ALB / Internal NLB / EC2 の3種類です。
設定手順
1. VPCオリジンの設定からプライベートサブネット内のリソースを指定して作成
2. ディストリビューション構成時に作成したVPCオリジンを選択
メリット
従来の CloudFront + Internet-facing ALB の構成では以下のような課題がありました。
・オリジン(ALB)が外部公開している
・オリジンへの直アクセスを制限するための対策が別途必要
こうした課題が、VPCオリジンを利用することで、
・オリジンをプライベートサブネット内に配置
・入り口をCloudFrontに固定できる
・オリジンへの直アクセス対策のための追加実装不要
上記のように改善できます。
注意点
注意点として以下のものが挙げられます。
・VPCにインターネットゲートウェイが必要
VPCオリジン作成の際にインターネットゲートウェイが作成されたVPCでないと選択できないようになっています。
VPCオリジンの通信がインターネットゲートウェイを経由するわけではありませんが、そのVPCがインターネット通信可能であることを示すために必要なんだそうです。
・CloudFrontの料金プラン条件
CloudFront VPCオリジンを使用するためには、CloudFrontの料金プランで
- ビジネスプラン以上
- 従量課金プラン
のどちらかを選択する必要があります。
フリープランなどでは使用不可の機能である点には注意が必要です。
Regional NAT Gateway
2つ目は、Regional NAT Gatewayです。
Regional NAT Gatewayは、VPC単位で配置できるNAT Gatewayです。
NAT Gatewayのためのパブリックサブネットを作らずに利用可能です。
設定手順
1. NAT Gateway作成時に、リージョナルを選択することで作成できます。
メリット
従来のNAT Gatewayでは以下のような課題がありました。
・AZごとにNAT Gatewayを作成
・NAT Gatewayを配置するためにパブリックサブネットが必要
・ゾーンが増えるとルートテーブルが複雑に
・ワークロードが増えるたびに作成や設定が必要
こうした課題が、Regional NAT Gatewayを利用することで、
・VPC単位で1つのRegional NAT Gatewayを用意すればいい
・NAT Gatewayのためのパブリックサブネット不要
・ルートテーブルがシンプルに
・ワークロードに応じて自動でスケーリング
上記のように改善できます。
パブリックサブネット不要になったことによるセキュリティ向上だけでなく、運用負荷も軽減されます。
注意点
注意点として以下のものが挙げられます。
・プライベートNATは非対応
現時点(2026年1月)ではプライベートNAT非対応なため、原則としてRegional NAT Gatewayを通る通信はインターネットゲートウェイに向かいます。
プライベートNATを使用する必要がある場合は、従来のNAT Gatewayを使用しましょう。
・課金はAZの数だけ
Regional NAT Gatewayはワークロードに応じて自動でスケーリングしますが、
スケーリングしたAZの分だけ課金対象となるという点には注意が必要です。
Systems Manager Session Manager
最後が、Systems Manager Session Managerです。
Session Managerを使うことで、ブラウザやAWS CLIからプライベートサブネット内のリソースに接続できます。
VPCエンドポイントを利用すれば、インターネットを介さずに接続することができます。
設定手順
1. EC2がSSMにアクセスするためのIAMロールを作成
2. VPCエンドポイントを作成
必要なエンドポイントは
・com.amazonaws.ap-northeast-1.ssm
・com.amazonaws.ap-northeast-1.ssmmessages
の2つ
3. セキュリティグループを設定し、EC2にIAMロールをアタッチ
4. EC2の接続からSSM Session Managerのタブを選んで接続
メリット
踏み台サーバを使用した構成では、以下のような課題がありました。
・サーバ管理やSSH鍵の管理などにより運用負荷が高い
・踏み台サーバへパブリックアクセスできる必要がある
・ログ取得の仕組みを別途構成する必要がある
・ログインできるユーザをSSH鍵やOSレベルで管理
こうした課題が、Systems Manager Session Managerを利用することで、
・踏み台サーバ不要、SSH鍵管理不要、インバウンドポート開放不要
・マネージドサービスで運用負荷が軽減
・VPCエンドポイントを使用してインターネットを介さずに接続
・パブリックサブネットが不要に
・AWSネイティブなサービス(CloudWatchやCloudTrail)で監視・ログ取得
・アクセス可能なユーザをIAMで管理
上記のように改善できます。
踏み台サーバと異なりマネージドサービスであるため、他のAWSサービスとの連携もスムーズです。
注意点
注意点として以下のものが挙げられます。
・接続先ノードにSSM Agentが必要
Session Managerで接続するためには、接続先ノード(今回はEC2インスタンス)にSSM Agentがインストールされている必要があります。
EC2の場合、Amazon Linux等主要なAMIにはプリインストールされていることも多いですが、別途インストールが必要な場合もあるため確認が必須です。
比較
最後に、
・パブリックサブネットありのWebシステム
・プライベートサブネットのみのWebシステム
の比較をしたいと思います。
あくまで今回の構成例での比較になる点にはご注意ください。
| 観点 | パブリックサブネットあり | プライベートサブネットのみ |
|---|---|---|
| セキュリティ | △ 直アクセス制御など公開経路の管理が必要 |
◎ 入口をCloudFrontに寄せて オリジンをプライベートに置ける |
| 運用負荷 | △ 踏み台/SSH管理や直アクセス制限が必要 |
◎ 踏み台等の管理や直アクセス制限の別途実装が不要 |
| コスト | △ 公開系リソースの常時コストが発生 |
△ マネージド機能選択に伴う追加コスト |
| パフォーマンス | ○ 今回の構成では大きな差はなし |
○ 今回の構成では大きな差はなし |
| 監査・ガバナンス | △ OS/踏み台ログの取得・集約設計が必要 |
◎ SSMはログ収集系サービスとネイティブに接続 |
| 拡張性 | ○ Zonal NAT GWをAZごとに配置して 段階的に拡張可能 |
○ Regional NAT GWにより 追加のネットワーク設計負荷が小さい |
まとめ
・CloudFront VPCオリジン
・Regional NAT Gateway
・Systems Manager Session Manager
以上のサービスを利用し、パブリックサブネット無しで、攻撃面が少ないWebサイトを公開できる構成を実現できました。
セキュリティ面の強化ができることがもっとも大きなメリットだと思います。
安全なWebシステムを構築したいという方にとって少しでも有益であれば幸いです。
ここまで読んでいただき、ありがとうございました。
参考
・Amazon CloudFront VPC オリジンを使用したアクセス制限
・Regional NAT gateways for automatic multi-AZ expansion
・AWS Systems Manager Session Manager