2026阿里云国际版操作审计ActionTrail实战教程：事件查询、Trail投递SLS/OSS与审计成本测算

Meta Description: 面向出海团队的阿里云国际版操作审计 ActionTrail 实战教程：讲清它记录的是「谁在什么时候对哪个资源做了什么」这类云 API 操作事件、管理事件与数据事件的区别、单账号/多账号/Inner 三种 Trail 怎么选，附控制台查询事件、创建单账号 Trail 投递到 SLS/OSS/MaxCompute 的完整实操、Python SDK 建 Trail 并启用、在 SLS 里做泄露 AccessKey 排查与高危操作追踪的四个真实 SQL 场景、七类 Insights 异常检测事件，以及审计日志的真实计费口径（ActionTrail 本身免费，费用全在下游存储）、成本测算表与七个避坑点。价格可能变动，请以官方为准；注册前请确认当地法规合规性。

关键词：阿里云国际版、ActionTrail、操作审计、云审计日志、等保合规、Trail、管理事件、数据事件、Insights事件、SLS日志服务、OSS归档、AccessKey审计、成本测算、出海架构

一句话答案：阿里云国际版的操作审计 ActionTrail 是一个「开箱即用、记录云 API 操作、产品本身免费」的合规与安全底座——它把你账号里所有通过控制台、OpenAPI、SDK 发生的操作，记录成一条条事件（谁、什么时候、对哪个资源、做了什么、从哪个源 IP、成功还是失败），默认免费保留 90 天，可在线查询；需要长期留存（等保 2.0 要求至少 180 天）时，只需建一条 Trail，把事件投递到日志服务 SLS、对象存储 OSS 或 MaxCompute，费用按下游服务计费。 它不部署任何主机、不接管任何流量，是一条「旁路」的账本。

对做出海业务的团队来说，「审计」这件事往往是在最尴尬的时刻才被想起：一次误删的 ECS 实例、一个泄露的 AccessKey、一笔莫名其妙的账单、一次等保或客户的安全问询。到那时再去回溯「到底是谁干的」，如果没有操作审计，就只能靠猜。ActionTrail 把这件事从「事后靠猜」变成「事前就记」——它是阿里云账号的「飞行记录仪（黑匣子）」，也是很多合规框架（等保 2.0、ISO 27001、SOC 2）里「审计日志留存」那一条的最省事解法。

本文基于阿里云国际版（alibabacloud.com）官方产品页与帮助文档的实测内容写成，面向已经或准备用国际版部署业务的中文开发者、运维与安全负责人。文中涉及的配置路径、代码与价格口径均来自官方文档，价格可能变动，请以官方为准；注册与部署前，请确认当地法规合规性。

一、先划边界：ActionTrail 补的是云治理版图里哪一块

新手最容易把「操作审计」和一堆名字相似的安全产品搞混。先把边界立起来，后面才不会买错、也不会以为「开了某个安全产品就等于有了审计」。

一句话总结这张表：云安全中心负责「资产有没有问题」，堡垒机负责「人在机器上干了什么」，云防火墙负责「流量通不通」，配置审计负责「配置对不对」，而 ActionTrail 负责「云 API 被谁调了、调了什么、什么时候调的」。 这几者是并联关系，不是替代关系——一家认真做合规的出海公司，通常这几个盒子都要有。

需要强调的是，ActionTrail 的定位是旁路审计：它不在你业务请求的主链路上，不会因为它的存在而让业务变慢或变复杂。你要做的就是「开一条 Trail，指定一个存储目的地」，剩下的记录、投递、索引都由阿里云自动完成。

二、先搞懂三种「事件」：管理事件、数据事件与 Insights 事件

ActionTrail 记的东西统称「事件（event）」。理解事件类型，是理解后面「为什么有的要钱、有的不要钱」的前提。

管理事件（management event）——控制面操作。 指你对云资源做管理动作时产生的事件，也就是常说的「控制面」操作：创建、修改、删除资源，例如创建一台 ECS 实例、删除一条安全组规则、创建一个 OSS Bucket。它还包括控制台相关的事件，例如登录阿里云管理控制台（ConsoleSignin）。这类事件对每个账号默认免费保留 90 天，可以在控制台在线查询和下载，无需任何配置——这就是「开箱即用」的含义。

