Google Cloud Storage 指南：儲存類別、權限、生命週期與防刪除

Cloud Storage 看起來像「放檔案的地方」，真正上線後卻常同時牽涉位置、存取權、保留期限、刪除復原與網路費用。

最典型的誤判有三種：為了省 storage cost，把會頻繁覆寫的資料放進 Archive；以為開了 Soft Delete 就等於完整版本控制；或把 bucket 設成 private，卻在其他層級留下一個 allUsers 的 IAM binding。

這篇不只教你上傳和下載，而是從建立 bucket 前的設計選擇開始，整理一套可以拿去做 side project、production review 與 ACE 題目的判斷方式。

一、先建立正確的物件儲存模型

Cloud Storage 的基本資源有：

• Bucket：物件的容器，決定 location、預設 storage class、namespace 與多項資料保護設定。
• Object：資料本體加上 metadata。一般物件不能就地修改中間一段內容，更新通常是寫入新內容並產生新的 generation。
• Folder / Managed folder：要先看 bucket 使用 Flat Namespace 還是 Hierarchical Namespace，兩者語意不同。

物件 URI 長這樣：

gs://BUCKET_NAME/OBJECT_NAME

例如：

gs://acme-prod-assets/images/products/keyboard.webp

Flat Namespace：斜線通常只是名稱的一部分

傳統 Cloud Storage bucket 使用 Flat Namespace。images/products/keyboard.webp 是一個 object name，工具會把 / 解讀成 delimiter，顯示出類似資料夾的介面，但底層沒有真正的 images 目錄。

這會影響 rename：在 Flat Namespace 中「移動一個大資料夾」通常代表複製或改寫許多物件，再刪除原物件，不是單一 atomic directory operation。

Hierarchical Namespace：真的有 Folder resource

Hierarchical Namespace（HNS）在 bucket 建立時啟用，之後不能切換。它提供真正的 folder resource、atomic folder rename 與較高的初始 QPS，適合 Hadoop、Spark、AI/ML 與其他重視 directory semantics 的資料工作負載。

HNS 不是免費獲得完整 POSIX file system。啟用前要確認限制，例如：

• 必須使用 Uniform Bucket-Level Access。
• Object Versioning、Bucket Lock、object-level ACL 等部分能力不相容。
• Folder 與用來套 IAM 的 managed folder 是不同資源。
• 既有 Flat Namespace bucket 不能直接改成 HNS。

一般網站圖片或備份不一定需要 HNS。若應用只依 prefix 列出物件，Flat Namespace 通常更單純。

二、Bucket location 先決定資料放在哪裡

Location 會影響延遲、可用性、資料落地、複寫與費用。不要只看「multi-region 比較安全」就直接選。

Location 類型	資料配置	適合情境	主要取捨
Region	單一 Region 內冗餘	與同 Region compute 搭配、短期資料	成本與延遲容易控制，但不涵蓋 Region 級災難
Dual-region	指定兩個 Region	跨區冗餘、DR、仍想控制資料位置	複寫與 operation 成本較高，需設計 RPO
Multi-region	一個大地理範圍	全球或跨區內容服務、ad hoc analytics	compute 不一定與實際儲存位置 colocate
Zone	Rapid Bucket 專用	極低延遲、高 I/O 的 AI/ML 或 analytics	Zonal failure domain，產品限制與 API 不同

一個實用原則是先讓 data 和 compute colocate。Cloud Run、GKE、Compute Engine 或 BigQuery 若經常讀取 bucket，把資料放在相容位置通常能降低延遲與不必要的 data transfer。

若選 dual-region，還要區分預設複寫與 Turbo Replication。它們的 RPO 與費用不同，不能只靠「dual」兩個字推斷資料多久會出現在另一區。

三、Storage Class 不只四種，也不只看讀取頻率

一般用途最常見四種 storage class，加上一個針對特殊高效能工作的 Rapid storage：

Storage class	Minimum storage duration	Retrieval fee	常見用途
Standard	無	無	熱資料、短期資料、頻繁讀寫
Nearline	30 天	有	約每月存取、較長期備份
Coldline	90 天	有	約每季存取、DR 資料
Archive	365 天	有	長期保存、很少讀取的資料
Rapid	無	無	Rapid Bucket 的 zonal 高 I/O workload

