Cost, Overrides, and Where Service Meshes Are Heading

The layer from part 101 is not free, and the honest number is easy to miss until it lands in a bill. Direct invoke looked free because nothing sat between the two functions. Putting a gateway there has a per-call price, and this part states it plainly, then says when it is worth paying and when it is not.

The second half zooms out. It would be easy to read this whole series as a serverless workaround: no mesh available, so improvise. That reading is backwards. AWS is switching off its own service mesh in September 2026, and the open-source meshes are moving the same way, off the per-workload proxy and into the platform. This layer is not a detour around the industry. It is where the industry is going, arrived at from the other side.

What the layer costs

Prices below are us-east-1 list rates, read on 2026-07-14. Re-run them against your own Region before you commit.

Component	Rate	Source
Private REST API requests	$3.50 per million (first 333M/month)	API Gateway pricing
Interface VPC endpoint	$0.01 per endpoint per AZ-hour	PrivateLink pricing
PrivateLink data processing	$0.01 per GB (first PB/month)	PrivateLink pricing

The fixed part is small and shared. One endpoint across two AZs runs about $14.60 per month (2 x $0.01 x 730 hours), and that one endpoint serves every private API in the VPC. Partial endpoint-hours bill as full hours, so the floor is real but flat.

The variable part is the honest tax. REST is the most expensive API Gateway tier, and it is the only tier that can be private. There is no escape to the cheaper HTTP API rate. At 50 million internal calls per month across the whole estate you are paying roughly $175 per month for plumbing that used to appear free. State that number to your team before someone finds it in a bill. Note the shape of that example: 50 million spread over a dozen services is a different bill from 50 million through one service, and the next section is about why.

It is worth paying when the calls are a contract boundary between teams. The $175 buys a throttle the callee sets on its own route, request validation against a schema, an exportable contract, and per-route latency and error metrics. It does not buy per-route authorization, because as the next section shows, the alternative has that too. It is not worth paying inside a single service’s own boundary. Two Lambdas owned by the same team, deployed by the same pipeline, with no independent consumer, should keep calling each other directly. Better still, they should stop being two Lambdas.

When to override the default

Before choosing any transport, ask whether the call needs a response at all. If the caller does not need the callee’s answer in-band, EventBridge or SQS is cheaper, more available, and removes the coupling instead of formalising it. Only a genuine request/response call belongs on this layer.

VPC Lattice deserves more than a paragraph, because it is the strongest objection to this entire series and the case for it is better than most write-ups admit. State it at full strength first.

Lattice is the service AWS built for exactly this traffic. Lambda is a native target type. Its auth policies are IAM policy documents evaluated with SigV4, on the action vpc-lattice-svcs:Invoke. And here is the part that should end a certain kind of argument: those policies are more expressive than an API Gateway resource policy, not less. Lattice ships condition keys for RequestMethod, RequestPath, RequestHeader, RequestQueryString, SourceVpc, and SourceVpcOwnerAccount (auth policies). AWS’s own example grants a role GET and nothing else. A resource policy on API Gateway has no header or query-string predicate to offer in reply. Lattice also gives the caller no endpoint plumbing to manage, associates VPCs to a service network directly, and shares across accounts through RAM.

So say it plainly. On identity, Lattice is not behind this layer. It is ahead of it. If you picked a private API Gateway because you believed it was the only way to get per-route IAM authorization on an internal call, you picked it for a reason that does not exist. AWS’s own framing points the same way: it positions API Gateway as the north-south front door and Lattice as the service-to-service layer. This series argues against that framing, and the honest thing is to say so out loud, and to say that AWS publishes no decision guide comparing the two. The argument below is mine, not AWS’s.

The argument is cost shape and API management, in that order.

Cost shape. Lattice charges $0.025 per service per hour, roughly $18.25 per service per month, plus $0.025 per GB processed. Requests are free for the first 300,000 per hour per service, which works out to roughly 219 million per month if traffic is evenly spread, then $0.10 per additional million (VPC Lattice pricing, read 2026-07-14). Read that against a private API Gateway: one shared interface endpoint costs about $14.60 per month across two AZs and serves every private API in the VPC, while requests cost $3.50 per million. The two fixed costs behave differently, and that is the whole game. Lattice’s floor scales linearly with the number of services. API Gateway’s floor does not scale at all.