数据事件（data event）——数据面操作。 指对云资源里数据的读写动作，也就是「数据面」操作：从 OSS Bucket 读取一个对象、在 Tablestore 里查询数据等。数据事件的体量通常远大于管理事件（一个高流量应用每秒可能产生成百上千条数据访问），所以 ActionTrail 默认不采集、不存储数据事件。要记录它，必须专门建一条 Trail 并显式开启数据事件，把事件投递到 SLS 或 OSS，费用按目的地服务的计费标准收取。

Insights 事件（洞察事件）——异常行为检测。 Insights 是 ActionTrail 内置的一组「行为基线 + 数学/机器学习模型」能力：它分析你账号里的管理事件，识别出偏离历史基线的可疑活动，然后生成 Insights 事件。注意两点：一是它只分析管理事件，不分析数据事件；二是开启后至少需要 24 小时才会产生第一条 Insights 事件（因为要先建立基线）。

📝 小提示：判断该不该记数据事件，只需问一句「我需不需要回答『谁读了我的这份数据』」。如果合规或安全要求你回答这个问题（例如金融、医疗类业务），就开数据事件；否则保持关闭，能省下可观的存储费。

三、三种 Trail 怎么选：单账号、多账号与 Inner-ActionTrail

「Trail（跟踪）」是 ActionTrail 的核心概念：一条 Trail 负责把事件投递到指定的存储目的地。按创建者、适用范围和投递内容，Trail 分三种。选错类型等于白建——尤其是企业用户，个人版和集团版是两个世界。

三个需要划重点的细节：

第一，多账号 Trail 是「集团级审计」的正解。 如果你们用资源目录（Resource Directory）把「生产」「测试」「各地分公司」拆成了多个成员账号，那么用管理账号建一条多账号 Trail，就能把所有成员的操作事件统一投递到一个存储目的地——这正是「不同审计员看不同范围」这种组织需求的落地方式。

第二，Inner-ActionTrail 是一个容易被忽略但很值钱的能力。 它记录的是阿里云自己对你服务做的维护操作（例如平台侧的运维动作），投递后可以对「云平台对我的资源到底做了什么」有完整可见性——这在和云厂商对账、排查非我方操作的变更时非常有用。它只支持投递到 SLS，且需要加白名单。

第三，Trail 只投递「启用之后」产生的新事件。 一条刚建好的 Trail 不会把过去 90 天的历史事件补投过去。如果你确实需要把历史事件也导出去，要另外创建一个数据回填（data backfill）任务。

四、开箱即用：不花一分钱先查事件（10 分钟上手）

ActionTrail 最讨喜的地方是：在你不做任何配置、不花一分钱的情况下，管理事件已经默认记着、默认能查。所以第一步不是建 Trail，而是先学会查。

控制台查询路径：登录阿里云 → 进入 ActionTrail 控制台 → 左侧导航 事件查询（Event Query） / 高级事件查询（Advanced Event Query）。在事件查询页面里，你可以按时间、用户名、资源类型、资源名称、事件名称等多个维度筛选事件。特别地，要查看全局事件（由 RAM 这类全局服务产生），需要在事件查询页面选一个具体地域——自 2022-12-22 00:00:00 起，全局事件只能在新加坡地域查询。

API 查询：除了控制台，事件查询也可以通过 LookupEvents 这个 API 完成，方便你在自己的系统里做二次检索；还有「高级事件查询」可做更复杂的条件组合。

需要给自己一个心理预期：控制台查询历史事件的速率上限是 2（每秒），这是默认配额——它是给「人工排查」用的，不是给「程序批量拉取」用的。要批量、长期地拉事件，就该建 Trail 投递到 SLS。

📝 小提示：事件在控制台可查询前的延迟约 10 分钟（投递到 OSS 也是约 10 分钟）。所以「刚做的操作立刻查不到」是正常的，等几分钟再刷。

五、建一条单账号 Trail：把事件投递到 SLS / OSS / MaxCompute

默认 90 天的留存撑得住「临时排查」，但撑不住合规。要长期留存，就得建 Trail。以下用控制台把一条单账号 Trail 从零建起来。

第 1 步，进入控制台并选地域。 登录 ActionTrail 控制台 → 左侧导航点 Trails → 在顶部导航栏选择你要创建 Trail 的地域。注意：这个地域会成为这条 Trail 的 home region（归属地域）。

第 2 步，点击 Create Trail。 默认打开的是 Quick Create Trail（快速创建） 页面；要配置全部参数，点页面顶部的 Create Trail 标签页。两者的差别很关键：