Nearline、Coldline、Archive 都是線上儲存，讀取時不需要等待離線媒體掛載。差別主要在 storage、operation、retrieval、availability 與 early deletion 的價格模型。

Minimum storage duration 是計費條件

如果 Archive 物件在 30 天後刪除、覆寫，或透過 Lifecycle 轉到其他 class，仍可能產生剩餘 minimum duration 的 early deletion charge。

因此這些資料通常不適合較冷的 class：

• 生命週期很短的 temporary object
• 會被固定檔名反覆覆寫的輸出
• 不能預測何時刪除的使用者上傳
• retrieval volume 很大、只是讀取次數看起來少的資料

真正要比的是整體成本：

總成本 = storage + operation + retrieval + data transfer
       + early deletion + replication + data protection copies

不確定存取模式時，評估 Autoclass

Autoclass 會依實際存取模式管理物件的 storage class，適合物件數多、存取模式不容易預測的 bucket。它不是必然比較便宜：經常被其他 Google Cloud 服務讀取、資料生命週期已很明確，或需要自行控制轉換時，手動 class 加 Lifecycle 可能更適合。

啟用 Autoclass 後不能再用 Lifecycle 的 SetStorageClass action。評估時也要讀 Autoclass management fee、enablement charge 與各 terminal storage class 的規則。

Rapid Bucket 是另一種工作負載，不是一般歸檔選項

Rapid Bucket 將 bucket 放在 zone，使用 Rapid storage，主打與 compute colocate 的低延遲和高吞吐。它支援 appendable object 等不同能力，但同時要求 HNS、Uniform Bucket-Level Access，也有專用 API 與相容性限制。

除非 workload 能證明 object storage latency 是 GPU、training checkpoint 或 analytics pipeline 的瓶頸，否則一般應用仍從 regional Standard 開始比較合理。

四、建立 Bucket 與基本操作

Bucket name 是全域名稱，會出現在 URI 與 log 中，不要放 email、客戶名稱等敏感資訊。

下面建立一個 regional Standard bucket，並把 access control 收斂到 IAM：

PROJECT_ID="$(gcloud config get-value project)"
BUCKET="gs://${PROJECT_ID}-assets-202607"

gcloud storage buckets create "$BUCKET" \
  --location=asia-east1 \
  --default-storage-class=STANDARD \
  --uniform-bucket-level-access

gcloud storage buckets update "$BUCKET" \
  --public-access-prevention

建立前先確認 PROJECT_ID，並換成符合自己環境且全域唯一的名稱。Public Access Prevention 適合確定不該公開的資料；若 bucket 要做公開網站來源，則需用不同的存取設計。

常用 gcloud storage 指令

# 上傳與下載
gcloud storage cp ./photo.webp "$BUCKET/images/photo.webp"
gcloud storage cp "$BUCKET/images/photo.webp" ./downloads/

# 列出與查看 metadata
gcloud storage ls "$BUCKET/images/"
gcloud storage objects describe "$BUCKET/images/photo.webp"

# 同步目錄：先不要加自動刪除 destination 的選項
gcloud storage rsync -r ./public/ "$BUCKET/public/"

# 刪除前先 describe，確認 project、bucket 和 object generation
gcloud storage rm "$BUCKET/images/photo.webp"

Google Cloud CLI 是官方建議的 Cloud Storage 命令列工具。既有 gsutil 腳本不用盲目逐字替換，因為 wildcard、輸出格式、parallel invocation 與部分 command behavior 不完全相同；先在測試 bucket 驗證。

避免重試蓋掉別人的物件

Cloud Storage 支援 generation 與 metageneration precondition。若「只有目的地不存在時才允許建立」，可以使用 generation match 0：

gcloud storage cp ./report.csv "$BUCKET/reports/report.csv" \
  --if-generation-match=0

若同名 live object 已存在，操作會以 412 Precondition Failed 結束，而不是默默覆寫。對 retry、read-modify-write、delete-after-replace 等流程，precondition 是避免 race condition 的重要工具。

