AWS Config Tutorial: Architecture, Pricing, Use Cases, and Hands-On Guide for Management and governance

by

Category

Management and governance

1. Introduction

AWS Config is an AWS Management and governance service that continuously records your AWS resource configurations, tracks how they change over time, and evaluates those configurations against rules you define.

In simple terms: AWS Config is “configuration history + compliance checks for AWS resources.” It helps you answer questions like: What changed? When? Who/what might have caused it? Is this resource compliant with our standards?

Technically, AWS Config uses a configuration recorder in each AWS Region to capture configuration items (metadata about supported AWS resources). It delivers these items to an Amazon S3 bucket (and optionally publishes notifications to Amazon SNS) and can evaluate recorded resources with AWS Config Rules and Conformance Packs. You can aggregate data across accounts and Regions with a configuration aggregator, query it with advanced queries, and integrate it with services like AWS Organizations, Amazon EventBridge, AWS Systems Manager, and AWS Security Hub.

The problem AWS Config solves is governance at scale: maintaining visibility and control over how your cloud infrastructure is configured—across accounts, Regions, and teams—without relying on ad-hoc scripts or manual audits.

2. What is AWS Config?

Official purpose

AWS Config is designed to help you assess, audit, and evaluate the configurations of your AWS resources. It provides resource inventory, configuration history, change notifications, and compliance evaluation against your desired configuration rules.

Official docs: https://docs.aws.amazon.com/config/latest/developerguide/WhatIsConfig.html

Core capabilities

Key capabilities include:

  • Configuration recording of supported resource types (configuration items).
  • Configuration history and resource timeline for change analysis.
  • Configuration snapshots (point-in-time exports).
  • Compliance evaluation using:
  • AWS managed rules
  • Custom rules (typically backed by AWS Lambda)
  • Conformance Packs (collections of rules)
  • Remediation support (commonly through AWS Systems Manager Automation for managed remediation actions).
  • Notifications of configuration and compliance changes (SNS / EventBridge integrations).
  • Multi-account and multi-Region aggregation using configuration aggregators.
  • Querying across your recorded configuration data using AWS Config advanced queries (SQL-like query language for supported resource properties).

Major components

  • Configuration recorder: Collects configuration changes for selected resource types in a Region.
  • Delivery channel: Sends configuration items and snapshots to an S3 bucket; can also send notifications to an SNS topic.
  • Configuration item (CI): The recorded representation of a resource’s configuration at a point in time.
  • AWS Config Rules: Evaluate whether resources comply with desired settings.
  • Conformance Packs: Packaged sets of rules and optional remediation settings to enforce standards at scale.
  • Configuration aggregator: Central view across accounts/Regions (often in a security or governance account).
  • Remediation actions: Automated fixes triggered for noncompliance (often via Systems Manager).
  • Advanced queries: Search and analyze configuration state across resources.

Service type

AWS Config is a managed governance service. You don’t deploy servers for it; you configure it and AWS runs the recording, storage delivery, and evaluation workflows.

Scope: regional/global and account considerations

  • Regional service: AWS Config is configured per Region. You enable it in each Region you want to record.
  • Global resources: Some AWS resources are “global” (for example, certain IAM resources). AWS Config supports recording global resources, but the recording happens in a selected Region. The exact behavior can vary by resource type—verify the “global resource” behavior in the official docs for your use case.
  • Account-scoped by default: AWS Config records resources in the current AWS account and Region unless you use AWS Organizations features (organization rules / conformance packs) and/or an aggregator.

How it fits into the AWS ecosystem

AWS Config complements (but does not replace) other governance and security services:

  • AWS CloudTrail answers: “Who called what API and when?”
  • AWS Config answers: “What is the configuration now, what was it before, and is it compliant?”
  • Amazon CloudWatch focuses on metrics/logs/alarms and operational telemetry.
  • AWS Security Hub aggregates security findings; AWS Config can be one data source and policy signal.
  • AWS Organizations provides multi-account management; AWS Config can enforce and report compliance across the organization.
  • AWS Systems Manager can automate remediation actions for noncompliant resources.

3. Why use AWS Config?

Business reasons

  • Reduce audit effort by having configuration history and compliance evidence available on demand.
  • Lower risk of outages caused by unintended infrastructure changes.
  • Standardize governance across teams and accounts with centrally defined rules and conformance packs.
  • Improve accountability: change history and compliance status support internal controls and reporting.

Technical reasons

  • Track configuration drift from infrastructure-as-code baselines.
  • Detect unintended changes across compute, networking, storage, IAM-related configurations (where supported).
  • Build automated guardrails: continuous evaluation and auto-remediation patterns.
  • Enable incident investigations: resource timelines help correlate changes with incidents.

Operational reasons

  • Continuous visibility rather than periodic manual checks.
  • Event-driven operations: react to compliance changes via SNS/EventBridge.
  • Central reporting: aggregators provide one-pane views across environments.

Security/compliance reasons

  • Prove compliance for common policies (encryption enabled, public access blocked, MFA enabled, restricted security groups, etc.), using AWS managed rules or custom rules.
  • Detect risky changes quickly (for example, an S3 bucket becoming public).
  • Support frameworks via conformance packs (AWS provides sample packs; verify availability and suitability in official docs).

Scalability/performance reasons

  • AWS Config scales with your environment without you managing collectors.
  • Data is delivered to S3 and can be queried and integrated into data/analytics pipelines if needed.

When teams should choose AWS Config

Choose AWS Config when you need any of the following: – Reliable configuration history for supported AWS resources – Continuous compliance evaluation across accounts/Regions – Governance automation and evidence for audits – A standardized way to express “resource configuration requirements” as rules

When teams should not choose AWS Config

AWS Config is not the right tool when: – You only need API audit logs (use AWS CloudTrail). – You need vulnerability scanning (use Amazon Inspector or other security scanners). – You need real-time performance monitoring (use Amazon CloudWatch, AWS X-Ray, etc.). – Your environment is extremely cost-sensitive and you only need a narrow set of checks—consider enabling AWS Config for a limited scope, or using IaC checks in CI/CD plus periodic targeted audits. – You need to manage/patch instances (use AWS Systems Manager).

4. Where is AWS Config used?

Industries

AWS Config is widely used in regulated and security-conscious environments, including: – Finance and fintech – Healthcare and life sciences – Government and public sector – SaaS providers (SOC 2 / ISO 27001 programs) – Retail and e-commerce (security and change governance)

Team types

  • Cloud platform engineering teams implementing governance guardrails
  • Security engineering / cloud security teams monitoring posture
  • DevOps / SRE teams investigating configuration drift and incidents
  • Compliance and audit teams generating evidence
  • IT operations teams managing change control processes

Workloads and architectures

  • Multi-account AWS Organizations architectures (prod/dev/shared services/security)
  • Microservices platforms (EKS/ECS/Lambda) where supporting infrastructure needs policy checks
  • Data platforms (S3, KMS, IAM, Lake Formation-related governance—where supported)
  • Network-heavy environments (VPC, security groups, NACLs, route tables—where supported)

Real-world deployment contexts

  • Central governance account aggregates Config data from workload accounts.
  • Organization conformance packs enforce baseline controls across accounts.
  • EventBridge triggers remediation or ticketing when a resource becomes noncompliant.

