AWS Cloud WANの場合も複数セグメントでインターネットへのアウトバウンド通信を集約する場合は明示的なBlackholeルートが必要

Cloud WANを使用する場合でもBlackholeルートを追加することになる

2026.05.27

 各セグメントからインターネットアウトバウンド通信を集約するEgress VPCへのルートを設定する場合、意図しないセグメント間通信をすることを防ぎたいこんにちは、のんピ(@non____97)です。
皆さんは各セグメントからインターネットアウトバウンド通信を集約するEgress VPCへのルートを設定する場合、意図しないセグメント間通信をすることを防ぎたいなと思ったことはありますか? 私はあります。
Transit Gatewayを用いてEast-WestとNorth-Southの通信検査したり、インターネットへのアウトバウンド通信を集約したりすることは多いでしょう。
この時、ルートテーブルで制御をしなければ思わぬネットワーク間で通信ができてしまうことがあります。
具体例は以下記事で紹介されています。
https://dev.classmethod.jp/articles/how-to-reslove-tgw-problem-by-blachole-route/
Cloud WANについても何かケアが必要なのでしょうか。
実際に確認してみました。
末尾の追記内容 (運用負荷の見解 / Site-to-Site VPN・Direct Connect とのプレフィックス衝突注意) を取り込んで再生成します。
 いきなりまとめAWS Cloud WANで複数のセグメントから単一のNetwork Function Group (NFG) に send-to でインターネットアウトバウンド通信を集約する構成では、segment-actions に明示的なクロスセグメント許可を書いていなくても、セグメント間で意図しない通信が発生してしまう
send-to により、NFGが各セグメントのプレフィックスを学習することで、NFG経由でセグメント間の折り返し通信が成立してしまうことが原因

対策は各セグメントに create-route アクションでRFC 1918 (10.0.0.0/8 / 172.16.0.0/12 / 192.168.0.0/16) を宛先とするBlackholeルート を追加すること
ロンゲストマッチにより 0.0.0.0/0 → NFG よりBlackholeルートが優先されるため、セグメント間通信を遮断しつつ、インターネットへのアウトバウンド通信は継続できる

Cloud WANの設定のみで対応する場合、Blackhole Staticルートを追加する以外の方法は無さそう
とはいえ、セグメントが増えても各セグメントに create-route を3つ程度追加するだけのため、運用負荷は高くない

注意点
Blackholeルートと同じプレフィックスがSite-to-Site VPNやDirect Connectからアドバタイズされてくる場合、StaticルートであるBlackholeが優先されてしまい、当該リソースへルーティングできなくなくなる
対向ルーター側でアドバタイズするルートを細分化できないか設計検討が必要


{
  "segment": "prod",
  "destinations": ["blackhole"],
  "action": "create-route",
  "description": "Block cross-segment RFC1918 leakage from prod",
  "destination-cidr-blocks": [
    "10.0.0.0/8",
    "172.16.0.0/12",
    "192.168.0.0/16"
  ]
}
 Transit Gatewayの場合Transit Gatewayの場合のおさらいです。
以下のようなネットワークの構成があります。
この時、ProdのVPCとDevのVPC間で通信をさせたくないと思っていたとしても、Network FirewallのTransit Gateway route tableに従い、ProdとDev間で通信ができてしまいます。
これはインターネットへのアウトバウンド通信の集約を行うためにデフォルトルートを追加しなければならないためです。
インターネットへのアウトバウンド通信の集約を行わない場合は以下のように各Transit Gateway route tableを定義することができ、ProdとDev間の通信を防ぐことができます。
インターネットのアウトバウンド通信を集約したい場合においての対応として考えられるのが、各VPC CIDRを集約したプレフィックスに対するBlackholeルートを追加することになります。基本的にはRFC 1918のプライベートIPアドレスを指定してあげれば良いでしょう。
具体的には以下のようになります。
これにより、ProdとDev間で通信しようとする場合はBlackholeルートにより、通信することはできません。Prod内、Dev内の通信についてはロンゲストマッチにより通信を継続することができます。
また、追加コストの受容かつNetwork Firewallのルールを分離させたいということでNetwork FirewallをProdとDevとで分離させても良いのであれば、以下のように構成することも可能です。
こちらの構成でもProdとDev間の通信を行わせないことが可能です。
コストは受容するが、Network Firewallのルールは1つのファイアウォールポリシーで管理したいという場合は、Inspection VPCをもう一つ追加し、追加したInspection VPCに既存Network FirewallのVPCエンドポイントを追加で関連付けることで対応可能です。
https://aws.amazon.com/jp/about-aws/whats-new/2025/05/aws-network-firewall-multiple-vpc-endpoints/
1つのNetwork Firewall、ファイアウォールポリシーを管理するだけで良いため、単純にNetwork Firewallを2つ用意する場合と比較すると管理コストを抑えることができます。
さらに、セカンダリエンドポイントは通常のNetwork Firewallエンドポイントよりも時間単価が安いのも嬉しいポイントです。


