I'd say that Django is not a great fit for lambda. Lambda works best when you architect you code around it, with lots of tiny methods. Django does not encourage this way of coding (just like the other frameworks).
> Lambda works best when you architect you code around it, with lots of tiny methods
as a total hobbyist: why?
deploying a django app with zappa is extremely painless... its only issue is that you still need an SQL backend, as DynamoDB isn't really an option unless you want to kiss most of djangos values goodbye.
that would've been my take why you'd want to use flask... because there is very little value in django if you remove models, caching, authentication, permissions and more (that can't be used without external infrastructure) from the equation.
I guess it depends on size of your app and expected load.
When your app is small and you got almost no users, zappa is great: your lambdas are lighting fast and you're in aws free tier.
When your app grows to like 200k SLOC and 50+ lines in requirements, chances are that it starts quite slow. Do you really want to pay for that?
When your load is high enough, well, aws lambdas become quite expensive even without zappa overhead compared to, say, EC2. https://servers.lol/ should say if serverless makes sense for any defined usecase.
Additionally, lambdas have hard restrictions (like 15 minutes limit) and sometimes it's a dealbreaker for you.
As a non-expert on lambda... Django encourages one function per view, and adding database calls, celery functions, maybe API calls, to your views make them quite big, and potentially slow to run. Running slow functions is not how lambdas are supposed to work (as I've understood them). Rather, you'd want smaller ones that call out to other smaller lambdas. That coding style is not something lambda encourages.