AWS S3 Security Checklist: Prevent Data Leaks in 2026
Secure Amazon S3 with this practical 2026 checklist covering public access, IAM, encryption, GuardDuty, logging, Object Lock, CLI auditing, and AWS Organizations.
The Complete AWS S3 Security Checklist to Prevent Data Leaks
Amazon S3 doesn't need to be hacked to leak data.
Sometimes it only needs one permission nobody reviewed.
A wildcard added during testing. An old vendor role. A cross-account policy that survived three migrations. A temporary public-access exception that quietly became permanent.
The infrastructure may be working exactly as configured.
That's the problem.
S3 security is not about adding the most controls. It is about making access intentional, explainable, observable, and recoverable.
A good S3 security architecture should make unauthorized access:
Hard to grant. Limited in scope. Easy to detect. Recoverable when something goes wrong.
AWS S3 SECURITY CHECKLIST
Secure Amazon S3 with layered protection across access control, encryption, monitoring, and backup and recovery.
Table of Contents
- The 60-Second S3 Security Audit
- Block Public Access
- Disable ACLs
- Apply Least Privilege
- Require TLS and Restrict Private Workloads
- Add Organization-Level Guardrails
- Choose the Right Encryption Model
- Detect Suspicious Access
- CloudTrail vs S3 Server Access Logs
- Keep Public Content Public Without Making S3 Public
- Prepare for Ransomware and Destructive Access
- Secure Replication and Backups
- Use Access Points and Access Grants at Scale
- Catch Misconfigurations Before Deployment
- Build the Incident-Response Workflow
- Map S3 Controls to Compliance Requirements
- AWS S3 Security FAQ
- Final AWS S3 Security Checklist
1. The 60-Second S3 Security Audit
Start with the controls that reduce the biggest blast radius.
| Priority | Security Check |
|---|---|
| 🔴 Critical | Block Public Access enabled |
| 🔴 Critical | No unintended public bucket policies |
| 🔴 Critical | ACLs disabled |
| 🔴 Critical | Bucket Owner Enforced enabled |
| 🔴 Critical | No unexplained wildcard principals |
| 🔴 Critical | Cross-account access reviewed |
| 🔴 Critical | Least-privilege IAM enforced |
| 🔴 Critical | TLS required |
| 🟠 High | CloudTrail S3 data events configured where needed |
| 🟠 High | GuardDuty S3 Protection enabled |
| 🟠 High | Access Analyzer findings reviewed |
| 🟠 High | Versioning enabled for critical data |
| 🟠 High | Encryption and KMS permissions reviewed |
| 🟡 Medium | Macie used for sensitive-data workloads |
| 🟡 Medium | Config/Security Hub monitors drift |
| 🟡 Medium | IaC security checks run before deployment |
If the critical controls are not in place, start there.
Don't optimize the alarm system while the front door is open.
Strong S3 security uses layered prevention, detection, and recovery controls so one failed safeguard does not become a data breach.
2. Block Public Access
Priority: 🔴 Critical
For most private workloads, S3 Block Public Access should stay enabled.
The four controls are:
BlockPublicAclsIgnorePublicAclsBlockPublicPolicyRestrictPublicBuckets
AWS recommends retaining Block Public Access unless public access is explicitly required.
Check a bucket
1
2
aws s3api get-public-access-block \
--bucket YOUR-BUCKETCheck account-level protection
1
2
aws s3control get-public-access-block \
--account-id YOUR_ACCOUNT_IDAudit bucket policies for public status
1
2
3
4
5
6
7
8
9
10
11
for bucket in $(aws s3api list-buckets \
--query 'Buckets[].Name' \
--output text); do
echo "Checking $bucket"
aws s3api get-bucket-policy-status \
--bucket "$bucket" \
--query 'PolicyStatus.IsPublic' \
--output text 2>/dev/null || echo "No bucket policy"
doneDo not treat this script as your entire audit. Access Points, IAM policies, organization controls, and cross-account permissions still matter.
3. Disable ACLs
Priority: 🔴 Critical
Modern S3 authorization is easier to reason about when ACLs are removed from the equation.
New buckets use Bucket owner enforced Object Ownership by default, which disables ACLs.
That lets you concentrate access control in:
- IAM policies
- bucket policies
- access-point policies
- VPC endpoint policies
- organization guardrails
Check the setting with:
1
2
aws s3api get-bucket-ownership-controls \
--bucket YOUR-BUCKETFor legacy buckets, move legitimate ACL permissions into policies before disabling ACLs.
Complexity is security debt.
Every additional permission system creates another place where forgotten access can survive.
4. Apply Least Privilege
Priority: 🔴 Critical
Broad permissions are easy to write and expensive to defend.
Avoid granting:
1
"Action": "s3:*"when the workload needs only a few actions.
Ask three questions:
Who needs access?
What exact action do they need?
Which exact resources do they need it on?
What exact action do they need?
Which exact resources do they need it on?
Example: read-only workload for one prefix
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "ListReports",
"Effect": "Allow",
"Action": "s3:ListBucket",
"Resource": "arn:aws:s3:::company-data",
"Condition": {
"StringLike": {
"s3:prefix": ["reports/*"]
}
}
},
{
"Sid": "ReadReports",
"Effect": "Allow",
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::company-data/reports/*"
}
]
}Be especially careful with permissions that can modify bucket policies, Block Public Access, Access Points, replication, KMS configuration, or Object Lock.
Reading one object is powerful.
Changing who can read every object is more powerful.
5. Require TLS and Restrict Private Workloads
Priority: 🔴 Critical
S3 traffic should use TLS.
AWS Security Hub control S3.5 checks whether bucket policies require secure transport and maps that control to PCI DSS v4.0.1 requirement 4.2.1.
Deny non-TLS requests
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
{
"Sid": "DenyInsecureTransport",
"Effect": "Deny",
"Principal": "*",
"Action": "s3:*",
"Resource": [
"arn:aws:s3:::company-data",
"arn:aws:s3:::company-data/*"
],
"Condition": {
"Bool": {
"aws:SecureTransport": "false"
}
}
}For private workloads, you can also restrict access to an approved VPC endpoint.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
{
"Sid": "DenyOutsideApprovedVPCE",
"Effect": "Deny",
"Principal": "*",
"Action": "s3:*",
"Resource": [
"arn:aws:s3:::company-data",
"arn:aws:s3:::company-data/*"
],
"Condition": {
"StringNotEquals": {
"aws:SourceVpce": "vpce-0123456789abcdef0"
}
}
}Test this carefully before production deployment. A strict endpoint condition can block legitimate administration or AWS service integrations that do not use that endpoint.
6. Add Organization-Level Guardrails
Priority: 🔴 Critical for multi-account environments
Managing every bucket independently does not scale.
AWS recommends data-perimeter controls built around three ideas:
trusted identities, trusted resources, expected networks.
aws:PrincipalOrgID is useful for restricting access to identities in your AWS Organization.But there is a trap.
AWS service principals such as CloudTrail are not members of your Organization. A blanket organization-ID deny can therefore break legitimate service delivery.
Use
aws:PrincipalIsAWSService to exempt direct AWS service principals from the deny. AWS specifically documents this pattern for data perimeters.Organization boundary example
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "DenyOutsideOrganization",
"Effect": "Deny",
"Principal": "*",
"Action": "s3:*",
"Resource": [
"arn:aws:s3:::company-data",
"arn:aws:s3:::company-data/*"
],
"Condition": {
"StringNotEquals": {
"aws:PrincipalOrgID": "o-example123"
},
"BoolIfExists": {
"aws:PrincipalIsAWSService": "false"
}
}
}
]
}This exemption does not mean every AWS service automatically receives permission. Required service access still needs correctly scoped Allow statements.
Where supported, use conditions such as
aws:SourceArn, aws:SourceAccount, or aws:SourceOrgID to reduce confused-deputy risk.There is another consequence:
third-party vendors using AWS accounts outside your Organization will also be denied.
If an external SaaS platform legitimately needs access, design an explicit exception rather than weakening your entire perimeter.
At organization scale, combine resource policies with SCPs, RCPs, and VPC endpoint policies.
7. Choose the Right Encryption Model
Priority: 🟠 High
Amazon S3 applies SSE-S3 as its baseline server-side encryption for uploaded objects.
Encryption still matters—but it does not repair bad authorization.
If an identity legitimately has
GetObject, storage encryption does not make that permission disappear.SSE-S3 vs SSE-KMS vs SSE-C
Compare SSE-S3, SSE-KMS, and SSE-C to choose the right Amazon S3 encryption model based on control, compliance, cost, and operational complexity.
| Feature | SSE-S3 | SSE-KMS | SSE-C |
|---|---|---|---|
| Key management | Amazon S3 | AWS KMS | Customer supplies key |
| S3 default | Yes | No | No |
| Customer key-policy control | None | Yes with customer-managed KMS keys | No AWS key policy |
| KMS key-use auditing | No | Yes | No |
| Additional KMS request cost | No | Yes | No |
| Complexity | Low | Medium | High |
| Best fit | General workloads | Stronger key control/compliance | Specialized legacy use cases |
In April 2026, AWS changed the default behavior for SSE-C. New general-purpose buckets now reject new SSE-C write requests unless SSE-C is deliberately enabled. AWS also applied the restriction to qualifying existing buckets with no SSE-C-encrypted objects.
For SSE-KMS, remember that the KMS key policy becomes part of your authorization model.
A tightly restricted S3 policy paired with an overly broad KMS policy is not the security win it appears to be.
8. Detect Suspicious Access
Priority: 🟠 High
A private bucket can still be compromised when valid credentials are stolen.
That is why prevention alone is incomplete.
IAM Access Analyzer
Use Access Analyzer to identify unintended public and cross-account access.
Every finding should become one of two things:
Expected → documented.
Unexpected → removed.
GuardDuty S3 Protection
GuardDuty S3 Protection analyzes S3 object-level activity for suspicious behavior.
Importantly, GuardDuty does not require you to enable S3 data-event logging in your own CloudTrail trail before GuardDuty can analyze the required data events.
Amazon Macie
Macie helps discover sensitive information in S3.
That changes the risk question from:
“Is this bucket exposed?”
to:
“What would the exposure actually reveal?”
A marketing-image bucket and a customer-record archive should not receive the same incident priority.
9. CloudTrail vs S3 Server Access Logs
Priority: 🟠 High
The two logging options overlap, but they are not identical.
| Capability | CloudTrail | S3 Server Access Logs |
|---|---|---|
| Main purpose | API/security auditing | S3 request records |
| Object activity | Data events when configured | Yes |
| Format | JSON | S3 delivery: newline-delimited records with space-delimited fields |
| Delivery | Event-oriented | Best effort |
| Investigation value | High | Supplementary |
| Cost | Data-event charges may apply | S3 log delivery has no delivery fee; storage/analysis still cost |
AWS documents S3-delivered server access logs as newline-delimited records made up of space-delimited fields. New CloudWatch-based server-access-log delivery can use structured JSON instead.
CloudTrail S3 data events are not automatically part of every trail and can generate significant volume.
Use them where the investigative or compliance value justifies the cost.
Security Hub maps S3 object-level read/write logging controls S3.22 and S3.23 to PCI DSS v4.0.1 requirement 10.2.1.
10. Keep Public Content Public Without Making S3 Public
Priority: 🟠 High
A website needing public files does not necessarily need a public S3 bucket.
For supported S3 origins, use:
Users → CloudFront → Origin Access Control → Private S3
AWS recommends Origin Access Control over the older Origin Access Identity model. OAC adds broader Region support, SSE-KMS support, and support for additional S3 request types.
CloudFront Origin Access Control lets you deliver public content while keeping the underlying S3 bucket private and reducing direct-origin exposure.
11. Prepare for Ransomware and Destructive Access
Priority: 🟠 High
Not every attacker wants to download your data.
Some want to destroy it.
Imagine a compromised deployment role with
s3:DeleteObject.Thousands of files disappear.
That is still a security incident.
Use S3 Versioning for important data so previous object versions can be recovered.
For higher-value backups and records, evaluate S3 Object Lock.
Object Lock uses a WORM model and can prevent protected object versions from being deleted or overwritten for a retention period or indefinitely.
Think in layers:
Versioning improves recovery.
Object Lock improves immutability.
Least privilege reduces destructive access.
GuardDuty helps detect suspicious activity.
Object Lock improves immutability.
Least privilege reduces destructive access.
GuardDuty helps detect suspicious activity.
12. Secure Replication and Backups
Priority: 🟠 High
A backup that uses the same trust boundary as production can fail with production.
For critical workloads, consider replication into a separately governed account or Region.
Review:
- replication IAM roles
- destination bucket policies
- KMS key permissions
- deletion privileges
- Object Lock settings
- recovery procedures
The principle is simple:
Compromising production should not automatically compromise recovery.
For particularly important datasets, test restoration rather than merely confirming that replication exists.
A backup you have never restored is still a theory.
13. Use Access Points and Access Grants at Scale
Priority: 🟡 Medium
One giant bucket policy can become harder to understand than the system it protects.
S3 Access Points let different workloads use separate endpoints and policies against shared data.
The current default quota is 10,000 S3 Access Points per AWS account per AWS Region, and AWS allows quota-increase requests. It is not a per-bucket quota.
Each Access Point is associated with one data source, such as a bucket.
S3 Access Grants can help when access must be delegated across many users, groups, applications, and data prefixes.
The rule:
Keep simple environments simple.
But when one policy becomes an organizational map, split the access paths into clearer boundaries.
14. Catch Misconfigurations Before Deployment
Priority: 🟠 High
The cheapest S3 leak is the one your pipeline rejects.
Use infrastructure-as-code and policy-as-code checks before deployment.
Useful tools include:
- CloudFormation Guard
- Checkov
- tfsec or equivalent Terraform scanning
- AWS Config
- CloudFormation Hooks
CloudFormation security baseline
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
Resources:
SecureBucket:
Type: AWS::S3::Bucket
DeletionPolicy: Retain
Properties:
PublicAccessBlockConfiguration:
BlockPublicAcls: true
IgnorePublicAcls: true
BlockPublicPolicy: true
RestrictPublicBuckets: true
OwnershipControls:
Rules:
- ObjectOwnership: BucketOwnerEnforced
BucketEncryption:
ServerSideEncryptionConfiguration:
- ServerSideEncryptionByDefault:
SSEAlgorithm: AES256
VersioningConfiguration:
Status: EnabledThe larger principle matters more than the template:
Secure defaults belong in code, not in someone's memory.
15. Build the Incident-Response Workflow
Priority: 🔴 Critical
When GuardDuty flags suspicious downloads or Access Analyzer discovers external access, your response should already be defined.
S3 INCIDENT-RESPONSE FLOW
A predefined S3 incident-response process helps teams contain exposure faster, preserve evidence, recover safely, and prevent the same misconfiguration from happening again.
16. Map S3 Controls to Compliance Requirements
Compliance mappings need care.
A technical S3 control can support a compliance requirement. It rarely satisfies the entire requirement by itself.
AWS Security Hub publishes explicit mappings between several S3 controls and PCI DSS v4.0.1.
SOC 2 and ISO/IEC 27001 are different: auditors evaluate broader control design and operating effectiveness. Treat the SOC 2 and ISO columns below as an engineering crosswalk for evidence planning—not an automatic certification claim.
| S3 Control | PCI DSS v4.0.1 | SOC 2 TSC | ISO/IEC 27001:2022 |
|---|---|---|---|
| Block Public Access | 1.4.4 | CC6.6 | A.5.15, A.8.20 |
| Least-privilege IAM | 7.2.1 | CC6.1, CC6.3 | A.5.15, A.5.18 |
| TLS-only access | 4.2.1 | CC6.7 | A.8.24 |
| SSE-KMS for scoped regulated data | 3.5.1 | CC6.1; C1.1 if Confidentiality is in scope | A.8.24 |
| S3 access/API logging | 10.2.1 | CC7.2 | A.8.15, A.8.16 |
| GuardDuty monitoring | Supports Req. 10/12.10 | CC7.2, CC7.3 | A.8.16, A.5.25 |
| Object Lock for protected logs | 10.5.1 | CC7.4/CC7.5 where relevant | A.8.13, A.8.15 |
| Incident-response process | 12.10.1 | CC7.3–CC7.5 | A.5.24–A.5.27 |
| IaC/change controls | Supports secure configuration obligations | CC8.1 | A.8.9, A.8.32 |
AWS explicitly maps Security Hub S3.5 to PCI DSS 4.2.1, S3.17 to 3.5.1, S3.9/S3.22/S3.23 to 10.2.1, S3.15 to 10.5.1, and public-access controls such as S3.8/S3.19 to 1.4.4.
For SOC 2, CC6-series criteria address logical access and external boundaries, while CC7.2 addresses monitoring for anomalous activity.
For ISO/IEC 27001:2022, examples include A.5.15 for access control and A.8.15 for logging.
What auditors will actually want
The setting itself is only the beginning.
Expect evidence such as:
- approved access-control policies
- current IAM and bucket-policy exports
- access-review records
- Security Hub or Config findings
- CloudTrail samples
- KMS configuration
- incident-response exercises
- restoration tests
- change approvals
- retained CI/CD security-scan results
A screenshot of a green setting is weak evidence if nobody can prove the control operated consistently throughout the audit period.
17. AWS S3 Security FAQ
Is S3 public by default?
New S3 environments are designed around private access, including Block Public Access protections and Bucket Owner Enforced ownership controls. You should still verify inherited and existing configurations rather than assuming every historical bucket follows modern defaults.
How do I check whether a bucket policy is public?
Start with:
1
2
aws s3api get-bucket-policy-status \
--bucket YOUR-BUCKETThen review Block Public Access, Access Points, cross-account policies, organization controls, and IAM Access Analyzer findings.
Is S3 encrypted by default?
Yes. S3 uses SSE-S3 as the baseline server-side encryption for uploaded objects.
Is SSE-KMS always better?
No.
SSE-KMS provides stronger key separation, policy control, and KMS auditing, but also adds complexity and KMS cost.
Use it when the additional control solves a real security, governance, or compliance requirement.
Does encryption protect against bad IAM permissions?
No.
Encryption protects stored data.
Authorization determines who is allowed to retrieve it.
Do I need both CloudTrail and GuardDuty?
They solve different problems.
CloudTrail provides audit records.
GuardDuty analyzes activity for suspicious behavior.
For important workloads, they complement each other.
Should I use S3 Server Access Logging too?
Sometimes.
It can provide useful request-level records, but traditional S3 delivery is best-effort. Use it according to your operational and compliance needs rather than treating it as a replacement for CloudTrail.
18. Final AWS S3 Security Checklist
🔴 Prevent
- Block Public Access enabled
- ACLs disabled
- Bucket Owner Enforced
- Wildcard principals reviewed
- Cross-account permissions documented
- Least-privilege IAM enforced
- TLS required
- VPC/network restrictions applied where appropriate
- Organization guardrails tested
- AWS service exceptions narrowly scoped
🟠 Protect
- Encryption configuration verified
- KMS permissions reviewed
- Versioning enabled
- Object Lock evaluated
- Backup/replication trust boundary reviewed
🟠 Detect
- Required CloudTrail S3 data events enabled
- IAM Access Analyzer reviewed
- GuardDuty S3 Protection enabled
- Macie considered for sensitive datasets
- Config/Security Hub monitoring enabled
- Every meaningful alert has an owner
🟡 Engineer Securely
- S3 configuration managed as code
- IaC scans run in CI/CD
- Policy changes peer-reviewed
- Exceptions documented
- Restore process tested
- Incident-response procedure exercised
Use this AWS S3 security checklist during architecture reviews, deployment approvals, and cloud-security audits to reduce exposure and improve recovery.
The Bottom Line
The dangerous bucket is rarely the one everyone knows is public.
It is the bucket everyone assumes is private.
Permissions accumulate. Integrations outlive their owners. Temporary exceptions become architecture. Valid credentials get compromised. Backups inherit the same permissions as production.
The answer is not another checkbox.
It is a system:
Prevent what you can.
Detect what gets through.
Recover from what succeeds.
Detect what gets through.
Recover from what succeeds.
Start with Block Public Access.
Reduce permission paths.
Keep ACLs disabled.
Audit cross-account access.
Require TLS.
Monitor object activity.
Protect recovery copies.
Move repeatable security rules into code and organization-level guardrails.
Then ask one question:
Can your team explain in 60 seconds who can access a production S3 bucket, what they can do, where they can access it from, and how you'll know when that changes?
If not, the bucket isn't understood well enough yet.
And what you don't understand is what eventually surprises you.
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article