はじめに

Azure NetApp Files（以下、ANF）は、Windows と Linux の双方から高性能なファイル共有を利用できるマネージドサービスです。ストレージ基盤の運用負荷を抑えられる点も特長です。本記事では、ANF でファイル共有環境を構築し、プロトコルごとの接続、Active Directory（AD）連携、Cool アクセス、ランサムウェア対策（ARP）を検証した結果と、設計・運用上のポイントを紹介します。

01. Azure NetApp Files とは ― 3 階層構造を理解する

ANF は、Azure のデータセンター内に設置された NetApp のストレージ基盤を、Azure のマネージドサービスとして利用できるサービスです。ハードウェアやストレージ基盤の運用をサービス側に任せながら、高性能なファイル共有を構築できます。レイテンシや構築時間は、ワークロードや構成に応じて評価することが大切です。

ANF のリソースは、NetApp アカウント、容量プール、ボリュームの 3 階層で構成されます。NetApp アカウントの配下に容量プールを作成し、その容量をボリュームに割り当てます。

階層	役割	ポイント
NetApp アカウント	リージョン単位の管理コンテナ	AD 連携設定もこの配下に紐付く。1 アカウント = 1 AD 接続
容量プール（Capacity Pool）	容量を TiB 単位で確保する領域	Service Level（Standard / Premium / Ultra 等）と QoS タイプを決定
ボリューム（Volume）	実際にマウントする共有領域	プロトコル・サイズ・スナップショット・ARP をここで設定

プロトコルは設計段階で確定する
ボリュームのプロトコル（SMB / NFS / Dual-protocol）は作成後に変更できません。利用するクライアントとアクセス要件を整理し、構築前に決めておきます。

02. プロトコルと Active Directory 連携の設計

ANF のボリュームは、用途に応じて NFS・SMB・Dual-protocol から選びます。今回のように Kerberos や LDAP を使わない NFS 単体の構成では AD 連携は不要です。一方、SMB と Dual-protocol では AD 連携が必要です。NFSv4.1 Kerberos など、NFS でも AD 接続を必要とする構成があります。

仕様参照：Active Directory 接続の要件

形態	主な用途	AD 連携
NFS 単体	Linux クライアントから利用。最もシンプル	今回の構成では不要（Kerberos / LDAP 利用時は別途確認）
SMB 単体	Windows クライアントから利用	必須
Dual-protocol	Windows / Linux 双方からアクセス	必須

SMB / Dual-protocol ボリュームを使う場合、AD 連携は NetApp アカウント単位で設定し、対象ボリュームを作成する前に済ませます。今回の検証では、次の 2 段階で処理を確認しました。

今回の検証では、AD 連携の設定と、ボリューム作成に伴う AD・DNS への登録は別の段階で進みました。

検証所見：AD 連携の時点では AD/DNS にオブジェクトは作成されない

今回の検証では、NetApp アカウントに AD を紐付けた時点で、AD のコンピューターオブジェクトや DNS の A / PTR レコードは確認できませんでした。ボリュームの作成後に登録を確認しています。連携設定の直後に「何も作成されていない」ように見えても、それだけで連携失敗とは判断できません。

AD 連携の確認方法
AD / DNS のオブジェクトの有無だけでなく、AD のセキュリティログで認証記録を確認します。さらに、ボリュームの作成とマウントまで行い、接続できることを確かめます。

03. Cool アクセスでコストを最適化する

ANF の Cool アクセスは、一定期間アクセスのないデータを、高速な Hot 層から Azure ストレージの Cool 層へ自動的に移動し、ストレージコストの最適化を図る仕組みです。容量プール側で有効化し、ボリューム単位で挙動を設定します。費用は容量だけでなく、読み出しやデータ移動も含めて評価します。

Cool アクセスの動作は、主に 3 つの設定で決まります。Coolness Period はデータを Cool 層へ移動するまでの非アクセス期間で、2〜183 日の範囲で指定でき、既定値は 31 日です。Tiering Policy は移動するデータの範囲を、Retrieval Policy は Cool 層のデータを読み出したときの動作を指定します。各設定はワークロードのアクセス特性に合わせて選びます。

仕様参照：Coolness Period と階層化ポリシー

Tiering Policy ― Cool 層へ移動するデータの範囲

ポリシー	対象データ	推奨用途
Auto	アクティブファイルシステム＋スナップショット両方。Coolness Period 経過後に移動	汎用（既定）
SnapshotOnly	スナップショットのブロックのみ。アクティブ FS は Hot 層に残す	バックアップ・長期保管系

Retrieval Policy ― Cool 層のデータを読み出したときの動作

ポリシー	挙動	推奨用途
Default	シーケンシャル read は Cool 層から直接読み込み、ランダム read のみ Hot 層へ再格納	多くの汎用ワークロード
On-Read	読み込みパターンに関係なく、アクセスされたブロックはすべて Hot 層へ戻る	傾向変化直後にレイテンシを抑えたい用途
Never	Cool 層から直接読み出し、読み出しによって Hot 層へ戻さない	アーカイブ志向のワークロード

