AWS S3 Security: How to Prevent Data Leaks in 2026

Amazon S3 is the backbone of data storage in the cloud. Organizations store everything in S3: application assets, database backups, log files, analytics data, and increasingly sensitive information like customer records, financial documents, and healthcare data. This ubiquity makes S3 the single most targeted AWS service by attackers and the most common source of cloud data breaches.

The pattern is depressingly familiar. A company misconfigures a bucket policy, disables Block Public Access for a quick test and forgets to re-enable it, or grants overly broad access to a third-party integration. The result: terabytes of sensitive data exposed to the open internet. High-profile S3 breaches have impacted government agencies, Fortune 500 companies, and startups alike. The common thread is not sophisticated attacks but basic misconfigurations that could have been prevented with the right controls.

This guide walks through every layer of S3 security, from account-level settings to individual object controls, giving you a comprehensive defense against data leaks.

1. Block Public Access Settings

S3 Block Public Access is the most important single control in S3 security. It provides four independent settings that prevent public access regardless of individual bucket policies or ACLs.

Account-Level Block Public Access

Enable all four Block Public Access settings at the account level:

• BlockPublicAcls – Prevents setting public ACLs on buckets and objects.
• IgnorePublicAcls – Ignores any existing public ACLs.
• BlockPublicPolicy – Prevents setting bucket policies that grant public access.
• RestrictPublicBuckets – Restricts access to buckets with public policies to only AWS services and authorized users.

Enable these at the account level using the AWS CLI:

aws s3control put-public-access-block --account-id YOUR_ACCOUNT_ID --public-access-block-configuration '{"BlockPublicAcls":true,"IgnorePublicAcls":true,"BlockPublicPolicy":true,"RestrictPublicBuckets":true}'

Once enabled at the account level, no bucket in the account can be made public unless an administrator explicitly removes this protection. For the rare cases where a bucket must be public (such as a static website hosting bucket), use a separate AWS account dedicated to public-facing content, and apply Block Public Access to all other accounts.

Service Control Policies for Extra Protection

If you use AWS Organizations, create a Service Control Policy (SCP) that prevents anyone from removing Block Public Access settings. This ensures that even account administrators cannot accidentally or intentionally expose buckets.

2. Implement Bucket Policies and ACLs

Bucket policies are JSON documents that define who can access a bucket and what operations they can perform. They provide fine-grained control that complements IAM policies.

Bucket Policy Best Practices

• Default to deny. Start with no bucket policy (which defaults to private) and add only the specific grants you need.
• Use conditions to restrict access. Common conditions include aws:SourceVpc to limit access to a specific VPC, aws:SourceIp for IP-based restrictions, and aws:PrincipalOrgID to restrict access to your AWS Organization.
• Enforce HTTPS. Add a deny statement for any request where aws:SecureTransport is false. This prevents data from being transmitted in plaintext.
• Require specific encryption. Use a deny statement that rejects PutObject requests missing the x-amz-server-side-encryption header or specifying the wrong encryption type.

ACL Deprecation

AWS now recommends disabling ACLs entirely on new buckets and migrating away from ACLs on existing buckets. When you create a bucket with the BucketOwnerEnforced object ownership setting, ACLs are disabled and the bucket owner automatically owns all objects. This eliminates an entire category of misconfiguration.

Audit your existing buckets and migrate to the BucketOwnerEnforced setting wherever possible. Use bucket policies for all access control.

3. Enable Default Encryption

Encryption at rest protects your data if the underlying storage media is compromised and satisfies compliance requirements across every major framework.

Encryption Options

• SSE-S3 (AES-256) – Amazon manages the encryption keys entirely. This is the simplest option with zero operational overhead. AWS enabled SSE-S3 as the default for all new buckets in January 2023.
• SSE-KMS – Uses AWS Key Management Service for key management. Provides superior audit capabilities because every use of the key is logged in CloudTrail. You can also use customer-managed keys (CMKs) for full control over key policies, rotation, and deletion.
• SSE-C – You provide the encryption key with each request. Amazon uses your key to encrypt and decrypt but does not store it. This option gives maximum control but requires you to manage key storage and rotation.
• Client-side encryption – You encrypt data before uploading to S3. Amazon never sees the plaintext data. Use this for the most sensitive data where you want end-to-end encryption.

Recommendation

Use SSE-KMS with a customer-managed key for sensitive data. The CloudTrail integration provides a complete audit trail of every encryption and decryption operation, and key policies give you explicit control over who can access the data. Use the S3 Security Scanner tool to audit encryption configuration across all your buckets.

4. Enable Access Logging and Monitoring

You cannot detect unauthorized access if you are not recording access in the first place. S3 provides multiple logging mechanisms, and you should enable all of them for sensitive buckets.

S3 Server Access Logging

• Enable server access logging for all buckets containing sensitive data. Logs include the requester, bucket name, request time, request action, response status, and error code.
• Direct logs to a dedicated logging bucket. The logging bucket should have its own tight access controls and a lifecycle policy to manage storage costs.
• Do not enable logging on the logging bucket itself. This creates exponentially growing log files and can cause runaway storage costs.

