AWSエグレス制御入門｜データ流出を防ぐDNS Firewall・データ境界・検知の3フェーズ導入設計

「セキュリティグループもWAFも入口は固めた。でも、外向きの通信はNATゲートウェイから全部出られる状態のまま」
AWSで環境を作ってきた人なら、思い当たる構成があるはずです。2026年10月20日、AWSの公式ブログ（Amazon Web Services ブログ）に「データ流出の防止: AWS で実現するクラウドワークロードのエグレス制御」の日本語版が掲載されました（原文はAWS Security Blogで2026年6月22日公開、8月4日にデータ境界の節を更新）。外向き通信（エグレス）を、ネットワーク・DNS・APIの3つの経路で多層的に押さえ、3つのフェーズで導入する設計がまとめられています。

この記事では、その内容をオンプレ経験のあるインフラエンジニア向けに読み解きます。個々のサービスの細かい設定ではなく、「どの経路をどのサービスで塞ぎ、どの順番で入れるか」という全体設計に絞り、東京リージョン（ap-northeast-1）の料金表から月額コストの目安も試算します。

エグレス制御が後回しになる理由とAWSブログの要点

多くの社内ネットワークでは、外に出る通信を境界のファイアウォールやプロキシに通す構成が一般的で、ログからどのサーバーがどこへ出たかを追えました。

クラウドでは、NATゲートウェイを置けばプライベートサブネットのインスタンスはそのままインターネットへ出られます。外部APIやリポジトリを使うアプリを止めたくないので、絞るのも怖い。AWSのブログも、アウトバウンド通信は既定で開放されたままのケースが少なくない、と指摘しています。

なぜ今、出口を見直すのか

ブログが挙げる理由は2つです。

1つ目は従来型の脆弱性です。CVE-2025-55182（React2Shell）が2025年12月に公開された際、複数のグループが数時間以内にパッチ未適用のReact Server Componentsを狙ってリモートコード実行を試み始めた、と書かれています。侵入した側は多くの場合、外向きの指令通信（C2）を張ってデータの持ち出しを始めます。出口に制御が無ければ、その通信は素通りです。

2つ目はAIエージェントです。OWASP Top 10 for Agentic Applicationsは、エージェントの目標の乗っ取り（ASI01）や想定外のコード実行（ASI05）を挙げています。ツールやAPIを呼べるエージェントは、操られれば流出の経路になります。

どちらも最後は「外向きの不正な通信」に行き着きます。出口で止めて、出口で気づける設計が要る、というのがブログの主張です。

ブログが想定するのは、スポークVPCをAWS Transit Gatewayに集約し、AWS Network Firewallで一元検査するマルチアカウント構成です。ブログ自身も「これは一例」と断っているので、自社の構成と照らし合わせる物差しとして読むのがよいと思います。

出口は3つある｜ネットワーク・DNS・APIの経路別に塞ぐ

AWSのブログは、エグレス対策を単一の制御ではなく多層的な戦略と位置づけています。ブログの内容を整理すると、出口は3つに分かれます。

ネットワークの制御だけでは、正規のAWS APIを使った持ち出しへの備えが手薄になります。ブログは、このAPI経路をデータ境界で守るとしています。

ネットワーク経路｜Transit GatewayとNetwork Firewallで一元検査

ブログの構成では、各スポークVPCのインターネット向け通信をTransit Gatewayに集め、Network Firewallで検査します。ファイアウォールのエンドポイントが0.0.0.0/0の行き先になり、NATゲートウェイでアドレス変換される前に検査されます。スポークVPCを増やしても検査の仕組みはそのままです。

機能としては、ドメイン名・ドメインカテゴリ・IPとポートでの許可と遮断、Suricata互換ルールによるIDS/IPS、TCP 443ではHTTPSだけを通すといったプロトコルの強制、TLS復号などが挙げられています。「宛先をドメイン名で絞れる」点は、セキュリティグループのルールにはない機能です。Network Firewall単体の仕組みはAWS Network Firewall入門、ハブアンドスポーク設計はAWS Transit Gateway入門で解説しています。

