はじめに Azure Batchは、数千規模の計算コアを並列稼働させる強力なサービスですが、その真価は「いかに迅速かつ安定して計算環境をデプロイできるか」にかかっています。本記事では、Office文書のPDF変換処理基盤を構築する過程で直面した課題と、それを技術的に解決した全フローを詳細に解説します。 起動時インストール（StartTask）の限界 初期検証では、マーケットプレイスの標準OSイメージに対し、ノード起動時にスクリプトを実行してツールを導入する「StartTask」方式を検討しました。しかし、実務上の大きな壁となったのが 「プロビジョニング時間」 です。 プロビジ

はじめに 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がマネージドサービスとして内部で担保している詳細な実装についても評価対象外としています。 目次 FSx for Windowsの主要機能を整理する FSx for Windowsの前提条件 検証対象とする機能 FSx for Windowsの本質的な価値 OCI再現構成の設計 段階的なアプローチ 最終構成図 使用するOCIサービス Phase 1：基本構成の構築 Phase 2：FSx相当機能の実装 Phase 3：マルチリージョン構成 Phase 4：フルマネージド相当の運用自動化 Phase 5：障害検証 検証結果：各機能の再現度 コスト比較 まとめ 構築時のトラブルシューティング 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を設定し、日次で自動バックアップを取得します。 ストレージ → ブロック・ボリューム → バックアップ・ポリシー ポリシーを作成（日次、7日間保持） 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を接続し、プライベートネットワーク経由で通信できるようにします。 東京・大阪それぞれにDRG（動的ルーティング・ゲートウェイ）を作成 リモートVCNピアリングで接続 ルートテーブルを更新 東京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 検証①：ファイルサーバー停止時のフェイルオーバー 検証手順： 大阪のクライアント（FS02経由Bastion）から \\fsx-poc.local\files にアクセス中 OCIコンソールからFS01（東京）を強制停止 アクセスが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の米国およびその他の国における登録商標または商標です。

