10. Systems Manager (SSM)

1. Overview

 

개요 및 배경

• 대규모 EC2 인스턴스 및 온프레미스(On-premises) 서버 플릿(Fleet)을 중앙 집중식으로 관리하고 제어하기 위한 서비스임
• 인프라 상태에 대한 통찰력을 제공하며, 문제 감지, OS 패치 자동화, 규정 준수(Compliance) 관리를 강화하는 광범위한 도구 모음을 제공함
• Systems Manager 서비스 자체는 무료이며, 운영 과정에서 사용되거나 생성된 기반 리소스(EC2, EBS 등)에 대해서만 요금이 부과됨

주요 리소스 및 주요 기능

1. SSM 에이전트 (SSM Agent)
   • 방식: SSM 서비스가 서버를 원격으로 제어하고 통신하기 위해 대상 EC2 인스턴스나 온프레미스 VM에 반드시 설치되어 실행되어야 하는 필수 소프트웨어임
   • 특징: Amazon Linux 2 AMI 및 일부 Ubuntu AMI에는 기본적으로 번들링되어 제공되므로 별도의 설치 과정 없이 즉시 사용할 수 있음
   • 구성: 기본 내장되어 있지 않은 다른 운영 체제(Windows, 기타 Linux 등)의 경우, 몇 가지 명령어 구동을 통해 에이전트를 수동으로 설치할 수 있음
2.  다양한 관리 기능 모음 (Feature Suite)
   • 노드 관리 (Node Tools): Session Manager, Run Command, Patch Manager(패치 자동화), State Manager, Inventory 등 개별 서버 상태 관리 및 원격 제어 특화 도구
   • 변경 관리 (Change Management): Automation, Maintenance Windows(유지 관리 시간대 지정), Change Calendar 등 작업 예약 및 자동화 도구
   • 애플리케이션 도구 (Application Tools): Parameter Store(파라미터 저장소), AppConfig 등 애플리케이션 구성 및 비밀 데이터 관리 도구
3.  서비스 통합 및 크로스 플랫폼 지원
   • 특징: Windows 및 Linux 운영 체제를 모두 원활하게 지원함
   • 통합: AWS CloudWatch(지표 및 대시보드 수집) 및 AWS Config와 완벽하게 기본 통합되어 인프라의 전반적인 가시성을 높임

헷갈리는 포인트 (Tips)

• 시험에서 특정 EC2 인스턴스가 Systems Manager 콘솔에 등록되지 않거나 제어할 수 없는 트러블슈팅(Troubleshooting) 상황이 매우 자주 출제됨. 원인은 거의 항상 다음 두 가지 중 하나에 속함.
• 첫 번째 원인: 대상 인스턴스에 SSM 에이전트(SSM Agent)가 아예 설치되어 있지 않거나, 실행 중인 상태가 아님.
• 두 번째 원인: EC2 인스턴스가 Systems Manager 서비스 엔드포인트와 통신할 수 있는 올바른 IAM 역할(IAM Role) 및 권한을 부여받지 못함 (예: AmazonSSMManagedInstanceCore 정책 누락).

---

2. SSM Documents & SSM Run Command

 

개요 및 배경

• AWS Systems Manager(SSM)의 핵심은 관리형 인스턴스에서 수행할 작업을 정의하는 SSM Document(문서)임
• Run Command는 지정된 SSM Document를 단일 또는 대규모 EC2 인스턴스/온프레미스 서버 플릿(Fleet) 전체에 걸쳐 원격으로 안전하게 실행하는 도구임
• SSH(포트 22) 접근 권한이나 배스천 호스트(Bastion Host) 없이도 OS 레벨의 명령(쉘 스크립트 등)을 실행할 수 있어 보안성이 매우 높음

주요 리소스 및 구성 요소

1. SSM Document (문서)
   • 구조: JSON 또는 YAML 형식으로 작성되며, 실행 시 동적으로 값을 전달받는 Parameters(파라미터)와 실제 수행할 작업 단계를 정의하는 mainSteps(주요 단계)로 구성됨
   • 유형: Command(명령 실행), Automation(AWS 리소스 관리 자동화), Session(세션 매니저 연결) 등 다양한 목적의 문서 유형이 존재함
   • 제공 방식: AWS가 사전 정의하여 제공하는 수백 개의 관리형 문서(AWS- 접두사, 예: AWS-RunShellScript, AWS-ApplyPatchBaseline)를 활용하거나, 사용자가 직접 커스텀 문서를 작성(Owned by me)할 수 있음
