AWS Cloud WAN
ポリシールールと評価順序
タグベースセグメントマッピング

空港のセキュリティチェックと搭乗ゲート振り分けのたとえ話で、複雑なポリシー評価の仕組みを直感的に理解しましょう

Cloud WAN ポリシールール タグベースマッピング ANS-C01対応 SAP-C02対応

🎯 最初に押さえる4つの結論

ルールは番号順に上から評価され、最初に一致したルールだけが適用される（first-match方式）。NACLやファイアウォールと同じ動作。

条件のAND/ORで柔軟に制御。AND=全条件一致、OR=いずれか一致。複雑なマッチングを実現できる。

タグベースで自動的にセグメント振り分け。VPCにタグを付けるだけで、ポリシーが自動的に正しいセグメントへマッピング。

具体的→汎用的の順にルールを配置。具体的なルール（複数条件）を上位に、汎用的なルール（単一条件）を下位に置くのが鉄則。

✈️ たとえ話：空港セキュリティ＆搭乗ゲート振り分け

Cloud WANのポリシールールは、国際空港のセキュリティチェックと搭乗ゲート振り分けシステムにそっくりです。

✈ 空港のたとえ話で理解するCloud WANポリシー 👨‍💼 乗客（VPC） 荷物タグ付き = AWSタグ 🚪 ゲート#1 Rule 100（最優先） 🚪 ゲート#2 Rule 200 🚪 ゲート#3 Default Rule 不一致 ▼ 不一致 ▼ 一致! ✅ 承認チェック VIPラウンジ許可？ 承認OK Production Seg ✈ 国際線ターミナル 一致! 承認不要 ➡ Development Seg 🛫 国内線ターミナル 全てに一致 catch-all ➡ Default Seg 🛫 共通待合エリア 💡 ポイント整理 ① ゲートは番号順に通過 ② 最初に一致で処理確定 ③ 荷物タグで自動振り分け ④ VIPは承認が必要 ⑤ デフォルトは最終受け皿 🔸 具体的ルール → 汎用ルール の順番が鉄則！

図1: 空港のたとえ話全体像 — 乗客（VPC）がゲート（ルール）を番号順に通過し、ターミナル（セグメント）に振り分けられる

空港のたとえ ✈Cloud WAN の実際ポイント
セキュリティゲート（#1, #2, #3...）ポリシールール（Rule 100, 200, 300...）番号の小さいゲートから順に通過チェック
パスポート＋搭乗券の両方確認AND条件（tag=Prod かつ Region=us-east-1）すべての条件を満たす必要がある
ビジネスクラスまたはVIP会員OR条件（tag=Prod または tag=Staging）いずれかの条件を満たせばOK
スーツケースの荷物タグVPCに付けたAWSタグ（Environment=Prod）自動的に正しいターミナルへ振り分け
VIPラウンジ入場に承認が必要承認要求設定（require-acceptance: true）重要セグメントへの接続に承認ワークフロー
搭乗ターミナル（国内線/国際線）セグメント（Production / Development）用途ごとに分離されたネットワーク区画

🗺 全体像：VPCライフサイクルと評価フロー

VPCが作成されてからCloud WANのセグメントに配置されるまでの完全なライフサイクルを図解します。

VPCライフサイクル：作成からセグメント配置まで 📦 Step 1 VPCを作成 🏷️ Step 2 タグを付与 🔗 Step 3 アタッチメント作成 🔎 Step 4 ポリシー評価 ✅ Step 5 セグメント配置完了 VPC + サブネット を構築 Environment=Prod Team=Backend等 Cloud WANへの 接続を要求 first-match方式で ルールを順番に照合 一致したセグメントに 自動配置 🎉

図2: VPCライフサイクル — 作成 → タグ付与 → アタッチメント → ポリシー評価 → セグメント配置

ポリシールール評価の詳細フロー

