如何为Amazon EMR集群安装安全关键和重要级别的补丁？

1. 手动执行yum/Patch Manager打补丁的可行性说明 #

• 技术层面：EMR 5.31.0底层确实运行Amazon Linux 2系统，你可以通过SSH登录节点执行yum update --security --sec-severity=Critical --sec-severity=Important命令仅安装安全关键和重要级补丁，也可以通过AWS Systems Manager Patch Manager批量操作，不用逐个登录节点。
• 官方推荐性：这不是官方默认推荐的生产级操作，原因如下：

  EMR预安装的大数据组件（Hadoop、Spark、Hive等）对特定依赖包的版本有强绑定，手动更新系统包可能导致组件版本冲突、服务异常甚至集群不可用，修改运行中节点的系统环境也会破坏EMR集群的版本一致性，后续扩容新节点时会因为新节点用的是官方原始AMI，和现有打过补丁的节点环境不一致引发故障。

2. 自定义AMI方案是否为唯一合规方案 #

• 自定义AMI是官方推荐的长期补丁管理方案，适合需要长期运行、对安全性要求高的集群，操作逻辑是基于官方EMR 5.31.0的基础AMI打好所需安全补丁后，再用自定义AMI创建集群，所有节点（包括后续扩容的节点）都会使用一致的补丁环境，不会出现版本冲突问题。
• 更简便的临时方案：如果你只是临时需要给短期运行的测试集群打补丁，不需要长期维护，可以使用EMR的引导操作功能，在集群启动时执行安全补丁安装脚本，这样不需要提前制作自定义AMI，流程更轻量，同样能保证所有节点的补丁环境一致。注意引导操作只在集群启动、节点初始化阶段执行，不会修改运行中节点的环境，也不会影响现有运行的业务。

3. 升级到EMR 6.x版本方案的可行性 #

这个方案是可行的，而且是官方推荐的中长期优化方案：

• EMR 6.x版本的基础操作系统更新，自带的安全补丁基线更高，后续版本迭代也会同步推送安全更新，你可以直接选择最新的EMR 6.x小版本，不需要手动额外打大量历史安全补丁。
• 操作方式可以先克隆现有集群的配置，在测试环境验证作业在EMR 6.x上的兼容性，确认无误后再切换生产流量到新集群，旧集群可以直接销毁，避免手动打补丁带来的稳定性风险。

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