--- 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 层细粒度控制,企业可同时使用