일반적인 EC2 인스턴스 연결 문제 및 오류 해결
Amazon Elastic Compute Cloud(EC2) 인스턴스에 연결하는 것은 클라우드 리소스를 관리하는 데 필수적입니다. Linux 인스턴스에 SSH를 사용하든 Windows 인스턴스에 원격 데스크톱 프로토콜(RDP)을 사용하든, 연결 실패는 흔히 발생하며 종종 좌절감을 유발합니다. 이 가이드는 EC2 인스턴스에 연결할 수 없는 가장 흔한 원인을 진단하고 해결하기 위한 체계적이고 단계별 접근 방식을 제공합니다.
연결 실패를 이해하려면 인스턴스 자체를 넘어서 살펴봐야 합니다. 문제는 일반적으로 보안 계층(보안 그룹, NACL)의 잘못된 구성, 잘못된 네트워킹 설정(VPC 라우팅) 또는 인증 문제에서 비롯됩니다. 이러한 구성 요소를 순서대로 체계적으로 확인하면 근본 원인을 신속하게 격리하고 액세스를 복원할 수 있습니다.
1단계: 초기 확인 및 인스턴스 상태
복잡한 네트워크 구성으로 들어가기 전에, 인스턴스가 올바르게 실행 중이고 기본적인 수준에서 접근 가능한지 확인하십시오.
1. 인스턴스 상태 확인
AWS Management Console 또는 AWS CLI를 사용하여 인스턴스의 전반적인 상태를 확인하십시오. 두 가지 중요한 확인 사항이 통과되어야 합니다:
- 시스템 상태 확인: 이 확인이 실패하면 일반적으로 AWS의 개입 또는 인스턴스 종료/재생성이 필요한 기본 하드웨어 또는 인프라 문제를 나타냅니다.
- 인스턴스 상태 확인: 이 확인이 실패하면 운영 체제 부팅 문제, 파일 시스템 손상 또는 드라이버 문제와 관련되는 경우가 많습니다. 이 확인이 실패하면 인스턴스가 네트워크 연결을 거부할 만큼 충분히 비정상적일 가능성이 높습니다.
조치: 두 확인 중 하나라도 실패하면 인스턴스를 중지했다가 시작하거나(시스템 확인이 실패할 경우 새 하드웨어로 이동됨) 시스템 로그에서 단서를 확인하는 것을 고려하십시오.
2. 퍼블릭 IP 주소 및 DNS 이름 확인
올바른 주소로 연결을 시도하고 있는지 확인하십시오. 인스턴스가 퍼블릭 서브넷에 있는 경우 퍼블릭 IPv4 주소 또는 탄력적 IP(Elastic 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 주소(
내 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은 스테이트리스(Stateless) 방식의 서브넷 수준 방화벽입니다. 인바운드 및 아웃바운드 트래픽을 독립적으로 확인합니다. 트래픽이 인바운드로 허용되면, 반환 트래픽도 아웃바운드로 허용되어야 합니다.
연결을 위한 NACL 요구 사항:
| 방향 | 프로토콜 | 포트 범위 | 규칙 작업 |
|---|---|---|---|
| 인바운드 | TCP | 22 (SSH) 또는 3389 (RDP) | 허용 |
| 아웃바운드 | TCP | 임시 포트 (1024-65535) | 허용 |
임시 포트는 매우 중요합니다. 클라이언트가 연결할 때(예: 54321 포트에서), 서버는 높은 번호의 임시 포트로 응답합니다. 만약 NACL이 이러한 높은 포트에서 아웃바운드 트래픽을 차단하면, 서버는 사용자에게 응답을 보낼 수 없게 되어 연결 시간 초과가 발생합니다.
문제 해결 단계: 인바운드 포트(22/3389)와 아웃바운드 임시 포트(1024-65535) 모두에 연결된 NACL에 허용(Allow) 규칙이 있는지 확인하십시오.
3단계: 라우팅 및 VPC 구성
보안 계층이 열려 있는 것으로 확인되면, 문제는 트래픽이 인스턴스의 서브넷으로 오고 가는 방식에 있습니다.
6. 서브넷 유형 및 라우팅 테이블
연결성은 인스턴스가 퍼블릭 서브넷에 있는지 프라이빗 서브넷에 있는지에 전적으로 달려 있습니다.
퍼블릭 서브넷 연결
인터넷에서 직접 액세스 (SSH/RDP)를 위해:
- 인스턴스에 퍼블릭 IPv4 주소 또는 탄력적 IP가 할당되어야 합니다.
- 연결된 라우팅 테이블에
0.0.0.0/0에 대한 경로가 인터넷 게이트웨이(IGW)를 가리키도록 설정되어 있어야 합니다.
프라이빗 서브넷 연결
프라이빗 서브넷의 인스턴스는 인터넷에서 직접 접근할 수 없습니다. 연결을 위해서는 여러 홉(multi-hop) 경로가 필요합니다.
- 배스천 호스트(점프 박스)를 통한 연결: 퍼블릭 EC2 인스턴스에 SSH로 연결한 다음, 배스천 호스트에서 프라이빗 인스턴스(프라이빗 IP 사용)로 SSH 연결을 합니다.
- 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에 다시 연결하는 것을 고려하십시오.
문제 해결 흐름 요약
연결에 실패하면 다음 우선순위 체크리스트를 따르십시오:
- 인스턴스 상태: 시스템/인스턴스 상태 확인이 통과되었습니까?
- 클라이언트 인증: 키 파일이 올바르고 권한이 설정되어 있습니까 (SSH)?
- 보안 그룹: 보안 그룹이 사용자 IP에서 포트 22/3389에 대한 인바운드 트래픽을 허용합니까?
- NACL: NACL이 인바운드 (22/3389) 및 아웃바운드 (1024-65535) 트래픽을 모두 허용합니까?
- 라우팅: 라우팅 테이블이 퍼블릭 서브넷에 대해 IGW를 가리킵니까?
- OS 방화벽: EC2 인스턴스의 로컬 방화벽이 연결을 허용합니까?
이 여섯 가지 영역을 체계적으로 검토함으로써 대부분의 EC2 연결 실패를 자신 있게 해결할 수 있습니다.