⚠️ 快速创建会「默认记全量」：Quick Create Trail 会记录所有管理事件（包含读事件和写事件）并投递到 SLS，它不支持数据事件、Insights 事件，也不支持投递到 OSS 或 MaxCompute。要自定义事件类型或投递目的地，请用 Create Trail 标签页——这直接关系到你的账单（读事件体量很大）。

第 3 步，配置基本信息。

第 4 步，选择投递目的地。 可以投递到 SLS、OSS、MaxCompute，也可以同时投递到多个。三种目的地的配置要点如下。

投递到 SLS（用于查询与分析）： 选择「投递到本账号」，然后选 New Log Service Project（在 ActionTrail 控制台顺手新建）或 Existing Log Service Project（选已有的），并指定 Logstore Region 与 Project Name（Project 名全局唯一）。成功后 ActionTrail 会自动创建一个名为 actiontrail_{Trail名} 的 Logstore，并内置面向审计优化的索引与仪表盘——你不需要提前建 Logstore，ActionTrail 还会禁用用户对该 Logstore 的写权限以保证数据准确性。

投递到 OSS（用于长期归档）： 选 New/Existing OSS Bucket，填 Bucket Name 与 Log File Prefix（日志文件前缀，便于定位）。注意：在中国大陆创建 Bucket 需完成实名认证。还要配置：

• Server Encryption（服务端加密）：Fully Managed by OSS（OSS 托管密钥）/ KMS（用密钥管理服务 KMS 的密钥）/ Disable。合规场景建议选 KMS。
• Enable Retention Policy（合规保留策略）：OSS 的 WORM（Write Once, Read Many，一次写入多次读取）能力，开启后数据在指定期限内不可删改，非常适合审计取证的「防篡改」要求。

投递到 MaxCompute（用于大数据分析）： 选择 MaxCompute Region 与 Project Quota（项目配额）。ActionTrail 会把审计日志投递到 actiontrail_{账号ID} 的 MaxCompute 项目中并自动建表，便于用 DataWorks 做 SQL 分析。首次创建时若当前地域没有可用配额，需换一个 MaxCompute 地域。

第 5 步，确认与验证。 建好后，事件会以 JSON 格式落到指定的 SLS Logstore、OSS Bucket 或 MaxCompute 表。在 Trails 页面，把鼠标移到该 Trail 的 Storage Service 列上，即可点进对应目的地查看。

投递路径速查（出问题时按这个找数据）：

📝 小提示：ActionTrail 投递到 OSS 时会先聚合——每 5 分钟窗口内产生的事件通常被合并成一个文件，事件量很大时可能拆成多个文件。所以 OSS 里看到的是「按 5 分钟一片」的文件，而不是「一条事件一行」。

⚠️ 两条不可不知的限制：其一，不要给不同的单账号 Trail 指定同一个投递目的地，否则事件会被重复投递、白白浪费存储。其二，控制台创建的 Trail 默认投递所有地域的事件；如果你只想跟踪特定地域，需要用 CreateTrail API 并设置 TrailRegion 参数。

六、用 Python SDK 建 Trail 并启用（代码实操）

控制台适合一次性操作，但基础设施即代码（IaC）场景下，用 SDK 建 Trail 更可复现。下面用 Python SDK 走一遍：先建 SLS Project，再建 Trail，最后启用它。

前置条件：已开通 日志服务 SLS（开通本身免费，投递后才按存储计费）；已安装 Python 开发环境；已获取 AccessKey 并配置到环境变量（ALIBABA_CLOUD_ACCESS_KEY_ID / ALIBABA_CLOUD_ACCESS_KEY_SECRET）。

先科普一个容易踩的坑：新建的 Trail 默认是 Disabled（禁用）状态，必须显式调用 StartLogging 启用，否则事件不会投递。

安装两个 SDK 依赖（SLS 与 ActionTrail 各一个）：

pip install alibabacloud_sls20201230
pip install alibabacloud_actiontrail20200706

第 1 步，创建 SLS Project。 把 endpoint 换成你要用的地域（下例用国际站常用的新加坡 ap-southeast-1）：

import os
from alibabacloud_sls20201230.client import Client as SlsClient
from alibabacloud_tea_openapi import models as open_api_models
from alibabacloud_sls20201230 import models as sls_models

