Optimize S3 Storage with Lifecycle Policies

Build S3 lifecycle rules that automatically tier objects to cut storage costs.

Introduction

30 Second Summary

Think about how you store files on your own computer. Some files you open every day, while others sit untouched for months.

In this project, you will create an S3 bucket, upload objects to different storage classes, and build an automated lifecycle policy that moves data through progressively cheaper storage tiers as it ages.

What You'll Build

You will configure an Amazon S3 lifecycle policy that automatically transitions objects through multiple storage classes based on their age, simulating a real production workload like application logs or media assets.

By the end of this project, you'll have:

An S3 bucket with objects stored across multiple storage classes (Standard, Standard-IA, and Glacier Instant Retrieval).
A working lifecycle rule that automates transitions from S3 Standard through Standard-IA to Glacier Flexible Retrieval, with automatic expiration that deletes aged-out objects.
A clear mental model of the storage class waterfall, where transitions flow one-way from hot to cold storage.
Secret Mission: Design a multi-rule lifecycle policy with prefix-based filtering that handles different data categories with different archiving strategies.

Are there any prerequisites?

You need an AWS account (free tier eligible). All work in this project is done in the AWS Management Console, so no CLI installation or coding environment is required.

Before We Start

Before We Start...

Create Your S3 Bucket and Sample Files

Before you can explore storage classes and lifecycle policies, you need an S3 bucket to experiment with and some sample files to upload into it.

In this step, you'll create a new bucket in the AWS Management Console and prepare three text files on your local machine. Each file will simulate a different data access pattern that you'll use throughout the project.

In this step, get ready to:

Sign in to the AWS Management Console and navigate to S3.
Create a new S3 bucket with a globally unique name.
Create three sample text files on your local machine.

Sign in to the AWS Management Console and navigate to S3

The S3 console is where you'll create and manage your bucket throughout this project.

Open your browser and navigate to https://console.aws.amazon.com/s3/.
Sign in to your AWS account if prompted.
In the left navigation pane, choose General purpose buckets.

What is an S3 bucket?

An S3 bucket is a container for storing objects (files) in Amazon's cloud. Every object you upload to S3 lives inside a bucket.

Think of it like a top-level folder that you can configure with security rules, lifecycle policies, and access permissions.

