Amazon S3: Classes, Versioning and Lifecycle

Amazon Simple Storage Service (S3) is AWS's object store and one of its oldest services. You put whole files in, give each one a key, and get them back over HTTPS. Backups, logs, images, static websites and data lakes all live in S3. This note covers how S3 is organized, which storage class to choose, and the features that protect and move your data. For object storage in general, see Block, File and Object Storage. For how apps use a blob store in a design, see the blob storage part of Core Databases.

Buckets, keys and objects#

S3 has two main parts: buckets and objects.

• A bucket is a container for objects. You create it in one Region, and its data stays in that Region unless you copy it out.
• A bucket name is globally unique across all AWS accounts, because the name appears in the bucket's URL. Once someone has a name, nobody else can use it.
• An object is the data plus metadata. It is stored under a key, such as invoices/2026/10/inv-1001.pdf.
• One object can be up to 5 TB. Upload large files in parts with multipart upload.
• Total storage in a bucket has no practical limit.
• The bucket and its objects have settings such as permissions, versioning and default encryption.

The key invoices/2026/10/inv-1001.pdf looks like a path, but S3 has a flat namespace. The console shows "folders" by splitting keys on /. These are only shared prefixes.

You work with objects through the REST API, the SDKs or the CLI:

aws s3 cp report.pdf s3://example-bucket/reports/report.pdf
aws s3 ls s3://example-bucket/reports/

S3 gives strong read-after-write consistency. After a successful write or delete, the next read or list returns the new state.

Durability vs availability#

S3's reliability numbers come in two kinds, and people often mix them up. They measure different things.

• Durability is the chance that a stored object is not lost. Most S3 classes are designed for 99.999999999% (11 nines) durability, because S3 stores copies across several devices and, for most classes, several AZs.
• Availability is the share of time you can reach the object. It varies by class, for example 99.99% for S3 Standard and lower for the infrequent-access classes.

An object can be fully durable but briefly unreachable. One Zone-IA is a special case: its data lives in one AZ, so if that AZ is destroyed, the data is lost.

Storage classes#

Durability and availability vary by storage class, which is the main choice you make per object. Each object has a storage class, and you trade storage price against retrieval price, retrieval speed and resilience.

A few rules apply to the cheaper classes:

• The IA and Glacier classes have a minimum storage duration and some have a minimum billable object size. Deleting early still costs the minimum.
• For Glacier Flexible Retrieval and Deep Archive, the object is not readable until you restore it. A restore makes a temporary copy, and you choose a speed tier. Faster tiers cost more.
• Intelligent-Tiering moves each object between access tiers based on how often it is read. It charges a small monitoring fee per object and no retrieval fees.
• S3 Express One Zone is a high-performance class in one AZ, for workloads that need the lowest latency.

Reduced Redundancy Storage (RRS) was an early class with lower durability. It is deprecated; do not use it.

Versioning#

Storage classes control cost. The next few features protect your data, starting with accidental overwrites. Versioning keeps every version of an object in the bucket. It is off by default.

To undo a delete, remove the delete marker, and the previous version becomes current again. To delete data for good, delete a specific version ID.

Once you turn versioning on, you can suspend it but never fully turn it off. Every version is billed as storage, so pair versioning with lifecycle rules that expire old versions.

Lifecycle rules#

Lifecycle rules are how you keep versioning and storage classes from getting expensive. A lifecycle configuration tells S3 to act on objects as they age. A rule can apply to the whole bucket or only to objects with a key prefix or a tag.

• Transition objects to a cheaper class, for example to Standard-IA after 30 days and to Glacier Flexible Retrieval after 90 days.
• Expire (delete) objects after a set time.
• Expire noncurrent versions a set number of days after a newer version replaces them.
• Abort incomplete multipart uploads, whose parts otherwise keep costing money.

You can turn a rule off without deleting it. Here is a rule for log files that moves them to cheaper classes as they age, then deletes them after a year:

{
  "Rules": [
    {
      "ID": "archive-logs",
      "Filter": { "Prefix": "logs/" },
      "Status": "Enabled",
      "Transitions": [
        { "Days": 30, "StorageClass": "STANDARD_IA" },
        { "Days": 90, "StorageClass": "GLACIER" }
      ],
      "Expiration": { "Days": 365 }
    }
  ]
}

In the API, GLACIER is the name for Glacier Flexible Retrieval. Object tags (key-value pairs on each object) can also drive lifecycle rules, IAM policies and storage metrics.

Encryption#

S3 encrypts every new object at rest by default. You choose who manages the key.

You can also encrypt data yourself before upload (client-side encryption). For data in transit, use HTTPS endpoints. A bucket policy can deny any request not made over TLS.

Replication#

Versioning protects data inside one bucket, which still lives in one Region. Replication copies objects to another bucket automatically and asynchronously.

• Cross-Region Replication (CRR) copies to a bucket in another Region, for disaster recovery or lower latency elsewhere.
• Same-Region Replication (SRR) copies within one Region, for example to gather logs into one account.
• Both buckets must have versioning on.
• New writes after you set up the rule are replicated. Copy existing objects with S3 Batch Replication.
• Delete markers are replicated only if you turn that option on. Deleting a specific version is not replicated, which protects the copy from malicious deletes.

Event notifications#

Replication reacts to changes automatically. If your own code needs to react, S3 can send a message when something happens in a bucket. Events include object created (any upload or copy), object removed, restore completed, replication events and lifecycle events. Destinations are SNS topics, SQS queues, Lambda functions and Amazon EventBridge.

For example, an upload to uploads/ can trigger a Lambda function that makes a thumbnail. Notifications are delivered at least once, so make the handler safe to run twice.

Logging#

Notifications tell your code what changed; logs tell you who did it. Server access logging writes a record of each request to a bucket you choose: who made the request, what action, which object, and when. Use it for security audits and usage analysis. CloudTrail data events give a similar record for API calls.

What S3 is not#

Because S3 is so flexible, teams sometimes stretch it into roles it doesn't fit. It is an object store, not a file system or a database.

• Not a file system. It has a flat namespace and no POSIX semantics. You cannot append to an object or lock it, and renaming a "folder" means copying every object under the prefix. If you need a shared file system, use Amazon EFS.
• Not a database. You fetch objects by bucket and key. There is no query by content. Keep an index of keys and metadata in a database such as DynamoDB or RDS. For analytics, Amazon Athena can run SQL over files stored in S3.

Key takeaways#

• Objects live in buckets under keys. Bucket names are globally unique, objects go up to 5 TB, and the namespace is flat.
• Durability (not losing data) and availability (reaching it now) are different. Most classes give 11 nines of durability; availability varies.
• Choose a storage class by access pattern. The Glacier Flexible Retrieval and Deep Archive classes need a restore before you can read.
• Versioning keeps old versions and turns deletes into delete markers. Pair it with lifecycle rules to control cost.
• New objects are encrypted with SSE-S3 by default. Use SSE-KMS for key control and audit.
• Replication is asynchronous and needs versioning on both buckets.