はじめに
以前携わった案件にてAzure NetApp Files（以降ANF）を構築する機会がありました。その際は何となく構築しただけでしたが、改めてANFについて整理したいと思い、本記事にてまとめます。なお、ANFの基本的な設定・利用方法については、弊社メンバーの記事が参考になりますのでご参照ください。
ANFとは
ANFは、NetApp（ONTAP）をベースとした、マネージドファイルストレージサービスです。高いパフォーマンスを提供するONTAPをマネージドサービスとして利用できる点が特徴です。ANFの主な特徴は以下の通りです。
- 高いストレージ性能：ANFは高いストレージ性能を兼ね備えており、最大スループットは4,500 MiB/秒にも達します。また、プレビュー機能ではありますが、ブレイクスルーモードでは最大50 GiB/秒のスループットを実現します
- マルチプロトコル対応：ONTAPの代表的な特徴です。 ANFは、NFS／SMB／デュアルプロトコル（NFS+SMB）に対応しており、LinuxとWindowsの混在環境においてもデータ共有が可能です。
- フルマネージドPaaS：ONTAPのOS・ハードウェア管理はAzureが行うため、ユーザー側で意識する必要はありません。
その他にも様々な特徴や機能があります。詳細は以下を参照ください。
ANFのユースケース
ANFの主要なユースケースとしては、以下のようなものがあります。
- 高いパフォーマンスを要求するアプリケーション（HPC、EDA等）
- VDI（Azure Virtual Desktop、Citrix等）
- AKSの共有ストレージ
- 機械学習
ONTAPとの違い
マネージドサービスのため、OS・ハードウェア管理等をAzureに任せることができる反面、通常のONTAPと比べて機能に制限があります。以前、AWSのFSx for NetApp Ontapを検証したことがありますが、ANFはクラウド側で隠蔽している範囲がかなり広い印象です。特に、ONTAP CLIやSystem Managerは利用できないため、細かな設定をしたい場合はマッチしない可能性があります、ANFで実現できない機能としては、以下のようなものがあります。
- iSCSI対応：ANFはNAS専用のためブロックストレージとしての利用はサポートされていません
- SnapLock：SnapLock（WORM）は未提供のためコンプライアンス要件がある場合は注意が必要です
- SnapMirror：ANF間のSnapMirror（CRR／CZR）は提供されていますが、他ONTAPとのSnapMirrorは提供されません
その他にも、利用したい機能がANFで対応しているかについては事前に確認しておくことをおすすめします。
ANFのストレージ階層
ANFには、次のようなストレージ階層があります。
※公式ドキュメントより抜粋
上図からわかる通り、ANFとしての基本コンポーネントは以下の3つです。
- NetAppアカウント
- 容量プール
- ボリューム
NetAppアカウント
NetAppアカウントは、ANFリソース全体の最上位コンテナです。設定項目もシンプルで、入れ物としての役割であることが分かります。
容量プール
容量プールは ANF における容量とパフォーマンスを購入・管理する単位です。ボリュームはすべていずれかの容量プールに属し、容量プールの設定によってボリュームのパフォーマンスが決定されます。
容量プールは、ANFにおいて非常に重要なリソースのため各設定値を掘り下げます。
Pool name
その名の通り、容量プールの名前です。
Service level
Service level（サービスレベル）の設定により、ボリュームのスループット上限が決定されます。
| Service level | スループット上限（1TiBあたり） |
|---|---|
| Standard | 16 MiB/s |
| Premium | 64 MiB/s |
| Ultra | 128 MiB/s |
| Flexible | 任意 |
※プレビュー機能としてElasticというサービスレベルも存在します
ボリュームの適用されるサービスレベルを変更したい場合は、変更したいサービスレベルの容量プールを事前に作成しておき、ボリュームを移動することで変更が可能です。ボリュームの移動は既存のアクセスに影響を与えずに実施できます。
Size（TiB）
容量プールのサイズです。最小で1TiBから設定が可能です。サイズは1TiB単位で後からサイズ変更することができます。（縮小も可）
容量プール内のすべてのボリュームが後述するStandardネットワーク機能を使用している場合のみ、1TiBの最小サイズを利用できます。その他、リソース制限については構築前に確認しておくことを推奨します。
Cool access
Cool Access を使うと、アクセス頻度の低い（コールド）データをANFのストレージ（ホットティア）から Azure Storage アカウント（クールティア）へ自動的に移動させることができます。ONTAPのFabricPoolに相当するANF独自の自動階層化機能となります。
実際のクール期間（2〜183日）については、ボリュームの設定画面から指定します。
QoS type
QoSは、ボリュームに割り当てるスループット上限の管理方法を決める設定です。AutoとManualの2種類から選択します。後から、Auto → Manualの変更はできますが逆はできません。
- Auto QoS：ボリュームのスループット上限が以下の計算式で自動的に決まります
スループット上限 = ボリュームクォータ（TiB）× Service level係数
| Service level | 係数 | 例：4TiB ボリュームの場合 |
|---|---|---|
| Standard | 16 MiB/s | 4 × 16 = 64 MiB/s |
| Premium | 64 MiB/s | 4 × 64 = 256 MiB/s |
| Ultra | 128 MiB/s | 4 × 128 = 512 MiB/s |
- Manual QoS：容量プールのバジェット（総スループット）をボリューム単位で任意に配分します
バジェット = 容量プールサイズ（TiB）× Service level係数
例としてUltra 8TiBの容量プールであれば 8 × 128 = 1,024 MiB/sが総バジェットになり、これを各ボリュームに自由に配分できます。
Encryption type
ボリュームに適用する暗号化方式を選択します。暗号化方式は後から変更できません。
- Single：ソフトウェアレベルの暗号化のみ
- Double：ソフトウェア + ハードウェアレベルの二重暗号化
ボリューム
ボリュームは実際にクライアントがマウントするファイルシステムです。ボリュームはいずれかの容量プールに属します。
ボリュームの主な仕様は以下の通りです。
- サイズ：50GiB〜100TiB（ただし、容量プールのサイズは越えられません）
- シンプロビジョニングのため、実際に書き込まれたデータ量のみが容量プールの消費量にカウントされます
- プロトコル（NFS v3／NFS v4.1／SMB 3.x／Dual Protocol）はボリューム作成時に選択し、後から変更することはできません
- ボリュームは委任されたサブネットに作成されます（サブネットにはいくつかの制限があり、事前に構成が必要です）
ネットワーク機能
ボリューム作成時にネットワーク機能という設定を行います。「基本」と「Standard」の2種類から選ぶことができますが、特別な理由がない限りは「Standard」を選択することが推奨です。「Standard」でないと、NSG・UDRが適用できないなどの制限がありますし、料金の差異はないため「基本」を選ぶ理由がほとんどありません。「基本」と「Standard」の違いは、以下のドキュメントをご参照ください。
Active Directory接続
プロトコルとして、SMBボリューム・NFSv4.1 Kerberos・Dual Protocolを利用する場合は、事前にActive Directory（AD）接続の設定が必要です。ADDS（Active Directory Domain Services）とMicrosoft Entra Domain Servicesの両方をサポートしています。
AD接続はNetAppアカウントレベルで設定します。主な設定項目は以下の通りです。
- Primary/Secondary DNS：ADドメインのDNSサーバIPアドレス
- AD DNS Domain Name：ANFと連携するADのFQDN（例：contoso.com）
- AD Site Name：ANFがドメインコントローラを探索する際に使用するADサイト名
- SMB Server Prefix：ANFがADDSに作成するコンピュータアカウントの名前プレフィックス
- OU パス：コンピュータアカウントを作成するOU（省略時はデフォルトOU）
基本はADDSを選択することが多いのではないかと思います。ADDSを接続する場合、委任されたサブネットからADDSが接続可能である必要があります。
レプリケーション
ANFにはリージョン間・ゾーン間のレプリケーション機能が提供されています。内部的にはSnapMirror技術が使われていますが、ユーザーはAzure PortalやAPIを通じて操作します。事前に機能登録が必要なようですが、異なるサブスクリプション間のレプリケーションにも対応しているようです。
Cross-Region Replication（CRR）
異なるAzureリージョン間でボリュームを非同期レプリケーションする機能です。リージョン障害に対するDR（ディザスタリカバリ）用途に利用します。
- レプリケーションスケジュール：10分・毎時間・毎日から選択
- フェイルオーバー：手動操作が必要
- 課金：レプリケーションした実データ量（GiB）に対して課金 + 宛先ボリュームの容量プール費用
Cross-Zone Replication（CZR）
同一リージョン内の異なる可用性ゾーン間でボリュームをレプリケーションする機能です。ゾーン障害に対するビジネス継続性確保を目的としています。
- レプリケーションスケジュール：10分・毎時間・毎日から選択
- フェイルオーバー：手動操作が必要
- 課金：データレプリケーション自体の追加コストなし（宛先の容量プール費用のみ）
価格
ANFの価格は以下を参照ください。
監視
ANFの監視には主に以下の手段が提供されています。
Azure Monitor（メトリクス）
容量プールやボリュームのメトリクスをAzure Monitor経由で確認できます。監視できるメトリクスは、以下にまとまっています。
アクティビティログ
ANFに対するPUT・POST・DELETE操作はすべてAzureアクティビティログに記録されます。「誰がいつスナップショットを作成したか」「ボリュームを変更したのは誰か」といった操作履歴を追跡できます。
ファイルアクセスログ
ボリューム単位でファイルシステム操作（読み書き・削除等）のログを有効化することができます。
データ保護
スナップショット
スナップショットはボリュームのポイントインタイムなファイルシステムイメージです。スナップショットはデータブロックをコピーせず、既存ブロックへのポインターによって実現されています。スナップショットはボリューム内に保存されます。1ボリュームあたり最大255本まで保持できます。
スナップショットからのリストアには以下の3種類があります。
| 方法 | 内容 |
|---|---|
| ファイルの復元 | ボリュームの「.snapshot」ディレクトリからユーザー自身が直接ファイルをコピーして復元 |
| ボリュームの復元 | ボリューム全体を指定スナップショットの時点に巻き戻す（以降のデータは失われ、元に戻せない） |
| 新しいボリュームの作成 | スナップショットを元に新規ボリュームを作成 |
バックアップ
バックアップは、ボリュームスナップショットとは独立した形で長期保存・アーカイブ・コンプライアンス対応を実現するフルマネージドバックアップ機能です。スナップショット（最大255本）では賄えない長期保存ニーズに対応します。バックアップしたボリュームは、同一リージョン内の新しいボリュームとして復元可能です。
バックアップが有効なボリュームでは、スナップショットによるボリュームの復元は利用できないため注意が必要です。
https://learn.microsoft.com/ja-jp/azure/azure-netapp-files/snapshots-revert-volume#considerations
ランサムウェア保護（ARP）
Advanced Ransomware Protection（ARP）は、ANFに組み込まれたAI駆動のランサムウェア検知・保護機能です。（2026/3/30時点ではPreview）
ARPはボリュームレベルで動作し、以下のステップで保護します。
- ベースライン学習：有効化後、ボリュームの通常の利用パターンを機械学習で学習します
- 継続的な異常検知：学習したベースラインと照らし合わせながら、ランサムウェアに似た挙動（大量のファイル拡張子変更等）をリアルタイムで検知します
- スナップショットの自動作成：脅威が検知されると、その時点でイミュータブル（変更・削除不可）なスナップショットを自動的に作成します
- アラート通知：Azure Monitor・アクティビティログ経由で管理者に通知します。攻撃レポートは30日間保存されます
脅威が検知された場合、管理者は内容を確認し、問題があると判断したらスナップショットからボリュームを復元できます。
さいごに
ANFの基本的な概念や機能についてまとめてみました。ざっくりと全体感は理解ができたような気がします。手が空いたときに、色々と実機で検証しながら理解を深めていきたいです。