CloudFront 实时日志适合在数秒内获取访问事件，用于监控突发 4xx/5xx、缓存异常、机器人流量、发布故障和安全事件。它不会直接把日志保存成可查询报表，而是把选定字段发送到 Amazon Kinesis Data Streams，再由消费者程序、Firehose、Lambda 或其他分析链路处理。
正确使用实时日志的关键是控制三个变量：采样率、字段数量和下游处理能力。如果一开始就对所有 Cache Behavior 使用 100% 采样并选择大量字段，CloudFront 日志费可能不是最大问题，Kinesis 容量、消费者计算、长期存储和查询扫描成本反而更容易失控。
本文配置与价格信息核查日期为 2026 年 8 月 6 日。AWS 服务功能和价格可能调整，实际费用应以当前 CloudFront、Kinesis、Firehose、Lambda、S3 及查询服务价格页为准。
CloudFront 实时日志与标准日志有什么区别？
| 对比项目 | 实时日志 | 标准日志 |
|---|---|---|
| 到达速度 | 通常在请求发生后的数秒内发送 | 批量投递，不适合秒级告警 |
| 目标位置 | Kinesis Data Streams | 按标准日志版本投递到支持的日志目标 |
| 采样率 | 可配置 1% 至 100% | 主要用于完整的批量访问记录 |
| 字段 | 可以选择需要的实时日志字段 | 使用标准日志定义的字段格式 |
| 主要用途 | 实时监控、告警、故障定位和流量检测 | 历史分析、审计、报表和离线查询 |
| 成本结构 | CloudFront 日志行费加 Kinesis 及下游费用 | 日志交付、存储和查询链路费用 |
两种日志并不互相替代。常见做法是保留标准日志作为完整历史数据，同时为关键路径启用一定比例的实时日志，用于快速发现问题。
CloudFront 实时日志的工作流程
一个典型链路如下：
CloudFront Cache Behavior → 实时日志配置 → Kinesis Data Stream → 消费者或 Firehose → 告警、存储和查询系统
实时日志配置主要包含：
采样率：决定符合条件的请求中有多少比例生成实时日志。
字段列表：决定每条记录包含哪些请求、响应、缓存和网络信息。
Endpoint：接收日志的 Kinesis Data Stream。
关联的 Cache Behavior：决定哪些路径和源站行为使用该配置。
实时日志不是自动开启的全局开关。应把配置关联到需要观察的 Cache Behavior，例如 /api/*、/video/* 或默认行为。不同业务路径可以使用不同采样率和字段组合。
配置前需要准备什么？
1. 创建 Kinesis Data Stream
CloudFront 实时日志使用 Kinesis Data Streams 作为接收端。根据 AWS 当前文档，用于实时日志的 Kinesis 数据流需要位于美国东部（弗吉尼亚北部）区域，即 us-east-1。
容量模式可以根据请求量和团队运维方式选择。无论使用哪种模式，都应评估峰值日志记录数和平均记录大小。如果写入能力不足，下游会出现延迟或丢失风险，实时监控也会失去意义。
2. 创建允许 CloudFront 写入的 IAM 角色
CloudFront 需要通过 IAM 角色向目标 Kinesis 数据流写入记录。角色的信任策略应允许 CloudFront 服务代入角色，权限策略则应限制到指定数据流以及必要的 Kinesis 写入操作。
不要为了快速配置而授予整个账号内所有 Kinesis 资源的管理权限。生产环境应使用最小权限，并避免不同业务分配无边界地共用一个高权限角色。
3. 估算日志吞吐
可以先用下面的方式进行粗略估算：
每秒实时日志数 ≈ 每秒 CloudFront 请求数 × 采样率
例如峰值为每秒 20,000 个请求，采样率为 10%，则预计每秒产生约 2,000 条实时日志。实际 Kinesis 容量还需要考虑单条记录大小、分区写入限制、流量突发和消费者读取能力。
如何选择实时日志字段？
字段并不是越多越好。字段越多，单条记录越大，下游解析、网络传输、存储和查询成本也越高。应从问题出发选择字段。
基础访问与性能字段
timestamp：请求时间。c-ip：客户端 IP，属于敏感数据，应设置访问和保留策略。cs-method：HTTP 请求方法。cs-protocol：请求协议。cs-host：请求主机名。cs-uri-stem：URI 路径。sc-status：返回给访问者的 HTTP 状态码。time-taken：CloudFront 处理请求所需时间。
缓存与故障排查字段
x-edge-location：处理请求的边缘位置。x-edge-result-type：请求在 CloudFront 中的结果类型。x-edge-response-result-type：响应阶段的结果分类。x-edge-request-id：可用于关联和排查单次请求。time-to-first-byte：首字节时间，可用于观察响应延迟。
安全与客户端识别字段
cs-user-agent：客户端 User-Agent。cs-referer：来源页面。cs-protocol-version：HTTP 协议版本。ssl-protocol与ssl-cipher：TLS 协议和密码套件。与 WAF、地理位置或请求头相关的字段：按实际检测需求选择。
查询字符串、Cookie、Authorization、客户端 IP 和 User-Agent 可能包含个人信息、令牌或业务敏感数据。不要为了“以后可能用到”而无差别采集。字段选择、脱敏、访问控制和保留期限应符合适用的隐私及合规要求。
四种常见场景如何选字段？
| 场景 | 建议字段方向 | 不应遗漏 |
|---|---|---|
| 监控 4xx/5xx | 时间、路径、状态码、结果类型、边缘位置 | 请求 ID 与主机名 |
| 分析缓存命中 | 路径、查询字符串、结果类型、响应结果、对象大小 | 确认缓存键实际包含哪些参数 |
| 排查 TTFB | 首字节时间、总处理时间、边缘位置、路径、状态码 | 区分命中与回源请求 |
| 识别异常流量 | 客户端 IP、地区、User-Agent、方法、路径、状态码 | 隐私控制与误报复核 |
采样率应该设置多少？
实时日志采样率可以设置为 1% 到 100%。100% 并不一定是最合理的默认值。采样率应由使用目的决定：
1%–5%：适合高流量业务的趋势观察和初步容量验证。
10%–25%：适合缓存、延迟和错误率分析，同时控制成本。
50%–100%：适合关键路径、短期故障调查或必须尽量完整捕获事件的场景。
以上比例是部署方法建议，不是 AWS 强制规则。低采样率可能错过低频错误或针对单个用户的问题；高采样率则会增加 Kinesis 写入和下游处理压力。
更稳妥的方式是按 Cache Behavior 区分：
普通静态资源使用较低采样率。
结账、登录或关键 API 使用更高采样率。
故障期间临时提高采样率，问题结束后恢复。
在提高采样率前先确认 Kinesis 和消费者有足够容量。
如何在控制台配置实时日志？
在
us-east-1创建或选择 Kinesis Data Stream。创建允许 CloudFront 写入该数据流的 IAM 角色。
进入 CloudFront 控制台的实时日志配置页面。
创建配置并填写名称。
设置采样率。
按用途选择需要记录的字段，并确认字段顺序。
选择 Kinesis Endpoint 和 IAM 角色。
把实时日志配置关联到目标分配的 Cache Behavior。
等待配置部署完成，并从 Kinesis 消费端确认记录到达。
不要只看到控制台显示“Enabled”就认为链路正常。还应检查数据流写入量、消费者延迟、解析失败、下游告警和最终存储是否都在工作。
Kinesis 消费端应该如何设计？
Kinesis 只是流式入口。你还需要决定日志如何被消费和保存：
实时告警：消费者读取日志，聚合短时间窗口内的状态码、路径和延迟，并发送告警。
Lambda 处理：适合事件驱动的轻量解析和转换，但要控制批次、并发、错误重试与费用。
Firehose 投递：把处理后的数据批量写入 S3、日志平台或其他支持的目的地。
长期分析：以分区和压缩格式保存到对象存储，再使用查询引擎分析。
消费者必须具备幂等性和错误处理能力。不要假设每一条记录只会被处理一次，也不要让一条格式异常的日志阻塞整个批次。
如何用实时日志监控 4xx 和 5xx？
不要只统计所有 4xx 或 5xx 的总数。应至少按以下维度分组：
状态码，例如 403、404、502、503 和 504。
URI 路径或路径模板。
CloudFront 结果类型。
边缘位置和访问地区。
请求方法和主机名。
发布版本或变更时间。
告警应结合请求量计算比例。例如每分钟 10 个 5xx 对低流量 API 可能很严重，但对每秒几十万请求的静态站点未必异常。建议同时设置：
错误数量阈值。
错误率阈值。
连续时间窗口。
最低请求样本量。
如何分析缓存命中异常？
缓存命中率突然下降时，可以按路径、查询参数、结果类型和时间窗口聚合实时日志。重点检查：
是否刚执行了大范围缓存失效。
源站是否修改了
Cache-Control或Expires。缓存策略是否新加入 Cookie、Header 或查询参数。
对象是否返回不可缓存状态或授权响应。
不同地区是否出现相同问题。
缓存未命中是否伴随 TTFB 和源站 5xx 上升。
实时日志可以迅速发现变化，但最终仍应结合 CloudFront 配置、响应头和源站日志确认原因。
CloudFront 实时日志怎么收费？
截至核查日期，AWS CloudFront 价格页列出的实时日志价格为每生成 100 万条日志记录 0.01 美元。这个价格只代表 CloudFront 实时日志本身，不包含完整链路中的其他服务。
粗略公式为：
CloudFront 实时日志费 = 生成的日志记录数 ÷ 1,000,000 × 0.01 美元
例如每月 30 亿次请求、采样率 10%，预计生成 3 亿条实时日志：
3 亿 ÷ 100 万 × 0.01 = 3 美元
这只是 CloudFront 日志生成费。实际账单还可能包括：
Kinesis Data Streams 容量、写入和读取。
增强型扇出或其他 Kinesis 功能。
Lambda 调用、执行时间和并发。
Firehose 数据处理和投递。
S3 存储、请求和生命周期管理。
日志平台摄取、索引和保留费用。
Athena 或其他查询服务扫描的数据量。
跨区域或其他适用的数据传输。
因此，控制成本的重点通常不是只降低 CloudFront 的每行日志费用，而是减少不必要的字段和记录，压缩长期数据，并避免下游系统反复扫描原始文本。
降低实时日志成本的八个方法
从低采样率开始：先验证数据价值和吞吐，再逐步提高。
只关联关键 Cache Behavior：不要默认覆盖所有静态小文件。
减少字段：只采集实际用于告警、排错或报表的字段。
按事件临时提高采样率：故障结束后及时恢复。
使用列式压缩格式长期保存：降低存储和查询扫描量。
设置数据生命周期：实时数据短期保留，历史数据转低成本存储或删除。
在写入日志平台前聚合：避免把所有原始事件发送到高成本索引系统。
设置预算与容量告警：同时监控日志量、Kinesis 吞吐、消费者延迟和下游费用。
常见配置错误
Kinesis 数据流区域不正确
用于 CloudFront 实时日志的 Kinesis Data Stream 应位于 us-east-1。不要因为 CloudFront 源站位于其他区域，就把实时日志数据流创建在源站区域。
IAM 权限过大或信任关系错误
权限过大会扩大安全风险，信任关系或数据流权限错误则会阻止日志写入。应限制到指定数据流并测试实际投递。
100% 采样但没有容量测试
流量高峰时，Kinesis 和消费者可能无法及时处理。应使用峰值而不是日均请求量规划容量。
采集了令牌和个人信息
日志字段可能包含查询参数、Cookie、IP 和其他敏感信息。应在采集前最小化字段，并在处理链路中执行脱敏和访问控制。
只有采集，没有告警和留存策略
日志进入 Kinesis 并不等于已经产生价值。必须明确谁消费、如何告警、保存多久以及故障时如何补救。
上线检查清单
确认实时日志解决的是秒级监控需求，而不是单纯替代历史日志。
按 Cache Behavior 明确采集范围。
根据用途确定最小字段集合。
检查敏感数据、隐私要求和保留期限。
在
us-east-1创建 Kinesis Data Stream。配置最小权限 IAM 角色和正确的信任关系。
用峰值请求量与记录大小规划吞吐。
从较低采样率开始，并确认日志能够端到端到达。
监控 Kinesis、消费者、告警和存储链路。
分别核算 CloudFront、Kinesis、处理、存储和查询费用。
常见问题
CloudFront 实时日志会记录所有请求吗？
取决于采样率和关联的 Cache Behavior。采样率为 100% 时，会尝试记录符合该配置范围的全部请求；更低比例只记录抽样请求。
实时日志可以直接写入 S3 吗？
实时日志的直接 Endpoint 是 Kinesis Data Streams。需要长期保存到 S3 时，可以通过消费者或数据投递服务构建后续链路。
实时日志能代替 CloudFront 标准日志吗？
通常不能。实时日志适合秒级监控和故障响应，标准日志更适合完整历史记录和离线分析。两者可以同时使用。
采样率 10% 能准确计算总请求数吗？
可以用于趋势估算，但不应当作精确计费或审计数据。低频事件、特定路径和短时间突发在抽样中可能失真。
为什么日志费很低，账单仍然增加很多？
CloudFront 日志生成费只是链路的一部分。Kinesis、消费者计算、日志平台摄取、存储和查询可能远高于日志行费。
结论
CloudFront 实时日志的价值是把 CDN 访问事件在数秒内送入流式处理链路，从而更快发现 4xx/5xx、缓存命中下降、延迟异常和可疑流量。它适合监控和响应，不应被简单视为标准访问日志的替代品。
上线时应先限定 Cache Behavior，选择最少字段并使用较低采样率，确认 Kinesis 和消费者容量后再逐步扩大。成本核算必须覆盖 CloudFront 日志行、Kinesis、处理、存储、索引和查询，而不能只看每 100 万条日志的价格。
CloudFlew 提供基于 CloudFront 的 CDN 服务。配置日志分析时，应结合请求量、字段大小、采样率、保留周期和告警需求设计完整链路，并以当前产品页面和服务条款为准。
参考资料
AWS CloudFront 开发者指南：Real-time logs，核查日期：2026-08-06
AWS CloudFront 开发者指南：Understanding real-time log configurations，核查日期：2026-08-06
AWS CloudFront 开发者指南：Kinesis endpoint requirements，核查日期：2026-08-06
AWS：Amazon CloudFront Pricing，核查日期：2026-08-06
