Packet Mirroring and Flow Logs

Introduction

Google Cloud gives you two complementary network-observability primitives. VPC Flow Logs records metadata about every (sampled) connection — 5-tuple, byte counts, packet counts, RTT, AS path — and lands it in Cloud Logging. Packet Mirroring clones the full packet payload (header + body, ingress + egress) of selected VMs and forwards each copy to a collector sitting behind an Internal TCP/UDP Load Balancer, where a third-party IDS or a Cloud IDS endpoint can inspect it. One tool tells you "who talked to whom and how much"; the other tells you "what was inside the conversation". A PCNE-grade design almost always uses both — Flow Logs for cost-cheap, always-on connectivity auditing, and Packet Mirroring for targeted deep packet inspection on tiers that justify the bandwidth and storage cost.

For the exam, the trap-laden territory sits in three places: the decryption boundary (Packet Mirroring sees ciphertext on TLS-encrypted flows, so HTTPS inspection requires TLS termination upstream of the mirror source), the firewall logging exclusion (a default default-deny-ingress rule emits zero log entries unless its --enable-logging flag is explicitly set), and the NCC + mirroring caveat (mirroring traffic cannot cross VPC peering or NCC VPC Spoke peering — collector and producer must share a VPC network). This study note walks through every gcloud command, API field, log schema entry, and BigQuery SQL pattern the exam can throw at you.

白話文解釋（Plain English Explanation）

The vocabulary across VPC Flow Logs, Packet Mirroring, Firewall Rules Logging, log sinks, and NCC integration is dense and easy to confuse. Three concrete analogies before we dive into commands.

Analogy 1: The Office Building's Three Surveillance Layers

Imagine a corporate headquarters with three independent surveillance systems running in parallel.

The lobby visitor logbook is VPC Flow Logs: every guest signs their name (source IP), the department they are visiting (destination IP/port), arrival and departure timestamps (start/end), how many bags they carried (bytes/packets), and whether they came in through the front door or the parking garage (ingress/egress reporter). The logbook is cheap to keep and easy to query — "show me all visits to the executive floor this week" — but it never tells you what was inside the bags. You can also dial the logbook's sampling rate (record every 10th visitor instead of all of them) and its aggregation interval (consolidate multiple visits by the same person within a 5-second window into one entry).

The mail-room X-ray machine is Packet Mirroring: every parcel routed through certain departments (tagged subnets, specific VMs, or instances with prod-web network tags) gets duplicated, with one copy continuing to its real destination and the other copy fed onto an X-ray belt parallel to the main flow. The X-ray belt terminates at an Internal Load Balancer that distributes the parcels across multiple inspectors (the collector backend instance group). Crucially, this X-ray cannot see through lead-lined boxes — TLS-encrypted traffic remains opaque unless you decrypt it before the parcel reaches the mirror tap.

The building's door alarms are Firewall Rules Logging: every door has a programmable alarm — but it only chirps if someone explicitly enabled logging on that door. The front door (allow-rule) might be silent because no one bothered to flip the switch; the side service door (deny-rule) might also be silent for the same reason. The result: you find out about an intrusion attempt only after the fact, and only on the doors where someone remembered to turn logging on.

Analogy 2: The Highway Patrol's Speed Trap vs. Dashcam

VPC Flow Logs is the highway patrol's automatic license-plate reader (ALPR) at every overpass — it sees every car (or every 10th car, depending on sample rate), records make/model/plate/direction/lane, and writes that into a database. Cheap, fast, queryable: "show me every car that passed Mile 42 between 03:00 and 04:00". It never sees the driver's face or what is in the trunk.

Packet Mirroring is the unmarked patrol car following a specific truck, recording high-definition dashcam footage of everything the truck does for the next 50 miles, including conversations with the driver picked up by a directional microphone. Far more detail, far more bandwidth, far more storage cost. You only assign unmarked cars to trucks that deserve the attention (PCI tier, regulated workloads, suspected compromise). The dashcam can only film what the unmarked car can see — if the truck's cargo container is locked (TLS-encrypted), the camera records the outside of the container, not the goods inside.

Firewall Rules Logging is the highway's toll-booth ticket printer. Each toll booth (firewall rule) can print a receipt for every car that passes through, but only if the booth operator switched the printer on. A toll booth with the printer off lets cars through without a paper trail, which means later forensic review has nothing to work with for that lane.

