S3 Storage Management and Lifecycle Policies. If you store data in the cloud, you quickly realise that not all files need to live on super-fast, expensive storage forever. This chapter explains how to automatically move or delete your files based on age, saving you money and keeping your storage tidy — a core skill for the SOA-C02 exam.
Jump to a section
A charity warehouse manager is the person responsible for organising a huge storage facility filled with donated items — clothes, books, furniture, and electronics — each tagged with a barcode and stored on shelves. The manager's job is to decide where each item goes when it arrives, how long it stays, and when it should be moved or disposed of, all while keeping costs low.
When a box of winter coats arrives, the manager puts them on the fastest-access shelves because they'll be distributed straight away. But a pallet of old textbooks might go on a slower, cheaper shelf in the back corner, since they're not needed urgently. Over time, the manager follows a policy: after six months, textbooks on the cheap shelf get moved to an even cheaper off-site storage unit. After a year, if no one has claimed them, they're recycled or donated to a paper mill. The manager also sets rules to automatically sort incoming items: expired food gets thrown out immediately, fragile items get special padded bins, and high-demand items stay on the premium shelves until they're claimed.
This is exactly how S3 Storage Management and Lifecycle Policies work in Amazon Web Services (AWS). The warehouse is your S3 bucket, the items are your data objects (files), and the shelves are different storage classes — each with a different price and access speed. The manager's rules are lifecycle policies: automated instructions that tell AWS when to move your data to cheaper storage or delete it, saving you money without you having to check every file yourself.
Amazon S3 (Simple Storage Service) is a cloud storage service from Amazon Web Services (AWS). You use it to store files — AWS calls them 'objects' — inside containers called 'buckets'. Think of a bucket like a folder on your computer, but one that can hold an almost unlimited number of files. Each object can be anything: a photo, a video, a log file, or a database backup.
To manage these objects efficiently, S3 offers several 'storage classes'. A storage class is like a pricing tier: each one has a different cost for storing data, a different cost for retrieving it, and a different level of durability and availability. The main storage classes you need to know for the SOA-C02 exam are:
S3 Standard: The default class. Use it for frequently accessed data, like images on a busy website. It's the most expensive per gigabyte but gives you fast access whenever you need it.
S3 Intelligent-Tiering: This class automatically moves your objects between two tiers — a fast-access tier and a slower-access tier — based on how often they are used. You pay a small monitoring fee, but it can save you money if you're not sure which tier to pick.
S3 Standard-IA (Infrequent Access): Use this for data you need occasionally, like monthly reports. It costs less to store than Standard but charges you a fee each time you access it.
S3 One Zone-IA: Similar to Standard-IA but stores your data in only one physical data centre (Availability Zone) instead of three. It's cheaper but less durable. Good for data you can recreate, like thumbnail images.
S3 Glacier Instant Retrieval: For long-lived data that you access maybe once a quarter but need instantly when you do. Think of it as cold storage but with fast delivery.
S3 Glacier Flexible Retrieval (formerly just Glacier): For data you access rarely, like archived records. Retrieval takes minutes to hours.
S3 Glacier Deep Archive: The cheapest class. Use it for data you need to keep for years but almost never access — think legal compliance records. Retrieval takes hours.
Now, what are lifecycle policies? A lifecycle policy is a set of rules you write that tell S3 what to do with your objects automatically. You define a 'transition action' (move an object to a cheaper storage class) or an 'expiration action' (delete an object) based on the object's age in days.
Why is this useful? Imagine you run a news website. Every day, your servers generate log files that list every visitor and error. During the first month, you might check those logs every day (S3 Standard). After 30 days, you probably only look at them if something goes wrong (move to Standard-IA). After 90 days, you keep them for legal reasons but never look at them (move to Glacier). After a year, you can delete them. A lifecycle policy does all that automatically, so you don't have to remember or write scripts.
Lifecycle policies apply to a whole bucket or to a subset of objects filtered by a 'prefix' (a folder-like path, e.g., 'logs/') or an 'object tag' (a label you assign, e.g., 'Project=Alpha'). When the policy runs, AWS checks the 'creation date' of each object and calculates how many days have passed. If the object meets the rule's criteria, AWS moves or deletes it.
A key detail: you cannot transition from Standard directly to Glacier Deep Archive in one step. You must transition through intermediate classes (like Standard-IA or Glacier Flexible Retrieval) depending on the minimum days between transitions. The standard rules allow transitions after 30 days to Standard-IA, 60 days to Glacier Flexible Retrieval, and 180 days to Glacier Deep Archive.
Another important concept is 'versioning'. If you enable versioning on a bucket, S3 keeps every version of an object when it is overwritten or deleted. Lifecycle policies can also manage these old (non-current) versions separately. For example, you might keep the current version in Standard forever, but move old versions to Glacier after 30 days and delete them after 365 days. This prevents your storage costs from spiralling out of control.
Finally, remember that lifecycle policies are not retroactive. They only apply to objects created after the policy is enabled. Also, if you delete an object before its lifecycle rule triggers, the rule simply never runs on it. Lifecycle policies run once per day, so there may be a delay of up to 24 hours before an action is taken.
Identify your data lifecycle
Determine how long each type of data needs to stay in fast storage, when it can be moved to cheaper storage, and when it can be deleted. This is crucial because it drives the rules you will write. For example, log files might be accessed for 30 days, then archived for a year, then deleted.
Enable versioning (optional but recommended)
If you enable versioning on your S3 bucket, every overwrite or deletion creates a new version of the object. This protects against accidental data loss. Versioning is a prerequisite if you plan to manage non-current versions separately using lifecycle rules.
Create a lifecycle rule in the AWS Console
Navigate to your S3 bucket, go to the 'Management' tab, and click 'Create lifecycle rule'. You can name the rule and optionally define a scope (prefix or tags) to limit which objects the rule applies to. This step sets up the automated policy.
Configure transition actions
Add rules that move objects to a cheaper storage class after a specified number of days. For example, 'Transition to Standard-IA after 30 days'. Ensure you follow the minimum day requirements between transitions (e.g., 30 days for Standard to Standard-IA).
Configure expiration actions
Add rules that permanently delete objects after a certain number of days. For example, 'Expire after 365 days'. If versioning is enabled, this will create a delete marker for the current version, and you must also add a 'NoncurrentVersionExpiration' rule to delete old versions.
Review and save the lifecycle policy
Double-check your rules for transition paths and minimum days. Save the policy. The lifecycle will run once per day, so allow up to 24 hours for actions to take effect. Monitor the bucket over the next week to ensure objects are being moved as expected.
An IT professional — let's call her Priya — works as a Cloud Administrator for a company called 'MediFile', a medical imaging startup that stores patient X-rays and MRI scans. MediFile needs to keep every scan for at least 7 years due to healthcare regulations, but they want to minimise storage costs because they have petabytes of data.
Priya's first task is to organise the data. She creates an S3 bucket called 'medifile-scans'. Inside, she uses a folder structure like 'patients/2024/01/25/patient-12345-scan.dcm'. She enables versioning on the bucket in case someone accidentally overwrites a scan.
Next, Priya creates a lifecycle policy. She opens the AWS Management Console, navigates to her bucket, and clicks the 'Management' tab, then 'Lifecycle rules'. She names the rule 'MedicalRetention. She defines the scope to apply to all objects in the bucket.
She then adds a series of transitions:
After 30 days from object creation, move objects from S3 Standard to S3 Standard-IA. Reason: after a month, the scan isn't accessed daily, only when a doctor reviews a patient history.
After 90 days, move objects from Standard-IA to S3 Glacier Flexible Retrieval. Reason: older scans are rarely looked at, but need to be kept for compliance.
After 365 days, move objects from Glacier to S3 Glacier Deep Archive. Reason: after a year, scans are almost never accessed, but must be retained for 7 more years.
She also adds an expiration rule: permanently delete objects after 2555 days (roughly 7 years). This meets the regulatory requirement.
Finally, she adds a separate rule for non-current versions. For old versions of objects (created when a file is overwritten), she transitions them to Glacier after 1 day and deletes them after 30 days. Why? She doesn't need old versions of the same scan sitting around on expensive storage indefinitely.
Priya reviews the policy and saves it. The lifecycle policy now runs automatically each day. She doesn't have to manually move a single file. She also sets up a life cycle policy on a separate bucket called 'medifile-backup' that simply deletes temporary backup files after 7 days.
The result: MediFile reduces its monthly S3 bill by 40%, because 60% of their data is now on Glacier or Glacier Deep Archive instead of Standard. Auditors are happy because data is retained for exactly 7 years and no longer. Priya's manager praises her for being proactive. On the SOA-C02 exam, Priya would know that the key is to set the correct transition rules with appropriate days, and to remember that lifecycle policies are applied to the bucket, not the individual objects.
The SOA-C02 exam tests your knowledge of S3 Storage Management and Lifecycle Policies heavily. Expect at least 3-5 questions on this topic across the multiple-choice section. The exam is not about memorising exact pricing; it's about knowing which storage class to use in which scenario and how to configure lifecycle rules correctly.
Here are the exact concepts they love to test:
Transition minimum days: The exam frequently asks about the minimum number of days between transitions. Remember: 30 days for S3 Standard to Standard-IA, 60 days for Standard-IA to Glacier Flexible Retrieval or Glacier Instant Retrieval, and 180 days for Glacier Flexible Retrieval to Glacier Deep Archive. There is a trick: you cannot transition from Standard directly to Glacier Deep Archive; you must go through an intermediate class.
Expiration vs transition: They will give you a scenario where an object should be deleted after 365 days. The correct answer is to set an 'expiration' action, not a 'transition' action. Trasition moves the object, expiration deletes it. Do not confuse the two.
Non-current version management: A frequent trap. The question will describe a bucket with versioning enabled, and ask how to handle old versions. The correct answer is to use 'NoncurrentVersionTransition' and 'NoncurrentVersionExpiration' within the lifecycle policy. They may try to trick you by suggesting you use the 'Current version' rules.
Lifecycle policy scope: The exam tests that you can filter by prefix or tags. A question might say 'only apply this rule to objects in the 'logs/' folder'. The answer will be to set the prefix to 'logs/' in the lifecycle rule. They may distract you with options like 'create a separate bucket' or 'use IAM policies'.
Storage class selection: You will be given a scenario about data access patterns. Common exam cases:
- Data accessed frequently: S3 Standard - Data accessed rarely but must be retrievable in minutes: S3 Glacier Flexible Retrieval - Data that can be recreated and is rarely used: S3 One Zone-IA - Data that needs the cheapest possible storage and retrieval can take hours: S3 Glacier Deep Archive - Intelligent-Tiering vs manual: Some questions ask when to use Intelligent-Tiering. The correct answer: when access patterns are unknown or unpredictable. But beware the monitoring fee. - Lifecycle policy timing: They might ask you what happens if you create a lifecycle policy with a 30-day transition on a bucket that already contains objects that are 60 days old. The correct answer: the policy is not retroactive. It only applies to newly uploaded objects.
Common traps include:
Thinking that lifecycle policies work in real-time. They do not; they run daily.
Assuming you can delete objects on the same day you transition them. You cannot set an expiration rule with fewer days than your latest transition rule.
Mixing up 'transition' and 'expiration' actions.
Forgetting that S3 One Zone-IA does not have the same durability as other classes (99.5% vs 99.999999999% durability).
To ace this section, memorise the transition min days table, practise writing lifecycle policies in the AWS console, and review practice questions that give you a business scenario and ask you to pick the cheapest storage class or the correct lifecycle rule.
Lifecycle policies automate moving data to cheaper storage classes or deleting it based on the age of the object, saving money and time.
You cannot transition from S3 Standard directly to Glacier Deep Archive; you must go through an intermediate class like Standard-IA or Glacier Flexible Retrieval.
Lifecycle policies are not retroactive — they only apply to objects created after the policy is enabled.
To manage old versions of objects in a versioned bucket, use 'NoncurrentVersionTransition' and 'NoncurrentVersionExpiration' rules.
Expiration actions in lifecycle policies delete the object permanently (or create a delete marker in versioned buckets), while transition actions move it to a different storage class.
S3 Intelligent-Tiering is ideal when access patterns are unknown, but it incurs a monthly monitoring fee per object.
These come up on the exam all the time. Here's how to tell them apart.
S3 Standard
Higher storage cost per GB (approx. $0.023/GB)
No retrieval fee
Designed for frequent, fast access multiple times per day
S3 Standard-IA
Lower storage cost per GB (approx. $0.0125/GB)
Charges a retrieval fee per GB accessed
Best for data accessed infrequently (once a month or less)
Lifecycle Transition Action
Moves an object to a cheaper storage class
Object continues to exist but on different storage
Use when you want to retain data but reduce cost
Lifecycle Expiration Action
Permanently deletes the object
Object no longer exists in the bucket
Use when you no longer need the data (e.g., after compliance period)
S3 Glacier Flexible Retrieval
Retrieval time of minutes to hours (typical 5-12 hours)
Storage cost approx. $0.004/GB
Good for data accessed once or twice a year
S3 Glacier Deep Archive
Retrieval time of 12 to 48 hours
Storage cost approx. $0.001/GB
Best for data accessed less than once a year (e.g., legal archives)
Mistake
Lifecycle policies can move objects to any storage class in any order.
Correct
Lifecycle policies can only transition objects to cheaper storage classes in a specific allowed path. For example, you cannot go directly from S3 Standard to Glacier Deep Archive without going through an intermediate class like Standard-IA.
This misconception arises because beginners think any rule is possible, but AWS has strict transition paths to prevent unexpected costs.
Mistake
If I set an expiration rule, the object is deleted immediately on the exact day.
Correct
Lifecycle policies execute once per day, so there can be a delay of up to 24 hours before an object is actually deleted or transitions. Expiration does not happen at midnight precisely.
The term 'expiration' sounds instant, so beginners assume real-time execution, but it is a batch process.
Mistake
Lifecycle policies apply to all objects in the bucket retroactively, even those uploaded before the policy was created.
Correct
Lifecycle policies are not retroactive. They only apply to objects created after the policy is enabled. Existing objects remain untouched unless you manually modify them.
Beginners think that because the policy is set on the bucket, it will check all objects. But AWS evaluates based on creation date, and only objects with a creation date after the policy's effective date are considered.
Mistake
Versioning must be enabled to use lifecycle policies.
Correct
Versioning is not required for lifecycle policies. You can set lifecycle rules on a bucket without versioning. Versioning is only needed if you want to manage non-current versions separately.
The exam often pairs lifecycle policies with versioning scenarios, leading beginners to think they are dependent. They are independent but often used together.
Mistake
When I delete an object using a lifecycle policy, I lose all versions, including the current one.
Correct
If versioning is enabled, an expiration action only creates a delete marker for the current version. Older versions remain visible unless you also set a non-current version expiration rule that permanently deletes them.
People confuse versioning and lifecycle. In a versioned bucket, deleting the current version just hides it, it does not permanently delete it unless specifically configured.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
No, you cannot transition directly from Standard to Glacier Deep Archive. You must first transition to Standard-IA after 30 days, then to Glacier Flexible Retrieval after 90 days, then to Glacier Deep Archive after 180 days.
The current version of the object will have a delete marker created, effectively hiding it. The old versions (non-current) will remain unless you also set a 'NoncurrentVersionExpiration' rule to permanently delete them after a specified number of days.
The lifecycle policy itself costs nothing to create, but the transition actions incur standard S3 transition charges (a small fee per thousand objects). The monitoring fee for Intelligent-Tiering also applies.
After you save the lifecycle policy, it can take up to 24 hours for the first run. Subsequent runs occur daily. So if you set a 30-day transition, the object will move roughly 30 to 31 days after creation.
Yes. When creating the lifecycle rule, you can add a tag-based filter (e.g., 'Project=Alpha'). Only objects with that tag will be affected. This is useful for organising data across different projects in the same bucket.
S3 Glacier Deep Archive is the cheapest for storage at about $0.001 per GB per month, but retrieval costs are high and retrieval time is hours. For rarely accessed data that must be retained long-term, it is the most cost-effective option.
You've just covered S3 Storage Management and Lifecycle Policies — now see how well it sticks with free SOA-C02 practice questions. Full explanations included, no account needed.
Done with this chapter?