Working at Amazon Web Services gave me strong exposure to distributed systems, operational ownership, and production-scale infrastructure, but there were definitely tradeoffs as well.
One downside was that, like many large organizations, ownership could become fragmented. You often own a subsystem or workflow rather than an entire product end-to-end, which can limit exposure to broader architectural decision-making unless you deliberately seek it out.
There was also significant process overhead. Design reviews, operational processes, dependency coordination, and organizational alignment were valuable for learning rigor, but they can slow iteration compared to smaller engineering teams.
Another challenge is that large internal ecosystems can abstract away infrastructure complexity. AWS has extensive internal tooling, deployment systems, and operational platforms, which are powerful, but some of that experience does not transfer directly outside the company.
I also found that operational work could dominate engineering time at points. Handling production issues, retries, integration failures, and on-call responsibilities teaches reliability engineering well, but it can reduce the amount of time spent on deeper technical exploration or greenfield development.
Finally, there is the perception aspect. AWS is a strong name, but experienced interviewers know there is wide variance between teams and roles. The company name opens doors, but ultimately you still need to demonstrate technical depth, ownership, and strong engineering judgment independently of the brand.
