DevOps 도구 및 베스트 프랙티스 마스터 - DevOps 지식 허브 DevOps 도구 및 베스트 프랙티스 마스터 - DevOps 지식 허브

일반적인 EC2 인스턴스 연결 문제 및 오류 해결

SSH 및 RDP에 대한 일반적인 EC2 연결 실패를 신속하게 진단하고 해결하는 방법을 알아보세요. 이 실용적인 가이드는 인스턴스 상태 확인, 중요한 보안 그룹 규칙 검증, 상태 비저장 네트워크 ACL 문제 해결, VPC 라우팅 구성 확인을 통해 인스턴스에 대한 즉각적인 액세스를 복원하는 과정을 안내합니다.

일반적인 EC2 인스턴스 연결 문제 및 오류 해결

EC2 연결이 실패할 때 가장 먼저 유용한 질문은 인스턴스에 연결할 수 없는지, 인증을 거부하는지, 아니면 잘못된 경로를 통해서만 연결할 수 있는지입니다. Linux 인스턴스에 SSH를 사용하든 Windows 인스턴스에 RDP(원격 데스크톱 프로토콜)를 사용하든 연결 실패는 흔하고 종종 좌절스럽습니다. SSH 및 RDP 오류는 종종 혼동되지만, Permission denied, Connection timed out, Connection refused 및 빈 RDP 화면은 서로 다른 계층을 가리킵니다. 오류 텍스트를 단서로 삼아 외부에서 내부로 작업하십시오.

1단계: 초기 확인 및 인스턴스 상태

복잡한 네트워크 구성을 살펴보기 전에 인스턴스가 올바르게 실행 중이고 기본 수준에서 연결 가능한지 확인하십시오.

1. 인스턴스 상태 확인

AWS Management Console 또는 AWS CLI를 사용하여 인스턴스의 전반적인 상태를 확인합니다. 두 가지 중요한 확인을 통과해야 합니다.

  • 시스템 상태 확인: 여기서 실패하면 일반적으로 AWS 개입 또는 인스턴스 종료/재생성이 필요한 기본 하드웨어 또는 인프라 문제를 나타냅니다.
  • 인스턴스 상태 확인: 여기서 실패하면 종종 운영 체제 부팅 문제, 파일 시스템 손상 또는 드라이버 문제와 관련이 있습니다. 이 확인에 실패하면 인스턴스가 네트워크 연결을 거부할 정도로 비정상일 가능성이 높습니다.

조치: 확인 중 하나라도 실패하면 인스턴스를 중지했다가 시작(시스템 확인 실패 시 새 하드웨어로 이동)하거나 시스템 로그에서 단서를 확인하는 것을 고려하십시오.

2. 퍼블릭 IP 주소 및 DNS 이름 확인

올바른 주소에 연결을 시도하고 있는지 확인하십시오. 인스턴스를 인터넷에서 직접 연결해야 하는 경우 퍼블릭 IPv4 주소 또는 탄력적 IP와 인터넷 게이트웨이를 통한 퍼블릭 서브넷 경로가 필요합니다. 프라이빗 서브넷에 있는 경우 Bastion Host를 통해 연결하거나 AWS Systems Manager Session Manager를 사용해야 합니다.

  • 팁: 인스턴스가 중지되었다가 시작된 경우 탄력적 IP를 할당하지 않았다면 퍼블릭 IP 주소가 변경되었을 수 있습니다.

3. 클라이언트 구성 확인(SSH/RDP)

연결 오류는 때때로 로컬 문제입니다. 클라이언트 소프트웨어가 올바르게 작동하는지 확인하십시오.

  • SSH(Linux/macOS): 올바른 프라이빗 키 파일(.pem 또는 .ppk)을 사용하고 있는지, 권한이 올바르게 설정되었는지 확인하십시오(chmod 400 /path/to/key.pem).
  • RDP(Windows): EC2 콘솔에서 프라이빗 키 파일을 사용하여 관리자 암호를 해독하여 얻은 올바른 암호를 사용하고 있는지 확인하십시오.

2단계: 보안 계층 진단(가장 일반적인 실패)

보안 구성 오류는 연결 문제의 주요 원인입니다. 보안 그룹과 네트워크 ACL은 모두 방화벽 역할을 하며, 둘 다 필요한 트래픽을 허용해야 합니다.

4. 보안 그룹(SG) 인그레스 규칙

보안 그룹은 인스턴스의 탄력적 네트워크 인터페이스(ENI)에 직접 연결된 상태 저장 방화벽입니다.

