{{ summaryHeading }}
{{ summaryPrimary }}
{{ summaryLine }}
{{ badge.label }}
SUBNETS NAT INTERNET ENDPOINTS {{ visualTrafficLabel }}
Choose the NAT gateway rate card that most closely matches the billing line you are modeling.
{{ activePreset.unitHelp }}
{{ activePreset.unitLabel }}
{{ hours_per_month }} h
Use 730 for an always-on month or lower it to model scheduled dev/test cleanup.
hours/mo
Use billing export bytes, NAT gateway metrics, flow logs, or a workload estimate before offload.
Use gateway/private access for S3, DynamoDB, or private provider paths; use interface endpoint when endpoints add hourly and per-GB cost.
{{ endpoint_offload_percent }}%
This reduces NAT-processed GB and may add endpoint substitute cost depending on the selected model.
%
{{ internet_egress_percent }}%
Set lower when most traffic stays in provider services or private networks; set higher for outbound internet APIs, downloads, and package mirrors.
%
{{ cross_az_percent }}%
Cross-AZ transfer can add a second per-GB line on top of NAT processing and internet egress.
%
Set 0 when public IPv4 cost is not part of this NAT estimate or is covered elsewhere.
addresses
Enter 0 to skip the budget-pressure check.
$ / mo
Editing a rate switches the rate card to Custom.
$ / unit-hour
This is separate from internet data-transfer-out and cross-AZ transfer lines.
$ / GB
Set 0 when internet egress is already modeled by another tool or bill line.
$ / GB
Use the provider's same-region inter-AZ data transfer rate.
$ / GB
The default models request plus return traffic for a cross-AZ NAT hairpin.
directions
Set 0 when public IPv4 is bundled or omitted.
$ / IP-hour
Gateway endpoints and free private access normally stay at 0.
units
Used only for offloaded traffic substitute cost.
$ / unit-hour
Set 0 for gateway endpoints or private paths without per-GB processing charges.
$ / GB
Used only in the optimization plan as a comparison, not in the monthly NAT total.
$ / mo
MetricValuePlanning noteCopy
{{ row.metric }} {{ row.value }} {{ row.note }}
FlowMonthly volumeCost basisMonthly costCopy
{{ row.flow }} {{ row.volume }} {{ row.basis }} {{ row.cost }}
LeverModeled changeMonthly impactOperator noteCopy
{{ row.lever }} {{ row.change }} {{ row.impact }} {{ row.note }}
PresetMonthly costDeltaEffective NAT rateCaveatCopy
{{ row.preset }} {{ row.cost }} {{ row.delta }} {{ row.rate }} {{ row.caveat }}
Tags: Cloud, Finance
API Gateway Cost Calculator Estimate API Gateway monthly spend across HTTP, REST, Private REST, and WebSocket traffic with request chunks, transfer, cache, and budget checks.
Cloud Egress Cost Calculator Estimate cloud data transfer spend from monthly volume, cache savings, tiered rates, request add-ons, peak months, and budget variance.
AWS Lambda Cost Calculator Estimate AWS Lambda monthly cost from requests, billed duration, memory, provisioned windows, streaming overage, free tier, and editable rates.
Object Storage Cost Calculator Estimate monthly object storage cost from average capacity, object size, requests, retrieval, egress, lifecycle exposure, and editable rate cards.
Customize
Advanced
:

Private cloud workloads often need outbound access without accepting inbound internet traffic. Managed network address translation, usually shortened to NAT, supplies that path by letting instances, containers, or services in private subnets start connections to package mirrors, external APIs, SaaS endpoints, update servers, and public cloud services. The routing pattern is simple to draw, but the bill is rarely a single line.

A NAT gateway estimate has to separate the traffic path from the pricing path. One line may charge for provisioned gateway hours. Another may charge for each gigabyte processed by NAT. Internet data transfer can be billed separately from NAT processing, and cross-zone routing can add transfer charges when private workloads hairpin through a NAT resource in another availability zone. Public IPv4 addresses and paid endpoint substitutes can also appear as separate monthly costs.

