fck-nat replaces a managed gateway with your own instance, and prices the trade honestly

The readme prices the competition, then concedes the ceiling

The opening is a cost comparison laid out as a table in prose, and it is worth taking apart. The managed gateway is charged both hourly and per gigabyte, at the same rate for each. The alternative is an instance type billed hourly at roughly a tenth of the managed hourly rate, with a per-gigabyte charge of zero, because you are paying for compute rather than for a data transfer product. Against that, the readme adds the cost people forget: the managed gateway has no storage charge, while an instance needs a volume, and it gives two figures for two volume types, one at a few times the managed storage rate and one at roughly a fifth of it. The summary claim is that sitting idle this costs about a tenth of the managed option, and that in practice the savings are greater. That is a well-constructed argument and it is honest about the one cost the comparison adds. The next paragraph is better still, because it is written in the voice of someone who has already been asked. It answers the question a sceptical engineer asks, which is why not use the official vendor image for this, and the answer is that the official one has not been updated since 2018, is still running an operating system release that is now past end of life, and has no ARM support, which means it cannot be deployed on the cheapest instance types. That is a specific, checkable claim about a specific product, and it is the strongest thing in the readme.

Five gigabits, and that number decides whether you use this

The second sceptical question gets the honest answer. The readme states that the vendor limits outgoing internet bandwidth on compute instances to five gigabits per second, and therefore the highest bandwidth this approach can support while remaining cost-effective is that same figure. It says that covers a very broad set of use cases and that if you need more you should use the managed gateway. Then it adds the hypothetical: if that limit were lifted, this could be operated cost-effectively at up to twenty-five gigabits, and at that point the managed option would not be needed. That paragraph is the whole project in miniature. The tool is not competing on capability; it is competing on price inside a bandwidth envelope that the platform sets. For a team whose egress is a few hundred megabits, the argument is decisive. For a team doing large data transfer, media delivery or anything bursty, the tool is the wrong shape and the readme says so. The third paragraph completes the honesty by naming a non-financial objection: if you have an allergy to non-managed services, this may not be for you, because although a high-availability mode exists it is not completely immune to outages, and if your workload requires the highest availability levels the managed option is likely better. A vendor comparison that tells you when not to buy is rarer than it should be.

Two processor families, two network modes, one packaging step

The build file is where the engineering is, and it is short enough to read in full. A version variable is defined at the top. Two environment variables set a retry policy for the cloud calls the build makes, with a high attempt count and a delay between them, which tells you the build talks to many regions and expects to be throttled. The packaging target builds a package file using a Ruby packaging tool, producing an architecture-independent package with the version in the filename, and it deliberately removes any previous artefact first so a rebuild is clean. Every image target depends on that packaging step, which means the package is built once and reused across all four images rather than four times. There are then four image targets: ARM and x86, each in two variants, one plain and one in what the target names call a NAT64 mode. That naming is the tell. A NAT64 instance is a specific configuration for translating traffic to and from a protocol the instance cannot speak natively, and having both variants built for both processor families means the project is covering the IPv6 migration path as well as the cheap-instance path. The final targets assemble all four, and a publish target substitutes a different variable file listing every public region before doing the same thing, so the published images and your own build differ only in which regions are included.

How to build the images yourself

The makefile is the only instruction that exists in the repository, and it is a build for four images. The aggregated target is the one to run, and it depends on the other four so you get every processor and network combination in one pass:

make al2023-ami

Each of those passes a version variable, two variable files, and a regions file into an image build tool, so the build is parameterised rather than hardcoded, and the regions file is the switch between building for yourself and building for publication. The packaging step that everything depends on is a single command producing an architecture-independent package:

make package

That dependency structure is the design decision. One package, four images, and a variable file per region set, so a change to what runs on the instance is made once and every image picks it up. A project that shipped four hand-maintained image recipes would drift, and a contributor adding a feature would have to get it right four times.

Image building, a service directory, and a documentation site

The repository layout says what this project is made of. There is a directory for the image templates, one with variable files in a configuration language, which is the standard arrangement for a reproducible image build. There is a service directory, which is presumably what runs on the instance once it boots, since the image is a normal Linux system with a package installed rather than a purpose-built appliance. There is a documentation directory with its own site configuration and a requirements file for the documentation tooling, so the docs are built from source and published like the images. There is an overrides directory, which in this kind of build usually means the places where the template departs from the base distribution's own image. A makefile at the root and a packaging directory. And two files that are about the project's relationship with money: a funding configuration file and a licence. The funding file's presence alongside a project that saves you money is a small detail, and the licence is the permissive one. What is absent from the listing is as informative: no source for a daemon, no test directory, no continuous integration badge in the readme, and no infrastructure-as-code for the instances themselves. So this repository builds images, and the networking that launches them is something you write, which is consistent with the readme's framing of it as a component rather than a service.

Editorial conclusion

Use fck-nat if your outbound traffic is steady and well under the bandwidth ceiling, because the saving is an order of magnitude on both the hourly and per-gigabyte charges and the operational cost is a machine you patch yourself. Do not use it if you need the availability guarantee of a managed service, since the readme says plainly that it is not immune to outages and that a workload requiring the highest availability levels should use the managed option. Four things to verify. Your peak outbound bandwidth against the stated five-gigabit limit, because that ceiling is not a design choice but an instance limit and crossing it means a different architecture. How you handle the machine image lifecycle, since the value of the project is that it is current where the official one is not, and that advantage disappears if you do not track its releases. That the high-availability mode is configured and tested, because the readme mentions it as existing without describing it. And which region you are in, since the build produces per-region images. The licence is MIT, version 1.4.0 was released on 2026-02-03, and the last push was on 2026-07-02.

Frequently asked questions

Official sources

1. AndrewGuenther/fck-nat on GitHub
2. License: MIT
3. Project website
4. README
5. Releases