Merge pull request #312251 from netapp-manishc/toc-restructure

Updating TOC as per TME

Author: v-shils

articles/azure-netapp-files/TOC.yml

@@ -7,13 +7,61 @@ ms.service: azure-netapp-files
 ms.topic: concept-article
 ms.date: 01/13/2026
 ms.author: anfdocs
+ms.custom: references_regions
 # Customer intent: "As a data engineer, I want to understand the advanced ransomware protection features of Azure NetApp Files, so that I can safeguard the cloud file data against ransomware attacks."
 ---
 
 # Understand Azure NetApp Files advanced ransomware protection (preview)
 
 Advanced ransomware protection (ARP) in Azure NetApp Files is a built-in capability that helps safeguard your cloud file data against ransomware attacks. It uses intelligent, AI-driven monitoring to detect unusual file activity in real time and automatically creates a secure snapshot of your data when a potential ransomware threat is detected. This approach provides an extra line of defense at the storage layer – preserving clean recovery points and minimizing data loss if ransomware encrypts your files, without requiring any external appliances or software.
 
+## Supported regions 
+
+- Australia Central 
+- Australia Central 2 
+- Australia East 
+- Australia Southeast 
+- Brazil South 
+- Brazil Southeast 
+- Canada Central 
+- Canada East 
+- Central India 
+- Central US 
+- East Asia 
+- East US 
+- East US 2 
+- France Central 
+- Germany North 
+- Germany West Central 
+- Israel Central 
+- Italy North 
+- Japan East
+- Japan West 
+- Korea Central 
+- Korea South
+- New Zealand North 
+- North Central US 
+- North Europe 
+- Norway East
+- Norway West 
+- Qatar Central 
+- South Africa North 
+- South Central US
+- South India
+- Southeast Asia 
+- Spain Central 
+- Sweden Central 
+- Switzerland North 
+- Switzerland West 
+- UAE Central 
+- UAE North 
+- UK South 
+- UK West 
+- West Europe 
+- West US 
+- West US 2 
+- West US 3 
+
 ## Why do we need advanced protection?
 
 Ransomware attacks have become a serious and growing threat to organizations of all sizes. Attackers continually evolve methods to infiltrate environments (for example, through phishing emails or zero-day exploits) and can silently encrypt critical files, halting business operations. Traditional security measures such as firewalls, email filters, and anti-malware software do their best to prevent infections, but sophisticated ransomware can slip through these defenses. Once data is encrypted by malware, companies face an awful choice, either lose valuable data or pay a hefty ransom with no guarantee of recovery.
@@ -100,28 +148,6 @@ Advanced ransomware protection provides several clear benefits for organizations
 
 Advanced ransomware protection brings peace of mind: even if ransomware manages to infiltrate your environment, your Azure NetApp Files shares are not left defenseless. The capability gives you a fighting chance to detect and disarm a ransomware attack in progress, with minimal or even no data loss. This can save your organization from costly downtime, potential ransom payments, or reputational damage associated with data breaches.
 
