Monitoring global traffic with AWS Cloud WAN Flow Logs

Monitoring global traffic can be challenging in large network deployments, where traffic crosses many accounts, AWS Regions, and teams. With AWS Cloud WAN, that traffic already passes through one core network that connects your VPCs and on-premises sites. Until now, though, seeing it at the flow level meant turning on Amazon Virtual Private Cloud (Amazon VPC) Flow Logs in each VPC and correlating the records yourself. Traffic between hybrid attachments, such as AWS Direct Connect, AWS Site-to-Site VPN, and Connect attachments, never reaches a VPC, so VPC Flow Logs can’t capture it.

Today we’re announcing AWS Cloud WAN Flow Logs. From the account that owns your core network, you capture flow logs for the traffic that crosses it. Every record includes the source and destination Region, segment, and attachment. You can publish them to Amazon CloudWatch Logs, Amazon Simple Storage Service (Amazon S3), or Amazon Data Firehose. You then analyze them with Amazon Athena or Amazon CloudWatch Logs Insights.

This 300-level post is for network administrators familiar with AWS Cloud WAN segments and attachments. It shows how to create flow logs at each scope and query them for cross-segment traffic, cross-Region traffic, and drops.

Key benefits

AWS Cloud WAN Flow Logs give you the following benefits:

• One view of your global network. Monitor traffic between VPCs, Regions, and on-premises networks connected through AWS Direct Connect, AWS Site-to-Site VPN, or software-defined WAN (SD-WAN).
• AWS Cloud WAN context in every record. Find out how much traffic moves between segments or Regions from a single query or dashboard.
• Service insertion and NAT context. Records show which inspection attachment a flow passed through and, with 1:1 network address translation (NAT), the translated address next to the original one.
• Drop reasons. Records show when and why AWS Cloud WAN drops a packet, complementing your attachment-level Amazon CloudWatch metrics. For examples, refer to the Pinpoint routing issues section.

How AWS Cloud WAN Flow Logs work

You create a flow log at one of three scopes. Resource type values are case sensitive.

Create an edge-scope flow log for each edge you monitor. Each record describes one flow through one attachment in one direction over a 1-minute interval.

You can create flow logs for VPC, Site-to-Site VPN, Direct Connect gateway, Connect (GRE), and AWS Transit Gateway peering attachments. Flows for a tunnel-less Connect attachment appear on its transport attachment, and flows for a Transit Gateway route table attachment appear on the peering attachment.

You manage all flow logs for a core network in the AWS Cloud WAN home Region: US West (Oregon) (us-west-2) for commercial Regions, or AWS GovCloud (US-West) (us-gov-west-1) for AWS GovCloud (US). AWS Cloud WAN publishes the logs from that Region.

The following figure shows the three scopes and their destinations.

Figure 1: AWS Cloud WAN Flow Logs scopes and destinations.

What’s in a flow log record

The default format has 42 fields, delivered as one space-separated line per record. The following table describes the AWS Cloud WAN context fields, with values from a ping from VPC A (segment dev) to VPC C (segment prod). The src-eni, dst-eni, and subnet fields describe the network interfaces of the AWS Cloud WAN attachment, not of your instances. For descriptions of all 42 fields, refer to the AWS Cloud WAN Flow Logs documentation.

Counting traffic accurately

AWS Cloud WAN records traffic each time it enters or leaves the core network through an attachment in scope. The following figure shows how a request and its response produce four records. To total traffic once, filter on flow-direction = 'ingress' or on one cwan-attachment-id.

Figure 2: With both attachments in scope, a request and its response produce four records.

The solid line is the request, recorded at attachment A as ingress (1) and at attachment C as egress (2). The dashed line is the response, recorded at attachment C as ingress (3) and at attachment A as egress (4).

Walkthrough

The example core network has edges in us-east-1 and us-west-2, two segments that share routes, and three VPCs: A (us-east-1, dev), C (us-east-1, prod), and B (us-west-2, prod). The core network flow log goes to CloudWatch Logs and the others go to Amazon S3.

Prerequisites

You need the following:

• Access to the account that owns the core network. That account manages flow logs for all its attachments.
• AWS Identity and Access Management (IAM) permissions to create flow logs, including networkmanager:GetCoreNetwork on the core network. For delivery role examples, refer to the AWS Cloud WAN Flow Logs documentation.
• Attachments exchanging traffic. A flow log stays in PROVISIONING until AWS Cloud WAN delivers its first records.
• AWS Command Line Interface (AWS CLI) version 2.40.1 or later.

Plan your first flow logs. Creating flow logs can briefly change the state of your core network or attachments:

• What locks the core network. The first core network flow log and the first edge flow log each set up delivery infrastructure, which briefly puts the core network in the UPDATING state. Policy updates and other changes do the same.
• What fails while it’s locked. While the core network is UPDATING, attempts to create new attachments, core network flow logs, or edge flow logs fail. Check that it’s AVAILABLE before your next change. Attachment flow logs don’t change the core network state. The first flow log on an attachment briefly puts that attachment in UPDATING, and another flow log on that attachment fails until it’s AVAILABLE again.
• How long delivery takes. Your first flow log can take longer to deliver records, because AWS Cloud WAN provisions the delivery resources before it sends any. Later flow logs deliver records within about 10 minutes.

Step 1: Prepare your destinations

Amazon S3. Create a bucket in us-west-2 with S3 Block Public Access turned on. If your identity can update the bucket policy, AWS Cloud WAN adds statements that allow delivery.logs.amazonaws.com to write to each log prefix when you create the flow log. If you manage bucket policies as code, add these statements yourself. For the statement text, refer to Amazon S3 bucket permissions for flow logs. If the bucket uses an AWS Key Management Service (AWS KMS) key, the key policy must also allow that principal.

Amazon Data Firehose. Create a Direct PUT stream in us-west-2. When you create the flow log, AWS tags the stream with LogDeliveryEnabled=true and creates the AWSServiceRoleForLogDelivery service-linked role if it doesn’t exist yet. Records arrive as JSON lines, one per record, in the form {"message":"<record>"}.

Amazon CloudWatch Logs. Create a log group in us-west-2, the Region where you call the API, and an IAM role for delivery:

aws logs create-log-group --log-group-name my-cloud-wan-flow-logs --region us-west-2 aws iam create-role --role-name CloudWanFlowLogsDelivery \ --assume-role-policy-document file://trust-policy.json aws iam put-role-policy --role-name CloudWanFlowLogsDelivery \ --policy-name WriteFlowLogs --policy-document file://permissions-policy.json

The trust policy (trust-policy.json) lets the flow logs service assume the role for your account:

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "vpc-flow-logs.amazonaws.com" }, "Action": "sts:AssumeRole", "Condition": { "StringEquals": { "aws:SourceAccount": "111122223333" } } } ] }

The permissions policy (permissions-policy.json) lets the role write to your log group:

{ "Version": "2012-10-17", "Statement": [ { "Sid": "WriteToFlowLogGroup", "Effect": "Allow", "Action": [ "logs:CreateLogStream", "logs:PutLogEvents", "logs:DescribeLogStreams" ], "Resource": [ "arn:aws:logs:us-west-2:111122223333:log-group:my-cloud-wan-flow-logs", "arn:aws:logs:us-west-2:111122223333:log-group:my-cloud-wan-flow-logs:*" ] }, { "Sid": "ListLogGroups", "Effect": "Allow", "Action": "logs:DescribeLogGroups", "Resource": "arn:aws:logs:us-west-2:111122223333:log-group:*" } ] }

Step 2: Create flow logs

Each command sets its destination with the following options:

Create a core network flow log in CloudWatch Logs

The following command sends the default format for every attachment:

aws ec2 create-flow-logs \ --region us-west-2 \ --resource-type CoreNetwork \ --resource-ids core-network-0123456789abcdef0 \ --log-group-name my-cloud-wan-flow-logs \ --deliver-logs-permission-arn arn:aws:iam::111122223333:role/CloudWanFlowLogsDelivery

The command returns the flow log ID:

{ "ClientToken": "EXAMPLEz1m0EXAMPLE", "FlowLogIds": [ "fl-0aaaaaaaaaaaaaaa1" ], "Unsuccessful": [] }

Each attachment gets a log stream named <attachment-id>-all. If this is the first flow log on the core network, wait until the core network is AVAILABLE before you run the next command. The following command returns its state:

aws networkmanager get-core-network --region us-west-2 \ --core-network-id core-network-0123456789abcdef0 \ --query CoreNetwork.State --output text

When the core network is ready, the command returns AVAILABLE.

Create an edge flow log in Amazon S3 as Parquet

The edge resource ID is the core network ID, a slash, and the edge’s Region code. The following command writes Apache Parquet with Hive-compatible, hourly partitions:

