Google CloudCompute EngineStorage

`google_compute_attached_disk` cost estimation

Attaches an existing persistent disk to a Compute Engine instance. The attachment is free. Cost lives on the disk itself: provisioned capacity by disk type, plus snapshots and regional replication.

The google_compute_attached_disk resource connects an already-created persistent disk to a running instance without defining the disk inline in the instance block. It is a lifecycle convenience: it lets you attach and detach a disk independently of the VM, which is useful when a data disk should outlive or move between instances. The attachment itself is free. Google bills the underlying google_compute_disk, not the act of attaching it.

Persistent disk pricing is by provisioned capacity and disk type, billed whether or not the disk is full and whether or not it is attached. Standard (pd-standard) is about $0.04/GB-month, Balanced (pd-balanced) about $0.10/GB-month, and SSD (pd-ssd) about $0.17/GB-month. Regional persistent disks replicate synchronously across two zones and cost roughly double their zonal equivalent. Hyperdisk separates capacity, throughput, and IOPS into individually provisioned and billed dimensions for high-performance workloads. Snapshots of these disks bill separately at about $0.026/GB-month for the incremental data stored.

The cost-adjacent gotcha that this exact resource makes easy is the orphaned disk. Because the attachment is decoupled from the VM, detaching a disk (or deleting an instance with a disk whose auto-delete is off) leaves a persistent disk sitting in the project, still provisioned and still billing every month. A fleet accumulates these over time, and since they are detached they are invisible in most instance-focused reviews. A 500 GB pd-ssd forgotten this way is about $85/month for nothing.

The second gotcha is provisioning too much or too fast a disk type. Teams default new data disks to pd-ssd when pd-balanced or pd-standard would serve the workload, paying up to 4x more per GB for IO they never use. Snapshot schedules also quietly grow: keep too many snapshots and the incremental storage adds up.

c3x flags google_compute_attached_disk as free and attributes capacity, disk type, snapshot, and regional-replication cost to the persistent disk being attached.

Terraform example

A minimal but realistic configuration that C3X can estimate.

resource "google_compute_disk" "data" {
  name = "app-data-disk"
  type = "pd-balanced"
  zone = "us-central1-a"
  size = 200
}

resource "google_compute_instance" "app" {
  name         = "app-server"
  machine_type = "e2-standard-2"
  zone         = "us-central1-a"

  boot_disk {
    initialize_params {
      image = "debian-cloud/debian-12"
    }
  }

  network_interface {
    network = "default"
  }
}

resource "google_compute_attached_disk" "data" {
  disk     = google_compute_disk.data.id
  instance = google_compute_instance.app.id
}

Pricing dimensions

What you actually pay for when you provision google_compute_attached_disk.

Dimension	Unit	What's being charged
Disk attachment	free	Attaching or detaching a disk carries no per-resource charge. The disk bills regardless of attachment state. $0 (free)
Standard persistent disk	per GB-month	pd-standard provisioned capacity, billed on allocated size whether or not it is full. about $0.04/GB-month
Balanced persistent disk	per GB-month	pd-balanced SSD-backed capacity, a middle ground for most general workloads. about $0.10/GB-month
SSD persistent disk	per GB-month	pd-ssd high-performance capacity. Regional variants replicate across two zones at roughly double. about $0.17/GB-month
Snapshot storage	per GB-month	Incremental snapshot data stored for the disk, billed separately from the disk itself. about $0.026/GB-month

Optimization tips

Common ways to reduce google_compute_attached_disk cost without changing the workload.

Hunt down orphaned detached disks

$85/month per orphaned 500 GB pd-ssd

Because the attachment is decoupled from the VM, detached disks keep billing while staying invisible in instance-focused reviews. Regularly list disks with no users and delete the ones nothing needs.

Match disk type to the real IO need

Up to 75% versus SSD on suitable workloads

pd-ssd costs about 4x pd-standard per GB. Many data disks defaulted to SSD would run fine on pd-balanced or pd-standard. Choose the type from the workload's actual throughput and latency needs.

Use regional disks only where you need zonal HA

About 50% versus regional on non-HA disks

Regional persistent disks cost roughly double their zonal equivalent for synchronous cross-zone replication. Use them only for workloads that require surviving a zone failure, not by default.

Trim snapshot retention

Snapshot schedules accumulate incremental storage. Keep a retention policy that matches your recovery needs so old snapshots do not pile up at $0.026/GB-month.

FAQ

Does attaching a disk cost anything?

No. The google_compute_attached_disk resource is free. You pay for the underlying persistent disk by provisioned capacity and type, and that charge applies whether the disk is attached, detached, or idle.

Do I still pay for a disk after I detach it?

Yes. A detached persistent disk keeps billing at its full provisioned rate every month until you delete it. This is the most common source of quiet waste with this resource, because detached disks are easy to overlook.

Which disk type is cheapest?

pd-standard at about $0.04/GB-month is the cheapest, followed by pd-balanced at about $0.10 and pd-ssd at about $0.17. Regional versions of each cost roughly double. Pick the lowest type your workload's IO requirements allow.

How are snapshots billed?

Snapshots store incremental data at about $0.026/GB-month, separate from the disk. Only changed blocks since the previous snapshot are stored, but a long schedule with many retained snapshots still accumulates cost over time.