Site icon IT & Life Hacks Blog｜Ideas for learning and practicing

The Complete AWS Config Guide: Systematizing Configuration Change Tracking and Continuous Compliance (with Comparisons to GCP Cloud Asset Inventory / Azure Policy + Resource Graph)

greeden
AWS Config

AWS Config

The Complete AWS Config Guide: Systematizing Configuration Change Tracking and Continuous Compliance (with Comparisons to GCP Cloud Asset Inventory / Azure Policy + Resource Graph)

Bottom line first: AWS Config is the foundation for handling both “change evidence” and “continuous compliance”

AWS Config is a governance-focused service that records AWS resource configurations (settings), tracks changes, and evaluates compliance via rules. What truly matters in real operations is being able to explain—during incidents or audits—“when, which setting, changed how,” and being able to turn “detect drift from the desired state and restore it” from a manual procedure into a mechanism. :contentReference[oaicite:0]{index=0}

The same pain exists on GCP and Azure. GCP’s Cloud Asset Inventory explicitly states it can be used for tracking resource changes for audit trails and drift management, and that you can receive change notifications via Pub/Sub. :contentReference[oaicite:1]{index=1}
On Azure, it’s organized such that Azure Policy can enforce, evaluate, and remediate organizational standards at scale, while Resource Graph supports cloud asset exploration and inventory management. :contentReference[oaicite:2]{index=2}

This article centers on AWS Config and, from an on-the-ground perspective, ties together a single design story: “What should we record?”, “How do we evaluate?”, and “How do we aggregate in multi-account environments?”

Who this helps (specifically)

First, SRE / operations teams. In configuration-related incidents, the hardest part isn’t “finding the culprit”—it’s “establishing the facts.” With AWS Config, configuration history and resource relationships (dependencies) help you scope impact and narrow down change-related causes faster. :contentReference[oaicite:3]{index=3}

Next, security / corporate IT teams. In audits and customer requirements, “we have rules” and “we continuously comply” are not the same thing. AWS Config supports rule evaluation and provides “conformance packs” that bundle rules and remediation, making it easier to distribute continuous compliance checks. :contentReference[oaicite:4]{index=4}

And finally, cloud administrators running multi-account operations. AWS Config provides an Aggregator to centrally view AWS Config data across multiple accounts, multiple regions, and AWS Organizations. :contentReference[oaicite:5]{index=5}
If you’re tired of “checking each account separately,” this is aimed at building a centralized view.

1. What AWS Config is: a service that treats “recording (evidence)” and “evaluation (compliance)” in the same UI and language

The essence of AWS Config is that it can handle these two things simultaneously:

  • Continuously record configuration changes and keep them as history (evidence)
  • Evaluate against rules and detect non-compliance (continuous compliance)

Official descriptions state that AWS Config tracks changes in resource configuration, periodically delivers updated configuration information to a specified S3 bucket, sends configuration history files at regular intervals (e.g., every 6 hours), and can deliver configuration snapshots (a full picture). :contentReference[oaicite:6]{index=6}

The key point: Config is closer to “recording and evaluating” than “monitoring.” Instead of second-by-second anomaly detection like metrics monitoring, it handles changes in “state” (configuration) and whether that state conforms to rules. That’s why it’s particularly strong for post-incident prevention, audit responses, and continuous standardization.

2. The first design decision: what to record (scope) determines 90% of operational success

When teams introduce AWS Config, the first common question is: “Should we record everything?” The practical answer is that it’s usually better to define your objectives first and roll out recording scope in phases, rather than record everything unconditionally from day one.

Officially, Config creates configuration history files per resource type and includes details about resources that changed. That means the broader your recording scope, the more data you emit, and the heavier storage/search/retention operations become. :contentReference[oaicite:7]{index=7}

