beginnerintermediateadvanced

AWS · Section 35

AWS Config and Governance

Level: intermediate
Read: 25 min
Concepts: 3

AWS Config records what your resources are configured as, moment by moment. A configuration recorder writes a configuration item on every change to a resource type in scope; those items accumulate into a per-resource configuration history delivered to an S3 bucket, alongside snapshots of the whole account and a configuration stream published to SNS. On top of that recorded state sit Config rules — managed or custom, triggered on configuration change or on a schedule — that mark each resource COMPLIANT or NON_COMPLIANT, conformance packs that deploy a whole rule set plus its remediation actions across an organization, and aggregators that give one read-only org-wide view. Rules report rather than prevent: proactive evaluation checks proposed properties but neither blocks nor remediates, so prevention still belongs to service control policies and IAM. Config sits next to CloudTrail rather than replacing it — Config describes resource configuration state, CloudTrail records API activity, and a real investigation uses both.

AWS overview

AWS Full Course 2026 | AWS Cloud Computing Tutorial for Beginners | AWS Training | SimplilearnSimplilearn

What is true here

The configuration recorder writes a configuration item on every change; the accumulated items are a resource's configuration history.
A snapshot is every recorded resource at one moment; the configuration stream pushes each item to an SNS topic as it happens.
Rules evaluate to COMPLIANT / NON_COMPLIANT / ERROR / NOT_APPLICABLE, on a configuration-change, periodic, or hybrid trigger.
Proactive rules check properties before deployment but do not block or remediate — prevention is an SCP/IAM job.
Config describes state; CloudTrail records the API call that produced it.

What you will be able to do

Explain what a configuration item, configuration history, snapshot, and configuration stream each contain
Choose a rule trigger and evaluation mode for a given governance check, and attach a remediation action to it
Deploy a rule set across an organization as a conformance pack, and aggregate results into one account
Decide whether a question belongs to AWS Config or to CloudTrail, and use both together in an investigation

Recording configuration, governing it, and telling it apart from CloudTrail

Recorder, items, history

Rules, conformance packs, remediation

State (Config) vs action (CloudTrail)

AWS Config and Governance

Recording configuration state, evaluating and remediating it with rules and conformance packs, and where Config stops and CloudTrail starts.

Configuration Recorder, Items, and History

coreintermediate

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".

Think of it as

Think of a building manager who photographs every room whenever anything in it moves. Each photo is a configuration item. The stack of photos for one room is that room's configuration history. A configuration snapshot is a photo of every room taken at the same moment, and the configuration stream is the manager shouting "room 14 changed" the instant it happens.

What we're doing: Answer "who widened this security group, and what did it look like before" without a hand-kept change log.

security-group-timeline.txttext

Config recorder is on, recording AWS::EC2::SecurityGroup.

09:14 configuration item: sg-0a1b2c3d ingress = [tcp/443 from 10.0.0.0/16]
10:02 someone adds an ingress rule in the console
10:02 configuration item: sg-0a1b2c3d ingress = [tcp/443 from 10.0.0.0/16,
                                                 tcp/22  from 0.0.0.0/0]
Console timeline for sg-0a1b2c3d shows both items side by side, with the
exact attribute that differs highlighted.

3: The item written before the change is the "last known good" configuration — you can read the exact prior state rather than reconstructing it.
6: The second item is written automatically on the change. Nothing in the workflow had to remember to record anything.

Why this works: The question "what was this configured as before" has no answer in the resource itself — a security group only shows its current rules. Configuration history is where the previous states live, which is why an account without AWS Config recording cannot answer configuration questions about its own past no matter how good its logging is.

Turning the recorder on only for the Region you happen to be looking at

Wrong

text

# Enable AWS Config in us-east-1 because that is where the app runs

Better

text

# Enable recording in every Region you have resources in, and aggregate
# the results into one account (see the Config rules concept)

What you see: An investigation into a resource in eu-west-1 finds no configuration history at all, because the recorder in that Region was never started.

Why: AWS Config is a regional service: a recorder records resources in its own Region only. An account with resources in five Regions and a recorder in one has history for a fifth of its estate, and nothing warns you about the other four.

