연결 문제의 일반적인 원인 인스턴스 연결 중 오류 발생: 연결 시간 초과 오류: 키를 로드할 수 없습니다... 예상: 모든 개인 키 오류: 서버에서 사용자 키를 인식하지 못함 오류: 사용 권한이 거부되었거나 [인스턴스] 포트 22에 의해 연결이 닫힘 오류: 보호되지 않는 프라이빗 키 파일 오류: 프라이빗 키는 '-----BEGIN RSA PRIVATE KEY-----'로 시작하고 '-----END RSA PRIVATE KEY-----'로 끝나야 합니다.오류: 서버에서 키 거부 또는 지원되는 인증 방법이 없음 인스턴스를 ping할 수 없음 오류: 서버에서 예기치 않게 네트워크 연결을 차단함 오류: EC2 Instance Connect에 대한 호스트 키 유효성 검사 실패 EC2 Instance Connect를 사용하여 Ubuntu 인스턴스에 연결할 수 없음 프라이빗 키를 분실했습니다. 인스턴스에 연결하려면 어떻게 해야 하나요?

Amazon EC2 Linux 인스턴스 연결 문제 해결

다음 정보와 일반적인 오류는 Linux 인스턴스 연결 문제를 해결하는 데 도움이 될 수 있습니다.

연결 문제

연결 문제의 일반적인 원인
인스턴스 연결 중 오류 발생: 연결 시간 초과
오류: 키를 로드할 수 없습니다... 예상: 모든 개인 키
오류: 서버에서 사용자 키를 인식하지 못함
오류: 사용 권한이 거부되었거나 [인스턴스] 포트 22에 의해 연결이 닫힘
오류: 보호되지 않는 프라이빗 키 파일
오류: 프라이빗 키는 '-----BEGIN RSA PRIVATE KEY-----'로 시작하고 '-----END RSA PRIVATE KEY-----'로 끝나야 합니다.
오류: 서버에서 키 거부 또는 지원되는 인증 방법이 없음
인스턴스를 ping할 수 없음
오류: 서버에서 예기치 않게 네트워크 연결을 차단함
오류: EC2 Instance Connect에 대한 호스트 키 유효성 검사 실패
EC2 Instance Connect를 사용하여 Ubuntu 인스턴스에 연결할 수 없음
프라이빗 키를 분실했습니다. 인스턴스에 연결하려면 어떻게 해야 하나요?

연결 문제의 일반적인 원인

다음 태스크를 정확하게 수행했는지 확인하여 인스턴스 연결 문제 해결을 시작하는 것이 좋습니다.

인스턴스의 사용자 이름 확인

사용자 계정의 사용자 이름 또는 인스턴스를 시작하는 데 사용한 AMI의 기본 사용자 이름을 사용하여 인스턴스에 연결할 수 있습니다.

사용자 계정의 사용자 이름을 가져옵니다.

사용자 계정을 생성하는 방법에 대한 자세한 내용은 Amazon EC2 Linux 인스턴스에서 시스템 사용자 관리 섹션을 참조하세요.

인스턴스를 시작하는 데 사용한 AMI의 기본 사용자 이름을 가져옵니다.

인스턴스를 시작하는 데 사용된 AMI	기본 사용자 이름
Amazon Linux	`ec2-user`
CentOS	`centos` 또는 `ec2-user`
Debian	`admin`
Fedora	`fedora` 또는 `ec2-user`
RHEL	`ec2-user` 또는 `root`
SUSE	`ec2-user` 또는 `root`
Ubuntu	`ubuntu`
Oracle	`ec2-user`
Bitnami	`bitnami`
Rocky Linux	`rocky`
기타	AMI 제공업체에 문의

보안 그룹 규칙이 트래픽을 허용하는지 확인

인스턴스와 연관된 보안 그룹이 IP 주소로부터 들어오는 SSH 트래픽을 허용하는지 확인하세요. VPC의 기본 보안 그룹은 기본적으로 수신 SSH 트래픽을 허용하지 않습니다. 인스턴스 시작 마법사가 생성한 보안 그룹은 기본적으로 SSH 트래픽을 활성화합니다. Linux 인스턴스에 인바운드 SSH 트래픽에 대한 규칙을 추가하는 단계는 컴퓨터에서 인스턴스 연결에 대한 규칙 섹션을 참조하세요. 확인 단계는 인스턴스 연결 중 오류 발생: 연결 시간 초과 섹션을 참조하세요.

인스턴스가 준비되었는지 확인

인스턴스를 시작한 후, 인스턴스가 연결 요청을 수락할 준비가 될 때까지 몇 분 정도 걸릴 수 있습니다. 인스턴스가 실행 중이고 상태 검사를 통과했는지 확인합니다.

https://console.aws.amazon.com/ec2/에서 Amazon EC2 콘솔을 엽니다.
탐색 창에서 인스턴스를 선택한 다음 인스턴스를 선택합니다.
다음을 확인합니다.
1. [인스턴스 상태(Instance state)] 열에서 인스턴스가 running 상태인지 확인합니다.
2. [상태 확인(Status Check)] 열에서 인스턴스가 두 가지 상태 확인을 통과했는지 확인합니다.

연결에 필요한 모든 사전 조건을 충족했는지 확인

연결에 필요한 모든 정보가 있는지 확인합니다. 자세한 내용은 SSH를 사용하여 Linux 인스턴스에 연결 단원을 참조하십시오.

Linux 또는 macOS X에서 연결

로컬 컴퓨터 운영 체제가 Linux 또는 macOS X인 경우 Linux 인스턴스에 연결하기 위한 특정 사전 조건을 확인하세요.

Windows에서 연결

로컬 컴퓨터 운영 체제가 Windows인 경우 Linux 인스턴스에 연결하기 위한 특정 사전 조건을 확인하세요.

인스턴스 연결 중 오류 발생: 연결 시간 초과

인스턴스에 연결하려고 할 때 Network error: Connection timed out 또는 Error connecting to [instance], reason: -> Connection timed out: connect라는 오류 메시지가 표시되면 다음과 같이 합니다.

보안 그룹 규칙을 확인합니다.

로컬 컴퓨터의 퍼블릭 IPv4 주소에서 들어오는 인바운드 트래픽을 적절한 포트로 허용하는 보안 그룹 규칙이 필요합니다.