That asymmetry decides most estates before the request charge matters:

Estate	Private API Gateway	VPC Lattice
20 services, 200k requests each per month	about $29	about $365
20 services, 5M requests each per month	about $368	about $375
3 services, 50M requests each per month	about $545	about $69

Per service, ignoring data processing, the crossover is where Lattice’s $18.25 is repaid by API Gateway’s $3.50 per million: roughly 5.2 million requests per service per month. Below it, the private API is cheaper, and a wide, shallow estate is not close. Above it, Lattice pulls away hard, because its marginal request price is 35 times cheaper.

API management. This is the argument that survives even when the money is a wash. API Gateway lets the callee defend itself and publish a contract. It has stage-level per-method throttling, so a team can cap a route it owns. It validates a request body against a schema before the integration runs. It exports an OpenAPI document. It takes WAF and it can cache. Lattice has none of these: no throttling of any kind, no request validation, no contract artifact, no WAF, no caching. Its listener rules match on header, method, and path, and that is the extent of it. In a multi-team estate, “any authorized caller may hammer me at the service quota and I have no way to say no” is a real operational hole, and it is the hole this layer fills. One caveat, because it matters: AWS says usage-plan throttling and quotas “are not hard limits, and are applied on a best-effort basis”, and per-caller quotas require API keys, which AWS separately tells you not to use for authorization. The defensible claim is per-route throttling, not per-caller billing-grade quotas.

Take the override when any single service crosses roughly 5 million calls a month, when the targets are not all Lambda (Lattice covers ECS, EKS, EC2, ALB, and IP targets), when you need cross-VPC or cross-account discovery without per-caller endpoint plumbing, or when your authorization genuinely needs a header or query-string predicate. Note what is not on that list: gRPC. Switching to Lattice does not buy you gRPC while your compute is still Lambda functions, for the reasons part 103 spells out. And one thing Lattice does not hand you in an all-Lambda estate, despite the reputation: health checks. AWS is explicit that they “do not support Lambda target groups”.

ECS Service Connect is the name people reach for the moment they hear App Mesh is being switched off. For an all-Lambda estate it is not a weaker option. It is an empty set.

Service Connect is not a network you join, it is a deployment feature of an ECS service. Its data plane is a managed Envoy sidecar that ECS injects into every task, its configuration lives in serviceConnectConfiguration on an ECS service, and its registry is a Cloud Map HTTP namespace that creates no Route 53 records. The considerations page is categorical: “Only the tasks that services create are supported.” Applications outside ECS, in AWS’s words, “can connect through the Service Connect proxy but can’t resolve Service Connect endpoint names” (Service Connect). A Lambda function has no task, no sidecar, and no name to resolve. AWS never writes the sentence “Lambda is not supported”, because it does not need to: the exclusion is structural. The roadmap request for Lambda support has been open since February 2023.

Two things stay true even if AWS shipped that support tomorrow. Service Connect has no IAM authorization. Access control is security groups, and its TLS is encryption without peer authentication, so there is no mutual TLS either. Trading this layer for Service Connect would swap an identity boundary for a network boundary. And the asymmetry runs one way only: an ECS task holding execute-api:Invoke on its task role is a first-class caller into the private API described here. This layer accepts ECS clients. Service Connect does not accept Lambda clients.

Service Connect is the right answer when the estate is ECS talking to ECS, in one Region and one namespace, and you want short names, retries, outlier detection, and per-service metrics with no code change and no extra service charge. That is the shape AWS recommends it for, and it is the App Mesh replacement for ECS. It is simply not a shape a Lambda can take. For a mixed estate the arithmetic is different again: Service Connect covers only the ECS half, so you would run two east-west mechanisms. Lattice is the one layer that spans both, because LAMBDA is a native target type alongside INSTANCE and IP. That is the real reason “targets are not all Lambda” points at Lattice rather than at Service Connect.

ALB with Lambda targets is cheaper per request than a REST API, and it is not a contract layer. It has no IAM authorization, no per-route usage plan, and an hourly plus LCU bill of its own. It balances load; it does not publish a contract.

Direct invoke remains correct inside a single service’s own boundary, where the caller and the callee ship together. It stops being correct at a team boundary. That is the whole rule.