def create_sls_client():
    config = open_api_models.Config(
        access_key_id=os.environ['ALIBABA_CLOUD_ACCESS_KEY_ID'],
        access_key_secret=os.environ['ALIBABA_CLOUD_ACCESS_KEY_SECRET']
    )
    config.endpoint = 'ap-southeast-1.log.aliyuncs.com'
    return SlsClient(config)

client = create_sls_client()
req = sls_models.CreateProjectRequest(project_name='cloud-trail-project-test')
client.create_project(req)
print('project created')

第 2 步，创建并启用 Trail。 把 sls_project_arn 换成你自己的 ARN（格式为 acs:log:<地域>:<账号ID>:project/<Project名>），endpoint 用 actiontrail.<地域>.aliyuncs.com：

import os
from alibabacloud_actiontrail20200706.client import Client as AtClient
from alibabacloud_tea_openapi import models as open_api_models
from alibabacloud_actiontrail20200706 import models as at_models

def create_at_client():
    config = open_api_models.Config(
        access_key_id=os.environ['ALIBABA_CLOUD_ACCESS_KEY_ID'],
        access_key_secret=os.environ['ALIBABA_CLOUD_ACCESS_KEY_SECRET']
    )
    config.endpoint = 'actiontrail.ap-southeast-1.aliyuncs.com'
    return AtClient(config)

client = create_at_client()
create_req = at_models.CreateTrailRequest(
    name='cloud_trail_test',
    sls_project_arn='acs:log:ap-southeast-1:141339776561****:project/cloud-trail-project-test'
)
client.create_trail(create_req)

start_req = at_models.StartLoggingRequest(name='cloud_trail_test')
client.start_logging(start_req)
print('trail created and enabled')

第 3 步，验证。 回到 ActionTrail 控制台 → Trails，应能看到 cloud_trail_test 且 Status 为 Enabled；到 SLS 控制台，在刚建的 Project 下的 actiontrail_cloud_trail_test Logstore 里，即可查看已投递的事件。在 Raw Logs（原始日志） 标签页可以看到事件的详细字段：acsRegion（地域）、eventName（事件名）、eventSource（事件源）、eventType（事件类型）、serviceName（服务名）、eventRw（读写类型）。

📝 小提示：国际站的 endpoint 后缀与地域一一对应，请以官方文档的 Endpoints 页为准；把 ap-southeast-1 换成你实际使用的地域即可。AccessKey 切勿硬编码进代码，用环境变量或密钥管理服务（KMS）托管。

七、把审计变成战斗力：SLS 里四个真实分析场景（附 SQL）

事件投递到 SLS 之后，它才真正「活」起来。下面四个场景都来自官方最佳实践，直接复制 SQL（把占位符换成你的值）就能用。

场景一：AccessKey 疑似泄露，查它的调用来自哪些城市。 当你发现某个 AccessKey 在异常 IP 上有调用、怀疑它被泄露时，先看它的调用「地理分布」——出现在非业务所在地的城市，就是高危信号。

__topic__: actiontrail_audit_event and event.userIdentity.accessKeyId:<YourAccessKeyId>
| SELECT count(1) as pv, city FROM (
    SELECT "event.sourceIpAddress" AS ip, ip_to_city("event.sourceIpAddress") as city FROM log
  ) WHERE ip_to_domain(ip)!='intranet' GROUP BY city ORDER BY pv DESC

场景二：追查一台 ECS 是谁删的。 高危操作（如删除 ECS 实例）一旦发生，第一反应是「谁干的」。下面这条按「服务名 + 事件名 + 用户名」聚合，直接列出删除 ECS 实例的用户及次数（把 <TargetServiceName> 换成 ECS、<TargetEventName> 换成 DeleteInstances）：

__topic__: actiontrail_audit_event
| SELECT serviceName, eventName, userName, count(1) as pv FROM (
    SELECT "event.eventName" as eventName,
           "event.serviceName" as serviceName,
           "event.userIdentity.userName" as userName FROM log
  ) WHERE (serviceName = <TargetServiceName> and eventName = <TargetEventName>)
  GROUP BY serviceName, eventName, userName

定位到可疑用户后，再下钻到具体某一次操作（含资源 ID 与 AccessKey）：

__topic__: actiontrail_audit_event and event.serviceName:<TargetServiceName>
  and <TargetResourceId> and event.userIdentity.accessKeyId:<YourAccessKeyId>

