Amazon S3

AWS’s object storage, and the de facto API most object stores copy.

What it is: Object storage
Type: Managed service on AWS
Made by: Amazon Web Services
License: Proprietary
Facts checked: 5 October 2026

What it is

Amazon S3 stores objects (files plus metadata) in buckets, addressed by a key such as logs/2026/10/05/app.json. You read and write whole objects over HTTPS, and S3 scales to any number of objects without you provisioning capacity.

Amazon S3 stores objects in buckets and is designed for 99.999999999% (11 nines) durability in every storage class. The choice you make for each object is its storage class, which trades storage price against access cost, how quickly the first byte comes back, and how many Availability Zones hold a copy. Choose well and the same data costs a fraction as much. Choose badly and retrieval fees or minimum storage durations eat the savings.

Why teams pick it

Designed for 11 nines of durability, with no capacity planning
Storage classes and lifecycle rules make cold data very cheap
Its API is the standard: MinIO, Cloudflare R2, Google Cloud Storage and most data tools speak it

Watch out for

Objects are replaced whole; there’s no appending to or editing part of a file
Per-request fees add up for millions of tiny files
Data transfer out to the internet is billed, which can dominate costs for public downloads
A bucket isn’t a file system: “folders” are key prefixes, and renaming one copies every object under it. Mount it with S3 Files or Mountpoint when software needs files

Alternatives

What all object storage have in common →

Apache OpenDALOpen sourceA Rust library, with bindings for Python, Java, Node.js, Go and more, that gives one API (read, write, stat, list, delete) over 50-plus storage backends: S3 and other object stores, local and HDFS file systems, Google Drive and Dropbox, and key-value stores.

Apache OzoneOpen sourceA Hadoop-born object store that serves the same buckets over S3 and as a Hadoop file system.

Azure Blob StorageAzureAzure’s object storage, with three blob types and an optional real directory tree for analytics.

Backblaze B2 Cloud StorageCommercialLow-cost object storage on Backblaze’s own hardware, with its own API and an S3-compatible one.

CephOpen sourceA distributed storage cluster that serves S3 buckets, block devices and a file system from the same pool of disks.

Cloudflare R2CommercialS3-compatible object storage from Cloudflare that charges nothing for data going out.

GarageOpen sourceA lightweight S3 object store that keeps copies of your data in several sites linked by ordinary Internet connections.

Google Cloud StorageGoogle CloudGoogle Cloud’s object storage, where even the archive class answers in milliseconds.

MinIOArchivedOpen sourceA self-hosted object store that speaks the S3 API. The open-source edition is archived and its images are gone from Docker Hub; MinIO now sells AIStor.

PGSTY SiloOpen sourceA community-maintained fork of the open-source MinIO server, with builds, images, security fixes and the full web console.

RustFSOpen sourceA young Rust reimplementation of MinIO’s design: S3-compatible, erasure-coded, Apache 2.0, and generally available since September 2026.

SeaweedFSOpen sourceA distributed blob store with an S3 gateway and a file system layer, built to store and serve billions of small files.

TigrisCommercialGlobally distributed S3-compatible object storage that moves data to where it’s read, with no egress fees.

Versity S3 GatewayOpen sourceA stateless S3 server that exposes an existing file system, or another object store, through the S3 API.

Wasabi Hot Cloud StorageCommercialS3-compatible object storage sold at one flat price per TB, with no egress or request fees.Zenko CloudServerOpen sourceScality’s open-source Node.js S3 server: a light S3 endpoint for development and tests, and a front end that can store objects in other clouds.

How it fits with other technologies

What uses Amazon S3

Upload, list and fetch with the AWS CLI · bash

aws s3 cp report.parquet s3://acme-analytics/sales/2026/10/report.parquet
aws s3 ls s3://acme-analytics/sales/2026/10/
aws s3 presign s3://acme-analytics/sales/2026/10/report.parquet --expires-in 3600

A bucket is not a disk#