Where this is all heading

It would be easy to read this series as a serverless workaround: no mesh available, so improvise. That reading is backwards. The mesh world is walking toward the same conclusion from the other side, and AWS has already arrived.

AWS is retiring its own service mesh. The App Mesh user guide carries the notice on every page: “On September 30, 2026, AWS will discontinue support for AWS App Mesh. After September 30, 2026, you will no longer be able to access the AWS App Mesh console or AWS App Mesh resources” (App Mesh). New customers were shut out back in September 2024. AWS built a sidecar mesh, ran it for years, and is switching it off. That is not a small signal about where managed east-west connectivity is going.

Be precise about what AWS replaced it with, because the obvious summary is wrong. AWS did not abolish the proxy. For ECS it points customers at Service Connect, where, in AWS’s words, “the Envoy proxy, known as the Service Connect Proxy, is fully managed by AWS”, against App Mesh’s self-managed sidecar. Envoy is still in the task. It is simply no longer your problem. The retired idea is not the sidecar, it is you operating the sidecar.

The open-source mesh is moving the same way. Istio’s ambient mode reached GA in November 2024, and its pitch is a mesh without per-pod proxies: L4 handled by a per-node ztunnel, L7 proxying opt-in and separately scaled (ambient mode). Istio’s own motivation reads like a bill of indictment against the sidecar: proxies must be injected by rewriting the pod spec, upgrades mean restarting application pods, and “the CPU and memory resources must be provisioned for worst case usage of each individual pod” (introducing ambient mesh). Cilium reaches the same place through eBPF with a per-node Envoy rather than a per-pod one.

Do not overstate it, though, because it is not unanimous. Istio still supports sidecars and says they “are not going away”. Linkerd, the other CNCF graduated mesh, argues the opposite outright and is fixing sidecar lifecycle problems rather than removing the proxy. The honest claim is not that the industry abandoned sidecars. It is that the centre of gravity is moving off the per-workload proxy and into the platform.

Which is the whole point. Both worlds have concluded the same thing: identity, authorization, encryption, and telemetry for east-west calls belong to the platform, not bolted to the workload. Istio ambient is Kubernetes working to acquire a property serverless had by construction. Lambda never had a sidecar to remove. The gateway, IAM, and the managed network are the platform layer, and this series is just wiring them together.

The convergence is real, but the implementations are diverging, and that is the trade you are signing. Kubernetes is standardising on portable, vendor-neutral specifications that you operate yourself: SPIFFE and SPIRE for workload identity, a CNCF graduated project since 2022, and OpenTelemetry, graduated in May 2026, for tracing across service boundaries. Serverless standardises on cloud primitives that you do not operate and cannot move: IAM SigV4, a private API Gateway, EventBridge. SigV4 and SPIFFE answer the same question, which workload is calling, with the same shape of answer, cryptographic and short-lived. The difference is who owns the trust root. You are buying an operator-free platform and paying in portability. That is a defensible trade, and it should be a conscious one.

One gap is worth admitting rather than papering over. The industry is settling on a two-part answer to identity on an internal call, and only half of it has landed. SPIFFE covers which workload is calling. For the other half, on whose behalf, the IETF’s Transaction Tokens draft is explicit that the two are not interchangeable: “A workload MUST NOT use a transaction token to authenticate itself to another workload, service or the TTS. Transaction tokens represents information relevant to authorization decisions and are not workload identity credentials” (Transaction Tokens). That is exactly the two-check rule part 102 arrived at from the AWS side. The difference is that the standard is still a working-group draft, so for now you build the second check yourself.

Trade-offs you are signing up for

The account-level throttle bucket is the one most posts miss. API Gateway allows 10,000 requests per second per account per Region, shared across REST, HTTP, and WebSocket APIs. A documented list of smaller Regions carries a lower 2,500 RPS default (API Gateway quotas). Move east-west traffic onto API Gateway and it now competes with your public APIs for the same bucket. Track headroom before you migrate the tenth service.

The integration timeout defaults to 29 seconds. Raising it for Regional and private REST APIs is possible, but AWS notes that doing so “might require a reduction in your account-level throttle quota limit” (What’s New, June 2024). Direct invoke has no such ceiling under the 15-minute function timeout. Long-running east-west calls do not belong behind this layer; they belong in Step Functions or an async pattern.

