AWSのOffice on EC2が即終了する原因と解決策

目次

• 導入：なぜOffice on EC2をSSMで安全に管理しようと思ったのか
• この記事で登場する主要サービス
  • AWS Systems Manager (SSM)とは？
  • AWS License Managerとは？
  • DHCPオプションセットとは？
• 最初の壁: SSMに繋がらない！ IAMロールとセキュリティグループとの格闘
• 見えない壁: ネットワークは正しいはずなのに…VPCエンドポイントの罠
• 最大の謎: なぜライセンス付きAMIだけが終了するのか？ DHCPオプションセットが根本原因だった話
• 補足：見落としがちなライセンスマネージャーのユーザー登録
• まとめ

導入：なぜOffice on EC2をSSMで安全に管理しようと思ったのか

「Microsoft Office付きEC2インスタンス」を起動してみたところ、なぜか数分で勝手に終了してしまう。。。そんな不可解な問題に直面したことはありませんか？

クラウドでのサーバー管理といえば「踏み台サーバー」を構築してアクセスするのが一般的でした。しかしこの方法は、維持コストや常時公開によるセキュリティリスクが課題です。
そこで現在のAWSが推奨しているのが AWS Systems Manager (SSM) を使った管理方式です。SSMを利用すれば、すべてのセキュリティポートを閉じたまま、安全かつ効率的にインスタンスへアクセスできます。

本記事では、このSSM方式でOffice付きEC2を構築しようとした際に遭遇した「インスタンス即終了問題」と、その解決までの道のりをまとめました。問題の原因は単なる設定ミスではなく、SSMやLicense Manager、Active Directory、そしてVPCのDNS設定など、いくつもの仕組みが影響し合っていました！

この記事が、同じようなトラブルに悩む方の助けになれば幸いです！

今回の記事で扱うOffice on EC2の構成です。

図1：構成図

この環境では、

• 踏み台サーバーを置かず、SSM Session ManagerとVPCエンドポイントを利用してプライベートサブネット内のサーバーへ安全に接続できる
• 各コンポーネントをすべてプライベートサブネットに配置し、インターネットに直接公開しない設計

といった点が特徴になっています。

この記事では、Office付きEC2インスタンスを安定稼働させるまでに経験したトラブルと解決の流れをまとめています。最初に、今回のカギとなったAWSの主要サービスをざっくり紹介します！

この記事で登場する主要サービス

AWS Systems Manager (SSM)とは？

AWS Systems Manager（以下SSM）は、EC2インスタンスをはじめとするサーバー群を、安全かつ効率的に管理するためのサービスです。従来はリモート操作のために特定の通信ポートを開放する必要がありましたが、SSMではその必要がありません。

サーバー内部で動作する「SSM Agent」が、AWSの管理サービスに対して内側から通信を開始する仕組みになっているためです。これにより、外部からのポートをすべて閉じた状態でも、AWSコンソールやCLIを通じて安全にサーバーへアクセスできます。

図2：SSMの役割

AWS License Managerとは？

AWS License Managerは、Windows ServerやMicrosoft OfficeなどのソフトウェアライセンスをAWS上で一元管理するサービスです。特にAWS Marketplace経由で提供される一部ソフトウェアでは、ライセンスがサーバー単位ではなく Active Directoryユーザーに紐づく「ユーザーベースのサブスクリプション」 という形態が採用されています。

License ManagerはActive Directoryと連携し、ユーザーごとの利用権限を集中管理します。EC2インスタンスはログイン時にLicense Managerへ問い合わせを行い、対象ユーザーが正しいライセンスを持っているかどうかを検証します。

DHCPオプションセットとは？

DHCPオプションセットは、VPCに設定することで、その中で起動するEC2インスタンスに対し、基本的なネットワーク設定を自動的に配布する仕組みです。

インスタンスはこの設定を通じて「利用するDNSサーバー」や「所属するドメイン名」といった情報を受け取ります。管理者はオプションセットをカスタマイズすることで、VPC全体のDNS解決やドメイン関連の挙動を統一的に制御できます。

図4：DHCPオプションセットの役割

最初の壁: SSMに繋がらない！ IAMロールとセキュリティグループとの格闘

SSMでサーバーに接続しようとして、まず直面するのが「そもそもSSMの管理画面にインスタンスが表示されない」という最初の壁です。この原因のほとんどは、EC2インスタンス自身が持つべきIAMロールとセキュリティグループという、2つの基本的な設定にあります。

EC2インスタンスがSSMと通信するには、IAMロールを、インスタンス起動時に身につけている必要があります。AmazonSSMManagedInstanceCore というポリシーがアタッチされたこの許可証がなければ、SSM AgentはAWSと対話する権限すら持てません。

さらに、たとえIAMロールを持っていても、インスタンスのファイアウォールであるセキュリティグループが外部への通信をブロックしていては意味がありません。アウトバウンドルールでHTTPS(443)の通信が許可されているか、という確認も必須です。

見えない壁: ネットワークは正しいはずなのに…VPCエンドポイントの罠

