Live data from Hacker News

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

lastweekinaws.com

191–200 of 284 posts

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

#191

> As of very recently, you can also force EC2 instances to stop or terminate without waiting for a clean shutdown or a ridiculous timeout Not true for GPU instances, they're stuck 5 minutes in a stopping state because they run some GPU health checks.

For our VM solution, we get around this by hot staging VM's. As soon as one customer stops theirs, we reset everything and start it up again. To the end user, our compute seems to be instantly available. Unless of course, we run out.

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

#192

Earlier quoted context omitted.

I've read very definitive discussions on here that Glacier never used tape. It has always been powered off hard disks.

For truly write once read never data tape is the optimal storage method. It is exactly what the LTO standard was designed to do and it does it very well. You can be confident that you will be able to read every bit of data from a 30 year old tape, probably even 50 years old. It has the lowest bit error rate of any technology I am aware of. LTO-9 is better than 1 uncorrectable bit error in 10^20 user bits, which is 1…

Aren't LTO formats only backward compatible with the immediate prior version?

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

#193

Earlier quoted context omitted.

Sounds like a good reason to use IPv6.

There were still a couple of services/features that choked on IPv6 last time I looked (1.5-2 years ago) but it works with most things and they do seem to be making progress on the others.

I don’t know any software that doesn’t work with IPv6 as of 2021.

Just some internet services that haven’t upgraded. (But fixed by NAT.)

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

#194

Earlier quoted context omitted.

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.

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 using it, merely that it's a better idea than rawdogging json

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

#195

Earlier quoted context omitted.

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.

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 check a goddamn thing it intends to do to my cloud control plane

You may say "running 'plan' does" and I can offer 50+ examples clearly demonstrating that it does not catch the most facepalm of bugs

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

1. a tool that thinks nuking things is an appropriate fix ... whew. Although I guess in our new LLM world, saying such things makes me the old person who should get onboard the "nothing matters" train

and the language is a dumpster, imho

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

#197

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.

You'll be glad(sic) to know they have specialized hostnames for IPv6 control plane endpoints, because AAAA records scare the olds https://github.com/aws/aws-cli/blob/2.28.14/awscli/botocore/...

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

#198

Would love an AWS equivalent to Cloud Run but the lambda changes are welcome nonetheless.

Isn't Fargate the AWS equivalent of Cloud Run?

It seems Cloud Run comes "batteries included" for a lot more things that one must provision separate AWS resources to achieve https://cloud.google.com/architecture/migrate-aws-lambda-to-...

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

#199
post #173
post #150

Earlier quoted context omitted.

I still get strong Hyderabad vibes from the copy/pasting plus the occasional original sentence. Perhaps they trained the LLM using that data though. (Small customer though: yearly AWS spend around 80k. Support is 10% of that.)

TAMs are super hit and miss. We’ve had great ones (hi Nick!) and not so great ones. ($7-10M/mo customer AWS spend, support is a complicated sliding scale % of that, gogo ES!). Non-ES at smaller customers has been universally useless, except at quota increases.

If you're pushing 10 mil per month through AWS, I pray you have some bitcoin miners hidden in that spend. The mind reels

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

#200

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…

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