시작 시도 시 "InternalError" 또는 "Client.UserInitiatedShutdown" 오류가 발생하며 중지되거나 종료되는 Amazon EC2 인스턴스 문제를 해결하려면 어떻게 해야 하나요?

간략한 설명

Amazon EC2 인스턴스 “InternalError” 또는 “Client.UserInitiatedShutdown” 오류의 일반적인 원인은 다음과 같습니다.

• 사용자의 Amazon Elastic Block Store(Amazon EBS) 볼륨이 인스턴스에 제대로 연결되지 않았습니다.
• 인스턴스에 연결된 EBS 볼륨이 오류 상태입니다.
• 암호화된 EBS 볼륨은 인스턴스에 연결되며 엔티티에는 AWS Key Management Service(AWS KMS) 키에 대한 권한이 없습니다.
• Amazon EC2 인스턴스는 감사 대몬과 같은 운영 체제 장애로 인해 시작된 지 몇 분 후에 중지되었습니다.

참고:

• 인스턴스가 시작되지 않고 오류 코드가 나타나지 않는 경우 AWS Command Line Interface(AWS CLI)에서 describe-instances 명령을 실행합니다. 그런 다음 명령이 JSON 응답을 반환하는 StateReason 메시지를 확인합니다.
• AWS CLI 명령을 실행할 때 오류가 발생하면 AWS CLI 오류 문제 해결을 참조하세요. 또한 최신 AWS CLI 버전을 사용하고 있는지 확인하세요.

해결 방법

EBS 볼륨이 인스턴스에 제대로 연결되지 않음

API에 정의된 볼륨에 따라 EBS 루트 볼륨을 인스턴스에 /dev/sda1 또는 /dev/xvda로 연결해야 합니다. 디바이스 이름이 중복되거나 이름이 충돌하는 두 번째 EBS 볼륨은 사용할 수 없습니다. 이 경우 인스턴스를 중지하거나 시작할 수 없습니다. 블록 디바이스 이름 충돌은 Xen 기반 인스턴스 유형(c4, m4, t2 등)에만 영향을 줍니다. 블록 디바이스 이름 충돌은 Nitro 기반 인스턴스(c5, m5, t3 등)에 영향을 주지 않습니다.

1. 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-nnnnnnnnnnnnnnn을 인스턴스 ID로 바꾸세요.

   장치 이름이 충돌하는 경우 다음 메시지와 비슷한 출력이 표시됩니다.

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

2. Amazon EC2 콘솔을 연 다음 사용자가 시작할 수 없는 인스턴스를 선택합니다.

3. 설명 탭에서 블록 디바이스에 나열된 장치 이름을 확인합니다. 블록 디바이스 필드에는 연결된 볼륨의 모든 디바이스 이름이 표시됩니다.

4. 루트 기기가 제대로 연결되어 있고 목록에 같은 이름이나 이름이 충돌하는 기기가 없는지 확인하세요.

5. 중복된 디바이스 또는 디바이스 이름이 충돌하는 경우 먼저 볼륨을 분리하고 이름을 바꾸세요. 그런 다음 업데이트된 디바이스 이름으로 볼륨을 다시 연결합니다.

연결된 EBS 볼륨이 오류 상태입니다

1. describe-instances API를 실행하여 StateReason 오류 메시지와 오류 코드를 확인합니다.

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

   참고: us-east-1은 원하는 AWS 리전으로 바꾸세요. i-nnnnnnnnnnnnnnn을 인스턴스 ID로 바꾸세요.

   연결된 EBS 볼륨이 오류 상태인 경우 다음 메시지와 비슷한 출력이 표시됩니다.

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

2. Amazon EC2 콘솔을 열고 Volumes를 선택한 다음 볼륨 상태가 오류인지 확인합니다. 옵션은 볼륨이 루트 볼륨인지 보조 볼륨인지에 따라 달라집니다.

3. 오류 상태의 볼륨이 보조 볼륨인 경우 볼륨을 분리한 다음 인스턴스를 시작합니다.

4. 오류 상태의 볼륨이 루트 볼륨이고 볼륨의 스냅샷이 있는 경우 다음 단계를 완료하십시오.
   볼륨을 분리합니다.
   스냅샷에서 새 볼륨을 생성합니다.
   원본 인스턴스의 디바이스 이름을 사용하여 새 볼륨을 연결한 다음 인스턴스를 시작합니다.

