Storage parity

1. The names

Google Cloud	AWS	Azure
Cloud Storage	Amazon S3	Azure Blob Storage
Hyperdisk / Persistent Disk / Local SSD	Amazon EBS / instance store	Azure Managed Disks / temporary disk
Filestore	Amazon EFS	Azure Files, Azure NetApp Files
Transfer Appliance	AWS Snow family	Azure Data Box, Azure Import/Export
Storage Transfer Service	AWS DataSync	Azure Storage Mover / AzCopy

Both published tables agree. Microsoft maps Filestore to two Azure services, which is the honest answer: Azure Files and Azure NetApp Files are different products at different capability levels, and which one a Filestore tier corresponds to depends on the tier (§4).

2. Cold storage — the row most likely to change an archive design

	Google Cloud	AWS	Azure
hot, no minimum	`STANDARD`, `RAPID`	S3 Standard, Express One Zone	hot
~30-day commitment	`NEARLINE` 30 days	Standard-IA, One Zone-IA 30 days	cool 30 days
~90-day commitment	`COLDLINE` 90 days	Glacier Instant Retrieval 90 days	cold 90 days
deep archive	`ARCHIVE` 365 days	Glacier Flexible 90 days, Deep Archive 180 days	archive 180 days
retrieval needs a restore/rehydrate step?	not described on the classes page	yes for Glacier Flexible and Deep Archive — "not available for real-time access"	yes — archive is offline, rehydration takes "up to 15 hours"
minimum billable object size	not stated on this page	128 KB for IA and Glacier IR	not stated as a size

Three estimate-bearing facts, in order of how much money they move.

Google Cloud's deepest class commits 365 days; AWS's and Azure's commit 180. An archive estate moved

to Google Cloud doubles its minimum commitment, and lifecycle rules tuned to a 180-day floor will incur early-deletion charges on Google Cloud. Re-tune every lifecycle rule on the way in. This is the single most reliable way to be wrong about the cost of a Google Cloud archive.

Google Cloud's archive has no documented rehydration step; the other two do. AWS Glacier Flexible and

Deep Archive are "not available for real-time access" and must be restored; Azure archive is offline and takes up to 15 hours to rehydrate. So an application that reads archived data directly works on Google Cloud and breaks on the other two without a restore workflow — which is code, not configuration. Moving off Google Cloud archive, budget that workflow.

AWS charges a 128 KB minimum billable object size on IA and Glacier IR classes, and does not monitor

Intelligent-Tiering objects below 128 KB at all. An estate of many small objects costs materially more on AWS cold classes than the raw byte count suggests. No equivalent floor appears on the Google Cloud classes page read here.

Where the tier lives also differs. Azure's tier is per block blob with an account-level default, and append and page blobs cannot be tiered at all. Google Cloud's class is per object with a bucket default that does not affect existing objects. AWS's class is per object. The practical consequence: on Azure, "move the account to cool" is a real operation with per-blob write charges; on Google Cloud the equivalent sentence does nothing to data already there.

3. Block storage — a different performance model, not a different price list

	Google Cloud	AWS	Azure
performance independent of capacity	Hyperdisk — yes	gp3 / io2 — yes	Premium SSD v2 / Ultra — yes
performance tied to capacity	Persistent Disk — yes	gp2 — yes	Premium SSD (P-tiers) — tiered by size
ephemeral local media	Local SSD — lost if the VM stops, crashes or fails	instance store	temporary disk
cross-zone synchronous replication	Regional Persistent Disk; Hyperdisk Balanced High Availability	— (EBS is zonal; io2 Block Express multi-attach is not cross-AZ)	ZRS managed disks

Estimate consequence. Google Cloud offers cross-zone synchronous block replication as a disk property, in two different families. That removes an application-level replication requirement from some designs moving in — and adds one back for designs moving out to AWS, where EBS has no cross-AZ synchronous equivalent in the pages read here. Check this before promising a like-for-like RPO.

And the Hyperdisk/Persistent Disk split means a capacity figure carried over from a gp2-style estate is probably too large: it was sized for IOPS, not for bytes (reference/storage/persistent-disk-and-hyperdisk.md §1).

4. Shared filesystems — the capacity floor is the constraint

Filestore's smallest current instances start at 1 TiB (Zonal) and 100 GiB (Regional). Amazon EFS and Azure Files both scale from effectively nothing. So an estate of many small NFS exports maps badly onto Filestore and well onto EFS or Azure Files, and that is a re-modelling decision — consolidate the exports, or move the data to object storage — rather than a line item.

The protocol column matters too: Filestore's legacy tiers are NFSv3 only, so a workload needing NFSv4.1 locking semantics is restricted to the current tiers (reference/storage/filestore.md §2).

5. Pricing dimension (never a price)

Dimension	Google Cloud	AWS	Azure
object storage	per GB-month by class, operations, retrieval fees on the cold classes, network egress	same shape, plus a 128 KB minimum billable object size on IA/Glacier IR, plus Intelligent-Tiering monitoring fees	same shape, plus prorated early-deletion charges, plus per-10,000-operation tier-change charges
block storage	provisioned capacity; provisioned IOPS and throughput separately on Hyperdisk	provisioned capacity plus provisioned IOPS/throughput on gp3/io2	provisioned capacity by tier; separate IOPS on v2/Ultra
shared filesystem	provisioned capacity per tier (with a floor)	provisioned or elastic capacity	provisioned capacity per tier

6. What this guide cannot tell you

Whether a given object's access pattern justifies a cold class on any of the three. That needs the access log, not a table. And it cannot tell you the egress cost of the migration itself, which on a large estate is frequently larger than a year of the storage — see guides/parity-and-migration-method.md, which treats egress as a first-class line.