URLのパスやHTTPメソッド単位で絞れるAWS Network Firewall Proxy（明示的プロキシ）もありますが、2026年10月時点では米国東部（オハイオ、us-east-2）リージョンのパブリックプレビューです。東京の本番で前提にする段階ではありません。

DNS経路｜Network Firewallでは見えない抜け道

AWSのブログは、DNSがセキュリティ設計で見落とされがちだと指摘しています。

VPC内のインスタンスがRoute 53 VPC Resolver（VPCの既定のDNS）で名前解決するとき、そのクエリはNetwork Firewallが検査する経路を通りません。DNS Firewallのドキュメントにも、Network FirewallからはVPC Resolverのクエリは見えない、と書かれています。

つまり、Network Firewallで絞っても、DNSクエリにデータを埋め込んで外部のネームサーバーへ送る「DNSトンネリング」は通ってしまいます。これを塞ぐのがDNS Firewallです。AWSのマネージドドメインリスト（DNSトンネリングなども対象のAggregate Threat List）でのブロックや、承認したドメインだけを解決させる許可リスト運用ができ、DNS Firewall Advancedを使えばAI/MLによるDNSトンネリングの検出も加わります。

逆に、アプリが8.8.8.8のような外部のDNSリゾルバーへ直接問い合わせる場合はDNS Firewallを通らないので、Network Firewallで止めます。2つで1セットと考えてください。

注意点として、DNS FirewallはVPCごとにルールグループを関連付ける必要があります。新しいVPCで付け忘れると、そこが抜け道になります。AWS Firewall Managerを使えば、Organizations配下のVPCへの関連付けを一元管理できます（AWS Firewall Manager入門）。

API経路｜データ境界で「組織の外」への持ち出しを止める

データ境界は、「信頼できるアイデンティティだけが、想定したネットワークから、信頼できるリソースにアクセスできる」ようにする予防的なガードレールです。攻撃者が正規の認証情報を手に入れても、組織外のS3バケットへデータを移す操作を止める役割を担います。
・SCP: 組織全体で「何をさせないか」を決める。例えば、DNS Firewallが関連付けられていないVPCの作成や、別の外向き経路を作れるサービスの使用を防ぐ
・RCP: リソース側で、組織外からのS3バケットへのアクセスなどを止める補完のレイヤー
・VPCエンドポイントポリシー: エンドポイント経由でアクセスできるプリンシパルとリソースを制限する。エグレス制御として最も直接効く部分

aws-samplesのリポジトリにあるS3用エンドポイントポリシーの例から、中心の1文だけを抜き出すと次の形です（原本はAWSのサービスが使う公開バケットへの許可など複数の文を含むので、必ず原本を確認してください）。

# 自組織のプリンシパルが自組織のリソースにアクセスするときだけ許可（簡略版）
{"Version": "2012-10-17",
 "Statement": [{"Sid": "AllowRequestsByOrgsIdentitiesToOrgsResources",
  "Effect": "Allow", "Principal": "*", "Action": "*", "Resource": "*",
  "Condition": {"StringEquals": {
   "aws:PrincipalOrgID": "<my-org-id>",
   "aws:ResourceOrgID": "<my-org-id>"}}}]}

データ境界のポリシーは新しい権限を与えず、アクセスできる範囲を絞る「2つ目の認可レイヤー」として働きます。SCPの書き方はAWS SCP実践設計入門で詳しく扱っています。

予防と発見を分けて設計する

ブログは、制御を予防的なものと発見的なものに分けています。

予防的コントロール（Network Firewall・DNS Firewall・データ境界）は通信を実際に遮断するので、業務を止めるリスクがあります。ブログも、有害だと確認できている、または可能性が高いものに限って適用するよう書いています。一方の発見的コントロール（Amazon GuardDuty・AWS IAM Access Analyzer・AWS Security Hub）は観察するだけなので、広く当てても業務は止まりません。検出結果から繰り返し出てくるパターンを見つけ、予防側のルールへ移していく。この往復が基本の回し方です。

GuardDutyで見るべき検出結果タイプ

