Virtual load balancer
with health checks and SSL

Only if your application stores session state on the VM itself. If sessions live in a cookie, a token or a shared store like Redis, any VM can handle any request, so round-robin or least-connections spreads load better and a failed VM doesn’t lose anyone’s session. Opt for sticky sessions when the app genuinely keeps state locally.

Because when the balancer terminates TLS, the connection your VM sees comes from the balancer. Turn on proxy protocol and the real client IP is passed through, so your logs, rate limiting and geolocation work as expected. If you pass TLS straight through instead, the client IP arrives directly.

Use the pool. Take one VM out of rotation, or let it fail its health check, deploy to it, return it, then move on to the next. Because the virtual load balancer only routes to healthy VMs, there’s always an instance serving traffic, so a rolling deploy across the pool never has to drop a request.

Yes, and it’s the recommended setup. Keep your VMs on a private network with no public addresses, put the virtual load balancer in front, and use firewall rules to allow traffic only from the balancer. Your application servers are then never directly reachable from the internet.

As many as your service needs. You add VMs to the pool as traffic grows and remove them when it falls, and one balancer fronts the whole pool behind a single address. For separate services or ports, run a balancer for each rather than overloading one.

Yes. A load balancer is £10/month for as long as it exists, regardless of how much traffic flows through it, since it’s holding the address and health-checking your pool the whole time. It’s a flat per-balancer charge rather than usage-based.