Egressの経路設計 — フォワードプロキシとNATゲートウェイの選定

Egressの経路設計で最初に問うべきは「何を制御したいか」です。この問いを曖昧なままにして全通信をプロキシ経由にしようとすると、設計コストと運用コストが同時に膨らみます。フォワードプロキシはURLレベルの可視化と制御を提供し、NAT GWはシンプルなIPマスカレードで広帯域を捌きます。VPCエンドポイントはAWSサービス向けの内部経路として両者を補完する存在です。この3つの役割の境界を理解したうえで、セキュリティ要件・可視化要件・運用負荷のトレードオフを判断することが設計の核心です。

すべてのEgressをプロキシ経由にするかNAT GWで流すかの判断

NAT GWで足りるケースと足りないケースの切り分け

NAT GWは「送信元IPを固定して外部に出る」という要件に対して最もシンプルな回答です。APIキー認証やIPホワイトリスト登録が必要な外部SaaS連携、バッチ処理の大量データ転送など、通信の中身を検査する必要がないケースではNAT GWで十分です。一方、「どのホスト名に何のリクエストが飛んでいるか」を記録・制御したい場合や、ドメイン単位でのアクセス制御が必要な場合はNAT GWだけでは対応できません。判断の分岐点は「IPアドレスで制御できるか、URLで制御しなければならないか」という1点に集約されます。セキュリティポリシーがIP制御だけで完結するなら、プロキシを挟むことで発生する設計・運用の複雑さは不要なコストです。

プロキシ導入が割に合わない構成パターン

プロキシを全Egress経路に挟む設計がコストに見合わないケースがあります。よくある例として、10Gbpsを超える大容量データ転送が常時発生する環境でのプロキシ挿入が挙げられます。この構成ではプロキシがボトルネックになりやすく、スケールアウトの設計・運用コストがNAT GWの単純な帯域増強を上回ることがあります。また、LambdaやCloud Functionsのような短命な実行環境では、コールドスタート時にプロキシへの接続確立オーバーヘッドがレイテンシに直接影響します。プロキシが本当に必要な経路と不要な経路を分ける「選択的プロキシ」が現実的な設計です。

ハイブリッド構成（NAT GW+プロキシ）を選ぶ判断軸

多くの本番環境では、プロキシとNAT GWを併用するハイブリッド構成が採用されます。想定例として考えられるのは、アプリケーションの外部HTTP/HTTPS通信はプロキシ経由、DBバックアップや大容量ログ転送はNAT GW直通という経路分離です。この分離を実現するには、サブネット単位のルートテーブル設計か、アプリケーション側のHTTP_PROXY環境変数による制御が主な手段になります。ルートテーブルで分離する場合は「プロキシを経由させたいサブネット」を設計図に明示しておかないと、後からサブネットが追加されるたびに抜け漏れが発生します。どちらを選ぶかは「経路の分離をインフラ層で強制するか、アプリケーション層に委ねるか」という設計思想の問題です。

URLフィルタリングをどの層で担保するか

セキュリティグループ・NACLとプロキシのフィルタ能力の違い

セキュリティグループとNACLはIPアドレスとポート番号でのフィルタリングが限界です。TCP 443の通信がどのドメインに向いているかは検査できず、SaaS系サービスへのアクセス制御は実質不可能です。プロキシはHTTP CONNECTメソッドでターゲットのホスト名を受け取るため、ホスト名単位の許可・拒否リストを管理できます。「外部への通信先を承認済みドメインに限定する」というセキュリティ要件がある場合、プロキシの採用が設計の前提になります。セキュリティグループだけで対応しようとすると、SaaSが使うIPレンジの管理が際限なく広がる泥沼にはまります。

DNS-over-HTTPSとSNIフィルタリングの限界