CloudTrail Data Events

• Enable CloudTrail S3 data events. While server access logs provide request-level detail, CloudTrail data events integrate with the broader CloudTrail ecosystem, enabling CloudWatch alarms, EventBridge rules, and SIEM integration.
• Use event selectors to control scope. For high-volume buckets, you can log only specific operations (such as DeleteObject and PutBucketPolicy) to manage costs.

CloudWatch Metrics and Alarms

• Enable S3 request metrics for critical buckets. Monitor the number of requests, error rates, and data transfer volumes. Set alarms for unusual patterns such as a spike in GetObject requests or unexpected 403 errors.
• Monitor S3 storage metrics. A sudden increase in bucket size may indicate unauthorized data uploads, while a sudden decrease may indicate data exfiltration or deletion.

5. Use S3 Object Lock and Versioning

Object Lock and versioning protect against data deletion, whether accidental or malicious (such as ransomware).

Versioning

• Enable versioning on all buckets containing important data. Versioning preserves every version of every object, allowing you to recover from accidental deletions and overwrites.
• Add lifecycle rules to manage version storage costs. Transition older versions to S3 Glacier after 30 days and delete them after 365 days (adjusting based on your retention requirements).
• Require MFA Delete on critical buckets. MFA Delete requires multi-factor authentication to delete object versions or change the versioning state of a bucket. This is a powerful last line of defense against compromised credentials.

Object Lock

• Use Governance mode for most use cases. Governance mode prevents most users from deleting or overwriting objects during a retention period, but allows users with specific permissions to override the lock.
• Use Compliance mode for regulatory requirements. In Compliance mode, no one—including the root account—can delete a locked object during the retention period. Use this for data subject to regulatory retention requirements.
• Apply legal holds when needed. A legal hold prevents object deletion indefinitely until explicitly removed, which is useful for litigation holds and regulatory investigations.

6. Implement VPC Endpoints for S3

By default, traffic from your VPC to S3 travels over the public internet (even though it stays within AWS's network). VPC endpoints provide a private connection from your VPC to S3 that never traverses the public internet.

Gateway Endpoints

• Create a gateway VPC endpoint for S3 in every VPC. Gateway endpoints are free and require only a route table entry. They improve security by keeping traffic private and can improve performance by avoiding internet gateway bottlenecks.
• Apply an endpoint policy. The endpoint policy controls which S3 buckets can be accessed through the endpoint. Restrict it to only the buckets your VPC workloads need.

Bucket Policies with VPC Conditions

Combine VPC endpoints with bucket policies that restrict access to traffic originating from specific VPCs or endpoints. Add a deny statement with the condition "StringNotEquals": {"aws:sourceVpce": "vpce-xxxxxxxxx"} to ensure the bucket is only accessible through your VPC endpoint. This effectively creates a private bucket that cannot be accessed from the internet even if other controls fail.

7. Use Amazon Macie for Data Discovery

Amazon Macie is a data security service that uses machine learning and pattern matching to discover and protect sensitive data in S3.

What Macie Does

• Automated sensitive data discovery. Macie scans your S3 buckets and identifies objects containing personally identifiable information (PII), financial data, credentials, and other sensitive content.
• Bucket security assessment. Macie evaluates bucket configurations and flags security issues such as unencrypted buckets, public access, or buckets shared with external accounts.
• Continuous monitoring. After initial discovery, Macie monitors for new sensitive data and configuration changes, alerting you to emerging risks.

When to Use Macie

Macie is particularly valuable for organizations subject to compliance requirements (HIPAA, GDPR, PCI DSS) that mandate data classification. It is also useful during cloud migrations, when data from on-premises systems is moved to S3 and may contain unexpectedly sensitive content.

Enable Macie on at least your most sensitive buckets. Use the findings to classify data, apply appropriate encryption and access controls, and build a data inventory for compliance reporting.

Conclusion

S3 security is a layered discipline. No single control is sufficient; defense in depth is required. Start with Block Public Access at the account level to prevent the most common misconfiguration. Layer on bucket policies with encryption and HTTPS requirements. Enable comprehensive logging so you can detect unauthorized access. Add Object Lock and versioning to protect against data loss. Use VPC endpoints to keep traffic private, and deploy Macie to discover sensitive data you may not know about.

The most secure S3 configuration is one that assumes mistakes will happen and builds guardrails to prevent those mistakes from becoming breaches. Account-level Block Public Access, SCPs preventing its removal, and bucket policies restricting access to specific VPCs create multiple independent layers that an attacker would need to bypass simultaneously.

If you are concerned about the security of your S3 environment, our AWS security consulting services include a comprehensive S3 security assessment. We audit every bucket in your account, identify misconfigurations, and implement the controls described in this guide. Protecting your data in S3 is one of the most impactful things you can do for your organization's security posture.