リソースタイプ
料金


Network Firewall Endpoint
USD 0.395/時間

Network Firewall セカンダリエンドポイント
USD 0.158/時間

なお、これらの構成の場合、Egress VPCのTransit Gateway route tableに各VPCのルートをStaticで定義しなければならないため、VPC数が多くなってくるとルートの管理負荷が高くなってくる可能性があります。ProdとDevとでそれぞれルート集約できるのであれば良いでしょうが、VPC分割が進むと綺麗に連番でVPC CIDRの割り当ては難しくなってくるものと考えます。
 Cloud WANの場合 (Blackholeルートなし)では、Cloud WANの場合はどうでしょうか。実際に試してみます。
構成図としては以下のとおりです。
特にBlackholeルートは設定せず、send-via、send-to アクションで各セグメントからInspection VPCへルーティングをしています。
全てのリソースはAWS CDKで作成しており、リポジトリは以下GitHubに保存しています。
https://github.com/non-97/aws-cdk-cloud-wan-single-region
Core Network Policyは以下のとおりです。
{
  "core-network-configuration": {
    "asn-ranges": [
      "65000-65099"
    ],
    "edge-locations": [
      {
        "location": "ap-northeast-1",
        "asn": 65001
      }
    ]
  },
  "version": "2025.11",
  "attachment-policies": [
    {
      "rule-number": 200,
      "condition-logic": "or",
      "description": "attachment segment prod",
      "action": {
        "association-method": "constant",
        "segment": "prod"
      },
      "conditions": [
        {
          "type": "tag-value",
          "value": "prod",
          "operator": "equals",
          "key": "cloudwan-seg"
        }
      ]
    },
    {
      "rule-number": 300,
      "condition-logic": "or",
      "description": "attachment segment dev",
      "action": {
        "association-method": "constant",
        "segment": "dev"
      },
      "conditions": [
        {
          "type": "tag-value",
          "value": "dev",
          "operator": "equals",
          "key": "cloudwan-seg"
        }
      ]
    },
    {
      "rule-number": 400,
      "condition-logic": "or",
      "description": "attachment nfg security",
      "action": {
        "add-to-network-function-group": "security"
      },
      "conditions": [
        {
          "type": "tag-value",
          "value": "security",
          "operator": "equals",
          "key": "cloudwan-nfg"
        }
      ]
    }
  ],
  "network-function-groups": [
    {
      "name": "security",
      "require-attachment-acceptance": false
    }
  ],
  "segments": [
    {
      "isolate-attachments": true,
      "name": "prod",
      "require-attachment-acceptance": false,
      "edge-locations": [
        "ap-northeast-1"
      ]
    },
    {
      "isolate-attachments": true,
      "name": "dev",
      "require-attachment-acceptance": false,
      "edge-locations": [
        "ap-northeast-1"
      ]
    }
  ],
  "segment-actions": [
    {
      "segment": "prod",
      "action": "send-to",
      "via": {
        "network-function-groups": [
          "security"
        ]
      },
      "when-sent-to": {
        "segments": "prod"
      }
    },
    {
      "mode": "single-hop",
      "when-sent-to": {
        "segments": [
          "prod"
        ]
      },
      "segment": "prod",
      "action": "send-via",
      "via": {
        "network-function-groups": [
          "security"
        ]
      }
    },
    {
      "segment": "dev",
      "action": "send-to",
      "via": {
        "network-function-groups": [
          "security"
        ]
      },
      "when-sent-to": {
        "segments": "dev"
      }
    },
    {
      "mode": "single-hop",
      "when-sent-to": {
        "segments": [
          "dev"
        ]
      },
      "segment": "dev",
      "action": "send-via",
      "via": {
        "network-function-groups": [
          "security"
        ]
      }
    }
  ]
}
 ルート情報の確認ルート情報は以下のとおりです。
