On July 14th 2022, AWS announced a new capability: flow logs for Transit Gateway. Transit Gateway VPC flow logs allows users to gain more visibility and insights into network traffic on the Transit Gateway.

AWS highlights these key benefits of using the new capability:

  • Centralized Flow Exports to gain end-to-end network visibility
  • Gain flow-level insights for traffic traversing to on-premises networks
  • Get more granular flow-level metrics in Transit Gateway

In this blog, we will focus on the security and forensic aspects of Transit Gateway VPC flow logs and expand the way this feature can be used by organizations to respond to cloud incidents.

AWS VPS flow logs for AWS transit gateway
Introducing VPC Flow Logs for AWS Transit Gateway

What is a transit gateway?

A transit gateway is a network transit hub that you can use to interconnect your virtual private clouds (VPCs) and on-premises networks.

AWS provides a solution for interconnecting multiple VPCs and on-premises networks using a single regional virtual router, which is the Transit Gateway, instead of using other solutions, such as VPC peering, which interconnects only two VPCs. Routing through a transit gateway operates at layer 3.

Architecture diagram of a transit gateway from AWS docs
Architecture diagram of a transit gateway from AWS docs

What is VPC flow logs?

VPC Flow logs is a feature that gives you visibility into the IP traffic going to and from network interfaces in your VPC.

It captures information about allowed and denied traffic (based on security group and network access control list (ACL) rules). It also includes source and destination IP addresses, ports, the Internet Assigned Numbers Authority (IANA) protocol number, packet and byte counts, a time interval during which the flow was observed, and an action (ACCEPT or REJECT). VPC flow logs don’t record the network packet raw data, only metadata about the network communication.

AWS provides a list of all available fields for a flow log record.

You can configure VPC flow logs on VPC, VPC subnet, or Elastic Network Interface (ENI) and export the logs to an S3 bucket or CloudWatch log group.

What are the benefits of using Transit Gateway VPC flow logs?

Before this capability, in order to record traffic going in and out from your Transit Gateway, you had to use the VPC flow logs, which were configured on VPC/VPC subnet/Elastic Network Interface (ENI) for each VPC connected to the Transit Gateway, looking at all the VPC flow logs records to see the full picture. If you used Transit Gateway for connecting on-premise networks, you could see IP addresses in the flow logs that originated from the on-premises network, but without understanding the trace route.

In the following picture, you can see a flow log record of network traffic coming from interface: “eni-041eb5ce012a00766“ using IP address 10.0.8.214 to 20.0.6.132, which is an Amazon Elastic Compute Cloud (Amazon EC2) in VPC2.

network record
network record

In order to get the full picture (account id, VPC id, Subnet id) you have to collect flow logs from all the VPCs connected to the Transit Gateway.

In the following picture, you can see part of log record from the Transit Gateway VPC flow logs:

Part of the flow log record in JSON format
Part of the flow log record in JSON format

In this record, you can see the account id, VPC id, subnets of the source, and destination endpoints from a single log source.

AWS provides a list of all the available fields for transit gateway flow log record.

Keep in mind, Transit Gateway VPC flow logs only record network traffic that transferred through the gateway and not all the network traffic coming in and out the VPC networks connected to the gateway. Transit Gateway VPC flow logs recording doesn’t replace VPC flow logs recording. For example, in our provided network topology, the gateway flow log won’t record communication between the two instances in the 10.0.0.0/16 VPC.

Examples of security cases when Transit Gateway VPC flow logs collection can help

1. Security incident in one of the VPC/accounts attached to the Transit Gateway

Transit Gateway

Imagine a scenario in which one of the AWS account your company possesses experienced a security incident. In that account, there were formerly (some of them still exist) multiple network connections to different AWS accounts using a Transit Gateway at the time of the incident. We don’t know how many EC2 instances in the account were infected.

We need to answer the question: “Are resources in the other AWS account that have VPC resources attached to the Transit Gateway affected by the incident?“ Using the Transit Gateway VPC flow logs, you can easily answer this question by scanning network records for which the source was the affected VPC/AWS account and check for potential network lateral movement.

2. Hunting for network lateral movement

In some cases, you want to hunt for potential malicious activity. You can scan the Transit Gateway VPC flow logs to check for abnormalities in connections between different networks connected to the gateway.

One example of such a case is an adversary in the on-premises network that tries to “jump” to the cloud resources.

