# Security Governance, Compliance, and AWS Config

> Chapter 14 of the Courseiva AWS-SECURITY-SPECIALTY curriculum — https://courseiva.com/learn/aws-security-specialty/security-governance-and-compliance

**Official objective:** 5.1 — Design and implement security governance and compliance controls

## Introduction

Security governance and compliance: the boring-sounding but absolutely vital rules that keep your cloud environment from turning into a free-for-all.  Without them, you have no way to prove to auditors, customers, or regulators that your systems are secure — and in the AWS Certified Security Specialty exam, designing these controls is the entire point of Domain 5.1.

## The Restaurant Health Inspector Analogy

Have you ever wondered why restaurants have those letter grades in the window?  That grade is the result of a health inspector checking the restaurant against a fixed set of rules — proper food storage temperatures, hand-washing sinks, pest control logs.  The restaurant doesn't get to make up its own rules; it must follow the local health code or risk being shut down.  In the cloud world, that health code is your compliance framework (like PCI DSS for credit card data or HIPAA for medical records), and the inspector is AWS Config.

AWS Config continuously records every change to your cloud kitchen — every new server you spin up (a virtual machine called an EC2 instance), every security group rule you open (like unlocking a back door), every storage bucket you make public.  It then compares your current setup against a set of rules you define, called 'Config rules'.  If Config spots a violation — for example, a storage bucket that should be private but is open to the whole internet — it flags it immediately, just like an inspector writing up a violation.  You can even set it to auto-remediate (automatically fix the problem), like a restaurant manager rushing to close a door that was left ajar.  The inspector doesn't run your kitchen; it just watches, records, and reports — and that's exactly what AWS Config does for governance and compliance.

## Core explanation

In the simplest possible terms, security governance is the set of policies that dictate who can do what, when, and how in your AWS account.  Compliance is the act of proving you are following those policies.  AWS Config is the tool that does the proving for you, automatically.

Let's start with a fundamental concept: an AWS account is like a digital castle.  Inside that castle, you have resources — virtual servers (EC2 instances), storage buckets (S3 buckets), databases, networking rules (security groups), and hundreds of other building blocks.  Left unattended, anyone with access could create, modify, or delete these resources in ways that break your security policies.  Security governance is the castle's rulebook: "No one may leave the front gate unlocked after sunset.  All treasure chests must have a lock.  Each guard must log their patrol."

AWS Config is the castle's automated watchman.  It continuously records the state of every resource it is enabled on.  This recording is called a configuration item (CI) — a snapshot of a resource at a point in time.  Every time a resource changes — someone opens a port on a security group, attaches a new storage volume, changes a bucket's permissions — Config takes a new snapshot and stores it.  This history allows you to see exactly what changed, when, and who made the change (via AWS CloudTrail, the audit log service).

Now, compliance.  Compliance frameworks are external rulebooks that organisations choose to follow.  Common ones include:
- PCI DSS (Payment Card Industry Data Security Standard) — for handling credit card data.
- HIPAA (Health Insurance Portability and Accountability Act) — for medical information.
- SOC 2 (System and Organisation Controls) — for data privacy and security practices.
- ISO 27001 — an international standard for information security management.

Each framework has hundreds of specific controls.  For example, PCI DSS Requirement 7 states you must restrict access to cardholder data on a need-to-know basis.  How do you prove you are doing that?  AWS Config can run a managed rule called "iam-user-no-policies-check" that detects any IAM user who has permissions not assigned through a group or role — a clear violation of the principle of least privilege.

This is where Config rules come in.  A Config rule is a piece of logic — either a predefined rule from AWS (a managed rule) or one you write yourself (a custom rule using AWS Lambda, a serverless compute service).  The rule evaluates your resources and reports whether they are COMPLIANT or NON_COMPLIANT.  For instance, a rule might check that every S3 bucket has versioning enabled (to prevent accidental deletion).  If you create a bucket without versioning, Config flags it as NON_COMPLIANT within minutes.

