🩺 실제 현장에서 EC2 인스턴스를 트러블슈팅하는 방법 (Instance Diagnostics 사용)

Source: Dev.to

EC2 인스턴스가 오작동하기 시작하면, 저는 먼저 SSH로 접속하거나 재부팅하지 않습니다.

대신 EC2 콘솔을 열고 바로 인스턴스 진단(Instance Diagnostics) 페이지로 이동합니다.

시간이 지나면서 대부분의 EC2 문제는 AWS가 이미 이 페이지에 표시해 주는 정보를 주의 깊게 읽는 것만으로도 이해할 수 있고 — 때로는 해결할 수 있다는 것을 깨달았습니다.

이 블로그에서는 인스턴스 진단의 각 섹션을 실제 현장에서 EC2 문제를 해결하는 데 어떻게 활용하는지 설명합니다.

내가 먼저 답하는 질문

아무것도 건드리기 전에 저는 스스로에게 간단한 질문을 합니다:

이것이 AWS 인프라스트럭처 문제인지, 아니면 인스턴스 내부의 문제인지?

인스턴스 진단은 이 질문에 몇 초 만에 답을 제공합니다.

상태 개요 – 항상 시작점

나는 항상 상단의 Status Overview(상태 개요)부터 시작합니다.

인스턴스 상태

인스턴스가 running(실행 중), stopped(중지) 또는 terminated(종료) 상태인지 표시합니다.
실행 중이 아니라면, 보통 해결할 문제가 없습니다.

시스템 상태 검사

기본 AWS 인프라(물리 호스트, 네트워킹 등)의 상태를 나타냅니다.
이 검사가 실패하면, 문제는 AWS 측에 있습니다. 대부분의 경우 인스턴스를 중지했다가 다시 시작하면 건강한 호스트로 이동하여 해결됩니다.

인스턴스 상태 검사

운영 체제와 내부 네트워킹의 상태를 나타냅니다.
이 검사가 실패하면, 문제는 인스턴스 내부에 있습니다 — 일반적으로 OS 부팅 문제, 커널 문제, 방화벽 규칙, 또는 자원 고갈 등이 원인입니다.

EBS 상태 검사

연결된 EBS 볼륨의 상태를 확인합니다.
이 검사가 실패하면, 디스크 또는 스토리지 수준의 문제가 있을 가능성이 높으며, 데이터 보호가 즉시 최우선 과제가 됩니다.

CloudTrail Events – 구성 변경 추적

문제가 갑자기 발생하면, CloudTrail Events 탭이 다음에 확인하는 곳입니다. 나는 이를 사용하여 다음을 확인합니다:

• 인스턴스가 중지, 시작, 또는 재부팅 되었는지 여부
• 보안 그룹 또는 네트워크 설정이 수정되었는지 여부
• IAM 역할 또는 인스턴스 프로파일이 변경되었는지 여부
• 볼륨이 연결되었는지 혹은 분리되었는지

이를 통해 사람에 의한 변경인지 자동화에 의한 변경인지 빠르게 파악할 수 있습니다.

SSM 명령 기록 – 인스턴스에서 실행된 작업 이해

SSM Command History 탭은 인스턴스에서 실행된 모든 Systems Manager Run Command를 표시합니다. 특히 다음을 파악하는 데 유용합니다:

• 패치 작업
• 유지 관리 스크립트
• 자동 복구
• 구성 변경

최근 명령이 없더라도 해당 정보는 여전히 가치가 있습니다. 이는 SSM 기반 작업이 문제를 일으키지 않았음을 확인해 주기 때문입니다.

도달성 분석기 – 문제가 네트워크와 관련된 경우

인스턴스가 실행 중이지만 접근할 수 없는 경우, 인스턴스 진단에서 바로 도달성 분석기를 엽니다. 이 도구는 다음과 같은 문제를 진단할 때 가장 많이 사용합니다:

• 보안 그룹 문제
• 네트워크 ACL 잘못된 구성
• 라우트 테이블 문제
• 인터넷 게이트웨이 또는 NAT 게이트웨이 연결 문제
• VPC‑간 또는 온프레미스 연결 문제

추측에 의존하지 않고, 도달성 분석기는 네트워크 경로가 정확히 어디에서 차단되는지 시각적으로 보여줍니다.

인스턴스 이벤트 – AWS 주도 작업 확인

Instance Events 탭은 AWS가 인스턴스에 대해 예약하거나 수행한 작업이 있는지 알려줍니다, 예를 들어:

• 예정된 유지 관리
• 호스트 퇴역
• 인스턴스 재부팅 알림

문제가 이러한 이벤트 중 하나와 일치하면, 근본 원인이 즉시 명확해집니다.

인스턴스 스크린샷 – OS가 멈췄을 때

인스턴스에 전혀 연결할 수 없을 경우 인스턴스 스크린샷을 확인합니다. 이는 특히 다음 상황에 도움이 됩니다:

• 부팅 실패 식별
• 커널‑패닉 메시지 감지
• 시작 중 OS가 멈췄는지 확인

단 하나의 스크린샷만으로도 몇 시간에 걸친 트러블슈팅을 설명할 수 있습니다.

시스템 로그 – 부팅 및 커널 문제 이해

시스템 로그는 저수준 OS 및 커널 메시지를 제공합니다. 나는 다음과 같은 경우에 이를 활용합니다:

• 인스턴스가 정상적으로 부팅되지 않을 때
• 서비스가 시작 중에 실패할 때
• 커널 또는 파일 시스템 오류가 의심될 때

로그인하지 않고도 OS 수준 오류를 진단할 수 있는 최고의 도구 중 하나입니다.

[[0;32m  OK  [0m] Reached target [0;1;39mTimer Units[0m.
[[0;32m  OK  [0m] Started [0;1;39mUser Login Management[0m.
[[0;32m  OK  [0m] Started [0;1;39mUnattended Upgrades Shutdown[0m.
[[0;32m  OK  [0m] Started [0;1;39mHostname Service[0m.
         Starting [0;1;39mAuthorization Manager[0m...

[[0;32m  OK  [0m] Started [0;1;39mAuthorization Manager[0m.
[[0;32m  OK  [0m] Started [0;1;39mThe PHP 8.2 FastCGI Process Manager[0m.
[[0;32m  OK  [0m] Finished [0;1;39mEC2 Instance Connect Host Key Harvesting[0m.
         Starting [0;1;39mOpenBSD Secure Shell server[0m...
[[0;32m  OK  [0m] Started [0;1;39mOpenBSD Secure Shell server[0m.
[[0;32m  OK  [0m] Started [0;1;39mDispatcher daemon for systemd‑networkd[0m.
[[0;1;31mFAILED[0m] Failed to start [0;1;39mPostfix Ma… Transport Agent (instance -)[0m.
See `systemctl status postfix@-.service` for details.
[[0;32m  OK  [0m] Started [0;1;39mLSB: AWS CodeDeploy Host Agent[0m.
[[0;32m  OK  [0m] Started [0;1;39mVarnish HTTP accelerator log daemon[0m.
[[0;32m  OK  [0m] Started [0;1;39mSnap Daemon[0m.
         Starting [0;1;39mTime & Date Service[0m...
[   13.865473] cloud‑init[1136]: Cloud‑init v. 25.1.4‑0ubuntu0~22.04.1 running 'modules:config' at Fri, 05 Dec 2025 01:25:29 +0000. Up 13.71 seconds.

Ubuntu 22.04.3 LTS ip‑***** ttyS0

ip‑****** login: [   15.070290] cloud‑init[1152]: Cloud‑init v. 25.1.4‑0ubuntu0~22.04.1 running 'modules:final' at Fri, 05 Dec 2025 01:25:30 +0000. Up 14.98 seconds.  
2025/12/05 01:25:30Z: Amazon SSM Agent v3.3.2299.0 is running  
2025/12/05 01:25:30Z: OsProductName: Ubuntu  
2025/12/05 01:25:30Z: OsVersion: 22.04  
[   15.189197] cloud‑init[1152]: Cloud‑init v. 25.1.4‑0ubuntu0~22.04.1 finished at Fri, 05 Dec 2025 01:25:30 +0000. Datasource DataSourceEc2Local.  Up 15.16 seconds  
2025/12/15 21:35:50Z: Amazon SSM Agent v3.3.3050.0 is running  
2025/12/15 21:35:50Z: OsProductName: Ubuntu  
2025/12/15 21:35:50Z: OsVersion: 22.04  
[1091674.876805] Out of memory: Killed process 465 (java) total‑vm:11360104 kB, anon‑rss:1200164 kB, file‑rss:3072 kB, shmem‑rss:0 kB, UID:1004 pgtables:2760 kB oom_score_adj:0  
[1091770.835233] Out of memory: Killed process 349683 (php) total‑vm:563380 kB, anon‑rss:430132 kB, file‑rss:4096 kB, shmem‑rss:0 kB, UID:0 pgtables:1068 kB oom_score_adj:0  
[1092018.639252] Out of memory: Killed process 347300 (php‑fpm8.2) total‑vm:531624 kB, anon‑rss:193648 kB, file‑rss:3456 kB, shmem‑rss:106240 kB, UID:33 pgtables:888 kB oom_score_adj:0

Session Manager: SSH 없이 안전한 액세스

If Systems Manager가 활성화된 경우, 인스턴스에 접근하기 위해 Session Manager를 사용하는 것을 선호합니다.

• CPU, 메모리 및 디스크 사용량을 확인
• 서비스를 안전하게 재시작
• SSH 포트를 열거나 키 페어를 관리하는 것을 피함

보안 및 운영 관점 모두에서, 이것이 내가 선호하는 접근 방식입니다.

경험이 가르쳐 준 것

EC2 인스턴스 문제 해결은 빠르게 대응하는 것이 아니라, 신중하게 관찰하는 것입니다.

Instance Diagnostics는 이미 다음을 제공합니다:

• 상태 신호
• 변경 이력
• 네트워크 분석
• OS‑레벨 가시성

올바르게 사용하면 이러한 도구가 추측을 없애고 다운타임을 줄여줍니다.

최종 생각

EC2 문제 해결에 대한 나의 접근 방식은 간단합니다:

1. 인스턴스 진단부터 시작합니다.
2. 신호를 이해합니다.
3. 근본 원인이 명확해진 후에만 조치를 취합니다.

대부분의 경우 답은 이미 보입니다 — 우리는 단지 속도를 늦추고 읽으면 됩니다.