2.  SSM Run Command
   • 대상 지정(Targets): 개별 인스턴스 ID를 직접 선택하거나, 특정 태그(Tags)를 지정하거나, 리소스 그룹(Resource Groups)을 선택하여 다수의 타겟을 한 번에 지정함
   • 속도 제어 (Rate Control): 대규모 배포 시 서비스 중단을 막기 위해, 한 번에 명령을 실행할 인스턴스의 수나 비율(예: 한 번에 10%씩 또는 5대씩)을 제한하는 동시성(Concurrency) 제어 기능이 필수적임
   • 오류 제어 (Error Control): 지정된 오류 임계값(Error threshold, 예: 실패율 5% 초과 또는 2대 실패)에 도달하면 나머지 인스턴스에 대한 명령 실행을 즉시 중단(Abort)함
   • 출력 및 감사: 명령 실행 결과(Standard Out/Error)는 콘솔에서 직접 확인하거나, 영구 보관 및 분석을 위해 Amazon S3 버킷이나 CloudWatch Logs로 전송할 수 있음. 또한, CloudTrail을 통해 "누가 언제 Run Command를 실행했는지" 전체 감사 로그가 기록됨

헷갈리는 포인트 (Tips)

• "SSH 키 페어 분실" 또는 "인바운드 22번 포트를 열 수 없는 매우 엄격한 보안 환경"에서 EC2 인스턴스 내부에 접근하거나 스크립트를 실행해야 하는 시나리오가 나오면, 해결책은 무조건 SSM Run Command (또는 Session Manager)임
• 대규모 플릿에 애플리케이션 업데이트나 패치를 적용할 때 "네트워크 트래픽 스파이크 방지"나 "전체 시스템 동시 다운타임 방지" 요구사항이 주어지면, Run Command의 동시성 제어(Concurrency Control) 및 오류 제어(Error Threshold) 옵션을 적용하는 것이 모범 사례임

---

3. SSM Automations

 

개요 및 배경

• AWS 리소스(EC2 인스턴스, EBS 볼륨, RDS 데이터베이스 등)에 대한 일반적인 유지 관리 및 배포 작업을 간소화하고 자동화하는 기능임
• 앞서 학습한 Run Command가 EC2 인스턴스의 내부(OS 레벨)에서 쉘 스크립트 등을 실행하는 것이라면, SSM Automations는 인스턴스의 외부(AWS API 레벨)에서 리소스를 제어(예: 인스턴스 재시작, AMI 생성, 스냅샷 생성 등)하는 고수준(Higher-level) 작업에 주로 사용됨

주요 리소스 및 작동 방식

1. Automation Runbooks (자동화 런북)
   • SSM Document의 한 유형(Document type: Automation)으로, 흔히 런북(Runbook)이라고 부름
   • AWS가 사전 정의한 다양한 관리형 런북(AWS-RestartEC2Instance, AWS-CreateImage 등)을 제공하며, 복잡한 워크플로우(예: 승인 단계 포함)를 커스텀 런북으로 직접 작성할 수도 있음
   • 대상 리소스: EC2 인스턴스뿐만 아니라 EBS, RDS 등 다양한 AWS 리소스를 제어할 수 있음
2.  자동화 트리거 방식 (Triggers)
   • 수동 실행: AWS 콘솔, AWS CLI, 또는 SDK를 통해 사용자가 직접 실행함
   • EventBridge 규칙 (Rules): 특정 이벤트 발생 시 자동으로 런북을 트리거하도록 구성할 수 있음
   • 유지 관리 기간 (Maintenance Windows): 정해진 스케줄(예: 매주 일요일 새벽)에 맞추어 일괄 작업(예: 전체 플릿 재부팅)을 자동 실행함
   • AWS Config 자동 문제 해결 (Remediation): 규정 준수 검사에서 부적합(Non-compliant)으로 판정된 리소스가 발견되면, SSM Automation 런북을 즉시 호출하여 자동으로 상태를 교정(예: 암호화되지 않은 볼륨에 대한 알림 또는 암호화 적용)함
