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

221–230 of 284 posts

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

#221

Post by hnlmorg »

mdaniel wrote: post #194
gigatexal wrote: post #132

Earlier quoted context omitted.

Yeah it’s just terrible. If Amazon knew what was good they’d just replace it with almost anything else. Heck just got all in on terraform and call it a day.

This may be heresy in an AWS thread, but as a concept Bicep actually isn't terrible: https://github.com/Azure/bicep/blob/v0.37.4/src/Bicep.Cli.E2... It does compile down to Azure Resource Manager's json DSL, so in that way close to Troposphere I guess, only both sides are official and not just some rando project that happens to emit yaml/json The implementation, of course, is ... very Azure, so I don't mean to praise…

I’ve heard so many bad things about bicep on Azure that I’m not convinced it’s an upgrade over TF.

The syntax does look nicer but sadly that’s just a superficial improvement.

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

#222

Post by jcattle »

simianwords wrote: post #212
dcminter wrote: post #210

Earlier quoted context omitted.

This could not possibly go wrong... You're braver than me if you're willing to trust the LLM here - fine if you're ready to properly review all the relevant docs once you have code in hand, but there are some very expensive risks otherwise.

There’s nothing brave in this. It generally works the way it should and even if it doesn’t - you just go back to see what went wrong. I take code from stack overflow all the time and there’s like a 90% chance it can work. What’s the difference here?

However on AWS the difference between "generally working the way it should and not working the way it should" can be a 30,000$ cloud bill racked up in a few hours with EC2 going full speed ahead mining bitcoin.

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

#223

Post by simianwords »

dcminter wrote: post #219
simianwords wrote: post #212

Earlier quoted context omitted.

There’s nothing brave in this. It generally works the way it should and even if it doesn’t - you just go back to see what went wrong. I take code from stack overflow all the time and there’s like a 90% chance it can work. What’s the difference here?

Well, the "accidentally making the S3 bucket public" scenario would be a good one. If you review carefully with full understanding of what e.g. all your policies are doing then great, no problem. If you don't do that will you necessarily notice that you accidentally leaked customer data to the world? The problem isn't the LLM it's assuming its output is correct just the same as assuming Stack Overflow answers are cor…

I agree but its about the extent. I'm willing to accept the risk of ocassionally making S3 public but getting things done much faster, much like I don't meticulously read documentation when I can get the answer from stackoverflow.

If you are comparing with stackoverflow then I guess we are on the same page - most people are fine with taking stuff from stackoverflow and it doesn't count as "brave".

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

#224

Post by simianwords »

jcattle wrote: post #222
simianwords wrote: post #212

Earlier quoted context omitted.

There’s nothing brave in this. It generally works the way it should and even if it doesn’t - you just go back to see what went wrong. I take code from stack overflow all the time and there’s like a 90% chance it can work. What’s the difference here?

However on AWS the difference between "generally working the way it should and not working the way it should" can be a 30,000$ cloud bill racked up in a few hours with EC2 going full speed ahead mining bitcoin.

For those high stakes cases maybe you can be more careful. You can still use an LLM to search and get references to the appropriate place and do your own verification.

But for low stakes LLM works just fine - not everything is going to blow up to a 30,000 bill.

In fact I'll take the complete opposite stance - verifying your design with an LLM will help you _save_ money more often than not. It knows things you don't and has awareness of concepts that you might have not even read about.

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

#225

Post by hnlmorg »

mdaniel wrote: post #195
gigatexal wrote: post #132

Earlier quoted context omitted.

Yeah it’s just terrible. If Amazon knew what was good they’d just replace it with almost anything else. Heck just got all in on terraform and call it a day.

As for "go all in on terraform," I pray to all that is holy every night that terraform rots in the hell that spawned it. And that's not even getting into the rug pull parts, I mean the very idea of 1. I need a goddamn CLI to run it (versus giving someone a URL they can load in their tenant and have running resources afterward) 1. the goddamn CLI mandates live cloud credentials, but then stright-up never uses them to…

There's a lot wrong with Terraform but I don't think you're being at all fair with your specific critisims here:

> 1. I need a goddamn CLI to run it (versus giving someone a URL they can load in their tenant and have running resources afterward)

CloudFormation is the only IaC that supports "running as a URL" and that's only because it's an AWS native solution. And CloudFormation is a hell of a lot more painful to write and slower to iterate on. So you're not any better off for using CF.

What usually happens with TF is you'd build a deploy pipeline. Thus you can test via the CLI then deploy via CI/CD. So you're not limited to just the CLI. But personally, I don't see the CLI as a limitation.

> the goddamn CLI mandates live cloud credentials, but then stright-up never uses them to check a goddamn thing it intends to do to my cloud control plane

All IaC requires live cloud credentials. It would be impossible for them to work without live credentials ;)

