AWS Config Beyond Rules: Conformance Packs and Advanced Queries

01Where most of us stop

Almost everyone who opens AWS Config does the same thing: add a managed rule, wait, read a list split into Compliant and Noncompliant. That works, and for a handful of rules it is all you need.

Two features sit right next to it that I had never properly used:

• Conformance packs — a bundle of rules deployed and scored as one thing.
• Advanced queries — SQL over everything Config has already recorded, answered in seconds.

I spent an afternoon on both in my own account. Here is where each one earns its place, including the part where I misread my own compliance score.

02The problem this solves

Say an account has a hundred IAM users. How do you know how many have access keys older than ninety days, how many have keys that stopped being used months ago but are still active, who can sign in without MFA, whether the password policy is still what somebody set two years ago, or whether root still has access keys on it?

You can answer all of that by hand — credential report, a few CLI calls, a spreadsheet, an afternoon. Then it is stale by Friday, because someone created three users.

Every question on that list is a managed Config rule, and AWS has already bundled them into Operational Best Practices for AWS Identity And Access Management. Deploy it once and it keeps re-evaluating. You stop running the audit and start reading it.

Advanced queries cover the other half: not "am I compliant against a standard," but "which buckets have versioning off, name them." No rule to deploy, no waiting.

03Deploying the pack

A conformance pack is a collection of Config rules and remediation actions deployed as one entity, from a YAML template. Under the hood it is a CloudFormation stack in a service-managed account, which is why you get a single deployment status instead of seventeen rule creations to watch.

Open that dropdown before committing to anything. It tells you how AWS thinks about the feature — regulatory frameworks and single-service packs in one alphabetical list.

I picked the IAM pack and named it iam-conformance.

The other branch matters even if you start with samples, because it is where you end up. Uploads cap at 50 KB — which is why FedRAMP High is split in two — and the middle option is underrated: store templates as SSM documents and deploy by document name, no bucket policy conversation.

04Parameters are the whole game

This is the step people skip. It is labelled optional, it is pre-filled, and it looks like a formality. These values are what compliant means in your account.

Fourteen characters, twenty-four passwords of reuse prevention, ninety-day rotation — that is CIS, not an AWS opinion. If your standard differs, change it here, not in a ticket six weeks later when someone notices the dashboard is green against the wrong number.

05The score, and why 25% is fine

Seventeen rules, twenty-five percent. Before reading that as a failing grade, look at the rule table — the compliance column has three states, not two.

The other thing that table shows: Remediation action: Not set, on every row. Packs are detective by default. Remediation only happens if the template carries AWS::Config::RemediationConfiguration blocks pointing at SSM Automation documents — and that belongs in phase two, not day one.

That Frameworks list is the part I did not expect. When an auditor asks which control covers password policy, this page answers it and you do not maintain it.

06Advanced queries: ask, get a table

Packs answer "am I compliant against a standard." They do not answer "which buckets, right now." That is the other half of the console.

This is the feature I expect to use most, and the reason is time. The questions that eat an afternoon are not hard, just tedious — which instances are still t2.micro, which sit in the subnet somebody wants to decommission, which EBS volumes are detached and still billing, which buckets have no encryption. Normally a script, a paginator and some jq. Here it is a SELECT against data Config already recorded.

Those pack-status samples matter: your conformance pack results are queryable data, not just a gauge, so you can build your own reporting instead of screenshotting a dial.

I opened the S3 versioning sample and ran it unmodified.

SELECT
  resourceId,
  resourceType,
  supplementaryConfiguration.BucketVersioningConfiguration.status
WHERE
  resourceType = 'AWS::S3::Bucket'
  AND supplementaryConfiguration.BucketVersioningConfiguration.status = 'Off'

Two audit log buckets with no versioning, and the Config delivery bucket next to them. I wrote none of that SQL — clicked a sample, hit Run, had the answer before I finished reading the query. By hand it is list-buckets, then get-bucket-versioning in a loop, then remembering that an unversioned bucket returns an empty response rather than the word "Off". Every bucket in that list was created by an AWS console flow, which is a useful reminder that service-created is not the same as compliant.

07Four things that will bite you

Scope is one account and one Region. The editor says so under the query title. In a landing zone that means you just answered a question about one account and may not notice. Org-wide answers run against an aggregator — that parallel set of Aggregators entries in the left nav. Set it up before you go looking for answers.

Export caps at 500 rows. Fine for exploring, wrong for inventory. aws configservice select-resource-config paginates properly and is what belongs in a script.

Packs bill per evaluation, per account, per Region. Deploying to twelve Regions because the wizard is quick is a decision with a monthly cost on it.

Rule names carry a random pack suffix. Mine are all <rule>-conformance-pack-4vyxkuk7v, and that suffix changes on redeployment — so dashboards, automation rules and suppressions keyed on rule names break quietly. Key on the pack name.

The same flow works for everything else in the catalog. Point it at S3 and those eight versioning findings arrive as a tracked rule instead of a one-off query, which is the shape you want them in long term.

08How I would run this

1. Start with one narrow pack, not a framework. A service owner can read a fifteen-rule pack and argue with it. Nobody argues productively with FedRAMP High Part 2 on day one.
2. Set every parameter deliberately, in the template. The defaults are CIS values. If your standard differs, the template is where that decision gets recorded and reviewed.
3. Move to organization packs early. Deployed from a delegated administrator, immutable in member accounts, re-applied centrally — one template to change instead of a hundred accounts. Every non-excluded account needs a working Configuration Recorder first, or it fails on the accounts you forgot.
4. Keep the YAML in the repo. aws_config_organization_conformance_pack exists. It encodes a policy decision, so it deserves a reviewer.
5. Add remediation only after the detection has been quiet. Manual first, one rule at a time.
6. Report unevaluated counts next to the score. Always.
7. Queries for today's ticket, packs for the trend. If you run the same query every month, it should be a rule in a pack.

Worth knowing where this is heading, too: AWS shipped close to three hundred new managed rules this year, and every announcement points at conformance packs as the way to deploy them. Since June, Security Hub CSPM runs its own service-linked Config rules independently of yours — so "we have Security Hub, we do not need Config rules" stopped being a coherent position. Its rules are its own; your standard is your pack.