AWS announces preview of AWS Interconnect - multicloud

AWS announces AWS Interconnect – multicloud (preview), providing simple, resilient, high-speed private connections to other cloud service providers. AWS Interconnect - multicloud is easy to configure and provides high-speed, resilient connectivity with dedicated bandwidth, enabling customers to interconnect AWS networking services such as AWS Transit Gateway, AWS Cloud WAN, and Amazon VPC to other cloud service providers with ease.

「InternalError」または「Client.UserInitiatedShutdown」エラーで起動しようとすると停止または終了する Amazon EC2 インスタンスをトラブルシューティングする方法を教えてください。

所要時間3分

Amazon Elastic Compute Cloud (Amazon EC2) インスタンスを起動しようとすると、起動しないか終了し、「InternalError」または「Client.UserInitiatedShutdown」エラーが表示されました。

簡単な説明

Amazon EC2 インスタンスの「InternalError」または「Client.UserInitiatedShutdown」エラーの代表的な原因は次のとおりです。

Amazon Elastic Block Store (Amazon EBS) ボリュームがインスタンスに正しくアタッチされていない。
インスタンスにアタッチされている EBS ボリュームがエラー状態である。
暗号化された EBS ボリュームがインスタンスにアタッチされているが、エンティティには AWS Key Management Service (AWS KMS) キーへのアクセス権限がない。
Amazon EC2 インスタンスが、監査デーモンなどのオペレーティングシステムの障害により起動された数分後に停止された。

注:

インスタンスが起動せず、エラーコードが表示されない場合は、AWS コマンドラインインターフェイス (AWS CLI) で describe-instances コマンドを実行します。コマンドが JSON レスポンスの一部として返した StateReason メッセージを確認します。
AWS CLI のコマンドの実行時にエラーが発生する場合は、「AWS CLI エラーのトラブルシューティング」を参照してください。また、AWS CLI の最新バージョンを使用していることを確認してください。

解決策

EBS ボリュームがインスタンスに正しくアタッチされていない

EBS ルートボリュームは、API で定義されている /dev/sda1 または /dev/xvda のいずれかとしてインスタンスにアタッチする必要があります。2 番目の EBS ボリュームに、重複すデバイス名や重複する名前は使用できません。使用した場合、インスタンスを停止したり起動したりできなくなるからです。ブロックデバイス名の競合は、Xen ベースのインスタンスタイプ (c4、m4、t2 など) にのみ影響します。ブロックデバイス名の競合は、Nitro ベースのインスタンス (c5、m5、t3 など) には影響しません。

StateReason のエラーメッセージとエラーコードを確認するには、以下のように describe-instances API を実行します。

$ aws ec2 describe-instances --instance-id i-nnnnnnnnnnnnnnn --region us-east-1 --query "Reservations[].Instances[].{StateReason:StateReason}" --output json

**注:**us-east-1 をお使いの AWS リージョンに、i-nnnnnnnnnnnnnnnnn をお使いのインスタンス ID に、それぞれ置き換えてください。

デバイス名が競合している場合は、次のメッセージのような出力が表示されます。

[    [{
        "StateReason": {
            "Code": "Server.InternalError",
            "Message": "Server.InternalError: Internal error on launch"
        }
    }]
]

Amazon EC2 コンソールを開き、起動できないインスタンスを選択します。
[説明] タブで、[ブロック] デバイスに表示されているデバイス名を確認します。[ブロック] デバイスフィールドには、アタッチされているボリュームのすべてのデバイス名が表示されます。
ルートデバイスが正しくアタッチされていること、および同じ名前や競合する名前でリストされているデバイスがないことを確認します。
重複する名前や競合する名前のデバイスがある場合は、まずボリュームをデタッチして名前を変更します。次に、デバイス名が更新されたボリュームを再アタッチします。

アタッチされた EBS ボリュームがエラー状態である