本記事は 2026 年 4 月 20 日 に AWS Migration & Modernization Blog で公開された「 Amazon EVS now offers Windows Server Licensing: A step-by-step guide 」を翻訳したものです。 柔軟性、制御性、そして選択肢の豊富さは、 Amazon Elastic VMware Service (Amazon EVS) の根幹をなす重要な柱です。Amazon EVS では、VMware テクノロジーへの既存の投資を維持しながら、クラウドのメリットを活用できます。Amazon EVS なら、Amazon VPC 内の EC2 ベアメタルインスタンス上で VMware Cloud Foundation (VCF) を直接実行でき、既存のツールや運用プロセスを維持したまま、ワークロードを迅速に移行し、老朽化したインフラストラクチャを廃止できます。 Amazon EVS で Microsoft Windows Server ライセンス の提供を開始したことをお知らせいたします。EVS 環境内で Microsoft Windows Server オペレーティングシステムを実行する仮想マシン (VM) を移行または作成できます。本記事では、移行における意味、仕組み、開始方法を説明します。 より柔軟な対応: Amazon EVS での Windows Server ライセンスオプション Amazon EVS で Windows ベースの VM を実行するには、状況に応じて 2 つのオプションがあります。 Bring Your Own License (BYOL):  ポータビリティ権を持つ対象の Windows Server ライセンス (例: 2019 年 10 月 1 日より前に購入した Windows Server 2016 または 2019 ライセンス) をお持ちの場合、EVS 環境にそのライセンスを持ち込めます。既に投資済みのライセンスを引き続き使用できます。 Amazon EVS の Microsoft Windows ライセンスエンタイトルメント: ポータビリティ権のない VM (Windows Server 2022 や 2025 を実行する VM など) については、Amazon EVS を通じて直接エンタイトルメント（使用権）を付与できるようになりました。vCPU 時間単位の課金で、エンタイトルメントはいつでも追加・削除でき、ニーズの変化に応じてコストを柔軟に管理できます。 開始前に知っておくべきコンセプト ライセンスを設定する前に、EVS コネクタと Windows Server ライセンスエンタイトルメントの 2 つのコンセプトを理解しておく必要があります。 EVS コネクタ: 今回のリリースで EVS コネクタが導入されました。コネクタにより、Amazon EVS サービスが EVS 環境内の VCF 管理アプライアンス (vCenter Server など) と通信できるようになります。各コネクタは 1 つの管理アプライアンスにマッピングされ、完全修飾ドメイン名 (FQDN) と AWS Secrets Manager に保存された認証情報で認証します。Windows Server ライセンスには、Amazon EVS 環境に vCenter コネクタが必要です。コネクタにより、Amazon EVS が Windows Server ライセンスの使用状況を追跡し、VM のライフサイクルイベントを監視できます。 Windows Server ライセンスエンタイトルメント: AWS 提供のライセンスを使用する Windows Server VM ごとにエンタイトルメントを作成する必要があります。作成後、Amazon EVS が VM の電源状態と vCPU 構成を監視するため、課金は実際の使用量に連動し、ワークロードの需要に応じて消費をスケールできます。 課金の仕組み: 監視はエンタイトルメント作成時に開始されますが、課金は VM の実行中の実際のリソース使用量に基づきます。Amazon EVS の Windows ライセンスは、エンタイトルメントを付与した VM の vCPU 時間単位で課金されます。AWS を通じてライセンスを取得した VM のみが課金対象です。Windows Server ライセンスのポータビリティ権の対象となる VM には、AWS からの追加ライセンスコストは発生しません。料金の例については、 Amazon EVS の料金ページ をご覧ください。 ステップバイステップガイド 以下の手順で、EVS 環境内のライセンスを設定します。 手順: VMware vCenter Server 内に ReadOnly ロールを持つユーザーアカウントを作成し、認証情報を AWS Secrets Manager に保存する。 EVS 内に vCenter コネクタを作成する。 VMware VM ID を使用して EVS 内に Windows Server ライセンスエンタイトルメントを追加する。 Activation VPC エンドポイントを作成し、Windows Server VM が AWS Key Management Server (KMS) を使用するよう設定する。 ステップ 1: EVS 環境内の VMware vCenter Server に ReadOnly ロールを持つユーザーアカウントを作成し、認証情報を AWS Secrets Manager に保存する EVS コネクタは、EVS 環境内の vCenter Server アプライアンスとの認証に認証情報が必要です。コネクタを作成する前に、コネクタが使用する ReadOnly ロールを持つ専用ユーザーアカウントを作成します。 新しいユーザーの作成とロールの割り当てに必要な管理者権限を持つアカウントで、Amazon EVS 環境の vCenter Server にログインします。 ローカルの Single-Sign On ユーザー を作成し、 ReadOnly グループに割り当て ます。 図 1: 新しいユーザーのユーザー名、パスワード、説明 (推奨) を設定 図 2: 作成したユーザーを ReadOnlyUsers グループに追加 次に、EVS コネクタが vCenter アプライアンスと連携するために、作成した認証情報が必要です。認証情報を安全に保存し Amazon EVS と共有するには、特定のタグを付けて AWS Secrets Manager に保存します。 AWS マネジメントコンソール から AWS Secrets Manager にアクセスします。 「新しいシークレットを保存する」 を選択します。 「その他のシークレットのタイプ」 を選択します。 「キー/値のペア」 セクションで、完全なユーザー名を 「 キー」 に、パスワードを 「 値」 に入力します。入力後、「 次」  を選択します。 ユーザー名は username@vsphere.local の形式にします この例では、ユーザー名は evs-connector@vsphere.local です 「シークレットの名前と説明」 セクションで、シークレットの名前を入力します。説明はオプションで追加できます。 「タグ – オプション」 セクションで 「 追加する」  を選択します。 キー に EvsAccess 、値 に true を入力してタグを追加します。 注意: キー と 値 は大文字と小文字が区別されます。 図 3: シークレットに EvsAccess=true タグを付与 「ローテーションを設定する」 セクションはデフォルトのままにします。「 次 」 を選択します。 内容を確認し、「 保存」  を選択します。 ステップ 2: EVS 内に vCenter コネクタを作成する 次に、vCenter Server との通信を可能にする Amazon EVS コネクタを作成します。 AWS マネジメントコンソール から Amazon EVS にアクセスします。 コネクタを追加する EVS 環境を選択します。 「コネクタ」 タブを選択し、 「コネクタを作成」 を選択します。 図 4: 新しいコネクタを作成 Amazon EVS vCenter アプライアンス の FQDN を入力します。 先ほど作成した AWS Secrets Manager のシークレットをリストから選択します。 vCenter ユーザーのアクセスと権限を設定済みであることを確認するチェックボックスを選択し、「 コネクタを作成 」 を選択します。 図 5: EVS vCenter へのアクセス権を持つ新しいコネクタの作成フォームを送信 接続の検証には最大 10 分かかる場合があります。Amazon EVS 環境のコネクタタブでコネクタの状態を確認できます。 次のステップに進む前に、 「状態」  が Active 、 「ステータス」 が Passed になるまで待つ必要があります。 ステップ 3: VMware VM ID を使用して EVS 内に Windows Server ライセンスエンタイトルメントを追加する ユーザーアカウントとコネクタの設定が完了したら、VM に Windows Server ライセンスのエンタイトルメントを付与できます。 AWS マネジメントコンソール から Amazon EVS にアクセスします。 コネクタを追加する EVS 環境を選択します。 「使用権限」 タブを選択し、 Add entitlements を選択します。 図 6: エンタイトルメントを追加 .csv ファイルをアップロードするか、VM ID を手動で追加できます。このウォークスルーでは、手動で ID を追加します。 Note: vCenter では PowerCLI やその他のツールで VM Managed Object ID を取得できます。 Note: 各エンタイトルメントに含められる VM は最大 100 台です。100 台ずつバッチでエンタイトルメントをリクエストできます。 テキストボックスに VM ID をカンマ区切りで入力します。 Add entitlements を選択します。 図 7: 新しいエンタイトルメントに VM ID を送信 エンタイトルメントの 「ステータス」 が Active に変わったことを確認します。 ステップ 4: Activation VPC エンドポイントを作成し、Windows Server VM が AWS Key Management Server (KMS) を使用するよう設定する Amazon EVS は、エンタイトルメントを付与した VM のアクティベーションに使用する Key Management Services (KMS) サーバーエンドポイントを提供します。エンタイトルメントの作成後、VPC エンドポイントを作成して Amazon EVS 提供の KMS サーバーへの接続を有効にできます。 このエンドポイントは、AWS 提供の Windows Server ライセンスを使用している Amazon EVS 環境が稼働中の場合にのみ作成できます。 AWS マネジメントコンソール から Amazon VPC にアクセスします。 左側のナビゲーションペインで、「 PrivateLink と Lattice」 セクションから 「 エンドポイント」 を選択します。 「エンドポイントを作成」 を選択します。 エンドポイントの名前を入力します。 「タイプ」 で 「 AWS のサービス」 を選択します。 図 8: Activation VPC エンドポイントを作成 サービス名が「 com.amazonaws.<region>.evs-windows-server-activation 」のサービスを選択します。 ネットワーク設定で、ドロップダウンメニューから Amazon EVS の VPC を選択します。 図 9: 新しいエンドポイントのアクティベーションサービスを設定 次に、 「サブネット」 セクションから サービスアクセスサブネット を選択します。 図 10: 新しいエンドポイントにサービスアクセスサブネットを関連付け エンドポイントにアタッチする セキュリティグループ を選択します。セキュリティグループは、AWS KMS サーバーに接続する Windows Server VM からの インバウンド TCP 1688 を 許可する必要があります 。 エンドポイントのステータスが 「 使用可能」 になったら、エンドポイント名を選択してスクロールダウンし、「 プライベート DNS 名」 を確認します。次のタスクで必要になります。 図 11: エンドポイントのプライベート DNS 名を取得 次に、エンタイトルメントを付与した VM が Amazon EVS 提供の KMS サーバーエンドポイントを Windows アクティベーションに使用するよう設定します。各 VM で手動で設定するか、PowerShell やグループポリシーでプロセスを自動化できます。本記事では、PowerShell による手動オプションを紹介します。 Windows Server VM にログインし、 PowerShell ウィンドウを開きます。 コピーした Private DNS name で、以下のコマンドにより VM が AWS KMS サーバーを使うよう設定します。 slmgr /skms <VPC Endpoint Private DNS Name>:1688 この例では、コマンドは以下のようになります。 slmgr /skms evs-windows-server-activation.us-east-2.amazonaws.com:1688 Key Management Service machine が AWS KMS サーバーに設定されたことを通知するダイアログウィンドウが表示されます。 図 12: Windows Server VM の AWS KMS サーバー設定が完了 次に、以下のコマンドを実行して Windows Server VM をアクティベートします。 slmgr /ato 成功すると、製品が正常にアクティベートされたことを通知するダイアログウィンドウが表示されます。 図 13: Windows Server VM のアクティベーション成功 Windows Server VM が正しく設定されたことを確認するには、以下のコマンドを実行します。 slmgr /dli 成功すると、以下のメッセージが表示されます。 図 14: ライセンスアクティベーションの確認 コマンドラインインターフェイス (CLI) を使う場合は、 ユーザーガイド を参照してください。 開始方法 今すぐ AWS への移行を始めましょう。戦略的なデータセンター撤退の計画、運用コストの削減、クラウドイノベーションの活用のいずれであっても、Amazon EVS で VCF ベースのワークロードをシンプルに移行できます。 さあ始めましょう: 今すぐ Amazon EVS コンソール にアクセス 詳細を確認: 技術ドキュメント で Amazon EVS とライセンスについて学ぶ 移行とモダナイゼーションのオプションを検討する: AWS for VMware ページ ですべての VMware ワークロードの AWS への移行・モダナイゼーションオプションを確認 計画を開始する: まずは お問い合わせ いただき、 無料のアセスメント から始めましょう。 著者について James Selwood AWS の Infrastructure Migration and Modernization チームのシニアスペシャリストソリューションアーキテクトです。19 年の業界経験を持ち、2019 年に AWS に入社。VMware、ネットワーク、コンピューティングインフラストラクチャのバックグラウンドを活かし、お客様のクラウド移行を支援しています。 Allan Scott AWS のシニアスペシャリストソリューションアーキテクトです。2022 年に AWS に入社し、Infrastructure Migration and Modernization チームで 22 年の業界経験を活かして複雑な技術課題に取り組んでいます。VMware 環境、ネットワーク、コンピューティングインフラストラクチャの最適化を専門としています。 Alex Pylnev AWS の Infrastructure Migration and Modernization チームのスペシャリストソリューションアーキテクトです。クラウド移行の計画・実行からレガシーインフラストラクチャのモダナイゼーションまで、お客様の技術課題を支援しています。VMware 環境での豊富な経験を持ちます。 Bianca Velasco AWS のプロダクトマーケティングマネージャーとして、VMware ベースのワークロードの AWS への移行とモダナイゼーションを担当しています。マーケティングとテクノロジー分野で 7 年以上の経験があります。 翻訳はパートナーソリューションアーキテクト 豊田が担当しました。原文は こちら です。