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

AWS in 2025: Stuff you think you know that's now wrong

lastweekinaws.com

Post reply on HN
Print view View original

91–100 of 284 posts

Re: AWS in 2025: Stuff you think you know that's now wrong

#91

Post by cavisne »

bob1029 wrote: post #69
hinkley wrote: post #60

Earlier quoted context omitted.

> Once upon a time Glacier was its own service that had nothing to do with S3. If you look closely (hi, billing data!) you can see vestiges of how this used to be, before the S3 team absorbed it as a series of storage classes. Your assumption holds if they still use tape. But this paragraph hints at it not being tape anymore. The eternal battle between tape versus drive backup takes another turn.

I am also assuming that Amazon intends for the Deep Archive tier to be a profitable offering. At $0.00099/gb-month, I don't see how it could be anything other than tape.

http://www.patentbuddy.com/Patent/20140047261

Is tape even cost competitive anymore? The market would be tiny.

Re: AWS in 2025: Stuff you think you know that's now wrong

#92

Post by SOLAR_FIELDS »

icedchai wrote: post #89
SOLAR_FIELDS wrote: post #44

Earlier quoted context omitted.

The problem is that the default behavior for this is opt-in, rather than opt-out. No one prefers opt-in. So why is it opt-in?

If it were opt-out someone would accidentally leave it on and eventually realize that entire systems had been accidentally "backed up" and exfiltrated to S3.

What? The same is possible whether it's opt-in or opt-out. It's just that if you have the gateway as opt-out you wouldn't also have this problem AND a massive AWS bill. You would just have this problem.

Re: AWS in 2025: Stuff you think you know that's now wrong

#93

Post by hinkley »

bob1029 wrote: post #83
simonw wrote: post #76

Earlier quoted context omitted.

I wonder if it's where old S3 hard drives go to die? Presumably AWS have the world's single largest collection of used storage devices - if you RAID them up you can probably get reliable performance out of them for Glacier?

I still don't know if it's possible to make it profitable with old drives in this kind of arrangement, especially if we intend to hit their crazy durability figures. The cost of keeping drives spinning is low, but is double-digit margin % in this context. You can't leave drives unpowered in a warehouse for years on end and say you have 11+ nines of durability.

Unpowered in a warehouse is a huge latency problem.

For storage especially we now build enough redundancy into systems that we don't have to jump on every fault. That reduces the chance of human error when trying to address it, and pushing the hardware harder during recovery (resilvering, catching up in a distributed concensus system, etc).

When the entire box gets taken out of the rack due to hitting max faults, then you can piece out the machine and recycle parts that are still good.

You could in theory ship them all off to the backend of nowhere, but it seems that Glacier is all the places where AWS data centers are, so it's not that. But Glacier being durable storage, with a low expectation of data out versus data in, they could and probably are cutting the aggregate bandwidth to the bone.

How good do your power backups have to be to power a pure Glacier server room? Can you use much cheaper in-rack switches? Can you use old in-rack switches from the m5i era?

Also most of the use cases they mention involve linear reads, which has its own recipe book for optimization. Including caching just enough of each file on fast media to hide the slow lookup time for the rest of the stream.

Little's Law would absolutely kill you in any other context but we are linear write, orders of magnitude fewer reads here. You have hardware sitting around waiting for a request. "Orders of magnitude" is the space where interesting solutions can live.

Re: AWS in 2025: Stuff you think you know that's now wrong

#94

Post by tester756 »

andrewmcwatters wrote: post #46
simonw wrote: post #7

S3: "Block Public Access is now enabled by default on new buckets." On the one hand, this is obviously the right decision. The number of giant data breeches caused by incorrectly configured S3 buckets is enormous. But... every year or so I find myself wanting to create an S3 bucket with public read access to I can serve files out of it. And every time I need to do that I find something has changed and my old recipe d…

This sort of thing drives me nuts in interviews, when people are like, are you familiar with such-and-such technology? Yeah, what month?

If you're aware of changes, then explain that there were changes over time, that's it

Re: AWS in 2025: Stuff you think you know that's now wrong

#95

Post by tayo42 »

hnlmorg wrote: post #53
crinkly wrote: post #38

Earlier quoted context omitted.

