Thread by @nickpowpow

This is low-key exciting - you no longer need to attach an internet gateway to your NAT gateway. I'll explain a bit more of why you may want to do this. 🧵 aws.amazon.com/about-aws/what…

This came up in a customer conversation multiple years ago when a customer said "we're going to give each developer two VPCs, one with routable space (/28) and one with junk space that can't reach on-prem"

I looked at this kind of sideways, and thought man, that's a lot of extra VPCs plus you can't access AD/auth/databases/shared services or those kinds of things from the playground space, plus the overhead of 2x your VPCs

So over some more thought, and I think beer was involved, I figured out you can add a secondary CIDR range of 100.64/12 to any VPC (we actually had to update the documentation for this), and then you can use that space as a playground.

Then the challenge was you could filter that playground space, but still didn't fix the reachability back on-premises. You may want to watch this little blurb on 'NAT school' from re:Invent 2019:

Essentially the NAT gateway just NATs to your private address. It doesn't turn into a public address until the NAT gateway looks at the route table and forwards it to the internet gateway, which turns it into a public IP like any other boring EC2 packet.

In this case, it meant we could put the NAT gateway in the 'routable' subnet, point the default route in the playground subnet to the NAT gateway, and we'd magically be able to reach on-premises resources using that routable space. It's one-way, but generally works great.

It was actually pretty widely used after that, and made it's way into some blog posts and other presentations, like this one: aws.amazon.com/blogs/containe…

However, this particular customer *really* didn't like opening up internet access. And when we designed NAT gateway we thought all customer would use it as we designed, so we created a check that there is an internet gateway attached to the VPC.

So, customers have been widely doing this kind of NAT trick to change their source addresses for a wide variety of things, including IP conservation, changing the address they use to send to their partners, solving some overlapping CIDR ranges and more. But they need an IGW.

And so today, we fixed that. You can create the NAT gateway without the IGW and use it privately. I actually have a sort of crazy deck on the 15 ways you can abuse this feature for good and evil, some (many) of which made their way into customer architectures. An example:

So with this knowledge you can primarily do 3 things:
1) Build NAT architectures without exposing things to the scary internets
2) Pray at the altar of NAT, and get rewarded with the power to build unholy architectures
3) Nerd snipe people who misunderstand NAT gateway

And while I have my deck of crazy TGW architectures, here's the one that shows you how to peer TGWs in the same region. (It's still not an awesome option, but it works, so just make sure you read the bad news box in red.)