Where the cluster needs to be spaced out will depend a bit on the usage pattern and complexity. There’s an available resource model which you can use for sizing larger clusters on github, but I believe it presumes that you are isolating VM’s into services, and I think it’s generally used more on the “Tens of thousands of users or more” scale, so the baseline resource sizing might be overly large. I think at a smaller scale the swings in utilization can be so big that it’s hard to do better than a heuristic guess based on which services are in use (IE: If you are doing high volume SMS, you will need more celery workers).
In particular for most environments the primary scale factor is form submissions, do you know what your expected usage is there? 800 users submitting 6ish forms a day is roughly the same as 200 users submitting 24 forms per day, so it’s more the “forms per month” and “peak form submission / sync” factors that affect sizing. Whether UCR reporting is being used, and how complex the reports are will also affect resource usage.
We do generally recommend having a VM Per Service, although the overhead of that can be high for a small cluster. It’s especially helpful to use VM-Per-Service for services which want to saturate their resource usage, like Elasticsearch, min.io, and Postgres. With some teams I’ve worked with using smaller clusters the first target for breaking out onto its own resource set has been Postgres, since having less contention on the core DB machine helps prevent cache churn, and the PG machines generally make good use of OS paging.
Last question: Do you have monitoring set up? HQ supports metrics reporting and monitoring through both Datadog (for in the cloud) and Prometheus (on-prem), both of which provide excellent insight for resource utilization and saturation.