D2-13. Amazon OpenSearch Service
Amazon OpenSearch Service(구 Elasticsearch Service)는 검색(Search) 및 분석(Analytics) 을 위한 관리형 서비스입니다.
Systems Manager(SSM)는 EC2 인스턴스와 온프레미스 Server Fleet을 대규모로 관리하는 데 도움을 주는 서비스입니다.
단일 서비스라기보단 인프라 관리, 문제 탐지, 패치, 자동화, 규정 준수를 위한 강격한 도구 모음입니다.
Server Fleet이란?
규모가 큰 시스템을 운영하기 위해, 다수의 서버를 하나의 그룹으로 묶어 중앙에서 효율적으로 관리하는 것을 의미합니다.
SSM이 EC2 인스턴스를 관리하기 위해서는 두 가지 핵심 요소가 필요합니다.
관리하려는 모든 EC2 인스턴스 및 온프레미스 서버에 SSM 에이전트가 설치되고 실행 중이어야 합니다.
Amazon Linux 2 AMI와 일부 Ubuntu AMI에는 이 에이전트가 기본적으로 포함되어 있습니다.
인스턴스가 SSM 서비스와 통신할 수 있도록 올바른 IAM 권한을 가지고 있어야 합니다.
이 IAM 권한에는 AWS 관리형 정책인 AmazonSSMManagedInstanceCore를 반드시 연결해야 합니다.
# 인스턴스 프로파일(Instance Profile) 생성
aws iam create-role \ --role-name AmazonEC2RoleForSSM \ --assume-role-policy-document file://trust-policy.json
# 인스턴스 프로파일에 AmazonSSMManagedInstanceCore 연결
aws iam attach-role-policy \ --role-name AmazonEC2RoleForSSM \ --policy-arn arn:aws:iam::aws:policy/AmazonSSMManagedInstanceCore
AmazonSSMManagedInstanceCore 정책은 인스턴스 프로파일(Instance Profile) 을 통해 EC2 인스턴스에 할당됩니다.
인스턴스는 이 프로파일을 통해 SSM 서비스와 통신할 수 있는 임시 자격 증명을 자동으로 얻게 됩니다.
| 기능 항목 | 설명 |
|---|---|
| Resource Groups | 태그·속성 기반으로 리소스를 묶어 SSM 작업 대상을 세밀하게 지정 |
| Documents | JSON/YAML 형식의 실행 문서(Playbook)로 Automation, Run Command 등을 정의 |
| Automation | 복잡한 운영·배포 워크플로우를 문서화·자동화하여 일관된 실행 보장 |
| Maintenance Windows | 특정 시간대에 패치·스크립트 실행 스케줄링으로 운영 중단 최소화 |
| Parameter Store | 애플리케이션 설정·보안 정보(Secrets) 중앙 관리 및 버전 관리 |
| Inventory | 에이전트가 설치된 인스턴스의 소프트웨어·설정 현황을 자동 수집·조회 |
| Session Manager | SSH/RDP 없이 웹 콘솔·CLI로 세션 연결, 세션 로그는 CloudWatch에 저장 |
| Run Command | 다수의 인스턴스에 명령 또는 스크립트를 동시에 실행 |
| State Manager | 구성 준수(Desired State)를 선언·강제 적용하여 drift 방지 |
| Patch Manager | OS 패치 레벨을 자동 평가·적용하여 보안 업데이트 일괄 관리 |
| Compliance | 패치 상태 및 구성이 정책을 준수하는지 스캔하고 보고합니다. |
Tags이란?
AWS 리소스(EC2, S3, Lambda 등)에 연결하는 키-값(Key-Value) 페어입니다.
해당 기능을 이용해 리소스 그룹화, 자동화, 보안, 비용 할당 등 다양한 용도로 사용됩니다.
공통 태그를 가진 리소스들을 논리적인 그룹으로 묶는 기능입니다.
태그 기반으로 필터링하여 생성된 그룹을 리소스 그룹이라고 부르며, 리전 단위(Regional) 로 작동합니다.
SSM은 이렇게 생성된 리소스 그룹을 작업 대상(Target) 으로 지정할 수 있습니다.
이를 통해 ‘dev 그룹 전체에 패치 적용’처럼 그룹 단위의 자동화 작업을 효율적으로 수행할 수 있습니다.
Documents는 SSM의 핵심 구성 요소로, 수행할 작업을 정의하는 설명서 또는 플레이북입니다.
형식은 JSON, YAML으로 지원되며, 문서 내에는 파라미터, 단계, 액션 등이 정의가 됩니다.
해당 기능을 통해 Run Command, Automation, Patch Manager, State Manager 등 다른 모든 SSM 기능의 실행 템플릿으로 사용됩니다. 또한 Parameter Store의 값을 동적으로 가져와 사용할 수도 있습니다.

