Cloud Storage 入門：位置、儲存類別、權限與資料保護

Cloud Storage 乍看只是「放檔案的地方」，實際用到正式環境，才會發現位置、權限、保留期限、誤刪復原和網路費用都得一起考慮。

常見的問題不是不會上傳檔案，而是選錯設定。例如為了省儲存費，把會頻繁覆寫的資料放進 Archive；以為開了 Soft Delete 就等於有完整的版本紀錄；或以為 bucket 是 private，卻沒發現上層還留著一條給 allUsers 的 IAM binding。

這篇會從建立 bucket 前的選擇談起。讀完後，你應該能說明資料該放在哪裡、用哪個儲存類別、誰可以存取，以及刪錯時怎麼救回來。這套判斷方式可以直接用在 side project、正式環境 review 和 ACE 題目。

一、先弄懂 Bucket、Object 和 Folder

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；Console 和工具只是把 / 當成分隔符號，畫出類似資料夾的畫面，底層其實沒有一個叫 images 的目錄。

這個差別在重新命名時特別明顯。在 Flat Namespace 裡「移動一個大資料夾」，通常得處理裡面的每個物件，再刪除舊物件，並不是一次完成的 atomic directory operation。

Hierarchical Namespace：真的有 Folder resource

如果工作負載真的需要目錄語意，可以在建立 bucket 時啟用 Hierarchical Namespace（HNS）。它提供真正的 folder resource、atomic folder rename，也能提高初始 QPS，常見於 Hadoop、Spark、AI/ML 這類會大量操作目錄的工作負載。

不過，HNS 仍不是完整的 POSIX file system，而且建立後不能再改回 Flat Namespace。啟用前先確認幾項限制：

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

一般網站圖片或備份通常用不到 HNS。若應用只是依 prefix 列出物件，Flat Namespace 會比較單純，相容的功能也更多。

flowchart TB
  subgraph REQUIREMENT["先確認真正需要的目錄能力"]
    direction LR
    START["描述工作負載的<br/>檔案操作模式"] --> DIRECTORY{"是否需要 atomic folder rename、<br/>真正 Folder resource 或高目錄吞吐？"}
  end
  DIRECTORY -->|"否，只用 prefix 列出物件"| FLAT["選 Flat Namespace<br/>結構單純、功能相容性較廣"]
  DIRECTORY -->|"是"| CONFLICT{"是否同時需要 Object Versioning、<br/>Bucket Lock 或 object ACL 等不相容能力？"}
  subgraph DECISION["處理相容性取捨"]
    direction LR
    CONFLICT -->|"是"| REDESIGN["拆分 bucket 或重新設計需求<br/>不要直接啟用 HNS"]
    CONFLICT -->|"否"| HNS["建立新 HNS bucket<br/>同時啟用 UBLA"]
  end
  FLAT --> VERIFY["用代表性檔案量測 rename、list、<br/>權限與工具相容性"]
  REDESIGN --> VERIFY
  HNS --> VERIFY

二、Bucket location：先看誰會讀寫這些資料

Location 會影響延遲、可用性、資料落地、複寫和費用。不要只因為 multi-region 聽起來比較安全就直接選它。

表格超出欄寬時，可左右捲動；鍵盤可聚焦表格後用左右方向鍵查看。

最實用的起點，是讓資料靠近讀寫它的運算服務。Cloud Run、GKE、Compute Engine 或 BigQuery 若經常存取這個 bucket，把兩邊放在相容的位置，通常可以降低延遲，也能少付不必要的 data transfer 費用。

如果選 dual-region，還要分清楚預設複寫和 Turbo Replication。兩者的 RPO 和費用不同，不能只看到「dual」就假設資料會在固定時間內出現在另一個 Region。

