It's a little more complex when the site is not 100% static. Even a contact form requires a server.
But I do think there should be a good separation between html and admin backend. Security is only one reason. There are other very important reasons:
1. waste of resources. the machine that builds the html from the cms is completely idle for 99% of the time.
2. scalability. the html should be served from a storage server like S3 together with a CDN. there should be absolutely no downtime in viewing html as a result of overload.
the ideal system for small websites is a machine that is turned off by default, and when an admin needs to change something it is turned on (even if it takes a whole minute). After the changes are committed, the system creates html and sends to S3. For forms, comments, and dynamic things it's best to use third-party (like facebook comments and a billion forms services), or use a different small machine that captures user input (completely separate from the turned-off admin machine).
> A separate machine/VM is better from an availability perspective.
How so? A separate machine is one more thing that can fail and since it isn't web facing it won't help with availability if the other one fails. And if it is a VM they will both go down if the underlying hardware fails.
Its true that a separate machine is one more thing that can fail, but if its purpose is so different, as with the "active CMS" - "static hosting service", then it becomes easier to create a replacement.
E.g. the frontend can be replicated (if needed), S3 can be used, while the backend CMS remains intact. Or the backend CMS can be implemented in a HA setup and the static hosting in the cloud.
But I do think there should be a good separation between html and admin backend. Security is only one reason. There are other very important reasons:
1. waste of resources. the machine that builds the html from the cms is completely idle for 99% of the time.
2. scalability. the html should be served from a storage server like S3 together with a CDN. there should be absolutely no downtime in viewing html as a result of overload.
the ideal system for small websites is a machine that is turned off by default, and when an admin needs to change something it is turned on (even if it takes a whole minute). After the changes are committed, the system creates html and sends to S3. For forms, comments, and dynamic things it's best to use third-party (like facebook comments and a billion forms services), or use a different small machine that captures user input (completely separate from the turned-off admin machine).