SSMがインスタンスを認識しない原因：VPCエンドポイントの不足

IAMロールやセキュリティグループの設定が正しくても、EC2インスタンスがSSMの管理画面に表示されないことがあります。よくある原因のひとつが、VPCエンドポイントの未設定や設定不備です。

プライベートサブネットにあるEC2インスタンスは、インターネットを経由せずにAWSサービスと通信する必要があります。そのためには、以下3つのVPCエンドポイントを作成しなければなりません。

• com.amazonaws..ssm : Run Commandやパッチ管理など、SSMの各種操作に必要
• com.amazonaws..ec2messages : インスタンスがSSMと状態をやり取りするために必要
• com.amazonaws..ssmmessages : Session Managerによるシェル接続に必要

セキュリティグループ設定の見落とし

エンドポイントを作成しただけでは通信できない場合があります。その多くは、VPCエンドポイントに関連付けるセキュリティグループの設定不足が原因です。

具体的には、エンドポイント側のセキュリティグループに HTTPS (443) のインバウンド通信許可 を追加する必要があります。インスタンス側のアウトバウンド許可だけでは不十分で、エンドポイントがリクエストを受け付けられないためです。

この設定を行うことで、SSM Agent がAWSサービスと正しく通信できるようになり、管理画面にインスタンスが表示されるようになります。

私自身もこのセキュリティグループの設定を見落としており、原因が分からず長く時間を費やしてしまいました。。。

最大の謎: なぜライセンス付きAMIだけが終了するのか？ DHCPオプションセットが根本原因だった話

問題

前述のセキュリティグループ設定を修正したことで、SSMの管理下にインスタンスを表示できるようになりました。しかし、別の環境ではさらに厄介な問題に直面しました。Officeライセンス付きのAMIを利用した場合にのみ、EC2インスタンスが起動直後に自動終了してしまう、という問題です。

IAMロール、VPCエンドポイント、セキュリティグループの設定はいずれも問題なく、Reachability Analyzerによるネットワーク経路も正常でした。

調査過程

当初はライセンス認証用の通信経路に問題があると考え、ネットワーク疎通を確認しましたが、対象ホストへの接続はいずれも成功しており、経路自体には問題がありませんでした。

それにもかかわらず認証が失敗し、インスタンスが終了する状況から、DNS解決に関連する設定を確認しました。

原因

根本原因はDHCPオプションセットにありました！

インスタンスは起動時にDHCPオプションセットで指定されたDNSサーバーを利用します。VPCのデフォルトではAmazonProvidedDNS (10.0.0.2など)が割り当てられますが、今回のAMIが要求するのは以下の2種類の名前解決です。

• Active Directory ドメイン(1)
• AWS License Manager(2)

AmazonProvidedDNSは(2)を解決できますが、(1)の内部ドメインは解決できません。このため認証処理の初期段階で失敗し、インスタンスが強制終了していました。

解決策

新しいDHCPオプションセットを作成し、プライマリのDNSサーバーとしてADドメインコントローラーを指定しました。ADのDNSサーバーは(1)を直接解決でき、未解決のクエリをAmazonProvidedDNSへフォワードする設定になっているため、(2)も同様に解決可能です。

この変更により、Officeライセンス付きAMIの認証処理が正常に完了し、インスタンスが終了せず稼働し続けることを確認できました！

補足：見落としがちなライセンスマネージャーのユーザー登録

DHCPオプションセットによるDNS設定を整えても、ライセンス認証が失敗する場合があります。

その原因のひとつが、AWS License Managerにおけるユーザー登録の不足です。Officeのライセンスをユーザーベースで管理している場合、認証時に「ログインしているユーザーがサブスクリプションに含まれているか」が検証されます。

このため、AWSマネジメントコンソールの License Manager → ユーザーベースのサブスクリプション 画面から、対象のADユーザーを追加する必要があります。

もしこの設定を忘れていると、DNSやネットワークが正しくてもライセンス認証は失敗します。確認する際は、対象ユーザーがサブスクリリプションに登録されているかを必ずチェックしましょう！

まとめ

Officeライセンス付きAMIを起動すると、インスタンスが数分で終了してしまう。。。そんな問題に直面しました。

原因を探るために、IAMロール、セキュリティグループ、VPCエンドポイント、ネットワークACLなど、考えられる設定を一通り確認しましたが、どれも問題は見つからず、解決の糸口がつかめないまま苦戦を強いられました。

しかし最終的に、根本原因はDHCPオプションセットにあることが判明しました。

ライセンス付きAMIは、起動直後にActive DirectoryのDNSを正しく参照できることを前提としています。ところが、デフォルトのAmazonProvidedDNSのままでは解決できないドメインが存在し、それがライセンス認証失敗の直接的な要因となっていました。

今回のトラブルシューティングを通じて実感したのは、「仕組みを正しく理解すること」の大切さです。VPC内でのDNS解決の仕組みをきちんと把握していれば、もっと早く問題にたどり着けたかもしれません。

初めて記事にまとめましたが、この記録が同じような問題で悩む方の助けになれば幸いです！