Let my data go free

NOTE: Also refer to the AWS Global Networking: Service Insertion post for more information as this doesn't totally work. Essentially, you need Service Insertion to push traffic to specific regional egress VPCs.

Ah, centralized egress. Sounds fancy, right? Let's break it down. Imagine all your internet traffic deciding to leave the building through one door. Bottleneck right? Not really. It's like having one super-efficient, highly secure exit that everyone knows. This is what we're aiming for, helped along by Cloud WAN.

Why Bother with Centralized Egress?

Simplified Network Management

Picture this: One rule to rule them all. Instead of playing whack-a-mole with policies across countless exit points, you have one spot to manage. Less is more.

Boosted Security

With all traffic marching through one exit, it's easier to keep an eye out. Think of it as having a bouncer at the door, checking IDs and keeping the bogons out. Plus, you can slap on all the fancy security tools you want at this single point to keep things tight.

Cost Savings

To be honest, this is the real reason. Money talks, and so does efficient use of resources. Just think, all those accounts, VPCs. You know how much AWS charges for NAT Gateways and IGWs? So there is that. Of course trying to frame anything AND Cloud WAN as cost saving is a bit of a stretch.

Implementing Centralized Egress

Now, setting this up might sound like a task for a network guru, but it's not rocket science. AWS Cloud WAN does a lot of the heavy lifting for you, making it more about smart configuration than about being a networking wizard. Though, like all things, the more you know.

Know Your Needs

First up, ask yourself, "Do I even need this?" If you're a small startup not thinking about conquering the world (yet), maybe you can skip this. But if you're looking to scale, keep things secure, and manage traffic properly, then yeah, it's worth a look.

Define your egress point

Choose where you want your internet traffic to exit. This is your golden gate. There are some gotchas here, mostly around how many regions you have deployed CloudWAN and how many egress points you want and if you care about regionality for the egress. What do I mean? Not to go into too much depth, but in CloudWAN, each Core Network Edge (CNE) is connected to every other one. What that means is every region is one hop away from the other. Let's make a picture

Here we have four regions. Let's say we make two egress VPCs, one in the US, one in EU. Sounds reasonable right. So one in eu-west-1 and one in us-east-2. OK, keep this in mind.

So now we need to make sure traffic knows how to get out. This means you're going to do a few things

Egress needs to be accessible by the various segments that need to get out. Let's assume dev and shared need to get out, so then we'd modify our CloudWAN policy as follows

````yaml showLineNumbers
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-west-1
            - location: eu-central-1
            - location: us-east-2
            - location: us-west-2
        segments:
          - name: prod
            require-attachment-acceptance: true
            isolate-attachments: false
            edge-locations:
              - eu-west-1
              - us-east-2
          - name: nonprod
            require-attachment-acceptance: false
            edge-locations:
              - eu-west-1
              - us-east-2
          - name: sharedservices
            require-attachment-acceptance: false
            edge-locations:
              - eu-west-1
              - us-east-2
          - name: egress
            require-attachment-acceptance: false
            edge-locations:
              - eu-west-1
              - us-east-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
            - rule-number: 400
             conditions:
                - type: tag-exists
                  key: egress
              action:
                association-method: constant
                segment: egress
          segment-actions:
            - action: share
              mode: attachment-route
              segment: sharedservices
              share-with: "*"
            - action: share
              mode: attachment-route
              segment: egress
              share-with:
                except:
                  - prod

Then next, you

Test and Tweak

Like anything in tech, it's all about iterating. Set it up, see how it runs, and adjust as needed. You might find that you need to tweak routes or policies as your needs evolve.

Again, do You Need It?

So, back to the big question: Do you need centralized egress? If your setup is small and manageable, maybe not. But if you're looking at a future where scale, security, and management are key, then it's a solid yes. It's not just about handling traffic; it's about doing it smartly, securely, and cost-effectively.

What's next?

We are making solid progress. We've got the following still upcoming:

External connectivity