[Cloud] Cloudflare WAF vs AWS WAF: 장애 사례와 트러블슈팅

목차

• 1. 왜 Cloudflare WAF vs AWS WAF 비교가 실무에서 중요한가
• 2. Cloudflare WAF vs AWS WAF 핵심 차이
• Cloudflare WAF가 잘 맞는 경우
• AWS WAF가 잘 맞는 경우
• 3. 실전 구현: 장애 추적을 쉽게 만드는 기본 구성
• Cloudflare 앞단 + AWS 원본 구조 테스트 예시
• AWS WAF Web ACL 설계 예시
• 4. 실제 장애 사례 1: 정상 사용자만 403이 뜨는 상황
• 5. 실제 장애 사례 2: Cloudflare 뒤에 AWS WAF를 붙였더니 원본 IP 판단이 꼬인 경우
• 6. 주의사항: 트러블슈팅할 때 자주 놓치는 포인트
• 7. 검증 방법: 해결됐는지 어떻게 확인할까
• 8. Cloudflare WAF vs AWS WAF, 무엇을 기준으로 선택할까
• 9. 마무리: 웹 방화벽은 도입보다 운영이 어렵습니다
• 자주 묻는 질문
• Cloudflare WAF와 AWS WAF를 같이 써도 되나요?
• 보안 장애가 나면 가장 먼저 뭘 봐야 하나요?
• 처음 도입할 때 바로 차단 정책으로 가도 될까요?

Cloudflare WAF vs AWS WAF: 실제 장애 사례와 트러블슈팅 가이드

Cloudflare WAF vs AWS WAF를 비교해 달라는 요청을 받으면, 저는 기능표부터 꺼내지 않습니다. 실무에서는 웹 방화벽 자체보다도 장애가 났을 때 얼마나 빨리 원인을 좁히고, 우회하고, 복구하느냐가 더 중요하거든요. 저도 초반에는 "둘 다 룰만 잘 넣으면 되는 거 아닌가?" 싶었는데, 운영을 해보면 보는 지점도 다르고 디버깅 방식도 꽤 다르더라고요. 특히 보안 장애는 애플리케이션 오류처럼 로그 한 줄로 바로 드러나지 않아서 초기에 헤매기 쉽습니다.

이번 글은 Cloudflare WAF vs AWS WAF를 단순 스펙 비교가 아니라, 보안 장애와 트러블슈팅 관점에서 정리한 글입니다. 정상 사용자가 막혔을 때 어디부터 볼지, 403이 떴을 때 WAF 문제인지 앱 문제인지 어떻게 가를지, Cloudflare 앞단과 AWS 원본 구성이 함께 있을 때 무엇을 먼저 확인해야 하는지 실무 기준으로 풀어보겠습니다.

Cloudflare 엣지와 AWS 내부 구간에서 WAF가 어떻게 배치되는지 한눈에 보여주는 아키텍처 이미지가 들어갈 자리입니다.

1. 왜 Cloudflare WAF vs AWS WAF 비교가 실무에서 중요한가

두 제품 모두 HTTP 요청을 검사하고 차단하지만, 트래픽을 관찰하는 위치와 운영자가 원인을 추적하는 방식이 다릅니다. Cloudflare WAF는 보통 사용자 요청이 원본 서버에 도달하기 전에 Cloudflare 엣지에서 먼저 평가합니다. AWS WAF는 CloudFront, Application Load Balancer(ALB), API Gateway 같은 AWS 보호 대상 리소스에 연결해 정책을 적용하죠.

그래서 같은 403 응답이어도 의미가 완전히 같지는 않습니다.

• Cloudflare WAF: 원본까지 요청이 가지 않았을 가능성이 큽니다.
• AWS WAF: AWS 리소스 경계까지는 도달했지만 연결된 Web ACL에서 차단됐을 수 있습니다.
• 애플리케이션 403: WAF가 아니라 인증, 인가, 세션, 경로 권한 로직 문제일 수 있습니다.

이 구분을 초반에 못 하면 개발팀은 앱 로그만 보고, 보안팀은 룰만 보고, 인프라팀은 CDN만 보게 됩니다. 장애 대응은 결국 관찰 지점을 분리하는 데서 시작됩니다. 이거 하나만 정리해도 대응 속도가 눈에 띄게 달라지더라고요.

