Deep Dive into AWS Cloud WAN Core Network Policy: Configuration, Examples, and Strategy
Thank you for reading this article.
I'm mob-engineer (@mob-engineer).
The core network policy is the heart of the Cloud WAN service, but configuring it can seem daunting for network beginners. In this article, I'll organize and summarize the policy structure, configuration examples, and strategies for Cloud WAN core networks.
Target Audience
This article is written for readers facing the following challenges:
- Those using Cloud WAN in practice but lacking deep understanding
- Those wanting to develop strategies for core network policies
Core Network Policy Structure
The core network policy structure is well documented in the official AWS documentation.
The core network policy consists of the following components:
- Core network configuration (IP addresses, AS numbers, etc.)
- Segments (filtering settings, etc.)
- Network function groups (used when configuring firewalls, etc.)
- Segment actions (specifying what processing to perform for each segment)
- Attachment policies (rules for attaching network resources)
That said, correctly understanding and configuring these rules can be challenging.
(Segment actions in particular seem to be a major hurdle)
Core Network Policy Samples
AWS provides several official samples.
1 Segment + 1 Region
{
"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"
}
}
]
}
This is a very simple core network policy that should be easy to understand.
For those touching Cloud WAN for the first time, starting with this policy is the quickest way to learn.
2 Segments + Multiple Regions
{
"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"
}
}
]
}
This is more complex than the previous example, but it becomes easier to understand if you imagine "completely separating networks for Tokyo and Osaka locations."
(Secured = Tokyo location, Non-Secured = Osaka location)
When Including Specific Segment Settings
{
"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"
}
}
]
}
This configuration is slightly different from the previous ones. It's used when you want to "restrict connections even within networks designated for development." (This is the kind of setting you'd use when multiple products are developing in the same environment)
Network Configuration Considering Development Process
{
"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"
}
}
]
}
This is probably the most common use case for Cloud WAN. It's used when separating development, staging, and production environments by tag name. (You can also do tricky things like specifying only relatively inexpensive regions for the development environment)
For Environments Not Using 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"
}
}
]
}
This is used when configuring connectivity between departments in each region. When complexity reaches this level, it's advisable to establish a dedicated organization to manage it. (Complex configurations are possible, but management becomes more challenging)
Placing a Firewall Between Networks
{
"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"
}
}
]
}
While the configuration is tedious, it's essentially used when "configuring a firewall between networks." However, with recent updates to Transit Gateway and Firewall integration, it's hard to imagine cases where you'd specifically configure a firewall with Cloud WAN.
Policy Strategy Considerations
The more complex the network becomes, the more complex the configuration gets. Here are some points to keep in mind:
- Keep policy descriptions simple and representative of the configuration content
- This may seem obvious, but if descriptions are simple, even first-time viewers can understand what the policy means
- Establish and document policy management rules
- (It would be easier if there were GitHub integration features) By establishing policy management rules, you can prevent inadvertent changes
- Use meaningful segment names
- Consider referencing naming conventions from "Readable Code"
- Prepare an environment identical to production
- If you mistakenly modify the core network policy, some communication impact will occur
- It's a matter of cost, but if possible, it's recommended to prepare an environment identical to production for testing
Summary
Personally, I think it's safer to establish a strategy for segment naming during the design phase. For those who have some experience with SD-WAN services, Cloud WAN should be an approachable service.
PS
Even looking at the Government Cloud Usage Guide, there's no mention of Cloud WAN, so it's unlikely to be used. (While it's convenient if mastered, there are few domestic cases and the difficulty level is high...)
Top comments (0)