Retrospect
In my old post, The Evolution of Cloud Networking on AWS I elaborated on what and why Transit Gateway could revamp your network transport. Although Transit Gateway has been generally available since November 2018 (ready to 4th anniversary), it is still the most powerful feature in the Cloud Networking space across the board.
If you think that Transit Gateway will be the last fascinating networking offering then you are definitely wrong!
New Launch
In July 2022, AWS formally announced another cool feature called Cloud WAN. As the matter of fact, I was a bit confused about its name due to WAN typically means external/public networks; however, what Cloud WAN is responsible for is not really about WAN, instead, it is more about globally consolidating all of your network ingredients, e.g. VPC, Transit Gateway, Site-to-Site VPN, and SD-WAN across regions into a single and unified management console.
Other than the name, I was also a bit confused about the key differences when compared with Transit Gateway in terms of their functionalities, especially after I read the Preview post. As a result, the following questions came up in my brain;
- Is Cloud WAN able to completely take over all the functionalities that Transit Gateway supports?
- Does Cloud WAN aim to replace Transit Gateway entirely?
In terms of the standpoint of the key offering, I do not think that AWS is willing to see there are two products without any differentiators. The best way to demystify any uncertainty is always to deploy, verify, and observe instead of reading documents without any implementations.
Comparison
From my viewpoint, it would be more straightforward to dig a new feature by comparisons; hence I use the Transit Gateway architecture to compare with the Cloud WAN one. Its architecture involves the following scenarios;
- Each Transit Gateway has four Transit Gateway Route Tables which aka VRFs 😁.
- Cross-region communications are via Transit Gateway Peerings.
When transforming to the Cloud WAN architecture, it looks quite similar to the Transit Gateway one; however, there are a few of differences between them.
First of all, the role and capability of Core Network Edge or CNE are typically identical to Transit Gateway; the only difference is that all the CNEs within the Cloud WAN core network automatically link with each other by nature. When turning to Transit Gateway, you need to manually create the Transit Gateway Peering for cross-region communications instead.
As following screenshots, all kinds of attachments, e.g. VPC and Site-to-Site VPN are associated with corresponding Core Network Edges as well as the Transit Gateway model; however, you might be interested in what is the Transit Gateway Route Table attachment?
Typically, the Transit Gateway Route Table attachment is equivalent to the Transit Gateway Peering attachment; create the peering connection and then associate it with the segment. In addition, one thing needs to keep in mind is that Direct Connect does not support to be directly associated with Core Network Edge yet; therefore, you need to leverage Transit VIF at this stage.
Secondly, each Cloud WAN segment exactly functions in the same way as Transit Gateway Route Table does; a slight difference in between is that you could leverage specified tag set(s) to move any Cloud WAN attachment to another segment. In my case, I use the key cloud-wan-segment as a condition and the value Development; as a result, that means once this criterion matches, this attachment will be moved to the Development segment. When turning to Transit Gateway Route Table, you need to re-associate the specified attachment instead. From my viewpoint, this feature is extremely handy, especially when you do not need to involve any change of the configuration.
Thirdly, a whole Cloud WAN core network could be completely managed via a JSON file by nature and every change is well-recorded (versioning), too. When turning to Transit Gateway, it does not have this feature in place, you need to manage it by your automated framework instead. In terms of change management, this feature is a significant spotlight of Cloud WAN from my perspective. Because of the versioning, you are able to roll back any change more efficiently; even before you commit any changes, you are able to see the comparison between the current profile and the new profile. This convenience lets me recall Cisco IOS-XR and Junos due to that is what they behave 😁.
{
"version": "2021.12",
"core-network-configuration": {
"vpn-ecmp-support": true,
"asn-ranges": [
"4200000001-4200000100"
],
"edge-locations": [
{
"location": "ap-southeast-1"
},
{
"location": "ap-northeast-1"
}
]
},
"segments": [
{
"name": "Shared",
"require-attachment-acceptance": true,
"allow-filter": [
"Production",
"Development",
"Staging"
]
},
{
"name": "Production",
"require-attachment-acceptance": true,
"allow-filter": [
"Shared"
]
},
{
"name": "Development",
"require-attachment-acceptance": true,
"allow-filter": [
"Shared"
]
},
{
"name": "Staging",
"require-attachment-acceptance": true,
"allow-filter": [
"Shared"
]
}
],
"segment-actions": [
{
"action": "create-route",
"segment": "Shared",
"destination-cidr-blocks": [
"0.0.0.0/0"
],
"destinations": [
"attachment-0123456789abcdefg"
]
},
{
"action": "create-route",
"segment": "Production",
"destination-cidr-blocks": [
"0.0.0.0/0"
],
"destinations": [
"attachment-0123456789abcdefg"
]
}
],
"attachment-policies": [
{
"rule-number": 100,
"condition-logic": "and",
"conditions": [
{
"type": "tag-value",
"operator": "equals",
"key": "cloud-wan-segment",
"value": "Production"
}
],
"action": {
"association-method": "tag",
"tag-value-of-key": "cloud-wan-segment"
}
},
{
"rule-number": 101,
"condition-logic": "and",
"conditions": [
{
"type": "tag-value",
"operator": "equals",
"key": "cloud-wan-segment",
"value": "Development"
}
],
"action": {
"association-method": "tag",
"tag-value-of-key": "cloud-wan-segment"
}
},
{
"rule-number": 102,
"condition-logic": "and",
"conditions": [
{
"type": "tag-value",
"operator": "equals",
"key": "cloud-wan-segment",
"value": "Staging"
}
],
"action": {
"association-method": "tag",
"tag-value-of-key": "cloud-wan-segment"
}
},
{
"rule-number": 103,
"condition-logic": "and",
"conditions": [
{
"type": "tag-value",
"operator": "equals",
"key": "cloud-wan-segment",
"value": "Shared"
}
],
"action": {
"association-method": "tag",
"tag-value-of-key": "cloud-wan-segment"
}
}
]
}
Lastly, other than leveraging the Transit Gateway Route Tables, you could also separate various business intentions via more than one Transit Gateway. When turning to the Cloud WAN architecture, each region could only have a Core Network Edge within a Cloud WAN core network. As you see in the above architecture diagrams, all the components reside in the Cloud WAN core network; therefore, the separation is taken place on the core network (well...please ignore Blackhole 😅).
Anything Else?
Other than the above-mentioned capabilities, there are additional three differences between Transit Gateway and Cloud WAN.
-
Simpler operations - for operators who are keen to address the following situations, Cloud WAN is what they seek for;
- They are not familiar with managing multi-hierarchies/segments of the network transport.
- They aim to streamline the whole Transit Gateway manipulation, e.g., segmentation across a variety of Transit Gateway Route Tables or cross-region routing exchange across a number of Transit Gateway Peerings.
- The Network-as-Code is a preferred method for routine operation.
- More Agility - when you want to filter any route entry, what you would perform on Transit Gateway is not to propagate the whole CIDR of the VPC to Transit Gateway Route Table, a more accurate static route instead; in other words, the control takes place on the route-entry level, the import/export cannot be on the segment (Transit Gateway Route Table) level. In terms of Cloud WAN, it supports both ways; that is other than the prefix filter, all the segments could be used as the objects for import/export.
- Higher CapEx - intrinsically, the charge model and pricing are quite close or even identical between Transit Gateway and Cloud WAN except for Core Network Edge. Transit Gateway itself is not charged, but each Core Network Edge charges $0.5/hour. Imagine that you have 4 Core Network Edges across regions in your environment, which means you need to extra pay $1,440/month without any attachments and data processes when compared with Transit Gateway.
For those reasons, if you are familiar with the whole Transit Gateway manipulation and all the modifications involved in your automated framework already then Cloud WAN may not able to catch your eyes because of its cost model.
Conclusion
For mitigating any unwanted requests toward your service origins as close to the sources (clients) as possible, we typically defend them on the edge (CDN) side. When looking at cloud security on the infrastructure level, both Transit Gateway and Cloud WAN adopt the same strategy as well; the isolation happens on the segments layer instead of the network access layer, e.g. Network Firewall/ACL and Security Group.
Why Cloud WAN is more fascinating than Transit Gateway from my viewpoint because it not only hugely simplifies operations but also completes the absences of Transit Gateway. Further, it makes the cloud networking operation close to the traditional MPLS VPN model 😁.
But, I still have to admit that its overall pricing is not so tasty 😅.
Top comments (0)