You are grappling with explosive data growth—yet not all data is equal. Some datasets are “hot” and frequently accessed, while others quietly age into “cold” data that sits idle but still consumes expensive storage. How can you pay less for data that isn’t accessed often, or is so old you don’t even know what it is but you are afraid to delete it?
Google Cloud NetApp Volumes (GCNV) addresses this challenge with auto-tiering, now available with the Flex Unified service level, enabling you to balance performance and cost automatically.
Auto-tiering provides:
- Cost Savings: Automatically move inactive data to lower-cost storage (up to ~70% savings).
- Performance Optimization: Hot data and metadata always resides in high-performance storage.
- Operational Simplicity: There is no manual lifecycle management, only policy-driven automation.
- Flexibility at Scale: Configure pool-level resource efficiency with volume-level policy control.
This article breaks down how auto-tiering works, what makes it powerful in Flex Unified, and how it helps optimize your storage footprint costs.
Understanding Flex Unified Service Level
The Flex Unified service level brings together file (NFS/SMB) and block (iSCSI, NVMe/TCP) workloads into a single storage pool, simplifying operations and eliminating silos.
Flex unified allows you to:
- Consolidate storage across workloads
- Scale capacity and performance independently
- Run mixed workloads without managing separate storage systems
- Offer different availability to different applications with zonal or regional pools
What is Auto-Tiering?
Auto-tiering is a policy-driven data placement mechanism that automatically moves data between two internal tiers:
- Hot tier (performance tier): high-performance, higher-cost storage
- Cold tier (capacity tier): lower-cost, lower-performance storage
The system continuously monitors data access patterns and makes decisions based on actual usage. When enabled, the frequently accessed (“hot”) data stays in the performance tier and the Infrequently accessed (“cold”) data is moved to the cost-efficient tier. For iSCSI volumes, auto-tiering applies only to snapshot data. Used blocks from the LUN won't be tiered, regardless of how often they are read. This helps ensure consistent latency.
To remain in the performance tier, data must be accessed randomly based on a time frame you configure. This design prevents sequential operations, such as virus scans or backups, from inadvertently keeping data in the hot tier.
This movement is automatic based on a cooling period you configure, transparent to applications, and it is granular to the data level. Although you configure when to move the data based on a cooling period, your applications are none the wiser. If the data is randomly accessed while in the cold tier, it moves back to the hot tier and the cooling period starts over again.
Within Flex Unified, hot-tier capacity is allocated at the storage pool level, meaning the total hot tier is shared between all volumes in the pool. An auto increase feature is also provided, allowing the hot tier to grow when it gets close to capacity to prevent out of space errors in the hot tier. Auto-increase is also shared across all volumes in the pool.
Configuring Auto-tiering on the storage pool:
At the same time, data lifecycle behavior (like cooling) is controlled independently per volume, giving fine-grained workload-level control and not all volumes in the pool must enable Auto-tiering at all - that is completely up to you.
Configuring Auto-tiering on the volume:
How Auto-Tiering Works Step by Step
Although the below steps continually run, applications continue to see a single unified volume with a complete dataset. Applications are unaware of tiering, and no application changes are required.
1. Data is Written to the Hot Tier
All new data is initially written to the hot tier to ensure optimal performance, unless hot-tier bypass is configured. Hot-tier bypass is covered later in this article.
2. Cooling Threshold Defines “Cold” Data (Per Volume)
Each volume has its own configurable cooling threshold, which determines when data becomes eligible for tiering. You can set this up while creating the volume and it is adjustable after volume creation. A range of 2 to 183 days is supported, with a default of 31 days. Since each threshold is configured per volume, each workload (e.g a DB vs archive) can have different aging policies even if they share the same pool-level hot-tier pool.
3. Access Patterns Are Continuously Analyzed
GCNV tracks the frequency of reads/writes, the type of access (random vs. sequential) and the time since the last access. This ensures tiering decisions reflect actual workload behavior.
4. Cold Data Moves to the Cold Tier
Once data exceeds the cooling threshold, the system automatically moves it from the pool’s hot tier to the cold tier.
Since this process runs periodically, [find out how long] it can reduce storage costs significantly, often up to almost 80% for cold data.
5. Data is Rehydrated When Accessed
If cold data is accessed again the system analyzes whether it is random reads or sequential reads. If it is random reads, the data is moved back to hot tier. If it is sequential read (e.g. virus scans, backups), the data will stay in the cold tier.
This ensures performance is restored only when needed.
6. Hot Tier Auto-Increase
When enabled, the hot tier auto-increase is invoked when the hot tier is almost full. It increases your hot tier by 10%, thereby ensuring your newly written data has space.
Why The Pool vs Volume Model Matters
The separation between pool-level performance (hot tier) and volume-level policies (cooling thresholds) is a powerful architectural advantage. It allows us to share the performance efficiency, where all volumes can draw from the same hot-tier storage pool. This enables better overall utilization of the hot tier and the pool. At the same time, the granular data lifecycle control allows each volume to define its own cooling behavior. This mechanism aligns with workload specific SLAs and access patterns.
Real-World Example
|
Volume Type |
Cooling Threshold |
Behavior |
|
Database volume |
90 days |
Data stays hot longer for performance |
|
User file share |
31 days |
Standard cooling |
|
Archive dataset |
2 days |
Aggressive cost optimization |
All of these volumes share the same hot tier storage pool, but behave differently based on per-volume policies.
This is key compared to traditional tiering models that are rigid or pool-wide.
Hot Tier Bypass: A Tool for Migration and Archival
The Flex Unified service offers a per-volume option called Hot Tier Bypass that is crucial for specific scenarios, such as initial data migration and data archival.
This feature directs all incoming writes to bypass the hot tier and be stored directly in the cold tier. This prevents large initial writes of potentially cold data from filling the hot tier or triggering an unintended hot-tier auto-increase. After the data is migrated, the data is moved back to the hot tier upon the first random read access. This feature can be disabled after the initial migration is complete to resume normal auto-tiering behavior.
Configuring Hot tier bypass:
Monitoring Data Tiering and Utilization
Understanding the distribution of your data between the hot and cold tiers is crucial for optimizing your configuration. GCNV integrates with Google Cloud’s comprehensive monitoring tools to provide detailed visibility into your auto-tiering behavior through Google Cloud Metrics Explorer and Volume observability. Additionally, gcloud commands may also be used to determine the amount of storage in the cold tier vs the hot tier.
1. Google Cloud Metrics Explorer
You can observe the data in the cold and hot tiers using Google Cloud Metrics Explorer.
- Filter: Filter on `NetApp storage pool autotiering`.
- Metrics: Track the number of `autotiered bytes in the cold` tier and the data residing in the hot tier.
- Granularity: By setting the view to unaggregated and filtering by name, you can see the tiering metrics individually per storage pool or volume.
2. Volume Observability UI
For quick, volume-specific insights, the Cloud Console provides an Observability tab on the volume details page. This tab shows a predefined dashboard with key metrics, including a dedicated chart for hot tier versus cold tier capacity for that specific volume. For example, this shows inactive data moving from the hot tier to the cold tier.
3. Volume Auto-Tiering Tab
Once auto-tiering is turned on for a volume, the auto-tiering tab is enabled on that volume UI output. The hot tier capacity, hot tier data, cold tier data, cooling threshold, and total volume capacity can be observed on this tab.
4. Google SDK
Additionally, gcloud commands may also be used to determine the amount of storage in the cold tier vs the hot tier.
~$gcloud netapp volumes describe autotier --location=us-central1-a
capacityGib: '2048'
coldTierSizeGib: '747'
createTime: '2026-05-08T20:00:30Z'
encryptionType: SERVICE_MANAGED
exportPolicy:
rules:
- accessType: READ_WRITE
allowedClients: 0.0.0.0/0
hasRootAccess: 'true'
kerberos5ReadOnly: false
kerberos5ReadWrite: false
kerberos5iReadOnly: false
kerberos5iReadWrite: false
kerberos5pReadOnly: false
kerberos5pReadWrite: false
nfsv3: true
nfsv4: false
squashMode: NO_ROOT_SQUASH
hotTierSizeUsedGib: '14'
labels:
creator: patd
mountOptions:
- export: /autotier
exportFull: 10.165.128.234:/autotier
instructions: |-
Setting up your instance
Open an SSH client and connect to your instance.
Install the nfs client on your instance.
On Red Hat Enterprise Linux or SuSE Linux instance:
sudo yum install -y nfs-utils
On an Ubuntu or Debian instance:
sudo apt-get install nfs-common
Mounting your volume
Create a new directory on your instance, such as "/autotier":
sudo mkdir /autotier
Mount your volume using the example command below:
sudo mount -t nfs -o rw,hard,rsize=65536,wsize=65536,vers=3,tcp 10.165.128.234:/autotier /autotier
Note. Please use mount options appropriate for your specific workloads when known.
ipAddress: 10.165.128.234
protocol: NFSV3
name: projects/cvs-pm-host-1p/locations/us-central1-a/volumes/autotier
network: projects/565.../global/networks/shared-vpc-prod
protocols:
- NFSV3
serviceLevel: FLEX
shareName: autotier
state: READY
stateDetails: Available for use
storagePool: newautotiertest
tieringPolicy:
coolingThresholdDays: 2
hotTierBypassModeEnabled: false
tierAction: ENABLED
usedGib: '760'
zone: us-central1-a
This approach—granular volume insights via the Observability UI tab and the extensive analytical capabilities of the Metrics Explorer, Google SDK and the volume auto-tiering tab ensures complete visibility into your storage performance and cost optimization.
What now?
Auto-tiering in the Flex Unified service level is more than just a cost optimization feature—it’s a smart data placement engine.
By combining pool-level hot tier performance with volume-level cooling intelligence, you achieve efficient shared infrastructure using pool level hot tier performance with volume level cooling intelligence. This combination delivers the best of both worlds, efficient shared infrastructure and fine-grained workload control.
The result is a system that automatically adapts to your data, so you don’t have to.
Try it out for yourself! Learn more about Google Cloud NetApp Volumes today!
