# 016 - AWS Config Strategic Use

Gil Ferreira

Last Modified: February 2026

Title: Strategic Use of AWS Config for Compliance, Drift Detection, and Event-Driven Governance

Status: Proposed

# Context

Our environment uses a broad set of AWS services (Lambda, S3, EC2, ECS, ECR, Textract) and is provisioned and managed via Terraform and Ansible. We need continuous visibility into resource configuration, compliance against security and operational baselines, and the ability to react to configuration changes in an event-driven manner—without relying solely on periodic audits or manual checks.

Drivers:

Configuration drift: Resources change outside IaC (console, CLI, other automation). Terraform state reflects desired state; we need a record of actual state and deviations.
Compliance: Security and governance requirements (tagging, encryption, network posture) must be validated continuously, not only at deploy time.
Event-driven response: When a resource becomes non-compliant or a risky change occurs, we want automated detection and optional remediation rather than delayed discovery.
Audit trail: A durable history of configuration changes supports incident response and compliance evidence.

AWS Config provides configuration recording, managed and custom rules, conformance packs, and integration with EventBridge and Lambda. This ADR defines how we use it strategically and where it fits alongside Terraform, Ansible, and our event-driven architecture.

# Decision

We will adopt AWS Config as the standard mechanism for:

Recording configuration history of selected AWS resources (Lambda, S3, EC2, ECS, ECR, and other supported resources).
Evaluating compliance via Config rules (managed and custom) and conformance packs.
Driving event-based workflows by consuming Config change and compliance events via EventBridge (and optionally SNS) for alerting, remediation, and integration with existing automation.

Config will complement, not replace, Terraform (desired state / provisioning) and Ansible (instance-level configuration). Config is the source of truth for recorded actual resource configuration and compliance state over time.

# Rationale

Single place for actual state over time: Terraform state is desired state; Config captures what actually exists and how it changed. That supports drift analysis and audit.
Managed rules and conformance packs: Reduces custom code for common checks (e.g. S3 bucket public access, unencrypted volumes, security group rules). Conformance packs bundle rules for frameworks (e.g. CIS, operational best practices).
Native event output: Config publishes configuration changes and compliance change events to EventBridge. That fits our event-driven architecture and allows Lambda, Step Functions, or other consumers to react without polling.
Leverage across our stack: Config supports Lambda, S3, EC2, ECS, ECR, and many other services we use. We can apply consistent governance regardless of whether resources were created by Terraform, Ansible, or manually.
Remediation: Config rules can trigger SSM Automation or Lambda for auto-remediation (e.g. enable S3 block public access, add required tags), with appropriate guardrails.

# Guidance: How to Use AWS Config

# 1. Recording (Configuration Items)

Enable Config in each account/region where we need governance. Use an aggregator if we have multiple accounts/regions for a single view.
Resource types: Enable recording for the subset we care about to balance cost and value:
- Lambda: AWS::Lambda::Function (config, env, VPC, etc.)
- S3: AWS::S3::Bucket (and optionally AWS::S3::BucketPolicy)
- EC2: AWS::EC2::Instance, AWS::EC2::SecurityGroup, AWS::EC2::Volume, AWS::EC2::VPC, etc.
- ECS: AWS::ECS::Cluster, AWS::ECS::Service, AWS::ECS::TaskDefinition
- ECR: AWS::ECR::Repository
Delivery: Store configuration history and snapshots in an S3 bucket and stream to SNS if we need immediate notifications. Prefer EventBridge for downstream automation (see below).
Retention: Set retention for configuration items and snapshots per compliance/audit requirements (e.g. 7 years for certain regimes).

# 2. Rules and Conformance Packs

Start with managed rules for common controls (e.g. s3-bucket-public-read-prohibited, ec2-instance-detailed-monitoring-enabled, ec2-security-group-attached-to-eni, lambda-inside-vpc).
Conformance packs: Use for baseline compliance (e.g. a custom “IBP security baseline” conformance pack) so we roll out a set of rules consistently across accounts/regions.
Custom rules: Use when we need checks not covered by managed rules (e.g. “all ECS services must use Fargate”, “all ECR repos must have image scanning on push”). Implement via Lambda (Config custom rule trigger).
Scope: Use scope of changes where possible so rules run only when relevant resources change, reducing cost and speeding evaluation.

# 3. Integration with Terraform and Ansible

Concern	Terraform / Ansible	AWS Config
Desired state / provisioning	Terraform	—
Instance OS/config	Ansible	—
Actual AWS resource config over time	—	Config recording
“Did something change outside IaC?”	Drift in Terraform	Config change events + history
“Does this resource meet our policy?”	Not primary	Config rules / conformance packs

Terraform: Deploy Config recorder, delivery channel, rules, and conformance packs via Terraform. Config will then observe those resources; drift detected by Config (e.g. tag removed) can trigger events that we can use to re-run Terraform or alert.
Ansible: Config does not manage OS-level config. We can use EventBridge from Config to trigger Ansible (e.g. when a new EC2 instance is recorded) for host-level hardening, if desired.

# 4. Where Config Fits in Our Stack

Area	Use Config For
Lambda	Recording function config (VPC, env, runtime); rules for “Lambda in VPC”, “no public access”, “approved runtimes”.
S3	Bucket config and policy; rules for public access block, encryption, versioning, logging.
EC2	Instance, security group, volume, AMI; rules for detailed monitoring, restricted SG rules, EBS encryption.
ECS	Cluster, service, task definition; rules for Fargate-only, CPU/memory limits, logging.
ECR	Repository config; rules for scan on push, lifecycle policy, encryption.
Textract	Config has limited Textract-specific rules; use for general account/region posture; any Textract-specific policy via custom rule if needed.
Cross-cutting	Tagging (e.g. “required tags”), encryption standards, network (e.g. no 0.0.0.0/0 on SG).

