Why does Google Cloud Platform recommend using HTTPS behind a load balancer

health checks managed instance groups VS health checks load balancing

The health checks used by managed instance groups are the same health checks used by load balancing, with some differences in behavior. Health checks that you apply to load balancing services help a load balancer determine where to direct network traffic. These health checks do not cause Compute Engine to recreate instances. Health checks that you apply to managed instance groups will proactively signal to the managed instance group to delete and recreate instances if they become UNHEALTHY.

For the majority of scenarios, use separate health checks for load balancing and for monitoring managed instance groups. Health checking for load balancing can and should be more aggressive since these health checks determine whether an instance receives user traffic. Since customers might rely on your services, you want to catch non-responsive instances quickly so you can redirect traffic if necessary. In contrast, health checking for instance groups will cause Compute Engine proactively replace failing instances so you could create health checks that are more conservative than health checks for a load balancer.

https://cloud.google.com/compute/docs/instance-groups/creating-groups-of-managed-instances#monitoring_groups

On Google’s Global HTTP Load Balancer, each HTTPS target proxy is linked to a certificate. You can use the gcloud tool (pre-installed on GCE images) to update your target proxies with new certificates. But make sure that:

• Your version of gcloud is relatively recent. The target-https-proxies commands were only recently added, so they aren’t present in older versions of gcloud. (Not to be confused with target-http-proxies, which manges plaintext HTTP sites)
• Your renewal server has API access to Compute Engine resources. You can configure this in your GCE templates, or on a instance-by-instance basis.

You can query gcloud for the current certificate, to check if it’s about to expire. If it is, you can upload your new certificate, then use the target-https-proxies update command to switch over to the new certificate. You won’t see the changes immediately, but soon, the renewed certificate should be installed globally.

There’s a usage quota of 30 SSL certificates (at least on my account). But if you aren’t too aggressive with your renewals, you won’t have any problems even if your renewal script doesn’t clean out expired certificates. It’d be a good idea to keep around at least 1 old certificate, just in case something goes wrong and you need to revert.