Aws vpc flowlogs 어떤 데이터

간헐적으로 발생하는 네트워크 이슈만큼 원인을 추적하기 어려운 이슈는 아마 없을 겁니다. 모든 요청에 대해서 에러가 발생하는 것도 아니고 가끔씩 에러가 발생하면서 수집하는 메트릭에는 특별한 흔적도 남기지 않는 그런 이슈들. 요즘에는 eBPF 기반의 도구를 이용해 네트워크 문제를 분석하는 경우도 많지만 어떤 경우에는 tcpdump와 같은 전통적인 도구가 필요한 경우가 있습니다.

간헐적인 네트워크 이슈들은 전반적인 패킷의 흐름을 수집하고 분석하면서 어느 구간에서 언제 문제가 생기는지를 분석해야 할 필요가 있기 때문입니다. 하지만 클라우드 환경에서는 tcpdump와 같은 도구를 이용해 패킷을 수집하기 쉽지 않습니다. 그래서 이번 글에서는 AWS에서 제공하는 VPC Flow logs를 네트워크 문제 분석에 어떻게 활용할 수 있을지에 대해서 살펴보겠습니다.

VPC Flow logs

VPC Flow logs는 VPC 내의 네트워크 트래픽을 수집하고 분석할 수 있는 로그를 제공해 주는 기능입니다. 전통적인 방식이라면 서버나 네트워크 장비에서 tcpdump와 같은 도구를 이용해 직접 패킷을 수집하겠지만 클라우드 환경에서는 아무래도 고객이 직접 접근 가능한 장비의 종류에 한계가 있기 때문에 tcpdump와 같은 도구를 이용해 패킷을 수집할 수 있는 범위가 한정적입니다. VPC Flow logs는 이런 환경에서 조금이라도 더 네트워크에 대한 관측 가능성을 높여 주기 위한 기능입니다. VPC Flow logs는 VPC 콘솔에서 볼 수 있습니다.

Aws vpc flowlogs 어떤 데이터
VPC 콘솔에서 볼 수 있는 Flow logs

아무래도 Flow logs 기능을 가장 찾기 쉬운 곳이 VPC 메뉴이다 보니 VPC의 모든 트래픽을 수집하는 기능이라고 오해할 수 있는데요, 그렇지 않습니다. Flow logs는 VPC의 모든 트래픽을 수집할 수도 있지만 특정 서브넷의 트래픽만 수집할 수 있고, 특정 ENI의 트래픽만 수집할 수도 있습니다.

Aws vpc flowlogs 어떤 데이터
Subnets 메뉴에서 볼 수 있는 Flow logs

그중에서도 특히 특정 ENI의 트래픽을 수집하는 기능이 아마 실무에서는 가장 많이 사용될 수 있는 기능 일 겁니다. 대부분의 네트워크 문제는 특정 서브넷과 같이 광범위하게 일어나기보다는 특정 인스턴스와 같이 작은 범위에서 발생하기 때문입니다. ENI의 Flow logs는 VPC 관리 콘솔이 아닌 EC2 관리 콘솔에서 볼 수 있기 때문에 찾기 힘들어서 있는지조차 모르는 경우도 많습니다. 저 역시 이번에 네트워크 이슈를 겪는 와중에 발견한 기능이었습니다. 그리고 이 기능으로 굉장히 많은 도움을 받았습니다.

Aws vpc flowlogs 어떤 데이터
EC2 관리 콘솔의 Network Interfaces 메뉴에서 볼 수 있는 Flow logs

Flow logs를 의미 있게 수집하기

Flow logs를 수집해야겠다고 생각하고 수집을 해보면 수집된 데이터가 실제로는 별다른 도움이 되지 못하다는 것을 알게 됩니다. Flow logs를 기본 포맷 그대로 사용하게 되면 아래와 같이 종단 간 무언가를 주고받았다는 내용만 있지 이걸 가지고는 네트워크 문제를 해결하는 데 도움이 되는 정보가 부족하기 때문입니다.

