Secure AWS Architecture: Decisions, Controls, Evidence, and Recovery

Executive summary

A secure AWS architecture is not a diagram of services with security products arranged around the edge. It is a set of decisions about who may exercise authority, where workloads and evidence are isolated, which actions are prevented, which failures are detected, and how the organization can contain damage and recover trust.

The multi-account patterns in the AWS Security Reference Architecture are a useful starting point, not a deployment prescription. The right design depends on business impact, data sensitivity, operating maturity, regulatory duties, recovery objectives, and the threats the organization is prepared to handle. A control is only credible when its scope, enforcement point, evidence, owner, failure mode, and test are explicit.

This paper uses six connected questions:

1. Objectives: What must remain true, and which outcomes are unacceptable?
2. Boundaries: Which organizational, identity, network, data, and delivery boundaries limit blast radius?
3. Controls: Which preventive, detective, responsive, and recovery mechanisms enforce the design?
4. Evidence: What demonstrates that each control exists, covers the intended scope, and continues operating?
5. Failure: What happens when a control, administrator, dependency, region, or account is compromised?
6. Change: Which architecture or threat changes require another decision?

The objective is not a “secure account.” It is an operating system for cloud risk in which important security claims can be challenged and tested.

Begin with objectives, owners, and unacceptable outcomes

Architecture work should start with the business services and decisions at risk. Record the service owner, data owner, security owner, recovery owner, and the person authorized to accept residual risk. Those roles may belong to different teams. If no one owns restoration or evidence quality, a control catalog will conceal the gap.

For each important workload, write objectives as observable properties:

• production changes originate from an approved, attributable delivery path;
• a workload in one environment cannot assume authority in another without an explicit trust relationship;
• customer data is decrypted only for an authorized workload and purpose;
• security telemetry from governed accounts reaches a separately administered evidence destination;
• responders can isolate a compromised workload without depending on the workload's own control plane;
• recovery artifacts can rebuild a known-good service within agreed recovery objectives.

Then state unacceptable outcomes. Examples include organization-level compromise, undetected modification of audit evidence, cross-tenant disclosure, irreversible key loss, an unreviewed production release, or a recovery path that shares the same compromised identity dependency. These statements determine where stronger separation, independent evidence, and rehearsed recovery are worth their cost.

The AWS Well-Architected Security Pillar organizes design thinking around identity, detection, infrastructure protection, data protection, incident response, and application security. It does not decide the organization's risk appetite. Use it to challenge a design after objectives and constraints are known.

Readers building service-level depth can use the AWS Certified Security - Specialty study plan to map security domains and the AWS Solutions Architect - Professional study plan to examine cross-domain architecture tradeoffs. These are independent learning aids, not AWS endorsements or substitutes for current owner documentation.

A reference system and its trust boundaries

The diagram separates five authority domains. Workforce identity enters through federation; delivery identities enter through a controlled pipeline; workload accounts contain runtime blast radius; delegated security administration aggregates findings and configuration state; and an archive account protects evidence under different administrative assumptions. Recovery is shown separately because a recovery plan that depends entirely on compromised production identities is not an independent recovery path.

This is a logical model. It does not require one account for every box, and separate accounts do not automatically create separation. A shared root mailbox, a broad organization role, uncontrolled cross-account trust, or a common pipeline can collapse several boxes into one effective trust domain.

Organization and account boundaries

Use an AWS Organization to express account lifecycle, delegated administration, billing, and broad policy boundaries. Separate production, non-production, security tooling, log archive, and recovery functions when the reduction in blast radius justifies the operational overhead. Further separation may be appropriate for regulated data, high-impact services, acquisitions, or teams with materially different administrators.

Organizational units are policy attachment points, not security classifications by themselves. Account vending should place new accounts into an intended organizational unit, attach baseline controls, register evidence destinations, configure owners, and block production use until those steps succeed. Detect accounts moved outside governed units and controls that stop applying after a reorganization.

Service control policies set the maximum available permissions for member accounts. They do not grant permissions, do not replace identity and resource policies, and do not constrain every organization actor in the same way. Management-account design and documented AWS exceptions matter. Treat SCPs as broad guardrails for high-consequence actions—such as leaving the organization, disabling designated telemetry, using disallowed Regions, or changing protected configurations—while keeping workload authorization near the resource and action.

Test SCP behavior against representative roles and automation before broad rollout. A preventive policy that blocks incident containment or recovery is a security failure, even if its intended restriction is valid.

Identity is an authority graph

Centralize workforce access through federation and IAM Identity Center or an equivalent identity path. Require strong authentication, short sessions for privileged access, explicit account assignments, and rapid deprovisioning. Map permission sets to job decisions rather than copying broad managed policies into every account.

