AWS BI Jumpstart · 2026

놀 유니버스
WAF 로그 분석

수집은 끝났습니다. 남은 과제는 "무엇을, 어떤 형태로 집계하여 시각화할 것인가"입니다.

발표 · 김도형 (Doohyung Kim)
Solutions Architect, Amazon Web Services

01 현황 진단

현재 환경 — As-Is

WAF 로그의 수집·저장은 이미 완료되어 있습니다. 다음 과제는 이 데이터를 어떻게 시각화·분석할 것인가입니다.

이미 확보된 것

WAF 로그 → S3 적재 완료 · 약 200GB/day, Parquet, 일·시 파티션
QuickSight 보유 · 이미 사용 중인 BI 도구
수집 파이프라인(Firehose) 운영 중

현재의 한계

시각화 미구축 · raw를 그대로 볼 방법이 없음
raw를 Athena로 직접 조회 시 스캔 비용·지연
SPICE에 raw 직접 적재는 한도상 비현실적
"무엇을, 어떤 단위로 보여줄지" 미정의

이미 쌓인 raw를 "어떤 형태로 집계하여 시각화할지"가 중요한 과제입니다.

02 시각화의 전제

왜 "집계"가 먼저인가

QuickSight SPICE는 빠르지만 데이터셋당 용량 한도가 있습니다. raw를 그대로 넣으면 며칠치밖에 담지 못합니다.

SPICE에 넣는 형태	일일 크기(추정)	2TB(Enterprise) 기준 보관
raw 상세 전체	~200 GB	약 10일
축소 상세 · 차단중심 · 컬럼 프루닝	10–30 GB	70–200일
집계 · 시간 × 저카디널리티	수십 MB	수년 (실질 무제한)

집계 결과 크기는 raw 볼륨이 아니라 "차원 카디널리티"에 비례합니다 → 트래픽이 늘어도 집계 테이블은 거의 커지지 않습니다. 결론: raw는 S3에 보존하고, SPICE에는 집계만 넣습니다.

03 선택 사항 논의 ①

무엇을 볼지 고정 → 그 단위로 집계

시각화 항목 (예시 위젯)

개요 · 시간대별 요청·차단 추이, 액션 분포, 차단율, 소스별(CF/ALB)
위협 · 공격 유형 분포(SQLi/XSS/Bot), Rule별 매칭, Rate-based
출처·지리 · Top 차단 IP, 국가별, Top User-Agent
경영진 · 일·주·월 차단 요약, 전기간 대비 증감

집계 테이블 (위젯을 받치는 fact)

테이블	집계 단위
`hourly_overview`	hour×action×source×country×rule
`hourly_attack_type`	hour×attack_category×action
`top_client_ip_daily`	day×clientIp(Top-N)×action

집계는 자동 축소가 아니라 "집계 단위 설계의 결과"입니다. 고카디널리티(IP·URI·UA)를 시간 단위에 그대로 넣으면 거의 안 줄어듦 → 일 단위 Top-N으로 분리. 그래서 먼저 카디널리티 측정이 필요합니다.

03 선택 사항 논의 ① — 보강

집계할 데이터 — WAF 로그 필드 매핑

WAF 로그 필드	집계 역할
`timestamp`	시간 차원 (hour)
`action`	차원 · ALLOW/BLOCK/COUNT
`labels`	공격 유형 차원 · SQLi/XSS/Bot
`terminatingRuleId`	차원 · Rule별
`httpRequest.country`	차원 · 국가
`httpSourceName`	차원 · CF/ALB
`(행 수)`	측정값 · request/blocked_count
`clientIp`	측정(distinct) · Top-N
`uri` · `User-Agent`	Top-N · 고카디널리티

INSERT INTO curated.waf_hourly_overview
SELECT date_trunc('hour', ts) AS hour,
       action, country, terminatingRuleId,
       httpSourceName,
       count(*)                  AS request_count,
       count_if(action='BLOCK')  AS blocked_count,
       approx_distinct(clientIp) AS distinct_ip
FROM cleaned.waf
WHERE month=? AND day=? AND hour=?   -- 증분
GROUP BY 1,2,3,4,5;

저카디널리티(action·country·rule)는 시간 차원으로 / 고카디널리티(IP·URI·UA)는 일 Top-N으로 분리 / 필요 컬럼만 SELECT → raw 스캔 비용↓.

04 선택 사항 논의 ②

함께 결정할 선택지들

결정 항목	선택지	비고
집계 엔진	안 A · Athena 권장 / 안 B · Glue	다음 장에서 안별 비교
curated 저장 포맷	S3 Parquet · 집계 결과, 소량	단순 · 저렴
데이터 신선도	SPICE(시간) / Direct Query(분) / CloudWatch(초·알림)	실시간 수집 ≠ 실시간 시각화
보관 기간	상세 vs 집계 각각 · 롤링 윈도우	SPICE 누적 한계 대응

저성숙·저비용 시작 관점의 기본 권장은 안 A(Athena) + SPICE 대시보드. 집계는 단순 카운트라 Athena로 충분합니다.

05 To-Be 아키텍처 · 1안 기본 권장

안 A — Athena 서버리스 집계

최저 비용 · 서버리스

SQL만으로 집계·서빙. EventBridge로 무인 배치.

운영 단순

인프라 없음 → 저성숙 고객에 가장 적합.

복잡 변환엔 한계

단순 GROUP BY엔 충분 — WAF에 적합.

기본 권장 · 시작점. WAF 집계는 대부분 단순 카운트라 Athena만으로 성능·비용 모두 유리합니다.

05 To-Be 아키텍처 · 2안 조건부

안 B — Glue ETL 집계

복잡 변환에 강함

Spark — 대규모 조인·다단계·커스텀 로직.

DPU 비용

단순 집계엔 기동 오버헤드로 Athena보다 비쌈.

운영 부담

Job 스크립트·스케줄·DPU 튜닝 관리.

조건부. 서빙은 안 A와 동일(Athena). 세션화·다중소스 조인 등 복잡 변환이 분명할 때만 정당화됩니다.

최종 궁극적 모습

종합 To-Be — 2 트랙, 단일 원천

종합 To-Be 아키텍처 · 대시보드 + 에이전트 2 트랙: 단일 raw를 사전 집계로 축소해 QuickSight 대시보드(Track 1)와 Bedrock 에이전트(Track 2, 옵션)가 각자 활용

시작은 안 A(Athena) + SPICE로 단순하게. 옵션(미래)으로 Amazon Quick agentic·Bedrock 연계로 확장합니다.

06 예시 화면

WAF 분석 대시보드 (예시)

야놀자 WAF 보안 대시보드 예시 — KPI(요청·차단·차단율·위협국·Rate 트리거), 시간대별 요청 vs 차단, 공격 유형 분포, Top 차단 IP·국가·URI·봇 User-Agent

01

스캔 최소화

직전 시간 파티션 · 필요 컬럼만 raw에서 읽음.

02

시간 단위 집계

hour GROUP BY로 request/blocked/distinct_ip 계산.

03

고카디널리티 분리

clientIp·uri·UA는 일 Top-N으로 분리(폭증 방지).

04

증분 적재

curated에 CTAS/INSERT, EventBridge로 매시간.

05

SPICE 렌더

curated만 읽어 위젯 렌더 → raw 직접조회 없이 빠르게.

06 예시 화면 — 필요 데이터

대시보드에 필요한 데이터 — 컬럼 정의

위 대시보드 위젯을 채우는 컬럼·타입·설명입니다. WAF 원천 로그 컬럼과 집계 시 생성되는 파생 컬럼으로 나뉩니다.

컬럼	타입	설명	출처
`timestamp`	bigint	요청 시각(epoch ms)	WAF
`action`	string	ALLOW/BLOCK/COUNT	WAF
`terminatingRuleId`	string	매칭 Rule ID	WAF
`httpSourceName`	string	CLOUDFRONT/ALB	WAF
`clientIp`	string	클라이언트 IP	WAF
`country`	string	ISO 국가코드	WAF
`uri`	string	요청 경로	WAF
`httpMethod`	string	GET/POST/…	WAF

컬럼	타입	설명	출처
`headers[UA]`	string	User-Agent	WAF
`labels`	array	공격유형 라벨	WAF
`hour`	timestamp	시간 버킷	파생
`attack_category`	string	SQLi/XSS/Bot	파생
`request_count`	bigint	요청 수	파생
`blocked_count`	bigint	차단 수	파생
`distinct_ip`	bigint	고유 IP 수	파생

raw 원천 컬럼은 그대로 보존하고, hour·attack_category·request_count 같은 파생 컬럼만 집계 시 생성해 curated 테이블에 저장합니다.

06 예시 화면 · 옵션(미래)

Amazon Quick — 대시보드 + AI 질의

Amazon Quick — 대시보드 + AI 질문(Generative BI, 옵션): 좌측 대시보드를 보며 우측 사이드 챗봇에 자연어로 질의 — 급증 공격 유형·SQLi 일별 추이·차단율 높은 URI·SQLi Rule 추천

질의 예시	사용 컬럼	출처
급증 공격 유형	`labels,action`	WAF파생
출처 국가 Top	`country,action`	WAF
SQLi 일별 추이	`labels,hour`	파생
차단율 높은 URI	`uri,action`	WAF
Top 차단 IP	`clientIp,action`	WAF
봇 트래픽 변화	`labels(Bot),hour`	파생

같은 curated 집계 테이블을 조회하므로 raw 직접조회 없이 빠르고 저렴합니다.

07 실행 계획

Quick Win (예시)

단계	내용	산출물
P0 · 현황 측정	카디널리티 측정, Managed Rule·라벨 확인, SPICE 한도·에디션 확인, 컬럼 프루닝 진단	측정 결과 + 임시 대시보드
P1 · MVP 집계	안 A(Athena)로 표준 집계 3종 증분 ETL · EventBridge 스케줄	curated 테이블
P2 · 대시보드	SPICE 대시보드 · 개요·위협·출처	운영 대시보드
P3 · 보안·거버넌스	RLS, KMS, 접근 거버넌스 · 사용자별 권한	정책
P4 · 확장	URI/UA Top-N, Rate-based, 경영진 리포트, 롤링·롤업	확장 뷰
P5 · 궁극 (옵션)	Amazon Quick agentic · 자연어 질의 + Bedrock 에이전트 연계	agentic 워크스페이스

단계별 기간은 야놀자 상황에 맞춰 협의 · 무료 AWS SA 지원 프로그램으로 진행. P0~P2로 빠르게 가치 입증 → 단계적 확장.

다음 단계

함께 결정하고,
빠르게 시작합니다.

01

현황 측정으로 집계 단위 확정

카디널리티 · Rule · SPICE 한도 확인.

02

안 A(Athena)로 MVP 착수

표준 집계 3종 + SPICE 대시보드.

03

신선도·집계 단위 최종 확정

SPICE / Direct Query 신선도 결정.

감사합니다 · 김도형, Solutions Architect, AWS

놀 유니버스WAF 로그 분석