AWS security architecture is not a product you enable. It is a set of decisions across five layers, each of which fails independently: identity, network, data, detection, and response. A design that is strong in one and absent in another is not partially secure; it is insecure in the way that layer allows.
This is the structure of those five layers, what belongs in each, and the order to build them in.
The shared responsibility model sets the boundary
AWS secures the cloud: hardware, the hypervisor, the physical facilities, and the managed service software. You secure what you put in it: your data, your identities, your network configuration, your patching, and your application code.
The boundary moves depending on the service, and this is where the model is most often misread:
- EC2 leaves you the operating system, patching, network configuration, and everything above.
- RDS takes the operating system and database engine patching, and leaves you users, network placement, encryption choices, and backups.
- Lambda and S3 leave you almost nothing but identity, encryption, and configuration.
The move from EC2 to a managed service is a security decision as much as an operational one, because it transfers a patching obligation you were probably not meeting.
Layer 1: identity, because everything else assumes it
Every AWS API call is authorized by IAM. If identity is wrong, no network control saves you, because the attacker is not on the network; they are holding a credential.
Eliminate long-lived credentials. IAM roles issue temporary credentials automatically and are the correct mechanism for EC2 instance profiles, Lambda execution roles, ECS task roles, and CI/CD via OIDC federation. A static access key in an environment variable or a repository is the most common root cause in real AWS incidents. If one must exist, rotate it on a schedule you actually enforce.
Grant least privilege, then verify it. Start from a narrow policy and widen only against a specific failure. IAM Access Analyzer generates policies from CloudTrail history, which turns least privilege from a guessing exercise into a measurement. Access Analyzer also reports resources shared outside your account, which catches public S3 buckets and over-broad resource policies.
Use conditions, not just actions. A policy that allows an action can also require MFA, restrict to a source VPC endpoint, or limit to a Region. These conditions are what make a leaked credential less useful.
Separate accounts, and put guardrails above them. Multiple AWS accounts under Organizations give a blast radius boundary that no IAM policy inside one account can match. Service control policies then set a ceiling that no principal in a member account can exceed, including its root user: deny Region use outside your footprint, deny disabling CloudTrail, deny deleting security tooling. Guardrails are not permissions, they are limits on permissions.
Protect the root user. Hardware MFA, no access keys, and no everyday use.
Layer 2: network, to limit reachability
Network controls do not authenticate anyone. They decide what can be reached at all, which shrinks the surface that identity has to defend.
The foundation is the VPC: a private address space, subnets that separate public ingress from private compute and isolated data, and route tables that make exposure explicit. Only the load balancer and the NAT gateway should sit in the public path. See AWS VPC explained for the components and public and private subnets for the tiering.
Beyond that layout:
- Security groups referencing security groups, not CIDR ranges, so rules stay correct as instances change.
- VPC endpoints so traffic to S3, DynamoDB, and other AWS services never crosses the internet. This is a security control and a cost saving at the same time.
- AWS WAF in front of a public HTTP entry point, meaning CloudFront, an Application Load Balancer, or API Gateway. WAF only makes sense where there is a public HTTP listener to protect; attaching it elsewhere is decoration.
- AWS Shield for DDoS protection, standard by default and Advanced where the risk justifies it.
- Private connectivity through PrivateLink for exposing an internal service to another VPC without joining the two networks.
Layer 3: data, on the assumption the other layers fail
Encrypt at rest everywhere. S3, EBS, RDS, DynamoDB, and EFS all support encryption with essentially no operational cost. Use AWS KMS, and prefer customer-managed keys where you need a key policy of your own, key rotation on your schedule, or an audit trail of every use. The key policy is an access control in its own right: a principal that can read an object but not use the key cannot decrypt it.
Encrypt in transit. TLS at the load balancer, TLS to the database, and TLS between services. ACM issues and rotates certificates without manual renewal.
Classify before you protect. You cannot apply proportionate controls to data you have not categorized. Macie discovers and classifies sensitive data in S3, which is usually faster than asking teams what their buckets contain.
Block public access at the account level for S3, then grant exceptions deliberately. The account-level setting is the one that survives a mistaken bucket policy.
Manage secrets in a secrets manager. Secrets Manager or Parameter Store with rotation, referenced by the application at runtime. Never in environment variables committed to a repository, and never in an AMI.
Back up with recovery in mind. Backups that live in the same account with the same credentials are not backups against a compromise. AWS Backup with a separate account and immutability gives you something an attacker with production access cannot delete.
Layer 4: detection, because prevention is incomplete
CloudTrail is not optional. It records management events, meaning the control-plane API calls that create, modify, and delete resources, and without it an incident cannot be reconstructed. Data events, such as individual S3 object reads and Lambda invocations, are not captured unless you enable them explicitly and pay for them, which is the gap most often discovered during an investigation rather than before one. Enable the trail organization-wide, deliver to a dedicated log account, turn on data events for the buckets that hold sensitive data, and use a service control policy to deny disabling any of it. Log file validation detects tampering.
GuardDuty analyzes CloudTrail, VPC flow logs, and DNS logs for known-bad patterns: credential use from an unexpected location, cryptomining, communication with known command-and-control infrastructure. It requires no agents and is the highest-value single toggle in AWS security.
AWS Config records resource configuration over time and evaluates rules continuously. It answers "was this bucket ever public?" and "which resources drifted from the standard?", which point-in-time scanning cannot.
Security Hub aggregates findings from GuardDuty, Config, Inspector, Macie, and Access Analyzer into one place and scores them against CIS and AWS Foundational Security Best Practices. Without it, findings sit in six consoles nobody opens.
Inspector scans EC2, container images, and Lambda for known vulnerabilities continuously rather than on a schedule.
Centralize all of it. Logs in the account that generated them are logs an attacker with that account can delete. The centralized AWS security logging architecture shows the cross-account pattern.
Layer 5: response, decided before you need it
Detection without response is an alerting system that makes people feel worse. Decide in advance:
- Who is paged, and through what, when GuardDuty raises a high-severity finding.
- How a credential is revoked. Attaching an explicit deny policy to the principal is faster than deleting it and preserves evidence.
- How an instance is isolated. Replace its security group with one that allows nothing, rather than terminating it, so memory and disk survive for analysis.
- What is automated. EventBridge rules can quarantine a resource or disable a key in seconds, which matters more than the sophistication of the analysis that follows.
- Where the evidence goes. A separate forensics account with append-only storage.
Run the plan once before you need it. An untested runbook is a document, not a capability.
Build order
The layers depend on each other, so the sequence matters more than the completeness of any one:
- Root user hardened, Organizations set up, CloudTrail organization-wide to a separate log account. Without the trail, nothing later can be investigated.
- GuardDuty and Security Hub on, in every Region you use. Detection before hardening, so you learn what is actually happening.
- IAM roles replacing static keys, and Access Analyzer running.
- VPC structure, with public ingress separated from private compute and isolated data.
- Encryption everywhere and public access blocked, which is mostly configuration.
- Service control policies as guardrails, once you know what normal looks like and will not lock yourself out.
- Response runbooks, tested.
Teams that start at step 5 end up with an encrypted environment they cannot audit. Teams that start at step 1 can investigate every mistake they make on the way to step 7.
Where this goes wrong most often
The recurring failures are unglamorous: static access keys in a repository, an S3 bucket made public to fix a permissions error and never reverted, CloudTrail enabled in one Region while the incident happens in another, GuardDuty findings routed to an unmonitored mailbox, an over-broad wildcard policy added during an outage and never narrowed, and backups that share credentials with the thing they are backing up.
None of these is a sophisticated attack. All of them are configuration decisions that were correct for an afternoon and never revisited, which is exactly what AWS Config and Security Hub exist to surface. For a review of what a weak starting point looks like in practice, the single-AZ web application review walks through a real set of gaps.
