Estimate VPC endpoint cost inputs: endpoint-hours and GB processed

Most endpoint cost models require two inputs: endpoint-hours and GB processed. This guide shows quick ways to estimate both without perfect data.

1) Estimate endpoint-hours

  • Count how many distinct interface endpoints you plan to deploy.
  • Count how many AZs each endpoint will attach to (commonly 2 or 3).
  • Use 730 hours/month for always-on infrastructure (or adjust for partial months).

Endpoint-hours = endpoints x AZs per endpoint x hours/month.

  • For ephemeral environments, estimate active hours/month (for example: 8 hours/day * weekdays) rather than assuming a full month.
  • If you plan to deploy endpoints per VPC per environment, include that multiplier explicitly (prod + staging + dev).

2) Estimate GB processed

  • From NAT: identify which NAT traffic is actually AWS-service traffic that can move to endpoints (S3, ECR, STS, etc).
  • From flow logs: roll up bytes for the relevant destinations and convert to GB/month.
  • From scenarios: start with 30% / 60% / 90% of NAT GB processed as a sensitivity model.

The goal is not to be perfect on day one. Build scenarios and tighten the estimate once you have flow logs and a billing cycle.

Worked scenario example

  • Endpoint-hours: 6 endpoints * 3 AZ * 730 hours/month = 13,140 endpoint-hours/month
  • GB processed: 4 TB/month AWS-service traffic moving off NAT into endpoints (model low/medium/high)

3) Turn inputs into cost

Use VPC Interface Endpoint Cost Calculator for endpoint-hours + per-GB processing, and compare against NAT Gateway cost.

  • Save a baseline scenario (NAT-heavy) and an endpoint scenario (endpoints + reduced NAT GB).
  • Do not forget transfer: endpoint decisions can change cross-AZ paths and create transfer line items.

Common pitfalls

  • Counting endpoints but forgetting the AZ multiplier (interface endpoints are per AZ).
  • Assuming 100% of NAT traffic moves to endpoints (many destinations remain public internet).
  • Not separating one-time spikes (image pulls, migrations) from steady-state traffic.
  • Missing cross-AZ effects when clients route to endpoints in other AZs.

How to validate the estimate

  • Compare endpoint-hours in billing to endpoints * AZs * hours. Large gaps usually mean inventory mistakes.
  • Use flow logs to validate the GB processed order of magnitude and the top destinations.
  • After rollout, reconcile NAT GB processed and endpoint GB processed as a before/after.

Related guides

Sources


Related guides


Related calculators


FAQ

How do I count endpoint-hours quickly?
Endpoint-hours are approximately endpoints x AZs per endpoint x hours/month. If you run 3 endpoints across 3 AZs for a full month, that's roughly 3 x 3 x 730 endpoint-hours.
Where do I get GB processed for endpoints?
Use flow logs, endpoint/traffic metrics, or estimate from the traffic you currently send through NAT to AWS services and model how much will shift to endpoints.
What if I don't know yet?
Build scenarios. Model low/medium/high traffic (GB/month) and 2-AZ vs 3-AZ deployments. The goal is to avoid under-budgeting and find the NAT break-even point.

Last updated: 2026-01-27