ANS-C01 対応 読了時間 約15分

Cloud WAN
スタティックルーティングと
セグメント共有

コアネットワークポリシーでルーティングを思い通りにコントロールする方法を
「ショッピングモール」のたとえ話で完全理解

1. まず結論：押さえるべき4つのポイント

セグメント共有は双方向がデフォルト

2つのセグメントを共有すると、相互にルートが自動広告される。一方向にしたい場合は deny-filter で制御する。

スタティックルートは共有されない

attachment-route モードでは、直接接続されたアタッチメントのルートのみが共有対象。スタティックルートは各セグメントで個別に定義が必要。

ブラックホールルートは伝搬されない

create-route で blackhole を指定すれば特定 CIDR 宛トラフィックをドロップできるが、リージョン間では伝搬されない。

セグメントはグローバルオブジェクト

1つのリージョンにルートがあれば他リージョンにもクロスリージョンピアリング経由で伝搬。全リージョンで一貫したルーティングが基本思想。

2. たとえ話：ショッピングモールで理解するCloud WAN

Cloud WAN のセグメントとルーティングの仕組みを、大型ショッピングモールに例えてみましょう。モール内の各ゾーン（フード、ファッション、エンタメ等）がセグメントに対応し、ゾーン間の通路やフロアマップの看板がルーティングに対応します。

ショッピングモールで理解するCloud WAN ゾーン = セグメント ／ 通路 = 共有 ／ 看板 = ルーティング セグメント(ゾーン) ルーティング(案内・制御) 🍜 フードゾーン = Production セグメント 👗 ファッションゾーン = Dev セグメント 🎮 エンタメゾーン = Shared セグメント 📌 固定の案内看板 = スタティックルート 🚶 ゾーン間の共有通路 = セグメント共有 🚫 立入禁止 = ブラックホールルート
ショッピングモールCloud WAN説明
モール全体コアネットワークすべてのゾーン（セグメント）を包括するネットワーク基盤
フロアのゾーンセグメント用途別に分離されたルーティングドメイン。デフォルトでは同ゾーン内テナントだけが相互通信可能
ゾーン間の共有通路セグメント共有（share）通路を開けると双方向に往来可能。一方通行にしたい場合は deny-filter で制限
固定の案内看板スタティックルート特定のCIDR宛トラフィックを明示的に指定アタッチメントに誘導
「立入禁止」看板ブラックホールルート特定CIDR宛トラフィックを破棄。行き先なしでドロップ
テナント（各店舗）アタッチメントセグメントに接続されたVPC、VPN、Direct Connect Gateway等
各地の支店エッジロケーションセグメントはグローバルだが物理的にはリージョンごとにエッジが存在
閉鎖されたゾーンisolate-attachments同ゾーン内テナント同士も往来禁止。外部との共有通路のみ利用可
入館許可リストallow-filter / deny-filterどのゾーンからの客を受け入れるか・拒否するかの明示ルール

3. セグメント共有（Segment Sharing）の仕組み

セグメント共有は、異なるセグメントのアタッチメント同士が通信できるようにする機能です。モールのゾーン間に通路を開けるイメージで、デフォルトでは双方向の往来が可能になります。

セグメント共有アーキテクチャ 🏭「ゾーン間の共有通路」 Cloud WAN Core Network VPC-S (Shared) Shared Services セグメント（共有元） Prod 本番環境 Dev 開発環境 Test テスト環境 VPC-A (Prod) VPC-B (Dev) VPC-C (Test) share share share ✕ ✕ ルート広告 戻りルート 接続 ✕ 直接共有なし（配列内セグメント間）

share-with 配列の重要制約

share-with に ["Prod","Dev","Test"] と指定した場合、各セグメントは Shared Services と通信可能ですが、Prod ↔ Dev、Dev ↔ Test の直接通信はできません。モールで例えると「各ゾーンから中央ラウンジは行けるが、ゾーン間に直通路はない」状態です。Prod ↔ Dev 間も必要なら、別途 share アクションを追加します。

