Essential AWS Config Rules: The Security and Compliance Checks That Actually Matter

AWS has over 300 managed Config rules. Enabling all of them is a recipe for alert fatigue — you end up with hundreds of findings across resource types you do not actually care about, obscuring the handful of genuinely critical issues that need immediate attention. Enabling too few leaves real security gaps. The challenge is picking the set that covers your highest-priority compliance requirements without generating noise that trains your team to ignore findings.

This guide covers the managed rules that consistently appear in security audits, compliance frameworks, and incident post-mortems as the highest-signal checks. These are organized by security domain, with notes on scope, trigger type, and why each one matters. After the managed rules, there is a section on writing custom rules for checks that AWS does not cover natively.

Identity and Access Management Rules

root-account-mfa-enabled is non-negotiable. The root account has unrestricted access to every resource in the account and bypasses all IAM policies. If root MFA is not enabled, a stolen root password provides complete account takeover. This rule evaluates periodically and has no configurable parameters — it either passes or fails. Treat any NON_COMPLIANT result as a critical finding requiring same-day remediation.

iam-root-access-key-check verifies that no access keys exist for the root account. Root access keys cannot be scoped by IAM policies, are invisible to most monitoring tools, and provide programmatic access equivalent to root console access. There is no legitimate operational use case for root access keys — if they exist, they must be deleted immediately.

iam-user-mfa-enabled checks that all IAM users with console access have MFA enabled. This rule evaluates all IAM users in the account and flags any where mfa_active is false and the user has a console password. Pair this with iam-user-no-policies-check, which ensures that IAM users do not have policies attached directly rather than through groups — direct user policy attachment makes permission management inconsistent and audit-unfriendly.

iam-policy-no-statements-with-admin-access identifies customer-managed IAM policies that contain statements granting full administrative access (Effect: Allow with Action: * and Resource: *). These policies represent maximum blast-radius credentials. Any role or user attached to such a policy has unrestricted access to every AWS service and resource. Flag and review these immediately — legitimate administrative roles almost always need scoped admin access, not unrestricted.

access-keys-rotated identifies IAM users with access keys that have not been rotated within a configurable number of days (90 days is the standard). Long-lived access keys accumulate exposure risk — more time for them to leak via logs, repositories, or screenshots. Configure the maxAccessKeyAge parameter to 90 and treat findings as high severity for keys older than 180 days.

Logging and Audit Trail Rules

cloudtrail-enabled verifies that at least one CloudTrail trail is enabled and logging in the account. Without CloudTrail, you have no audit record of API activity — no forensic capability, no compliance evidence, and no basis for anomaly detection. This rule is a prerequisite for almost every other security monitoring capability. If it fires, nothing else in your security monitoring stack is reliable.

cloudtrail-s3-dataevents-enabled checks that at least one trail is recording S3 data events. Management events are recorded by default; data events (GetObject, PutObject, DeleteObject) require explicit configuration. For any account storing sensitive data in S3, data event recording is mandatory for forensic investigation of data access incidents. Note that data event recording significantly increases CloudTrail costs — scope it to specific buckets containing sensitive data rather than all S3 buckets if cost is a constraint.

multi-region-cloudtrail-enabled verifies that a trail is configured to log events in all regions, including regions where you do not actively operate workloads. Attackers who compromise credentials frequently pivot to unused regions specifically to evade monitoring. A trail that only covers your primary region is blind to this tactic.

cloudtrail-log-file-validation-enabled ensures that CloudTrail log file integrity validation is enabled. This feature generates a signed digest file for each log file, allowing you to cryptographically verify that logs have not been modified or deleted after delivery to S3. In a security incident investigation, tampered logs are worthless. Enable this on every trail.

Network and Infrastructure Rules

vpc-flow-logs-enabled verifies that VPC Flow Logs are enabled on every VPC. Flow logs capture accept/reject decisions for network traffic, providing the network-layer visibility needed for intrusion detection, security group analysis, and post-incident investigation. This rule evaluates each VPC in the account and reports NON_COMPLIANT for any VPC without at least one active flow log.

restricted-ssh and restricted-common-ports check whether security groups allow unrestricted inbound access (0.0.0.0/0 or ::/0) on sensitive ports — SSH (22), RDP (3389), and a set of commonly exploited service ports. These rules trigger on configuration changes to security groups, providing near-real-time detection when someone opens a security group to the internet. They generate significant findings in environments where developers self-manage security groups without review.

ec2-security-group-attached-to-eni identifies security groups that are not attached to any Elastic Network Interface. Unattached security groups are not actively blocking traffic, but they represent configuration clutter that makes security group auditing harder and may be reattached accidentally in the future with stale, overly permissive rules. This is a medium-priority hygiene rule.

ec2-no-amazon-key-pair (where applicable) checks that EC2 instances are not using EC2 key pairs for SSH access. Key pair authentication is difficult to audit, rotate, and control at scale — every instance with a key pair attached requires tracking which humans hold the corresponding private key. The preferred alternative is AWS Systems Manager Session Manager, which requires no open SSH port and records all session activity in CloudTrail.

Storage and Data Protection Rules

s3-bucket-public-access-prohibited is the highest-priority S3 security rule. It verifies that all four Block Public Access settings are enabled at the bucket level: BlockPublicAcls, IgnorePublicAcls, BlockPublicPolicy, and RestrictPublicBuckets. A single publicly accessible S3 bucket containing sensitive data is a reportable data breach. This rule should have automated remediation configured — enable Block Public Access immediately when a violation is detected.

s3-bucket-server-side-encryption-enabled checks that default server-side encryption is enabled on every S3 bucket. Since January 2023, AWS enables SSE-S3 by default on new buckets, but existing buckets created before that date may lack it. For compliance frameworks requiring customer-managed keys, supplement this rule with a custom rule or bucket policy check that verifies SSE-KMS is configured rather than SSE-S3.