A disk (a physical SSD, or a block volume such as EBS) is just a long row of numbered blocks. It knows nothing about files. Ask it for block 81,920 and it returns 4 KB of bytes.

A file system such as ext4, NTFS or XFS is software that turns those blocks into named files inside folders. It tracks which blocks belong to which file, and gives you the operations programs expect: open a file, change bytes in the middle, append to the end, rename a folder in one step, lock a file, set permissions. A network file system (NFS or SMB, as in EFS) runs that software on a server and lets many machines mount the same folders.

An S3 bucket is neither. It is a flat map from keys to objects that you reach over HTTPS with a handful of calls: PUT a whole object, GET all or a byte range of one, LIST keys by prefix, DELETE. There is no file system inside it, so no operating system can mount it out of the box. The folders you see in the console are an illusion: the key photos/2026/a.jpg is one string that happens to contain slashes, and the console groups keys by the text before each /.

That difference is why “just put it on S3” sometimes fails: a program that opens a file and edits part of it, renames a temporary file into place, or takes a lock assumes a file system. To run it against a bucket, something has to translate file operations into S3 calls. That is what mounting S3 means.

Disk, file system or bucket?#

	Disk (block volume)	File system (ext4 on a disk, or EFS)	S3 bucket
What it stores	Numbered blocks of bytes	Named files in nested folders, built on blocks	Objects (bytes plus metadata) under keys
How you reach it	Attached to a machine as a device, e.g. `/dev/nvme1n1`	Mounted as a folder, e.g. `/data`	HTTPS API calls from anywhere with permission
Folders	None; it doesn’t know about files	Real directories	None; keys containing `/` that tools display as folders
Change bytes in the middle	Yes, any block	Yes	No; upload the whole object again
Append to the end	Yes	Yes	No (Express One Zone directory buckets can)
Rename a folder	Not applicable	One instant operation	Copy and delete every object under the prefix
Locks and permissions	Not applicable	File locks, owners, `chmod`	No locks; access is set by IAM and bucket policies
Who can use it at once	Usually one machine	One machine (ext4) or many (EFS, over NFS)	Any number of clients
Typical latency	Under a millisecond to a few milliseconds	Under a millisecond locally; a few over NFS	Tens of milliseconds per request

You never use a disk without a file system: formatting it with mkfs is the step that puts one on it. A bucket can’t be formatted, which is why mounting one needs a translator.

What mounting a bucket does#

Both apps read files from what looks like an ordinary folder. Underneath, each file operation becomes S3 requests.

Live modeldata or requestresponsebusy / idle instance

What you’re watchingMountpoint (top) turns every read into a GET to the bucket, so each one waits for S3. S3 Files (bottom) keeps recently used small files on its own fast storage, answers most reads there, and goes to the bucket only for the rest. Real S3 replies take tens of milliseconds; here they’re slowed down so you can see them.

Ways to put a file system on top of S3#

None of these changes the bucket itself. Each one runs a file system somewhere else and maps it onto objects. They differ in how much of a real file system you get, and where it runs.

Amazon S3 Files

AWS · NFS · since April 2026

A managed file system, built on EFS, linked to a bucket or prefix. EC2, Lambda, ECS and EKS mount it over NFS 4.1/4.2 and get edits, renames, locks and POSIX permissions. Hot small files live on fast storage; changes are written back to the bucket as new object versions.

Mountpoint for Amazon S3

AWS · open source · FUSE

A client you run on the machine (mount-s3). Fast for reading big files and writing new ones in one pass, but it deliberately doesn’t fake what S3 can’t do: no editing existing files, no renames (except on directory buckets), no locks or symlinks.

s3fs-fuse, rclone mount

open source · FUSE

Older general-purpose mounts that emulate more of a file system, for example by re-uploading a whole object when one byte changes. Convenient, but slow and surprising under heavy writes, and not safe for several writers.

JuiceFS

open source · own format

