Earlier quoted context omitted.
Hosting IMDS on the host side is pretty much the only reasonable way to provide stability guarantees. It should still work even if the network is having issues. That being said, IMDS on AWS is a dead simple key-value storage. A competent developer should be able to write it in a memory-safe language in a way that can't be easily exploited.
“No, there is another”—Yoda, The Empire Strikes Back :) What you describe carries the risk that secrets end up in crash dumps and be exfiltrated. Imagine an attacker owns the host to some extent and can do that. The data is then on disk first, then stored somewhere else. You probably need per-tenant/per-VM encryption in your cache, since you can never protect against someone with elevated privileges from crashing or…
But if you're within the classic hypervisor model, then it doesn't really matter that much. The attack surface of a simple plain HTTP key-value storage is negligible compared to all other privileged code that needs to run on the host.
Sure, each tenant needs to have its own instance of the metadata service, and it should be bound to listen on the tenant-specific interface. AWS also used to set the max TTL on these interface to 1, so the packets would be dropped by routers.