EC2 シリアルコンソールを試してみました

11095 ワード
シリアルコンソール トラブルシューティング EC2 障害対応 AWS AWS テキストリンク

こんにちは。
今回は、オンプレミスのデータセンターやマシンルームでよく使っていた、シリアルコンソール接続が AWS でサポートされたので、早速、試してみました。

筆者自身、クラウド関係の業務に従事する前は自社サーバーやストレージの検証などをマシンルームでよく実施しており、実際にシリアルコンソールから操作していたことがありました。
例えば、設定をミスして SSH の接続ができなくなった際にシリアルコンソールからログインして、修復するといったこともありました。

というわけで、Amazon EC2 の EC2 シリアルコンソールについてみていきましょう。

前提条件

  • EC2 シリアルコンソールの設定を行うのに必要な権限
    (AWS のアカウントレベルで使わせたくない！という場合は SCP で以下のアクションを Deny する)
    • EC2 シリアルコンソールの設定状況を表示：EC2 の GetSerialConsoleAccessStatus
    • EC2 シリアルコンソールの有効化：EC2 の EnableSerialConsoleAccess
    • EC2 シリアルコンソールの無効化：EC2 の DisableSerialConsoleAccess
  • 操作する IAM ユーザーに必要な権限
    • EC2 Instance Connect の SendSerialConsoleSSHPublicKey
  • 接続する Amazon EC2 インスタンスの稼働システム
    • AWS Nitro System なインスタンスタイプ
      本記事では t3.micro で確認。
  • 接続する EC2 インスタンス側に必要な設定(事前に仕込んでおく必要あり)
    • OS 側の root ユーザーのパスワード
  • 接続する EC2 インスタンスの OS が Windows の場合の設定
    • Emergency Management Service(EMS) の有効化
  • EC2 シリアルコンソールが利用可能なリージョンであること
    現時点では以下のリージョンで利用可能です。
    • バージニア北部(us-east-1)
    • オハイオ(us-east-2)
    • オレゴン(us-west-2)
    • アイルランド(eu-west-1)
    • フランス(eu-west-3)
    • シドニー(ap-southeast-2)
    • 東京(ap-nourtheast-1)
  • 接続不可になった Amazon EC2 インスタンスをどうにかして直したい！という熱い気持ち

実際に試してみよう

EC2 シリアルコンソールの有効化

初回の設定時は、EC2 インスタンスを選択して、接続 ＞ EC2 シリアルコンソール で以下の表示がされるので、Manage access ボタンをクリックして設定画面を表示します。

Allow にチェックをいれて、 Update ボタンをクリックする。

すると、以下の様に表示されます。

しかし、1度設定してしまうと、接続 ＞ EC2 シリアルコンソール では以下の表示になり、設定変更(無効化)が行えません。

答えは EC2 ダッシュボードにありました！

上図で囲われている箇所をクリックすることで、前述の設定画面が表示されます。

この EC2 シリアルコンソールの設定は、各リージョンごとに有効、無効を分けて設定可能のようです。例えば、東京リージョンで有効化しても、シドニーリージョンでは明示的に有効化するまでは無効状態です。

AWS CLI を使った設定確認や有効、無効化も試してみよう

前提条件にあるEC2 シリアルコンソールの設定を行うのに必要な権限を有した状態で、以下のコマンドを実行します。
本記事執筆時点(2021/4/6JST)では AWS CloudShell 上の AWS CLI のバージョンでは未対応でしたので、アップデートが必要です。

状態確認
$ aws ec2 get-serial-console-access-status
{
    "SerialConsoleAccessEnabled": true
}

SerialConsoleAccessEnabled の値が true になっているので、有効状態であるということがわかります。

有効化
$ aws ec2 enable-serial-console-access 
{
    "SerialConsoleAccessEnabled": true
}

戻り値として、SerialConsoleAccessEnabled が true で表示されてわかりやすいです。

念のため、状態確認のコマンドも実行します。

$ aws ec2 get-serial-console-access-status
{
    "SerialConsoleAccessEnabled": true
}

SerialConsoleAccessEnabled の値が true になっているので、有効状態であるということがわかります。

無効化
$ aws ec2 disable-serial-console-access 
{
    "SerialConsoleAccessEnabled": false
}

こちらも戻り値として、SerialConsoleAccessEnabled が false で表示されてわかりやすいですね。

念のため、こちらでも状態確認のコマンドも実行します。

