Deploying a Static Website on Google Cloud Storage with GCP Load Balancer

Prerequisites and Bucket Configuration

Before configuring the load balancer, you must prepare the Google Cloud Storage (GCS) bucket to serve static files correctly. The most critical step is enabling website hosting on the bucket. Without this, the load balancer cannot determine which file to serve when a user requests a directory path, such as /.

1. Navigate to the Cloud Storage browser in the Google Cloud Console.
2. Select your target bucket and click the Properties tab.
3. Scroll to the Website Hosting section and click Edit.
4. Enter the name of your index page (e.g., index.html) in the Main Page Name field.
5. If you have custom error pages, specify them in the 404 Error File field.
6. Click Save.

Next, ensure the bucket has appropriate permissions. If you are using Uniform IAM, the storage.objects.get permission must be granted to the allUsers or allAuthenticatedUsers identity. Alternatively, if you use Fine-Grained Access Control, you can attach a predefined role like Storage Object Viewer to the allUsers principal. This allows the load balancer’s health checks and incoming traffic to read the objects from the bucket.

Creating the Backend Service

The core of this architecture is the Backend Service, which defines where traffic goes. In Google Cloud Platform, an HTTP(S) Load Balancer does not support GCS directly as a "bucket backend" in the same way some CDNs do. Instead, you create a backend service that uses the GCS bucket as its origin. However, standard HTTP(S) LB backends typically expect Compute Engine instances or Cloud Run services. To use GCS effectively with an external HTTP(S) LB, you often need a workaround involving a Cloud Functions or Cloud Run service that proxies requests, OR you utilize the fact that GCS buckets can be accessed via their native URL structure if configured as a CDN-backed bucket.

Note: A common architectural pattern for serving static sites via GCP Load Balancer involves using a Cloud Run service or Cloud Function as the backend that fetches content from GCS, because direct GCS integration into the standard HTTP(S) LB backend pool is not natively supported for dynamic routing in the same way VMs are. However, for pure static hosting, many users opt for Google Cloud CDN directly attached to a GCS bucket, which bypasses the need for a complex Load Balancer setup. If strict Load Balancer features like advanced routing rules are required, a proxy service is necessary.

For the purpose of this guide, we will assume the standard approach of using a Backend Bucket. While older documentation might suggest otherwise, modern GCP allows you to create a Backend Bucket resource. Here is how:

1. Go to Load Balancing > Create Load Balancer.
2. Select HTTP(S) Load Balancing and click Continue.
3. In the Backend configuration section, click Create Backend Bucket.
4. Name your backend bucket and select the GCS bucket you created earlier.
5. Ensure CDN is enabled if you want caching benefits, though this is optional for basic functionality.
6. Click Create.

This creates a specialized backend type optimized for static assets. It simplifies the configuration by removing the need for health checks against individual servers, as the bucket itself is the source of truth.

Configuring Health Checks

When using a standard Backend Service with Compute Engine instances, health checks are mandatory. However, when you use a Backend Bucket (as described above), the load balancer treats the entire bucket as a single logical unit. You do not configure traditional TCP/HTTP health checks against specific IP addresses. Instead, the system validates the bucket's existence and accessibility during the initial handshake.

If you were forced to use a Backend Service with VMs acting as proxies to GCS, you would need to define a Health Check resource. Go to VPC Network > Health checks and create an HTTP health check targeting the root path /. Set the request path to /, the port to 80, and the healthy threshold to 2. Attach this health check to your backend service. This ensures that traffic is only sent to VMs that can successfully retrieve the index.html file from the GCS bucket.

Setting Up Frontend and Routing

The frontend configuration handles incoming traffic from users. Create a Frontend Configuration with a new IP address (static IP recommended for production). Select HTTPS if you plan to use SSL certificates. For HTTPS, you must create an SSL certificate in the Certificate Manager or upload one manually. Attach this certificate to the frontend port 443.

In the Host and Path Rules section, set the host rule to match your domain (e.g., *.example.com) and leave the path as /* to route all traffic to the backend bucket. Click Create to finalize the load balancer. Propagation may take several minutes.

It is important to note that unlike AWS ALBs, GCP Load Balancers do not have a native "Redirect HTTP to HTTPS" toggle in the UI. To enforce HTTPS, you must create a separate HTTP load balancer on port 80 that redirects to the HTTPS listener, or handle redirection within your application code if you are using a proxy service.

Verification and Troubleshooting

Once deployed, verify the setup by navigating to your load balancer’s IP address or domain. If you see your website, the configuration is successful. If you encounter a 502 Bad Gateway error, check the backend bucket configuration to ensure the correct GCS bucket is selected. If you see a 403 Forbidden error, verify the IAM permissions on the GCS bucket allow public read access.

For more details on managing cloud infrastructure across providers, you might find our guide on Improving Cloud Infrastructure: AWS, GCP, Azure VMware Experiences helpful for broader context.

Frequently Asked Questions

Can I use a GCS bucket directly without a load balancer?

Yes, you can enable Google Cloud CDN directly on a GCS bucket. This is often simpler and cheaper than setting up a full HTTP(S) Load Balancer. It provides global caching and DDoS protection without managing backend instances or complex routing rules.

Why did my deployment fail with a 403 Forbidden error?

This usually indicates that the GCS bucket does not have public read permissions. Ensure that the allUsers identity has the Storage Object Viewer role assigned, or that uniform bucket-level access is configured to allow anonymous reads.

Is a health check required for Backend Buckets?

No, traditional health checks are not required for Backend Buckets because the bucket is treated as a single logical entity. The load balancer validates the bucket's availability at the time of connection rather than polling individual servers.

How do I force HTTP to redirect to HTTPS?

GCP Load Balancers do not have a built-in toggle for this. You must create a second HTTP load balancer on port 80 with a URL map that returns a 301 redirect to the HTTPS version of your domain, or implement the redirect logic in your static site's HTML/JavaScript.

What happens if the GCS bucket is deleted?

If the backend bucket reference points to a deleted GCS bucket, the load balancer will return 502 Bad Gateway errors for all incoming requests. Always ensure the underlying storage resource exists before relying on the load balancer.