GCP Log Types Explained: Audit Logs, VPC Flow Logs, Firewall Logs, and Application Logs

Simple explanation

Think of your GCP project as a building with several different camera systems installed:

• Cloud Audit Logs are the entrance cameras. They record who came in, what they picked up, and what they changed. Admin Activity logs are the always-on cameras. Data Access logs are the cameras you choose to install in sensitive rooms.

• VPC Flow Logs are the motion sensors. They track movement between rooms, recording who went where and how much they were carrying.

• Firewall Rules Logging records which doors were tried and whether they opened, naming the specific door (rule) that was used.

• Application logs are the internal cameras. They record what people are doing once inside, from your code’s point of view.

No single camera covers every angle. If someone entered through a side door you had no camera on, the entrance footage alone will not show how they got in. You need multiple angles to reconstruct what happened.

Why one log source is never enough

Each log type covers a specific visibility plane:

• Control plane: Cloud Audit Logs record changes to your GCP resources and configuration. IAM changes, resource creation, API calls. This is the authoritative record of what was done to your environment at the API level.

• Network plane: VPC Flow Logs and Firewall Logs record what is happening at the network level. Which connections are being made, how much data is moving, and whether rules are working as intended.

• Workload plane: Application logs record what your code is doing. Authentication failures, errors, unusual data access patterns from inside the application itself.

Admin Activity logs capture configuration changes but not data reads. If someone is querying your BigQuery tables without modifying anything, that activity does not appear in Admin Activity logs. It only appears in Data Access logs, which are disabled by default for most services. VPC Flow Logs capture traffic patterns but cannot see which GCP API was called. Application logs record what your code does but cannot see direct GCP API calls made by an attacker who bypasses your application entirely.

Cloud Audit Logs

Cloud Audit Logs record API calls against GCP services. Every time someone creates a resource, modifies an IAM policy, reads data from Cloud Storage, or calls any GCP service API, that call can generate an audit log entry. The entry records the identity, the action, the resource, and the outcome.

Security question answered: Who called which API on which resource, and did it succeed?

There are four sub-types:

Admin Activity logs

Records configuration changes: creating resources, modifying IAM policy bindings, enabling services, deleting buckets. Always enabled by default. Retained for 400 days at no charge.

This is the non-negotiable baseline. Every GCP environment has these, and they cover every configuration change across all services. If a resource was created or deleted, or if an IAM policy was changed, Admin Activity logs have the record.

Example events: SetIamPolicy, CreateFirewallRule, DeleteBucket, CreateServiceAccount

Data Access logs

Records reads and writes of user data: reading a Cloud Storage object, querying a BigQuery table, accessing a Secret Manager secret version. Not enabled by default for most services. Retained for 30 days.

Data Access logs come in three sub-types, enabled separately per service: DATA_READ (reading user data), DATA_WRITE (writing user data), and ADMIN_READ (reading resource metadata such as listing buckets or checking IAM policies). Enable at minimum DATA_READ and DATA_WRITE for services that handle sensitive data. BigQuery is the only exception: Data Access logs are on by default for BigQuery.

Useful for: detecting data exfiltration, supporting compliance audits, tracking who accessed sensitive resources.

System Event logs

Records Google-initiated operations on your infrastructure: live VM migration, automatic scaling of managed instance groups, scheduled Cloud SQL maintenance. Always enabled. Retained for 400 days.

Useful for: operational troubleshooting. If a VM restarted unexpectedly, System Event logs confirm whether Google triggered the event and why. Less relevant for direct security detection.

Policy Denied logs

Records requests blocked by a VPC Service Controls perimeter. When a request comes from an untrusted context (wrong network, wrong project, or wrong access level), a Policy Denied entry is written automatically. Retained for 400 days.

Useful for: detecting access attempts from unexpected contexts, and debugging VPC-SC perimeters during dry-run mode before enforcement is switched on.

VPC Flow Logs