Production vs dev/test usage

  • Production: Typically enabled broadly, with centralized aggregation and carefully designed rules to avoid noise.
  • Dev/test: Often enabled with fewer rules or limited resource recording to control costs, while still providing drift visibility.

5. Top Use Cases and Scenarios

Below are realistic scenarios where AWS Config is commonly applied.

1) Detect and alert on public S3 buckets

  • Problem: Buckets accidentally become public due to policy or ACL changes.
  • Why AWS Config fits: Records S3 bucket configuration changes and evaluates against managed rules.
  • Example scenario: A developer applies a bucket policy allowing s3:GetObject to Principal: *. AWS Config flags noncompliance and triggers an EventBridge rule to notify security.

2) Enforce encryption-at-rest standards

  • Problem: Some storage resources are created without encryption.
  • Why AWS Config fits: Managed rules can detect encryption settings across supported services.
  • Example scenario: A new EBS volume is created without encryption (where relevant). AWS Config rule detects noncompliance; Systems Manager Automation remediates by snapshot + re-create (remediation feasibility depends on resource type—verify in docs).

3) Track security group exposure (0.0.0.0/0)

  • Problem: Inbound access from the internet is unintentionally opened.
  • Why AWS Config fits: Records security group changes and evaluates ingress rules.
  • Example scenario: Port 22 is opened to 0.0.0.0/0. AWS Config flags it; a Lambda-based custom rule checks exception tags and escalates if missing.

4) Required tags enforcement (cost allocation, ownership)

  • Problem: Resources lack required tags, making cost allocation and ownership unclear.
  • Why AWS Config fits: Managed rule patterns can require tags and report noncompliance.
  • Example scenario: New S3 buckets must have Owner and CostCenter. AWS Config rule flags missing tags and routes a notification to the owning team.

5) Change investigation and incident correlation

  • Problem: Service outage occurs; you need to know what infrastructure changed.
  • Why AWS Config fits: Resource timeline shows configuration changes over time.
  • Example scenario: An application loses connectivity to a database. AWS Config timeline shows a NACL change 10 minutes before the incident.

6) Drift detection from IaC standards

  • Problem: Infrastructure created by Terraform/CloudFormation drifts due to console edits.
  • Why AWS Config fits: Tracks changes outside your IaC pipelines.
  • Example scenario: Someone manually modifies an IAM role trust policy. AWS Config records the delta and can trigger a workflow to revert via IaC.

7) Multi-account compliance reporting for auditors

  • Problem: Auditors require evidence of controls across all accounts and Regions.
  • Why AWS Config fits: Aggregators provide centralized views of compliance status.
  • Example scenario: Security team generates compliance reports across 50 accounts using an aggregator and exports evidence from S3 snapshots.

8) Continuous compliance baselines with conformance packs

  • Problem: Managing dozens of rules individually becomes hard.
  • Why AWS Config fits: Conformance packs package rules and (optionally) remediation settings.
  • Example scenario: The platform team deploys a baseline conformance pack to all accounts, ensuring consistent enforcement.

9) Automated remediation for common misconfigurations

  • Problem: Teams repeatedly make the same configuration mistakes.
  • Why AWS Config fits: Integrates with Systems Manager Automation runbooks for remediation (where supported).
  • Example scenario: If an S3 bucket has public access settings disabled, automatically apply a remediation that blocks public access (verify supported remediation actions for the specific rule/resource).

10) Governance for ephemeral environments

  • Problem: Short-lived environments are created and destroyed; governance must keep up.
  • Why AWS Config fits: Continuous recording catches changes during the environment lifecycle.
  • Example scenario: A preview environment creates many security groups. AWS Config ensures no security group becomes internet-open without an exception tag.

11) Proving control effectiveness over time

  • Problem: You must show that controls were consistently enforced, not just at audit time.
  • Why AWS Config fits: Maintains historical compliance evaluation results and configuration history (retention details vary—verify current retention behavior in official docs).
  • Example scenario: Quarterly audit requires proof that encryption controls were continuously monitored.

12) Centralized governance in AWS Organizations

  • Problem: Business units manage their own accounts; central governance needs guardrails.
  • Why AWS Config fits: Organization-level deployment patterns and aggregation enable centralized policy with distributed execution.
  • Example scenario: Security account deploys organization conformance packs and aggregates compliance results for executive reporting.

6. Core Features

This section focuses on important AWS Config capabilities used in real environments.

6.1 Configuration recording (configuration items)

  • What it does: Records configuration changes for supported resource types in a Region.
  • Why it matters: Without recording, you can’t reconstruct historical configuration state.
  • Practical benefit: Enables timelines, drift investigations, and compliance evaluation.
  • Limitations/caveats:
  • Not all AWS resource types are supported; check the official “supported resource types” list.
  • Recording can increase costs if you record many resource types across many accounts/Regions.

6.2 Configuration history and timeline

  • What it does: Provides change history per resource (what changed and when).
  • Why it matters: Root cause analysis often requires knowing exactly what changed.
  • Practical benefit: Faster incident investigation and reduced mean time to recovery (MTTR).
  • Limitations/caveats: Timeline fidelity depends on supported properties and recording settings.

6.3 Configuration snapshots

  • What it does: Produces point-in-time exports of configuration for recorded resources, delivered to S3.
  • Why it matters: Snapshots are useful for audits and offline analysis.
  • Practical benefit: Repeatable evidence capture for compliance programs.
  • Limitations/caveats: Snapshots and stored objects can increase S3 storage costs.

6.4 Configuration change notifications (SNS / EventBridge)

  • What it does: Sends notifications when resources change configuration and when compliance status changes.
  • Why it matters: Enables event-driven workflows (alerting, ticketing, remediation).
  • Practical benefit: Integrate with existing operations tooling.
  • Limitations/caveats: Notifications can be noisy if scope is broad and environments are highly dynamic—filtering and tuning is important.

6.5 AWS Config Rules (managed and custom)

  • What it does: Evaluates resources against desired configuration settings.
  • Why it matters: Provides continuous compliance rather than periodic checks.
  • Practical benefit: Detects misconfigurations early.
  • Limitations/caveats:
  • Some managed rules apply only to specific resource types or Regions.
  • Custom rules typically require a Lambda function (and its operational lifecycle).

6.6 Conformance Packs

  • What it does: Deploys a collection of rules and optional remediation settings as a single unit.
  • Why it matters: Governance at scale requires packaging, versioning, and repeatability.
  • Practical benefit: Standard baselines across accounts/Regions.
  • Limitations/caveats: Conformance packs still evaluate underlying rules; cost scales with evaluations and scope.

6.7 Remediation actions (commonly via Systems Manager Automation)

  • What it does: Automates fixes for certain noncompliant findings using AWS-managed or custom remediation documents.
  • Why it matters: Reduces manual effort and speeds up risk reduction.
  • Practical benefit: “Detect and fix” loops for common misconfigurations.
  • Limitations/caveats:
  • Not every rule/resource supports automatic remediation.
  • Remediation can be risky if applied blindly; approvals and guardrails matter.

6.8 Multi-account and multi-Region aggregation

  • What it does: Collects configuration and compliance data across accounts and Regions into a central aggregator.
  • Why it matters: Enterprise AWS usage is typically multi-account.
  • Practical benefit: Single place to query and report compliance posture.
  • Limitations/caveats: Cross-account permissions and AWS Organizations setup must be correct.

