[TheLoneTechNerd]

Does anyone have insight on why they're making this change? All they say in this post is "In our effort to continuously improve customer experience". From my point of view as a customer, I don't really see an experiential difference between a subdomain style and a path style - one's a ".", the other's a "/" - but I imagine there's a good reason for the change.

[BillinghamJ]

Three reasons -

First to allow them to shard more effectively. With different subdomains, they can route requests to various different servers with DNS.

Second, it allows them to route you directly to the correct region the bucket lives in, rather than having to accept you in any region and re-route.

Third, to ensure proper separation between websites by making sure their origins are separate. This is less AWS's direct concern and more of a best practice, but doesn't hurt.

I'd say #2 is probably the key reason and perhaps #1 to a lesser extent. Actively costs them money to have to proxy the traffic along.

[cavisne]

I think they should explain this a bit better. That said

For core services like compute and storage a lot of the price to consumers is based on the cost of providing the raw infrastructure. If these path style requests cost more money, everyone else ends up paying. It seems likely any genuine cost saving will be at least partly passed through.

I wouldn't underestimate #1 not just for availability but for scalability. The challenge of building some system that knows about every bucket (as whatever sits behind these requests must) isnt going to get any easier over time.

Makes me wonder when/if dynamodb will do something similar

[peterwwillis]

So "improving customer experience" is really Amazon speak for "saving us money"

[cobookman]

With Software defined networking you don't need the subdomain to do that.

[Gasparila]

One big reason to me: cookie security

Currently all buckets share a domain and therefore share cookies. I've seen attacks (search for cookie bomb + fallback manifest) that leverage shared cookies to allow an attacker to exfiltrate data from other buckets

[notfed]

Cookies support URL path restrictions.

[zmmmmm]

The only obvious thing that occurs to me is that bringing the bucket into the domain name puts it under the same-origin policy in the browser security model. Perhaps there are a significant number of people hosting their buckets and compromising security this way? Not something I have heard of but it seems possible. Makes me wonder if they are specifically not mentioning it because this is the reason and they know there are vulnerable applications in the wild and they don't want to draw attention to it?

[TheLoneTechNerd]

Removing my comments because I can't seem to delete them...

[chtitux]

Probably because they want to improve the response time with a more precise DNS answer.

With s3.amazonaws.com, they need to have a proxy near you that download the content from the real region. With yourbucket.s3.amazonaws.com, they can give an IP of an edge in the same region as your bucket.

[dillondoyle]

I would guess cookies and other domain scoped spam/masking 'tricks'? I've never tried but perhaps getting a webpush auth on that shared domain could cause problems

[iampims]

It’s a known trick for spammers to leverage the amazon domain to rank higher in search rankings.

[driverdan]

That's a search engine problem, not a hosting problem.

[bayareanative]

Virtual and path style share the same domain suffix. It's also *.amazonaws.com, not amazon.com.

[ynniv]

I have no visibility into Amazon, but using subdomains let you shard across multiple IP addresses.