Hosting a static website on Google Cloud using GCS is pretty trivial.

Here I will describe two approaches, depending on your needs:

1. HTTP only. Cheap and easy.
2. HTTPS required. Slightly more complex and and a little more expensive.

HTTP Only

This approach is a cheap way to host a site. You only pay for Cloud storage, and the cost is virtually nothing.

This is possibly fine if you want to serve static content, and you don’t need your users to send any data to you. For example, if they do not need to submit any forms, provide any sensitive information, and so on.

But bear in mind that many users will NOT proceed to your site if they see a browser warning that the connection is not secure.

Strategy

• Create a GCS bucket to store your static web content.
• Make the bucket available to public.
• Create a DNS C record (alias) with your domain registrar, to point your domain to the Google Cloud Storage API.

Detailed steps using the Cloud Console and Google Cloud CLI

From the Google Cloud Console, create a project to store your bucket.
Cloud Storage → Buckets → Create

Bucket setup:

• Name the bucket, using your website’s domain name, e.g. “foo.mydomain.com”. If you haven’t yet done so, you will need to perform verification steps that you own this domain.
• Choose where to store your data. (Regional is cheapest.) Choose your storage class. If you expect your site to be accessed often, select “Standard”.
• Turn off “Enforce public access prevention on the bucket”.
• Leave access control as “Uniform”, assuming you don’t want to restrict access to specific files in your site.
• Click Create.

Make your bucket available to public. Click on the “Permission” tab, then “Grant access”:

Then we’ll add the principal allUsers and assign the role Storage Object Viewer:

You’ll then be prompted to confirm you want to “Allow Public Access”. You should accept this.

Upload your static website content to the bucket. Let’s say that all your site content is in a folder called “public”. The easiest way to upload is simply to use the “Upload Folder”:

Now you have a folder called public in the root of your bucket:

But what if we didn’t want the bucket folder? What if we wanted the contents of the bucket folder to be in the root of our bucket. No problem! Let’s just use the gsutil command in the Cloud Shell to move our content.

Open Cloud Shell:

In the Cloud Shell, run the gsutil command

gsutil mv gs://foo.example.com/public/* gs://foo.example.com/

Now let’s tell Cloud Storage that this is a website, and which page it should use when we go to our domain. From the Buckets page, use the More actions dropdown, and select “Edit website configuration”.

Now enter your default page, e.g. index.html .

Finally, you need to go to your domain name provider, and create a DNS CNAME record that points to c.storage.googleapis.com. I happen to use Ionos. So this is what it looks like in Ionos, if I were to create a new CNAME record for the subdomain foo.example.com:

And that’s it! If you now visit foo.example.com, you’ll see your site!

HTTPS

Generally, this is the approach you’ll want to take. But it costs more, and takes a bit more effort to set up. The additional Google Cloud products that you need — such as static external IP address, load balancer, and managed certificate — are what increases the cost. Using this approach, you can expect to pay… Maybe £0.50 per day in total. (Assuming you don’t have millions of visitors!)

Strategy

• Create a GCS bucket to store your static web content.
• Make the bucket available to public.
• Create a VPC network and subnet to store a load balancer.
• Create an HTTPS load balancer.
• Reserve an external IP address, and attach it to the load balancer frontend.
• Attach a Google-managed SSL certificate to the load balancer proxy.
• Attach the bucket as the load balancer backend.
• Create a DNS A record with your domain registrar, to point your domain to the external IP address.

Detailed steps using the Cloud Console and Google Cloud CLI

First, create the bucket, just as described above for the HTTP steps. The only difference this time is that the bucket can be any unique name you want, but should NOT be named after your domain. E.g. my-foo-site-bucket.

Make the bucket publicly available to allUsers , using the same instructions as above.

Upload your static site content, and set the default home page, using the same instructions as above.

Now things will deviate a bit.

We need to create a network to host our load balancer. We can easily do this from the Cloud Console:

VPC Networks → Create VPC Network.

Here, I create a VPC network called “foo-proxy-network”, with a new custom subnet called “proxy-subnet”. I’ve set up this subnet to use the CIDR block 192.168.0.0/24.

Now we create a new HTTPS load balancer:

• Network Services → Load Balancing → Create Load Balancer
• Select HTTP(S) load balancing
• “From internet” and “Global HTTP(S) load balancer”

Load balancer frontend configuration:

• Name the frontend. E.g. foo-lb-frontend.
• Set protocol to HTTPS.
• IP Address → Create (reserve) a new static IP address.

• I’ve called the IP address “foo-ext-ip”.
• Now we need to create an SSL certificate, which will be used to encrypt your traffic.
  Certificate → Create a new certificate.
  Name it, e.g. “foo-cert”. Select “Create Google-managed certificate”. And then supply your domain, e.g. “example.com”.

Load balancer backend configuration:

• Create a backend bucket. Name it, e.g. foo-backend-bucket. Then, select the Cloud storage bucket we created above.
• If you expect lots of traffic, you can optionally cache your content using Cloud CDN. This service has a cost, but it’s worth it if you expect to serve a lot of traffic.

Finally, Create the LB.

Load balancer provisioning takes a few minutes, and attaching a the certificate can take an hour or so.

The final step (which you can do whilst you’re waiting for the LB) is to create a DNS A record, to point your DNS name to your new external IP address. I’m using Ionos as my domain name provider. So for me, it looks like this:

And that’s it! You are now serving a secure website, through an HTTPS load balancer!

Links

This blog is also published at Medium.