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

# Insights 事件的成本
<a name="insights-events-costs"></a>

**注意**  
資料事件的 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 錯誤率。

您可以分別尋找 和 `InsightsEvents``DataInsightsEvents`用量類型，以識別 帳單上 Insights 的管理和資料事件費用。如需詳細資訊，請參閱[使用 檢視您的 CloudTrail 成本和用量 AWS Cost Explorer](cloudtrail-costs.md)。

您將針對線索和事件資料存放區產生個別的 Insights 費用，以及針對線索產生個別的資料事件 Insights。如需定價的詳細資訊，請參閱[AWS CloudTrail 定價](https://aws.amazon.com/cloudtrail/pricing/)。

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

在此第一個範例中，您會在線索記錄管理事件上啟用 Insights，並選擇收集這兩種 Insights 類型。此範例中的線索同時記錄 `read``write`和管理事件。
+ 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。兩個線索都記錄`read``write`和管理事件。
+ 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 錯誤率。追蹤和事件資料存放區都是記錄`read``write`和管理事件。當您在兩者上啟用 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。此範例中的線索是記錄`read``write`和管理與資料事件。
+ 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 個管理和資料事件會產生成本。