내용으로 건너뛰기
AWS re:Post을(를) 사용하면 다음에 동의하게 됩니다. AWS re:Post 이용 약관
AWS re:Postre:Post
re:Post 소개

Amazon EC2 인스턴스에 연결할 수 없는 이유는 무엇입니까?

8분 분량
0

Amazon Elastic Compute Cloud(Amazon EC2) 인스턴스에 연결하려고 하면 오류가 발생합니다.

간략한 설명

먼저 EC2 인스턴스 구성을 확인하고 인스턴스가 인스턴스 및 시스템 상태 검사를 통과했는지 확인합니다.

여전히 연결할 수 없는 경우 SSH, EC2 Instance Connect에 대한 연결 또는 AWS Systems Manager의 기능인 Session Manager 연결을 복원하십시오. 또는 EC2 직렬 콘솔을 사용하여 연결을 복원하십시오.

참고: 일반적으로 EC2 직렬 콘솔은 표준 프로세스 수행이 아니라 문제 해결에만 사용합니다.

한 연결 방법이 작동하지 않는 경우 다른 연결 방법을 사용하여 인스턴스에 액세스하고 문제를 해결하십시오.

여전히 연결을 복원할 수 없는 경우 복구 인스턴스를 사용하여 영향을 받는 인스턴스의 로그에서 오류를 확인하십시오.

해결 방법

참고: AWS Command Line Interface(AWS CLI) 명령을 실행할 때 오류가 발생하면 AWS CLI의 오류 해결을 참조하십시오. 또한 최신 AWS CLI 버전을 사용하고 있는지 확인하십시오.

인스턴스 액세스 구성 확인

보안 그룹 규칙 검토

인바운드 보안 그룹 규칙은 사용자의 IP 주소에서 Linux의 경우 포트 22, Windows의 경우 포트 3389로의 액세스를 허용해야 합니다.

보안 그룹 규칙을 확인하려면 다음 describe-security-groups AWS CLI 명령을 실행합니다.

aws ec2 describe-security-groups --group-ids SG-IDs

참고: SG-IDs를 보안 그룹 ID로 바꾸십시오.

포트 22 또는 3389가 허용 목록에 없는 경우 다음 authorize-security-group-ingress 명령을 실행하여 액세스를 허용하도록 규칙을 업데이트하십시오.

aws ec2 authorize-security-group-ingress --group-id SG-ID --protocol tcp --port 22 --cidr SOURCE-IP/32

참고: SG-ID를 보안 그룹 ID로 바꾸고 SOURCE-IP를 소스 IP 주소로 바꾸십시오. Windows 인스턴스를 사용하는 경우 22를 3389로 바꾸십시오. 소스 IP 주소가 퍼블릭 IP 주소인 경우 checkip.amazonaws.com 도구를 사용하여 IP 주소를 식별할 수 있습니다.

네트워크 ACL 검토

기본적으로 네트워크 액세스 제어 목록(네트워크 ACL)은 모든 인바운드 및 아웃바운드 트래픽을 허용합니다. 네트워크 ACL이 인스턴스에 대한 인바운드 SSH 액세스와 임시 포트(1024-65535)에 대한 아웃바운드 액세스를 허용하는지 확인하십시오. 네트워크 ACL이 포트 22 또는 3389를 차단하는 경우 트래픽을 허용하는 새 규칙을 추가하십시오. 퍼블릭 IP 주소의 경우 라우팅 테이블에 트래픽을 인터넷 게이트웨이로 라우팅하는 항목이 있어야 합니다.

라우팅 테이블 확인

라우팅 테이블에 연결 경로가 있는지 확인하십시오.

인스턴스가 상태 검사를 통과했는지 확인

인스턴스에 연결하려면 인스턴스가 상태 검사를 통과해야 합니다. Amazon EC2 콘솔을 사용하여 시스템 상태와 인스턴스 상태가 모두 정상으로 표시되는지 확인합니다. 또한 Amazon CloudWatch 지표를 사용하여 인스턴스의 상태를 확인하고 연결에 영향을 미치는 문제를 식별할 수 있습니다.

