S3 Bucket Security Best Practices
Amazon S3 is one of the most widely used cloud storage services in the world, and with that scale comes real security responsibility. Misconfigured buckets remain a leading cause of sensitive data exposure in cloud environments, from accidentally public objects to overly permissive policies that go unnoticed for months. Whether you're hosting static assets, storing application data, or archiving compliance records, getting S3 bucket security right is not optional. This guide covers foundational defaults, policy configurations, and practical checklists to give you an actionable reference as of early 2026.
How S3 Bucket Security Works by Default
A common misconception is that S3 buckets are inherently risky. In reality, all S3 buckets are private by default. When you create a new bucket, no public access is granted, and AWS automatically enables Block Public Access settings at the account level.
Access is governed by a layered permission model where an explicit Deny always overrides an Allow, regardless of where it's defined. Understanding this hierarchy is the foundation of any secure configuration:
- IAM identity-based policies, control what actions a user or role can perform
- Bucket resource-based policies, define who can access a specific bucket and under what conditions
- Access Control Lists (ACLs), legacy object-level permissions (AWS now recommends disabling these entirely)
- VPC endpoint policies, restrict which buckets and actions are reachable from within a VPC
AWS recommends setting S3 Object Ownership to "bucket owner enforced," which disables ACLs. This simplifies permission management significantly, instead of managing object-level ACLs across millions of objects, all access flows through bucket policies and IAM, which are far easier to audit.
AWS S3 Security Best Practices
A defense-in-depth approach means layering multiple controls rather than relying on any single setting. Here is the current AWS-recommended baseline:
S3 Bucket Policy Examples for Common Security Scenarios
Bucket policies are JSON documents attached directly to a bucket that define who can access it and under what conditions. Below are the most practically useful examples.
Enforce HTTPS-Only Access
{
"Version": "2012-10-17",
"Statement": [{
"Sid": "RestrictToTLSRequestsOnly",
"Effect": "Deny",
"Principal": "*",
"Action": "s3:*",
"Resource": [
"arn:aws:s3:::your-bucket-name",
"arn:aws:s3:::your-bucket-name/*"
],
"Condition": { "Bool": { "aws:SecureTransport": "false" } }
}]
}
Deny Unencrypted Uploads (Enforce KMS)
{
"Version": "2012-10-17",
"Statement": [{
"Sid": "DenyObjectsThatAreNotSSEKMS",
"Principal": "*",
"Effect": "Deny",
"Action": "s3:PutObject",
"Resource": "arn:aws:s3:::your-bucket-name/*",
"Condition": {
"Null": {
"s3:x-amz-server-side-encryption-aws-kms-key-id": "true" } } }]}
Other Common Patterns
- Restrict to a specific VPC endpoint: Use the aws:sourceVpce condition key to ensure the bucket is only reachable from a designated private network.
- Grant CloudFront OAI access: Allow only the Origin Access Identity principal, keeping objects private from direct URL access while serving them through the CDN.
- IP-based restrictions: Use NotIpAddress with aws:SourceIp to deny requests from outside a trusted CIDR range.
Always use "Version": "2012-10-17" and validate policies through IAM Access Analyzer before deployment to catch unintended access grants.
Enforcing SSL with the s3-bucket-ssl-requests-only Policy
Forcing all S3 traffic over HTTPS is one of the most straightforward, high-impact controls available. The AWS Config managed rule s3-bucket-ssl-requests-only checks whether your bucket policy explicitly denies HTTP requests, flagging non-compliant buckets automatically.
The policy evaluates the aws:SecureTransport condition key. When a request arrives over plain HTTP, this key evaluates to false, and the Deny statement blocks it. This applies to all principals, AWS services, cross-account roles, and anonymous requests alike. Adding the HTTPS-only Deny statement shown in the policy examples section above satisfies both the AWS Config rule and common compliance requirements under PCI-DSS and HIPAA.
Using an S3 Bucket Policy Generator Safely
The AWS Policy Generator is a useful starting point, but generated policies require careful review before going into production. Follow these steps:
- Select "S3 Bucket Policy" as the policy type, then fill in the principal, actions, resource ARN, and conditions (e.g., aws:SecureTransport or aws:SourceIp).
- Check for overly broad principals, avoid "Principal": "*" unless intentional.
- Verify resource ARNs are scoped correctly (bucket-level vs. object-level).
- Use IAM Access Analyzer's "Preview external access" feature to understand the real-world effect before saving.
The generator is a scaffold, security judgment still applies. Never paste generated JSON directly into production without review.
S3 Bucket Security Checklist
Use this consolidated checklist to audit any S3 bucket configuration:
How Sentra Strengthens S3 Bucket Security at Scale
Applying the right bucket policies and IAM controls is necessary, but at enterprise scale, knowing which buckets contain sensitive data, how that data moves, and who can access it becomes the harder problem. This is where cloud data exposure typically occurs: not from a single misconfigured bucket, but from data sprawl across hundreds of buckets that no one has a complete picture of.
Sentra discovers and classifies sensitive data at petabyte scale directly within your environment, data never leaves your control. It maps data movement across S3, identifies shadow data and over-permissioned buckets, and enforces data-driven guardrails aligned with compliance requirements. For organizations adopting AI, Sentra provides the visibility needed to ensure sensitive training data or model outputs in S3 are properly governed. Eliminating redundant and orphaned data typically reduces cloud storage costs by around 20%.
S3 bucket security is not a one-time configuration task. It's an ongoing practice spanning access control, encryption, network boundaries, monitoring, and data visibility. The controls covered here, from enforcing SSL and disabling ACLs to using policy generators safely and maintaining a security checklist, give you a comprehensive framework. As your environment grows, pairing these technical controls with continuous data discovery ensures your security posture scales with your data, not behind it.
All S3 buckets are private by default. When you create a new bucket, no public access is granted, and AWS automatically enables Block Public Access settings at the account level.
Add a bucket policy with a Deny statement that blocks all requests where the <code>aws:SecureTransport</code> condition key is <code>false</code>. The AWS Config managed rule <code>s3-bucket-ssl-requests-only</code> can then automatically flag non-compliant buckets.
Setting S3 Object Ownership to "bucket owner enforced" disables ACLs, which simplifies permission management. Instead of managing object-level ACLs across millions of objects, all access flows through bucket policies and IAM, making configurations far easier to audit.
The AWS Policy Generator is a useful starting point, but generated policies should never be pasted directly into production. Always review for overly broad principals, verify resource ARN scoping, and use IAM Access Analyzer's "Preview external access" feature before deploying.
Key controls include enabling Block Public Access at account and bucket levels, disabling ACLs, configuring default encryption (SSE-S3 or SSE-KMS), enforcing HTTPS via bucket policy, applying least-privilege IAM, enabling versioning, using VPC endpoints for internal workloads, and activating logging through CloudTrail, GuardDuty, and IAM Access Analyzer.
Nikki Ralston is Senior Product Marketing Manager at Sentra, with over 20 years of experience bringing cybersecurity innovations to global markets. She works at the intersection of product, sales, and markets translating complex technical solutions into clear value. Nikki is passionate about connecting technology with users to solve hard problems.
