I'll do my best to keep it short and to the point but you really could read dozens of books on this and still not know where to start.
From a enterprise design objective you are needing to learn about what's called "n tier architecture" Basically you have separate layers and tiers that will provide the isolation and separation of components. For example you could have a presentation tier running a web server like NGINX, which depending on the customer's use can run some types of websites or act as a reverse proxy to the application tier. If there is an enterprise application involved then it should be in a application tier where it would run on it's own dedicated resources and middleware like WebSphere application server or JBoss EAP. Then for the database tier place your database(s) here with their own resources.
It could look like this:
Pres. Tier (Apache/NGINX) <--> App. Tier (WAS/JBoss)
<--> Database Tier (Oracle/Postgres/SQL)
You do want to keep these VM's separate because if you combine roles within a single VM and it get's compromised then they have access to everything that node has VS just a web server because the application and database tiers aren't exposed externally, just the presentation tier. This means if that box get's hacked then they would have to break into the application server next and hop from there to the database server because there is no connectivity from the presentation to the database tiers.
Then each node should also be hardened using some sort of framework like NIST 800-53 or 800-171. Don't let it overwhelm you, just take you time implementing, testing and scripting the needed changes and create GPO's and pre-hardened images. Also if you are not under any particular requirements you could loosely apply what fits best within your organization. CIS-CAT is another framework and they have some basic free tools but to get all system types done you may need to buy a membership.
After the hardening you should consider at a minimum having a vulnerability scan performed to see what your low hanging fruit is. Then after all that is mitigated then work on getting a pentest performed to find any vulnerable code. Pentesting may be overkill for your clients, but if you look at banks and other large companies they do this regularly to make sure that their code and middleware stack has the least amount of attack surface as possible.
Other considerations may be that you design several NGINX servers to load balance the user connections using "sticky sessions" so that you could in theory patch, reboot, rebuild and replace a VM behind the load balancer's providing some form of redundancy and higher availability or even High Availability (HA).
This is just the tip of the iceberg but should be enough to get you started on your design. If you are buying new hardware you may want to consider looking into Dell VRTX chassis with blades. You could have 2 of these at separate data centers and perform full redundancy and failover. Or just get one with 2 blades and run a clustered host. Just fill with RAM and drives and load your preferred virtualization hypervisor and build your cluster. If on a budget Ubiquiti has affordable networking gear but their FREE support is chat based only. Otherwise Cisco is the "Gold Standard" but you pay for TAC support and annual renewals or you don't get security updates or phone support which if you don't have the budget for it then stay away from it.
Lastly, I would try to boil down a few more things. You need to determine the budget and what are the requirements from EACH of your 300 clients and can some of them share hosted space (Think shared hosting plan) when performance isn't the top priority and does that open any security holes that another customer may not allow. What the clients want may not be realistic at their price point even with a cloud provider because when you get a VM you don't get any hardening or security management so you are still responsible for it. With security it is like a sliding scale teeter-totter with usability. If it's completely usable then it's not secure, but if it's completely secure then nobody can access it. You will need to determine where you need to be for this and it may be different for different clients. There is no silver bullet to these things. Most developers do not consider security as part of their development so plan on things breaking as you become more secure. The broken items can be fixed with proper coding and or architecture design.
