How to Monitor AWS Transit Gateway Traffic and Attachment Errors: Step-by-Step Guide

AWS Transit Gateway connects multiple VPCs, AWS accounts, and on-premises networks through a central hub, but without proper monitoring, traffic surges, attachment failures, and routing misconfigurations can go undetected until customer-facing services fail. A single misconfigured route or attachment error can black hole traffic between VPCs, causing silent failures that never trigger application-level alerts.

This guide walks through the exact steps to monitor AWS Transit Gateway traffic patterns, flow logs, attachment health, and performance metrics using CloudWatch, VPC Flow Logs, and observability platforms that provide unified visibility across your entire AWS network.

Prerequisites

Before you begin monitoring AWS Transit Gateway, ensure you have:

• An active AWS account with Transit Gateway deployed and at least one VPC attachment configured
• IAM permissions to enable CloudWatch metrics, create log groups, and configure VPC Flow Logs
• AWS CLI installed and configured, or access to the AWS Management Console
• An S3 bucket for storing Transit Gateway Flow Logs (optional but recommended for long term retention and cost efficiency)
• A CloudWatch Logs log group or an observability platform that can ingest and query AWS logs at scale
• Basic familiarity with VPC networking, route tables, and Transit Gateway attachment types (VPC, VPN, Direct Connect)

Step 1: Enable CloudWatch Metrics for Transit Gateway

AWS Transit Gateway publishes metrics to CloudWatch automatically at no extra charge, but you need to know which metrics to monitor and how to set up dashboards and alerts that catch issues before they cascade.

Transit Gateway metrics are published to the AWS/TransitGateway namespace every 60 seconds. Key metrics include:

• BytesIn and BytesOut — total bytes flowing through the Transit Gateway, useful for tracking traffic volume and detecting surges
• PacketsIn and PacketsOut — packet count, which helps identify flood attacks or unusual traffic patterns
• PacketDropCountBlackhole — packets dropped because no route exists, often caused by misconfigured route tables or missing attachments
• PacketDropCountNoRoute — packets dropped due to missing route entries in the Transit Gateway route table

To view these metrics in the AWS Console:

1. Navigate to CloudWatch → Metrics → All metrics
2. Select the AWS/TransitGateway namespace
3. Choose metrics by Transit Gateway ID or attachment ID to drill down by specific VPC or VPN connection
4. Add metrics to a dashboard or create an alarm for packet drop thresholds

For teams managing multiple Transit Gateways across regions or accounts, pulling these metrics into a centralized observability platform avoids the context switching required when monitoring each Transit Gateway individually in separate CloudWatch dashboards.

Step 2: Enable Transit Gateway Flow Logs for Traffic Visibility

Transit Gateway Flow Logs capture detailed records of IP traffic traversing your Transit Gateway, including source and destination IPs, ports, protocol, packet and byte counts, and the specific attachment each flow passed through. Unlike CloudWatch metrics, which give aggregate counts, flow logs provide per-flow visibility, making them essential for diagnosing asymmetric routing, debugging connectivity issues, and identifying bandwidth-heavy workloads.

To enable Transit Gateway Flow Logs:

1. Open the AWS VPC Console and navigate to Transit Gateways
2. Select your Transit Gateway and choose Actions → Create flow log
3. Configure the destination:

• CloudWatch Logs: creates a log group where each flow record is stored as a log event
• S3: stores flow logs as compressed files, more cost effective for long term storage and analysis

1. Select the flow log format. Use the default format unless you need custom fields for specific analysis
2. Set the aggregation interval: 1 minute for near real time visibility or 10 minutes for reduced log volume
3. Add tags to identify the flow log resource, especially if you are managing multiple Transit Gateways

Once enabled, flow logs begin capturing traffic within a few minutes. Each flow log record includes:

• Attachment ID — which VPC, VPN, or Direct Connect connection the traffic passed through
• Source and destination account IDs — useful for identifying cross-account traffic patterns
• Packets and bytes transferred — helps measure actual data transfer and detect bandwidth anomalies
• Packet loss reasons — including NO_ROUTE, BLACK_HOLE, MTU_EXCEEDED, and TTL_EXPIRED

Flow logs do not capture individual packet payloads but provide enough detail to reconstruct traffic patterns, diagnose routing failures, and identify the exact attachment or route causing packet loss.

