Three tasks: apply managed rules to a set of resources, attach automatic remediation to a rule, and read the compliance dashboard. The third task is the reporting layer. The second is the one that changes what the rule is — and it is also the one that deserves the most caution.
On paper the three tasks look like a tour of the AWS Config console. They are not. Read in order, they walk you from a rule that produces a report to a rule that produces a change, and the difference between those two things is the difference between a compliance programme that costs you money and one that reduces risk.
Imagine AnyCompany enables forty managed rules across the organisation and wires the results into a dashboard and an email digest. Compliance posture is now visible. Two questions follow immediately: who fixes the failures, and how long does each one stay broken?
If the answer is “the owning team, when they get to it”, then every rule you enable adds to a backlog rather than to your security posture. The dashboard turns green only as fast as humans work the queue, and the queue grows with your estate. Teams in this position often conclude that Config is noisy, when the actual problem is that nothing on the other end of the detection closes the gap.
Attaching a remediation action changes the shape of the system. The rule stops describing the world and starts correcting it. That is why the second task in this lab is the one worth slowing down for.
Both lanes below start identically: a resource drifts, the rule re-evaluates, the result comes back non-compliant. Everything interesting happens in the third column.
Pick rules from the AWS-maintained catalogue and point them at a scoped set of resources. You are writing down a desired state in a form the platform can check on its own.
Attach an action to a rule so a failure triggers a fix. This is the task that converts a detection into a control loop, and the one with real consequences if you aim it badly.
Use the compliance view to see which rules pass, which resources fail, and how the picture moved after remediation ran. This is your evidence trail and your feedback signal.
A Config rule is a small, named statement of desired state plus the code that checks it. The only difference between a managed rule and a custom rule is who owns that code. Getting this distinction right early saves a surprising amount of engineering.
You enable it, set a few parameters, and choose which resources it applies to. AWS owns the evaluation logic and keeps it current as services change. There is no function to deploy, no runtime to patch, and no code review to schedule. The catalogue is large and covers most of the checks an organisation actually needs.
Backed by your own logic, typically an AWS Lambda function or a Guard policy. Use it when the requirement is genuinely specific to your organisation — a naming convention, an internal tagging taxonomy, a relationship between two resources that no generic rule could know about. You now own a code artefact with a lifecycle.
Whichever kind of rule you use, these are the knobs. Two of them are about correctness and two are about noise and cost, and people routinely tune only the first two.
Which managed rule, or which function. This is the statement of desired state — versioning on, encryption present, no open ingress on this port.
Many managed rules take arguments: which port, which tag keys, how many days, which KMS key. Same rule, different policy, depending on what you pass.
Which resource types — and optionally which tags — the rule applies to. This is the noise dial and the cost dial in one control.
Re-evaluate when a matching resource changes, on a fixed schedule, or both. Change-triggered gives you minutes-to-detection; periodic catches things a change event cannot describe.
Leave a rule unscoped and it evaluates against everything of that type in the account. In a sandbox that is fine. In a shared account with several thousand resources across a dozen teams, it produces a wall of failures that nobody owns, and the dashboard becomes something people learn to ignore. Scoping to resource type — and, where it fits, to a tag such as an environment or an owning team — keeps every failure attributable to somebody.
Scope also drives cost. Config bills on the evaluations it performs and on the configuration items it records, so an unscoped rule set across a large estate is a spend decision as much as a governance one. The two problems have the same fix, which is convenient: narrow the scope and you improve signal and reduce the bill in the same change.
The pattern that holds up at scale is to start narrow and widen deliberately. Enable a rule against one resource type in one account, look at what it flags, decide whether every one of those findings is something you would genuinely act on, then extend. Enabling forty rules organisation-wide on the first day is how a governance programme acquires a reputation for noise it never recovers from.
This is the single most useful thing to be clear about before the lab, because it explains why the previous module spent time on service control policies and why remediation exists at all.
A Config rule evaluates recorded state. It runs after the API call has already succeeded and the resource already exists in its new shape. It cannot refuse the call, it cannot hold the request while it decides, and it cannot make the change conditional on approval. By the time a rule reports non-compliance, the thing it is complaining about is real.
That is not a defect — it is the division of labour. A service control policy refuses the call at the boundary and never lets the state exist. A Config rule notices the states you could not or chose not to forbid outright. The two cover different ground, and the gap between them is measured in the time between the change landing and the rule re-evaluating.
Which leads to the practical consequence: for anything where existence-for-a-few-minutes is itself unacceptable, a detective control is the wrong primary defence. Use a preventive control and keep the Config rule as the check that your preventive control is actually in force.
A small slice of the catalogue, chosen because these are the checks that come up in governance conversations and because several of them appear in this lab or in the earlier modules. Rule identifiers are shown in the form you will search for them.
| Managed rule | What it evaluates | Typical scope | Safe to auto-fix? |
|---|---|---|---|
| s3-bucket-versioning-enabled | Whether versioning is turned on for a bucket. Optionally whether MFA delete is required as well. | S3 bucket | Yes, additive |
| s3-bucket-public-read-prohibited | Whether the bucket policy or ACL grants read access to everyone. A companion rule covers public write. | S3 bucket | Usually |
| encrypted-volumes | Whether an attached EBS volume is encrypted, optionally with a named KMS key. | EBS volume | No, disruptive |
| iam-user-mfa-enabled | Whether each IAM user has a multi-factor device registered. Periodic, because there is no single resource change to hang it on. | IAM user | Lockout risk |
| restricted-ssh | Whether any security group allows unrestricted inbound access on the SSH port. A parameterised sibling covers arbitrary ports. | Security group | Usually |
| required-tags | Whether resources carry the tag keys you name, and optionally specific values. The backbone of most tag-based governance. | Many types | Fills in noise |