https://console.aws.amazon.com/ec2/에서 Amazon EC2 콘솔을 엽니다.
탐색 창에서 인스턴스(Instances)를 선택한 다음 인스턴스를 선택합니다.
콘솔 페이지 아래쪽에 있는 보안(Security) 탭의 인바운드 규칙(Inbound rules)에서 선택한 인스턴스에 적용되는 규칙 목록을 확인합니다. 로컬 컴퓨터에서 포트 22(SSH)로의 트래픽을 허용하는 규칙이 있는지 확인합니다.

보안 그룹에 로컬 컴퓨터에서 들어오는 인바운드 트래픽을 허용하는 규칙이 없을 경우 보안 그룹에 규칙을 추가합니다. 자세한 내용은 컴퓨터에서 인스턴스 연결에 대한 규칙 단원을 참조하십시오.
인바운드 트래픽을 허용하는 규칙은 소스(Source) 필드를 확인합니다. 값이 단일 IP 주소이고 IP 주소가 고정적이지 않으면 컴퓨터를 다시 시작할 때마다 새 IP 주소가 할당됩니다. 그러면 컴퓨터의 IP 주소 트래픽이 규칙에 포함되지 않습니다. 컴퓨터가 회사 네트워크에 있거나 인터넷 서비스 제공업체(ISP)를 통해 연결하는 경우 IP 주소가 고정되지 않거나 컴퓨터를 다시 시작할 때마다 컴퓨터 IP 주소가 동적으로 변경될 수 있습니다. 보안 그룹 규칙에서 소스(Source)에 단일 IP 주소를 지정하는 대신 로컬 컴퓨터에서 들어오는 인바운드 트래픽을 허용하려면 클라이언트 컴퓨터에서 사용하는 IP 주소의 범위를 지정합니다.

보안 그룹 규칙에 대한 자세한 내용은 Amazon VPC 사용 설명서의 보안 그룹 규칙을 참조하세요.

서브넷의 라우팅 테이블을 확인합니다.

VPC 외부로 지정된 모든 트래픽을 VPC의 인터넷 게이트웨이로 보내는 경로가 필요합니다.

https://console.aws.amazon.com/ec2/에서 Amazon EC2 콘솔을 엽니다.
탐색 창에서 인스턴스를 선택한 다음 인스턴스를 선택합니다.
[네트워킹(Networking)] 탭에서 [VPC ID] 및 [서브넷 ID(Subnet ID)]의 값을 기록합니다.
https://console.aws.amazon.com/vpc/에서 Amazon VPC 콘솔을 엽니다.
탐색 창에서 [Internet Gateways]를 선택합니다. VPC에 인터넷 게이트웨이가 연결되어 있는지 확인합니다. 그렇지 않은 경우 [인터넷 게이트웨이 생성(Create internet gateway)]을 선택하고 인터넷 게이트웨이의 이름을 입력한 다음 [인터넷 게이트웨이 생성(Create internet gateway)]을 선택합니다. 그런 다음 생성한 인터넷 게이트웨이에 대해 [작업(Actions)], [VPC에 연결(Attach to VPC)]을 선택하고, VPC를 선택한 다음 [인터넷 게이트웨이 연결(Attach internet gateway)]을 선택하여 VPC에 연결합니다.
탐색 창에서 서브넷을 선택한 후 해당 서브넷을 선택합니다.
[라우팅 테이블(Route table)] 탭에서 대상 위치로 0.0.0.0/0 경로가 있으며, VPC의 대상으로 해당 인터넷 게이트웨이가 있는지 확인합니다. IPv6 주소를 이용해 인스턴스에 연결하는 경우 인터넷 게이트웨이를 가리키는 모든 IPv6 트래픽(::/0)에 대한 경로가 있는지 확인합니다. 그렇지 않으면 다음을 수행하십시오.
1. 라우팅 테이블의 ID(rtb-xxxxxxxx)를 선택해 해당 라우팅 테이블로 이동합니다.
2. 라우팅 탭에서 라우팅 편집을 선택합니다. 라우팅 추가를 선택하고 대상 위치로 0.0.0.0/0을, 대상으로 인터넷 게이트웨이를 사용합니다. IPv6의 경우 라우팅 추가를 선택하고 대상 위치로 ::/0을, 대상으로 인터넷 게이트웨이를 사용합니다.
3. 라우팅 저장을 선택합니다.

네트워크 ACL(액세스 제어 목록)을 검사하여 서브넷 유무를 확인하십시오.

네트워크 ACL은 포트 22의 로컬 IP 주소에서 수신되는 인바운드 SSH 트래픽을 허용해야 합니다. 또한 임시 포트(1024~65535)로의 아웃바운드 트래픽도 허용해야 합니다.

https://console.aws.amazon.com/vpc/에서 Amazon VPC 콘솔을 엽니다.
탐색 창에서 Subnets를 선택합니다.
서브넷을 선택합니다.
[네트워크 ACL(Network ACL)] 탭의 [인바운드 규칙(Inbound rules)]에서 규칙이 컴퓨터의 필수 포트에서 트래픽을 허용하는지 확인합니다. 허용하지 않을 경우 트래픽을 차단하는 규칙을 삭제하거나 수정합니다.
[아웃바운드 규칙(Outbound rules)] 탭에서 규칙이 임시 포트에서 컴퓨터로의 트래픽을 허용하는지 확인합니다. 허용하지 않을 경우 트래픽을 차단하는 규칙을 삭제하거나 수정합니다.

컴퓨터가 회사 네트워크에 있는 경우

네트워크 관리자에게 내부 방화벽이 포트 22의 로컬 컴퓨터에서 수신되는 인바운드 및 아웃바운드 트래픽을 허용하는지 여부를 문의합니다.

컴퓨터에 방화벽이 있을 경우 방화벽이 포트 22의 컴퓨터에서 수신되는 인바운드 및 아웃바운드 트래픽을 허용하는지 확인합니다.

인스턴스에 퍼블릭 IPv4 주소가 있는지 확인합니다.

퍼블릭 IP 주소가 없을 경우 인스턴스와 탄력적 IP 주소를 연결할 수 있습니다. 자세한 내용은 탄력적 IP 주소 섹션을 참조하세요.

인스턴스에서 CPU 부하를 확인합니다. 서버 과부하가 발생했을 수 있습니다.