On premises network - Transit Gateway

You can easily find evidence of such a jump in a single log source (Transit Gateway VPC flow) instead of compiling different types of log sources together.

Conclusions

Transit Gateway VPC flow logs is indeed a valuable source for forensic investigations as well as threat hunting. At Mitiga, we are constantly monitoring new service announcements of cloud service providers and extending our solution to support a growing number of services and data sources.

Transit Gateway VPC flow logs are no different. Mitiga’s Incident Readiness and Response (IR²) solution already supports this data source and includes scalable and effective ways to collect, parse, store, analyze, fetch, and investigate Transit Gateway VPC flow logs.

Mitiga’s customers who turn on Transit Gateway VPC flow logs may benefit twice: first, they get improved incident response readiness; second, they unlock more proactive business-as-usual value, as Mitiga hunts for malicious indicators in Transit Gateway VPC flow logs through its proactive forensics threat hunting capability.

To conclude, enabling and using Transit Gateway VPC flow logs can help in security incidents by helping you find answers from a single source of logs, instead of combining different types of logs and data about your environment in order to get to the same answers. If you heavily use Transit Gateways in your environment, you should strongly consider using this capability. It is important to remember that the Transit Gateway VPC flow logs capability doesn’t replace VPC flow logs in VPCs that are connected to the gateway. Transit Gateway VPC flow logs don’t cover networks that reach the VPC in ways other than through the gateway.

LAST UPDATED:

June 23, 2025

Don't miss these stories:

Why Visibility Drives Everything in Modern Cybersecurity with Sevco’s Greg Fitzgerald

In this episode of Mitiga Mic, Brian Contos sits down with Greg Fitzgerald, co-founder of Sevco Security, for a candid conversation on the real state of asset visibility, prioritization, and the evolving challenges facing security teams. With nearly three decades in the industry, Fitzgerald brings perspective on how cybersecurity has shifted from endpoint tools to orchestration-wide awareness. And why that shift is critical for cloud, SaaS, AI, and identity defense. Watch the episode or read the full transcript below.

How Threat Actors Used Salesforce Data Loader for Covert API Exfiltration

In recent weeks, a sophisticated threat group has targeted companies using Salesforce’s SaaS platform with a campaign focused on abusing legitimate tools for illicit data theft. Mitiga’s Threat Hunting & Incident Response team, part of Mitiga Labs, investigated one such case and discovered that a compromised Salesforce account was used in conjunction with a “Salesforce Data Loader” application, a legitimate bulk data tool, to facilitate large-scale data exfiltration of sensitive customer data.

God-Mode in the Shadows: When Security Tools and Excessive Permissions Become Cloud Security Risks

By the time the alarms go off, it’s often too late. A trusted third-party security tool, one that promised to protect your cloud and SaaS environments, has been operating with unchecked ‘god-mode’ privileges. These tools, usually classified as SaaS Security Posture Management (SSPM) or Data Security Posture Management (DSPM), have been granted near-unrestricted access to your data, configurations, and secrets.

How AI Is Transforming Cybersecurity: Detection, Response & Threat Evolution with Mitiga’s Ofer Maor

In this episode of Mitiga Mic, Brian Contos, Field CISO at Mitiga, sits down once again with Ofer Maor, CTO and Co-founder, to break down one of today’s most urgent cybersecurity challenges: the intersection of Artificial Intelligence (AI) and Detection & Response. From the Automated SOC to AI-powered attackers and cloud-based AI infrastructure threats, Ofer outlines the three pillars of AI-DR (AI Detection and Response) and what organizations need to know now and in the near future.

Meet Mitiga in Las Vegas at Black Hat, DEF CON, and BSides

From August 4 to 11, Mitiga will be on the ground in Las Vegas for Black Hat USA, DEF CON, and BSides Las Vegas. If you’re responsible for cloud security, SaaS threat detection, or incident response, this is your opportunity to connect directly with our team.

Why Wi-Fi Isn’t Enough: Joseph Salazar on Wireless Airspace Security

In this episode of Mitiga Mic, we sit down with cybersecurity veteran Joseph Salazar, now with Bastille Networks, to uncover the vast and often invisible world of wireless attack surfaces. From Bluetooth-enabled coffee mugs and smart thermostats to malicious USB cables that launch attacks from parking lots, Joseph walks us through real-world threats that operate outside your firewall and beyond traditional security tools.