produced by Classmethod

AWS CDKでAWS Cloud WANの環境一式を構築してService InsertionによるNetwork Firewallの検査やインターネットのアウトバウンド通信の集約をしてみた

Cloud WANの環境をサッと用意したいときに

AWS Cloud WAN AWS Site-to-Site VPN Amazon VPC AWS Network Firewall AWS

2026.04.26

 複数リージョンにVPCを用意してVPCルートテーブルを調整するのが大変だなこんにちは、のんピ(@non____97)です。
皆さんはAWS Cloud WANの検証をするときに、複数リージョンにVPCを用意してVPCルートテーブルを調整するのが大変だなと思ったことはありますか? 私はあります。
Cloud WANを採用するシーンの中に複数リージョンにVPCが分散配置している場合に統合的に管理をしたい場合があると考えます。
実際にこちらの検証をするにあたって毎回複数リージョンにVPCを用意していくのは中々大変です。特にCloud WANでCore Networkの作成が完了するまで20分ほどかかることもあるため、それまでVPCの接続を待つことになります。集中力が持ちません。特にService Insertionを用いてEast-Westの通信をNetwork Firewallで検査させたり、NAT GatewayがあるVPCにルーティングさせようとする場合は登場人物が特に多くなります。
Service Insertionについては以下AWS Blogsをご覧ください。
https://aws.amazon.com/jp/blogs/news/simplify-global-security-inspection-with-aws-cloud-wan-service-insertion/
https://aws.amazon.com/jp/blogs/news/migration-to-aws-cloud-wan-multi-region-inspection-using-service-insertion/
https://aws.amazon.com/jp/blogs/networking-and-content-delivery/centralized-ingress-inspection-architecture-in-aws-cloud-wan/
ということで、AWS CDKでCloud WANの環境をサッと用意できるようにしてみました。
 検証環境検証環境は以下のとおりです。
ap-northeast-1とus-east-1の2リージョンを使用しており、セグメントはdevとprod、shareの3つを用意しています。
セグメント間の通信をする際にはNetwork Firewallを通すようにしています。また、prodセグメントについてはインターネットに出る際にはEgress VPCから出るようにしています。
オンプレ相当としてVPN VPCを用意して、Site-to-Site VPNで接続をしてBGPで経路交換するようにしています。VPNサーバーではLibreswanとFRRを使用しています。
なお、この構成の時間あたりの料金は以下のとおりです。


リソース
単価 (USD/時間)
数量
小計 (USD/時間)


Cloud WAN Core Network Edge
$0.500
2
$1.000

Cloud WAN VPC Attachment (ap-northeast-1)
$0.090
4
$0.360

Cloud WAN VPC Attachment (us-east-1)
$0.065
2
$0.130

Cloud WAN Site-to-Site VPN Attachment
$0.065
1
$0.065

Network Firewall Endpoint
$0.395
1
$0.395

NAT Gateway (ap-northeast-1)
$0.062
2
$0.124

NAT Gateway (us-east-1)
$0.045
1
$0.045

EC2 t3.micro (ap-northeast-1)
$0.0136
2
$0.027

EC2 t3.micro (us-east-1)
$0.0104
2
$0.021

EC2 t3.small VPN Router (us-east-1)
$0.0208
1
$0.021

VPN Connection
$0.048
1
$0.048

EIC Endpoint
無料
3
$0.000

合計


$2.236

実際にはEBSボリュームの料金やデータ転送量に対する課金が発生します。ボチボチな料金だと思うので長時間放置するのは避けましょう。
 AWS CDKのコードAWS CDKのコードの構成は以下のようになっています。
.
├── bin
│   └── aws-cdk-cloud-wan.ts          # CDK アプリケーションのエントリポイント。2つのStack (Region1/Region2) を定義
├── lib
│   ├── constructs
│   │   ├── core-network.ts           # Cloud WAN の Global Network / Core Network / ポリシーを定義する Construct
│   │   ├── egress-vpc.ts             # インターネット出口用 VPC (NAT Gateway / IGW) の Construct。share セグメントに所属
│   │   ├── index.ts                  # Construct のバレルファイル
│   │   ├── inspection-vpc.ts         # Network Firewall による検査用 VPC の Construct。send-to や send-via でトラフィックをルーティングする
│   │   ├── private-vpc.ts            # ワークロード用 VPC の Construct。prod / dev セグメントで利用
│   │   └── vpn-vpc.ts                # オンプレミス接続用 VPC の Construct。VPN Router / Site-to-Site VPN / BGP を含む
│   ├── network-config.ts             # CIDR / ASN / セグメント名 / タグキーなどStackに注入する設定を一元管理
│   ├── region1-stack.ts              # ap-northeast-1 のStack。Core Network / Egress / Prod / Dev / Inspection VPC を配置
│   └── region2-stack.ts              # us-east-1 のStack。Egress / Prod / VPN VPC を配置
├── src
│   └── ec2
│       └── vpn-router-userdata.sh    # VPN Router EC2 の UserData スクリプト。Libreswan (IPsec) / FRR (BGP) を自動セットアップ
├── test
│   └── aws-cdk-cloud-wan.test.ts     # Stackのスナップショットテスト。VPC Attachment のタグやリソース数を検証
├── cdk.context.json
├── cdk.json
├── package.json
└── tsconfig.json
us-east-1のVPCをCore NetworkにアタッチするためにCore Networkの情報を渡していますが、crossRegionReferencesを使えば簡単にクロスリージョンで値の参照を行うことができます。
./bin/aws-cdk-cloud-wan.ts
#!/usr/bin/env node
import * as cdk from 'aws-cdk-lib/core';
import { Region1Stack } from '../lib/region1-stack';
import { Region2Stack } from '../lib/region2-stack';

