AWS Compliance Monitoring & Risk Scoring: Quantify Your Security Posture

Compliance in AWS is not a binary state. You are not simply "compliant" or "non-compliant" — you exist at a specific point on a spectrum that shifts continuously as resources are provisioned, configurations change, policies drift, and new findings are generated. The challenge is measuring where you stand on that spectrum at any given moment, tracking how your position changes over time, and prioritizing the specific findings that move the needle most effectively.

Risk scoring transforms the overwhelming volume of compliance data generated by AWS services into actionable metrics. Rather than reviewing hundreds of individual findings across multiple dashboards, a well-designed risk score provides a single, defensible measure of account health that can be tracked over time, compared across accounts, and used to prioritize remediation efforts.

This guide covers the architecture of AWS compliance monitoring, the native tools that provide compliance data, how to build a meaningful risk scoring model, and the operational practices required to maintain continuous compliance at scale.

The Compliance Monitoring Landscape in AWS

AWS provides multiple services that generate compliance-relevant data, each operating at a different layer of the stack and producing different types of findings.

AWS Config — Configuration Compliance

AWS Config is the foundational compliance monitoring service. It continuously records the configuration state of your AWS resources — EC2 instances, security groups, IAM policies, S3 buckets, RDS instances, and over 300 other resource types — and evaluates that state against rules that define your compliance requirements.

Config rules can be AWS-managed, covering common compliance checks like whether CloudTrail is enabled, whether S3 buckets have public access blocked, whether IAM policies restrict admin access, and whether encryption is enabled on storage resources. Custom rules, implemented as Lambda functions, can evaluate any configuration attribute against any logic you define.

Config's conformance packs bundle related rules into compliance frameworks. AWS provides pre-built conformance packs for CIS AWS Foundations Benchmark, PCI DSS, HIPAA, NIST 800-53, and other standards. Deploying a conformance pack instantly evaluates your environment against the full set of controls in that framework and generates a compliance summary with pass/fail status for each rule.

The compliance score produced by Config is straightforward: the percentage of rules that your resources pass. A 95% compliance score means that 95% of your rule evaluations returned COMPLIANT. This is useful as a high-level metric but has significant limitations — it treats all rules as equal, regardless of severity, and it does not account for the risk context of the non-compliant resources.

AWS Security Hub — Standards-Based Scoring

Security Hub extends Config's compliance model with security-specific standards evaluations and a weighted scoring system. Security Hub's security score reflects the proportion of passed controls relative to total controls for each enabled security standard, with the score calculated per standard and as an aggregate across all enabled standards.

Security Hub evaluates controls from the AWS Foundational Security Best Practices (FSBP), CIS AWS Foundations Benchmark, PCI DSS, and NIST 800-53. Each control is assigned a severity (CRITICAL, HIGH, MEDIUM, LOW) that influences its impact on the overall score. A single failing critical control reduces the score more than multiple failing low-severity controls.

Security Hub's scoring is more nuanced than Config's percentage-based compliance score, but it still operates within the security configuration domain. It does not incorporate billing health, operational metrics, or service quota status into its scoring model.

AWS Trusted Advisor

Trusted Advisor evaluates your AWS environment against a set of checks covering cost optimization, performance, security, fault tolerance, and service limits. The security checks overlap partially with Config and Security Hub — verifying MFA status, security group configurations, and IAM access key rotation — but Trusted Advisor also covers operational categories that other tools ignore.

The service limits category is particularly relevant for compliance risk scoring. Service quotas define the maximum number of resources you can provision for each AWS service in each region. Approaching or exceeding a service quota can cause resource provisioning failures, deployment failures, and cascading operational issues. Monitoring service quota utilization is an essential component of operational risk assessment.

AWS Health Dashboard

AWS Health Dashboard surfaces account-specific events including scheduled maintenance, service disruptions, abuse notifications, and compliance-related communications. Health events can indicate that AWS has identified a potential issue with your account — such as an open security group that is being actively exploited — or that a service your workload depends on is experiencing degradation.