A full POSIX file system that keeps its metadata in a database (Redis, PostgreSQL, SQLite and others) and stores file contents as chunks in a bucket. Renames and locks are real, but the bucket holds JuiceFS chunks, not your files as readable objects.

S3 File Gateway

AWS · on-premises

A Storage Gateway appliance in your data centre that serves NFS or SMB shares to local machines and stores each file as an object in S3, with a local cache.

FSx for Lustre

AWS · HPC

A high-performance parallel file system for training and simulation jobs. It can be linked to a bucket, presenting its objects as files and exporting results back.

Directory buckets

S3 Express One Zone

Not a mount, but the closest S3 gets to a file system on its own: real directories, appending to objects, and an atomic RenameObject call. Single Availability Zone only.

What survives the translation#

The two AWS options take opposite approaches. Mountpoint is a thin, fast translator that refuses operations S3 can’t do directly. S3 Files is a real file system that syncs to the bucket in the background.

You try to	Mountpoint for S3	S3 Files
Read a file, or part of one	Yes	Yes; small hot files in about a millisecond
Write a new file	Yes, written once from start to end	Yes
Edit an existing file	No; only replace it whole, with `--allow-overwrite`	Yes; the bucket gets a new object version
Append	Only on Express One Zone, with `--incremental-upload`	Yes
Rename a file or folder	Only on directory buckets	Yes; instant on the mount, copied object by object in the bucket
Lock a file	No	Yes, advisory locks
`chmod`, `chown`, symlinks	No; permissions are fixed at mount time	Yes; stored as object metadata
See the change in the bucket	When the file is closed	After 60 seconds without writes to the file
Runs where	Any Linux machine with AWS credentials	Inside a VPC: EC2, Lambda, ECS, EKS

S3 Files requires versioning on the bucket. If a file changes in the bucket and on the mount at the same time, the bucket wins and your copy is moved to a lost-and-found folder.
Neither can read objects in Glacier Flexible Retrieval or Deep Archive until they are restored.
Renaming a folder with millions of objects through any mount is slow and costs one copy and one delete request per object, because the bucket itself has no folders.

Mount a bucket#

Mountpoint runs on the machine; S3 Files is created once, then mounted like any NFS share.

bash

# Mountpoint for Amazon S3: a client on this machine
mount-s3 my-bucket /mnt/s3

# S3 Files: create a file system linked to the bucket, then mount it
aws s3files create-file-system --bucket arn:aws:s3:::my-bucket \
  --role-arn arn:aws:iam::111122223333:role/S3FilesAccess
aws s3files create-mount-target --file-system-id fs-0a1b2c3d \
  --subnet-id subnet-0123abcd
sudo mount -t s3files fs-0a1b2c3d:/ /mnt/s3files

echo hello > /mnt/s3files/notes/today.txt   # appears as notes/today.txt in the bucket

Retrieval speed by class#

Each colour is a request for an object stored in a different class.

Live modeldata or requestresponsebusy / idle instance

What you’re watchingAn app reads four objects, each in a different storage class. Standard, Standard-IA and Glacier Instant Retrieval all answer in milliseconds; the last two charge per GB retrieved. The fourth object is in Glacier Deep Archive, so a restore job has to bring it back first. Real Standard restores take up to 12 hours; here they’re compressed to seconds.

Storage classes at a glance#

Class	Best for	First byte	Availability (designed)	Zones	Minimum duration	Minimum billed size	Retrieval fee
S3 Standard	Frequently accessed data	Milliseconds	99.99%	≥ 3	None	None	None
S3 Intelligent-Tiering	Unknown or changing access patterns	Milliseconds; opt-in archive tiers take minutes to hours	99.9%	≥ 3	None	None; objects under 128 KB aren’t tiered	None, plus a small monthly fee per monitored object
S3 Express One Zone	Latency-critical data next to your compute	Single-digit milliseconds	99.95%	1	1 hour	None	Per GB
S3 Standard-IA	Data read about once a month that must come back instantly	Milliseconds	99.9%	≥ 3	30 days	128 KB	Per GB
S3 One Zone-IA	Re-creatable data read about once a month	Milliseconds	99.5%	1	30 days	128 KB	Per GB
S3 Glacier Instant Retrieval	Archives read about once a quarter, instantly	Milliseconds	99.9%	≥ 3	90 days	128 KB	Per GB
S3 Glacier Flexible Retrieval	Backups and archives read about once a year	Minutes to hours, after a restore	99.99% once restored	≥ 3	90 days	+40 KB metadata per object	Per GB; bulk restores are free
S3 Glacier Deep Archive	Retention for years, read less than once a year	Hours, after a restore	99.99% once restored	≥ 3	180 days	+40 KB metadata per object	Per GB

