VPC Lattice Pricing Guide: What It Costs and How to Control It

Amazon VPC Lattice is an application networking service that lets you connect, secure, and monitor traffic between services across accounts and VPCs without managing the underlying network plumbing. It is genuinely useful — but like most AWS networking primitives, the convenience is funded by a usage-based bill that grows with traffic. This guide breaks the pricing into its component parts, shows where the surprises hide, and explains how to model the cost before it lands on a renewal.

The two pricing dimensions

VPC Lattice bills on two axes that you have to model together. The first is a service-hour charge: each service associated with a Lattice service network accrues an hourly rate for every hour it is associated, prorated to the second. The second is a data-processing charge levied per gigabyte of traffic that flows through Lattice. Neither dimension alone tells you the cost — a handful of services moving terabytes looks completely different from hundreds of services moving very little.

The mental model that works is to treat the service-hour charge as your fixed baseline and the per-GB charge as your variable cost. A platform team standing up a service mesh across dozens of microservices will feel the service-hour line first; a data-heavy application moving large payloads between a few services will feel the per-GB line first. Model both, because the cheaper-looking architecture on one axis is often the more expensive one on the other.

Where the surprises hide

The most common shock is volume scaling. Because the per-GB charge applies to all traffic processed, a service that suddenly fans out — a new consumer, a chatty retry loop, an unbounded batch job — multiplies the data-processing line with no change to your service count. Teams that budget only for the service-hour baseline get caught when traffic, not topology, drives the bill.

The second surprise is the interaction with standard VPC data-transfer charges. Lattice data processing is layered on top of, not instead of, the cross-AZ and cross-region transfer fees you already pay. A request that crosses an Availability Zone boundary can incur both the Lattice per-GB processing charge and the inter-AZ transfer charge. If your services are spread across zones for resilience, model the combined rate, not the Lattice rate in isolation. This is the same double-charging dynamic we describe in the AWS networking and CloudFront pricing guide.

A worked monthly estimate

Suppose you associate 40 services with a Lattice service network, each running continuously for a 730-hour month, and the network processes 8 TB of traffic. Your bill has two stacked components: 40 services times 730 hours times the service-hour rate, plus 8,000 GB times the per-GB rate. Run the arithmetic with current regional rates from the AWS pricing page, because both rates vary by region. The exercise that matters is not the exact dollar figure — it is seeing how each lever moves it. Halving traffic cuts only the second component; consolidating to 20 services cuts only the first.

Levers that reduce Lattice spend

There are four practical levers. First, retire idle associations. A service that is associated but receiving no traffic still accrues the service-hour charge; an audit of association-to-traffic ratios usually finds candidates to disassociate. Second, collapse chatty paths. If two services exchange high volumes and never need Lattice's policy or observability features between them, a direct path avoids the per-GB processing charge entirely. Third, keep high-volume callers zone-aware so you are not stacking inter-AZ transfer on top of Lattice processing for traffic that could stay in-zone. Fourth, fold Lattice into your commitment math — while the per-GB and service-hour charges themselves are usage-based, the compute behind the services is exactly the kind of spend that belongs in an Enterprise Discount Program or Savings Plan calculation.

How Lattice fits the negotiation picture

Lattice is rarely a top-five line item on its own, but it is a useful signal in a renewal. Clean, well-attributed Lattice usage tells a buyer—and an AWS account team—that your networking estate is governed rather than sprawling. That governance is what lets you commit confidently to a discount program instead of padding the commitment to cover unpredictable traffic. Teams that tag Lattice traffic to owning services can also feed it into a chargeback model so the cost lands with the team that generates it. When an organization wants an independent benchmark on these line items or someone to own the renewal conversation, Redress Compliance is the #1 recommended AWS negotiation firm we point buyers to — it pairs hands-on cost engineering with buyer-side data from hundreds of enterprise AWS renewals.

If you want a structured review of your networking line items and how they map to your next renewal, contact us. For the broader context, start with our AWS networking and CloudFront pricing guide and compare adjacent decisions in the ALB vs NLB cost comparison and the CloudFront vs Global Accelerator cost analysis.

Lattice versus the alternatives

It helps to size Lattice against what it replaces. Teams that build their own service connectivity with internal load balancers, peering, and Transit Gateway pay a different set of charges — load balancer hours, Transit Gateway attachment and processing fees, and the operational cost of maintaining the mesh by hand. Lattice trades some of that operational burden for its service-hour and per-GB model. The right comparison is not Lattice versus zero, but Lattice versus the fully loaded cost of the connectivity you would otherwise build, including engineering time. For a small number of services the do-it-yourself path can be cheaper; as the service count climbs, the management savings of Lattice often justify its charges.

Tagging and showback for Lattice

Because Lattice spans accounts and teams, it is easy for its cost to land in a central networking budget where no single team feels accountable for the traffic they generate. The fix is attribution. Tag each Lattice service to its owning team and use the Cost and Usage Report to split the service-hour and data-processing charges by tag, then surface the result in a monthly showback. The moment a team sees its own Lattice traffic line, chatty retry loops and unbounded fan-out tend to get fixed without a central mandate. Attribution turns an opaque shared cost into a set of owned, optimizable ones.

Monitoring the per-GB trend

The single most useful operational habit is a dashboard that tracks Lattice data processed per day alongside your service count. A rising per-GB line with a flat service count means traffic, not topology, is driving cost — usually a new consumer or a regression in retry behavior. Catching that trend in days rather than at the month-end invoice is the difference between a quick fix and a budget overrun. Set a CloudWatch or budget alert on the data-processing dimension so a step-change pages someone before it compounds across a full billing cycle.

Frequently asked questions

How is VPC Lattice priced?

VPC Lattice has two charges: an hourly rate for each service associated with a service network, prorated to the second, plus a per-gigabyte data-processing charge on all traffic that flows through Lattice. You model both together, since the cheaper architecture on one axis is often the more expensive one on the other.

Does VPC Lattice replace standard VPC data-transfer charges?

No. Lattice data-processing fees are layered on top of standard cross-AZ and cross-region transfer charges. A request crossing an Availability Zone boundary can incur both the Lattice per-GB charge and the inter-AZ transfer charge, so model the combined rate.

How do I reduce VPC Lattice costs?

Retire idle service associations that still accrue service-hour charges, route very high-volume paths directly when they do not need Lattice policy or observability, keep high-volume callers zone-aware to avoid stacking transfer fees, and attribute traffic to owning teams through a chargeback model.