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

Start with a calculator if you need a first-pass estimate, then use this guide to validate the assumptions and catch the billing traps.

This page is the input-measurement workflow, not the bill-boundary page: the goal is to turn endpoint inventory, AZ coverage, hours, and GB into a defendable model.

If you still are not sure which charges belong inside the endpoint bill, go back to the pricing guide first.

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)

Evidence pack for a defendable endpoint-hours and GB model

• Inventory source: where the endpoint count came from, including per-VPC and per-environment duplication.
• AZ and hours source: which endpoints are always-on versus ephemeral, and how active hours were measured rather than assumed.
• GB source: NAT metrics, flow logs, or scenario logic used to decide what traffic actually moves to endpoints.
• Open uncertainty: any migration spikes, image pulls, backfills, or path changes still modeled loosely.

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.

What this page should hand off next

• Hand off to VPC endpoints pricing if your measurement work changes what you think belongs in the endpoint bill versus the transfer or NAT bill.
• Hand off to VPC endpoints cost optimization once the endpoint-hours and GB model is stable enough to judge before/after changes.
• Do not move into optimization with only guessed environment counts or guessed GB shifts if the main drivers are still unclear.

Related guides

Sources

• AWS PrivateLink pricing (interface endpoints)
• PrivateLink documentation

Related guides

Related calculators

FAQ