It's not just Amazon, but it's characteristically Amazon. What's fun is when other companies try to ape some of the practices without the actual ownership structures -- e.g. someone from your team is expected to be "on call", but even if there is a problem, you can't do much about it. And you're nominally a pure feature team, so even if you have some devops skills, you can't actually SSH into anything, you can't restart anything, you can't commit, build, and redeploy anything. You might have limited access to production data to at least look at, but you might need to request this first, which will take time to approve. So the typical decision you have to make is whether it's really the fault of code your team "owns" or not. If it is, is it a known issue or not. If not, and it's serious enough, you can try to find workarounds the end-user can do, or maybe find a code change and get that ready to be pushed out (absolute earliest time to hit production being hours with cooperation from others in the company -- namely the actual devops people, 'release engineers/managers', etc. -- and high-level signoff; if it's the weekend, expect Monday instead), or maybe the issue is close enough to a recent release window that you can argue for a rollback (which of course affects almost every other team, because Monolith). If you're lucky, there's some feature flag you made which is gating the breaking code that you can get toggled off (for everyone or just some subset) on the order of an hour or two, so long as turning it off doesn't create bigger issues, and until someone makes a mistake with that and breaks things for others, so now config changes also require high-level signoff, and take a long time to get through...
Or the company wants every team to add time-series DB-backed monitoring to everything now, and you have to use the same tech stack (no matter how good/bad) every other team is using, and you have to add a bunch of stuff even if there's no actionable thing you can do if a number crosses some threshold or what have you, because again, you don't actually own any of your deployment infrastructure. At best it can complement your regular application logs for debugging some issues and noticing trends (good or bad).
It doesn't have to be all bad though. When specialization works well, it works well, and there's at least a minimum level of service you can expect (even if it's not the best) without having to work for it yourself like you would if you owned all that extra stuff.
