資源階層 (Resource Hierarchy)：雲端的套娃系統

在 GCP 中，資源管理是層層繼承的。這不僅是為了分類，更是為了權限控管 (IAM Policy) 和 組織政策 (Organization Policy)。

• Organization (組織)：代表整個企業（例如：你的銀行）。它是階層的最頂端。
• Folders (資料夾)：這是組織下的分組機制。你可以按部門（消金、企金）或按環境（開發、測試、生產）來切分。
• Projects (專案)：資源的最小行政單位。任何資源（VM, Cloud Run, Storage）都必須屬於一個專案。
• Resources (資源)：最底層的服務實體。資源只能存在於一個專案中。

銀行實務點： 雲端部門通常會在 Folder 層級設定「禁止將資源公開到網際網路」的政策，這樣底下的所有 Project 都會自動遵守，避免開發人員誤開外網。

resources 文件: https://docs.cloud.google.com/resource-manager/docs/cloud-platform-resource-hierarchy

google workspace, cloud identity account都是身份提供者的角色
差別在於企業是否使用google workspace套件, 個人使用gcp, 通常就是cloud identity account

這裡提到orgnization, folder的資源 與project可以設定gcp資源,服務如cloud run, engine不同, 這裡的資源是指權限和規則, 用以制定什麼角色能做什麼以及什麼是不能發生

ex. 資安組員可以檢視foler, 在org下面禁止建立公用ip的ＶＭ

而規則會依照 org - folder - project的順序被繼承

如果 aaa@ex-mail.com 被賦予 A-folder的engine管理權限, 他也會被賦予 A-folder下project的engine管理權限 而bbb@ex-mail.com只被指派 B-project的engine管理權限, 他的權限就只被限定於個project

本日實作步驟

點選左上角的專案 會出現popup, 點擊「管理資源」可以看到資源階層

點入管理資源後 可以看到organizatioin - no organization(因為是個人帳戶 也可以自己命名)

在我的階層中 因為沒有特別設定folder, 變成直接是 organization → projects的結構

實務上organizatioin一定是唯一的最頂層
folder可以看需求為多層地巢狀結構

project一定是資源管理的末端 所有資源一定是與project綁定而不會是folder

gcp左側點擊billing 來建立或管理billing account

建立帳號, 然後填一些個人資料 還有扣款用信用卡

建立帳號後 設定budget&alert

我是設定每月10美元 花到50%, 90% 100%預算時會寄mail, 目前都是預設的設定

在action中 預設是觸發email通知, 最下面有個pub/sub是可以來串接自動化

可以串接自動化腳本在alert發生時採取行動(如關閉api, 減少VM, …避免預算進一步消耗)

alert觸發時會把當前的alert資訊以JSON格式送給pub/sub的主題(這裡不做研究)

接著在report中就可以看到預計產生的費用 不過目前還沒有任何服務 沒有收費

這裡貼一張開發一陣子的費用, 就會看到不同服務產生的費用