AWS Certified CloudOps Engineer - Associate (SOA-C03) #8 Domain 3-2 배포: Systems Manager 운영 자동화

2026년 6월 2일 화요일

5 분 소요

#7에서 CloudFormation으로 인프라를 코드로 배포했다면, 이 글은 배포된 인스턴스를 운영하는 도구인 Systems Manager(SSM)를 다룹니다. SSM은 단일 서비스가 아니라 운영 기능의 묶음이고, SOA-C03에서 가장 자주 등장하는 이름 중 하나입니다. 핵심 기능을 운영 시나리오별로 정리하겠습니다.

SSM의 전제: 에이전트와 권한 #

SSM 기능 대부분은 두 가지를 요구합니다.

SSM Agent: 최신 Amazon Linux,Windows AMI에는 기본 포함. 인스턴스가 SSM과 통신
인스턴스 IAM Role: AmazonSSMManagedInstanceCore 정책. 이게 없으면 인스턴스가 SSM에 안 보임

“인스턴스가 Systems Manager 콘솔의 관리 대상 목록에 안 나타난다"는 시나리오의 답은 거의 항상 IAM Role 누락 또는 에이전트,네트워크(엔드포인트) 문제입니다.

Parameter Store: 설정과 비밀 관리 #

애플리케이션 설정,연결 문자열,비밀을 중앙에서 관리하는 저장소입니다.

유형	용도
String / StringList	일반 설정값
SecureString	KMS로 암호화된 비밀(비밀번호,토큰)

계층 경로(/app/prod/db/url)로 환경별 정리
버전 관리로 값 변경 이력 추적
#3에서 본 CloudWatch Agent 설정 저장소로도 표준 사용

Parameter Store vs Secrets Manager #

시험 단골 비교입니다.

항목	Parameter Store	Secrets Manager
비용	표준은 무료	비밀당 유료
자동 교체(rotation)	없음(직접 구현)	내장 자동 교체
RDS 연동	수동	자격 증명 자동 교체 통합

“DB 비밀번호를 주기적으로 자동 교체하라"는 요구의 답은 Secrets Manager입니다. 단순 설정값이면 비용이 없는 Parameter Store가 맞습니다.

Session Manager: 키 없는 접속 #

인스턴스에 SSH 키나 인바운드 포트 없이 셸로 접속하는 기능입니다.

22번 포트를 열지 않아도 됨. 베스천 호스트 불필요
프라이빗 서브넷의 인스턴스에도 접속(VPC 엔드포인트 경유)
모든 세션을 CloudTrail,S3,CloudWatch Logs에 기록해 감사

보안과 운영 양쪽에서 강력한 답입니다. “프라이빗 인스턴스에 SSH 포트를 열지 않고 안전하게 접속하고 접속 기록을 남겨라"는 거의 항상 Session Manager입니다.

Patch Manager: 패치 일괄 적용 #

인스턴스의 OS,애플리케이션 패치를 자동으로 일괄 적용합니다.

구성	역할
Patch Baseline	어떤 패치를 승인,거부할지 규칙
Patch Group	태그로 묶은 패치 대상 그룹
Maintenance Window	패치를 적용할 시간 창

“수백 대 인스턴스에 매월 보안 패치를 정해진 시간에 자동 적용하고, 미적용 인스턴스를 보고하라"는 답이 Patch Manager(+ Maintenance Window + 규정 준수 보고)입니다.

State Manager: 원하는 상태 유지 #

인스턴스가 항상 정해진 구성을 유지하도록 주기적으로 적용합니다.

에이전트 설치 상태, 특정 설정 파일, 도메인 가입 등을 지속적으로 강제
드리프트가 생기면 다시 맞춤

CloudFormation 드리프트 탐지가 “어긋남을 보고"한다면, State Manager는 “어긋남을 다시 맞춤"입니다.

Run Command와 Automation #

기능	성격	예
Run Command	여러 인스턴스에 일회성 명령 실행	전 인스턴스에 스크립트 한 번 실행
Automation	다단계 절차(런북) 실행	#4의 자동 복구

Run Command는 SSH 없이 명령을 동시에 뿌리는 도구입니다. “여러 인스턴스에 동일 명령을 키 없이 실행하라"는 답이 Run Command입니다. Automation은 #4에서 다룬 자동 복구 런북과 같은 기능입니다.

시험 출제 패턴 #

인스턴스가 SSM 관리 대상에 안 보임 → IAM Role(AmazonSSMManagedInstanceCore) 확인
DB 비밀번호 자동 교체 → Secrets Manager
단순 설정값 중앙 관리(무료) → Parameter Store
프라이빗 인스턴스에 키,포트 없이 접속 + 감사 → Session Manager
수백 대 패치 자동 일괄 적용 + 보고 → Patch Manager + Maintenance Window
구성을 지속 강제 → State Manager
여러 인스턴스에 일회성 명령 → Run Command

자주 만나는 함정 #

1) SSM에 인터넷이 필요하다고 단정 #

프라이빗 서브넷 인스턴스는 인터넷 없이도 VPC 인터페이스 엔드포인트로 SSM에 연결됩니다. “프라이빗인데 SSM이 안 된다"는 답이 엔드포인트 구성인 경우가 많습니다.

2) Parameter Store가 자동 교체를 한다고 생각 #

자동 교체는 Secrets Manager의 기능입니다. Parameter Store는 직접 갱신해야 합니다.

3) Session Manager에 22번 포트가 필요하다고 오해 #

Session Manager는 인바운드 포트를 열지 않습니다. 보안 그룹에서 SSH를 막아도 접속됩니다.

4) 패치를 Run Command로 일일이 돌림 #

일회성이면 Run Command지만, 정기,규정 준수 보고가 필요하면 Patch Manager가 맞습니다.

정리 #

이번 글에서 잡은 것:

SSM은 에이전트 + IAM Role(AmazonSSMManagedInstanceCore)이 전제. 관리 목록 누락의 1차 원인
Parameter Store(무료 설정,SecureString) vs Secrets Manager(유료,자동 교체). 비밀 자동 교체는 Secrets Manager
Session Manager로 키,포트 없이 접속 + 전 세션 감사 기록. 베스천 불필요
Patch Manager로 베이스라인,그룹,정비 창 기반 패치 자동화와 준수 보고
State Manager로 원하는 구성 지속 강제, Run Command로 일회성 명령, Automation으로 다단계 런북

다음: Domain 3-3 컨테이너 운영 #

인스턴스 운영을 잡았으니, 다음은 SOA-C03에서 새로 들어온 컨테이너 운영입니다.

#9 Domain 3-3 배포: 컨테이너 운영(ECS,EKS,ECR)에서는 ECS와 EKS의 차이, Fargate와 EC2 시작 유형, ECR로 이미지를 관리하는 법, 컨테이너 로깅과 모니터링, 그리고 배포,스케일링 운영까지 SOA-C03의 새 범위를 정리하겠습니다.