const app = new cdk.App();

const region1 = 'ap-northeast-1';
const region2 = 'us-east-1';

const region1Stack = new Region1Stack(app, 'CloudWanRegion1Stack', {
  env: { account: process.env.CDK_DEFAULT_ACCOUNT, region: region1 },
  region2,
  crossRegionReferences: true,
});

const region2Stack = new Region2Stack(app, 'CloudWanRegion2Stack', {
  env: { account: process.env.CDK_DEFAULT_ACCOUNT, region: region2 },
  coreNetworkId: region1Stack.coreNetworkId,
  coreNetworkArn: region1Stack.coreNetworkArn,
  crossRegionReferences: true,
});

region2Stack.addDependency(region1Stack);

詳細は以下記事をご覧ください。
https://dev.classmethod.jp/articles/cdk-cross-region-references-for-acm-and-cloudfront/
crossRegionReferencesは強い参照となることが注意点として挙げられますが、Core Networkの作り直しは元よりネットワークトポロジ全体に影響があるので、さして問題になりません。
デプロイまでは大体40分ほどかかります。Core Networkを作成するStackが25分、もう一つのStackが15分です。
コードは以下GitHubリポジトリに保存しています。
https://github.com/non-97/aws-cdk-cloud-wan
 Cloud WANの環境の確認 Global NetworkDevelopersIOにはCloud WANのやってみた系の記事が少ないので、せっかくなのでAWSマネジメントコンソールで確認できる情報を確認してみます。
まずはGlobal Networkについてです。
トポロジグラフを確認すると、以下のようにリージョンやセグメント、セグメントにアタッチしているリソースの情報を確認できます。全体のネットワーク構成を掴むのに使えますね。
ap-northeast-1をクリックすると、Core Network Edge が使用しているASNや内部CIDRブロックを確認できます。
!内部CIDRブロックはTransit Gateway Connectを利用する際に使用するものなので、本環境では使用はされません。
メトリクスを選択すると、このリージョンで流れているデータ量やパケット数などの情報を確認できます。こちらも全体感を把握するのに役立ちますね。
次にセグメントをクリックします。すると、このセグメントが紐付くCore Network Edgeのリージョンや共有しているセグメントを確認できます。
!私の旧環境のスクリーンショット分しかなかったため、shareセグメントとルート共有するように記載ありますが、実際には行っていません。
ルートを選択すると、このセグメントで設定されているルート情報を確認できます。Service Insertion の send-to アクションを設定しているので、STATICのデフォルトルートが登録されています。また、send-via アクションでProdセグメント内の別ネットワークにアクセスする際はSecurity NFGを経由するように設定しているため、PROPAGATEDのルートの送信先はInspection VPCとなっています。
参考までにdevセグメントとshareセグメントのルートは以下のとおりです。devとshareはセグメントはルートを共有しているので同じルートが設定されていますね。
適当なVPCをクリックすると、エッジロケーションやアタッチメントタイプ、所属するセグメント、適用されているアタッチメントポリシーのルール番号などの情報を確認できました。
Site-to-Site VPNをクリックした際にも同じような情報を確認できます。
なお、Site-to-Site VPNについては現在の接続の状態を確認することができます。トンネルがダウンしている場合は通常緑色のラインが赤色になり、カーソルを合わせるとCore network VPN attachment, 少なくとも 1 つの接続がダウンしていますと表示してくれます。
グローバルなネットワークにおいて全体の接続状況を一つの画面で確認できるのは嬉しいですね。
トポロジツリータブをクリックすると、ネットワークトポロジをツリー上に表現することができます。人によってはこちらの方が分かりやすいかもしれません。
 Core Network続いてCore Networkです。
