Evaluating AWS Resource Compliance: Config, Security Hub, Audit Manager

AWS Config evaluates only what it has recorded, so every compliance result depends on two plumbing pieces. The configuration recorder watches supported resource types (all types, or a selected list) in one account and Region and produces a configuration item — a point-in-time JSON snapshot of a resource's state — when that state changes. The delivery channel delivers configuration history files and periodic snapshots to an S3 bucket and can publish notifications to an SNS topic.

Know the current recorder model precisely:

• Customer managed recorder: the one you create. You get one per account per Region, and it cannot be started until a delivery channel exists.
• Service-linked recorders: created and managed by another AWS service for its own needs (Security Hub CSPM creates one in a specific setup, covered below). They sit alongside your customer managed recorder.
• Recording frequency: continuous records every change as it happens; daily records at most one configuration item per resource per 24 hours, delivered at the end of the period only if the state changed. Daily recording is cheaper, but it delays every change-triggered evaluation by up to a day.

Keep three stages apart when diagnosing: recording (configuration items exist), evaluation (rules produce results from them) and delivery (history and snapshot files reach S3). A broken delivery channel bucket policy breaks delivery to S3; it is not the reason a rule shows no results when the recorder is running.

Know what breaks when the recorder is stopped: no new configuration items are produced, so change-triggered rules stop evaluating and the resource timeline develops a gap you can never backfill. Periodic rules keep running on their schedule, which is why a half-broken Config setup can look alive. If one resource type's rules go silent while others work, a selective recorder that omits that type is the usual cause.

Rule types.

