Cut AgentCore NAT Gateway Costs in 2026: An Egress Architecture Playbook
Your agent needs the internet but the NAT gateway bills a flat $33 a month while it idles. Here is the architect's decision tree: which traffic to move to VPC endpoints, when a NAT instance beats a managed NAT, and how to size egress so you only pay for the public access you actually use.
Cut AgentCore NAT Gateway Costs in 2026: An Egress Architecture Playbook
In my last article I mapped the AgentCore bill line by line and found the surprise: a NAT gateway charging about $33 a month while the agent sits idle, two-thirds of a small dev bill spent on a gateway that bills at 3 AM on a Sunday when nobody is talking to the agent.
A reader asked the exact right follow-up:
How would you approach optimizing the architecture when NAT costs are high but the agent still needs external internet access?
That is the real question, because "just delete the NAT" is useless advice if your agent genuinely has to reach a third-party API. So this is the sequel: the architecture playbook for keeping an agent connected to the outside world without paying a flat idle tax for the privilege.
The short version: most of what you think needs the NAT does not. The trick is to sort your egress into three buckets and route each one to the cheapest path that still reaches it. Let me show you the buckets, the real numbers, and the decision tree I actually use.
First, know what the NAT is really charging you for
A managed NAT gateway in us-east-1 bills two ways (AWS VPC pricing, October 2026):
- $0.045 per hour, which is the fixed part. $0.045 times 730 hours is $32.85 a month, and it accrues whether or not a single byte flows. This is the idle tax from article one.
- $0.045 per GB processed, the variable part, on top of normal data transfer out.
So there are two separate problems hiding in one line item. The hourly charge punishes you for existing. The per-GB charge punishes you for volume. A good architecture attacks both, and they have different fixes.
Keep that split in your head, because every option below is really a bet on one of those two numbers.
Sort your egress into three buckets
Open your agent and list every external endpoint it actually talks to. Then drop each one into a bucket. This sorting is the whole exercise. Once traffic is bucketed, the right path is obvious.
Bucket 1: AWS services (S3, DynamoDB, Bedrock, Secrets Manager, CloudWatch).
This is the biggest surprise for most people. An AgentCore agent's heaviest "external" traffic, the model calls themselves, is traffic to Bedrock, and Bedrock is an AWS service. It never needs to leave the AWS network, so it never needs the NAT.
This is the biggest surprise for most people. An AgentCore agent's heaviest "external" traffic, the model calls themselves, is traffic to Bedrock, and Bedrock is an AWS service. It never needs to leave the AWS network, so it never needs the NAT.
Bucket 2: Private or SaaS endpoints that support PrivateLink (MongoDB Atlas, Datadog, Snowflake, a partner's VPC service).
Many managed providers publish an AWS PrivateLink endpoint service. If yours does, that traffic can also skip the public internet.
Many managed providers publish an AWS PrivateLink endpoint service. If yours does, that traffic can also skip the public internet.
Bucket 3: Genuinely public, non-AWS endpoints (a third-party REST API, a webhook, a scraping target, an on-prem system exposed over the internet).
This is the only bucket that truly needs a route to the public internet. And it is almost always smaller than people assume.
This is the only bucket that truly needs a route to the public internet. And it is almost always smaller than people assume.
The mistake I see is treating all three buckets as bucket 3 and provisioning one NAT to carry everything. You are then paying the idle tax to move traffic that never had to touch the internet in the first place.
Bucket 1: send AWS traffic through VPC endpoints, not the NAT
AWS traffic has two endpoint types, and the price difference between them matters.
Gateway endpoints (S3 and DynamoDB only). These are the free lunch. No hourly charge, no data-processing charge. You add a gateway endpoint, point your subnet route table at it, and S3 and DynamoDB traffic bypasses the NAT at zero added cost. If your agent reads prompts, documents, or state from S3, this alone can cut a big slice of NAT data processing to nothing. There is no scenario where you should route S3 traffic through a NAT in the same Region. Use the gateway endpoint.
Interface endpoints, powered by PrivateLink (Bedrock, AgentCore, Secrets Manager, almost every other AWS service). These are not free, but they are cheap and, crucially, they bypass the NAT. The rate in us-east-1 (verified from AWS VPC pricing, October 2026):
- $0.01 per hour, per endpoint, per Availability Zone
- $0.01 per GB processed
And here is the detail that caught the commenters on the first article, and that you have to get right: the hourly charge is per AZ. An interface endpoint spread across three AZs is three meters running. $0.01 times 730 hours times 3 AZs is about $21.90 a month for one endpoint, before data. Wire up four AWS services that way across three AZs and you have quietly rebuilt the $33 you were trying to remove, plus you still have the NAT.
So interface endpoints are not automatically cheaper than the NAT. They win under specific conditions. The honest comparison is below.
Worth knowing for AgentCore specifically: AgentCore Runtime and Gateway both support interface VPC endpoints. The AWS docs are explicit that with PrivateLink you reach AgentCore "without the use of an internet gateway, NAT device, VPN connection," and instances "don't need public IP addresses." So the agent's own control-plane and the model traffic can run entirely private. That removes the single biggest reason people assume they need a NAT at all.
The comparison nobody runs: endpoint vs NAT, by AZ count
Here is the math that decides it, using the verified us-east-1 rates. Fixed monthly cost only (ignore data for a second, since both charge roughly $0.01 to $0.045 per GB and volume is the same either way).
────────────────────────────────┬──────────────────
Option │ Fixed $/month
────────────────────────────────┼──────────────────
1 NAT gateway (1 AZ) │ ~$33
1 interface endpoint, 1 AZ │ ~$7.30
1 interface endpoint, 3 AZ │ ~$21.90
3 interface endpoints, 1 AZ │ ~$21.90
3 interface endpoints, 3 AZ │ ~$65.70
────────────────────────────────┴──────────────────
Option │ Fixed $/month
────────────────────────────────┼──────────────────
1 NAT gateway (1 AZ) │ ~$33
1 interface endpoint, 1 AZ │ ~$7.30
1 interface endpoint, 3 AZ │ ~$21.90
3 interface endpoints, 1 AZ │ ~$21.90
3 interface endpoints, 3 AZ │ ~$65.70
────────────────────────────────┴──────────────────
Read the bottom row twice. Three AWS services across three AZs on interface endpoints costs about $66 a month fixed, double the NAT you were trying to avoid. The endpoint swap is not a free win. It is a win in exactly two shapes:
- Few endpoints, few AZs. One or two services, pinned to a single AZ on a dev account: endpoints crush the NAT ($7 to $15 versus $33).
- High data volume. Even with more endpoints, if you move serious GB, the NAT's $0.045/GB versus the endpoint's $0.01/GB on the variable side tips the total toward endpoints regardless of the fixed cost.
Where the NAT still wins on fixed cost is the messy middle: many AWS services, spread across three AZs for high availability, at low data volume. In that exact shape, one NAT carrying everything can be cheaper than a wall of per-AZ endpoints. This is the case the "always use endpoints" advice gets wrong.
My rule: put S3 and DynamoDB on free gateway endpoints always. Then add interface endpoints only for the AWS services that carry real traffic, and on a dev account pin them to a single AZ. Do not reflexively spread every endpoint across three AZs on an account that serves ten requests a day.
Bucket 2: ask your SaaS providers for PrivateLink
For managed third parties, check whether they publish a PrivateLink endpoint service. Many of the big data and observability vendors do. If they do, you connect to their endpoint service the same way you connect to an AWS one, and that traffic leaves the NAT's bill and stops traversing the public internet, which is a security win on top of the cost one.
If a provider only offers VPC peering, that is also a NAT-free path, though it is a heavier setup and widens your network trust boundary, so weigh it.
If the provider offers neither, that endpoint falls into bucket 3.
Bucket 3: the traffic that truly needs the internet
This is the honest part. AWS's own guidance is blunt about it: if your workload must reach public IP addresses outside AWS that do not support private connectivity, "the traffic from the private subnets must route through the NAT gateway, and the associated data processing costs are unavoidable."
So for genuine public egress, you are keeping a route to the internet. The optimization is no longer "remove it," it is "make it cheap and make it tight." Three moves:
1. Shrink the hourly cost with a NAT instance if volume is low.
A managed NAT gateway's convenience costs you that flat ~$33 a month. For a low-traffic dev or internal agent, a NAT instance, a small EC2 running NAT yourself, can be dramatically cheaper. A
A managed NAT gateway's convenience costs you that flat ~$33 a month. For a low-traffic dev or internal agent, a NAT instance, a small EC2 running NAT yourself, can be dramatically cheaper. A
t4g.nano or t4g.micro runs a few dollars a month versus $33, and for an agent pushing a trickle of API calls that is often all you need. The trade is real and you should say it out loud: a NAT instance is your responsibility to patch, monitor, and make highly available, and a single instance is a single point of failure. For production, the managed NAT gateway's resilience usually earns its price. For a dev account or a tolerant internal workload, the NAT instance is the honest cost-optimized choice. Pick deliberately, do not cargo-cult either one.2. Shrink the per-GB cost by moving fewer bytes.
The variable charge is $0.045 per GB in and out. So compress responses, request only the fields you need, and cache anything you fetch more than once. An agent that re-pulls the same third-party reference data on every task is paying the NAT to move identical bytes repeatedly. A small local cache turns that into one fetch. This also helps the model bill, since less fetched junk means less context to tokenize.
The variable charge is $0.045 per GB in and out. So compress responses, request only the fields you need, and cache anything you fetch more than once. An agent that re-pulls the same third-party reference data on every task is paying the NAT to move identical bytes repeatedly. A small local cache turns that into one fetch. This also helps the model bill, since less fetched junk means less context to tokenize.
3. Centralize egress if you run many agents.
One NAT per VPC does not scale. If you are running several agent stacks, put a single NAT gateway in a shared egress VPC and route the spokes to it through Transit Gateway or Cloud WAN. You pay for one NAT instead of five. The caveat from the AWS whitepaper is worth repeating: Transit Gateway adds its own per-GB data-processing charge, so for a single very high-volume VPC, keeping the NAT local can still be cheaper. Centralization is a fleet optimization, not a single-agent one.
One NAT per VPC does not scale. If you are running several agent stacks, put a single NAT gateway in a shared egress VPC and route the spokes to it through Transit Gateway or Cloud WAN. You pay for one NAT instead of five. The caveat from the AWS whitepaper is worth repeating: Transit Gateway adds its own per-GB data-processing charge, so for a single very high-volume VPC, keeping the NAT local can still be cheaper. Centralization is a fleet optimization, not a single-agent one.
The decision tree I actually use
Put it together and the architecture falls out of a few questions, asked per endpoint:
- Is it S3 or DynamoDB in the same Region? Gateway endpoint. Free. Done.
- Is it another AWS service (Bedrock, AgentCore, Secrets Manager)? Interface endpoint. Pin to one AZ on dev, spread on prod only if you need the HA. Compare the per-AZ total against the NAT before you fan it out.
- Is it a SaaS provider with PrivateLink or peering? Use it. Off the NAT, off the public internet.
- Is it a genuinely public non-AWS endpoint? This is the only traffic that keeps a route to the internet. On dev or low volume, consider a NAT instance over a managed NAT. Compress and cache to cut the per-GB charge. Centralize across a fleet with a shared egress VPC.
After this sorting, a surprising number of agents land on: gateway endpoints for storage, one or two interface endpoints for AWS services, and no NAT at all, because nothing was left in bucket 3. That is the best outcome. The cheapest NAT gateway is the one you proved you did not need.
A pre-deploy egress checklist
Before an AgentCore agent goes to production, I want these answered:
- [ ] Every external endpoint the agent calls is listed and sorted into AWS service, PrivateLink-capable SaaS, or genuinely public.
- [ ] S3 and DynamoDB traffic rides free gateway endpoints, never the NAT.
- [ ] AWS-service interface endpoints are priced per AZ and compared against the NAT before being spread across three AZs; dev is pinned to one AZ.
- [ ] SaaS providers were checked for a PrivateLink endpoint service.
- [ ] If bucket 3 is empty, there is no NAT at all.
- [ ] If a NAT is required, dev and low-volume stacks evaluated a NAT instance against the managed gateway, with the HA trade stated.
- [ ] Public-egress payloads are compressed and repeat fetches are cached.
- [ ] A fleet of agents routes through one centralized egress VPC, with the Transit Gateway data charge accounted for.
- [ ] A teardown exists so dev NATs and endpoints do not bill after everyone goes home.
The takeaway
The reader's question had a hidden assumption worth challenging: that the agent needing "external internet access" means it needs a NAT. Most of the time it does not. The model calls are AWS traffic. The storage is AWS traffic. A good chunk of the SaaS tier supports private connectivity. What is actually left for the public internet is usually a thin slice, and that slice is the only thing a NAT should carry.
So the optimization is not a clever trick to make a NAT cheaper. It is the discipline to route each kind of traffic to the path built for it, and to only pay for public egress on the bytes that are genuinely public. Do that, and the $33 idle tax from the first article either shrinks to the price of a couple of interface endpoints, or disappears entirely because you proved the NAT was carrying traffic that never needed it.
Price the model first, as the last article argued. Then route the egress deliberately. That is most of AgentCore network cost engineering, and none of it is exotic.
What is the trickiest egress case you have hit, the third-party endpoint that would not support PrivateLink and forced you to keep a NAT? Those are the ones worth comparing notes on.
Sources: AWS VPC pricing and AWS PrivateLink pricing (us-east-1, October 2026, verified via the AWS Price List API); AWS re:Post, "How do I reduce data transfer charges for my NAT gateway" and "How can I optimize NAT gateway usage"; the AWS whitepaper "Building a Scalable and Secure Multi-VPC Network Infrastructure" (centralized egress); and the Amazon Bedrock AgentCore developer guide on interface VPC endpoints and VPC configuration. Builds on my earlier article, "Amazon Bedrock AgentCore Pricing: Hidden Costs That Bill While Your Agent Idles."
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article