Don't Run Multiple Services In One VM
Instead run each service in a smaller VM.
Why?
First, if you cram multiple services in one VM, when you hit a bug, such as one that results in 100% CPU consumption till the VM is restarted, all services running in that VM are affected, rather than just one. Figuring out which service has the bug is also harder. As is understanding how many resources each service needs. As you tune performance, like increasing the Java heap size of one service, it could affect other services.
Second, when you upgrade global dependencies like the JVM or yum or switching to Amazon Linux 2, you could be upgrading multiple services at once. This is contrary to good DevOps practice, which calls for services to be upgraded one at a time.
Third, running multiple services in one VM makes it easy to get into a situation where each VM is running a different set of services: VM 1 running services A, B, and C, VM 2 running A and C, VM 3 running B and C, etc. This, in turn, makes life harder.
Fourth, running multiple services in one VM makes it hard to autoscale — you have to autoscale all services, whether or not needed.
Fifth, when you have an outage and have SSH’ed in to a VM to debug things, the possibility of inadvertently affecting the wrong service is higher. If you decide to reboot the VM, that again affects all services running in the VM.
Sixth, running multiple services in one VM makes the entire VM stateful if just one service is stateful. Stateful VMs are harder to work with.
Seventh, running multiple services in one VM obscures the logical structure of the system (services), instead making the physical structure (VMs) more prominent.
Eighth, deployments become harder, because of the risk of affecting services that are not being updated.
For all these reasons, run each microservice in a separate VM, rather than co-mingling them.