AWS Systems Manager Patch Manager를 사용하여 운영 중인 서버 그룹에 보안 패치를 일괄 적용하고 리포트를 생성하는 방법은 무엇인가요?

SSM Patch Manager 자동화 워크플로우

1단계: 패치 기준(Patch Baseline) 정의

"어떤 패치를 설치할 것인가?"를 결정하는 규칙 세트입니다.

• 동작: 운영체제별(Ubuntu, Windows, Amazon Linux 등)로 '심각도(Critical)'나 '보안(Security)' 관련 패치를 출시 후 며칠 뒤에 자동으로 승인할지 정합니다.

• 팁: AWS가 제공하는 '기본 패치 기준(Default Baseline)'을 그대로 써도 훌륭하지만, 특정 패치를 제외해야 한다면 커스텀 기준을 만드세요.

2단계: 패치 그룹(Patch Group) 구성

"어느 서버에 적용할 것인가?"를 정하는 단계입니다.

• 방법: EC2 인스턴스에 Patch Group이라는 태그(Tag)를 추가합니다. (예: Key: Patch Group, Value: Production-Web)

• 이점: 이 태그를 통해 개발용 서버와 운영용 서버의 패치 주기를 다르게 가져갈 수 있습니다.

3단계: 유지 관리 시간(Maintenance Window) 설정

"언제 패치할 것인가?"를 정합니다. 서비스 중단을 최소화하기 위한 필수 과정입니다.

1. SSM 콘솔 → [유지 관리 시간]에서 실행 시간을 정합니다. (예: 매주 일요일 새벽 3시)

2. 작업 등록: AWS-RunPatchBaseline 명령을 실행하도록 등록하고, 위에서 만든 패치 그룹을 대상으로 지정합니다.

3. 작업 선택: Scan(검사만 수행) 또는 Install(검사 후 설치) 중 하나를 선택합니다.

4단계: 준수 확인 및 리포트 생성 (Reporting)

패치가 잘 끝났는지 증거를 남겨야 합니다.

• 구성 준수(Compliance): SSM 콘솔의 [준수] 메뉴에서 리전 내 모든 인스턴스의 패치 상태를 한눈에 대시보드로 확인합니다.

• S3 내보내기: 상세 리포트가 필요하다면 SSM Inventory 기능을 통해 패치 현황을 S3로 내보낸 뒤, Amazon Athena나 QuickSight로 시각화된 리포트를 생성할 수 있습니다.

패치 방식 비교: "지금 즉시" vs "스케줄링"

Tip

패치 후 '재부팅' 옵션을 반드시 확인하세요!

보안 패치 중에는 커널 업데이트처럼 재부팅이 필수인 경우가 많습니다. AWS-RunPatchBaseline 실행 시 RebootOption을 잘못 설정하면, 대낮에 운영 중인 웹 서버가 갑자기 꺼지는 대참사가 발생할 수 있습니다.

'다중 가용 영역(Multi-AZ)'에 서버를 나누어 배치하고, 한쪽 영역이 패치되는 동안 다른 쪽이 트래픽을 감당하게 하는 교차 패치 전략을 사용합니다.