AWS FSx for WindowsをOCIでどこまで再現できるかやってみた

はじめに

NTT西日本の山塚です。普段はOCIを活用したインフラ設計・構築に携わっています。

AWSには「Amazon FSx for Windows File Server」というフルマネージドのWindowsファイルサーバーサービスがあります。SMB共有、Active Directory連携、自動バックアップ、マルチAZ構成など、Windowsファイルサーバーに必要な機能が揃っており、数クリックで構築できる便利なサービスです。

一方、OCIには同等のマネージドサービスがありません（2026年3月時点）。

「OCIでもFSx for Windowsのようなことはできないのか」という声をきっかけに、OCIの既存サービスを組み合わせてFSx for Windowsの主要機能をどこまで再現できるかを検証してみました。

※私個人としてもActive Directoryをあまり触ったことがなかったため、これを機に学んでみようという想いもありました。

本記事では、基本的なファイル共有機能だけでなく、マルチAZ相当の可用性構成やフルマネージド相当の運用自動化まで、可能な限りの再現に挑戦しました。さらに、実際に疑似的に障害を発生させて、どこまで自動復旧できるのかを検証した結果もまとめます。

この記事は2026年3月時点の情報に基づきます。本記事の内容は筆者個人の検証・見解であり、所属組織の公式見解・推奨構成を示すものではありません。

---

対象読者

本記事は、以下の方を対象としています。

• OCI環境でWindowsファイルサーバーの構築・運用を検討しているエンジニア
• AWSのFSx for WindowsをOCI上で代替できるか調査している方
• DFS-R/DFS-Nを活用したマルチリージョン冗長構成に興味のある方
• クラウド間のサービス比較・移行検討をされている方

前提知識：

本記事では、以下の知識があることを前提としています。

• OCIのコンソール操作とCompute Instanceの基本的な作成
• Windows Server（PowerShell操作、役割・機能の追加）の基本操作
• Amazon FSx for Windows File Serverの基本的な概念

---

背景・目的

OCI環境を主に利用している場合、AWS上のFSx for Windows File Serverに相当するマネージドサービスは存在しません。しかし、OCIのCompute InstanceやBlock Volume、OS Management Hubといった既存サービスを組み合わせることで、類似の機能を自前で構築できる可能性があります。

本記事の目的は、FSx for Windowsの主要機能（SMB共有・Active Directory連携・バックアップ・マルチAZ相当の可用性・フルマネージド相当の運用自動化）をOCI上で再現し、その再現度・コスト・運用工数を定量的に評価することです。

なお、本記事で取り上げる再現度の評価は、筆者が今回の検証で確認した機能の範囲に限ったものです。FSx for Windowsのすべての機能を網羅的に検証したものではなく、AWSがマネージドサービスとして内部で担保している詳細な実装についても評価対象外としています。

---

目次

1. FSx for Windowsの主要機能を整理する
   • FSx for Windowsの前提条件
   • 検証対象とする機能
   • FSx for Windowsの本質的な価値
2. OCI再現構成の設計
   • 段階的なアプローチ
   • 最終構成図
   • 使用するOCIサービス
3. Phase 1：基本構成の構築
4. Phase 2：FSx相当機能の実装
5. Phase 3：マルチリージョン構成
6. Phase 4：フルマネージド相当の運用自動化
7. Phase 5：障害検証
8. 検証結果：各機能の再現度
9. コスト比較
10. まとめ
11. 構築時のトラブルシューティング

---

1. FSx for Windowsの主要機能を整理する

1.1 FSx for Windowsの前提条件

FSx for WindowsはActive Directoryへの参加が必須です。単体では動作しません。

AWSでFSxを使う場合、以下のいずれかのADが必要です。

ADの種類	管理者	特徴
AWS Managed Microsoft AD	AWS	フルマネージド、パッチ適用も自動
Self-Managed AD	ユーザー	EC2やオンプレミスで自前構築

今回のOCI構成では、FSxを動かすための土台としてADサーバーも自前で構築します。ただし、検証の主眼はあくまでFSxの機能再現であり、ADの機能検証ではありません。

図1. Amazon FSx for Windows File Server — AWSコンソールの作成画面

1.2 検証対象とする機能

FSx for Windowsには多くの機能がありますが、今回は以下の主要機能に着目して検証を行いました。

カテゴリ	機能	概要
ファイル共有	SMB（Server Message Block）プロトコル	SMB 2.0〜3.1.1対応
ファイル共有	SMB暗号化	転送中のデータを暗号化
認証・アクセス制御	Active Directory連携	ドメインユーザーでの認証
認証・アクセス制御	Windows ACL（Access Control List）	NTFS（NT File System）アクセス権限
認証・アクセス制御	ABE（Access-Based Enumeration）	権限のないファイルを非表示
データ保護	シャドウコピー（VSS）	「以前のバージョン」での復元
データ保護	自動バックアップ	日次バックアップ
データ保護	保管時暗号化	ストレージの暗号化
パフォーマンス	データ重複排除	ストレージ効率化
可用性	マルチAZ構成	自動フェイルオーバー
運用	フルマネージド	パッチ適用をAWSが自動実行

1.3 FSx for Windowsの本質的な価値

FSx for Windowsの価値は、機能面だけではありません。以下をすべてAWSが担当してくれるという点にあります。

