How to Enforce S3 Guardrails With AWS Config Rules

Retrospective: this article looks back at events from November 2017, written in 2026 with the benefit of hindsight.

AWS Config continuously evaluates resource settings against rules. For S3, a handful of rules catches most of the misconfigurations behind past data exposures. Here is how to set them up across your organization.

Step 1: Enable AWS Config everywhere

Enable AWS Config recording in every account and region, ideally through AWS Control Tower or an organization-wide deployment. Aggregate results into your security tooling account.

Step 2: Deploy key S3 managed rules

Start with these AWS managed rules:

• s3-bucket-public-read-prohibited and s3-bucket-public-write-prohibited
• s3-account-level-public-access-blocks-periodic
• s3-bucket-ssl-requests-only
• s3-bucket-server-side-encryption-enabled
• s3-bucket-logging-enabled (for sensitive buckets)
• s3-bucket-versioning-enabled (for critical data)

The simplest way to deploy many rules together is a conformance pack, such as the operational best practices packs AWS provides for frameworks like CIS.

Step 3: Add automatic remediation where safe

Attach Systems Manager automation documents to rules so non-compliant settings are fixed automatically — for example, re-enabling Block Public Access. Start with notification only, then automate once you trust the results.

Step 4: Route findings

Send Config findings to AWS Security Hub alongside GuardDuty and other services, so one queue shows all cloud security issues.

Step 5: Add preventive controls

Config detects and fixes after the fact. Pair it with Service Control Policies that prevent the risky change in the first place, such as denying deletion of account-level public access blocks.

Common mistakes

• Enabling Config only in the main region.
• Hundreds of findings with no owner. Assign remediation by account owner.