Nice article. Interesting perspective on your pricing comparasion, however, the issue is if you are building a production application in which you need to consider an array of different things such as durability, availability, redundancy, backups, single points of failure, your argument for a single server that holds "a database, storage, and your API" is not resilient. Here are some counterpoints: If your app scales, you will normally need to run a second server, and put a load balancer in front of it. In fact, in low scale its actually very good practice to run at least 2 servers (in separate Availability Zones) to increase availability in case a certain AZ goes down. So, when you scale more, you will need 3+ servers. Having the DB in the same server of your application is generally against good practice. It's highly recommended to put a DB in a separate server, and also run a backup server db and ensure you constantly sync and backup your data. The headache of this makes it way more attractive to use a managed DB instead which will handle db updates, automated backups and give you easier ways to manage scaling. So, the above couple points make the pricing argument not well balanced in the scenario of reliable highly available production apps. Other favorable point for serverless is usage in apps that have seasonal peaks or low growth. Serverless scales nicely for unexpected demands with very low maintenance on your side. You also don't pay for idle resources, and it frees your time on maintenance so you can focus more on business value. Anyways, while I love serverless, there are scenarios where using a server makes more sense, and these scenarios depend on the type of applications you will have. If you can't tolerate any cold start latencies, or if your app requires high memory and cpu requirements, or have long-running functions. Though serverless services in AWS come with different patterns and ways for you to build around these points.

Nice article, I didn't know about the prune. Normally I just use webpack and serverless framework and run the optimisations on webpack itself. but the deployment package has to restrict to 500MB I think you mean 250Mb. From the docs, the deployment package can be: 50 MB (zipped, for direct upload) 250 MB (unzipped, including layers) 3 MB (console editor) or now up to 10Gb if you are using a container image.