Tiering data to object storage is not recommended when using Throughput Optimized HDDs (st1).

BlueXP creates a single S3 bucket for each working environment and names it fabric-pool-cluster unique identifier. A different S3 bucket is not created for each volume.

When BlueXP creates the S3 bucket, it uses the following default settings:

If you don't plan to access the inactive data, you can reduce your storage costs by changing the storage class to one of the following: Intelligent Tiering, One-Zone Infrequent Access, Standard-Infrequent Access, or S3 Glacier Instant Retrieval. When you change the storage class, inactive data starts in the Standard storage class and transitions to the storage class that you selected, if the data is not accessed after 30 days.

The access costs are higher if you do access the data, so take that into consideration before you change the storage class. Amazon S3 documentation: Learn more about Amazon S3 storage classes.

You can select a storage class when you create the working environment and you can change it any time afterwards. For instructions on changing the storage class, refer to Tiering inactive data to low-cost object storage.

The storage class for data tiering is system wide—​it's not per volume.

BlueXP creates a new storage account with a container for each Cloud Volumes ONTAP working environment. The name of the storage account is random. A different container is not created for each volume.

BlueXP creates the storage account with the following settings:

If you don't plan to access the inactive data in the capacity tier, you can choose the cool storage tier, where the inactive data is retained for a minimum of 30 days. You can also opt for the cold tier, where the inactive data is stored for a minimum of 90 days. Based on your storage requirements and cost considerations, you can select the tier that best suits your needs. When you change the storage tier to cool or cold, the inactive capacity tier data moves directly to the cool or cold storage tier. The cool and cold tiers offer lower storage costs compared to the hot tier, but they come with higher access costs, so take that into consideration before you change the storage tier. Refer to Microsoft Azure documentation: Learn more about Azure Blob storage access tiers.

You can select a storage tier when you create the working environment and you can change it any time afterwards. For details about changing the storage tier, refer to Tiering inactive data to low-cost object storage.

The storage access tier for data tiering is system wide—​it's not per volume.

BlueXP creates a bucket for each working environment and names it fabric-pool-cluster unique identifier. A different bucket is not created for each volume.

When BlueXP creates the bucket, it uses the following default settings:

The access costs are higher if you do access the data, so take that into consideration before you change the storage class. To learn more, refer to Google Cloud documentation: Storage classes.

You can select a storage tier when you create the working environment and you can change it any time afterwards. For details about changing the storage class, refer to Tiering inactive data to low-cost object storage.

The storage class for data tiering is system wide—​it's not per volume.

If read, cold data blocks on the capacity tier become hot and are moved to the performance tier.

If read, cold data blocks on the cloud tier stay cold and are not written back to the performance tier. This policy is available starting with ONTAP 9.6.

This policy is supported starting with Cloud Volumes ONTAP 9.4.

If read by random reads, the cold data blocks in the capacity tier become hot and move to the performance tier. If read by sequential reads, such as those associated with index and antivirus scans, the cold data blocks stay cold and do not move to the performance tier.