| 유형 | 설명 |
|---|---|
| AWS 관리형 문서 | AWS가 미리 생성하여 제공하는 문서 |
| 사용자 지정 문서 | 사용자가 특정 작업을 위해 직접 생성하는 문서 |
# 파일명: InstallApache.yaml
schemaVersion: '2.2'
description: Install Apache and a custom index page.
parameters:
Message:
type: String
default: Hello World
mainSteps:
- action: aws:runShellScript
name: runShellScript
inputs:
runCommand:
- sudo yum update -y
- sudo yum install -y httpd
- sudo systemctl start httpd
- echo "" > /var/www/html/index.html
| 구성 요소 | 설명 |
|---|---|
| 스키마 (Schema) | 문서의 구조와 버전 정의 |
| 파라미터 (Parameters) | 문서 실행 시 동적으로 값을 전달받기 위한 변수이며, 재사용성을 높여줌 |
| 메인 스텝 (mainSteps) | 실제로 실행될 작업 단계각 단계는 특정 action을 가짐 |
| 액션 (Action) | 각 스텝에서 수행할 구체적인 동작쉘 스크립트 실행, PowerShell 실행, 패치 적용 등 다양한 액션이 수행 |
Run Command는 위에서 정의한 SSM Document를 다수의 인스턴스를 fleet에서 원격으로 실행하는 기능입니다.

# 위 'InstallApache.yaml' 문서를 특정 대상에게 실행시키는 명령어
aws ssm send-command \\
--document-name "InstallApache" \\
--targets "Key=tag:Environment,Values=WebServer" \\
--parameters '{"Message":["Custom Hello World From CLI"]}'
| 주요 특징 | 간략한 설명 |
|---|---|
| SSM 에이전트 | SSH/RDP 포트 개방 없이, SSM 에이전트가 직접 명령을 수신하여 실행합니다. |
| 대상 지정 | 리소스 그룹, 태그, 또는 수동 선택으로 명령을 실행할 대상을 지정합니다. |
| 비율 제어 (Concurrency) | ‘동시에 1대씩’ 또는 ‘전체의 33%씩’ 등 동시 실행 비율을 제어합니다. |
| 오류 제어 (Threshold) | ‘1번만 실패해도 중단’처럼, 오류 발생 시 작업 중단 임계값을 설정합니다. |
| 출력 로깅 | 명령 실행 결과를 S3 또는 CloudWatch Logs로 전송하여 영구 저장합니다. |
| 상태 알림 | 작업 성공/실패 등 진행 상태를 SNS를 통해 알림 받을 수 있습니다. |
| 자동화 트리거 | EventBridge를 사용하여 특정 이벤트 발생 시 Run Command를 자동 실행합니다. |
Automations은 EC2 인스턴스 뿐만 아니라 RDS, S3, EBS와 같은 다양한 AWS 리소스에 대한 일반적인 유지 관리 및 배포 작업을 단순화하고 자동화하는 기능입니다.
| 구분 | Automations | Run Command |
|---|---|---|
| 실행 위치 | 인스턴스 외부 (AWS API 레벨) | 인스턴스 내부 (OS 레벨) |
| 주요 대상 | AWS 리소스 | 인스턴스 내부의 OS |
| 문서 유형 | Runbook (Automation Document) | Command Document |
| 주요 용도 | 리소스 관리 워크플로우 | 원격 스크립트/명령어 실행 |
SSM Automation은 Runbook이라고 불리는 SSM Document를 기반으로 작동합니다.
이 Runbook은 AWS-RestartEC2InstanceWithApproval처럼 AWS가 미리 정의한 것을 사용하거나, JSON/YAML을 이용해 사용자가 직접 작성할 수 있습니다.
| 실행 방식 | 설명 |
|---|---|
| 수동 실행 | AWS 콘솔, CLI, SDK를 통해 사용자가 즉시 실행 |
| 스케줄 기반 | Maintenance Windows를 통해 특정 시간에 예약 실행 |
| 이벤트 기반 | EventBridge 규칙을 통해 특정 이벤트 발생 시 자동 실행 |
| 자동 수정 | AWS Config가 비준수 리소를 발견했을 때, 자동으로 실행하여 수정 |
| 제어 방식 | 설명 |
|---|---|
| 비율 제어(Rate Control) | 동시 실행 비율 제어 |
| 오류 제어(Error Threshold) | 오류 임계값을 설정하여 장애 전파 방지 |
| 다중 계정/리전 | 단일 Automation을 여러 AWS 계정 및 리전에 걸쳐 동시 실행 |
Parameter Store는 애플리케이션의 Configuration 데이터와 Secrets을 안전하게 저장하고 관리하는 Serverless 스토리지 서비스입니다.
| 특징 | 설명 |
|---|---|
| 보안 | IAM을 통해 접근을 제어하며, KMS를 사용하여 파라미터 암호화(Secrets) |
| 버전 관리 | 파라미터가 업데이트될 때마다 자동으로 버전 추적 |
| 통합 | CloudFormation 템플릿에서 직접 파라미터 값을 참조할 수 있으며, EventBridge를 통한 파라미터 변경 또는 만료 알림 |
CloudFormation 템플릿이란?
AWS 인프라(EC2, S3, VPC 등)를 코드로 정의한 ‘설계도’ (JSON/YAML 파일)입니다.이 설계도를 CloudFormation 서비스에 제출하면, AWS가 템플릿에 적힌 모든 리소스를 자동으로, 순서대로, 반복 가능하게 생성해 줍니다. 이를 ‘Infrastructure as Code (IaC)’ 라고 부릅니다.
파라미터를 /my-app/dev/db-password처럼 경로(Path) 기반의 계층 구조로 정리할 수 있습니다.
해당 구조 덕분에 IAM 정책을 효율적으로 관리할 수 있습니다.
ex). /my-app/dev/*의 하위 경로의 모든 파라미터에 대해 dev 팀에게 접근 권한 부여
| 유형 | 설명 | 권한 |
|---|---|---|
| String (일반 텍스트) | 암호화되지 않는 일반 설정 값 | IAM 권한(ssm:GetParameter) |
| SecureString (암호화된 텍스트) | DB 암호나 API 키처럼 민감한 정보를 저장하는 데 사용되며 저장 시 KMS를 사용해 자동으로 암호화된 값 | IAM 권한(ssm:GetParameter), KMS 키 권한(kms:Decrypt) |
| 구분 | Standard | Advanced |
|---|---|---|
| 비용 | 무료 | 파라미터 당 월 $0.05 |
| 최대 크기 | 4KB | 8KB |
| Parameter Policies | 사용 X | 사용 O |
파라미터에 만료 날짜나 변경 규칙을 적용하는 고급 기능입니다.
AWS가 공식적으로 제공하고 관리하는 공용 파라미터입니다.
사용자는 이 파라미터를 통해 AWS 서비스의 최신 정보를 쉽게 조회할 수 있습니다.
Parameter Store와 Secrets Manager는 둘 다 보안 암호를 저장할 수 있지만,
Secrets Manager는 DB 암호 자동 순환(Rotation), 무작위 암호 생성 등 더 강력하고 전문적인 보안 암호 관리 기능을 제공합니다.
Inventory는 인스턴스(EC2, 온프레미스)에서 메타데이터를 수집하여 중앙에서 조회하고 분석할 수 있게 하는 기능힙니다.
이를 통해 인스턴스에 설치된 소프트웨어, 구성, 서비스 상태 등을 파악할 수 있습니다.
| 항목 | 설명 |
|---|---|
| 수집 대상 | 설치된 애플리케이션, OS 드라이버, 구성, 업데이트 내역, 실행 중인 서비스 등 |
데이터 활용 (Inventory Resource Data Sync) |
S3 중앙 저장 > Athena로 SQL 쿼리 및 분석 > QuickSight로 대시보드 시각화 |
| 주요 특징 | 수집 주기 설정 가능, 다중 계정 데이터 중앙 취합, 사용자 정의 Inventory 생성 가능 |
여러 인스턴스와 계정에서 수집된 인벤토리 데이터를 중앙 S3 버킷으로 자동 전송하여 Athena를 통해 통합 분석할 수 있도록 설정하는 기능입니다.
| 단계 | 설명 |
|---|---|
| 1. S3 버킷 생성 | 인벤토리 데이터를 저장할 중앙 S3 버킷을 생성합니다. |
| 2. 버킷 정책 설정 | SSM 서비스(ssm.amazonaws.com)가 해당 S3 버킷에 데이터를 쓸 수 있도록(PutObject 권한) S3 버킷 정책을 설정해야 합니다. |
| 3. 데이터 동기화 생성 | SSM 인벤토리 메뉴에서 ‘Resource Data Sync’를 생성하고, 위에서 만든 S3 버킷을 대상으로 지정합니다. |
| 4. 데이터 쿼리 | 동기화가 완료되면(데모에서 약 5분 소요), SSM 콘솔 또는 Athena 콘솔에서 S3의 데이터를 직접 SQL로 쿼리할 수 있습니다. (예: AWS:Application 타입 조회) |
State Manager는 인스턴스를 사용자가 정의한 특정 상태로 일관되게 유지하는 프로세스를 자동화하는 기능입니다.
State Manager는 연결(Association) 이라는 개념을 사용합니다.
이는 ‘무엇을’(SSM 문서), ‘어디에’(대상 인스턴스), ‘언제’(스케줄) 적용할지 정의하는 것입니다.
| 단계 | 설명 |
|---|---|
| 1. 상태 정의 | SSM 문서를 사용해 원하는 상태(Desired State)를 정의합니다. |
| 2. 연결 생성 | 정의된 문서를 특정 대상 인스턴스 및 스케줄과 연결합니다. |
| 3. 상태 적용/유지 | State Manager가 스케줄에 따라 인스턴스가 정의된 상태를 준수하느니 확인하고, 미준수 시 자동으로 구성 적용합니다. |
Inventory와 State Manager의 관계
“인벤토리 수집 활성화” 자체를 하나의 ‘상태’로 정의할 수 있습니다.
State Manager는 이 설정을 모든 대상 인스턴스에 일관되게 적용하고 유지하는 역할을 합니다..
Patch Manager는 인스턴스의 패치 적용 프로세스를 자동화하는 기능입니다.
OS/애플리케이션/보안 업데이트를 모두 관리합니다.
| 구성 요소 | 설명 |
|---|---|
| Patch Baseline | 인스턴스에 설치할 패치를 결정하는 규칙 세트입니다.승인/거부할 패치를 지정하거나, 릴리스 후 일정 기간이 지나면 자동 승인되도록 설정할 수 있습니다.AWS에서 제공하는 기본 기준 또는 사용자 정의 기준을 사용할 수 있습니다. |
| Patch Group | 인스턴스를 특정 Patch Baseline과 연결하는 방법입니다.인스턴스에 PatchGroup이라는 태그 키를 사용하여 지정하며, 하나의 인스턴스는 하나의 패치 그룹에만 속할 수 있습니다. |
Maintenance Windows는 OS 패치, 드라이버 업데이트 등 시스템에 영향을 줄 수 있는 작업을 수행할 시기(스케줄) 를 정의하는 기능입니다.
| 구성 요소 | 설명 |
|---|---|
| 스케줄 | 작업이 실행될 시간 |
| 기간 | 창이 열려있는 시간 |
| 대상 | 작업이 적용될 인스턴스 (태그 또는 리소스 그룹) |
| 작업 | 해당 기간에 실행할 Task |
Patch Manager와 Maintenance Windows 관계
Patch Manager은 어떤 패치를 설치할지 정의하는 것이며,
Maintenance Windows은 언제 패치를 적용할지 정의하는 스케줄링 도구로, 서비스 영향을 최소화합니다.
Session Manager는 인스턴스에 안전한 Shell 환경을 제공하는 기능입니다.
가장 큰 특징은 SSH 키, Bastion Host, 인바운드 포트 개방 없이 AWS 콘솔, CLI, SDK를 통해 인스턴스에 직접 연결할 수 있다는 점입니다.
Session Manager는 SSM 에이전트와 IAM 권한을 기반으로 동작합니다.
| 구성 요소 | 설명 |
|---|---|
| 인스턴스 | SSM 에이전트가 설치 및 실행 중이어야 합니다.SSM 서비스와 통신할 수 있는 IAM 역할(Instance Profile)이 필요합니다. |
| 사용자 | 인스턴스에 연결할 수 있는 IAM 권한(ssm:StartSession 등)이 필요합니다.IAM 사용자는 AWS API(콘솔, CLI)를 통해 Session Manager 서비스에 연결을 요청합니다. |
| 네트워크 | 인스턴스의 보안 그룹에 인바운드 규칙이 전혀 필요 없습니다.인스턴스가 SSM 서비스 엔드포인트와 통신(Outbound)할 수 만 있으면 됩니다. |

| 특징 | 설명 |
|---|---|
| 보안 강화 | 인바운드 포트 불필요: 외부에 포트를 노출할 필요가 없어 공격 표면이(Attack Surface)가 줄어듬.SSH 키 불필요: 키 페어를 관리, 배포, 순환할 필요가 없음. |
| 접근 제어(IAM) | 세분화된 권한: IAM 정책을 통해 어떤 사용자(User)가 어떤 인스턴스(Resource)에 연결할 수 있는지 제어합니다.태그(Tag) 기반 제어: 인스턴스 태그(예: Environment=Dev)를 기반으로 연결을 제한할 수 있습니다.명령어 제한: 세션 내에서 실행할 수 있는 특정 명령어까지 제한할 수 있습니다. |
| 로깅 및 감사 | 세션 내에서 실행된 모든 명령어와 연결 기록을 CloudWatch Logs 또는 S3로 전송하여 완벽한 감사 추적을 제공합니다. StartSession 같은 API 호출 자체는 CloudTrail에 기록됩니다. |