五、存取控制：先讓 IAM 邊界簡單

Uniform Bucket-Level Access

啟用 Uniform Bucket-Level Access（UBLA）後，bucket 與 object 的存取都由 IAM 控制，object ACL 不再生效。Google 一般建議使用 UBLA，它也是 HNS、managed folder、bucket-level IAM Conditions 與 federation principal 的前置條件。

既有 bucket 開啟前要先檢查 ACL usage，否則只靠 object ACL 取得權限的舊應用會突然失效。UBLA 連續啟用 90 天後就不能停用，也不應把 production migration 當成一條無風險的 toggle。

常見角色：

Role	能力
roles/storage.objectViewer	讀取與列出 object
roles/storage.objectCreator	建立 object，但不能覆寫或刪除
roles/storage.objectUser	讀、寫、刪 object，適合一般 object 操作
roles/storage.objectAdmin	完整管理 object
roles/storage.admin	管理 bucket 與 object，權限很大

授權給 service account 的範例：

gcloud storage buckets add-iam-policy-binding "$BUCKET" \
  --member="serviceAccount:asset-reader@${PROJECT_ID}.iam.gserviceaccount.com" \
  --role="roles/storage.objectViewer"

角色要依實際操作選擇，不要因為讀寫失敗就直接改成 storage.admin。

Managed Folder：在同一個 Bucket 內切 IAM 邊界

若不同團隊只應存取特定 prefix，可以評估 managed folder。它是在指定物件 prefix 上套 IAM 的資源，不等於 HNS 的 folder；Flat Namespace 和 HNS bucket 都能使用。

若權限、保留、location 或生命週期需求差異很大，拆成不同 bucket 通常比在同一個 bucket 疊很多例外更容易治理。

Public Access Prevention

Public Access Prevention 會阻止 allUsers 和 allAuthenticatedUsers 透過 IAM 或 ACL 取得公開存取。可以在 bucket 啟用，也能透過 Organization Policy 在 project、folder 或 organization 強制執行。

它不會阻止 Signed URL，因為 Signed URL 的權限來自簽署身分與特定請求，而不是公開 principal。

Signed URL：持有者在期限內就是使用者

Signed URL 適合讓沒有 Google 帳號的客戶，在有限時間內讀取或上傳特定 object。任何拿到 URL 的人都能在期限內執行該請求，所以：

• 有效期只設實際需要的長度。
• 不要把 URL 寫進公開 log、analytics 或聊天頻道。
• upload URL 要限制 HTTP method、content type 與 object path。
• 若需要立即撤銷，Signed URL 不是理想 session 機制；通常要輪替簽署 key 或改變物件／權限。

用 service account impersonation 產生短效 URL，避免下載 JSON key：

gcloud storage sign-url "$BUCKET/reports/monthly.pdf" \
  --impersonate-service-account="url-signer@${PROJECT_ID}.iam.gserviceaccount.com" \
  --duration=15m

呼叫者需要 impersonation 所需權限，簽署 service account 也必須有目標 object 對應權限。不要為了讓指令成功就建立長效 service account key。

六、Lifecycle：自動處理，不代表準時執行

Object Lifecycle Management 會定期檢查物件；符合一條 rule 的所有 condition 時，執行其中一個 action：

• SetStorageClass
• Delete
• AbortIncompleteMultipartUpload

一個分層範例：

{
  "rule": [
    {
      "action": { "type": "SetStorageClass", "storageClass": "NEARLINE" },
      "condition": { "age": 30, "matchesStorageClass": ["STANDARD"] }
    },
    {
      "action": { "type": "SetStorageClass", "storageClass": "COLDLINE" },
      "condition": { "age": 90, "matchesStorageClass": ["NEARLINE"] }
    },
    {
      "action": { "type": "SetStorageClass", "storageClass": "ARCHIVE" },
      "condition": { "age": 365, "matchesStorageClass": ["COLDLINE"] }
    }
  ]
}

gcloud storage buckets update "$BUCKET" \
  --lifecycle-file=./lifecycle.json

設計時要知道：