AWSが担当すること	内容
構築	コンソールから数クリックで完了
パッチ適用	メンテナンスウィンドウで自動実行
障害検知	CloudWatchで自動監視
障害復旧	マルチAZで自動フェイルオーバー
バックアップ	日次自動バックアップ
ハードウェア管理	完全にAWS側で管理

FSxのパッチ適用について

FSx for Windowsでは、パッチ適用のタイミング（曜日・時間）はメンテナンスウィンドウで指定できますが、パッチを適用しないという選択はできません。14日以内にメンテナンスが実行されない場合、セキュリティと信頼性を確保するためにAWSがパッチ適用を続行します。（2026年3月時点の情報。詳細はAWS公式ドキュメントをご確認ください。）

一方、OCI構成では「パッチを当てるかどうか」も含めてユーザーが判断できます。

今回の検証では、これらのマネージド部分も可能な限り再現することに挑戦し、実際に障害を発生させて自動復旧の挙動を確認しました。

---

2. OCI再現構成の設計

2.1 段階的なアプローチ

検証は以下の5つのPhaseに分けて実施しました。

Phase	内容	目的
Phase 1	基本構成	SMB共有、AD連携の実現
Phase 2	FSx相当機能	VSS、暗号化、ABE、重複排除の実装
Phase 3	マルチリージョン	マルチAZ相当の可用性を実現
Phase 4	運用自動化	フルマネージド相当の運用を実現
Phase 5	障害検証	実際に障害を起こして自動復旧を検証

2.2 最終構成図

図2. OCI上に構築したFSx再現構成の全体図

今回は上記の構成で検証しています。構成図にはプライベートサブネットからインターネットへの外向き通信に使用するNATゲートウェイも含まれています。

2.3 使用するOCIサービス

FSx機能	OCI対応サービス
ファイルサーバー	Compute Instance（Windows Server 2022）
ストレージ	Block Volume
Active Directory	Compute Instance（AD DS役割）
バックアップ	Block Volume Backup Policy
暗号化	Block Volume暗号化（デフォルト有効）
マルチAZ	マルチリージョン（ + DFS-R（Distributed File System Replication））
監視	OCI Monitoring + Alarms
パッチ適用	OS Management Hub

再現をするにあたってインスタンスを始めとする上記サービスを用いて検証を実施しました。

---

3. Phase 1：基本構成の構築

このPhaseのゴール

FSx for Windowsの核心は「ADと連携したSMBファイル共有」です。Phase 1ではこの最小構成を東京リージョンに立ち上げます。OCIにはマネージドADサービスがないため、ADサーバー自体もCompute Instanceで自前構築するのがポイントです。

Phase 1では、FSx for Windowsの最も基本的な機能である「Active Directoryと連携したSMBファイル共有」をOCIで再現します。

3.1 構成概要

今回の東京リージョンの構成は以下の通りです。ADサーバーとファイルサーバーをそれぞれ別のインスタンスとして用意し、Block Volumeをファイル保存用のストレージとして使用します。

リソース	スペック	IPアドレス	役割
ADサーバー	VM.Standard.E5.Flex（2OCPU（Oracle Compute Unit） / 16GB）	10.0.3.10	ユーザー認証を担当
ファイルサーバー	VM.Standard.E5.Flex（4OCPU / 32GB）	10.0.3.20	ファイル保存・共有を担当
Block Volume	100GB（Balanced）	-	ファイル保存用ストレージ
ドメイン名	fsx-poc.local	-	AD管理単位の名前

3.2 ネットワーク（VCN）の作成

サーバーを動かすには、まずネットワーク基盤が必要です。OCIでは「VCN（Virtual Cloud Network）」を作成します。

リソース	設定値	用途
VCN	10.0.0.0/16	サーバーを配置する仮想ネットワーク
サブネット	10.0.3.0/24（プライベート）	サーバーを配置するセグメント
NAT Gateway	-	プライベートサブネットからインターネットへの外向き通信用

ポイント

プライベートサブネットを使うことで、サーバーがインターネットから直接アクセスされることを防ぎます。セキュリティの基本です。

3.3 ADサーバーの構築

FSx for WindowsはActive Directoryと連携してユーザー認証を行います。FSxでは「AWS Managed AD」が利用できますが、OCIにはこのサービスがないため、自分でADサーバーを構築します。

AD DSのインストール

Windows ServerにActive Directory機能を追加します。

# Active Directoryドメインサービス（AD DS）をインストール
# -IncludeManagementTools で管理ツールも一緒にインストール
Install-WindowsFeature -Name AD-Domain-Services -IncludeManagementTools

新規フォレストの作成

ADドメインを新規作成します。「フォレスト」はADの最上位の管理単位です。

# ローカルAdministratorにパスワードを設定
# ドメイン作成時、このアカウントがドメイン管理者になるため必須
net user Administrator "**********"

# ドメイン復旧モード用のパスワードを設定
$SafeModePassword = ConvertTo-SecureString "**********" -AsPlainText -Force
Install-ADDSForest `
    -DomainName "fsx-poc.local" `           # ドメインのDNS名
    -DomainNetbiosName "FSXPOC" `           # 短縮名（FSXPOC\userのように使う）
    -ForestMode "WinThreshold" `            # Windows Server 2016以降の機能を有効化
    -DomainMode "WinThreshold" `
    -InstallDns:$true `                     # DNSサーバーも一緒にインストール
    -SafeModeAdministratorPassword $SafeModePassword `
    -Force:$true

注意

ドメイン作成後のログインはFSXPOC\Administrator（ドメイン管理者）で行います。ローカルのAdministratorではログインできなくなります。

3.4 ファイルサーバーの構築

ドメイン参加

ファイルサーバーをADドメインに参加させます。ドメインに参加することで、ドメインユーザーにファイルアクセス権限を設定できるようになります。

# DNSサーバーをADサーバーに向ける
# ドメイン名「fsx-poc.local」を解決するにはADのDNSが必要
$adapterIndex = (Get-NetAdapter | Where-Object {$_.Status -eq "Up"}).ifIndex
Set-DnsClientServerAddress -InterfaceIndex $adapterIndex -ServerAddresses "10.0.3.10"

# ドメインに参加（再起動が必要）
Add-Computer -DomainName "fsx-poc.local" -Credential (Get-Credential) -Restart

3.5 Block Volumeの追加

ファイルを保存するための追加ストレージを接続します。OCIでは「Block Volume」を作成し、iSCSI（Internet Small Computer System Interface）でサーバーにアタッチします。

# iSCSI Initiatorサービスを自動起動に設定
# Block VolumeはiSCSIプロトコルで接続する
Set-Service -Name msiscsi -StartupType Automatic
Start-Service msiscsi

# iSCSI接続（OCIコンソールで表示されるコマンドを使用）
# -IsPersistent $true で再起動後も自動的に再接続される
Connect-IscsiTarget `
    -NodeAddress "iqn.2015-12.com.oracleiaas:xxxxxxxx" `
    -TargetPortalAddress 169.254.2.2 `
    -IsPersistent $true

重要

-IsPersistent $trueを忘れると、再起動時にディスクが消えたように見えます。必ず指定してください。

# ディスクをGPT形式で初期化
Initialize-Disk -Number 1 -PartitionStyle GPT

# パーティションを作成してDドライブに割り当て
New-Partition -DiskNumber 1 -UseMaximumSize -DriveLetter D

# NTFSでフォーマット
Format-Volume -DriveLetter D -FileSystem NTFS -NewFileSystemLabel "FileData" -Confirm:$false

図3. ディスクの管理画面 — Block VolumeがDドライブとして認識された状態

3.6 SMB共有の作成

Block Volumeをアタッチしただけでは、他のコンピューターからアクセスできません。「SMB共有」を作成することで、ネットワーク経由でファイルにアクセスできるようになります。

# フォルダ構造を作成
New-Item -Path "D:\Shares\Common" -ItemType Directory -Force

# SMB共有を作成
# -FullAccess: フルコントロール（すべての操作が可能）
# -ChangeAccess: 変更権限（読み書き可能、権限変更は不可）
New-SmbShare -Name "Common" `
    -Path "D:\Shares\Common" `
    -FullAccess "FSXPOC\Domain Admins" `
    -ChangeAccess "FSXPOC\Domain Users" `
    -Description "共通ファイル共有"

図4. エクスプローラーからSMB共有（\\FS01\Common）へのアクセスが成功した状態

---

4. Phase 2：FSx相当機能の実装

このPhaseのゴール

Phase 1で「ファイルを置ける」状態になりました。Phase 2では、FSx for Windowsが標準で備えている付加価値機能、特にデータ保護（VSS・バックアップ）、セキュリティ（SMB暗号化・ABE）、ストレージ効率化（重複排除）をWindows Server標準機能とOCIサービスで再現します。これらはFSxでは「デフォルトで有効」または「数クリック」で済む機能ですが、OCI構成では一つひとつ手動で有効化・検証する必要があります。

Phase 1で基本的なファイル共有ができました。Phase 2では、FSx for Windowsが標準で提供する追加機能を実装します。

4.1 シャドウコピー（VSS）の設定

シャドウコピーは、ファイルの「スナップショット」を定期的に取得する機能です。ユーザーがファイルを誤って削除・上書きした場合、「以前のバージョン」から復元できます。

FSx for Windowsではデフォルトで有効ですが、OCI構成では手動で設定します。

# シャドウコピー用の領域を確保
# Dドライブの10GBをシャドウコピー保存用に使用
vssadmin resize shadowstorage /for=D: /on=D: /maxsize=10GB

# 動作確認用にシャドウコピーを手動作成
vssadmin create shadow /for=D:

# 定期実行のスケジュールタスクを作成（毎日7:00と12:00）
$trigger1 = New-ScheduledTaskTrigger -Daily -At 7:00AM
$trigger2 = New-ScheduledTaskTrigger -Daily -At 12:00PM
$action = New-ScheduledTaskAction -Execute "vssadmin" -Argument "create shadow /for=D:"
$principal = New-ScheduledTaskPrincipal -UserId "SYSTEM" -LogonType ServiceAccount

