Amazon S3 (Simple Storage Service) is typically the first AWS service most engineers encounter when they begin working with cloud infrastructure. It is deceptively simple on the surface, but has considerable depth once access control, storage tiering, and cost optimization enter the picture. This post covers the core S3 concepts I worked through, supported by a short hands-on lab.
Topics Covered
- Buckets
- Objects
- Uploading files
- Storage classes
- Bucket policies
- ACLs and permissions
1. Buckets
A bucket is the top-level container in S3 — the root under which every object is stored. Bucket names must be globally unique across all of AWS, not just within a single account, which is why they often follow a pattern like firstbucket-<account-id>-<region>.
Each bucket is also tied to a specific region at creation time (e.g., eu-north-1, Stockholm). This choice affects latency, cost, and data residency, since the underlying data physically resides in that region's data centers.
For this lab, I created a bucket named firstbucket-605365943139-eu-north-1-an. Immediately after creation, it was empty — zero objects — and ready to receive uploads.
2. Objects
Everything you store inside a bucket — images, videos, documents, backups, logs — is called an object. Each object consists of:
- The data itself (the file)
- A key (essentially its full path/name inside the bucket)
- Metadata (content type, size, last modified date, etc.)
There's no real folder structure in S3 under the hood — folders are a UI convenience. What actually exists is a flat namespace of keys, and prefixes (like images/photo.jpg) just simulate folder hierarchy.
3. Uploading
Uploading is the process of adding an object to a bucket. In the AWS console, this is a straightforward Upload action, though the same operation is typically automated through the CLI or an SDK in production systems.
For this lab, I uploaded two JPEG images directly into the bucket. Once uploaded, S3 surfaces key metadata for each object — type, size, last modified timestamp, and storage class:
| Name | Type | Size | Storage Class |
|---|---|---|---|
| WhatsApp Image ...11.01.41 PM.jpg | jpeg | 201.5 KB | Standard |
| WhatsApp Image ...11.17.02 PM.jpeg | jpeg | 123.0 KB | Standard |
4. Storage Classes
Not all data needs to be instantly available all the time, and S3 gives you multiple storage classes to balance cost vs. retrieval speed:
- S3 Standard — frequently accessed data, highest availability, most expensive.
- S3 Intelligent-Tiering — automatically moves objects between tiers based on access patterns.
- S3 Standard-IA / One Zone-IA — infrequently accessed data, cheaper storage but a retrieval fee.
- S3 Glacier / Glacier Deep Archive — long-term archival, very cheap storage, but retrieval can take minutes to hours.
By default, newly uploaded objects land in Standard, which is exactly what I saw in the lab. Picking the right class for the right data is one of the easiest ways to cut cloud storage costs.
5. Bucket Policies
A bucket policy is a JSON document attached to the bucket itself that defines who can do what — for example, allowing public read access to a bucket used for a static website, or restricting access to specific IAM roles or AWS accounts.
Because a bucket policy applies at the bucket level, it's the go-to tool when you want a single, centralized rule for everything inside that bucket (e.g., "only this Lambda function's role can write objects here").
6. ACLs and Permissions
Access Control Lists (ACLs) are an older, more granular way to control access — at the level of individual buckets or individual objects. They predate bucket policies and IAM, and AWS now recommends disabling ACLs in favor of bucket policies and IAM policies for most use cases, since ACLs can get messy to manage at scale.
Broadly, S3 access boils down to three tools working together:
- IAM policies — control what an AWS identity (user/role) can do across services.
- Bucket policies — control access to a specific bucket.
- ACLs — legacy, fine-grained access on buckets/objects (mostly discouraged today).
Understanding how these layers interact — and that they're evaluated together, not in isolation — is one of the more important "aha" moments when learning S3.
Summary
This lab was intentionally small in scope, but it establishes the core mental model required before working with S3 in more advanced contexts — static website hosting, data lake architectures, or backend integrations. The next step in this learning path is exploring IAM in more depth and integrating S3 into a Spring Boot application.
If you're working through AWS fundamentals as well, I'd be interested to hear which concept took longest to click. For me, it was distinguishing bucket policies, ACLs, and IAM policies — three mechanisms that all govern access, but at different layers and with different intended use cases.
Top comments (0)