LoginSignup
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@mob_engineer(Masaki Okuda モブエンジニア)

【机上検討】Cloud WANコアネットワークのポリシー戦略を整理してみる

Last updated at Posted at 2025-09-15

深夜テンションでCloud WANに関するコアなネタを執筆してみました。

記事を読んでいただきありがとうございます。
モブエンジニア（@mob-engineer)です。

Cloud WANというサービスの肝として[コアネットワークポリシー]が存在しますが、
ネットワーク初学者が設定するのは大変なイメージがあります。
本記事では、Cloud WANコアネットワークのポリシー構成～設定例～戦略までザクっと整理してアウトプットしたいと思います。

対象読者

次のような課題を抱えている読者向けに本記事を執筆しております。

  1. Cloud WANを実務で利用しているがいまいち理解が浅い方
  2. コアネットワークポリシーの戦略を考えていきたい方

コアネットワークポリシーの構成

コアネットワークポリシーの構成についてはAWS公式ドキュメントで分かりやすくまとめられています。

公式ドキュメント

コアネットワークポリシーの構成として以下の通りです。

  • コアネットワーク構成（IPアドレス、AS番号など）
  • セグメント（フィルタリング設定など）
  • ネットワーク機能グループ（ファイアウォールなどを設定する場合利用）
  • セグメント機能（セグメントごとにどのような処理を行うか指定）
  • アタッチメントポリシー（ネットワークリソースをアタッチメントするときのルール）

とは言え上記ルールを正しく理解して設定するのは大変な印象を持っています。
（特にセグメント機能が鬼門という印象を持っています）

コアネットワークポリシーのサンプル

AWS公式からいくつかサンプルが公開されています。

1セグメント＋1リージョン

AWSドキュメント

{
	"version": "2021.12",
	"core-network-configuration": {
		"asn-ranges": [
			"64512-65534"
		],
		"edge-locations": [
			{
				"location": "us-east-1"
			}
		]
	},
	"segments": [
		{
			"name": "mynetwork",
			"require-attachment-acceptance": false
		}
	],
	"attachment-policies": [
		{
			"rule-number": 100,
			"condition-logic": "and",
			"conditions": [
				{
					"type": "any"
				}
			],
			"action": {
				"association-method": "constant",
				"segment": "mynetwork"
			}
		}
	]
}

非常にシンプルなコアネットワークポリシーなので読みやすいかと思います。
初めてCloud WANを触る方は上記ポリシーから理解することが手っ取り早いと思います。

2つのセグメント+複数リージョン

公式ドキュメント

{
    "version": "2021.12",
    "core-network-configuration": {
        "asn-ranges": [
            "64512-65534"
        ],
        "edge-locations": [
            {
                "location": "us-east-1"
            },
            {
                "location": "us-east-2"
            },
            {
                "location": "eu-west-1"
            }
        ]
    },
    "segments": [
        {
            "name": "secured"
        },
        {
            "name": "nonSecured"
        }
    ],
    "attachment-policies": [
        {
            "rule-number": 100,
            "conditions": [
                {
                    "type": "tag-value",
                    "key": "Network",
                    "value": "Secured",
                    "operator": "equals"
                }
            ],
            "action": {
                "association-method": "constant",
                "segment": "secured"
            }
        },
        {
            "rule-number": 200,
            "conditions": [
                {
                    "type": "tag-value",
                    "key": "Network",
                    "value": "Non-Secured",
                    "operator": "equals"
                }
            ],
            "action": {
                "association-method": "constant",
                "segment": "non-secured"
            }
        }
    ]
}

先ほどより分かりづらいですが、イメージとして「東京拠点・大阪拠点でネットワークを完全分離する場合」を想定するとイメージしやすいかと思います。
（Secured＝東京拠点、Non-Secured=大阪拠点）

特定のセグメント設定を入れる場合

公式ドキュメント

