How the Compliance Score is calculated

A proportional score per category: each affected resource counts once, weighted by its worst finding's severity, relative to the total resources of that category's type(s) — so 10 risky Security Groups out of 100 hurts less than 10 out of 10.

How it works

Three rules turn raw findings into one proportional score.

Per-resource, not per-finding

A resource with several findings (e.g. a Security Group open on both SSH and RDP) only counts once — its worst severity is used.

Proportional to inventory

The penalty is divided by the total resources of that category, so the score reflects the share affected, not a raw finding count.

Weighted overall score

Each category score (0–100) is combined into the overall score using the weights below — Security counts for the most.

Formula

category_score = 100 − (Σ worst finding weight / total resources in category) × 100

overall_score  = Σ (category_score × category weight)

Categories with zero resources of their type default to a score of 100 (nothing to penalize) rather than being counted as failing.

Severity weights

How much a single affected resource penalizes its category, by its worst finding's severity.

Severity	Weight	Meaning
High	1.0	Counts as a full affected resource.
Medium	0.6	Counts as 60% of an affected resource.
Low	0.3	Counts as 30% of an affected resource.

Category	Overall weight	Resource types counted
Security	50%	Security Groups KMS Keys Aurora Clusters RDS Instances Secrets
Messaging	30%	SNS Topics SQS Queues
Hygiene	20%	All resources (untagged / unnamed check)

Findings feeding the score 42 finding types

Each row is a type of operational finding detected in the background for the listed resource types and aggregated by the Compliance view.

Recommendation type	Severity	Resource types
Cluster red	High	OpenSearch Domains
High cpu	High	ElastiCache Clusters Replication Groups OpenSearch Domains
High error rate	High	Lambda Functions
High jvm heap	High	OpenSearch Domains
Low free storage	High	OpenSearch Domains
Near timeout	High	Lambda Functions
Restrict open rule	High	Security Groups
Restrict public access	High	RDS Instances Aurora Clusters
Add dlq	Medium	SQS Queues
Cluster yellow	Medium	OpenSearch Domains
Enable encryption	Medium	SNS Topics
Enable rotation	Medium	KMS Keys Secrets
High disk queue	Medium	OpenSearch Domains
High evictions	Medium	ElastiCache Clusters Replication Groups
Hpa saturated	Medium	Kubernetes Workloads
Increase request	Medium	Kubernetes Workloads
Limit throttle	Medium	Kubernetes Workloads
Long duration	Medium	Lambda Functions
Memory pressure	Medium	ElastiCache Clusters Replication Groups
Read throttles	Medium	DynamoDB Tables
Reduce request	Medium	Kubernetes Workloads
Replication lag	Medium	ElastiCache Clusters Replication Groups
Review	Medium	ALB / NLB Classic Load Balancers
Review provisioned throughput	Medium	EFS File Systems
Review stale secret	Medium	Secrets
Throttling	Medium	Lambda Functions
Write throttles	Medium	DynamoDB Tables
Consolidate objects	Low	S3 Buckets
Delete	Low	CloudWatch Log Groups
Enable encryption	Low	SQS Queues
Hpa idle	Low	Kubernetes Workloads
Hpa thrashing	Low	Kubernetes Workloads
Limit oversized	Low	Kubernetes Workloads
Low hit rate	Low	ElastiCache Clusters Replication Groups
Review idle topic	Low	SNS Topics
Right size	Low	DynamoDB Tables
Add gateway endpoints	Info	NAT Gateways
High availability	Info	RDS Instances Aurora Clusters
Review	Info	NAT Gateways
Review ha topology	Info	Aurora Clusters
Review stopped	Info	RDS Instances
Versioning	Info	S3 Buckets

Hygiene is computed inline (not from the Recommendation table): any resource without a name tag counts as a low-severity finding against the total resource count.