AWS Config vs Audit Manager

The situation

A platform team supports a compliance programme against three frameworks at once:

• PCI DSS 3.2.1, required by the payments product; annual external audit.
• SOC 2 Type II, sold to enterprise customers; bi-annual assessor review.
• Internal control set, an ops baseline that sits on top of the regulatory frameworks.

Existing posture:

• AWS Config enabled in every account via Organization-level aggregator, ~200 managed rules across a dozen categories (encryption, network exposure, IAM, logging).
• Conformance packs deployed: Operational-Best-Practices-for-PCI-DSS, Operational-Best-Practices-for-AWS-Well-Architected-Reliability, and a custom pack for the internal baseline.
• A quarterly report assembled by hand: screenshots of Config dashboards, copy-pasted rule names, auditor-readable PDFs that take a week to build.

The asks from the compliance officer:

• An auditor-ready report keyed to the framework’s control numbers, not Config rule names.
• Evidence attached to each control, the actual data that proves “bucket encryption on” was true on a given date.
• Assessor workflow: a control is reviewed, annotated, and marked sign-off by the named assessor before the report is generated.
• No duplication with Config’s existing rules, whatever produces the report should read Config’s state, not re-scan the same resources.
• Framework coverage that includes PCI DSS 3.2.1, SOC 2, HIPAA, and at least one cloud-specific baseline (CIS AWS Foundations, AWS Well-Architected).

What actually matters

There are two questions in the brief that sound similar on a first read and want different answers.

The first is “is this resource in the desired state right now?”, a per-resource, per-rule verdict that updates on configuration change or schedule. A live compliance dashboard answers it, with results categorised as compliant, non-compliant, not-applicable, or insufficient-data. The measurement is continuous, the audience is the on-call engineer who needs to fix a regression today. This is the measurement layer.

The second is “prepare me an audit artefact for this framework on this date”, a time-windowed, control-keyed, assessor-reviewed package with sign-off recorded and evidence attached per control. The output is a document, not a console view; the audience is the external auditor; the timeline is retrospective by design. This is the reporting and assessor-workflow layer.

The two layers overlap on the evidence itself. A rule that already evaluates “bucket encryption on” is exactly what the audit report wants to attach to a control like PCI DSS 3.4 “Render PAN unreadable.” There’s no reason to re-scan the bucket for the auditor’s sake; the rule’s verdict, timestamped and pinned to a window, is the evidence. A correct architecture has the measurement layer producing per-resource verdicts continuously, and the reporting layer attaching those verdicts to framework controls without duplicating the scan.

The non-overlap is what makes both layers necessary. The measurement layer has no concept of an assessor, no framework-to-control mapping that produces a signed artefact, no report generation, no narrative, no scoping by time window. The reporting layer has no concept of live compliance state, it’s retrospective by design. Trying to replace a live dashboard with a report-generation tool gives a slow dashboard; trying to replace a report-generation tool with screenshots of a live dashboard gives a week of copy-paste every quarter.

What we’ll filter on

Ranking the options against:

1. Produces a framework-keyed report. PCI DSS control 3.4, not s3-bucket-server-side-encryption-enabled.
2. Attaches evidence to each control, the underlying API call or Config evaluation is preserved in the output.
3. Assessor workflow, review, annotate, sign-off per control.
4. Live compliance state, “show me everything that is non-compliant right now” is queryable.
5. Framework coverage, pre-built frameworks for PCI DSS, SOC 2, HIPAA, CIS, Well-Architected.

The compliance-reporting landscape

1. AWS Config conformance pack alone. Deploys a set of rules tied to a named baseline (Operational-Best-Practices-for-PCI-DSS). Dashboards show compliance percentages per rule and per resource. No report artefact, no assessor workflow, no framework-control mapping beyond the rule names. Fails the report requirement.

2. AWS Audit Manager alone. Runs an assessment against a framework; evidence collection reaches out to Config, CloudTrail, and direct API calls. Produces the report. Without Config already populated, the evidence surface is thin; Audit Manager pulls some evidence on its own (CloudTrail queries, Snapshot-based evidence), but many controls expect Config rule results.

