What is Amazon S3?

Amazon S3 (Simple Storage Service) is AWS’s service for storing files in the cloud. You hand S3 a file, S3 keeps a safe, redundant copy, and hands it back whenever you ask for it over the internet. It is one of the oldest and most widely used AWS services because it is cheap, almost infinitely large, and extremely reliable, which makes it the default home for backups, application uploads, logs, data lakes, and the files behind static websites.

S3 is object storage, not a filesystem

The single most important thing to understand about S3 is what kind of storage it is. There are three broad families:

Block storage — raw disk volumes you attach to a server (like Amazon EBS). Your operating system formats it and treats it like a hard drive.
File storage — a shared network filesystem with folders you can mount on many machines at once (like Amazon EFS).
Object storage — what S3 is. You store whole files as self-contained “objects,” each identified by a unique key, accessed through an API (Application Programming Interface, a defined way for programs to talk to a service) over HTTPS.

In S3 you do not get a drive letter or a mount point. You cannot run a database on it, you cannot edit the middle of a file in place, and you cannot open it like C:\ or /mnt/data. Instead you PUT an object to upload it and GET it to download it. This trade-off is exactly why S3 can scale so far: by giving up filesystem semantics, it gains effectively unlimited capacity and very high durability.

Buckets and objects

S3 has just two core concepts:

A bucket is a top-level container for your data. Bucket names are globally unique across all of AWS (no two customers can have a bucket called my-bucket), and a bucket lives in one AWS Region.
An object is a single stored file plus its metadata. Every object has a key (its name, e.g. reports/2026/q2.pdf), the data itself, and metadata such as content type.

The slashes in a key like reports/2026/q2.pdf look like folders, but S3 has no real directories. The whole string is just the object’s key. The console shows you folders for convenience, but it is a flat key namespace underneath.

Durability and scale

S3 Standard is designed for eleven nines of durability — 99.999999999%. In plain terms, if you store ten million objects, you would statistically expect to lose one object roughly once every ten thousand years. S3 achieves this by automatically storing copies of your data across multiple physically separate data centers (Availability Zones) within a Region.

Scale is effectively unlimited. A single object can be up to 5 TB, a single bucket can hold an unlimited number of objects, and you never provision capacity in advance — you pay only for what you actually store.

S3 now gives you strong read-after-write consistency automatically and at no extra cost. When a PUT succeeds, an immediate GET of that key returns the new data. The old “eventual consistency” surprises from years ago are gone, so you no longer need to design around them.

Common uses

Use case	Why S3 fits
Backups and archives	Cheap, durable, with lifecycle rules to move cold data to Glacier.
Data lakes / analytics	Store raw and processed data; query directly with Athena or load into Redshift.
Application file uploads	User photos, documents, exports — served via presigned URLs or CloudFront.
Static website hosting	Serve HTML, CSS, JS, and images directly from a bucket.
Log storage	CloudFront, ELB, and VPC flow logs all deliver to S3.

When to use S3 (and when not to)

Use S3 when you need to store and retrieve whole files, share data across services, host static assets, or keep durable backups, and you access objects as complete units.

Do not use S3 when you need a mountable disk for an operating system (use EBS), a shared POSIX filesystem several servers write to concurrently (use EFS), or a place to run a database or do frequent small in-place edits. To change one byte of an S3 object you must upload the entire object again.

Creating a bucket and storing an object

AWS Management Console

Sign in and open the S3 console.
Click Create bucket.
Enter a globally unique Bucket name (e.g. devcraftly-demo-2026) and choose a Region.
Leave Block all public access enabled (the safe default).
Click Create bucket.
Open the bucket, click Upload, add a file, and click Upload again.

AWS CLI

Create a bucket, upload an object, then download it. These commands use AWS CLI v2.

# Create a bucket in us-east-1
aws s3 mb s3://devcraftly-demo-2026 --region us-east-1

# Upload a local file as an object
aws s3 cp ./report.pdf s3://devcraftly-demo-2026/reports/2026/q2.pdf

# List the objects in the bucket
aws s3 ls s3://devcraftly-demo-2026/reports/2026/

# Download the object back
aws s3 cp s3://devcraftly-demo-2026/reports/2026/q2.pdf ./downloaded.pdf

Output:

make_bucket: devcraftly-demo-2026
upload: ./report.pdf to s3://devcraftly-demo-2026/reports/2026/q2.pdf
2026-06-15 10:42:18    104857 q2.pdf
download: s3://devcraftly-demo-2026/reports/2026/q2.pdf to ./downloaded.pdf

You can also define a bucket in infrastructure-as-code so it is repeatable and version-controlled. Here is a minimal CloudFormation template:

Resources:
  DemoBucket:
    Type: AWS::S3::Bucket
    Properties:
      BucketName: devcraftly-demo-2026
      PublicAccessBlockConfiguration:
        BlockPublicAcls: true
        BlockPublicPolicy: true
        IgnorePublicAcls: true
        RestrictPublicBuckets: true

Cost note

For S3 Standard in most US Regions you pay roughly $0.023 per GB per month for storage, plus small per-request fees (about $0.005 per 1,000 PUT/LIST requests and $0.0004 per 1,000 GET requests). Storing 100 GB costs around $2.30/month. The fee that surprises people is data transfer out to the internet (around $0.09 per GB after the free tier) — moving data out often costs more than storing it, so front high-traffic buckets with CloudFront and keep data and compute in the same Region.

Best Practices

Keep Block Public Access turned on unless you have a deliberate reason to serve content publicly, and grant access with bucket policies and IAM rather than ACLs.
Enable default encryption (SSE-S3 or SSE-KMS) so every object is encrypted at rest.
Turn on versioning on buckets holding important data to recover from accidental overwrites and deletes.
Use lifecycle rules to transition cold data to cheaper classes (Glacier) and expire old objects automatically.
Choose a Region close to your users or compute to cut latency and transfer cost.
Use presigned URLs to grant temporary, scoped access instead of making objects public.