6.9 Advanced queries

  • What it does: Lets you query recorded resource configuration state using a SQL-like query language (AWS Config query).
  • Why it matters: Faster ad-hoc investigations and reporting without exporting data.
  • Practical benefit: Identify patterns (e.g., untagged resources, security group rules, encryption settings) quickly.
  • Limitations/caveats: Query coverage depends on what AWS Config records and how resource properties are modeled.

6.10 Integration with AWS Organizations

  • What it does: Enables governance patterns across organizational units (OUs) and accounts, including delegated administration and organization-level deployments (capabilities vary—verify current organization-level features in docs).
  • Why it matters: Central governance without manually configuring every account.
  • Practical benefit: Consistent compliance posture across the org.
  • Limitations/caveats: Requires correct Organizations setup and careful permission design.

7. Architecture and How It Works

High-level architecture

At a high level:

  1. You enable AWS Config in a Region.
  2. The configuration recorder discovers and records supported resources as configuration items.
  3. AWS Config delivers configuration items and snapshots to an S3 bucket (and optionally publishes to SNS).
  4. AWS Config Rules evaluate resources and store compliance results.
  5. Events can flow to EventBridge and/or notifications to SNS for automation and alerting.
  6. In multi-account setups, a configuration aggregator centralizes data for reporting and queries.

Request/data/control flow

  • Data plane (recording): AWS Config observes resource configuration state and changes (implementation is managed by AWS).
  • Control plane (your actions): You configure recorders, delivery channels, rules, conformance packs, remediation, aggregators, and permissions.
  • Storage: Configuration history and snapshots are delivered to S3; compliance results are available via the AWS Config console and APIs.

Integrations with related services

Common integrations include: – Amazon S3: required destination for configuration history and snapshots. – Amazon SNS: optional notifications for configuration changes and evaluation results. – Amazon EventBridge: receive AWS Config events for workflows. – AWS Lambda: custom rules (and sometimes custom remediation). – AWS Systems Manager: remediation actions via Automation runbooks. – AWS Organizations: centralized governance, aggregation, and org-wide deployment patterns. – AWS CloudTrail: correlate “who changed” (CloudTrail) with “what changed” (Config). – AWS Security Hub: posture management and findings aggregation (integration patterns vary; verify in official docs for your region and use case).

Dependency services

Minimum dependencies to run AWS Config in a Region: – An S3 bucket for delivery (in the same account, typically). – An IAM role for AWS Config (often a service-linked role).

Security/authentication model

  • AWS Config uses IAM to assume a role to access S3 and publish to SNS.
  • Access to AWS Config APIs and console is controlled by IAM policies.
  • Cross-account aggregation requires explicit authorization (often via Organizations-managed authorization or aggregator permissions).

Networking model

  • AWS Config is an AWS-managed service accessed via AWS APIs.
  • If you need private connectivity from VPC-only networks, investigate VPC endpoints (AWS PrivateLink) availability for AWS Config in your Regions. Availability can vary—verify in official docs:
  • VPC endpoints overview: https://docs.aws.amazon.com/vpc/latest/privatelink/what-is-privatelink.html

Monitoring/logging/governance considerations

  • CloudTrail logs AWS Config API calls (who created rules, changed recorders, etc.).
  • CloudWatch can be used to monitor related automation (Lambda, Systems Manager).
  • AWS Config itself becomes part of your governance baseline—treat its configuration as critical infrastructure (IaC, version control, change management).

Simple architecture diagram

flowchart LR
  R[AWS Resources\n(EC2, S3, SGs, etc.)] --> CR[AWS Config\nConfiguration Recorder]
  CR --> S3[(Amazon S3\nConfig bucket)]
  CR --> SNS[(Amazon SNS\noptional notifications)]
  CR --> RULES[AWS Config Rules\nManaged/Custom]
  RULES --> COMPLIANCE[Compliance Results\nConsole/API]

Production-style architecture diagram (multi-account)

flowchart TB
  subgraph Org[AWS Organizations]
    subgraph Sec[Security / Governance Account]
      AGG[AWS Config Aggregator]
      S3C[(Central S3 bucket\n(optional for reports/artifacts))]
      SH[AWS Security Hub\n(optional)]
      EB[Amazon EventBridge\nRules]
      ITSM[Ticketing/ChatOps\n(optional)]
    end

    subgraph Prod[Production Account(s)]
      CRP[AWS Config Recorder]
      DC1[Delivery Channel]
      S3P[(S3 bucket for Config delivery)]
      RULESP[AWS Config Rules\n+ Conformance Packs]
      SSM[AWS Systems Manager\nAutomation Remediation]
    end

    subgraph Dev[Dev/Test Account(s)]
      CRD[AWS Config Recorder]
      S3D[(S3 bucket)]
      RULESD[Rules tuned for dev]
    end
  end

  CRP --> DC1 --> S3P
  CRP --> RULESP
  RULESP --> EB
  EB --> ITSM
  RULESP --> SSM

  CRD --> S3D
  CRP --> AGG
  CRD --> AGG
  AGG --> SH
  AGG --> S3C

8. Prerequisites

AWS account requirements

  • An AWS account with billing enabled.
  • If doing multi-account governance: AWS Organizations set up (optional for this lab).

Permissions / IAM roles

You need permissions to: – Create or manage AWS Config components: recorders, delivery channels, rules. – Create and manage S3 bucket and bucket policy. – Create service-linked role (recommended) or IAM role for AWS Config. – Optional: SNS topic and policy.

A practical set of permissions for the lab: – config:* (or at minimum: config:PutConfigurationRecorder, config:PutDeliveryChannel, config:StartConfigurationRecorder, config:PutConfigRule, config:Describe*, config:Get*, config:Delete*) – s3:CreateBucket, s3:PutBucketPolicy, s3:PutEncryptionConfiguration, s3:PutBucketPublicAccessBlock, s3:ListBucket, s3:DeleteObject, s3:DeleteBucket – iam:CreateServiceLinkedRole (if creating service-linked role) – Optional sns:* for topic setup

Billing requirements

AWS Config is a paid service (usage-based). Even small labs can incur charges if left running.

Tools

  • AWS Management Console (optional, but helpful)
  • AWS CLI v2 recommended:
  • Install: https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html
  • jq is helpful for formatting outputs (optional)

Region availability

AWS Config is available in many AWS Regions, but not necessarily all. Verify availability for your target Region in AWS Regional Services list: – https://aws.amazon.com/about-aws/global-infrastructure/regional-product-services/

Quotas / limits

AWS Config has service quotas (for example, number of rules, conformance packs, recorders). Check Service Quotas for AWS Config in your account/Region: – https://docs.aws.amazon.com/servicequotas/latest/userguide/intro.html

Prerequisite services

  • Amazon S3 (for delivery channel)
  • IAM (role/service-linked role)
  • Optional: SNS, EventBridge, Lambda, Systems Manager (for more advanced patterns)

9. Pricing / Cost

AWS Config pricing is usage-based and varies by Region. Do not rely on fixed numbers from third-party sources; always confirm in the official pricing page.

Official pricing: – https://aws.amazon.com/config/pricing/ – AWS Pricing Calculator: https://calculator.aws/#/

