Security guide

Secure AWS Architecture: Reference Design and Checklist

A secure AWS architecture puts workloads in separate accounts under AWS Organizations, sets guardrails centrally, signs people in with temporary credentials, sends logs to a dedicated account, closes unnecessary network exposure, controls encryption keys and prepares detection and response before an incident.

This guide lays out that design as a layout of accounts and controls, maps it to the seven areas of the AWS Well-Architected Security Pillar and to the AWS Security Reference Architecture (SRA), and ends with a decision checklist. Every claim cites an AWS documentation page we read on 4 November 2026; the wording is ours.

AWS says not every workload needs every security service. Use this as a reference to decide from risk, not a shopping list.

Updated 4 November 2026 (last reviewed)

TL;DR

The short version

6 points

Separate accounts are the base: AWS calls accounts a hard boundary and recommends isolating production from development and test.
Set guardrails at the organization with SCPs and RCPs; they limit but never grant, and they do not touch the management account.
Use IAM Identity Center and roles with temporary credentials; remove root credentials from member accounts.
Send logs to a Log Archive account with immutable storage; run detection from a delegated Security Tooling account.
Close inbound ports, require IMDSv2, use VPC endpoints, block public S3 access and control KMS key policy.
Prepare responses before you need them and practise them in game days.

The layout: accounts, OUs and what lives where

The AWS SRA organizes security around an Org Management account and three groups of accounts. The Security OU holds a Security Tooling account and a Log Archive account. The Infrastructure OU holds a Network account and a Shared Services account. The Workloads OU holds the application accounts. AWS notes the reference is built around a simple three-tier web application so security controls stay visible.

Figure: a simplified secure AWS organization. Account roles come from the AWS SRA, accessed 4 November 2026.

Group accounts by function, compliance requirements or common controls, not by your reporting structure. If you will run more than a handful of accounts, AWS Control Tower orchestrates Organizations, Service Catalog and IAM Identity Center to build a landing zone and applies controls so accounts do not drift.

Sources (AWS documentation, accessed 4 November 2026): AWS SRA; Security Pillar, account management; AWS Control Tower.

Guardrails: SCPs, RCPs and the management account

Service control policies define the maximum permissions for IAM users and roles in member accounts. They grant nothing, do not affect users and roles in the management account, and cannot restrict service-linked roles. AWS recommends testing SCPs in a separate organization or OU and rolling out from specific OUs to broader ones. Resource control policies do the same for resources, limiting access by principals outside your organization, and they also do not affect resources in the management account. Keep workloads out of the management account, since the guardrails do not reach it.

Sources (AWS documentation, accessed 4 November 2026): AWS Organizations, SCPs; AWS Organizations, SCP examples; AWS Organizations, RCPs; AWS SRA, Org Management.

Identity: federation, roles and the root user

Connect your identity provider to IAM Identity Center and assign groups to accounts through permission sets, which are templates of IAM policies. Give workloads roles so they use temporary credentials. AWS also advises requiring MFA, applying least privilege, using IAM Access Analyzer to check public and cross-account access, and removing unused access regularly.

Protect the root user: MFA, no access keys, a group email address. For member accounts, AWS recommends removing root credentials and managing root access centrally. When a temporary credential leaks, you can revoke a role's sessions: IAM attaches an inline deny that applies to sessions issued before a chosen time. Practise it in the AWS Account Compromise Lab.

Sources (AWS documentation, accessed 4 November 2026): IAM Identity Center; IAM Identity Center, permission sets; IAM best practices; IAM root user best practices; IAM, revoke role sessions; AWS SRA, Org Management.

Logging and detection

An organization trail records events for the management account and all member accounts. The SRA sends security logs to a dedicated Log Archive account whose storage must be immutable, suggesting S3 Object Lock, versioning and lifecycle rules, and recommends encrypting security log buckets with customer managed KMS keys so reading a log needs both S3 and KMS permissions. CloudTrail log file validation uses signed hourly digest files to show whether log files were altered or deleted.

By default trails do not log data events such as S3 object-level activity, so decide in advance which sensitive buckets need them. For detection, GuardDuty analyses CloudTrail management events, VPC flow logs and DNS logs. The Security Pillar recommends delegated administration for GuardDuty, Security Hub and AWS Config, so security tooling is separate from the billing management account, and says to monitor API calls that change the security posture.

Sources (AWS documentation, accessed 4 November 2026): CloudTrail organization trail; AWS SRA, Log Archive; CloudTrail log file validation; CloudTrail data events; GuardDuty; Security Pillar, account management; Security Pillar, detection; AWS SRA, Security Tooling.

Network and compute

The SRA keeps shared network infrastructure in a Network account and says application VPCs should use VPC endpoints to reach AWS services instead of internet or NAT paths. Systems Manager Session Manager lets you close inbound SSH and remote PowerShell ports and drop bastion hosts and SSH keys. For EC2, IMDSv2 is a session-oriented method for instance metadata; you can configure instances to accept only IMDSv2 and set the account default for new instances, which does not change existing ones. AWS WAF monitors HTTP(S) requests to protected web applications.