検証所見
Cool 層への移動は、Azure Monitor のメトリック「Volume cool tier size」で確認しました。画面だけで判断せず、メトリックを使って階層化の状態を確認します。

04. ランサムウェア対策（ARP）の検証と運用上の注意点

Advanced Ransomware Protection（ARP）は、ボリュームのファイル拡張子、データのエントロピー、IOPS などを分析し、通常とは異なる振る舞いを検知する機能です。大量のファイル変更や不審な拡張子などを手掛かりに、脅威の疑いを知らせます。新規・既存のボリュームで有効化でき、一時停止・再開・無効化も可能です。

不審な活動を検知すると、ARP は保護用のリカバリスナップショットを自動取得し、Azure の監視チャネルに通知します。実際の運用では、次の 3 点を設計に織り込む必要があります。

通知先まで含めて設計します。Azure Activity Log のイベントを起点に、アラートルールと Action Group（アクショングループ）を組み合わせ、メールなどの連絡手段につなぐ構成を別途用意します。
検知までの時間を実環境で確認します。今回の検証では 5〜10 分程度を要しました。これは本検証環境での観測値であり、サービス全体の検知時間を示すものではありません。自社のデータや操作パターンでも確認が必要です。
復旧の判断と実行は運用者が担います。スナップショットは自動取得されますが、脅威の確認、復旧ポイントの選択、リストアの手順は別途整備します。

検知から復旧までの流れ

検知から復旧までは、①振る舞いを検知 → ②保護スナップショットを取得 → ③「アクティブな脅威」を確認 → ④運用者が脅威か偽陽性かを判定 → ⑤必要に応じて適切なスナップショットから復旧、という流れです。ARP 画面は Volume → Storage services → Advanced Ransomware Protection から開きます。

Action Group で通知を構成する

Activity Log に記録される脅威検知イベントを条件にアラートルールを作成し、Action Group に関連付けます。検証記録ではイベント名を「DetectedSuspectVolumes」としていますが、ルール作成時には対象環境の実際のログで、イベント名・操作名・対象リソースを確認してください。Teams への通知は Logic Apps などを介して構成します。通知にはボリューム名と検知時刻を含め、重大度や夜間の連絡先を運用ルールに合わせて設定します。

ONTAP 版との比較で確認すること
検知の仕組みだけでなく、保護スナップショットの保持、脅威の判定、通知先、復旧操作を比較します。ANF では Azure の管理画面と監視機能を軸に運用し、ONTAP 版は対象製品・バージョンで使える操作を確認します。

ANF と ONTAP 版では、利用できる管理操作や運用方法が異なります。以下の比較図は検証時点の整理です。現在の ANF では保護スナップショットと偽陽性フィードバックによる学習が公式ドキュメントで説明されているため、図と併せて仕様の補足を確認してください。ONTAP 版は利用するバージョンと構成に応じて確認します。

公開時の仕様補足
ANF は保護用リカバリスナップショットを自動取得し、保持はサービスが管理します。また、偽陽性としての判定は学習の改善に使われます。下の旧比較図にある「通常スナップショットで代替」「偽陽性学習は非対応」は現行仕様の説明として扱わないでください。「99%+」も今回の検証で測定した精度ではありません。出典：Microsoft Learn：ARP の構成。

検証時点の比較図を参照する（上記の仕様補足あり）

05. ANF / AFF / Cloud Volumes ONTAP の使い分け

同じ NetApp のストレージでも、提供形態によって適した用途が異なります。Azure のマネージドサービスである ANF、オンプレミス向けのオールフラッシュストレージである AFF、クラウド VM 上で動作する Cloud Volumes ONTAP（CVO）の特徴を、代表的な観点で比較します。

容量上限の読み方
Cool アクセスで最大 7.2 PiB の Large volume を使うには登録が必要で、80%超のデータを Cool 層に置く条件があります。図中の性能・容量はすべての構成の保証値ではありません。出典：Cool アクセスの条件。

次のマトリクスは、要件ごとに 3 製品の適合度を整理したものです。検証チームの評価として、◎（第一選択）、◯（適合）、△（条件付きで適合）、✘（不向き）で示しています。

Azure 中心で基盤の運用負荷を抑え、高性能なファイル共有を利用したい場合は ANF、オンプレミスでブロックストレージも含めた構成を持ちたい場合は AFF、クラウド VM 上で ONTAP のデータ管理機能を活用したい場合は CVO、という整理になります。今回の「Azure 上で手早くファイル共有基盤を立てる」という検証には、ANF が適していました。

06. 検証環境と構築フロー

検証では、1 つの VNet 内に VM 用と ANF 用のサブネットを分け、NFS・SMB・Dual-protocol の 3 種類のボリュームを用意しました。ここでは、その環境構成と構築の流れを紹介します。