Pricing dimensions (how you get charged)

AWS Config costs typically come from:

  1. Configuration items recorded – Each recorded configuration item can generate charges. – The number depends on how many resources you record and how frequently they change.

  2. Rule evaluations – AWS Config Rules evaluate resources (periodically and/or on change, depending on rule type and configuration). – Costs scale with number of rules * number of resources evaluated * evaluation frequency.

  3. Conformance packs – Conformance packs are collections of rules. Cost is generally tied to the evaluations of the included rules (verify exact billing behavior on the pricing page).

  4. Optional delivery and storage – S3 storage for configuration history and snapshots. – SNS message delivery costs if you use notifications. – KMS costs if you use SSE-KMS encryption for S3/SNS. – Data transfer costs are usually minimal for in-region delivery to S3, but cross-region/cross-account patterns can introduce additional costs—verify based on your architecture.

Free tier

AWS Config has historically not had a broad free tier like some services; any free tier or limited trial offers can change. Verify current free-tier status on the pricing page.

Cost drivers (what makes bills go up)

  • Enabling AWS Config in many Regions.
  • Recording all supported resource types in accounts with many resources.
  • High-change environments (autoscaling, CI/CD-driven infra changes).
  • Large numbers of rules and conformance pack rules.
  • Frequent periodic evaluations.

Hidden or indirect costs

  • S3 bucket growth over time (snapshots and continuous delivery).
  • KMS request costs if encrypting at rest with customer-managed keys.
  • Lambda costs for custom rules and remediation.
  • Systems Manager Automation execution costs (if applicable to your remediations).
  • Operational overhead: rule tuning, exception handling, governance workflows.

Network/data transfer implications

  • In many setups, Config delivers to S3 in the same account and Region—data transfer costs are typically low.
  • If you centralize delivery across Regions or accounts, review S3 and inter-region data transfer pricing.

How to optimize cost

  • Record only the resource types you need (instead of “all supported”) where feasible.
  • Start with a small set of high-value rules and expand gradually.
  • Prefer change-triggered evaluations where appropriate to reduce periodic evaluation volume (depends on rule type).
  • Use aggregation for visibility, but keep delivery/storage strategy intentional.
  • Implement lifecycle policies for the S3 bucket where appropriate (ensure it meets audit retention needs).

Example low-cost starter estimate (how to think about it)

A low-cost approach typically looks like: – Enable AWS Config in one Region. – Record a limited set of resource types (for example, S3 buckets only). – Deploy 1–3 managed rules (tagging, public access, encryption). – Avoid custom rules until needed.

To estimate accurately: – Use the AWS Pricing Calculator and model configuration items and rule evaluations. – Validate with a short trial in a non-production account and observe usage metrics.

Example production cost considerations

In production, costs usually reflect: – Multiple accounts and Regions. – Broad recording scopes. – Many rules and conformance packs. – Remediation and event-driven automation. – Long-term S3 retention.

A realistic enterprise cost model should be reviewed quarterly and aligned to governance outcomes (which rules provide value, what noise can be reduced).

10. Step-by-Step Hands-On Tutorial

Objective

Enable AWS Config in one AWS Region with a minimal scope, deliver configuration history to an S3 bucket, and create a managed AWS Config rule to enforce required tags on S3 buckets.

Lab Overview

You will: 1. Create an S3 bucket to store AWS Config data (securely). 2. Create (or ensure) the AWS Config service-linked role exists. 3. Create an AWS Config configuration recorder and delivery channel using AWS CLI. 4. Start the recorder and verify configuration items are being delivered. 5. Add a managed AWS Config rule (required-tags) to check required tags on S3 buckets. 6. Create a test S3 bucket without required tags to observe noncompliance, then fix it. 7. Clean up to stop charges.

This lab is designed to be low-cost by recording only S3 buckets in a single Region, but charges may still apply. Don’t leave AWS Config running unintentionally.

Step 1: Set environment variables and verify AWS CLI identity

Choose a Region where you want to run the lab (example: us-east-1).

export AWS_REGION="us-east-1"
export AWS_ACCOUNT_ID="$(aws sts get-caller-identity --query Account --output text)"
aws sts get-caller-identity

Expected outcome: You see your account ID, ARN, and user/role in the output.

Step 2: Create an S3 bucket for AWS Config delivery (secure baseline)

Pick a globally unique bucket name.

export CONFIG_BUCKET="my-aws-config-delivery-${AWS_ACCOUNT_ID}-${AWS_REGION}"
aws s3api create-bucket \
  --bucket "${CONFIG_BUCKET}" \
  --region "${AWS_REGION}" \
  $( [ "${AWS_REGION}" = "us-east-1" ] && echo "" || echo "--create-bucket-configuration LocationConstraint=${AWS_REGION}" )

Enable bucket versioning (recommended for audit artifacts):

aws s3api put-bucket-versioning \
  --bucket "${CONFIG_BUCKET}" \
  --versioning-configuration Status=Enabled

Enable default encryption (SSE-S3). For SSE-KMS, verify the required KMS permissions and key policy.

aws s3api put-bucket-encryption \
  --bucket "${CONFIG_BUCKET}" \
  --server-side-encryption-configuration '{
    "Rules": [
      {
        "ApplyServerSideEncryptionByDefault": {
          "SSEAlgorithm": "AES256"
        }
      }
    ]
  }'

Block public access:

aws s3api put-public-access-block \
  --bucket "${CONFIG_BUCKET}" \
  --public-access-block-configuration '{
    "BlockPublicAcls": true,
    "IgnorePublicAcls": true,
    "BlockPublicPolicy": true,
    "RestrictPublicBuckets": true
  }'

Expected outcome: The bucket exists, is encrypted, versioned, and not publicly accessible.

Step 3: Add the S3 bucket policy that allows AWS Config to write

AWS Config needs permissions to: – Get bucket ACL – List bucket (for prefix checks) – Put objects into the AWS Config prefix with the correct ACL

Apply a bucket policy (adjust if your organization uses stricter controls). This pattern follows AWS’s typical recommended policy structure; verify the latest recommended policy in official docs for AWS Config S3 delivery.

cat > /tmp/aws-config-bucket-policy.json <<EOF
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AWSConfigBucketPermissionsCheck",
      "Effect": "Allow",
      "Principal": { "Service": "config.amazonaws.com" },
      "Action": "s3:GetBucketAcl",
      "Resource": "arn:aws:s3:::${CONFIG_BUCKET}"
    },
    {
      "Sid": "AWSConfigBucketExistenceCheck",
      "Effect": "Allow",
      "Principal": { "Service": "config.amazonaws.com" },
      "Action": "s3:ListBucket",
      "Resource": "arn:aws:s3:::${CONFIG_BUCKET}"
    },
    {
      "Sid": "AWSConfigBucketDelivery",
      "Effect": "Allow",
      "Principal": { "Service": "config.amazonaws.com" },
      "Action": "s3:PutObject",
      "Resource": "arn:aws:s3:::${CONFIG_BUCKET}/AWSLogs/${AWS_ACCOUNT_ID}/Config/*",
      "Condition": {
        "StringEquals": {
          "s3:x-amz-acl": "bucket-owner-full-control"
        }
      }
    }
  ]
}
EOF