Aws vpc flowlogs 어떤 데이터
기본 포맷으로 수집한 Flow logs

먼저 Flow logs가 어떤 데이터를 수집하는지 알아보기 위해 기본 포맷을 먼저 살펴보겠습니다. Flow logs가 사용하는 기본 포맷은 아래와 같습니다.

${version} ${account-id} ${interface-id} ${srcaddr} ${dstaddr} ${srcport}
${dstport} ${protocol} ${packets} ${bytes} ${start} ${end} ${action}
${log-status}

하지만 특정 ENI에서 수집한다면 ${account-id}와 ${interface-id} 같은 정보는 필요하지 않습니다. 그리고 기본 포맷에는 아주 중요한 필드가 하나 빠져 있습니다. 바로 ${tcp-flags} 필드입니다. 이 필드는 커스텀 포맷을 사용해서 직접 추가를 해줘야 합니다. 그래서 tcpdump의 데이터와 유사한 수준으로 의미 있게 사용할 수 있는 포맷은 아래와 같습니다.

${pkt-srcaddr} ${srcaddr} ${srcport} ${pkt-dstaddr} ${dstaddr} ${dstport}
${tcp-flags} ${action}

패킷의 출발지 주소와 포트, 목적지 주소와 포트, 그리고 ${tcp-flags}로 표현되는 패킷의 플래그. 이 정도 데이터들이 분석을 하기 위해 필요한 정보들입니다. 그리고 이렇게 커스텀 포맷을 사용하면 수집되는 데이터가 아래와 같이 변합니다.

Aws vpc flowlogs 어떤 데이터
${tcp-flags}를 수집하는 Flow logs의 데이터

어디에서 출발한 패킷인지, 그리고 이 패킷이 SYN 패킷인지, ACK 패킷인지, 패킷의 플래그를 통해 알 수 있습니다. 이 정도의 데이터는 있어야 종단 간 3 way handshake는 맺었는지, 어떤 패킷들을 주고받았는지, RST 패킷은 없었는지 등등 네트워크 문제를 분석하기 위해 필요한 정보들을 얻을 수 있습니다.

${tcp-flags} 해석하기

Flow logs에서 수집하는 ${tcp-flags}는 패킷의 플래그 값을 10진수로 표현한 숫자입니다. 그리고 TCP 패킷의 플래그는 아래 그림과 같습니다.

Aws vpc flowlogs 어떤 데이터
TCP 패킷 플래그

TCP 플래그를 표현하기 위한 비트에는 총 6개의 비트가 있습니다. 그리고 각각이 1이 되었을 때의 10진수 값을 ${tcp-flags} 필드에 넣어서 출력합니다. 이렇게 설명하면 이해하기가 어려우니 SYN 패킷이 있다고 가정해 보겠습니다. 그럼 다섯 번째 비트가 1이 되어야 하기 때문에 플래그 값이 000010 이 됩니다. 그리고 이 값은 10진수로 2가 됩니다. 같은 방식으로 FIN 패킷은 1, ACK 패킷은 16, SYN + ACK 패킷은 18이 됩니다.

Aws vpc flowlogs 어떤 데이터
TCP 플래그 값을 10진수로 변환

아래와 같은 Flow log는 10.255.78.140에서 10.200.235.55로 SYN+ACK 패킷을 보냈다는 것을 의미합니다.

Aws vpc flowlogs 어떤 데이터
SYN+ACK 패킷에 대한 로그

이렇게 Flow logs에 패킷의 플래그가 포함되기 시작하면 네트워크 문제를 분석하기 위한 도구로 사용될 수 있습니다.

Flow logs의 단점

하지만 Flow logs에도 단점이 있습니다. 바로 패킷의 순서가 보장되지 않는다는 건데요, 아무래도 수집되는 데이터가 초 단위로 밖에 볼 수 없다 보니 Flow logs를 볼 때 SYN 패킷 보다 SYN + ACK 패킷이 먼저 보이는 경우도 있습니다.

