AWS Security Misconfigurations: The 10 Mistakes Everyone Makes

Why AWS Misconfigurations Matter

The cloud doesn't get breached because AWS is insecure — it gets breached because people misconfigure it. AWS provides the tools for strong security, but the shared responsibility model means everything above the infrastructure layer is on you.

According to Gartner, through 2028, over 99% of cloud security failures will be the customer's fault. Here are the 10 misconfigurations that cause the most damage.

1. Public S3 Buckets

The classic. Companies store sensitive data in S3, forget to restrict access, and attackers find it using automated scanning tools.

The Mistake

# This bucket policy allows ANYONE to read everything
{
  "Effect": "Allow",
  "Principal": "*",
  "Action": "s3:GetObject",
  "Resource": "arn:aws:s3:::my-bucket/*"
}

Detection

# Check for public buckets
aws s3api list-buckets --query 'Buckets[].Name' --output text | \
  xargs -I {} aws s3api get-bucket-acl --bucket {} | grep -i "public"

# Check bucket policy
aws s3api get-bucket-policy --bucket my-bucket

Fix

# Block all public access (account-level)
aws s3control put-public-access-block \
  --account-id 123456789012 \
  --public-access-block-configuration \
  BlockPublicAcls=true,IgnorePublicAcls=true,\
  BlockPublicPolicy=true,RestrictPublicBuckets=true

2. Overprivileged IAM Roles

Giving services or users AdministratorAccess or *:* permissions because it's "easier." When that role is compromised, the attacker owns your entire account.

The Mistake

# NEVER DO THIS
{
  "Effect": "Allow",
  "Action": "*",
  "Resource": "*"
}

Fix

# Least privilege — only allow what's needed
{
  "Effect": "Allow",
  "Action": [
    "s3:GetObject",
    "s3:PutObject"
  ],
  "Resource": "arn:aws:s3:::my-app-uploads/*"
}

# Use IAM Access Analyzer to find unused permissions
aws accessanalyzer create-analyzer --analyzer-name my-analyzer --type ACCOUNT

3. Hardcoded Credentials in Code

AWS access keys committed to GitHub repos. Automated bots scan for these within seconds.

Detection

# Search your codebase for AWS keys
grep -rn "AKIA" .  # AWS access key IDs start with AKIA
grep -rn "aws_secret_access_key" .

# Use git-secrets to prevent committing secrets
git secrets --install
git secrets --register-aws

Fix

• Use IAM roles instead of access keys (for EC2, Lambda, ECS)
• Use AWS Secrets Manager or SSM Parameter Store for application secrets
• Rotate keys every 90 days. Delete unused keys.

4. Default VPC and Security Groups

The default VPC has an internet gateway and permissive security groups. New EC2 instances launched in the default VPC may be publicly accessible.

Detection

# Find security groups allowing 0.0.0.0/0 on SSH
aws ec2 describe-security-groups \
  --filters "Name=ip-permission.cidr,Values=0.0.0.0/0" \
  --query 'SecurityGroups[?IpPermissions[?FromPort==`22`]].[GroupId,GroupName]'

Fix

• Delete or restrict the default VPC security group
• Never allow 0.0.0.0/0 on SSH (port 22) or RDP (port 3389)
• Use AWS Systems Manager Session Manager instead of direct SSH

5. Unencrypted Data at Rest

EBS volumes, RDS databases, and S3 buckets without server-side encryption.

Fix

# Enable default S3 encryption
aws s3api put-bucket-encryption --bucket my-bucket \
  --server-side-encryption-configuration '{
    "Rules": [{"ApplyServerSideEncryptionByDefault": {"SSEAlgorithm": "aws:kms"}}]
  }'

# Enable EBS encryption by default (account-level)
aws ec2 enable-ebs-encryption-by-default

6. CloudTrail Not Enabled

CloudTrail logs every API call in your account. Without it, you have zero visibility into who did what. Many accounts disable it or don't enable it in all regions.

Fix

# Create a multi-region trail
aws cloudtrail create-trail \
  --name security-trail \
  --s3-bucket-name my-cloudtrail-logs \
  --is-multi-region-trail \
  --enable-log-file-validation

aws cloudtrail start-logging --name security-trail

7. No MFA on Root Account

The root account has unrestricted access to everything. Without MFA, a leaked password gives complete control.

Fix

• Enable hardware MFA on the root account (YubiKey preferred)
• Never use root for daily tasks — create IAM users/roles
• Delete root access keys if they exist
• Set up AWS Organizations with SCPs (Service Control Policies)

8. Publicly Accessible RDS Instances

Databases directly accessible from the internet. Combined with weak passwords, this is a recipe for data breaches.

Detection

aws rds describe-db-instances \
  --query 'DBInstances[?PubliclyAccessible==`true`].[DBInstanceIdentifier,Endpoint.Address]'

Fix

• Set PubliclyAccessible to false
• Place databases in private subnets
• Use VPC security groups to restrict access to application servers only

9. Lambda Functions with Excessive Permissions

Lambda execution roles often get AmazonS3FullAccess or AmazonDynamoDBFullAccess when they only need read access to one table.

Fix

# Specific policy for a Lambda function
{
  "Effect": "Allow",
  "Action": ["dynamodb:GetItem", "dynamodb:Query"],
  "Resource": "arn:aws:dynamodb:us-east-1:123456789012:table/orders"
}

10. Missing GuardDuty

GuardDuty is AWS's threat detection service that monitors for malicious activity. It's cheap (~$1/GB of CloudTrail logs) and catches real attacks. Many accounts don't enable it.

Fix

# Enable GuardDuty
aws guardduty create-detector --enable

# Enable in all regions
for region in $(aws ec2 describe-regions --query 'Regions[].RegionName' --output text); do
  aws guardduty create-detector --enable --region $region
done

AWS Security Checklist

1. ✅ Block public S3 access at account level
2. ✅ Follow least privilege for all IAM roles
3. ✅ No hardcoded credentials — use IAM roles and Secrets Manager
4. ✅ Restrict security groups — no 0.0.0.0/0 on management ports
5. ✅ Encrypt everything at rest (S3, EBS, RDS)
6. ✅ CloudTrail enabled in all regions with log validation
7. ✅ MFA on root + all human users
8. ✅ RDS in private subnets, not publicly accessible
9. ✅ Lambda roles scoped to minimum permissions
10. ✅ GuardDuty enabled in all regions

Key Takeaways

• The cloud is only as secure as your configuration — AWS doesn't secure it for you
• Most breaches come from the same 10 misconfigurations — this list covers 90%+ of real incidents
• Use AWS Security Hub to get a unified view of your security posture
• Automate checks with tools like ScoutSuite, Prowler, or AWS Config Rules
• Enable CloudTrail + GuardDuty + Config from day one — they're your security foundation