ブログが挙げる、エグレスに直結する検出結果は次の3つです。
・Trojan:EC2/DNSDataExfiltration: EC2インスタンスがDNSを通じてデータを送っている
・Exfiltration:S3/MaliciousIPCaller: GetObjectなどのS3データAPIが、脅威インテリジェンスに載ったIPアドレスから呼ばれた
・AttackSequence:S3/CompromisedData: バケットポリシーの変更と、盗んだ認証情報による抽出を一連の攻撃として相関

流出の「試み」が失敗したことを示すアラートは、予防側が効いている証拠になります。反対に、実際に流出したことを示す検出結果は、すぐにインシデント対応へ回す合図です。同じGuardDutyのアラートでも、意味が2通りあります。

GuardDutyの組織展開はAmazon GuardDuty実践設計入門、外部公開の検出はAWS IAM Access Analyzer入門で扱っています。なお、ブログで補完役として挙がっているAWS Shield network security directorは、パブリックプレビューが終了しており、2026年10月時点のドキュメントではコンソールにアクセスできないとされています。

3フェーズで段階的に導入する手順

ブログは、運用の成熟度とリスクの許容度に合わせて段階的に進めればよい、としています。3つのフェーズに確認ポイントを添えて整理します。

1. フェーズ1｜DNS FirewallとGuardDutyで「すぐ効く」ところから

すべてのVPCでDNS Firewallを、すべてのアカウントでGuardDutyを有効にする段階です。どちらもネットワーク構成を作り直さずに入れられます。

DNS Firewallのルールには、ALLOW・ALERT・BLOCKの3つのアクションがあります。ALERTは通信を通したまま、メトリクスとログをCloudWatchへ送るアクションです。まずALERTで業務の名前解決が引っかからないかを確かめてからBLOCKに切り替えると、アプリを止めるリスクを抑えられます。関連付けの漏れはAWS CLIで確認できます。

# AWS CLI: VPCにDNS Firewallのルールグループが関連付けられているか確認する
aws route53resolver list-firewall-rule-group-associations --vpc-id vpc-0123456789abcdef0 --region ap-northeast-1

# AWS CLI: ルールグループをVPCに関連付ける（IDは自分の環境の値に置き換える）
aws route53resolver associate-firewall-rule-group --name egress-dns-baseline --firewall-rule-group-id rslvr-frg-0123456789example --vpc-id vpc-0123456789abcdef0 --priority 101 --region ap-northeast-1

1つ目の結果が空なら、そのVPCにはDNS Firewallが付いていません。VPCが多い環境では、Firewall Managerのポリシーで関連付ける方が漏れにくくなります。

2. フェーズ2｜データ境界とNetwork Firewallで基盤を作る

組織全体のデータ境界（SCP・RCP・VPCエンドポイントポリシー）を展開し、Transit GatewayにアタッチしたNetwork Firewallを配置します。ネットワーク経路の変更を伴うため、事前の準備が欠かせません。進める前に次の点を確かめておきます。
・外向き通信の棚卸し: 各ワークロードが必要とする外部ドメイン・IPを洗い出す。フェーズ1のDNS Firewallのログが材料になる
・直出しのNATゲートウェイ: スポークVPCに残ると検査を迂回する出口になる。SCPで新設を防ぐかも決める
・VPCエンドポイント: S3などへの通信は、エンドポイントとエンドポイントポリシーで組織内に閉じる
・AIエージェントの許可リスト: カテゴリ単位で開けず、必要なエンドポイントだけに絞る

ブログでは、Amazon Bedrockで動くエージェントの通信も、EC2やコンテナと同じ経路・同じ許可リストとデータ境界で扱います。エージェント専用の出口は作りません。

3. フェーズ3｜検出と自動修復で運用を効率化する

AWS IAM Access Analyzerで外部アクセスを継続的に検出し、Amazon EventBridgeとAWS Lambdaの自動修復でファイアウォールのルールを更新し、検出結果をAWS Security Hubに集めます。GuardDutyが検出した脅威に応じて、Network Firewallの拒否ルールやDNS Firewallのブロックリストを自動更新する流れです。