场景三：生成资源使用报表。 审计数据不只是「追责」，还能做容量规划。例如统计近半年每月创建的 ECS 实例数、看同比增长率（把 eventName 换成 CreateInstance）：

__topic__: actiontrail_audit_event and event.serviceName:<TargetServiceName>
  and event.eventName:<TargetEventName>
| select t, diff[1] as current, diff[2] as last_month, diff[3] as percentage from (
    select t, compare(pv, 2592000) as diff from (
      select count(1) as pv, date_format(from_unixtime(__time__), '%m') as t from log group by t
    ) group by t order by t
  )

查完后在页面底部切到 Chart（图表） 标签即可可视化。

场景四：给「异常访问」配一条告警。 安全运营的关键是「不靠人盯」。下面这条找出「当日访问量比 60 天均值高出 50% 以上」的服务，可直接挂成告警：

__topic__: actiontrail_audit_event
|select a.serviceName, a.avg_pv, b.today_pv from (
    select serviceName, avg(pv) as avg_pv from (
      select "event.serviceName" as serviceName, count(1) as pv,
             date_format(from_unixtime(__time__), '%m-%d') as day from log group by serviceName, day
    ) group by serviceName
  ) a join (
    select "event.serviceName" as serviceName, count(1) as today_pv from log
    where date_format(from_unixtime(__time__), '%Y-%m-%d')=current_date group by serviceName
  ) b on a.serviceName = b.serviceName

在图表右上角点告警图标，进入 Alert Monitoring Rule（告警监控规则） 面板，把触发条件写成下面这个表达式即可：

$0.today_pv > $0.avg_pv && ($0.today_pv - $0.avg_pv)/$0.avg_pv > 0.5

其中 $0 代表查询返回的原始图表数据，$0.avg_pv 即某服务的 60 天平均访问量。这样，任何服务的 API 访问量异常飙升都会自动触发告警——这正是「操作基线 + 阈值告警」的威力。

八、Insights 事件：七种「异常检测」规则一览

如果你不想自己写 SQL，ActionTrail 内置的 Insights 会自动分析你的管理事件并生成异常事件。它一共识别七类风险活动：

几个必须知道的行为特征：Insights 事件成对出现（一条 start 事件 + 一条 end 事件，标记检测活动的起止）；它按地域分析，事件生成在触发它的管理事件所在的同一地域；首次开启后至少 24 小时才会产生第一条事件（因为要先建模），此后持续分析。目前 Insights 功能为免费试用，未来是否收费以官方公告为准。

哪些地域用不了 Insights？ 国际站里 韩国（首尔）、菲律宾（马尼拉）、阿联酋（迪拜） 不支持 Insights 事件（中国大陆另有若干地域不支持）。如果你打算用 Insights 做安全运营，选地域时先把这一点考虑进去。

📝 小提示：Insights 只分析管理事件，即使你开了数据事件它也不看数据事件。所以「用 Insights 盯数据面异常」这条路走不通——数据面的异常要自己在 SLS 里写规则。

九、计费与成本测算：ActionTrail 免费，钱花在「下游」

这是很多人的第一个误解。ActionTrail 产品本身不收费——它只负责「记录」和「投递」。你真正花钱的地方，是事件落地之后下游服务（SLS / OSS / MaxCompute）按各自计费标准收的存储与流量费。官方文档说得很直白：如果未来某些功能要收费，会提前一个月通知。

先分清「免费」和「付费」的边界：

SLS 的计费公式（用于投递到 SLS 的场景，官方口径）：

• 日写入成本 = 每日原始写入量(GB) × 写入单价
• 日存储成本 = 每日压缩后数据量(GB) × 留存天数 × 每 GB 每日存储单价
• 日总成本 = 日写入成本 + 日存储成本；月估算 = 日总成本 × 30
• 关键：按写入量计费模式下，前 30 天的存储费是免费的

官方给出的单价锚点是：写入约 USD 0.061/GB，存储约 USD 0.002875/GB/天。官方还给了个算例：假设每日原始写入 1.79 TiB（约 1833 GB）、2:1 压缩（约 373.55 GB/天）、留存 7 天，则日写入 ≈ 1833 × 0.061 ≈ USD 111.8，日存储 ≈ 373.55 × 7 × 0.002875 ≈ USD 7.5，月成本 ≈ (111.8 + 7.5) × 30 ≈ USD 3,579。注意 SLS 是 T+1 计费（当天用量次日结算、再从余额扣）。

