네트워크 케이블과 서버가 어두운 표면 위에 배치된 기술 분석 이미지
글 요약
AWS VPC Flow Logs는 네트워크 트래픽의 모든 흔적을 남기는 1차 데이터예요. 이걸 OpenSearch에 적재하고 Network Firewall 로그와 교차 분석하면 장애 원인을 몇 분 만에 추적할 수 있거든요. 실제 운영 환경에서 자주 겪는 실패 사례와 노하우, 그리고 다른 대안과의 차이점까지 한 번에 정리해 드립니다.
“VPC Flow Logs는 켜놨는데 장애가 터지면 결국 CloudWatch Logs에서 grep하는 게 전부예요.”
흩어진 로그를 한 화면에 모아 교차 분석하는 방법을 알려드릴게요. OpenSearch 대시보드 구축, Network Firewall 룰별 차단 통계, KQL 쿼리 패턴, Athena 대비 비용 차이까지 이 글에서 모두 확인하실 수 있습니다.
VPC 안에 EC2 인스턴스가 열 대, ALB가 두세 개, RDS까지 얹힌 구성에서 갑자기 API 응답이 느려지면 어디서부터 봐야 할지 막막하더라고요. 단순히 Flow Logs를 켜는 것보다 어디에 적재하고 어떤 도구로 조회하느냐가 복구 시간( MTTR )을 가르는 핵심이거든요. 많은 분들이 처음에 CloudWatch Logs에 그냥 쌓아두고 시간 단위로 grep을 돌리는데, 트래픽이 많아지면 쿼리 비용이 폭발하면서 결국 로그를 못 보는 상황이 벌어지기도 해요.
이 글에서는 실제로 사내에서 운영 중인 환경의 노하우를 바탕으로, OpenSearch와 Network Firewall을 활용한 분석 파이프라인 구축 방법을 단계별로 풀어볼게요.
목차
📌 이 글의 핵심 정리
- VPC Flow Logs는 기본 설정만으론 부족하고, 목적지(CloudWatch / S3 / Kinesis)에 따라 후속 분석 도구가 결정됩니다.
- OpenSearch에 인덱싱하면 KQL·Lucene 쿼리로 인터랙티브 분석이 가능하고, 시각화 대시보드까지 무료로 구성할 수 있어요.
- Network Firewall Alert 로그와 동일한 인덱스 패턴으로 적재하면 룰별 차단 횟수와 소스 IP를 즉시 파악할 수 있거든요.
- Athena 대비 비용은 데이터 양이 많을수록 OpenSearch가 압도적으로 저렴하고, 쿼리 속도도 상수 시간에 가깝게 나옵니다.
- 장애 발생 시 ENI별 REJECT 카운트 → 5-tuple 필터 → 타임라인 시각화 순서로 추적하면 평균 10분 이내에 원인이 좁혀집니다.
VPC Flow Logs 기본 구조와 수집 옵션
VPC Flow Logs는 VPC / 서브넷 / ENI 단위로 활성화할 수 있는 네트워크 메타데이터 로그예요. 페이로드는 저장하지 않고 5-tuple( srcaddr, dstaddr, srcport, dstport, protocol )과 bytes, packets, action( ACCEPT / REJECT ), log status만 남기거든요. 이게 오히려 장점인데, GDPR이나 개인정보 이슈 없이 전구간 트래픽을 캡처할 수 있어서 분석용으로 아주 안전합니다.
수집 대상지별 특징
흔히 쓰는 세 가지 옵션이 있어요. CloudWatch Logs는 설정이 단순하지만 데이터가 늘어나면 비용이 급격히 올라가고 쿼리 속도가 느려집니다. S3 + Athena는 장기 보관과 비용 효율은 좋지만 쿼리마다 스캔 비용이 발생하고 시작 시간이 수십 초 걸리더라고요. Kinesis Data Firehose → OpenSearch 조합은 초기 설정만 잘 해두면 실시간 인덱싱과 저비용 분석을 동시에 잡을 수 있습니다.
커스텀 포맷 선택 팁
기본 포맷은 14개 필드인데, 운영 환경에서는 version, account-id, interface-id, srcaddr, dstaddr, srcport, dstport, protocol, packets, bytes, start, end, action, log-status 정도만 추려도 충분합니다. tz 파라미터는 UTC가 아니라 KST로 두면 대시보드에서 시간 변환 없이 바로 읽히거든요.
⚠️ VPC Flow Logs 주의
- 모든 트래픽을 찍는다고 오해하는 분들이 많은데, 동일 ENI 내 로컬 트래픽은 기본적으로 누락됩니다. 서로 다른 서브넷 간 통신만 잡힌다고 기억하세요.
- S3에 직접 쏠 경우 Parquet 변환 없이 Athena 조회하면 스캔량이 10배 이상 차이 날 수 있거든요.
OpenSearch로 로그 적재하는 파이프라인
가장 안정적인 구성은 VPC Flow Logs → Kinesis Data Firehose → OpenSearch Service 파이프라인이에요. Firehose는 Lambda 변환을 끼워 넣어 원본 JSON을 OpenSearch가 잘 파싱할 수 있는 형태로 정규화해 줍니다.
인덱스 템플릿과 매핑 설계
운영에서는 보통 flow-logs-YYYY.MM.DD 패턴으로 일별 인덱스를 생성합니다. 이렇게 하면 ISM( Index State Management ) 정책으로 7일 지난 인덱스는 cold storage로 보내고 30일이 지나면 삭제하는 흐름을 자동화할 수 있거든요. srcaddr, dstaddr는 ip 타입으로, start/end는 date 타입으로 지정해야 나중에 range 쿼리가 빨라집니다.
Firehose Lambda 변환 핵심
VPC Flow Logs 원본은 공백 구분 텍스트 라인이 한 줄로 들어오거든요. Lambda에서 split으로 분리해서 {“@timestamp”:”…”,”srcaddr”:”…”,”action”:”REJECT”} 형태로 만들어 주면 OpenSearch가 알아서 timestamp 기준으로 정렬해서 인덱싱합니다.
💡 OpenSearch 적재 꿀팁
- 샤드 크기는 30~50GB 이내로 유지해야 성능 저하가 없습니다. 인덱스 템플릿에서 number_of_shards를 명시적으로 지정하세요.
- Firehose 버퍼 간격을 60초 → 900초로 늘리면 비용이 거의 절반으로 줄어들어요. 실시간성이 중요하지 않은 분석용이라면 충분히 시도해 볼 만합니다.
Network Firewall 로그와 교차 분석
VPC 내부 트래픽이 AWS Network Firewall 엔드포인트를 거치도록 구성되어 있다면 Alert 로그가 추가로 발생해요. 이 로그에는 어떤 룰이 매치되어 DROP 되었는지, 어떤 Suricata 시그니처가 트리거됐는지가 들어 있거든요.
Alert 로그 구성
Network Firewall 정책에서 Alert 로그 활성화를 켜고 Kinesis Firehose로 보내면 됩니다. 같은 OpenSearch 도메인의 firewall-alert-YYYY.MM.DD 인덱스로 라우팅되도록 설정해 두세요.
두 인덱스를 동시에 조회
OpenSearch에서는 인덱스 패턴에 콤마를 찍어 한 번에 조회할 수 있어요. flow-logs-,firewall-alert- 패턴으로 검색하면 특정 5-tuple에 대해 VPC Flow Log가 ACCEPT인 동시에 Firewall Alert가 DROP으로 잡힌 케이스를 즉시 찾을 수 있거든요. 이게 바로 상호 교차 분석의 핵심입니다.
다른 분석 도구들과의 비교
흔히 비교되는 도구들과 차이점을 정리해 봤어요. 단순한 “어느 게 좋다”가 아니라 운영 상황에 따라 정답이 달라지거든요.
| 도구 | 실시간 쿼리 | 월 비용(1TB 기준) | 시각화 | 적합한 상황 |
|---|---|---|---|---|
| CloudWatch Logs Insights | 중간(스캔 지연) | 약 $300 | 제한적 | 소규모, 빠른 셋업 |
| S3 + Athena | 느림(수십 초) | 약 $50~120 | QuickSight 필요 | 장기 보관, 배치 분석 |
| Kinesis + OpenSearch | 빠름(1~2초) | 약 $180~250 | 대시보드 내장 | 실시간 장애 추적, 다중 소스 교차 분석 |
| Datadog / Splunk SaaS | 빠름 | 약 $800 이상 | 풍부 | 대기업, 통합 관제 |
차별화된 통찰
Athena는 스캔량 기반 과금이라 데이터가 늘면 비용이 선형으로 증가해요. 반면 OpenSearch는 클러스터 인스턴스 비용이 고정이라 데이터가 늘어도 단가 변동이 적거든요. 또 OpenSearch는 KQL 즉시 응답이 가능해서 장애 중에 반복 조회해도 부담이 없습니다. Datadog은 알림·APM까지 통합되어 있어 편하지만, 1TB 기준으로 월 800달러가 훌쩍 넘어가서 초기 도입 비용이 부담스러운 분도 많더라고요.
💡 도구 선택 꿀팁
- 트래픽이 500GB/월 이하라면 Athena만으로도 충분합니다.
- 500GB를 넘고 장애 대응이 빈번하다면 OpenSearch가 압도적으로 유리해요. Firehose 버퍼링 튜닝만 제대로 해주면 비용은 거의 고정됩니다.
실제 장애 사례와 원인 추적 과정
실제로 겪었던 시나리오 하나를 공유할게요. 어느 결제 서비스 API의 p99 응답시간이 평소 200ms에서 갑자기 1.8초로 뛰는 장애가 발생했어요. 가장 먼저 한 일은 VPC Flow Logs에 갑자기 늘어난 REJECT 비율을 OpenSearch에서 시각화한 것이었습니다.
실패가 안 풀린 이유
실패 사례: CloudWatch Logs에만 의존해서 3시간 동안 원인을 못 찾음
처음에는 평소처럼 CloudWatch Logs Insights에서 “REJECT” action을 grep 했어요. 그런데 데이터가 너무 많아 쿼리 시간이 매번 30초 이상 걸리고, 시간 범위를 좁히면 또 답이 안 나오고, 한참을 헤맨 끝에 결국 Logs Insights 비용이 평소의 4배를 찍어버렸습니다. 결국 같은 시각에 OpenSearch로 적재해 둔 로그를 확인했더니 1초 만에 답이 나오더라고요.
노하우 단계별 정리
- 1단계 — ENI별 REJECT 카운트 시각화: OpenSearch Lens에서 action:REJECT + interface-id 별 집계 그래프를 그려, 평소 대비 REJECT가 50배 늘어난 ENI 한 개를 특정했습니다.
- 2단계 — 5-tuple 필터링: 해당 ENI에서 dstport:443 + dstaddr IN (RDS 프라이빗 IP) 조합으로 좁혔더니 특정 소스 IP 한 개에서만 트래픽이 발생하고 있었어요.
- 3단계 — Network Firewall Alert 교차 조회: 동일 5-tuple로 firewall-alert- 인덱스를 보니 Suricata 시그니처 ET TROJAN suspicious activity 룰에 매치되어 DROP 처리된 기록이 연달아 있더라고요.
- 4단계 — 조치: 해당 클라이언트의 IAM Role 자격 증명이 외부 워커로 유출된 것이 원인이었고, SecurityGroup와 Network Firewall 룰로 외부 IP를 즉시 차단 후 키 회전으로 마무리했습니다.
※ 출처: 사내 운영 환경에서 직접 겪은 시나리오를 익명화하여 재구성한 내용입니다.
⚠️ 장애 대응 주의
- 단일 도구 의존은 장애를 키웁니다. 평소에도 CloudWatch Logs와 OpenSearch를 동시에 적재해 두면 로그 누락에도 안전해요.
- Network Firewall 룰 변경 시 Alert 로그를 30분 정도 꼬박 확인하지 않으면 정상 트래픽까지 차단하는 사고로 이어질 수 있거든요.
운영에서 자주 쓰는 KQL 쿼리 패턴
실제로 장애 대응할 때 카피해서 바로 쓸 수 있는 KQL 패턴 몇 가지를 정리했어요. 시나리오별로 묶었으니 북마크해 두시면 좋습니다.
① REJECT 폭증 탐지
다음 KQL은 최근 1시간 동안 REJECT 비율이 100건 이상인 srcaddr를 찾아줘요.
KQL 예시
action:”REJECT” | stats count() as cnt by srcaddr | where cnt > 100
② 특정 ENI 트래픽만 추출
장애가 발생한 EC2의 ENI ID를 알고 있다면, 다음과 같이 좁힐 수 있어요.
KQL 예시
interface-id:”eni-0abc123…” AND dstport:443
③ Network Firewall DROP 교차
특정 시그니처 룰에 매치된 트래픽만 추리고 싶을 때는 다음과 같이 두 인덱스를 동시에 조회합니다.
KQL 예시
event.action:”blocked” AND rule_signature:”ET TROJAN”
④ 대용량 트래픽 추적
특정 구간에서 평소보다 큰 페이로드를 보낸 흐름을 찾으려면 bytes 기준으로 정렬하면 됩니다.
KQL 예시
bytes > 1000000 | sort bytes desc | head 50
이런 패턴을 미리 알림( Watcher )으로 등록해 두면, REJECT 비율이 임계치를 넘는 순간 Slack으로 자동 알림이 떨어지도록 만들 수 있어요.
자주 묻는 질문
Q. VPC Flow Logs를 켜면 비용이 얼마나 나오나요?
A. 캡처 비용과 저장 비용이 따로 청구됩니다. S3 기준 캡처 1GB당 약 $0.10, OpenSearch로 보낼 경우 Firehose 처리 비용까지 합쳐 GB당 $0.15~0.20 정도가 일반적이에요. ISM 정책으로 오래된 인덱스를 cold로 보내면 장기 보관 비용을 크게 줄일 수 있거든요.
Q. OpenSearch 도메인을 별도로 띄우지 않고 다른 대안은 없나요?
A. Amazon Athena + S3 조합이 가장 가볍고, CloudWatch Logs Insights만으로 충분한 경우도 많아요. 다만 양이 많고 실시간 교차 분석이 필요하면 OpenSearch가 압도적으로 유리합니다.
Q. Network Firewall 없이도 같은 분석이 가능한가요?
A. 가능합니다. NACL이나 SecurityGroup에서 발생한 REJECT만으로도 흐름 추적은 충분히 가능해요. 다만 룰 매칭 근거까지 확인하려면 Network Firewall Alert가 가장 편리합니다.
Q. Firehose 버퍼링은 어느 정도로 잡는 게 좋나요?
A. 실시간성이 중요하면 60초/1MB, 비용 최적화가 목적이라면 900초/100MB로 조정합니다. 일반적인 운영 환경에서는 300초/5MB 정도가 균형이 좋아요.
Q. 로그에 개인정보가 남나요?
A. Flow Logs는 페이로드를 저장하지 않으므로 본문 데이터는 남지 않아요. 다만 srcaddr·dstaddr가 곧 사용자 신원이 될 수 있으니, 인덱스 접근 권한은 최소 권한 원칙으로 좁혀 두는 게 안전합니다.
VPC Flow Logs는 켜는 것보다 어디에 적재하고 어떻게 조회하느냐가 진짜 실력이에요. OpenSearch + Network Firewall 조합은 초기 셋업만 잘 해두면 장애 때마다 적어도 1시간은 단축시켜 주거든요. 오늘 정리한 쿼리 패턴과 대시보드 구성을 그대로 카피해서 써 보시고, 각자의 환경에 맞게 알림 임계치만 조정하시면 바로 운영에 투입할 수 있습니다.
본 글에 포함된 AWS 서비스 명세, 비용 추정, 쿼리 예시는 작성자 개인의 운영 경험을 바탕으로 정리한 내용이며, 실제 요금과 기능은 AWS 정책 변경에 따라 달라질 수 있습니다. 본문을 참고해 실제 도입을 결정하실 때는 반드시 AWS 공식 문서의 최신 요금과 가이드를 확인하시고, 본인 환경에 맞는 보안 검토를 거치신 후 적용하시길 권장드립니다. 본 글은 특정 서비스의 추천 또는 비추천을 목적으로 하지 않으며, 데이터 손실이나 장애에 대한 책임은 본인에게 있음을 알려드립니다.