Records sampled network flows sent and received by VM network interfaces. Each record includes source and destination IP, port, protocol, bytes transferred, and whether the flow was accepted or denied. VPC Flow Logs are enabled at the subnet level. They are sampled, so they give statistical visibility rather than complete packet capture.

Security question answered: Which VMs are communicating with which IPs, on which ports, and how much data is moving?

Most useful for:

• Detecting unexpected outbound connections to unusual IP ranges
• Identifying large data transfers that could indicate exfiltration
• Spotting east-west traffic between VMs that should not be communicating
• Network security forensics and compliance requirements

Key limitation: Sampled, not full capture. Does not tell you which GCP API was called, only which IPs communicated and how much data moved. For understanding how subnets and network topology work in GCP, see VPC Networks Explained.

Firewall Rules Logging

Records every connection attempt that matches a firewall rule where logging has been enabled. Unlike VPC Flow Logs (which are sampled), Firewall Rules Logging records every matching connection. Each entry includes the rule name, disposition (ALLOWED or DENIED), source and destination IP, port, and protocol.

You enable logging per firewall rule, not per subnet. This lets you be selective: enable logging on high-risk rules (rules allowing ingress from the internet, rules allowing access to sensitive services) without paying for logging on every rule in the network.

Security question answered: Are specific firewall rules being triggered, and is traffic being allowed or denied as intended?

Most useful for:

• Confirming that deny rules are actually blocking traffic
• Auditing which external IPs are reaching a specific service
• Identifying unexpected traffic hitting an allow rule

Key limitation: Only records connections matching rules where logging is explicitly enabled. A firewall rule with no logging enabled generates no entries, even if traffic hits it constantly.

Workload and application logs

Logs generated by your own applications, containers, and services. These arrive in Cloud Logging from several sources:

• Cloud Run and App Engine: standard output (stdout/stderr) from containers is automatically collected. Structured JSON logs are parsed and queryable by individual field.

• GKE: node-level system logs and container logs are collected via the GKE logging agent when Cloud Logging is enabled on the cluster.

• Compute Engine: application and OS logs require the Cloud Ops Agent to be installed on the VM. Without it, application logs do not reach Cloud Logging automatically.

Security question answered: What is happening inside your application? Authentication failures, errors, unusual data access patterns from the application’s point of view.

Key limitation: Application logs record what your code does. An attacker calling the BigQuery API directly with stolen credentials will not appear in your application logs at all. They bypass your application entirely.

Other security-relevant log sources

• Cloud Load Balancing access logs: records HTTP requests with URL, status code, latency, and client IP. Useful for detecting scraping, scanning, and anomalous traffic patterns at the application layer.

• Cloud DNS logs: records DNS queries from VMs within your VPC. Useful for detecting communication with known malicious domains or unusual DNS query patterns that indicate malware or exfiltration via DNS tunnelling. See Cloud DNS Setup for how DNS is configured in GCP.

• Cloud NAT logs: records NAT translation events for VMs without external IPs. Useful for tracking outbound internet connections from private VMs that should not be calling out. See Cloud NAT for how this fits into the network architecture.

• Google Workspace audit logs: if your organisation uses Google Workspace, admin and user activity logs there are separate from GCP Cloud Audit Logs, but the same identities appear in both. Relevant when investigating credential compromise that spans both Workspace and GCP.

Log types comparison

Quick reference: what each log type records, where it is enabled, and what it does not cover.

How it works in practice

Real investigations almost always need more than one log source. Here is how the same attack scenario surfaces differently across log types:

• IAM role granted to a new identity → Admin Activity logs, as a SetIamPolicy call

• Service account reads BigQuery tables → Data Access logs (only if enabled for BigQuery)

• Unusual outbound connection to an external IP → VPC Flow Logs, as a flow record with destination IP and bytes transferred

• Blocked ingress attempt from the internet → Firewall Rules Logging, if logging is enabled on the matching rule

