LoginSignup
1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@pommny_dev(Pommny)inJapan AWS Jr. Champions

エンタープライズ環境でのオンプレミスとAWSの統合 ②VPCからのインターネットアクセス・プロキシとの統合

Last updated at Posted at 2025-09-05

はじめに

本記事は、エンタープライズ環境におけるオンプレミスとAWSの統合シリーズ の第二弾です。
第一弾では、社内DNSとAWS Route53を統合する際の設計パターンや注意点について整理しました。
https://qiita.com/pommny_dev/items/8b98dad0082f5a79e0ff

今回は、エンタープライズ環境で非常によく登場する 「オンプレのプロキシとの統合」 をテーマに取り上げます。

特に、以下の観点に焦点を当てて解説します。

  • プロキシの役割
  • プロキシと統合する際のネットワーク設計の考え方
  • プロキシの設定箇所
  • プロキシ利用時に特に注意すべきポイント

実際の案件で遭遇したトラブル事例も交えながら、設計・運用時にクライアントと認識を合わせておくべきポイントも合わせて整理します。

プロキシとは

まず前提として、ここでいう「プロキシ」とは 社内からインターネットへの通信を中継・制御するための仕組み を指します。
エンタープライズ環境ではセキュリティポリシー上、VPCから直接インターネットに出るのではなく、オンプレ環境にあるプロキシサーバを経由して外部にアクセスする構成が一般的です。

image.png

プロキシの役割

  • 通信の中継
    VPC内のサーバからの外部アクセスを一度プロキシに集約し、そこからインターネットへ接続する。
  • セキュリティ統制
    通信先のドメインやポートを制御し、不正アクセスやマルウェア通信を防止する。
  • 監査・ログ取得
    誰がどこにアクセスしたかを一元的に記録でき、監査要件に対応可能。

プロキシのメリット

  • セキュリティポリシーの一元化
    各VPCで個別にFirewallやアクセス制御を作り込む必要がなく、運用負荷を削減できる。
  • 運用コストの削減
    監査ログの収集や外部通信の制御をプロキシに集中させることで、VPCごとの構成をシンプルにできる。
  • コンプライアンス対応
    企業ごとに求められるセキュリティ基準（通信ログ保持やアクセス制御）を満たしやすい。

つまり、プロキシは「エンタープライズ環境におけるインターネットアクセスのゲートウェイ」として機能し、 AWS環境をオンプレと統合する際の大前提となる仕組みです。

そのため、VPCからインターネット向けに通信する場合、このプロキシを意識した設計をすることが重要（不可欠）となります。

プロキシと統合する場合のネットワーク設計

オンプレのプロキシと統合する構成では、AWS側のネットワークルーティングを明確に設計しておく必要があります。
ポイントは「VPCから出るインターネット向けの通信を、必ずオンプレのプロキシ経由に集約すること」です。
今回は、実際に案件で経験した、Direct Connect Gateway (DXGW) + Transit Gateway (TGW)構成におけるルートテーブル (RTB) の設計内容に触れます。

Direct Connect Gateway (DXGW)

  • 役割
    AWSとオンプレ環境をDirect Connect経由で接続する中継ポイント。
  • 設計上の注意点
    • DXGWでは「オンプレ側に広報するVPC CIDR」を明示的に設定する必要がある
    • プロキシ経由でインターネット通信を行うVPCのCIDRを、必ずDXGWの許可プレフィックスに含めておく必要がある
    • 設定を漏らすと、そのVPCからの通信がオンプレ側へ到達できず、結果的にプロキシを経由できなくなる

Transit Gateway (TGW)

  • 役割
    複数のVPCを統合して、DXGWおよびオンプレ環境と接続するハブ。
  • 設計上の注意点
    • インターネット向けの通信はすべてDXGWにルーティングすることが原則
    • 具体的には、TGWのルートテーブルに以下を設定する必要がある
      • 送信先：0.0.0.0/0（もしくは個別の宛先IPレンジ）
      • ターゲット：DXGWアタッチメント
    • この設定により、VPC内から出るインターネット通信は必ずオンプレ（＝プロキシ）に集約される

VPC ルートテーブル (RTB)

  • 役割
    各VPCからTGWに対してトラフィックをルーティングするポイント。
  • 設計上の注意点
    • インターネット向け通信はすべてTGWを経由させる必要があるため、以下のルートを設定する
      • 送信先：0.0.0.0/0 （もしくは個別の宛先IPレンジ）
      • ターゲット：TGWアタッチメント

注意点①：Network Firewall (NFW)

  • 役割
    VPCごとに独自の通信制御を行うためのAWSのセキュリティサービス。
  • 設計上の注意点
    • プロキシとNFWは「外部通信の制御」という点で役割が重複する
    • エンタープライズ環境ではすでにオンプレのプロキシで一元的に通信制御が行われているケースが多いため、
      VPCごとにNFWをデプロイする必要はないことが多い
    • ただし、VPCごとに異なるセキュリティ要件がある場合は、例外的にNFWの導入を検討する