Also, the Japanese documentation explicitly notes that recording AWS::Config::ResourceCompliance (to preserve past compliance results) is not required for current compliance evaluations and can be excluded if unnecessary. This is very practical: you can tune “depth of history” based on requirements. :contentReference[oaicite:8]{index=8}

A recommended phased rollout (least contentious in real teams) looks like this:

  1. Start with “high-pain areas” (networking, permissions, public exposure) for recording/evaluation
  2. Add “cost-accident-prone areas” (unused resources, missing tags, abandonment)
  3. Finally add “strict audit-required areas” (paired with retention period and evidence presentation)

This sequence makes benefits visible early while controlling operational load.

3. Rules and conformance packs: from “individual rules” to “packaged operations”

AWS Config evaluates via Config Rules (managed/custom), and conformance packs let you distribute multiple rules and remediation actions together. Official docs describe a conformance pack as “a collection of Config rules and remediation actions” that can be deployed to accounts/regions or across an entire Organization. :contentReference[oaicite:9]{index=9}

A major operational tip is not to add rules ad hoc. If you keep adding individual rules without a plan, you often end up with:

  • No one knows what a rule is for
  • Exception handling becomes person-dependent
  • Non-compliance grows so large that nobody looks anymore

Sample template descriptions show that conformance packs are easy to bundle by purpose—“security,” “operations,” “cost optimization,” etc. :contentReference[oaicite:10]{index=10}
In other words, you can operate rule sets as “purpose-based packages,” which makes team alignment easier.

Example bundles (conceptual)

  • Security baseline pack: minimum must-have items (public exposure, encryption, logging, etc.)
  • Operations standard pack: tagging, backups by default, monitoring expectations, etc.
  • Cost hygiene pack: early detection of unused/abandoned/oversized resources

This “pack-level” thinking also maps well to GCP/Azure (policy sets and organizational standards), as covered later.

4. Multi-account aggregation: use Aggregator to make “one place to look”

Because AWS often defaults to multi-account setups, it’s common to want a centralized Config view. Official docs explain that aggregators can collect AWS Config configuration and compliance data from multiple accounts and regions, or from all enabled accounts under Organizations. :contentReference[oaicite:11]{index=11}

Once this is in place, operational benefits become immediate:

  • See which accounts are non-compliant at a glance
  • Operate as “a mechanism to restore,” not “blame a team”
  • Explain in audits that the organization performs continuous evaluation

In short, Config’s value tends to grow dramatically in multi-account environments where standardization is the goal.

5. Change tracking: Config shines when you must explain “since when was this wrong?”

The most “saved me” moment with AWS Config is during incident response or investigations when asked: “Since when has this setting been like this?” Config can deliver configuration history files and snapshots to S3 and preserve them as history. :contentReference[oaicite:12]{index=12}

It’s also described that you can store and view a timeline of compliance state changes for conformance packs. This means you can track not only “it’s non-compliant now,” but also “when it became non-compliant,” which is highly valuable as operational evidence. :contentReference[oaicite:13]{index=13}

The design point here is not only “keep history or not,” but also:

  • How long you retain it
  • Who looks at it and how often
  • How you manage exceptions (legitimate deviations)

“Logs exist but nobody checks them” effectively becomes “logs don’t exist,” so it’s recommended to define a minimum cadence (e.g., weekly/monthly review of top 10 non-compliance items).

6. Comparison with GCP: Cloud Asset Inventory centers on “inventory + change notifications”

GCP Cloud Asset Inventory is organized around use cases such as metadata filtering, audit trails via change tracking, compliance drift management, and security/cost audits. :contentReference[oaicite:14]{index=14}
For asset history, it explicitly states you can retrieve up to 35 days of create/update/delete history. :contentReference[oaicite:15]{index=15}

It also officially describes receiving “real-time change notifications” via Pub/Sub by creating and subscribing to feeds. :contentReference[oaicite:16]{index=16}

