It's not really a UI issue.

The tool as a whole should incorporate a model of S3. Any action you take through the UI should first be applied to this model, and then the resulting impact analyzed. If the impact is "service goes down", then don't apply the action without raising red flags.

Where I work we use PCS for high availability, and it bugs the heck out of me that a fat-fingered command can bring down a service. PCS knows what the effect of any given command will be, but there's no way (that I know of) to do a "dry run" to see whether your services would remain up afterward.

Interesting.

In practice, it would likely be very hard to make a model of your infrastructure to test against, but I can imagine a tool that would run each query against a set of heuristics, and if any flags pop up, it would make you jump through some hoops to confirm. Such a tool should NEVER have an option to silently confirm, and the only way to adjust a heuristic if it becomes invalid should be formally getting someone from an appropriate department to change it and sign off on it.

By the way, this is how companies acquire red tape. It's like scar tissue.

For many systems, the rule is simply "X of Y servers must be up". Something like that isn't too hard to enforce.

They probably didn't know the service would go down. For that, you need to identify the minimal requirements for the service to be up upfront, and code that requirements into the UI upfront. Most tools don't do that. File managers don't check the file you delete is not necessary for any of the installed software packages to run. Shells don't check the file you overwriting doesn't contain vital config file. Firewall UIs don't check that this port you're closing isn't vital for some infrastructural service. It would be nice to have a benevolent omniscient God-like UI that would have foresight to check such things - but usually the way it works is that you know about these things after the first (if you're lucky) time it breaks.

Or it makes you re-enter the quantity of affected targets as a confirmation, similar to the way GitHub requires a second entry of a repo name for deletion.