• AWS Systems Manager CloudWatch 대시보드는 2026년 4월 30일 이후에는 더 이상 사용할 수 없습니다. 고객은 Amazon CloudWatch 콘솔을 계속 사용하여 현재와 마찬가지로 Amazon CloudWatch 대시보드를 보고, 생성하고, 관리할 수 있습니다. 자세한 내용은 [Amazon CloudWatch 대시보드 설명서](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html)를 참조하세요.
# AWS Systems Manager Patch Manager 자습서
이 섹션의 자습서에서는 여러 패치 적용 시나리오에 AWS Systems Manager의 도구인 Patch Manager를 사용하는 방법을 보여줍니다.
**Topics**
+ [자습서: IPv6 전용 환경에서 서버 패치 적용](patch-manager-server-patching-iPv6-tutorial.md)
+ [자습서: 콘솔을 사용한 Windows 서비스 팩 설치를 위한 패치 기준 생성](patch-manager-windows-service-pack-patch-baseline-tutorial.md)
+ [자습서: 콘솔을 사용한 애플리케이션 종속성 업데이트, 관리형 노드 패치, 애플리케이션별 상태 확인 수행](aws-runpatchbaselinewithhooks-tutorial.md)
+ [자습서: AWS CLI를 사용한 서버 환경에 패치 적용](patch-manager-patch-servers-using-the-aws-cli.md)
# 자습서: IPv6 전용 환경에서 서버 패치 적용
Patch Manager는 IPv6만 있는 환경에서 노드의 패치 적용을 지원합니다. SSM Agent 구성을 업데이트하면 IPv6 서비스 엔드포인트만 직접적으로 호출하도록 패치 작업을 구성할 수 있습니다.
**IPv6 전용 환경에서 서버를 패치하려면**
1. SSM Agent 3.3270.0 이상이 관리형 노드에 설치되어 있는지 확인합니다.
1. 관리형 노드에서 SSM Agent 구성 파일로 이동합니다. 다음 디렉터리에서 `amazon-ssm-agent.json` 파일을 찾을 수 있습니다.
+ Linux: `/etc/amazon/ssm/`
+ macOS: `/opt/aws/ssm/`
+ Windows Server: `C:\Program Files\Amazon\SSM`
`amazon-ssm-agent.json`이 아직 존재하지 않는 경우 동일한 디렉터리에 있는 `amazon-ssm-agent.json.template`의 콘텐츠를 `amazon-ssm-agent.json`에 복사합니다.
1. 다음 항목을 업데이트하여 올바른 리전을 설정하고 `UseDualStackEndpoint`를 `true`로 설정합니다.
```
{
--------
"Agent": {
"Region": "region",
"UseDualStackEndpoint": true
},
--------
}
```
1. 운영 체제에 맞는 명령을 사용하여 SSM Agent 서비스를 다시 시작합니다.
+ Linux: `sudo systemctl restart amazon-ssm-agent`
+ Snap 사용 시 Ubuntu Server: `sudo snap restart amazon-ssm-agent`
+ macOS: `sudo launchctl stop com.amazon.aws.ssm` 다음에 `sudo launchctl start com.amazon.aws.ssm`
+ Windows Server: `Stop-Service AmazonSSMAgent` 다음에 `Start-Service AmazonSSMAgent`
운영 체제별 전체 명령 목록은 [SSM Agent 상태 확인 및 에이전트 시작](ssm-agent-status-and-restart.md) 섹션을 참조하세요.
1. 패치 작업을 실행하여 IPv6 전용 환경에서 패치 작업이 성공했는지 확인합니다. 패치되는 노드가 패치 소스에 연결되어 있는지 확인합니다. 패치 실행의 Run Command 출력을 확인하여 액세스할 수 없는 리포지토리에 대한 경고를 확인할 수 있습니다. IPv6 전용 환경에서 실행 중인 노드에 패치를 적용할 때는 노드가 패치 소스에 연결되어 있는지 확인합니다. 패치 실행의 Run Command 출력을 확인하여 액세스할 수 없는 리포지토리에 대한 경고를 확인할 수 있습니다. DNF 기반 운영 체제의 경우 `/etc/dnf/dnf.conf`에서 `skip_if_unavailable` 옵션이 `True`로 설정되면 패치 적용 중에 사용할 수 없는 리포지토리를 건너뛰도록 구성할 수 있습니다. DNF 기반 운영 체제에는 Amazon Linux 2023, Red Hat Enterprise Linux 8 이상 버전, Oracle Linux 8 이상 버전, Rocky Linux, AlmaLinux 및 CentOS 8 이상 버전이 포함됩니다. Amazon Linux 2023에서는 `skip_if_unavailable` 옵션이 기본적으로 `True`로 설정됩니다.
**참고**
설치 재정의 목록 또는 기준 재정의 기능을 사용하는 경우 제공된 URL에 노드에서 연결할 수 있는지 확인합니다. SSM Agent 구성 옵션 `UseDualStackEndpoint`가 `true`로 설정된 경우 S3 URL이 제공될 때 듀얼 스택 S3 클라이언트가 사용됩니다.
# 자습서: 콘솔을 사용한 Windows 서비스 팩 설치를 위한 패치 기준 생성
사용자 정의 패치 기준을 만들 때 지원되는 모든 패치 또는 일부 또는 한 가지 유형의 패치만 설치하도록 지정할 수 있습니다.
Windows의 패치 기준에서 패치 업데이트를 서비스 팩으로만 제한하기 위해 `ServicePacks`를 유일한 **분류** 옵션으로만 선택할 수 있습니다. Windows Update 또는 WSUS(Windows Server Update Services)에서 업데이트를 사용할 수 있는 경우 AWS Systems Manager의 도구인 Patch Manager로 서비스 팩을 자동 설치할 수 있습니다.
모든 Windows 버전에 대한 서비스 팩의 설치 여부를 제어하거나 Windows 7 또는 Windows Server 2016과 같은 특정 버전에 대한 서비스 팩만 설치할지 여부를 제어하도록 패치 기준을 구성할 수 있습니다.
Windows 관리형 노드에 모든 서비스 팩을 설치하는 데만 사용할 사용자 정의 패치 기준을 만들려면 다음 절차를 따르세요.
**Windows 서비스 팩 설치를 위한 패치 기준선을 생성하려면(콘솔)**
1. [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)에서 AWS Systems Manager 콘솔을 엽니다.
1. 탐색 창에서 **Patch Manager**를 선택합니다.
1. **패치 기준선** 탭을 선택한 다음 **패치 기준선 생성**을 선택합니다.
1. **Name(이름)** 필드에 새로운 패치 기준 이름(예: `MyWindowsServicePackPatchBaseline`)을 입력합니다.
1. (선택 사항) **설명**에 이 패치 기준에 대한 설명을 입력합니다.
1. **운영 체제**에서 `Windows`를 선택합니다.
1. 이 패치 기준을 생성하는 즉시 Windows의 기본값으로 사용하려면 **Set this patch baseline as the default patch baseline for Windows Server instances(이 패치 기준을 Windows Server 인스턴스의 기본 패치 기준으로 설정)**를 선택하십시오.
**참고**
이 옵션은 2022년 12월 22일에 [패치 정책](patch-manager-policies.md)이 릴리스되기 전에 Patch Manager에 처음 액세스한 경우에만 사용할 수 있습니다.
기존 패치 기준을 기본값으로 설정하는 방법에 대한 자세한 내용은 [기존 패치 기준을 기본값으로 설정](patch-manager-default-patch-baseline.md) 섹션을 참조하세요.
1. **Approval rules for operating systems(운영 체제에 대한 승인 규칙)** 섹션에서 필드를 사용하여 자동 승인 규칙을 한 개 이상 생성합니다.
+ **제품**: 승인 규칙이 적용되는 운영 체제 버전입니다(예: `WindowsServer2012`). 지원되는 Windows 버전을 하나 또는 둘 이상 또는 모두 선택할 수 있습니다. 기본 선택은 `All`입니다.
+ **Classification(분류)**: `ServicePacks`를 선택합니다.
+ **Severity(심각도)**: 규칙이 적용될 패치의 심각도 값입니다. 모든 서비스 팩이 규칙에 포함되도록 하려면 `All`을 선택합니다.
+ **Auto-approval**: 자동 승인을 위해 패치를 선택하는 방법입니다.
+ **Approve patches after a specified number of days**(지정된 일 수 후 패치 승인): 패치가 릴리스 또는 업데이트된 후 자동으로 승인되기까지 Patch Manager가 대기하는 일 수입니다. 0\$1360의 정수를 입력할 수 있습니다. 대부분의 시나리오에서 100일 이상 기다리지 않는 것이 좋습니다.
+ **Approve patches released up to a specific date**(특정 날짜까지 릴리스된 패치 승인): Patch Manager가 해당 날짜 또는 그 이전에 릴리스 또는 업데이트된 모든 패치를 자동으로 적용하는 패치 릴리스 날짜입니다. 예를 들어 2023년 7월 7일을 지정하면 2023년 7월 8일 또는 그 이후에 릴리스되거나 마지막으로 업데이트된 패치가 자동으로 설치되지 않습니다.
+ (선택 사항) **Compliance reporting(규정 준수 보고)**: 기준에서 승인된 서비스 팩에 할당할 심각도 수준입니다(예: `High`).
**참고**
규정 준수 보고 수준을 지정하고 승인된 서비스 패치의 패치 상태가 `Missing`으로 보고되는 경우 패치 기준선의 전반적인 보고된 규정 준수 심각도는 사용자가 지정한 심각도 수준입니다.
1. (선택 사항) **Manage tags(태그 관리)**의 경우, 하나 이상의 태그 키 이름/값 페어를 패치 기준에 적용합니다.
태그는 리소스에 할당하는 선택적 메타데이터입니다. 태그를 사용하면 용도, 소유자 또는 환경을 기준으로 하는 등 리소스를 다양한 방식으로 분류할 수 있습니다. 서비스 팩 업데이트 전용인 이 패치 기준의 경우 다음과 같은 키-값 쌍을 지정할 수 있습니다.
+ `Key=OS,Value=Windows`
+ `Key=Classification,Value=ServicePacks`
1. **패치 기준 생성**을 선택합니다.
# 자습서: 콘솔을 사용한 애플리케이션 종속성 업데이트, 관리형 노드 패치, 애플리케이션별 상태 확인 수행
대부분의 경우 관리형 노드는 최신 소프트웨어 업데이트로 패치된 후 재부팅해야 합니다. 그러나 안전 장치 없이 프로덕션 환경에서 노드를 재부팅하면 경보 호출, 잘못된 지표 데이터 기록, 데이터 동기화 중단과 같은 여러 문제가 발생할 수 있습니다.
이 자습서에서는 AWS Systems Manager 문서(SSM 문서) `AWS-RunPatchBaselineWithHooks`를 사용하여 다음을 수행하는 복잡한 다단계 패치 작업을 수행하여 이러한 문제를 피하는 방법을 보여줍니다.
1. 애플리케이션에 새로 연결 방지
1. 운영 체제 업데이트 설치
1. 애플리케이션의 패키지 종속성 업데이트
1. 시스템 다시 시작
1. 애플리케이션별 상태 확인 수행
이 예에서는 인프라를 다음과 같이 설정했습니다.
+ 대상 가상 머신은 Systems Manager에 관리형 노드로 등록됩니다.
+ `Iptables`는 로컬 방화벽으로 사용됩니다.
+ 관리형 노드에서 호스팅되는 애플리케이션이 포트 443에서 실행되고 있습니다.
+ 관리형 노드에서 호스팅되는 애플리케이션이 `nodeJS` 애플리케이션입니다.
+ 관리형 노드에서 호스팅되는 애플리케이션이 pm2 프로세스 관리자에 의해 관리됩니다.
+ 애플리케이션에 이미 지정된 상태 확인 엔드포인트가 있습니다.
+ 애플리케이션의 상태 확인 엔드포인트에 최종 사용자 인증이 필요하지 않습니다. 엔드포인트를 사용하면 조직의 가용성 설정 요구 사항을 충족하는 상태 확인을 수행할 수 있습니다. (사용자 환경에서는 `nodeJS` 애플리케이션이 실행 중이고 요청을 수신할 수 있는지 확인하는 것으로 충분할 수 있습니다. 다른 경우에는 캐싱 계층 또는 데이터베이스 계층에 대한 연결이 이미 설정되었는지도 확인해야 할 수 있습니다.)
이 자습서의 예제는 데모용으로만 제공되며 프로덕션 환경에 있는 그대로 구현되지 않습니다. 또한 `AWS-RunPatchBaselineWithHooks` 문서와 함께 Systems Manager의 도구인 Patch Manager의 수명 주기 후크 기능은 다양한 다른 시나리오를 지원할 수 있습니다. 다음은 몇 가지 예제입니다.
+ 지표 보고 에이전트를 패치 전에 중지하고 관리형 노드 재부팅 후 다시 시작합니다.
+ 관리형 노드를 패치 전에 CRM 또는 PCS 클러스터에서 분리하고 재부팅한 후 다시 연결합니다.
+ 운영 체제(OS) 업데이트가 적용된 후 관리형 노드가 재부팅되기 전에 Windows Server 시스템에서 서드 파티 소프트웨어(예: Java, Tomcat, Adobe 애플리케이션 등)를 업데이트합니다.
**애플리케이션 종속성 업데이트, 관리형 노드 패치 및 애플리케이션별 상태 확인 수행**
1. 다음 내용으로 사전 설치 스크립트에 대한 SSM 문서를 생성하고 이름을 `NodeJSAppPrePatch`로 지정합니다. *your\$1application*을 애플리케이션 이름으로 바꿉니다.
이 스크립트는 새로운 수신 요청을 즉시 차단하고 패치 작업을 시작하기 전에 이미 활성화된 요청이 완료될 때까지 5초간 기다립니다. `sleep` 옵션에 대해 수신 요청을 완료하는 데 일반적으로 걸리는 시간보다 긴 시간(초)을 지정합니다.
```
# exit on error
set -e
# set up rule to block incoming traffic
iptables -I INPUT -j DROP -p tcp --syn --destination-port 443 || exit 1
# wait for current connections to end. Set timeout appropriate to your application's latency
sleep 5
# Stop your application
pm2 stop your_application
```
SSM 문서 생성에 대한 자세한 내용은 [SSM 문서 콘텐츠 생성](documents-creating-content.md) 섹션을 참조하세요.
1. 설치 후 스크립트에 대해 다음 내용으로 다른 SSM 문서를 생성하여 애플리케이션 종속성을 업데이트하고 이름을 `NodeJSAppPostPatch`로 지정합니다. */your/application/path*를 애플리케이션의 경로로 바꿉니다.
```
cd /your/application/path
npm update
# you can use npm-check-updates if you want to upgrade major versions
```
1. `onExit` 스크립트에 대한 다음 내용으로 다른 SSM 문서를 생성하여 애플리케이션을 다시 불러오고 상태 확인을 수행합니다. 이 SSM 문서의 이름을 `NodeJSAppOnExitPatch`로 지정합니다. *your\$1application*을 애플리케이션 이름으로 바꿉니다.
```
# exit on error
set -e
# restart nodeJs application
pm2 start your_application
# sleep while your application starts and to allow for a crash
sleep 10
# check with pm2 to see if your application is running
pm2 pid your_application
# re-enable incoming connections
iptables -D INPUT -j DROP -p tcp --syn --destination-port
# perform health check
/usr/bin/curl -m 10 -vk -A "" http://localhost:443/health-check || exit 1
```
1. 다음 단계에 따라 AWS Systems Manager의 도구인 State Manager에 연결을 생성하여 작업을 실행합니다.
1. [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)에서 AWS Systems Manager 콘솔을 엽니다.
1. 탐색 창에서 **State Manager**를 선택한 후 **연결 생성**을 선택합니다.
1. [**이름(Name)**]에 연결의 목적을 식별하는 데 도움이 되는 이름을 입력합니다.
1. [**문서(Document)**] 목록에서 `AWS-RunPatchBaselineWithHooks`를 선택합니다.
1. [**작업(Operation)**]에서 [**설치(Install)**]를 선택합니다.
1. (옵션) [**스냅샷 ID(Snapshot Id)**]에 작업 속도를 높이고 일관성을 보장하기 위해 생성하는 GUID를 제공합니다. `00000000-0000-0000-0000-111122223333`과 같이 단순한 GUID 값을 사용할 수 있습니다.
1. [**설치 전 후크 문서 이름(Pre Install Hook Doc Name)**]에 `NodeJSAppPrePatch`를 입력합니다.
1. [**설치 후 후크 문서 이름(Post Install Hook Doc Name)**]에 `NodeJSAppPostPatch`를 입력합니다.
1. [**종료 시 후크 문서 이름(On ExitHook Doc Name)**]에 `NodeJSAppOnExitPatch`를 입력합니다.
1. **대상(Targets)**에서, 태그를 지정하거나, 노드를 수동으로 선택하거나, 리소스 그룹을 선택하거나, 모든 관리형 노드를 선택하여 관리형 노드를 식별할 수 있습니다.
1. [**일정 지정(Specify schedule)**]에서 연결을 실행할 빈도를 지정합니다. 예를 들어 관리형 노드 패치의 경우 일주일에 한 번이 일반적입니다.
1. **속도 제어(Rate control)** 섹션에서 여러 관리형 노드에서 연결을 실행하는 방법을 제어하는 옵션을 선택합니다. 한 번에 관리형 노드의 일부만 업데이트되는지 확인합니다. 그렇지 않으면 전체 또는 대부분의 플릿이 한 번에 오프라인 상태가 될 수 있습니다. 속도 제어 사용에 대한 자세한 내용은 [State Manager 연결에서의 대상 및 속도 제어 이해](systems-manager-state-manager-targets-and-rate-controls.md) 섹션을 참조하세요.
1. (선택 사항) **출력 옵션**에서 명령 출력을 파일에 저장하려면 **S3 버킷에 쓰기 활성화** 옆의 상자를 선택합니다. 상자에 버킷 및 접두사(폴더) 이름을 입력합니다.
**참고**
데이터를 S3 버킷에 쓰는 기능을 부여하는 S3 권한은 이 작업을 수행하는 IAM 사용자의 권한이 아닌 관리형 노드에 할당된 인스턴스 프로파일의 권한입니다. 자세한 내용은 [Systems Manager에 필요한 인스턴스 권한 구성](setup-instance-permissions.md)이나 [하이브리드 환경을 위한 IAM 서비스 역할 생성](hybrid-multicloud-service-role.md)을 참조하세요. 또한 지정된 S3 버킷이 다른 AWS 계정에 있는 경우 관리형 노드와 연결된 인스턴스 프로파일 또는 IAM 서비스 역할은 해당 버킷에 쓸 수 있는 권한이 있어야 합니다.
1. **연결 생성**을 선택합니다.
# 자습서: AWS CLI를 사용한 서버 환경에 패치 적용
다음 절차는 사용자 지정 패치 기준, 패치 그룹 및 유지 관리 기간을 사용하여 서버 환경에 패치를 적용하는 방법에 대해 설명합니다.
**시작하기 전 준비 사항**
+ 관리형 노드에서 SSM Agent 설치 또는 업데이트 Linux 관리형 노드에 패치를 실행하려면 노드가 SSM Agent 버전 2.0.834.0 이상을 실행 중이어야 합니다. 자세한 내용은 [Run Command를 사용하여 SSM Agent 업데이트](run-command-tutorial-update-software.md#rc-console-agentexample) 섹션을 참조하세요.
+ AWS Systems Manager의 도구인 Maintenance Windows에 대한 역할 및 권한을 구성합니다. 자세한 내용은 [Maintenance Windows 설정](setting-up-maintenance-windows.md) 섹션을 참조하세요.
+ 아직 하지 않은 경우 AWS Command Line Interface(AWS CLI)을 설치하고 구성합니다.
자세한 내용은 [최신 버전의 AWS CLI 설치 또는 업데이트](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html)를 참조하세요.
**Patch Manager 및 패치 관리형 노드 구성(명령줄)**
1. 다음 명령을 실행하여 이름이 `Production-Baseline`인 Windows 패치 기준을 생성합니다. 이 패치 기준선은 프로덕션 환경의 패치가 릴리스되거나 마지막으로 업데이트되고 7일 후에 승인합니다. 패치 기준에는 프로덕션 환경용임을 나타내는 태그가 지정되어 있습니다.
**참고**
`OperatingSystem` 파라미터 및 `PatchFilters`는 패치 기준이 적용되는 대상 관리형 노드의 운영 체제에 따라 달라집니다. 자세한 내용은 [OperatingSystem](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-OperatingSystem) 및 [PatchFilter](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html)를 참조하십시오.
------
#### [ Linux & macOS ]
```
aws ssm create-patch-baseline \
--name "Production-Baseline" \
--operating-system "WINDOWS" \
--tags "Key=Environment,Value=Production" \
--approval-rules "PatchRules=[{PatchFilterGroup={PatchFilters=[{Key=MSRC_SEVERITY,Values=[Critical,Important]},{Key=CLASSIFICATION,Values=[SecurityUpdates,Updates,ServicePacks,UpdateRollups,CriticalUpdates]}]},ApproveAfterDays=7}]" \
--description "Baseline containing all updates approved for production systems"
```
------
#### [ Windows Server ]
```
aws ssm create-patch-baseline ^
--name "Production-Baseline" ^
--operating-system "WINDOWS" ^
--tags "Key=Environment,Value=Production" ^
--approval-rules "PatchRules=[{PatchFilterGroup={PatchFilters=[{Key=MSRC_SEVERITY,Values=[Critical,Important]},{Key=CLASSIFICATION,Values=[SecurityUpdates,Updates,ServicePacks,UpdateRollups,CriticalUpdates]}]},ApproveAfterDays=7}]" ^
--description "Baseline containing all updates approved for production systems"
```
------
시스템은 다음과 같은 정보를 반환합니다.
```
{
"BaselineId":"pb-0c10e65780EXAMPLE"
}
```
1. 다음 명령을 실행하여 두 패치 그룹에 대해 "Production-Baseline" 패치 기준을 등록합니다. 그룹의 이름은 "Database Servers" 및 "Front-End Servers"로 지정됩니다.
------
#### [ Linux & macOS ]
```
aws ssm register-patch-baseline-for-patch-group \
--baseline-id pb-0c10e65780EXAMPLE \
--patch-group "Database Servers"
```
------
#### [ Windows Server ]
```
aws ssm register-patch-baseline-for-patch-group ^
--baseline-id pb-0c10e65780EXAMPLE ^
--patch-group "Database Servers"
```
------
시스템은 다음과 같은 정보를 반환합니다.
```
{
"PatchGroup":"Database Servers",
"BaselineId":"pb-0c10e65780EXAMPLE"
}
```
------
#### [ Linux & macOS ]
```
aws ssm register-patch-baseline-for-patch-group \
--baseline-id pb-0c10e65780EXAMPLE \
--patch-group "Front-End Servers"
```
------
#### [ Windows Server ]
```
aws ssm register-patch-baseline-for-patch-group ^
--baseline-id pb-0c10e65780EXAMPLE ^
--patch-group "Front-End Servers"
```
------
시스템은 다음과 같은 정보를 반환합니다.
```
{
"PatchGroup":"Front-End Servers",
"BaselineId":"pb-0c10e65780EXAMPLE"
}
```
1. 다음 명령을 실행하여 프로덕션 서버에 대한 두 개의 유지 관리 기간을 생성합니다. 첫 번째 기간은 매주 화요일 오후 10시에 실행합니다. 두 번째 Window는 매주 토요일 오후 10시에 실행합니다. 또한 유지 관리 기간에는 프로덕션 환경용임을 나타내는 태그가 지정되어 있습니다.
------
#### [ Linux & macOS ]
```
aws ssm create-maintenance-window \
--name "Production-Tuesdays" \
--tags "Key=Environment,Value=Production" \
--schedule "cron(0 0 22 ? * TUE *)" \
--duration 1 \
--cutoff 0 \
--no-allow-unassociated-targets
```
------
#### [ Windows Server ]
```
aws ssm create-maintenance-window ^
--name "Production-Tuesdays" ^
--tags "Key=Environment,Value=Production" ^
--schedule "cron(0 0 22 ? * TUE *)" ^
--duration 1 ^
--cutoff 0 ^
--no-allow-unassociated-targets
```
------
시스템은 다음과 같은 정보를 반환합니다.
```
{
"WindowId":"mw-0c50858d01EXAMPLE"
}
```
------
#### [ Linux & macOS ]
```
aws ssm create-maintenance-window \
--name "Production-Saturdays" \
--tags "Key=Environment,Value=Production" \
--schedule "cron(0 0 22 ? * SAT *)" \
--duration 2 \
--cutoff 0 \
--no-allow-unassociated-targets
```
------
#### [ Windows Server ]
```
aws ssm create-maintenance-window ^
--name "Production-Saturdays" ^
--tags "Key=Environment,Value=Production" ^
--schedule "cron(0 0 22 ? * SAT *)" ^
--duration 2 ^
--cutoff 0 ^
--no-allow-unassociated-targets
```
------
시스템은 다음과 같은 정보를 반환합니다.
```
{
"WindowId":"mw-9a8b7c6d5eEXAMPLE"
}
```
1. 다음 명령을 실행하여 `Database` 및 `Front-End` 서버 패치 그룹을 해당 유지 관리 기간에 등록합니다.
------
#### [ Linux & macOS ]
```
aws ssm register-target-with-maintenance-window \
--window-id mw-0c50858d01EXAMPLE \
--targets "Key=tag:PatchGroup,Values=Database Servers" \
--owner-information "Database Servers" \
--resource-type "INSTANCE"
```
------
#### [ Windows Server ]
```
aws ssm register-target-with-maintenance-window ^
--window-id mw-0c50858d01EXAMPLE ^
--targets "Key=tag:PatchGroup,Values=Database Servers" ^
--owner-information "Database Servers" ^
--resource-type "INSTANCE"
```
------
시스템은 다음과 같은 정보를 반환합니다.
```
{
"WindowTargetId":"e32eecb2-646c-4f4b-8ed1-205fbEXAMPLE"
}
```
------
#### [ Linux & macOS ]
```
aws ssm register-target-with-maintenance-window \
--window-id mw-9a8b7c6d5eEXAMPLE \
--targets "Key=tag:PatchGroup,Values=Front-End Servers" \
--owner-information "Front-End Servers" \
--resource-type "INSTANCE"
```
------
#### [ Windows Server ]
```
aws ssm register-target-with-maintenance-window ^
--window-id mw-9a8b7c6d5eEXAMPLE ^
--targets "Key=tag:PatchGroup,Values=Front-End Servers" ^
--owner-information "Front-End Servers" ^
--resource-type "INSTANCE"
```
------
시스템은 다음과 같은 정보를 반환합니다.
```
{
"WindowTargetId":"faa01c41-1d57-496c-ba77-ff9caEXAMPLE"
}
```
1. 다음 명령을 실행하여 각 유지 관리 기간 동안 `Database` 및 `Front-End` 서버에 누락된 업데이트를 설치하는 패치 작업을 등록합니다.
------
#### [ Linux & macOS ]
```
aws ssm register-task-with-maintenance-window \
--window-id mw-0c50858d01EXAMPLE \
--targets "Key=WindowTargetIds,Values=e32eecb2-646c-4f4b-8ed1-205fbEXAMPLE" \
--task-arn "AWS-RunPatchBaseline" \
--service-role-arn "arn:aws:iam::123456789012:role/MW-Role" \
--task-type "RUN_COMMAND" \
--max-concurrency 2 \
--max-errors 1 \
--priority 1 \
--task-invocation-parameters "RunCommand={Parameters={Operation=Install}}"
```
------
#### [ Windows Server ]
```
aws ssm register-task-with-maintenance-window ^
--window-id mw-0c50858d01EXAMPLE ^
--targets "Key=WindowTargetIds,Values=e32eecb2-646c-4f4b-8ed1-205fbEXAMPLE" ^
--task-arn "AWS-RunPatchBaseline" ^
--service-role-arn "arn:aws:iam::123456789012:role/MW-Role" ^
--task-type "RUN_COMMAND" ^
--max-concurrency 2 ^
--max-errors 1 ^
--priority 1 ^
--task-invocation-parameters "RunCommand={Parameters={Operation=Install}}"
```
------
시스템은 다음과 같은 정보를 반환합니다.
```
{
"WindowTaskId":"4f7ca192-7e9a-40fe-9192-5cb15EXAMPLE"
}
```
------
#### [ Linux & macOS ]
```
aws ssm register-task-with-maintenance-window \
--window-id mw-9a8b7c6d5eEXAMPLE \
--targets "Key=WindowTargetIds,Values=faa01c41-1d57-496c-ba77-ff9caEXAMPLE" \
--task-arn "AWS-RunPatchBaseline" \
--service-role-arn "arn:aws:iam::123456789012:role/MW-Role" \
--task-type "RUN_COMMAND" \
--max-concurrency 2 \
--max-errors 1 \
--priority 1 \
--task-invocation-parameters "RunCommand={Parameters={Operation=Install}}"
```
------
#### [ Windows Server ]
```
aws ssm register-task-with-maintenance-window ^
--window-id mw-9a8b7c6d5eEXAMPLE ^
--targets "Key=WindowTargetIds,Values=faa01c41-1d57-496c-ba77-ff9caEXAMPLE" ^
--task-arn "AWS-RunPatchBaseline" ^
--service-role-arn "arn:aws:iam::123456789012:role/MW-Role" ^
--task-type "RUN_COMMAND" ^
--max-concurrency 2 ^
--max-errors 1 ^
--priority 1 ^
--task-invocation-parameters "RunCommand={Parameters={Operation=Install}}"
```
------
시스템은 다음과 같은 정보를 반환합니다.
```
{
"WindowTaskId":"8a5c4629-31b0-4edd-8aea-33698EXAMPLE"
}
```
1. 다음 명령을 실행하여 패치 그룹에 대한 높은 수준의 패치 규정 준수 요약을 확인합니다. 상위 수준의 패치 규정 준수 요약에는 각 패치 상태의 패치가 있는 관리형 노드 수가 포함됩니다.
**참고**
첫 번째 유지 관리 기간 동안 패치 태스크가 실행될 때까지 요약에는 관리형 노드 수가 0으로 표시됩니다.
------
#### [ Linux & macOS ]
```
aws ssm describe-patch-group-state \
--patch-group "Database Servers"
```
------
#### [ Windows Server ]
```
aws ssm describe-patch-group-state ^
--patch-group "Database Servers"
```
------
시스템은 다음과 같은 정보를 반환합니다.
```
{
"Instances": number,
"InstancesWithFailedPatches": number,
"InstancesWithInstalledOtherPatches": number,
"InstancesWithInstalledPatches": number,
"InstancesWithInstalledPendingRebootPatches": number,
"InstancesWithInstalledRejectedPatches": number,
"InstancesWithMissingPatches": number,
"InstancesWithNotApplicablePatches": number,
"InstancesWithUnreportedNotApplicablePatches": number
}
```
1. 다음 명령을 실행하여 패치 그룹에 대한 관리형 노드별 패치 요약 상태를 확인합니다. 관리형 노드별 요약에는 패치 그룹에 대한 관리형 노드당 각 패치 상태의 여러 패치가 포함됩니다.
------
#### [ Linux & macOS ]
```
aws ssm describe-instance-patch-states-for-patch-group \
--patch-group "Database Servers"
```
------
#### [ Windows Server ]
```
aws ssm describe-instance-patch-states-for-patch-group ^
--patch-group "Database Servers"
```
------
시스템은 다음과 같은 정보를 반환합니다.
```
{
"InstancePatchStates": [
{
"BaselineId": "string",
"FailedCount": number,
"InstalledCount": number,
"InstalledOtherCount": number,
"InstalledPendingRebootCount": number,
"InstalledRejectedCount": number,
"InstallOverrideList": "string",
"InstanceId": "string",
"LastNoRebootInstallOperationTime": number,
"MissingCount": number,
"NotApplicableCount": number,
"Operation": "string",
"OperationEndTime": number,
"OperationStartTime": number,
"OwnerInformation": "string",
"PatchGroup": "string",
"RebootOption": "string",
"SnapshotId": "string",
"UnreportedNotApplicableCount": number
}
]
}
```
Patch Manager 구성 태스크에 사용할 수 있는 다른 AWS CLI 명령의 예를 보려면 [AWS CLI를 사용하여 Patch Manager 리소스 작업](patch-manager-cli-commands.md) 섹션을 참조하세요.