s3-bucket-logging-enabled verifies that S3 server access logging is enabled on each bucket. Access logs record every request to the bucket — useful for forensic analysis of data access incidents and required by several compliance frameworks as an audit trail. This rule evaluates all S3 buckets and flags those without logging configured.

encrypted-volumes checks that all attached EBS volumes are encrypted. Unencrypted EBS volumes expose data at rest to anyone with access to the underlying storage — a real concern in a shared hardware environment. This rule is triggered by changes to EC2 instances and EBS volumes.

Encryption and Key Management Rules

rds-storage-encrypted verifies that RDS database instances have encryption at rest enabled. Like EBS encryption, this is a baseline data protection control required by most compliance frameworks. Encryption cannot be enabled on an existing RDS instance without a snapshot-and-restore cycle — catch this at deployment time, not during an audit.

cmk-backing-key-rotation-enabled checks that AWS KMS customer-managed keys have automatic annual key rotation enabled. Annual rotation limits the exposure window if a key is compromised and is required by PCI DSS and several other frameworks. This rule does not apply to AWS-managed keys, which AWS rotates automatically.

Custom Rules via Lambda

Managed rules cover common compliance requirements, but every organization has checks that are specific to their architecture, tagging standards, or regulatory context. Custom Config rules address this gap. A custom rule is a Lambda function that receives a configuration item as input, evaluates it against your custom logic, and returns a compliance determination.

Common custom rule use cases include: verifying that all EC2 instances have required cost allocation tags (environment, team, project); checking that S3 buckets follow your naming convention and are associated with a registered application; verifying that IAM roles used by Lambda functions do not have policies attached beyond the specific services the function uses; and checking that all RDS instances have deletion protection enabled.

Custom rules are evaluated either on configuration change (triggered when a specific resource type changes) or on a schedule (evaluated periodically regardless of changes). Change-triggered rules are more efficient — they only run when something actually changes. Schedule-triggered rules are useful for checks that depend on external data or that evaluate relationships between resources rather than a single resource's configuration.

Rules vs. Conformance Packs

Individual rules are the building blocks; conformance packs bundle them into deployable compliance frameworks. If you are working toward a specific standard — CIS, PCI DSS, NIST 800-53 — deploy the corresponding conformance pack rather than manually selecting individual rules. Conformance packs deploy all applicable rules in one operation and provide a compliance score against the full framework.

Use individual rules for checks that are not covered by any conformance pack, for custom rules, and for rules you want to scope differently than the conformance pack defaults. Individual rules and conformance packs coexist — you can deploy the CIS conformance pack and add custom individual rules for organization-specific requirements.

Scoping Rules to Specific Accounts, Regions, and Resource Types

Config rules evaluate all resources of the targeted type in the account and region where the rule is deployed. For organization-wide rule deployment via StackSets, the same rule runs in every account and region in scope. This is appropriate for most security rules — you want the same baseline everywhere.

However, some rules need scope adjustments. Use resource-level scoping to limit a rule to specific resources by tag (e.g., only evaluate RDS instances tagged environment: production). Use rule exclusions to skip specific resource IDs from evaluation. These scoping mechanisms prevent false positives in environments where certain intentional configurations would otherwise be flagged.

Related Reading

• AWS Config setup guide — enabling recording, delivery channels, and multi-account aggregation
• Config conformance packs — bundled compliance frameworks for CIS, PCI DSS, and NIST
• Config auto remediation — automatically fixing non-compliant resources
• IAM security monitoring — root login detection, MFA gap analysis, and policy drift alerting

FAQ

How many Config rules should I enable?

There is no universal number — it depends on your environment and compliance requirements. A reasonable starting set for a security-conscious organization is 25–40 rules covering the IAM, logging, network, and storage domains described above. Adding conformance packs for relevant frameworks (CIS, PCI DSS) will expand this to 60–100 rules. Beyond that, every additional rule should have a specific compliance or security rationale — more rules is not inherently better if they generate noise without signal.

What is the difference between periodic and change-triggered Config rules?

Change-triggered rules evaluate a resource's configuration immediately when that resource changes. They are efficient because they only run when something actually changes. Periodic rules run on a schedule regardless of whether resources have changed — useful for checks that depend on time (access key age, certificate expiration) or that evaluate account-level settings rather than individual resources. Most managed rules are change-triggered; a subset of IAM and account-level rules are periodic.

Can Config rules auto-remediate non-compliant resources?

Yes. Config supports remediation actions backed by AWS Systems Manager Automation documents. You configure a remediation action for a rule, specifying the SSM document to run, the parameters to pass (including the non-compliant resource identifier), and whether remediation is automatic or manual. Automatic remediation runs immediately when a NON_COMPLIANT finding is generated. Use auto-remediation cautiously — it is appropriate for low-risk fixes like enabling encryption, but not for actions that could disrupt production workloads.

Do Config rules evaluate historical configurations or only the current state?

Config rules evaluate the current configuration state of resources. When a rule is first enabled, it evaluates all in-scope resources in their current state. Subsequently, it evaluates resources when they change (for change-triggered rules) or on schedule (for periodic rules). Config does not retroactively evaluate historical configurations against new rules — enabling a new rule does not produce findings for past violations that have already been remediated.

How do I prevent Config rule findings from cluttering my dashboard with known exceptions?

Use Config rule exemptions to suppress specific resources from evaluation. Add the resource ARN to the rule's exemption list with a justification note. For broader suppression — entire accounts or resource categories — use rule scoping to exclude specific tags or resource types from evaluation. Exemptions should be documented and reviewed periodically to ensure they remain valid; outdated exemptions are a common audit finding.