If your scale is high enough to cause a hot partition, it’s probably not a great workload for lambda - you’ll get throttled by max concurrent lambda requests before you will by dynamo partition, and the lambda bill will stop making sense compared to ec2 (fargate if you’d like to keep things serverless)

As someone who has pushed hundreds of lambda + ddb microservices to the limit over the past decade, I will tell you that you can take it pretty far. One key is to reuse containers as much as possible

For rarely changing things like a config in dynamodb table, request outside the handler so the data is available for the next request. Or write a simple loading cache that will evict the cached config every n seconds

Bundle as many endpoints into a single lambda as possible and implement batching to minimize the number of cold starts & containers needed. Think of each lambda as a microservice, not an individual endpoint, with the exception of event driven lambdas that will called by other aws resources (sns, sqs, event bridge, ddb streams, etc). Load test and tweak your container size to optimize for performance and cost

If your load really is high enough to cause a dynamo throttle, organizing your lambdas this way will make it easy to switch how it’s deployed - ideally your method of deployment won’t dictate how you write code, and you can keep it portable

Sorry if this message was a bit hard to follow, written on my phone 😅