{{ 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 costs across HTTP, REST, Private REST, and WebSocket APIs with traffic tiers, payload chunks, transfer, cache, and budget checks.
Cloud Egress Cost Calculator Estimate monthly cloud egress cost from transfer volume, cache savings, payload reduction, provider-style tiers, peak months, and budget checks.
AWS Lambda Cost Calculator Estimate AWS Lambda monthly cost from requests, billed duration, memory, architecture, free-tier use, provisioned concurrency, and editable rates.
Object Storage Cost Calculator Estimate object storage spend from data volume, object size, request counts, retrieval, egress, lifecycle moves, replication, and editable rate cards.
Customize
Advanced
:

Cloud NAT gateway cost is shaped by architecture as much as by the published rate card. A private subnet that sends updates, package downloads, telemetry, API calls, or application traffic through managed NAT can incur hourly gateway charges, data-processing charges, internet egress charges, public IPv4 charges, and sometimes cross-zone transfer charges. Those line items can grow quietly because NAT is often treated as plumbing rather than a workload cost center.

The main planning question is how much traffic truly needs to pass through NAT. Some destinations may be better served by private endpoints, gateway endpoints, direct private paths, service connectors, or workload changes that reduce outbound internet dependence. Other traffic must still pass through NAT for security, routing, or vendor-access reasons. A useful model keeps the original traffic demand visible, then separates offloaded traffic from traffic that remains NAT-processed.

This calculation is intended for cloud engineers, FinOps teams, platform owners, and application teams reviewing NAT gateway spend before a migration, after a bill spike, or during subnet design. It gives a monthly view of the cost drivers so teams can compare zonal deployment, regional assumptions, endpoint offload, cross-zone routing, public IPv4 exposure, and self-managed alternatives using one consistent set of assumptions.

What It Answers:

  • How much monthly spend comes from NAT hourly charges, processed data, internet egress, cross-zone routing, public IPv4 addresses, and endpoint substitutes.
  • How endpoint or private-path offload changes the amount of data processed by NAT.
  • Whether a modeled scenario stays under a monthly budget cap.
  • How provider-style rate cards compare when applied to the same workload volume.

Input Model:

The workload begins with monthly outbound data volume and active hours. NAT units represent gateways, regional resources, or equivalent managed NAT constructs that accrue hourly cost. Endpoint offload removes a percentage of data from the NAT-processed path and applies endpoint substitute rates when relevant. The remaining data can then be split into internet-bound share and cross-zone hairpin share.

The model keeps rate-card fields editable because provider prices vary by region, service type, contract, currency, and architecture. Presets are useful starting points, but the final planning run should use the exact rates that apply to the account, region, and destination mix. Public IPv4 charges are modeled separately because they can be tied to addresses used by NAT or adjacent network components.

Cost driver Modeled from Optimization question
NAT hourly NAT units x active hours x hourly rate Are all deployed gateways needed for the hours modeled?
Data processing NAT-processed GB x processing rate Can private service paths remove common destinations?
Internet egress Internet-bound GB x egress rate Which traffic actually exits to the internet?
Cross-zone transfer Hairpin GB x zone-transfer rate x charged directions Can subnets and NAT placement reduce zone crossing?

Interpreting the Results:

The spend breakdown shows which line item dominates the monthly estimate. If hourly charges dominate, consolidation, scheduling, or architecture simplification may matter more than data reduction. If processed-data charges dominate, endpoint offload and reducing outbound dependencies can have the largest impact. If internet egress dominates, the NAT layer is only one part of the cost story and the destination mix should be reviewed.

Cross-zone costs deserve special attention because they can be caused by subnet placement or routing choices rather than user-visible traffic growth. A design that sends private-subnet traffic across zones to reach a NAT resource may create avoidable transfer charges and resilience concerns. The provider comparison should be read as a normalized scenario test, not as a quote, because real bills depend on region, tiering, taxes, credits, committed-use terms, and service-specific rules.

Technical Details:

The model converts the selected data unit to gigabytes, applies the endpoint offload rate, and then calculates remaining NAT-processed traffic. Each cost line is then calculated independently so the result can identify which assumption is responsible for the total.

NAT_processed_GB = raw_GB x (1-offload_rate)
NAT_core_cost = unitsxhoursxhourly_rate + NAT_processed_GBxprocessing_rate
monthly_total = NAT_core_cost + internet_egress_cost + cross_zone_cost + IPv4_cost + endpoint_substitute_cost

Practical Checks:

  • Use billing export data or flow logs to estimate real NAT-processed volume before committing to an optimization plan.
  • Separate service-to-service traffic from true internet-bound traffic; the optimization path is different for each group.
  • Verify whether cross-zone data transfer is charged in one or two directions for the provider and path being modeled.
  • Recalculate after endpoint changes, subnet placement changes, or application dependency changes, because NAT spend can move quickly with architecture.

References: