The cheapest fix is usually configuration

When something is slow or expensive, the discussion moves quickly to architecture. Architecture is interesting, and architectural change is expensive, slow and risky. It is worth an afternoon first to rule out the boring explanations.

The usual suspects

A recurring set of causes turns up far more often than design flaws:

• An instance sized for a launch that happened two years ago.
• A missing database index on a query that grew with the table.
• Log retention set to forever, quietly becoming a real line item.
• A staging environment running at production size, around the clock.
• No lifecycle policy on object storage, so nothing ever ages out.
• A cache that was configured and then disabled during an incident, and never re-enabled.

None of these is interesting, which is exactly why they persist: nobody gets assigned to look for them.

Measure, then decide

Proper cost attribution and a week of real performance data usually identify the top few contributors precisely. Acting on measurement rather than intuition is the difference between a configuration change and a quarter of work.

Why these survive

They survive because they are nobody’s job. There is no ticket for an oversized instance, and nothing fails. The fix is as much a review habit as a technical change.

Then do the architecture

Sometimes the design really is the problem and the work is genuinely needed. That case is far easier to make, and far easier to size, once the cheap explanations have been eliminated and the remaining number is known.