セグメント共有の処理フロー

1

share アクション定義

ポリシーJSONで共有元と share-with を指定

2

双方向ルート広告

アタッチメントルートが相互セグメントへ自動伝搬

3

attachment-route

直接接続のルートのみ共有。スタティックは対象外

4

フィルタで微調整

deny/allow-filter で一方向制御やアクセス制限を追加

4. deny-filter / allow-filter で一方向制御

セグメント共有はデフォルトで双方向ですが、deny-filter を使えば一方向化できます。モールで例えると「ファッションゾーンからフードゾーンに行けるが、フードゾーンからは戻れない（入館許可リストに載っていない）」という状態です。

deny-filter による一方向共有 🔒「入館拒否リスト」 shared-services deny-filter: ["test"] 🚫 test からのルートを拒否 test テスト環境セグメント ✅ ルート広告OK ❌ deny-filter で拒否 💡 deny-filter はセグメント定義内で指定。share アクション後に適用される。 allow-filter と deny-filter は同時使用不可。用途に応じて選択すること。

deny-filter

指定セグメントからのルートを拒否。「この客は入れない」リスト。share 後に適用されるため、share 定義自体は必要。

allow-filter

指定セグメントからのルートのみ許可。「この客だけOK」リスト。deny-filter との同時利用は不可。

5. スタティックルーティング（create-route）

スタティックルートは、セグメント内に手動で固定のルートエントリを作成する機能です。モールで例えると「特定の行き先を指す固定の案内看板」。動的に変わるのではなく、管理者が明示的に設置します。

スタティックルーティング 📌「固定の案内看板」 Prod セグメント（グローバル） us-east-1 エッジ ルートテーブル 10.1.0.0/16 → VPC-1 10.2.0.0/16 → VPC-2 10.99.0.0/16 → BH blackhole us-west-2 エッジ ルートテーブル 10.1.0.0/16 → (伝搬) 10.3.0.0/16 → VPC-3 伝搬ルートで到達可能 ap-northeast-1 ルートテーブル 10.1.0.0/16 → (伝搬) 10.4.0.0/16 → VPC-4 10.99.0.0/16 → BH blackhole 伝搬 伝搬 VPC-1 10.1.0.0/16 VPC-3 10.3.0.0/16 Blackhole 10.99.0.0/16 → DROP 💡 スタティックルートは create-route で各セグメントに個別定義。ブラックホールはリージョン間で伝搬されない。 ローカルにアタッチメントがないリージョンは、クロスリージョンピアリング経由で別リージョンの経路を利用

最重要ポイント：スタティックルートとセグメント共有の関係

セグメント共有（share）の attachment-route モードでは、直接接続されたアタッチメントのルートだけが共有されます。スタティックルートは共有対象外。複数セグメントで同じスタティックルートが必要な場合は、それぞれのセグメントで個別に create-route 文を記述してください。

6. isolate-attachments 🏭「閉鎖されたゾーン」

isolate-attachments を true にすると、同じセグメント内のアタッチメント同士が通信できなくなります。モールで例えると「同じゾーン内のテナント同士にも壁がある」状態です。外部セグメントとの share ルートやスタティックルート経由でのみ通信可能になります。

isolate-attachments: true 🔒「壁のあるゾーン」 Dev セグメント (isolate-attachments: true) VPC-A VPC-B VPC-C ✕ ✕ Shared Services share 経由でのみ到達可能

7. コアネットワークポリシー JSON / CLI 例

セグメント共有の設定

