10 AWS Security Misconfigurations Found in 90% of Accounts

I've reviewed over 200 AWS accounts across startups and enterprises. These 10 security misconfigurations appear in more than 90% of them, and most teams don't know they exist until something goes wrong.

AWS security misconfigurations are incorrect settings in cloud infrastructure that expose resources to unauthorized access, data breaches, or service disruption. Unlike software vulnerabilities requiring patches, misconfigurations result from human error, default settings that aren't secured, or operational shortcuts that become permanent. Cloud misconfigurations cause over 80% of security breaches, making this the most impactful security work you can do.

The good news? Every issue I'll cover is detectable using native AWS tools, and most fixes take minutes to implement. By the end of this guide, you'll know exactly how to detect each issue using AWS Security Hub, Config rules, and CLI commands, plus the specific steps to fix them.

Here's a quick reference of all 10 misconfigurations with severity ratings and detection methods:

Let me walk through each one, including why it matters, how to detect it, and exactly how to fix it.

1. Public S3 Buckets

Severity: Critical

Public S3 buckets remain the most common and dangerous misconfiguration in AWS environments. Despite AWS making Block Public Access the default for new buckets as of April 2023, legacy buckets and misconfigurations continue to expose sensitive data.

Why It's Still the Number One Issue

AWS considers a bucket public when Access Control Lists (ACLs) grant permissions to the AllUsers or AuthenticatedUsers groups, or when bucket policies grant access to principals outside your zone of trust. The challenge is that buckets created before April 2023 don't have Block Public Access enabled by default, and a single misconfigured policy can override account-level protections.

Block Public Access provides four settings that work together:

• BlockPublicAcls: Prevents accepting public ACLs for buckets and objects
• IgnorePublicAcls: Ignores all public ACLs on buckets and objects
• BlockPublicPolicy: Rejects bucket policies that grant public access
• RestrictPublicBuckets: Restricts access to AWS service principals and authorized users only

How to Detect Public Buckets

Security Hub Controls: S3.1 (account-level), S3.8 (bucket-level), S3.2 (public read), S3.3 (public write)

Config Rules: s3-account-level-public-access-blocks, s3-bucket-public-read-prohibited

CLI Detection:

# Check account-level Block Public Access settings
aws s3control get-public-access-block --account-id <account-id>

# Check bucket-level settings
aws s3api get-public-access-block --bucket <bucket-name>

# Check bucket ACLs for public grants
aws s3api get-bucket-acl --bucket <bucket-name>

IAM Access Analyzer also automatically flags cross-account and public access, generating findings with details about the access level and external principal.

How to Fix and Prevent

Enable Block Public Access at the account level first, then verify bucket-level settings:

# Enable at account level (protects all buckets)
aws s3control put-public-access-block \
    --account-id <account-id> \
    --public-access-block-configuration \
    BlockPublicAcls=true,IgnorePublicAcls=true,BlockPublicPolicy=true,RestrictPublicBuckets=true

# Enable at bucket level
aws s3api put-public-access-block \
    --bucket <bucket-name> \
    --public-access-block-configuration \
    BlockPublicAcls=true,IgnorePublicAcls=true,BlockPublicPolicy=true,RestrictPublicBuckets=true

For legitimate public access needs, use CloudFront with Origin Access Control (OAC), presigned URLs with expiration times, or VPC endpoints for private access.

While S3 exposure is visible, IAM policy issues hide in plain sight, making them equally dangerous but harder to spot.

2. Overly Permissive IAM Policies

Severity: Critical

Overly permissive IAM policies violate the principle of least privilege and create the largest attack surface in most AWS accounts. When credentials are compromised, the damage is limited only by what those credentials can access.

Common Anti-Patterns

In my reviews, I consistently find these patterns:

• Full administrator permissions (*:*) granted to IAM users or roles
• Wildcard service actions like s3:* or ec2:* instead of specific operations
• Policies attached directly to users rather than groups or roles
• Missing condition keys that would restrict access by IP, organization, or MFA status
• No permissions boundaries for delegated administration

IAM users and roles have no permissions by default, which is the right starting point. The problem is that teams add permissions incrementally and rarely remove them.

How to Detect Overpermissioned Policies

Security Hub Controls: IAM.1 (admin privileges), IAM.2 (user-attached policies), IAM.21 (wildcard actions)

Config Rules: iam-policy-no-statements-with-admin-access, iam-user-no-policies-check

CLI Detection with IAM Access Analyzer:

# Validate a policy against best practices
aws accessanalyzer validate-policy \
    --policy-document file://policy.json \
    --policy-type IDENTITY_POLICY

# List policies attached to a user (should be empty - use groups)
aws iam list-attached-user-policies --user-name <user-name>

How to Implement Least Privilege

Start with AWS managed policies for job functions like ViewOnlyAccess, PowerUserAccess, or SecurityAudit. Then use IAM Access Analyzer's policy generation feature, which creates least-privilege policies based on actual CloudTrail access activity.

Here's an example of a properly scoped policy with condition keys:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["s3:GetObject", "s3:PutObject"],
      "Resource": "arn:aws:s3:::my-bucket/my-prefix/*",
      "Condition": {
        "IpAddress": {
          "aws:SourceIp": "203.0.113.0/24"
        },
        "Bool": {
          "aws:MultiFactorAuthPresent": "true"
        }
      }
    }
  ]
}

Use aws:PrincipalOrgID condition keys to ensure access only comes from within your AWS Organization, and review permissions every 90 days to identify and remove unused access.

For broader governance, consider using Service Control Policies to prevent misconfigurations before they happen.

Even perfect IAM policies mean nothing if your root account lacks MFA.

3. Missing MFA on Root Account

Severity: Critical

The root user has unrestricted access to everything in your AWS account, including the ability to close it entirely. Compromise of root credentials without MFA protection leads to complete account takeover, data destruction, and significant financial impact through unauthorized resource provisioning.

The Risk of Unprotected Root

As of 2025, AWS now enforces MFA for root users across all account types, including member accounts in AWS Organizations. But enforcement doesn't mean configuration. Many accounts I review have MFA enabled with a single device that's lost or inaccessible, which creates operational risk without the security benefit.

How to Detect Missing MFA

Security Hub Controls: IAM.6 (hardware MFA), IAM.9 (virtual MFA)

Config Rules: root-account-mfa-enabled, root-account-hardware-mfa-enabled

CLI Detection:

# Check if root account has MFA enabled
aws iam get-account-summary | grep "AccountMFAEnabled"

# List MFA devices for root user
aws iam list-mfa-devices

How to Enable MFA

AWS supports three MFA types, and I recommend using the strongest option your team can manage:

1. Passkeys and FIDO Security Keys (strongest): Physical devices like YubiKeys that use public key cryptography. These are phishing-resistant and provide the strongest authentication.

2. Virtual Authenticator Apps: Software applications like Google Authenticator, Microsoft Authenticator, or Authy that generate time-based codes.

3. Hardware TOTP Tokens: Physical devices generating six-digit codes. AWS recommends FIDO security keys over these due to their stronger security properties.

Best practices:

• Register multiple MFA devices (up to 8 supported) for redundancy
• Store MFA recovery information with multi-person approval
• Use a group email address for root user, not an individual's email
• Document and test root access procedures annually

With authentication secured, let's ensure your data at rest is encrypted.

4. Unencrypted EBS Volumes

Severity: High

EBS volumes are not encrypted by default unless you explicitly enable encryption by default at the Region level. Unencrypted volumes expose data at rest to unauthorized access if snapshots are shared, volumes are attached to compromised instances, or physical hardware is accessed.

Why Default Encryption Matters

When you enable encryption by default, EBS automatically encrypts new volumes, new volumes created from unencrypted snapshots, and snapshot copies. The encryption happens on the servers hosting EC2 instances, protecting both data at rest and data in transit between instances and volumes.

You have two key options:

• AWS managed key (aws/ebs): No configuration required, AWS handles everything
• Customer managed key: Provides control over key policies, rotation, and cross-account snapshot sharing

How to Find Unencrypted Volumes

Security Hub Controls: EC2.7 (encryption by default), EC2.3 (attached volumes encrypted)

Config Rules: ec2-ebs-encryption-by-default, encrypted-volumes

CLI Detection:

# Check if encryption by default is enabled
aws ec2 get-ebs-encryption-by-default --region <region>

# List unencrypted volumes
aws ec2 describe-volumes \
    --filters Name=encrypted,Values=false \
    --query 'Volumes[*].[VolumeId,State,Size]' \
    --output table

How to Enable Encryption

Enable encryption by default in each Region where you operate (this is Region-specific):

# Enable encryption by default
aws ec2 enable-ebs-encryption-by-default --region <region-name>