aws s3api put-bucket-policy \
  --bucket "${CONFIG_BUCKET}" \
  --policy file:///tmp/aws-config-bucket-policy.json

Expected outcome: Bucket policy is applied successfully.

Step 4: Create (or verify) the AWS Config service-linked role

AWS Config commonly uses a service-linked role named AWSServiceRoleForConfig.

Try creating it (if it already exists, AWS will return an error you can safely ignore).

aws iam create-service-linked-role --aws-service-name config.amazonaws.com

If you get an “already exists” error, proceed.

Expected outcome: Service-linked role exists for AWS Config.

Step 5: Create the delivery channel

A delivery channel tells AWS Config where to deliver data (S3 is required; SNS is optional).

Create a delivery channel named default (or another name). Many setups use default, but naming is up to you.

cat > /tmp/aws-config-delivery-channel.json <<EOF
{
  "name": "default",
  "s3BucketName": "${CONFIG_BUCKET}",
  "s3KeyPrefix": "config"
}
EOF

aws configservice put-delivery-channel \
  --delivery-channel file:///tmp/aws-config-delivery-channel.json \
  --region "${AWS_REGION}"

Expected outcome: Delivery channel is created.

Step 6: Create the configuration recorder (record only S3 buckets)

To keep cost and noise low, record a narrow set of resource types. Here we record only S3 buckets.

cat > /tmp/aws-config-recorder.json <<EOF
{
  "name": "default",
  "roleARN": "arn:aws:iam::${AWS_ACCOUNT_ID}:role/aws-service-role/config.amazonaws.com/AWSServiceRoleForConfig",
  "recordingGroup": {
    "allSupported": false,
    "includeGlobalResourceTypes": false,
    "resourceTypes": ["AWS::S3::Bucket"]
  }
}
EOF

aws configservice put-configuration-recorder \
  --configuration-recorder file:///tmp/aws-config-recorder.json \
  --region "${AWS_REGION}"

Expected outcome: Recorder is created/updated.

Step 7: Start the configuration recorder

aws configservice start-configuration-recorder \
  --configuration-recorder-name default \
  --region "${AWS_REGION}"

Expected outcome: Recorder starts successfully.

Step 8: Verify AWS Config is running and delivering data

Check recorder status:

aws configservice describe-configuration-recorder-status \
  --region "${AWS_REGION}"

Look for: – recording: true – lastStatus: SUCCESS (or similar)

Check that objects are appearing in S3 (may take several minutes):

aws s3 ls "s3://${CONFIG_BUCKET}/" --recursive | head

Expected outcome: You see AWS Config delivery objects under a prefix like: AWSLogs/<account-id>/Config/<region>/... and/or your s3KeyPrefix.

If you see nothing, wait 5–10 minutes and retry, especially right after first enablement.

Step 9: Create a managed AWS Config rule for required tags on S3 buckets

We’ll use the managed rule required-tags and require two tags: Owner and CostCenter.

cat > /tmp/aws-config-rule-required-tags.json <<EOF
{
  "ConfigRuleName": "s3-required-tags",
  "Description": "Require Owner and CostCenter tags on S3 buckets",
  "Scope": {
    "ComplianceResourceTypes": ["AWS::S3::Bucket"]
  },
  "Source": {
    "Owner": "AWS",
    "SourceIdentifier": "REQUIRED_TAGS"
  },
  "InputParameters": "{ \"tag1Key\": \"Owner\", \"tag2Key\": \"CostCenter\" }"
}
EOF

aws configservice put-config-rule \
  --config-rule file:///tmp/aws-config-rule-required-tags.json \
  --region "${AWS_REGION}"

Expected outcome: The rule is created. Evaluation can take a few minutes.

Step 10: Create a test S3 bucket without tags and observe noncompliance

Create a new bucket:

export TEST_BUCKET="aws-config-tag-test-${AWS_ACCOUNT_ID}-${AWS_REGION}"
aws s3api create-bucket \
  --bucket "${TEST_BUCKET}" \
  --region "${AWS_REGION}" \
  $( [ "${AWS_REGION}" = "us-east-1" ] && echo "" || echo "--create-bucket-configuration LocationConstraint=${AWS_REGION}" )

Wait a few minutes, then check compliance for the rule:

aws configservice get-compliance-details-by-config-rule \
  --config-rule-name "s3-required-tags" \
  --compliance-types NON_COMPLIANT \
  --region "${AWS_REGION}"

Expected outcome: The new bucket should appear as NON_COMPLIANT (after AWS Config records it and the rule evaluates it).

If it doesn’t show up yet: – Wait a few more minutes – Re-run the compliance query – Optionally trigger re-evaluation (not always necessary)

You can also check overall rule compliance summary:

aws configservice describe-compliance-by-config-rule \
  --config-rule-names "s3-required-tags" \
  --region "${AWS_REGION}"

Step 11: Fix the bucket by applying required tags

Add the required tags:

aws s3api put-bucket-tagging \
  --bucket "${TEST_BUCKET}" \
  --tagging 'TagSet=[{Key=Owner,Value=PlatformTeam},{Key=CostCenter,Value=CC-1234}]' \
  --region "${AWS_REGION}"

Wait for re-evaluation (or trigger it).

Trigger an on-demand evaluation:

aws configservice start-config-rules-evaluation \
  --config-rule-names "s3-required-tags" \
  --region "${AWS_REGION}"

Now query compliant resources:

aws configservice get-compliance-details-by-config-rule \
  --config-rule-name "s3-required-tags" \
  --compliance-types COMPLIANT \
  --region "${AWS_REGION}"

Expected outcome: The test bucket becomes COMPLIANT.

Validation

Use this checklist:

  1. Recorder status shows recording: true: bash aws configservice describe-configuration-recorder-status --region "${AWS_REGION}"

  2. S3 bucket contains AWS Config objects: bash aws s3 ls "s3://${CONFIG_BUCKET}/" --recursive | head -n 20

  3. Rule exists and returns evaluations: bash aws configservice describe-config-rules --config-rule-names "s3-required-tags" --region "${AWS_REGION}" aws configservice describe-compliance-by-config-rule --config-rule-names "s3-required-tags" --region "${AWS_REGION}"

  4. Test bucket compliance changes after tagging.

Troubleshooting

Common issues and fixes:

  1. InsufficientDeliveryPolicyException or delivery failures – Cause: S3 bucket policy is missing or incorrect. – Fix: Re-check the bucket policy statements and the resource ARN paths. Confirm the bucket is in the same account and the policy allows config.amazonaws.com.

  2. Recorder won’t start (NoAvailableDeliveryChannelException) – Cause: You attempted to start the recorder before creating the delivery channel. – Fix: Create delivery channel first, then start the recorder.

  3. No objects appear in S3 – Cause: Initial delivery can take time; or resource scope is too narrow and there are no matching resources. – Fix: Wait 5–15 minutes; create a resource of the recorded type (we created an S3 bucket); verify recorder status is SUCCESS.

  4. Rule shows INSUFFICIENT_DATA – Cause: AWS Config hasn’t recorded the resource yet, or rule evaluation hasn’t run. – Fix: Wait; trigger evaluation with start-config-rules-evaluation.

  5. Access denied creating service-linked role – Cause: Missing iam:CreateServiceLinkedRole. – Fix: Use an admin role, or have your IAM admins create the role.

