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.
Overview
When 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.
- Reading or editing an object's metadata does not cause the object to transition to 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.
Pricing
Cloud Storage pricing remains the same for Autoclass-enabled buckets, with the following exceptions:
- Retrieval fees are never charged.
- Early deletion fees are never charged.
- All operations are charged at the Standard storage rate.
- There is no operation charge when Autoclass transitions an object to a colder storage class.
- There is no Class A operation charge when Autoclass transitions an object from Nearline storage to Standard storage.
- When Autoclass transitions an object from Coldline storage or Archive storage to Standard storage or Nearline storage, each such transition incurs a Class A operation charge.
- A management fee and enablement charge apply when using Autoclass.
Autoclass for existing buckets
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.
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:
- Each object remains stored in whichever storage class it has at the time Autoclass is disabled. You can subsequently change an object's storage class as you would for non-Autoclass buckets.
- The Autoclass pricing structure no longer applies.
- Autoclass cannot be re-enabled on the bucket until one day has elapsed. Attempts to do so fail.
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.
Should you use Autoclass?
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:
- Your data has a variety of access frequencies.
- The access patterns for your data are unknown or unpredictable.
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 behavior
Once 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.
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.
- During this period, the object continues to be billed using its pre-transition storage class, except in the case of transitions to Standard storage that occur as a result of enabling Autoclass.
Restrictions
A bucket cannot have both Autoclass enabled and either of the following in a Object Lifecycle Management configuration:
- A rule that uses the
SetStorageClass
action. - A rule that uses the
matchesStorageClass
condition.
Requests that would cause a bucket to have both Autoclass enabled and one of these Object Lifecycle Management rules fail.
- A rule that uses the
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.
Monitoring storage class usage and transitions
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.
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 next
- Enable Autoclass.
- Learn about Object Lifecycle Management.