Governance goes beyond checking.  It also includes remediation — fixing non-compliant resources automatically.  AWS Config can trigger an AWS Systems Manager Automation document — a pre-written script — to perform actions like closing an open security group port or enabling encryption on a storage volume.  This is called auto-remediation.

Finally, aggregating Config data across multiple accounts and regions is handled by a feature called Config Aggregator.  If your organisation has 50 AWS accounts, you don't want to log into each one to check compliance.  Aggregator collects all that data in one central view.

In summary, AWS Config is the continuous compliance monitoring service that gives you visibility into what exists in your account, what rules it should follow, and whether it is actually following them.  It replaces the old, error-prone method of manually checking resources or writing custom scripts that nobody maintains.

## Real-world context

Meet Priya, a cloud security engineer at a healthcare startup called MediSecure.  They handle patient records, so they must comply with HIPAA.  Priya has just been told the company needs to pass a third-party audit next quarter.  She has never used AWS Config before.  Here is exactly what she does:

First, Priya enables AWS Config in the us-east-1 (North Virginia) region.  She must do this per region if she wants coverage everywhere.  She selects all resource types to record — EC2, S3, IAM, RDS (database), and more.  Config starts recording immediately, creating a configuration history that goes back to the moment she turned it on.

Second, she sets up a Config rule for HIPAA compliance.  AWS provides a bunch of managed rules under the "HIPAA Security" conformance pack.  A conformance pack is a collection of rules and remediation actions bundled together for a specific standard.  Priya selects the pack and deploys it.  It automatically creates dozens of rules, such as:
- ec2-ebs-encryption-by-default (every storage volume must be encrypted)
- rest-api-logging-enabled (API calls must be logged)
- iam-policy-no-statements-with-admin-access (no IAM policy should give full admin to everyone)

Almost immediately, Priya sees a red flag: three EC2 instances have unencrypted storage volumes.  The rule shows them as NON_COMPLIANT.  Config gives her a link to the specific resource ID.

Third, she sets up auto-remediation.  For the unencrypted volume rule, she attaches an AWS Systems Manager Automation document called "AWSConfigRemediation-EnableEncryptVolume".  This document snaps a picture of the volume, creates an encrypted copy, and swaps it in — all without downtime.  Now, if someone creates a non-compliant volume, Config fixes it automatically within minutes.

Fourth, Priya needs to see compliance across all departments.  The company has three AWS accounts — development, staging, and production.  She sets up a Config Aggregator in a central "audit" account and authorises the other accounts to send their Config data there.  Now she can generate a single dashboard showing compliance status across the entire organisation.

Finally, the auditor asks for evidence.  Priya goes to the Config dashboard, selects a timeframe, and downloads a compliance report.  She can also pull a configuration timeline for any specific resource to show every change made in the last 90 days.  The auditor is satisfied because the evidence is automated, timestamped, and immutable — no one can retroactively modify Config logs.

Priya's daily work now includes checking compliance reports, tuning rules (e.g., adjusting thresholds for what counts as "unencrypted"), and responding to alerts when resources become non-compliant.  AWS Config has given her a powerful tool to enforce governance without manually checking every server.

## Exam focus

The SCS-C02 exam loves AWS Config.  Domain 5.1 — Design and implement security governance and compliance controls — is heavily focused on how to use Config to prove compliance.  Expect at least 5–7 questions on this topic across the exam.  Here is what you absolutely must know:

First, managed rules vs. custom rules.  The exam will test whether you know when to use a managed rule (AWS-provided, no coding needed) versus a custom rule (written in Python or Node.js using AWS Lambda).  Managed rules cover common scenarios like encryption checks, logging checks, and IAM best practices.  Custom rules are needed when your organisation has a proprietary policy — for example, "all EC2 instances must have a tag called 'CostCenter' with a value matching the finance department's list."  A custom rule would need to call out to a database to verify the value.