Linux(SSH) 요구 사항:

  • 프로토콜: TCP
  • 포트 범위: 22
  • 소스: 사용자의 퍼블릭 IP 주소(My IP) 또는 0.0.0.0/0(모든 IP에 대해, 보안상 권장되지 않음).

Windows(RDP) 요구 사항:

  • 프로토콜: TCP
  • 포트 범위: 3389
  • 소스: 사용자의 퍼블릭 IP 주소 또는 0.0.0.0/0.

문제 해결 단계: 관련 포트(22 또는 3389)에 대해 필요한 인그레스 규칙의 소스를 일시적으로 0.0.0.0/0으로 변경합니다. 연결할 수 있으면 특정 클라이언트 IP 주소가 차단되었거나 올바르게 식별되지 않았기 때문입니다.

경고: 프로덕션 환경에서는 관리 포트(22/3389)에 대해 보안 그룹을 0.0.0.0/0으로 열어두지 마십시오. 가능하면 특정 소스 IP 또는 VPC 엔드포인트를 사용하십시오.

5. 네트워크 ACL(NACL)

네트워크 ACL은 상태 비저장 서브넷 수준 방화벽입니다. 인바운드 및 아웃바운드 트래픽을 독립적으로 확인합니다. 트래픽이 인바운드로 허용되면 반환 트래픽도 아웃바운드로 허용되어야 합니다.

연결을 위한 NACL 요구 사항:

방향 프로토콜 포트 범위 규칙 동작
인바운드 TCP 22(SSH) 또는 3389(RDP) 허용
아웃바운드 TCP 임시 포트(1024-65535) 허용

임시 포트는 중요합니다. 클라이언트가 연결하면(예: 포트 54321에서) 서버는 높은 번호의 임시 포트로 응답합니다. NACL이 이러한 높은 포트에서 아웃바운드 트래픽을 차단하면 서버가 응답을 다시 보낼 수 없어 연결 시간 초과가 발생합니다.

문제 해결 단계: 연결된 NACL에 인바운드 포트(22/3389)와 아웃바운드 임시 포트(1024-65535) 모두에 허용 규칙이 있는지 확인하십시오.

3단계: 라우팅 및 VPC 구성

보안 계층이 열려 있는 것으로 확인되면 문제는 인스턴스의 서브넷으로 트래픽이 라우팅되는 방식에 있습니다.

6. 서브넷 유형 및 라우팅 테이블

연결은 인스턴스가 퍼블릭 서브넷에 있는지 프라이빗 서브넷에 있는지에 전적으로 달려 있습니다.

퍼블릭 서브넷 연결

직접 인터넷 액세스(외부 세계에서 SSH/RDP)의 경우:

  1. 인스턴스에 퍼블릭 IPv4 주소 또는 탄력적 IP가 할당되어 있어야 합니다.
  2. 연결된 라우팅 테이블에는 **인터넷 게이트웨이(IGW)**를 가리키는 0.0.0.0/0 경로가 있어야 합니다.

프라이빗 서브넷 연결

프라이빗 서브넷의 인스턴스는 인터넷에서 직접 연결할 수 없습니다. 연결하려면 다중 홉 경로가 필요합니다.

  1. Bastion Host(점프 박스)를 통한 연결: 퍼블릭 EC2 인스턴스에 SSH로 연결한 다음 Bastion Host에서 프라이빗 인스턴스(프라이빗 IP 사용)로 SSH로 연결합니다.
  2. VPN/Direct Connect를 통한 연결: AWS Site-to-Site VPN 또는 Direct Connect를 사용하는 경우 트래픽을 온프레미스 네트워크로 보낸 다음 프라이빗 서브넷으로 라우팅하도록 라우팅을 구성해야 합니다.

7. OS 수준 방화벽 문제

AWS 보안 확인을 통과하면 EC2 인스턴스에서 실행 중인 운영 체제 자체가 연결을 차단하고 있을 수 있습니다. 이는 Linux의 iptables 또는 Windows Defender 방화벽과 같은 로컬 방화벽을 수동으로 설치하거나 구성한 경우 일반적입니다.

진단(콘솔 또는 Session Manager를 통해 가능한 경우):

  • Linux: iptables -L을 확인하거나 firewall-cmd --list-all을 사용합니다. 포트 22가 명시적으로 허용되는지 확인하십시오.
  • Windows: Windows Defender 방화벽 설정에서 포트 3389에 대한 인바운드 규칙을 확인합니다.

