Amazon EC2上で稼働しているWindows ServerをAWS Systems Manager Automationを使ってバージョンアップしてみた

amaebi

2023.8.10

Topics

はじめに
バージョンアップによる懸念点
SSM Automation
前提条件
対応OSの種類
手順
まとめ

はじめに

こんにちは、マイグレーションチームのamaebiです。
突然ですが、皆さまはWindows Serverのサポート期限について、気にしたことはありますか？普段業務していると、そんな面倒くさいことはつい後回しにしてしまいますよね…

ですが、現在EC2で稼働しているWindows Server 2012/Windows Server 2012 R2のサポート期限があと2か月だというのをご存じでしたか？
そう言われてもファイルデータ、ユーザー情報などを考えるとそう簡単にOSをバージョンアップさせるなんて難しい話です。

そこで、EC2で稼働しているWindows ServerのOSを簡単にバージョンアップする方法についてご紹介します。

ちなみに、Windows Serverのサポート期限は以下の通りです。

OS名	サポート終了日	延長サポート終了日
Windows Server 2012	2018年10月9日	2023年10月10日
Windows Server 2012 R2	2018年10月9日	2023年10月10日
Windows Server 2016	2022年1月11日	2027年1月12日
Windows Server 2019	2024年1月9日	2029年1月9日
Windows Server 2022	2026年10月13日	2031年10月14日

出典：Windows Server 2012 ライフサイクル
出典：Windows Server 2012 R2 ライフサイクル
出典：Windows Server 2016 ライフサイクル
出典： Windows Server 2019 ライフサイクル
出典：Windows Server 2022 ライフサイクル

バージョンアップによる懸念点

Windows Serverのバージョンアップを行う際に、どうしても様々な懸念点が発生します。

バージョンアップに対して人員や時間を費やしたくない
バージョンアップ失敗によるWindows Serverのロールバックは可能だろうか
ユーザー情報やフォルダ、ファイルに影響はないのだろうか
バージョンアップ後もバージョンアップ前と同じように使えるのだろうか
Windows Serverを何時間止めるのだろうか

どうしてもこのような懸念点の影響で、OSのバージョンアップに踏み込みづらい方も多いと思います。
そこで、今回取り上げた不安を抱えた方にも安心してバージョンアップできる便利なサービスについて紹介していきます。

SSM Automation

どうやってバージョンアップするのかと言いますと、AWSが提供するAWS Systems Managerの機能のひとつであるSSM Automationというサービスを利用して行います。
SSM Automationは、EC2やRDS、S3、Redshiftなど幅広いサービスのタスク(メンテナンス、デプロイ、修復)を自動化してくれるサービスなっております。
今回は、SSM AutomationのAWSEC2-CloneInstanceAndUpgradeWindowsという機能を利用して、EC2のWindows Serverのバージョンアップをします。バージョンアップの構成図は以下のようになります。(Windows Server 2012 R2 から Windows Server 2022へのバージョンアップを想定しております。)

上の構成図のようにSSM Automationを使用してEC2(Windows Server 2012 R2)からAMI(Windows Server 2022)を作成したのち、取得したAMIから手動でEC2立ち上げ、切替を行います。

SSM Automationを使用することで、現在皆さまが抱えている懸念点を解消するメリットがございます。

バージョンアップの自動化による工数削減

バージョンアップを手動で行うことなく、自動で行うことにより無駄な人員の削減やヒューマンエラーの防止になります。さらに、最初からテンプレート化されているタスクを実行するだけで、簡単にバージョンアップできるためタスク作成の作業も削減できます。
ただし、OSのバージョンアップには数時間ほどかかる可能性がございます。(バージョンアップ中に本番稼働中のWindows Serverを止める必要はございません。)

EC2の複製により失敗時の切り戻しが容易に

あくまでも、本番稼働中のEC2からAMI取得し、取得したAMIからバージョンアップさせるため、何か問題が発生した場合でもすぐに本番稼働中のEC2に切り戻せます。

ユーザー情報やフォルダ、ファイルなどを全てコピー

前述したように、本番稼働中のEC2からAMI取得し、取得したAMIからバージョンアップさせるため、ユーザー情報やフォルダ、ファイルなどの基本情報はすべてコピーされます。ですので、現在本番稼働中のWindows Serverと変わらずに使用することができます。
ただし、OSのバージョンによっては、アプリケーションが対応していない可能性がございますのでご注意ください。

本番稼働中のWindows Serverへの影響はAMI取得のみ

本番稼働中のEC2からAMIを取得します。その際に、本番稼働中のEC2に影響を与えるのはAMI作成中のみとなります。そのため、長時間によるサーバー停止やWindows Serverの大きな影響なく安全にバージョンアップを行うことができます。
可能であれば本番稼働中のEC2再起動によるAMI作成が、より精度の高いAMIを作成できます。

出典：AWS Systems Manager Automation

では、実際にSSM Automationを使用したOSのバージョンアップについて、具体的に見てみましょう。

前提条件

前提条件として、下記の確認が必要です。(公式ドキュメントから一部抜粋しております。)
細かい前提条件を確認したい場合は、公式のドキュメントを参照してください。

前提条件

Microsoft Active Directory ドメインに参加しているインスタンスの場合は、ホスト名の競合を避けるために、ドメインコントローラーに接続できない SubnetId を指定することをお勧めします。

このオートメーションは、暗号化されていない Amazon EBS ルートボリュームを持つ Amazon EC2 インスタンスでのみ動作します。指定されたインスタンスに暗号化されたルートボリュームがある場合、オートメーションは失敗します。

インスタンスでブートディスクに 20 GB の空きディスク領域があることを確認します。

出典：自動アップグレードの実行

対応OSの種類

バージョンアップに対応しているOSは以下の通りです。

Windows Serverの自動アップグレードパス

Systems Manager オートメーションランブック AWSEC2-CloneInstanceAndUpgradeWindows は次のアップグレードパスをサポートしています。

Windows Server 2008 R2 から Windows Server 2012 R2 へ

Windows Server 2012 R2 から Windows Server 2016 へ

Windows Server 2012 R2 から Windows Server 2019 へ

Windows Server 2012 R2 から Windows Server 2022 へ

Windows Server 2016 から Windows Server 2019 へ

Windows Server 2016 から Windows Server 2022 へ

Windows Server 2019 から Windows Server 2022 へ

出典：自動アップグレードの実行

今回は、サポート終了直前であるため、Windows Server 2012R2からWindows Server2022へのバージョンアップを行っていきます。

手順

大まかな手順としては以下になります。

SSM Automation用のIAM RoleをEC2(Windows Server 2012R2)にアタッチ
SSM Agentの確認
SSM Automationを実行
作成されたAMI(Windows Server 2022)からEC2(Windows Server 2022)を作成
バージョンアップしたWindows Serverの比較
切替

それでは、より詳細な作成方法を見ていきましょう。

SSM Automation用のIAM RoleをEC2(Windows Server 2012R2)にアタッチ

AmazonSSMManagedInstanceCoreを対象のEC2(Windows Server 2012 R2)に付与することで、AWS Systems Managerへのアクセス許可が付与されます。これにより、SSM Automationなどのコア機能が利用可能になります。
引用:AmazonSSMManagedInstanceCore

注意！！

対象のEC2に既存のIAMロールがアタッチされている場合は、そのIAMロール自体にAmazonSSMManagedInstanceCoreポリシーを適応してください。

既存のIAMロールがアタッチされている場合

マネジメントコンソール＞ EC2 ＞インスタンスから該当のインスタンス(Windows Server 2012R2)を選択し、インスタンスの状態＞セキュリティ＞ IAM ロールを変更をクリックします。

既存のIAMロールを確認し、名前をコピーしておきます。

マネジメントコンソール＞ IAM ＞ロールから検索欄に先程コピーしたIAMロール名をペーストします。そこからヒットしたIAMロールをクリックします。

許可タグから許可を追加＞ポリシーのアタッチをクリックします。

その他の許可ポリシーからAmazonSSMManagedInstanceCoreと検索し、該当するポリシーを選択してから、許可を追加をクリックします。

許可ポリシーからAmazonSSMManagedInstanceCoreが適応されていることを確認してください。確認できましたら、IAMロールのアタッチは完了です。

既存のIAMロールがアタッチされていない場合

マネジメントコンソール＞ IAM ＞ロールからロールを作成をクリックします。

AWSのサービスを選択し、下のユースケースでEC2を選択して、次へをクリックします。

許可ポリシーからAmazonSSMManagedInstanceCoreと検索し、該当するポリシーを選択してから、次へをクリックします。

ロール名と説明を記載し、

選択したポリシーが間違っていないか確認してからロール作成をクリックします。

先程作成したIAMロールを選択してからIAMロールの更新をクリックすればIAMロールのアタッチが完了です。

SSM Agentの確認

SSM Agentをインストールすることで、AWS Systems Managerを利用したリソースの更新、管理、設定ができるようになります。
引用:SSM Agent の使用

PS C:\Users\Administrator＞ Get-Service AmazonSSMAgent

Status   Name               DisplayName
------   ----               -----------
Running  AmazonSSMAgent     Amazon SSM Agent

EC2(Windows Server 2012R2)にRDPを行い、PowerShellから上記のコマンドを入力するとSSM Agentがインストールされているかが確認できます。さらに、StatusがRunningなっていることを確認してください。
引用:SSM Agent ステータスの確認とエージェントの起動

PS C:\Users\Administrator＞ Get-Service AmazonSSMAgent

Status   Name               DisplayName
------   ----               -----------
Stopped  AmazonSSMAgent     Amazon SSM Agent

※もしSSM AgentのStatusがStoppedだった場合、次のコマンドでSSM Agentを起動してください。

PS C:\Users\Administrator＞ #AmazonSSMAgentを起動
PS C:\Users\Administrator＞ Start-Service AmazonSSMAgent
PS C:\Users\Administrator＞
PS C:\Users\Administrator＞ #AmazonSSMAgentが起動しているかの確認
PS C:\Users\Administrator＞ Get-Service AmazonSSMAgent

Status   Name               DisplayName
------   ----               -----------
Running  AmazonSSMAgent     Amazon SSM Agent

Start-Service AmazonSSMAgentコマンドを使用することで、AmazonSSMAgentを起動することができます。必ずGet-Service AmazonSSMAgentコマンドでStatusは確認してください。

マネジメントコンソール＞ Systems Manager ＞フリートマネージャーから該当のEC2(Windows Server 2012R2)のノードの状態が実行中になっていることを確認してください。実行中の確認が終わりましたらSSM Agentの確認は完了です。