Service spotlight: AWS AppSync and its resolver-cost model

GraphQL servers usually mean running (and scaling, and patching) a Node process that resolves fields by calling out to your actual data sources. AppSync’s pitch is skipping that process entirely — you define a schema and per-field resolvers that AppSync itself executes, with no server of yours in the request path unless a resolver specifically needs one. That’s a meaningfully different operational model, and it comes with a cost model that’s easy to underestimate if you’re used to thinking in request-per- second server pricing.

What it actually is

You upload a GraphQL schema and attach a resolver to each field that needs one — a small piece of logic that maps the incoming GraphQL selection to a call against a data source: DynamoDB, Aurora (via RDS Data API), OpenSearch, EventBridge, HTTP endpoints, or a Lambda function for anything custom. Resolvers used to be written in VTL (Apache Velocity Template Language, borrowed from API Gateway’s mapping templates) — verbose, unfamiliar syntax most teams didn’t already know. AppSync now supports JavaScript resolvers as the default recommended option, which is a meaningfully better developer experience if you’re starting fresh; VTL still works for existing resolvers and some advanced batching patterns.

The other core piece is built-in real-time subscriptions over WebSockets — a client subscribes to a mutation, and AppSync pushes the result to every subscribed client when it fires, with the pub/sub infrastructure entirely managed. That’s the feature that’s genuinely hard to replicate cheaply with a hand-rolled server; it’s Socket.io-style infrastructure you don’t have to run.

Where it earns its keep

• DynamoDB-backed APIs, especially. A direct AppSync-to-DynamoDB resolver (no Lambda in between) is close to the cheapest, lowest-latency path from a GraphQL query to a NoSQL read — no cold start, no intermediate compute to size or scale.
• Apps that need live data — collaborative tools, dashboards, chat — where subscriptions replace a polling loop or a separately-built WebSocket service.
• Fine-grained, field-level auth. AppSync resolvers can enforce authorization per field (via Cognito groups, IAM, Lambda authorizers, or OIDC), so a mobile client and an admin client can query the same schema and see different fields without maintaining two APIs or two sets of REST endpoints.

Where it’s the wrong tool

If most of your resolvers end up calling a Lambda anyway (because the logic is too custom for a direct data-source resolver), you’ve mostly rebuilt “API Gateway plus Lambda” with GraphQL schema validation on top — worth it if GraphQL’s client-side benefits (one round trip, client-specified shape) matter to you, not worth it if you just wanted a managed API layer. And teams unfamiliar with GraphQL’s N+1 problem will hit it here exactly like anywhere else: a nested field resolver that fires once per parent item needs batching (AppSync’s batch invoke for Lambda resolvers, or DynamoDB BatchGetItem) or it’ll quietly turn one query into hundreds of downstream calls.

The pricing gotcha

AppSync bills per query/mutation request and, separately, per resolver invocation within that request — a query resolving five nested fields is one request but potentially five (or more, with N+1) billed resolver executions, plus real-time subscription connection-minutes and message counts on top if you’re using them. A single GraphQL query that looks simple from the client can fan out into a surprising number of billed resolver calls server-side; the AWS docs’ pricing page undersells how fast that adds up on a deeply nested schema, and it’s worth actually tracing a representative query’s resolver count before assuming the bill will track request count linearly.

A practical tip

Use pipeline resolvers to chain multiple resolution steps (an auth check, then a DynamoDB read, then a transform) into a single resolver attached to one field, rather than pushing that logic into nested field resolvers on the schema — it collapses what would be several billed resolver invocations per query into fewer, more predictable ones, and keeps the N+1 pattern from creeping in as the schema grows.