A part of our system I inherited uses API Gateway to call Lambda functions. The gateway accepts request from a React front-end, then the Lambda functions make calls to an RDS database in a private subnet of our VPC for data. Meanwhile, the app also uses CloudFront to serve content backed by an S3 bucket. We deploy the React code to the same bucket.

In the end, this turns out to be an absurdly complex and difficult to manage architecture. We used the Serverless Framework to handle deployment of API Gateway and Lambda -- this uses CloudFormation to produce and manage all the services. But we also have a bunch of other parts Serverless isn't handling (network, certs, load balancers, vpcs, etc), so we use Terraform for that. Getting a functional and repeatable deploy process was a massive effort.

In our new architecture, we have a Python (Django) back-end that securely provides the API via a container in ECS running on Fargate, with data from a serverless RDS. The content and React code live in a bucket fronted by CloudFront. All can be deployed with a little terraform to extend our current infra, and new builds deployed simply using GitHub Actions.

This is all vastly simpler than the previous architecture, just as or more secure than Gateway, far more rationally composable and discretely deployable. Because it's all in containers, it's also simple to develop locally. There's nothing we can't do with our API, and that was absolutely not the case with the numerous sneaky constraints of API Gateway.

Honestly, I don't see a single valid use-case for API Gateway, and see only the thinnest special-case uses for Lambda. Containers provide nearly all of the purported advantages of serverless Lambda.