Amazon VPC Flow Logs · IP 트래픽 메타데이터 · 관측성

VPC를 오간 모든 흐름을 한 줄 레코드로 남기세요

VPC Flow Logs는 네트워크 인터페이스를 드나드는 IP 트래픽을 5-tuple 단위 레코드로 기록합니다. 트래픽 경로 밖에서 수집하므로 처리량과 지연에 영향이 없고, CloudWatch Logs, Amazon S3, Amazon Data Firehose로 보내 바로 분석합니다.

Default format · version 21 record = 1 flow

2 123456789012 eni-0a1b2c3d4e5f60718 203.0.113.12 10.0.1.25 51544 22 6 3 180 1760331600 1760331660 REJECT OK

  • 2version
  • 123456789012account-id
  • eni-0a1b…0718interface-id
  • 203.0.113.12srcaddr
  • 10.0.1.25dstaddr
  • 51544srcport
  • 22dstport
  • 6protocol · TCP
  • 3packets
  • 180bytes
  • 1760331600start
  • 1760331660end
  • REJECTaction
  • OKlog-status

인터넷에서 들어온 SSH 시도가 보안 그룹이나 네트워크 ACL에 막혔다는 사실이 한 줄에 담깁니다.

6

캡처 대상 (VPC · 서브넷 · ENI · TGW · TGW attachment · regional NAT)

1 / 10 min

최대 집계 간격 선택 (Nitro 인스턴스는 항상 1분 이하)

3

전송 대상 (CloudWatch Logs · S3 · Firehose)

Out-of-path

트래픽 경로 밖 수집, 성능 영향 없음

Why Flow Logs

"이 패킷은 어디서 막혔나"에 답하는 기본 로그

패킷 캡처 없이도 누가, 언제, 어느 포트로, 얼마나 통신했고 허용됐는지 거부됐는지를 알 수 있습니다. 네트워크 운영, 보안, 비용 분석이 같은 데이터를 봅니다.

Diagnose

보안 그룹 · NACL 문제 해결

REJECT 레코드로 과하게 막힌 규칙을 찾고, 같은 흐름의 ingress · egress 레코드를 비교해 상태 비저장 NACL의 반환 트래픽 누락을 가려냅니다.

Forensics

보안 조사와 이상 탐지

침해 의심 시점의 통신 상대, 포트 스캔, 예상 밖의 아웃바운드를 레코드로 재구성합니다. Amazon GuardDuty도 VPC flow log를 기본 데이터 소스로 분석합니다.

Analyze

트래픽 · 비용 분석

bytes, traffic-path, az-id 필드로 AZ 간 · 인터넷 · 피어링 트래픽 규모를 나눠 보고, 데이터 전송 비용이 어디서 생기는지 추적합니다.

Record format

기본 형식으로 시작하고, 필요한 필드는 사용자 지정 형식으로

기본 형식은 version 2 필드 14개를 고정 순서로 씁니다. 사용자 지정 형식은 원하는 필드만 원하는 순서로 고르며, 레코드의 version은 고른 필드 중 가장 높은 버전이 됩니다. 형식은 생성 후 바꿀 수 없으므로 바꾸려면 flow log를 새로 만듭니다.

--log-formatcustom · version 5
${version} ${interface-id} ${instance-id} ${srcaddr} ${dstaddr}
${pkt-srcaddr} ${pkt-dstaddr} ${flow-direction} ${traffic-path}
${tcp-flags} ${action}
사용자 지정 형식 정의 예시
NAT gateway ENI · ingresssample record
5 eni-0nat0123456789abc - 10.0.1.25 10.0.0.15 10.0.1.25 198.51.100.10 ingress - 2 ACCEPT

# dstaddr     = NAT 게이트웨이 ENI의 프라이빗 IP
# pkt-dstaddr = 패킷의 실제 목적지 (인터넷 상대)
# instance-id = '-' (요청자 관리형 ENI)
# tcp-flags 2 = SYN, traffic-path는 egress 레코드에만 채워짐
NAT 게이트웨이 네트워크 인터페이스에서 기록한 사용자 지정 형식 레코드와 필드 해석
  1. v3 pkt-srcaddr · pkt-dstaddr

    NAT 게이트웨이나 EKS 파드처럼 중간 계층을 거칠 때 ENI 주소가 아닌 패킷의 원래 출발지 · 목적지를 보여 줍니다. vpc-id, subnet-id, instance-id, tcp-flags도 v3입니다.

  2. v4 · v5 위치와 방향

    region, az-id, sublocation(v4)과 flow-direction(ingress · egress), traffic-path(IGW, 피어링, VGW, 게이트웨이 엔드포인트 등 egress 경로), pkt-src/dst-aws-service(v5)로 흐름의 맥락을 더합니다.

  3. v7 ecs-* 필드

    ecs-cluster-name, ecs-service-name, ecs-task-arn 등으로 ECS 태스크 단위 트래픽을 식별합니다. 해당 ECS API 호출 권한이 필요하고, ECS가 아닌 트래픽은 '-'로 남습니다.

  4. v8+ 거부 원인과 확장 메타데이터

    reject-reason(v8)은 VPC Block Public Access(BPA)나 VPC Encryption Controls(EC)로 거부된 흐름을 구분합니다. resource-id(v9)는 regional NAT 게이트웨이, encryption-status(v10)는 전송 중 암호화 여부, v11은 인스턴스 · ENI · ASG 태그, interface-type, next-hop-* 필드를 더합니다.