참고: 예약된 유지 관리 및 인스턴스 연결에 영향을 줄 수 있는 기타 이벤트를 확인하는 것이 가장 좋습니다.

인스턴스 상태가 정상이 아닌 경우 인스턴스를 재부팅합니다. 일반적으로 인스턴스를 재부팅하면 사소한 문제가 해결됩니다. 여전히 연결할 수 없거나 시스템 상태가 정상이 아닌 경우 AWS 인프라에 문제가 있을 수 있습니다. 이 문제를 해결하려면 시스템 상태 검사 실패로 인해 Amazon EC2 인스턴스가 다운되는 이유는 무엇입니까?를 참조하십시오.

여전히 문제가 발생하는 경우 EC2 Linux 인스턴스의 상태 검사 실패 문제를 해결하려면 어떻게 해야 합니까? 또는 인스턴스 상태 검사 실패로 인해 EC2 Windows 인스턴스가 다운되는 이유는 무엇입니까?를 참조하십시오.

연결 오류 해결

인스턴스가 상태 검사를 통과했는데 연결 오류가 발생하는 경우 다음 리소스를 참조하십시오.

SSH 연결 복원

참고: SSH 키 페어를 분실한 경우 처음 인스턴스를 실행한 후 SSH 키 페어를 분실한 경우 Amazon EC2 인스턴스에 연결하려면 어떻게 해야 합니까?를 참조하십시오.

사용자 이름 및 IP 주소 설정 검토

인스턴스에 올바른 사용자 이름을 사용해야 합니다. 그런 다음, 퍼블릭 IP 주소에서 인스턴스에 연결합니다.

참고: 프라이빗 IP 주소에서 연결하는 경우 대상 인스턴스에 대한 네트워크 연결이 작동하는지 확인하십시오.

SSH 서버 상태 확인

SSH 서버 상태를 확인하려면 Session Manager, EC2 Instance Connect 또는 EC2 직렬 콘솔을 사용하여 인스턴스에 연결합니다.

다음 명령을 실행하여 배포에 따라 SSH 서비스의 상태를 확인합니다.

systemd를 사용하는 시스템:

sudo systemctl status sshd

Ubuntu 또는 Debian 시스템:

sudo systemctl status ssh

CentOS 6과 같은 레거시 시스템:

sudo service sshd status

SSH 서비스 상태가 중지됨인 경우 다음 명령을 실행하여 배포에 따라 서비스를 시작합니다.

systemd를 사용하는 시스템:

sudo systemctl start sshd

Ubuntu 또는 Debian 시스템:

systemctl start ssh

CentOS 6과 같은 레거시 시스템:

sudo service sshd start

프라이빗 키 파일 권한 검토

프라이빗 키 파일에 필요한 읽기 권한이 있는지 확인하십시오.

네트워크 연결 테스트

포트 22에 대한 연결을 테스트하려면 클라이언트에서 다음 명령 중 하나를 실행합니다.

nc -zv Host 22

-또는-

telnet Host 22

참고: Host를 IP 주소 또는 FQDN(Fully Qualified Domain Name)으로 바꾸십시오.

그 후 다음 명령을 실행하여 상세 모드에서 인스턴스에 SSH 연결을 사용합니다.

ssh -i key_pair.pem user@Host -vvv

참고: Host를 IP 주소 또는 FQDN으로 바꾸십시오.

연결 문제를 해결하려면 SSH를 사용하여 EC2 인스턴스에 연결할 때 발생하는 "Connection refused" 또는 "Connection timed out" 오류를 해결하려면 어떻게 해야 합니까? 및 Amazon EC2 Linux 인스턴스 연결 문제 해결을 참조하십시오.

EC2 Instance Connect 연결 복원

