> ## Documentation Index
> Fetch the complete documentation index at: https://docs.plerion.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Managing GCP workload scanning

> Change what GCP workload scanning covers, re-run the access command, understand and control cost, and turn scanning off or remove it

With **[GCP workload scanning](/guides/integrations/gcp/workload-scanning/overview)** turned on, you manage it from the GCP organization integration's detail page: settings, the access command, cost, and turning scanning off or removing it.

***

## Where settings live

On the integration's detail page:

* **Capabilities** > `Edit` opens the Capabilities panel, with the same **Workload scanning** capability, workload scan type, workload, billing account, networking, and region settings as the wizard.
* `Update Plerion access` opens the Plerion access panel with the **Script** and **Terraform** tabs. The command shown there is generated for your current settings, so re-running it brings the grants in Google Cloud in line with what you've selected.
* **Coverage** > `Edit` opens **Manage projects**, where you choose which projects the integration covers.

Each project under the organization also has its own Capabilities panel. There you can turn workload scanning off for that project, or narrow its scan types, workloads, and regions below the organization's settings. A project's region override can only narrow the organization's list, not add to it.

***

## Re-running the access command

The onboarding script and Terraform template are safe to run again at any time. Re-run them after changing a capability or workload type, or when the Capabilities panel shows the **Update Plerion access in Google Cloud** warning.

Re-running the **script**:

* Finds the existing scanning project by the `plerion-scan=true` label onboarding gave it, and fixes anything missing rather than creating a second project. If it finds more than one project with that label in the organization, it stops and asks you to resolve the duplicate.
* Re-links the billing account, so passing a different `--billing-account` moves the scanning project to that account.
* Creates or removes the type-gated roles and scanner service accounts to match the `--workload-types` in the generated command (see [Changing workload types](#changing-workload-types)).
* Never removes `PlerionWorkloadScan` or `PlerionWorkloadScanSnapshots`, the grants that come with the capability itself. See [Access and permissions](/guides/integrations/gcp/workload-scanning/access-and-permissions#summary) for what each role is.

Re-running **Terraform** applies the updated variables (`enable_workload_scanning`, `billing_account_id`, `workload_nat`, `workload_regions`, `workload_types`) against your existing state. Keep using the same state; to run it again from a fresh state, set `scan_project_id` to the existing scanning project. Terraform also doesn't re-link billing on an existing scanning project.

***

## Workload regions

**Workload regions** limits scanning to the regions you list, up to 16. Leave it empty to scan workloads wherever they are.

What the setting does depends on your networking mode:

* **Ephemeral external IP**: a scope filter only. Plerion creates subnets on demand in whichever region a scan runs.
* **Cloud NAT**: also the list of regions where onboarding provisions a subnet, a Cloud Router, and Cloud NAT. At least one region is required, and a workload outside the list isn't scanned. After adding a region, re-run the access command so it provisions NAT there.

A change takes effect on the next scan run. A run already in progress finishes with the settings it started with.

<Note>
  In Cloud NAT mode, subnet address ranges are assigned by list position. Reordering the list on its own changes nothing, but reordering it while adding or removing a region at the same time can fail with an address collision. Add or remove regions without reordering the rest.
</Note>

***

## Changing workload types

Turning a workload type off in the Capabilities panel stops new scans of that type from the next run. Turning one on starts them from the next run, once any grant it needs exists.

Some types come with their own role or scanner identity. Plerion can't change your organization's IAM, so creating or removing those is done by the access command, which is generated for the types currently on:

| Workload type | Grant it needs | Created when | Removed when |
| - | - | - | - |
| Compute Engine instances | None beyond the **Workload scanning** capability | | |
| Compute Engine managed instance groups | None beyond the **Workload scanning** capability | | |
| Compute Engine custom images | `PlerionWorkloadScanImageRead` on the tenant service account | You re-run the access command with the type on | You re-run it with the type off |
| Cloud Run, Cloud Functions (2nd gen) | `PlerionWorkloadScanArtifactPull` and the `plerion-scanner-artifact@` service account (shared by both types) | You re-run with either type on | You re-run with **both** off |
| Cloud Functions (1st gen) | `PlerionWorkloadScanFunctionSourceRead` and the `plerion-scanner-source@` service account | You re-run with the type on | You re-run with the type off |

Turning off Cloud Run while Cloud Functions (2nd gen) stays on (or the reverse) leaves the shared artifact grant in place, because the remaining type still needs it. See [Access and permissions](/guides/integrations/gcp/workload-scanning/access-and-permissions#organization-level-roles-gated-by-workload-type) for what each grant allows.

<Note>
  An integration that turned on the **Workload scanning** capability before newer workload types existed has only **Compute Engine instances** on. The other types stay off until you turn them on in the Capabilities panel, save, and re-run the access command.
</Note>

***

## Cost

Scanning compute is billed to the scanning project on your own Google Cloud bill. There is no separate Plerion charge for it. Every resource Plerion creates is labeled with the owning tenant, integration, and execution, so you can filter for it in billing reports.

The table below estimates one scan run for a project with 10 workloads of each type, at Google's list prices. Your bill depends on disk sizes, scan duration, region, and any committed-use or free-tier discounts, so treat these as an order of magnitude rather than a quote.

| Workload (10 of each) | Compute used | Estimated cost per run | Range | Basis |
| - | - | - | - | - |
| Compute Engine instances | 1 shared scanner VM | \~\$0.05 | \$0.02–0.10 | Estimated: 20–40 minutes of VM time (\~2–3¢) plus 10 snapshots and scan disks (\~1–2¢). Grows with disk size |
| Compute Engine custom images | 1 shared scanner VM (its own batch) | \~\$0.04 | \$0.02–0.10 | Estimated: as for instances, without the snapshot step |
| Compute Engine managed instance groups (one image each) | 1 shared scanner VM (its own batch) | \~\$0.05 | \$0.02–0.10 | Estimated: 10 sampled member disks, same mechanics as instances |
| Cloud Run services | 10 Cloud Run job executions | \~\$0.01 | Roughly fixed | Measured: about \$0.0008 and 30 seconds per scan at 1 vCPU / 2 GiB |
| Cloud Functions (2nd gen) | 10 Cloud Run job executions (same job as Cloud Run) | \~\$0.01 | Roughly fixed | Measured: same rate as Cloud Run |
| Cloud Functions (1st gen) | 10 Cloud Run job executions (its own job) | \~\$0.02 | Roughly fixed | Estimated: same shape at 1 vCPU / 4 GiB |

Beyond per-run compute:

* **Cloud NAT**, if you chose that networking mode, is a standing charge per provisioned region plus data processing, billed whether or not a scan is running. See [Google's Cloud NAT pricing](https://cloud.google.com/vpc/network-pricing#nat).
* **Ephemeral external IP** mode has no standing cost. Nothing stays running between scans.
* Cloud Run jobs cost nothing while idle.
* A disk scan run is bounded by a 12-hour timeout, so a single run's cost has a ceiling.

***

## Turning workload scanning off

Turning the **Workload scanning** capability off in the Capabilities panel stops Plerion from starting new workload scans as soon as you save. A run already in progress finishes and cleans up after itself as usual.

It does **not** delete anything in Google Cloud. The roles stay granted until you remove them, and the scanning project, its network, and any Cloud NAT stay in your organization and keep accruing their standing costs until you delete the project. The panel says so under the heading **Access stays granted in Google Cloud**.

***

## Removing workload scanning entirely

To delete the scanning project and everything in it:

<Tabs>
  <Tab title="Script">
    Re-run the onboarding script with `--remove-workload-scanning`. It deletes the scanning project (network, Cloud NAT, scanner service accounts, and their bindings) and the organization-level `PlerionWorkloadScanArtifactPull`, `PlerionWorkloadScanFunctionSourceRead`, and `PlerionWorkloadScanImageRead` roles and bindings if they exist.

    It doesn't remove `PlerionWorkloadScan` or `PlerionWorkloadScanSnapshots`, since those belong to the **Workload scanning** capability rather than the scanning project. The script prints the `gcloud` commands that remove their bindings. Removing the bindings is what ends the access. The role definitions stay in your organization. A role with no bindings grants nothing, so leaving them is safe. To delete them, run `gcloud iam roles delete <role> --organization=<org-id>`.
  </Tab>

  <Tab title="gcloud">
    Delete the scanning project directly:

    ```bash theme={"system"}
    gcloud projects delete <scanning-project-id> --quiet
    ```

    Find the project ID in your Google Cloud console by searching for the label `plerion-scan=true`, or at the end of the onboarding script's output (`Scanning project: <id>`). This leaves the organization-level roles in place.
  </Tab>

  <Tab title="Terraform">
    Set `enable_workload_scanning = false` and remove the workload types from `workload_types`, then apply. Or run `terraform destroy` to remove everything the template created, including the base integration.
  </Tab>
</Tabs>

<Warning>
  Deleting the GCP organization integration in Plerion doesn't delete the scanning project or any role in Google Cloud. Plerion has no permission to change your organization's IAM or delete your projects. Remove workload scanning with one of the methods above first, or afterward.
</Warning>

***

## Next step

* [FAQ](/guides/integrations/gcp/workload-scanning/faq)


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.