管理与治理

1. CloudWatch Metrics：时间序列，不是日志行

平均延迟可能掩盖长尾，应根据 SLA 监控 p95/p99。错误计数通常看 Sum，资源利用率常看 Average/Max，不能机械地对所有指标使用同一 statistic。

Metric Streams 把近实时指标持续传给 Firehose/外部监控；GetMetricData/仪表盘用于查询和展示。它们解决的是指标分发与观察，不替代原始应用日志。

2. CloudWatch Logs：事件文本与结构化记录

多账户/多 Region 环境可集中日志和指标到观测账户。集中化不等于所有团队都应拥有原始敏感 payload；仍需最小权限和日志脱敏。

3. Alarm 把观察转为动作

状态包括 OK、ALARM、INSUFFICIENT_DATA。Alarm 可通知 SNS、触发 Auto Scaling 或自动化动作；部署 guardrails 用 alarm 决定是否回滚。合理设置 evaluation periods 和 datapoints to alarm，避免单点毛刺。

4. SageMaker endpoint 指标如何定位延迟

客户端端到端延迟还包括客户端到 SageMaker Runtime API 的网络延迟。不要把所有延迟都归咎于模型：先分解 network、overhead、model 三段。

主来源：SageMaker metrics in CloudWatch

5. AWS X-Ray：一次请求经过了哪里

X-Ray 适合 API Gateway → Lambda → 推理 endpoint → 数据库的跨服务延迟定位。它不替代模型质量/漂移监控，也不会自动收集未 instrument 的所有内部逻辑。

6. Amazon Quick（原 Amazon QuickSight）

2026 年 Amazon QuickSight 已重命名并扩展为 Amazon Quick。课件和考试题仍可能使用 QuickSight 名称；把它们视为同一产品演进。

图表按问题选：时间变化用 line，类别比较用 bar，相关性用 scatter/heat map，目标对比用 KPI/gauge，层级占比用 tree map。饼图不适合大量类别和细微比较。

7. CloudTrail：谁在何时调用了哪个 API

Event history 提供近期 management events；需要长期、跨账户审计时创建 trail，把事件送到 S3，并可接 CloudWatch Logs/EventBridge。CloudTrail 记录 API 活动，不记录模型内部预测内容。

8. AWS Config：资源现在和以前是怎么配置的

• Configuration item/history：记录支持资源的配置与关系变化。
• Config rule：持续/触发式评估资源是否符合要求。
• Conformance pack：成组部署规则和 remediation。
• Remediation：通过 Systems Manager Automation 等自动修复不合规资源。

Config 回答“这个 security group 何时变成不合规、当时配置是什么”；CloudTrail 回答“谁调用 API 改了它”。二者结合才形成完整调查。

9. 四种证据对照

记忆：CloudWatch 看运行，X-Ray 看路径，CloudTrail 看动作，Config 看状态。

主来源：AWS CloudTrail or Amazon CloudWatch?

10. 成本工具按动作分层

• 先启用并规范 cost allocation tags，例如 owner、project、environment、model。
• 训练用 Spot + checkpoint；稳定长期计算评估 Savings Plans/承诺；间歇推理评估 serverless/async scale-to-zero。
• 删除 idle notebook、endpoint 和实验资源；设置日志 retention 和 S3 lifecycle。
• 不要只比较小时单价，要比较达到目标质量/吞吐所需的总成本。