// Shared Services を Prod, Dev と共有
{
  "segment-actions": [
    {
      "action": "share",
      "mode": "attachment-route",
      "segment": "shared-services",
      "share-with": ["prod", "dev"]
    }
  ]
}
// ※ prod と dev の間では直接共有されない
// ※ スタティックルートは共有対象外
// 全セグメントと共有（dev, prod を除外）
{
  "segment-actions": [
    {
      "action": "share",
      "mode": "attachment-route",
      "segment": "shared-services",
      "share-with": {
        "except": ["dev", "prod"]
      }
    }
  ]
}
// "*" 全セグメントから except で指定分を除外
// deny-filter で test→shared の一方向を遮断
{
  "segments": [
    {
      "name": "shared-services",
      "deny-filter": ["test"]
    },
    { "name": "test" }
  ],
  "segment-actions": [
    {
      "action": "share",
      "mode": "attachment-route",
      "segment": "shared-services",
      "share-with": ["test"]
    }
  ]
}
// shared→test: OK / test→shared: 拒否

スタティックルート / ブラックホール

{
  "segment-actions": [
    {
      "action": "create-route",
      "segment": "prod",
      "destination-cidr-blocks": ["10.1.0.0/16"],
      "destinations": ["attachment-0abc123def456"],
      "description": "Route to on-prem via VPN"
    }
  ]
}
// 各リージョンに1アタッチメント推奨
{
  "segment-actions": [
    {
      "action": "create-route",
      "segment": "prod",
      "destination-cidr-blocks": ["10.99.0.0/16"],
      "destinations": ["blackhole"],
      "description": "Block legacy CIDR"
    }
  ]
}
// ⚠ ブラックホールはリージョン間で伝搬されない
// 必要な全リージョンで個別定義すること
// 複数セグメントに同じルートが必要→個別定義
{
  "segment-actions": [
    {
      "action": "create-route",
      "segment": "prod",
      "destination-cidr-blocks": ["10.1.0.0/16"],
      "destinations": ["attachment-aaa111"]
    },
    {
      "action": "create-route",
      "segment": "dev",
      "destination-cidr-blocks": ["10.1.0.0/16"],
      "destinations": ["attachment-bbb222"]
    }
  ]
}
// share ではスタティックルート非伝搬のため必須
# ポリシーバージョンの作成と適用

# 1. 現在のポリシーを取得
aws networkmanager get-core-network-policy \
  --core-network-id core-network-0abc123 \
  --output json > current-policy.json

# 2. ポリシーを更新（JSONファイルを編集後）
aws networkmanager put-core-network-policy \
  --core-network-id core-network-0abc123 \
  --policy-document file://updated-policy.json

# 3. ポリシーバージョンの変更セットを確認
aws networkmanager get-core-network-change-set \
  --core-network-id core-network-0abc123 \
  --policy-version-id 2

# 4. ポリシーを実行（LIVE適用）
aws networkmanager execute-core-network-change-set \
  --core-network-id core-network-0abc123 \
  --policy-version-id 2

統合ポリシー JSON 例（end-to-end）

{
  "version": "2021.12",
  "core-network-configuration": {
    "vpn-ecmp-support": true,
    "dns-support": true,
    "asn-ranges": ["65000-65100"],
    "edge-locations": [
      { "location": "us-east-1" },
      { "location": "us-west-2" },
      { "location": "ap-northeast-1" }
    ]
  },
  "segments": [
    {
      "name": "prod",
      "require-attachment-acceptance": true
    },
    {
      "name": "dev",
      "isolate-attachments": true,
      "require-attachment-acceptance": false
    },
    {
      "name": "shared-services",
      "deny-filter": ["dev"]
    }
  ],
  "segment-actions": [
    {
      "action": "share",
      "mode": "attachment-route",
      "segment": "shared-services",
      "share-with": ["prod", "dev"]
    },
    {
      "action": "create-route",
      "segment": "prod",
      "destination-cidr-blocks": ["10.0.0.0/8"],
      "destinations": ["attachment-vpn001"]
    },
    {
      "action": "create-route",
      "segment": "prod",
      "destination-cidr-blocks": ["10.99.0.0/16"],
      "destinations": ["blackhole"]
    }
  ],
  "attachment-policies": [
    {
      "rule-number": 100,
      "conditions": [
        { "type": "tag-value",
          "operator": "equals",
          "key": "env",
          "value": "prod" }
      ],
      "action": {
        "association-method": "constant",
        "segment": "prod"
      }
    },
    {
      "rule-number": 200,
      "conditions": [
        { "type": "tag-value",
          "operator": "equals",
          "key": "env",
          "value": "dev" }
      ],
      "action": {
        "association-method": "constant",
        "segment": "dev"
      }
    }
  ]
}

