Defense in Depth: Security Layers on AWS
Defense in depth is a security strategy that uses multiple independent layers of protection so that if one layer fails, the next layer catches the threat. This concept comes from military doctrine and maps directly to how you should architect security on AWS.
Why Single-Layer Security Fails​
Many organizations make the mistake of relying heavily on a single security mechanism, typically a firewall or network perimeter. This fails because:
- Perimeter breaches happen. Misconfigured security groups, leaked credentials, or compromised dependencies can bypass your outermost layer entirely.
- Insider threats exist. An overly privileged IAM user or a compromised application already sits inside your perimeter.
- Vulnerabilities are discovered continuously. A zero-day in one layer should not mean total compromise.
A single misconfigured S3 bucket policy or an overly broad IAM role can expose data even when your network layer is airtight. Each layer must assume the others have already been breached.
The Five Security Layers​
1. Network Layer​
The network layer controls where traffic can flow. On AWS, this means VPCs, subnets, security groups, NACLs, and VPC endpoints. A well-designed network layer ensures that only the minimum required network paths exist between resources.
Goal: Minimize the blast radius of any single compromised resource by limiting what it can reach.
2. Identity Layer (IAM)​
The identity layer controls who can do what. IAM is arguably the most critical layer because a misconfigured identity policy can bypass every other layer. An IAM role with *:* permissions makes every other security control irrelevant.
Goal: Ensure every principal has only the exact permissions needed, for the shortest time possible.
3. Data Layer​
The data layer protects your data at rest and in transit. This includes encryption with KMS, S3 bucket policies, Block Public Access settings, and TLS enforcement. Even if an attacker gains access to your network and has some IAM permissions, encrypted data with separate key policies adds another barrier.
Goal: Ensure data is unreadable to unauthorized parties, even if they gain access to the storage medium.
4. Application Layer​
The application layer protects your workloads from external threats like SQL injection, cross-site scripting, and DDoS attacks. AWS WAF, Shield, and API Gateway provide the tools to filter malicious traffic before it reaches your application code.
Goal: Filter and block known attack patterns at the edge before they reach business logic.
5. Detection and Response Layer​
No set of preventive controls is perfect. The detection layer ensures you know when something unexpected happens and can respond quickly. CloudTrail, GuardDuty, AWS Config, and Security Hub provide continuous monitoring and alerting.
Goal: Detect anomalies, policy violations, and active threats in near real time.
AWS Services by Security Layer​
| Layer | AWS Service | What It Does |
|---|---|---|
| Network | VPC | Isolated virtual network |
| Security Groups | Stateful firewall at the ENI level | |
| NACLs | Stateless firewall at the subnet level | |
| VPC Endpoints | Private connectivity to AWS services | |
| AWS PrivateLink | Private connectivity to third-party services | |
| Identity | IAM | Users, roles, policies, permissions |
| AWS STS | Temporary credentials | |
| AWS Organizations | Multi-account governance | |
| IAM Identity Center | Centralized SSO | |
| Data | KMS | Encryption key management |
| S3 Block Public Access | Prevent public S3 buckets | |
| ACM | TLS certificate management | |
| Secrets Manager | Secure secrets storage and rotation | |
| Application | AWS WAF | Web application firewall |
| AWS Shield | DDoS protection | |
| API Gateway | API authentication and throttling | |
| Cognito | User authentication and authorization | |
| Detection | CloudTrail | API activity logging |
| GuardDuty | Threat detection | |
| AWS Config | Configuration compliance | |
| Security Hub | Centralized security findings |
The Shared Responsibility Model​
AWS operates on a shared responsibility model:
- AWS is responsible for security of the cloud - physical data centers, hypervisors, managed service infrastructure, and the global network.
- You are responsible for security in the cloud - IAM configuration, security group rules, encryption settings, application code, and operating system patches.
The boundary shifts depending on the service type:
| Service Type | Your Responsibility | AWS Responsibility |
|---|---|---|
| IaaS (EC2) | OS, patching, firewall, data, IAM | Hardware, hypervisor, network |
| Managed (RDS, ECS) | Data, IAM, network config | OS, patching, engine updates |
| Serverless (Lambda, S3) | Code, data, IAM | Everything else |
The more managed the service, the less you are responsible for, but IAM and data protection are always your responsibility regardless of the service type.
Key Takeaways​
- No single layer of security is sufficient. Defense in depth means each layer independently limits the damage an attacker can do.
- IAM is the most impactful layer because it cuts across every other layer.
- The shared responsibility model means you are always responsible for IAM, data protection, and application-level security.
- Design each layer assuming the others have already been compromised.
Flashcards​
What is defense in depth?
Click to revealA security strategy that uses multiple independent layers of protection so that failure of one layer does not result in total compromise. Each layer is designed to catch what the others might miss.