AWS에서는 Amazon CloudWatch 지표 및 인스턴스 상태 등과 같은 데이터를 자동으로 제공하므로, 이러한 정보를 사용하여 인스턴스에 대한 CPU 로드를 확인하고 필요할 경우 로드 처리 방법을 조정할 수 있습니다. 자세한 내용은 CloudWatch를 사용하여 인스턴스 모니터링 섹션을 참조하세요.

부하가 가변적이면 Auto Scaling 및 Elastic Load Balancing을 사용하여 인스턴스를 자동으로 확장하거나 축소할 수 있습니다.
부하가 꾸준히 증가하는 경우 더 큰 인스턴스 유형으로 전환할 수 있습니다. 자세한 내용은 Amazon EC2 인스턴스 유형 변경 섹션을 참조하세요.

IPv6 주소를 사용해 인스턴스에 연결하려면 다음을 확인합니다.

서브넷은 IPv6 트래픽(::/0)을 인터넷 게이트웨이로 이어주는 경로가 있는 라우팅 테이블과 연결되어야 합니다.
보안 그룹 규칙이 포트 22의 로컬 IPv6 주소에서 수신되는 인바운드 트래픽을 허용해야 합니다.
네트워크 ACL 규칙은 인바운드 및 아웃바운드 IPv6 트래픽을 허용해야 합니다.
이전 AMI에서 인스턴스를 시작한 경우, DHCPv6에 맞게 구성되지 않을 수 있습니다(IPv6 주소가 네트워크 인터페이스에서 자동으로 인식되지 않음). 자세한 내용을 알아보려면 Amazon VPC 사용 설명서의 인스턴스에서 IPv6 구성하기를 참조하세요.
로컬 컴퓨터에 IPv6 주소가 있고 IPv6를 사용하도록 컴퓨터를 구성해야 합니다.

오류: 키를 로드할 수 없습니다... 예상: 모든 개인 키

인스턴스에 연결하여 오류 메시지 unable to load key ... Expecting: ANY PRIVATE KEY를 수신하려고 할 때 프라이빗 키가 저장된 파일이 잘못 구성되었습니다. 프라이빗 키 파일은 .pem으로 끝날 경우에도 여전히 잘못 구성될 수 있습니다. 인증서가 누락된 이유로 프라이빗 키 파일이 잘못 구성될 수 있습니다.

프라이빗 키 파일이 잘못 구성된 경우, 다음 단계에 따라 오류를 해결하십시오.

새 키 페어를 생성합니다. 자세한 내용은 Amazon EC2를 사용하여 키 페어 생성 단원을 참조하십시오.

참고
또는 타사 도구를 사용해 새 키 페어를 만들 수 있습니다. 자세한 내용은 서드 파티 도구를 사용하여 키 페어를 생성하고 Amazon EC2로 퍼블릭 키 가져오기 단원을 참조하십시오.
새 키 페어를 인스턴스에 추가합니다. 자세한 내용은 프라이빗 키를 분실했습니다. 인스턴스에 연결하려면 어떻게 해야 하나요? 섹션을 참조하세요.
새 키 페어를 사용하여 인스턴스에 연결합니다.

오류: 서버에서 사용자 키를 인식하지 못함

SSH를 사용하여 인스턴스에 연결하는 경우

연결 시 ssh -vvv를 사용하여 자세한 디버깅 정보를 확인합니다.


ssh -vvv -i path/key-pair-name.pem instance-user-name@ec2-203-0-113-25.compute-1.amazonaws.com

다음 샘플 출력은 서버에서 인식하지 못하는 키를 사용하여 인스턴스에 연결하려 했는지를 확인하는 방법을 보여 줍니다.


open/ANT/myusername/.ssh/known_hosts).
debug2: bits set: 504/1024
debug1: ssh_rsa_verify: signature correct
debug2: kex_derive_keys
debug2: set_newkeys: mode 1
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug2: set_newkeys: mode 0
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug2: key: boguspem.pem ((nil))
debug1: Authentications that can continue: publickey
debug3: start over, passed a different list publickey
debug3: preferred gssapi-keyex,gssapi-with-mic,publickey,keyboard-interactive,password
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Trying private key: boguspem.pem
debug1: read PEM private key done: type RSA
debug3: sign_and_send_pubkey: RSA 9c:4c:bc:0c:d0:5c:c7:92:6c:8e:9b:16:e4:43:d8:b2
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey
debug2: we did not send a packet, disable method
debug1: No more authentication methods to try.
Permission denied (publickey).

PuTTY를 사용하여 인스턴스에 연결하는 경우

프라이빗 키(.pem) 파일이 PuTTY(.ppk)에서 인식하는 형식으로 변환되었는지 확인합니다. 프라이빗 키 변환에 대한 자세한 내용은 PuTTY를 사용하여 Linux 인스턴스에 연결 섹션을 참조하세요.

참고
PuTTYgen에서 프라이빗 키 파일을 불러온 후 생성이 아니라 Save Private Key(프라이빗 키 저장)를 선택합니다.

AMI에 적합한 사용자 이름을 사용하여 연결하고 있는지 확인합니다. PuTTY 구성 창에서 호스트 이름 상자에 사용자 이름을 입력합니다.

인스턴스를 시작하는 데 사용된 AMI	기본 사용자 이름
Amazon Linux	`ec2-user`
CentOS	`centos` 또는 `ec2-user`
Debian	`admin`
Fedora	`fedora` 또는 `ec2-user`
RHEL	`ec2-user` 또는 `root`
SUSE	`ec2-user` 또는 `root`
Ubuntu	`ubuntu`
Oracle	`ec2-user`
Bitnami	`bitnami`
Rocky Linux	`rocky`
기타	AMI 제공업체에 문의

해당 포트로의 인바운드 트래픽을 허용할 인바운드 보안 그룹 규칙이 있는지 확인합니다. 자세한 내용은 컴퓨터에서 인스턴스 연결에 대한 규칙 단원을 참조하십시오.

오류: 사용 권한이 거부되었거나 [인스턴스] 포트 22에 의해 연결이 닫힘

SSH를 사용하여 인스턴스에 연결할 때 Host key not found in [directory], Permission denied (publickey), Authentication failed, permission denied, 또는 Connection closed by [instance] port 22 오류 중 하나가 발생하는 경우 AMI에 적합한 사용자 이름을 사용하여 연결하고 있는지, 그리고 인스턴스에 대한 올바른 프라이빗 키(.pem)) 파일을 지정했는지 확인합니다.

