{"id":259,"date":"2026-04-13T09:42:27","date_gmt":"2026-04-13T09:42:27","guid":{"rendered":"https:\/\/www.devopsschool.com\/tutorials\/aws-config-tutorial-architecture-pricing-use-cases-and-hands-on-guide-for-management-and-governance\/"},"modified":"2026-04-13T09:42:27","modified_gmt":"2026-04-13T09:42:27","slug":"aws-config-tutorial-architecture-pricing-use-cases-and-hands-on-guide-for-management-and-governance","status":"publish","type":"post","link":"https:\/\/www.devopsschool.com\/tutorials\/aws-config-tutorial-architecture-pricing-use-cases-and-hands-on-guide-for-management-and-governance\/","title":{"rendered":"AWS Config Tutorial: Architecture, Pricing, Use Cases, and Hands-On Guide for Management and governance"},"content":{"rendered":"\n<h2 class=\"wp-block-heading\">Category<\/h2>\n\n\n\n<p>Management and governance<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">1. Introduction<\/h2>\n\n\n\n<p>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.<\/p>\n\n\n\n<p>In simple terms: AWS Config is \u201cconfiguration history + compliance checks for AWS resources.\u201d It helps you answer questions like: <em>What changed? When? Who\/what might have caused it? Is this resource compliant with our standards?<\/em><\/p>\n\n\n\n<p>Technically, AWS Config uses a <strong>configuration recorder<\/strong> in each AWS Region to capture configuration items (metadata about supported AWS resources). It delivers these items to an <strong>Amazon S3 bucket<\/strong> (and optionally publishes notifications to <strong>Amazon SNS<\/strong>) and can evaluate recorded resources with <strong>AWS Config Rules<\/strong> and <strong>Conformance Packs<\/strong>. You can aggregate data across accounts and Regions with a <strong>configuration aggregator<\/strong>, query it with <strong>advanced queries<\/strong>, and integrate it with services like <strong>AWS Organizations<\/strong>, <strong>Amazon EventBridge<\/strong>, <strong>AWS Systems Manager<\/strong>, and <strong>AWS Security Hub<\/strong>.<\/p>\n\n\n\n<p>The problem AWS Config solves is governance at scale: maintaining visibility and control over <em>how<\/em> your cloud infrastructure is configured\u2014across accounts, Regions, and teams\u2014without relying on ad-hoc scripts or manual audits.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">2. What is AWS Config?<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Official purpose<\/h3>\n\n\n\n<p>AWS Config is designed to help you <strong>assess, audit, and evaluate<\/strong> the configurations of your AWS resources. It provides <strong>resource inventory<\/strong>, <strong>configuration history<\/strong>, <strong>change notifications<\/strong>, and <strong>compliance evaluation<\/strong> against your desired configuration rules.<\/p>\n\n\n\n<p>Official docs: https:\/\/docs.aws.amazon.com\/config\/latest\/developerguide\/WhatIsConfig.html<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Core capabilities<\/h3>\n\n\n\n<p>Key capabilities include:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Configuration recording<\/strong> of supported resource types (configuration items).<\/li>\n<li><strong>Configuration history<\/strong> and <strong>resource timeline<\/strong> for change analysis.<\/li>\n<li><strong>Configuration snapshots<\/strong> (point-in-time exports).<\/li>\n<li><strong>Compliance evaluation<\/strong> using:<\/li>\n<li><strong>AWS managed rules<\/strong><\/li>\n<li><strong>Custom rules<\/strong> (typically backed by AWS Lambda)<\/li>\n<li><strong>Conformance Packs<\/strong> (collections of rules)<\/li>\n<li><strong>Remediation<\/strong> support (commonly through AWS Systems Manager Automation for managed remediation actions).<\/li>\n<li><strong>Notifications<\/strong> of configuration and compliance changes (SNS \/ EventBridge integrations).<\/li>\n<li><strong>Multi-account and multi-Region aggregation<\/strong> using configuration aggregators.<\/li>\n<li><strong>Querying<\/strong> across your recorded configuration data using AWS Config <strong>advanced queries<\/strong> (SQL-like query language for supported resource properties).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Major components<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Configuration recorder<\/strong>: Collects configuration changes for selected resource types in a Region.<\/li>\n<li><strong>Delivery channel<\/strong>: Sends configuration items and snapshots to an S3 bucket; can also send notifications to an SNS topic.<\/li>\n<li><strong>Configuration item (CI)<\/strong>: The recorded representation of a resource\u2019s configuration at a point in time.<\/li>\n<li><strong>AWS Config Rules<\/strong>: Evaluate whether resources comply with desired settings.<\/li>\n<li><strong>Conformance Packs<\/strong>: Packaged sets of rules and optional remediation settings to enforce standards at scale.<\/li>\n<li><strong>Configuration aggregator<\/strong>: Central view across accounts\/Regions (often in a security or governance account).<\/li>\n<li><strong>Remediation actions<\/strong>: Automated fixes triggered for noncompliance (often via Systems Manager).<\/li>\n<li><strong>Advanced queries<\/strong>: Search and analyze configuration state across resources.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Service type<\/h3>\n\n\n\n<p>AWS Config is a <strong>managed governance service<\/strong>. You don\u2019t deploy servers for it; you configure it and AWS runs the recording, storage delivery, and evaluation workflows.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Scope: regional\/global and account considerations<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Regional service<\/strong>: AWS Config is configured <strong>per Region<\/strong>. You enable it in each Region you want to record.<\/li>\n<li><strong>Global resources<\/strong>: Some AWS resources are \u201cglobal\u201d (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\u2014verify the \u201cglobal resource\u201d behavior in the official docs for your use case.<\/li>\n<li><strong>Account-scoped<\/strong> by default: AWS Config records resources in the current AWS account and Region unless you use <strong>AWS Organizations<\/strong> features (organization rules \/ conformance packs) and\/or an <strong>aggregator<\/strong>.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">How it fits into the AWS ecosystem<\/h3>\n\n\n\n<p>AWS Config complements (but does not replace) other governance and security services:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>AWS CloudTrail<\/strong> answers: \u201cWho called what API and when?\u201d<\/li>\n<li><strong>AWS Config<\/strong> answers: \u201cWhat is the configuration now, what was it before, and is it compliant?\u201d<\/li>\n<li><strong>Amazon CloudWatch<\/strong> focuses on metrics\/logs\/alarms and operational telemetry.<\/li>\n<li><strong>AWS Security Hub<\/strong> aggregates security findings; AWS Config can be one data source and policy signal.<\/li>\n<li><strong>AWS Organizations<\/strong> provides multi-account management; AWS Config can enforce and report compliance across the organization.<\/li>\n<li><strong>AWS Systems Manager<\/strong> can automate remediation actions for noncompliant resources.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">3. Why use AWS Config?<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Business reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Reduce audit effort<\/strong> by having configuration history and compliance evidence available on demand.<\/li>\n<li><strong>Lower risk of outages<\/strong> caused by unintended infrastructure changes.<\/li>\n<li><strong>Standardize governance<\/strong> across teams and accounts with centrally defined rules and conformance packs.<\/li>\n<li><strong>Improve accountability<\/strong>: change history and compliance status support internal controls and reporting.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Technical reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Track configuration drift<\/strong> from infrastructure-as-code baselines.<\/li>\n<li><strong>Detect unintended changes<\/strong> across compute, networking, storage, IAM-related configurations (where supported).<\/li>\n<li><strong>Build automated guardrails<\/strong>: continuous evaluation and auto-remediation patterns.<\/li>\n<li><strong>Enable incident investigations<\/strong>: resource timelines help correlate changes with incidents.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Operational reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Continuous visibility<\/strong> rather than periodic manual checks.<\/li>\n<li><strong>Event-driven operations<\/strong>: react to compliance changes via SNS\/EventBridge.<\/li>\n<li><strong>Central reporting<\/strong>: aggregators provide one-pane views across environments.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Security\/compliance reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Prove compliance<\/strong> for common policies (encryption enabled, public access blocked, MFA enabled, restricted security groups, etc.), using AWS managed rules or custom rules.<\/li>\n<li><strong>Detect risky changes<\/strong> quickly (for example, an S3 bucket becoming public).<\/li>\n<li><strong>Support frameworks<\/strong> via conformance packs (AWS provides sample packs; verify availability and suitability in official docs).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Scalability\/performance reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>AWS Config scales with your environment without you managing collectors.<\/li>\n<li>Data is delivered to S3 and can be queried and integrated into data\/analytics pipelines if needed.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">When teams should choose AWS Config<\/h3>\n\n\n\n<p>Choose AWS Config when you need any of the following:\n&#8211; Reliable configuration history for supported AWS resources\n&#8211; Continuous compliance evaluation across accounts\/Regions\n&#8211; Governance automation and evidence for audits\n&#8211; A standardized way to express \u201cresource configuration requirements\u201d as rules<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">When teams should not choose AWS Config<\/h3>\n\n\n\n<p>AWS Config is not the right tool when:\n&#8211; You only need API audit logs (use <strong>AWS CloudTrail<\/strong>).\n&#8211; You need vulnerability scanning (use <strong>Amazon Inspector<\/strong> or other security scanners).\n&#8211; You need real-time performance monitoring (use <strong>Amazon CloudWatch<\/strong>, <strong>AWS X-Ray<\/strong>, etc.).\n&#8211; Your environment is extremely cost-sensitive and you only need a narrow set of checks\u2014consider enabling AWS Config for a limited scope, or using IaC checks in CI\/CD plus periodic targeted audits.\n&#8211; You need to manage\/patch instances (use <strong>AWS Systems Manager<\/strong>).<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">4. Where is AWS Config used?<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Industries<\/h3>\n\n\n\n<p>AWS Config is widely used in regulated and security-conscious environments, including:\n&#8211; Finance and fintech\n&#8211; Healthcare and life sciences\n&#8211; Government and public sector\n&#8211; SaaS providers (SOC 2 \/ ISO 27001 programs)\n&#8211; Retail and e-commerce (security and change governance)<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Team types<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Cloud platform engineering teams implementing governance guardrails<\/li>\n<li>Security engineering \/ cloud security teams monitoring posture<\/li>\n<li>DevOps \/ SRE teams investigating configuration drift and incidents<\/li>\n<li>Compliance and audit teams generating evidence<\/li>\n<li>IT operations teams managing change control processes<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Workloads and architectures<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Multi-account AWS Organizations architectures (prod\/dev\/shared services\/security)<\/li>\n<li>Microservices platforms (EKS\/ECS\/Lambda) where supporting infrastructure needs policy checks<\/li>\n<li>Data platforms (S3, KMS, IAM, Lake Formation-related governance\u2014where supported)<\/li>\n<li>Network-heavy environments (VPC, security groups, NACLs, route tables\u2014where supported)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Real-world deployment contexts<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Central governance account aggregates Config data from workload accounts.<\/li>\n<li>Organization conformance packs enforce baseline controls across accounts.<\/li>\n<li>EventBridge triggers remediation or ticketing when a resource becomes noncompliant.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Production vs dev\/test usage<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Production<\/strong>: Typically enabled broadly, with centralized aggregation and carefully designed rules to avoid noise.<\/li>\n<li><strong>Dev\/test<\/strong>: Often enabled with fewer rules or limited resource recording to control costs, while still providing drift visibility.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">5. Top Use Cases and Scenarios<\/h2>\n\n\n\n<p>Below are realistic scenarios where AWS Config is commonly applied.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">1) Detect and alert on public S3 buckets<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Buckets accidentally become public due to policy or ACL changes.<\/li>\n<li><strong>Why AWS Config fits:<\/strong> Records S3 bucket configuration changes and evaluates against managed rules.<\/li>\n<li><strong>Example scenario:<\/strong> A developer applies a bucket policy allowing <code>s3:GetObject<\/code> to <code>Principal: *<\/code>. AWS Config flags noncompliance and triggers an EventBridge rule to notify security.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">2) Enforce encryption-at-rest standards<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Some storage resources are created without encryption.<\/li>\n<li><strong>Why AWS Config fits:<\/strong> Managed rules can detect encryption settings across supported services.<\/li>\n<li><strong>Example scenario:<\/strong> 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\u2014verify in docs).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">3) Track security group exposure (0.0.0.0\/0)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Inbound access from the internet is unintentionally opened.<\/li>\n<li><strong>Why AWS Config fits:<\/strong> Records security group changes and evaluates ingress rules.<\/li>\n<li><strong>Example scenario:<\/strong> Port 22 is opened to <code>0.0.0.0\/0<\/code>. AWS Config flags it; a Lambda-based custom rule checks exception tags and escalates if missing.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">4) Required tags enforcement (cost allocation, ownership)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Resources lack required tags, making cost allocation and ownership unclear.<\/li>\n<li><strong>Why AWS Config fits:<\/strong> Managed rule patterns can require tags and report noncompliance.<\/li>\n<li><strong>Example scenario:<\/strong> New S3 buckets must have <code>Owner<\/code> and <code>CostCenter<\/code>. AWS Config rule flags missing tags and routes a notification to the owning team.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">5) Change investigation and incident correlation<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Service outage occurs; you need to know what infrastructure changed.<\/li>\n<li><strong>Why AWS Config fits:<\/strong> Resource timeline shows configuration changes over time.<\/li>\n<li><strong>Example scenario:<\/strong> An application loses connectivity to a database. AWS Config timeline shows a NACL change 10 minutes before the incident.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">6) Drift detection from IaC standards<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Infrastructure created by Terraform\/CloudFormation drifts due to console edits.<\/li>\n<li><strong>Why AWS Config fits:<\/strong> Tracks changes outside your IaC pipelines.<\/li>\n<li><strong>Example scenario:<\/strong> Someone manually modifies an IAM role trust policy. AWS Config records the delta and can trigger a workflow to revert via IaC.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">7) Multi-account compliance reporting for auditors<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Auditors require evidence of controls across all accounts and Regions.<\/li>\n<li><strong>Why AWS Config fits:<\/strong> Aggregators provide centralized views of compliance status.<\/li>\n<li><strong>Example scenario:<\/strong> Security team generates compliance reports across 50 accounts using an aggregator and exports evidence from S3 snapshots.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">8) Continuous compliance baselines with conformance packs<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Managing dozens of rules individually becomes hard.<\/li>\n<li><strong>Why AWS Config fits:<\/strong> Conformance packs package rules and (optionally) remediation settings.<\/li>\n<li><strong>Example scenario:<\/strong> The platform team deploys a baseline conformance pack to all accounts, ensuring consistent enforcement.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">9) Automated remediation for common misconfigurations<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Teams repeatedly make the same configuration mistakes.<\/li>\n<li><strong>Why AWS Config fits:<\/strong> Integrates with Systems Manager Automation runbooks for remediation (where supported).<\/li>\n<li><strong>Example scenario:<\/strong> 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).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">10) Governance for ephemeral environments<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Short-lived environments are created and destroyed; governance must keep up.<\/li>\n<li><strong>Why AWS Config fits:<\/strong> Continuous recording catches changes during the environment lifecycle.<\/li>\n<li><strong>Example scenario:<\/strong> A preview environment creates many security groups. AWS Config ensures no security group becomes internet-open without an exception tag.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">11) Proving control effectiveness over time<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> You must show that controls were consistently enforced, not just at audit time.<\/li>\n<li><strong>Why AWS Config fits:<\/strong> Maintains historical compliance evaluation results and configuration history (retention details vary\u2014verify current retention behavior in official docs).<\/li>\n<li><strong>Example scenario:<\/strong> Quarterly audit requires proof that encryption controls were continuously monitored.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">12) Centralized governance in AWS Organizations<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Business units manage their own accounts; central governance needs guardrails.<\/li>\n<li><strong>Why AWS Config fits:<\/strong> Organization-level deployment patterns and aggregation enable centralized policy with distributed execution.<\/li>\n<li><strong>Example scenario:<\/strong> Security account deploys organization conformance packs and aggregates compliance results for executive reporting.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">6. Core Features<\/h2>\n\n\n\n<p>This section focuses on important AWS Config capabilities used in real environments.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">6.1 Configuration recording (configuration items)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Records configuration changes for supported resource types in a Region.<\/li>\n<li><strong>Why it matters:<\/strong> Without recording, you can\u2019t reconstruct historical configuration state.<\/li>\n<li><strong>Practical benefit:<\/strong> Enables timelines, drift investigations, and compliance evaluation.<\/li>\n<li><strong>Limitations\/caveats:<\/strong><\/li>\n<li>Not all AWS resource types are supported; check the official \u201csupported resource types\u201d list.<\/li>\n<li>Recording can increase costs if you record many resource types across many accounts\/Regions.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">6.2 Configuration history and timeline<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Provides change history per resource (what changed and when).<\/li>\n<li><strong>Why it matters:<\/strong> Root cause analysis often requires knowing exactly what changed.<\/li>\n<li><strong>Practical benefit:<\/strong> Faster incident investigation and reduced mean time to recovery (MTTR).<\/li>\n<li><strong>Limitations\/caveats:<\/strong> Timeline fidelity depends on supported properties and recording settings.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">6.3 Configuration snapshots<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Produces point-in-time exports of configuration for recorded resources, delivered to S3.<\/li>\n<li><strong>Why it matters:<\/strong> Snapshots are useful for audits and offline analysis.<\/li>\n<li><strong>Practical benefit:<\/strong> Repeatable evidence capture for compliance programs.<\/li>\n<li><strong>Limitations\/caveats:<\/strong> Snapshots and stored objects can increase S3 storage costs.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">6.4 Configuration change notifications (SNS \/ EventBridge)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Sends notifications when resources change configuration and when compliance status changes.<\/li>\n<li><strong>Why it matters:<\/strong> Enables event-driven workflows (alerting, ticketing, remediation).<\/li>\n<li><strong>Practical benefit:<\/strong> Integrate with existing operations tooling.<\/li>\n<li><strong>Limitations\/caveats:<\/strong> Notifications can be noisy if scope is broad and environments are highly dynamic\u2014filtering and tuning is important.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">6.5 AWS Config Rules (managed and custom)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Evaluates resources against desired configuration settings.<\/li>\n<li><strong>Why it matters:<\/strong> Provides continuous compliance rather than periodic checks.<\/li>\n<li><strong>Practical benefit:<\/strong> Detects misconfigurations early.<\/li>\n<li><strong>Limitations\/caveats:<\/strong><\/li>\n<li>Some managed rules apply only to specific resource types or Regions.<\/li>\n<li>Custom rules typically require a Lambda function (and its operational lifecycle).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">6.6 Conformance Packs<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Deploys a collection of rules and optional remediation settings as a single unit.<\/li>\n<li><strong>Why it matters:<\/strong> Governance at scale requires packaging, versioning, and repeatability.<\/li>\n<li><strong>Practical benefit:<\/strong> Standard baselines across accounts\/Regions.<\/li>\n<li><strong>Limitations\/caveats:<\/strong> Conformance packs still evaluate underlying rules; cost scales with evaluations and scope.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">6.7 Remediation actions (commonly via Systems Manager Automation)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Automates fixes for certain noncompliant findings using AWS-managed or custom remediation documents.<\/li>\n<li><strong>Why it matters:<\/strong> Reduces manual effort and speeds up risk reduction.<\/li>\n<li><strong>Practical benefit:<\/strong> \u201cDetect and fix\u201d loops for common misconfigurations.<\/li>\n<li><strong>Limitations\/caveats:<\/strong><\/li>\n<li>Not every rule\/resource supports automatic remediation.<\/li>\n<li>Remediation can be risky if applied blindly; approvals and guardrails matter.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">6.8 Multi-account and multi-Region aggregation<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Collects configuration and compliance data across accounts and Regions into a central aggregator.<\/li>\n<li><strong>Why it matters:<\/strong> Enterprise AWS usage is typically multi-account.<\/li>\n<li><strong>Practical benefit:<\/strong> Single place to query and report compliance posture.<\/li>\n<li><strong>Limitations\/caveats:<\/strong> Cross-account permissions and AWS Organizations setup must be correct.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">6.9 Advanced queries<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Lets you query recorded resource configuration state using a SQL-like query language (AWS Config query).<\/li>\n<li><strong>Why it matters:<\/strong> Faster ad-hoc investigations and reporting without exporting data.<\/li>\n<li><strong>Practical benefit:<\/strong> Identify patterns (e.g., untagged resources, security group rules, encryption settings) quickly.<\/li>\n<li><strong>Limitations\/caveats:<\/strong> Query coverage depends on what AWS Config records and how resource properties are modeled.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">6.10 Integration with AWS Organizations<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Enables governance patterns across organizational units (OUs) and accounts, including delegated administration and organization-level deployments (capabilities vary\u2014verify current organization-level features in docs).<\/li>\n<li><strong>Why it matters:<\/strong> Central governance without manually configuring every account.<\/li>\n<li><strong>Practical benefit:<\/strong> Consistent compliance posture across the org.<\/li>\n<li><strong>Limitations\/caveats:<\/strong> Requires correct Organizations setup and careful permission design.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">7. Architecture and How It Works<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">High-level architecture<\/h3>\n\n\n\n<p>At a high level:<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li>You enable AWS Config in a Region.<\/li>\n<li>The <strong>configuration recorder<\/strong> discovers and records supported resources as <strong>configuration items<\/strong>.<\/li>\n<li>AWS Config delivers configuration items and snapshots to an <strong>S3 bucket<\/strong> (and optionally publishes to <strong>SNS<\/strong>).<\/li>\n<li><strong>AWS Config Rules<\/strong> evaluate resources and store compliance results.<\/li>\n<li>Events can flow to <strong>EventBridge<\/strong> and\/or notifications to <strong>SNS<\/strong> for automation and alerting.<\/li>\n<li>In multi-account setups, a <strong>configuration aggregator<\/strong> centralizes data for reporting and queries.<\/li>\n<\/ol>\n\n\n\n<h3 class=\"wp-block-heading\">Request\/data\/control flow<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Data plane (recording):<\/strong> AWS Config observes resource configuration state and changes (implementation is managed by AWS).<\/li>\n<li><strong>Control plane (your actions):<\/strong> You configure recorders, delivery channels, rules, conformance packs, remediation, aggregators, and permissions.<\/li>\n<li><strong>Storage:<\/strong> Configuration history and snapshots are delivered to S3; compliance results are available via the AWS Config console and APIs.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Integrations with related services<\/h3>\n\n\n\n<p>Common integrations include:\n&#8211; <strong>Amazon S3<\/strong>: required destination for configuration history and snapshots.\n&#8211; <strong>Amazon SNS<\/strong>: optional notifications for configuration changes and evaluation results.\n&#8211; <strong>Amazon EventBridge<\/strong>: receive AWS Config events for workflows.\n&#8211; <strong>AWS Lambda<\/strong>: custom rules (and sometimes custom remediation).\n&#8211; <strong>AWS Systems Manager<\/strong>: remediation actions via Automation runbooks.\n&#8211; <strong>AWS Organizations<\/strong>: centralized governance, aggregation, and org-wide deployment patterns.\n&#8211; <strong>AWS CloudTrail<\/strong>: correlate \u201cwho changed\u201d (CloudTrail) with \u201cwhat changed\u201d (Config).\n&#8211; <strong>AWS Security Hub<\/strong>: posture management and findings aggregation (integration patterns vary; verify in official docs for your region and use case).<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Dependency services<\/h3>\n\n\n\n<p>Minimum dependencies to run AWS Config in a Region:\n&#8211; An <strong>S3 bucket<\/strong> for delivery (in the same account, typically).\n&#8211; An IAM role for AWS Config (often a <strong>service-linked role<\/strong>).<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Security\/authentication model<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>AWS Config uses IAM to assume a role to access S3 and publish to SNS.<\/li>\n<li>Access to AWS Config APIs and console is controlled by IAM policies.<\/li>\n<li>Cross-account aggregation requires explicit authorization (often via Organizations-managed authorization or aggregator permissions).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Networking model<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>AWS Config is an AWS-managed service accessed via AWS APIs.<\/li>\n<li>If you need private connectivity from VPC-only networks, investigate <strong>VPC endpoints (AWS PrivateLink)<\/strong> availability for AWS Config in your Regions. Availability can vary\u2014verify in official docs:<\/li>\n<li>VPC endpoints overview: https:\/\/docs.aws.amazon.com\/vpc\/latest\/privatelink\/what-is-privatelink.html<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Monitoring\/logging\/governance considerations<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>CloudTrail<\/strong> logs AWS Config API calls (who created rules, changed recorders, etc.).<\/li>\n<li><strong>CloudWatch<\/strong> can be used to monitor related automation (Lambda, Systems Manager).<\/li>\n<li><strong>AWS Config<\/strong> itself becomes part of your governance baseline\u2014treat its configuration as critical infrastructure (IaC, version control, change management).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Simple architecture diagram<\/h3>\n\n\n\n<pre><code class=\"language-mermaid\">flowchart LR\n  R[AWS Resources\\n(EC2, S3, SGs, etc.)] --&gt; CR[AWS Config\\nConfiguration Recorder]\n  CR --&gt; S3[(Amazon S3\\nConfig bucket)]\n  CR --&gt; SNS[(Amazon SNS\\noptional notifications)]\n  CR --&gt; RULES[AWS Config Rules\\nManaged\/Custom]\n  RULES --&gt; COMPLIANCE[Compliance Results\\nConsole\/API]\n<\/code><\/pre>\n\n\n\n<h3 class=\"wp-block-heading\">Production-style architecture diagram (multi-account)<\/h3>\n\n\n\n<pre><code class=\"language-mermaid\">flowchart TB\n  subgraph Org[AWS Organizations]\n    subgraph Sec[Security \/ Governance Account]\n      AGG[AWS Config Aggregator]\n      S3C[(Central S3 bucket\\n(optional for reports\/artifacts))]\n      SH[AWS Security Hub\\n(optional)]\n      EB[Amazon EventBridge\\nRules]\n      ITSM[Ticketing\/ChatOps\\n(optional)]\n    end\n\n    subgraph Prod[Production Account(s)]\n      CRP[AWS Config Recorder]\n      DC1[Delivery Channel]\n      S3P[(S3 bucket for Config delivery)]\n      RULESP[AWS Config Rules\\n+ Conformance Packs]\n      SSM[AWS Systems Manager\\nAutomation Remediation]\n    end\n\n    subgraph Dev[Dev\/Test Account(s)]\n      CRD[AWS Config Recorder]\n      S3D[(S3 bucket)]\n      RULESD[Rules tuned for dev]\n    end\n  end\n\n  CRP --&gt; DC1 --&gt; S3P\n  CRP --&gt; RULESP\n  RULESP --&gt; EB\n  EB --&gt; ITSM\n  RULESP --&gt; SSM\n\n  CRD --&gt; S3D\n  CRP --&gt; AGG\n  CRD --&gt; AGG\n  AGG --&gt; SH\n  AGG --&gt; S3C\n<\/code><\/pre>\n\n\n\n<h2 class=\"wp-block-heading\">8. Prerequisites<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">AWS account requirements<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>An AWS account with billing enabled.<\/li>\n<li>If doing multi-account governance: AWS Organizations set up (optional for this lab).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Permissions \/ IAM roles<\/h3>\n\n\n\n<p>You need permissions to:\n&#8211; Create or manage AWS Config components: recorders, delivery channels, rules.\n&#8211; Create and manage S3 bucket and bucket policy.\n&#8211; Create service-linked role (recommended) or IAM role for AWS Config.\n&#8211; Optional: SNS topic and policy.<\/p>\n\n\n\n<p>A practical set of permissions for the lab:\n&#8211; <code>config:*<\/code> (or at minimum: <code>config:PutConfigurationRecorder<\/code>, <code>config:PutDeliveryChannel<\/code>, <code>config:StartConfigurationRecorder<\/code>, <code>config:PutConfigRule<\/code>, <code>config:Describe*<\/code>, <code>config:Get*<\/code>, <code>config:Delete*<\/code>)\n&#8211; <code>s3:CreateBucket<\/code>, <code>s3:PutBucketPolicy<\/code>, <code>s3:PutEncryptionConfiguration<\/code>, <code>s3:PutBucketPublicAccessBlock<\/code>, <code>s3:ListBucket<\/code>, <code>s3:DeleteObject<\/code>, <code>s3:DeleteBucket<\/code>\n&#8211; <code>iam:CreateServiceLinkedRole<\/code> (if creating service-linked role)\n&#8211; Optional <code>sns:*<\/code> for topic setup<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Billing requirements<\/h3>\n\n\n\n<p>AWS Config is a paid service (usage-based). Even small labs can incur charges if left running.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Tools<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>AWS Management Console (optional, but helpful)<\/li>\n<li>AWS CLI v2 recommended:<\/li>\n<li>Install: https:\/\/docs.aws.amazon.com\/cli\/latest\/userguide\/getting-started-install.html<\/li>\n<li><code>jq<\/code> is helpful for formatting outputs (optional)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Region availability<\/h3>\n\n\n\n<p>AWS Config is available in many AWS Regions, but not necessarily all. Verify availability for your target Region in AWS Regional Services list:\n&#8211; https:\/\/aws.amazon.com\/about-aws\/global-infrastructure\/regional-product-services\/<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Quotas \/ limits<\/h3>\n\n\n\n<p>AWS Config has service quotas (for example, number of rules, conformance packs, recorders). Check <strong>Service Quotas<\/strong> for AWS Config in your account\/Region:\n&#8211; https:\/\/docs.aws.amazon.com\/servicequotas\/latest\/userguide\/intro.html<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Prerequisite services<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Amazon S3 (for delivery channel)<\/li>\n<li>IAM (role\/service-linked role)<\/li>\n<li>Optional: SNS, EventBridge, Lambda, Systems Manager (for more advanced patterns)<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">9. Pricing \/ Cost<\/h2>\n\n\n\n<p>AWS Config pricing is <strong>usage-based<\/strong> and varies by Region. Do not rely on fixed numbers from third-party sources; always confirm in the official pricing page.<\/p>\n\n\n\n<p>Official pricing:\n&#8211; https:\/\/aws.amazon.com\/config\/pricing\/\n&#8211; AWS Pricing Calculator: https:\/\/calculator.aws\/#\/<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Pricing dimensions (how you get charged)<\/h3>\n\n\n\n<p>AWS Config costs typically come from:<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li>\n<p><strong>Configuration items recorded<\/strong>\n   &#8211; Each recorded configuration item can generate charges.\n   &#8211; The number depends on how many resources you record and how frequently they change.<\/p>\n<\/li>\n<li>\n<p><strong>Rule evaluations<\/strong>\n   &#8211; AWS Config Rules evaluate resources (periodically and\/or on change, depending on rule type and configuration).\n   &#8211; Costs scale with number of rules * number of resources evaluated * evaluation frequency.<\/p>\n<\/li>\n<li>\n<p><strong>Conformance packs<\/strong>\n   &#8211; 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).<\/p>\n<\/li>\n<li>\n<p><strong>Optional delivery and storage<\/strong>\n   &#8211; <strong>S3 storage<\/strong> for configuration history and snapshots.\n   &#8211; <strong>SNS<\/strong> message delivery costs if you use notifications.\n   &#8211; <strong>KMS<\/strong> costs if you use SSE-KMS encryption for S3\/SNS.\n   &#8211; <strong>Data transfer<\/strong> costs are usually minimal for in-region delivery to S3, but cross-region\/cross-account patterns can introduce additional costs\u2014verify based on your architecture.<\/p>\n<\/li>\n<\/ol>\n\n\n\n<h3 class=\"wp-block-heading\">Free tier<\/h3>\n\n\n\n<p>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.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Cost drivers (what makes bills go up)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Enabling AWS Config in <strong>many Regions<\/strong>.<\/li>\n<li>Recording <strong>all supported resource types<\/strong> in accounts with many resources.<\/li>\n<li>High-change environments (autoscaling, CI\/CD-driven infra changes).<\/li>\n<li>Large numbers of rules and conformance pack rules.<\/li>\n<li>Frequent periodic evaluations.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Hidden or indirect costs<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>S3 bucket growth over time (snapshots and continuous delivery).<\/li>\n<li>KMS request costs if encrypting at rest with customer-managed keys.<\/li>\n<li>Lambda costs for custom rules and remediation.<\/li>\n<li>Systems Manager Automation execution costs (if applicable to your remediations).<\/li>\n<li>Operational overhead: rule tuning, exception handling, governance workflows.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Network\/data transfer implications<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>In many setups, Config delivers to S3 in the same account and Region\u2014data transfer costs are typically low.<\/li>\n<li>If you centralize delivery across Regions or accounts, review S3 and inter-region data transfer pricing.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">How to optimize cost<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Record only the <strong>resource types you need<\/strong> (instead of \u201call supported\u201d) where feasible.<\/li>\n<li>Start with a <strong>small set of high-value rules<\/strong> and expand gradually.<\/li>\n<li>Prefer <strong>change-triggered evaluations<\/strong> where appropriate to reduce periodic evaluation volume (depends on rule type).<\/li>\n<li>Use <strong>aggregation<\/strong> for visibility, but keep delivery\/storage strategy intentional.<\/li>\n<li>Implement lifecycle policies for the S3 bucket where appropriate (ensure it meets audit retention needs).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Example low-cost starter estimate (how to think about it)<\/h3>\n\n\n\n<p>A low-cost approach typically looks like:\n&#8211; Enable AWS Config in <strong>one Region<\/strong>.\n&#8211; Record <strong>a limited set of resource types<\/strong> (for example, S3 buckets only).\n&#8211; Deploy <strong>1\u20133 managed rules<\/strong> (tagging, public access, encryption).\n&#8211; Avoid custom rules until needed.<\/p>\n\n\n\n<p>To estimate accurately:\n&#8211; Use the AWS Pricing Calculator and model configuration items and rule evaluations.\n&#8211; Validate with a short trial in a non-production account and observe usage metrics.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Example production cost considerations<\/h3>\n\n\n\n<p>In production, costs usually reflect:\n&#8211; Multiple accounts and Regions.\n&#8211; Broad recording scopes.\n&#8211; Many rules and conformance packs.\n&#8211; Remediation and event-driven automation.\n&#8211; Long-term S3 retention.<\/p>\n\n\n\n<p>A realistic enterprise cost model should be reviewed quarterly and aligned to governance outcomes (which rules provide value, what noise can be reduced).<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">10. Step-by-Step Hands-On Tutorial<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Objective<\/h3>\n\n\n\n<p>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.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Lab Overview<\/h3>\n\n\n\n<p>You will:\n1. Create an S3 bucket to store AWS Config data (securely).\n2. Create (or ensure) the AWS Config service-linked role exists.\n3. Create an AWS Config configuration recorder and delivery channel using AWS CLI.\n4. Start the recorder and verify configuration items are being delivered.\n5. Add a managed AWS Config rule (<code>required-tags<\/code>) to check required tags on S3 buckets.\n6. Create a test S3 bucket without required tags to observe noncompliance, then fix it.\n7. Clean up to stop charges.<\/p>\n\n\n\n<p>This lab is designed to be low-cost by recording only <strong>S3 buckets<\/strong> in a single Region, but charges may still apply. Don\u2019t leave AWS Config running unintentionally.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 1: Set environment variables and verify AWS CLI identity<\/h3>\n\n\n\n<p>Choose a Region where you want to run the lab (example: <code>us-east-1<\/code>).<\/p>\n\n\n\n<pre><code class=\"language-bash\">export AWS_REGION=\"us-east-1\"\nexport AWS_ACCOUNT_ID=\"$(aws sts get-caller-identity --query Account --output text)\"\naws sts get-caller-identity\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> You see your account ID, ARN, and user\/role in the output.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 2: Create an S3 bucket for AWS Config delivery (secure baseline)<\/h3>\n\n\n\n<p>Pick a globally unique bucket name.<\/p>\n\n\n\n<pre><code class=\"language-bash\">export CONFIG_BUCKET=\"my-aws-config-delivery-${AWS_ACCOUNT_ID}-${AWS_REGION}\"\naws s3api create-bucket \\\n  --bucket \"${CONFIG_BUCKET}\" \\\n  --region \"${AWS_REGION}\" \\\n  $( [ \"${AWS_REGION}\" = \"us-east-1\" ] &amp;&amp; echo \"\" || echo \"--create-bucket-configuration LocationConstraint=${AWS_REGION}\" )\n<\/code><\/pre>\n\n\n\n<p>Enable bucket versioning (recommended for audit artifacts):<\/p>\n\n\n\n<pre><code class=\"language-bash\">aws s3api put-bucket-versioning \\\n  --bucket \"${CONFIG_BUCKET}\" \\\n  --versioning-configuration Status=Enabled\n<\/code><\/pre>\n\n\n\n<p>Enable default encryption (SSE-S3). For SSE-KMS, verify the required KMS permissions and key policy.<\/p>\n\n\n\n<pre><code class=\"language-bash\">aws s3api put-bucket-encryption \\\n  --bucket \"${CONFIG_BUCKET}\" \\\n  --server-side-encryption-configuration '{\n    \"Rules\": [\n      {\n        \"ApplyServerSideEncryptionByDefault\": {\n          \"SSEAlgorithm\": \"AES256\"\n        }\n      }\n    ]\n  }'\n<\/code><\/pre>\n\n\n\n<p>Block public access:<\/p>\n\n\n\n<pre><code class=\"language-bash\">aws s3api put-public-access-block \\\n  --bucket \"${CONFIG_BUCKET}\" \\\n  --public-access-block-configuration '{\n    \"BlockPublicAcls\": true,\n    \"IgnorePublicAcls\": true,\n    \"BlockPublicPolicy\": true,\n    \"RestrictPublicBuckets\": true\n  }'\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> The bucket exists, is encrypted, versioned, and not publicly accessible.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 3: Add the S3 bucket policy that allows AWS Config to write<\/h3>\n\n\n\n<p>AWS Config needs permissions to:\n&#8211; Get bucket ACL\n&#8211; List bucket (for prefix checks)\n&#8211; Put objects into the AWS Config prefix with the correct ACL<\/p>\n\n\n\n<p>Apply a bucket policy (adjust if your organization uses stricter controls). This pattern follows AWS\u2019s typical recommended policy structure; verify the latest recommended policy in official docs for AWS Config S3 delivery.<\/p>\n\n\n\n<pre><code class=\"language-bash\">cat &gt; \/tmp\/aws-config-bucket-policy.json &lt;&lt;EOF\n{\n  \"Version\": \"2012-10-17\",\n  \"Statement\": [\n    {\n      \"Sid\": \"AWSConfigBucketPermissionsCheck\",\n      \"Effect\": \"Allow\",\n      \"Principal\": { \"Service\": \"config.amazonaws.com\" },\n      \"Action\": \"s3:GetBucketAcl\",\n      \"Resource\": \"arn:aws:s3:::${CONFIG_BUCKET}\"\n    },\n    {\n      \"Sid\": \"AWSConfigBucketExistenceCheck\",\n      \"Effect\": \"Allow\",\n      \"Principal\": { \"Service\": \"config.amazonaws.com\" },\n      \"Action\": \"s3:ListBucket\",\n      \"Resource\": \"arn:aws:s3:::${CONFIG_BUCKET}\"\n    },\n    {\n      \"Sid\": \"AWSConfigBucketDelivery\",\n      \"Effect\": \"Allow\",\n      \"Principal\": { \"Service\": \"config.amazonaws.com\" },\n      \"Action\": \"s3:PutObject\",\n      \"Resource\": \"arn:aws:s3:::${CONFIG_BUCKET}\/AWSLogs\/${AWS_ACCOUNT_ID}\/Config\/*\",\n      \"Condition\": {\n        \"StringEquals\": {\n          \"s3:x-amz-acl\": \"bucket-owner-full-control\"\n        }\n      }\n    }\n  ]\n}\nEOF\n\naws s3api put-bucket-policy \\\n  --bucket \"${CONFIG_BUCKET}\" \\\n  --policy file:\/\/\/tmp\/aws-config-bucket-policy.json\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> Bucket policy is applied successfully.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 4: Create (or verify) the AWS Config service-linked role<\/h3>\n\n\n\n<p>AWS Config commonly uses a service-linked role named <strong>AWSServiceRoleForConfig<\/strong>.<\/p>\n\n\n\n<p>Try creating it (if it already exists, AWS will return an error you can safely ignore).<\/p>\n\n\n\n<pre><code class=\"language-bash\">aws iam create-service-linked-role --aws-service-name config.amazonaws.com\n<\/code><\/pre>\n\n\n\n<p>If you get an \u201calready exists\u201d error, proceed.<\/p>\n\n\n\n<p><strong>Expected outcome:<\/strong> Service-linked role exists for AWS Config.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 5: Create the delivery channel<\/h3>\n\n\n\n<p>A delivery channel tells AWS Config where to deliver data (S3 is required; SNS is optional).<\/p>\n\n\n\n<p>Create a delivery channel named <code>default<\/code> (or another name). Many setups use <code>default<\/code>, but naming is up to you.<\/p>\n\n\n\n<pre><code class=\"language-bash\">cat &gt; \/tmp\/aws-config-delivery-channel.json &lt;&lt;EOF\n{\n  \"name\": \"default\",\n  \"s3BucketName\": \"${CONFIG_BUCKET}\",\n  \"s3KeyPrefix\": \"config\"\n}\nEOF\n\naws configservice put-delivery-channel \\\n  --delivery-channel file:\/\/\/tmp\/aws-config-delivery-channel.json \\\n  --region \"${AWS_REGION}\"\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> Delivery channel is created.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 6: Create the configuration recorder (record only S3 buckets)<\/h3>\n\n\n\n<p>To keep cost and noise low, record a narrow set of resource types. Here we record only S3 buckets.<\/p>\n\n\n\n<pre><code class=\"language-bash\">cat &gt; \/tmp\/aws-config-recorder.json &lt;&lt;EOF\n{\n  \"name\": \"default\",\n  \"roleARN\": \"arn:aws:iam::${AWS_ACCOUNT_ID}:role\/aws-service-role\/config.amazonaws.com\/AWSServiceRoleForConfig\",\n  \"recordingGroup\": {\n    \"allSupported\": false,\n    \"includeGlobalResourceTypes\": false,\n    \"resourceTypes\": [\"AWS::S3::Bucket\"]\n  }\n}\nEOF\n\naws configservice put-configuration-recorder \\\n  --configuration-recorder file:\/\/\/tmp\/aws-config-recorder.json \\\n  --region \"${AWS_REGION}\"\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> Recorder is created\/updated.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 7: Start the configuration recorder<\/h3>\n\n\n\n<pre><code class=\"language-bash\">aws configservice start-configuration-recorder \\\n  --configuration-recorder-name default \\\n  --region \"${AWS_REGION}\"\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> Recorder starts successfully.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 8: Verify AWS Config is running and delivering data<\/h3>\n\n\n\n<p>Check recorder status:<\/p>\n\n\n\n<pre><code class=\"language-bash\">aws configservice describe-configuration-recorder-status \\\n  --region \"${AWS_REGION}\"\n<\/code><\/pre>\n\n\n\n<p>Look for:\n&#8211; <code>recording: true<\/code>\n&#8211; <code>lastStatus: SUCCESS<\/code> (or similar)<\/p>\n\n\n\n<p>Check that objects are appearing in S3 (may take several minutes):<\/p>\n\n\n\n<pre><code class=\"language-bash\">aws s3 ls \"s3:\/\/${CONFIG_BUCKET}\/\" --recursive | head\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> You see AWS Config delivery objects under a prefix like:\n<code>AWSLogs\/&lt;account-id&gt;\/Config\/&lt;region&gt;\/...<\/code> and\/or your <code>s3KeyPrefix<\/code>.<\/p>\n\n\n\n<p>If you see nothing, wait 5\u201310 minutes and retry, especially right after first enablement.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 9: Create a managed AWS Config rule for required tags on S3 buckets<\/h3>\n\n\n\n<p>We\u2019ll use the managed rule <strong><code>required-tags<\/code><\/strong> and require two tags: <code>Owner<\/code> and <code>CostCenter<\/code>.<\/p>\n\n\n\n<pre><code class=\"language-bash\">cat &gt; \/tmp\/aws-config-rule-required-tags.json &lt;&lt;EOF\n{\n  \"ConfigRuleName\": \"s3-required-tags\",\n  \"Description\": \"Require Owner and CostCenter tags on S3 buckets\",\n  \"Scope\": {\n    \"ComplianceResourceTypes\": [\"AWS::S3::Bucket\"]\n  },\n  \"Source\": {\n    \"Owner\": \"AWS\",\n    \"SourceIdentifier\": \"REQUIRED_TAGS\"\n  },\n  \"InputParameters\": \"{ \\\"tag1Key\\\": \\\"Owner\\\", \\\"tag2Key\\\": \\\"CostCenter\\\" }\"\n}\nEOF\n\naws configservice put-config-rule \\\n  --config-rule file:\/\/\/tmp\/aws-config-rule-required-tags.json \\\n  --region \"${AWS_REGION}\"\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> The rule is created. Evaluation can take a few minutes.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 10: Create a test S3 bucket without tags and observe noncompliance<\/h3>\n\n\n\n<p>Create a new bucket:<\/p>\n\n\n\n<pre><code class=\"language-bash\">export TEST_BUCKET=\"aws-config-tag-test-${AWS_ACCOUNT_ID}-${AWS_REGION}\"\naws s3api create-bucket \\\n  --bucket \"${TEST_BUCKET}\" \\\n  --region \"${AWS_REGION}\" \\\n  $( [ \"${AWS_REGION}\" = \"us-east-1\" ] &amp;&amp; echo \"\" || echo \"--create-bucket-configuration LocationConstraint=${AWS_REGION}\" )\n<\/code><\/pre>\n\n\n\n<p>Wait a few minutes, then check compliance for the rule:<\/p>\n\n\n\n<pre><code class=\"language-bash\">aws configservice get-compliance-details-by-config-rule \\\n  --config-rule-name \"s3-required-tags\" \\\n  --compliance-types NON_COMPLIANT \\\n  --region \"${AWS_REGION}\"\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> The new bucket should appear as <code>NON_COMPLIANT<\/code> (after AWS Config records it and the rule evaluates it).<\/p>\n\n\n\n<p>If it doesn\u2019t show up yet:\n&#8211; Wait a few more minutes\n&#8211; Re-run the compliance query\n&#8211; Optionally trigger re-evaluation (not always necessary)<\/p>\n\n\n\n<p>You can also check overall rule compliance summary:<\/p>\n\n\n\n<pre><code class=\"language-bash\">aws configservice describe-compliance-by-config-rule \\\n  --config-rule-names \"s3-required-tags\" \\\n  --region \"${AWS_REGION}\"\n<\/code><\/pre>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 11: Fix the bucket by applying required tags<\/h3>\n\n\n\n<p>Add the required tags:<\/p>\n\n\n\n<pre><code class=\"language-bash\">aws s3api put-bucket-tagging \\\n  --bucket \"${TEST_BUCKET}\" \\\n  --tagging 'TagSet=[{Key=Owner,Value=PlatformTeam},{Key=CostCenter,Value=CC-1234}]' \\\n  --region \"${AWS_REGION}\"\n<\/code><\/pre>\n\n\n\n<p>Wait for re-evaluation (or trigger it).<\/p>\n\n\n\n<p>Trigger an on-demand evaluation:<\/p>\n\n\n\n<pre><code class=\"language-bash\">aws configservice start-config-rules-evaluation \\\n  --config-rule-names \"s3-required-tags\" \\\n  --region \"${AWS_REGION}\"\n<\/code><\/pre>\n\n\n\n<p>Now query compliant resources:<\/p>\n\n\n\n<pre><code class=\"language-bash\">aws configservice get-compliance-details-by-config-rule \\\n  --config-rule-name \"s3-required-tags\" \\\n  --compliance-types COMPLIANT \\\n  --region \"${AWS_REGION}\"\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> The test bucket becomes <code>COMPLIANT<\/code>.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Validation<\/h3>\n\n\n\n<p>Use this checklist:<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li>\n<p>Recorder status shows <code>recording: true<\/code>:\n   <code>bash\n   aws configservice describe-configuration-recorder-status --region \"${AWS_REGION}\"<\/code><\/p>\n<\/li>\n<li>\n<p>S3 bucket contains AWS Config objects:\n   <code>bash\n   aws s3 ls \"s3:\/\/${CONFIG_BUCKET}\/\" --recursive | head -n 20<\/code><\/p>\n<\/li>\n<li>\n<p>Rule exists and returns evaluations:\n   <code>bash\n   aws configservice describe-config-rules --config-rule-names \"s3-required-tags\" --region \"${AWS_REGION}\"\n   aws configservice describe-compliance-by-config-rule --config-rule-names \"s3-required-tags\" --region \"${AWS_REGION}\"<\/code><\/p>\n<\/li>\n<li>\n<p>Test bucket compliance changes after tagging.<\/p>\n<\/li>\n<\/ol>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Troubleshooting<\/h3>\n\n\n\n<p>Common issues and fixes:<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li>\n<p><strong><code>InsufficientDeliveryPolicyException<\/code> or delivery failures<\/strong>\n   &#8211; Cause: S3 bucket policy is missing or incorrect.\n   &#8211; Fix: Re-check the bucket policy statements and the resource ARN paths. Confirm the bucket is in the same account and the policy allows <code>config.amazonaws.com<\/code>.<\/p>\n<\/li>\n<li>\n<p><strong>Recorder won\u2019t start (<code>NoAvailableDeliveryChannelException<\/code>)<\/strong>\n   &#8211; Cause: You attempted to start the recorder before creating the delivery channel.\n   &#8211; Fix: Create delivery channel first, then start the recorder.<\/p>\n<\/li>\n<li>\n<p><strong>No objects appear in S3<\/strong>\n   &#8211; Cause: Initial delivery can take time; or resource scope is too narrow and there are no matching resources.\n   &#8211; Fix: Wait 5\u201315 minutes; create a resource of the recorded type (we created an S3 bucket); verify recorder status is <code>SUCCESS<\/code>.<\/p>\n<\/li>\n<li>\n<p><strong>Rule shows <code>INSUFFICIENT_DATA<\/code><\/strong>\n   &#8211; Cause: AWS Config hasn\u2019t recorded the resource yet, or rule evaluation hasn\u2019t run.\n   &#8211; Fix: Wait; trigger evaluation with <code>start-config-rules-evaluation<\/code>.<\/p>\n<\/li>\n<li>\n<p><strong>Access denied creating service-linked role<\/strong>\n   &#8211; Cause: Missing <code>iam:CreateServiceLinkedRole<\/code>.\n   &#8211; Fix: Use an admin role, or have your IAM admins create the role.<\/p>\n<\/li>\n<\/ol>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Cleanup<\/h3>\n\n\n\n<p>To avoid ongoing charges, remove the rule and stop AWS Config.<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li>\n<p>Delete the AWS Config rule:\n   <code>bash\n   aws configservice delete-config-rule \\\n     --config-rule-name \"s3-required-tags\" \\\n     --region \"${AWS_REGION}\"<\/code><\/p>\n<\/li>\n<li>\n<p>Stop the recorder:\n   <code>bash\n   aws configservice stop-configuration-recorder \\\n     --configuration-recorder-name default \\\n     --region \"${AWS_REGION}\"<\/code><\/p>\n<\/li>\n<li>\n<p>Delete delivery channel (must delete before recorder in many cases):\n   <code>bash\n   aws configservice delete-delivery-channel \\\n     --delivery-channel-name default \\\n     --region \"${AWS_REGION}\"<\/code><\/p>\n<\/li>\n<li>\n<p>Delete configuration recorder:\n   <code>bash\n   aws configservice delete-configuration-recorder \\\n     --configuration-recorder-name default \\\n     --region \"${AWS_REGION}\"<\/code><\/p>\n<\/li>\n<li>\n<p>Delete test bucket (must be empty first):\n   <code>bash\n   aws s3 rm \"s3:\/\/${TEST_BUCKET}\" --recursive\n   aws s3api delete-bucket --bucket \"${TEST_BUCKET}\" --region \"${AWS_REGION}\"<\/code><\/p>\n<\/li>\n<li>\n<p>Delete Config delivery bucket content and bucket:\n   <code>bash\n   aws s3 rm \"s3:\/\/${CONFIG_BUCKET}\" --recursive\n   aws s3api delete-bucket --bucket \"${CONFIG_BUCKET}\" --region \"${AWS_REGION}\"<\/code><\/p>\n<\/li>\n<li>\n<p>Optional: Keep the service-linked role (recommended in many orgs). If you must remove it, verify no other Region\/account usage depends on it.<\/p>\n<\/li>\n<\/ol>\n\n\n\n<h2 class=\"wp-block-heading\">11. Best Practices<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Architecture best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Use a multi-account strategy<\/strong>: separate workload accounts from a central security\/governance account.<\/li>\n<li><strong>Aggregate centrally<\/strong> using AWS Config aggregators for cross-account visibility.<\/li>\n<li><strong>Standardize baselines<\/strong> with conformance packs (version them and roll out progressively).<\/li>\n<li><strong>Design for exceptions<\/strong>: define how teams request exceptions (tags, parameter store allowlists, separate OUs, or rule logic).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">IAM\/security best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Prefer <strong>service-linked role<\/strong> unless you have strict custom requirements.<\/li>\n<li>Use <strong>least privilege<\/strong> for operators who manage rules vs. those who only view compliance.<\/li>\n<li>Protect S3 delivery bucket:<\/li>\n<li>Block public access<\/li>\n<li>Enforce encryption<\/li>\n<li>Restrict bucket policy to AWS Config service principal and your account<\/li>\n<li>Use <strong>SSE-KMS<\/strong> where required, but ensure KMS key policy allows AWS Config and operational users appropriately.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Cost best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Record only what you need<\/strong> (resource types) especially in dev\/test.<\/li>\n<li>Limit the number of rules to those that directly support risk reduction or audit requirements.<\/li>\n<li>Prefer managed rules when they meet requirements (less custom code to run and maintain).<\/li>\n<li>Use S3 lifecycle policies carefully (align with audit retention policies first).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Performance best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Avoid overly chatty automation triggered by every compliance event; filter by severity and environment.<\/li>\n<li>Tune periodic evaluations\u2014use change-triggered where appropriate.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Reliability best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Treat AWS Config setup as <strong>foundational governance<\/strong>:<\/li>\n<li>Deploy via Infrastructure as Code (CloudFormation\/Terraform\/CDK).<\/li>\n<li>Use CI\/CD to version rules and conformance packs.<\/li>\n<li>Use alarms\/notifications on recorder status failures (you can build operational checks around AWS Config APIs and EventBridge events).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Operations best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Establish a process for:<\/li>\n<li>Rule lifecycle (create \u2192 test \u2192 deploy \u2192 tune \u2192 retire)<\/li>\n<li>Handling false positives<\/li>\n<li>Managing remediation approvals and rollbacks<\/li>\n<li>Use consistent naming:<\/li>\n<li>Rule names: <code>env-domain-control<\/code> (e.g., <code>prod-s3-public-access-blocked<\/code>)<\/li>\n<li>Conformance packs: <code>baseline-security-v1<\/code><\/li>\n<li>Tag governance resources too (S3 buckets, SNS topics, automation functions).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Governance\/tagging\/naming best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Define required tags and enforce them via AWS Config plus IaC checks.<\/li>\n<li>Use AWS Organizations OUs to separate environments and apply different baselines per OU.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">12. Security Considerations<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Identity and access model<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>AWS Config service role<\/strong>: AWS Config assumes a role to deliver to S3\/SNS and to evaluate resources.<\/li>\n<li><strong>User\/automation access<\/strong>: Controlled by IAM policies for AWS Config APIs:<\/li>\n<li>Read-only roles for auditors<\/li>\n<li>Admin roles for governance\/platform team<\/li>\n<li><strong>Cross-account<\/strong>: Aggregators and organization deployments require explicit trust and authorizations.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Encryption<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>S3 delivery bucket encryption<\/strong>: Use SSE-S3 or SSE-KMS depending on requirements.<\/li>\n<li><strong>SNS encryption<\/strong> (if used): Consider SSE-KMS for SNS topics where mandated.<\/li>\n<li><strong>In transit<\/strong>: AWS service APIs use TLS.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Network exposure<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>AWS Config is managed and accessed via AWS APIs; your main exposure considerations are:<\/li>\n<li>Who can call AWS Config APIs<\/li>\n<li>Who can read the S3 delivered data<\/li>\n<li>Consider VPC endpoints if your environment restricts internet egress; verify AWS Config endpoint support in your Regions.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Secrets handling<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>AWS Config itself doesn\u2019t require you to store secrets.<\/li>\n<li>Custom rules\/remediation (Lambda, SSM) might\u2014use <strong>AWS Secrets Manager<\/strong> or <strong>SSM Parameter Store<\/strong> for secrets rather than embedding secrets in code.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Audit\/logging<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Enable <strong>AWS CloudTrail<\/strong> organization trails to log AWS Config API calls.<\/li>\n<li>Log and monitor changes to:<\/li>\n<li>Recorder settings<\/li>\n<li>Delivery channel destinations<\/li>\n<li>Rules and conformance packs<\/li>\n<li>Remediation configurations<\/li>\n<li>Consider a \u201cgovernance change approval\u201d workflow for modifications to AWS Config baselines.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Compliance considerations<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Map rules\/conformance packs to your control framework (CIS, NIST, ISO, SOC 2).<\/li>\n<li>Maintain evidence:<\/li>\n<li>S3 snapshots and delivered history<\/li>\n<li>Compliance reports from aggregators<\/li>\n<li>Ensure retention meets policy (S3 lifecycle must not delete evidence prematurely).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Common security mistakes<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Delivering to an S3 bucket without blocking public access.<\/li>\n<li>Allowing broad IAM permissions to disable AWS Config or delete rules.<\/li>\n<li>Auto-remediating production resources without guardrails\/approvals.<\/li>\n<li>Not enabling AWS Config in critical Regions (governance blind spots).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Secure deployment recommendations<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Use a dedicated, locked-down S3 bucket for delivery with strict bucket policy.<\/li>\n<li>Use AWS Organizations and delegated admin to centralize governance.<\/li>\n<li>Deploy and manage AWS Config settings using IaC and change control.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">13. Limitations and Gotchas<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Known limitations \/ boundaries<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>AWS Config only records <strong>supported resource types<\/strong> and only the properties it is designed to track.<\/li>\n<li>Some resources are global or have special recording considerations.<\/li>\n<li>Rule evaluation timing is not always immediate; expect eventual consistency.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Quotas<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Quotas exist for rules, conformance packs, aggregators, and more. Values can change.<\/li>\n<li>Always check <strong>Service Quotas<\/strong> in your account\/Region for AWS Config.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Regional constraints<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Not all Regions may support every AWS Config capability equally.<\/li>\n<li>Verify feature availability (for example, specific managed rules, remediation actions, organization features) in official docs for your Regions.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Pricing surprises<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Recording \u201call supported resource types\u201d across many Regions can generate significant configuration items.<\/li>\n<li>Periodic rules across many resources can generate high evaluation counts.<\/li>\n<li>S3 storage and KMS usage can grow quietly over time.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Compatibility issues<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Custom rules require maintaining Lambda runtime compatibility and permissions.<\/li>\n<li>Remediation actions can fail if IAM permissions or resource constraints prevent changes.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Operational gotchas<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>You must create a <strong>delivery channel<\/strong> before starting the recorder.<\/li>\n<li>Deleting AWS Config components has dependencies (stop recorder, delete delivery channel, etc.).<\/li>\n<li>High-volume environments can generate many notifications; plan filtering and routing.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Migration challenges<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>If migrating from ad-hoc scripts or third-party tooling, the main work is:<\/li>\n<li>Defining rule intent<\/li>\n<li>Handling exceptions<\/li>\n<li>Mapping policies to managed rules or building custom rules<\/li>\n<li>Managing rollout without breaking teams<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Vendor-specific nuances<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>AWS Config is AWS-native and integrates deeply with AWS services; cross-cloud governance requires additional tooling (see comparisons).<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">14. Comparison with Alternatives<\/h2>\n\n\n\n<p>AWS Config is best compared with services that provide governance, compliance checks, and configuration tracking.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Comparison table<\/h3>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Option<\/th>\n<th>Best For<\/th>\n<th>Strengths<\/th>\n<th>Weaknesses<\/th>\n<th>When to Choose<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td><strong>AWS Config<\/strong><\/td>\n<td>AWS resource configuration history + compliance<\/td>\n<td>Native AWS integration; config timeline; managed\/custom rules; conformance packs; aggregators<\/td>\n<td>Cost can grow at scale; only supported resource types; eventual consistency<\/td>\n<td>You need continuous compliance + config history in AWS<\/td>\n<\/tr>\n<tr>\n<td><strong>AWS CloudTrail<\/strong><\/td>\n<td>API activity auditing (\u201cwho did what\u201d)<\/td>\n<td>Strong audit trail; forensic detail; integrates with detection tooling<\/td>\n<td>Not a configuration state database; doesn\u2019t directly evaluate compliance<\/td>\n<td>Use alongside Config for investigations and audit<\/td>\n<\/tr>\n<tr>\n<td><strong>AWS Security Hub<\/strong><\/td>\n<td>Security posture management and findings aggregation<\/td>\n<td>Centralizes findings across services; compliance standards views<\/td>\n<td>Depends on other data sources; not a full config history system<\/td>\n<td>Use for security reporting; pair with Config for governance controls<\/td>\n<\/tr>\n<tr>\n<td><strong>AWS Systems Manager<\/strong><\/td>\n<td>Ops management + automation<\/td>\n<td>Remediation automation; patching; inventory; runbooks<\/td>\n<td>Not a compliance evaluator by itself<\/td>\n<td>Use for remediation actions triggered by Config<\/td>\n<\/tr>\n<tr>\n<td><strong>Azure Policy (Microsoft Azure)<\/strong><\/td>\n<td>Azure governance and compliance<\/td>\n<td>Strong policy-as-code, enforcement modes<\/td>\n<td>Azure-specific<\/td>\n<td>Multi-cloud orgs: use Azure Policy in Azure; use Config in AWS<\/td>\n<\/tr>\n<tr>\n<td><strong>Google Cloud Organization Policy \/ Cloud Asset Inventory<\/strong><\/td>\n<td>GCP governance and asset inventory<\/td>\n<td>Org-level constraints; asset visibility<\/td>\n<td>GCP-specific; different model than AWS Config rules<\/td>\n<td>Use in GCP; combine with AWS Config for multi-cloud<\/td>\n<\/tr>\n<tr>\n<td><strong>Cloud Custodian (open source)<\/strong><\/td>\n<td>Multi-cloud policy automation<\/td>\n<td>Flexible; supports multiple clouds<\/td>\n<td>Requires hosting\/ops; policy maintenance<\/td>\n<td>When you want cross-cloud policies with self-managed control<\/td>\n<\/tr>\n<tr>\n<td><strong>OPA \/ policy-as-code in CI<\/strong><\/td>\n<td>Prevent misconfigurations before deploy<\/td>\n<td>Fast feedback; shift-left<\/td>\n<td>Doesn\u2019t track post-deploy drift alone<\/td>\n<td>Combine with AWS Config for continuous drift\/compliance<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<h2 class=\"wp-block-heading\">15. Real-World Example<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Enterprise example (regulated organization)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> 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.<\/li>\n<li><strong>Proposed architecture:<\/strong><\/li>\n<li>Enable AWS Config in all required Regions in all workload accounts.<\/li>\n<li>Use AWS Organizations to manage multi-account governance.<\/li>\n<li>Deploy <strong>organization conformance packs<\/strong> (baseline security controls) to all OUs; apply stricter packs to production OUs.<\/li>\n<li>Configure a <strong>central AWS Config aggregator<\/strong> in the security account to collect compliance and configuration data.<\/li>\n<li>Route compliance change events to EventBridge and create tickets for critical noncompliance.<\/li>\n<li>Use Systems Manager Automation for safe, pre-approved remediations (e.g., enforce S3 public access block) and require approvals for high-risk remediations.<\/li>\n<li><strong>Why AWS Config was chosen:<\/strong><\/li>\n<li>Native configuration history and compliance evaluation.<\/li>\n<li>Scales across accounts\/Regions using aggregators and organization patterns.<\/li>\n<li>Strong audit evidence story via delivered S3 history\/snapshots.<\/li>\n<li><strong>Expected outcomes:<\/strong><\/li>\n<li>Reduced audit time and faster evidence gathering.<\/li>\n<li>Faster detection of misconfigurations and reduced risk window.<\/li>\n<li>Centralized compliance dashboards for leadership and auditors.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Startup\/small-team example (lean operations)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> 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.<\/li>\n<li><strong>Proposed architecture:<\/strong><\/li>\n<li>Enable AWS Config in one primary Region for production.<\/li>\n<li>Record only key resource types (S3, security groups, IAM-related where needed\u2014verify supported types).<\/li>\n<li>Add 5\u201310 high-value managed rules: S3 public access, encryption checks, open security group ports, required tags.<\/li>\n<li>Notify a Slack\/email channel via SNS when critical rules become noncompliant.<\/li>\n<li><strong>Why AWS Config was chosen:<\/strong><\/li>\n<li>Minimal operational overhead compared to self-hosted governance.<\/li>\n<li>Immediate value: visibility into changes and basic compliance.<\/li>\n<li><strong>Expected outcomes:<\/strong><\/li>\n<li>Fewer \u201cmystery changes\u201d during incidents.<\/li>\n<li>Improved cost allocation and ownership through tagging compliance.<\/li>\n<li>A governance foundation that can scale later with conformance packs and aggregation.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">16. FAQ<\/h2>\n\n\n\n<ol class=\"wp-block-list\">\n<li>\n<p><strong>Is AWS Config the same as AWS CloudTrail?<\/strong><br\/>\n   No. CloudTrail logs API activity (who called what). AWS Config records resource configuration state and changes over time and evaluates compliance.<\/p>\n<\/li>\n<li>\n<p><strong>Do I need an S3 bucket for AWS Config?<\/strong><br\/>\n   Yes. AWS Config uses a delivery channel that delivers configuration history and snapshots to an S3 bucket.<\/p>\n<\/li>\n<li>\n<p><strong>Is AWS Config regional or global?<\/strong><br\/>\n   AWS Config is configured per Region. Some global resource types can be recorded, typically in a designated Region\u2014verify the current behavior in official docs for the resource types you care about.<\/p>\n<\/li>\n<li>\n<p><strong>Can AWS Config work across multiple AWS accounts?<\/strong><br\/>\n   Yes. Common patterns include using AWS Organizations features and a configuration aggregator in a central account.<\/p>\n<\/li>\n<li>\n<p><strong>What\u2019s the difference between AWS Config rules and conformance packs?<\/strong><br\/>\n   Rules are individual compliance checks. Conformance packs bundle multiple rules (and optional remediation settings) into a deployable unit.<\/p>\n<\/li>\n<li>\n<p><strong>Does AWS Config prevent noncompliant resources from being created?<\/strong><br\/>\n   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.<\/p>\n<\/li>\n<li>\n<p><strong>How quickly does AWS Config detect changes?<\/strong><br\/>\n   It\u2019s near-real-time for many changes, but not guaranteed instantaneous. Expect some delay (eventual consistency).<\/p>\n<\/li>\n<li>\n<p><strong>Can I write custom compliance logic?<\/strong><br\/>\n   Yes. You can create custom rules, typically using AWS Lambda to evaluate resources.<\/p>\n<\/li>\n<li>\n<p><strong>Does AWS Config store configuration history forever?<\/strong><br\/>\n   AWS Config retains configuration history according to its service behavior and your S3 retention policies. Retention details and limits can change\u2014verify in official docs, and ensure your S3 lifecycle policies align with audit requirements.<\/p>\n<\/li>\n<li>\n<p><strong>How do I reduce AWS Config costs?<\/strong><br\/>\n   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.<\/p>\n<\/li>\n<li>\n<p><strong>Can AWS Config auto-remediate issues?<\/strong><br\/>\n   Yes, in many cases via remediation actions (often Systems Manager Automation). Not all rules\/resources support remediation; test carefully.<\/p>\n<\/li>\n<li>\n<p><strong>Does AWS Config support Kubernetes (EKS) resources?<\/strong><br\/>\n   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.<\/p>\n<\/li>\n<li>\n<p><strong>Can I get notified when a resource becomes noncompliant?<\/strong><br\/>\n   Yes. Use SNS or EventBridge to react to compliance change events.<\/p>\n<\/li>\n<li>\n<p><strong>Is AWS Config required for SOC 2 \/ ISO 27001?<\/strong><br\/>\n   Not required, but commonly used to provide evidence and continuous monitoring for relevant controls. Your requirements depend on your auditors and control design.<\/p>\n<\/li>\n<li>\n<p><strong>What\u2019s a good minimal starting set of AWS Config rules?<\/strong><br\/>\n   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.<\/p>\n<\/li>\n<li>\n<p><strong>Can I export AWS Config data for analytics?<\/strong><br\/>\n   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).<\/p>\n<\/li>\n<li>\n<p><strong>How does AWS Config relate to AWS Organizations SCPs?<\/strong><br\/>\n   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.<\/p>\n<\/li>\n<\/ol>\n\n\n\n<h2 class=\"wp-block-heading\">17. Top Online Resources to Learn AWS Config<\/h2>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Resource Type<\/th>\n<th>Name<\/th>\n<th>Why It Is Useful<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>Official documentation<\/td>\n<td>AWS Config Developer Guide<\/td>\n<td>Primary reference for concepts, setup, rules, aggregators, and APIs: https:\/\/docs.aws.amazon.com\/config\/latest\/developerguide\/WhatIsConfig.html<\/td>\n<\/tr>\n<tr>\n<td>Official pricing<\/td>\n<td>AWS Config Pricing<\/td>\n<td>Accurate, region-specific pricing model: https:\/\/aws.amazon.com\/config\/pricing\/<\/td>\n<\/tr>\n<tr>\n<td>Pricing tool<\/td>\n<td>AWS Pricing Calculator<\/td>\n<td>Model costs for configuration items and rule evaluations: https:\/\/calculator.aws\/#\/<\/td>\n<\/tr>\n<tr>\n<td>Official rule reference<\/td>\n<td>AWS Managed Rules List<\/td>\n<td>Shows available managed rules and parameters (verify current list): https:\/\/docs.aws.amazon.com\/config\/latest\/developerguide\/managed-rules-by-aws-config.html<\/td>\n<\/tr>\n<tr>\n<td>Official getting started<\/td>\n<td>Getting Started with AWS Config<\/td>\n<td>Step-by-step enablement guidance (console and concepts): https:\/\/docs.aws.amazon.com\/config\/latest\/developerguide\/gs-console.html<\/td>\n<\/tr>\n<tr>\n<td>Official API reference<\/td>\n<td>AWS Config API Reference<\/td>\n<td>For automation and tooling: https:\/\/docs.aws.amazon.com\/config\/latest\/APIReference\/<\/td>\n<\/tr>\n<tr>\n<td>CLI reference<\/td>\n<td>AWS CLI \u2013 configservice commands<\/td>\n<td>Copy\/paste commands and options: https:\/\/docs.aws.amazon.com\/cli\/latest\/reference\/configservice\/<\/td>\n<\/tr>\n<tr>\n<td>Architecture guidance<\/td>\n<td>AWS Architecture Center<\/td>\n<td>Patterns and best practices; search for governance\/compliance: https:\/\/aws.amazon.com\/architecture\/<\/td>\n<\/tr>\n<tr>\n<td>Official videos<\/td>\n<td>AWS YouTube Channel<\/td>\n<td>Talks, demos, governance best practices (search \u201cAWS Config\u201d): https:\/\/www.youtube.com\/@AmazonWebServices<\/td>\n<\/tr>\n<tr>\n<td>Samples<\/td>\n<td>AWS Samples on GitHub (search)<\/td>\n<td>Reference implementations and automation patterns (validate repo trust): https:\/\/github.com\/aws-samples<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<h2 class=\"wp-block-heading\">18. Training and Certification Providers<\/h2>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Institute<\/th>\n<th>Suitable Audience<\/th>\n<th>Likely Learning Focus<\/th>\n<th>Mode<\/th>\n<th>Website URL<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>DevOpsSchool.com<\/td>\n<td>Beginners to experienced DevOps\/Cloud engineers<\/td>\n<td>AWS governance, DevOps practices, hands-on labs<\/td>\n<td>Check website<\/td>\n<td>https:\/\/www.devopsschool.com\/<\/td>\n<\/tr>\n<tr>\n<td>ScmGalaxy.com<\/td>\n<td>DevOps, build\/release, and tooling learners<\/td>\n<td>SCM\/DevOps foundations plus cloud governance topics<\/td>\n<td>Check website<\/td>\n<td>https:\/\/www.scmgalaxy.com\/<\/td>\n<\/tr>\n<tr>\n<td>CLoudOpsNow.in<\/td>\n<td>CloudOps\/operations teams<\/td>\n<td>Operations, monitoring, governance, cost awareness<\/td>\n<td>Check website<\/td>\n<td>https:\/\/www.cloudopsnow.in\/<\/td>\n<\/tr>\n<tr>\n<td>SreSchool.com<\/td>\n<td>SREs and reliability-focused engineers<\/td>\n<td>Reliability engineering, operations, governance integration<\/td>\n<td>Check website<\/td>\n<td>https:\/\/www.sreschool.com\/<\/td>\n<\/tr>\n<tr>\n<td>AiOpsSchool.com<\/td>\n<td>Ops teams exploring AIOps<\/td>\n<td>Automation, operations analytics, governance signals<\/td>\n<td>Check website<\/td>\n<td>https:\/\/www.aiopsschool.com\/<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<h2 class=\"wp-block-heading\">19. Top Trainers<\/h2>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Platform\/Site<\/th>\n<th>Likely Specialization<\/th>\n<th>Suitable Audience<\/th>\n<th>Website URL<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>RajeshKumar.xyz<\/td>\n<td>DevOps\/cloud coaching and workshops (verify offerings)<\/td>\n<td>Individuals and teams seeking practical mentoring<\/td>\n<td>https:\/\/www.rajeshkumar.xyz\/<\/td>\n<\/tr>\n<tr>\n<td>devopstrainer.in<\/td>\n<td>DevOps and cloud training programs (verify offerings)<\/td>\n<td>Beginners to intermediate engineers<\/td>\n<td>https:\/\/www.devopstrainer.in\/<\/td>\n<\/tr>\n<tr>\n<td>devopsfreelancer.com<\/td>\n<td>Freelance DevOps consulting\/training (verify offerings)<\/td>\n<td>Teams needing short-term enablement<\/td>\n<td>https:\/\/www.devopsfreelancer.com\/<\/td>\n<\/tr>\n<tr>\n<td>devopssupport.in<\/td>\n<td>DevOps support and training resources (verify offerings)<\/td>\n<td>Operations teams and practitioners<\/td>\n<td>https:\/\/www.devopssupport.in\/<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<h2 class=\"wp-block-heading\">20. Top Consulting Companies<\/h2>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Company<\/th>\n<th>Likely Service Area<\/th>\n<th>Where They May Help<\/th>\n<th>Consulting Use Case Examples<\/th>\n<th>Website URL<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>cotocus.com<\/td>\n<td>Cloud\/DevOps consulting (verify exact services)<\/td>\n<td>Governance design, AWS foundations, automation<\/td>\n<td>Multi-account landing zone improvements; governance rollout planning; compliance reporting setup<\/td>\n<td>https:\/\/www.cotocus.com\/<\/td>\n<\/tr>\n<tr>\n<td>DevOpsSchool.com<\/td>\n<td>DevOps and cloud consulting\/training<\/td>\n<td>Governance implementation, DevOps operating model<\/td>\n<td>AWS Config rollout with conformance packs; rule tuning; remediation pipelines<\/td>\n<td>https:\/\/www.devopsschool.com\/<\/td>\n<\/tr>\n<tr>\n<td>DEVOPSCONSULTING.IN<\/td>\n<td>DevOps consulting services (verify exact services)<\/td>\n<td>Cloud operations and governance<\/td>\n<td>CI\/CD + compliance guardrails; tagging standards enforcement; audit evidence workflows<\/td>\n<td>https:\/\/www.devopsconsulting.in\/<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<h2 class=\"wp-block-heading\">21. Career and Learning Roadmap<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">What to learn before AWS Config<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>AWS fundamentals: accounts, Regions, IAM, VPC, EC2, S3<\/li>\n<li>IAM policy basics (allow\/deny, least privilege, roles)<\/li>\n<li>Logging basics: CloudTrail and CloudWatch<\/li>\n<li>Infrastructure as Code basics (CloudFormation\/Terraform) to manage governance as code<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">What to learn after AWS Config<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>AWS Organizations advanced governance (SCPs, delegated admin patterns)<\/li>\n<li>AWS Security Hub and detective controls strategy<\/li>\n<li>Event-driven automation: EventBridge + Lambda + Systems Manager Automation<\/li>\n<li>Policy as code in CI\/CD (OPA, tfsec\/checkov, cfn-lint, etc.)<\/li>\n<li>Data analytics on S3-delivered governance evidence (Athena\/Glue) if needed<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Job roles that use AWS Config<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Cloud Platform Engineer<\/li>\n<li>Cloud Security Engineer \/ Security Architect<\/li>\n<li>DevOps Engineer \/ SRE<\/li>\n<li>Governance, Risk, and Compliance (GRC) technical roles<\/li>\n<li>Solutions Architect (especially in regulated environments)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Certification path (AWS)<\/h3>\n\n\n\n<p>There is no certification dedicated only to AWS Config, but it\u2019s relevant to:\n&#8211; AWS Certified Solutions Architect (Associate\/Professional)\n&#8211; AWS Certified SysOps Administrator \u2013 Associate\n&#8211; AWS Certified DevOps Engineer \u2013 Professional\n&#8211; AWS Certified Security \u2013 Specialty<br\/>\nVerify current AWS certification names and availability: https:\/\/aws.amazon.com\/certification\/<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Project ideas for practice<\/h3>\n\n\n\n<ol class=\"wp-block-list\">\n<li><strong>Baseline conformance pack rollout<\/strong> in a multi-account org (dev \u2192 staging \u2192 prod).<\/li>\n<li><strong>Automated remediation<\/strong> for a safe control (e.g., enforce S3 public access block) with approval gates.<\/li>\n<li><strong>Drift detection pipeline<\/strong>: AWS Config events \u2192 EventBridge \u2192 ticket\/Slack \u2192 IaC PR to revert.<\/li>\n<li><strong>Tag governance program<\/strong>: required tags + exception tagging + compliance reporting dashboard.<\/li>\n<li><strong>Central aggregator + reporting<\/strong>: aggregate compliance into a security account and build periodic reports.<\/li>\n<\/ol>\n\n\n\n<h2 class=\"wp-block-heading\">22. Glossary<\/h2>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>AWS Config<\/strong>: AWS service for recording resource configurations, tracking changes, and evaluating compliance.<\/li>\n<li><strong>Configuration recorder<\/strong>: AWS Config component that records configuration changes for selected resource types.<\/li>\n<li><strong>Delivery channel<\/strong>: AWS Config component that delivers configuration history and snapshots to S3 (and optionally sends notifications to SNS).<\/li>\n<li><strong>Configuration item (CI)<\/strong>: A point-in-time representation of a resource\u2019s configuration recorded by AWS Config.<\/li>\n<li><strong>AWS Config Rule<\/strong>: A compliance check that evaluates whether resources meet desired configuration requirements.<\/li>\n<li><strong>Managed rule<\/strong>: A predefined rule provided by AWS.<\/li>\n<li><strong>Custom rule<\/strong>: A rule with custom evaluation logic (commonly backed by AWS Lambda).<\/li>\n<li><strong>Conformance Pack<\/strong>: A deployable collection of rules (and optional remediation settings) representing a compliance standard or baseline.<\/li>\n<li><strong>Configuration aggregator<\/strong>: A component that collects configuration and compliance data across accounts and Regions.<\/li>\n<li><strong>Compliance status<\/strong>: Result of evaluating a resource against a rule (e.g., COMPLIANT \/ NON_COMPLIANT \/ INSUFFICIENT_DATA).<\/li>\n<li><strong>Remediation action<\/strong>: An automated action that attempts to fix noncompliance (often through Systems Manager Automation).<\/li>\n<li><strong>AWS Organizations<\/strong>: Service for managing multiple AWS accounts with centralized governance.<\/li>\n<li><strong>SCP (Service Control Policy)<\/strong>: Organization-level policy that limits what actions accounts can perform.<\/li>\n<li><strong>EventBridge<\/strong>: Event bus service used to route AWS service events to targets for automation.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">23. Summary<\/h2>\n\n\n\n<p>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.<\/p>\n\n\n\n<p>Cost is driven mainly by <strong>configuration items recorded<\/strong> and <strong>rule evaluations<\/strong>, 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.<\/p>\n\n\n\n<p>Use AWS Config when you need configuration history and continuous compliance in AWS\u2014especially 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.<\/p>\n\n\n\n<p>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.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Management and governance<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[20,33],"tags":[],"class_list":["post-259","post","type-post","status-publish","format-standard","hentry","category-aws","category-management-and-governance"],"_links":{"self":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/posts\/259","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/comments?post=259"}],"version-history":[{"count":0,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/posts\/259\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/media?parent=259"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/categories?post=259"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/tags?post=259"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}