AWS Deep Dive

AWS Well-Architected Framework



The Well-Architected Framework uses somewhat eccentric definitions of “component” (mostly normal) and “workload” (not really normal). In the Well-Architected Framework, a component is a unit of something (code, application configuration, S3 bucket, etc.) that meets some atomic requirement. A workload is then a collection of components that performs a distinct business function (this is in contrast to the more usual understanding of the term “workload”, which would be something like “system resources consumed when performing an operation of some sort”).

Architectures and technology portfolios are then understood as collections of “workloads” within the Well-Architected Framework.

Security and operational excellence are generally not traded-off against the other pillars.

I suppose that quote pretty clearly contextualizes the Well-Architected Framework as more aspirational than anything else.

The Pillars of the Framework

Operational Excellence

Design Principles


Best Practices

It’s not called this, but the directive that each components, processes, etc. must have a “single wringable neck” associated with it makes an oblique appearance in the AWS “organizational” best practices for “operational excellence”.

Key questions:

This document really is full of zingers:

Recognize that an undesired result is a successful experiment that has identified a path that will not lead to success.


Key questions:

So, explainability, modularity, reversibility.


Key questions:

So, logging and playbooks.


Key question: