VPC Flow Logs not capturing outbound traffic for subnet in observability setup

I’ve configured VPC Flow Logs for our production VPC to monitor network traffic patterns, but I’m noticing that outbound traffic from one specific subnet (10.240.15.0/24) isn’t being captured in the logs. Inbound traffic shows up fine, but outbound connections initiated from instances in this subnet are completely missing.

I’ve verified the flow log collector is active and the IAM service authorization exists. The subnet configuration looks identical to other subnets where logging works correctly. Here’s the flow log setup:


ibmcloud is flow-log-create my-vpc-flowlog \
  --target subnet-abc123 \
  --bucket my-logging-bucket \
  --active true

The collector status shows ‘active’ but only captures ingress traffic. Has anyone encountered direction-specific logging issues with VPC Flow Logs? I need to troubleshoot application connectivity and the missing outbound data is blocking our security analysis.

Update: I found the issue! The security groups were fine, but the problem was indeed with IAM permissions. Even though I had service-to-service authorization set up, the specific IAM policy for the flow log service account was missing the ‘writer’ role for the COS bucket.

I’ve seen this before - the flow log collector might be created with default direction settings. Check if your flow log has an implicit direction filter. By default, some older configurations only captured ingress traffic unless explicitly configured otherwise.

Can you verify the actual flow log configuration with:


ibmcloud is flow-log FLOW_LOG_ID --output json

Look for any ‘direction’ or ‘traffic_type’ fields in the output. If it’s set to ‘ingress’ only, that would explain why outbound traffic isn’t being captured.

Thanks for the suggestion. I checked the flow log details and there’s no explicit direction field shown in the output, which I assume means it should capture all traffic. The JSON output shows the collector is attached to the correct subnet and the bucket path is valid. Still no outbound traffic in the logs though.

I ran into something similar last month. In our case, the problem was that we had created the flow log collector before the subnet was fully provisioned with all its network interfaces. Try deleting and recreating the flow log collector for that specific subnet.

Before you do that, make sure all instances in the subnet have their network interfaces fully attached and in ‘available’ state. Use ibmcloud is subnet SUBNET_ID to check the attached network interfaces count matches your expectations.

Another thing to check - are there any security group rules or network ACLs on that subnet that might be dropping packets before they reach the flow log collection point? If outbound traffic is being blocked at the security group level, it won’t show up in flow logs because the packets never leave the virtual network interface.

Run a quick test by temporarily opening up all outbound rules and see if the logs start capturing. That would at least confirm whether it’s a security policy issue versus a flow log configuration problem.

Great that you identified the root cause! Let me provide a comprehensive solution for anyone facing similar VPC Flow Logs direction issues:

1. VPC Subnet Configuration Check: First, verify your subnet is properly attached to the VPC and has active network interfaces. Use:


ibmcloud is subnet SUBNET_ID --output json

Confirm the subnet status is ‘available’ and network_interfaces array is populated.

2. Flow Log Direction Settings: When creating flow logs in ic-2019, you need to ensure bidirectional capture. If your flow log was created with older CLI versions, recreate it with explicit parameters:


ibmcloud is flow-log-create my-vpc-flowlog \
  --target subnet-abc123 \
  --bucket my-logging-bucket \
  --active true

Note: The CLI defaults to all traffic, but verify with ibmcloud is flow-log FLOW_LOG_ID that no direction filters exist.

3. IAM Permissions for Logging (Critical): This is where your issue was. The flow log service needs proper authorization:

a) Service-to-service authorization:


ibmcloud iam authorization-policy-create is \
  cloud-object-storage Writer \
  --source-service-instance-id VPC_INSTANCE_ID \
  --target-service-instance-id COS_INSTANCE_ID

b) Verify the flow log service account has both Reader AND Writer roles on the COS bucket. Many setups only grant Reader, which allows the service to verify the bucket exists but not write log files.

c) Check bucket policies don’t have explicit deny rules for the flow log service principal.

4. Additional Troubleshooting:

  • Verify COS bucket is in the same region as your VPC
  • Check that the bucket path in flow log config doesn’t have trailing slashes
  • Ensure no network ACLs are blocking the logging service’s internal communication
  • Review Cloud Activity Tracker events for any authorization failures

5. Validation: After fixing IAM permissions, it can take 5-10 minutes for flow logs to start appearing. Monitor the COS bucket for new objects with naming pattern: `{account-id}{vpc-id}{subnet-id}_{timestamp}.gz The key takeaway: outbound traffic logging failures are almost always IAM-related when ingress works fine. The flow log collector needs full write access to persist both directions of traffic data.

Have you checked the IAM authorization between the flow log service and Cloud Object Storage? Even if the collector shows active, insufficient permissions can cause partial logging failures. The service needs both read and write access to the bucket.

Also verify that the subnet’s routing table doesn’t have any custom routes that might bypass flow log collection. Sometimes egress traffic routed through specific gateways can have logging gaps if the network path isn’t properly instrumented.