# Optionally set a customer managed key as default
aws ec2 modify-ebs-default-kms-key-id \
    --kms-key-id <kms-key-id> \
    --region <region-name>

For existing unencrypted volumes, you'll need to migrate via snapshots:

1. Create a snapshot of the unencrypted volume
2. Copy the snapshot with encryption enabled
3. Create a new encrypted volume from the encrypted snapshot
4. Stop the instance, detach old volume, attach new volume, restart

Encryption protects data at rest, but open security groups expose it to the network.

5. Security Groups with 0.0.0.0/0

Severity: High

Security groups with rules allowing ingress from 0.0.0.0/0 permit traffic from any IP address on the internet. While acceptable for ports 80 and 443 on public-facing load balancers, opening administrative or database ports to the world creates significant attack surface.

High-Risk Ports That Should Never Be Open

These ports should never be accessible from 0.0.0.0/0:

• 22 (SSH): Remote command-line access to Linux instances
• 3389 (RDP): Remote Desktop access to Windows instances
• 3306 (MySQL), 5432 (PostgreSQL), 1433 (MS SQL): Database access
• 27017 (MongoDB), 6379 (Redis): NoSQL and cache access
• 9200/9300 (Elasticsearch): Search engine access

How to Find Overly Permissive Rules

Security Hub Controls: EC2.18 (unrestricted traffic for authorized ports), EC2.19 (unrestricted high-risk ports)

Config Rules: restricted-ssh, restricted-common-ports, vpc-sg-open-only-to-authorized-ports

CLI Detection:

# List security groups with 0.0.0.0/0 rules
aws ec2 describe-security-groups \
    --query 'SecurityGroups[?IpPermissions[?IpRanges[?CidrIp==`0.0.0.0/0`]]].{GroupId:GroupId,GroupName:GroupName,VpcId:VpcId}' \
    --output table

# Find security groups with SSH open to the world
aws ec2 describe-security-groups \
    --filters Name=ip-permission.from-port,Values=22 \
              Name=ip-permission.to-port,Values=22 \
              Name=ip-permission.cidr,Values='0.0.0.0/0' \
    --query 'SecurityGroups[*].[GroupId,GroupName,VpcId]'

While you're auditing security groups, you might also want to find unused security groups in your account to reduce unnecessary attack surface.

Secure Alternatives to Open Ports

AWS Systems Manager Session Manager (Recommended): Eliminates the need for SSH or RDP ports entirely. Sessions are fully auditable via CloudTrail, controlled by IAM policies, and logged to S3 or CloudWatch Logs.

Security group references: Instead of IP ranges, reference other security groups for internal communication:

aws ec2 authorize-security-group-ingress \
    --group-id <target-security-group-id> \
    --protocol tcp \
    --port 3306 \
    --source-group <source-security-group-id>

Specific IP ranges: For legacy requirements, restrict to known office or VPN IP ranges rather than 0.0.0.0/0.

Even with tight network security, you need visibility into what's happening. That's where logging comes in.

6. Missing CloudTrail Logging

Severity: High

Without CloudTrail enabled, you have no record of who did what, when, and from where in your AWS account. This makes incident investigation impossible, compliance audits difficult, and unauthorized activity undetectable.

What Should Be Logged

CloudTrail captures four types of events:

1. Management Events (default, free): Control plane operations like creating instances, modifying security groups, and IAM changes
2. Data Events (additional charges): Data plane operations like S3 GetObject/PutObject and Lambda invocations
3. Network Activity Events: VPC Flow Logs metadata
4. Insights Events: Anomalous API call patterns detected by machine learning

CloudTrail Event History provides 90 days of management event retention for free, but you need a trail configured to retain logs longer or send them to CloudWatch Logs for alerting.

How to Detect Logging Gaps

Security Hub Controls: CloudTrail.1 (multi-Region trail), CloudTrail.2 (encryption), CloudTrail.4 (log validation), CloudTrail.5 (CloudWatch integration)

Config Rules: cloud-trail-enabled, multi-region-cloud-trail-enabled, cloud-trail-encryption-enabled

CLI Detection:

# List all trails
aws cloudtrail list-trails

# Check if trail is logging
aws cloudtrail get-trail-status --name my-trail

# Find trails that aren't multi-region (a gap)
aws cloudtrail describe-trails --query 'trailList[?IsMultiRegionTrail==`false`]'