3.  실행 제어 및 안전 장치
   • Run Command와 마찬가지로 대규모 리소스에 대한 속도 제어(Rate Control / Concurrency) 및 오류 임계값(Error Threshold) 설정을 지원하여, 한 번에 하나씩 안전하게 작업을 수행(예: 인스턴스 1대씩 순차 재시작)하고 오류 발생 시 전체 워크플로우를 중단할 수 있음
   • 실행 시 자동화 작업을 수행할 권한을 가진 IAM 역할(Automation Assume Role)을 지정하여 보안 원칙(최소 권한)을 준수해야 함

헷갈리는 포인트 (Tips)

• 문제에서 "EC2 인스턴스 내부의 구성 파일 변경이나 패키지 설치"가 필요하다면 SSM Run Command가 정답이고, "EC2 인스턴스의 중지/시작, AMI 생성, EBS 스냅샷 백업"과 같은 AWS API 레벨의 작업을 정기적으로 수행해야 한다면 SSM Automations가 정답임
• "AWS Config에서 보안 그룹 포트(예: 22번 포트)가 전체 공개된 것을 발견했을 때 이를 자동으로 닫고 싶다"는 시나리오가 나오면, AWS Config Remediation(자동 문제 해결)과 SSM Automation Runbook을 연동하는 아키텍처를 구성하는 것이 가장 완벽한 모범 사례임

---

4. SSM Parameter Store

 

개요 및 배경

• 애플리케이션의 구성 데이터(Configuration)와 비밀 정보(Secrets)를 안전하게 저장하고 관리할 수 있는 서버리스(Serverless) 기반의 관리형 저장소.
• 데이터베이스 문자열, 비밀번호, 라이선스 키 등을 코드와 분리하여 저장하며, 버전 추적(Version tracking) 기능을 기본적으로 제공.
• AWS IAM을 통한 세밀한 접근 제어, KMS를 이용한 암호화, EventBridge 연동을 통한 알림, 그리고 CloudFormation과의 완벽한 통합을 지원.

주요 리소스 및 기능

