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