How to Configure Proper Logging

Always create multi-Region trails. Single-Region trails miss activity in other Regions, including new Regions AWS adds over time.

# Create a multi-region trail with best practices enabled
aws cloudtrail create-trail \
    --name organization-trail \
    --s3-bucket-name cloudtrail-logs-bucket \
    --is-multi-region-trail \
    --enable-log-file-validation

# Start logging
aws cloudtrail start-logging --name organization-trail

For AWS Organizations, create an organization trail that automatically covers all member accounts. This is essential for AWS Organizations governance patterns.

Essential configuration checklist:

• Enable log file validation (detects tampering)
• Encrypt log files using KMS
• Configure S3 bucket policies to prevent unauthorized access
• Set up CloudWatch Logs for real-time alerting
• Enable CloudTrail Insights for anomaly detection

With logging in place, let's address the credentials that could be used against you.

7. Unused IAM Credentials

Severity: Medium

Unused credentials (access keys, passwords, roles, users) create significant risk. Forgotten credentials can be compromised without detection, used by former employees, or discovered in code repositories and configuration files by attackers.

The Hidden Risk of Stale Credentials

I regularly find access keys that haven't been used in over a year but remain active. These are prime targets: they have permissions, no one monitors them, and if compromised, no legitimate use would be disrupted to trigger an alert.

Types of unused credentials to track:

• Unused access keys: Not used for API calls within 90 days
• Unused passwords: Not used for console sign-in within 45-90 days
• Unused IAM roles: Not assumed within 90 days
• Unused IAM users: No activity (console or API) for extended periods

How to Find Unused Credentials

Security Hub Controls: IAM.3 (key rotation), IAM.8 (unused credentials), IAM.22 (credentials unused 45+ days)

Config Rules: iam-user-unused-credentials-check, access-keys-rotated

IAM Access Analyzer: Continuously monitors and generates findings for unused roles, access keys, and passwords over 90 days.

CLI Detection using Credential Report:

# Generate credential report
aws iam generate-credential-report

# Download and analyze
aws iam get-credential-report --output text --query Content | base64 --decode > credential-report.csv

# Get access key last used information
aws iam get-access-key-last-used --access-key-id <access-key-id>

The credential report includes user creation date, password last used, access key last used dates, and MFA status for every user.

How to Clean Up and Rotate

Disable before deleting: Always disable unused keys first and wait a period to ensure nothing breaks:

# Disable unused access key
aws iam update-access-key \
    --access-key-id <access-key-id> \
    --status Inactive \
    --user-name <user-name>

# After confirming no impact, delete
aws iam delete-access-key \
    --access-key-id <access-key-id> \
    --user-name <user-name>

Best practices:

• Rotate access keys every 90 days maximum
• Create a second access key before disabling the first (zero-downtime rotation)
• Remove credentials for users inactive over 45 days
• Use AWS Secrets Manager for automated rotation of database credentials
• Replace long-term credentials with IAM roles wherever possible

Credential hygiene matters, but so does your network architecture.

8. Default VPC Usage

Severity: Medium

Every AWS account comes with a default VPC in each Region. While convenient for getting started, default VPCs have security and operational limitations that make them unsuitable for production workloads.

Why Default VPCs Are Problematic

Security issues:

• Predictable CIDR block (172.31.0.0/16) makes network scanning easier
• Internet Gateway attached by default with public routes
• Default security group allows all inbound traffic from itself
• Public subnets by default with automatic public IP assignment
• No network segmentation or isolation

Operational limitations:

• Cannot customize CIDR block (always 172.31.0.0/16)
• Limited subnet sizing control
• Difficult to integrate with VPC peering or Transit Gateway systematically
• Cannot enforce organizational network standards

How to Identify Default VPC Resources

Security Hub Control: EC2.2 (default security group should not allow traffic)

Config Rule: vpc-default-security-group-closed

CLI Detection:

# List default VPCs across all regions
for region in $(aws ec2 describe-regions --query 'Regions[].RegionName' --output text); do
  echo "Region: $region"
  aws ec2 describe-vpcs \
    --region $region \
    --filters Name=isDefault,Values=true \
    --query 'Vpcs[*].[VpcId,CidrBlock]' \
    --output table
done

# Find instances in default VPC
aws ec2 describe-instances \
    --query 'Reservations[*].Instances[?VpcId==`<default-vpc-id>`].[InstanceId,InstanceType,State.Name]'

