83% of cloud breaches stem from misconfigured controls — not zero-day exploits or sophisticated adversaries. The most preventable incidents in cloud security aren’t the ones you worry about. They’re the ones you don’t even know you’re skipping.

Here are the five controls that, when implemented correctly, reduce breach risk by 95%. Not the flashy ones. The foundational ones.

1. IAM Roles vs. Policies: Stop Assigning Permissions Directly

Every AWS account starts with root credentials. Every good security team destroys those within 24 hours of setup.

The mistake happens later: teams create IAM policies with specific permissions, then attach them directly to users or roles. This creates 2–3 layers of indirection that become impossible to audit at scale.

What actually works:

  • Never attach policies to users — always use groups or roles
  • Cap policy size at 2KB — anything larger indicates over-permissioning
  • Use SAML or OIDC federation for human access; service roles for machine access
  • Enable CloudTrail events for CreatePolicy and AttachUserPolicy — alert on both

At 100+ users, the average team manages 17–22 inline policies. With role-based policies, the same team maintains 3–5 policies — each with multiple attached roles.

2. S3 Bucket Public Access: It’s Not About ACLs

“We turned off ACLs — we’re safe” — This misconception persists because the console UI makes it feel like the job is done.

The real risk isn’t ACLs. It’s bucket policies, block public access settings, and object-level permissions.

What actually works:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Deny",
    "Principal": "*",
    "Action": "s3:GetObject",
    "Resource": "arn:aws:s3:::your-bucket-name/*",
    "Condition": {
      "StringEquals": {
        "aws:SourceVpc": "vpc-12345678"
      }
    }
  }]
}

Pair this with BlockPublicAccess enabled at the account level (not just per-bucket), and you’ve closed 99% of public access vectors.

Real-world impact: Teams that enforce account-level block public access reduce misconfiguration alerts by 68% in their first quarter.

3. KMS Key Rotation: You Already Have This Enabled

KMS key rotation sounds complex. The reality: AWS enables it by default for customer-managed keys, but teams disable it thinking it’ll improve performance.

The key insight: Rotation isn’t about new material — it’s about limiting the blast radius if a key is exposed. Each key generates ~1TB of encrypted data before rotation is recommended.

What actually works:

  • Enable automatic annual rotation for all customer-managed keys
  • Audit GetKeyRotationStatus monthly — alert on disabled rotation
  • Don’t rotate keys used for long-term archival or compliance records (e.g., 7+ year retention)

The performance impact: 0.03ms per encryption operation before and after rotation — measurable with CloudWatch, but irrelevant in 99% of workloads.

4. Logging Defaults: CloudTrail Without Data Is Just a Log

Most teams enable CloudTrail in the management account and forget about it. The problem: no data, no alerts, no verification.

What actually works:

  • Enable CloudTrail in every region where you have resources — not just us-east-1 and us-west-2
  • Create trails with CloudWatch Logs groups and set up metric filters for critical events:
    • CreateAccessKey (new credentials)
    • StopLogging (attempted log tampering)
    • DeleteTrail (security control removal)
    • UpdateSecurityGroup (network changes)
  • Send all logs to a centralized S3 bucket with Object Lock enabled (WORM storage)

Teams that implement all three see detection time drop from 142 hours (avg. for undetected breaches) to under 4 hours for critical events.

5. Network Isolation: Security Groups ≠ Firewall

Security groups are stateful, NACLs are stateless. Most teams treat them interchangeably — which worked until it didn’t.

The pattern that breaks: open ingress (0.0.0.0/0) on high ports, then rely on “it’s inside the VPC.”

What actually works:

  • Default-deny all ingress/egress — only allow what’s necessary
  • Use security group references (not CIDRs) for inter-service communication
  • Enable VPC Flow Logs for all public and private subnets
  • Audit ModifySecurityGroupRule events daily

Real result: Teams with strict security group policies see 73% fewer lateral movement attempts in their CSPM scans.

One Last Thing

Cloud security isn’t about implementing every control. It’s about ensuring the five I’ve listed here — IAM hygiene, public access prevention, key rotation, logging with alerts, and network isolation — are all in place, working, and continuously verified.

Breaches happen at the intersection of assumptions. Your checklist should measure what could go wrong, not what you hope won’t.