S3 doesn’t just store files: it can also preserve the change history of each file and automatically manage what to do with them as time passes. These two features—versioning and lifecycle—protect you from mistakes and save you money effortlessly. Let’s take a look.

Versioning means that every time you upload an object with the same key, S3 does not overwrite the previous one, but instead saves a new version and keeps the old ones.

Analogy: It’s like the version history of a Google Docs or Word document. You can go back to a previous version if you make a mistake. Nothing is lost forever.

How it works:

At any time, you can retrieve an old version or restore it as the current one.

Why it’s so useful:

• Protects against accidental deletions: if someone deletes an object, S3 actually adds a “delete marker,” but the versions are still there and you can recover them.
• Protects against accidental overwrites: Did you upload the wrong file over the good one? Just go back to the previous version.
• It’s a defense against ransomware: if an attacker encrypts your files, the previous (unencrypted) versions are still available.

Real example: An employee accidentally overwrites the production configuration file with a bad one and the website stops working. Thanks to versioning, the team restores the previous version in seconds and everything goes back to normal. Without versioning, they would have lost the good file.

⚠️ Watch out for cost: each version takes up space and costs money. If you version files that change a lot, you could end up storing lots of old versions. That’s why versioning is combined with lifecycle to automatically delete old versions.

Important detail: once you enable versioning on a bucket, you can suspend it but not fully disable it. Keep this in mind before enabling it.

Lifecycle rules tell S3 what to do with objects based on their age, automatically. They serve two purposes:

1. Transition: move objects to cheaper storage classes over time (remember the classes from subchapter 5.2).
2. Expiration: delete objects (or old versions) when they’re no longer needed.

Analogy: It’s like an assistant who automatically organizes your storage room: “what hasn’t been touched in 30 days goes in the drawer; after 90 days, into the basement boxes; after 7 years, to the trash.”

A typical policy for logs might be:

With this rule, you don’t have to move or delete anything by hand. The objects “age” and their cost drops automatically, and they’re deleted when the law no longer requires you to keep them.

Lifecycle also manages the old versions generated by versioning. For example:

“Always keep the current version, but delete versions older than 90 days.”

This way you get the protection of versioning without the cost skyrocketing from keeping old versions forever. This combination—versioning + lifecycle for old versions—is a very common best practice.

These two features complement each other:

Recommended best practice: enable versioning on buckets with important data and add a lifecycle rule that cleans up old versions after a reasonable time. This way you’re protected without overpaying.

• Versioning preserves the history of each object: it protects against accidental deletions and overwrites (and against ransomware). Each version takes up space and costs money.
• Once enabled, versioning can be suspended but not fully removed.
• Lifecycle automates the fate of objects: transition to cheaper classes and expiration (deletion) based on their age.
• Lifecycle also cleans up old versions, preventing versioning from driving up costs.
• Versioning + lifecycle is the ideal combination: protection with controlled cost.

In the next subchapter, we’ll dive into a critical topic: S3 security with bucket policies and ACLs, to control who can access your data.