AWS Security Hardening: The Checklist Your Cloud Needs

If you're running anything in AWS, this one is for you. I've seen too many teams learn about AWS security the hard way -- a surprise bill from crypto-mining on a compromised instance, or worse, a data breach that makes the news. The good news? Most AWS security issues are preventable with a systematic approach. Here's the checklist your cloud needs.

This covers identity management, network security, data protection, monitoring, and compliance. Follow it to systematically eliminate common vulnerabilities, implement the principle of least privilege, and establish continuous security monitoring.

Phase 1: Identity & Access Management (IAM)

Root Account Protection

• Disable root account access keys completely -- Root keys provide unrestricted AWS account access; if compromised, attacker controls everything (CRITICAL)
• Enable MFA (Multi-Factor Authentication) on root account -- Prevents unauthorized access even if password is compromised (CRITICAL)
• Use hardware MFA device for root account (not virtual) -- Hardware tokens cannot be compromised via malware or phishing (CRITICAL)
• Remove all root account access keys -- Reduces blast radius; root keys have no permission boundaries
• Store root account password in secure offline location -- Root access should only be needed for rare account-level changes

IAM User & Role Strategy

• Adopt "roles not users" architecture wherever possible -- Roles use temporary credentials; users with long-term keys are high-risk targets (CRITICAL)
• Implement least privilege principle for all permissions -- Users with excessive permissions become high-value targets; limits blast radius (CRITICAL)
• Use IAM policy conditions to restrict by IP/time/device -- Adds second layer of defense; prevents access from suspicious locations
• Enable MFA for all human users (not just root) -- Protects individual user accounts from compromise
• Use temporary credentials from STS for cross-account access -- Temporary credentials automatically expire; cannot be reused if leaked
• Implement service control policies (SCPs) as guardrails -- Prevents entire categories of dangerous actions across organizational units
• Use temporary credentials with session duration limits -- Reduces window of exposure if credentials are compromised

Credential Management

• Rotate IAM access keys every 90 days (automated preferred) -- Limits damage window if old credentials are leaked (CRITICAL)
• Enable credential report generation and review quarterly -- Identifies unused/old credentials that should be removed (CRITICAL)
• Disable unused IAM users and keys immediately -- Orphaned accounts are forgotten about and become security holes
• Use AWS Secrets Manager or Parameter Store for sensitive data -- Never hardcode credentials in code or configuration files
• Implement automatic access key rotation for service accounts -- Reduces manual effort and human error in credential management
• Require strong password policy (14+ chars, complexity) -- Makes brute-force attacks computationally expensive

Cross-Account & External Access

• Use IAM roles for cross-account access instead of keys -- Prevents credential sprawl; temporary credentials are safer (CRITICAL)
• Document and audit all trust relationships -- Rogue trust relationships allow unauthorized access
• Use external ID for cross-account role assumption -- Prevents unauthorized parties from assuming your role
• Implement sts:AssumeRole time limits -- Expired sessions cannot be reused

Phase 2: Network Security

VPC & Subnet Architecture

• Use private subnets for databases and application servers -- Prevents direct internet exposure; forces traffic through security layers (CRITICAL)
• Implement public/private/database subnet tiers -- Network segmentation limits lateral movement if one tier is compromised (CRITICAL)
• Use VPC Flow Logs to monitor all network traffic -- Detects unauthorized connections; required for incident investigation
• Enable VPC Flow Logs to CloudWatch and S3 -- Provides both real-time alerts and long-term audit trail
• Use VPC endpoints for AWS service access (S3, DynamoDB, etc.) -- Keeps traffic off internet; prevents data exfiltration over public internet
• Implement service-to-service communication via service mesh -- Enforces mutual TLS authentication between microservices

Security Groups & NACLs

• Remove any security group rules allowing 0.0.0.0/0 from internet -- Exposes services to entire internet; makes systems attack targets (CRITICAL)
• Restrict database security group to application servers only -- Prevents direct database access from internet attackers (CRITICAL)
• Use NACL egress rules to block unexpected outbound traffic -- Prevents data exfiltration; detects compromised instances trying to call home
• Document and version control all security group rules -- Prevents undocumented/legacy rules; enables audit trail
• Implement security group chaining (restrict to specific SGs) -- More secure than CIDR ranges; auto-scales with environment
• Use Security Group Manager tools to prevent rule drift -- Catches accidental overly-permissive rules before deployment

Network Access Control

• Disable default VPC or isolate it -- Default VPC has overly permissive default security groups (CRITICAL)
• Use WAF (Web Application Firewall) for public web apps -- Blocks common web attacks (SQL injection, XSS, DDoS)
• Implement IP whitelisting for administrative tools -- Prevents brute-force attacks on bastion hosts/management interfaces
• Use AWS Shield Standard (auto-enabled) and Shield Advanced -- Protects against DDoS attacks; critical for public-facing apps
• Implement network segmentation using private link -- Adds zero-trust network access control

Phase 3: Data Protection & Encryption

Encryption in Transit

• Enable TLS/HTTPS for all public-facing applications -- Prevents eavesdropping on user data; required for compliance (CRITICAL)
• Use HTTPS for all communication between AWS services -- Protects against man-in-the-middle attacks within AWS (CRITICAL)
• Use TLS 1.2 minimum (TLS 1.3 preferred) -- Older TLS versions have known vulnerabilities
• Disable unencrypted protocols (HTTP, Telnet, FTP) -- These protocols send credentials in plaintext
• Use certificate pinning for critical APIs -- Prevents man-in-the-middle even if certificate authority is compromised
• Implement mutual TLS (mTLS) between services -- Both client and server verify each other's identity

