Sync: add aws source identity notes

wiki/sources/ctp-topic-63-optimise-resource-cost-using-automation.md

@@ -0,0 +1,48 @@
+---
+title: "CTP Topic 63 Optimise resource cost using automation"
+type: source
+tags: []
+date: 2026-04-14
+---
+
+## Source File
+- [[Cloud & DevOps/Public-Cloud-Learning-Sessions/05_FinOps/ctp-topic-63-optimise-resource-cost-using-automation]]
+
+## Summary（用中文描述）
+- 核心主题：使用自动化手段优化 AWS 云资源成本
+- 问题域：云转型计划中如何通过标准化的实例选型、存储优化、承诺计划和自动化调度降低云支出
+- 方法/机制：批准区域（Approved Region）标准化、实例类型选择（ARM/Graviton）、承诺计划（Savings Plans/Reserved Instances）、EBS 存储优化（GP2→GP3）、基于标签的 EC2/RDS 自动化调度（Scheduler）
+- 结论/价值：综合运用多种成本优化手段，组合使用最高可节省 70% 以上的云资源成本
+
+## Key Claims（用中文描述）
+- 企业使用 AWS Graviton ARM 处理器替代 Intel 实例，可节省 20-25% 成本
+- 同配置将实例从 M 系列切换到 R 系列，可节省约 35% on-demand 价格
+- 通过 1 年承诺计划购买 Reserved Instances，可获得约 40% 折扣；3 年承诺可获得约 60-64% 折扣
+- 将 EBS 存储从 GP2 迁移到 GP3，可直接节省 20% 成本
+- 对于非 7×24 运行的工作负载（如开发测试环境），通过自动化调度每天只运行 10 小时，可节省 70% 成本
+
+## Key Quotes
+> "Graviton is mature enough for production" — Graviton ARM 实例已成熟可用于生产环境，比同规格 Intel 便宜 20-25%
+> "Auto shutdown = yes" — Pushka 演示通过 Terraform 模块配置 Scheduler，设置标签实现实例自动停止
+
+## Key Concepts
+- [[Approved Region（批准区域）]]：建议使用的云资源部署区域，有助于提高安全性、标准化管理和优化成本
+- [[Instance Type Selection（实例类型选择）]]：根据工作负载选择合适的实例家族（M/T/C/R/X 系列），以优化性能和成本
+- [[Commitment Plan（承诺计划）]]：通过预先承诺使用云资源一段时间（Savings Plans / Reserved Instances），获得折扣价格
+- [[Automation Scheduler（自动化调度）]]：通过设置定时任务，自动启动和停止云资源，以节省非工作时间的资源成本
+- [[Storage Optimization（存储优化）]]：通过选择合适的存储类型（如 GP3 替代 GP2），及时清理无用存储，合理分配存储空间来降低存储成本
+- [[Graviton]]：AWS 自研 ARM 处理器，比同规格 Intel 便宜 20-25%，已成熟用于生产环境
+- [[Terraform Scheduler Module]]：Terraform 模块，通过标签（如 `auto_shutdown = yes`）配置 EC2/RDS 自动启停
+
+## Key Entities
+- [[Pushka]]：Principal SRE，演示如何使用 Terraform 模块配置 Scheduler 实现实例自动启停
+
+## Connections
+- [[ctp-topic-13-cloud-finops-policies-best-practices-to-optimize-the-co]] ← topic_13 介绍 FinOps 政策框架，本 Topic 补充技术实施细节
+- [[ctp-topic-71-pcgs-guide-to-rightsizing-why-how-when]] ← topic_71 聚焦 RightSizing，与本 Topic 实例选型优化互补
+- [[public-cloud-learning-sessions-reducing-cloud-costs-20250318-170100-meeting-reco]] ← 综合成本优化技术，含 Savings Plans 实施流程
+- [[public-cloud-learning-sessions-best-practices-for-ec2-cost-optimization-in-aws-2]] ← EC2 成本优化最佳实践，含 Graviton 使用
+- [[public-cloud-learning-sessions-storage-cost-optimization-20240305-160037-meeting]] ← 存储优化专题，含 GP2→GP3 迁移
+
+## Contradictions
+- 暂无已知冲突

wiki/sources/public-cloud-learning-sessions-budget-control-20240319-160204-meeting-recording.md