From a resource change to an answerable history

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

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

Together

text

# One resource over time — the history
aws configservice get-resource-config-history \
  --resource-type AWS::EC2::SecurityGroup --resource-id sg-0a1b2c3d

# Every recorded resource right now — a snapshot
aws configservice deliver-config-snapshot --delivery-channel-name default

Remember: 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.

Config Rules, Conformance Packs, and Remediation

coreintermediate

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.

Think of it as

Rules are the building code; the configuration recorder is the inspector who already has photographs of every room. A conformance pack is the whole code book adopted at once rather than clause by clause, and remediation is the inspector being allowed to fix the wiring instead of only writing a citation.

What we're doing: Stop unencrypted EBS volumes from accumulating, across every account in the organization.

encrypted-volumes-governance.txttext

Rule: encrypted-volumes (managed), trigger = configuration changes
  scope: AWS::EC2::Volume

Someone creates an unencrypted volume in the staging account.
  → evaluation result: NON_COMPLIANT

Remediation action attached to the rule runs an SSM Automation document
that snapshots the volume, recreates it encrypted, and reattaches it.
Aggregator in the security account shows the org-wide compliance count
drop back to zero without anyone logging into staging.

1: A configuration-change trigger means the check runs when the volume is created, not hours later on a schedule — the window of exposure is minutes.
5: NON_COMPLIANT is a report, not a block. Nothing has been prevented at this point; the volume exists and is unencrypted.
8: Remediation is the step that closes the loop. Without it, governance is a dashboard someone has to read and act on.

Why this works: Rules alone produce a compliance number; remediation produces a compliant estate. The aggregator matters because the number has to be visible somewhere other than the account that broke the rule — a team that owns staging is not the team that reads the security dashboard.

Treating proactive evaluation as a guardrail that blocks bad deployments

Wrong

text

# "We enabled proactive rules, so non-compliant resources cannot be
# created any more."

Better

text

# Use proactive rules to check properties before deployment in a pipeline,
# and use SCPs / IAM conditions when you actually need the action denied

What you see: A non-compliant resource is created anyway and shows up as NON_COMPLIANT afterwards, despite a proactive rule existing for exactly that check.

Why: AWS Config documents this directly: proactive rules do not remediate resources flagged NON_COMPLIANT and do not prevent them from being deployed. Prevention is an authorization concern — a service control policy or an IAM condition — not a Config concern.

From a rule to a fixed resource

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

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

Together

text

# A managed rule with a configuration-change trigger, scoped by resource type
aws configservice put-config-rule --config-rule file://encrypted-volumes.json

# What the account currently fails
aws configservice describe-compliance-by-config-rule \
  --compliance-types NON_COMPLIANT

Remember: 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.

AWS Config vs CloudTrail

standardintermediate

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.

Think of it as

CloudTrail is the door log: it records that a specific person opened a specific door at 10:02. AWS Config is the photograph of the room: it shows what was inside before and after. The log tells you who; the photograph tells you what changed.

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

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"

Enabling one of the two and assuming it covers the other's question

Wrong

text

# "CloudTrail is on, so we have a full audit trail — AWS Config would be
# duplicate logging."

Better

text

# Run both: CloudTrail for who/what/when on the API call, AWS Config for
# the resource state before and after that call

What you see: An incident review can name the principal that made a change but cannot say what the resource was configured as beforehand, so the rollback target has to be guessed from memory or from a stale runbook.

Why: A CloudTrail event carries the request parameters of one API call, not the full resulting configuration of the resource — and many resources reach a state through several calls plus service-side defaults. Reconstructing prior state from API events is guesswork; a configuration item is the state, recorded.

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

Together

text

# "What did it look like?" — Config
aws configservice get-resource-config-history \
  --resource-type AWS::EC2::SecurityGroup --resource-id sg-0a1b2c3d

# "Who changed it?" — CloudTrail
aws cloudtrail lookup-events --lookup-attributes \
  AttributeKey=ResourceName,AttributeValue=sg-0a1b2c3d

Remember: 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.