SNIフィルタリングはTLSハンドシェイク中のServer Name Indicationフィールドを見てホスト名を判別します。プロキシなしでもL7スイッチや専用ゲートウェイでSNIベースのフィルタリングは可能ですが、Encrypted Client Hello（ECH）が普及するとSNI自体が暗号化されてフィルタリングが機能しなくなります。DNS-over-HTTPSも同様で、名前解決の経路が暗号化されるとDNSフィルタリングが無効化されます。将来の変化を見据えると、確実な制御手段としてプロキシによるURL検査が現時点では最も安定した設計です。SNIやDNSフィルタリングは補助手段として組み合わせることはできますが、主軸に据えると設計が短命になるリスクがあります。

プロキシでURLフィルタリングを設計する際の落とし穴

よくあるつまずきとして、URLフィルタリングの許可リストを初期設定時だけ作成し、その後の更新運用を設計しないケースがあります。SaaS製品はCDNドメインを頻繁に追加・変更するため、許可リストが古くなると正規の通信を遮断します。CloudFront・Fastlyのエッジドメインは製品ごとに異なり、定期的に変更されます。ワイルドカードを乱用してフィルタリングが形骸化するアンチパターンも一般的です。許可リストの追加申請フローと棚卸し頻度を設計段階で決めないと、プロキシが運用上の形式になり下がります。フィルタリングルールの「メンテナンス体制」を設計の一部として扱うことが重要です。

プロキシ経由TLS検査を入れるかの判断と設計

TLSインスペクションが必要な要件と不要な要件

TLSインスペクション（SSLインスペクション）はHTTPS通信の中身をプロキシが復号・検査してから再暗号化して転送します。DLPポリシーとして送信データの内容を検査する義務がある場合や、マルウェアのC2通信をペイロードレベルで検知したい場合に必要になります。一方、社内システムからAWS APIを呼ぶといった用途ではTLS検査は不要です。TLSインスペクションを全通信に適用すると処理負荷が大きく増加し、一般的な目安としてスループットが検査なしと比べて30〜50%程度低下するケースが多く、プロキシのサイジング見直しが必要になります。検査が必要な通信カテゴリと不要なカテゴリを分けた「選択的インスペクション」が設計の基本方針です。

証明書チェーンとトラスト配布の設計

TLSインスペクションを有効にすると、プロキシが自前のCA証明書でサーバー証明書を再発行します。クライアント側がこのCA証明書を信頼していないと証明書エラーが発生します。LinuxサーバーはOS信頼ストアへの追加が必要で、Python・Rubyなどの言語ランタイムは独自の証明書ストアを持つため個別対応が必要です。Dockerコンテナはベースイメージのビルド時にCAを組み込むか、実行時にボリュームマウントで渡す設計が一般的です。証明書の配布手段と更新手順を設計段階で決めておかないと、10台・50台・100台と展開が進むにつれて一貫性が崩れます。

certificate pinningが絡む場合の落とし穴

一部のAPIクライアントはcertificate pinningを実装しており、特定のCA・証明書だけを信頼するように設計されています。プロキシがCA証明書を差し替えると通信が失敗します。モバイルバックエンドAPIや金融系外部APIではcertificate pinningが多いため、TLSインスペクションの「除外リスト」設計が不可欠です。mTLSの場合はクライアント証明書の提示が求められるため、プロキシがmTLSをパススルーできる構成か終端できる構成かを事前に確認する必要があります。この見落としは本番移行後に発覚しやすく、影響範囲が広くなりがちです。除外リストの設計と更新運用もセットで計画してください。

PrivateLinkとVPCエンドポイントをNAT GWの代わりに使う設計

VPCエンドポイントが有効なサービス境界

VPCエンドポイントはAWSのサービス（S3・DynamoDB・ECR・SSM等）への通信をVPC内で完結させます。NAT GWを経由してインターネット越しにAWS APIを呼ぶ設計は、通信がAWSバックボーン外に出るためコンプライアンス上問題になることがあります。金融・医療系の要件では「データがインターネットを経由しない経路」を求められるケースが多く、S3・DynamoDBへのアクセスはゲートウェイ型エンドポイント、ECR・SSMはインターフェース型エンドポイントを使う設計が標準に近づいています。VPC内からAWSサービスに向けた通信は、原則としてエンドポイントで内部化できないかを先に検討するのが設計の順番です。

