🌐 AWS Advanced Networking Specialty

🛫 AWS Cloud WAN
アタッチメント承認ポリシー完全ガイド

国際空港の入国審査システムにたとえて、VPCアタッチメントの承認ルールと条件ロジックを分かりやすく解説します

🎯 結論ファースト：正解のポイント

1
ルール番号100（優先度高）で us-east-1 の本番環境への承認を要求する
2
条件ロジックは「AND」を使用（Production かつ us-east-1 の両方を満たす場合のみマッチ）
3
ルール番号200（優先度低）で他のすべてのアタッチメントを承認不要として自動承認

✈️ 国際空港の入国審査でたとえると...

AWS Cloud WANのアタッチメント承認ポリシーを、国際空港ネットワークの入国審査システムに置き換えて考えてみましょう。VPCが空港に到着する「飛行機」、セグメントが「ターミナルの各ウィング」と考えると理解しやすくなります。

🌐
AWS Cloud WAN
↕️
国際空港ネットワーク
世界中の空港を接続する統一された航空ネットワーク
🏢
エッジロケーション
↕️
各都市のターミナルビル
us-east-1 = ニューヨーク空港、ap-southeast-2 = シドニー空港
🚪
セグメント
↕️
ターミナルのウィング（翼）
Development棟、Production棟、SharedServices棟と分かれている
✈️
VPCアタッチメント
↕️
到着する飛行機
タグで行き先（どの環境ウィングか）が決まっている
🛂
承認ポリシー
↕️
入国審査ルール
どの飛行機にVIP審査が必要か決める規則
🔢
ルール番号
↕️
チェックの優先順位
番号が小さいほど先にチェックされる

🏗️ 空港ネットワーク構成図

🗽 ニューヨーク空港
us-east-1 リージョン
🔧 Development ウィング（開発）
🔒 Production ウィング（本番）⚠️ VIP審査必須
🤝 SharedServices ウィング（共有）
🦘 シドニー空港
ap-southeast-2 リージョン
🔧 Development ウィング（開発）
✅ Production ウィング（本番）自動通過OK
🤝 SharedServices ウィング（共有）
🛬 VPCアタッチメント（飛行機）の入国審査フロー
✈️
VPCが
アタッチ要求
→
🏷️
タグ確認
(Environment)
→
📋
ルール番号順に
条件チェック
→
🚪
セグメントに
接続完了

📋 承認ルールの詳細設計

ルール 100 🥇 最優先でチェック
🔐 承認を要求（Require Acceptance）
🎯 条件設定
🏷️ Tag (Environment)
Production
AND
🌍 Region
us-east-1
💡 空港でたとえると...

「ニューヨーク空港」の「Production棟」に着陸しようとする飛行機だけは、必ずVIP入国審査（手動承認）が必要です。両方の条件を満たした場合のみこのルールが適用されます。

ルール 200 🥈 次にチェック
✅ 承認不要（Auto Accept）
🎯 条件設定
🏷️ Tag (Environment)
任意の値（ワイルドカード）
💡 空港でたとえると...

ルール100に該当しなかった残りすべての飛行機は、自動ゲート（承認不要）で通過できます。Development、SharedServices、または他リージョンのProductionはすべてここで処理されます。

⚖️ AND条件 vs OR条件の違い

✅ AND条件（正解）
Production かつ us-east-1
✅ 要件を正確に満たす
✅ us-east-1 + Production → 承認必要
⬜ us-east-1 + Development → 自動承認
⬜ ap-southeast-2 + Production → 自動承認
⬜ ap-southeast-2 + Development → 自動承認
❌ OR条件（不正解）
Production または us-east-1
❌ 範囲が広すぎる
⚠️ us-east-1 + Production → 承認必要
⚠️ us-east-1 + Development → 誤って承認必要
⚠️ ap-southeast-2 + Production → 誤って承認必要
⬜ ap-southeast-2 + Development → 自動承認

🔄 ルール評価の順序

1
VPCアタッチメント要求の受信
新しいVPCがCloud WANコアネットワークへの接続を要求。Environment タグが付与されている。
2
ルール100をチェック（番号が小さい順）
Tag=Production AND Region=us-east-1 の両方を満たすか確認。マッチすれば承認待ちになり、ルール評価終了。
3
ルール200をチェック
ルール100にマッチしなかった場合、ルール200で評価。ワイルドカードですべてにマッチするため、自動承認。
4
セグメントへの接続
承認済み（自動または手動）のVPCは、指定されたセグメントに接続完了。

