In AWS, when would you run a self-managed NAT instance on EC2 instead of a managed NAT gateway, and what do you take on operationally by doing so?

## The default answer, and why it is the default For almost every production VPC, the right egress device is a **NAT gateway**. It is a managed appliance: AWS builds it redundantly within its Availability Zone, scales its throughput for you as traffic grows, patches nothing you can see, and exposes no host for you to compromise. You create it in a public subnet with an Elastic IP and point private route tables at it. That is the whole operational surface. The price is a per-hour charge for each NAT gateway plus a **per-GB data-processing charge on every byte that passes through it, in both directions**, and that second component is what drives people to look for alternatives. It is charged on top of any normal data-transfer-out charge. ## What a NAT instance actually is A NAT instance is an ordinary EC2 instance in a public subnet, with a public address, configured to forward and translate traffic for other subnets. The one AWS-specific step is disabling the instance's **source/destination check**. By default EC2 drops any packet an instance sends or receives whose source or destination is not the instance itself — a sensible anti-spoofing default that makes routing impossible. Turning it off is what converts an instance into a router: ``` aws ec2 modify-instance-attribute \ --instance-id i-0123456789abcdef0 \ --no-source-dest-check ``` The forwarding and address-translation configuration on the host itself is ordinary Linux networking, not an AWS feature. ## The honest comparison **Cost.** A NAT gateway's hourly charge is roughly that of a small always-on instance, and then the per-GB processing charge accrues on top. A `t4g.nano` or `t4g.micro` NAT instance has no per-GB processing charge at all — you pay for the instance and for normal data transfer. For a development account pushing a few gigabytes a month, the instance can be an order of magnitude cheaper. For a production account pushing terabytes, the instance's bandwidth ceiling becomes the binding constraint long before the savings matter. **Bandwidth.** A NAT gateway scales its throughput automatically as traffic grows, with no action from you. A NAT instance is capped by its instance type's network performance, and small burstable types have credit-based network and CPU limits that produce exactly the kind of intermittent, load-dependent slowness that is miserable to diagnose. **Availability.** A NAT gateway is redundant inside its Availability Zone; if the underlying hardware fails, you do not notice. A NAT instance is one instance. If it stops responding, the route table keeps sending traffic to it and every private subnet behind it loses egress. Building real HA means health-checking the instance and having something rewrite the route table entry to a standby — an Auto Scaling group of size one plus a bootstrap that claims the route is the common pattern, and it is genuinely more moving parts than most teams want in the path of all outbound traffic. **Capability.** This is the underrated column. A NAT gateway cannot have a security group attached, cannot forward a port inbound, cannot run a proxy, and gives you no per-connection visibility beyond CloudWatch metrics and flow logs. A NAT instance is a host you control: it can carry a security group, double as a bastion, run an egress proxy that allow-lists destination domains, or log every connection. Teams with a hard egress-control requirement sometimes choose an instance-based path for exactly this reason — though at that point the honest framing is that they are building an egress firewall that happens to also do NAT, not saving money on NAT. **Operational burden.** The NAT instance is a Linux host in the traffic path of everything: it needs patching, hardening, monitoring, and an owner. A NAT gateway needs none of that. ## How to answer Say the default is the NAT gateway and give the two legitimate reasons to deviate — **cost at low volume**, and **capability you cannot get otherwise**. Then name the three things you have signed up for: patching, a bandwidth ceiling, and failover you have to build yourself. A candidate who claims the NAT instance is simply cheaper, with no mention of availability, is telling you they have never had one fail at 3am and take every private subnet's internet access with it. The third option worth mentioning is removing traffic from the NAT path altogether where the destination allows it, which is a different leaf's subject but the correct instinct: the cheapest NAT byte is the one that never traverses the NAT device.