本文属于机器翻译版本。若本译文内容与英语原文存在差异,则一律以英文原文为准。
Insights 事件的成本
注意
只有跟踪支持数据事件的 Insights 事件。
当您在现有跟踪或事件数据存储上启用 Insights 事件时, CloudTrail会分析过去 28 天的管理和跟踪或事件数据存储收集的数据事件,以建立正常活动的基准。创建初始基准后,每天都会根据过去 28 天的数据重新计算基准。基线分析不 CloudTrail 收取任何费用。
基线分析完成后,您将为所分析的任何 future 管理和数据事件 CloudTrail 付费。 CloudTrail您需要根据针对启用的 Insights 类型分析的管理和数据事件的数量收取费用。
如果您选择为记录和管理事件的跟踪或事件数据存储同时记录管理事件的 API 调用率read和 write API 错误率 Insights 类型,则分析的事件总数将大于记录的管理事件总数。这是因为 CloudTrail 将对只写管理事件进行两次分析,一次用于计算 API 调用率,另一次用于确定 API 错误率。将对只读管理事件进行一次分析,以计算 API 错误率。
同样,如果您选择为记录和数据事件的跟踪同时记录数据事件的 API 调用率read和 write API 错误率 Insights 类型,则分析的事件总数将大于记录的数据事件总数。这是因为 CloudTrail 将对所有数据事件进行两次分析,一次用于计算 API 调用率,另一次用于确定 API 错误率。
您可以通过分别查找和DataInsightsEvents使用类型来确定账单上管理事件和数据事件的 Insights 费用。InsightsEvents有关更多信息,请参阅 通过查看您的 CloudTrail 成本和使用情况 Amazon Cost Explorer。
您将为跟踪和事件数据存储分别收取 Insights 费用,为跟踪分别收取数据事件 Insights 费用。有关定价的更多信息,请参阅Amazon CloudTrail 定价
示例 1-启用跟踪上的 API 调用率和 API 错误率的管理事件见解
在第一个示例中,您启用 Insights on trail 记录管理事件,然后选择收集这两种 Insights 类型。此示例中的跟踪同时记录了 read 和 write 管理事件。
-
CloudTrail 分析过去 28 天内记录的管理事件以形成基准。分析不 CloudTrail 收取任何费用。
-
创建基准后,跟踪记录了 300,000 个管理事件,其中 270,000 个是
read管理事件,30,000 个是write管理事件。-
对
write管理事件进行两次分析,一次是 API 调用率,一次是 API 错误率(30,000 * 2=60,000)。 -
针对 API 错误率对
read管理事件进行一次分析(270,000 *1=270,000)。 -
分析的管理事件总数为 330,000(60,000 + 270,000)。分析此跟踪的 330,000 个管理事件将产生费用。如果您为其他跟踪或事件数据存储启用了 Insights,则需要单独付费。
-
示例 2-启用对两个跟踪的管理事件的见解
在下一个示例中,您在两个跟踪上启用 Insights 记录管理事件,即跟踪 A 和跟踪 B。您选择仅在跟踪 A 上启用 API 调用率见解,仅在跟踪 B 上启用 API 错误率见解。这两个跟踪都记录readwrite和管理事件。
-
CloudTrail 分析过去 28 天内记录的
write管理事件以形成基准。分析不 CloudTrail 收取任何费用。 -
创建基准后,跟踪记录了 800,000 个管理事件,其中 710,000 个是
read事件,90,000 个是write事件。对于跟踪 A,将进行以下分析:
-
针对 API 调用率对
write管理事件进行一次分析(90,000 * 1=90,000)。 -
不分析
read管理事件,因为 CloudTrail 仅分析 API 调用率 Insights 的write管理事件。 -
分析的管理事件总数为 90,000。分析跟踪 A 的 90,000 个管理事件将产生费用。
对于跟踪 B,将进行以下分析:
-
针对 API 错误率对
write管理事件进行一次分析(90,000 * 1=90,000)。 -
针对 API 错误率(710,000 *1=710,000)对
read管理事件进行一次分析。 -
分析的管理事件总数为 800,000(90,000 + 710,000)。分析跟踪 B 的 800,000 个管理事件将产生费用。
-
示例 3-针对跟踪和事件数据存储中的 API 调用率和 API 错误率启用管理事件见解
在此示例中,您为记录管理事件的跟踪和事件数据存储启用了 API 调用率和 API 错误率的 Insights。跟踪和事件数据存储都记录 read 和 write 管理事件。当您在跟踪和事件数据存储上都启用了 CloudTrail Insights 时,您将分别为这两者收取见解费用。
-
CloudTrail 分析过去 28 天内记录的管理事件以形成基准。分析不 CloudTrail 收取任何费用。
-
创建基准后,跟踪和事件数据存储记录了 500,000 个管理事件,其中 380,000 个是
read管理事件,120,000 个是write管理事件。对于跟踪,将进行以下分析:
-
对跟踪的
write管理事件进行两次分析,一次是 API 调用率,一次是 API 错误率(120,000 * 2=240,000)。 -
针对跟踪的 API 错误率对
read管理事件进行一次分析(380,000 *1=380,000)。 -
对跟踪分析的管理事件总数为 620,000(240,000 + 380,000)。分析跟踪的 620,000 个管理事件将产生费用。
对于事件数据存储,将进行以下分析:
-
对事件数据存储的
write管理事件进行两次分析,一次是 API 调用率,一次是 API 错误率(120,000 * 2=240,000)。 -
针对事件数据存储的 API 错误率对
read管理事件进行一次分析(380,000 *1=380,000)。 -
对事件数据存储分析的管理事件总数为 620,000(240,000 + 380,000)。分析事件数据存储的 620,000 个管理事件将产生费用。
-
示例 4 — 启用管理事件见解和数据事件见解,了解跟踪上的 API 调用率和 API 错误率
在最后一个示例中,您将启用管理和数据事件洞察。此示例中的跟踪是记录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)。针对 API 错误率对read管理事件进行一次分析(270,000 *1=270,000)。分析的管理事件总数为 330,000(60,000 + 270,000)。 -
对
read和write数据事件进行两次分析,一次针对 API 调用率,另一次针对 API 错误率 (400,000 * 2)。分析的数据事件总数为 800,000 个。 -
分析此跟踪的 1,130,000 个管理和数据事件将产生成本。
-