AWS Cloud WAN
アタッチメントポリシー完全ガイド
設定・ルール評価・タグベースセグメントマッピングを図解で理解
最初に押さえる3つのポイント
ルールは番号順に評価
小さい番号から順に評価され、最初に一致したルールのみが適用される（ファーストマッチ方式）
AND / OR で条件を制御
AND条件はすべて一致が必要、OR条件はいずれか一致でOK。条件の組み合わせでアタッチメント配置を精密制御
タグで自動セグメント割当
VPCにタグを付けるだけで、アタッチメントポリシーが自動的に正しいセグメントへマッピングする
たとえ話：ホテル客室割り振りシステム
Cloud WAN のアタッチメントポリシーは、大型ホテルの「客室割り振りシステム」に似ています。宿泊客（VPC）が到着したとき、予約ルール（ポリシー）に基づいて、自動的に適切なフロア（セグメント）に割り振られます。
| 🏨 ホテルのたとえ | ☁️ Cloud WAN の実際 | |
|---|---|---|
| 🏢 | ホテル全体 | Cloud WAN コアネットワーク |
| 🏗️ | 各フロア（一般客フロア / VIPフロアなど） | セグメント（Dev / Prod / Sharedなど） |
| 🧑💼 | 宿泊客（名前・会員ステータスを持つ） | アタッチメント（VPC / VPN / DXなど） |
| 📋 | 客室割り振りルール一覧 | アタッチメントポリシー |
| 🔢 | ルールの優先順位番号 | rule-number（小さい番号が優先） |
| 🏷️ | 宿泊客の会員カード（ゴールド / プラチナ） | リソースタグ（Environment=Prod など） |
| ✅ | VIPフロアはフロントマネージャーの承認が必要 | require-attachment-acceptance（承認要求） |
| 🔒 | フロア間の移動制限 | セグメント分離（isolate-attachments） |
アタッチメントポリシーとは
Cloud WAN のアタッチメントポリシーは、新しいVPCやVPN接続がコアネットワークに接続される際に、「どのセグメントに配置するか」を自動的に決定するルールセットです。ホテルで宿泊客がチェックインした際に、予約条件に基づいて適切な部屋に案内する仕組みと同じです。
アタッチメントポリシーの全体像
ポリシーの構成要素
ルール番号、条件論理（AND/OR）、条件タイプ（タグ・リージョン・アカウントID等）、アクション（セグメント割当）で構成されます。
対象アタッチメント
VPC、Site-to-Site VPN、Direct Connect Gateway、Transit Gateway ルートテーブル、Connect アタッチメントが対象です。
セグメント割当方法
定数指定（constant）で直接セグメント名を指定するか、タグ値ベース（tag）でアタッチメントのタグ値からセグメント名を導出できます。
ルール評価順序の仕組み（ファーストマッチ方式）
アタッチメント要求
VPCやVPN接続がコアネットワークに接続を要求する
Rule 100 を評価
最小番号のルールから条件を評価する
一致判定
条件に一致すればそのルールのアクションを実行し終了
不一致なら次へ
一致しなければ次に大きい番号のルールを評価する
ルール評価フロー（ファーストマッチ方式）
AND / OR 条件論理の使い分け
AND すべての条件に一致
条件A かつ 条件B の両方が満たされなければルールは適用されない。より厳密な制御に使用する。
条件1: Region = us-east-1
条件2: Attachment-type = vpc
→ 両方一致した場合のみ Prod セグメントに割当
OR いずれかの条件に一致
条件A または 条件B のどちらかが満たされればルールが適用される。柔軟な割当に使用する。
条件1: tag Env=Production
条件2: tag Env=Staging
→ どちらかに一致すれば Prod セグメントに割当
AND / OR 条件ロジックの動作比較
タグベースのセグメントマッピング
タグベースのセグメント自動マッピング
タグキーの設計
「Segment」「Environment」などの共通キーを組織内で統一して使用します。複数チームが同じ命名規則に従うことで、一貫した自動マッピングが可能になります。
動的なセグメント移動
VPCのタグ値を変更するだけで、セグメントの所属を変更できます。ただし、require-attachment-acceptance が false の場合、タグ変更で自動移動する点に注意が必要です。
スケーラビリティ
タグベースのマッピングを使うと、数百のVPCを持つ大規模環境でも、個別にルールを書く必要がなくなります。タグの統一さえ守れば拡張は容易です。
承認ワークフロー
自動承認
require-attachment-acceptance: false の場合、条件に一致するアタッチメントは自動的にセグメントに割り当てられます。開発環境など素早いデプロイが求められる場合に使用します。
手動承認
require-attachment-acceptance: true の場合、管理者がAWS コンソールまたはAPIで承認するまでアタッチメントは保留（pending）状態になります。本番環境に推奨です。
セグメント継承
ポリシーで明示的に指定しない場合、セグメント作成時に設定された require-attachment-acceptance の値を継承します。一貫したセキュリティポリシーの適用に便利です。
require-attachment-acceptance が false のセグメントでは、アタッチメントのタグが変更されると自動的にセグメントが移動する場合があります。本番環境では true に設定しておくことを推奨します。
JSON ポリシー設定例
{
"attachment-policies": [
{
"rule-number": 100,
"condition-logic": "or",
"conditions": [
{
"type": "tag-value",
"operator": "equals",
"key": "Environment",
"value": "Production"
}
],
"action": {
"association-method": "constant",
"segment": "ProductionSegment",
"require-acceptance": true
}
}
]
}
{
"attachment-policies": [
{
"rule-number": 100,
"condition-logic": "or",
"conditions": [
{
"type": "tag-exists",
"key": "Segment"
}
],
"action": {
// タグの値をセグメント名として使用
"association-method": "tag",
"tag-value-of-key": "Segment"
}
}
]
}
// VPCにタグ Segment=Prod をつけると
// → 自動的に "Prod" セグメントに割り当て
// VPCにタグ Segment=Dev をつけると
// → 自動的に "Dev" セグメントに割り当て
{
"attachment-policies": [
{
"rule-number": 300,
"condition-logic": "and",
"conditions": [
{
"type": "region",
"operator": "equals",
"value": "us-east-2"
},
{
"type": "attachment-type",
"operator": "equals",
"value": "vpc"
}
],
"action": {
"association-method": "constant",
"segment": "ProductionSegment",
"require-acceptance": true
}
}
]
}
// AND条件: us-east-2 かつ VPCタイプの場合のみ
// ProductionSegment に割り当て（承認必要）
ベストプラクティス vs アンチパターン
✅ ベストプラクティス
- ルール番号は100刻みで設定し、後から挿入可能な余裕を持たせる
- 具体的なルール（複数条件AND）を小さい番号に、汎用ルールを大きい番号に配置
- 本番セグメントには
require-acceptance: trueを必ず設定 - タグベースのマッピングを活用してルール数を最小化
- タグ命名規則を組織全体で統一してから運用開始
- ポリシー変更前にドライラン（新規ポリシーバージョンのテスト）を実施
✗ アンチパターン
- ルール番号を1刻みで設定し、後からの挿入が困難になる
- 汎用的なルール（全マッチ）を最初に配置し、具体的なルールが評価されない
- 本番セグメントで承認を必須にせず、意図しないアタッチメントを許可してしまう
- VPCごとに個別ルールを作成し、ルール数が爆発的に増加
- タグ命名規則を統一せず、マッピング漏れが発生する
- ポリシー変更を本番に直接適用し、ネットワーク障害を引き起こす
トラブルシューティング
| 症状 | 原因 | 対処法 |
|---|---|---|
| アタッチメントが想定と異なるセグメントに割り当てられる | より優先度の高い（小さい番号の）ルールが先に一致している | ルール番号の順序を確認し、具体的なルールの番号を小さく設定する |
| アタッチメントがどのセグメントにも割り当てられない | タグが設定されていない、またはルールの条件に一致しない | VPCのタグを確認し、ポリシー条件との一致性を検証する |
| アタッチメントがPending状態のまま | require-acceptance: true が設定されており、承認待ちの状態 |
AWS コンソールまたは API で承認操作を実行する |
| タグを変更してもセグメントが変わらない | 承認が必要なセグメント、またはポリシーバージョンが未更新 | 新しいポリシーバージョンを作成・適用し、承認設定を確認する |
| AND条件のルールが一致しない | いずれかの条件が満たされていない | 各条件を個別に検証し、すべてが満たされるか確認する |
試験対策のポイント（ANS-C01 / SAP-C02）
ファーストマッチを理解
ルールは番号の小さい順に評価され、最初に一致したルールのみが適用される。Network ACLと同じ動作パターンであることを覚える。
AND / OR の使い分け
AND = すべての条件が必要（厳密制御）、OR = いずれか一致でOK（柔軟制御）。問題文で「リージョンとタイプの両方」と言われたらAND。
タグベース vs 定数指定
大規模環境では association-method: "tag" を使うことでルール数を削減できる。「数百のVPCを効率的に管理」ならタグベースを選択。
承認ワークフロー
本番環境のセグメントには承認を必須にすることがベストプラクティス。「セキュリティ要件が厳しい」シナリオでは require-acceptance: true。
よくある質問（FAQ）
はい。コアネットワークポリシーごとにルール数の上限があります。大規模環境ではタグベースの association-method: "tag" を活用して、ルール数を最小化することが推奨されます。最新の上限値はAWS公式ドキュメントの Cloud WAN クォータページで確認してください。
はい。タグベースのマッピングを使用している場合、VPCのタグ値を変更することでセグメントを移動できます。ただし、require-attachment-acceptance: true のセグメントでは再度承認が必要になります。定数指定の場合は、ポリシー自体の変更が必要です。
ファーストマッチ方式のため、最初に一致したルール（最小のルール番号）のみが適用されます。それ以降のルールは評価されません。このため、具体的な条件を持つルールには小さい番号を、汎用的なルールには大きい番号を割り当てることが重要です。
主に以下の演算子が使用できます：equals（完全一致）、not-equals（不一致）、begins-with（前方一致）、contains（部分一致）、any（任意の値に一致）。ただし、attachment-type では equals のみ使用可能です。
いいえ。ポリシーの変更は「新しいポリシーバージョン」として作成され、実行（適用）操作を行うまで反映されません。これにより、変更をレビューしてからデプロイするワークフローが可能です。本番環境では必ず変更内容を確認してから適用してください。
📋 チートシート
ルール評価
小さい番号から順に評価。最初の一致で終了（ファーストマッチ）。番号は100刻み推奨。
条件ロジック
AND = すべて一致が必要。OR = いずれか一致でOK。ネットワーク機能グループはAND必須。
セグメント割当方法
constant = セグメント名を直接指定。tag = タグ値でセグメント名を自動導出。大規模環境はtag推奨。
承認設定
本番は require-acceptance: true を推奨。false だとタグ変更で自動移動の可能性あり。
条件タイプ
tag-value, tag-exists, region, account-id, attachment-type, resource-id が使用可能。
ポリシーバージョン
変更は新バージョンとして作成→レビュー→実行のワークフロー。ロールバック可能。
用語集
| 用語 | 説明 |
|---|---|
| Attachment Policy | アタッチメントをどのセグメントに配置するかを決定するルールセット |
| Segment | ネットワーク分離の単位。セグメント内のリソースは相互に通信可能 |
| rule-number | ルールの評価優先度を決める番号。小さいほど優先 |
| condition-logic | 複数条件の結合方法。AND（すべて一致）またはOR（いずれか一致） |
| association-method | セグメント割当方法。constant（直接指定）またはtag（タグ値連動） |
| require-acceptance | 管理者の承認を必要とするかの設定。true で承認ワークフローが有効化 |
| Policy Version | ポリシーの変更管理単位。変更は新バージョンとして作成し適用する |