참고: 오류 상태인 루트 볼륨의 기존 스냅샷이 없는 경우 인스턴스를 다시 시작할 수 없습니다. 새 인스턴스를 시작하고 관련 애플리케이션을 설치한 다음 이전 인스턴스를 대체하도록 새 인스턴스를 구성해야 합니다.

연결된 EBS 볼륨은 암호화되어 있으며 AWS KMS 키에 액세스할 수 있는 IAM 권한이 충분하지 않습니다

이 문제를 해결하려면 다음 단계에 따라 AWS Identity and Access Management(IAM) 권한을 확인하세요.

1. describe-instances API를 실행하여 StateReason 오류 메시지와 오류 코드를 확인합니다.

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

   참고: us-east-1은 원하는 AWS 리전으로 바꾸세요. i-nnnnnnnnnnnnnnn을 인스턴스 ID로 바꾸세요.

   인스턴스에 연결된 암호화된 볼륨이 있고 권한 또는 정책 문제가 있는 경우 클라이언트 오류가 발생합니다. 다음 메시지와 비슷한 출력이 표시됩니다.

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

인스턴스를 시작하려고 시도한 사용자에게 올바른 IAM 권한이 있는지 확인합니다. EC2 Auto Scaling과 같은 다른 서비스를 통해 간접적으로 인스턴스를 시작한 경우 다음 구성도 확인하세요.

• 볼륨을 암호화하는 데 사용되는 AWS KMS 키가 활성화되었습니다.
• 키에는 올바른 키 정책이 있습니다.

참고: 볼륨이 암호화되었는지 확인하려면 Amazon EC2 콘솔을 연 다음 볼륨을 선택합니다. 암호화된 볼륨은 Encryption 열에 Encrypted 레이블을 표시합니다.

감사 데몬과 같은 운영 체제 장애로 인한 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의 파라미터에 액세스하려면 복구 인스턴스가 있어야 합니다.

1. Amazon EC2 콘솔을 엽니다.

2. 탐색 창에서 인스턴스를 선택한 다음 손상된 인스턴스를 선택합니다.

3. 인스턴스를 중지합니다.

4. 중지된 인스턴스에서 Amazon EBS 볼륨 /dev/xvda를 분리합니다.

5. 손상된 인스턴스와 동일한 가용 영역에서 새 EC2 인스턴스를 시작합니다. 이제 새 인스턴스를 복구 인스턴스로 사용할 수 있습니다.

6. 4단계에서 분리한 Amazon EBS 볼륨을 보조 디바이스로 복구 인스턴스에 연결합니다.

7. SSH를 사용하여 복구 인스턴스에 연결합니다.

8. 다음 명령을 사용하여 /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"

Debian 기반 운영 체제:

> 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용으로 다른 파티션이 마운트되며, 루트 파티션에 디스크 공간이 부족하면 이러한 파티션이 꽉 차게 됩니다. 이 시나리오에서는 "기기에 남은 공간 없음" 오류가 발생하지 않지만 인스턴스는 시작되지 않습니다.

디스크 공간 확인

디스크 공간을 확인하려면 다음 명령을 실행합니다.

> df -hT

감사 데몬 작업 매개변수 확인

디스크 공간이 가득 차면 /etc/auditd/auditd.conf 아래의 감사 데몬 작업에서 다음 매개 변수를 확인하세요.

admin_space_left

이 값은 디스크 공간 부족 시 감사 데몬이 작업을 수행할 때 사용할 수 있는 여유 디스크의 최소값(MB)을 정의합니다.

admin_space_left_action

이 매개 변수는 디스크 공간이 부족할 때 감사 데몬이 수행하는 작업을 정의합니다. 유효한 값은 ignore, syslog, rotate, email, exec, suspend, single, halt입니다.

감사 데몬 작업을 변경한 후 Amazon EBS 볼륨을 인스턴스에 다시 /dev/sda1로 연결한 다음 인스턴스를 시작합니다.

이러한 매개 변수를 변경하는 방법에 대한 자세한 내용은 man7 웹 사이트의 auditd.conf를 참조하십시오.

참고: Amazon EBS 볼륨 파티션 크기를 늘릴 수도 있습니다.

관련 정보

EC2 인스턴스를 시작할 수 없는 이유는 무엇인가요?

AWS KMS 내의 키 정책

인스턴스가 즉시 종료됨