적합한 사용자 이름은 다음과 같습니다.

인스턴스를 시작하는 데 사용된 AMI	기본 사용자 이름
Amazon Linux	`ec2-user`
CentOS	`centos` 또는 `ec2-user`
Debian	`admin`
Fedora	`fedora` 또는 `ec2-user`
RHEL	`ec2-user` 또는 `root`
SUSE	`ec2-user` 또는 `root`
Ubuntu	`ubuntu`
Oracle	`ec2-user`
Bitnami	`bitnami`
Rocky Linux	`rocky`
기타	AMI 제공업체에 문의

예를 들어 SSH 클라이언트를 사용하여 Amazon Linux 인스턴스에 연결하려면 다음 명령을 사용합니다.


ssh -i /path/key-pair-name.pem instance-user-name@ec2-203-0-113-25.compute-1.amazonaws.com

인스턴스를 시작할 때 선택한 키 페어에 해당하는 프라이빗 키를 사용하고 있는지 확인합니다.

https://console.aws.amazon.com/ec2/에서 Amazon EC2 콘솔을 엽니다.
탐색 창에서 [인스턴스(Instances)]를 선택한 다음 인스턴스를 선택합니다.
[세부 정보(Details)] 탭의 [인스턴스 세부 정보(Instance details)]에서 [키 페어 이름(Key pair name)]의 값을 확인합니다.
인스턴스를 시작할 때 키 페어를 지정하지 않은 경우 인스턴스를 종료하고 새 인스턴스를 시작하여 키 페어를 지정할 수 있습니다. 이 인스턴스가 사용하던 인스턴스이지만 해당 키 페어의 .pem 파일이 없을 경우 키 페어를 새 것으로 바꿀 수 있습니다. 자세한 내용은 프라이빗 키를 분실했습니다. 인스턴스에 연결하려면 어떻게 해야 하나요? 섹션을 참조하세요.

고유한 키 페어를 만든 경우 키 생성기가 RSA 키를 만들도록 설정되어 있는지 확인합니다. DSA 키는 허용되지 않습니다.

Permission denied (publickey) 오류가 반환되고 위의 어느 것도 적용되지 않는 경우(예를 들어, 전에는 연결할 수 있었지만), 인스턴스의 홈 디렉토리에서의 권한이 변경되었을 수 있습니다. /home/instance-user-name/.ssh/authorized_keys에 대한 권한은 소유자로만 제한되어야 합니다.

인스턴스에서 권한을 확인하려면

인스턴스를 중지하고 루트 볼륨을 분리합니다. 자세한 내용은 Amazon EC2 인스턴스 중지 및 시작 단원을 참조하십시오.
현재의 인스턴스와 동일한 가용 영역에서 임시 인스턴스를 시작하고(현재의 인스턴스에 사용한 것과 비슷하거나 동일한 AMI 사용) 루트 볼륨을 임시 인스턴스에 연결합니다.
임시 인스턴스에 연결하고 마운트 지점을 생성한 후 연결한 볼륨을 마운트합니다.

임시 인스턴스에서 연결된 볼륨의 /home/instance-user-name/ 디렉토리의 권한을 확인합니다. 필요하다면 다음과 같이 권한을 조정합니다.


[ec2-user ~]$ chmod 600 mount_point/home/instance-user-name/.ssh/authorized_keys


[ec2-user ~]$ chmod 700 mount_point/home/instance-user-name/.ssh


[ec2-user ~]$ chmod 700 mount_point/home/instance-user-name

볼륨을 마운트 해제하고 임시 인스턴스에서 분리한 다음 원본 인스턴스에 다시 연결합니다. 루트 볼륨에 올바른 이름을 지정해야 합니다(예: /dev/xvda).
인스턴스를 시작합니다. 더 이상 필요하지 않은 경우, 임시 인스턴스를 종료할 수 있습니다.

오류: 보호되지 않는 프라이빗 키 파일

다른 사용자의 읽기 및 쓰기 작업으로부터 프라이빗 키 파일을 보호해야 합니다. 프라이빗 키를 본인 이외의 다른 모든 사람이 읽거나 쓸 수 있는 경우 SSH는 키를 무시하고 다음과 같은 경고 메시지를 표시합니다.


@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@         WARNING: UNPROTECTED PRIVATE KEY FILE!          @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions 0777 for '.ssh/my_private_key.pem' are too open.
It is required that your private key files are NOT accessible by others.
This private key will be ignored.
bad permissions: ignore key: .ssh/my_private_key.pem
Permission denied (publickey).

인스턴스에 로그인할 때 이와 비슷한 메시지가 표시되면 오류 메시지의 첫 줄을 살펴보고 인스턴스에 올바른 퍼블릭 키를 사용하고 있는지 확인합니다. 위의 예에서는 프라이빗 키 .ssh/my_private_key.pem 및 파일 권한 0777이 사용되어 모든 사람에게 이 파일에 대한 읽기 또는 쓰기가 허용됩니다. 이 권한 수준은 전혀 보호되지 않는 수준이므로 SSH에서는 이 키를 무시합니다.

macOS 또는 Linux에서 연결하는 경우 프라이빗 키 파일 경로를 대체하는 다음 명령을 실행하여 이 오류를 해결합니다.


[ec2-user ~]$ chmod 0400 .ssh/my_private_key.pem

Windows에서 Linux 인스턴스에 연결하는 경우 로컬 컴퓨터에서 다음 단계를 수행합니다.

.pem 파일로 이동합니다.
.pem 파일을 마우스 오른쪽 버튼으로 클릭하고 [속성(Properties)]을 선택합니다.
보안 탭을 선택합니다.
[고급(Advanced)]을 선택합니다.
파일의 소유자인지 확인합니다. 그렇지 않은 경우 소유자를 사용자 이름으로 변경합니다.
[상속 비활성화(Disable inheritance)] 및 [이 객체에서 상속된 모든 권한 제거(Remove all inherited permissions from this object)]를 선택합니다.
[추가(Add)], [보안 주체 선택(Select a principal)]을 차례로 선택하고 사용자 이름을 입력한 다음 [확인(OK)]을 선택합니다.
[권한 항목(Permission Entry)] 창에서 [읽기(Read)] 권한을 부여하고 [확인(OK)]을 선택합니다.
적용(Apply)을 클릭하여 모든 설정이 저장되었는지 확인합니다.
[확인(OK)]을 선택하여 [고급 보안 설정(Advanced Security Settings)] 창을 닫습니다.
[확인(OK)]을 선택하여 [속성(Properties)] 창을 닫습니다.
Windows에서 SSH를 사용하여 Linux 인스턴스에 연결할 수 있어야 합니다.

