This chapter covers Cloud Intrusion Detection Systems (IDS) in Google Cloud, a critical security service for monitoring network traffic and detecting threats. For the ACE exam, IDS-related topics appear in approximately 5-7% of questions, primarily within Domain 5 (Security) and Objective 5.2 (Implement network security controls). You will learn how Cloud IDS works, its components, configuration steps, and how it differs from other security tools like firewall rules and Cloud Armor. Mastery of this topic ensures you can design secure VPC networks and respond to exam scenarios involving threat detection.
Jump to a section
Imagine a secure office building with a security guard stationed at the front desk. The guard's job is to watch everyone who enters and exits, but crucially, the guard does NOT block anyone from entering. Instead, the guard writes down every suspicious event in a logbook—someone trying the back door, a person wearing a mask, or a visitor who doesn't have a badge. The guard then periodically reports these events to the building manager. This is exactly how a Cloud IDS works. It sits in the network path (often using packet mirroring or flow logs) and inspects traffic without blocking it. It logs suspicious patterns—known attack signatures, anomalies in traffic volume, or policy violations—and sends alerts to a security information and event management (SIEM) system or a monitoring dashboard. Just as the guard cannot physically stop a person from entering (that would be an intrusion prevention system, IPS), a Cloud IDS is passive. It observes, records, and alerts. The 'logbook' in Google Cloud is typically Cloud Logging, where IDS alerts are stored. The 'building manager' is the security operations team that reviews the logs and decides on a response, such as updating firewall rules or isolating a compromised instance. The key mechanistic parallel: the guard does not have the authority to lock doors based on suspicion—only to document and escalate. Similarly, Cloud IDS does not modify firewall rules or block traffic; it only generates alerts. This distinction is critical for the ACE exam, as questions often test whether you know IDS is passive versus IPS which is active.
What is Cloud IDS and Why Does It Exist?
Cloud Intrusion Detection System (IDS) is a Google Cloud managed service that monitors network traffic for malicious activity, policy violations, and known attack patterns. It is deployed inline or out-of-band (via packet mirroring) and inspects traffic at layers 4-7 of the OSI model. The primary purpose is to provide visibility into potential threats without impacting network performance, as IDS operates passively—it does not block traffic, only alerts.
On the ACE exam, you must understand that Cloud IDS is a passive monitoring tool. It does not replace firewall rules or Cloud Armor (which are preventive controls). Instead, it complements them by detecting attacks that bypass perimeter defenses, such as zero-day exploits, SQL injection attempts, or command-and-control traffic.
How Cloud IDS Works Internally
Cloud IDS uses packet mirroring to copy traffic from a VPC subnet to the IDS appliance. The IDS endpoint is a Google-managed virtual machine running a threat detection engine (e.g., Snort or Suricata-based rules). The step-by-step flow:
Traffic Mirroring: A packet mirroring policy is created in the VPC, specifying the source subnet (where traffic originates) and the destination (the IDS endpoint). The mirroring copies all packets (ingress and egress) from the source to the IDS, but the original traffic continues unaffected.
Packet Inspection: The IDS endpoint receives the mirrored packets and reassembles them into application-layer data. It then applies a set of signatures (predefined patterns of known attacks) and anomaly detection algorithms (e.g., protocol violations, unusual payload sizes).
Alert Generation: When a match is found, the IDS generates an alert. Alerts are logged to Cloud Logging and can be forwarded to Pub/Sub for further processing (e.g., triggering a Cloud Function to update firewall rules).
No Traffic Blocking: Critically, the IDS never modifies or drops the original traffic. This is the key difference from an Intrusion Prevention System (IPS).
Key Components, Values, Defaults, and Timers
Packet Mirroring Policy: Must be attached to a VPC subnet. The policy defines a source subnet (or specific VM instances) and a destination (the IDS endpoint). A single VPC can have up to 5 mirroring policies.
IDS Endpoint: A zonal resource. You must create a Cloud IDS endpoint in the same region as the subnet you want to monitor. The endpoint is a managed instance group that auto-scales based on traffic volume.
Threat Intelligence: Cloud IDS includes built-in rules from Talos (Cisco) and Google's Threat Intelligence. You cannot customize signatures directly; instead, you can enable or disable severity levels (HIGH, MEDIUM, LOW).
Alert Severity: Each alert has a severity: CRITICAL, HIGH, MEDIUM, LOW, INFO. The exam may ask which severity indicates a confirmed exploit (CRITICAL) versus a policy violation (MEDIUM).
Latency: Packet mirroring adds negligible latency (typically <1 ms) because it is a copy operation.
Pricing: Billed per GB of mirrored traffic. There is no upfront cost.
Configuration and Verification Commands
To deploy Cloud IDS, you use the Google Cloud Console, gcloud CLI, or Terraform. Key gcloud commands:
# Create an IDS endpoint in a specific zone
gcloud ids endpoints create my-ids-endpoint \
--zone=us-central1-a \
--network=my-vpc \
--severity=HIGH
# Create a packet mirroring policy
gcloud compute packet-mirrorings create my-mirror \
--region=us-central1 \
--source-subnetworks=my-subnet \
--collector-ilb=my-ids-ilb
# View IDS alerts
gcloud logging read "resource.type=ids.googleapis.com/Endpoint"
# List IDS endpoints
gcloud ids endpoints listNote: The --severity flag in the endpoint creation sets the minimum severity level for alerts. For example, HIGH means only HIGH and CRITICAL alerts are generated, filtering out LOW and MEDIUM.
Interaction with Related Technologies
VPC Firewall Rules: IDS does not replace firewall rules. Firewall rules are stateless or stateful and block traffic based on IP/port/protocol. IDS inspects the payload and can detect attacks that use allowed ports (e.g., SQL injection on port 443).
Cloud Armor: Cloud Armor is a web application firewall (WAF) that blocks malicious requests at the edge (Google Cloud Load Balancer). It is a preventive control. IDS is a detective control for internal traffic. They are complementary.
Security Command Center: IDS alerts are automatically ingested into Security Command Center (SCC) as findings. SCC provides a unified dashboard for all security threats.
Chronicle (SIEM): IDS logs can be exported to Chronicle for advanced analytics and correlation.
Performance and Scaling
Cloud IDS endpoints auto-scale based on the volume of mirrored traffic. The maximum throughput per endpoint is approximately 10 Gbps. For higher throughput, you can create multiple endpoints and distribute mirroring policies. The service is regional; you cannot monitor a subnet in one region with an endpoint in another.
Limitations
No TLS Inspection: Cloud IDS cannot inspect encrypted traffic (HTTPS) unless you use a proxy that terminates TLS. The exam may test this: IDS inspects packets at the network layer; if traffic is encrypted, it cannot see the payload.
No Custom Rules: You cannot write your own signatures. You rely on Google-managed rules. For custom detection, you must use other tools like Packet Mirroring + third-party IDS.
Only for VPC Traffic: IDS does not monitor traffic outside your VPC (e.g., on-premises via Cloud VPN unless mirrored).
Exam-First Summary
For the ACE exam, remember:
Cloud IDS is passive (detect only, no block).
It uses packet mirroring to copy traffic.
Alerts go to Cloud Logging and Security Command Center.
You cannot customize signatures.
Minimum severity can be set (HIGH, MEDIUM, etc.).
Does not inspect HTTPS without TLS termination.
Complements firewall rules and Cloud Armor.
Enable required APIs
Before using Cloud IDS, you must enable the IDS API and the Compute Engine API. In the Google Cloud Console, go to APIs & Services > Library and search for 'Cloud IDS API'. Enable it. Also ensure that the Compute Engine API is enabled (it usually is by default). This step is often a prerequisite in exam scenarios where the user first needs to enable APIs before creating resources.
Create an IDS endpoint
Navigate to the IDS page in the console or use gcloud to create an endpoint. Specify the zone, VPC network, and minimum severity level (e.g., HIGH). The endpoint is a zonal resource; choose a zone where your target subnet resides. The endpoint will be a managed instance group that receives mirrored traffic. This step creates the detection engine that will process packets.
Configure packet mirroring
Create a packet mirroring policy that specifies which traffic to mirror. You can mirror all traffic from a subnet or from specific VM instances. The policy must reference a collector internal load balancer (ILB) that points to the IDS endpoint. The ILB is automatically created when you create the endpoint. The mirroring policy is regional and must be in the same region as the endpoint.
Verify IDS is receiving traffic
After a few minutes, check the IDS endpoint's metrics in Cloud Monitoring. Look for 'Mirrored Bytes' to confirm traffic is being copied. You can also generate test traffic using a known attack pattern (e.g., a simple ping sweep) to verify alerts appear in Cloud Logging. This step ensures the setup is working correctly.
Review and respond to alerts
Alerts appear in Cloud Logging with the resource type 'ids.googleapis.com/Endpoint'. You can set up log-based metrics or export logs to Pub/Sub for automated response. For example, a Cloud Function can read Pub/Sub messages and update firewall rules to block the offending IP. However, note that IDS itself does not block traffic; any response must be implemented separately.
Enterprise Scenario 1: E-commerce Platform Protecting Against SQL Injection
A large e-commerce company runs its web application on Google Cloud with a public-facing HTTP load balancer and backend VM instances in a VPC. They have Cloud Armor configured to block common web attacks, but they want deeper inspection of traffic that reaches the backend (e.g., internal API calls between microservices). They deploy Cloud IDS on the subnet hosting the backend VMs. The IDS detects SQL injection attempts that bypassed the WAF (because the WAF only inspects HTTP headers, not the body of internal requests). The security team receives alerts in Security Command Center and manually investigates. In production, they set the severity to MEDIUM to catch policy violations like unexpected database queries. Performance: the IDS endpoint auto-scales to handle up to 10 Gbps of mirrored traffic; their peak traffic is 3 Gbps, so no issues. Misconfiguration: they initially forgot to enable the IDS API, causing the endpoint creation to fail. After enabling, they also had to ensure the packet mirroring policy's source subnet matched the correct region.
Enterprise Scenario 2: Financial Services Monitoring for C2 Traffic
A bank uses Google Cloud for a trading application. They have strict compliance requirements to monitor for command-and-control (C2) traffic. They deploy Cloud IDS on all VPC subnets that handle sensitive data. The IDS detects outbound connections to known malicious IP addresses (using Talos threat intelligence). Alerts are sent to a SIEM (Chronicle) via Pub/Sub. The bank also uses the IDS to detect protocol anomalies, such as SSH traffic on non-standard ports. Common pitfall: they tried to use IDS to inspect HTTPS traffic, but it failed because the traffic was encrypted. They had to deploy a reverse proxy that terminates TLS before mirroring. Scale: they have 20 subnets across 3 regions, each with its own IDS endpoint. They use a single packet mirroring policy per subnet. The total mirrored traffic is 50 Gbps, requiring 5 endpoints per region (since each endpoint handles ~10 Gbps).
Enterprise Scenario 3: Healthcare Provider Detecting Data Exfiltration
A healthcare provider stores patient records in Cloud SQL and Compute Engine. They need to detect unauthorized data transfers. They deploy Cloud IDS on the subnet containing the application servers. The IDS detects large outbound payloads that match patterns of data exfiltration (e.g., sudden high volume of traffic to an external IP). The security team receives a CRITICAL alert and isolates the VM using a Cloud Function that adds a firewall rule to block the VM's outbound traffic. However, they learned that IDS only alerts; the Cloud Function implements the blocking. This architecture is common in exam scenarios: IDS + Cloud Functions + Firewall Rules = automated response. Misconfiguration: they set the minimum severity to CRITICAL, but some exfiltration attempts were flagged as HIGH, so they missed them. They later changed to MEDIUM.
What the ACE Exam Tests on Cloud IDS (Objective 5.2)
The ACE exam expects you to understand the following specific points about Cloud IDS:
Passive vs. Active: IDS is passive—it does not block traffic. IPS is active. Exam questions will present scenarios where a candidate needs to choose between IDS and IPS. The correct answer is IDS if the requirement is 'detect but not block'.
Packet Mirroring: You must know that IDS uses packet mirroring to copy traffic. The mirroring policy is attached to a subnet or VM, and the destination is the IDS endpoint via an internal load balancer.
Alert Severity: The exam tests the severity levels: CRITICAL, HIGH, MEDIUM, LOW, INFO. A common question: 'Which severity indicates a confirmed exploit?' Answer: CRITICAL.
Integration with Security Command Center: IDS alerts automatically appear as findings in SCC. You may be asked where to view all security threats in one place—the answer is SCC.
Encrypted Traffic: IDS cannot inspect HTTPS traffic unless TLS is terminated. This is a frequent trap: candidates assume IDS can inspect all traffic, but it operates at the packet level.
Common Wrong Answers and Why Candidates Choose Them
'Cloud IDS blocks malicious traffic': This is the most common mistake. Candidates confuse IDS with IPS (Cloud Armor or firewall rules). The exam will explicitly say 'detect' vs 'prevent'.
'You can write custom signatures': Many candidates assume they can add custom rules, but Cloud IDS is a managed service with predefined rules. Customization is not supported; for custom rules, you would use a third-party IDS on a VM.
'IDS inspects HTTPS traffic': Because HTTPS is encrypted, IDS sees only encrypted packets. The exam may present a scenario where the requirement is to inspect HTTPS payloads; the correct answer would involve a proxy that terminates TLS.
'Packet mirroring is done at the VM level only': Mirroring can be at the subnet or VM level. The exam may test that you can mirror a whole subnet or individual instances.
Specific Numbers and Terms That Appear on the Exam
Maximum throughput per endpoint: 10 Gbps.
Maximum packet mirroring policies per VPC: 5.
Severity levels: CRITICAL, HIGH, MEDIUM, LOW, INFO. The default minimum severity is LOW.
Resource type for alerts: ids.googleapis.com/Endpoint.
Command to create endpoint: gcloud ids endpoints create.
Command to list endpoints: gcloud ids endpoints list.
Edge Cases and Exceptions
Cross-region mirroring: Not supported. The endpoint must be in the same region as the mirrored subnet.
Multiple endpoints in one VPC: Allowed, but each endpoint is independent.
Mirroring to a different VPC: Not supported; the collector ILB must be in the same VPC.
How to Eliminate Wrong Answers
When you see a question about network security monitoring, ask: 'Does the requirement say block or detect?' If it says detect, choose IDS. If it says block, choose IPS or firewall. If the question mentions encrypted traffic, look for an option involving a proxy. If it mentions custom rules, look for a third-party solution. By understanding the underlying mechanism (passive copy + alert), you can eliminate any answer that implies active intervention.
Cloud IDS is a passive intrusion detection system that uses packet mirroring to copy traffic for analysis.
It does not block traffic; it only generates alerts in Cloud Logging and Security Command Center.
IDS endpoints are zonal resources with a maximum throughput of ~10 Gbps each.
You cannot add custom signatures; the service uses Google-managed threat intelligence.
To inspect HTTPS traffic, you must terminate TLS before mirroring.
Packet mirroring policies are regional and limited to 5 per VPC.
The minimum severity level for alerts can be set (CRITICAL, HIGH, MEDIUM, LOW, INFO).
Cloud IDS complements firewall rules and Cloud Armor by detecting attacks that bypass perimeter controls.
These come up on the exam all the time. Here's how to tell them apart.
Cloud IDS
Passive detection only; does not block traffic
Inspects traffic at layers 4-7 using signatures and anomaly detection
Deployed within VPC using packet mirroring
Alerts are logged to Cloud Logging and SCC
Cannot inspect HTTPS without TLS termination
Cloud Armor
Active prevention; blocks malicious traffic at the edge
Inspects HTTP/HTTPS traffic at the application layer (WAF)
Deployed at the Google Cloud Load Balancer
Blocks requests based on rules (e.g., OWASP, rate limiting)
Can inspect HTTPS because it terminates TLS at the load balancer
Mistake
Cloud IDS can block malicious traffic automatically.
Correct
Cloud IDS is a passive detector only. It does not block traffic. Blocking is done by firewall rules, Cloud Armor, or an IPS. The exam tests this distinction explicitly.
Mistake
You can add custom intrusion detection signatures to Cloud IDS.
Correct
Cloud IDS uses Google-managed signatures from Talos and Google Threat Intelligence. You cannot add custom signatures. For custom detection, you must use a self-managed IDS on a VM.
Mistake
Cloud IDS can inspect encrypted HTTPS traffic without additional configuration.
Correct
Cloud IDS inspects packets at layers 4-7, but if the payload is encrypted (TLS), it cannot see the plaintext. To inspect HTTPS, you must terminate TLS at a proxy and then mirror the decrypted traffic.
Mistake
Packet mirroring affects the performance of the original traffic.
Correct
Packet mirroring copies packets and sends them to the IDS endpoint. The original traffic is not delayed or modified. The copy operation is done at the hypervisor level with minimal latency (<1 ms).
Mistake
Cloud IDS is a global service that can monitor traffic across regions from a single endpoint.
Correct
Cloud IDS endpoints are zonal resources. A packet mirroring policy can only mirror traffic from subnets in the same region as the endpoint. You need separate endpoints per region.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Cloud IDS is a passive detection service that monitors internal VPC traffic for threats using packet mirroring. It does not block traffic. Cloud Armor is a web application firewall (WAF) that blocks malicious traffic at the edge (load balancer). Cloud Armor is active and can inspect HTTPS because it terminates TLS. On the exam, choose Cloud IDS for internal network monitoring and Cloud Armor for edge protection.
Yes, if you create a packet mirroring policy on that subnet, all traffic (including east-west) is mirrored to the IDS endpoint. However, the mirroring copies all packets, so you must ensure you have the capacity to handle the volume.
Cloud IDS alerts are automatically logged to Cloud Logging with resource type 'ids.googleapis.com/Endpoint'. You can also view them in Security Command Center under 'Findings'. To set up real-time notifications, export logs to Pub/Sub.
The IDS endpoint is a managed instance group that auto-heals. If an instance fails, a new one is created. Packet mirroring continues to copy traffic to the internal load balancer, which distributes it to healthy instances. There is no data loss, but alerts may be delayed during failover.
Yes, Cloud IDS supports Shared VPC. The IDS endpoint must be created in the host project, and packet mirroring policies can reference subnets in service projects. Ensure the necessary IAM permissions are granted (compute.packetMirrorings.create on the host project).
Yes, Cloud IDS inspects both IPv4 and IPv6 traffic. The packet mirroring policy copies all IP traffic regardless of version. However, the IDS endpoint must be in a subnet that supports IPv6 if you want to mirror IPv6 traffic.
Cloud IDS is billed per GB of mirrored traffic. There is no charge for the endpoint itself. Pricing varies by region; check the Google Cloud pricing page. For example, in us-central1, it is $0.008 per GB of mirrored data. There is no minimum commitment.
You've just covered Cloud Intrusion Detection System (IDS) — now see how well it sticks with free ACE practice questions. Full explanations included, no account needed.
Done with this chapter?