Second, conformance packs.  These are bundles of Config rules and remediation actions designed for specific compliance frameworks (CIS, NIST, HIPAA, PCI DSS).  The exam will ask you which conformance pack to use for a given regulation.  Memorise the major ones: CIS AWS Foundations, NIST 800-53, HIPAA Security, PCI DSS v3.2.1.

Third, remediation.  The exam tests whether you know that auto-remediation uses AWS Systems Manager Automation documents (SSM documents).  Config cannot fix issues by itself; it triggers an automation workflow.  You may see a question where the correct answer involves creating an SSM document and attaching it to a Config rule.

Fourth, Config vs. other services.  The exam loves to confuse you with similar-sounding services:
- AWS CloudTrail: records API calls (who did what, when).  It is about actions, not resource state.
- AWS Security Hub: aggregates security findings from multiple services (Config, GuardDuty, Inspector) into a single dashboard.  It shows high-level security posture.
- AWS Config: records resource configurations and evaluates them against rules.  It is about state, not actions.

Common traps:
- The exam will ask: "Which service can monitor configuration changes to S3 buckets?"  Some candidates pick CloudTrail.  Wrong.  CloudTrail records the API call to change the bucket policy, but Config records the actual configuration after the change and can check if it violates a rule.
- They might say: "You need to ensure all EBS volumes are encrypted.  Which service?"  Answer: AWS Config with a managed rule (ec2-ebs-encryption-by-default).  Not a Lambda function directly.
- They might test: "You have 10 accounts and need a central compliance view.  What feature?"  Answer: Config Aggregator — not Security Hub (though Security Hub can also aggregate, but the question will specifically reference Config data).

Key definitions to memorise:
- Configuration item (CI): a snapshot of a resource's configuration at a point in time.
- Configuration history: a collection of CIs over time (up to 7 years, if you configure it to stream to S3).
- Config rule: a rule that evaluates your resources against a desired configuration.
- Evaluation: the periodic or triggered check of a resource against a rule (returns COMPLIANT or NON_COMPLIANT).
- Remediation: the automatic or manual action to fix a non-compliant resource.
- Conformance pack: a collection of rules and remediations for a specific compliance framework.

Finally, remember that Config is regional — you must enable it per region.  To cover all regions, you typically use an AWS Organization and enable Config in every region.  The exam will give a scenario where a company has resources in multiple regions but only enabled Config in one region, and ask what is wrong.

## Step by step

1. **Enable AWS Config** — Navigate to the AWS Config console and click 'Get started'. Choose which resource types to record (e.g., EC2, S3, IAM). You can record all resources or a subset. Also decide where to store the configuration history (an S3 bucket) and whether to stream updates to an SNS topic. This step makes Config start taking snapshots and tracking changes.
2. **Define Config Rules** — Add rules that represent your desired security posture. For governance, you might add a managed rule like 's3-bucket-public-read-prohibited' to ensure no storage bucket is open to the internet. Each rule evaluates resources and returns COMPLIANT or NON_COMPLIANT. This step enforces your policies automatically.
3. **Set Up Auto-Remediation (Optional)** — For critical rules, attach an SSM Automation document that runs when a resource is found NON_COMPLIANT. For example, if an EBS volume lacks encryption, Config triggers a document that creates an encrypted copy and attaches it. This step automates fixing violations, reducing manual effort and attack window.
4. **Enable Aggregator for Multi-Account View** — If you have multiple AWS accounts, create a Config Aggregator in a central account. Authorise each source account to share its Config data. This allows you to see compliance across the entire organisation from one place. This step gives you a governance dashboard for your whole cloud estate.
5. **Review and Respond to Compliance Reports** — Regularly check the Config dashboard or set up automated notifications (via Amazon SNS) when resources become NON_COMPLIANT. Generate compliance reports for auditors by exporting the configuration timeline. This step ensures continuous compliance and provides evidence for audits.