Prodセグメントのルート

Devセグメントのルート

Security NFGのルート

ProdとDevに直接的なルートはないものの、Security NFGでProdとDev間の折り返し通信ができてしまいそうですね。
 Prod VPC A → Prod VPC B実際に疎通確認をしてみましょう。
Prod VPC A → Prod VPCです。
$ hostname -i
10.1.0.223

$ ping -c 4 10.2.0.234
PING 10.2.0.234 (10.2.0.234) 56(84) bytes of data.
64 bytes from 10.2.0.234: icmp_seq=1 ttl=123 time=2.76 ms
64 bytes from 10.2.0.234: icmp_seq=2 ttl=123 time=1.13 ms
64 bytes from 10.2.0.234: icmp_seq=3 ttl=123 time=1.16 ms
64 bytes from 10.2.0.234: icmp_seq=4 ttl=123 time=1.13 ms

--- 10.2.0.234 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3005ms
rtt min/avg/max/mdev = 1.131/1.545/2.757/0.699 ms
問題なく通信できました。
Network Firewallも問題なく通っています。
{
    "firewall_name": "AwsCnVpcB646F1DF-Nfw",
    "availability_zone": "ap-northeast-1a",
    "event_timestamp": "1779857072",
    "event": {
        "icmp_type": 8,
        "aws_category": "",
        "src_ip": "10.1.0.223",
        "src_port": 0,
        "event_type": "alert",
        "alert": {
            "severity": 3,
            "signature_id": 2000002,
            "rev": 1,
            "signature": "ICMP ping detected",
            "action": "allowed",
            "category": ""
        },
        "flow_id": 53708269902472,
        "dest_ip": "10.2.0.234",
        "proto": "ICMP",
        "verdict": {
            "action": "alert"
        },
        "icmp_code": 0,
        "dest_port": 0,
        "pkt_src": "geneve encapsulation",
        "timestamp": "2026-05-27T04:44:32.798936+0000",
        "direction": "to_server"
    }
}
 Dev VPC A → Dev VPC B続いて、Dev VPC A → Dev VPC Bです。
$ hostname -i
10.101.0.156

$ ping -c 4 10.102.0.48
PING 10.102.0.48 (10.102.0.48) 56(84) bytes of data.
64 bytes from 10.102.0.48: icmp_seq=1 ttl=123 time=2.51 ms
64 bytes from 10.102.0.48: icmp_seq=2 ttl=123 time=1.10 ms
64 bytes from 10.102.0.48: icmp_seq=3 ttl=123 time=1.08 ms
64 bytes from 10.102.0.48: icmp_seq=4 ttl=123 time=1.22 ms

--- 10.102.0.48 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3004ms
rtt min/avg/max/mdev = 1.082/1.478/2.514/0.599 ms
こちらも問題なく通信できました。
Network Firewallも問題なく通っています。
{
    "firewall_name": "AwsCnVpcB646F1DF-Nfw",
    "availability_zone": "ap-northeast-1a",
    "event_timestamp": "1779857184",
    "event": {
        "icmp_type": 8,
        "aws_category": "",
        "src_ip": "10.101.0.156",
        "src_port": 0,
        "event_type": "alert",
        "alert": {
            "severity": 3,
            "signature_id": 2000002,
            "rev": 1,
            "signature": "ICMP ping detected",
            "action": "allowed",
            "category": ""
        },
        "flow_id": 218232706638873,
        "dest_ip": "10.102.0.48",
        "proto": "ICMP",
        "verdict": {
            "action": "alert"
        },
        "icmp_code": 0,
        "dest_port": 0,
        "pkt_src": "geneve encapsulation",
        "timestamp": "2026-05-27T04:46:24.050811+0000",
        "direction": "to_server"
    }
}
 Prod VPC A → Dev VPC Aそれでは、Prod VPC A → Dev VPC Aです。