Analogy 3: The Hospital Patient Records Stack

VPC Flow Logs is the hospital admission ledger: name, date, ward, length of stay, billing code. It tells the auditor "yes, patient X was here on day Y, transferred from emergency to ICU on day Z, billed for 6 days". It does not contain medical notes.

Packet Mirroring is the continuous bedside vitals monitor wired into a secondary recording deck in the nurses' station. Every heartbeat, every breath, every word spoken in the room (if you have the audio bug) is preserved. The recording deck is sized for the volume — overloading it loses fidelity. The collector ILB is the patch panel that fans the feed out to multiple specialist reviewers (IDS appliance instances) without any single one becoming a bottleneck. Encrypted communications (TLS) are like a whispered conversation in the patient's native language no one in the recording booth understands — you have to bring a translator (TLS terminator) to the room before the recording, not after.

Firewall Rules Logging is the medication door's swipe log — useful when on, invisible when off. The hospital cannot prosecute drug-cabinet theft if it never enabled logging on that cabinet's lock.

Packet Mirroring Architecture — Producer, Tap, Collector

Packet Mirroring is a regional VPC-network feature that copies selected VM traffic and delivers the copy to a collector inside the same VPC network in the same region. There is no inter-region or inter-VPC magic. Three entities matter: the mirrored producer (what is being copied), the mirror tap (the VM's NIC-level hook that performs the copy), and the collector (where the copy is delivered).

The mirrored producer is selected, not configured

You do not "enable mirroring on a VM" directly. You create a mirroring policy that names the producer side via one of three selectors: a subnet (every VM in the subnet, present and future), an instance list, or a network tag list. Tags are the most flexible — adding pci-tier to a new VM auto-enrolls it into the policy. You can additionally filter the mirrored traffic by IP CIDR, protocol (tcp, udp, icmp, esp), and direction (INGRESS, EGRESS, BOTH).

The collector must be an Internal TCP/UDP Load Balancer

The collector is not a single VM. It is an Internal TCP/UDP Load Balancer with the is_mirroring_collector=true flag set on its forwarding rule. Backend instance groups run the IDS / DPI software (Cloud IDS endpoint, Palo Alto VM-Series, Suricata, Zeek). The ILB fans mirrored packets across the backend pool using a symmetric hash so the same flow always lands on the same inspector — critical for stateful protocols.

Mirroring is GRE-encapsulated inside Google's fabric

The cloned packet is encapsulated and delivered as a copy on the collector subnet. The collector backend receives the complete original packet (Ethernet headers, IP headers, payload) and inspects it. The original packet to the real destination is unaffected — same path, same timing.

gcloud workflow

gcloud compute forwarding-rules create ids-collector-fr \
  --region=us-central1 \
  --load-balancing-scheme=INTERNAL \
  --backend-service=ids-collector-bes \
  --is-mirroring-collector \
  --network=prod-vpc \
  --subnet=collector-subnet

gcloud compute packet-mirrorings create pci-mirror \
  --region=us-central1 \
  --network=prod-vpc \
  --collector-ilb=ids-collector-fr \
  --mirrored-tags=pci-tier \
  --filter-protocols=tcp,udp \
  --filter-direction=BOTH

Mirroring Policy Selection Logic — Subnet, Instance, Tag, and Filters

The policy is the central control plane object. Getting its selectors and filters right is the difference between a 10× cost overrun and a precise, audit-friendly mirror.

Subnet-scoped mirroring

Names a single subnet within the VPC; every VM in that subnet, present and future, becomes a producer. Best for "mirror everything in the PCI cardholder data subnet". The trap: shared-purpose subnets accidentally mirror non-PCI workloads that happen to share the address range.

Instance-scoped mirroring

Lists explicit Compute Engine instance URIs. Useful for targeted investigation ("mirror only these three VMs suspected of compromise") but does not scale; you must update the list every time the fleet changes. Not a fit for autoscaled instance groups.

Tag-scoped mirroring

Lists network tags. Most flexible: any VM whose --tags includes the listed value is auto-enrolled. Combine with an instance template that injects the tag on every new VM in an MIG (Managed Instance Group), and your autoscaled fleet stays covered with zero policy edits.

Filters refine the mirror

After the selector chooses producers, the filter decides which packets among the producers' traffic actually get copied. Filter fields:

• CIDRs: --filter-cidr-ranges=10.0.0.0/8,203.0.113.0/24 — only mirror packets whose source or destination matches.
• Protocols: --filter-protocols=tcp,udp,icmp,esp — drop the rest.
• Direction: --filter-direction=INGRESS|EGRESS|BOTH — defaults to BOTH.

Priority and conflict resolution

Multiple policies can apply to the same VM. Each policy has a priority (default 1000); the lowest numeric value wins for the conflicting fields, and all selected protocols/CIDRs are unioned. The collector ILB of the winning policy receives all mirrored packets, so design priorities deliberately if you have overlapping selectors.

Bandwidth Implications and Collector Sizing

Mirroring is not free on the producer side. Even though Google handles the clone in the network fabric, the cloned packets consume producer VM egress bandwidth quota and you pay for cross-zone traffic if the collector ILB's backends live in a different zone. Plan accordingly.

Doubling rule of thumb

A workload producing 3 Gbps of legitimate north-south traffic with --filter-direction=BOTH generates roughly 6 Gbps of mirrored traffic (ingress + egress each cloned). If the collector ILB backends are sized for 5 Gbps aggregate, packets are dropped at the inspector silently — the producer never sees an error, the inspector loses coverage, and your IDS misses attacks. Plan inspector capacity at ≥2× peak producer throughput.

Cross-zone egress cost

The collector ILB distributes mirrored packets across backends in (potentially) multiple zones. Cross-zone egress is billed at the standard Compute Engine rate. To minimize cost, deploy backend MIGs in the same zone as the bulk of producer VMs. For a multi-zone producer fleet, accept the cross-zone bill or run one collector ILB per zone with zone-scoped mirror policies (rare — usually the cost is acceptable).

Per-VM mirroring overhead

Mirroring is implemented at the host hypervisor, not inside the guest. There is no measurable CPU cost on the producer VM. However, the producer VM's egress bandwidth budget (see machine type bandwidth caps) does count the mirrored egress. A 16-vCPU n2-standard-16 VM with a 32 Gbps cap pushing 18 Gbps real egress + 18 Gbps mirrored egress will saturate the cap and slow the real traffic.

Collector backend autoscaling

Build the collector MIG with autoscaling on CPU > 60% or on a custom metric exposed by your IDS process. Sudden traffic spikes during incidents are exactly when you cannot afford the inspector to drop packets. Set the minimum replicas to ≥2 for zonal redundancy.

The Encrypted Traffic Decryption Boundary

This is the single most exam-relevant fact about Packet Mirroring: it does not decrypt anything. The collector sees what the wire sees, ciphertext included.

What the inspector observes on TLS flows

On a TLS-encrypted connection (HTTPS, gRPC-TLS, TLS-wrapped SMTP), the inspector reads:

• The TCP/IP headers (source, destination, ports) — fully visible.
• The TLS handshake: ClientHello SNI, ALPN list, supported cipher suites, JA3/JA3S fingerprint, certificate chain in ServerHello.
• The encrypted application data: opaque bytes only. No HTTP method, no URL path, no headers, no body.

You can still get a lot of signal from handshake metadata — JA3 fingerprinting identifies malware C2 toolkits whose TLS libraries produce distinctive cipher orderings even before any payload flows. But you cannot inspect a JSON request body or detect SQL injection in the URL with raw Packet Mirroring.

Where to terminate TLS for deep inspection

Three architectural options for putting plaintext on the mirror tap:

1. External HTTPS Load Balancer with SSL policy and managed cert — TLS terminates at the Google front end; mirror the backend VMs' traffic, which is plaintext HTTP between LB and backend (set the load-balancer-to-backend protocol to HTTP, or use HTTPS with an instance-side certificate you control).
2. Internal HTTPS Load Balancer with the same pattern.
3. VM-side TLS terminator (NGINX, Envoy) on a sidecar; mirror the post-decryption traffic between the terminator and the application container on the same VM (loopback or shared NIC).

Egress TLS to third parties

If your VMs initiate TLS to external services (API calls, webhook deliveries), there is no Google front end to do termination. The choices are (a) TLS-MITM proxy (Secure Web Proxy, Squid with bumping) that decrypts using a corporate CA bundle installed on the producer VMs, then mirror the proxy egress, or (b) accept that egress payloads are not inspectable and rely on JA3/SNI/destination IP for detection.

IPsec ESP traffic

Packet Mirroring captures esp packets if you include the protocol in the filter, but the contents are encrypted by the IPsec tunnel. Inspect post-decryption by mirroring traffic behind the VPN gateway, on the destination subnet.

VPC Flow Logs — Aggregation, Sampling, and Metadata Fields

VPC Flow Logs is a subnet-scoped logging feature that emits one record per flow aggregation window describing each TCP/UDP connection observed by a VM in the subnet. It is much cheaper than Packet Mirroring because it records metadata, not payload, but the trade-offs (aggregation interval, sample rate, metadata-annotation level) materially affect cost, latency, and signal quality.

Enable per-subnet

Flow Logs is enabled at the subnet level, not the VPC or VM level:

gcloud compute networks subnets update prod-web-subnet \
  --region=us-central1 \
  --enable-flow-logs \
  --logging-aggregation-interval=interval-5-sec \
  --logging-flow-sampling=0.5 \
  --logging-metadata=include-all

Aggregation interval

A flow's start and end timestamps are bucketed into a window before being logged. The available windows are 5 sec, 30 sec, 1 min, 5 min, 10 min, 15 min. The 5-sec window produces the most log entries (one per active flow per 5-sec slice), highest cost, best resolution; 15-min the cheapest and coarsest. For incident-response and SOC use cases, 5 sec or 30 sec is standard. For compliance-only retention, 5 min is acceptable.

Sample rate

A floating-point 0.0 – 1.0 controlling what fraction of flows the subnet logs. 1.0 = every flow; 0.5 = half; 0.1 = 10%. Sample rate scales the log volume linearly. Dev subnets: 0.1 is fine. Prod: 0.5 or 1.0 for full visibility. PCI cardholder data subnets: 1.0 — auditors expect complete records, no statistical sampling.

Metadata level

Three choices for what extra annotations to include:

• include-all — VM-instance name, VM-instance ID, project, zone, GKE pod/service/namespace if applicable, the Compute Engine instance group, autonomous-system info on the remote IP, the GCE region.
• exclude-all — bare 5-tuple, bytes, packets, start/end timestamps. Cheapest.
• custom — explicit field list (newer feature) for fine-grained cost control.

Key fields in a log entry

The log JSON contains (under jsonPayload):

• connection.src_ip, connection.dest_ip, connection.src_port, connection.dest_port, connection.protocol.
• src_instance (with vm_name, region, zone, project_id).
• dest_instance if both endpoints are inside your VPC.
• src_vpc / dest_vpc (network name, subnetwork).
• src_gke_details / dest_gke_details for GKE pods.
• bytes_sent, packets_sent, start_time, end_time.
• reporter — SRC or DEST indicating which side observed the flow.
• rtt_msec — measured RTT for TCP flows.
• dest_country / dest_continent — geolocation of the remote IP when external.

What VPC Flow Logs does not see

Flow Logs reports only allowed flows by default — anything dropped by a firewall rule is not in the flow-log stream. For dropped-packet visibility, you need Firewall Rules Logging (next section) or Firewall Insights (Network Intelligence Center).

Firewall Rules Logging — Logging Is Opt-In Per Rule

VPC firewall rules (and hierarchical firewall policies, network firewall policies) do not log by default. Each rule has its own --enable-logging flag, and forgetting it is a top-five operational pitfall.

Enabling per rule

gcloud compute firewall-rules update default-deny-ingress \
  --enable-logging \
  --logging-metadata=include-all

For hierarchical policies:

gcloud compute firewall-policies rules update 1000 \
  --firewall-policy=org-baseline \
  --organization=123456789 \
  --enable-logging

What firewall logs contain

The log entry includes:

• rule_details.reference — fully-qualified rule name.
• rule_details.action — ALLOW or DENY.
• rule_details.priority.
• disposition — ALLOWED or DENIED.
• connection — same 5-tuple as Flow Logs.
• src_instance / dest_instance where resolvable.
• instance.vm_name for the VM that observed the packet.

Logging cost-control patterns

Logging every connection on a chatty allow-internal rule is expensive and low-signal. Common patterns:

• Log only deny rules — high signal (intrusion attempts, misconfigured clients), low volume.
• Log the explicit allow rules for sensitive paths (PCI subnet ingress) — needed for compliance.
• Skip logging on chatty internal allow-all rules — accept that audit happens via Flow Logs instead.

How firewall logs and Flow Logs differ

Flow Logs sees connection-level metadata regardless of which rule allowed it. Firewall Rules Logging attributes packets to specific rule actions, including denies that Flow Logs never records. You generally enable Firewall Rules Logging on deny rules and rely on Flow Logs for accepted-flow audit.

Log Sinks to BigQuery — From Cloud Logging to Query Engine

Cloud Logging keeps flow logs and firewall logs for 30 days by default, with a configurable retention up to 3650 days but at progressively higher cost. For long-term retention, ad-hoc SQL analytics, dashboards, and SOC investigation tooling, the canonical pattern is to sink logs to BigQuery.

Create the sink

gcloud logging sinks create flow-logs-to-bq \
  bigquery.googleapis.com/projects/sec-ops/datasets/network_logs \
  --log-filter='resource.type="gce_subnetwork" AND logName=~"compute.googleapis.com%2Fvpc_flows"' \
  --use-partitioned-tables

The --use-partitioned-tables flag is critical: it creates date-partitioned tables (one logical table, daily partitions) which control storage cost via partition expiration and let queries restrict scan to a date range using _PARTITIONTIME.

Grant the sink writer

The sink command returns a writer service account (serviceAccount:[email protected]); grant it roles/bigquery.dataEditor on the destination dataset. Without this, the sink silently produces zero rows.

Multi-project / org sinks

For organization-wide collection, create the sink at the organization level with --include-children and the writer SA gains permissions across all child projects. Routes all VPC flow logs across the org to a single security BigQuery dataset — the canonical SOC architecture.

Partition expiration for cost

ALTER TABLE network_logs.compute_googleapis_com_vpc_flows
SET OPTIONS (partition_expiration_days = 365);

Auto-drops partitions older than 365 days. For PCI (1 year online + 1 year archive), pair this with Cloud Storage sink for the archive tier.

Common BigQuery SQL Queries — Top Talkers, Denied Connections, Egress Costs

Once flow logs land in BigQuery, a handful of canned queries cover 80% of SOC and FinOps use cases.

Query 1 — Top talkers by egress bytes (last 24h)

SELECT
  jsonPayload.src_instance.vm_name AS src_vm,
  jsonPayload.connection.dest_ip AS dest_ip,
  jsonPayload.dest_country AS dest_country,
  SUM(CAST(jsonPayload.bytes_sent AS INT64)) AS total_bytes
FROM `sec-ops.network_logs.compute_googleapis_com_vpc_flows_*`
WHERE _TABLE_SUFFIX BETWEEN
  FORMAT_DATE('%Y%m%d', DATE_SUB(CURRENT_DATE(), INTERVAL 1 DAY)) AND
  FORMAT_DATE('%Y%m%d', CURRENT_DATE())
GROUP BY src_vm, dest_ip, dest_country
ORDER BY total_bytes DESC
LIMIT 50;

Catches data exfiltration patterns, runaway analytics jobs, and unexpected cross-region replication.

Query 2 — Denied connection attempts by source IP

SELECT
  jsonPayload.connection.src_ip AS attacker_ip,
  jsonPayload.connection.dest_port AS targeted_port,
  COUNT(*) AS attempt_count
FROM `sec-ops.network_logs.compute_googleapis_com_firewall_*`
WHERE jsonPayload.disposition = 'DENIED'
  AND _PARTITIONTIME >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 6 HOUR)
GROUP BY attacker_ip, targeted_port
HAVING attempt_count > 100
ORDER BY attempt_count DESC;

Surfaces port-scan campaigns and misconfigured clients hammering a denied path.

Query 3 — Cross-region egress cost attribution

SELECT
  jsonPayload.src_instance.region AS src_region,
  jsonPayload.dest_instance.region AS dest_region,
  ROUND(SUM(CAST(jsonPayload.bytes_sent AS INT64)) / POW(1024, 3), 2) AS gib_sent
FROM `sec-ops.network_logs.compute_googleapis_com_vpc_flows_*`
WHERE jsonPayload.src_instance.region IS NOT NULL
  AND jsonPayload.dest_instance.region IS NOT NULL
  AND jsonPayload.src_instance.region != jsonPayload.dest_instance.region
  AND _TABLE_SUFFIX = FORMAT_DATE('%Y%m%d', CURRENT_DATE())
GROUP BY src_region, dest_region
ORDER BY gib_sent DESC;

FinOps gold — surfaces accidentally chatty cross-region replication that drives the largest line item on most GCP bills.

Query 4 — GKE pod-level traffic breakdown

SELECT
  jsonPayload.src_gke_details.cluster.cluster_name AS cluster,
  jsonPayload.src_gke_details.pod.pod_name AS pod,
  jsonPayload.connection.dest_ip AS dest_ip,
  SUM(CAST(jsonPayload.bytes_sent AS INT64)) AS bytes
FROM `sec-ops.network_logs.compute_googleapis_com_vpc_flows_*`
WHERE jsonPayload.src_gke_details IS NOT NULL
  AND _PARTITIONTIME >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 1 HOUR)
GROUP BY cluster, pod, dest_ip
ORDER BY bytes DESC
LIMIT 100;

Maps GKE workload egress to specific pods — invaluable when a pod is exfiltrating data or a misconfigured service is hammering an external API.

Query 5 — Long-lived flow correlation

SELECT
  jsonPayload.connection.src_ip,
  jsonPayload.connection.dest_ip,
  jsonPayload.connection.dest_port,
  TIMESTAMP_DIFF(MAX(TIMESTAMP(jsonPayload.end_time)),
                 MIN(TIMESTAMP(jsonPayload.start_time)), SECOND) AS duration_sec
FROM `sec-ops.network_logs.compute_googleapis_com_vpc_flows_*`
WHERE _PARTITIONTIME >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 24 HOUR)
GROUP BY 1, 2, 3
HAVING duration_sec > 3600
ORDER BY duration_sec DESC;

Surfaces persistent C2 callbacks, mismanaged SSH tunnels, and long-lived suspicious sessions.

Network Connectivity Center + Packet Mirroring Patterns

Network Connectivity Center (NCC) provides a managed hub-and-spoke topology with VPC Spokes, Hybrid Spokes (VPN/Interconnect), and Router Appliance Spokes. Packet Mirroring intersects NCC in two specific ways the exam tests.

Mirroring cannot cross the hub

A core constraint: Packet Mirroring policies and collectors must share a single VPC network. NCC's hub-and-spoke connects multiple VPCs but does not create a unified VPC. Two consequences:

1. You cannot place a collector ILB in the hub project and mirror producer traffic from spoke VPCs into it — mirroring would need to cross a peering, which it cannot.
2. Each spoke VPC needs its own collector ILB (and ideally its own Cloud IDS endpoint or third-party IDS instance).

Pattern A — Per-spoke inspection

Most common. Each spoke VPC runs its own Packet Mirroring policy and collector ILB. SOC consumes mirrored alerts from each inspector independently — usually by routing IDS Pub/Sub findings to a central topic. Cost scales linearly with spokes but isolation is clean.

Pattern B — Centralised inspection via NVA at the hub

For hub-and-spoke designs that require centralised inspection, the answer is not Packet Mirroring but traffic steering through a Network Virtual Appliance (NVA) at the hub. Spokes route traffic to the hub via NCC, the NVA inspects (inline, not mirrored), and forwards. This trades inline latency for centralised visibility — the opposite trade-off of Packet Mirroring.

Pattern C — Shared VPC consolidation

Best for organisations with many small workload projects: consolidate into a Shared VPC with one host project. The host project owns one mirror policy and one collector ILB; service projects' VMs sit in the host project's subnets and are mirrored automatically. The PCNE exam favours this pattern when the question mentions "minimise operational overhead" with mirrored inspection.

