Two Easy Ways to Cut Costs in AppSync Merged APIs

#aws #serverless #appsync #architecture

AWS released Merged APIs for AppSync in mid-2023. The Merged API acts as a unified endpoint over disparate AppSync Source APIs. This works well with a microservice architecture, as each source API can live near its resource service. I’ve written about AppSync Merged APIs in the past and have included links to those articles in the references section, below.

The Merged API works by directly loading the schema and resolvers of its Source APIs. It differs from tools like Apollo Federation in that it eliminates an additional network hop. The AppSync Merged API invokes the source resolver directly; it doesn’t make an extra wire call to your Source API. How AppSync does this is not widely publicized and can lead to some inefficiencies in your AppSync architecture. I’ve experienced these inefficiencies firsthand and want to share my solutions. Let’s look at the first problem.

CloudWatch Logging

AppSync can log to CloudWatch, and these logs can be critical for debugging problems. In AppSync, you have three controls you can use to affect logging:

Enable / Disable

Field resolver log level (All/Debug/Info/Error/None)

Include verbose content (e.g., request/response headers, context)All these settings are available on both the Source and the Merged APIs.

How do the settings interact between a source and the Merged API? That is, if I change a log setting in the source API, is that change reflected in the Merged? Today I am here to tell you, “No, it is not.” The settings are completely independent. Each AppSync API gets its own log group.

For example, if you have full logging in your Merged API (Enabled, All, & Include verbose content) and more restricted logging in your source API (Enabled, Error, Exclude verbose content), you will still end up with two independent CloudWatch log groups. The Merged API log group will have more content than the source API log group.

What happens if you completely turn off logging in the source API? This was the question I found myself asking recently. The happy answer is that the Merged API logs everything you ask it to. This leads us to our first cost-cutting measure for AppSync: turn off source API logging in production. This can reduce your AppSync-generated CloudWatch bill by up to half. You can adjust log levels in the Merged API to your preference and disable logging in the source API.

If you deploy to multiple environments, such as dev/staging/production, you can adjust this setting per environment. For example, I deploy (and test) my source APIs in isolation, before merging. I do this in my dev environment. For these tests, having the source API log in CloudWatch is essential for debugging. I set the log levels differently as the app progresses through each environment on its way to production, where the source API logging is fully disabled.

AppSync Caching

AppSync has a built-in cache. It is easy to use, and AWS handles most of the underlying cache management for you. You are responsible for telling AppSync the caching behavior you want to use (Full Request / Per-resolver / Operation) and the size of the cache to provision.

Because you are selecting cache sizes from a tier (ranging from small to 12xlarge) and the cache incurs an hourly charge (ranging from $0.044 to $6.775), this part of AppSync begins to run counter to my definition of “serverless.” Don’t lose hope, however. AppSync was introduced in 2021 without caching, which was added in 2022. AWS introduced Elasticache Serverless in 2024. Don’t be surprised if we get a much more “serverless” caching option in AppSync in the near future.

Anyway, back to the case at hand. Cache settings, like log settings, are configured at the API level. Both AppSync source APIs and Merged APIs have cache settings. And, like we’ve already discovered with log settings, the configuration of one API’s cache does not affect the other. Your caching can be completely turned off on your source APIs, yet it will still work with the Merged API if you enable it there. Nice!

This means you don’t need to pay hourly charges for source API caches and still retain the ability to cache at the Merged API, taking pressure off of your underlying resource services.

Further Savings

You can use your infrastructure-as-code framework to configure log levels and cache sizes in each environment. Whether you are using Serverless Framework, CDK, SAM, or Terraform, you have easy ways to group configuration settings per deployment environment. You will likely want to set your log levels to DEBUG in your dev and staging environments, but to something higher (INFO or WARN) in production, where you (hopefully) have higher traffic.

Similarly, for caches, you don’t need 4xlarge cache instances in your dev environment. Set those to small or medium and save.

Summary

To get the most out of AppSync Merged API, you need to understand the difference between it and “federated” solutions. Because it pulls in resolvers directly, you get logging and caching at the Merged API level. This allows you to disable logging and caching on all your AppSync Source APIs without losing any functionality.

Happy building!