図 6　Japan East の検証環境：VNet、VM 用・ANF 用サブネット、3ボリューム

Japan East リージョンの VNet（172.17.0.0/16）に、Linux VM（Ubuntu 24.04）、Windows Server 2019、ANF 用の委任サブネットを配置しました。Windows Server は AD ドメインコントローラーを兼ねています。ANF アカウント配下には Standard の容量プールを 1 つ作成し、NFS（Volume 1）、SMB（Volume 2）、Dual-protocol（Volume 3）の各ボリュームを配置しました。NFS は Linux から、SMB は Windows からマウントし、Dual-protocol は両方のクライアントから接続を確認しました。

構築は、①事前準備、②NetApp アカウントの作成、③容量プールの作成、④ボリュームの作成、⑤マウントと動作確認の順に進めました。

構築を円滑に進めるうえで、特に重要だったのが最初の事前準備です。

構築前に確認する 3 つの項目

構築前に、次の 3 点を確認します。環境によって実施済みの項目や申請が不要な場合もあるため、対象サブスクリプションとリージョンの状態を確認してから進めます。

リソースプロバイダーの登録：対象サブスクリプションに Microsoft.NetApp を登録します。

az provider register --namespace Microsoft.NetApp

サブネットの委任：ANF 用サブネットに Microsoft.NetApp/volumes を委任します。
リージョンの利用可否：「Creation of 'netAppAccounts' has been restricted」が表示された場合は、Azure サポートに対象リージョンのアクセスを確認します。

アカウント作成後は AD 連携、スナップショットポリシー、バックアップを利用する場合のバックアップコンテナー（Backup vault）を整理します。今回の容量プールは Standard を使用しました。容量プールは最小 1 TiB・1 TiB 単位、通常ボリュームは最小 50 GiB・1 GiB 単位が基本です。Standard / Premium / Ultra のスループットは、それぞれ容量 1 TiB 当たり 16 / 64 / 128 MiB/s を基準とします。QoS、Cool アクセス、Flexible などの条件により計算方法が異なるため、選択する構成の仕様を確認します。

仕様参照：リソース上限／サービスレベル

07. 検証結果まとめと推奨事項

NFS・SMB・Dual-protocol のすべてでマウントを確認できました。Dual-protocol は Security Style を Unix に設定し、安定した動作を確認しています。Cool アクセスでは、設定した非アクセス期間の経過後にデータが Cool 層へ移動したことをメトリックで確認しました。ARP は疑似試験で検知を確認できた一方、検知までの時間と通知経路を含めた運用設計が必要だと分かりました。また、ボリューム作成後はプロトコルを変更できないため、構築前に利用要件を確定しておくことが重要です。

検証項目	結果	要点
ボリューム作成 / マウント	○	NFS・SMB・Dual-protocol すべて確認。Dual-protocol は Unix Security Style で安定
Cool アクセス階層化	○	Cool 層への移動をメトリックで確認
Advanced Ransomware Protection	△	検知は可能だが検証時は 5〜10 分のラグ。通知には Action Group を別途構成
プロトコルの後変更	△	作成後の変更は不可。設計段階での確定が必須

運用開始前に整理する設定

Network Features は Standard を使用します。2026 年 7 月以降、新規ボリュームで Basic を指定した場合も Standard が適用されます。既存の Basic ボリュームはこの変更の対象外です。
Service Level は性能と費用の要件に応じて選択します。今回の検証では Standard を使用しました。Cool アクセスは容量プール側で有効化してから、ボリュームの設定を行います。
Dual-protocol の Security Style はアクセス権の設計に合わせて選択します。今回の検証では Unix で動作を確認しました。SMB の Access Based Enumeration と SMB3 暗号化も、利用要件に応じて検討します。
ARP は新規・既存のボリュームで有効化できます。検知後に担当者へ通知が届くよう、アラートルールと Action Group を併せて設計します。
スナップショットポリシーは、必要な復旧ポイントに合わせて時間・日・週・月単位のスケジュールを組み合わせます。保持する世代数は、それぞれの周期で設定します。

ANF は、Azure 上でストレージ基盤の運用負荷を抑えながら、高性能なファイル共有を構築する際の有力な選択肢です。プロトコルの選択、NetApp アカウント単位の AD 接続、ARP の通知・復旧手順まで設計しておくことで、検証結果を実運用につなげやすくなります。本記事がその設計判断の一助になれば幸いです。

08. 参考ドキュメント

Azure NetApp Files documentation ↗

Register the NetApp resource provider ↗

Network features (Standard vs Basic) ↗

Configure cool access for a volume ↗

Configure advanced ransomware protection ↗

Active Directory connections ↗

本記事は社内検証の結果をもとに記載したものです。仕様や画面は変更される場合があるため、最新の公式ドキュメントをご確認ください。

# 検証レポート

Azure NetApp Files を検証してわかったこと