Pattern D — Cross-region SOC aggregation

For multi-region producer fleets, deploy one mirror policy + one collector ILB per region per VPC. Each inspector emits findings to a regional Pub/Sub topic, all of which fan into a single SOC BigQuery dataset via Pub/Sub-to-BigQuery Dataflow templates. The SOC dashboard runs cross-region SQL against the unified dataset.

Comparison Table — Mirroring vs. Flow Logs vs. Firewall Logs

Common PCNE Exam Scenarios

Scenario A — Compliance wants DPI on PCI subnet without latency

"PCI auditors require deep packet inspection on the cardholder data network." Answer: Packet Mirroring with tag selector pci-tier, filter tcp,udp, direction BOTH, into a collector ILB feeding a Cloud IDS endpoint. Out-of-band, zero added latency to production traffic.

Scenario B — Denied port-scan attempts invisible in Cloud Logging

"SOC reports no record of an obvious port-scan campaign in Cloud Logging." Answer: the default-deny is implicit and cannot log; add an explicit catch-all deny rule with --enable-logging at priority 65534. Now denies are captured.

Scenario C — Cross-VPC mirroring fails

"Three workload VPCs peered to a security VPC; mirror policies in workload VPCs target a collector ILB in the security VPC." Answer: mirroring cannot cross VPC peering or NCC VPC Spokes. Each producer VPC needs its own collector ILB, or migrate workloads into a Shared VPC.