# Event-Driven Use Cases Where AWS Config Shines

These patterns use Config’s configuration change delivery and compliance change events to EventBridge (and optionally Lambda) for real-time or near-real-time response.

# 1. S3 Bucket Accidentally Made Public

Config rule: e.g. s3-bucket-public-read-prohibited or custom rule on bucket policy.
Event: Config emits compliance change event (resource non-compliant).
EventBridge: Rule matches config-compliance-change; target Lambda or Step Functions.
Action: Notify security team; optionally invoke remediation (e.g. Lambda to set block public access, or SSM Automation).
Why Config: Continuous evaluation on every relevant S3 change; event-driven so we don’t wait for a scan.

# 2. Security Group Opened to 0.0.0.0/0

Config rule: e.g. restricted-common-ports or custom rule (no 0.0.0.0/0 on 22/3389/443 etc.).
Event: Configuration change (SG rule added) + compliance change (now non-compliant).
EventBridge: Trigger Lambda or SNS.
Action: Alert; optional auto-remediation (e.g. remove offending rule via Lambda or SSM).
Why Config: Evaluates as soon as the SG resource is updated; event-driven remediation.

# 3. Lambda Deployed Without VPC (Policy Requires VPC)

Config rule: e.g. lambda-inside-vpc (managed) or custom.
Event: Compliance change when a new or updated function has no VPC config.
EventBridge: Notify or trigger runbook / Terraform fix.
Why Config: Aligns with our Lambda usage and catches misconfigurations at change time.

# 4. ECS Task Definition or Service Changed Outside Terraform

Config: Records AWS::ECS::TaskDefinition / AWS::ECS::Service changes.
Event: Configuration change event for the ECS resource.
EventBridge: Rule triggers Lambda that compares to Terraform state or runbook; optionally trigger Terraform apply or alert.
Why Config: Gives an event when “someone changed ECS in the console”; we can reconcile with IaC.

# 5. ECR Repository Missing “Scan on Push” or Encryption

Config rule: Managed or custom (e.g. “ECR repo has image scan on push enabled”).
Event: Compliance change.
EventBridge: Notify; optional remediation (enable scan via API).
Why Config: Keeps container supply chain posture consistent across many repos.

# 6. New Resource Missing Required Tags

Config rule: e.g. “required-tags” (managed or custom).
Event: Compliance change when resource is created/updated without tags.
EventBridge: Lambda to add tags (remediation) or notify.
Why Config: Fires on create/update; good for cost and governance tagging.

# 7. Compliance Dashboard and Escalation

Config: Conformance pack scores; compliance change events per rule.
EventBridge: Stream compliance events to analytics (e.g. S3 + Athena, or third-party SIEM). Aggregate for dashboards.
Action: Escalate when compliance score drops or critical rules fail.
Why Config: Single pipeline of compliance events for real-time visibility.

# 8. Triggering Terraform Drift Check or Ansible

Config: Configuration change event (e.g. EC2 or ECS changed).
EventBridge: Rule triggers pipeline or Lambda that runs terraform plan (drift) or triggers Ansible for that host.
Why Config: Uses Config as the “something changed” signal; Terraform/Ansible remain the remediation mechanism.

# Implications

People/Training
- Teams need a basic understanding of Config (recorder, rules, conformance packs, events).
- Operators and security need to know how to respond to Config-driven alerts and optional remediation.
Process
- Define which rules are “informational” vs “blocking” (e.g. alert only vs auto-remediate).
- Integrate Config compliance into release and change management where appropriate (e.g. gate or visibility).
- Document remediation runbooks for key rules.
Tooling
- Provision Config (recorder, delivery, rules, conformance packs) via Terraform.
- Use EventBridge as the primary consumer of Config events; Lambda/Step Functions for remediation or escalation.
- Consider Config aggregator if we have multiple accounts/regions.
Risks
- Cost: Recording many resource types and high churn can increase Config cost; limit recorded types and use scope-of-changes for rules.
- Noise: Too many rules or overly strict rules can generate alert fatigue; tune and prioritize.
- Remediation: Auto-remediation can conflict with Terraform if both change the same resource; define clear ownership (e.g. Config remediates tags, Terraform owns structural changes).

# Trade-Offs

Benefits
- Continuous compliance and configuration history without manual audits.
- Event-driven response to misconfigurations, aligned with our architecture.
- Reusable conformance packs and managed rules across accounts/regions.
- Clear separation: Terraform/Ansible for “do”; Config for “observe and evaluate.”
Drawbacks
- Additional cost and operational surface (recorder, rules, aggregator).
- Rule and remediation design required to avoid conflicts with IaC and to limit noise.

# Key Evaluation Metrics

Coverage: Percentage of in-scope accounts/regions with Config enabled and key rules deployed.
Time to detect: Mean time from a non-compliant change to Config evaluation and event delivery.
Remediation rate: Percentage of non-compliant resources remediated (manually or automatically) within SLA.
Event pipeline health: EventBridge delivery success and Lambda/Step Functions execution success for Config-driven workflows.
Cost: Config and downstream (Lambda, EventBridge) cost per account/region, tracked and reviewed.

# Conclusion

We will use AWS Config strategically to record configuration history, evaluate compliance with managed and custom rules (and conformance packs), and feed EventBridge with configuration and compliance change events. That supports event-driven alerting, remediation, and integration with Terraform and Ansible. We will scope recording and rules to our main services (Lambda, S3, EC2, ECS, ECR) and adopt Config incrementally—starting with high-value rules and a few event-driven use cases—then expand by account and rule set.