Every detective rule has a trigger: configuration change (fires when a matching resource's configuration item changes) or periodic (fires every 1, 3, 6, 12 or 24 hours regardless of changes). Encryption and network-exposure checks suit change triggers. Time-based conditions — key age, credential age — change while the resource does not, so they need a periodic rule: a managed rule that already runs periodically, or a Lambda rule. A Guard custom policy rule cannot do this because its detective evaluation is change-triggered only.

Detective vs proactive evaluation. Detective evaluation checks resources that already exist. Proactive evaluation, turned on per rule for rules that support it (many managed rules and Guard custom policy rules), checks a resource's planned properties before deployment: a pipeline calls StartResourceEvaluation with the proposed configuration and reads the result with GetResourceEvaluationSummary. Proactive evaluation only reports — it neither blocks the deployment nor remediates — so the pipeline must fail its own stage on a NON_COMPLIANT result. StartConfigRulesEvaluation and periodic triggers re-evaluate deployed resources only.

Config closes the detection loop through a remediation configuration: an association between one Config rule and a Systems Manager Automation runbook that fixes the noncompliant resource. Automation documents are the only remediation target. Lambda functions, CloudFormation stacks and Step Functions state machines cannot be attached directly; a runbook step (aws:invokeLambdaFunction) can call a Lambda function when the fix needs custom code. AWS ships purpose-built runbooks — the AWSConfigRemediation-* family plus documents such as AWS-DisablePublicAccessForSecurityGroup — and you can author your own.

The mechanics:

• AutomationAssumeRole: the runbook runs under an IAM role you pass as a parameter. Its trust policy must allow Systems Manager to assume it, and its permissions policy must allow every action the runbook's steps perform.
• Automatic vs manual: automatic remediation starts as soon as the rule marks a resource NON_COMPLIANT; manual remediation runs only when someone chooses Remediate. A remediation that works when run by hand but never runs on its own is set to manual.
• Retries: for automatic remediation you set a number of attempts within a time window (for example, 5 retries in 300 seconds). Retries happen only after a failed execution. If the resource fails that many times within the window, Config adds a remediation exception for it and stops auto-remediating it until the exception is removed.
• Approval: for changes too risky to fully automate, a runbook can include an aws:approve step that pauses until a designated approver signs off.
• Service-linked rules cannot carry remediation: you can manage remediation only for rules you own. Rules created by another service — such as the securityhub- prefixed rules behind Security Hub CSPM controls — show Manage remediation as unavailable. To auto-remediate the condition through Config, add the same managed rule as your own customer managed rule and attach the remediation to it.

Some noncompliance cannot be fixed in place. An existing unencrypted RDS instance cannot be encrypted where it stands, so the right response is a notification and a tracked ticket to rebuild from an encrypted snapshot copy, not a runbook. Deciding between auto-fix and notify-and-track is part of the task.

AWS Config sends a notification-ready event every time a rule's evaluation of a resource changes: an Amazon EventBridge event with source aws.config and detail type Config Rules Compliance Change, whose detail carries the rule name, the resource and the new compliance type (for example NON_COMPLIANT). An EventBridge rule that matches it and targets an SNS topic delivers email or chat alerts with no code; other targets open tickets or start workflows.

Scope is the part that is easy to get wrong:

• The event lands on the default event bus of the account and Region where the rule evaluated.
• A Config aggregator emits no events. It copies configuration and compliance data into a read-only view; it does not re-publish anything to the aggregator account's bus.
• So organization-wide alerting needs an EventBridge rule in every account and Region that forwards matching events to a central event bus in the security account (whose resource policy allows the organization to put events), where one rule targets SNS. Deploying those forwarding rules with a service-managed StackSet keeps new accounts covered.

Security Hub CSPM has its own notification path: its findings reach EventBridge as Security Hub findings events, and the same forwarding pattern applies. Its automation rules are not a notification mechanism — they only update finding fields (severity, workflow status, notes) as findings arrive.

Conformance packs give every account the same rules; aggregators give one place to see the results. Neither crosses Regions on its own, and neither substitutes for the other.

A conformance pack packages a set of Config rules — and optionally their remediation configurations — into one YAML template that is deployed and tracked as a unit. AWS publishes sample packs mapped to frameworks (Operational Best Practices for PCI DSS, HIPAA Security, NIST 800-53, CIS and others), and you can write custom packs. Each pack reports a compliance score: compliant rule-resource combinations divided by all evaluated rule-resource combinations.

An organization conformance pack, deployed from the management account or a Config delegated administrator, lands in every member account, and in accounts that join later. Three details decide whether it actually deploys:

• Each member needs a running configuration recorder in that Region. For an account that joins the organization later, Config retries deployment for only 7 hours; if no recorder exists by then, that account's status ends as failed. Baseline the recorder into new accounts first (for example with a StackSet).
• The deployment API is Region-specific: deploy the pack again in every Region that must be covered.
• If you use a delegated administrator, Config does not create its service-linked role in the management account automatically. Create it manually in IAM, or the delegated administrator cannot deploy to the management account.

An aggregator collects configuration and compliance data from multiple source accounts and Regions into one read-only view in one account, queryable with advanced queries. An organization aggregator includes every account automatically, including new ones. An individual-accounts aggregator requires each source account to authorize the aggregator account and Region; an unauthorized source simply does not appear. An aggregator evaluates nothing: it shows results that rules in the source accounts already produced. A new account or Region therefore needs its own rules or pack (or an organization pack deployed in that Region) before anything shows up for it.

Security Hub's standards and controls now live in AWS Security Hub CSPM. In 2025 AWS split the service: the original one, renamed Security Hub CSPM, keeps the ASFF findings, security standards, controls, security scores, delegated administration, central configuration and cross-Region aggregation; the new AWS Security Hub correlates findings in OCSF format. Compliance scoring against a standard is a Security Hub CSPM job.

Enabling a standard — AWS Foundational Security Best Practices (FSBP), CIS AWS Foundations Benchmark, PCI DSS, NIST 800-53 — turns on its controls. Each control produces findings with a compliance status of PASSED, FAILED, WARNING (cannot determine, for example because recording is off) or NOT_AVAILABLE, and Security Hub CSPM derives a control status (Passed, Failed, Unknown, No data) from them.

The AWS Config dependency. Most controls run as service-linked Config rules named securityhub-<rule>-<id>, which Security Hub CSPM creates and manages. What feeds them depends on the setup:

• Security Hub CSPM without the new Security Hub: you must run your customer managed recorder in every account and Region where it is enabled, recording every resource type that an enabled control checks. Global resources (such as IAM) need recording in one Region only, ideally the aggregation home Region. AWS::Config::ResourceCompliance does not need to be recorded, and turning it off saves cost. If a checked type is not recorded, the control gets WARNING findings (control status Unknown) and Config.1 fails. Daily recording delays change-triggered control findings by up to 24 hours.
• Both Security Hub CSPM and the new Security Hub enabled: Security Hub CSPM creates its own service-linked recorder, AWSConfigurationRecorderForSecurityHubCSPM, in each account and Region, records what its controls need and stops using your customer managed recorder; Config.1 then always passes. In that setup, stopping your own recorder no longer degrades the scores.

Exceptions and suppression. Control status ignores findings that are archived or have workflow status SUPPRESSED. Setting one resource's findings to SUPPRESSED — by hand or with an automation rule matching that resource — records an accepted exception while the control keeps checking every other resource. Setting a finding to RESOLVED, or lowering its severity, does not remove it from the calculation. Disabling the control would stop checking everything.

Across the organization, a delegated administrator uses central configuration policies to enable standards and controls across accounts, OUs and Regions, and cross-Region aggregation shows every member's control status in one home Region. That is detection and scoring. It is not evidence organized by framework control for an assessor — that is the next section.

Audit evidence comes in three kinds, and each has its own source:

The Config timeline links each change to related CloudTrail events, but the caller identity and source IP come from CloudTrail itself.

AWS Audit Manager turns technical results into audit evidence. An assessment built from a prebuilt or custom framework (PCI DSS, HIPAA, SOC 2 and others) automatically collects evidence for each control from four sources — Config rule results, Security Hub CSPM control findings, CloudTrail activity and API-call snapshots — into daily evidence folders, and exports an assessment report. Config and Security Hub CSPM detect; Audit Manager organizes the proof by control. Neither replaces the other.

Audit Manager is in maintenance mode. Since 30 April 2026 it cannot be set up in new accounts. Existing customers keep using it, including creating new assessments, with these limits:

• A single-account customer can keep using that account in that Region, but cannot add Regions or accounts, or deploy it to an organization.
• An organization customer (set up in the management account) can add the organization's member accounts to assessments, but cannot extend to new Regions.

AWS points new users to Config conformance packs, deployed in each account and Region that must be checked. They track resource compliance over time with configuration items as evidence, but they are not a full replacement: there are no templates for frameworks such as SOC 2 or GDPR, packs cover only the technical controls that a Config rule can test, and there is no export equivalent to the Audit Manager assessment report.

AWS Artifact covers AWS's side of the shared responsibility model. Artifact Reports are on-demand downloads of AWS's own SOC 1/2/3 reports, PCI attestations and ISO certifications — proof of the security of the cloud that your own tooling cannot produce. Artifact Agreements manage agreements such as the HIPAA Business Associate Addendum (BAA):

• An account agreement covers only the account that accepts it.
• An organization agreement is accepted from the management account of an organization with all features enabled, and covers every existing and future member account.

The AWS Well-Architected Tool evaluates a workload's design and practices against AWS best practices — the part of security posture that no resource scan can observe, such as identity processes, incident-response readiness and data classification. Config, Security Hub CSPM and Trusted Advisor check resource settings; the Well-Architected Tool reviews how the workload is built and run.

How a review works:

• You define a workload and answer the questions of one or more lenses. The Well-Architected Framework lens includes the Security Pillar; the Lens Catalog adds AWS-authored lenses for specific domains.
• Each answer is compared with the question's best practices. The tool flags high-risk and medium-risk issues and builds an improvement plan: a prioritized list of the missing best practices with guidance.
• Milestones save a point-in-time record of the workload's answers and risks. Saving one after the first review and another after remediation shows how risks changed.

Features that are easy to confuse:

Sharing. A workload can be shared with accounts, IAM users, the organization or OUs, in the same Region only. Read-Only permission lets the recipient view the workload; Contributor also lets them update answers and notes. Custom lenses are shared the same way.

Recurring access reviews (IAM Access Analyzer unused-access findings, credential reports, last-accessed data) are taught with the Domain 4 authorization lesson, and tag standards (tag policies, the required-tags rule) with the Task 6.2 deployment lesson.

Task 6.3 comes together as one pipeline: framework requirement → detective control → remediation or ticket → notification → evidence. Walk it with a PCI-style requirement: "restrict inbound traffic to the cardholder data environment to only necessary ports."

Step 1 — detective control. Make sure every account and Region in scope runs a configuration recorder, then deploy the Operational Best Practices for PCI DSS conformance pack as an organization pack in each Region used, or at minimum enable restricted-ssh and restricted-common-ports in the cardholder accounts. These rules are change-triggered, so evaluation follows each security group change. A pipeline can also run proactive evaluation on planned security groups before they are deployed.

Step 2 — response and notification. Attach a remediation configuration that binds the rule to AWS-DisablePublicAccessForSecurityGroup, set to automatic, under an AutomationAssumeRole allowed to revoke ingress. Forward Config Rules Compliance Change events from each account and Region to a central bus that notifies the security team and opens tickets for findings that cannot be auto-fixed. The PCI DSS standard in Security Hub CSPM scores the same posture per control.

Step 3 — evidence. An organization that is an existing Audit Manager customer runs a PCI DSS assessment, which files Config results, Security Hub CSPM findings and CloudTrail activity into evidence folders per control. Without Audit Manager, the conformance pack's compliance timeline and configuration items, plus CloudTrail logs, supply the technical evidence. AWS's own PCI attestation comes from AWS Artifact.

Step 4 — architecture. A Well-Architected Tool review against the Security Pillar covers the practices that rules cannot test, with milestones recording progress through the improvement plan.

This is the difference between a point-in-time audit (gather screenshots when asked) and a continuous compliance program: the evidence exists before anyone asks.

Each failure has a short diagnostic list.

Rules aren't evaluating. Check the recorder first: missing, stopped, without a delivery channel (a customer managed recorder cannot start without one), or not recording the resource type in question. Daily recording explains results that arrive up to a day late. Then check the rule's scope (a rule limited to a tag or resource ID ignores everything else). For Lambda-backed rules, confirm the function's resource policy lets Config invoke it, and read the function's logs: a crashing evaluator looks like a rule that never ran.

Auto-remediation isn't running. The remediation is set to manual; no remediation is attached to the rule; or the rule is service-linked, so remediation cannot be managed on it at all.

Auto-remediation always fails. Run describe-remediation-execution-status (or open the execution in Systems Manager) to see each step's state and error. Read the error closely: an access-denied that names the assumed-role session of the AutomationAssumeRole proves Systems Manager assumed the role, so the trust policy is fine and the role's permissions policy lacks the action. An error saying the role cannot be assumed points at the trust policy or the role ARN instead. Retries help only with transient failures; once the attempts in the window fail, Config records a remediation exception for the resource and stops auto-remediating it until the exception is removed.

The aggregator is missing accounts. In individual-accounts mode, the source account has not authorized the aggregator account and Region. In organization mode, check trusted access and the aggregator's role. In either mode, confirm the source account actually runs Config in that Region — an aggregator shows only what the sources produce.

An organization conformance pack fails in some members. Usually those accounts had no running recorder in that Region, often new accounts that passed the 7-hour retry window. If the management account fails while a delegated administrator deploys, the Config service-linked role is missing there. Custom Lambda rules in the pack must reference functions that each account can invoke.

Security Hub CSPM controls show WARNING or Config.1 fails. A resource type that an enabled control checks is not being recorded in that account and Region (global resources must be recorded in at least one Region).