{
    "version": "2021.12",
    "core-network-configuration": {
        "asn-ranges": [
            "64512-65534"
        ],
        "edge-locations": [
            {
                "location": "us-east-1"
            },
            {
                "location": "eu-west-1"
            }
        ]
    },
    "segments": [
        {
            "name": "development",
            "isolate-attachments": true,
            "require-attachment-acceptance": false
        },
        {
            "name": "hybrid"
        }
    ],
    "segment-actions": [
        {
            "action": "share",
            "mode": "attachment-route",
            "segment": "development",
            "share-with": [
                "hybrid"
            ]
        },
        {
            "action": "create-route",
            "destination-cidr-blocks": [
                "0.0.0.0/0"
            ],
            "segment": "development",
            "destinations": [
                "attachment-12355678901234567",
                "attachment-23456789012345678"
            ]
        }
    ],
    "attachment-policies": [
        {
            "rule-number": 10,
            "conditions": [
                {
                    "type": "attachment-type",
                    "operator": "equals",
                    "value": "vpc"
                }
            ],
            "action": {
                "association-method": "constant",
                "segment": "development"
            }
        },
        {
            "rule-number": 20,
            "conditions": [
                {
                    "type": "attachment-type",
                    "operator": "equals",
                    "value": "vpn"
                }
            ],
            "action": {
                "association-method": "constant",
                "segment": "hybrid"
            }
        }
    ]
}

先ほどの設定とは少し毛色が変わりますが、
「開発用に指定されているネットワークでも接続できないように制限」する場合利用するイメージです。（複数プロダクトが同じ環境で開発している場合、入れる設定というニュアンスですかね）

開発プロセスを考慮したネットワーク設定

公式ドキュメント

{
	"version": "2021.12",
	"core-network-configuration": {
		"asn-ranges": [
			"64512-65534"
		],
		"edge-locations": [
			{
				"location": "us-east-1"
			},
			{
				"location": "us-west-2"
			}
		]
	},
	"segments": [
		{
			"name": "development",
			"isolate-attachments": true,
			"require-attachment-acceptance": false
		},
		{
			"name": "testing",
			"isolate-attachments": true,
			"require-attachment-acceptance": false
		},
		{
			"name": "production",
			"isolate-attachments": true,
			"require-attachment-acceptance": true
		},
		{
			"name": "sharedServices"
		}
	],
	"segment-actions": [
		{
			"action": "share",
			"mode": "attachment-route",
			"segment": "sharedservices",
			"share-with": "*"
		}
	],
	"attachment-policies": [
		{
			"rule-number": 1000,
			"conditions": [
				{
					"type": "tag-exists",
					"key": "Stage"
				}
			],
			"action": {
				"association-method": "tag",
				"tag-value-of-key": "Stage"
			}
		},
		{
			"rule-number": 1500,
			"conditions": [
				{
					"type": "resource-id",
					"operator": "equals",
					"value": "vpc-1234567890123456"
				}
			],
			"action": {
				"association-method": "constant",
				"segment": "sharedservices"
			}
		},
		{
			"rule-number": 1600,
			"conditions": [
				{
					"type": "resource-id",
					"operator": "equals",
					"value": "vpn-1234567890123456"
				}
			],
			"action": {
				"association-method": "constant",
				"segment": "sharedservices"
			}
		}
	]
}

Cloud WANを利用する中で一番利用するケースかと思いますが、Tag名で開発環境・ステージング環境・本番環境に分ける場合利用します。（開発環境は比較的安価なリージョンのみを指定というトリッキーなことも実現できます）

VPCを利用しない環境の場合

公式ドキュメント

{
    "version": "2021.12",
    "core-network-configuration": {
        "asn-ranges": [
            "64512-65534"
        ],
        "inside-cidr-blocks": [
            "100.65.0.0/16"
        ],
        "edge-locations": [
            {
                "location": "eu-central-1"
            },
            {
                "location": "us-west-2"
            },
            {
                "location": "us-east-1"
            },
            {
                "location": "eu-west-1"
            }
        ]
    },
    "segments": [
        {
            "name": "sales"
        },
        {
            "name": "testing"
        },
        {
            "name": "iot",
            "isolate-attachments": true
        },
        {
            "name": "internet"
        },
        {
            "name": "engineering"
        }
    ],
    "segment-actions": [
        {
            "action": "share",
            "mode": "attachment-route",
            "segment": "internet",
            "share-with": [
                "sales"
            ]
        },
        {
            "action": "share",
            "mode": "attachment-route",
            "segment": "iot",
            "share-with": [
                "engineering"
            ]
        },
        {
            "action": "create-route",
            "destination-cidr-blocks": [
                "0.0.0.0/0"
            ],
            "segment": "sales",
            "destinations": [
                "attachment-12355678901234567",
                "attachment-23456789012345678",
                "attachment-35567890123456790",
                "attachment-4567890123456789a"
            ]
        }
    ],
    "attachment-policies": [
        {
            "rule-number": 1000,
            "conditions": [
                {
                    "type": "tag-exists",
                    "key": "Assign-to"
                }
            ],
            "action": {
                "association-method": "tag",
                "tag-value-of-key": "Assign-to"
            }
        }
    ]
}