• Repeated failed logins in your application → application logs from Cloud Run, GKE, or Compute Engine

• DNS lookup to a suspicious domain → Cloud DNS logs

The attacker who exfiltrated data via an authorised GCP API call appears in Data Access logs. Their unusual source IP appears in VPC Flow Logs. The IAM change that gave them access appears in Admin Activity logs. To detect this, you need all three sources. To detect it automatically and in real time, you need alerts built on those log sources.

When to use each log type

Use Cloud Audit Logs when you need to know…

• Who changed an IAM policy, and when
• Whether a resource was created, modified, or deleted, and by which identity
• Which service accounts accessed a Cloud Storage bucket or BigQuery dataset (requires Data Access logs enabled)
• Whether a VPC Service Controls perimeter blocked a request
• Which credentials are being used to call your GCP services
• How to demonstrate access history to a compliance auditor

Use VPC Flow Logs when you need to know…

• Which VMs are communicating with which external IP addresses
• How much data is moving between your environment and the internet
• Whether VMs that should be isolated are actually communicating with each other
• Network-level evidence for a forensics investigation

Use Firewall Rules Logging when you need to know…

• Whether a specific deny rule is actually blocking traffic
• Which external IPs are hitting an allow rule for a public-facing service
• Whether a new firewall rule is producing the allow/deny behaviour you intended

Use application logs when you need to know…

• What errors your application is throwing and why
• Which users are failing authentication in your own auth system
• Application-specific data access patterns your code tracks directly
• Debugging a specific service using Logs Explorer

VPC Flow Logs vs Firewall Rules Logging

This is one of the most common points of confusion for beginners. Both involve network traffic, but they answer different questions and are enabled in different places.

Use VPC Flow Logs when you want broad visibility into traffic across a subnet. Use Firewall Rules Logging when you want to confirm that specific rules are being triggered. Enable both in environments where network visibility matters for security or compliance.

How to query across log types

All log types land in Cloud Logging and are queryable via Logs Explorer or the gcloud CLI. Each log type uses a distinct log name. Scope your queries by log name to search the right source precisely.

# Find recent Admin Activity audit log entries for a project
# Good starting point for any investigation: who changed what?
gcloud logging read \
  'logName="projects/my-app-prod/logs/cloudaudit.googleapis.com%2Factivity"' \
  --project=my-app-prod \
  --limit=20 \
  --format='table(timestamp,protoPayload.authenticationInfo.principalEmail,protoPayload.methodName,protoPayload.resourceName)'

# Query Policy Denied logs to see what VPC Service Controls is blocking
# Useful when debugging a new VPC-SC perimeter in dry-run mode
gcloud logging read \
  'logName="projects/my-app-prod/logs/cloudaudit.googleapis.com%2Fpolicy"
  AND protoPayload.status.code=7' \
  --project=my-app-prod \
  --limit=20 \
  --format='table(timestamp,protoPayload.authenticationInfo.principalEmail,protoPayload.resourceName,protoPayload.status.message)'

# Query Firewall Rules Logging for denied connections
# Useful for auditing which traffic your deny rules are actually blocking
gcloud logging read \
  'logName="projects/my-app-prod/logs/compute.googleapis.com%2Ffirewall"
  AND jsonPayload.disposition="DENIED"' \
  --project=my-app-prod \
  --limit=50 \
  --format='table(timestamp,jsonPayload.connection.src_ip,jsonPayload.connection.dest_port,jsonPayload.rule_details.reference)'

# Query VPC Flow Logs for outbound flows from VMs in a project
# Look for large flows that could indicate data exfiltration
gcloud logging read \
  'logName="projects/my-app-prod/logs/compute.googleapis.com%2Fvpc_flows"
  AND jsonPayload.reporter="SRC"' \
  --project=my-app-prod \
  --limit=20 \
  --format='table(timestamp,jsonPayload.connection.src_ip,jsonPayload.connection.dest_ip,jsonPayload.bytes_sent)'