StateReason のエラーメッセージとエラーコードを確認するには、以下のように describe-instances API を実行します。

$ aws ec2 describe-instances --instance-id i-nnnnnnnnnnnnnnn --region us-east-1 --query "Reservations[].Instances[].{StateReason:StateReason}" --output json

**注:**us-east-1 をお使いの AWS リージョンに、i-nnnnnnnnnnnnnnnnn をお使いのインスタンス ID に、それぞれ置き換えてください。

アタッチされている EBS ボリュームがエラー状態の場合、次のメッセージのような出力が表示されます。

[    [{
        "StateReason": {
            "Code": "Server.InternalError",
            "Message": "Server.InternalError: Internal error on launch"
        }
    }]
]

Amazon EC2 コンソールを開き、[ボリューム] を選択し、[ボリュームのステータス] が エラー であるかどうかを確認します。以下のどのオプションを選択するかは、ボリュームがルートボリュームか 2 次ボリュームかによって異なります。
エラー状態のボリュームが 2 次ボリュームの場合は、[ボリュームをデタッチ]してからインスタンスを起動します。
エラー状態のボリュームがルートボリュームで、そのボリュームのスナップショットがある場合は、次の手順を実行します。
ボリュームをデタッチします。
スナップショットから新しいボリュームを作成します。
元のインスタンスのデバイス名を使用して新しいボリュームをアタッチしてからインスタンスを起動します。

注: エラー状態のルートボリュームの既存のスナップショットがない場合、インスタンスを再起動することはできません。新しいインスタンスを作成し、該当するアプリケーションをインストールし、古いインスタンスを置き換えるように新しいインスタンスを設定する必要があります。

アタッチされた EBS ボリュームが暗号化されているため、AWS KMS キーにアクセスするには IAM アクセス許可では不十分である

この問題を解決するには、以下の手順に従って AWS Identity and Access Management (IAM) アクセス許可を確認してください。

StateReason のエラーメッセージとエラーコードを確認するには、以下のように describe-instances API を実行します。

$ aws ec2 describe-instances --instance-id i-nnnnnnnnnnnnnnn --region us-east-1 --query "Reservations[].Instances[].{StateReason:StateReason}" --output json

**注:**us-east-1 をお使いの AWS リージョンに、i-nnnnnnnnnnnnnnnnn をお使いのインスタンス ID に、それぞれ置き換えてください。

暗号化されたボリュームがインスタンスにアタッチされていて、アクセス許可またはポリシーに問題がある場合、クライアントエラーが表示されます。次のメッセージのような出力が表示されます。

[    [{
        "StateReason": {
            "Code": "Client.InternalError",
            "Message": "Client.InternalError: Client error on launch"
        }
    }]
]

インスタンスを作成しようとしたユーザーが正しい IAM アクセス許可を持っていることを確認します。EC2 自動スケーリングなどの別のサービスを介してインスタンスを間接的に作成した場合は、次の設定も確認してください。

ボリュームの暗号化に使用される AWS KMS キーが有効化されている。
キーに正しいキーポリシーがある。

注:ボリュームが暗号化されているかどうかを確認するには、Amazon EC2 コンソールを開き、[ボリューム] を選択します。暗号化されたボリュームには、[暗号化] 列に「暗号化済み」というラベルが表示されます。

監査デーモンなどのオペレーティングシステムの中断により EC2 インスタンスがシャットダウンされた

EC2 インスタンスのシャットダウン理由エラーコードを確認します。「Client.UserInitiatedShutdown」などの OS エラーが原因で EC2 インスタンスがシャットダウンした場合は、レスキューインスタンスを作成します。次に、以下のトラブルシューティング手順に従います。

EC2 インスタンスのシャットダウン理由を確認する

EC2 インスタンスがシャットダウンした理由を確認するには、次のコマンドを実行します。

aws ec2 describe-instances --instance-ids i-xxxx --query 'Reservations[*].Instances[].StateReason'