aws ec2 create-flow-logs \ --region us-west-2 \ --resource-type CoreNetworkEdge \ --resource-ids core-network-0123456789abcdef0/us-east-1 \ --log-destination-type s3 \ --log-destination arn:aws:s3:::amzn-s3-demo-bucket/edge/ \ --destination-options FileFormat=parquet,HiveCompatiblePartitions=true,PerHourPartition=true

The command returns fl-0bbbbbbbbbbbbbbb2, and objects land under a path like the following:

edge/AWSLogs/aws-account-id=111122223333/aws-service=vpcflowlogs/aws-region=us-west-2/year=2026/month=10/day=29/hour=16/

The first edge flow log also puts the core network in UPDATING, so run the same check before you create the flow log for the second edge. To cover the second edge, run the same command with --resource-ids core-network-0123456789abcdef0/us-west-2, which returns fl-0ddddddddddddddd4.

Create an attachment flow log with a custom format

Pass --log-format with the AWS Cloud WAN fields you need, in single quotation marks so your shell doesn’t expand them:

aws ec2 create-flow-logs \ --region us-west-2 \ --resource-type CoreNetworkAttachment \ --resource-ids attachment-0aaaaaaaaaaaaaaa1 \ --log-destination-type s3 \ --log-destination arn:aws:s3:::amzn-s3-demo-bucket/attachment/ \ --log-format '${srcaddr} ${dstaddr} ${srcport} ${dstport} ${protocol} ${bytes} ${packets} ${src-region} ${dst-region} ${src-segment-name} ${dst-segment-name} ${flow-direction}'

The command returns fl-0ccccccccccccccc3. The following table shows the address and count fields from five records. Records 1 and 2 are an HTTP response and request, record 3 is a ping, and records 4 and 5 are drops.

The following table shows the AWS Cloud WAN context fields from the same records. For the drops in records 4 and 5, dst-region and dst-segment-name are a hyphen (-), because AWS Cloud WAN has no destination for the packet.

The default format doesn’t include the 1:1 NAT fields. To log them, add ${src-nat-addr} ${dst-nat-addr} to --log-format. A record sets at most one of them: src-nat-addr for traffic from the attachment that uses 1:1 NAT, and dst-nat-addr for traffic to it. srcaddr and dstaddr keep the VPC address, so to find traffic by its translated address, filter on the NAT fields.

Step 3: Check the status

Run the following command with the flow log ID from Step 2:

aws ec2 describe-flow-logs --region us-west-2 --flow-log-ids fl-0aaaaaaaaaaaaaaa1

A flow log becomes ACTIVE when its first records arrive. After about 10 minutes, confirm that DeliverLogsStatus is still SUCCESS and that log streams or objects exist. If the status is FAILED, DeliverLogsErrorMessage gives the reason.

Analyzing AWS Cloud WAN Flow Logs

The following sections show how to find dropped traffic and query your flow logs.

Pinpoint routing issues

When AWS Cloud WAN drops a packet, the record shows why. The numbers match the following figure:

• 1, No route (10.99.0.10): the destination isn’t reachable from the source segment. dst-attachment-type is drop:no-route, and packets-lost-no-route counts the packets.
• 2, Blocked route (10.98.0.10): the destination matches a route that discards traffic. dst-attachment-type is drop:blackhole, and packets-lost-blackhole counts the packets.
• 3, Time to live (TTL) expired (VPC C): the packet’s IP TTL, which the sender sets, runs out in the core network. In this example, the packet was sent with ping -t 1. packets-lost-ttl-expired counts the packets on the destination attachment’s egress record. dst-attachment-type keeps the real attachment type, such as vpc, so a drop: filter doesn’t find these.

For no-route and blocked-route drops, the destination attachment, VPC, Region, and segment fields are -, but dstaddr and dstport remain set.

Figure 3: How flow logs record traffic that AWS Cloud WAN didn’t deliver.

Query with Amazon Athena

The following statement creates a table with partition projection over the Parquet flow logs, so new hourly partitions are queryable without an AWS Glue crawler.