Cleanup

To avoid ongoing charges, remove the rule and stop AWS Config.

  1. Delete the AWS Config rule: bash aws configservice delete-config-rule \ --config-rule-name "s3-required-tags" \ --region "${AWS_REGION}"

  2. Stop the recorder: bash aws configservice stop-configuration-recorder \ --configuration-recorder-name default \ --region "${AWS_REGION}"

  3. Delete delivery channel (must delete before recorder in many cases): bash aws configservice delete-delivery-channel \ --delivery-channel-name default \ --region "${AWS_REGION}"

  4. Delete configuration recorder: bash aws configservice delete-configuration-recorder \ --configuration-recorder-name default \ --region "${AWS_REGION}"

  5. Delete test bucket (must be empty first): bash aws s3 rm "s3://${TEST_BUCKET}" --recursive aws s3api delete-bucket --bucket "${TEST_BUCKET}" --region "${AWS_REGION}"

  6. Delete Config delivery bucket content and bucket: bash aws s3 rm "s3://${CONFIG_BUCKET}" --recursive aws s3api delete-bucket --bucket "${CONFIG_BUCKET}" --region "${AWS_REGION}"

  7. Optional: Keep the service-linked role (recommended in many orgs). If you must remove it, verify no other Region/account usage depends on it.

11. Best Practices

Architecture best practices

  • Use a multi-account strategy: separate workload accounts from a central security/governance account.
  • Aggregate centrally using AWS Config aggregators for cross-account visibility.
  • Standardize baselines with conformance packs (version them and roll out progressively).
  • Design for exceptions: define how teams request exceptions (tags, parameter store allowlists, separate OUs, or rule logic).

IAM/security best practices

  • Prefer service-linked role unless you have strict custom requirements.
  • Use least privilege for operators who manage rules vs. those who only view compliance.
  • Protect S3 delivery bucket:
  • Block public access
  • Enforce encryption
  • Restrict bucket policy to AWS Config service principal and your account
  • Use SSE-KMS where required, but ensure KMS key policy allows AWS Config and operational users appropriately.

Cost best practices

  • Record only what you need (resource types) especially in dev/test.
  • Limit the number of rules to those that directly support risk reduction or audit requirements.
  • Prefer managed rules when they meet requirements (less custom code to run and maintain).
  • Use S3 lifecycle policies carefully (align with audit retention policies first).

Performance best practices

  • Avoid overly chatty automation triggered by every compliance event; filter by severity and environment.
  • Tune periodic evaluations—use change-triggered where appropriate.

Reliability best practices

  • Treat AWS Config setup as foundational governance:
  • Deploy via Infrastructure as Code (CloudFormation/Terraform/CDK).
  • Use CI/CD to version rules and conformance packs.
  • Use alarms/notifications on recorder status failures (you can build operational checks around AWS Config APIs and EventBridge events).

Operations best practices

  • Establish a process for:
  • Rule lifecycle (create → test → deploy → tune → retire)
  • Handling false positives
  • Managing remediation approvals and rollbacks
  • Use consistent naming:
  • Rule names: env-domain-control (e.g., prod-s3-public-access-blocked)
  • Conformance packs: baseline-security-v1
  • Tag governance resources too (S3 buckets, SNS topics, automation functions).

Governance/tagging/naming best practices

  • Define required tags and enforce them via AWS Config plus IaC checks.
  • Use AWS Organizations OUs to separate environments and apply different baselines per OU.

12. Security Considerations

Identity and access model

  • AWS Config service role: AWS Config assumes a role to deliver to S3/SNS and to evaluate resources.
  • User/automation access: Controlled by IAM policies for AWS Config APIs:
  • Read-only roles for auditors
  • Admin roles for governance/platform team
  • Cross-account: Aggregators and organization deployments require explicit trust and authorizations.

Encryption

  • S3 delivery bucket encryption: Use SSE-S3 or SSE-KMS depending on requirements.
  • SNS encryption (if used): Consider SSE-KMS for SNS topics where mandated.
  • In transit: AWS service APIs use TLS.

Network exposure

  • AWS Config is managed and accessed via AWS APIs; your main exposure considerations are:
  • Who can call AWS Config APIs
  • Who can read the S3 delivered data
  • Consider VPC endpoints if your environment restricts internet egress; verify AWS Config endpoint support in your Regions.

Secrets handling

  • AWS Config itself doesn’t require you to store secrets.
  • Custom rules/remediation (Lambda, SSM) might—use AWS Secrets Manager or SSM Parameter Store for secrets rather than embedding secrets in code.

Audit/logging

  • Enable AWS CloudTrail organization trails to log AWS Config API calls.
  • Log and monitor changes to:
  • Recorder settings
  • Delivery channel destinations
  • Rules and conformance packs
  • Remediation configurations
  • Consider a “governance change approval” workflow for modifications to AWS Config baselines.

Compliance considerations

  • Map rules/conformance packs to your control framework (CIS, NIST, ISO, SOC 2).
  • Maintain evidence:
  • S3 snapshots and delivered history
  • Compliance reports from aggregators
  • Ensure retention meets policy (S3 lifecycle must not delete evidence prematurely).

Common security mistakes

  • Delivering to an S3 bucket without blocking public access.
  • Allowing broad IAM permissions to disable AWS Config or delete rules.
  • Auto-remediating production resources without guardrails/approvals.
  • Not enabling AWS Config in critical Regions (governance blind spots).

Secure deployment recommendations

  • Use a dedicated, locked-down S3 bucket for delivery with strict bucket policy.
  • Use AWS Organizations and delegated admin to centralize governance.
  • Deploy and manage AWS Config settings using IaC and change control.

13. Limitations and Gotchas

Known limitations / boundaries

  • AWS Config only records supported resource types and only the properties it is designed to track.
  • Some resources are global or have special recording considerations.
  • Rule evaluation timing is not always immediate; expect eventual consistency.

Quotas

  • Quotas exist for rules, conformance packs, aggregators, and more. Values can change.
  • Always check Service Quotas in your account/Region for AWS Config.

Regional constraints

  • Not all Regions may support every AWS Config capability equally.
  • Verify feature availability (for example, specific managed rules, remediation actions, organization features) in official docs for your Regions.

Pricing surprises

  • Recording “all supported resource types” across many Regions can generate significant configuration items.
  • Periodic rules across many resources can generate high evaluation counts.
  • S3 storage and KMS usage can grow quietly over time.

Compatibility issues

  • Custom rules require maintaining Lambda runtime compatibility and permissions.
  • Remediation actions can fail if IAM permissions or resource constraints prevent changes.

Operational gotchas

  • You must create a delivery channel before starting the recorder.
  • Deleting AWS Config components has dependencies (stop recorder, delete delivery channel, etc.).
  • High-volume environments can generate many notifications; plan filtering and routing.

Migration challenges

  • If migrating from ad-hoc scripts or third-party tooling, the main work is:
  • Defining rule intent
  • Handling exceptions
  • Mapping policies to managed rules or building custom rules
  • Managing rollout without breaking teams

Vendor-specific nuances

  • AWS Config is AWS-native and integrates deeply with AWS services; cross-cloud governance requires additional tooling (see comparisons).

14. Comparison with Alternatives

AWS Config is best compared with services that provide governance, compliance checks, and configuration tracking.

