Conceptly
← 전체 목록
🛡️

AWS WAF

보안웹 애플리케이션 방화벽

WAF는 공개 웹 엔드포인트로 들어오는 HTTP 요청을 규칙으로 검사해 악성 패턴을 먼저 걸러내는 방어 계층입니다. 애플리케이션 코드에 도달하기 전 단계에서 공통 웹 공격을 차단합니다.

아키텍처 다이어그램

🔗 관계 다이어그램

점선 애니메이션은 데이터 또는 요청의 흐름 방향을 나타냅니다

왜 필요한가요?

공개 웹 서비스는 애플리케이션에 도달하기 전부터 봇, 스캔, SQL 인젝션, 과도한 요청을 맞습니다. 이 트래픽을 가장 앞단에서 걸러내지 못하면 백엔드가 정상 요청과 악성 요청을 함께 감당해야 합니다.

왜 이런 방식이 등장했나요?

웹 서비스가 공개되면 SQL 인젝션, XSS 스캔, 크리덴셜 스터핑 같은 자동화된 공격이 하루 수천~수만 건 들어옵니다. 초기에는 이런 필터링을 애플리케이션 코드 안에서 처리했지만, 요청이 앱 서버까지 도달한 뒤에야 걸러지므로 백엔드 성능이 악성 트래픽에 함께 끌려 내려갔습니다. 앱 레벨에서 규칙을 관리하면 서비스마다 필터링 로직이 제각각이 되고, 새로운 공격 패턴에 대응하는 속도도 느려집니다. 이 문제를 해결하기 위해 엣지나 로드 밸런서 앞단에서 HTTP 요청을 먼저 검사하고 차단하는 전용 방화벽 계층인 WAF가 자리를 잡았습니다.

내부적으로 어떻게 동작하나요?

WAF는 규칙 세트를 CloudFront, ALB, API Gateway 앞단에 붙여 요청을 검사하고 차단하거나 허용합니다. SQL 인젝션, XSS, 봇 트래픽 같은 공통 공격 패턴을 Managed Rules로 빠르게 막을 수 있고, 필요하면 CAPTCHA와 사용자 정의 규칙까지 더해 메트릭과 로그를 CloudWatch, S3로 보냅니다.

경계와 구분

WAF와 IAM은 둘 다 보안 서비스지만 막는 지점이 다릅니다. IAM은 자격증명 기반 권한을 제어하고, WAF는 공개 엔드포인트로 들어오는 HTTP 요청 자체를 필터링합니다. 누가 AWS 리소스에 접근할 수 있는지가 문제면 IAM을 보고, 공개 웹 트래픽에서 악성 요청을 걸러야 하면 WAF를 보면 됩니다.

언제 쓰나요?

대표적인 구성은 CloudFront 배포나 ALB 앞에 WAF를 붙이고 AWS Managed Rules의 OWASP Top 10 규칙 세트를 적용하는 것입니다. 이렇게 하면 SQL 인젝션, XSS 같은 공통 공격 패턴이 앱 서버에 도달하기 전에 차단됩니다. 공개 API를 운영할 때는 API Gateway 앞에 WAF를 두고 속도 기반 규칙으로 특정 IP의 과도한 요청을 제한할 수 있습니다. 봇 트래픽이 문제되는 서비스에서는 Bot Control 규칙 그룹을 추가해 스크래핑과 크리덴셜 스터핑을 걸러냅니다. 다만 WAF는 HTTP 요청 레이어에서 동작하므로, 사용자 인증이나 AWS 리소스 간 권한 제어는 WAF의 역할이 아닙니다.

SQL 인젝션 방어XSS 방지봇 차단지리적 제한