Sources (AWS documentation, accessed 4 November 2026): AWS SRA, Network; AWS SRA, Application; Systems Manager Session Manager; EC2 instance metadata; EC2, require IMDSv2; AWS WAF; Security Pillar, infrastructure protection.

Data protection

S3 Block Public Access has four settings, applied at access point, bucket, account or organization level; at organization level all four apply together, and S3 uses the most restrictive combination. The key policy is the primary control on a KMS key: no principal has permission unless a key policy, IAM policy or grant allows it, and IAM policies only take effect if the key policy permits them. Key policies are Regional. Deleting a KMS key needs a waiting period of 7 to 30 days. The Security Pillar starts data protection with classification and encryption.

Rehearse these choices in the AWS Hardening Lab.

Sources (AWS documentation, accessed 4 November 2026): S3 Block Public Access; KMS key policies; KMS key deletion; Security Pillar, data protection.

Incident response

The Security Pillar says to put tools and access in place before an incident and to routinely practise through game days. GuardDuty documents remediation steps for compromised credentials, starting with identifying the entity and API call in the finding and reviewing the entity's permissions. Keys that begin with ASIA are temporary STS credentials; keys beginning with AKIA are long-term credentials.

Sources (AWS documentation, accessed 4 November 2026): Security Pillar, incident response; GuardDuty, compromised credentials; Well-Architected Security Pillar.

Mapping to the Security Pillar and the SRA

The Security Pillar defines seven areas. This table shows the controls in this guide for each, and where the SRA places them. The mapping is our summary of the cited documents.

Security Pillar area	Controls in this guide	Where in the SRA
Security foundations	Accounts under Organizations; SCPs and RCPs; Control Tower; root user hardening	Org Management and the OU structure
Identity and access management	IAM Identity Center, roles with temporary credentials, least privilege, Access Analyzer	Org Management, Shared Services
Detection	Organization trail, GuardDuty, Security Hub, Config, delegated administration	Security Tooling, Log Archive
Infrastructure protection	Separate network account, VPC endpoints, Session Manager, IMDSv2, security groups	Network, Application
Data protection	S3 Block Public Access, encryption, KMS key policy, immutable log storage	Application, Log Archive
Incident response	Runbooks, isolation, session revocation, game days	Security Tooling
Application security	Edge filtering with a web application firewall, secure delivery pipeline	Network, Application

Sources (AWS documentation, accessed 4 November 2026): Well-Architected Security Pillar; Well-Architected Security Pillar; AWS SRA.

Decision checklist

Nine questions to answer before you call an AWS environment well designed. For a weighted version with a score, use the AWS Security Checklist. For benchmark-level settings, use the CIS AWS Benchmark Checklist.

Are production, development and test in separate accounts? If not, start here; every other control is weaker without the boundary.
Does the root user have MFA, no access keys and a business-managed email, with member-account root credentials removed? This is a cheap control that blocks the most powerful identity.
Does anyone use long-term IAM user keys? Move people to Identity Center and workloads to roles.
Which guardrails exist at organization level (SCPs, RCPs, Block Public Access, IMDSv2 defaults)? Guardrails work even when a team forgets.
Where do the organization trail and other security logs go, and can an account administrator delete them? They should go to a Log Archive account and be immutable.
Is GuardDuty on everywhere and does a High finding page a person? Alerts nobody sees are not detection.
Can you reach servers without open inbound ports? Use Session Manager and close SSH and RDP.
Who can use and who can manage each KMS key? Separate administrators from users in the key policy.
Have you practised revoking a role session and isolating an instance? A runbook that was never tried is a guess.

Frequently asked questions

What is a secure AWS architecture?

A design in which workloads run in separate AWS accounts under AWS Organizations, guardrails are set centrally, identities use temporary credentials, logs go to a dedicated account, networks and instances have no unnecessary exposure, data is encrypted with controlled keys, and detection and response are prepared in advance. AWS describes this in the Well-Architected Security Pillar and the AWS Security Reference Architecture.

What is the AWS Security Reference Architecture?

It is AWS guidance on deploying the full range of AWS security services in a multi-account environment. It is built around a single-page diagram and walks through organizational units and accounts: Org Management, Security Tooling, Log Archive, Network, Shared Services and Application. AWS says not every workload needs every service, and that you decide based on risk.

Why separate AWS accounts?

AWS describes accounts as a hard boundary. It strongly recommends separating production from development and test, and grouping accounts by function, compliance requirements or common controls rather than by reporting structure.

What are the seven areas of the Security Pillar?

Security foundations, identity and access management, detection, infrastructure protection, data protection, incident response and application security.

Do service control policies grant permissions?

No. They set the maximum permissions for IAM users and roles in member accounts. They do not affect the management account and cannot restrict service-linked roles. Resource control policies work similarly for resources, limiting access by external principals.

Where should logs be stored?

In a dedicated Log Archive account. The AWS SRA says log storage there must be immutable, recommends S3 Object Lock and versioning, and recommends encrypting security log buckets with customer managed KMS keys for a second layer of access control.

Is there a checklist I can use?

Yes: the decision checklist at the end of this page, and the interactive AWS Security Checklist on PlayCISO, which gives a weighted score and the gaps by domain.