CREATE EXTERNAL TABLE IF NOT EXISTS cwan_flow_logs_edge ( version int, resource_type string, account_id string, core_network_id string, cwan_attachment_id string, cwan_pair_attachment_id string, src_account_id string, dst_account_id string, src_vpc_id string, dst_vpc_id string, src_subnet_id string, dst_subnet_id string, src_eni string, dst_eni string, src_az_id string, dst_az_id string, srcaddr string, dstaddr string, srcport int, dstport int, protocol int, packets bigint, bytes bigint, `start` bigint, `end` bigint, log_status string, type string, tcp_flags int, flow_direction string, packets_lost_no_route bigint, packets_lost_blackhole bigint, packets_lost_mtu_exceeded bigint, packets_lost_ttl_expired bigint, src_region string, dst_region string, src_segment_name string, dst_segment_name string, pkt_src_aws_service string, pkt_dst_aws_service string, network_function_group_attachment_ids string, src_attachment_type string, dst_attachment_type string ) PARTITIONED BY (`aws-account-id` string, `aws-service` string, `aws-region` string, `year` string, `month` string, `day` string, `hour` string) STORED AS PARQUET LOCATION 's3://amzn-s3-demo-bucket/edge/AWSLogs/' TBLPROPERTIES ( 'projection.enabled' = 'true', 'projection.aws-account-id.type' = 'enum', 'projection.aws-account-id.values' = '111122223333', 'projection.aws-service.type' = 'enum', 'projection.aws-service.values' = 'vpcflowlogs', 'projection.aws-region.type' = 'enum', 'projection.aws-region.values' = 'us-west-2', 'projection.year.type' = 'integer', 'projection.year.range' = '2026,2030', 'projection.month.type' = 'integer', 'projection.month.range' = '1,12', 'projection.month.digits' = '2', 'projection.day.type' = 'integer', 'projection.day.range' = '1,31', 'projection.day.digits' = '2', 'projection.hour.type' = 'integer', 'projection.hour.range' = '0,23', 'projection.hour.digits' = '2', 'storage.location.template' = 's3://amzn-s3-demo-bucket/edge/AWSLogs/aws-account-id=${aws-account-id}/aws-service=${aws-service}/aws-region=${aws-region}/year=${year}/month=${month}/day=${day}/hour=${hour}' )

The aws-region partition is the publishing Region, not the Region of your edge or bucket. Parquet column names use underscores, such as flow_direction. If your queries return no rows, check that projection.aws-region.values matches the aws-region= value in your own S3 object paths.

Traffic between segments

The following query totals ingress traffic for each segment pair:

SELECT src_segment_name, dst_segment_name, sum(bytes) AS total_bytes, count(*) AS records FROM cwan_flow_logs_edge WHERE year = '2026' AND month = '10' AND day = '29' AND hour BETWEEN '11' AND '16' AND flow_direction = 'ingress' GROUP BY src_segment_name, dst_segment_name ORDER BY total_bytes DESC;

The query returns the following:

src_segment_name | dst_segment_name | total_bytes | records prod | dev | 7488222292 | 1670 prod | prod | 828117301 | 769 dev | prod | 12562720 | 1672 dev | - | 20760 | 48

Traffic between Regions

The following query shows inter-Region traffic for data transfer and workload planning. In this window, the – row is the dropped traffic.

SELECT src_region, dst_region, sum(bytes) AS total_bytes, sum(packets) AS total_packets FROM cwan_flow_logs_edge WHERE year = '2026' AND month = '10' AND day = '29' AND hour BETWEEN '11' AND '16' AND flow_direction = 'ingress' GROUP BY src_region, dst_region ORDER BY total_bytes DESC;

The query returns the following:

src_region | dst_region | total_bytes | total_packets us-east-1 | us-east-1 | 7500785012 | 1132774 us-west-2 | us-east-1 | 826715230 | 101983 us-east-1 | us-west-2 | 1402071 | 24526 us-east-1 | - | 20760 | 270

Dropped traffic

The following query skips the ingress filter. AWS Cloud WAN records TTL-expired drops on the destination attachment as egress.

SELECT srcaddr, dstaddr, dst_attachment_type, sum(packets_lost_no_route) AS no_route, sum(packets_lost_blackhole) AS blackhole, sum(packets_lost_mtu_exceeded) AS mtu_exceeded, sum(packets_lost_ttl_expired) AS ttl_expired FROM cwan_flow_logs_edge WHERE year = '2026' AND month = '10' AND day IN ('29', '30') AND (packets_lost_no_route > 0 OR packets_lost_blackhole > 0 OR packets_lost_mtu_exceeded > 0 OR packets_lost_ttl_expired > 0) GROUP BY srcaddr, dstaddr, dst_attachment_type ORDER BY no_route + blackhole + mtu_exceeded + ttl_expired DESC;