Windows 명령 프롬프트 창에서 다음 명령을 실행합니다.

명령 프롬프트에서 .pem 파일의 파일 경로 위치로 이동합니다.
다음 명령을 실행하여 명시적 사용 권한을 재설정하고 제거합니다.
```
icacls.exe $path /reset
```
다음 명령을 실행하여 현재 사용자에게 읽기 권한을 부여합니다.
```
icacls.exe $path /GRANT:R "$($env:USERNAME):(R)"
```
다음 명령을 실행하여 상속을 비활성화하고 상속된 사용 권한을 제거합니다.
```
icacls.exe $path /inheritance:r
```
Windows에서 SSH를 사용하여 Linux 인스턴스에 연결할 수 있어야 합니다.

오류: 프라이빗 키는 '-----BEGIN RSA PRIVATE KEY-----'로 시작하고 '-----END RSA PRIVATE KEY-----'로 끝나야 합니다.

ssh-keygen과 같은 타사 도구를 사용하여 RSA 키 페어를 생성하는 경우 OpenSSH 키 형식으로 프라이빗 키가 생성됩니다. 인스턴스에 연결할 때 암호를 해독하기 위해 OpenSSH 형식의 프라이빗 키를 사용하면 Private key must begin with "-----BEGIN RSA PRIVATE KEY-----" and end with "-----END RSA PRIVATE KEY-----" 오류가 발생합니다.

이 오류를 해결하려면 프라이빗 키가 PEM 형식이어야 합니다. 다음 명령을 사용하여 PEM 형식의 프라이빗 키를 생성합니다.


ssh-keygen -m PEM

오류: 서버에서 키 거부 또는 지원되는 인증 방법이 없음

PuTTY를 사용하여 인스턴스에 연결하고 Error: Server refused our key 또는 Error: No supported authentication methods available 중 하나가 발생하면 AMI에 적합한 사용자 이름으로 연결했는지 확인하십시오. PuTTY 구성 창에서 사용자 이름에 사용자 이름을 입력합니다.

적합한 사용자 이름은 다음과 같습니다.

인스턴스를 시작하는 데 사용된 AMI	기본 사용자 이름
Amazon Linux	`ec2-user`
CentOS	`centos` 또는 `ec2-user`
Debian	`admin`
Fedora	`fedora` 또는 `ec2-user`
RHEL	`ec2-user` 또는 `root`
SUSE	`ec2-user` 또는 `root`
Ubuntu	`ubuntu`
Oracle	`ec2-user`
Bitnami	`bitnami`
Rocky Linux	`rocky`
기타	AMI 제공업체에 문의

다음 사항도 확인해야 합니다.

PuTTY의 최신 버전을 사용하고 있습니다. 자세한 내용은 PuTTY 웹 페이지를 참조하세요.
프라이빗 키(.pem) 파일이 PuTTY(.ppk)에서 인식하는 형식으로 변환되었습니다. 프라이빗 키 변환에 대한 자세한 내용은 PuTTY를 사용하여 Linux 인스턴스에 연결 섹션을 참조하세요.

인스턴스를 ping할 수 없음

ping 명령은 일종의 ICMP 트래픽입니다. 따라서 인스턴스를 ping할 수 없는 경우, 인바운드 보안 그룹 규칙에서 모든 소스, 즉 컴퓨터 또는 명령을 실행하는 인스턴스에서 오는 Echo Request 메시지에 대한 ICMP 트래픽을 허용하는지 확인합니다.

인스턴스에서 ping 명령을 실행할 수 없는 경우, 아웃바운드 보안 그룹 규칙에서 모든 대상, 즉 ping을 시도 중인 호스트에 보내는 Echo Request 메시지에 대한 ICMP 트래픽을 허용하는지 확인합니다.

Ping 명령은 방화벽에 의해 차단되거나 네트워크 지연 또는 하드웨어 문제로 인해 시간 초과될 수도 있습니다. 추가 문제 해결에 대한 도움말은 로컬 네트워크 또는 시스템 관리자에게 문의해야 합니다.

오류: 서버에서 예기치 않게 네트워크 연결을 차단함

PuTTY를 사용하여 인스턴스에 연결할 때 "Server unexpectedly closed network connection.(서버에서 예기치 않게 네트워크 연결을 차단했습니다.)"라는 오류가 발생하는 경우 연결이 끊어지지 않도록 PuTTY 구성의 연결 페이지에서 keepalives를 활성화했는지 확인합니다. 일부 서버는 지정된 기간 내 데이터를 수신하지 않을 때 클라이언트의 연결을 끊습니다. keepalives 간격을 59초로 설정합니다.

keepalives를 활성화한 후에도 문제가 계속 발생하는 경우 PuTTY 구성의 연결 페이지에서 Nagle 알고리즘을 비활성화합니다.

오류: EC2 Instance Connect에 대한 호스트 키 유효성 검사 실패

인스턴스 호스트 키를 교체할 경우 새 호스트 키가 AWS의 신뢰할 수 있는 호스트 키 데이터베이스에 자동으로 업로드되지 않습니다. 이로 인해 EC2 Instance Connect 브라우저 기반 클라이언트를 사용하여 인스턴스에 연결하려고 하면 호스트 키 유효성 검사가 실패하고 인스턴스에 연결할 수 없게 됩니다.

이 오류를 해결하려면 새 호스트 키를 EC2 Instance Connect에 업로드하는 인스턴스에서 eic_harvest_hostkeys 스크립트를 실행해야 합니다. 스크립트는 /opt/aws/bin/(Amazon Linux 2 인스턴스) 및 /usr/share/ec2-instance-connect/(Ubuntu 인스턴스)에 있습니다.

Amazon Linux 2

Amazon Linux 2 인스턴스에서 호스트 키 유효성 검사 실패 오류를 해결하려면

SSH로 인스턴스에 연결합니다.