8. ベストプラクティス ＆ アンチパターン

全リージョンにアタッチメントを配置

スタティックルートの destinations に各リージョンのアタッチメントを含め、クロスリージョン伝搬に頼らず最適パスを確保。

スタティックルートの共有を期待

attachment-route モードではスタティックルートは共有対象外。各セグメントで明示的に create-route を記述。

deny-filter で一方向共有を実現

セグメント定義の deny-filter で片方向のルート広告を遮断。セキュリティ境界の設計に活用。

share-with配列内の直通を期待

share-with ["A","B"] でも A↔B 間は共有されない。必要なら別途 share アクションを追加。

ブラックホールを全必要リージョンに定義

ブラックホールルートは伝搬されない。セキュリティ上必要なら全エッジロケーションで個別定義。

1セグメント＝1アタッチメントの乱立

セグメントはグローバルオブジェクト。同じルーティング要件のアタッチメントは同一セグメントにまとめる。

ポリシー適用前に変更セットを確認

get-core-network-change-set で差分確認してから execute。本番環境への影響を事前に把握。

allow-filter と deny-filter の同時使用

1つのセグメントで両方は指定不可。要件に応じてどちらか一方を選択。

9. トラブルシューティング

共有先にルートが表示されない

症状: share を設定したのに、共有先セグメントのルートテーブルにルートが出ない

確認1: そのルートはスタティックルートではないか？ attachment-route モードではスタティックルートは共有対象外。

確認2: deny-filter / allow-filter がルートをブロックしていないか確認。

確認3: アタッチメントが正しいセグメントに関連付けられているか確認。

ブラックホールが効かないリージョンがある

症状: 一部リージョンでブラックホール対象 CIDR 宛のトラフィックが通過する

原因: ブラックホールルートはリージョン間で伝搬されない。

対処: 必要な全リージョンに個別に create-route (blackhole) を定義する。

ポリシー適用でエラーが発生

症状: put-core-network-policy で ValidationException が返る

確認1: allow-filter と deny-filter を同時に指定していないか。

確認2: セグメント名が segments 定義と一致しているか（大文字小文字に注意）。

確認3: edge-locations が core-network-configuration のサブセットであるか。

isolate-attachments でも通信できる

症状: isolate-attachments: true にしたのに同セグメント内で通信可能

確認: ルートテーブルアタッチメントからのルートは isolate-attachments の影響を受けない。ルートテーブルの管理は利用者の責任。

10. ANS-C01 試験対策 Tips

出題されやすいポイント

Q: セグメント共有でスタティックルートが伝搬されないのはなぜ？ → attachment-route モードでは直接接続のアタッチメントルートのみ共有。スタティック・他セグメント経由のルートは対象外。各セグメントで create-route を個別定義する。

Q: share-with の配列内セグメント同士は通信できるか？ → できない。共有元セグメントと各配列セグメント間のみ。配列内のセグメント同士の通信には別途 share が必要。

Q: ブラックホールルートはクロスリージョン伝搬されるか？ → されない。AWS公式ドキュメントに明記。全リージョンで個別定義が必要。

Q: 一方向のセグメント共有を実現するには？ → segments 定義で deny-filter を使う。share アクション後に適用されるフィルタ。allow-filter との同時使用は不可。

