일반적인 EC2 인스턴스 연결 문제 진단 및 해결 방법

EC2 연결 문제는 일반적으로 인스턴스, 보안 그룹, 서브넷 규칙, 라우팅 테이블 또는 게이트웨이 경로 중 하나의 차단된 홉으로 귀결됩니다. EC2 인스턴스에 SSH로 접속할 수 없거나, 애플리케이션 포트에 도달할 수 없거나, 한 인스턴스에서 다른 인스턴스로 연결할 수 없는 경우, 규칙을 무작위로 변경하는 대신 네트워크 경로를 순서대로 확인하세요.

아래의 점검 사항은 트래픽이 중단되는 위치를 파악하고 액세스를 복원하는 가장 작은 수정 사항을 적용하는 데 도움이 됩니다.

EC2 연결 문제의 일반적인 원인

연결 문제는 AWS 네트워킹 스택의 다양한 계층에서 발생할 수 있습니다. 근본 원인을 파악하려면 일반적으로 다음 요소들을 조합하여 확인해야 합니다.

보안 그룹: 탄력적 네트워크 인터페이스에 연결된 상태 저장 가상 방화벽입니다. 인스턴스 수준에서 인바운드 및 아웃바운드 트래픽을 제어합니다.
네트워크 액세스 제어 목록(NACL): NACL은 서브넷 수준에서 작동하며 서브넷으로 들어오고 나가는 트래픽에 대한 추가적인 상태 비저장 필터링 계층을 제공합니다.
라우팅 테이블: 서브넷 트래픽이 VPC 내부, 인터넷 게이트웨이, NAT 게이트웨이 또는 트랜짓 게이트웨이 등 어디로 이동할지 결정합니다.
인스턴스 상태 및 네트워킹 구성: EC2 인스턴스 자체의 문제(예: 중지됨, 네트워크 인터페이스 설정 오류)입니다.
인터넷 게이트웨이(IGW) / NAT 게이트웨이: 인터넷 액세스가 필요한 인스턴스의 경우 IGW(퍼블릭 서브넷) 또는 NAT 게이트웨이(프라이빗 서브넷) 구성이 중요합니다.
VPC 피어링 / 트랜짓 게이트웨이: VPC 간 연결 시 이러한 VPC 간 연결 서비스가 올바르게 구성되어야 합니다.

단계별 진단 및 해결

증상부터 시작하여 패킷 경로를 따라가세요.

1. 인스턴스 상태 및 기본 네트워크 연결 확인

복잡한 네트워크 구성을 살펴보기 전에 인스턴스 자체가 정상 상태이고 기본 네트워크 구성이 올바른지 확인하세요.

인스턴스 상태 확인: EC2 콘솔에서 인스턴스를 선택하고 "상태 확인" 탭을 확인합니다. 시스템 확인과 인스턴스 확인이 모두 통과해야 합니다.
퍼블릭 및 프라이빗 IP: 인스턴스에 예상한 주소가 있는지 확인합니다. 퍼블릭 서브넷의 인스턴스는 IPv4를 통한 직접 인터넷 액세스를 위해 퍼블릭 IPv4 주소 또는 탄력적 IP가 여전히 필요합니다.
운영 체제 리스너: 네트워크 경로는 열려 있지만 포트가 여전히 실패하는 경우 인스턴스에서 서비스가 수신 대기 중인지 확인합니다. 예를 들어, 데몬 구성을 변경하지 않았다면 SSH는 TCP 22에서 수신 대기해야 합니다.
DNS 확인: IP로 연결되지만 호스트 이름 조회가 실패하는 경우 VPC DNS 설정, 사용자 지정 확인자 및 Linux의 /etc/resolv.conf를 확인하세요.

2. 보안 그룹 검토

보안 그룹은 EC2 인스턴스와 주고받는 트래픽을 제어하는 상태 저장 방화벽입니다. 연결 문제의 매우 일반적인 원인입니다.

2.1. 인바운드 규칙

Linux의 SSH 또는 Windows의 RDP와 같이 인스턴스에 연결할 수 없는 경우:

EC2 인스턴스에 연결된 보안 그룹을 확인합니다.
인바운드 규칙을 확인합니다: 소스 IP 또는 신뢰할 수 있는 CIDR에서 필요한 TCP 포트를 허용합니다. 관리 액세스의 경우 0.0.0.0/0 대신 현재 퍼블릭 IP를 <your_ip>/32로 사용하는 것이 좋습니다.

예시: IP 주소에서 SSH 액세스를 허용하려면:

유형: SSH
프로토콜: TCP
포트 범위: 22
소스: <your_ip>/32

2.2. 아웃바운드 규칙

인스턴스가 외부 리소스(예: 패키지 다운로드, 다른 AWS 서비스 연결)에 연결할 수 없는 경우:

EC2 인스턴스에 연결된 보안 그룹을 확인합니다.
아웃바운드 규칙을 확인합니다: 기본적으로 보안 그룹은 모든 아웃바운드 트래픽을 허용합니다. 사용자 지정 아웃바운드 규칙이 생성된 경우 대상 포트 및 IP에 필요한 트래픽을 허용하는지 확인합니다.

예시: 모든 아웃바운드 트래픽을 허용하려면:

유형: 모든 트래픽
프로토콜: 모두
포트 범위: 모두
대상: 0.0.0.0/0

3. 네트워크 액세스 제어 목록(NACL) 조사

NACL은 서브넷 수준에서 작동하는 상태 비저장 방화벽입니다. 보안 그룹이나 인스턴스에 도달하기 전에 트래픽을 필터링합니다.

인스턴스의 서브넷과 연결된 NACL을 식별합니다.
인바운드 규칙 확인: NACL은 규칙 번호 순서대로 평가됩니다. 소스 IP의 필수 포트에서 트래픽을 허용하는 인바운드 규칙이 있는지 확인합니다.
아웃바운드 규칙 확인: 마찬가지로 아웃바운드 규칙이 대상으로의 트래픽을 허용하는지 확인합니다.
상태 비저장 특성: NACL은 설정된 연결을 기억하지 않습니다. 흐름의 양쪽 모두에 대한 인바운드 및 아웃바운드 규칙이 필요합니다. 랩톱에서 SSH를 사용하는 경우 서브넷 NACL은 일반적으로 IP에서 인바운드 TCP 22와 반환 트래픽을 위한 IP로의 아웃바운드 임시 포트가 필요합니다. 임시 포트 범위는 운영 체제 및 클라이언트에 따라 다르므로 환경에 적합한 범위를 사용하세요.
규칙 번호 매기기: 낮은 규칙 번호가 먼저 평가됩니다. 명시적 거부 규칙(예: 특정 트래픽을 거부하는 규칙 100)과 허용 규칙(예: 광범위한 트래픽을 허용하는 규칙 200)을 신중하게 사용하세요.

4. 라우팅 테이블 검토

라우팅 테이블은 서브넷의 네트워크 트래픽이 전달되는 위치를 결정합니다. 잘못된 라우팅은 트래픽이 대상에 도달하지 못하게 할 수 있습니다.

인스턴스의 서브넷과 연결된 라우팅 테이블을 찾습니다.
기본 경로 확인: 퍼블릭 서브넷의 인스턴스가 인터넷에 액세스하려면 인터넷 게이트웨이(IGW)를 가리키는 0.0.0.0/0 경로가 있어야 합니다.
```
대상 | 대상
----------------|--------
10.0.0.0/16     | local
0.0.0.0/0       | igw-xxxxxxxxxxxxxxxxx
```
프라이빗 서브넷 및 NAT 게이트웨이: 프라이빗 서브넷의 인스턴스가 아웃바운드 인터넷 연결을 시작하려면 해당 서브넷의 라우팅 테이블에 NAT 게이트웨이 또는 NAT 인스턴스를 가리키는 0.0.0.0/0 경로가 필요합니다.
```
대상 | 대상
----------------|--------
10.0.0.0/16     | local
0.0.0.0/0       | nat-xxxxxxxxxxxxxxxxx
```
VPC 피어링, 트랜짓 게이트웨이 또는 VPN: 인스턴스가 다른 VPC 또는 온프레미스 네트워크와 통신해야 하는 경우 라우팅이 필요한 양쪽 모두에 원격 CIDR 블록에 대한 경로를 올바른 대상에 추가합니다.

5. 인터넷 게이트웨이(IGW) 및 NAT 게이트웨이 연결 문제 해결

인터넷 게이트웨이

*   IGW가 생성되어 VPC에 연결되어 있는지 확인합니다.
*   퍼블릭 서브넷의 라우팅 테이블에 IGW를 가리키는 `0.0.0.0/0` 경로가 있는지 확인합니다.
*   인스턴스에 퍼블릭 IP 주소 또는 탄력적 IP 주소가 할당되어 있는지 확인합니다.
*   보안 그룹 및 NACL 규칙이 필요한 인바운드 및 아웃바운드 트래픽을 허용해야 합니다. 명확한 이유와 보완 제어가 없는 한 전체 인터넷에 민감한 포트를 열지 마십시오.

NAT 게이트웨이

*   NAT 게이트웨이가 생성되어 퍼블릭 서브넷에 있는지 확인합니다.
*   NAT 게이트웨이에 탄력적 IP 주소가 연결되어 있는지 확인합니다.
*   프라이빗 서브넷의 라우팅 테이블에 NAT 게이트웨이를 가리키는 `0.0.0.0/0` 경로가 있는지 확인합니다.
*   프라이빗 및 퍼블릭 서브넷의 NACL 규칙이 아웃바운드 연결 및 반환 트래픽을 허용해야 합니다. NAT 게이트웨이는 보안 그룹을 사용하지 않습니다.

6. VPC 피어링 및 트랜짓 게이트웨이

VPC 간 연결 문제가 발생하는 경우:

VPC 피어링:
- 피어링 연결이 활성 상태이고 두 VPC에서 모두 수락되었는지 확인합니다.
- 두 VPC의 라우팅 테이블에 피어링된 VPC의 CIDR 블록으로의 트래픽을 허용하는 경로가 추가되었는지 확인합니다.
- 두 VPC의 보안 그룹 및 NACL이 필요한 IP 범위 간 트래픽을 허용하는지 확인합니다.
트랜짓 게이트웨이:
- 트랜짓 게이트웨이가 생성되고 관련 VPC가 연결되어 있는지 확인합니다.
- 트랜짓 게이트웨이 라우팅 테이블이 VPC 연결 간 트래픽을 올바르게 라우팅하는지 확인합니다.
- 각 VPC 내의 라우팅 테이블에도 다른 VPC로 향하는 트래픽에 대해 트랜짓 게이트웨이를 가리키는 경로가 있는지 확인합니다.
- 각 VPC 내의 보안 그룹 및 NACL이 VPC 간 트래픽을 허용해야 합니다.

7. AWS 네트워크 연결 도구 사용

AWS는 네트워크 문제 진단을 위한 도구를 제공합니다.

VPC 연결 분석기: 이 도구는 지원되는 소스 및 대상 리소스 간의 연결을 분석합니다. 보안 그룹, NACL, 라우팅 테이블, 게이트웨이 및 관련 네트워크 구성으로 인한 경로 실패를 식별할 수 있습니다.
VPC 흐름 로그: 연결 실패를 직접 진단하지는 않지만 VPC 흐름 로그는 VPC의 네트워크 인터페이스로 들어오고 나가는 IP 트래픽에 대한 정보를 캡처합니다. 이러한 로그를 분석하면 차단되거나 예상치 못한 트래픽 패턴을 발견하여 보안 그룹 또는 NACL의 잘못된 구성을 식별하는 데 도움이 될 수 있습니다.

8. 기타 잠재적 문제

탄력적 네트워크 인터페이스(ENI): ENI가 인스턴스에 연결되어 있고 올바르게 구성되었는지 확인합니다.
서브넷의 라우팅 테이블 연결: 서브넷이 의도한 라우팅 테이블에 올바르게 연결되어 있는지 확인합니다.
DNS 구성: 사용자 지정 DNS를 사용하는 경우 올바르게 확인되는지 확인합니다. 기본 VPC DNS의 경우 VPC에 대해 DNS 확인이 활성화되어 있는지 확인합니다.
프록시 서버: 인스턴스가 프록시를 사용하도록 구성된 경우 프록시 자체에 액세스할 수 있고 올바르게 구성되었는지 확인합니다.

연결 문제 방지를 위한 모범 사례

최소 권한: 최소한의 필요한 권한으로 보안 그룹 및 NACL을 구성합니다. 다른 수단으로 절대적으로 필요하고 보호되지 않는 한 민감한 포트에 0.0.0.0/0을 사용하지 마십시오.
태깅: 네트워크 리소스(VPC, 서브넷, 보안 그룹, 라우팅 테이블)에 일관되게 태그를 지정하여 목적과 연결된 인스턴스를 쉽게 식별할 수 있도록 합니다.
문서화: 네트워크 토폴로지, IP 주소 지정 체계 및 보안 규칙에 대한 명확한 문서를 유지 관리합니다.
정기적인 감사: 보안 그룹 및 NACL 규칙을 정기적으로 검토하여 여전히 관련성이 있고 안전한지 확인합니다.
AWS 도구 활용: 사전 예방적 모니터링 및 문제 해결을 위해 VPC 연결 분석기 및 VPC 흐름 로그를 숙지하세요.

핵심 요약

EC2 연결이 끊어지면 인스턴스 상태, 리스너, 보안 그룹, NACL, 라우팅 테이블, 게이트웨이 및 원격 측 규칙 순서로 경로를 추적하세요. 한 번에 한 계층씩 변경한 다음 다시 테스트합니다. 이렇게 하면 수정 범위를 좁힐 수 있고 다음 중단을 진단하기가 훨씬 쉬워집니다.