Introducing VPC Flow Logs for AWS Transit Gateway

Since the launch of Amazon Virtual Private Cloud (Amazon VPC) Flow Logs in 2015, customers have utilized VPC Flow Logs to gain better visibility of network traffic patterns on AWS by providing network telemetry data regarding the IP traffic flowing to and from ENIs within a given VPC. As customers’ networks grew, customers began utilizing multiple VPCs interconnected by AWS Transit Gateways and were looking to gain better visibility of network traffic patterns through the Transit Gateway. Today, we take another step forward in announcing VPC Flow Logs for Transit Gateway, a new capability that allows customers to gain deeper visibility and insights into network traffic on the Transit Gateway. With this feature, Transit Gateway can export detailed information, such as source/destination IPs, ports, protocol, traffic counters, timestamps, and various metadata for all of the network flow traversing through the Transit Gateway.

VPC Flow Logs for Transit Gateway offer a number of key benefits for customers by:

• Centralized Flow Exports to gain end-to-end network visibility: Flow Logs enable network administrators to gain flow level visibility for all of the traffic traversing between VPCs and on-premises networks using one central gateway.
• Gain flow-level insights for traffic traversing to on-premises networks: Flow Logs provides an AWS native tool for customers to centrally export and inspect flow-level information for all of the network traffic that is traversing between AWS and customer’s on-premises networks. Flow Logs provides flow-level visibility for traffic traversing over AWS Direct Connect and VPN connections without having to rely on customer’s on-premises routers or third-party tools in customer data centers.
• Get more granular flow-level metrics in Transit Gateway:  Flow Logs provide more granular visibility into network metrics at an individual flow level, on top of the existing Transit Gateway attachment-level metrics. This flow-level granularity provides customers with valuable insights into their traffic patterns for protocols, applications, and individual end-users accessing AWS resources from on-premises networks.

In this post, you’ll learn more information regarding how VPC Flow Logs for Transit Gateway works, the record format for Flow Logs, and how to create a new Transit Gateway Flow Log subscription.

Industry leading partners

We’re excited to be working with many of our existing VPC Flow Log partners at the launch of VPC Flow Logs for Transit Gateway. Before diving into the details of how VPC Flow Logs for Transit Gateway works, we want to highlight the partners that have integrated with this new feature at launch:

• Datadog:  Analyze VPC Flow Logs for AWS Transit Gateway in Datadog
• Dynatrace:  Dynatrace adds support for AWS Transit Gateway with VPC Flow Logs

Understanding VPC Flow Logs for Transit Gateway and record formats

Customers can create a Flow Log for the entire Transit Gateway or for an individual Transit Gateway attachment. Each record captures a network internet protocol (IP) traffic flow, characterized by a 5-tuple (Source IP, Destination IP, Transport Protocol, Source Port, and Destination Port). Transit Gateway monitors all of the IP traffic and publishes flow log records that represent all of the network flows on the specified resource. By default, the Transit Gateway Flow Log record includes values for the different components of the IP flow, including the source IP, source port, destination IP, destination port, and protocol. When you create a flow log, you can use the default format for the flow record, or you can specify a custom format that includes additional metadata in the flow record. The default information in a Transit Gateway Flow Log record include:

• version:  Indicates the version in which the field was introduced. The default format includes all version 2 fields, in the same order that they appear in this list.
• tgw-id: The ID of the Transit Gateway for which the traffic is recorded
• tgw-attachment-id: The ID of the Transit Gateway attachment for which the traffic is recorded.
• srcaddr: The source IP address
• dstaddr: The destination IP address
• srcport: The source port of the traffic.
• dstport: The destination port of the traffic.
• protocol: The IANA protocol number of the traffic. For more information, see Assigned Internet Protocol Numbers.
• packets: The number of packets transferred during the flow.
• bytes: The number of bytes transferred during the flow.
• start: The timestamp when the first packet of the flow was received within the aggregation interval.
• end: The timestamp when the last packet of the flow was received within the aggregation interval.
• packets-lost-no-route: Packets lost due to no route
• packets-lost-blackhole: Packets lost due to black hole
• packets-lost-mtu-exceeded: Packets lost due to size exceeded MTU
• packets-loss-ttl: Packets lost due to time to live expiry
• tgw-src-vpc-account-id: The AWS account ID of the VPC for source traffic
• tgw-dst-vpc-account-id: The AWS account ID of the VPC for destination traffic
• tgw-src-vpc-id: The ID of the source VPC
• tgw-dst-vpc-id: The ID of the destination VPC
• tgw-src-subnet-id: The ID of the source Transit Gateway attachment subnet for the flow.
• tgw-dst-subnet-id: The ID of the destination Transit Gateway attachment subnet for the flow.
• tgw-src-eni: The ID of the source Transit Gateway attachment ENI for the flow.
• tgw-dst-eni: The ID of the destination Transit Gateway attachment ENI for the flow.
• tcp-flags: The bitmask value for the following TCP flags: SYN, SYN-ACK, FIN, RST, ACK
• type:  The type of traffic. Possible values are IPV4 | IPv6 | EFA.
• region: ID of the AWS Region for the Transit Gateway.
• tgw-src-az-id: ID of the Source Availability Zone.
• tgw-dst-az-id: ID of the Destination Availability Zone
• flow-direction: Direction of flow with respect to the Transit Gateway attachment where traffic is captured. Possible values: ingress | egress.
• pkt-src-aws-service: The name of the AWS Service for source IP Address if applicable
• pkt-dst-aws-service: The name of the AWS Service for destination IP Address if applicable
• resource-type: Type of flow log resource, Transit Gateway or Transit Gateway attachment
• account-id:  The AWS account ID of the owner of the source transit gateway.

