What is the optimal architecture design on Azure for an infrequently used backend that needs a robust configuration?

I'm trying to find the optimal cloud architecture to host a software on Microsoft Azure.

The scenario is the following:

• A (containerised) REST API is exposed to the users through which they can submit POST and GET requests. POST requests trigger a backend that needs a robust configuration to operate properly and GET requests are sent to fetch the result of the backend, if any. This component of the solution is currently hosted on an Azure Web App Service which does the job perfectly.
• The (containerised) backend (triggered by POST requests) perform heavy calculations during a short amount of time (typically 5-10 minutes are allotted for the calculation). This backend needs (at least) 4 cores and 16 Gb RAM, but the more the better.

The current configuration consists in the backend hosted together with the REST API on the App Service with a plan that accommodates the backend's requirements. This is clearly not very cost-efficient, as the backend is idle ~90% of the time. On top of that it's not really scalable despite an automatic scaling rule to spawn new instances based on the CPU use: it's indeed possible that if several POST requests come at the same time, they are handled by the same instance and make it crash due to a lack of memory.

• Azure Functions doesn't seem to be an option: the serverless (consumption plan) solution they propose is restricted to 1.5 Gb RAM and doesn't have Docker support. More expensive solutions, such as the az Functions EP3 plan need to have one instance allocated all the time, hence making that choice not cost-effective and quite similar to the App Service.
• Azure Container Instances neither, because first the max number of CPUs is 4 (which is really few for the needs here, although acceptable) and second there are cold starts of approximately 2 minutes (I imagine due to the creation of the container group, pull of the image, and so on). Despite the process is async from a user perspective, a high latency is not allowed as the result is expected within 5-10 minutes, so cold starts are a problem.
• Azure Batch, which at first glance appears to be a perfect fit (beefy configurations available, made for hpc, cost effective, made for time limited tasks, ...) seems to be slow too (it takes a couple of minutes to resize a pool and jobs don't run immediately when submitted).

So to reformulate a bit: is it possible to have a solution that scales to 0 instance (so really no cost) when there's no backend work to process and that can scale up almost instantaneously (let's say within 1 or 2 minutes) to n instances of a beefy config (let's say 8 CPUs/16Gb RAM)?

Do you have any idea what I could use?

Thanks in advance!

PS: this question follows from the original stackoverflow post: https://stackoverflow.com/questions/71411555/what-is-the-optimal-architecture-design-on-azure-for-an-infrequently-used-backen/71413699#71413699