High-performance and highly available VPS/VDS with automatic installation and full root access to the OS. The ordered resources are guaranteed to be reserved for you.
Fortify your operational continuity with our resilient disaster recovery solutions, ensuring swift recovery and minimal downtime in the face of unforeseen challenges.
S3 cost savings do not come from mechanically moving βeverything oldβ to Glacier, but from policies aligned with the role of the data. It is important to understand how often an object is read, how long the business is willing to wait for restore, whether the object can be deleted automatically, whether versioning is enabled, and whether there are RPO/RTO, audit, compliance, or Object Lock requirements.
A low-cost storage class can increase the total bill because of retrieval fees, restore operations, minimum storage duration, transition requests, large numbers of small objects, and old data that continues to be stored without the application being aware of it.
A safe lifecycle strategy is based on prefixes or tags, with separate policies for active files, temporary exports, logs, archives, rarely accessed data, and noncurrent versions. The first steps are inventory, access analysis, and identifying data owners, followed by pilot rules for transitions, expiration, cleanup of old versions and delete markers, and removal of incomplete multipart uploads.
The main takeaway: lifecycle management should make storage predictable, not simply move data to the cheapest class.
Why saving money on object storage does not start with Glacier
The bill for S3 Standard usually grows unnoticed: user files, exports, media assets, logs, and old object versions. At some point, a large storage line item appears on the bill, and the first solution seems obvious: move everything older than 90 days to Glacier, delete temporary data, and archive the logs.
On a diagram, this looks like savings. In production infrastructure, it looks like a risk area.
A low-cost storage class does not always mean low-cost data. Objects may suddenly be needed by analytics, auditors, support, or the disaster recovery process. That is when retrieval fees, restore delays, minimum storage duration charges, old versions, and delete markers appearβmarkers that can make an object look deleted even though the storage space has not actually been freed.
Good lifecycle logic starts not with the object's age, but with its role:
How often the object is read;
How long the business is willing to wait for recovery;
Whether the object can be deleted automatically;
Whether versioning is enabled and whether old versions are needed for rollback;
Whether there are audit, compliance, RPO/RTO, or Object Lock requirements.
RPO is the acceptable recovery point: how much data the business can afford to lose in a failure. RTO is the acceptable recovery time. Object Lock is a mechanism that protects objects from deletion or modification for a specified period and is often used for compliance.
S3 Lifecycle is useful when it becomes a managed policy: first understand the storage economics, then choose storage classes, segment objects by use case, and only then enable transition, expiration, and version cleanup. Otherwise, optimization can easily become a new source of costsβor an overly fast way to delete data that was still supposed to be retained.
Where S3 Savings Really Come From
In S3, it is important to calculate not only the price per gigabyte per month, but the cost of owning an object throughout its lifecycle: the object is written, stored, read, transitioned to another class, restored, deleted, or retained as an old version.
This formula is not about calculating costs down to the cent; it is about disciplined thinking. A storage class with a low price per volume is cost-effective only when the dataβs behavior matches its economics: the object is rarely read, it lives long enough, and restore operations do not break SLAs or workflows.
The bill should account for:
Object storage in the selected class;
API requests, reads, and listing;
Requests to transition objects between classes;
Retrieval fees for βcoldβ classes;
Archive restore operations;
Minimum storage duration and early deletion charges;
Old object versions when versioning is enabled;
Incomplete multipart uploads.
This is where the βmove it somewhere cheaper and save moneyβ model often breaks down. For example, an analytics pipeline rereads archived exports once a week. After they are transitioned to IA or Glacier, storage becomes cheaper, but retrieval costs, restore operations, and access delays appear. IA means Infrequent Access: the class is cheaper for storage, but is designed for infrequent reads.
The minimum storage duration adds another effect. If an object is transitioned to a cheaper class and then deleted soon after, the provider may still charge for it as if it had been stored for the minimum period. For this reason, temporary files and intermediate exports should generally not be automatically moved to cold storage: on paper they become cheaper, but on the bill they do not.
Object versions are a separate area. A team may look at the current object and assume the volume is under control, while old versions continue to be stored and billed. They are useful for rollback, but without cleanup they become a quiet cost multiplier.
Therefore, a storage class should be selected not based on the lowest price per GB, but based on data behavior: how often the object is read, how long it lives, how quickly it must be restored, and whether it has old versions.
Storage classes: choose based on access needs, not the lowest storage cost
Glacier Deep Archive looks like the obvious winner: storage costs are lower, so old data should be moved there. But in a B2B system, an object may be needed today: by support to look into an order, by the finance team for reconciliation, or by engineers investigating an incident.
That is why the storage class affects not only the AWS bill, but also SLA, manual work, and decision-making speed.
S3 Standard
S3 Standard is suitable for active data: user content, working files, media data, documents, and objects that an application reads regularly.
The main risk is overpaying for data that has not been used for a long time. If an object sits idle for months without being accessed but remains in Standard, the team pays for fast access that is not actually needed.
When it becomes clear that some data is no longer active but still needs to be quickly accessible on request, the next option is IA classes.
Standard-IA and One Zone-IA
Standard-IA is suitable for infrequently accessed data that still needs to be available quickly: old reports, closed orders, completed cases, and support documents.
However, the cost savings apply only when reads are infrequent. If analytics, support, or batch jobs regularly reread these objects, retrieval fees can wipe out the benefit.
One Zone-IA should be used with more caution: it stores data in a single Availability Zone. This is reasonable for reproducible data or non-critical copies, but risky for the only copy of documents, user files, backups, or audit materials.
If the data is already archival but you cannot wait hours for it to be restored, the IA storage classes may not be sufficient. In that case, it makes more sense to consider Glacier Instant Retrieval.
Glacier Instant Retrieval
Glacier Instant Retrieval is suitable for archives that are rarely needed but may have to be accessed almost immediately. Examples include documents, old orders, investigation materials, or archival backups where waiting hours for restore is unacceptable.
The risk is that large-scale reads from such an archive can become expensive. If reports, analytics, or support teams still regularly retrieve the data, this storage class may not be as inexpensive as the storage price suggests.
When an archive is almost never read and the business can tolerate waiting for restore, you can move to colder storage classes.
Glacier Flexible Retrieval and Deep Archive
Glacier Flexible Retrieval is suitable for long-term archives where it is acceptable to wait for data restoration. Deep Archive is intended for very long-term storage: audit, compliance, and historical data that is rarely accessed.
The main consideration here is not the price per GB, but the restore time. If legal teams, auditors, support, or an incident investigation team may need the data urgently, an overly cold storage class can turn cost savings into downtime and manual escalation.
However, teams do not always know in advance how an object will be used in a month or six months. Intelligent-Tiering is suitable for these unpredictable scenarios.
Intelligent-Tiering
Intelligent-Tiering is useful when a team cannot predict object access patterns. An export may be read every day at first, forgotten a month later, and then accessed again six months later for analysis.
But it is not βfree magic.β Intelligent-Tiering does not eliminate the S3 pricing model: automation, monitoring, and individual storage tiers also come at a cost. It should be viewed as a way to reduce the risk of manual error, not as a universal replacement for a lifecycle policy.
A storage class answers the question of where to place the data. But it does not determine when to transition an object or when to delete it. S3 Lifecycle rules are needed for that.
What S3 Lifecycle can do: transitions, expiration, and version handling
S3 Lifecycle is not a discount or a βmake it cheaperβ button. It is a data management schedule: what stays in the working area, what is moved to a colder storage class, what is deleted after its lifetime expires, and what needs to be cleaned up as technical leftovers.
A rule can be applied to an entire bucket, limited to a prefix, or used to select objects by tag. For example: delete objects with the /exports/temp/ prefix after 7 days, move old versions to IA after 30 days, and delete them after 180 days.
The main S3 Lifecycle actions are:
Transition β moving the current object to a different storage class.
Expiration β deletion of the current object when its retention period expires. In a bucket without versioning, this is a physical deletion; with versioning enabled, a delete marker may be created, while older versions remain.
NoncurrentVersionTransition β transition of old, noncurrent versions to a different storage class.
NoncurrentVersionExpiration β deletion of old versions after a specified period.
Deleting expired object delete markers β cleaning up obsolete delete markers when there is no longer any required data behind them.
The current object and an old version are different entities. The application sees the current object. A noncurrent version is needed for rollback, investigation, or recovery. They have different roles, which means different lifetimes and different consequences when deleted.
Lifecycle is safe only when the rule clearly answers three questions: which objects it affects, what it does, and when the action must stop.
Object and Lifecycle Decision Matrix
A single bucket can contain user files under /media/, temporary exports under /exports/temp/, audit logs under /logs/audit/, and old document versions. To S3, these are simply objects, but to the business they differ in value, lifetime, and the cost of mistakes.
For this reason, a lifecycle policy should not apply uniformly to an entire bucket. A rule such as βmove everything older than 90 days to archiveβ treats a user document, a temporary export, and an audit log the same way, even though the consequences of a mistake are different for each.
Before configuring lifecycle policies, define the following separately for each group of objects:
EU Cloud Infrastructure You Control
Run production workloads on dedicated resources across EU data centres. Transparent pricing, no hidden costs.
Full control over compute, storage, and networking.
When the object can be moved to a lower-cost class;
When it can be deleted;
What to do with old versions;
Which risk is the primary one: restore latency, loss of rollback capability, excess retrieval fees, or premature deletion.
For example, active user files usually should not be moved to a cold storage class based on age alone. Temporary exports are often more cost-effective to delete quickly than to move to IA or Glacier. Audit logs require caution because of investigations, compliance requirements, and internal retention policies. Old object versions must be managed separately because the application does not see them, but the bill for them continues to grow.
This decision matrix is needed not as a ready-made AWS rule, but as a way to separate data by role. After that, you can move on to practical lifecycle policies: separately for active files, infrequently accessed data, archives, temporary objects, old versions, and logs.
Lifecycle Policies by Scenario: How to Apply the Matrix in Practice
Frequently accessed objects
For /media/active/, user documents, and application files, you should not configure transition to a cold storage class based on age alone. An old object is not always rarely accessed: it may be opened by users, support, integrations, or background processes.
Transition is usually not needed. If access patterns are unpredictable, it is better to consider Intelligent-Tiering or collect access statistics first. Expiration should be tied not to age, but to a business event: account closure, contract expiration, an explicit retention period, or a deletion request.
If versioning is enabled, old versions can be cleaned up separately while preserving a 30β90 day rollback window. Too short a period is risky: an error may not be detected immediately.
When an object is no longer active and moves into a closed business context, lifecycle rules can be made more aggressive.
Infrequently accessed data
Closed orders, old reports, and completed cases are best transitioned based on a clear marker: the order close date, the end of the period, or a tag set by the application.
Standard-IA is suitable for this data if fast access is required. One Zone-IA should be used only for copies that can be restored from another source. Automatic deletion can be considered 1β3 years after a case is closed, provided there are no regulatory, audit, contractual, or customer support requirements.
When versioning is enabled, you need to define a separate rollback window: for example, transition noncurrent versions to Standard-IA after 30 days and delete them after 180β365 days.
If the data has already moved out of the operational environment and is barely used in workflows, it is no longer simply βinfrequent accessβ; it is archive data.
Archived data
Data is moved to an archive after it leaves the operational environment: the financial period has been closed, the project has ended, or the data is no longer needed for day-to-day work.
The choice between Glacier Instant Retrieval, Glacier Flexible Retrieval, and Deep Archive depends on the acceptable restore time. If the legal team, audit, or security may need to request the data urgently, Deep Archive may be too slow.
Expiration for archives is enabled only after checking the retention period, compliance requirements, legal hold, and Object Lock. For some data, this is 3 years; for other data, it is 7 or 10 years. If archived objects are versioned, older versions are considered part of the archive and must be retained under the same or stricter rules.
A completely different approach is needed for objects that are not supposed to be long-lived from the outset.
Temporary files
For /exports/temp/, it is usually more cost-effective to keep S3 Standard and delete objects quickly. Moving temporary data to colder storage classes often makes it more expensive because of minimum storage duration requirements and operation costs.
The main cost-saving mechanism here is expiration. Exports and intermediate files can be deleted after 1, 3, or 7 days, but only after confirming that the user or integration has enough time to retrieve the file. You should also enable a separate rule to abort incomplete multipart uploads, for example after 1 day.
If versioning is enabled for the entire bucket, temporary files may create old versions when overwritten. For this prefix, a separate rule is needed to delete noncurrent versions after 1β7 days.
Versioned buckets generally require separate logic: the current object and its history are managed by different rules.
Object Versions
In a versioning-enabled bucket, current objects and older versions are separate entities. The application sees the current object, while noncurrent versions remain in the history and continue to consume storage.
The current object can remain in its storage class or be managed by the regular rule for that scenario. Older versions can be transitioned to Standard-IA after 30 days using NoncurrentVersionTransition, and later to Glacier. Deletion requires a separate NoncurrentVersionExpiration, for example after 180 or 365 days.
The retention period for noncurrent versions should be aligned with RPO/RTO, support requirements, and investigations. If they are deleted too early, the team may lose the ability to recover from a failed release, data corruption, or accidental deletion.
Logs are a separate case: they have their own retention periods, owners, and consequences of deletion.
Logs
Logs should be separated: application logs, access logs, audit logs, and security logs should not all be governed by the same policy.
App logs can be moved to IA after 30 days, then to Glacier after 90β180 days. Audit and security logs usually require a more cautious policy: the active retention period and deletion schedule must be agreed with security, the legal team, and audit.
App logs can be deleted after 1β2 years if this aligns with internal policy. Audit and security logs should be deleted only after the approved retention period has expired. If versioning is enabled, older versions of logs must also be cleaned up with a separate rule.
In practice, it is safer not to enable lifecycle rules for the entire bucket at once, but to apply them one prefix or tag at a time: verify the data owner, retention period, restore process, versioning, and cost estimate, including read operations. Versioned buckets require particular care: deleting the current object does not necessarily mean the costs have actually gone away.
Versioning and delete markers: why βdeletedβ does not mean βspace freedβ
In B2B storage environments, object versions are one of the most common sources of hidden costs. Lifecycle rules may seem to be configured, with current objects deleted or moved to lower-cost storage classes, but the bill decreases less than expected.
This usually happens as follows: a rule deletes the current version, S3 creates a delete marker, and the application no longer sees the object, but older versions continue to be stored and billed. The delete marker itself is usually not the main contributor to storage usage, but it creates a management problem: the team sees βdeleted,β while the objectβs history remains in the bucket.
Before enabling rules, you need to review the volume of noncurrent versions, the number of delete markers, and whether there is a separate policy for older versions. This can be done using S3 Inventory, Storage Lens, or selective checks of prefixes where documents, exports, and user files are frequently overwritten.
A safe sequence is to first define the rollback window with the data owner and in line with RPO/RTO requirements, then configure older versions to transition to a lower-cost storage class, then delete them based on age, and only then clean up expired delete markers.
If you start with deletion, you may lose the ability to restore data. If you address only the markers, there will be almost no cost savings. Version cleanup should therefore be a separate part of the lifecycle strategy, not a side effect of standard expiration.
Hidden Cost Factors Before Enabling Lifecycle
A lifecycle rule affects several billing line items at once. Before transitioning objects in bulk, it is useful to run through a short checklist: where additional costs may arise and what you need to verify before enabling the rule.
Access and restoration
The first risk is reading data after moving it to a lower-cost storage class. For Standard-IA, One Zone-IA, Glacier Instant Retrieval, and archive classes, frequent access can eat up the savings through retrieval fees.
For Glacier Flexible Retrieval and Deep Archive, another factor comes into play: restore operations. Data cannot be read immediately; it must be restored first, which affects cost, RTO, customer support, audits, and investigations.
Before moving data, it is worth reviewing reports, batch jobs, support requests, analytics, and disaster recovery scenarios. If an object is still read frequently or is needed urgently, a lower-cost storage class may be the right choice only on paper.
Minimum storage duration and transitions
IA and Glacier storage classes have a minimum storage duration. If an object is deleted soon after it is transitioned, the expected savings may not materialize: the provider will still charge as if it had been stored for the minimum period.
Transition requests should also be considered separately. Bulk transitions between classes are operations too, and their cost is especially noticeable when there are many small objects.
Before setting this up, it is worth reviewing object lifetimes, average file size, and the number of objects by prefix. For temporary exports, the main lever is often not a transition, but a short, safe expiration.
Versioning, delete markers, and multipart uploads
In a versioned bucket, older versions continue to be stored even after the current object is deleted. You should therefore check the volume of noncurrent versions in advance and verify that a NoncurrentVersionExpiration rule is in place.
Delete markers create a different problem: the object appears to be deleted, but its history may remain in the bucket. If you do not clean up stale markers and old versions, the bill will decrease less than expected.
Another hidden leftover is incomplete multipart uploads. Unfinished uploads can take up space without a visible object, so AbortIncompleteMultipartUpload should be enabled for them.
Aggressive deletion
A short expiration period quickly reduces storage volume, but it may delete data before a user, integration, audit process, or support team has retrieved it. Applying short expiration periods to logs, documents, archives, and objects subject to legal hold, Object Lock, or compliance requirements is especially risky.
Before enabling deletion, check the SLA, retention period, data owner, and recovery scenarios. Lifecycle policies should reduce unnecessary costs, not create a risk of premature data loss.
This check does not replace a cost calculation, but it helps avoid viewing lifecycle policies solely as a way to reduce storage costs. If an object needs to be read frequently, restored quickly, or retained for a long time for compliance reasons, a cheaper storage class may end up costing more than expected.
How to implement lifecycle policies without surprises
Safe implementation starts with an inventory. You need to understand which prefixes and tags exist in the bucket, which objects are being read, where versioning is enabled, how much storage old versions consume, and whether there are any incomplete multipart uploads.
For this, use S3 Inventory, Storage Class Analysis, Storage Lens, access logs, or application statistics.
After that, it is best to segment the bucket for management purposes: /media/active/, /exports/temp/, /logs/app/, /logs/audit/, /archive/, and project or customer tags. Each group should have a data owner. Without an owner, the deletion period becomes guesswork, and guesswork in a lifecycle policy means poor control.
Recommended workflow:
Collect actual usage and storage volume by prefix;
Group objects by use case and owner;
Agree on retention, restoration, and deletion periods;
Configure transition, expiration, and version cleanup for a pilot;
Validate restoration and the impact on billing;
Scale the rule only to similar groups of objects.
This process is slower than a rule that applies to βeverything older than N days,β but it reduces the risk of two common mistakes: paying more than expected for cold data and deleting something the business still needs.
Conclusion
S3 Lifecycle reduces costs not by mechanically moving everything old into an archive, but by applying a dedicated policy to each object type: where to store it, when to transition it, when to delete it, and how long to retain older versions. For a business, this is not just about the price per gigabyte, but about managed risk: whether you can quickly retrieve data for a customer, an audit, an investigation, or recovery after an error.
A safe approach is to segment objects by prefix or tag, review access patterns and retention and recovery requirements, choose the storage class, and only then enable transitions, expiration, and cleanup of noncurrent versions.
Versioning, delete markers, minimum storage duration, and retrieval fees require particular attention: these are the factors that most often turn expected savings into an unexpected bill.
The ultimate goal of a lifecycle policy is not to βmove everything to cheaper storage,β but to make storage predictable.
FAQ
Can we simply move everything older than 90 days to Glacier?
Technically, yes, but this is a poor general-purpose policy. An objectβs age does not always mean it is rarely needed. Older documents, logs, or order files may be needed regularly by support teams, analytics teams, auditors, or recovery processes.
When should you use Intelligent-Tiering?
When object access patterns are unpredictable: the data is read frequently today, used very little a month later, and then needed again for analytics. Intelligent-Tiering reduces the risk of manual error, but it does not eliminate the need to review costs, monitoring, and access scenarios.
Why might your S3 bill not decrease after deleting objects?
A common reason is versioning. In a versioned bucket, deleting the current object can create a delete marker, while older versions continue to be stored and billed.
Separate rules are needed for noncurrent versions and, when safe, for cleaning up expired delete markers.
Should temporary files be moved to cheaper storage classes?
Usually not. If a file exists for only a few days, moving it to IA or Glacier may not save money because of minimum storage duration requirements and the cost of transition requests.
For temporary exports, a short expiration period and an AbortIncompleteMultipartUpload rule for incomplete multipart uploads are usually a better fit.
How can you tell whether a lifecycle rule is safe to enable?
The rule should have a data owner, an agreed retention period, a clear recovery scenario, and separate logic for older versions.
It is best to start with a single prefix or tag: verify actual access, the impact on billing, and the recovery process, and only then scale the policy to similar groups of objects.
Subscribe to our newsletter to get articles and news
Cookie consent
This site uses cookies to ensure it works properly and to track how you use it. By clicking 'Accept', you agree to these technologies. For more details, please see our Privacy Policy and Cookies Policy
Functional
Always active
The technical storage or access is strictly necessary for the legitimate purpose of enabling the use of a specific service explicitly requested by the subscriber or user, or for the sole purpose of carrying out the transmission of a communication over an electronic communications network.
Preferences
The technical storage or access is necessary for the legitimate purpose of storing preferences that are not requested by the subscriber or user.
Statistics
The technical storage or access that is used exclusively for statistical purposes.The technical storage or access that is used exclusively for anonymous statistical purposes. Without a subpoena, voluntary compliance on the part of your Internet Service Provider, or additional records from a third party, information stored or retrieved for this purpose alone cannot usually be used to identify you.
Marketing
The technical storage or access is required to create user profiles to send advertising, or to track the user on a website or across several websites for similar marketing purposes.