Register-ScheduledTask -TaskName "VSS-ShadowCopy-D" `
    -Trigger $trigger1,$trigger2 `
    -Action $action `
    -Principal $principal

図5. 設定済みシャドウコピーの一覧（スケジュール実行分を含む）

VSSの動作確認

実際にファイルを復元できることを確認しました。

# 1. テストファイル作成
"Original content - 2026/03/23 08:10" | Out-File "D:\Shares\Common\vss-test.txt"

# 2. シャドウコピー作成
vssadmin create shadow /for=D:

# 3. ファイルを変更
"Modified content - 2026/03/23 08:11" | Out-File "D:\Shares\Common\vss-test.txt"

# 4. シャドウコピーから復元
$shadowCopyPath = "\\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy4\Shares\Common\vss-test.txt"
Copy-Item -LiteralPath $shadowCopyPath -Destination "D:\Shares\Common\vss-test.txt" -Force

# 5. 復元後の内容確認 → "Original content" に戻っていることを確認
Get-Content "D:\Shares\Common\vss-test.txt"

項目	結果
シャドウコピー作成	成功
以前のバージョンから復元	成功（Modified → Original に復元）

4.2 Windows ACLの設定

補足

Windows ACL（NTFS権限）はNTFSでフォーマットされたボリューム上であれば標準で利用できます。今回の検証では、3.5節でNTFSフォーマットしたDドライブ上に共有フォルダを作成しており、ACLは既に機能している状態です。個別の権限設定の検証は4.4節のABE動作確認の中で実施しています（admin-onlyフォルダへのアクセス制御をNTFS権限で設定）。

4.3 SMB暗号化の有効化

サーバーとクライアント間の通信を暗号化します。社内ネットワークでも、データの盗聴を防ぐために有効化しておくことが推奨されます。

# サーバー全体でSMB暗号化を有効化
# SMB 3.0以降のクライアントとの通信が暗号化される
Set-SmbServerConfiguration -EncryptData $true -Force

設定確認：

Get-SmbServerConfiguration | Select-Object EncryptData, RejectUnencryptedAccess

項目	値
EncryptData	True
RejectUnencryptedAccess	True

4.4 ABE（Access-Based Enumeration）の有効化

ABEを有効にすると、ユーザーがアクセス権限を持たないファイルやフォルダが一覧に表示されなくなります。「見えるけど開けない」という状況を防げます。

# Common共有でABEを有効化
Set-SmbShare -Name "Common" -FolderEnumerationMode AccessBased -Force

ABEの動作確認

Domain Adminsのみアクセス可能なフォルダを作成し、一般ユーザー（testuser01）から見えないことを確認しました。

Administratorで見えるフォルダ（7個）：

admin-only/
dedup-test/
dfsn-test.txt
replication-test.txt
test.txt
testuser01.txt
vss-test.txt

testuser01で見えるフォルダ（6個）：

dedup-test/
dfsn-test.txt
replication-test.txt
test.txt
testuser01.txt
vss-test.txt

項目	結果
ABE有効化前	admin-only が見える
ABE有効化後	admin-only が見えない ✓

4.5 データ重複排除の有効化

同じデータが複数のファイルに含まれている場合、1つだけ保存して容量を節約する機能です。特に、Office文書やVMイメージなど似たファイルが多い環境で効果を発揮します。

# データ重複排除機能をインストール
Install-WindowsFeature -Name FS-Data-Deduplication -IncludeManagementTools

# Dドライブで有効化
Enable-DedupVolume -Volume "D:"

# 作成直後のファイルも対象にする（デフォルトは3日経過後）
Set-DedupVolume -Volume "D:" -MinimumFileAgeDays 0

重複排除の効果測定

同一ファイル（ntoskrnl.exe、約11MB）を10個コピーして効果を測定しました。

# テスト用に同じファイルを10個コピー
1..10 | ForEach-Object { 
    Copy-Item "C:\Windows\System32\ntoskrnl.exe" "D:\Shares\Common\dedup-test\copy$_.exe"
}

# 重複排除を即時実行
Start-DedupJob -Volume "D:" -Type Optimization -Wait

# 効果を確認
Get-DedupStatus -Volume "D:"

項目	値
最適化ファイル数	10個
元のサイズ	約110MB
節約容量	約104MB
節約率	約94%

図6. 重複排除実行後の状態 — 節約率94%（SavedSpaceが約104MB）を確認

4.6 保管時暗号化について

補足

OCIのBlock Volumeはデフォルトで保管時暗号化（AES-256）が有効になっており、ユーザーによる追加設定は不要です。今回の検証でも、Block Volumeを作成した時点で自動的に暗号化が有効な状態です。このため、個別の設定手順は省略しています。

4.7 バックアップポリシーの設定

OCIコンソールでBlock Volume Backup Policyを設定し、日次で自動バックアップを取得します。

1. ストレージ → ブロック・ボリューム → バックアップ・ポリシー
2. ポリシーを作成（日次、7日間保持）
3. Block Volume（bv-filedata）にポリシーを割り当て

図7. Block Volumeに割り当てたバックアップポリシーの設定内容（7日間保持）

バックアップからの復元テスト

実際にバックアップから復元できることを確認しました。

手順： 1. OCIコンソールでBlock Volumeバックアップから新しいボリュームを作成 2. FS01にiSCSIでアタッチ 3. Eドライブとしてマウント 4. データを確認

結果：

項目	Eドライブ（復元）	Dドライブ（現在）
ファイル数	4個	7個
admin-only	なし	あり（3/23作成）
dedup-test	なし	あり（3/23作成）
vss-test.txt	なし	あり（3/23作成）

バックアップ時点（3/20頃）のデータが正確に復元されました。

---

5. Phase 3：マルチリージョン構成

このPhaseのゴール

FSx for WindowsのマルチAZ構成は「同一リージョン内の2つのAZにファイルサーバーを分散配置し、障害時に自動フェイルオーバーする」という設計です。OCIの東京・大阪リージョンをはじめ多くのリージョンがシングルAD構成のため、これを再現するにはリージョンをまたいだ冗長化が必要になります。DRGによるリージョン間接続、DFS-Rによるファイル同期、DFS-N（Distributed File System Namespace）による透過的なアクセスパスの3点が連携して初めて成立する構成です。

FSx for WindowsのマルチAZ構成では、2つのAZにファイルサーバーを配置し、障害時に自動フェイルオーバーします。

OCIはほとんどのリージョンがシングルADのため、同等の可用性を実現するにはマルチリージョン構成が必要です。

5.1 構成概要

東京・大阪それぞれのリージョンにADサーバーとファイルサーバーを1台ずつ配置します。IPアドレスは以下の通りで、東京側がプライマリ、大阪側がスタンバイという役割分担です。

リージョン	ADサーバー	ファイルサーバー
東京	AD01（10.0.3.10）	FS01（10.0.3.20）
大阪	AD02（172.16.3.10）	FS02（172.16.3.20）

5.2 リージョン間接続（リモートVCNピアリング）

東京と大阪のVCNを接続し、プライベートネットワーク経由で通信できるようにします。

1. 東京・大阪それぞれにDRG（動的ルーティング・ゲートウェイ）を作成
2. リモートVCNピアリングで接続
3. ルートテーブルを更新

東京VCNのルート	大阪VCNのルート
172.16.0.0/16 → DRG	10.0.0.0/16 → DRG

図8. 東京-大阪間のリモートVCNピアリングが「ピアリング済み」になった状態

5.3 追加ドメインコントローラーの構成

大阪リージョンにセカンダリDCを構築します。

# 大阪ADサーバー（AD02）で実行
# 東京ADに参加するための資格情報を指定
$SafeModePassword = ConvertTo-SecureString "**********" -AsPlainText -Force
$DomainCred = Get-Credential -Message "FSXPOC\Administrator のパスワードを入力"

Install-ADDSDomainController `
    -DomainName "fsx-poc.local" `
    -InstallDns:$true `
    -Credential $DomainCred `
    -SafeModeAdministratorPassword $SafeModePassword `
    -Force:$true

