[プレビュー]Network Firewall ProxyでWindows Updateのアウトバウンド制御を試してみた

はじめに

こんにちは、こんばんは。コンサルティング部のぐっさんです。

「AWS Network Firewall Proxy」というサービスが先日プレビュー公開されました。
NAT Gatewayと統合されたマネージドな明示的プロキシサービスで、VPCからのアウトバウンド通信をドメインベースで制御できることに加えHTTPメソッド・URI・ヘッダー・ステータスコードなどの細かなフィルタリングを使った通信制御が可能になります。

https://aws.amazon.com/jp/about-aws/whats-new/2025/11/aws-network-firewall-proxy-preview/

https://aws.amazon.com/blogs/networking-and-content-delivery/securing-egress-architectures-with-network-firewall-proxy/

簡単ですが以下のような構成で閉域網からのインターネットアクセスにプロキシサーバーをSquid等で自前で立ててアウトバウンドの通信制御を行っていることが多いと思います。
(ECS等でコンテナ運用されていることもありますよね。)

この自前のプロキシサーバーがマネージドなサービスとして運用可能になるかも？！という話です。
パブリックプレビューはオハイオ(us-east-2)リージョンで無料で試すことができます。
※紐づくNAT Gatewayは通常通りの料金がかかりますので注意

今回は実用的なシナリオとして「Windows Updateのアウトバウンド制御」を検証してみました。
許可したドメインのみ通信可能なホワイトリスト方式で設定し、Allow/Denyの両方のログを確認します。

検証環境

構成図

シンプルですが以下のような構成になります。

使用リソース

※VPC(サブネット/ルートテーブル含む)・EC2の作成は完了しているものとして今回の記事では手順を割愛し、主な設定値のみ記載します。

VPC・サブネットの構成

リソースマップはこんな感じです。

ルートテーブル

パブリックサブネット:

プライベートサブネット:
※ここにはNat Gatewayへの経路を設定しません。エンドポイント経由でアクセス可能です。

EC2の準備

アップデート検証のため少し古いAMIを使いました。

セキュリティグループ

インバウンドルール:

アウトバウンドルール:

SSM用VPCエンドポイント

プライベートサブネットからSSM経由でRDP接続するため、以下のVPCエンドポイントを作成します:

• com.amazonaws.us-east-2.ssm
• com.amazonaws.us-east-2.ssmmessages

VPCエンドポイントのセキュリティグループでは、EC2のSGからの443ポートでのインバウンドアクセスを許可しておきます。
アウトバウンドルールは不要です。

NFW Proxyのセットアップ

ルールグループ作成

• VPCコンソールから「Proxy rule groups」を選択し、ルールグループを作成します。

• 適当なルールグループ名を設定します。文字/数字/ハイフンのみ使用できます。

• ルールの定義
  Network Firewall Proxyには3つの検証フェーズがあり、以下の順にトラフィック検査が走ります。
  • PreDNS – プロキシが目的の宛先ドメインのDNSを解決しようとする前に適用される
  • PreRequest – プロキシが宛先サーバーにHTTPリクエストを送信する前に適用される
  • PostResponse – プロキシが宛先サーバーからHTTP応答を受信した後に適用される

今回のユースケースではシンプルにPreDNSフェーズで特定ドメインへのアクセスを許可し、
他のドメインへはデフォルト拒否を行うイメージで設定してみます。
いわゆるホワイトリスト形式の運用を想定しています。

ルール名を設定し、条件を追加します。

Windows Update用に以下のドメインを許可設定します。

windowsupdate.microsoft.com
*.windowsupdate.microsoft.com
*.update.microsoft.com
*.windowsupdate.com
download.windowsupdate.com
download.microsoft.com
*.download.windowsupdate.com
wustat.windows.com
ntservicepack.microsoft.com
go.microsoft.com
dl.delivery.mp.microsoft.com
*.delivery.mp.microsoft.com

許可ドメインの一覧はWSUS用の手順ですが、以下を参照しました。

https://learn.microsoft.com/ja-jp/windows-server/administration/windows-server-update-services/deploy/2-configure-wsus

実際のルール設定値:

補足: ワイルドカードで指定したかったため、演算子をStringLikeにしてみました。

条件が追加され、「値」の部分を押下すると設定されているドメインリストを確認できました。

ルールグループが無事作成されました！

Proxy Configuration作成

作成したルールグループを関連付け、デフォルトアクションを設定します。

VPCコンソールの「プロキシ設定」へ。

デフォルトアクション
ドメインホワイトリスト形式の運用を想定しているため、PreDNSのデフォルトアクションを拒否にして
その他フェーズは「許可」とします。

ルールグループのアタッチ
先ほど作成したホワイトリストをアタッチします。優先度は「0」のままとします。

作成
確認して作成します。

