Difference between AWS Config and Security Hub: The Boundary Problem
Because AWS Config and Security Hub are often mentioned together, many miss the difference between the two. This is due to the similarity of both surfacing findings that leads to confusion between their roles. Compounded to this is that there is often an unclear boundary between configuration and governance.
Failing to establish a clear boundary between these services will lead to misrouted alerts and duplicated controls. It will also weaken governance when scaling out to a multiple-account environment. There is also the risk of mistaking findings for enforcement signals.
The critical differentiator between these two services is the distinction between findings and governance signals. This is further explained by considering evaluation output in contrast to governance intent. Another perspective is weighing the benefits of signal quality over signal quantity.
By considering these differentiators, we map AWS Config to providing findings, and we will examine where AWS Config’s responsibility ends. Accordingly, we will map AWS Security Hub to governance and investigate where that begins.
What AWS Config Actually Does
AWS Config’s key difference from Security Hub is that it continuously tracks resource state configuration. Accordingly, it maintains the configuration change history for all the resources across AWS accounts and regions. Critically, it continually evaluates these resources against defined baselines, providing the current state of the AWS environment configuration. The visibility of the AWS environment state is independent and orthogonal to the threat context reported by other services.
Another key difference between AWS Config and Security Hub is that AWS Config performs rule-based compliance evaluation. These compliance results are deterministic, unlike other Security Hub sources that are non-deterministic by nature. The other key difference is that they are structured evaluations and not alarms or alerts. Finally, they reflect adherence to policy and do not carry any severity context.
For a deeper look at how these evaluations are implemented in practice, see AWS Config rules for compliance monitoring and governance.
A further distinction from Security Hub is that AWS Config provides findings primarily intended for downstream processing and consumption. Therefore, it never performs any native aggregation or correlation of its findings but simply reports them. Additionally, it does not prioritize or score findings according to risk. This is because its output is regarded as input into governance services.
Another key boundary of AWS Config, making it distinct from Security Hub, is that it does not correlate its findings with other AWS services. Additionally, it does not provide a centralized security view but only evaluates the system state. While a key source of governance signals, it does not perform governance or enforcement orchestration.
What Security Hub Actually Does
Security Hub’s key difference from other services, including AWS Config, is that it aggregates findings from these multiple AWS services. The other key value that it adds to the workflow is normalizing all its inputs into a common finding format. Additionally, it provides platform teams with centralized visibility across accounts and regions that individual services rarely provide. Alongside AWS services, it can also consume third-party and partner findings.
However, the Security Hub’s most fundamental distinction is that it does not detect findings but contextualizes them. Therefore, it does not have any threat detection logic or provide any independent findings generation. It primarily places its reliance on upstream services for findings, basing security workflows on a modular systems approach. Its main job is to contextualize these findings through standards and controls.
Specifically, what makes Security Hub different from AWS Config and other services is that it transforms their findings into governance signals. Furthermore, it maps these governance signals to compliance standards and controls. Subsequently, it presents a posture assessment across accounts and regions to platform management teams. From this, it also derives and presents a risk-oriented view of the security state.
Given Security Hub’s primary role is to contextualize findings, consequently, it never performs any configuration state evaluation. There are several other activities outside its scope include tracking of resources that are handled by other services. Neither does it perform any independent detection capability of the system state. Also outside its scope is configuration enforcement or performing remediation.
Where the Handoff Happens
Direction of Flow Between AWS Config and Security Hub
Understanding the direction of flow between AWS Config and Security Hub is needed to understand the differences between these two services. The flow is one-way from AWS Config to Security Hub, and no flow in the other direction. Critically, there is no feedback loop back into AWS Config evaluation, which entails that AWS Config executes its evaluation independently. Basically, Security Hub acts solely as a downstream consumer only and supports the pipeline model without any bi-directional integration.
What Crosses the Boundary Between AWS Config and Security Hub
Having established the signal flow, it is necessary to understand the artefacts that cross the boundary between AWS Config and Security Hub. These artefacts are transferred to Security Hub without any further evaluation. They include structured evaluation results that describe the compliance state of resources in a consistent format that Security Hub consumes. Next is the resource compliance state metadata, which provides additional descriptive context for the resource’s compliance state. Security Hub ingests these artifacts and normalizes them as governance-ready findings. Also, Security Hub receives the policy reference with these artifacts and subsequently enhances them with the policy context.
From Findings to Governance Signals
Security Hub converts AWS Config’s raw evaluation results into factual inputs, which is its primary difference. Additionally, these resource-level findings from AWS Config lack organizational context, which Security Hub subsequently adds. Furthermore, Security Hub converts these raw findings into governance-relevant signals for further downstream processing. Another critical enhancement that Security Hub performs is to map these signals to compliance standards and controls. Furthermore, alongside signal normalization, Security Hub normalizes its severity and performs prioritization based on its severity. Lastly, it aggregates compliance posture across accounts and regions.
Why the Separation Matters at Scale
Many organizations operate multiple AWS Accounts across multiple regions, making clear ownership between evaluation and governance imperative. This also ensures that noise is reduced since there is no duplication of signals from AWS Config and Security Hub. Furthermore, this modular approach supports scalability for multiple accounts as organizations increase their AWS footprint. Additionally, this separation enforces consistent policy interpretation across environments.
Why This Matters for Governance
The distinction between AWS Config and Security Hub is essential since governance depends upon clear responsibility. Therefore, this distinction delineates clear ownership between evaluation and governance. This established explicit responsibility boundaries across these services, focusing on their particular roles. Furthermore, this established separation of concerns is inherent in any modular architecture, which enables accountability. This prevents governance failures that are caused by blurred roles.
Another important characteristic of the security workflow is signal quality over signal quantity, where high-volume findings create operational noise. This is central to governance that requires curated and contextual signals in evaluating the environment’s security posture. Another governance tenet is the prioritization of signals over evaluating raw detection output. Hence, the focus of signal refinement is to enable superior decision-making.
Organization scale makes the AWS Config and Security Hub distinction critical due to the complexity of multiple accounts and multiple regions. Governance is around posture and not raw data, which central teams require when monitoring and remediating the security environment. Also, this distinction ensures that governance is consistent across environments since roles are not mixed from environment to environment. Additionally, any coordination or visibility gaps are amplified by scale whenever there are multiple accounts and multiple regions.
Security workflows are subject to the same architectural forces as any other complex system, where service abstraction can accelerate delivery but hide complexity. Poor service boundaries invariably lead to implicit coupling that undermines long-term governance. Additionally, enforcement of handoffs between services prevents architectural drift, making systems harder to maintain.
The other key architectural aspect to consider is that governance emerges from system design. Hence, having distinct roles across evaluation and governance layers ensures that a well-structured system emerges. Additionally, enforcing intentional handoffs will enable sustainable control free from technical debt.
Conclusion: Thinking in Signals, Not Services
In understanding the difference between AWS Config and Security Hub, it is necessary to regard these services as implementation details. It is the difference between the signals of these two services that is key, where Governance is driven by signal flow. It is vital to take the perspective of outcomes rather than comparing features and having clarity on responsibility over tool selection.
Properly delineating between evaluation and governance clearly separates the two services, ensuring separation of concerns. Additionally, enforcing one-way handoffs prevents tight coupling between the two services, a key system design tenet. Furthermore, explicit boundaries enable independent evolution of these services due to the changing security environment. Also, this separation supports scaling and control as AWS environments continue expanding.
It is important to summarize the key distinction between these services. This context summarizes AWS Config as evaluating the factual state of the AWS environment. In contrast, Security Hub is summarized as contextualizing organizational meaning from factual states. Finally, governance is considered to emerge from these interactions.
The underlying concept that binds these two functions is that signal flow shapes security outcomes. The other important principle is to prioritize architecture over service accumulation.
Difference between AWS Config and Security Hub: Further Reading
Best Practices for Security, Identity, & Compliance
Security Pillar – AWS Well-Architected Framework
AWS Certified Security Study Guide: Specialty (SCS-C02) Exam by Alexandre M. S. P. Moraes et. al.
Security Engineering: A Guide to Building Dependable Distributed Systems by Ross Anderson
Affiliate Disclosure: As an Amazon Associate, I earn from qualifying purchases. This means that if you click on one of the Amazon links and make a purchase, I may receive a small commission at no additional cost to you. This helps support the site and allows me to continue creating valuable content.