Every class is designed for 11 nines of durability. The One Zone classes keep data in a single Availability Zone, so losing that zone can lose the data.
Minimum duration: if you delete, overwrite or transition an object sooner, you’re still billed for the full period.
Minimum billed size: smaller objects are billed as 128 KB. The two Glacier archive classes add 40 KB of metadata per object: 32 KB billed at the archive rate and 8 KB at the Standard rate.
Express One Zone stores data in directory buckets and doesn’t support lifecycle transitions.

Intelligent-Tiering, tier by tier#

Intelligent-Tiering moves each object between tiers based on when it was last read, and moves it back to Frequent Access when it’s read again. There are no retrieval fees.

Frequent Access

default

Where new objects start. Millisecond access.

Infrequent Access

after 30 days

Objects nobody has read for 30 consecutive days. Still millisecond access, at a lower storage price.

Archive Instant Access

after 90 days

Objects nobody has read for 90 consecutive days. Still millisecond access, and cheaper again.

Archive Access

opt-in · 90+ days

Optional, for data your application can wait for. Objects must be restored first, which takes minutes to hours.

Deep Archive Access

opt-in · 180+ days

Optional. Restores finish within 12 hours, as with Glacier Deep Archive.

Getting archived objects back#

Objects in Glacier Flexible Retrieval or Glacier Deep Archive, or in Intelligent-Tiering’s opt-in archive tiers, can’t be read directly. You first call RestoreObject, which makes a temporary readable copy, and choose how fast that should happen.

Stored in	Expedited	Standard	Bulk
Glacier Flexible Retrieval, or the Archive Access tier	1–5 minutes	3–5 hours	5–12 hours, free
Glacier Deep Archive, or the Deep Archive Access tier	Not available	Within 12 hours	Within 48 hours

Expedited times apply to objects under 250 MB, and Expedited requests may be turned away at busy times unless you buy provisioned capacity.
Standard retrievals are free for objects in Intelligent-Tiering.
Restore requests are limited to 1,000 per second per account. To restore millions of objects, use S3 Batch Operations.

Choosing a class#

Read often, or you don’t know

Standard · Intelligent-Tiering

Start in S3 Standard. If access patterns are unknown or change over time, Intelligent-Tiering finds the savings for you without retrieval fees.

Read about once a month

Standard-IA

Cheaper storage with a per-GB retrieval fee. Use One Zone-IA only for data you could re-create, such as replicas or derived files.

Read a few times a year, instantly

Glacier Instant Retrieval

Medical images, news archives, uploads from years ago: rarely read, but when they are, someone is waiting.

Read rarely, can wait hours

Glacier Flexible · Deep Archive

Backups, compliance archives and raw data kept for years. Deep Archive is S3’s cheapest class and an alternative to tape.

Latency is the bottleneck

Express One Zone

ML training, interactive analytics and other request-heavy jobs running in the same Availability Zone. AWS quotes up to 10x faster access than S3 Standard.

Lots of small objects

watch out

In the IA classes and Glacier Instant Retrieval, objects under 128 KB are billed as 128 KB, and Intelligent-Tiering doesn’t tier them. Bundle small files, or leave them in Standard.

Automate it with a lifecycle rule#

