The NAT tax is real. We got to tens of thousands of registered users of our app with the $30/month NAT gateway being like 90% of our AWS bill. And it didn't even serve customer facing traffic! At the time, it's only use was for a serverless Aurora DB used by background jobs.
It only gets more expensive when you actually serve large amounts of traffic, need multi-AZ setups, and run multiple AWS accounts for different envs for beta/prod and each engineer's sandbox account. The worst part of cloud billing is how each base cost has several dimensions of multipliers.
I don't know about your specific network architecture but, if you need to access AWS services from inside your VPC, make sure to configure a VPC endpoint for the services where it is available(RDS is one of them).
Far too many people forget about that and send their AWS traffic through their NAT GWs.
Keep in mind for low traffic sites, it may be cheaper to use NAT, if you already need it for something else. All those "VPC endpoints" can really add up. It's kind of crazy you gotta pay for the privilege of connecting to AWS from within AWS.
Tbh this site is pretty misleading. Fastly and Cloudflare support ipv6 pretty well in their productы, it’s just that their marketing team apparently don’t care
The website is pretty explicit about that it's testing if a domain/website is available over IPv6 vs IPv4. Clicking on a website also sends you to https://ipv6.fail/domain/cloudflare.net/ where it's even more explicit what they're testing against. Wouldn't call it misleading exactly.
You do realize this is AWS policy, right? I mean you cannot run away from AWS costs ... on AWS. They are targeting dollar amounts of profits for themselves, not charging cost+20% for service X. They will find some other way to charge you the yet more than you're saving here, because MBA culture.
And AWS is like 10x more expensive than dedicated hosting, minimum. Not 10%, 1000%. To the point that for the price of
I mean if cost matters to you you need to move out of the cloud. Plenty of Kubernetes hosting these days, and very easy to set it up yourself.
This. You then work to dig deeper into the vendor lock-in, to move your apps to use apparently cheaper AWS-only services, and if you're wily (or oblivious) you can report this as cost savings.
Thank you for creating the project! Oddly enough I came across fck-nat last week and have been looking into incorporating it into my project app to avoid paying the $30+ per month for the managed solution.
As someone who is new to setting up VPCs and networking, how does this work? I was so curious I even tried to query ChatGPT about it a couple of days ago but I got a less than satisfactory answer.
Is the secret to making it work disabling the "source destination check"? Say a host in the private subnet wants to connect to a host on the internet, it tries to connect to <PublicIP>, and sends some IP packets over the subnet via the ENI, does the VPC subnet act like an old-school ethernet connection where fck-nat gets the IP packets for <PublicIP> (source/dest is disabled so it receives the packets) and then it forwards it to the internet gateway and does the network address translations when it receives a response packet?
From the VPC perspective, the key here is understanding that subnets within VPCs have route tables that determine where traffic from your subnet goes next. In this case traffic to the internet is sent to an interface on the NAT instance.
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.
Author of fck-nat here. My big issue with Alternat is that it actively updates the route table which can still cause availability problems. It's a shorter outage than the current fck-nat replacement methodology, but it is still dropping connections.
The longer term vision for fck-nat is a two node approach using conntrackd and keepalived to actively failover existing connections to the secondary with no loss of availability. This has the added benefit of not requiring all of the auxiliary infrastructure that Alternat sets up.
That's an awesome update! I currently run fck-nat in pre-prod environments (and love it so far) but still use NAT gateway in production. I was actively looking into switching over to AlterNat for prod because of the failover to NAT gateway during NAT instance updates and outages, but definitely not a fan of the complexity you're eluding to. The future plans you've outlined definitely make me want to wait it out and just use fck-nat across the board. Thanks for sharing these plans!
I don't want to get anyone too hyped on it just yet because there's still a lot of testing to be done, but hopefully will start giving some more concrete updates on "fck-nat 2.0" soon-ish!
Also if you're open to it, I'd love to reach out and get some feedback on your experience with fck-nat, how many environments you're running it in, etc. Is that something you'd be open to? If so, what's a good way to get in touch?
IPv4 clients are a different problem, with a different solution -- NAT is for outbound connections. Of course, plenty of services you want to connect to could only support IPv4.
IPv6 internally doesn't stop you running public IPv4-accessible services.
What type of NAT algorithm are you using for your NAT here? E.g. full cone, symmetric, etc. Such details can be useful for testing. Currently I'm having to code a small script to simulate different NAT behaviours so I can test trying to traverse them easily. I looked for a way to do this kind of thing with cloud networking ages back but they were no where near as configurable as needed. Normally the details were hidden. IDK what they would be using in that case.
The other thing is the port allocation algorithm. Many home routers try to preserve the source port (assuming its available.) But there's other algorithms that could be used here like independent delta +1 (increment each new mapping by +1) and others. IDK if there's a target market for something this specific or niche. But thought I'd put it out there.
Any chance you're willing to share your scripts? I'm interested in trying out NAT traversal, too, and was starting to research ways to simulate all the different types.
One use case for NAT is lambdas calling out of their VPC to the internet. Not everything is v6 friendly yet.
I'll try and deploy this. Our NAT costs aren't that high, but reducing spend is worth an hour or two. I might leave this as something for the new guy, just so we can see if he can do it without taking down the environment.
If you did it right, your tool or service will exist for decades to come, if you have the option to not call it something fsck, fwkc, fck, etc. it's worth exercising that option.
If you're too stuck up to appreciate a funny pun, don't use the software. No one's holding a gun to your head. Or you could relax, not everything needs to be "serious business".
While not really being one who cares personally about the example here, I would not give a tool a name that I full well know will offend the sensibilities of some who will use it. That would make me a jerk, no matter how funny or whimsical I may find it.
Even when poking fun at myself, I choose names of projects carefully. It's pretty easy to not be a jerk, at least in this way.
> I full well know will offend the sensibilities of some who will use it
How could you possibly know this, where do you draw the line?
For something people, "Hacker News" is surely offensive because "hacker" is generally thought of as a negative term (Yes, I know our meaning, others generally don't).
GitHub could also be offensive to some, "git" after all is as much of a swear-word as "fck".
An early-90s textbook I read about encryption said that some people were disgusted hearing the word 'decrypt' for the first time because a crypt is a place where dead bodies were stored. They suggested (to those offended) to use the word cipher instead ;)
Good luck explaining a less-techy client at your job that fck-nat, fsck (which was originally just "fuck", afaik) and so on are fine puns and no one's holding a gun to their head either. I feel similar about recursive acronyms. These are funny-ish when you're in your mom jokes phase, but then someone asks you what that means and sometimes you can see their "what a bunch of creeps" reaction when you try to explain. Not surprising that people try to avoid that "we can use FCK for our SHT instances in CRP network" nonsense.
The name of 'Git' (the source control system) is literally a derogatory term. I think you overestimate the value or prevalence of decorum. you should also google the relationship between the number of uses of the word "fuck" in code comments with code quality. There's been several papers on it.
In many countries c*nt is one of the more terrible swearwords could imagine. In Ireland it's friendly banter. d*ckhead can be either a term of endearment amongst (close) friends, or an insult in Australia, and worse in other countries.
In many, if not most, non American countries, f*ck just doesn't cut the mustard when swearing.
Heck, in the UK, they have a major high street brand called FCUK.
Here's the thing: there is no reason not to keep pointing out that these are just bad names. And by pointing that out every time, someone might just pay attention and give their tool a better name in the future, because they took heed and decided against calling their tool "cwnt" in favour of calling it "check-wnat". And you will never know it could have been called the "oh stop being so thin skinned" cwnt.
And as a bonus, folks don't have to guess at what it does, the name tells you. Imagine if fsck had just been called checkfs... it would have been both a better name and would have saved a lot of askubuntu/superuser/etc posts.
I am not, I just don’t get why some people are so profanity oriented in naming things. Personally, it doesn’t offend me, but it ridicules them in my eyes, and stops me from talking about it around people. If that’s what they want, okay. If that’s not what they want, they can use this subthread as a feedback. How would they know if no one spoke?
Also, I find your reaction thin skinned-ish as well. Why throw stop commands if you ought to not care? Cause it’s ridiculous? Well, we have more in common than you think then.
> Also, I find your reaction thin skinned-ish as well. Why throw stop commands if you ought to not care?
Oh really. You're the one who can't shut up about some app that used to be named f*ck but was renamed some 30+ years ago still grinds your gears.
It's an (ancient) light hearted joke, please just drop it.
I care about the state of the world, and I find it deeply depressing people run around being prude like we're some kind of Christian middle ages society.
It only gets more expensive when you actually serve large amounts of traffic, need multi-AZ setups, and run multiple AWS accounts for different envs for beta/prod and each engineer's sandbox account. The worst part of cloud billing is how each base cost has several dimensions of multipliers.