作成後の詳細画面はこんな感じです。

Proxy作成

いよいよProxyを作成します！
VPCのコンソールから「プロキシ」を選択し作成します。

詳細設定の内容です。
任意のプロキシ名を入力し、先ほど設定したプロキシのConfigを選択します。

先に作っておいたNatゲートウェイをここで指定。
オプションのTLS検査は無効にしておき、ポートはデフォルト。ログ記録を有効化します。

ログはCloudWatch Logs、S3、Data Firehoseへ配信できます。
今回はAllow/Alert/Deny全てのログをCloudWatch Logsに出力することとします。この設定でプロキシを作成します！

作成すると状態が「アタッチ中」となります。
Nat Gatewayへのアタッチをしている状態で、私の環境ではおよそ10分でアタッチ済みとなりました。

作成完了後にNat Gatewayの設定を見てみます。
「Attachments」タブにnetwork-firewall-proxyが存在し、紐づくVPCエンドポイントが設定されています。

このVPCエンドポイントの設定を見てみます。

Nat Gatewayと同じパブリックサブネットに、プロキシ用のVPCエンドポイントが自動作成されていました。
同じVPC内であればルートテーブルでアクセス許可されているのでEC2からのエンドポイントアクセスはこのまま出来そうですね。
ちなみに、このVPCエンドポイントのセキュリティグループはVPCのデフォルトセキュリティグループがアタッチされていました。
デフォルトのセキュリティグループはSecurity HubのEC2.2対応などでルール削除している環境もありそうなのでGAでどんな仕様になるか気になりました。

EC2からこのVPCエンドポイントへアクセスする必要があるため、紐づいているデフォルトのセキュリティグループのインバウンドルールへ以下を追加しました。

作成完了後、コンソールからProxy EndpointのDNS名とポート番号を確認しておきます。

Windows側の設定

Windows EC2にRDP接続し、システムプロキシを設定します。

事前確認: プロキシ設定前のアクセステスト

まず、プロキシ設定前に直接インターネットへアクセスできないことを確認します。

curl.exe http://go.microsoft.com

プライベートサブネットでNAT Gateway経由のルートがないため、タイムアウトするはずです。

実行結果

PS C:\Users\Administrator> curl.exe http://go.microsoft.com
curl: (28) Failed to connect to go.microsoft.com port 80 after 21049 ms: Could not connect to server

想定通りですね。

curlでProxy経由のアクセステスト

OSのプロキシ設定前に、curlの -x オプションで直接プロキシを指定して接続動作を確認します。
curlでのHTTPSアクセスは追加のオプションが必要となるためシンプルに確認できるHTTPのURLへリクエストを送ってみます。

<proxy-endpoint>の部分にはプロキシのプライベートDNS名が入ります。

許可ドメインへのアクセス（成功するはず）:

curl.exe -x "<proxy-endpoint>" http://go.microsoft.com

こちらは実行後特にプロンプトへ返答がありませんでした。

許可していないドメインへのアクセス（拒否されるはず）:

curl.exe -x "<proxy-endpoint>" http://example.com

結果は「Forbidden」が返されました。想定通りです！

Windows PowerShellでは curl は Invoke-WebRequest のエイリアスになっているため、一般的なcurlを使う場合は curl.exe と明示的に指定します。

この時点で許可ドメインへのアクセスが成功し、許可外のドメインが拒否されていれば、Proxyの設定は正しく動作しています。

ログ確認

curlアクセス後のCloudWatch Logsを見てみましょう。

Allowログ（go.microsoft.com）

以下のようなログがALLOW_LOGSにありました。
"final_action": "allow"で、"dest_domain": "go.microsoft.com."とあり想定される動きをしていそうです。

{
    "event_timestamp": 1764488306,
    "proxy_name": "test-nfw-proxy",
    "client_src_ip": "10.0.100.210",
    "final_action": "allow",
    "src_vpc": "vpc-xxxxxxxxxxxxxxxxx",
    "dest_domain": "go.microsoft.com.",
    "http_method": "GET",
    "dest_ip": "23.221.245.214",
    "http_status_code": 302,
    "final_rule_name": "default",
    "final_rule_group_name": ""
}

Denyログ（example.com）

DENY_LOGSもみてみます。
"final_action": "deny"で、"dest_domain": "example.com."とあり、デフォルトアクションで拒否されたことがわかります。
ドメインチェックのフェーズで拒否されているため、"dest_ip"やステータスコードの値は詳細が入っていません。

{
    "event_timestamp": 1764489065,
    "proxy_name": "test-nfw-proxy",
    "client_src_ip": "10.0.100.210",
    "final_action": "deny",
    "src_vpc": "vpc-xxxxxxxxxxxxxxxxx",
    "dest_domain": "example.com.",
    "http_method": "GET",
    "dest_ip": "<nil>",
    "http_status_code": -1,
    "final_rule_name": "default",
    "final_rule_group_name": ""
}