Health events should be included in your compliance monitoring pipeline because they represent external signals about account risk that are not captured by configuration-based monitoring tools.

Building a Risk Scoring Model

A meaningful risk score transforms heterogeneous compliance data into a single, interpretable metric. The model must account for finding severity, resource criticality, time-based degradation, and organizational context.

Signal Aggregation

The first step is aggregating findings from all relevant sources into a normalized data model. Each finding should include the source service (Config, Security Hub, GuardDuty, Trusted Advisor, Health), the severity level normalized to a common scale (Critical, High, Medium, Low, Informational), the affected resource with its account ID, region, and resource type, the compliance framework mapping if applicable (CIS control number, PCI DSS requirement), and the timestamp of first detection and current status (open, suppressed, resolved).

Scoring Algorithm

A basic risk score starts with a maximum score of 100 (representing a fully compliant account) and deducts points for each open finding based on its severity. Critical findings deduct the most points, informational findings the least. This produces a score that decreases as the number and severity of open findings increase.

A more sophisticated model incorporates several additional factors. Resource criticality weights findings differently based on whether the affected resource is in a production account or a sandbox account, whether it handles sensitive data, and whether it is internet-facing. A public S3 bucket finding in a production account scores higher risk than the same finding in an internal development account.

Age-based degradation increases the risk contribution of a finding over time. A high-severity finding that has been open for 7 days represents more risk than one opened today, because it indicates either that the finding has not been triaged or that remediation is blocked. This decay factor incentivizes timely resolution.

Trend analysis evaluates whether the score is improving, stable, or degrading. An account with a score of 75 that was at 85 last week is more concerning than an account with a steady score of 75. Trend detection surfaces accounts that are drifting toward risk even if their absolute score has not yet crossed a threshold.

Dimensional Scoring

Rather than a single aggregate score, provide dimensional scores that break down risk by category: security posture (based on Security Hub findings, GuardDuty detections, and IAM analysis), compliance status (based on Config conformance pack evaluations against regulatory standards), cost health (based on budget adherence, anomaly detection alerts, and spend trends), and operational health (based on service quota utilization, Health Dashboard events, and resource configuration status).

Dimensional scores enable targeted remediation. An account with a good security score but poor cost health needs a different intervention than an account with poor security and healthy costs.

Service Quota Monitoring

Service quotas are a frequently overlooked compliance and operational risk. AWS imposes limits on the number of resources you can create for each service in each region — the number of VPCs, EC2 instances, IAM roles, S3 buckets, Lambda concurrent executions, and hundreds of other resource types.

When you approach a service quota, new resource provisioning requests fail. If your Auto Scaling group needs to launch additional instances to handle a traffic spike but you have reached your EC2 instance quota in that region, your application cannot scale and users experience degraded performance or outages.

Monitor service quota utilization using the Service Quotas API. Deploy a Lambda function on a scheduled trigger that queries ListServiceQuotas and GetServiceQuotaApplied for each service you use, compares current utilization against the quota value, and alerts when utilization exceeds 80%. Integrate quota monitoring into your risk scoring model — an account at 95% of its VPC quota or Lambda concurrency quota carries operational risk that should be reflected in its health score.

Account Health Alerts

Account health alerts aggregate the actionable outputs of your compliance monitoring infrastructure into notifications that drive remediation. The alerting architecture should distinguish between immediate-action alerts that indicate active risk (a critical Security Hub finding, a GuardDuty detection, root account login), daily digest alerts that summarize compliance posture changes (new findings, resolved findings, score changes), and weekly trend reports that provide leadership-level visibility into organizational compliance trajectory.

Configure alert routing based on the account's organizational context. Production account alerts route to the on-call engineering team. Development account alerts route to the owning team's Slack channel. Shared infrastructure account alerts route to the platform engineering team. This routing ensures that alerts reach the people with the context and authority to act on them.