把上面的公式代进出海团队常见的量级，得到一张成本测算表（假设 2:1 压缩、留存 90 天、按写入量计费模式、单价取官方锚点；仅为量级估算，实际以 SLS 官方与你的账单为准）：

三条可落地的省钱动作：

1. 把留存期压到 30 天以内，存储费归零。 按写入量计费模式下前 30 天存储免费——如果你的合规要求本来就是「保留 30 天」，那么存储费直接是 0，只剩写入费。要长期留存，把热数据放 SLS、冷数据生命周期归档到 OSS。
2. 非必要不投递读事件。 建 Trail 时把管理事件选成 Write event（只投递增删改），事件量能大幅下降；只有在需要完整审计 AccessKey 使用轨迹时才选 All Events。这是「Quick Create 默认记全量」这个默认值最容易被忽略的账单来源。
3. 长期归档走 OSS + 生命周期。 OSS 的成本结构比 SLS 更适合「只存不查」的冷数据，配合生命周期规则沉降到低频/归档存储，能进一步压低单位成本。

⚠️ 最隐蔽的一个计费坑：删除 Trail ≠ 停止计费。 当你创建 Trail 把数据事件投递到 SLS 时，ActionTrail 会在每个目标地域自动创建一个 Logstore 来存放事件；删除 Trail 时这个 Logstore 不会被删除，里面的历史数据事件会继续产生存储费。要真正停止计费，必须手动去 SLS 控制台找到 ActionTrail 自动创建的 Project（名字通常以 actiontrail 开头），再删掉存放数据事件的 Logstore。删除不可逆，操作前请确认数据确实不再需要。

十、配额、限制与七个避坑点

先用一张表把 ActionTrail 的硬性配额看清（默认配额，部分可在 Quota Center 申请提升）：

七个高频避坑点，逐条对照自查：

1. 删除 Trail 后没删 Logstore → 残留存储费持续产生（见上一节）。
2. 图省事用了「快速创建」 → 默认记录全部管理事件（含读）投到 SLS，事件量最大，账单最高。要控费就改用 Create Trail 并选 Write event。
3. 以为建 Trail 能看到历史 → 错。Trail 只投递启用后产生的新事件；要补历史，需另建数据回填（data backfill）任务。
4. 给多条 Trail 配了同一个投递目的地 → 事件被重复投递，白花存储费。官方明确要求不要把同一地域、同一事件类型投到同一目的地多次。
5. 在错误的地域找全局事件 → 自 2022-12-22 起，全局事件只能在新加坡地域查询；OSS 投递时，全局事件与 home region 事件存在同一目录，避免重复。
6. 拿控制台查询当批量拉取用 → 历史事件查询速率默认仅 2 次/秒，批量分析请走 SLS/SQL。
7. 指望 Insights 立刻出结果 → 首次开启后至少 24 小时才有第一条事件；且首尔、马尼拉、迪拜等地域不支持 Insights。

十一、常见问题 FAQ

• Q：ActionTrail 到底收不收费？

A：产品本身免费。 ActionTrail 只负责记录和投递，钱花在下游——你把事件投递到 SLS、OSS 或 MaxCompute 后，按这些服务各自的计费标准收费。管理事件的默认记录与 90 天在线查询不收费。

• Q：默认能查多久的事件？想查更早怎么办？

A：默认每个账号保留最近 90 天的管理事件，可直接在线查询和下载。如果不建 Trail，就查不到 90 天以前的事件。 要长期留存，建 Trail 投递到 SLS/OSS/MaxCompute。

• Q：为什么数据事件默认不记录？

A：因为数据面操作（读 OSS 对象、查 Tablestore 等）体量远大于管理事件，默认全记会带来可观的存储成本。默认关闭、需要时再建 Trail 显式开启，是成本与合规的折中。

• Q：建了 Trail，能看到账号过去 90 天的历史事件吗？

A：不能。 Trail 只投递启用之后新产生的事件。要把已有的历史事件导出去，需要另外创建一个数据回填（data backfill）任务。

• Q：事件多久能查到？

A：事件在控制台可查询前约 10 分钟延迟；投递到 OSS 也在约 10 分钟内；投递到 SLS 通常 1 分钟内即可查询分析。

• Q：把 Trail 删掉就停止计费了吗？