Q: isolate-attachments の影響範囲は？ → 同セグメント内のアタッチメント間通信を遮断。ただしルートテーブルアタッチメントからのルートには影響しない。

引っかけパターン

「share を設定すればスタティックルートも共有される」 → 誤り。attachment-route モードはアタッチメントルートのみ。

「ブラックホールは1リージョンで定義すれば全リージョンに効く」 → 誤り。伝搬されないため個別定義が必要。

「allow-filter と deny-filter を組み合わせてきめ細かく制御」 → 誤り。同時使用は不可。

11. よくある質問（FAQ）

仕様どおりの動作です。attachment-route モードでは直接接続されたアタッチメントのルートのみ共有されます。スタティックルートは各セグメントで create-route により個別定義してください。

セグメント定義で deny-filter を使います。例: prod セグメントに "deny-filter": ["dev"] を追加すると、dev → prod のルート広告が遮断され、prod → dev のみ維持されます。

いいえ。ブラックホールルートはクロスリージョンで伝搬されません。必要な全リージョンで個別に定義してください。

いいえ。共有元セグメントとの間でのみ共有されます。配列内のセグメント同士の通信が必要な場合は別途 share アクションを追加してください。

同一セグメント内のアタッチメント同士が通信不可に。share 経由の他セグメントルートやスタティックルートでのみ外部と通信できます。ルートテーブルアタッチメントからのルートは影響を受けません。

ポリシーバージョン "2025.11" が必要です。BGPコミュニティサポートも有効になります。新規構築では 2025.11 を推奨します。

except は share-with 内で「全セグメントから特定セグメントを除外」する指定。deny-filter はセグメント定義内で「特定セグメントからのルート受信を拒否」する指定。except は共有の対象制御、deny-filter は受信後のフィルタリングという違いがあります。

12. 用語集

コアネットワーク（Core Network）
Cloud WAN が管理するグローバルネットワーク。セグメントやエッジを含む最上位の概念。
セグメント（Segment）
用途別に分離されたルーティングドメイン。デフォルトでは同セグメント内のアタッチメントのみ相互通信可能。
エッジロケーション（Edge Location）
各AWSリージョンに作成されるCore Network Edge。アタッチメントの接続点。
アタッチメント（Attachment）
コアネットワークに接続するリソース。VPC、VPN、Direct Connect Gateway、Connect、ルートテーブルの5種類。
attachment-route モード
セグメント共有の唯一のモード。直接接続されたアタッチメントのルートのみが共有対象。
ブラックホールルート
create-route で destinations に "blackhole" を指定し、対象CIDRのトラフィックを破棄するルート。
deny-filter
セグメント定義内で指定。特定セグメントからのルート受信を拒否し、一方向共有を実現。
allow-filter
セグメント定義内で指定。特定セグメントからのルートのみ受信許可。deny-filterとの同時使用は不可。
isolate-attachments
セグメント定義内で true に設定すると、同セグメント内アタッチメント間の通信を遮断。
ルーティングポリシー
バージョン 2025.11 で利用可能。ルートのフィルタ・修正・制御をきめ細かく定義する機能。

チートシート

share アクション

セグメント間のアタッチメントルートを双方向共有。mode は attachment-route のみ。share-with に配列 or except 指定。

create-route

スタティックルート追加。destinations にアタッチメントID or "blackhole"。リージョンごとに1アタッチメント推奨。

deny / allow-filter

segments定義内で指定。deny は拒否リスト、allow は許可リスト。同時使用不可。share後に適用。

ブラックホールルート

destinations を "blackhole" に。トラフィック破棄。伝搬されないので各リージョンで個別定義。

isolate-attachments

true で同セグメント内通信遮断。share経由 or スタティックルートのみ。ルートテーブルアタッチメントは影響外。

ポリシーバージョン

2021.12: 基本機能。2025.11: ルーティングポリシー + BGPコミュニティ。新規は2025.11推奨。

Created by SSuzuki1063

AWS SAP Learning Resources