[TheSoftwareGuy]

>It's not like there's some secret sauce here in most of these implementation details. If there was, I'd understand not telling us. This is probably less an Apple-style culture of secrecy and more laziness and a belief that important details have been abstracted away from us users because "The Cloud" when in fact, these details do really matter for performance and other design decisions we have to make.

Having worked inside AWS I can tell you one big reason is the attitude/fear that anything we put in out public docs may end up getting relied on by customers. If customers rely on the implementation to work in a specific way, then changing that detail requires a LOT more work to prevent breaking customer's workloads. If it is even possible at that point.

[wubrr]

Right now, it is basically impossible to reliably build full applications with things like DynamoDB (among other AWS products), without relying on internal behaviour which isn't explicitly documented.

[cbsmith]

I've built several DynamoDB apps, and while you might have some expectations of internal behaviour, you can build apps that are pretty resilient to change of the internal behaviour but rely heavily on the documented behaviour. I actually find the extent of the opacity a helpful guide on the limitations of the service.

[JustExAWS]

I am also a former AWS employee. What non public information did you need for DDB?

[mannyv]

Totally incorrect for Dynamo.

It was probably correct for Cognito 1.0.

[libraryofbabel]

And yet "Hyrum's Law" famously says people will come to rely on features of your system anyway, even if they are undocumented. So I'm not convinced this is really customer-centric, it's more AWS being able to say: hey sorry this change broke things for you, but you were relying on an internal detail. I do think there is a better option here where there are important details that are published but with a "this is subject to change at any time" warning slapped on them. Otherwise, like OP says, customers just have to figure it all out on their own.

[TheSoftwareGuy]

You're right, people absolutely do rely on internal behavior intentionally and sometimes even unintentionally. And we tried our hardest not to break any of those customers either. but the point is that putting something in the docs is seen as a promise that you can rely on it. And going back on a promise is the exact opposite of the "Earns Trust" leadership principal that everyone is evaluated against.

[lazide]

Sure, but the court isn’t going to consider hyrum’s law in a tort claim, but might consider AWS documentation - even with a disclaimer - with more weight.

Rely on undocumented behavior at your own risk.

[simonw]

Thanks for this, that's a really insightful comment.

[thiagowfx]

https://www.hyrumslaw.com/

[scarface_74]

You have been quoted Simon Willison on his blog - his blog is popular on HN.

https://simonwillison.net/2025/Sep/8/thesoftwareguy/#atom-ev...

[UltraSane]

Just add an option to re-enable spacebar heating.