NAT unit
The billable gateway, active zone, assigned VM count, or custom unit used for the hourly part of the estimate.
Processed data
The raw traffic volume that would traverse NAT before endpoint, private access, proxy, or other bypass choices are modeled.
Endpoint offload
The share of traffic moved away from NAT by gateway endpoints, private service access, interface endpoints, package mirrors, or a controlled proxy path.
Cross-AZ hairpin
Traffic that crosses an availability-zone boundary on the way to or from NAT, which can add cost and complicate failure-domain design.
Private subnets NAT Internet Endpoint offload Costs change when traffic stays on NAT, exits the cloud, crosses zones, or bypasses NAT.

The largest NAT line depends on workload shape. A lightly used development network can be dominated by always-on gateway hours. A build farm, data movement job, crawler, or image-processing job can be dominated by processed gigabytes. A multi-zone production network can waste money when every zone sends traffic through one central NAT gateway. A workload that mostly talks to cloud storage, container registries, logging services, or internal APIs may be better served by private endpoints or private access.

Cost mistakes often start with averaging too much. A single blended dollar-per-gigabyte number hides whether the next fix should be scheduling idle gateways, adding endpoint routes, removing cross-zone hairpin paths, reducing internet egress, or replacing public IPv4 addresses. Billing exports, NAT metrics, flow logs, route tables, destination tags, and subnet ownership are usually needed before a design change can be trusted.

Cloud rate cards also use different units. AWS-style NAT pricing can be hourly per gateway or per configured availability zone, Azure-style NAT pricing combines resource hours with data processed and bandwidth, and Google Cloud NAT hourly pricing depends on assigned VM counts. Region, currency, taxes, data-transfer tiers, credits, committed-use terms, and private contracts can all move the final bill away from a planning estimate.

How to Use This Tool:

Model the NAT path you are actually paying for, then compare the estimate against the traffic and routing evidence you have. Start with a preset only when its units and region are close enough for planning.

  1. Choose Pricing preset or Custom. The preset fills editable NAT hourly, processing, internet egress, cross-zone, and public IPv4 rates.
  2. Enter Billable NAT units and Monthly active hours. Use 730 for an always-on month, or lower the hours when modeling scheduled dev/test cleanup.
  3. Enter Monthly processed data in GB, TB, TiB, PB, or PiB. Use the traffic that would traverse NAT before endpoint or private-path offload.
  4. Select Endpoint offload model, then set Endpoint/private-path offload, Internet-bound share, and Cross-AZ hairpin share.
  5. Set Public IPv4 addresses and an optional Monthly budget cap. Open Advanced when you need custom endpoint costs, charged cross-zone directions, or a self-managed comparator.
  6. Fix any Check NAT assumptions alert before trusting the result. Active hours must stay from 0 to 744, endpoint offload from 0% to 95%, traffic shares from 0% to 100%, and rates cannot be negative.
  7. Read Spend Breakdown first, then use Traffic Ledger and Optimization Plan to see which lever changed the estimate. Use Provider Comparison, NAT Cost Curve, and Cost Driver Map for sensitivity checks, and JSON when you need a structured copy.

Interpreting Results:

The monthly total is a planning estimate assembled from separate cost drivers. If gateway hours dominate, reducing active hours or consolidating idle non-production paths may save more than traffic tuning. If NAT data processing dominates, endpoint offload, private service routes, package mirrors, or fewer outbound dependencies are the first places to inspect. If internet egress dominates, NAT is only one part of the outbound bill and the destination mix needs review.

Cross-zone exposure should be read as both a cost clue and a topology clue. A central NAT path can be cheaper in hourly charges but more expensive in transfer and resiliency. One NAT resource per zone can raise the hourly baseline while removing hairpin traffic, so the optimization rows compare those pressures instead of assuming one topology is always better.