This estimate models production Transit Gateway monitoring at scale. Smaller deployments with fewer attachments or lower traffic volume will generate fewer flow logs and incur lower CloudWatch or S3 storage costs.

Step 3: Query Transit Gateway Flow Logs for Packet Loss and Routing Issues

Once Transit Gateway Flow Logs are enabled, the next step is querying them to detect specific issues: missing routes, packet loss, cross-region latency spikes, or traffic imbalances across attachments.

If you sent flow logs to CloudWatch Logs, you can query them using CloudWatch Logs Insights. Navigate to CloudWatch → Logs → Insights, select your Transit Gateway flow log group, and run queries to surface patterns.

Example query to find flows with packet loss:

fields @timestamp, srcaddr, dstaddr, packets_lost_no_route, packets_lost_blackhole
| filter packets_lost_no_route > 0 or packets_lost_blackhole > 0
| sort @timestamp desc
| limit 100

This query returns all flows where packets were dropped due to missing routes or black hole routes, helping you identify misconfigured Transit Gateway route tables or VPC route tables that point to a non-existent attachment.

Example query to identify top talkers by attachment:

fields attachment_id, sum(bytes) as total_bytes
| stats sum(total_bytes) by attachment_id
| sort total_bytes desc

This shows which VPC or VPN attachment is generating the most traffic, useful for capacity planning and detecting unexpected bandwidth usage from a specific workload or service.

If you sent flow logs to S3, you can query them using Amazon Athena by creating a table that maps to the S3 bucket structure, then running SQL queries to aggregate and filter flow records at scale.

For teams working with high flow log volume (tens of GB per day or more), querying directly in CloudWatch Logs Insights can become slow and expensive. Centralized log management platforms with fast indexing and high cardinality filtering make it easier to search across months of flow logs without waiting minutes for query results.

Step 4: Monitor Transit Gateway Attachment Health and State Changes

Transit Gateway attachments represent connections to VPCs, VPN tunnels, Direct Connect gateways, or peering connections. Each attachment has a state: available, pending, modifying, deleting, deleted, failed, or rejected. Monitoring attachment state transitions helps catch configuration errors, quota limits, or networking issues that prevent traffic from flowing.

CloudWatch does not publish attachment state as a metric by default. Instead, you can monitor attachment state using EventBridge (formerly CloudWatch Events) or by polling the Transit Gateway API periodically.

To set up EventBridge monitoring for attachment state changes:

1. Navigate to EventBridge → Rules → Create rule
2. Define the event pattern to match Transit Gateway API calls:

{
  "source": ["aws.ec2"],
  "detail-type": ["AWS API Call via CloudTrail"],
  "detail": {
    "eventName": [
      "CreateTransitGatewayVpcAttachment",
      "DeleteTransitGatewayVpcAttachment",
      "ModifyTransitGatewayVpcAttachment"
    ]
  }
}

1. Set the target to an SNS topic, Lambda function, or an observability platform webhook
2. Test the rule by creating or modifying a test attachment

This setup ensures you receive an alert whenever an attachment is created, deleted, or modified, helping you track unintended changes or detect when an attachment fails to reach the available state.

For production environments with dozens of attachments across multiple accounts, a centralized dashboard showing attachment state, last state change timestamp, and associated route table propagations reduces the time required to diagnose why traffic between two VPCs suddenly stopped flowing.

Step 5: Set Up Alerts for Transit Gateway Packet Loss and Traffic Anomalies

Monitoring metrics and flow logs is only useful if you get notified when something goes wrong. CloudWatch Alarms allow you to define thresholds and trigger notifications via SNS, but setting effective alert thresholds requires understanding normal baseline traffic patterns for your Transit Gateway.

To create a CloudWatch Alarm for packet drops:

1. Navigate to CloudWatch → Alarms → Create alarm
2. Select the AWS/TransitGateway namespace and choose the PacketDropCountNoRoute metric
3. Set the statistic to Sum and the period to 5 minutes
4. Define the threshold: for example, trigger if packet drops exceed 100 in a 5 minute window
5. Configure the alarm action to send a notification to an SNS topic

Example alarm for sustained high traffic:

1. Select the BytesOut metric for your Transit Gateway
2. Set the statistic to Average over a 10 minute period
3. Trigger if average bytes out exceeds 10 GB per 10 minutes, indicating a potential DDoS, data exfiltration, or misconfigured application sending excessive traffic