Comparison table

Option Best For Strengths Weaknesses When to Choose
AWS Config AWS resource configuration history + compliance Native AWS integration; config timeline; managed/custom rules; conformance packs; aggregators Cost can grow at scale; only supported resource types; eventual consistency You need continuous compliance + config history in AWS
AWS CloudTrail API activity auditing (“who did what”) Strong audit trail; forensic detail; integrates with detection tooling Not a configuration state database; doesn’t directly evaluate compliance Use alongside Config for investigations and audit
AWS Security Hub Security posture management and findings aggregation Centralizes findings across services; compliance standards views Depends on other data sources; not a full config history system Use for security reporting; pair with Config for governance controls
AWS Systems Manager Ops management + automation Remediation automation; patching; inventory; runbooks Not a compliance evaluator by itself Use for remediation actions triggered by Config
Azure Policy (Microsoft Azure) Azure governance and compliance Strong policy-as-code, enforcement modes Azure-specific Multi-cloud orgs: use Azure Policy in Azure; use Config in AWS
Google Cloud Organization Policy / Cloud Asset Inventory GCP governance and asset inventory Org-level constraints; asset visibility GCP-specific; different model than AWS Config rules Use in GCP; combine with AWS Config for multi-cloud
Cloud Custodian (open source) Multi-cloud policy automation Flexible; supports multiple clouds Requires hosting/ops; policy maintenance When you want cross-cloud policies with self-managed control
OPA / policy-as-code in CI Prevent misconfigurations before deploy Fast feedback; shift-left Doesn’t track post-deploy drift alone Combine with AWS Config for continuous drift/compliance

15. Real-World Example

Enterprise example (regulated organization)

  • Problem: A financial services company runs 200+ AWS accounts across multiple Regions. Auditors require continuous evidence that encryption, logging, and network exposure policies are enforced, and security needs centralized reporting.
  • Proposed architecture:
  • Enable AWS Config in all required Regions in all workload accounts.
  • Use AWS Organizations to manage multi-account governance.
  • Deploy organization conformance packs (baseline security controls) to all OUs; apply stricter packs to production OUs.
  • Configure a central AWS Config aggregator in the security account to collect compliance and configuration data.
  • Route compliance change events to EventBridge and create tickets for critical noncompliance.
  • Use Systems Manager Automation for safe, pre-approved remediations (e.g., enforce S3 public access block) and require approvals for high-risk remediations.
  • Why AWS Config was chosen:
  • Native configuration history and compliance evaluation.
  • Scales across accounts/Regions using aggregators and organization patterns.
  • Strong audit evidence story via delivered S3 history/snapshots.
  • Expected outcomes:
  • Reduced audit time and faster evidence gathering.
  • Faster detection of misconfigurations and reduced risk window.
  • Centralized compliance dashboards for leadership and auditors.

Startup/small-team example (lean operations)

  • Problem: A startup with a small DevOps team has experienced incidents due to manual console changes and inconsistent tagging. They need lightweight governance without slowing development.
  • Proposed architecture:
  • Enable AWS Config in one primary Region for production.
  • Record only key resource types (S3, security groups, IAM-related where needed—verify supported types).
  • Add 5–10 high-value managed rules: S3 public access, encryption checks, open security group ports, required tags.
  • Notify a Slack/email channel via SNS when critical rules become noncompliant.
  • Why AWS Config was chosen:
  • Minimal operational overhead compared to self-hosted governance.
  • Immediate value: visibility into changes and basic compliance.
  • Expected outcomes:
  • Fewer “mystery changes” during incidents.
  • Improved cost allocation and ownership through tagging compliance.
  • A governance foundation that can scale later with conformance packs and aggregation.

16. FAQ

  1. Is AWS Config the same as AWS CloudTrail?
    No. CloudTrail logs API activity (who called what). AWS Config records resource configuration state and changes over time and evaluates compliance.

  2. Do I need an S3 bucket for AWS Config?
    Yes. AWS Config uses a delivery channel that delivers configuration history and snapshots to an S3 bucket.

  3. Is AWS Config regional or global?
    AWS Config is configured per Region. Some global resource types can be recorded, typically in a designated Region—verify the current behavior in official docs for the resource types you care about.

  4. Can AWS Config work across multiple AWS accounts?
    Yes. Common patterns include using AWS Organizations features and a configuration aggregator in a central account.

  5. What’s the difference between AWS Config rules and conformance packs?
    Rules are individual compliance checks. Conformance packs bundle multiple rules (and optional remediation settings) into a deployable unit.

  6. Does AWS Config prevent noncompliant resources from being created?
    AWS Config primarily detects and evaluates after creation/change. Preventive controls typically use IAM policies, SCPs (Organizations), or service-native controls. Config can trigger remediation after the fact.

  7. How quickly does AWS Config detect changes?
    It’s near-real-time for many changes, but not guaranteed instantaneous. Expect some delay (eventual consistency).

  8. Can I write custom compliance logic?
    Yes. You can create custom rules, typically using AWS Lambda to evaluate resources.

  9. Does AWS Config store configuration history forever?
    AWS Config retains configuration history according to its service behavior and your S3 retention policies. Retention details and limits can change—verify in official docs, and ensure your S3 lifecycle policies align with audit requirements.

  10. How do I reduce AWS Config costs?
    Limit recording to necessary resource types, reduce the number of rules, prefer change-triggered evaluations where appropriate, and tune conformance packs. Use the pricing page and calculator to model costs.

  11. Can AWS Config auto-remediate issues?
    Yes, in many cases via remediation actions (often Systems Manager Automation). Not all rules/resources support remediation; test carefully.

  12. Does AWS Config support Kubernetes (EKS) resources?
    AWS Config focuses on AWS resource configurations; it may record certain EKS-related AWS resources (clusters, security groups, IAM, etc.), but not necessarily Kubernetes objects inside the cluster. For in-cluster policy, use Kubernetes-native tooling plus AWS governance.

  13. Can I get notified when a resource becomes noncompliant?
    Yes. Use SNS or EventBridge to react to compliance change events.

  14. Is AWS Config required for SOC 2 / ISO 27001?
    Not required, but commonly used to provide evidence and continuous monitoring for relevant controls. Your requirements depend on your auditors and control design.

  15. What’s a good minimal starting set of AWS Config rules?
    Common starting points: required tags, S3 public access controls, encryption checks for key data stores, and security group exposure checks. Choose rules based on your threat model and compliance needs.

  16. Can I export AWS Config data for analytics?
    Yes. Data is delivered to S3; you can build analytics pipelines (for example, using Athena) if desired. Ensure your delivered data format and partitions match your query approach (verify in docs and test).

  17. How does AWS Config relate to AWS Organizations SCPs?
    SCPs can prevent actions at the account level; AWS Config detects and reports configuration compliance. Many organizations use SCPs for preventive guardrails and AWS Config for detective controls and evidence.

17. Top Online Resources to Learn AWS Config

