- IAM: Lock Down Access Before Anything Else
- S3: Audit Every Bucket for Public Access
- CloudTrail: Log Everything, Centralize Immediately
- VPC: Network Controls That Matter
- Encryption: At Rest and In Transit
- GuardDuty: Threat Detection You Cannot Afford to Skip
- AWS Config: Continuous Compliance Monitoring
- Organizations and SCPs: Guardrails at Scale
- AWS Security Services Comparison
- Frequently Asked Questions
AWS shared responsibility model puts the security of the cloud on Amazon and the security in the cloud on you. Most teams understand this in theory. In practice, misconfigured S3 buckets, overly permissive IAM roles, and disabled CloudTrail are still behind a significant portion of cloud breaches. This checklist covers the 12 controls that close the highest-risk gaps in a typical AWS environment.
IAM: Lock Down Access Before Anything Else
IAM is where most AWS breaches begin. A leaked access key with AdministratorAccess is game over. Start here:
- Delete root account access keys. The root account should only be used to set up the AWS Organization and create the first admin user. Lock it down with MFA and never touch it again.
- Enable MFA on all IAM users. Enforce it with an SCP: deny all actions except MFA enrollment for users without MFA active.
- Use IAM roles, not long-term keys. EC2 instances, Lambda functions, and ECS tasks should use instance profiles and execution roles — never a hardcoded access key.
- Apply least-privilege policies. Use IAM Access Analyzer to identify overly permissive policies. Start with the AWS-managed ReadOnlyAccess policy and tighten from there.
- Rotate access keys every 90 days. Use AWS Secrets Manager or SSM Parameter Store for applications that still require keys.
Red flag: If your AWS environment has active root account access keys, fix that before you read anything else in this article. It is the single highest-risk configuration in AWS.
S3: Audit Every Bucket for Public Access
S3 buckets defaulted to private since 2023, but older accounts and third-party deployments can still have public buckets exposing sensitive data. Run this check monthly:
- Enable S3 Block Public Access at the account level (covers all current and future buckets)
- Use AWS Config rule: s3-bucket-public-read-prohibited for continuous monitoring
- Enable S3 Server Access Logging on all buckets containing sensitive data
- Enable S3 Object Versioning on critical data buckets — protects against ransomware deletion
- Enforce SSE-S3 or SSE-KMS encryption at rest via bucket policy
CloudTrail: Log Everything, Centralize Immediately
CloudTrail is your audit log for every API call in AWS. Without it, you cannot investigate an incident. Enable it in every region, including regions you do not use — attackers create resources in unused regions specifically to avoid detection.
- Enable CloudTrail in all regions with multi-region trail
- Enable CloudTrail log file integrity validation
- Send logs to a dedicated, locked-down S3 bucket in a separate logging account
- Send CloudTrail events to CloudWatch Logs for real-time alerting
- Set up CloudWatch Alarms for: root login, console login without MFA, security group changes, and IAM policy modifications
Quick win: Enable AWS Security Hub with the CIS AWS Foundations Benchmark standard. It automatically checks 43 controls and gives you a scored dashboard of your current posture in under 5 minutes.
VPC: Network Controls That Matter
Default VPCs exist in every region and every account. Most have overly permissive default security groups. Clean this up:
- Delete the default VPC in regions you do not use
- Remove all inbound 0.0.0.0/0 rules from security groups except explicit public-facing services
- Enable VPC Flow Logs on all VPCs and ship to CloudWatch or S3
- Use private subnets for all compute resources; access via bastion host, AWS Systems Manager Session Manager, or VPN
- Never expose RDS, ElastiCache, or internal APIs directly to the internet
Common mistake: Security Group rules are stateful, but Network ACLs are not. If you rely on NACLs for blocking, verify both inbound and outbound rules. Forgetting outbound rules on NACLs is a classic misconfiguration.
Encryption: At Rest and In Transit
- Enable EBS volume encryption by default at the account level — this covers all future volumes automatically
- Enable RDS encryption at rest when creating instances (cannot be enabled post-creation)
- Enforce HTTPS-only access on all S3 buckets via bucket policy condition
aws:SecureTransport - Use AWS KMS with Customer Managed Keys for sensitive data; enables key rotation control and audit trail
- Enable Certificate Manager for all public-facing TLS certificates — automatic renewal, no manual certificate tracking
GuardDuty: Threat Detection You Cannot Afford to Skip
GuardDuty analyzes CloudTrail, VPC Flow Logs, and DNS logs using ML to detect: credential compromise, cryptomining, C2 communication, port scanning, and unusual API calls. At roughly $3 per account per month for small environments, it is the highest-value AWS security service. Enable it in every account and every region, and route findings to Security Hub and your SIEM.
AWS Config: Continuous Compliance Monitoring
AWS Config records every configuration change to AWS resources and evaluates them against rules you define. Use the managed rule set for CIS Benchmarks, PCI-DSS, or HIPAA. When a resource drifts from compliant state — a security group opens port 22 to 0.0.0.0/0 — Config flags it immediately and can auto-remediate via Lambda or SSM Automation.
Organizations and SCPs: Guardrails at Scale
If you run multiple AWS accounts (you should — separate workloads into separate accounts), AWS Organizations with Service Control Policies gives you preventative controls that override even Administrator access. Use SCPs to: prevent disabling CloudTrail, block access from non-approved regions, require MFA for sensitive actions, and deny root account API calls.
Takeaway: Security Hub, GuardDuty, CloudTrail, and S3 Block Public Access are the four non-negotiable baseline controls. Enable those first in every account. Then work through IAM hygiene, VPC cleanup, and encryption enforcement systematically. See our Security Tools page for CSPM platforms that automate this checklist across multi-account environments.
n
AWS Security Services Comparison
| Service | What It Does | Monthly Cost (small env) | Priority |
|---|---|---|---|
| GuardDuty | ML-based threat detection | ~$3-15 | Critical |
| Security Hub | Aggregates security findings, CIS benchmark checks | ~$1-5 | Critical |
| CloudTrail | API audit logging across all services | ~$2 (S3 storage) | Critical |
| AWS Config | Configuration compliance monitoring | ~$0.003/rule evaluation | High |
| Inspector | Vulnerability scanning for EC2, containers, Lambda | ~$1-10 | High |
| Macie | Sensitive data discovery in S3 | ~$1-5 | Medium |
| WAF | Web application firewall for CloudFront/ALB | ~$5 + $0.60/million requests | Medium |
🔗 Further Reading
Frequently Asked Questions
n
What is the AWS shared responsibility model?
n
The AWS shared responsibility model divides security obligations between AWS and the customer. AWS is responsible for the security of the cloud infrastructure (hardware, software, networking, and facilities). The customer is responsible for security in the cloud: operating system patches, application security, identity and access management, data encryption, and network configuration within their AWS environment.
n
n
What are the most critical AWS security controls?
n
The four non-negotiable AWS security controls are: (1) Enable GuardDuty in all regions for threat detection. (2) Enable CloudTrail across all regions with log integrity validation. (3) Enable S3 Block Public Access at the account level. (4) Delete root account access keys and enforce MFA on all IAM users. These four controls close the highest-risk gaps in any AWS environment.
n
n
How do I prevent S3 bucket data exposure?
n
Enable S3 Block Public Access at the AWS account level to prevent current and future public bucket configurations. Use bucket policies to enforce HTTPS-only access. Enable S3 access logging. Use AWS Config rule s3-bucket-public-read-prohibited for continuous compliance monitoring. Enable S3 Object Versioning on sensitive data buckets to protect against ransomware deletion.
n
n
What is AWS GuardDuty and why is it important?
n
AWS GuardDuty is a managed threat detection service that analyzes CloudTrail logs, VPC Flow Logs, and DNS logs using machine learning to detect compromised accounts, cryptomining, C2 communications, port scanning, and unusual API call patterns. It costs approximately $3 per account per month for small environments and provides threat detection capability that would otherwise require significant engineering effort to build manually.
n
n
n