EC2 Instance Connect CLI를 사용하여 연결하거나, 인스턴스를 시작할 때 인스턴스에 할당된 SSH 키 페어와 인스턴스를 시작할 때 사용한 AMI의 기본 사용자 이름을 사용하여 연결할 수 있습니다. Amazon Linux 2의 경우, 기본 사용자 이름은 ec2-user입니다.

예를 들어 인스턴스가 Amazon Linux 2를 사용하여 시작되었고 인스턴스의 퍼블릭 DNS 이름이 ec2-a-b-c-d.us-west-2.compute.amazonaws.com이고 키 페어가 my_ec2_private_key.pem인 경우 다음 명령을 사용하여 인스턴스에 SSH를 추가합니다.
```
$ ssh -i my_ec2_private_key.pem ec2-user@ec2-a-b-c-d.us-west-2.compute.amazonaws.com
```
인스턴스 연결에 대한 자세한 내용은 SSH 클라이언트를 사용하여 Linux 인스턴스에 연결 주제를 참조하십시오.
다음 폴더로 이동합니다.
```
[ec2-user ~]$ cd /opt/aws/bin/
```
인스턴스에서 다음 명령을 실행합니다. 
```
[ec2-user ~]$ ./eic_harvest_hostkeys
```
호출이 성공하면 출력이 표시되지 않습니다.

이제 EC2 Instance Connect 브라우저 기반 클라이언트를 사용하여 인스턴스에 연결할 수 있습니다.

Ubuntu

Ubuntu 인스턴스에서 호스트 키 유효성 검사 실패 오류를 해결하려면

SSH로 인스턴스에 연결합니다.

EC2 Instance Connect CLI를 사용하여 연결하거나, 인스턴스를 시작할 때 인스턴스에 할당된 SSH 키 페어와 인스턴스를 시작할 때 사용한 AMI의 기본 사용자 이름을 사용하여 연결할 수 있습니다. Ubuntu의 기본 사용자 이름은 ubuntu입니다.

예를 들어 인스턴스가 Ubuntu를 사용하여 시작되었고 인스턴스의 퍼블릭 DNS 이름이 ec2-a-b-c-d.us-west-2.compute.amazonaws.com이고 키 페어가 my_ec2_private_key.pem인 경우 다음 명령을 사용하여 인스턴스에 SSH를 추가합니다.
```
$ ssh -i my_ec2_private_key.pem ubuntu@ec2-a-b-c-d.us-west-2.compute.amazonaws.com
```
인스턴스 연결에 대한 자세한 내용은 SSH 클라이언트를 사용하여 Linux 인스턴스에 연결 주제를 참조하십시오.

다음 폴더로 이동합니다.


[ec2-user ~]$ cd /usr/share/ec2-instance-connect/

인스턴스에서 다음 명령을 실행합니다. 
```
[ec2-user ~]$ ./eic_harvest_hostkeys
```
호출이 성공하면 출력이 표시되지 않습니다.

이제 EC2 Instance Connect 브라우저 기반 클라이언트를 사용하여 인스턴스에 연결할 수 있습니다.

EC2 Instance Connect를 사용하여 Ubuntu 인스턴스에 연결할 수 없음

EC2 Instance Connect를 사용하여 Ubuntu 인스턴스에 연결하고 연결을 시도할 때 오류가 발생하는 경우, 다음 정보를 사용하여 문제를 해결할 수 있습니다.

가능한 원인

인스턴스의 ec2-instance-connect 패키지가 최신 버전이 아닙니다.

솔루션

인스턴스의 ec2-instance-connect 패키지를 다음과 같이 최신 버전으로 업데이트합니다.

EC2 Instance Connect 이외의 방법을 사용하여 인스턴스에 연결합니다.
인스턴스에 다음 명령을 사용하여 ec2-instance-connect 패키지를 최신 버전으로 업데이트합니다.
```
apt update && apt upgrade
```

프라이빗 키를 분실했습니다. 인스턴스에 연결하려면 어떻게 해야 하나요?

EBS 기반 인스턴스용 프라이빗 키를 분실하는 경우 인스턴스에 대한 액세스 권한을 다시 얻을 수 있습니다. 인스턴스를 중지하고, 루트 볼륨을 분리한 후 다른 인스턴스에 데이터 볼륨으로 연결하고, 새 퍼블릭 키로 authorized_keys 파일을 수정하고, 해당 볼륨을 원본 인스턴스로 되돌린 뒤 인스턴스를 다시 시작합니다. 인스턴스 시작, 연결, 중지에 대한 자세한 내용은 Amazon EC2 인스턴스 상태 변경에서 확인하십시오.

이 절차는 EBS 루트 볼륨이 있는 인스턴스에만 지원됩니다. 루트 디바이스가 인스턴스 스토어 볼륨인 경우 이 절차를 사용하여 인스턴스에 대한 액세스 권한을 다시 얻을 수 없습니다. 인스턴스에 연결하려면 프라이빗 키가 있어야 합니다. 인스턴스의 루트 디바이스 유형을 확인하려면 Amazon EC2 콘솔을 열고 인스턴스를 선택한 다음 인스턴스를 선택하고 스토리지 탭을 선택한 다음 루트 디바이스 세부 정보 섹션에서 루트 디바이스 유형 값을 확인합니다.

이때 값은 EBS 또는 INSTANCE-STORE입니다.

다음 단계 외에도 프라이빗 키를 분실한 경우 Linux 인스턴스에 연결하는 다른 방법도 있습니다. 자세한 내용은 처음 시작한 후 SSH 키 페어를 분실한 경우 Amazon EC2 인스턴스에 연결하려면 어떻게 해야 합니까?를 참조하세요.

키 페어가 다른 EBS 지원 인스턴스에 연결하는 단계

1단계: 새 키 페어 생성
2단계: 원본 인스턴스와 루트 볼륨에 대한 정보 가져오기
3단계: 원본 인스턴스 중지
4단계: 임시 인스턴스 시작
5단계: 원본 인스턴스에서 루트 볼륨을 분리하고 임시 인스턴스에 연결
6단계: 임시 인스턴스에 마운트된 원본 볼륨의 authorized_keys에 새 퍼블릭 키 추가
7단계: 임시 인스턴스에서 원본 볼륨을 마운트 해제하고 분리한 다음 원본 인스턴스에 다시 연결
8단계: 새 키 페어를 사용하여 원본 인스턴스에 연결
9단계: 정리