Aws vpc flowlogs 어떤 데이터
순서가 바뀐 Flow logs

위 데이터는 누가 봐도 10.200.235.55가 먼저 보낸 SYN에 대해 10.255.78.140이 SYN+ACK로 응답을 한 흐름이지만, Flow logs 상으로는 SYN+ACK가 먼저 보이게 됩니다. 하지만 SYN+ACK 가 먼저 보내질 일은 없으니 전체 Flow logs를 보고 흐름을 파악하면 됩니다.

그리고 비용이 꽤 많이 발생한다는 큰 단점이 있습니다. 저도 정확하게 측정은 해보지 않았지만 트래픽이 많을 경우 수집하는 Flow logs의 크기가 순식간에 GB를 넘겨 버릴 수도 있기 때문에 비용이 많이 발생할 수 있다고 합니다.

마치며

만약 AWS 환경에서 네트워크 이슈가 발생했고 tcpdump를 이용해 패킷 덤프를 생성하기 어려운 상황이라면 VPC Flow logs를 활용해 보는 것은 좋은 선택입니다. Flow logs를 이용하면 운영 중인 워크로드에 부담을 주지 않으면서도 패킷의 플래그 수준까지 데이터를 수집할 수 있기 때문입니다. 하지만 제법 많은 비용이 발생할 수 있기 때문에 가급적 짧은 시간 동안만, 그리고 문제가 발생하는 구간만을 대상으로 필요한 로그만 수집하는 게 좋습니다. 마지막으로 이 글이 클라우드 환경에서 네트워크 이슈로 어려움을 겪고 계신 분들에게 도움이 되었으면 좋겠습니다.

Aws vpc flowlogs 어떤 데이터

Flow Logs for Amazon Virtual Private Cloud (Amazon VPC) enables you to capture information about the IP traffic going to and from network interfaces in your VPC. Flow Logs data can be published to Amazon CloudWatch Logs or Amazon Simple Storage Service (Amazon S3).

Since we launched VPC Flow Logs in 2015, you have been using it for variety of use-cases like troubleshooting connectivity issues across your VPCs, intrusion detection, anomaly detection, or archival for compliance purposes. Until today, VPC Flow Logs provided information that included source IP, source port, destination IP, destination port, action (accept, reject) and status. Once enabled, a VPC Flow Log entry looks like the one below.

Aws vpc flowlogs 어떤 데이터

While this information was sufficient to understand most flows, it required additional computation and lookup to match IP addresses to instance IDs or to guess the directionality of the flow to come to meaningful conclusions.

Today we are announcing the availability of additional meta data to include in your Flow Logs records to better understand network flows. The enriched Flow Logs will allow you to simplify your scripts or remove the need for postprocessing altogether, by reducing the number of computations or lookups required to extract meaningful information from the log data.

When you create a new VPC Flow Log, in addition to existing fields, you can now choose to add the following meta-data:

  • vpc-id : the ID of the VPC containing the source Elastic Network Interface (ENI).
  • subnet-id : the ID of the subnet containing the source ENI.
  • instance-id : the Amazon Elastic Compute Cloud (Amazon EC2) instance ID of the instance associated with the source interface. When the ENI is placed by AWS services (for example, AWS PrivateLink, NAT Gateway, Network Load Balancer etc) this field will be “-
  • tcp-flags : the bitmask for TCP Flags observed within the aggregation period. For example, FIN is 0x01 (1), SYN is 0x02 (2), ACK is 0x10 (16), SYN + ACK is 0x12 (18), etc. (the bits are specified in “Control Bits” section of RFC793 “Transmission Control Protocol Specification”).
    This allows to understand who initiated or terminated the connection. TCP uses a three way handshake to establish a connection. The connecting machine sends a SYN packet to the destination, the destination replies with a SYN + ACK and, finally, the connecting machine sends an ACK. In the Flow Logs, the handshake is shown as two lines, with tcp-flags values of 2 (SYN), 18 (SYN + ACK).  ACK is reported only when it is accompanied with SYN (otherwise it would be too much noise for you to filter out).
  • type : the type of traffic : IPV4, IPV6 or Elastic Fabric Adapter.
  • pkt-srcaddr : the packet-level IP address of the source. You typically use this field in conjunction with srcaddr to distinguish between the IP address of an intermediate layer through which traffic flows, such as a NAT gateway.
  • pkt-dstaddr : the packet-level destination IP address, similar to the previous one, but for destination IP addresses.