ただし自動ブロックは業務を止める側の仕組みです。どの重大度で自動化するかは、フェーズ1・2で検出結果の傾向をつかんでから決める方が安全だと思います。流出の試みをシミュレートした定期テストで、制御が効いているかを確かめることもブログは勧めています。

コスト試算｜東京リージョンで月額いくらかかるか

AWSの料金表（東京リージョン、2026年10月21日に取得。USD・税別）の単価で試算します。条件は、2AZにNetwork Firewallのエンドポイント各1つ、スポークVPC 3つ、外向き通信が月1,000GB、DNSクエリが月1億件、ドメインリストに1,000ドメイン、という想定例です（1か月＝730時間）。

DNS Firewall Advancedは、ルールグループとVPCの関連付けごとに0.16 USD/時かかります。3つのVPCに付けると、0.16 × 3 × 730 = 350.40 USDが加わります。

費用の大半はNetwork Firewallのエンドポイントの時間料金で、通信量が少ない環境ほど固定費の比率が高くなります。DNS Firewallは従量課金が中心なので、コストの面でも始めやすい選択です。

NATゲートウェイは、Network Firewallと同じリージョン・同じ通信経路に置いた場合、時間料金とデータ処理料金がファイアウォールの使用量に応じて免除されるとAWSの料金ページに記載があります（NATの費用全般はAWS NAT Gateway コスト削減入門）。

この試算には、GuardDuty・Security Hub・CloudWatch Logs・データ転送料・TLS復号などを含めていません。Network Firewall自体のTransit Gatewayアタッチメント料金や、経路によって増えるTransit Gatewayの処理量も、料金表から断定できなかったため入れていません。実際の見積もりはAWS Pricing Calculatorで確かめてください。

よくある質問（FAQ）

Q1. セキュリティグループのアウトバウンドルールを絞るだけでは足りませんか？

宛先IPとポートは絞れますが、ドメイン名での指定や中身の検査はできません。さらにAWSのVPCのドキュメントには、セキュリティグループはRoute 53 Resolver（VPC+2のアドレス）へのDNSリクエストをブロックできず、フィルタするにはDNS Firewallを使う、と明記されています。セキュリティグループは土台として残し、その上に重ねる位置づけです。

Q2. 小規模でTransit Gatewayを使っていません。それでも意味はありますか？

あります。ブログのハブアンドスポークは一例です。VPCが1～2個なら、フェーズ1（DNS FirewallとGuardDuty）とVPCエンドポイントポリシーから始めるだけでも、DNS経路とAPI経路の一部（エンドポイントを通る通信）を押さえられます。API経路全体は、SCP・RCPと合わせて守ります。

Q3. AIエージェントには別の対策が必要ですか？

ブログの考え方では、エージェント専用の出口は作らず、同じ経路・同じ許可リスト・同じデータ境界を当てます。そのうえで許可するドメインを必要なエンドポイントに厳密に絞り、Amazon Bedrock Guardrailsのようなアプリケーション側のガードレールと組み合わせます。

Q4. クラウドに限らないエグレス対策の基礎は？

エグレスフィルタリングやC2通信の仕組みは、姉妹サイトのエグレスフィルタリングの解説（SecurityMaster）で扱っています。

本記事のまとめ

・出口は3つ: ネットワーク・DNS・AWSのAPI。どれか1つだけでは塞ぎきれない
・DNSは別経路: VPC Resolver経由の名前解決はNetwork Firewallから見えない。DNS FirewallをVPCごとに付ける
・データ境界: 正規の認証情報を使った組織外への持ち出しを、SCP・RCP・VPCエンドポイントポリシーで止める
・導入は3フェーズ: DNS FirewallとGuardDuty → データ境界とNetwork Firewall → 検出と自動修復
・プレビュー機能は前提にしない: Network Firewall Proxyは2026年10月時点で米国東部（オハイオ、us-east-2）のパブリックプレビュー、Shield network security directorはプレビュー終了

まずは自分の環境で、DNS Firewallが付いていないVPCがいくつあるかを数えるところから始めてみてください。そこは、安く塞げる出口の一つです。