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

251–260 of 284 posts

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

#251

Post by kbolino »

paulddraper wrote: post #193
kbolino wrote: post #156

Earlier quoted context omitted.

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.)

There's a matrix provided by Amazon themselves listing the level of IPv6 support in their various services: https://docs.aws.amazon.com/vpc/latest/userguide/aws-ipv6-su...

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

#252

Post by albert_e »

A "Catch me up" on AWS (and for that matter other large platforms) would be very useful for many folks.

Ideally it should be a stream of important updates that can be interactively filtered by time-range. For example, if I have not been actively consuming AWS updates firehose for last 18 months, I should be able to "summarize" that length of updates.

Why this is not already a feature of "What's New" section of AWS and other platforms -- I dont know. Waiting to be built -- either by OEM or by the Community.

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

#253

Post by ash_091 »

albert_e wrote: post #252

A "Catch me up" on AWS (and for that matter other large platforms) would be very useful for many folks. Ideally it should be a stream of important updates that can be interactively filtered by time-range. For example, if I have not been actively consuming AWS updates firehose for last 18 months, I should be able to "summarize" that length of updates. Why this is not already a feature of "What's New" section of AWS an…

I played a lot of DOTA2 in the past and I've often thought that big tech could learn something from Valve's patch notes. Especially in the context of process changes, stuff you should know, etc. Expecting folk to read a series of lengthy emails/blog posts to stay up to date is unrealistic.

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

#254

Post by luluthefirst »

simonw wrote: post #74
sylens wrote: post #51

Earlier quoted context omitted.

The thing to keep in mind with the "Block Public Access" setting is that is a redundancy built in to save people from making really big mistakes. Even if you have a terrible and permissive bucket policy or ACLs (legacy but still around) configured for the S3 bucket, if you have Block Public Access turned on - it won't matter. It still won't allow public access to the objects within. If you turn it off but you have a…

I think this is the key of why I find it confusing: I need a very clear diagram showing which rules override which other rules.

They don't really override each other but they act like stacked barriers, like a garage door blocking access to an open or closed car. Access is granted if every relevant layer allows it.

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

#255

Post by gchamonlive »

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…

All Terraform does is build a DAG, compare it with the current state file and pass the changes down to the provider so it can translate to the correct sequence of interactions with the upstream API. Most of your criticism boils down to limitations of the cloud provider API and/or Terraform provider quality. It won't check for naming collision for instance, it assumes you know what you are doing.

Regarding HCL, I respect their decision to keep the language minimal, and for all it's worth you can go very, very far with the language expressions and using modules to abstract some logic, but I think it's a fair criticism for the language not to support custom functions and higher level abstractions.

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

#256

Post by tkjef »

SteveNuts wrote: post #71
gigatexal wrote: post #67

Earlier quoted context omitted.

Yeah holy crap why is cloud formation so terrible?

Last time I tried to use CF, the third party IAC tools were faster to release new features than the functionality of CF itself. (Like Terraform would support some S3 bucket feature when creating a bucket, but CF did not). I'm not sure if that's changed recently, I've stopped using it.

I have been on the terraform side for 7 years-ish.

eksctl just really impressed me with its eks management, specifically managed node groups & cluster add-ons, over terraform.

that uses cloudformation under the hood. so i gave it a try, and it’s awesome. combine with github actions and you have your IAC automation.

nice web interface for others to check stacks status, events for debugging and associated resources that were created.

oh, ever destroy some legacy complex (or not that complex) aws shit in terraform? it’s not going to be smooth. site to site connections, network interfaces, subnets, peering connections, associated resources… oh, my.

so far cloudformation has been good at destroying, but i haven’t tested that with massive legacy infra yet.

but i am happily converted tf>cf.

and will happily use both alongside each other as needed.

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

#257

Post by mdaniel »

hnlmorg wrote: post #225
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…

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 wri…

> CloudFormation is the only IaC that supports "running as a URL"

Incorrect, ARM does too, they even have a much nicer icon for one click "Deploy to Azure" https://learn.microsoft.com/en-us/azure/azure-resource-manag...> and as a concrete example (or whole repo of them): https://github.com/Azure/azure-quickstart-templates/tree/2db...>

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

Did you read the rest of the sentence? I said it's the worst of both worlds: I can't run "plan" without live creds, but then it doesn't use them to check jack shit. Also, to circle back to our CF and Bicep discussion, no, I don't need cloud creds to write code for those stacks - I need only creds to apply them

I don't need a state file for CF nor Bicep. Mysterious about that, huh?

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

#258

Post by mdaniel »

hnlmorg wrote: post #231
SvenL wrote: post #200

Earlier quoted context omitted.

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

I believe the usual uninformed thinking is "terraform exists outside of AWS, so I can move off of AWS" versus "we have used CF or Bicep, now we're stuck" kind of deal

Which is to say both of you are correct, but OP was highlighting the improper expectations of "if we write in TF, sure it sucks balls but we can then just pivot to $other_cloud" not realizing it's untrue and now you've used a rusty paintbrush as a screwdriver

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

#259

Post by reactordev »

pas wrote: post #218
reactordev wrote: post #181

Earlier quoted context omitted.

You say this, someone challenges you, now you're on the defensive during an interview and everyone has a bad taste in their mouth. Yeah, that's how it goes.

That's just the taste of iron from the blood after the duel. But this is completely normal after a formal challenge! Companies want real cyberwarriors, and the old (lame) rockstar ninjas that they hired 10 years ago are very prone to issuing these.

I don’t want to go to war, I just want a quiet house in the mountains and a career that allows me to think about things.

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

#260

Post by mdaniel »

austinshea wrote: post #182
no_wizard wrote: post #141

Earlier quoted context omitted.

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…

Most work isn’t greenfield. AWS can be used in a different, cost effective, way. It can be used as a middle-ground capable of serving the existing business, while building towards a cloud agnostic future. The good AWS services (s3, ec2, acm, ssm, r53, RDS, metadata, IAM, and E/A/NLBs) are actually good, even if they are a concern in terms of tracking their billing changes. If you architect with these primitives, you…

Of that list, watch out since IAM != IAM != IAM, so "cloud agnostic" is that famous 80/20 split
Post reply on HN