AWS Cloud WANで実現するマルチVPC・オンプレミスの要塞ネットワーク：コアネットワークポリシーとセグメント分離の深層
こんにちは。幾多のネットワーク障害で冷や汗をかき、深夜のパケットキャプチャとルータのログ解析に青春を捧げてきたシニアSREの私だ。
クラウドの規模が拡大するにつれ、VPCの数は増え、オンプレミスとの専用線（AWS Direct Connect）や拠点間VPN（AWS Site-to-Site VPN）との接続要件は複雑怪奇を極めていく。かつては、何十個ものTransit Gateway（TGW）をピアリングさせ、静的ルートの嵐やルートテーブルの伝播（Propagation）のコンフリクトに頭を悩ませたものだ。
「開発環境から本番環境のDBへの通信を物理的・論理的に完全に遮断しつつ、共通の監視ツールやセキュリティアプライアンスからのアクセスだけは全セグメントに許可したい」
こうした要求に対し、従来のTGWではアタッチメントごとのルートテーブル制御を泥臭く手動、あるいは複雑なLambdaによる自動化で乗り切る必要があった。そこで登場したのが AWS Cloud WAN だ。今回は、Cloud WANの心臓部である「コアネットワークポリシー（Core Network Policy）」を駆使し、美しく、かつ鉄壁のセグメント分離設計をどう実装するか、実務の現場目線で徹底的に解説しよう。
—
1. Cloud WANコアネットワークポリシーの全体像と「セグメント」という概念
Cloud WANは、グローバル規模のAWSバックボーンネットワーク上で、VPCやVPN、Direct Connect（DX）を一元管理するためのマネージドSD-WANサービスだ。このアーキテクチャの根幹を成すのが Core Network Policy (CNP) である。
CNPは、JSON形式で記述される「ネットワークの設計図」だ。これには大きく分けて以下の3つの要素が定義される。
1. セグメント（Segments）: トラフィックを論理的に分離する空間。例えば、production、development、shared-services のように分ける。
2. アタッチメントのルーティング（Attachments & Edge/Segment Associations）: どのVPCやVPNをどのセグメントに所属させるかを決めるルール。
3. セグメント間ルーティング（Segment Actions / Sharing）: どのセグメント同士の通信を許可（あるいは拒否）するかのポリシー。
従来のTGWルートテーブルが「宛先ベースのルータ的発想」だったのに対し、Cloud WANのCNPは「意図に基づくポリシーベース（Intent-based）のネットワーク管理」を実現する。パケットがどこから来てどこへ行くべきかを、宣言的に定義できるのが最大の強みだ。
—
2. 徹底解説：実務で使えるセグメント分離ポリシー（JSON）
百聞は一見に如かず。実際に本番・開発・共通基盤の3つのセグメントに分離し、共通基盤からのみ各セグメントへアクセス可能な（かつ開発から本番へは一切通信できない）堅牢なコアネットワークポリシーのサンプルを見てほしい。
以下のJSONをCloud WANのコアネットワークポリシーとして適用する。
{
"version": "2021.12",
"core-network-configuration": {
"asn-ranges": [64512, 64513],
"edge-locations": [
{
"location": "us-east-1",
"asn": 64512
},
{
"location": "ap-northeast-1",
"asn": 64513
}
]
},
"segments": [
{
"name": "production",
"description": "本番環境用セグメント。極めて厳格なアクセス制御を適用。",
"isolate-attachments": true
},
{
"name": "development",
"description": "開発・検証環境用セグメント。"
},
{
"name": "shared-services",
"description": "監視、CI/CD、踏み台などの共通基盤セグメント。"
}
],
"segment-actions": [
{
"action": "share",
"segment": "shared-services",
"mode": "attachment-route",
"share-with": [
"production",
"development"
],
"description": "共通基盤セグメントのルートを本番および開発セグメントに共有し、一方向の通信（またはサービス提供）を可能にする"
}
],
"attachment-policies": [
{
"rule-number": 100,
"condition": {
"tag": [
{
"key": "Environment",
"operator": "equals",
"value": "Production"
}
]
},
"action": {
"segment": "production"
}
},
{
"rule-number": 200,
"condition": {
"tag": [
{
"key": "Environment",
"operator": "equals",
"value": "Development"
}
]
},
"action": {
"segment": "development"
}
},
{
"rule-number": 300,
"condition": {
"tag": [
{
"key": "Environment",
"operator": "equals",
"value": "Shared"
}
]
},
"action": {
"segment": "shared-services"
}
}
]
}パラメーターの深掘りポイント
isolate-attachments: true(productionセグメント):
同じ production セグメントに所属するVPC同士であっても、デフォルトでは直接通信させず、完全に孤立（Isolate）させたい場合に指定する。マイクロセグメンテーションを徹底したいPCI-DSS環境や金融系システムで非常に重宝する設定だ。
segment-actionsのshare:
shared-services のルートを production と development に共有している。これにより、共通基盤側（例: 監視サーバーやパッチ配信用リポジトリ）から各VPCへの接続経路が自動生成される。逆に、本番から開発への逆方向の共有定義は書いていないため、パケットはルーティングされない。
—
3. 実運用における通信フローとデバッグの極意
Cloud WAN環境下でトラブル（「開発VPCから共通基盤のログ収集サーバーにアクセスできない！」など）が発生した際、SREがどのような手順でパケットの生死を追うべきか、そのシーケンスと実務Tipsを授けよう。
トラブルシューティング・シーケンス
1. クライアントVPCのルートテーブル確認:
VPCのルートテーブルに、Cloud WAN（network-manager のコアルータ）をターゲットとした経路（例: 10.100.0.0/16 -> tgw-attach-xxxx あるいは Cloud WAN用プレフィックスリスト）が正しく存在するか確認する。
2. Cloud WANのセグメントビュー確認:
AWSコンソール（またはAWS CLI）で、当該アタッチメントが意図したセグメント（例: development）にアタッチされているか、タグ評価が正しく行われているかをチェックする。
3. セグメント間ルーティングの確認:
宛先VPCのCIDRが、送信元セグメントのルーティングテーブルに「共有（Shared）」として伝播しているかを検証する。
4. VPCフローログ & Security Group / NACL:
Cloud WAN自体の転送に問題がない場合、原因の大半は宛先EC2/リソースの セキュリティグループ（Security Group） や ネットワークACL によるドロップである。VPCフローログで REJECT されてないかを dstAddr や dstPort でフィルターして確認する。
設定適用・検証用のAWS CLIコマンド例
ポリシーの変更やアタッチメントのステータス確認は、コンソールをポチポチするよりもCLIやTerraformで迅速に行うのがSREの流儀だ。現在のアタッチメントの状態をJSONでスナップショットとして抜き出すコマンドを載せておく。
# Cloud WANのコアネットワークIDを指定して、アタッチメントの一覧と現在のセグメント所属状況をJSONで取得する
aws networkmanager get-network-resource-relationships \
--core-network-id "core-net-0123456789abcdef0" \
--output json \
| jq '.RelationshipRelationships[] | select(.Resource-type == "attachment")'※実務では、このアタッチメント作成時に自動付与されるリソースタグ（上のポリシー例で言う Environment=Production など）が、CI/CDパイプライン（TerraformやAWS CDK）側で正しく付与されていることが前提となる。タグの付け忘れがセグメント誤所属（一番多いヒューマンエラー）を引き起こすため、AWS OrganizationsのTag PoliciesやSCPで厳格にガードしておこう。
—
4. まとめ：インフラエンジニアがCloud WANを選ぶ理由
これまでのAWSネットワーク設計は、VPCが増えるたびにルートテーブルのルール行数が増え、夜な夜なルートの重複やループに頭を抱える「職人芸」の領域だった。
しかし、AWS Cloud WANのコアネットワークポリシーを用いたセグメント分離設計を取り入れることで、ネットワークの意図（Intent）をコードとしてバージョン管理し、組織横断のセキュリティガバナンスをプログラム的に強制することが可能になる。
「インフラをコードで定義し、セキュリティはポリシーで担保する」。
このモダンな境地へシフトするために、ぜひ今日のプロジェクトからCloud WANの導入を検討してみてほしい。君の夜間対応が減ることを、心から祈っている。
コメント