3. Config (conformance packs) + Audit Manager (assessments). The intended pairing. Config populates the live compliance state and conformance packs keep the rule set current; Audit Manager assessments point at the Config rules as evidence sources, add assessor workflow, and generate the framework-keyed report.

4. Security Hub consolidated findings + manual report. Security Hub aggregates findings from Config, GuardDuty, Inspector, and third parties. Its CIS AWS Foundations standard is similar in shape to a Config conformance pack. No framework mapping to PCI, SOC 2, or HIPAA controls; no assessor workflow. Useful for the live security posture view; doesn’t produce the audit artefact.

5. Third-party GRC platforms (Vanta, Drata, Secureframe). Integrate with AWS, collect evidence, produce auditor-ready reports. Mature assessor workflows; licence cost; often appropriate for organisations with multi-cloud compliance programmes. Out of scope when “AWS-native” is a constraint; frequently present alongside Audit Manager in practice.

Side by side

Option	Framework report	Evidence per control	Assessor workflow	Live state	Framework coverage
Config conformance pack	✗	Partial (rule state)	✗	✓	Best practices packs
Audit Manager alone	✓	Thin without Config	✓	✗	PCI, SOC 2, HIPAA, GDPR, CIS, WA
Config + Audit Manager	✓	✓	✓	✓	Combined
Security Hub + manual	Partial	Partial	✗	✓	CIS primarily
Third-party GRC	✓	✓	✓	—	Wide, varies

The pairing is the answer. Config is the measurement layer; Audit Manager is the report layer. They compose, and each one alone leaves a hole the other fills.

Where evidence comes from and where reports go

The pick in depth

Config: keep conformance packs, tighten the Organization aggregator. The conformance packs the team already runs cover most of what the frameworks ask. A domain decision: the Organization-level aggregator (configured in the management account or a delegated administrator) collects rule results from every member account in one place, and Audit Manager reads from that aggregator. Without aggregation, Audit Manager has to assess each account individually and the report becomes a pile of per-account PDFs rather than one consolidated framework report.

Custom Config rules fill the gaps. Where a framework control has no corresponding managed rule, a Lambda-backed custom rule (or a Guard rule using CFN Guard) evaluates the specific condition. The cost of writing a custom rule is low; the benefit is that Audit Manager can attach its result to the control directly, rather than the control remaining “manual evidence required.”

Audit Manager: pre-built frameworks plus a custom framework for the internal baseline. PCI DSS 3.2.1, SOC 2, HIPAA, CIS AWS Foundations, NIST, and AWS Well-Architected ship as pre-built frameworks; each one is a list of controls with default data sources. The team uses them as-is for the external frameworks and copies the structure for the internal baseline, creating a custom framework that lists each internal control with its data source (usually a Config rule).

An assessment scopes a framework to accounts and a time window. For the quarterly PCI audit: assessment named PCI-2028-Q1, scope [payments-prod, payments-staging, tooling, audit], window 2028-01-01 to 2028-03-31. Audit Manager starts collecting evidence immediately, every time a referenced Config rule evaluates during the window, the result lands in the assessment’s evidence folder for the relevant control. By March 31st there’s a substantial body of evidence per control: rule evaluations keyed by resource and date, CloudTrail events matching the control’s API-call data sources, any manual evidence uploaded by the team.

Assessor workflow. Each control has an owner (configured at framework creation) and an assessor. The owner reviews the auto-collected evidence; the assessor reviews the owner’s attestation and signs off. Controls can be delegated, the networking team owns “VPC flow logs enabled for all subnets” and gets the evidence in their queue automatically. Status transitions are logged; the report captures them as part of the audit trail.

Report generation. On assessment close, Audit Manager generates a PDF report keyed to the framework’s controls, with evidence excerpts attached per control and the assessor’s sign-off recorded. The underlying evidence files land in S3 alongside the report; with S3 Object Lock in compliance mode on that bucket, the evidence becomes immutable for the retention period the auditor requires. The report itself is the artefact handed to the external auditor.

A worked PCI DSS 3.4 evidence trail

Control: “Render PAN unreadable anywhere it is stored (for example, strong cryptography, hashing, truncation, index tokens and pads).”