1단계: 새 키 페어 생성

새 키 페어는 Amazon EC2 콘솔이나 타사 도구를 사용해 만들 수 있습니다. 새 키 페어의 이름을 잃어버린 프라이빗 키와 동일하게 지정하려면 먼저 기존 키 페어를 삭제해야 합니다. 새 키 페어 생성에 대한 자세한 내용은 Amazon EC2를 사용하여 키 페어 생성 또는 서드 파티 도구를 사용하여 키 페어를 생성하고 Amazon EC2로 퍼블릭 키 가져오기 단원을 참조하십시오.

2단계: 원본 인스턴스와 루트 볼륨에 대한 정보 가져오기

이 절차를 완료하는 데 필요한 다음 정보를 기록해 둡니다.

원래 인스턴스에 대한 정보를 가져오려면

https://console.aws.amazon.com/ec2/에서 Amazon EC2 콘솔을 엽니다.
탐색 창에서 인스턴스를 선택한 후 연결할 인스턴스를 선택합니다. (이후의 내용에서는 이를 원본 인스턴스라고 지칭함)
[세부 정보(Details)] 탭에서 인스턴스 ID와 AMI ID를 기록합니다.
[네트워킹(Networking)] 탭에서 가용 영역을 기록합니다.
[스토리지(Storage)] 탭의 [루트 디바이스 이름(Root device name)] 아래에서 루트 볼륨의 디바이스 이름(예: /dev/xvda)을 기록합니다. 그런 다음 [블록 디바이스(Block devices)]에서 이 디바이스 이름을 찾아 볼륨 ID(예: vol-0a1234b5678c910de)를 기록합니다.

3단계: 원본 인스턴스 중지

인스턴스 상태, 인스턴스 중지를 차례로 선택합니다. 이 옵션이 비활성화되어 있으면 해당 인스턴스가 이미 중지되었거나 해당 루트 디바이스가 인스턴스 스토어 볼륨인 것입니다.

주의

인스턴스를 중지하면 인스턴스 스토어 볼륨의 데이터가 삭제됩니다. 인스턴스 스토어 볼륨의 데이터를 유지하려면 영구 스토리지에 백업하세요.

4단계: 임시 인스턴스 시작

임시 인스턴스를 실행합니다.

탐색 창에서 Instances(인스턴스)를 선택한 후 Launch instances(인스턴스 시작)를 선택합니다.
이름 및 태그(Name and tags) 섹션에서 이름(Name)에 임시(Temporary)를 입력합니다.
애플리케이션 및 OS 이미지(Application and OS Images) 섹션에서 원본 인스턴스를 시작하는 데 사용한 것과 동일한 AMI를 선택합니다. 이 AMI가 표시되지 않는 경우 중지된 인스턴스에서 사용 가능한 AMI를 만들 수 있습니다. 자세한 내용은 Amazon EBS 지원 AMI 생성 단원을 참조하십시오.
인스턴스 유형(Instance type) 섹션에서 기본 인스턴스 유형을 유지합니다.
키 페어(Key pair) 섹션의 키 페어 이름(Key pair name)에서 사용할 기존 키 페어를 선택하거나 새로 하나 생성합니다.
네트워크 설정(Network settings) 섹션에서 편집(Edit)을 선택한 다음 서브넷(Subnet)에 대해 원본 인스턴스와 동일한 가용 영역에 있는 서브넷을 선택합니다.
요약(Summary) 패널에서 시작(Launch)을 선택합니다.

5단계: 원본 인스턴스에서 루트 볼륨을 분리하고 임시 인스턴스에 연결

탐색 창에서 [볼륨(Volumes)]을 선택하고 원본 인스턴스에 대한 루트 디바이스 볼륨을 선택합니다(전 단계에서 기록한 볼륨 ID). Actions(작업), Detach volume(볼륨 분리)를 선택하고 Detach(분리)를 선택합니다. 볼륨이 available 상태가 될 때까지 기다리십시오. (새로 고침 아이콘을 클릭해야 할 수도 있습니다.)
해당 볼륨을 선택한 상태에서 Actions(작업)을 선택한 후 Attach volume(볼륨 연결)을 선택합니다. 임시 인스턴스의 인스턴스 ID를 선택하고 Device name(디바이스 이름)에서 지정된 디바이스(예: /dev/sdf)를 기록한 후 Attach volume(볼륨 연결)을 선택합니다.

참고
AWS Marketplace AMI에서 원본 인스턴스를 시작했고 볼륨에 AWS Marketplace 코드가 포함되어 있는 경우 볼륨을 연결하기 전에 먼저 임시 인스턴스를 중지해야 합니다.

6단계: 임시 인스턴스에 마운트된 원본 볼륨의 `authorized_keys`에 새 퍼블릭 키 추가

임시 인스턴스에 연결합니다.
임시 인스턴스에서 인스턴스에 연결한 볼륨을 마운트해야 해당 파일 시스템에 액세스할 수 있습니다. 예를 들어 디바이스 이름이 /dev/sdf인 경우 다음 명령을 사용하여 볼륨을 /mnt/tempvol로 마운트합니다.

참고
디바이스 이름은 인스턴스에서 다르게 표시될 수 있습니다. 예를 들면 /dev/sdf로 탑재된 디바이스가 인스턴스에서는 /dev/xvdf로 표시되기도 합니다. Red Hat 중 일부 버전(CentOS 등 변형 버전 포함)은 후행 문자가 4자씩 늘어나기도 하며, 이 경우 /dev/sdf가 /dev/xvdk로 변경됩니다.
1. lsblk 명령을 사용하면 볼륨이 파티셔닝됐는지 여부를 확인할 수 있습니다.
```
[ec2-user ~]$ lsblk
NAME    MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
xvda    202:0    0    8G  0 disk
└─xvda1 202:1    0    8G  0 part /
xvdf    202:80   0  101G  0 disk
└─xvdf1 202:81   0  101G  0 part
xvdg    202:96   0   30G  0 disk
```
  위 예에서 /dev/xvda 및 /dev/xvdf는 파티션 볼륨이고, /dev/xvdg는 파티션 볼륨이 아닙니다. 볼륨이 파티셔닝된 경우 이후의 단계에서는 원시 디바이스(/dev/xvdf1)) 대신에 파티션(/dev/xvdf)을 마운트해야 합니다.
