Containers are more about abstracting away kernel state tables, but not deeper env like processor arch. You can see this in how there was a lot of work into deploying aarch64 containers over the past year to support M1 docker.
And lambda is more about changing the process lifecycle from traditional always using resources. Sort of the inetd for hyperscalers.
The whole arch64 and docker is my point. I use docker to abstract that pain so I don’t have to care about (to a certain degree). If all of sudden, I need to worry about my underlying arch, then I might as well run on VMs. For lambda, it’s more of a micro-OS anyway than a generic docker container.
I'm not sure what you mean by not caring about underlying arch. With docker you use an arch-specific image. The author may transparently provide multiple arch versions of the image, but I wouldn't call it abstracting. (not in the sense fat-binaries do for example) Specifically, if you then make your own app image on top of the base one, it will again need to be built for each architecture separately.
Docker explicitly doesn't abstract aarch64. That's why it took tons of work to build up the ecosystem this far and even then and still you'll come across public images that aren't multiarch.
And lambda is more about changing the process lifecycle from traditional always using resources. Sort of the inetd for hyperscalers.