기록되지 않는 트래픽

Flow Logs는 모든 IP 트래픽을 담지 않습니다. 아래 트래픽은 레코드가 생기지 않으므로, DNS 질의 기록이 필요하면 Route 53 Resolver 쿼리 로깅을 함께 씁니다.

Amazon DNS 서버 질의169.254.169.254 (IMDS)169.254.169.123 (Time Sync)DHCPARPWindows 라이선스 활성화기본 VPC 라우터 예약 IPTraffic Mirroring 소스 트래픽엔드포인트 ENI ↔ NLB ENI생성 직후 삭제된 regional NAT

Features

주요 기능

Scope

캡처 범위 선택

VPC나 서브넷에 만들면 그 안의 모든 ENI가 대상이 되고, 나중에 생긴 ENI도 자동으로 포함됩니다. 특정 ENI 하나만 보거나 Transit Gateway와 attachment, regional NAT 게이트웨이 단위로도 만듭니다.

Traffic type

ACCEPT · REJECT · ALL

허용된 트래픽만, 거부된 트래픽만, 또는 전부를 기록합니다. 보안 그룹 문제 해결용이라면 REJECT만 모아 로그 양과 비용을 줄입니다.

Aggregation

1분 또는 10분 집계

최대 집계 간격 동안 같은 흐름을 한 레코드로 묶습니다. 기본은 10분이며 1분을 고르면 더 세밀하지만 레코드가 늘어납니다. Nitro 인스턴스 ENI는 설정과 무관하게 1분 이하입니다.

Query

Logs Insights · Athena

CloudWatch Logs에서는 Logs Insights 쿼리로 바로 집계하고, S3에서는 Amazon Athena로 SQL을 실행합니다. 콘솔에서 Athena 통합용 CloudFormation 템플릿도 생성할 수 있습니다.

Transit Gateway

TGW flow logs

Transit Gateway 전체나 attachment별로 흐름을 기록합니다. 출발지 · 목적지 VPC와 계정, 그리고 packets-lost-no-route, packets-lost-blackhole 같은 손실 카운터로 라우팅 문제를 찾습니다. Transit Gateway 소개

Organization

중앙 수집 · 조직 단위 활성화

버킷 정책이나 교차 계정 IAM 역할로 다른 계정의 S3 버킷, Firehose 스트림에 보냅니다. CloudWatch telemetry 활성화 규칙을 쓰면 조직 · 계정 · 태그 범위의 기존과 새 VPC에 CloudWatch Logs 대상 flow log가 자동으로 만들어집니다.

Destinations

전송 대상 비교

같은 리소스에 대상과 형식이 다른 flow log를 여러 개 만들 수 있습니다. 즉시 조회와 알람은 CloudWatch Logs, 장기 보관과 대량 분석은 S3, 외부 도구로 스트리밍할 때는 Firehose가 잘 맞습니다.

VPC Flow Logs 전송 대상별 비교
대상저장 형태분석 방법어떤 경우에 맞나
CloudWatch Logs 로그 그룹에 ENI별 로그 스트림. 게시 권한을 가진 IAM 역할 필요 Logs Insights 쿼리, metric filter와 알람, 구독 필터 문제 해결 중 바로 조회하거나 REJECT 급증에 알람을 걸 때
Amazon S3 text(gzip) 또는 Apache Parquet 파일. Hive 호환 S3 prefix, 시간 단위 파티션 선택 가능 Amazon Athena SQL, 콘솔이 생성하는 Athena 통합 템플릿 수개월 이상 보관, 계정 · 조직 단위 대량 분석, 비용을 낮추고 싶을 때
Amazon Data Firehose 같은 계정 또는 다른 계정의 Firehose 스트림으로 전달 Firehose가 지원하는 대상(OpenSearch Service, Splunk, HTTP 엔드포인트 등)에서 분석 SIEM이나 서드파티 관측성 도구로 거의 실시간 스트리밍할 때

Reference architecture

수집, 전달, 분석의 세 단계