Lifecycle rules move objects to colder classes as they age and can delete them at the end. Save this as lifecycle.json and apply it with aws s3api put-bucket-lifecycle-configuration --bucket my-bucket --lifecycle-configuration file://lifecycle.json.

json

{
  "Rules": [
    {
      "ID": "age-out-logs",
      "Filter": { "Prefix": "logs/" },
      "Status": "Enabled",
      "Transitions": [
        { "Days": 30, "StorageClass": "STANDARD_IA" },
        { "Days": 90, "StorageClass": "GLACIER_IR" },
        { "Days": 365, "StorageClass": "DEEP_ARCHIVE" }
      ],
      "Expiration": { "Days": 2555 }
    }
  ]
}

Other features worth knowing#

Versioning

Keeps every version of an object, so an overwrite or delete can be undone. Pair it with a lifecycle rule that expires old versions.

Object Lock

Write once, read many: objects can’t be deleted or overwritten until a date you set. Used for compliance and ransomware protection.

Replication

Copies new objects to another bucket in the same or another Region, optionally into a cheaper storage class.

Strong consistency

Since December 2020, a read after a successful write or delete always sees the change, for every object in every Region.

Event notifications

Trigger a Lambda function, an SQS queue, an SNS topic or an EventBridge rule when objects are created or deleted.

S3 Tables

Table buckets that store Apache Iceberg tables and run compaction and snapshot clean-up for you, for a higher storage price plus per-object monitoring and compaction fees.

Very large objects

A single object can be up to 50 TB, raised from 5 TB in December 2025. Upload anything over about 100 MB in parallel parts with multipart upload.

The same idea at other providers#

Every major cloud offers hot-to-archive tiers. The names differ, and so do the details: Google’s Archive class is still readable in milliseconds, while Azure’s Archive tier must be rehydrated first.

Access pattern	AWS S3	Google Cloud Storage	Azure Blob Storage
Frequent	Standard	Standard	Hot
About monthly	Standard-IA (30-day minimum)	Nearline (30-day minimum)	Cool (30-day minimum)
About quarterly	Glacier Instant Retrieval (90 days)	Coldline (90 days)	Cold (90 days)
Yearly or less	Glacier Flexible Retrieval (90 days), Deep Archive (180 days)	Archive (365 days), readable in milliseconds	Archive (180 days), offline until rehydrated
Automatic tiering	Intelligent-Tiering	Autoclass	Lifecycle rules on last access time
A real file system view	S3 Files mount; directory buckets for real directories	Hierarchical namespace buckets; Cloud Storage FUSE to mount	Data Lake Storage hierarchical namespace; BlobFuse2 or NFS 3.0 to mount

See it in a real stack

Small lakehouse on DuckLake →

Live modeldata or requestresponsebusy / idle instance

Open in playground

What you’re watchingA nightly load writes new rows: DuckLake commits the snapshot to PostgreSQL and the data to S3 as Parquet. Analysts’ queries look up the current files in the catalog and read them from S3.

Open lakehouse on IcebergKafka streams events into Spark, which writes Iceberg tables on S3 that Trino queries for dashboards.Apache KafkaApache SparkApache IcebergAmazon S3Trino Serverless web app on AWSCloudFront serves the site from S3 and sends API calls through API Gateway to Lambda functions backed by DynamoDB.Amazon CloudFrontAmazon S3Amazon API GatewayAWS LambdaAmazon DynamoDB CQRS with a static read sideCommands update PostgreSQL; a Lambda projector rewrites the affected JSON views in S3, and CloudFront serves every read without touching a database.Amazon API GatewayAWS LambdaPostgreSQLAmazon SQSAmazon S3Amazon CloudFront Background jobs with a queueThe API drops slow work onto SQS and returns at once; a pool of Fargate workers drains the queue at a steady pace.AWS LambdaAmazon SQSAWS FargateAmazon S3 Code sandboxes for AI agentsAn agent’s code runs in a fresh Firecracker microVM per task, isolated by its own kernel, with outputs saved to S3.FirecrackerAmazon S3 IoT telemetry pipelineDevices stream readings into Kinesis; Lambda writes them to TimescaleDB for Grafana, and raw data is archived to S3.Amazon Kinesis Data StreamsAWS LambdaTimescaleDBAmazon S3Grafana

