EC2 が起動できない！実例から学ぶ原因と解決策〜オペ部だより〜

実際にいただいた EC2 インスタンスが起動できないというお問い合わせの中から、いくつかの事例とその解決策をご紹介します。

クラスメソッドメンバーズ

#オペレーション

#Amazon EC2

#AWS

#クラスメソッドメンバーズ

#クラスメソッド

池田晃和

2019.08.13

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

こんにちは、札幌在住 AWS 事業本部オペレーション部（通称オペ部）の池田です。オペ部ではクラスメソッドメンバーズにご加入いただいているお客様が直面されたお困りごとや疑問など、様々なお問い合わせに対して各種ドキュメントや技術検証結果のご案内をしたり、場合によっては AWS と連携してお客様が直面している問題解決の支援を行なっています。本記事では、タイトルにある通り実際にいただいた EC2 インスタンスが起動できないというお問い合わせの中から、いくつかの事例とその解決策をご紹介したいと思います（EC2 インスタンスが起動不可となる原因は多岐にわたり、全ての事例と原因を網羅できているわけではありませんが、調査方法の参考にしていただけると嬉しいです）。

インスタンスステータスのチェックが失敗する

事象

AMI を作成して EC2 を起動し、system log では　Login プロンプトが表示されているが、1/2 ステータスチェック失敗となりログインができない。
インスタンスステータスチェックが失敗し SSH 接続ができないため再起動を実施したが解消されない。

確認のポイント

インスタンスステータスのチェックに失敗している場合には下記のような問題が発生しているケースがあります。

インスタンスのステータスチェック - Amazon Elastic Compute Cloud

これらのチェックでは、ユーザーが関与して修復する必要のある問題が検出されます。インスタンスステータスチェックが失敗した場合は通常、自分自身で (たとえば、インスタンスを再起動する、インスタンス設定を変更するなどによって) 問題に対処する必要があります。インスタンスステータスチェックの失敗の原因となる問題の例を次に示します。・失敗したシステムステータスチェック・正しくないネットワークまたは起動設定・メモリの枯渇・破損したファイルシステム・互換性のないカーネル

上記ドキュメントにあるように、インスタンスステータスに失敗している場合はインスタンス内部またはインスタンスの設定に問題があるということですので、落ち着いて以下の点を確認してみましょう。

インスタンスステータスのチェックに失敗していた時間帯の OS の状況（ログファイルからエラー表示を探す）
/var/log/messages
/var/log/cloud-init.log
これらのログは、EBS ボリュームを別のログイン可能なインスタンスへアタッチ、マウントすることで取得が可能です。エラーメッセージが記録されていないか確認を行いましょう。
システムログ（マネジメントコンソール上からアクセスできます）
AMI 作成までの間に実施した作業について（インスタンスへ変更を加えていないか）
ネットワーク設定
カーネルのアップデートなど
これらの変更が原因となるケースもあります。可能なら変更作業を 1項目ずつ行い原因の切り分けを行ってみましょう。
同じ AMI を利用して正常起動できたインスタンスがあるか（あるなら両者の相違点を洗い出す）
ステータスチェックが 2/2 になりログインも成功するインスタンスがある場合、両者間の相違点が原因であると考えられます。よく見比べてみましょう。

解決策

このケースの場合、原因は状況によって様々ですが、前述のようなインスタンスおよび AMI の設定に関する情報を確認することで特定できることが多くあります。設定変更を行う際の注意点などが AWS ドキュメントに記載されていたり、ログファイルに具体的なエラー内容が記載されていることもあります。「早く起動したい」という気持ちをグッとこらえ深呼吸してから調査を行ってみましょう。思わぬ箇所を見落としていたりするかもしれません。インスタンスおよび AMI の設定に問題が見当たらなかった実例として、システムログに「XFS ファイルシステムが壊れていることを示すメッセージ」が記録されているケースがありました。

