AWS re.Invent day 1: Cloud WAN and a small tip…

Here we go, the 1st day of this 2022 edition of the AWS re:Invent is almost over and it was already a pretty busy day with 2 interesting hands-on workshop. Here some insights about Cloud WAN and to finish a small tips about a “funny” trap…

Creating a large network: Cloud WAN

When working over multiple VPCs as well as eventually Regions, connecting everything together (in a proper manner 😉) becomes a key. Nowadays the usual way is to go through Transit Gateways which is a service per region and requires to manage:

– Attachments
– Routing tables
– Inter-Region peering

This can of course be automated using for instance Terraform but can make it hard to keep a global view on the network infrastructure. In addition handling all the routing tables can become a bit tricky, especially when it goes to debugging and fixing routing issues.

The new alternative proposed by AWS is called Cloud WAN

So what is Cloud WAN?

It is a global service (not region related) which allows to create a cross-region and cross-VPC network.
Cloud WAN is based on the AWS core network (backbone) which as the Transit Gateway works on a principle of attachments to allow subnets to communicate together. It supports several attachment type such as of course VPCs but also TGWs or VPNs.

However, unlike the Transit Gateway it is based on a Segments principle which manages the whole routing behind the scene for you.

A segment groups together pieces of network that shall communicate together by deploying Core Network Edges (CNE) in the corresponding region. The nice thing there is that once the segments have been declared, the attachment can be automatically linked to the right segments using metadata such as tags.

In addition all this is defined in a global policy called the CNP which stands for Core Network Policy, a simple JSON file.

The whole is managed through the well known Network Manager.

Here an exemple of the definition of some segments as part of a CNP

"segments": [
{
"name": "prod",
"edge-locations": [
"eu-north-1",
"us-west-2"
],
"require-attachment-acceptance": false,
"isolate-attachments": true
},
…
…
"attachment-policies": [
{
"rule-number": 100,
"conditions": [
{
"type": "tag-exists",
"key": "prod"
}
],
"action": {
"association-method": "constant",
"segment": "prod"
}
},

This will in the Network Manager then see something like showing the attachment rule applied:

Then on the Attachment you set a tag Prod = true and that’s it.

To route traffic through this segment the last thing to do is in the routing table of the VPC itself, to add a route to send the traffic through the core network and you are all set.

So why not always using it?

The price indeed…
All information can be found there: https://aws.amazon.com/cloud-wan/pricing/

With the provided example in the pricing page, we can see that Cloud WAN for 2 VPCs in 1 Region (so using 1 CNE) will costs approx. $460.- per month.
It means you should think about if the price is worth…
The answer will of course depends on the size and complexity of your network…and of course the efforts you are ready to put in yourself (i.e. “terraforming” the whole TGW; attachments and routing tables).

Here a small summary of the pros and cons I could identify in these first 2 hours testing

Pros:
– Ease of creation and configuration (including CNP versioning)
– Ease of monitoring

Cons:
– Price vs traditional TGW based solution

By the way on 17.01, I will attend an Aviatrix flight-school session which will obviously also be an interesting comparison.

…to conclude a small tip

In the second workshop I attended to day, one of the exercise what to migrate a MySQL database from on-prem to RDS using DMS (Database Migration Service).

It is a pretty nice solution which is quite easy to implement:

1. Create you RDS target environment
2. Configure a subnet group in DMS
3. Create a Replication instance (which creates a specific EC2 instance in the background)
4. Configure your source endpoint (the on-prem DB) and a target one (your RDS database)
5. Create a replication tasks

Sounds easy 😜 … here comes the trick…

Whatever I did the Replication instance was able to connect my source endpoint but not my target one??

Of course did the basic check like ensure the password is the right one and checking that the private IP of my Replication instance was declare in the security group for my RDS database in order to reach it

Here how the security instance is looking like:

So I ensure that the IP 10.0.0.31 was allowed to access the port 3306 on my RDS database in the corresponding security groups…which was the case.

After searching a while with AWS guys on-site, who were really helpful, one of them finally told me that IP shows above is not “always” the one which is really used… 🤔 🤨

What is then the workaround?? Simply allowing the access to the RDS port to the security group my Replication instance is part of:

We usually see the Security Group like an IPtable definition on Linux (for those you did firewalling before firewalld :-D) but we often forget that it is also a logical object which groups all its members and allows to reference them as one.