5.4 DFS-Rの構成

DFS-R（分散ファイルシステムレプリケーション）を使って、東京-大阪間でファイルを自動同期します。

# 両方のファイルサーバー（FS01・FS02）で実行
Install-WindowsFeature -Name FS-DFS-Replication, FS-DFS-Namespace -IncludeManagementTools

# 東京ファイルサーバー（FS01）で実行

# レプリケーショングループを作成
New-DfsReplicationGroup -GroupName "FSx-Replication"
New-DfsReplicatedFolder -GroupName "FSx-Replication" -FolderName "Common"

# メンバーを追加
Add-DfsrMember -GroupName "FSx-Replication" -ComputerName "FS01.fsx-poc.local"
Add-DfsrMember -GroupName "FSx-Replication" -ComputerName "FS02.fsx-poc.local"

# 接続を追加
Add-DfsrConnection -GroupName "FSx-Replication" `
    -SourceComputerName "FS01.fsx-poc.local" `
    -DestinationComputerName "FS02.fsx-poc.local"

# フォルダパスを設定（東京をプライマリに）
Set-DfsrMembership -GroupName "FSx-Replication" -FolderName "Common" `
    -ComputerName "FS01.fsx-poc.local" -ContentPath "D:\Shares\Common" -PrimaryMember $true

Set-DfsrMembership -GroupName "FSx-Replication" -FolderName "Common" `
    -ComputerName "FS02.fsx-poc.local" -ContentPath "D:\Shares\Common"

# 設定の更新
Update-DfsrConfigurationFromAD -ComputerName "FS01.fsx-poc.local"
Update-DfsrConfigurationFromAD -ComputerName "FS02.fsx-poc.local"

図9. DFS-Rレプリケーションの同期状態 — 東京・大阪間で「同期済み」になった状態

注意

DFS-Rの設定後、レプリケーションが開始されるまで数分かかる場合があります。うまく同期されない場合は、両方のファイルサーバーでDFSRサービスを再起動（Restart-Service DFSR）してください。

5.5 DFS名前空間の構成

DFS-Nを使うと、ユーザーは \\fsx-poc.local\files という単一のパスでアクセスでき、自動的に近いサーバーに接続されます。

# 東京ファイルサーバー（FS01）で実行

# 名前空間を作成
New-DfsnRoot -Path "\\fsx-poc.local\files" `
    -TargetPath "\\FS01.fsx-poc.local\Common" `
    -Type DomainV2

