Being brought up in New Zealand, I always felt the rest of the world was so far away. It is maybe for that reason I find the idea of linking regions and geographies so intriguing. It seems almost like magic to have people and workloads talk to each other with just a few clicks and commands.
Queue entry center stage, AWS Cloud WAN. At DXC, as an AWS Partner, we have been involved with assessing and previewing and feeding into AWS Cloud WAN for the last 6 months and now the new service was announced and released to public preview at AWS re:Invent 2021.
Before I get into the nitty gritty of what it does, what is the potential value?
High-level summary and business value
AWS Cloud WAN is basically an AWS Managed WAN that routes traffic between regions and geographies. Doesn’t this already exist with Transit Gateways? Well, yes, but AWS Cloud WAN provides automation and much reduced complexity. You have been able to build a software-defined WAN with multiple Transit Gateways but the complexity is potentially a barrier to broader acceptance and implementation by customers. AWS Cloud WAN offers some very nice features and also commoditizes things somewhat.
This brings us to the business value. Why should customers start using AWS Cloud WAN – or consider it? I think a high-level value proposition is threefold:
1. Agility and speed. In contrast to the traditional bricks and mortar of MPLS or build multiple Transit Gateways, Direct Connects or VPNs across VPCs, regions multiple AWS accounts. Cloud WAN can be up and running very quickly as customers look to add regions and connect regions and geographies. Workloads can be connecting to each other almost instantaneously. This has always been a value of the public cloud but enterprise networking hasn’t kept up.
2. Reduced cost by leveraging DevOps, and programmability (technically – a single intent-based routing policy as code document). If that sounds like a mouthful, I’ll go into more detail later on. AWS Cloud WAN can be brought into the fold with a consistent Infrastructure as Code that integrates with current DevOps processes in customer environments. If no processes exist, then deploying an MVP to deploy and manage the WAN isn’t too onerous whatever flavor of tooling is chosen. Once it is deployed, AWS Cloud WAN can exist and be extended as part of these processes. There’s no need for the complications of MPLS. And the need to manage multitude of Transit Gateways.
3. Unlock new capabilities. Depending on the customer requirements, AWS Cloud WAN features can help realize additional business value. For example: the ability to have a Dev VPC in each region that can connect to other Dev VPCs in other regions may reduce management overhead of these environments. The AWS backbone is used for speedy connectivity and the abstraction layer that connects these regional Dev environments seamlessly requires minimal setup.
These are the main areas I see AWS Cloud WAN providing business value at a high level. There will be others, but this is dependent on the customer. An AWS blog outlines the main use cases for AWS Cloud WAN.
In terms of business value for DXC the primary proposition is that of management of the WAN, SDN brings opportunities to manage and do things in a cloud-native way with DevOps processes and be agile and innovative. At DXC we help customers dip their toe into, and move, from the traditional MPLS – if it makes business sense for them.
The detail
Before we go into the specifications, a picture is worth a thousand words so this diagram from AWS provides a bit of framing.
This is the way an architecture could look currently with multiple Transit Gateways:
And this is a possible AWS Cloud WAN Architecture, abstracted:
Some major points:
- You can see there are different segments that transcend regions. A Dev environment can seamlessly talk to a Dev environment in another region using the AWS backbone. I guess you could think of it in terms of functionality as virtual routing and forwarding (VNF).
- Routing and forwarding are controlled using intent-based policies.
- Existing Transit Gateways can continue to be used and brought into the fold.
- Support for third-party vendors to snap into the service easily.
So, what are the differentiators from what has been before? These are the main ones:
Simpler to Configure
- Auto discovery
- Simplified routing configuration to VNFs
- Templatized routing configuration
AWS Managed Routing and Services
- Traffic remains on AWS backbone as long as possible
Global environmental zones
- Cloud-native equivalent to an MPLS VRF.
- Global metrics visibility within each zone for east/west traffic
Let’s drill into the programmability a bit more. There are three related items:
- There is a single intent-based routing policy document describing the global AWS Cloud WAN infrastructure.
- Deployments are programmable and API-driven.
- AWS uses a two-step update process to allow an enterprise to install a manual verification step, if desired.
What we are looking at are reduced configuration mistakes due to process, and an organization’s AWS Cloud WAN infrastructure can be configured via a single JSON document that describes the totality of configuration. With standard DevOps processes being used, everything is API driven and programmable. AWS also provide the option of an additional verification step within the console.
All of this avoids the delays inherent in traditional MPLS VPN WANs, as well as the opportunities to introduce errors in creating, configuring and maintaining multiple AWS Transit Gateways and their peering relationships across multiple cloud regions and geographies.
What would a real-world example be? I have been chatting with a client recently and there are two main drivers for them to move forward with AWS Cloud WAN.
First, they love the idea of using native cloud technologies to achieve their goals. Second, the idea of keeping east/west traffic in the cloud without transiting the WAN or going to their carrier neutral facility is attractive. The ability to use DevOps networking is also a driver.
AWS Cloud WAN was released as public preview at AWS re:invent with DXC as a launch partner. We are very excited to be part of this brave new world and are gearing up accordingly. Any inquiries, please reach out and we can discuss any potential business value you might get from implementing AWS Cloud WAN.
About the author
Scott Brodie is chief architect for hybrid and multicloud services at DXC Technology.
Contributor
Kevin Kuehl, network security architect, DXC Technology