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

231–240 of 284 posts

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

#231

Post by hnlmorg »

SvenL wrote: post #200
mdaniel wrote: post #195

Earlier quoted context omitted.

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…

Amen, and I would add to that list “no, just because you use terraform doesn’t mean you can simply switch between cloud providers”.

Is there any IaC solutions where you can “simply switch between cloud providers”?

This isn’t a limitation of TF, it’s an intended consequence of cloud vendor lock in

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

#232

Post by simianwords »

dcminter wrote: post #226
simianwords wrote: post #223

Earlier quoted context omitted.

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.

That's fair - I would definitely use stackoverflow liberally and dive into documentation when situation demands it.

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

#233

Post by anon7000 »

JCM9 wrote: post #81

Some good stuff here. I wish AWS would just focus on these boring, but ultimately important, things that they’re good at instead of all the current distractions trying to play catch up on “AI.” AWS leadership missed the boat there big time, but that’s OK. Ultimately AWS doesn’t have the right leadership or talent to be good at GenAI, but they do (or at least used to) have decent core engineers. I’d like to see them g…

They continue to have large teams working on core stuff. It’s just that they’re working at such a low level (like high perf virtualized networking on their custom network cards) that most people don’t hear about it or care that much.

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

#234

Post by bambax »

Self-hosting is the future. If you have small-to-modetate traffic it's extremely easy to do and very cheap.

Then you can self-cloud. Several startips are in this space. It gets you the best of both worlds: scaling, freedom, cost-control.

And no marketing jargon that you need to learn, and then unlearn!

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

#235

Post by bluecassette »

romperstomper wrote: post #186

> DynamoDB You can now have empty fields When this was changed? I think this is still an issue, I've had some such errors quite recently.

18th May 2020

> DynamoDB now supports empty values for non-key String and Binary attributes in DynamoDB tables. Empty value support gives you greater flexibility to use attributes for a broader set of use cases without having to transform such attributes before sending them to DynamoDB. List, Map, and Set data types also support empty String and Binary values.

https://docs.aws.amazon.com/amazondynamodb/latest/developerg...

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

#236

Post by vvoyer »

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.

This 2024 re:Invent session says exactly the opposite:

"If you want to partition your data even better, you can introduce some randomness in your key names": https://youtu.be/2DSVjJTRsz8?t=2206

FWIW The optimal way we were told was to partition our data was to do this: 010111/some/file.jpg.

Where `010111/` is a random binary string which will please both the automatic partitioning (503s => partition) and manual partitioning you could ask AWS. Please as in the cardinality of partitions grows slower at each characters vs prefixes like `az9trm/`.

We were told that the later version makes manual partitioning a challenge because as soon as you reach two characters you've already created 36x36 partitions (1,296).

The issue with that: your keys are no more meaningful if you're relying on S3 to have "folders" by tenants for example (customer1/..).

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

#237

Post by pcthrowaway »

lijok wrote: post #85
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?

You don’t raid old drives as it creates cascading failures because recovering from a failed drive adds major wear to other drives

This is less of a concern with RAID 6, and especially in Glacier's use case where reading any piece of data happens seldom, I'd expect it to be fine.

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

#238

Post by pcthrowaway »

themafia wrote: post #86
nodesocket wrote: post #58

I'll add: When doing instance to instance communication (in the same AZ) always use private ips. If you use public ip routing (even the same AZ) this is charged as regional data transfer. Even worse, if you run self hosted NAT instance(s) don't use a EIP attached to them. Just use a auto-assigned public IP (no EIP). NAT instance with EIP - AWS routes it through the public AWS network infrastructure (hairpinning). - Y…

> You get charged $0.01/GB regional data transfer, even if in the same AZ. My understanding is that transfer gets charged on both sides as well. So if you own both sides you'll pay $0.02/GB.

Is transfer into the instance not always free anymore?

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

#239

Post by benterix »

no_wizard wrote: post #141
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.

At what point is AWS worth using over other compute competitors when you’re using them as a storage bucket + VPS. They’re wholly more expensive at that point. Why not go with a more traditional but rock solid VPS provider? I have the opposite philosophy for what it’s worth: if we are going to pay for AWS I want to use it correctly, but maximally. So for instance if I can offload N thing to Amazon and it’s appropriate…

> That said, I strongly believe developers don’t do enough consideration as to how to maximize vendor usage in an optimal way

Because it's not straightforward. 1) You need to have general knowledge of AWS services and their strong and weak points to be able to choose the optimal one for the task, 2) you need to have good knowledge of the chosen service (like DynamoDB or Step Functions) to be able to use it optimally; being mediocre at it is often not enough, 3) local testing is often a challenge or plain impossible, you often have to do all testing on a dev account on AWS infra.

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

#240

Post by awongh »

dcminter wrote: post #210
awongh wrote: post #153

Earlier quoted context omitted.

This is exactly what I use LLMs for. To just read the docs for me and pull out the base level demo code that's buried in all the AWS documentation. Once I have that I can also ask it for the custom tweaks I need.

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.

This is LLM as semantic search- so it's way way easier to start from the basic example code and google to confirm that it's correct than it is to read the docs from scratch and piece together the basic example code. Especially for things like configurations and permissions.
Post reply on HN