I was only talking about function code. It should be painfully obvious to anyone that if you opt to leverage other AWS services that those are things you would ultimately have to replace but those decisions have nothing to do with serverless.
> but those decisions have nothing to do with serverless.
Sure they do.
Because if you need a DB for persistence you are either setting up a server for it (and therefore not serverless, even if part of your system uses a Lambda) or consuming a serverless DB service. And so on for other parts of the stack. On AWS, for DB, that might be Dynamo (lock-in heavy) or, say, Aurora Serverless (no real lock-in if you don't use the RDS Data API but instead use the normal MySQL or Postgres API, but that's higher friction—more involved VPC setup—to use from Lambda than RDS Data API is, so the path of least resistance leads to lockin.)
Lambda or other FaaS is often part of a serverless solution, but is rarely a serverless solution by itself.