A：没有。 删除 Trail 不会删除它自动创建的 SLS Logstore，历史数据仍持续产生存储费。要真正停费，必须手动到 SLS 控制台删掉对应的 Logstore（不可逆，删前确认不再需要）。

• Q：历史事件查询有速率限制吗？

A：有。通过控制台或 LookupEvents 查询历史事件的默认速率仅 2 次/秒，它是给人工排查用的。要批量、长期拉取，请投递到 SLS 用 SQL 分析。

• Q：Insights 事件要收费吗？

A：目前 Insights 功能为免费试用，未来是否收费请以官方公告为准。另外它只分析管理事件，且首次开启后至少 24 小时才会产生第一条事件。

• Q：国际站支持哪些地域，哪些地域不支持 Insights？

A：国际站支持香港、新加坡、首尔、吉隆坡、雅加达、东京、法兰克福、伦敦、硅谷、弗吉尼亚、迪拜、柔佛等地域（孟买、悉尼已关闭）。其中 首尔、马尼拉、迪拜不支持 Insights 事件。

• Q：预算有限，只想用最基本的能力，怎么配最省？

A：三步——① 建 Trail 时管理事件只选 Write event（不投递读事件）；② 合规允许就把留存期压到 30 天以内（按写入量计费模式下前 30 天存储免费）；③ 需要长期留存的部分用生命周期规则归档到 OSS。

• Q：全局事件（如 RAM 相关）在哪里查？

A：需要先在事件查询页面选一个具体地域；自 2022-12-22 00:00:00 起，全局事件只能在新加坡地域查询。

十二、总结

把全文收成一张决策卡：

1. 定位：ActionTrail 是阿里云账号的「黑匣子」——记录云 API 层谁在什么时候对哪个资源做了什么，旁路运行、开箱即用、产品本身免费。它与云安全中心（资产/威胁）、堡垒机（主机运维会话）、云防火墙（网络流量）、配置审计（配置合规）并联互补。
2. 事件类型：管理事件（控制面，免费保留 90 天）/ 数据事件（数据面，默认关，需建 Trail 开启）/ Insights 事件（七类异常检测，目前免费试用）。
3. Trail 选型：个人单账号用单账号 Trail（每地域最多 5 条）；集团审计用管理账号建多账号 Trail（全局仅 1 条）；想看平台侧操作提工单开 Inner-ActionTrail（仅支持投 SLS）。
4. 投递目的地：要查询分析选 SLS（自动建 actiontrail_{Trail名} Logstore，1 分钟内可见）；要长期归档选 OSS（支持 KMS 加密与 WORM 防篡改）；要做大数据分析选 MaxCompute。
5. 计费真相：ActionTrail 免费，费用全在下游。SLS 按「写入 + 存储」计费（写入约 USD 0.061/GB，存储约 USD 0.002875/GB/天，前 30 天存储免费）；删除 Trail 不删 Logstore，会残留计费。
6. 三条省钱动作：只投递写事件；留存压到 30 天内；冷数据生命周期归档到 OSS。

最后强调两个最容易被忽略的点：一是「快速创建 Trail 会默认记录全部管理事件（含读事件）并投递到 SLS」，这是账单飙升的隐形源头；二是「Trail 只投递新事件，删 Trail 不删 Logstore」这一对组合，既让「以为能看到历史」的人落空，又让「以为删了就停费」的人踩坑。本文全部单价为官方参考价，价格可能变动，请以官方为准；注册与部署前，请确认当地法规合规性。

延伸阅读（本站相关文章）：

• 阿里云国际版注册教程：免实名、支付宝与国内信用卡支付
• 阿里云国际版密钥管理服务 KMS 实战教程
• 阿里云国际版云安全中心实战教程
• 阿里云国际版云防火墙 CFW 实战教程
• 阿里云国际版堡垒机 Bastionhost 实战教程
• 阿里云国际版日志服务 SLS 实战教程
• 阿里云国际版云监控 CloudMonitor 告警专题
• 阿里云国际版对象存储 OSS 实战教程

⚠️ 免责声明：本文中提到的配置、价格和优惠信息可能随时间变化，请以阿里云国际版官网（alibabacloud.com）的实时信息为准。本文不构成任何投资或购买建议。注册前请确认当地法规合规性。

本文由 2.chengzicloud.cloud 提供，点击访问首页了解更多