Scenario D — Mirrored HTTPS traffic shows only ciphertext

"DPI engine sees encrypted blobs only." Answer: terminate TLS upstream (External HTTPS LB with managed cert) and mirror the post-decryption backend traffic, or run an instance-side TLS terminator (NGINX/Envoy) and mirror the local plaintext path.

Scenario E — Top-talker BigQuery query times out

"BigQuery SOC query against year-old flow logs runs for minutes." Answer: ensure the sink uses --use-partitioned-tables and filter _PARTITIONTIME or _TABLE_SUFFIX in the WHERE clause to scan a single day's partition rather than the full year.

Cost Anatomy

Three cost dimensions to manage:

1. VPC Flow Logs storage — Cloud Logging charges per-GB ingested above the monthly free tier (50 GiB/project). Levers: lower sample rate, coarser aggregation interval, exclude-all metadata on noisy subnets, log exclusions for chatty allow-rule flows.
2. Packet Mirroring — no direct mirror fee, but the collector ILB backend VMs, their cross-zone egress, and the IDS license/usage are billed normally. Lever: tightly scope producer selectors and use protocol/CIDR filters.
3. BigQuery storage + scan — log sinks generate steady ingest; partition expiration controls long-term storage. Levers: partition_expiration_days, materialised summary tables instead of raw scans, BI Engine for dashboards.

FAQs

Q: Does VPC Flow Logs capture denied traffic?

No. Flow Logs records only allowed flows. For denied-connection visibility, enable Firewall Rules Logging on explicit deny rules (the implicit default-deny cannot log — add an explicit catch-all at priority 65534 with --enable-logging).

Q: Can Packet Mirroring inspect HTTPS payloads?

Not on raw mirrored traffic — the inspector sees ciphertext only. Terminate TLS upstream of the mirror tap (External HTTPS Load Balancer with managed certificate, or an instance-side NGINX/Envoy terminator) and mirror the post-decryption segment.

Q: Can the collector ILB sit in a different VPC from the producer VMs?

No. Packet Mirroring policy and collector ILB must share the same VPC network and region. The constraint applies to VPC peering, Network Connectivity Center VPC Spokes, and Shared VPC service-project boundaries (host-project VPC is the shared substrate, so host + service projects in one Shared VPC do work).

Q: How does aggregation interval affect cost vs. resolution?

A 5-second aggregation interval is the default and produces the most log entries per connection (one per active window per flow), maximising fidelity at maximum cost. Coarser intervals (30s, 1m, 5m, 10m, 15m) reduce the number of entries per flow, lowering cost but obscuring sub-window timing detail. SOC/forensics use cases want 5–30 sec; archival/compliance can use 5 min.

Q: How do I write BigQuery queries efficiently against flow log sinks?

Always include a _PARTITIONTIME or _TABLE_SUFFIX predicate in the WHERE clause so the scan is restricted to one or a few daily partitions. Avoid SELECT * — flow log records are wide; pick only the columns you need. Cluster on jsonPayload.connection.dest_ip if denied-IP forensics is a frequent query.

Q: Can I mirror traffic between VMs in the same subnet (east-west)?

Yes. Packet Mirroring captures all traffic from selected producer VMs regardless of destination — same-subnet east-west, same-VPC cross-subnet, and egress to the internet are all mirrored.

Q: Does Packet Mirroring add latency to the original packet?

No. The clone takes a parallel path inside the host network fabric; the original packet continues to its real destination at full speed. Mirroring is fully out-of-band and adds zero latency to production traffic. Bandwidth, however, is consumed against the producer VM's egress cap.