Data sources Audit Manager attaches by default:

• Config rule: s3-bucket-server-side-encryption-enabled
• Config rule: rds-storage-encrypted
• Config rule: dynamodb-table-encryption-enabled
• Config rule: ebs-encryption-by-default
• Config rule: elasticsearch-encrypted-at-rest

The team adds one custom Config rule: redshift-cluster-kms-enabled for the analytics estate. Three-month assessment window. Every time one of those rules evaluates, daily change-triggered or configuration-change-triggered. Audit Manager records the result keyed to resource, account, and timestamp, and attaches it to the control.

At assessment close: ~90 days of evaluations × ~40 resources averaging ~2 rules each = thousands of evidence records for this one control. The report’s PDF page for 3.4 lists the controls, summarises coverage (“all 47 S3 buckets across 4 in-scope accounts were COMPLIANT with s3-bucket-server-side-encryption-enabled for 100% of the assessment window”), and links to the raw evidence in S3. The assessor signs the page; the external auditor has what they need.

If a single bucket falls out of compliance for 4 hours during the window, the evidence shows that gap explicitly. Audit Manager does not hide non-compliance; it surfaces it for the assessor to annotate. That annotation, “non-compliance detected at 2028-02-14T03:12Z on bucket stale-backup-archive; remediated at 03:17Z by AWS Config auto-remediation action; tracked in JIRA PCI-4432”, becomes part of the report, and the auditor sees the incident and the response. The goal is not a clean dashboard; it is an honest narrative the auditor can verify.

Audit Manager’s own data sources beyond Config

Controls that don’t map cleanly to Config rules use other sources:

• CloudTrail event queries. “CreateUser events during the assessment window” attaches every CreateUser CloudTrail event as evidence for an identity-management control.
• AWS API snapshots. A daily snapshot of DescribeTrustedAdvisorCheckResult or GetAccountAuthorizationDetails provides point-in-time evidence for controls that don’t map to a single resource.
• Manual evidence. A PDF of the team’s password policy, the runbook for incident response, or a screenshot of the third-party dependency-scanning tool’s report, uploaded by the control owner and attached to the control.

The last category is the honest admission that not every framework control maps to an AWS API call. Manual evidence is uploaded once, referenced from as many controls as apply, and versioned alongside the automated evidence. The report doesn’t hide that a control was satisfied by manual evidence; the assessor’s sign-off vouches for it.

What’s worth remembering

1. Config measures; Audit Manager reports. Config is the live compliance state per resource per rule. Audit Manager is the time-windowed, framework-keyed, assessor-reviewed, report-generating layer.
2. Audit Manager reads Config as an evidence source. No duplication; the same rule evaluation feeds the live Config dashboard and the assessment’s evidence folder. Remove Config and Audit Manager’s evidence surface collapses.
3. Pre-built frameworks cover the common cases. PCI DSS 3.2.1, SOC 2, HIPAA, GDPR, NIST 800-53, CIS AWS Foundations, AWS Well-Architected. Copy and edit for internal baselines.
4. Organization aggregator is the input plumbing. Without aggregation, Audit Manager assesses per account; with aggregation, one assessment spans the in-scope accounts and the report is one document.
5. Assessor workflow includes delegation. Controls can be assigned to specific owners and assessors in different accounts; evidence lands in the right person’s queue and sign-off is tracked in the assessment’s audit trail.
6. Non-compliance is evidence too. Audit Manager surfaces gaps rather than hiding them; the assessor annotates, the report documents, the auditor sees the response.
7. Evidence archive belongs in S3 Object Lock. Compliance-mode retention makes the evidence immutable for the retention period the auditor requires; the report PDF alone is not enough.
8. Security Hub and Audit Manager answer different questions. Security Hub is real-time security posture with threat findings; Audit Manager is audit-ready evidence for a framework. The two often coexist and feed different audiences.

Config conformance packs alone produce a dashboard; the auditor will not accept a dashboard. Audit Manager alone without Config produces a thin report with most controls marked “manual evidence required.” The combination. Config measuring, Audit Manager reporting, produces the artefact the auditor signs. The same rule is visible from both sides; the difference is what gets generated on the other side.