How to Migrate to Custom VPCs

Create custom VPCs with proper network segmentation:

# Create VPC with appropriate CIDR
aws ec2 create-vpc \
    --cidr-block 10.0.0.0/16 \
    --tag-specifications 'ResourceType=vpc,Tags=[{Key=Name,Value=Production-VPC}]'

# Create public and private subnets
aws ec2 create-subnet \
    --vpc-id <vpc-id> \
    --cidr-block 10.0.1.0/24 \
    --availability-zone us-east-1a \
    --tag-specifications 'ResourceType=subnet,Tags=[{Key=Name,Value=Public-Subnet-1A}]'

Best practices for custom VPCs:

• Deploy across at least 2 Availability Zones
• Create public, private, and data subnet tiers
• Use NAT Gateways for private subnet outbound access
• Enable VPC Flow Logs for traffic monitoring
• Use VPC endpoints for private connectivity to AWS services

Consider deleting default VPCs after migration to prevent accidental deployments. Note that AWS doesn't allow recreating them in the same Region once deleted.

With proper network architecture, ensure all traffic is encrypted.

9. Missing Encryption in Transit

Severity: Medium

Encryption in transit protects data as it travels over untrusted networks. Without it, traffic can be intercepted, modified, or analyzed through man-in-the-middle attacks.

TLS Requirements and Modern Standards

• Minimum TLS version: TLS 1.2 (TLS 1.0 and 1.1 are deprecated)
• TLS 1.3: Available across most AWS services for enhanced security and performance
• Cipher suites: Use strong, modern ciphers; avoid weak ones like RC4 or DES

How to Detect Unencrypted Traffic

Security Hub Controls: S3.5 (S3 SSL requests only), CloudFront.3 (encryption in transit)

Config Rules: alb-http-to-https-redirection-check, cloudfront-viewer-policy-https, s3-bucket-ssl-requests-only

CLI Detection:

# Check ALB listener security policy
aws elbv2 describe-listeners \
    --load-balancer-arn <alb-arn> \
    --query 'Listeners[?Protocol==`HTTPS`].[ListenerArn,SslPolicy]'

# Check CloudFront distribution TLS settings
aws cloudfront get-distribution-config --id <distribution-id>

How to Enforce HTTPS Everywhere

ALB Configuration: Use modern security policies and configure HTTP to HTTPS redirect:

# Create HTTPS listener with TLS 1.2/1.3
aws elbv2 create-listener \
    --load-balancer-arn <alb-arn> \
    --protocol HTTPS \
    --port 443 \
    --certificates CertificateArn=<certificate-arn> \
    --ssl-policy ELBSecurityPolicy-TLS13-1-2-2021-06 \
    --default-actions Type=forward,TargetGroupArn=<target-group-arn>

# Configure HTTP to HTTPS redirect
aws elbv2 create-listener \
    --load-balancer-arn <alb-arn> \
    --protocol HTTP \
    --port 80 \
    --default-actions Type=redirect,RedirectConfig='{Protocol=HTTPS,Port=443,StatusCode=HTTP_301}'

S3 Bucket Policy: Enforce HTTPS and minimum TLS version:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Deny",
      "Principal": "*",
      "Action": "s3:*",
      "Resource": ["arn:aws:s3:::my-bucket", "arn:aws:s3:::my-bucket/*"],
      "Condition": {
        "Bool": {"aws:SecureTransport": "false"}
      }
    },
    {
      "Effect": "Deny",
      "Principal": "*",
      "Action": "s3:*",
      "Resource": ["arn:aws:s3:::my-bucket/*"],
      "Condition": {
        "NumericLessThan": {"s3:TlsVersion": "1.2"}
      }
    }
  ]
}

CloudFront: Set ViewerProtocolPolicy to redirect-to-https and use TLSv1.2_2021 as minimum security policy.

Finally, let's ensure you have continuous compliance monitoring.

10. No AWS Config Rules

Severity: Medium

AWS Config continuously monitors and records resource configurations, evaluating them against rules that define desired states. Without Config rules enabled, you lack automated compliance checking and configuration drift detection. This is the meta-problem: having no system to catch the other nine issues.

Essential Config Rules for Security

AWS provides managed rules for common security requirements. Here are the essential categories:

Identity and Access Management:

• iam-password-policy
• iam-user-mfa-enabled
• root-account-mfa-enabled
• iam-policy-no-statements-with-admin-access
• access-keys-rotated

