alternat VS fck-nat

This is perfect for preprod environments. I'd probably not deploy in production. There is a better nat instance setup available called alternat [1] which is a little more durable and better for production cases.

[1] https://github.com/1debit/alternat

We use https://github.com/1debit/alternat in our EKS cluster to save the AWS tax (surcharge for NAT on top of the egress fee)

Unfortunately we've been getting absolutely hammered by NAT gateway pricing, and we've had to switch over to NAT instances. We deployed (alternat)[https://github.com/1debit/alternat] for some OOTB resiliency, but I've never had to manage a group of NAT instances myself at this scale.

alterNAT is another approach that makes it even easier, and falls back to NAT GW if needed.

As for the alternatives they already exists. Feel free to create more if your like, more the merrier. https://github.com/1debit/alternat

You can go around NAT gateway costs (not completely) by using alternat: https://github.com/1debit/alternat

Welcome to hell. I default to public subnets where possible; past that I either bend the knee or use alterNAT.

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/