@@ -0,0 +1,52 @@
+---
+title: "Public Cloud Learning Sessions - Budget Control - 20240319"
+type: source
+tags: [FinOps, AWS, Cost-Optimization, Budget-Control, Alerting]
+date: 2024-03-19
+sources: [Cloud & DevOps/Public-Cloud-Learning-Sessions/05_FinOps/public-cloud-learning-sessions-budget-control-20240319-160204-meeting-recording.md]
+last_updated: 2026-04-26
+---
+
+## Source File
+- [[Cloud & DevOps/Public-Cloud-Learning-Sessions/05_FinOps/public-cloud-learning-sessions-budget-control-20240319-160204-meeting-recording.md]]
+
+## Summary（用中文描述）
+- 核心主题：AWS 预算控制自动化系统——面向 SRE Core 团队（Daniela、Evan、Alan）的内部学习分享
+- 问题域：AWS 账户蔓延导致的成本失控，以及现有成本削减措施不可持续的问题
+- 方法/机制：AWS Budget → SNS → Lambda → Step Functions → SCP Enforcement（服务控制策略封禁新资源创建）的完整告警与执行链路；Source Identity 追踪跨角色切换的原始登录身份
+- 结论/价值：提供账户级别的详细告警（支出预测/实际支出/成本驱动因素），并将 Enforcement 从手动审批逐步演进为自动封禁
+
+## Key Claims（用中文描述）
+- SRE Core 团队通过 AWS Budget 服务 + 自定义 Lambda/Step Functions 构建的自动化预算控制，解决了 AWS 账户蔓延导致的成本失控问题
+- 告警类型分为 4 种：Forecast（预测超支）、Actual（实际超支 80%/90%/95%/98%）、Severe（100% 且评分制触发）、Enforcement（100% 且启用强制执行则触发 SCP 封禁）
+- Source Identity（AWS Source Identity 属性）通过 CloudTrail 跨角色切换追踪原始登录用户，解决了联邦登录（NetIQ）中"假设角色后无法识别原始身份"的问题
+- 评分系统（Scoring System）根据账户规模和月末时间节点计算宽限期（Grace Period），避免轻微超支的账户被误处罚
+- 初始实施范围仅限 Lab 账户，其他账户继续接收标准超预算告警
+
+## Key Quotes
+> "This is the first time that we were able to get to this level of granularity." — Daniel，描述通过 Athena + Cost Explorer 实现的资源级成本粒度
+
+## Key Concepts
+- [[AWS-Source-Identity]]：通过 `sts:SourceIdentity` 属性在假设角色后保留原始登录身份，使 CloudTrail 可追踪跨角色用户活动
+- [[FinOps]]：云财务管理，本质是将财务责任与工程实践结合，本 Source 展示 FinOps 执行层（告警→Enforcement）的自动化实现
+- [[AWS-Budget-Alerts]]：AWS Budget 服务原生的预算告警机制，通过 SNS → Lambda → Step Functions 扩展为详细告警邮件
+- [[SCP-Enforcement]]：Service Control Policy，在 100% 预算触发时自动封禁账户新资源创建，实现成本治理的"硬执行"
+- [[CloudTrail]]：AWS 审计日志服务，Source Identity 机制使其能追踪联邦登录跨角色切换的完整用户链
+- [[Step-Functions]]：AWS Step Functions 编排 Lambda 和数据增强逻辑，实现告警流程自动化
+- [[Cost-Explorer]]：AWS 成本分析工具，提供用户维度的日度支出数据，用于 top users 报告
+
+## Key Entities
+- [[Daniela]]：SRE Core 团队成员，负责图表和详细成本报告讲解（提及 <2 次，wikilink 记录）
+- [[Evan]]：SRE Core 团队成员（提及 <2 次，wikilink 记录）
+- [[Alan]]：SRE Core 团队成员，负责 AWS Budget Alerts and Actions 实现细节讲解（提及 <2 次，wikilink 记录）
+- [[SRE-Core-Team]]：预算控制自动化系统的开发团队，由 Daniela、Evan、Alan 三人组成
+- [[Phenops-Team]]：FinOps 执行团队，本 Source 中负责预算分配和 Enforcement 审批决策
+- [[NetIQ]]：联邦身份管理系统（NetIQ Access Manager），用于用户认证并提供 Source Identity 的上游身份
+
+## Connections
+- [[ctp-topic-13-cloud-finops-policies]] ← extends ← [[public-cloud-learning-sessions-budget-control-20240319]]：Topic 13 定义 FinOps 政策框架（成本管理→成本优化→治理自动化三层），本 Source 展示"治理与自动化"层（Budget Enforcement）的具体技术实现
+- [[ctp-topic-63-optimise-resource-cost-using-automation]] ← relates_to ← [[public-cloud-learning-sessions-budget-control-20240319]]：Topic 63 聚焦 RightSizing/承诺计划等主动优化手段，本 Source 聚焦被动告警+强制执行机制，两者互补构成 FinOps 完整闭环
+- [[public-cloud-learning-sessions-reducing-cloud-costs-20250318]] ← extends ← [[public-cloud-learning-sessions-budget-control-20240319]]：2025 版主讲 Vinay（FinOps Lead），补充了 Savings Plans/RI 承诺计划，本 Source 是 2024 早期版本，两者构成 FinOps 知识演进
+
+## Contradictions
+- 与 [[ctp-topic-13-cloud-finops-policies]] 关于 Enforcement 方式：Topic 13 提到"集中式上线/策略开发/自动报告"，本 Source 明确提出 SCP 自动封禁新资源作为 Enforcement 手段；两者不矛盾，Topic 13 描述政策层面，本 Source 描述执行层面

