{"id":718,"date":"2026-04-15T03:51:15","date_gmt":"2026-04-15T03:51:15","guid":{"rendered":"https:\/\/www.devopsschool.com\/tutorials\/google-cloud-ids-tutorial-architecture-pricing-use-cases-and-hands-on-guide-for-networking\/"},"modified":"2026-04-15T03:51:15","modified_gmt":"2026-04-15T03:51:15","slug":"google-cloud-ids-tutorial-architecture-pricing-use-cases-and-hands-on-guide-for-networking","status":"publish","type":"post","link":"https:\/\/www.devopsschool.com\/tutorials\/google-cloud-ids-tutorial-architecture-pricing-use-cases-and-hands-on-guide-for-networking\/","title":{"rendered":"Google Cloud IDS Tutorial: Architecture, Pricing, Use Cases, and Hands-On Guide for Networking"},"content":{"rendered":"\n<h2 class=\"wp-block-heading\">Category<\/h2>\n\n\n\n<p>Networking<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">1. Introduction<\/h2>\n\n\n\n<p>Cloud IDS is Google Cloud\u2019s managed network intrusion detection service. It helps you detect suspicious activity and known threats in your Virtual Private Cloud (VPC) network traffic\u2014without you having to deploy, patch, and scale IDS appliances yourself.<\/p>\n\n\n\n<p>In simple terms: you mirror a copy of selected network traffic to Cloud IDS, and Cloud IDS analyzes that traffic and writes threat detections to Google Cloud Logging so your security and operations teams can investigate and respond.<\/p>\n\n\n\n<p>Technically, Cloud IDS works by integrating with <strong>VPC Packet Mirroring<\/strong>. You deploy a <strong>Cloud IDS endpoint<\/strong> (a regional managed resource) in your VPC network. Packet Mirroring then copies packets from chosen sources (VM NICs, GKE node NICs, etc.) to the endpoint for analysis. Detections are emitted as structured logs (and can be exported to SIEM\/SOAR tools).<\/p>\n\n\n\n<p><strong>What problem it solves:<\/strong> modern cloud networks change fast and generate high traffic volumes. Self-managed IDS is operationally heavy (capacity planning, tuning, signature updates, HA, patching). Cloud IDS provides a managed approach to network threat detection aligned with Google Cloud Networking primitives.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">2. What is Cloud IDS?<\/h2>\n\n\n\n<p><strong>Official purpose (high-level):<\/strong> Cloud IDS provides managed network intrusion detection for Google Cloud VPC environments by inspecting mirrored traffic and producing threat detections for investigation and response. (Verify exact wording in the official product overview: https:\/\/cloud.google.com\/intrusion-detection-system\/docs)<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Core capabilities<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Out-of-band traffic inspection (detect, not block):<\/strong> Cloud IDS analyzes a copy of traffic. It does not sit inline and does not prevent packets from reaching their destination.<\/li>\n<li><strong>Threat detection using managed signatures:<\/strong> Detects known exploit patterns, scanning behaviors, command-and-control indicators, and other suspicious traffic patterns based on the IDS engine\u2019s rules\/signatures (signature set and update behavior are managed by the service).<\/li>\n<li><strong>Centralized detections in Cloud Logging:<\/strong> Findings are written to Cloud Logging for searching, alerting, exporting, and retention control.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Major components<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Cloud IDS endpoint:<\/strong> A regional resource you create in a VPC network. It represents the inspection point that Packet Mirroring sends traffic to.<\/li>\n<li><strong>Packet Mirroring policy:<\/strong> A VPC configuration that selects:<\/li>\n<li>traffic sources (instances, subnets, tags)<\/li>\n<li>traffic direction (ingress\/egress)<\/li>\n<li>optional filters (CIDRs, protocols, ports)<\/li>\n<li>collector destination (Cloud IDS endpoint)<\/li>\n<li><strong>Cloud Logging:<\/strong> Stores threat detection logs and (typically) endpoint\/health logs. You can create log-based metrics, alerts, and sinks to export logs to BigQuery, Pub\/Sub, or Cloud Storage.<\/li>\n<li><strong>IAM + Audit Logs:<\/strong> Control and record who can create endpoints, configure mirroring, and view threat logs.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Service type<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Managed security service<\/strong> in the <strong>Google Cloud Networking<\/strong> ecosystem.<\/li>\n<li><strong>Control plane<\/strong>: Google-managed API and configuration.<\/li>\n<li><strong>Data plane<\/strong>: Mirrored traffic sent to the managed inspection endpoint.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Scope (regional\/global\/project)<\/h3>\n\n\n\n<p>Cloud IDS is <strong>project-scoped<\/strong> (resources live in a Google Cloud project) and the <strong>Cloud IDS endpoint is regional<\/strong>. Packet Mirroring is also regional in typical deployments, so you generally deploy <strong>one endpoint per region<\/strong> you want coverage in.<\/p>\n\n\n\n<blockquote>\n<p>If you need exact scope constraints (e.g., cross-region mirroring support), verify in the Cloud IDS and Packet Mirroring documentation.<\/p>\n<\/blockquote>\n\n\n\n<h3 class=\"wp-block-heading\">How it fits into the Google Cloud ecosystem<\/h3>\n\n\n\n<p>Cloud IDS complements other Google Cloud security and networking services:\n&#8211; <strong>VPC Packet Mirroring<\/strong> (traffic copy mechanism)\n&#8211; <strong>Cloud Logging<\/strong> (detections store and search)\n&#8211; <strong>Cloud Monitoring<\/strong> (operational visibility, alerting)\n&#8211; <strong>Security Command Center (SCC)<\/strong> and <strong>SIEM tooling<\/strong> (investigation and triage) \u2014 integration patterns often rely on log export; verify any direct connectors in official docs\n&#8211; <strong>Cloud Armor<\/strong> (L7\/WAF), <strong>Cloud NGFW \/ firewall policies<\/strong> (enforcement) \u2014 Cloud IDS focuses on detection, not blocking\n&#8211; <strong>VPC Flow Logs<\/strong> (metadata-based flow visibility) \u2014 Cloud IDS adds deep packet inspection on mirrored traffic<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">3. Why use Cloud IDS?<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Business reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Reduce security risk<\/strong>: detect malicious network activity early (scans, exploit attempts, lateral movement signals).<\/li>\n<li><strong>Lower operational overhead<\/strong>: avoid maintaining IDS appliances and signature update pipelines.<\/li>\n<li><strong>Faster time to value<\/strong>: deploy endpoints and start analyzing mirrored traffic quickly.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Technical reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Deep packet inspection on selected traffic<\/strong> (as opposed to metadata-only flow logs).<\/li>\n<li><strong>Flexible coverage<\/strong> using Packet Mirroring selectors (instances, subnets, tags) and filters.<\/li>\n<li><strong>Centralized detections<\/strong> in Cloud Logging with powerful search and export tooling.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Operational reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Managed scaling and availability<\/strong> (service-managed capacity behind the endpoint).<\/li>\n<li><strong>Standard Google Cloud operations model<\/strong>: IAM, audit logs, Cloud Logging, Monitoring.<\/li>\n<li><strong>Automatable<\/strong>: infrastructure as code around endpoints + mirroring policies (exact Terraform resources and fields: verify in official provider docs).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Security\/compliance reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Security monitoring evidence<\/strong>: threat logs, audit logs, and configured retention help support compliance programs.<\/li>\n<li><strong>Separation of duties<\/strong>: network team configures mirroring; security team consumes logs; platform team manages projects and IAM.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Scalability\/performance reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Selective mirroring<\/strong>: inspect what matters instead of all traffic everywhere.<\/li>\n<li><strong>Regional deployment<\/strong>: place inspection near workloads to avoid unnecessary cross-region traffic.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">When teams should choose Cloud IDS<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>You need <strong>managed network IDS<\/strong> for Compute Engine and other VPC-attached workloads.<\/li>\n<li>You want to <strong>start with detection<\/strong> (out-of-band) before investing in inline enforcement.<\/li>\n<li>You already use (or can use) <strong>Cloud Logging<\/strong> and log export pipelines.<\/li>\n<li>You have security operations that can triage and respond to detections.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">When teams should not choose it<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>You need <strong>inline blocking\/prevention<\/strong> (that\u2019s typically firewall\/IPS\/NGFW territory, not IDS).<\/li>\n<li>Your workload is mostly <strong>serverless without VPC traffic you can mirror<\/strong> (or traffic doesn\u2019t traverse NICs you can mirror).<\/li>\n<li>You need <strong>full packet capture retention<\/strong> (Cloud IDS is for detection; it is not a PCAP archive).<\/li>\n<li>You cannot accept the <strong>cost and network overhead<\/strong> of mirroring meaningful traffic volume.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">4. Where is Cloud IDS used?<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Industries<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Financial services and fintech (east-west monitoring, compliance-driven logging)<\/li>\n<li>Healthcare (regulated environments with audit requirements)<\/li>\n<li>Retail and e-commerce (protect web tiers and internal services)<\/li>\n<li>SaaS providers (multi-tenant workload monitoring)<\/li>\n<li>Manufacturing and critical infrastructure (monitor hybrid connectivity into VPC)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Team types<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Security engineering \/ detection engineering<\/li>\n<li>SOC analysts and incident responders<\/li>\n<li>Platform engineering and SRE (operational ownership, log routing)<\/li>\n<li>Network engineering (Packet Mirroring design, segmentation)<\/li>\n<li>DevSecOps teams (policy-as-code, automation)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Workloads<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Compute Engine VM fleets (web\/app\/db tiers)<\/li>\n<li>GKE clusters (mirroring node traffic; exact coverage patterns depend on your networking mode\u2014verify)<\/li>\n<li>Hybrid workloads (on-prem \u2194 VPC traffic that terminates on mirrored NICs)<\/li>\n<li>Third-party virtual appliances where traffic traverses mirrorable interfaces<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Architectures<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Hub-and-spoke VPC designs (centralized inspection per region)<\/li>\n<li>Shared VPC with centralized security tooling (verify supported deployment patterns)<\/li>\n<li>Multi-project environments with centralized logging and SIEM export<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Real-world deployment contexts<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Production<\/strong>: targeted mirroring for critical subnets, internet-facing services, and sensitive east-west paths; log export to SIEM; alerting and incident playbooks.<\/li>\n<li><strong>Dev\/test<\/strong>: smaller endpoint footprint, narrower mirroring scope, short log retention, used for tuning and validating detection pipelines.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">5. Top Use Cases and Scenarios<\/h2>\n\n\n\n<p>Below are realistic Cloud IDS use cases in Google Cloud Networking environments.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">1) Detect internet-facing exploit attempts against VM web servers<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Public endpoints receive vulnerability scans and exploit payloads.<\/li>\n<li><strong>Why Cloud IDS fits:<\/strong> Mirroring the web VM NIC allows deep inspection and detection patterns beyond basic firewall logs.<\/li>\n<li><strong>Scenario:<\/strong> Mirror ingress\/egress for a web subnet in <code>us-central1<\/code>; triage threat logs in Cloud Logging and forward to SIEM.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">2) Identify lateral movement signals inside a VPC<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> After initial compromise, attackers move east-west to other services.<\/li>\n<li><strong>Why Cloud IDS fits:<\/strong> Packet Mirroring can focus on sensitive internal subnets to detect scanning, suspicious SMB\/RDP patterns, etc.<\/li>\n<li><strong>Scenario:<\/strong> Mirror traffic on the app subnet NICs and alert on scan-like detections.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">3) Monitor administrative access paths (SSH\/RDP) for suspicious behavior<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Brute force attempts and unauthorized admin activity are hard to see at scale.<\/li>\n<li><strong>Why Cloud IDS fits:<\/strong> Deep inspection of admin protocols and related traffic patterns (detection coverage varies\u2014verify).<\/li>\n<li><strong>Scenario:<\/strong> Mirror bastion host NICs and SOC monitors threat logs.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">4) Add detection coverage to \u201callow-by-need\u201d firewall environments<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Firewalls allow required traffic but don\u2019t detect malicious payloads inside allowed flows.<\/li>\n<li><strong>Why Cloud IDS fits:<\/strong> IDS focuses on threat detection within permitted traffic.<\/li>\n<li><strong>Scenario:<\/strong> Microsegmented VPC with strict firewall rules; Cloud IDS monitors allowed service-to-service flows.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">5) Validate segmentation and policy changes safely<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Network policy changes can introduce blind spots.<\/li>\n<li><strong>Why Cloud IDS fits:<\/strong> Mirror selectively during change windows and compare detections\/traffic patterns before and after.<\/li>\n<li><strong>Scenario:<\/strong> During a migration to hierarchical firewall policies, mirror a sample of traffic to ensure no new suspicious flows appear.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">6) Detect suspicious egress and command-and-control patterns<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Compromised hosts call out to malicious infrastructure.<\/li>\n<li><strong>Why Cloud IDS fits:<\/strong> IDS engines often detect C2 patterns and suspicious outbound traffic signatures (coverage varies).<\/li>\n<li><strong>Scenario:<\/strong> Mirror egress from a sensitive subnet; create alerting on high-severity detections.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">7) Provide network-based detections for workloads without host agents<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Some environments cannot run EDR\/agents (vendor appliances, legacy OS constraints).<\/li>\n<li><strong>Why Cloud IDS fits:<\/strong> Network-based detection is agentless.<\/li>\n<li><strong>Scenario:<\/strong> Mirror traffic from a vendor-managed VM appliance and use threat logs for monitoring.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">8) Strengthen hybrid security monitoring (on-prem \u2194 VPC)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Hybrid connections bring on-prem risks into cloud networks.<\/li>\n<li><strong>Why Cloud IDS fits:<\/strong> Mirror traffic at the cloud NIC where hybrid traffic terminates.<\/li>\n<li><strong>Scenario:<\/strong> Mirror traffic to\/from a proxy VM that front-ends on-prem connectivity; send logs to centralized SOC.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">9) Support incident response with corroborating network evidence<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> During an incident, teams need multiple evidence sources.<\/li>\n<li><strong>Why Cloud IDS fits:<\/strong> Threat logs complement flow logs, firewall logs, and application logs.<\/li>\n<li><strong>Scenario:<\/strong> IR team correlates Cloud IDS detections with VPC Flow Logs in BigQuery.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">10) Continuous security monitoring for regulated workloads<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Compliance requires demonstrable monitoring controls.<\/li>\n<li><strong>Why Cloud IDS fits:<\/strong> Threat logs + retention policies + audit logs provide evidence of monitoring and access control.<\/li>\n<li><strong>Scenario:<\/strong> PCI-like environment mirrors payment subnet traffic to Cloud IDS and exports logs to a retained archive bucket.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">11) Detect risky scanning from developer and CI networks<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Misconfigured scanners or tools can behave like attackers.<\/li>\n<li><strong>Why Cloud IDS fits:<\/strong> Mirror developer subnet egress to detect unexpected scanning.<\/li>\n<li><strong>Scenario:<\/strong> Mirror traffic from CI runner subnet for a week; tune exceptions if needed.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">12) Monitor third-party integrations inside VPC<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Vendor systems and partners increase risk.<\/li>\n<li><strong>Why Cloud IDS fits:<\/strong> Target mirroring to partner-connected workloads.<\/li>\n<li><strong>Scenario:<\/strong> Mirror traffic to\/from a partner SFTP VM and alert on suspicious inbound patterns.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">6. Core Features<\/h2>\n\n\n\n<p>This section focuses on core, currently relevant Cloud IDS capabilities in Google Cloud. If you need exact per-feature availability, verify in official docs: https:\/\/cloud.google.com\/intrusion-detection-system\/docs<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">1) Managed Cloud IDS endpoint (regional)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Provides a managed inspection endpoint in a chosen region and VPC network.<\/li>\n<li><strong>Why it matters:<\/strong> You don\u2019t deploy and maintain IDS VMs\/appliances.<\/li>\n<li><strong>Practical benefit:<\/strong> Faster deployment and fewer operational tasks (patching, scaling).<\/li>\n<li><strong>Caveats:<\/strong> Regional coverage\u2014multi-region environments typically require multiple endpoints.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">2) Integration with VPC Packet Mirroring<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Uses Packet Mirroring to copy traffic from selected sources to Cloud IDS.<\/li>\n<li><strong>Why it matters:<\/strong> Lets you choose exactly what to inspect, where.<\/li>\n<li><strong>Practical benefit:<\/strong> Target high-value assets and reduce mirrored volume.<\/li>\n<li><strong>Caveats:<\/strong> Mirroring increases network traffic (a copy of packets) and can increase cost.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">3) Threat detection logs in Cloud Logging<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Emits threat detections as structured logs to Cloud Logging.<\/li>\n<li><strong>Why it matters:<\/strong> Logging is the foundation for search, alerting, export, and retention.<\/li>\n<li><strong>Practical benefit:<\/strong> Build SOC workflows with log-based alerts and SIEM export.<\/li>\n<li><strong>Caveats:<\/strong> Logs can become high volume; plan retention and sinks.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">4) Severity-based detection signal<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Threat logs include severity\/priority fields so teams can triage.<\/li>\n<li><strong>Why it matters:<\/strong> Reduces noise by helping focus on high-impact detections first.<\/li>\n<li><strong>Practical benefit:<\/strong> Build alerting thresholds (e.g., alert only on high\/critical).<\/li>\n<li><strong>Caveats:<\/strong> Severity semantics are engine-defined; validate your triage mapping.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">5) Service-managed scaling and availability<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Cloud IDS manages inspection capacity behind the endpoint.<\/li>\n<li><strong>Why it matters:<\/strong> IDS capacity planning is difficult in dynamic environments.<\/li>\n<li><strong>Practical benefit:<\/strong> More predictable operations under changing traffic patterns.<\/li>\n<li><strong>Caveats:<\/strong> There are still quotas\/limits and practical throughput considerations\u2014verify limits.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">6) Centralized governance with IAM and Audit Logs<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> IAM controls who can create endpoints, configure mirroring, and view logs; Admin Activity is captured in Cloud Audit Logs.<\/li>\n<li><strong>Why it matters:<\/strong> IDS configuration is security-sensitive.<\/li>\n<li><strong>Practical benefit:<\/strong> Implement separation of duties and traceability.<\/li>\n<li><strong>Caveats:<\/strong> Misconfigured IAM can expose threat telemetry; restrict log access.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">7) Filterable inspection scope via Packet Mirroring rules<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Allows selecting traffic based on instances\/subnets\/tags and optional filtering.<\/li>\n<li><strong>Why it matters:<\/strong> You rarely want to mirror everything.<\/li>\n<li><strong>Practical benefit:<\/strong> Control cost and reduce noise by mirroring only relevant sources and protocols.<\/li>\n<li><strong>Caveats:<\/strong> Over-filtering can create blind spots; document coverage decisions.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">8) Export-friendly detections (SIEM\/SOAR pipelines)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Cloud Logging sinks can export Cloud IDS threat logs to Pub\/Sub, BigQuery, or Cloud Storage.<\/li>\n<li><strong>Why it matters:<\/strong> Most enterprises need centralized security analytics.<\/li>\n<li><strong>Practical benefit:<\/strong> Integrate with detection engineering and incident automation.<\/li>\n<li><strong>Caveats:<\/strong> Export pipelines add cost and operational responsibility.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">7. Architecture and How It Works<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">High-level architecture<\/h3>\n\n\n\n<p>Cloud IDS sits out-of-band from application traffic:\n1. Workloads send\/receive traffic normally in a VPC network.\n2. Packet Mirroring copies selected packets and sends the mirrored stream to a Cloud IDS endpoint.\n3. Cloud IDS analyzes mirrored traffic using a managed IDS engine.\n4. Threat detections are written to Cloud Logging.\n5. Security teams query, alert, and export logs.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Data flow vs control flow<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Control flow (configuration):<\/strong><\/li>\n<li>Create Cloud IDS endpoint in a region and VPC.<\/li>\n<li>Create Packet Mirroring policy to send mirrored traffic to that endpoint.<\/li>\n<li>Configure IAM, logging retention, and log export sinks.<\/li>\n<li><strong>Data flow (traffic + logs):<\/strong><\/li>\n<li>Mirrored packets \u2192 Cloud IDS endpoint \u2192 analysis \u2192 threat logs \u2192 Cloud Logging \u2192 alerting\/SIEM.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Integrations with related services<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>VPC Packet Mirroring:<\/strong> Required to feed traffic.<\/li>\n<li><strong>Cloud Logging:<\/strong> Primary detection output destination.<\/li>\n<li><strong>Cloud Monitoring:<\/strong> Operational metrics\/alerts for logs and potentially endpoint health signals (verify available metrics).<\/li>\n<li><strong>Pub\/Sub \/ BigQuery \/ Cloud Storage:<\/strong> Common destinations via Logging sinks.<\/li>\n<li><strong>Security Command Center:<\/strong> Often used for centralized security posture and findings; Cloud IDS data is typically integrated via logs\/export patterns unless a direct integration is documented (verify).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Dependency services<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Compute Engine APIs (for Packet Mirroring and VM-based traffic sources)<\/li>\n<li>Cloud IDS API<\/li>\n<li>Cloud Logging<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Security\/authentication model<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Cloud IDS and Packet Mirroring are managed by Google Cloud IAM.<\/li>\n<li>Users and service accounts require roles to:<\/li>\n<li>create\/modify endpoints (Cloud IDS permissions)<\/li>\n<li>create\/modify packet mirroring policies (Compute Network permissions)<\/li>\n<li>view\/query logs (Logging permissions)<\/li>\n<li>All configuration changes should be traceable via Cloud Audit Logs.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Networking model<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Cloud IDS endpoint is deployed into your VPC network in a region (resource association).<\/li>\n<li>Mirrored traffic is sent to the collector endpoint in-region.<\/li>\n<li>Because traffic is mirrored (duplicated), you must account for:<\/li>\n<li>additional bandwidth consumption<\/li>\n<li>possible inter-zone traffic charges if sources and collectors are in different zones within the region (verify how your topology affects billing)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Monitoring\/logging\/governance considerations<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Use <strong>Cloud Logging<\/strong> queries and log-based metrics for detection and operations.<\/li>\n<li>Set <strong>retention policies<\/strong> appropriate to compliance requirements.<\/li>\n<li>Export high-value logs to a centralized security project.<\/li>\n<li>Tag and name IDS endpoints and mirroring policies consistently for audits.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Simple architecture diagram (Mermaid)<\/h3>\n\n\n\n<pre><code class=\"language-mermaid\">flowchart LR\n  A[VMs \/ GKE Nodes in VPC] --&gt;|Normal traffic| B[Peers \/ Services]\n  A --&gt;|Mirrored packets (Packet Mirroring)| C[Cloud IDS Endpoint (Regional)]\n  C --&gt; D[Threat detections]\n  D --&gt; E[Cloud Logging]\n  E --&gt; F[Alerting \/ SIEM Export]\n<\/code><\/pre>\n\n\n\n<h3 class=\"wp-block-heading\">Production-style architecture diagram (Mermaid)<\/h3>\n\n\n\n<pre><code class=\"language-mermaid\">flowchart TB\n  subgraph Region[\"Google Cloud Region (e.g., us-central1)\"]\n    subgraph VPC[\"Prod VPC Network\"]\n      subgraph App[\"App Subnet(s)\"]\n        W1[Web VM MIG]\n        A1[App VM MIG]\n      end\n      subgraph Data[\"Data Subnet(s)\"]\n        D1[DB VM]\n      end\n      PM[Packet Mirroring Policy]\n      IDS[Cloud IDS Endpoint]\n    end\n\n    W1 --&gt;|traffic| A1\n    A1 --&gt;|traffic| D1\n    W1 --&gt;|ingress\/egress| Internet[(Internet)]\n    PM --&gt;|mirrors selected sources| IDS\n  end\n\n  IDS --&gt; LOG[Cloud Logging: Cloud IDS threat logs]\n  LOG --&gt; SINK[Logging Sink -&gt; Pub\/Sub\/BigQuery\/Storage]\n  SINK --&gt; SIEM[SIEM \/ SOC Platform]\n  LOG --&gt; ALERT[Cloud Monitoring Alerting (log-based)]\n  IAM[IAM + Audit Logs] --&gt; PM\n  IAM --&gt; IDS\n<\/code><\/pre>\n\n\n\n<h2 class=\"wp-block-heading\">8. Prerequisites<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Account\/project requirements<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>A Google Cloud project with <strong>Billing enabled<\/strong>.<\/li>\n<li>Ability to enable required APIs.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Permissions \/ IAM roles<\/h3>\n\n\n\n<p>You typically need:\n&#8211; Cloud IDS administration permissions (for endpoints)\n&#8211; Compute Network administration permissions (for Packet Mirroring)\n&#8211; Logging permissions (to view threat logs)<\/p>\n\n\n\n<p>Common role patterns (verify the exact role names and least-privilege in IAM docs):\n&#8211; <code>roles\/ids.admin<\/code> or equivalent (Cloud IDS endpoint management)\n&#8211; <code>roles\/compute.networkAdmin<\/code> (Packet Mirroring configuration)\n&#8211; <code>roles\/logging.viewer<\/code> (view logs) and\/or <code>roles\/logging.admin<\/code> (create sinks\/metrics)<\/p>\n\n\n\n<blockquote>\n<p>Use least privilege. For production, separate roles between network\/platform admins and security analysts.<\/p>\n<\/blockquote>\n\n\n\n<h3 class=\"wp-block-heading\">Billing requirements<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Cloud IDS usage is billable (no assumption of a free tier).<\/li>\n<li>Packet mirroring increases network usage and can increase bills indirectly.<\/li>\n<li>Cloud Logging ingestion and retention may cost depending on usage and retention.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">CLI\/SDK\/tools needed<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Google Cloud CLI (<code>gcloud<\/code>) installed and authenticated:<\/li>\n<li>Install: https:\/\/cloud.google.com\/sdk\/docs\/install<\/li>\n<li>Optional: <code>nmap<\/code> on a test VM for generating scan-like traffic.<\/li>\n<li>Optional: Terraform (if you\u2019re automating), but the hands-on lab below uses console + gcloud.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Region availability<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Cloud IDS is not available in every region. Verify supported regions:<\/li>\n<li>https:\/\/cloud.google.com\/intrusion-detection-system\/docs (check \u201cLocations\u201d\/availability)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Quotas\/limits<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Cloud IDS endpoint quotas per project\/region may apply.<\/li>\n<li>Packet Mirroring has its own quotas and limits.<\/li>\n<li>Logging ingestion quotas may apply in extreme cases.<\/li>\n<\/ul>\n\n\n\n<p>Always confirm:\n&#8211; Cloud IDS quotas: in Google Cloud console \u2192 IAM &amp; Admin \u2192 Quotas (filter for \u201cCloud IDS\u201d)\n&#8211; Packet Mirroring quotas: quotas for Compute Engine networking<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Prerequisite services<\/h3>\n\n\n\n<p>Enable APIs:\n&#8211; Cloud IDS API\n&#8211; Compute Engine API\n&#8211; Cloud Logging API (usually enabled by default)<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">9. Pricing \/ Cost<\/h2>\n\n\n\n<p>Cloud IDS pricing is <strong>usage-based<\/strong> and can vary by region and SKU\/edition. Do not assume a single flat price.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Pricing dimensions (typical)<\/h3>\n\n\n\n<p>From a cost-model perspective, Cloud IDS solutions commonly include:\n&#8211; <strong>Per-endpoint cost<\/strong> (e.g., hourly per Cloud IDS endpoint)\n&#8211; <strong>Traffic processing cost<\/strong> (e.g., per GiB of mirrored traffic inspected)<\/p>\n\n\n\n<p>However, you must confirm the <strong>current<\/strong> billing units and SKUs on the official pricing page:\n&#8211; Cloud IDS pricing: https:\/\/cloud.google.com\/intrusion-detection-system\/pricing<br\/>\n&#8211; Google Cloud Pricing Calculator: https:\/\/cloud.google.com\/products\/calculator<\/p>\n\n\n\n<blockquote>\n<p>If the pricing page describes only one dimension (or additional dimensions), treat that as the source of truth.<\/p>\n<\/blockquote>\n\n\n\n<h3 class=\"wp-block-heading\">Free tier<\/h3>\n\n\n\n<p>Cloud IDS generally should be treated as <strong>no free tier<\/strong> unless the official pricing page explicitly states otherwise. Verify in official pricing docs.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Primary cost drivers<\/h3>\n\n\n\n<ol class=\"wp-block-list\">\n<li><strong>How much traffic you mirror<\/strong> (biggest lever)<\/li>\n<li><strong>How many endpoints<\/strong> you deploy (often one per region per environment)<\/li>\n<li><strong>How verbose your logging\/export is<\/strong><\/li>\n<li><strong>How long you retain logs<\/strong> (and whether you export to BigQuery\/Storage)<\/li>\n<\/ol>\n\n\n\n<h3 class=\"wp-block-heading\">Hidden or indirect costs<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Inter-zone network charges<\/strong>: If mirrored traffic traverses zones (even within the same region), you may incur inter-zone egress. Exact billing depends on topology\u2014verify with Google Cloud networking pricing docs.<\/li>\n<li><strong>Log ingestion and storage<\/strong>: High-volume threat logs can increase Logging costs depending on your plan and retention.<\/li>\n<li><strong>SIEM pipeline costs<\/strong>:<\/li>\n<li>Pub\/Sub throughput<\/li>\n<li>Dataflow (if used)<\/li>\n<li>BigQuery storage and query cost<\/li>\n<li>Third-party SIEM licensing<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Network\/data transfer implications<\/h3>\n\n\n\n<p>Packet mirroring duplicates packets. If you mirror 1 Gbps of sustained traffic, you are effectively adding an additional 1 Gbps stream that must be delivered to the collector and processed\u2014plus any internal network overhead.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">How to optimize cost (without losing value)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Start with <strong>targeted mirroring<\/strong> (critical workloads only).<\/li>\n<li>Use <strong>Packet Mirroring filters<\/strong> to exclude low-value traffic (e.g., known safe internal health checks) but be careful not to create blind spots.<\/li>\n<li>Mirror <strong>ingress only<\/strong> for certain tiers if egress isn\u2019t needed (depends on threat model).<\/li>\n<li>Use <strong>separate endpoints<\/strong> for different environments (dev\/test vs prod) and keep dev\/test short-lived.<\/li>\n<li>Apply <strong>log routing<\/strong>:<\/li>\n<li>keep only important severities long term<\/li>\n<li>export to cheaper storage for archival if needed<\/li>\n<li>Review detections and tune scope; avoid \u201cmirror everything forever\u201d.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Example low-cost starter estimate (how to think about it)<\/h3>\n\n\n\n<p>A low-cost pilot typically looks like:\n&#8211; 1 Cloud IDS endpoint in one region\n&#8211; Mirroring limited to 1\u20133 small VMs and only a subset of ports\/protocols\n&#8211; Short test window (a few hours to a few days)\n&#8211; Logging retained briefly, minimal exports<\/p>\n\n\n\n<p>Because exact pricing varies, calculate it using:\n&#8211; endpoint-hours for the pilot duration\n&#8211; estimated mirrored GiB processed per day\n&#8211; expected log volume<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Example production cost considerations<\/h3>\n\n\n\n<p>For production, estimate:\n&#8211; endpoints per region \u00d7 24\u00d77 hours\n&#8211; mirrored traffic volume per region (by tier)\n&#8211; expected log volume and retention (e.g., 30\/90\/365 days)\n&#8211; SIEM export and downstream analytics costs<\/p>\n\n\n\n<p>A practical approach:\n1. Pilot with narrow mirroring.\n2. Measure mirrored traffic volume and resulting detections\/log volume.\n3. Expand coverage iteratively with cost guardrails and alerting.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">10. Step-by-Step Hands-On Tutorial<\/h2>\n\n\n\n<p>This lab deploys Cloud IDS in a safe, low-cost way by:\n&#8211; Using small VM instances\n&#8211; Limiting the mirrored sources\n&#8211; Running the lab for a short time and cleaning up<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Objective<\/h3>\n\n\n\n<p>Deploy a <strong>Cloud IDS endpoint<\/strong> and a <strong>Packet Mirroring policy<\/strong> in Google Cloud, generate test traffic, and validate that <strong>Cloud IDS threat logs<\/strong> appear in Cloud Logging.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Lab Overview<\/h3>\n\n\n\n<p>You will:\n1. Create a VPC and two test VMs (client and server).\n2. Create a Cloud IDS endpoint in the same region.\n3. Configure Packet Mirroring to mirror traffic from the server VM to the Cloud IDS endpoint.\n4. Generate traffic (HTTP + optional port scan) and validate logs.\n5. Clean up all resources to stop charges.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Step 1: Set up your environment (project, region, APIs)<\/h3>\n\n\n\n<p>1) Choose or create a project:\n&#8211; Console: <strong>IAM &amp; Admin \u2192 Manage resources \u2192 Create Project<\/strong>\n&#8211; Ensure <strong>Billing<\/strong> is enabled for the project.<\/p>\n\n\n\n<p>2) Set variables in your terminal:<\/p>\n\n\n\n<pre><code class=\"language-bash\">export PROJECT_ID=\"YOUR_PROJECT_ID\"\nexport REGION=\"us-central1\"\nexport ZONE=\"us-central1-a\"\nexport VPC_NAME=\"ids-lab-vpc\"\nexport SUBNET_NAME=\"ids-lab-subnet\"\n<\/code><\/pre>\n\n\n\n<p>3) Authenticate and set the project:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud auth login\ngcloud config set project \"$PROJECT_ID\"\ngcloud config set compute\/region \"$REGION\"\ngcloud config set compute\/zone \"$ZONE\"\n<\/code><\/pre>\n\n\n\n<p>4) Enable APIs:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud services enable \\\n  compute.googleapis.com \\\n  ids.googleapis.com \\\n  logging.googleapis.com\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> APIs enable successfully. If you see permission errors, you need a project owner\/admin (or equivalent) to enable services.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 2: Create a VPC network and subnet<\/h3>\n\n\n\n<p>Create a custom-mode VPC and subnet:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud compute networks create \"$VPC_NAME\" --subnet-mode=custom\n\ngcloud compute networks subnets create \"$SUBNET_NAME\" \\\n  --network=\"$VPC_NAME\" \\\n  --region=\"$REGION\" \\\n  --range=\"10.10.0.0\/24\"\n<\/code><\/pre>\n\n\n\n<p>Add firewall rules to allow:\n&#8211; internal traffic within the subnet\n&#8211; SSH for administration\n&#8211; HTTP between the test VMs<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud compute firewall-rules create ids-lab-allow-internal \\\n  --network=\"$VPC_NAME\" \\\n  --allow=tcp,udp,icmp \\\n  --source-ranges=\"10.10.0.0\/24\"\n\ngcloud compute firewall-rules create ids-lab-allow-ssh \\\n  --network=\"$VPC_NAME\" \\\n  --allow=tcp:22 \\\n  --source-ranges=\"0.0.0.0\/0\"\n\ngcloud compute firewall-rules create ids-lab-allow-http \\\n  --network=\"$VPC_NAME\" \\\n  --allow=tcp:80 \\\n  --source-ranges=\"10.10.0.0\/24\"\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> VPC, subnet, and firewall rules exist.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 3: Create two small VM instances (server + client)<\/h3>\n\n\n\n<p>1) Create a server VM:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud compute instances create ids-server \\\n  --zone=\"$ZONE\" \\\n  --machine-type=\"e2-micro\" \\\n  --subnet=\"$SUBNET_NAME\" \\\n  --image-family=\"debian-12\" \\\n  --image-project=\"debian-cloud\"\n<\/code><\/pre>\n\n\n\n<p>2) Create a client VM:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud compute instances create ids-client \\\n  --zone=\"$ZONE\" \\\n  --machine-type=\"e2-micro\" \\\n  --subnet=\"$SUBNET_NAME\" \\\n  --image-family=\"debian-12\" \\\n  --image-project=\"debian-cloud\"\n<\/code><\/pre>\n\n\n\n<p>3) Install a simple web server on <code>ids-server<\/code>:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud compute ssh ids-server --zone=\"$ZONE\" --command=\"sudo apt-get update &amp;&amp; sudo apt-get install -y nginx\"\n<\/code><\/pre>\n\n\n\n<p>4) Get the internal IP of <code>ids-server<\/code>:<\/p>\n\n\n\n<pre><code class=\"language-bash\">export SERVER_IP=\"$(gcloud compute instances describe ids-server --zone=\"$ZONE\" \\\n  --format='get(networkInterfaces[0].networkIP)')\"\necho \"$SERVER_IP\"\n<\/code><\/pre>\n\n\n\n<p>5) From <code>ids-client<\/code>, curl the server:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud compute ssh ids-client --zone=\"$ZONE\" --command=\"curl -I http:\/\/$SERVER_IP\"\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> <code>curl<\/code> returns an HTTP response header (e.g., <code>HTTP\/1.1 200 OK<\/code>), proving basic connectivity.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 4: Create a Cloud IDS endpoint (regional)<\/h3>\n\n\n\n<p>You can create the endpoint via <strong>Console<\/strong> or <strong>gcloud<\/strong>. The Console path is often the most foolproof because it guides required fields.<\/p>\n\n\n\n<p><strong>Option A (recommended): Create via Console<\/strong>\n1. Console \u2192 <strong>Navigation menu \u2192 Security \u2192 Cloud IDS<\/strong> (or search \u201cCloud IDS\u201d).\n2. Click <strong>Create endpoint<\/strong>.\n3. Configure:\n   &#8211; <strong>Name:<\/strong> <code>ids-endpoint-1<\/code>\n   &#8211; <strong>Region:<\/strong> <code>us-central1<\/code> (use your <code>$REGION<\/code>)\n   &#8211; <strong>Network:<\/strong> <code>ids-lab-vpc<\/code>\n   &#8211; Any severity\/tuning options: keep defaults for the lab unless you have a specific reason.\n4. Click <strong>Create<\/strong>.\n5. Wait for provisioning to finish.<\/p>\n\n\n\n<p><strong>Option B: Create via gcloud (verify flags in help)<\/strong>\nRun:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud ids endpoints create ids-endpoint-1 \\\n  --location=\"$REGION\" \\\n  --network=\"$VPC_NAME\"\n<\/code><\/pre>\n\n\n\n<p>If the command fails due to flags or requirements, run:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud ids endpoints create --help\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> Endpoint becomes <strong>READY\/RUNNING<\/strong> (exact status text may vary). Provisioning can take several minutes.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 5: Configure Packet Mirroring to send traffic to Cloud IDS<\/h3>\n\n\n\n<p>Packet Mirroring must be in the <strong>same region<\/strong> as the IDS endpoint and mirrored sources.<\/p>\n\n\n\n<p>This step is easiest in the Console due to collector selection UI.<\/p>\n\n\n\n<p>1) Console \u2192 <strong>VPC network \u2192 Packet mirroring<\/strong>\n&#8211; Or search: \u201cPacket Mirroring\u201d.<\/p>\n\n\n\n<p>2) Click <strong>Create packet mirroring policy<\/strong>.<\/p>\n\n\n\n<p>3) Configure the policy (typical fields):\n&#8211; <strong>Name:<\/strong> <code>ids-mirror-policy-1<\/code>\n&#8211; <strong>Region:<\/strong> <code>us-central1<\/code>\n&#8211; <strong>Network:<\/strong> <code>ids-lab-vpc<\/code><\/p>\n\n\n\n<p>4) <strong>Collector destination<\/strong>\n&#8211; Select <strong>Cloud IDS endpoint<\/strong> as the collector.\n&#8211; Choose <code>ids-endpoint-1<\/code>.<\/p>\n\n\n\n<p>5) <strong>Mirrored sources<\/strong>\n&#8211; Choose <strong>Instances<\/strong> and select <code>ids-server<\/code> (mirror only the server for this lab).<\/p>\n\n\n\n<p>6) <strong>Traffic direction<\/strong>\n&#8211; Start with <strong>Ingress and egress<\/strong> (or choose one direction if you want to reduce volume).<\/p>\n\n\n\n<p>7) <strong>Filter (optional but recommended)<\/strong>\n&#8211; If the UI allows: filter to <strong>TCP<\/strong> and ports like <code>80<\/code> and <code>22<\/code> to reduce mirrored volume.\n&#8211; If you can\u2019t easily filter, proceed without filters for the lab.<\/p>\n\n\n\n<p>8) Create the policy.<\/p>\n\n\n\n<p><strong>Expected outcome:<\/strong> Packet mirroring policy is created and shows as active. Within a short time, mirrored traffic should start flowing to Cloud IDS when traffic occurs on <code>ids-server<\/code>.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 6: Generate test traffic (and optional \u201cnoisy\u201d traffic)<\/h3>\n\n\n\n<p>1) Generate normal HTTP traffic:\nFrom <code>ids-client<\/code>, run:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud compute ssh ids-client --zone=\"$ZONE\" --command=\"for i in {1..20}; do curl -s http:\/\/$SERVER_IP &gt;\/dev\/null; done; echo done\"\n<\/code><\/pre>\n\n\n\n<p>2) Optional: generate scan-like traffic (may produce IDS detections)\nInstall <code>nmap<\/code> on <code>ids-client<\/code> and scan common ports:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud compute ssh ids-client --zone=\"$ZONE\" --command=\"sudo apt-get update &amp;&amp; sudo apt-get install -y nmap\"\ngcloud compute ssh ids-client --zone=\"$ZONE\" --command=\"nmap -sS -Pn -p 1-1024 $SERVER_IP\"\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> Traffic is generated. Whether you get detections depends on signature coverage and service behavior. Even if there are no detections, you can still validate endpoint health and confirm logging pipelines.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 7: View Cloud IDS threat logs in Cloud Logging<\/h3>\n\n\n\n<p>1) Console \u2192 <strong>Logging \u2192 Logs Explorer<\/strong>.<\/p>\n\n\n\n<p>2) Use a query that searches for Cloud IDS logs.\nBecause exact log names can change, use an exploratory query first:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>In Logs Explorer, select <strong>Resource type<\/strong> related to Cloud IDS (if present), or search for \u201ccloudids\u201d.<\/li>\n<\/ul>\n\n\n\n<p>Example broad query:<\/p>\n\n\n\n<pre><code class=\"language-text\">search(\"cloudids\")\n<\/code><\/pre>\n\n\n\n<p>Then narrow down based on observed fields (such as <code>logName<\/code>, <code>resource.type<\/code>, or <code>jsonPayload<\/code>).<\/p>\n\n\n\n<p>If the docs specify a log name (for example, a \u201cthreat\u201d log), use that exact filter. Verify in docs if needed:\n&#8211; https:\/\/cloud.google.com\/intrusion-detection-system\/docs<\/p>\n\n\n\n<p>3) Confirm you see entries that look like:\n&#8211; detections with signature\/threat identifiers\n&#8211; severity fields\n&#8211; source\/destination IP\/port metadata (depending on log structure)<\/p>\n\n\n\n<p><strong>Expected outcome:<\/strong> You can locate Cloud IDS-related logs. If scan-like traffic triggered signatures, you should see threat detection entries.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Validation<\/h3>\n\n\n\n<p>Use this checklist:<\/p>\n\n\n\n<p>1) <strong>Endpoint status<\/strong>\n&#8211; Cloud IDS endpoint shows <strong>Ready\/Running<\/strong> in Console (Cloud IDS page).<\/p>\n\n\n\n<p>2) <strong>Packet mirroring status<\/strong>\n&#8211; Packet mirroring policy exists and is enabled in the correct region and VPC.\n&#8211; Mirrored source includes <code>ids-server<\/code>.<\/p>\n\n\n\n<p>3) <strong>Traffic occurred<\/strong>\n&#8211; You successfully curled the server and (optionally) ran <code>nmap<\/code>.<\/p>\n\n\n\n<p>4) <strong>Logs visible<\/strong>\n&#8211; You can find Cloud IDS logs in Logs Explorer by searching <code>cloudids<\/code>.\n&#8211; If threat detections exist, they appear as structured entries.<\/p>\n\n\n\n<p>If you want to validate via CLI, you can attempt a broad logs read (then refine):<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud logging read 'search(\"cloudids\")' --limit=50 --format=json\n<\/code><\/pre>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Troubleshooting<\/h3>\n\n\n\n<h4 class=\"wp-block-heading\">Problem: Cloud IDS endpoint creation fails<\/h4>\n\n\n\n<p>Common causes:\n&#8211; API not enabled (<code>ids.googleapis.com<\/code>)\n&#8211; Insufficient IAM permissions\n&#8211; Region not supported for Cloud IDS<\/p>\n\n\n\n<p>Fix:\n&#8211; Enable APIs (Step 1)\n&#8211; Verify roles like Cloud IDS admin permissions\n&#8211; Try a supported region (check official docs)<\/p>\n\n\n\n<h4 class=\"wp-block-heading\">Problem: Packet mirroring can\u2019t select the Cloud IDS endpoint as collector<\/h4>\n\n\n\n<p>Common causes:\n&#8211; Region mismatch between packet mirroring policy and endpoint\n&#8211; Endpoint not ready\n&#8211; Missing permissions for packet mirroring configuration<\/p>\n\n\n\n<p>Fix:\n&#8211; Ensure packet mirroring policy region equals endpoint region\n&#8211; Wait for endpoint readiness\n&#8211; Verify <code>compute.networkAdmin<\/code> (or least-privilege equivalent)<\/p>\n\n\n\n<h4 class=\"wp-block-heading\">Problem: No threat detections appear<\/h4>\n\n\n\n<p>This can happen even if everything is configured correctly:\n&#8211; The traffic you generated didn\u2019t match any signatures\n&#8211; Filters are too restrictive\n&#8211; You mirrored the wrong source or direction\n&#8211; Logs are present but you are filtering incorrectly<\/p>\n\n\n\n<p>Fix:\n&#8211; Remove restrictive filters temporarily\n&#8211; Mirror both ingress and egress\n&#8211; Run scan-like traffic (<code>nmap<\/code>) and some unusual HTTP requests\n&#8211; Use broad Logs Explorer query: <code>search(\"cloudids\")<\/code>\n&#8211; Verify mirrored source is the VM that actually receives the traffic<\/p>\n\n\n\n<h4 class=\"wp-block-heading\">Problem: You see logs but they\u2019re too noisy<\/h4>\n\n\n\n<p>Fix:\n&#8211; Restrict mirrored sources (only critical workloads)\n&#8211; Apply Packet Mirroring filters (protocol\/ports\/CIDRs)\n&#8211; Filter alerts by severity; export only what you need<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Cleanup<\/h3>\n\n\n\n<p>To stop charges, remove the mirroring policy and Cloud IDS endpoint, then delete the VMs and network.<\/p>\n\n\n\n<p>1) Delete packet mirroring policy (Console recommended)\n&#8211; Console \u2192 VPC network \u2192 Packet mirroring \u2192 delete <code>ids-mirror-policy-1<\/code><\/p>\n\n\n\n<p>2) Delete Cloud IDS endpoint\n&#8211; Console \u2192 Cloud IDS \u2192 Endpoints \u2192 delete <code>ids-endpoint-1<\/code><\/p>\n\n\n\n<p>Or attempt via CLI (verify command in your environment):<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud ids endpoints delete ids-endpoint-1 --location=\"$REGION\"\n<\/code><\/pre>\n\n\n\n<p>3) Delete VMs:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud compute instances delete ids-server ids-client --zone=\"$ZONE\" --quiet\n<\/code><\/pre>\n\n\n\n<p>4) Delete firewall rules:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud compute firewall-rules delete \\\n  ids-lab-allow-internal ids-lab-allow-ssh ids-lab-allow-http --quiet\n<\/code><\/pre>\n\n\n\n<p>5) Delete subnet and VPC:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud compute networks subnets delete \"$SUBNET_NAME\" --region=\"$REGION\" --quiet\ngcloud compute networks delete \"$VPC_NAME\" --quiet\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> All lab resources are removed and Cloud IDS charges stop.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">11. Best Practices<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Architecture best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Deploy per region<\/strong>: plan Cloud IDS endpoints regionally and keep mirroring regional to minimize complexity and cost.<\/li>\n<li><strong>Start with a threat model<\/strong>: decide what you need to detect (internet attacks, lateral movement, egress C2) and mirror accordingly.<\/li>\n<li><strong>Tiered coverage<\/strong>:<\/li>\n<li>Internet-facing tiers: mirror ingress\/egress of web\/app frontends<\/li>\n<li>Sensitive internal tiers: mirror east-west among app\/data tiers<\/li>\n<li><strong>Use hub-and-spoke patterns carefully<\/strong>: don\u2019t centralize mirrored traffic across regions unless docs explicitly support it and you\u2019ve modeled costs.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">IAM\/security best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Least privilege<\/strong>:<\/li>\n<li>Network admins: manage Packet Mirroring<\/li>\n<li>Security admins: manage Cloud IDS endpoints (or separate further)<\/li>\n<li>SOC analysts: view threat logs only<\/li>\n<li><strong>Separate duties<\/strong>: prevent a single role from both disabling monitoring and approving its own changes.<\/li>\n<li><strong>Audit<\/strong>: regularly review Cloud Audit Logs for IDS endpoint and packet mirroring changes.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Cost best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Mirror only what you need<\/strong> (sources + direction + filters).<\/li>\n<li><strong>Avoid mirroring high-volume east-west blindly<\/strong>; sample or target sensitive segments.<\/li>\n<li><strong>Control logging and exports<\/strong>:<\/li>\n<li>route only important logs to expensive analytics stores<\/li>\n<li>keep long-term archive in cheaper storage if required<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Performance best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Minimize unnecessary mirroring<\/strong> to reduce extra bandwidth and overhead.<\/li>\n<li><strong>Watch for hotspots<\/strong>: if you mirror a very high-throughput interface, you can generate high volumes of mirrored traffic and logs.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Reliability best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Standardize deployment<\/strong> with infrastructure as code.<\/li>\n<li><strong>Use consistent naming\/tagging<\/strong> so endpoints and policies are easy to identify during incidents.<\/li>\n<li><strong>Document coverage<\/strong>: for every endpoint\/policy, document what is mirrored and what is excluded.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Operations best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Create alerting strategy<\/strong>:<\/li>\n<li>High-severity detections \u2192 page\/on-call<\/li>\n<li>Medium severity \u2192 ticket\/queue<\/li>\n<li>Low severity \u2192 aggregated review<\/li>\n<li><strong>Use log-based metrics<\/strong> to monitor detection rates and spot anomalies.<\/li>\n<li><strong>Tune iteratively<\/strong>: adjust mirroring scope and alert thresholds based on operational feedback.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Governance\/tagging\/naming best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Use labels (where supported) and consistent names like:<\/li>\n<li><code>ids-endpoint-prod-uscentral1<\/code><\/li>\n<li><code>pm-prod-web-ingress-uscentral1<\/code><\/li>\n<li>Keep resources in dedicated folders\/projects if you have centralized security governance.<\/li>\n<li>Align retention and export policies with compliance requirements.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">12. Security Considerations<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Identity and access model<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Cloud IDS is controlled by <strong>IAM<\/strong>.<\/li>\n<li>Packet Mirroring is controlled by Compute networking permissions.<\/li>\n<li>Threat logs are controlled by <strong>Logging IAM<\/strong>.<\/li>\n<\/ul>\n\n\n\n<p>Key recommendation: treat \u201cwho can disable mirroring\u201d as a high-risk permission and restrict it.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Encryption<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Google Cloud encrypts data at rest by default in many services.<\/li>\n<li>For in-transit security, mirrored traffic handling is managed by Google; validate details in official documentation if you have strict requirements.<\/li>\n<\/ul>\n\n\n\n<p>If you need customer-managed encryption keys (CMEK) for logs or exports, confirm supported services:\n&#8211; Cloud Logging CMEK support varies by feature\/export target\u2014verify in official docs.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Network exposure<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Cloud IDS is designed for internal inspection of mirrored traffic in your VPC context.<\/li>\n<li>Avoid exposing administrative access widely:<\/li>\n<li>restrict SSH source ranges in real deployments (don\u2019t use <code>0.0.0.0\/0<\/code> like the lab)<\/li>\n<li>use IAP for TCP forwarding or bastion patterns where appropriate<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Secrets handling<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Cloud IDS itself typically does not require you to manage secrets to function.<\/li>\n<li>Protect SIEM export credentials and downstream integration secrets (if any) using Secret Manager.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Audit\/logging<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Enable and monitor Cloud Audit Logs for:<\/li>\n<li>endpoint lifecycle events<\/li>\n<li>packet mirroring policy changes<\/li>\n<li>IAM changes affecting IDS visibility<\/li>\n<li>Use centralized logging projects and restricted sinks for security telemetry.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Compliance considerations<\/h3>\n\n\n\n<p>Cloud IDS can support compliance by providing:\n&#8211; documented monitoring control implementation\n&#8211; centrally retained detections\n&#8211; audit trails for configuration changes<\/p>\n\n\n\n<p>But compliance requires process:\n&#8211; retention policies\n&#8211; incident response runbooks\n&#8211; periodic access reviews<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Common security mistakes<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Mirroring too broadly and then granting broad log access (data exposure risk).<\/li>\n<li>Treating IDS detections as \u201cblocked\u201d (they are not).<\/li>\n<li>Not documenting what\u2019s mirrored and assuming coverage you don\u2019t have.<\/li>\n<li>Leaving dev\/test endpoints running indefinitely.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Secure deployment recommendations<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Use dedicated projects or shared VPC host projects for security tooling (as your org design dictates).<\/li>\n<li>Export threat logs to a centralized SOC environment with restricted access.<\/li>\n<li>Implement alerting and response playbooks before expanding coverage.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">13. Limitations and Gotchas<\/h2>\n\n\n\n<p>Always validate these against current official docs for your region and org constraints.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Known limitations (common patterns)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Detection only, not prevention<\/strong>: Cloud IDS does not block traffic.<\/li>\n<li><strong>Coverage depends on what you mirror<\/strong>: anything not mirrored is invisible to Cloud IDS.<\/li>\n<li><strong>Regional design<\/strong>: endpoints are regional; multi-region needs multiple endpoints.<\/li>\n<li><strong>Not a full PCAP solution<\/strong>: don\u2019t expect full forensic packet retention as a built-in feature.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Quotas and limits<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Endpoint count quotas per project\/region may apply.<\/li>\n<li>Packet mirroring policy and mirrored source quotas may apply.<\/li>\n<li>Logging and export quotas apply at scale.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Regional constraints<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Service availability varies by region.<\/li>\n<li>Packet mirroring and endpoint location must align.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Pricing surprises<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Traffic duplication cost<\/strong>: mirroring doubles traffic volume for mirrored flows.<\/li>\n<li><strong>Inter-zone egress<\/strong>: topology can create unexpected network charges (verify).<\/li>\n<li><strong>Log volume<\/strong>: detections + metadata can generate large log volumes, especially during scanning events.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Compatibility issues<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Workloads that don\u2019t expose mirrorable interfaces (some managed\/serverless services) won\u2019t be directly coverable.<\/li>\n<li>GKE coverage depends on how traffic traverses node NICs and your CNI mode\u2014verify design patterns in docs.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Operational gotchas<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Creating a mirroring policy is easy; tuning it to be useful is the real work.<\/li>\n<li>SOC fatigue: too many low-value detections without severity-based alerting and triage workflows.<\/li>\n<li>Change management: network changes can silently reduce coverage if mirrored sources change (autoscaling, new MIGs, new subnets).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Migration challenges<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Moving from self-managed IDS to Cloud IDS requires:<\/li>\n<li>mapping existing sensor placement to mirror points<\/li>\n<li>rethinking coverage because mirroring is selective<\/li>\n<li>rebuilding alerting\/export pipelines around Cloud Logging<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">14. Comparison with Alternatives<\/h2>\n\n\n\n<p>Cloud IDS is one option in Google Cloud Networking security. Here\u2019s how it compares.<\/p>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Option<\/th>\n<th>Best For<\/th>\n<th>Strengths<\/th>\n<th>Weaknesses<\/th>\n<th>When to Choose<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td><strong>Cloud IDS (Google Cloud)<\/strong><\/td>\n<td>Managed network IDS for VPC traffic<\/td>\n<td>Managed operations, integrates with Packet Mirroring + Cloud Logging, scalable<\/td>\n<td>Detect-only (not inline), requires mirroring design, regional footprint<\/td>\n<td>You want managed IDS detections without running appliances<\/td>\n<\/tr>\n<tr>\n<td><strong>Self-managed IDS (Suricata\/Snort on Compute Engine)<\/strong><\/td>\n<td>Full control and customization<\/td>\n<td>Complete control over rules, tuning, packet capture options<\/td>\n<td>High ops overhead (patching, scaling, HA), capacity planning<\/td>\n<td>You need custom IDS logic or specialized workflows and accept ops burden<\/td>\n<\/tr>\n<tr>\n<td><strong>Palo Alto \/ Check Point \/ Fortinet virtual appliances<\/strong><\/td>\n<td>Inline enforcement + advanced security stacks<\/td>\n<td>Can do inline NGFW\/IPS, mature enterprise features<\/td>\n<td>Higher complexity and cost, HA\/scale design, licensing<\/td>\n<td>You need prevention and deep policy enforcement, not only detection<\/td>\n<\/tr>\n<tr>\n<td><strong>Cloud Armor (WAF\/DDoS for HTTP(S))<\/strong><\/td>\n<td>Web app protection at the edge<\/td>\n<td>Strong for L7 attacks, integrates with HTTP(S) load balancers<\/td>\n<td>Not a general network IDS; doesn\u2019t inspect east-west non-HTTP traffic<\/td>\n<td>You need WAF and edge protection for web apps<\/td>\n<\/tr>\n<tr>\n<td><strong>VPC Flow Logs<\/strong><\/td>\n<td>Network visibility and troubleshooting<\/td>\n<td>Low overhead, great for traffic metadata, easy to analyze<\/td>\n<td>No payload inspection; limited for exploit detection<\/td>\n<td>You need traffic analytics and baseline behavior, not deep inspection<\/td>\n<\/tr>\n<tr>\n<td><strong>AWS: Traffic Mirroring + partner IDS \/ AWS Network Firewall<\/strong><\/td>\n<td>AWS environments<\/td>\n<td>Native AWS ecosystem options<\/td>\n<td>Different platform; migration effort<\/td>\n<td>Choose if you are on AWS<\/td>\n<\/tr>\n<tr>\n<td><strong>Azure: Defender for Cloud + Azure Firewall + traffic analysis<\/strong><\/td>\n<td>Azure environments<\/td>\n<td>Native Azure ecosystem options<\/td>\n<td>Different platform; migration effort<\/td>\n<td>Choose if you are on Azure<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<h2 class=\"wp-block-heading\">15. Real-World Example<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Enterprise example (regulated financial services)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> A regulated enterprise runs customer-facing services on Compute Engine and GKE. They need network-based detection evidence and SOC triage workflows for both inbound attacks and lateral movement attempts.<\/li>\n<li><strong>Proposed architecture:<\/strong><\/li>\n<li>Deploy Cloud IDS endpoints per production region (e.g., <code>us-central1<\/code>, <code>us-east1<\/code>).<\/li>\n<li>Use Packet Mirroring to mirror:<ul>\n<li>internet-facing web tier NICs (ingress\/egress)<\/li>\n<li>a subset of sensitive internal subnets (east-west)<\/li>\n<\/ul>\n<\/li>\n<li>Send Cloud IDS threat logs to:<ul>\n<li>Cloud Logging in a centralized security project<\/li>\n<li>BigQuery for correlation with VPC Flow Logs<\/li>\n<li>SIEM via Pub\/Sub\/Dataflow (if used)<\/li>\n<\/ul>\n<\/li>\n<li>Configure log-based alerting for high-severity detections and on-call paging.<\/li>\n<li><strong>Why Cloud IDS was chosen:<\/strong><\/li>\n<li>Managed IDS operations; faster rollout than appliance fleets.<\/li>\n<li>Strong integration with Google Cloud Logging and existing SOC tooling.<\/li>\n<li><strong>Expected outcomes:<\/strong><\/li>\n<li>Reduced time to detect scanning\/exploit behavior.<\/li>\n<li>Central audit evidence for security monitoring.<\/li>\n<li>Better incident correlation (flow logs + threat detections).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Startup \/ small-team example (SaaS on Compute Engine)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> A small SaaS team has limited security staff but wants better visibility into attacks against their API and admin endpoints.<\/li>\n<li><strong>Proposed architecture:<\/strong><\/li>\n<li>Deploy one Cloud IDS endpoint in the primary region.<\/li>\n<li>Mirror only the API backend MIG instances and the bastion host.<\/li>\n<li>Keep short log retention in Cloud Logging; export only high severity to a low-touch alerting channel.<\/li>\n<li><strong>Why Cloud IDS was chosen:<\/strong><\/li>\n<li>Minimal operational overhead.<\/li>\n<li>Quick deployment using managed service + Packet Mirroring.<\/li>\n<li><strong>Expected outcomes:<\/strong><\/li>\n<li>Early warning of scans and exploit attempts.<\/li>\n<li>Improved security maturity without building an IDS platform internally.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">16. FAQ<\/h2>\n\n\n\n<p>1) <strong>Is Cloud IDS an IPS?<\/strong><br\/>\nNo. Cloud IDS is intrusion <strong>detection<\/strong> (out-of-band). It analyzes mirrored traffic and generates detections; it does not block traffic.<\/p>\n\n\n\n<p>2) <strong>How does Cloud IDS see my traffic?<\/strong><br\/>\nIt uses <strong>VPC Packet Mirroring<\/strong> to receive a copy of packets from selected sources and analyzes that mirrored stream.<\/p>\n\n\n\n<p>3) <strong>Does Cloud IDS inspect all traffic in my VPC by default?<\/strong><br\/>\nNo. It only inspects the traffic you choose to mirror via Packet Mirroring policies.<\/p>\n\n\n\n<p>4) <strong>Is Cloud IDS regional or global?<\/strong><br\/>\nThe Cloud IDS endpoint is <strong>regional<\/strong>. Plan one endpoint per region for coverage.<\/p>\n\n\n\n<p>5) <strong>Can Cloud IDS monitor GKE traffic?<\/strong><br\/>\nIt can monitor traffic that traverses mirrorable interfaces (often node NICs). Exact coverage depends on your GKE networking mode and traffic path\u2014verify in official docs and test in your environment.<\/p>\n\n\n\n<p>6) <strong>Can Cloud IDS monitor serverless (Cloud Run \/ Cloud Functions) traffic?<\/strong><br\/>\nNot directly unless traffic traverses VPC interfaces you can mirror (for example, via certain architectures). In many cases, serverless ingress is handled by managed infrastructure not directly mirrorable\u2014verify your design.<\/p>\n\n\n\n<p>7) <strong>Where do detections appear?<\/strong><br\/>\nDetections are written to <strong>Cloud Logging<\/strong> as Cloud IDS threat logs.<\/p>\n\n\n\n<p>8) <strong>Can I export Cloud IDS detections to my SIEM?<\/strong><br\/>\nYes. Use <strong>Cloud Logging sinks<\/strong> to export to Pub\/Sub, BigQuery, or Cloud Storage, then forward to your SIEM.<\/p>\n\n\n\n<p>9) <strong>How long does it take for detections to show up?<\/strong><br\/>\nIt varies. Endpoint provisioning can take minutes, and detections depend on traffic and signature matches. Logs often appear shortly after relevant traffic occurs.<\/p>\n\n\n\n<p>10) <strong>Why am I not seeing any detections?<\/strong><br\/>\nCommon reasons: your traffic doesn\u2019t match signatures, mirroring policy isn\u2019t applied correctly, filters are too restrictive, or you\u2019re not querying the right logs. Use broad log searches like <code>search(\"cloudids\")<\/code>.<\/p>\n\n\n\n<p>11) <strong>Does Packet Mirroring impact performance?<\/strong><br\/>\nPacket Mirroring duplicates traffic; it can increase bandwidth usage. Performance impact depends on traffic volume and mirroring scope. Start small and measure.<\/p>\n\n\n\n<p>12) <strong>What are the main cost drivers?<\/strong><br\/>\nTypically endpoint runtime and the amount of mirrored traffic inspected, plus indirect costs like internal bandwidth and log ingestion\/export.<\/p>\n\n\n\n<p>13) <strong>Can I mirror traffic from multiple subnets\/instances into one endpoint?<\/strong><br\/>\nCommonly yes within the same region\/VPC constraints, using Packet Mirroring selectors. Confirm scale limits and best practices in docs.<\/p>\n\n\n\n<p>14) <strong>How do I control who can view detections?<\/strong><br\/>\nUse IAM on Cloud Logging (and any exported destinations). Restrict access to threat logs to security teams.<\/p>\n\n\n\n<p>15) <strong>Is Cloud IDS suitable for compliance requirements?<\/strong><br\/>\nIt can help by providing monitoring telemetry and audit trails, but compliance depends on your overall controls: retention, access control, incident response processes, and evidence management.<\/p>\n\n\n\n<p>16) <strong>Can Cloud IDS replace Cloud Armor?<\/strong><br\/>\nNo. Cloud Armor is primarily edge protection (WAF\/DDoS) for HTTP(S) load balancing. Cloud IDS is network IDS based on mirrored traffic inspection. They address different layers and are often complementary.<\/p>\n\n\n\n<p>17) <strong>Should I mirror all traffic to be safe?<\/strong><br\/>\nUsually no. Mirroring all traffic can be expensive and noisy. A targeted strategy guided by a threat model is more effective.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">17. Top Online Resources to Learn Cloud IDS<\/h2>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Resource Type<\/th>\n<th>Name<\/th>\n<th>Why It Is Useful<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>Official documentation<\/td>\n<td>Cloud IDS docs \u2014 https:\/\/cloud.google.com\/intrusion-detection-system\/docs<\/td>\n<td>Primary source for concepts, endpoint lifecycle, logging, and limitations<\/td>\n<\/tr>\n<tr>\n<td>Official pricing<\/td>\n<td>Cloud IDS pricing \u2014 https:\/\/cloud.google.com\/intrusion-detection-system\/pricing<\/td>\n<td>Current SKUs, billing dimensions, regional notes<\/td>\n<\/tr>\n<tr>\n<td>Pricing tool<\/td>\n<td>Google Cloud Pricing Calculator \u2014 https:\/\/cloud.google.com\/products\/calculator<\/td>\n<td>Build an estimate using your expected endpoints and traffic<\/td>\n<\/tr>\n<tr>\n<td>Related doc<\/td>\n<td>VPC Packet Mirroring docs \u2014 https:\/\/cloud.google.com\/vpc\/docs\/packet-mirroring<\/td>\n<td>Required to feed traffic into Cloud IDS; selectors, filters, quotas<\/td>\n<\/tr>\n<tr>\n<td>Related doc<\/td>\n<td>Cloud Logging overview \u2014 https:\/\/cloud.google.com\/logging\/docs<\/td>\n<td>Querying, retention, exporting, and alerting on threat logs<\/td>\n<\/tr>\n<tr>\n<td>Related doc<\/td>\n<td>Log sinks \/ routing \u2014 https:\/\/cloud.google.com\/logging\/docs\/routing\/overview<\/td>\n<td>Export Cloud IDS logs to SIEM pipelines<\/td>\n<\/tr>\n<tr>\n<td>Related doc<\/td>\n<td>Cloud Monitoring alerting \u2014 https:\/\/cloud.google.com\/monitoring\/alerts<\/td>\n<td>Build alerting workflows from log-based metrics<\/td>\n<\/tr>\n<tr>\n<td>Security reference<\/td>\n<td>Security Command Center docs \u2014 https:\/\/cloud.google.com\/security-command-center\/docs<\/td>\n<td>Central security management; validate ingestion paths for IDS logs\/findings<\/td>\n<\/tr>\n<tr>\n<td>CLI reference<\/td>\n<td>Google Cloud CLI (gcloud) \u2014 https:\/\/cloud.google.com\/sdk\/gcloud<\/td>\n<td>Automation and repeatable lab execution<\/td>\n<\/tr>\n<tr>\n<td>Training platform<\/td>\n<td>Google Cloud Skills Boost \u2014 https:\/\/www.cloudskillsboost.google<\/td>\n<td>Hands-on labs and guided quests (search for Cloud IDS \/ Packet Mirroring)<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<h2 class=\"wp-block-heading\">18. Training and Certification Providers<\/h2>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Institute<\/th>\n<th>Suitable Audience<\/th>\n<th>Likely Learning Focus<\/th>\n<th>Mode<\/th>\n<th>Website URL<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>DevOpsSchool.com<\/td>\n<td>Cloud\/DevOps engineers, SREs, platform teams<\/td>\n<td>Google Cloud operations, networking fundamentals, security tooling overview<\/td>\n<td>Check website<\/td>\n<td>https:\/\/www.devopsschool.com<\/td>\n<\/tr>\n<tr>\n<td>ScmGalaxy.com<\/td>\n<td>Engineers and students<\/td>\n<td>DevOps\/SCM plus cloud basics; may include security and networking tracks<\/td>\n<td>Check website<\/td>\n<td>https:\/\/www.scmgalaxy.com<\/td>\n<\/tr>\n<tr>\n<td>CLoudOpsNow.in<\/td>\n<td>Cloud ops practitioners<\/td>\n<td>Cloud operations, monitoring, reliability, and practical implementation guidance<\/td>\n<td>Check website<\/td>\n<td>https:\/\/www.cloudopsnow.in<\/td>\n<\/tr>\n<tr>\n<td>SreSchool.com<\/td>\n<td>SREs, ops engineers<\/td>\n<td>Reliability engineering practices, monitoring\/alerting, incident response<\/td>\n<td>Check website<\/td>\n<td>https:\/\/www.sreschool.com<\/td>\n<\/tr>\n<tr>\n<td>AiOpsSchool.com<\/td>\n<td>Ops + automation practitioners<\/td>\n<td>AIOps concepts, automated operations, observability pipelines<\/td>\n<td>Check website<\/td>\n<td>https:\/\/www.aiopsschool.com<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<h2 class=\"wp-block-heading\">19. Top Trainers<\/h2>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Platform\/Site<\/th>\n<th>Likely Specialization<\/th>\n<th>Suitable Audience<\/th>\n<th>Website URL<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>RajeshKumar.xyz<\/td>\n<td>DevOps\/cloud training content<\/td>\n<td>Beginners to intermediate engineers<\/td>\n<td>https:\/\/www.rajeshkumar.xyz<\/td>\n<\/tr>\n<tr>\n<td>devopstrainer.in<\/td>\n<td>DevOps and cloud training<\/td>\n<td>Engineers seeking practical guidance<\/td>\n<td>https:\/\/www.devopstrainer.in<\/td>\n<\/tr>\n<tr>\n<td>devopsfreelancer.com<\/td>\n<td>Freelance DevOps enablement<\/td>\n<td>Teams needing short-term training\/support<\/td>\n<td>https:\/\/www.devopsfreelancer.com<\/td>\n<\/tr>\n<tr>\n<td>devopssupport.in<\/td>\n<td>DevOps support and training<\/td>\n<td>Ops teams needing hands-on help<\/td>\n<td>https:\/\/www.devopssupport.in<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<h2 class=\"wp-block-heading\">20. Top Consulting Companies<\/h2>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Company Name<\/th>\n<th>Likely Service Area<\/th>\n<th>Where They May Help<\/th>\n<th>Consulting Use Case Examples<\/th>\n<th>Website URL<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>cotocus.com<\/td>\n<td>Cloud\/DevOps consulting<\/td>\n<td>Architecture, implementation, automation, operations<\/td>\n<td>Designing Packet Mirroring scope; setting up log export pipelines; operational runbooks<\/td>\n<td>https:\/\/cotocus.com<\/td>\n<\/tr>\n<tr>\n<td>DevOpsSchool.com<\/td>\n<td>DevOps\/cloud consulting &amp; enablement<\/td>\n<td>Training + implementation support<\/td>\n<td>Cloud IDS pilot rollout; IAM model design; Cloud Logging\/SIEM integration patterns<\/td>\n<td>https:\/\/www.devopsschool.com<\/td>\n<\/tr>\n<tr>\n<td>DEVOPSCONSULTING.IN<\/td>\n<td>DevOps consulting<\/td>\n<td>Platform engineering, CI\/CD, cloud operations<\/td>\n<td>Standardizing IaC for IDS endpoints and mirroring policies; monitoring\/alerting integration<\/td>\n<td>https:\/\/www.devopsconsulting.in<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<h2 class=\"wp-block-heading\">21. Career and Learning Roadmap<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">What to learn before Cloud IDS<\/h3>\n\n\n\n<p>To get real value from Cloud IDS in Google Cloud Networking, learn:\n&#8211; <strong>VPC fundamentals<\/strong>: subnets, routes, firewall rules, shared VPC concepts\n&#8211; <strong>Compute Engine networking<\/strong>: NICs, tags, service accounts\n&#8211; <strong>Cloud Logging<\/strong>: Logs Explorer, log-based metrics, sinks, retention\n&#8211; <strong>Security basics<\/strong>: IDS vs IPS, threat modeling, incident response basics\n&#8211; <strong>IAM<\/strong>: roles, least privilege, audit logs<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">What to learn after Cloud IDS<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Detection engineering<\/strong>: alert tuning, triage workflows, severity mapping<\/li>\n<li><strong>SIEM integrations<\/strong>: Pub\/Sub + Dataflow patterns, BigQuery analytics<\/li>\n<li><strong>Network security enforcement<\/strong>: firewall policies, Cloud Armor, and NGFW\/IPS solutions where appropriate<\/li>\n<li><strong>Zero trust and segmentation<\/strong>: microsegmentation, identity-aware access patterns<\/li>\n<li><strong>Operational excellence<\/strong>: SLOs for detection pipelines, on-call playbooks, postmortems<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Job roles that use it<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Cloud Security Engineer<\/li>\n<li>Security Operations (SOC) Analyst<\/li>\n<li>Detection Engineer<\/li>\n<li>Cloud Network Engineer (security-focused)<\/li>\n<li>SRE \/ Platform Engineer (security telemetry pipelines)<\/li>\n<li>DevSecOps Engineer<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Certification path (if available)<\/h3>\n\n\n\n<p>There isn\u2019t a Cloud IDS-specific certification commonly listed as a standalone credential. Relevant Google Cloud certifications and learning paths to consider:\n&#8211; Google Cloud security certifications (verify current names in Google Cloud certification catalog)\n&#8211; Google Cloud networking certifications (verify current names)<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Project ideas for practice<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Build a <strong>multi-region IDS design<\/strong> with endpoints per region and centralized logging.<\/li>\n<li>Implement <strong>log routing<\/strong>: Cloud IDS \u2192 Logging sink \u2192 BigQuery \u2192 dashboards for detections.<\/li>\n<li>Create <strong>alerting<\/strong>: log-based metrics by severity and service, route to on-call.<\/li>\n<li>Write an <strong>IaC module<\/strong> (Terraform) for standardized endpoint + mirroring policy (verify provider support and fields).<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">22. Glossary<\/h2>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Cloud IDS<\/strong>: Google Cloud managed intrusion detection service that analyzes mirrored VPC traffic and produces threat detections.<\/li>\n<li><strong>IDS (Intrusion Detection System)<\/strong>: Detects suspicious activity; typically generates alerts\/logs but does not block traffic.<\/li>\n<li><strong>IPS (Intrusion Prevention System)<\/strong>: Detects and blocks malicious traffic inline (not what Cloud IDS provides).<\/li>\n<li><strong>VPC (Virtual Private Cloud)<\/strong>: Google Cloud virtual network containing subnets, routes, and firewall rules.<\/li>\n<li><strong>Packet Mirroring<\/strong>: VPC feature that copies packets from selected sources and sends them to a collector for analysis.<\/li>\n<li><strong>Cloud IDS endpoint<\/strong>: Regional resource that serves as the destination collector for mirrored traffic inspection.<\/li>\n<li><strong>Threat detection \/ signature<\/strong>: A rule\/pattern used by an IDS engine to identify suspicious or known malicious traffic.<\/li>\n<li><strong>Cloud Logging<\/strong>: Central service for storing and querying logs; Cloud IDS writes detections here.<\/li>\n<li><strong>Log sink<\/strong>: A Cloud Logging routing rule that exports logs to destinations like BigQuery, Pub\/Sub, or Cloud Storage.<\/li>\n<li><strong>SIEM<\/strong>: Security Information and Event Management system for centralized security analytics and alerting.<\/li>\n<li><strong>SOC<\/strong>: Security Operations Center team\/process for monitoring and responding to security events.<\/li>\n<li><strong>Least privilege<\/strong>: Security principle of granting only the minimal permissions necessary to perform a task.<\/li>\n<li><strong>Inter-zone egress<\/strong>: Network data transfer between zones that can incur charges, depending on traffic path and service.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">23. Summary<\/h2>\n\n\n\n<p>Cloud IDS is Google Cloud\u2019s managed <strong>network intrusion detection<\/strong> service in the <strong>Networking<\/strong> category. It inspects <strong>mirrored VPC traffic<\/strong> (via Packet Mirroring), detects suspicious activity using managed IDS capabilities, and writes detections to <strong>Cloud Logging<\/strong> for triage, alerting, and export.<\/p>\n\n\n\n<p>It matters because it provides deep network threat visibility without requiring you to run and scale IDS appliances yourself. Architecturally, it fits best when you can define a clear mirroring strategy (critical tiers, sensitive subnets, admin paths) and when you already operate centralized logging and incident response workflows.<\/p>\n\n\n\n<p>Cost and security success depend on:\n&#8211; controlling <strong>mirrored traffic volume<\/strong> (primary cost driver)\n&#8211; locking down <strong>IAM<\/strong> for endpoint\/mirroring changes and log access\n&#8211; building a sustainable <strong>alerting and triage<\/strong> process to avoid noise<\/p>\n\n\n\n<p>Use Cloud IDS when you want managed IDS detections for VPC workloads; consider other tools when you need inline prevention or when your workloads aren\u2019t mirrorable. Next, deepen your skills with Packet Mirroring design patterns, Cloud Logging routing, and SIEM integration to make Cloud IDS operationally effective.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Networking<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[51,50],"tags":[],"class_list":["post-718","post","type-post","status-publish","format-standard","hentry","category-google-cloud","category-networking"],"_links":{"self":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/posts\/718","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/comments?post=718"}],"version-history":[{"count":0,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/posts\/718\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/media?parent=718"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/categories?post=718"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/tags?post=718"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}