Flow Logs는 ENI와 Transit Gateway에서 흐름 메타데이터를 트래픽 경로 밖에서 모아, 집계 간격마다 레코드로 묶어 대상에 전달합니다. 대상마다 분석 도구가 달라지므로 용도별로 flow log를 나눠 만드는 구성이 일반적입니다. 경로 자체가 의도대로 설정됐는지는 Reachability Analyzer로 정적으로 확인합니다.

VPC Flow Logs 수집과 전송 아키텍처 VPC 안의 EC2 인스턴스 ENI, NAT 게이트웨이 ENI, ECS 태스크 ENI와 VPC 밖의 Transit Gateway에서 흐름 정보가 VPC Flow Logs로 수집됩니다. Flow Logs는 1분 또는 10분 집계 간격으로 레코드를 만들어 CloudWatch Logs, Amazon S3, Amazon Data Firehose로 전달합니다. CloudWatch Logs는 Logs Insights와 알람으로, S3는 Athena로, Firehose는 OpenSearch나 Splunk 같은 도구로 분석합니다. VPC 10.0.0.0/16 DESTINATIONS → ANALYSIS EC2 인스턴스 ENIprivate subnet NAT Gateway ENIpkt-srcaddr · pkt-dstaddr ECS 태스크 ENIecs-* 필드 Transit GatewayTGW · attachment 단위 VPC Flow Logs out-of-path 수집 집계 1분 · 10분 ACCEPT · REJECT · ALL 흐름 메타데이터 CloudWatch LogsENI별 로그 스트림 Amazon S3text · Parquet Data Firehose스트리밍 전달 전달 Logs Insights쿼리 · 알람 Amazon AthenaSQL 분석 OpenSearchSplunk · HTTP 등
흐름 수집 (out-of-path) 레코드 전달 분석 도구로 전달

좁은 화면에서는 다이어그램을 좌우로 밀어서 보세요.

Getting started

첫 flow log를 켜는 순서

  1. STEP 1

    범위와 traffic type

    VPC · 서브넷 · ENI · TGW · regional NAT 중 대상을 고르고, ACCEPT · REJECT · ALL을 정합니다. VPC 소개

  2. STEP 2

    대상 준비

    로그 그룹과 IAM 역할, 또는 S3 버킷 정책이나 Firehose 스트림을 준비합니다.

  3. STEP 3

    형식과 집계 간격

    기본 또는 사용자 지정 형식, 1분 · 10분 간격, S3라면 Parquet와 Hive 파티션을 고릅니다.

  4. STEP 4

    flow log 생성

    콘솔이나 aws ec2 create-flow-logs로 만들고 태그를 붙입니다.

  5. STEP 5

    쿼리로 검증

    몇 분 뒤 레코드가 쌓이면 Logs Insights나 Athena로 REJECT 상위 흐름부터 확인합니다.

Pricing

비용 항목

Flow Logs 자체에는 별도 시간 요금이 없고, 생성된 로그 데이터가 CloudWatch의 vended logs 요금으로 과금됩니다. 단가는 대상별로 다르고 사용량이 늘수록 낮아지는 구간제입니다.

VPC Flow Logs 과금 항목
과금 항목과금 기준참고
CloudWatch Logs 수집vended logs 수집 GB로그 그룹 보관 기간 동안 CloudWatch Logs 저장 요금이 더해집니다
S3 전송vended logs 전달 GB버킷의 S3 저장 · 요청 요금은 별도. 수명 주기 정책으로 보관 비용을 줄입니다
Parquet 변환변환한 GBS3 대상에서 Parquet 형식을 고른 경우에만. 대신 Athena 스캔량이 줄어듭니다
Firehose 전송vended logs 전달 GBFirehose 이후 단계와 최종 대상의 요금은 해당 서비스에서 청구됩니다
조직 단위 자동 활성화AWS Config 구성 항목CloudWatch telemetry 활성화 규칙은 AWS Config 서비스 연결 레코더로 리소스를 찾으므로 Config 요금이 붙고, 수집은 vended logs 요금입니다
분석다른 서비스에서 청구Logs Insights는 스캔한 데이터 양, Athena는 쿼리가 스캔한 데이터 양 기준

로그 양은 트래픽 양보다 흐름 수와 집계 간격, 고른 필드 수에 비례합니다. REJECT만 기록하거나 필요한 필드만 고르면 비용을 줄일 수 있습니다. 대상 리소스(로그 그룹, 버킷, Firehose 스트림)에 비용 배분 태그를 붙이면 flow log 요금을 팀별로 나눠 봅니다. 최신 단가는 Amazon CloudWatch 요금 페이지의 Vended Logs 항목에서 확인하세요.

Next step

필요한 흐름만, 필요한 형식으로 기록하세요

문제 해결, 보안 조사, 비용 분석 중 무엇이 목적인지와 계정 · VPC 구조를 정리해 오시면 캡처 범위, 필드 구성, 대상과 보관 전략을 함께 검토합니다.