The query returns the following:

srcaddr | dstaddr | dst_attachment_type | no_route | blackhole | mtu_exceeded | ttl_expired 10.1.0.5 | 10.99.0.10 | drop:no-route | 150 | 0 | 0 | 0 10.1.0.5 | 10.98.0.10 | drop:blackhole | 0 | 120 | 0 | 0 10.1.0.5 | 10.3.0.141 | vpc | 0 | 0 | 0 | 30

Because – also appears in NODATA and INCOMPLETEDATA records, filter on the drop: values to list only dropped destinations:

SELECT dstaddr, dst_attachment_type, src_segment_name, sum(packets) AS dropped_packets, count(*) AS records FROM cwan_flow_logs_edge WHERE year = '2026' AND month = '10' AND day IN ('29', '30') AND dst_attachment_type LIKE 'drop:%' GROUP BY dstaddr, dst_attachment_type, src_segment_name ORDER BY dropped_packets DESC;

The query returns the following:

dstaddr | dst_attachment_type | src_segment_name | dropped_packets | records 10.99.0.10 | drop:no-route | dev | 150 | 25 10.98.0.10 | drop:blackhole | dev | 120 | 23

The following figure shows this query in the Athena query editor.

Figure 4: Destinations that AWS Cloud WAN dropped traffic to, by drop reason.

Traffic through service insertion

With a network function group and a send-via segment action, network_function_group_attachment_ids holds the inspection attachment IDs. For example, in a core network where a send-via action sends traffic between dev and prod through an inspection VPC, the following query lists the inspected flows:

SELECT cwan_attachment_id, flow_direction, srcaddr, dstaddr, protocol, src_segment_name, dst_segment_name, src_attachment_type, dst_attachment_type, cwan_pair_attachment_id, network_function_group_attachment_ids, sum(packets) AS packets, sum(bytes) AS bytes, count(*) AS records FROM cwan_flow_logs_edge WHERE network_function_group_attachment_ids <> '-' AND year = '2026' AND month = '11' AND day = '02' GROUP BY 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11 ORDER BY packets DESC;

The first four rows, with selected columns, show each inspected flow twice: ingress at the source attachment and egress at the destination attachment. Both records carry the inspection attachment. In the full output, cwan_pair_attachment_id names the other VPC attachment, not the inspection attachment.

cwan_attachment_id | flow_direction | network_function_group_attachment_ids attachment-0d1d1d1d1d1d1d1d1 | ingress | attachment-0e1e1e1e1e1e1e1e1 attachment-0d2d2d2d2d2d2d2d2 | ingress | attachment-0e1e1e1e1e1e1e1e1 attachment-0d2d2d2d2d2d2d2d2 | egress | attachment-0e1e1e1e1e1e1e1e1 attachment-0d1d1d1d1d1d1d1d1 | egress | attachment-0e1e1e1e1e1e1e1e1

AWS Cloud WAN logs inspected traffic at the source and destination attachments, not at the inspection attachment, so the ingress filter in the earlier queries still counts each inspected flow once. The field can hold more than one attachment ID, separated by commas. To match one of them, use contains(split(network_function_group_attachment_ids, ','), 'attachment-0e1e1e1e1e1e1e1e1').

Query with Amazon CloudWatch Logs Insights

For the core network flow log in CloudWatch Logs, the following query parses the default format, filters on ingress, and finds the top talkers:

parse @message "* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *" as version, resource_type, account_id, core_network_id, cwan_attachment_id, cwan_pair_attachment_id, src_account_id, dst_account_id, src_vpc_id, dst_vpc_id, src_subnet_id, dst_subnet_id, src_eni, dst_eni, src_az_id, dst_az_id, srcaddr, dstaddr, srcport, dstport, protocol, packets, bytes, start, end, log_status, type, tcp_flags, flow_direction, lost_no_route, lost_blackhole, lost_mtu_exceeded, lost_ttl_expired, src_region, dst_region, src_segment, dst_segment, pkt_src_aws_service, pkt_dst_aws_service, nfg_attachment_ids, src_attachment_type, dst_attachment_type | filter flow_direction = "ingress" | stats sum(bytes) as total_bytes, sum(packets) as total_packets by srcaddr, dstaddr, cwan_attachment_id | sort total_bytes desc | limit 10

The first row is a cross-Region flow from us-west-2:

srcaddr | dstaddr | cwan_attachment_id | total_bytes | total_packets 10.2.0.127 | 10.3.0.141 | attachment-0bbbbbbbbbbbbbbb2 | 826787673 | 102825 10.3.0.141 | 10.2.0.127 | attachment-0ccccccccccccccc3 | 3356190 | 55726 10.3.0.141 | 10.1.0.5 | attachment-0ccccccccccccccc3 | 1432035 | 16803 10.1.0.5 | 10.3.0.141 | attachment-0aaaaaaaaaaaaaaa1 | 824092 | 10111 10.1.0.5 | 10.2.0.127 | attachment-0aaaaaaaaaaaaaaa1 | 277620 | 3305 10.1.0.5 | 10.99.0.10 | attachment-0aaaaaaaaaaaaaaa1 | 1680 | 20 10.1.0.5 | 10.98.0.10 | attachment-0aaaaaaaaaaaaaaa1 | 1680 | 20

The following figure shows the same query in the CloudWatch Logs Insights console. Because the query runs against the core network log group, it covers every attachment. The top two rows are the cross-Region flow between VPC B (us-west-2) and VPC C (us-east-1), one row per direction. The last two rows are the dropped traffic to 10.99.0.10 and 10.98.0.10.

Figure 5: Top talkers by bytes in CloudWatch Logs Insights.

Things to know

Keep the following in mind:

• Flow logs are immutable. To change one, create a replacement, then delete the old one. AWS Cloud WAN rejects a flow log with the same resource, destination, and log format as an existing one with FlowLogAlreadyExists. A different format for the same resource and destination is accepted.
• Fixed options. The interval is 1 minute, and there’s no traffic-type filter. Custom formats take AWS Cloud WAN fields only, and Amazon S3 delivery supports plain text and Parquet.
• Cross-account data. Records for other accounts’ attachments, including their account and VPC IDs, go to the core network owner’s destination. Limit access when those accounts belong to another organization or to teams that shouldn’t see each other’s traffic. To do so, use S3 bucket policies, CloudWatch Logs resource policies, or IAM policies.
• Drops in an inspection VPC aren’t marked as drops. If traffic reaches the inspection attachment and doesn’t come back, the source attachment’s record shows the inspection attachment as cwan-pair-attachment-id. This happens, for example, when your firewall drops the traffic. The record has no drop: value, the packets-lost-* counters stay 0, and no record appears at the destination attachment. To find these drops, use your firewall’s own logs, such as AWS Network Firewall alert and flow logs. You can also use VPC Flow Logs on the inspection VPC’s appliance interfaces.

Cleanup

If you no longer need the resources from this walkthrough, delete the flow logs, then the destinations and the IAM role. If you reused an existing bucket, skip the delete-bucket command:

aws ec2 delete-flow-logs --region us-west-2 \ --flow-log-ids fl-0aaaaaaaaaaaaaaa1 fl-0bbbbbbbbbbbbbbb2 fl-0ccccccccccccccc3 fl-0ddddddddddddddd4 aws logs delete-log-group --log-group-name my-cloud-wan-flow-logs --region us-west-2 aws s3 rm s3://amzn-s3-demo-bucket/edge/ --recursive aws s3 rm s3://amzn-s3-demo-bucket/attachment/ --recursive aws s3api delete-bucket --bucket amzn-s3-demo-bucket --region us-west-2 aws iam delete-role-policy --role-name CloudWanFlowLogsDelivery --policy-name WriteFlowLogs aws iam delete-role --role-name CloudWanFlowLogsDelivery

If you created the Athena table, drop it:

DROP TABLE IF EXISTS cwan_flow_logs_edge;

Conclusion

In this post, you created AWS Cloud WAN Flow Logs at three scopes and used the Region, segment, and drop fields to analyze cross-segment traffic, cross-Region traffic, and drops. You no longer need to turn on VPC Flow Logs in every VPC and correlate records across accounts. From the account that owns your core network, you get one view of your global network to find routing issues and plan for cross-Region traffic.

To get started and check Region availability, refer to the AWS Cloud WAN User Guide. If you have questions or feedback, leave a comment.

Further reading

To learn more, refer to the following resources:

• Logging IP traffic using VPC Flow Logs covers destinations and permissions.
• Querying Amazon VPC flow logs describes more table options.
• CloudWatch Logs Insights query syntax lists the query commands.
• Understand your network traffic trends using AWS Transit Gateway Flow Logs shows similar analysis for transit gateways.

About the author