ポリシールール評価フロー（first-match方式） ✈ 空港のセキュリティゲートを番号順に通過するイメージ VPC アタッチメント ✈ 到着した乗客 評価開始 Rule 100 🚪 ゲート#1（最優先） 一致？ YES ✅ Segment A 🛫 ターミナルA STOP NO Rule 200 🚪 ゲート#2 一致？ YES ✅ Segment B 🛫 ターミナルB STOP NO Rule 999（Default） 🚪 最終ゲート 常にYES Default Segment 🛫 共通ターミナル

図3: ポリシールール評価フロー — first-match方式で最初に一致したルールで処理が確定し、STOP

🔢 ルール番号と評価順序（first-match方式）

Cloud WANのポリシールールには番号が割り当てられ、小さい番号から順に評価されます。

1
Rule 100
最優先
2
Rule 200
第2優先
3
Rule 300
第3優先
∗
Rule 999
Default
first-match（最初の一致で確定）
ルール100が一致したら、ルール200以降は一切評価されません。空港ゲート#1で通過OKなら#2に行かないのと同じ。
100刻みで設計する
100刻みなら、後からルール150のように間に挿入可能。連番(1,2,3...)だと追加が困難。
順番の設計が最重要
汎用ルールを先頭に置くと、具体ルールが到達不能に。具体的→汎用的の順が鉄則。
デフォルトルール必須
どのルールにも一致しなかった場合の最終受け皿。設定しないとタグなしVPCが宙に浮く。

🔄 NACLとの比較図

Cloud WANのfirst-match方式は、NACLとまったく同じ評価ロジックです。両方を並べて理解しましょう。

first-match方式：NACL vs Cloud WAN ポリシー Network ACL（NACL） Rule 100: ALLOW Rule 200: DENY Rule 300: ALLOW Rule *: DENY ALL ➡ 一致→処理確定! ↑ 到達しない ↑ 到達しない 最終受け皿 Cloud WAN ポリシー R100: Prod→Seg A R200: Dev→Seg B R300: Stg→Seg C R999: Default Seg ➡ 一致→配置確定! ↑ 到達しない ↑ 到達しない 最終受け皿 = 同じ動作

図4: NACLもCloud WANも同じfirst-match方式 — 最初に一致したルールで処理が確定し、以降のルールは評価されない

🧰 条件の論理演算子（AND / OR）

各ルールには複数の条件を設定でき、AND（かつ）またはOR（または）で組み合わせられます。

AND条件 vs OR条件の動作比較 ✈ パスポートと搭乗券の両方チェック vs どちらか一方でOK AND条件（すべて一致が必要） 💵 パスポートと搭乗券の両方が必要 条件1: tag=Prod 📁 パスポート確認 AND 条件2: Region=us-e1 🎫 搭乗券確認 ✅ 一致 両方OK時のみ 例： tag=Prod + us-east-1 → ✅ 一致 tag=Prod + ap-ne-1 → ❌ 不一致（リージョン違い） OR条件（いずれか一致でOK） 💰 ビジネスかVIPのどちらかでOK 条件1: tag=Prod 💰 ビジネスクラス OR 条件2: tag=Staging 🌟 VIP会員 ✅ 一致 どちらかでOK 例： tag=Prod のみ → ✅ 一致（条件1がOK） tag=Staging のみ → ✅ 一致（条件2がOK）

図5: AND条件は「すべて一致」、OR条件は「いずれか一致」— 空港での確認方法の違い

AND/ORの組み合わせ戦略：ANDルール（tag=Prod AND Region=us-east-1）を上位に、ORルール（tag=Prod OR tag=Staging）を下位に配置すると、特定リージョンの本番VPCを特別扱いしつつ、残りをまとめて処理できます。

🔎 条件タイプの全体マップ

ポリシールールで使用できるすべての条件タイプを図解します。

