I've actually really been of two minds about this since leaving AWS, though it's been a few years. On one hand, I remember spending an absurd amount of time debugging esoteric internal tooling errors that were un-googleable. The cases where you were lucky enough to find someone else who had the same issue on the internal stack-overflow or wiki were the good ones.
On the other hand, I've actually found myself missing features from amazon internal tools at the jobs I've had since. One example: I remember a pipelines feature where you could look at any change and quickly tell exactly how far that change had made it in your pipeline. At my current job, determining exactly when change X deployed to region Y has been a multi-step exercise in manually comparing commit hashes.
Right!? The observability on OSS CI/CD pipelines seems to be pretty lacking. Maybe I'll look for an opportunity there for my next position... :)
In fairness, I guess this is the tradeoff you get for being forced into "one and only one way to do it". The benefit is that all the tools are likely to play nice with one another "all the way through the flow", because they only have one representation format to be compatible with. The downside is, well, there's only one way to do it; and if that way happens to suck for you (as, for instance, for an ex-coworker who needed to build multiple different versions of the same code against different base OS images for...reasons), the tools are going to hinder more than they help.
On the other hand, I've actually found myself missing features from amazon internal tools at the jobs I've had since. One example: I remember a pipelines feature where you could look at any change and quickly tell exactly how far that change had made it in your pipeline. At my current job, determining exactly when change X deployed to region Y has been a multi-step exercise in manually comparing commit hashes.