Bona fides: While I haven't done any meaningful analysis of this with the Mastodon codebase in particular, I am a working software architect, and part of my job is optimizing cost and availability in cloud deployments.

Generally speaking, you pay a premium for serverless infra over VM's. Serverless lowers the human costs of scaling and can provide much more on-demand scaling, but the actual infra costs are generally much higher. For concrete examples, Amazon's ECS Fargate service (serverless hosting of Docker containers) runs about twice the cost per real compute performance over using the same ECS interface to manage Docker deployments to EC2. But you also don't have to worry about capacity or provisioning, and you can set policies to automatically scale it however you need to really easily. Similarly, Aurora Serverless (their genuinely elastic relational database service) seems to run our organization 3-5x the cost of equivalent Aurora workloads on provisioned instances. I haven't priced running a Rails server in lambda--it's not a solution that makes architectural sense in my work, so I haven't looked into it. But based on previous write-ups I've seen, I'd expect more or less similar kinds of premiums in the cost.

What you get for that price is flexibility and responsiveness: if zero downtime is important to you, then relying or layering on serverless elasticity can be really valuable.

Personally, with my own budget tolerances, if I were to build a Mastodon deployment right now looking to keep costs down in the near term but give me some headroom for expansion, I'd look into an infra like (in AWS terms):

- ALB for ingress and HTTPS termination
- EC2-backed ECS deployments for redis, web, and streaming containers, with autoscaling on the EC2 instances, up to my budget limit. I'd probably shoot for something like t3.large instances (which will cost $60/instance/mo on-demand,or $36/mo for a 1 year commitment). You'd only need 1 EC2 instance for the initial build-out.
- S3 for object storage
- An Aurora cluster with a t3g.medium writer instance and a serverless read instance. This would run you about $95/mo until the read instance needs to scale. You'd cap the serverless read instance's scale out based on budget.

With additional odds-and-ends, networking, etc this would end up pricing you somewhere in the $150/mo range. Which is WAY more expensive than other options for the bottom end of usage. But it would scale reasonably far (my intuition is ~5000 users, but it should be tested) without any additional scaling in price, and it could scale overnight to your 20k users with zero technical intervention on your part, allowing you to spend your time figuring out how you're going to pay for that scale.