fck-nat VS aws-transit-gateway-connect-sample

https://github.com/AndrewGuenther/fck-nat/blob/main/service/... this is the bit you need to understand.

You've got the gist of it, but you probably want to read about NAT and iptables.

The source destination check is important - but implementation specific here. Google Cloud does it like this - https://cloud.google.com/vpc/docs/using-routes#canipforward

This entire thread is about the additional costs imposed on a publicly accessible IP[1].

Granted, there are other (but similarly expensive) workarounds such as NAT gateways[2] for outbound connectivity or the cheaper NAT instance method which AWS doesn't support any more, but there are alternatives[3]. However, for use cases requiring inbound connectivity such as setting up websites on EC2 instances, or using an ELB which need internet access, these charges definitely rack up.

[1] https://aws.amazon.com/blogs/aws/new-aws-public-ipv4-address...

[2] https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-gat...

[3] https://fck-nat.dev

Weird, I was just looking into this yesterday and found https://fck-nat.dev/

If you find yourself needing NAT Gateway after all, I recommend https://fck-nat.dev/ - the name speaks for itself. If you use CDK, using it in place of managed NAT Gateway is dead simple.

There are tradeoffs for using a managed NAT Gateway that are usually not considered. It's sort of a roller coaster, but the introduction for the fck-nat project goes in to the most obvious tradeoffs

May I suggest https://fck-nat.dev/ ?

For those unaware: https://fck-nat.dev/

I maintain a NAT instance AMI that works on both ARM and x86: https://fck-nat.dev/

If you need a generic replacement for NAT Gateway you can build one using Transit Gateway and a pair of router VMs running GRE+BGP.

Amazon has most of an example here using quagga (but CloudFormation, ick): https://github.com/aws-samples/aws-transit-gateway-connect-s...