The AWS AppSync Limits You Need To Know

The AWS AppSync Limits You Need To Know

All the AWS AppSync service quotas to keep in mind

AWS AppSync is a managed service that enables developers to build scalable and secure GraphQL APIs quickly. However, as with any service, there are certain limits thet must keep in mind while designing their APIs. In this article, we'll discuss the important limits you should know.

API Limits

You can create up to 25 AppSync APIs per region. However, if you need more, this limit can be increased. Furthermore, each API can have a maximum of 50 API keys, and up to 50 authentication providers. Those can't be extended, but they should be more than enough to cover most use cases.

Execution Time

AWS AppSync limits the execution time for mutations, queries, and subscriptions to 30 seconds. This limit ensures that the API responds to requests in a timely manner.

Queries that last too long provide a very bad user experience for your customers. There are several things you can do to reduce the execution time:

  • When possible, prefer VTL or JavaScript resolvers over Lambda functions, it can save you some cold starts.

  • Avoid resolvers that are too deeply nested. Nested resolvers are executed in series because child resolvers expect the parent's data (ctx.source).

  • If you're using pipeline resolvers, keep the number of functions to a minimum.

  • Optimize your requests. For example, make sure you use proper indexes when you query DynamoDB or RDS data sources.

💡 Tools such as X-Ray or GraphBolt can help you understand how queries are executed and detect slow resolvers and bottlenecks.

Resolvers

The maximum number of resolvers that can be executed in a single request is 10,000. Remember that one resolver might be executed more than once in the same request. This often happens when resolving nested fields from a list, for example (n+1 problem). Be careful, the number of executions can compound pretty quickly, especially if you deep-nest resolvers (my friends, the friends of my friends, and their friends).

Still using VTL? The maximum size of VTL mapping templates is 64 kilobytes, while their maximum size after they are evaluated is 5 megabytes, and the number of iterations in a foreach loop is limited to 1,000.

If you're using JavaScript resolvers, you can't use more than 32,000 characters.

For pipeline resolvers, the maximum number of functions that can be used is 10 per pipeline. If you need more complex logic, it's probably time to switch to a Lambda resolver (or an Express Step Function).

Request Tokens

AWS AppSync allocates request tokens to mutation and query requests based on the amount of resources they consume, with a maximum rate of 2,000 per second per region (shared by all the APIs!).

Requests consuming less than or equal to 1,500 KB-seconds of memory and vCPU time are allocated one token. After that, one more token is added per additional chunk of 1,500 KB-seconds consumed.

Although you can request a quota increase, a high token consumption could indicate the need to optimize requests and improve API performance. It also affects the number of requests that your APIs can receive per second. The more tokens they consume, the fewer concurrent requests they will accept.

Subscriptions

The maximum size of a message that can be received through subscriptions is 240 kilobytes.

There is also a default limit of 100 subscriptions per WebSocket connection (that is, per client), but it can be adjusted.

Finally, a hard limit of 100 subscription invalidation requests per second applies.

Other Limits

Maximum size of the schema document: 1 megabyte.

The maximum number of AppSync custom domains that you can create in a region is 25, but you can request more if you need them.

If you're using caching, you won't be able to use more than 25 caching keys per resolver, and each item has a maximum Time To Live (TTL) of 1 hour.

Conclusion

AWS AppSync offers a range of features and functionalities for building GraphQL APIs, but it's important to be aware of the service's limits. Remember that they are there for a reason; they are guard rails to prevent you from adopting bad practices that could affect the performance of your APIs and make sure they perform and scale.