$ hostname -i
10.1.0.223

$ ping -c 4 10.101.0.156
PING 10.101.0.156 (10.101.0.156) 56(84) bytes of data.
64 bytes from 10.101.0.156: icmp_seq=1 ttl=123 time=3.17 ms
64 bytes from 10.101.0.156: icmp_seq=2 ttl=123 time=1.18 ms
64 bytes from 10.101.0.156: icmp_seq=3 ttl=123 time=1.19 ms
64 bytes from 10.101.0.156: icmp_seq=4 ttl=123 time=1.16 ms

--- 10.101.0.156 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3004ms
rtt min/avg/max/mdev = 1.162/1.674/3.167/0.861 ms
はい、通信できてしまいました。
ということで、2つ以上のセグメントで同一のNFGに send-to で繋げた場合は何かしらの対応が必要です。
send-viaについては以下記事で紹介しているように、ProdとDev間とで通信することはできません。
https://dev.classmethod.jp/articles/aws-cloud-wan-service-insertion-send-via-no-transitive-route-propagation/
ちなみにNetwork Firewallは問題なく通っていました。
{
    "firewall_name": "AwsCnVpcB646F1DF-Nfw",
    "availability_zone": "ap-northeast-1a",
    "event_timestamp": "1779857255",
    "event": {
        "icmp_type": 8,
        "aws_category": "",
        "src_ip": "10.1.0.223",
        "src_port": 0,
        "event_type": "alert",
        "alert": {
            "severity": 3,
            "signature_id": 2000002,
            "rev": 1,
            "signature": "ICMP ping detected",
            "action": "allowed",
            "category": ""
        },
        "flow_id": 2098777114342334,
        "dest_ip": "10.101.0.156",
        "proto": "ICMP",
        "verdict": {
            "action": "alert"
        },
        "icmp_code": 0,
        "dest_port": 0,
        "pkt_src": "geneve encapsulation",
        "timestamp": "2026-05-27T04:47:35.029907+0000",
        "direction": "to_server"
    }
}

 Prod VPC A → インターネットインターネットへのアウトバウンド通信も確認します。
まず、Prod Aです。
$ hostname -i
10.1.0.223

$ curl https://checkip.amazonaws.com
57.181.152.161
通信できました。
Network Firewallも通っています。
{
    "firewall_name": "AwsCnVpcB646F1DF-Nfw",
    "availability_zone": "ap-northeast-1a",
    "event_timestamp": "1779857528",
    "event": {
        "aws_category": "",
        "tx_id": 0,
        "app_proto": "tls",
        "src_ip": "10.1.0.223",
        "src_port": 40812,
        "event_type": "alert",
        "alert": {
            "severity": 3,
            "signature_id": 2000001,
            "rev": 1,
            "signature": "Access to checkip.amazonaws.com detected",
            "action": "allowed",
            "category": ""
        },
        "flow_id": 2210287241619623,
        "dest_ip": "52.220.207.21",
        "proto": "TCP",
        "verdict": {
            "action": "alert"
        },
        "tls": {
            "sni": "checkip.amazonaws.com",
            "version": "UNDETERMINED"
        },
        "dest_port": 443,
        "pkt_src": "geneve encapsulation",
        "timestamp": "2026-05-27T04:52:08.046582+0000",
        "direction": "to_server"
    }
}
 Dev VPC A → インターネット次にDev VPC Aです。
$ hostname -i
10.101.0.156

