SW BBANG K

EC2 인스턴스를 운영하다 보면 CloudWatch 콘솔에서 CPU는 보이는데 메모리가 없다는 걸 처음 마주치는 순간이 있다. 알람을 걸려고 했더니 지표 자체가 없고, 인스턴스가 OOM으로 죽었는데 CloudWatch에는 아무 흔적이 없다. EC2 메모리 사용률 은 기본 CloudWatch 지표에 포함되지 않으며, 이를 수집하려면 CloudWatch Agent를 직접 설치해야 한다. TL;DR — EC2 메모리 모니터링 핵심 요약 항목 기본 CloudWatch CloudWatch Agent 설치 후 CPU 사용률 ✅ 자동 수집 ✅ 자동 수집 네트워크 I/O ✅ 자동 수집 ✅ 자동 수집 디스크 I/O (EBS 바이트) ✅ 자동 수집 ✅ 자동 수집 메모리 사용률 (RAM) ❌ 수집 불가 ✅ 수집 가능 디스크 공간 사용률 (파일시스템) ❌ 수집 불가 ✅ 수집 가능 프로세스별 메모리 ❌ 수집 불가 ✅ 수집 가능 (procstat 플러그인) 왜 EC2 메모리 사용률은 기본으로 보이지 않는가 CloudWatch가 기본으로 수집하는 지표는 AWS 하이퍼바이저 계층에서 관측 가능한 것들이다. CPU 사이클, 네트워크 패킷, EBS I/O 바이트 — 이것들은 인스턴스 외부에서 측정할 수 있다. 반면 OS 내부의 메모리 할당 상태, 파일시스템 사용량, 프로세스 목록은 게스트 OS 안에서만 볼 수 있다. AWS는 EC2 인스턴스 내부 OS에 직접 접근하지 않는다. 이건 보안 모델의 일부이기도 하고, 공유 책임 모델(Shared Responsibility Model)의 경계이기도 하다. 게스트 OS 레이어는 고객 책임 영역이고, AWS는 그 안을 들여다보지 않는다. 결과적으로 메모리 사용률을 수집하려면 인스턴스 안에서 직접 데이터를 밀어내는 에이전트가 필요하다. EBS 디스크 I/O 바이트는 하이퍼바이...

AWS 계정을 처음 만들고 프리 티어로 실습하다가 월말에 예상치 못한 청구서를 받는 경우가 생각보다 많다. EC2 인스턴스를 종료하지 않고 잠들었거나, 실수로 프리 티어 한도를 초과하는 서비스를 켜둔 경우다. CloudWatch 결제 알람(Billing Alarm) 을 미리 설정해두면 요금이 임계값을 넘는 순간 이메일로 알림을 받을 수 있어, 프리 티어 초과를 조기에 차단할 수 있다. TL;DR — CloudWatch 결제 알람 설정 요약 단계 작업 핵심 포인트 1 결제 알람 활성화 루트 계정 또는 결제 권한 보유 IAM 사용자로 Billing 콘솔에서 활성화 필요 2 SNS 주제 생성 us-east-1 리전에서만 생성 — 결제 지표는 이 리전에만 존재 3 이메일 구독 추가 및 확인 구독 확인 이메일의 링크를 클릭해야 알림이 실제로 전송됨 4 CloudWatch 알람 생성 EstimatedCharges 지표, USD 5 임계값 설정 5 동작 확인 알람 상태 및 SNS 구독 상태 검증 결제 알람이 작동하는 방식 — 설정 전에 반드시 알아야 할 구조 CloudWatch 결제 알람은 일반 CloudWatch 알람과 동일한 메커니즘으로 동작하지만, 몇 가지 중요한 제약이 있다. AWS/Billing 네임스페이스의 EstimatedCharges 지표는 us-east-1 리전에서만 게시 된다. 다른 리전에서 알람을 만들려고 해도 이 지표를 찾을 수 없다. 또한 이 지표는 약 6시간마다 업데이트되므로, 실시간 요금 감시 도구가 아니라 누적 요금 경보 도구로 이해해야 한다. 알람이 트리거되면 CloudWatch는 SNS(Simple Notification Service) 주제로 메시지를 발행하고, SNS는 구독된 이메일 주소로 알림을 전달한다. 이 흐름에서 SNS 구독 확인이 완료되지 않으면 알람이 울려...

ALB 액세스 로그에 502가 쏟아지는데 타겟 그룹 콘솔에는 인스턴스가 멀쩡히 Healthy 로 표시되어 있다. 이 상황이 혼란스러운 이유는 ALB의 헬스체크와 실제 요청 처리가 완전히 별개의 레이어에서 동작하기 때문이다. 헬스체크는 통과했지만 실제 HTTP 응답이 ALB의 기대를 벗어나는 순간 502가 발생한다. TL;DR — ALB 502 원인 분류 원인 카테고리 증상 핵심 확인 지점 HTTP 프로토콜 위반 모든 요청에서 502 발생 응답 헤더 형식, Content-Length 불일치 Keep-Alive 타임아웃 불일치 간헐적 502, 로드 증가 시 악화 ALB idle timeout vs 앱 서버 keep-alive timeout 응답 헤더 크기 초과 특정 요청에서만 502 응답 헤더 총 크기 타겟 연결 거부/타임아웃 target_status_code가 비어 있음 보안 그룹, 포트 바인딩 청크 인코딩 오류 대용량 응답에서 502 Transfer-Encoding 헤더 처리 ALB 502가 발생하는 메커니즘 ALB는 클라이언트와 타겟 사이에서 HTTP 레이어 7 프록시로 동작한다. 타겟이 Healthy 상태라는 것은 ALB가 헬스체크 엔드포인트에서 정상 응답을 받았다는 의미일 뿐, 실제 애플리케이션 요청에 대한 응답이 올바르다는 보장이 아니다. ALB는 타겟으로부터 받은 HTTP 응답이 RFC를 위반하거나, 연결이 예기치 않게 끊기거나, 응답 자체를 받지 못하면 클라이언트에게 502를 반환한다. sequenceDiagram participant C as 클라이언트 participant ALB as ALB participant TG as 타겟 인스턴스 C->>ALB: HTTP 요청 ALB->>TG: 요청 전달 (Keep-Alive 연...