enekui
Cloud  ·  6 min

AWS Config adds 191 managed rules: what governance actually looks like for SMBs

AWS Config just expanded its managed rules library by 191 entries per AWS, covering services from Bedrock to ECS to S3. If you're running a small engineering team and wondering whether your RDS instances are encrypted or your S3 buckets are accidentally public, this is the tooling AWS wants you to use. The question is whether it's worth the overhead for a team of four.

What AWS Config does (and why it matters now)

AWS Config continuously evaluates your resources against rules you define. A rule might be "all RDS instances must have encryption at rest enabled" or "CloudTrail must be logging to a specific bucket". When a resource drifts out of compliance, Config flags it. You get a compliance dashboard, historical snapshots, and remediation hooks.

The 191 new rules span: - AI workloads: Bedrock model invocation logging, SageMaker notebook encryption. - Compute: ECS task definition checks, EKS cluster logging. - Data: RDS encryption, Redshift audit logging, S3 public access blocks. - Foundations: CloudTrail multi-region trails, ACM certificate key checks, API Gateway access logs.

Examples from the announcement: - ACM_CERTIFICATE_RSA_CHECK: flags certificates using weak RSA keys. - API_GWV2_ACCESS_LOGS_ENABLED: ensures API Gateway v2 logs requests. - APPSYNC_AUTHORIZATION_CHECK: validates AppSync API authorization config. - ATHENA_WORKGROUP_ENCRYPTED_AT_REST: checks Athena query result encryption.

You can deploy these individually or bundle them into conformance packs (pre-built sets of rules for frameworks like CIS, PCI-DSS). They're available in regions where the underlying services run.

What this means for your SMB

If you're a 5-person team running €8k/month on AWS, you probably don't have a dedicated compliance officer. You also probably don't have time to manually audit 200 resources every quarter to check if someone left an RDS snapshot public or forgot to enable CloudTrail in a new region.

This is where Config shines: it automates the boring, critical stuff. The new rules cover gaps that matter to SMBs: - S3 public access: one misconfigured bucket can leak customer data. The S3-related rules (there are several in this batch) flag public buckets, missing encryption, and lifecycle misconfigurations. - RDS/Redshift encryption: if you're storing customer PII, encryption at rest isn't optional. The new RDS and Redshift rules check this continuously. - CloudTrail logging: if you ever need to audit "who deleted this Lambda function", CloudTrail is your only source of truth. The new rules ensure trails are enabled and logging to the right place. - Bedrock/SageMaker: if you're experimenting with AI (and many SMBs are), the new Bedrock rules check model invocation logging and data protection settings. SageMaker rules validate notebook encryption and VPC isolation.

The cost question: Config charges per rule evaluation per resource. For a small account (say 50 resources, 10 active rules), you're looking at tens of euros per month, not hundreds. The trade-off is whether that's cheaper than the engineer-hours spent manually auditing or the cost of a compliance incident.

When to skip it: if your AWS footprint is tiny (one RDS instance, one S3 bucket, no AI workloads), Config is overkill. Use CloudFormation drift detection and manual quarterly audits. But if you're managing 30+ resources across multiple services, Config pays for itself in reduced audit time.

How we'd apply it at Enekui

For a client running Bedrock + Lambda + RDS, we'd enable a subset of these rules via Terraform: - BEDROCK_MODEL_INVOCATION_LOGGING_ENABLED: ensures all Bedrock API calls are logged (critical for debugging and cost tracking). - RDS_INSTANCE_ENCRYPTION_AT_REST_ENABLED: flags any RDS instance without encryption (non-negotiable for GDPR workloads). - S3_BUCKET_PUBLIC_READ_PROHIBITED and S3_BUCKET_PUBLIC_WRITE_PROHIBITED: prevents accidental public buckets. - CLOUDTRAIL_ENABLED: ensures CloudTrail is active in all regions.

We'd bundle these into a custom conformance pack, deploy it once, and wire Config to SNS for Slack alerts. When a resource drifts (e.g. someone disables RDS encryption during a migration), the team gets notified within minutes, not weeks.

Example Terraform snippet for enabling a rule:

resource "aws_config_config_rule" "rds_encryption" {
  name = "rds-encryption-at-rest"

  source {
    owner             = "AWS"
    source_identifier = "RDS_INSTANCE_ENCRYPTION_AT_REST_ENABLED"
  }

  depends_on = [aws_config_configuration_recorder.main]
}

For a typical SMB client (€5-10k/month AWS spend), we'd enable 8-12 rules covering encryption, logging, and public access. Total Config cost: €30-50/month. Audit time saved: 4-6 hours per quarter.

Should you enable all 191 rules?

No. Start with the rules that map to your actual risks: - Storing customer data? Enable RDS/S3 encryption rules. - Running AI workloads? Enable Bedrock/SageMaker rules. - Multi-region setup? Enable CloudTrail multi-region rules.

Avoid enabling rules for services you don't use (e.g. Redshift rules if you're not running Redshift). Each active rule costs money and generates noise.

If you're unsure which rules matter, run a 2-week cloud diagnosis. We'll map your current resources to the relevant Config rules and estimate the compliance gap. Typical output: "You have 12 RDS instances, 3 lack encryption, here are the 4 Config rules to fix that."

Want help shipping this? We offer a cloud diagnosis (2 weeks, €2,900) that includes Config rule recommendations, Terraform setup, and Slack alerting. Get in touch.

Fuentes