こんにちは！SREとして日夜クラウドの海を泳ぎ回っている、あなた専属のテックライターです。
AWSのネットワークサービス、次から次へと新しい機能が出てきて「いったいどれを使えばいいんだ…？」と頭を抱えていませんか？特に、世界中に広がるたくさんのVPCやオフィスを繋ぐとなると、ルート表の管理だけで夜しか眠れなくなってしまいますよね。
今回は、そんなマルチVPC・マルチリージョンの複雑怪奇なネットワークを、まるでおしゃれな一軒家のようにスッキリ整理整頓してくれる、AWSの強力な武器「AWS Cloud WAN」、そしてその頭脳である「コアネットワークポリシーとセグメント分離設計」について、一緒に優しく紐解いていきましょう！
難しい専門用語はちょっと置いておいて、まずは身近な世界の例えから一歩ずつ理解していきましょうね。
—
1. そもそも「AWS Cloud WAN」ってなに？（身近な例えで理解する）
想像してみてください。あなたは、世界中にたくさんの支店（VPCやオフィス）を持つ大きなお会社の総務部長さんです。
支店A（開発チーム）から支店B（経理チーム）へ荷物を送りたいとき、そして支店C（一般公開用のWebサイト）からインターネットへ荷物を届けたいとき、どうしていますか？ 昔ながらの方法だと、すべての支店同士を専用の道路（VPNやVPCピアリング）で直接つなぐ必要があり、支店が増えるほど道路網がクモの巣のように複雑になってしまいました。
ここで登場するのが、AWS Cloud WANです。
Cloud WANは、いわば「世界中を網羅する巨大な物流センター（コアネットワーク）」を作ってくれるサービスです。各支店は、この物流センターにだけ荷物を持ち込めば、あとはセンターの優秀なAI（ポリシー）が自動的に宛先を判断し、安全なルートで荷物を届けてくれます。
セグメント分離ってなに？
さて、ここで大事なルールがあります。
「経理チームの機密書類が置いてある部屋」と「誰でも入れるエントランス（一般公開Web）」が同じ通路で繋がっていたら……セキュリティ的に大問題ですよね？
そこでセグメント分離（部屋の鍵分け）の出番です。
Cloud WANの「コアネットワークポリシー」という設計図を使うことで、「開発エリア」「経理エリア」「外部公開エリア」といったグループ（セグメント）を綺麗に分け、「開発エリアから経理エリアへは立ち入り禁止！だけど、どちらのエリアもインターネットとは通信できるよ」といった交通整理を、一元的に自動化できるのです。
—
2. コアネットワークポリシーの正体を知ろう
Cloud WANの心臓部は、「コアネットワークポリシー（Core Network Policy）」と呼ばれるJSON形式の設定ファイルです。
このファイルは、いわば「物流センターの運行マニュアル」。
「どんなグループ（セグメント）を作るか」「どのVPCやVPNをどのグループに所属させるか」「どのグループ同士の通信を許可するか」を、すべてここに書き込みます。
百聞は一見にしかず。実際のポリシーの雰囲気を、初心者向けにコメント付きのコードブロックで見てみましょう！
{
"version": "2021.12",
"core-network-configuration": {
"asn-ranges": ["64512-64555"],
"edge-locations": [
{
"location": "ap-northeast-1", // 東京リージョンを物流センターの拠点に指定
"asn": 64512
},
{
"location": "us-east-1", // バージニアリージョンも拠点に追加
"asn": 64513
}
]
},
"segments": [
{
"name": "Production", // 本番環境用の厳重なセグメント（お堅い部屋）
"description": "本番システム用の隔離されたセグメントです",
"isolate-attachments": true // デフォルトで他のセグメントとは通信させない
},
{
"name": "Development", // 開発環境用のセグメント（ワイワイした部屋）
"description": "開発・検証用のセグメントです"
}
],
"segment-actions": [
{
"action": "create-route",
"segment": "Development",
"destination-cidr-block": "0.0.0.0/0",
"destinations": ["attachment-id-or-something"] // インターネットへの抜け道などを定義
}
]
}「うわ、JSONだ……難しそう……」と思いましたか？ 大丈夫です！
要するに、edge-locations で「どの地域に拠点を置くか」を決め、segments で「どんなセキュリティレベルの部屋を作るか」を定義しているだけなんです。
—
3. 現場で役立つ！セグメント分離設計のステップ
では、実際に私たちがクラウドアーキテクトとして設計を行う際の流れを、実務に即して優しく解説します。
ステップ1：セグメント（部屋）の切り分け方針を決める
まず、システムをどのグループに分けるべきか整理します。よくあるパターンは以下の通りです。
SharedServices: 共通の監視ツールやDNS、踏み台サーバーを置く部屋Production: 顧客データや機密を扱う本番システムの部屋Development: エンジニアが自由に試行錯誤できる開発の部屋
ステップ2：アタッチメント（扉の取り付け）を行う
VPCやVPNを、Cloud WANの物流センターに接続（アタッチ）します。このとき、コンソール画面やAWS CLIから「このVPCは Production の部屋に繋ぎます」とラベルを貼ってあげます。
例えば、AWS CLIを使ってVPCをCloud WANに接続するコマンドは、以下のようなイメージです。
aws networkmanager create-core-network-policy-attachment \
--core-network-id "core-net-0123456789abcdef0" \
--edge-location "ap-northeast-1" \
--resource-arn "arn:aws:ec2:ap-northeast-1:123456789012:vpc-01112223334445556" \
--tags Key=Environment,Value=Production*※実務では、TerraformやAWS CloudFormationなどのIaC（コードによるインフラ管理）を使って宣言的に構築することがほとんどですが、やっていることはこのCLIの裏側と同じです！*
ステップ3：アタッチメントの関連付け（Association）と伝播（Propagation）
ここがCloud WANの最も賢いところです！
- 関連付け (Association): 「このVPCはどのセグメント（部屋）に属するか」を決めます。
- 伝播 (Propagation): 「どのセグメントの間で、ルート情報（宛先リスト）を教え合うか」を決めます。
ポリシーの中で「Production と Development はお互いに完全に隔離する（お互いのルート情報を教え合わない）」と設定しておけば、開発環境のVPCから本番環境のVPCへは、パケットがどうあがいても到達できません。これでセグメント分離がバッチリ完了です！
—
4. トラブルシューティングの現場から：パケットはどこへ消えた？
「ポリシーを設定したのに、なぜか通信できない！」
SREの現場では、そんなトラブルに遭遇することも珍しくありません。そんなとき、私たちはどうやって原因を突き止めるでしょうか？
1. ルートテーブルの確認: Cloud WANが自動生成したコアネットワークのルートテーブルに、目的地のIPアドレス（10.1.0.0/16 など）がちゃんと載っているかを確認します。
2. セグメントのミスマッチ: 通信元と通信先のVPCが、お互いに通信を許可し合っているセグメントに所属しているか、ポリシーの記述をもう一度じっくり読み返します。
3. AWS Network Managerのトラフィックアナライザー: 「パケットがどこでドロップされたか」を可視化してくれる便利な機能があるので、迷わずポチッと有効化してパケットの足跡を追いかけます。
難解に見えるネットワークの不具合も、一つひとつ「荷物の宛先は合っているか」「通っていい部屋の許可証を持っているか」を順番に確認していけば、必ず原因が見つかりますよ。
—
まとめ
今回は、AWS Cloud WANのコアネットワークポリシーとセグメント分離設計について、郵便配達や会社の部屋の例えを交えてお話ししました。
- Cloud WAN は、世界中のVPCや拠点をつなぐ巨大な物流センター！
- コアネットワークポリシー は、センターの運行ルールを書いた設計図（JSON）！
- セグメント分離 は、部屋ごとに鍵をかけて安全性を保つスマートな仕組み！
最初は取っつきにくく感じるクラウドネットワークですが、基本のコンセプトさえ掴んでしまえば、これほど強力で頼もしい味方はいません。
あなたのクラウドインフラストラクチャが、安全で快適なハイウェイで結ばれますように。それではまた、次の技術の海でお会いしましょう！
コメント