What is Amazon S3 and what are its storage classes?
S3 is AWS's object storage. You store files as objects inside buckets and access them by key over HTTPS. Storage classes trade storage cost against access speed and retrieval cost, from S3 Standard for frequently used data to the Glacier classes for archives you rarely read.
Explain it simply
Think of S3 as a huge locker room. A bucket is your locker, with a name nobody else in the world can use. Inside, you keep objects: any file, from a profile photo to a 2 GB video, each with a label called a key, like resumes/2026/riya.pdf.
You do not "open" S3 like a hard disk. You put a whole file in, and you get a whole file out, usually over an HTTPS API call. That is why it is called object storage, not file storage or block storage.
Storage classes are like choosing where to keep things at home. Daily-use items stay on the table (expensive space, instant access). Old exam papers go to the loft (cheap space, but you need a ladder and time to get them down).
Example
A placement portal stores resumes:
Bucket: placement-portal-resumes
resumes/2026/riya.pdf -> S3 Standard (read often this season)
resumes/2024/old-batch.zip -> S3 Glacier Deep Archive (kept for records)
Lifecycle rule:
after 30 days -> move to S3 Standard-IA
after 365 days -> move to S3 Glacier Flexible RetrievalA lifecycle rule moves objects to cheaper classes automatically as they age, so nobody has to do it by hand.
How it works
- Buckets belong to one AWS Region. Bucket names are globally unique.
- Objects can be up to 5 TB each. A key can contain slashes, which the console shows like folders, but S3 itself is flat.
- Durability: S3 is designed for 99.999999999% (eleven nines) durability by storing data redundantly across devices and, for most classes, across multiple Availability Zones.
- Consistency: after a successful write, a read of that object returns the new data (strong read-after-write consistency).
- Access: private by default. You grant access with IAM policies, bucket policies and short-lived pre-signed URLs.
Storage classes at a high level
| Class | Use it for |
|---|---|
| S3 Standard | Frequently accessed data, websites, app files |
| S3 Intelligent-Tiering | Unknown or changing access patterns; S3 moves data between tiers for you |
| S3 Standard-IA | Infrequent access but must be available quickly |
| S3 One Zone-IA | Infrequent, easy-to-recreate data stored in a single AZ |
| S3 Glacier Instant Retrieval | Archives that are rarely read but need millisecond access |
| S3 Glacier Flexible Retrieval | Archives where waiting minutes to hours is fine |
| S3 Glacier Deep Archive | Long-term records read maybe once a year; retrieval takes hours |
The colder the class, the cheaper the storage, but the more you pay (in money or time) to read it back. Some infrequent and archive classes also have a minimum storage duration.
Real-world use
- Storing user uploads such as profile photos, resumes and certificates.
- Hosting a static website or the build files of a React app, usually behind CloudFront.
- Backups and database exports, moved to Glacier with lifecycle rules.
- A data lake: logs and event data that analytics tools such as Athena query in place.
Common mistakes
- Making a bucket public to "fix" an access error. Use pre-signed URLs or CloudFront instead and keep Block Public Access on.
- Treating S3 like a disk you can edit in place. To change part of an object, you upload the whole object again.
- Putting frequently read data in Glacier to save money and then paying more in retrieval charges and waiting hours.
- Forgetting versioning, so an accidental delete or overwrite cannot be undone.
What to say in the interview
"S3 is object storage. I create a bucket in a region and store objects by key; each object can be up to 5 TB, and S3 is designed for eleven nines of durability. It is private by default, and I control access with IAM and bucket policies or pre-signed URLs. Storage classes trade storage cost against retrieval cost and speed: Standard for hot data, Standard-IA or One Zone-IA for infrequent access, Intelligent-Tiering when I don't know the pattern, and the Glacier classes for archives. I'd use lifecycle rules to move old data to cheaper classes automatically."
Follow-up questions
- What is a pre-signed URL and when would you use one?
- How does S3 versioning protect you from accidental deletes?
- What is the difference between S3, EBS and EFS?
- How would you serve images from S3 fast to users across India?
Go deeper
Read these once the basics above feel easy.
For large uploads, use multipart upload: the file is split into parts that upload in parallel and can be retried individually. Let browsers upload directly to S3 with a pre-signed URL so big files never pass through your own server. Enable server-side encryption (it is on by default for new objects) and use bucket policies to require HTTPS.
Design keys and prefixes with access patterns in mind, since S3 scales request throughput per prefix. Use event notifications to trigger Lambda or put messages on SQS when objects arrive. For compliance, Object Lock can make objects write-once-read-many for a retention period, and replication (same-region or cross-region) keeps copies in another bucket.