PrivateLinkとNAT GWのコスト設計上の判断

インターフェース型VPCエンドポイントはENIに紐づくコストが1アベイラビリティゾーンあたり発生します。複数AZに展開する場合はコストが乗算されるため、エンドポイント数×AZ数を試算してからNAT GWとの比較を行う必要があります。一方、NAT GWはデータ転送量に応じた課金があり、AWSサービスへの大量データ転送がある環境ではエンドポイントの方がコストを抑えられることがあります。想定例として月間100GB以上のS3転送が発生する環境では、ゲートウェイ型エンドポイント（データ処理費用なし）への切り替えを設計に含める価値があります。ただしこれは方向性の目安であり、実際の転送量を計測したうえで判断することが前提です。

エンドポイントポリシーによるアクセス制御の設計

VPCエンドポイントにはエンドポイントポリシーを設定でき、特定のS3バケットやDynamoDBテーブルへのアクセスのみを許可するといった細かい制御が可能です。NAT GW経由ではこのレベルのアクセス制御は実現できません。エンドポイントポリシーを活用することで「VPC内のEC2インスタンスは自組織のS3バケットにのみアクセス可能」というポリシーをインフラレベルで強制できます。ただし、エンドポイントポリシーとIAMポリシーは独立して評価されるため、両方を適切に設計しないと意図しない許可・拒否が発生します。エンドポイントポリシーを「デフォルト全許可」のまま放置するアンチパターンは一般的で、設計時に必ず絞り込む方針を決めておく必要があります。

コンテナ環境でEgress経路を統一する方法と落とし穴

EKS/ECSでのEgress経路統一パターン

KubernetesクラスターでEgress経路を統一する方法は大きく2つです。ひとつはノードレベルで透過型プロキシを動かし、全Podのoutboundをiptablesベースのアプローチで捕捉する方式です。もうひとつはPodにHTTP_PROXY環境変数を注入し、アプリケーションが明示的にプロキシを参照する方式です。前者はアプリケーション変更が不要ですが、TLS通信をiptablesで捕捉するには証明書配布が絡むため複雑になります。後者はシンプルですが、HTTP_PROXYを参照しないアプリケーション（一部のGoバイナリ等）が設計漏れになりやすいため、使用するランタイムのプロキシ対応状況を事前に一覧化する必要があります。

サイドカープロキシとノードレベルプロキシの選択

サイドカーパターンはPodごとにプロキシコンテナを配置し、Pod内のトラフィックを捕捉します。IstioのEnvoyサイドカーがこのモデルの代表例です。サービスメッシュとして導入する場合はEgressGatewayリソースを設計に加える必要があります。ノードレベルプロキシはDaemonSetとして1ノードに1プロセスを配置するモデルで、Pod数が増えてもプロセス数はノード数に比例するため管理が簡略です。数十ノード・数百Podが存在する環境での選択基準は「Podごとの独立した制御が必要か」という点に集約されます。独立制御が不要なら、ノードレベルプロキシの方が運用コストは低くなります。

サービスメッシュとEgress制御の重複問題

Istioなどのサービスメッシュとフォワードプロキシを併用すると、Egress制御の責務が重複します。ServiceEntry・VirtualService・フォワードプロキシの許可リストを別々に管理しなければならず、設定の不整合が原因の障害が発生しやすくなります。よくあるつまずきは、プロキシで許可されている通信がIstioのEgressポリシーで遮断される、またはその逆の状況です。設計段階でEgress制御の責務をどちらに寄せるかを決め、重複管理を避けることが重要です。サービスメッシュを採用する場合は、フォワードプロキシをEgressGatewayの内側に配置するか削除する設計が整理しやすくなります。

Egress可視化をVPCフローログだけで賄うか専用プロキシログで補うか

VPCフローログが提供する情報とその限界