wiki/sources/public-cloud-learning-sessions-storage-cost-optimization-20240305-160037-meeting.md

@@ -0,0 +1,57 @@
+---
+title: "Public Cloud Learning Sessions - Storage Cost Optimization - 20240305"
+type: source
+tags:
+  - AWS
+  - Storage
+  - FinOps
+  - Cost-Optimization
+date: 2024-03-05
+---
+
+## Source File
+- [[Cloud & DevOps/Public-Cloud-Learning-Sessions/05_FinOps/public-cloud-learning-sessions-storage-cost-optimization-20240305-160037-meeting.md]]
+
+## Summary（用中文描述）
+- 核心主题：AWS 存储服务（EBS/EFS/FSx/S3）的成本优化最佳实践与 ADM 实案例证
+- 问题域：公有云存储选型决策、存储层级管理、生命周期策略、数据传输成本控制
+- 方法/机制：按需选择存储类型与层级、智能分层（Intelligent Tiering）、生命周期策略自动化、DLM/AWS Backup 快照管理
+- 结论/价值：正确的存储选型和分层策略可带来显著成本节省；ADM 通过迁移至 FSx for NetApp ONTAP 实现 60% 成本削减
+
+## Key Claims（用中文描述）
+- GP3 相比 GP2 提供 20% 成本优化，且可独立扩展 IOPS 和吞吐量
+- EBS 快照归档层提供比标准层低 75% 的存储成本，但恢复时间更长、保留期为 90 天
+- EFS 不频繁访问层最小计费对象大小为 128KB
+- S3 Intelligent Tiering 可根据访问模式自动在冷热存储层之间迁移数据，且层间迁移无转换费用
+- ADM 迁移至 AWS FSx for NetApp ONTAP 后，相比最初的自管理 NetApp on EC2 方案实现 60% 成本削减
+
+## Key Quotes
+> "With GP3, you can scale IOPS and throughput independently of the volume size." — GP3 核心优势
+> "With Intelligent Tiering we can automatically move data from warmer to colder storage tiers based on object access patterns." — S3 Intelligent Tiering 核心机制
+
+## Key Concepts
+- [[EBS-GP3]]：通用型 SSD（GP3），比 GP2 便宜 20%，可独立扩展 IOPS 和吞吐量
+- [[EBS-Snapshot-Archive]]：EBS 快照归档层，比标准层低 75% 成本，但恢复需 3-12 小时且保留期 90 天
+- [[Data-Lifecycle-Manager]]：AWS DLM，自动化 EBS 快照生命周期管理，可设置保留策略并迁移至归档层
+- [[AWS-Backup]]：AWS 备份服务，可跨服务集中管理备份，支持跨账户跨区域复制
+- [[EFS-Infrequent-Access]]：EFS 不频繁访问层，最小计费对象大小 128KB，通过生命周期策略自动迁移
+- [[S3-Intelligent-Tiering]]：S3 智能分层，根据访问频率自动在多个存储层间迁移，无转换费用
+- [[S3-Lifecycle-Policies]]：S3 生命周期策略，可转换对象层级、过期非当前版本、删除未完成的多段上传
+- [[FSx-for-NetApp-ONTAP]]：AWS 托管 NetApp 文件系统，支持 SSD 和 HDD 分层，自动在层间迁移冷数据
+- [[AWS-PrivateLink]]：通过 AWS 网络内访问 S3 避免数据传输费用
+
+## Key Entities
+- [[AWS]]：Amazon Web Services，云存储服务提供商（EBS/EFS/FSx/S3）
+- [[ADM]]：案例客户，通过三阶段迁移（OpenZFS → 自管理 NetApp on EC2 → FSx for NetApp ONTAP）最终实现 60% 成本削减
+
+## Connections
+- [[public-cloud-learning-sessions-reducing-cloud-costs-20250318-170100-meeting-reco]] ← extends ← [[ctp-topic-13-cloud-finops-policies]]
+- [[EBS-GP3]] ← extends ← [[ctp-topic-13-cloud-finops-policies]]（FinOps 存储优化话题扩展）
+- [[public-cloud-learning-sessions-best-practices-for-ec2-cost-optimization-in-aws-2]] ← extends ← [[public-cloud-learning-sessions-reducing-cloud-costs-20250318-170100-meeting-reco]]（EC2 + Storage 共同构成完整成本优化知识链路）
+
+## Contradictions
+- 与 [[ctp-topic-14-octane-hub-on-aws]] 的潜在冲突（存储选型）：
+  - 冲突点：EFS 与 EBS 的适用场景边界
+  - 当前观点：EFS 适合备份，EBS 适合实时数据库（Octane Hub 案例）
+  - 对方观点：EFS Infrequent Access 和 EFS Archive 层适用于不频繁访问的文件共享场景
+  - 说明：两者均正确，但适用场景不同——EFS 更适合跨多实例共享的文件系统，EBS 更适合单实例高性能块存储