So on GCP, a common standard pattern is:

  • Use Asset Inventory for inventory (current state) and history (recent changes)
  • Use change notifications (Pub/Sub) as the trigger to build detection → automated response (or ticketing)

A clear difference vs AWS Config is that AWS can place “rule evaluation and compliance” at the center via Config, whereas on GCP “asset visibility and change detection” are strongly handled by Asset Inventory, and policy enforcement/remediation is often built by combining other mechanisms (Org Policy, automation). It’s less about “which is better” and more about a difference in design philosophy and service boundaries.

7. Comparison with Azure: Policy handles “evaluation + remediation,” Resource Graph handles “cross-tenant exploration”

Azure Policy is described as a mechanism to enforce organizational standards and evaluate compliance at scale, offering aggregated views via compliance dashboards and touching on bulk remediation for existing resources as well as automatic remediation for new resources. :contentReference[oaicite:17]{index=17}

For “remediation tasks” that fix non-compliant resources, it explicitly explains executing remediation operations (by specified IDs) for deployIfNotExists and modify policy assignments. :contentReference[oaicite:18]{index=18}

Meanwhile, Resource Graph is organized as a service to explore cloud inventory and manage it more effectively. :contentReference[oaicite:19]{index=19}
In other words, Azure has a clear split:

  • Policy: evaluate whether standards are met + a mechanism to restore
  • Resource Graph: cross-environment inventory/exploration (query)

Mapping to AWS Config: Config’s “evaluation (rules / conformance packs)” resembles Policy, and Config’s “inventory/history” is closer to Resource Graph / asset management. For multi-cloud governance alignment, discussing it in this mapping tends to synchronize understanding across teams.

8. A practical onboarding template: what to decide in the first two weeks

To avoid “we enabled AWS Config but it’s just there,” here are the items that become much easier later if you align early:

  1. Priority of objectives
    Is it for audits, incident investigation, or standardization (continuous compliance)? Objectives change both recording scope and rule selection. :contentReference[oaicite:20]{index=20}

  2. Recording scope (target resource types)
    Do you start with everything or start with critical domains? Decide together with history depth (e.g., whether to retain past compliance history). :contentReference[oaicite:21]{index=21}

  3. Unit of rule operations
    Do you grow via individual rules, or bundle by purpose via conformance packs? Long-term, packs tend to be less likely to collapse. :contentReference[oaicite:22]{index=22}

  4. Multi-account aggregation approach
    Will you aggregate centrally via an Aggregator, and which account “owns” the aggregated view? :contentReference[oaicite:23]{index=23}

  5. Storage and retention policy
    Because Config delivers history to S3, define retention and lifecycle/archiving as operational rules. It’s also specified that Config itself does not modify S3 lifecycle policies. :contentReference[oaicite:24]{index=24}

  6. Build a “review routine”
    Define who checks what weekly/monthly (non-compliance review, exception review). Without this, non-compliance tends to pile up and the system becomes ceremonial.

Summary: AWS Config becomes “team confidence” as standardization matures

AWS Config is a core governance service that records configuration changes, preserves history, and evaluates compliance via rules. With building blocks such as S3 delivery of configuration history and snapshots, bundling rules and remediations via conformance packs, and multi-account aggregation via aggregators, it’s well-suited to shifting operations from “procedures” to “mechanisms.” :contentReference[oaicite:25]{index=25}

GCP Cloud Asset Inventory is strong at inventory + change tracking and Pub/Sub change notifications, while Azure shows a clear split: Policy for evaluation/remediation and Resource Graph for cross-environment exploration. :contentReference[oaicite:26]{index=26}

A robust “first step” is: “start recording + evaluating from critical domains, bundle by purpose with conformance packs, and create a centralized aggregated view with an Aggregator.” Start small and don’t rush—but define the “review routine” carefully from the beginning. With AWS Config, that care directly translates into strength in incident response and audit readiness.

Reference links (official / primary sources prioritized)

Exit mobile version