AWS的成本與用量管控工具

7 min readMar 1, 2024

本文將介紹如何"控制"我們在AWS上的財務風險與認知在AWS達成的目的是偏離的。所以在本文中，治理(Governance)可以幫助我們完成這些事。關於更多的雲端治理介紹，可參閱本部落格"雲端運算的企業治理"與"企業的雲端治理要點"一文。

本文將討論在AWS Organization level與 account level的兩個層級來討論AWS的各項服務與資源的成本與用量管控。討論的重點如下:

運用SCPs進行治理
標籤政策的執行
運用服務目錄(Service Catalog)進行治理
運用CloudTrial進行稽核

PS:本文將假設讀者對於資訊安全有其基本概念並對AWS IAM也有基本的認識與操作。

運用SCP(Service Control Policies)進行治理

使用這項工具的前提是我們在"AWS Organizations"已經設定了正確的帳號結構。這是對AWS Organization中的各個OU與其Sub OU進行政策性的控制，例如我們需要針對某些OU來限制存取某些的AWS服務或區域。又或者可以針對測試與開發環境限制使用某些小型的EC2 instance。例如以下我們在SCP中下達的Policy(JSON格式)，把這個Policy套用在某個account或OU時，他們就只使用t2與t3的micro/small的instance。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "RequireMicroInstanceType",
      "Effect": "Deny",
      "Action": "ec2:RunInstances",
      "Resource": [
        "arn:aws:ec2:*:*:instance/*"
      ],
      "Condition": {
        "StringNotEquals": {
          "ec2:InstanceType": ["t2.micro", "t2.small", "t3.micro", "t3.small"]
        }
      }
    }
  ]
}

如果我們也有設定了IAM policy，哪麼 SCP與 IAM 的Net allowed permission就會是”Union”的(如下圖所示)。另外在AWS中， explicit deny是高於 explicit allow。例如，有一個Policy允許某個帳號可以建立EC2 instance，但另一個policy卻禁止，哪麼最後還是會禁止該帳號建立EC2。

另外AWS Control Tower也會使用SCP來幫我們達成某種的管控，例如實行資料停留護欄(data residency guardrails)。Control Tower透過API的方式來呼叫SCP來限制某些資源在某些Regions的使用，以便幫我們達成某些國家與區域的資料保護監管。

標籤政策的執行

如果我們已經有tag strategy後，我們可以透過將tag policy套用於整個組織的 SCP 來提高資源和成本的可見度等級。我們可以編寫為 SCP policy(JSON格式)並將其套用到 OU。也可以在 AWS management console的 AWS Organizations 內建立和套用tag policy。

Tag policy與Server control policy相關，因為它們可以幫助我們標準化整個 OU 中的運作，但tag policy專門控制對tag的how and what。我們需要透過 AWS Organizations 在 OU 或account level attach tag policy。如果在Org Root中套用，則該組織內的所有帳號都將受到該policy的約束。

若要透過遵守有效tag policy來衡量團隊的標籤狀況，可使用AWS resource group的tag compliance report。不過任何在這個合規報表中的資料不會即時的，因為AWS需要時間來對所有資產進行掃描，通常需要48小時以上。

使用AWS Config來進行tag治理

之前我們提到AWS resource group的tag compliance report的資料不會是及時的(因為是報表嘛)。如果我們要使用tag policy來及時查看不合規的狀況，就要使用AWS Config。

例如以下的範例，我們建立一個 required-tags的policy來掃描那些雲端資源是不合於這一個政策的。在本例中，Policy是將owner tag key套用到帳號內的所有 EC2 instance。下圖呈現了required-tags-managed規則的Application，用於檢查具有所需標owner key的 EC2 instance：

另外我們可以結合 EventBridge與SNS來傳送不合規的結果給予相關的人員。EventBridge是一種serverless的全託管服務，可以與多個AWS服務直接整合，例如Lambda、SNS或其他的SaaS服務。以下是延續上述的例子進行作業流程的延伸。

AWS Config 的discovery功能可以自動觸發工作流程並自動套用標籤以此檢查不合規資源，然後通知團隊該資源沒有標籤並套用預設值。

運用服務目錄(Service Catalog)進行治理

之前我們提到的大都是黑名單式管理，也就是那些服務不能使用其他的都可以用。另一種方式就是白名單式管理，也就是你只能使用這些服務，服務目錄就是屬於此種方式。這名字顧名思義就是我們建立了一個以上的AWS服務使用清單，規定那角色或帳號只能使用清單裡的服務。

服務目錄協助我們對AWS進行治理和成本管控。可以透過建立服務組合來標準化使用者使用 AWS 資源的方式。在下圖的範例中，我們建立了一個名為 FinOps Portfolio 的服務組合，其中包含兩個服務：一個 S3 bucket和一個 EC2 Linux instance。然後，我們可以透過管理群組、角色和使用者的權限來指派誰可以啟用這些服務，以存取該服務組合：

使用服務目錄的好處是，使用者不需要特別去設定IAM權限。只要透過服務目錄的入口網站就可以啟用規定的服務，這些清單中的服務是被限制在組織的政策與預算之下的。

運用CloudTrial進行稽核

CloudTrail 主要用於稽核、保護和追蹤AWS 帳號的使用者活動和 API 使用情況。當我們預設使用 AWS Control Tower 設定部署多帳號的 AWS 環境時，Control Tower 會自動建立 CloudTrail baseline和日誌記錄帳號，用於聚合所有帳號中的 API 活動。 CloudTrail會收集並保留這些日誌訊息，在需要的時候進行查詢和分析。如果沒有使用 Control Tower，則必須為個別AWS 帳號手動啟用 CloudTrail。

舉例我們可能只想記錄從S3 bucket中刪資料的情況（如果發生這種情況）。配置 CloudTrail 時，可以使用advanced event selectors。下圖呈現在 AWS 控制台中進行此設定的範例。我們使用advanced event selectors在 CloudTrail 上設定更精細的配置並降低成本(因為不用每個event都記錄)：

上面所介紹的所有AW服務都是我們對AWS進行管理時會用到的日常維運工具，特別是合規與稽核。