Operationalizing Compliance Monitoring

Remediation Workflows

Compliance monitoring generates findings. Findings require remediation. Without a defined workflow that assigns ownership, tracks progress, and escalates stale findings, your monitoring infrastructure produces alerts that no one acts on — a state worse than no monitoring, because it provides false assurance.

Implement a remediation workflow that automatically assigns new findings to the account owner or the team responsible for the affected resource. Set SLA targets for remediation based on finding severity — critical findings within 24 hours, high within 7 days, medium within 30 days. Escalate findings that exceed their SLA to management for prioritization. Track mean time to remediation (MTTR) as a key performance metric for your security program.

Automated Remediation

For well-understood, low-risk findings, implement automated remediation using AWS Systems Manager Automation documents or AWS Config remediation actions. Common automation targets include enabling S3 bucket encryption on non-compliant buckets, restricting overly permissive security groups, enabling CloudTrail logging in accounts where it has been disabled, and rotating IAM access keys that exceed age thresholds.

Automated remediation should be deployed cautiously and with appropriate guardrails. Limit automation to non-destructive changes (enabling features, restricting access) rather than destructive changes (terminating resources, deleting policies). Require human approval for remediation actions in production accounts.

Compliance Reporting

Regulatory compliance frameworks (SOC 2, ISO 27001, PCI DSS, HIPAA) require evidence of continuous monitoring and documented remediation processes. Your compliance monitoring infrastructure should produce exportable reports that map your AWS Config and Security Hub findings to specific framework controls, demonstrate that non-compliant findings were identified and remediated within defined timeframes, and provide historical compliance trend data showing continuous improvement or sustained compliance.

FAQ

What is an AWS account risk score?

An AWS account risk score is a composite metric that quantifies the overall health and compliance posture of an AWS account. It aggregates findings from security monitoring (GuardDuty, Security Hub), compliance evaluation (Config, conformance packs), operational health (service quotas, Health Dashboard), and billing status into a single, trackable number. The score provides a quick assessment of whether an account requires immediate attention and how its risk posture compares to other accounts in the organization.

How does AWS Security Hub calculate its security score?

Security Hub calculates a security score as the percentage of passed controls relative to total controls for each enabled security standard. Controls are weighted by severity — a failed critical control has more impact on the score than a failed low-severity control. The score is calculated per standard (CIS, FSBP, PCI DSS, NIST) and as an aggregate across all enabled standards. Suppressed and disabled controls are excluded from the calculation.

What is AWS security posture management?

Cloud Security Posture Management (CSPM) is the practice of continuously monitoring and improving the security configuration of your cloud environment. In AWS, CSPM involves deploying Config rules and Security Hub standards to evaluate resource configurations, using IAM Access Analyzer to identify overly permissive access, running GuardDuty for threat detection, and tracking compliance against regulatory frameworks. CSPM is proactive — it identifies misconfigurations and policy violations before they are exploited.

How do I monitor AWS service quotas?

Use the Service Quotas API to programmatically query your current quotas and utilization for each service. Deploy a scheduled Lambda function that checks utilization against quota values and alerts when utilization exceeds a defined threshold (80% is a common trigger). Alternatively, enable Trusted Advisor's service limits checks for coverage of the most common quotas. Integrate quota monitoring into your account health dashboard for unified operational visibility.

What compliance frameworks can I monitor with AWS native tools?

AWS Config conformance packs and Security Hub security standards support CIS AWS Foundations Benchmark, AWS Foundational Security Best Practices, PCI DSS, NIST 800-53, HIPAA eligibility (through the HIPAA conformance pack), and SOC 2 (through mapped Config rules). Custom conformance packs can be built to map additional frameworks to AWS Config rules. Security Hub also supports custom security standards for organization-specific compliance requirements.