Scope
캡처 범위 선택
VPC나 서브넷에 만들면 그 안의 모든 ENI가 대상이 되고, 나중에 생긴 ENI도 자동으로 포함됩니다. 특정 ENI 하나만 보거나 Transit Gateway와 attachment, regional NAT 게이트웨이 단위로도 만듭니다.
Amazon VPC Flow Logs · IP 트래픽 메타데이터 · 관측성
VPC Flow Logs는 네트워크 인터페이스를 드나드는 IP 트래픽을 5-tuple 단위 레코드로 기록합니다. 트래픽 경로 밖에서 수집하므로 처리량과 지연에 영향이 없고, CloudWatch Logs, Amazon S3, Amazon Data Firehose로 보내 바로 분석합니다.
2 123456789012 eni-0a1b2c3d4e5f60718 203.0.113.12 10.0.1.25 51544 22 6 3 180 1760331600 1760331660 REJECT OK
인터넷에서 들어온 SSH 시도가 보안 그룹이나 네트워크 ACL에 막혔다는 사실이 한 줄에 담깁니다.
캡처 대상 (VPC · 서브넷 · ENI · TGW · TGW attachment · regional NAT)
최대 집계 간격 선택 (Nitro 인스턴스는 항상 1분 이하)
전송 대상 (CloudWatch Logs · S3 · Firehose)
트래픽 경로 밖 수집, 성능 영향 없음
Why Flow Logs
패킷 캡처 없이도 누가, 언제, 어느 포트로, 얼마나 통신했고 허용됐는지 거부됐는지를 알 수 있습니다. 네트워크 운영, 보안, 비용 분석이 같은 데이터를 봅니다.
REJECT 레코드로 과하게 막힌 규칙을 찾고, 같은 흐름의 ingress · egress 레코드를 비교해 상태 비저장 NACL의 반환 트래픽 누락을 가려냅니다.
침해 의심 시점의 통신 상대, 포트 스캔, 예상 밖의 아웃바운드를 레코드로 재구성합니다. Amazon GuardDuty도 VPC flow log를 기본 데이터 소스로 분석합니다.
bytes, traffic-path, az-id 필드로 AZ 간 · 인터넷 · 피어링 트래픽 규모를 나눠 보고, 데이터 전송 비용이 어디서 생기는지 추적합니다.
Record format
기본 형식은 version 2 필드 14개를 고정 순서로 씁니다. 사용자 지정 형식은 원하는 필드만 원하는 순서로 고르며, 레코드의 version은 고른 필드 중 가장 높은 버전이 됩니다. 형식은 생성 후 바꿀 수 없으므로 바꾸려면 flow log를 새로 만듭니다.
${version} ${interface-id} ${instance-id} ${srcaddr} ${dstaddr}
${pkt-srcaddr} ${pkt-dstaddr} ${flow-direction} ${traffic-path}
${tcp-flags} ${action}
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 레코드에만 채워짐
v3 pkt-srcaddr · pkt-dstaddrNAT 게이트웨이나 EKS 파드처럼 중간 계층을 거칠 때 ENI 주소가 아닌 패킷의 원래 출발지 · 목적지를 보여 줍니다. vpc-id, subnet-id, instance-id, tcp-flags도 v3입니다.
v4 · v5 위치와 방향region, az-id, sublocation(v4)과 flow-direction(ingress · egress), traffic-path(IGW, 피어링, VGW, 게이트웨이 엔드포인트 등 egress 경로), pkt-src/dst-aws-service(v5)로 흐름의 맥락을 더합니다.
v7 ecs-* 필드ecs-cluster-name, ecs-service-name, ecs-task-arn 등으로 ECS 태스크 단위 트래픽을 식별합니다. 해당 ECS API 호출 권한이 필요하고, ECS가 아닌 트래픽은 '-'로 남습니다.
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
허용된 트래픽만, 거부된 트래픽만, 또는 전부를 기록합니다. 보안 그룹 문제 해결용이라면 REJECT만 모아 로그 양과 비용을 줄입니다.
Aggregation
최대 집계 간격 동안 같은 흐름을 한 레코드로 묶습니다. 기본은 10분이며 1분을 고르면 더 세밀하지만 레코드가 늘어납니다. Nitro 인스턴스 ENI는 설정과 무관하게 1분 이하입니다.
Query
CloudWatch Logs에서는 Logs Insights 쿼리로 바로 집계하고, S3에서는 Amazon Athena로 SQL을 실행합니다. 콘솔에서 Athena 통합용 CloudFormation 템플릿도 생성할 수 있습니다.
Transit Gateway
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가 잘 맞습니다.
| 대상 | 저장 형태 | 분석 방법 | 어떤 경우에 맞나 |
|---|---|---|---|
| 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로 정적으로 확인합니다.
좁은 화면에서는 다이어그램을 좌우로 밀어서 보세요.
Getting started
VPC · 서브넷 · ENI · TGW · regional NAT 중 대상을 고르고, ACCEPT · REJECT · ALL을 정합니다. VPC 소개
로그 그룹과 IAM 역할, 또는 S3 버킷 정책이나 Firehose 스트림을 준비합니다.
기본 또는 사용자 지정 형식, 1분 · 10분 간격, S3라면 Parquet와 Hive 파티션을 고릅니다.
콘솔이나 aws ec2 create-flow-logs로 만들고 태그를 붙입니다.
몇 분 뒤 레코드가 쌓이면 Logs Insights나 Athena로 REJECT 상위 흐름부터 확인합니다.
Pricing
Flow Logs 자체에는 별도 시간 요금이 없고, 생성된 로그 데이터가 CloudWatch의 vended logs 요금으로 과금됩니다. 단가는 대상별로 다르고 사용량이 늘수록 낮아지는 구간제입니다.
| 과금 항목 | 과금 기준 | 참고 |
|---|---|---|
| CloudWatch Logs 수집 | vended logs 수집 GB | 로그 그룹 보관 기간 동안 CloudWatch Logs 저장 요금이 더해집니다 |
| S3 전송 | vended logs 전달 GB | 버킷의 S3 저장 · 요청 요금은 별도. 수명 주기 정책으로 보관 비용을 줄입니다 |
| Parquet 변환 | 변환한 GB | S3 대상에서 Parquet 형식을 고른 경우에만. 대신 Athena 스캔량이 줄어듭니다 |
| Firehose 전송 | vended logs 전달 GB | Firehose 이후 단계와 최종 대상의 요금은 해당 서비스에서 청구됩니다 |
| 조직 단위 자동 활성화 | AWS Config 구성 항목 | CloudWatch telemetry 활성화 규칙은 AWS Config 서비스 연결 레코더로 리소스를 찾으므로 Config 요금이 붙고, 수집은 vended logs 요금입니다 |
| 분석 | 다른 서비스에서 청구 | Logs Insights는 스캔한 데이터 양, Athena는 쿼리가 스캔한 데이터 양 기준 |
로그 양은 트래픽 양보다 흐름 수와 집계 간격, 고른 필드 수에 비례합니다. REJECT만 기록하거나 필요한 필드만 고르면 비용을 줄일 수 있습니다. 대상 리소스(로그 그룹, 버킷, Firehose 스트림)에 비용 배분 태그를 붙이면 flow log 요금을 팀별로 나눠 봅니다. 최신 단가는 Amazon CloudWatch 요금 페이지의 Vended Logs 항목에서 확인하세요.
Next step
문제 해결, 보안 조사, 비용 분석 중 무엇이 목적인지와 계정 · VPC 구조를 정리해 오시면 캡처 범위, 필드 구성, 대상과 보관 전략을 함께 검토합니다.