Update nexus: fix conflicts and sync local changes
This commit is contained in:
Shen Wei
@@ -1,67 +1,67 @@
|
||||
---
|
||||
title: "CTP Topic 27 AWS Instance Scheduler"
|
||||
type: source
|
||||
tags:
|
||||
- AWS
|
||||
- Instance-Scheduler
|
||||
- Cost-Optimization
|
||||
- CTP
|
||||
- FinOps
|
||||
date: 2026-04-14
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Cloud & DevOps/Public-Cloud-Learning-Sessions/05_FinOps/ctp-topic-27-aws-instance-scheduler.md]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：AWS Instance Scheduler —— 通过定时自动化控制 EC2 和 RDS 实例启停，实现非生产环境（开发/测试）的成本优化
|
||||
- 问题域：非生产 AWS 账号中 EC2/RDS 实例 24/7 运行导致成本浪费，Cloud FinOps 需要自动化手段降低这部分支出
|
||||
- 方法/机制：
|
||||
- CloudFormation 一键部署，由 CCOE 的 Guardrails 框架自动集成推送至所有相关账号
|
||||
- CloudWatch Events 定时触发（默认每 15 分钟）
|
||||
- Lambda 函数读取 DynamoDB 中的调度配置（Schedules + Periods）
|
||||
- 通过实例标签（`Schedule`、`Period`）关联调度规则
|
||||
- 支持多时区办公时间配置（如西雅图时间、英国时间）
|
||||
- 结论/价值：
|
||||
- 自动覆盖公司内部绝大多数月消费超过 10 美元的 AWS 账号
|
||||
- 与基于空闲率的调度不同，本工具基于"时间表"触发
|
||||
- RDS 实例智能配合每 7 天维护窗口，确保维护完成后恢复正常调度状态
|
||||
- 实例关机行为必须设置为"停止（Stop）"而非"终止（Terminate）"以保留数据
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- AWS Instance Scheduler 通过时间表驱动（非空闲率驱动）的定时任务，可为非生产环境实例节省最高 70% 的运行成本
|
||||
- 通过 Guardrails 框架集成，Instance Scheduler 自动部署至公司绝大多数月消费超过 10 美元的 AWS 账号，无需用户手动配置
|
||||
- CloudWatch Events 每 15 分钟触发 Lambda 检查，结合 DynamoDB 中定义的 Schedules 和 Periods，实现精细化的多时区调度
|
||||
- RDS 实例的每 7 天维护窗口与调度系统智能协同，确保维护完成后实例恢复到预期的调度状态
|
||||
|
||||
## Key Quotes
|
||||
> "该工具是基于'时间表'（Schedule）而非'空闲率'（Idle time）触发的" — Gustavo，澄清核心触发机制
|
||||
> "通过 Guardrails，该功能已自动覆盖了公司内部绝大多数月消费超过 10 美元的 AWS 账号" — Gustavo，说明部署覆盖范围
|
||||
> "实例的关机行为必须设置为'停止（Stop）'而非'终止（Terminate）'" — Gustavo，操作注意事项
|
||||
|
||||
## Key Concepts
|
||||
- [[AWS Instance Scheduler]]：AWS 官方提供的开源解决方案，通过 CloudFormation 部署，自动定时启动和停止 EC2 及 RDS 实例以节省成本
|
||||
- [[Guardrails]]：CCOE 团队实施的自动化合规与治理框架，Instance Scheduler 作为其中的成本控制组件被自动部署
|
||||
- [[CloudWatch Events]]：系统的触发器，按照预设的时间间隔（如 15 分钟）激活 Lambda 函数
|
||||
- [[DynamoDB Config Table]]：用于存储调度定义（Schedules）和周期定义（Periods）的 NoSQL 数据库，是调度的逻辑核心
|
||||
- [[Tag-Based Scheduling]]：用户通过在实例上添加特定标签（如 `Schedule`、`Period`）将其关联到预定义的调度逻辑
|
||||
- [[RDS Maintenance Window]]：RDS 特有的每 7 天维护窗口，Instance Scheduler 能够识别并配合该窗口，确保数据库在维护后正确关闭
|
||||
- [[Override Status]]：高级配置，允许管理员强制将实例保持在停止状态，即使在预设的启动时间内也不启动
|
||||
|
||||
## Key Entities
|
||||
- [[Gustavo]]：CCOE 团队成员，Instance Scheduler 主题讲师
|
||||
- [[CCOE（云卓越中心）]]：负责 Guardrails 框架实施和 Instance Scheduler 集成的内部团队
|
||||
- [[AWS]]：Instance Scheduler 的官方服务提供方
|
||||
|
||||
## Connections
|
||||
- [[ctp-topic-13-cloud-finops-policies-best-practices-to-optimize-the-co]] ← depends_on ← [[ctp-topic-27-aws-instance-scheduler]]：Topic 13 定义 FinOps 政策层（标签合规、成本可见性），Topic 27 提供具体技术实现（Instance Scheduler）
|
||||
- [[ctp-topic-63-optimise-resource-cost-using-automation]] ← related_to ← [[ctp-topic-27-aws-instance-scheduler]]：两专题均覆盖 EC2/RDS 自动化调度，Topic 63 侧重 Terraform 层面的 `auto_shutdown` 标签方案，Topic 27 侧重 AWS 原生 Instance Scheduler 方案
|
||||
- [[ctp-topic-71-pcgs-guide-to-rightsizing-why-how-when]] ← extends ← [[ctp-topic-27-aws-instance-scheduler]]：Right Sizing 从实例规格层面降低容量，Instance Scheduler 从运行时间层面降低浪费，构成互补的成本优化策略
|
||||
- [[public-cloud-learning-sessions-budget-control-20240319]] ← related_to ← [[ctp-topic-27-aws-instance-scheduler]]：两专题同属 FinOps 范畴，分别聚焦预算告警强制封禁和实例调度自动节能
|
||||
|
||||
## Contradictions
|
||||
- 与 [[ctp-topic-63-optimise-resource-cost-using-automation]] 可能的实现路径差异：
|
||||
- 冲突点：EC2/RDS 自动调度的实现方案选择
|
||||
- 当前观点：Topic 27 推荐 AWS 原生 Instance Scheduler（CloudFormation + CloudWatch + Lambda + DynamoDB），通过 Guardrails 自动推送覆盖全公司账号
|
||||
- 对方观点：Topic 63 推荐 Terraform Scheduler 模块（`auto_shutdown = yes` 标签），在 Terraform 层面实现
|
||||
- 说明：两者并不互斥——Instance Scheduler 是 AWS 原生方案覆盖广账户层，Terraform Scheduler 是 IaC 层细粒度控制，企业可同时使用
|
||||
---
|
||||
title: "CTP Topic 27 AWS Instance Scheduler"
|
||||
type: source
|
||||
tags:
|
||||
- AWS
|
||||
- Instance-Scheduler
|
||||
- Cost-Optimization
|
||||
- CTP
|
||||
- FinOps
|
||||
date: 2026-04-14
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Cloud & DevOps/Public-Cloud-Learning-Sessions/05_FinOps/ctp-topic-27-aws-instance-scheduler.md]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：AWS Instance Scheduler —— 通过定时自动化控制 EC2 和 RDS 实例启停，实现非生产环境（开发/测试）的成本优化
|
||||
- 问题域：非生产 AWS 账号中 EC2/RDS 实例 24/7 运行导致成本浪费，Cloud FinOps 需要自动化手段降低这部分支出
|
||||
- 方法/机制：
|
||||
- CloudFormation 一键部署，由 CCOE 的 Guardrails 框架自动集成推送至所有相关账号
|
||||
- CloudWatch Events 定时触发（默认每 15 分钟）
|
||||
- Lambda 函数读取 DynamoDB 中的调度配置（Schedules + Periods）
|
||||
- 通过实例标签（`Schedule`、`Period`）关联调度规则
|
||||
- 支持多时区办公时间配置（如西雅图时间、英国时间）
|
||||
- 结论/价值：
|
||||
- 自动覆盖公司内部绝大多数月消费超过 10 美元的 AWS 账号
|
||||
- 与基于空闲率的调度不同，本工具基于"时间表"触发
|
||||
- RDS 实例智能配合每 7 天维护窗口，确保维护完成后恢复正常调度状态
|
||||
- 实例关机行为必须设置为"停止（Stop）"而非"终止（Terminate）"以保留数据
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- AWS Instance Scheduler 通过时间表驱动（非空闲率驱动）的定时任务，可为非生产环境实例节省最高 70% 的运行成本
|
||||
- 通过 Guardrails 框架集成，Instance Scheduler 自动部署至公司绝大多数月消费超过 10 美元的 AWS 账号，无需用户手动配置
|
||||
- CloudWatch Events 每 15 分钟触发 Lambda 检查，结合 DynamoDB 中定义的 Schedules 和 Periods，实现精细化的多时区调度
|
||||
- RDS 实例的每 7 天维护窗口与调度系统智能协同，确保维护完成后实例恢复到预期的调度状态
|
||||
|
||||
## Key Quotes
|
||||
> "该工具是基于'时间表'（Schedule）而非'空闲率'（Idle time）触发的" — Gustavo，澄清核心触发机制
|
||||
> "通过 Guardrails，该功能已自动覆盖了公司内部绝大多数月消费超过 10 美元的 AWS 账号" — Gustavo，说明部署覆盖范围
|
||||
> "实例的关机行为必须设置为'停止（Stop）'而非'终止（Terminate）'" — Gustavo，操作注意事项
|
||||
|
||||
## Key Concepts
|
||||
- [[AWS Instance Scheduler]]：AWS 官方提供的开源解决方案，通过 CloudFormation 部署，自动定时启动和停止 EC2 及 RDS 实例以节省成本
|
||||
- [[Guardrails]]：CCOE 团队实施的自动化合规与治理框架，Instance Scheduler 作为其中的成本控制组件被自动部署
|
||||
- [[CloudWatch Events]]：系统的触发器，按照预设的时间间隔（如 15 分钟）激活 Lambda 函数
|
||||
- [[DynamoDB Config Table]]：用于存储调度定义（Schedules）和周期定义（Periods）的 NoSQL 数据库，是调度的逻辑核心
|
||||
- [[Tag-Based Scheduling]]：用户通过在实例上添加特定标签（如 `Schedule`、`Period`）将其关联到预定义的调度逻辑
|
||||
- [[RDS Maintenance Window]]：RDS 特有的每 7 天维护窗口，Instance Scheduler 能够识别并配合该窗口，确保数据库在维护后正确关闭
|
||||
- [[Override Status]]：高级配置，允许管理员强制将实例保持在停止状态，即使在预设的启动时间内也不启动
|
||||
|
||||
## Key Entities
|
||||
- [[Gustavo]]：CCOE 团队成员，Instance Scheduler 主题讲师
|
||||
- [[CCOE（云卓越中心）]]：负责 Guardrails 框架实施和 Instance Scheduler 集成的内部团队
|
||||
- [[AWS]]：Instance Scheduler 的官方服务提供方
|
||||
|
||||
## Connections
|
||||
- [[ctp-topic-13-cloud-finops-policies-best-practices-to-optimize-the-co]] ← depends_on ← [[ctp-topic-27-aws-instance-scheduler]]：Topic 13 定义 FinOps 政策层（标签合规、成本可见性），Topic 27 提供具体技术实现（Instance Scheduler）
|
||||
- [[ctp-topic-63-optimise-resource-cost-using-automation]] ← related_to ← [[ctp-topic-27-aws-instance-scheduler]]：两专题均覆盖 EC2/RDS 自动化调度，Topic 63 侧重 Terraform 层面的 `auto_shutdown` 标签方案，Topic 27 侧重 AWS 原生 Instance Scheduler 方案
|
||||
- [[ctp-topic-71-pcgs-guide-to-rightsizing-why-how-when]] ← extends ← [[ctp-topic-27-aws-instance-scheduler]]：Right Sizing 从实例规格层面降低容量，Instance Scheduler 从运行时间层面降低浪费，构成互补的成本优化策略
|
||||
- [[public-cloud-learning-sessions-budget-control-20240319]] ← related_to ← [[ctp-topic-27-aws-instance-scheduler]]：两专题同属 FinOps 范畴，分别聚焦预算告警强制封禁和实例调度自动节能
|
||||
|
||||
## Contradictions
|
||||
- 与 [[ctp-topic-63-optimise-resource-cost-using-automation]] 可能的实现路径差异：
|
||||
- 冲突点：EC2/RDS 自动调度的实现方案选择
|
||||
- 当前观点：Topic 27 推荐 AWS 原生 Instance Scheduler（CloudFormation + CloudWatch + Lambda + DynamoDB），通过 Guardrails 自动推送覆盖全公司账号
|
||||
- 对方观点：Topic 63 推荐 Terraform Scheduler 模块（`auto_shutdown = yes` 标签），在 Terraform 层面实现
|
||||
- 说明：两者并不互斥——Instance Scheduler 是 AWS 原生方案覆盖广账户层，Terraform Scheduler 是 IaC 层细粒度控制，企业可同时使用
|
||||
|
||||
Reference in New Issue
Block a user