ALB 4XX 알람이 계속 발생하는데 사이트는 정상일 때

안녕하세요 클래스메소드 김재욱(Kim Jaewook) 입니다. 이번 블로그에서는 ALB 4XX 알람이 계속 발생하는데 사이트는 정상일 때의 원인을 살펴봤습니다.

AWS 환경을 운영하다 보면 이런 상황을 종종 만나게 됩니다.

• EC2 정상 동작
• ALB 통해 웹 사이트 정상 접근 가능
• 애플리케이션 이상 없음
• 그런데 CloudWatch 알람 메일은 계속 도착

이번에도 정확히 그런 사례였습니다.

발생한 알람

CloudWatch에서 아래와 같은 알람 메일이 지속적으로 수신되었습니다.

Alarm Name:
shayukai-prd-alb-target-http-4xx

Metric:
AWS/ApplicationELB - HTTPCode_Target_4XX_Count

Condition:
5분 동안 4xx 응답이 5건 이상 발생 시 ALARM

핵심은 다음 Metric입니다.

HTTPCode_Target_4XX_Count

이 Metric은 다음을 의미합니다.

ALB가 Target Group 뒤의 애플리케이션(EC2 등)으로부터 받은 4xx 응답 수

참고로 ALB 자체가 반환한 4xx는 다른 Metric입니다.

실제 확인 결과는 다음과 같았습니다.

• 사이트 정상 접속 가능
• ALB Health Check 정상
• Apache 정상 동작
• 애플리케이션 오류 없음
• CPU / Memory 이상 없음

즉, CloudWatch 알람은 발생했지만 실제 장애 상황은 아니었습니다.

원인 확인

원인을 확인하기 위해 ALB Access Log를 분석했습니다.

로그를 확인해보니 외부에서 다양한 요청이 유입되고 있었습니다.

사례 1 — 공개 스캐닝 서비스 요청

다음과 같은 요청이 확인되었습니다.

GET https://54.xxx.xxx.xxx:443/ HTTP/1.1

User-Agent:
HTTP Banner Detection (https://security.ipip.net)

ipip.net 은 공개적으로 알려진 IP 정보 수집 서비스입니다.

인터넷에 공개된 서버들을 자동으로 탐색하며 다음을 수행합니다.

• HTTP Banner 수집
• 포트 상태 확인
• 서버 정보 식별

즉, 특정 서비스를 직접 공격한다기보다는 인터넷 전반을 대상으로 한 자동화 스캐닝 트래픽에 가깝습니다.

사례 2 — Palo Alto Networks Cortex Xpanse

다음과 같은 요청도 확인되었습니다.

GET https://54.xxx.xxx.xxx:443/ HTTP/1.1

User-Agent:
Hello from Palo Alto Networks...

이는 글로벌 보안 업체인 Palo Alto Networks의 인터넷 자산 탐색 서비스(Cortex Xpanse)에서 발생한 요청으로 보였습니다.

• User-Agent에 서비스 정보 명시
• 공식 문서 URL 제공
• 자신들의 스캐닝 활동을 공개적으로 설명

즉, 신원을 숨기는 형태의 요청은 아니었습니다.

사례 3 — Binance API 형태의 요청

가장 흥미로웠던 로그는 아래 요청이었습니다.

GET /public/stream?streams=btcusdt@depth
Host: fstream.binance.com

Result: 404

원래는 Binance API 엔드포인트로 전달되어야 할 요청 형태였지만, 우리 ALB Endpoint로 유입되고 있었습니다.

가능한 시나리오는 다음과 같습니다.

• 잘못된 대상 IP 설정
• 자동화된 봇의 오동작
• 인터넷 스캐닝 과정 중 잘못된 요청

애플리케이션에는 해당 경로가 존재하지 않았기 때문에 자연스럽게 404 응답이 반환되었습니다.

그리고 이 응답이 HTTPCode_Target_4XX_Count 증가로 이어졌습니다.

결국 원인은 “인터넷 노이즈”

정리하면 이번 알람의 원인은 다음과 같았습니다.

공개된 서버나 ALB Endpoint에는 이런 요청이 지속적으로 유입됩니다.

특히 신규 Public Endpoint는 각종 인터넷 스캐닝 시스템에 빠르게 수집되는 경우가 많습니다.

WAF의 가능성?

처음에는 이런 의문이 들 수 있습니다.

“WAF 때문에 이런 요청이 발생하는 건가?”

하지만 실제로는 반대입니다.

인터넷 스캐닝 트래픽 발생
        ↓
ALB 도달
        ↓
WAF가 요청 검사
        ↓
Count 모드라 통과
        ↓
Target(EC2)까지 전달
        ↓
404 발생
        ↓
CloudWatch 알람

• 스캐닝 트래픽은 원래 존재
• WAF는 이를 탐지/차단하기 위한 장치
• 현재는 Count 모드이므로 차단하지 않고 관찰만 수행

중인 상태였습니다.

WAF Block 모드로 전환하면 해결될까?

부분적으로는 도움이 될 수 있습니다.

실제 WAF 로그를 보면 다음이 확인되었습니다.

• User-Agent 없는 일부 요청은 WAF Rule에 매칭
• AWS Managed Rule에서 탐지되는 요청 존재

예를 들어

Rule:
NoUserAgent_HEADER

Action:
COUNT

현재는 Count 모드였기 때문에 실제 차단은 이루어지지 않았습니다.

Block 모드로 전환하면

• 일부 비정상 요청은 ALB 단계에서 차단 가능
• EC2까지 도달하지 않음
• 따라서 Target 4xx 감소 가능

하지만 모든 요청이 차단되지는 않습니다.

예를 들어 다음과 같은 요청은 정상적인 HTTP 요청 형태를 사용하기 때문에 WAF Rule에 걸리지 않을 수도 있습니다.

• ipip.net
• Palo Alto Cortex Xpanse

즉, WAF Block 모드로 전환해도 일부 404 알람은 계속 발생할 수 있습니다.

결국 중요한 건 “알람 기준”

이번 환경의 조건은 다음과 같았습니다.

• 5분 동안 4xx 응답 5건 이상 → ALARM

하지만 공개된 인터넷 서비스 환경에서는 이 기준이 지나치게 민감할 수 있습니다.

실제 운영에서는 보통 다음과 같은 방식으로 조정합니다.

Threshold: 50
EvaluationPeriods: 3

예를 들어 다음과 같이 운영하는 경우가 많습니다.

• 일시적인 스캐닝 트래픽은 무시
• 지속적인 이상 증가만 감지
• 실제 장애와 노이즈를 구분

정리

이번 사례를 통해 다시 느낀 점은, AWS 운영 환경에서 발생하는 모든 CloudWatch 알람이 반드시 “서비스 장애”를 의미하지는 않는다는 점이었습니다.

특히 인터넷에 공개된 ALB나 EC2 Endpoint는 다양한 자동화 트래픽에 항상 노출되어 있습니다.

예를 들어 다음과 같은 요청들은 실제 운영 환경에서 매우 흔하게 관찰됩니다.

• 공개 스캐닝 서비스의 HTTP Banner 수집
• 인터넷 자산 탐색(Security Reconnaissance)
• 잘못된 대상 IP로 전달된 API 요청
• 자동화된 Bot의 비정상 경로 접근
• 존재하지 않는 URL 탐색

이러한 요청들은 애플리케이션 입장에서는 자연스럽게 404 응답으로 이어질 수 있으며, 그 결과 HTTPCode_Target_4XX_Count 증가 및 CloudWatch 알람 발생으로 연결될 수 있습니다.

하지만 중요한 점은, 이런 현상이 반드시 애플리케이션 장애나 보안 사고를 의미하는 것은 아니라는 점입니다.

이번 환경에서도 실제 서비스 상태는 다음과 같았습니다.

• 사이트 정상 접속 가능
• ALB Health Check 정상
• Apache 정상 동작
• 애플리케이션 기능 정상
• 리소스 상태 정상

즉, “알람은 발생했지만 서비스는 정상”인 상태였습니다.

또한 이번 사례를 통해 WAF의 역할에 대해서도 다시 정리할 수 있었습니다.

처음에는 “WAF 때문에 이런 요청이 생기는 것 아닌가?”라는 의문이 들 수 있지만, 실제로는 반대입니다.

WAF는 원인이 아니라, 이미 인터넷에 존재하는 다양한 요청들을 탐지하고 완화하기 위한 장치에 가깝습니다.

특히 Count 모드에서는 다음을 수행합니다.

• 어떤 요청이 Rule에 매칭되는지 관찰
• 정상 요청 오탐(False Positive) 여부 확인
• 실제 차단 전 영향도 분석

이후 충분한 검증이 끝나면 Block 모드로 전환하여 일부 비정상 요청을 차단할 수 있습니다.

다만 Block 모드 역시 모든 스캐닝 트래픽을 완전히 제거하는 것은 아닙니다.

정상적인 HTTP 형태를 사용하는 요청이나 공개 스캐닝 서비스의 접근은 WAF Rule에 매칭되지 않을 수 있으며, 이 경우 일부 404 응답은 계속 발생할 수 있습니다.

결국 운영에서 중요한 것은 단순히 “알람 발생 여부” 자체가 아니라, 해당 알람이 실제 장애 상황을 의미하는지를 구분하는 과정이라고 생각합니다.

특히 공개 서비스 환경에서는 인터넷 노이즈(Noise)와 실제 장애를 분리해서 판단할 수 있어야 하며, 이를 위해 다음과 같은 운영 기준 정리가 중요합니다.

• 서비스 특성에 맞는 CloudWatch Threshold 설정
• Evaluation Period 조정
• WAF Count → Block 단계적 운영
• 정상 스캐닝 트래픽과 이상 징후 구분
• 고객과의 사전 운영 정책 공유

이번 사례에서는 Threshold가 5분 동안 4xx 5건으로 비교적 민감하게 설정되어 있었기 때문에, 일반적인 인터넷 스캐닝 트래픽만으로도 알람이 발생하고 있었습니다.

따라서 실제 운영 환경에서는 다음과 같은 방향도 함께 고려할 필요가 있습니다.

• Threshold 상향
• 지속적인 증가 패턴만 감지
• 실제 서비스 영향 기반 알람 설계
• 불필요한 Alert Fatigue 방지

CloudWatch 알람은 많을수록 좋은 것이 아니라, 실제 대응이 필요한 이벤트를 정확하게 알려줄 수 있어야 운영 효율이 높아집니다.

이번 사례는 AWS 운영에서 흔히 마주칠 수 있는 인터넷 노이즈 기반 4XX 알람 사례였으며, 단순한 에러 숫자만 볼 것이 아니라 로그와 트래픽 성격을 함께 분석하는 것이 중요하다는 점을 다시 확인할 수 있었던 경험이었습니다.