Hacker News Reader

Comment by TheLoneTechNerd | Hacker News Reader

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.

View on HN

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.

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

Huh? If the DNS doesnt see the bucket name how can it hand back the right IP of where the bucket lives?

How does that work? My browser is going to send all requests to the same domain to the same place.

Anycast ip.

You have a sole ip address. All traffix routed to nearest PoP. The PoP makes the call on where and how to route the request.

Lookup google front end (GFE) whitepaper. Or thd google cloud global load balancer

That front end server that lives in the PoP can also inspect the http packets for layer 7 load balancing.

https://cloud.google.com/load-balancing/docs/load-balancing-...

Added to my comment, but basically S3 is not a CDN - it doesn't have PoPs/anycast.

They _do_ use anycast and PoPs for the DNS services though. So that's basically how they handle the routing for buckets - but relies entirely on having separate subdomains.

What you're saying is correct for Cloudfront though.

Presumably Amazon has PoPs for CloudFront; why couldn't S3 share the same infrastructure?

It means two hops not one. S3 gets can be cached but then you have a whole host off issues. Better to get to the origin.

They could do that, but they have absolutely no incentive to do so - all it would do is cost them more. S3 isn't a CDN and isn't designed to work like one.

With SDN the PoP would only need to receive the TCP request and proxy TCP acks.

Raw data could flow from a different PoP that's closer to DC.

Aka user->Closest PoP-> backhaul fiber -> dc->user

Yeah you basically do. Sure you can reroute the traffic internally over the private global network to the relevant server, but that's going to use unnecessary bandwidth and add cost.

By sharding/routing with DNS, the client and public internet deal with that and allow AWS to save some cash.

Bear in mind, S3 is not a CDN. It doesn't have anycast, PoPs, etc.

In fact, even _with_ the subdomain setup, you'll notice that before the bucket has fully propagated into their DNS servers, it will initially return 307 redirects to https ://<bucket>.s3-<region>.amazonaws.com

This is for exactly the same reason - S3 doesn't want to be your CDN and it saves them money. See: https://docs.aws.amazon.com/AmazonS3/latest/dev/VirtualHosti...

I'm not sure you understand how anycast works. It would be very shocking if Amazon didn't make use of it and it's likely the reason they do need to split into subdomains.

Anycast will pull in traffic to the closest (hop distance) datacenter for a client, which won't be the right datacenter a lot of the time if everything lives under one domain. In that case they will have to route it over their backbone or re-egress it over the internet, which does cost them money.

AWS in general are not fans of Anycast. Interesting thread from one of their principal engineers on the topic.

https://twitter.com/colmmacc/status/1067265693681311744

Google Cloud took a different approach based on their existing GFE infrastructure. It does not really seem to have worked out, there have been a couple of global outages due to bad changes to this single point of failure, and they introduced a cheaper networking tier that is more like AWS.

> AWS in general are not fans of Anycast.

I don't think that's true. Route53 has been using Anycast since its inception [0].

The Twitter thread you linked simply points out that fault isolation is tricky with Anycast, and so I am not sure how you arrived at the conclusion that you did.

[0] https://aws.amazon.com/blogs/architecture/a-case-study-in-gl...

Route53 is the exception, compared to Google Cloud where the vast majority of api's are anycast through googleapis.com

It's a good choice for DNS because DNS i a single point of failure anyway, see yesterdays multi hour Azure/Microsoft outage!

Got it, thanks. Are there research papers or blog posts by Google that reveal how they resume transport layer connections when network layer routing changes underneath it (a problem inherent to Anycast)?

I do understand how it works and can confirm that AWS does not use it for the IPs served for the subdomain-style S3 hostnames.

Their DNS nameservers which resolve those subdomains do of course.

S3 isn't designed to be super low latency. It doesn't need to be the closest distance to client - all that would do is cost AWS more to handle the traffic. (Since the actual content only lives in specific regions.)

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

reduces incentive for them to raise prices

And reduces chances of outages... which is good for both customers and AWS.

Do they not charge for network costs anyway?

A more optimistic view is that this allows them to provide a better service.

They charge for data transfer. They don't charge based on the level of complexity needed for their internal network operations.

Everything is a tradeoff.

Makes it faster, reduces complexity and would allow them to reduce prices too

Pricing is set by markets based on competitors' offerings. Reduced costs could simply result in monopoly rents.

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

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

Cookies support URL path restrictions.

That doesn't prevent unauthorized reading of the cookies. The only way to properly prevent it is using a different domain/subdomain.

https://developer.mozilla.org/en-US/docs/Web/API/document/co...

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?

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

Does it bother you the domain is amazon.com and not com.amazon?

I can't read what you're replying to, but it absolutely bothers me. The current scheme has this completely random double reversal in the middle of the URL; it would have been so trivial to just make it actually big-endian, but instead we have this big-little-big endian nonsense. Far too late to change it now, but it is ugly and annoying.

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.

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

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

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

Public suffix list: https://publicsuffix.org

s3.amazonaws.com subdomains are as distinct from each other as co.uk subdomains.

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

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

Reply on news.ycombinator.com