# Strategies for Designing Around Serverless Service Limits
Written on
Chapter 1: Understanding Service Limits
When creating applications with managed services, being aware of service limits is crucial to avoid unexpected issues in production.
Photo by Nicolas Cool on Unsplash
As a solutions architect, I frequently participate in project design meetings. One recurring theme I notice is the statement, “We can’t utilize service X due to its low limit.” Surprisingly, this comes up quite often.
Your initial thought may be to request an increase in service limits. While that can be a solution, not every limit can be adjusted, and even if it can, it may not suffice for your needs. Service limits exist for valid reasons. Before seeking an increase, consider why the limit is in place. AWS has these restrictions for a purpose, and circumventing them is usually ill-advised.
Let’s examine some scenarios to find alternative approaches that align with the intended use of these services.
Section 1.1: SNS Filter Policies
Amazon SNS has a standard limit of 100,000 topics per account (or 1,000 FIFO topics), yet allows only 200 subscription filter policies per account. This discrepancy can be puzzling. If both limits are fully utilized, only 0.2% of your topics can have a subscription filter if each topic has a single subscription.
The reason behind these varying limits is unclear, but it’s essential to factor this into your application design.
Consider a multi-tenant application where integrators subscribe to events, which increase as development progresses. Initially, I designed a system where all subscriptions were channeled through a single topic, with filter policies for tenant and event specifics.
This approach worked until it didn’t. Upon hitting the subscription filter limit, I had to quickly rethink the architecture. Instead of relying on a single topic for all subscriptions, I opted for multiple topics created dynamically without filters.
This method leverages the vast number of topics available in an account. The trade-off is the added complexity of managing topic publications, but it’s a manageable task with a one-to-many DynamoDB data model. If I had considered the service quota earlier, I could have saved significant development time.
Section 1.2: Lambda Authorizer Result Size
Lambda Authorizers are functions that provide custom authorization above your API Gateway, validating user identities and returning IAM policies containing accessible endpoint ARNs. However, the policy size is capped at 8KB.
Previously, I suggested a centralized Lambda authorizer for the entire ecosystem to improve caching efficiency. However, as my application expanded to include numerous microservices and endpoints, we encountered the policy size limit because every endpoint needed explicit listing, given our system-defined roles.
To address this, we decided to implement Lambda authorizers within each microservice. This not only reduced policy sizes but also improved flexibility in enriching the authorizer context with caller data.
This situation illustrates the importance of planning for future scalability in your designs. Always assess whether your design might outgrow service quotas.
The first video, "AWS re:Invent 2019: [REPEAT 3] Serverless Architectural Patterns and Best Practices," delves into effective design strategies for serverless architectures.
Chapter 2: EventBridge Rule Targets
EventBridge manages event routing through rules, each limited to five targets. In an architecture review, a participant stated that EventBridge was unsuitable due to this limitation, assuming that more than five subscribers rendered it unusable.
Fortunately, by using SNS as a target, you can easily notify multiple subscribers. Simply include an SNS topic as one of your targets to fan out notifications.
Each target should represent a distinct process, whether it’s for auditing events, transforming them for other applications, or notifying subscribers.
Service limits serve important purposes. Attempting to circumvent them in complex ways can lead to maintenance challenges. Embrace the intended use of the tools in your designs.
Similar to EventBridge, adhering to best practices with DynamoDB Streams is essential. It’s advisable to maintain a maximum of two handlers to avoid throttling. For multiple processes resulting from a DynamoDB Stream, you can again use SNS to fan out messages, enabling multiple consumers.
Section 2.1: DynamoDB Query Size Limits
DynamoDB imposes a query size limit of 1MB for scan or query operations. If a query exceeds this size, it returns a LastEvaluatedKey property, indicating further results are available.
In a previous article, I detailed how our application faced data "loss" due to ignoring this limit. We had not accounted for the maximum query size, which resulted in partial data responses.
To prevent this, consider two options:
- Design your data model to avoid exceeding 1MB.
- Implement paging in your application.
Effective design upfront can help avoid this limit. However, if unbounded data or large objects are unavoidable, incorporating DynamoDB paging into your application is crucial to prevent unexpected data loss.
Conclusion
Service limits serve as protective measures in your infrastructure design. If you encounter issues with quotas as your application scales, reevaluating your design is often the best course of action. In some instances, increasing the limit may be necessary.
Ultimately, ensure you work in harmony with infrastructure limits. They exist to prevent missteps. Designing applications is challenging, and it’s essential to be aware of service quotas for the services you are using.
Remember to monitor these limits throughout your application’s lifecycle. They are not just a one-time consideration but require ongoing attention to ensure that as you grow, your infrastructure can keep pace. Even serverless architectures have their limits.
Most service limits can be increased, but for those that cannot, a thoughtful design decision is necessary. By questioning the reasons behind these limits, you can gain deeper insight into the AWS ecosystem.
Good luck, and consider these insights in your next system design!
The second video, "AWS re:Invent 2023 - Best Practices for Serverless Developers," provides valuable strategies for serverless application design and management.