$ curl https://checkip.amazonaws.com
57.181.152.161
通信できました。同じIPアドレスが返ってきていることから意図したとおりインターネットへのアウトバウンド通信の集約ができていることが分かります。
Network Firewallのログは以下のとおりです。
{
    "firewall_name": "AwsCnVpcB646F1DF-Nfw",
    "availability_zone": "ap-northeast-1a",
    "event_timestamp": "1779857534",
    "event": {
        "aws_category": "",
        "tx_id": 0,
        "app_proto": "tls",
        "src_ip": "10.101.0.156",
        "src_port": 36608,
        "event_type": "alert",
        "alert": {
            "severity": 3,
            "signature_id": 2000001,
            "rev": 1,
            "signature": "Access to checkip.amazonaws.com detected",
            "action": "allowed",
            "category": ""
        },
        "flow_id": 1706644564071687,
        "dest_ip": "52.220.101.240",
        "proto": "TCP",
        "verdict": {
            "action": "alert"
        },
        "tls": {
            "sni": "checkip.amazonaws.com",
            "version": "UNDETERMINED"
        },
        "dest_port": 443,
        "pkt_src": "geneve encapsulation",
        "timestamp": "2026-05-27T04:52:14.143970+0000",
        "direction": "to_server"
    }
}
 Cloud WANの場合 (Blackholeルートあり)では、Blackholeルートを追加した場合です。
Core Network Policyは以下のとおりで、各セグメントにRFC 1918のIPアドレスをBlackholeルートとする create-route アクションを追加しました。
{
  "core-network-configuration": {
    "asn-ranges": [
      "65000-65099"
    ],
    "edge-locations": [
      {
        "location": "ap-northeast-1",
        "asn": 65001
      }
    ]
  },
  "version": "2025.11",
  "attachment-policies": [
    {
      "rule-number": 200,
      "condition-logic": "or",
      "description": "attachment segment prod",
      "action": {
        "association-method": "constant",
        "segment": "prod"
      },
      "conditions": [
        {
          "type": "tag-value",
          "value": "prod",
          "operator": "equals",
          "key": "cloudwan-seg"
        }
      ]
    },
    {
      "rule-number": 300,
      "condition-logic": "or",
      "description": "attachment segment dev",
      "action": {
        "association-method": "constant",
        "segment": "dev"
      },
      "conditions": [
        {
          "type": "tag-value",
          "value": "dev",
          "operator": "equals",
          "key": "cloudwan-seg"
        }
      ]
    },
    {
      "rule-number": 400,
      "condition-logic": "or",
      "description": "attachment nfg security",
      "action": {
        "add-to-network-function-group": "security"
      },
      "conditions": [
        {
          "type": "tag-value",
          "value": "security",
          "operator": "equals",
          "key": "cloudwan-nfg"
        }
      ]
    }
  ],
  "network-function-groups": [
    {
      "name": "security",
      "require-attachment-acceptance": false
    }
  ],
  "segments": [
    {
      "isolate-attachments": true,
      "name": "prod",
      "require-attachment-acceptance": false,
      "edge-locations": [
        "ap-northeast-1"
      ]
    },
    {
      "isolate-attachments": true,
      "name": "dev",
      "require-attachment-acceptance": false,
      "edge-locations": [
        "ap-northeast-1"
      ]
    }
  ],
  "segment-actions": [
    {
      "segment": "prod",
      "action": "send-to",
      "via": {
        "network-function-groups": [
          "security"
        ]
      },
      "when-sent-to": {
        "segments": "prod"
      }
    },
    {
      "mode": "single-hop",
      "when-sent-to": {
        "segments": [
          "prod"
        ]
      },
      "segment": "prod",
      "action": "send-via",
      "via": {
        "network-function-groups": [
          "security"
        ]
      }
    },
    {
      "segment": "dev",
      "action": "send-to",
      "via": {
        "network-function-groups": [
          "security"
        ]
      },
      "when-sent-to": {
        "segments": "dev"
      }
    },
    {
      "mode": "single-hop",
      "when-sent-to": {
        "segments": [
          "dev"
        ]
      },
      "segment": "dev",
      "action": "send-via",
      "via": {
        "network-function-groups": [
          "security"
        ]
      }
    },
    {
      "segment": "prod",
      "destinations": [
        "blackhole"
      ],
      "action": "create-route",
      "description": "Block cross-segment RFC1918 leakage from prod",
      "destination-cidr-blocks": [
        "10.0.0.0/8",
        "172.16.0.0/12",
        "192.168.0.0/16"
      ]
    },
    {
      "segment": "dev",
      "destinations": [
        "blackhole"
      ],
      "action": "create-route",
      "description": "Block cross-segment RFC1918 leakage from dev",
      "destination-cidr-blocks": [
        "10.0.0.0/8",
        "172.16.0.0/12",
        "192.168.0.0/16"
      ]
    }
  ]
}
 ルート情報の確認ルート情報は以下のとおりです。