Encryption at Rest

• Enable default encryption for all S3 buckets -- Prevents unencrypted sensitive data storage (CRITICAL)
• Use AWS KMS keys (not S3-managed encryption) -- KMS provides key rotation, access auditing, and compliance controls (CRITICAL)
• Enable EBS encryption for all volumes -- Protects against data theft if storage is physically accessed (CRITICAL)
• Enable RDS encryption at rest (all engines) -- Protects database from theft; required for most compliance standards
• Enable DynamoDB encryption at rest -- Protects NoSQL data; KMS provides key management
• Use customer-managed KMS keys instead of AWS-managed -- Gives you control over key rotation and access policies
• Implement key rotation policy (annual minimum) -- Limits damage window if master key is compromised

Key Management

• Restrict KMS key access with key policies -- Prevents unauthorized decryption of encrypted data (CRITICAL)
• Enable CloudTrail logging of KMS operations -- Detects unauthorized decryption attempts; required for compliance (CRITICAL)
• Use separate KMS keys for different purposes -- Limits blast radius if one key is compromised
• Implement key policy separation of duties -- Requires multiple approvals to decrypt sensitive data
• Implement KMS key alias naming for clarity -- Makes audits easier; prevents use of wrong key

Secrets Management

• Use AWS Secrets Manager for database passwords -- Prevents hardcoded credentials in application code (CRITICAL)
• Enable automatic secret rotation -- Limits damage if a secret is compromised
• Implement secret replication for disaster recovery -- Ensures applications can still authenticate after regional failure
• Use resource-based policies for secret access -- Prevents unauthorized applications from reading secrets

Phase 4: Storage Security

S3 Bucket Hardening

• Block all public access at bucket level -- Prevents accidental public exposure; easiest way to leak data (CRITICAL)
• Enable versioning on sensitive buckets -- Allows recovery from ransomware/accidental deletion (CRITICAL)
• Enable MFA Delete on critical buckets -- Prevents even admins from deleting bucket contents without MFA (CRITICAL)
• Use bucket policies to enforce HTTPS only -- Prevents unencrypted data transmission (CRITICAL)
• Enable S3 Object Lock (WORM) for compliance archives -- Prevents modification of audit logs and compliance records
• Use S3 Access Logging to track all bucket access -- Detects unauthorized access attempts; required for compliance
• Implement bucket lifecycle policies -- Automatically deletes old data; reduces exposure window

S3 Access Control

• Use IAM policies instead of bucket ACLs -- IAM policies are more flexible and easier to audit (CRITICAL)
• Disable S3 "Authenticated Users" group access -- Prevents any authenticated AWS user from accessing bucket (CRITICAL)
• Use presigned URLs with expiration for temporary access -- Limits exposure window; prevents indefinite access
• Use cross-account S3 access with assumed roles -- Temporary credentials are more secure than long-term keys

Phase 5: Compute Security

EC2 Instance Hardening

• Enforce IMDSv2 only -- Prevents SSRF attacks from reading instance credentials (CRITICAL)
• Use Systems Manager Session Manager instead of SSH/RDP -- No open ports to internet; audit trail; no key management (CRITICAL)
• Remove default SSH/RDP security group rules -- Prevents brute-force attacks on bastion hosts (CRITICAL)
• Enable detailed monitoring and CloudWatch Agent -- Detects anomalous behavior; enables performance baselines
• Use Systems Manager Patch Manager for OS updates -- Automates patching; reduces manual effort and human error
• Implement launch templates with security defaults -- Ensures all new instances follow security standards

Container Security (ECS/EKS)

• Use container image scanning for vulnerabilities -- Detects known CVEs before deployment (CRITICAL)
• Implement admission controllers (OPA/Gatekeeper for K8s) -- Prevents deployment of non-compliant images (CRITICAL)
• Use private ECR repositories with IAM access control -- Prevents pulling of unauthorized images
• Sign container images and verify signatures -- Prevents tampering; ensures image provenance
• Use pod security policies / security standards (Kubernetes) -- Prevents privilege escalation inside containers
• Implement network policies to restrict pod-to-pod traffic -- Prevents lateral movement if one pod is compromised

Lambda Security

• Use IAM execution role with minimal permissions -- Prevents lateral movement if function is compromised (CRITICAL)
• Store secrets in Secrets Manager, not environment variables -- Environment variables are visible in CloudWatch logs (CRITICAL)
• Enable VPC for Lambda (if accessing private resources) -- Keeps function within security perimeter
• Implement Lambda concurrency limits -- Prevents runaway costs from DDoS or malicious invocations

Phase 6: Database Security

RDS Hardening

• Place RDS instances in private subnets -- Prevents direct internet access; forces traffic through app layer (CRITICAL)
• Use AWS Secrets Manager for database credentials -- Prevents hardcoded passwords; enables automatic rotation (CRITICAL)
• Enable automated backups with appropriate retention -- Ensures recovery from data loss or corruption (CRITICAL)
• Enable encryption at rest for all RDS instances -- Protects data from physical access threats
• Enable audit logging -- Tracks who accessed what data and when

The bottom line: AWS security isn't a one-time setup. It's a continuous process. Work through this checklist methodically, then schedule quarterly reviews to catch drift. The cost of prevention is always less than the cost of a breach.

If you found this useful, share it with a colleague who needs it. Subscribe for more developer resources every week.

---

Want the full resource?

AWS Security Hardening Checklist — $5.99 on Gumroad

Get the complete, downloadable version. Perfect for bookmarking, printing, or sharing with your team.

Get it now on Gumroad →

---

If you found this useful, drop a ❤️ and follow for more developer resources every week.