Signal Read it as Check next
Budget pressure The modeled monthly total exceeds the entered budget cap. Inspect the largest Spend Breakdown row before changing architecture.
High blended rate Fixed hourly or IPv4 cost is large compared with raw traffic volume. Check active hours, NAT unit count, and whether the path is idle most of the month.
Large endpoint savings A meaningful share of raw traffic can bypass NAT processing. Validate destination services and endpoint substitute costs before changing routes.
Cross-AZ savings above one extra NAT unit Hairpin transfer costs may justify zone-local NAT or route realignment. Compare the transfer line with the added gateway-hour baseline and failure-domain design.

A result under budget is not a quote. Verify current provider prices, billing-account currency, destination-specific data transfer, taxes, credits, and private agreements before using the number for a purchase order or architecture approval.

Technical Details:

NAT cost modeling starts with a traffic conservation step. Raw NAT-bound traffic is converted to gigabytes, endpoint offload removes a bounded percentage, and the remaining traffic becomes the NAT-processed volume. Internet egress and cross-zone exposure are calculated from that remaining volume because the offloaded share is assumed to bypass the modeled NAT path.

The hourly side is independent of traffic. A provisioned NAT resource can cost money even when almost no data passes through it, and public IPv4 addresses can add an hourly line of their own. Endpoint substitutes are kept separate because they can reduce NAT processing while adding their own hourly or per-GB costs.

Formula Core:

The core equation combines fixed gateway runtime, variable traffic charges, cross-zone transfer, public IPv4, and endpoint substitute cost.

O = G×p N = G-O T = (u×h×r_h)+(N×r_n)+(N×e×r_e)+(N×z×r_z×d)+(a×h×r_a)+C_endpoint C_endpoint = (c×h×r_c)+(O×r_o)

Here G is raw NAT-bound traffic in GB, O is offloaded GB, p is endpoint offload share, N is NAT-processed GB, u is billable NAT units, h is active hours, e is internet-bound share, z is cross-zone share, d is charged cross-zone directions, a is public IPv4 address count, and T is monthly total.

Input or driver Rule Why it matters
Traffic units TB and PB use decimal 1,000-based conversion; TiB and PiB use binary 1,024-based conversion. Billing exports and monitoring systems may not use the same unit family.
Monthly active hours Accepted from 0 to 744 hours. Runtime cost can dominate low-traffic NAT paths.
Endpoint offload Accepted from 0% to 95%. The remaining NAT path is still modeled instead of allowing a complete bypass assumption.
Internet and cross-zone shares Each share is accepted from 0% to 100% of NAT-processed traffic. The same processed traffic can carry more than one billing category.
Cross-zone charged directions Accepted from 0 to 2. Some paths charge one direction, both directions, or no extra cross-zone transfer.
Rates and comparator costs Negative values are rejected. Custom rate cards should represent actual bill lines, credits excluded unless entered deliberately.

With the default AWS US East-style scenario, 12 TB is converted to 12,000 GB. A 25% offload removes 3,000 GB and leaves 9,000 GB through NAT. The 70% internet share applies to 6,300 GB, and the 20% cross-zone share applies to 1,800 GB. Three NAT units running 730 hours at $0.045 per hour add $98.55 before traffic charges, and three public IPv4 addresses at $0.005 per hour add $10.95.

The effective rate divides the complete monthly total by raw traffic, not by NAT-processed traffic. That makes small but always-on environments look expensive per GB, which is usually correct for budget analysis because the fixed gateway and address hours still belong to the workload.

Accuracy and Pricing Notes:

Preset rates are editable planning values, not live quotes. Provider pages can change, regional rates can differ, and account-level discounts or commitments can change the bill. Use current provider pricing pages, billing exports, Cost Explorer or cost-management reports, route tables, flow logs, and service metrics when the estimate will drive a production change.