🧪 シナリオ別の動作確認

🔴 シナリオ1：us-east-1 の Production VPC
📍 us-east-1 🏷️ Environment=Production
📋 ルール100チェック：Production ✅ AND us-east-1 ✅
🎯 条件マッチ！ルール100を適用
⏳ 承認待ち（手動承認が必要）
🟢 シナリオ2：ap-southeast-2 の Production VPC
📍 ap-southeast-2 🏷️ Environment=Production
📋 ルール100チェック：Production ✅ AND us-east-1 ❌
➡️ ルール200チェック：任意タグ ✅
✅ 自動承認
🟢 シナリオ3：us-east-1 の Development VPC
📍 us-east-1 🏷️ Environment=Development
📋 ルール100チェック：Production ❌ AND us-east-1 ✅
➡️ ルール200チェック：任意タグ ✅
✅ 自動承認
🟢 シナリオ4：SharedServices VPC（任意リージョン）
📍 任意のリージョン 🏷️ Environment=SharedServices
📋 ルール100チェック：Production ❌
➡️ ルール200チェック：任意タグ ✅
✅ 自動承認

💻 実装例：Core Network Policy JSON

JSON attachment-policies セクション 
{
  "attachment-policies": [
    {
      // ルール100: us-east-1のProductionのみ承認必要
      "rule-number": 100,
      "action": {
        "require-acceptance": true,
        "association-method": "tag"
      },
      "condition-logic": "and",
      "conditions": [
        {
          "type": "tag-value",
          "key": "Environment",
          "value": "Production"
        },
        {
          "type": "region",
          "value": "us-east-1"
        }
      ]
    },
    {
      // ルール200: その他すべては自動承認
      "rule-number": 200,
      "action": {
        "require-acceptance": false,
        "association-method": "tag"
      },
      "conditions": [
        {
          "type": "tag-exists",
          "key": "Environment"
        }
      ]
    }
  ]
}

💡 ベストプラクティス

🔢
ルール番号の間隔を空ける
100, 200のように間隔を空けることで、後から中間ルールを追加しやすくなります（例：150を後で追加）。
🎯
特定条件を先に配置
より具体的な条件（例外処理）を小さい番号で先にチェック。汎用ルールは大きい番号で後に配置。
🏷️
一貫したタグ戦略
Environment タグの値を標準化（Production, Development, SharedServices）して管理の一貫性を保つ。
📝
ドキュメント化
各ルールの目的と条件を文書化。なぜその承認ポリシーが必要かを記録しておく。

❓ よくある質問（FAQ）

🤔 Q: なぜルール番号100と200なのですか？
A: Cloud WANは番号が小さいルールから順に評価します。100と200のように間隔を空けることで、将来新しいルール（例：150）を追加する余地を残せます。また、「特定条件 → 汎用条件」の順序で処理することで、例外処理を確実に行えます。
🤔 Q: 「承認を要求」とは具体的に何が起こりますか？
A: VPCアタッチメント要求が「Pending Acceptance」状態になり、ネットワーク管理者が手動で承認操作を行うまで接続が完了しません。これにより、本番環境への予期しない接続を防ぎ、セキュリティレビューのワークフローを組み込めます。
🤔 Q: 両方のルールにマッチした場合はどうなりますか？
A: 最初にマッチしたルールのみが適用されます。ルール100でマッチすれば、ルール200は評価されません。これが「優先度の高いルール（小さい番号）を先に定義する」理由です。
🤔 Q: OR条件ではなくAND条件を使う理由は？
A: 要件は「us-east-1 の Production のみ」承認を必要としています。OR条件だと「us-east-1 または Production」となり、us-east-1のDevelopmentや、ap-southeast-2のProductionも誤って承認対象になってしまいます。両方の条件を満たす場合のみマッチさせるためにANDが必要です。

📌 まとめ：試験のポイント

✓
ルール番号は優先順位：小さい番号が先に評価される。特定の例外条件は小さい番号、汎用条件は大きい番号に設定
✓
AND条件で絞り込み：複数条件のすべてを満たす場合のみマッチ。「かつ」の関係を正確に表現
✓
OR条件は範囲が広がる：どちらか一方でもマッチするため、意図しないリソースが対象になりやすい
✓
タグベースの自動セグメント割り当て：VPCにEnvironmentタグを付けることで、適切なセグメントに自動マッピング可能
✓
承認ワークフロー：本番環境への接続にガードレールを設け、セキュリティとガバナンスを強化

Created by SSuzuki1063

AWS SAP Learning Resources