First, exposing an API served by AWS Lambda has the infamous cold start problem. It's not fun to wait a couple of seconds for a mobile app to respond just because the request hit in an unfortunate time. One solution we found is to use a Serverless Framework plugin to periodically ping lambdas to keep them hot. But each concurrent lambda execution is a separate container, so you have to anticipate a number of concurrent requests you will be receiving at peak, or want to handle without a ~1s latency. Ouch - what happened to effortless scaling? And Amazon API Gateway adds another 100-200ms of latency on top of Lambda.
If you want to use an SQL database, you have to add your lambdas to a VPC, unless you want to expose your database to the Internet. But if you need to access the Internet from your lambdas, then you need a NAT (which you pay for). And you get another couple of seconds to cold starts while AWS attaches a network interface to your lambda. So, if you don't want this, you're stuck with e.g. DynamoDB. DynamoDB is optimized for scaling but it's a poor fit for relational data. Very basic support for indexes, no transactions, and data model migrations are very painful. There is also no spatial data story for DynamoDB, whereas if we had used Postgres, we'd be able to make use of PostGIS which is awesome.
The tooling is terrible. Serverless Framework is very rigid and riddled with bugs - we ended up maintaining our own fork of Serverless alongside forks of 3 plugins and another custom plugin we wrote to support our very simple workflow. There's no faithful offline reproduction of the API Gateway -> Lambda environment. We frequently ran into issues when the code is deployed that wouldn't show up when testing with a "simulation" plugin locally.
There's a lot of other problems we ran into, but these are the biggest ones I could think of. It didn't help that we didn't have much experience with this technology before deciding to serve our API using it (this was probably our biggest mistake). I guess we should have stuck with what we're faimiliar with - normal, "serverful" apps. And with the DyanmoDB provisioned capacity costs, I'm not sure we saved that much in the end.