2. Cloudflare WAF vs AWS WAF 핵심 차이

쉽게 말해 Cloudflare WAF는 인터넷 입구 쪽에 더 가깝고, AWS WAF는 AWS 리소스 보호에 더 밀착돼 있습니다. 둘 다 관리형 룰, 커스텀 룰, IP 제어, 레이트 리밋 같은 공통 기능은 있지만 운영 감각은 꽤 다릅니다. 특히 로그를 어디서 보고, 어떤 헤더를 기준으로 클라이언트를 식별하는지가 실무에서는 정말 중요합니다.

항목	Cloudflare WAF	AWS WAF
주요 배치 위치	Cloudflare 엣지	CloudFront, ALB, API Gateway 등 AWS 리소스 앞단
장애 체감 지점	사용자 입장에서 즉시 차단 체감	AWS 서비스 경계에서 정책 적용
원인 추적 포인트	Security Events, 커스텀 룰, 관리형 룰, 봇/레이트 리밋 정책	Web ACL, Rule priority, sampled requests, 로그 대상
복합 구성 시 주의점	원본 IP 전달 헤더와 프록시 체인 확인	커스텀 IP/레이트 룰의 forwarded IP 설정 점검

제가 현업에서 자주 강조하는 포인트가 하나 있습니다. WAF는 보안 장비이면서 동시에 트래픽 해석기라는 점입니다. 어떤 헤더를 보고 판단하는지, 어떤 경로와 메서드에 민감한지, 차단이 어느 단계에서 일어나는지 모르면 운영이 금방 꼬입니다.

Cloudflare WAF가 잘 맞는 경우

• 전 세계 사용자 대상 서비스라 엣지 차단 효과가 중요한 경우
• DDoS 완화, 봇 제어, 캐시와 함께 운영하는 경우
• 원본 서버까지 악성 요청을 최대한 보내고 싶지 않은 경우

AWS WAF가 잘 맞는 경우

• AWS 인프라 중심으로 서비스가 구성된 경우
• CloudFront, ALB, API Gateway와 일관되게 묶어 관리하고 싶은 경우
• 변경 이력과 IaC로 정책을 통제하고 싶은 경우

3. 실전 구현: 장애 추적을 쉽게 만드는 기본 구성

보안 장애에서 제일 아쉬운 순간은 로그를 안 남겼다는 사실을 뒤늦게 깨달을 때입니다. 처음엔 번거로워 보여도, WAF는 차단보다 관측 체계를 먼저 만들어두는 편이 훨씬 낫습니다. 저는 보통 아래 원칙으로 시작합니다.

1. WAF 정책을 처음부터 전부 block으로 넣지 않습니다.
2. 가능하면 count, log, sampled requests 중심으로 먼저 동작을 봅니다.
3. 원본 IP, 요청 경로, 메서드, User-Agent, Host 헤더를 함께 확인합니다.
4. Cloudflare와 AWS를 같이 쓸 때는 어느 계층에서 막혔는지 구분 가능한 로그 기준을 먼저 정합니다.

Cloudflare 앞단 + AWS 원본 구조 테스트 예시

아래 명령은 공개 엔드포인트에서 상태 코드와 응답 헤더를 빠르게 비교할 때 많이 씁니다. 다만 프록시 환경의 원본 IP 판별은 단순 curl 한 번으로 결론내리기보다, Cloudflare 이벤트와 AWS WAF 로그를 함께 맞춰 보는 편이 안전합니다.

# 기본 응답 헤더와 상태 코드 확인
curl -s -o /dev/null -D - https://example.com/

# 로그인 경로 확인
curl -s -o /dev/null -D - https://example.com/login

# 헬스체크 경로 확인
curl -s -o /dev/null -D - https://example.com/health

단순해 보여도 꽤 유용합니다. 정상 경로와 문제 경로를 나눠 보면 어느 계층에서 튕겼는지 감이 잡히거든요. 여기에 시간대까지 맞춰서 WAF 이벤트를 보면 훨씬 빨라집니다.

AWS WAF Web ACL 설계 예시

아래 YAML은 개념 설명용 예시입니다. 콘솔, CloudFormation, Terraform 문법과 1:1로 동일한 배포 파일은 아니고, 룰 우선순위와 관측 포인트를 이해하기 위한 샘플로 보시면 됩니다.

webAcl:
  name: prod-web-acl
  scope: REGIONAL
  defaultAction:
    allow: {}
  rules:
    - name: block-known-bad-ip
      priority: 10
      action:
        block: {}
    - name: rate-limit-login
      priority: 20
      action:
        block: {}
    - name: managed-common-rules
      priority: 30
      overrideAction:
        none: {}
  visibilityConfig:
    cloudWatchMetricsEnabled: true
    sampledRequestsEnabled: true
    metricName: prod-web-acl

실무에서는 priority 때문에 생각보다 많이 헷갈립니다. 저도 처음엔 관리형 룰이 뒤에서 잡을 줄 알았는데, 앞단 커스텀 룰에서 이미 차단되고 있었던 적이 있었습니다. 그래서 장애가 나면 저는 항상 룰 순서부터 먼저 봅니다.

AWS WAF의 Web ACL 우선순위와 Cloudflare 규칙 평가 흐름을 비교해 보여주는 이미지가 들어갈 자리입니다.

4. 실제 장애 사례 1: 정상 사용자만 403이 뜨는 상황

개발팀에서는 로그인 잘 된다고 하는데, 특정 사용자군만 403이 뜨는 경우가 있습니다. 처음엔 브라우저 문제나 쿠키 문제처럼 보여도, 실제로는 정상 트래픽이 봇이나 의심 요청으로 오탐되는 경우가 제법 있습니다. 이런 케이스는 특히 배포 직후나 로그인 경로 변경 직후에 잘 나타납니다.

Cloudflare 쪽에서는 보통 아래 순서로 보는 게 빨랐습니다.

1. 해당 시간대 Security Events에서 URI와 IP를 확인합니다.
2. 차단 룰이 관리형 룰인지, 커스텀 룰인지 분리합니다.
3. 특정 국가, ASN, User-Agent, 봇 정책 조건이 걸려 있는지 봅니다.
4. 원본 서버 로그가 비어 있는지 함께 확인해 앞단 차단인지 가릅니다.

AWS WAF에서는 접근 방식이 조금 다릅니다.

1. 연결된 Web ACL과 보호 대상 리소스를 먼저 확인합니다.
2. sampled requests에서 어떤 룰이 매치됐는지 확인합니다.
3. ALB 액세스 로그나 애플리케이션 로그와 시간대를 맞춰 봅니다.
4. 원본 서버에 요청이 실제로 도달했는지 확인합니다.

핵심은 WAF 403과 앱 403을 분리하는 겁니다. 앱 로그가 전혀 없으면 앞단 차단 가능성이 높고, 앱 로그에 인증 실패나 권한 오류가 남으면 애플리케이션 이슈일 수 있습니다. 당연한 이야기 같지만, 장애 상황에서는 이 기본 분기가 제일 강력합니다.

5. 실제 장애 사례 2: Cloudflare 뒤에 AWS WAF를 붙였더니 원본 IP 판단이 꼬인 경우

이 케이스도 자주 나옵니다. Cloudflare가 프록시 역할을 하고 뒤에 AWS WAF가 또 있는 구조였는데, 로그인 경로의 레이트 리밋이 이상하게 동작하는 상황이었습니다. 사용자 한 명이 과도 요청을 보낸 것도 아닌데 여러 사용자가 묶여 차단되는 느낌이었죠.

원인은 대개 단순합니다. AWS WAF 커스텀 IP 기반 룰이나 rate-based rule이 실제 클라이언트 IP가 아니라 프록시 구간의 주소를 기준으로 평가하면 의도와 다르게 동작할 수 있습니다. 이럴 때는 원본 IP 전달 방식과 forwarded IP 설정을 같이 점검해야 합니다.

• CF-Connecting-IP 또는 X-Forwarded-For를 원본에서 어떻게 수집하는지 확인합니다.
• AWS WAF의 커스텀 IP/Geo/ASN/rate-based rule이 어떤 헤더를 기준으로 평가하는지 확인합니다.
• 프록시 체인이 여러 단계라면 어느 주소가 first IP로 해석되는지 테스트합니다.
• 레이트 리밋은 바로 차단보다 관찰 모드로 먼저 검증합니다.

# 응답 헤더와 상태 코드 확인
curl -s -o /dev/null -D - https://example.com/login

# 특정 경로 반복 호출로 제한 반응 확인
for i in $(seq 1 5); do
  curl -s -o /dev/null -w "%{http_code}\n" https://example.com/api/login
done

직접 겪어보면, 이 문제는 기능 차이보다도 배치 구조를 정확히 이해하지 못한 상태에서 둘을 같이 붙일 때 더 자주 터집니다. 그래서 Cloudflare WAF vs AWS WAF를 비교할 때는 누가 더 좋으냐보다, 누가 어디서 무엇을 보고 차단하느냐를 먼저 정리해야 합니다.

6. 주의사항: 트러블슈팅할 때 자주 놓치는 포인트

이 섹션은 실제 장애 대응에서 체감이 큽니다. 아래 항목만 체크해도 원인 추적 속도가 훨씬 빨라집니다.

• 규칙 우선순위: 먼저 매치된 룰에서 이미 차단됐을 수 있습니다.
• 허용 목록: 관리자 IP만 열어두고 모바일 회선, VPN, 사내 NAT 대역을 빼먹는 경우가 많습니다.
• 경로 예외 처리: /health, /callback, /api/upload 같은 경로는 성격이 달라 별도 예외가 필요할 수 있습니다.
• 메서드 차이: GET은 통과하는데 POST만 막히는 경우가 생각보다 자주 있습니다.
• 헤더 기반 탐지: User-Agent 누락, 비정상 Content-Type, 특이한 Host 헤더 때문에 오탐이 날 수 있습니다.
• 배포 타이밍: 앱 변경과 WAF 룰 변경이 겹치면 원인 추적이 훨씬 어려워집니다.

장애 중에는 룰을 무작정 끄기보다 영향 범위가 좁은 예외부터 적용하는 편이 안전합니다. 예를 들어 전체 관리형 룰을 비활성화하기보다 특정 URI나 특정 파라미터에 한해 임시 예외를 주는 식이죠. 이렇게 해야 보안 노출을 최소화하면서 서비스는 살릴 수 있습니다.

403 응답이 났을 때 어떤 순서로 헤더, 로그, 룰 매치를 따라가야 하는지 보여주는 트러블슈팅 이미지가 들어갈 자리입니다.

7. 검증 방법: 해결됐는지 어떻게 확인할까

문제가 해결된 것처럼 보여도 검증이 약하면 같은 장애가 반복됩니다. 저는 보통 아래 순서로 확인합니다.

1. 차단되던 실제 요청 패턴을 다시 재현합니다.
2. 정상 사용자 시나리오와 악성 의심 시나리오를 둘 다 테스트합니다.
3. WAF 로그에서 의도한 룰만 매치되는지 확인합니다.
4. 애플리케이션 로그와 응답 시간도 같이 봅니다.
5. 임시 예외를 넣었다면 만료 계획과 원복 일정을 남깁니다.

코드 블록은 아주 기본적인 확인용입니다. 여기서 중요한 건 상태 코드만 볼 게 아니라, 어느 레이어에서 응답이 만들어졌는지도 같이 보는 겁니다.

# 정상 페이지 확인
curl -I https://example.com/

# 로그인 엔드포인트 확인
curl -X POST -d "username=test&password=test" https://example.com/login -i

# 헬스체크 경로 확인
curl -I https://example.com/health

검증에서 진짜 중요한 건 200 OK가 나왔는지만 보는 게 아닙니다. 원래 막아야 할 요청이 계속 막히는지도 꼭 같이 봐야 합니다. 서비스는 살렸는데 방화벽이 사실상 꺼진 상태가 되는 게 가장 위험하거든요.

장애 조치 전후로 차단 이벤트와 정상 응답 비율이 어떻게 달라졌는지 보여주는 결과 대시보드 이미지가 들어갈 자리입니다.

8. Cloudflare WAF vs AWS WAF, 무엇을 기준으로 선택할까

정리하면 이렇습니다. 두 제품은 기능 몇 개만 비교해서 고를 대상이 아닙니다. 운영 팀의 시야, 로그 수집 체계, 서비스 배치 구조, 장애 대응 프로세스를 함께 봐야 선택이 훨씬 정확해집니다.

질문	Cloudflare WAF 쪽이 유리한 경우	AWS WAF 쪽이 유리한 경우
트래픽을 어디서 먼저 걸러야 하나?	인터넷 엣지에서 최대한 먼저	AWS 리소스 경계에서 정교하게
운영 중심이 어디인가?	CDN, 엣지 보안, 글로벌 트래픽	AWS 네이티브 리소스 중심
트러블슈팅 포인트는?	원본 도달 전 차단 여부	Web ACL, sampled requests, 리소스 연결 상태
복합 환경 난이도는?	AWS와 조합 시 헤더와 원본 IP 해석 주의	프록시 뒤 커스텀 룰의 forwarded IP 설정 주의

도입을 검토 중이라면 제품 비교표만 보지 말고 장애 시나리오를 먼저 적어보는 걸 권합니다. "로그인 POST가 갑자기 막히면 누가 어디서 무엇을 확인할까?", "Cloudflare와 AWS WAF를 함께 쓰면 어느 계층에서 예외를 줄까?" 같은 질문이 실제 운영 품질을 좌우합니다.

9. 마무리: 웹 방화벽은 도입보다 운영이 어렵습니다

이번 글에서는 Cloudflare WAF vs AWS WAF를 웹 방화벽 비교 차원이 아니라, 보안 장애와 트러블슈팅 중심으로 정리했습니다. 직접 운영해보면 좋은 제품을 고르는 일보다 관찰 가능성을 확보하는 일이 더 중요하다는 걸 금방 느끼게 됩니다. 로그를 남기고, 룰 우선순위를 정리하고, 원본 IP 해석 기준을 분명히 해두면 장애 대응이 훨씬 편해집니다.

핵심만 짚으면 아래 네 가지입니다.

• Cloudflare WAF는 엣지에서 빠르게 차단하는 데 강점이 있습니다.
• AWS WAF는 AWS 리소스와의 통합 운영에 강점이 있습니다.
• 403 장애는 WAF, 프록시, 애플리케이션을 분리해서 봐야 빨리 해결됩니다.
• 복합 구성에서는 헤더와 원본 IP 해석이 가장 자주 문제를 일으킵니다.

다음 글에서는 WAF 예외 처리 패턴과 헬스체크, 로그인, API 업로드 경로를 안전하게 분리하는 방법도 다뤄보겠습니다. 이전에 정리한 리버스 프록시와 원본 IP 전달 방식 글도 함께 보시면 이해가 훨씬 빨라집니다.

도입 환경, 장애 대응 포인트, 운영 난이도를 기준으로 두 WAF를 요약 비교한 인포그래픽 이미지가 들어갈 자리입니다.

자주 묻는 질문

Cloudflare WAF와 AWS WAF를 같이 써도 되나요?

됩니다. 다만 어디서 차단됐는지 구분할 수 있도록 로그, 헤더, 원본 IP 해석 기준을 먼저 정리해두는 게 좋습니다.

보안 장애가 나면 가장 먼저 뭘 봐야 하나요?

응답 코드만 보지 말고 원본 서버 로그 유무와 WAF 이벤트를 함께 보셔야 합니다. 그 분기만 정확히 잡아도 시간을 많이 줄일 수 있습니다.

처음 도입할 때 바로 차단 정책으로 가도 될까요?

권장하지 않습니다. 가능하면 count, log, sampled requests 중심으로 먼저 관찰하고 오탐 여부를 확인한 뒤 점진적으로 차단 강도를 올리는 편이 안전합니다.

📚 함께 읽으면 좋은 글

• AWS GCS vs Azure Blob Storage, 실제 사용 비교와 마이그레이션 전략
• AWS Aurora vs Cloud SQL 1년 운영 회고
• Azure Functions 최신 업데이트와 실전 대응 전략
• OpenStack Trove vs RDS 마이그레이션, 왜 AWS RDS로 옮겼나
• Cloudflare NAS 원격 접속: Tunnel 연결 오류 디버깅 완벽 가이드