条件タイプ（Condition Types）全体マップ ポリシールール ルールに設定できる条件タイプ 🏷️ tag-value タグのキーと値で マッチング 例: Environment=Prod 🌎 region AWSリージョンで マッチング 例: us-east-1 👤 account-id AWSアカウントIDで マッチング 例: 123456789012 📄 resource-id リソースIDで マッチング 例: vpc-0abc123def 🌟 any すべてに一致 （キャッチオール） デフォルトルール用

図6: 5つの条件タイプ — tag-value, region, account-id, resource-id, any（キャッチオール）

🏷️ タグベースセグメントマッピング

VPCに付けたタグに基づいて、アタッチメントを自動的に適切なセグメントへ振り分けます。空港の荷物タグが正しいベルトコンベアに流れるのと同じです。

タグベースセグメントマッピング 🏷 スーツケースの荷物タグで自動的にターミナルへ振り分け VPC（荷物タグ付き） ポリシーエンジン セグメント（ターミナル） VPC-A 🏷 Env = Production VPC-B 🏷 Env = Development VPC-C 🏷 Env = Staging VPC-D ❌ タグなし アタッチメントポリシー R100: Env=Prod ➡ Prod Seg R200: Env=Dev ➡ Dev Seg R300: Env=Stg ➡ Stg Seg R999: any ➡ Default Seg ▲ 高優先度　▼ 低優先度 Production Seg ✈ 国際線ターミナル Development Seg 🛫 国内線ターミナル Staging Seg 🛫 チャーターターミナル Default Seg 🛫 共通待合エリア

図7: タグベースマッピング — VPCのタグ値がポリシーエンジンで照合され、自動的に正しいセグメントへ振り分け

タグキーと値
VPCに Environment=Production のようなタグを付けます。この値がポリシー条件と照合されます。
自動マッピング
ポリシーにタグ条件を設定するだけで、VPC接続時に手動介入なしに自動振り分けされます。
階層的ルール評価
具体的→汎用的の順に配置。「Prod + us-east-1」を先に、「Prod」だけを後に評価。

🏷️ タグ命名規則ビジュアルガイド

タグの表記揺れはマッチング失敗の最大の原因です。組織全体で統一しましょう。

タグ命名規則：OK vs NG パターン ✅ OK: 統一された命名規則 Environment = Production ✅ PascalCase統一 Environment = Development ✅ フルスペル統一 Environment = Staging ✅ 値も統一 💡 ルール: キーはPascalCase、値もPascalCase、略語禁止 ❌ NG: バラバラな命名 environment = production ❌ 小文字 Env = Dev ❌ 略語 env_name = stg-01 ❌ 独自形式 🚨 表記揺れ = ポリシー不一致 = セグメント配置失敗！

図8: タグ命名の統一が自動マッピング成功の鍵 — 表記揺れは配置失敗の最大原因

👤 承認ワークフロー

特定のセグメントへの接続に管理者の承認を必須にできます。VIPラウンジ入場に上司の承認が必要なイメージです。

承認ワークフロー：自動承認 vs 手動承認 🟢 パス1: 承認不要（開発環境など） VPC接続要求 Env=Development ポリシー評価 require-acceptance: false 即座に ✅ 接続完了！ Dev Segment に配置 🔴 パス2: 承認必要（本番環境など） VPC接続要求 Env=Production ポリシー評価 require-acceptance: true ⏳ Pending 承認待ち状態 承認 ✅ 接続完了 拒否 ❌ 接続拒否 ⚡ 自動化も可能 EventBridge + Lambda

図9: 承認ワークフロー — 開発環境は自動承認、本番環境は手動承認（またはLambdaで条件付き自動化）

📈 ルール階層設計パターン

ルールを具体的→汎用的の順に並べる設計パターンを図解します。

ルール階層設計：ピラミッド型ルール配置 R100: 最も具体的 tag=Prod AND Region=us-east-1 R200: やや具体的 tag=Production（リージョン問わず） R300: 汎用的 tag=Development OR tag=Staging R999: デフォルト（キャッチオール） 条件: any — すべてに一致 ▲ 高優先度 条件が多い ▼ 低優先度 条件が少ない 💡 鉄則 1. AND条件を上に 2. OR条件を中に 3. 単一条件を下に 4. anyを最下位に 逆にすると具体ルール が到達不能に！