まず、現在のCore Networkのポリシーは以下のようになっています。
{
  "core-network-configuration": {
    "vpn-ecmp-support": true,
    "asn-ranges": [
      "65000-65099"
    ],
    "edge-locations": [
      {
        "location": "ap-northeast-1",
        "asn": 65001
      },
      {
        "location": "us-east-1",
        "asn": 65002,
        "inside-cidr-blocks": [
          "192.168.100.0/24"
        ]
      }
    ],
    "inside-cidr-blocks": [
      "192.168.0.0/16"
    ]
  },
  "version": "2021.12",
  "attachment-policies": [
    {
      "rule-number": 100,
      "condition-logic": "or",
      "description": "attachment segment share",
      "action": {
        "association-method": "constant",
        "segment": "share"
      },
      "conditions": [
        {
          "type": "tag-value",
          "value": "share",
          "operator": "equals",
          "key": "cloudwan-seg"
        }
      ]
    },
    {
      "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": [
    {
      "name": "share",
      "require-attachment-acceptance": false,
      "edge-locations": [
        "ap-northeast-1",
        "us-east-1"
      ]
    },
    {
      "isolate-attachments": true,
      "name": "prod",
      "require-attachment-acceptance": false,
      "edge-locations": [
        "ap-northeast-1",
        "us-east-1"
      ]
    },
    {
      "name": "dev",
      "require-attachment-acceptance": false,
      "edge-locations": [
        "ap-northeast-1",
        "us-east-1"
      ]
    }
  ],
  "segment-actions": [
    {
      "mode": "attachment-route",
      "segment": "share",
      "action": "share",
      "share-with": [
        "dev"
      ]
    },
    {
      "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"
        ]
      }
    }
  ]
}
Core Network Policyのサンプルは以下AWS公式ドキュメントで紹介されています。
https://docs.aws.amazon.com/ja_jp/network-manager/latest/cloudwan/cloudwan-policy-examples.html
また、ポリシーの各パラメーターは以下AWS公式ドキュメントをご覧ください。
https://docs.aws.amazon.com/network-manager/latest/cloudwan/cloudwan-policies-json.html
マネジメントコンソールからCore Networkを選択すると、以下のように使用しているリージョンや流れているネットワークのスループット、アタッチメントの情報を確認できます。
論理タブをクリックすると、ネットワーク間の関連付けを確認することができます。
!こちらも私の旧環境のスクリーンショット分しかなかったため、ProdとShare間のルートがあるように見えていますが、実際にはありません。
Filter byのパラメーターを調整することで、ネットワーク間の到達性を確認することができます。
到達できない場合は以下のようにオレンジの線が繋がらないようになります。
ルーティング情報ベースタブをクリックすると、指定したセグメントとエッジロケーションに流れてきているルート情報を確認できます。
Local PreferenceやAS Path、MED、BGPコミュニティタグも確認できるため、Site-to-Site VPNやDirect ConnectにおいてBGPで経路交換する場合のルート情報の整理に役立ちそうです。
ルートタブをクリックすると、トポロジツリーで確認したように実際のルートを確認できます。
こちらではNFGのルートも確認できます。
イベントタブをクリックすると、Core Networkで発生したイベントログを確認することが可能です。
こちらの機能を使用する場合はイベントをログ出力するように設定する必要があります。詳細は以下AWS公式ドキュメントをご覧ください。
https://docs.aws.amazon.com/network-manager/latest/cloudwan/cloudwan-onboard-events.html
ログはオレゴンリージョンの/aws/events/networkmanagerloggrouに出力されます。
実際に記録されていたログは以下のとおりです。
Routes in one or more Segments have been installed
{
    "version": "0",
    "id": "911ea313-9caf-9588-4a11-a31b23625678",
    "detail-type": "Network Manager Routing Update",
    "source": "aws.networkmanager",
    "account": "<AWSアカウントID>",
    "time": "2026-04-25T06:37:11Z",
    "region": "us-west-2",
    "resources": [
        "arn:aws:networkmanager::<AWSアカウントID>:global-network/global-network-0530c4e133edd415a",
        "arn:aws:networkmanager::<AWSアカウントID>:core-network/core-network-01a763d8efb75dd43"
    ],
    "detail": {
        "changeType": "SEGMENT_ROUTE_INSTALLED",
        "changeDescription": "Routes in one or more Segments have been installed.",
        "edgeLocation": "us-east-1",
        "segments": [
            "share"
        ],
        "routes": [
            {
                "destinationCidrBlock": "10.102.0.0/16",
                "attachments": [
                    {
                        "attachmentId": "attachment-0cc4803245fdaeb7f",
                        "resourceId": "vpn-0687904978f1a78df",
                        "attachmentType": "vpn",
                        "vpnOutsideIpAddress": "32.195.78.94"
                    },
                    {
                        "attachmentId": "attachment-0cc4803245fdaeb7f",
                        "resourceId": "vpn-0687904978f1a78df",
                        "attachmentType": "vpn",
                        "vpnOutsideIpAddress": "32.195.78.94"
                    }
                ],
                "routeType": "route_propagated",
                "routeState": "active",
                "bgpAttributes": {
                    "med": "0",
                    "asPath": [
                        "AS_SEQ: [64901]"
                    ]
                }
            }
        ],
        "coreNetworkArn": "arn:aws:networkmanager::<AWSアカウントID>:core-network/core-network-01a763d8efb75dd43"
    }
}
BGP for a VPN connection has been established
{
    "version": "0",
    "id": "87e21c34-fb54-ec8d-038c-3486184ad41a",
    "detail-type": "Network Manager Status Update",
    "source": "aws.networkmanager",
    "account": "<AWSアカウントID>",
    "time": "2026-04-25T06:36:39Z",
    "region": "us-west-2",
    "resources": [
        "arn:aws:networkmanager::<AWSアカウントID>:global-network/global-network-0530c4e133edd415a",
        "arn:aws:networkmanager::<AWSアカウントID>:core-network/core-network-01a763d8efb75dd43",
        "arn:aws:ec2:us-east-1:712953625629:vpn-connection/vpn-0687904978f1a78df"
    ],
    "detail": {
        "changeType": "VPN_CONNECTION_BGP_UP",
        "changeDescription": "BGP for a VPN connection has been established.",
        "edgeLocation": "us-east-1",
        "attachmentArn": "arn:aws:networkmanager::<AWSアカウントID>:attachment/attachment-0cc4803245fdaeb7f",
        "vpnConnectionArn": "arn:aws:ec2:us-east-1:712953625629:vpn-connection/vpn-0687904978f1a78df",
        "outsideIpAddress": "32.195.78.94",
        "coreNetworkArn": "arn:aws:networkmanager::<AWSアカウントID>:core-network/core-network-01a763d8efb75dd43"
    }
}
IPsec for a VPN connection has come up
{
    "version": "0",
    "id": "ab55c864-d2d2-9089-6d04-0f17b5c84bf1",
    "detail-type": "Network Manager Status Update",
    "source": "aws.networkmanager",
    "account": "<AWSアカウントID>",
    "time": "2026-04-25T06:36:12Z",
    "region": "us-west-2",
    "resources": [
        "arn:aws:networkmanager::<AWSアカウントID>:global-network/global-network-0530c4e133edd415a",
        "arn:aws:networkmanager::<AWSアカウントID>:core-network/core-network-01a763d8efb75dd43",
        "arn:aws:ec2:us-east-1:712953625629:vpn-connection/vpn-0687904978f1a78df"
    ],
    "detail": {
        "changeType": "VPN_CONNECTION_IPSEC_UP",
        "changeDescription": "IPsec for a VPN connection has come up.",
        "edgeLocation": "us-east-1",
        "attachmentArn": "arn:aws:networkmanager::<AWSアカウントID>:attachment/attachment-0cc4803245fdaeb7f",
        "vpnConnectionArn": "arn:aws:ec2:us-east-1:712953625629:vpn-connection/vpn-0687904978f1a78df",
        "outsideIpAddress": "32.195.78.94",
        "coreNetworkArn": "arn:aws:networkmanager::<AWSアカウントID>:core-network/core-network-01a763d8efb75dd43"
    }
}
IPsec for a VPN connection has gone down
{
    "version": "0",
    "id": "a5cf3fe0-0e14-1ed1-e8f2-5f8d301ae277",
    "detail-type": "Network Manager Status Update",
    "source": "aws.networkmanager",
    "account": "<AWSアカウントID>",
    "time": "2026-04-25T06:30:43Z",
    "region": "us-west-2",
    "resources": [
        "arn:aws:networkmanager::<AWSアカウントID>:global-network/global-network-0530c4e133edd415a",
        "arn:aws:networkmanager::<AWSアカウントID>:core-network/core-network-01a763d8efb75dd43",
        "arn:aws:ec2:us-east-1:712953625629:vpn-connection/vpn-0687904978f1a78df"
    ],
    "detail": {
        "changeType": "VPN_CONNECTION_IPSEC_DOWN",
        "changeDescription": "IPsec for a VPN connection has gone down.",
        "edgeLocation": "us-east-1",
        "attachmentArn": "arn:aws:networkmanager::<AWSアカウントID>:attachment/attachment-0cc4803245fdaeb7f",
        "vpnConnectionArn": "arn:aws:ec2:us-east-1:712953625629:vpn-connection/vpn-0687904978f1a78df",
        "outsideIpAddress": "18.205.62.158",
        "coreNetworkArn": "arn:aws:networkmanager::<AWSアカウントID>:core-network/core-network-01a763d8efb75dd43"
    }
}

