# fck-nat: the 10% idle figure holds on the cheaper storage tier, not the default one

> A published AMI that replaces a managed NAT gateway with a NAT instance on the smallest ARM instance type, with the price comparison printed in the readme. The savings claim checks out on cold-tier storage and is slightly optimistic on the default tier, and the project says plainly that it is not for five nines.

**AndrewGuenther/fck-nat** — Feasible cost konfigurable NAT: An AWS NAT Instance AMI

- Repository: https://github.com/AndrewGuenther/fck-nat
- Website: https://fck-nat.dev
- Stars: 2,253 · Forks: 97
- Language: HCL
- License: MIT
- Published: 2026-09-30 · Updated: 2026-09-30 · Language: en
- Canonical page: https://hysenlabs.com/projects/andrewguenther-fck-nat

## The idle cost claim is a tenth only on the colder storage tier

The readme prints the whole price comparison, which makes it checkable. A managed NAT gateway is listed at 0.045 dollars per hour and 0.045 per gigabyte, with no storage charge. The smallest instance the project targets is listed at 0.0042 per hour, with no per-gigabyte charge at all, plus either 0.64 dollars per month for general-purpose block storage or 0.12 per month for the cold tier. A month is roughly 730 hours, so the managed gateway costs about 32.85 dollars sitting idle with nothing flowing. The instance plus the cheaper storage tier comes to about 3.19, which is under a tenth of it. The same instance on the default tier comes to about 3.71, which is closer to eleven percent. So the headline is right for the configuration it was calculated for and slightly optimistic for the one people use first. The readme adds that in practice the savings are greater, without a figure.

## The ceiling is AWS's, and the author argues it retires the alternative

The bandwidth limit is the whole story for who should use this, and the readme is explicit about it: AWS caps outgoing internet bandwidth on instances at 5Gbps, so the highest speed fck-nat can support while remaining worth it is 5Gbps. That covers a wide range of workloads, and anything beyond it should use the managed gateway. What is interesting is the argument that follows. The readme reasons that if AWS ever lifted the limit, fck-nat could be run cost-effectively at speeds up to 25Gbps, and then asks, pointedly, whether you would still need the managed gateway. That is the author arguing that the managed service survives only because of a platform limit rather than because of anything it provides, which is a strong claim and one the readme backs with a link to the instance bandwidth documentation.

## The official NAT instance AMI loses on age, on end-of-life, and on architecture

The readme answers the obvious objection first, in italics, by explaining why not to use the AMI AWS already provides. Three reasons, given in one sentence each. It has not been updated since 2018. It still runs the first generation of Amazon Linux, which has reached end of life, so it is not receiving patches. And it has no ARM support, which means it cannot be deployed on the instance types the same readme calls EC2's most cost-effective. That third reason is the one that matters most for the cost comparison, because the project is built around an ARM instance type at a small fraction of the managed gateway's hourly rate, and an AMI that cannot run on ARM cannot be compared to it at all. The project's own answer is that it is not a specialisation of the official AMI but a separate build on a current operating system.

## The readme says not to use it if you need five nines

One paragraph is worth quoting more than any of the price tables, because it is the one that tells you when not to buy this. If you have an allergy to non-managed services, the readme says fck-nat may not be for you. It supports a high-availability mode, but it is not completely immune to outages, which it qualifies as very rare. And if your workload requires five nines of uptime, it says a managed NAT gateway is probably the better option. That is an unusually clear statement of the boundary, made by the project rather than inferred by a reader, and it pairs naturally with the bandwidth ceiling: beyond 5Gbps, or beyond five nines, the correct answer is the thing this project is replacing. It also reframes the design. The value proposition is not that the service is better, it is that the same egress is cheaper.

## The deliverable is an RPM built by fpm and baked into an AMI by packer

The build file shows the delivery mechanism, and it is unusual. There is no application code in this repository at all; the primary language here is the configuration dialect for building machine images. What gets built first is a package: a target creates a build directory, removes any previous package file, and invokes a packaging tool to produce a distribution package named with the version and the word any, meaning architecture-independent. That package is then handed to the image builder, which runs only the one named build, passing the version and two variable files, one carrying the architecture-specific values and one carrying the operating-system values. So the update path is a package inside an image, and the image is rebuilt from that package rather than configured at boot.

## Four images are published, and half of them exist for IPv6