flowchart TB
  subgraph CONTEXT["確認特殊工作負載"]
    direction TB
    START["盤點讀寫服務、<br/>使用者位置、<br/>資料落地限制與 RPO"] --> RAPID{"是否需要與單一 Zone colocate 的<br/>Rapid 高 I/O 工作負載？"}
  end
  RAPID -->|"是"| ZONE["Zone<br/>建立 Rapid<br/>Bucket 並接受<br/>zonal failure<br/>domain"]
  RAPID -->|"否"| RESIDENCY{"資料是否必須固定<br/>在特定 Region，<br/>且主要 compute<br/>也在當地？"}
  subgraph GENERAL["一般 Bucket Location"]
    direction TB
    RESIDENCY -->|"是"| REGION["Region<br/>降低延遲<br/>與跨區<br/>transfer"]
    RESIDENCY -->|"否"| DR{"是否要指定兩個<br/>Region<br/>承擔區域級災難？"}
    DR -->|"是"| DUAL["Dual-region<br/>依 RPO<br/>選複寫模式"]
    DR -->|"否，服務跨<br/>廣大地理範圍"| MULTI["Multi-region<br/>再檢查<br/>colocate<br/>與費用"]
  end
  ZONE --> VALIDATE["以延遲、RPO、<br/>資料落地、operation<br/>與 transfer 成本驗證"]
  REGION --> VALIDATE
  DUAL --> VALIDATE
  MULTI --> VALIDATE

三、Storage Class：便宜的單價不一定省錢

一般工作負載最常用前四種 storage class；Rapid 則是為特定高效能工作負載設計的另一類選擇：

表格超出欄寬時，可左右捲動；鍵盤可聚焦表格後用左右方向鍵查看。

Nearline、Coldline 和 Archive 仍然是線上儲存，讀取時不用等待離線媒體掛載。它們的差別主要在儲存單價、operation、retrieval、availability 和 early deletion 的計費方式。

最短儲存天數是計費條件，不是鎖定期

Archive 物件可以在第 30 天刪除、覆寫，或透過 Lifecycle 轉到別的 class，但帳單仍可能補收剩餘最短儲存天數的 early deletion charge。

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

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

因此，不能只比較每 GB 的儲存單價，應該看整體成本：

總成本 = 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，目的是讓高 I/O 工作負載能和 compute 放在一起。它支援 appendable object，但同時要求 HNS 和 UBLA，使用的 API 與工具也有額外限制。

若沒有量測證據顯示 object storage latency 已經拖慢 GPU、training checkpoint 或 analytics pipeline，一般應用先從 regional Standard 開始即可。

flowchart TB
  START["用 access log 或預估值盤點<br/>物件壽命、讀取量與刪除時間"] --> PREDICTABLE{"存取模式與生命週期<br/>是否可預測？"}
  PREDICTABLE -->|"否"| AUTO["評估 Autoclass<br/>同時計入管理費與功能限制"]
  PREDICTABLE -->|"是"| LIFETIME{"物件通常會保留多久，<br/>多久需要取回一次？"}
  subgraph CLASSES["手動類別候選"]
    direction LR
    LIFETIME -->|"短期、頻繁讀寫或不確定何時刪除"| STANDARD["Standard<br/>無 minimum duration／retrieval fee"]
    LIFETIME -->|"至少 30 天，約每月取回"| NEARLINE["Nearline"]
    LIFETIME -->|"至少 90 天，約每季取回"| COLDLINE["Coldline"]
    LIFETIME -->|"至少 365 天，極少取回"| ARCHIVE["Archive"]
  end
  AUTO --> TCO["試算 storage、operation、retrieval、<br/>early deletion 與 data transfer"]
  STANDARD --> TCO
  NEARLINE --> TCO
  COLDLINE --> TCO
  ARCHIVE --> TCO
  TCO --> VERIFY["用實際資料量與刪除／覆寫行為驗證<br/>再設定 Lifecycle 或 Autoclass"]

四、建立 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 的 gcloud storage 指令。既有 gsutil 腳本則不要直接逐字替換，因為 wildcard、輸出格式、parallel invocation 和部分指令行為並不完全相同；先拿測試 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 結束，而不是悄悄把它蓋掉。凡是會重試、先讀後寫或替換後刪除的流程，都應考慮用 precondition 避免 race condition。

五、存取控制：先把 IAM 邊界收乾淨

