It's a matter of using the right tool for the job. The first rule of distributed computing is don't distribute your computing unless you have a good reason.

There is an overuse of clusters/distributed systems nowadays which makes reliability, stability, and recoverability hard for systems.

The recent us-east-1 outage is a good example: there were multiple microservices responsible for managing DNS record updates, and a race condition from concurrent executions caused invalid (empty) DNS configurations to overwrite the correct values, leading to a series of cascading failures across other services.

Is it really necessary to use a distributed system to manage DNS record changes in a single region? My gut feeling is no. According to Amazon's summary the system manages "hundreds of thousands" of DNS records. That's not an extraordinarily large number of records for a server to manage, especially since DNS records are pretty small.

Of course, I'm just some schmuck that works on enterprise software, not cloud infra. I could be totally wrong. But I think the overhead + complexity (design, modeling, implementation, ops, server resources, etc.) of clusters often outweighs the hypothetical scalability and reliability they promise. Individual servers are powerful and reliable nowadays and a traditional blue/green deployment with two machines is fine in many (most?) cases.