Networking isn't scary.

I get it. You don't really know about networking. I mean, you know what a subnet is. Kinda.

192.168.0.0/24 is one, like at home, right?

It's archaic. It's just numbers. Plus, I hear AWS says just use /16s in your VPCs, give yourself room to scale.

That's 65,536 IP addresses. I mean, if you have that level of concurrency, AWS will really love you.

Still, for the small company/startup, not really thinking about multi region or anything like that, makes perfect sense. You have better things to worry about.

So the first real question is, do you need this? I'm not from AWS or their sales force, so I am not trying to convince you. In fact, I'd posit that if you don't know you need it, you probably don't. Ask yourself,

• Do we have a lot of accounts in our default setup?
• Do those accounts have a more than one VPC?
• Do you operate this pattern in multiple regions?
• Do you forsee any kind of cross region communication?
• Do you connect to on-prem or external partners?
• Have you actually looked into peering Transit Gateways?
• Did that make you hate your life?
• Can you afford this? hint: you're looking at a base cost of at least 500+ per region, not including attachment costs

Still with me?

CloudWAN overview

AWS CloudWAN is a managed networking service. AWS has another one of these, called the Transit Gateway. They are very much related. Very much. So let's first define that one.

Transit Gateway

AWS Transit Gateway is essentially a centralised hub in your account which can be used to connect

• VPCs
• VPNs
• Direct Connects

and propogate both the traffic between these connected services, as well as propogate routing information between them. Sounds pretty cool right? It gets better. You can share Transit Gateways across your organisation via RAM

So what's the problem then?

Transit Gateways are a Regional Service. This will lead you to Transit Gateway peering. This allows you to link intra and inter regional Transit Gateways. However, you can only have static routes to the peering attachments. Now you will go down the rabbit hole of lambdas updating routing table entries and, well, no.

there is of course more to Transit Gateways...

CloudWAN to the rescue

CloudWAN is built on the Transit Gateway tech. Transit Gateways use BGP under the hood. In case you're unfamiliar with BGP, welcome my summer child, read here Quick summary, BGP is a path vector routing protocol, of which the internet is built. It's designed for massive scalability and stability.

CloudWAN consists of

• Global/Core Network
• Segments
• Core Network Edges
• Attachments

It's deceptively simple. But like Lego, you can do a lot with a few pieces. In this case, a whole global network.

Let's do a quick deployment

Via your favorite provisioning tool, you will provison a global network, a core network and define your network policy. Your network policy defines

• which regions you deploy Core Network Edges (CNEs)
• which segments you create
• how they can talk to each other and who propogates what
• which attachments you have
• rules for attaching

Cloudformation

AWSTemplateFormatVersion: 2010-09-09

Description: CloudWAN Deployment

Resources:
  GlobalNetwork:
    Type: AWS::NetworkManager::GlobalNetwork
    Properties:
      Description: Global Network - Viking Ops
      Tags:
        - Key: Env
          Value: asgard
        - Key: Name
          Value: network-asgard

  CoreNetwork:
    Type: AWS::NetworkManager::CoreNetwork
    Metadata:
      cfn-lint:
        config:
          ignore_checks:
            - E3002
    Properties:
      GlobalNetworkId: !Ref GlobalNetwork
      PolicyDocument:
        version: "2021.12"
        core-network-configuration:
          vpn-ecmp-support: true
          asn-ranges:
            - 64520-64620
          edge-locations:
            - location: eu-north-1
            - location: us-west-2
        segments:
          - name: prod
            require-attachment-acceptance: true
            isolate-attachments: false
            edge-locations:
              - eu-north-1
              - us-west-2
          - name: nonprod
            require-attachment-acceptance: false
            edge-locations:
              - eu-north-1
              - us-west-2
          - name: sharedservices
            require-attachment-acceptance: false
            edge-locations:
              - eu-north-1
              - us-west-2
          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
          segment-actions:
            - action: share
              mode: attachment-route
              segment: sharedservices
              share-with: "*"

Outputs:
  CoreNetworkId:
    Value: !GetAtt CoreNetwork.CoreNetworkId
    Description: Core Network Id
  CoreNetworkArn:
    Value: !GetAtt CoreNetwork.CoreNetworkArn
    Description: Core Network ARN

So, 80+ lines of Cloudformation and you have yourself a global network, ready to attach your VPCs and propogate those routes/traffic.

What's next?

Well this is just the start. We're gonna run down the following in the upcoming series

• How to plan for a global network
• IPAM
• Egress/Inspection
• External connectivity