Did you hear about the Buddhist vacuum cleaner? No attachments.

My wife is Buddhist and approves of this joke

CloudWAN, like Transit Gateways, works with the concept of attachments. You attach things to CloudWAN. As of writing those can be:

• VPC
• Site to Site VPNs
• Transit Gateway route tables

note: you need to setup peering as well for this to work

• Connect attachments. My favorite kind

Obviously, as in the name, attachments attach to CloudWAN, facilitating traffic flow. Routing information is also passed bidirectional. Now here is where it becomes interesting. An attachment is to a segment. A segment knows the CIDRs of everything attached. Assuming isolation isn't enabled, all attachments can see each other (assuming no other blocks). Segments can be shared with each other. This means each segment will both learn the CIDRs from the shared segment and propogate these to each segment it also has sharing enabled with.

Sharing is bidirectional by default

So if you are going to use any kind of shared segment, be sure to add some deny filters.

Connect attachments

These ones are fun, as they allow you to attach third party SDN devices to CloudWAN. This enables all kinds of things. Imagine cross cloud networking. Under the hood, you setup a GRE tunnel between the regional CNE and your device.

In CloudWAN terms, you create a Connect Attachment and then define the Connect Peers

We'll go in depth on this later.

Please get back on track

So, you have your CloudWAN policy done, it's deployed and as you saw, there is some attachment policy defined

          attachment-policies:
            - rule-number: 100
              conditions:
                - type: tag-exists
                  key: prod
              action:
                association-method: constant
                segment: prod
            - rule-number: 200
              conditions:
                - type: tag-exists
                  key: nonprod
              action:
                association-method: constant
                segment: nonprod
            - rule-number: 300
             conditions:
                - type: tag-exists
                  key: sharedservices
              action:
                association-method: constant
                segment: sharedservices

Understanding the above should be pretty straight forward. When creating your VPCs, you'll setup the VPC attachment to CloudWAN and give that attachment a tag. The tag is the hook to the segment.

It really is that easy. Of course the secret sauce is putting all this in IaC, which for now I won't dive into, suffice to say you need

• IPAM setup
• IPAM allocation for your VPC (as discussed before)
• Split the CIDR into subnets

So many attachments!

Now a warning. You pay per attachment, per hour. Connection costs and of course data transfer. Think if you really need everything on CloudWAN. Maybe (and this is a future topic) think about leveraging something like VPC lattice to cut down on those costs.

What's next?

We're still soldiering on. We've got the following still upcoming:

• Egress/Inspection
• External connectivity