It translates protection needs into designs for identity, networks, workloads, applications, data, management planes, monitoring, resilience, and provider dependencies. It is an architectural description and decision model, not a product or generic checklist.
The architecture should describe both provider-operated and customer-operated elements across the chosen service and deployment models. It connects business consequences and data sensitivity to concrete enforcement points, administrative paths, cryptographic boundaries, telemetry, recovery mechanisms, and lifecycle processes. Reference patterns must be adapted to the system and contract.
Key points
Scope and contextIdentify assets, services, dependencies, jurisdictions, threat assumptions, required data flows, availability needs, and the consequences of compromise or provider failure.
Trust and responsibilityShow where identities, policy decisions, enforcement, keys, data, and administration cross organizational or technical boundaries, and assign an accountable owner for each control.
Assurance and evolutionRecord design decisions and exceptions, validate important properties, review provider and application changes, test recovery, and keep diagrams and threat models aligned with deployed infrastructure.
Important limitationAn architecture diagram does not establish that controls exist, work, or remain correctly configured. Reference patterns can omit service-specific behavior, and a design that ignores operational ownership, observable evidence, failure modes, or application logic can create false confidence.