$ aws ec2 get-serial-console-access-status
{
    "SerialConsoleAccessEnabled": false
}

SerialConsoleAccessEnabled の値が false になっているので、無効状態であるということがわかります。

シリアルコンソールで接続する

つないでみる

前提条件を満たし、 EC2 シリアルコンソールの有効化をしていれば、接続したい EC2 インスタンスを選択したうえで、接続 ＞ EC2 シリアルコンソール で以下の様に、「接続」ボタンをクリックすればOKです。

Linux の場合

上記操作後、ログイン待ち状態が表示されます。
シリアルコンソール接続をしたまま、OS再起動すると、起動時のログも流れて表示されます。

ここで、前提条件にも記載した通り、ユーザー名とパスワードを入力すると、ログインが行えるので、ログの確認をしたり設定ミスをした設定ファイルの修復をしたりといった作業を行います。

Windows の場合

前提条件に記載の通り、Emergency Management Service(EMS) が必要であり、EMS の主要機能である Special Admin Console(SAC)で接続が可能です。

下準備として、以下のコマンドを Windows サーバー上で実行しておく必要があります。

Powershell の場合：

bcdedit /emssettings EMSPORT:1 EMSBAUDRATE:115200
bcdedit /ems '{current}' on
shutdown /r /t 0

コマンドプロンプトの場合：

bcdedit /emssettings EMSPORT:1 EMSBAUDRATE:115200
bcdedit /ems {current} on
shutdown /r /t 0

上記コマンドで設定済みの Windows サーバーに対して、シリアルコンソールで接続すると以下の様に表示されます。

Computer is booting, SAC started and initialized.                               

Use the "ch -?" command for information about using channels.                   
Use the "?" command for general help.                                           


SAC>                                                                            
EVENT: The CMD command is now available.                                        
SAC>

SAC では CMD コマンドでコマンドプロンプトのチャネルを開きます。

SAC>cmd
The Command Prompt session was successfully launched.
SAC>
EVENT:   A new channel has been created.  Use "ch -?" for channel help.
Channel: Cmd0001
SAC>

そして、開いたチャネルに ch コマンドで接続します。

SAC>ch
Channel List

(Use "ch -?" for information on using channels)

# Status  Channel Name
0 (AV)    SAC
1 (AV)    Cmd0001
SAC>ch -si 1

以下の様に表示されるので、問題なければ、 Enter キーを押下します。

Name:                  Cmd0001
Description:           Command
Type:                  VT-UTF8
Channel GUID:          ********-****-****-****-************
Application Type GUID: ********-****-****-****-************

Press <esc><tab> for next channel.
Press <esc><tab>0 to return to the SAC channel.
Use any other key to view this channel.

以下の画面になったら、 Administrator ユーザーのユーザー名と必要に応じてドメイン名、ユーザーのパスワードを入力します。

Please enter login credentials.
Username: Administrator
Domain  : 
Password: ********************************

ログインが成功すると、Administrator ユーザーのコマンドプロンプトに接続ができます。

Microsoft Windows [Version 10.0.17763.1817]                                     
(c) 2018 Microsoft Corporation. All rights reserved.                            

C:\Windows\system32>

ここまできたら、reg コマンドを使ったりファイル操作をしたり、 powershell を使ったりすることができます。
これで RDP などによる接続ができない状態になってもトラブルシューティングができるようになります。

まとめ

これまで、iptables の設定ミスや各種設定ファイルの破損などで EC2 インスタンスに接続できなくなった場合は、以下の手順で復旧を試みることが多かったです。

  1. 変更作業前に取得した Amazon Machine Image(AMI) で復旧する。
  2. 接続不可の EC2 インスタンスを一度停止して、 EBS ボリュームをデタッチし、別の EC2 インスタンスにアタッチして設定ファイルの修正を行い、正常な状態にして元の EC2 インスタンスで再アタッチして起動する。

どちらも、停止を伴うため、現在、処理中のデータなどがある場合は中途半端になったり欠落したりといったことが想定されます。また、例えば、単に SSH 接続ができないだけで、それ以外のシステム的には問題ないといった場合には、簡単に再起動はできないといった事情もあると思います。

そういった、停止しづらいシステムでかつ、AWS Systems Manager のセッションマネージャーが利用できないといった EC2 インスタンスへ接続ができない際のトラブルシューティングで効いてくるのかと考えます。

記載されている会社名、製品名、サービス名、ロゴ等は各社の商標または登録商標です。