## Comparisons

### AWS Config vs AWS CloudTrail

**AWS Config:**
- Records resource configuration state
- Evaluates resources against rules for compliance
- Stores configuration items over time

**AWS CloudTrail:**
- Records API actions and user identity
- Logs who made a change and from where
- Does not evaluate resource state; just logs actions

### Managed Config Rule vs Custom Config Rule

**Managed Config Rule:**
- Pre-built by AWS for common compliance checks
- No coding required
- Limited to predefined parameter adjustments

**Custom Config Rule:**
- Written by you as a Lambda function
- Allows any custom logic or external data lookup
- Requires programming knowledge and Lambda setup

### Config Conformance Pack vs Individual Config Rules

**Config Conformance Pack:**
- Collection of multiple rules and remediation actions
- Targeted at a specific compliance framework (e.g., HIPAA)
- One-click deployment for complete standard compliance

**Individual Config Rules:**
- Single rule for one specific check
- Used for ad-hoc or unique policies
- Requires manual grouping and management

### Config (State Monitoring) vs GuardDuty (Threat Detection)

**Config (State Monitoring):**
- Monitors resource configurations and compliance
- Runs on a schedule or when a resource changes
- Produces compliance status (COMPLIANT/NON_COMPLIANT)

**GuardDuty (Threat Detection):**
- Analyses network traffic and logs for threats
- Uses machine learning and threat intelligence
- Produces security findings (severity: HIGH/MEDIUM/LOW)

## Diagram

_Flowchart showing the lifecycle of AWS Config: from enabling the service, recording changes, evaluating against rules, triggering auto-remediation, and aggregating data for audits._

```mermaid
flowchart TD
    A[Enable Config] --> B[Config Records Configuration Items]
    B --> C[Config Rules Evaluate Resources]
    C --> D{Compliant?}
    D -- Yes --> E[No Action Needed]
    D -- No --> F[Auto-Remediation via SSM]
    F --> G[Resource Fixed]
    B --> H[Configuration History in S3]
    H --> I[Aggregator for Multi-Account View]
    I --> J[Compliance Dashboard & Reports]
```

## Common misconceptions

- **Misconception:** AWS Config monitors user activity and logs who made changes. **Reality:** Config records resource configuration changes. CloudTrail logs who made the API call. Config does not log identity; it tracks state. (Both services are often mentioned together, so beginners confuse their purposes.)
- **Misconception:** Once you enable Config, it automatically fixes all non-compliant resources. **Reality:** Config only evaluates resources against rules. Auto-remediation is an optional feature you must explicitly configure using SSM Automation documents. (People assume 'monitoring' and 'fixing' come as a package. AWS separates the two to give you control.)
- **Misconception:** Config rules can be applied to resources across all AWS accounts from a single rule. **Reality:** Config rules are per-account and per-region. To manage compliance across multiple accounts, you use Config Aggregator to view data centrally, but each account still has its own rules. (Centralised dashboards (like Security Hub) create the illusion of centralised rule enforcement.)
- **Misconception:** Config is only useful for large enterprises with compliance requirements. **Reality:** Config is valuable for any organisation to track changes, detect misconfigurations early, and enforce security best practices. Even a single developer can use it to ensure they don't accidentally expose data. (Small teams often think compliance tools are overkill until they have a breach.)
- **Misconception:** CloudTrail and Config do the same thing — one records all changes, the other records some. **Reality:** CloudTrail records API actions (who called what, when, from what IP). Config records the configuration state of resources (what settings were applied after the action). They complement each other but are not interchangeable. (Both produce logs and dashboards, so beginners assume redundancy.)
- **Misconception:** Custom Config rules cannot be written in any programming language — only AWS-specified ones. **Reality:** You can write custom Config rules in any language that AWS Lambda supports (Python, Node.js, Java, etc.). The rule runs as a Lambda function that receives resource data and returns compliance status. (The name 'managed rules' suggests AWS controls all logic, but custom rules allow full flexibility.)

