After reviewing hundreds of AWS accounts, we see the same security mistakes repeated across businesses of every size. These are not theoretical risks — they are the exact misconfigurations that lead to data breaches, unauthorized access, and compliance failures. Here are 25 of the most common, organized by category, with concrete steps to fix each one.
Identity and Access Management
1. Root account without MFA. The root account has unrestricted access to every resource in your AWS account. Without multi-factor authentication, a compromised password gives attackers full control. Enable hardware MFA on root immediately and store the device securely offline.
2. Overly permissive IAM policies. Policies with "Effect": "Allow", "Action": "*", "Resource": "*" grant god-mode access to any user or role they are attached to. Replace wildcard policies with least-privilege permissions scoped to specific services and resources.
3. Long-lived access keys. Access keys that have not been rotated in months or years are a ticking time bomb. If leaked in code repositories or logs, they provide persistent access. Rotate keys every 90 days, or better yet, replace them entirely with IAM roles and temporary credentials.
4. No password policy enforced. Without a password policy, IAM users can set weak passwords like "password123." Configure minimum length (14+ characters), require mixed case, numbers, and symbols, and enforce rotation every 90 days.
5. Shared credentials across team members. When multiple people share a single IAM user, you lose all audit trail capability. You cannot determine who made a specific change. Create individual IAM users or, preferably, use AWS IAM Identity Center with federated authentication.
Network Security
6. Public subnets for private resources. Databases, application servers, and internal APIs should never be in public subnets with internet-facing routes. Place them in private subnets and use NAT gateways or VPC endpoints for outbound connectivity. This eliminates direct attack surface from the internet.
7. Overly permissive security groups. Security groups with 0.0.0.0/0 on ports like SSH (22) or RDP (3389) expose your instances to brute-force attacks from the entire internet. Restrict ingress rules to specific CIDR blocks, use bastion hosts, or implement AWS Systems Manager Session Manager for remote access.
8. No VPC flow logs enabled. Without flow logs, you have zero visibility into network traffic patterns. When a security incident occurs, you cannot determine what connections were made or data exfiltrated. Enable VPC flow logs and send them to CloudWatch Logs or S3 for analysis.
9. Default VPC still in use. The default VPC is configured for convenience, not security. It has public subnets, an internet gateway, and permissive default security group rules. Create custom VPCs with proper network segmentation and delete or restrict the default VPC in every region.
10. No network segmentation. Flat networks allow lateral movement — if one resource is compromised, the attacker can reach everything. Segment your VPC into tiers (public, application, data) with network ACLs and security groups controlling traffic between layers.
Storage Security
11. Public S3 buckets. Publicly accessible S3 buckets have caused some of the largest data breaches in history. Enable S3 Block Public Access at the account level to prevent any bucket from being made public, regardless of individual bucket policies or ACLs.
12. No encryption at rest. Unencrypted data stored in S3, EBS, or RDS is readable by anyone who gains access to the underlying storage or snapshots. Enable default encryption on all storage services using AWS KMS keys. This is free for SSE-S3 and minimal cost for KMS-managed keys.
13. No versioning on critical buckets. Without versioning, a malicious or accidental deletion permanently destroys your data. Enable versioning on buckets containing business-critical data and combine with MFA Delete to prevent unauthorized permanent deletions.
14. No lifecycle policies. Old versions, incomplete multipart uploads, and outdated objects accumulate cost and expand your attack surface. Implement lifecycle policies to transition old data to cheaper storage tiers and expire objects that are no longer needed.
Compute Security
15. Unpatched EC2 instances. Instances running outdated operating systems and software are vulnerable to known exploits. Use AWS Systems Manager Patch Manager to automate patching schedules and maintain compliance. Unpatched systems are the low-hanging fruit attackers target first.
16. IMDSv1 still enabled. Instance Metadata Service version 1 is vulnerable to Server-Side Request Forgery (SSRF) attacks that can steal IAM credentials from running instances. Enforce IMDSv2 on all instances, which requires session-based token authentication for metadata access.
17. No instance profiles used. Hardcoding access keys on EC2 instances is unnecessary and dangerous. Instance profiles attach IAM roles that provide temporary, automatically-rotated credentials. Any application running on EC2 should use instance profiles instead of static credentials.
18. Overly permissive instance roles. Instance roles with broad permissions (like full S3 access) mean a compromised instance can access all your data. Scope instance roles to the minimum permissions required by the specific application running on that instance.
Logging and Monitoring
19. CloudTrail disabled or single-region. CloudTrail is your audit log for all AWS API activity. Without it enabled in all regions, attackers can operate undetected in regions you are not monitoring. Enable a multi-region trail with log file validation and store logs in a protected S3 bucket.
20. No GuardDuty enabled. GuardDuty uses machine learning and threat intelligence to detect malicious activity in your account. It identifies compromised instances, reconnaissance attempts, and credential theft with zero configuration. Enable it in all regions — it costs pennies relative to the protection it provides.
21. No AWS Config rules. Without Config rules, you have no automated way to detect when resources drift from your security standards. Implement Config rules for critical controls like encrypted volumes, restricted security groups, and required tags. Use conformance packs for comprehensive baseline coverage.
22. No centralized logging. Logs scattered across individual instances and services make incident investigation nearly impossible. Centralize logs using CloudWatch Logs, a dedicated logging account, or a SIEM solution. Set retention policies and enable alerts for suspicious patterns.
Operational Security
23. No MFA on console users. IAM users with console access but no MFA are one phished password away from a breach. Enforce MFA for all human users through IAM policies that deny actions unless MFA is present. Use conditional policies to require MFA for sensitive operations.
24. No budget alerts configured. Unexpected charges often indicate compromised credentials being used to spin up cryptocurrency mining instances. AWS Budgets alerts at 50%, 80%, and 100% of expected spend serve as an early warning system for unauthorized usage.
25. No incident response plan. When a breach occurs, the worst time to figure out your response process is during the incident itself. Document your response plan including who to contact, how to isolate compromised resources, how to preserve evidence, and how to communicate with stakeholders. Test the plan with tabletop exercises at least annually.
Where to Start
If you recognize more than five of these mistakes in your environment, prioritize them by exploitability. Start with root MFA, public S3 remediation, and enabling GuardDuty — these three actions alone eliminate the most common attack vectors we see exploited in real breaches.