Part 1: Sustainable hosting
If you want to do something about climate change, and you happen to use some computational resources on the Internet, then perhaps you should check if these computational resources are running on renewable energy.
The Green Web Foundation has a tool for that. Go check it out at https://www.thegreenwebfoundation.org/
Now, I tried it, and noticed that I didn’t get the green certificate I desired. So I started looking for ways to fix it. This is the first post about the things I encountered along the way.
A couple of things you need to know first. My web site is statically generated and then uploaded to S3. And I was running in the Virginia region. Don’t ask my why. I don’t even remember it anymore.
Now, it seems that Virgina is not running on renewable energy only, and Amazon’s web site doesn’t state explicitly that it is compensating for its use of non-renewable energy in the Virginia region. It does however explicitly state that for a few other regions:
So I figured I would move my S3 hosted site over to Frankfurt instead.
Moving an s3 hosted site over to another region requires a little more effort than just clicking a few buttons. In fact, I’m pretty sure I did it all wrong, taking down my web site for hours, so this write-up is mainly to help you to do it in the right way.
How it should have been done
Step 1: Before
Before I changed anything at all, this is what I had: a bucket in the Virginia region not using renewable energy or not compensating for its lack of using renewable energy, CNAME DNS entry sending all
www.eastpole.nl traffic to that bucket and a forwarding rule forwarding
eastpole.nl traffic to
Step 2: Create a green replica
If you want to start hosting your files from a ‘green’ region, you obviously need to create a bucket in that region. Unfortunately, these buckets cannot be named the same, and you do want to avoid downtime. What I did is create a new bucket that is named differently:
green.eastpole.nl. I also created a new CNAME record pointing to that new bucket. And I copied the entire contents of the bucket over.
In the new situation,
www.eastpole.nl would still take you to the old Virginia based bucket, but
green.eastpole.nl would take you to the new bucket. Technically, you have a replica of your existing site, running at a different address.
Step 3: Reroute traffic to the replica
Next, I needed to route traffic to the replica. However, that’s not something you achieve easily by simply changing the CNAME
www.eastpole.nl record to point to the
green.eastpole.nl bucket. Doing that would break the mechanism that S3 relies on for serving web content from an S3 bucket. The rule is that the DNS name needs to correspond with the bucket name.
However, I can forward traffic for
www.eastpole.nl to the new
green.eastpole.nl domain. And that’s what I did. I first added forwarding rules for
www.eastpole.nl, and then I removed the CNAME record for
As a result, entering either
www.eastpole.nl now would result in you being redirected to
green.eastpole.nl, which would get served by the new green bucket. Still, the URL in your browser would read
green.eastpole.nl, which is not what I want.
Step 4: Relocate the original
The problem is, if you want
www.eastpole.nl as the actual domain, and if you want to stick to S3, then you must have a bucket named
www.eastpole.nl. The obvious solution is to actually create that bucket, in the right region. Keep in mind though that you cannot simply move the bucket. You need to delete it, and then recreate it somewhere else.
It’s also important to know that deleting
www.eastpole.nl will not automatically free up its name. It takes an hour or longer for the name to be released (WHY, Amazon, WHY?!?). So it takes more than an hour to recreate it in the green region.
To be fair, all of the previous steps actually take more time than you might expect. The thing is: it always involves changing DNS entries, and DNS changes take a while to percolate through the network.
Step 5: Restore the routes
We’re almost there. All I had to do next is change the DNS entries again. I removed the
www.eastpole.nl forwarding rule to make sure I could add a CNAME record for it, pointing to the new bucket with the original bucket name. Now traffic for
eastpole.nl would get forwarded to
www.eastpole.nl, which in turn would route the request to the
www.eastpole.nl bucket. All that was left to do is to get rid of the temporary
green.eastpole.nl bucket and CNAME record.
TL;DR How it all went wrong
I was working my way through all of the steps, and then this is where it all went wrong in my case: I changed the CNAME record of my DNS registry to point to the green.eastpole.nl bucket. At first it seemed fine. But then I got errors in my browser. Apparently your domain name needs to correspond to the bucket name. I couldn’t point the CNAME record for www.eastpole.nl to the green.eastpole.nl bucket.
So, the site was broken. And I only found out the day after. Super annoying. In an effort to fix it, I tried to delete the existing www.eastpole.nl bucket and recreate it in the Frankfurt region. However, after deleting it, Amazon refused to recreate it in Frankfurt.
Turns out I am not the first person on the globe running into this issue. I just wished they would have warned me about it up front. (And after I saw this message, I realized I had seen this before, but years ago. Why did I not remember that?) Apparently, it would take at least an hour before I could go ahead and recreate it in Frankfurt.
Did I get a green certificate?
Well, actually, no. I didn’t. It turns out that there the Green Web Foundation is checking locations by IP, and it seems there is an issue there:
Now, to be fair, I don’t care too much about the certificate. I care more about finding other ways to reduce the footprint of the things I do. And even then, there are a couple of things I should start considering first before I considering my sites to be ‘green’. In a next post, I’ll try to address the remaining issues, including how to handle Typekit.