このブログは AWS のスペシャリストソリューションアーキテクト Suhail Fouzan、ソリューションアーキテクト Eswar Sesha Sai Kamineni、シニアテクニカルアカウントマネージャー Rizwan Mohammed によって執筆された内容を日本語化したものです。原文は こちら を参照して下さい。なお、本翻訳では原文公開後の名称変更を反映し、「Amazon Quick Suite」を現在の正式名称である「Amazon Quick」に統一しています。 今日の変化の激しい IT 環境において、インフラストラクチャ全体のパッチ適用コンプライアンスを監視・可視化することは極めて重要です。従来、 Amazon QuickSight で包括的なパッチ適用ダッシュボードを作成するには、各ビジュアルコンポーネントに対して複数のステップを要する手動かつ時間のかかるプロセスが必要でした。 Amazon Quick は、データ分析と可視化の機能を強化する AI 搭載のアシスタントです。このブログでは、 Amazon Quick が自然言語による対話を通じてダッシュボード作成を簡素化し、この体験をどのように変革するかを解説します。多段階の手動プロセスを数回の簡単なプロンプト操作に短縮し、パッチ適用コンプライアンスとインベントリに関する洞察に富んだ可視化を素早く生成する方法を紹介します。AI を活用した機能が、正確性を維持しながら貴重な時間を節約し、組織のパッチ適用状況に関するリアルタイムのインサイトを提供する動的なダッシュボードの作成にどのように役立つかをご覧ください。システム管理者、セキュリティアナリスト、IT マネージャーのいずれであっても、このガイドは Amazon Quick がパッチ適用コンプライアンスとインベントリの監視・レポート方法をどのように革新するかを説明します。 さらに、このソリューションはカスタムインベントリの可視化を通じて、インフラストラクチャの包括的な可視性を提供します。クラウドプロバイダー、AWS ドライバー、インスタンスタイプ全体にわたるコンピューティングリソースの分布を把握するためのグラフを作成できます。 ソリューションの概要 図 1: アーキテクチャ図 このソリューションは、複数の AWS サービスを活用して Amazon Quick のデータセット作成を自動化し、自然言語クエリを使用してデータを可視化します。 AWS Systems Manager （SSM）のアソシエーションを使用して、各ターゲットマネージドノードでカスタムスクリプトが実行され、必要なインベントリ情報を収集して カスタムインベントリパス に配置します。この情報は、SSM Inventory とリソースデータ同期によって Organization 内の各 AWS アカウントから収集され、中央の S3 バケットに保存されます。この S3 バケットは AWS Glue クローラーによってクロールされ、Glue データベースが作成されます。このデータベースのデータは、Amazon Quick が Amazon Athena 経由でクエリし、データセットの作成とデータの可視化を行います。 このソリューションは、 AWS CloudFormation スタックを使用してデプロイされ、データストレージ用の Amazon S3 バケット、データカタログ用の AWS Glue データベースとクローラー、Systems Manager アソシエーション、リソースデータ同期、Amazon Quick のデータセットと分析ダッシュボードを管理するための AWS CloudFormation StackSet などのリソースを作成します。このソリューションは主に 2 つの自動スケジュールで動作します。Systems Manager アソシエーションは 7 日ごとにカスタムインベントリ収集を実行し、AWS Glue クローラーは 12 時間ごとに Amazon Athena データベースとのデータ同期を実行します。両方のスケジュール間隔は、組織固有の要件に合わせて変更できます。 SSM カスタムアソシエーションは、クラウドプロバイダーおよびオンプレミスシステム全体のすべてのマネージドノードからメタデータを収集し、以下のインフラストラクチャ情報を収集・提供します。 Cloud_provider – AWS やオンプレミスの VMware などのクラウドプロバイダー情報 Total_diskspace – プロビジョニングされたディスク容量の合計 Free_diskspace – 利用可能な空きディスク容量 Free_space_percent – 利用可能な空き容量の割合 Diskspace_status – 10% 未満の場合のディスク容量ステータス さらに、インスタンスメタデータとカスタムスクリプトを使用して、EC2 マネージドノードに固有の以下の情報を収集します。 EC2_type – Xen や Nitro ベースのインスタンスなどの EC2 ハイパーバイザータイプ Instance_type – オンデマンドやスポットなどの購入オプション NVMe_version – インストールされている NVMe ドライバーのバージョン ENA_version – インストールされている ENA ドライバーのバージョン License_type – Windows ライセンス付属や BYOL などのインスタンスに関連付けられたライセンス情報 この情報は、各マネージドノードのカスタムインベントリパスに保存されます。SSM Inventory アソシエーションは、 標準のインベントリメタデータ とともにこのカスタムデータをキャプチャします。各アカウントの リソースデータ同期 により、インベントリメタデータが中央の S3 バケットに同期されます。 前提条件 このウォークスルーを実施するには、以下が必要です。 Systems Manager マネージドノード（カスタムインベントリ情報をキャプチャするための Amazon EC2 インスタンスまたは ハイブリッドノード ） アカウントで Systems Manager Inventory が有効化されていること マネージドノードにパッチを適用するための Systems Manager Patch Manager のスキャンまたはインストール操作 Admin pro または Author pro の Amazon Quick ユーザーアカウント CloudFormation StackSet を作成するために必要な権限 AWS Organization ID ウォークスルー AWS CloudFormation スタックを使用してソリューションをデプロイし、必要なリソースを作成します。CloudFormation スタックは、Organization 管理アカウントまたは StackSet の委任管理者アカウントからデプロイできます。中央の S3 バケット、Quick ダッシュボード、およびその他のリソースは、スタックをデプロイしたアカウントとリージョンに作成されます。 デプロイ後、 Amazon Quick を使用したビジュアルの作成 についての手順を説明します。 GitHub リポジトリから CloudFormation テンプレート をダウンロードし、 スタックをデプロイ します。 パラメータエリアで、以下のパラメータを入力します。 SSM Resource Data Sync and Custom inventory configuration セクション: Amazon S3 bucket: AWS Systems Manager リソースデータ同期に使用する Amazon S3 バケットの名前 Target type: カスタムインベントリアソシエーションのターゲットタイプ。すべてのインスタンスの場合は ALL、タグベースのターゲットの場合は TAG を指定し、次のパラメータにタグキーと値を入力します Tag key for targeting instances: 対象インスタンスのタグキー Tag value for targeting instances: 対象インスタンスのタグ値 AWS Accounts Options セクション: AWS Organization ID: AWS Organization ルート ID（r-xxx）または Organization Unit ID（ou-xxx） AWS Account IDs: Organization または OU にデプロイする AWS アカウント ID のリスト（アカウントは指定した Org/OU のメンバーである必要があります）。Organization または OU 内のすべてのアカウントにデプロイする場合は空のままにします AWS Account Regions: AWS リージョンのリスト 図 2: AWS CloudFormation パラメータ – Organization デプロイ Organization を使用せずにアカウントにデプロイする場合: AWS Organization ID: フィールドを空のままにします AWS Account IDs: デプロイする AWS アカウント ID のリスト（アカウントはいずれの Organization にも属していない必要があります） AWS Account Regions: AWS リージョンのリスト 図 3: Organization に属さないアカウント用の AWS CloudFormation パラメータ Amazon Athena セクション: Amazon Athena Database Name: AWS Systems Manager リソースデータ同期用の Amazon Athena データベース名 Amazon Quick セクション: Amazon Quick user: Amazon Quick のユーザー名を入力します Resources タブに移動して、CloudFormation スタックによって作成されたリソースを確認します。 CloudFormation のデプロイが完了したら、アカウント上の SSM インベントリアソシエーションの実行が完了するまで待ちます。デフォルトでは、インベントリアソシエーションは 30 分ごとに実行されます。インベントリの実行が完了したら、以下の手順に従って Glue クローラーを実行します。 AWS Glue クローラーコンソール に移動します 「SSM-GlueCrawler-*」で始まるクローラーを選択します Run を選択してクローラーを実行します Glue クローラーは、中央の S3 バケットからインベントリデータをクロールし、Glue データベース ssm_datasync_resources を更新します。 Quick ユーザーと権限の検証 Quick ユーザーロール: Amazon Quick コンソール に移動してサインインします 右上のユーザーアイコンを選択し、 Manage Quick を選択します Manage users を選択し、Quick ユーザーのロールとして Admin Pro を選択します 図 4: Amazon Quick ユーザーの権限 Quick の権限: 同じページの左メニューで、 Permissions の下にある AWS resources を選択します Amazon Athena と Amazon S3 を選択します。Select S3 buckets で、先ほどデプロイした CloudFormation テンプレートによって作成された Systems Manager インベントリおよびパッチ適用データ用の S3 バケットを選択します。また、Amazon Athena のクエリ結果出力先として設定した S3 バケットも併せて選択してください Save を選択します 図 5: Amazon Quick ロールの S3 バケットへの権限 Amazon Quick を使用したビジュアルの作成 Quick のホームページで、 Analysis を選択し、CloudFormation スタックによって作成された SSM Inventory Analysis を選択します Visuals の下にある Build アイコンを選択します。ビジュアルを構築するためのクエリを入力するサイドパネルが開きます 以下は、ビジュアルを生成するためのプロンプト例です。必要に応じてプロンプトやビジュアルをカスタマイズできます プロバイダー別マネージドノード このビジュアルは、さまざまなクラウドプロバイダーおよびオンプレミスインフラストラクチャにデプロイされたマネージドノードの数を表示し、プラットフォーム間のワークロード分布に関する洞察を提供します。 プロンプトとして「 Create a pie chart for count of resourceid by provider 」と入力し、BUILD を選択します または、「 Create a visual for count of resourceid by provider 」と入力して、Amazon Quick にビジュアルタイプを決定させることもできます Amazon Quick がビジュアルを生成します。 Add to Analysis を選択し、必要に応じてビジュアルのサイズを変更します 見出しをダブルクリックして編集し、「Managed Node by Provider」に更新します 図 6: Amazon Quick を使用したビジュアルの構築 ステータス別マネージドノード プロンプトとして「 Create a donut chart for count of resourceid by instancestatus 」と入力し、BUILD を選択します Add to Analysis を選択し、必要に応じてビジュアルのサイズを変更します。ビジュアルの見出しを更新します 以下に説明する他のビジュアルについても、異なるプロンプトを使用して同じ手順に従いビジュアルを生成します 図 7: ステータス別マネージドノード OS 別マネージドノード プロンプト: 「 Create a donut chart for count of resourceid by platformname 」 図 8: OS 別マネージドノード プラットフォーム別マネージドノード プロンプト: 「 Create a donut chart for count of resourceid by platformtype 」 SSM Agent バージョン プロンプト: 「 Create a visual for count of resourceid by version and application name equals Amazon SSM Agent 」 ディスク容量ステータス プロンプト: 「 Create a visual for count of resourceid by diskspacestatus 」 図 9: 運用ダッシュボード Amazon EC2 インスタンス固有のビジュアル 以下のビジュアルは、SSM カスタムインベントリアソシエーションから取得した Amazon EC2 インスタンスの詳細情報を表示し、さまざまな AWS 固有のコンポーネントとリソース構成に関する貴重な洞察を提供します。 以下は、ビジュアルを作成するためのプロンプトです。 AWS PV Driver バージョン プロンプト: 「 Create a visual for count of resourceid by application version and application name equals AWS PV Drivers 」 ビジュアルから null または empty データを選択し、 Exclude null を選択します。 Add to Analysis を選択してビジュアルを分析に追加します。これは、このビジュアルに該当しない他のプロバイダー（オンプレミスやハイブリッドノードなど）の null/空の値を除外するためです ダッシュボードにテキスト見出しを追加するには、ペインの上部にある Add Text アイコンを選択し、テキストを AWS Dashboard に変更します Amazon EC2 ENA Driver バージョン プロンプト: 「 Create a visual for count of resourceid by enaversion 」 AWS NVMe Driver バージョン プロンプト: 「 Create a visual for count of resourceid by nvmeversion 」 ライセンスタイプ別 Amazon EC2 インスタンス プロンプト: 「 Create a pie chart for count of resourceid by licensetype 」 インスタンスタイプ別 Amazon EC2 インスタンス プロンプト: 「 Create a pie chart for count of resourceid by instancetype 」 図 10: AWS EC2 メトリクスダッシュボード コンプライアンスシート コンプライアンスシートは、特にパッチおよびアソシエーションのコンプライアンスに焦点を当てたコンプライアンス固有の可視化を作成するために使用されます。ここでは、非準拠のパッチを強調表示するビジュアルを生成するとともに、不足しているパッチの包括的なリストを提供し、システムのセキュリティポスチャの明確な概要を示します。 シートの上部から Compliance シートを選択します 以下は、コンプライアンス固有のビジュアルのプロンプト例です パッチコンプライアンス別マネージドノード プロンプト: 「 create a pie chart for count of resourceid by compliance status for compliancetype equals Patch 」 アソシエーションコンプライアンス別マネージドノード プロンプト: 「 create a pie chart for count of resourceid by compliance status for compliancetype equals Association 」 プロバイダー別パッチ準拠マネージドノード プロンプト: 「 create a donut chart for count of resourceid by provider for compliancetype equals Patch and compliance status equal COMPLIANT 」 プロバイダー別パッチ非準拠マネージドノード プロンプト: 「 create a donut chart for count of resourceid by provider for compliancetype equals Patch and compliance status equal NON_COMPLIANT 」 OS 別パッチ準拠マネージドノード プロンプト: 「 create a visual for count of resourceid by platformname for compliancetype equals Patch and compliance status equal COMPLIANT 」 OS 別パッチ非準拠マネージドノード プロンプト: 「 create a visual for count of resourceid by platformname for compliancetype equals Patch and compliance status equal NON_COMPLIANT 」 不足しているパッチ プロンプト: 「 create a pivot table with provider, accountid, region, platformname, resourceid, patch title for compliancetype equals Patch and compliance status equal NON_COMPLIANT and patch status equal Missing 」 図 11: コンプライアンスダッシュボード ビジュアルが作成されたら、 Publish を選択してダッシュボードを公開します。さらに、Amazon Quick を活用して詳細情報を取得したり、ダッシュボードとインタラクションして質問に対する回答を得ることもできます。例えば、ディスク容量が危険な状態のマネージドノードのリストを取得するには、「 List of resourceid by diskspacestatus equal Critical 」というプロンプトで回答を得ることができます。 クリーンアップ リソースを削除するには: AWS CloudFormation コンソール に移動します Stacks を選択し、 ssm-inventory-patching-dashboard という名前のスタックを選択します Delete を選択し、 Delete stack を選択します Amazon Quick コンソール に移動します ダッシュボード、分析、およびデータセットを削除します まとめ このブログ記事では、Amazon Quick が Systems Manager のパッチ適用およびインベントリダッシュボードの作成をどのように簡素化するかを紹介しました。自然言語によるインタラクションを活用することで、かつては複雑で多段階のプロセスだった作業が、包括的な可視化を生成するシンプルで直感的なプロンプトに変わりました。このソリューションは貴重な時間を節約するだけでなく、クラウドおよびオンプレミス環境全体のパッチ適用コンプライアンス、インベントリステータス、インフラストラクチャ分布に関するリアルタイムの洞察を提供します。 さらに、Amazon Quick は自然言語プロンプトによるダッシュボードデータのインタラクティブなクエリを可能にし、特定の情報を素早く取得できます。AWS Systems Manager と Amazon Quick を含む AWS サービスの組み合わせにより、組織はハイブリッドインフラストラクチャの管理を強化しながら、監視とレポートのプロセスを簡素化できます。パッチコンプライアンスの管理、インベントリの追跡、AWS 固有のコンポーネントの監視のいずれであっても、このソリューションはインフラストラクチャの可視化と管理に対する合理化されたアプローチを提供します。CloudFormation テンプレートをダウンロードし、AI を活用した可視化を数分で実装して、今すぐインフラストラクチャ監視を変革しましょう。 AWS Systems Manager のパッチ適用機能の詳細については、 AWS Systems Manager Patch Manager のドキュメント をご覧ください。 Suhail Fouzan Suhail Fouzan は、Amazon Web Services（AWS）のスペシャリストソリューションアーキテクトで、IT 業界で 15 年以上の経験を持っています。Microsoft ワークロード、移行サービス、AWS Systems Manager を使用したオペレーション管理を専門とし、お客様のインフラストラクチャの AWS への移行を成功に導いています。仕事以外では、クリケットを楽しんだり、家族と過ごしたりしています。 Eswar Sesha Sai Kamineni Eswar Sesha Sai Kamineni は、Amazon Web Services のソリューションアーキテクトです。クラウドソリューションの設計を支援し、技術的なガイダンスを提供することで、お客様のビジネス変革を支援しています。George Mason University でデータアナリティクスエンジニアリングの学位を取得しました。AI と機械学習に深い関心を持っています。テクノロジーの新しい進歩について読んだり、ハイキングを楽しんでいます。 Rizwan Mohammed Rizwan Mohammed は、AWS のシニアテクニカルアカウントマネージャーで、エンタープライズのお客様が AWS サービスを採用し、新しいアーキテクチャを構築し、現在の実装を最適化するのを支援しています。クラウドオペレーションと Microsoft ワークロードを専門とし、お客様のオペレーショナルエクセレンスの向上に情熱を注いでいます。 翻訳は Solutions Architect の小野が担当しました。原文は こちら です。

