That’s not an in-memory cache either. AIUI it’s storing those artefacts to disk

Container sizes may be affected though.

So you're now weighing the increased container pull time (due to size) vs the class load time you're saving through the cache.

It's nice to at least have the option of making that tradeoff

(And I suspect for plenty of applications, the class cache will be worth more time than (an also probably cached) image pull)

If you’re deploying Java applications, container size isn’t exactly your first priority anyhow, and this is O(n) additional space.

If image size is a concern, I imagine a native binary using GraalVM would’ve been a better way out anyhow, and you’ll bypass this cache entirely.

RAM might be inexpensive, but this hasn't stopped cloud providers from being stingy with RAM and price gouging.

At current RAM prices you'd expect the smallest instances to have 2GB, yet they still charge $4/month for 512MB, which isn't enough to run the average JVM web server.

That is pretty ridiculous complaint. Your problem is that they allow configuring instances smaller than your arbitrary baseline? Especially as AWS allows you to pick 2/4/8 GB per vCPU for general purpose instances. And the smallest of these (c7g.medium) is 2GB/1vCPU. The .5 GB t4g.nano has actually more generous ratio because it also has only .1 vCPU, putting it at 5GB/vCPU.

I'd assume they are very aware of demand levels for different types and would be adjusting the configurations if needed.