In June 2023, a misconfigured S3 bucket exposed 3.35 terabytes of data belonging to a major US government contractor — including sensitive personnel records, private encryption keys, and internal documentation.
The misconfiguration was simple: the bucket's block public access settings had been disabled during a development sprint and never re-enabled in production. No attacker exploited a vulnerability. No credential was stolen. The data was simply visible to anyone who knew the bucket name, which is not difficult to discover.
This incident is not unusual. Misconfiguration is consistently the leading cause of cloud security breaches — responsible for 80% of cloud data exposures according to the Gartner Cloud Security Report. AWS provides hundreds of security controls, natively integrated services, and detailed documentation.
The challenge is not that security tools are unavailable — it is that the default configuration of many AWS services prioritises ease of use over security, and teams under delivery pressure do not always harden every control. The result is an attack surface built incrementally from shortcuts that each seemed reasonable at the time.
This guide provides a complete, actionable AWS security checklist for 2026 — covering IAM, S3, VPC networking, encryption, logging, detection services, and compliance tooling. Every item includes the specific AWS service or CLI command to implement it, and why it matters. Work through it systematically against your own account using AWS Security Hub's Foundational Security Best Practices standard as a complementary automated check.
- Shared responsibility model — what AWS secures vs what you secure
- IAM security — identity is the new perimeter
- S3 security — hardening object storage
- VPC and network security
- Encryption at rest and in transit
- Logging and audit trail — CloudTrail, VPC Flow Logs, Config
- Threat detection — GuardDuty, Security Hub, Inspector
- EC2 and compute security
- Multi-account strategy and AWS Organizations
- Compliance and governance tooling
- Master security checklist — all controls in one place
- Frequently asked questions
The most important conceptual foundation for AWS security is understanding the shared responsibility model. AWS and the customer each own different parts of the security stack, and confusing these responsibilities is where most cloud security failures begin.
IAM (Identity and Access Management) is the most critical AWS security domain. Compromised IAM credentials are the starting point for the vast majority of AWS breaches — once an attacker has valid IAM credentials with sufficient permissions, every other AWS security control can be circumvented. IAM hardening is therefore the highest-priority AWS security investment.
The AWS root account has unrestricted access to everything in the account and cannot be restricted by IAM policies. It must be protected as if its compromise means total account loss — because it does.
Every IAM entity (user, role, group) should have only the permissions required to perform its specific function — nothing more. In practice, teams frequently attach AdministratorAccess or *:* wildcard policies because they are convenient. This means any compromise of that identity gives the attacker full account control. Use IAM Access Analyzer and the IAM policy simulator to identify and reduce over-permissive policies.
IAM access keys (access key ID + secret access key) are long-lived credentials that are frequently committed to source code repositories, stored in plaintext configuration files, or left in developer laptops. They are the most commonly stolen credential type in AWS breaches. Replace them with short-lived credentials from IAM roles wherever possible.
S3 misconfigurations are the single most common cause of cloud data breaches. The consequences of a public S3 bucket are severe and immediate — data is exposed to the entire internet without authentication. AWS has added account-level and bucket-level public access blocking, but these controls must be explicitly enabled and verified.
A well-designed VPC separates resources into subnets by tier and access level. Public subnets (internet-accessible) contain only load balancers and NAT gateways — never application servers or databases. Private subnets contain application servers that access the internet via NAT gateway but are not directly reachable from the internet. Isolated subnets contain databases and sensitive workloads with no internet route at all.
| Key type | Who manages it | Use case | Rotation | Cost |
|---|---|---|---|---|
| AWS managed key | AWS manages lifecycle automatically | Default encryption for S3, EBS, RDS — no customer involvement needed | Automatic annual | Free |
| Customer managed key (CMK) | You create and manage key policies | Sensitive workloads requiring audit, cross-account access, or custom rotation policies | Configurable (annual recommended) | $1/month per key + API calls |
| Customer provided key (SSE-C) | You generate and provide keys per request | S3 only — highest control, you hold the key material | Your responsibility | No AWS charge for the key |
| CloudHSM | You control dedicated HSM hardware | FIPS 140-2 Level 3 compliance, financial services, government | Your responsibility | $1.60/hour per HSM |
Logging is the foundation of security visibility in AWS. Without it, you cannot detect attacks, investigate incidents, demonstrate compliance, or understand what is happening in your account. AWS provides several complementary logging services — each capturing a different category of events.
GuardDuty analyses CloudTrail logs, VPC Flow Logs, DNS logs, and S3 data events using machine learning and threat intelligence to detect malicious behaviour. It requires no agents and no configuration of what to look for — it generates findings automatically. Enable it in every region and every AWS account in your organization.
Security Hub aggregates findings from GuardDuty, Inspector, Macie, IAM Access Analyzer, and third-party tools into a single dashboard. It also runs automated compliance checks against security standards — CIS AWS Foundations Benchmark, AWS Foundational Security Best Practices, and PCI DSS. Run these checks against your account immediately to get a prioritised remediation list.
Inspector v2 automatically discovers and scans EC2 instances, Lambda functions, and container images in ECR for OS-level CVEs and software vulnerabilities. It prioritises findings by exploitability and context — a critical CVE in a public-facing EC2 instance scores higher than the same CVE in an internal development instance. Enable it with a single API call; no agents needed for EC2 (uses SSM Agent).
Using a single AWS account for all workloads is the most common structural mistake in AWS security. A single account gives any compromised role or user access to every resource in the account — development, staging, production, and security tooling. AWS Organizations allows you to organise workloads into separate accounts with centralised governance.
| Service | What it does | Compliance relevance | Cost model |
|---|---|---|---|
| AWS Config | Records resource configurations continuously and evaluates against rules. Non-compliant resources flagged in real time. | SOC 2, PCI DSS, HIPAA, ISO 27001 — evidence of configuration control | $0.003 per configuration item recorded + rule evaluations |
| AWS Security Hub | Aggregates findings from GuardDuty, Inspector, Macie. Runs CIS, FSBP, PCI DSS automated checks. | CIS AWS Foundations Benchmark, PCI DSS, NIST 800-53 | 30-day free trial; $0.0010 per check after |
| AWS Audit Manager | Continuously collects evidence mapped to compliance frameworks (PCI DSS, SOC 2, HIPAA, GDPR). Auto-generates audit-ready reports. | Reduces manual audit evidence collection by 80% | $1.25 per resource per month assessed |
| AWS Artifact | On-demand access to AWS compliance reports — SOC 1/2/3, PCI AOC, ISO certificates, HIPAA BAA | Provides AWS's own compliance documentation for audit packages | Free |
| AWS Organizations + SCPs | Enforces guardrails across all accounts — prevents violation of security policies even by admins | Evidence of preventive control across the organisation | Free (part of Organizations) |
| Amazon Macie | ML-based PII and sensitive data discovery in S3 | GDPR, CCPA, HIPAA — demonstrates data discovery and classification controls | $1 per bucket per month + $0.10 per GB assessed |
- ✓Enable MFA on the root account IAM — use hardware MFA, store credentials offlineCRITICAL
- ✓Delete all root account access keys IAM — zero access keys should exist for rootCRITICAL
- ✓Enable S3 Block Public Access at account level S3 — prevents any bucket from being accidentally made publicCRITICAL
- ✓Enable CloudTrail in all regions CloudTrail — with log file validation and delivery to protected S3 bucketCRITICAL
- ✓Enable GuardDuty in all regions and all accounts GuardDuty — 30-day free trial; $3–$5/month for most accountsCRITICAL
- ✓Enable MFA for all IAM users with console access IAM — enforce via IAM policyCRITICAL
- ✓No security groups with 0.0.0.0/0 inbound on port 22 or 3389 EC2 — use Session Manager insteadCRITICAL
- ✓Enable EBS default encryption EC2 — all new volumes encrypted automaticallyCRITICAL
- ✓No long-lived IAM access keys IAM — rotate or replace with roles; disable keys unused 90+ daysCRITICAL
- ✓Enforce IMDSv2 on all EC2 instances EC2 — prevents SSRF credential theftCRITICAL
- ✓Enable Security Hub with CIS and FSBP standards Security Hub — automated compliance scoring
- ✓Enable VPC Flow Logs on all VPCs VPC — delivered to CloudWatch Logs or S3
- ✓Enable AWS Config in all regions Config — record all resource changes
- ✓Enable S3 versioning and MFA delete on backup buckets S3
- ✓Enable S3 default encryption with KMS CMK for sensitive buckets KMS S3
- ✓Enable S3 HTTPS-only bucket policy on all buckets S3 — deny aws:SecureTransport=false
- ✓Enable Inspector v2 on all EC2 and Lambda Inspector — continuous CVE scanning
- ✓Enable KMS key rotation on all CMKs KMS — annual automatic rotation
- ✓Enable RDS encryption for all database instances RDS
- ✓CloudWatch alarms for all CIS benchmark events CloudWatch — root login, SG changes, IAM changes
- ✓Implement IAM Access Analyzer IAM — identify external access to your resources
- ✓Enable AWS Secrets Manager for all application secrets Secrets Manager — no secrets in code, env vars, or user data
- ✓Enable GuardDuty S3 Protection and EKS Protection GuardDuty
- ✓Deploy VPC endpoints for S3, SSM, KMS, and EC2 VPC — traffic stays off the internet
- ✓Enable SSM Patch Manager SSM — automated security patching for all EC2 instances
- ✓Migrate to multi-account structure with AWS Organizations Organizations — separate prod, dev, security, log archive
- ✓Implement Service Control Policies Organizations — deny disabling security services, restrict regions
- ✓Enable Amazon Macie on sensitive S3 buckets Macie — PII and credential discovery
- ✓Configure centralised log archive with immutable retention S3 — Object Lock, separate account
- ✓Implement permission boundaries on all developer IAM roles IAM
- ✓Deploy WAF on all internet-facing ALBs WAF — AWS managed rule groups for OWASP Top 10
- ✓Enable AWS Shield Standard Shield (free) — automatic DDoS protection for all AWS resources
- ✓Replace IAM access keys with IAM Roles Anywhere or OIDC federation IAM
- ✓Enable AWS Audit Manager Audit Manager — automate compliance evidence collection
- ✓Conduct quarterly IAM access reviews — remove unused permissions, users, roles
- ✓Use S3 Object Lock COMPLIANCE mode for all backup data S3 — ransomware-resistant
- ✓Deploy AWS Network Firewall or third-party NGFW for deep packet inspection Network Firewall
⚡ Start here — five actions you can take in the next hour
- Enable GuardDuty in every region right now — takes 30 seconds per region, 30-day free trial, and it immediately starts analysing CloudTrail and Flow Logs for malicious behaviour. If you have an AWS Organizations setup, enable it as a delegated admin from your Security account to cover all accounts simultaneously.
- Enable S3 Block Public Access at the account level — one CLI command covers all current and future buckets. Then run aws s3control get-public-access-block --account-id YOUR_ACCOUNT_ID to verify all four settings are true. This eliminates the most common AWS breach vector.
- Run the IAM credential report — aws iam generate-credential-report && aws iam get-credential-report. Look for: users without MFA, access keys older than 90 days, root access keys existing at all. Remediate each finding in order of severity.
- Enable Security Hub with default standards — aws securityhub enable-security-hub --enable-default-standards. Within an hour it will show you every CIS and AWS FSBP control failure in your account, prioritised by severity. This turns the entire checklist above into an automated finding list.
- Build toward cloud security maturity — AWS security connects directly to zero trust architecture (IAM is the identity layer), network segmentation (VPC design implements microsegmentation), and incident response (GuardDuty findings feed your SOAR playbooks). Zero trust guide → | IR plan → | IAM guide →
The highest-impact AWS security controls in priority order: enable MFA on the root account and delete its access keys; enable S3 Block Public Access at the account level; enable CloudTrail in all regions with log file validation; enable GuardDuty across all accounts and regions; enforce MFA for all IAM users; eliminate long-lived access keys in favour of IAM roles; enforce IMDSv2 on all EC2 instances to prevent SSRF-based credential theft; enable default EBS encryption; and remove all security groups with unrestricted inbound on SSH or RDP ports. These ten controls address the most commonly exploited misconfigurations in AWS breach investigations.
The AWS shared responsibility model divides security responsibilities between AWS and the customer. AWS is responsible for "security of the cloud" — the physical data centres, hardware, hypervisors, network infrastructure, and the software running managed services (S3, RDS, Lambda). Customers are responsible for "security in the cloud" — IAM configuration, data encryption choices, S3 bucket policies, security group rules, EC2 instance patching, application security, and monitoring. A misconfigured S3 bucket, weak IAM policy, or unpatched EC2 instance is the customer's responsibility — AWS cannot see inside your account configurations and does not fix them on your behalf.
Amazon GuardDuty detects malicious and anomalous activity by analysing CloudTrail API logs, VPC Flow Logs, DNS logs, and S3 data events using machine learning and threat intelligence. It generates findings for threats including: EC2 instances communicating with known C2 servers or malicious IPs, cryptocurrency mining activity, compromised IAM credentials making unusual API calls, API calls from Tor exit nodes, S3 data exfiltration, port scanning from EC2 instances, rootkit behaviour, and credential exfiltration attempts. It requires no agents and no configuration of detection rules — enable it with one API call and it generates findings automatically within minutes of enabling.
S3 bucket security requires several layered controls: enable Block Public Access at both the account level and the individual bucket level; attach a bucket policy that denies HTTP access (requiring HTTPS via aws:SecureTransport condition); enable default server-side encryption with KMS; enable versioning to protect against accidental or malicious deletion; enable server access logging to record every request; for backup buckets, enable S3 Object Lock in COMPLIANCE mode to create immutable, ransomware-resistant storage; and use IAM Access Analyzer to identify any external access grants. Regularly audit bucket policies and ACLs, and use AWS Config rules to flag buckets that deviate from your security baseline.
The CIS (Center for Internet Security) AWS Foundations Benchmark is a set of security configuration recommendations for AWS accounts, published and maintained by the non-profit CIS. It covers IAM, logging, monitoring, networking, and S3 controls across around 50 specific checks. AWS Security Hub runs automated checks against the CIS benchmark (currently v1.4) and scores your account against each control. Achieving a high CIS score is a common compliance requirement for SOC 2, PCI DSS, and ISO 27001 audits in cloud-hosted environments. The benchmark is freely available at cisecurity.org and is one of the most widely referenced cloud security standards globally.
Multiple accounts via AWS Organizations is strongly recommended for any organisation beyond a single small team. A single account means a compromised IAM role can potentially access all resources — production, development, security tooling, and sensitive data — in the same account. Separate accounts provide hard blast-radius boundaries: a compromise in the development account cannot reach production. The recommended structure separates workloads into production, staging, and development OUs, with dedicated accounts for security tooling, log archiving, and a management account for billing and Organizations governance. AWS provides the multi-account Landing Zone Accelerator as a free starting template for this structure.