AWS WAF는 어디서 동작하나: CloudFront·ALB 연결과 검사 한계

AWS WAF는 ALB 안에 들어 있는 장비가 아니다. Web ACL을 만들고 CloudFront 배포나 Application Load Balancer 같은 지원 리소스에 연결해 HTTP(S) 요청을 검사하는 관리형 서비스다. 따라서 Client → WAF → ALB라는 그림은 검사 순서를 이해하기 위한 논리적 표현이지, WAF가 독립된 네트워크 홉이나 ALB 내부 모듈이라는 뜻이 아니다.

반대로 Network Load Balancer는 WAF Web ACL 연결 대상이 아니다. TCP·UDP·TLS 트래픽을 받는 NLB 앞에서 HTTP 요청 본문까지 WAF로 검사하는 구조를 그리면 서비스 경계를 잘못 섞은 것이다.

Web ACL은 어디에 연결할까

CloudFront와 ALB 중 하나를 무조건 고르는 문제가 아니다. 보호하려는 진입점과 우회 가능성을 기준으로 결정한다.

인터넷 사용자
    │
    ▼
CloudFront ── global Web ACL
    │
    ▼
ALB ───────── regional Web ACL
    │
    ▼
애플리케이션

• CloudFront에 연결하는 Web ACL은 전 세계 엣지에서 배포로 들어오는 요청을 검사한다. CloudFront용 리소스는 Global 범위로 관리한다.
• ALB에 연결하는 Web ACL은 ALB가 있는 리전의 리소스다. ALB와 같은 리전에 있어야 한다.
• 두 곳에 모두 연결하려면 하나의 ACL이 두 번 동작하는 것이 아니라, 범위가 다른 두 Web ACL을 각각 운영하는 구조다.

이중 WAF가 항상 더 안전한 것은 아니다. 규칙 중복, 오탐 조사, 비용과 지연이 함께 늘어난다. 엣지 ACL은 공통 차단과 속도 기반 방어, ALB ACL은 원본에만 필요한 세부 규칙처럼 책임을 나누는 편이 낫다.

CloudFront 앞만 막고 ALB 주소를 인터넷에 그대로 열어 두면 사용자가 CloudFront를 거치지 않고 원본으로 접근할 수 있다. CloudFront가 원본 요청에 비밀 사용자 지정 헤더를 넣고 ALB에서 그 헤더가 없는 요청을 거부하는 방식 등을 함께 검토해야 한다. 헤더 값은 코드나 공개 저장소에 노출하지 않고 주기적으로 교체한다.

규칙은 숫자가 작을수록 먼저 평가된다

Web ACL 안의 규칙은 priority 숫자가 낮은 것부터 평가된다. Allow와 Block 같은 종료 동작이 일어나면 뒤 규칙은 평가하지 않는다. Count는 일치 여부를 기록하면서 다음 규칙으로 넘기는 비종료 동작이다.

새 관리형 규칙이나 사용자 정의 규칙은 곧바로 차단하기보다 다음 순서가 안전하다.

1. Count로 적용해 실제 요청에서 일치량과 오탐을 관찰한다.
2. 로그와 샘플 요청에서 업무상 정상 패턴을 확인한다.
3. 예외 범위를 최소화한 뒤 Block으로 전환한다.
4. 전환 뒤 차단률과 애플리케이션 오류율을 함께 본다.

Count에서 문제가 없었다는 사실도 모든 트래픽이 안전하다는 보증은 아니다. 관찰 기간에 없던 요청과 새 공격 패턴은 별도로 다뤄야 한다.

본문 검사는 전체 요청을 무제한 읽지 않는다

WAF가 요청 본문을 검사한다고 해서 항상 전체 body를 보는 것은 아니다. AWS 문서 기준으로 ALB의 body inspection limit은 8KB로 고정되어 있다. CloudFront는 기본 16KB이며 64KB까지 늘릴 수 있다. 검사 한도를 넘긴 요청을 Continue, Match, No match 중 어떻게 처리할지도 규칙에서 정해야 한다.

예를 들어 큰 JSON 업로드에서 악성 문자열이 검사 범위 뒤에 있다면 기본 설정만으로 놓칠 수 있다. 그렇다고 모든 초과 요청을 차단하면 정상 업로드가 깨질 수 있다. 다음을 같이 결정해야 한다.

• API별 정상 body 크기와 업로드 경로
• 초과 body의 처리 방식
• 파일 업로드를 별도 도메인이나 경로로 분리할지
• 애플리케이션의 스키마 검증과 크기 제한

CloudFront 또는 ALB에 연결한 WAF에서 gRPC 요청의 body inspection 규칙은 적용되지 않는다. 다른 WAF 규칙까지 모두 사라지는 것은 아니지만, 메시지 본문을 WAF가 해석해 막아 줄 것이라고 가정해서는 안 된다. 인증·인가, 입력 검증, 메시지 크기 제한은 애플리케이션과 게이트웨이 계층에서도 필요하다.

구조를 결정할 때 확인할 질문

• 실제 공개 진입점은 CloudFront인가, ALB인가?
• 원본 ALB로 직접 접근하는 우회 경로가 닫혀 있는가?
• Web ACL 범위와 리전이 연결 대상과 맞는가?
• 규칙 priority와 종료 동작 때문에 뒤 규칙이 무시되지 않는가?
• body 검사 한도와 oversize handling이 API 특성에 맞는가?
• 먼저 Count로 오탐을 확인하고 차단으로 전환했는가?

ALB 자체의 요청 처리 흐름은 AWS ALB 요청 흐름 정리, NLB와 함께 쓰는 지원 구조는 ALB와 NLB 조합 패턴에서 이어서 볼 수 있다.

참고 자료

• AWS WAF: Web ACL
• AWS WAF를 연결할 수 있는 리소스
• AWS WAF 규칙 동작
• AWS WAF body inspection limit
• CloudFront 원본 요청에 사용자 지정 헤더 추가