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:
PracticeDetails
Block public access
Enable S3 Block Public Access at both bucket and account levels. Enforce via Service Control Policies (SCPs) in AWS Organizations.
Least-privilege IAM
Grant only specific actions each role needs. Avoid "Action": "s3:*" in production. Use presigned URLs for temporary access. Learn more about AWS IAM.
Encrypt at rest and in transit
Configure default SSE-S3 or SSE-KMS encryption. Enforce HTTPS by denying requests where aws:SecureTransport is false.
Enable versioning & Object Lock
Versioning preserves object history for recovery. Object Lock enforces WORM for compliance-critical data.
Unpredictable bucket names
Append a GUID or random identifier to reduce risk of bucket squatting.
VPC endpoints
Route internal workload traffic through VPC endpoints so it never traverses the public internet.
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:
ControlStatus
Block Public Access
Enabled at account and bucket level
ACLs disabled
Object Ownership set to "bucket owner enforced"
Default encryption
SSE-S3 or SSE-KMS configured
HTTPS enforced
Bucket policy denies aws:SecureTransport: false
Least-privilege IAM
No wildcard actions in production policies
Versioning
Enabled; Object Lock for sensitive data
Bucket naming
Includes unpredictable identifiers
VPC endpoints
Configured for internal workloads
Logging & monitoring
Server access logging, CloudTrail, GuardDuty, and IAM Access Analyzer active
AWS Config rules
s3-bucket-ssl-requests-only and related rules enabled
Disaster recovery
Cross-region replication configured where required
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.