Worth exploring

Article· August 2023Using Kubernetes with AWS Lambda: Scaling Up Your Serverless ApplicationsRohit Ghumare, LumigoA vendor blog post whose concrete part is a walkthrough of creating a Lambda function from an EKS cluster with the AWS Controllers for Kubernetes (ACK) Lambda controller, closely following AWS’s own 2022 tutorial. The benefits section is vague and blurs what Kubernetes and Lambda each do, and the post ends with a pitch for Lumigo’s observability product.

Article· August 2022Deploying AWS Lambda functions using AWS Controllers for Kubernetes (ACK)Rajdeep Saha, AWS Compute BlogAWS’s step-by-step tutorial for managing Lambda functions as Kubernetes custom resources: install the ACK Lambda controller in EKS, give it IAM permissions through IRSA, then kubectl apply a Function manifest that points at code in S3. It explains why you might (one GitOps and RBAC model for pods and functions) but, being AWS’s own post, not the drawbacks.

Article· February 2021Alternative to AWS lambda serverless concept in Kubernetes?Stack Overflow question by ajsgA team running everything on Kubernetes asks how to get Lambda-style, per-request scaling for loading AI models from S3. The 2021 answers name Knative, KFServing (now KServe) and Kubeless (since archived), which makes it a quick snapshot of the options rather than an up-to-date guide.

All resources →

Where it came from2006–2026

In 2005 Amazon’s retail business had a storage problem of its own: product images, videos and other data that had to be kept cheaply and reliably at a scale that kept growing. Werner Vogels later wrote that “the majority of our data needed an object (or key-value) store”, and that the block and file storage on the market couldn’t offer low cost with high reliability.

AWS launched S3 on 14 March 2006 with a one-paragraph announcement. It stored objects of 1 byte to 5 GB under a key you chose, reached over REST or SOAP, for $0.15 per GB-month plus $0.20 per GB transferred, with no minimum fee. Behind it sat about 1 PB of capacity on roughly 400 storage nodes in 15 racks across three data centres. Its stated design principles were decentralization, asynchrony, autonomy and failure tolerance, so that no single machine could become a bottleneck or a single point of failure.

S3’s bucket-and-key HTTP API became the interface many other object stores copy. At its 20th birthday in March 2026 it held more than 500 trillion objects across hundreds of exabytes, served over 200 million requests a second and charged about 2 cents per GB. AWS says code written against it in 2006 still works unchanged.

Why it’s built this way

A flat key-value store over HTTP, not a file system: Most of Amazon’s own data was whole objects fetched by key. Leaving out directories, partial writes and locks let S3 spread data over many commodity machines and serve it to any program on the internet.
Cheap commodity hardware that expects failure: Building from commodity parts kept costs low, so the system was designed around machines failing: every object is stored in several places and no single node is in charge.
Availability first, strong consistency later: Caches in S3’s metadata layer kept it highly available but meant a read could, rarely, return stale data. In December 2020 a cache coherence protocol made every read see the latest write, at no extra cost.
Pay per GB, with no minimum: Billing only for what was stored and transferred meant a developer could start with one object and grow without buying capacity up front.

Timeline

2006
Launches on 14 March at $0.15 per GB-month; objects up to 5 GB
2012
Glacier launches for archives at $0.01 per GB-month (August)
2018
Intelligent-Tiering moves objects between tiers automatically
2020
Strong read-after-write consistency for every object, at no extra cost (December)
2023
Express One Zone offers single-digit millisecond latency
2025
Maximum object size rises from 5 TB to 50 TB (December)
2026
Turns 20 with 500+ trillion objects; S3 Files mounts buckets over NFS (April)

Sources49 · facts checked 5 October 2026

Improve this page on GitHub