Amazon S3 Explained: Going Beyond the Basics — Part 2
In this follow-up to my previous S3 article, I dive deeper into Amazon S3’s storage classes, lifecycle rules, versioning, security, replication, and real-world use cases. This article focuses on understanding not just what these features do, but when and why we would use them in a real AWS architecture.
In my previous article, I covered the fundamentals of Amazon S3, including buckets, objects, bucket policies, versioning, replication, and storage classes.
After publishing it, someone asked me to elaborate more on the concepts and explain them in greater detail.
So, here is a follow-up article focusing on how Amazon S3 actually works in real-world scenarios and how its major features fit together.
1. What Actually Happens When You Upload a File to S3?
When you upload a file to Amazon S3, it becomes an object.
An object consists mainly of:
The actual data (your file)
An object key (its name/path)
Metadata
Optional tags
For example, suppose we have:
my-website/images/logo.png
Here:
my-website → S3 bucket
images/logo.png → object key
The image itself → object data
One important thing to understand is that S3 doesn't actually have traditional folders like a normal file system.
What looks like a folder structure is essentially part of the object's key.
For example:
images/2026/profile.jpg
is simply an object whose key is images/2026/profile.jpg.
This becomes especially useful when working with large amounts of data because S3 is designed around objects rather than traditional file-system directories.
2. Why Is S3 So Scalable?
One of the reasons S3 is so popular is that you don't have to manually manage storage capacity.
With a traditional server, you might have to think about:
"How much disk space do I need?"
With S3, you can upload data as your requirements grow.
For example, imagine a website that initially stores 10 GB of images.
Over time:
10 GB → 100 GB → 1 TB → 10 TB
You don't have to manually add another hard drive every time your storage requirements increase.
AWS handles the underlying infrastructure and scaling.
This makes S3 particularly useful for:
Websites
Backup systems
Data lakes
Application files
Logs
Media storage
Machine learning datasets
3. S3 Storage Classes — Choosing the Right One
One of the most important S3 concepts is storage classes.
Not every file needs to be accessed frequently.
For example, imagine a company storing:
Website images → accessed constantly
Monthly reports → accessed occasionally
Old backups → rarely accessed
Archived records → almost never accessed
Putting everything into the same storage class wouldn't necessarily be cost-efficient.
That's where different S3 storage classes become useful.
S3 Standard
Designed for frequently accessed data.
Examples:
Website assets
Application files
Frequently accessed images
S3 Standard-IA
IA means Infrequent Access.
This can be useful when data is stored for a long time but isn't accessed very often.
Example:
A company's monthly reports that are rarely opened but still need to remain immediately available.
S3 One Zone-IA
Similar to Infrequent Access storage, but data is stored in a single Availability Zone.
This can be useful for certain data that can be recreated if necessary.
S3 Glacier Classes
These are designed for archival and long-term storage.
For example:
A company might need to retain old records for several years but almost never access them.
Instead of paying for high-performance storage, archival storage can be used.
4. S3 Lifecycle Rules
This is where S3 becomes even more interesting.
Instead of manually moving objects between storage classes, we can create Lifecycle Rules.
For example:
Day 0 → S3 Standard
After 30 days → Standard-IA
After 90 days → Glacier
After several years → Delete
This means S3 can automatically manage the lifecycle of our data.
Imagine a company storing application logs.
They might need recent logs frequently, but older logs become less useful over time.
A lifecycle policy can automatically move those logs to cheaper storage as they age.
This can reduce storage costs without requiring someone to manually manage thousands or millions of objects.
5. S3 Versioning
Versioning is another feature that I found particularly useful while learning S3.
Suppose we have:
report.pdf
and accidentally upload a new version that overwrites the previous one.
With versioning enabled, S3 can retain previous versions of the object.
So instead of simply having:
report.pdf
we can have multiple versions of that object stored by S3.
This can help protect against:
Accidental deletion
Accidental overwrites
Application mistakes
Unwanted modifications
However, there is an important point:
Versioning can increase storage usage and therefore increase costs.
That's why lifecycle rules can also be useful with versioning — for example, automatically deleting older versions after a certain period.
6. S3 Bucket Policies vs IAM Policies
This was another concept that initially required some attention.
Both IAM policies and S3 bucket policies can control access, but they are not exactly the same.
IAM Policy
An IAM policy is attached to an identity such as:
IAM user
IAM group
IAM role
It defines what that identity is allowed to do.
Bucket Policy
A bucket policy is attached directly to an S3 bucket.
It can define who can access the bucket and what actions they can perform.
For example, a bucket policy could allow a specific AWS service or account to access objects in the bucket.
A simple way to remember it:
IAM policy → permissions for an identity
Bucket policy → permissions defined at the bucket level
Understanding this distinction becomes especially important when troubleshooting S3 access issues.
7. Block Public Access
S3 also has a very important security feature called Block Public Access.
By default, AWS strongly encourages keeping S3 buckets private unless there is a specific reason to make data public.
This is extremely important because accidentally exposing an S3 bucket can result in sensitive information becoming publicly accessible.
For example, you wouldn't want a bucket containing:
Customer information
Application backups
Internal documents
Database exports
to accidentally become publicly readable.
Therefore, when working with S3, it's important to always ask:
Who actually needs access to this data?
Then grant only the permissions that are required.
This follows the principle of least privilege.
8. S3 Static Website Hosting
One of the interesting things about S3 is that it can also be used to host static websites.
For example, a website containing:
HTML
CSS
JavaScript
Images
can be stored in an S3 bucket.
S3 can then serve these static files to users.
This is particularly useful for simple static websites because you don't necessarily need to maintain a traditional web server just to serve static content.
For more advanced architectures, S3 can also work together with services such as Amazon CloudFront to deliver content efficiently through a CDN.
9. S3 Replication
What happens if we need our data to exist in another AWS Region?
That's where S3 Replication can help.
For example:
Bucket A → Mumbai Region
can replicate objects to:
Bucket B → Singapore Region
This can be useful for:
Disaster recovery
Compliance requirements
Geographic redundancy
Lower-latency access in different regions
There are different replication approaches depending on the architecture and requirements.
The important idea is:
S3 doesn't have to keep your data in only one location.
10. S3 and Data Lakes
S3 isn't only useful for storing individual files.
It is also a major building block for data lakes.
A company might collect:
Application logs
Customer data
Transaction data
IoT data
Analytics data
Machine learning datasets
and store huge amounts of this information in S3.
Other AWS services can then process and analyze that data.
This makes S3 an important part of many modern cloud architectures.
11. A Simple Real-World Example
Let's imagine we're building an e-commerce application.
Our application receives thousands of product images.
Instead of storing all those images directly on the application server, we could store them in S3.
The architecture could look something like:
User → Application → S3 → Product Image
We could then use:
S3 Standard for frequently accessed images
CloudFront for faster global delivery
Versioning to protect against accidental overwrites
Lifecycle rules to manage old files
Bucket policies/IAM for access control
Replication for additional resilience
Suddenly, S3 isn't just "cloud storage."
It becomes an important component of the application's architecture.
12. What I Took Away From Learning S3
While learning S3, one of the biggest things I realized is that the service is much more than simply uploading files to the cloud.
The important part is understanding why each feature exists.
For example:
Storage Classes → Optimize storage costs
Lifecycle Rules → Automatically manage data over time
Versioning → Protect against accidental changes
Bucket Policies/IAM → Control access
Replication → Improve resilience and meet geographic requirements
Static Website Hosting → Serve static web content
Data Lakes → Store and analyze massive datasets
Once these concepts start connecting, S3 becomes much easier to understand.
Final Thoughts
S3 is one of those AWS services that looks simple at first:
"It's just cloud storage."
But once you start exploring its security, scalability, storage classes, lifecycle management, versioning, replication, and integration with other AWS services, you realize how powerful it actually is.
I'm currently continuing my preparation for the AWS Certified Solutions Architect – Associate certification, and learning S3 has helped me understand several cloud architecture concepts more clearly.
If you're also preparing for an AWS certification, I would recommend not just memorizing what each S3 feature does.
Try to understand:
"Why would I use this feature in a real architecture?"
That shift in thinking makes AWS concepts much easier to remember.
This is Part 2 of my Amazon S3 learning series. If there is a particular S3 concept you'd like me to dive deeper into, feel free to mention it in the comments!
This one should work nicely as the follow-up to the comment because it explicitly acknowledges the request and goes deeper instead of repeating the first article.
After publishing it, someone asked me to elaborate more on the concepts and explain them in greater detail.
So, here is a follow-up article focusing on how Amazon S3 actually works in real-world scenarios and how its major features fit together.
1. What Actually Happens When You Upload a File to S3?
When you upload a file to Amazon S3, it becomes an object.
An object consists mainly of:
The actual data (your file)
An object key (its name/path)
Metadata
Optional tags
For example, suppose we have:
my-website/images/logo.png
Here:
my-website → S3 bucket
images/logo.png → object key
The image itself → object data
One important thing to understand is that S3 doesn't actually have traditional folders like a normal file system.
What looks like a folder structure is essentially part of the object's key.
For example:
images/2026/profile.jpg
is simply an object whose key is images/2026/profile.jpg.
This becomes especially useful when working with large amounts of data because S3 is designed around objects rather than traditional file-system directories.
2. Why Is S3 So Scalable?
One of the reasons S3 is so popular is that you don't have to manually manage storage capacity.
With a traditional server, you might have to think about:
"How much disk space do I need?"
With S3, you can upload data as your requirements grow.
For example, imagine a website that initially stores 10 GB of images.
Over time:
10 GB → 100 GB → 1 TB → 10 TB
You don't have to manually add another hard drive every time your storage requirements increase.
AWS handles the underlying infrastructure and scaling.
This makes S3 particularly useful for:
Websites
Backup systems
Data lakes
Application files
Logs
Media storage
Machine learning datasets
3. S3 Storage Classes — Choosing the Right One
One of the most important S3 concepts is storage classes.
Not every file needs to be accessed frequently.
For example, imagine a company storing:
Website images → accessed constantly
Monthly reports → accessed occasionally
Old backups → rarely accessed
Archived records → almost never accessed
Putting everything into the same storage class wouldn't necessarily be cost-efficient.
That's where different S3 storage classes become useful.
S3 Standard
Designed for frequently accessed data.
Examples:
Website assets
Application files
Frequently accessed images
S3 Standard-IA
IA means Infrequent Access.
This can be useful when data is stored for a long time but isn't accessed very often.
Example:
A company's monthly reports that are rarely opened but still need to remain immediately available.
S3 One Zone-IA
Similar to Infrequent Access storage, but data is stored in a single Availability Zone.
This can be useful for certain data that can be recreated if necessary.
S3 Glacier Classes
These are designed for archival and long-term storage.
For example:
A company might need to retain old records for several years but almost never access them.
Instead of paying for high-performance storage, archival storage can be used.
4. S3 Lifecycle Rules
This is where S3 becomes even more interesting.
Instead of manually moving objects between storage classes, we can create Lifecycle Rules.
For example:
Day 0 → S3 Standard
After 30 days → Standard-IA
After 90 days → Glacier
After several years → Delete
This means S3 can automatically manage the lifecycle of our data.
Imagine a company storing application logs.
They might need recent logs frequently, but older logs become less useful over time.
A lifecycle policy can automatically move those logs to cheaper storage as they age.
This can reduce storage costs without requiring someone to manually manage thousands or millions of objects.
5. S3 Versioning
Versioning is another feature that I found particularly useful while learning S3.
Suppose we have:
report.pdf
and accidentally upload a new version that overwrites the previous one.
With versioning enabled, S3 can retain previous versions of the object.
So instead of simply having:
report.pdf
we can have multiple versions of that object stored by S3.
This can help protect against:
Accidental deletion
Accidental overwrites
Application mistakes
Unwanted modifications
However, there is an important point:
Versioning can increase storage usage and therefore increase costs.
That's why lifecycle rules can also be useful with versioning — for example, automatically deleting older versions after a certain period.
6. S3 Bucket Policies vs IAM Policies
This was another concept that initially required some attention.
Both IAM policies and S3 bucket policies can control access, but they are not exactly the same.
IAM Policy
An IAM policy is attached to an identity such as:
IAM user
IAM group
IAM role
It defines what that identity is allowed to do.
Bucket Policy
A bucket policy is attached directly to an S3 bucket.
It can define who can access the bucket and what actions they can perform.
For example, a bucket policy could allow a specific AWS service or account to access objects in the bucket.
A simple way to remember it:
IAM policy → permissions for an identity
Bucket policy → permissions defined at the bucket level
Understanding this distinction becomes especially important when troubleshooting S3 access issues.
7. Block Public Access
S3 also has a very important security feature called Block Public Access.
By default, AWS strongly encourages keeping S3 buckets private unless there is a specific reason to make data public.
This is extremely important because accidentally exposing an S3 bucket can result in sensitive information becoming publicly accessible.
For example, you wouldn't want a bucket containing:
Customer information
Application backups
Internal documents
Database exports
to accidentally become publicly readable.
Therefore, when working with S3, it's important to always ask:
Who actually needs access to this data?
Then grant only the permissions that are required.
This follows the principle of least privilege.
8. S3 Static Website Hosting
One of the interesting things about S3 is that it can also be used to host static websites.
For example, a website containing:
HTML
CSS
JavaScript
Images
can be stored in an S3 bucket.
S3 can then serve these static files to users.
This is particularly useful for simple static websites because you don't necessarily need to maintain a traditional web server just to serve static content.
For more advanced architectures, S3 can also work together with services such as Amazon CloudFront to deliver content efficiently through a CDN.
9. S3 Replication
What happens if we need our data to exist in another AWS Region?
That's where S3 Replication can help.
For example:
Bucket A → Mumbai Region
can replicate objects to:
Bucket B → Singapore Region
This can be useful for:
Disaster recovery
Compliance requirements
Geographic redundancy
Lower-latency access in different regions
There are different replication approaches depending on the architecture and requirements.
The important idea is:
S3 doesn't have to keep your data in only one location.
10. S3 and Data Lakes
S3 isn't only useful for storing individual files.
It is also a major building block for data lakes.
A company might collect:
Application logs
Customer data
Transaction data
IoT data
Analytics data
Machine learning datasets
and store huge amounts of this information in S3.
Other AWS services can then process and analyze that data.
This makes S3 an important part of many modern cloud architectures.
11. A Simple Real-World Example
Let's imagine we're building an e-commerce application.
Our application receives thousands of product images.
Instead of storing all those images directly on the application server, we could store them in S3.
The architecture could look something like:
User → Application → S3 → Product Image
We could then use:
S3 Standard for frequently accessed images
CloudFront for faster global delivery
Versioning to protect against accidental overwrites
Lifecycle rules to manage old files
Bucket policies/IAM for access control
Replication for additional resilience
Suddenly, S3 isn't just "cloud storage."
It becomes an important component of the application's architecture.
12. What I Took Away From Learning S3
While learning S3, one of the biggest things I realized is that the service is much more than simply uploading files to the cloud.
The important part is understanding why each feature exists.
For example:
Storage Classes → Optimize storage costs
Lifecycle Rules → Automatically manage data over time
Versioning → Protect against accidental changes
Bucket Policies/IAM → Control access
Replication → Improve resilience and meet geographic requirements
Static Website Hosting → Serve static web content
Data Lakes → Store and analyze massive datasets
Once these concepts start connecting, S3 becomes much easier to understand.
Final Thoughts
S3 is one of those AWS services that looks simple at first:
"It's just cloud storage."
But once you start exploring its security, scalability, storage classes, lifecycle management, versioning, replication, and integration with other AWS services, you realize how powerful it actually is.
I'm currently continuing my preparation for the AWS Certified Solutions Architect – Associate certification, and learning S3 has helped me understand several cloud architecture concepts more clearly.
If you're also preparing for an AWS certification, I would recommend not just memorizing what each S3 feature does.
Try to understand:
"Why would I use this feature in a real architecture?"
That shift in thinking makes AWS concepts much easier to remember.
This is Part 2 of my Amazon S3 learning series. If there is a particular S3 concept you'd like me to dive deeper into, feel free to mention it in the comments!
This one should work nicely as the follow-up to the comment because it explicitly acknowledges the request and goes deeper instead of repeating the first article.
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article