-## Considerations and usage guidelines
-
-Before using advanced ransomware protection, there are a few important points and limitations to understand:
-
-* **Enrollment per volume**: You must explicitly enable advanced ransomware protection on each volume that you want protected – it is not “on” by default. This can be done easily using the Azure portal (a toggle option in the volume settings) or through the Azure API/CLI by setting the ransomware protection property on the volume. Only volumes with advanced ransomware protection enabled will be monitored and automatically snapshotted on threats.
-
-* **Storage capacity planning**: Advanced ransomware protection’s automatic snapshots use your existing Azure NetApp Files volume capacity ensuring sufficient space for at least one extra snapshot per protected volume. Actual storage used depends on data changes before a snapshot. Advanced ransomware protection itself has no additional cost or separate SKU, but may increase storage usage as protection snapshots are created. Monitor your volumes and capacity pools to manage capacity during ransomware events.
-
-* **Operational visibility**: When advanced ransomware protection triggers, it logs alerts in Azure NetApp Files events and Azure Monitor. Make sure your operations team is monitoring these channels or has set up automated alert rules, so that a ransomware alert isn't missed. Treat an advanced ransomware protection alert as urgent, investigate the possibly compromised client or user account immediately, since the snapshot indicates suspicious activity was indeed happening. Early investigation can help you contain the threat (for example, by isolating a VM or revoking credentials) while the snapshot protects your data.
-
-* **Data restoration process**: In the event of a real ransomware attack, the recommended recovery method is to revert the entire volume to the protected snapshot using Azure NetApp Files’ restore capability. This essentially turns back the clock on that volume to the pre-attack state captured by the snapshot. Volume revert is very fast (usually seconds) regardless of volume size. If a full revert isn't desirable (say other parts of the volume had important recent changes you want to keep), you can also mount the snapshot as a new volume or use the single-file restore from snapshot capability to copy back only selected files that were encrypted. Azure NetApp Files gives flexibility in recovery, but in all cases the snapshot ensures you do not have to rebuild data from scratch.
-
-* **Coexistence with other protection features**: Advanced ransomware protection is designed to complement, not replace, existing data protection features like scheduled snapshots, backups, and cross-region replication. We recommend using advanced ransomware protection alongside a robust backup strategy. For example, you might keep daily snapshots and weekly backups for general data recovery and compliance, while advanced ransomware protection watches for the exceptional case of ransomware in between those scheduled snapshots and backups. Advanced ransomware protection also works in tandem with Azure’s security services, for instance, you might get an alert from Microsoft Defender for Storage or an antivirus at around the same time. Using multiple layers of defense is the best practice for comprehensive protection.
-
-* **User access and permissions**: Only subscription owners or contributors with the right Azure role can enable or disable advanced ransomware protection on a volume. 
-
-* **Immutable protection snapshots**: When an advanced ransomware protection snapshot is created, remember that its immutability is a crucial safeguard as the protection snapshots are designed to be read-only, ensuring they cannot be altered or deleted even by privileged accounts. While this locked-down design keeps your backup safe from tampering or further ransomware attempts, it’s still essential to strictly control who can access and restore from these snapshots. Use Azure NetApp Files’ integration with Azure RBAC to restrict snapshot recovery permissions to only a trusted group of administrators.
-
-* **Testing the feature**: It’s a good idea to become familiar with how advanced ransomware protection works by testing it in a non-production environment. You might simulate a ransomware-like workload (for example, encrypt a set of test files on a volume) to see how and when an alert is generated and how the snapshot and restore process works. Testing helps validate your operational runbooks for responding to advanced ransomware protection alerts, so in a real incident everyone knows what to do. Keep in mind that the detection algorithms might not trigger on every possible change – they're tuned to catch common ransomware patterns – so avoid trying this in a way that could create false confidence. Microsoft’s internal testing has covered many scenarios, but real-world validation in your environment is valuable too.
-
-By considering these aspects, you can deploy advanced ransomware protection effectively and be prepared to use it when needed. The capability significantly strengthens the resiliency of your Azure NetApp Files volumes against one of the most damaging types of cyberattacks today. With it enabled, you gain a dependable recovery fallback that operates automatically, letting you focus on preventing attacks and running your business – and knowing that if ransomware strikes, Azure NetApp Files advanced ransomware protection has you covered with a rapid, storage-integrated response.
-
 ## Conclusion
 
 Advanced ransomware protection for Azure NetApp Files is a conceptual game-changer for data protection in the cloud file storage space. It extends the Azure NetApp Files platform with an AI-powered ability to detect ransomware threats from within and respond instantly by securing your data. In practice, this means: your critical file shares are continuously watched for danger; if encryption malware sneaks in, the service itself will catch the abnormal pattern and shield your data by creating a protection snapshot and issuing an alarm. You can then quickly restore your files to the uninfected state and eliminate the malware – avoiding costly downtime and ransom payments.

articles/azure-netapp-files/advanced-ransomware-protection.md

@@ -31,21 +31,21 @@ The Flexible, Standard, Premium, and Ultra service levels deliver in‑Azure bar
     For more information including a review of the available features, see [Understand Elastic zone-redundant storage](elastic-zone-redundant-concept.md).
 
 