図10: ピラミッド型ルール配置 — 頂点が最も具体的で優先度が高く、底辺がキャッチオール

💻 設定コード例

{
  "attachment-policies": [
    {
      "rule-number": 100,
      "description": "Production VPCs in us-east-1",
      "conditions": [
        { "type": "tag-value", "operator": "equals",
          "key": "Environment", "value": "Production" },
        { "type": "region", "operator": "equals",
          "value": "us-east-1" }
      ],
      "condition-logic": "and",
      "action": {
        "association-method": "tag",
        "segment": "production",
        "require-acceptance": true
      }
    },
    {
      "rule-number": 200,
      "description": "All Development VPCs",
      "conditions": [
        { "type": "tag-value", "operator": "equals",
          "key": "Environment", "value": "Development" }
      ],
      "condition-logic": "or",
      "action": {
        "association-method": "tag",
        "segment": "development",
        "require-acceptance": false
      }
    },
    {
      "rule-number": 999,
      "description": "Default catch-all",
      "conditions": [ { "type": "any" } ],
      "condition-logic": "or",
      "action": {
        "association-method": "constant",
        "segment": "default",
        "require-acceptance": false
      }
    }
  ]
}
AWSTemplateFormatVersion: '2010-09-09'
Resources:
  CoreNetwork:
    Type: AWS::NetworkManager::CoreNetwork
    Properties:
      GlobalNetworkId: !Ref GlobalNetwork
      PolicyDocument:
        version: "2021.12"
        segments:
          - name: production
            require-attachment-acceptance: true
          - name: development
            require-attachment-acceptance: false
          - name: default
        attachment-policies:
          - rule-number: 100
            conditions:
              - type: tag-value
                key: Environment
                value: Production
              - type: region
                value: us-east-1
            condition-logic: and
            action:
              association-method: tag
              segment: production
          - rule-number: 200
            conditions:
              - type: tag-value
                key: Environment
                value: Development
            action:
              association-method: tag
              segment: development
          - rule-number: 999
            conditions:
              - type: any
            action:
              association-method: constant
              segment: default
resource "aws_networkmanager_core_network" "main" {
  global_network_id = aws_networkmanager_global_network.main.id
  policy_document = jsonencode({
    version = "2021.12"
    segments = [
      { name = "production",
        require-attachment-acceptance = true },
      { name = "development",
        require-attachment-acceptance = false },
      { name = "default" }
    ]
    attachment-policies = [
      {
        rule-number     = 100
        condition-logic = "and"
        conditions = [
          { type = "tag-value", key = "Environment",
            value = "Production", operator = "equals" },
          { type = "region", value = "us-east-1",
            operator = "equals" }
        ]
        action = { association-method = "tag",
          segment = "production",
          require-acceptance = true }
      },
      {
        rule-number = 200
        conditions = [
          { type = "tag-value", key = "Environment",
            value = "Development", operator = "equals" }
        ]
        action = { association-method = "tag",
          segment = "development" }
      },
      {
        rule-number = 999
        conditions = [ { type = "any" } ]
        action = { association-method = "constant",
          segment = "default" }
      }
    ]
  })
}

✅ ベストプラクティス vs ❌ アンチパターン

✅ ベストプラクティス

✓ 具体的→汎用の順でルール番号を設計する
✓ 100刻みでルール番号を付けて将来の追加に備える
✓ タグの命名規則を統一（PascalCase、フルスペル）
✓ デフォルトルールを必ず最後尾に配置する
✓ 本番に require-acceptance: true を設定する
✓ 変更前にポリシーのドライランで影響範囲を確認

❌ アンチパターン