VPCフローログはENIを通過したパケットのIPアドレス・ポート・バイト数・許可/拒否をレコードとして残します。インシデント調査や通信量の把握には有用ですが、「どのURLに何のリクエストを送ったか」は記録しません。TCP 443の通信量が急増していることは把握できても、どのドメインに向けた通信かはVPCフローログだけでは特定できません。DNSフローログ（Route 53 Resolverクエリログ）を組み合わせると名前解決の記録が取れますが、リクエスト単位のURL・HTTPメソッド・レスポンスコードは依然として残りません。可視化の粒度をどこに設定するかは、インシデント対応時に許容できる調査コストと照らして判断します。

プロキシログで得られる追加情報の価値

フォワードプロキシはリクエスト単位でURL・User-Agent・レスポンスコード・送受信バイト数を記録できます。セキュリティインシデント対応では、「いつ・どのIPから・どのURLに・何バイトのデータを送ったか」を追跡できるかどうかで、影響範囲の特定にかかる工数が大きく変わります。一般的に、プロキシログをSIEMに連携する構成ではVPCフローログのみの構成と比べてログ精度が向上し、調査時間の短縮につながります。ただしプロキシログはストレージコストも増加するため、保存期間・圧縮ポリシー・ローテーション設計を事前に決めておく必要があります。

SIEM連携と検知ルール設計への影響

VPCフローログをSIEMに送る構成では、異常検知ルールはIPアドレス・ポート・バイト数のパターンに基づきます。プロキシログを追加することでドメイン名・URLパス・User-Agentを軸にした検知ルールが書けるようになります。「新規に出現したドメインへのHTTPS通信」や「短時間に大量の異なるURLへのアクセス」といったふるまい検知はプロキシログなしには困難です。両者を組み合わせる場合は、送信元IPで突き合わせる相関設計が必要で、ログフォーマットの統一とタイムスタンプのタイムゾーン統一は設計初期に決めておく事項です。ログの持ち方を後から変えると既存の検知ルールが全面的に書き直しになります。

Egress方式比較表（フォワードプロキシ/NAT GW/VPCエンドポイント）

比較軸	フォワードプロキシ	NAT GW	VPCエンドポイント
フィルタリング粒度	URLレベル（ホスト名・パス）	IPアドレス・ポートのみ	エンドポイントポリシーによるリソース単位
TLS検査	可能（CA証明書配布が必要）	不可	不可（VPC内部通信）
ログの粒度	URL・UA・ステータスコード・バイト数	IP・ポート・バイト数	CloudTrailでAPIオペレーションのみ
帯域スケール	プロキシ性能に依存（要サイジング）	自動スケール	自動スケール
対応する通信先	外部HTTP/HTTPS全般	外部全般（プロトコル不問）	AWSサービスのみ
運用負荷	高（許可リスト・証明書管理）	低	中（エンドポイントポリシー管理）
主な採用理由	URLフィルタリング・可視化・DLP	シンプルな外部接続・大容量転送	コンプライアンス（通信の内部化）・コスト最適化

設計判断の順序として、まずAWSサービス向けの通信はVPCエンドポイントで内部化できないかを確認し、残った外部通信に対してURLレベルの制御が必要かどうかでプロキシとNAT GWを選ぶ流れが整理しやすくなります。以下のチェックリストを設計レビューの確認ポイントとして活用してください。

• URLレベルのフィルタリング要件があるか（ある場合はプロキシが前提）
• TLSインスペクションが必要なコンプライアンス要件があるか（ある場合はCA配布設計をセットで計画）
• AWSサービスへの通信はVPCエンドポイントで内部化できるか（S3・DynamoDBはゲートウェイ型を優先検討）
• 大容量データ転送がプロキシのスループット上限を超えないか（超える場合はNAT GW直通の経路分離を検討）
• certificate pinningやmTLSが絡む外部APIを洗い出し、TLS検査の除外リストを設計に含めたか
• コンテナ環境でHTTP_PROXY非対応のランタイム・バイナリの有無を確認したか
• プロキシログの保存先・保存期間・SIEM連携を設計に含めたか
• 許可リストの更新運用（SaaSドメイン変更への追従フロー）を決めたか
• サービスメッシュを採用する場合、Egress制御の責務をプロキシとメッシュのどちらに寄せるか決定したか