Prodセグメントのルート

Devセグメントのルート

Security NFGのルート

Prodセグメント、DevセグメントにてBlackholeルートがあることが分かりますね。
 Prod VPC A → Prod VPC BBlackholeルートを設定していなかった場合と同じ通信を試します。
まず、Prod VPC A → Prod VPC Bです。
$ hostname -i
10.1.0.223

$ ping -c 4 10.2.0.234
PING 10.2.0.234 (10.2.0.234) 56(84) bytes of data.
64 bytes from 10.2.0.234: icmp_seq=1 ttl=123 time=2.79 ms
64 bytes from 10.2.0.234: icmp_seq=2 ttl=123 time=1.30 ms
64 bytes from 10.2.0.234: icmp_seq=3 ttl=123 time=3.66 ms
64 bytes from 10.2.0.234: icmp_seq=4 ttl=123 time=1.02 ms

--- 10.2.0.234 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3004ms
rtt min/avg/max/mdev = 1.017/2.192/3.661/1.082 ms
問題なく通信できました。
Network Firewallのログは以下のとおりです。
{
    "firewall_name": "AwsCnVpcB646F1DF-Nfw",
    "availability_zone": "ap-northeast-1a",
    "event_timestamp": "1779857950",
    "event": {
        "icmp_type": 8,
        "aws_category": "",
        "src_ip": "10.1.0.223",
        "src_port": 0,
        "event_type": "alert",
        "alert": {
            "severity": 3,
            "signature_id": 2000002,
            "rev": 1,
            "signature": "ICMP ping detected",
            "action": "allowed",
            "category": ""
        },
        "flow_id": 1816427272690312,
        "dest_ip": "10.2.0.234",
        "proto": "ICMP",
        "verdict": {
            "action": "alert"
        },
        "icmp_code": 0,
        "dest_port": 0,
        "pkt_src": "geneve encapsulation",
        "timestamp": "2026-05-27T04:59:10.291847+0000",
        "direction": "to_server"
    }
}

 Dev VPC A → Dev VPC B次にDev VPC A → Dev VPC Bです。
$ hostname -i
10.101.0.156

$ ping -c 4 10.102.0.48
PING 10.102.0.48 (10.102.0.48) 56(84) bytes of data.
64 bytes from 10.102.0.48: icmp_seq=1 ttl=123 time=2.51 ms
64 bytes from 10.102.0.48: icmp_seq=2 ttl=123 time=1.05 ms
64 bytes from 10.102.0.48: icmp_seq=3 ttl=123 time=1.05 ms
64 bytes from 10.102.0.48: icmp_seq=4 ttl=123 time=1.13 ms

--- 10.102.0.48 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3004ms
rtt min/avg/max/mdev = 1.047/1.433/2.509/0.621 ms
こちらも問題なく通信できました。
Network Firewallのログは以下のとおりです。
{
    "firewall_name": "AwsCnVpcB646F1DF-Nfw",
    "availability_zone": "ap-northeast-1a",
    "event_timestamp": "1779857975",
    "event": {
        "icmp_type": 8,
        "aws_category": "",
        "src_ip": "10.101.0.156",
        "src_port": 0,
        "event_type": "alert",
        "alert": {
            "severity": 3,
            "signature_id": 2000002,
            "rev": 1,
            "signature": "ICMP ping detected",
            "action": "allowed",
            "category": ""
        },
        "flow_id": 2069543908974998,
        "dest_ip": "10.102.0.48",
        "proto": "ICMP",
        "verdict": {
            "action": "alert"
        },
        "icmp_code": 0,
        "dest_port": 0,
        "pkt_src": "geneve encapsulation",
        "timestamp": "2026-05-27T04:59:35.678461+0000",
        "direction": "to_server"
    }
}
 Prod VPC A → Dev VPC Aでは、Prod VPC A → Dev VPC Aです。