Private DNS carries a trade-off too. With private DNS enabled for execute-api in a VPC, that VPC can no longer reach the default endpoint of public API Gateway APIs. A private hosted zone workaround is the way around it. If the same functions call a public third-party API hosted on API Gateway, know this before you flip the switch. The alternative addressing form is the endpoint-associated alias, https://{rest-api-id}-{vpce-id}.execute-api.{region}.amazonaws.com/{stage} (invoke a private API).

Finally, VPC attachment is a one-time architectural commitment: subnets, security groups, an ENI budget. Cheap once, not free.

What I plan to measure

The POC is not deployed, so these are targets rather than results. Gateway overhead per call is the first number: Latency minus IntegrationLatency at p50 and p99, per route. That difference is exactly what the per-call tax buys or costs. Then the monthly bill: requests times $3.50 per million, plus endpoint AZ-hours, plus PrivateLink GB processed, set against the Lattice service-hour equivalent at the estate’s real service count. Then per-route 4XXError and 5XXError rates, which direct invoke cannot produce at all. And one adoption metric that matters more than any of them: the count of cross-team lambda:InvokeFunction grants, where the target is zero.

Where this default holds

The default holds for a multi-team serverless estate with all-Lambda targets, request/response calls, and moderate volume. That default is a private REST API behind one shared execute-api interface endpoint, with AWS_IAM per-route grants. It gives you a mesh’s authorization and observability story with no sidecar, no control plane, and a fixed cost measured in tens of dollars.

Apply the filters in order, because the first one removes the most work. If nobody is waiting on the reply, use an event bus and none of this applies. If the targets are not all Lambda, or a service crosses roughly 5 million calls per month, Lattice starts to win. If you need gRPC, you are changing compute, not gateways. And whatever you ship the bytes as, keep the schema as the contract, because that is the part you will still be living with when the wire format changes.

The first step is cheaper than the migration: count the cross-team lambda:InvokeFunction grants in your account today. That number is the size of the coupling you are carrying.

References

• AWS App Mesh - “On September 30, 2026, AWS will discontinue support for AWS App Mesh.” AWS is switching off its own sidecar mesh.
• Migrating from App Mesh to ECS Service Connect - The replacement is a managed sidecar, not no sidecar: “the Envoy proxy, known as the Service Connect Proxy, is fully managed by AWS”. An AWS blog, not a doc.
• Amazon ECS Service Connect - “Only the tasks that services create are supported”, and applications outside ECS “can’t resolve Service Connect endpoint names”. Why it is an empty set for an all-Lambda estate.
• Istio ambient mode - A mesh without per-pod proxies: L4 in a per-node ztunnel, L7 proxying opt-in and separately scaled. GA since November 2024.
• Introducing ambient mesh - Istio’s own indictment of the sidecar: injection by pod-spec rewrite, restarts on upgrade, and worst-case resource provisioning per pod.
• SPIFFE - CNCF graduated since 2022. The portable, vendor-neutral answer to “which workload is calling”, and the job IAM SigV4 does inside AWS.
• OpenTelemetry - CNCF graduated in May 2026. The standard for tracing across service boundaries, which is one of the things a mesh was bought for.
• IETF: OAuth 2.0 Transaction Tokens - The other half of the identity answer: “A workload MUST NOT use a transaction token to authenticate itself… are not workload identity credentials.” Still a draft.
• Amazon API Gateway pricing - REST at $3.50 per million for the first 333M requests; HTTP API at $1.00 per million. Prices read 2026-07-14, us-east-1.
• AWS PrivateLink pricing - Interface endpoints billed per endpoint per AZ-hour with partial hours billed as full, plus per-GB data processing.
• Amazon VPC Lattice pricing - $0.025 per service-hour, $0.025 per GB, first 300,000 requests per hour free, and the 100-service worked example behind the crossover math.
• What is VPC Lattice - AWS’s “fully managed application networking service”, and the network-owner versus service-owner split it is built around.
• VPC Lattice auth policies - IAM policies on vpc-lattice-svcs:Invoke, with condition keys for RequestMethod, RequestPath, RequestHeader and RequestQueryString. Why Lattice is ahead of this layer on identity, not behind it.