AWS EC2 인스턴스가 정상적으로 실행(Running) 상태임에도 불구하고 SSH(Secure Shell, 포트 22)를 통한 원격 접속이 전혀 되지 않는 가장 흔한 원인은 네트워크 방화벽 설정에 기인합니다. 실제 접속 시도는 사용자의 로컬 환경에서 시작되어 인터넷 게이트웨이, VPC 라우팅 테이블, 서브넷, 그리고 인스턴스 자체에 이르기까지 복잡한 경로를 따라가며 여러 보안 계층을 순차적으로 통과해야 합니다. 이 경로 상에서 핵심적인 보안 제어 요소인 보안 그룹(Security Group)의 인바운드 규칙과 네트워크 ACL(Network Access Control List, NACL)의 인바운드 및 아웃바운드 규칙을 체계적이고 단계적으로 점검하는 것이 문제 해결의 핵심입니다.
AWS EC2 인스턴스가 정상적으로 실행(Running) 상태임에도 불구하고 SSH(Secure Shell, 포트 22)를 통한 원격 접속이 전혀 되지 않는 가장 흔한 원인은 네트워크 방화벽 설정에 기인합니다. 실제 접속 시도는 사용자의 로컬 환경에서 시작되어 인터넷 게이트웨이, VPC 라우팅 테이블, 서브넷, 그리고 인스턴스 자체에 이르기까지 복잡한 경로를 따라가며 여러 보안 계층을 순차적으로 통과해야 합니다. 이 경로 상에서 핵심적인 보안 제어 요소인 보안 그룹(Security Group)의 인바운드 규칙과 네트워크 ACL(Network Access Control List, NACL)의 인바운드 및 아웃바운드 규칙을 체계적이고 단계적으로 점검하는 것이 문제 해결의 핵심입니다.
1. SSH 접속 경로와 보안 계층 이해
SSH 접속이 인스턴스에 도달하기까지는 다음의 두 가지 방화벽을 통과해야 합니다.
- NACL (서브넷 수준): 인스턴스가 속한 서브넷의 트래픽을 제어합니다. 허용(Allow) 및 거부(Deny) 규칙을 사용하며, Stateful(상태 기반)이 아닌 Stateless(무상태) 방식으로 작동합니다. 즉, 인바운드와 아웃바운드 규칙을 모두 명시해야 합니다.
- 보안 그룹 (인스턴스 수준): 개별 인스턴스 또는 ENI(Elastic Network Interface)의 트래픽을 제어합니다. 허용 규칙만 지정 가능하며, Stateful 방식으로 작동합니다. (인바운드 허용 시 관련 아웃바운드는 자동 허용)
2. 점검 순서 1: 보안 그룹 (인스턴스 수준 방화벽)
보안 그룹은 인스턴스에 가장 직접적으로 적용되는 방화벽이므로, 가장 먼저 확인해야 할 사항입니다.
2.1. SSH 인바운드 규칙 확인
- 진단: EC2 인스턴스에 연결된 보안 그룹의 인바운드(Inbound) 규칙을 확인합니다.
- 필수 규칙: SSH(TCP 포트 22)에 대한 허용 규칙이 명시되어 있어야 합니다.
- 소스 IP 주소: 소스가
0.0.0.0/0(전체 허용, 보안 위험) 또는 사용자가 현재 접속을 시도하는 공인 IP 주소로 정확하게 설정되어 있는지 확인합니다. 회사 네트워크라면 회사 IP 대역이 소스로 지정되어야 합니다.
2.2. 인스턴스 상태 및 인증서 점검 (선행 조건)
보안 그룹은 통과했지만 인스턴스 내부 문제로 접속이 안 될 수 있습니다.
- 인스턴스 상태: 인스턴스 상태 검사(Status Check)가 모두
2/2 checks passed인지 확인합니다. 만약 Instance Reachability Check Failed 오류가 있다면 OS 내부 문제이므로, 네트워크 방화벽 문제가 아닙니다. - 키 페어 (Key Pair): 인스턴스 시작 시 사용된 PEM 파일이 정확하고, 해당 파일에 대한 접근 권한(퍼미션)이 올바르게 설정되어 있는지 확인합니다.
3. 점검 순서 2: 네트워크 ACL (서브넷 수준 방화벽)
보안 그룹은 통과했지만 NACL에서 트래픽을 차단했을 수 있습니다. NACL은 무상태(Stateless)이므로 인바운드와 아웃바운드 규칙을 모두 점검해야 합니다.
3.1. SSH 인바운드 규칙 확인 (요청)
- 진단: 인스턴스가 속한 서브넷에 연결된 NACL의 인바운드 규칙을 확인합니다.
- 필수 규칙: 소스
0.0.0.0/0또는 접속자 IP로부터 TCP 포트 22를 허용하는 규칙(Allow)이 낮은 번호로 명시되어 있어야 합니다. (규칙 번호가 낮을수록 우선순위가 높습니다.)
3.2. SSH 아웃바운드 규칙 확인 (응답)
SSH 접속이 성공하려면 서버의 응답 트래픽이 클라이언트로 돌아가야 합니다.
- 문제 원리: NACL은 무상태(Stateless)이므로, 인바운드 요청을 허용했더라도 응답 트래픽을 위한 아웃바운드 규칙이 없으면 통신이 끊깁니다.
- 필수 규칙:
- 대상: 클라이언트의 IP 주소(또는
0.0.0.0/0) - 프로토콜: TCP
- 포트 범위: Ephemeral Port (임시 포트, 1024-65535)를 허용하는 아웃바운드 규칙이 있어야 합니다. 클라이언트가 SSH 요청을 보낼 때 사용하는 소스 포트가 바로 이 임시 포트이기 때문입니다. 가장 안전한 방법은 모든 트래픽(0-65535)을 허용하는 규칙을 추가하는 것입니다.
- 대상: 클라이언트의 IP 주소(또는
4. 최종 점검: 라우팅 및 공인 IP
위의 방화벽 설정이 모두 올바른 경우, 라우팅 테이블이나 공인 IP 할당 문제를 확인합니다.
- 라우팅 테이블: 인스턴스가 인터넷과 통신하기 위해 서브넷의 라우팅 테이블에 인터넷 게이트웨이(IGW)로 향하는 기본 경로(
0.0.0.0/0)가 설정되어 있는지 확인합니다. - 공인 IP 할당: 인스턴스가 퍼블릭 서브넷에 있다면 자동 공인 IP 할당이 활성화되었거나 Elastic IP(EIP)가 연결되어 있는지 확인합니다. 공인 IP 없이는 외부에서 접속할 수 없습니다.
Disclaimer: 본 블로그의 정보는 개인의 단순 참고 및 기록용으로 작성된 것이며, 개인적인 조사와 생각을 담은 내용이기에 오류가 있거나 편향된 내용이 있을 수 있습니다.