## Key takeaways

- AWS Config is a continuous monitoring service that records resource configurations and evaluates them against rules you define.
- Config rules can be either managed (pre-built by AWS) or custom (written as Lambda functions) to enforce your unique policies.
- Auto-remediation in Config uses AWS Systems Manager Automation documents to fix non-compliant resources automatically.
- Config is region-specific, so you must enable it separately for each region you want to monitor.
- Config Aggregator allows you to view compliance data from multiple accounts and regions in a single dashboard.
- Conformance packs bundle multiple Config rules and remediation actions together for specific compliance frameworks like HIPAA or PCI DSS.
- Config does not log who made changes — use CloudTrail for identity auditing alongside Config for configuration tracking.

## FAQ

**What is the difference between AWS Config and AWS CloudTrail?**

CloudTrail records API actions (who did what, when, from where), while Config records the configuration state of resources (e.g., is this S3 bucket public or private?). Think of CloudTrail as the security camera that films who enters the room, and Config as the inventory list that shows what furniture is in the room and its condition.

**Do I need to enable AWS Config in every region?**

Yes. AWS Config is a regional service, so you must enable it separately in each region where you have resources. You can use an AWS Organization-level policy or CloudFormation StackSets to enable it across all regions automatically.

**Can AWS Config help me pass a compliance audit?**

Absolutely. AWS Config provides an immutable history of resource configurations, shows compliance status against rules, and lets you generate reports. Auditors accept these as evidence of continuous monitoring and enforcement.

**How much does AWS Config cost?**

You pay per configuration item recorded (each snapshot of a resource) and per Config rule evaluation. Costs can add up if you record all resource types in many regions, but AWS provides a free tier of 10,000 configuration items per month. Check the official pricing page for current rates.

**What happens if I delete an IAM user that Config was tracking?**

Config will record the deletion as a configuration change. The last configuration item will show the user as deleted. The rule evaluation for that user will no longer apply, but the configuration history remains available for auditing purposes.

**Can I use Config to detect if someone makes an S3 bucket public?**

Yes. Create a Config rule called 's3-bucket-public-read-prohibited' (a managed rule). When someone changes the bucket policy to allow public access, Config will detect the new configuration and mark the bucket as NON_COMPLIANT within about 15 minutes.

**Does Config work with resources created outside of AWS (on-premises or other clouds)?**

AWS Config is designed for resources within AWS accounts only. To monitor on-premises resources, you would need to use AWS Systems Manager or other hybrid governance tools. However, you can use Config rules to evaluate resources that are managed via AWS CloudFormation StackSets across accounts.

## Check your understanding

1. **What AWS service would you use to ensure that all S3 buckets in your account have versioning enabled, and to get alerted when a new bucket is created without it?**

   Answer: Use AWS Config with a managed rule called 's3-bucket-versioning-enabled'. Config will evaluate each bucket and flag those without versioning.

2. **You need to view compliance data from 20 AWS accounts in one place. What AWS Config feature should you use?**

   Answer: Use Config Aggregator to collect configuration and compliance data from multiple accounts and regions into a single dashboard.

3. **What is the difference between a managed Config rule and a custom Config rule?**

   Answer: A managed rule is pre-built by AWS and requires no coding. A custom rule is a Lambda function you write to evaluate resources against your own logic.

4. **If an EC2 instance is found non-compliant by a Config rule, what AWS feature can automatically fix it?**

   Answer: Auto-remediation using an AWS Systems Manager Automation document, which is triggered by the Config rule when a resource is non-compliant.

5. **True or false: AWS Config records who made a specific configuration change to an S3 bucket.**

   Answer: False. Config records the configuration state of the bucket (e.g., is it public?), not who changed it. Use CloudTrail to identify the user who made the change.

---

Interactive version with quiz and diagrams: https://courseiva.com/learn/aws-security-specialty/security-governance-and-compliance