✗ 汎用ルールを最上位に置き具体ルールが評価されない
✗ 連番(1,2,3...)で後から間にルール追加できない
✗ 表記揺れ（Production / production / Prod）でマッチ失敗
✗ デフォルトルールなしでタグなしVPCが宙に浮く
✗ 全セグメント承認なしで誤接続が起きる
✗ テストなしでルール変更を本番適用する

🔧 トラブルシューティング判定フロー

問題発生時の判定フローチャートで、原因を素早く特定しましょう。

トラブルシューティング判定フロー 🚨 VPCが意図したセグメントに入らない タグは正しい？ NO 🔧 タグの表記揺れ 大文字/小文字/略語確認 YES 上位ルールが 先にマッチ？ YES 🔧 ルール順番の問題 番号を調整して優先度変更 NO ステータスが Pending? YES 🔧 承認が未実行 accept-attachment実行 NO 🔧 ポリシー変更の影響 Policy Documentを比較確認 ✅ 修正ステップ タグ修正 → ポリシー再評価 ✅ 修正ステップ ルール番号を変更し再デプロイ

図11: トラブルシューティング判定フロー — 3つのチェックポイントで原因を素早く特定

📚 試験対策（ANS-C01 / SAP-C02）

🔹 first-match方式の理解
「ルール100と200の両方に一致する場合は？」→ ルール100のみ適用。NACLと同じ動作を問う問題が頻出。
🔹 AND/OR条件の区別
「tag=Prod AND Region=us-east-1」vs「tag=Prod OR Region=us-east-1」の結果の違いを正確に説明できるか。
🔹 タグベースマッピングの利点
「100以上のVPCを効率的にセグメント分けする方法は？」→ タグベースのアタッチメントポリシー。
🔹 require-acceptanceの使い分け
「本番への意図しないVPC接続を防ぐ方法は？」→ require-acceptance: true。
🔹 ルール設計の優先順位
「複数条件ルールと単一条件ルールの配置順は？」→ 具体的（複数条件）を上位に。

💬 よくある質問（FAQ）

同じルール番号を持つ複数のルールは設定できません。同じ優先度で処理したい場合は、1つのルール内でOR条件を組み合わせましょう。
2つの方法があります。(1) VPCのタグ値を変更して再評価させる。(2) ポリシールール自体を変更して再デプロイする。
タグベースの条件にマッチしないため、デフォルトルール（any条件）に到達します。デフォルトがなければどのセグメントにも入れません。
はい。EventBridge + Lambdaの組み合わせで、アタッチメント要求イベントを検知し、条件に基づいて自動的にaccept-attachment APIを呼び出せます。
Policy Documentサイズに制限がありますが、数十〜数百のルールは問題なく定義可能です。タグベースの自動マッピングでルール数を最小限に保つのが推奨です。

📖 用語集

Attachment Policy
アタッチメントをどのセグメントに振り分けるか定義するルール群
Segment
Cloud WANの論理的なネットワーク区画
first-match
最初に条件一致した時点で評価停止する方式
condition-logic
AND=全条件一致、OR=いずれか一致
require-acceptance
管理者の承認を必須にする設定
association-method
tag（タグベース）/ constant（固定割当）
Core Network Policy
セグメント・ルーティング・ポリシーのJSON文書
Edge Location
Cloud WANがデプロイされるAWSリージョン

📋 チートシート

🔢 ルール評価
小さい番号からfirst-match。100刻み設計。デフォルトを最後に。
🧰 AND / OR
AND=全条件一致。OR=いずれか。ANDルールを上位に配置。
🏷️ タグマッピング
タグ → ポリシー照合 → 自動配置。命名規則統一が重要。
👤 承認設定
本番: true、開発: false。Lambda自動承認も可能。
⚙️ 条件タイプ
tag-value / region / account-id / resource-id / any
📈 階層設計
AND条件→OR条件→単一条件→any の順で配置。

Created by SSuzuki1063

AWS SAP Learning Resources