1. 계층적 구조 (Hierarchical Structure) 및 IAM 제어
   • 파라미터를 디렉터리 경로처럼 계층적으로 구성할 수 있음. (예: /my-department/my-app/dev/db-url)
   • 이러한 계층 구조는 IAM 정책을 단순화하는 데 매우 유용. 예를 들어, Dev 환경의 Lambda 함수에는 /my-department/my-app/dev/* 경로에 대한 접근 권한만 부여하고, Prod 환경에는 /prod/* 권한만 부여하여 보안을 격리할 수 있음.
2.  저장 유형 및 KMS 연동 (Encryption)
   • 일반 텍스트(Plain text): 암호화가 필요 없는 일반적인 환경 설정값 저장에 사용.
   • 보안 문자열(SecureString): 비밀번호나 API 키 등 민감한 정보를 저장할 때 사용하며, 백그라운드에서 AWS KMS를 사용하여 데이터를 암호화 및 복호화. (이때, 애플리케이션의 IAM 역할에는 Parameter Store 접근 권한뿐만 아니라 해당 KMS 키에 대한 kms:Decrypt 권한도 반드시 있어야 함.)
3.  표준(Standard) vs 고급(Advanced) 티어
   • 표준 (Standard): 무료로 제공되며, 파라미터당 최대 4KB의 크기를 지원. 파라미터 정책(Policies)은 지원하지 않음.
   • 고급 (Advanced): 파라미터당 월 $0.05의 요금이 부과되지만, 최대 8KB의 크기를 지원하며, 파라미터 정책(Parameter Policies) 기능을 사용할 수 있음.
4.  파라미터 정책 (Parameter Policies - Advanced 전용)
   • 고급 티어에서만 제공되는 기능으로, 파라미터에 TTL(Time to Live, 만료일)을 할당하여 민감한 데이터(예: 비밀번호)의 주기적인 변경 및 삭제를 강제할 수 있음.
   • EventBridge와 연동되어 파라미터 만료 15일 전에 사전 알림을 보내거나, 특정 기간(예: 20일) 동안 파라미터가 변경되지 않았을 때(NoChangeNotification) 경고 알림을 트리거하여 보안 규정 준수를 도움.
5.  퍼블릭 파라미터 및 Secrets Manager 통합
   • 퍼블릭 파라미터: AWS가 자체적으로 제공하고 업데이트하는 파라미터. (예: 특정 리전의 최신 Amazon Linux 2 AMI ID를 API 호출 한 번으로 가져올 수 있음)
   • Secrets Manager 참조: Parameter Store의 API를 사용하면서도 특정 참조 구문을 통해 AWS Secrets Manager에 저장된 비밀 정보를 직접 가져올 수 있음. (하나의 코드로 두 서비스를 모두 유연하게 활용 가능)

헷갈리는 포인트 (Tips)

• 문제에서 "비용을 최소화하면서 설정값을 저장하고 싶다"는 요구사항이 나오면 SSM Parameter Store (Standard Tier)가 정답. 반면, "자동으로 비밀번호를 교체(Rotation)해야 한다"는 요구사항이 명시되어 있다면 이는 Parameter Store가 아닌 AWS Secrets Manager의 고유 기능.
• CloudFormation 템플릿에서 Parameter Store에 저장된 값을 동적으로 참조하여 스택 배포 시 최신 AMI나 비밀번호를 주입하는 패턴이 자주 출제되므로 연동 개념을 꼭 기억.

---

5. SSM Patch Manager and Maintenance Windows

 

개요 및 배경

• 대규모 EC2 인스턴스 및 온프레미스 서버 환경에서 OS, 애플리케이션, 보안 업데이트 패치 적용 프로세스를 자동화하는 핵심 서비스.
• 사용자가 원할 때 즉시(On-demand) 패치를 실행할 수도 있고, 서비스 중단을 최소화하기 위해 유지 관리 기간(Maintenance Windows)을 설정하여 예약된 일정에 따라 자동 실행할 수도 있음.
• 패치 적용 후 인스턴스의 패치 상태를 스캔하여 패치 규정 준수 보고서(Patch Compliance Report)를 생성하고, 이를 Amazon S3로 전송하여 감사(Audit) 목적으로 활용할 수 있음.

주요 리소스 및 기능

1. 패치 베이스라인 (Patch Baselines)
   • 인스턴스에 설치해야 할 패치와 거부할(설치하지 않을) 패치의 명확한 규칙을 정의.
   • 사전 정의된 베이스라인 (Predefined): AWS가 관리하며 수정할 수 없음. 기본적으로 '중요(Critical)' 및 '보안(Security)' 관련 패치만 자동으로 승인하여 설치하도록 구성되어 있음.
   • 사용자 지정 베이스라인 (Custom): 릴리스 후 며칠이 지나면 패치를 자동 승인할지(Auto-approve), 명시적으로 거부/허용할 패치는 무엇인지, 자체 사내 패치 리포지토리를 사용할지 등을 자유롭게 정의할 수 있음.
2.  패치 그룹 (Patch Groups)
   • 특정 패치 베이스라인을 적용할 인스턴스들의 논리적인 묶음. (예: dev, test, prod)
   • 대상을 지정하기 위해 인스턴스에 반드시 태그 키(Tag Key)를 Patch Group으로 설정.
   • 매핑 규칙 (중요): 하나의 인스턴스는 오직 단 하나의 패치 그룹에만 속할 수 있으며, 하나의 패치 그룹은 단 하나의 패치 베이스라인에만 연결될 수 있음. Patch Group 태그가 지정되지 않은 인스턴스는 시스템의 '기본(Default) 패치 베이스라인'을 적용받음.
3.  유지 관리 기간 (Maintenance Windows)
   • 업무 외 시간(예: 새벽 3시 ~ 5시) 등 리소스에 대한 유지 관리 작업(OS 패치, 드라이버 업데이트, 소프트웨어 설치 등)을 안전하게 수행할 수 있는 스케줄을 정의.
   • 특정 일정(Schedule), 지속 시간(Duration), 대상(Registered Instances), 그리고 실행할 작업(Tasks)의 묶음으로 구성.

헷갈리는 포인트 (Tips)

• 패치 매니저의 실제 패치 설치 작업은 백그라운드에서 SSM Run Command와 AWS-RunPatchBaseline이라는 AWS 관리형 SSM 문서를 통해 수행. 에이전트가 이 문서를 실행하며 패치 매니저 서비스에 쿼리하여 설치할 패치 목록을 받아옴.
• 문제에서 "프로덕션 환경의 서비스 가용성에 영향을 주지 않으면서(다운타임 최소화) 수백 대의 인스턴스에 최신 보안 패치를 일괄 적용해야 한다"는 요구사항이 나오면 정답의 핵심 키워드는 다음 3가지 조합.
  1. SSM Patch Manager (패치 규칙 정의)
  2. Maintenance Windows (업무 외 시간에 스케줄링)
  3. Rate Control / Concurrency (동시성 제어를 통해 한 번에 전체가 다운되는 것을 방지)