The 69 AWS checks 6WAF runs automatically

EBS in available (detached) state → $0.08–0.125/GB/month even when unused

BytesOutToDestination < 1 GB/day for 14 days → fixed charge $0.045/hr (~$32/mo)

Lambda not invoked for 30 days — Provisioned Concurrency still billed

0 database connections for 7 consecutive days → forgotten instance, 100% savings possible

0 records for 14 days → shard-hour charge $0.015/shard/hr (~$11/shard/mo)

EFS $0.30/GB/month — 13× more expensive than S3. Small filesystems not using POSIX should migrate to S3

ML endpoint not invoked for 7 days — model still in S3, endpoint can be safely deleted

Site-to-site VPN 0 bytes for 14 days → $36.50/month fixed charge being wasted

Health check not attached to any record set → $0.50–1.00/month per check

EIP not attached to a running instance → AWS charges $0.005/hr when idle

ALB/NLB/Classic ELB with no healthy targets → fixed charge $0.008–0.025/hr

avg CPU < 20% and peak < 40% for 14 days → downsize 1 tier (CloudWatch CPUUtilization)

Max connections < 10 for 14 days → downsize 1 tier; Multi-AZ × 2

avg CPU < 20% and connections < 5 → recommend pause/resume off-hours (~50% savings)

avg CPU < 20% and JVM < 60% for 14 days → downsize instance type

avg CPU utilization < 25% (Container Insights) → reduce task CPU reservation (Fargate only)

Redis/Memcached node CPU < 20% and memory < 20% → downsize 1 tier

Peak consumed IOPS < 30% provisioned IOPS → migrate to gp3 with custom IOPS (much cheaper)

Instance tagged Environment=dev/test/staging has Multi-AZ enabled → 50% savings when disabled

avg utilization < 20% RCU/WCU for 14 days → switch to PAY_PER_REQUEST

avg memory < 30% allocated (Lambda Insights required) → reduce memory, save GB-seconds

avg CPU < 20% on brokers for 14 days → downsize instance type or reduce broker count

Cache nodes running 90+ days On-Demand → 1-year Reserved Node saves ~30%

Domain running 90+ days → 1-year RI saves ~28%

Cluster running 90+ days On-Demand → Reserved Node saves ~34%

RI or SP utilization < 50% — paying upfront for capacity that's going unused

EC2 tagged Environment=dev/test/staging running continuously → auto-stop saves 64%

Traffic to S3/DDB via NAT Gateway → paying $0.045/GB NAT fee; Gateway Endpoint is FREE

HTTP API (v2) $1.00/million requests vs REST API $3.50/million — 71% cheaper

Public S3 bucket > 1 GB/day without CloudFront → main benefits are latency + GET request-cost offload (per-GB egress rates are similar — informational)

Instances tagged dev/test/batch/worker running On-Demand → Spot saves 60–90%

AMI/snapshot > 90 days not attached to any running instance → $0.05/GB/month

Bucket > 1 GB Standard without lifecycle rule → save ~30% by moving to IA/Glacier

Container image > 90 days (not tagged 'latest') → save $0.10/GB/month

gp2 $0.10/GB vs gp3 $0.08/GB — migrate to gp3, save $0.02/GB/month (no downtime)

Log group with no expiry → $0.03/GB/month accumulating indefinitely

Multipart uploads > 7 days incomplete → storage charged for uncommitted parts

Bucket has versioning enabled but no NoncurrentVersionExpiration → ~50% storage is old versions

Stopped instance incurs no CPU cost but EBS volumes still charged $0.08–0.125/GB/month

Root has full access and cannot be restricted by IAM policy — without MFA the whole account is one stolen password from takeover

Root access keys are the most dangerous attack vector — never use them in code or automation

No account password policy is set, so IAM users can choose arbitrarily weak passwords

Minimum length in the password policy is under 14 characters (6WAF's recommended threshold, aligned to CIS)

The password policy does not stop users from returning to previous passwords

No MaxPasswordAge is set, so a leaked password stays valid indefinitely

An IAM user access key has not been used for more than 90 days — deactivate or delete it

IAM users sign in to the console with long-term passwords instead of centralised SSO/federation

No instance profile attached, which tends to push applications into storing static access keys on the host

The bucket does not have all four Public Access Block settings enabled, or has no configuration at all — risk of public data exposure

Account-level Block Public Access is not fully enabled, so newly created buckets are not protected by default

The bucket is encrypted with S3-managed keys, without KMS key control and its dedicated audit trail

The bucket does not declare a default encryption configuration explicitly

The volume is not encrypted at rest, and snapshots taken from it are not encrypted either

A customer-managed symmetric KMS key in Enabled state has rotation off; AWS-managed and asymmetric keys are skipped

An inbound rule allows all protocols from 0.0.0.0/0 or ::/0 — every port is reachable

A Security Group allows SSH from 0.0.0.0/0 — exposed to brute-force and credential stuffing

A Security Group allows RDP from 0.0.0.0/0 — exposed to brute-force and credential stuffing

No network traffic logs are available to investigate incidents or spot unusual access

No trail exists — administrative activity in the account is not recorded for audit

The trail exists but logging is stopped, leaving a gap in the audit trail

No trail records activity in all regions, so activity in rarely used regions may go unrecorded

You cannot prove log files were not modified or deleted after delivery

You cannot build real-time metric filters and alarms on CloudTrail events

The instance runs in a single Availability Zone — an AZ outage takes the database offline until it is restored

An accidental delete or bad write cannot be rolled back to an earlier point within the last 35 days

All instances sit in one AZ, so losing that AZ removes all serving capacity

Subnets route through a NAT gateway in another AZ — that AZ failing cuts outbound access for the others (severity is a 6WAF classification; no matching Security Hub control)

RDS and DynamoDB (Medium) and in-use EBS volumes (Low) are not protected by an AWS Backup plan

Overwritten or deleted objects cannot be restored to a previous version