-* <a name="Flexible"></a>Flexible service level:
+* <a name="Flexible"></a>**Flexible service level**:
     The Flexible service level enables you to adjust throughput and size limits independently. You can use the Flexible service level to create high-capacity volumes with low throughput requirements or the reverse: low-capacity volumes with high throughput requirements. The Flexible service level is designed for demanding applications such as Oracle or SAP HANA.
 
     The minimum throughput you can assign a Flexible capacity pool is 128 MiB/second regardless of the pool quota. The maximum throughput is 5 x 128 MiB/second/TiB x the size of the capacity pool in TiB. For more information, see [Flexible service level throughput examples](#flexible-examples) and [considerations for the Flexible service level](azure-netapp-files-set-up-capacity-pool.md#considerations).
 
     >[!IMPORTANT]
     >The Flexible service level is only supported for new _manual QoS_ capacity pools.
 
-* <a name="Standard"></a>Standard service level:   
+* <a name="Standard"></a>**Standard service level**:   
     The Standard service level provides up to 16 MiB/s of throughput per 1 TiB of capacity provisioned.   
 
-* <a name="Premium"></a>Premium service level:   
+* <a name="Premium"></a>**Premium service level**:   
     The Premium service level provides up to 64 MiB/s of throughput per 1 TiB of capacity provisioned. 
 
-* <a name="Ultra"></a>Ultra service level:   
+* <a name="Ultra"></a>**Ultra service level**:   
     The Ultra service level provides up to 128 MiB/s of throughput per 1 TiB of capacity provisioned. 
 
 ### Storage with cool access

articles/azure-netapp-files/azure-netapp-files-service-levels.md

@@ -0,0 +1,90 @@
+---
+title: Requirements and considerations for Azure NetApp Files cache volumes
+description: Understand the considerations and requirements for Azure NetApp Files cache volumes. 
+services: azure-netapp-files
+author: netapp-manishc
+ms.service: azure-netapp-files
+ms.topic: concept-article
+ms.date: 03/09/2026
+ms.author: anfdocs
+ms.custom: references_regions
+---
+# Requirements and considerations for Azure NetApp Files cache volumes
+
+Before you configure [cache volumes](configure-cache-volumes.md), make sure that you understand the requirements for each option. 
+
+## Requirements and considerations
+
+* Cache volumes are currently only supported with the REST API (new caches endpoint).
+* The Azure NetApp Files cache volume must be deployed in an availability zone. To populate a new or existing volume in an availability zone, see [Manage availability zones in Azure NetApp Files](manage-availability-zone-volume-placement.md). 
+* When creating a cache volume, ensure that there's sufficient space in the capacity pool to accommodate the new cache volume.
+* You should ensure that the protocol type is the same for the cache volume and origin volume. The security style and the Unix permissions are inherited from the origin volume. For example, creating a cache volume with NFSv3 or NFSv4 when origin is UNIX, and SMB when the origin is NTFS.
+* You should enable encryption on the origin volume.
+* The source cluster must be running ONTAP 9.15.1 or later version.
+* You should configure an Active Directory (AD) or LDAP connection within the NetApp account to create an LDAP-enabled cache volume.
+* You can't move a cache volume to another capacity pool.
+* The `globalFileLocking` parameter value must be the same on all cache volumes that share the same origin volume. Global file locking can be enabled when creating the first cache volume by setting `globalFileLocking` to true. The subsequent cache volumes from the same origin volume must have this setting set to true. To change the global file locking setting on existing cache volumes, you must update the origin volume first. After updating the origin volume, the change propagates to all the cache volumes associated with that origin volume. The `volume flexcache origin config modify -is-global-file-locking-enabled` command should be executed on the source cluster to change the setting on the origin volume.
+* The volume security style for a cache volume is inherited from the external ONTAP origin volume only at creation time and is not a configurable parameter on a cache volume. If the security style is changed on the external origin volume, the cache volume must be deleted and recreated with the correct protocol choice to align to the security styles.
+
+    | Origin Volume Security Style |  Cache volume protocol |  Resultant cache volume security style |
+    |-|-|-|
+    | UNIX  | NFS  |  UNIX |
+    | NTFS  | SMB  | NTFS  |
+    | MIXED  | NFS or SMB  |  MIXED (unsupported) |
+
+   >[!NOTE]
+   >MIXED security style coming from the origin volume configuration will be inherited by the cache volume but is unsupported in Azure NetApp Files if file access issues arise.
+  
+
+### Networking considerations 
+
+* Cache volumes only support Standard network features. Basic network features can't be configured on cache volumes. 
+* The delegated subnet address space for hosting the Azure NetApp Files volumes must have at least seven free IP addresses: six for cluster peering and one for data access to one or more cache volumes.
+    * Ensure that the delegated subnet address space is sized appropriately to accommodate the Azure NetApp Files network interfaces. Review the [guidelines for Azure NetApp Files network planning](azure-netapp-files-network-topologies.md) to ensure you meet the requirements for delegated subnet sizing.
+* When creating each cache volume, the Azure NetApp Files volume placement algorithm attempts to reuse the same Azure NetApp Files storage system as any previously created cache volumes in the subscription to reduce the number of network interface cards (NICs)/IPs consumed in the delegated subnet. If this isn't possible, another 6+1 NICs are consumed.
+* You can't use the same source cluster for multiple subscriptions for creating cache volumes in the same availability zone in the same region.
+* When creating a cache volume, subnets need to be specified for the cache volume (cacheSubnetResourceId) and for cluster peering (peeringSubnetResourceId). 
+    * The same subnet can be specified for both cache volume and cluster peering (but the subnet must have the Microsoft.Netapp/volumes delegation).
+    * When different subnets are used, each subnet needs to be on a different VNET and each subnet must have the Microsoft.Netapp/volumes delegation.
+
+### Write-back considerations 
+
+If you're enabling write-back on the external origin volume:
+
+* You must be running ONTAP 9.15.1P5 or later on the system hosting the external origin volume. 
+* Each external origin system node has at least 128 GB of RAM and 20 CPUs to absorb the write-back messages initiated by write-back enabled caches. This is the equivalent of an A400 or greater. If the origin cluster serves as the origin to multiple write-back enabled Azure NetApp Files cache volumes, it requires more CPUs and RAM.
+* Testing is executed for files smaller than 100 GB and WAN roundtrip times between the cache and origin not exceeding 100 milliseconds. Any workloads outside of these limits might result in unexpected performance characteristics.
+* The external origin must remain less than 80% full. Cache volumes aren't granted exclusive lock delegations if there isn't at least 20% space remaining in the origin volume. Calls to a write-back-enabled cache are forwarded to the origin in this situation. This helps prevent running out of space at the origin, which would result in leaving dirty data orphaned at a write-back-enabled cache.
+
+### Interoperability considerations 
+
+You can't use cache volumes if the following features are configured on the origin or cache: 
+
+>[!NOTE]
+> File Access Logs (FAL) for cache volumes isn't currently supported. Although diagnostic settings might be available for cache volumes, enabling diagnostic settings on a cache volume to configure File Access Logs has no effect.
+
+#### Unsupported features
+
+The following features can't be used with Azure NetApp Files cache volumes:
+
+* Application volume groups
+* Azure NetApp Files backup
+* Cross-region, cross-zone, and cross-zone-region replication
+* FlexCache disaster recovery
+* NFSv4.2
+* Ransomware protection
+* Snapshot policies
+* S3 Buckets
+
+#### Supported features
+
+The following features are supported with cache volumes:
+
+* Availability zone volume placement
+* Customer-managed keys
+* Lightweight Directory Access Protocol (LDAP)
+* NFSv3 and NFSv4.1, SMB, and dual-protocol (NFS and SMB)
+* Kerberos
+
+>[!NOTE]
+>You can't transition noncustomer managed key cache volumes to customer managed key.

articles/azure-netapp-files/cache-requirements.md

@@ -104,6 +104,7 @@ Cache volumes are supported in the following regions:
 
 ## Next steps
 
+- [Requirements and considerations for cache volumes](cache-requirements.md)
 - [Configure a cache volume for Azure NetApp Files](configure-cache-volumes.md)
 
 For more details, visit Configure a cache volume for Azure NetApp Files.