AWS Config, AWS Security Hub, and AWS Audit Manager can all appear in a cloud-governance architecture, but they answer different questions. Config records how AWS resources are configured and can evaluate those resources against rules. Security Hub brings security findings and exposure context into a security-operations workflow, while the closely related Security Hub CSPM service evaluates security posture against controls and standards. Audit Manager automates the collection and organization of evidence for audits and assessments. Treating those capabilities as interchangeable is one of the fastest ways to build a compliance process with the wrong source of truth.<\/p>\n
The distinction matters in AWS Certified Security – Specialty SCS-C03<\/a> because current objectives include governance, compliance evaluation, security findings, logging, and evidence. A strong architecture often uses more than one of these services, but each should have a defined role: resource state, security posture and findings, or audit evidence.<\/p>\n AWS Config records configuration information for supported resources, including relationships and historical changes. If a security engineer needs to know when an S3 bucket’s public-access settings changed, whether an EC2 security group allowed a risky port, or how a resource was configured at an earlier point in time, Config provides the resource-centric record needed for that investigation.<\/p>\n Config Rules add evaluation. A managed or custom rule can test whether a resource complies with a defined condition, and conformance packs can group rules and remediation actions into a broader governance package. Config can therefore answer both a descriptive question\u2014what configuration exists\u2014and a policy question\u2014does that configuration satisfy this rule?<\/p>\n That makes Config especially useful when compliance depends on concrete AWS resource settings. It is not a SIEM and it is not an audit-report writer. Its core value is configuration history, relationships, rule evaluation, and optional remediation around AWS resources.<\/p>\n Current AWS documentation distinguishes AWS Security Hub from AWS Security Hub CSPM. Security Hub focuses on correlating, prioritizing, and responding to security exposures and findings across the environment. Security Hub CSPM focuses on cloud security posture management: evaluating resources against security controls and standards and producing findings when controls fail. AWS describes the services as complementary and recommends using both when the organization needs both posture assessment and exposure-response workflows.<\/p>\n This distinction is important because older explanations often used \u201cSecurity Hub\u201d as a single label for both activities. In a current architecture, the posture and compliance side belongs specifically to Security Hub CSPM. Many of its controls depend on AWS Config resource recording, so the service can evaluate resource configuration and turn failed controls into standardized security findings.<\/p>\n Security Hub then becomes valuable when those findings need to be aggregated with other security signals, prioritized, correlated, and connected to response. The difference is subtle but operationally meaningful: Config supplies resource state, CSPM evaluates many security controls over that state, and Security Hub helps security teams work with the resulting exposure picture.<\/p>\n AWS Audit Manager is built for assessment and evidence workflows. It can continuously collect evidence from AWS data sources, map that evidence to controls in a framework, organize it inside an assessment, and help teams prepare audit-ready reports. Its users are often security governance, risk, compliance, and audit teams rather than the engineers responding to an active threat.<\/p>\n An auditor may need proof that a control operated during a defined period, not merely a statement that a resource is compliant right now. Audit Manager is designed around that need. Evidence can be reviewed, delegated, assessed, and retained as part of an audit process. Frameworks can represent a regulatory standard, an industry benchmark, or an organization’s own control structure.<\/p>\n Audit Manager does not replace the systems that generate the evidence. It can collect evidence from services such as Config, CloudTrail, Security Hub CSPM, and other AWS sources, but it does not become the primary enforcement engine for those controls. Think of it as the evidence and assessment layer, not as the service that fixes a noncompliant security group.<\/p>\n A Config rule can evaluate a narrow resource condition, such as whether encryption is enabled or whether a security group permits a prohibited port. Security Hub CSPM standards group many controls into a security-posture view and normalize failed controls into findings that can be prioritized with other security issues. Both can involve compliance language, but the audience and workflow differ.<\/p>\n Config is strongest when infrastructure teams need direct configuration history, rule results, and remediation. Security Hub CSPM is stronger when the security program needs an opinionated set of security controls and standards across accounts and Regions. Security Hub adds the broader exposure and findings workflow. Audit Manager sits later in the chain when evidence must be organized for review against a framework.<\/p>\n An overview of AWS security services<\/a> helps show why no single control covers prevention, detection, posture, response, and assurance. AWS Config, Security Hub, and Audit Manager can exchange or reuse evidence, but their responsibilities remain distinct and should be designed around the question each service is meant to answer.<\/p>\n Imagine that an organization requires encryption on selected storage resources. Config records each resource and its configuration changes. A Config rule can evaluate the encryption requirement and, where appropriate, invoke remediation. Security Hub CSPM can include a related control in a security standard and create a finding when the control fails. Security Hub can help prioritize that failure alongside other exposures. Audit Manager can collect evidence showing the control’s status during an assessment period.<\/p>\n Each step preserves a different kind of truth. Config says what the resource configuration was and whether a rule considered it compliant. Security Hub CSPM says whether a security control passed and represents the failure as a security finding. Audit Manager says which evidence has been collected and reviewed for an assessment control. Combining them is powerful because the interfaces are aligned to different operational jobs.<\/p>\n The same architecture also supports separation of duties. Platform teams can own Config rules and remediation. Security operations can own findings and exposure response. GRC teams can own frameworks, assessments, and evidence reviews. The organization does not need every team to work inside the same console or interpret the same object as proof of every requirement.<\/p>\n Config is the natural starting point when a scenario says \u201crecord,\u201d \u201ctrack changes,\u201d \u201cevaluate resource configuration,\u201d \u201cidentify when a resource became noncompliant,\u201d or \u201cremediate a configuration.\u201d Its timeline and configuration-item model are designed for those questions. Aggregators can centralize results across multiple accounts and Regions, which is important in large AWS Organizations environments.<\/p>\n Config also matters because other security services depend on resource recording. If Security Hub CSPM needs a Config-backed control but the relevant resource type is not recorded, posture evaluation can become incomplete. That makes Config part of the plumbing of a broader compliance architecture, not merely a standalone reporting tool.<\/p>\n Do not stretch Config into a general incident-response platform. It can reveal a dangerous configuration and trigger remediation, but authentication events, malware detections, application logs, and third-party findings belong in other detection and response systems.<\/p>\n If the requirement is to evaluate security best practices at scale, Security Hub CSPM is the relevant posture-management layer. If the requirement is to correlate and prioritize security exposures and findings and route them into response workflows, Security Hub is the broader security-operations layer. Current AWS terminology makes it worth naming which part of the family a design actually depends on.<\/p>\n Findings are operational security objects, not audit reports. They can contain severity, resource information, control status, provider details, and workflow state. They can be sent through EventBridge or integrated with ticketing, automation, and partner products. This supports security teams that need to work a queue of exposures rather than read raw Config history.<\/p>\nAWS Config answers what a resource is and how it changed<\/h2>\n
Security Hub now has a distinct relationship with Security Hub CSPM<\/h2>\n
Audit Manager answers whether the audit has evidence<\/h2>\n
Configuration compliance and security posture are related but not identical<\/h2>\n
A mature design lets the services feed one another<\/h2>\n
Choose Config when the requirement is resource-state governance<\/h2>\n
Choose Security Hub and CSPM when the requirement is security prioritization<\/h2>\n