beginnerintermediateadvanced

AWS · Config and Governance

AWS Config and Governance

Configuration history, rules and remediation, and how Config differs from CloudTrail

Configuration item per changepoint-in-time view of one resource
Rules report, they do not blockprevention is SCPs and IAM
Conformance pack = rules + remediationdeployable org-wide as one unit
Config = state, CloudTrail = actionan investigation needs both

1.Configuration Recorder, Items, and History

AWS Config watches your resources and writes down how each one is configured. The configuration recorder is the thing that watches; every time a recorded resource is created, changed, or deleted it writes a configuration item — a point-in-time snapshot of that one resource. The collection of those items for a resource over time is its configuration history, and it is what lets you answer "what did this security group look like last Tuesday".

Key features

A configuration item is a point-in-time view of one resource: metadata, attributes, relationships, current configuration, and related events
A customer managed configuration recorder records all supported resource types in its Region by default; a service-linked recorder's scope is fixed by the linked service
Configuration history is the collection of configuration items for one resource over a time period, delivered to an S3 bucket you specify and browsable as a timeline
A configuration snapshot is the opposite cut: every recorded resource at one moment, useful for validating the whole account rather than one resource
The configuration stream publishes each new configuration item to an SNS topic, so changes can trigger notifications or external systems as they happen
AWS Config also builds a relationship map — an EBS volume attached to an instance associated with a security group — so you can see the blast radius of a change

The four record shapes AWS Config produces

The four record shapes AWS Config produces
Record	Covers	When it is written	Where it lands
Configuration item	One resource, one moment	On every create/update/delete of a recorded resource	S3 + the Config API
Configuration history	One resource, over time	Accumulated from configuration items	S3 bucket you specify, console timeline
Configuration snapshot	Every recorded resource, one moment	On request, or on a schedule you set	S3 bucket you specify
Configuration stream	Every new configuration item	Continuously, as changes happen	An SNS topic of your choice

From a resource change to an answerable history

detected bywritesaccumulatesintopublished to

Resource changes

security group edited

Configuration recorder

in scope?

Configuration item

point-in-time view

Configuration history

S3 bucket + console timeline

Configuration stream

SNS notification

Signature

recorder → configuration item → configuration history · snapshot (all resources, one moment) · stream (SNS)

The configuration recorder writes a configuration item on every change to a recorded resource. Those items accumulate into that resource's configuration history — the only place its previous configuration exists. A snapshot is the same data cut the other way: every resource at one moment.

2.Config Rules, Conformance Packs, and Remediation

A Config rule is a compliance check written against a resource's configuration — "every EBS volume must be encrypted", "no security group may allow 0.0.0.0/0 on port 22". AWS Config evaluates matching resources and marks each one COMPLIANT or NON_COMPLIANT. A conformance pack is a bundle of rules and remediation actions deployed as one unit, and a remediation action is what fixes a flagged resource instead of only reporting it.

Key features

Managed rules are predefined and customizable by AWS Config; custom rules are yours, written as a Lambda function or as CloudFormation Guard policy
Evaluation results are COMPLIANT, NON_COMPLIANT, ERROR (a bad rule parameter), or NOT_APPLICABLE (the rule's logic does not apply to that resource)
Triggers are configuration-change (evaluate when a matching resource changes), periodic (every N hours), or hybrid — both
Detective evaluation checks resources already deployed; proactive evaluation checks a proposed set of properties before deployment — but proactive rules neither remediate nor block a deployment
A conformance pack is a YAML template bundling managed/custom rules plus remediation actions, deployable to one account and Region or across an AWS Organization
An aggregator collects configuration and compliance data from many accounts and Regions into one account, is read-only, and adds no extra cost

Rule trigger and evaluation modes

Rule trigger and evaluation modes
Setting	Option	What it means
Trigger	Configuration changes	Evaluates when a resource in the rule's scope is created, updated, or deleted
Trigger	Periodic	Evaluates on a fixed frequency you choose, e.g. every 24 hours
Trigger	Hybrid	Both — on change and on the periodic schedule
Mode	Detective	Evaluates resources that already exist
Mode	Proactive	Evaluates proposed resource properties before deployment; does not block or remediate

From a rule to a fixed resource

evaluated onproducesNON_COMPLIANTdrivesreportedinto

Config rule

managed, or Lambda/Guard custom

Trigger

configuration change / periodic

Evaluation result

COMPLIANT / NON_COMPLIANT / ERROR / NOT_APPLICABLE

Remediation action

SSM Automation document

Aggregator

org-wide read-only view

Signature

Config rule (managed | custom Lambda/Guard) → COMPLIANT / NON_COMPLIANT / ERROR / NOT_APPLICABLE → remediation

Rules evaluate configuration and label resources COMPLIANT or NON_COMPLIANT — they report, they do not prevent. Conformance packs bundle rules plus remediation for deployment across an organization; aggregators give one read-only, org-wide view. Prevention still belongs to SCPs and IAM.

3.AWS Config vs CloudTrail

CloudTrail answers "who called what API, when, and from where". AWS Config answers "what did this resource actually look like at that moment". They overlap in feeling — both are audit tools — but they record different things: CloudTrail records the action, Config records the resulting state. An investigation usually needs both.

Key features

CloudTrail records API calls — the actor, the action, the time, the source IP; AWS Config records configuration items — the resource's attributes and relationships
A change made outside the API surface CloudTrail sees (a resource drifting, an indirect effect on a related resource) still produces a Config configuration item
CloudTrail Event history covers 90 days of management events with no setup; AWS Config history exists only from when the recorder was started
Config alone cannot tell you which principal made a change; CloudTrail alone cannot tell you what the resource looked like before it
Both are regional and both need deliberate multi-Region, multi-account setup — an organization trail for CloudTrail, an aggregator for Config

Which service answers which question

Which service answers which question
Question	Service	Where the answer lives
Who opened port 22 to the internet?	CloudTrail	The AuthorizeSecurityGroupIngress event's userIdentity
What were this security group's rules last Tuesday?	AWS Config	The configuration item recorded at that time
Which resources are non-compliant right now?	AWS Config	Rule evaluation results
Was this S3 object read, and by whom?	CloudTrail (data events)	A trail with S3 data events enabled
What is attached to this EC2 instance?	AWS Config	The configuration item's relationship map

Two questions, two services

CloudTrail — the action

Who called the API, when, from where
Management events by default; data events opt-in
90-day Event history without setup; trails for retention
Answers "who did this"

AWS Config — the state

What the resource was configured as, moment by moment
Configuration items written on every recorded change
History exists only from when recording started
Answers "what did it look like before"

Command

text

# The two halves of one investigation
# 1. What was it configured as?
aws configservice get-resource-config-history \
  --resource-type AWS::EC2::SecurityGroup --resource-id sg-0a1b2c3d

# 2. Who made it that way?
aws cloudtrail lookup-events --lookup-attributes \
  AttributeKey=ResourceName,AttributeValue=sg-0a1b2c3d

CloudTrail = the action (who called which API, when). AWS Config = the state (what the resource was configured as, then and now). Neither substitutes for the other, and an incident review normally starts in Config and ends in CloudTrail.

Spotted a mistake on this page? Tell us.

Read Sheet