What I've found people really want when they say "serverless" in this context is, "direct file upload without a proxy server", which is basically what BaaS' lik

What I've found people really want when they say "serverless" in this context is, "direct file upload without a proxy server", which is basically what BaaS' like Firebase and Parse do... <pitch> Firebase Storage (https://firebase.google.com/docs/storage/ https://firebase.google.com/docs/storage/) provides clients that perform secure, serverless uploads and downloads. Instead of doing the dance with a server minting signed URLs, it uses a rules engine that lets developers specify declarative rules to authorize client operations. You can write rules to match object prefixes, restrict access to particular user or set of users, check the contents of the file metadata (size, content type, other headers), or check a current file with the prefix to not overwrite it. If HackerNews formatting were more forgiving of code snippets, I'd post one here, but instead have to link to the docs (https://firebase.google.com/docs/storage/security/secure-files https://firebase.google.com/docs/storage/security/secure-fil...). We've found that this model is more performant and less expensive (no need for a proxy server), as well as lower cognitive load on developers, as they think about what they want the end result to be, rather than how they need to build up the end result. And since I know people will bring it up: there are definitely limitations in flexibility (you're using a DSL), and a steeper learning curve for the very complicated use cases. The goal here is make it trivial for 90% of use cases and possible for 9%; rather than making it possible for 100% and equally difficult for everyone. Tradeoffs... </pitch> And if you want other examples, Parse did a similar thing with role based access control to a Parse File, allowing direct client upload and access by only a set of users. S3 and GCS can do this as well, assuming their (relatively coarse) IAM models are granular enough for you (and you're a authorized principle in their systems, which is often the harder thing). Bringing this full circle, "serverless" typically involves a switch from writing code (imperative) to writing config (declarative). You're not validating JWTs signing URLs, or writing middleware, you're letting services know how to configure those primitives for you. In some ways the Serverless framework does abstract this for you (hey look, I didn't provision a VM), and in some ways it doesn't (you still wrote code to generate a signed URL). Disclosure: I built Firebase Storage