AWS Security Best Practices: Zero Trust Architecture Guide
Implement defense-in-depth security on AWS. Master IAM, encryption, network security, compliance, and incident response with AWS Well-Architected Security Pillar patterns.
Technical TL;DR
Security = Shared Responsibility. AWS secures the cloud; you secure what's in the cloud.
Non-negotiables:
---
1. Identity and Access Management (IAM)
1.1 Root Account: Use It Once
The root account has unlimited access. Compromise is catastrophic.
Required Actions:
```yaml
1. Enable MFA on root account (hardware MFA preferred)
2. Delete root access keys (never use them programmatically)
3. Create IAM users for daily administrative tasks
4. Store root credentials in AWS Secrets Manager (rare emergency access)
5. Enable AWS Organization for multi-account governance
```
1.2 IAM Users: MFA Is Mandatory
All human IAM users must have MFA enabled. No exceptions.
User Creation Checklist:
```yaml
☐ Individual IAM user (no shared credentials)
☐ MFA enabled (virtual or hardware token)
☐ Password policy: 14+ chars, rotation required, no reuse
☐ Access keys disabled for humans (use console only)
☐ Permission boundaries for non-admin users
☐ Tag users for cost allocation (Owner, Department, CostCenter)
```
1.3 IAM Roles: The Only Way for Workloads
Applications, services, and EC2 instances must use IAM roles. Never embed access keys.
Role Configuration:
```yaml
EC2/Lambda/Containers:
- Create IAM role with least-privilege policy
- Attach role to resource at creation
- Use AWS SDK default credential chain
- Rotate credentials automatically (AWS handles this)
Cross-Account Access:
- Use IAM roles, not access keys
- Implement trust policies with external ID
- Require MFA for cross-account assume-role
```
1.4 Least Privilege: Start Deny, Whitelist
Default to deny access. Grant only what's verified needed.
Policy Creation Process:
```yaml
1. Start with AWS managed policies (baseline)
2. Use IAM Access Analyzer to identify required permissions
3. Create customer-managed policies (scoped to resources)
4. Validate with IAM policy simulator
5. Implement permissions boundaries (max permissions)
6. Review quarterly with Trusted Advisor + Access Advisor
```
Example: Least-Privilege S3 Access
```json
{
"Effect": "Allow",
"Action": ["s3:GetObject"],
"Resource": "arn:aws:s3:::my-app-bucket/prod/*"
}
```
❌ Bad: `"Action": "s3:*"` on `"Resource": "*"`
✅ Good: Specific action, specific resource
1.5 AWS Organizations: Multi-Account Governance
Multiple AWS accounts = security isolation. Don't rely on IAM alone for separation.
Account Structure:
```yaml
Root Organization
├── Security Account (centralized logging, GuardDuty)
├── Shared Services Account (CI/CD, pipelines)
├── Prod Account (production workloads)
├── Staging Account (pre-production)
├── Dev Account (development environments)
└── Audit Account (compliance, 3rd-party access)
```
SCPs (Service Control Policies):
```yaml
```
---
2. Network Security
2.1 VPC Design: Private Subnets by Default
Never place production resources in public subnets.
VPC Architecture:
```yaml
VPC (10.0.0.0/16)
├── Public Subnets (10.0.1.0/24)
│ └── Application Load Balancers only
├── Private Subnets (10.0.2.0/24)
│ └── EC2, ECS, EKS, RDS, Lambda (VPC-enabled)
└── Isolated Subnets (10.0.3.0/24)
└── Database (no internet gateway required)
```
Routing:
```yaml
Public Subnets → Internet Gateway
Private Subnets → NAT Gateway (for outbound updates)
Isolated Subnets → No internet route (maximum security)
```
2.2 Security Groups: Stateful Firewalls
Security groups are stateful. Allow outbound = allow return inbound.
Best Practices:
```yaml
1. Default to deny all (create with no rules)
2. Whitelist specific protocols + ports + sources
3. Use security group references (not IPs when possible)
4. Document SG rules in description (who, why, when)
5. Regular audits: remove unused rules (via Trusted Advisor)
```
Example: Web Tier SG
```yaml
Inbound:
- 80/tcp from ALB-SG
- 443/tcp from ALB-SG
- 22/tcp from Bastion-SG (only if required)
Outbound:
- 443/tcp to 0.0.0.0/0 (for AWS APIs)
- 3306/tcp to Database-SG (for RDS)
```
2.3 NACLs: Stateless Network Control
NACLs are stateless. Must explicitly allow both directions.
Use Cases:
Warning: NACLs operate at subnet level (harder to manage than SGs)
2.4 VPC Endpoints: Private AWS Access
VPC endpoints allow private access to AWS services without internet.
Required Endpoints for Production:
```yaml
☐ s3 (S3 access without internet gateway)
☐ dynamodb (DDB private access)
☐ ec2 (EC2 API private access)
☐ sqs (SQS private messaging)
☐ sns (SNS private notifications)
☐ secretsmanager (Secrets Manager private access)
☐ kms (KMS private encryption)
```
Cost: $0.01/endpoint/hour (offset by NAT Gateway savings)
2.5 Bastion Hosts: Secure SSH Access
Never expose SSH/RDP directly to the internet.
Bastion Architecture:
```yaml
☐ Place bastion in public subnet
☐ Security group: allow 22/tcp from trusted IPs only
☐ Hardened AMI (minimal packages, latest patches)
☐ AWS Systems Manager Session Manager (preferred over SSH)
☐ Enable CloudTrail logging for bastion
☐ Auto-scaling group (HA bastion)
```
Session Manager Benefits:
---
3. Data Encryption
3.1 Encryption at Rest: KMS by Default
All data must be encrypted at rest. Use AWS KMS for customer-managed keys.
Services Requiring Encryption:
```yaml
☐ S3 (bucket default encryption)
☐ EBS volumes (enabled by default)
☐ RDS (encryption at creation)
☐ DynamoDB (encryption at table creation)
☐ Lambda (environment variables via KMS)
☐ EFS (encryption enabled)
☐ CloudWatch Logs (encryption via KMS)
```
3.2 KMS Key Management
Customer Managed Keys (CMKs) vs. AWS Managed Keys:
| Factor | AWS Managed | Customer Managed |
|--------|-------------|------------------|
| **Rotation** | Automatic every 3 years | Automatic every 1 year |
| **Control** | AWS-managed | Full control (policies, access) |
| **Cost** | Free | $1/month/key |
| **Use Case** | General encryption | Compliance, granular access |
KMS Best Practices:
```yaml
☐ Separate keys per environment (dev/staging/prod)
☐ Separate keys per data classification (public/confidential)
☐ Key policies: restrict to specific IAM roles/users
☐ Enable automatic key rotation
☐ Use key aliases (human-readable names)
☐ Document key purpose in description
```
3.3 Encryption in Transit: TLS Everywhere
All network traffic must be encrypted. HTTP is unacceptable for production.
TLS Configuration:
```yaml
☐ ALB/CLB: TLS 1.2+ minimum (disable TLS 1.0/1.1)
☐ ACM certificates (auto-renewal, free)
☐ Forward Secrecy (use ECDHE ciphers)
☐ HSTS headers (enforce HTTPS)
☐ Certificate pinning for mobile apps
☐ RDS: Force SSL in parameter groups
```
ACM Best Practices:
```yaml
1. Import or create certs via ACM
2. Use ACM for ALB/CLB/CloudFront
3. Enable auto-renewal
4. Set up expiration alerts (CloudWatch metric)
5. Use Cert Manager for Kubernetes (cert-manager.io)
```
---
4. Secrets Management
4.1 Never Store Secrets in Code or Environment Variables
Environment variables are visible in console. Not secure for secrets.
Approved Secret Storage:
```yaml
☐ AWS Secrets Manager (automatic rotation, $0.40/secret/month)
☐ Parameter Store SecureString (free for Standard tier)
☐ AWS CloudHSM (FIPS 140-2 Level 3, highest security)
```
4.2 Secrets Manager: Auto-Rotation
Secrets Manager supports automatic credential rotation. Use it.
Supported Services:
Rotation Strategy:
```yaml
1. Create secret in Secrets Manager
2. Enable automatic rotation (30-90 days)
3. Create Lambda function for rotation logic
4. Grant Lambda permissions to update password
5. Applications retrieve secret via SDK (latest version)
```
4.3 Parameter Store: Free Alternative
Parameter Store SecureString is free for most use cases.
When to Use Parameter Store:
```yaml
✓ Configuration values (non-sensitive)
✓ API keys, tokens (SecureString tier)
✓ Small-scale secrets (<10KB)
✓ Budget-conscious projects
```
When to Use Secrets Manager:
```yaml
✓ Automatic credential rotation required
✓ Secret sharing across AWS accounts
✓ Larger secrets (>10KB)
✓ Fine-granced audit logging needed
```
---
5. Logging and Monitoring
5.1 CloudTrail: Audit Everything
CloudTrail logs all API calls. Required for compliance and incident response.
Required Trails:
```yaml
☐ Management events (all regions, all services)
☐ Data events (S3 object access, Lambda execution)
☐ Trails encrypted with KMS
☐ Logs delivered to CloudWatch Logs
☐ Separate logging account (prevents log tampering)
☐ Enable CloudTrail Insights (anomaly detection)
```
Trail Architecture:
```yaml
Production Account → CloudTrail → S3 ( Logging Account)
↓
CloudWatch Logs
↓
SNS Alerts
```
5.2 GuardDuty: Threat Detection
GuardDuty uses ML to detect threats. Enable in all accounts.
Detection Capabilities:
```yaml
```
Configuration:
```yaml
☐ Enable in all AWS accounts (multi-account setup)
☐ Enable in all regions
☐ Export findings to Security Hub
☐ Set up SNS alerts for high-severity findings
☐ Integrate with incident response workflow
```
5.3 Security Hub: Compliance Centralization
Security Hub aggregates findings from GuardDuty, Inspector, Macie.
Enabled Security Standards:
```yaml
☐ CIS AWS Foundations Benchmark
☐ AWS Foundational Security Best Practices
☐ PCI DSS (if applicable)
☐ HIPAA (if applicable)
☐ NIST 800-53 (if applicable)
```
Workflow:
```yaml
1. Findings generated by services
2. Aggregated in Security Hub
3. Assigned severity (Critical/High/Medium/Low)
4. SNS alerts for Critical/High
5. Automated remediation via Lambda
6. Manual investigation for complex findings
```
---
6. Incident Response
6.1 Incident Response Playbook
Document your incident response process before an incident occurs.
Playbook Sections:
```yaml
1. Detection and Notification
- GuardDuty findings (SNS alerts)
- CloudTrail anomalies
- User reports
2. Triage and Investigation
- Confirm scope (affected accounts, resources)
- Gather evidence (logs, screenshots)
- Assess impact
3. Containment
- Isolate affected resources (revoke IAM credentials)
- Block malicious IPs (NACLs, WAF)
- Suspend compromised accounts
4. Eradication
- Remove malware, backdoors
- Close security gaps
- Patch vulnerabilities
5. Recovery
- Restore from clean backups
- Verify no persistence
- Monitor for recurrence
6. Post-Incident Review
- Root cause analysis
- Process improvements
- Communication to stakeholders
```
6.2 Automated Response with Lambda
Lambda can automatically remediate security findings.
Automated Response Examples:
```yaml
☐ GuardDuty finding → Revoke compromised IAM keys
☐ Security Hub alert → Isolate EC2 instance (detach SG)
☐ Config violation → Tag non-compliant resources
☐ S3 public access → Enable bucket policy restrictions
```
---
7. Compliance and Governance
7.1 AWS Config: Configuration Auditing
Config tracks resource state changes. Required for compliance.
Required Rules:
```yaml
☐ encrypted-volumes (EBS encryption required)
☐ s3-bucket-server-side-encryption-enabled
☐ iam-user-mfa-enabled
☐ root-account-mfa-enabled
☐ instances-in-vpc (no EC2 in EC2-Classic)
☐ approved-amis-by-id (use only approved AMIs)
```
7.2 Service Control Policies (SCPs)
SCPs enforce guardrails across AWS Organizations.
Example SCPs:
```yaml
Deny unencrypted S3 uploads:
- Action: s3:PutObject
- Condition: s3:x-amz-server-side-encryption absent
Deny creation of resources without tags:
- Action: * (all services)
- Condition: aws:PrincipalTag absent
Deny access to specific regions:
- Action: *
- NotRegion: us-east-1, us-west-2
```
---
8. Security Assessment Tools
Required Security Tools
```yaml
☐ Trusted Advisor (free tier includes security checks)
☐ Security Hub (centralized findings)
☐ GuardDuty (threat detection)
☐ Inspector (vulnerability scanning)
☐ Macie (data classification, PII detection)
☐ Audit Manager (compliance reporting)
```
Regular Assessments
```yaml
Weekly: Review GuardDuty findings
Monthly: Security Hub compliance status
Quarterly: IAM policy review, remove unused permissions
Annually: Penetration testing (requires AWS approval)
```
---
Summary: Security Excellence Pillars
1. **MFA everywhere** (root, IAM users, cross-account roles)
2. **IAM roles for workloads** (never embed access keys)
3. **Encrypt everything** (at rest with KMS, in transit with TLS)
4. **Least privilege** (whitelist, don't blacklist)
5. **Multi-account isolation** (AWS Organizations + SCPs)
6. **Centralized logging** (CloudTrail + Security Hub + GuardDuty)
7. **Automated response** (Lambda + SNS for critical findings)
8. **Regular assessments** (continuous monitoring, quarterly audits)
---
Need a Security Assessment?
Our AWS-certified security architects can evaluate your cloud security posture, identify gaps, and implement defense-in-depth controls.
<a href="/contact" className="text-aws-orange font-semibold hover:text-aws-light">
Schedule a Free Security Review →
</a>
Internal Linking Strategy:
---
*Last updated: January 5, 2025*
Related Articles
AWS Networking Best Practices: VPC, CloudFront, and Connectivity Guide
Master AWS networking architecture. Learn VPC design, CloudFront CDN, Route 53 DNS, Direct Connect hybrid networking, and network security best practices aligned with AWS Well-Architected Framework.
AWS AI/ML Best Practices: SageMaker and Bedrock Architecture Guide
Master AWS AI/ML services. Learn SageMaker training/deployment, Bedrock generative AI, foundation model selection, MLOps patterns, and cost optimization for machine learning workloads.
AWS Compute Best Practices: The Complete Well-Architected Guide
Master EC2, Lambda, and ECS/EKS compute architectures. Learn right-sizing, auto-scaling, serverless patterns, and cost optimization strategies aligned with AWS Well-Architected Framework.