먼저 SSH, Session Manager 또는 EC2 직렬 콘솔을 사용해 인스턴스에 연결하여 EC2 Instance Connect가 설치되어 있는지 확인합니다. 그런 다음, EC2 Instance Connect를 사용하여 인스턴스에 연결합니다.

EC2 Instance Connect를 사용할 때 문제가 발생하는 경우 포트 22에서 com.amazonaws.region.ec2-instance-connect 접두사 목록 이름에 대해 인바운드 SSH 트래픽을 허용해야 합니다. 또한 AWS Identity and Access Management(IAM) 사용자 정책에 ec2-instance-connect:SendSSHPublicKey 작업이 포함되어 있는지 확인합니다.

여전히 문제가 발생하는 경우 EC2 Instance Connect를 사용하여 EC2 인스턴스에 연결할 때 발생하는 오류를 해결하려면 어떻게 해야 합니까?를 참조하십시오.

EC2 직렬 콘솔을 사용하여 연결 복원

사전 요구 사항: EC2 직렬 콘솔에 대한 액세스를 구성합니다.

EC2 직렬 콘솔을 사용하여 인스턴스에 연결하려면 Amazon EC2 콘솔 또는 SSH를 사용하면 됩니다. 자세한 내용은 연결할 수 없거나 액세스할 수 없는 Linux 인스턴스의 EC2 직렬 콘솔에 액세스하려면 어떻게 해야 합니까?를 참조하십시오.

연결한 후 인스턴스의 부팅, 네트워크 구성 또는 기타 문제를 해결합니다.

EC2 직렬 콘솔을 사용할 때 문제가 발생하는 경우 IAM 정책에 ec2-instance-connect:SendSerialConsoleSSHPublicKey 작업이 포함되어 있는지 확인하십시오.

Session Manager 연결 복원

Session Manager는 SSH 키가 아닌 IAM 역할 및 권한을 통해서만 인증을 관리합니다. Session Manager를 사용하기 전에 Session Manager의 사전 요구 사항을 준수해야 합니다. 그런 다음, Session Manager를 사용하여 인스턴스에 연결합니다.

Session Manager를 사용할 때 문제가 발생하면 다음 작업을 수행하십시오.

IAM 역할 확인

인스턴스에 AmazonSSMManagedInstanceCore 정책이 연결된 IAM 역할이 있는지 확인합니다.

또는 역할에 다음과 같은 필수 권한이 있는지 확인합니다.

  • ssmmessages:CreateControlChannel
  • ssmmessages:CreateDataChannel
  • ssmmessages:OpenControlChannel
  • ssmmessages:OpenDataChannel

기존 역할에 필요한 Session Manager 권한을 추가할 수 있습니다.

참고: 기본 호스트 관리 구성을 사용하여 인스턴스를 관리하는 경우 인스턴스를 관리하기 위해 IAM 인스턴스 프로파일을 만들 필요가 없습니다.

권한을 업데이트하는 경우 IAM 역할을 분리했다가 다시 연결합니다. 몇 분 정도 기다린 후 AWS Systems Manager 에이전트(SSM 에이전트)를 시작하거나 인스턴스를 시작합니다.

SSM 에이전트 상태 문제 해결

인스턴스에 SSM 에이전트를 설치했는지 확인합니다.

SSH, EC2 직렬 콘솔 또는 EC2 Instance Connect를 사용하여 인스턴스에 연결합니다. 그리고 다음 명령을 실행하여 배포에 따라 SSM 에이전트의 상태를 확인합니다.

systemd를 사용하는 시스템:

sudo systemctl status amazon-ssm-agent

Debian 또는 Ubuntu 시스템:

sudo systemctl status snap.amazon-ssm-agent.amazon-ssm-agent.service

에이전트 상태가 중지됨인 경우 다음 명령을 실행하여 배포에 따라 에이전트를 시작합니다.

systemd를 사용하는 시스템:

sudo systemctl start amazon-ssm-agent

Debian 또는 Ubuntu 시스템:

sudo systemctl start snap.amazon-ssm-agent.amazon-ssm-agent.service

SSM 에이전트가 실행 중인지 확인하려면 시스템 로그를 확인하십시오.

최신 버전의 SSM 에이전트를 사용하는 것이 가장 좋습니다. 최신 버전인지 확인하려면 GitHub 웹 사이트에서 amazon-ssm-agent/RELEASENOTES를 참조하십시오. 최신 버전이 아닌 경우 운영 체제(OS)에 따라 업데이트된 SSM 에이전트를 설치하십시오.

추가 문제를 해결하려면 /var/log/amazon/ssm/amazon-ssm-agent.log 로그에서 오류를 확인하십시오. 또는 SSM 에이전트 문제 해결을 참조하십시오.

네트워크 연결 확인

네트워크 ACL 및 보안 그룹이 포트 443에서 AWS Systems Manager 엔드포인트에 대한 아웃바운드 연결을 허용하는지 확인하십시오.

인스턴스가 Session Manager에 표시되지 않는 경우 Systems Manager에서 Amazon EC2 인스턴스를 관리형 인스턴스로 표시하지 않는 이유는 무엇입니까?를 참조하십시오.

프라이빗 인스턴스의 경우 가상 프라이빗 클라우드(VPC) 엔드포인트를 만듭니다. 서비스 이름에서 com.amazonaws.REGION.ssm 및 com.amazonaws.REGION.ssmmessages를 선택합니다.

참고: REGION을 AWS 리전으로 바꾸십시오.

VPC 엔드포인트에 연결하는 보안 그룹은 포트 443에서 인바운드 트래픽을 허용해야 합니다.

자세한 내용은 SSM 엔드포인트에 연결할 수 없음을 참조하십시오.

누락된 사전 요구 사항 확인

SSH, EC2 직렬 콘솔 또는 EC2 Instance Connect를 사용하여 인스턴스에 연결한 후 다음 명령을 실행하여 관리형 노드 가용성 문제를 해결합니다.

sudo ssm-cli get-diagnostics --output table

누락된 Session Manager 사전 요구 사항의 출력을 확인하십시오.

또는 Systems Manager 런북을 실행하여 누락된 사전 요구 사항이 있는지 자동으로 확인하십시오. AWSSupport-TroubleshootManagedInstance를 실행하여 보안 그룹 규칙, VPC 엔드포인트, 네트워크 ACL 규칙, 라우팅 테이블, IAM 프로파일을 비롯한 VPC 구성을 확인합니다. 또는 AWSSupport-TroubleshootSessionManager를 실행하여 Session Manager 사전 요구 사항을 준수하는지 확인합니다.

인스턴스 콘솔 로그 확인

위 방법을 사용하여 인스턴스에 연결할 수 없는 경우 다음 사용자 데이터 스크립트를 실행하여 Session Manager 연결을 복원하십시오.

Content-Type: multipart/mixed; boundary="//"MIME-Version: 1.0
--//
Content-Type: text/cloud-config; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="cloud-config.txt"
#cloud-config
cloud_final_modules:
- [scripts-user, always]
--//
Content-Type: text/x-shellscript; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="userdata.txt"

#!/bin/bash

sudo ssm-cli get-diagnostics --output table >> /dev/console
# or
sudo ssm-cli get-diagnostics --output table >> /dev/ttyS0

그런 다음, 인스턴스 콘솔 출력을 확인하여 실패한 연결 단계를 파악합니다. 실패한 단계의 문제를 해결한 후 Session Manager를 사용하여 연결을 테스트하십시오.

여전히 연결할 수 없는 경우 복구 인스턴스를 사용하여 부팅 문제를 해결하십시오.

관련 정보

Amazon EC2 인스턴스와 관련된 문제 해결

댓글 없음

관련 콘텐츠