To create a VPC Flow Log, you can use the AWS Management Console, the AWS Command Line Interface (CLI) or the CreateFlowLogs API, select S3 as destination, and select which additional information and the order you want to consume the fields, for example:

Aws vpc flowlogs 어떤 데이터

Or using the AWS Command Line Interface (CLI) as below:

$ aws ec2 create-flow-logs --resource-type VPC \
                            --region eu-west-1 \
                            --resource-ids vpc-12345678 \
                            --traffic-type ALL  \
                            --log-destination-type s3 \
                            --log-destination arn:aws:s3:::sst-vpc-demo \
                            --log-format '${version} ${vpc-id} ${subnet-id} ${instance-id} ${interface-id} ${account-id} ${type} ${srcaddr} ${dstaddr} ${srcport} ${dstport} ${pkt-srcaddr} ${pkt-dstaddr} ${protocol} ${bytes} ${packets} ${start} ${end} ${action} ${tcp-flags} ${log-status}'

# be sure to replace the bucket name and VPC ID !

{
    "ClientToken": "1A....HoP=",
    "FlowLogIds": [
        "fl-12345678123456789"
    ],
    "Unsuccessful": [] 
}

Enriched VPC Flow Logs are delivered to S3. We will automatically add the required S3 Bucket Policy to authorize VPC Flow Logs to write to your S3 bucket. VPC Flow Logs does not capture real-time log streams for your network interface, it might take several minutes to begin collecting and publishing data to the chosen destinations. Your logs will eventually be available on S3 at s3://<bucket name>/AWSLogs/<account id>/vpcflowlogs/<region>/<year>/<month>/<day>/

An SSH connection from my laptop with IP address 90.90.0.200 to an EC2 instance would appear like this :

3 vpc-exxxxxx2 subnet-8xxxxf3 i-0bfxxxxxxaf eni-08xxxxxxa5 48xxxxxx93 IPv4 172.31.22.145 90.90.0.200 22 62897 172.31.22.145 90.90.0.200 6 5225 24 1566328660 1566328672 ACCEPT 18 OK
3 vpc-exxxxxx2 subnet-8xxxxf3 i-0bfxxxxxxaf eni-08xxxxxxa5 48xxxxxx93 IPv4 90.90.0.200 172.31.22.145 62897 22 90.90.0.200 172.31.22.145 6 4877 29 1566328660 1566328672 ACCEPT 2 OK

172.31.22.145 is the private IP address of the EC2 instance, the one you see when you type ifconfig on the instance.  All flags are “OR”ed during aggregation period. When connection is short, probably both SYN and FIN (3), as well as SYN+ACK and FIN (19) will be set for the same lines.

Once a Flow Log is created, you can not add additional fields or modify the structure of the log to ensure you will not accidently break scripts consuming this data. Any modification will require you to delete and recreate the VPC Flow Logs. There is no additional cost to capture the extra information in the VPC Flow Logs, normal VPC Flow Log pricing applies, remember that Enriched VPC Flow Log records might consume more storage when selecting all fields.  We do recommend to select only the fields relevant to your use-cases.

Enriched VPC Flow Logs is available in all regions where VPC Flow logs is available, you can start to use it today.

-- seb

PS: I heard from the team they are working on adding additional meta-data to the logs, stay tuned for updates.