Design principles of the AWS Cloud

The AWS Well-Architected Framework is a set of best practices organized into six pillars. Know each pillar's focus well enough to tell them apart from a one-line scenario.

The six pillars

• Operational excellence: Running and monitoring systems and continually improving processes: operations as code, small reversible changes, learning from failures.
• Security: Protecting data, systems, and assets: strong identity foundation, traceability, security at every layer, encryption in transit and at rest.
• Reliability: A workload performs its intended function correctly and consistently, and recovers from failure: automatic recovery, scale horizontally, test recovery procedures.
• Performance efficiency: Using computing resources efficiently as demand and technology change: pick the right resource types, go global, use serverless, experiment more often.
• Cost optimization: Delivering business value at the lowest price point: consumption-based model, measure efficiency, stop paying for idle resources.
• Sustainability: Minimizing the environmental impact of workloads: maximize utilization, use managed services, reduce the downstream impact of your workload.

Telling pillars apart

• Recovering from an outage or a failed component points to Reliability. Choosing the right instance type for speed points to Performance efficiency.
• Reducing energy use or hardware footprint points to Sustainability, even when it also saves money.
• Runbooks, automation of operations, and post-incident learning point to Operational excellence.
• The AWS Well-Architected Tool (in the console) lets you review a workload against the pillars and track improvements.

General cloud design principles

• Stop guessing capacity needs: scale with demand instead of buying for the peak.
• Test systems at production scale, then tear the test environment down so you only pay while testing.
• Automate with architectural experimentation in mind: infrastructure as code makes changes cheap and repeatable.
• Design for failure: assume components will fail, and remove single points of failure (for example, use multiple Availability Zones).
• Use loosely coupled components (queues, events) so one part can fail or scale without breaking the others.
• Prefer managed and serverless services so AWS does the undifferentiated heavy lifting.