[    4.172714] XFS (*****): Metadata CRC error detected at xfs_agi_read_verify+0x5a/0x100 [xfs], xfs_agi block 0x23*****
[    4.187751] XFS (*****): Unmount and run xfs_repair
[    4.187752] XFS (*****): First 64 bytes of corrupted metadata buffer:
[    4.187754] ffff8882******: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
[    4.187755] ffff8882******: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
[    4.187755] ffff8882******: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
[    4.187756] ffff8882******: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
[    4.187761] XFS (******): metadata I/O error: block 0x23***** ("xfs_trans_read_buf_map") error 74 numblks 1
[    4.191729] ena: ena device version: 0.10
[    4.191730] ena: ena controller version: 0.0.1 implementation version 1
[    4.223112] XFS (*****): Error -117 reserving per-AG metadata reserve pool.
[    4.246853] XFS (*****): xfs_do_force_shutdown(0x8) called from line 1017 of file fs/xfs/xfs_fsops.c.  Return address = 0xffffffffa01******
[    4.246857] XFS (*****): Corruption of in-memory data detected.  Shutting down filesystem
[    4.262150] XFS (*****): Please umount the filesystem and rectify the problem(s)```

このようなメッセージが記録されている場合、当該パーティションの破損が原因の可能性が高いと考えられます。当該ボリュームをデタッチし、別のインスタンスにアタッチしてマウントが可能か確認してみましょう。マウントがうまくできない場合には、xfs_repair コマンドを利用したファイルシステムの修復を試してみましょう。

作業前に当該ボリュームのスナップショットを作成し、バックアップしておきましょう。

 $ sudo xfs_repair /dev/PATH_TO_DEV

この方法による修復で改善しない場合、対象のファイルシステムが復旧できる可能性は低い状況です。直近のバックアップデータからのリストアを検討しましょう。

権限が不足している

事象

EC2 の起動設定を新規作成したいが、下記のようなエラーが表示され起動設定の作成ができない。

起動設定を作成できませんでした An unknown error occurred

EC2 の起動を行うと status が一時 pending になるものの、すぐに stopped となり起動できない。

確認のポイント

起動設定の作成に失敗する原因として、当該ユーザの権限が不足しているケースが多くあります。

例えば、EC2 インスタンス作成時に IAM ロールを割り当てる場合、当該操作を行う IAM ユーザに iam:PassRole, iam:ListInstanceProfiles, ec2:* のアクセス権限が必要です。対象の IAM ユーザの権限を確認してみましょう。暗号化された EBS ボリュームをアタッチしたインスタンスを起動しようとしている場合、Key Management Service(以下 KMS) へのアクセス権限を IAM ユーザ/ロールにアタッチしておく必要があります。これは、EBS ボリュームの暗号化は KMS により管理されているからです。

解決策

Amazon EC2 でのロールの使用に必要なアクセス許可

Amazon EBS Encryption

前提条件 CMK を EBS 暗号化のデフォルト値として設定するときは、インスタンスの起動、ボリュームの作成、スナップショットのコピー、およびイメージのコピーに CMK を使用できるようにする KMS キーポリシーへのアクセスもユーザーに許可する必要があります。これらのアクセス許可には、GenerateDataKeyWithoutPlainText、Reencrypt*、CreateGrant、DescribeKey、および Decrypt が含まれます。

IAM ロールの割り当てを行なっていない場合や不足していた権限のアタッチでもエラーが解消されない場合、AWS CLI による操作を行った際の出力にエラーメッセージが含まれていないか確認してみましょう。

create-launch-configuration

キャパシティが不足している / 起動数が上限に達している

インスタンスの起動に関する問題のトラブルシューティング

事象

AutoScaling を利用している場合や手動操作で新規インスタンスを起動しようとするがエラーメッセージが表示されて起動できない。

確認のポイント

起動失敗した前後の時間帯の CloudTrail でエラーコード: Server.InsufficientInstanceCapacity が発生し、StartInstances イベントが正常に終了していない。
起動失敗時に下記エラーが表示される（この例では ap-northeast-1c において t2.small のキャパシティが不足していることを表しています）。

A server error (InsufficientInstanceCapacity) occurred when calling the StartInstances operation: We currently do not have sufficient t2.small capacity in the Availability Zone you requested (ap-northeast-1c). Our system will be working on provisioning additional capacity.

起動失敗したアカウントにおいて対象インスタンスの実行可能数の上限値に達している。
起動失敗時に下記エラーが表示される。

Launching a new EC2 instance. Status Reason: Your quota allows for 0 more running instance(s). You requested at least 1. Launching EC2 instance failed.

各インスタンスおよびリージョン内での起動上限数は EC2 コンソール左ペインにあるメニュー「制限」の項目から確認ができます。

解決策

キャパシティ不足が発生している場合、起動対象のアベイラビリティーゾーン（AZ）を変更するか、異なるインスタンスタイプを一時的に起動しておき、期待するインスタンスの起動が可能となったか定期的に確認をするようにしましょう。なお、あらかじめ（キャパシティ不足が発生していない時に）キャパシティの予約をしておくことで、キャパシティ不足による起動問題を回避することが可能です。オンデマンドキャパシティの予約を利用する方法と、リザーブドインスタンス（RI）を AZ 指定で購入し利用する方法があります。目的や要件、予算と照らし合わせてどちらを利用するか検討しましょう。

RIを購入せずに任意の期間でEC2のキャパシティを確保可能になりました

実行可能数の上限値に達している場合には、上限緩和申請を行う必要があります。対象となるインスタンスタイプと起動したい数量、その理由を添えて申請しましょう。また、対象リージョン全体での実行可能数の制限も確認して必要に応じてこちらも上限緩和の申請を行いましょう。

Amazon EC2 インスタンスの上限緩和申請時に確認しておくこと

おわりに

ここでご紹介した他にも様々な原因でインスタンスの起動が行えない場合があり、本記事の内容が役に立たない場面もあるかと思います。今回は触れていませんが、AWS が管理する仮想ホスト側や利用しているネットワークに問題が生じている可能性もあります。しかし、原因を特定して早期復旧に繋げるには「何が起きているのか」を正しく把握する必要があります。そのためにもまずは落ち着いて、実行しようとした操作内容や各種設定項目に間違いがないか確認しましょう。可能ならチーム内の別のメンバーにダブルチェックをしてもらうのも有効かもしれません。また、画面に表示されているメッセージをよく読み AWS ドキュメントから検索してみてください。次に、現時点でアクセス可能なログファイルや CloudWatch の内容を確認してみてください。きっと原因につながるメッセージが記録されているはずです。それでも解消されない、原因が見つからない場合にはそれまで調べた情報と共にサポートへ問い合わせましょう。ユーザー側ではアクセスできない領域も含めて調査してもらえます。また、他のユーザー事例から解決策が素早く提示されるかもしれません。最後に、AWS が公開している「技術的なお問い合わせに関するガイドライン」をご紹介して終わりとさせていただきます。この記事がいつか誰かのお役に立てば幸いです。