Skip to content
PuglieseWeb Engineering HandbookSystemDox Pages

AWS Config

AWS Config records the configuration of your AWS resources and how it changes over time. It is the service that answers “what did this look like last Tuesday, and who changed it?” — including for resources that have since been deleted.

For teams doing configuration management in the ITIL sense, Config is the piece that holds the configuration baseline and reports variation against it.

  • It keeps a configuration history per resource, so drift is visible rather than inferred.
  • Rules evaluate resources against conditions you define and mark them compliant or non-compliant.
  • Alerts go out through Amazon SNS, and changes and compliance events can be routed through Amazon EventBridge.

Config is configured per Region, but results can be aggregated across Regions and across accounts into a single aggregator view — which is how you get one compliance picture for an organization.

Config rules

Section titled “Config rules”

Rules come from two places: AWS-managed rules, which cover most common requirements out of the box, and custom rules backed by a Lambda function or a Guard policy.

Trigger types decide when a rule runs:

  • Configuration change — whenever a resource in the rule’s scope is created, updated or deleted.
  • Periodic — on a schedule you choose, for example every 24 hours.
  • Hybrid — both.

Evaluation modes decide what a rule looks at:

  • Detective evaluates resources that already exist. This is the default and the mode most rules use.
  • Proactive evaluates a proposed set of resource properties before anything is deployed, so a pipeline can ask “would this be compliant?” and fail early.

A distinction worth being precise about: proactive rules do not block deployment. They return a verdict; they do not stop the resource being created and they do not remediate it. Only genuine preventive controls — service control policies, resource control policies, and CloudFormation hooks such as Control Tower’s proactive controls — actually stop an API call. Proactive evaluation also supports a limited set of resource types, so check before designing around it.

Common rule examples: RDS instances have backups enabled, CloudTrail is enabled in the account, EBS volumes are encrypted, security groups do not allow unrestricted access to specific ports, required tags are present.

Automated remediation

Section titled “Automated remediation”
  • Remediation runs through AWS Systems Manager Automation documents.
  • Documents can be AWS-managed or custom; a custom document can call a Lambda function for logic that has no runbook equivalent.
  • Remediation can be automatic or require manual approval.
  • If an automatic remediation fails, retries can be configured.

Cost

Section titled “Cost”

AWS Config bills on two things: configuration items recorded, and rule evaluations.

  • Recording can be continuous (an item every time a resource changes) or periodic (at most one item per resource per day). Continuous costs less per item; periodic records far fewer items. Which is cheaper depends entirely on how often your resources actually change, so pick per resource type rather than globally.
  • Rule evaluations are tiered by monthly volume per Region, and conformance-pack evaluations share the same tiers.

Both rates change; see the AWS Config pricing page rather than a figure copied into a document. On a large estate with continuous recording of high-churn resource types, Config is not a rounding error — it is worth modelling before you turn it on organization-wide.

Section titled “Related”