$ hostname -i
10.1.0.223

$ ping -c 4 10.101.0.156
PING 10.101.0.156 (10.101.0.156) 56(84) bytes of data.

--- 10.101.0.156 ping statistics ---
4 packets transmitted, 0 received, 100% packet loss, time 3085ms
はい、全てのパケットがドロップしました。
Blackholeルートが効いていますね。
 Prod VPC A → インターネットインターネットへのアウトバウンド通信が継続してできるかも確認しておきましょう。
まず、Prod VPC Aです。
$ hostname -i
10.1.0.223

$ curl https://checkip.amazonaws.com
57.181.152.161
通信できましたね。
Network Firewallのログは以下のとおりです。
{
    "firewall_name": "AwsCnVpcB646F1DF-Nfw",
    "availability_zone": "ap-northeast-1a",
    "event_timestamp": "1779858030",
    "event": {
        "aws_category": "",
        "tx_id": 0,
        "app_proto": "tls",
        "src_ip": "10.1.0.223",
        "src_port": 40374,
        "event_type": "alert",
        "alert": {
            "severity": 3,
            "signature_id": 2000001,
            "rev": 1,
            "signature": "Access to checkip.amazonaws.com detected",
            "action": "allowed",
            "category": ""
        },
        "flow_id": 1841923384537736,
        "dest_ip": "54.179.238.89",
        "proto": "TCP",
        "verdict": {
            "action": "alert"
        },
        "tls": {
            "sni": "checkip.amazonaws.com",
            "version": "UNDETERMINED"
        },
        "dest_port": 443,
        "pkt_src": "geneve encapsulation",
        "timestamp": "2026-05-27T05:00:30.567173+0000",
        "direction": "to_server"
    }
}
 Dev VPC A → インターネット続いて、Dev VPC Aです。
$ hostname -i
10.101.0.156

$ curl https://checkip.amazonaws.com
57.181.152.161
こちらも変わらず通信できました。
Network Firewallのログは以下のとおりです。
{
    "firewall_name": "AwsCnVpcB646F1DF-Nfw",
    "availability_zone": "ap-northeast-1a",
    "event_timestamp": "1779858037",
    "event": {
        "aws_category": "",
        "tx_id": 0,
        "app_proto": "tls",
        "src_ip": "10.101.0.156",
        "src_port": 36738,
        "event_type": "alert",
        "alert": {
            "severity": 3,
            "signature_id": 2000001,
            "rev": 1,
            "signature": "Access to checkip.amazonaws.com detected",
            "action": "allowed",
            "category": ""
        },
        "flow_id": 1297804386883438,
        "dest_ip": "18.141.46.247",
        "proto": "TCP",
        "verdict": {
            "action": "alert"
        },
        "tls": {
            "sni": "checkip.amazonaws.com",
            "version": "UNDETERMINED"
        },
        "dest_port": 443,
        "pkt_src": "geneve encapsulation",
        "timestamp": "2026-05-27T05:00:37.029528+0000",
        "direction": "to_server"
    }
}
 Cloud WANを使用する場合でもBlackholeルートを追加することになるAWS Cloud WANの場合も複数セグメントでインターネットへのアウトバウンド通信を集約する場合は明示的なBlackholeルートが必要ということを紹介しました。
Cloud WANの設定のみでBlackholeのStaticルートを追加する以外の方法は特にないようでした。セグメントが増えたとしても create-route を各セグメントに3つ程度追加するだけなので、そこまで運用負荷は高くはないかと考えています。
注意点としてはBlackholeルートのプレフィックスと同じプレフィックスがSite-to-Site VPNやDirect Connectからアドバタイズされてこないかです。もし、同じプレフィックスがアドバタイズされてきてしまった場合、Staticルートが優先される = Blackhole が優先されてしまい、そのリソースにルーティングすることできません。Site-to-Site VPNやDirect Connectの対向のルーターでアドバタイズしてくるルートを細分化できないか検討しましょう。
この記事が誰かの助けになれば幸いです。
以上、クラウド事業本部 コンサルティング部の のんピ(@non____97)でした!