モニタリングタブをクリックすると以下のようにCore Network全体の転送データ量やパケット数を確認できます。
Core Networkのアタッチメントの一覧も表示可能です。
 疎通確認 ap-northeast-1 Prod Private VPC EC2 インスタンス と us-east-1 Prod Private VPC EC2 インスタンス以降、実際に疎通確認をします。
まず、ap-northeast-1 Prod Private VPC EC2 インスタンス と us-east-1 Prod Private VPC EC2 インスタンスの通信です。
pingを叩きます。
$ hostname -f
ip-10-1-0-180.ap-northeast-1.compute.internal

$ ping -c 4 10.101.0.38
PING 10.101.0.38 (10.101.0.38) 56(84) bytes of data.
64 bytes from 10.101.0.38: icmp_seq=1 ttl=122 time=152 ms
64 bytes from 10.101.0.38: icmp_seq=2 ttl=122 time=150 ms
64 bytes from 10.101.0.38: icmp_seq=3 ttl=122 time=150 ms
64 bytes from 10.101.0.38: icmp_seq=4 ttl=122 time=150 ms

--- 10.101.0.38 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3005ms
rtt min/avg/max/mdev = 149.811/150.464/152.267/1.041 ms
通信できましたね。
今回はisolate-attachments : trueで同一セグメント内のネットワーク間の通信を行えないようにした上で、send-via アクションでSecurity NFGを通るようにしています。
Network Firewallのアラートログを確認すると、以下のようにログが記録されていました。
{
    "firewall_name": "ClounVpc825C25AF-Nfw",
    "availability_zone": "ap-northeast-1a",
    "event_timestamp": "1777122477",
    "event": {
        "icmp_type": 8,
        "aws_category": "",
        "src_ip": "10.1.0.180",
        "src_port": 0,
        "event_type": "alert",
        "alert": {
            "severity": 3,
            "signature_id": 2000002,
            "rev": 1,
            "signature": "ICMP ping detected",
            "action": "allowed",
            "category": ""
        },
        "flow_id": 1543805544049109,
        "dest_ip": "10.101.0.38",
        "proto": "ICMP",
        "verdict": {
            "action": "pass"
        },
        "icmp_code": 0,
        "dest_port": 0,
        "pkt_src": "geneve encapsulation",
        "timestamp": "2026-04-25T13:07:57.490517+0000",
        "direction": "to_server"
    }
}
通信経路を図示すると以下のとおりです。
 ap-northeast-1 Prod Private VPC EC2 インスタンス と ap-northeast-1 Dev Private VPC EC2 インスタンス次に、ap-northeast-1 Prod Private VPC EC2 インスタンス と ap-northeast-1 Dev Private VPC EC2 インスタンスの通信です。
要するに異なるセグメント間の通信です。
$ hostname -f
ip-10-1-0-180.ap-northeast-1.compute.internal

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

--- 10.2.0.21 ping statistics ---
4 packets transmitted, 0 received, 100% packet loss, time 3152ms

