Cargando...
Cargando...
Managed GraphQL and Pub/Sub APIs with offline sync, real-time subscriptions, and multi-source data federation — serverless, at scale.
Amazon AppSync is a fully managed service that enables developers to create scalable GraphQL and Pub/Sub APIs that securely connect applications to data sources including AWS DynamoDB, Lambda, RDS, OpenSearch, HTTP endpoints, and more. It provides built-in real-time data synchronization via WebSocket subscriptions, offline data access with conflict resolution for mobile/web apps, and fine-grained authorization controls. AppSync eliminates the need to manage GraphQL server infrastructure, handling connection management, caching, and scaling automatically.
Build and run scalable GraphQL APIs that federate multiple data sources, support real-time subscriptions, and enable offline-first mobile/web applications without managing any server infrastructure.
Use When
Avoid When
GraphQL API support
Full GraphQL spec: queries, mutations, subscriptions
Pub/Sub API (Event API)
AppSync Events — serverless WebSocket Pub/Sub without GraphQL schema requirement, GA as of 2024
Real-time WebSocket subscriptions
Server-push updates to connected clients via GraphQL subscriptions
Pipeline resolvers
Chain multiple resolver functions sequentially for complex business logic
JavaScript resolvers (APPSYNC_JS runtime)
Modern alternative to VTL — write resolver logic in JavaScript (subset of ES2022)
VTL (Velocity Template Language) resolvers
Legacy resolver language; still supported but JavaScript resolvers preferred for new development
Direct Lambda resolvers
Bypass VTL/JS templates entirely and invoke Lambda directly
Server-side caching
Per-resolver or per-API caching backed by ElastiCache; reduces data source calls
Merged APIs (API federation)
Combine multiple AppSync source APIs into a single unified API endpoint
Fine-grained authorization
Supports API Key, AWS IAM, Amazon Cognito User Pools, OIDC, and Lambda authorizers
Multiple authorization modes per API
One primary + up to 2 additional auth modes simultaneously
Offline sync (DataStore)
Via AWS Amplify DataStore — automatic conflict detection and resolution for offline-first apps
DynamoDB data source
Native integration with batch operations, transactions, and single-table design support
Aurora Serverless (RDS Data API) data source
Query relational databases via RDS Data API
OpenSearch Service data source
Full-text search and analytics queries from GraphQL resolvers
HTTP data source
Call any HTTP/HTTPS endpoint including third-party APIs
EventBridge data source
Publish events directly to EventBridge from AppSync resolvers
AWS WAF integration
Protect AppSync APIs with WAF rules for rate limiting and threat filtering
CloudWatch Logs & X-Ray tracing
Full observability with field-level logging and distributed tracing
Private APIs (VPC endpoints)
AppSync APIs can be made private and accessible only within a VPC via VPC endpoints
Custom domain names
Associate custom domains with AppSync APIs
Conflict detection and resolution
Built-in strategies: OPTIMISTIC_CONCURRENCY, AUTOMERGE, LAMBDA — used with Amplify DataStore
GraphQL-to-DynamoDB Direct Resolver
high freqAppSync resolvers use built-in DynamoDB request/response templates (VTL or JS) to perform GetItem, PutItem, Query, Scan, and TransactWriteItems without Lambda — reduces latency and cost by eliminating a compute layer
Lambda Resolver for Complex Business Logic
high freqUse Lambda as a data source when resolver logic requires complex computation, multi-step orchestration, or calling external services not natively supported — Direct Lambda resolvers skip VTL entirely for simpler code
Cognito-Authenticated GraphQL API
high freqCognito User Pools as the primary auth mode enables user-level authorization; combined with field-level @auth directives in the schema to restrict access per user role or group
Amplify DataStore Offline-First Mobile App
high freqAmplify DataStore uses AppSync as the backend for automatic data synchronization, conflict resolution, and offline support in iOS, Android, React Native, and web applications
GraphQL Mutation to Event Bus
medium freqAppSync mutations publish events directly to EventBridge event bus using the native EventBridge data source — enables event-driven architectures triggered by GraphQL API calls without Lambda intermediary
Full-Text Search GraphQL API
medium freqAppSync queries route to OpenSearch for full-text search, aggregations, and analytics while other resolvers in the same schema hit DynamoDB — single GraphQL API federating multiple data stores
Protected GraphQL API
medium freqWAF Web ACL attached to AppSync API provides rate limiting, IP blocking, SQL injection protection, and bot control — critical for public-facing GraphQL APIs which are vulnerable to query depth attacks
Relational Database GraphQL API
medium freqLambda resolver calls RDS Data API (Aurora Serverless) or RDS Proxy to execute SQL queries, returning structured data to AppSync — used when relational data model is required behind a GraphQL interface
Merged APIs (AppSync Federation)
medium freqMultiple source AppSync APIs (owned by different teams) are merged into a single Merged API endpoint — enables microservices teams to independently manage their GraphQL schemas while exposing one unified API to clients
Globally Distributed GraphQL API
low freqCloudFront in front of AppSync caches query responses at edge locations for read-heavy workloads — reduces latency for global users and offloads AppSync for cacheable queries
AppSync subscriptions are triggered by mutations — a client subscribes to a specific mutation (e.g., onCreatePost) and receives real-time updates whenever that mutation executes. The subscription filter happens server-side. This is the core real-time mechanism and is almost always tested.
AppSync supports FIVE authorization modes: API Key (for public/dev use, expires in 1-365 days), AWS IAM (for AWS service-to-service), Amazon Cognito User Pools (for user auth), OpenID Connect/OIDC (for third-party identity providers), and Lambda Authorizer (for custom auth logic). You can enable one primary + additional modes simultaneously. Know which mode to choose for each scenario.
Pipeline resolvers allow you to chain multiple resolver functions (called 'functions' in AppSync) in sequence on a single GraphQL field. Each function can call a different data source. This is the correct architecture for 'fetch user, then fetch their orders, then check inventory' type logic — NOT multiple separate resolvers.
For offline-first mobile apps with automatic sync and conflict resolution, the answer is AppSync + Amplify DataStore — NOT a custom solution with S3 + SQS. DataStore provides built-in conflict resolution strategies (OPTIMISTIC_CONCURRENCY, AUTOMERGE, LAMBDA) and handles the sync protocol automatically.
AppSync subscriptions are triggered by mutations via persistent WebSocket connections — the server PUSHES updates to subscribers. This is the correct answer for any real-time, event-driven, or collaborative application scenario.
Know all 5 AppSync authorization modes: API Key (public/dev), IAM (AWS services), Cognito User Pools (end users), OIDC (third-party IdP), Lambda Authorizer (custom). Multiple modes can be active simultaneously (1 primary + additional). Match the auth mode to the scenario.
AppSync ≠ API Gateway. AppSync is for GraphQL with native subscriptions, multi-source federation, and offline sync. API Gateway is for REST/HTTP/WebSocket. Never substitute one for the other on exam answers involving GraphQL.
AppSync caching reduces calls to your data sources (DynamoDB, Lambda, etc.) by caching resolver responses. Caching can be scoped to the full request (per unique query + variables + identity) or per resolver. Enabling caching requires provisioning a dedicated cache instance — this incurs HOURLY costs regardless of usage. Always factor this into architecture cost discussions.
JavaScript resolvers (APPSYNC_JS runtime) are the modern replacement for VTL. New AppSync features are being added to JS resolvers first. If an exam scenario mentions 'reduce complexity of resolver logic' or 'developer-friendly resolver code,' JavaScript resolvers are the preferred answer over VTL for new development.
AppSync Merged APIs allow multiple independent AppSync source APIs to be combined into a single unified API endpoint. This is the AppSync answer to GraphQL federation for microservices — different teams own different source APIs, and the Merged API stitches them together. Distinguish this from a single AppSync API with multiple data sources.
AppSync Events (Pub/Sub API) — launched 2024 — is a separate capability from GraphQL APIs. It provides WebSocket-based Pub/Sub WITHOUT requiring a GraphQL schema. Clients publish to named channels and subscribers receive messages. This is the AppSync answer when the scenario says 'real-time broadcast' or 'fan-out' without GraphQL complexity.
The 30-second maximum execution timeout for queries and mutations is a hard limit. For operations that take longer (e.g., complex ML inference, long ETL), use an async pattern: mutation triggers Lambda which processes asynchronously, then publishes result via a mutation that triggers a subscription update to the waiting client.
API Key authorization in AppSync has an expiration between 1 and 365 days. It is intended for public APIs or development/testing — NOT for production user authentication. Exam scenarios describing 'unauthenticated public read access' point to API Key; scenarios with 'authenticated users' point to Cognito or IAM.
Common Mistake
AppSync is just a GraphQL wrapper around DynamoDB — it only works with DynamoDB as a data source
Correct
AppSync supports a wide range of data sources natively: DynamoDB, Lambda, Aurora Serverless (RDS Data API), OpenSearch Service, HTTP endpoints, EventBridge, and None (for local resolvers). A single AppSync API can federate ALL of these simultaneously under one GraphQL schema.
This misconception causes candidates to choose Lambda-based custom GraphQL servers when AppSync would natively serve the use case. Remember: AppSync = multi-source federation, not DynamoDB-only.
Common Mistake
AppSync subscriptions work like polling — the client periodically queries for new data
Correct
AppSync subscriptions use persistent WebSocket connections (MQTT over WebSocket). The SERVER pushes updates to subscribed clients in real-time when a relevant mutation occurs. No polling is involved. This is fundamentally different from REST API polling patterns.
This is a critical architectural distinction. Exam questions that contrast 'real-time push' vs 'polling' should always point to AppSync subscriptions for the push answer. Polling solutions (even with API Gateway) are anti-patterns for real-time requirements.
Common Mistake
You need to use VTL (Velocity Template Language) to write AppSync resolvers — there's no other option
Correct
AppSync supports TWO resolver runtimes: VTL (the original, still supported) and JavaScript (APPSYNC_JS, the modern preferred runtime using a subset of ES2022). JavaScript resolvers are generally preferred for new development due to readability and easier debugging. Direct Lambda resolvers bypass both entirely.
Many candidates studied AppSync before JavaScript resolvers were introduced and assume VTL is mandatory. On exams, 'reduce resolver complexity' or 'use familiar language' scenarios favor JavaScript resolvers. VTL is not deprecated but is no longer the only choice.
Common Mistake
Enabling AppSync server-side caching is always free and just improves performance
Correct
AppSync caching provisions a dedicated ElastiCache-backed cache cluster that incurs HOURLY charges based on the instance type selected (from t2.small to r4.8xlarge). You pay for the cache instance even if it receives zero traffic. This can significantly increase costs for low-traffic APIs.
Cost optimization questions may present caching as a free optimization — it is NOT. For low-traffic or cost-sensitive APIs, consider client-side caching or CloudFront instead. Always weigh the cache instance cost against the data source call savings.
Common Mistake
AppSync is only for mobile apps — it's not suitable for web or server-to-server use cases
Correct
AppSync serves mobile apps, web applications (React, Vue, Angular), server-to-server integrations (using IAM auth), IoT devices, and any HTTP/WebSocket client. AWS Amplify makes mobile/web integration easier, but AppSync is a general-purpose managed GraphQL service usable from any client.
The strong association with Amplify and mobile DataStore leads candidates to incorrectly exclude AppSync from web or backend-to-backend architecture options. IAM authorization makes AppSync perfectly suited for secure service-to-service GraphQL calls.
Common Mistake
AppSync and API Gateway are interchangeable — use either for GraphQL APIs
Correct
API Gateway does NOT natively support GraphQL. API Gateway is for REST and HTTP APIs (and WebSocket APIs for custom real-time). AppSync is the AWS-managed GraphQL service with built-in subscriptions, schema management, resolver engine, and data source integrations. They solve different problems.
This is a classic exam trap. If a question mentions GraphQL, real-time subscriptions, or offline sync — AppSync is the answer. If it mentions REST, HTTP, or OpenAPI — API Gateway is the answer. They are not interchangeable.
APOLLO = AppSync Pipeline, Lambda, OIDC, Lambda-auth, OpenSearch — the five key AppSync integration pillars
CIAO for AppSync auth modes: Cognito, IAM, API Key, OIDC (plus Lambda = CIAOL) — one primary mode + up to 2 additional
AppSync subscriptions = PUSH not PULL — 'S' for Subscribe = Server Sends, not client Scans
30-second rule: AppSync queries/mutations = 30 seconds max. Anything longer = async pattern (mutate → Lambda → subscribe)
Caching COSTS: AppSync cache = ElastiCache instance = Hourly bill. Cache ≠ Free. Cache = Cluster.
CertAI Tutor · · 2026-02-21
In the Same Category
Comparisons
Guides & Patterns