各リージョンにある部門間は接続できるように設定する場合利用するイメージですね。
そのうえで、このレベルまで複雑になってきた場合、専門組織を置いて管理していく必要があると考えられます。（複雑なことは行えるがその分管理が）

ネットワーク間にファイアウォールを置く

公式ドキュメント

{
	"version": "2021.12",
	"core-network-configuration": {
		"asn-ranges": [
			"64512-65534"
		],
		"edge-locations": [
			{
				"location": "us-east-1"
			},
			{
				"location": "us-west-2"
			}
		]
	},
	"segments": [
		{
			"name": "internalApps"
		},
		{
			"name": "firewall"
		},
		{
			"name": "onPremises"
		}
	],
	"segment-actions": [
		{
			"action": "create-route",
			"destination-cidr-blocks": [
				"0.0.0.0/0"
			],
			"segment": "internalApps",
			"destinations": [
				"attachment-deadbeef901234567",
				"attachment-eeeeee00000000000"
			],
			"description": "Send all internet headed on-premises through the firewall"
		},
		{
			"action": "create-route",
			"destination-cidr-blocks": [
				"0.0.0.0/0"
			],
			"segment": "onPremises",
			"destinations": [
				"attachment-deadbeef901234567",
				"attachment-eeeeee00000000000"
			],
			"description": "Send all traffic received from the VPN through the firewall"
		},
		{
			"action": "share",
			"mode": "attachment-route",
			"segment": "firewall",
			"share-with": [
				"internalAapps",
				"onPremises"
			]
		}
	],
	"attachment-policies": [
		{
			"rule-number": 500,
			"description": "We’ll do our specific policies before we do attachment types.",
			"conditions": [
				{
					"type": "tag-value",
					"key": "core-network",
					"operator": "equals",
					"value": "firewall"
				}
			],
			"action": {
				"association-method": "constant",
				"segment": "firewall"
			}
		},
		{
			"rule-number": 1000,
			"description": "Let’s assume all VPCs are internal apps",
			"conditions": [
				{
					"type": "attachment-type",
					"operator": "equals",
					"value": "vpc"
				}
			],
			"action": {
				"association-method": "constant",
				"segment": "internalApps"
			}
		},
		{
			"rule-number": 1500,
			"description": "Let’s also assume all VPNs are from on-premises",
			"conditions": [
				{
					"type": "attachment-type",
					"operator": "equals",
					"value": "site-to-site-vpn"
				}
			],
			"action": {
				"association-method": "constant",
				"segment": "onPremises"
			}
		}
	]
}

記述はめんどくさいですが、ざっくり言えば「ネットワーク間にファイアウォールを設定する」場合利用する設定となります。そのうえで、Transit GatewayとFirewall統合のアップデートもありましたので、あえてCloud WANでファイアウォールを設定するケースが考えづらいというところもあります。

ポリシー戦略あれこれ

複雑なネットワークになればなるほど設定が複雑化します。
そのうえで、留意した方がいいポイントとしていくつかあると考えています。

  1. ポリシーの説明文はシンプルかつ設定内容を表現したものにする
    1. 当たり前かもしれませんが、説明文がシンプルであればどのような意味を持つポリシーか初見でも理解できます
  2. ポリシー管理ルールを明文化しておく
    1. （GitHubと連携する機能があれば楽なのですが）ポリシー管理ルールを決めておくことで不用意な変更が起きにくくなります
  3. セグメント名は意味のある内容にする
    1. リーダブルコードの命名規則を参考に考えてみてもいいと思います
  4. 本番環境と同じ環境を用意しておく
    1. コアネットワークポリシーを誤って変更した場合、何らかの通信影響が発生します
    2. コストとの相談になりますが、可能であれば本番環境と同じ環境を用意したうえで検証を行うことを推奨します

まとめ

個人的にセグメント名については設計段階で戦略を立てておいた方が安全だと思います。そのうえで、ある程度SD-WANサービスを触っている方にとってはCloud WANは触りやすいサービスだと考えています。

PS

ガバメントクラウド利用ガイドを見ても、Cloud WANについて言及は為されていないので利用することはほぼないと思います。（使いこなせば便利ですが、国内事例も少ない＋難易度が高いので。。。）

ネットワーク接続方法(AWS編)

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?