# 大阪のターゲットをルートターゲットとして追加
New-DfsnRootTarget -Path "\\fsx-poc.local\files" `
    -TargetPath "\\FS02.fsx-poc.local\Common"

図10. DFS名前空間の構成 — FS01・FS02の両ターゲットがOnlineで登録されていることを確認

---

6. Phase 4：フルマネージド相当の運用自動化

このPhaseのゴール

FSx for Windowsの最大の価値のひとつは「運用をAWSに任せられる」点です。パッチ適用・死活監視・障害通知はすべてAWS側が自動で行います。OCI構成でこれを再現するには、OS Management Hub（パッチ）・OCI Monitoring + Alarms（監視・通知）・PowerShellスクリプト＋タスクスケジューラ（サービス自動復旧）の3層で自動化を積み上げる設計にしました。

FSx for Windowsでは、パッチ適用、監視、障害復旧などをAWSが担当します。OCI構成でこれを再現するには、自分で自動化を構築する必要があります。

6.1 パッチ適用の自動化（OS Management Hub）

OS Management Hubを使うと、Windows Updateの適用をOCIコンソールから管理できます。今回はインスタンスの登録までを確認しました。

図11. OS Management Hubに東京リージョンの2台が「Active」として登録された状態（インスタンス表示名はOCIコンソール上の名称。ホスト名はAD01・FS01に対応。また大阪リージョン側も同様の画面になっている。）

設定の流れと詰まりポイント

有効化までにいくつか事前設定が必要で、順番を間違えると詰まります。

1. プロファイルの作成

OS Management Hubはリージョン固有のリソースです。今回は東京・大阪それぞれのコンパートメントに同じ設定でプロファイルを1つずつ作成しました。

2. 動的グループの作成

ALL {instance.compartment.id = '<コンパートメントOCID>'}

OCIDはOCIコンソール → アイデンティティ → コンパートメント → 対象コンパートメントのOCIDをコピーして使用します。

3. IAMポリシーの追加

プロファイルを作成してエージェントを有効化しても、IAMポリシーが不足していると管理コンソールにインスタンスが表示されません。今回は検証のためテナンシ全体を対象にポリシーを作成しています。実運用では最小権限の原則に基づき、対象コンパートメントに絞ることを推奨します。

allow dynamic-group OracleIdentityCloudService/<動的グループ名> to {OSMH_MANAGED_INSTANCE_ACCESS} in tenancy where request.principal.id = target.managed-instance.id
allow dynamic-group OracleIdentityCloudService/<動的グループ名> to read instance-images in tenancy
allow dynamic-group OracleIdentityCloudService/<動的グループ名> to read instances in tenancy

4. エージェントの有効化

OCIコンソールからエージェントを有効化します。有効化直後はコンソール上のステータスが「実行中」にならない場合がありますが、VMにRDPしてサービスの状態を確認すると Running になっていることがあります。反映に数分〜数十分かかる場合があるため、少し待ってから再確認してください。

補足

インスタンスの登録後は、OS Management Hubのメニューからジョブを作成し、パッチ適用のスケジュールと対象を設定することで自動パッチ適用が可能になります。今回の検証ではインスタンスの登録確認までにとどめており、パッチ適用ジョブの実行は未確認です。

6.2 監視アラームの設定

OCI Monitoringでサーバーの状態を監視し、異常時にアラートを発報します。

図12. OCI Monitoringに登録したアラーム一覧（AD01・FS01のインスタンス停止検知。大阪側も同様に設定。）

メトリクス	閾値	意味
インスタンス状態	STOPPED	サービス断

今回は検証のため、簡易的にVMのヘルスチェックのメトリクスのみアラーム定義で作成して設定しています。

6.3 サービス監視スクリプト

OCIの監視機能はインスタンスレベルの監視ですが、Windowsサービス（SMBなど）の監視は標準では対応していません。PowerShellスクリプトで死活監視と自動復旧を実装します。

# C:\Scripts\monitor-services.ps1

$logFile = "C:\Scripts\monitor-services.log"
$services = @(
    @{Name="LanmanServer"; DisplayName="SMB Server"},
    @{Name="Netlogon"; DisplayName="Netlogon"}
)

$timestamp = Get-Date -Format "yyyy-MM-dd HH:mm:ss"

foreach ($svc in $services) {
    $status = Get-Service -Name $svc.Name -ErrorAction SilentlyContinue
    if ($status.Status -ne "Running") {
        # サービスが停止していたらログに記録して再起動
        "$timestamp - WARNING: $($svc.DisplayName) is not running. Restarting..." | Out-File -Append $logFile
        Start-Service -Name $svc.Name -ErrorAction SilentlyContinue
        "$timestamp - INFO: $($svc.DisplayName) restart attempted." | Out-File -Append $logFile
    }
}

# 1分ごとに実行するタスクスケジュールを作成
$trigger = New-ScheduledTaskTrigger -Once -At (Get-Date) `
    -RepetitionInterval (New-TimeSpan -Minutes 1)
$action = New-ScheduledTaskAction -Execute "PowerShell.exe" `
    -Argument "-ExecutionPolicy Bypass -File C:\Scripts\monitor-services.ps1"
$principal = New-ScheduledTaskPrincipal -UserId "SYSTEM" -LogonType ServiceAccount
$settings = New-ScheduledTaskSettingsSet -StartWhenAvailable

Register-ScheduledTask -TaskName "Monitor-Services" `
    -Trigger $trigger -Action $action -Principal $principal -Settings $settings

---

7. Phase 5：障害検証

このPhaseのゴール

構成を「作った」だけでは再現できたとは言えません。FSx for Windowsが保証する自動復旧をOCI構成が実際の障害でどこまで模倣できるか、この検証こそが本記事の核心です。「ファイルサーバーの停止」「SMBサービスの停止」の2シナリオで実際に障害を発生させ、切り替わり時間・復旧時間を実測しました。

FSx for WindowsのマルチAZ構成では、障害発生時に数秒〜数十秒で自動フェイルオーバーします。OCI構成で同等の自動復旧ができるのか、実際に障害を発生させて検証しました。

7.1 検証シナリオ

今回は以下の2つのシナリオで障害を疑似的に発生させ、それぞれ自動復旧の挙動を確認しました。なお、インスタンスの完全停止（シナリオ①）の中でOCI Alarmsによるアラート通知の検知についても合わせて確認しています。

#	障害シナリオ	検証内容
1	ファイルサーバー（FS01）の停止	DFS-NでFS02にフェイルオーバーするか。またOCI Alarmsでインスタンス停止を検知できるか
2	SMBサービスの停止	監視スクリプトで自動復旧するか

