12. Cost, Simplicity, and Operability

Every extra service, database, queue, cache, region, replica, gateway, and framework has a reliability, security, cost, and operational price. Architecture should be as complex as the requirements need, but no more. The Well-Architected guidance explicitly treats architecture as a set of trade-offs rather than independent maximization of every quality.

Evidence: S2, S3, S30, S32

Checklist

• Every major component has a clear responsibility.

• Every nontrivial pattern solves a named requirement or risk.

• We considered a simpler design and documented why it is insufficient if rejected.

• The team can operate the technology with available skills and support.

• Ownership is clear for services, data, alerts, and incidents.

• Runbooks exist for important failure and recovery procedures.

• Cost model includes normal load, peak load, redundancy, observability, and data transfer where material.

• High-availability choices match business value; not every component is made mission-critical by default.

• Operational work is automated where repetition creates risk.

• Architecture decisions record important trade-offs and revisit triggers.

Evidence: S2, S30, S32

Practical synthesis

A good design is not the design with the most patterns. It is the design whose behavior, limits, failures, security, operations, and change process are understood well enough to justify the trade-offs.