The model does not know destination-specific egress tiers, tax, marketplace charges, support-plan effects, logging charges, traffic inspection fees, transit gateway fees, firewall licensing, or operational labor unless you add those costs through custom fields or a separate comparison. It also does not prove that endpoint offload is safe for a workload; route, DNS, IAM, service endpoint, and application behavior still need validation.

The arithmetic runs in the browser and does not require a server lookup. Copied JSON, downloaded files, or a shared page address can still carry entered assumptions if you choose to share them.

Advanced Tips:

  • Set Endpoint/private-path offload to 0% once to see the no-offload baseline before arguing for endpoint work.
  • Compare Cross-AZ hairpin share at the measured value and at 0% to see whether route alignment beats adding another NAT unit.
  • Use 240 active hours for a work-hours-only development path and 730 hours for an always-on monthly baseline.
  • Switch to Custom as soon as a real billing export gives you account-specific NAT, bandwidth, IPv4, or endpoint rates.
  • Use Provider Comparison as sensitivity analysis only; it applies preset rates to the same traffic shape and does not migrate architecture or contracts.
  • Keep the budget cap in the model even when the result is under budget, because the variance makes later traffic-growth checks easier.

Worked Examples:

Default multi-zone AWS-style plan

Using the default AWS US East-style rates, 12 TB of raw traffic, 25% endpoint offload, 70% internet-bound traffic, and 20% cross-zone hairpin traffic produces 9,000 GB through NAT. The modeled total is about $1,117.50 per month, or about $682.50 under an $1,800 budget cap.

Offload sensitivity check

With the same traffic and rates but no endpoint offload, all 12,000 GB remain on the NAT path and the total rises to about $1,453.50. Raising offload from 25% to 40% lowers NAT-processed traffic to 7,200 GB and moves the estimate to about $915.90 before any paid endpoint substitute cost is added.

Cross-zone route review

At the default 20% hairpin share and two charged directions, the cross-zone line is $36.00 per month. One extra NAT unit at $0.045 for 730 hours is $32.85 before any other changes, so the route design deserves review instead of assuming central NAT is cheaper.

FAQ:

Why can NAT cost stay high after endpoint offload?

Endpoint offload reduces NAT-processed traffic, but hourly gateway cost, public IPv4 addresses, remaining internet egress, cross-zone transfer, and paid endpoint substitute costs can still be material.

Should internet egress be included in a NAT estimate?

Include it when the NAT path carries outbound internet traffic and you want a workload-level estimate. Set Internet-bound share lower when most traffic stays on private provider paths or internal services.

What does the Check NAT assumptions alert mean?

The alert means at least one value is outside the accepted planning range, such as negative traffic, endpoint offload above 95%, active hours above 744, a share above 100%, or a negative rate. Fix the named field before using the result.

Why compare a self-managed NAT or proxy cost?

A self-managed path can look cheaper on a bill line, but it adds availability, patching, scaling, monitoring, security, and incident-response work. Treat the comparison as a prompt for deeper review, not an automatic recommendation.

What evidence should be gathered before changing routes?

Use billing exports, NAT metrics, flow logs, route tables, service destinations, subnet placement, and workload ownership tags. Destination and zone grouping make the optimization rows much more useful.

Glossary:

NAT gateway
A managed outbound translation path for private workloads that need to start connections outside their private subnet.
Billable NAT unit
The hourly unit used by the selected pricing model, such as gateway count, active zones, assigned VM count, or a custom unit.
Processed data
Traffic volume charged by the NAT data-processing rate after offload is removed.
Endpoint offload
Traffic moved from NAT to private endpoints, private access, gateway endpoints, proxies, or equivalent private paths.
Cross-AZ hairpin
Traffic that crosses an availability-zone boundary to reach or return from NAT.
Effective rate
The complete monthly estimate divided by the original raw NAT-bound traffic volume.

References: