[network] VPC Flow Logs

One-Line Summary

VPC Flow Logs는 VPC 안 네트워크 인터페이스(ENI)를 드나드는 IP 트래픽의 "메타데이터"를 기록하는 기능이다. 출발지/목적지 IP·포트, 프로토콜, 바이트 수, 그리고 ACCEPT/REJECT 같은 요약 정보를 남기지 만, 패킷의 실제 내용(payload)은 절대 담지 않는다. 연결이 왜 막혔는지(트러블슈팅), 이상 트래픽 탐지(보안), 감사(audit)에 쓴다. VPC · Subnet · ENI 3단계 어디서든 켤 수 있고, 로그는 CloudWatch Logs · S3 · Data Firehose로 보낸다.

Why It Exists

"A 서버에서 B DB로 접속이 안 된다." 원인이 Security Group인지, NACL인지, 라우트 테이블인지, 애초에 트래픽이 도달은 했는지 눈으로 볼 방법이 없으면 추측만 하게 된다. 또 "누가 우리 인스턴스에 계속 접속을 시도하는가" 같은 보안 관찰도 트래픽 기록이 없으면 불가능하다.

VPC Flow Logs가 이 "네트워크 트래픽 기록장" 역할을 한다.

[Flow Logs 없음]
A → B 접속 실패
  -> SG? NACL? 라우트? 트래픽 도달은 했나?  전부 추측 (블랙박스)

[Flow Logs 있음]
A → B 트래픽이 REJECT 로 기록됨
  -> "트래픽은 도달했고 SG/NACL 중 하나가 막았다" 로 범위 좁힘
  -> 아예 기록이 없으면 -> 라우팅/도달 자체 문제로 방향 전환

시험 감각:

"VPC 안 트래픽을 기록/감시/디버깅하고 싶다" = VPC Flow Logs. 단, 패킷 내용까지 필요하면 Flow Logs가 아니라 Traffic Mirroring.

Abbreviations

약어	풀네임	의미
`Flow Logs`	VPC Flow Logs	ENI를 드나드는 IP 트래픽 메타데이터 기록
`ENI`	Elastic Network Interface	인스턴스에 붙는 가상 NIC (Flow Logs의 최소 단위)
`CW Logs`	CloudWatch Logs	로그 목적지 중 하나(실시간에 가까운 조회·경보)
`S3`	Simple Storage Service	로그 목적지 중 하나(대량 장기 보관, Athena 분석)
`Firehose`	Amazon Data Firehose	로그 목적지 중 하나(외부/분석 파이프라인 전달)
`Athena`	Amazon Athena	S3에 쌓인 로그를 SQL로 조회
`Logs Insights`	CloudWatch Logs Insights	CW Logs에 쌓인 로그를 쿼리

무엇을 기록하는가 — 메타데이터일 뿐, payload가 아니다 (빈출)

Flow Logs는 트래픽의 헤더/요약 정보(메타데이터) 만 남긴다. 실제 주고받은 데이터(HTTP 본문, 쿼리 내용 등)는 담기지 않는다.

담긴다 (메타데이터)	담기지 않는다
출발지/목적지 IP (srcaddr/dstaddr)	패킷 페이로드(실제 전송 내용)
출발지/목적지 포트 (srcport/dstport)	HTTP 본문·SQL 쿼리·파일 내용
프로토콜, 패킷 수, 바이트 수	애플리케이션 레벨 데이터
허용/거부 결과 (action: ACCEPT/REJECT)	—

패킷 내용까지 봐야 하는 심층 분석(침입 탐지의 payload 검사 등)은 Flow Logs로 못 한다. 그때는 Traffic Mirroring(패킷 복제)을 쓴다. 이 구분이 시험 단골이다. (빈출)

어디에 켜는가 — VPC / Subnet / ENI 3단계 (빈출)

Flow Logs는 3가지 범위 중 하나로 생성한다. 상위에 켜면 하위가 모두 포함된다.

[VPC]      ← VPC 전체의 모든 ENI 트래픽 (가장 넓음)
  └ [Subnet]   ← 해당 서브넷 안 모든 ENI 트래픽
       └ [ENI] ← 특정 인터페이스 하나만 (가장 좁음, 정밀 디버깅)

범위	대상	언제
VPC	VPC 내 모든 ENI	전체 감사·보안 관찰, 광범위 로깅
Subnet	해당 서브넷의 모든 ENI	특정 계층(예: DB 서브넷)만 관찰
ENI	특정 인터페이스 1개	특정 인스턴스 연결 문제 정밀 디버깅

"어느 서브넷/인스턴스가 문제인지 특정됐다" = ENI 또는 Subnet 레벨로 좁혀 켠다. "전체 트래픽 감사가 필요하다" = VPC 레벨.

어디로 보내는가 — 목적지 3종 (빈출)

목적지	특징	분석 도구
CloudWatch Logs	실시간에 가깝게 조회·경보(알람) 걸기 좋음	CloudWatch Logs Insights
Amazon S3	대량·장기 보관, 비용 저렴	Amazon Athena(SQL 조회)
Amazon Data Firehose	스트리밍으로 외부/분석 시스템 전달	다운스트림(예: OpenSearch, 서드파티)

[ENI/Subnet/VPC 트래픽]
        │
        ▼  (Flow Logs 캡처)
   ┌────┴────────────────────┐
   ▼            ▼            ▼
CloudWatch    Amazon      Amazon Data
  Logs          S3         Firehose
   │            │            │
Logs Insights  Athena     외부 분석 파이프라인
(경보·조회)    (SQL 대량)   (스트리밍)

"대량 로그를 저비용 장기 보관 후 SQL 분석" = S3 + Athena. "실시간 경보·빠른 조회" = CloudWatch Logs (+ Logs Insights). "실시간 스트리밍으로 외부 전달" = Data Firehose.

로그 레코드 필드 & 샘플 — ACCEPT/REJECT가 핵심

기본(default) 형식의 대표 필드는 다음과 같다.

필드	의미
`srcaddr` / `dstaddr`	출발지 / 목적지 IP
`srcport` / `dstport`	출발지 / 목적지 포트
`protocol`	프로토콜 번호(6=TCP, 17=UDP, 1=ICMP)
`packets` / `bytes`	전송된 패킷 수 / 바이트 수
`action`	ACCEPT(허용됨) / REJECT(거부됨) — 디버깅 핵심
`log-status`	`OK`(정상), `NODATA`(트래픽 없음), `SKIPDATA`(일부 누락)

샘플 레코드 (default 형식)
version account-id  interface-id       srcaddr    dstaddr    srcport dstport protocol packets bytes ... action log-status
2       123456789   eni-0abc123def456  10.0.1.10  10.0.2.20  49152   3306    6        20      4249  ... ACCEPT OK      ← DB(3306) 접속 허용됨
2       123456789   eni-0abc123def456  203.0.113.5 10.0.1.10 51000   22      6        3       120   ... REJECT OK      ← SSH(22) 외부 시도 거부됨

action이 REJECT면 트래픽은 ENI까지 "도달"했지만 SG/NACL이 막은 것이다. ACCEPT면 방화벽은 통과했다는 뜻(그래도 앱 레벨에서 실패할 수 있음). log-status가 NODATA면 아예 트래픽이 없었다는 신호다.

연결 문제 디버깅에 어떻게 쓰나 (실무·빈출)

"접속 안 됨"의 원인을 Flow Logs로 좁힐 수 있다. 이는 Security Group vs NACL의 다층 방어, Route Table의 라우팅과 함께 보는 4단계 점검과 맞물린다.

[디버깅 흐름]
Flow Logs에 그 트래픽 기록이 있나?
  ├─ 없음(NODATA)  → 라우팅/도달 문제. Route Table·IGW/NAT 확인
  └─ 있음
       ├─ REJECT   → SG 또는 NACL이 막음. 규칙 확인
       └─ ACCEPT   → 방화벽은 통과. 앱/OS 방화벽/포트 리슨 여부 확인

Flow Logs 관찰	해석	다음 점검
레코드 자체가 없음	트래픽이 ENI에 도달조차 못함	Route Table, IGW/NAT, 경로
`REJECT`	SG/NACL 중 하나가 거부	SG/NACL 규칙
`ACCEPT`인데 실패	네트워크는 통과, 상위 계층 문제	앱 설정, OS 방화벽, 서비스 포트

Flow Logs는 SG/NACL 중 어느 쪽이 막았는지까지는 직접 알려주지 않는다(둘 다 통과해야 ACCEPT). 다만 REJECT 자체가 "방화벽 계층에서 막혔다"는 강한 단서다. NACL은 stateless라 응답용 ephemeral 포트 REJECT가 종종 잡힌다. (빈출)

무엇이 기록되지 않는가 — 한계·함정 (빈출)

Flow Logs가 특정 트래픽은 아예 캡처하지 않는다. 이걸 모르면 "로그에 없으니 통신이 안 됐다"고 오판한다.

캡처되지 않는 트래픽	이유
Amazon DNS 서버로 가는 트래픽	AWS 제공 DNS(Route 53 Resolver)는 제외
DHCP 트래픽	인프라 관리 트래픽
인스턴스 메타데이터 `169.254.169.254`	링크로컬 서비스
Amazon 타임 싱크(169.254.169.123)	링크로컬 서비스
Windows 라이선스 활성화 트래픽	KMS 활성화용 트래픽
기본 VPC 라우터로의 트래픽(예약 IP), 미러 세션 트래픽 등	인프라 예약

추가 한계:

항목	내용
실시간 아님	캡처~기록 사이 약간의 지연(수집 윈도우, 보통 분 단위)이 있다
소급 불가	켠 이후 트래픽만 기록. 과거 트래픽은 못 본다(먼저 켜둬야 함)
메타데이터만	payload 없음(→ [무엇을 기록하는가] 참고)
자동 생성 아님	명시적으로 활성화해야 함(기본 꺼짐)

함정 포인트: "이미 지나간 사고 트래픽을 분석하라" → Flow Logs가 꺼져 있었다면 소급 불가. "왜 로그에 DNS/메타데이터 조회가 안 보이나" → 원래 제외 대상이라 정상.

보안 관찰(security monitoring)에 쓰기

Flow Logs는 비정상/의심 트래픽 탐지의 원천 데이터다.

반복되는 REJECT(포트 스캔·무차별 접속 시도) 패턴 탐지
예상 밖 목적지로 나가는 아웃바운드(데이터 유출·C2 의심)
특정 IP의 비정상 트래픽량

소비 서비스	역할
Amazon GuardDuty	VPC Flow Logs 등을 자동 분석해 위협 탐지(별도 파싱 불필요)
CloudWatch Logs Insights / Athena	직접 쿼리로 이상 패턴 조사

"VPC 트래픽에서 위협을 자동 탐지" = GuardDuty(Flow Logs·DNS 로그·CloudTrail을 소스로 사용). "직접 쿼리해 조사" = Logs Insights(CW) 또는 Athena(S3).

직접 조사할 때 — 어떤 도구로

로그를 어디로 보냈느냐에 따라 쿼리 도구가 갈린다: CloudWatch Logs → Logs Insights, S3 → Athena. 가장 흔한 조사 패턴은 누가 계속 거부(REJECT)당하나(포트 스캔·무차별 접속) — Logs Insights 예:

fields srcAddr, dstPort
| filter action = "REJECT"
| stats count(*) as rejects by srcAddr
| sort rejects desc | limit 20

감각: 급한 실시간 조사는 Logs Insights, 장기·대량 로그의 저비용 분석은 S3+Athena. 반복 REJECT 소스, 예상 밖 목적지로의 대량 아웃바운드가 조사 1순위 신호다.

Common Wrong Directions

오답 방향	왜 부족한가
Flow Logs로 패킷 내용(payload) 을 본다	메타데이터만 기록. payload는 Traffic Mirroring
Flow Logs를 켜면 과거 트래픽도 볼 수 있다	소급 불가. 켠 이후만 기록
Flow Logs를 실시간 초단위 스트림으로 기대	약간의 지연 존재(실시간 아님)
DNS/메타데이터 조회가 로그에 없어 통신 실패로 판단	애초에 캡처 제외 대상
Flow Logs가 SG/NACL 중 어느 쪽이 막았는지 알려준다고 가정	REJECT까지만. 둘 다 통과해야 ACCEPT
위협 탐지를 Flow Logs 원본을 직접 다 보며 하려 함	자동 탐지는 GuardDuty가 담당
VPC 전체에만 켤 수 있다고 생각	VPC/Subnet/ENI 3단계 가능

Exam Triggers

문제에서 이런 표현이 나오면	떠올릴 것
"capture IP traffic info to/from network interfaces"	`VPC Flow Logs`
"troubleshoot why connection is blocked (ACCEPT/REJECT)"	`VPC Flow Logs`
"need packet contents / payload inspection"	`Traffic Mirroring` (Flow Logs 아님)
"store flow logs cheaply and query with SQL"	S3 + Athena
"near real-time alerting / query flow logs"	CloudWatch Logs (+ Logs Insights)
"stream flow logs to external/analytics system"	Amazon Data Firehose
"detect threats/anomalies from VPC traffic automatically"	`GuardDuty` (Flow Logs 소스)
"enable logging for a single interface / one subnet"	ENI / Subnet 레벨 Flow Logs
"why is DNS/metadata traffic missing from logs"	캡처 제외 대상(정상)
"analyze traffic that already happened but logs were off"	소급 불가 → 사전 활성화 필요

Memory Sentence

VPC Flow Logs는 ENI를 드나드는 IP 트래픽의 메타데이터(src/dst IP·포트·프로토콜·바이트·ACCEPT/REJECT)를 기록하되 payload는 안 담는다(payload는 Traffic Mirroring). VPC·Subnet·ENI 3단계로 켜고, CloudWatch Logs·S3·Firehose로 보내 Logs Insights/Athena로 분석한다. REJECT면 SG/NACL이 막은 것, 기록이 없으면 라우팅 문제. DNS·메타데이터(169.254.169.254)는 캡처 제외, 실시간 아니고 과거 소급도 안 되니 미리 켜둬야 하며, 위협 자동 탐지는 GuardDuty가 소스로 쓴다.