📌 まとめ

  • VPC → TGW → DXGW → On-Prem Proxy → Internet という経路を前提にルート設計する
  • DXGW：オンプレに広報するVPC CIDRを必ず許可プレフィックスに含める
  • TGW：0.0.0.0/0 をDXGWにルーティングする設定を忘れない
  • VPC：デフォルトルートをTGWに向ける
  • NFW：プロキシ導入済み環境では不要なケースが多いが、個別要件があれば検討する

プロキシの設定

オンプレプロキシを統合する場合、単にネットワーク経路をプロキシ経由にするだけでは不十分です。
実際には、各レイヤーでプロキシ設定を正しく行い、さらにプロキシ除外設定 (NO_PROXY) を適切に行う必要があります。
これにより、プロキシに向ける通信・プロキシに向けない通信を各ホスト・アプリケーション側で正しく判別・ルーティング出来るようにします。

プロキシ設定を行うレイヤー

プロキシの設定は、主に以下のレイヤーで行う必要があります。
下記にてプロキシサーバのホスト名を設定します。

  • ホスト (OSレベル)

    • 例：Linuxのシステム環境変数 http_proxy / https_proxy
    • AWSにおけるAuto Scaling環境では、起動テンプレートのUserData に記載して設定を自動化することも可能

  • ミドルウェア

    • 例：Javaで動作するアプリケーションは、Javaの環境変数（-Dhttp.proxyHost など）で設定
    • データベースクライアントやメッセージキューなども個別に設定が必要

  • アプリケーション／ランタイム

    • 各アプリケーション固有の設定でプロキシを指定する場合
    • SaaSやPaaSソリューションを利用する場合は、エージェントの設定ファイル や 管理コンソール からプロキシを定義することが多い

NO_PROXYの設定

プロキシ設定と合わせて必ず必要なのが、プロキシ除外 (NO_PROXY) 設定 です。
これは「内部通信や特定のドメインについては、プロキシを通さず直接通信する」という指定です。

  • 設定を怠るとどうなるか？
    • 本来は直接アクセスすべき内部リソースまでプロキシに転送されてしまう
    • 結果として「通信不可」や「意図しないルーティング」が発生する

実際に経験したインシデント例

  • 構成：TGW + PrivateLink 環境、評価環境と本番環境を同じTGWに接続
    　　（評価環境と本番環境を同じTGWに接続すべきかは一旦置いておく）
  • 問題：amazonaws.com ドメインを NO_PROXY に入れていなかった
  • 結果：
    • PrivateLink経由で行うはずの大量データ通信が、誤ってオンプレのプロキシ (DXGW経由) に流れてしまった
    • Direct Connect回線が逼迫し、本番システムへのアクセスが遅延
  • 教訓：
    • NO_PROXY設定の徹底は必須
    • 特に amazonaws.com ドメインや、VPCエンドポイントで利用するドメインは必ず除外すること

image.png

📌 まとめ

  • プロキシ設定は「ホスト」「ミドルウェア」「アプリケーション／ランタイム」それぞれで必要
  • NO_PROXYを忘れると、内部通信までプロキシに流れてインシデントにつながる

プロキシ環境での注意点：ポート

オンプレのプロキシを利用する場合に見落としがちなのが、プロキシで許可されているポート範囲です。
プロキシで許可されているポート範囲が限定されている場合、VPCからプロキシ経由でPaaSサービスやSaaSサービスに接続するにあたり、ベンダー側指定のポートでの通信が出来るかどうか確認する必要があります。

注意点

  • プロキシのポート許可設定は事前に必ず確認する
  • 80 / 443 以外のポートをアプリケーションやサービスが利用する場合、通信がブロックされてしまう可能性有り。
  • PaaS / SaaS 統合では、80/443以外のポート を利用するケースが少なくない

実際の事例

  • 背景：あるプロジェクトで、外部の PaaSメタストア にインターネット経由で接続する必要があった
  • 問題：プロキシ環境は 80 / 443 以外のポートを許可していなかった
  • 結果：アプリケーションがプロキシ経由でメタストアに接続できず、アーキテクチャ構成の見直しを迫られた。

回避策

  • プロキシでポートを追加許可してもらう（理想）
  • 今回の事例ではプロキシ側でのポート許可が不可であったため、ベンダ側と協議し、VPC内にメタストア用のDBを立てて接続以下のような代替案で実装。

image.png

📌 まとめ

  • プロキシ環境では「ポート制御」を軽視しない
  • AWS統合の要件定義時に「アプリケーションが利用するポート」を必ず棚卸しておく
  • 許可されていない場合の代替構成（VPC内リソースやPrivateLink）を考慮する必要有。

おわりに

今回はエンタープライズ環境におけるプロキシとAWSの統合時の設計や注意点をまとめてみました。
複雑なアーキテクチャや利用しているサービスが多いほど、プロキシの設定漏れによる意図せぬ通信が発生するケースは多いのではないかと思います。
（アサインされたPJでもプロキシには大苦戦しました）

今後同じような経験をする方の一助になれば幸いです。

※本記事は一部文章の整形や表現の統一に生成AIを使用して執筆しています点ご了承ください。

1
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?