Uniform Bucket-Level Access

啟用 Uniform Bucket-Level Access（UBLA）後，bucket 和 object 都改由 IAM 控制，object ACL 不再生效。對新系統來說，這通常比混用 IAM 和 ACL 容易管理；而且 HNS、managed folder、bucket-level IAM Conditions 和 federation principal 也都要求開啟 UBLA。

既有 bucket 在切換前，要先檢查目前誰還依賴 object ACL，否則舊應用可能會突然失去權限。UBLA 連續啟用 90 天後就不能停用，因此正式環境應先完成權限盤點和測試，不要把它當成隨時能切回去的開關。

常見角色：

表格超出欄寬時，可左右捲動；鍵盤可聚焦表格後用左右方向鍵查看。

授權給 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。它是一個能在指定 object 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。這種連結是 bearer credential：誰拿到它，誰就能在有效期內送出指定請求。因此：

• 有效期只設實際需要的長度。
• 不要把 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。

flowchart TB
  START["先確認誰要存取、哪一批物件、<br/>允許哪些動作與多久"] --> ACTOR{"存取者是哪一類？"}
  ACTOR -->|"內部人員、服務帳號或 workload"| IAM["UBLA + IAM<br/>在最低可行層級授予最小角色"]
  ACTOR -->|"內部團隊只管理特定 prefix"| MANAGED["Managed Folder + IAM<br/>若例外太多則拆分 bucket"]
  ACTOR -->|"外部使用者短時間讀取或上傳單一物件"| SIGNED["短效 Signed URL<br/>限制 method、path、content type"]
  ACTOR -->|"匿名網站內容"| PUBLIC{"是否真的需要讓原始物件<br/>直接公開？"}
  PUBLIC -->|"否"| ORIGIN["保留 private origin<br/>透過受控服務或 CDN 提供"]
  PUBLIC -->|"是"| ISOLATE["使用獨立公開 bucket／路徑<br/>縮小 allUsers 範圍"]
  IAM --> GUARD["檢查 inherited binding、ACL migration、<br/>Public Access Prevention 與 Audit Logs"]
  MANAGED --> GUARD
  SIGNED --> GUARD
  ORIGIN --> GUARD
  ISOLATE --> GUARD

六、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 縮小範圍，確認結果後再套到正式環境。Lifecycle 一旦寫錯，受影響的可能是整個 bucket，而不只是一兩個物件。

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

Soft Delete：救回最近刪除或覆寫的資料

Cloud Storage 會為支援這項功能的新 bucket 預設啟用 7 天 Soft Delete，除非組織政策或建立者指定其他設定。保留期可設為 7 到 90 天，也可以設為 0 來停用。Rapid Bucket 等部分產品並不支援 Soft Delete。

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

修改 Soft Delete policy 只會套用到之後刪除的資料；已經進入 soft-deleted 狀態的物件，仍沿用刪除當下的保留期。因此縮短 policy 不會立刻清掉既有的 soft-deleted object。

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 只是讓那份內容也不能提早刪。合規保存、操作復原與異地備份仍要分開設計。

快速選擇

表格超出欄寬時，可左右捲動；鍵盤可聚焦表格後用左右方向鍵查看。

flowchart TB
  START["描述要防範的失敗<br/>與可接受的復原時間"] --> FAILURE{"最主要的失敗模式是？"}
  FAILURE -->|"最近誤刪或覆寫"| SOFT["Soft Delete<br/>設定 7–90 天復原窗口"]
  FAILURE -->|"需要多個同名物件歷史版本"| VERSION["Object Versioning<br/>搭配 Lifecycle 清理 noncurrent version"]
  FAILURE -->|"法規要求期限內不可刪改"| RETENTION["Retention Policy<br/>確認後才評估不可逆的 Bucket Lock"]
  FAILURE -->|"整個 Region 無法使用"| DR["Dual-region／replication<br/>或獨立備份與切換計畫"]
  FAILURE -->|"內容公開曝光"| ACCESS["Public Access Prevention 與 IAM<br/>不是 retention 設定"]
  SOFT --> STACK{"是否還有其他獨立失敗模式？"}
  VERSION --> STACK
  RETENTION --> STACK
  DR --> STACK
  ACCESS --> STACK
  STACK -->|"有"| COST["分層組合，但計入 live、noncurrent、<br/>soft-deleted 與複寫副本成本"]
  STACK -->|"沒有"| TEST["執行刪除、覆寫、還原與 DR 演練"]
  COST --> TEST

