> I had cloudflare in front of my stuff. Hacker found an uncached object and hit it 100M+ times. I stopped that and then they found my origin bucket and hit that directly.
Pardon my ignorance, but isn’t that something that can happen to anyone? Uncached objects are not something as serious as leaving port 22 open with a weak password (or is it?). Also, aren’t S3 resources (like images) public so that anyone can hit them any times they want?
No. Your buckets should be private, with a security rule that they can only be accessed by your CDN provider, precisely to force the CDN to be used.
Why isn't that the default?
I'm glad I use a Hetzner VPS. I pay about EUR 5 monthly, and never have to worry about unexpected bills.
Don't they charge for every TB exceeding the included limit? (website says "For each additional TB, we charge € 1.19 in the EU and US, and € 8.81 in Singapore.")
They do, but the risk of having to pay $1.44/TB after the first 20TB is easier to swallow than say, CloudFront's ~$100/TB after 1TB.
> CloudFront's ~$100/TB after 1TB.
I had to double-check because that sounds hilariously wrong. I can't find it anywhere in the pricing. It's at most 0.08/TB.
Am I missing something?
You're missing the unit, it's $0.085 per GB, not TB, and that's only for NA/EU traffic. I rounded up a bit from that number because other regions cost more, plus you get billed a flat amount for each request as well.
They do offer progressively cheaper rates as you use more bandwidth each month, but that doesn't have much impact until you're already spending eye watering amounts of money.
Oh, yeah, egg on my face. They only put the unit of measurement at the top, and then talk about TB, so it's a bit deceptive. In retrospect, I was stupid to imagine 0.085/TB made any sense.
0.085/TB makes a lot of sense if you sell just with a 50 to 100% markup. But they rather sell at tens of thousands of markup to the real cost
> I'm glad I use a Hetzner VPS. I pay about EUR 5 monthly, and never have to worry about unexpected bills.
The trade-off being that your site falls over with some amount of traffic. That's not a criticism, that may be what you want to happen – I'd rather my personal site on a £5 VPS fell over than charged me £££.
But that's not what many businesses will want, it would be very bad to lose traffic right at your peak. This was a driver for a migration to cloud hosting at my last company, we had a few instances of doing a marketing push and then having the site slow down because we couldn't scale up new machines quickly enough (1-12 month commitment depending on spec, 2 working day lead time). We could quantify the lost revenue and it was worth paying twice the price for cloud to have that quick scaling.
Because not all uses for buckets fit that.
Buckets are used for backups, user uploads, and lots of things other than distributing files publicly.
I would say its probably not a good idea to make a bucket directly publicly accessible, but people do not do that.
A lot of the point of serverless is convenience and less admin and things like adding a layer in front of the bucket that could authenticate, rate limit etc. is not convenient and requires more admin.
Because just using a cdn without proper caching headers is just another service you're paying for without any savings.
The real question is if they considered caching and thus configured it appropriately. If you don't, you're telling everyone you want every request to go to origin
Buckets are private by default.
And it's getting harder and harder to make them public because of people misconfiguring them and then going public against AWS when they discover the bill.
This story is giving "I leave OWASP top 10 vulns in my code because hacker mindset".
It's not that hard to configure access controls, they're probably cutting corners on other areas as well. I wouldn't trust anything this person is responsible for.
It's about rate limiting, not access controls. Without implementing limits your spend can go above what your budget is. Without cloud you hit natural rate limits of the hardware you are using to host.
> It's about rate limiting, not access controls.
You just shouldn't be using S3 to serve files directly. You can run most public and many private uses through CloudFront. Which gives you additional protections and reduces things like per object fetch costs.
> you hit natural rate limits
Seen by your customers or the public as a "denial of service." Which may actually be fine for the people who truly do want to limit their spending to less than $100/month.
That might be the more general solution but in this context it is absolutely also an access control issue.
with "classic" hosting, your server goes down from being overloaded to the hoster shutting it off.
with AWS, you wake up to a 6 figures bill.
No, s3 objects should always be private and then have a cloudfront proxy in front of them at the least. You should always have people hitting a cache for things like images.