Resource Type Name Why It Is Useful
Official documentation AWS Config Developer Guide Primary reference for concepts, setup, rules, aggregators, and APIs: https://docs.aws.amazon.com/config/latest/developerguide/WhatIsConfig.html
Official pricing AWS Config Pricing Accurate, region-specific pricing model: https://aws.amazon.com/config/pricing/
Pricing tool AWS Pricing Calculator Model costs for configuration items and rule evaluations: https://calculator.aws/#/
Official rule reference AWS Managed Rules List Shows available managed rules and parameters (verify current list): https://docs.aws.amazon.com/config/latest/developerguide/managed-rules-by-aws-config.html
Official getting started Getting Started with AWS Config Step-by-step enablement guidance (console and concepts): https://docs.aws.amazon.com/config/latest/developerguide/gs-console.html
Official API reference AWS Config API Reference For automation and tooling: https://docs.aws.amazon.com/config/latest/APIReference/
CLI reference AWS CLI – configservice commands Copy/paste commands and options: https://docs.aws.amazon.com/cli/latest/reference/configservice/
Architecture guidance AWS Architecture Center Patterns and best practices; search for governance/compliance: https://aws.amazon.com/architecture/
Official videos AWS YouTube Channel Talks, demos, governance best practices (search “AWS Config”): https://www.youtube.com/@AmazonWebServices
Samples AWS Samples on GitHub (search) Reference implementations and automation patterns (validate repo trust): https://github.com/aws-samples

18. Training and Certification Providers

Institute Suitable Audience Likely Learning Focus Mode Website URL
DevOpsSchool.com Beginners to experienced DevOps/Cloud engineers AWS governance, DevOps practices, hands-on labs Check website https://www.devopsschool.com/
ScmGalaxy.com DevOps, build/release, and tooling learners SCM/DevOps foundations plus cloud governance topics Check website https://www.scmgalaxy.com/
CLoudOpsNow.in CloudOps/operations teams Operations, monitoring, governance, cost awareness Check website https://www.cloudopsnow.in/
SreSchool.com SREs and reliability-focused engineers Reliability engineering, operations, governance integration Check website https://www.sreschool.com/
AiOpsSchool.com Ops teams exploring AIOps Automation, operations analytics, governance signals Check website https://www.aiopsschool.com/

19. Top Trainers

Platform/Site Likely Specialization Suitable Audience Website URL
RajeshKumar.xyz DevOps/cloud coaching and workshops (verify offerings) Individuals and teams seeking practical mentoring https://www.rajeshkumar.xyz/
devopstrainer.in DevOps and cloud training programs (verify offerings) Beginners to intermediate engineers https://www.devopstrainer.in/
devopsfreelancer.com Freelance DevOps consulting/training (verify offerings) Teams needing short-term enablement https://www.devopsfreelancer.com/
devopssupport.in DevOps support and training resources (verify offerings) Operations teams and practitioners https://www.devopssupport.in/

20. Top Consulting Companies

Company Likely Service Area Where They May Help Consulting Use Case Examples Website URL
cotocus.com Cloud/DevOps consulting (verify exact services) Governance design, AWS foundations, automation Multi-account landing zone improvements; governance rollout planning; compliance reporting setup https://www.cotocus.com/
DevOpsSchool.com DevOps and cloud consulting/training Governance implementation, DevOps operating model AWS Config rollout with conformance packs; rule tuning; remediation pipelines https://www.devopsschool.com/
DEVOPSCONSULTING.IN DevOps consulting services (verify exact services) Cloud operations and governance CI/CD + compliance guardrails; tagging standards enforcement; audit evidence workflows https://www.devopsconsulting.in/

21. Career and Learning Roadmap

What to learn before AWS Config

  • AWS fundamentals: accounts, Regions, IAM, VPC, EC2, S3
  • IAM policy basics (allow/deny, least privilege, roles)
  • Logging basics: CloudTrail and CloudWatch
  • Infrastructure as Code basics (CloudFormation/Terraform) to manage governance as code

What to learn after AWS Config

  • AWS Organizations advanced governance (SCPs, delegated admin patterns)
  • AWS Security Hub and detective controls strategy
  • Event-driven automation: EventBridge + Lambda + Systems Manager Automation
  • Policy as code in CI/CD (OPA, tfsec/checkov, cfn-lint, etc.)
  • Data analytics on S3-delivered governance evidence (Athena/Glue) if needed

Job roles that use AWS Config

  • Cloud Platform Engineer
  • Cloud Security Engineer / Security Architect
  • DevOps Engineer / SRE
  • Governance, Risk, and Compliance (GRC) technical roles
  • Solutions Architect (especially in regulated environments)

Certification path (AWS)

There is no certification dedicated only to AWS Config, but it’s relevant to: – AWS Certified Solutions Architect (Associate/Professional) – AWS Certified SysOps Administrator – Associate – AWS Certified DevOps Engineer – Professional – AWS Certified Security – Specialty
Verify current AWS certification names and availability: https://aws.amazon.com/certification/

Project ideas for practice

  1. Baseline conformance pack rollout in a multi-account org (dev → staging → prod).
  2. Automated remediation for a safe control (e.g., enforce S3 public access block) with approval gates.
  3. Drift detection pipeline: AWS Config events → EventBridge → ticket/Slack → IaC PR to revert.
  4. Tag governance program: required tags + exception tagging + compliance reporting dashboard.
  5. Central aggregator + reporting: aggregate compliance into a security account and build periodic reports.

22. Glossary

  • AWS Config: AWS service for recording resource configurations, tracking changes, and evaluating compliance.
  • Configuration recorder: AWS Config component that records configuration changes for selected resource types.
  • Delivery channel: AWS Config component that delivers configuration history and snapshots to S3 (and optionally sends notifications to SNS).
  • Configuration item (CI): A point-in-time representation of a resource’s configuration recorded by AWS Config.
  • AWS Config Rule: A compliance check that evaluates whether resources meet desired configuration requirements.
  • Managed rule: A predefined rule provided by AWS.
  • Custom rule: A rule with custom evaluation logic (commonly backed by AWS Lambda).
  • Conformance Pack: A deployable collection of rules (and optional remediation settings) representing a compliance standard or baseline.
  • Configuration aggregator: A component that collects configuration and compliance data across accounts and Regions.
  • Compliance status: Result of evaluating a resource against a rule (e.g., COMPLIANT / NON_COMPLIANT / INSUFFICIENT_DATA).
  • Remediation action: An automated action that attempts to fix noncompliance (often through Systems Manager Automation).
  • AWS Organizations: Service for managing multiple AWS accounts with centralized governance.
  • SCP (Service Control Policy): Organization-level policy that limits what actions accounts can perform.
  • EventBridge: Event bus service used to route AWS service events to targets for automation.

23. Summary

AWS Config is an AWS Management and governance service that records supported AWS resource configurations, tracks changes over time, and evaluates compliance with rules and conformance packs. It matters because it provides continuous visibility into configuration drift, supports audit evidence collection, and enables automated governance workflows across accounts and Regions.

Cost is driven mainly by configuration items recorded and rule evaluations, plus indirect costs like S3 storage, KMS, and automation components. Security success depends on locking down the S3 delivery bucket, controlling who can modify AWS Config settings, and designing safe remediation paths.

Use AWS Config when you need configuration history and continuous compliance in AWS—especially in multi-account environments. Start small (limited resource types, a few high-value managed rules), validate value and noise, then scale with conformance packs, aggregation, and remediation automation.

Next step: review the official AWS Config Developer Guide and implement a production-ready multi-account pattern with an aggregator and a baseline conformance pack, managed as code.