7.2 検証①：ファイルサーバー停止時のフェイルオーバー

検証手順：

1. 大阪のクライアント（FS02経由Bastion）から \\fsx-poc.local\files にアクセス中
2. OCIコンソールからFS01（東京）を強制停止
3. アクセスがFS02（大阪）に切り替わるか確認

検証結果：

項目	結果
フェイルオーバー	成功
切り替わり時間	約1分
アラート通知	約20秒で到達
ユーザー操作	不要（自動切り替え）

図13. FS01停止後にFS02へ切り替わった状態（アクセスパスは \\fsx-poc.local\files のまま）

FS01停止後、エクスプローラーの読み込みバーがゆっくりと進み、約1分後にFS02経由でファイル一覧が表示されました。DFS-Nの名前空間により同じパスでアクセスが継続しましたが、切り替わりにかかる時間はFSxのマルチAZとは差があります。

7.3 検証②：SMBサービス停止時の自動復旧

検証手順：

# FS01で実行
# 現在時刻を確認
Get-Date -Format "HH:mm:ss"  # 17:00:23

# SMBサービスを強制停止
Stop-Service -Name LanmanServer -Force

検証結果：

項目	結果
サービス停止時刻	17:00:23
自動復旧時刻	17:01:12
検知〜復旧時間	約49秒
自動復旧	成功

図14. 監視スクリプトが出力したログ — サービス停止から49秒で自動復旧したことが記録されている

※この画面をキャプチャするまで複数回検証したため、画像下部のログ内に4回分の停止と起動に関するログが記載されております。

7.4 障害検証のまとめ

シナリオ	FSx	OCI構成	差分
ファイルサーバー障害	数秒で自動フェイルオーバー	約1分で切り替え完了（DFS-N）	切り替え時間に差あり
アラート通知	CloudWatch連携	約20秒	ほぼ同等
サービス停止	自動検知・復旧（数秒）	約49秒	若干の遅延
インスタンス停止時の復旧	自動フェイルオーバー	本検証構成では手動対応が必要（アラート通知後にコンソールから再起動）	手動対応必要

インスタンス停止時の復旧について

インスタンスが停止した場合、OCIでもOCI Functionsや通知サービスを組み合わせることで、アラート契機に自動再起動する仕組みを構築することは可能です。ただし今回の検証構成ではその自動化は含めていないため、アラート通知後はコンソールからの手動再起動が必要な状態です。

検証から得られた教訓

OCI構成でもDFS-Nを活用することで、ファイルサーバー障害時に同じパスでのアクセスを継続できました。ただし切り替わりに約1分かかっており、FSxのマルチAZ（数秒）と比べると差があります。サービスレベルの監視と自動復旧も、監視間隔を1分に設定することで実用的なレベルになります。

FSxのような「AWSが全責任を持つ」という安心感は得られません。自前構築では「半自動復旧 + 迅速な手動対応」という運用設計が現実的です。

---

8. 検証結果：各機能の再現度

8.1 機能別の検証結果サマリー

カテゴリ	機能	再現度	検証内容	備考
ファイル共有	SMB（Server Message Block）プロトコル	○	SMB共有作成・アクセス確認	Windows Server標準機能
ファイル共有	SMB暗号化	○	EncryptData: True 確認	設定で有効化
認証・アクセス制御	Active Directory連携	○	ドメイン参加・認証確認	自己管理ADを構築
認証・アクセス制御	Windows ACL（Access Control List）	○	NTFS権限設定・確認（ABE検証内で実施）	NTFS権限で同等
認証・アクセス制御	ABE（Access-Based Enumeration）	○	権限なしユーザーで非表示確認	設定で有効化
データ保護	シャドウコピー（VSS）	○	ファイル復元を実際に確認	スケジュール設定が必要
データ保護	自動バックアップ	○	バックアップから復元テスト	Block Volume Backup Policy
データ保護	保管時暗号化	○	OCIデフォルトで有効（AES-256）	追加設定不要
パフォーマンス	データ重複排除	○	94%の節約率を確認	Windows Server機能
可用性	マルチAZ構成	○	FS01停止→約1分でFS02へ切り替え	DFS-R/DFS-Nで実現。切り替え時間はFSxとの差あり
運用	フルマネージド（サービス自動復旧）	○	約49秒で自動復旧	監視スクリプトで実現
運用	フルマネージド（パッチ自動化）	△	OS Management Hub設定	インスタンス登録まで確認済み。パッチ適用ジョブの実行は未検証

8.2 再現度の評価

評価の前提

以下の再現度は、本記事で実施した検証項目の範囲内での評価です。FSx for Windowsのすべての機能を網羅的に検証したものではなく、AWSがマネージドサービスとして内部で担保する詳細な実装については評価対象外としています。

領域	再現度	コメント
機能面	95%以上	検証対象とした主要機能はすべて動作確認済み
可用性	75%	DFS-R/DFS-Nで切り替え可能だが約1分の遅延あり。FSxの数秒とは差がある
マネージド	60〜70%	自動化は可能だが運用工数は発生する
総合	約80%	機能面はほぼ再現可能

---

9. コスト比較

9.1 前提条件

コスト比較にあたって、以下の条件を前提として試算しています。単価の根拠は末尾の参考資料に記載の各社公式料金ページを参照しています。

項目	値
ストレージ	1TB
スループット	32MB/s相当
バックアップ保持	7日間
リージョン	東京（+大阪 for マルチリージョン）

