Every outage I have worked has the same moment in it. Somebody finally finds the cause, and the room goes quiet, because the cause is a piece of the system nobody had thought about in a year. It was added for a good reason. The person who added it has moved on. It worked fine until the night it did not.
That moment is what people are actually buying when they buy simplicity. Not elegance, and not minimalism for its own sake. They are buying the ability to understand their own system at two in the morning, when the pager is going off and the customer is already on the phone.
Most teams do not choose complexity. They accumulate it. A queue gets added to solve a timing problem. A cache goes in front of a database that was slow that quarter. A second cloud account shows up because one team needed isolation. A managed service gets adopted, then half replaced, then left in place because removing it is nobody's priority. Every one of those decisions was defensible on the day it was made. The trouble is that nobody ever schedules the day where you take something out.
This shows up in two places on your financials, and the first is cost.
Complexity is expensive in ways that never appear as a single line item. Duplicate storage because some pipeline wanted its own copy of the data. Traffic charges between services that ought to live closer together. Environments stood up to evaluate something and never switched off. Capacity sized for a launch that happened three years ago. When I run a cost assessment, the savings almost never come from negotiating a better rate. They come from finding things that are running for no reason, and the harder a stack is to reason about, the more of those you have. I have yet to see an environment where the biggest win was a discount rather than a deletion.
The second is uptime, and it is the one people underestimate.
Availability is usually treated as a function of redundancy. Add another zone, add a replica, add a failover path. That works for hardware failure, which is not what takes most systems down. What takes systems down is change, and change goes wrong most often in the places where the people making it do not fully understand what they are touching. A system with forty components and six engineers does not have a redundancy problem. It has a comprehension problem, and no amount of duplicate infrastructure fixes that.
Right sizing is the discipline of matching the stack to the team that has to operate it. For every component you run, somebody on staff should be able to explain what it does, why it is there, and what happens when it fails. Where that is not true, you have found either a documentation gap, a training gap, or something that should come out. All three are worth knowing about before an incident tells you.
The test I use with clients is simple. Imagine the two people who know the most about your infrastructure are both unavailable for a week. Can the rest of the team keep the system running, deploy a change safely, and recover from a failure? If the honest answer is no, that is not a staffing problem. The system has outgrown the organization that owns it, and adding more technology will make it worse rather than better.
The good news is that this is usually cheaper to fix than people expect. Consolidating costs less than buying more. What it takes is somebody looking at the whole picture, deciding what earns its place, and saying plainly what does not.
If that sounds like your environment, an infrastructure assessment is where we normally start. Two weeks, a clear picture of what you are running, and a prioritized list of what to keep, what to consolidate, and what to retire.