S3-Compatible XML on GCS Tricked Me

I am currently in the process of migrating my old website to this new one. During the migration of my old website, I also decided to clean up long-forgotten DNS records. Over the years, I had added several subdomains — some of which I didn’t even remember creating. Two of them were

extensions.anupshinde.com and content.anupshinde.com

I did not remember why these were created. I had not maintained the website for many years; it had simply remained operational. I’ve written more about that period of neglect in this post.

I was relying on my faint memory. Especially the name extensions sounded like something I might have created as a temporary or trial version. I did not check the full DNS record (the target value). The first thing I do is load the domain on Chrome.

The first thing I notice is s3.amazonaws.com. And I assume it's some AWS storage bucket, and therefore, this subdomain can be deleted. The 2006 version did look odd, but I didn't look into it further.

But why delete AWS-related stuff?

Well, I had an AWS account earlier. I closed my AWS account about a year ago. They implemented some policy changes in Workspaces related to LDAP, which resulted in me being billed for something I had not even used. Amazon support helped me out and reversed the charges. However, it was an account I hadn't used in a year. I had used it for years and wasn't keeping up with their policy changes. It was better to get off AWS completely, so that I wouldn't get billed for something I didn't use. I am more of a user with Google Cloud, and while AWS (being more capable) was not something I enjoyed using. I have also seen horror stories of receiving huge bills overnight from multiple cloud providers, including Google and AWS.

The DELETE action

So, I assumed it was probably some AWS cache - even though it did feel odd to have it up for so long. I thought I could delete the subdomain.

Similarly, with content.anupshinde.com. It still showed the AWS string in the xmlns parameter. It had a lot more content, but I was like - "maybe it's old"

I had migrated the website multiple times before, in the past. Therefore, it was assumed that some features were included for backward compatibility or content that was later not linked.

I go with these actions (still not checking the target value)

extensions.anupshinde.com ==> DELETE

content.anupshinde.com ==> DELETE

Along with a few other subdomains.

Pause and recheck

But then I paused for a moment, my faint memory saying content.anupshinde.com looks useful. I took on two action items.

• Check my website (old-website) links
• Check my GCS buckets

And my gut check was correct. I broke some links to demos on the website, and I had corresponding subdomain buckets on GCS. I use Cloudflare, and the CNAME deletion had propagated fast.

Reversal

The first action was to reverse the deletion. However, I did not note the old target value.

You can do the Cloudflare Audit Logs. Search for "Audit logs" in the Go-To search bar on your.

I found out the actual action and the old content pointing to Google's cloud storage c.storage.googleapis.com. When deleting, I had overlooked this detail, and it was right in my face.

Realization

The whole fiasco started because I thought the subdomain was pointing to a closed AWS account's S3 service.

<ListBucketResult xmlns="http://doc.s3.amazonaws.com/2006-03-01">

I missed out the subtle information that xmlns does not mean where the response is coming from. The 2006 oddity was also something that I registered and missed. As a seasoned developer, it felt both stupid and confusing.

So, I chose to ask ChatGPT to see whether it would fall victim to the same assumption.

And it did! 😏 Suddenly, I am not feeling so bad about it.

So, what did that XMLNS mean?
It states that the XML file adheres to the format specified in the Amazon S3 documentation from March 2006.

And yet it was so easy to miss in a rushed hour and plethora of text.

Why is Google Cloud Storage doing this?

Google Cloud Storage (GCS) supports an interoperability mode that mimics the Amazon S3 XML API.

Read more about it here: Interoperability with other storage providers.