はい、こちらはできませんでした。
なぜならProdセグメントとDevセグメント間でのルートの共有がないためです。
 ap-northeast-1 Dev Private VPC EC2 インスタンス と us-ast-1 VPN VPC EC2 インスタンス次にap-northeast-1 Dev Private VPC EC2 インスタンス と us-ast-1 VPN VPC EC2 インスタンスの通信です。
つまりは同一セグメント内の通信です。
$ hostname -f
ip-10-2-0-21.ap-northeast-1.compute.internal

$ ping -c 4 10.102.1.18
PING 10.102.1.18 (10.102.1.18) 56(84) bytes of data.
64 bytes from 10.102.1.18: icmp_seq=1 ttl=124 time=151 ms
64 bytes from 10.102.1.18: icmp_seq=2 ttl=124 time=148 ms
64 bytes from 10.102.1.18: icmp_seq=3 ttl=124 time=148 ms
64 bytes from 10.102.1.18: icmp_seq=4 ttl=124 time=149 ms

--- 10.102.1.18 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3004ms
rtt min/avg/max/mdev = 148.291/149.107/151.029/1.115 ms
問題なく通信できました。
なお、こちらはisolate-attachments : falseであり、send-via などのsegment-actionも設定していないため、Network Firewallは通りません。
通信経路を図示すると以下のとおりです。
 ap-northeast-1 Prod Private VPC EC2 インスタンス と インターネット間次に、ap-northeast-1 Prod Private VPC EC2 インスタンス と インターネット間の通信です。
https://checkip.amazonaws.comにアクセスをして、どの出口から出ているのかも確認します。
$ hostname -f
ip-10-1-0-180.ap-northeast-1.compute.internal