I just stick CloudFront in front of those buckets. You don't need to expose the bucket at all then and can point it at a canonical hostname in your DNS.

That’s definitely the “correct” way of doing things if you’re writing infra professionally. But I do also get that more casual users might prefer not to incur the additional costs nor complexity of having CloudFront in front. Though at that point, one could reasonably ask if S3 is the right choice for causal users.

>S3 is the right choice for causal users.

It's so simple for storing and serving a static website.

Are there good and cheap alternatives?

Re: AWS in 2025: Stuff you think you know that's now wrong

#96

Post by regularfry »

general1726 wrote: post #72

I think there is more of us who kind of degenerated from doing it the AWS way - API Gateway, serverless lambdas mess around with IAM roles until it works, ... - to - Give me EC2 / LightSail VPS instance maybe an S3 bucket let's set domain through Route53 and go away with the rest of your orchestrion AWS.

Honestly just having to manage IAM is such a time-suck that the way I've explained it to people is that we've traded the time we used to spend administering systems for time spent just managing permissions, and IAM is so obtuse that it comes out as a net loss.

There's a sweet spot somewhere in between raw VPSes and insanely detailed least-privilege serverless setups that I'm trying to revert to. Fargate isn't unmanageable as a candidate, not sure it's The One yet but I'm going to try moving more workloads to it to find out.

Re: AWS in 2025: Stuff you think you know that's now wrong

#97

Post by beaviskhan »

Also S3 related: the bucket owner can now be configured as the object owner no matter where the object originated. In the past this was exceedingly painful if you wanted to allow one account contribute objects to a bucket in another account. You could do the initial contribution, but the contributor always owned the object, and you couldn't delegate access to a third account.

Re: AWS in 2025: Stuff you think you know that's now wrong

#98

Post by MaKey »

tayo42 wrote: post #95
hnlmorg wrote: post #53

Earlier quoted context omitted.

That’s definitely the “correct” way of doing things if you’re writing infra professionally. But I do also get that more casual users might prefer not to incur the additional costs nor complexity of having CloudFront in front. Though at that point, one could reasonably ask if S3 is the right choice for causal users.

>S3 is the right choice for causal users. It's so simple for storing and serving a static website. Are there good and cheap alternatives?

Yeah, your classic web hoster. Just today I uploaded a static website to one via FTP.

Re: AWS in 2025: Stuff you think you know that's now wrong

#99

Post by Spivak »

SOLAR_FIELDS wrote: post #92
icedchai wrote: post #89

Earlier quoted context omitted.

If it were opt-out someone would accidentally leave it on and eventually realize that entire systems had been accidentally "backed up" and exfiltrated to S3.

What? The same is possible whether it's opt-in or opt-out. It's just that if you have the gateway as opt-out you wouldn't also have this problem AND a massive AWS bill. You would just have this problem.

The bad situation is if you created a VPC with no internet access but the hypothetical automatic VPC endpoint still let instances access S3. Then a compromised instance has a vector for data exfiltration.

Re: AWS in 2025: Stuff you think you know that's now wrong

#100

Post by viccis »

>In EC2, you can now change security groups and IAM roles without shutting the instance down to do it.

Hasn't it been this way for many years?

>Spot instances used to be much more of a bidding war / marketplace.

Yeah because there's no bidding any more at all, which is great because you don't get those super high spikes as availability drops and only the ones who bid super high to ensure they wouldn't be priced out are able to get them.

>You don’t have to randomize the first part of your object keys to ensure they get spread around and avoid hotspots.

This one was a nightmare and it took ages to convince some of my more pig headed coworkers in the past that they didn't need to do it any more. The funniest part is that they were storing their data as millions and millions of 10-100kb files, so the S3 backend scaling wasn't the thing bottlenecking performance anyway!

>Originally Lambda had a 5 minute timeout and didn’t support container images. Now you can run them for up to 15 minutes, use Docker images, use shared storage with EFS, give them up to 10GB of RAM (for which CPU scales accordingly and invisibly), and give /tmp up to 10GB of storage instead of just half a gig.

This was/is killer. It used to be such a pain to have to manage pyarrow's package size if I wanted a Python Lambda function that used it. One thing I'll add that took me an embarrassingly long time to realize is that your Python global scope is actually persisted, not just the /tmp directory.

Post reply on HN