The design should distinguish:

• workforce roles, assumed by people through federation;
• workload roles, used by compute with short-lived credentials;
• delivery roles, assumed by approved build or deployment identities;
• service-linked roles, created and used by AWS services;
• emergency roles, activated through a controlled break-glass process;
• external roles, assumed by vendors or partner accounts under explicit conditions.

Least privilege is a lifecycle, not a one-time policy review. Begin with job and workload intent, constrain trust policies, use resource and condition context, inspect actual access, remove unused permissions, and repeat after changes. Avoid long-lived access keys where roles or workload identity are available. An identity policy can look narrow while a permissive resource policy, iam:PassRole, role-creation path, or KMS key policy creates an escalation route.

For emergency access, separate credential custody from approval where practical. Define activation evidence, session duration, permitted actions, notification, post-use credential rotation, and a retrospective. Test the path without exposing live secrets in ordinary runbooks.

Network boundaries constrain paths; they do not establish intent

Start from required flows: source identity, destination, protocol, data classification, authorization decision, and evidence. Design VPCs, subnets, routing, security groups, network ACLs, gateways, endpoints, inspection, and DNS around those flows. Default-deny egress can be valuable for high-impact workloads, but only when dependencies, failure behavior, update paths, and incident operations are understood.

Private addressing and TLS do not answer who is authorized. Enforce service and tenant authorization at an application or policy boundary even when traffic stays inside a VPC. Use VPC endpoints and endpoint policies where they materially reduce unwanted paths, and log enough connection and DNS context to investigate misuse. Protect the instance metadata path and prefer workload-specific credentials over network-location assumptions.

Central inspection can improve consistency, but it adds routing complexity and a concentration of failure. Document bypass routes, encrypted-traffic limits, scaling behavior, fail-open or fail-closed decisions, and how responders isolate one workload without taking down unrelated services.

Data protection includes authority and recoverability

Classify data and map creation, transit, use, derived copies, logs, backups, retention, and deletion. Encryption is necessary for many objectives, but the harder questions are which principals may request decryption, which services may act on their behalf, how key policy changes are governed, and whether recovery can succeed after account or key compromise.

Use TLS for data in transit and AWS service encryption capabilities where appropriate. For sensitive data, customer-managed KMS keys can provide separation, policy control, rotation choices, and audit evidence. Follow AWS KMS least-privilege guidance: constrain administrators, key users, grants, aliases, and service context. Do not assume an IAM Deny or Allow can be understood without the key policy and grant model.

Separate key administration from data use when the threat model warrants it. Alert on policy, grant, deletion, and disablement changes. Define what happens when KMS, a Region, or an owning account is unavailable. Backups should have retention and deletion protections matched to the destructive capability being modeled, and restorations must be tested with required keys, dependencies, schemas, and data integrity checks.

Preventive, detective, and evidence controls

Prevention limits the possible action space. Detection reveals prohibited or unexpected behavior. Evidence shows whether both still work. These are different jobs.

An organization-level CloudTrail trail can apply event collection across member accounts. Its architecture still requires decisions about Regions, management and data events, destinations, access, cost, retention, and failure alarms. Use CloudTrail log-file integrity validation when the objective includes detecting deletion or modification after delivery; it does not prevent deletion, validate every downstream transformation, or prove that an event category was configured for collection.

Centralize configuration history and compliance signals with AWS Config aggregation, findings with Security Hub central configuration, and threat detection with GuardDuty organization administration where those services fit the objectives. Aggregation is not coverage. Monitor account enrollment, Region enablement, recorder state, delivery errors, delegated-administrator changes, suppressed findings, stale timestamps, and permission failures.

Protect the evidence pipeline with a different administrative path from ordinary workloads. Restrict deletion and lifecycle changes, encrypt data, control query access, and preserve time and identity context. Record immutable identifiers that join cloud activity to deployment, ticket, source revision, approver, and workload telemetry. Evidence also has sensitivity: central logs may contain customer identifiers, object names, queries, secrets, or investigation material, so minimize and govern their access.

Evidence has four useful dimensions:

• existence: the configuration or artifact is present;
• coverage: all intended accounts, Regions, resources, and event types are included;
• operation: the pipeline is current and failures are surfaced;
• effectiveness: tests show the control changes or reveals the modeled outcome.

A green configuration rule establishes neither operation nor effectiveness on its own.

Vulnerability and software-supply-chain decisions

Inventory operating systems, container images, functions, packages, infrastructure modules, build actions, and externally managed services. Decide patch and remediation objectives by exploitability and business impact, not a universal severity number. Account for immutable deployments, emergency patches, end-of-life dependencies, managed-service boundaries, and assets that cannot tolerate automatic restart.