Terraform does do a lot of checking. I do agree there is a lot that the plan misses though. That's definitely frustrating. But it's a side effect of cloud vendors having arbitrary conditions that are hard to define and forever changing. You run into the same problem with any tool you'd use to provision. Heck, even manually deploying stuff from the web console sometimes takes a couple of tweaks to get right.

> 1. related to that, having a state file that believes it knows what exists in the world is just ludicrous and pain made manifest

This is a very strange complaint. Having a state file is the bare minimum any IaC NEEDS for it to be considered a viable option. If you don't like IaC tracking state then you're really little better off than managing resources manually.

> a tool that thinks nuking things is an appropriate fix ... whew.

This is grossly unfair. Terraform only destroys resources when:

1. you remove those resources from the source. Which is sensible because you're telling Terraform you no longer want those resources

2. when you make a change that AWS doesn't support doing on live resources. Thus the limitation isn't Terraform, it is AWS

In either scenario, the destroy is explicit in the plan and expected behaviour.

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

#226

Post by dcminter »

simianwords wrote: post #223
dcminter wrote: post #219

Earlier quoted context omitted.

Well, the "accidentally making the S3 bucket public" scenario would be a good one. If you review carefully with full understanding of what e.g. all your policies are doing then great, no problem. If you don't do that will you necessarily notice that you accidentally leaked customer data to the world? The problem isn't the LLM it's assuming its output is correct just the same as assuming Stack Overflow answers are cor…

I agree but its about the extent. I'm willing to accept the risk of ocassionally making S3 public but getting things done much faster, much like I don't meticulously read documentation when I can get the answer from stackoverflow. If you are comparing with stackoverflow then I guess we are on the same page - most people are fine with taking stuff from stackoverflow and it doesn't count as "brave".

I think anyone who just copies and pastes from SO is indeed "brave" for pretty much exactly the same reason.

> I'm willing to accept the risk of ocassionally making S3 public

This is definitely where we diverge. I'm generally working with stuff that legally cannot be exposed - with hefty compliance fines on the horizon if we fuck up.

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

#227

Post by hnlmorg »

damieng wrote: post #120
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.

I'd argue putting CloudFront on top of S3 is less complex than getting the permissions and static sharing setup right on S3 itself.

I do get where you're coming from, but I don't agree. With the CF+S3 combo you now need to choose which sharing mode to work with S3 (there are several different ways you can link CF to S3). Then you have the wider configuration of CF to manage too. And that's before you account for any caching issues you might run into when debugging your site.

If you know what you're doing, as it sounds like you and I do, then all of this is very easy to get set up (but then aren't most things easy when you already know how? hehe). However we are talking about people who aren't comfortable with vanilla S3, so throwing another service into the mix isn't going to make things easier for them.

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

#228

Post by hnlmorg »

crinkly wrote: post #65
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.

It's actually incredibly cheap. I think our software distribution costs, in the account I run, are around $2.00 a month. That's pushing out several thousand MSI packages a day.

S3 is actually quite expensive compared to the competition for both storage costs and egress costs. At a previous start-up, we had terrabytes of data on S3 and it was our second largest cost (after GPUs) and by some margin.

For small scale stuff, S3s storage and egress charges are unlikely to be impactful. But it doesn’t mean they’re cheap relative to the competition.

There are also ways you can reduce S3 costs, but then you're trading the costs received from AWS with the costs of hiring competent DevOps. Either way, you pay.

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

#229

Post by afandian »

time0ut wrote: post #35
afandian wrote: post #10

Earlier quoted context omitted.

Having experienced the joy of setting up VPC, subnets and PrivateLink endpoints the whole thing just seems absurd. They spent the effort of branding private VPC endpoints "PrivateLink". Maybe it took some engineering effort on their part, but it should be the default out of the box, and an entirely unremarkable feature. In fact, I think if you have private subnets, the only way to use S3 etc is Private Link (correct…

You can provision gateway endpoints for S3 and DynamoDB. They are free and considered best practice. They are opt-in though, but easy to enable.

True, I forgot that. But depending on services you still have to have some Gateway and some Interface endpoints.

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

#230

Post by ed_g »

cldcntrl wrote: post #2

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

Generally speaking this isn't something Amazon S3 customers need to worry about - as others have said, S3 will automatically scale index performance over time based on load. The challenge primarily comes when customers need large bursts of requests within a namespace that hasn't had a chance to scale - that's when balancing your workload over randomized prefixes is helpful.

Please see the documentation: https://docs.aws.amazon.com/AmazonS3/latest/userguide/optimi...

This 2024 re:Invent session "Optimizing storage performance with Amazon S3 (STG328)" which goes very deep on the subject: https://www.youtube.com/watch?v=2DSVjJTRsz8

And this blog that discusses Iceberg's new base-2 hash file layout which helps optimize request scaling performance of large-scale Iceberg workloads running on S3: https://aws.amazon.com/blogs/storage/how-amazon-ads-uses-ice...

Post reply on HN