CloudWatch Alarms work well for basic thresholds, but they lack the context required to understand why packet loss is happening. For example, an alert that says “PacketDropCountNoRoute = 150” does not tell you which VPC attachment, which source IP, or which destination was affected. Observability platforms that correlate Transit Gateway metrics with VPC Flow Logs, application traces, and infrastructure events provide that missing context, reducing mean time to resolution during incidents.

Step 6: Correlate Transit Gateway Metrics with Application Performance and Infrastructure Monitoring

Transit Gateway sits at the network layer, but most incidents that appear as Transit Gateway packet loss or latency actually originate in application misconfiguration, database overload, or security group rules blocking traffic. Monitoring Transit Gateway in isolation creates blind spots.

To get full visibility:

• Correlate Transit Gateway flow logs with application APM traces to see if a slow API response correlates with cross-VPC network latency
• Link Transit Gateway attachment state changes with deployment events to detect if a recent infrastructure change caused an attachment to go into failed state
• Overlay Transit Gateway traffic volume metrics with EC2 instance CPU and network utilization to determine if packet loss is caused by insufficient instance capacity rather than routing issues

Platforms that ingest AWS CloudWatch metrics, Transit Gateway Flow Logs, VPC Flow Logs, and application telemetry into a single queryable data store make this correlation possible without manually jumping between CloudWatch, AWS Console, and APM dashboards.

CubeAPM provides unified monitoring for AWS infrastructure, including Transit Gateway metrics, VPC Flow Logs, and application traces, all correlated in one platform. It runs on your own infrastructure, avoiding AWS CloudWatch egress charges and ensuring Transit Gateway flow logs never leave your VPC. Pricing is $0.15/GB for all ingested telemetry, with no per-host or per-user fees. For teams running self hosted infrastructure monitoring alongside Transit Gateway monitoring, CubeAPM eliminates the need to maintain separate Prometheus, Grafana, and CloudWatch integrations.

Troubleshooting Common Issues

Packet loss shows in CloudWatch but flow logs show no drops

This usually means the packet loss is happening at the VPC or instance level, not at the Transit Gateway. Check VPC Flow Logs for the affected VPC attachment and verify security group rules, network ACLs, and instance network interface limits.

Transit Gateway attachment stuck in `pending` state

Common causes include VPC route table propagation disabled, insufficient IP address space in the VPC subnet, or AWS service quota limits. Check the Transit Gateway route table to confirm the VPC CIDR is propagated, and verify your account has not hit the attachment limit for your region.

Flow logs enabled but no records appearing in CloudWatch or S3

Verify the IAM role assigned to the flow log has permissions to write to the destination. For CloudWatch Logs, the role needs logs:CreateLogGroup, logs:CreateLogStream, and logs:PutLogEvents. For S3, it needs s3:PutObject on the target bucket. Also confirm the Transit Gateway is actively routing traffic, flow logs only capture active flows.

High CloudWatch Logs costs from Transit Gateway Flow Logs

Transit Gateway Flow Logs can generate significant log volume in high traffic environments. Consider switching to S3 as the destination for lower storage costs, or reduce the aggregation interval from 1 minute to 10 minutes. For long term retention and fast querying, centralized log platforms with flat per-GB pricing avoid CloudWatch’s per-GB ingestion and query charges.

Asymmetric routing causing intermittent packet loss

This occurs when traffic from VPC A to VPC B flows through one Transit Gateway attachment, but return traffic takes a different path. Enable appliance mode on the Transit Gateway attachment to force traffic to stay within the same Availability Zone, preventing cross-AZ asymmetry.

Conclusion

Monitoring AWS Transit Gateway requires more than enabling CloudWatch metrics. Transit Gateway Flow Logs provide per-flow visibility into traffic patterns, packet loss reasons, and attachment-level throughput. Correlating flow logs with application traces, infrastructure metrics, and deployment events reduces the time required to diagnose routing failures, capacity bottlenecks, and security misconfigurations.

For teams managing Transit Gateways at scale across multiple AWS accounts or regions, centralized observability platforms that ingest CloudWatch metrics, flow logs, and application telemetry into a single queryable store eliminate the manual work of switching between AWS Console, CloudWatch dashboards, and third-party APM tools.

Disclaimer: The information in this article reflects the latest details available at the time of publication and may change as technologies and products evolve. Features, pricing, and plan limits can change over time. Always verify the latest information directly with the vendor before making purchasing or deployment decisions.

Frequently Asked Questions