2. 임시 디렉터리를 만들어 볼륨을 마운트합니다.
```
[ec2-user ~]$ sudo mkdir /mnt/tempvol
```
3. 임시 탑재 지점에 볼륨(또는 파티션)을 탑재하되, 이전에 인식된 볼륨 이름이나 디바이스 이름을 사용합니다. 필요한 명령은 사용자 운영 체제의 파일 시스템에 따라 다릅니다. 디바이스 이름은 인스턴스에서 다르게 표시될 수 있습니다. 자세한 내용은 6단계의 note 섹션을 참조하십시오.
  - Amazon Linux, Ubuntu 및 Debian
```
[ec2-user ~]$ sudo mount /dev/xvdf1 /mnt/tempvol
```
  - Amazon Linux 2, CentOS, SUSE Linux 12, RHEL 7.x
```
[ec2-user ~]$ sudo mount -o nouuid /dev/xvdf1 /mnt/tempvol
```
참고
파일 시스템이 손상되었다는 오류가 발생한다면, 다음 명령을 실행해 fsck 유틸리티를 사용하여 파일 시스템을 확인하고 문제를 해결하십시오.
```
[ec2-user ~]$ sudo fsck /dev/xvdf1
```
임시 인스턴스에서 다음 명령을 사용하여 마운팅된 볼륨의 authorized_keys를 임시 인스턴스에 대한authorized_keys의 새로운 퍼블릭 키로 업데이트합니다.

중요
다음 예는 Amazon Linux 사용자 이름 ec2-user를 사용합니다. Ubuntu 인스턴스의 경우 ubuntu처럼 다른 사용자 이름으로 바꿔야 할 수 있습니다.
```
[ec2-user ~]$ cp .ssh/authorized_keys /mnt/tempvol/home/ec2-user/.ssh/authorized_keys
```
이렇게 복사가 완료됐다면 다음 단계로 넘어갑니다.

(선택 사항) 사용자가 /mnt/tempvol에서 파일을 편집할 권한이 없다면 sudo를 사용하여 파일을 업데이트한 후 이 파일에 대한 권한을 확인해야 원본 인스턴스에 로그인할 수 있는지 여부를 확실하게 알 수 있습니다. 파일에 대한 권한을 확인하려면 다음 명령을 사용하세요.
```
[ec2-user ~]$ sudo ls -l /mnt/tempvol/home/ec2-user/.ssh
total 4
-rw------- 1 222 500 398 Sep 13 22:54 authorized_keys
```
이 예시에서 출력을 보면 222가 사용자 ID이고 500이 그룹 ID입니다. 그런 다음 sudo를 사용하여 실패한 복사 명령을 다시 실행합니다.
```
[ec2-user ~]$ sudo cp .ssh/authorized_keys /mnt/tempvol/home/ec2-user/.ssh/authorized_keys
```
권한이 변경되었는지 확인하려면 다음 명령을 다시 실행합니다.
```
[ec2-user ~]$ sudo ls -l /mnt/tempvol/home/ec2-user/.ssh
```
사용자 ID와 그룹 ID가 변경되었다면 다음 명령을 사용하여 해당 항목을 복구합니다.
```
[ec2-user ~]$ sudo chown 222:500 /mnt/tempvol/home/ec2-user/.ssh/authorized_keys
```

7단계: 임시 인스턴스에서 원본 볼륨을 마운트 해제하고 분리한 다음 원본 인스턴스에 다시 연결

임시 인스턴스에서 연결된 볼륨을 마운트 해제해야 이 볼륨을 원본 인스턴스에 다시 연결할 수 있습니다. 예를 들어 다음 명령을 사용하면 /mnt/tempvol에서 볼륨을 탑재 해제할 수 있습니다.
```
[ec2-user ~]$ sudo umount /mnt/tempvol
```
임시 인스턴스에서 볼륨 분리(이전 단계에서 탑재 해제한 볼륨): Amazon EC2 콘솔의 탐색 창에서 Volumes(볼륨)를 선택하고 원본 인스턴스의 루트 디바이스 볼륨을 선택하고(이전 단계에서 기록한 볼륨 ID 참조) Actions(작업), Detach volume(볼륨 분리)를 선택한 다음 Detach(분리)를 선택합니다. 볼륨이 available 상태가 될 때까지 기다리십시오. (새로 고침 아이콘을 클릭해야 할 수도 있습니다.)
볼륨을 원본 인스턴스에 다시 연결: 볼륨을 선택한 상태에서 Actions(작업), Attach volume(볼륨 연결)을 선택합니다. 원본 인스턴스의 인스턴스 ID를 선택하고, 앞서 2단계에서 원래 루트 디바이스 연결을 위해 메모한 디바이스 이름(/dev/sda1 또는 /dev/xvda)을 지정한 뒤 Attach volume(볼륨 연결)을 선택합니다.

중요
원래 연결과 동일한 디바이스 이름을 지정하지 않으면 원본 인스턴스를 시작할 수 없습니다. Amazon EC2는 sda1 또는 /dev/xvda에서 루트 디바이스 볼륨을 찾습니다.

8단계: 새 키 페어를 사용하여 원본 인스턴스에 연결

원래 인스턴스를 선택하고 인스턴스 상태, 인스턴스 시작을 차례로 선택합니다. 인스턴스가 running 상태로 진입했다면 새 키 페어에 대한 프라이빗 키 파일을 사용하여 해당 인스턴스에 연결할 수 있습니다.

참고

새 키 페어와 해당 프라이빗 키 파일의 이름이 원래 키 페어의 이름과 다른 경우 인스턴스에 연결할 때 새 프라이빗 키 파일의 이름을 지정해야 합니다.

9단계: 정리

(선택 사항) 임시 인스턴스를 더 이상 사용하지 않는 경우 해당 인스턴스는 종료해도 됩니다. 임시 인스턴스를 선택하고 인스턴스 상태, 인스턴스 종료(삭제)를 차례로 선택합니다.

javascript가 브라우저에서 비활성화되거나 사용이 불가합니다.

AWS 설명서를 사용하려면 Javascript가 활성화되어야 합니다. 지침을 보려면 브라우저의 도움말 페이지를 참조하십시오.

문서 규칙

Windows 인스턴스에 대한 일반적인 스크린샷

Linux 인스턴스 상태 확인 실패