AWS provides you with the ability to publish the flow logs to multiple destinations. The first two options are to publish the flow logs to either Amazon CloudWatch Logs or Amazon Simple Storage Service (Amazon S3). These destinations let you view the flow logs in those destinations or utilize flow analysis tools, such as Amazon Athena, Amazon QuickSight, CloudWatch Contributor Insights, or partner solutions. For example, with CloudWatch Contributor Insights, you can produce a list of the Top-N contributors based on data transferred or blocked requests. An example of this with VPC Flow Logs can be found in the Improve security by analyzing VPC flow logs with Amazon CloudWatch Contributor Insights post.

[UPDATE 8/4/2023: In addition to Amazon S3 and CloudWatch, you can now publish to Kinesis Data Firehose. If you are interested, the blog post Introducing Amazon VPC Flow Logs to Kinesis Data Firehose has details on how this works.]

Figure 1 – VPC Flow Logs for Transit Gateway Architecture

Walkthrough

Let’s get started with creating a new Transit Gateway Flow Log. We’ll send Flow Logs to Amazon S3 for our example. However, the destination can be any supported destination, including Amazon S3 and CloudWatch.

Prerequisites

For this walkthrough, you should have the following prerequisites fulfilled:

• You have created at least two VPCs. Optionally, you can also choose existing VPCs.
• You have created a Transit Gateway to interconnect the VPCs together, and you can route traffic from one VPC to another.
• You must have instances or resources deployed in the VPC that can send traffic to and from each other. Without traffic flowing, no flow logs will be created.

Create an Amazon S3 bucket

1. Navigate to the Amazon S3 console and create a bucket with a unique name.
2. Configure any additional settings for the bucket, including public access settings, versioning, and encryption. Additional information about policies and S3 bucket permission policies can be found in the documentation.

Figure 2 – Create an S3 bucket

This bucket will be used to send the Flow Logs as a destination.

Create a Transit Gateway Flow Log subscription

You can create a flow log subscription for a Transit Gateway or a Transit Gateway attachment. If you create a flow log for a Transit Gateway attachment, then all of the traffic ingressing and egressing through that attachment is monitored. For this example, we will create a flow log for a Transit Gateway attachment.

1. Navigate to the Transit Gateway Attachments in console, and select the attachment that you want to monitor.
2. Select Flow logs at the bottom, and select Create flow log at the bottom.

Figure 3 – Select attachment and create flow log

3. Enter the name of the Flow Log subscription.
4. Select Amazon S3 as the destination, inputing the ARN, such as arn:aws::s3:::my-bucket/my-logs/, of the S3 bucket that you created.

Figure 4 – Create a Transit Gateway Flow Log

After you create a Flow Log subscription, it can take several minutes to begin collecting and publishing data to Amazon S3. Flow Logs aggregates the data for your Transit Gateway attachments and sends the Flow Logs in aggregation one minute intervals to the destination.

Enable Flow Logs for an entire Transit Gateway

In addition to supporting Flow Logs on a per Transit Gateway attachment level, we also support configuring Flow Logs on a Transit Gateway level. At a Transit Gateway level, you’ll see all of the flows traversing the Transit Gateway across all of the attachments. For this example, we’ll delete the Transit Gateway attachment Flow Log and create a new Flow Log for the Transit Gateway.

1. Navigate to the Transit Gateway attachment console and delete the Flow Log created in the previous step.
2. Navigate to the Transit Gateway console and select the Transit Gateway that you want to monitor.
3. Select Flow logs at the bottom, and select Create flow log at the bottom.

Figure 5 – Select Transit Gateway and create flow log

4. Enter the name of the Flow Log subscription.
5. Select the type of traffic to capture in the Flow Log.
6. Select Amazon S3 as the destination, inputing the ARN of the S3 bucket that you created.

Sending traffic across different attachments will generate flow logs for the entire Transit Gateway, compared to only the attachment shown in the previous section.

Cleaning up

To avoid incurring future charges, delete the following resources:

1. Delete the Transit Gateway and/or Transit Gateway Attachment Flow Log.
2. Delete the contents in the S3 bucket and the S3 bucket itself.
3. If you created new VPCs, a new Transit Gateway, and/or new instances:
   1. Delete the instances in the VPC
   2. Delete the Transit Gateway attachments and Transit Gateway
   3. Delete the VPCs

Conclusion

In this post, we introduced VPC Flow Logs for Transit Gateway. This is a new capability that allows customers to gain deeper visibility and insights into network traffic on the Transit Gateway. With this feature, Transit Gateway can export detailed information, such as source/destination IPs, ports,protocol, traffic counters, timestamps, and various metadata for all of the network flows traversing through the Transit Gateway. VPC Flow Logs for Transit Gateway can be published to Amazon S3 and CloudWatch. To learn more about VPC Flow Logs for Transit Gateway, visit our documentation and the FAQ page.