AWS services don't mesh nice with each other, and the reason "software architecture" exists in the first place is so that disparate teams and technologies play nice with each other.
An "Architect" can't solve this problem anymore than an "Engineer" can fix the problem of technical debt because neither person can see the future. It's like pointing at everything wrong with a piece of technology and saying an "Architect" could've fixed that in hindsight.
"Architects" are not the solution to technical design and technical debt.
An engineering manager can place all engineers in a room and ask them to come up with an "architecture" that is the same if not better than anything a single "Architect" can come up with, and this "Architecture" will never solve the problem of technical debt for the same reason why we can't predict stock prices.
In fact, this problem is probably more prevalent in greenfield over-engineered solutions than old legacy-ridden ones.
(And really much of what we call "technical debt" is just the scaffolding we put together over the years to make stuff be compatible.)
Theoretically, those "software architects" would put a stop to "over-engineered" solutions, but why do these companies still have technical debt?
Most likely because technical debt is not solely just "over engineered" solutions.
Yup. In that context, it is usually called Second System Syndrome (when discussing the person that is laboring under it's influence while in the act of designing) or Second System Effect (when discussing the resulting system):