Windowsのプロキシ設定

今回Windows Updateを実行するために、以下のプロキシ設定を行いました。

補足: 設定アプリから手動でWindows Updateを実行する場合はユーザープロキシのみでも動作しますが、自動更新やSSMパッチマネージャー経由の場合はSYSTEMアカウントで実行されるため、WinHTTPプロキシ設定が必要かと思います。

1. ユーザープロキシ設定（GUI）

Windowsの設定 → ネットワークとインターネット → プロキシ で以下を設定します。
<proxy-endpoint>には実際のProxy EndpointのプライベートDNS名をアドレスに設定します。
xxx.proxy.nfw.us-east-2.amazonaws.comのような値です。

ちなみに443を設定した場合は失敗しました。コントロールパネルでLAN設定を見ると、GUIの設定から行ったプロキシ設定はデフォルトでHTTPが指定される仕様のようでした。

WinHTTPプロキシを設定する場合

今回は試していませんが、以下のような設定になるかと思います。

# 設定確認
netsh winhttp show proxy

# プロキシ設定
netsh winhttp set proxy proxy-server="<proxy-endpoint>:ポート番号" bypass-list="169.254.169.254"

補足: bypass-listにEC2のメタデータエンドポイントを入れておかないと、今回のようにSSM経由でアクセスしている場合にWinHTTPプロキシを有効化したままインスタンスを再起動した場合EC2へのアクセス不可となることがありますのでご注意ください。

動作検証

Windows Update実行

Windowsの設定 → Windows Update → 更新プログラムの確認を実行します。

しばらくするとダウンロードが始まります。更新のチェックは問題なく通っていそうです。

「再起動が必要です」の表示まできたらあとはEC2を再起動するのみ！(再起動が不要なアップデートもあります)

Windows Updateのログでも「All federated installs have completed」のメッセージが出力されていました。
ちなみに、UpdateのログはPowerShellで「Get-WindowsUpdateLog」コマンドを実行することでデスクトップに出力されます。

CloudWatch Logsでログ確認

Allow/Denyそれぞれのログを確認します。

Allowログ

ログ自体は大量に出ていますが、以下のようにホワイトリストのルールでワイルドカードで指定したドメインにもアクセスできています。

{
    "event_timestamp": 1764497623,
    "proxy_name": "test-nfw-proxy",
    "client_src_ip": "10.0.100.210",
    "final_action": "allow",
    "src_vpc": "vpc-xxxxxxxxxxxxxxxxx",
    "dest_domain": "au.download.windowsupdate.com.",
    "http_method": "GET",
    "dest_ip": "146.75.78.172",
    "http_status_code": 206,
    "final_rule_name": "default",
    "final_rule_group_name": ""
}

Denyログ

bingへの接続が拒否されていました。アップデート後の検索エンジンの最適化で設定されるものでしょうか。
アップデート自体に直接は関係なさそうなのでそのままにしておきます。

{
    "event_timestamp": 1764498850,
    "proxy_name": "test-nfw-proxy",
    "client_src_ip": "10.0.100.210",
    "final_action": "deny",
    "src_vpc": "vpc-xxxxxxxxxxxxxxxxx",
    "dest_domain": "www.bing.com.",
    "http_method": "",
    "dest_ip": "<nil>",
    "http_status_code": -1,
    "final_rule_name": "default",
    "final_rule_group_name": ""
}

ログを確認したのでEC2を再起動してみます。

アップデート確認

再起動後、再接続をして設定からWindows Updateの結果をみてみます。

無事アップデートが完了していますね。

プロキシ設定解除（検証後）

ユーザープロキシは設定アプリから「プロキシサーバーを使う」をオフにします。

その他、EC2やVPCなど検証に使用したリソースを削除しておきます。

所感

良かった点

• マネージドなので構築・運用が楽
• NAT Gatewayとの統合でアーキテクチャがシンプル
• ルール設定がGUIで直感的に設定できる
• CloudWatch Logsとの統合が便利

気になった点

• プロキシエンドポイントのセキュリティグループ設定
• GAでの料金設定

まとめ

Network Firewall Proxyを使ってWindows Updateのアウトバウンド制御を試してみました。
今回はPreDNSフェーズのみを検証しましたが、PreRequestやPostResponseも試してみたいですね。

マネージドサービスとして運用負荷が下がる点は魅力的です。
現状キャッシュ機能等はなさそうなため、用途によってはSquid等のキャッシュプロキシとの使い分けが必要です。

GA時の料金体系や追加機能に期待しつつ、引き続きウォッチしていきたいと思います！

参考リンク

• AWS Network Firewall ドキュメント