9.2 構成別コスト比較

構成	月額インフラコスト	初期構築工数	月間運用工数
FSx シングルAZ	$267	数時間	ほぼゼロ
FSx マルチAZ	$400〜500	数時間	ほぼゼロ
OCI シングル構成	$218	1〜2日	5〜10時間
OCI マルチリージョン	$450〜500	2〜3週間	10〜20時間

補足

コスト試算の前提となる単価は各社公式の料金ページを参照しています。詳細は末尾の参考資料をご確認ください。

注意

インフラコストだけを見るとOCI構成が安く見えますが、構築・運用の人件費を含めると、多くのケースでFSxの方がTCO（Total Cost of Ownership）が低くなると考えられます。

---

10. まとめ

10.1 どこまで再現できたか

「OCIでFSx for Windowsをどこまで再現できるか」の結論：

• 機能面：95%以上再現可能（検証対象とした主要機能はすべて動作確認済み）
• 可用性：75%再現可能（DFS-R/DFS-Nで切り替え可能だが約1分の遅延あり）
• マネージド：60〜70%が限界（自動化可能だが運用工数は発生）
• 総合：約80%の再現度

10.2 検証で確認できたこと

カテゴリ	機能	結果
ファイル共有	SMBプロトコル	○ 成功
ファイル共有	SMB暗号化	○ 有効化確認
認証・アクセス制御	Active Directory連携	○ 成功
認証・アクセス制御	Windows ACL	○ 動作確認（ABE検証内で実施）
認証・アクセス制御	ABE	○ 動作確認
データ保護	シャドウコピー（VSS）	○ ファイル復元成功
データ保護	自動バックアップ	○ 復元成功
データ保護	保管時暗号化	○ OCIデフォルトで有効
パフォーマンス	データ重複排除	○ 94%節約
可用性	マルチAZ相当（フェイルオーバー）	○ 成功（約1分で切り替え）
運用	SMBサービス自動復旧	○ 約49秒
運用	アラート通知	○ 約20秒

10.3 FSx for Windowsの価値

今回の検証を通じて、FSx for Windowsのマネージドサービスとしての価値が明確になりました。

• ゼロ運用 → OCI構成では月10〜20時間の運用工数
• SLAによる保証 → OCI構成は自己責任
• 数クリックで構築 → OCI構成は2〜3週間
• パッチ適用の完全自動化 → OCI構成では設定と判断が必要

10.4 選定の考え方

OCI構成を検討する価値があるケース：

• OCI環境への統一が必須要件
• Windows Server運用の体制・ノウハウがある
• 構築・運用の工数を許容できる
• パッチ適用のタイミングを完全にコントロールしたい

FSxが適切なケース：

• 運用負荷を最小化したい
• 高可用性（マルチAZ）が必須
• 少人数チームで運用する

最終的な判断は、コストだけでなく、運用体制、リスク許容度、RTO（Recovery Time Objective）要件を総合的に考慮して行う必要があります。

---

構築時のトラブルシューティング

今回の検証で遭遇した問題と解決方法をまとめます。

私自身Active Directory（AD）を触るのが初めてだったこともあり、検証の本筋とは異なる部分でエラーが生じた箇所もありましたが、こちらについても参考として記載しております。

問題	原因	解決方法
PowerShellでAccess denied	管理者権限で起動していない	スタートメニュー右クリック→「Windows PowerShell (管理者)」
ドメイン作成時にパスワードエラー	ローカルAdministratorのパスワード未設定	net user Administrator "パスワード" で事前設定
ドメイン参加後ログインできない	ローカルユーザーではログイン不可	FSXPOC\Administrator（バックスラッシュ）でログイン
再起動後にDドライブが消える	iSCSI接続の永続化設定漏れ	-IsPersistent $true を指定
RDPでログインできない	Remote Desktop Usersグループが空、またはネットワークプロファイルがPublic	Domain Adminsをグループに追加、プロファイルをPrivateに変更
DFS-Rが同期しない	設定反映に時間がかかる	両サーバーでDFSRサービスを再起動
OS Management Hubが有効化されない	IAMポリシー不足	VMが置かれているコンパートメントにポリシー追加
ABEが効かない	FolderEnumerationModeがUnrestricted	Set-SmbShare -Name "共有名" -FolderEnumerationMode AccessBased
重複排除が効かない	MinimumFileAgeDaysがデフォルト3日	Set-DedupVolume -Volume "D:" -MinimumFileAgeDays 0

---

執筆者

山塚 友貴
NTT西日本　ビジネス営業本部
主にOCIのインフラ設計や構築、運用に携わっています。
保有資格：Oracle Cloud Infrastructure 2024 Architect Professional、AWS Certified Solutions Architect - Professional、Azure Solutions Architect Expert（AZ-305）など。

参考資料

• Amazon FSx for Windows File Server ドキュメント
• Amazon FSx for Windows File Server の料金
• Amazon FSx メンテナンスウィンドウの使用
• OCI Block Volume ドキュメント
• OCI OS Management Hub
• OCI Cost Estimator
• DFS-R の概要

商標

• OracleとJavaは、Oracle Corporationおよびその関連企業の登録商標です。
• Amazon Web Services、AWS、Amazon FSxは、米国その他の諸国における、Amazon.com, Inc.またはその関連会社の商標です。
• Microsoft、Windows、Windows Server、Active Directoryは、米国Microsoft Corporationの米国およびその他の国における登録商標または商標です。