AWS Security Best Practices: A Practitioner's Guide for 2026
AWS breaches follow predictable patterns. Overly permissive IAM roles exploited through SSRF. Access keys committed to public repositories and harvested by automated scanners within minutes. S3 buckets misconfigured to allow public access. CloudTrail disabled or logs unmonitored. GuardDuty not enabled in all regions.
None of these are novel attack techniques. They are predictable consequences of not configuring AWS security primitives correctly. This guide covers the specific configurations that close the most common attack paths — organized by security domain.
Briefings like this, every morning before 9am.
Threat intel, active CVEs, and campaign alerts — distilled for practitioners. 50,000+ subscribers. No noise.
IAM: The Most Impactful AWS Security Domain
IAM misconfiguration is the root cause of the majority of AWS security incidents. The controls that produce the most impact per implementation hour:
Eliminate the root account from operational use. The AWS root account has unrestricted access to all resources and cannot be restricted by IAM policies. Create individual IAM users or roles for all operations, enable MFA on the root account, rotate or delete root access keys, and store root credentials in a secure vault accessed only for break-glass scenarios.
Enforce MFA for all human IAM users. Apply an IAM policy that denies all actions except MFA enrollment for users who have not yet enrolled an MFA device. This is a well-documented pattern available in AWS documentation — implement it before the first human IAM user is created.
Implement least privilege through permission boundaries and SCPs. IAM permission boundaries cap the maximum permissions a role or user can be granted regardless of what policies are attached. Service Control Policies (SCPs) in AWS Organizations apply organization-wide guardrails — for example, preventing any account from disabling CloudTrail or from creating IAM roles without a specific boundary attached. SCPs are the most powerful least-privilege control available in multi-account AWS environments.
Audit and rotate access keys. Long-lived IAM access keys are the most commonly exploited AWS credential type. Audit key age with IAM Credential Report (generated via the console or API) and rotate or delete keys older than 90 days. For programmatic access, prefer IAM roles assumed via STS over long-lived access keys wherever possible — EC2 instance profiles, ECS task roles, Lambda execution roles all use temporary credentials rather than static keys.
Logging and Detection: CloudTrail, GuardDuty, and Security Hub
AWS provides native detection services that, when properly configured, detect the majority of account-level threats without custom detection logic. Most organizations have these services enabled but not configured to capture the full event set or respond to findings.
CloudTrail must be enabled in all regions with log file validation enabled. A single-region CloudTrail trail misses API calls made in unmonitored regions — a technique attackers use to avoid detection when establishing persistence. Enable a multi-region trail, enable S3 data event logging for buckets containing sensitive data, and ship CloudTrail logs to a centralized S3 bucket in a security logging account that the application accounts cannot modify or delete.
GuardDuty should be enabled in all AWS regions in all accounts. GuardDuty detects credential compromise (anomalous API call patterns, access from unusual geographic locations), EC2 instance compromise (outbound communication to known C2 IPs, cryptocurrency mining behavior), and S3 threat patterns (unusual data access patterns, public exposure). A common misconfiguration: GuardDuty enabled only in the primary region while attackers pivot to secondary regions. Enable GuardDuty organization-wide using AWS Organizations with auto-enable for new accounts.
AWS Security Hub provides a consolidated security findings view across GuardDuty, Inspector, Macie, IAM Access Analyzer, and Firewall Manager. Enable the Foundational Security Best Practices (FSBP) standard — it provides 94 automated checks across core AWS services that map directly to the CIS AWS Foundations Benchmark. Security Hub's findings score by severity; start remediation from Critical findings and work down. Integrate Security Hub findings with your SIEM or SOAR platform for centralized visibility.
Network Security: VPC Design and Exposure Reduction
VPC design decisions made at account creation time are expensive to change later. Security-conscious VPC architecture starts with private subnets for compute workloads and restricts internet access to specific, intentional paths.
Never place EC2 instances with sensitive workloads in public subnets with public IP addresses. Use private subnets for all application tier and database tier resources, with a NAT gateway in the public subnet for outbound internet access when required. Use a bastion host or AWS Systems Manager Session Manager for administrative access rather than opening SSH or RDP to the internet.
Security group rules should be as specific as possible. Avoid security groups that allow inbound access from 0.0.0.0/0 to anything other than a load balancer or CDN origin. Use security group references rather than CIDR ranges for inter-tier communication within the VPC — 'allow inbound on port 5432 from the application tier security group' is more resilient than 'allow inbound on port 5432 from 10.0.0.0/24' because it does not break when subnets are reconfigured. Enable VPC Flow Logs for all VPCs and ship them to your CloudTrail logging account for network-level forensics.
AWS Network Firewall (for layer 7 inspection) and WAF (for application layer HTTP filtering) provide defense in depth beyond security groups. WAF with managed rule groups (AWS Managed Rules, or third-party rule groups from the AWS Marketplace) covers OWASP Top 10 patterns at the network layer before traffic reaches application code.
S3, Secrets, and Data Protection
S3 data exposure is one of the most common AWS breach patterns. The specific controls that prevent it:
Enable S3 Block Public Access at the account level via the S3 console or through an SCP that denies s3:PutBucketPublicAccessBlock with a false value. Account-level Block Public Access prevents any bucket or object from becoming public regardless of bucket policy or ACL settings. This is a single control that eliminates the entire category of public S3 exposure.
For secrets management, never store credentials in EC2 user data, environment variables embedded in CloudFormation templates, or application configuration files checked into source control. Use AWS Secrets Manager or AWS Systems Manager Parameter Store (SecureString type) for all secrets, with IAM role-based access rather than hardcoded credentials. Secrets Manager provides automatic rotation for supported credential types (RDS database passwords, IAM access keys, Redshift credentials).
Enable Macie for continuous discovery of sensitive data in S3. Macie uses machine learning to identify buckets containing PII, payment card data, and credentials. In large organizations with hundreds of S3 buckets, Macie is more reliable than manual bucket inventory for identifying sensitive data exposure risks.
Enable server-side encryption for all S3 buckets with SSE-S3 minimum and SSE-KMS for buckets containing sensitive data. Apply bucket policies that deny s3:PutObject without server-side encryption specified — this ensures that applications that attempt to write unencrypted objects fail rather than silently succeeding.
Subscribe to unlock Remediation & Mitigation steps
Free subscribers unlock full IOC lists, remediation steps, and every daily briefing.
The bottom line
AWS security is primarily a configuration problem, not a tooling problem. GuardDuty, CloudTrail, Security Hub, and IAM Access Analyzer are available to every AWS account. The organizations that get breached are not the ones without tools — they are the ones with tools that are not enabled in all regions, not integrated with detection workflows, or not configured with the specific settings (multi-region trails, organization-wide GuardDuty, account-level S3 block public access) that close the common attack paths.
Frequently asked questions
What is the CIS AWS Foundations Benchmark?
The CIS AWS Foundations Benchmark is a prescriptive guide published by the Center for Internet Security containing specific, actionable configuration recommendations for securing AWS accounts. Version 3.0 covers IAM, storage, logging, monitoring, networking, and other service-level recommendations. AWS Security Hub can automatically audit your account against the CIS benchmark and report findings by severity. The benchmark is freely available at cisecurity.org and represents a solid baseline for any AWS security program.
How do I detect compromised IAM credentials in AWS?
GuardDuty detects compromised credentials through behavioral analysis: anomalous API calls from unusual geographic locations, credential use from Tor exit nodes, API calls from known malicious IPs, and unusual patterns like calling GetCallerIdentity from an unfamiliar source. CloudTrail logs every API call including unauthorized attempts. For automated detection: set CloudWatch alarms on GuardDuty finding types related to credential compromise (UnauthorizedAccess:IAMUser/*, CredentialAccess:IAMUser/*) and route high-severity findings to PagerDuty, Slack, or your SIEM via EventBridge.
What is the AWS Shared Responsibility Model?
AWS is responsible for the security 'of' the cloud: physical infrastructure, hardware, networking, hypervisor, and the managed services layer. Customers are responsible for security 'in' the cloud: operating system configuration, network and firewall configuration, IAM and access management, application security, and data encryption. In practice: AWS patches the underlying EC2 host hypervisor, but you patch the guest OS. AWS encrypts data at rest on the storage layer, but you configure encryption keys and access policies for your data. Understanding this boundary is essential for determining which controls AWS provides and which you must implement.
What AWS service covers container security?
Amazon Inspector v2 provides continuous vulnerability scanning for Amazon ECR container images and EC2 instances. It integrates with the CI/CD pipeline through the ECR enhanced scanning feature, which scans images at push and continuously as new CVEs are published. For Kubernetes workloads on EKS, AWS provides EKS security controls including pod security policies, network policies, and integration with GuardDuty for EKS audit log analysis. Supplemental tooling: Trivy (open source) and Snyk Container provide image scanning that integrates earlier in the build pipeline than Inspector.
Sources & references
Free resources
Critical CVE Reference Card 2025–2026
25 actively exploited vulnerabilities with CVSS scores, exploit status, and patch availability. Print it, pin it, share it with your SOC team.
Ransomware Incident Response Playbook
Step-by-step 24-hour IR checklist covering detection, containment, eradication, and recovery. Built for SOC teams, IR leads, and CISOs.
Get threat intel before your inbox does.
50,000+ security professionals read Decryption Digest for early warnings on zero-days, ransomware, and nation-state campaigns. Free, weekly, no spam.
Unsubscribe anytime. We never sell your data.
Founder & Cybersecurity Evangelist, Decryption Digest
Cybersecurity professional with expertise in threat intelligence, vulnerability research, and enterprise security. Covers zero-days, ransomware, and nation-state operations for 50,000+ security professionals weekly.