Related: Hellerstein et. al's paper evaluating the limitations of serverless frameworks for different use cases. (https://blog.acolyer.org/2019/01/14/serverless

Related: Hellerstein et. al's paper evaluating the limitations of serverless frameworks for different use cases. (https://blog.acolyer.org/2019/01/14/serverless-computing-one-step-forward-two-steps-back/ https://blog.acolyer.org/2019/01/14/serverless-computing-one...) tl;dr FaaS lifetimes, lack of cache locality, network rates and isolation make serverless platforms great only for embarassingly parallel, short-lived, I/O-bound tasks that don't require high performance and are only occasionally run. Anything else will be more expensive and slower than just maintaining your own server. Lambda thus would be perfect for irregular batch jobs or orchestration tasks. Trying to serve an API isn't advisable because of the low-latency requirements. On a tangential note, AWS Lambda is actually insufficient to serve an API by itself - you also need to use AWS API Gateway to serve incoming requests, create your own route tables and dedicated subnets if you need to allow VPC access, enable Cloudtrail logging and monitoring (very limited), and add IAM rules to allow all of these to interoperate. It is not a turn-key solution by any means. Add to this the limits on deployment artifacts (50 MB max), and you've basically done all the work needed to launch your own EC2 instance in its own subnet and availability zone, but resulting in something with smaller capacity and worse observability. Use a server, dammit.