• Lifecycle 非同步執行，不能拿來當精準排程器。
• 設定變更最多可能需要 24 小時生效，期間舊規則仍可能執行。
• 多條 rule 同時符合時，Delete 優先於 SetStorageClass；多個 class 轉換則選 at-rest 價格最低者。
• Delete 通常會先進入 Soft Delete；若有 Object Versioning，live version 會先變成 noncurrent。
• Retention policy 或 object hold 尚未滿足時，Delete 不會生效。

先用測試資料與 matchesPrefix 驗證，再套到 production。Lifecycle 寫錯時，影響的不是一台 VM，而可能是一整個 bucket 的資料。

七、Soft Delete、Versioning、Retention 解決不同問題

Soft Delete：復原最近刪除或覆寫的資料

Cloud Storage 預設對 bucket 啟用 7 天 Soft Delete，除非組織或使用者選了其他 policy。可設定的保留期為 7 到 90 天，也能停用。

Soft-deleted object 在保留期內可恢復，但仍會產生 storage cost。若 bucket 大量存放短命 temporary object，七天保留可能讓 billable bytes 明顯高於 live data，應依 recovery requirement 調整，而不是因為預設開啟就不檢查。

Object Versioning：保留同名物件的歷史 generation

啟用 Object Versioning 後，覆寫或刪除 live object 時，舊 generation 會成為 noncurrent version。它適合需要找回多個歷史版本的情境，但每個版本都會計費，也要用 Lifecycle 清理。

Soft Delete 與 Versioning 可以一起使用：Versioning 管歷史版本，Soft Delete 再保護被刪除的 version。保護層增加，儲存成本也會增加。HNS bucket 目前不支援 Object Versioning，選 namespace 前要一起決定。

Retention Policy 與 Bucket Lock：強制不能提早刪

Retention Policy 要求 object 在指定期間內不能刪除或取代，適合法規或不可竄改保留。鎖定 policy 後，不能移除或縮短保留期，屬於高風險、接近不可逆的治理動作。

它不是備份：若應用寫入錯誤內容，Retention Policy 只是讓那份內容也不能提早刪。合規保存、操作復原與異地備份仍要分開設計。

快速選擇

需求	優先評估
救回最近誤刪或覆寫	Soft Delete
保留同名物件多個歷史版本	Object Versioning + Lifecycle
法規要求期間內不可刪除	Retention Policy，必要時再 Lock
防止公開曝光	Public Access Prevention，不是 retention
Region 級災難復原	Dual-region、replication 或獨立備份策略

八、一致性與快取：Object List 也是 Strongly Consistent

Cloud Storage 對 bucket listing、object listing、object read-after-write、metadata update 與 delete 提供 strong global consistency。成功上傳後，新的 object 和 listing 應立即可見。

有幾個例外要分清楚：

• IAM 授權或撤銷是 eventually consistent，通常需要傳播時間。
• 刪除後重建同名 bucket 可能需要等待。
• 公開且可快取的 object 可能在 cache lifetime 內繼續回傳舊內容。
• Bucket 設定的 metadata 讀取可能已更新，但實際 configuration propagation 仍需時間。

所以「Cloud Storage 是 strong consistency」不代表所有權限、cache 與 control-plane change 都瞬間完成。

九、Cloud Storage FUSE 不是 Filestore

Cloud Storage FUSE 讓 Linux workload 以掛載目錄的方式存取 bucket，很適合不方便改用 object API 的 ML、analytics 或 data pipeline。HNS 能改善 folder operation 與部分 workload 的吞吐。

但它仍不是完整 POSIX file system：應用若依賴 file locking、in-place update、低延遲 metadata operation 或傳統 shared filesystem semantics，應評估 Filestore、Persistent Disk 或其他 block/file storage。

選擇時可以這樣問：

• 程式可以用 object API 嗎？可以就優先直接用 Cloud Storage。
• 只是需要 pathname 介面嗎？評估 FUSE。
• 真的依賴 POSIX locking 和 shared directory 嗎？評估 Filestore。
• VM 只需單機 block device 嗎？評估 Persistent Disk 或 Hyperdisk。

十、成本檢查不要漏掉保護副本

