Published on

AWS Global Networking: Planning

Authors
  • avatar
    Name
    Kris Gillespie
    Twitter

You need a plan.

cloudwan

I know you're probably here for that sweet sweet technical info and trust me, it's here, but we need to set the stage. It's not that I don't trust your ability. More, I just don't know you. So let's just agree to quickly lay this out.

You need an IP plan

Every hardcore AWS fanboy I've come across says things like

"Networking is vastly simplified in AWS." "Just go with a a /16 per VPC and /24s per subnet." "Think concurrency"

On the surface, assuming you don't scale too much, should be fine. But then, why are you reading this? I'm gonna assume you and your business has some kind of global aspirations. I'll also assume you probably deploy a common pattern in each region you want to expand to. Something like, regional specific and some shared core services. Assuming you also follow current best practices of splitting concerns via accounts then lets assume something like:

50 accounts. 30 or so have 1 or more VPCs deployed in each region you operate. 10 are shared and just deployed in a limited number of regions. The rest are just single region specific. Each VPC has a designation. Public/Private and maybe based on type of service (lambdas like to scale, need more ips, maybe) Also consider any external connectivity. Direct Connect and Data Centers. VPNs. Do you need to NAT incoming? Maybe consider a separate range for all that too.

In the end, you're going to want to do something like

  • Take 10/8, divide it by the number of regions you believe you'll be in. Then add a few more.
  • Divide each region into the number of accounts/VPCs. Then add a few more. At least double the amount (I would)
  • Then do your subnet splitting.

Then put all that, into IPAM

AWS VPC IPAM

The best way to explain how AWS IPAM functions is with a quick picture

ipam-pool

You define a hierachy. Once visualised, it makes a lot of sense. The other nice aspect of IPAM is that you can quickly lookup the details of any IP. Very useful for trying to hunt down things from your VPC flow logs. Now the real trick. Assuming you deploy all your infra from code, you can now reference these IPAM pools when you are provisioning your VPCs.

Example Cloudformation

VPC:
  Type: AWS::EC2::VPC
  Properties:
    Ipv4IpamPoolId: ipam-0f0f1234a12ab1234
    EnableDnsSupport: 'true'
    EnableDnsHostnames: 'true'
    Tags:
     - Key: env
       Value: prod

IoC and planning = Zen

Lastly, add some pools for external connectivity if you have that on the roadmap. I'd just take either the 172.16/12 or 192.168/16.

So by doing a bit of work up front, digging into subnetting and planning a bit forward, you now have a plan. You can stamp out your pattern in any region on your radar and know you'll never have overlapping ips

What's next?

We are still just beginning. We've got the following still upcoming:

  • Connecting a VPC to CloudWAN
  • Egress/Inspection
  • External connectivity