느려진 원인이 AWS 네트워크인지 몇 분 안에 가려내세요

How it works

agent가 모으고, scope 전체를 보고, monitor로 좁힙니다

agent는 커널의 TCP 이벤트만 받아 약 30초마다 Network Flow Monitor로 보냅니다. scope 안의 모든 흐름은 Workload insights에서 분류별로 보고, 계속 지켜볼 흐름은 local · remote 리소스를 지정해 monitor로 만듭니다.

# web 서브넷(local) → DynamoDB · 다른 AZ(remote) 흐름을 추적
aws networkflowmonitor create-monitor \
  --monitor-name web-to-backend \
  --scope-arn arn:aws:networkflowmonitor:ap-northeast-2:111122223333:scope/e21c…d8cf \
  --local-resources  type="AWS::EC2::Subnet",identifier="arn:aws:ec2:…:subnet/subnet-0web…" \
  --remote-resources type="AWS::AWSService",identifier="DynamoDB" \
                     type="AWS::AvailabilityZone",identifier="ap-northeast-2c"

# 생성 후 AWS/NetworkFlowMonitor 네임스페이스에 지표 게시
# DataTransferred · Retransmissions · Timeouts
# RoundTripTime(µs) · HealthIndicator(0 healthy / 100 degraded)

Workload insights 분류: INTRA_AZ · INTER_AZ · INTER_VPC · INTER_REGION · AMAZON_S3 · AMAZON_DYNAMODB · UNCLASSIFIED(NAT 게이트웨이를 거치거나 AWS 밖으로 나가는 흐름 등). RTT는 항상 계산되지 않아 데이터가 듬성할 수 있습니다.

Features

주요 기능

기본 할당량: scope는 계정 · Region당 1개, monitor는 계정 · Region당 20개(조정 가능), monitor당 local · remote 리소스 각 25개. 서비스 전체로 분당 약 500만 흐름, agent 설치 인스턴스 약 5,000대 규모까지 지원하며 그 이상은 용량이 늘 때까지 모니터링 성능에 영향이 있을 수 있습니다. agent는 Linux(Amazon Linux 2023, RPM · DEB 계열, x86_64 · Graviton)용입니다.

Compare

CloudWatch Network Monitoring 세 기능과 VPC Flow Logs

Network Flow Monitor는 AWS 안의 워크로드 간 실제 TCP 흐름, Internet Monitor는 인터넷 최종 사용자 구간, Network Synthetic Monitor는 VPC와 온프레미스 사이 하이브리드 경로를 봅니다. VPC Flow Logs는 성능이 아니라 흐름 기록입니다.

Reference architecture

워크로드 옆의 agent, CloudWatch로 이어지는 지표

EC2 인스턴스와 EKS 노드의 agent가 AZ 간 흐름과 S3 · DynamoDB로 가는 흐름을 관측해 Network Flow Monitor로 보냅니다. delegated administrator 계정이 scope를 관리하고, monitor 지표는 CloudWatch 알람과 대시보드로 이어집니다. 경로 구성 자체의 검증은 Reachability Analyzer, 흐름 기록은 VPC Flow Logs가 맡습니다.

Getting started

시작하기

1. STEP 1

   계정 범위 결정

   여러 계정을 볼 거라면 Organizations에서 CloudWatch용 delegated administrator를 등록하고 그 계정으로 진행합니다.

2. STEP 2

   초기화

   CloudWatch 콘솔 Network Monitoring의 Flow monitors에서 초기화합니다. 서비스 연결 역할, scope, 초기 토폴로지가 만들어지며 최대 30분 걸립니다.

3. STEP 3

   agent 배포

   인스턴스 역할에 CloudWatchNetworkFlowMonitorAgentPublishPolicy를 붙이고 SSM · CloudShell · 패키지로 설치합니다. EKS는 add-on을 켭니다.

4. STEP 4

   Workload insights 검토

   AZ 간 · VPC 간 · S3 등 분류별 상위 흐름을 보고 지속 추적할 워크로드를 고릅니다.

5. STEP 5

   monitor와 알람

   local · remote 리소스로 monitor를 만들고 HealthIndicator와 재전송 지표에 CloudWatch 알람을 겁니다.

scope에 계정을 더하거나 뺀 뒤에는 토폴로지를 다시 만드는 동안 약 20분이 지나야 다음 변경을 할 수 있습니다. 관리 계정으로도 계정을 추가할 수 있지만 delegated administrator 사용이 권장됩니다.

Pricing

비용 항목

flow monitoring 요금은 두 가지로 정해집니다. agent를 배포 · 활성화한 컴퓨팅 리소스 수(monitored resource)와, 게시되는 CloudWatch 지표입니다. 단가는 Region마다 다릅니다.

agent를 설치하는 인스턴스 수가 곧 비용이므로, 모든 인스턴스보다 핵심 계층(웹 · 앱 · DB 노드)부터 배포하는 것이 좋습니다. 최신 단가와 계산 예시는 Amazon CloudWatch 요금 페이지의 CloudWatch Network Monitoring with flow monitoring 항목에서 확인하세요.