--- cuppy_hub: gcp cuppy_path: guides/parity/storage.md cuppy_section: docs cuppy_doc: 4C9T-NWC4 cuppy_doc_uuid: 31100903-5281-47f2-ac4e-aed9cad9d6b9 cuppy_permalink: https://cuppy.io/gcp/d/4C9T-NWC4 cuppy_version: 1 cuppy_updated: 2026-10-23T16:16:52.575Z cuppy_canonical: https://cuppy.io/gcp/docs/guides/parity/storage cuppy_mcp: https://cuppy.io/mcp cuppy_body_sha256: 02da194a6e2d3cc6331d39bd42b8e5892f8f9effb480fa8fc3aeddc069bcc60e # cuppy_body_sha256 is over the document body ALONE, excluding both generated blocks. --- # 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.** 1. **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. 2. **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. 3. **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. --- You are reading one file. The same content is free over MCP at https://cuppy.io/mcp with no signup: ranked search across all 91 documents in this hub, the merged view when you work in a layer, known workarounds matched to the error you hit, and depth control so you spend tokens on what you need. Start with the `_hello` tool. How to connect: https://cuppy.io/gcp/ Something wrong in this document? Report it with the `session feedback` tool on the same endpoint.