今回は続いて投稿できました！ばんざーい🙌
と、喜んでいる場合ではないですが、AWSでOffice付きWindowsServerの構築を試した記事となります。
はい、もりりんです。
今回はRPAではなくAWSに関するお話です。
紹介する構築方法は、2022時点に公開された情報を元に試しています。
AWSのコンソールは変わっていますが、設定する内容は変わっていなかったためスムーズにできました。
詰まるとすれば、VPC等のネットワーク周りでのアクセス制限の設定ミスかと思います。
では、さらっと流していきましょう。
過去のAWS記事
普段EC2はAmazon LinuxかUbuntuでの構築となりますが、今のところWindowsServerはRPAぐらいでの利用となります。
また、弊社がAWS上にRPA環境を構築した際はOffice付きAMIは対応されておらず、Officeなしで構築しています。
BizRobo!の導入は過去でも紹介しているため、AWSの紹介のみとなっております。
環境さえ構築してしまえば、環境構築マニュアルをそのまま設定していくだけですね。
ホスト名の指定は注意しましょうというところですね。
AWSでOfficeを操作できる環境の構築について
調べると色々なブログが出てくるので詳細は割愛しますが、Microsoftのライセンスポリシーの変更により、クラウドベンダーが提供するサーバ内でOfficeを利用する方法に規制がかかりました。
2019、2022にOfficeを含むMicrosoft製品をクラウドベンダー上のサービスで利用する規約に大きな変更があり、それに応じてAWSが対応しています。
サーバ用途でなければ、Amazon WorkSpacesでOfficeが利用できるため、そちらの採用が費用的にも一番かと思います。
が、そうでなく！サーバ上でOfficeを使いたいんだ！という場合には、AWSの提供方法に従って構築していきます。
AWS記事がわかりづらいという方は、他の方のブログも参考に構築していきましょう。
2022リリース当時に執筆されたブログが多いため、コンソール等の仕様変更による操作の違いには注意しましょう。
また、注意点としてはAWSから購入したOfficeやRDPライセンスを月払いのサブスクリプション形式（日割り不可）での利用となります。
毎月費用が発生しますので、それを加味して利用するかどうかを検討してください。
なお、現在Officeバージョンは2021のみの固定となり、他バージョンを利用することはできません。
Officeを利用するために必要な構成と費用について
最初に費用について記載しておこうと思います。
正直小規模環境だと利用するメリットなさそう…という感じでかなり割高となります。
検証時に構築した最小構成だと思われるイメージ図は以下です。
冗長構成にはしていないため、必要な場合は別途NATゲートウェイ等を追加してみてください。
Officeを利用できる環境を維持する最低料金が約$300、ここにライセンスが追加費用となります。
サーバが1台のみの最小構成で利用すると、サーバ費用より高くなる可能性が高いです。
必要なサービス明細は以下となります。
通信/転送料は含んでいないため、ここに記載している額＋αとなると考えてください。
| AWS Managed Microsoft AD (Standard Edition) | 約$109/月（ドメインコントローラー2つ分） |
| LicenseManager Endpoint | 約$10/月 |
| Route 53 Resolver Outbound Endpoint | 約$180/月（2AZにエンドポイントを設置するため、$90/月を2台分） |
| ライセンス（Office/RDP） | $31.43/月（Officeは$21.43、RDPは$10） ※ユーザごとの課金と記載されているので、利用しているADユーザ分かかる？ |
サーバ数が多いと、その程度か…っとなるかもしれませんが、思ったより維持費高いなと思うため、RDP元のPCで処理できるのであればそちらで利用したほうがいいかと思います。
ただし、BizRobo!の場合はDAというリモートPCが必要になることがあるため、そちらをAWS上で設ける場合は検討する内容になります。
どのみち、費用に見合うか、本当にサーバにOfficeが必要なのかを確認した上で構築する必要があります。
環境の構築手順
色々前提条件等の記載が必要になるかと思いますが、今回は簡単な説明なため大幅に割愛しています。
私が構築した手順は以下です。
- VPC周りを作成（ネットワークACL、セキュリティグループ、NATゲートウェイ）
- Microsoft ADサーバを作成
- ライセンスマネージャーの設定
- Route53 Resolver Outboundの作成
- 捨て管理端末をADユーザを作成
- ライセンスをサブスクライブ
- EC2を作成
- ライセンスマネージャーでOfficeライセンスとADユーザを紐付け
- Windowsの初期設定
先に提示した画像ベースで作成します。
検証後にパブリックサブネットのみの構成に移行しましたが、特に問題なく動作しました。
ただし、外部からアクセスされないようネットワークACL、セキュリティグループは見直しましょう。
Office付きWindowsAMIでログインできるADユーザのAdminを作成します。
管理者権限を持った１ユーザしか作成されないため、設定したパスワードを忘れないように控えておきます。
他ユーザが必要な場合、Step5でユーザを作成します。
2つ以上のAZに属するサブネットを指定する必要があります。
Step1で事前に作成したプライベートサブネットを指定しましょう。
作成には時間がかかるため、しばらく待ち時間です。
私の場合、40分ほど待ちました。
ライセンスマネージャーを一度も利用したことがない場合、最初にアクセスロールの付与ダイアログが表示されるため許可しましょう。
設定からADサーバの紐付けを設定しますが、先ほどと同様にロールの付与ダイアログが表示されるので許可します。
「設定メニュー」 – 「ユーザーベースのサブスクリプション」の設定ボタンから先ほど作成したADサーバとOfficeの紐付けを追加します。
ライセンスを選択すると、VPC、サブネット、セキュリティグループの紐付けを選択します。
セキュリティグループは「1688」ポートのみ許可した専用のセキュリティグループを用意しましょう。
EC2からADサーバへの名前解決ができないということで、EC2→Route53へのルート作成します。
なお、ここでもRoute53用のセキュリティグループが必要になるため、TCP/UDPの53ポートを許可したセキュリティグループを作成しておきましょう。
リゾルバーの作成にも時間がかかるので、しばらく待ちましょう。
ここまでくると、ADサーバを利用したOffice認証が可能となっています。
ただし、ADサーバではAdminユーザしか作成されていないため他ユーザでのログインができません。
ユーザが複数必要な場合は、一時的に管理端末を設けてADユーザを追加しておきましょう。
管理端末を作成する場合は、通常のWindows AMIを利用し、高度な設定で「ドメイン結合ディレクトリ」にADサーバを指定します。
起動したら、RDPでログインし、Windows上でドメイン参加、ADサーバに関する機能の追加を実施します。
ADユーザの追加は、「サーバーマネージャー」 – 「ツール」から起動した「Active Directory Users and Computers」から設定しましょう。
ここからOffice付きWindowsを作成するための準備をします。
ライセンスマネージャー経由でAWS Marketplaceより、下記2つのライセンスを購入します。
- Office LTSC Professional Plus
- Remote Desktop Services SAL
購入すると、ライセンスがアクティブ状態となります。
実際に利用するEC2をOffice付きWindowsAMIで作成します。
なお、EBSは100GB以上必要です。
見落としやすい項目ですが、高度な設定の「リソースベースのIPv4（Aレコード）DNSリクエストを有効化」にチェックが入っているか確認してください。
起動が完了すると、System Manager（以降、SSM）経由でRunCommandが2つ実行されます。
EC2の起動を確認したら、OfficeライセンスとADユーザを紐づけます。
ライセンスマネージーを確認すると、Office付きAMIで起動しているEC2を確認できます。
インスタンスを選択し、ADユーザの紐付けを実施します。
ユーザーを関連付ける、ユーザーをサブスクライブして関連付けるの2つがありますが、使い分けは以下となります。
- ユーザーを関連付ける：既に紐付け済みのADユーザを利用する場合
- ユーザーをサブスクライブして関連付ける：新規ADユーザを利用する場合（ = 課金）
最初は、「ユーザーをサブスクライブして関連付ける」からADユーザ名とADドメインで登録します。
紐付けが完了すれば、ADユーザでログインしましょう。
WindowsServerが英語用なので、日本語化やUIのアニメーション設定を調整します。
ADユーザがドメインユーザグループのみに所属している場合、日本語パックのインストールに失敗するため管理者グループを付与する必要があることは注意ですね。
また、ドメインユーザグループのみの場合、Windowsメニューに再起動、シャットダウンメニューが表示されないため、必要な場合は管理者グループに所属させておきましょう。
もし管理者グループ以外でもできるようでしたら、権限が小さい方がいいかもしれません。
試してみての感想
EC2インスタンスは、t3.large、t3.xlarge、m4.largeで試しました。
RDP経由だと、Tomcat、MySQLを起動した状態の8Gibでもそこまで遅延は感じませんでした。
ただし、AWSコンソール上でのSSM経由RDPだと、かなりもっさり感が強かったです。
xlargeだとかなり改善されましたが、そこはコンソール上でリモートしているからでしょう。
何気にSSM経由のRDPは便利ーーーって思ったので、Windowsを利用する際はこちらの機能も利用していこうと思います。
Officeバージョンについては前述しましたが、2021固定となります。
自宅PCや会社PCでOfficeバージョンが異なる場合は、互換性を意識して利用していく必要がありますね。
さほど影響はないかと思いますが…
しかし、環境維持コストが気になるところですね。
AD認証の環境を維持するだけで$300程度が必要となるため、本当にOfficeが必要なのか？と再検討はしていただきたいところです。
Azureは専門ではないですが、同規模での費用感の比較をしたいところです。（頑張って調べます😂）
今回は、ここまでとなります。
今後もRPA以外のブログを執筆していきますので、少しでもどなたかの参考になると幸いです。