This times and again. If you're hitting an API hosted on a domain you don't control, you're bound to get screwed. Otherwise they would just be able to deploy a simple Firebase API proxy (for the single call that they use) that uses TLS tickets and keep alive, change the DNS records and call it a day.

You wouldn't have clients talk to AWS Lambda directly. You'd put it behind API Gateway, which would allow you to use your own domain in front. Your clients would just know to send requests to https://myapi.mycorp.com.

Since you control the domain, you could then stop something like this more quickly.

yes, this is exactly how it is implemented now

You could then switch to regular servers running an open source Lambda reimplementation e.g. https://github.com/siscia/effe https://github.com/atlassian/localstack etc. Just make sure you can change the URLs everywhere.

Sounds so to me, all that takes is lambda changing how they charge and suddenly your hard-coded app is stuck again.

Solution here is to make sure all api endpoints and URLs used in your code (eg into services such as lambda) get mapped through a domain that you can control / change via DNS. Then you can always cut off a service or redirect all requests to a different endpoint of your choosing (eg another serverless system or your own backend). This is better than hardcoding an unalterable endpoint / url / domain in your code that is beyond your own control, and it is doubly important if updating code on your product is difficult or impossible.

AWS Lambda functions are super portable. You can essentially copy & paste them into a simple express.js app and be up and running in a few minutes.

But, either way I agree. You should always have all requests to any services going through your own domain.