OSS gives you several levers to control storage costs: choose the right storage class for each dataset, automate transitions and cleanup with lifecycle rules, and shift outbound traffic costs to requesters when appropriate.
Unit prices in the following examples are based on OSS pricing published on July 30, 2024. Prices are updated periodically. For current rates, see the Pricing page. The examples cover common storage and request scenarios only. Other OSS features may incur additional billable items. For a complete list, see Billable items.
Monitor bucket capacity
Storage fees are charged based on data storage capacity and storage class. Unexpected capacity growth can quickly inflate costs — either from unauthorized uploads or from accumulated data that was never cleaned up.
To track usage, export CSV usage details from the account-level usage report. The report shows storage capacity per bucket, so you can verify that growth matches expectations. For details, see Query usage at the account level.
If capacity grows unexpectedly, tighten access controls. Set the bucket access control list (ACL) to private, or configure a bucket policy to block unauthorized uploads and downloads. For guidance, see Reduce the risk of unauthorized access due to account credential leaks.
Choose the right storage class
OSS offers three storage classes. The right choice depends on how frequently your data is accessed and how quickly you need to retrieve it.
| Storage class | Best for | Access frequency |
|---|---|---|
| Standard | Hot data requiring real-time reads | More than once per month |
| Infrequent Access | Warm data accessed occasionally but requiring real-time reads | Less than once per month |
| Archive Storage | Cold data stored long-term, rarely accessed, restored in about one minute | Less than once per 90 days |
Archive Storage requires a restore operation before you can read the data. If you set the storage class to Archive Storage without enabling real-time access for Archive objects, the data is not immediately readable.
Use lifecycle rules to automatically transition objects between storage classes as they age — see Configure lifecycle rules below.
Shift outbound traffic costs to requesters
By default, the bucket owner pays for all outbound traffic and data retrieval fees. If you authorize external users to access bucket data over the internet and want them to bear those costs, enable pay-by-requester mode.
For setup steps, see Pay-by-requester.
When pay-by-requester mode is enabled, outbound data transfer plans cannot be used to offset outbound traffic over internet fees generated when requesters download data from OSS to clients. In this mode, outbound traffic fees are charged based on actual usage.
Configure lifecycle rules
Lifecycle rules automate three types of cost-saving operations: transitioning objects to cheaper storage classes, deleting old object versions, and removing incomplete multipart upload parts.
Each rule consists of three elements:
| Element | Description |
|---|---|
| Conditions | When the rule triggers, based on object age (days since last modification) or a specific date |
| Actions | What the rule does: transition the storage class, or delete the object, version, or part |
| Filters | Which objects the rule applies to, identified by prefix or tags |
Transition storage classes based on access frequency
Configure a lifecycle rule to automatically move objects to a less expensive storage class when they are accessed less frequently. Filter by prefix or tags to target specific datasets while leaving frequently accessed objects in Standard storage.
For configuration steps, see Lifecycle rules based on last modification time.
Clean up previous versions
When versioning is enabled, overwritten or deleted objects are retained as previous versions. Over time, these accumulate and incur storage fees.
Configure a lifecycle rule to automatically delete previous versions after a specified number of days.
The configuration example above deletes previous versions older than 200 days. For setup steps, see Lifecycle rules based on last modification time.
Clean up incomplete multipart uploads
After a multipart upload, if CompleteMultipartUpload is never called, the uploaded parts remain in the bucket and continue to incur storage fees.
Configure a lifecycle rule to automatically delete parts after a specified number of days or on a specified date.
The configuration example above deletes parts created more than two days ago. For setup steps, see Lifecycle rules based on last modification time.