In April 2023, Amazon turned on Block Public Access by default for every new S3 bucket. That single change quietly fixed a mistake that had leaked data from thousands of companies for years. Yet misconfigured buckets still show up in breach reports, and most of the damage traces back to a handful of repeatable errors. The good news: these mistakes are predictable, and once you know them, they are easy to dodge. (What is Amazon S3?)
This guide covers the S3 traps that affect teams in production: permissions, versioning, lifecycle rules, and cost surprises. It focuses on what works in practice, including details beyond the documentation.
Why S3 Mistakes Are So Common
S3 is deceptively simple. You create a bucket, upload a file, and it works. That ease hides a deep configuration surface: bucket policies, ACLs, IAM roles, encryption, replication, and lifecycle rules all interact. A small change in one place can quietly undo a safeguard in another.
Three forces make this worse:
- Defaults changed over time. Encryption and public access blocking are now on by default, but buckets created years ago may not reflect that.
- Permissions stack. A bucket policy, an IAM policy, and an ACL can each grant access. One loose rule is enough to expose data.
- Deletion is permanent without guardrails. Versioning helps, but it is not a backup on its own.
Understanding the mechanics matters most. S3 stores objects inside buckets, and each object is addressed by a key. Access is controlled at the bucket and object level. When any of those layers is misconfigured, the results range from a surprise bill to a public data leak.
Mistake 1: Assuming Buckets Are Private by Default
The single most damaging S3 mistake is leaving a bucket open to the world. Older buckets created before the 2023 default change may still allow public access unless someone explicitly configured Block Public Access.
The fix is straightforward but easy to skip:
- Turn on Block Public Access at the account level in addition to per-bucket settings.
- Audit existing buckets for public policies and public ACLs.
- Use AWS Config or a similar tool to flag any bucket that drifts toward public access.
A bucket policy that grants `s3:GetObject` to `Principal: “*”` is the classic culprit. It looks harmless in a quick review but exposes every object to anyone with the URL. Static website hosting is the usual reason teams open a bucket, and it is rarely the right reason for sensitive data.
Mistake 2: Fighting Bucket Policies, ACLs, and IAM at Once
Access control in S3 is where confusion peaks. Three systems can grant permission, and they do not always agree.
| Control | What It Does | Common Trap |
|---|---|---|
| IAM policies | Grants permissions to users and roles | Overly broad `s3:` on `` resources |
| Bucket policies | Grants access at the bucket level | Public principals or missing conditions |
| ACLs | Legacy object and bucket permissions | Still enabled when they should be disabled |
Since 2023, new buckets default to Bucket Owner Enforced object ownership, which disables ACLs. Teams that copy old tutorials still try to set ACLs on these buckets, and the changes are ignored or fail. The practical rule: pick one model, usually IAM plus bucket policies, and disable ACLs unless a legacy workload truly needs them.
Another frequent slip is granting `s3:*` to a role “just to get it working.” That role can then delete data, change policies, and read everything. Scope permissions to specific actions and specific prefixes.
Mistake 3: Treating Versioning as a Backup
Versioning sounds like a safety net. It is not a full one. When versioning is on, overwriting or deleting an object keeps prior versions, but anyone with `s3:DeleteObjectVersion` can permanently remove every version. Versioning alone does not stop a determined or careless actor.
To make versioning meaningful:
- Enable MFA Delete for buckets holding critical data.
- Add Object Lock in compliance mode where regulations demand immutability.
- Pair versioning with lifecycle rules that expire noncurrent versions on a sensible schedule, so storage costs do not balloon.
A common mistake is enabling versioning and then forgetting it. Costs creep up as old versions pile up, and nobody notices until the bill arrives. Versioning without lifecycle rules is a slow leak.
Mistake 4: Misconfigured Lifecycle Rules That Delete Too Much
Lifecycle rules are powerful and unforgiving. A rule that matches a broad prefix can expire objects you meant to keep. A rule that expires noncurrent versions can permanently erase the history you thought versioning protected.
Practical safeguards:
- Test rules on a non-production bucket first.
- Use specific prefixes rather than the whole bucket.
- Review transition and expiration timing together, since a transition to a cheaper storage class followed by early expiration can cost more than it saves.
- Watch for aborted multipart uploads. These invisible fragments incur storage charges until a lifecycle rule cleans them up.
Many teams learn this the hard way when a “cleanup” rule wipes logs they needed for an audit. Lifecycle rules deserve the same review process as code changes.
Mistake 5: Ignoring Encryption Details
Since January 2023, S3 encrypts all new objects by default with SSE-S3. That is a real improvement, but it does not satisfy every compliance requirement. Some frameworks demand customer-managed keys and key rotation, which means SSE-KMS instead of the default.
Two mistakes stand out:
- Assuming default encryption covers bucket-level metadata or access logs.
- Using KMS keys without planning for request costs, which can spike with high-volume workloads.
The right choice depends on the data. For regulated workloads, customer-managed keys with tight key policies are usually required. For general storage, the default is often enough. The error is not choosing one or the other; it is never deciding at all.
Mistake 6: Forgetting That Consistency Is No Longer a Problem
Older articles still warn about eventual consistency in S3. That guidance is outdated. Since December 2020, S3 provides strong read-after-write consistency for all PUT and DELETE operations. A new object is immediately visible to reads, and overwrites and deletes are reflected right away.
Why does this matter? Teams sometimes build unnecessary workarounds, like polling loops or delayed reads, to handle a consistency problem that no longer exists. Removing those workarounds simplifies code and cuts latency. If a design pattern exists only to dodge eventual consistency, it is probably dead weight now.
Mistake 7: Skipping Replication and Backup Planning
Replication is not automatic backup. Cross-Region Replication requires versioning on both source and destination buckets, and it does not retroactively copy existing objects unless you run Batch Replication. Teams often enable replication and assume everything is protected, then discover years of data were never copied.
A sound plan separates concerns:
- Use replication for latency, regional resilience, or compliance.
- Use a separate backup process, such as AWS Backup, for point-in-time recovery.
- Test restores as well as copies.
The same logic applies to any workflow that touches S3 files. If someone needs to document a configuration or capture an error message, knowing how to take a screenshot on a mac or how to take a screenshot on windows speeds up incident reports. Small operational habits like these keep debugging from dragging on.
Mistake 8: Getting Surprised by Costs
S3 pricing has several moving parts: storage, requests, data transfer, and retrieval fees for colder storage classes. A few mistakes show up again and again.
| Cost Trap | What Happens | Fix |
|---|---|---|
| Aborted multipart uploads | Fragments sit and bill indefinitely | Lifecycle rule to abort incomplete uploads |
| Wrong storage class | Frequent access to Glacier tiers triggers retrieval fees | Match class to access pattern |
| Requester Pays misconfiguration | Unexpected bills or blocked access | Confirm who pays before enabling |
| Unmonitored data transfer | Egress costs climb quietly | Set budgets and alerts |
Transfer Acceleration and multipart uploads have their own thresholds. Multipart upload is recommended for objects over 100 MB and required over 5 GB, but abandoned uploads are a silent cost. A single lifecycle rule that aborts incomplete multipart uploads after a few days often pays for itself.
It also helps to know when a tool or service is winding down, since migrations create their own S3 costs. Readers tracking platform changes may find it useful to follow news like Amazon Luna ending game purchases in 2026, a reminder that cloud services evolve and budgets should flex with them. (Amazon S3)
Mistake 9: Weak Naming and Bucket Hygiene
Bucket names are globally unique and must follow DNS rules: 3 to 63 characters, lowercase, no IP-address format. A subtle risk is bucket name reuse. If a bucket is deleted, someone else can register the same name, and any application still pointing at it may send data to a stranger.
Good hygiene includes:
- Using organization-specific prefixes in bucket names.
- Avoiding names that reveal company or environment details.
- Keeping an inventory of buckets and their owners.
Naming feels trivial until a stale reference sends logs to a bucket someone else now controls.
Mistake 10: No Monitoring or Alerting
Many S3 incidents are discovered by customers or researchers, not by the team that owns the bucket. That gap is a monitoring failure. Practical steps include enabling server access logging, turning on CloudTrail data events for sensitive buckets, and alerting on policy changes.
A simple dashboard that tracks public access status, encryption settings, and versioning state catches drift before it becomes a headline. The cheapest security control is often the alert nobody set up.
A Practical Checklist
Before shipping any S3-backed feature, run through these checks:
- Account-level Block Public Access is on.
- ACLs are disabled unless a legacy workload needs them.
- IAM policies are scoped to specific actions and prefixes.
- Versioning, MFA Delete, or Object Lock protect critical data.
- Lifecycle rules are tested and scoped to narrow prefixes.
- Encryption choice matches compliance needs.
- Replication and backup are separate, tested processes.
- Budgets and alerts cover storage, requests, and transfer.
- Bucket names are unique and owned.
- Logging and CloudTrail data events are enabled.
Conclusion
Most S3 disasters are not exotic. They come from a public bucket policy, an over-broad IAM role, a lifecycle rule that deleted too much, or a bill nobody watched. The platform keeps improving its defaults, but defaults only protect new resources, and only if teams understand what changed. Treat S3 configuration like code: review it, test it, monitor it, and revisit it when the defaults shift. Do that, and the scary headlines stay someone else’s problem.
Frequently Asked Questions
Are S3 buckets private by default?
For buckets created after April 2023, yes. Block Public Access is enabled by default, and ACLs are disabled unless you change object ownership settings. Older buckets may still allow public access, so an audit is worth the effort.
Does S3 versioning protect against deletion?
Only partly. Versioning keeps prior versions, but anyone with permission to delete object versions can remove them permanently. For real protection, add MFA Delete or Object Lock, and use lifecycle rules to manage old versions.
Is S3 eventually consistent?
No, not anymore. Since December 2020, S3 offers strong read-after-write consistency for all PUT and DELETE operations. Workarounds built for eventual consistency are usually unnecessary today and can be removed.
What is the most common S3 security mistake?
Leaving a bucket or object public through a permissive bucket policy is the most common and most damaging error. Account-level Block Public Access and regular policy audits close this gap quickly.
Why is my S3 bill higher than expected?
The usual causes are aborted multipart uploads, data stored in the wrong storage class, retrieval fees from cold tiers, and unmonitored data transfer. Lifecycle rules, budgets, and access-pattern reviews usually bring costs back in line.
Do I need KMS encryption if S3 encrypts by default?
Only if your compliance framework requires customer-managed keys. Default SSE-S3 encryption covers most general workloads, while SSE-KMS adds key control and auditability at the cost of extra request charges.
