Cloud Custodian配置offhour过滤器叠加标签过滤无法匹配EC2实例

Cloud Custodian的offhour时间过滤器默认逻辑有两个极易踩中的设计规则，是导致组合过滤匹配数为0的核心原因：

• 默认情况下offhour会优先查找资源上的maid_offhours标签读取调度规则，没有显式指定关联标签时，它不会识别你自定义的Schedule: OfficeHours标签，会直接判定资源不满足过滤条件。
• offhour默认使用UTC时区计算时间，且默认仅在设定的关机时间点之后1小时的时间窗口内匹配资源。你日志中的运行时间为UTC 12:01，设置的offhour为11，已经超出默认1小时匹配窗口，就算标签匹配也无法命中资源。
• 过滤器之间默认是AND逻辑，只要offhour过滤不通过，哪怕前面的标签过滤已经命中实例，最终返回的匹配结果也是0。

给offhour过滤器补全关联标签、时区、匹配窗口参数即可，参考可直接运行的配置如下：

policies:
  - name: stop-after-hours 
    resource: ec2
    filters:
      # 匹配已打Schedule:OfficeHours标签的实例
      - tag:Schedule: "OfficeHours" 
      - type: offhour
        offhour: 11
        # 指定关联你自定义的Schedule调度标签，不再查找默认的maid_offhours标签
        tag: Schedule
        # 替换为你业务实际使用的时区，eu-central-1区域可填CET
        tz: CET
        # 扩大匹配时间窗口为4小时，避免10分钟周期调度的时间差漏匹配
        window: 4
        # 关闭标签值格式校验，直接使用策略中写死的offhour参数，不要求标签值为内置的调度规则格式
        validate: false
    actions:
      - stop
    mode:
      type: periodic
      schedule: "rate(10 minutes)"
      role: arn:aws:iam::XXXXXX:role/LambdaRoleCloudCustodian

• 执行dry-run验证时，要确保运行命令的时间落在「设置的时区下11点到15点」区间内（因为window设为4，关机点后4小时内都能匹配），否则依然会出现匹配数为0的情况。
• 如果后续需要给不同实例设置不同的开关机时间，可以把Schedule标签值改为Custodian识别的结构化格式，比如off=19;on=9;tz=CET，此时可以删掉策略中写死的offhour/tz参数，过滤器会自动从标签值解析调度规则。
• 不需要额外改用value类型的标签过滤器，原生的tag:Schedule: "OfficeHours"写法在组合过滤中是可以正常生效的。

内容的提问来源于stack exchange，提问作者Mornor