$ curl -m 5 -v https://checkip.amazonaws.com
* Host checkip.amazonaws.com:443 was resolved.
* IPv6: (none)
* IPv4: 3.0.185.196, 18.138.142.246, 52.74.183.204, 18.139.26.116, 52.74.9.231, 13.228.196.61, 52.76.181.204, 54.255.102.50
*   Trying 3.0.185.196:443...
* ALPN: curl offers h2,http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* SSL Trust Anchors:
*   CAfile: /etc/pki/tls/certs/ca-bundle.crt
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_128_GCM_SHA256 / x25519 / RSASSA-PSS
* ALPN: server accepted h2
* Server certificate:
*   subject: CN=checkip.amazonaws.com
*   start date: Nov  3 00:00:00 2025 GMT
*   expire date: Dec  2 23:59:59 2026 GMT
*   issuer: C=US; O=Amazon; CN=Amazon RSA 2048 M04
*   Certificate level 0: Public key type RSA (2048/112 Bits/secBits), signed using sha256WithRSAEncryption
*   Certificate level 1: Public key type RSA (2048/112 Bits/secBits), signed using sha256WithRSAEncryption
*   Certificate level 2: Public key type RSA (2048/112 Bits/secBits), signed using sha256WithRSAEncryption
*   subjectAltName: "checkip.amazonaws.com" matches cert's "checkip.amazonaws.com"
* SSL certificate verified via OpenSSL.
* Established connection to checkip.amazonaws.com (3.0.185.196 port 443) from 10.1.0.180 port 40244 
* using HTTP/2
* [HTTP/2] [1] OPENED stream for https://checkip.amazonaws.com/
* [HTTP/2] [1] [:method: GET]
* [HTTP/2] [1] [:scheme: https]
* [HTTP/2] [1] [:authority: checkip.amazonaws.com]
* [HTTP/2] [1] [:path: /]
* [HTTP/2] [1] [user-agent: curl/8.17.0]
* [HTTP/2] [1] [accept: */*]
> GET / HTTP/2
> Host: checkip.amazonaws.com
> User-Agent: curl/8.17.0
> Accept: */*
> 
* Request completely sent off
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
< HTTP/2 200 
< date: Sat, 25 Apr 2026 13:32:14 GMT
< content-type: text/plain;charset=UTF-8
< content-length: 13
< server: nginx
< vary: Origin
< vary: Access-Control-Request-Method
< vary: Access-Control-Request-Headers
< 
57.181.60.10
* Connection #0 to host checkip.amazonaws.com:443 left intact
無事に通信できました。
57.181.60.10というのはap-northeast-1のInspection VPCのNAT Gatewayです。
これはProdセグメントにて、send-to アクションでSecurity NFGにルーティングをしているためです。
この経路でもNetwork Firewall通ります。Network Firewallのログを確認すると、確かにこの時の通信が記録されていました。
{
    "firewall_name": "ClounVpc825C25AF-Nfw",
    "availability_zone": "ap-northeast-1a",
    "event_timestamp": "1777123934",
    "event": {
        "aws_category": "",
        "tx_id": 0,
        "app_proto": "tls",
        "src_ip": "10.1.0.180",
        "src_port": 40244,
        "event_type": "alert",
        "alert": {
            "severity": 3,
            "signature_id": 2000001,
            "rev": 1,
            "signature": "Access to checkip.amazonaws.com detected",
            "action": "allowed",
            "category": ""
        },
        "flow_id": 1802298880418392,
        "dest_ip": "3.0.185.196",
        "proto": "TCP",
        "verdict": {
            "action": "pass"
        },
        "tls": {
            "sni": "checkip.amazonaws.com",
            "version": "UNDETERMINED"
        },
        "dest_port": 443,
        "pkt_src": "geneve encapsulation",
        "timestamp": "2026-04-25T13:32:14.425631+0000",
        "direction": "to_server"
    }
}
通信経路を図示すると以下のとおりです。
 us-east-1 Prod Private VPC EC2 インスタンス と インターネット間次にus-east-1 Prod Private VPC EC2 インスタンス と インターネット間の通信です。
先ほどのパターンと異なり、送信元VPCのリージョンとInspection VPCのリージョンが異なります。
通信結果は以下のとおりです。
$ hostname -f
ip-10-101-0-38.ec2.internal

$ curl -m 5 -v https://checkip.amazonaws.com
* Host checkip.amazonaws.com:443 was resolved.
* IPv6: (none)
* IPv4: 44.194.153.254, 107.23.164.39, 98.95.253.57, 100.49.40.12, 44.214.94.248, 52.0.234.61, 54.211.239.28, 34.232.152.199
*   Trying 44.194.153.254:443...
*   Trying 107.23.164.39:443...
* ALPN: curl offers h2,http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* SSL Trust Anchors:
*   CAfile: /etc/pki/tls/certs/ca-bundle.crt
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_128_GCM_SHA256 / x25519 / RSASSA-PSS
* ALPN: server accepted h2
* Server certificate:
*   subject: CN=checkip.amazonaws.com
*   start date: Nov  3 00:00:00 2025 GMT
*   expire date: Dec  2 23:59:59 2026 GMT
*   issuer: C=US; O=Amazon; CN=Amazon RSA 2048 M04
*   Certificate level 0: Public key type RSA (2048/112 Bits/secBits), signed using sha256WithRSAEncryption
*   Certificate level 1: Public key type RSA (2048/112 Bits/secBits), signed using sha256WithRSAEncryption
*   Certificate level 2: Public key type RSA (2048/112 Bits/secBits), signed using sha256WithRSAEncryption
*   subjectAltName: "checkip.amazonaws.com" matches cert's "checkip.amazonaws.com"
* SSL certificate verified via OpenSSL.
* Established connection to checkip.amazonaws.com (44.194.153.254 port 443) from 10.101.0.38 port 43182
* using HTTP/2
* [HTTP/2] [1] OPENED stream for https://checkip.amazonaws.com/
* [HTTP/2] [1] [:method: GET]
* [HTTP/2] [1] [:scheme: https]
* [HTTP/2] [1] [:authority: checkip.amazonaws.com]
* [HTTP/2] [1] [:path: /]
* [HTTP/2] [1] [user-agent: curl/8.17.0]
* [HTTP/2] [1] [accept: */*]
> GET / HTTP/2
> Host: checkip.amazonaws.com
> User-Agent: curl/8.17.0
> Accept: */*
>
* Request completely sent off
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
< HTTP/2 200
< date: Sat, 25 Apr 2026 13:35:54 GMT
< content-type: text/plain;charset=UTF-8
< content-length: 13
< server: nginx
< vary: Origin
< vary: Access-Control-Request-Method
< vary: Access-Control-Request-Headers
<
57.181.60.10
* Connection #0 to host checkip.amazonaws.com:443 left intact
はい、先ほどと同じく57.181.60.10が返ってきました。
つまりは別リージョンであってもInspection VPCにルーティングされていることがわかります。
Network Firewallのログにも以下のように記録されていました。
{
    "firewall_name": "ClounVpc825C25AF-Nfw",
    "availability_zone": "ap-northeast-1a",
    "event_timestamp": "1777124154",
    "event": {
        "aws_category": "",
        "tx_id": 0,
        "app_proto": "tls",
        "src_ip": "10.101.0.38",
        "src_port": 43182,
        "event_type": "alert",
        "alert": {
            "severity": 3,
            "signature_id": 2000001,
            "rev": 1,
            "signature": "Access to checkip.amazonaws.com detected",
            "action": "allowed",
            "category": ""
        },
        "flow_id": 622001668079509,
        "dest_ip": "44.194.153.254",
        "proto": "TCP",
        "verdict": {
            "action": "pass"
        },
        "tls": {
            "sni": "checkip.amazonaws.com",
            "version": "UNDETERMINED"
        },
        "dest_port": 443,
        "pkt_src": "geneve encapsulation",
        "timestamp": "2026-04-25T13:35:54.573607+0000",
        "direction": "to_server"
    }
}
通信経路を図示すると以下のとおりです。
 ap-northeast-1 Dev Private VPC EC2 インスタンス と インターネット間次に、ap-northeast-1 Dev Private VPC EC2 インスタンス と インターネット間の通信です。
$ hostname -f
ip-10-2-0-21.ap-northeast-1.compute.internal

$ curl -m 5 -v https://checkip.amazonaws.com
* Host checkip.amazonaws.com:443 was resolved.
* IPv6: (none)
* IPv4: 52.74.9.231, 18.138.142.246, 52.74.183.204, 54.255.102.50, 47.131.141.155, 52.76.181.204, 3.0.185.196, 18.139.26.116
*   Trying 52.74.9.231:443...
*   Trying 18.138.142.246:443...
*   Trying 52.74.183.204:443...
*   Trying 54.255.102.50:443...
*   Trying 47.131.141.155:443...
*   Trying 52.76.181.204:443...
*   Trying 3.0.185.196:443...
*   Trying 18.139.26.116:443...
* Connection timed out after 5001 milliseconds
* closing connection #0
curl: (28) Connection timed out after 5001 milliseconds
通信に失敗しました。
これはDevセグメントからEgress VPCをデフォルトゲートウェイとするルートが存在しないためです。
Egress VPCが属するShareセグメントとルート共有をしていますが、これで共有されるのは各ネットワークリソースからPropagationするルートです。
対応として、Staticでデフォルトルートを設定してあげましょう。
Cloud WANにおけるルーティングは全て1つのCore Network Policyで制御をしています。Core Network Policyを更新します。
現在LIVEのポリシーをクリックします。
以下のようにGUIで各種情報を確認できます。
ネットワーク設定タブ

セグメントタブ

ネットワーク機能グループタブ

ルーティングポリシータブ

セグメントアクションタブ

アタッチメントポリシータブ

編集をしましょう。
Static routeを追加したいので、セグメントアクションタブをクリックします。
ルートの作成をクリックします。
今回はdevセグメントのデフォルトルートがap-northeast-1とus-east-1のEgress VPCとなるようにします。
なお、送信先はリージョン内で一つまでであるため、同一リージョンに複数のEgress VPCを用意することはできません。
destinations — Defines the list of attachments to send the traffic to, with up to one attachment-id per Region. Because a segment is a global object, you should design your routing so that every AWS Region has an attachment in the destinations list. Regions that do not have attachments in this list will receive a propagated version of this route through cross-Region peering connections, and will use the static route of another Region. This is the same case for multiple attachments that are defined across multiple remote Regions.
Core network policy version parameters in AWS Cloud WAN - AWS Network Manager
追加後のルートは以下のようになります。
Core Network PolicyのJSON上では以下が追加された形になります。
{
.
.
(中略)
.
.
  "segment-actions": [
    {
      "action": "create-route",
      "segment": "dev",
      "destination-cidr-blocks": [
        "0.0.0.0/0"
      ],
      "destinations": [
        "attachment-01f13397c9dc20640",
        "attachment-03a397f1fcd710d8d"
      ]
    },
.
.
(中略)
.
.
  ],
.
.
(中略)
.
.
}
なお、Egress VPCからの戻りのトラフィックのルートですが、こちらはShareアクションによってルート情報を共有しているため、改めてのルート追加は不要です。
ポリシーの作成をクリックすると、以下のようにエイリアスがLATESTのポリシーバージョンが作成されます。状態はReady to executeとなっています。
新しいポリシーバージョンを選択して変更セットの表示または適用をクリックします。
すると、以下のようにどのような更新があるのか確認できます。CloudFormationのChange Setと同じような感じですね。
詳細をクリックすると、具体的にどのような変更が行われるのか確認することができます。
変更セットの適用をクリックすると、新しいバージョンの適用が行われます。
2分ほど待つと、全てのイベントが完了しました。
この状態で再度https://checkip.amazonaws.comへアクセスしてみます。
$ hostname -f
ip-10-2-0-21.ap-northeast-1.compute.internal
$ 
$ curl -m 5 -v https://checkip.amazonaws.com
* Host checkip.amazonaws.com:443 was resolved.
* IPv6: (none)
* IPv4: 18.139.26.116, 52.74.9.231, 3.0.185.196, 52.74.183.204, 54.255.102.50, 47.131.141.155, 13.228.196.61, 18.138.142.246
*   Trying 18.139.26.116:443...
* ALPN: curl offers h2,http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* SSL Trust Anchors:
*   CAfile: /etc/pki/tls/certs/ca-bundle.crt
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_128_GCM_SHA256 / x25519 / RSASSA-PSS
* ALPN: server accepted h2
* Server certificate:
*   subject: CN=checkip.amazonaws.com
*   start date: Nov  3 00:00:00 2025 GMT
*   expire date: Dec  2 23:59:59 2026 GMT
*   issuer: C=US; O=Amazon; CN=Amazon RSA 2048 M04
*   Certificate level 0: Public key type RSA (2048/112 Bits/secBits), signed using sha256WithRSAEncryption
*   Certificate level 1: Public key type RSA (2048/112 Bits/secBits), signed using sha256WithRSAEncryption
*   Certificate level 2: Public key type RSA (2048/112 Bits/secBits), signed using sha256WithRSAEncryption
*   subjectAltName: "checkip.amazonaws.com" matches cert's "checkip.amazonaws.com"
* SSL certificate verified via OpenSSL.
* Established connection to checkip.amazonaws.com (18.139.26.116 port 443) from 10.2.0.21 port 38934 
* using HTTP/2
* [HTTP/2] [1] OPENED stream for https://checkip.amazonaws.com/
* [HTTP/2] [1] [:method: GET]
* [HTTP/2] [1] [:scheme: https]
* [HTTP/2] [1] [:authority: checkip.amazonaws.com]
* [HTTP/2] [1] [:path: /]
* [HTTP/2] [1] [user-agent: curl/8.17.0]
* [HTTP/2] [1] [accept: */*]
> GET / HTTP/2
> Host: checkip.amazonaws.com
> User-Agent: curl/8.17.0
> Accept: */*
> 
* Request completely sent off
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
< HTTP/2 200 
< date: Sat, 25 Apr 2026 13:56:15 GMT
< content-type: text/plain;charset=UTF-8
< content-length: 13
< server: nginx
< vary: Origin
< vary: Access-Control-Request-Method
< vary: Access-Control-Request-Headers
< 
13.113.18.78
* Connection #0 to host checkip.amazonaws.com:443 left intact
はい、今度は無事にアクセスできました。
こちらのIPアドレスはap-northeast-1のNAT GatewayのIPアドレスです。
通信経路を図示すると以下のとおりです。
 us-east-1 VPC VPC EC2 インスタンス と インターネット間最後にus-east-1 VPC VPC EC2 インスタンス と インターネット間の通信です。
$ hostname -f
ip-10-102-1-18.ec2.internal

$ curl -m 5 -v https://checkip.amazonaws.com
* Host checkip.amazonaws.com:443 was resolved.
* IPv6: (none)
* IPv4: 18.208.47.218, 98.95.253.57, 54.211.239.28, 32.193.53.71, 107.23.164.39, 44.214.94.248, 52.5.178.197, 3.226.147.200
*   Trying 18.208.47.218:443...
* ALPN: curl offers h2,http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* SSL Trust Anchors:
*   CAfile: /etc/pki/tls/certs/ca-bundle.crt
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_128_GCM_SHA256 / x25519 / RSASSA-PSS
* ALPN: server accepted h2
* Server certificate:
*   subject: CN=checkip.amazonaws.com
*   start date: Nov  3 00:00:00 2025 GMT
*   expire date: Dec  2 23:59:59 2026 GMT
*   issuer: C=US; O=Amazon; CN=Amazon RSA 2048 M04
*   Certificate level 0: Public key type RSA (2048/112 Bits/secBits), signed using sha256WithRSAEncryption
*   Certificate level 1: Public key type RSA (2048/112 Bits/secBits), signed using sha256WithRSAEncryption
*   Certificate level 2: Public key type RSA (2048/112 Bits/secBits), signed using sha256WithRSAEncryption
*   subjectAltName: "checkip.amazonaws.com" matches cert's "checkip.amazonaws.com"
* SSL certificate verified via OpenSSL.
* Established connection to checkip.amazonaws.com (18.208.47.218 port 443) from 10.102.1.18 port 59376 
* using HTTP/2
* [HTTP/2] [1] OPENED stream for https://checkip.amazonaws.com/
* [HTTP/2] [1] [:method: GET]
* [HTTP/2] [1] [:scheme: https]
* [HTTP/2] [1] [:authority: checkip.amazonaws.com]
* [HTTP/2] [1] [:path: /]
* [HTTP/2] [1] [user-agent: curl/8.17.0]
* [HTTP/2] [1] [accept: */*]
> GET / HTTP/2
> Host: checkip.amazonaws.com
> User-Agent: curl/8.17.0
> Accept: */*
> 
* Request completely sent off
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
< HTTP/2 200 
< date: Sat, 25 Apr 2026 13:59:03 GMT
< content-type: text/plain;charset=UTF-8
< content-length: 14
< server: nginx
< vary: Origin
< vary: Access-Control-Request-Method
< vary: Access-Control-Request-Headers
< 
54.80.107.232
* Connection #0 to host checkip.amazonaws.com:443 left intact
無事にアクセスできました。こちらのIPアドレスはus-east-1のEgress VPCのNAT Gatewayのものです。
これはCloud WANの評価順序として、同一の宛先IPアドレスで、転送先が異なる場合においては同一リージョンのルートを優先するためだと考えます。以下AWS公式ドキュメントではStatic Route同士での優先順については言及はされていませんが、VPCからPropagationされたルートについては同一リージョンのものが優先されると紹介されています。
Route evaluation
Cloud WAN evaluates routes at each core network edge in the following order:
The most specific route for the destination
For routes with the same destination IP address, but different targets, the following route priority is used:
Static routes
VPC-propagated routes in the same Region.
For dynamic routes received at the core network with an unequal AS path length and/or MED BGP attributes, Cloud WAN evaluates them in the following order:
AS path length
MED

For dynamic routes received at the core network with equal AS path length and MED BGP attributes, Cloud WAN evaluates them in the following order:
Direct Connect gateway-propagated routes.
Cloud WAN Connect-propagates routes in the same Region.
Site-to-Site VPN-propagated routes in the same Region.
Routes propagated from other sources, such as transit gateway peering and core network edges in other remote Regions over the AWS global infrastructure. If identical routes are received from two or more sources, a single attachment will be chosen in a deterministically random manner.


Attachments in AWS Cloud WAN - AWS Network Manager
通信経路を図示すると以下のとおりです。
 Cloud WANの環境をサッと用意したいときにAWS CDKでAWS Cloud WANの環境一式を構築してService InsertionによるNetwork Firewallの検査やインターネットのアウトバウンド通信の集約をしてみました。
Cloud WANの環境をサッと用意したいときに使ってみたください。
3つ以上のリージョンを使うパターンにおいてTransit Gatewayを使ってInter peeringするのは辛くなってきます。その際にはCloud WANを取り入れる、および移行する対応が挙げられます。以下AWS Blogsを参考に検討してみましょう。
https://aws.amazon.com/jp/blogs/networking-and-content-delivery/aws-cloud-wan-and-aws-transit-gateway-migration-and-interoperability-patterns/
また、Cloud WANについては公式ワークショップも公開されているので、こちらも試していただくとより理解が深まるかと思います。
https://catalog.us-east-1.prod.workshops.aws/workshops/3547afcd-0829-4d44-85e8-17b68d4b52bc/ja-JP
この記事が誰かの助けになれば幸いです。
以上、クラウド事業本部 コンサルティング部の のんピ(@non____97)でした!

この記事をシェアする

関連記事

AWS CDK の Connections クラスを利用してセキュリティグループルールをシンプルに書いてみた

2025.08.29

AWS CDK で VPC Block Public Access の除外設定を作成する

2025.03.23

プライベートサブネットにあるEC2にEC2 Instance Connectを利用して接続する環境をAWS CDKで構築してみた

2025.08.31

EC2 Instance Connect Endpoint で PrivateWithEgress に配置された EC2 Instance に接続する構成を AWS CDK で作成してみた

2024.09.29