出力例:

[
    {
        "Code": "Client.UserInitiatedShutdown",
        "Message": "Client.UserInitiatedShutdown: User initiated shutdown"
    }
]

**注:**OS レベルでのシャットダウンを実行するのがベストプラクティスです。

レスキューインスタンスを作成する

以下の手順に従ってレスキューインスタンスを作成します。レスキューインスタンスが必要なのは、インスタンス停止中に auditd.conf のパラメータにアクセスするためです。

Amazon EC2 コンソールを開きます。
ナビゲーションペインから [インスタンス] を選択し、シャットダウンしたインスタンスを選択します。
インスタンスを停止します。
停止したインスタンスから Amazon EBS ボリューム /dev/xvda をデタッチします。
シャットダウンしたインスタンスと同じアベイラビリティーゾーンで、新しい EC2 インスタンスを作成します。新しいインスタンスがレスキューインスタンスになります。
レスキューインスタンスにセカンダリデバイスとして、ステップ 4 でデタッチした Amazon EBS ボリュームをアタッチします。
SSH を使用してレスキューインスタンスに接続します。
次のコマンドを使用して /mnt にボリュームをマウントします。
```
$ sudo mount /dev/xvdf /mnt/
```
注: /mnt/var/log ディレクトリが空であるか見つからない場合は、/mnt/etc/fstab エントリが存在することを確認してください。次に、手順 8 に従って、必要なパーティションを /var/log または /var/log/audit としてマウントします。

OS レベルのログを確認する

監査デーモンの OS レベルのログを確認するには、次のコマンドを実行します。

RPM ベースのオペレーティングシステムの場合:

> cat /var/log/messages | grep -i "Audit daemon"

Linux ベースのオペレーティングシステムの場合:

> cat /var/log/syslog | grep -i "Audit daemon"

次の出力は、監査デーモン用のディスク容量が少なく、インスタンスが停止していることを示しています。

auditd[1009]: Audit daemon is low on disk space for logging
auditd[1009]: The audit daemon is now halting the system

パーティションの空き容量が不足してもルートパーティションの空き容量には影響がないため、通常、/var/log または /var/log/audit には別のパーティションがマウントされます。このシナリオでは、「No space left on device」というエラーは発生しませんが、インスタンスが起動しません。

ディスク容量を確認する

ディスク容量を確認するには、次のコマンドを実行します。

> df -hT

監査デーモンのアクションパラメータを確認する

ディスク容量がいっぱいの場合は、/etc/auditd/auditd.conf の監査デーモンアクションで次のパラメータを確認してください。

admin_space_left

この値は、ディスク容量が不足しているときに監査デーモンがアクションを実行するための最低の空きディスク容量 (メガバイト数) を設定します。

admin_space_left_action

このパラメータは、ディスク容量が少ないときに監査デーモンが実行するアクションを設定します。有効な値は ignore、syslog、rotate、email、exec、suspend、single、および halt です。

監査デーモンのアクションを変更したら、Amazon EBS ボリュームを /dev/sda1 としてインスタンスに再度アタッチし、次いでインスタンスを起動します。

これらのパラメータを変更する方法の詳細については、man7 ウェブサイトの auditd.conf を参照してください。

注: Amazon EBS ボリュームのパーティションサイズを増やすという方法もあります。

「InternalError」または「Client.UserInitiatedShutdown」エラーで起動しようとすると停止または終了する Amazon EC2 インスタンスをトラブルシューティングする方法を教えてください。

簡単な説明

解決策

EBS ボリュームがインスタンスに正しくアタッチされていない

アタッチされた EBS ボリュームがエラー状態である

アタッチされた EBS ボリュームが暗号化されているため、AWS KMS キーにアクセスするには IAM アクセス許可では不十分である

監査デーモンなどのオペレーティングシステムの中断により EC2 インスタンスがシャットダウンされた

関連情報

関連するコンテンツ