Cloud Storage bill 可能來自：

• Live、noncurrent 與 soft-deleted object 的 storage
• Class A / Class B 等 operation
• Nearline、Coldline、Archive retrieval
• Minimum duration 的 early deletion
• Internet、cross-region 或特定服務間 data transfer
• Dual-region replication 與 Turbo Replication
• Autoclass、Storage Intelligence 等管理功能

Free Tier 只涵蓋指定美國 Region 的部分 Standard storage、operation 與 data transfer，而且條件會調整。若 bucket 放在 asia-east1，不要把美國區的免費額度套進估算。

延伸閱讀：Google Cloud Free Tier 與帳單管理

實際控成本可以做：

1. 用 Billing report 或 export 按 SKU 看費用，不只看 service total。
2. 監控 live bytes、noncurrent bytes 與 soft-deleted bytes。
3. 定期檢查 Lifecycle、Autoclass 與 retention 是否仍符合需求。
4. 讓 compute 和 data colocate，檢查跨區與對外流量。
5. 在變更 storage class 前，用實際 access log 或 inventory 估算 retrieval。

十一、四個情境題

情境一：網站公開圖片

圖片頻繁讀取，先用 Standard。若全球使用者很多，評估 External Application Load Balancer 與 Cloud CDN。不要因為是公開內容就把整個 bucket 授權給 allUsers；可用 private origin、獨立公開 bucket 或受控的公開路徑設計縮小範圍。

情境二：七年財務封存

若資料寫入後幾乎不讀，Archive 可能合適，但還要確認法規要求的是「保存七年」還是「七年不可刪」。前者可用 Lifecycle 管理，後者要評估 Retention Policy 與 Lock。最後仍需設計搜尋、legal hold、稽核權限與復原演練。

情境三：使用者上傳後產生縮圖

前端用短效 Signed URL 直接上傳，Eventarc 觸發處理器。處理器用 object generation 或 event ID 去重，避免重送時重複工作。原圖和縮圖可以有不同 bucket、IAM 與 Lifecycle。

情境四：Spark 每天重新命名大型輸出目錄

Flat Namespace 的大量 rename 可能變成許多 object operation。若 folder rename、directory throughput 是明確瓶頸，建立新 bucket 時評估 HNS；同時確認 Object Versioning、Bucket Lock 等不相容功能不是需求。

ACE 與實務都值得記住的判斷

• 選 storage class 時，同時看 access、retention、retrieval 和 early deletion。
• 選 location 時，同時看 compute、latency、data residency、DR 和 transfer cost。
• UBLA 用 IAM 簡化權限；Public Access Prevention 防止 anonymous principal。
• Signed URL 是 bearer credential，拿到連結的人在期限內就能使用。
• Soft Delete、Versioning、Retention、replication 各自解決不同失敗模式。
• Lifecycle 是非同步 policy，不是準點執行的 scheduler。
• 更新或刪除 object 時，用 generation precondition 防止 race condition。
• HNS 有真正 folder，但也有無法事後切換與功能不相容的代價。

結論

Cloud Storage 的正確設計順序是：先選 namespace 和 location，再決定 storage class、access boundary、data protection 和 lifecycle，最後才是上傳指令。

如果只記得 Standard、Nearline、Coldline、Archive 四個名字，很容易漏掉真正昂貴的 retrieval、early deletion、版本、soft-deleted bytes 與 data transfer。把每一層對應的 failure mode 和 billable resource 說清楚，才算真的掌握物件儲存。

官方資料

• Cloud Storage overview
• Storage classes 與 minimum duration
• Bucket locations
• Hierarchical Namespace
• Object Lifecycle Management
• Soft Delete
• Data protection options
• Uniform Bucket-Level Access
• Public Access Prevention
• Signed URLs
• Request preconditions
• gcloud storage transition guide

Cloud Storage 功能、限制與價格會更新。本文最後查核日期為 2026-07-14；建立 production bucket 前請再確認目標 location、產品相容性與 pricing。

系列文章

• 上一篇：GCP-106：Cloud Monitoring & Logging
• 延伸：GCP 資料儲存策略
• 延伸：GCP 成本優化指南