복구 팁: 모든 연결이 끊어진 경우 인스턴스를 중지하고, 루트 볼륨을 분리하고, 작동 중인 복구 인스턴스에 연결하고, OS 구성 파일을 수정하여 방화벽을 비활성화한 다음, 볼륨을 원래 인스턴스 ID에 다시 연결하는 것을 고려하십시오.

퍼블릭, 프라이빗 및 관리형 연결 옵션

모든 EC2 인스턴스가 인터넷에서 SSH 또는 RDP를 수락해야 한다고 가정하지 마십시오. 퍼블릭 인스턴스에는 퍼블릭 주소, 인터넷 게이트웨이 경로, 허용적인 보안 제어 및 실행 중인 리스너가 필요합니다. 프라이빗 인스턴스는 일반적으로 배스천 호스트, VPN, Direct Connect, EC2 Instance Connect Endpoint 또는 Systems Manager Session Manager와 같은 다른 액세스 방법이 필요합니다.

Session Manager는 인바운드 SSH의 필요성을 제거할 수 있기 때문에 운영 팀에 특히 유용합니다. 인스턴스에는 SSM 에이전트, 올바른 Systems Manager 권한이 있는 IAM 인스턴스 프로필, SSM 엔드포인트에 대한 네트워크 액세스가 필요합니다. 프라이빗 서브넷에서는 일반적으로 VPC 인터페이스 엔드포인트 또는 NAT 경로를 통한 아웃바운드 인터넷을 의미합니다. 이러한 부분 중 하나라도 누락되면 인스턴스 자체는 정상이더라도 Session Manager가 옵션으로 표시되지 않습니다.

배스천 설계의 경우 두 구간을 모두 테스트하십시오. 먼저 워크스테이션에서 배스천으로 연결합니다. 그런 다음 배스천에서 대상 인스턴스의 프라이빗 IP로 연결합니다. 대상 인스턴스 보안 그룹은 일반적으로 배스천 보안 그룹에서만 SSH를 허용해야 하며, 사용자 홈 IP나 전체 VPC CIDR에서 허용해서는 안 됩니다(특별한 이유가 없는 한).

RDP의 경우 Windows 부팅은 특히 패치 또는 첫 실행 후 Linux SSH 시작보다 시간이 더 오래 걸릴 수 있습니다. 인스턴스 상태 확인이 방금 통과했지만 RDP가 여전히 실패하는 경우 시스템 로그를 확인하고 방화벽 규칙을 변경하기 전에 몇 분 정도 기다리십시오. 보안 그룹을 반복적으로 교체하면 실제 부팅 또는 서비스 문제를 숨길 수 있습니다.

워크스테이션에서 빠른 테스트

AWS 리소스를 변경하기 전에 작은 네트워크 테스트를 사용하십시오. Linux 또는 macOS에서 nc -vz <public-ip> 22는 TCP 포트 22가 완료되는지 테스트합니다. RDP의 경우 nc -vz <public-ip> 3389를 사용하거나 Windows에서 포트 테스트 도구를 사용하십시오. 시간 초과는 라우팅, 보안 그룹, NACL 또는 업스트림 방화벽을 가리킵니다. 연결 거부는 인스턴스 OS 또는 서비스를 더 많이 가리킵니다.

DNS가 관련된 경우 명시적으로 확인하십시오.

dig +short ec2-203-0-113-10.compute-1.amazonaws.com

그런 다음 결과를 EC2 콘솔의 현재 퍼블릭 IP와 비교하십시오. 탄력적 IP는 안정적으로 유지되지만 자동 할당된 퍼블릭 IP는 중지/시작 후 변경될 수 있습니다. 이것은 손상된 runbook 및 저장된 RDP 프로필의 간단한 원인입니다.

회사 VPN을 사용하는 경우 VPC를 편집하기 전에 다른 네트워크에서 테스트하십시오. 일부 회사 네트워크는 아웃바운드 SSH 또는 RDP를 차단하고 일부 홈 라우터 또는 ISP는 일반적이지 않은 포트를 방해합니다. 다른 네트워크에서의 성공적인 연결은 인스턴스가 괜찮을 수 있음을 알려줍니다.

경로가 명확하지 않은 경우 VPC Reachability Analyzer를 사용하는 것이 좋습니다. 소스와 대상 간의 경로를 모델링하고 라우팅 또는 필터링이 트래픽을 차단하는 위치를 지적할 수 있습니다. 잘못된 SSH 키나 게스트 OS 내에서 중지된 서비스를 수정하지는 않지만 AWS 네트워크 설계 문제를 운영 체제 문제와 분리하는 데 도움이 됩니다.

