AWS Config Non-Compliant Rule Sentinel

AWS Config evaluates every configured rule continuously, but it has no built-in way to say "notify this Slack channel the moment any rule goes NON_COMPLIANT" without wiring an EventBridge rule and a notification target per account - a separate configuration surface from the flow that actually needs to react. This blueprint runs Config's own compliance query, filtered server-side, and alerts Slack directly with the exact rule names and resource counts.

How it works

1. periodic_compliance_check (io.kestra.plugin.core.trigger.Schedule) runs every 6 hours, explicitly passing aws_region through its own inputs: block so the flow is self-contained when the trigger fires. Shipped disabled so a manual run can be verified first.
2. probe_config_compliance (io.kestra.plugin.aws.cli.AwsCLI) runs aws configservice describe-compliance-by-config-rule --compliance-types NON_COMPLIANT, capturing the result's ComplianceByConfigRules list (and NextToken) as named task outputs via the plugin's own documented output-echo convention.
3. evaluate_compliance (io.kestra.plugin.core.flow.If) branches on whether that list has any entries at all.
   • then (NON_COMPLIANT_RULES_DETECTED): alert_non_compliant_rules reports every non-compliant rule's name and capped non-compliant-resource count to Slack.
   • else (HEALTHY): log_all_rules_compliant records a clean sweep.
4. log_audit_complete always runs last, printing the non-compliant rule count regardless of which branch fired.
5. The errors block alerts Slack separately if the flow itself fails outright - AWS Config not being enabled in the region, or bad credentials, must not read as HEALTHY.

What you get

• A HEALTHY/NON_COMPLIANT_RULES_DETECTED answer computed by AWS Config's own server-side filter, not by paging through every rule (compliant and not) and filtering client-side.
• The exact rule names and per-rule non-compliant resource counts in the Slack alert itself, instead of requiring someone to open the AWS Config console to see which rules and how many resources are affected.
• A worked example of io.kestra.plugin.aws.cli.AwsCLI driving a read-only compliance audit via a plain aws configservice CLI call, reusing the same output-capture convention as this repository's CloudFormation stuck-stack sentinel blueprint, with the same deliberate fix (newlines only, not spaces, stripped before the marker) so rule names and messages are never corrupted.

Who it's for

• Cloud governance and security teams running AWS Config rules who need an immediate signal when a rule starts failing, without building and maintaining a separate EventBridge-to-notification pipeline per account.
• On-call engineers who want one Slack alert with the exact rule names and resource counts instead of opening the AWS Config console to check manually.
• Anyone evaluating the AWS plugin who wants a worked example of AwsCLI used for a read-only governance audit rather than a provisioning command.

Why orchestrate this with Kestra

AWS Config itself has no cross-account, cross-rule "tell me the moment anything goes NON_COMPLIANT" primitive beyond what you wire up separately in EventBridge and SNS, configuration that then has to be kept in sync as rules are added or removed. Kestra supplies the schedule, the HEALTHY/NON_COMPLIANT_RULES_DETECTED classification as a first-class branch, and an execution history that shows exactly when drift was introduced and which rules and resources were affected.

Prerequisites

• An AWS account with AWS Config enabled and at least one Config rule active in the target region (update aws_region).
• AWS credentials with config:DescribeComplianceByConfigRule permission - entirely read-only, cannot modify any rule or resource.
• A Slack incoming webhook for alerts.

This blueprint has no meaningful local testing path. LocalStack now requires its own account and auth token as of March 2026, and even where LocalStack is used, its own documentation describes AWS Config's compliance evaluation as inert - describe-compliance-by-config-rule always returns INSUFFICIENT_DATA there rather than evaluating against real resource configuration. A real AWS account with Config actually enabled is the only way to exercise this blueprint meaningfully.

Secrets

• AWS_ACCESS_KEY_ID / AWS_SECRET_ACCESS_KEY: credentials for io.kestra.plugin.aws.cli.AwsCLI.
• SLACK_WEBHOOK_URL: Slack incoming webhook used by alert_non_compliant_rules and the errors block.
• In Kestra OSS (no Enterprise secrets backend), secrets are supplied as environment variables prefixed SECRET_, base64-encoded - for example SECRET_AWS_SECRET_ACCESS_KEY=$(echo -n '<your-secret-key>' | base64) - and read back in flows with {{ secret('NAME') }}.

Inputs

• aws_region (STRING, default us-east-1): region whose Config rules are audited.

Outputs

• outputs.probe_config_compliance.vars.ComplianceByConfigRules: the list of non-compliant rules, each with ConfigRuleName and Compliance.ComplianceContributorCount.CappedCount / CapExceeded (verified fields from AWS Config's own DescribeComplianceByConfigRule API reference).
• outputs.probe_config_compliance.vars.NextToken: pagination token, present when more non-compliant rules exist than fit in one page - not consumed by this blueprint (see Pitfalls).

Quick start

1. Enable AWS Config in a real AWS account and attach at least one managed Config rule (for example s3-bucket-public-read-prohibited).
2. Add the AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, and SLACK_WEBHOOK_URL secrets.
3. Run the flow manually against a compliant account and confirm log_all_rules_compliant fires.
4. Create a resource that violates the attached rule (for example, make an S3 bucket public if using the rule above) and wait for AWS Config to re-evaluate, then re-run to confirm alert_non_compliant_rules fires with the real rule name and resource count.
5. Enable periodic_compliance_check once you trust the check against your real account.

How to extend

• Loop over several aws_region values with io.kestra.plugin.core.flow.Loop to audit every region where Config is enabled in one run.
• Handle NextToken with a follow-up AwsCLI call using --starting-token if an account has enough non-compliant rules to paginate - this blueprint's single call only sees the first page.
• Add a second, separate remediation flow that triggers an AWS Config auto-remediation action for a specific rule behind an explicit approval gate - deliberately kept out of this sentinel so the monitoring path never changes any resource.

Pitfalls

• --compliance-types NON_COMPLIANT does not surface INSUFFICIENT_DATA rules (rules that have not been evaluated yet) - a rule can sit silently unevaluated and this blueprint will not flag it, since it is checking only for active non-compliance, not evaluation coverage.
• Pagination is not handled. If an account has more non-compliant rules than fit in one describe-compliance-by-config-rule page, NextToken will be present in the output but this blueprint does not follow it - see How to extend.
• The output-capture convention (tr -d '\n' | xargs -0 -I {} echo '::{"outputs":{}}::') deliberately does not strip spaces, unlike the plugin's own Javadoc example, for the same reason documented in this repository's CloudFormation stuck-stack sentinel: stripping spaces would corrupt any rule name or message containing them.
• LocalStack's AWS Config support is documented as inert for compliance evaluation - describe-compliance-by-config-rule there always returns INSUFFICIENT_DATA regardless of actual resource state, on top of LocalStack now requiring its own account since March 2026. Neither issue is specific to this blueprint; both are disclosed here so they are not mistaken for a bug in it.
• This blueprint is UNTESTED against a live AWS account. The CLI command, its --compliance-types filter, and the ComplianceByConfigRules / Compliance.ComplianceContributorCount output fields are taken verbatim from AWS's own CLI and API reference documentation - but no Kestra engine was run to execute this flow end to end.

Links

• Kestra AWS plugin documentation
• AWS Config DescribeComplianceByConfigRule API reference
• AWS CLI describe-compliance-by-config-rule reference
• Kestra secrets (OSS vs Enterprise)