Search for a command to run...
I'm a curious Geek with an insatiable thirst to learn new technologies and enjoy the process every day. I aim to deliver high-quality services with the highest standards and cutting-edge DevOps technologies to make people's lives easier.
No comments yet. Be the first to comment.
Introduction If you've ever tried creating a custom VPC in AWS, you’ve probably run into the question:"What CIDR block should I use?" For many DevOps/Cloud engineers, subnetting feels like a leftover from the old networking world — full of slashes, b...
Download 💡 This documents is optimized for mobile view.
![Up and Running with kubectl-ai [PDF]](/_next/image?url=https%3A%2F%2Fcdn.hashnode.com%2Fres%2Fhashnode%2Fimage%2Fupload%2Fv1753898584930%2F01739f18-1331-4d48-b709-fc2750685607.png&w=3840&q=75)
Learn to deal with DNS caches as efficiently as possible. Download 💡 This documents is optimized for mobile view.
![How to deal with DNS caches [PDF]](/_next/image?url=https%3A%2F%2Fcdn.hashnode.com%2Fres%2Fhashnode%2Fimage%2Fupload%2Fv1753101148740%2F9721c8d4-86d5-4ec8-b4f7-c317f7ccfe56.png&w=3840&q=75)
Download 💡 This documents is optimized for mobile view.
![Are Kubernetes Secrets Really Secure? [PDF]](/_next/image?url=https%3A%2F%2Fcdn.hashnode.com%2Fres%2Fhashnode%2Fimage%2Fupload%2Fv1752308392314%2F25995822-24ef-4fab-afa4-f88a806d9e89.png&w=3840&q=75)
🧐 𝗪𝗵𝗮𝘁 𝗶𝘀 𝗲𝗻𝘃𝘀𝘂𝗯𝘀𝘁?envsubst (GNU gettext) streams stdin ➜ stdout, replacing any $VAR with their environment values. Think sed for env-vars, no regex. 🚀 𝗪𝗵𝗲𝗻 𝗱𝗼𝗲𝘀 𝗶𝘁 𝘀𝗵𝗶𝗻𝗲?• Container start-up configs: inject secrets or ...
Navigating AWS NAT options isn’t just about plugging a connectivity hole – it’s about balancing cost, reliability, and complexity for your specific needs. Here’s a quick recap and comparison to help guide decision-making.
Already dual-stack / IPv6-only? → Use an Egress-Only Internet Gateway (no NAT fees).
More than 70 % of bytes go to AWS services? → Shift to Gateway/Interface Endpoints and bypass NAT entirely.
Low-duty or bursty dev/test traffic? → Spin up a Disposable NAT Gateway.
Are you okay with running and patching EC2? → Use a NAT instance, Fck-NAT AMI, or Spot-based alterNAT.
Need ≥99.9 % HA with minimal ops? → Stick with a Managed NAT Gateway.
If none of the above fit, re-evaluate your requirements.
Easiest to deploy (fully managed), highly available within an AZ, and scales to high throughput without user intervention. However, it introduces significant cost at scale (data processing fees) and provides no fine-grained control (no security groups on it, idle costs accumulate). Best for teams that value simplicity and uptime over cost, or when traffic levels are low enough that fees aren’t a concern. Common assumption: “It’s AWS-managed so it must be the best choice” – which is true for hassle-free operation, but as we’ve seen, it can be overkill or too costly for some scenarios.
Public Connectivity:
Access the internet from a private subnet
Private Connectivity:
Access your network using allow-listed IP addresses
The following diagram shows how instances can access on-premises resources through AWS VPN. Traffic from the instances is routed to a virtual private gateway, over the VPN connection, to the customer gateway, and then to the destination in the on-premises network. However, suppose that the destination allows traffic only from a specific IP address range, such as 100.64.1.0/28. This would prevent traffic from these instances from reaching the on-premises network.
The following diagram shows the key components of the configuration for this scenario. The VPC has its original IP address range plus the allowed IP address range. The VPC has a subnet from the allowed IP address range with a private NAT gateway. Traffic from the instances that is destined for the on-premises network is sent to the NAT gateway before being routed to the VPN connection. The on-premises network receives the traffic from the instances with the source IP address of the NAT gateway, which is from the allowed IP address range.
Enable communication between overlapping networks
You can use a private NAT gateway to enable communication between networks even if they have overlapping CIDR ranges. For example, suppose that the instances in VPC A need to access the services provided by the instances in VPC B.
The following diagram shows the key components of the configuration for this scenario. First, your IP management team determines which address ranges can overlap (non-routable address ranges) and which can't (routable address ranges). The IP management team allocates address ranges from the pool of routable address ranges to projects on request.
Each VPC has its original IP address range, which is non-routable, plus the routable IP address range assigned to it by the IP management team. VPC A has a subnet from its routable range with a private NAT gateway. The private NAT gateway gets its IP address from its subnet. VPC B has a subnet from its routable range with an Application Load Balancer. The Application Load Balancer gets its IP addresses from its subnets.
Traffic from an instance in the non-routable subnet of VPC A that is destined for the instances in the non-routable subnet of VPC B is sent through the private NAT gateway and then routed to the transit gateway. The transit gateway sends the traffic to the Application Load Balancer, which routes the traffic to one of the target instances in the non-routable subnet of VPC B. The traffic from the transit gateway to the Application Load Balancer has the source IP address of the private NAT gateway. Therefore, response traffic from the load balancer uses the address of the private NAT gateway as its destination. The response traffic is sent to the transit gateway and then routed to the private NAT gateway, which translates the destination to the instance in the non-routable subnet of VPC A.
| Price per NAT gateway ($/hour) | Price per GB data processed ($) |
| $0.052 | $0.052 |
NAT Gateway Scenarios:
Create a NAT gateway:
Essentially free of AWS surcharges – you pay for an EC2 and standard bandwidth, making it much cheaper for high outbound traffic. You also get more control (security groups, custom AMI possibilities). The trade-off is you manage it: patching, scaling, and handling failover in case of issues. Suitable for cost-sensitive environments and when you have the expertise to manage the instance. It’s a building block for other solutions like fck-nat and alterNAT. Be ready to address the single-point-of-failure problem, either by accepting short downtimes or implementing your own redundancy.
Example:
t2.micro Instance + egress fee + EIP costs for 1 hour:
$0.0134/hour + $0.09/GB + $0.005 = $0.1084/h
How to do it yourself:
A convenient improvement on the NAT instance approach. You get up-to-date, optimized NAT appliances you can launch with minimal effort. This drastically lowers deployment complexity for NAT instances and ensures you’re not running outdated software. Cost benefits mirror the NAT instance (no per-GB fee, can use tiny cheap instances). The main caution is that it’s a community project; while popular, it’s not an AWS native service, so you assume responsibility for it (albeit a small one). Great for small-to-medium workloads in production, and for development setups where you want to eliminate that ~$30/mo per environment NAT Gateway cost. Think of fck-nat as “NAT Instance 2.0” – easier and safer than rolling your own from scratch.
Please refer to the docs for detailed pricing:
https://github.com/AndrewGuenther/fck-nat/blob/main/docs/choosing_an_instance_size.md
Official Site: https://fck-nat.dev/v1.3.0/
Deploy with Terraform: https://fck-nat.dev/v1.3.0/deploying/#terraform
Deploy with CloudFormation: https://fck-nat.dev/v1.3.0/deploying/#cloudformation
Manual Deployment: https://fck-nat.dev/stable/deploying/#manual-web-console
GitHub Repo: https://github.com/AndrewGuenther/fck-nat
A robust solution aimed at larger-scale or mission-critical use of NAT instances. It tackles the reliability concerns by introducing managed failover to NAT Gateways and automates maintenance so your NAT instances don’t become pets you forget to update. It’s ideal for high-volume traffic scenarios (tens of TB per month) where NAT Gateway fees are exorbitant, but you cannot tolerate prolonged outages. The complexity is higher – essentially you’re running a mini service within your infrastructure – but Terraform scripts make it deployable if you’re invested in that ecosystem. alterNAT invites teams to rethink the assumption that “only AWS can provide HA”; it shows you can design a highly available NAT solution yourself. Use it when you have a clear cost imperative and enough scale to justify the complexity. If your NAT Gateway costs are trivial, stick with simpler options.
Please refer to to the project docs for the pricing:
https://github.com/chime/terraform-aws-alternat/tree/main?tab=readme-ov-file#background
There are two ways to deploy alterNAT:
By building a Docker image:
Using Terraform:
GitHub Repo:
A creative strategy by Shahin Hemmati for very intermittent needs. It’s the ultimate cost saver if you truly don’t need continuous internet connectivity – why pay for NAT 24/7 when you use it 2% of the time? By automating NAT Gateway creation on a schedule, you ensure you “only pay for NAT Gateway while it’s actually needed”. The obvious limitation is that it doesn’t work for always-online services. It flips the usual assumption (“NAT must be always available”) and asks, what if it isn’t? Use this for controlled environments like nightly maintenance, offline batch processing, or ultra-secure setups where internet access is a gated event. It requires discipline and coordination, but when applicable, it can nearly eliminate NAT costs (and even provide security benefits by closing egress pathways most of the day).
Cost Analysis of the Disposable NAT Gateway Solution:
| Service | Usage per cycle | Price | Cost per cycle |
| NAT Gateway | 1 hour | $0.052/hour | $0.052 |
| Lambda | 2 invocations, 128MB, 2 min each | $0.20 per 1M requests | Within the always free plan |
| EventBridge | 2 scheduled events | $1 per 1M invocations | Within the always free plan |
| EIP | 1 hour | $0.005/hour | $0.005 |
| Data Processing | 1 GB | $0.052/GB | $0.052 |
| Total cost per cycle | $0.109 |
Cost Analysis of the Disposable NAT Instance Solution:
| Service | Usage per cycle | Price | Cost per cycle |
| EC2 instance | 1 hour | $0.0134/hour | $0.0134 |
| Lambda | 2 invocations, 128MB, 2 min each | $0.20 per 1M requests | Within the always free plan |
| EventBridge | 2 scheduled events | $1 per 1M invocations | Within the always free plan |
| EIP | 1 hour | $0.005/hour | $0.005 |
| Data Transfer | 1 GB | $0.09/GB | $0.09 |
| Total cost per cycle | $0.1084 |
Deploy using CloudFormation:
GitHub Repo:
The forward-looking approach. By adopting IPv6, you can avoid NAT altogether for a lot of traffic. The egress-only IGW is free, high-performing, and simple – if you can use it. This strategy is best when you’re modernizing your network and can ensure both your apps and the services they call support IPv6. It won’t completely replace NAT Gateway until the rest of the world is on IPv6 (and you might still need NAT64 for IPv6-only instances to reach IPv4-only endpoints), but it can dramatically cut down NAT usage. It challenges the common mindset “IPv6 is optional in AWS.” As IPv6 adoption increases, ignoring egress-only gateways could mean literally turning away free bandwidth. Forward-thinking teams in Web, IoT, or cloud-native domains should definitely leverage this: let IPv6 carry as much as possible, and your NAT Gateways (or NAT instances) will only handle legacy IPv4 traffic.
There is no charge for an egress-only internet gateway, but there are data transfer charges for EC2 instances that use internet gateways which is ~$0.09/GB depending on the region.
How to add an egress-only internet access to a subnet:
| Strategy | Cost Efficiency | Security | Scalability | Deployment Complexity | Best Use Case |
| NAT Gateway (Baseline) | High cost, simple pricing; costly at scale due to per-GB fees | No security groups; NACLs and instance SGs apply | Auto scales to 100 Gbps; highly available within AZ | Very easy (AWS managed); zero config | Always-on services needing simplicity and uptime |
| Disposable NAT Gateway (On-Demand) | Extremely low; pay only during active schedule windows | Secure by limited access windows; reduces attack surface | Full NAT Gateway scale during active period; no scale outside window | Low; requires only schedules, public & private subnet ID,s plus route table name | Intermittent egress needs like patching or batch jobs |
| NAT Instance (DIY) | Low cost, no per-GB fee; only EC2 hourly and bandwidth | Can use SGs; responsible for patching and updates | Limited by EC2 instance size; manual failover needed | Moderate; requires EC2 setup, routing, maintenance | Cost-sensitive workloads with moderate traffic |
| fck-nat (Pre-built AMIs) | Very low cost, pre-configured; uses cheap ARM instances | Improved security with modern AMIs; minimal upkeep | Up to 5 Gbps on t4g.nano; scales with instance size | Low; pre-configured AMIs reduce setup effort | Cost-efficient dev/test or small prod environments |
| alterNAT (HA NAT Instance Setup) | Medium; savings at scale but pays for standby NAT Gateways | Automated instance replacement and failover; patching handled | Per-AZ scaling with EC2 sizing; failover to NAT Gateway | High; Terraform setup with ASG, Lambda, route monitoring | High-traffic production environments needing HA |
| Egress-Only Internet Gateway (IPv6) | Free (no processing fee); only standard bandwidth charges | Blocks inbound by design; secure IPv6 egress only | Highly scalable; horizontally redundant by AWS | Low; simple setup but requires IPv6 readiness across the stack | Long-term IPv6 strategy or hybrid egress with IPv6 support |
In practice, many organizations will use a combination of these strategies. For example, you might use fck-nat in dev/test, alterNAT in a high-traffic production environment, and enable IPv6 + egress-only IGW to offload part of the traffic, all at once. The AWS ecosystem allows you to mix and match per VPC or per subnet. The key is to evaluate your requirements and usage patterns. If uptime and simplicity trump everything, NAT Gateway is a fine choice – just be aware of the costs (and perhaps monitor them to catch any surprises). If cost is a major concern, explore these alternatives: you might save a lot more than you expect. Just remember that with greater control comes a bit more responsibility. As one engineer noted in a discussion about cutting NAT costs, AWS will always charge you for something; it’s on you to architect smartly around those charges. In the end, the optimal solution will depend on your team’s tolerance for complexity, your traffic profile, and how much you value a few hundred milliseconds of failover time or a few hundred dollars of savings.
By constructively questioning the default assumptions – “NAT Gateway is the only way” or “managing infrastructure is too risky” – DevOps teams can arrive at a solution that best fits their cost goals and reliability needs. Whether it’s a lean EC2 NAT instance or a full-fledged HA setup with alterNAT, AWS gives us the building blocks to refine our egress architecture. The bottom line: don’t pay $75k in data processing fees if a weekend of engineering can save 40% of that, and don’t hesitate to use multiple strategies as stepping stones (for instance, using fck-nat now and planning for IPv6 long-term). NAT in AWS is no longer one-size-fits-all – and that’s a good thing for the cloud community’s pocketbook and architecture creativity.
Note:
The above costs are based on the AWS pricing as of April 2025 and based on the Europe (Frankfurt) region.