The delivery path is privileged infrastructure. Pin and review dependencies, isolate untrusted pull-request execution, protect release branches, use short-lived cloud credentials, separate build from deployment authority, and require attributable approvals for high-impact production changes. Generate software bills of materials or provenance where they support a real verification decision. SLSA version 1.2 provides a vocabulary for supply-chain integrity; a claimed level or attestation is only useful if a consumer verifies the issuer, subject, build identity, and expected policy.

This delivery model connects to the SLSA research brief, why provenance matters, and the SolarWinds Orion incident record. The ATT&CK software supply-chain technique T1195.002 helps categorize one attacker path; it does not determine whether a particular build system is compromised.

Incident containment, break glass, and recovery

Design response actions while building the workload. The NIST SP 800-61r3 research brief explains why preparation, response, recovery, and improvement belong to the broader operating model. For AWS, pre-authorize and test actions such as:

• revoke a workforce session or workload credential;
• quarantine an instance, task, function, or account while preserving evidence;
• block a delivery identity or artifact;
• rotate a secret or disable a KMS grant;
• snapshot volatile or durable evidence under an investigation account;
• fail over or rebuild from an approved source;
• communicate through an out-of-band identity and coordination path.

Containment must not depend exclusively on the compromised account. Delegated responders need carefully bounded authority, and their actions need independent logs. A quarantine policy should preserve required management, evidence, and recovery paths rather than indiscriminately severing them.

Recovery is a restoration of trustworthy service, not merely availability. Define the known-good source for code, configuration, data, keys, identities, and dependencies. Decide how compromise scope changes the restoration point. Verify artifacts and access paths before reconnecting. Reconcile transactions or customer state after restoration. Monitor for recurrence, and record which architecture assumption or control failed.

Run exercises against concrete scenarios: a stolen federated administrator session, public data exposure caused by a resource policy, a compromised deployment role, disabled telemetry, destructive encryption or deletion, and a regional dependency failure. The Capital One incident record and ATT&CK Valid Accounts, T1078 can seed discussion, but the exercise must use the organization's own identities, boundaries, and decisions.

Control-to-evidence matrix

Use this matrix as a design contract. Link each row to machine-readable policy and tests where possible. The Open Policy Agent research shows one way to separate policy decisions from application code; it is not a substitute for the AWS enforcement points or ownership described here. The broader method in Threat Modeling That Produces Testable Controls can be used to derive additional rows from workload-specific abuse paths.

Failure modes and tradeoffs

Common architecture failures are organizational as often as technical:

• Centralization without independence: the same administrator can alter workloads, detectors, and evidence.
• Guardrails without recovery testing: an SCP protects normal operations but blocks emergency restoration.
• Detection without pipeline health: findings look quiet because a Region, account, or recorder is missing.
• Encryption without authority analysis: broad key users or grants defeat the intended separation.
• Segmentation without flow ownership: emergency exceptions accumulate until boundaries are nominal.
• Automation without safe failure: account vending or remediation partially applies a baseline and still reports success.
• Backups without trust restoration: data returns, but compromised identities or artifacts immediately reintroduce the incident.

More accounts, policies, and security services increase isolation and visibility only when teams can operate them. They also increase cost, dependency count, quota management, alert volume, and failure modes. Prefer a smaller set of explicit, measured controls over a large catalog whose coverage cannot be demonstrated.

Architecture review checklist

• Are business objectives, unacceptable outcomes, accountable owners, and risk authority recorded?
• Do account, identity, delivery, network, data, evidence, and recovery boundaries match the threat model?
• Are root, management-account, delegated-administrator, vendor, and break-glass paths explicitly reviewed?
• Does each preventive control state its limitations and exception path?
• Can evidence demonstrate existence, coverage, operation, and effectiveness?
• Are evidence stores and detection administration separated from ordinary workload control?
• Can responders contain and investigate a workload without trusting that workload?
• Can the organization rebuild code, configuration, data, identities, and keys from known-good sources?
• Have representative denial, detection, containment, and restore tests run successfully?
• Are cost, availability, privacy, and operational tradeoffs documented?

Review the architecture at least every six months and after a new account or Region strategy, identity-provider or federation change, organization-policy restructure, major data classification change, new public or partner trust path, delivery-platform migration, high-impact incident, failed recovery exercise, or material AWS service change. Use the source directory, daily briefing, and intelligence index to find current AWS security intelligence as change input—not as proof that local controls work.

Source scope and freshness

This paper is a source-grounded decision model, not an AWS configuration standard, audit opinion, compliance determination, or assurance that a deployed environment is secure. Service behavior and documentation change; verify implementation choices against current owner documentation and test them in the intended environment.