Insights 事件的成本 - AWS CloudTrail

本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

Insights 事件的成本

注意

資料事件的 Insights 事件僅支援追蹤。

當您在現有的線索或事件資料存放區上啟用 Insights 事件時，CloudTrail 會分析過去 28 天的管理和由線索或事件資料存放區收集的資料事件，以建立正常活動的基準。建立初始基準之後，基準會在資料過去 28 天內每天重新計算。基準分析不收取 CloudTrail 費用。

在基準分析之後，您會針對 CloudTrail 分析的任何未來管理和資料事件產生 CloudTrail 費用。根據針對已啟用的 Insights 類型分析的管理和資料事件數量，會產生費用。

如果您選擇為記錄和管理事件的線索或事件資料存放區記錄 API 呼叫率read和 API 錯誤率 Insights 類型，則分析的事件write總數將大於記錄的管理事件總數。這是因為 CloudTrail 會分析唯寫管理事件兩次，一次用於計算 API 呼叫率，另一次用於判斷 API 錯誤率。唯讀管理事件將分析一次，以計算 API 錯誤率。

同樣地，如果您選擇為記錄和資料事件的線索記錄 API 呼叫率read和 API 錯誤率 Insights 類型write，則分析的事件總數將大於記錄的資料事件總數。這是因為 CloudTrail 會分析所有資料事件兩次，一次用於計算 API 呼叫率，另一次用於判斷 API 錯誤率。

您可以分別尋找 和 InsightsEventsDataInsightsEvents用量類型，以識別 帳單上 Insights 的管理和資料事件費用。如需詳細資訊，請參閱使用 檢視您的 CloudTrail 成本和用量 AWS Cost Explorer。

您將針對線索和事件資料存放區產生個別的 Insights 費用，以及針對線索產生個別的資料事件 Insights。如需定價的詳細資訊，請參閱AWS CloudTrail 定價。

範例 1：針對追蹤的 API 呼叫率和 API 錯誤率啟用管理事件的洞見

在此第一個範例中，您會在線索記錄管理事件上啟用 Insights，並選擇收集這兩種 Insights 類型。此範例中的線索同時記錄 readwrite和管理事件。

  • CloudTrail 會分析過去 28 天內記錄的管理事件，以形成基準。分析無需支付 CloudTrail 費用。

  • 建立基準後，線索會記錄 300，000 個管理事件，其中 270，000 個是read管理事件，30，000 個是write管理事件。

    • write 管理事件會分析兩次，一次用於 API 呼叫率，一次用於 API 錯誤率 (30，000 * 2=60，000)。

    • read 管理事件會針對 API 錯誤率 (270，000 *1=270，000) 分析一次。

    • 分析的總管理事件為 330，000 (60，000 + 270，000)。分析此線索的 330，000 個管理事件會產生成本。如果您為其他線索或事件資料存放區啟用 Insights，則會另外收費。

範例 2 – 啟用兩個線索管理事件的洞見

在此下一個範例中，您會在兩個線索記錄管理事件上啟用 Insights，即線索 A 和線索 B。您可以選擇僅在線索 A 上啟用 API 呼叫率 Insights，並在線索 B 上啟用 API 錯誤率 Insights。兩個線索都記錄readwrite和管理事件。

  • CloudTrail 會分析過去 28 天內記錄的write管理事件，以形成基準。分析無需支付 CloudTrail 費用。

  • 建立基準後，線索會記錄 800，000 個管理事件，其中 710，000 個是read事件，90，000 個是write事件。

    對於線索 A，會發生下列分析：

    • write 管理事件會針對 API 呼叫率 (90，000 * 1=90，000) 分析一次。

    • 不會分析read管理事件，因為 CloudTrail 只會分析 API 呼叫率 Insights 的write管理事件。

    • 分析的總管理事件為 90，000。分析線索 A 的 90，000 個管理事件會產生成本。

    對於線索 B，會發生下列分析：

    • write 管理事件會針對 API 錯誤率 (90，000 * 1=90，000) 分析一次。

    • read 管理事件會針對 API 錯誤率 (710，000 *1=710，000) 分析一次。

    • 分析的總管理事件為 800，000 (90，000 + 710，000)。分析線索 B 的 800，000 個管理事件會產生成本。

範例 3：針對追蹤和事件資料存放區上的 API 呼叫率和 API 錯誤率啟用管理事件的洞見

在此範例中，您會在線索和事件資料存放區記錄管理事件上啟用 Insights for API 呼叫率和 API 錯誤率。追蹤和事件資料存放區都是記錄readwrite和管理事件。當您在兩者上啟用 Insights 時，會針對追蹤和事件資料存放區分別產生 CloudTrail Insights 的費用。

  • CloudTrail 會分析過去 28 天內記錄的管理事件，以形成基準。分析無需支付 CloudTrail 費用。

  • 建立基準後，追蹤和事件資料存放區日誌 500，000 個管理事件，其中 380，000 個是read管理事件，120，000 個是write管理事件。

    對於線索，會發生下列分析：

    • write 管理事件會針對線索分析兩次，一次針對 API 呼叫率，一次針對 API 錯誤率 (120，000 * 2=240，000)。

    • read 管理事件會針對 API 錯誤率 (380，000 *1=380，000) 的線索分析一次。

    • 針對追蹤分析的總管理事件為 620，000 (240，000 + 380，000)。分析線索的 620，000 個管理事件會產生成本。

    對於事件資料存放區，會發生下列分析：

    • write 管理事件會針對事件資料存放區分析兩次，一次針對 API 呼叫率，一次針對 API 錯誤率 (120，000 * 2=240，000)。

    • read 管理事件會針對 API 錯誤率的事件資料存放區分析一次 (380，000 *1=380，000)。

    • 針對事件資料存放區分析的總管理事件為 620，000 (240，000 + 380，000)。分析事件資料存放區的 620，000 個管理事件會產生成本。

範例 4 – 在線索上啟用管理事件 Insights 和資料事件 Insights for API 呼叫率和 API 錯誤率

在此最終範例中，您會在管理和資料事件上啟用 Insights。此範例中的線索是記錄readwrite和管理與資料事件。

  • CloudTrail 會分析過去 28 天內記錄的管理和資料事件，以形成基準。分析無需支付 CloudTrail 費用。

  • 建立基準後，線索會記錄 300，000 個管理事件，其中 270，000 個是讀取管理事件，30，000 個是寫入管理事件。追蹤也會記錄 400，000 個資料事件，其中 340，000 個是讀取資料事件，60，000 個是寫入資料事件。

    • write 管理事件會分析兩次，一次用於 API 呼叫率，一次用於 API 錯誤率 (30，000 * 2=60，000)。read 管理事件會針對 API 錯誤率 (270，000 *1=270，000) 分析一次。分析的總管理事件為 330，000 (60，000 + 270，000)。

    • read 和 write資料事件會分析兩次，一次用於 API 呼叫率，一次用於 API 錯誤率 (400，000 * 2)。分析的資料事件總數為 800，000。

    • 分析此線索的 1，130，000 個管理和資料事件會產生成本。