本記事は 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 年以上の経験があります。 翻訳はパートナーソリューションアーキテクト 豊田が担当しました。原文は こちら です。

皆様は、「DataKeeper」という製品をご存知でしょうか。 DataKeeperとは、稼働中のサーバのデータを、リアルタイムで待機系に複製（ミラーリング）し、止めないシステム運用を実現するソフトウェアです。 クラスタノード間でボリュームをミラーリングし、あたかも共有ストレージのように扱うことが可能になります。クラスタリングソフトウェアであるLifeKeeperやWindowsのWSFC（Windows Server Failover Clustering）と連携することにより、高可用性を実現しつつ、データの冗長性を確保することが可能となります。   本記事では、DataKeeperの機能や特徴を解説し、どのような状況で活用していくかについて紹介していきます。   DataKeeperの基本機能・主な特長 基本機能 DataKeeperは、稼働系と待機系のローカルディスク上のボリュームをレプリケーションの技術で同期し、 それらのボリュームを論理的な共有ディスクのように扱い、LifeKeeperおよびWSFCとも連携する機能が特徴です。 DataKeeperの構成イメージ   サーバ毎に接続されたローカルディスク上のボリュームをレプリケーションし、 ミラーボリュームを作成することで、共有ディスクとして扱うことが可能となります。 障害発生時には LifeKeeper と連携してLifeKeeperが監視・フェイルオーバーを実行し、 DataKeeperがデータレプリケーションを担い、論理共有ディスク上のデータをそのまま待機系に引き継ぎます。   主な特徴 ■ブロックレベルのリアルタイム・レプリケーション 同期／非同期に対応しており、WAN向け最適化や圧縮も備え、レイテンシー環境でも帯域効率よく複製します。帯域制御とパフォーマンスについては、ファイル単位ではなく「ブロックレベル」となるため、高速での転送が可能となります。 同期に使うネットワーク帯域を調整できるため、業務ネットワークへの影響を最小限に抑えられます。   ■WSFCとネイティブ連携 DataKeeper VolumeをWSFCのリソースとして扱い、クラスタ側の制御に自然統合することができます。 Windows標準のクラスタ機能（WSFC）が、DataKeeperのボリュームを「物理ディスクリソース」として認識し、SQL Serverやファイルサーバの冗長化をする際、使い慣れた WSFC の管理画面で運用できるため、学習コストを増やさずに導入できます。   ■クラウド/仮想/物理を横断 AWS/Azure/GCPやVMware、オンプレ物理で同じ考え方で設計・展開が可能となります。 AWSやAzureでは、オンプレミスのような「共有ストレージ（SAN）」をマウントしてクラスタを組むのが難しい、または高価なマネージドサービスが必要となりますが、 DataKeeperを使えば、ローカルディスク同士を同期させるだけでクラスタを組むことが可能です。   ■コスト最適化 共有ストレージが不要となり、OSからは「共有ディスク」として認識されるため、アプリケーション側の対応が不要、コストを抑えることができます。   では、これらの特徴が実際の現場でどのように役立つのか、シチュエーションごとに DataKeeper の活用イメージを紹介します。   シチュエーション別、DataKeeperの活用事例 1) クラウド移行を検討中の情シス（AWS） 前提 ：既存オンプレで SQL Server FCI や ファイルサーバクラスタ を利用中 AWS に移行しても ダウンタイムを極小化した高可用性（HA） 構成 を維持したい 課題 ： AWS では、共有ディスク構成が直接使えない/FSx for Windows（共有ファイルサービス）が割高/　　マルチAZをまたいだ共有ストレージ提供が制約多い、という背景がある 解決 ：DataKeeper を使うことで、各ノードのローカル EBS（ディスク）上のボリュームをブロック単位で同期し、 共有ディスクなしでも WSFC）を構築可能。またマルチAZまで柔軟に拡張可能となります。AWS に「オンプレ同等の可用性構成」を持ち込めます。 構成イメージ(AWS)： マルチAZの SQL Server FCI/ファイルサーバ にLifeKeeper + DataKeeper を導入した構成各ノードはローカル EBS を利用 DataKeeper が ブロックレベルで EBS を同期（Sync/Async） LifeKeeper/WSFC によりAZ 障害時は自動フェイルオーバー ➡ 共有ディスクが不要なため、AWS の制約（共有ストレージ/コスト）を解消できます   2) 共有ストレージのコストや仕様で悩むエンジニア 前提 ：オンプレ/仮想環境で NAS/SAN などの共有ストレージ を利用している 課題 ：共有ストレージは高コスト、専用スキルや運用の複雑性、SPOFが気になる。 解決 ：DataKeeperは既存のローカルストレージを活用し、SPOFを排除。 SSD/フラッシュも活かせるため性能面でも優位。 アレイ依存のレプリケーションに比べ、コスト効率の高いHA/DRが構築可能。  構成イメージ ：Azure：ASCS/ERSやDBのWSFCを共有ディスク不要で内部LB・クォーラム設計のガイダンスに沿い、DataKeeperで共有相当を実現。 ➡コストを下げつつ、ストレージの複雑性・制約をすべて解消できます     他方式とのDataKeeperの比較 具体的な活用イメージをご紹介しましたが、他方式と比べてどこが優れているのか？も気になるポイントです。 代表的な方式との比較を整理してみます。  比較対象 DataKeeper導入のメリット DataKeeper導入のデメリット vs クラウド共有ストレージ（FSx/Azure Files等） ・コスト最適化（従量課金を排除） ・マルチAZ対応 ・ローカルI/Oで性能が安定 ・局所レイテンシ低減の余地 ・レプリケーション帯域の確保が必要 ・ローカルディスク障害時の運用が発生 ・一般的に2ノード中心 vs S2D （Storage Spaces Direct） ・WSFC＋既存ディスクで即構成 ・クラウド横断で利用可能 ・専用NIC/ハード不要 ・学習コストが低い ・スケールアウトストレージ機能なし ・大規模分散用途には不向き ・ソフトウェアライセンス費用が発生 vs SQL Server Always On（AG） ・DB以外も保護可能 ・SEでFCIが作れライセンス最適 ・アプリ改修不要 ・フェイルオーバーが単純 ・読み取り専用レプリカ不可 ・全ボリュームレプリケーション ・AGにあるDBレベル機能を持たない   比較を踏まえて理解が深まったところで、 実際の相談でよくいただく質問もまとめておきます。 よくある質問（FAQ） Q1. レプリケーションは同期／非同期を切り替えられますか？ A. はい。ブロックレベルで同期／非同期を選択でき、切り替えも可能です。 Q2. SQL Server Standard EditionでもFCIを構築できますか？ A. 可能です。DataKeeper＋WSFCで共有ディスク相当を提供できるため、Standard EditionでもFCIを構成できます。 Q3. ネットワーク障害でノード間の通信が切断された場合、再同期はどうなりますか？ A. フル同期のやり直しは不要です。通信が途絶えた際、DataKeeperはレプリケーションを一時停止し、変更されたブロック箇所（差分）だけを内部のビットマップメモリに記録し続けます。ネットワーク復旧後は、その差分データのみが自動的に再同期（部分再同期）されるため、システムへの負荷を最小限に抑えて正常な状態に復帰できます。 Q4. DataKeeperでレプリケーションできないデータはありますか？ A. はい。Cドライブなどの「OSシステム領域（システムボリューム）」はレプリケーションの対象外となります。また、DataKeeperはドライブ（ボリューム）単位でのブロック同期を行うため、「特定のファイルやフォルダだけ」を指定して同期することも仕様上できません。   まとめ DataKeeperでは、AWSやAzure等のクラウド・オンプレを問わず、同じアーキテクチャ思想で設計・展開・運用できるのが強みであることをお伝えいたしました。 LifeKeeper連携まで含めた“アプリもデータも守る”設計で、止めないシステム運用を支援します。  詳しい内容をお知りになりたいかたは、以下バナーからお問合せください。