In yesterday’s post, I went over how to run a little static site (the one where you are reading this) in CGP following their guide.

After finishing the setup, I had the feeling that at least the load balancer (LB) was going to have some cost. I was right. Checking the billing today, I could see how the LB will incur daily charges even with very low traffic. Calculating the cost of the LB is indeed tricky. The pricing is quite complicated, and you need to take into account multiple factors. I will show ways to eliminate the cost of it in this post.

Not only that. Looking at the quite-limiting free tier in GCP, I realized the Could Storage free tier only applies to US region buckets. Below I will describe how I moved the bucket I created in europe-west3 to us-east1 to make sure the little storage I need will be included in the free tier and remove the Load Balancer.

Moving a bucket to a different region

If your bucket is empty, the best is to delete it and then create a new one in the new region. If, like my case, you already have data in the bucket, you will need to create the new bucket in the new region and transfer the data before deleting the current bucket. Bucket names are unique; if for any reason, you need to reuse the name, which again is my situation, you will need to use an intermediate bucket for your data.

In my case, as mentioned above, I want to have the same bucket name but in a different region. Luckily, I don’t need to move the data in the bucket because I can reupload the site as easily as I update it. That saves me the hassle of creating an intermediate bucket.

First, I removed the bucket using the console. It was the first time deleting a bucket in GCP for me, and the console is more forgiving if you are still learning. Yesterday, I created the bucket using the console. This time, I decided to use the CLI. Running gsutil mb -l us-east1 -c standard -b on -p notes-nestorlafon-com gs:// creates the bucket with the configuration needed. Careful, the guide doesn’t have the same parameters as my command; some of them are the default value, but others, like -p are needed unless you have a configuration file for gsutil. Once the bucket is created, you want to make it public. The CLI command for that is simple gsutil iam ch allUsers:objectViewer gs://

Next is uploading the site again. For that I decided to give a try to the rsync option with the command gsutil rsync -d -r _site gs:// It spits some warnings, but it seems to do the expected job. The -d option is to delete files not present in the source.

One last step before verifying that everything is working as expected is to set up the bucket for acting as a website. For that, I used the command gsutil web set -m index.html -e 404.html gs://

After that, was working again as expected from a bucket in a different region.

Removing the Load Balancer

To be able to remove the load balancer, as I explain below, your site needs to be served from a subdomain, in my case notes in `, and you should be ok use insecure HTTP for it. If you plan to run any serious website, it is better to stick to pay for the LB and an SSL certificate for your HTTPS connection.

In the console, if you go to your bucket, and click on one file, you will see that the public URL look like You can rewrite it as and it will still work. Note that the second link uses HTTP and has the bucket’s name as part of the domain. That’s what makes possible the next step.

Now you can go to your domain registrant and change the DNS configuration. Delete the old A entry for your subdomain and create a new CNAME entry pointing to your bucket domain. In my case, notes pointing to

Now you can remove the LB. I went to the console, selected the LB, and press delete. It will prompt you to remove the backend bucket. Tick that box; deleting that backend bucket won’t affect your storage bucket, as it is only part of the LB configuration.

There you go. Your static site is running for free in GCP.

Amendment a few days later

Accidentally, I found Google was still billing me some cents per day. Looking at the billing details, this was due to Static IP Charge in Compute Engine. But looking in the console section for Compute Engine showed nothing. After a bit of reading, I found that I could use gcloud compute addresses list to see all addresses used in that project, and in the same document, I found that external static IPs are reserved in the VPC Network. Once there in the console, deleting the IP is a couple of clicks away. I didn’t request that IP, most probably it was needed for the Load Balancer. It wasn’t gone when I removed the Load Balancer as it is not part of it. I wish Google was smarter and notify you that you deleted the last resource using that IP reservation.