Flow Logs는 특히 NACL 또는 보안 그룹이 의심스러운 경우에도 도움이 될 수 있습니다. 클라이언트 IP에서 포트 22 또는 3389로의 거부된 흐름은 패킷이 모니터링되는 네트워크 인터페이스 또는 서브넷에 도달하여 거부되었음을 알려줍니다. 흐름이 전혀 없으면 트래픽이 VPC에 도달하지 않았거나, 주소가 잘못되었거나, 잘못된 ENI, 서브넷 또는 시간 창을 보고 있음을 의미할 수 있습니다.

각 환경에 대해 승인된 소스 IP 범위, 배스천 이름, SSM 요구 사항, AMI별 기본 사용자 이름 및 복구 인스턴스 절차 등 소규모 액세스 runbook을 유지하십시오. 모든 엔지니어가 콘솔에서 해당 세부 정보를 다시 찾아야 하는 경우 연결 인시던트 속도가 느려집니다.

또한 의도적으로 프라이빗인 서브넷을 기록하십시오. 이 한 가지 메모는 누군가가 인터넷 경로를 갖도록 설계되지 않은 인스턴스에 직접 SSH를 시도할 때 많은 디버깅 시간을 절약할 수 있습니다.

오류 메시지 읽기

Connection timed out은 일반적으로 패킷이 왕복을 완료하지 못함을 의미합니다. 퍼블릭 IP, 라우팅 테이블, 인터넷 게이트웨이, 보안 그룹 소스, NACL 규칙, 회사 방화벽 및 프라이빗 서브넷에 직접 연결하려고 하는지 확인하십시오.

Connection refused는 일반적으로 네트워크 경로가 인스턴스에 도달했지만 해당 포트에서 수신 대기 중인 항목이 없거나 OS에서 거부했음을 의미합니다. Linux에서는 sshd가 실행 중이고 포트 22에서 수신 대기 중인지 확인하십시오. Windows에서는 RDP가 활성화되어 있고 원격 데스크톱 서비스가 실행 중인지 확인하십시오.

Permission denied (publickey)는 VPC 문제가 아닙니다. 일반적으로 잘못된 사용자 이름, 잘못된 프라이빗 키, authorized_keys에 퍼블릭 키 누락, 홈 디렉토리 권한 변경 또는 Ubuntu 이미지에 ec2-user 대신 ubuntu를 사용하는 등의 AMI 사용자 이름 불일치를 의미합니다.

Windows RDP의 경우 인증 실패는 인스턴스가 교체된 후 오래된 암호 해독된 관리자 암호를 사용하거나, 중지/시작 후 잘못된 퍼블릭 IP에 연결하거나, 도메인 정책이 로컬 로그인 권한을 재정의하기 때문에 자주 발생합니다.

로그인할 수 없는 경우 복구 경로

인스턴스에 Systems Manager 에이전트가 설치되어 있고, SSM 권한이 있는 인스턴스 프로필이 있으며, SSM 엔드포인트 또는 인터넷에 대한 네트워크 액세스 권한이 있는 경우 Session Manager가 일반적으로 가장 덜 방해가 되는 복구 경로입니다. SSH를 전 세계에 열지 않고도 로그를 검사하고, 방화벽 규칙을 수정하거나, authorized_keys를 복구할 수 있습니다.

SSM을 사용할 수 없는 경우 지원되는 곳에서는 EC2 직렬 콘솔을 사용하거나, 루트 볼륨을 분리하여 동일한 가용 영역의 복구 인스턴스에 연결합니다. 조심스럽게 마운트하고, 네트워크 또는 SSH 구성을 수정하고, 마운트를 해제하고, 원래 인스턴스에 다시 연결합니다. 복구 시도를 해도 복구가 더 악화되지 않도록 먼저 스냅샷을 만드십시오.

연결이 실패하면 다음 우선 순위 체크리스트를 따르십시오: 인스턴스 상태, 올바른 주소, 올바른 사용자 이름/키 또는 RDP 암호, 보안 그룹, NACL, 라우팅 테이블, OS 방화벽 및 서비스 상태. 이 순서는 실제 문제가 하나의 오래된 키나 하나의 누락된 경로일 때 5개의 AWS 제어를 변경하는 것을 방지합니다.