In the previous subchapter, we saw how to set limits with SCPs. But how do you know, at all times, if your resources comply with the rules your company requires? How do you detect a bucket that became public or an unencrypted database? For that continuous compliance monitoring there is AWS Config. It's like having a permanent auditor reviewing your infrastructure.

In a real AWS account, things change all the time: resources are created, configurations are modified, someone adjusts a permission... With so many changes, it's very easy for something to end up not complying with security rules without anyone noticing:

• An S3 bucket that someone made public "temporarily" and forgot to close (remember the drift from subchapter 22.4).
• A database that was created without encryption.
• A Security Group with a dangerous port open.
• A resource without the company's required tags.

You need something to continuously monitor and alert you when something stops complying with the rules.

AWS Config is a service that records the configuration of your resources and monitors that they comply with the rules you define, continuously. It does three fundamental things:

Analogy: AWS Config is like a health inspector who lives in your restaurant and continuously checks that everything complies with hygiene rules. He doesn't come once a year: he's always watching, and the moment something is out of order (a fridge left open, a dirty surface), he notes it and alerts you. Plus, he keeps a journal of how everything has been over time.

Config saves how each resource is configured at every moment, and keeps a history of changes. This allows you to answer very valuable questions:

• "How was this Security Group configured last week?"
• "Who changed this configuration and when?"
• "What did my infrastructure look like on the day of the incident?"

This history is pure gold for investigating problems and for audits.

You define rules that your resources must comply with, and Config continuously checks if they do. AWS offers many predefined rules, and you can create your own. Examples:

Each resource is marked as "compliant" (meets the rule) or "non-compliant" (does not meet the rule). At a glance, you see the compliance status of your entire account.

When a resource becomes non-compliant, Config can alert (the security team, for example) and even automatically fix it (remediation). For example, if a bucket becomes public, a remediation action could automatically block it again.

You may wonder how this differs from Checkov/tfsec (subchapter 21.2). The difference is when they act:

They complement each other: static analysis prevents insecure code from reaching production (prevention), and AWS Config monitors that what is already deployed continues to comply (continuous detection). Remember the drift from subchapter 22.4: Config is one way to detect that something was changed manually and stopped complying with the rules.

Real world example: a financial company has the rule "all databases must be encrypted" (by regulation). They configure a Config Rule to check this. One day, someone manually creates a test database without encryption. Config immediately marks it as 'non-compliant', alerts the security team, and an automatic remediation marks it for review. The non-compliance is detected in minutes, not at the annual audit. The company can demonstrate to regulators that it has continuous compliance monitoring.

The key idea is continuous compliance. Instead of checking compliance once a year (in a manual, stressful audit that only gives a snapshot), Config checks it all the time, automatically. This is essential for companies with regulatory requirements (banking, healthcare, etc.), but useful for anyone who wants to keep their infrastructure secure and organized.

• In a real account, infrastructure changes constantly, and it's easy for something to end up not complying with security rules without anyone noticing.
• AWS Config monitors compliance continuously: it records resource configuration (with history), evaluates if they comply with rules, and alerts (or remediates) when something is non-compliant. Like an inspector living in your infrastructure.
• The configuration history allows you to investigate incidents and audit ("how was this last week?").
• Compared to static analysis (Chapter 21), which acts before deployment on code, Config acts after, on real resources and continuously (also detects drift). They complement each other.
• It provides continuous compliance: checks compliance all the time, instead of a one-off annual audit. Essential for regulated environments.

In the next subchapter, we will move from monitoring compliance to detecting active threats with GuardDuty.