この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
しばたです。
先日Microsoft Office LTSC入りAMIが提供され実際に試してみた記事を公開しました。
AMIが公開される以前から「EC2でMicrosoft Officeを使いたい。(EC2でExcelを使いたい、などの派生を含む)」という相談をよく受けていたのですが、ライセンス上の問題によりEC2にMicrosoft Officeを導入するのは一筋縄ではいきませんでした。
本記事ではそのへんのライセンス周りの難しさについて注意喚起の意味も込めて解説します。
免責事項
ライセンスの話をするのでいつも通り免責事項を最初に。
極力間違いの無い様に努めて書いていますが、あくまでもいち個人の解釈にすぎず、本記事の内容はライセンスに対する記述の正確さを保証しません。
仮に本記事の内容に誤りがあり、それによりいかなる不利益を被ったとしても一切の責任を負えませんので予めご了承ください。
ライセンスに関する正式な判断が必要になる場合は必ず Microsoft および AWS に確認してください。
【重要】まずはAmazon WorkSpacesで代替できないか検討してください
単純にAWS環境上でMicrosoft Officeを使いたいという事であれば、まずはAmazon WorkSpacesの利用を検討してください。
これはOffice入りAMIが公開された今でも変わらないと私は考えています。
Amazon WorkSpacesではMicrosoft Office Professional Plusをバンドル済みのマシンイメージが提供されておりライセンス上の懸念を一切気にすることなく利用することができます。
それでもEC2でMicrosoft Officeを使いたい方へ
それでもEC2でOfficeを使いたい場合Office入りAMIを使ってください。
Office入りAMIを使う際はライセンス管理のために、
- ユーザー認証にAWS Managed Microsoft ADが必須
- ライセンス管理のためにAWS License Managerの利用が必須
- OfficeライセンスアクティベーションのためにVPC Endpointが必須
- Active DirectoryとのDNS連携のためにRoute 53 Resolver Outbound Endpointが原則必須
と多くの前提条件があります。
これらの条件をクリアしてでもEC2を導入すべきかを慎重に考えることを推奨します。
Office入りAMIが提供される以前はSPLAのService ProviderからOffice入りの環境を提供してもらうしかありませんでした。
一応現在もこの方式は使えるのですが2025年9月30日まで期限付きとなります。2025年9月30日以後は利用不可なので今から導入するのは決しておススメできません。
注意 : 自分でOfficeをインストールしないでください
なお、間違っても手持ちのOfficeソフトウェアを勝手にEC2にインストールしないで下さい。
確実にライセンス違反になります。
Microsoft Officeライセンスの複雑さ
Microsoft製品はそれぞれ固有のライセンス条項があり、Officeも独自のライセンスの元で提供されています。
Officeの販売形態としては大きく
- 買い切り版 : リテール版やボリュームライセンス版Office(Office LTSC 他) など
- サブスクリプション版 : Microsoft 365 Apps（旧：Office 365 ProPlus）など
の2形態ありますが、どちらも個人のクライアント端末か組織が保有するハードウェア環境(要はオンプレ環境)でのみインストールして利用可能です。
クラウド環境などのサービス事業者がハードウェアを所有する環境には原則として *1持ち込めません。
クラウド環境でOfficeを利用するにはAzure、Microsoftが認めたホスティング事業者(QMTH)、SPLA Service Providerによるサービスとしての提供のいずれかである必要があります。
細かい話はWindows Virtual Desktop ライセンスガイドに記載されていますのでご一読ください。
(Windows Virtual Desktop ライセンスガイド P28より引用)
追記
2022年10月のライセンス改定によりクラウド環境へのOffice導入に対する制限が緩和されたのですが、それでも「Listed Providerは除く」ためAWSに関しては従来通り何も変わりありません。
2022年10月のライセンス改定によりクラウド環境へのOffice導入に対する制限が緩和されたのですが、それでも「Listed Providerは除く」ためAWSに関しては従来通り何も変わりありません。
AWSの場合
上記の表に関してAWS環境においては以下の通りとなります。
| 環境 | 対象ソフトウェア | AWSでの利用可否 |
|---|---|---|
| 占有ホスト (Dedicated Hosts) | Office Professional Plus | OK : AWSサービス利用 or SPLA提供であれば可能 |
| 占有ホスト (Dedicated Hosts) | Microsoft 365 Apps | NG : AWSでは利用不可 |
| 共有ホスト (通常のEC2) | Office Professional Plus | OK : AWSサービス利用 or SPLA提供であれば可能 |
| 共有ホスト (通常のEC2) | Microsoft 365 Apps | NG : AWSでは利用不可 |
雑に言ってしまえば、サブスクリプション版OfficeはAWSで一切利用不可、買い切り版OfficeであればAWS公式サービスを使うか2025年9月30日までならSPLA提供のものを使うことができる、といった感じです。
ユーザーが購入したOfficeをAWSに持ち込むことはどちらの場合も出来ません。BYOL不可です。
ただし、ひとつだけ例外があり、2019年10月1日以前に購入した製品であれば占有ホストでのみ購入したバージョンのOfficeをBYOLすることが可能です。
これは2019年10月1日を境にライセンス上の占有ホストの扱いが異なるためです。
(Windows Virtual Desktop ライセンスガイド P30より引用。ピンク字の強調は筆者が加筆)
とはいえ、この場合Officeのバージョンアップは不可ですので、2022年も終わりつつある今現在では決しておススメできる方法ではありません。
Officeのサーバーサイドオートメーション
Officeを利用可能な環境の時点で十分めんどうな感じではありますが、Officeの利用形態においても問題があります。
私のこれまでの経験上EC2でOfficeを利用する用途としてバッチ処理でOfficeを使うといった「サーバーサイドオートメーション」の要望が多いのですが、Officeのサーバーサイドオートメーションはそれ自体が多くの問題をはらんでいます。
そもそもOfficeはクライアント環境において対話的に利用することを前提としたソフトウェアであり、非対話的に利用するのはサポート外です。
Microsoftでは、無人の非対話型クライアント アプリケーションまたはコンポーネント (ASP、ASP.NET、DCOM、NT サービスを含む) から Office アプリケーションをMicrosoft自動化することは現在推奨されておらず、サポートされていません。この環境で Office を実行すると、Office が不安定な動作やデッドロックを発生する可能性があるためです。
ライセンス面でも
技術的な問題とは別に、ライセンスの問題も考慮する必要があります。 現在のライセンス ガイドラインでは、クライアントにライセンス認証済みの Office がインストールされている場合を除き、クライアント要求を処理するサーバー上で Office アプリケーションを使用することは禁じられています。
といった形で全ての利用クライアントにOfficeが必要ですのでご注意ください。
非公開情報 : SPLAではOfficeのサーバーサイドオートメーションは禁止されている
また、公開できるソースは無いのですが、以前とあるSPLAリセラー *2に対しSPLA契約下でのOfficeサーバーサイドオートメーションについて問い合わせたところ、
Microsoftの内規によりSPLA契約においてOfficeのサーバーサイドオートメーションは禁止されている
旨の回答をもらった事があります。
公開されたソースが無いため上記を裏付ける証拠を出せないのが心苦しいですが、SPLAで提供されるOffice SALはユーザーライセンスのみの提供であり、デバイスライセンスを前提とするサーバーサイドオートメーションと矛盾するため禁止されているんだと推測されます。
AWSにおいて禁止されているかは未確認ですので、必要がある方はAWSサポートに問い合わせると良いでしょう。
(私個人としては「そもそもサーバーサイドオートメーションを使うべきでない」という考えのためサポートに確認する予定はありません)
リモートデスクトップ接続
EC2でOfficeを使う場合、対象のインスタンスにはリモートデスクトップ接続でログインする必要があります。
Windows Serverのデフォルトでは「管理用途に限りデフォルトで同時2セッションまでRDP接続可能」となっていますが、Officeの利用は基本的に管理用途には当てはまりません。
このためAWSが提供するOffice入りAMIの利用においてもRemote Desktop Service SAL(RDS SAL)のサブスクライブが必須となっています。
加えてユーザーライセンスのRDS CAL/SALを管理するにはActive Directory環境が必要です。
Office入りAMIを利用する際にAWS Managed Microsoft ADを使うのはこういった事情があります。 *3
利用者から見れば「単純にOfficeを使いたい」だけかもしれませんが、Microsoftライセンスの都合重厚な環境が必要となります。
まとめ
以上となります。
AWSでMicrosoft Officeを使うにはライセンス面および環境面で多くの面倒ごとがあるのがご理解いただけたと思います。
個人的には「AWSではMicrosoft Officeを使わない」のが一番お勧めできますが、どうしても必要な場合はAWS公式のサービスを使う様にしてください。
この記事は最初に書こうと思った時から1年くらい寝かせてしまっていたのですが *4、先日のSPLAライセンス改定の話も出てきたので気合いで再構成して書き直しました。
Microsoftライセンスのつらみが少しでも共有できれば幸いです。
15