You should see an empty list of buckets (or any buckets you've previously created).

Can't find General purpose buckets?

Make sure you're on the S3 service page. If you landed on the AWS Console homepage instead, type S3 in the search bar at the top and select S3 from the results.

Help me find the S3 General purpose buckets page in the AWS Console.

Create a new S3 bucket

Your bucket needs a globally unique name. No two buckets in all of AWS can share the same name.

Click Create bucket.
In the Bucket name field, enter a unique name using the pattern storage-classes-lab- followed by your initials and today's date (for example, storage-classes-lab-jd-20260630).
In the navigation bar at the top of the page, confirm the AWS Region is set to the region closest to your physical location.
Scroll down and confirm that Block all public access is checked.
Confirm that Bucket Versioning is set to Disable.
Confirm that Default encryption is set to Amazon S3 managed keys (SSE-S3).
Click Create bucket at the bottom of the page.

Why does the bucket name need to be globally unique?

S3 bucket names exist in a shared global namespace across all AWS accounts. The name you choose becomes part of the URL used to access objects in your bucket, so it must be one-of-a-kind.

Adding your initials and today's date to the name makes it very unlikely to collide with someone else's bucket.

After the bucket is created, you'll be redirected back to the General purpose buckets list. Your new bucket should appear in the list.

Seeing a 'Bucket name already exists' error?

This means someone else in the world already has a bucket with that exact name. Try adding extra characters to make it unique, like a random number at the end.

Help me choose a unique S3 bucket name.

Create three sample text files on your local machine

You need three small text files that simulate different data access patterns. These will be your test objects for experimenting with storage classes in the next step.

Press the Windows key to open your search bar.
Type Notepad and press Enter to open it.
Type the following text: This file simulates frequently accessed data, like real-time analytics or active user sessions.
Save the file to your Desktop as file-hot.txt by pressing Ctrl+S, selecting your Desktop, typing file-hot.txt as the file name, and clicking Save.
Press Ctrl+N to create a new file.
Type: This file simulates infrequently accessed data, like monthly reports or old logs.
Save this file to your Desktop as file-warm.txt.
Press Ctrl+N to create another new file.
Type: This file simulates archival data, like compliance records or historical backups.
Save this file to your Desktop as file-cold.txt.

Why these three files?

Each file represents a different access pattern: hot (frequent), warm (occasional), and cold (rare). These patterns directly map to the S3 storage classes you'll explore in this project.

In a real production environment, these could be application logs (hot), monthly reports (warm), and compliance archives (cold).

Check your Desktop. You should see three files: file-hot.txt, file-warm.txt, and file-cold.txt.

File saved as .txt.txt?

Windows sometimes appends an extra .txt extension if you have file extensions hidden. In the Save dialog, change the Save as type dropdown to All Files (*.*) before saving, then type the full filename including .txt.

Help me save text files correctly in Windows Notepad.

Your S3 bucket is ready and your sample files are prepared. Next up, you'll upload these files to different storage classes and see how S3 handles each one.

Upload Objects to Different Storage Classes

Your bucket is created and your sample files are ready. Now it's time to upload those files and assign each one a different storage class.

Each storage class in S3 offers a different balance of cost, availability, and retrieval speed. By choosing the right class at upload time, you control how much you pay to store each object.

In this step, get ready to:

Upload a file using the default S3 Standard storage class.
Upload files to S3 Standard-IA and Glacier Instant Retrieval.
Verify all three objects display their respective storage classes in the console.

Upload file-hot.txt with the default storage class

When you upload an object without changing any settings, S3 assigns it the S3 Standard storage class. This is the most expensive class per GB but has no retrieval fees and no minimum storage duration.

In your bucket, click Upload.
Click Add files and select file-hot.txt from your local machine.
Expand the Properties section.
Under Storage class, confirm it is set to Standard. This is the default, so no change is needed.
Click Upload at the bottom of the page.

You should see a green success banner at the top of the page confirming your file uploaded successfully.

Click Close to return to your bucket's object list.

Why start with S3 Standard?

S3 Standard is designed for frequently accessed data (more than once a month). It offers 99.99% availability and no retrieval fees. Think of it as the "hot" tier for data you need right now.

Upload file-warm.txt and file-cold.txt with different storage classes

Now you will upload the remaining two files and override the default storage class for each one. This lets you see how S3 handles objects stored at different cost and access tiers.

Click Upload.
Click Add files and select file-warm.txt from your local machine.
Expand the Properties section.
Under Storage class, change the selection to Standard-IA.
Click Upload at the bottom of the page.
Click Close to return to your bucket.

What is S3 Standard-IA?

S3 Standard-IA stands for "Infrequent Access." It costs less per GB than S3 Standard, but charges a per-GB retrieval fee every time you download the data.

It is ideal for data you access about once a month but still need available in milliseconds when you do.

Now upload the final file with an archival storage class.

Click Upload.
Click Add files and select file-cold.txt from your local machine.
Expand the Properties section.
Under Storage class, change the selection to Glacier Instant Retrieval.
Click Upload at the bottom of the page.
Click Close to return to your bucket.

What is Glacier Instant Retrieval?

S3 Glacier Instant Retrieval is designed for archive data accessed about once a quarter. It still provides millisecond retrieval (unlike other Glacier classes), but at a much lower storage cost than Standard-IA.

The trade-off is a 90-day minimum storage duration. If you delete or transition the object before 90 days, you are charged for the full 90 days.

Don't see Glacier Instant Retrieval in the list?

Make sure you expanded the Properties section (not the Permissions or Tags sections). The Storage class dropdown appears inside Properties.

If the option still does not appear, confirm your bucket is a General purpose bucket (not a Directory bucket). Directory buckets do not support Glacier classes.

help me find the Glacier Instant Retrieval storage class option during upload

Verify your objects and their storage classes

Back in your bucket's object list, you should now see all three files. The Storage class column shows the class you assigned to each one.

Look at the Storage class column in the object list. You should see:
Click on file-hot.txt to open its Object overview page.
Note the Storage class, Size, and Last modified fields in the properties panel.
Use the back arrow or breadcrumb to return to the object list, then repeat for file-warm.txt and file-cold.txt.

What should I see in the properties panel?

Each object's overview page shows its storage class alongside metadata like the file size and the timestamp of when it was uploaded. This is the same information that lifecycle rules will use later to decide when to transition objects.

Don't see a Storage class column?

If the column is not visible, your browser window may be too narrow. Try making the browser wider or scrolling horizontally in the object list. You can also click into any object to confirm its storage class on the detail page.

help me find the storage class information for my uploaded S3 objects

You now have three objects stored at different price and performance tiers. Next up, you will discover what happens when you try to move objects between storage classes manually.

Change Storage Classes and Discover the Waterfall

Your bucket now holds three objects, each living in a different storage class. But how do these classes relate to each other?

Storage class transitions in S3 follow a strict one-way path. You can move objects toward colder, cheaper classes, but you cannot move them back. In this step, you will discover this constraint firsthand by manually changing storage classes in the console.

In this step, get ready to:

Transition file-hot.txt from S3 Standard to S3 Standard-IA manually.
Attempt to move it back and discover the one-way waterfall constraint.
Explore the allowed downward transition targets from Standard-IA.

Transition file-hot.txt to Standard-IA

Your file-hot.txt is currently in S3 Standard. You are going to manually move it to a colder storage class to simulate what happens when data ages.

In your bucket's object list, select the checkbox next to file-hot.txt.
Open the Actions menu at the top of the object list.
Choose Edit storage class.
On the Edit storage class page, observe the list of available target classes. You should see options like S3 Standard-IA, S3 Intelligent-Tiering, S3 One Zone-IA, S3 Glacier Instant Retrieval, S3 Glacier Flexible Retrieval, and S3 Glacier Deep Archive.
Select Standard-IA as the target storage class.
Choose Save changes in the bottom-right corner.

What just happened behind the scenes?

When you change an object's storage class through the console, S3 performs a copy operation. It creates a new version of the object with the new storage class and replaces the old one.

This is important to understand for the SAA exam. Changing a storage class is not a simple metadata flip. It is a copy to a new object with updated system metadata.

Back in your bucket's object list, confirm that file-hot.txt now shows Standard-IA in the Storage class column.

Still seeing Standard?

Refresh the page if the storage class column has not updated. If you still see Standard, make sure you clicked Save changes on the Edit storage class page before navigating away.

help me figure out why my storage class change did not save

Discover the one-way waterfall

Now try to move file-hot.txt back to its original class. This is where the waterfall model reveals itself.

Select the checkbox next to file-hot.txt again.
Open the Actions menu and choose Edit storage class.
Look at the list of available target classes. Notice that S3 Standard is NOT listed as an option.

This is the waterfall model in action. Transitions only flow downward toward colder, cheaper storage classes. You cannot move an object back up to a warmer class using this action.

What is the storage class waterfall?

S3 storage classes are arranged in a hierarchy from "hot" (frequently accessed, higher cost) to "cold" (rarely accessed, lower cost). The console and lifecycle rules enforce one-way transitions down this hierarchy.

The only way to move an object back "up" to a warmer class is to copy it to a new object with the desired storage class. This is a deliberate design choice that lifecycle policies also follow.

Choose Cancel to close the Edit storage class page without making changes.

Explore the allowed transitions from Standard-IA

Your file-warm.txt is currently in Standard-IA. Let's check what transitions are available from this class to confirm the waterfall pattern.

Select the checkbox next to file-warm.txt.
Open the Actions menu and choose Edit storage class.
Observe the available target classes. You should see only classes that are "below" Standard-IA in the waterfall: S3 Intelligent-Tiering, S3 One Zone-IA, S3 Glacier Instant Retrieval, S3 Glacier Flexible Retrieval, and S3 Glacier Deep Archive.
Notice that S3 Standard is not available here either. The console only offers downward transitions.
Choose Cancel to close without making changes.

Why does this matter for lifecycle rules?

Lifecycle rules follow the exact same waterfall constraint. When you automate transitions in the next step, you can only move objects downward through the hierarchy. This is why planning your transition timeline matters. Once data moves to a colder class, you cannot automatically send it back up.

The SAA exam frequently tests this concept by asking which transitions are valid or invalid in a lifecycle configuration.

The full waterfall at a glance

S3 Standard can transition to: Standard-IA, Intelligent-Tiering, One Zone-IA, Glacier Instant Retrieval, Glacier Flexible Retrieval, Glacier Deep Archive.
S3 Standard-IA can transition to: Intelligent-Tiering, One Zone-IA, Glacier Instant Retrieval, Glacier Flexible Retrieval, Glacier Deep Archive.
S3 One Zone-IA can transition to: Glacier Flexible Retrieval, Glacier Deep Archive.
S3 Glacier Instant Retrieval can transition to: Glacier Flexible Retrieval, Glacier Deep Archive.
S3 Glacier Flexible Retrieval can transition to: Glacier Deep Archive only.

You have now seen the waterfall model firsthand. In the next step, you will use this knowledge to build an automated lifecycle policy that transitions objects through multiple storage classes on a schedule.

Create a Lifecycle Rule for Automated Transitions

In the previous step, you discovered that storage class transitions follow a one-way waterfall. Moving objects manually works for one-off changes, but production buckets can hold millions of objects that all need to age through the same path.

S3 lifecycle rules automate these transitions based on object age. In this step, you'll create a rule that moves objects from Standard through Standard-IA to Glacier Flexible Retrieval, then deletes them after a year.

In this step, get ready to:

Create a lifecycle rule in the Management tab.
Configure automated storage class transitions at 30 and 90 days.
Set an expiration policy that deletes objects after 365 days.

Create a lifecycle rule and set its scope

A lifecycle rule needs two things: a scope (which objects it applies to) and actions (what happens to those objects over time). You'll start by naming the rule and defining its scope.

In your bucket, click the Management tab.
Click Create lifecycle rule.
In the Lifecycle rule name field, enter log-aging-policy.
Under Rule scope, choose Apply to all objects in the bucket.
Under Lifecycle rule actions, check Transition current versions of objects between storage classes.

Why apply to all objects?

Choosing "Apply to all objects in the bucket" means every object follows the same aging path. This is perfect for a uniform workload like application logs where all files have the same access pattern.

In the Secret Mission later, you'll see how to use prefix filters to apply different rules to different categories of data.

Configure storage class transitions

Now you'll define the transition timeline. Each transition specifies a target storage class and how many days after creation to move objects there.

Scroll down to the Transition current versions of objects between storage classes section.
In the first transition row, choose Standard-IA as the storage class.
Enter 30 in the Days after object creation field.
Click Add transition to add a second row.
In the second transition row, choose Glacier Flexible Retrieval as the storage class.
Enter 90 in the Days after object creation field.

Why 30 days for the first transition?

The console enforces a minimum of 30 days before transitioning objects to Standard-IA or One Zone-IA. You cannot enter a value lower than 30 for these storage classes.

The console also enforces the waterfall ordering. You can only add transitions that flow "downward" toward colder storage classes, matching the same constraint you saw when editing storage classes manually.

Add an expiration rule and save

Expiration rules automatically delete objects after a set number of days. This is useful for data with a known retention period, like logs that only need to be kept for one year.

Scroll back up to the Lifecycle rule actions section.
Check Expire current versions of objects.
Scroll down to the Expire current versions of objects section that appears.
Enter 365 in the Days after object creation field.
If you see a warning about incomplete multipart uploads, acknowledge it by checking the acknowledgement box.
Click Create rule.

You should be taken back to the Management tab. Your new lifecycle rule log-aging-policy appears in the list with a status of Enabled.

What does this rule actually do?

Your lifecycle rule creates a three-stage aging pipeline. Objects start in S3 Standard. After 30 days, they automatically move to Standard-IA (cheaper storage, per-GB retrieval fee). After 90 days, they move to Glacier Flexible Retrieval (much cheaper, but retrieval takes minutes to hours).

After 365 days, objects are permanently deleted. This is the exact pattern the SAA exam tests: "A company stores log files that are accessed frequently for the first month, occasionally for the next two months, and rarely after that. What lifecycle configuration minimizes cost?"

Will the rule transition your sample files?

Amazon S3 does not transition objects smaller than 128 KB by default. Since your sample text files are tiny, the rule won't actually move them in practice. In a real production bucket with larger files (application logs, media assets), the transitions would execute automatically.

The rule is still valid and visible in the console. This is the same configuration you would use for real workloads.

Don't see your rule in the Management tab?

Make sure you clicked Create rule at the bottom of the page. If the console showed a validation error, check that your Standard-IA transition has at least 30 days and that Glacier Flexible Retrieval has a higher day count than Standard-IA.

If you accidentally navigated away, go back to the Management tab in your bucket. If no rule appears, click Create lifecycle rule and start again.

Still stuck? Help me troubleshoot my lifecycle rule creation.

Click on your log-aging-policy rule to view its details.
Confirm you see two transitions listed: Standard-IA at 30 days and Glacier Flexible Retrieval at 90 days.
Confirm you see the expiration set to 365 days.

Your lifecycle rule is now live. In the next step, you'll review the full configuration and connect it to the SAA exam scenarios you'll face on test day.

Review Your Configuration and SAA Exam Scenarios

Your lifecycle rule is live. You now have an automated policy that transitions objects through three storage tiers and deletes them after a year.

In this step, you'll review your configuration through the lens of the AWS Solutions Architect Associate exam. The SAA exam tests your ability to choose the right storage class for a given access pattern and to design lifecycle rules that minimize cost. Understanding the constraints behind your rule is what separates memorizing storage classes from actually architecting with them.

In this step, get ready to:

Review your lifecycle rule's transition timeline visualization.
Learn the minimum storage duration constraints tested on the SAA exam.
Apply a decision framework for choosing storage classes based on access patterns.

Review your lifecycle rule and the SAA exam scenario

The S3 console displays a transition timeline visualization after you create a lifecycle rule. This visual is a helpful way to confirm your transitions are ordered correctly.

In the Management tab of your bucket, click on the log-aging-policy rule to open its details.
Observe the transition timeline that AWS displays. You should see your two transitions (Standard-IA at 30 days, Glacier Flexible Retrieval at 90 days) and the expiration at 365 days laid out on a timeline.

Why does this matter for the SAA exam?

This lifecycle rule maps directly to a classic SAA exam question: "A company stores log files in S3. The files are accessed frequently for the first month, occasionally for the next two months, and rarely after that. What lifecycle configuration minimizes cost?"

The answer is exactly what you built. S3 Standard for the first 30 days (frequent access), Standard-IA from day 30 to 90 (occasional access), and Glacier Flexible Retrieval from day 90 onward (rare access with acceptable retrieval delay).

Understand minimum storage duration constraints

Each storage class below S3 Standard enforces a minimum storage duration. If you delete or transition an object before that minimum, AWS charges you for the remaining days as if the object were still stored there.

Review these minimum storage durations. These are the constraints the SAA exam tests most frequently:

S3 Standard-IA and S3 One Zone-IA: 30-day minimum storage duration.
S3 Glacier Instant Retrieval and S3 Glacier Flexible Retrieval: 90-day minimum storage duration.
S3 Glacier Deep Archive: 180-day minimum storage duration.

What happens if I delete before the minimum?

Objects deleted, overwritten, or transitioned before their minimum storage duration incur a pro-rated charge equal to the storage charge for the remaining days. For example, if you delete a Standard-IA object after 10 days, you still pay for the other 20 days.

This is why your lifecycle rule transitions to Standard-IA at 30 days (the minimum) and to Glacier Flexible Retrieval at 90 days (the minimum for that class). Setting transitions below these thresholds would mean paying for storage you are not using.

What about objects smaller than 128 KB?

Amazon S3 applies a default behavior that prevents objects smaller than 128 KB from being transitioned to any storage class. Your sample text files are well under this threshold, so the lifecycle rule will not actually transition them in practice.

This is expected. In production, real workloads (log files, media assets) easily exceed 128 KB. The rule configuration itself is still valid and visible in the console.

Apply the storage class decision framework

The SAA exam gives you an access pattern and asks you to pick the cheapest storage class that meets the requirements. Use this decision framework to answer those questions.

Read through each storage class and its ideal use case:

Frequently accessed (more than once a month), millisecond access needed: S3 Standard.
Unknown or changing access patterns: S3 Intelligent-Tiering.
Infrequently accessed (about once a month), millisecond access needed: S3 Standard-IA.
Same as above but data is recreatable, single AZ acceptable: S3 One Zone-IA (costs 20% less than Standard-IA).
Archive, accessed quarterly, millisecond access needed: S3 Glacier Instant Retrieval.
Archive, accessed 1-2 times per year, minutes to hours retrieval OK: S3 Glacier Flexible Retrieval.
Archive, accessed less than once per year, hours retrieval OK: S3 Glacier Deep Archive.

The two key questions on the exam

When you see a storage class question on the SAA exam, ask yourself two things. First: how often is the data accessed? This narrows down your tier. Second: how fast does the data need to be available when requested? This separates Glacier Instant Retrieval (milliseconds) from Glacier Flexible Retrieval (minutes to hours) from Glacier Deep Archive (hours to days).

How does your lifecycle rule map to this framework?

Your rule starts at S3 Standard (frequent access in the first month). At 30 days it transitions to Standard-IA (occasional access, still millisecond retrieval). At 90 days it transitions to Glacier Flexible Retrieval (rare access, retrieval delay of minutes to hours is acceptable). At 365 days the object expires because it is no longer needed.

You now have a complete mental model of S3 storage classes, the one-way waterfall, minimum storage durations, and how to design lifecycle rules that minimize cost. Ready to take it further? The Secret Mission challenges you to design a multi-rule policy with prefix-based filtering for different data categories.

Secret mission

Design a Multi-Rule Policy with Prefix Filtering

In production, different types of data age at different rates. Logs can be aggressively archived and deleted, while media assets need fast retrieval for months. Can you design a multi-rule lifecycle policy that handles each category differently?

Clean Up Your Resources

This project's S3 storage (a few KB of text files) falls well within the AWS Free Tier's 5 GB allowance for 12 months. Decide whether to keep your resources, pause them to come back later, or delete them entirely.

Resources you used:

S3 bucket with five objects (across multiple storage classes) and two lifecycle rules.
Three local text files (file-hot.txt, file-warm.txt, file-cold.txt).

Keep everything running

No action needed. Choose this if you want to observe how lifecycle rules behave over time.

Your S3 bucket, objects, and lifecycle rules remain in place.
The few KB of text files cost effectively nothing under the Free Tier (5 GB of S3 Standard storage free for 12 months).
Note that objects smaller than 128 KB are not transitioned by lifecycle rules, so your sample files will stay in their current storage classes.

Pause - I'll come back to this later

S3 does not have a true "pause" state. Since the storage costs are negligible for small text files, pausing is effectively the same as keeping.

If you want to reduce your account footprint slightly, delete the objects but keep the bucket and lifecycle rules. This lets you re-upload files later and see the rules in action.
Open your bucket in the S3 console, select all objects, and choose Delete.
Confirm the deletion when prompted.
Your bucket and lifecycle rules stay intact for future experimentation.

Delete - I don't want to use this again

Remove all project resources to keep your AWS account clean. This ensures zero ongoing charges.

In the S3 console, navigate to General purpose buckets.
Click your bucket name to open it.
Select all objects (including items in the logs/ and media/ folders), then choose Delete.
On the Delete objects page, type permanently delete in the confirmation field, then choose Delete objects.
Return to the General purpose buckets list.
Select the radio button next to your bucket and choose Delete at the top of the page.
On the Delete bucket page, type your bucket name in the confirmation field and choose Delete bucket.
Delete the three local text files (file-hot.txt, file-warm.txt, file-cold.txt) from your computer.

That's a Wrap!

Nice work! You just built a complete S3 storage optimization strategy from scratch, covering manual transitions, automated lifecycle policies, and real-world cost decision-making.

You've learned how to:

Upload objects to multiple S3 storage classes and discover the one-way waterfall model by manually transitioning objects and observing allowed paths.
Build an automated lifecycle policy with multi-step transitions from Standard to Standard-IA to Glacier Flexible Retrieval, plus an expiration rule for automatic deletion.
Apply the SAA exam decision framework for choosing the right storage class based on access frequency, retrieval speed, and cost trade-offs.
Secret Mission: Designed a multi-rule lifecycle policy with prefix-based filtering for different data categories (logs vs. media), demonstrating real-world architecture decision-making.

Ready to quiz yourself?