The build targets name four artifacts, and the naming makes the design legible. There is an ARM64 target and an x86 target, and then a NAT64 variant of each. NAT64 is the translation layer that lets an IPv6-only host reach IPv4 destinations, so half of the published images exist specifically to make an IPv6 network able to talk to the rest of the internet without a second dual-stack path. Each architecture has its own variable file carrying its own values, while the operating-system values are shared, and the image builder distinguishes the two builds by name. The aggregate target simply depends on all four, and a second target exists for the public release path. The one oddity is the package filename saying architecture-independent while the contents are architecture-specific binaries, which is a wrapper package convention rather than a mistake.

## One flag switches the build between your regions and every public region

Look closely at how the region list reaches the build, because it is the difference between a private AMI and a public one. The individual targets reference a make variable for the regions file, and the local build path leaves that variable unset, which is why the release target explicitly assigns it before depending on the aggregate. The assigned file is the one covering all public regions. So the same four build commands produce images in whatever regions your own configuration names, and the release process re-runs them against the full public set by setting one variable. It is a small piece of engineering that makes the difference between a personal build and a published one almost invisible in the commands themselves, which is the point.

## The build exports a thirty-minute retry budget for AWS

Two environment variables at the top of the build file are exported for every recipe: a maximum attempt count of 120 and a delay of 15 seconds between polls. Multiplied out, that is a half hour of patient waiting before the build gives up on whatever it is asking AWS to do. The reason is not visible in the file and does not need to be: copying an image across regions and registering it everywhere it needs to exist is slow and occasionally needs retrying, and a build that fails on a rate limit would be useless for a project whose entire output is an image. The version number is a single variable in the same file, threaded into both the package filename and the image builder, so there is one place to change it. It matches the newest release tag.

## Conclusion

fck-nat is worth evaluating if your egress bill is dominated by managed gateway hours and you can accept running a component yourself. Four things decide whether the arithmetic works for you. Recompute the idle figure rather than trusting it, because the ten percent claim in the readme is accurate only if you store the NAT instance's data on the colder and cheaper storage tier rather than the default one, and the difference between those two choices is a tenth of the claim. Check your egress bandwidth ceiling, since the whole approach is capped by the limit AWS places on outbound internet traffic from an instance, and the readme itself tells you to use the managed gateway if you exceed it. Decide whether your uptime requirement allows a self-managed component, because the project says so explicitly. And if you use IPv6 addressing, note that the NAT64 variants are built and published alongside the others rather than being an afterthought.

## FAQ

### What does NAT stand for in AWS, and what is a NAT gateway?

This repository does not define either term. It compares a managed NAT gateway against self-hosted NAT instances, and what it states about the managed side is its price: 0.045 dollars per hour and 0.045 per gigabyte with no storage charge. It also notes that AWS limits outgoing internet bandwidth on instances to 5Gbps.

### How much does NAT cost on AWS?

A managed NAT gateway is listed at 0.045 dollars per hour and 0.045 per gigabyte, with no monthly storage charge. The smallest instance the project targets is listed at 0.0042 per hour with no per-gigabyte charge, plus 0.64 per month for general-purpose block storage or 0.12 per month for the cold tier.

### When should I use a managed NAT gateway instead of fck-nat?

When you need more than the 5Gbps of outgoing internet bandwidth AWS allows on an instance, or when your workload needs five nines of uptime. The readme says its own high-availability mode is not completely immune to outages, however rare, and that a managed gateway is probably the better option at that requirement.

### Does fck-nat replace the AWS NAT instance AMI?

That is the comparison it draws. The readme says the official NAT instance AMI has not been updated since 2018, still runs Amazon Linux 1, which is end of life, and has no ARM support, so it cannot be deployed on the instance types the same readme calls EC2's most cost-effective. fck-nat publishes its own ARM and x86 images on a current operating system.

## Sources

- [AndrewGuenther/fck-nat on GitHub](https://github.com/AndrewGuenther/fck-nat)
- [License: MIT](https://github.com/AndrewGuenther/fck-nat/blob/main/LICENSE)
- [Project website](https://fck-nat.dev)
- [README](https://github.com/AndrewGuenther/fck-nat/blob/main/README.md)
- [Releases](https://github.com/AndrewGuenther/fck-nat/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/andrewguenther-fck-nat