Hacker News Reader

Comment by MobileVet | Hacker News Reader

One thing that I haven't seen discussed in the comments is the inherent vulnerability of S3 pricing. Like all things AWS, if something goes sideways, you are suddenly on the wrong side of a very large bill. For instance, someone can easily blow your egress charges through the roof by making a massive amount of requests for your assets hosted there.

While Cloudflare may reach out and say 'you should be on enterprise' when that happens on R2, the fact they also handle DDoS and similar attacks as part of their offering means the likelihood of success is much lower (as is the final bill).

View on HN

Typically you would use S3 with CloudFront for hosting. S3 provides no protections because it's meant to be a durable and global service. CloudFront provides DDoS and other types of protection while making it easy to get prepaid bandwidth discounts.

Just one data point, but adding Cloudflare to our stack (in front of "CloudFront with bandwidth discounts") took about $30k USD per year off our bandwidth bill.

Yes, obviously. But just as obviously is there's rarely an easy and safe path with AWS. By default, R2 is easy, safe, and cheaper.

In my experience the AWS waf and ddos mitigation are really expensive (min $40k per year contract) and are missing really basic ddos handling capabilities (last I evaluated it they did not have the ability to enforce client js validation which can be very effective against some bot networks). Maybe it has evolved since but Cloudflare enterprise was cheaper and more capable out of the box.

Cloudflare is a CDN that added R2 storage, which leverges the CDN, to some extent, by default it seems

AWS made S3 as data storage, then added CloudFront for CDN purposes. The CDN is an optional addon which may or may not make sense... E.g. an internal data storage staying in AWS doesn't need the CDN.

Comparing CloudFlare to S3 is apples and oranges, in my option. Comparing CloudFlare+R2 and S3+CloudFront is more appropriate, I think.

---

Additional thoughts:

It's hard to evaluate the bias of the author.. The author clearly dislikes AWS, and while some of the plants are generally what I would agree with.. I question if the author is properly evaluating AWS in the comparison and trying to sell their book. Would the book be any better, or would it echo chamber the typical AWS perceived negatives. For instance, the author notes S3 intelligent tiering... But if you know that the data is not going to be accessed, you could likely skip the overhead of intelligent tiering and directly put it into a cheaper storage class... And in general the same with other S3 data types.

I do generally agree that AWS bandwidth charges are extortion... But I still would want less bias in a product review/comparison from something posted here on hacker news.

Also, once you are on Enterprise, they will not bug/charge you for contracted overages very often (like once a year) and will forgive significant overages if you resolve them quickly, in my experience.

Its a welcome change from Vercel, who, if you site is under attack will email you saying congrats on using 75% of your quota in a day.

Cloudflare has DDOS roots and it plays well here.

I'm not really sure what point you're trying to make here. S3 bills you on, essentially, serving files to your customers. So yes if your customers download more files then you get charged more. What exactly is the surprising part here

The surprise is any ne'er-do-well can DDoS your bucket even if they aren't a customer. Genuine customer traffic volume will probably be known and expected, but putting an S3 bucket in the open is something like leaving a blank check on the internet.

It's a bit unfair to characterize that as a surprise on how much S3 bills you, no? The surprising part here is lack of DDoS protection on your end or leaving a bucket public and exposed. AWS is just charging you for how much it served, it doesn't make sense to hold them to a fault here.

AWS will also forgive mistakes or negligence based bills, in my case 3 times.

If you want to hire someone to walk your dog you probably won't put an ad in the New york times to a head hunter that you will pay by the hour with no oversight and it would be totally unfair to that head hunter when you don't want to pay them for the time of all those interviews. But an infinitely scalable service you somehow can't put immediately terminal limits on is somehow fine on the cloud.

it loses trust with customers when the simple setup is flawed. S3 is rightly built to support as much egress as any customer would want, but wrong to make it complex to set up rules to limit the bandwidth and price.

It should be possible to use the service, especially common ones like S3 with little knowledge of architecture and stuff.

> it loses trust with customers when the simple setup is flawed.

S3’s simple setup (which denies all public access) is not flawed in the manner being discussed here. Allowing public direct access to an S3 bucket is a supported option, but for years has been both non-default and strongly recommended against.

> The surprising part here is lack of DDoS protection on your end or leaving a bucket public and exposed.

It doesn't take anything near DDoS. If you dare to put up a website that serves images from S3, and one guy on one normal connection decides to cause you problems, they can pull down a hundred terabytes in a month.

Is serving images from S3 a crazy use case? Even if you have signed and expiring URLs it's hard to avoid someone visiting your site every half hour and then using the URL over and over.

> AWS is just charging you for how much it served, it doesn't make sense to hold them to a fault here.

Even if it's not their fault, it's still an "inherent vulnerability of S3 pricing". But since they charge so much per byte with bad controls over it, I think it does make sense to hold them to a good chunk of fault.

I think this just boils down to: S3 is expensive. It’s orthogonal to DDoS. Of course, the same principle applies for any expensive resource: put DDoS protection in front of it.

It boils down to: S3 is expensive in a way that's hard to control.

Do you expect DDoS protection to kick in from one person downloading a single digit number of images per second?

I don't know about fair or unfair, but it's just a problem you don't have to worry about if there's no egress fees.

There was a backlash about being billed for unauthorized requests. It's since been updated[0]. I don't know that all affected was retroactively refunded.

[0] https://aws.amazon.com/about-aws/whats-new/2024/08/amazon-s3...

Reply on news.ycombinator.com