Skip to content

EMR clster patching without SSM patch manger

0

We're currently running EMR clusters with release version 6.10.0 where instances are patched using SSM "AWS-RunPatchBaseline" during bootstrap. We're experiencing several critical issues: cluster failures when primary nodes reboot during patching, SSM throttling with large clusters (affecting scalability), and extended cluster launch times (>10 minutes). Given EMR's recommendation to move away from SSM-based patching, we're evaluating two alternatives:

  1. upgrading to EMR 7.x with AL2023 (which uses locked repositories and automatic security updates without SSM patching), or
  2. implementing a custom AMI approach.

Could you help us understand the trade-offs between these approaches, specifically around security updates, patching mechanisms, and cluster stability?

If we choose EMR 7.x with AL2023, does it require any additional patching during bootstrap, or will security updates be automatically included when the cluster is created? Also, how does the AL2023 locked repository mechanism handle ongoing security updates compared to our current SSM patching processon emr 6.x?

1 Answer
0

Based on your described issues, I recommend moving to EMR 7.x with AL2023 because:

It directly addresses your current pain points:

  1. Eliminates SSM throttling
  2. Reduces cluster launch times
  3. Improves cluster stability
  4. Removes primary node reboot issues

Provides a more sustainable long-term solution:

  1. Aligned with AWS's recommended approach
  2. Built-in security update mechanism
  3. Reduced operational overhead
  4. Better scalability characteristics

Migration Path:

  1. Start with test workloads
  2. Validate application compatibility
  3. Gradually migrate production workloads
  4. Monitor for any AL2023-specific considerations

The AL2023 approach offers a better balance of security, stability, and operational efficiency compared to both your current SSM-based approach and a custom AMI solution.

Remember to test extensively with your specific workloads before making the switch, as EMR 7.x might have some behavioral differences from 6.x that could affect your applications.

AWS
EXPERT
answered 6 months ago

You are not logged in. Log in to post an answer.

A good answer clearly answers the question and provides constructive feedback and encourages professional growth in the question asker.