八、一致性很強，但權限和快取仍需要時間

Cloud Storage 對 bucket listing、object listing、object read-after-write、metadata update 和 delete 提供 strong global consistency。上傳成功後，新 object 應該可以立刻讀到，也會立刻出現在列表中。

有幾個例外要分清楚：

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

所以「Cloud Storage 是 strong consistency」指的是資料操作，不代表權限、cache 和所有 control-plane 變更也會瞬間完成。

九、需要掛載路徑時，先別把 FUSE 當成 Filestore

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

但它仍不是完整的 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。

flowchart TB
  START["列出應用程式依賴的<br/>讀寫與一致性語意"] --> OBJECT{"程式能直接使用<br/>Object API 嗎？"}
  OBJECT -->|"能"| API["直接使用 Cloud Storage API<br/>最符合物件儲存語意"]
  OBJECT -->|"不能，只缺 pathname 介面"| PATH{"是否需要 POSIX locking、<br/>in-place update 或 shared directory？"}
  PATH -->|"不需要"| FUSE["Cloud Storage FUSE<br/>仍按物件語意設計與測試"]
  PATH -->|"需要多台主機共享檔案系統"| FILESTORE["Filestore<br/>使用 NFS／檔案系統語意"]
  PATH -->|"只需單一 VM 的 block device"| BLOCK["Persistent Disk／Hyperdisk<br/>由 VM 上的檔案系統管理"]
  API --> BENCH["用真實 workload 測試 latency、<br/>metadata operation、failure 與成本"]
  FUSE --> BENCH
  FILESTORE --> BENCH
  BLOCK --> BENCH

十、看帳單時，別漏掉歷史版本和防刪副本

Cloud Storage 的費用不只來自目前看得到的檔案，還可能包括：

• 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 等不相容功能。

十二、做決定時，照這個順序檢查

1. 先看操作方式：只用 object 和 prefix，還是真的需要 atomic folder rename？這會決定是否要 HNS。
2. 再看資料在哪裡使用：把 location、compute、data residency 和 DR 放在一起選。
3. 估算整體成本：除了儲存單價，也要算 retrieval、early deletion、operation 和 data transfer。
4. 收好權限邊界：內部身分用 IAM，短期外部存取用 Signed URL；不該公開的 bucket 開啟 Public Access Prevention。
5. 分清楚要防哪種事故：Soft Delete、Versioning、Retention 和 replication 解決的問題不同。
6. 最後才寫自動化規則：Lifecycle 不是準點排程；更新或刪除物件時，也要用 generation precondition 避免 race condition。

結語

設計 Cloud Storage 時，可以先回答幾個問題：應用怎麼操作檔案、資料由哪裡讀寫、多久會再用到、誰能存取，以及刪錯後要保留多久。這些答案會依序帶出 namespace、location、storage class、權限和資料保護設定。

Standard、Nearline、Coldline、Archive 只是其中一部分。真正會影響架構和帳單的，往往是 retrieval、early deletion、歷史版本、soft-deleted bytes 和 data transfer。建立 bucket 前把這些條件寫下來，通常比事後搬資料或補救權限省事得多。

官方資料

• Cloud Storage overview
• Storage classes 與 minimum duration
• Bucket locations
• Hierarchical Namespace
• Rapid Bucket
• 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 的功能、限制和價格可能更新。建立正式環境的 bucket 前，請再確認目標 location、產品相容性和 pricing。

系列文章

• 上一篇：GCP 監控與日誌入門
• 下一篇：Cloud SQL 入門
• 延伸：GCP 資料儲存策略
• 延伸：GCP 成本優化指南