Live data from Hacker News

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

lastweekinaws.com

131–140 of 284 posts

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

#131

> Availability Zones used to be randomized between accounts (my us-east-1a was your us-east-1c) WTH?

They did this to stop people from overloading us-east-1a.

It was fine, until there started to be ways of wiring up networks between accounts (eg PrivateLink endpoint services) and you had to figure out which AZ was which so you could be sure you were mapping to the the same AZs in each account.

I built a whole methodology for mapping this out across dozens of AWS accounts, and built lookup tables for our internal infrastructure… and then AWS added the zone ID to AZ metadata so that we could just look it up directly instead.

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

#132

Earlier quoted context omitted.

Yeah holy crap why is cloud formation so terrible?

It's designed to be a declarative DSL, but then you have to do all sorts of filters and maps in any group of resources and suddenly you are programming in yaml with both hands tied behind your back

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.

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

#133

I haven’t used AWS in the last 5 years. Is IPv6 still somewhat of an issue? I remember some services not supporting it at all and making it impossible to manage as a IPv6-only network.

Yeah, it’s still limited, and a few things still require at least a dual stack setup.

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

#134

Earlier quoted context omitted.

"The door is locked, so instead of suggesting to the end user that they should unlock the door with this key that we know how to give the end user deterministically, we instead tell them to drive across town and back on our toll roads and collect money from it" This has been a common gotcha for over a decade now: https://www.lastweekinaws.com/blog/the-aws-managed-nat-gatew...

Speaking solely on my own behalf: I don't know a single person at AWS (and I know a lot of them) who wants to mislead customers into spending more money than they need to. I remember a time before Gateway Endpoints existed, and customers (including me at the time) were spending tons of money passing traffic through pricey NAT Gateways to S3. S3 Gateway Endpoints saved them money.

Clearly you guys are aware of the problem though. I mean, every time this thing happens there's probably a ticket. I've personally filed one myself years ago when it happened to me. So why has the behavior not changed? You don't have to give up security to remove this footgun, it's possible to remove it and still make it an opt-in action for security purposes.

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

#135
post #65
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.

With CloudFront?

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

#136
post #121

Paid AWS support got a lot less capable on average during these two decades . :/ My recent interactions with them would probably have been better if they were an LLM.

They probably are an LLM and if they aren't, their higher management is pushing for them to be LLMs by 2027 at the latest.

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

#138

> Availability Zones used to be randomized between accounts (my us-east-1a was your us-east-1c) WTH?

It was for spreading load out. If someone was managing resources in a bunch of accounts and always defaulted to, say, 1b, AWS randomized what AZs corresponded to what datacenter segments to avoid hot spots.

The canonical AZ naming was provided because, I bet, they realized that the users who needed canonical AZ identifiers were rarely the same users that were causing hot spots via always picking the same AZ.

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

#140
post #36

Earlier quoted context omitted.

Well yeah that's the point....why route through the public internet.

I doubt the traffic ever actually leaves AWS. Assuming it does make it all the way out to their edge routers, the destination ASN will still be one of their own. Not that the pricing will reflect this, of course. The other problem with (interface) VPC endpoints is that they eat up IP addresses. Every service/region permutation needs a separate IP address drawn from your subnets. Immaterial if you're using IPv6, but c…

Sounds like a good reason to use IPv6.
Post reply on HN