Encryption:

• encrypted-volumes
• ec2-ebs-encryption-by-default
• s3-bucket-server-side-encryption-enabled
• s3-bucket-ssl-requests-only

Network Security:

• restricted-ssh
• vpc-sg-open-only-to-authorized-ports
• vpc-default-security-group-closed

Logging:

• cloud-trail-enabled
• multi-region-cloud-trail-enabled

Public Access:

• s3-bucket-public-read-prohibited
• s3-bucket-public-write-prohibited
• rds-snapshots-public-prohibited

How to Check Config Status

# Check if Config recorder is running
aws configservice describe-configuration-recorders

# Get recorder status
aws configservice describe-configuration-recorder-status

# List existing rules
aws configservice describe-config-rules

How to Deploy Critical Rules

Start by enabling the Config recorder, then deploy rules:

# Enable Config recorder
aws configservice start-configuration-recorder \
    --configuration-recorder-name default

# Deploy encrypted-volumes rule
aws configservice put-config-rule \
    --config-rule '{
      "ConfigRuleName": "encrypted-volumes",
      "Source": {
        "Owner": "AWS",
        "SourceIdentifier": "ENCRYPTED_VOLUMES"
      }
    }'

# Deploy restricted-ssh rule
aws configservice put-config-rule \
    --config-rule '{
      "ConfigRuleName": "restricted-ssh",
      "Source": {
        "Owner": "AWS",
        "SourceIdentifier": "INCOMING_SSH_DISABLED"
      }
    }'

Conformance packs bundle multiple rules for compliance frameworks. AWS provides sample packs for PCI DSS, HIPAA, NIST 800-53, and CIS Benchmarks.

For multi-account deployments, use organization Config rules to deploy consistently across all accounts, which integrates well with AWS Organizations governance patterns.

Now that we've covered individual issues, let's look at tools that catch them all.

How to Detect All 10 Issues at Once

You don't need to run CLI commands for each misconfiguration individually. AWS provides tools that aggregate findings across multiple categories, giving you a single view of your security posture. For a comprehensive approach covering 55+ security checks across IAM, network, data, and logging domains, see our AWS security review checklist.

AWS Security Hub

Security Hub is your central aggregation point. It collects findings from AWS Config, GuardDuty, Inspector, IAM Access Analyzer, Firewall Manager, and Macie. The AWS Foundational Security Best Practices standard covers most of the misconfigurations in this guide and provides automated security checks with severity ratings.

# Enable Security Hub with default standards
aws securityhub enable-security-hub --enable-default-standards

Security Hub calculates security scores based on passed vs. enabled controls, making it easy to track improvement over time. It also supports cross-Region aggregation for a unified view across your entire AWS footprint.

IAM Access Analyzer

Access Analyzer focuses specifically on access issues using automated reasoning to identify external access. It performs three types of analysis:

• External access: Resources accessible outside your zone of trust
• Internal access: Which principals within your organization can access specific resources
• Unused access: Unused roles, access keys, passwords, and permissions

It also validates policies against IAM grammar and best practices before deployment, helping prevent misconfigurations proactively.

AWS Trusted Advisor

Trusted Advisor provides security checks including S3 bucket permissions, security group rules, IAM policies, MFA status, exposed access keys, and CloudTrail logging. Full security checks require Business or Enterprise Support plans.

Start with Security Hub. Enable it with the Foundational Security Best Practices standard, then layer on Access Analyzer for deeper IAM analysis and Trusted Advisor for broader operational recommendations.

Conclusion

These 10 misconfigurations appear repeatedly because they're easy to create accidentally and hard to spot without systematic monitoring. The good news is that AWS provides the tools to detect and fix all of them.

Start with the Critical items today: Enable S3 Block Public Access at the account level, verify root MFA, and audit your IAM policies for wildcards.

Enable Security Hub with the Foundational Security Best Practices standard for continuous monitoring of all 10 issues across your accounts.

Most fixes take minutes but prevent catastrophic breaches. A single public S3 bucket or overly permissive IAM policy can undo months of security work.

For a deeper understanding of AWS security fundamentals, check out AWS account security fundamentals and comprehensive AWS security best practices.

Quarterly security reviews catch drift before it becomes a problem. The misconfigurations I've covered aren't one-time fixes; they require ongoing vigilance as teams add resources, change configurations, and onboard new services.