Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Amazon S3 will no longer charge for several HTTP error codes

aws.amazon.com

Post reply on HN
Print view View original

61–70 of 77 posts

Re: Amazon S3 will no longer charge for several HTTP error codes

#61

Post by beeeeerp »

paulddraper wrote: post #55
beeeeerp wrote: post #11

Now please do this for NXDOMAIN on Route53. This can be a big problem with acquired domains.

That's not analogous.

It’s still a huge problem for people that have purchased domains. I bought one that apparently used to be a BT tracker, and gets on the order of several hundred NXDOMAIN requests per second.

I understand it’s still hitting Route53 infrastructure, but I’m not using it, and it’s not commonplace to charge for NXDOMAIN records. Because of this, I’m unable to host at AWS (prohibitively expensive for my use-case).

It’s worth mentioning that DNS infrastructure for things like this are very cheap (I used to self-host the DNS infrastructure for this domain for ~$2.5/mo), so the up charge is even worse that what AWS is charging for bandwidth. If they brought it in line with actual costs, I wouldn’t have as much of a problem.

Re: Amazon S3 will no longer charge for several HTTP error codes

#62

Post by deanCommie »

simonw wrote: post #50
akira2501 wrote: post #46

Earlier quoted context omitted.

> unwittingly enable something that suddenly charges you hundreds of dollars before you know it The default is to have current and estimated monthly cost displayed on your root console as soon as you login. You will also get email alerts when you hit 50% and then 80% of your "free tier quota" in a month. > even if you're not doing anything with the service except looking around. I'm not aware of any services which wi…

"It's not too hard to figure out, though, if you take the time to read through their rather large set of documentation" I don't even know where I would start with that. https://docs.aws.amazon.com/ lists documentation for 305 different products!

Well, presumably, from the service you decided to use first?

Re: Amazon S3 will no longer charge for several HTTP error codes

#63

Post by paulddraper »

beeeeerp wrote: post #61
paulddraper wrote: post #55

Earlier quoted context omitted.

That's not analogous.

It’s still a huge problem for people that have purchased domains. I bought one that apparently used to be a BT tracker, and gets on the order of several hundred NXDOMAIN requests per second. I understand it’s still hitting Route53 infrastructure, but I’m not using it, and it’s not commonplace to charge for NXDOMAIN records. Because of this, I’m unable to host at AWS (prohibitively expensive for my use-case). It’s wor…

A book could be written about AWS "overcharged" services

Re: Amazon S3 will no longer charge for several HTTP error codes

#64

Post by amzn-throw »

mike_d wrote: post #53
dmw_ng wrote: post #12

Can't imagine a change like this would be made without some analysis.. would love an internal view into a decision like this, I wonder if they already have log data to compute financial loss from the change, or if they have sampling instrumentation fancy enough to write/deploy custom reports like this quickly. In any case 2 weeks seems like an impressive turnaround for such a large service, unless they'd been interna…

> Can't imagine a change like this would be made without some analysis.. would love an internal view into a decision like this Sure, here you go: There was some buzz and negative press so it got picked up by the social media managers who forwarded it to executive escalations who loops in legal. Legal realizes that what they are doing is borderline fraud and sends it to the VP that oversees billing as a P0. It then ge…

As someone that works at AWS (but not on S3), that's wrong in like eight different ways.

But the only way that matters is the core one - analysis, data, and instrumentation.

AWS does not make these kinds of decisions without a look at the metrics.

Re: Amazon S3 will no longer charge for several HTTP error codes

#65

Post by alanfranz »

lapcat wrote: post #20

AWS is full of dark patterns. You can sign up for the so-called "free" tier and then too easily, unwittingly enable something that suddenly charges you hundreds of dollars before you know it (by getting a bill at the end of the month), even if you're not doing anything with the service except looking around. AWS doesn't give any warning to free tier members that a configuration change is going to cost you, and their…

Most cloud providers work this way somehow. Flexible, pay as you go infra doesn’t cope well with fixed pricing.

Fixed price cloud offerings exist for some services, but can end up with an apparently larger sticker price.

Re: Amazon S3 will no longer charge for several HTTP error codes

#66

Post by beeeeerp »

paulddraper wrote: post #63
beeeeerp wrote: post #61

Earlier quoted context omitted.

It’s still a huge problem for people that have purchased domains. I bought one that apparently used to be a BT tracker, and gets on the order of several hundred NXDOMAIN requests per second. I understand it’s still hitting Route53 infrastructure, but I’m not using it, and it’s not commonplace to charge for NXDOMAIN records. Because of this, I’m unable to host at AWS (prohibitively expensive for my use-case). It’s wor…

A book could be written about AWS "overcharged" services

Totally agree with this. In their defense (not that I like it), obviously the market is willing to pay what they charge. It’s unfortunate that the other big cloud providers haven’t driven prices down that much.

Re: Amazon S3 will no longer charge for several HTTP error codes

#67

Post by moi2388 »

There needs to be a law that says any user needs to set any limit on any service or subscription, and then the costs can not surpass this until the budget is upped by the user. At the same time, there should be real-time cost analysis, breakdown per service and predicted costs per day.

Re: Amazon S3 will no longer charge for several HTTP error codes

#68

Post by usr1106 »

moi2388 wrote: post #67

There needs to be a law that says any user needs to set any limit on any service or subscription, and then the costs can not surpass this until the budget is upped by the user. At the same time, there should be real-time cost analysis, breakdown per service and predicted costs per day.

A law in which country?

Well, GDPR showed a bit that rather global impact is possible.

If you offer an open service on the internet you need to be prepared that users and misusers will cause costs.

However, if you block it for public access you as a customer are not offering a public service. It's the cloud provider offering a public service so it seems just a basic legal principle that it's the cloud provider who pays for misuse (attempts to access something that is not public). But of course big corporations are not known for fair contracts respecting legitimate interest of the customer before legal action is on the horizon. I wonder what made AWS wake up here.

Re: Amazon S3 will no longer charge for several HTTP error codes

#69

Post by _flux »

wavemode wrote: post #34
hunter2_ wrote: post #24

Earlier quoted context omitted.

If I understand TFA, you'd need to find a way to get S3 (which offers no server-side script execution, only basic file delivery) to emit an error code (403 specifically) alongside a response of useful data. Good luck...

Simple. Just encode all of your app's data and logic as a massive lookup table, each bit of which is represented by an object that either doesn't exist (a zero) or is unauthorized to access (a one). When you read a sequential series of keys (404 403 403 404 = 0110) it will either tell you the data you were looking for or the next key name to begin reading from.

You can also perfectly parallellize those requests, making the operation highly efficient!

Re: Amazon S3 will no longer charge for several HTTP error codes

#70

Post by cbsmith »

recursive wrote: post #25
cbsmith wrote: post #5

Earlier quoted context omitted.

In fairness, the issue was attended to within weeks after it recently got attention.

So, another way of saying this is, it took more than a decade to get attention?

Realistically, Amazon didn't have the scale/resources to mitigate/manage this problem for customers back in the day. It also wasn't a target like it is now. Even a decade ago, it was a comparatively small problem that was no doubt simpler to address this on a case-by-case basis.

Being responsive isn't about having infinite resources. It's about prioritization. I doubt at the time this was anywhere near the top of the list for them to fix even for the person who tweeted years ago.

Post reply on HN