Stay organized with collections Save and categorize content based on your preferences.
The Autoclass feature automatically transitions objects in your bucket to appropriate storage classes based on each object's access pattern. The feature moves data that is not accessed to colder storage classes to reduce storage cost and moves data that is accessed to Standard storage to optimize future accesses. Autoclass simplifies and automates cost saving for your Cloud Storage data.
OverviewWhen enabled, Autoclass manages all aspects of storage classes for a bucket:
All objects added to the bucket begin in Standard storage, even if a different storage class is specified in the request.
The bucket itself always has its default storage class set to Standard storage, and requests that attempt to change this property to a storage class other than Standard storage fail.
If you attempt to change the storage class of an object manually during a rewrite or copy operation, the overall operation succeeds. However, the storage class change is ignored, and the object is always set to Standard storage.
Most objects transition to progressively colder storage classes if they're not accessed.
By default, the terminal storage class for Autoclass is Nearline storage, which means objects transition to Nearline storage and remain in that storage class until they're accessed. Optionally, you can configure Autoclass so that the terminal storage class is Archive storage.
Objects smaller than 128 KiB don't transition to colder storage classes. Instead, they are permanently stored in Standard storage. Only object data, not object metadata, is considered when determining whether the object is smaller than 128 KiB.
Soft-deleted objects retain their existing storage classes until the end of their retention duration.
When an object's data is read, the object transitions to Standard storage if it's not already stored in Standard storage.
When a soft-deleted object is restored, the resulting object begins in Standard storage, regardless of the storage class of the soft-deleted object.
All storage and operation charges for objects managed by Autoclass are billed using Autoclass-specific SKUs.
Cloud Storage pricing for Autoclass-enabled buckets has the following exceptions:
Autoclass configurations can be enabled, disabled, or modified for an existing bucket.
Changes to the Autoclass configuration can take up to one day to go into effect, and Cloud Storage might continue to perform actions based on the earlier configuration during this time.
When you enable Autoclass on an existing bucket, the following occurs:
All objects in the bucket, except soft-deleted objects, transition to Standard storage.
Note: The storage class reported for individual objects might not immediately show Standard storage after Autoclass is enabled. This delay has no effect on the Autoclass pricing for such objects or on the start of their 30-day period.Objects already in Standard storage at the time you enable Autoclass are treated as if they just transitioned to Standard storage. As a result, such objects need another 30 days of no access before they are eligible to transition to Nearline storage.
There is a one-time Autoclass enablement charge. For more information, see Autoclass charges.
When you disable Autoclass on an existing bucket, the following occurs:
When you change the terminal storage class in your Autoclass configuration, the following occurs:
If you change the terminal storage class from Archive storage to Nearline storage, objects in Archive storage and Coldline storage at the time of your change transition to Nearline storage.
If you change the terminal storage class from Nearline storage to Archive storage, objects in Nearline storage at the time of your change are treated as if they just transitioned to Nearline storage. As a result, such objects need another 60 days of no access before they transition to Coldline storage.
When enabled, Autoclass reduces the amount of data management you need to do and eliminates certain charges that apply for other buckets. Autoclass is a useful feature to enable for the following general access patterns:
However, Autoclass is not recommended if the majority of your bucket's data fits into the use cases of specific storage classes. For example, say your bucket has two use cases: some data is accessed weekly while some data is backup data that is never meant to be accessed. In this scenario, Autoclass is not recommended if you know which objects fall into each of those use cases.
Autoclass is also not recommended if other Google Cloud services regularly read data from the bucket. For example, Autoclass is not recommended if you use Sensitive Data Protection to scan the content of your bucket.
Transition behaviorOnce Autoclass is enabled, objects at least 128 KiB in size transition between storage classes as follows:
If an object's data is accessed, the object transitions to Standard storage.
Any object that isn't accessed for 30 days transitions to Nearline storage.
get
object method. Other types of methods, such as copy
object and rewrite
object, don't update the last accessed timestamp.
If the bucket is configured to use Nearline storage as the terminal storage class, Autoclass only changes the state of an object stored in Nearline storage if that object is accessed.
If the bucket is configured to use Archive storage as the terminal storage class, objects continue to transition to colder storage classes as follows:
Any object that isn't accessed for 90 days transitions to Coldline storage. Such objects spent at least 30 days in Standard storage and 60 days in Nearline storage.
Any object that isn't accessed for 365 days transitions to Archive storage. Such objects spent at least 30 days in Standard storage, 60 days in Nearline storage and 275 days in Coldline storage.
Autoclass only changes the state of an object stored in Archive storage if that object is accessed.
Once an object becomes eligible to transition between storage classes, Cloud Storage performs the transition asynchronously, so there can be a lag between when an object is eligible for transition and when the transition actually occurs.
A bucket cannot have both Autoclass enabled and either of the following in a Object Lifecycle Management configuration:
SetStorageClass
action.matchesStorageClass
condition.Requests that would cause a bucket to have both Autoclass enabled and one of these Object Lifecycle Management rules fail.
Because object composition requires the source objects and the composed object to all use the same storage class, composing an object in an Autoclass bucket fails unless all source objects are stored as Standard storage at the time of the composition request.
You can't use Autoclass on a bucket with hierarchical namespace enabled.
The following storage metrics are available in Monitoring to track storage class transitions:
autoclass/transition_operation_count: The number of storage class transitions initiated by Autoclass, excluding transitions that occurred as part of enabling Autoclass.
autoclass/transitioned_bytes_count: The total number of bytes transitioned by Autoclass, excluding bytes transitioned as part of enabling Autoclass.
Optionally, both metrics can be grouped by the source or destination storage class involved in transitions.
Important: Objects in Standard storage are reported asREGIONAL
if they are stored in a region and as MULTI-REGIONAL
otherwise.
For a guide to tracking metrics with Monitoring, see Create charts with Metrics Explorer.
Additionally, you can monitor the number of bytes stored in each storage class over time for you Autoclass-enabled buckets by going to the bucket's Configuration tab in the Google Cloud console and clicking See Performance.
What's nextExcept as otherwise noted, the content of this page is licensed under the Creative Commons Attribution 4.0 License, and code samples are licensed under the Apache 2.0 License. For details, see the Google Developers Site Policies. Java is a registered trademark of Oracle and/or its affiliates.
Last updated 2025-10-02 UTC.
[[["Easy to understand","easyToUnderstand","thumb-up"],["Solved my problem","solvedMyProblem","thumb-up"],["Other","otherUp","thumb-up"]],[["Hard to understand","hardToUnderstand","thumb-down"],["Incorrect information or sample code","incorrectInformationOrSampleCode","thumb-down"],["Missing the information/samples I need","missingTheInformationSamplesINeed","thumb-down"],["Other","otherDown","thumb-down"]],["Last updated 2025-10-02 UTC."],[],[]]
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.5