Amazon S3 will no longer support path-style API requests

https://forums.aws.amazon.com/ann.jspa?annID=6776

by cyanbane • 7 years ago

652 264 7 years ago

forums.aws.amazon.com

gcb0• 7 years ago

Does that mean people still have tons of public-by-mistake s3 buckets because of their clumsy UI, and they just gave up and are swiping what's left under the rug?

ceejayoz4• 7 years ago

This wouldn't have any impact on that issue. Those accidentally-public buckets are already accessible in both the path-based and the virtualhost-based method.

scarface74• 7 years ago

You really have to try to make a bucket public. Even when you do, you get warnings within the UI, and there is a column showing you it’s public.

Is there even a UI option to make a bucket public anymore? I always edit the bucket policy and add the JSON to make it public read only.

ceejayoz4• 7 years ago

A lot of that is a fairly recent development, though. Lots of buckets laying around from the years it largely didn’t warn you.

marcinzm• 7 years ago

They're not public by "mistake". They're public because someone was lazy, wanted to share something and didn't want to bother with authentication. They knew they were making it public but figured no one would find it except the desired recipient so why put in the effort to make a better solution.

cddotdotslash• 7 years ago

This is going to break so many legacy codebases in ways I can't even imagine.

Edit: Could they have found a better place to announce this than a forum post?

Sytten• 7 years ago

There is probably a PR document in the process of being released, it's in more than a year after all.

Rexxar• 7 years ago

Couldn't they do a redirection (301) to not break code ?

notmyname• 7 years ago

No, because path-style bucket names weren't originally required to conform to dns naming limitations. I don't know how they're going to migrate those older non-conforming buckets to the host-style form.

pluc• 7 years ago

You're on Hacker News..

mark242• 7 years ago

This will hopefully prevent malicious sites hosted on v1-style buckets from stealing cookies/localstorage/credentials/etc.

judge2020• 7 years ago

Care to elaborate? Why would there be any secrets stored via s3.amazonaws.com?

ARandomerDude• 7 years ago

TL;DR

Migrate

from: s3.amazonaws.com/<bucketname>/key

to: <bucketname>.s3.amazonaws.com/key

no later than: September 30th, 2020

TheLoneTechNerd2• 7 years ago

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.

ynniv• 7 years ago

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

zmmmmm• 7 years ago

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?

TheLoneTechNerd2• 7 years ago

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

chtitux• 7 years ago

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.

iampims• 7 years ago

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

bayareanative• 7 years ago

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

driverdan• 7 years ago

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

BillinghamJ11• 7 years ago

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.

cobookman3• 7 years ago

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

peterwwillis2• 7 years ago

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

cavisne3• 7 years ago

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

dillondoyle• 7 years ago

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

Gasparila• 7 years ago

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• 7 years ago

Cookies support URL path restrictions.

jasonpeacock• 7 years ago

IMO, this is an improvement - it makes it clear that the bucket is global and public, whereas with the path you could believe that it was only visible when logged into your account.

It also helps people understand why the bucket name is restricted in it's naming.

ceejayoz4• 7 years ago

it makes it clear that the bucket is global and public

How does it do that? You can host a private bucket at foo.s3.amazonaws.com just fine.

geofft6• 7 years ago

I think the claim is that the namespace is global and public, i.e., you and I can't both have buckets named "foo". There is only one S3 bucket named "foo" in the world.

If it's https://s3.amazonaws.com/foo/ you could believe that it's based on your cookies or something, but if it's https://foo.s3.amazonaws.com/ it's more obvious that it's a global namespace in the same way DNS domain names are (and that it's possible to tell if a name is already in use by someone else, too).

manigandham• 7 years ago

This is most likely to help mitigate the domain being abused for browser security due to the same-origin policy. This is very common when dealing with malware, phishing, and errant JS files.

astrocat• 7 years ago

Amazon explicitly recommends naming buckets like "example.com" and "www.example.com" : https://docs.aws.amazon.com/AmazonS3/latest/dev/website-host...

Now, it seems, this is a big problem. V2 resource requests will look like this: https://example.com.s3.amazonaws.com/... or https://www.example.com.s3.amazonaws.com/...

And, of course, this ruins https. Amazon has you covered for * .s3.amazonaws.com, but not for * .* .s3.amazonaws.com or even * .* .* .s3.amazonaws... and so on.

So... I guess I have to rename/move all my buckets now? Ugh.

dfsegoat• 7 years ago

FWIW - I found it fairly trivial to set up CloudFront in front of my buckets [1], so that I can use HTTPS with AWS Cert Mgr (ACM) to serve our s3 sites on https://mydomain.com [2].

I set this up some time ago using our domain name and ACM, and I don't think I will need to change anything in light of this announcement.

1 - https://docs.aws.amazon.com/AmazonS3/latest/dev/website-host...

2 - https://docs.aws.amazon.com/acm/latest/userguide/acm-overvie...

thayne6• 7 years ago

That isn't a solution for every use case. For example, it means you can't use the s3 VPC gateway for those buckets.

thayne6• 7 years ago

So... I guess I have to rename/move all my buckets now? Ugh.

It's worse than that. You can't rename a bucket. You will have to create a new bucket and copy everything over.

destroy-2A2• 7 years ago

It’s not a huge problem thanks to S3 batch

https://aws.amazon.com/blogs/aws/new-amazon-s3-batch-operati...

the_mitsuhiko3• 7 years ago

Was curious when someone would bring this up. This has been an issue for such a long time and still the docs are so quiet about it.

BillinghamJ11• 7 years ago

The point of that is solely for doing website hosting with S3 though - where you'll have a CNAME. Why would you name a bucket that way if you're not using it for the website hosting feature?

ceejayoz4• 7 years ago

You might be POSTing user uploads to uploads.example.com.

https://docs.aws.amazon.com/AmazonS3/latest/API/RESTObjectPO...

the_mitsuhiko3• 7 years ago

It also comes up when working with buckets of others. Right now if you build a service that is supposed to fetch from a user supplied s3 bucket the path access was the safest.

Now one would need to hook the cert validation and ignore dots which can be quite tricky because deeply hidden in an ssl layer.

Tharkun• 7 years ago

Not too long ago, we used S3 to serve large amounts of publicly available data in webapps. We had hundreds of buckets with URL style names. Then the TLS fairy came along. Google began punishing websites without HTTPS and browsers prevented HTTPS pages from loading HTTP iframes.

Suddenly we had two options. Use CloudFront with hundreds of SSL certs, at great expense (in time and additional AWS fees), or change the names of all buckets to something without dots.

But aaaaah, S3 doesn't support renaming buckets. And we still had to support legacy applications anf legacy customers. So we ended up duplicating some buckets as needed. Because, you see, S3 also doesn't support having multiple aliases (symlinks) for the same bucket.

Our S3 bills went up by about 50%, but that was a lot cheaper than the CloudFront+HTTPS way.

The cynic in me thinks not having aliases/symlinks in S3 is a deliberate money-grabbing tactic.

Hedja• 7 years ago

That's an interesting contradiction to the rest of their docs. Their docs in other place repeatedly state using periods "." will cause issues. https://docs.aws.amazon.com/AmazonS3/latest/dev/BucketRestri...

e.g.

The name of the bucket used for Amazon S3 Transfer Acceleration must be DNS-compliant and must not contain periods (".").

and as you mentioned

When you use virtual hosted–style buckets with Secure Sockets Layer (SSL), the SSL wildcard certificate only matches buckets that don't contain periods. To work around this, use HTTP or write your own certificate verification logic. We recommend that you do not use periods (".") in bucket names when using virtual hosted–style buckets.

AWS Docs have always been a mess of inconsistencies so this isn't a big surprise. I dealt with similar naming issues when setting up third-party CDNs since ideally Edges would cache using a HTTPS connection to Origin. IIRC the fix was to use path-style, but now with the deprecation it'd need a full migration.

Wonder how CloudFront works around it. Maybe it special cases it and uses the S3 protocol instead of HTTP/S.

dylan604• 7 years ago

isn't that domain name style bucket naming only for hosting a static website from an s3 bucket? otherwise, you can name the bucket whatever you want within the rest of the naming rules.

samat4• 7 years ago

One important implication is that collateral freedom techniques [1] using Amazon S3 will no longer work.

To put it simply, right now I could put some stuff not liked by Russian or Chinese government (maybe entire website) and give a direct s3 link to https:// s3 .amazonaws.com/mywebsite/index.html. Because it's https — there is no way man in the middle knows what people read on s3.amazonaws.com. With this change — dictators see my domain name and block requests to it right away.

I don't know if they did it on purpose or just forgot about those who are less fortunate in regards to access to information, but this is a sad development.

This censorship circumvention technique is actively used in the wild and loosing Amazon is no good.

1 https://en.wikipedia.org/wiki/Collateral_freedom

samat4• 7 years ago

If there is anyone from Amazon caring about freedom of speech and censorship — please contact me at s@samat.me, I'd love to give you more perspective on this.

hkai2• 7 years ago

Hey Samat, I am pretty sure that AWS knows exactly what they're doing. They don't want to lose money by hosting objectionable content, and then lose customers to Aliyun or Russian cloud providers.

KeenFox• 7 years ago

Google Reader served a similar purpose. People used its social features for communication since (the thinking went) governments weren't going to block Google.

saint_fiasco• 7 years ago

Teenagers use Google Docs to chat in environments where popular IM applications are blocked, such as schools and libraries.

It's not really the same threat model as people living under dictatorships, but it might just work.

xiaq• 7 years ago

You cannot solve a political problem with a technical solution.

samat4• 7 years ago

It's better to approach issues from all sides.

filoleg• 7 years ago

You are correct, but you forget that a technological solution like this one can help bringing around the actual social change you are looking for. It is kinda difficult to bring a social change when your major communication and information distribution methods are gutted.

jmull• 7 years ago

That's true, but technology can be part of a political solution.

In particular, a political solution requires that people be able to communicate (in order to work together), and technology can be a component of that.

geofft6• 7 years ago

Sure you can. Weapons research is a very common counterexample; people have been solving political problems with technical solutions ranging from sharpening spear-heads to achieving nuclear chain reactions.

(Of course "who is politically right" and "who has the most technical expertise on their side" are at best tenuously related, but that's a different and longstanding problem. If you believe you're politically right and you have technical expertise on your side, use it.)

nsx147• 7 years ago

Bitcoin

anbop• 7 years ago

What was the Manhattan Project?

Someone1234• 7 years ago

Use DNS over HTTP. Firefox is very easily configurable (network.trr.bootstrapAddress, network.trr.mode, etc) so that if you pick the right bootstrap provider and DNS over HTTP provider you'll never send an unencrypted DNS query (including no SNIs) and it will fail completely rather than reverting to your OS's DNS Client if it cannot be resolved via the DNS over HTTP channel you define.

Because the S3 buckets are virtual-hosted they share IPs so there is deniability if you can hide the DNS/SNI.

aaomidi• 7 years ago

Yes but https SNI still exists.

tirumaraiselvan• 7 years ago

Did you mean use DNS over HTTPS?

djsumdog• 7 years ago

This is similar to domain fronting, which many providers are no longer allowing either.

Thaxll• 7 years ago

Use Cloudflare or any free CDN service?

Edit: Why am I getting downvoted, it's a legit answer, CDN hides your origin.

jetzzz• 7 years ago

Cloudflare is just a disaster for bypassing government censorship. If some website is blocked in my country and I try to access it with Tor or VPN then I better hope it is not behind Cloudflare, because Cloudflare just gives me endless Google captcha instead of the desired website.

kevin_nisbet3• 7 years ago

This is an interesting perspective.

Just as a counter argument, one of the things we tried to do at a previous employer was data exfiltration protection. This meant using outbound proxies from our networks to reach pre-approved urls and we don't want to mitm the TLS connections. This leaves a bit of a problem, because we don't want to whitelist all of s3, the defeats the purpose, so we had to mandate using the bucket.s3 uri style, which is a bit of a pain for clients that use the direct s3 link style, but then we could whitelist buckets we control.

I don't want to say this use case is more important, but I can see the merits of standardizing on the subdomain style, and that this might be a common ask of amazon.

arcbyte2• 7 years ago

Exfiltration protection is pointless. It's a great way to waste money and annoy your employees.

novaleaf• 7 years ago

since your employer is willing to invest in this, wouldn't a custom proxy solve your problem? just whitelist the s3 buckets you care about, and have people access s3 through the proxy.

cortesoft2• 7 years ago

But that isn't really a counter argument.. if you provide the ability to use both formats, your use case would still work (only provide access to the custom subdomain you control).

paulddraper4• 7 years ago

IMO the even bigger problem is that this literally breaks HTTPS.

AWS S3 will only provide SSL validation if your bucket name happens to not contain "."

Which is a practice encouraged by AWS. [1]

So anyone that has www.example.com as the bucket name can no longer use HTTPS.

[1] https://docs.aws.amazon.com/AmazonS3/latest/dev/website-host...

giovannibajo1• 7 years ago

We have exactly this problem. I would appreciate if somebody explained how we should fix this. We need HTTPS and we have buckets with dots in their names

icebraining• 7 years ago

They do say "We recommend that you do not use periods (".") in bucket names when using virtual hosted–style buckets." in the "bucket restrictions": https://docs.aws.amazon.com/AmazonS3/latest/dev/BucketRestri...

Still, seems kinda lazy from their part, they could just generate a custom cert.

tus87• 7 years ago

Did Amazon invent the rule the cert wildcards only match one level?

randomguy9839• 7 years ago

"right now I could put some stuff not liked by Russian or Chinese government (maybe entire website) and give a direct s3 link to https:// s3 .amazonaws.com/mywebsite/index.html. Because it's https — there is no way man in the middle knows what people read on s3.amazonaws.com."

Chinese government will just ban the whole s3.amazonaws.com domain. Same as facebook.com, youtube.com, google.com, gmail.com, wikipedia...

However letting them banning sub-domains will actually make S3 a useable service in China. It's a huge step forward.

andromeduck• 7 years ago

You could say the same about Dragonfly.

morpheuskafka• 7 years ago

Would encrypted SNI fix this?

[1] https://blog.cloudflare.com/encrypted-sni/

ec1096854• 7 years ago

Yes, nothing man in the middle can do to detect the final domain being connected to.

MichaelMoser1232• 7 years ago

https://en.wikipedia.org/wiki/Domain_fronting#Disabling Interestingly a different although related trick (that of domain fronting) has been blocked last year "by both Google and Amazon.... in part due to pressure from the Russian government over Telegram domain fronting activity using both of the cloud providers' services."

eecc• 7 years ago

Follow the money :/

andrewxhill• 7 years ago

Definitely worth checking out https://ipfs.io/. Even for those who don't or can't run IPFS peers on their own devices, IPFS gateways can fill much of the same purpose you listed above. Additionally, the same content should be viewable through _any_ gateway. Meaning if a Gateway provider ever amazoned you, you simply make the requests through a new gateway.

MichaelMoser1232• 7 years ago

Yes, but restrictive governments will have no problem with blocking access to the ipfs.io domain via DNS and by blocking its IP addresses, whereas using the same method for blocking all access to AWS or google cloud is too costly as it will result in collateral damage at home. (Well China can block access to AWS located outside of China because there are AWS Regions in China)

netheril96• 7 years ago

Collateral freedom doesn't work in China. China has already blocked or throttled (hard to tell which, since GFW doesn't announce it) connections to AWS S3 for years.

adamfisk3• 7 years ago

S3 is hardly the only example of collateral freedom in China. There are many other cases where the concept works.

PureParadigm• 7 years ago

One counter example is GreatFire, who use GitHub for their wiki [1].

[1] https://github.com/greatfire/wiki

geokon• 7 years ago

Pretty sure Signal and Psiphon use it successfully. Yes it's throttled, but it's usable most of the time.

They probably got an ultimatum from Chinese authorities to either stop allowing this or get blocked entirely.

They just blocked wikipedia last week.. no one is too big to get shutdown in China

_pmf_• 7 years ago

I think this is exactly what happened.

est• 7 years ago

"collateral freedom" is a failed concept. Many years ago people use Gmail to communicate, and they argue that Chinese government won't dare to block such important and neutral service.

There are like <1% websites in China relies on S3 to deliver static files. Blocking AWS as a whole has happened before. There is simply no freedom was "collateral". Freedom has to be fought hard and eared.

blairanderson• 7 years ago

TL;DR https://news.ycombinator.com/item?id=19821813

RocketSyntax• 7 years ago

Boo. Now old packages won't work.

segmondy• 7 years ago

So much for customer obsession.

jhall14682• 7 years ago

I don't think "never change" is customer obsession. Improving products is customer obsession.

notatoad• 7 years ago

this goes beyond "never change". never changing your product is a bad thing, but never changing your URLs is a mantra everybody should live by.

phlakaton• 7 years ago

Hm. I had a local testing setup using an S3 standin service from localstack and a Docker Compose cluster, and path-style addressing made that pretty easy to set up. Anyone else in that "bucket?" Suggestions on the best workaround?

yeahitslikethat2• 7 years ago

"In our effort to continuously improve customer experience, the path-style naming convention is being retired in favor of virtual-hosted style request format. Customers should update their applications"

How does forcing customers to rewrite their code to confirm to this change, improve customer experience?

blantonl3• 7 years ago

Maybe as the technical debt continues to come due with the current architecture, it's time to make the hard choices to keep a good customer experience?

yeahitslikethat2• 7 years ago

It's on amazon to pay off their technical debt. Not their customers. They are turning off a feature at their customers expense.

That's the exact opposite of good customer service.

bagels2• 7 years ago

Fun fact: The s3 console as of right now still shows v1 urls when you look at the overview page for a key/file.

geekrax2• 7 years ago

There are millions of results for "https://s3.amazonaws.com/" on GitHub: http://bit.ly/2GUVjDi

BillinghamJ11• 7 years ago

GitHub search is really poor. It is also including the uses of the subdomain style.

geekrax2• 7 years ago

Agreed. The search could use some love for doing exact match.

The scale at which different libraries, tools, and systems depending on hard-coded S3 urls will break by this change is insane.

caseymarquis• 7 years ago

I'm so glad I saw this. I would have been very confused when this went live had I not seen this post today. I wish I could upvote this more.

blantonl3• 7 years ago

I'm kind of shocked at some of the responses here... everything from outrage, to expressing dismay at how many things could break, to how hard this is to fix, to accusing Amazon of all kinds of nefarious things.

How hard is it for 99% of the developers and technical leaders here to search your codebase for s3.amazonaws.com and update your links in the next 18 months?

simonw• 7 years ago

You're assuming that most code is actively maintained. It isn't. This is going to break so much older stuff.

jhall14682• 7 years ago

While true, I don't think backwards compatibility forever is the right solution to the old code problem.

peterwwillis2• 7 years ago

It's a reasonable timeframe, but not all codebases are actively maintained. In addition, it's concievable that there's some hidden custom library somewhere that crafts S3 URIs, making it near impossible to simply grep for a certain URI type in the codebase. So people may have to scour codebases they don't even maintain to look for random code which may craft an S3 URI in a certain way, then fork that project, fix the functionality, publish it, and use the fork. Then they may need to fork every other project that uses that original project, and do the same thing ad infinitum. If this is a private company, they have to do all that within some corp-wide globally available private repo, which either means (1) making this repo public on the internet, or (2) adding it to every security group they have that pulls code. It may even require adding direct connect or privatelink. So that means a long research project, followed by a project of fixing, testing, and releasing new code, followed by a project get network access to the custom repos and change software to use them.

So, surprisingly hard, but doable. And from the customer's perspective, a huge pain in the ass, just to save Amazon some pennies on bandwidth.

fpgaminer• 7 years ago

How hard is it for 99% of the developers and technical leaders here to search your codebase for s3.amazonaws.com and update your links in the next 18 months?

I've got a number of hobby projects, some hosted on AWS, that I built ages ago. I have no idea how this change will effect those projects because ... I just frankly don't remember the codebases. I built them on a weekend, set them up, and now just use them.

It isn't the end of the world. But I'm not really excited about having to dig up old code, re-grok it, and fix anything that changes like these might break.

I suppose that's just the nature of a developer's life. But I think many of us long for a "write once, run forever" world. Horror stories about legacy software aside, it was nice to be able to write software for Windows and then have it work a decade later.

blantonl3• 7 years ago

I suppose that's just the nature of a developer's life. But I think many of us long for a "write once, run forever" world.

Well, I think AWS developers are in the same boat right? Here we are.

An architectural decision that many years ago was the approach now needs to be rethought and updated.

sly010• 7 years ago

Is there a deprecation announcement that does not include the phrase "In our effort to continuously improve customer experience"?

Edit: autotypo

massung• 7 years ago

Anyone know if this will affect the internal use (e.g. EMR) s3 schema: s3://bucket/path/key?

BillinghamJ11• 7 years ago

No it won't

electrum• 7 years ago

No. The file system implementation uses the AWS S3 client, which will automatically use virtual-host style when possible (if the bucket name supports it).

merb• 7 years ago

I see a problem when using the s3 library to other services that support s3 but only have some kind of path style access like minio or ceph with no subdomains enabled. it will break once their java api removes the old code.

euank• 7 years ago

One of the weird peculiarities of path-style API requests was that it meant CORS headers meant nothing for any bucket pretty much. I wrote a post about this a bit ago [0].

I guess after this change, the cors configuration will finally do something!

On the flip side, anyone who wants to list buckets entirely from the client-side javascript sdk won't be able to anymore unless Amazon also modifies cors headers on the API endpoint further after disabling path-style requests.

[0] https://euank.com/2018/11/12/s3-cors-pfffff.html

ajcodez• 7 years ago

I switched to MinIO for anything new. Happy user - https://min.io/

sl1ck731• 7 years ago

Does the "you are no longer logged in" screen not infuriate anyone besides me? There doesn't seem any purpose to it just redirecting you to the landing page when you were trying to access a forum post that doesn't even require you be logged in.

Absolutely mind boggling with as much as they pay people they do something so stupid and haven't changed it after so long.

pulkitsh1234• 7 years ago

    ag -o 'https?://s3.amazonaws.com.*?\/.*?\/'| awk -F':' '{print $1, $4}' | sort | uniq | cut -d'/' -f 1 | sort | uniq -c | gsort -h -rk1,1

For anyone interesting in finding out the occurrences in their codebase. (Mac)

lazyant• 7 years ago

`In our effort to continuously improve customer experience` , what's the actual driver here, I don't see how going from two to one option and forcing you to change if you are in the wrong one improves my experience.

a13n• 7 years ago

Reduce complexity for future customers

thaumasiotes• 7 years ago

http://chainsawsuit.com/comic/2017/12/07/improvements/

We asked our investors and they said you're very excited about it being less good, which is great news for you!

btown• 7 years ago

What kind of company deprecates a URL format that's still recommended by the Object URL in the S3 Management Console?

https://www.dropbox.com/s/zzr3r1nvmx6ekct/Screenshot%202019-...

There are so, SO many teams that use S3 for static assets, make sure it's public, and copy that Object URL. We've done this at my company, and I've seen these types of links in many of our partners' CSS files. These links may also be stored deep in databases, or even embedded in Markdown in databases.

This will quite literally cause a Y2K-level event, and since all that traffic will still head to S3's servers, it won't even solve any of their routing problems.

Set it as a policy for new buckets, if you must, if you change the Object URL output and have a giant disclaimer.

But don't. Freaking. Break. The. Web.

EugeneOZ• 7 years ago

Also in millions of manuals, generated PDFs, sent emails... Some things you just can't "update" anymore.. It's really disastrous change for the web data integrity.

hueving3• 7 years ago

One of the magicians in Las Vegas (the one at the MGM) even used s3 image links in emails to send emails to everyone "predicting" the contents of something that hadn't happened.

parktheredcar• 7 years ago

I think recent years have proven that despite all the memeing about things like rest, "don't break the web" is not a value shared by all of the parties involved.

The takeaway is that for those of us that do still wish to uphold those values, we can let this serve as a lesson that we should not publish assets behind urls we don't control.

jypepin2• 7 years ago

Came here for the same comment. I setup some s3 related stuff less than 2 months ago and the documentation, at least for the js sdk, still recommends the path-style url. I don't even recall a V1/V2 mentioned.

That seems very inconvenient, and is pretty inline with my experience with aws: I guess their services are cheap and good, but oh boy! The developer experience is SO bad.

- So many services, it is very hard to know what to use for what - Complex and not user friendly APIs - coming with terrible documentation

I'm pretty sure they'd get a lot more business if they invested a bit more in developer friendliness - right now I only use aws if a Client really insists on it, because despite having used it a fair amount, I'm still not happy and comfortable with it.

mabey• 7 years ago

Out of curiosity what cloud service do you prefer?

jacurtis• 7 years ago

Except S3 storage isn't actually all that cheap anymore. Amazon has literally never changed the price of S3 storage over the last decade even though storage costs have plummeted over the same time period.

There are other providers out there like Digital Ocean Spaces, Wasabi, and Backblaze that offer storage solutions for much cheaper than S3 now.

Digital Ocean Spaces and Wasabi in particular actually use the Amazon S3 api for all their storage. This means you can switch over to either of those solutions without changing the programming of your app or the S3 plugins or libraries that you are currently using. The only thing you change is the base url that you make api calls to.

Backblaze has their own API, but they also offer a few additional features not offered under S3's api.

hartleybrody• 7 years ago

Agreed. Cool URIs don't change. [1]

[1] https://www.w3.org/Provider/Style/URI

xyzzy_plugh• 7 years ago

This will break software updates for so many systems, probably even some Amazon devices.

pronoiac• 7 years ago

For other folks looking for announcement feeds, see https://forums.aws.amazon.com/rss.jspa - announcements are the asterisks.

etxm• 7 years ago

This is going to be the Y2K of September 2020.

reilly3000• 7 years ago

I was already planning a move to GCP, but this certainly helps. Now that cloud is beating retail in earnings, the ‘optimizations’ come along with it. That and BigQuery is an amazing tool.

It’s not like I’m super outraged that they would change their API, the reasoning seems sound. It’s just that if I have to touch S3 paths everywhere I may as well move them elsewhere to gain some synergies with GCP services. I would think twice if I were heavy up on IAM roles and S3 Lambda triggers, but that isn’t the case.

chillaxtian• 7 years ago

A similar removal is coming in just 2 months for V2 signatures: https://forums.aws.amazon.com/ann.jspa?annID=5816

This could be just as disruptive.

Difficult to say that they will actually follow through, as the only mention of this date is in the random forum post I linked.

scrollaway• 7 years ago

Doubtful, sigv2 is not supported in all regions. So all current software that wants to be compatible with more than a portion of regions has to be compatible.

This is a great way of introducing breaking changes. Imagine that for example, ipv6 would be at near 100% adoption if "new websites" were only available over v6.

miguelmota• 7 years ago

Always confused me how they had two different ways of retrieving the same object. Glad that they're sticking to the subdomain option. Sucks to go back and check for old urls though. This change might break a good chunk of the web.

ec1096854• 7 years ago

Amazon is proud that they never break backwards compatibility like this. Quotes like the container you are running on Fargate will keep running 10 years from now.

Something weird is going on if they don’t keep path style domains working for existing buckets.

quickthrower2• 7 years ago

Only 10 years. Shame that that is a boast. 100 years would be better.

swiley• 7 years ago

Commercial platform breaks things people have built on it for "the sake of continuously improving customer experience. "

Also: see photos of your favorite celebrity walking their dog and other news at 11.

niyazpk• 7 years ago

One way to do this without breaking existing applications would be to charge more for the path style requests for a while. Then deprecate once enough people have moved away from it, so that less people are outraged by the change.

interfixus• 7 years ago

In our effort to continuously improve customer experience, [feature x] is being retired

In this case, the most highly improved experience I can think of eould be that of sundry nefarious entities monitoring internet traffic.

iamgopal• 7 years ago

They should produce a free redirect service at least.

jasonkester• 7 years ago

I wonder how they’ll handle capitalized bucket names. This seems like it will break that.

S3 has been around a long time, and they made some decisions early on that they realised wouldn’t scale, so they reversed them. This v1 vs v2 url thing is one of them.

But another was letting you have “BucketName” and “bucketname” as two distinct buckets. You can’t name them like that today, but you could at first, and they still work (and are in conflict under v2 naming).

Amazons own docs explain that you still need to use the old v1 scheme for capitalized names, as well as names containing certain special characters.

It’d be a shame if they just tossed all those old buckets in the trash by leaving them inaccessible.

All in, this seems like another silly, unnecessary, depreciation of an API that was working perfectly well. A trend I’m noticing more often these days.

Shame.

Roark66• 7 years ago

AWS API is an inconsistent mess. If you don't believe me try writing a script to tag resources. Every resource type requires using different way to identify it, different way to pass the tags etc. You're pretty much required to write different code to handle each resource type.

cs02rm0• 7 years ago

I didn't know path style was possible.

I'd have found it really useful. :-/

gigatexal• 7 years ago

Hmm I don’t understand why this change is happening. What does this gain? Removal of tech debt?

rynop• 7 years ago

How does this impact CloudFront origin domain names? I have an s3 bucket as a CF origin and the format the AWS CF Console auto-completes to is:

<bucket>.s3.amazonaws.com

Do I need to change my origin to be, Origin domain name: s3.amazonaws.com, Origin Path: <bucket>

This is a sneaky one that will bite lots of folks as it is NOT clear.

bagels2• 7 years ago

I think you have this backwards.

<bucket>.s3.amazonaws.com is the V2 url formula.

tckr• 7 years ago

The title is misleading. Path style request "/foo/bar/file.ext" are still supported.

What changes is that the bucket name must be in the hostname.

k__• 7 years ago

Path style can be used in hostnames?

orf• 7 years ago

https://github.com/search?q=%22https%3A%2F%2Fs3.amazonaws.co...

Over a million results (+250k http). This is going to be painful.

jvarsanik• 7 years ago

Does anyone know if this will affect uploads? We are getting an upload URL using s3.createPresignedPost and this returns (at least currently) a path-style url...

abra5593• 7 years ago

this looks to be largely resolved: https://aws.amazon.com/blogs/aws/amazon-s3-path-deprecation-...

Amazon S3 will no longer support path-style API requests

Related Stories