Update May 09 06:17 EDT: Added Amazon's reply to the users' feedback to the original S3 path deprecation plan at the end of the article.

Amazon announced in a post on the Amazon Simple Storage Service (S3) forum that the company will deprecate path-style API requests (used by many to circumvent censorship) starting with September 30, only keeping support for the virtual-hosted style request format.

While the path-style URI requests (aka V1) include the bucket name in the URIs and are of the "//s3.amazonaws.com/[bucketname]/key" form, the virtual-hosted style URI requests (aka V2) feature the bucket name within the domain name and have a "//[bucketname].s3.amazonaws.com/key" structure.

"In our effort to continuously improve customer experience, the path-style naming convention is being retired in favor of virtual-hosted style request format," says Amazon.

Amazon recommends customers to start using V2 S3 API requests before V1 will be disabled on September 30:

Customers should update their applications to use the virtual-hosted style request format when making S3 API requests before September 30th, 2020 to avoid any service disruptions. Customers using the AWS SDK can upgrade to the most recent version of the SDK to ensure their applications are using the virtual-hosted style request format.

After September 30, S3 will no longer accept path-style URI requests and they will all automatically fail in all regions if not replaced with virtual-hosted style requests.

The anti-censorship angle

While at first glance disabling path-style access to S3 hosting shouldn't pose any problems to anyone besides web apps and websites which access assets using the future to be disabled V1 URI requests, there are voices asking Amazon to reconsider.

The most important reason for Amazon to not deprecate path-style URI requests is that hosting and accessing a website via a URL similar to https://s3.amazonaws.com/mywebsite/index.html makes it harder to be blocked in countries where censorship is a thing.

As Samat Galimov said on Twitter, hosting websites on S3 and using V1-styled URLs is an anti-censorship technique named 'collateral freedom' [1, 2] which is based on making it unfeasible for censors to block a domain because it is hosted using a cloud service like Amazon's.

If the censorship body would attempt to block access to the entire cloud service it would also break a huge list of other websites and web services which are not on the censored list.

I can put my entire website under https://t.co/uHxHXKs1Ix and the only way to block it in Russia or China will be to block the entire @Amazon. This technique is called collateral freedom and is actively used right now. Please keep it working! 2/2 — Samat Galimov (@samat) May 3, 2019

As the GreatFire anonymous organization aptly explained:

[..] the authorities have tried to block our mirror websites on S3 - but they have given up. Since we are using all of these platforms to implement collateral freedom - Amazon, GitHub, the App Store and Microsoft - they also know that to effectively stop us they have to block all of them.

Domain fronting already disabled

Another method of bypassing censorship was previously disabled by both Amazon for CloudFront [1, 2] and Google for App Engine in April 2018 [1, 2] following Russian government's request to end Telegram's domain fronting practices back in May 2018. [1, 2, 3]

David Fifield, Chang Lan, Rod Hynes, Percy Wegmann, and Vern Paxson detail in their "Blocking-resistant communication through domain fronting" [PDF] research paper how the domain fronting technique can be successfully used to block censorship attempts.

"Domain fronting uses different domain names at different layers. At the plaintext layers visible to the censor—the DNS request and the TLS Server Name Indication—appears the front domain allowed.example. At the HTTP layer, unreadable to the censor, is the actual, covert destination forbidden.example," state the researchers.

i suppose it’s been a while since AWS broke half the internet, so here’s your regularly scheduled apocalypse:



"Amazon S3 will no longer support path-style API requests starting September 30th, 2020"https://t.co/CxOGkgtvRe — david celis (@davidcelis) May 3, 2019

Update May 09 06:17 EDT: Amazon published a blog post detailing a number of changes to the original S3 path deprecation plan with the highlight being that: