AWS Free Tier에서 EC2 인스턴스를 운영하다 보면, CPU 사용률이 100%로 고정되면서 SSH 접속이 불가능한 문제가 발생할 수 있습니다. 이 문제는 주로 다음과 같은 원인으로 발생합니다.
- 특정 프로세스가 CPU를 과부하시키는 경우 (예: 무한 루프, 폭주하는 패키지 업데이트 등)
- AWS Free Tier의 t2.micro / t3.micro 인스턴스에서 CPU 크레딧 부족으로 인해 성능 제한이 걸린 경우
- 네트워크 문제, 보안 그룹 설정 오류, 또는 VPC 라우팅 문제
제 경우는 htop command를 설치하기 위해 여러가지 패키지를 설치하는 과정에서 과부하가 온 것으로 추정하고 있습니다. 이 글에서는 SSH 접속이 멈추거나 불가능할 때 제가 이 문제를 해결한 단계별 가이드를 알려드리려고 합니다.
SSH 접속 불가 시 기본 점검 사항
먼저, AWS 콘솔에서 EC2 인스턴스가 정상적으로 실행 중인지 확인해야 합니다.
"Status Check" 탭에서 시스템 상태 점검 확인
"Instance Status Check" 또는 "System Status Check" 가 실패(⚠️) 라면 서버 자체의 문제가 있을 가능성이 있습니다. 저는 정상적으로 실행되고 있어 이 부분이 문제되진 않았습니다.
✅ 만약 Instance Status Check가 실패하면?
- EC2를 Stop 후 Start 하여 다시 부팅하거나
- 인스턴스가 부팅되지 않는다면, 새로운 인스턴스를 생성하고 데이터를 마이그레이션하는 방법을 고려할 수 있습니다.
SSH 접속 재시도 & 네트워크 점검
기본적인 SSH 접속 시도
ssh -i my-key.pem ec2-user@<EC2_PUBLIC_IP>
SSH 접속을 시도하였을 때, Terminal에서 아무 반응(메시지가 뜨지 않는 등)이 없는 경우 과부하로 인해 접속이 불가한 상황일 수 있습니다. 이 때는 네트워크 문제를 확인해야 합니다.
네트워크 문제 확인
ping <EC2_PUBLIC_IP>- ping: sendto: No route to host → EC2 네트워크 단절 가능성 (VPC, 보안 그룹, 서브넷 문제)
- request timeout → 보안 그룹에서 SSH(22번 포트)가 차단되었을 가능성
사실 이 ping 부분은 논란의 여지가 있습니다. Chat GPT가 제시해준 문제 해결 방식에 ping을 보내 네트워크 문제를 확인하라는 내용이 있는데 이는 반은 맞고 반은 틀립니다.
CPU 과부하 문제를 모두 해결한 뒤에 public ip에 ping을 전송하였지만 이전과 같이 계속 request timeout 메시지가 뜨고 있습니다.
이는 EC2가 보안 그룹이나 VPC(Virtual Private Cloud) 네트워크 설정에 따라 ping(ICMP packet)을 차단할 수도 있기에 일어나는 현상입니다. AWS 기본 설정은 ping(ICMP) 요청을 허용하지 않습니다. 따라서 ICMP을 허용하여야 ping이 정상적으로 작동할 수 있습니다. 이후에도 동일한 현상이 지속될 경우 Network ACL과 EC2 Instance 내부 방화벽을 체크해볼 필요가 있습니다. 이 내용은 CPU 과부하 내용과는 거리가 멀기 때문에 추후에 다루도록 하겠습니다.
보안 그룹에서 SSH(22번 포트) 확인
- AWS 콘솔 → EC2 → Security Groups 이동
- 현재 EC2가 속한 보안 그룹 클릭
- Inbound Rules에서 SSH(22번 포트) 규칙 확인
- Port: 22
- Source: 0.0.0.0/0 (보안상 비추천) 또는 My IP
✅ 설정 후 다시 SSH 접속 시도를 해봅시다.
ssh -i my-key.pem ec2-user@<EC2_PUBLIC_IP>
저는 위 과정을 토대로 SSH 재 접속을 진행하였지만 실패하였습니다. 이후 문제가 일어난 원인을 찾기 위해 모니터링 탭에서 현 상황을 확인하였고, CPU 사용률이 100%로 지속되고 있어 과부하로 인해 SSH 접속이 불가한 것을 알아냈습니다.
CPU 사용률 100%로 인한 SSH 접속 불가 문제 해결
AWS 콘솔에서 CPU 크레딧 확인
- AWS 콘솔 → EC2 → 해당 인스턴스 클릭
- Monitoring 탭에서 "CPU Credit Balance" 확인
CPU 크레딧이 0이면 성능이 제한되어 SSH 접속이 어려울 수 있습니다.
✅ 해결 방법
- EC2를 Stop 후 Start 하면 CPU 크레딧이 일부 회복될 수 있습니다.
- CPU 크레딧이 자주 부족하면, 인스턴스 타입을 t3.small 이상으로 변경을 고려할 수 있습니다.
AWS Systems Manager(SSM)으로 비상 접근
SSH가 불가능할 경우, AWS SSM을 사용하면 EC2 내부로 접근할 수 있습니다.
✅ SSM으로 접속 방법
- AWS 콘솔 → EC2 → 해당 인스턴스 선택
- "Connect" 버튼 클릭
- "Session Manager" 탭 선택 → "Start Session" 클릭
다만 AWS SSM을 사용하기 위해서는 EC2 Instance에 SSM Agent가 미리 설치되어 있어야 하며 올바른 IAM 역할이 적용되었는지 확인해야 합니다. 저는 SSM Agent가 설치되어 있지 않아 인스턴스 타입을 변경하였습니다 (아래 이어지는 내용입니다).
CPU를 과부하시키는 프로세스 확인 및 종료
CPU를 과다 점유하는 프로세스(PID)를 찾아 강제 종료를 하는 방법도 있습니다.
top
kill -9 <PID>
최후의 방법: 인스턴스 타입 변경 (성능 업그레이드)
AWS Free Tier의 t2.micro / t3.micro 인스턴스는 CPU 크레딧이 부족하면 성능이 제한됩니다. 이 경우 인스턴스 타입을 업그레이드하는 것이 해결책이 될 수 있습니다.
✅ 인스턴스 타입 변경 방법
- AWS 콘솔 → EC2 대시보드 → 해당 인스턴스 선택
- Instance State → Stop (중지)
- Actions → Instance Settings → Change Instance Type
- t3.small(또는 t3.medium)으로 변경 후 저장
- Instance State → Start (다시 시작)
🚀 변경 후 다시 SSH 접속 시도
ssh -i my-key.pem ec2-user@<EC2_PUBLIC_IP>결론
이 문제는 CPU 사용률 100%로 인해 SSH 접속이 불가능한 상황에서 발생하는 것으로, CPU 크레딧 부족, 무한 루프 프로세스, 네트워크 설정 문제 등이 원인이 됩니다. 위 방법을 통해 점진적으로 문제를 해결하고 SSH를 복구할 수 있습니다.