• 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 노드 도구
AWS Systems Manager는 다음과 같은 액세스, 관리 및 *관리형 노드* 구성 도구를 제공합니다. 관리형 노드는 [하이브리드 및 멀티클라우드](operating-systems-and-machine-types.md#supported-machine-types) 환경에서 Systems Manager와 함께 사용하도록 구성된 모든 시스템입니다.
**Topics**
+ [AWS Systems Manager Compliance](systems-manager-compliance.md)
+ [AWS Systems Manager Distributor](distributor.md)
+ [AWS Systems Manager Fleet Manager](fleet-manager.md)
+ [AWS Systems Manager 하이브리드 정품 인증](activations.md)
+ [AWS Systems Manager Inventory](systems-manager-inventory.md)
+ [AWS Systems Manager Patch Manager](patch-manager.md)
+ [AWS Systems Manager Run Command](run-command.md)
+ [AWS Systems Manager Session Manager](session-manager.md)
+ [AWS Systems Manager State Manager](systems-manager-state.md)
# AWS Systems Manager Compliance
AWS Systems Manager의 도구인 Compliance를 사용하여 관리형 노드 플릿에 대해 패치 규정 준수 및 구성 일관성을 스캔할 수 있습니다. 여러 AWS 계정 및 리전의 데이터를 수집하여 집계한 후 규정을 준수하지 않는 특정 리소스로 드릴다운할 수 있습니다. 기본적으로 Compliance는 Patch Manager에 패치에 대한 현재 준수 데이터를 표시하고 State Manager에 연결을 표시합니다. Patch Manager와 State Manager도 모두 AWS Systems Manager의 도구입니다. Compliance를 시작하려면 [Systems Manager 콘솔](https://console.aws.amazon.com//systems-manager/compliance)을 엽니다. 탐색 창에서 **Compliance**를 선택합니다.
Patch Manager에서 패치 규정 준수 데이터를 AWS Security Hub CSPM로 보낼 수 있습니다. Security Hub CSPM에서는 우선순위가 높은 보안 알림 및 규정 준수 상태를 포괄적으로 파악할 수 있습니다. 또한 플릿의 패치 상태를 모니터링합니다. 자세한 내용은 [Patch Manager와 AWS Security Hub CSPM 통합](patch-manager-security-hub-integration.md) 섹션을 참조하세요.
Compliance에는 다음과 같은 추가적인 장점 및 기능이 있습니다.
+ AWS Config를 사용하여 Patch Manager 패치 데이터와 State Manager 연결에 대한 규정 준수 기록 및 변경 사항 추적을 봅니다.
+ IT 또는 비즈니스 요구 사항에 따라 규정 준수를 사용자 지정하여 자체 규정 준수 유형을 만들 수 있습니다.
+ AWS Systems Manager, State Manager 또는 Amazon EventBridge의 또 다른 도구인 Run Command를 사용하여 문제를 해결합니다.
+ Amazon Athena와 Amazon Quick으로 데이터를 포팅하여 플릿 전체의 보고서를 생성합니다.
**EventBridge 지원**
이 Systems Manager 도구는 Amazon EventBridge 규칙에서 *이벤트* 유형으로 지원됩니다. 자세한 내용은 [Amazon EventBridge로 Systems Manager 이벤트 모니터링](monitoring-eventbridge-events.md) 및 [참조: Systems Manager용 Amazon EventBridge 이벤트 패턴 및 유형](reference-eventbridge-events.md) 섹션을 참조하세요.
**Chef InSpec 통합**
Systems Manager는 [https://www.chef.io/inspec/](https://www.chef.io/inspec/)과 통합됩니다. InSpec은 GitHub 또는 Amazon Simple Storage Service(S3)에 육안 판독 프로파일을 생성할 수 있는 오픈 소스 런타임 프레임워크입니다. Systems Manager를 사용하여 규정 준수 스캔을 수행하고 준수 및 비준수 노드를 확인할 수 있습니다. 자세한 내용은 [Systems Manager Compliance와 함께 Chef InSpec 프로파일 사용](integration-chef-inspec.md) 섹션을 참조하세요.
**가격 책정**
Compliance는 추가 비용 없이 제공됩니다. 사용하는 AWS 리소스에 대해서만 비용을 지불하는 것입니다.
**Topics**
+ [Compliance 시작하기](compliance-prerequisites.md)
+ [규정 준수에 대한 권한 구성](compliance-permissions.md)
+ [Compliance의 리소스 데이터 동기화 생성](compliance-datasync-create.md)
+ [규정 준수에 대해 자세히 알아보기](compliance-about.md)
+ [Compliance의 리소스 데이터 동기화 삭제](systems-manager-compliance-delete-RDS.md)
+ [EventBridge를 사용하여 규정 준수 문제 해결](compliance-fixing.md)
+ [AWS CLI를 사용하여 사용자 지정 규정 준수 메타데이터를 할당합니다.](compliance-custom-metadata-cli.md)
# Compliance 시작하기
AWS Systems Manager의 도구인 Compliance를 시작하려면 다음 태스크를 완료합니다.
****
| Task | 자세한 정보 |
| --- | --- |
| Compliance는 Patch Manager의 패치 데이터와 State Manager의 연결을 사용합니다. Patch Manager와 State Manager도 모두 AWS Systems Manager의 도구입니다. Compliance는 Systems Manager를 사용하여 관리형 노드의 사용자 정의 규정 준수 유형도 사용합니다. [하이브리드 및 멀티클라우드](operating-systems-and-machine-types.md#supported-machine-types) 환경의 Amazon Elastic Compute Cloud(Amazon EC2) 인스턴스 및 비 EC2 시스템에 대한 설정 요구 사항을 완료했는지 확인합니다. | [조직을 위한 Systems Manager 통합 콘솔 설정](systems-manager-setting-up-organizations.md) |
| 관리형 노드에서 사용하는 AWS Identity and Access Management(IAM) 역할을 업데이트하여 규정 준수 권한을 제한합니다. | [규정 준수에 대한 권한 구성](compliance-permissions.md) |
| 패치 규정 준수를 모니터링하려는 경우 Patch Manager를 구성했는지 확인합니다. Compliance가 패치 규정 준수 데이터를 표시하려면 Patch Manager를 사용하여 패치 작업을 수행해야 합니다. | [AWS Systems Manager Patch Manager](patch-manager.md) |
| 연결 규정 준수를 모니터링하려는 경우 State Manager 연결을 생성했는지 확인합니다. Compliance가 연결 규정 준수 데이터를 표시하려면 연결을 생성해야 합니다. | [AWS Systems Manager State Manager](systems-manager-state.md) |
| (선택 사항) 규정 준수 이력 및 변경 사항 추적을 보기 위해 시스템을 구성합니다. | [규정 준수 구성 이력 및 변경 사항 추적 보기](compliance-about.md#compliance-history) |
| (선택 사항) 사용자 지정 규정 준수 유형을 만듭니다. | [AWS CLI를 사용하여 사용자 지정 규정 준수 메타데이터를 할당합니다.](compliance-custom-metadata-cli.md) |
| (옵션) 리소스 데이터 동기화를 생성하여 대상 Amazon Simple Storage Service(Amazon S3) 버킷에서 모든 규정 준수 데이터를 집계합니다. | [Compliance의 리소스 데이터 동기화 생성](compliance-datasync-create.md) |
# 규정 준수에 대한 권한 구성
보안 모범 사례로 관리형 노드에서 사용하는 AWS Identity and Access Management(IAM) 역할을 다음 권한으로 업데이트하여 노드의 [PutComplianceItems](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PutComplianceItems.html) API 작업 사용 기능을 제한하는 것이 좋습니다. 이 API 작업은 Amazon EC2 인스턴스 또는 관리형 노드와 같은 지정된 리소스에 규정 준수 유형 및 기타 규정 준수 세부 정보를 등록합니다.
노드가 Amazon EC2 인스턴스인 경우 인스턴스에서 사용하는 IAM 인스턴스 프로파일을 다음 권한으로 업데이트해야 합니다. Systems Manager에서 관리하는 EC2 인스턴스의 인스턴스 프로파일에 대한 자세한 내용은 [Systems Manager에 필요한 인스턴스 권한 구성](setup-instance-permissions.md) 섹션을 참조하세요. 다른 유형의 관리형 노드의 경우 노드에서 사용하는 IAM 역할을 다음 권한으로 업데이트합니다. 자세한 내용은 *IAM 사용 설명서*의 [역할 권한 업데이트](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_update-role-permissions.html)를 참조하세요.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ssm:PutComplianceItems"
],
"Resource": "*",
"Condition": {
"StringEquals": {
"ec2:SourceInstanceARN": "${ec2:SourceInstanceARN}"
}
}
},
{
"Effect": "Allow",
"Action": [
"ssm:PutComplianceItems"
],
"Resource": "*",
"Condition": {
"StringEquals": {
"ssm:SourceInstanceARN": "${ssm:SourceInstanceARN}"
}
}
}
]
}
```
------
# Compliance의 리소스 데이터 동기화 생성
AWS Systems Manager의 리소스 데이터 동기화 기능을 사용하여 모든 관리형 노드의 규정 준수 데이터를 대상 Amazon Simple Storage Service(Amazon S3) 버킷으로 전송할 수 있습니다. 동기화를 생성할 때 여러 AWS 계정, AWS 리전 및 [하이브리드 및 멀티클라우드](operating-systems-and-machine-types.md#supported-machine-types) 환경에서 관리형 노드를 지정할 수 있습니다. 그러면 새로운 규정 준수 데이터가 수집될 때마다 리소스 데이터 동기화가 중앙 데이터를 자동으로 업데이트합니다. 모든 규정 준수 데이터가 대상 S3 버킷에 저장되면 Amazon Athena와 Amazon Quick 같은 서비스를 사용하여 수집한 데이터에 대한 쿼리를 실행하거나 분석할 수 있습니다. Compliance의 리소스 데이터 동기화 구성은 일회성 작업입니다.
Compliance의 리소스 데이터 동기화는 AWS Management Console에서 다음 절차에 따라 생성합니다.
**리소스 데이터 동기화를 위해 S3 버킷 생성 및 구성(콘솔)**
1. [https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/)에서 Amazon S3 콘솔을 엽니다.
1. 집계된 규정 준수 데이터를 저장할 버킷을 생성합니다. 자세한 내용은 *Amazon Simple Storage Service 사용 설명서*의 [버킷 생성](https://docs.aws.amazon.com/AmazonS3/latest/userguide/CreatingABucket.html)을 참조하세요. 버킷 이름과 버킷을 생성한 AWS 리전을 따로 적어둡니다.
1. 버킷을 열고 **권한** 탭과 **버킷 정책**을 차례로 선택합니다.
1. 다음 버킷 정책을 복사하여 정책 편집기에 붙여 넣습니다. 이때 amzn-s3-demo-bucket 및 *Account-ID*를 사용자가 생성한 S3 버킷 이름 및 유효한 AWS 계정 ID로 바꿉니다. 원할 경우 *Bucket-Prefix*를 Amazon S3 접두사(하위 디렉터리) 이름으로 바꿉니다. 접두사를 생성하지 않았다면 정책의 ARN에서 *Bucket-Prefix*/를 제거하세요.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "SSMBucketPermissionsCheck",
"Effect": "Allow",
"Principal": {
"Service": "ssm.amazonaws.com"
},
"Action": "s3:GetBucketAcl",
"Resource": "arn:aws:s3:::amzn-s3-demo-bucket"
},
{
"Sid": " SSMBucketDelivery",
"Effect": "Allow",
"Principal": {
"Service": "ssm.amazonaws.com"
},
"Action": "s3:PutObject",
"Resource": ["arn:aws:s3:::amzn-s3-demo-bucket/Bucket-Prefix/*/accountid=111122223333/*"],
"Condition": {
"StringEquals": {
"s3:x-amz-acl": "bucket-owner-full-control"
}
}
}
]
}
```
------
**리소스 데이터 동기화 생성**
1. [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)에서 AWS Systems Manager 콘솔을 엽니다.
1. 탐색 창에서 **Fleet Manager**를 선택합니다.
1. [**계정 관리(Account management)**], [**리소스 데이터 동기화(Resource Data Syncs)**]를 선택한 다음 [**리소스 데이터 동기화 생성(Create resource data sync)**]을 선택합니다.
1. [**동기화 이름(Sync name)**] 필드에 동기화 구성 이름을 입력합니다.
1. [**버킷 이름(Bucket name)**] 필드에 절차를 시작할 때 생성한 Amazon S3 버킷 이름을 입력합니다.
1. (옵션) **버킷 접두사(Bucket prefix)** 필드에 S3 버킷 접두사(하위 디렉터리)의 이름을 입력합니다.
1. 생성한 S3 버킷이 현재 AWS 리전에 위치하면 **버킷 리전** 필드에서 **이 리전**을 선택합니다. 버킷이 다른 AWS 리전에 위치하면 [**다른 리전(Another region)**]을 선택하고 리전 이름을 입력합니다.
**참고**
동기화와 대상 S3 버킷이 서로 다른 리전에 위치하는 경우에는 데이터 전송 요금이 부과될 수 있습니다. 자세한 내용은 [Amazon S3 요금](https://aws.amazon.com/s3/pricing/)을 참조하세요.
1. **생성(Create)**을 선택합니다.
# 규정 준수에 대해 자세히 알아보기
AWS Systems Manager의 도구인 Compliance는 Patch Manager 패치의 패치 상태와 State Manager의 연결에 대한 데이터를 수집하고 보고합니다. Patch Manager와 State Manager도 모두 AWS Systems Manager의 도구입니다. 또한 Compliance는 관리형 노드에 대해 지정한 사용자 정의 규정 준수 유형에 대해 보고합니다. 이 섹션에는 이러한 규정 준수 유형 각각에 대한 세부 정보와 Systems Manager 규정 준수 데이터를 보는 방법이 나와 있습니다. 또한 규정 준수 이력과 변경 사항 추적을 확인하는 방법에 정보도 다룹니다.
**참고**
Systems Manager는 [https://www.chef.io/inspec/](https://www.chef.io/inspec/)과 통합됩니다. InSpec은 GitHub 또는 Amazon Simple Storage Service(S3)에 육안 판독 프로파일을 생성할 수 있는 오픈 소스 런타임 프레임워크입니다. Systems Manager를 사용하여 규정 준수 검사를 수행하고 준수 및 비준수 인스턴스를 확인할 수 있습니다. 자세한 내용은 [Systems Manager Compliance와 함께 Chef InSpec 프로파일 사용](integration-chef-inspec.md) 섹션을 참조하세요.
## 패치 규정 준수 정보
Patch Manager를 사용하여 인스턴스에 패치를 설치하고 나면 콘솔 또는 AWS Command Line Interface(AWS CLI) 명령에 대한 응답이나 해당하는 Systems Manager API 작업을 통해 규정 준수 상태에 대한 정보를 즉시 볼 수 있습니다.
패치 규정 준수 상태 값에 대한 자세한 내용은 [패치 규정 준수 상태 값](patch-manager-compliance-states.md) 섹션을 참조하세요.
## State Manager 연결 규정 준수 정보
State Manager 연결을 하나 이상 생성하고 나면 콘솔 또는 AWS CLI 명령에 대한 응답이나 해당하는 Systems Manager API 작업을 통해 규정 준수 상태에 대한 정보를 즉시 볼 수 있습니다. 연결의 경우 Compliance는 `Compliant` 또는 `Non-compliant`의 상태와 연결에 할당된 심각도(예: `Critical` 또는 `Medium`)를 보여줍니다.
State Manager가 관리형 노드에서 연결을 실행하면 해당 노드의 모든 연결에 대한 규정 준수 상태를 업데이트하는 규정 준수 집계 프로세스가 트리거됩니다. 규정 준수 보고서의 `ExecutionTime` 값은 관리형 노드에서 연결이 실행된 시점이 아니라 Systems Manager가 규정 준수 상태를 캡처한 시점을 나타냅니다. 즉, 서로 다른 시점에 실행된 경우에도 여러 연결에 동일한 `ExecutionTime` 값이 표시될 수 있습니다. 실제 연결 실행 시간을 확인하려면 AWS CLI 명령 [https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-association-execution-targets.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-association-execution-targets.html)를 사용하여 연결 실행 기록을 참조하거나 콘솔에서 실행 세부 정보를 확인하세요.
## 사용자 지정 규정 준수 정보
관리형 노드에 규정 준수 메타데이터를 할당할 수 있습니다. 그러면 이 메타데이터를 규정 준수 보고를 위해 다른 규정 준수 데이터와 함께 집계할 수 있습니다. 예를 들어 여러분의 회사가 관리형 노드에서 소프트웨어 X의 버전 2.0, 3.0, 4.0을 실행한다고 가정하겠습니다. 이 회사는 버전 2.0과 3.0을 실행하는 인스턴스가 규정을 미준수하여 버전 4.0으로 표준화하려고 합니다. [PutComplianceItems](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PutComplianceItems.html) API 작업을 사용하여 소프트웨어 X의 이전 버전을 실행하는 관리형 노드를 명시적으로 기록할 수 있습니다. AWS CLI, AWS Tools for Windows PowerShell 또는 SDK를 사용하여 규정 준수 메타데이터만 할당할 수 있습니다. 다음 CLI 명령 샘플은 관리형 인스턴스에 규정 준수 메타데이터를 할당하고, 필요한 형식 `Custom:`으로 규정 준수 유형을 지정합니다. 각 *example resource placeholder*를 사용자의 정보로 바꿉니다.
------
#### [ Linux & macOS ]
```
aws ssm put-compliance-items \
--resource-id i-1234567890abcdef0 \
--resource-type ManagedInstance \
--compliance-type Custom:SoftwareXCheck \
--execution-summary ExecutionTime=AnyStringToDenoteTimeOrDate \
--items Id=Version2.0,Title=SoftwareXVersion,Severity=CRITICAL,Status=NON_COMPLIANT
```
------
#### [ Windows ]
```
aws ssm put-compliance-items ^
--resource-id i-1234567890abcdef0 ^
--resource-type ManagedInstance ^
--compliance-type Custom:SoftwareXCheck ^
--execution-summary ExecutionTime=AnyStringToDenoteTimeOrDate ^
--items Id=Version2.0,Title=SoftwareXVersion,Severity=CRITICAL,Status=NON_COMPLIANT
```
------
**참고**
`ResourceType` 파라미터는 `ManagedInstance`만 지원합니다. 관리형 AWS IoT Greengrass 코어 디바이스에 사용자 지정 규정 준수를 추가하는 경우 `ManagedInstance`의 `ResourceType`를 식별해야 합니다.
그러면 규정 준수 관리자는 요약을 보거나 규정 준수 또는 미준수 관리형 노드에 대한 보고서를 만들 수 있습니다. 관리형 노드 하나에 최대 10개의 사용자 지정 규정 준수 유형을 할당할 수 있습니다.
사용자 지정 규정 준수 유형을 만들고 규정 준수 데이터를 보는 방법의 예는 [AWS CLI를 사용하여 사용자 지정 규정 준수 메타데이터를 할당합니다.](compliance-custom-metadata-cli.md)을 참조하십시오.
## 현재의 규정 준수 데이터 보기
이 섹션에서는 AWS CLI를 사용하거나 Systems Manager 콘솔에서 규정 준수 데이터를 보는 방법을 설명합니다. 패치 및 연결의 규정 준수 이력과 변경 사항 추적을 확인하는 방법은 [규정 준수 구성 이력 및 변경 사항 추적 보기](#compliance-history) 섹션을 참조하세요.
**Topics**
+ [현재의 규정 준수 데이터 보기(콘솔)](#compliance-view-results-console)
+ [현재의 규정 준수 데이터 보기(AWS CLI)](#compliance-view-data-cli)
### 현재의 규정 준수 데이터 보기(콘솔)
Systems Manager 콘솔에서 규정 준수 데이터를 보려면 다음 절차를 따릅니다.
**Systems Manager 콘솔에서 현재의 규정 준수 보고서를 보려면**
1. [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)에서 AWS Systems Manager 콘솔을 엽니다.
1. 탐색 창에서 **Compliance**를 선택합니다.
1. **규정 준수 대시보드 필터링** 섹션에서 규정 준수 데이터를 필터링하는 옵션을 선택합니다. **규정 준수 리소스 요약** 섹션에는 선택한 필터를 기반으로 규정 준수 데이터 개수가 표시됩니다.
1. 자세한 내용을 보기 위해 리소스로 드릴다운하려면 아래로 스크롤해 **리소스에 대한 세부 정보 개요** 영역을 선택하고 관리형 노드의 ID를 선택합니다.
1. **인스턴스 ID** 또는 **이름(Name)** 세부 정보 페이지에서 **구성 규정 준수(Configuration compliance)** 탭을 선택하여 관리형 노드에 대한 자세한 구성 규정 준수 보고서를 확인합니다.
**참고**
규정 준수 문제 수정에 대한 자세한 내용은 [EventBridge를 사용하여 규정 준수 문제 해결](compliance-fixing.md)을 참조하십시오.
### 현재의 규정 준수 데이터 보기(AWS CLI)
AWS CLI에서 다음 AWS CLI 명령을 사용하여 패치 적용, 연결, 사용자 지정 규정 준수 유형에 대한 규정 준수 데이터의 요약을 볼 수 있습니다.
[https://docs.aws.amazon.com/cli/latest/reference/ssm/list-compliance-summaries.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/list-compliance-summaries.html)
지정한 필터에 따라 규정 준수 및 규정 미준수 연결 상태의 요약 개수를 반환합니다. (API: [ListComplianceSummaries](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_ListComplianceSummaries.html))
[https://docs.aws.amazon.com/cli/latest/reference/ssm/list-resource-compliance-summaries.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/list-resource-compliance-summaries.html)
리소스 수준 요약 개수를 반환합니다. 요약에는 지정한 필터 조건에 따라 규정 준수 및 규정 미준수 상태와 세부적인 규정 준수 항목 심각도 개수에 대한 정보가 포함되어 있습니다. (API: [ListResourceComplianceSummaries](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_ListResourceComplianceSummaries.html))
다음 AWS CLI 명령을 사용하여 패치 적용에 대한 그 밖의 규정 준수 데이터를 볼 수 있습니다.
[https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-patch-group-state.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-patch-group-state.html)
패치 그룹에 대한 높은 수준의 집계된 패치 규정 준수 상태를 반환합니다. (API: [DescribePatchGroupState](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_DescribePatchGroupState.html))
[https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-instance-patch-states-for-patch-group.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-instance-patch-states-for-patch-group.html)
지정된 패치 그룹의 인스턴스에 대한 높은 수준의 패치 상태를 반환합니다. (API: [DescribeInstancePatchStatesForPatchGroup](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_DescribeInstancePatchStatesForPatchGroup.html))
**참고**
AWS CLI를 사용하여 패치를 구성하고 패치 규정 준수 세부 정보를 보는 방법은 [자습서: AWS CLI를 사용한 서버 환경에 패치 적용](patch-manager-patch-servers-using-the-aws-cli.md) 섹션을 참조하세요.
## 규정 준수 구성 이력 및 변경 사항 추적 보기
Systems Manager Compliance는 관리형 노드에 대한 *현재* 패치 및 연결의 규정 준수 데이터를 표시합니다. [AWS Config](https://docs.aws.amazon.com/config/latest/developerguide/)를 사용하여 패치와 연결의 규정 준수 기록 및 변경 사항 추적을 확인할 수 있습니다. AWS Config는 AWS 계정에 있는 AWS 리소스의 구성을 자세히 보여줍니다. 이러한 보기에는 리소스 간에 어떤 관계가 있는지와 리소스가 과거에 어떻게 구성되었는지도 포함되므로, 시간이 지나면서 구성과 관계가 어떻게 변하는지 확인할 수 있습니다. 패치 및 연결의 규정 준수 이력과 변경 사항 추적을 확인하려면 AWS Config에서 다음 리소스를 설정해야 합니다.
+ `SSM:PatchCompliance`
+ `SSM:AssociationCompliance`
AWS Config에서 이러한 특정 리소스를 선택하고 구성하는 방법에 대한 자세한 내용은 *AWS Config Developer Guide*의 [Selecting Which Resources AWS Config Records](https://docs.aws.amazon.com/config/latest/developerguide/select-resources.html)를 참조하세요.
**참고**
AWS Config 요금에 대한 자세한 내용은 [요금](https://aws.amazon.com/config/pricing/)을 참조하세요.
# Compliance의 리소스 데이터 동기화 삭제
더 이상 AWS Systems Manager Compliance를 사용하여 규정 준수 데이터를 보고 싶지 않은 경우, Compliance 데이터 수집에 사용되는 리소스 데이터 동기화를 삭제하는 것이 좋습니다.
**Compliance 리소스 데이터 동기화를 삭제하려면**
1. [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)에서 AWS Systems Manager 콘솔을 엽니다.
1. 탐색 창에서 **Fleet Manager**를 선택합니다.
1. **계정 관리(Account management)**에서 **리소스 데이터 동기화(Resource data sync)**를 선택합니다.
1. 목록에서 동기화를 선택합니다.
**중요**
Compliance에 사용되는 동기화를 선택해야 합니다. Systems Manager는 여러 도구에 대한 리소스 데이터 동기화를 지원합니다. 잘못된 동기화를 선택하면 Systems Manager Explorer 또는 Systems Manager Inventory의 데이터 집계가 중단될 수 있습니다.
1. **삭제**를 선택합니다.
1. 데이터가 저장된 Amazon Simple Storage Service(Amazon S3) 버킷을 삭제합니다. S3 버킷 삭제에 대한 자세한 내용은 [버킷 삭제](https://docs.aws.amazon.com/AmazonS3/latest/userguide/delete-bucket.html)를 참조하세요.
# EventBridge를 사용하여 규정 준수 문제 해결
AWS Systems Manager의 도구인 Run Command를 사용하여 패치 및 연결 규정 준수 문제를 신속하게 해결할 수 있습니다. 인스턴스 또는 AWS IoT Greengrass 코어 디바이스 ID 또는 태그를 타겟팅할 수 있고 `AWS-RunPatchBaseline` 문서 또는 `AWS-RefreshAssociation` 문서를 실행할 수 있습니다. 연결을 새로 고치거나 패치 기준을 다시 실행해도 규정 준수 문제가 해결되지 않으면 연결, 패치 기준 또는 인스턴스 구성을 조사하여 Run Command 작업이 문제를 해결하지 못한 이유를 파악해야 합니다.
패치에 대한 자세한 내용은 [AWS Systems Manager Patch Manager](patch-manager.md) 및 [패치를 위한 SSM 명령 문서: `AWS-RunPatchBaseline`](patch-manager-aws-runpatchbaseline.md) 섹션을 참조하세요.
연결에 대한 자세한 내용은 [Systems Manager에서 연결 작업](state-manager-associations.md) 섹션을 참조하세요.
명령 실행에 대한 자세한 내용은 [AWS Systems Manager Run Command](run-command.md)을 참조하십시오.
**Compliance를 EventBridge 이벤트 대상으로 지정**
Systems Manager Compliance 이벤트에 대한 응답으로 작업을 수행하도록 Amazon EventBridge를 구성할 수도 있습니다. 예를 들어 하나 이상의 관리형 노드가 중요한 패치 업데이트를 설치하지 못했거나 바이러스 백신 소프트웨어를 설치하는 연결을 실행하지 못한 경우 Compliance 이벤트가 발생할 때 `AWS-RunPatchBaseline` 문서 또는 `AWS-RefreshAssocation` 문서를 실행하도록 EventBridge를 구성할 수 있습니다.
다음 절차에 따라 Compliance를 EventBridge 이벤트 대상으로 구성합니다.
**Compliance를 EventBridge 이벤트 대상으로 구성하려면(콘솔)**
1. [https://console.aws.amazon.com/events/](https://console.aws.amazon.com/events/)에서 Amazon EventBridge 콘솔을 엽니다.
1. 탐색 창에서 **규칙**을 선택합니다.
1. **규칙 생성**을 선택합니다.
1. 규칙에 대해 이름과 설명을 입력하세요.
규칙은 동일한 AWS 리전과 동일한 이벤트 버스의 다른 규칙과 동일한 이름을 가질 수 없습니다.
1. **이벤트 버스**에서 이 규칙과 연결할 이벤트 버스를 선택합니다. 이 규칙이 자신의 AWS 계정에서 오는 일치하는 이벤트에 응답하도록 하려면 **default**(기본)를 선택합니다. 계정의 AWS 서비스이(가) 이벤트를 출력하면 항상 계정의 기본 이벤트 버스로 이동합니다.
1. **규칙 유형**에서 **이벤트 패턴이 있는 규칙**을 선택합니다.
1. **Next**(다음)를 선택합니다.
1. **이벤트 소스(Event source)**에서 **AWS 이벤트 또는 EventBridge 파트너 이벤트(Events or EventBridge partner events)**를 선택합니다.
1. **이벤트 패턴(Event pattern)**섹션에서 **이벤트 패턴 양식(Event pattern form)**을 선택합니다.
1. **이벤트 소스**에서 **AWS 서비스**를 선택합니다.
1. **AWS service**(서비스)에서 **Systems Manager**를 선택합니다.
1. [**이벤트 유형(Event type)**] 필드에서 [**Configuration Compliance**]를 선택합니다.
1. **Specific detail type(s)**(특정 상세 유형)에서 **Configuration Compliance State Change**(구성 준수 상태 변경)을 선택합니다.
1. **Next**(다음)를 선택합니다.
1. **대상 유형**에서 **AWS서비스**를 선택합니다.
1. **Select a target**(대상 선택)에서 **Systems Manager Run Command**을(를) 선택합니다.
1. [**문서(Document)**] 목록에서 대상이 호출될 때 실행할 Systems Manager 문서(SSM 문서)를 선택합니다. 예를 들어 규정 미준수 패치 이벤트의 경우 `AWS-RunPatchBaseline`을 선택하고, 규정 미준수 연결 이벤트의 경우 `AWS-RefreshAssociation`을 선택합니다.
1. 나머지 필드 및 파라미터의 정보를 지정합니다.
**참고**
필수 필드 및 파라미터는 이름 옆에 별표(\$1)가 있습니다. 대상을 생성하려면 각 필수 파라미터 또는 필드의 값을 지정해야 합니다. 그렇지 않으면 시스템에서 규칙이 생성되지만 실행되지 않습니다.
1. **Next**(다음)를 선택합니다.
1. (선택 사항)규칙에 대해 하나 이상의 태그를 입력하세요. 자세한 내용은 *Amazon EventBridge User Guide*의 [Tagging Your Amazon EventBridge Resources](https://docs.aws.amazon.com/eventbridge/latest/userguide/eventbridge-tagging.html)를 참조하세요.
1. **Next**(다음)를 선택합니다.
1. 규칙의 세부 정보를 검토하고 **규칙 생성**을 선택합니다.
# AWS CLI를 사용하여 사용자 지정 규정 준수 메타데이터를 할당합니다.
다음 절차에서는 AWS Command Line Interface(AWS CLI)를 통해 AWS Systems Manager [PutComplianceItems](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PutComplianceItems.html) API 작업을 호출하여 리소스에 사용자 정의 규정 준수 메타데이터를 할당하는 과정을 안내합니다. 다음 시연에서처럼 이 API 작업을 사용하여 관리형 노드에 패치 또는 연결 규정 준수 메타데이터를 수동으로 할당할 수도 있습니다. 사용자 정의 규정 준수에 대한 자세한 내용은 [사용자 지정 규정 준수 정보](compliance-about.md#compliance-custom)를 참조하십시오.
**관리형 인스턴스에 사용자 정의 규정 준수 메타데이터를 할당하려면(AWS CLI)**
1. 아직 하지 않은 경우 AWS Command Line Interface(AWS CLI)을 설치하고 구성합니다.
자세한 내용은 [최신 버전의 AWS CLI 설치 또는 업데이트](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html)를 참조하세요.
1. 다음 명령을 실행하여 사용자 지정 규정 준수 메타데이터를 관리형 노드에 할당합니다. 각 *example resource placeholder*를 사용자의 정보로 바꿉니다. `ResourceType` 파라미터는 `ManagedInstance`의 값만 지원합니다. 관리형 AWS IoT Greengrass 코어 디바이스에 사용자 정의 규정 준수 메타데이터를 할당하더라도 이 값을 지정합니다.
------
#### [ Linux & macOS ]
```
aws ssm put-compliance-items \
--resource-id instance_ID \
--resource-type ManagedInstance \
--compliance-type Custom:user-defined_string \
--execution-summary ExecutionTime=user-defined_time_and/or_date_value \
--items Id=user-defined_ID,Title=user-defined_title,Severity=one_or_more_comma-separated_severities:CRITICAL, MAJOR, MINOR,INFORMATIONAL, or UNSPECIFIED,Status=COMPLIANT or NON_COMPLIANT
```
------
#### [ Windows ]
```
aws ssm put-compliance-items ^
--resource-id instance_ID ^
--resource-type ManagedInstance ^
--compliance-type Custom:user-defined_string ^
--execution-summary ExecutionTime=user-defined_time_and/or_date_value ^
--items Id=user-defined_ID,Title=user-defined_title,Severity=one_or_more_comma-separated_severities:CRITICAL, MAJOR, MINOR,INFORMATIONAL, or UNSPECIFIED,Status=COMPLIANT or NON_COMPLIANT
```
------
1. 이전 단계를 반복하여 하나 이상의 노드에 사용자 지정 규정 준수 메타데이터를 추가로 할당합니다. 다음 명령을 사용하여 관리형 노드에 패치 또는 연결 규정 준수 메타데이터를 수동으로 할당할 수도 있습니다.
연결 규정 준수 메타데이터
------
#### [ Linux & macOS ]
```
aws ssm put-compliance-items \
--resource-id instance_ID \
--resource-type ManagedInstance \
--compliance-type Association \
--execution-summary ExecutionTime=user-defined_time_and/or_date_value \
--items Id=user-defined_ID,Title=user-defined_title,Severity=one_or_more_comma-separated_severities:CRITICAL, MAJOR, MINOR,INFORMATIONAL, or UNSPECIFIED,Status=COMPLIANT or NON_COMPLIANT
```
------
#### [ Windows ]
```
aws ssm put-compliance-items ^
--resource-id instance_ID ^
--resource-type ManagedInstance ^
--compliance-type Association ^
--execution-summary ExecutionTime=user-defined_time_and/or_date_value ^
--items Id=user-defined_ID,Title=user-defined_title,Severity=one_or_more_comma-separated_severities:CRITICAL, MAJOR, MINOR,INFORMATIONAL, or UNSPECIFIED,Status=COMPLIANT or NON_COMPLIANT
```
------
패치 규정 준수 메타데이터
------
#### [ Linux & macOS ]
```
aws ssm put-compliance-items \
--resource-id instance_ID \
--resource-type ManagedInstance \
--compliance-type Patch \
--execution-summary ExecutionTime=user-defined_time_and/or_date_value,ExecutionId=user-defined_ID,ExecutionType=Command \
--items Id=for_example, KB12345,Title=user-defined_title,Severity=one_or_more_comma-separated_severities:CRITICAL, MAJOR, MINOR,INFORMATIONAL, or UNSPECIFIED,Status=COMPLIANT or NON_COMPLIANT,Details="{PatchGroup=name_of_group,PatchSeverity=the_patch_severity, for example, CRITICAL}"
```
------
#### [ Windows ]
```
aws ssm put-compliance-items ^
--resource-id instance_ID ^
--resource-type ManagedInstance ^
--compliance-type Patch ^
--execution-summary ExecutionTime=user-defined_time_and/or_date_value,ExecutionId=user-defined_ID,ExecutionType=Command ^
--items Id=for_example, KB12345,Title=user-defined_title,Severity=one_or_more_comma-separated_severities:CRITICAL, MAJOR, MINOR,INFORMATIONAL, or UNSPECIFIED,Status=COMPLIANT or NON_COMPLIANT,Details="{PatchGroup=name_of_group,PatchSeverity=the_patch_severity, for example, CRITICAL}"
```
------
1. 다음 명령을 실행하여 특정 관리형 노드의 규정 준수 항목 목록을 봅니다. 필터를 사용하여 특정 규정 준수 데이터로 드릴다운합니다.
------
#### [ Linux & macOS ]
```
aws ssm list-compliance-items \
--resource-ids instance_ID \
--resource-types ManagedInstance \
--filters one_or_more_filters
```
------
#### [ Windows ]
```
aws ssm list-compliance-items ^
--resource-ids instance_ID ^
--resource-types ManagedInstance ^
--filters one_or_more_filters
```
------
다음 예제에서는 필터와 함께 이 명령을 사용하는 방법을 보여 줍니다.
------
#### [ Linux & macOS ]
```
aws ssm list-compliance-items \
--resource-ids i-02573cafcfEXAMPLE \
--resource-type ManagedInstance \
--filters Key=DocumentName,Values=AWS-RunPowerShellScript Key=Status,Values=NON_COMPLIANT,Type=NotEqual Key=Id,Values=cee20ae7-6388-488e-8be1-a88ccEXAMPLE Key=Severity,Values=UNSPECIFIED
```
------
#### [ Windows ]
```
aws ssm list-compliance-items ^
--resource-ids i-02573cafcfEXAMPLE ^
--resource-type ManagedInstance ^
--filters Key=DocumentName,Values=AWS-RunPowerShellScript Key=Status,Values=NON_COMPLIANT,Type=NotEqual Key=Id,Values=cee20ae7-6388-488e-8be1-a88ccEXAMPLE Key=Severity,Values=UNSPECIFIED
```
------
------
#### [ Linux & macOS ]
```
aws ssm list-resource-compliance-summaries \
--filters Key=OverallSeverity,Values=UNSPECIFIED
```
------
#### [ Windows ]
```
aws ssm list-resource-compliance-summaries ^
--filters Key=OverallSeverity,Values=UNSPECIFIED
```
------
------
#### [ Linux & macOS ]
```
aws ssm list-resource-compliance-summaries \
--filters Key=OverallSeverity,Values=UNSPECIFIED Key=ComplianceType,Values=Association Key=InstanceId,Values=i-02573cafcfEXAMPLE
```
------
#### [ Windows ]
```
aws ssm list-resource-compliance-summaries ^
--filters Key=OverallSeverity,Values=UNSPECIFIED Key=ComplianceType,Values=Association Key=InstanceId,Values=i-02573cafcfEXAMPLE
```
------
1. 다음 명령을 실행하여 규정 준수 상태 요약을 봅니다. 필터를 사용하여 특정 규정 준수 데이터로 드릴다운합니다.
```
aws ssm list-resource-compliance-summaries --filters One or more filters.
```
다음 예제에서는 필터와 함께 이 명령을 사용하는 방법을 보여 줍니다.
------
#### [ Linux & macOS ]
```
aws ssm list-resource-compliance-summaries \
--filters Key=ExecutionType,Values=Command
```
------
#### [ Windows ]
```
aws ssm list-resource-compliance-summaries ^
--filters Key=ExecutionType,Values=Command
```
------
------
#### [ Linux & macOS ]
```
aws ssm list-resource-compliance-summaries \
--filters Key=AWS:InstanceInformation.PlatformType,Values=Windows Key=OverallSeverity,Values=CRITICAL
```
------
#### [ Windows ]
```
aws ssm list-resource-compliance-summaries ^
--filters Key=AWS:InstanceInformation.PlatformType,Values=Windows Key=OverallSeverity,Values=CRITICAL
```
------
1. 다음 명령을 실행하여 규정 준수 유형에 대한 규정 준수 및 규정 미준수 리소스의 요약 개수를 봅니다. 필터를 사용하여 특정 규정 준수 데이터로 드릴다운합니다.
```
aws ssm list-compliance-summaries --filters One or more filters.
```
다음 예제에서는 필터와 함께 이 명령을 사용하는 방법을 보여 줍니다.
------
#### [ Linux & macOS ]
```
aws ssm list-compliance-summaries \
--filters Key=AWS:InstanceInformation.PlatformType,Values=Windows Key=PatchGroup,Values=TestGroup
```
------
#### [ Windows ]
```
aws ssm list-compliance-summaries ^
--filters Key=AWS:InstanceInformation.PlatformType,Values=Windows Key=PatchGroup,Values=TestGroup
```
------
------
#### [ Linux & macOS ]
```
aws ssm list-compliance-summaries \
--filters Key=AWS:InstanceInformation.PlatformType,Values=Windows Key=ExecutionId,Values=4adf0526-6aed-4694-97a5-14522EXAMPLE
```
------
#### [ Windows ]
```
aws ssm list-compliance-summaries ^
--filters Key=AWS:InstanceInformation.PlatformType,Values=Windows Key=ExecutionId,Values=4adf0526-6aed-4694-97a5-14522EXAMPLE
```
------
# AWS Systems Manager Distributor
Distributor의 도구인 AWS Systems Manager를 사용하면 AWS Systems Manager 관리형 노드에 소프트웨어를 패키징하고 게시할 수 있습니다. 자체 소프트웨어를 패키징하고 게시하거나 Distributor을 사용해 AWS 제공 에이전트 소프트웨어 패키지를 찾거나 게시할 수 있습니다(예: **AmazonCloudWatchAgent** 또는 **Trend Micro**와 같은 서드 파티 패키지). 패키지 게시는 패키지 문서의 특정한 버전을 노드 ID, AWS 계정 ID, 태그, 또는 AWS 리전를 사용해 인식하는 관리형 노드에 보급합니다. Distributor를 시작하려면 [Systems Manager 콘솔](https://console.aws.amazon.com//systems-manager/distributor)을 엽니다. 탐색 창에서 **Distributor**를 선택합니다.
Distributor에서 패키지를 생성하면, 다음 중 한 가지 방법으로 해당 패키지를 설치할 수 있습니다.
+ [AWS Systems Manager Run Command](run-command.md)를 사용하여 한 번만
+ [AWS Systems Manager State Manager](systems-manager-state.md)를 사용하여 일정에 따라
**중요**
타사 판매자가 배포한 패키지는 AWS가 관리하지 않으며 패키지 공급업체가 게시합니다. 내부 보안 통제를 준수하기 위해 추가 실사를 수행하는 것이 좋습니다. 보안은 AWS와 사용자의 공동 책임입니다. 이것을 공동 책임 모델이라고 합니다. 자세한 내용은 [공동 책임 모델](https://aws.amazon.com/compliance/shared-responsibility-model/)을 참조하세요.
## Distributor가 조직에 주는 이점은 무엇인가요?
Distributor에서 제공하는 이점은 다음과 같습니다.
+ **한 패키지에 여러 플랫폼**
Distributor에서 패키지를 생성할 때, 시스템은 AWS Systems Manager 문서(SSM 문서)를 생성합니다. 이 문서에.zip 파일을 첨부할 수 있습니다. Distributor를 실행할 때, 시스템은 SSM 문서의 지침을 처리하고 지정된 대상의.zip 파일에 소프트웨어 패키지를 설치합니다. Distributor는 Windows, Ubuntu Server, Debian Server 및 Red Hat Enterprise Linux 등 여러 운영 체제를 지원합니다. 지원되는 플랫폼에 대한 자세한 내용은 [지원되는 패키지 플랫폼 및 아키텍처](#what-is-a-package-platforms) 섹션을 참조하세요.
+ **관리형 인스턴스 그룹 간에 패키지 액세스 제어**
Run Command 또는 State Manager를 사용해 패키지를 얻을 관리형 노드와 해당 패키지의 버전을 제어할 수 있습니다. Run Command와 State Manager는 AWS Systems Manager의 도구입니다. 관리형 노드는 인스턴스, 장치 ID, AWS 계정 번호, 태그 또는 AWS 리전별로 그룹화할 수 있습니다. State Manager 연결을 사용해 패키지의 여러 버전을 여러 인스턴스 그룹으로 전달할 수 있습니다.
+ **포함되어 바로 사용 가능한 많은 AWS 에이전트**
Distributor에는 관리형 노드에 바로 배포할 수 있는 AWS 에이전트 패키지가 많이 포함되어 있습니다. Distributor `Packages` 목록 페이지에서 `Amazon`이 발행한 패키지를 찾습니다. 예를 들면 `AmazonCloudWatchAgent`나 `AWSPVDriver`와 같습니다.
+ **배포 자동화**
환경을 최신 상태로 유지하려면 State Manager를 사용하여 노드를 처음 시작할 때 대상 관리형 노드에 자동으로 배포하도록 패키지를 예약합니다.
## Distributor는 누가 사용해야 하나요?
+ 새로 생성한 소프트웨어 패키지 또는 기존 소프트웨어 패키지(AWS에서 게시한 패키지 포함)를 여러 Systems Manager 관리형 노드에 한 번에 배포하려는 모든 AWS 고객.
+ 소프트웨어 패키지를 생성하는 소프트웨어 개발자
+ 최신 소프트웨어 패키지를 사용해 Systems Manager 관리형 노드를 최신 상태로 유지해야 하는 관리자.
## Distributor에는 어떤 기능이 있나요?
+ **Windows 및 Linux 인스턴스 둘 다에 패키지 배포**
Distributor를 사용하여 Linux 및 Windows Server용 Amazon Elastic Compute Cloud(Amazon EC2) 인스턴스 및 AWS IoT Greengrass 코어 디바이스 소프트웨어 패키지를 배포할 수 있습니다. 지원되는 인스턴스 운영 체제 유형의 목록은 [지원되는 패키지 플랫폼 및 아키텍처](#what-is-a-package-platforms) 섹션을 참조하세요.
**참고**
Distributor는 macOS 운영 체제에서 지원됩니다.
+ **한 번만 또는 자동화된 일정에 따라 패키지 배포**
패키지는 한 번만, 정기적으로 또는 기본 패키지 버전이 다른 버전으로 바뀔 때마다 배포하도록 선택할 수 있습니다.
+ **패키지를 완전히 다시 설치하거나 인플레이스 업데이트 수행**
새 패키지 버전을 설치하려면 제공하는 *업데이트 스크립트*에 따라 현재 버전을 완전히 제거하고 새 버전을 설치하거나 새 구성 요소와 업데이트된 구성 요소로만 현재 버전을 업데이트할 수 있습니다. 재설치 동안에는 패키지 애플리케이션을 사용할 수 없지만 인플레이스 업데이트 중에는 계속 사용할 수 있습니다. 인플레이스 업데이트는 보안 모니터링 애플리케이션이나 애플리케이션 다운타임을 피해야 하는 기타 시나리오에 특히 유용합니다.
+ **콘솔, CLI, PowerShell 및 SDK에서 Distributor 기능에 액세스**
선택한 Systems Manager 콘솔, AWS Command Line Interface(AWS CLI), AWS Tools for PowerShell 또는 AWS SDK를 사용하여 Distributor로 작업할 수 있습니다.
+ **IAM 액세스 제어**
AWS Identity and Access Management(IAM) 정책을 사용해 패키지 또는 패키지 버전을 생성, 배포 또는 삭제할 수 있는 조직의 멤버를 제어할 수 있습니다. 예를 들어, 관리자에게 패키지를 배포할 수 있는 권한은 부여하지만 패키지를 변경하거나 새 패키지 버전을 생성할 수 있는 권한은 부여하지 않을 수 있습니다.
+ **로깅 및 감사 기능 지원**
다른 AWS 서비스와(과)의 통합을 통해 AWS 계정에서 Distributor 사용자 작업을 감사하고 로그할 수 있습니다. 자세한 내용은 [Distributor 활동 감사 및 로깅](distributor-logging-auditing.md) 섹션을 참조하세요.
## Distributor의 패키지란?
*패키지*는 다음을 포함해 설치 가능한 소프트웨어 또는 자산 모음입니다.
+ 대상 운영 체제 플랫폼별 소프트웨어 .zip 파일 각 .zip 파일에는 다음 스크립트가 포함되어 있어야 합니다.
+ **install** 및 **uninstall** 스크립트. Windows Server 기반 관리형 노드에는 PowerShell 스크립트(스크립트 이름이 `install.ps1` 및 `uninstall.ps1`)가 필요합니다. Linux 기반 관리형 노드에는 셸 스크립트(스크립트 이름: `install.sh` 및 `uninstall.sh`)가 필요합니다. AWS Systems Manager SSM Agent가 **install** 및 **uninstall** 스크립트의 명령을 읽고 수행합니다.
+ 실행 파일. 대상 관리형 노드에 패키지를 설치하려면 SSM Agent가 이 실행 파일을 찾아야 합니다.
+ 패키지 콘텐츠를 설명하는 JSON 형식 매니페스트 파일. 매니페스트는 ZIP 파일에 포함되어 있지 않지만 패키지를 구성하는 ZIP 파일과 동일한 Amazon Simple Storage Service(Amazon S3) 버킷에 저장됩니다. 매니페스트는 패키지 버전을 식별하고, 패키지의 ZIP 파일을 대상 관리형 노드 속성(예: 운영 체제 버전 또는 아키텍처)에 매핑합니다. 매니페스트를 생성하는 방법은 [2단계: JSON 패키지 매니페스트 생성](distributor-working-with-packages-create.md#packages-manifest) 섹션을 참조하세요.
Distributor 콘솔에서 **단순(Simple)** 패키지 생성을 선택하면 Distributor가 소프트웨어 실행 파일 이름과 대상 플랫폼 및 아키텍처를 기반으로 설치 및 제거 스크립트, 파일 해시 및 JSON 패키지 매니페스트를 생성합니다.
### 지원되는 패키지 플랫폼 및 아키텍처
Distributor을 사용해 다음 Systems Manager 관리형 노드 플랫폼에 패키지를 게시할 수 있습니다. 버전 값은 대상 운영 체제 Amazon Machine Image(AMI)의 정확한 릴리스 버전과 일치해야 합니다. 이 버전 확인에 대한 자세한 내용은 [2단계: JSON 패키지 매니페스트 생성](distributor-working-with-packages-create.md#packages-manifest)의 4단계 참조하십시오.
**참고**
Systems Manager는 다음 AWS IoT Greengrass 코어 디바이스를 위한 운영 체제 중 일부를 지원하지 않습니다. 자세한 내용은 *AWS IoT Greengrass Version 2 개발자 안내서*의 [AWS IoT Greengrass 코어 디바이스 설정](https://docs.aws.amazon.com/greengrass/v2/developerguide/setting-up.html) 섹션을 참조하세요.
| 플랫폼 | 매니페스트 파일의 코드 값 | 지원되는 아키텍처 |
| --- | --- | --- |
| AlmaLinux | almalinux | x86\$164 ARM64 |
| Amazon Linux 2 및 Amazon Linux 2023 | `amazon` | x86\$164 또는 x86 ARM64(Amazon Linux 2 및 AL2023, A1 인스턴스 유형) |
| Debian Server | `debian` | x86\$164 또는 x86 |
| openSUSE | `opensuse` | x86\$164 |
| openSUSE Leap | `opensuseleap` | x86\$164 |
| Oracle Linux | `oracle` | x86\$164 |
| Red Hat Enterprise Linux (RHEL) | `redhat` | x86\$164 ARM64(RHEL 7.6 이상, A1 인스턴스 유형) |
| Rocky Linux | rocky | x86\$164 ARM64 |
| SUSE Linux Enterprise Server (SLES) | `suse` | x86\$164 |
| Ubuntu Server | `ubuntu` | x86\$164 또는 x86 ARM64(Ubuntu Server 16 이상, A1 인스턴스 유형) |
| Windows Server | `windows` | x86\$164 |
**Topics**
+ [Distributor가 조직에 주는 이점은 무엇인가요?](#distributor-benefits)
+ [Distributor는 누가 사용해야 하나요?](#distributor-who)
+ [Distributor에는 어떤 기능이 있나요?](#distributor-features)
+ [Distributor의 패키지란?](#what-is-a-package)
+ [Distributor 설정](distributor-getting-started.md)
+ [Distributor 패키지 작업](distributor-working-with.md)
+ [Distributor 활동 감사 및 로깅](distributor-logging-auditing.md)
+ [AWS Systems Manager Distributor 문제 해결](distributor-troubleshooting.md)
# Distributor 설정
AWS Systems Manager의 도구인 Distributor를 사용해 소프트웨어 패키지를 생성, 관리 및 배포하기 전에 다음 단계를 수행합니다.
## Distributor 사전 조건 완료
AWS Systems Manager의 도구인 Distributor를 사용하기 전에 환경이 다음 요구 사항을 충족하는지 확인합니다.
**Distributor 필수 조건**
| 요구 사항 | 설명 |
| --- | --- |
| SSM Agent | 배포하려는 관리형 노드 또는 패키지를 제거하려는 노드에 AWS Systems Manager SSM Agent 버전 2.3.274.0 이상이 설치되어 있어야 합니다. SSM Agent를 설치 또는 업데이트하려면 [SSM Agent 작업](ssm-agent.md) 섹션을 참조하세요. |
| AWS CLI | (옵션) Systems Manager 콘솔 대신 AWS Command Line Interface(AWS CLI)를 사용하여 패키지를 생성하고 관리하려면 로컬 컴퓨터에서 AWS CLI의 최신 릴리스를 설치합니다. CLI를 설치하거나 업그레이드하는 방법에 대한 자세한 내용은 *AWS Command Line Interface 사용 설명서*의 [AWS Command Line Interface 설치](https://docs.aws.amazon.com/cli/latest/userguide/installing.html)를 참조하세요. |
| AWS Tools for PowerShell | (옵션) Systems Manager 콘솔 대신 Tools for PowerShell을 사용하여 패키지를 생성하고 관리하려면 로컬 컴퓨터에 Tools for PowerShell의 최신 릴리스를 설치합니다. Tools for PowerShell을 설치하거나 업그레이드하는 방법에 대한 자세한 내용은 *AWS Tools for PowerShell 사용 설명서*의 [AWS Tools for Windows PowerShell 또는 AWS Tools for PowerShell Core 설정](https://docs.aws.amazon.com/powershell/latest/userguide/pstools-getting-set-up.html)을 참조하세요. |
**참고**
Systems Manager에서는 Distributor를 사용하여 Oracle Linux 관리형 노드에 패키지를 배포하는 작업을 지원하지 않습니다.
## Distributor 권한을 사용하여 IAM 인스턴스 프로파일 확인 또는 생성
AWS Systems Manager는 기본적으로 인스턴스에서 작업을 수행할 권한이 없습니다. AWS Identity and Access Management(IAM) 인스턴스 프로파일을 사용하여 액세스 권한을 부여해야 합니다. 인스턴스 프로파일은 시작 시 Amazon Elastic Compute Cloud(Amazon EC2) 인스턴스에 IAM 역할 정보를 전달하는 컨테이너입니다. 이 요구 사항은 Distributor뿐 아니라 모든 Systems Manager 도구에 대한 권한에 적용됩니다.
**참고**
엣지 디바이스가 AWS IoT Greengrass 코어 소프트웨어와 SSM Agent를 실행하도록 구성할 때 Systems Manager가 사용해 작업을 수행하는 IAM 서비스 역할을 특정하세요. 인스턴스 프로파일을 사용하여 관리형 에지 디바이스를 구성할 필요가 없습니다.
Run Command와 State Manager 등의 다른 Systems Manager 도구를 이미 사용하고 있는 경우에는 Distributor에 대해 필요한 권한이 있는 인스턴스 프로파일이 이미 인스턴스에 연결되어 있습니다. Distributor 태스크를 수행할 수 있는 권한이 있는지 확인하는 가장 간단한 방법은 **AmazonSSMManagedInstanceCore** 정책을 인스턴스 프로파일에 연결하는 것입니다. 자세한 내용은 [Systems Manager에 필요한 인스턴스 권한 구성](setup-instance-permissions.md)을 참조하세요.
## 패키지에 대한 사용자 액세스 제어
AWS Identity and Access Management(IAM) 정책을 사용하면 패키지를 생성, 배포 및 관리할 수 있는 사람을 제어할 수 있습니다. 또한 관리형 노드에서 수행할 수 있는 Run Command 및 State Manager API 작업을 제어할 수도 있습니다. Distributor와 마찬가지로 Run Command 및 State Manager는 모두 AWS Systems Manager의 도구입니다.
**ARN 형식**
사용자 정의 패키지는 문서 Amazon 리소스 이름(ARN)과 연결되어 있고 다음과 같은 형식을 갖습니다.
```
arn:aws:ssm:region:account-id:document/document-name
```
다음은 예입니다.
```
arn:aws:ssm:us-west-1:123456789012:document/ExampleDocumentName
```
각각 최종 사용자와 관리자를 위한 AWS 제공 기본 IAM 정책 페어를 사용하여 Distributor 작업에 대한 권한을 부여할 수 있습니다. 또는 권한 요구 사항에 적절한 사용자 정의 IAM 정책을 생성할 수 있습니다.
IAM 정책에서 변수 사용에 대한 자세한 내용은 [IAM 정책 요소: 변수](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_variables.html)를 참조하세요.
정책을 생성하고 사용자 또는 그룹에 연결하는 방법에 대한 자세한 내용은 **IAM 사용 설명서의 [IAM 정책 생성](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html) 및 [IAM 정책 추가 및 제거](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage-attach-detach.html)를 참조하세요.
## Distributor 패키지를 저장할 Amazon S3 버킷 생성 또는 선택
AWS Systems Manager 콘솔에서 **단순** 워크플로를 사용해 패키지를 생성할 경우 Distributor에서 소프트웨어를 업로드하던 기존 Amazon Simple Storage Service(Amazon S3) 버킷을 선택합니다. Distributor는 AWS Systems Manager의 도구입니다. **고급(Advanced)** 워크플로에서는 시작하기 전에 소프트웨어 또는 자산의 ZIP 파일을 Amazon S3 버킷에 업로드해야 합니다. 콘솔에서 **단순(Simple)** 또는 **고급(Advanced)** 워크플로를 선택하든, API를 사용하든 상관없이 패키지 생성을 시작하려면 Amazon S3 버킷이 필요합니다. 패키지 생성 프로세스가 시작되면 Distributor가 설치할 수 있는 소프트웨어 및 자산을 이 버킷에서 내부 Systems Manager 스토어로 복사합니다. 자산이 내부 스토어로 복사되기 때문에 패키지 생성을 마치면 Amazon S3 버킷을 삭제하거나 다른 용도로 사용할 수 있습니다.
버킷 생성 방법에 대한 자세한 내용은 *Amazon Simple Storage Service 시작 안내서*의 [버킷 생성](https://docs.aws.amazon.com/AmazonS3/latest/userguide/CreatingABucket.html)을 참조하세요. AWS CLI 명령을 실행하여 버킷을 생성하는 방법에 대한 자세한 내용은 *AWS CLI Command Reference*의 [https://docs.aws.amazon.com/cli/latest/reference/s3/mb.html](https://docs.aws.amazon.com/cli/latest/reference/s3/mb.html)를 참조하세요.
# Distributor 패키지 작업
AWS Systems Manager 콘솔, AWS 명령줄 도구(AWS CLI 및 AWS Tools for PowerShell), AWS SDK를 사용하여 Distributor에서 패키지를 추가, 관리 또는 배포할 수 있습니다. Distributor는 AWS Systems Manager의 도구입니다. Distributor에 패키지를 추가하기 전에:
+ 설치 가능한 자산을 생성해 압축합니다.
+ (선택 사항) 패키지의 JSON 매니페스트 파일을 생성합니다. Distributor 콘솔에서 **단순(Simple)** 패키지 생성 프로세스를 사용하는 경우에는 필요하지 않습니다. 심플 패키지 생성 프로세스에서는 JSON 매니페스트 파일이 자동으로 생성되기 때문입니다.
매니페스트 파일은 AWS Systems Manager 콘솔이나 텍스트 또는 JSON 편집기를 사용해 생성할 수 있습니다.
+ 설치 가능한 자산 또는 소프트웨어를 저장할 Amazon Simple Storage Service(Amazon S3) 버킷을 준비합니다. **고급(Advanced)** 패키지 생성 프로세스를 사용한다면 시작하기 전에 자산을 Amazon S3 버킷에 업로드합니다.
**참고**
패키지 생성 프로세스에서 Distributor가 패키지 내용을 내부 Systems Manager 버킷에 저장하기 때문에 패키지 생성을 마친 후 이 버킷을 삭제하거나 다른 용도로 사용할 수 있습니다.
AWS에서 게시한 패키지는 이미 패키징되어 바로 배포할 수 있습니다. AWS에서 게시한 패키지를 관리형 노드에 배포하려면 [Distributor 패키지 설치 또는 업데이트](distributor-working-with-packages-deploy.md) 섹션을 참조하세요.
AWS 계정 간에 Distributor 패키지를 공유할 수 있습니다. AWS CLI 명령에서 다른 계정에서 공유한 패키지를 사용하는 경우 패키지 이름 대신 Amazon 리소스 이름(ARN) 패키지를 사용합니다.
**Topics**
+ [Distributor에서 패키지 보기](distributor-view-packages.md)
+ [Distributor에서 패키지 생성](distributor-working-with-packages-create.md)
+ [콘솔에서 Distributor 패키지 권한 편집](distributor-working-with-packages-ep.md)
+ [콘솔에서 Distributor 패키지 태그 편집](distributor-working-with-packages-tags.md)
+ [Distributor 패키지에 버전 추가](distributor-working-with-packages-version.md)
+ [Distributor 패키지 설치 또는 업데이트](distributor-working-with-packages-deploy.md)
+ [Distributor 패키지 제거](distributor-working-with-packages-uninstall.md)
+ [Distributor 패키지 삭제](distributor-working-with-packages-dpkg.md)
# Distributor에서 패키지 보기
설치 가능한 패키지를 보려면 AWS Systems Manager 콘솔이나 선호하는 AWS 명령줄 도구를 사용합니다. Distributor는 AWS Systems Manager의 도구입니다. Distributor에 액세스하려면 AWS Systems Manager 콘솔을 열고 왼쪽 탐색 창에서 **Distributor**를 선택합니다. 사용 가능한 모든 패키지를 볼 수 있습니다.
다음 섹션에서는 선호하는 명령줄 도구를 사용하여 Distributor 패키지를 보는 방법을 설명합니다.
## 명령줄을 사용하여 패키지 보기
이 섹션에는 기본 명령줄 도구를 사용하여 제공된 명령을 사용하여 Distributor 패키지를 보는 방법에 대한 정보가 들어 있습니다.
------
#### [ Linux & macOS ]
**Linux에서 AWS CLI를 사용하여 패키지를 보려면**
+ 공유 패키지를 제외한 모든 패키지를 보려면 다음 명령을 실행합니다.
```
aws ssm list-documents \
--filters Key=DocumentType,Values=Package
```
+ Amazon이 소유한 모든 패키지를 보려면 다음 명령을 실행합니다.
```
aws ssm list-documents \
--filters Key=DocumentType,Values=Package Key=Owner,Values=Amazon
```
+ 서드 파티에서 소유한 모든 패키지를 보려면 다음 명령을 실행합니다.
```
aws ssm list-documents \
--filters Key=DocumentType,Values=Package Key=Owner,Values=ThirdParty
```
------
#### [ Windows ]
**Windows에서 AWS CLI를 사용하여 패키지를 보려면**
+ 공유 패키지를 제외한 모든 패키지를 보려면 다음 명령을 실행합니다.
```
aws ssm list-documents ^
--filters Key=DocumentType,Values=Package
```
+ Amazon이 소유한 모든 패키지를 보려면 다음 명령을 실행합니다.
```
aws ssm list-documents ^
--filters Key=DocumentType,Values=Package Key=Owner,Values=Amazon
```
+ 서드 파티에서 소유한 모든 패키지를 보려면 다음 명령을 실행합니다.
```
aws ssm list-documents ^
--filters Key=DocumentType,Values=Package Key=Owner,Values=ThirdParty
```
------
#### [ PowerShell ]
**Tools for PowerShell을 사용하여 패키지를 보려면**
+ 공유 패키지를 제외한 모든 패키지를 보려면 다음 명령을 실행합니다.
```
$filter = New-Object Amazon.SimpleSystemsManagement.Model.DocumentKeyValuesFilter
$filter.Key = "DocumentType"
$filter.Values = "Package"
Get-SSMDocumentList `
-Filters @($filter)
```
+ Amazon이 소유한 모든 패키지를 보려면 다음 명령을 실행합니다.
```
$typeFilter = New-Object Amazon.SimpleSystemsManagement.Model.DocumentKeyValuesFilter
$typeFilter.Key = "DocumentType"
$typeFilter.Values = "Package"
$ownerFilter = New-Object Amazon.SimpleSystemsManagement.Model.DocumentKeyValuesFilter
$ownerFilter.Key = "Owner"
$ownerFilter.Values = "Amazon"
Get-SSMDocumentList `
-Filters @($typeFilter,$ownerFilter)
```
+ 서드 파티에서 소유한 모든 패키지를 보려면 다음 명령을 실행합니다.
```
$typeFilter = New-Object Amazon.SimpleSystemsManagement.Model.DocumentKeyValuesFilter
$typeFilter.Key = "DocumentType"
$typeFilter.Values = "Package"
$ownerFilter = New-Object Amazon.SimpleSystemsManagement.Model.DocumentKeyValuesFilter
$ownerFilter.Key = "Owner"
$ownerFilter.Values = "ThirdParty"
Get-SSMDocumentList `
-Filters @($typeFilter,$ownerFilter)
```
------
# Distributor에서 패키지 생성
패키지를 생성하려면 설치 가능한 소프트웨어 또는 자산을 운영 체제 플랫폼마다 파일 1개씩 준비합니다. 파일이 1개 이상 있어야만 패키지를 생성할 수 있습니다.
여러 플랫폼에서 동일한 파일을 사용하는 경우도 있을 수 있지만 패키지에 연결한 모든 파일은 매니페스트의 `Files` 섹션에 나열되어 있어야 합니다. 콘솔에서 단순 워크플로를 사용해 패키지를 생성하는 경우에는 매니페스트가 자동으로 생성됩니다. 단일 문서에 연결할 수 있는 파일의 최대 개수는 20개입니다. 각 파일의 최대 크기는 1GB입니다. 지원되는 플랫폼에 대한 자세한 내용은 [지원되는 패키지 플랫폼 및 아키텍처](distributor.md#what-is-a-package-platforms) 섹션을 참조하세요.
패키지를 생성할 때 시스템에서 새 [SSM 문서](documents.md)를 생성합니다. 이 문서를 사용하면 관리형 노드에 패키지를 배포할 수 있습니다.
데모용인 예제 패키지 [ExamplePackage.zip](https://docs.aws.amazon.com/systems-manager/latest/userguide/samples/ExamplePackage.zip)을 웹 사이트에서 다운로드할 수 있습니다. 예제 패키지에는 완료된 JSON 매니페스트와 PowerShell v7.0.0용 설치 프로그램이 포함된 .zip 파일 3개가 들어 있습니다. 설치 및 제거 스크립트에는 유효한 명령이 포함되어 있지 않습니다. **고급(Advanced)** 워크플로에서는 소프트웨어 설치 파일과 스크립트를 .zip 파일로 압축해야 패키지를 생성할 수 있지만 **단순(Simple)** 워크플로에서는 설치 가능한 자산을 압축하지 않습니다.
**Topics**
+ [단순 워크플로를 사용한 패키지 생성](#distributor-working-with-packages-create-simple)
+ [고급 워크플로를 사용한 패키지 생성](#distributor-working-with-packages-create-adv)
## 단순 워크플로를 사용한 패키지 생성
이 섹션에서는 Distributor 콘솔을 사용해 **단순** 패키지 생성 워크플로를 선택하여 Distributor에서 패키지를 생성하는 방법에 대해 알아봅니다. Distributor는 AWS Systems Manager의 도구입니다. 패키지를 생성하려면 설치 가능한 자산을 운영 체제 플랫폼마다 파일 1개씩 준비합니다. 파일이 1개 이상 있어야만 패키지를 생성할 수 있습니다. **단순(Simple)** 패키지 생성 프로세스에서는 설치 및 제거 스크립트와 파일 해시, 그리고 JSON 형식의 매니페스트가 자동으로 생성됩니다. **단순(Simple)** 워크플로우를 선택하면 설치 파일을 업로드하여 ZIP 파일로 압축하는 프로세스와 새로운 패키지를 비롯해 연결된 [SSM 문서](documents.md)를 생성하는 프로세스가 처리됩니다. 지원되는 플랫폼에 대한 자세한 내용은 [지원되는 패키지 플랫폼 및 아키텍처](distributor.md#what-is-a-package-platforms) 섹션을 참조하세요.
심플 메서드를 사용하여 패키지를 만들면 Distributor에서 `install` 및 `uninstall` 스크립트가 생성됩니다. 그러나 인플레이스 업데이트를 위한 패키지를 생성하는 경우에는 **업데이트 스크립트(Update script)** 탭에서 자체 `update` 스크립트 내용을 제공해야 합니다. `update` 스크립트에 대한 입력 명령을 추가할 때 Distributor은 `install` 및 `uninstall` 스크립트와 함께 생성된 .zip 패키지에 이 스크립트를 포함합니다.
**참고**
`In-place` 업데이트 옵션을 사용하여 연결된 애플리케이션을 오프라인으로 전환하지 않고도 기존 패키지 설치에 새 파일이나 업데이트된 파일을 추가합니다.
**단순 워크플로를 사용하여 패키지를 생성하려면**
1. [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)에서 AWS Systems Manager 콘솔을 엽니다.
1. 탐색 창에서 **Distributor**를 선택합니다.
1. Distributor 홈페이지에서 **패키지 생성(Create package)**과 **단순(Simple)**을 차례대로 선택합니다.
1. **패키지 생성(Create package)** 페이지에서 패키지 이름을 입력합니다. 패키지 이름은 문자, 숫자, 마침표, 대시 및 밑줄을 포함할 수 있습니다. 이 이름은 모든 버전의 패키지 연결에 적용할 수 있을 정도로 충분히 일반적이어야 하지만 패키지의 목적을 식별할 수 있을 정도로 구체적이어야 합니다.
1. (선택 사항) **버전 이름(Version name)**에 버전 이름을 입력합니다. 버전 이름은 최대 512자로 구성되며, 여기에 특수 문자가 포함될 수 없습니다.
1. **위치(Location)**에서 버킷 이름 및 접두사를 사용하거나 버킷 URL을 사용하여 버킷을 선택합니다.
1. **소프트웨어 업로드(Upload software)**에서 **소프트웨어 추가(Add software)**를 선택한 다음, `.rpm`, `.msi`, `.deb` 확장을 사용하여 설치 가능한 소프트웨어 파일을 검색합니다. 파일 이름에 공백이 있으면 업로드가 실패합니다. 소프트웨어 파일은 한 번에 1개 이상 업로드할 수 있습니다.
1. **대상 플랫폼(Target platform)**에서 설치 파일마다 표시된 대상 운영 체제 플랫폼이 정확한지 확인합니다. 운영 체제가 잘못 표시되어 있으면 드롭다운 목록에서 정확한 운영 체제를 선택합니다.
**단순(Simple)** 패키지 생성 워크플로의 경우, 설치 가능한 파일마다 한 번씩 업로드하기 때문에 Distributor에서 다수의 운영 체제에 단일 파일을 대상으로 지정하도록 명령하기 위한 추가 단계가 필요합니다. 예를 들어 이름이 `Logtool_v1.1.1.rpm`인 소프트웨어 설치 파일을 업로드하는 경우에는 **단순(Simple)** 워크플로우에서 기본값을 몇 가지 변경해야만 동일한 소프트웨어를 Amazon Linux 운영 체제와 Ubuntu Server 운영 체제에 업로드할 수 있습니다. 여러 플랫폼을 대상으로 지정할 때는 다음 중 하나를 수행합니다.
+ 시작하기 전에 **고급** 워크플로를 사용해 각 설치 파일을 zip 파일로 압축한 다음 설치 파일을 다수의 운영 체제 플랫폼 또는 버전에 업로드할 수 있도록 매니페스트를 직접 작성합니다. 자세한 내용은 [고급 워크플로를 사용한 패키지 생성](#distributor-working-with-packages-create-adv) 섹션을 참조하세요.
+ zip 파일이 다수의 운영 체제 플랫폼 또는 버전으로 업로드될 수 있도록 **심플** 워크플로에서 매니페스트 파일을 직접 편집합니다. 자세한 내용은 [2단계: JSON 패키지 매니페스트 생성](#packages-manifest) 단원에서 4단계 마지막을 참조하세요.
1. **플랫폼 버전(Platform version)**에서 표시된 운영 체제 플랫폼 버전이 **\$1any**, 와일드카드 뒤에 오는 주 릴리스 버전(7.\$1) 또는 소프트웨어를 적용하려는 정확한 운영 체제 릴리스 버전인지 확인합니다. 운영 체제 플랫폼 버전을 지정하는 방법에 대한 자세한 내용은 [2단계: JSON 패키지 매니페스트 생성](#packages-manifest) 단원에서 4단계를 참조하세요.
1. **아키텍처(Architecture)**의 드롭다운 목록에서 설치 파일마다 정확한 프로세서 아키텍처를 선택합니다. 지원되는 프로세서 아키텍처에 대한 자세한 내용은 [지원되는 패키지 플랫폼 및 아키텍처](distributor.md#what-is-a-package-platforms) 섹션을 참조하세요.
1. (선택 사항) **스크립트**를 확장하고 설치 가능한 소프트웨어에 대해 Distributor에서 생성되는 스크립트를 검토합니다.
1. (선택 사항) 인플레이스 업데이트에 사용할 업데이트 스크립트를 제공하려면 **스크립트**를 확장하고 **Update script(업데이트 스크립트)** 탭을 선택한 다음, 업데이트 스크립트 명령을 입력합니다.
Systems Manager는 사용자를 대신하여 업데이트 스크립트를 생성하지 않습니다.
1. 소프트웨어 설치 파일을 추가하려면 **Add software(소프트웨어 추가)**를 선택합니다. 아니면 다음 단계로 이동합니다.
1. (선택 사항) **Manifest(매니페스트)**를 확장하여 Distributor에서 설치 가능한 소프트웨어에 생성한 JSON 패키지 매니페스트를 살펴봅니다. 이번 절차를 시작한 이후 플랫폼 버전, 대상 플랫폼 등 소프트웨어에 대한 정보를 변경하였다면 **Generate manifest(매니페스트 생성)**을 선택하여 업데이트된 패키지 매니페스트를 확인합니다.
8단계에서 설명한 것처럼 소프트웨어 설치 파일을 다수의 운영 체제에 업로드하는 경우에는 매니페스트를 수동으로 편집할 수 있습니다. 매니페스트 편집에 대한 자세한 내용은 [2단계: JSON 패키지 매니페스트 생성](#packages-manifest) 섹션을 참조하세요.
1. **Create package(패키지 생성)**를 선택합니다.
Distributor에서 소프트웨어 업로드 및 패키지 생성을 마칠 때까지 기다립니다. 각 설치 파일의 업로드 상태가 Distributor에 표시됩니다. 이 작업은 추가하는 패키지 수와 크기에 따라 몇 분까지 걸릴 수 있습니다. Distributor에서 새로운 패키지의 [**패키지 세부 정보(Package details)**] 페이지로 자동 리디렉션되지만 소프트웨어가 업로드된 후에도 이 페이지를 열도록 직접 선택할 수 있습니다. Distributor가 패키지 생성 프로세스를 마칠 때까지 [**패키지 세부 정보(Package details)**] 페이지에 패키지에 대한 모든 정보가 표시되지 않습니다. 업로드 및 패키지 생성 프로세스를 중지하려면 **취소**를 선택합니다.
Distributor에서 일부 소프트웨어 설치 파일을 업로드하지 못하는 경우에는 [**업로드 실패(Upload failed)**] 메시지가 표시됩니다. 업로드를 다시 시도하려면 **Retry upload(업로드 재시도)**를 선택합니다. 패키지 생성 실패에 따른 문제 해결 방법에 대한 자세한 내용은 [AWS Systems Manager Distributor 문제 해결](distributor-troubleshooting.md) 섹션을 참조하세요.
## 고급 워크플로를 사용한 패키지 생성
이 섹션에서는 고급 사용자가 설치 및 제거 스크립트와 JSON 매니페스트 파일로 설치 가능한 자산을 압축하여 Amazon S3 버킷으로 업로드한 후 Distributor에서 패키지를 생성할 수 있는 방법에 대해서 알아보겠습니다.
패키지를 생성하려면 설치 가능한 자산의 .zip 파일을 운영 체제 플랫폼당 하나의 .zip 파일로 준비합니다. 패키지를 생성하려면 하나 이상의 .zip 파일이 필요합니다. 다음으로, JSON 매니페스트를 생성합니다. 매니페스트에는 패키지 코드 파일에 대한 포인터가 포함되어 있습니다. 필요한 코드 파일을 폴더 또는 디렉터리에 추가했고 매니페스트가 올바른 값으로 채워진 경우 S3 버킷에 패키지를 업로드합니다.
예제 패키지 [ExamplePackage.zip](https://docs.aws.amazon.com/systems-manager/latest/userguide/samples/ExamplePackage.zip)은 Amazon 웹사이트에서 다운로드할 수 있습니다. 예제 패키지에는 완료된 JSON 매니페스트와 .zip 파일 3개가 들어 있습니다.
**Topics**
+ [1단계: ZIP 파일 생성](#packages-zip)
+ [2단계: JSON 패키지 매니페스트 생성](#packages-manifest)
+ [3단계: Amazon S3 버킷에 패키지 및 매니페스트 업로드](#packages-upload-s3)
+ [4단계: Distributor에 패키지 추가](#distributor-working-with-packages-add)
### 1단계: ZIP 파일 생성
소프트웨어 또는 설치 가능한 자산의 .zip 파일 하나 이상이 패키지의 바탕을 이룹니다. 여러 운영 체제에 하나의 .zip 파일을 설치할 수 없는 경우 패키지에는 지원하려는 운영 체제당 .zip 파일이 하나씩 포함됩니다. 예를 들어 Red Hat Enterprise Linux의 지원되는 버전 및 Amazon Linux 인스턴스는 일반적으로 동일한 .RPM 실행 파일을 실행할 수 있으므로 두 운영 체제를 지원하려면 이 패키지에 .zip 파일을 하나만 연결해야 합니다.
**필수 파일**
각 .zip 파일에 다음 항목이 필요합니다.
+ **install** 및 **uninstall** 스크립트. Windows Server 기반 관리형 노드에는 PowerShell 스크립트(스크립트 이름이 `install.ps1` 및 `uninstall.ps1`)가 필요합니다. Linux 기반 관리형 노드에는 셸 스크립트(스크립트 이름: `install.sh` 및 `uninstall.sh`)가 필요합니다. SSM Agent가 **install** 및 **uninstall** 스크립트의 명령을 실행합니다.
예를 들어, 설치 스크립트는 설치 프로그램(예: .rpm 또는 .msi)을 실행할 수 있고, 파일을 복사하거나 구성 설정을 지정할 수 있습니다.
+ 실행 파일, 설치 프로그램 패키지(rpm, .deb, .msi 등), 기타 스크립트 또는 구성 파일 등
**옵션 파일**
각 .zip 파일에서 다음 항목은 선택 사항입니다.
+ **update** 스크립트입니다. 업데이트 스크립트를 제공하면 `In-place update` 옵션을 사용하여 패키지를 설치할 수 있습니다. 기존 패키지 설치에 새 파일이나 업데이트된 파일을 추가하려는 경우 `In-place update` 옵션은 업데이트를 수행하는 동안 패키지 애플리케이션을 오프라인으로 전환하지 않습니다. Windows Server 기반 관리형 노드에는 PowerShell 스크립트(`update.ps1`라는 스크립트)가 필요합니다. Linux 기반 관리형 노드에는 셸 스크립트(`update.sh`라는 이름의 스크립트)가 필요합니다. SSM Agent은 **update** 스크립트의 명령을 실행합니다.
패키지 설치 또는 업데이트에 대한 자세한 내용은 [Distributor 패키지 설치 또는 업데이트](distributor-working-with-packages-deploy.md) 섹션을 참조하세요.
샘플 **install** 및 **uninstall** 스크립트를 포함한 .zip 파일의 예를 살펴보려면 예제 패키지인 [ExamplePackage.zip](https://docs.aws.amazon.com/systems-manager/latest/userguide/samples/ExamplePackage.zip)을 다운로드하세요.
### 2단계: JSON 패키지 매니페스트 생성
설치 파일을 준비하여 ZIP 파일로 압축하고 JSON 매니페스트를 생성합니다. 다음은 템플릿입니다. 이 단원의 절차에는 매니페스트 템플릿의 일부에 대한 설명이 나와 있습니다. JSON 편집기를 사용해 매니페스트를 별도의 파일로 생성할 수 있습니다. 또한 패키지를 생성할 때 AWS Systems Manager 콘솔에서 매니페스트를 작성할 수 있습니다.
```
{
"schemaVersion": "2.0",
"version": "your-version",
"publisher": "optional-publisher-name",
"packages": {
"platform": {
"platform-version": {
"architecture": {
"file": ".zip-file-name-1.zip"
}
}
},
"another-platform": {
"platform-version": {
"architecture": {
"file": ".zip-file-name-2.zip"
}
}
},
"another-platform": {
"platform-version": {
"architecture": {
"file": ".zip-file-name-3.zip"
}
}
}
},
"files": {
".zip-file-name-1.zip": {
"checksums": {
"sha256": "checksum"
}
},
".zip-file-name-2.zip": {
"checksums": {
"sha256": "checksum"
}
}
}
}
```
**JSON 패키지 매니페스트를 생성하려면**
1. 매니페스트에 스키마 버전을 추가합니다. 이 릴리스에서 스키마 버전은 항상 `2.0`입니다.
```
{ "schemaVersion": "2.0",
```
1. 매니페스트에 사용자 정의 패키지 버전을 추가합니다. Distributor에 패키지를 추가할 때 지정하는 [**버전 이름(Version name)**]의 값이기도 합니다. 이 값은 패키지를 추가할 때 Distributor에서 생성한 AWS Systems Manager 문서의 일부가 됩니다. 또한 최신 패키지 이외의 패키지 버전을 설치하려면 `AWS-ConfigureAWSPackage` 문서에 입력값으로 이 값을 제공합니다. `version` 값에는 문자, 숫자, 밑줄, 하이픈 및 마침표를 사용할 수 있으며 길이는 최대 128자입니다. 배포 시 정확한 패키지 버전을 쉽게 지정할 수 있으려면 사람이 읽을 수 있는 패키지 버전을 사용하는 것이 좋습니다. 다음은 예입니다.
```
"version": "1.0.1",
```
1. (선택 사항) 게시자 이름을 추가합니다. 다음은 예입니다.
```
"publisher": "MyOrganization",
```
1. 패키지를 추가합니다. `"packages"` 단원에는 패키지의 .zpi 파일에서 지원하는 플랫폼, 릴리스 버전 및 아키텍처에 대한 설명이 들어 있습니다. 자세한 내용은 [지원되는 패키지 플랫폼 및 아키텍처](distributor.md#what-is-a-package-platforms) 섹션을 참조하세요.
*platform-version*은 와일드카드 값인 `_any`일 수 있습니다. 이 값을 사용하면 .zip 파일이 모든 플랫폼 릴리스를 지원함을 나타냅니다. 모든 부 버전이 지원되도록 주 릴리스 버전 뒤에 와일드카드를 지정할 수도 있습니다(예: 7.\$1). 특정 운영 체제 버전에 대한 *platform-version* 값을 지정하도록 선택한 경우 대상 운영 체제 AMI의 정확한 릴리스 버전과 일치하는지 확인합니다. 다음은 운영 체제의 올바른 값을 얻을 수 있도록 제안되는 리소스입니다.
+ Windows Server 기반 관리형 노드에서 릴리스 버전은 WMI(Windows Management Instrumentation) 데이터로 사용할 수 있습니다. 다음 명령 프롬프트에서 명령을 실행해 버전 정보를 얻은 다음 `version`에 대한 결과를 구문 분석할 수 있습니다.
```
wmic OS get /format:list
```
+ Linux 기반 관리형 노드에서는 운영 체제 릴리스를 처음 스캔하여 버전을 확인할 수 있습니다(다음 명령). `VERSION_ID`의 값을 찾아보세요.
```
cat /etc/os-release
```
필요한 값을 반환하지 않은 경우 다음 명령을 실행해 `/etc/lsb-release` 파일에서 LSB 릴리스 정보를 가져오고 `DISTRIB_RELEASE`의 값을 찾아봅니다.
```
lsb_release -a
```
이러한 방법이 실패하면 일반적으로 배포를 기준으로 릴리스를 확인할 수 있습니다. 예를 들어, Debian Server에서는 `/etc/debian_version` 파일을, Red Hat Enterprise Linux에서는 `/etc/redhat-release` 파일을 스캔할 수 있습니다.
```
hostnamectl
```
```
"packages": {
"platform": {
"platform-version": {
"architecture": {
"file": ".zip-file-name-1.zip"
}
}
},
"another-platform": {
"platform-version": {
"architecture": {
"file": ".zip-file-name-2.zip"
}
}
},
"another-platform": {
"platform-version": {
"architecture": {
"file": ".zip-file-name-3.zip"
}
}
}
}
```
다음은 예입니다. 이 예제에서 운영 체제 플랫폼은 `amazon`이고, 지원되는 릴리스 버전은 `2016.09`이고, 아키텍처는 `x86_64`이고, 이 플랫폼을 지원하는 .zip 파일은 `test.zip`입니다.
```
{
"amazon": {
"2016.09": {
"x86_64": {
"file": "test.zip"
}
}
}
},
```
패키지가 상위 요소의 모든 버전을 지원함을 나타내기 위해 와일드카드 값 `_any`를 추가할 수 있습니다. 예를 들어 패키지가 Amazon Linux의 모든 릴리스 버전에서 지원된다고 나타내려면 패키지 구문이 다음과 비슷해야 합니다. 버전 또는 아키텍처 수준에서`_any` 와일드카드를 사용하여 플랫폼의 모든 버전, 버전의 모든 아키텍처 또는 플랫폼의 모든 버전 및 아키텍처를 지원할 수 있습니다.
```
{
"amazon": {
"_any": {
"x86_64": {
"file": "test.zip"
}
}
}
},
```
다음 예에서는 `_any`를 추가해 첫 번째 패키지 `data1.zip`이 Amazon Linux 2016.09의 모든 아키텍처에 대해 지원됨을 보여줍니다. 두 번째 패키지 `data2.zip`은 Amazon Linux의 모든 릴리스에 대해 지원되지만 아키텍처가 `x86_64`인 관리형 노드만 지원합니다. `2023.8` 및 `_any` 버전은 둘 다 `amazon` 아래에 있는 항목입니다. 여기에는 지원되는 버전, 아키텍처 및 연결된 .zip 파일이 아니라 하나의 플랫폼(Amazon Linux)이 있습니다.
```
{
"amazon": {
"2023.8": {
"_any": {
"file": "data1.zip"
}
},
"_any": {
"x86_64": {
"file": "data2.zip"
}
}
}
}
```
.zip 파일이 플랫폼을 두 개 이상 지원하는 경우에는 매니페스트의 `"packages"` 섹션에서 .zip 파일을 두 번 이상 참조할 수 있습니다. 예를 들어 Red Hat Enterprise Linux 8.x 버전과 Amazon Linux를 둘 다 지원하는 .zip 파일이 있는 경우 다음 예제에 표시된 것처럼 `"packages"` 섹션에는 동일한 .zip 파일을 가리키는 항목이 2개 있습니다.
```
{
"amazon": {
"2023.8.20250715 ": {
"x86_64": {
"file": "test.zip"
}
}
},
"redhat": {
"8.*": {
"x86_64": {
"file": "test.zip"
}
}
}
},
```
1. 4단계에서 이 패키지의 일부인 .zip 파일 목록을 추가합니다. 각 파일 항목에는 파일 이름과 `sha256` 해시 값 체크섬이 필요합니다. 설치 실패를 방지하기 위해 매니페스트의 체크섬 값은 압축된 자산에 `sha256` 해시 값과 일치해야 합니다.
설치 가능 항목에서 정확한 체크섬을 얻기 위해 다음 명령을 실행할 수 있습니다. Linux에서 `shasum -a 256 file-name.zip` 또는 `openssl dgst -sha256 file-name.zip`을 실행합니다. Windows의 경우 [PowerShell](https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.utility/get-filehash?view=powershell-6)에서 `Get-FileHash -Path path-to-.zip-file` cmdlet을 실행합니다.
매니페스트의 `"files"` 섹션에는 패키지의 각 .zip 파일에 대한 참조가 하나씩 들어 있습니다.
```
"files": {
"test-agent-x86.deb.zip": {
"checksums": {
"sha256": "EXAMPLE2706223c7616ca9fb28863a233b38e5a23a8c326bb4ae241dcEXAMPLE"
}
},
"test-agent-x86_64.deb.zip": {
"checksums": {
"sha256": "EXAMPLE572a745844618c491045f25ee6aae8a66307ea9bff0e9d1052EXAMPLE"
}
},
"test-agent-x86_64.nano.zip": {
"checksums": {
"sha256": "EXAMPLE63ccb86e830b63dfef46995af6b32b3c52ce72241b5e80c995EXAMPLE"
}
},
"test-agent-rhel8-x86.nano.zip": {
"checksums": {
"sha256": "EXAMPLE13df60aa3219bf117638167e5bae0a55467e947a363fff0a51EXAMPLE"
}
},
"test-agent-x86.msi.zip": {
"checksums": {
"sha256": "EXAMPLE12a4abb10315aa6b8a7384cc9b5ca8ad8e9ced8ef1bf0e5478EXAMPLE"
}
},
"test-agent-x86_64.msi.zip": {
"checksums": {
"sha256": "EXAMPLE63ccb86e830b63dfef46995af6b32b3c52ce72241b5e80c995EXAMPLE"
}
},
"test-agent-rhel8-x86.rpm.zip": {
"checksums": {
"sha256": "EXAMPLE13df60aa3219bf117638167e5bae0a55467e947a363fff0a51EXAMPLE"
}
}
}
```
1. 패키지 정보를 추가한 후에는 매니페스트 파일을 저장한 다음 닫습니다.
다음은 완성된 매니페스트의 예입니다. 이 예제에서는 플랫폼을 두 개 이상 지원하지만 `"files"` 섹션에서 한 번만 참조되는 .zip 파일인 `NewPackage_LINUX.zip`이 있습니다.
```
{
"schemaVersion": "2.0",
"version": "1.7.1",
"publisher": "Amazon Web Services",
"packages": {
"windows": {
"_any": {
"x86_64": {
"file": "NewPackage_WINDOWS.zip"
}
}
},
"amazon": {
"_any": {
"x86_64": {
"file": "NewPackage_LINUX.zip"
}
}
},
"ubuntu": {
"_any": {
"x86_64": {
"file": "NewPackage_LINUX.zip"
}
}
}
},
"files": {
"NewPackage_WINDOWS.zip": {
"checksums": {
"sha256": "EXAMPLEc2c706013cf8c68163459678f7f6daa9489cd3f91d52799331EXAMPLE"
}
},
"NewPackage_LINUX.zip": {
"checksums": {
"sha256": "EXAMPLE2b8b9ed71e86f39f5946e837df0d38aacdd38955b4b18ffa6fEXAMPLE"
}
}
}
}
```
#### 패키지 예제
예제 패키지 [ExamplePackage.zip](https://docs.aws.amazon.com/systems-manager/latest/userguide/samples/ExamplePackage.zip)은 Amazon 웹사이트에서 다운로드할 수 있습니다. 예제 패키지에는 완료된 JSON 매니페스트와 .zip 파일 3개가 들어 있습니다.
### 3단계: Amazon S3 버킷에 패키지 및 매니페스트 업로드
모든 .zip 파일을 폴더 또는 디렉터리로 복사하거나 이동하여 패키지를 준비합니다. 유효한 패키지에는 [2단계: JSON 패키지 매니페스트 생성](#packages-manifest)에서 생성한 매니페스트 및 매니페스트 파일 목록에 지정된 모든 .zip 파일이 필요합니다.
**Amazon S3에 패키지 및 매니페스트를 업로드하려면**
1. 매니페스트에서 지정한 모든 .zip 아카이브 파일을 폴더 또는 디렉터리로 복사하거나 이동합니다. .zip 아카이브 파일 및 매니페스트 파일을 이동하려는 폴더 또는 디렉터리를 압축하지 않습니다.
1. 버킷을 생성하거나 기존 버킷을 선택합니다. 자세한 내용은 *Amazon Simple Storage Service 시작 안내서*의 [버킷 생성](https://docs.aws.amazon.com/AmazonS3/latest/userguide/CreatingABucket.html)을 참조하세요. AWS CLI 명령을 실행하여 버킷을 생성하는 방법에 대한 자세한 내용은 *AWS CLI Command Reference*의 [https://docs.aws.amazon.com/cli/latest/reference/s3/mb.html](https://docs.aws.amazon.com/cli/latest/reference/s3/mb.html)를 참조하세요.
1. 버킷에 폴더나 디렉터리를 업로드합니다. 자세한 내용은 *Amazon Simple Storage Service 시작 안내서*의 [버킷에 객체 추가](https://docs.aws.amazon.com/AmazonS3/latest/userguide/PuttingAnObjectInABucket.html)를 참조하세요. JSON 매니페스트를 AWS Systems Manager 콘솔에 붙여 넣으려는 경우 매니페스트를 업로드하지 않습니다. AWS CLI 명령을 실행하여 파일을 업로드하는 방법에 대한 자세한 내용은 *AWS CLI Command Reference*의 [https://docs.aws.amazon.com/cli/latest/reference/s3/mv.html](https://docs.aws.amazon.com/cli/latest/reference/s3/mv.html)를 참조하세요.
1. 버킷의 홈 페이지에서 업로드한 폴더나 디렉터리를 선택합니다. 파일을 버킷의 하위 폴더로 업로드하였다면 해당하는 하위 폴더(*접두사*로도 알 수 있음)를 기록해야 합니다. 패키지를 Distributor에 추가할 때 접두사가 필요하기 때문입니다.
### 4단계: Distributor에 패키지 추가
AWS Systems Manager 콘솔, AWS 명령줄 도구(AWS CLI 및 AWS Tools for PowerShell) 또는 AWS SDK를 사용하여 Distributor에 새 패키지를 추가할 수 있습니다. 패키지를 추가할 때 새 [SSM 문서](documents.md)를 추가합니다. 이 문서를 사용하면 관리형 노드에 패키지를 배포할 수 있습니다.
**Topics**
+ [콘솔을 사용한 패키지 추가](#create-pkg-console)
+ [AWS CLI를 사용한 패키지 추가](#create-pkg-cli)
#### 콘솔을 사용한 패키지 추가
AWS Systems Manager 콘솔을 사용하여 패키지를 만들 수 있습니다. [3단계: Amazon S3 버킷에 패키지 및 매니페스트 업로드](#packages-upload-s3)에서 패키지를 업로드한 버킷 이름을 준비합니다.
**Distributor에 패키지를 추가하려면(콘솔)**
1. [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)에서 AWS Systems Manager 콘솔을 엽니다.
1. 탐색 창에서 **Distributor**를 선택합니다.
1. Distributor 홈페이지에서 **Create package(패키지 생성)**과 **고급**을 차례대로 선택합니다.
1. **패키지 생성(Create package)** 페이지에서 패키지 이름을 입력합니다. 패키지 이름은 문자, 숫자, 마침표, 대시 및 밑줄을 포함할 수 있습니다. 이 이름은 모든 버전의 패키지 연결에 적용할 수 있을 정도로 충분히 일반적이어야 하지만 패키지의 목적을 식별할 수 있을 정도로 구체적이어야 합니다.
1. **Version name(버전 이름)**에 매니페스트 파일 내 `version` 항목의 정확한 값을 입력합니다.
1. [**S3 버킷 이름(S3 bucket name)**]에서 [3단계: Amazon S3 버킷에 패키지 및 매니페스트 업로드](#packages-upload-s3)에서 .zip 파일과 매니페스트를 업로드한 버킷의 이름을 선택합니다.
1. **S3 키 접두사**에 .zip 파일과 매니페스트가 저장되는 버킷의 하위 폴더를 입력합니다.
1. .zip 파일이 저장된 Amazon S3 버킷에 업로드한 매니페스트를 사용하려면 [**매니페스트(Manifest)**]에서 [**패키지에서 추출(Extract from package)**]을 선택합니다.
(옵션) .zip 파일이 저장된 S3 버킷에 JSON 매니페스트를 업로드하지 않았다면 [**새 매니페스트(New manifest)**]를 선택합니다. JSON 편집기 필드에서 전체 매니페스트를 작성하거나 붙여넣을 수 있습니다. JSON 매니페스트를 생성하는 자세한 방법은 [2단계: JSON 패키지 매니페스트 생성](#packages-manifest) 섹션을 참조하세요.
1. 매니페스트 작성을 마치면 [**패키지 생성(Create package)**]을 선택합니다.
1. Distributor가 .zip 파일과 매니페스트에서 패키지를 생성할 때까지 기다립니다. 이 작업은 추가하는 패키지 수와 크기에 따라 몇 분까지 걸릴 수 있습니다. Distributor에서 새로운 패키지의 **Package details(패키지 세부 정보)** 페이지로 자동 리디렉션되지만 소프트웨어가 업로드된 후에도 이 페이지를 열도록 직접 선택할 수 있습니다. Distributor가 패키지 생성 프로세스를 마칠 때까지 [**패키지 세부 정보(Package details)**] 페이지에 패키지에 대한 모든 정보가 표시되지 않습니다. 업로드 및 패키지 생성 프로세스를 중지하려면 **취소**를 선택합니다.
#### AWS CLI를 사용한 패키지 추가
AWS CLI을 사용하여 패키지를 생성할 수 있습니다. [3단계: Amazon S3 버킷에 패키지 및 매니페스트 업로드](#packages-upload-s3)에서 패키지를 업로드한 버킷에서 해당 URL을 사용할 준비가 되었습니다.
**AWS CLI를 사용하여 Amazon S3에 패키지를 추가하려면**
1. AWS CLI를 사용하여 패키지를 생성하려면 다음 명령을 실행합니다. 이때 *package-name*을 해당 패키지 이름으로 바꾸고 *path-to-manifest-file*은 JSON 매니페스트 파일의 파일 경로로 바꿉니다. amzn-s3-demo-bucket은 전체 패키지가 저장된 Amazon S3 버킷의 URL입니다. Distributor에서 **create-document** 명령을 실행할 때 `--document-type`에 대해 `Package` 값을 지정합니다.
Amazon S3 버킷에 매니페스트 파일을 추가하지 않은 경우 `--content` 파라미터 값은 JSON 매니페스트 파일에 대한 파일 경로입니다.
```
aws ssm create-document \
--name "package-name" \
--content file://path-to-manifest-file \
--attachments Key="SourceUrl",Values="amzn-s3-demo-bucket" \
--version-name version-value-from-manifest \
--document-type Package
```
다음은 예입니다.
```
aws ssm create-document \
--name "ExamplePackage" \
--content file://path-to-manifest-file \
--attachments Key="SourceUrl",Values="https://s3.amazonaws.com/amzn-s3-demo-bucket/ExamplePackage" \
--version-name 1.0.1 \
--document-type Package
```
1. 패키지가 추가되었는지 확인하고 다음 명령을 실행하되 *package-name*은 패키지의 이름으로 바꿔 패키지 매니페스트를 표시합니다. (패키지의 버전과 같지 않은) 문서의 특정 버전을 확인하려면 `--document-version` 파라미터를 추가할 수 있습니다.
```
aws ssm get-document \
--name "package-name"
```
**create-document** 명령과 함께 사용할 수 있는 다른 옵션에 대한 자세한 내용은 *AWS CLI Command Reference*의 AWS Systems Manager 섹션에 있는 [https://docs.aws.amazon.com/cli/latest/reference/ssm/create-document.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/create-document.html)를 참조하세요. **get-document** 명령과 함께 사용할 수 있는 다른 옵션에 대한 자세한 내용은 [https://docs.aws.amazon.com/cli/latest/reference/ssm/get-document.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/get-document.html)를 참조하세요.
# 콘솔에서 Distributor 패키지 권한 편집
AWS Systems Manager의 도구인 Distributor에 패키지를 추가한 후 Systems Manager 콘솔에서 패키지의 권한을 편집할 수 있습니다. 패키지의 권한에 다른 AWS 계정를 추가할 수 있습니다. 동일한 AWS 리전에서만 다른 계정과 패키지를 공유할 수 있습니다. 크로스 리전 공유는 지원되지 않습니다. 기본적으로 패키지는 [**프라이빗(Private)**]으로 설정되어 있습니다. 즉, 패키지 생성자의 AWS 계정에 대한 액세스 권한을 가진 사용자만 패키지 정보를 보고 패키지를 업데이트 또는 삭제할 수 있습니다. **프라이빗** 권한을 허용 가능한 경우 이 절차를 건너뛸 수 있습니다.
**참고**
20개 이하의 계정과 공유되는 패키지의 권한을 업데이트할 수 있습니다.
**콘솔에서 패키지 권한을 편집하려면**
1. [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)에서 AWS Systems Manager 콘솔을 엽니다.
1. 탐색 창에서 **Distributor**를 선택합니다.
1. **패키지** 페이지에서 권한을 편집하려는 패키지를 선택합니다.
1. **Package details(패키지 세부 정보)** 탭에서 **권한 편집**을 선택해 권한을 변경합니다.
1. **Edit permissions(권한 편집)**에서 **Shared with specific accounts(특정 계정과 공유됨)**를 선택합니다.
1. [**특정 계정과 공유됨(Shared with specific accounts)**]에서 AWS 계정 번호를 한 번에 하나씩 추가합니다. 작업을 마쳤으면 **저장**을 선택합니다.
# 콘솔에서 Distributor 패키지 태그 편집
AWS Systems Manager의 도구인 Distributor에 패키지를 추가한 후에는 Systems Manager 콘솔에서 해당 패키지의 태그를 편집할 수 있습니다. 이러한 태그는 패키지에 적용되며, 패키지를 배포하려는 관리형 노드의 태그에는 연결되지 않습니다. 태그는 대소문자를 구분하는 키와 값 페어로, 조직과 관련된 기준으로 패키지를 그룹화 및 필터링하는 데 유용합니다. 태그를 추가하지 않으려는 경우 패키지를 설치하거나 새 버전을 추가할 준비가 된 것입니다.
**콘솔에서 패키지 태그를 편집하려면**
1. [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)에서 AWS Systems Manager 콘솔을 엽니다.
1. 탐색 창에서 **Distributor**를 선택합니다.
1. **패키지** 페이지에서 태그를 편집할 패키지를 선택합니다.
1. **패키지 세부 정보** 탭의 **태그**에서 **편집**을 선택합니다.
1. **태그 추가**에서 태그 키나, 태그 키 및 값 페어를 입력한 다음 **추가**를 선택합니다. 태그를 더 추가하고 싶은 경우 이 단계를 반복합니다. 태그를 삭제하려면 창 아래에서 태그에 표시된 **X**를 선택합니다.
1. 패키지에 태그 추가가 완료되면 [**저장(Save)**]을 선택합니다.
# Distributor 패키지에 버전 추가
패키지 버전을 추가하려면 [패키지를 생성](distributor-working-with-packages-create.md)한 후 Distributor를 사용해 이전 버전에 이미 존재하는 AWS Systems Manager(SSM) 문서에 항목을 추가하여 패키지 버전을 추가합니다. Distributor는 AWS Systems Manager의 도구입니다. 시간을 절약하기 위해 패키지의 이전 버전에 대한 매니페스트를 업데이트하고 매니페스트에서 `version` 항목의 값을 변경한 다음(예: `Test_1.0`에서 `Test_2.0`으로 변경) 새 버전의 매니페스트로 저장합니다. Distributor 콘솔의 간단한 [**버전 추가(Add version)**] 워크플로가 매니페스트 파일을 업데이트합니다.
새 패키지 버전은 다음 작업을 수행할 수 있습니다.
+ 현재 버전에 연결된 설치 파일을 하나 이상 바꿉니다.
+ 추가 플랫폼을 지원하기 위해 새로운 설치 파일을 추가합니다.
+ 특정 플랫폼에 대한 지원을 중단하기 위해 파일을 삭제합니다.
새 버전에서 동일한 Amazon Simple Storage Service(Amazon S3) 버킷을 사용할 수 있지만 맨 끝에 표시되는 URL의 파일 이름은 달라야 합니다. Systems Manager 콘솔이나 AWS Command Line Interface(AWS CLI)를 사용하여 새 버전을 추가할 수 있습니다. 기존에 Amazon S3 버킷에 저장되어 있던 설치 파일과 동일한 이름으로 설치 파일을 업로드할 경우 기존 파일을 덮어쓰게 됩니다. 설치 파일은 이전 버전에서 새로운 버전으로 복사할 수 없습니다. 따라서 새로운 버전에 추가하려면 이전 버전에서 설치 파일을 업로드해야 합니다. Distributor가 새로운 패키지 버전 생성을 마치면 Amazon S3 버킷을 삭제하거나 다른 용도로 사용할 수 있습니다. Distributor가 버전 관리 프로세스의 일환으로 소프트웨어를 내부 Systems Manager 버킷에 복사하기 때문입니다.
**참고**
각 패키지는 최대 25개 버전으로 유지됩니다. 더 이상 필요하지 않은 버전을 삭제할 수 있습니다.
**Topics**
+ [콘솔을 사용한 패키지 버전 추가](#add-pkg-version)
+ [AWS CLI를 사용한 패키지 버전 추가](#add-pkg-version-cli)
## 콘솔을 사용한 패키지 버전 추가
이러한 단계를 수행하기 전에 [Distributor에서 패키지 생성](distributor-working-with-packages-create.md)의 지침에 따라 해당 버전에 대한 새 패키지를 생성합니다. 그런 다음 Systems Manager 콘솔을 사용하여 Distributor에 새 패키지 버전을 추가합니다.
### 단순 워크플로를 사용한 패키지 버전 추가
**Simple(단순)** 워크플로를 사용해 패키지 버전을 추가할 때는 업데이트된 설치 가능한 파일을 준비하거나, 더욱 많은 플랫폼과 아키텍처를 지원할 수 있는 설치 파일을 추가합니다. 그런 다음 Distributor를 사용해 새롭거나 업데이트된 설치 파일을 업로드하고 패키지 버전을 추가합니다. Distributor 콘솔의 간단한 [**버전 추가(Add version)**] 워크플로가 매니페스트 파일과 관련 SSM 문서를 업데이트합니다.
**단순 워크플로를 사용하여 패키지 버전을 추가하려면**
1. [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)에서 AWS Systems Manager 콘솔을 엽니다.
1. 탐색 창에서 **Distributor**를 선택합니다.
1. Distributor 홈 페이지에서 다른 버전을 추가하려는 패키지를 선택합니다.
1. **Add version(버전 추가)** 페이지에서 **Simple(단순)**을 선택합니다.
1. **Version name(버전 이름)**에 버전 이름을 입력합니다. 새로운 버전 이름은 이전 버전 이름과 달라야 합니다. 버전 이름은 최대 512자로 구성되며, 여기에 특수 문자가 포함될 수 없습니다.
1. **S3 버킷 이름**의 목록에서 기존 S3 버킷을 선택합니다. 이전 버전에서 설치 파일을 저장했던 버킷을 그대로 선택할 수도 있지만 이때는 버킷에 저장된 기존 설치 파일을 덮어쓰지 않도록 설치 파일 이름이 달라야 합니다.
1. **S3 키 접두사**에 설치 가능한 자산이 저장되는 버킷의 하위 폴더를 입력합니다.
1. [**소프트웨어 업로드(Upload software)**]에서 새로운 버전에 추가할 소프트웨어 설치 파일을 찾습니다. 기존 버전의 설치 파일은 새로운 버전으로 자동 복사되지 않습니다. 따라서 새로운 버전에 동일한 설치 파일을 추가하려면 이전 패키지 버전에서 설치 파일을 업로드해야 합니다. 소프트웨어 파일은 한 번에 1개 이상 업로드할 수 있습니다.
1. **대상 플랫폼(Target platform)**에서 설치 파일마다 표시된 대상 운영 체제 플랫폼이 정확한지 확인합니다. 운영 체제가 잘못 표시되어 있으면 드롭다운 목록에서 정확한 운영 체제를 선택합니다.
**Simple(단순)** 버전 관리 워크플로우에서는 설치 파일마다 한 번씩 업로드하기 때문에 다수의 운영 체제를 대상으로 단일 파일을 업로드해야 한다면 추가 단계가 필요합니다. 예를 들어 이름이 `Logtool_v1.1.1.rpm`인 소프트웨어 설치 파일을 업로드하는 경우에는 **Simple(단순)** 워크플로우에서 기본값을 몇 가지 변경해야만 Distributor가 동일한 소프트웨어를 Amazon Linux 운영 체제와 Ubuntu Server 운영 체제에 업로드할 수 있습니다. 이러한 제약은 다음 중 한 가지를 사용해 해결할 수 있습니다.
+ 시작하기 전에 **고급** 버전 관리 워크플로우를 사용해 각 설치 파일을 .zip 파일로 압축한 다음 설치 파일을 다수의 운영 체제 플랫폼 또는 버전에 업로드할 수 있도록 매니페스트를 직접 작성합니다. 자세한 내용은 [고급 워크플로를 사용한 패키지 버전 추가](#add-pkg-version-adv) 섹션을 참조하세요.
+ zip 파일이 다수의 운영 체제 플랫폼 또는 버전으로 업로드될 수 있도록 **심플** 워크플로에서 매니페스트 파일을 직접 편집합니다. 자세한 내용은 [2단계: JSON 패키지 매니페스트 생성](distributor-working-with-packages-create.md#packages-manifest) 단원에서 4단계 마지막을 참조하세요.
1. **플랫폼 버전(Platform version)**에서 표시된 운영 체제 플랫폼 버전이 **\$1any**, 와일드카드 뒤에 오는 주 릴리스 버전(8.\$1) 또는 소프트웨어를 적용하려는 정확한 운영 체제 릴리스 버전인지 확인합니다. 플랫폼 버전을 지정하는 방법에 대한 자세한 내용은 [2단계: JSON 패키지 매니페스트 생성](distributor-working-with-packages-create.md#packages-manifest) 단원에서 4단계를 참조하세요.
1. **아키텍처**의 드롭다운 목록에서 설치 파일마다 정확한 프로세서 아키텍처를 선택합니다. 지원되는 아키텍처에 대한 자세한 내용은 [지원되는 패키지 플랫폼 및 아키텍처](distributor.md#what-is-a-package-platforms) 섹션을 참조하세요.
1. (선택 사항) **스크립트**를 확장하여 Distributor에서 설치 가능한 소프트웨어에 대해 생성된 설치 및 제거 스크립트를 검토합니다.
1. 소프트웨어 설치 파일을 새로운 버전에 추가하려면 **Add software(소프트웨어 추가)**를 선택합니다. 아니면 다음 단계로 이동합니다.
1. (선택 사항) **Manifest(매니페스트)**를 확장하여 Distributor에서 설치 가능한 소프트웨어에 생성한 JSON 패키지 매니페스트를 살펴봅니다. 이번 절차를 시작한 이후 플랫폼 버전, 대상 플랫폼 등 설치 가능한 소프트웨어에 대한 정보를 변경하였다면 **Generate manifest(매니페스트 생성)**을 선택하여 업데이트된 패키지 매니페스트를 확인합니다.
9단계에서 설명한 것처럼 소프트웨어 설치 파일을 다수의 운영 체제에 업로드하는 경우에는 매니페스트를 수동으로 편집할 수 있습니다. 매니페스트 편집에 대한 자세한 내용은 [2단계: JSON 패키지 매니페스트 생성](distributor-working-with-packages-create.md#packages-manifest) 섹션을 참조하세요.
1. 소프트웨어 추가를 비롯해 대상 플랫폼, 버전 및 아키텍처 데이터에 대한 검토까지 마쳤다면 이제 **Add version(버전 추가)**를 선택합니다.
1. Distributor에서 소프트웨어 업로드 및 새로운 패키지 버전 생성을 마칠 때까지 기다립니다. 각 설치 파일의 업로드 상태가 Distributor에 표시됩니다. 이 작업은 추가하는 패키지 수와 크기에 따라 몇 분까지 걸릴 수 있습니다. Distributor에서 패키지의 **Package details(패키지 세부 정보)** 페이지로 자동 리디렉션되지만 소프트웨어가 업로드된 후에도 이 페이지를 열도록 직접 선택할 수 있습니다. Distributor가 패키지 새 패키지 버전 생성을 마칠 때까지 [**Package details(패키지 세부 정보)**] 페이지에 패키지에 대한 모든 정보가 표시되지 않습니다. 업로드 및 패키지 버전 생성을 중지하려면 **Stop upload(업로드 중지)**를 선택합니다.
1. Distributor에서 일부 소프트웨어 설치 파일을 업로드하지 못하는 경우에는 [**업로드 실패(Upload failed)**] 메시지가 표시됩니다. 업로드를 다시 시도하려면 **Retry upload(업로드 재시도)**를 선택합니다. 패키지 버전 생성 실패에 따른 문제 해결 방법에 대한 자세한 내용은 [AWS Systems Manager Distributor 문제 해결](distributor-troubleshooting.md) 섹션을 참조하세요.
1. Distributor가 새로운 패키지 버전 생성을 마치면 해당 패키지 **세부 정보** 페이지의 **버전** 탭에서 사용 가능한 패키지 버전 목록에 새로운 버전이 있는지 확인합니다. 버전을 추가한 다음 **기본 버전 설정**을 선택하여 패키지의 기본 버전을 설정합니다.
기본 버전을 설정하지 않으면 최신 패키지 버전이 기본 버전입니다.
### 고급 워크플로를 사용한 패키지 버전 추가
패키지 버전을 추가하려면 [패키지를 생성](distributor-working-with-packages-create.md)한 후 Distributor를 사용해 이전 버전에 존재하는 SSM 문서에 항목을 추가하여 패키지 버전을 추가합니다. 시간을 절약하기 위해 패키지의 이전 버전에 대한 매니페스트를 업데이트하고 매니페스트에서 `version` 항목의 값을 변경한 다음(예: `Test_1.0`에서 `Test_2.0`으로 변경) 새 버전의 매니페스트로 저장합니다. **고급** 워크플로우에서 새로운 패키지 버전을 추가하려면 업데이트된 매니패스트가 필요합니다.
**고급 워크플로를 사용하여 패키지 버전을 추가하려면**
1. [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)에서 AWS Systems Manager 콘솔을 엽니다.
1. 탐색 창에서 **Distributor**를 선택합니다.
1. Distributor 홈페이지에서 다른 버전을 추가할 패키지와 **Add version(버전 추가)**를 차례대로 선택합니다.
1. **Version name(버전 이름)**에 매니페스트 파일의 `version` 항목에 있는 값을 입력합니다.
1. **S3 버킷 이름**의 목록에서 기존 S3 버킷을 선택합니다. 이전 버전에서 설치 파일을 저장했던 버킷을 그대로 선택할 수도 있지만 이때는 버킷에 저장된 기존 설치 파일을 덮어쓰지 않도록 설치 파일 이름이 달라야 합니다.
1. **S3 키 접두사**에 설치 가능한 자산이 저장되는 버킷의 하위 폴더를 입력합니다.
1. .zip 파일과 함께 S3 버킷에 업로드한 매니페스트를 사용하려면 **Manifest(매니페스트)**에서 **Extract from package(패키지에서 추출)**를 선택합니다.
(옵션) .zip 파일이 저장된 Amazon S3 버킷에 수정된 JSON 매니페스트를 업로드하지 않았다면 [**새 매니페스트(New manifest)**]를 선택합니다. JSON 편집기 필드에서 전체 매니페스트를 작성하거나 붙여넣을 수 있습니다. JSON 매니페스트를 생성하는 자세한 방법은 [2단계: JSON 패키지 매니페스트 생성](distributor-working-with-packages-create.md#packages-manifest) 섹션을 참조하세요.
1. 매니페스트 작성을 마치면 [**패키지 버전 추가(Add package version)**]를 선택합니다.
1. 패키지 **세부 정보** 페이지의 **버전** 탭에서 사용 가능한 패키지 버전 목록의 새 버전을 확인합니다. 버전을 추가한 다음 **기본 버전 설정**을 선택하여 패키지의 기본 버전을 설정합니다.
기본 버전을 설정하지 않으면 최신 패키지 버전이 기본 버전입니다.
## AWS CLI를 사용한 패키지 버전 추가
AWS CLI을 사용하여 Distributor에 새 패키지 버전을 추가할 수 있습니다. 이러한 명령을 실행하기 전에 이 주제 시작 부분에서 설명한 것처럼 새 패키지 버전을 생성해 S3에 업로드해야 합니다.
**AWS CLI를 사용하여 패키지 버전을 추가하려면**
1. 다음 명령을 실행하여 새 패키지 버전에 대한 항목으로 AWS Systems Manager 문서를 편집합니다. *document-name*을 문서 이름으로 바꿉니다. *amzn-s3-demo-bucket*을 [3단계: Amazon S3 버킷에 패키지 및 매니페스트 업로드](distributor-working-with-packages-create.md#packages-upload-s3)에서 복사한 JSON 매니페스트의 URL로 바꿉니다. *S3-bucket-URL-of-package*는 전체 패키지가 저장된 Amazon S3 버킷의 URL입니다. *version-name-from-updated-manifest*를 매니페스트의 `version` 값으로 바꿉니다. `--document-version` 파라미터를 `$LATEST`로 설정해 이 패키지 버전과 연결된 문서를 최신 버전 문서로 지정합니다.
```
aws ssm update-document \
--name "document-name" \
--content "S3-bucket-URL-to-manifest-file" \
--attachments Key="SourceUrl",Values="amzn-s3-demo-bucket" \
--version-name version-name-from-updated-manifest \
--document-version $LATEST
```
다음은 예입니다.
```
aws ssm update-document \
--name ExamplePackage \
--content "https://s3.amazonaws.com/amzn-s3-demo-bucket/ExamplePackage/manifest.json" \
--attachments Key="SourceUrl",Values="https://s3.amazonaws.com/amzn-s3-demo-bucket/ExamplePackage" \
--version-name 1.1.1 \
--document-version $LATEST
```
1. 다음 명령을 실행하여 패키지가 업데이트되었는지 확인하고 패키지 매니페스트를 표시합니다. *package-name*은 패키지의 이름으로 바꾸고, 경우에 따라 *document-version*은 업데이트한 문서의 버전 번호(패키지 버전과 다름)로 바꿉니다. 이 패키지 버전이 문서의 최신 버전과 연결된 경우 선택적 `--document-version` 파라미터의 값에 대해 `$LATEST`를 지정할 수 있습니다.
```
aws ssm get-document \
--name "package-name" \
--document-version "document-version"
```
**update-document** 명령과 함께 사용할 수 있는 다른 옵션에 대한 자세한 내용은 *AWS CLI Command Reference*의 AWS Systems Manager 섹션에 있는 [https://docs.aws.amazon.com/cli/latest/reference/ssm/update-document.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/update-document.html)를 참조하세요.
# Distributor 패키지 설치 또는 업데이트
AWS Systems Manager의 도구인 Distributor를 사용하여 AWS Systems Manager 관리형 노드에 패키지를 배포할 수 있습니다. 패키지를 배포하려면 AWS Management Console 또는 AWS Command Line Interface(AWS CLI)를 사용합니다. 명령당 한 패키지의 버전을 하나만 배포할 수 있습니다. 새 패키지를 설치하거나 기존 설치를 인플레이스 업데이트할 수 있습니다. 특정 버전을 배포하도록 선택하거나 항상 패키지의 최신 버전을 배포하도록 선택할 수 있습니다. AWS Systems Manager의 도구인 State Manager를 사용하여 패키지를 설치하는 것이 좋습니다. State Manager를 사용하면 관리형 노드에서 항상 최신 버전의 패키지를 실행하도록 할 수 있습니다.
**중요**
Distributor를 사용하여 설치하는 패키지는 Distributor를 사용하여 제거해야 합니다. 그렇지 않으면 Systems Manager가 애플리케이션을 `INSTALLED` 상태로 등록하고, 이로 인해 의도하지 않은 결과가 발생할 수 있습니다.
| 기본 설정 | AWS Systems Manager 작업 | 추가 정보 |
| --- | --- | --- |
| 패키지를 즉시 설치하거나 업데이트합니다. | Run Command | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/systems-manager/latest/userguide/distributor-working-with-packages-deploy.html) |
| 설치에 항상 기본 버전이 포함되도록 정기적으로 패키지를 설치 또는 업데이트합니다. | State Manager | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/systems-manager/latest/userguide/distributor-working-with-packages-deploy.html) |
| 특정 태그 또는 태그 세트가 있는 새 관리형 노드에 패키지를 자동으로 설치합니다. 예를 들어 새 인스턴스에 Amazon CloudWatch 에이전트를 설치합니다. | State Manager | 이렇게 하기 위한 한 가지 방법은 새 인스턴스에 태그를 적용한 다음 State Manager 연결에서 해당 태그를 대상으로 지정하는 것입니다. 그러면 State Manager 태그가 일치하는 인스턴스에서 연결에 패키지를 자동으로 설치합니다. [State Manager 연결에서의 대상 및 속도 제어 이해](systems-manager-state-manager-targets-and-rate-controls.md)을(를) 참조하세요. |
**Topics**
+ [콘솔을 사용하여 패키지 한 번 설치 또는 업데이트](#distributor-deploy-pkg-console)
+ [콘솔을 사용하여 패키지 설치 또는 업데이트 예약](#distributor-deploy-sm-pkg-console)
+ [AWS CLI를 사용한 패키지 한 번 설치](#distributor-deploy-pkg-cli)
+ [AWS CLI를 사용한 패키지 한 번 업데이트](#distributor-update-pkg-cli)
+ [AWS CLI를 사용한 패키지 설치 예약](#distributor-smdeploy-pkg-cli)
+ [AWS CLI를 사용한 패키지 업데이트 예약](#distributor-smupdate-pkg-cli)
## 콘솔을 사용하여 패키지 한 번 설치 또는 업데이트
AWS Systems Manager 콘솔을 사용하여 패키지를 한 번만 설치 또는 업데이트할 수 있습니다. 일회성 설치를 구성하는 경우 Distributor는 AWS Systems Manager의 도구인 [AWS Systems Manager Run Command](run-command.md)를 사용하여 설치를 수행합니다.
**콘솔을 사용하여 패키지를 한 번 설치하거나 업데이트하려면**
1. [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)에서 AWS Systems Manager 콘솔을 엽니다.
1. 탐색 창에서 **Distributor**를 선택합니다.
1. Distributor 홈 페이지에서 설치할 패키지를 선택합니다.
1. **Install one time(한 번만 설치)**을 선택합니다.
이 명령은 Run Command를 열며, 명령 문서 `AWS-ConfigureAWSPackage` 및 Distributor 패키지가 이미 선택되어 있습니다.
1. **문서 버전**에서 실행할 `AWS-ConfigureAWSPackage` 문서의 버전을 선택합니다.
1. **작업**에서 **설치**를 선택합니다.
1. **Installation type(설치 유형)**에서 다음 중 하나를 선택합니다.
+ **Uninstall and reinstall(제거 및 재설치)**: 패키지가 완전히 제거되었다가 다시 설치됩니다. 재설치가 완료될 때까지 애플리케이션을 사용할 수 없습니다.
+ [**인플레이스 업데이트(In-place update)**]: `update` 스크립트에서 제공한 지침에 따라 새 파일이나 변경된 파일만 기존 설치에 추가됩니다. 애플리케이션은 업데이트 프로세스 전체에서 사용할 수 있습니다. 이 옵션은 `AWSEC2Launch-Agent` 패키지를 제외한 AWS 게시 패키지에 대해 지원되지 않습니다.
1. **이름**에 선택한 패키지 이름이 입력되었는지 확인합니다.
1. (선택 사항) **버전**에 패키지의 버전 이름 값을 입력합니다. 이 필드를 비워 두면 Run Command에서는 Distributor에서 선택한 기본 버전을 설치합니다.
1. **대상** 섹션에서, 태그를 지정하거나, 수동으로 관리형 노드를 선택하거나, 리소스 그룹을 지정하여 이 작업을 실행할 인스턴스 또는 장치를 식별합니다.
**참고**
목록에 관리형 노드가 표시되지 않은 경우에는 [관리형 노드 가용성 문제 해결](fleet-manager-troubleshooting-managed-nodes.md) 섹션을 참조하세요.
1. **Other parameters**(다른 파라미터):
+ **Comment**(설명)에 명령에 대한 정보를 입력합니다.
+ **제한 시간(초)**에서 전체 명령 실행이 실패할 때까지 시스템이 기다리는 시간을 초 단위로 지정합니다.
1. **속도 제어(Rate control)**에서:
+ **동시성(Concurrency)**에서 명령을 동시에 실행할 대상의 백분율 또는 개수를 지정합니다.
**참고**
태그나 리소스 그룹을 지정하여 대상을 선택하였지만 대상으로 지정할 관리형 노드 수를 잘 모를 경우에는 백분율을 지정하여 동시에 문서를 실행할 수 있는 대상의 수를 제한합니다.
+ **오류 임계값**에서, 명령이 관리형 노드의 개수 또는 백분율에서 실패한 후 다른 대상에서 해당 명령의 실행을 중지할 시간을 지정합니다. 예를 들어 세 오류를 지정하면 네 번째 오류를 받았을 때 Systems Manager가 명령 전송을 중지합니다. 여전히 명령을 처리 중인 관리형 노드도 오류를 전송할 수 있습니다.
1. (선택 사항) **Output options**(출력 옵션)에서 명령 출력을 파일에 저장하려면 **Write command output to an S3 bucket**(S3 버킷에 명령 출력 쓰기) 상자를 선택합니다. 상자에 버킷 및 접두사(폴더) 이름을 입력합니다.
**참고**
데이터를 S3 버킷에 쓰는 기능을 부여하는 S3 권한은 이 작업을 수행하는 IAM 사용자의 권한이 아니라 인스턴스에 할당된 인스턴스 프로파일(EC2 인스턴스용) 또는 IAM 서비스 역할(하이브리드 정품 인증 시스템)의 권한입니다. 자세한 내용은 [Systems Manager에 필요한 인스턴스 권한 구성](setup-instance-permissions.md)이나 [하이브리드 환경을 위한 IAM 서비스 역할 생성](hybrid-multicloud-service-role.md)을 참조하세요. 또한 지정된 S3 버킷이 다른 AWS 계정에 있는 경우 관리형 노드와 연결된 인스턴스 프로파일 또는 IAM 서비스 역할은 해당 버킷에 쓸 수 있는 권한이 있어야 합니다.
1. **SNS notifications**(SNS 알림) 섹션에서, 명령 실행 상태에 대한 알림이 전송되도록 하려면 **Enable SNS notifications**(SNS 알림 활성화) 확인란을 선택합니다.
Run Command에 대한 Amazon SNS 알림 구성에 대한 자세한 내용은 [Amazon SNS 알림을 사용하여 Systems Manager 상태 변경 모니터링](monitoring-sns-notifications.md) 섹션을 참조하세요.
1. 패키지를 설치할 준비가 되면 [**실행(Run)**]을 선택합니다.
1. **Command status(명령 상태)** 영역은 실행 진행률을 보고합니다. 명령이 계속 진행 중인 경우 **Overall status(전체 상태)** 또는 **세부 상태** 열에 **성공** 또는 **실패**가 표시될 때까지 콘솔의 왼쪽 위 모서리에 있는 새로 고침 아이콘을 선택합니다.
1. **대상 및 출력(Targets and output)** 영역에서 관리형 노드 이름 옆에 있는 버튼을 선택한 후 **출력 보기(View output)**를 선택합니다.
명령 출력 페이지에 명령 실행 결과가 표시됩니다.
1. (옵션) Amazon S3 버킷에 명령 출력을 쓰도록 선택한 경우 출력 로그 데이터를 볼 수 있도록 [**Amazon S3**]를 선택합니다.
## 콘솔을 사용하여 패키지 설치 또는 업데이트 예약
AWS Systems Manager 콘솔을 사용하여 패키지 설치 또는 업데이트를 예약할 수 있습니다. 패키지 설치 또는 업데이트를 예약할 때 Distributor는 [AWS Systems Manager State Manager](systems-manager-state.md)을 사용해 설치 또는 업데이트합니다.
**콘솔을 사용하여 패키지 설치를 예약하려면**
1. [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)에서 AWS Systems Manager 콘솔을 엽니다.
1. 탐색 창에서 **Distributor**를 선택합니다.
1. Distributor 홈 페이지에서 설치 또는 업데이트할 패키지를 선택합니다.
1. **Package(패키지)**에서 **Install on a schedule(일정에 따라 설치)**을 선택합니다.
이 명령은 자동으로 생성된 새 연결에 대한 State Manager를 엽니다.
1. **이름**에 이름(예: **Deploy-test-agent-package**)을 입력합니다. 이는 선택 사항이며, 권장 사항은 아닙니다. 공백은 이름에 사용할 수 없습니다.
1. **문서** 목록에는 문서 이름 `AWS-ConfigureAWSPackage`가 이미 선택되어 있습니다.
1. **작업**에서 **설치**가 선택되어 있는지 확인합니다.
1. **Installation type(설치 유형)**에서 다음 중 하나를 선택합니다.
+ **Uninstall and reinstall(제거 및 재설치)**: 패키지가 완전히 제거되었다가 다시 설치됩니다. 재설치가 완료될 때까지 애플리케이션을 사용할 수 없습니다.
+ [**인플레이스 업데이트(In-place update)**]: `update` 스크립트에서 제공한 지침에 따라 새 파일이나 변경된 파일만 기존 설치에 추가됩니다. 애플리케이션은 업데이트 프로세스 전체에서 사용할 수 있습니다.
1. **이름**에 패키지 이름이 입력되었는지 확인합니다.
1. 최신 게시 버전 이외의 패키지 버전을 설치하려면 **버전**에 버전 식별자를 입력합니다.
1. **대상**에서 **이 계정의 모든 관리형 인스턴스 선택**, **태그 지정** 또는 **수동으로 인스턴스 선택**을 선택합니다. 태그를 사용하여 리소스 대상을 지정하는 경우 제공된 필드에 태그 키 및 태그 값을 입력합니다.
**참고**
**이 계정의 모든 관리형 인스턴스 선택** 또는 **인스턴스 수동 선택** 중 하나를 통해 관리형 AWS IoT Greengrass 코어 디바이스를 선택할 수 있습니다.
1. **일정 지정**에서 정기적으로 연결을 실행하려면 **일정이 있을 때**를, 연결을 한 번만 실행하려면 **일정이 없을 때**를 선택합니다. 이러한 옵션에 대한 자세한 내용은 [Systems Manager에서 연결 작업](state-manager-associations.md) 섹션을 참조하세요. 컨트롤을 사용하여 `cron` 또는 연결에 대한 일정을 생성합니다.
1. **연결 생성**을 선택합니다.
1. **연결** 페이지에서 생성된 연결 옆에 있는 단추를 선택한 다음, **지금 연결 적용**을 선택합니다.
State Manager는 지정된 대상에 대해 연결을 생성하고 즉시 실행합니다. 실행 중인 연결의 결과에 대한 자세한 내용은 이 설명서의 [Systems Manager에서 연결 작업](state-manager-associations.md) 섹션을 참조하세요.
**고급 옵션**, **비율 제어(Rate control)** 및 **출력 옵션(Output options)**에서의 옵션 작업에 대한 자세한 내용은 [Systems Manager에서 연결 작업](state-manager-associations.md) 섹션을 참조하세요.
## AWS CLI를 사용한 패키지 한 번 설치
AWS CLI에서 **send-command**를 실행하여 Distributor 패키지를 한 번 설치할 수 있습니다. 패키지가 이미 설치되어 있으면 패키지가 제거되고 새 버전이 설치되는 동안 애플리케이션이 오프라인으로 전환됩니다.
**AWS CLI를 사용하여 패키지를 한 번 설치하려면**
+ AWS CLI에서 다음과 같은 명령을 실행합니다.
```
aws ssm send-command \
--document-name "AWS-ConfigureAWSPackage" \
--instance-ids "instance-IDs" \
--parameters '{"action":["Install"],"installationType":["Uninstall and reinstall"],"name":["package-name (in same account) or package-ARN (shared from different account)"]}'
```
**참고**
`installationType`에 대한 기본 동작은 `Uninstall and reinstall`입니다. 전체 패키지를 설치할 때 이 명령에서 `"installationType":["Uninstall and reinstall"]`을 생략할 수 있습니다.
다음은 예입니다.
```
aws ssm send-command \
--document-name "AWS-ConfigureAWSPackage" \
--instance-ids "i-00000000000000" \
--parameters '{"action":["Install"],"installationType":["Uninstall and reinstall"],"name":["ExamplePackage"]}'
```
**send-command** 명령과 함께 사용할 수 있는 다른 옵션에 대한 자세한 내용은 *AWS CLI Command Reference*의 AWS Systems Manager 섹션에 있는 [https://docs.aws.amazon.com/cli/latest/reference/ssm/send-command.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/send-command.html)를 참조하세요.
## AWS CLI를 사용한 패키지 한 번 업데이트
AWS CLI에서 **send-command**을 실행하면 관련 애플리케이션을 오프라인으로 전환하지 않고 Distributor 패키지를 업데이트할 수 있습니다. 패키지의 새 파일이나 업데이트된 파일만 바뀝니다.
**AWS CLI를 사용하여 패키지를 한 번 업데이트하려면**
+ AWS CLI에서 다음과 같은 명령을 실행합니다.
```
aws ssm send-command \
--document-name "AWS-ConfigureAWSPackage" \
--instance-ids "instance-IDs" \
--parameters '{"action":["Install"],"installationType":["In-place update"],"name":["package-name (in same account) or package-ARN (shared from different account)"]}'
```
**참고**
새 파일이나 변경된 파일을 추가할 때는 명령에 `"installationType":["In-place update"]`를 포함해야 합니다.
다음은 예입니다.
```
aws ssm send-command \
--document-name "AWS-ConfigureAWSPackage" \
--instance-ids "i-02573cafcfEXAMPLE" \
--parameters '{"action":["Install"],"installationType":["In-place update"],"name":["ExamplePackage"]}'
```
**send-command** 명령과 함께 사용할 수 있는 다른 옵션에 대한 자세한 내용은 *AWS CLI Command Reference*의 AWS Systems Manager 섹션에 있는 [https://docs.aws.amazon.com/cli/latest/reference/ssm/send-command.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/send-command.html)를 참조하세요.
## AWS CLI를 사용한 패키지 설치 예약
AWS CLI에서 **create-association**을 실행하여 일정에 따라 Distributor 패키지를 설치할 수 있습니다. `--name` 값 즉, 문서 이름은 항상 `AWS-ConfigureAWSPackage`입니다. 다음 명령은 키 `InstanceIds`를 사용하여 대상 관리형 노드를 지정합니다. 패키지가 이미 설치되어 있으면 패키지가 제거되고 새 버전이 설치되는 동안 애플리케이션이 오프라인으로 전환됩니다.
```
aws ssm create-association \
--name "AWS-ConfigureAWSPackage" \
--parameters '{"action":["Install"],"installationType":["Uninstall and reinstall"],"name":["package-name (in same account) or package-ARN (shared from different account)"]}' \
--targets [{\"Key\":\"InstanceIds\",\"Values\":[\"instance-ID1\",\"instance-ID2\"]}]
```
**참고**
`installationType`에 대한 기본 동작은 `Uninstall and reinstall`입니다. 전체 패키지를 설치할 때 이 명령에서 `"installationType":["Uninstall and reinstall"]`을 생략할 수 있습니다.
다음은 예입니다.
```
aws ssm create-association \
--name "AWS-ConfigureAWSPackage" \
--parameters '{"action":["Install"],"installationType":["Uninstall and reinstall"],"name":["Test-ConfigureAWSPackage"]}' \
--targets [{\"Key\":\"InstanceIds\",\"Values\":[\"i-02573cafcfEXAMPLE\",\"i-0471e04240EXAMPLE\"]}]
```
**create-association** 명령과 함께 사용할 수 있는 다른 옵션에 대한 자세한 내용은 *AWS CLI Command Reference*의 AWS Systems Manager 섹션에 있는 [https://docs.aws.amazon.com/cli/latest/reference/ssm/create-association.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/create-association.html)를 참조하세요.
## AWS CLI를 사용한 패키지 업데이트 예약
AWS CLI에서 **create-association**을 실행하면 관련 애플리케이션을 오프라인으로 전환하지 않고 일정에 따라 Distributor 패키지를 업데이트할 수 있습니다. 패키지의 새 파일이나 업데이트된 파일만 바뀝니다. `--name` 값 즉, 문서 이름은 항상 `AWS-ConfigureAWSPackage`입니다. 다음 명령은 키 `InstanceIds`를 사용하여 대상 인스턴스를 지정합니다.
```
aws ssm create-association \
--name "AWS-ConfigureAWSPackage" \
--parameters '{"action":["Install"],"installationType":["In-place update"],"name":["package-name (in same account) or package-ARN (shared from different account)"]}' \
--targets [{\"Key\":\"InstanceIds\",\"Values\":[\"instance-ID1\",\"instance-ID2\"]}]
```
**참고**
새 파일이나 변경된 파일을 추가할 때는 명령에 `"installationType":["In-place update"]`를 포함해야 합니다.
다음은 예입니다.
```
aws ssm create-association \
--name "AWS-ConfigureAWSPackage" \
--parameters '{"action":["Install"],"installationType":["In-place update"],"name":["Test-ConfigureAWSPackage"]}' \
--targets [{\"Key\":\"InstanceIds\",\"Values\":[\"i-02573cafcfEXAMPLE\",\"i-0471e04240EXAMPLE\"]}]
```
**create-association** 명령과 함께 사용할 수 있는 다른 옵션에 대한 자세한 내용은 *AWS CLI Command Reference*의 AWS Systems Manager 섹션에 있는 [https://docs.aws.amazon.com/cli/latest/reference/ssm/create-association.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/create-association.html)를 참조하세요.
# Distributor 패키지 제거
AWS Management Console 또는 AWS Command Line Interface(AWS CLI)를 사용하여 Run Command로 AWS Systems Manager 관리형 노드에서 Distributor 패키지를 제거할 수 있습니다. Distributor와 Run Command는 AWS Systems Manager의 도구입니다. 이 릴리스에서는 명령당 패키지 하나의 버전을 하나씩만 제거할 수 있습니다. 특정 버전이나 기본 버전을 제거할 수 있습니다.
**중요**
Distributor를 사용하여 설치하는 패키지는 Distributor를 사용하여 제거해야 합니다. 그렇지 않으면 Systems Manager가 애플리케이션을 `INSTALLED` 상태로 등록하고, 이로 인해 의도하지 않은 결과가 발생할 수 있습니다.
**Topics**
+ [콘솔을 사용한 패키지 제거](#distributor-pkg-uninstall-console)
+ [AWS CLI를 사용한 패키지 제거](#distributor-pkg-uninstall-cli)
## 콘솔을 사용한 패키지 제거
Systems Manager 콘솔에서 Run Command을 사용하여 패키지를 한 번 제거할 수 있습니다. Distributor에서는 [AWS Systems Manager Run Command](run-command.md)를 사용하여 패키지를 제거합니다.
**콘솔을 사용하여 패키지를 제거하려면**
1. [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)에서 AWS Systems Manager 콘솔을 엽니다.
1. 탐색 창에서 **Run Command**를 선택합니다.
1. Run Command 홈 페이지에서 [**Run command**]를 선택합니다.
1. `AWS-ConfigureAWSPackage` 명령 문서를 선택합니다.
1. **작업**에서 **제거**를 선택합니다.
1. **이름**에 제거하려는 패키지 이름을 입력합니다.
1. **대상(Target)**에서 관리형 노드를 대상으로 지정하는 방식을 선택합니다. 대상에서 공유하는 태그 키와 값을 지정할 수 있습니다. ID, 플랫폼 및 SSM Agent 버전 같은 속성을 선택하여 대상을 지정할 수도 있습니다.
1. 고급 옵션을 사용하여 작업에 대한 설명을 추가하거나, [**속도 제어(Rate control)**]에서 [**동시성(Concurrency)**] 및 [**Error threshold(오류 임계값)**] 변경하거나, 출력 옵션을 지정하거나, Amazon Simple Notification Service(Amazon SNS) 알림을 구성할 수 있습니다. 자세한 내용은 이 설명서의 [콘솔에서 명령 실행](https://docs.aws.amazon.com/systems-manager/latest/userguide/rc-console.html)을 참조하십시오.
1. 패키지를 제거할 준비가 되면 [**실행(Run)**]을 선택한 후 [**결과 보기(View results)**]를 선택합니다.
1. 명령 목록에서 실행한 `AWS-ConfigureAWSPackage` 명령을 선택합니다. 명령이 아직 진행 중인 경우 콘솔 오른쪽 위 모서리의 새로 고침 아이콘을 선택합니다.
1. **상태(Status)** 열에 **성공(Success)** 또는 **실패(Failed)**가 표시되면 **출력(Output)** 탭을 선택합니다.
1. [**출력 보기(View output)**]를 선택합니다. 명령 출력 페이지에 명령 실행 결과가 표시됩니다.
## AWS CLI를 사용한 패키지 제거
AWS CLI에서 Run Command를 사용하여 관리형 노드에서 Distributor 패키지를 제거할 수 있습니다.
**AWS CLI를 사용하여 패키지를 제거하려면**
+ AWS CLI에서 다음과 같은 명령을 실행합니다.
```
aws ssm send-command \
--document-name "AWS-ConfigureAWSPackage" \
--instance-ids "instance-IDs" \
--parameters '{"action":["Uninstall"],"name":["package-name (in same account) or package-ARN (shared from different account)"]}'
```
다음은 예입니다.
```
aws ssm send-command \
--document-name "AWS-ConfigureAWSPackage" \
--instance-ids "i-02573cafcfEXAMPLE" \
--parameters '{"action":["Uninstall"],"name":["Test-ConfigureAWSPackage"]}'
```
**send-command** 명령과 함께 사용할 수 있는 다른 옵션에 대한 자세한 내용은 *AWS CLI Command Reference*의 AWS Systems Manager 섹션에 있는 [https://docs.aws.amazon.com/cli/latest/reference/ssm/send-command.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/send-command.html)를 참조하세요.
# Distributor 패키지 삭제
이 섹션은 패키지를 삭제하는 방법을 설명합니다. 패키지 버전은 삭제할 수 없으며 전체 패키지만 삭제할 수 있습니다.
## 콘솔을 사용한 패키지 삭제
AWS Systems Manager 콘솔을 사용하여 AWS Systems Manager의 도구인 Distributor에서 패키지 또는 패키지 버전을 삭제할 수 있습니다. 이 패키지를 삭제하면 Distributor에서 모든 패키지 버전이 삭제됩니다.
**콘솔을 사용하여 패키지를 삭제하려면**
1. [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)에서 AWS Systems Manager 콘솔을 엽니다.
1. 탐색 창에서 **Distributor**를 선택합니다.
1. **Distributor** 홈 페이지에서 삭제할 패키지를 선택합니다.
1. 패키지 세부 정보 페이지에서 **패키지 삭제**를 선택합니다.
1. 삭제를 확인하라는 메시지가 표시되면 [**패키지 삭제(Delete package)**]를 선택합니다.
## 콘솔을 사용한 패키지 버전 삭제
Systems Manager 콘솔을 사용하여 Distributor에서 패키지 버전을 삭제할 수 있습니다.
**콘솔을 사용하여 패키지 버전을 삭제하려면**
1. [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)에서 AWS Systems Manager 콘솔을 엽니다.
1. 탐색 창에서 **Distributor**를 선택합니다.
1. **Distributor** 홈 페이지에서 삭제할 패키지 버전을 선택합니다.
1. 패키지의 버전 페이지에서 삭제할 버전을 선택하고 **버전 삭제**를 선택합니다.
1. 삭제를 확인하라는 메시지가 표시되면 [**패키지 버전 삭제(Delete package version)**]를 선택합니다.
## 명령줄을 사용한 패키지 삭제
선호하는 명령줄 도구를 사용하여 Distributor에서 패키지를 삭제할 수 있습니다.
------
#### [ Linux & macOS ]
**AWS CLI를 사용하여 패키지를 삭제하려면**
1. 다음 명령을 실행하여 특정 패키지에 대한 문서를 나열합니다. 이 명령의 결과에서 삭제하려는 패키지를 찾습니다.
```
aws ssm list-documents \
--filters Key=Name,Values=package-name
```
1. 다음 명령을 실행하여 패키지를 삭제합니다. *package-name*을 패키지 파일 이름으로 바꿉니다.
```
aws ssm delete-document \
--name "package-name"
```
1. **list-documents** 명령을 다시 실행하여 패키지가 삭제되었는지 확인합니다. 삭제한 패키지가 목록에 포함되어서는 안 됩니다.
```
aws ssm list-documents \
--filters Key=Name,Values=package-name
```
------
#### [ Windows ]
**AWS CLI를 사용하여 패키지를 삭제하려면**
1. 다음 명령을 실행하여 특정 패키지에 대한 문서를 나열합니다. 이 명령의 결과에서 삭제하려는 패키지를 찾습니다.
```
aws ssm list-documents ^
--filters Key=Name,Values=package-name
```
1. 다음 명령을 실행하여 패키지를 삭제합니다. *package-name*을 패키지 파일 이름으로 바꿉니다.
```
aws ssm delete-document ^
--name "package-name"
```
1. **list-documents** 명령을 다시 실행하여 패키지가 삭제되었는지 확인합니다. 삭제한 패키지가 목록에 포함되어서는 안 됩니다.
```
aws ssm list-documents ^
--filters Key=Name,Values=package-name
```
------
#### [ PowerShell ]
**Tools for PowerShell을 사용하여 패키지를 삭제하려면**
1. 다음 명령을 실행하여 특정 패키지에 대한 문서를 나열합니다. 이 명령의 결과에서 삭제하려는 패키지를 찾습니다.
```
$filter = New-Object Amazon.SimpleSystemsManagement.Model.DocumentKeyValuesFilter
$filter.Key = "Name"
$filter.Values = "package-name"
Get-SSMDocumentList `
-Filters @($filter)
```
1. 다음 명령을 실행하여 패키지를 삭제합니다. *package-name*을 패키지 파일 이름으로 바꿉니다.
```
Remove-SSMDocument `
-Name "package-name"
```
1. **Get-SSMDocumentList** 명령을 다시 실행하여 패키지가 삭제되었는지 확인합니다. 삭제한 패키지가 목록에 포함되어서는 안 됩니다.
```
$filter = New-Object Amazon.SimpleSystemsManagement.Model.DocumentKeyValuesFilter
$filter.Key = "Name"
$filter.Values = "package-name"
Get-SSMDocumentList `
-Filters @($filter)
```
------
## 명령줄을 사용한 패키지 버전 삭제
선호하는 명령줄 도구를 사용하여 Distributor에서 패키지 버전을 삭제할 수 있습니다.
------
#### [ Linux & macOS ]
**AWS CLI를 사용하여 패키지 버전을 삭제하려면**
1. 다음 명령을 실행하여 패키지 버전을 나열합니다. 이 명령의 결과에서 삭제하려는 패키지 버전을 찾습니다.
```
aws ssm list-document-versions \
--name "package-name"
```
1. 다음 명령을 실행하여 패키지 버전을 삭제합니다. *package-name*을 패키지 이름으로 바꾸고 *version*을 버전 번호로 바꿉니다.
```
aws ssm delete-document \
--name "package-name" \
--document-version version
```
1. **list-document-versions** 명령을 실행하여 패키지 버전이 삭제되었는지 확인합니다. 삭제한 패키지 버전은 검색되지 않아야 합니다.
```
aws ssm list-document-versions \
--name "package-name"
```
------
#### [ Windows ]
**AWS CLI를 사용하여 패키지 버전을 삭제하려면**
1. 다음 명령을 실행하여 패키지 버전을 나열합니다. 이 명령의 결과에서 삭제하려는 패키지 버전을 찾습니다.
```
aws ssm list-document-versions ^
--name "package-name"
```
1. 다음 명령을 실행하여 패키지 버전을 삭제합니다. *package-name*을 패키지 이름으로 바꾸고 *version*을 버전 번호로 바꿉니다.
```
aws ssm delete-document ^
--name "package-name" ^
--document-version version
```
1. **list-document-versions** 명령을 실행하여 패키지 버전이 삭제되었는지 확인합니다. 삭제한 패키지 버전은 검색되지 않아야 합니다.
```
aws ssm list-document-versions ^
--name "package-name"
```
------
#### [ PowerShell ]
**Tools for PowerShell을 사용하여 패키지 버전을 삭제하려면**
1. 다음 명령을 실행하여 패키지 버전을 나열합니다. 이 명령의 결과에서 삭제하려는 패키지 버전을 찾습니다.
```
Get-SSMDocumentVersionList `
-Name "package-name"
```
1. 다음 명령을 실행하여 패키지 버전을 삭제합니다. *package-name*을 패키지 이름으로 바꾸고 *version*을 버전 번호로 바꿉니다.
```
Remove-SSMDocument `
-Name "package-name" `
-DocumentVersion version
```
1. **Get-SSMDocumentVersionList** 명령을 실행하여 패키지 버전이 삭제되었는지 확인합니다. 삭제한 패키지 버전은 검색되지 않아야 합니다.
```
Get-SSMDocumentVersionList `
-Name "package-name"
```
------
**list-documents** 명령과 함께 사용할 수 있는 다른 옵션에 대한 자세한 내용은 *AWS CLI Command Reference*의 AWS Systems Manager 섹션에 있는 [https://docs.aws.amazon.com/cli/latest/reference/ssm/list-documents.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/list-documents.html)를 참조하세요. **delete-document** 명령과 함께 사용할 수 있는 다른 옵션에 대한 자세한 내용은 [https://docs.aws.amazon.com/cli/latest/reference/ssm/delete-document.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/delete-document.html)를 참조하세요.
# Distributor 활동 감사 및 로깅
AWS CloudTrail을 사용하여 AWS Systems Manager의 도구인 Distributor와 관련된 활동을 감사할 수 있습니다. Systems Manager에 대한 자세한 감사 및 로깅 옵션은 [AWS Systems Manager에서 로깅 및 모니터링](monitoring.md) 섹션을 참조하세요.
## CloudTrail을 사용하여 Distributor 활동 감사
CloudTrail에서는 AWS Systems Manager 콘솔, AWS Command Line Interface(AWS CLI) 및 Systems Manager SDK에서 수행된 API 호출을 캡처합니다. CloudTrail 콘솔에서 정보를 보거나 Amazon Simple Storage Service(Amazon S3) 버킷에 정보를 저장할 수 있습니다. 계정에 대한 모든 CloudTrail 로그를 저장하는 데 버킷 하나가 사용됩니다.
Run Command 및 State Manager 작업 로그는 문서 생성, 패키지 설치 및 패키지 제거 활동을 보여줍니다. Run Command와 State Manager는 AWS Systems Manager의 도구입니다. Systems Manager 활동의 CloudTrail 로그 보기 및 사용에 대한 자세한 내용은 [AWS CloudTrail를 사용하여 AWS Systems Manager API 호출 로깅](monitoring-cloudtrail-logs.md) 섹션을 참조하세요.
# AWS Systems Manager Distributor 문제 해결
다음 정보는 AWS Systems Manager의 도구인 Distributor 사용 시 발생할 수 있는 문제를 해결하는 데 유용합니다.
**Topics**
+ [이름이 같은 잘못된 패키지가 설치됨](#distributor-tshoot-1)
+ [오류: 매니페스트를 조회하지 못함: 패키지의 최신 버전을 찾을 수 없음](#distributor-tshoot-2)
+ [오류: 매니페스트를 검색하는 데 실패함: 검증 예외](#distributor-tshoot-3)
+ [패키지가 지원되지 않음(패키지에 설치 작업이 없음)](#distributor-tshoot-4)
+ [오류: 매니페스트를 다운로드하지 못했습니다. 이름이 있는 문서가 존재하지 않습니다.](#distributor-tshoot-5)
+ [업로드에 실패했습니다.](#distributor-tshoot-6)
+ [오류: 플랫폼을 찾지 못함: 플랫폼에 대한 매니페스트를 찾을 수 없음: oracle, 버전 8.9, 아키텍처 x86\$164](#distributor-tshoot-7)
## 이름이 같은 잘못된 패키지가 설치됨
**문제:** 패키지를 설치했으나 Distributor가 대신 다른 패키지를 설치했습니다.
**원인:** 설치 중 Systems Manager에서 사용자 정의 외부 패키지보다 앞서 AWS 게시 패키지를 결과로 찾았습니다. 사용자 정의 패키지 이름이 AWS 게시 패키지 이름과 동일한 경우 사용자 패키지 대신 AWS 패키지가 설치됩니다.
**해결 방법:** 이 문제를 피하려면 패키지의 이름을 AWS 게시 패키지의 이름과 다르게 지정해야 합니다.
## 오류: 매니페스트를 조회하지 못함: 패키지의 최신 버전을 찾을 수 없음
**문제:** 다음과 같은 오류가 표시됩니다.
```
Failed to retrieve manifest: ResourceNotFoundException: Could not find the latest version of package
arn:aws:ssm:::package/package-name status code: 400, request id: guid
```
**원인:** Distributor에서 2.3.274.0 버전 이전의 SSM Agent를 사용합니다.
**솔루션:** SSM Agent 버전을 2.3.274.0 버전 이상으로 업데이트하세요. 자세한 내용은 [Run Command를 사용하여 SSM Agent 업데이트](run-command-tutorial-update-software.md#rc-console-agentexample) 또는 [연습: AWS CLI를 사용하여 SSM Agent를 자동으로 업데이트](state-manager-update-ssm-agent-cli.md) 섹션을 참조하세요.
## 오류: 매니페스트를 검색하는 데 실패함: 검증 예외
**문제:** 다음과 같은 오류가 표시됩니다.
```
Failed to retrieve manifest: ValidationException: 1 validation error detected: Value 'documentArn'
at 'packageName' failed to satisfy constraint: Member must satisfy regular expression pattern:
arn:aws:ssm:region-id:account-id:package/package-name
```
**원인:** Distributor에서 2.3.274.0 버전 이전의 SSM Agent를 사용합니다.
**솔루션:** SSM Agent 버전을 2.3.274.0 버전 이상으로 업데이트하세요. 자세한 내용은 [Run Command를 사용하여 SSM Agent 업데이트](run-command-tutorial-update-software.md#rc-console-agentexample) 또는 [연습: AWS CLI를 사용하여 SSM Agent를 자동으로 업데이트](state-manager-update-ssm-agent-cli.md) 섹션을 참조하세요.
## 패키지가 지원되지 않음(패키지에 설치 작업이 없음)
**문제:** 다음과 같은 오류가 표시됩니다.
```
Package is not supported (package is missing install action)
```
**원인:** 패키지 디렉터리 구조가 올바르지 않습니다.
**해결 방법:** 소프트웨어 및 필수 스크립트가 포함된 상위 디렉터리를 압축하지 않습니다. 대신 절대 경로에 직접 필요한 모든 콘텐츠의 `.zip` 파일을 생성합니다. `.zip` 파일이 제대로 생성되었는지 확인하려면 대상 플랫폼 디렉터리의 압축을 풀고 디렉터리 구조를 검토합니다. 예를 들어 설치 스크립트 절대 경로는 `/ExamplePackage_targetPlatform/install.sh`여야 합니다.
## 오류: 매니페스트를 다운로드하지 못했습니다. 이름이 있는 문서가 존재하지 않습니다.
**문제**: 다음과 같은 오류가 표시됩니다.
```
Failed to download manifest - failed to retrieve package document description: InvalidDocument: Document with name filename does not exist.
```
**원인 1:** 다른 계정에서 Distributor 패키지를 공유할 때 Distributor가 패키지 이름으로 패키지를 찾을 수 없습니다.
**솔루션 1:** 다른 계정에서 패키지를 공유할 때 패키지 이름뿐만 아니라 패키지의 전체 Amazon 리소스 이름(ARN)도 사용합니다.
**원인 2:** VPC를 사용할 때 대상인 AWS 리전에 대한 `AWS-ConfigureAWSPackage` 문서가 포함된 AWS 관리형 S3 버킷 액세스 권한을 IAM 인스턴스 프로파일에 제공하지 않았습니다.
**솔루션 2:** [AWS 관리형 S3 버킷과 SSM Agent 통신](ssm-agent-technical-details.md#ssm-agent-minimum-s3-permissions)에서 설명하는 것과 같이 IAM 인스턴스 프로파일이 SSM Agent에 대상인 AWS 리전에 대한 `AWS-ConfigureAWSPackage` 문서가 포함된 AWS 관리형 S3 버킷 액세스 권한을 제공하는지 확인합니다.
## 업로드에 실패했습니다.
**문제**: 다음과 같은 오류가 표시됩니다.
```
Upload failed. At least one of your files was not successfully uploaded to your S3 bucket.
```
**원인:** 소프트웨어 패키지 이름에 공백이 있습니다. 예를 들어, `Hello World.msi` 업로드에 실패할 수 있습니다.
## 오류: 플랫폼을 찾지 못함: 플랫폼에 대한 매니페스트를 찾을 수 없음: oracle, 버전 8.9, 아키텍처 x86\$164
**문제**: 다음과 같은 오류가 표시됩니다.
```
Failed to find platform: no manifest found for platform: oracle, version 8.9, architecture x86_64
```
**원인:** 오류는 JSON 패키지 매니페스트에 해당 플랫폼,이 경우 Oracle Linux에 대한 정의가 없음을 의미합니다.
**해결책:** [Trend Micro Deep Security Software](https://help.deepsecurity.trendmicro.com/software.html) 사이트에서 배포하려는 패키지를 다운로드합니다. [단순 워크플로를 사용한 패키지 생성](distributor-working-with-packages-create.md#distributor-working-with-packages-create-simple)을 사용하여 `.rpm` 소프트웨어 패키지를 생성합니다. 패키지에 대해 다음 값을 설정하고 Distributor를 사용하여 소프트웨어 패키지 업로드를 완료합니다.
```
Platform version: _any
Target platform: oracle
Architecture: x86_64
```
# AWS Systems Manager Fleet Manager
AWS Systems Manager의 도구인 Fleet Manager는 AWS 또는 온프레미스에서 실행되는 노드를 원격으로 관리하는 데 도움이 되는 통합 사용자 인터페이스(UI) 환경입니다. Fleet Manager를 사용하면 하나의 콘솔에서 전체 서버 플릿의 상태 및 성능 상태를 볼 수 있습니다. 또한 개별 노드에서 데이터를 수집하여 콘솔에서 일반적인 문제 해결 및 관리 태스크를 수행할 수 있습니다. 여기에는 원격 데스크톱 프로토콜(RDF)을 사용하여 Windows 인스턴스에 연결, 폴더 및 파일 내용 보기, Windows 레지스트리 관리, 운영 체제 사용자 관리 등이 포함됩니다.
Fleet Manager를 시작하려면 [Systems Manager 콘솔](https://console.aws.amazon.com/systems-manager/fleet-manager)을 엽니다. 탐색 창에서 **Fleet Manager**를 선택합니다.
## Fleet Manager는 누가 사용해야 하나요?
노드 플릿을 중앙 집중식으로 관리하려는 모든 AWS 고객은 Fleet Manager를 사용해야 합니다.
## Fleet Manager가 조직에 주는 이점은 무엇인가요?
Fleet Manager에서 제공하는 이점은 다음과 같습니다.
+ 관리형 노드에 수동으로 연결할 필요 없이 다양한 일반적인 시스템 관리 태스크를 수행합니다.
+ 단일 통합 콘솔에서 여러 플랫폼에서 실행되는 노드를 관리합니다.
+ 단일 통합 콘솔에서 서로 다른 운영 체제를 실행하는 노드를 관리합니다.
+ 시스템 관리의 효율성을 개선합니다.
## Fleet Manager에는 어떤 기능이 있나요?
Fleet Manager의 주요 기능은 다음과 같습니다.
+ **Red Hat Knowledgebase 포털 액세스**
Red Hat Enterprise Linux(RHEL) 인스턴스를 통해 Red Hat Knowledgebase 포털에서 바이너리, 지식 공유 및 토론 포럼에 액세스하세요.
+ **관리형 노드 상태**
어떤 관리형 인스턴스가 `running`이고 어떤 인스턴스가 `stopped`인지 봅니다. 중지된 인스턴스에 대한 자세한 내용은 *Amazon EC2 사용 설명서*의 [인스턴스 중지 및 시작](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Stop_Start.html)을 참조하세요. AWS IoT Greengrass 코어 디바이스에서 `online`, `offline`을 볼 수 있고, `Connection lost`의 상태를 표시할 수 있습니다.
**참고**
2021년 7월 12일 이전에 관리형 인스턴스를 중지한 경우 `stopped` 마커가 표시되지 않습니다. 마커를 표시하려면 인스턴스를 시작하고 중지합니다.
+ **인스턴스 정보 보기**
관리형 인스턴스에 연결된 볼륨에 저장된 폴더 및 파일 데이터에 대한 정보, 인스턴스에 대한 실시간 성능 데이터, 인스턴스에 저장된 로그 데이터에 대한 정보를 봅니다.
+ **엣지 디바이스 정보 보기**
디바이스의 AWS IoT Greengrass 사물 이름, SSM Agent ping 상태 및 버전 등을 봅니다.
+ **계정 및 레지스트리 관리**
인스턴스의 운영 체제(OS) 사용자 계정과 Windows 인스턴스의 레지스트리를 관리합니다.
+ **서비스에 대한 액세스 제어**
AWS Identity and Access Management(IAM) 정책을 사용하여 Fleet Manager 기능에 대한 액세스를 제어합니다. 이러한 정책을 통해 조직의 어떤 개별 사용자 또는 그룹이 다양한 Fleet Manager 기능을 사용할 수 있는지 그리고 어떤 관리형 노드를 관리할 수 있는지 제어할 수 있습니다.
**Topics**
+ [Fleet Manager는 누가 사용해야 하나요?](#fleet-who)
+ [Fleet Manager가 조직에 주는 이점은 무엇인가요?](#fleet-benefits)
+ [Fleet Manager에는 어떤 기능이 있나요?](#fleet-features)
+ [Fleet Manager 설정](setting-up-fleet-manager.md)
+ [관리형 노드 작업](fleet-manager-managed-nodes.md)
+ [기본 호스트 관리 구성을 사용한 자동 EC2 인스턴스 관리](fleet-manager-default-host-management-configuration.md)
+ [Remote Desktop을 사용하여 Windows Server 관리형 인스턴스에 연결](fleet-manager-remote-desktop-connections.md)
+ [관리형 인스턴스의 Amazon EBS 볼륨 관리](fleet-manager-manage-amazon-ebs-volumes.md)
+ [Red Hat Knowledge 기본 포털에 액세스](fleet-manager-red-hat-knowledge-base-access.md)
+ [관리형 노드 가용성 문제 해결](fleet-manager-troubleshooting-managed-nodes.md)
# Fleet Manager 설정
AWS 계정의 사용자가 AWS Systems Manager의 도구인 Fleet Manager를 사용하여 관리형 노드를 모니터링하고 관리하려면 먼저 필요한 권한이 부여되어야 합니다. 또한 Fleet Manager를 사용하여 모니터링 및 관리할 모든 Amazon Elastic Compute Cloud(Amazon EC2) 인스턴스, AWS IoT Greengrass 코어 디바이스, 온프레미스 서버, 엣지 디바이스, 가상 머신(VM)은 반드시 Systems Manager **관리형 노드여야 합니다. 관리형 노드는 [하이브리드 및 멀티클라우드](operating-systems-and-machine-types.md#supported-machine-types) 환경에서 Systems Manager와 함께 사용하도록 구성된 모든 시스템입니다.
즉, 노드가 특정 전제 조건을 충족하고 AWS Systems Manager 에이전트(SSM Agent)로 구성되어야 합니다.
시스템 유형에 따라 다음 항목 중 하나를 참조하여 시스템이 관리형 노드에 대한 요구 사항을 충족하는지 확인하세요.
+ Amazon EC2 인스턴스: [Systems Manager를 사용한 EC2 인스턴스 관리](systems-manager-setting-up-ec2.md)
**작은 정보**
또한 AWS Systems Manager의 도구인 Quick Setup을 사용하여 Amazon EC2 인스턴스를 개별 계정에서 관리형 인스턴스로 빠르게 구성할 수도 있습니다. 비즈니스 또는 조직이 AWS Organizations을 사용하는 경우, 여러 조직 구성 단위(OU)와 AWS 리전에 걸쳐 인스턴스를 구성할 수도 있습니다. Quick Setup을 사용하여 관리형 인스턴스 구성에 대한 자세한 내용은 [Quick Setup을 사용한 Amazon EC2 호스트 관리 설정](quick-setup-host-management.md) 섹션을 참조하세요.
+ 클라우드의 온프레미스 및 기타 서버 유형: [Systems Manager로 하이브리드 및 멀티클라우드 환경에서 노드 관리](systems-manager-hybrid-multicloud.md)
+ AWS IoT Greengrass(엣지) 디바이스: [Systems Manager를 통한 엣지 디바이스 관리](systems-manager-setting-up-edge-devices.md)
**Topics**
+ [Fleet Manager에 대한 액세스 제어](configuring-fleet-manager-permissions.md)
# Fleet Manager에 대한 액세스 제어
AWS Systems Manager의 도구인 Fleet Manager를 사용하려면 AWS Identity and Access Management(IAM) 사용자 또는 역할에 필요한 권한이 있어야 합니다. 모든 Fleet Manager 기능에 대한 액세스를 제공하는 IAM 정책을 생성하거나 선택한 기능에 대한 액세스 권한을 부여하도록 정책을 수정할 수 있습니다. 그런 다음 계정에서 이러한 권한을 사용자 또는 ID에 부여합니다.
**태스크 1: 액세스 권한을 정의하는 IAM 정책 생성**
Fleet Manager에 액세스할 수 있는 ID(사용자, 역할 또는 사용자 그룹)를 제공하기 위해 **IAM 사용 가이드의 다음 항목에 설명되어 있는 방법 중 하나를 따라 IAM을 생성할 수 있습니다.
+ [고객 관리형 정책으로 사용자 지정 IAM 권한 정의](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html)
아래에서 제공하는 샘플 정책 중 하나를 사용하거나 부여하려는 권한에 따라 수정할 수 있습니다. 전체 Fleet Manager 액세스 및 읽기 전용 액세스에 대한 샘플 정책을 제공합니다.
**태스크 2: IAM 정책을 사용자에게 연결하여 권한 부여**
Fleet Manager에 대한 액세스 권한을 정의하는 IAM 정책을 하나 이상 생성한 후에는 **IAM 사용 가이드의 다음 절차 중 하나를 사용하여 계정의 ID에 이러한 권한을 부여합니다.
+ [IAM 자격 증명 권한 추가(콘솔)](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage-attach-detach.html#add-policies-console)
+ [IAM 자격 증명 권한 추가(AWS CLI)](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage-attach-detach.html#add-policy-cli)
+ [IAM 자격 증명 권한 추가(AWS API)](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage-attach-detach.html#add-policy-api)
**Topics**
+ [Fleet Manager 관리자 액세스 정책 샘플](#admin-policy-sample)
+ [Fleet Manager 읽기 전용 액세스 정책 샘플](#read-only-policy-sample)
## Fleet Manager 관리자 액세스 정책 샘플
다음 정책은 모든 Fleet Manager 기능에 대한 권한을 제공합니다. 즉, 사용자는 로컬 사용자 및 그룹을 생성 및 삭제할 수 있으며 모든 로컬 그룹에 대한 그룹 멤버십을 수정하고 Windows Server 레지스트리 키 또는 값을 수정할 수 있습니다. 각 *example resource placeholder*를 사용자의 정보로 바꿉니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "EC2",
"Effect": "Allow",
"Action": [
"ec2:CreateTags",
"ec2:DeleteTags",
"ec2:DescribeInstances",
"ec2:DescribeTags"
],
"Resource": "*"
},
{
"Sid": "General",
"Effect": "Allow",
"Action": [
"ssm:AddTagsToResource",
"ssm:DescribeInstanceAssociationsStatus",
"ssm:DescribeInstancePatches",
"ssm:DescribeInstancePatchStates",
"ssm:DescribeInstanceProperties",
"ssm:GetCommandInvocation",
"ssm:GetServiceSetting",
"ssm:GetInventorySchema",
"ssm:ListComplianceItems",
"ssm:ListInventoryEntries",
"ssm:ListTagsForResource",
"ssm:ListCommandInvocations",
"ssm:ListAssociations",
"ssm:RemoveTagsFromResource"
],
"Resource": "*"
},
{
"Sid": "DefaultHostManagement",
"Effect": "Allow",
"Action": [
"ssm:ResetServiceSetting",
"ssm:UpdateServiceSetting"
],
"Resource": "arn:aws:ssm:us-east-1:111122223333:servicesetting/ssm/managed-instance/default-ec2-instance-management-role"
},
{
"Effect": "Allow",
"Action": [
"iam:PassRole"
],
"Resource": "arn:aws:iam::111122223333:role/service-role/AWSSystemsManagerDefaultEC2InstanceManagementRole",
"Condition": {
"StringEquals": {
"iam:PassedToService": [
"ssm.amazonaws.com"
]
}
}
},
{
"Sid": "SendCommand",
"Effect": "Allow",
"Action": [
"ssm:GetDocument",
"ssm:SendCommand",
"ssm:StartSession"
],
"Resource": [
"arn:aws:ec2:*:111122223333:instance/*",
"arn:aws:ssm:*:111122223333:managed-instance/*",
"arn:aws:ssm:*:111122223333:document/SSM-SessionManagerRunShell",
"arn:aws:ssm:*:*:document/AWS-PasswordReset",
"arn:aws:ssm:*:*:document/AWSFleetManager-AddUsersToGroups",
"arn:aws:ssm:*:*:document/AWSFleetManager-CopyFileSystemItem",
"arn:aws:ssm:*:*:document/AWSFleetManager-CreateDirectory",
"arn:aws:ssm:*:*:document/AWSFleetManager-CreateGroup",
"arn:aws:ssm:*:*:document/AWSFleetManager-CreateUser",
"arn:aws:ssm:*:*:document/AWSFleetManager-CreateUserInteractive",
"arn:aws:ssm:*:*:document/AWSFleetManager-CreateWindowsRegistryKey",
"arn:aws:ssm:*:*:document/AWSFleetManager-DeleteFileSystemItem",
"arn:aws:ssm:*:*:document/AWSFleetManager-DeleteGroup",
"arn:aws:ssm:*:*:document/AWSFleetManager-DeleteUser",
"arn:aws:ssm:*:*:document/AWSFleetManager-DeleteWindowsRegistryKey",
"arn:aws:ssm:*:*:document/AWSFleetManager-DeleteWindowsRegistryValue",
"arn:aws:ssm:*:*:document/AWSFleetManager-GetDiskInformation",
"arn:aws:ssm:*:*:document/AWSFleetManager-GetFileContent",
"arn:aws:ssm:*:*:document/AWSFleetManager-GetFileSystemContent",
"arn:aws:ssm:*:*:document/AWSFleetManager-GetGroups",
"arn:aws:ssm:*:*:document/AWSFleetManager-GetPerformanceCounters",
"arn:aws:ssm:*:*:document/AWSFleetManager-GetProcessDetails",
"arn:aws:ssm:*:*:document/AWSFleetManager-GetUsers",
"arn:aws:ssm:*:*:document/AWSFleetManager-GetWindowsEvents",
"arn:aws:ssm:*:*:document/AWSFleetManager-GetWindowsRegistryContent",
"arn:aws:ssm:*:*:document/AWSFleetManager-MountVolume",
"arn:aws:ssm:*:*:document/AWSFleetManager-MoveFileSystemItem",
"arn:aws:ssm:*:*:document/AWSFleetManager-RemoveUsersFromGroups",
"arn:aws:ssm:*:*:document/AWSFleetManager-RenameFileSystemItem",
"arn:aws:ssm:*:*:document/AWSFleetManager-SetWindowsRegistryValue",
"arn:aws:ssm:*:*:document/AWSFleetManager-StartProcess",
"arn:aws:ssm:*:*:document/AWSFleetManager-TerminateProcess"
]
},
{
"Sid": "TerminateSession",
"Effect": "Allow",
"Action": [
"ssm:TerminateSession"
],
"Resource": "*",
"Condition": {
"StringLike": {
"ssm:resourceTag/aws:ssmmessages:session-id": [
"${aws:userid}"
]
}
}
}
]
}
```
------
## Fleet Manager 읽기 전용 액세스 정책 샘플
다음 정책은 읽기 전용 Fleet Manager 기능에 대한 권한을 제공합니다. 각 *example resource placeholder*를 사용자의 정보로 바꿉니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "EC2",
"Effect": "Allow",
"Action": [
"ec2:DescribeInstances",
"ec2:DescribeTags"
],
"Resource": "*"
},
{
"Sid": "General",
"Effect": "Allow",
"Action": [
"ssm:DescribeInstanceAssociationsStatus",
"ssm:DescribeInstancePatches",
"ssm:DescribeInstancePatchStates",
"ssm:DescribeInstanceProperties",
"ssm:GetCommandInvocation",
"ssm:GetServiceSetting",
"ssm:GetInventorySchema",
"ssm:ListComplianceItems",
"ssm:ListInventoryEntries",
"ssm:ListTagsForResource",
"ssm:ListCommandInvocations",
"ssm:ListAssociations"
],
"Resource": "*"
},
{
"Sid": "SendCommand",
"Effect": "Allow",
"Action": [
"ssm:GetDocument",
"ssm:SendCommand",
"ssm:StartSession"
],
"Resource": [
"arn:aws:ec2:*:111122223333:instance/*",
"arn:aws:ssm:*:111122223333:managed-instance/*",
"arn:aws:ssm:*:111122223333:document/SSM-SessionManagerRunShell",
"arn:aws:ssm:*:*:document/AWSFleetManager-GetDiskInformation",
"arn:aws:ssm:*:*:document/AWSFleetManager-GetFileContent",
"arn:aws:ssm:*:*:document/AWSFleetManager-GetFileSystemContent",
"arn:aws:ssm:*:*:document/AWSFleetManager-GetGroups",
"arn:aws:ssm:*:*:document/AWSFleetManager-GetPerformanceCounters",
"arn:aws:ssm:*:*:document/AWSFleetManager-GetProcessDetails",
"arn:aws:ssm:*:*:document/AWSFleetManager-GetUsers",
"arn:aws:ssm:*:*:document/AWSFleetManager-GetWindowsEvents",
"arn:aws:ssm:*:*:document/AWSFleetManager-GetWindowsRegistryContent"
]
},
{
"Sid": "TerminateSession",
"Effect": "Allow",
"Action": [
"ssm:TerminateSession"
],
"Resource": "*",
"Condition": {
"StringLike": {
"ssm:resourceTag/aws:ssmmessages:session-id": [
"${aws:userid}"
]
}
}
}
]
}
```
------
# 관리형 노드 작업
**관리형 노드는 AWS Systems Manager용으로 구성된 시스템입니다. 다음과 같은 시스템 유형을 관리형 노드로 구성할 수 있습니다.
+ Amazon Elastic Compute Cloud(Amazon EC2) 인스턴스
+ 자체 프레미스의 서버(온프레미스 서버)
+ AWS IoT Greengrass 코어 디바이스
+ AWS IoT 및 비 AWS 엣지 디바이스
+ 다른 클라우드 환경의 VM을 포함한 가상 머신
Systems Manager 콘솔에서 ‘mi-’로 시작하는 시스템은 [*하이브리드 정품 인증*](activations.md)을 사용하는 관리형 노드로 구성되어 있습니다. 엣지 디바이스는 AWS IoT 사물 이름을 보여줍니다.
**참고**
macOS 인스턴스에 대해 지원되는 유일한 기능은 파일 시스템 보기입니다.
**Systems Manager 인스턴스 티어 정보**
AWS Systems Manager에서는 표준 인스턴스 티어와 고급 인스턴스 티어를 제공합니다. 둘 다 [하이브리드 및 멀티클라우드](operating-systems-and-machine-types.md#supported-machine-types) 환경에서 관리형 노드를 지원합니다. 표준 인스턴스 티어를 통해 AWS 리전의 AWS 계정당 최대 1,000개의 시스템을 등록할 수 있습니다. 단일 계정 및 리전에 1,000개 이상의 시스템을 등록해야 하는 경우 고급 인스턴스 티어를 사용합니다. 고급 인스턴스 티어에서 원하는 만큼 관리형 노드를 생성할 수 있습니다. Systems Manager를 위해 구성된 모든 관리형 노드의 가격은 사용량에 따라 지불하는 방식으로 책정됩니다. 고급 인스턴스 티어 활성화에 대한 자세한 내용은 [고급 인스턴스 티어 설정](fleet-manager-enable-advanced-instances-tier.md) 섹션을 참조하세요. 요금에 대한 자세한 내용은 [AWS Systems Manager 요금](https://aws.amazon.com/systems-manager/pricing/)을 참조하세요.
표준 인스턴스 계층 및 고급 인스턴스 계층에 대한 다음 추가 정보에 유의하세요.
+ 고급 인스턴스도 AWS Systems Manager Session Manager를 사용하여 [하이브리드 및 멀티클라우드](operating-systems-and-machine-types.md#supported-machine-types) 환경의 비 EC2 노드에 연결할 수 있습니다. Session Manager에서는 인스턴스에 대한 대화형 쉘 액세스가 제공됩니다. 자세한 내용은 [AWS Systems Manager Session Manager](session-manager.md) 섹션을 참조하세요.
+ 표준 인스턴스 할당량은 또한 Systems Manager 온프레미스 정품 인증을 사용하는 EC2 인스턴스에도 적용됩니다(일반 시나리오는 아님).
+ Microsoft에서 릴리스한 가상 머신 온프레미스 인스턴스 기반 애플리케이션을 패치하려면 고급 인스턴스 티어를 활성화합니다. 고급 인스턴스 티어 사용에는 요금이 따릅니다. Microsoft에서 릴리스한 Amazon Elastic Compute Cloud(Amazon EC2) 인스턴스 기반 애플리케이션을 패치하는 데는 추가 요금이 없습니다. 자세한 내용은 [Microsoft에서 Windows Server에 릴리스한 애플리케이션 패치 적용](patch-manager-patching-windows-applications.md) 섹션을 참조하세요.
**관리형 노드 표시**
콘솔에 관리형 노드가 표시되지 않으면 다음을 수행합니다.
1. 콘솔이 관리형 노드를 생성한 AWS 리전에서 열렸는지 확인합니다. 콘솔의 오른쪽 상단 모서리에 있는 목록을 사용하여 리전을 변경할 수 있습니다.
1. 관리형 노드 설정 단계에서 Systems Manager 요구 사항이 충족되는지 확인합니다. 자세한 내용은 [AWS Systems Manager에 대한 관리형 노드 설정](systems-manager-setting-up-nodes.md) 섹션을 참조하세요.
1. 비 EC2 시스템의 경우 하이브리드 정품 인증 프로세스를 완료했는지 확인합니다. 자세한 내용은 [Systems Manager로 하이브리드 및 멀티클라우드 환경에서 노드 관리](systems-manager-hybrid-multicloud.md) 섹션을 참조하세요.
다음 추가 정보를 참고하세요.
+ Fleet Manager 콘솔에는 종료된 Amazon EC2 노드가 표시되지 않습니다.
+ Systems Manager는 시스템에서 작업을 수행하기 위해 정확한 시간 참조가 필요합니다. 노드의 날짜와 시간이 잘못 설정되어 있으면 API 요청의 서명 날짜와 일치하지 않을 수 있습니다. 자세한 내용은 [사용 사례 및 모범 사례](systems-manager-best-practices.md) 섹션을 참조하세요.
+ 태그를 만들거나 편집할 때 시스템에서 테이블 필터에 변경 사항을 표시하는 데 최대 1시간이 걸릴 수 있습니다.
+ 관리형 노드의 상태가 30일 이상 `Connection Lost`한 후에는 해당 노드가 Fleet Manager 콘솔에 더 이상 나열되지 않을 수 있습니다. 목록으로 복원하려면 연결이 끊긴 문제를 해결해야 합니다. 문제 해결 팁은 [관리형 노드 가용성 문제 해결](fleet-manager-troubleshooting-managed-nodes.md) 섹션을 참조하세요.
**관리형 노드에서 Systems Manager 지원 확인**
AWS Config은(는) AWS 관리형 규칙을 제공합니다. AWS Config은(는) 미리 정의되고 사용자 정의 가능한 이 규칙을 사용하여 AWS 리소스 구성이 공통 모범 사례를 준수하는지 평가합니다. AWS Config 관리형 규칙에는 [ec2-instance-managed-by-systems-manager](https://docs.aws.amazon.com/config/latest/developerguide/ec2-instance-managed-by-systems-manager.html) 규칙이 포함됩니다. 이 규칙은 해당 계정의 Amazon EC2 인스턴스가 Systems Manager에서 관리되는지를 확인합니다. 자세한 내용은 [AWS Config 관리형 규칙](https://docs.aws.amazon.com/config/latest/developerguide/evaluate-config_use-managed-rules.html)을 참조하세요.
**관리형 노드에서 보안 태세 강화**
관리형 노드에서 무단 루트 수준 명령에 대한 보안 태세를 강화하는 방법은 [SSM Agent를 통한 루트 수준 명령에 대한 액세스 제한](ssm-agent-restrict-root-level-commands.md) 섹션을 참조하세요.
**관리형 노드 등록 취소**
관리형 노드는 언제든지 등록을 취소할 수 있습니다. 예를 들어 동일한 AWS Identity and Access Management(IAM) 역할의 노드를 여러 개 관리하면서 어떤 종류의 악의적인 동작을 감지하는 경우, 언제든지 원하는 수 컴퓨터를 등록 취소할 수 있습니다. (동일한 시스템을 다시 등록하려면 이전에 등록하는 데 사용한 것과 다른 하이브리드 활성화 코드와 활성화 ID를 사용해야 합니다.) 관리형 노드 등록 취소에 대한 자세한 내용은 [하이브리드 및 멀티클라우드 환경의 관리형 노드 등록 취소](fleet-manager-deregister-hybrid-nodes.md) 섹션을 참조하세요.
**Topics**
+ [인스턴스 티어 구성](fleet-manager-configure-instance-tiers.md)
+ [관리형 노드의 암호 재설정](fleet-manager-reset-password.md)
+ [하이브리드 및 멀티클라우드 환경의 관리형 노드 등록 취소](fleet-manager-deregister-hybrid-nodes.md)
+ [Fleet Manager를 사용하여 OS 파일 시스템 작업](fleet-manager-file-system-management.md)
+ [관리형 노드 성능 모니터링](fleet-manager-monitoring-node-performance.md)
+ [프로세스 작업](fleet-manager-manage-processes.md)
+ [관리형 노드의 로그 보기](fleet-manager-view-node-logs.md)
+ [Fleet Manager를 사용하여 관리형 노드에서 OS 사용자 계정 및 그룹 관리](fleet-manager-manage-os-user-accounts.md)
+ [관리형 노드의 Windows 레지스트리 관리](fleet-manager-manage-windows-registry.md)
# 인스턴스 티어 구성
이 주제에서는 고급 인스턴스 티어를 활성화해야 하는 시나리오에 대해 설명합니다.
AWS Systems Manager에서는 [하이브리드 및 멀티클라우드](operating-systems-and-machine-types.md#supported-machine-types) 환경의 비 EC2 시스템에 대한 표준 인스턴스 티어와 고급 인스턴스 티어를 제공합니다.
추가 비용 없이 AWS 리전별로 계정당 최대 1,000개의 표준 [하이브리드 정품 인증 노드](activations.md)를 등록할 수 있습니다. 그러나 1,000개 이상의 하이브리드 노드를 등록하려면 고급 인스턴스 티어를 활성화해야 합니다. 고급 인스턴스 티어를 사용하는 데는 요금이 부과됩니다. 자세한 내용은 [AWS Systems Manager요금](https://aws.amazon.com/systems-manager/pricing/)을 참조하세요.
등록된 하이브리드 정품 인증 노드가 1,000개 미만인 경우에도 두 가지 다른 시나리오에는 고급 인스턴스 티어가 필요합니다.
+ Session Manager를 사용하여 비EC2 노드에 연결하려고 합니다.
+ Microsoft에서 릴리스한 비EC2 노드 기반 애플리케이션(운영 체제 아님)을 패치하려고 합니다.
**참고**
Microsoft에서 릴리스한 Amazon EC2 인스턴스 기반 애플리케이션을 패치하는 것은 무료입니다.
## 고급 인스턴스 티어 세부 시나리오
다음 정보는 고급 인스턴스 티어를 활성화해야 하는 세 가지 시나리오에 대한 세부 정보를 제공합니다.
시나리오 1: 1,000개가 넘는 하이브리드 정품 인증 노드를 등록하려는 경우
표준 인스턴스 티어를 사용하면 추가 비용 없이 특정 계정에서 AWS 리전당 최대 1,000개의 비 EC2 노드를 [하이브리드 및 멀티클라우드 환경](operating-systems-and-machine-types.md#supported-machine-types)에서 등록할 수 있습니다. 한 리전에 1,000개 이상의 비EC2 노드를 등록해야 하는 경우 고급 인스턴스 티어를 사용해야 합니다. 그런 다음에 하이브리드 및 멀티클라우드 환경의 시스템을 원하는 만큼 정품 인증할 수 있습니다. 고급 인스턴스 티어에 대한 요금은 Systems Manager 관리형 노드로 정품 인증된 고급 노드 수와 해당 노드가 실행되는 시간을 기준으로 합니다.
특정 계정의 한 리전에서 1,000개의 온프레미스 노드를 초과하는 경우 [하이브리드 활성화를 생성하여 Systems Manager에 노드 등록](hybrid-activation-managed-nodes.md)에 설명된 활성화 프로세스를 사용하는 모든 Systems Manager 관리형 노드에 요금이 부과됩니다.
또한 Systems Manager 하이브리드 활성화를 사용하여 기존 Amazon Elastic Compute Cloud(Amazon EC2) 인스턴스를 활성화하고 테스트 등에 비EC2 인스턴스로 사용할 수 있습니다. 이러한 노드는 하이브리드 노드로 사용할 수도 있습니다. 이는 일반적인 시나리오가 아닙니다.
시나리오 2: Microsoft에서 릴리스한 하이브리드 활성 노드 기반 애플리케이션 패치
하이브리드 및 멀티클라우드 환경에 있는 Microsoft에서 릴리스한 비 EC2 노드의 애플리케이션에 패치를 적용하려는 경우에도 고급 인스턴스 티어가 필요합니다. 비EC2 노드 기반의 Microsoft 애플리케이션을 패치하기 위해 고급 인스턴스 티어를 활성화하면 1,000개 미만이더라도 모든 온프레미스 노드에 대해 요금이 부과됩니다.
Microsoft에서 릴리스한 Amazon Elastic Compute Cloud(Amazon EC2) 인스턴스 기반 애플리케이션을 패치하는 데는 추가 요금이 없습니다. 자세한 내용은 [Microsoft에서 Windows Server에 릴리스한 애플리케이션 패치 적용](patch-manager-patching-windows-applications.md) 섹션을 참조하세요.
시나리오 3: Session Manager를 사용하여 하이브리드 활성 노드에 연결
Session Manager는 인스턴스에 대한 대화형 셸 액세스를 제공합니다. Session Manager를 사용하여 하이브리드 정품 인증 관리형 노드에 연결하려면 고급 인스턴스 티어를 정품 인증해야 합니다. 그러면 1,000개 미만이라도 모든 하이브리드 활성 노드에 대해 요금이 부과됩니다.
**요약: 고급 인스턴스 티어는 언제 필요한가요?**
다음 표를 사용하여 고급 인스턴스 티어를 사용해야 하는 시기와 추가 요금이 적용되는 시나리오를 검토하세요.
****
| 시나리오 | 고급 인스턴스 티어가 필요한가요? | 추가 요금이 발생하나요? |
| --- | --- | --- |
| 특정 계정에서 내 리전의 하이브리드 활성 노드 수가 1,000개 이상입니다. | 예 | 예 |
| 하이브리드 활성 노드가 1,000개 미만이라도 Patch Manager를 사용하여 Microsoft에서 릴리스한 하이브리드 활성 노드 기반 애플리케이션을 패치하고 싶습니다. | 예 | 예 |
| 하이브리드 활성 노드가 1,000개 미만이라도 Session Manager를 사용하여 하이브리드 활성 노드에 연결하고 싶습니다. | 예 | 예 |
| [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/systems-manager/latest/userguide/fleet-manager-configure-instance-tiers.html) | 아니요 | 아니요 |
**Topics**
+ [고급 인스턴스 티어 세부 시나리오](#systems-manager-managed-instances-tier-scenarios)
+ [고급 인스턴스 티어 설정](fleet-manager-enable-advanced-instances-tier.md)
+ [고급 인스턴스 티어에서 표준 인스턴스 티어로 되돌리기](fleet-manager-revert-to-standard-tier.md)
# 고급 인스턴스 티어 설정
AWS Systems Manager에서는 [하이브리드 및 멀티클라우드](operating-systems-and-machine-types.md#supported-machine-types) 환경의 비 EC2 시스템에 대한 표준 인스턴스 티어와 고급 인스턴스 티어를 제공합니다. 표준 인스턴스 티어를 사용하면 한 AWS 리전의 AWS 계정당 최대 1,000개의 하이브리드 활성 머신을 등록할 수 있습니다. 또한 고급 인스턴스 티어는 Patch Manager를 사용하여 Microsoft에서 릴리스한 비EC2 노드 기반 애플리케이션을 패치하고 Session Manager를 사용하여 비EC2 노드에 연결하는 데 필요합니다. 자세한 내용은 [고급 인스턴스 티어 설정](#fleet-manager-enable-advanced-instances-tier) 섹션을 참조하세요.
이 섹션에서는 고급 인스턴스 티어를 사용하도록 하이브리드 및 멀티클라우드 환경을 구성하는 방법을 설명합니다.
**시작하기 전 준비 사항**
고급 인스턴스에 대한 요금 내역을 검토합니다. 고급 인스턴스는 종량 과금제로 이용 가능합니다. 자세한 내용은 [AWS Systems Manager 요금](https://aws.amazon.com/systems-manager/pricing/)을 참조하세요.
## 고급 인스턴스 티어를 설정하는 권한 구성
AWS Identity and Access Management(IAM)에 표준 인스턴트 티어에서 고급 인스턴스 티어로 환경을 변경할 수 있는 권한이 있는지 확인합니다. 사용자, 그룹 또는 역할에 `AdministratorAccess` IAM 정책이 연결되었거나 Systems Manager 활성화 티어 서비스 설정을 변경할 수 있는 권한이 있어야 합니다. 활성화 티어 설정은 다음 API 작업을 사용합니다.
+ [GetServiceSetting](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_GetServiceSetting.html)
+ [UpdateServiceSetting](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_UpdateServiceSetting.html)
+ [ResetServiceSetting](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_ResetServiceSetting.html)
다음 절차를 사용하여 인라인 IAM 정책을 사용자 계정에 연결합니다. 이 정책을 통해 사용자는 현재 관리형 인스턴스 티어 설정을 볼 수 있습니다. 또한 이 정책을 통해 사용자는 지정된 AWS 계정와 AWS 리전에서 현재 설정을 변경하거나 재설정할 수 있습니다.
1. AWS Management Console에 로그인하여 [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)에서 IAM 콘솔을 엽니다.
1. 탐색 창에서 **사용자**를 선택합니다.
1. 목록에서 정책을 삽입할 사용자 이름을 선택합니다.
1. **권한** 탭을 선택합니다.
1. 페이지 오른쪽에 있는 **Permission policies(권한 정책)**에서 **Add inline policy(인라인 정책 추가)**를 선택합니다.
1. **JSON** 탭을 선택합니다.
1. 기본 내용을 다음으로 바꿉니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ssm:GetServiceSetting"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"ssm:ResetServiceSetting",
"ssm:UpdateServiceSetting"
],
"Resource": "arn:aws:ssm:us-east-1:111122223333:servicesetting/ssm/managed-instance/activation-tier"
}
]
}
```
------
1. **정책 검토**를 선택합니다.
1. **Review Policy(정책 검토)** 페이지의 **이름**에 인라인 정책 이름을 입력합니다. 예를 들면 **Managed-Instances-Tier**입니다.
1. **정책 생성**을 선택합니다.
관리자는 다음 인라인 정책을 사용자에게 할당하여 읽기 전용 권한을 지정할 수 있습니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ssm:GetServiceSetting"
],
"Resource": "*"
},
{
"Effect": "Deny",
"Action": [
"ssm:ResetServiceSetting",
"ssm:UpdateServiceSetting"
],
"Resource": "*"
}
]
}
```
------
IAM 정책 생성 및 편집에 대한 자세한 내용은 *IAM User Guide*의 [Creating IAM Policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html)를 참조하세요.
## 고급 인스턴스 티어 설정(콘솔)
다음 절차에서는 Systems Manager 콘솔을 사용하여 지정된 AWS 계정 및 AWS 리전에서 관리형 인스턴스 정품 인증을 통해 추가된 **모든 비 EC2 노드를 고급 인스턴스 티어 사용으로 변경하는 방법을 보여줍니다.
**시작하기 전 준비 사항**
콘솔이 관리형 인스턴스를 생성한 AWS 리전에서 열렸는지 확인합니다. 콘솔의 오른쪽 상단 모서리에 있는 목록을 사용하여 리전을 변경할 수 있습니다.
[하이브리드 및 멀티클라우드](operating-systems-and-machine-types.md#supported-machine-types) 환경의 Amazon Elastic Compute Cloud(Amazon EC2) 인스턴스 및 비 EC2 시스템에 대한 설정 요구 사항을 완료했는지 확인합니다. 자세한 내용은 [AWS Systems Manager에 대한 관리형 노드 설정](systems-manager-setting-up-nodes.md) 섹션을 참조하세요.
**중요**
다음 절차는 계정 수준 설정을 변경하는 방법을 설명합니다. 이 변경 사항으로 인해 계정에 요금이 청구됩니다.
**고급 인스턴스 티어를 설정하려면(콘솔)**
1. [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)에서 AWS Systems Manager 콘솔을 엽니다.
1. 탐색 창에서 **Fleet Manager**를 선택합니다.
1. **설정**을 선택한 다음 **인스턴스 계층 설정 변경**을 선택합니다.
1. 대화 상자에서 계정 설정 변경에 대한 정보를 검토하고 계속 진행합니다.
1. 승인하는 경우 수락할 옵션을 선택하고 **설정 변경**을 선택합니다.
시스템에서 모든 인스턴스를 표준 인스턴스 티어에서 고급 인스턴스 티어로 이동하는 프로세스를 완료하는 데 몇 분이 소요될 수 있습니다.
**참고**
표준 인스턴스 티어로 다시 변경하는 방법에 대한 자세한 내용은 [고급 인스턴스 티어에서 표준 인스턴스 티어로 되돌리기](fleet-manager-revert-to-standard-tier.md) 섹션을 참조하세요.
## 고급 인스턴스 티어 설정(AWS CLI)
다음 절차에서는 AWS Command Line Interface를 사용하여 지정된 AWS 계정와 AWS 리전에서 관리형 인스턴스 활성화를 통해 추가된 *모든* 온프레미스 서버와 VM을 고급 인스턴스 티어 사용으로 변경하는 방법을 설명합니다.
**중요**
다음 절차는 계정 수준 설정을 변경하는 방법을 설명합니다. 이 변경 사항으로 인해 계정에 요금이 청구됩니다.
**AWS CLI를 사용하여 고급 인스턴스 티어를 설정하려면**
1. AWS CLI을 열고 다음 명령을 실행합니다. 각 *example resource placeholder*를 사용자의 정보로 바꿉니다.
------
#### [ Linux & macOS ]
```
aws ssm update-service-setting \
--setting-id arn:aws:ssm:region:aws-account-id:servicesetting/ssm/managed-instance/activation-tier \
--setting-value advanced
```
------
#### [ Windows ]
```
aws ssm update-service-setting ^
--setting-id arn:aws:ssm:region:aws-account-id:servicesetting/ssm/managed-instance/activation-tier ^
--setting-value advanced
```
------
명령이 성공해도 출력은 없습니다.
1. 다음 명령을 실행하여 현재 AWS 계정 및 AWS 리전의 관리형 노드에 대한 현재 서비스 설정을 확인합니다.
------
#### [ Linux & macOS ]
```
aws ssm get-service-setting \
--setting-id arn:aws:ssm:region:aws-account-id:servicesetting/ssm/managed-instance/activation-tier
```
------
#### [ Windows ]
```
aws ssm get-service-setting ^
--setting-id arn:aws:ssm:region:aws-account-id:servicesetting/ssm/managed-instance/activation-tier
```
------
명령은 다음과 같은 정보를 반환합니다.
```
{
"ServiceSetting": {
"SettingId": "/ssm/managed-instance/activation-tier",
"SettingValue": "advanced",
"LastModifiedDate": 1555603376.138,
"LastModifiedUser": "arn:aws:sts::123456789012:assumed-role/Administrator/User_1",
"ARN": "arn:aws:ssm:us-east-2:123456789012:servicesetting/ssm/managed-instance/activation-tier",
"Status": "PendingUpdate"
}
}
```
## 고급 인스턴스 티어 설정(PowerShell)
다음 절차에서는 AWS Tools for Windows PowerShell를 사용하여 지정된 AWS 계정와 AWS 리전에서 관리형 인스턴스 활성화를 통해 추가된 *모든* 온프레미스 서버와 VM을 고급 인스턴스 티어 사용으로 변경하는 방법을 설명합니다.
**중요**
다음 절차는 계정 수준 설정을 변경하는 방법을 설명합니다. 이 변경 사항으로 인해 계정에 요금이 청구됩니다.
**PowerShell을 사용하여 고급 인스턴스 티어를 설정하려면**
1. AWS Tools for Windows PowerShell을 열고 다음 명령을 실행합니다. 각 *example resource placeholder*를 사용자의 정보로 바꿉니다.
```
Update-SSMServiceSetting `
-SettingId "arn:aws:ssm:region:aws-account-id:servicesetting/ssm/managed-instance/activation-tier" `
-SettingValue "advanced"
```
명령이 성공해도 출력은 없습니다.
1. 다음 명령을 실행하여 현재 AWS 계정 및 AWS 리전의 관리형 노드에 대한 현재 서비스 설정을 확인합니다.
```
Get-SSMServiceSetting `
-SettingId "arn:aws:ssm:region:aws-account-id:servicesetting/ssm/managed-instance/activation-tier"
```
명령은 다음과 같은 정보를 반환합니다.
```
ARN:arn:aws:ssm:us-east-2:123456789012:servicesetting/ssm/managed-instance/activation-tier
LastModifiedDate : 4/18/2019 4:02:56 PM
LastModifiedUser : arn:aws:sts::123456789012:assumed-role/Administrator/User_1
SettingId : /ssm/managed-instance/activation-tier
SettingValue : advanced
Status : PendingUpdate
```
시스템에서 모든 노드를 표준 인스턴스 티어에서 고급 인스턴스 티어로 이동하는 프로세스를 완료하는 데 몇 분이 소요될 수 있습니다.
**참고**
표준 인스턴스 티어로 다시 변경하는 방법에 대한 자세한 내용은 [고급 인스턴스 티어에서 표준 인스턴스 티어로 되돌리기](fleet-manager-revert-to-standard-tier.md) 섹션을 참조하세요.
# 고급 인스턴스 티어에서 표준 인스턴스 티어로 되돌리기
이 섹션에서는 고급 인스턴스 티어에서 실행되는 하이브리드 정품 인증 노드를 표준 인스턴스 티어로 다시 변경하는 방법을 설명합니다. 이 구성은 AWS 계정 및 단일 AWS 리전의 모든 하이브리드 정품 인증 노드에 적용됩니다.
**시작하기 전 준비 사항**
다음과 같은 중요한 세부 정보를 검토합니다.
**참고**
계정과 리전에서 1,000개가 넘는 하이브리드 정품 인증 노드 실행하는 경우에는 표준 인스턴스 티어로 되돌릴 수 없습니다. 먼저 1,000개 이하가 될 때까지 노드의 등록을 취소해야 합니다. 이는 Systems Manager 하이브리드 정품 인증(일반적인 시나리오가 아님)을 사용하는 Amazon Elastic Compute Cloud(Amazon EC2) 인스턴스에도 적용됩니다. 자세한 내용은 [하이브리드 및 멀티클라우드 환경의 관리형 노드 등록 취소](fleet-manager-deregister-hybrid-nodes.md) 섹션을 참조하세요.
되돌리면 AWS Systems Manager의 도구인 Session Manager를 사용하여 하이브리드 활성 노드에 대화형으로 액세스할 수 없습니다.
되돌리면 하이브리드 활성 노드에서 AWS Systems Manager의 도구인 Patch Manager를 사용하여 Microsoft에서 릴리스한 애플리케이션에 패치를 적용할 수 없습니다.
모든 하이브리드 정품 인증 노드를 표준 인스턴스 티어로 되돌리는 프로세스를 완료하는 데 30분 이상이 걸릴 수 있습니다.
이 섹션에서는 AWS 계정 및 AWS 리전의 모든 하이브리드 정품 인증 노드를 고급 인스턴스 티어에서 표준 인스턴스 티어로 되돌리는 방법을 설명합니다.
## 표준 인스턴스 티어로 되돌리기(콘솔)
다음 절차에서는 Systems Manager 콘솔을 사용하여 지정된 AWS 계정 및 AWS 리전에서 표준 인스턴스 티어를 사용하도록 [하이브리드 및 멀티클라우드](operating-systems-and-machine-types.md#supported-machine-types) 환경의 모든 하이브리드 정품 인증 노드를 변경하는 방법을 보여줍니다.
**표준 인스턴스 티어로 되돌리려면(콘솔)**
1. [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)에서 AWS Systems Manager 콘솔을 엽니다.
1. 탐색 창에서 **Fleet Manager**를 선택합니다.
1. [**계정 설정(Account settings)**] 드롭다운을 선택하고 [**인스턴스 티어 설정(Instance tier settings)**]을 선택합니다.
1. **Change account settings(계정 설정 변경)**를 선택합니다.
1. 팝업 창에 있는 계정 설정 변경 관련 정보를 검토하고 이를 승인하는 경우에는 수락 후 계속 진행할 수 있는 옵션을 선택합니다.
## 표준 인스턴스 티어로 되돌리기(AWS CLI)
다음 절차에서는 AWS Command Line Interface를 사용하여 지정된 AWS 계정 및 AWS 리전에서 표준 인스턴스 티어를 사용하도록 [하이브리드 및 멀티클라우드](operating-systems-and-machine-types.md#supported-machine-types) 환경의 모든 하이브리드 정품 인증 노드를 변경하는 방법을 보여줍니다.
**AWS CLI을 사용하여 표준 인스턴스 티어로 되돌리려면**
1. AWS CLI을 열고 다음 명령을 실행합니다. 각 *example resource placeholder*를 사용자의 정보로 바꿉니다.
------
#### [ Linux & macOS ]
```
aws ssm update-service-setting \
--setting-id arn:aws:ssm:region:aws-account-id:servicesetting/ssm/managed-instance/activation-tier \
--setting-value standard
```
------
#### [ Windows ]
```
aws ssm update-service-setting ^
--setting-id arn:aws:ssm:region:aws-account-id:servicesetting/ssm/managed-instance/activation-tier ^
--setting-value standard
```
------
명령이 성공해도 출력은 없습니다.
1. 30분 후에 다음 명령을 실행하여 현재 AWS 계정와 AWS 리전의 관리형 인스턴스에 대한 설정을 확인합니다.
------
#### [ Linux & macOS ]
```
aws ssm get-service-setting \
--setting-id arn:aws:ssm:region:aws-account-id:servicesetting/ssm/managed-instance/activation-tier
```
------
#### [ Windows ]
```
aws ssm get-service-setting ^
--setting-id arn:aws:ssm:region:aws-account-id:servicesetting/ssm/managed-instance/activation-tier
```
------
명령은 다음과 같은 정보를 반환합니다.
```
{
"ServiceSetting": {
"SettingId": "/ssm/managed-instance/activation-tier",
"SettingValue": "standard",
"LastModifiedDate": 1555603376.138,
"LastModifiedUser": "System",
"ARN": "arn:aws:ssm:us-east-2:123456789012:servicesetting/ssm/managed-instance/activation-tier",
"Status": "Default"
}
}
```
요청이 승인되면 상태가 *기본값*으로 변경됩니다.
## 표준 인스턴스 티어로 되돌리기(PowerShell)
다음 절차에서는 AWS Tools for Windows PowerShell를 사용하여 지정된 AWS 계정 및 AWS 리전에서 표준 인스턴스 티어를 사용하도록 하이브리드 및 멀티클라우드 환경의 하이브리드 정품 인증 노드를 변경하는 방법을 보여줍니다.
**PowerShell을 사용하여 표준 인스턴스 티어로 되돌리려면**
1. AWS Tools for Windows PowerShell을 열고 다음 명령을 실행합니다.
```
Update-SSMServiceSetting `
-SettingId "arn:aws:ssm:region:aws-account-id:servicesetting/ssm/managed-instance/activation-tier" `
-SettingValue "standard"
```
명령이 성공해도 출력은 없습니다.
1. 30분 후에 다음 명령을 실행하여 현재 AWS 계정와 AWS 리전의 관리형 인스턴스에 대한 설정을 확인합니다.
```
Get-SSMServiceSetting `
-SettingId "arn:aws:ssm:region:aws-account-id:servicesetting/ssm/managed-instance/activation-tier"
```
명령은 다음과 같은 정보를 반환합니다.
```
ARN: arn:aws:ssm:us-east-2:123456789012:servicesetting/ssm/managed-instance/activation-tier
LastModifiedDate : 4/18/2019 4:02:56 PM
LastModifiedUser : System
SettingId : /ssm/managed-instance/activation-tier
SettingValue : standard
Status : Default
```
요청이 승인되면 상태가 *기본값*으로 변경됩니다.
# 관리형 노드의 암호 재설정
관리형 노드에서 모든 사용자 암호를 재설정할 수 있습니다. 여기에는 AWS Systems Manager에서 관리하는 Amazon Elastic Compute Cloud(Amazon EC2) 인스턴스, AWS IoT Greengrass 코어 디바이스, 온프레미스 서버 및 가상 머신이 포함됩니다. 암호 재설정 기능은 AWS Systems Manager의 도구인 Session Manager에 바탕을 두고 있습니다. 이 기능을 사용하면 인바운드 포트를 개방하거나, Bastion Host를 유지하거나, SSH 키를 관리하지 않고도 관리형 노드에 연결할 수 있습니다.
암호 재설정은 사용자가 암호를 잊었거나, 혹은 RDP 또는 SSH를 관리형 노드에 연결하지 않고 빠르게 암호를 업데이트하고 싶을 때 매우 유용합니다.
**사전 조건**
관리형 노드 암호를 재설정하려면 먼저 다음 요건을 충족해야 합니다.
+ 암호를 변경할 관리형 노드가 Systems Manager 관리형 노드여야 합니다. 또한,관리형 노드에 SSM Agent 버전 2.3.668.0 이상이 설치되어 있어야 합니다.) SSM Agent 설치 또는 업데이트에 대한 자세한 내용은 [SSM Agent 작업](ssm-agent.md) 섹션을 참조하세요.
+ 암호 재설정 기능은 계정에서 관리형 노드에 연결할 수 있도록 설정된 Session Manager 구성을 사용합니다. 따라서 Session Manager를 사용하려면 현재 AWS 리전에서 계정에 필요한 사전 조건이 충족되어야 합니다. 자세한 내용은 [Session Manager 설정](session-manager-getting-started.md) 섹션을 참조하세요.
**참고**
온프레미스 노드에 대한 Session Manager 지원은 고급 인스턴스 티어에만 제공됩니다. 자세한 내용은 [고급 인스턴스 티어 설정](fleet-manager-enable-advanced-instances-tier.md) 섹션을 참조하세요.
+ 암호를 변경하는 AWS 사용자는 해당 관리형 노드에 대해 `ssm:SendCommand` 권한이 있어야 합니다. 자세한 내용은 [태그를 기반으로 Run Command 액세스 제한](run-command-setting-up.md#tag-based-access) 섹션을 참조하세요.
**액세스 제한**
암호를 재설정할 수 있는 사용자 권한을 특정 관리형 노드로 제한할 수 있습니다. Session Manager `ssm:StartSession` 작업에 `AWS-PasswordReset` SSM 문서와 함께 자격 증명 기반 정책을 사용하면 가능합니다. 자세한 내용은 [인스턴스에 대한 사용자 세션 액세스 제어](session-manager-getting-started-restrict-access.md)를 참조하세요.
**데이터 암호화**
관리형 노드에 대한 암호 재설정 옵션을 사용하려면 Session Manager 데이터에 대해 AWS Key Management Service(AWS KMS) 완전 암호화를 설정합니다. 자세한 내용은 [세션 데이터의 KMS 키 암호화를 설정하려면(콘솔)](session-preferences-enable-encryption.md) 섹션을 참조하세요.
## 관리형 노드의 암호 재설정
Systems Manager 관리형 노드의 암호는 Systems Manager **Fleet Manager** 콘솔 또는 AWS Command Line Interface(AWS CLI)를 사용해 재설정할 수 있습니다.
**관리형 노드의 암호 재설정(콘솔)**
1. [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)에서 AWS Systems Manager 콘솔을 엽니다.
1. 탐색 창에서 **Fleet Manager**를 선택합니다.
1. 새로운 암호가 필요한 노드 옆에 있는 버튼을 선택합니다.
1. **인스턴스 작업, 암호 재설정**을 선택합니다.
1. [**사용자 이름(User name)**]에 암호를 변경할 사용자 이름을 입력합니다. 해당 노드에 대한 계정을 소유하고 있는 사용자 이름도 될 수 있습니다.
1. **제출**을 선택합니다.
1. **Enter new password(새 암호 입력)** 명령 창의 메시지에 따라 새로운 암호를 지정합니다.
**참고**
관리형 노드에 설치된 SSM Agent 버전이 암호 재설정을 지원하지 않을 경우에는 AWS Systems Manager의 도구인 Run Command를 사용해 지원되는 버전을 설치하라는 메시지가 표시됩니다.
**관리형 노드의 암호 재설정(AWS CLI)**
1. 관리형 노드의 사용자 암호를 재설정하려면 다음 명령을 실행합니다. 각 *example resource placeholder*를 사용자의 정보로 바꿉니다.
**참고**
AWS CLI를 사용해 암호를 재설정할 경우 Session Manager 플러그인이 로컬 시스템에 설치되어 있어야 합니다. 자세한 내용은 [AWS CLI의 Session Manager 플러그인 설치](session-manager-working-with-install-plugin.md) 섹션을 참조하세요.
------
#### [ Linux & macOS ]
```
aws ssm start-session \
--target instance-id \
--document-name "AWS-PasswordReset" \
--parameters '{"username": ["user-name"]}'
```
------
#### [ Windows ]
```
aws ssm start-session ^
--target instance-id ^
--document-name "AWS-PasswordReset" ^
--parameters username="user-name"
```
------
1. **Enter new password(새 암호 입력)** 명령 창의 메시지에 따라 새로운 암호를 지정합니다.
## 관리형 노드의 암호 재설정에 따른 문제 해결
암호를 재설정하면서 발생하는 문제는 대부분 [암호 재설정 사전 조건](#pw-reset-prereqs)만 충족해도 해결할 수 있습니다. 그 밖에는 다음 정보가 암호 재설정 문제를 해결하는 데 도움이 될 것입니다.
**Topics**
+ [관리형 노드 사용 불가](#password-reset-troubleshooting-instances)
+ [SSM Agent가 최신 상태가 아닙니다(콘솔)](#password-reset-troubleshooting-ssmagent-console)
+ [암호 재설정 옵션은 제공되지 않습니다(AWS CLI).](#password-reset-troubleshooting-ssmagent-cli)
+ [`ssm:SendCommand`를 실행할 수 있는 권한이 없습니다](#password-reset-troubleshooting-sendcommand)
+ [Session Manager 오류 메시지](#password-reset-troubleshooting-session-manager)
### 관리형 노드 사용 불가
**문제**: **관리형 인스턴스** 콘솔 페이지에서 관리형 노드의 암호를 재설정하려고 하는데 노드가 목록에 없습니다.
+ **솔루션**: 연결하려는 관리형 노드가 Systems Manager에서 구성되지 않았을 수 있습니다. Systems Manager에서 EC2 인스턴스를 사용하려면 인스턴스에 대해 작업을 수행할 권한을 부여하는 AWS Identity and Access Management(IAM) 인스턴스 프로파일을 인스턴스에 연결해야 합니다. 자세한 내용은 [Systems Manager에 필요한 인스턴스 권한 구성](setup-instance-permissions.md)을 참조하세요.
Systems Manager에서 EC2 시스템이 아닌 시스템을 사용하려면 시스템에서 관리형 노드의 작업을 수행하는 권한을 Systems Manager에 부여하는 IAM 서비스 역할을 생성합니다. 더 자세한 내용은 [하이브리드 및 멀티클라우드 환경에서 Systems Manager에 필요한 IAM 서비스 역할 생성](hybrid-multicloud-service-role.md)을 참조하세요(온프레미스 서버 및 VM에 대한 Session Manager 지원은 고급 인스턴스 티어에만 제공됩니다. 자세한 내용은 [고급 인스턴스 티어 설정](fleet-manager-enable-advanced-instances-tier.md) 참조).
### SSM Agent가 최신 상태가 아닙니다(콘솔)
**문제**: SSM Agent 버전이 암호 재설정 기능을 지원하지 않는다는 메시지가 표시됩니다.
+ **해결 방법**: 암호를 재설정하려면 SSM Agent 버전 2.3.668.0 이상이 필요합니다. 콘솔에서 **업데이트 SSM Agent**를 선택하여 관리형 노드의 에이전트를 업데이트할 수 있습니다.
SSM Agent의 업데이트된 버전은 Systems Manager에 새 도구가 추가되거나 기존 도구가 업데이트될 때마다 릴리스됩니다. 최신 버전의 에이전트를 사용하지 못하면 관리형 노드에서 다양한 Systems Manager 도구를 사용하지 못할 수 있습니다. 이러한 이유로 시스템의 SSM Agent 상태를 최신 상태로 유지하는 프로세스를 자동화하는 것이 좋습니다. 자세한 내용은 [SSM Agent 업데이트 자동화](ssm-agent-automatic-updates.md) 섹션을 참조하세요. SSM Agent 업데이트에 대해 알림을 수신하려면 GitHub에서 [SSM Agent 릴리스 정보](https://github.com/aws/amazon-ssm-agent/blob/mainline/RELEASENOTES.md) 페이지를 구독합니다.
### 암호 재설정 옵션은 제공되지 않습니다(AWS CLI).
**문제**: AWS CLI `[https://docs.aws.amazon.com/cli/latest/reference/ssm/start-session.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/start-session.html)` 명령을 사용해 관리형 노드에 연결했습니다. SSM 문서 `AWS-PasswordReset`을 지정하고 유효한 사용자 이름을 입력하였지만 암호를 변경할 수 있는 메시지가 표시되지 않습니다.
+ **해결 방법**: 관리형 노드에 설치된 SSM Agent 버전이 최신 상태가 아닙니다. 암호를 재설정하려면 버전 2.3.668.0 이상이 필요합니다.
SSM Agent의 업데이트된 버전은 Systems Manager에 새 도구가 추가되거나 기존 도구가 업데이트될 때마다 릴리스됩니다. 최신 버전의 에이전트를 사용하지 못하면 관리형 노드에서 다양한 Systems Manager 도구를 사용하지 못할 수 있습니다. 이러한 이유로 시스템의 SSM Agent 상태를 최신 상태로 유지하는 프로세스를 자동화하는 것이 좋습니다. 자세한 내용은 [SSM Agent 업데이트 자동화](ssm-agent-automatic-updates.md) 섹션을 참조하세요. SSM Agent 업데이트에 대해 알림을 수신하려면 GitHub에서 [SSM Agent 릴리스 정보](https://github.com/aws/amazon-ssm-agent/blob/mainline/RELEASENOTES.md) 페이지를 구독합니다.
### `ssm:SendCommand`를 실행할 수 있는 권한이 없습니다
**문제**: 관리형 노드에 연결하여 암호를 변경하려고 하지만 관리형 노드에서 `ssm:SendCommand`을 실행할 권한이 없다는 오류 메시지가 표시됩니다.
+ **해결 방법**: IAM 정책에 `ssm:SendCommand` 명령을 실행할 수 있는 권한을 추가해야 합니다. 자세한 내용은 [태그를 기반으로 Run Command 액세스 제한](run-command-setting-up.md#tag-based-access) 섹션을 참조하세요.
### Session Manager 오류 메시지
**문제**: Session Manager에 관한 오류 메시지가 표시됩니다.
+ **해결 방법**: 암호 재설정 기능을 지원하려면 Session Manager가 올바르게 구성되어 있어야 합니다. 자세한 내용은 [Session Manager 설정](session-manager-getting-started.md) 및 [Session Manager 문제 해결](session-manager-troubleshooting.md) 섹션을 참조하세요.
# 하이브리드 및 멀티클라우드 환경의 관리형 노드 등록 취소
더 이상 AWS Systems Manager를 사용하여 온프레미스 서버, 엣지 디바이스 또는 가상 머신(VM)을 관리하고 싶지 않은 경우에는 등록을 취소할 수 있습니다. 하이브리드 정품 인증 등록을 취소하면 Systems Manager의 관리형 노드 목록에서 제거됩니다. AWS Systems Manager 하이브리드 정품 인증 노드에서 실행되는 에이전트(SSM Agent)는 더는 등록되지 않기 때문에 권한 부여 토큰 새로 고침을 진행할 수 없습니다. SSM Agent는 최대 절전 모드로 전환되고 클라우드에서 Systems Manager에 대한 핑 빈도가 시간당 한 번으로 줄어듭니다. Systems Manager는 등록 취소된 관리형 노드에 대한 명령 기록을 30일 동안 저장합니다.
**참고**
지정된 활성화 코드 및 ID에 대한 인스턴스 제한에 도달하지 않았다면 동일한 활성화 코드 및 ID를 사용하여 온프레미스 서버, 엣지 디바이스 또는 VM을 다시 등록할 수 있습니다. 콘솔에서 **노드 도구**를 선택한 다음, **하이브리드 활성화**를 선택하여 인스턴스 제한을 확인할 수 있습니다. **등록된 인스턴스**의 값이 **등록 한도**보다 작으면 동일한 활성화 코드와 ID를 사용하여 시스템을 다시 등록할 수 있습니다. 더 큰 경우 다른 활성화 코드와 ID를 사용해야 합니다.
다음 절차에서는 Systems Manager 콘솔을 사용하여 하이브리드 정품 인증 노드의 등록을 취소하는 방법을 설명합니다. AWS Command Line Interface를 사용하여 이를 수행하는 방법에 대한 자세한 내용은 [deregister-managed-instance](https://docs.aws.amazon.com/cli/latest/reference/ssm/deregister-managed-instance.html)를 참조하세요.
관련 내용은 다음 주제를 참조하세요.
+ [관리형 노드 등록 취소 및 다시 등록(Linux)](hybrid-multicloud-ssm-agent-install-linux.md#systems-manager-install-managed-linux-deregister-reregister)(Linux)
+ [관리형 노드 등록 취소 및 다시 등록(Windows Server)](hybrid-multicloud-ssm-agent-install-windows.md#systems-manager-install-managed-win-deregister-reregister) (Windows Server)
**하이브리드 정품 인증 노드의 등록을 취소하는 방법(콘솔)**
1. [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)에서 AWS Systems Manager 콘솔을 엽니다.
1. 탐색 창에서 **Fleet Manager**를 선택합니다.
1. 등록 취소할 관리형 노드 옆에 있는 버튼을 선택합니다.
1. **노드 태스크, 도구, 이 관리 노드 등록 취소**를 선택합니다.
1. **이 관리 노드 등록 취소** 대화 상자의 정보를 검토하세요. 이상이 없으면 **등록 취소**를 선택합니다.
# Fleet Manager를 사용하여 OS 파일 시스템 작업
AWS Systems Manager의 도구인 Fleet Manager를 사용하여 관리형 노드에서 파일 시스템 작업을 할 수 있습니다. Fleet Manager를 사용하여 관리형 노드에 연결된 볼륨에 저장된 디렉터리 및 파일 데이터에 대한 정보를 볼 수 있습니다. 예를 들어 디렉터리 및 파일의 이름, 크기, 확장자, 소유자 및 권한을 볼 수 있습니다. Fleet Manager 콘솔에서 최대 10,000줄의 파일 데이터를 텍스트로 미리 볼 수 있습니다. 파일 `tail`에도 이 기능을 사용할 수 있습니다. `tail`을 사용하여 파일 데이터를 볼 때 파일의 마지막 10줄이 처음에 표시됩니다. 새 데이터 행이 파일에 기록되면 뷰가 실시간으로 업데이트됩니다. 결과적으로 콘솔에서 로그 데이터를 검토할 수 있어 문제 해결 및 시스템 관리의 효율성을 향상시킬 수 있습니다. 또한 디렉터리를 만들고 파일 및 디렉터리를 복사, 잘라내기, 붙여넣기, 이름 바꾸기 또는 삭제할 수 있습니다.
정기적인 백업을 생성하거나 관리형 노드에 연결된 Amazon Elastic Block Store(Amazon EBS) 볼륨의 스냅샷을 생성하는 것이 좋습니다. 파일을 복사하거나 잘라내어 붙여넣을 때, 새 파일 또는 디렉터리와 이름이 같은 대상 경로의 기존 파일 및 디렉터리가 대체됩니다. 시스템 파일 및 디렉터리를 바꾸거나 수정하면 심각한 문제가 발생할 수 있습니다. AWS는 이러한 문제가 해결될 수 있다고 보장하지 않습니다. 시스템 파일을 수정할 때는 사용자의 주의가 필요합니다. 모든 파일 및 디렉터리에 변경과 백업이 있는지 확인하는 것은 사용자의 책임입니다. 파일 및 디렉터리를 삭제하거나 바꾸려면 실행 취소할 수 없습니다.
**참고**
Fleet Manager는 AWS Systems Manager의 도구인 Session Manager를 사용하여 텍스트 미리 보기 및 `tail` 파일을 봅니다. Amazon Elastic Compute Cloud(Amazon EC2) 인스턴스에서, 인스턴스 프로파일은 관리형 인스턴스에 Session Manager가 이 기능을 사용할 수 있는 권한을 제공해야 합니다. 인스턴스 프로파일에 Session Manager 권한 추가에 대한 자세한 내용은 [기존 IAM 역할에 Session Manager 권한 추가](getting-started-add-permissions-to-existing-profile.md) 섹션을 참조하세요.
**Topics**
+ [Fleet Manager를 사용하여 OS 파일 시스템 보기](fleet-manager-viewing-file-system.md)
+ [Fleet Manager를 사용하여 OS 파일 미리 보기](fleet-manager-preview-os-files.md)
+ [Fleet Manager를 사용하여 OS 파일 테일링](fleet-manager-tailing-os-files.md)
+ [Fleet Manager를 사용하여 OS 파일 또는 디렉터리 복사, 잘라내기 및 붙여넣기](fleet-manager-move-files-or-directories.md)
+ [Fleet Manager를 사용하여 OS 파일 및 디렉터리 이름 변경](fleet-manager-renaming-files-and-directories.md)
+ [Fleet Manager를 사용하여 OS 파일 및 디렉터리 삭제](fleet-manager-deleting-files-and-directories.md)
+ [Fleet Manager를 사용하여 OS 디렉터리 생성](fleet-manager-creating-directories.md)
+ [Fleet Manager를 사용하여 OS 디렉터리 잘라내기, 복사 및 붙여넣기](fleet-manager-managing-directories.md)
# Fleet Manager를 사용하여 OS 파일 시스템 보기
Fleet Manager를 사용하여 Systems Manager 관리형 노드에서 OS 파일 시스템을 볼 수 있습니다.
**Fleet Manager를 사용하여 파일 시스템을 보는 방법**
1. [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)에서 AWS Systems Manager 콘솔을 엽니다.
1. 탐색 창에서 **Fleet Manager**를 선택합니다.
1. 보려고 하는 파일 시스템과 관리형 노드의 링크를 선택합니다.
1. **도구, 파일 시스템**을 선택합니다.
# Fleet Manager를 사용하여 OS 파일 미리 보기
Fleet Manager를 사용하여 OS에서 텍스트 파일을 미리 볼 수 있습니다.
**Fleet Manager를 사용하여 파일의 텍스트 미리 보기를 보는 방법**
1. [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)에서 AWS Systems Manager 콘솔을 엽니다.
1. 탐색 창에서 **Fleet Manager**를 선택합니다.
1. 미리 보려고 하는 파일과 관리형 노드의 링크를 선택합니다.
1. **도구, 파일 시스템**을 선택합니다.
1. 미리 보려는 파일이 포함된 디렉터리의 **파일 이름(File name)**을 선택합니다.
1. 내용을 미리 보려는 파일 옆에 있는 버튼을 선택합니다.
1. **작업, 텍스트로 미리 보기**를 선택합니다.
# Fleet Manager를 사용하여 OS 파일 테일링
Fleet Manager를 사용하여 관리형 노드에서 파일을 테일링할 수 있습니다.
**Fleet Manager을 사용하여 OS 파일을 테일링하는 방법**
1. [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)에서 AWS Systems Manager 콘솔을 엽니다.
1. 탐색 창에서 **Fleet Manager**를 선택합니다.
1. 추적하려는 파일과 관리형 노드의 링크를 선택합니다.
1. **도구, 파일 시스템**을 선택합니다.
1. 추적하려는 파일이 포함된 디렉터리의 **파일 이름(File name)**을 선택합니다.
1. 콘텐츠에 테일을 붙일 파일 옆에 있는 버튼을 선택합니다.
1. **작업, 테일 파일**을 선택합니다.
# Fleet Manager를 사용하여 OS 파일 또는 디렉터리 복사, 잘라내기 및 붙여넣기
Fleet Manager를 사용하여 관리형 노드에서 OS 파일을 복사하고 잘라내며 붙여넣을 수 있습니다.
**Fleet Manager를 사용하여 파일 또는 디렉터리를 복사하거나 잘라내고 붙여넣는 방법**
1. [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)에서 AWS Systems Manager 콘솔을 엽니다.
1. 탐색 창에서 **Fleet Manager**를 선택합니다.
1. 복사하거나 잘라내어 붙여넣을 파일과 관리형 노드의 링크를 선택합니다.
1. **도구, 파일 시스템**을 선택합니다.
1. 파일을 복사하거나 잘라내려면 복사하거나 잘라낼 파일이 들어 있는 디렉터리의 **파일 이름(File name)**을 선택합니다. 디렉터리를 복사하거나 잘라내려면 복사하거나 잘라낼 디렉터리 옆에 있는 버튼을 선택한 다음 8단계로 진행합니다.
1. 복사하거나 잘라낼 파일 옆에 있는 버튼을 선택합니다.
1. **작업(Actions)** 메뉴에서 **복사(Copy)** 또는 **잘라내기(Cut)**를 선택합니다.
1. **파일 시스템(File system)** 보기에서 파일을 붙여넣을 디렉터리 옆에 있는 버튼을 선택합니다.
1. **작업(Actions)** 메뉴에서 **붙여넣기(Paste)**를 선택합니다.
# Fleet Manager를 사용하여 OS 파일 및 디렉터리 이름 변경
Fleet Manager를 사용하여 계정의 관리형 노드에서 파일 및 디렉터리의 이름을 변경할 수 있습니다.
**Fleet Manager를 사용하여 파일 또는 디렉터리의 이름을 바꾸려면**
1. [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)에서 AWS Systems Manager 콘솔을 엽니다.
1. 탐색 창에서 **Fleet Manager**를 선택합니다.
1. 이름을 바꿀 파일 또는 디렉터리의 관리형 노드의 링크를 선택합니다.
1. **도구, 파일 시스템**을 선택합니다.
1. 파일 이름을 바꾸려면 이름을 바꾸려는 파일이 들어 있는 디렉터리의 **파일 이름(File name)**을 선택합니다. 디렉터리의 이름을 바꾸려면 이름을 바꿀 디렉터리 옆에 있는 버튼을 선택한 다음 8단계로 진행합니다.
1. 콘텐츠 이름을 바꿀 파일 옆에 있는 버튼을 선택합니다.
1. **작업, 이름 바꾸기**를 선택합니다.
1. **파일 이름** 필드에 파일의 새 이름을 입력하고 **이름 바꾸기**를 선택합니다.
# Fleet Manager를 사용하여 OS 파일 및 디렉터리 삭제
Fleet Manager를 사용하여 계정의 관리형 노드에서 파일 및 디렉터리를 삭제할 수 있습니다.
**Fleet Manager를 사용하여 파일 또는 디렉터리를 삭제하는 방법**
1. [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)에서 AWS Systems Manager 콘솔을 엽니다.
1. 탐색 창에서 **Fleet Manager**를 선택합니다.
1. 삭제하려는 파일 또는 디렉터리의 관리형 노드의 링크를 선택합니다.
1. **도구, 파일 시스템**을 선택합니다.
1. 파일을 삭제하려면 삭제하려는 파일이 들어 있는 디렉터리의 **파일 이름(File name)**을 선택합니다. 디렉터리를 삭제하려면 삭제할 디렉터리 옆에 있는 버튼을 선택한 다음 7단계로 진행합니다.
1. 삭제할 콘텐츠의 파일 옆에 있는 버튼을 선택합니다.
1. **작업, 삭제**를 선택합니다.
# Fleet Manager를 사용하여 OS 디렉터리 생성
Fleet Manager를 사용하여 계정의 관리형 노드에서 디렉터리를 생성할 수 있습니다.
**Fleet Manager를 사용하여 디렉터리를 생성하는 방법**
1. [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)에서 AWS Systems Manager 콘솔을 엽니다.
1. 탐색 창에서 **Fleet Manager**를 선택합니다.
1. 디렉터리를 생성할 관리형 노드의 링크를 선택합니다.
1. **도구, 파일 시스템**을 선택합니다.
1. 새 디렉터리를 생성할 디렉터리의 **파일 이름(File name)**을 선택합니다.
1. **디렉터리 생성(Create directory)**을 선택합니다.
1. **디렉터리 이름** 필드에 새 디렉터리 이름을 입력하고 **디렉터리 생성**을 선택합니다.
# Fleet Manager를 사용하여 OS 디렉터리 잘라내기, 복사 및 붙여넣기
Fleet Manager를 사용하여 계정의 관리형 노드에서 디렉터리를 잘라내고, 복사하며, 붙여넣을 수 있습니다.
**Fleet Manager를 사용하여 디렉터리를 복사하거나 잘라내고 붙여넣는 방법**
1. [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)에서 AWS Systems Manager 콘솔을 엽니다.
1. 탐색 창에서 **Fleet Manager**를 선택합니다.
1. 복사하거나 잘라내어 붙여넣을 파일과 관리형 노드의 링크를 선택합니다.
1. **도구, 파일 시스템**을 선택합니다.
1. 디렉터리를 복사하거나 잘라낼 디렉터리 옆에 있는 버튼을 선택한 다음, 8단계로 진행합니다.
1. **작업(Actions)** 메뉴에서 **복사(Copy)** 또는 **잘라내기(Cut)**를 선택합니다.
1. **파일 시스템(File system)** 보기에서 파일을 붙여넣을 디렉터리 옆에 있는 버튼을 선택합니다.
1. **작업(Actions)** 메뉴에서 **붙여넣기(Paste)**를 선택합니다.
# 관리형 노드 성능 모니터링
AWS Systems Manager의 도구인 Fleet Manager를 사용하여 관리형 노드에 대한 성능 데이터를 실시간으로 볼 수 있습니다. 성능 데이터는 성능 카운터에서 검색됩니다.
Fleet Manager에서 사용할 수 있는 성능 카운터는 다음과 같습니다.
+ CPU 사용률
+ 디스크 입/출력(I/O) 활용도
+ 네트워크 트래픽
+ 메모리 사용량
**참고**
Fleet Manager는 AWS Systems Manager의 도구인 Session Manager를 사용하여 성능 데이터를 검색합니다. Amazon Elastic Compute Cloud(Amazon EC2) 인스턴스에서, 인스턴스 프로파일은 관리형 인스턴스에 Session Manager가 이 기능을 사용할 수 있는 권한을 제공해야 합니다. 인스턴스 프로파일에 Session Manager 권한 추가에 대한 자세한 내용은 [기존 IAM 역할에 Session Manager 권한 추가](getting-started-add-permissions-to-existing-profile.md) 섹션을 참조하세요.
**Fleet Manager에서 성능 데이터를 보려면**
1. [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)에서 AWS Systems Manager 콘솔을 엽니다.
1. 탐색 창에서 **Fleet Manager**를 선택합니다.
1. 성능을 모니터링하려는 관리형 노드 옆에 있는 버튼을 선택합니다.
1. **세부 정보 보기**를 선택합니다.
1. **도구, 성능 카운터**를 선택합니다.
# 프로세스 작업
AWS Systems Manager의 도구인 Fleet Manager를 사용하여 관리형 노드에서 프로세스에 대한 작업을 수행할 수 있습니다. Fleet Manager를 사용하여, 프로세스에 대한 정보를 볼 수 있습니다. 예를 들어 프로세스의 핸들 및 스레드 외에 CPU 사용률 및 메모리 사용량을 확인할 수 있습니다. Fleet Manager와 함께 콘솔에서 프로세스를 시작하고 종료할 수 있습니다.
**참고**
Fleet Manager는 AWS Systems Manager의 도구인 Session Manager를 사용하여 프로세스 데이터를 검색합니다. Amazon Elastic Compute Cloud(Amazon EC2) 인스턴스에서, 인스턴스 프로파일은 관리형 인스턴스에 Session Manager가 이 기능을 사용할 수 있는 권한을 제공해야 합니다. 인스턴스 프로파일에 Session Manager 권한 추가에 대한 자세한 내용은 [기존 IAM 역할에 Session Manager 권한 추가](getting-started-add-permissions-to-existing-profile.md) 섹션을 참조하세요.
**Topics**
+ [Fleet Manager를 사용하여 OS 프로세스에 대한 세부 정보 보기](fleet-manager-view-process-details.md)
+ [Fleet Manager를 사용하여 관리형 노드에서 OS 프로세스 시작](fleet-manager-start-process.md)
+ [Fleet Manager를 사용하여 OS 프로세스 종료](fleet-manager-terminate-process.md)
# Fleet Manager를 사용하여 OS 프로세스에 대한 세부 정보 보기
Fleet Manager를 사용하여 관리형 노드의 프로세스에 대한 세부 정보를 볼 수 있습니다.
**Fleet Manager와 함께 프로세스 세부 사항 확인**
1. [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)에서 AWS Systems Manager 콘솔을 엽니다.
1. 탐색 창에서 **Fleet Manager**를 선택합니다.
1. 프로세스를 보려는 노드의 링크를 선택합니다.
1. **도구, 프로세스**를 선택합니다.
# Fleet Manager를 사용하여 관리형 노드에서 OS 프로세스 시작
Fleet Manager를 사용하여 관리형 노드에서 프로세스를 시작할 수 있습니다.
**Fleet Manager와 함께 프로세스 시작**
1. [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)에서 AWS Systems Manager 콘솔을 엽니다.
1. 탐색 창에서 **Fleet Manager**를 선택합니다.
1. 프로세스를 시작하려는 관리형 노드의 링크를 선택합니다.
1. **도구, 프로세스**를 선택합니다.
1. **새 프로세스 시작(Start new process)**을 선택합니다.
1. **프로세스 이름 또는 전체 경로** 필드에 프로세스 이름 또는 실행 파일의 전체 경로를 입력합니다.
1. (선택 사항) **작업 디렉터리** 필드에 프로세스를 실행할 디렉터리 경로를 입력합니다.
# Fleet Manager를 사용하여 OS 프로세스 종료
**Fleet Manager를 사용하여 OS 프로세스를 종료하는 방법**
1. [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)에서 AWS Systems Manager 콘솔을 엽니다.
1. 탐색 창에서 **Fleet Manager**를 선택합니다.
1. 프로세스를 시작하려는 관리형 노드의 링크를 선택합니다.
1. **도구, 프로세스**를 선택합니다.
1. 종료할 프로세스 옆에 있는 버튼을 선택합니다.
1. **작업, 프로세스 종료** 또는 **작업, 프로세스 트리 종료**를 선택합니다.
**참고**
프로세스 트리를 종료하면 해당 프로세스를 사용하는 모든 프로세스와 응용 프로그램도 종료됩니다.
# 관리형 노드의 로그 보기
AWS Systems Manager의 도구인 Fleet Manager를 사용하여 관리형 노드에 저장된 로그 데이터를 볼 수 있습니다. Windows 관리형 노드의 경우 콘솔에서 Windows 이벤트 로그를 보고 세부 정보를 복사할 수 있습니다. 이벤트 검색에 도움이 되도록 [**이벤트 수준(Event level)**], [**이벤트 ID(Event ID)**], [**이벤트 소스(Event source)**] 및 [**생성 시간(Time created)**]별로 Windows 이벤트 로그를 필터링합니다. 파일 시스템을 보는 절차를 사용하여 다른 로그 데이터를 볼 수도 있습니다. Fleet Manager를 사용하여 파일 시스템 보기에 대한 자세한 내용은 [Fleet Manager를 사용하여 OS 파일 시스템 작업](fleet-manager-file-system-management.md) 섹션을 참조하세요.
**Fleet Manager를 사용하여 Windows 이벤트 로그를 보려면**
1. AWS Systems Manager 콘솔([https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/))을 엽니다.
1. 탐색 창에서 **Fleet Manager**를 선택합니다.
1. 이벤트 로그를 보려는 관리형 노드 옆에 있는 버튼을 선택합니다.
1. **세부 정보 보기**를 선택합니다.
1. **도구, Windows 이벤트 로그**를 선택합니다.
1. 보려는 이벤트가 포함된 [**로그 이름(Log name)**]을 선택합니다.
1. 보려는 [**로그 이름(Log name)**] 옆에 있는 버튼을 선택한 다음 [**이벤트 보기(View events)**]를 선택합니다.
1. 보려는 이벤트 옆에 있는 버튼을 선택한 다음 **이벤트 세부 정보 보기(View event details)**를 선택합니다.
1. (옵션) [**JSON으로 복사(Copy as JSON)**]를 선택하여 이벤트 세부 정보를 클립보드에 복사합니다.
# Fleet Manager를 사용하여 관리형 노드에서 OS 사용자 계정 및 그룹 관리
AWS Systems Manager의 도구인 Fleet Manager를 사용하여 관리형 노드에서 운영 체제(OS) 사용자 계정 및 그룹을 관리할 수 있습니다. 예를 들어 사용자와 그룹을 생성하고 삭제할 수 있습니다. 또한 그룹 멤버십, 사용자 역할 및 상태와 같은 세부 정보를 볼 수 있습니다.
**중요**
Fleet Manager는 다양한 사용자 관리 작업을 위해 AWS Systems Manager의 도구인 Run Command와 Session Manager를 사용합니다. 결과적으로 사용자는 운영 체제 사용자 계정에 다른 방법으로는 불가능한 권한을 부여할 수 있습니다. 이는 AWS Systems Manager Agent(SSM Agent)가 루트 권한(Linux) 또는 SYSTEM 권한(Windows Server)을 사용하여 Amazon Elastic Compute Cloud(Amazon EC2) 인스턴스에서 실행되기 때문입니다. SSM Agent를 통해 루트 수준 명령에 대한 액세스 제한에 대한 자세한 내용은 [SSM Agent를 통한 루트 수준 명령에 대한 액세스 제한](ssm-agent-restrict-root-level-commands.md) 섹션을 참조하세요. 이 기능에 대한 액세스를 제한하려면 정의한 작업에만 액세스를 허용하는 AWS Identity and Access Management(IAM) 정책을 사용자에 대해 생성하는 것이 좋습니다. Fleet Manager에 대한 IAM 정책 생성에 대한 자세한 내용은 [Fleet Manager에 대한 액세스 제어](configuring-fleet-manager-permissions.md) 섹션을 참조하세요.
**Topics**
+ [Fleet Manager를 사용하여 OS 사용자 또는 그룹 생성](manage-os-user-accounts-create.md)
+ [Fleet Manager를 사용하여 사용자 또는 그룹 멤버십 업데이트](manage-os-user-accounts-update.md)
+ [Fleet Manager를 사용하여 OS 사용자 또는 그룹 삭제](manage-os-user-accounts-delete.md)
# Fleet Manager를 사용하여 OS 사용자 또는 그룹 생성
**참고**
Fleet Manager는 Session Manager를 사용하여 새 사용자의 암호를 설정합니다. Amazon EC2 인스턴스에서, 관리형 인스턴스에 연결된 인스턴스 프로파일은 Session Manager가 이 기능을 사용할 수 있는 권한을 제공해야 합니다. 인스턴스 프로파일에 Session Manager 권한 추가에 대한 자세한 내용은 [기존 IAM 역할에 Session Manager 권한 추가](getting-started-add-permissions-to-existing-profile.md) 섹션을 참조하세요.
서버에 직접 로그온하여 사용자 계정 또는 그룹을 생성하는 대신 Fleet Manager 콘솔을 사용하여 동일한 작업을 수행할 수 있습니다.
**Fleet Manager를 사용하여 OS 사용자 계정을 생성하는 방법**
1. [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)에서 AWS Systems Manager 콘솔을 엽니다.
1. 탐색 창에서 **Fleet Manager**를 선택합니다.
1. 새 사용자를 생성할 관리형 노드 옆에 있는 버튼을 선택합니다.
1. **세부 정보 보기**를 선택합니다.
1. **도구, 사용자 및 그룹**을 선택합니다.
1. [**사용자(Users)**] 탭을 선택한 다음 [**사용자 생성(Create user)**]을 선택합니다.
1. 새 사용자의 [**이름(Name)**] 값을 입력합니다.
1. (권장) [**암호 설정(Set password)**] 옆에 있는 확인란을 선택합니다. 절차가 끝나면 새 사용자의 암호를 입력하라는 메시지가 표시됩니다.
1. [**사용자 생성(Create user)**]을 선택합니다. 새 사용자의 암호를 생성하기 위해 확인란을 선택한 경우 암호 값을 입력하고 [**완료(Done)**]를 선택하라는 메시지가 나타납니다. 지정한 암호가 관리형 노드의 로컬 또는 도메인 정책에 지정된 요구 사항을 충족하지 않으면 오류가 반환됩니다.
**Fleet Manager를 사용하여 OS 그룹을 생성하는 방법**
1. [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)에서 AWS Systems Manager 콘솔을 엽니다.
1. 탐색 창에서 **Fleet Manager**를 선택합니다.
1. 새 그룹을 생성할 관리형 노드 옆에 있는 버튼을 선택합니다.
1. **세부 정보 보기**를 선택합니다.
1. **도구, 사용자 및 그룹**을 선택합니다.
1. **그룹** 탭을 선택한 다음 **그룹 생성**을 선택합니다.
1. 새 그룹의 [**이름(Name)**] 값을 입력합니다.
1. (옵션) 새 그룹에 대한 [**설명(Description)**] 값을 입력합니다.
1. (옵션) 새 그룹의 [**그룹 멤버(Group members)**]에 추가할 사용자를 선택합니다.
1. [**그룹 생성(Create group)**]을 선택합니다.
# Fleet Manager를 사용하여 사용자 또는 그룹 멤버십 업데이트
서버에 직접 로그온하여 사용자 계정 또는 그룹을 업데이트하는 대신 Fleet Manager 콘솔을 사용하여 동일한 작업을 수행할 수 있습니다.
**Fleet Manager를 사용하여 새 그룹에 OS 사용자 계정을 추가하는 방법**
1. [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)에서 AWS Systems Manager 콘솔을 엽니다.
1. 탐색 창에서 **Fleet Manager**를 선택합니다.
1. 업데이트하려는 사용자 계정이 있는 관리형 노드 옆에 있는 버튼을 선택합니다.
1. **세부 정보 보기**를 선택합니다.
1. **도구, 사용자 및 그룹**을 선택합니다.
1. **사용자** 탭을 선택합니다.
1. 업데이트하려는 사용자 옆에 있는 버튼을 선택합니다.
1. **작업, 그룹에 사용자 추가**를 선택합니다.
1. [**그룹에 추가(Add to group)**]에서 사용자를 추가할 그룹을 선택합니다.
1. [**그룹에 사용자 추가(Add user to group)**]를 선택합니다.
**Fleet Manager를 사용하여 OS 그룹의 멤버십을 편집하는 방법**
1. [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)에서 AWS Systems Manager 콘솔을 엽니다.
1. 탐색 창에서 **Fleet Manager**를 선택합니다.
1. 업데이트하려는 그룹이 있는 관리형 노드 옆에 있는 버튼을 선택합니다.
1. **세부 정보 보기**를 선택합니다.
1. **도구, 사용자 및 그룹**을 선택합니다.
1. **그룹** 탭을 선택합니다.
1. 업데이트하려는 그룹 옆에 있는 버튼을 선택합니다.
1. **작업, 그룹 수정**을 선택합니다.
1. [**그룹 멤버(Group members)**]에서 추가하거나 제거하려는 사용자를 선택합니다.
1. [**그룹 수정(Modify group)**]을 선택합니다.
# Fleet Manager를 사용하여 OS 사용자 또는 그룹 삭제
서버에 직접 로그온하여 사용자 계정 또는 그룹을 삭제하는 대신 Fleet Manager 콘솔을 사용하여 동일한 작업을 수행할 수 있습니다.
**Fleet Manager를 사용하여 OS 사용자 계정을 삭제하는 방법**
1. [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)에서 AWS Systems Manager 콘솔을 엽니다.
1. 탐색 창에서 **Fleet Manager**를 선택합니다.
1. 삭제하려는 사용자 계정이 있는 관리형 노드 옆에 있는 버튼을 선택합니다.
1. **세부 정보 보기**를 선택합니다.
1. **사용자 및 그룹**을 선택합니다.
1. **사용자** 탭을 선택합니다.
1. 삭제하려는 사용자 옆에 있는 버튼을 선택합니다.
1. **작업, 로컬 사용자 삭제**를 선택합니다.
**Fleet Manager를 사용하여 OS 그룹을 삭제하는 방법**
1. [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)에서 AWS Systems Manager 콘솔을 엽니다.
1. 탐색 창에서 **Fleet Manager**를 선택합니다.
1. 삭제하려는 그룹이 있는 관리형 노드 옆에 있는 버튼을 선택합니다.
1. **세부 정보 보기**를 선택합니다.
1. **도구, 사용자 및 그룹**을 선택합니다.
1. [**그룹(Group)**] 탭을 선택합니다.
1. 업데이트하려는 그룹 옆에 있는 버튼을 선택합니다.
1. **작업, 로컬 그룹 삭제**를 선택합니다.
# 관리형 노드의 Windows 레지스트리 관리
AWS Systems Manager의 도구인 Fleet Manager를 사용하여 Windows Server 관리형 노드에서 레지스트리를 관리할 수 있습니다. Fleet Manager 콘솔에서 레지스트리 항목과 값을 생성, 복사, 업데이트 및 삭제할 수 있습니다.
**중요**
레지스트리를 수정하기 전에 레지스트리 백업을 생성하거나 관리형 노드에 연결된 루트 Amazon Elastic Block Store(Amazon EBS) 볼륨의 스냅샷을 생성하는 것이 좋습니다. 레지스트리를 잘못 수정하면 심각한 문제가 발생할 수 있습니다. 이러한 문제로 인해 운영 체제를 다시 설치하거나 스냅샷에서 관리형 노드의 루트 볼륨을 복원해야 할 수 있습니다. AWS는 이러한 문제가 해결될 수 있다고 보장하지 않습니다. 레지스트리를 수정할 때는 사용자의 주의가 필요합니다. 모든 레지스트리 변경과 백업이 있는지 확인하는 것은 사용자의 책임입니다.
## Windows 레지스트리 키 또는 항목 생성
**Fleet Manager를 사용하여 Windows 레지스트리 키를 생성하려면**
1. [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)에서 AWS Systems Manager 콘솔을 엽니다.
1. 탐색 창에서 **Fleet Manager**를 선택합니다.
1. 레지스트리 키를 생성할 관리형 노드 옆에 있는 버튼을 선택합니다.
1. **세부 정보 보기**를 선택합니다.
1. **도구, Windows 레지스트리**를 선택합니다.
1. [**레지스트리 이름(Registry name)**]을 선택하여 새 레지스트리 키를 만들 Hive를 선택합니다.
1. **생성, 레지스트리 키 생성**을 선택합니다.
1. 새 키를 생성할 레지스트리 항목 옆에 있는 버튼을 선택합니다.
1. [**레지스트리 키 생성(Create registry key)**]을 선택합니다.
1. 새 레지스트리 키의 [**이름(Name)**] 값을 입력하고 [**제출(Submit)**]을 선택합니다.
**Fleet Manager를 사용하여 Windows 레지스트리 항목을 생성하려면**
1. [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)에서 AWS Systems Manager 콘솔을 엽니다.
1. 탐색 창에서 **Fleet Manager**를 선택합니다.
1. 레지스트리 항목을 생성할 인스턴스 옆에 있는 버튼을 선택합니다.
1. **세부 정보 보기**를 선택합니다.
1. **도구, Windows 레지스트리**를 선택합니다.
1. [**레지스트리 이름(Registry name)**]을 선택하여 새 레지스트리 항목을 생성할 Hive 및 후속 레지스트리 키를 선택합니다.
1. **생성, 레지스트리 항목 생성**을 선택합니다.
1. 새 레지스트리 항목의 [**이름(Name)**] 값을 입력합니다.
1. 레지스트리 항목에 대해 생성할 값의 [**유형(Type)**]을 선택합니다. 레지스트리 값 유형에 대한 자세한 내용은 [레지스트리 값 유형](https://docs.microsoft.com/en-us/windows/win32/sysinfo/registry-value-types)을 참조하세요.
1. 새 레지스트리 항목의 [**값(Value)**]을 입력합니다.
## Windows 레지스트리 항목 업데이트
**Fleet Manager를 사용하여 Windows 레지스트리 항목을 업데이트하려면**
1. [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)에서 AWS Systems Manager 콘솔을 엽니다.
1. 탐색 창에서 **Fleet Manager**를 선택합니다.
1. 레지스트리 항목을 업데이트할 관리형 노드 옆에 있는 버튼을 선택합니다.
1. **세부 정보 보기**를 선택합니다.
1. **도구, Windows 레지스트리**를 선택합니다.
1. [**레지스트리 이름(Registry name)**]을 선택하여 업데이트할 Hive 및 후속 레지스트리 키를 선택합니다.
1. 업데이트할 레지스트리 항목 옆에 있는 버튼을 선택합니다.
1. **작업, 레지스트리 항목 업데이트**를 선택합니다.
1. 레지스트리 항목의 [**값(Value)**]을 새로 입력합니다.
1. **업데이트**를 선택합니다.
## Windows 레지스트리 항목 또는 키 삭제
**Fleet Manager를 사용하여 Windows 레지스트리 키를 삭제하려면**
1. [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)에서 AWS Systems Manager 콘솔을 엽니다.
1. 탐색 창에서 **Fleet Manager**를 선택합니다.
1. 레지스트리 키를 생성할 관리형 노드 옆에 있는 버튼을 선택합니다.
1. **도구, Windows 레지스트리**를 선택합니다.
1. [**레지스트리 이름(Registry name)**]을 선택하여 삭제할 Hive 및 후속 레지스트리 키를 선택합니다.
1. 삭제할 레지스트리 키 옆에 있는 버튼을 선택합니다.
1. **작업, 레지스트리 키 삭제**를 선택합니다.
**Fleet Manager를 사용하여 Windows 레지스트리 항목을 삭제하려면**
1. [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)에서 AWS Systems Manager 콘솔을 엽니다.
1. 탐색 창에서 **Fleet Manager**를 선택합니다.
1. 레지스트리 항목을 생성할 관리형 노드 옆에 있는 버튼을 선택합니다.
1. **세부 정보 보기**를 선택합니다.
1. **도구, Windows 레지스트리**를 선택합니다.
1. [**레지스트리 이름(Registry name)**]을 선택하여 삭제할 항목이 들어 있는 Hive 및 후속 레지스트리 키를 선택합니다.
1. 삭제할 레지스트리 항목 옆에 있는 버튼을 선택합니다.
1. **작업, 레지스트리 항목 삭제**를 선택합니다.
# 기본 호스트 관리 구성을 사용한 자동 EC2 인스턴스 관리
기본 호스트 관리 구성 설정을 통해 AWS Systems Manager에서 Amazon EC2 인스턴스를 자동으로 관리형 인스턴스로 관리할 수 있습니다. 관리형 인스턴스는 Systems Manager에 사용하도록 구성된 EC2 인스턴스입니다.
Systems Manager로 인스턴스를 관리하는 경우의 이점은 다음과 같습니다.
+ Session Manager를 사용하여 안전하게 EC2 인스턴스에 연결합니다.
+ Patch Manager를 사용하여 자동 패치 스캔을 수행합니다.
+ Systems Manager Inventory를 사용하여 인스턴스에 대한 세부 정보를 봅니다.
+ Fleet Manager를 사용하여 인스턴스를 추적하고 관리합니다.
+ SSM Agent를 자동으로 최신 상태로 유지합니다.
*Fleet Manager, Inventory, Patch Manager, Session Manager는 Systems Manager의 도구입니다.*
기본 호스트 관리 구성을 사용하여 AWS Identity and Access Management(IAM) 인스턴스 프로파일을 수동으로 생성하지 않고 EC2 인스턴스를 관리할 수 있습니다. 그 대신에 기본 IAM 역할이 활성화된 AWS 계정 및 AWS 리전의 모든 인스턴스를 관리하는 권한이 Systems Manager에 확보되도록 기본 호스트 관리 구성을 통해 해당 역할이 생성되고 적용됩니다.
제공된 권한이 사용 사례에 충분하지 않은 경우 기본 호스트 관리 구성에서 생성된 기본 IAM 역할에 정책을 추가할 수도 있습니다. 또는 기본 IAM 역할에서 제공하는 모든 기능에 대한 권한이 필요하지 않은 경우 사용자 지정 역할과 정책을 직접 생성할 수 있습니다. 기본 호스트 관리 구성에 대해 선택한 IAM 역할의 모든 변경 사항은 리전 및 계정의 모든 관리형 Amazon EC2 인스턴스에 적용됩니다.
기본 호스트 관리 구성에서 사용하는 정책에 대한 자세한 내용은 [AWS 관리형 정책: AmazonSSMManagedEC2InstanceDefaultPolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-AmazonSSMManagedEC2InstanceDefaultPolicy) 섹션을 참조하세요.
**최소 권한 액세스 구현**
이 주제의 이 절차는 관리자만 수행할 수 있습니다. 따라서 관리자가 아닌 사용자가 기본 호스트 관리 구성을 구성하거나 수정하지 못하도록 하려면 **최소 권한 액세스를 구현하는 것이 좋습니다. 기본 호스트 관리 구성에 대한 액세스를 제한하는 예제 정책을 보려면 이 주제의 [기본 호스트 관리 구성의 최소 권한 정책 예제](#least-privilege-examples) 이후를 참조하세요.
**중요**
기본 호스트 관리 구성을 사용하여 등록된 인스턴스의 등록 정보는 `var/lib/amazon/ssm` 또는 `C:\ProgramData\Amazon` 디렉터리에 로컬로 저장됩니다. 이러한 디렉토리 또는 해당 파일을 제거하면 인스턴스가 기본 호스트 관리 구성을 사용하여 시스템 관리자에 연결하는 데 필요한 보안 인증을 획득하지 못하게 됩니다. 이러한 경우 IAM 인스턴스 프로파일을 사용하여 인스턴스에 필요한 권한을 제공하거나 인스턴스를 다시 생성해야 합니다.
**Topics**
+ [사전 조건](#dhmc-prerequisites)
+ [기본 호스트 관리 구성 설정 활성화](#dhmc-activate)
+ [기본 호스트 관리 구성 설정 비활성화](#dhmc-deactivate)
+ [기본 호스트 관리 구성의 최소 권한 정책 예제](#least-privilege-examples)
## 사전 조건
설정을 활성화하는 AWS 리전 및 AWS 계정에서 기본 호스트 관리 구성을 사용하려면 다음과 같은 요구 사항을 충족해야 합니다.
+ 관리할 인스턴스에서 IMDSv2(인스턴스 메타데이터 서비스 버전 2)를 사용해야 합니다.
기본 호스트 관리 구성은 인스턴스 메타데이터 서비스 버전 1을 지원하지 않습니다. IMDSv2로 전환에 대한 자세한 내용은 *Amazon EC2 사용 설명서*의 [인스턴스 메타데이터 서비스 버전 2 사용으로 전환](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-metadata-transition-to-version-2.html)을 참조하세요.
+ 인스턴스를 관리하려면 SSM Agent version 3.2.582.0 이상을 설치해야 합니다.
인스턴스에 설치된 SSM Agent 버전 확인에 대한 자세한 내용은 [SSM Agent 버전 번호 확인](ssm-agent-get-version.md) 섹션을 참조하세요.
SSM Agent 업데이트에 대한 자세한 내용은 [SSM Agent 자동 업데이트](ssm-agent-automatic-updates.md#ssm-agent-automatic-updates-console) 섹션을 참조하세요.
+ 이 주제의 작업을 수행하는 관리자라면 [GetServiceSetting](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_GetServiceSetting.html), [ResetServiceSetting](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_ResetServiceSetting.html) 및 [UpdateServiceSetting](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_UpdateServiceSetting.html) API 작업에 대한 권한이 있어야 합니다. 또한 `AWSSystemsManagerDefaultEC2InstanceManagementRole` IAM 역할에 대한 `iam:PassRole` 권한이 있어야 합니다. 다음은 이러한 권한을 제공하는 정책 예제입니다. 각 *example resource placeholder*를 사용자의 정보로 바꿉니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ssm:GetServiceSetting",
"ssm:ResetServiceSetting",
"ssm:UpdateServiceSetting"
],
"Resource": "arn:aws:ssm:us-east-1:111122223333:servicesetting/ssm/managed-instance/default-ec2-instance-management-role"
},
{
"Effect": "Allow",
"Action": [
"iam:PassRole"
],
"Resource": "arn:aws:iam::111122223333:role/service-role/AWSSystemsManagerDefaultEC2InstanceManagementRole",
"Condition": {
"StringEquals": {
"iam:PassedToService": [
"ssm.amazonaws.com"
]
}
}
}
]
}
```
------
+ 시스템 관리자를 사용하여 관리할 EC2 인스턴스에 이미 IAM 인스턴스 프로파일이 연결되었으면 `ssm:UpdateInstanceInformation` 작업을 허용하는 권한을 제거해야 합니다. SSM Agent에서는 기본 호스트 관리 구성 권한을 사용하기 전에 인스턴스 프로파일 권한을 사용하려고 시도합니다. IAM 인스턴스 프로파일에서 `ssm:UpdateInstanceInformation` 작업을 허용하면 인스턴스에서 기본 호스트 관리 구성 권한을 사용하지 않습니다.
## 기본 호스트 관리 구성 설정 활성화
Fleet Manager 콘솔에서 또는 AWS Command Line Interface이나 AWS Tools for Windows PowerShell을 사용하여 기본 호스트 관리 구성을 활성화할 수 있습니다.
Amazon EC2 인스턴스를 이 설정으로 관리할 각 리전에서 기본 호스트 관리 구성을 하나씩 켜야 합니다.
기본 호스트 관리 구성을 켠 후 인스턴스가 다음 절차의 5단계에서 선택한 역할의 자격 증명을 사용하는 데 최대 30분이 걸릴 수 있습니다.
**기본 호스트 관리 구성을 활성화하는 방법(콘솔)**
1. [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)에서 AWS Systems Manager 콘솔을 엽니다.
1. 탐색 창에서 **Fleet Manager**를 선택합니다.
1. **계정 관리, 기본 호스트 관리 구성**을 선택합니다.
1. **기본 호스트 관리 구성 활성화**를 켭니다.
1. 인스턴스에 대해 Systems Manager 도구를 활성화하는 데 사용되는 AWS Identity and Access Management(IAM) 역할을 선택합니다. 기본 호스트 관리 구성에서 제공하는 기본 역할을 사용하는 것이 좋습니다. 여기에는 Systems Manager를 사용하여 Amazon EC2 인스턴스를 관리하는 데 필요한 최소 권한 세트가 포함되어 있습니다. 사용자 지정 역할을 사용하는 것을 선호하는 경우 역할의 신뢰 정책에서 Systems Manager를 신뢰할 수 있는 엔터티로 허용해야 합니다.
1. **구성**을 선택하여 설정을 완료합니다.
**기본 호스트 관리 구성을 활성화하는 방법(명령줄)**
1. 다음 신뢰 관계 정책이 포함된 JSON 파일을 로컬 컴퓨터에 생성합니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement":[
{
"Sid":"",
"Effect":"Allow",
"Principal":{
"Service":"ssm.amazonaws.com"
},
"Action":"sts:AssumeRole"
}
]
}
```
------
1. AWS CLI 또는 Tools for Windows PowerShell을 열고 로컬 시스템의 운영 체제 유형에 따라 다음과 같은 명령 중 하나를 실행하여 계정에서 서비스 역할을 생성합니다. 각 *example resource placeholder*를 사용자의 정보로 바꿉니다.
------
#### [ Linux & macOS ]
```
aws iam create-role \
--role-name AWSSystemsManagerDefaultEC2InstanceManagementRole \
--path /service-role/ \
--assume-role-policy-document file://trust-policy.json
```
------
#### [ Windows ]
```
aws iam create-role ^
--role-name AWSSystemsManagerDefaultEC2InstanceManagementRole ^
--path /service-role/ ^
--assume-role-policy-document file://trust-policy.json
```
------
#### [ PowerShell ]
```
New-IAMRole `
-RoleName "AWSSystemsManagerDefaultEC2InstanceManagementRole" `
-Path "/service-role/" `
-AssumeRolePolicyDocument "file://trust-policy.json"
```
------
1. 다음 명령을 실행하여 새로 생성한 역할에 `AmazonSSMManagedEC2InstanceDefaultPolicy` 관리형 정책을 연결합니다. 각 *example resource placeholder*를 사용자의 정보로 바꿉니다.
------
#### [ Linux & macOS ]
```
aws iam attach-role-policy \
--policy-arn arn:aws:iam::aws:policy/AmazonSSMManagedEC2InstanceDefaultPolicy \
--role-name AWSSystemsManagerDefaultEC2InstanceManagementRole
```
------
#### [ Windows ]
```
aws iam attach-role-policy ^
--policy-arn arn:aws:iam::aws:policy/AmazonSSMManagedEC2InstanceDefaultPolicy ^
--role-name AWSSystemsManagerDefaultEC2InstanceManagementRole
```
------
#### [ PowerShell ]
```
Register-IAMRolePolicy `
-PolicyArn "arn:aws:iam::aws:policy/AmazonSSMManagedEC2InstanceDefaultPolicy" `
-RoleName "AWSSystemsManagerDefaultEC2InstanceManagementRole"
```
------
1. AWS CLI 또는 Tools for Windows PowerShell을 열고 다음 명령을 실행합니다. 각 *example resource placeholder*를 사용자의 정보로 바꿉니다.
------
#### [ Linux & macOS ]
```
aws ssm update-service-setting \
--setting-id arn:aws:ssm:region:account-id:servicesetting/ssm/managed-instance/default-ec2-instance-management-role \
--setting-value service-role/AWSSystemsManagerDefaultEC2InstanceManagementRole
```
------
#### [ Windows ]
```
aws ssm update-service-setting ^
--setting-id arn:aws:ssm:region:account-id:servicesetting/ssm/managed-instance/default-ec2-instance-management-role ^
--setting-value service-role/AWSSystemsManagerDefaultEC2InstanceManagementRole
```
------
#### [ PowerShell ]
```
Update-SSMServiceSetting `
-SettingId "arn:aws:ssm:region:account-id:servicesetting/ssm/managed-instance/default-ec2-instance-management-role" `
-SettingValue "service-role/AWSSystemsManagerDefaultEC2InstanceManagementRole"
```
------
명령이 성공해도 출력은 없습니다.
1. 다음 명령을 실행하여 현재 AWS 계정 및 AWS 리전에서 기본 호스트 관리 구성에 대한 현재 서비스 설정을 봅니다.
------
#### [ Linux & macOS ]
```
aws ssm get-service-setting \
--setting-id arn:aws:ssm:region:account-id:servicesetting/ssm/managed-instance/default-ec2-instance-management-role
```
------
#### [ Windows ]
```
aws ssm get-service-setting ^
--setting-id arn:aws:ssm:region:account-id:servicesetting/ssm/managed-instance/default-ec2-instance-management-role
```
------
#### [ PowerShell ]
```
Get-SSMServiceSetting `
-SettingId "arn:aws:ssm:region:account-id:servicesetting/ssm/managed-instance/default-ec2-instance-management-role"
```
------
명령은 다음과 같은 정보를 반환합니다.
```
{
"ServiceSetting": {
"SettingId": "/ssm/managed-instance/default-ec2-instance-management-role",
"SettingValue": "service-role/AWSSystemsManagerDefaultEC2InstanceManagementRole",
"LastModifiedDate": "2022-11-28T08:21:03.576000-08:00",
"LastModifiedUser": "System",
"ARN": "arn:aws:ssm:us-east-2:-123456789012:servicesetting/ssm/managed-instance/default-ec2-instance-management-role",
"Status": "Custom"
}
}
```
## 기본 호스트 관리 구성 설정 비활성화
Fleet Manager 콘솔에서 또는 AWS Command Line Interface이나 AWS Tools for Windows PowerShell을 사용하여 기본 호스트 관리 구성을 비활성화할 수 있습니다.
Amazon EC2 인스턴스를 더는 이 구성으로 관리하지 않으려는 각 리전에서 기본 호스트 관리 구성 설정을 하나씩 꺼야 합니다. 한 리전에서 비활성화하면 모든 리전에서 비활성화되는 것이 아닙니다.
기본 호스트 관리 구성을 비활성화하고 Systems Manager에 대한 액세스를 허용하는 Amazon EC2 인스턴스에 인스턴스 프로파일을 연결하지 않으면 Systems Manager에서 해당 인스턴스를 더는 관리하지 않습니다.
**기본 호스트 관리 구성을 비활성화하는 방법(콘솔)**
1. [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)에서 AWS Systems Manager 콘솔을 엽니다.
1. 탐색 창에서 **Fleet Manager**를 선택합니다.
1. **계정 관리, 기본 호스트 관리 구성**을 선택합니다.
1. **기본 호스트 관리 구성 활성화**를 끕니다.
1. **구성**을 선택하여 기본 호스트 관리 구성을 비활성화합니다.
**기본 호스트 관리 구성을 비활성화하는 방법(명령줄)**
+ AWS CLI 또는 Tools for Windows PowerShell을 열고 다음 명령을 실행합니다. 각 *example resource placeholder*를 사용자의 정보로 바꿉니다.
------
#### [ Linux & macOS ]
```
aws ssm reset-service-setting \
--setting-id arn:aws:ssm:region:account-id:servicesetting/ssm/managed-instance/default-ec2-instance-management-role
```
------
#### [ Windows ]
```
aws ssm reset-service-setting ^
--setting-id arn:aws:ssm:region:account-id:servicesetting/ssm/managed-instance/default-ec2-instance-management-role
```
------
#### [ PowerShell ]
```
Reset-SSMServiceSetting `
-SettingId "arn:aws:ssm:region:account-id:servicesetting/ssm/managed-instance/default-ec2-instance-management-role"
```
------
## 기본 호스트 관리 구성의 최소 권한 정책 예제
다음과 같은 샘플 정책에서는 소속 조직의 멤버가 계정의 기본 호스트 관리 구성 설정을 변경하지 못하도록 하는 방법을 보여줍니다.
### AWS Organizations에 대한 서비스 제어 정책
다음 정책에서는 소속 AWS Organizations의 관리자 멤버가 아닌 멤버가 기본 호스트 관리 구성 설정을 업데이트하지 못하도록 하는 방법을 보여줍니다. 각 *example resource placeholder*를 사용자의 정보로 바꿉니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [{
"Effect": "Deny",
"Action": [
"ssm:UpdateServiceSetting",
"ssm:ResetServiceSetting"
],
"Resource": "arn:aws:ssm:*:*:servicesetting/ssm/managed-instance/default-ec2-instance-management-role",
"Condition": {
"StringNotEqualsIgnoreCase": {
"aws:PrincipalTag/job-function": [
"administrator"
]
}
}
},
{
"Effect": "Deny",
"Action": [
"iam:PassRole"
],
"Resource": "arn:aws:iam::*:role/service-role/AWSSystemsManagerDefaultEC2InstanceManagementRole",
"Condition": {
"StringEquals": {
"iam:PassedToService": "ssm.amazonaws.com"
},
"StringNotEqualsIgnoreCase": {
"aws:PrincipalTag/job-function": [
"administrator"
]
}
}
},
{
"Effect": "Deny",
"Resource": "arn:aws:iam::*:role/service-role/AWSSystemsManagerDefaultEC2InstanceManagementRole",
"Action": [
"iam:AttachRolePolicy",
"iam:DeleteRole"
],
"Condition": {
"StringNotEqualsIgnoreCase": {
"aws:PrincipalTag/job-function": [
"administrator"
]
}
}
}
]
}
```
------
### IAM 보안 주체 정책
다음 정책에서는 소속 AWS Organizations의 IAM 그룹, 역할 또는 사용자가 기본 호스트 관리 구성 설정을 업데이트하지 못하도록 하는 방법을 보여줍니다. 각 *example resource placeholder*를 사용자의 정보로 바꿉니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Action": [
"ssm:UpdateServiceSetting",
"ssm:ResetServiceSetting"
],
"Resource": "arn:aws:ssm:us-east-1:111122223333:servicesetting/ssm/managed-instance/default-ec2-instance-management-role"
},
{
"Effect": "Deny",
"Action": [
"iam:AttachRolePolicy",
"iam:DeleteRole",
"iam:PassRole"
],
"Resource": "arn:aws:iam::111122223333:role/service-role/AWSSystemsManagerDefaultEC2InstanceManagementRole"
}
]
}
```
------
# Remote Desktop을 사용하여 Windows Server 관리형 인스턴스에 연결
Remote Desktop Protocol(RDP)를 사용하여 Windows Server Amazon Elastic Compute Cloud(Amazon EC2) 인스턴스에 연결하는 데 AWS Systems Manager의 도구인 Fleet Manager를 사용할 수 있습니다. Fleet Manager [Amazon DCV](https://docs.aws.amazon.com/dcv/latest/adminguide/what-is-dcv.html)로 구동되는 원격 데스크톱에서는 Systems Manager 콘솔에서 직접 Windows Server 인스턴스에 안전하게 연결할 수 있습니다. 단일 브라우저 창에서 4개까지 동시에 연결할 수 있습니다.
Fleet Manager 원격 데스크톱 API의 이름은 AWS Systems Manager GUI Connect입니다. Systems Manager GUI Connect API 사용에 대한 자세한 내용은 *[AWS Systems Manager GUI Connect API 참조](https://docs.aws.amazon.com/ssm-guiconnect/latest/APIReference)*를 참조하세요.
현재 Windows Server 2012 RTM 이상이 실행되는 원격 데스크톱에서만 인스턴스를 사용할 수 있습니다. 원격 데스크톱에서는 영어 입력만 지원됩니다.
Fleet Manager 원격 데스크톱은 콘솔 전용 서비스이며 관리형 인스턴스에 대한 명령줄 연결을 지원하지 않습니다. 쉘을 통해 Windows Server 관리형 인스턴스에 연결하려면 AWS Systems Manager의 또 다른 도구인 Session Manager를 사용할 수 있습니다. 자세한 내용은 [AWS Systems Manager Session Manager](session-manager.md) 섹션을 참조하세요.
**참고**
RDP 연결 기간은 AWS Identity and Access Management(IAM) 자격 증명 기간에 따라 결정되지 않습니다. 대신 연결은 최대 연결 기간 또는 유휴 시간 제한 중 먼저 도달하는 시점까지 유지됩니다. 자세한 내용은 [원격 연결 기간 및 동시성](#rdp-duration-concurrency) 섹션을 참조하세요.
인스턴스에 Systems Manager와의 상호 작용을 허용하는 AWS Identity and Access Management(IAM) 권한 구성에 대한 자세한 내용은 [Systems Manager에 대한 인스턴스 권한 구성](setup-instance-permissions.md)을 참조하세요.
**Topics**
+ [환경 설정](#rdp-prerequisites)
+ [원격 데스크톱 IAM 권한 구성](#rdp-iam-policy-examples)
+ [원격 데스크톱 연결 인증](#rdp-authentication)
+ [원격 연결 기간 및 동시성](#rdp-duration-concurrency)
+ [Systems Manager GUI Connect의 AWS IAM Identity Center 속성 처리](#iam-identity-center-attribute-handling)
+ [원격 데스크톱을 사용하여 관리형 노드에 연결](#rdp-connect-to-node)
+ [현재 연결과 완료된 연결에 대한 정보 보기](#list-connections)
## 환경 설정
원격 데스크톱 사용을 시작하기 전에 다음과 같은 요구 사항이 환경에서 충족되는지 확인하세요.
+ **관리형 노드 구성**
Amazon EC2 인스턴스가 Systems Manager에서 [관리형 노드](fleet-manager-managed-nodes.md)로 구성되어 있는지 확인하세요.
+ **SSM Agent 최소 버전**
노드에서 SSM Agent 버전 3.0.222.0 이상이 실행되는지 확인하세요. 노드에서 실행되는 에이전트 버전을 확인하는 방법에 대한 내용은 [SSM Agent 버전 번호 확인](ssm-agent-get-version.md)을 참조하세요. SSM Agent 설치 또는 업데이트에 대한 자세한 내용은 [SSM Agent 작업](ssm-agent.md) 섹션을 참조하세요.
+ **RDP 포트 구성**
원격 연결을 수락하려면 Windows Server 노드의 Remote Desktop Services 서비스에서 기본 RDP 포트 3389를 사용해야 합니다. AWS에서 제공하는 Amazon Machine Images(AMIs)의 기본 구성입니다. 원격 데스크톱을 사용하려고 인바운드 포트를 명시적으로 열지 않아도 됩니다.
+ **키보드 기능을 위한 PSReadLine 모듈 버전**
PowerShell에서 키보드가 제대로 작동하는지 확인하려면 Windows Server 2022가 실행되는 노드에 PSReadLine 모듈 버전 2.2.2 이상이 있는지 확인하세요. 이전 버전이 실행되고 있다면 다음 명령을 사용하여 필요한 버전을 설치할 수 있습니다.
```
Install-PackageProvider -Name NuGet -MinimumVersion 2.8.5.201 -Force
```
NuGet 패키지 공급자를 설치한 후 다음 명령을 실행합니다.
```
Install-Module `
-Name PSReadLine `
-Repository PSGallery `
-MinimumVersion 2.2.2 -Force
```
+ **Session Manager 구성**
원격 데스크톱을 사용할 수 있으려면 Session Manager 설정 전제 조건을 완료해야 합니다. 원격 데스크톱을 사용하여 인스턴스에 연결하면 AWS 계정 및 AWS 리전에 대해 정의된 모든 세션 기본 설정이 적용됩니다. 자세한 내용은 [Session Manager 설정](session-manager-getting-started.md) 섹션을 참조하세요.
**참고**
Amazon Simple Storage Service(S3)를 사용하여 Session Manager 활동 로그를 기록하는 경우에는 원격 데스크톱 연결의 `bucket_name/Port/stderr`에서 다음과 같은 오류가 발생합니다. 이 오류는 예상되는 동작이며 무시해도 됩니다.
```
Setting up data channel with id SESSION_ID failed: failed to create websocket for datachannel with error: CreateDataChannel failed with no output or error: createDataChannel request failed: unexpected response from the service
Session is already terminated
```
## 원격 데스크톱 IAM 권한 구성
Systems Manager 및 Session Manager에 필요한 IAM 권한 외에도 사용하는 역할 또는 사용자에 연결을 시작할 수 있는 권한이 부여되어야 합니다.
**연결을 시작하기 위한 권한**
콘솔에서 EC2 인스턴스에 RDP를 연결하려면 다음 권한이 필요합니다.
+ `ssm-guiconnect:CancelConnection`
+ `ssm-guiconnect:GetConnection`
+ `ssm-guiconnect:StartConnection`
**연결을 나열하기 위한 권한**
콘솔에서 연결 목록을 보려면 다음 권한이 필요합니다.
`ssm-guiconnect:ListConnections`
다음은 사용자 또는 역할을 연결하여 다양한 원격 데스크톱 상호 작용 유형을 허용할 수 있는 IAM 정책 예제입니다. 각 *example resource placeholder*를 사용자의 정보로 바꿉니다.
### EC2 인스턴스 연결을 위한 표준 정책
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "EC2",
"Effect": "Allow",
"Action": [
"ec2:DescribeInstances",
"ec2:GetPasswordData"
],
"Resource": "*"
},
{
"Sid": "SSM",
"Effect": "Allow",
"Action": [
"ssm:DescribeInstanceProperties",
"ssm:GetCommandInvocation",
"ssm:GetInventorySchema"
],
"Resource": "*"
},
{
"Sid": "TerminateSession",
"Effect": "Allow",
"Action": [
"ssm:TerminateSession"
],
"Resource": "*",
"Condition": {
"StringLike": {
"ssm:resourceTag/aws:ssmmessages:session-id": [
"${aws:userid}"
]
}
}
},
{
"Sid": "SSMStartSession",
"Effect": "Allow",
"Action": [
"ssm:StartSession"
],
"Resource": [
"arn:aws:ec2:*:111122223333:instance/*",
"arn:aws:ssm:*:111122223333:managed-instance/*",
"arn:aws:ssm:*::document/AWS-StartPortForwardingSession"
],
"Condition": {
"ForAnyValue:StringEquals": {
"aws:CalledVia": "ssm-guiconnect.amazonaws.com"
}
}
},
{
"Sid": "GuiConnect",
"Effect": "Allow",
"Action": [
"ssm-guiconnect:CancelConnection",
"ssm-guiconnect:GetConnection",
"ssm-guiconnect:StartConnection",
"ssm-guiconnect:ListConnections"
],
"Resource": "*"
}
]
}
```
------
### 특정 태그가 있는 EC2 인스턴스에 연결하기 위한 정책
**참고**
다음 IAM 정책에서 `SSMStartSession` 섹션에는 `ssm:StartSession` 작업에 대한 Amazon 리소스 이름(ARN)이 필요합니다. 표시된 대로, 사용자가 지정한 ARN에는 AWS 계정 ID가 *필요하지 않습니다*. 계정 ID를 지정하면 Fleet Manager에서 `AccessDeniedException`을 반환합니다.
예제 정책 아래쪽에 있는 `AccessTaggedInstances` 섹션에도 `ssm:StartSession`에 대한 ARN이 필요합니다. 이 ARN의 경우 AWS 계정 ID를 지정합니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "EC2",
"Effect": "Allow",
"Action": [
"ec2:DescribeInstances",
"ec2:GetPasswordData"
],
"Resource": "*"
},
{
"Sid": "SSM",
"Effect": "Allow",
"Action": [
"ssm:DescribeInstanceProperties",
"ssm:GetCommandInvocation",
"ssm:GetInventorySchema"
],
"Resource": "*"
},
{
"Sid": "SSMStartSession",
"Effect": "Allow",
"Action": [
"ssm:StartSession"
],
"Resource": [
"arn:aws:ssm:*::document/AWS-StartPortForwardingSession"
],
"Condition": {
"ForAnyValue:StringEquals": {
"aws:CalledVia": "ssm-guiconnect.amazonaws.com"
}
}
},
{
"Sid": "AccessTaggedInstances",
"Effect": "Allow",
"Action": [
"ssm:StartSession"
],
"Resource": [
"arn:aws:ec2:*:111122223333:instance/*",
"arn:aws:ssm:*:111122223333:managed-instance/*"
],
"Condition": {
"StringLike": {
"ssm:resourceTag/tag key": [
"tag value"
]
}
}
},
{
"Sid": "GuiConnect",
"Effect": "Allow",
"Action": [
"ssm-guiconnect:CancelConnection",
"ssm-guiconnect:GetConnection",
"ssm-guiconnect:StartConnection",
"ssm-guiconnect:ListConnections"
],
"Resource": "*"
}
]
}
```
------
### AWS IAM Identity Center 사용자가 EC2 인스턴스에 연결하기 위한 정책
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "SSO",
"Effect": "Allow",
"Action": [
"sso:ListDirectoryAssociations*",
"identitystore:DescribeUser"
],
"Resource": "*"
},
{
"Sid": "EC2",
"Effect": "Allow",
"Action": [
"ec2:DescribeInstances",
"ec2:GetPasswordData"
],
"Resource": "*"
},
{
"Sid": "SSM",
"Effect": "Allow",
"Action": [
"ssm:DescribeInstanceProperties",
"ssm:GetCommandInvocation",
"ssm:GetInventorySchema"
],
"Resource": "*"
},
{
"Sid": "TerminateSession",
"Effect": "Allow",
"Action": [
"ssm:TerminateSession"
],
"Resource": "*",
"Condition": {
"StringLike": {
"ssm:resourceTag/aws:ssmmessages:session-id": [
"${aws:userName}"
]
}
}
},
{
"Sid": "SSMStartSession",
"Effect": "Allow",
"Action": [
"ssm:StartSession"
],
"Resource": [
"arn:aws:ec2:*:*:instance/*",
"arn:aws:ssm:*:*:managed-instance/*",
"arn:aws:ssm:*:*:document/AWS-StartPortForwardingSession"
],
"Condition": {
"ForAnyValue:StringEquals": {
"aws:CalledVia": "ssm-guiconnect.amazonaws.com"
}
}
},
{
"Sid": "SSMSendCommand",
"Effect": "Allow",
"Action": [
"ssm:SendCommand"
],
"Resource": [
"arn:aws:ec2:*:*:instance/*",
"arn:aws:ssm:*:*:managed-instance/*",
"arn:aws:ssm:*:*:document/AWSSSO-CreateSSOUser"
]
},
{
"Sid": "GuiConnect",
"Effect": "Allow",
"Action": [
"ssm-guiconnect:CancelConnection",
"ssm-guiconnect:GetConnection",
"ssm-guiconnect:StartConnection",
"ssm-guiconnect:ListConnections"
],
"Resource": "*"
}
]
}
```
------
## 원격 데스크톱 연결 인증
원격 연결을 설정할 때 Windows 보안 인증 정보 또는 인스턴스와 연결된 Amazon EC2 키 페어(`.pem` 파일)를 사용하여 인증할 수 있습니다. 키 페어에 대한 내용은 *Amazon EC2 사용 설명서*의 [Amazon EC2 키 페어 및 Windows 인스턴스](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/ec2-key-pairs.html)를 참조하세요.
또는 AWS IAM Identity Center을 사용하여 AWS Management Console 인증을 받은 경우 추가 보안 인증 정보를 제공하지 않고 인스턴스에 연결할 수 있습니다. IAM Identity Center를 통한 원격 연결 인증을 허용하는 정책의 예는 [원격 데스크톱 IAM 권한 구성](#rdp-iam-policy-examples)를 참조하세요.
**시작하기 전 준비 사항**
원격 데스크톱을 사용하여 연결을 시작하기 전에 다음과 같은 IAM ID 센터 인증을 사용하는 조건을 참고합니다.
+ 원격 데스크톱에서는 IAM ID 센터를 활성화한 해당 AWS 리전에서 노드에 대한 IAM Identity Center 인증이 지원됩니다.
+ 원격 데스크톱에서는 IAM Identity Center 사용자 이름이 16자까지 지원됩니다.
+ 원격 데스크톱에서는 영숫자와 특수 문자(`.` `-` `_`)로 구성된 IAM Identity Center 사용자 이름이 지원됩니다.
**중요**
`+` `=` `,` 문자가 포함된 IAM Identity Center 사용자 이름의 경우 연결되지 않습니다.
IAM Identity Center에서는 이러한 문자가 사용자 이름에는 지원되지만 Fleet Manager RDP 연결에는 지원되지 않습니다.
또한 IAM Identity Center 사용자 이름에 하나 이상의 `@` 기호가 포함된 경우 Fleet Manager는 `@` 기호가 이메일 주소의 도메인 부분을 도입하는지 여부와 상관없이 첫 번째 `@` 기호와 그 뒤에 오는 모든 문자를 무시합니다. 예를 들어 IAM Identity Center 사용자 이름 `diego_ramirez@example.com`의 경우 `@example.com` 부분은 무시되고 Fleet Manager에 대한 사용자 이름은 `diego_ramirez`가 됩니다. `diego_r@mirez@example.com`의 경우, Fleet Manager는 `@mirez@example.com`을 무시하고 Fleet Manager의 사용자 이름은 `diego_r`이 됩니다.
+ IAM Identity Center를 사용하는 연결이 인증되면 원격 데스크톱에서는 인스턴스의 로컬 관리자 그룹에 로컬 Windows 사용자가 생성됩니다. 이 사용자는 원격 연결이 종료된 후에도 유지됩니다.
+ 원격 데스크톱에서는 Microsoft Active Directory 도메인 컨트롤러인 노드에 대한 IAM Identity Center 인증이 허용되지 않습니다.
+ 원격 데스크톱에서는 Active Directory 도메인에 **조인된 노드에 IAM Identity Center 인증을 사용하는 것이 허용되지만, 그렇게 하지 않는 것이 좋습니다. 이 인증 방법에서는 도메인에서 부여된 더 제한적인 권한이 재정의될 수도 있는 관리 권한이 사용자에게 부여됩니다.
**IAM Identity Center 인증을 지원하는 리전**
IAM Identity Center 인증을 사용한 Remote Desktop 연결은 다음 AWS 리전에서 지원됩니다.
+ 미국 동부(오하이오)(us-east-2)
+ 미국 동부(버지니아 북부)(us-east-1)
+ 미국 서부(캘리포니아 북부)(us-west-1)
+ 미국 서부(오리건)(us-west-2)
+ 아프리카(케이프타운)(af-south-1)
+ 아시아 태평양(홍콩)(ap-east-1)
+ 아시아 태평양(뭄바이)(ap-south-1)
+ 아시아 태평양(도쿄)(ap-northeast-1)
+ 아시아 태평양(서울)(ap-northeast-2)
+ 아시아 태평양(오사카) (ap-northeast-3)
+ 아시아 태평양(싱가포르)(ap-southeast-1)
+ 아시아 태평양(시드니)(ap-southeast-2)
+ 아시아 태평양(자카르타) (ap-southeast-3)
+ 캐나다(중부)(ca-central-1)
+ 유럽(프랑크푸르트)(eu-central-1)
+ 유럽(스톡홀름)(eu-north-1)
+ 유럽(아일랜드)(eu-west-1)
+ 유럽(런던) (eu-west-2)
+ 유럽(파리)(eu-west-3)
+ 이스라엘(텔아비브) (il-central-1)
+ 남아메리카(상파울루)(sa-east-1)
+ 유럽(밀라노)(eu-south-1)
+ 중동(바레인)(me-south-1)
+ AWS GovCloud(미국 동부)(us-gov-east-1)
+ AWS GovCloud(미국 서부)(us-gov-west-1)
## 원격 연결 기간 및 동시성
다음과 같은 조건이 활성 원격 데스크톱 연결에 적용됩니다.
+ **연결 기간**
기본적으로 원격 데스크톱 연결은 60분 후에 연결이 해제됩니다. 연결 해제를 방지하려면 연결이 해제되기 전에 **세션 갱신**을 선택하여 기간 타이머를 재설정할 수 있습니다.
+ **연결 제한 시간**
원격 데스크톱 연결의 유휴 상태가 10분을 넘기면 연결이 해제됩니다.
+ **연결 지속성**
원격 데스크톱을 사용하여 Windows Server에 연결하면 최대 연결 기간(60분) 또는 유휴 제한 시간(10분)이 충족될 때까지 연결이 유지됩니다. 연결 기간은 AWS Identity and Access Management(IAM) 자격 증명의 기간에 따라 결정되지 않습니다. 연결 기간 제한이 충족되지 않으면 IAM 자격 증명이 만료된 후에도 연결이 유지됩니다. 원격 데스크톱을 사용하는 경우 IAM 자격 증명이 만료된 후에 브라우저 페이지를 벗어나 연결을 종료해야 합니다.
+ **동시 연결**
기본적으로 동일한 AWS 계정 및 AWS 리전의 원격 데스크톱 연결을 5개까지 활성화할 수 있습니다. 최대 50개 동시 연결로 서비스 할당량 증가를 요청하려면 **Service Quotas 사용 설명서의 [할당량 증가 요청](https://docs.aws.amazon.com/servicequotas/latest/userguide/request-quota-increase.html)을 참조하세요.
**참고**
Windows Server의 표준 라이선스는 두 개의 동시 RDP 연결을 허용합니다. 더 많은 연결을 지원하려면에서 Microsoft의 Client Access Licenses(CAL)또는 AWS로부터 Microsoft Remote Desktop Services 라이선스를 추가로 구매해야 합니다. 추가 라이선스에 대한 자세한 내용은 다음 주제를 참조하세요.
Microsoft 웹 사이트의 [클라이언트 액세스 라이선스 및 관리 라이선스](https://www.microsoft.com/en-us/licensing/product-licensing/client-access-license)
*License Manager 사용 설명서*의 [지원되는 소프트웨어 제품에 License Manager 사용자 기반 구독 사용](https://docs.aws.amazon.com/license-manager/latest/userguide/user-based-subscriptions.html)
## Systems Manager GUI Connect의 AWS IAM Identity Center 속성 처리
Systems Manager GUI Connect는 RDP를 사용하여 EC2 인스턴스에 대한 Fleet Manager 연결을 지원하는 API입니다. 다음 IAM Identity Center 사용자 데이터는 연결이 닫힌 후에도 유지됩니다.
+ `username`
Systems Manager GUI Connect는 기본적으로 AWS 관리형 키를 사용하여 유휴 상태에서 자격 증명 속성을 암호화합니다. Systems Manager GUI Connect에서 이 속성을 암호화할 때는 고객 관리형 키가 지원되지 않습니다. IAM Identity Center 인스턴스에서 사용자를 삭제하면 Systems Manager GUI Connect는 해당 사용자와 연결된 `username` 속성을 7년 동안 계속 유지한 후 삭제합니다. 이 데이터는 Systems Manager GUI Connect 연결 기록 나열과 같은 감사 이벤트를 지원하기 위해 유지됩니다. 데이터는 수동으로 삭제할 수 없습니다.
## 원격 데스크톱을 사용하여 관리형 노드에 연결
**브라우저의 텍스트 복사/붙여넣기 지원**
Google Chrome 및 Microsoft Edge 브라우저를 사용하여 관리형 노드에서 로컬 시스템으로, 로컬 시스템에서 연결된 관리형 노드로 텍스트를 복사하고 붙여넣을 수 있습니다.
Mozilla Firefox 브라우저를 사용하면 관리형 노드의 텍스트를 로컬 시스템으로만 복사하고 붙여넣을 수 있습니다. 로컬 시스템에서 관리형 노드로의 복사는 지원되지 않습니다.
**Fleet Manager 원격 데스크톱을 사용하여 관리형 노드에 연결**
1. [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)에서 AWS Systems Manager 콘솔을 엽니다.
1. 탐색 창에서 **Fleet Manager**를 선택합니다.
1. 연결하려는 노드를 선택합니다. 확인란 또는 노드 이름을 선택할 수 있습니다.
1. **노드 작업** 메뉴에서 **원격 데스크톱과 연결**을 선택합니다.
1. 원하는 **인증 유형(Authentication type)** 항목을 선택합니다. **사용자 보안 인증 정보**를 선택하는 경우 연결하려는 노드의 Windows 사용자 계정에 대한 사용자 이름과 암호를 입력합니다. **키 페어**를 선택하면 다음과 같은 방법 중 하나를 사용하여 인증을 제공할 수 있습니다.
1. 로컬 파일 시스템에서 인스턴스와 연결된 PEM 키를 선택하려면 **로컬 시스템 찾아보기**를 선택합니다.
– 또는 -
1. PEM 파일의 콘텐츠를 복사하여 제공된 필드에 붙여넣으려면 **키 페어 콘텐츠 붙여넣기**를 선택합니다.
1. **연결(Connect)**을 선택합니다.
1. 선호하는 디스플레이 해상도를 선택하려면 **작업** 메뉴에서 **해상도**를 선택한 후 다음 중에서 선택합니다.
+ **자동으로 조정**
+ **1920 x 1080**
+ **1400 x 900**
+ **1366 x 768**
+ **800 x 600**
**자동으로 조정** 옵션에서는 감지된 화면 크기에 따라 해상도가 설정됩니다.
## 현재 연결과 완료된 연결에 대한 정보 보기
Systems Manager 콘솔의 Fleet Manager 섹션을 사용하여 계정에서 수행된 RDP 연결에 대한 정보를 볼 수 있습니다. 필터 세트를 사용하면 표시되는 연결 목록을 시간 범위, 특정 인스턴스, 연결을 수행한 사용자 및 특정 상태의 연결로 제한할 수 있습니다. 콘솔은 현재 활성 상태인 모든 연결과 과거의 모든 연결에 대한 정보를 보여주는 탭도 제공합니다.
**현재 연결과 완료된 연결에 대한 정보를 보는 방법**
1. [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)에서 AWS Systems Manager 콘솔을 엽니다.
1. 탐색 창에서 **Fleet Manager**를 선택합니다.
1. **계정 관리, 원격 데스크톱으로 연결**을 선택합니다.
1. 다음 탭 중 하나를 선택합니다.
+ **활성 연결**
+ **연결 기록**
1. 표시되는 연결 결과 목록 범위를 더 좁히려면 검색(![\[\]](http://docs.aws.amazon.com/ko_kr/systems-manager/latest/userguide/images/search-icon.png)) 상자에 하나 이상의 필터를 지정합니다. 자유 텍스트 검색어를 입력할 수도 있습니다.
# 관리형 인스턴스의 Amazon EBS 볼륨 관리
[Amazon Elastic Block Store](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AmazonEBS.html)(Amazon EBS)는 Amazon Elastic Compute Cloud(Amazon EC2) 인스턴스와 함께 사용할 수 있는 블록 스토리지 볼륨을 제공합니다. EBS 볼륨은 형식이 지정되지 않은 원시 블록 디바이스처럼 동작합니다. 이러한 볼륨을 인스턴스에 디바이스로 마운트할 수 있습니다.
AWS Systems Manager의 도구인 Fleet Manager를 사용하여 관리형 인스턴스에서 Amazon EBS 볼륨을 관리할 수 있습니다. 예를 들어 EBS 볼륨을 초기화하고, 파티션을 포맷하며, 볼륨을 마운트해 사용할 수 있습니다.
**참고**
Fleet Manager는 현재 Windows Server 인스턴스에 대해서만 Amazon EBS 볼륨 관리를 지원합니다.
## EBS 볼륨 세부 정보 보기
**Fleet Manager를 사용하여 EBS 볼륨의 세부 정보를 보는 방법**
1. [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)에서 AWS Systems Manager 콘솔을 엽니다.
1. 탐색 창에서 **Fleet Manager**를 선택합니다.
1. EBS 볼륨 세부 정보를 보려는 관리형 인스턴스 옆에 있는 버튼을 선택합니다.
1. **세부 정보 보기**를 선택합니다.
1. **도구, EBS 볼륨**을 선택합니다.
1. EBS 볼륨의 세부 정보를 보려면 **볼륨 ID** 열에서 해당 ID를 선택합니다.
## EBS 볼륨 초기화 및 포맷
**Fleet Manager를 사용하여 EBS 볼륨을 초기화하고 포맷하는 방법**
1. [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)에서 AWS Systems Manager 콘솔을 엽니다.
1. 탐색 창에서 **Fleet Manager**를 선택합니다.
1. EBS 볼륨을 초기화, 포맷 및 마운트할 관리형 인스턴스 옆에 있는 버튼을 선택합니다. 디스크가 비어 있는 경우에만 EBS 볼륨을 초기화할 수 있습니다.
1. **세부 정보 보기**를 선택합니다.
1. **도구** 메뉴에서 **EBS 볼륨**을 선택합니다.
1. 초기화하고 포맷할 EBS 볼륨 옆에 있는 버튼을 선택합니다.
1. **초기화 및 포맷**을 선택합니다.
1. **파티션 스타일**에서 EBS 볼륨에 사용할 파티션 스타일을 선택합니다.
1. (선택 사항) 파티션의 **드라이브 문자**를 선택합니다.
1. (선택 사항) 파티션을 식별할 **파티션 이름**을 입력합니다.
1. 파티션에 저장된 파일 및 데이터를 정리하는 데 사용할 **파일 시스템**을 선택합니다.
1. EBS 볼륨을 사용할 수 있게 하려면 **확인**을 선택합니다. 확인 후 AWS Management Console에서 파티션 구성을 변경할 수는 없지만 SSH 또는 RDP를 통해 인스턴스에 로그인하여 파티션 구성을 변경할 수 있습니다.
# Red Hat Knowledge 기본 포털에 액세스
Red Hat 고객이라면 AWS Systems Manager의 도구인 Fleet Manager를 사용하여 지식 기반 포털에 액세스할 수 있습니다. Red Hat Enterprise Linux(RHEL) 인스턴스를 실행하거나 AWS의 RHEL 서비스를 이용한다면 Red Hat 고객으로 간주됩니다. Knowledge 기본 포털에는 Red Hat 라이선스 고객에게만 제공되는 커뮤니티 지원을 위한 바이너리, 지식 공유 및 토론 포럼이 포함되어 있습니다.
Knowledge 기본 포털에 액세스하려면 Systems Manager와 Fleet Manager에 대한 필수 AWS Identity and Access Management(IAM) 권한 외에도 콘솔에 액세스하는 데 사용하는 사용자 또는 역할은 `rhelkb:GetRhelURL` 작업을 허용해야 합니다.
**Red Hat Knowledgebase 포털에 액세스**
1. [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)에서 AWS Systems Manager 콘솔을 엽니다.
1. 탐색 창에서 **Fleet Manager**를 선택합니다.
1. Red Hat Knowledgebase 포털에 연결하는 데 사용하려는 RHEL 인스턴스를 선택하세요.
1. **계정 관리**, **Red Hat Knowledgebase 액세스**를 선택하여 Red Hat Knowledge 기본 페이지를 엽니다.
완벽하게 지원되는 RHEL 워크로드를 실행하기 위해 AWS에서 RHEL을 사용하는 경우, AWS 자격 증명을 사용해 Red Hat 웹사이트를 통해 Red Hat Knowledge 기본에 액세스할 수도 있습니다.
# 관리형 노드 가용성 문제 해결
Run Command, Distributor, Session Manager와 같은 여러 AWS Systems Manager 도구의 경우 작업을 실행할 관리형 노드를 수동으로 선택하도록 할 수 있습니다. 이러한 경우 노드를 수동으로 선택하도록 지정한 후, 작업을 실행할 수 있는 관리형 노드 목록이 표시됩니다.
이 주제에서는 *실행 중인 것으로 확인된* 관리형 노드가 Systems Manager의 관리형 노드 목록에 포함되지 않은 이유를 진단합니다.
노드가 Systems Manager에서 관리되고 관리형 노드 목록에서 사용 가능하게 하려면 다음 3가지 기본 요구 사항을 충족해야 합니다.
+ SSM Agent는 지원되는 운영 체제가 있는 노드에 설치되어 실행 중이어야 합니다.
**참고**
일부 AWS 관리형 Amazon Machine Images(AMIs)는 [SSM Agent](ssm-agent.md)가 사전 설치된 인스턴스를 시작하도록 구성됩니다. SSM Agent를 미리 설치하도록 사용자 정의 AMI를 구성할 수도 있습니다. 자세한 내용은 [SSM Agent가 사전 설치된 상태로 AMIs 검색](ami-preinstalled-agent.md) 섹션을 참조하세요.
+ Amazon Elastic Compute Cloud(Amazon EC2) 인스턴스에서 AWS Identity and Access Management(IAM) 인스턴스에 대한 인스턴스 프로파일을 첨부해야 합니다. 인스턴스 프로파일을 사용하면 인스턴스가 Systems Manager 서비스와 통신할 수 있습니다. 인스턴스에 인스턴스 프로파일을 할당하지 않으면 일반적인 시나리오가 아닌 [하이브리드 정품 인증](activations.md)을 사용하여 인스턴스를 등록합니다.
+ SSM Agent는 서비스에 자신을 등록하기 위해 Systems Manager 엔드포인트에 연결할 수 있어야 합니다. 그 이후에는 서비스에서 관리형 노드를 사용할 수 있어야 하며, 이는 인스턴스 상태를 확인하기 위해 5분마다 신호를 보내는 서비스에 의해 확인됩니다.
+ 관리형 노드의 상태가 30일 이상 `Connection Lost`한 후에는 해당 노드가 Fleet Manager 콘솔에 더 이상 나열되지 않을 수 있습니다. 목록으로 복원하려면 연결이 끊긴 문제를 해결해야 합니다.
관리형 노드가 실행 중인지 확인한 후 다음 명령을 사용하여 SSM Agent가 Systems Manager 서비스에 등록되었는지 확인할 수 있습니다. 이 명령은 성공적으로 등록될 때까지 결과를 반환하지 않습니다.
------
#### [ Linux & macOS ]
```
aws ssm describe-instance-associations-status \
--instance-id instance-id
```
------
#### [ Windows ]
```
aws ssm describe-instance-associations-status ^
--instance-id instance-id
```
------
#### [ PowerShell ]
```
Get-SSMInstanceAssociationsStatus `
-InstanceId instance-id
```
------
등록이 완료되고 이제 관리형 노드를 Systems Manager 작업에 사용할 수 있는 경우 명령은 다음과 유사한 결과를 반환합니다.
```
{
"InstanceAssociationStatusInfos": [
{
"AssociationId": "fa262de1-6150-4a90-8f53-d7eb5EXAMPLE",
"Name": "AWS-GatherSoftwareInventory",
"DocumentVersion": "1",
"AssociationVersion": "1",
"InstanceId": "i-02573cafcfEXAMPLE",
"Status": "Pending",
"DetailedStatus": "Associated"
},
{
"AssociationId": "f9ec7a0f-6104-4273-8975-82e34EXAMPLE",
"Name": "AWS-RunPatchBaseline",
"DocumentVersion": "1",
"AssociationVersion": "1",
"InstanceId": "i-02573cafcfEXAMPLE",
"Status": "Queued",
"AssociationName": "SystemAssociationForScanningPatches"
}
]
}
```
등록이 아직 완료되지 않았거나 실패한 경우 명령은 다음과 유사한 결과를 반환합니다.
```
{
"InstanceAssociationStatusInfos": []
}
```
명령이 5분 정도 후에도 결과를 반환하지 않으면 다음 정보를 사용하여 관리형 노드의 문제를 해결하는 데 도움이 됩니다.
**Topics**
+ [해결 방법 1: SSM Agent가 관리형 노드에 설치되어 실행 중인지 확인](#instances-missing-solution-1)
+ [해결 방법 2: 인스턴스에 대해 IAM 인스턴스 프로파일이 지정되었는지 확인(EC2 인스턴스만 해당)](#instances-missing-solution-2)
+ [해결 방법 3: 서비스 엔드포인트 연결 확인](#instances-missing-solution-3)
+ [해결 방법 4: 대상 운영 체제 지원 확인](#instances-missing-solution-4)
+ [해결 방법 5: Amazon EC2 인스턴스와 동일한 AWS 리전에서 작업 중인지 확인](#instances-missing-solution-5)
+ [솔루션 6: 관리형 노드의 SSM Agent에 적용한 프록시 구성 확인](#instances-missing-solution-6)
+ [솔루션 7: 관리형 인스턴스에 TLS 인증서 설치](#hybrid-tls-certificate)
+ [`ssm-cli`를 사용하여 관리형 노드 가용성 문제 해결](troubleshooting-managed-nodes-using-ssm-cli.md)
## 해결 방법 1: SSM Agent가 관리형 노드에 설치되어 실행 중인지 확인
SSM Agent의 최신 버전이 관리형 노드에 설치되어 실행되고 있는지 확인합니다.
SSM Agent가 관리형 노드에 설치되어 실행 중인지 확인하려면 [SSM Agent 상태 확인 및 에이전트 시작](ssm-agent-status-and-restart.md) 섹션을 참조하세요.
관리형 노드에 SSM Agent를 설치하거나 다시 설치하려면 다음 주제를 참조하세요.
+ [Linux용 EC2 인스턴스에 수동으로 SSM Agent 설치 및 제거](manually-install-ssm-agent-linux.md)
+ [하이브리드 Linux 노드에 SSM Agent를 설치하는 방법](hybrid-multicloud-ssm-agent-install-linux.md)
+ [SSM Agent용 EC2 인스턴스에 수동으로 Windows Server 설치 및 제거](manually-install-ssm-agent-windows.md)
+ [하이브리드 Windows 노드에 SSM Agent를 설치하는 방법](hybrid-multicloud-ssm-agent-install-windows.md)
## 해결 방법 2: 인스턴스에 대해 IAM 인스턴스 프로파일이 지정되었는지 확인(EC2 인스턴스만 해당)
Amazon Elastic Compute Cloud(Amazon EC2) 인스턴스가 Systems Manager API와 통신하도록 허용하는 AWS Identity and Access Management(IAM) 인스턴스 프로파일로 구성되어 있는지 확인합니다. 또한 사용자가 시스템 관리자 API와 통신할 수 있는 IAM 신뢰 정책이 있는지도 확인합니다.
**참고**
온프레미스 서버, 엣지 디바이스 및 가상 머신(VM)은 인스턴스 프로파일 대신 IAM 서비스 역할을 사용합니다. 자세한 내용은 [하이브리드 및 멀티클라우드 환경에서 Systems Manager에 필요한 IAM 서비스 역할 생성](hybrid-multicloud-service-role.md)을 참조하세요.
**필요한 권한이 있는 인스턴스 프로파일이 EC2 인스턴스에 연결되어 있는지 확인**
1. [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/)에서 Amazon EC2 콘솔을 엽니다.
1. 탐색 창에서 **인스턴스**를 선택합니다.
1. 인스턴스 프로파일을 확인할 인스턴스를 선택합니다.
1. 하단 창의 [**설명(Description)**] 탭에서 [**IAM 역할(IAM role)**]을 찾고 역할의 이름을 선택합니다.
1. 인스턴스 프로파일에 대한 역할 [**요약(Summary)**] 페이지의 [**권한(Permissions)**] 탭에서 `AmazonSSMManagedInstanceCore`가 [**권한 정책(Permissions policies)**] 아래에 나열되어 있는지 확인합니다.
대신 사용자 정의 정책을 사용하는 경우 `AmazonSSMManagedInstanceCore`와 동일한 권한을 제공하는지 확인합니다.
[콘솔에서 `AmazonSSMManagedInstanceCore` 열기](https://console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/AmazonSSMManagedInstanceCore$jsonEditor)
Systems Manager용 인스턴스 프로파일에 연결할 수 있는 다른 정책에 대한 자세한 내용은 [Systems Manager에 필요한 인스턴스 권한 구성](setup-instance-permissions.md)을 참조하세요.
## 해결 방법 3: 서비스 엔드포인트 연결 확인
인스턴스가 Systems Manager 서비스 엔드포인트에 연결되어 있는지 확인합니다. 이러한 연결은 Systems Manager에 VPC 엔드포인트를 생성 및 구성하거나 서비스 엔드포인트에 대한 HTTPS(포트 443) 아웃바운드 트래픽을 허용함으로써 이루어집니다.
Amazon EC2 인스턴스에서는, AWS 리전에 대한 Systems Manager 서비스 엔드포인트는 Virtual Private Cloud(VPC) 구성에서 아웃바운드 트래픽을 허용하는 경우 인스턴스를 등록하는 데 사용됩니다. 그러나 인스턴스가 시작된 VPC 구성에서 아웃바운드 트래픽을 허용하지 않고 퍼블릭 서비스 엔드포인트에 대한 연결을 허용하도록 이 구성을 변경할 수 없는 경우, 대신 VPC에 대한 인터페이스 엔드포인트를 구성해야 합니다.
자세한 내용은 [Systems Manager용 VPC 엔드포인트를 사용하여 EC2 인스턴스의 보안 개선](setup-create-vpc.md)을 참조하세요.
## 해결 방법 4: 대상 운영 체제 지원 확인
선택한 작업이 나열될 것으로 예상되는 관리형 노드 유형에서 실행될 수 있는지 확인합니다. 일부 Systems Manager 작업은 Windows 인스턴스 또는 Linux 인스턴스만 대상으로 할 수 있습니다. 예를 들어 Systems Manager(SSM) `AWS-InstallPowerShellModule` 및 `AWS-ConfigureCloudWatch`는 Windows 인스턴스에서만 실행할 수 있습니다. [**명령 실행(Run a command)**] 페이지에서 이러한 문서 중 하나를 선택하고 [**수동으로 인스턴스 선택(Choose instances manually)**]을 선택하면 Windows 인스턴스만 나열되고 선택할 수 있습니다.
## 해결 방법 5: Amazon EC2 인스턴스와 동일한 AWS 리전에서 작업 중인지 확인
Amazon EC2 인스턴스는 미국 동부(오하이오) 리전(us-east-2) 또는 유럽(아일랜드) 리전(eu-west-1)과 같은 특정 AWS 리전에서 생성 및 사용 가능합니다. 작업하려는 Amazon EC2 인스턴스와 동일한 AWS 리전에서 작업하고 있는지 확인합니다. 자세한 내용은 *AWS Management Console 시작하기*에서 [리전 선택](https://docs.aws.amazon.com/awsconsolehelpdocs/latest/gsg/getting-started.html#select-region)을 참조하세요.
## 솔루션 6: 관리형 노드의 SSM Agent에 적용한 프록시 구성 확인
관리형 노드의 SSM Agent에 적용한 프록시 구성이 올바른지 확인합니다. 프록시 구성이 올바르지 않으면 노드가 필요한 서비스 엔드포인트에 연결할 수 없거나 Systems Manager가 관리형 노드의 운영 체제를 잘못 식별할 수 있습니다. 자세한 내용은 [SSM Agent를 구성하여 Linux 노드에 프록시 사용](configure-proxy-ssm-agent.md) 및 [Windows Server 인스턴스에 프록시를 사용하도록 SSM Agent 구성](configure-proxy-ssm-agent-windows.md)(을)를 참조하세요.
## 솔루션 7: 관리형 인스턴스에 TLS 인증서 설치
AWS Systems Manager와(과) 함께 사용하는 각 관리형 인스턴스에 TLS(전송 계층 보안) 인증서를 설치해야 합니다. AWS 서비스은(는) 이러한 인증서를 사용하여 다른 AWS 서비스에 대한 호출을 암호화합니다.
Amazon Machine Image(AMI)에서 생성된 각 Amazon EC2 인스턴스에는 TLS 인증서가 기본적으로 이미 설치되어 있습니다. 대부분의 최신 운영 체제에는 신뢰 저장소에 Amazon Trust Services CA의 필수 TLS 인증서가 포함되어 있습니다.
인스턴스에 필요한 인증서가 설치되어 있는지 확인하려면 인스턴스의 운영 체제에 따라 다음 명령을 실행합니다. 관리형 인스턴스가 위치한 URL *리전* 부분을 AWS 리전로 교체하세요.
------
#### [ Linux & macOS ]
```
curl -L https://ssm.region.amazonaws.com
```
------
#### [ Windows ]
```
Invoke-WebRequest -Uri https://ssm.region.amazonaws.com
```
------
명령이 `UnknownOperationException` 에러를 반환합니다. 대신 SSL/TLS 오류 메시지가 나타나면 필요한 인증서가 설치되지 않을 수 있습니다.
필수 Amazon Trust Services CA 인증서가 기본 운영 체제, Amazon에서 제공하지 않는 AMIs에서 생성된 인스턴스 또는 자체 온프레미스 서버와 VM에 설치되어 있지 않은 경우 [Amazon Trust Services](https://www.amazontrust.com/repository/)의 인증서를 설치하여 활성화하거나 AWS Certificate Manager(ACM)를 사용하여 지원되는 통합 서비스에 대한 인증서를 생성하고 관리해야 합니다.
각 관리형 인스턴스에 다음과 같은 TLS(전송 계층 보안) 인증서가 하나 설치되어 있어야 합니다.
+ Amazon Root CA 1
+ Starfield Services Root Certificate Authority - G2
+ Starfield Class 2 인증 기관
ACM 사용에 대한 자세한 내용은 *[AWS Certificate Manager User Guide](https://docs.aws.amazon.com/acm/latest/userguide/)*를 참조하세요.
GPO(그룹 정책 객체)로 인증서를 관리하는 컴퓨팅 환경이라면 이러한 인증서 중 하나가 포함되도록 그룹 정책을 구성해야 합니다.
Amazon Root 및 Starfield 인증서에 대한 자세한 내용은 블로그 게시물 [How to Prepare for AWS’s Move to Its Own Certificate Authority](https://aws.amazon.com/blogs/security/how-to-prepare-for-aws-move-to-its-own-certificate-authority/)를 참조하세요.
# `ssm-cli`를 사용하여 관리형 노드 가용성 문제 해결
`ssm-cli`는 SSM Agent 설치에 포함된 독립 실행형 명령줄 도구입니다. SSM Agent 3.1.501.0 이상을 컴퓨터에 설치하는 경우 해당 컴퓨터에서 `ssm-cli` 명령을 실행할 수 있습니다. 이러한 명령의 출력은 시스템이 AWS Systems Manager에서 관리되는 Amazon EC2 인스턴스 또는 비 EC2 시스템의 최소 요건 충족 여부를 판단하는 데 도움이 되며, 따라서 Systems Manager의 관리형 노드 목록에 추가 됩니다. (SSM Agent 버전 3.1.501.0은 2021년 11월에 출시되었습니다.)
**최소 요구 사항**
Amazon EC2 인스턴스 또는 비 EC2 시스템이 AWS Systems Manager에서 관리되고 관리형 노드 목록에서 사용 가능하려면 다음 세 가지 기본 요구 사항을 충족해야 합니다.
+ [지원되는 운영 체제](operating-systems-and-machine-types.md#prereqs-operating-systems)가 있는 시스템에 SSM Agent가 설치되어 실행 중이어야 합니다.
EC2의 일부 AWS 관리형 Amazon Machine Images(AMIs)는 [SSM Agent](ssm-agent.md)가 사전 설치된 인스턴스를 시작하도록 구성됩니다. SSM Agent를 미리 설치하도록 사용자 정의 AMI를 구성할 수도 있습니다. 자세한 내용은 [SSM Agent가 사전 설치된 상태로 AMIs 검색](ami-preinstalled-agent.md) 섹션을 참조하세요.
+ Systems Manager 서비스와 통신하는 데 필요한 권한을 제공하는 AWS Identity and Access Management(IAM) 인스턴스 프로파일(EC2 인스턴스의 경우) 또는 IAM 서비스 역할(비 EC2 시스템의 경우)이 시스템에 연결되어 있어야 합니다.
+ SSM Agent는 서비스에 자신을 등록하기 위해 Systems Manager 엔드포인트에 연결할 수 있어야 합니다. 그 이후에는 서비스에서 관리형 노드를 사용할 수 있어야 하며, 이는 관리형 노드의 상태를 확인하기 위해 5분마다 신호를 보내는 서비스에 의해 확인됩니다.
**`ssm-cli`에서 사전 구성된 명령**
실행 중인 것으로 확인된 시스템이 Systems Manager의 관리형 노드 목록에 포함되지 않은 이유를 진단하기 위해 필수 정보를 수집하는 사전 구성된 명령이 포함되어 있습니다. 이러한 명령은 `get-diagnostics` 옵션을 지정할 때 실행됩니다.
시스템에서 다음 명령을 실행하여 관리형 노드 가용성 문제 해결에 도움이 되는 `ssm-cli`를 사용합니다.
------
#### [ Linux & macOS ]
```
ssm-cli get-diagnostics --output table
```
------
#### [ Windows ]
Windows Server 시스템에서 명령을 실행하기 전에 `C:\Program Files\Amazon\SSM` 디렉터리로 이동해야 합니다.
```
ssm-cli.exe get-diagnostics --output table
```
------
#### [ PowerShell ]
Windows Server 시스템에서 명령을 실행하기 전에 `C:\Program Files\Amazon\SSM` 디렉터리로 이동해야 합니다.
```
.\ssm-cli.exe get-diagnostics --output table
```
------
명령을 통해 다음과 비슷한 테이블로 출력을 반환합니다.
**참고**
`ssmmessages`, `s3`, `kms`, `logs` 및 `monitoring` 엔드포인트와의 연결성 확인은 Amazon Simple Storage Service(Amazon S3) 또는 Amazon CloudWatch Logs, 그리고 AWS Key Management Service(AWS KMS) 암호화에 로그할 수 있는 Session Manager과 같은 추가적인 옵션 기능을 위한 것입니다.
------
#### [ Linux & macOS ]
```
[root@instance]# ssm-cli get-diagnostics --output table
┌───────────────────────────────────────┬─────────┬───────────────────────────────────────────────────────────────────────┐
│ Check │ Status │ Note │
├───────────────────────────────────────┼─────────┼───────────────────────────────────────────────────────────────────────┤
│ EC2 IMDS │ Success │ IMDS is accessible and has instance id i-0123456789abcdefa in Region │
│ │ │ us-east-2 │
├───────────────────────────────────────┼─────────┼───────────────────────────────────────────────────────────────────────┤
│ Hybrid instance registration │ Skipped │ Instance does not have hybrid registration │
├───────────────────────────────────────┼─────────┼───────────────────────────────────────────────────────────────────────┤
│ Connectivity to ssm endpoint │ Success │ ssm.us-east-2.amazonaws.com is reachable │
├───────────────────────────────────────┼─────────┼───────────────────────────────────────────────────────────────────────┤
│ Connectivity to ec2messages endpoint │ Success │ ec2messages.us-east-2.amazonaws.com is reachable │
├───────────────────────────────────────┼─────────┼───────────────────────────────────────────────────────────────────────┤
│ Connectivity to ssmmessages endpoint │ Success │ ssmmessages.us-east-2.amazonaws.com is reachable │
├───────────────────────────────────────┼─────────┼───────────────────────────────────────────────────────────────────────┤
│ Connectivity to s3 endpoint │ Success │ s3.us-east-2.amazonaws.com is reachable │
├───────────────────────────────────────┼─────────┼───────────────────────────────────────────────────────────────────────┤
│ Connectivity to kms endpoint │ Success │ kms.us-east-2.amazonaws.com is reachable │
├───────────────────────────────────────┼─────────┼───────────────────────────────────────────────────────────────────────┤
│ Connectivity to logs endpoint │ Success │ logs.us-east-2.amazonaws.com is reachable │
├───────────────────────────────────────┼─────────┼───────────────────────────────────────────────────────────────────────┤
│ Connectivity to monitoring endpoint │ Success │ monitoring.us-east-2.amazonaws.com is reachable │
├───────────────────────────────────────┼─────────┼───────────────────────────────────────────────────────────────────────┤
│ AWS Credentials │ Success │ Credentials are for │
│ │ │ arn:aws:sts::123456789012:assumed-role/Fullaccess/i-0123456789abcdefa │
│ │ │ and will expire at 2021-08-17 18:47:49 +0000 UTC │
├───────────────────────────────────────┼─────────┼───────────────────────────────────────────────────────────────────────┤
│ Agent service │ Success │ Agent service is running and is running as expected user │
├───────────────────────────────────────┼─────────┼───────────────────────────────────────────────────────────────────────┤
│ Proxy configuration │ Skipped │ No proxy configuration detected │
├───────────────────────────────────────┼─────────┼───────────────────────────────────────────────────────────────────────┤
│ SSM Agent version │ Success │ SSM Agent version is 3.0.1209.0, latest available agent version is │
│ │ │ 3.1.192.0 │
└───────────────────────────────────────┴─────────┴───────────────────────────────────────────────────────────────────────┘
```
------
#### [ Windows Server and PowerShell ]
```
PS C:\Program Files\Amazon\SSM> .\ssm-cli.exe get-diagnostics --output table
┌───────────────────────────────────────┬─────────┬─────────────────────────────────────────────────────────────────────┐
│ Check │ Status │ Note │
├───────────────────────────────────────┼─────────┼─────────────────────────────────────────────────────────────────────┤
│ EC2 IMDS │ Success │ IMDS is accessible and has instance id i-0123456789EXAMPLE in │
│ │ │ Region us-east-2 │
├───────────────────────────────────────┼─────────┼─────────────────────────────────────────────────────────────────────┤
│ Hybrid instance registration │ Skipped │ Instance does not have hybrid registration │
├───────────────────────────────────────┼─────────┼─────────────────────────────────────────────────────────────────────┤
│ Connectivity to ssm endpoint │ Success │ ssm.us-east-2.amazonaws.com is reachable │
├───────────────────────────────────────┼─────────┼─────────────────────────────────────────────────────────────────────┤
│ Connectivity to ec2messages endpoint │ Success │ ec2messages.us-east-2.amazonaws.com is reachable │
├───────────────────────────────────────┼─────────┼─────────────────────────────────────────────────────────────────────┤
│ Connectivity to ssmmessages endpoint │ Success │ ssmmessages.us-east-2.amazonaws.com is reachable │
├───────────────────────────────────────┼─────────┼─────────────────────────────────────────────────────────────────────┤
│ Connectivity to s3 endpoint │ Success │ s3.us-east-2.amazonaws.com is reachable │
├───────────────────────────────────────┼─────────┼─────────────────────────────────────────────────────────────────────┤
│ Connectivity to kms endpoint │ Success │ kms.us-east-2.amazonaws.com is reachable │
├───────────────────────────────────────┼─────────┼─────────────────────────────────────────────────────────────────────┤
│ Connectivity to logs endpoint │ Success │ logs.us-east-2.amazonaws.com is reachable │
├───────────────────────────────────────┼─────────┼─────────────────────────────────────────────────────────────────────┤
│ Connectivity to monitoring endpoint │ Success │ monitoring.us-east-2.amazonaws.com is reachable │
├───────────────────────────────────────┼─────────┼─────────────────────────────────────────────────────────────────────┤
│ AWS Credentials │ Success │ Credentials are for │
│ │ │ arn:aws:sts::123456789012:assumed-role/SSM-Role/i-123abc45EXAMPLE │
│ │ │ and will expire at 2021-09-02 13:24:42 +0000 UTC │
├───────────────────────────────────────┼─────────┼─────────────────────────────────────────────────────────────────────┤
│ Agent service │ Success │ Agent service is running and is running as expected user │
├───────────────────────────────────────┼─────────┼─────────────────────────────────────────────────────────────────────┤
│ Proxy configuration │ Skipped │ No proxy configuration detected │
├───────────────────────────────────────┼─────────┼─────────────────────────────────────────────────────────────────────┤
│ Windows sysprep image state │ Success │ Windows image state value is at desired value IMAGE_STATE_COMPLETE │
├───────────────────────────────────────┼─────────┼─────────────────────────────────────────────────────────────────────┤
│ SSM Agent version │ Success │ SSM Agent version is 3.2.815.0, latest agent version in us-east-2 │
│ │ │ is 3.2.985.0 │
└───────────────────────────────────────┴─────────┴─────────────────────────────────────────────────────────────────────┘
```
------
다음 표에는 `ssm-cli`에서 수행하는 각 검사에 대한 추가 세부 정보가 나와 있습니다.
**`ssm-cli` 진단 검사**
| Check]를 선택합니다 | 세부 정보 |
| --- | --- |
| Amazon EC2 인스턴스 메타데이터 서비스 | 관리형 노드가 메타데이터 서비스에 도달할 수 있는지를 나타냅니다. 실패한 테스트는 로컬 경로, 프록시 또는 OS(운영 체제) 방화벽 및 프록시 구성으로 인해 발생할 수 있는 http://169.254.169.254에 대한 연결 문제를 나타냅니다. |
| 하이브리드 인스턴스 등록 | SSM Agent가 하이브리드 정품 인증을 사용하여 등록되었는지를 나타냅니다. |
| ssm 엔드포인트에 연결성 | 노드가 TCP 포트 443에서 Systems Manager의 서비스 엔드포인트에 도달할 수 있는지를 나타냅니다. 실패한 테스트는 노드가 있는 https://ssm.region.amazonaws.com에 따라 AWS 리전에 대한 연결 문제를 나타냅니다. 연결 문제는 보안 그룹, 네트워크 액세스 제어 목록, 라우팅 테이블 또는 OS 방화벽 및 프록시를 포함한 VPC 구성으로 인해 발생할 수 있습니다. |
| ec2messages 엔드포인트에 연결성 | 노드가 TCP 포트 443에서 Systems Manager의 서비스 엔드포인트에 도달할 수 있는지를 나타냅니다. 실패한 테스트는 노드가 있는 https://ec2messages.region.amazonaws.com에 따라 AWS 리전에 대한 연결 문제를 나타냅니다. 연결 문제는 보안 그룹, 네트워크 액세스 제어 목록, 라우팅 테이블 또는 OS 방화벽 및 프록시를 포함한 VPC 구성으로 인해 발생할 수 있습니다. |
| ssmmessages 엔드포인트에 연결성 | 노드가 TCP 포트 443에서 Systems Manager의 서비스 엔드포인트에 도달할 수 있는지를 나타냅니다. 실패한 테스트는 노드가 있는 https://ssmmessages.region.amazonaws.com에 따라 AWS 리전에 대한 연결 문제를 나타냅니다. 연결 문제는 보안 그룹, 네트워크 액세스 제어 목록, 라우팅 테이블 또는 OS 방화벽 및 프록시를 포함한 VPC 구성으로 인해 발생할 수 있습니다. |
| s3 엔드포인트에 연결성 | 노드가 TCP 포트 443에서 Amazon Simple Storage Service의 서비스 엔드포인트에 도달할 수 있는지를 나타냅니다. 실패한 테스트는 노드가 있는 https://s3.region.amazonaws.com에 따라 AWS 리전에 대한 연결 문제를 나타냅니다. 노드를 관리형 노드 목록에 표시하기 위해 이 엔드포인트에 연결할 필요는 없습니다. |
| kms 엔드포인트에 연결성 | 노드가 TCP 포트 443에서 AWS Key Management Service의 서비스 엔드포인트에 도달할 수 있는지를 나타냅니다. 실패한 테스트는 노드가 있는 `https://kms.region.amazonaws.com`에 따라 AWS 리전에 대한 연결 문제를 나타냅니다. 노드를 관리형 노드 목록에 표시하기 위해 이 엔드포인트에 연결할 필요는 없습니다. |
| logs 엔드포인트에 연결성 | 노드가 TCP 포트 443에서 Amazon CloudWatch Logs의 서비스 엔드포인트에 도달할 수 있는지를 나타냅니다. 실패한 테스트는 노드가 있는 https://logs.region.amazonaws.com에 따라 AWS 리전에 대한 연결 문제를 나타냅니다. 노드를 관리형 노드 목록에 표시하기 위해 이 엔드포인트에 연결할 필요는 없습니다. |
| monitoring 엔드포인트에 연결성 | 노드가 TCP 포트 443에서 Amazon CloudWatch의 서비스 엔드포인트에 도달할 수 있는지를 나타냅니다. 실패한 테스트는 노드가 있는 https://monitoring.region.amazonaws.com에 따라 AWS 리전에 대한 연결 문제를 나타냅니다. 노드를 관리형 노드 목록에 표시하기 위해 이 엔드포인트에 연결할 필요는 없습니다. |
| AWS 자격 증명 | 시스템에 연결된 IAM 인스턴스 프로파일(EC2 인스턴스의 경우) 또는 IAM 서비스 역할(비 EC2 시스템의 경우)별로 필요한 보안 인증 정보가 SSM Agent에 있는지를 나타냅니다. 실패한 테스트는 인스턴스에 연결된 IAM 인스턴스 프로파일 또는 IAM 서비스 역할이 없거나 Systems Manager에 필요한 권한이 포함되어 있지 않음을 나타냅니다. |
| 에이전트 서비스 | SSM Agent 서비스가 실행 중인지 여부와 서비스가 Linux 또는 macOS용 루트 또는 Windows Server용 SYSTEM으로 실행 중인지 여부를 나타냅니다. 실패한 테스트는 SSM Agent 서비스가 실행되고 있지 않거나 루트 또는 SYSTEM으로 실행되고 있지 않음을 나타냅니다. |
| 프록시 구성 | 프록시를 사용하도록 SSM Agent가 구성되었는지를 나타냅니다. |
| Sysprep 이미지 상태(Windows만 해당) | 노드의 Sysprep 상태를 나타냅니다. Sysprep 상태가 IMAGE\$1STATE\$1COMPLETE 이외의 값이면 SSM Agent가 노드에서 시작되지 않습니다. |
| SSM Agent 버전 | 사용 가능한 최신 SSM Agent 버전이 설치되어 있는지를 나타냅니다. |
# AWS Systems Manager 하이브리드 정품 인증
[하이브리드 및 멀티클라우드](operating-systems-and-machine-types.md#supported-machine-types) 환경의 AWS Systems Manager에서 사용하도록 비 EC2 시스템을 구성하려면 **하이브리드 정품 인증을 생성합니다. 관리형 노드로 지원되는 비 EC2 시스템 유형에는 다음이 포함됩니다.
+ 자체 프레미스의 서버(온프레미스 서버)
+ AWS IoT Greengrass 코어 디바이스
+ AWS IoT 및 비 AWS 엣지 디바이스
+ 다른 클라우드 환경의 VM을 포함한 가상 머신
[https://docs.aws.amazon.com/cli/latest/reference/ssm/create-activation.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/create-activation.html) 명령을 실행하여 하이브리드 정품 인증 프로세스를 시작하면 명령 응답으로 활성화 코드와 ID가 수신됩니다. 그런 다음에 [하이브리드 Linux 노드에 SSM Agent 설치](hybrid-multicloud-ssm-agent-install-linux.md)의 3단계 및 [하이브리드 Windows Server 노드에 SSM Agent 설치](hybrid-multicloud-ssm-agent-install-windows.md)의 4단계에 설명된 대로 시스템에 SSM Agent를 설치하는 명령에 활성화 코드 및 ID를 포함합니다.
이 정품 인증 프로세스는 AWS IoT Greengrass 코어 디바이스를 **제외한 모든 비 EC2 시스템 유형에 적용됩니다. AWS IoT Greengrass Systems Manager용 핵심 장치 구성에 대한 자세한 내용은 관리자용 핵심 장치는 [Systems Manager를 통한 엣지 디바이스 관리](systems-manager-setting-up-edge-devices.md) 섹션을 참조하세요.
**참고**
현재 비 EC2 macOS 시스템에 대한 지원은 제공되지 않습니다.
**Systems Manager 인스턴스 티어 정보**
AWS Systems Manager에서는 표준 인스턴스 티어와 고급 인스턴스 티어를 제공합니다. 둘 다 [하이브리드 및 멀티클라우드](operating-systems-and-machine-types.md#supported-machine-types) 환경에서 관리형 노드를 지원합니다. 표준 인스턴스 티어를 통해 AWS 리전의 AWS 계정당 최대 1,000개의 시스템을 등록할 수 있습니다. 단일 계정 및 리전에 1,000개 이상의 시스템을 등록해야 하는 경우 고급 인스턴스 티어를 사용합니다. 고급 인스턴스 티어에서 원하는 만큼 관리형 노드를 생성할 수 있습니다. Systems Manager를 위해 구성된 모든 관리형 노드의 가격은 사용량에 따라 지불하는 방식으로 책정됩니다. 고급 인스턴스 티어 활성화에 대한 자세한 내용은 [고급 인스턴스 티어 설정](fleet-manager-enable-advanced-instances-tier.md) 섹션을 참조하세요. 요금에 대한 자세한 내용은 [AWS Systems Manager 요금](https://aws.amazon.com/systems-manager/pricing/)을 참조하세요.
표준 인스턴스 계층 및 고급 인스턴스 계층에 대한 다음 추가 정보에 유의하세요.
+ 고급 인스턴스도 AWS Systems Manager Session Manager를 사용하여 [하이브리드 및 멀티클라우드](operating-systems-and-machine-types.md#supported-machine-types) 환경의 비 EC2 노드에 연결할 수 있습니다. Session Manager에서는 인스턴스에 대한 대화형 쉘 액세스가 제공됩니다. 자세한 내용은 [AWS Systems Manager Session Manager](session-manager.md) 섹션을 참조하세요.
+ 표준 인스턴스 할당량은 또한 Systems Manager 온프레미스 정품 인증을 사용하는 EC2 인스턴스에도 적용됩니다(일반 시나리오는 아님).
+ Microsoft에서 릴리스한 가상 머신 온프레미스 인스턴스 기반 애플리케이션을 패치하려면 고급 인스턴스 티어를 활성화합니다. 고급 인스턴스 티어 사용에는 요금이 따릅니다. Microsoft에서 릴리스한 Amazon Elastic Compute Cloud(Amazon EC2) 인스턴스 기반 애플리케이션을 패치하는 데는 추가 요금이 없습니다. 자세한 내용은 [Microsoft에서 Windows Server에 릴리스한 애플리케이션 패치 적용](patch-manager-patching-windows-applications.md) 섹션을 참조하세요.
# AWS Systems Manager Inventory
AWS Systems Manager Inventory는 AWS 컴퓨팅 환경에 대한 가시성을 제공합니다. Inventory를 사용하여 관리형 노드에서 *메타데이터*를 수집할 수 있습니다. 이 메타데이터를 중앙 Amazon Simple Storage Service(Amazon S3) 버킷에 저장한 후 기본 제공 도구를 사용하여 데이터를 쿼리하고 어느 노드에서 소프트웨어 정책이 요구하는 소프트웨어 및 구성을 실행 중인지, 어느 노드를 업데이트해야 하는지 빠르게 확인할 수 있습니다. 원클릭 절차를 사용하여 모든 관리형 노드에 대해 인벤토리를 구성할 수 있습니다. 또한 Amazon Athena를 사용하여 여러 AWS 리전 및 AWS 계정의 인벤토리 데이터를 구성하고 볼 수 있습니다. 인벤토리를 시작하려면 [Systems Manager 콘솔](https://console.aws.amazon.com//systems-manager/inventory)을 엽니다. 탐색 창에서 [**Inventory**]를 선택합니다.
Systems Manager Inventory가 수집하는 미리 구성된 메타데이터 형식이 요구 사항을 충족하지 않을 경우 사용자 정의 Systems Manager Inventory를 생성할 수 있습니다. 사용자 지정 인벤토리는 사용자가 제공하고 특정 디렉터리에서 관리형 노드에 추가하는 정보를 포함하는 단순한 JSON 파일입니다. Systems Manager Inventory가 데이터를 수집할 때 이 사용자 정의 인벤토리 데이터를 캡처합니다. 예를 들어 대규모 데이터 센터를 운영하는 경우 각 서버의 랙 위치를 사용자 지정 인벤토리로 지정할 수 있습니다. 그러면 다른 인벤토리 데이터를 볼 때 랙 공간 데이터를 볼 수 있습니다.
**중요**
Systems Manager Inventory는 관리형 노드에서*만* 메타데이터를 수집합니다. Inventory는 독점 정보 또는 데이터에 액세스하지 않습니다.
다음 표에서는 Systems Manager Inventory로 수집할 수 있는 데이터 형식을 설명합니다. 또한 이 표에서는 노드를 대상으로 하는 다양한 오퍼링과 지정할 수 있는 수집 간격에 대해 설명합니다.
****
| 구성 | 세부 사항 |
| --- | --- |
| 메타데이터 형식 | 다음 유형의 데이터를 수집할 인벤토리를 구성할 수 있습니다. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/systems-manager/latest/userguide/systems-manager-inventory.html) 인벤토리에서 수집한 모든 메타데이터의 목록을 보려면 [인벤토리에서 수집한 메타데이터](inventory-schema.md) 섹션을 참조하세요. |
| 대상 노드 | AWS 계정에서 관리되는 모든 노드의 인벤토리를 선택하고, 태그를 사용하여 개별적으로 노드 또는 대상 노드 그룹을 선택할 수 있습니다. 모든 관리형 노드에서 인벤토리 데이터를 수집하는 방법에 대한 자세한 내용은 [AWS 계정의 모든 관리형 노드에 대한 인벤토리 작성](inventory-collection.md#inventory-management-inventory-all) 섹션을 참조하세요. |
| 정보 수집 시기 | 수집 간격을 분, 시간 및 일 단위로 지정할 수 있습니다. 가장 짧은 수집 간격은 30분입니다. |
**참고**
수집하는 데이터의 용량에 따라 시스템이 데이터를 지정된 출력 경로에 보고하는 데 몇 분이 걸릴 수 있습니다. 정보가 수집된 후 보안 HTTPS 채널을 통해 AWS 계정에서만 액세스할 수 있는 일반 텍스트 AWS 스토어로 데이터가 전송됩니다.
Systems Manager 콘솔의 [**Inventory**] 페이지에서 데이터를 볼 수 있으며, 손쉽게 데이터를 쿼리할 수 있도록 여러 개의 미리 정의된 카드가 포함됩니다.
![\[Systems Manager 콘솔의 Systems Manager Inventory 카드\]](http://docs.aws.amazon.com/ko_kr/systems-manager/latest/userguide/images/inventory-cards.png)
**참고**
Inventory 카드가 [*종료됨(Terminated)*] 및 [*중지됨(Stopped)*] 상태의 Amazon EC2 관리형 인스턴스를 자동으로 필터링하여 제외합니다. 온프레미스와 AWS IoT Greengrass 코어 디바이스 관리형 노드의 경우 인벤토리 카드가 *종료됨* 상태의 노드를 자동으로 필터링하여 제외합니다.
리소스 데이터 동기화를 생성하여 단일 Amazon S3 버킷에 모든 데이터를 저장하고 동기화하는 경우 [**인벤토리 세부 정보 뷰(Inventory Detailed View)**] 페이지에서 데이터를 세부적으로 확인할 수 있습니다. 자세한 내용은 [여러 리전 및 계정에서 인벤토리 데이터 쿼리](systems-manager-inventory-query.md) 섹션을 참조하세요.
**EventBridge 지원**
이 Systems Manager 도구는 Amazon EventBridge 규칙에서 *이벤트* 유형으로 지원됩니다. 자세한 내용은 [Amazon EventBridge로 Systems Manager 이벤트 모니터링](monitoring-eventbridge-events.md) 및 [참조: Systems Manager용 Amazon EventBridge 이벤트 패턴 및 유형](reference-eventbridge-events.md) 섹션을 참조하세요.
**Topics**
+ [Systems Manager Inventory에 대해 자세히 알아보기](inventory-about.md)
+ [Systems Manager Inventory 설정](systems-manager-inventory-setting-up.md)
+ [인벤토리 수집 구성](inventory-collection.md)
+ [여러 리전 및 계정에서 인벤토리 데이터 쿼리](systems-manager-inventory-query.md)
+ [필터를 사용하여 인벤토리 수집 쿼리](inventory-query-filters.md)
+ [인벤토리 데이터 집계](inventory-aggregate.md)
+ [사용자 정의 인벤토리 작업](inventory-custom.md)
+ [인벤토리 이력 및 변경 사항 추적 보기](inventory-history.md)
+ [데이터 수집 중지 및 인벤토리 데이터 삭제](systems-manager-inventory-delete.md)
+ [관리형 노드에 사용자 지정 인벤토리 메타데이터 할당](inventory-custom-metadata.md)
+ [AWS CLI를 사용하여 인벤토리 데이터 수집 구성](inventory-collection-cli.md)
+ [연습: 리소스 데이터 동기화를 사용하여 인벤토리 데이터 집계](inventory-resource-data-sync.md)
+ [Systems Manager Inventory 관련 문제 해결](syman-inventory-troubleshooting.md)
# Systems Manager Inventory에 대해 자세히 알아보기
AWS Systems Manager 인벤토리를 구성할 때 수집할 메타데이터의 유형, 메타데이터를 수집할 관리형 노드, 메타데이터 모음에 대한 일정을 지정해야 합니다. 이러한 구성은 AWS 계정에 AWS Systems Manager State Manager 연결로 저장됩니다. 연결은 단순히 구성일 뿐입니다.
**참고**
인벤토리는 메타데이터만 수집합니다. 개인 정보나 독점 정보는 수집하지 않습니다.
**Topics**
+ [인벤토리에서 수집한 메타데이터](inventory-schema.md)
+ [파일 및 Windows 레지스트리 인벤토리 관련 작업](inventory-file-and-registry.md)
# 인벤토리에서 수집한 메타데이터
다음 샘플은 각 AWS Systems Manager Inventory 플러그인에서 수집한 메타데이터의 전체 목록을 보여줍니다.
```
{
"typeName": "AWS:InstanceInformation",
"version": "1.0",
"attributes":[
{ "name": "AgentType", "dataType" : "STRING"},
{ "name": "AgentVersion", "dataType" : "STRING"},
{ "name": "ComputerName", "dataType" : "STRING"},
{ "name": "InstanceId", "dataType" : "STRING"},
{ "name": "IpAddress", "dataType" : "STRING"},
{ "name": "PlatformName", "dataType" : "STRING"},
{ "name": "PlatformType", "dataType" : "STRING"},
{ "name": "PlatformVersion", "dataType" : "STRING"},
{ "name": "ResourceType", "dataType" : "STRING"},
{ "name": "AgentStatus", "dataType" : "STRING"},
{ "name": "InstanceStatus", "dataType" : "STRING"}
]
},
{
"typeName" : "AWS:Application",
"version": "1.1",
"attributes":[
{ "name": "Name", "dataType": "STRING"},
{ "name": "ApplicationType", "dataType": "STRING"},
{ "name": "Publisher", "dataType": "STRING"},
{ "name": "Version", "dataType": "STRING"},
{ "name": "Release", "dataType": "STRING"},
{ "name": "Epoch", "dataType": "STRING"},
{ "name": "InstalledTime", "dataType": "STRING"},
{ "name": "Architecture", "dataType": "STRING"},
{ "name": "URL", "dataType": "STRING"},
{ "name": "Summary", "dataType": "STRING"},
{ "name": "PackageId", "dataType": "STRING"}
]
},
{
"typeName" : "AWS:File",
"version": "1.0",
"attributes":[
{ "name": "Name", "dataType": "STRING"},
{ "name": "Size", "dataType": "STRING"},
{ "name": "Description", "dataType": "STRING"},
{ "name": "FileVersion", "dataType": "STRING"},
{ "name": "InstalledDate", "dataType": "STRING"},
{ "name": "ModificationTime", "dataType": "STRING"},
{ "name": "LastAccessTime", "dataType": "STRING"},
{ "name": "ProductName", "dataType": "STRING"},
{ "name": "InstalledDir", "dataType": "STRING"},
{ "name": "ProductLanguage", "dataType": "STRING"},
{ "name": "CompanyName", "dataType": "STRING"},
{ "name": "ProductVersion", "dataType": "STRING"}
]
},
{
"typeName": "AWS:AWSComponent",
"version": "1.0",
"attributes":[
{ "name": "Name", "dataType": "STRING"},
{ "name": "ApplicationType", "dataType": "STRING"},
{ "name": "Publisher", "dataType": "STRING"},
{ "name": "Version", "dataType": "STRING"},
{ "name": "InstalledTime", "dataType": "STRING"},
{ "name": "Architecture", "dataType": "STRING"},
{ "name": "URL", "dataType": "STRING"}
]
},
{
"typeName": "AWS:WindowsUpdate",
"version":"1.0",
"attributes":[
{ "name": "HotFixId", "dataType": "STRING"},
{ "name": "Description", "dataType": "STRING"},
{ "name": "InstalledTime", "dataType": "STRING"},
{ "name": "InstalledBy", "dataType": "STRING"}
]
},
{
"typeName": "AWS:Network",
"version":"1.0",
"attributes":[
{ "name": "Name", "dataType": "STRING"},
{ "name": "SubnetMask", "dataType": "STRING"},
{ "name": "Gateway", "dataType": "STRING"},
{ "name": "DHCPServer", "dataType": "STRING"},
{ "name": "DNSServer", "dataType": "STRING"},
{ "name": "MacAddress", "dataType": "STRING"},
{ "name": "IPV4", "dataType": "STRING"},
{ "name": "IPV6", "dataType": "STRING"}
]
},
{
"typeName": "AWS:PatchSummary",
"version":"1.0",
"attributes":[
{ "name": "PatchGroup", "dataType": "STRING"},
{ "name": "BaselineId", "dataType": "STRING"},
{ "name": "SnapshotId", "dataType": "STRING"},
{ "name": "OwnerInformation", "dataType": "STRING"},
{ "name": "InstalledCount", "dataType": "NUMBER"},
{ "name": "InstalledPendingRebootCount", "dataType": "NUMBER"},
{ "name": "InstalledOtherCount", "dataType": "NUMBER"},
{ "name": "InstalledRejectedCount", "dataType": "NUMBER"},
{ "name": "NotApplicableCount", "dataType": "NUMBER"},
{ "name": "UnreportedNotApplicableCount", "dataType": "NUMBER"},
{ "name": "MissingCount", "dataType": "NUMBER"},
{ "name": "FailedCount", "dataType": "NUMBER"},
{ "name": "OperationType", "dataType": "STRING"},
{ "name": "OperationStartTime", "dataType": "STRING"},
{ "name": "OperationEndTime", "dataType": "STRING"},
{ "name": "InstallOverrideList", "dataType": "STRING"},
{ "name": "RebootOption", "dataType": "STRING"},
{ "name": "LastNoRebootInstallOperationTime", "dataType": "STRING"},
{ "name": "ExecutionId", "dataType": "STRING", "isOptional": "true"},
{ "name": "NonCompliantSeverity", "dataType": "STRING", "isOptional": "true"},
{ "name": "SecurityNonCompliantCount", "dataType": "NUMBER", "isOptional": "true"},
{ "name": "CriticalNonCompliantCount", "dataType": "NUMBER", "isOptional": "true"},
{ "name": "OtherNonCompliantCount", "dataType": "NUMBER", "isOptional": "true"}
]
},
{
"typeName": "AWS:PatchCompliance",
"version":"1.0",
"attributes":[
{ "name": "Title", "dataType": "STRING"},
{ "name": "KBId", "dataType": "STRING"},
{ "name": "Classification", "dataType": "STRING"},
{ "name": "Severity", "dataType": "STRING"},
{ "name": "State", "dataType": "STRING"},
{ "name": "InstalledTime", "dataType": "STRING"}
]
},
{
"typeName": "AWS:ComplianceItem",
"version":"1.0",
"attributes":[
{ "name": "ComplianceType", "dataType": "STRING", "isContext": "true"},
{ "name": "ExecutionId", "dataType": "STRING", "isContext": "true"},
{ "name": "ExecutionType", "dataType": "STRING", "isContext": "true"},
{ "name": "ExecutionTime", "dataType": "STRING", "isContext": "true"},
{ "name": "Id", "dataType": "STRING"},
{ "name": "Title", "dataType": "STRING"},
{ "name": "Status", "dataType": "STRING"},
{ "name": "Severity", "dataType": "STRING"},
{ "name": "DocumentName", "dataType": "STRING"},
{ "name": "DocumentVersion", "dataType": "STRING"},
{ "name": "Classification", "dataType": "STRING"},
{ "name": "PatchBaselineId", "dataType": "STRING"},
{ "name": "PatchSeverity", "dataType": "STRING"},
{ "name": "PatchState", "dataType": "STRING"},
{ "name": "PatchGroup", "dataType": "STRING"},
{ "name": "InstalledTime", "dataType": "STRING"},
{ "name": "InstallOverrideList", "dataType": "STRING", "isOptional": "true"},
{ "name": "DetailedText", "dataType": "STRING", "isOptional": "true"},
{ "name": "DetailedLink", "dataType": "STRING", "isOptional": "true"},
{ "name": "CVEIds", "dataType": "STRING", "isOptional": "true"}
]
},
{
"typeName": "AWS:ComplianceSummary",
"version":"1.0",
"attributes":[
{ "name": "ComplianceType", "dataType": "STRING"},
{ "name": "PatchGroup", "dataType": "STRING"},
{ "name": "PatchBaselineId", "dataType": "STRING"},
{ "name": "Status", "dataType": "STRING"},
{ "name": "OverallSeverity", "dataType": "STRING"},
{ "name": "ExecutionId", "dataType": "STRING"},
{ "name": "ExecutionType", "dataType": "STRING"},
{ "name": "ExecutionTime", "dataType": "STRING"},
{ "name": "CompliantCriticalCount", "dataType": "NUMBER"},
{ "name": "CompliantHighCount", "dataType": "NUMBER"},
{ "name": "CompliantMediumCount", "dataType": "NUMBER"},
{ "name": "CompliantLowCount", "dataType": "NUMBER"},
{ "name": "CompliantInformationalCount", "dataType": "NUMBER"},
{ "name": "CompliantUnspecifiedCount", "dataType": "NUMBER"},
{ "name": "NonCompliantCriticalCount", "dataType": "NUMBER"},
{ "name": "NonCompliantHighCount", "dataType": "NUMBER"},
{ "name": "NonCompliantMediumCount", "dataType": "NUMBER"},
{ "name": "NonCompliantLowCount", "dataType": "NUMBER"},
{ "name": "NonCompliantInformationalCount", "dataType": "NUMBER"},
{ "name": "NonCompliantUnspecifiedCount", "dataType": "NUMBER"}
]
},
{
"typeName": "AWS:InstanceDetailedInformation",
"version":"1.0",
"attributes":[
{ "name": "CPUModel", "dataType": "STRING"},
{ "name": "CPUCores", "dataType": "NUMBER"},
{ "name": "CPUs", "dataType": "NUMBER"},
{ "name": "CPUSpeedMHz", "dataType": "NUMBER"},
{ "name": "CPUSockets", "dataType": "NUMBER"},
{ "name": "CPUHyperThreadEnabled", "dataType": "STRING"},
{ "name": "OSServicePack", "dataType": "STRING"}
]
},
{
"typeName": "AWS:Service",
"version":"1.0",
"attributes":[
{ "name": "Name", "dataType": "STRING"},
{ "name": "DisplayName", "dataType": "STRING"},
{ "name": "ServiceType", "dataType": "STRING"},
{ "name": "Status", "dataType": "STRING"},
{ "name": "DependentServices", "dataType": "STRING"},
{ "name": "ServicesDependedOn", "dataType": "STRING"},
{ "name": "StartType", "dataType": "STRING"}
]
},
{
"typeName": "AWS:WindowsRegistry",
"version":"1.0",
"attributes":[
{ "name": "KeyPath", "dataType": "STRING"},
{ "name": "ValueName", "dataType": "STRING"},
{ "name": "ValueType", "dataType": "STRING"},
{ "name": "Value", "dataType": "STRING"}
]
},
{
"typeName": "AWS:WindowsRole",
"version":"1.0",
"attributes":[
{ "name": "Name", "dataType": "STRING"},
{ "name": "DisplayName", "dataType": "STRING"},
{ "name": "Path", "dataType": "STRING"},
{ "name": "FeatureType", "dataType": "STRING"},
{ "name": "DependsOn", "dataType": "STRING"},
{ "name": "Description", "dataType": "STRING"},
{ "name": "Installed", "dataType": "STRING"},
{ "name": "InstalledState", "dataType": "STRING"},
{ "name": "SubFeatures", "dataType": "STRING"},
{ "name": "ServerComponentDescriptor", "dataType": "STRING"},
{ "name": "Parent", "dataType": "STRING"}
]
},
{
"typeName": "AWS:Tag",
"version":"1.0",
"attributes":[
{ "name": "Key", "dataType": "STRING"},
{ "name": "Value", "dataType": "STRING"}
]
},
{
"typeName": "AWS:ResourceGroup",
"version":"1.0",
"attributes":[
{ "name": "Name", "dataType": "STRING"},
{ "name": "Arn", "dataType": "STRING"}
]
},
{
"typeName": "AWS:BillingInfo",
"version": "1.0",
"attributes": [
{ "name": "BillingProductId", "dataType": "STRING"}
]
}
```
**참고**
`"typeName": "AWS:InstanceInformation"`의 경우에, `InstanceStatus`는 Active, ConnectionLost, Stopped, Terminated 중 하나일 수 있습니다.
버전 2.5의 릴리스에서 RPM Package Manager는 일련 속성을 Epoch로 교체했습니다. Epoch 속성은 일련처럼 단조 증가하는 정수입니다. `AWS:Application` 유형을 이용해 인벤토리를 작성할 때 큰 Epoch 값은 새 버전을 의미합니다. Epoch 값이 동일하거나 빈 경우에는 버전 또는 릴리스 속성의 값으로 새 버전을 판단합니다.
일부 메타데이터는 Linux 인스턴스에서 제공되지 않습니다. 특히 "typeName": "AWS:Network"의 경우 다음과 같은 메타데이터 유형은 아직 Linux 인스턴스에 대해 지원되지 않습니다. Windows의 경우에는 지원됩니다.
\$1 "name": "SubnetMask", "dataType": "STRING"\$1,
\$1 "name": "DHCPServer", "dataType": "STRING"\$1,
\$1 "name": "DNSServer", "dataType": "STRING"\$1,
\$1 "name": "Gateway", "dataType": "STRING"\$1,
# 파일 및 Windows 레지스트리 인벤토리 관련 작업
AWS Systems Manager Inventory를 통해 Windows Server, Linux 및 macOS 운영 체제에서 파일을 검색하고 인벤토리로 만들 수 있습니다. 또한 Windows 레지스트리를 검색하고 인벤토리로 만들 수 있습니다.
**Files**: 몇 가지 예를 들자면 파일 이름, 파일 생성 시각, 파일을 마지막으로 수정하고 액세스한 시간, 파일 크기 등 파일에 관한 메타데이터 정보를 수집할 수 있습니다. 파일 인벤토리 수집을 시작하려면 인벤토리를 수행할 파일 경로, 인벤토리로 만들고자 하는 파일의 유형을 정의하는 패턴 한 개 이상, 그리고 그 경로가 반복적으로 통과하는지 여부를 지정합니다. Systems Manager는 패턴과 일치하는 지정된 경로의 파일에 대한 모든 파일 메타데이터의 인벤토리를 작성합니다. 파일 인벤토리에서는 다음 파라미터 입력을 사용합니다.
```
{
"Path": string,
"Pattern": array[string],
"Recursive": true,
"DirScanLimit" : number // Optional
}
```
+ **Path**: 파일을 인벤토리로 만들고자 하는 디렉터리 경로. Windows에서는 해당 환경 변수가 단일 디렉터리 경로와 매핑되는 경우에 한해 `%PROGRAMFILES% `와 같은 환경 변수를 사용할 수 있습니다. 예를 들어 여러 디렉터리 경로에 매핑되는 %PATH%를 사용하는 경우 Inventory에는 오류가 발생합니다.
+ **Pattern**: 파일을 식별할 패턴의 어레이
+ **Recursive**: Inventory가 디렉터리를 반복적으로 통과하는지 여부를 나타내는 부울 값
+ **DirScanLimit**: 몇 개의 디렉터리를 검사할 수 있는지 지정하는 값(선택 사항). 이 파라미터를 사용하여 해당 노드의 성능 저하를 최소화합니다. Inventory는 최소 5,000개의 디렉터리를 검사합니다.
**참고**
Inventory는 지정된 모든 경로에서 최소 500개 파일에 대해 메타데이터를 수집합니다.
다음은 파일에 대한 인벤토리 작업을 수행할 때 파라미터를 지정하는 방법을 보여주는 예제입니다.
+ Linux 및 macOS에서는 `/home/ec2-user` 디렉터리(하위 디렉터리는 모두 제외)에 .sh 파일에 대한 메타데이터를 수집합니다.
```
[{"Path":"/home/ec2-user","Pattern":["*.sh", "*.sh"],"Recursive":false}]
```
+ Windows에서는 모든 ".exe" 파일에 대한 메타데이터를 Program Files 폴더(하위 디렉터리 포함)에 반복적으로 수집합니다.
```
[{"Path":"C:\Program Files","Pattern":["*.exe"],"Recursive":true}]
```
+ Windows에서는 특정 로그 패턴의 메타데이터를 수집합니다.
```
[{"Path":"C:\ProgramData\Amazon","Pattern":["*amazon*.log"],"Recursive":true}]
```
+ 반복 수집을 수행할 때는 디렉터리 개수를 제한합니다.
```
[{"Path":"C:\Users","Pattern":["*.ps1"],"Recursive":true, "DirScanLimit": 1000}]
```
**Windows 레지스트리**: Windows 레지스트리 키 및 값을 수집할 수 있습니다. 키 경로를 선택하고 모든 키와 값을 반복적으로 수집할 수 있습니다. 특정 경로에 대해 특정 레지스트리 키와 그 값을 수집할 수도 있습니다. 인벤토리는 키 경로, 이름 및 값을 수집합니다.
```
{
"Path": string,
"Recursive": true,
"ValueNames": array[string] // optional
}
```
+ **Path**: 레지스트리 키의 경로
+ **Recursive**: 인벤토리가 레지스트리 경로를 반복적으로 통과하는지 여부를 나타내는 부울 값
+ **ValueNames**: 레지스트리 키에 대한 인벤토리 작업을 위한 값 이름의 어레이. 이 파라미터를 사용하는 경우 Systems Manager는 지정된 경로에 대한 지정된 값 이름만 인벤토리로 만듭니다.
**참고**
인벤토리는 지정된 모든 경로에 대해 최소 250개 레지스트리 키 값을 수집합니다.
다음은 Windows 레지스트리에 대한 인벤토리 작업을 수행할 때 파라미터를 지정하는 방법을 보여주는 예제입니다.
+ 특정 경로에 대해 모든 키와 값을 반복적으로 수집합니다.
```
[{"Path":"HKEY_LOCAL_MACHINE\SOFTWARE\Amazon","Recursive": true}]
```
+ 특정 경로에 대해 모든 키와 값을 수집합니다(반복 검색은 해제됨).
```
[{"Path":"HKEY_LOCAL_MACHINE\SOFTWARE\Intel\PSIS\PSIS_DECODER", "Recursive": false}]
```
+ `ValueNames` 옵션을 사용하여 특정 키를 수집합니다.
```
{"Path":"HKEY_LOCAL_MACHINE\SOFTWARE\Amazon\MachineImage","ValueNames":["AMIName"]}
```
# Systems Manager Inventory 설정
AWS Systems Manager Inventory를 사용하여 관리형 노드에서 실행 중인 애플리케이션, 서비스, AWS 구성 요소 등에 대한 메타데이터를 수집하기 전에 단일 Amazon Simple Storage Service(Amazon S3) 버킷의 인벤토리 데이터 스토리지를 중앙 집중화하도록 리소스 데이터 동기화를 구성하는 것이 좋습니다. 또한 인벤토리 이벤트의 Amazon EventBridge 모니터링을 구성하는 것이 좋습니다. 이러한 프로세스를 통해 인벤토리 데이터 및 수집을 보다 쉽게 보고 관리할 수 있습니다.
**Topics**
+ [인벤토리의 리소스 데이터 동기화 생성](inventory-create-resource-data-sync.md)
+ [EventBridge를 사용한 Inventory 이벤트 모니터링](systems-manager-inventory-setting-up-eventbridge.md)
# 인벤토리의 리소스 데이터 동기화 생성
이 주제에서는 AWS Systems Manager 인벤토리에 대한 리소스 데이터 동기화를 설정하고 구성하는 방법에 대해 설명합니다. Systems Manager Explorer의 리소스 데이터 동기화에 대한 자세한 내용은 [여러 계정 및 리전에서 데이터를 표시하도록 Systems Manager Explorer 설정](Explorer-resource-data-sync.md) 단원을 참조하세요.
## 리소스 데이터 동기화 정보
Systems Manager 리소스 데이터 동기화를 사용하여 모든 관리형 노드에서 수집된 인벤토리 데이터를 단일 Amazon Simple Storage Service(Amazon S3) 버킷으로 전송합니다. 이제 새로운 인벤토리 데이터가 수집될 때마다 리소스 데이터 동기화가 중앙 데이터를 자동으로 업데이트합니다. 모든 인벤토리 데이터가 대상 Amazon S3 버킷에 저장되면 Amazon Athena와 Amazon Quick 같은 서비스를 사용하여 수집한 데이터에 대한 쿼리를 실행하거나 분석할 수 있습니다.
예를 들어 150개 관리형 노드 플릿에서 실행 중인 운영 체제(OS) 및 애플리케이션에 대한 데이터를 수집할 수 있도록 인벤토리를 구성하였다고 가정하겠습니다. 이러한 노드 중 일부는 노드는 온프레미스 데이터 센터에 있고, 다른 노드는 여러 AWS 리전의 Amazon Elastic Compute Cloud(Amazon EC2)에서 실행되고 있습니다. 리소스 데이터 동기화를 구성하지 *않았다면* 각 노드마다 수집된 인벤토리 데이터를 수동으로 수집하거나, 혹은 스크립트를 생성하여 이 정보를 수집해야 합니다. 그런 다음 쿼리를 통해 데이터를 분석하려면 데이터를 애플리케이션으로 포팅해야 합니다.
리소스 데이터 동기화를 사용하면 작업 한 번으로 모든 관리형 노드에서 수집된 인벤토리 데이터를 모두 동기화할 수 있습니다. 동기화가 성공적으로 생성되면 Systems Manager가 모든 인벤토리 데이터의 기준을 만들어서 대상 Amazon S3 버킷에 저장합니다. 이후 새로운 인벤토리 데이터가 수집되면 Systems Manager가 Amazon S3 버킷의 데이터를 자동 업데이트합니다. 이후부터는 데이터를 빠르고 경제적으로 Amazon Athena 및 Amazon Quick에 포팅할 수 있습니다.
다이어그램 1에서는 리소스 데이터 동기화를 통해 [하이브리드 및 멀티클라우](operating-systems-and-machine-types.md#supported-machine-types)드 환경의 Amazon EC2 및 기타 시스템 유형에서 대상 Amazon S3 버킷으로 인벤토리 데이터를 집계하는 방법을 보여줍니다. 또한 리소스 데이터 동기화가 여러 AWS 계정 및 AWS 리전에서 어떻게 작동하는지도 보여줍니다.
**다이어그램 1: 여러 AWS 계정 및 AWS 리전에서 리소스 데이터 동기화**
![\[Systems Manager 리소스 데이터 동기화 아키텍처\]](http://docs.aws.amazon.com/ko_kr/systems-manager/latest/userguide/images/inventory-resource-data-sync-updated.png)
관리형 노드가 삭제되더라도 리소스 데이터 동기화가 삭제된 노드의 인벤토리 파일을 보존합니다. 하지만 실행 노드의 경우에는 새로운 파일이 생성되어 Amazon S3 버킷에 작성되면 리소스 데이터 동기화가 이전 인벤토리 파일을 자동으로 덮어씁니다. 시간 경과에 따른 인벤토리 변경 사항을 추적하고 싶다면 AWS Config 서비스를 사용하여 `SSM:ManagedInstanceInventory` 리소스 유형을 추적할 수 있습니다. 자세한 내용은 [AWS Config 시작하기](https://docs.aws.amazon.com/config/latest/developerguide/getting-started.html) 섹션을 참조하세요.
이 섹션의 절차에 따라 Amazon S3 및 AWS Systems Manager 콘솔을 사용하여 Inventory에 대한 리소스 데이터 동기화를 생성할 수 있습니다. AWS CloudFormation을 사용하여 리소스 데이터 동기화를 생성하거나 삭제할 수도 있습니다. CloudFormation을 사용하려면 CloudFormation 템플릿에 [https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-ssm-resourcedatasync.html](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-ssm-resourcedatasync.html) 리소스를 추가합니다. 자세한 내용은 다음 설명서 리소스 중 하나를 참조하세요.
+ [AWS CloudFormation resource for resource data sync in AWS Systems Manager](https://aws.amazon.com/blogs/mt/aws-cloudformation-resource-for-resource-data-sync-in-aws-systems-manager/)(블로그)
+ *AWS CloudFormation 사용 설명서*의 [AWS CloudFormation 템플릿 작업](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/template-guide.html)
**참고**
AWS Key Management Service(AWS KMS)를 사용하여 Amazon S3 버킷의 인벤토리 데이터를 암호화할 수 있습니다. AWS Command Line Interface(AWS CLI)를 사용하여 암호화된 동기화를 생성하는 방법과 Amazon Athena 및 Amazon Quick에서 중앙 데이터를 사용하는 방법에 대한 예는 [연습: 리소스 데이터 동기화를 사용하여 인벤토리 데이터 집계](inventory-resource-data-sync.md) 섹션을 참조하세요.
## 시작하기 전 준비 사항
리소스 데이터 동기화를 생성하기 전에 다음 절차를 사용하여 집계된 인벤토리 데이터를 저장할 중앙 Amazon S3 버킷을 생성합니다. 이 절차에서는 Systems Manager가 여러 계정에서 버킷에 인벤토리 데이터를 쓸 수 있는 버킷 정책을 할당하는 방법을 설명합니다. 리소스 데이터 동기화를 위해 인벤토리 데이터를 집계하는 데 사용할 Amazon S3 버킷이 이미 있는 경우 다음 절차에서 정책을 사용하도록 버킷을 구성해야 합니다.
**참고**
지정된 Amazon S3 버킷이 Object Lock을 사용하도록 구성된 경우 Systems Manager Inventory는 해당 버킷에 데이터를 추가할 수 없습니다. 리소스 데이터 동기화를 위해 생성하거나 선택한 Amazon S3 버킷이 Amazon S3 Object Lock을 사용하도록 구성되지 않았는지 확인합니다. 자세한 내용은 *Amazon Simple Storage Service 사용 설명서*의 [Amazon S3 Object Lock 작동 방식](https://docs.aws.amazon.com/AmazonS3/latest/userguide/object-lock-overview.html)을 참조하세요.
**리소스 데이터 동기화를 위해 Amazon S3 버킷을 생성하고 구성하려면**
1. [https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/)에서 S3 콘솔을 엽니다.
1. 수집한 인벤토리 데이터를 저장할 버킷을 생성합니다. 자세한 내용은 *Amazon Simple Storage Service 사용 설명서*의 [버킷 생성](https://docs.aws.amazon.com/AmazonS3/latest/userguide/CreatingABucket.html)을 참조하세요. 버킷 이름과 버킷을 생성한 AWS 리전을 따로 적어둡니다.
1. **권한** 탭을 선택한 후 **버킷 정책**을 선택합니다.
1. 다음 버킷 정책을 복사하여 정책 편집기에 붙여 넣습니다. *amzn-s3-demo-bucket*을 생성한 S3 버킷의 이름으로 바꿉니다. *account\$1ID\$1number*를 유효한 AWS 계정 ID 번호로 바꿉니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "SSMBucketPermissionsCheck",
"Effect": "Allow",
"Principal": {
"Service": "ssm.amazonaws.com"
},
"Action": "s3:GetBucketAcl",
"Resource": "arn:aws:s3:::amzn-s3-demo-bucket"
},
{
"Sid": " SSMBucketDelivery",
"Effect": "Allow",
"Principal": {
"Service": "ssm.amazonaws.com"
},
"Action": "s3:PutObject",
"Resource": [
"arn:aws:s3:::amzn-s3-demo-bucket/*/accountid=111122223333/*",
"arn:aws:s3:::amzn-s3-demo-bucket/*/accountid=444455556666/*",
"arn:aws:s3:::amzn-s3-demo-bucket/*/accountid=123456789012/*",
"arn:aws:s3:::amzn-s3-demo-bucket/*/accountid=777788889999/*"
],
"Condition": {
"StringEquals": {
"s3:x-amz-acl": "bucket-owner-full-control",
"aws:SourceAccount": "111122223333"
},
"ArnLike": {
"aws:SourceArn": "arn:aws:ssm:*:111122223333:resource-data-sync/*"
}
}
}
]
}
```
------
1. 변경 내용을 저장합니다.
## Inventory의 리소스 데이터 동기화 생성
Systems Manager Inventory의 리소스 데이터 동기화는 Systems Manager 콘솔에서 다음 절차에 따라 생성합니다. AWS CLI를 사용하여 리소스 데이터 동기화를 만드는 방법에 대한 자세한 내용은 [AWS CLI를 사용하여 인벤토리 데이터 수집 구성](inventory-collection-cli.md) 섹션을 참조하세요.
**리소스 데이터 동기화 생성**
1. [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)에서 AWS Systems Manager 콘솔을 엽니다.
1. 탐색 창에서 **Fleet Manager**를 선택합니다.
1. [**계정 관리(Account management)**] 메뉴에서 [**리소스 데이터 동기화(Resource data sync)**]를 선택합니다.
1. **Create resource data sync(리소스 데이터 동기화 생성)**를 선택합니다.
1. [**동기화 이름(Sync name)**] 필드에 동기화 구성 이름을 입력합니다.
1. [**버킷 이름(Bucket name)**] 필드에 **리소스 데이터 동기화를 위한 Amazon S3 버킷을 생성하고 구성하려면** 절차를 사용하여 생성한 Amazon S3 버킷의 이름을 입력합니다.
1. (옵션) [**버킷 접두사(Bucket prefix)**] 필드에 Amazon S3 버킷 접두사(하위 디렉터리)의 이름을 입력합니다.
1. 생성한 Amazon S3 버킷이 현재 AWS 리전에 위치하면 [**버킷 리전(Bucket region)**] 필드에서 [**이 리전(This region)**]을 선택합니다. 버킷이 다른 AWS 리전에 위치하면 [**다른 리전(Another region)**]을 선택하고 리전 이름을 입력합니다.
**참고**
동기화와 대상 Amazon S3 버킷이 서로 다른 리전에 위치하는 경우에는 데이터 전송 요금이 부과될 수 있습니다. 자세한 내용은 [Amazon S3 요금](https://aws.amazon.com/s3/pricing/)을 참조하세요.
1. (옵션) [**KMS Key ARN**] 필드에 Amazon S3의 인벤토리 데이터를 암호화할 KMS 키 ARN을 입력하거나 붙여 넣습니다.
1. **생성(Create)**을 선택합니다.
여러 AWS 리전의 인벤토리 데이터를 동기화하려면 *각* 리전에서 리소스 데이터 동기화를 생성해야 합니다. 인벤토리 데이터를 수집해 중앙 Amazon S3 버킷으로 보내려는 각 AWS 리전에서 이 절차를 반복합니다. 각 리전에서 동기화를 생성할 때 [**버킷 이름(Bucket name)**] 필드에 중앙 Amazon S3 버킷을 지정합니다. 그런 다음 [**버킷 리전(Bucket region)**] 옵션을 사용하여 다음 스크린샷에 표시된 것처럼 중앙 Amazon S3 버킷을 생성한 리전을 선택합니다. 연결이 실행되어 인벤토리 데이터를 수집하고 나면 Systems Manager가 중앙 Amazon S3 버킷에 데이터를 저장합니다.
![\[여러 AWS 리전에서 Systems Manager 리소스 데이터 동기화\]](http://docs.aws.amazon.com/ko_kr/systems-manager/latest/userguide/images/inventory-rds-multiple-regions.png)
## AWS Organizations에 정의된 계정에 대한 인벤토리 리소스 데이터 동기화 생성
AWS Organizations에 정의된 AWS 계정의 인벤토리 데이터를 중앙 Amazon S3 버킷으로 동기화할 수 있습니다. 다음 절차를 완료하면 인벤토리 데이터가 중앙 버킷의 *개별* Amazon S3 키 접두사와 동기화됩니다. 각 키 접두사는 서로 다른 AWS 계정 ID를 나타냅니다.
**시작하기 전 준비 사항**
시작하기 전에 AWS Organizations에서 AWS 계정를 설정하고 구성했는지 확인합니다. 자세한 내용은 [https://docs.aws.amazon.com/organizations/latest/userguide/rgs_getting-started.html](https://docs.aws.amazon.com/organizations/latest/userguide/rgs_getting-started.html)를 참조하세요.
또한 AWS Organizations에 정의된 AWS 리전과 AWS 계정 각각에 대해 조직 기반 자원 데이터 동기화를 생성해야 합니다.
### 중앙 Amazon S3 버킷 생성
다음 절차를 사용하여 집계된 인벤토리 데이터를 저장할 중앙 Amazon S3 버킷을 생성합니다. 이 절차에서는 Systems Manager가 AWS Organizations 계정 ID에서 버킷에 인벤토리 데이터를 쓸 수 있는 버킷 정책을 할당하는 방법을 설명합니다. 리소스 데이터 동기화를 위해 인벤토리 데이터를 집계하는 데 사용할 Amazon S3 버킷이 이미 있는 경우 다음 절차에서 정책을 사용하도록 버킷을 구성해야 합니다.
**AWS Organizations에 정의된 여러 계정의 리소스 데이터 동기화를 위한 Amazon S3 버킷을 생성하고 구성하려면**
1. [https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/)에서 S3 콘솔을 엽니다.
1. 집계된 인벤토리 데이터를 저장할 버킷을 생성합니다. 자세한 내용은 *Amazon Simple Storage Service 사용 설명서*의 [버킷 생성](https://docs.aws.amazon.com/AmazonS3/latest/userguide/CreatingABucket.html)을 참조하세요. 버킷 이름과 버킷을 생성한 AWS 리전을 따로 적어둡니다.
1. **권한** 탭을 선택한 후 **버킷 정책**을 선택합니다.
1. 다음 버킷 정책을 복사하여 정책 편집기에 붙여 넣습니다. *amzn-s3-demo-bucket* 및 *organization-id*를 사용자가 생성한 Amazon S3 버킷 이름 및 유효한 AWS Organizations 계정 ID로 바꿉니다.
원할 경우 *bucket-prefix*를 Amazon S3 접두사(하위 디렉터리) 이름으로 바꿉니다. 접두사를 생성하지 않았을 경우에는 다음 정책의 ARN에서 *bucket-prefix/*를 제거하세요.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "SSMBucketPermissionsCheck",
"Effect": "Allow",
"Principal": {
"Service": "ssm.amazonaws.com"
},
"Action": "s3:GetBucketAcl",
"Resource": "arn:aws:s3:::amzn-s3-demo-bucket"
},
{
"Sid": " SSMBucketDelivery",
"Effect": "Allow",
"Principal": {
"Service": "ssm.amazonaws.com"
},
"Action": "s3:PutObject",
"Resource": [
"arn:aws:s3:::amzn-s3-demo-bucket/bucket-prefix/*/accountid=*/*"
],
"Condition": {
"StringEquals": {
"s3:x-amz-acl": "bucket-owner-full-control",
"aws:SourceOrgID": "organization-id"
}
}
},
{
"Sid": " SSMBucketDeliveryTagging",
"Effect": "Allow",
"Principal": {
"Service": "ssm.amazonaws.com"
},
"Action": "s3:PutObjectTagging",
"Resource": [
"arn:aws:s3:::amzn-s3-demo-bucket/bucket-prefix/*/accountid=*/*"
]
}
]
}
```
------
### AWS Organizations에 정의된 계정에 대한 인벤토리 리소스 데이터 동기화 생성
다음 절차에서는 AWS CLI를 사용하여 AWS Organizations에 정의된 계정에 대한 리소스 데이터 동기화를 만드는 방법을 설명합니다. 이 작업을 수행하려면 AWS CLI를 사용해야 합니다. AWS Organizations에 정의된 AWS 리전과 AWS 계정에 대해서도 각각 이 절차를 수행해야 합니다.
**AWS Organizations(AWS CLI)에 정의된 계정에 대한 리소스 데이터 동기화를 생성하려면**
1. 아직 하지 않은 경우 AWS Command Line Interface(AWS CLI)을 설치하고 구성합니다.
자세한 내용은 [최신 버전의 AWS CLI 설치 또는 업데이트](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html)를 참조하세요.
1. 다음 명령을 실행하여 다른 *AWS Organizations 기반* 리소스 데이터 동기화가 없는지 확인합니다. 여러 표준 동기화 및 Organizations 기반 동기화를 비롯한 다양한 동기화를 사용할 수 있습니다. 그러나 Organizations 기반 리소스 데이터 동기화는 하나만 가질 수 있습니다.
```
aws ssm list-resource-data-sync
```
명령이 다른 Organizations 기반 리소스 데이터 동기화를 반환하는 경우 이를 삭제하거나 새 동기화를 생성하지 않도록 선택해야 합니다.
1. 다음 명령을 실행하여 AWS Organizations에 정의된 계정에 대한 리소스 데이터 동기화를 생성합니다. amzn-s3-demo-bucket에 이 주제의 앞부분에서 생성한 Amazon S3 버킷의 이름을 지정합니다. 버킷의 접두사(하위 디렉터리)를 생성한 경우 *prefix-name*에 이 정보를 지정합니다.
```
aws ssm create-resource-data-sync --sync-name name --s3-destination "BucketName=amzn-s3-demo-bucket,Prefix=prefix-name,SyncFormat=JsonSerDe,Region=AWS 리전, for example us-east-2,DestinationDataSharing={DestinationDataSharingType=Organization}"
```
1. 중앙 Amazon S3 버킷에 데이터를 동기화하려는 모든 AWS 리전 및 AWS 계정에 대해 2단계와 3단계를 반복합니다.
### 리소스 데이터 동기화 관리
각 AWS 계정에서는 AWS 리전당 리소스 데이터 동기화가 5회씩 발생할 수 있습니다. AWS Systems Manager Fleet Manager콘솔을 사용하여 리소스 데이터 동기화를 관리할 수 있습니다.
**리소스 데이터 동기화를 보는 방법**
1. [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)에서 AWS Systems Manager 콘솔을 엽니다.
1. 탐색 창에서 **Fleet Manager**를 선택합니다.
1. **계정 관리** 드롭다운에서 **리소스 데이터 동기화**를 선택합니다.
1. 테이블에서 리소스 데이터 동기화를 선택한 다음에 **세부 정보 보기**를 선택하여 리소스 데이터 동기화에 대한 정보를 봅니다.
**리소스 데이터 동기화 삭제**
1. [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)에서 AWS Systems Manager 콘솔을 엽니다.
1. 탐색 창에서 **Fleet Manager**를 선택합니다.
1. **계정 관리** 드롭다운에서 **리소스 데이터 동기화**를 선택합니다.
1. 테이블에서 리소스 데이터 동기화를 선택한 다음에 **삭제**를 선택합니다.
# EventBridge를 사용한 Inventory 이벤트 모니터링
AWS Systems Manager Inventory 리소스 상태 변경에 대한 응답으로 이벤트를 생성하도록 Amazon EventBridge에서 규칙을 구성할 수 있습니다. EventBridge는 다음과 같은 Inventory 상태 변경에 대한 이벤트를 지원합니다. 모든 이벤트는 최선의 작업을 기반으로 전송됩니다.
**특정 인스턴스에 대해 사용자 정의 인벤토리 유형이 삭제됨**: 이 이벤트를 모니터링하도록 규칙이 구성된 경우 특정 관리형의 사용자 정의 인벤토리 유형이 삭제될 때 EventBridge가 이벤트를 생성합니다. EventBridge는 사용자 정의 인벤토리 유형별로 노드당 하나의 이벤트를 보냅니다. 다음은 샘플 이벤트 패턴입니다.
```
{
"timestampMillis": 1610042981103,
"source": "SSM",
"account": "123456789012",
"type": "INVENTORY_RESOURCE_STATE_CHANGE",
"startTime": "Jan 7, 2021 6:09:41 PM",
"resources": [
{
"arn": "arn:aws:ssm:us-east-1:123456789012:managed-instance/i-12345678"
}
],
"body": {
"action-status": "succeeded",
"action": "delete",
"resource-type": "managed-instance",
"resource-id": "i-12345678",
"action-reason": "",
"type-name": "Custom:MyCustomInventoryType"
}
}
```
**모든 인스턴스에 대한 사용자 정의 인벤토리 유형이 삭제됨**: 이 이벤트를 모니터링하도록 규칙이 구성된 경우 모든 관리형 노드의 사용자 정의 인벤토리 유형이 삭제될 때 EventBridge가 이벤트를 생성합니다. 다음은 샘플 이벤트 패턴입니다.
```
{
"timestampMillis": 1610042904712,
"source": "SSM",
"account": "123456789012",
"type": "INVENTORY_RESOURCE_STATE_CHANGE",
"startTime": "Jan 7, 2021 6:08:24 PM",
"resources": [
],
"body": {
"action-status": "succeeded",
"action": "delete-summary",
"resource-type": "managed-instance",
"resource-id": "",
"action-reason": "The delete for type name Custom:SomeCustomInventoryType was completed. The deletion summary is: {\"totalCount\":1,\"remainingCount\":0,\"summaryItems\":[{\"version\":\"1.1\",\"count\":1,\"remainingCount\":0}]}",
"type-name": "Custom:MyCustomInventoryType"
}
}
```
**이전 스키마 버전으로 [PutInventory](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PutInventory.html) 호출**: 이 이벤트를 모니터링하도록 규칙이 구성된 경우 현재 스키마보다 낮은 스키마 버전을 사용하는 PutInventory 호출이 수행될 때 EventBridge가 이벤트를 생성합니다. 이 이벤트는 모든 인벤토리 유형에 적용됩니다. 다음은 샘플 이벤트 패턴입니다.
```
{
"timestampMillis": 1610042629548,
"source": "SSM",
"account": "123456789012",
"type": "INVENTORY_RESOURCE_STATE_CHANGE",
"startTime": "Jan 7, 2021 6:03:49 PM",
"resources": [
{
"arn": "arn:aws:ssm:us-east-1:123456789012:managed-instance/i-12345678"
}
],
"body": {
"action-status": "failed",
"action": "put",
"resource-type": "managed-instance",
"resource-id": "i-01f017c1b2efbe2bc",
"action-reason": "The inventory item with type name Custom:MyCustomInventoryType was sent with a disabled schema verison 1.0. You must send a version greater than 1.0",
"type-name": "Custom:MyCustomInventoryType"
}
}
```
이러한 이벤트를 모니터링하도록 EventBridge 구성하는 방법에 대한 자세한 내용은 [Systems Manager 이벤트에 대해 EventBridge 구성](monitoring-systems-manager-events.md) 섹션을 참조하세요.
# 인벤토리 수집 구성
이 섹션에서는 Systems Manager 콘솔을 사용하여 관리형 노드 1개 이상에 대한 AWS Systems Manager Inventory 수집을 구성하는 방법에 대해서 설명합니다. AWS Command Line Interface(AWS CLI)를 사용하여 인벤토리 수집을 구성하는 방법의 예는 [AWS CLI를 사용하여 인벤토리 데이터 수집 구성](inventory-collection-cli.md) 섹션을 참조하세요.
인벤토리 수집을 구성할 때 AWS Systems Manager State Manager 연결을 생성하는 것으로 시작합니다. Systems Manager는 연결이 실행될 때 인벤토리 데이터를 수집합니다. 연결을 먼저 생성하지 않고 AWS Systems Manager Run Command 등을 사용하여 `aws:softwareInventory` 플러그 인을 호출하려고 하면 시스템이 다음 오류를 반환합니다. `The aws:softwareInventory plugin can only be invoked via ssm-associate.`
**참고**
관리형 노드에 대해 여러 인벤토리 연결을 만드는 경우 다음 동작을 유의하세요.
각 노드에 *모든* 노드(--targets "Key=InstanceIds,Values=\$1")를 대상으로 하는 인벤토리 연결이 할당될 수 있습니다.
태그 키/값 페어 또는 AWS 리소스 그룹을 사용하는 특정 연결이 각 노드에 할당될 수도 있습니다.
노드에 여러 인벤토리 연결이 할당된 경우 실행되지 않은 연결에 대해 상태가 *건너뜀(Skipped)*으로 표시됩니다. 가장 최근에 실행된 연결은 인벤토리 연결의 실제 상태를 표시합니다.
노드에 여러 인벤토리 연결이 할당되고 각각 태그 키/값 페어를 사용하는 경우 태그 충돌로 인해 해당 인벤토리 연결이 노드에서 실행되지 않습니다. 태그 키/값 충돌이 없는 노드에서 연결이 계속 실행됩니다.
**시작하기 전**
인벤토리 수집을 구성하기 전에 다음 작업을 수행하세요.
+ 인벤토리로 만들고 싶은 노드에서 AWS Systems Manager SSM Agent를 업데이트합니다. SSM Agent 최신 버전을 실행하여 지원되는 모든 인벤토리 유형에 대한 메타데이터를 수집할 수 있는지 확인합니다. SSM Agent를 사용해 State Manager 를 업데이트하는 방법에 대한 자세한 내용은 [연습: AWS CLI를 사용하여 SSM Agent를 자동으로 업데이트](state-manager-update-ssm-agent-cli.md) 섹션을 참조하세요.
+ [하이브리드 및 멀티클라우드](operating-systems-and-machine-types.md#supported-machine-types) 환경의 Amazon Elastic Compute Cloud(Amazon EC2) 인스턴스 및 비 EC2 시스템에 대한 설정 요구 사항을 완료했는지 확인합니다. 자세한 내용은 [AWS Systems Manager에 대한 관리형 노드 설정](systems-manager-setting-up-nodes.md) 섹션을 참조하세요.
+ Microsoft Windows Server 노드의 경우 노드가 Windows PowerShell 3.0 이상으로 구성되었는지 확인합니다. SSM Agent는 PowerShell에서 `ConvertTo-Json` cmdlet을 사용하여 Windows 업데이트 인벤토리 데이터를 필요한 형식으로 변환합니다.
+ (옵션) 리소스 데이터 동기화를 생성하여 Amazon S3 버킷에 인벤토리 데이터를 중앙 집중식으로 저장합니다. 그러면 새 인벤토리 데이터가 수집될 때 리소스 데이터 동기화에 의해 중앙 데이터가 자동으로 업데이트됩니다. 자세한 내용은 [연습: 리소스 데이터 동기화를 사용하여 인벤토리 데이터 집계](inventory-resource-data-sync.md) 섹션을 참조하세요.
+ (선택 사항) JSON 파일을 생성하여 사용자 정의 인벤토리를 수집합니다. 자세한 내용은 [사용자 정의 인벤토리 작업](inventory-custom.md) 섹션을 참조하세요.
## AWS 계정의 모든 관리형 노드에 대한 인벤토리 작성
전역 인벤토리 연결을 생성하면 AWS 계정의 모든 관리형 노드에 대한 인벤토리를 쉽게 작성할 수 있습니다. 전역 인벤토리 연결은 다음 작업을 수행합니다.
+ AWS 계정에 있는 모든 관리형 노드에 전역 인벤토리 구성(연결)을 자동으로 적용합니다. 전역 인벤토리 연결이 적용되어 실행될 경우, 이미 인벤토리 연결이 있는 관리형 노드는 건너뜁니다. 노드를 건너뛰면 `Overridden By Explicit Inventory Association`이라는 자세한 상태 메시지가 표시됩니다. 이러한 노드는 전역 연결에서 건너뛰지만 각자 할당된 인벤토리 연결을 실행할 때는 인벤토리를 보고합니다.
+ AWS 계정에 생성된 새로운 노드를 전역 인벤토리 연결에 자동으로 추가합니다.
**참고**
전역 인벤토리 연결을 구성한 관리형 노드에 특정 연결을 할당하면 Systems Manager Inventory에서 전역 연결의 우선순위를 무시하고 특정 연결을 적용합니다.
전역 인벤토리 연결은 SSM Agent 버전 2.0.790.0 이상에서 사용할 수 있습니다. 노드에서 SSM Agent를 업데이트하는 자세한 방법은 [Run Command를 사용하여 SSM Agent 업데이트](run-command-tutorial-update-software.md#rc-console-agentexample) 섹션을 참조하세요.
### 원클릭 절차로 인벤토리 수집 구성(콘솔)
다음 절차에 따라 AWS 계정 및 단일 AWS 리전의 모든 관리형 노드에 대해 Systems Manager Inventory를 구성합니다.
**Systems Manager Inventory의 현재 리전에서 모든 관리형 노드 구성**
1. [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)에서 AWS Systems Manager 콘솔을 엽니다.
1. 탐색 창에서 [**Inventory**]를 선택합니다.
1. **Managed instances with inventory enabled(인벤토리가 활성화된 관리형 인스턴스)** 카드에서 **Click here to enable inventory on all instances(모든 인스턴스에서 인벤토리를 활성화하려면 여기를 클릭)**를 선택합니다.
![\[모든 관리형 노드에서 Systems Manager Inventory를 활성화하는 중입니다.\]](http://docs.aws.amazon.com/ko_kr/systems-manager/latest/userguide/images/inventory-one-click-1.png)
성공하면 콘솔에 다음 메시지가 표시됩니다.
![\[모든 관리형 노드에서 Systems Manager Inventory를 활성화하는 중입니다.\]](http://docs.aws.amazon.com/ko_kr/systems-manager/latest/userguide/images/inventory-one-click-2.png)
계정에 포함된 관리형 노드 수에 따라 전역 인벤토리 연결이 적용되는 데 몇 분이 걸릴 수 있습니다. 몇 분 동안 기다린 다음 페이지를 새로 고칩니다. 그래픽이 바뀌어 모든 관리형 노드에서 인벤토리가 구성된 것으로 나타내는지 확인합니다.
### 콘솔을 사용하여 수집 구성
이 섹션에는 Systems Manager 콘솔을 사용하여 관리형 노드에서 메타데이터를 수집하도록 Systems Manager Inventory를 구성하는 방법이 나와 있습니다. 특정 AWS 계정의 모든 노드(및 그 계정에서 만들 수 있는 향후의 모든 노드)에서 빠르게 메타데이터를 수집하거나 태그 또는 노드 ID를 사용하여 선택적으로 인벤토리 데이터를 수집할 수 있습니다.
**참고**
이 절차를 완료하기 전에 전역 인벤토리 연결이 이미 존재하는지 확인합니다. 전역 인벤토리 연결이 이미 존재하는 경우 새 인스턴스를 시작할 때마다 연결이 해당 인스턴스에 적용되고 새 인스턴스가 인벤토리에 추가됩니다.
**인벤토리 수집을 구성하려면**
1. [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)에서 AWS Systems Manager 콘솔을 엽니다.
1. 탐색 창에서 [**Inventory**]를 선택합니다.
1. **인벤토리 설정**을 선택합니다.
1. **대상** 섹션에서, 다음 중 하나를 선택하여 이 작업을 실행할 노드를 식별합니다.
+ **이 계정의 모든 관리형 인스턴스 선택** - 이 옵션은 인벤토리 연결이 존재하지 않는 모든 관리형 노드를 선택합니다. 이 옵션을 선택하면 인벤토리 연결이 이미 있는 노드들이 인벤토리 수집에서 무시되고, 인벤토리 결과에 **건너뜀** 상태로 표시됩니다. 자세한 내용은 [AWS 계정의 모든 관리형 노드에 대한 인벤토리 작성](#inventory-management-inventory-all) 섹션을 참조하세요.
+ **태그 지정(Specifying a tag)** - 태그 하나를 지정하여 계정에서 인벤토리를 수집할 노드를 식별하려면 이 옵션을 사용합니다. 태그를 사용하는 경우 그 이후로 이와 동일한 태그를 사용하여 생성되는 노드도 인벤토리를 보고합니다. 모든 노드와 연결된 인벤토리 연결이 존재하는 경우, 태그를 사용하여 특정 노드를 여러 인벤토리에 대한 대상으로 선택하면 **모든 관리형 인스턴스** 대상 그룹의 노드 멤버십을 무시합니다. 지정한 태그를 가진 관리형 노드는 이후에 수행되는 **모든 관리형 인스턴스**의 인벤토리 수집에서 무시됩니다.
+ **수동으로 인스턴스 선택(Manually selecting instances)** - 계정에서 특정 관리형 노드를 선택하려면 이 옵션을 사용합니다. 이 옵션을 사용하여 특정 노드를 명시적으로 선택하면 **모든 관리형 인스턴스** 대상의 인벤토리 연결을 무시합니다. 노드는 이후에 수행되는 **모든 관리형 인스턴스**의 인벤토리 수집에서 무시됩니다.
**참고**
예상한 관리형 노드가 목록에 없으면 [관리형 노드 가용성 문제 해결](fleet-manager-troubleshooting-managed-nodes.md)에서 문제 해결 팁을 참조하세요.
1. **일정** 섹션에서 시스템이 노드로부터 인벤토리 메타데이터를 수집하는 간격을 선택합니다.
1. [**파라미터(Parameters)**] 섹션에서 목록을 사용하여 다양한 유형의 인벤토리 수집을 설정하거나 해제합니다. 파일 및 Windows 레지스트리 인벤토리를 수집하는 방법에 대한 자세한 내용은 [파일 및 Windows 레지스트리 인벤토리 관련 작업](inventory-file-and-registry.md) 섹션을 참조하세요.
1. Amazon S3 버킷에 연결 실행 상태를 저장하고 싶으면 [**고급(Advanced)**] 섹션에서 [**인벤토리 실행 로그를 Amazon S3 버킷에 동기화(Sync inventory execution logs to an Amazon S3 bucket)**]를 선택합니다.
1. **인벤토리 설정**을 선택합니다. Systems Manager가 State Manager 연결을 생성하고 노드에 대해 Inventory를 즉시 실행합니다.
1. 탐색 창에서 **State Manager**를 선택합니다. `AWS-GatherSoftwareInventory` 문서를 사용하는 새로운 연결이 생성되었는지 확인합니다. 연결 일정표는 rate 표현식을 사용합니다. 또한 **상태** 필드에 **성공**이 표시되는지 확인합니다. [**Amazon S3 버킷으로 인벤토리 실행 로그 동기화(Sync inventory execution logs to an Amazon S3 bucket)**] 옵션을 선택하는 경우 몇 분 후 Amazon S3에서 로그 데이터를 볼 수 있습니다. 특정 노드에 대한 인벤토리 데이터를 보려는 경우 탐색 창에서 **관리형 인스턴스**를 선택합니다.
1. 노드를 선택한 후 **세부 정보 보기(View detail)**를 선택합니다.
1. 노드 세부 정보 페이지에서 **인벤토리(Inventory)**를 선택합니다. **인벤토리 유형** 목록을 사용하여 인벤토리를 필터링합니다.
# 여러 리전 및 계정에서 인벤토리 데이터 쿼리
AWS Systems Manager Inventory가 Amazon Athena와 통합되어 여러 AWS 리전 및 AWS 계정에서 인벤터리 데이터를 쿼리하는 데 도움이 됩니다. Athena 통합은 리소스 데이터 동기화를 사용하므로 AWS Systems Manager 콘솔의 **세부 정보 보기** 페이지에서 모든 관리형 노드의 인벤토리 데이터를 볼 수 있습니다.
**중요**
이 기능은 AWS Glue를 사용하여 Amazon Simple Storage Service(Amazon S3) 버킷의 데이터를 크롤링하고 Amazon Athena를 사용하여 데이터를 쿼리합니다. 탐색하는 데이터의 양에 다라 이러한 서비스 사용에 대한 비용이 청구될 수 있습니다. AWS Glue는 시간당 요금제이며, 크롤러(데이터 검색) 및 ETL 작업(데이터 처리 및 로드)의 경우 초 단위로 비용이 청구됩니다. Athena에서는 각 쿼리가 검사한 데이터의 양을 기준으로 요금이 청구됩니다. Systems Manager Inventory와 Amazon Athena의 통합을 사용하기 전에 이러한 서비스에 대한 요금 자침을 확인하는 것이 좋습니다. 자세한 내용은 [Amazon Athena 요금](https://aws.amazon.com/athena/pricing/) 및 [AWS Glue 요금](https://aws.amazon.com/glue/pricing/)을 참조하세요.
Amazon Athena를 사용할 수 있는 모든 AWS 리전의 **세부 정보 보기(Detailed View)** 페이지에서 인벤토리 데이터를 볼 수 있습니다. 지원되는 리전 목록은 **Amazon Web Services 일반 참조의 [Amazon Athena 서비스 엔드포인트](https://docs.aws.amazon.com/general/latest/gr/athena.html#athena_region)를 참조하세요.
**시작하기 전 준비 사항**
Athena 통합은 리소스 데이터 동기화를 사용합니다. 이 기능을 사용하려면 리소스 데이터 동기화를 설정 및 구성해야 합니다. 자세한 내용은 [연습: 리소스 데이터 동기화를 사용하여 인벤토리 데이터 집계](inventory-resource-data-sync.md) 섹션을 참조하세요.
또한 **세부 정보 보기(Detailed View)** 페이지에 리소스 데이터 동기화에서 사용하는 중앙 Amazon S3 버킷의 *소유자*에 대한 인벤토리 데이터가 표시됩니다. 중앙 Amazon S3 버킷의 소유자가 아닌 경우에는 **세부 정보 보기(Detailed View)** 페이지에서 인벤토리 데이터가 표시되지 않습니다.
## 액세스 구성
Systems Manager 콘솔의 **세부 정보 보기** 페이지에서 여러 계정 및 리전의 데이터를 쿼리하고 보려면 먼저 데이터를 볼 수 있는 권한이 있는 IAM 엔터티를 구성해야 합니다.
인벤토리 데이터가 AWS Key Management Service(AWS KMS) 암호화를 사용하는 Amazon S3 버킷에 저장된 경우 AWS KMS 암호화를 위해 IAM 엔터티와 `Amazon-GlueServiceRoleForSSM` 서비스 역할 또한 구성해야 합니다.
**Topics**
+ [세부 정보 보기 페이지에 액세스하도록 IAM 엔터티 구성](#systems-manager-inventory-query-iam-user)
+ [(선택 사항) AWS KMS 암호화 데이터를 볼 수 있는 권한 구성](#systems-manager-inventory-query-kms)
### 세부 정보 보기 페이지에 액세스하도록 IAM 엔터티 구성
다음은 **상세 보기** 페이지에서 인벤토리 데이터를 보는 데 필요한 최소 권한에 대한 설명입니다.
`AWSQuicksightAthenaAccess` 관리형 정책
다음 `PassRole` 및 추가 필수 권한 블록
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowGlue",
"Effect": "Allow",
"Action": [
"glue:GetCrawler",
"glue:GetCrawlers",
"glue:GetTables",
"glue:StartCrawler",
"glue:CreateCrawler"
],
"Resource": "*"
},
{
"Sid": "iamPassRole",
"Effect": "Allow",
"Action": "iam:PassRole",
"Resource": [
"arn:aws:iam::111122223333:role/SSMInventoryGlueRole",
"arn:aws:iam::111122223333:role/SSMInventoryServiceRole"
],
"Condition": {
"StringEquals": {
"iam:PassedToService": "glue.amazonaws.com"
}
}
},
{
"Sid": "iamRoleCreation",
"Effect": "Allow",
"Action": [
"iam:CreateRole",
"iam:AttachRolePolicy"
],
"Resource": "arn:aws:iam::111122223333:role/*"
},
{
"Sid": "iamPolicyCreation",
"Effect": "Allow",
"Action": "iam:CreatePolicy",
"Resource": "arn:aws:iam::111122223333:policy/*"
}
]
}
```
------
(선택 사항) 인벤토리 데이터를 저장하는 데 사용되는 Amazon S3 버킷이 AWS KMS를 사용하여 암호화된 경우 다음 블록도 정책에 추가해야 합니다.
```
{
"Effect": "Allow",
"Action": [
"kms:Decrypt"
],
"Resource": [
"arn:aws:kms:Region:account_ID:key/key_ARN"
]
}
```
액세스 권한을 제공하려면 사용자, 그룹 또는 역할에 권한을 추가하세요.
+ AWS IAM Identity Center의 사용자 및 그룹:
권한 세트를 생성합니다. *AWS IAM Identity Center 사용자 안내서*에서 [권한 세트 생성](https://docs.aws.amazon.com//singlesignon/latest/userguide/howtocreatepermissionset.html)의 지침을 따릅니다.
+ ID 제공업체를 통해 IAM에서 관리되는 사용자:
ID 페더레이션을 위한 역할을 생성합니다. *IAM 사용자 설명서*의 [Create a role for a third-party identity provider (federation)](https://docs.aws.amazon.com//IAM/latest/UserGuide/id_roles_create_for-idp.html)의 지침을 따릅니다.
+ IAM 사용자:
+ 사용자가 맡을 수 있는 역할을 생성합니다. *IAM 사용자 설명서*에서 [Create a role for an IAM user](https://docs.aws.amazon.com//IAM/latest/UserGuide/id_roles_create_for-user.html)의 지침을 따릅니다.
+ (권장되지 않음) 정책을 사용자에게 직접 연결하거나 사용자를 사용자 그룹에 추가합니다. *IAM 사용 설명서*에서 [사용자(콘솔)에 권한 추가](https://docs.aws.amazon.com//IAM/latest/UserGuide/id_users_change-permissions.html#users_change_permissions-add-console)의 지침을 따릅니다.
### (선택 사항) AWS KMS 암호화 데이터를 볼 수 있는 권한 구성
인벤토리 데이터를 저장하는 데 사용되는 Amazon S3 버킷이 AWS Key Management Service(AWS KMS)를 사용하여 암호화된 경우, AWS KMS 키에 대한 `kms:Decrypt` 권한으로 IAM 엔터티 및 **Amazon-GlueServiceRoleForSSM** 역할을 구성해야 합니다.
**시작하기 전 준비 사항**
AWS KMS 키에 대한 `kms:Decrypt` 권한을 제공하려면 IAM 엔터티에 다음 정책 블록을 추가합니다.
```
{
"Effect": "Allow",
"Action": [
"kms:Decrypt"
],
"Resource": [
"arn:aws:kms:Region:account_ID:key/key_ARN"
]
}
```
아직 수행하지 않은 경우 해당 절차를 완료하고 AWS KMS 키에 대해 `kms:Decrypt` 권한을 추가합니다.
다음 절차에 따라 AWS KMS 키에 대한 `kms:Decrypt` 권한으로 **Amazon-GlueServiceRoleForSSM** 역할을 구성합니다.
**`kms:Decrypt` 권한을 가진 **Amazon-GlueServiceRoleForSSM** 역할을 구성하려면**
1. IAM 콘솔([https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/))을 엽니다.
1. 탐색 창에서 **역할(Roles)**을 선택한 다음 검색 필드를 사용하여 **Amazon-GlueServiceRoleForSSM** 역할을 찾습니다. **요약** 페이지가 열립니다.
1. 검색 필드를 사용하여 **Amazon-GlueServiceRoleForSSM** 역할을 찾습니다. 역할 이름을 선택합니다. **요약** 페이지가 열립니다.
1. 역할 이름을 선택합니다. **요약** 페이지가 열립니다.
1. **인라인 정책 추가**를 선택합니다. **정책 생성** 페이지가 열립니다.
1. **JSON** 탭을 선택합니다.
1. 편집기에서 기존 JSON 텍스트를 삭제하고 다음 정책을 복사한 다음 JSON 편집기에 붙여 넣습니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"kms:Decrypt"
],
"Resource": [
"arn:aws:kms:us-east-1:111122223333:key/key_ARN"
]
}
]
}
```
------
1. [**정책 검토(Review policy)**]를 선택합니다.
1. **정책 검토** 페이지에서 **이름** 필드에 이름을 입력합니다.
1. **정책 생성**을 선택합니다.
## 인벤토리 세부 정보 보기(Inventory Detail View) 페이지에서 데이터 쿼리
다음 절차에 따라 Systems Manager Inventory [**세부 정보 뷰(Detailed View)**] 페이지에서 여러 AWS 리전과 AWS 계정의 인벤토리 데이터를 봅니다.
**중요**
Inventory [**세부 정보 뷰(Detailed View)**] 페이지는 Amazon Athena를 제공하는 AWS 리전에서만 사용할 수 있습니다. 다음 탭이 Systems Manager Inventory 페이지에 표시되지 않는 경우 Athena는 리전에서 사용할 수 없으며 **세부 정보 보기(Detailed View)**를 사용하여 데이터를 쿼리할 수 없습니다.
![\[인벤토리 대시보드 | 세부 정보 보기 | 설정 탭 표시\]](http://docs.aws.amazon.com/ko_kr/systems-manager/latest/userguide/images/inventory-detailed-view-for-error.png)
**AWS Systems Manager 콘솔에서 여러 리전과 계정의 인벤토리 데이터를 보려면**
1. [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)에서 AWS Systems Manager 콘솔을 엽니다.
1. 탐색 창에서 [**Inventory**]를 선택합니다.
1. **세부 정보 보기(Detailed View)** 탭을 선택합니다.
![\[AWS Systems Manager 인벤토리 세부 정보 보기 페이지에 액세스\]](http://docs.aws.amazon.com/ko_kr/systems-manager/latest/userguide/images/inventory-detailed-view.png)
1. 데이터를 쿼리할 리소스 데이터 동기화를 선택합니다.
![\[AWS Systems Manager 콘솔에서 인벤토리 데이터 표시\]](http://docs.aws.amazon.com/ko_kr/systems-manager/latest/userguide/images/inventory-display-data.png)
1. **인벤토리 유형** 목록에서 쿼리하려는 인벤토리 데이터의 유형을 선택한 후 Enter를 누릅니다.
![\[AWS Systems Manager 콘솔에서 인벤토리 유형 선택\]](http://docs.aws.amazon.com/ko_kr/systems-manager/latest/userguide/images/inventory-type.png)
1. 데이터를 필터링하려면 필터 막대를 선택한 후 필터 옵션을 선택합니다.
![\[AWS Systems Manager 콘솔에서 인벤토리 데이터 필터링\]](http://docs.aws.amazon.com/ko_kr/systems-manager/latest/userguide/images/inventory-filter.png)
**CSV로 내보내기** 버튼을 사용해 현재 쿼리 세트를 Microsoft Excel 등과 같은 스프레드시트 애플리케이션에서 볼 수 있습니다. [**쿼리 기록(Query History)**] 및 [**고급 쿼리 실행(Run Advanced Queries)**] 버튼을 사용해 Amazon Athena에서 기록 세부 정보를 보고 데이터와 상호 작용할 수도 있습니다.
### AWS Glue 크롤러 예약 편집
AWS Glue는 기본적으로 중앙 Amazon S3 버킷에서 매일 두 번씩 인벤토리 데이터를 크롤링합니다. 노드에서 수집하는 데이터 유형을 자주 변경하는 경우 다음 절차의 설명에 따라 데이터를 더욱 자주 탐색할 수 있습니다.
**중요**
AWS Glue는 AWS 계정에 시간당 요금을 부과하며, 크롤러(데이터 검색) 및 ETL 작업(데이터 처리 및 로드)의 경우 초 단위로 비용이 청구됩니다. 크롤러 일정을 변경하기 전에 [AWS Glue 요금](https://aws.amazon.com/glue/pricing/) 페이지를 확인하세요.
**인벤토리 데이터 크롤러 일정을 변경하려면**
1. [https://console.aws.amazon.com/glue/](https://console.aws.amazon.com/glue/)에서 AWS Glue 콘솔을 엽니다.
1. 탐색 창에서 **크롤러**를 선택합니다.
1. 크롤러 목록에서 Systems Manager Inventory 데이터 크롤러 옆의 옵션을 선택합니다. 크롤러 이름의 형식은 다음과 같습니다.
`AWSSystemsManager-s3-bucket-name-Region-account_ID`
1. **작업**을 선택한 후 **크롤러 편집**을 선택합니다.
1. 탐색 창에서 **일정**을 선택합니다.
1. **Cron 표현식** 필드에서 cron 형식을 사용하여 새 일정을 지정합니다. cron 형식에 대한 자세한 내용은 *AWS Glue 개발자 안내서*의 [크롤러와 작업을 위한 시간 기반 일정](https://docs.aws.amazon.com/glue/latest/dg/monitor-data-warehouse-schedule.html)을 참조하세요.
**중요**
AWS Glue에서 더 이상 요금이 발생하지 않도록 크롤러를 일시 중지할 수 있습니다. 크롤러를 일시 중지하거나 데이터 크롤링 횟수를 줄이도록 빈도를 변경하면 인벤토리 [**세부 정보 뷰(Detailed View)**]에 최신이 아닌 데이터가 표시될 수 있습니다.
# 필터를 사용하여 인벤토리 수집 쿼리
인벤토리 데이터를 수집했으면 AWS Systems Manager의 필터 기능을 사용하여 특정 필터 조건에 맞는 관리형 노드 목록을 쿼리할 수 있습니다.
**인벤토리 필터를 기반으로 노드 쿼리**
1. [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)에서 AWS Systems Manager 콘솔을 엽니다.
1. 탐색 창에서 [**Inventory**]를 선택합니다.
1. **Filter by resource groups, tags or inventory types(리소스 그룹, 태그 또는 인벤토리 유형별로 필터링)** 섹션에서 필터 상자를 선택합니다. 미리 정의된 필터의 목록이 표시됩니다.
1. 필터를 적용할 속성을 선택합니다. 이 예에서는 [`AWS:Application`]을 선택합니다. 메시지가 나타나면 필터를 적용할 두 번째 속성을 선택합니다. 이 예에서는 [`AWS:Application.Name`]을 선택합니다.
1. 목록에서 구분 기호를 선택합니다. 예를 들어 **Begin with(다음으로 시작)**를 선택합니다. 필터에 텍스트 상자가 표시됩니다.
1. 텍스트 상자에 값을 입력합니다. 예를 들어 *Amazon*을 입력합니다(SSM Agent의 이름은 *Amazon SSM Agent*로 지정됨).
1. Enter을 누릅니다. *Amazon*이라는 단어로 시작하는 애플리케이션 이름이 들어 있는 관리형 노드 목록이 반환됩니다.
**참고**
여러 필터를 결합하여 검색 범위를 좁힐 수 있습니다.
# 인벤토리 데이터 집계
AWS Systems Manager 인벤토리용 관리형 노드를 구성한 뒤에는 집계된 인벤토리 데이터 수를 볼 수 있습니다. 예를 들어 `AWS:Application` 인벤토리 유형을 수집하기 위해 관리형 노드를 수십, 수백 개 정도 구성했다고 가정하겠습니다. 그 경우 이 섹션의 정보를 이용하여 이 데이터를 수집하도록 구성된 노드가 몇 개인지 정확한 수를 알아볼 수 있습니다.
데이터 유형으로 집계하여 특정한 인벤토리 세부 정보를 확인할 수도 있습니다. 예를 들어 `AWS:InstanceInformation` 인벤토리 유형은 `Platform` 데이터 형식의 운영 체제 플랫폼 정보를 수집합니다. `Platform` 데이터 형식으로 데이터를 집계함으로써 Windows, Linux, Windows Server 및 macOS를 실행하는 노드가 각각 몇 개인지 빠르게 파악할 수 있습니다.
이 섹션의 절차에서는 AWS Command Line Interface(AWS CLI)를 사용하여 집계된 인벤토리 데이터 수를 보는 방법을 설명합니다. AWS Systems Manager 콘솔의 **인벤토리** 페이지에서 사전 구성된 집계 개수를 볼 수도 있습니다. 이렇게 사전 구성된 대시보드를 *인벤토리 인사이트*라고 부르며, 이를 통해 인벤토리 구성 문제를 클릭 한 번으로 해결할 수 있습니다.
다음은 인벤토리 데이터 집계 개수에 관한 중요한 세부 정보입니다.
+ 인벤토리 데이터를 수집하도록 구성된 관리형 노드를 종료하면 Systems Manager는 인벤토리 데이터를 30일 동안 보관한 다음 삭제합니다. 실행 노드의 경우 30일이 경과한 인벤토리 데이터가 삭제됩니다. 인벤토리 데이터를 30일 이상 저장해야 하는 경우 AWS Config를 사용하여 이력을 기록하거나 정기적으로 데이터를 쿼리하여 Amazon Simple Storage Service(Amazon S3) 버킷에 업로드하면 됩니다.
+ 노드가 이전에 `AWS:Network`와 같이 특정한 인벤토리 데이터 형식을 보고하도록 구성된 경우 나중에 구성을 변경하여 해당 유형의 수집을 중지하도록 하더라도, 해당 노드를 종료하고 30일이 지날 때까지 집계 개수에는 여전히 `AWS:Network` 데이터가 표시됩니다.
특정 AWS 계정의 모든 노드(및 그 계정에서 만들 수 있는 향후의 모든 노드)에서 인벤토리 데이터를 빠르게 구성하고 수집하는 방법에 대한 자세한 내용은 [AWS 계정의 모든 관리형 노드에 대한 인벤토리 작성](inventory-collection.md#inventory-management-inventory-all) 섹션을 참조하세요.
**Topics**
+ [인벤토리 데이터를 집계하여 지정된 유형의 데이터를 수집하는 노드 개수를 확인](#inventory-aggregate-type)
+ [인벤토리 유형을 수집하도록 구성된 노드와 그렇지 않은 노드를 파악하기 위해 인벤토리 데이터를 그룹으로 집계](#inventory-aggregate-groups)
## 인벤토리 데이터를 집계하여 지정된 유형의 데이터를 수집하는 노드 개수를 확인
AWS Systems Manager [GetInventory](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_GetInventory.html) API 작업을 사용하여 하나 이상의 Inventory 유형 및 데이터 형식을 수집하는 노드의 집계 개수를 볼 수 있습니다. 예를 들어 `AWS:InstanceInformation` Inventory 유형을 사용하면 `AWS:InstanceInformation.PlatformType` 데이터 형식과 함께 GetInventory API 작업을 사용하여 운영 체제의 집계를 볼 수 있습니다. 다음은 예 AWS CLI 명령과 출력입니다.
```
aws ssm get-inventory --aggregators "Expression=AWS:InstanceInformation.PlatformType"
```
시스템은 다음과 같은 정보를 반환합니다.
```
{
"Entities":[
{
"Data":{
"AWS:InstanceInformation":{
"Content":[
{
"Count":"7",
"PlatformType":"windows"
},
{
"Count":"5",
"PlatformType":"linux"
}
]
}
}
}
]
}
```
**시작하기**
개수를 보려는 인벤토리 유형과 데이터 유형을 결정합니다. AWS CLI에서 다음 명령을 실행하여 집계가 지원되는 인벤토리 유형 및 데이터 유형의 목록을 볼 수 있습니다.
```
aws ssm get-inventory-schema --aggregator
```
이 명령은 집계가 지원되는 인벤토리 유형 및 데이터 유형의 JSON 목록을 반환합니다. **TypeName** 필드에는 지원되는 인벤토리 유형이 표시됩니다. 그리고 **Name** 필드에는 데이터 유형이 각각 표시됩니다. 예를 들어 아래의 목록에서 `AWS:Application` 인벤토리 유형에는 `Name` 및 `Version` 데이터 형식이 포함됩니다.
```
{
"Schemas": [
{
"TypeName": "AWS:Application",
"Version": "1.1",
"DisplayName": "Application",
"Attributes": [
{
"DataType": "STRING",
"Name": "Name"
},
{
"DataType": "STRING",
"Name": "Version"
}
]
},
{
"TypeName": "AWS:InstanceInformation",
"Version": "1.0",
"DisplayName": "Platform",
"Attributes": [
{
"DataType": "STRING",
"Name": "PlatformName"
},
{
"DataType": "STRING",
"Name": "PlatformType"
},
{
"DataType": "STRING",
"Name": "PlatformVersion"
}
]
},
{
"TypeName": "AWS:ResourceGroup",
"Version": "1.0",
"DisplayName": "ResourceGroup",
"Attributes": [
{
"DataType": "STRING",
"Name": "Name"
}
]
},
{
"TypeName": "AWS:Service",
"Version": "1.0",
"DisplayName": "Service",
"Attributes": [
{
"DataType": "STRING",
"Name": "Name"
},
{
"DataType": "STRING",
"Name": "DisplayName"
},
{
"DataType": "STRING",
"Name": "ServiceType"
},
{
"DataType": "STRING",
"Name": "Status"
},
{
"DataType": "STRING",
"Name": "StartType"
}
]
},
{
"TypeName": "AWS:WindowsRole",
"Version": "1.0",
"DisplayName": "WindowsRole",
"Attributes": [
{
"DataType": "STRING",
"Name": "Name"
},
{
"DataType": "STRING",
"Name": "DisplayName"
},
{
"DataType": "STRING",
"Name": "FeatureType"
},
{
"DataType": "STRING",
"Name": "Installed"
}
]
}
]
}
```
다음 구문을 사용하는 명령을 만들어 목록의 인벤토리 유형에 대한 데이터를 집계할 수 있습니다.
```
aws ssm get-inventory --aggregators "Expression=InventoryType.DataType"
```
여기 몇 가지 예가 있습니다.
**예제 1**.
이 예에서는 해당 노드에서 사용하는 Windows 역할 개수를 집계합니다.
```
aws ssm get-inventory --aggregators "Expression=AWS:WindowsRole.Name"
```
**예제 2**.
이 예에서는 해당 노드에 설치된 애플리케이션 개수를 집계합니다.
```
aws ssm get-inventory --aggregators "Expression=AWS:Application.Name"
```
**여러 집계자 결합**
명령 하나에 여러 가지 인벤토리 유형과 데이터 유형을 결합하면 데이터를 더 잘 이해할 수 있습니다. 여기 몇 가지 예가 있습니다.
**예제 1**.
이 예에서는 해당 노드에서 사용하는 운영 체제 유형의 개수를 집계합니다. 또한 운영 체제의 구체적인 이름도 반환합니다.
```
aws ssm get-inventory --aggregators '[{"Expression": "AWS:InstanceInformation.PlatformType", "Aggregators":[{"Expression": "AWS:InstanceInformation.PlatformName"}]}]'
```
**예제 2**.
이 예에서는 해당 노드에서 실행 중인 애플리케이션 개수와 각 애플리케이션의 특정 버전을 집계합니다.
```
aws ssm get-inventory --aggregators '[{"Expression": "AWS:Application.Name", "Aggregators":[{"Expression": "AWS:Application.Version"}]}]'
```
원한다면 하나 이상의 인벤토리 유형과 데이터 유형으로 된 집계 표현식을 JSON 파일로 만들고 AWS CLI에서 그 파일을 호출할 수 있습니다. 이 파일의 JSON은 다음 구문을 사용해야 합니다.
```
[
{
"Expression": "string",
"Aggregators": [
{
"Expression": "string"
}
]
}
]
```
.json 파일 확장자로 파일을 저장해야 합니다.
다음은 여러 가지 인벤토리 유형과 데이터 유형을 사용하는 예제입니다.
```
[
{
"Expression": "AWS:Application.Name",
"Aggregators": [
{
"Expression": "AWS:Application.Version",
"Aggregators": [
{
"Expression": "AWS:InstanceInformation.PlatformType"
}
]
}
]
}
]
```
다음 명령을 사용하여 AWS CLI에서 해당 파일을 호출합니다.
```
aws ssm get-inventory --aggregators file://file_name.json
```
명령은 다음과 같은 정보를 반환합니다.
```
{"Entities":
[
{"Data":
{"AWS:Application":
{"Content":
[
{"Count": "3",
"PlatformType": "linux",
"Version": "2.6.5",
"Name": "audit-libs"},
{"Count": "2",
"PlatformType": "windows",
"Version": "2.6.5",
"Name": "audit-libs"},
{"Count": "4",
"PlatformType": "windows",
"Version": "6.2.8",
"Name": "microsoft office"},
{"Count": "2",
"PlatformType": "windows",
"Version": "2.6.5",
"Name": "chrome"},
{"Count": "1",
"PlatformType": "linux",
"Version": "2.6.5",
"Name": "chrome"},
{"Count": "2",
"PlatformType": "linux",
"Version": "6.3",
"Name": "authconfig"}
]
}
},
"ResourceType": "ManagedInstance"}
]
}
```
## 인벤토리 유형을 수집하도록 구성된 노드와 그렇지 않은 노드를 파악하기 위해 인벤토리 데이터를 그룹으로 집계
Systems Manager Inventory의 그룹으로 관리형 노드 중 하나 이상의 Inventory 유형을 수집하도록 구성된 인스턴스 수와 그렇지 않은 인스턴스 수를 빠르게 파악할 수 있습니다. 그룹을 통해 하나 이상의 인벤토리 유형과 `exists` 연산자를 사용하는 필터를 지정합니다.
예를 들어, 다음 인벤토리 유형을 수집하도록 구성한 관리형 노드가 4개 있다고 가정하겠습니다.
+ 노드 1: `AWS:Application`
+ 노드 2: `AWS:File`
+ 노드 3: `AWS:Application`, `AWS:File`
+ 노드 4: `AWS:Network`
AWS CLI에서 다음 명령을 실행하여 `AWS:Application`과 `AWS:File inventory` 인벤토리 유형을 둘 다 수집하도록 구성된 노드가 몇 개인지 확인할 수 있습니다. 응답에는 이러한 두 가지 인벤토리 유형을 모두 수집하도록 구성되지 않은 노드 개수도 반환됩니다.
```
aws ssm get-inventory --aggregators 'Groups=[{Name=ApplicationAndFile,Filters=[{Key=TypeName,Values=[AWS:Application],Type=Exists},{Key=TypeName,Values=[AWS:File],Type=Exists}]}]'
```
명령의 응답은 `AWS:Application` 및 `AWS:File` 인벤토리 유형을 둘 다 수집하도록 구성된 관리형 노드가 하나뿐임을 보여줍니다.
```
{
"Entities":[
{
"Data":{
"ApplicationAndFile":{
"Content":[
{
"notMatchingCount":"3"
},
{
"matchingCount":"1"
}
]
}
}
}
]
}
```
**참고**
그룹은 데이터 유형 개수를 반환하지 않습니다. 또한 결과를 심층 분석하여 인벤토리 유형을 수집하도록 구성된 노드와 그렇지 않은 노드 ID를 파악할 수도 없습니다.
원한다면 하나 이상의 인벤토리 유형으로 된 집계 표현식을 JSON 파일로 만들고 AWS CLI에서 그 파일을 호출할 수 있습니다. 이 파일의 JSON은 다음 구문을 사용해야 합니다.
```
{
"Aggregators":[
{
"Groups":[
{
"Name":"Name",
"Filters":[
{
"Key":"TypeName",
"Values":[
"Inventory_type"
],
"Type":"Exists"
},
{
"Key":"TypeName",
"Values":[
"Inventory_type"
],
"Type":"Exists"
}
]
}
]
}
]
}
```
.json 파일 확장자로 파일을 저장해야 합니다.
다음 명령을 사용하여 AWS CLI에서 해당 파일을 호출합니다.
```
aws ssm get-inventory --cli-input-json file://file_name.json
```
**추가 예제**
다음 예에서는 지정된 인벤토리 유형을 수집하도록 구성된 관리형 노드와 그렇지 않은 노드를 파악하기 위해 인벤토리 데이터를 집계하는 방법을 보여줍니다. 이 예제에서는 AWS CLI를 사용합니다. 각 예제에 전체 명령과 필터가 나와 있으므로 정보를 파일에 입력하는 방법을 선호한다면 명령줄에서 이 명령과 샘플 input.json 파일을 실행하면 됩니다.
**예제 1**.
이 예에서는 `AWS:Application` 또는 `AWS:File` 인벤토리 유형을 수집하도록 구성된 노드와 그렇지 않은 노드의 개수를 집계합니다.
AWS CLI에서 다음 명령을 실행합니다.
```
aws ssm get-inventory --aggregators 'Groups=[{Name=ApplicationORFile,Filters=[{Key=TypeName,Values=[AWS:Application, AWS:File],Type=Exists}]}]'
```
파일을 사용하려면 다음 샘플을 복사하여 파일에 붙여 넣은 다음 이 파일을 input.json으로 저장합니다.
```
{
"Aggregators":[
{
"Groups":[
{
"Name":"ApplicationORFile",
"Filters":[
{
"Key":"TypeName",
"Values":[
"AWS:Application",
"AWS:File"
],
"Type":"Exists"
}
]
}
]
}
]
}
```
AWS CLI에서 다음 명령을 실행합니다.
```
aws ssm get-inventory --cli-input-json file://input.json
```
명령은 다음과 같은 정보를 반환합니다.
```
{
"Entities":[
{
"Data":{
"ApplicationORFile":{
"Content":[
{
"notMatchingCount":"1"
},
{
"matchingCount":"3"
}
]
}
}
}
]
}
```
**예제 2**.
이 예에서는 `AWS:Application`, `AWS:File` 및 `AWS:Network` 인벤토리 유형을 수집하도록 구성된 노드와 그렇지 않은 노드의 개수를 집계합니다.
AWS CLI에서 다음 명령을 실행합니다.
```
aws ssm get-inventory --aggregators 'Groups=[{Name=Application,Filters=[{Key=TypeName,Values=[AWS:Application],Type=Exists}]}, {Name=File,Filters=[{Key=TypeName,Values=[AWS:File],Type=Exists}]}, {Name=Network,Filters=[{Key=TypeName,Values=[AWS:Network],Type=Exists}]}]'
```
파일을 사용하려면 다음 샘플을 복사하여 파일에 붙여 넣은 다음 이 파일을 input.json으로 저장합니다.
```
{
"Aggregators":[
{
"Groups":[
{
"Name":"Application",
"Filters":[
{
"Key":"TypeName",
"Values":[
"AWS:Application"
],
"Type":"Exists"
}
]
},
{
"Name":"File",
"Filters":[
{
"Key":"TypeName",
"Values":[
"AWS:File"
],
"Type":"Exists"
}
]
},
{
"Name":"Network",
"Filters":[
{
"Key":"TypeName",
"Values":[
"AWS:Network"
],
"Type":"Exists"
}
]
}
]
}
]
}
```
AWS CLI에서 다음 명령을 실행합니다.
```
aws ssm get-inventory --cli-input-json file://input.json
```
명령은 다음과 같은 정보를 반환합니다.
```
{
"Entities":[
{
"Data":{
"Application":{
"Content":[
{
"notMatchingCount":"2"
},
{
"matchingCount":"2"
}
]
},
"File":{
"Content":[
{
"notMatchingCount":"2"
},
{
"matchingCount":"2"
}
]
},
"Network":{
"Content":[
{
"notMatchingCount":"3"
},
{
"matchingCount":"1"
}
]
}
}
}
]
}
```
# 사용자 정의 인벤토리 작업
AWS Systems Manager Inventory *사용자 정의 인벤토리*를 생성하여 원하는 메타데이터를 노드에 할당할 수 있습니다. 예를 들어 데이터 센터에서 여러 랙에 다수의 서버를 설치하여 관리하고 있으며, 이 서버들은 Systems Manager 관리형 노드로 구성되었다고 가정하겠습니다. 현재는 서버 랙 위치에 대한 정보를 스프레드시트에 저장하고 있습니다. 하지만 사용자 정의 인벤토리를 사용하면 각 노드의 랙 위치를 노드에 대한 메타데이터로 지정할 수 있습니다. Systems Manager를 사용하여 인벤토리를 수집할 경우에는 메타데이터가 다른 인벤토리 메타데이터와 함께 수집됩니다. 그런 다음 [리소스 데이터 동기화](inventory-resource-data-sync.html)를 사용하여 모든 인벤토리 메타데이터를 중앙 Amazon S3 버킷으로 포팅하고 데이터를 쿼리할 수 있습니다.
**참고**
Systems Manager는 AWS 계정당 최대 20개의 사용자 정의 인벤토리 유형을 지원합니다.
노드에 사용자 정의 인벤토리를 할당하려면 [관리형 노드에 사용자 지정 인벤토리 메타데이터 할당](inventory-custom-metadata.md)에 설명된 대로 Systems Manager [PutInventory](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PutInventory.html) API 작업을 사용할 수 있습니다. 아니면, 사용자 정의 인벤토리 JSON 파일을 생성하여 노드에 업로드하는 방법이 있습니다. 이번 단원에서는 JSON 파일을 생성하는 방법에 대해서 설명합니다.
다음 예제 JSON 파일은 온프레미스 서버의 랙 정보를 지정하는 사용자 지정 인벤토리를 포함하고 있습니다. 이 예제는 `Content` 아래에 데이터를 설명하는 여러 항목을 포함하는 한 사용자 지정 인벤토리 데이터 형식(`"TypeName": "Custom:RackInformation"`)을 지정합니다.
```
{
"SchemaVersion": "1.0",
"TypeName": "Custom:RackInformation",
"Content": {
"Location": "US-EAST-02.CMH.RACK1",
"InstalledTime": "2016-01-01T01:01:01Z",
"vendor": "DELL",
"Zone" : "BJS12",
"TimeZone": "UTC-8"
}
}
```
다음 예제에 나온 것처럼 `Content` 섹션에 개별 항목을 지정할 수도 있습니다.
```
{
"SchemaVersion": "1.0",
"TypeName": "Custom:PuppetModuleInfo",
"Content": [{
"Name": "puppetlabs/aws",
"Version": "1.0"
},
{
"Name": "puppetlabs/dsc",
"Version": "2.0"
}
]
}
```
사용자 정의 인벤토리에 사용되는 JSON 스키마는 `SchemaVersion` `TypeName` 및 `Content` 섹션이 필요하지만 이 섹션의 정보를 정의할 수 있습니다.
```
{
"SchemaVersion": "user_defined",
"TypeName": "Custom:user_defined",
"Content": {
"user_defined_attribute1": "user_defined_value1",
"user_defined_attribute2": "user_defined_value2",
"user_defined_attribute3": "user_defined_value3",
"user_defined_attribute4": "user_defined_value4"
}
}
```
`TypeName` 값은 100자로 제한됩니다. 또한 `TypeName` 값은 대문자로 된 `Custom` 단어로 시작해야 합니다. 예를 들어 `Custom:PuppetModuleInfo`입니다. 따라서 이 예시(`CUSTOM:PuppetModuleInfo`, `custom:PuppetModuleInfo`)에서는 예외가 발생합니다.
`Content` 섹션에는 속성과 *data*가 포함됩니다. 이들 항목은 대/소문자를 구분하지 않습니다. 하지만 속성을 정의하는 경우에는(예: "`Vendor`": "DELL") 사용자 정의 인벤토리 파일에서 이 속성을 일관적으로 참조해야 합니다. 한 파일에서 "`Vendor`": "DELL"(`vendor`에서 대문자 “V” 사용)을 지정한 다음 다른 파일에서 "`vendor`": "DELL"(`vendor`에서 소문자 “v” 사용)을 지정하면 시스템이 오류 메시지를 반환합니다.
**참고**
파일을 `.json` 확장자로 저장해야 하며 정의한 인벤토리는 문자열 값으로만 구성되어야 합니다.
파일을 생성한 후에는 노드에 저장해야 합니다. 다음은 노드에서 사용자 정의 인벤토리 JSON 파일을 저장해야 하는 위치를 나타낸 표입니다.
****
| 운영 체제 | 경로 |
| --- | --- |
| Linux | /var/lib/amazon/ssm/*node-id*/inventory/custom |
| macOS | `/opt/aws/ssm/data/node-id/inventory/custom` |
| Windows Server | %SystemDrive%\$1ProgramData\$1Amazon\$1SSM\$1InstanceData\$1*node-id*\$1inventory\$1custom |
사용자 지정 인벤토리를 사용하는 방법의 예제는 [EC2 Systems Manager 사용자 지정 인벤토리 유형을 사용하여 플릿의 디스크 사용률 얻기](https://aws.amazon.com/blogs/mt/get-disk-utilization-of-your-fleet-using-ec2-systems-manager-custom-inventory-types/)를 참조하십시오.
## 사용자 지정 인벤토리 삭제
[DeleteInventory](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_DeleteInventory.html) API 작업을 사용하여 사용자 정의 Inventory 유형 및 해당 유형과 연결된 데이터를 삭제할 수 있습니다. AWS Command Line Interface(AWS CLI)를 사용하여 delete-inventory 명령을 호출함으로써 인벤토리 유형의 모든 데이터를 삭제합니다. `SchemaDeleteOption`과 함께 delete-inventory 명령을 호출하여 사용자 지정 인벤토리 유형을 삭제합니다.
**참고**
인벤토리 유형을 인벤토리 스키마라고도 합니다.
`SchemaDeleteOption` 파라미터에는 다음과 같은 옵션이 있습니다.
+ **DeleteSchema**: 이 옵션은 지정한 사용자 지정 유형 및 해당 유형과 연결된 모든 데이터를 삭제합니다. 원한다면 나중에 스키마를 다시 만들 수 있습니다.
+ [**DisableSchema**]: 이 옵션을 선택하면 시스템에서 현재 버전을 해제하고, 현재 버전에 대한 모든 데이터를 삭제하고, 해당 버전이 해제된 버전과 같거나 이전 버전일 경우 새 데이터를 모두 무시합니다. 해제된 버전보다 높은 버전에 대해 [PutInventory](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PutInventory.html) 작업을 호출함으로써 이 Inventory 유형을 다시 허용할 수 있습니다.
**AWS CLI를 사용하여 사용자 정의 인벤토리를 삭제하거나 해제하려면**
1. 아직 하지 않은 경우 AWS Command Line Interface(AWS CLI)을 설치하고 구성합니다.
자세한 내용은 [최신 버전의 AWS CLI 설치 또는 업데이트](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html)를 참조하세요.
1. `dry-run` 옵션으로 시스템에서 삭제할 데이터를 확인하려면 다음 명령을 실행하십시오. 이 명령은 어떤 데이터도 삭제하지 않습니다.
```
aws ssm delete-inventory --type-name "Custom:custom_type_name" --dry-run
```
시스템은 다음과 같은 정보를 반환합니다.
```
{
"DeletionSummary":{
"RemainingCount":3,
"SummaryItems":[
{
"Count":2,
"RemainingCount":2,
"Version":"1.0"
},
{
"Count":1,
"RemainingCount":1,
"Version":"2.0"
}
],
"TotalCount":3
},
"TypeName":"Custom:custom_type_name"
}
```
인벤토리 삭제 요약을 이해하는 방법은 [인벤토리 삭제 요약 이해하기](#delete-custom-inventory-summary) 섹션을 참조하세요.
1. 다음 명령을 실행하여 사용자 지정 인벤토리 유형의 데이터를 모두 삭제합니다.
```
aws ssm delete-inventory --type-name "Custom:custom_type_name"
```
**참고**
이 명령의 출력에는 삭제 진행 상황이 표시되지 않습니다. 그러므로 [총 개수(TotalCount)]와 [남은 개수(Remaining Count)]는 항상 동일합니다. 아직 아무것도 삭제되지 않았기 때문입니다. 이 주제 후반부에서 설명하는 방법으로 describe-inventory-deletions 명령을 사용하여 삭제 진행 상황을 표시할 수 있습니다.
시스템은 다음과 같은 정보를 반환합니다.
```
{
"DeletionId":"system_generated_deletion_ID",
"DeletionSummary":{
"RemainingCount":3,
"SummaryItems":[
{
"Count":2,
"RemainingCount":2,
"Version":"1.0"
},
{
"Count":1,
"RemainingCount":1,
"Version":"2.0"
}
],
"TotalCount":3
},
"TypeName":"custom_type_name"
}
```
그러면 Systems Manager Inventory 서비스에서 지정된 사용자 정의 Inventory 유형의 데이터가 모두 삭제됩니다.
1. 다음 명령을 실행합니다. 이 명령은 현재 버전을 해제하고, 해당하는 데이터를 모두 삭제하고, 해제된 버전 이하의 버전에서는 신규 데이터를 모두 무시하는 등의 작업을 현재 버전의 인벤토리 유형에 대해 수행합니다.
```
aws ssm delete-inventory --type-name "Custom:custom_type_name" --schema-delete-option "DisableSchema"
```
시스템은 다음과 같은 정보를 반환합니다.
```
{
"DeletionId":"system_generated_deletion_ID",
"DeletionSummary":{
"RemainingCount":3,
"SummaryItems":[
{
"Count":2,
"RemainingCount":2,
"Version":"1.0"
},
{
"Count":1,
"RemainingCount":1,
"Version":"2.0"
}
],
"TotalCount":3
},
"TypeName":"Custom:custom_type_name"
}
```
다음 명령으로 해제된 인벤토리 유형을 볼 수 있습니다.
```
aws ssm get-inventory-schema --type-name Custom:custom_type_name
```
1. 다음 명령을 실행하여 인벤토리 유형을 삭제합니다.
```
aws ssm delete-inventory --type-name "Custom:custom_type_name" --schema-delete-option "DeleteSchema"
```
지정된 사용자 지정 유형의 스키마와 인벤토리 데이터가 모두 삭제됩니다.
시스템은 다음과 같은 정보를 반환합니다.
```
{
"DeletionId":"system_generated_deletion_ID",
"DeletionSummary":{
"RemainingCount":3,
"SummaryItems":[
{
"Count":2,
"RemainingCount":2,
"Version":"1.0"
},
{
"Count":1,
"RemainingCount":1,
"Version":"2.0"
}
],
"TotalCount":3
},
"TypeName":"Custom:custom_type_name"
}
```
### 삭제 상태 보기
`describe-inventory-deletions` AWS CLI 명령으로 삭제 작업의 상태를 확인할 수 있습니다. 특정한 삭제 작업의 상태를 보려면 삭제 ID를 지정하십시오. 아니면 삭제 ID를 생략하고 최근 30일간 실행된 전체 삭제 작업 목록을 볼 수도 있습니다.
****
1. 다음 명령을 실행하여 삭제 작업의 상태를 확인합니다. 시스템에서는 delete-inventory 요약을 통해 삭제 ID를 반환했습니다.
```
aws ssm describe-inventory-deletions --deletion-id system_generated_deletion_ID
```
시스템에서 최신 상태를 반환합니다. 삭제 작업이 아직 종료되지 않았을 수 있습니다. 시스템은 다음과 같은 정보를 반환합니다.
```
{"InventoryDeletions":
[
{"DeletionId": "system_generated_deletion_ID",
"DeletionStartTime": 1521744844,
"DeletionSummary":
{"RemainingCount": 1,
"SummaryItems":
[
{"Count": 1,
"RemainingCount": 1,
"Version": "1.0"}
],
"TotalCount": 1},
"LastStatus": "InProgress",
"LastStatusMessage": "The Delete is in progress",
"LastStatusUpdateTime": 1521744844,
"TypeName": "Custom:custom_type_name"}
]
}
```
삭제 작업이 성공하면 `LastStatusMessage` 상태: 삭제 성공이 반환됩니다.
```
{"InventoryDeletions":
[
{"DeletionId": "system_generated_deletion_ID",
"DeletionStartTime": 1521744844,
"DeletionSummary":
{"RemainingCount": 0,
"SummaryItems":
[
{"Count": 1,
"RemainingCount": 0,
"Version": "1.0"}
],
"TotalCount": 1},
"LastStatus": "Complete",
"LastStatusMessage": "Deletion is successful",
"LastStatusUpdateTime": 1521745253,
"TypeName": "Custom:custom_type_name"}
]
}
```
1. 다음 명령을 실행하여 최근 30일간 실행된 전체 삭제 작업 목록을 볼 수도 있습니다.
```
aws ssm describe-inventory-deletions --max-results a number
```
```
{"InventoryDeletions":
[
{"DeletionId": "system_generated_deletion_ID",
"DeletionStartTime": 1521682552,
"DeletionSummary":
{"RemainingCount": 0,
"SummaryItems":
[
{"Count": 1,
"RemainingCount": 0,
"Version": "1.0"}
],
"TotalCount": 1},
"LastStatus": "Complete",
"LastStatusMessage": "Deletion is successful",
"LastStatusUpdateTime": 1521682852,
"TypeName": "Custom:custom_type_name"},
{"DeletionId": "system_generated_deletion_ID",
"DeletionStartTime": 1521744844,
"DeletionSummary":
{"RemainingCount": 0,
"SummaryItems":
[
{"Count": 1,
"RemainingCount": 0,
"Version": "1.0"}
],
"TotalCount": 1},
"LastStatus": "Complete",
"LastStatusMessage": "Deletion is successful",
"LastStatusUpdateTime": 1521745253,
"TypeName": "Custom:custom_type_name"},
{"DeletionId": "system_generated_deletion_ID",
"DeletionStartTime": 1521680145,
"DeletionSummary":
{"RemainingCount": 0,
"SummaryItems":
[
{"Count": 1,
"RemainingCount": 0,
"Version": "1.0"}
],
"TotalCount": 1},
"LastStatus": "Complete",
"LastStatusMessage": "Deletion is successful",
"LastStatusUpdateTime": 1521680471,
"TypeName": "Custom:custom_type_name"}
],
"NextToken": "next-token"
```
### 인벤토리 삭제 요약 이해하기
인벤토리 삭제 요약을 이해하려면 다음 예제를 생각해 보십시오. 사용자가 노드 세 개에 Custom:RackSpace 인벤토리를 할당했습니다. 인벤토리 항목 1과 2는 사용자 지정 유형 버전 1.0을 사용합니다("SchemaVersion":"1.0"). 인벤토리 항목 3은 사용자 지정 유형 버전 2.0을 사용합니다("SchemaVersion":"2.0").
RackSpace 사용자 지정 인벤토리 1
```
{
"CaptureTime":"2018-02-19T10:48:55Z",
"TypeName":"CustomType:RackSpace",
"InstanceId":"i-1234567890",
"SchemaVersion":"1.0" "Content":[
{
content of custom type omitted
}
]
}
```
RackSpace 사용자 지정 인벤토리 2
```
{
"CaptureTime":"2018-02-19T10:48:55Z",
"TypeName":"CustomType:RackSpace",
"InstanceId":"i-1234567891",
"SchemaVersion":"1.0" "Content":[
{
content of custom type omitted
}
]
}
```
RackSpace 사용자 지정 인벤토리 3
```
{
"CaptureTime":"2018-02-19T10:48:55Z",
"TypeName":"CustomType:RackSpace",
"InstanceId":"i-1234567892",
"SchemaVersion":"2.0" "Content":[
{
content of custom type omitted
}
]
}
```
사용자는 다음 명령을 실행하여 삭제할 데이터를 미리 봅니다.
```
aws ssm delete-inventory --type-name "Custom:RackSpace" --dry-run
```
시스템은 다음과 같은 정보를 반환합니다.
```
{
"DeletionId":"1111-2222-333-444-66666",
"DeletionSummary":{
"RemainingCount":3,
"TotalCount":3,
TotalCount and RemainingCount are the number of items that would be deleted if this was not a dry run. These numbers are the same because the system didn't delete anything.
"SummaryItems":[
{
"Count":2, The system found two items that use SchemaVersion 1.0. Neither item was deleted.
"RemainingCount":2,
"Version":"1.0"
},
{
"Count":1, The system found one item that uses SchemaVersion 1.0. This item was not deleted.
"RemainingCount":1,
"Version":"2.0"
}
],
},
"TypeName":"Custom:RackSpace"
}
```
사용자는 다음 명령을 실행하여 Custom:RackSpace 인벤토리를 삭제합니다.
**참고**
이 명령의 출력에는 삭제 진행 상황이 표시되지 않습니다. 그러므로 `TotalCount`와 `RemainingCount`는 항상 동일합니다. 아직 아무것도 삭제되지 않았기 때문입니다. `describe-inventory-deletions` 명령을 사용하여 삭제 진행 상황을 표시합니다.
```
aws ssm delete-inventory --type-name "Custom:RackSpace"
```
시스템은 다음과 같은 정보를 반환합니다.
```
{
"DeletionId":"1111-2222-333-444-7777777",
"DeletionSummary":{
"RemainingCount":3, There are three items to delete
"SummaryItems":[
{
"Count":2, The system found two items that use SchemaVersion 1.0.
"RemainingCount":2,
"Version":"1.0"
},
{
"Count":1, The system found one item that uses SchemaVersion 2.0.
"RemainingCount":1,
"Version":"2.0"
}
],
"TotalCount":3
},
"TypeName":"RackSpace"
}
```
### EventBridge에서 인벤토리 삭제 작업 보기
사용자가 사용자 정의 인벤토리를 삭제할 때마다 이벤트를 생성하도록 Amazon EventBridge를 구성할 수 있습니다. EventBridge는 사용자 정의 인벤토리 삭제 작업에 대해 다음과 같은 3가지 유형의 이벤트를 제공합니다.
+ **Delete action for an instance(인스턴스에 대한 삭제 작업)**: 지정된 관리형 노드에 대한 사용자 지정 인벤토리가 무사히 삭제되었는지 여부.
+ **Delete action summary(삭제 작업 요약)**: 삭제 작업의 요약.
+ [**해제된 사용자 정의 Inventory 유형 경고(Warning for turned off custom inventory type)**]: 이전에 해제한 사용자 정의 Inventory 유형 버전에 [PutInventory](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PutInventory.html) API 작업을 호출할 경우 등장하는 경고 이벤트.
다음은 각 이벤트의 예입니다.
**Delete action for an instance(인스턴스에 대한 삭제 작업)**
```
{
"version":"0",
"id":"998c9cde-56c0-b38b-707f-0411b3ff9d11",
"detail-type":"Inventory Resource State Change",
"source":"aws.ssm",
"account":"478678815555",
"time":"2018-05-24T22:24:34Z",
"region":"us-east-1",
"resources":[
"arn:aws:ssm:us-east-1:478678815555:managed-instance/i-0a5feb270fc3f0b97"
],
"detail":{
"action-status":"succeeded",
"action":"delete",
"resource-type":"managed-instance",
"resource-id":"i-0a5feb270fc3f0b97",
"action-reason":"",
"type-name":"Custom:MyInfo"
}
}
```
**Delete action summary(삭제 작업 요약)**
```
{
"version":"0",
"id":"83898300-f576-5181-7a67-fb3e45e4fad4",
"detail-type":"Inventory Resource State Change",
"source":"aws.ssm",
"account":"478678815555",
"time":"2018-05-24T22:28:25Z",
"region":"us-east-1",
"resources":[
],
"detail":{
"action-status":"succeeded",
"action":"delete-summary",
"resource-type":"managed-instance",
"resource-id":"",
"action-reason":"The delete for type name Custom:MyInfo was completed. The deletion summary is: {\"totalCount\":2,\"remainingCount\":0,\"summaryItems\":[{\"version\":\"1.0\",\"count\":2,\"remainingCount\":0}]}",
"type-name":"Custom:MyInfo"
}
}
```
**해제된 사용자 정의 인벤토리 유형 경고**
```
{
"version":"0",
"id":"49c1855c-9c57-b5d7-8518-b64aeeef5e4a",
"detail-type":"Inventory Resource State Change",
"source":"aws.ssm",
"account":"478678815555",
"time":"2018-05-24T22:46:58Z",
"region":"us-east-1",
"resources":[
"arn:aws:ssm:us-east-1:478678815555:managed-instance/i-0ee2d86a2cfc371f6"
],
"detail":{
"action-status":"failed",
"action":"put",
"resource-type":"managed-instance",
"resource-id":"i-0ee2d86a2cfc371f6",
"action-reason":"The inventory item with type name Custom:MyInfo was sent with a disabled schema version 1.0. You must send a version greater than 1.0",
"type-name":"Custom:MyInfo"
}
}
```
사용자 정의 인벤토리 삭제 작업에 EventBridge 규칙을 생성하려면 다음 절차를 따릅니다. 이 절차는 사용자 정의 인벤토리 삭제 작업에 대한 알림을 Amazon SNS 주제에 전송하도록 규칙을 생성하는 방법입니다. 시작하기 전에 Amazon SNS 주제가 있는지 확인하고 없으면 새로 생성합니다. 자세한 내용은 *Amazon Simple Notification Service Developer Guide*의 [Getting Started](https://docs.aws.amazon.com/sns/latest/dg/GettingStarted.html)를 참조하세요.
**인벤토리 삭제 작업에 EventBridge를 구성하려면**
1. [https://console.aws.amazon.com/events/](https://console.aws.amazon.com/events/)에서 Amazon EventBridge 콘솔을 엽니다.
1. 탐색 창에서 **규칙**을 선택합니다.
1. **규칙 생성**을 선택합니다.
1. 규칙에 대해 이름과 설명을 입력하세요.
규칙은 동일한 리전과 동일한 이벤트 버스의 다른 규칙과 동일한 이름을 가질 수 없습니다.
1. **이벤트 버스**에서 이 규칙과 연결할 이벤트 버스를 선택합니다. 이 규칙이 자신의 AWS 계정에서 오는 일치하는 이벤트에 응답하도록 하려면 **default**(기본)를 선택합니다. 계정의 AWS 서비스이(가) 이벤트를 출력하면 항상 계정의 기본 이벤트 버스로 이동합니다.
1. **규칙 유형**에서 **이벤트 패턴이 있는 규칙**을 선택합니다.
1. **다음**을 선택합니다.
1. **이벤트 소스(Event source)**에서 **AWS 이벤트 또는 EventBridge 파트너 이벤트(Events or EventBridge partner events)**를 선택합니다.
1. **이벤트 패턴(Event pattern)**섹션에서 **이벤트 패턴 양식(Event pattern form)**을 선택합니다.
1. **이벤트 소스**에서 **AWS 서비스**를 선택합니다.
1. **AWS service**(서비스)에서 **Systems Manager**를 선택합니다.
1. [**이벤트 유형(Event type)**]으로 [**인벤토리**]를 선택합니다.
1. **Specific detail type(s)**(특정 상세 유형)에서 **Inventory Resource State Change**(인벤토리 리소스 상태 변경)을 선택합니다.
1. **다음**을 선택합니다.
1. **대상 유형**에서 **AWS서비스**를 선택합니다.
1. **Select a target**(대상 선택)에서 **SNS topic**(SNS 주제)을 선택한 후 **Topic**(주제)에서 주제를 선택합니다.
1. **Additional settings**(추가 설정) 섹션의 **Configure target input**(대상 입력 구성)에서 **Matched event**(일치하는 이벤트)가 선택되었는지 확인합니다.
1. **다음**을 선택합니다.
1. (선택 사항)규칙에 대해 하나 이상의 태그를 입력하세요. 자세한 내용은 *Amazon EventBridge User Guide*의 [Tagging Your Amazon EventBridge Resources](https://docs.aws.amazon.com/eventbridge/latest/userguide/eventbridge-tagging.html)를 참조하세요.
1. **다음**을 선택합니다.
1. 규칙의 세부 정보를 검토하고 **규칙 생성**을 선택합니다.
# 인벤토리 이력 및 변경 사항 추적 보기
[AWS Config](https://docs.aws.amazon.com/config/latest/developerguide/)를 사용하여 모든 관리형 노드에 대한 AWS Systems Manager Inventory 기록 및 변경 사항 추적을 확인할 수 있습니다. AWS Config에서는 AWS 계정에 있는 AWS 리소스의 구성을 자세히 보여줍니다. 이러한 보기에는 리소스 간에 어떤 관계가 있는지와 리소스가 과거에 어떻게 구성되었는지도 포함되므로, 시간이 지나면서 구성과 관계가 어떻게 변하는지 확인할 수 있습니다. 인벤토리 기록과 변경 사항 추적을 보려면 AWS Config에서 다음 리소스를 설정해야 합니다.
+ SSM:ManagedInstanceInventory
+ SSM:PatchCompliance
+ SSM:AssociationCompliance
+ SSM:FileData
**참고**
Inventory 기록 및 변경 추적에 대한 다음과 같은 중요한 세부 정보에 유의합니다.
AWS Config를 사용하여 시스템의 변경 사항을 추적하는 경우 AWS Config(`SSM:FileData`)에서 파일 변경 사항을 볼 수 있도록 `AWS:File` 메타데이터를 수집하도록 Systems Manager Inventory를 구성해야 합니다. 그렇지 않으면 AWS Config가 시스템의 파일 변경 사항을 추적하지 않습니다.
SSM:PatchCompliance 및 SSM:AssociationCompliance를 설정하여 Systems Manager Patch Manager 패치와 Systems Manager State Manager 연결의 Compliance 기록 및 변경 사항 추적을 확인할 수 있습니다. 이러한 리소스의 규정 준수 관리에 대한 자세한 내용은 [규정 준수에 대해 자세히 알아보기](compliance-about.md) 섹션을 참조하세요.
다음 절차에서는 AWS Command Line Interface(AWS CLI)를 사용하여 AWS Config에서 인벤토리 기록 및 변경 사항 추적의 기록을 설정하는 방법을 설명합니다. AWS Config에서 이러한 리소스를 선택하고 구성하는 방법에 대한 자세한 내용은 *AWS Config Developer Guide*의 [Selecting Which Resources AWS Config Records](https://docs.aws.amazon.com/config/latest/developerguide/select-resources.html)를 참조하세요. AWS Config 요금에 대한 자세한 내용은 [요금](https://aws.amazon.com/config/pricing/)을 참조하세요.
**시작하기 전에**
AWS Config에 AWS Identity and Access Management(IAM) 권한이 있어야 Systems Manager 리소스에 대한 구성 세부 정보를 가져올 수 있습니다. 다음 절차에서는 IAM 역할의 Amazon 리소스 이름(ARN)을 지정하여 Systems Manager 리소스에 대한 권한을 AWS Config에 부여해야 합니다. `AWS_ConfigRole` 관리형 정책을 AWS Config에 할당한 IAM 역할에 연결할 수 있습니다. 이 역할에 대한 자세한 내용은 *AWS Config 개발자 안내서*의 [AWS 관리형 정책: AWS\$1ConfigRole](https://docs.aws.amazon.com/config/latest/developerguide/security-iam-awsmanpol.html#security-iam-awsmanpol-AWS_ConfigRole)을 참조하세요. IAM 역할을 생성하고 해당 역할에 `AWS_ConfigRole` 관리형 정책을 할당하는 방법에 대한 자세한 내용은 *IAM 사용 설명서*의 [AWS 서비스에 권한을 위임하는 역할 생성](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-service.html)을 참조하세요.
**AWS Config에서 인벤토리 기록 및 변경 사항 추적의 기록을 설정하려면**
1. 아직 하지 않은 경우 AWS Command Line Interface(AWS CLI)을 설치하고 구성합니다.
자세한 내용은 [최신 버전의 AWS CLI 설치 또는 업데이트](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html)를 참조하세요.
1. 다음 JSON 샘플을 복사하여 단순한 텍스트 파일에 붙여 넣고 recordingGroup.json으로 저장합니다.
```
{
"allSupported":false,
"includeGlobalResourceTypes":false,
"resourceTypes":[
"AWS::SSM::AssociationCompliance",
"AWS::SSM::PatchCompliance",
"AWS::SSM::ManagedInstanceInventory",
"AWS::SSM::FileData"
]
}
```
1. 다음 명령을 실행하여 recordingGroup.json 파일을 AWS Config에 로드합니다.
```
aws configservice put-configuration-recorder --configuration-recorder name=myRecorder,roleARN=arn:aws:iam::123456789012:role/myConfigRole --recording-group file://recordingGroup.json
```
1. 다음 명령을 실행하여 인벤토리 이력 및 변경 사항 추적의 기록을 시작합니다.
```
aws configservice start-configuration-recorder --configuration-recorder-name myRecorder
```
기록 및 변경 내용 추적을 구성한 후 Systems Manager 콘솔에서 **AWS Config** 버튼을 선택하여 특정 관리형 노드에 대한 기록을 드릴다운할 수 있습니다. **관리형 인스턴스(Managed Instances)** 페이지 또는 **Inventory** 페이지에서 **AWS Config** 버튼에 액세스할 수 있습니다. 모니터 크기에 따라 페이지 오른쪽으로 스크롤해야 이 버튼이 보일 수도 있습니다.
# 데이터 수집 중지 및 인벤토리 데이터 삭제
더 이상 AWS Systems Manager Inventory를 사용하여 AWS 리소스에 대한 메타데이터를 보고 싶지 않다면, 데이터 수집을 중지하고 이미 수집된 데이터를 삭제할 수 있습니다. 이 섹션에는 다음 정보가 포함됩니다.
**Topics**
+ [데이터 수집 중지](#systems-manager-inventory-delete-association)
+ [Inventory 리소스 데이터 동기화 삭제](#systems-manager-inventory-delete-RDS)
## 데이터 수집 중지
인벤토리 데이터를 수집하도록 Systems Manager를 처음 구성하면 시스템에서 일정 및 메타데이터를 수집할 리소스를 정의하는 State Manager 연결을 생성합니다. `AWS-GatherSoftwareInventory` 문서를 사용하는 State Manager 연결을 삭제하여 데이터 수집을 중지할 수 있습니다.
**Inventory 연결을 삭제하려면**
1. [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)에서 AWS Systems Manager 콘솔을 엽니다.
1. 탐색 창에서 **State Manager**를 선택합니다.
1. `AWS-GatherSoftwareInventory` 문서를 사용하는 연결을 선택한 다음 **삭제(Delete)**를 선택합니다.
1. `AWS-GatherSoftwareInventory` 문서를 사용하는 나머지 연결에 대해 3단계를 반복합니다.
## Inventory 리소스 데이터 동기화 삭제
더 이상 AWS Systems Manager Inventory를 사용하여 AWS 리소스에 대한 메타데이터를 보고 싶지 않다면, 인벤토리 데이터 수집에 사용되는 리소스 데이터 동기화를 삭제하는 것이 좋습니다.
**Inventory 리소스 데이터 동기화를 삭제하려면**
1. [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)에서 AWS Systems Manager 콘솔을 엽니다.
1. 탐색 창에서 [**Inventory**]를 선택합니다.
1. **리소스 데이터 동기화(Resource data sync)**를 선택합니다.
1. 목록에서 동기화를 선택합니다.
**중요**
Inventory에 사용되는 동기화를 선택해야 합니다. Systems Manager는 여러 도구에 대한 리소스 데이터 동기화를 지원합니다. 잘못된 동기화를 선택하면 Systems Manager Explorer 또는 Systems Manager Compliance의 데이터 집계가 중단될 수 있습니다.
1. **삭제(Delete)**를 선택합니다.
1. 삭제할 나머지 리소스 데이터 동기화에 대해 이 단계를 반복합니다.
1. 데이터가 저장된 Amazon Simple Storage Service(Amazon S3) 버킷을 삭제합니다. Amazon S3 버킷 삭제에 대한 자세한 내용은 [버킷 삭제](https://docs.aws.amazon.com/AmazonS3/latest/userguide/delete-bucket.html)를 참조하세요.
# 관리형 노드에 사용자 지정 인벤토리 메타데이터 할당
다음 절차는 AWS Systems Manager [PutInventory](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PutInventory.html) API 작업을 사용하여 관리형 노드에 사용자 정의 인벤토리 메타데이터를 할당하는 프로세스를 안내합니다. 이번 예에서는 노드에 랙 위치 정보를 할당합니다. 사용자 지정 인벤토리에 대한 자세한 내용은 [사용자 정의 인벤토리 작업](inventory-custom.md) 섹션을 참조하세요.
**사용자 지정 인벤토리 메타데이터를 노드에 할당**
1. 아직 하지 않은 경우 AWS Command Line Interface(AWS CLI)을 설치하고 구성합니다.
자세한 내용은 [최신 버전의 AWS CLI 설치 또는 업데이트](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html)를 참조하세요.
1. 다음 명령을 실행하여 노드에 랙 위치 정보를 할당합니다.
**Linux**
```
aws ssm put-inventory --instance-id "ID" --items '[{"CaptureTime": "2016-08-22T10:01:01Z", "TypeName": "Custom:RackInfo", "Content":[{"RackLocation": "Bay B/Row C/Rack D/Shelf E"}], "SchemaVersion": "1.0"}]'
```
**Windows**
```
aws ssm put-inventory --instance-id "ID" --items "TypeName=Custom:RackInfo,SchemaVersion=1.0,CaptureTime=2021-05-22T10:01:01Z,Content=[{RackLocation='Bay B/Row C/Rack D/Shelf F'}]"
```
1. 다음 명령을 실행하여 이 노드의 사용자 정의 인벤토리 항목을 확인합니다.
```
aws ssm list-inventory-entries --instance-id ID --type-name "Custom:RackInfo"
```
시스템은 다음과 같은 정보로 응답합니다.
```
{
"InstanceId": "ID",
"TypeName": "Custom:RackInfo",
"Entries": [
{
"RackLocation": "Bay B/Row C/Rack D/Shelf E"
}
],
"SchemaVersion": "1.0",
"CaptureTime": "2016-08-22T10:01:01Z"
}
```
1. 다음 명령을 실행하여 사용자 정의 인벤토리 스키마를 확인합니다.
```
aws ssm get-inventory-schema --type-name Custom:RackInfo
```
시스템은 다음과 같은 정보로 응답합니다.
```
{
"Schemas": [
{
"TypeName": "Custom:RackInfo",
"Version": "1.0",
"Attributes": [
{
"DataType": "STRING",
"Name": "RackLocation"
}
]
}
]
}
```
# AWS CLI를 사용하여 인벤토리 데이터 수집 구성
다음 절차에서는 관리형 노드에서 메타데이터를 수집하도록 AWS Systems Manager 인벤토리를 구성하는 프로세스를 설명합니다. 인벤토리 수집을 구성할 때 Systems Manager State Manager 연결을 생성하는 것으로 시작합니다. Systems Manager는 연결이 실행될 때 인벤토리 데이터를 수집합니다. 연결을 먼저 생성하지 않고 Systems Manager Run Command 등을 사용하여 `aws:softwareInventory` 플러그인을 호출하려고 하면 시스템이 다음 오류를 반환합니다.
`The aws:softwareInventory plugin can only be invoked via ssm-associate`.
**참고**
노드에는 한 번에 하나의 인벤토리 연결만 구성할 수 있습니다. 둘 이상의 인벤토리 연결로 노드를 구성할 경우 연결이 실행되지 않으며 인벤토리 데이터가 수집되지 않습니다.
## 빠르게 인벤토리에 대한 모든 관리형 노드 구성(CLI)
AWS 계정 및 현재 리전의 모든 관리형 노드에서 인벤토리 데이터를 수집하도록 빠르게 구성할 수 있습니다. 이를 전역 인벤토리 연결 생성이라고 합니다. AWS CLI를 사용하여 전역 인벤토리 연결을 생성하려면 다음 절차에 나와 있듯이 `instanceIds` 값에 와일드카드 옵션을 사용하십시오.
**AWS 계정 및 현재 리전의 모든 관리형 노드에서 인벤토리 구성(CLI)**
1. 아직 하지 않은 경우 AWS Command Line Interface(AWS CLI)을 설치하고 구성합니다.
자세한 내용은 [최신 버전의 AWS CLI 설치 또는 업데이트](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html)를 참조하세요.
1. 다음 명령을 실행합니다.
------
#### [ Linux & macOS ]
```
aws ssm create-association \
--name AWS-GatherSoftwareInventory \
--targets Key=InstanceIds,Values=* \
--schedule-expression "rate(1 day)" \
--parameters applications=Enabled,awsComponents=Enabled,customInventory=Enabled,instanceDetailedInformation=Enabled,networkConfig=Enabled,services=Enabled,windowsRoles=Enabled,windowsUpdates=Enabled
```
------
#### [ Windows ]
```
aws ssm create-association ^
--name AWS-GatherSoftwareInventory ^
--targets Key=InstanceIds,Values=* ^
--schedule-expression "rate(1 day)" ^
--parameters applications=Enabled,awsComponents=Enabled,customInventory=Enabled,instanceDetailedInformation=Enabled,networkConfig=Enabled,services=Enabled,windowsRoles=Enabled,windowsUpdates=Enabled
```
------
**참고**
이 명령은 Inventory가 Windows 레지스트리 또는 파일에 대한 메타데이터를 수집하는 것을 허용하지 않습니다. 이러한 데이터 형식을 인벤토리하려면 다음 절차를 사용하십시오.
## 관리형 노드에서 수동으로 인벤토리 구성(CLI)
다음 절차를 사용하여 수동으로 인스턴스 ID 또는 태그를 사용해 관리형 노드에 AWS Systems Manager 인벤토리를 구성합니다.
**수동으로 관리형 노드에서 인벤토리 구성(CLI)**
1. 아직 하지 않은 경우 AWS Command Line Interface(AWS CLI)을 설치하고 구성합니다.
자세한 내용은 [최신 버전의 AWS CLI 설치 또는 업데이트](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html)를 참조하세요.
1. 다음 명령을 실행하여 노드에서 Systems Manager Inventory를 실행하는 State Manager 연결을 생성합니다. 각 *example resource placeholder*를 사용자의 정보로 바꿉니다. 이 명령은 6시간마다 서비스를 실행하고 노드에서 네트워크 구성, Windows 업데이트, 애플리케이션 메타데이터를 수집하도록 구성합니다.
------
#### [ Linux & macOS ]
```
aws ssm create-association \
--name "AWS-GatherSoftwareInventory" \
--targets "Key=instanceids,Values=an_instance_ID" \
--schedule-expression "rate(240 minutes)" \
--output-location "{ \"S3Location\": { \"OutputS3Region\": \"region_ID, for example us-east-2\", \"OutputS3BucketName\": \"amzn-s3-demo-bucket\", \"OutputS3KeyPrefix\": \"Test\" } }" \
--parameters "networkConfig=Enabled,windowsUpdates=Enabled,applications=Enabled"
```
------
#### [ Windows ]
```
aws ssm create-association ^
--name "AWS-GatherSoftwareInventory" ^
--targets "Key=instanceids,Values=an_instance_ID" ^
--schedule-expression "rate(240 minutes)" ^
--output-location "{ \"S3Location\": { \"OutputS3Region\": \"region_ID, for example us-east-2\", \"OutputS3BucketName\": \"amzn-s3-demo-bucket\", \"OutputS3KeyPrefix\": \"Test\" } }" ^
--parameters "networkConfig=Enabled,windowsUpdates=Enabled,applications=Enabled"
```
------
시스템은 다음과 같은 정보로 응답합니다.
```
{
"AssociationDescription": {
"ScheduleExpression": "rate(240 minutes)",
"OutputLocation": {
"S3Location": {
"OutputS3KeyPrefix": "Test",
"OutputS3BucketName": "Test bucket",
"OutputS3Region": "us-east-2"
}
},
"Name": "The name you specified",
"Parameters": {
"applications": [
"Enabled"
],
"networkConfig": [
"Enabled"
],
"windowsUpdates": [
"Enabled"
]
},
"Overview": {
"Status": "Pending",
"DetailedStatus": "Creating"
},
"AssociationId": "1a2b3c4d5e6f7g-1a2b3c-1a2b3c-1a2b3c-1a2b3c4d5e6f7g",
"DocumentVersion": "$DEFAULT",
"LastUpdateAssociationDate": 1480544990.06,
"Date": 1480544990.06,
"Targets": [
{
"Values": [
"i-02573cafcfEXAMPLE"
],
"Key": "InstanceIds"
}
]
}
}
```
대규모 노드 그룹을 대상으로 EC2 태그와 `Targets` 파라미터를 사용할 수 있습니다. 다음 예제를 참조하세요.
------
#### [ Linux & macOS ]
```
aws ssm create-association \
--name "AWS-GatherSoftwareInventory" \
--targets "Key=tag:Environment,Values=Production" \
--schedule-expression "rate(240 minutes)" \
--output-location "{ \"S3Location\": { \"OutputS3Region\": \"us-east-2\", \"OutputS3BucketName\": \"amzn-s3-demo-bucket\", \"OutputS3KeyPrefix\": \"Test\" } }" \
--parameters "networkConfig=Enabled,windowsUpdates=Enabled,applications=Enabled"
```
------
#### [ Windows ]
```
aws ssm create-association ^
--name "AWS-GatherSoftwareInventory" ^
--targets "Key=tag:Environment,Values=Production" ^
--schedule-expression "rate(240 minutes)" ^
--output-location "{ \"S3Location\": { \"OutputS3Region\": \"us-east-2\", \"OutputS3BucketName\": \"amzn-s3-demo-bucket\", \"OutputS3KeyPrefix\": \"Test\" } }" ^
--parameters "networkConfig=Enabled,windowsUpdates=Enabled,applications=Enabled"
```
------
표현식과 함께 `files` 및 `windowsRegistry` 유형의 인벤토리를 사용하여 Windows Server 노드에서 파일 및 Windows 레지스트리 키를 인벤토리로 만들 수도 있습니다. 이러한 인벤토리 유형에 대한 자세한 내용은 [파일 및 Windows 레지스트리 인벤토리 관련 작업](inventory-file-and-registry.md)를 참조하십시오.
------
#### [ Linux & macOS ]
```
aws ssm create-association \
--name "AWS-GatherSoftwareInventory" \
--targets "Key=instanceids,Values=i-0704358e3a3da9eb1" \
--schedule-expression "rate(240 minutes)" \
--parameters '{"files":["[{\"Path\": \"C:\\Program Files\", \"Pattern\": [\"*.exe\"], \"Recursive\": true}]"], "windowsRegistry": ["[{\"Path\":\"HKEY_LOCAL_MACHINE\\Software\\Amazon\", \"Recursive\":true}]"]}' \
--profile dev-pdx
```
------
#### [ Windows ]
```
aws ssm create-association ^
--name "AWS-GatherSoftwareInventory" ^
--targets "Key=instanceids,Values=i-0704358e3a3da9eb1" ^
--schedule-expression "rate(240 minutes)" ^
--parameters '{"files":["[{\"Path\": \"C:\\Program Files\", \"Pattern\": [\"*.exe\"], \"Recursive\": true}]"], "windowsRegistry": ["[{\"Path\":\"HKEY_LOCAL_MACHINE\\Software\\Amazon\", \"Recursive\":true}]"]}' ^
--profile dev-pdx
```
------
1. 다음 명령을 실행하여 연결 상태를 확인합니다.
```
aws ssm describe-instance-associations-status --instance-id an_instance_ID
```
시스템은 다음과 같은 정보로 응답합니다.
```
{
"InstanceAssociationStatusInfos": [
{
"Status": "Pending",
"DetailedStatus": "Associated",
"Name": "reInvent2016PolicyDocumentTest",
"InstanceId": "i-1a2b3c4d5e6f7g",
"AssociationId": "1a2b3c4d5e6f7g-1a2b3c-1a2b3c-1a2b3c-1a2b3c4d5e6f7g",
"DocumentVersion": "1"
}
]
}
```
# 연습: 리소스 데이터 동기화를 사용하여 인벤토리 데이터 집계
다음 시연에서는 AWS Command Line Interface(AWS CLI)를 사용하여 AWS Systems Manager Inventory에 대한 리소스 데이터 동기화 구성을 생성하는 방법을 설명합니다. 리소스 데이터 동기화는 모든 관리형 노드의 인벤토리 데이터를 중앙의 Amazon Simple Storage Service(Amazon S3) 버킷으로 자동 포팅합니다. 새로운 인벤토리 데이터가 발견될 때마다 동기화를 통해 중앙의 Amazon S3 버킷 데이터가 자동으로 업데이트됩니다.
이번 시연에서는 Amazon Athena 및 Amazon Quick을 사용하여 수집한 데이터에 대해 쿼리를 실행하고 분석하는 방법에 대해서 설명합니다. AWS Management Console에서 Systems Manager를 사용하여 리소스 데이터 동기화를 생성하는 방법에 대한 자세한 내용은 [연습: 리소스 데이터 동기화를 사용하여 인벤토리 데이터 집계](#inventory-resource-data-sync) 섹션을 참조하세요. AWS Management Console의 Systems Manager를 사용하여 여러 AWS 리전 및 계정의 인벤토리를 쿼리하는 방법에 대한 자세한 내용은 [여러 리전 및 계정에서 인벤토리 데이터 쿼리](systems-manager-inventory-query.md) 섹션을 참조하세요.
**참고**
이 연습에는 AWS Key Management Service(AWS KMS)를 사용하여 동기화를 암호화하는 방법에 대한 정보가 포함되어 있습니다. 암호화는 옵션이므로 인벤토리에서는 사용자별 데이터, 독점 데이터 또는 민감한 데이터를 수집하지 않습니다. AWS KMS에 대한 자세한 내용은 [AWS Key Management Service Developer Guide](https://docs.aws.amazon.com/kms/latest/developerguide/)를 참조하세요.
**시작하기 전 준비 사항**
이 섹션에서 연습을 시작하기 전에 다음 작업을 검토하거나 완료합니다.
+ 관리형 노드에서 인벤토리 데이터를 수집합니다. 이번 시연의 Amazon Athena 및 Amazon Quick 섹션 목적에 따라 애플리케이션 데이터의 수집을 권장합니다. 인벤토리 데이터를 수집하는 방법에 대한 자세한 내용은 [인벤토리 수집 구성](inventory-collection.md) 또는 [AWS CLI를 사용하여 인벤토리 데이터 수집 구성](inventory-collection-cli.md) 섹션을 참조하세요.
+ (선택 사항) 인벤토리 데이터가 AWS Key Management Service(AWS KMS) 암호화를 사용하는 Amazon Simple Storage Service(Amazon S3) 버킷에 저장된 경우, AWS KMS 암호화를 위해 IAM 계정과 `Amazon-GlueServiceRoleForSSM` 서비스 역할 또한 구성해야 합니다. IAM 계정과 이 역할을 구성하지 않는 경우 콘솔의 **세부 정보 보기(Detailed View)** 탭을 선택하면 Systems Manager가 `Cannot load Glue tables`를 표시합니다. 자세한 내용은 [(선택 사항) AWS KMS 암호화 데이터를 볼 수 있는 권한 구성](systems-manager-inventory-query.md#systems-manager-inventory-query-kms) 섹션을 참조하세요.
+ (선택 사항) AWS KMS를 사용하여 리소스 데이터 동기화를 암호화하려면 다음 정책을 포함하는 새 키를 생성하거나 기존 키를 업데이트하고 이 정책을 키에 추가해야 합니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Id": "ssm-access-policy",
"Statement": [
{
"Sid": "ssm-access-policy-statement",
"Action": [
"kms:GenerateDataKey"
],
"Effect": "Allow",
"Principal": {
"Service": "ssm.amazonaws.com"
},
"Resource": "arn:aws:kms:us-east-1:123456789012:key/KMS_key_id",
"Condition": {
"StringLike": {
"aws:SourceAccount": "123456789012"
},
"ArnLike": {
"aws:SourceArn": "arn:aws:ssm:*:123456789012:resource-data-sync/*"
}
}
}
]
}
```
------
**인벤토리의 리소스 데이터 동기화를 생성하려면**
1. [https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/)에서 S3 콘솔을 엽니다.
1. 집계된 인벤토리 데이터를 저장할 버킷을 생성합니다. 자세한 내용은 *Amazon Simple Storage Service 사용 설명서*에서 [버킷 생성](https://docs.aws.amazon.com/AmazonS3/latest/userguide/create-bucket-overview.html)을 참조하세요. 버킷 이름과 버킷을 생성한 AWS 리전을 따로 적어둡니다.
1. 버킷을 생성한 후 **권한** 탭, **버킷 정책**을 차례로 선택합니다.
1. 다음 버킷 정책을 복사하여 정책 편집기에 붙여 넣습니다. 이때 amzn-s3-demo-bucket 및 *account-id*를 사용자가 생성한 Amazon S3 버킷 이름 및 유효한 AWS 계정 ID로 바꿉니다. 여러 계정을 추가할 때 계정마다 조건 문자열과 ARN을 추가합니다. 계정 하나를 추가할 때 예제에서 추가 자리 표시자를 제거합니다. 원할 경우 *bucket-prefix*를 Amazon S3 접두사(하위 디렉터리) 이름으로 바꿉니다. 접두사를 생성하지 않았으면 정책의 ARN에서 *bucket-prefix/*를 제거합니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": " SSMBucketDelivery",
"Effect": "Allow",
"Principal": {
"Service": "ssm.amazonaws.com"
},
"Action": "s3:PutObject",
"Resource": [
"arn:aws:s3:::amzn-s3-demo-bucket/bucket-prefix/*/accountid=111122223333/*"
],
"Condition": {
"StringEquals": {
"s3:x-amz-acl": "bucket-owner-full-control",
"aws:SourceAccount": [
"111122223333",
"444455556666",
"123456789012",
"777788889999"
]
},
"ArnLike": {
"aws:SourceArn": [
"arn:aws:ssm:*:111122223333:resource-data-sync/*",
"arn:aws:ssm:*:444455556666:resource-data-sync/*",
"arn:aws:ssm:*:123456789012:resource-data-sync/*",
"arn:aws:ssm:*:777788889999:resource-data-sync/*"
]
}
}
}
]
}
```
------
1. (선택 사항) 동기화를 암호화하려면 앞 단계에 나열된 정책에 다음 조건을 추가해야 합니다. `StringEquals` 섹션에 추가하세요.
```
"s3:x-amz-server-side-encryption":"aws:kms",
"s3:x-amz-server-side-encryption-aws-kms-key-id":"arn:aws:kms:region:account_ID:key/KMS_key_ID"
```
다음 예를 참고하세요
```
"StringEquals": {
"s3:x-amz-acl": "bucket-owner-full-control",
"aws:SourceAccount": "account-id",
"s3:x-amz-server-side-encryption":"aws:kms",
"s3:x-amz-server-side-encryption-aws-kms-key-id":"arn:aws:kms:region:account_ID:key/KMS_key_ID"
}
```
1. 아직 하지 않은 경우 AWS Command Line Interface(AWS CLI)을 설치하고 구성합니다.
자세한 내용은 [최신 버전의 AWS CLI 설치 또는 업데이트](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html)를 참조하세요.
1. (옵션) 동기화를 암호화하려면 다음 명령을 실행하여 버킷 정책에서 AWS KMS 키 요구 사항을 실행하는지 확인합니다. 각 *example resource placeholder*를 사용자의 정보로 바꿉니다.
------
#### [ Linux & macOS ]
```
aws s3 cp ./A_file_in_the_bucket s3://amzn-s3-demo-bucket/prefix/ \
--sse aws:kms \
--sse-kms-key-id "arn:aws:kms:region:account_ID:key/KMS_key_id" \
--region region, for example, us-east-2
```
------
#### [ Windows ]
```
aws s3 cp ./A_file_in_the_bucket s3://amzn-s3-demo-bucket/prefix/ ^
--sse aws:kms ^
--sse-kms-key-id "arn:aws:kms:region:account_ID:key/KMS_key_id" ^
--region region, for example, us-east-2
```
------
1. 다음 명령을 실행하여 이 절차를 시작할 때 생성한 Amazon S3 버킷에서 리소스 데이터 동기화 구성을 생성합니다. 이 명령은 로그인되어 있는 AWS 리전에서 동기화를 생성합니다.
**참고**
동기화와 대상 Amazon S3 버킷이 서로 다른 리전에 위치하는 경우에는 데이터 전송 요금이 부과될 수 있습니다. 자세한 내용은 [Amazon S3 요금](https://aws.amazon.com/s3/pricing/)을 참조하세요.
------
#### [ Linux & macOS ]
```
aws ssm create-resource-data-sync \
--sync-name a_name \
--s3-destination "BucketName=amzn-s3-demo-bucket,Prefix=prefix_name, if_specified,SyncFormat=JsonSerDe,Region=bucket_region"
```
------
#### [ Windows ]
```
aws ssm create-resource-data-sync ^
--sync-name a_name ^
--s3-destination "BucketName=amzn-s3-demo-bucket,Prefix=prefix_name, if_specified,SyncFormat=JsonSerDe,Region=bucket_region"
```
------
`region` 파라미터를 사용하여 동기화 구성을 생성할 리전을 지정할 수 있습니다. 다음 예에서는 us-west-1 리전의 인벤토리 데이터가 us-west-2 리전에 속한 Amazon S3 버킷에서 동기화됩니다.
------
#### [ Linux & macOS ]
```
aws ssm create-resource-data-sync \
--sync-name InventoryDataWest \
--s3-destination "BucketName=amzn-s3-demo-bucket,Prefix=HybridEnv,SyncFormat=JsonSerDe,Region=us-west-2"
--region us-west-1
```
------
#### [ Windows ]
```
aws ssm create-resource-data-sync ^
--sync-name InventoryDataWest ^
--s3-destination "BucketName=amzn-s3-demo-bucket,Prefix=HybridEnv,SyncFormat=JsonSerDe,Region=us-west-2" ^ --region us-west-1
```
------
(선택 사항) AWS KMS를 사용하여 동기화를 암호화하려면 다음 명령을 실행하여 동기화를 생성합니다. 동기화를 암호화한 경우 AWS KMS 키와 Amazon S3 버킷이 같은 리전에 있어야 합니다.
------
#### [ Linux & macOS ]
```
aws ssm create-resource-data-sync \
--sync-name sync_name \
--s3-destination "BucketName=amzn-s3-demo-bucket,Prefix=prefix_name, if_specified,SyncFormat=JsonSerDe,AWSKMSKeyARN=arn:aws:kms:region:account_ID:key/KMS_key_ID,Region=bucket_region" \
--region region
```
------
#### [ Windows ]
```
aws ssm create-resource-data-sync ^
--sync-name sync_name ^
--s3-destination "BucketName=amzn-s3-demo-bucket,Prefix=prefix_name, if_specified,SyncFormat=JsonSerDe,AWSKMSKeyARN=arn:aws:kms:region:account_ID:key/KMS_key_ID,Region=bucket_region" ^
--region region
```
------
1. 다음 명령을 실행하여 동기화 구성 상태를 확인합니다.
```
aws ssm list-resource-data-sync
```
동기화 구성을 다른 리전에 생성한 경우에는 아래 예제와 같이 `region` 파라미터를 지정해야 합니다.
```
aws ssm list-resource-data-sync --region us-west-1
```
1. 동기화 구성이 성공적으로 생성된 후에는 Amazon S3의 대상 버킷을 검사합니다. 몇 분 내에 인벤토리 데이터가 표시되어야 합니다.
**Amazon Athena의 데이터 작업**
아래 섹션에서는 Amazon Athena에서 데이터를 확인하거나 쿼리를 실행하는 방법에 대해 설명합니다. 시작하기 전에 Athena에 대해 알아보는 것이 좋습니다. 자세한 내용은 *Amazon Athena User Guide*의 [What is Amazon Athena?](https://docs.aws.amazon.com/athena/latest/ug/what-is.html) 및 [Working with Data](https://docs.aws.amazon.com/athena/latest/ug/work-with-data.html)를 참조하세요.
**Amazon Athena에서 데이터를 보고 쿼리하려면**
1. [https://console.aws.amazon.com/athena/](https://console.aws.amazon.com/athena/home)에서 Athena 콘솔을 엽니다.
1. 다음 문을 복사하여 쿼리 편집기에 붙여 넣은 다음 **쿼리 실행**을 선택합니다.
```
CREATE DATABASE ssminventory
```
시스템이 ssminventory라는 이름의 데이터베이스를 생성합니다.
1. 다음 문을 복사하여 쿼리 편집기에 붙여 넣은 다음 **쿼리 실행**을 선택합니다. 이때 amzn-s3-demo-bucket 및 *bucket\$1prefix*를 Amazon S3 대상의 이름 및 접두사로 바꿉니다.
```
CREATE EXTERNAL TABLE IF NOT EXISTS ssminventory.AWS_Application (
Name string,
ResourceId string,
ApplicationType string,
Publisher string,
Version string,
InstalledTime string,
Architecture string,
URL string,
Summary string,
PackageId string
)
PARTITIONED BY (AccountId string, Region string, ResourceType string)
ROW FORMAT SERDE 'org.openx.data.jsonserde.JsonSerDe'
WITH SERDEPROPERTIES (
'serialization.format' = '1'
) LOCATION 's3://amzn-s3-demo-bucket/bucket_prefix/AWS:Application/'
```
1. 다음 문을 복사하여 쿼리 편집기에 붙여 넣은 다음 **쿼리 실행**을 선택합니다.
```
MSCK REPAIR TABLE ssminventory.AWS_Application
```
시스템이 테이블을 분할합니다.
**참고**
추가되는 AWS 리전 또는 AWS 계정에서 리소스 데이터 동기화를 생성하는 경우에는 위 명령을 다시 실행하여 파티션을 업데이트해야 합니다. Amazon S3 버킷 정책도 업데이트해야 할 수 있습니다.
1. 데이터를 미리 보려면 `AWS_Application` 테이블 옆에 있는 보기 아이콘을 선택합니다.
![\[Amazon Athena 미리 보기 데이터 아이콘.\]](http://docs.aws.amazon.com/ko_kr/systems-manager/latest/userguide/images/sysman-inventory-resource-data-sync-walk.png)
1. 다음 문을 복사하여 쿼리 편집기에 붙여 넣은 다음 **쿼리 실행**을 선택합니다.
```
SELECT a.name, a.version, count( a.version) frequency
from aws_application a where
a.name = 'aws-cfn-bootstrap'
group by a.name, a.version
order by frequency desc
```
쿼리는 Linux, macOS 및 Windows Server용 Amazon Elastic Compute Cloud(Amazon EC2) 인스턴스에 있는 AWS 애플리케이션인 `aws-cfn-bootstrap`의 여러 버전 수를 반환합니다.
1. 다음 문을 개별적으로 복사하여 쿼리 편집기에 붙여 넣고 amzn-s3-demo-bucket 및 *bucket-prefix*를 Amazon S3에 대한 정보로 바꾼 다음, **쿼리 실행**을 선택합니다. 아래 문들은 Athena의 인벤토리 테이블을 추가로 설정합니다.
```
CREATE EXTERNAL TABLE IF NOT EXISTS ssminventory.AWS_AWSComponent (
`ResourceId` string,
`Name` string,
`ApplicationType` string,
`Publisher` string,
`Version` string,
`InstalledTime` string,
`Architecture` string,
`URL` string
)
PARTITIONED BY (AccountId string, Region string, ResourceType string)
ROW FORMAT SERDE 'org.openx.data.jsonserde.JsonSerDe'
WITH SERDEPROPERTIES (
'serialization.format' = '1'
) LOCATION 's3://amzn-s3-demo-bucket/bucket-prefix/AWS:AWSComponent/'
```
```
MSCK REPAIR TABLE ssminventory.AWS_AWSComponent
```
```
CREATE EXTERNAL TABLE IF NOT EXISTS ssminventory.AWS_WindowsUpdate (
`ResourceId` string,
`HotFixId` string,
`Description` string,
`InstalledTime` string,
`InstalledBy` string
)
PARTITIONED BY (AccountId string, Region string, ResourceType string)
ROW FORMAT SERDE 'org.openx.data.jsonserde.JsonSerDe'
WITH SERDEPROPERTIES (
'serialization.format' = '1'
) LOCATION 's3://amzn-s3-demo-bucket/bucket-prefix/AWS:WindowsUpdate/'
```
```
MSCK REPAIR TABLE ssminventory.AWS_WindowsUpdate
```
```
CREATE EXTERNAL TABLE IF NOT EXISTS ssminventory.AWS_InstanceInformation (
`AgentType` string,
`AgentVersion` string,
`ComputerName` string,
`IamRole` string,
`InstanceId` string,
`IpAddress` string,
`PlatformName` string,
`PlatformType` string,
`PlatformVersion` string
)
PARTITIONED BY (AccountId string, Region string, ResourceType string)
ROW FORMAT SERDE 'org.openx.data.jsonserde.JsonSerDe'
WITH SERDEPROPERTIES (
'serialization.format' = '1'
) LOCATION 's3://amzn-s3-demo-bucket/bucket-prefix/AWS:InstanceInformation/'
```
```
MSCK REPAIR TABLE ssminventory.AWS_InstanceInformation
```
```
CREATE EXTERNAL TABLE IF NOT EXISTS ssminventory.AWS_Network (
`ResourceId` string,
`Name` string,
`SubnetMask` string,
`Gateway` string,
`DHCPServer` string,
`DNSServer` string,
`MacAddress` string,
`IPV4` string,
`IPV6` string
)
PARTITIONED BY (AccountId string, Region string, ResourceType string)
ROW FORMAT SERDE 'org.openx.data.jsonserde.JsonSerDe'
WITH SERDEPROPERTIES (
'serialization.format' = '1'
) LOCATION 's3://amzn-s3-demo-bucket/bucket-prefix/AWS:Network/'
```
```
MSCK REPAIR TABLE ssminventory.AWS_Network
```
```
CREATE EXTERNAL TABLE IF NOT EXISTS ssminventory.AWS_PatchSummary (
`ResourceId` string,
`PatchGroup` string,
`BaselineId` string,
`SnapshotId` string,
`OwnerInformation` string,
`InstalledCount` int,
`InstalledOtherCount` int,
`NotApplicableCount` int,
`MissingCount` int,
`FailedCount` int,
`OperationType` string,
`OperationStartTime` string,
`OperationEndTime` string
)
PARTITIONED BY (AccountId string, Region string, ResourceType string)
ROW FORMAT SERDE 'org.openx.data.jsonserde.JsonSerDe'
WITH SERDEPROPERTIES (
'serialization.format' = '1'
) LOCATION 's3://amzn-s3-demo-bucket/bucket-prefix/AWS:PatchSummary/'
```
```
MSCK REPAIR TABLE ssminventory.AWS_PatchSummary
```
**Amazon Quick의 데이터 작업**
아래 섹션에서는 Amazon Quick의 시각화 빌드를 위해 참조할 수 있는 링크에 대해서 간략히 소개합니다.
**Amazon Quick에서 시각화를 구축하려면**
1. [Amazon Quick](https://quicksight.aws/)에 가입한 후 QuickSight 콘솔에 로그인합니다.
1. `AWS_Application` 테이블과 생성한 다른 테이블에서 데이터 집합을 생성합니다. 자세한 내용은 *Amazon Quick 사용 설명서*의 [Amazon Athena 데이터를 사용하여 데이터 세트 생성](https://docs.aws.amazon.com/quicksuite/latest/userguide/create-a-data-set-athena.html)을 참조하세요.
1. 테이블을 조인합니다. 예를 들어 다른 인벤토리 테이블의 `resourceid` 열과 일치하기 때문에 `AWS_InstanceInformation`의 `instanceid` 열을 조인할 수 있습니다. 테이블 조인에 대한 자세한 내용은 *Amazon Quick 사용 설명서*의 [데이터 조인](https://docs.aws.amazon.com/quicksuite/latest/userguide/joining-data.html)을 참조하세요.
1. 시각화를 빌드합니다. 자세한 내용은 *Amazon Quick 사용 설명서*의 [분석 및 보고서: Amazon Quick Sight에서 데이터 시각화](https://docs.aws.amazon.com/quicksuite/latest/userguide/working-with-visuals.html)를 참조하세요.
# Systems Manager Inventory 관련 문제 해결
여기서는 AWS Systems Manager 인벤토리와 관련된 일반적인 오류나 문제를 해결하는 방법을 설명합니다. Systems Manager에서 노드를 보는 데 문제가 있는 경우 [관리형 노드 가용성 문제 해결](fleet-manager-troubleshooting-managed-nodes.md) 섹션을 참조하세요.
**Topics**
+ [문서 '`AWS-GatherSoftwareInventory`'와의 다중 적용 모든 연결은 지원되지 않습니다.](#systems-manager-inventory-troubleshooting-multiple)
+ [Inventory 실행 상태가 계속 보류 중임](#inventory-troubleshooting-pending)
+ [`AWS-ListWindowsInventory` 문서 실행 실패](#inventory-troubleshooting-ListWindowsInventory)
+ [콘솔은 인벤토리 대시보드 \$1 세부 정보 보기 \$1 설정 탭을 표시하지 않습니다.](#inventory-troubleshooting-tabs)
+ [UnsupportedAgent](#inventory-troubleshooting-unsupported-agent)
+ [건너뜀](#inventory-troubleshooting-skipped)
+ [실패](#inventory-troubleshooting-failed)
+ [Amazon EC2 인스턴스에 대한 인벤토리 규정 준수 실패](#inventory-troubleshooting-ec2-compliance)
+ [S3 버킷 객체에 이전 데이터가 포함되어 있음](#systems-manager-inventory-troubleshooting-s3)
## 문서 '`AWS-GatherSoftwareInventory`'와의 다중 적용 모든 연결은 지원되지 않습니다.
`Multiple apply all associations with document 'AWS-GatherSoftwareInventory' are not supported` 오류는 *모든 노드에 대한* Inventory 연결을 구성하려는 하나 이상의 AWS 리전이 모든 노드에 대한 인벤토리 연결로 이미 구성되었음을 의미합니다. 필요한 경우 모든 노드에 대한 기존 인벤토리 연결을 삭제한 다음 새로 생성할 수 있습니다. 기존 인벤토리 연결을 보려면 Systems Manager 콘솔에서 **State Manager**를 선택한 다음 `AWS-GatherSoftwareInventory` SSM 문서를 사용하는 연결을 찾습니다. 모든 노드에 대한 기존 인벤토리 연결이 여러 리전에 걸쳐 생성되었고 새로 생성하려는 경우 기존 연결이 있는 각 리전에서 기존 연결을 삭제해야 합니다.
## Inventory 실행 상태가 계속 보류 중임
인벤토리 수집이 계속 `Pending` 상태인 이유는 두 가지입니다.
+ 선택된 AWS 리전에 노드가 없습니다.
Systems Manager Quick Setup을 사용하여 글로벌 인벤토리 연결을 생성하는 경우 선택한 리전에 사용 가능한 노드가 없으면 인벤토리 연결(`AWS-GatherSoftwareInventory` 문서)의 상태가 `Pending`으로 표시됩니다.****
+ 권한 부족
하나 이상의 노드에 Systems Manager Inventory를 실행할 권한이 없는 경우 인벤토리 연결이 `Pending`으로 표시됩니다. AWS Identity and Access Management(IAM) 인스턴스 프로파일에 **AmazonSSMManagedInstanceCore** 관리형 정책이 포함되어 있는지 확인합니다. 인스턴스 프로파일에 이 정책을 추가하는 방법에 대한 자세한 내용은 [EC2 인스턴스 권한에 대한 대체 구성](setup-instance-permissions.md#instance-profile-add-permissions) 섹션을 참조하세요.
최소한 인스턴스 프로파일에 다음 IAM 권한이 있어야 합니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ssm:DescribeAssociation",
"ssm:ListAssociations",
"ssm:ListInstanceAssociations",
"ssm:PutInventory",
"ssm:PutComplianceItems",
"ssm:UpdateAssociationStatus",
"ssm:UpdateInstanceAssociationStatus",
"ssm:UpdateInstanceInformation",
"ssm:GetDocument",
"ssm:DescribeDocument"
],
"Resource": "*"
}
]
}
```
------
## `AWS-ListWindowsInventory` 문서 실행 실패
`AWS-ListWindowsInventory` 문서는 더 이상 사용되지 않습니다. 이 문서를 사용하여 인벤토리를 수집하지 마세요. 대신 [인벤토리 수집 구성](inventory-collection.md)에 설명된 프로세스 중 하나를 사용하세요.
## 콘솔은 인벤토리 대시보드 \$1 세부 정보 보기 \$1 설정 탭을 표시하지 않습니다.
Inventory [**세부 정보 뷰(Detailed View)**] 페이지는 Amazon Athena를 제공하는 AWS 리전에서만 사용할 수 있습니다. 다음 탭이 인벤토리(Inventory) 페이지에 표시되지 않는 경우 Athena는 리전에서 사용할 수 없으며 **세부 정보 보기(Detailed View)**를 사용하여 데이터를 쿼리할 수 없습니다.
![\[인벤토리 대시보드 | 세부 정보 보기 | 설정 탭 표시\]](http://docs.aws.amazon.com/ko_kr/systems-manager/latest/userguide/images/inventory-detailed-view-for-error.png)
## UnsupportedAgent
인벤토리 연결의 세부 상태가 **UnsupportedAgent**로 표시되고, **연결 상태**가 **실패**로 표시되는 경우 관리형 노드의 AWS Systems Manager SSM Agent 버전이 올바르지 않은 것입니다. 예를 들어 전역 인벤토리 연결을 생성하여 해당 AWS 계정의 모든 노드에 대한 인벤토리를 작성하려면 SSM Agent 버전 2.0.790.0 이상을 사용해야 합니다. 각 노드에서 실행 중인 에이전트 버전은 **관리형 인스턴스** 페이지의 **에이전트 버전** 열에서 볼 수 있습니다. 노드에서 SSM Agent를 업데이트하는 자세한 방법은 [Run Command를 사용하여 SSM Agent 업데이트](run-command-tutorial-update-software.md#rc-console-agentexample) 섹션을 참조하세요.
## 건너뜀
노드에 대한 인벤토리 연결 상태가 **건너뜀**으로 표시되면 해당 노드에서 우선순위가 더 높은 인벤토리 연결이 이미 실행 중임을 의미합니다. Systems Manager는 동일한 관리형 노드에 여러 인벤토리 연결을 적용할 수 있는 경우 특정 우선 순위를 따릅니다.
### 인벤토리 연결 우선 순위
Systems Manager는 다음 우선 순위에 따라 인벤토리 연결을 적용합니다.
1. **Quick Setup 인벤토리 연결** - Quick Setup 및 통합 콘솔을 사용하여 생성된 연결입니다. 이러한 연결은 이름이 `AWS-QuickSetup-SSM-CollectInventory-`로 시작하고 모든 관리형 노드를 대상으로 합니다.
1. **명시적 인벤토리 연결** - 다음을 사용하여 특정 관리형 노드를 대상으로 하는 연결입니다.
+ 인스턴스 ID
+ 태그 키-값 페어
+ AWS 리소스 그룹
1. **글로벌 인벤토리 연결** - 모든 관리형 노드를 대상으로 하지만(`--targets "Key=InstanceIds,Values=*"` 사용) Quick Setup을 통해 생성되지 **않은** 연결입니다.
### 일반적인 시나리오
**시나리오 1: Quick Setup 연결이 명시적 연결을 재정의**
+ 모든 인스턴스를 대상으로 하는 Quick Setup 인벤토리 연결이 있습니다.
+ 태그별로 특정 관리형 노드를 대상으로 하는 수동 연결을 생성합니다.
+ 결과: 수동 연결에 `Skipped` 및 세부 상태 `OverriddenByExplicitInventoryAssociation`이 표시됩니다.
+ Quick Setup 연결은 모든 인스턴스에서 인벤토리를 계속 수집합니다.
**시나리오 2: 명시적 연결이 글로벌 연결을 재정의**
+ 모든 인스턴스를 대상으로 하는 글로벌 인벤토리 연결이 있습니다(Quick Setup에서 생성하지 않음).
+ 특정 인스턴스를 대상으로 하는 연결을 생성합니다.
+ 결과: 글로벌 연결이 특정 대상 인스턴스에 대해 `Skipped`를 표시합니다.
+ 명시적 연결이 대상 인스턴스에서 실행됩니다.
### 해결 단계
**Quick Setup 대신 자체 인벤토리 연결을 사용하려는 경우:**
1. **Quick Setup 연결 식별**: Systems Manager 콘솔에서 State Manager로 이동하여 이름이 `AWS-QuickSetup-SSM-CollectInventory-`로 시작하는 연결을 찾습니다.
1. **Quick Setup 구성 제거**:
+ Systems Manager 콘솔에서 Quick Setup으로 이동합니다.
+ 인벤토리 수집 구성을 찾습니다.
+ Quick Setup 구성을 삭제합니다(연결된 인벤토리 연결이 제거됨).
**참고**
Quick Setup에서 생성한 연결은 수동으로 삭제할 필요가 없습니다.
1. **연결 실행 확인**: Quick Setup 구성을 제거한 후 명시적 인벤토리 연결이 성공적으로 실행되기 시작해야 합니다.
**기존 동작을 수정하려는 경우:**
+ 기존 인벤토리 연결을 모두 보려면 Systems Manager 콘솔에서 **State Manager**를 선택한 다음 `AWS-GatherSoftwareInventory` SSM 문서를 사용하는 연결을 찾습니다.
+ 각 관리형 노드는 한 번에 하나의 활성 인벤토리 연결만 가질 수 있습니다.
**중요**
할당된(우선 순위가 더 높은) 인벤토리 연결이 실행될 때 건너뛴 노드에서 인벤토리 데이터가 계속 수집됩니다.
Quick Setup 인벤토리 연결은 명시적 대상 지정이 있는 유형까지 포함하여 다른 모든 유형보다 우선합니다.
연결 유형에 관계없이 우선 순위가 더 높은 연결로 재정의되는 경우 세부 상태 메시지 `OverriddenByExplicitInventoryAssociation`이 표시됩니다.
## 실패
인스턴스의 인벤토리 연결 상태가 **실패(Failed)**인 경우, 해당 인스턴스에 여러 개의 인벤토리 연결이 할당되었을 수 있습니다. 하나의 노드는 한 번에 한 개의 인벤토리 연결만 가질 수 있습니다. 인벤토리 연결은 `AWS-GatherSoftwareInventory` AWS Systems Manager 문서(SSM 문서)를 사용합니다. AWS Command Line Interface(AWS CLI)에서 다음 명령을 실행하여 노드에 대한 연결 목록을 볼 수 있습니다.
```
aws ssm describe-instance-associations-status --instance-id instance-ID
```
## Amazon EC2 인스턴스에 대한 인벤토리 규정 준수 실패
인스턴스에 여러 인벤토리 연결을 할당하면 Amazon Elastic Compute Cloud(Amazon EC2) 인스턴스에 대한 인벤토리 규정 준수가 실패할 수 있습니다.
이 문제를 해결하려면 인스턴스에 할당된 인벤토리 연결을 하나 이상 삭제합니다. 자세한 내용은 [연결 삭제](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-state-manager-delete-association.html)를 참조하세요.
**참고**
관리형 노드에 대해 여러 인벤토리 연결을 만드는 경우 다음 동작을 유의하세요.
각 노드에 *모든* 노드(--targets "Key=InstanceIds,Values=\$1")를 대상으로 하는 인벤토리 연결이 할당될 수 있습니다.
태그 키-값 페어 또는 AWS 리소스 그룹을 사용하는 특정 연결이 각 노드에 할당될 수도 있습니다.
노드에 여러 인벤토리 연결이 할당된 경우 실행되지 않은 연결에 대해 상태가 *건너뜀(Skipped)*으로 표시됩니다. 가장 최근에 실행된 연결은 인벤토리 연결의 실제 상태를 표시합니다.
노드에 여러 인벤토리 연결이 할당되고 각각 태그 키-값 페어를 사용하는 경우 태그 충돌로 인해 해당 인벤토리 연결이 노드에서 실행되지 않습니다. 태그 키-값 충돌이 없는 노드에서 연결이 계속 실행됩니다.
## S3 버킷 객체에 이전 데이터가 포함되어 있음
Amazon S3 버킷 객체 내부의 데이터는 인벤토리 연결이 성공하고 새 데이터가 발견되면 업데이트됩니다. Amazon S3 버킷 객체는 연결이 실행되고 실패할 때 노드마다 업데이트되지만, 이 경우 객체 내부의 데이터는 업데이트되지 않습니다. Amazon S3 버킷 객체 내부의 데이터는 연결이 성공적으로 실행될 때만 업데이트됩니다. 인벤토리 연결에 실패하면 Amazon S3 버킷 객체에 이전 데이터가 표시됩니다.
# AWS Systems Manager Patch Manager
AWS Systems Manager의 도구인 Patch Manager는 보안 관련 업데이트 및 기타 유형의 업데이트로 관리형 노드를 패치하는 프로세스를 자동화합니다.
**참고**
Systems Manager는 AWS Systems Manager의 도구인 Quick Setup에서 **패치 정책을 지원합니다. 패치 정책을 사용하는 것이 패치 작업을 구성하는 데 권장되는 방법입니다. 단일 패치 정책 구성을 사용하여 조직 내 모든 리전의 모든 계정이나, 선택한 계정 및 리전이나, 단일 계정-리전 페어에 대한 패치 적용을 정의할 수 있습니다. 자세한 내용은 [Quick Setup의 패치 정책 구성](patch-manager-policies.md) 섹션을 참조하세요.
Patch Manager를 사용하면 운영 체제와 애플리케이션 모두를 패치할 수 있습니다. (Windows Server에서 애플리케이션 지원은 Microsoft에서 릴리스한 애플리케이션의 업데이트로 제한됩니다.) Patch Manager를 사용하여 Windows 노드에 서비스 팩을 설치하고 Linux 노드에서 부 버전 업그레이드를 실행할 수 있습니다. 운영 체제 유형별로 Amazon Elastic Compute Cloud(Amazon EC2) 인스턴스, 엣지 디바이스, 온프레미스 서버 및 가상 머신의 플릿에 패치를 적용할 수 있습니다. 여기에는 [Patch Manager 필수 조건](patch-manager-prerequisites.md)에 나와 있는 여러 운영 체제의 지원되는 버전이 포함됩니다. 인스턴스를 스캔하여 누락된 패치 보고서만 보거나, 혹은 스캔 후 누락된 패치를 모두 자동으로 설치할 수도 있습니다. Patch Manager를 시작하려면 [Systems Manager 콘솔](https://console.aws.amazon.com//systems-manager/patch-manager)을 엽니다. 탐색 창에서 **Patch Manager**를 선택합니다.
AWS는 Patch Manager에서 사용 가능성 여부를 확인하기 전에는 패치를 테스트하지 않습니다. 또한 Patch Manager는 주요 버전의 운영 체제 업그레이드를 지원하지 않습니다(예: Windows Server 2016에서 Windows Server 2019로 또는 (Red Hat Enterprise Linux)(RHEL) 7.0에서 RHEL 8.0으로).
패치의 심각도 수준을 보고하는 Linux 기반 운영 체제 유형의 경우 Patch Manager는 업데이트 알림 또는 개별 패치에 대해 소프트웨어 게시자가 보고한 심각도 수준을 사용합니다. Patch Manager는 CVSS([Common Vulnerability Scoring System](https://www.first.org/cvss/))와 같은 서드 파티 소스 또는 NVD([National Vulnerability Database](https://nvd.nist.gov/vuln))에서 발표한 지표에서 심각도 수준을 도출하지 않습니다.
## Patch Manager가 조직에 주는 이점은 무엇인가요?
Patch Manager는 보안 관련 업데이트 및 기타 유형의 업데이트로 관리형 노드를 패치하는 프로세스를 자동화합니다. 다음과 같은 몇 가지 중요한 이점이 있습니다.
+ **중앙 집중식 패치 적용 제어** - 패치 정책을 사용하면 조직의 모든 리전, 특정 계정 및 리전 또는 단일 계정-리전 페어에 있는 모든 계정에 대해 반복 패치 적용 작업을 설정할 수 있습니다.
+ **유연한 패치 적용 작업** - 인스턴스를 스캔하여 누락된 패치 보고서만 보거나 스캔 후 누락된 패치를 모두 자동으로 설치할 수도 있습니다.
+ **포괄적인 규정 준수 보고** - 스캔 작업 후 패치 규정을 위반하는 관리형 노드와 누락된 패치에 관한 자세한 정보를 볼 수 있습니다.
+ **교차 플랫폼 지원** - Patch Manager는 다양한 Linux 배포판, macOS, Windows Server를 포함한 여러 운영 체제를 지원합니다.
+ **사용자 지정 패치 기준** - 설치가 승인된 패치를 지정하는 사용자 지정 패치 기준을 통해 조직의 패치 규정 준수를 구성하는 항목을 정의할 수 있습니다.
+ **다른 AWS 서비스와의 통합** - Patch Manager는 관리와 보안을 강화하기 위해 AWS Organizations, AWS Security Hub CSPM, AWS CloudTrail, AWS Config과 통합됩니다.
+ **결정적 업그레이드** - Amazon Linux 2023과 같은 운영 체제의 버전이 지정된 리포지토리를 통한 결정적 업그레이드를 지원합니다.
## Patch Manager는 누가 사용해야 하나요?
Patch Manager는 다음을 위해 설계되었습니다.
+ 관리형 노드 플릿에서 패치 규정 준수를 유지해야 하는 IT 관리자
+ 인프라 전반의 패치 규정 준수 상태에 대해 가시성이 필요한 운영 관리자
+ 대규모로 자동 패치 적용 솔루션을 구현하려는 클라우드 아키텍트
+ 패치 적용을 작업 워크플로에 통합해야 하는 DevOps 엔지니어
+ 중앙 집중식 패치 관리가 필요하며 다중 계정/다중 리전 배포가 있는 조직
+ AWS 관리형 노드, 엣지 디바이스, 온프레미스 서버, 가상 머신의 보안 태세 및 운영 상태를 유지할 책임이 있는 사람
## Patch Manager의 주요 기능은 무엇입니까?
Patch Manager는 다음과 같은 몇 가지 핵심 기능을 제공합니다.
+ **패치 정책** - AWS Organizations와의 통합을 통해 단일 정책을 사용하여 여러 AWS 계정 및 리전에서 패치 적용 작업을 구성합니다.
+ **사용자 지정 패치 기준** - 승인 및 거부된 패치 목록과 함께 릴리스 후 며칠 이내에 패치를 자동으로 승인하는 규칙을 정의합니다.
+ **여러 패치 적용 방법** - 특정 요구 사항에 적합하게 패치 정책, 유지 관리 기간 또는 온디맨드 '지금 패치' 작업 중에서 선택합니다.
+ **규정 준수 보고** - CSV 형식으로 Amazon S3 버킷으로 전송할 수 있는 패치 규정 준수 상태에 대한 세부 보고서를 생성합니다.
+ **교차 플랫폼 지원** -Windows Server, 다양한 Linux 배포판, macOS에서 운영 체제와 애플리케이션을 모두 패치합니다.
+ **일정 유연성** - 사용자 지정 CRON 또는 Rate 표현식을 사용하여 패치를 스캔하고 설치하기 위한 다양한 일정을 설정합니다.
+ **수명 주기 후크** - Systems Manager 문서를 사용하여 패치 작업 전후에 사용자 지정 스크립트를 실행합니다.
+ **보안 포커스** - 기본적으로 Patch Manager는 사용 가능한 모든 패치를 설치하는 대신 보안 관련 업데이트에 중점을 둡니다.
+ **속도 제어** - 운영 영향을 최소화하기 위해 패치 작업에 대한 동시성 및 오류 임곗값을 구성합니다.
## Patch Manager에서 규정 준수란 무엇인가요?
Systems Manager 플릿의 관리형 노드에 대한 *패치 규정 준수*를 구성하는 항목에 대한 벤치마크는 AWS, 운영 체제(OS) 공급업체 또는 보안 컨설팅 회사와 같은 타사에서 정의하지 않습니다.
대신 *패치 기준*에서 조직 또는 계정의 관리형 노드에 대한 패치 준수의 의미를 정의합니다. 패치 기준은 관리형 노드에 어떤 패치를 설치해야 하는지에 대한 규칙을 지정하는 구성입니다. 관리형 노드는 패치 기준에서 지정하는 승인 기준을 충족하는 모든 패치를 통해 최신 상태로 유지하면 패치를 준수하는 것입니다.
패치 기준을 *준수*한다고 해서 관리형 노드가 반드시 *안전*하다는 의미는 아닙니다. 규정 준수란 패치 기준에 의해 정의된 패치 중 *사용 가능*하고 *승인된* 패치가 노드에 설치되었음을 의미합니다. 관리형 노드의 전반적인 보안은 Patch Manager의 범위 밖의 여러 요인에 의해 결정됩니다. 자세한 내용은 [AWS Systems Manager의 보안](security.md) 섹션을 참조하세요.
각 패치 기준은 Red Hat Enterprise Linux(RHEL), macOS, Windows Server 등의 지원되는 특정 운영 체제(OS) 유형에 대한 구성입니다. 패치 기준은 지원되는 모든 OS 버전에 대한 패치 규칙을 정의하거나 RHEL 7.8. 및 RHEL 9.3과 같이 사용자가 지정한 버전으로만 제한할 수 있습니다.
패치 기준에서 특정 분류 및 심각도 수준의 모든 패치가 설치 승인을 받도록 지정할 수 있습니다. 예를 들어 `Security`로 분류된 모든 패치는 포함하되 `Bugfix`, `Enhancement` 등의 다른 분류는 제외할 수 있습니다. 또한 심각도가 `Critical`인 패치는 모두 포함하고 `Important` 및 `Moderate`인 다른 패치는 제외할 수 있습니다.
또한 승인 또는 거부할 특정 패치 목록에 패치의 ID를 추가하여 패치 기준에서 패치를 명시적으로 정의할 수 있습니다(예: Windows Server의 경우 `KB2736693`, Amazon Linux 2023(AL2023)의 경우 `dbus.x86_64:1:1.12.28-1.amzn2023.0.1`). 필요에 따라 패치가 제공된 후 패치 적용을 기다리는 일수를 지정할 수 있습니다. Linux 및 macOS의 경우 패치 기준 규칙에 정의된 패치 대신 규정 준수를 위한 외부 패치 목록(설치 재정의 목록)을 지정할 수 있습니다.
패치 작업이 실행되면 Patch Manager는 관리형 노드에 현재 적용된 패치를 패치 기준 또는 설치 재정의 목록에 설정된 규칙에 따라 적용해야 하는 패치와 비교합니다. Patch Manager가 누락된 패치에 대한 보고서만 표시하도록 선택하거나(`Scan` 작업), Patch Manager가 관리형 노드에서 누락된 모든 패치를 자동으로 설치하도록 선택할 수 있습니다(`Scan and install` 작업).
**참고**
패치 규정 준수 데이터는 가장 최근에 성공한 패치 작업의 특정 시점 스냅샷을 나타냅니다. 각 규정 준수 보고서에는 규정 준수 상태가 계산된 때를 식별하는 캡처 시간이 포함되어 있습니다. 규정 준수 데이터를 검토할 때 캡처 시간을 고려하여 작업이 예상대로 실행되었는지 확인합니다.
Patch Manager는 패치 작업에 사용할 수 있는 사전 정의된 패치 기준을 제공하지만, 이러한 사전 정의된 구성은 권장 모범 사례가 아닌 예제로 제공됩니다. 플릿에 대한 패치 규정 준수를 구성하는 항목을 더 잘 제어하려면 자체 사용자 지정 패치 기준을 생성하는 것이 좋습니다.
패치 기준에 대한 자세한 내용은 다음 주제를 참조하세요.
+ [미리 정의된 사용자 지정 패치 기준](patch-manager-predefined-and-custom-patch-baselines.md)
+ [승인 패치 및 거부 패치 목록의 패키지 이름 형식](patch-manager-approved-rejected-package-name-formats.md)
+ [AWS가 미리 정의한 패치 기준 보기](patch-manager-view-predefined-patch-baselines.md)
+ [사용자 정의 패치 기준 작업](patch-manager-manage-patch-baselines.md)
+ [패치 규정 준수 보고서 작업](patch-manager-compliance-reports.md)
## 주요 구성 요소
Patch Manager 도구 작업을 시작하기 전에 도구 패치 작업의 몇 가지 주요 구성 요소와 특성을 숙지해야 합니다.
**패치 기준**
Patch Manager는 승인 및 거부된 패치 목록(선택 사항)과 함께 릴리스 후 며칠 내에 패치를 자동 승인하는 규칙을 포함하는 *패치 기준선*을 사용합니다. 패치 작업이 실행되면 Patch Manager는 관리형 노드에 현재 적용된 패치를 패치 기준선에 설정된 규칙에 따라 적용해야 하는 패치와 비교합니다. Patch Manager가 누락된 패치에 대한 보고서만 표시하도록 선택하거나(`Scan` 작업), Patch Manager가 관리형 노드에서 누락된 모든 패치를 자동으로 설치하도록 선택할 수 있습니다(`Scan and install` 작업).
**패치 작업 방법**
Patch Manager는 현재 실행 `Scan` 및 `Scan and install` 작업을 위한 네 가지 방법을 제공합니다.
+ **(권장) Quick Setup에 구성된 패치 정책** - AWS Organizations와의 통합을 기반으로 하는 단일 패치 정책으로 여러 AWS 계정 계정 및 해당 계정을 운영하는 모든 AWS 리전 계정을 비롯하여 전체 조직의 패치 적용 일정과 패치 기준선을 정의할 수 있습니다. 패치 정책은 조직의 일부 조직 단위(OU)만 대상으로 할 수도 있습니다. 단일 패치 정책을 사용하여 다양한 일정에 따라 스캔하고 설치할 수 있습니다. 자세한 내용은 [Quick Setup 패치 정책을 사용한 조직 내 인스턴스에 대한 패치 적용 구성](quick-setup-patch-manager.md) 및 [Quick Setup의 패치 정책 구성](patch-manager-policies.md)(을)를 참조하세요.
+ **Quick Setup에 구성된 호스트 관리 옵션** - 호스트 관리 구성도 AWS Organizations와의 통합을 통해 지원되므로, 최대 전체 조직을 대상으로 패치 작업을 실행할 수 있습니다. 단, 이 옵션은 현재 기본 패치 기준선을 사용하여 누락된 패치를 스캔하고 규정 준수 보고서에 결과를 제공하는 것으로 제한됩니다. 이 작업 방법으로 패치를 설치할 수는 없습니다. 자세한 내용은 [Quick Setup을 사용한 Amazon EC2 호스트 관리 설정](quick-setup-host-management.md) 섹션을 참조하세요.
+ **패치 `Scan` 또는 `Install` 태스크를 실행하기 위한 유지 관리 기간** - Maintenance Windows라는 Systems Manager 도구에서 설정하는 유지 관리 기간은 사용자가 정의한 일정에 따라 다양한 유형의 태스크를 실행하도록 구성할 수 있습니다. Run Command 유형 태스크는 선택한 관리형 노드 세트에 대해 `Scan` 또는 `Scan and install` 태스크를 실행하는 데 사용할 수 있습니다. 각 유지 관리 기간 태스크는 단일 AWS 계정-AWS 리전 쌍의 관리형 노드만 대상으로 할 수 있습니다. 자세한 내용은 [자습서: 콘솔을 사용하여 패치를 위한 유지 관리 기간 생성](maintenance-window-tutorial-patching.md) 섹션을 참조하세요.
+ **Patch Manager의 주문형 **지금 패치** 작업** - **지금 패치** 옵션을 사용하면 관리형 노드에 최대한 빨리 패치를 적용해야 할 때 설정된 일정을 무시할 수 있습니다. **Patch now**(지금 패치)를 사용하여, `Scan` 또는 `Scan and install` 작업을 실행할지 여부와 작업을 실행할 대상 관리형 노드를 지정합니다. 패치 작업 중에 Systems Manager 문서(SSM 문서)를 수명 주기 후크로 실행하도록 선택할 수도 있습니다. 각각의 **Patch now**(지금 패치) 작업은 단일 AWS 계정-AWS 리전 쌍의 관리형 노드만 대상으로 할 수 있습니다. 자세한 내용은 [관리형 노드 온디맨드 패치](patch-manager-patch-now-on-demand.md) 섹션을 참조하세요.
**규정 준수 보고**
`Scan`작업이 끝나면 Systems Manager 콘솔을 사용하여 어떤 관리형 노드가 패치 규정을 위반하지 않는지, 그리고 각 노드에서 어떤 패치가 누락되었는지에 대한 정보를 확인할 수 있습니다. 선택한 Amazon Simple Storage Service(S3) 버킷으로 전송되는 패치 규정 준수 보고서를 .csv 형식으로 생성할 수도 있습니다. 일회성 보고서를 생성하거나 정기적인 일정에 따라 보고서를 생성할 수 있습니다. 단일 관리형 노드의 경우 보고서에 노드에 대한 모든 패치의 세부 정보가 포함됩니다. 모든 관리형 노드에 대한 보고서의 경우 누락된 패치 수에 대한 요약만 제공됩니다. 보고서가 생성된 후 Amazon Quick과 같은 도구를 사용하여 데이터를 가져오고 분석할 수 있습니다. 자세한 내용은 [패치 규정 준수 보고서 작업](patch-manager-compliance-reports.md) 섹션을 참조하세요.
**참고**
패치 정책을 사용하여 생성된 규정 준수 항목의 실행 유형은 `PatchPolicy`입니다. 패치 정책 작업에서 생성도되지 않은 규정 준수 항목의 실행 유형은 `Command`입니다.
**통합**
Patch Manager는 다음과 같은 다른 AWS 서비스와 통합됩니다.
+ **AWS Identity and Access Management(IAM)** - IAM을 사용하여 Patch Manager 작업에 액세스할 수 있는 사용자, 그룹 및 역할을 제어할 수 있습니다. 자세한 내용은 [AWS Systems Manager에서 IAM을 사용하는 방식](security_iam_service-with-iam.md) 및 [Systems Manager에 필요한 인스턴스 권한 구성](setup-instance-permissions.md)을 참조하세요.
+ **AWS CloudTrail** - CloudTrail을 사용하여 사용자, 역할 또는 그룹에 의해 시작된 패치 작업 이벤트의 감사 가능한 기록을 기록할 수 있습니다. 자세한 내용은 [AWS CloudTrail를 사용하여 AWS Systems Manager API 호출 로깅](monitoring-cloudtrail-logs.md) 섹션을 참조하세요.
+ **AWS Security Hub CSPM** - Patch Manager에서 패치 규정 준수 데이터를 AWS Security Hub CSPM로 보낼 수 있습니다. Security Hub CSPM에서는 우선순위가 높은 보안 알림 및 규정 준수 상태를 포괄적으로 파악할 수 있습니다. 또한 플릿의 패치 상태를 모니터링합니다. 자세한 내용은 [Patch Manager와 AWS Security Hub CSPM 통합](patch-manager-security-hub-integration.md) 섹션을 참조하세요.
+ **AWS Config** - Patch Manager 대시보드에서 Amazon EC2 인스턴스 관리 데이터를 볼 수 있도록 AWS Config에서 기록을 설정합니다. 자세한 내용은 [패치 대시보드 요약 보기](patch-manager-view-dashboard-summaries.md) 섹션을 참조하세요.
**Topics**
+ [Patch Manager가 조직에 주는 이점은 무엇인가요?](#how-can-patch-manager-benefit-my-organization)
+ [Patch Manager는 누가 사용해야 하나요?](#who-should-use-patch-manager)
+ [Patch Manager의 주요 기능은 무엇입니까?](#what-are-the-main-features-of-patch-manager)
+ [Patch Manager에서 규정 준수란 무엇인가요?](#patch-manager-definition-of-compliance)
+ [주요 구성 요소](#primary-components)
+ [Quick Setup의 패치 정책 구성](patch-manager-policies.md)
+ [Patch Manager 필수 조건](patch-manager-prerequisites.md)
+ [Patch Manager 작업 작동 방식](patch-manager-patching-operations.md)
+ [관리형 노드 패치를 위한 SSM 명령 문서](patch-manager-ssm-documents.md)
+ [패치 기준](patch-manager-patch-baselines.md)
+ [Amazon Linux 2 관리형 노드에서 Kernel Live Patching 사용](patch-manager-kernel-live-patching.md)
+ [콘솔을 사용하여 Patch Manager 리소스 및 규정 준수 작업](patch-manager-console.md)
+ [AWS CLI를 사용하여 Patch Manager 리소스 작업](patch-manager-cli-commands.md)
+ [AWS Systems Manager Patch Manager 자습서](patch-manager-tutorials.md)
+ [Patch Manager 문제 해결](patch-manager-troubleshooting.md)
# Quick Setup의 패치 정책 구성
AWS에서는 *패치 정책*을 사용하여 조직 및 AWS 계정에 대한 패치 적용을 구성할 것을 권장합니다. 패치 정책은 2022년 12월 Patch Manager에 도입되었습니다.
패치 정책은 AWS Systems Manager의 도구인 Quick Setup을 사용하여 설정하는 구성입니다. 패치 정책은 이전 패치 구성 방법에서 제공되는 것보다 더 광범위하고 중앙 집중화된 패치 작업 제어 기능을 제공합니다. 패치 정책은 지원되는 Linux, macOS 및 Windows Server 버전을 포함하여 [Patch Manager에서 지원되는 모든 운영 체제](patch-manager-prerequisites.md#pm-prereqs)에서 사용할 수 있습니다. 정책 생성에 대한 자세한 지침은 [Quick Setup 패치 정책을 사용한 조직 내 인스턴스에 대한 패치 적용 구성](quick-setup-patch-manager.md) 섹션을 참조하세요.
## 패치 정책의 주요 기능
노드를 패치하는 다른 방법을 사용하는 대신, 패치 정책을 사용하여 다음과 같은 주요 기능의 이점을 활용하세요.
+ **단일 설정** - 유지 관리 기간 또는 State Manager 연결을 사용하여 패치 작업을 설정하려면 Systems Manager 콘솔의 여러 부분에서 여러 태스크를 수행해야 할 수 있습니다. 패치 정책을 사용하면 모든 패치 작업을 단일 마법사에서 설정할 수 있습니다.
+ **다중 계정/다중 리전 지원** - Patch Manager에서 유지 관리 기간, State Manager 연결 또는 **Patch now**(지금 패치) 기능을 사용하면 단일 AWS 계정-AWS 리전 쌍의 관리형 노드에 대해서만 작업을 수행할 수 있습니다. 따라서 여러 계정과 여러 리전을 사용하는 경우, 각 계정-리전 쌍에서 설정 작업을 수행해야 하므로 설정 및 유지 관리 작업에 시간이 많이 소요될 수 있습니다. 반면, AWS Organizations를 사용하면 모든 AWS 리전에서 모든 AWS 계정의 모든 관리형 노드에 적용되는 단일 패치 정책을 설정할 수 있습니다. 또는 원하는 경우 계정 및 리전에서 선택한 일부 조직 단위(OU)에만 패치 정책을 적용할 수도 있습니다. 원하는 경우 패치 정책을 단일 로컬 계정에도 적용할 수 있습니다.
+ **조직 차원의 설치 지원** - Quick Setup의 기존 호스트 관리 구성 옵션은 관리형 노드의 패치 규정 준수를 매일 검사할 수 있도록 지원합니다. 하지만 이 검사은 미리 정해진 시간에 수행되며, 패치 규정 준수 정보만 제공합니다. 패치 설치 작업은 수행되지 않습니다. 패치 정책을 사용하여 다양한 스캐닝 및 설치 일정을 지정할 수 있습니다. 사용자 지정 CRON 또는 Rate 표현식을 사용하여 이들 작업의 빈도와 시간을 선택할 수도 있습니다. 예를 들어 매일 누락된 패치를 검사하여 정기적으로 업데이트되는 규정 준수 정보를 제공할 수 있습니다. 하지만 원치 않는 가동 중단을 방지하기 위해, 설치 일정을 일주일에 한 번으로 정할 수도 있습니다.
+ **간소화된 패치 기준선 선택** - 패치 정책에도 패치 기준선이 포함되어 있으며, 패치 기준선이 구성되는 방식에는 변화가 없습니다. 단, 패치 정책을 생성하거나 업데이트할 때, 각 운영 체제(OS) 유형에 사용할 AWS 관리형 기준선 또는 사용자 지정 기준선을 단일 목록에서 선택할 수 있습니다. 태스크마다 각 OS 유형에 대한 기본 기준선을 지정할 필요는 없습니다.
**참고**
패치 정책 실행을 기반으로 패치 작업을 수행할 때는 `AWS-RunPatchBaseline` SSM 문서를 사용합니다. 자세한 내용은 [패치를 위한 SSM 명령 문서: `AWS-RunPatchBaseline`](patch-manager-aws-runpatchbaseline.md) 섹션을 참조하세요.
**관련 정보**
[Systems Manager Quick Setup을 사용하여 중앙에서 AWS 조직 전체에 패치 적용 작업 배포](https://aws.amazon.com/blogs/mt/centrally-deploy-patching-operations-across-your-aws-organization-using-systems-manager-quick-setup/)(AWS 클라우드 운영 및 마이그레이션 블로그)
## 패치 정책을 사용할 경우의 기타 차이점
이전 패치 구성 방법 대신 패치 정책을 사용할 때 주의해야 할 몇 가지 다른 차이점은 다음과 같습니다.
+ **패치 그룹이 필요 없음** - 이전 패치 작업에서는 패치 그룹에 속하도록 여러 노드에 태그를 지정한 다음, 해당 패치 그룹에 사용할 패치 기준선을 지정할 수 있었습니다. 패치 그룹이 없으면 Patch Manager가 OS 유형의 현재 기본 패치 기준선을 사용하여 인스턴스에 패치를 적용했습니다. 패치 정책을 사용하면 더 이상 패치 그룹을 설정하고 유지 관리할 필요가 없습니다.
**참고**
2022년 12월 22일에 패치 정책 지원이 릴리스될 당시에 패치 그룹을 사용하고 있지 않았던 계정-리전 페어에 대해서는 콘솔에서 패치 그룹 기능이 지원되지 않습니다. 이 날짜 이전에 패치 그룹을 사용하기 시작한 계정-리전 페어에서는 패치 그룹 기능을 계속 사용할 수 있습니다.
+ **'Configure patching(패치 구성)' 페이지 제거** - 패치 정책이 릴리스되기 전에는 **Configure patching**(패치 구성) 페이지에서 패치를 적용할 노드, 패치 일정 및 패치 작업에 대한 기본값을 지정할 수 있었습니다. 이 페이지가 Patch Manager에서 제거되었습니다. 이들 옵션은 이제 패치 정책에서 지정합니다.
+ **'Patch now(지금 패치)' 지원 안 함** - 온디맨드로 노드를 패치 기능은 여전히 한 번에 하나의 AWS 리전-AWS 계정 쌍으로 제한됩니다. 자세한 내용은 [관리형 노드 온디맨드 패치](patch-manager-patch-now-on-demand.md) 섹션을 참조하세요.
+ **패치 정책 및 규정 준수 정보** - 패치 정책 구성에 따라 관리형 노드의 규정 준수를 검사하면, 규정 준수 데이터가 사용자에게 제공됩니다. 다른 규정 준수 검사 방법과 동일한 방식으로 데이터를 이 보고 관련 작업을 수행할 수 있습니다. 전체 조직 또는 여러 조직 단위에 대해 패치 정책을 설정할 수 있지만, 규정 준수 정보는 각 AWS 계정-AWS 리전 쌍에 대해 개별적으로 보고됩니다. 자세한 내용은 [패치 규정 준수 보고서 작업](patch-manager-compliance-reports.md) 섹션을 참조하세요.
+ **연결 규정 준수 상태 및 패치 정책**-Quick Setup 패치 정책이 적용되는 관리형 노드의 패치 상태는 해당 노드의 State Manager 연결 실행 상태와 일치합니다. 연결 실행 상태가 `Compliant`인 경우 관리형 노드의 패치 상태가 `Compliant`로 표시됩니다. 연결 실행 상태가 `Non-Compliant`인 경우 관리형 노드의 패치 상태가 `Non-Compliant`로 표시됩니다.
## 패치 정책이 지원되는 AWS 리전
Quick Setup의 패치 정책 구성은 현재 다음 리전에서 지원됩니다.
+ 미국 동부(오하이오)(us-east-2)
+ 미국 동부(버지니아 북부)(us-east-1)
+ 미국 서부(캘리포니아 북부)(us-west-1)
+ 미국 서부(오리건)(us-west-2)
+ 아시아 태평양(뭄바이)(ap-south-1)
+ 아시아 태평양(서울)(ap-northeast-2)
+ 아시아 태평양(싱가포르)(ap-southeast-1)
+ 아시아 태평양(시드니)(ap-southeast-2)
+ 아시아 태평양(도쿄)(ap-northeast-1)
+ 캐나다(중부)(ca-central-1)
+ 유럽(프랑크푸르트)(eu-central-1)
+ 유럽(아일랜드)(eu-west-1)
+ 유럽(런던) (eu-west-2)
+ 유럽(파리) (eu-west-3)
+ 유럽(스톡홀름)(eu-north-1)
+ 남아메리카(상파울루)(sa-east-1)
# Patch Manager 필수 조건
AWS Systems Manager의 도구인 Patch Manager를 사용하기 전에 필수 사전 조건을 충족했는지 확인합니다.
**Topics**
+ [SSM Agent 버전](#agent-versions)
+ [Python 버전](#python-version)
+ [추가 패키지 요구 사항](#additional-package-requirements)
+ [패치 소스에 대한 연결](#source-connectivity)
+ [S3 엔드포인트 액세스](#s3-endpoint-access)
+ [로컬에 패치를 설치할 수 있는 권한](#local-installation-permissions)
+ [Patch Manager에 지원되는 운영 체제](#supported-os)
## SSM Agent 버전
버전 2.0.834.0 이상의 SSM Agent가 Patch Manager로 관리형 노드에서 실행 중이어야 합니다.
**참고**
SSM Agent의 업데이트된 버전은 Systems Manager에 새 도구가 추가되거나 기존 도구가 업데이트될 때마다 릴리스됩니다. 최신 버전의 에이전트를 사용하지 못하면 관리형 노드에서 다양한 Systems Manager 도구를 사용하지 못할 수 있습니다. 이러한 이유로 시스템의 SSM Agent 상태를 최신 상태로 유지하는 프로세스를 자동화하는 것이 좋습니다. 자세한 내용은 [SSM Agent 업데이트 자동화](ssm-agent-automatic-updates.md) 섹션을 참조하세요. SSM Agent 업데이트에 대해 알림을 수신하려면 GitHub에서 [SSM Agent 릴리스 정보](https://github.com/aws/amazon-ssm-agent/blob/mainline/RELEASENOTES.md) 페이지를 구독합니다.
## Python 버전
macOS 및 대부분의 리눅스 운영체제(OS)의 경우 Patch Manager에서는 현재 Python 버전 2.6\$13.12이 지원됩니다. AlmaLinux, Debian Server 및 Ubuntu Server OS에는 지원되는 Python 3 버전(3.0\$13.12)이 필요합니다.
## 추가 패키지 요구 사항
DNF 기반 운영 체제의 경우 리포지토리 정보 및 패치 파일의 압축을 풀려면 `zstd`, `xz` 및 `unzip` 유틸리티가 필요할 수 있습니다. DNF 기반 운영 체제에는 Amazon Linux 2023, Red Hat Enterprise Linux 8 이상 버전, Oracle Linux 8 이상 버전, Rocky Linux, AlmaLinux 및 CentOS 8 이상 버전이 포함됩니다. `unzip`이 없어 `No such file or directory: b'zstd'`, `No such file or directory: b'unxz'`, 패치 적용 실패 등과 유사한 오류가 표시되는 경우 이 유틸리티를 설치해야 합니다. `zstd`, `xz` 및 `unzip`은 다음을 실행하여 설치할 수 있습니다.
```
dnf install zstd xz unzip
```
## 패치 소스에 대한 연결
관리형 노드가 인터넷에 직접 연결되어 있지 않고 VPC 엔드포인트가 있는 Amazon Virtual Private Cloud(Amazon VPC)를 사용하는 경우 노드가 소스 패치 리포지토리에 액세스할 수 있는지 확인해야 합니다. Linux 노드에서 패치 업데이트는 일반적으로 노드에 구성된 원격 리포지토리에서 다운로드됩니다. 따라서, 노드에서 리포지토리에 연결할 수 있어야 패치를 적용할 수 있습니다. 자세한 내용은 [보안 패치 선택 방법](patch-manager-selecting-patches.md) 섹션을 참조하세요.
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`로 설정됩니다.
**CentOS Stream: `EnableNonSecurity` 플래그 활성화**
CentOS Stream 노드는 업데이트 알림의 개념을 사용하는 패키지 관리자로 DNF를 사용합니다. 업데이트 알림은 단순히 특정 문제를 수정하는 패키지 모음입니다.
하지만 CentOS Stream 기본 리포지토리는 업데이트 알림으로 구성되지 않습니다. 따라서 Patch Manager는 기본 CentOS Stream 리포지토리에서 패키지를 탐지하지 못합니다. Patch Manager가 업데이트 알림에 포함되지 않은 패키지를 처리하게 하려면 패치 기준 규칙에서 `EnableNonSecurity` 플래그를 설정해야 합니다.
**Windows Server: Windows Update 카탈로그 또는 Windows Server Update Services(WSUS)에 연결되었는지 확인합니다.**
Windows Server 관리형 노드는 Windows 업데이트 카탈로그 또는 Windows Server Update Services(WSUS)에 연결할 수 있어야 합니다. 노드가 인터넷 게이트웨이, NAT 게이트웨이 또는 NAT 인스턴스를 통해 [Microsoft Update 카탈로그](https://www.catalog.update.microsoft.com/home.aspx)에 연결되어 있는지 확인합니다. WSUS를 사용하는 경우 노드가 환경의 WSUS 서버에 연결되어 있는지 확인합니다. 자세한 내용은 [문제: 관리형 노드에 Windows 업데이트 카탈로그 또는 WSUS에 대한 액세스 권한이 없습니다.](patch-manager-troubleshooting.md#patch-manager-troubleshooting-instance-access) 섹션을 참조하세요.
## S3 엔드포인트 액세스
관리형 노드가 사설 네트워크에서 작동하는지 아니면 퍼블릭 네트워크에서 작동하는지에 관계없이 필수 AWS 관리형 Amazon Simple Storage Service(Amazon S3) 버킷에 액세스하지 못하면 패치 작업이 실패합니다. 관리형 노드가 액세스할 수 있어야 하는 S3 버킷에 대한 자세한 내용은 [AWS 관리형 S3 버킷과 SSM Agent 통신](ssm-agent-technical-details.md#ssm-agent-minimum-s3-permissions) 및 [Systems Manager용 VPC 엔드포인트를 사용하여 EC2 인스턴스의 보안 개선](setup-create-vpc.md) 섹션을 참조하세요.
## 로컬에 패치를 설치할 수 있는 권한
Windows Server 및 Linux 운영 체제에서 Patch Manager는 패치를 설치하기 위해 각각 관리자 및 루트 사용자 계정을 수임합니다.
그러나 macOS에서 Brew 및 Brew Cask의 경우 Homebrew는 루트 사용자로 실행되는 명령을 지원하지 않습니다. 결과적으로 Patch Manager는 Homebrew 디렉터리의 소유자 또는 Homebrew 디렉터리의 소유자 그룹에 속하는 유효한 사용자로 Homebrew 명령을 쿼리하고 실행합니다. 따라서 패치를 설치하려면 `homebrew` 디렉터리의 소유자에게 `/usr/local` 디렉터리에 대한 재귀 소유자 권한도 필요합니다.
**작은 정보**
다음 명령은 지정된 사용자에게 이 권한을 제공합니다.
```
sudo chown -R $USER:admin /usr/local
```
## Patch Manager에 지원되는 운영 체제
Patch Manager 도구가 다른 Systems Manager 도구가 지원했던 동일한 운영 체제 버전을 모두 지원하지 않을 수 있습니다. Systems Manager에서 지원되는 운영 체제의 전체 목록은 [Systems Manager가 지원되는 운영 체제](operating-systems-and-machine-types.md#prereqs-operating-systems) 섹션을 참조하세요. 따라서 Patch Manager에서 사용하려는 관리형 노드에 다음 표에 나열된 운영 체제 중 하나를 실행 중인지 확인합니다.
**참고**
Patch Manager는 Windows용 Windows Update 카탈로그 및 Windows Server 업데이트 서비스와 같이 관리형 노드에 구성된 패치 리포지토리에 의존하여 설치 가능한 패치를 검색합니다. 따라서 EOL(For End of Life) 운영 체제 버전의 경우 사용 가능한 새 업데이트가 없으면 Patch Manager에서 새 업데이트를 보고하지 못할 수 있습니다. 이는 Linux 배포 관리자, Microsoft 또는 Apple에서 새 업데이트를 릴리스하지 않았기 때문이거나 관리형 노드에 새 업데이트에 액세스할 수 있는 적절한 라이선스가 없기 때문일 수 있습니다.
수명 종료(EOL)에 도달한 OS 버전은 사용하지 않는 것이 좋습니다. AWS를 포함한 OS 공급업체는 일반적으로 EOL에 도달한 버전의 보안 패치 또는 기타 업데이트를 제공하지 않습니다. EOL 시스템을 계속 사용하면 보안 수정 사항과 기타 운영 문제를 포함한 업그레이드를 적용할 수 없는 위험이 크게 증가합니다. AWS는 EOL에 도달한 OS 버전에서 Systems Manager 기능을 테스트하지 않습니다.
Patch Manager는 관리형 노드에서 사용 가능한 패치를 기준으로 규정 준수 상태를 보고합니다. 따라서 인스턴스가 EOL 운영 체제를 실행 중이고 사용 가능한 업데이트가 없는 경우 패치 작업에 대해 구성된 패치 기준에 따라 Patch Manager가 노드를 규정 준수 상태로 보고할 수 있습니다.
| 운영 체제 | 세부 정보 |
| --- | --- |
| Linux | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/systems-manager/latest/userguide/patch-manager-prerequisites.html) |
| macOS | *macOS는 Amazon EC2 인스턴스에서만 지원됩니다.* 13.0\$113.7(Ventura) 14*.x*(Sonoma) 15*.x*(Sequoia) macOS OS 업데이트 Patch Manager는 13.1\$113.2과 같은 macOS를 위한 운영 체제(OS) 업데이트 또는 업그레이드를 지원하지 않습니다. macOS에서 OS 버전 업데이트를 수행하려면 Apple에 내장된 OS 업그레이드 메커니즘을 사용하는 것이 좋습니다. 자세한 내용은 Apple 개발자 문서 웹사이트의 [장치 관리](https://developer.apple.com/documentation/devicemanagement)를 참조하세요. Homebrew 지원 Patch Manager에서는 오픈 소스 소프트웨어 패키지 관리 시스템인 Homebrew를 다음 기본 설치 위치 중 하나에 설치해야 합니다. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/systems-manager/latest/userguide/patch-manager-prerequisites.html) Homebrew가 설치되지 않은 경우 Patch Manager를 사용한 패치 적용 작업이 올바르게 작동하지 않습니다. 리전 지원 일부 AWS 리전에서는 macOS가 지원되지 않습니다. macOS용 Amazon EC2 지원에 대한 자세한 내용은 *Amazon EC2 사용 설명서*의 [Amazon EC2 Mac 인스턴스](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-mac-instances.html)를 참조하세요. macOS 엣지 디바이스 AWS IoT Greengrass 코어 디바이스용 SSM Agent는 macOS에서 지원되지 않습니다. macOS 엣지 디바이스를 패치하기 위해 Patch Manager를 사용할 수 없습니다. |
| Windows | R2 버전을 포함하여 Windows Server 2012부터 Windows Server 2025까지 해당됩니다. AWS IoT Greengrass 코어 디바이스용 SSM Agent는 Windows 10에서 지원되지 않습니다. Windows 10 엣지 디바이스를 패치하기 위해 Patch Manager를 사용할 수 없습니다. Windows Server 2012 및 2012 R2 지원 Windows Server 2012 및 2012 R2는 2023년 10월 10일 이후로 지원이 종료되었습니다. 이러한 버전과 함께 Patch Manager를 사용하려면 Microsoft의 확장 보안 업데이트(ESU)도 사용하는 것이 좋습니다. 자세한 내용은 Microsoft 웹 사이트에서 [Windows Server 2012 및 2012 R2에 대한 지원 종료](https://learn.microsoft.com/en-us/lifecycle/announcements/windows-server-2012-r2-end-of-support)를 참조하세요. |
# Patch Manager 작업 작동 방식
이 섹션에서는 AWS Systems Manager의 도구인 Patch Manager가 설치할 패치를 결정하는 방법 및 지원되는 각 운영 체제에 이러한 패치가 설치되는 방법에 대한 기술적인 정보를 제공합니다. Linux 운영 체제의 경우 관리형 노드에 구성된 기본 소스 리포지토리 이외의 패치를 위해 사용자 지정 패치 기준에서 소스 리포지토리를 지정하는 방법에 대한 정보도 제공합니다. 이 단원에서는 Linux 운영 체제의 서로 다른 배포에서 패치 기준 규칙이 작동하는 방법에 대해서도 설명합니다.
**참고**
다음 항목의 정보는 패치 작업에 사용하는 구성 방법 또는 유형에 관계없이 적용됩니다.
Quick Setup에서 구성된 패치 정책
Quick Setup에서 구성된 호스트 관리 옵션
패치 `Scan` 또는 `Install` 태스크를 실행하기 위한 유지 관리 기간
온디맨드 **Patch now**(지금 패치) 작업
**Topics**
+ [패키지 릴리스 날짜 및 업데이트 날짜 계산 방법](patch-manager-release-dates.md)
+ [보안 패치 선택 방법](patch-manager-selecting-patches.md)
+ [대체 패치 소스 리포지토리를 지정하는 방법(Linux)](patch-manager-alternative-source-repository.md)
+ [패치 설치 방법](patch-manager-installing-patches.md)
+ [Linux 기반 시스템에서 패치 기준 규칙 사용 방법](patch-manager-linux-rules.md)
+ [Linux 및 Windows Server 간 패치 작업 차이점](patch-manager-windows-and-linux-differences.md)
# 패키지 릴리스 날짜 및 업데이트 날짜 계산 방법
**중요**
이 페이지의 정보는 Amazon Elastic Compute Cloud(Amazon EC2) 인스턴스용 Amazon Linux 2 및 Amazon Linux 2023 운영 체제(OS)에 적용됩니다. Amazon Web Services에서 이러한 OS 유형에 대한 패키지를 생성하고 유지 관리합니다. 다른 운영 체제의 제조업체가 패키지와 리포지토리를 관리하는 방법은 릴리스 날짜와 업데이트 날짜를 계산하는 방법에 영향을 줍니다. Amazon Linux 2 및 Amazon Linux 2023(예: Red Hat Enterprise Linux) 이외의 OS의 경우 패키지 업데이트 및 유지 관리 방법에 대한 자세한 내용은 제조업체 설명서를 참조하세요.
생성하는 [사용자 지정 패치 기준선](patch-manager-predefined-and-custom-patch-baselines.md#patch-manager-baselines-custom) 설정에서 대부분의 OS 유형에 대해 특정 일 수 후 설치를 위해 패치가 자동 승인되도록 지정할 수 있습니다. AWS는 7일의 자동 승인 날짜를 포함하는 미리 정의된 여러 패치 기준선을 제공합니다.
자동 승인 지연은 패치가 릴리스된 후 패치 적용을 위해 자동 승인되기까지 대기하는 일 수입니다. 예를 들어, `CriticalUpdates` 분류를 사용하여 규칙을 생성하고 7일 자동 승인 지연으로 구성합니다. 결과적으로 릴리스 날짜 또는 마지막 업데이트 날짜가 7월 7일인 새로운 중요 패치는 7월 14일에 자동으로 승인됩니다.
Amazon Linux 2 및 Amazon Linux 2023에서 자동 승인 지연으로 인한 예기치 않은 결과를 방지하려면 릴리스 날짜와 업데이트 날짜가 계산되는 방식을 이해하는 것이 중요합니다.
**참고**
Amazon Linux 2 또는 Amazon Linux 2023 리포지토리가 패키지 릴리스 날짜 정보를 제공하지 않는 경우 Patch Manager는 패키지의 빌드 시간을 자동 승인 날짜 사양 날짜로 사용합니다. 패키지의 빌드 시간을 확인할 수 없는 경우 Patch Manager는 기본 날짜인 1970년 1월 1일을 사용합니다. 이에 따라 Patch Manager에서 1970년 1월 1일 이후 모든 날짜에 대한 패치를 승인하도록 구성된 패치 기준의 자동 승인 날짜 사양이 무시됩니다.
대부분의 경우 패치가 설치되기 전 자동 승인 대기 시간은 `Release Date` 값이 아닌 `updateinfo.xml`의 `Updated Date` 값에서 계산됩니다. 다음은 이러한 날짜 계산에 대한 중요한 세부 정보입니다.
+ `Release Date`는 공지가 릴리스된 날짜입니다. 이는 아직 패키지가 관련 리포지토리에서 반드시 사용 가능함을 의미하지는 않습니다.
+ `Update Date`는 공지가 업데이트된 마지막 날짜입니다. 공지 업데이트는 텍스트 또는 설명 업데이트와 같은 작은 것을 나타낼 수 있습니다. 이는 아직 패키지가 해당 날짜부터 릴리스되었거나 관련 리포지토리에서 반드시 사용 가능함을 의미하지는 않습니다.
이는 패키지의 `Update Date` 값이 7월 7일 수 있지만 7월 13일(예)까지 설치할 수 없음을 의미합니다. 이 경우 7일 자동 승인 지연을 지정하는 패치 기준선이 7월 14일에 `Install` 작업에서 실행된다고 가정합니다. `Update Date` 값이 실행 날짜 7일 전이므로 패키지의 패치 및 업데이트는 7월 14일에 설치됩니다. 패키지가 실제 설치 가능한 상태가 되고 단 하루가 지났는데 설치가 진행됩니다.
+ 운영 체제 또는 애플리케이션 패치를 포함하는 패키지는 최초 릴리스 후 두 번 이상 업데이트할 수 있습니다.
+ 패키지는 AWS 관리형 리포지토리로 릴리스될 수 있지만 나중에 문제가 발견되면 롤백됩니다.
일부 패치 작업에서는 이러한 요인이 중요하지 않을 수 있습니다. 예를 들어, 심각도 값이 `Low` 및 `Medium`이고 분류가 `Recommended`인 패치를 설치하도록 패치 기준선이 구성된 경우 자동 승인 지연은 작업에 거의 영향을 미치지 않을 수 있습니다.
그러나 중요하거나 심각도가 높은 패치의 타이밍이 더 중요한 경우 패치 설치 시기를 더 세밀하게 제어할 수 있습니다. 이를 수행하는 데 권장되는 방법은 관리 노드에서 작업을 패치하기 위해 기본 리포지토리 대신 대체 패치 소스 리포지토리를 사용하는 것입니다.
사용자 지정 패치 기준을 만들 때 대체 패치 소스 리포지토리를 지정할 수 있습니다. 각 사용자 지정 패치 기준에서 지원되는 최대 20개의 Linux 운영 체제 버전에 대해 패치 소스 구성을 지정할 수 있습니다. 자세한 내용은 [대체 패치 소스 리포지토리를 지정하는 방법(Linux)](patch-manager-alternative-source-repository.md) 섹션을 참조하세요.
# 보안 패치 선택 방법
AWS Systems Manager의 도구인 Patch Manager의 주 기능은 관리형 노드에 운영 체제 보안 관련 업데이트를 설치하는 것입니다. 기본적으로 Patch Manager는 사용 가능한 모든 패치를 설치하기 보다는 보안에 관련된 소규모의 패치만 설치합니다.
기본적으로 Patch Manager는 패키지 리포지토리에서 더 이상 사용되지 않는 것으로 표시된 패키지를 다른 패키지 업데이트 설치에 이 대체가 필요하지 않은 한 다른 이름의 대체 패키지로 대체하지 않습니다. 대신 패키지를 업데이트하는 명령의 경우 Patch Manager는 설치되었지만 더 이상 사용되지 않는 패키지에 대해 누락된 업데이트만 보고하고 설치합니다. 더 이상 사용되지 않는 패키지를 교체하려면 일반적으로 기존 패키지를 제거하고 대체 패키지를 설치해야 하기 때문입니다. 더 이상 사용되지 않는 패키지를 교체하면 의도하지 않은 주요 변경 사항이나 추가 기능이 발생할 수 있습니다.
이 동작은 기능 업그레이드가 아닌 보안 업데이트에 초점을 맞춘 YUM 및 DNF의 `update-minimal` 명령과 일치합니다. 자세한 내용은 [패치 설치 방법](patch-manager-installing-patches.md) 섹션을 참조하세요.
**참고**
패치 기준 규칙에서 `ApproveUntilDate` 파라미터 또는 `ApproveAfterDays` 파라미터를 사용하는 경우 Patch Manager는 협정 세계시(UTC)를 사용하여 패치 릴리스 날짜를 평가합니다.
예를 들어 `ApproveUntilDate`의 경우 `2025-11-16` 같은 날짜를 지정하면 `2025-11-16T00:00:00Z` \$1 `2025-11-16T23:59:59Z`에 릴리스된 패치가 승인됩니다.
관리형 노드에서 네이티브 패키지 관리자가 표시하는 패치 릴리스 날짜는 시스템의 현지 시간대에 따라 다른 시간을 표시할 수 있지만 Patch Manager는 승인 계산에 항상 UTC 날짜/시간을 사용합니다. 이를 통해 공식 보안 권고 웹 사이트에 게시된 패치 릴리스 날짜와 일관성을 보장할 수 있습니다.
패치의 심각도 수준을 보고하는 Linux 기반 운영 체제 유형의 경우 Patch Manager는 업데이트 알림 또는 개별 패치에 대해 소프트웨어 게시자가 보고한 심각도 수준을 사용합니다. Patch Manager는 CVSS([Common Vulnerability Scoring System](https://www.first.org/cvss/))와 같은 서드 파티 소스 또는 NVD([National Vulnerability Database](https://nvd.nist.gov/vuln))에서 발표한 지표에서 심각도 수준을 도출하지 않습니다.
**참고**
Patch Manager에서 지원하는 모든 Linux 기반 시스템에서 관리형 노드에 대해 구성된 다른 소스 리포지토리를 선택하여 비보안 업데이트를 설치할 수도 있습니다. 자세한 내용은 [대체 패치 소스 리포지토리를 지정하는 방법(Linux)](patch-manager-alternative-source-repository.md) 섹션을 참조하세요.
Patch Manager가 운영 체제에 맞는 보안 패치를 선택하는 방법을 알아보려면 다음 탭에서 선택합니다.
------
#### [ Amazon Linux 2 and Amazon Linux 2023 ]
사전 구성된 리포지토리는 Amazon Linux 2에서 Amazon Linux 2023와 다르게 처리됩니다.
Amazon Linux 2의 경우 Systems Manager 패치 기준 서비스는 관리형 노드의 사전 구성된 리포지토리를 사용합니다. 하나의 노드에는 보통 다음과 같은 두 개의 사전 구성된 리포지토리가 있습니다.
**Amazon Linux 2**
+ **리포지토리 ID**: `amzn2-core/2/architecture`
**리포지토리 이름**: `Amazon Linux 2 core repository`
+ **리포지토리 ID**: `amzn2extra-docker/2/architecture`
**리포지토리 이름**: `Amazon Extras repo for docker`
**참고**
*아키텍처*는 x86\$164 또는 (Graviton 프로세서의 경우) aarch64일 수 있습니다.
Amazon Linux 2023(AL2023) 인스턴스를 생성할 때 AL2023 버전에서 사용 가능한 업데이트와 사용자가 선택한 특정 AMI 업데이트가 포함됩니다. AL2023 인스턴스에는 시작 시 심각하고 중요한 추가 보안 업데이트가 자동으로 수신되지 않습니다. 그 대신에 기본적으로 켜져 있는 AL2023의 *버전 관리형 리포지토리를 통한 결정적 업그레이드* 기능을 사용하여 특정한 니즈를 충족하는 업데이트를 일정에 따라 적용할 수 있습니다. 자세한 내용은 **Amazon Linux 2023 사용 설명서의 [버전 지정 리포지토리를 통한 결정적 업그레이드](https://docs.aws.amazon.com/linux/al2023/ug/deterministic-upgrades.html)를 참조하세요.
AL2023의 사전 구성된 리포지토리는 다음과 같습니다.
+ **리포지토리 ID**: `amazonlinux`
**리포지토리 이름**: Amazon Linux 2023 리포지토리
Amazon Linux 2023(평가판 릴리스)의 사전 구성된 리포지토리는 패키지 업데이트의 *잠긴 버전*에 연결됩니다. 새로운 Amazon Linux 2023용 Amazon Machine Images(AMIs)가 릴리스될 때 특정 버전으로 잠겨 있습니다. 패치 업데이트의 경우 Patch Manager는 패치 업데이트 리포지토리의 최신 잠긴 버전을 검색한 다음 잠긴 버전의 콘텐츠를 기반으로 관리 노드의 패키지를 업데이트합니다.
**패키지 관리자**
Amazon Linux 2 관리형 노드에서는 Yum을 패키지 관리자로 사용합니다. Amazon Linux 2023은 DNF를 패키지 관리자로 사용합니다.
두 패키지 관리자 모두 *업데이트 알림* 개념을 `updateinfo.xml`이라는 파일로 사용합니다. 업데이트 알림은 단순히 특정 문제를 수정하는 패키지 모음입니다. Patch Manager는 업데이트 알림에 있는 모든 패키지를 보안으로 간주합니다. 개별 패키지에는 분류 또는 심각도 수준이 할당되지 않습니다. 따라서 Patch Manager는 업데이트 알림의 속성을 관련 패키지에 할당합니다.
**참고**
**패치 기준선 생성** 페이지에서 **비보안 업데이트 포함** 확인란을 선택하면 `updateinfo.xml` 파일로 분류되지 않은 패키지(또는 적절한 형식의 분류, 심각도 및 날짜 값이 없는 파일이 포함된 패키지)가 미리 필터링된 패치 목록에 포함될 수 있습니다. 그러나 패치가 적용되려면 패치가 사용자 지정 패치 기준 규칙을 충족해야 합니다.
**비보안 업데이트 포함** 옵션에 대한 자세한 내용은 [패치 설치 방법](patch-manager-installing-patches.md) 및 [Linux 기반 시스템에서 패치 기준 규칙 사용 방법](patch-manager-linux-rules.md)의 내용을 참조하세요.
------
#### [ CentOS Stream ]
CentOS Stream에서 Systems Manager 패치 기준 서비스가 관리형 노드에 있는 사전 구성된 리포지토리를 사용합니다. 다음 목록에는 가상의 CentOS 9.2 Amazon Machine Image(AMI)에 대한 예가 나와 있습니다.
+ **리포지토리 ID**: `example-centos-9.2-base`
**리포지토리 이름**: `Example CentOS-9.2 - Base`
+ **리포지토리 ID**: `example-centos-9.2-extras`
**리포지토리 이름**: `Example CentOS-9.2 - Extras`
+ **리포지토리 ID**: `example-centos-9.2-updates`
**리포지토리 이름**: `Example CentOS-9.2 - Updates`
+ **리포지토리 ID**: `example-centos-9.x-examplerepo`
**리포지토리 이름**: `Example CentOS-9.x – Example Repo Packages`
**참고**
모든 업데이트는 관리형 노드에 구성되어 있는 원격 리포지토리로부터 다운로드됩니다. 따라서, 패치 적용을 수행할 수 있도록 리포지토리에 연결하려면 인터넷에 대한 아웃바운드 액세스 권한이 노드에 있어야 합니다.
CentOS Stream 노드는 DNF를 패키지 관리자로 사용합니다. 패키지 관리자는 업데이트 알림 개념을 사용합니다. 업데이트 알림은 단순히 특정 문제를 수정하는 패키지 모음입니다.
하지만 CentOS Stream 기본 리포지토리는 업데이트 알림으로 구성되지 않습니다. 따라서 Patch Manager는 기본 CentOS Stream 리포지토리에서 패키지를 탐지하지 못합니다. Patch Manager가 업데이트 알림에 포함되지 않은 패키지를 처리하게 하려면 패치 기준 규칙에서 `EnableNonSecurity` 플래그를 설정해야 합니다.
**참고**
CentOS Stream 업데이트 알림이 지원됩니다. 업데이트 알림을 포함하는 리포지토리는 시작 후 다운로드할 수 있습니다.
------
#### [ Debian 서버 ]
Debian Server의 경우 Systems Manager 패치 기준 서비스가 인스턴스에 있는 사전 구성된 리포지토리를 사용합니다. 사용 가능한 패키지 업그레이드의 업데이트된 목록을 가져오기 위해 3개의 사전 구성된 리포지토리가 사용됩니다. 이를 위해, Systems Manager는 `sudo apt-get update` 명령과 동등한 명령을 수행합니다.
그런 다음 패키지는 `debian-security codename` 리포지토리에서 필터링됩니다. 즉, 각 Debian Server 버전에서 Patch Manager는 다음과 같이 해당 버전의 관련 리포지토리에 속하는 업그레이드만 식별합니다.
+ Debian Server 11: `debian-security bullseye`
+ Debian Server 12: `debian-security bookworm`
------
#### [ Oracle Linux ]
Oracle Linux에서 Systems Manager 패치 기준 서비스가 관리형 노드에 있는 사전 구성된 리포지토리를 사용합니다. 하나의 노드에는 보통 다음과 같은 두 개의 사전 구성된 리포지토리가 있습니다.
**Oracle Linux 7**:
+ **리포지토리 ID**: `ol7_UEKR5/x86_64`
**리포지토리 이름**: `Latest Unbreakable Enterprise Kernel Release 5 for Oracle Linux 7Server (x86_64)`
+ **리포지토리 ID**: `ol7_latest/x86_64`
**리포지토리 이름**: `Oracle Linux 7Server Latest (x86_64)`
**Oracle Linux 8**:
+ **리포지토리 ID**: `ol8_baseos_latest`
**리포지토리 이름**: `Oracle Linux 8 BaseOS Latest (x86_64)`
+ **리포지토리 ID**: `ol8_appstream`
**리포지토리 이름**: `Oracle Linux 8 Application Stream (x86_64)`
+ **리포지토리 ID**: `ol8_UEKR6`
**리포지토리 이름**: `Latest Unbreakable Enterprise Kernel Release 6 for Oracle Linux 8 (x86_64)`
**Oracle Linux 9**:
+ **리포지토리 ID**: `ol9_baseos_latest`
**리포지토리 이름**: `Oracle Linux 9 BaseOS Latest (x86_64)`
+ **리포지토리 ID**: `ol9_appstream`
**리포지토리 이름**: `Oracle Linux 9 Application Stream Packages(x86_64)`
+ **리포지토리 ID**: `ol9_UEKR7`
**리포지토리 이름**: `Oracle Linux UEK Release 7 (x86_64)`
**참고**
모든 업데이트는 관리형 노드에 구성되어 있는 원격 리포지토리로부터 다운로드됩니다. 따라서, 패치 적용을 수행할 수 있도록 리포지토리에 연결하려면 인터넷에 대한 아웃바운드 액세스 권한이 노드에 있어야 합니다.
Oracle Linux 관리형 노드는 Yum을 패키지 관리자로 사용하며, Yum은 업데이트 알림의 개념을 `updateinfo.xml`이라는 파일로 사용합니다. 업데이트 알림은 단순히 특정 문제를 수정하는 패키지 모음입니다. 개별 패키지에는 분류 또는 심각도 수준이 할당되지 않습니다. 따라서 Patch Manager는 업데이트 알림의 속성을 관련 패키지에 할당하고 패치 기준에 지정된 분류 필터를 기반으로 패키지를 설치합니다.
**참고**
**패치 기준선 생성** 페이지에서 **비보안 업데이트 포함** 확인란을 선택하면 `updateinfo.xml` 파일로 분류되지 않은 패키지(또는 적절한 형식의 분류, 심각도 및 날짜 값이 없는 파일이 포함된 패키지)가 미리 필터링된 패치 목록에 포함될 수 있습니다. 그러나 패치가 적용되려면 패치가 사용자 지정 패치 기준 규칙을 충족해야 합니다.
------
#### [ AlmaLinux, RHEL, and Rocky Linux ]
AlmaLinux, Red Hat Enterprise Linux 및 Rocky Linux의 Systems Manager 패치 기준선 서비스에서는 관리형 노드의 사전 구성된 리포지토리(repos)를 사용합니다. 하나의 노드에는 보통 다음과 같은 세 개의 사전 구성된 리포지토리가 있습니다.
모든 업데이트는 관리형 노드에 구성되어 있는 원격 리포지토리로부터 다운로드됩니다. 따라서, 패치 적용을 수행할 수 있도록 리포지토리에 연결하려면 인터넷에 대한 아웃바운드 액세스 권한이 노드에 있어야 합니다.
**참고**
**패치 기준선 생성** 페이지에서 **비보안 업데이트 포함** 확인란을 선택하면 `updateinfo.xml` 파일로 분류되지 않은 패키지(또는 적절한 형식의 분류, 심각도 및 날짜 값이 없는 파일이 포함된 패키지)가 미리 필터링된 패치 목록에 포함될 수 있습니다. 그러나 패치가 적용되려면 패치가 사용자 지정 패치 기준 규칙을 충족해야 합니다.
Red Hat Enterprise Linux 7 관리형 노드에서는 Yum을 패키지 관리자로 사용합니다. AlmaLinux, Red Hat Enterprise Linux 8 및 Rocky Linux 관리형 노드에서는 DNF를 패키지 관리자로 사용합니다. 두 패키지 관리자 모두 업데이트 알림 개념을 `updateinfo.xml`이라는 파일로 사용합니다. 업데이트 알림은 단순히 특정 문제를 수정하는 패키지 모음입니다. 개별 패키지에는 분류 또는 심각도 수준이 할당되지 않습니다. 따라서 Patch Manager는 업데이트 알림의 속성을 관련 패키지에 할당하고 패치 기준에 지정된 분류 필터를 기반으로 패키지를 설치합니다.
RHEL 7
다음 리포지토리 ID는 RHUI 2와 연결되어 있습니다. RHUI 3는 2019년 12월에 출시되었으며 Yum 리포지토리 ID에 대한 다른 이름 지정 체계를 도입했습니다. 관리형 노드를 생성하는 RHEL-7 AMI에 따라 명령을 업데이트해야 할 수도 있습니다. 자세한 내용은 *Red Hat Customer Portal*의 [Repository IDs for RHEL 7 in AWS Have Changed](https://access.redhat.com/articles/4599971)를 참조하세요.
+ **리포지토리 ID**: `rhui-REGION-client-config-server-7/x86_64`
**리포지토리 이름**: `Red Hat Update Infrastructure 2.0 Client Configuration Server 7`
+ **리포지토리 ID**: `rhui-REGION-rhel-server-releases/7Server/x86_64`
**리포지토리 이름**: `Red Hat Enterprise Linux Server 7 (RPMs)`
+ **리포지토리 ID**: `rhui-REGION-rhel-server-rh-common/7Server/x86_64`
**리포지토리 이름**: `Red Hat Enterprise Linux Server 7 RH Common (RPMs)`
AlmaLinux, 8 RHEL 8 및 Rocky Linux 8
+ **리포지토리 ID**: `rhel-8-appstream-rhui-rpms`
**리포지토리 이름**: `Red Hat Enterprise Linux 8 for x86_64 - AppStream from RHUI (RPMs)`
+ **리포지토리 ID**: `rhel-8-baseos-rhui-rpms`
**리포지토리 이름**: `Red Hat Enterprise Linux 8 for x86_64 - BaseOS from RHUI (RPMs)`
+ **리포지토리 ID**: `rhui-client-config-server-8`
**리포지토리 이름**: `Red Hat Update Infrastructure 3 Client Configuration Server 8`
AlmaLinux 9, RHEL 9 및 Rocky Linux 9
+ **리포지토리 ID**: `rhel-9-appstream-rhui-rpms`
**리포지토리 이름**: `Red Hat Enterprise Linux 9 for x86_64 - AppStream from RHUI (RPMs)`
+ **리포지토리 ID**: `rhel-9-baseos-rhui-rpms`
**리포지토리 이름**: `Red Hat Enterprise Linux 9 for x86_64 - BaseOS from RHUI (RPMs)`
+ **리포지토리 ID**: `rhui-client-config-server-9`
**리포지토리 이름**: `Red Hat Enterprise Linux 9 Client Configuration`
------
#### [ SLES ]
SUSE Linux Enterprise Server(SLES) 관리형 노드에 있는 ZYPP 라이브러리는 다음 위치에서 사용 가능한 패치 목록(패키지 모음)을 가져옵니다.
+ 리포지토리 목록: `etc/zypp/repos.d/*`
+ 패키지 정보: `/var/cache/zypp/raw/*`
SLES 관리형 노드는 Zypper를 패키지 관리자로 사용하며, Zypper는 패치 개념을 사용합니다. 패치는 단순히 특정 문제를 수정하는 패키지 모음입니다. Patch Manager는 패치에서 참조하는 모든 패키지를 보안 관련으로 처리합니다. 개별 패키지에는 분류 또는 심각도가 지정되지 않았기 때문에 Patch Manager는 해당 패키지를 이들이 속한 패치의 속성에 할당합니다.
------
#### [ Ubuntu 서버 ]
Ubuntu Server에서 Systems Manager 패치 기준 서비스가 관리형 노드에 있는 사전 구성된 리포지토리를 사용합니다. 사용 가능한 패키지 업그레이드의 업데이트된 목록을 가져오기 위해 3개의 사전 구성된 리포지토리가 사용됩니다. 이를 위해, Systems Manager는 `sudo apt-get update` 명령과 동등한 명령을 수행합니다.
그런 다음 `codename-security` 리포지토리에서 패키지가 필터링됩니다. 여기서 코드명은 Ubuntu Server 14의 경우 `trusty`와 같이 릴리스 버전마다 고유합니다. Patch Manager는 이러한 리포지토리의 일부인 업그레이드만 식별합니다.
+ Ubuntu Server 16.04 LTS: `xenial-security`
+ Ubuntu Server 18.04 LTS: `bionic-security`
+ Ubuntu Server 20.04 LTS: `focal-security`
+ Ubuntu Server 22.04 LTS(`jammy-security`)
+ Ubuntu Server 24.04 LTS(`noble-security`)
+ Ubuntu Server 25.04(`plucky-security`)
------
#### [ Windows Server ]
Microsoft Windows 운영 체제에서 Patch Manager는 Microsoft가 Microsoft Update에 게시하고 WSUS(Windows Server Update Services)에서 자동으로 사용할 수 있는 사용 가능한 업데이트 목록을 검색합니다.
**참고**
Patch Manager는 Patch Manager에 지원되는 Windows Server 운영 체제 버전에 대해서만 패치를 제공합니다. 예를 들어 Patch Manager는 Windows RT 패치에 사용할 수 없습니다.
Patch Manager는 모든 AWS 리전에서 새로운 업데이트를 지속적으로 모니터링합니다. 사용 가능한 업데이트 목록은 최소한 하루에 한 번씩 리전별로 갱신됩니다. Microsoft의 패치 정보가 처리되면 Patch Manager는 해당 패치 목록에서 최신 업데이트로 대체된 업데이트를 제거합니다. 그러므로 최신 업데이트만 표시되며 설치 시 사용 가능한 상태가 됩니다. 예를 들어 `KB4012214`가 `KB3135456`을 대체하는 경우 `KB4012214`만 Patch Manager에서 업데이트로 사용됩니다.
마찬가지로 Patch Manager는 패치 작업 중에 관리형 노드에서 사용할 수 있는 패치만 설치할 수 있습니다. 기본적으로 Windows Server 2019 및 Windows Server 2022는 이후 업데이트로 대체되는 업데이트를 제거합니다. 따라서 Windows Server 패치 기준의 `ApproveUntilDate` 파라미터를 사용하지만 `ApproveUntilDate` 파라미터에서 선택한 날짜가 최신 패치 날짜 **이전인 경우 다음과 같은 시나리오가 발생합니다.
+ 대체된 패치는 노드에서 제거되므로 Patch Manager를 사용하여 설치할 수 없습니다.
+ 최신 대체 패치가 노드에 있지만 `ApproveUntilDate` 파라미터의 지정된 날짜에 따라 아직 설치가 승인되지 않았습니다.
즉, 관리형 노드는 이전 달의 중요한 패치가 설치되지 않았더라도 Systems Manager 운영 측면에서 규정을 준수합니다. `ApproveAfterDays` 파라미터를 사용할 때도 이와 동일한 시나리오가 발생할 수 있습니다. Microsoft의 대체 패치 동작으로 인해 Microsoft에서 제공하는 최신 패치가 `ApproveAfterDays`의 일수가 경과하기 전에 릴리스되는 경우 Windows Server에 대한 패치가 설치되지 않도록 숫자(일반적으로 30일 이상)를 설정할 수 있습니다. 관리형 노드에서 대체된 패치를 사용할 수 있도록 Windows 그룹 정책 개체(GPO) 설정을 수정한 경우에는 이 시스템 동작이 적용되지 않습니다.
**참고**
경우에 따라 Microsoft는 업데이트된 날짜와 시간을 지정하지 않는 애플리케이션에 대한 패치를 릴리스합니다. 이 경우 업데이트된 `01/01/1970`의 날짜 및 시간은 기본적으로 제공됩니다.
------
# 대체 패치 소스 리포지토리를 지정하는 방법(Linux)
패치 작업에 대해 관리형 노드에 구성된 기본 리포지토리를 사용하는 경우 AWS Systems Manager의 도구인 Patch Manager는 보안 관련 패치를 찾거나 설치합니다. 이는 Patch Manager의 기본 동작입니다. Patch Manager가 보안 패치를 선택 및 설치하는 방법에 대한 모든 정보는 [보안 패치 선택 방법](patch-manager-selecting-patches.md) 섹션을 참조하세요.
그러나 Linux 시스템에서는 Patch Manager를 사용하여 보안과 관련되지 않은 패치 또는 관리형 노드에 구성된 기본 소스 리포지토리가 아닌 다른 소스 리포지토리에 있는 패치를 설치할 수도 있습니다. 사용자 지정 패치 기준을 만들 때 대체 패치 소스 리포지토리를 지정할 수 있습니다. 각 사용자 지정 패치 기준에서 지원되는 최대 20개의 Linux 운영 체제 버전에 대해 패치 소스 구성을 지정할 수 있습니다.
예를 들어, Ubuntu Server 플릿에 Ubuntu Server 25.04 관리형 노드가 모두 포함된다고 가정해 보겠습니다. 이 경우, 동일한 사용자 지정 패치 기준으로 각 버전에 대체 리포지토리를 지정할 수 있습니다. 각 버전에 대해 이름을 입력하고, 운영 체제 버전 유형(제품)을 지정하고, 리포지토리 구성을 제공합니다. 또한 지원되는 모든 운영 체제 버전에 적용되는 단일의 대체 소스 리포지토리를 지정할 수도 있습니다.
**참고**
관리형 노드에 대한 대체 패치 리포지토리를 지정하는 사용자 정의 패치 기준을 실행해도 해당 리포지토리가 운영체제의 새 기본 리포지토리로 지정되지 않습니다. 패치 작업이 완료된 후 이전에 노드의 운영체제에서 기본값으로 구성된 리포지토리는 기본값으로 유지됩니다.
이 옵션 사용에 대한 예제 시나리오 목록은 이 주제 후반부의 [대체 패치 소스 리포지토리의 사용 샘플](#patch-manager-alternative-source-repository-examples) 섹션을 참조하세요.
기본 및 사용자 지정 패치 기준에 대한 자세한 내용은 [미리 정의된 사용자 지정 패치 기준](patch-manager-predefined-and-custom-patch-baselines.md) 섹션을 참조하세요.
**예: 콘솔 사용**
Systems Manager 콘솔에서 작업 중인 경우 대체 패치 소스 리포지토리를 지정하려면 **패치 기준 생성(Create patch baseline)** 페이지의 **패치 소스(Patch sources)** 섹션을 사용합니다. **패치 소스(Patch sources)** 옵션 사용에 대한 자세한 내용은 [Linux를 위한 사용자 지정 패치 기준 생성](patch-manager-create-a-patch-baseline-for-linux.md) 섹션을 참조하세요.
**예: AWS CLI 사용**
AWS Command Line Interface(AWS CLI)와 함께 `--sources` 옵션을 사용하는 예는 [다른 OS 버전에 대한 사용자 지정 리포지토리가 있는 패치 기준 생성](patch-manager-cli-commands.md#patch-manager-cli-commands-create-patch-baseline-mult-sources) 섹션을 참조하세요.
**Topics**
+ [대체 리포지토리에 대한 중요 고려 사항](#alt-source-repository-important)
+ [대체 패치 소스 리포지토리의 사용 샘플](#patch-manager-alternative-source-repository-examples)
## 대체 리포지토리에 대한 중요 고려 사항
대체 패치 리포지토리를 사용하여 대치 전략을 계획할 경우 다음 사항에 유의하세요.
**리포지토리 업데이트 확인 적용(YUM 및 DNF)**
리포지토리에 연결할 수 없는 경우 Linux 배포의 패키지 관리자에 대한 기본 구성을 설정하여 연결할 수 없는 패키지 리포지토리를 건너뛸 수 있습니다. 리포지토리 업데이트 확인을 적용하려면 `skip_if_unavailable=False`를 리포지토리 구성에 추가합니다.
`skip_if_available` 옵션에 대한 자세한 내용은 [패치 소스에 대한 연결](patch-manager-prerequisites.md#source-connectivity) 섹션을 참조하세요.
**지정된 리포지토리만 패치를 적용하는 데 사용됩니다.**
대체 리포지토리를 지정하는 것이 *추가* 리포지토리를 지정하는 것을 의미하지는 않습니다. 관리형 노드에 대해 기본으로 구성되지 않은 리포지토리를 지정할 수 있습니다. 하지만 업데이트를 적용하려면 기본 리포지토리도 대체 패치 소스 구성의 일부로 지정해야 합니다.
예를 들어 Amazon Linux 2 관리형 노드의 기본 리포지토리는 `amzn2-core` 및 `amzn2extra-docker`입니다. 패치 적용 작업에 EPEL(Extra Packages for Enterprise Linux) 리포지토리를 포함하려면 세 리포지토리를 모두 대체 리포지토리로 지정해야 합니다.
**참고**
관리형 노드에 대한 대체 패치 리포지토리를 지정하는 사용자 정의 패치 기준을 실행해도 해당 리포지토리가 운영체제의 새 기본 리포지토리로 지정되지 않습니다. 패치 작업이 완료된 후 이전에 노드의 운영체제에서 기본값으로 구성된 리포지토리는 기본값으로 유지됩니다.
**YUM 기반 배포에 대한 패치 동작은 updateinfo.xml 매니페스트에 따라 다릅니다.**
YUM 기반 배포(예: Amazon Linux 2 또는 Red Hat Enterprise Linux)에 대해 대체 패치 리포지토리를 지정할 경우 패치 동작은 완전하고 올바른 형식의 `updateinfo.xml` 파일 형태의 업데이트 매니페스트가 리포지토리에 포함되는지 여부에 따라 달라집니다. 이 파일은 다양한 패키지의 릴리스 날짜, 분류 및 심각도를 지정합니다. 패치 동작에 영향을 주는 항목은 다음과 같습니다.
+ **분류(Classification)**와 **심각도(Severity)**를 기준으로 필터링하지만 `updateinfo.xml`에 지정되어 있지 않은 경우 해당 패키지는 필터에 포함되지 않습니다. 즉, `updateinfo.xml` 파일이 없는 패키지는 패치에 포함되지 않습니다.
+ **ApprovalAfterDays**를 기준으로 필터링하지만 패키지 릴리스 날짜가 Unix Epoch 형식이 아니거나 릴리스 날짜가 지정되지 않은 경우 해당 패키지는 필터에 포함되지 않습니다.
+ **패치 기준선 생성** 페이지에서 **비보안 업데이트 포함** 확인란을 선택한 경우는 예외입니다. 이 경우 `updateinfo.xml` 파일이 없거나 적절하게 서식 지정된 **분류(Classification)**, **보안(Severity)** 및 **날짜(Date)** 값이 없는 이 파일을 포함하는 패키지는 사전 필터링된 패치 목록에 포함*됩니다*. 이 경우에도 설치를 위한 다른 패치 기준 규칙 요건을 충족해야 합니다.
## 대체 패치 소스 리포지토리의 사용 샘플
**예제 1 - Ubuntu Server에 대한 비보안 업데이트**
이미 Patch Manager를 사용하여 AWS에서 제공하는 미리 정의된 패치 기준인 `AWS-UbuntuDefaultPatchBaseline`을 사용하는 Ubuntu Server 관리형 노드의 플릿에 보안 패치를 설치했습니다. 이 기본 패치 기준을 기반으로 하는 새 패치 기준을 생성하되, 승인 규칙에서 기본 배포의 일부인 비보안 관련 업데이트도 설치하도록 지정할 수 있습니다. 이 패치 기준이 노드에 대해 실행될 때 보안 및 비보안 문제에 대한 패치가 적용됩니다. 또한 기준에 대해 지정하는 패치 예외의 비보안 패치를 승인할 수도 있습니다.
**예제 2 - Ubuntu Server의 PPA(Personal Package Archives)**
Ubuntu Server 관리형 노드가 [Ubuntu의 PPA(Personal Package Archives)](https://launchpad.net/ubuntu/+ppas)를 통해 배포된 소프트웨어를 실행합니다. 이 경우 관리형 노드에 구성한 PPA 리포지토리를 패치 적용 작업에 대한 소스 리포지토리로 지정하는 패치 기준을 생성합니다. 그런 다음 Run Command를 사용하여 노드에서 패치 기준 문서를 실행합니다.
**예제 3 - 지원되는 Amazon Linux 버전의 사내 애플리케이션**
Amazon Linux 관리형 노드에서 산업 규정 준수에 필요한 애플리케이션을 실행해야 합니다. 노드에 이러한 애플리케이션의 리포지토리를 구성하거나, YUM을 사용하여 애플리케이션을 처음 설치한 후 업데이트하거나, 이 새로운 기업 리포지토리를 포함하도록 새 패치 기준을 생성할 수 있습니다. 그런 다음 Run Command를 사용하여 `Scan` 옵션으로 `AWS-RunPatchBaseline` 문서를 실행하여 기업 패키지가 설치된 패키지로 나열되고 관리형 노드에서 최신 상태인지 확인할 수 있습니다. 최신이 아닌 경우 애플리케이션을 업데이트하도록 `Install` 옵션을 사용하여 문서를 다시 실행하면 됩니다.
# 패치 설치 방법
AWS Systems Manager의 도구인 Patch Manager는 운영 체제 내장 패키지 관리자를 사용하여 관리형 노드에 업데이트를 설치합니다. 예를 들어 및 Amazon Linux 2023의 Windows Server 및 `DNF`에서 Windows Update API를 사용합니다. 패치 관리자는 리포지토리 상태, 미러 URL, GPG 확인 및 `skip_if_unavailable`와 같은 옵션 등의 설정을 포함하여 노드의 기존 패키지 관리자 및 리포지토리 구성을 준수합니다.
Patch Manager는 현재 설치된 더 이상 사용되지 않는 패키지를 대체하는 새 패키지를 설치하지 않습니다. (예외: 새 패키지가 설치 중인 다른 패키지 업데이트의 종속성이거나 새 패키지의 이름이 더 이상 사용되지 않는 패키지와 동일합니다.) 대신 Patch Manager는 설치된 패키지에 대해 사용 가능한 업데이트를 보고하고 설치합니다. 이 접근 방식은 한 패키지로 다른 패키지를 교체할 때 발생할 수 있는 예기치 않은 시스템 기능 변경을 방지하는 데 도움이 됩니다.
더 이상 사용되지 않는 패키지를 제거하고 대체 패키지를 설치해야 하는 경우 사용자 지정 스크립트를 사용하거나 Patch Manager의 표준 작업 밖에서 패키지 관리자 명령을 사용해야 할 수 있습니다.
Patch Manager가 운영 체제에 패치를 설치하는 방법을 알아보려면 다음 탭 중 하나를 선택합니다.
------
#### [ Amazon Linux 2 and Amazon Linux 2023 ]
Amazon Linux 2 및 Amazon Linux 2023 관리형 노드에서 패치 설치 워크플로는 다음과 같습니다.
1. `AWS-RunPatchBaseline` 또는 `AWS-RunPatchBaselineAssociation` 문서에 대해 `InstallOverrideList` 파라미터를 사용하여 https URL 또는 Amazon Simple Storage Service(Amazon S3) 경로 스타일 URL을 사용하여 패치 목록을 지정한 경우 나열된 패치가 설치되고 2\$17단계를 건너뜁니다.
1. 패치 기준에 지정된 대로 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters)를 적용하여 추가 처리를 위해 적격 패키지만 유지합니다.
1. 패치 기준에 지정된 대로 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules)를 적용합니다. 각 승인 규칙은 패키지를 승인된 것으로 정의할 수 있습니다.
그러나 승인 규칙은 패치 기준을 생성하거나 마지막으로 업데이트할 때 **비보안 업데이트 포함(Include nonsecurity updates)** 확인란을 선택했는지 여부에 따라 달라집니다.
비보안 업데이트가 제외되면 보안 리포지토리에서 업그레이드가 있는 패키지만 선택할 수 있도록 묵시적인 규칙이 적용됩니다. 패키지마다, 후보 패키지 버전(일반적으로 최신 버전)이 보안 리포지토리에 속해 있어야 합니다.
비보안 업데이트가 포함된 경우 다른 리포지토리의 패치도 고려됩니다.
1. 패치 기준에 지정된 대로 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches)를 적용합니다. 승인된 패치는 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters)를 통해 폐기되었거나 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules)에 지정된 승인 규칙이 이를 승인하지 않더라도 업데이트가 승인됩니다.
1. 패치 기준에 지정된 대로 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches)를 적용합니다. 거부된 패치는 승인된 패치 목록에서 제거되고 적용되지 않습니다.
1. 여러 패치 버전이 승인되는 경우 최신 버전이 적용됩니다.
1. YUM 업데이트 API(Amazon Linux 2) 또는 DNF 업데이트 API(Amazon Linux 2023)는 다음과 같이 승인된 패치에 적용됩니다.
+ AWS에서 제공하는 미리 정의된 기본 패치 기준선의 경우 `updateinfo.xml`에 지정된 패치만 적용됩니다(보안 업데이트만 해당). **비보안 업데이트 포함** 확인란이 선택되지 않았기 때문입니다. 미리 정의된 기준선은 다음과 같은 사용자 지정 기준선과 동일합니다.
+ **비보안 업데이트 포함** 확인란은 선택되지 않음
+ `[Critical, Important]`의 심각도 목록
+ `[Security, Bugfix]`의 분류 목록
Amazon Linux 2의 경우 이 워크플로와 동등한 yum 명령은 다음과 같습니다.
```
sudo yum update-minimal --sec-severity=Critical,Important --bugfix -y
```
Amazon Linux 2023의 경우 이 워크플로와 동등한 dnf 명령은 다음과 같습니다.
```
sudo dnf upgrade-minimal --sec-severity=Critical --sec-severity=Important --bugfix -y
```
**비보안 업데이트 포함** 확인란이 선택된 경우 `updateinfo.xml`에 포함된 패치 및 `updateinfo.xml`에 포함되지 않은 패치가 모두 적용됩니다(보안 및 비보안 업데이트).
Amazon Linux 2의 경우 **비보안 업데이트 포함**이 선택된 기준선에 `[Critical, Important]`의 심각도 목록 및 `[Security, Bugfix]`의 분류 목록이 포함된 경우 이와 동등한 yum 명령은 다음과 같습니다.
```
sudo yum update --security --sec-severity=Critical,Important --bugfix -y
```
Amazon Linux 2023의 경우 이와 동등한 dnf 명령은 다음과 같습니다.
```
sudo dnf upgrade --security --sec-severity=Critical --sec-severity=Important --bugfix -y
```
**참고**
현재 사용되지 않는 패키지를 대체하는 다른 이름의 새 패키지는 `yum` 또는 `dnf` 명령을 Patch Manager 외부에서 실행하는 경우에 설치됩니다. 그러나 동일한 Patch Manager 작업으로는 설치되지 *않습니다*.
**Amazon Linux 2023에 대한 추가 패치 세부 정보**
심각도 수준 '없음' 지원
Amazon Linux 2023는 DNF 패키지 관리자가 인식하는 패치 심각도 수준 `None`도 지원합니다.
심각도 수준 '중간' 지원
Amazon Linux 2023의 경우 `Medium`의 패치 심각도 수준은 일부 외부 리포지토리에 정의될 수 있는 `Moderate`의 심각도와 동일합니다. 패치 기준에 `Medium` 심각도 패치를 포함하면 외부 패치의 `Moderate` 심각도 패치도 인스턴스에 설치됩니다.
API 작업 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_DescribeInstancePatches.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_DescribeInstancePatches.html)를 사용하여 규정 준수 데이터를 쿼리하는 경우 심각도 수준 `Medium`을 필터링하면 심각도 수준이 `Medium` 및 `Moderate`인 패치가 모두 보고됩니다.
Amazon Linux 2023의 전이적 종속 항목 처리
Amazon Linux 2023의 경우 Patch Manager는 동등한 `dnf` 명령이 설치하는 것과는 다른 버전의 전이적 종속 항목을 설치할 수 있습니다. 전이적 종속 항목은 다른 패키지의 요구 사항(종속 항목의 종속 항목)을 충족하기 위해 자동으로 설치되는 패키지입니다.
예를 들어 `dnf upgrade-minimal --security`는 알려진 보안 문제를 해결하는 데 필요한 전이적 종속 항목의 *최소* 버전을 설치하는 반면, Patch Manager는 동일한 전이적 종속 항목의 사용 가능한 **최신 버전을 설치합니다.
1. 업데이트가 설치되어 있는 경우 관리형 노드가 재부팅됩니다. (예외: `AWS-RunPatchBaseline` 문서에서 `RebootOption` 파라미터가 `NoReboot`로 설정되어 있으면 Patch Manager를 실행한 후 관리형 노드가 재부팅되지 않습니다. 자세한 내용은 [파라미터 이름: `RebootOption`](patch-manager-aws-runpatchbaseline.md#patch-manager-aws-runpatchbaseline-parameters-norebootoption) 섹션을 참조하세요.)
**참고**
Linux 배포의 패키지 관리자에 대한 기본 구성을 설정하여 오류 없이 연결할 수 없는 패키지 리포지토리를 건너뛸 수 있습니다. 이러한 경우 관련 패치 적용 작업은 리포지토리에서 업데이트를 설치하지 않고 진행되며 성공적으로 완료됩니다. 리포지토리 업데이트를 적용하려면 `skip_if_unavailable=False`를 리포지토리 구성에 추가합니다.
`skip_if_available` 옵션에 대한 자세한 내용은 [패치 소스에 대한 연결](patch-manager-prerequisites.md#source-connectivity) 섹션을 참조하세요.
------
#### [ CentOS Stream ]
CentOS Stream 관리형 노드에서 패치 설치 워크플로는 다음과 같습니다.
1. `AWS-RunPatchBaseline` 또는 `AWS-RunPatchBaselineAssociation` 문서에 대해 `InstallOverrideList` 파라미터를 사용하여 https URL 또는 Amazon Simple Storage Service(Amazon S3) 경로 스타일 URL을 사용하여 패치 목록을 지정한 경우 나열된 패치가 설치되고 2\$17단계를 건너뜁니다.
패치 기준에 지정된 대로 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters)를 적용하여 추가 처리를 위해 적격 패키지만 유지합니다.
1. 패치 기준에 지정된 대로 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules)를 적용합니다. 각 승인 규칙은 패키지를 승인된 것으로 정의할 수 있습니다.
그러나 승인 규칙은 패치 기준을 생성하거나 마지막으로 업데이트할 때 **비보안 업데이트 포함(Include nonsecurity updates)** 확인란을 선택했는지 여부에 따라 달라집니다.
비보안 업데이트가 제외되면 보안 리포지토리에서 업그레이드가 있는 패키지만 선택할 수 있도록 묵시적인 규칙이 적용됩니다. 패키지마다, 후보 패키지 버전(일반적으로 최신 버전)이 보안 리포지토리에 속해 있어야 합니다.
비보안 업데이트가 포함된 경우 다른 리포지토리의 패치도 고려됩니다.
1. 패치 기준에 지정된 대로 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches)를 적용합니다. 승인된 패치는 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters)를 통해 폐기되었거나 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules)에 지정된 승인 규칙이 이를 승인하지 않더라도 업데이트가 승인됩니다.
1. 패치 기준에 지정된 대로 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches)를 적용합니다. 거부된 패치는 승인된 패치 목록에서 제거되고 적용되지 않습니다.
1. 여러 패치 버전이 승인되는 경우 최신 버전이 적용됩니다.
1. CentOS Stream의 DNF 업데이트가 승인된 패치에 적용됩니다.
**참고**
CentOS Stream의 경우 Patch Manager는 동등한 `dnf` 명령이 설치하는 것과는 다른 버전의 전이적 종속 항목을 설치할 수 있습니다. 전이적 종속 항목은 다른 패키지의 요구 사항(종속 항목의 종속 항목)을 충족하기 위해 자동으로 설치되는 패키지입니다.
예를 들어 `dnf upgrade-minimal ‐‐security`는 알려진 보안 문제를 해결하는 데 필요한 전이적 종속 항목의 *최소* 버전을 설치하는 반면, Patch Manager는 동일한 전이적 종속 항목의 *사용 가능한 최신 버전*을 설치합니다.
1. 업데이트가 설치되어 있는 경우 관리형 노드가 재부팅됩니다. (예외: `AWS-RunPatchBaseline` 문서에서 `RebootOption` 파라미터가 `NoReboot`로 설정되어 있으면 Patch Manager를 실행한 후 관리형 노드가 재부팅되지 않습니다. 자세한 내용은 [파라미터 이름: `RebootOption`](patch-manager-aws-runpatchbaseline.md#patch-manager-aws-runpatchbaseline-parameters-norebootoption) 섹션을 참조하세요.)
------
#### [ Debian 서버 ]
Debian Server 인스턴스에서 패치 설치 워크플로는 다음과 같습니다.
1. `AWS-RunPatchBaseline` 또는 `AWS-RunPatchBaselineAssociation` 문서에 대해 `InstallOverrideList` 파라미터를 사용하여 https URL 또는 Amazon Simple Storage Service(Amazon S3) 경로 스타일 URL을 사용하여 패치 목록을 지정한 경우 나열된 패치가 설치되고 2\$17단계를 건너뜁니다.
1. `python3-apt`(`libapt`에 대한 Python 라이브러리 인터페이스)에 대한 업데이트가 있는 경우 최신 버전으로 업그레이드됩니다. (**Include nonsecurity updates(비보안 업데이트 포함)** 옵션을 선택하지 않은 경우에도 이 비보안 패키지가 업그레이드됩니다.)
1. 패치 기준에 지정된 대로 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters)를 적용하여 추가 처리를 위해 적격 패키지만 유지합니다.
1. 패치 기준에 지정된 대로 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules)를 적용합니다. 각 승인 규칙은 패키지를 승인된 것으로 정의할 수 있습니다.
**참고**
Debian Server에 대한 업데이트 패키지의 릴리스 날짜를 확실히 결정할 수 없으므로 이 운영 체제에서는 자동 승인 옵션이 지원되지 않습니다.
그러나 승인 규칙은 패치 기준을 생성하거나 마지막으로 업데이트할 때 **Include nonsecurity updates(비보안 업데이트 포함)** 확인란을 선택했는지 여부에 따라 달라집니다.
비보안 업데이트가 제외되면 보안 리포지토리에서 업그레이드가 있는 패키지만 선택할 수 있도록 묵시적인 규칙이 적용됩니다. 패키지마다, 후보 패키지 버전(일반적으로 최신 버전)이 보안 리포지토리에 속해 있어야 합니다.
비보안 업데이트가 포함된 경우 다른 리포지토리의 패치도 고려됩니다.
**참고**
Debian Server의 경우 패치 후보 버전은 `debian-security`에 포함된 패치로 제한됩니다.
1. 패치 기준에 지정된 대로 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches)를 적용합니다. 승인된 패치는 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters)를 통해 폐기되었거나 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules)에 지정된 승인 규칙이 이를 승인하지 않더라도 업데이트가 승인됩니다.
1. 패치 기준에 지정된 대로 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches)를 적용합니다. 거부된 패치는 승인된 패치 목록에서 제거되고 적용되지 않습니다.
1. APT 라이브러리가 사용되어 패키지가 업그레이드됩니다.
**참고**
Patch Manager에서는 APT `Pin-Priority` 옵션을 사용하여 패키지에 우선순위를 지정하는 기능을 지원하지 않습니다. Patch Manager에서는 활성화된 모든 리포지토리에서 사용 가능한 업데이트를 집계하고 설치된 각 패키지의 기준과 일치하는 최신 업데이트를 선택합니다.
1. 업데이트가 설치되어 있는 경우 관리형 노드가 재부팅됩니다. (예외: `AWS-RunPatchBaseline` 문서에서 `RebootOption` 파라미터가 `NoReboot`로 설정되어 있으면 Patch Manager를 실행한 후 관리형 노드가 재부팅되지 않습니다. 자세한 내용은 [파라미터 이름: `RebootOption`](patch-manager-aws-runpatchbaseline.md#patch-manager-aws-runpatchbaseline-parameters-norebootoption) 섹션을 참조하세요.)
------
#### [ macOS ]
macOS 관리형 노드에서 패치 설치 워크플로는 다음과 같습니다.
1. `/Library/Receipts/InstallHistory.plist` 속성 목록은 `softwareupdate` 및 `installer` 패키지 관리자를 사용하여 설치 및 업그레이드된 소프트웨어의 레코드입니다. `pkgutil` 명령줄 도구(`installer`용)와 `softwareupdate` 패키지 관리자를 사용하여 CLI 명령을 실행하여 이 목록을 구문 분석합니다.
`installer`의 경우 CLI 명령에 대한 응답에 `package name`, `version`, `volume`, `location` 및 `install-time` 세부 정보가 포함되지만 Patch Manager는 `package name`과 `version`만 사용합니다.
`softwareupdate`의 경우 CLI 명령에 대한 응답에 패키지 이름(`display name`), `version` 및 `date`가 포함되지만 패치 관리자는 패키지 이름과 버전만 사용합니다.
Brew 및 Brew Cask의 경우 Homebrew는 루트 사용자로 실행되는 명령을 지원하지 않습니다. 결과적으로 Patch Manager는 Homebrew 디렉터리의 소유자 또는 Homebrew 디렉터리의 소유자 그룹에 속하는 유효한 사용자로 Homebrew 명령을 쿼리하고 실행합니다. 명령은 `softwareupdate` 및 `installer`와 유사하며 Python 하위 프로세스를 통해 실행되어 패키지 데이터를 수집하고 출력을 구문 분석하여 패키지 이름 및 버전을 식별합니다.
1. 패치 기준에 지정된 대로 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters)를 적용하여 추가 처리를 위해 적격 패키지만 유지합니다.
1. 패치 기준에 지정된 대로 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules)를 적용합니다. 각 승인 규칙은 패키지를 승인된 것으로 정의할 수 있습니다.
1. 패치 기준에 지정된 대로 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches)를 적용합니다. 승인된 패치는 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters)를 통해 폐기되었거나 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules)에 지정된 승인 규칙이 이를 승인하지 않더라도 업데이트가 승인됩니다.
1. 패치 기준에 지정된 대로 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches)를 적용합니다. 거부된 패치는 승인된 패치 목록에서 제거되고 적용되지 않습니다.
1. 여러 패치 버전이 승인되는 경우 최신 버전이 적용됩니다.
1. 관리형 노드에서 적절한 패키지 CLI를 호출하여 다음과 같이 승인된 패치를 처리합니다.
**참고**
`installer`에는 업데이트를 확인하고 설치하는 기능이 없습니다. 따라서 `installer`의 경우 Patch Manager는 설치된 패키지만 보고합니다. 그 결과 `installer` 패키지는 `Missing`으로 보고되지 않습니다.
+ AWS에서 제공하는 미리 정의된 기본 패치 기준선 및 **비보안 업데이트 포함** 확인란이 선택되지 *않은* 사용자 지정 패치 기준선의 경우 보안 업데이트만 적용됩니다.
+ **비보안 업데이트 포함** 확인란이 *선택된* 사용자 지정 패치 기준선의 경우 보안 및 비보안 업데이트가 모두 적용됩니다.
1. 업데이트가 설치되어 있는 경우 관리형 노드가 재부팅됩니다. (예외: `AWS-RunPatchBaseline` 문서에서 `RebootOption` 파라미터가 `NoReboot`로 설정되어 있으면 Patch Manager를 실행한 후 관리형 노드가 재부팅되지 않습니다. 자세한 내용은 [파라미터 이름: `RebootOption`](patch-manager-aws-runpatchbaseline.md#patch-manager-aws-runpatchbaseline-parameters-norebootoption) 섹션을 참조하세요.)
------
#### [ Oracle Linux ]
Oracle Linux 관리형 노드에서 패치 설치 워크플로는 다음과 같습니다.
1. `AWS-RunPatchBaseline` 또는 `AWS-RunPatchBaselineAssociation` 문서에 대해 `InstallOverrideList` 파라미터를 사용하여 https URL 또는 Amazon Simple Storage Service(Amazon S3) 경로 스타일 URL을 사용하여 패치 목록을 지정한 경우 나열된 패치가 설치되고 2\$17단계를 건너뜁니다.
1. 패치 기준에 지정된 대로 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters)를 적용하여 추가 처리를 위해 적격 패키지만 유지합니다.
1. 패치 기준에 지정된 대로 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules)를 적용합니다. 각 승인 규칙은 패키지를 승인된 것으로 정의할 수 있습니다.
그러나 승인 규칙은 패치 기준을 생성하거나 마지막으로 업데이트할 때 **비보안 업데이트 포함(Include nonsecurity updates)** 확인란을 선택했는지 여부에 따라 달라집니다.
비보안 업데이트가 제외되면 보안 리포지토리에서 업그레이드가 있는 패키지만 선택할 수 있도록 묵시적인 규칙이 적용됩니다. 패키지마다, 후보 패키지 버전(일반적으로 최신 버전)이 보안 리포지토리에 속해 있어야 합니다.
비보안 업데이트가 포함된 경우 다른 리포지토리의 패치도 고려됩니다.
1. 패치 기준에 지정된 대로 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches)를 적용합니다. 승인된 패치는 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters)를 통해 폐기되었거나 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules)에 지정된 승인 규칙이 이를 승인하지 않더라도 업데이트가 승인됩니다.
1. 패치 기준에 지정된 대로 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches)를 적용합니다. 거부된 패치는 승인된 패치 목록에서 제거되고 적용되지 않습니다.
1. 여러 패치 버전이 승인되는 경우 최신 버전이 적용됩니다.
1. 버전 7 관리형 노드에서 다음과 같이 YUM 업데이트 API가 승인된 패치에 적용됩니다.
+ AWS에서 제공하는 미리 정의된 기본 패치 기준선 및 **비보안 업데이트 포함** 확인란이 선택되지 *않은* 사용자 지정 패치 기준선의 경우 `updateinfo.xml`에 지정한 패치만 적용됩니다(보안 업데이트만 해당).
이 워크플로와 동등한 YUM 명령은 다음과 같습니다.
```
sudo yum update-minimal --sec-severity=Important,Moderate --bugfix -y
```
+ **비보안 업데이트 포함** 확인란을 *선택한* 사용자 지정 패치 기준선의 경우 `updateinfo.xml`에 포함된 패치 및 `updateinfo.xml`에 포함되지 않은 패치가 모두 적용됩니다(보안 및 비보안 업데이트).
이 워크플로와 동등한 YUM 명령은 다음과 같습니다.
```
sudo yum update --security --bugfix -y
```
버전 8 및 9 관리형 노드에서 다음과 같이 DNF 업데이트 API가 승인된 패치에 적용됩니다.
+ AWS에서 제공하는 미리 정의된 기본 패치 기준선 및 **비보안 업데이트 포함** 확인란이 선택되지 *않은* 사용자 지정 패치 기준선의 경우 `updateinfo.xml`에 지정한 패치만 적용됩니다(보안 업데이트만 해당).
이 워크플로와 동등한 YUM 명령은 다음과 같습니다.
```
sudo dnf upgrade-minimal --security --sec-severity=Moderate --sec-severity=Important
```
**참고**
Oracle Linux의 경우 Patch Manager는 동등한 `dnf` 명령이 설치하는 것과는 다른 버전의 전이적 종속 항목을 설치할 수 있습니다. 전이적 종속 항목은 다른 패키지의 요구 사항(종속 항목의 종속 항목)을 충족하기 위해 자동으로 설치되는 패키지입니다.
예를 들어 `dnf upgrade-minimal --security`는 알려진 보안 문제를 해결하는 데 필요한 전이적 종속 항목의 *최소* 버전을 설치하는 반면, Patch Manager는 동일한 전이적 종속 항목의 *사용 가능한 최신 버전*을 설치합니다.
+ **비보안 업데이트 포함** 확인란을 *선택한* 사용자 지정 패치 기준선의 경우 `updateinfo.xml`에 포함된 패치 및 `updateinfo.xml`에 포함되지 않은 패치가 모두 적용됩니다(보안 및 비보안 업데이트).
이 워크플로와 동등한 YUM 명령은 다음과 같습니다.
```
sudo dnf upgrade --security --bugfix
```
**참고**
현재 사용되지 않는 패키지를 대체하는 다른 이름의 새 패키지는 `yum` 또는 `dnf` 명령을 Patch Manager 외부에서 실행하는 경우에 설치됩니다. 그러나 동일한 Patch Manager 작업으로는 설치되지 *않습니다*.
1. 업데이트가 설치되어 있는 경우 관리형 노드가 재부팅됩니다. (예외: `AWS-RunPatchBaseline` 문서에서 `RebootOption` 파라미터가 `NoReboot`로 설정되어 있으면 Patch Manager를 실행한 후 관리형 노드가 재부팅되지 않습니다. 자세한 내용은 [파라미터 이름: `RebootOption`](patch-manager-aws-runpatchbaseline.md#patch-manager-aws-runpatchbaseline-parameters-norebootoption) 섹션을 참조하세요.)
**참고**
Linux 배포의 패키지 관리자에 대한 기본 구성을 설정하여 오류 없이 연결할 수 없는 패키지 리포지토리를 건너뛸 수 있습니다. 이러한 경우 관련 패치 적용 작업은 리포지토리에서 업데이트를 설치하지 않고 진행되며 성공적으로 완료됩니다. 리포지토리 업데이트를 적용하려면 `skip_if_unavailable=False`를 리포지토리 구성에 추가합니다.
`skip_if_available` 옵션에 대한 자세한 내용은 [패치 소스에 대한 연결](patch-manager-prerequisites.md#source-connectivity) 섹션을 참조하세요.
------
#### [ AlmaLinux, RHEL, and Rocky Linux ]
Red Hat Enterprise Linux 및 Rocky Linux 관리형 노드의 패치 설치 워크플로는 다음과 같습니다.
1. `AWS-RunPatchBaseline` 또는 `AWS-RunPatchBaselineAssociation` 문서에 대해 `InstallOverrideList` 파라미터를 사용하여 https URL 또는 Amazon Simple Storage Service(Amazon S3) 경로 스타일 URL을 사용하여 패치 목록을 지정한 경우 나열된 패치가 설치되고 2\$17단계를 건너뜁니다.
1. 패치 기준에 지정된 대로 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters)를 적용하여 추가 처리를 위해 적격 패키지만 유지합니다.
1. 패치 기준에 지정된 대로 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules)를 적용합니다. 각 승인 규칙은 패키지를 승인된 것으로 정의할 수 있습니다.
그러나 승인 규칙은 패치 기준을 생성하거나 마지막으로 업데이트할 때 **비보안 업데이트 포함(Include nonsecurity updates)** 확인란을 선택했는지 여부에 따라 달라집니다.
비보안 업데이트가 제외되면 보안 리포지토리에서 업그레이드가 있는 패키지만 선택할 수 있도록 묵시적인 규칙이 적용됩니다. 패키지마다, 후보 패키지 버전(일반적으로 최신 버전)이 보안 리포지토리에 속해 있어야 합니다.
비보안 업데이트가 포함된 경우 다른 리포지토리의 패치도 고려됩니다.
1. 패치 기준에 지정된 대로 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches)를 적용합니다. 승인된 패치는 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters)를 통해 폐기되었거나 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules)에 지정된 승인 규칙이 이를 승인하지 않더라도 업데이트가 승인됩니다.
1. 패치 기준에 지정된 대로 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches)를 적용합니다. 거부된 패치는 승인된 패치 목록에서 제거되고 적용되지 않습니다.
1. 여러 패치 버전이 승인되는 경우 최신 버전이 적용됩니다.
1. YUM 업데이트 API(RHEL 7의 경우) 또는 DNF 업데이트 API(AlmaLinux 8 및 9, RHEL 8, 9 및 10, Rocky Linux 8 및 9의 경우)는 다음 규칙에 따라 승인된 패치에 적용됩니다.
**시나리오 1: 비보안 업데이트 제외**
+ **적용 대상**: AWS에서 제공하는 사전 정의된 기본 패치 기준 및 사용자 지정 패치 기준.
+ **비보안 업데이트 포함** 확인란: 선택하지 *않음*.
+ **패치 적용**: `updateinfo.xml`(보안 업데이트만 해당)에 지정된 패치는 패치 기준 구성과 일치하고 구성된 리포지토리에서 찾을 수 있는 *경우에만* 적용됩니다.
경우에 따라 `updateinfo.xml`에 지정된 패치를 구성된 리포지토리에서 더 이상 사용하지 못할 수 있습니다. 구성된 리포지토리에는 일반적으로 모든 이전 업데이트의 누적 롤업인 최신 버전의 패치만 있지만 최신 버전은 패치 기준 규칙과 일치하지 않을 수 있으며 패치 적용 작업에서 생략됩니다.
+ **명령**: RHEL 7의 경우 이 워크플로와 동등한 yum 명령은 다음과 같습니다.
```
sudo yum update-minimal --sec-severity=Critical,Important --bugfix -y
```
AlmaLinux, RHEL 8 및 Rocky Linux의 경우 이 워크플로와 동등한 dnf 명령은 다음과 같습니다.
```
sudo dnf update-minimal --sec-severity=Critical --bugfix -y ; \
sudo dnf update-minimal --sec-severity=Important --bugfix -y
```
**참고**
AlmaLinux, RHEL 및 Rocky LinuxRocky Linux의 경우 Patch Manager는 동등한 `dnf` 명령이 설치하는 것과는 다른 버전의 전이적 종속 항목을 설치할 수 있습니다. 전이적 종속 항목은 다른 패키지의 요구 사항(종속 항목의 종속 항목)을 충족하기 위해 자동으로 설치되는 패키지입니다.
예를 들어 `dnf upgrade-minimal --security`는 알려진 보안 문제를 해결하는 데 필요한 전이적 종속 항목의 *최소* 버전을 설치하는 반면, Patch Manager는 동일한 전이적 종속 항목의 *사용 가능한 최신 버전*을 설치합니다.
**시나리오 2: 비보안 업데이트 포함**
+ **적용 대상**: 사용자 지정 패치 기준.
+ **비보안 업데이트 포함** 확인란: 선택.
+ **패치 적용**: `updateinfo.xml`에 있는 패치*와* `updateinfo.xml`에 없는 패치가 적용됩니다(보안 및 비보안 업데이트).
+ **명령**: RHEL 7의 경우 이 워크플로와 동등한 yum 명령은 다음과 같습니다.
```
sudo yum update --security --bugfix -y
```
AlmaLinux 8 및 9, RHEL 8 및 9 Rocky Linux 8 및 9의 경우 이 워크플로와 동등한 dnf 명령은 다음과 같습니다.
```
sudo dnf update --security --bugfix -y
```
**참고**
현재 사용되지 않는 패키지를 대체하는 다른 이름의 새 패키지는 `yum` 또는 `dnf` 명령을 Patch Manager 외부에서 실행하는 경우에 설치됩니다. 그러나 동일한 Patch Manager 작업으로는 설치되지 *않습니다*.
1. 업데이트가 설치되어 있는 경우 관리형 노드가 재부팅됩니다. (예외: `AWS-RunPatchBaseline` 문서에서 `RebootOption` 파라미터가 `NoReboot`로 설정되어 있으면 Patch Manager를 실행한 후 관리형 노드가 재부팅되지 않습니다. 자세한 내용은 [파라미터 이름: `RebootOption`](patch-manager-aws-runpatchbaseline.md#patch-manager-aws-runpatchbaseline-parameters-norebootoption) 섹션을 참조하세요.)
**참고**
Linux 배포의 패키지 관리자에 대한 기본 구성을 설정하여 오류 없이 연결할 수 없는 패키지 리포지토리를 건너뛸 수 있습니다. 이러한 경우 관련 패치 적용 작업은 리포지토리에서 업데이트를 설치하지 않고 진행되며 성공적으로 완료됩니다. 리포지토리 업데이트를 적용하려면 `skip_if_unavailable=False`를 리포지토리 구성에 추가합니다.
`skip_if_available` 옵션에 대한 자세한 내용은 [패치 소스에 대한 연결](patch-manager-prerequisites.md#source-connectivity) 섹션을 참조하세요.
------
#### [ SLES ]
:SUSE Linux Enterprise Server(SLES) 관리형 노드, 패치 설치 워크플로는 다음과 같습니다.
1. `AWS-RunPatchBaseline` 또는 `AWS-RunPatchBaselineAssociation` 문서에 대해 `InstallOverrideList` 파라미터를 사용하여 https URL 또는 Amazon Simple Storage Service(Amazon S3) 경로 스타일 URL을 사용하여 패치 목록을 지정한 경우 나열된 패치가 설치되고 2\$17단계를 건너뜁니다.
1. 패치 기준에 지정된 대로 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters)를 적용하여 추가 처리를 위해 적격 패키지만 유지합니다.
1. 패치 기준에 지정된 대로 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules)를 적용합니다. 각 승인 규칙은 패키지를 승인된 것으로 정의할 수 있습니다.
그러나 승인 규칙은 패치 기준을 생성하거나 마지막으로 업데이트할 때 **비보안 업데이트 포함(Include nonsecurity updates)** 확인란을 선택했는지 여부에 따라 달라집니다.
비보안 업데이트가 제외되면 보안 리포지토리에서 업그레이드가 있는 패키지만 선택할 수 있도록 묵시적인 규칙이 적용됩니다. 패키지마다, 후보 패키지 버전(일반적으로 최신 버전)이 보안 리포지토리에 속해 있어야 합니다.
비보안 업데이트가 포함된 경우 다른 리포지토리의 패치도 고려됩니다.
1. 패치 기준에 지정된 대로 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches)를 적용합니다. 승인된 패치는 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters)를 통해 폐기되었거나 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules)에 지정된 승인 규칙이 이를 승인하지 않더라도 업데이트가 승인됩니다.
1. 패치 기준에 지정된 대로 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches)를 적용합니다. 거부된 패치는 승인된 패치 목록에서 제거되고 적용되지 않습니다.
1. 여러 패치 버전이 승인되는 경우 최신 버전이 적용됩니다.
1. Zypper 업데이트 API가 승인된 패치에 적용됩니다.
1. 업데이트가 설치되어 있는 경우 관리형 노드가 재부팅됩니다. (예외: `AWS-RunPatchBaseline` 문서에서 `RebootOption` 파라미터가 `NoReboot`로 설정되어 있으면 Patch Manager를 실행한 후 관리형 노드가 재부팅되지 않습니다. 자세한 내용은 [파라미터 이름: `RebootOption`](patch-manager-aws-runpatchbaseline.md#patch-manager-aws-runpatchbaseline-parameters-norebootoption) 섹션을 참조하세요.)
------
#### [ Ubuntu 서버 ]
Ubuntu Server 관리형 노드에서 패치 설치 워크플로는 다음과 같습니다.
1. `AWS-RunPatchBaseline` 또는 `AWS-RunPatchBaselineAssociation` 문서에 대해 `InstallOverrideList` 파라미터를 사용하여 https URL 또는 Amazon Simple Storage Service(Amazon S3) 경로 스타일 URL을 사용하여 패치 목록을 지정한 경우 나열된 패치가 설치되고 2\$17단계를 건너뜁니다.
1. `python3-apt`(`libapt`에 대한 Python 라이브러리 인터페이스)에 대한 업데이트가 있는 경우 최신 버전으로 업그레이드됩니다. (**Include nonsecurity updates(비보안 업데이트 포함)** 옵션을 선택하지 않은 경우에도 이 비보안 패키지가 업그레이드됩니다.)
1. 패치 기준에 지정된 대로 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters)를 적용하여 추가 처리를 위해 적격 패키지만 유지합니다.
1. 패치 기준에 지정된 대로 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules)를 적용합니다. 각 승인 규칙은 패키지를 승인된 것으로 정의할 수 있습니다.
**참고**
Ubuntu Server에 대한 업데이트 패키지의 릴리스 날짜를 확실히 결정할 수 없으므로 이 운영 체제에서는 자동 승인 옵션이 지원되지 않습니다.
그러나 승인 규칙은 패치 기준을 생성하거나 마지막으로 업데이트할 때 **Include nonsecurity updates(비보안 업데이트 포함)** 확인란을 선택했는지 여부에 따라 달라집니다.
비보안 업데이트가 제외되면 보안 리포지토리에서 업그레이드가 있는 패키지만 선택할 수 있도록 묵시적인 규칙이 적용됩니다. 패키지마다, 후보 패키지 버전(일반적으로 최신 버전)이 보안 리포지토리에 속해 있어야 합니다.
비보안 업데이트가 포함된 경우 다른 리포지토리의 패치도 고려됩니다.
그러나 승인 규칙은 패치 기준을 생성하거나 마지막으로 업데이트할 때 [**비보안 업데이트 포함(Include nonsecurity updates)**] 확인란을 선택했는지 여부에 따라 달라집니다.
**참고**
Ubuntu Server의 각 버전에서 패치 후보 버전은 다음과 같이 해당 버전의 관련 리포지토리에 속하는 패치로 제한됩니다.
Ubuntu Server 16.04 LTS: `xenial-security`
Ubuntu Server 18.04 LTS: `bionic-security`
Ubuntu Server 20.04 LTS): `focal-security`
Ubuntu Server 22.04 LTS: `jammy-security`
Ubuntu Server 24.04 LTS(`noble-security`)
Ubuntu Server 25.04(`plucky-security`)
1. 패치 기준에 지정된 대로 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches)를 적용합니다. 승인된 패치는 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters)를 통해 폐기되었거나 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules)에 지정된 승인 규칙이 이를 승인하지 않더라도 업데이트가 승인됩니다.
1. 패치 기준에 지정된 대로 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches)를 적용합니다. 거부된 패치는 승인된 패치 목록에서 제거되고 적용되지 않습니다.
1. APT 라이브러리가 사용되어 패키지가 업그레이드됩니다.
**참고**
Patch Manager에서는 APT `Pin-Priority` 옵션을 사용하여 패키지에 우선순위를 지정하는 기능을 지원하지 않습니다. Patch Manager에서는 활성화된 모든 리포지토리에서 사용 가능한 업데이트를 집계하고 설치된 각 패키지의 기준과 일치하는 최신 업데이트를 선택합니다.
1. 업데이트가 설치되어 있는 경우 관리형 노드가 재부팅됩니다. (예외: `AWS-RunPatchBaseline` 문서에서 `RebootOption` 파라미터가 `NoReboot`로 설정되어 있으면 Patch Manager를 실행한 후 관리형 노드가 재부팅되지 않습니다. 자세한 내용은 [파라미터 이름: `RebootOption`](patch-manager-aws-runpatchbaseline.md#patch-manager-aws-runpatchbaseline-parameters-norebootoption) 섹션을 참조하세요.)
------
#### [ Windows Server ]
Windows Server 관리형 노드에서 패치 작업이 수행되는 경우 노드가 Systems Manager에서 해당되는 패치 기준 스냅샷을 요청합니다. 이 스냅샷에는 배포하도록 승인된 패치 기준에 있는 사용 가능한 모든 업데이트 목록이 들어 있습니다. 이 업데이트 목록이 Windows 업데이트 API로 전송되며, 여기서 관리형 노드에 적용 가능한 업데이트를 결정하고 필요 시 이를 설치합니다. Windows에서는 사용 가능한 최신 KB 버전만 설치할 수 있습니다. Patch Manager는 KB의 최신 버전 또는 KB의 이전 버전이 적용된 패치 기준과 일치하는 경우 KB의 최신 버전을 설치합니다. 업데이트가 설치되면, 필요한 모든 패치 적용 작업을 완료하기 위해 필요한 만큼 관리형 노드가 재부팅됩니다. (예외: `AWS-RunPatchBaseline` 문서에서 `RebootOption` 파라미터가 `NoReboot`로 설정되어 있으면 Patch Manager를 실행한 후 관리형 노드가 재부팅되지 않습니다. 자세한 내용은 [파라미터 이름: `RebootOption`](patch-manager-aws-runpatchbaseline.md#patch-manager-aws-runpatchbaseline-parameters-norebootoption) 섹션을 참조하세요.) 패치 적용 작업에 대한 정보는 Run Command 요청의 결과에 요약되어 표시됩니다. 추가 로그는 `%PROGRAMDATA%\Amazon\PatchBaselineOperations\Logs` 폴더의 관리형 노드에서 찾을 수 있습니다.
KB를 다운로드하고 설치하는 데 Windows Update API가 사용되므로 Windows Update에 대한 모든 그룹 정책 설정이 유지됩니다. Patch Manager를 사용하는 데는 그룹 정책 설정이 필요하지 않지만, 관리형 노드가 Windows Server Update Services(WSUS) 서버로 향하도록 하는 것과 같은 정의된 설정은 적용됩니다.
**참고**
Patch Manager는 Windows Update API를 사용하여 KB의 다운로드 및 설치를 진행하므로 기본적으로 Windows는 Microsoft의 Windows Update 사이트로부터 모든 KB를 다운로드합니다. 따라서 관리형 노드에서 Microsoft Windows Update 사이트에 연결할 수 있어야 하며, 그렇지 않으면 패치가 적용되지 않습니다. 또는 WSUS 서버가 KB 리포지토리 역할을 수행하도록 구성하고, 관리형 노드가 그룹 정책을 사용하는 해당 WSUS 서버를 대상으로 지정하도록 구성할 수 있습니다.
Patch Manager는 **승인된 패치** 목록 또는 **거부된 패치** 목록이 기준 구성에 포함된 경우와 같이 Windows Server에 대한 사용자 지정 패치 기준을 생성할 때 KB ID를 참조할 수 있습니다. Microsoft Windows Update 또는 WSUS 서버에서 KB ID가 할당된 업데이트만 Patch Manager에 의해 설치됩니다. KB ID가 없는 업데이트는 패치 작업에 포함되지 않습니다.
사용자 지정 패치 기준 생성에 대한 자세한 내용은 다음 주제를 참조하세요.
[Windows Server를 위한 사용자 지정 패치 기준 생성](patch-manager-create-a-patch-baseline-for-windows.md)
[패치 기준 생성(CLI)](patch-manager-create-a-patch-baseline-for-windows.md)
[Windows 운영 체제의 패키지 이름 형식](patch-manager-approved-rejected-package-name-formats.md#patch-manager-approved-rejected-package-name-formats-windows)
------
# Linux 기반 시스템에서 패치 기준 규칙 사용 방법
Linux 배포용 패치 기준의 규칙은 배포 유형에 따라 다르게 작동합니다. Windows Server 관리형 노드의 패치 업데이트와 달리 규칙은 인스턴스의 구성된 리포지토리를 고려하기 위해 각 노드에서 평가됩니다. AWS Systems Manager의 도구인 Patch Manager는 기본 패키지 관리자를 사용하여 패치 기준에서 승인한 패치 설치를 진행합니다.
패치의 심각도 수준을 보고하는 Linux 기반 운영 체제 유형의 경우 Patch Manager는 업데이트 알림 또는 개별 패치에 대해 소프트웨어 게시자가 보고한 심각도 수준을 사용합니다. Patch Manager는 CVSS([Common Vulnerability Scoring System](https://www.first.org/cvss/))와 같은 서드 파티 소스 또는 NVD([National Vulnerability Database](https://nvd.nist.gov/vuln))에서 발표한 지표에서 심각도 수준을 도출하지 않습니다.
**Topics**
+ [Amazon Linux 2 및 Amazon Linux 2023에서 패치 기준 규칙이 작동하는 방식](#linux-rules-amazon-linux)
+ [CentOS Stream에서 패치 기준 규칙 작동 방법](#linux-rules-centos)
+ [Debian Server에서 패치 기준 규칙 작동 방법](#linux-rules-debian)
+ [macOS에서 패치 기준 규칙 작동 방법](#linux-rules-macos)
+ [Oracle Linux에서 패치 기준 규칙 작동 방법](#linux-rules-oracle)
+ [AlmaLinux, RHEL 및 Rocky Linux의 패치 기준선 규칙 작동 방식](#linux-rules-rhel)
+ [SUSE Linux Enterprise Server에서 패치 기준 규칙 작동 방법](#linux-rules-sles)
+ [Ubuntu Server에서 패치 기준 규칙 작동 방법](#linux-rules-ubuntu)
## Amazon Linux 2 및 Amazon Linux 2023에서 패치 기준 규칙이 작동하는 방식
**참고**
Amazon Linux 2023(AL2023)은 하나 이상의 시스템 설정을 통해, 잠글 수 있는 버전 관리형 리포지토리를 특정 버전에 사용합니다. AL2023 EC2 인스턴스의 모든 패치 작업에서 Patch Manager는 시스템 구성과 관계없이 최신 리포지토리 버전을 사용합니다. 자세한 내용은 **Amazon Linux 2023 사용 설명서의 [버전 지정 리포지토리를 통한 결정적 업그레이드](https://docs.aws.amazon.com/linux/al2023/ug/deterministic-upgrades.html)를 참조하세요.
Amazon Linux 2 및 Amazon Linux 2023에서 패치 선택 프로세스는 다음과 같습니다.
1. 관리형 노드에서 YUM 라이브러리(Amazon Linux 2) 또는 DNF 라이브러리(Amazon Linux 2023)는 구성된 각 리포지토리에 대한 `updateinfo.xml` 파일에 액세스합니다.
`updateinfo.xml` 파일이 없는 경우 **비보안 업데이트 포함** 및 **자동 승인** 설정에 따라 패치 설치 여부가 결정됩니다. 예를 들어 비보안 업데이트가 허용된 경우 자동 승인 시간이 되면 설치됩니다.
1. `updateinfo.xml`에 있는 각 업데이트 알림에는 다음 표에 설명된 대로, 패키지의 속성을 알림에 나타내는 여러 속성이 들어 있습니다.
**업데이트 알림 속성**
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/systems-manager/latest/userguide/patch-manager-linux-rules.html)
승인된 패치 및 거부된 패치 목록의 승인된 형식에 대한 자세한 내용은 [승인 패치 및 거부 패치 목록의 패키지 이름 형식](patch-manager-approved-rejected-package-name-formats.md) 섹션을 참조하세요.
1. SSM Agent는 관리형 노드의 프로덕트를 확인합니다. 이 속성은 패치 기준의 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html) 데이터 유형에 있는 상품 키 속성의 값에 해당합니다.
1. 패키지는 다음 지침에 따라 업데이트 대상으로 선택됩니다.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/systems-manager/latest/userguide/patch-manager-linux-rules.html)
패치 규정 준수 상태 값에 대한 자세한 내용은 [패치 규정 준수 상태 값](patch-manager-compliance-states.md) 섹션을 참조하세요.
## CentOS Stream에서 패치 기준 규칙 작동 방법
CentOS Stream 기본 리포지토리에는 `updateinfo.xml` 파일이 포함되지 않습니다. 하지만 만들거나 사용하는 사용자 지정 리포지토리에는 이 파일이 포함될 수 있습니다. 이 항목에서 `updateinfo.xml` 참조는 이러한 사용자 지정 리포지토리에만 적용됩니다.
CentOS Stream에서 패치 선택 프로세스는 다음과 같습니다.
1. 관리형 노드에서 DNF 라이브러리는 구성된 리포지토리마다 사용자 지정 리포지토리에 `updateinfo.xml` 파일이 있는 경우 이 파일에 액세스합니다.
항상 기본 리포지토리를 포함하는 `updateinfo.xml`이 없는 경우 **비보안 업데이트 포함** 및 **자동 승인** 설정에 따라 패치 설치 여부가 결정됩니다. 예를 들어 비보안 업데이트가 허용된 경우 자동 승인 시간이 되면 설치됩니다.
1. `updateinfo.xml`이 있는 경우 해당 파일의 각 업데이트 알림에는 다음 표에 설명된 대로, 패키지의 속성을 알림에 나타내는 여러 속성이 들어 있습니다.
**업데이트 알림 속성**
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/systems-manager/latest/userguide/patch-manager-linux-rules.html)
승인된 패치 및 거부된 패치 목록의 승인된 형식에 대한 자세한 내용은 [승인 패치 및 거부 패치 목록의 패키지 이름 형식](patch-manager-approved-rejected-package-name-formats.md) 섹션을 참조하세요.
1. 모든 경우 SSM Agent는 관리형 노드의 프로덕트를 확인합니다. 이 속성은 패치 기준의 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html) 데이터 유형에 있는 상품 키 속성의 값에 해당합니다.
1. 패키지는 다음 지침에 따라 업데이트 대상으로 선택됩니다.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/systems-manager/latest/userguide/patch-manager-linux-rules.html)
패치 규정 준수 상태 값에 대한 자세한 내용은 [패치 규정 준수 상태 값](patch-manager-compliance-states.md) 섹션을 참조하세요.
## Debian Server에서 패치 기준 규칙 작동 방법
Debian Server에서 패치 기준 서비스는 *우선 순위* 및 *섹션* 필드에 필터링을 제공합니다. 이러한 필드는 일반적으로 모든 Debian Server 패키지에 존재합니다. 패치가 패치 기준에 의해 선택된 것인지를 확인하기 위해 Patch Manager는 다음 작업을 수행합니다.
1. Debian Server 시스템의 경우, `sudo apt-get update`와 동등한 명령이 실행되어 사용 가능한 패키지 목록을 새로 고칩니다. 리포지토리는 구성되지 않으며 데이터는 `sources` 목록에 구성되어 있는 리포지토리로부터 가져옵니다.
1. `python3-apt`(`libapt`에 대한 Python 라이브러리 인터페이스)에 대한 업데이트가 있는 경우 최신 버전으로 업그레이드됩니다. (**Include nonsecurity updates(비보안 업데이트 포함)** 옵션을 선택하지 않은 경우에도 이 비보안 패키지가 업그레이드됩니다.)
1. 다음으로 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters), [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules), [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches) 및 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches) 목록이 적용됩니다.
**참고**
Debian Server에 대한 업데이트 패키지의 릴리스 날짜를 확실히 결정할 수 없으므로 이 운영 체제에서는 자동 승인 옵션이 지원되지 않습니다.
그러나 승인 규칙은 패치 기준을 생성하거나 마지막으로 업데이트할 때 **Include nonsecurity updates(비보안 업데이트 포함)** 확인란을 선택했는지 여부에 따라 달라집니다.
비보안 업데이트가 제외되면 보안 리포지토리에서 업그레이드가 있는 패키지만 선택할 수 있도록 묵시적인 규칙이 적용됩니다. 패키지마다, 후보 패키지 버전(일반적으로 최신 버전)이 보안 리포지토리에 속해 있어야 합니다. 이 경우 Debian Server의 패치 후보 버전은 다음 리포지토리에 포함된 패치로 제한됩니다.
이러한 리포지토리는 다음과 같이 이름이 지정됩니다.
+ Debian Server 11: `debian-security bullseye`
+ Debian Server 12: `debian-security bookworm`
비보안 업데이트가 포함된 경우 다른 리포지토리의 패치도 고려됩니다.
승인된 패치 및 거부된 패치 목록의 승인된 형식에 대한 자세한 내용은 [승인 패치 및 거부 패치 목록의 패키지 이름 형식](patch-manager-approved-rejected-package-name-formats.md) 섹션을 참조하세요.
*우선순위* 및 *섹션* 필드의 내용을 보려면 다음 `aptitude` 명령을 실행하세요.
**참고**
먼저 Debian Server 시스템에 Aptitude를 설치해야 할 수 있습니다.
```
aptitude search -F '%p %P %s %t %V#' '~U'
```
이 명령에 대한 응답으로, 업그레이드 가능한 모든 패키지가 다음 형식으로 보고됩니다.
```
name, priority, section, archive, candidate version
```
패치 규정 준수 상태 값에 대한 자세한 내용은 [패치 규정 준수 상태 값](patch-manager-compliance-states.md) 섹션을 참조하세요.
## macOS에서 패치 기준 규칙 작동 방법
macOS에서 패치 선택 프로세스는 다음과 같습니다.
1. 관리형 노드에서 Patch Manager는 `InstallHistory.plist` 파일의 구문 분석된 내용에 액세스하고 패키지 이름과 버전을 식별합니다.
구문 분석 프로세스에 대한 자세한 내용은 [패치 설치 방법](patch-manager-installing-patches.md)의 **macOS** 탭을 참조하세요.
1. SSM Agent는 관리형 노드의 프로덕트를 확인합니다. 이 속성은 패치 기준의 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html) 데이터 유형에 있는 상품 키 속성의 값에 해당합니다.
1. 패키지는 다음 지침에 따라 업데이트 대상으로 선택됩니다.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/systems-manager/latest/userguide/patch-manager-linux-rules.html)
패치 규정 준수 상태 값에 대한 자세한 내용은 [패치 규정 준수 상태 값](patch-manager-compliance-states.md) 섹션을 참조하세요.
## Oracle Linux에서 패치 기준 규칙 작동 방법
Oracle Linux에서 패치 선택 프로세스는 다음과 같습니다.
1. 관리형 노드에서 YUM 라이브러리는 구성된 각 리포지토리에 대한 `updateinfo.xml` 파일에 액세스합니다.
**참고**
리포지토리가 Oracle에서 관리하는 것이 아닌 경우 `updateinfo.xml` 파일을 사용할 수 없을 수 있습니다. `updateinfo.xml`이 없는 경우 **비보안 업데이트 포함** 및 **자동 승인** 설정에 따라 패치 설치 여부가 결정됩니다. 예를 들어 비보안 업데이트가 허용된 경우 자동 승인 시간이 되면 설치됩니다.
1. `updateinfo.xml`에 있는 각 업데이트 알림에는 다음 표에 설명된 대로, 패키지의 속성을 알림에 나타내는 여러 속성이 들어 있습니다.
**업데이트 알림 속성**
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/systems-manager/latest/userguide/patch-manager-linux-rules.html)
승인된 패치 및 거부된 패치 목록의 승인된 형식에 대한 자세한 내용은 [승인 패치 및 거부 패치 목록의 패키지 이름 형식](patch-manager-approved-rejected-package-name-formats.md) 섹션을 참조하세요.
1. SSM Agent는 관리형 노드의 프로덕트를 확인합니다. 이 속성은 패치 기준의 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html) 데이터 유형에 있는 상품 키 속성의 값에 해당합니다.
1. 패키지는 다음 지침에 따라 업데이트 대상으로 선택됩니다.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/systems-manager/latest/userguide/patch-manager-linux-rules.html)
패치 규정 준수 상태 값에 대한 자세한 내용은 [패치 규정 준수 상태 값](patch-manager-compliance-states.md) 섹션을 참조하세요.
## AlmaLinux, RHEL 및 Rocky Linux의 패치 기준선 규칙 작동 방식
AlmaLinux, Red Hat Enterprise Linux (RHEL) 및 Rocky Linux의 패치 선택 프로세스는 다음과 같습니다.
1. 관리형 노드의 YUM 라이브러리(RHEL 7) 또는 DNF 라이브러리(AlmaLinux 8 및 9, RHEL 8, 9 및 10, Rocky Linux 8 및 9)에서는 구성된 리포지토리마다 `updateinfo.xml` 파일에 액세스합니다.
**참고**
리포지토리가 Red Hat에서 관리하는 것이 아닌 경우 `updateinfo.xml` 파일을 사용할 수 없을 수 있습니다. `updateinfo.xml`을 찾을 수 없는 경우, 패치가 적용되지 않습니다.
1. `updateinfo.xml`에 있는 각 업데이트 알림에는 다음 표에 설명된 대로, 패키지의 속성을 알림에 나타내는 여러 속성이 들어 있습니다.
**업데이트 알림 속성**
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/systems-manager/latest/userguide/patch-manager-linux-rules.html)
승인된 패치 및 거부된 패치 목록의 승인된 형식에 대한 자세한 내용은 [승인 패치 및 거부 패치 목록의 패키지 이름 형식](patch-manager-approved-rejected-package-name-formats.md) 섹션을 참조하세요.
1. SSM Agent는 관리형 노드의 프로덕트를 확인합니다. 이 속성은 패치 기준의 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html) 데이터 유형에 있는 상품 키 속성의 값에 해당합니다.
1. 패키지는 다음 지침에 따라 업데이트 대상으로 선택됩니다.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/systems-manager/latest/userguide/patch-manager-linux-rules.html)
패치 규정 준수 상태 값에 대한 자세한 내용은 [패치 규정 준수 상태 값](patch-manager-compliance-states.md) 섹션을 참조하세요.
## SUSE Linux Enterprise Server에서 패치 기준 규칙 작동 방법
SLES에서 각 패치에는 패치에 있는 패키지 속성을 나타내는 다음 속성이 포함되어 있습니다.
+ **카테고리**: 패치 기준선의 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html) 데이터 유형에 있는 **분류 키** 속성의 값에 해당합니다. 업데이트 알림에 들어 있는 패치 유형을 나타냅니다.
AWS CLI 명령 **[https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-patch-properties.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-patch-properties.html)** 또는 API 작업 **[https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_DescribePatchProperties.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_DescribePatchProperties.html)**를 사용하여 지원되는 값 목록을 볼 수 있습니다. 또한 Systems Manager 콘솔의 [**패치 기준 생성(Create patch baseline)**] 페이지 또는 [**패치 기준 편집(Edit patch baseline)**] 페이지의 [**승인 규칙(Approval rules)**] 영역에서 목록을 볼 수 있습니다.
+ **심각도**: 패치 기준선의 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html) 데이터 유형에 있는 **심각도** 키 속성의 값에 해당합니다. 패치의 심각도를 나타냅니다.
AWS CLI 명령 **[https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-patch-properties.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-patch-properties.html)** 또는 API 작업 **[https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_DescribePatchProperties.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_DescribePatchProperties.html)**를 사용하여 지원되는 값 목록을 볼 수 있습니다. 또한 Systems Manager 콘솔의 [**패치 기준 생성(Create patch baseline)**] 페이지 또는 [**패치 기준 편집(Edit patch baseline)**] 페이지의 [**승인 규칙(Approval rules)**] 영역에서 목록을 볼 수 있습니다.
SSM Agent는 관리형 노드의 프로덕트를 확인합니다. 이 속성은 패치 기준선의 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html) 데이터 유형에 있는 **제품** 키 속성의 값에 해당합니다.
각 패치에 대해 패치 기준이 필터로 사용되어, 자격을 갖춘 패키지만 업데이트에 포함되도록 허용합니다. 패치 기준 정의를 적용한 후에도 여러 패키지가 남아 있으면 최신 버전이 사용됩니다.
승인된 패치 및 거부된 패치 목록의 승인된 형식에 대한 자세한 내용은 [승인 패치 및 거부 패치 목록의 패키지 이름 형식](patch-manager-approved-rejected-package-name-formats.md) 섹션을 참조하세요.
## Ubuntu Server에서 패치 기준 규칙 작동 방법
Ubuntu Server에서 패치 기준 서비스는 *우선 순위* 및 *섹션* 필드에 필터링을 제공합니다. 이러한 필드는 일반적으로 모든 Ubuntu Server 패키지에 존재합니다. 패치가 패치 기준에 의해 선택된 것인지를 확인하기 위해 Patch Manager는 다음 작업을 수행합니다.
1. Ubuntu Server 시스템의 경우, `sudo apt-get update`와 동등한 명령이 실행되어 사용 가능한 패키지 목록을 새로 고칩니다. 리포지토리는 구성되지 않으며 데이터는 `sources` 목록에 구성되어 있는 리포지토리로부터 가져옵니다.
1. `python3-apt`(`libapt`에 대한 Python 라이브러리 인터페이스)에 대한 업데이트가 있는 경우 최신 버전으로 업그레이드됩니다. (**Include nonsecurity updates(비보안 업데이트 포함)** 옵션을 선택하지 않은 경우에도 이 비보안 패키지가 업그레이드됩니다.)
1. 다음으로 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters), [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules), [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches) 및 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches) 목록이 적용됩니다.
**참고**
Ubuntu Server에 대한 업데이트 패키지의 릴리스 날짜를 확실히 결정할 수 없으므로 이 운영 체제에서는 자동 승인 옵션이 지원되지 않습니다.
그러나 승인 규칙은 패치 기준을 생성하거나 마지막으로 업데이트할 때 **Include nonsecurity updates(비보안 업데이트 포함)** 확인란을 선택했는지 여부에 따라 달라집니다.
비보안 업데이트가 제외되면 보안 리포지토리에서 업그레이드가 있는 패키지만 선택할 수 있도록 묵시적인 규칙이 적용됩니다. 패키지마다, 후보 패키지 버전(일반적으로 최신 버전)이 보안 리포지토리에 속해 있어야 합니다. 이 경우 Ubuntu Server의 패치 후보 버전은 다음 리포지토리에 포함된 패치로 제한됩니다.
+ Ubuntu Server 16.04 LTS: `xenial-security`
+ Ubuntu Server 18.04 LTS: `bionic-security`
+ Ubuntu Server 20.04 LTS: `focal-security`
+ Ubuntu Server 22.04 LTS(`jammy-security`)
+ Ubuntu Server 24.04 LTS(`noble-security`)
+ Ubuntu Server 25.04(`plucky-security`)
비보안 업데이트가 포함된 경우 다른 리포지토리의 패치도 고려됩니다.
승인된 패치 및 거부된 패치 목록의 승인된 형식에 대한 자세한 내용은 [승인 패치 및 거부 패치 목록의 패키지 이름 형식](patch-manager-approved-rejected-package-name-formats.md) 섹션을 참조하세요.
*우선순위* 및 *섹션* 필드의 내용을 보려면 다음 `aptitude` 명령을 실행하세요.
**참고**
먼저 Ubuntu Server 16 시스템에 Aptitude를 설치해야 할 수 있습니다.
```
aptitude search -F '%p %P %s %t %V#' '~U'
```
이 명령에 대한 응답으로, 업그레이드 가능한 모든 패키지가 다음 형식으로 보고됩니다.
```
name, priority, section, archive, candidate version
```
패치 규정 준수 상태 값에 대한 자세한 내용은 [패치 규정 준수 상태 값](patch-manager-compliance-states.md) 섹션을 참조하세요.
# Linux 및 Windows Server 간 패치 작업 차이점
이 주제에서는 AWS Systems Manager의 도구인 Patch Manager의 Linux 패치와 Windows Server 패치 간 주요 차이점에 대해 설명합니다.
**참고**
Linux 관리형 노드에 패치를 실행하려면 노드가 SSM Agent 버전 2.0.834.0 이상을 실행 중이어야 합니다.
SSM Agent의 업데이트된 버전은 Systems Manager에 새 도구가 추가되거나 기존 도구가 업데이트될 때마다 릴리스됩니다. 최신 버전의 에이전트를 사용하지 못하면 관리형 노드에서 다양한 Systems Manager 도구를 사용하지 못할 수 있습니다. 이러한 이유로 시스템의 SSM Agent 상태를 최신 상태로 유지하는 프로세스를 자동화하는 것이 좋습니다. 자세한 내용은 [SSM Agent 업데이트 자동화](ssm-agent-automatic-updates.md) 섹션을 참조하세요. SSM Agent 업데이트에 대해 알림을 수신하려면 GitHub에서 [SSM Agent 릴리스 정보](https://github.com/aws/amazon-ssm-agent/blob/mainline/RELEASENOTES.md) 페이지를 구독합니다.
## 차이점 1: 패치 평가
Patch Manager는 Windows 관리형 노드와 Linux 관리형 노드에 적용되는 패치를 평가할 때 서로 다른 프로세스를 사용합니다.
**Linux**
Linux 패치의 경우 Systems Manager는 패치 기준 규칙과 *각* 관리형 노드에서 승인 및 거부된 패치 목록을 평가합니다. 서비스가 관리형 노드에 구성된 리포지토리에서 알려진 패치 및 업데이트 목록을 검색하기 때문에 Systems Manager는 각 노드에서 패치를 평가해야 합니다.
**Windows**
Windows 패치의 경우 Systems Manager는 패치 기준 규칙과 승인/거부된 패치 목록을 *직접 서비스에서* 평가합니다. Windows 패치는 단일 리포지토리(Windows 업데이트)에서 가져오기 때문에 이것이 가능합니다.
## 차이점 2: `Not Applicable` 패치
Linux 운영 체제에서는 사용할 수 있는 패키지가 매우 많기 때문에 Systems Manager가 [*해당 사항 없음(Not Applicable)*] 상태의 패치에 대해서는 세부 정보를 보고하지 않습니다. 예를 들어 `Not Applicable` 패치는 인스턴스에 Apache가 설치되어 있지 않은 경우 Apache 소프트웨어용 패치입니다. Systems Manager는 요약에서 `Not Applicable` 패치 수를 보고하지만 관리형 노드에 대해 [DescribeInstancePatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_DescribeInstancePatches.html) API를 호출하면 상태가 `Not Applicable`인 패치는 반환된 데이터에 포함되지 않습니다. Windows에서는 이러한 동작이 다릅니다.
## 차이점 3: SSM 문서 지원
`AWS-ApplyPatchBaseline` Systems Manager 문서(SSM 문서)는 Linux 관리형 노드를 지원하지 않습니다. Linux, macOS 및 Windows Server 관리형 노드에 패치 기준을 적용하기 위해 권장되는 SSM 문서는 `AWS-RunPatchBaseline`입니다. 자세한 내용은 [관리형 노드 패치를 위한 SSM 명령 문서](patch-manager-ssm-documents.md) 및 [패치를 위한 SSM 명령 문서: `AWS-RunPatchBaseline`](patch-manager-aws-runpatchbaseline.md)(을)를 참조하세요.
## 차이점 4: 애플리케이션 패치
Patch Manager는 운영 체제를 패치하는 데 중점을 둡니다. 그러나 Patch Manager를 사용하여 관리형 노드의 일부 애플리케이션을 패치할 수도 있습니다.
**Linux**
Linux 운영 체제에서 Patch Manager는 업데이트를 위해 구성된 리포지토리를 사용하며 운영 체제와 애플리케이션 패치를 구분하지 않습니다. Patch Manager를 사용하여 업데이트를 가져올 리포지토리를 정의할 수 있습니다. 자세한 내용은 [대체 패치 소스 리포지토리를 지정하는 방법(Linux)](patch-manager-alternative-source-repository.md) 섹션을 참조하세요.
**Windows**
Windows Server 관리형 노드에서는 Microsoft Word 2016, Microsoft Exchange Server 2016과 같이 Microsoft에서 출시한 애플리케이션에 대해 *승인된* 패치와 *거부된* 패치 예외는 물론, 승인 규칙을 적용할 수 있습니다. 자세한 내용은 [사용자 정의 패치 기준 작업](patch-manager-manage-patch-baselines.md) 섹션을 참조하세요.
## 차이점 5: 사용자 지정 패치 기준의 거부된 패치 목록 옵션
사용자 지정 패치 기준을 생성할 때 **거부된 패치** 목록에 하나 이상의 패치를 지정할 수 있습니다. Linux 관리형 노드의 경우 패치가 기준에서 허용되는 다른 패치의 종속 항목인 경우 설치될 수 있도록 선택할 수도 있습니다.
하지만 Windows Server에서는 패치 종속성의 개념을 지원하지 않습니다. Windows Server에 대한 사용자 지정 기준선의 **거부된 패치** 목록에 패치를 추가할 수 있지만 (1) 거부된 패치가 관리형 노드에 이미 설치되어 있는지 여부와 (2) **거부된 패치 작업**에 대해 선택하는 옵션에 따라 결과가 달라집니다.
Windows Server의 거부된 패치 옵션에 대한 자세한 내용은 다음 표를 참조하세요.
| 설치 상태 | 옵션: “종속성으로 허용” | 옵션: “블록” |
| --- | --- | --- |
| 패치가 이미 설치됨 | 보고된 상태: INSTALLED\$1OTHER | 보고된 상태: INSTALLED\$1REJECTED |
| 패치가 아직 설치되지 않음 | 패치 건너뜀 | 패치 건너뜀 |
Microsoft에서 릴리스하는 Windows Server에 대한 각 패치에는 일반적으로 설치하는 데 필요한 모든 정보가 포함됩니다. 하지만 경우에 따라 수동으로 설치해야 하는 사전 필수 패키지가 필요할 수 있습니다. Patch Manager는 이러한 사전 필수 조건에 대해 정보를 보고하지 않습니다. 관련 정보는 Microsoft 웹 사이트의 [Windows 업데이트 문제 해결](https://learn.microsoft.com/en-us/troubleshoot/windows-client/installing-updates-features-roles/windows-update-issues-troubleshooting)을 참조하세요.
# 관리형 노드 패치를 위한 SSM 명령 문서
이 주제에서는 보안과 관련된 최신 업데이트를 통해 관리형 노드를 계속 패치하는 데 활용할 수 있는 9개의 Systems Manager 문서(SSM 문서)에 대해 설명합니다.
패치 작업에서는 이들 문서 중 5개만 사용할 것을 권장하고 있습니다. 5개의 SSM 문서를 함께 참조하면 AWS Systems Manager를 사용한 다양한 패치 옵션에 대해 배울 수 있습니다. 이 문서 중 4개는 대체된 4개의 레거시 SSM 문서보다 나중에 발표되었으며 기능의 확장 또는 통합을 나타냅니다.
**패치 작업에 권장되는 SSM 문서**
패치 작업에서는 다음과 같은 5개의 SSM 문서를 사용할 것을 권장합니다.
+ `AWS-ConfigureWindowsUpdate`
+ `AWS-InstallWindowsUpdates`
+ `AWS-RunPatchBaseline`
+ `AWS-RunPatchBaselineAssociation`
+ `AWS-RunPatchBaselineWithHooks`
**패치 작업을 위한 기존 SSM 문서**
다음 네 개의 레거시 SSM 문서는 일부 AWS 리전에서 계속 사용할 수 있지만 더 이상 업데이트되거나 지원되지 않습니다. 이러한 문서는 IPv6 환경에서 작동이 보장되지 않으며 IPv4만 지원합니다. 모든 시나리오에서 작동하도록 보장할 수 없으며 향후 지원이 중단될 수 있습니다. 패치 작업에 이러한 문서를 사용하지 않는 것이 좋습니다.
+ `AWS-ApplyPatchBaseline`
+ `AWS-FindWindowsUpdates`
+ `AWS-InstallMissingWindowsUpdates`
+ `AWS-InstallSpecificWindowsUpdates`
IPv6만 지원하는 환경에서 패치 작업을 설정하는 단계는 [자습서: IPv6 전용 환경에서 서버 패치 적용](patch-manager-server-patching-iPv6-tutorial.md) 섹션을 참조하세요.
패치 적용 작업 시 이러한 SSM 문서를 사용하는 방법에 대한 자세한 내용은 다음 섹션을 참조하세요.
**Topics**
+ [관리형 노드 패치를 위한 권장 SSM 문서 정보](#patch-manager-ssm-documents-recommended)
+ [관리형 노드 패치를 위한 SSM 레거시](#patch-manager-ssm-documents-legacy)
+ [관리형 노드 패치를 위한 SSM 문서의 알려진 제한 사항](#patch-manager-ssm-documents-known-limitations)
+ [패치를 위한 SSM 명령 문서: `AWS-RunPatchBaseline`](patch-manager-aws-runpatchbaseline.md)
+ [패치를 위한 SSM 명령 문서: `AWS-RunPatchBaselineAssociation`](patch-manager-aws-runpatchbaselineassociation.md)
+ [패치를 위한 SSM 명령 문서: `AWS-RunPatchBaselineWithHooks`](patch-manager-aws-runpatchbaselinewithhooks.md)
+ [`AWS-RunPatchBaseline` 또는 `AWS-RunPatchBaselineAssociation`에 InstallOverrideList 파라미터를 사용하기 위한 샘플 시나리오](patch-manager-override-lists.md)
+ [BaselineOverride 파라미터 사용](patch-manager-baselineoverride-parameter.md)
## 관리형 노드 패치를 위한 권장 SSM 문서 정보
관리형 노드 패치 작업에서는 다음과 같은 5개의 SSM 문서를 사용할 것을 권장합니다.
**Topics**
+ [`AWS-ConfigureWindowsUpdate`](#patch-manager-ssm-documents-recommended-AWS-ConfigureWindowsUpdate)
+ [`AWS-InstallWindowsUpdates`](#patch-manager-ssm-documents-recommended-AWS-InstallWindowsUpdates)
+ [`AWS-RunPatchBaseline`](#patch-manager-ssm-documents-recommended-AWS-RunPatchBaseline)
+ [`AWS-RunPatchBaselineAssociation`](#patch-manager-ssm-documents-recommended-AWS-RunPatchBaselineAssociation)
+ [`AWS-RunPatchBaselineWithHooks`](#patch-manager-ssm-documents-recommended-AWS-RunPatchBaselineWithHooks)
### `AWS-ConfigureWindowsUpdate`
기본적인 Windows Update 기능을 구성하고 이들을 사용하여 업데이트를 자동 설치하거나 자동 업데이트를 해제할 수 있도록 돕습니다. 모든 AWS 리전에서 사용 가능합니다.
이 SSM 문서에서는 Windows 업데이트에게 지정된 업데이트를 다운로드 및 설치하고 필요에 따라 관리형 노드를 재부팅할 것을 요구합니다. AWS Systems Manager의 도구인 State Manager에서 이 문서를 사용하여 Windows Update에서 구성을 유지할 수 있습니다. 또한 AWS Systems Manager의 도구인 Run Command를 사용하여 이를 수동으로 실행하여 Windows 업데이트 구성을 변경할 수도 있습니다.
이 문서에서 사용 가능한 파라미터는 설치할 업데이트의 범주나 자동 업데이트의 해제 여부를 지정하는 것은 물론이고, 패치 작업이 실행되는 요일과 시간을 지정할 수 있도록 지원합니다. 이 SSM 문서는 Windows 업데이트를 엄격하게 제어할 필요가 없고 규정 준수 정보를 수집할 필요가 없는 경우에 매우 유용합니다.
**기존 SSM 문서 대체: **
+ *없음*
### `AWS-InstallWindowsUpdates`
Windows Server 관리형 노드에 업데이트를 설치합니다. 모든 AWS 리전에서 사용 가능합니다.
이 SSM 문서는 특정 업데이트를 설치하고 싶은 경우(`Include Kbs` 파라미터 사용), 또는 특정 분류 또는 범주에 따라 패치를 설치하되, 패치 규정 준수 정보가 필요하지 않은 경우에 기본적인 패치 기능을 제공합니다.
**기존 SSM 문서 대체:**
+ `AWS-FindWindowsUpdates`
+ `AWS-InstallMissingWindowsUpdates`
+ `AWS-InstallSpecificWindowsUpdates`
3개의 레거시 문서는 서로 다른 역할을 수행하지만, 최신 SSM 문서인 `AWS-InstallWindowsUpdates`에서는 서로 다른 파라미터 설정을 사용해도 동일한 결과를 얻을 수 있습니다. 이러한 파라미터 설정은 [관리형 노드 패치를 위한 SSM 레거시](#patch-manager-ssm-documents-legacy)에 설명되어 있습니다.
### `AWS-RunPatchBaseline`
관리형 노드에 패치를 설치하거나 노드를 스캔하여 기준에 부합하는 패치의 누락 여부를 판단합니다. 모든 AWS 리전에서 사용 가능합니다.
`AWS-RunPatchBaseline`을 사용하면 운영 체제 유형에 대해 "기본값"으로 지정된 패치 기준을 사용하여 패치 승인을 제어할 수 있습니다. Systems Manager Compliance 도구를 사용하여 확인할 수 있는 패치 규정 준수 정보를 보고합니다. 이러한 도구들은 어떤 노드에서 패치가 누락되었는지, 어떤 패치가 누락되었는지와 같이 관리형 노드의 패치 규정 준수 상태에 대한 통찰력을 제공합니다. `AWS-RunPatchBaseline`을 사용하면 `PutInventory` API 명령을 사용하여 패치 규정 준수 정보가 기록됩니다. Linux 운영 체제의 경우 관리형 노드에 구성된 기본 소스 리포지토리와 사용자 지정 패치 기준에서 지정한 대체 소스 리포지토리의 패치에 대한 규정 준수 정보가 제공됩니다. 대체 소스 리포지토리에 대한 자세한 내용은 [대체 패치 소스 리포지토리를 지정하는 방법(Linux)](patch-manager-alternative-source-repository.md) 섹션을 참조하세요. Systems Manager Compliance 도구에 대한 자세한 내용은 [AWS Systems Manager Compliance](systems-manager-compliance.md) 섹션을 참조하세요.
**기존 문서 대체:**
+ `AWS-ApplyPatchBaseline`
레거시 문서 `AWS-ApplyPatchBaseline`은 Windows Server 관리형 노드에만 적용되며 애플리케이션 패치를 지원하지 않습니다. 최신 버전의 `AWS-RunPatchBaseline`은 Windows 및 Linux 시스템 모두를 동일하게 지원합니다. `AWS-RunPatchBaseline` 문서를 사용하려면 SSM Agent 버전 2.0.834.0 이상이 필요합니다.
`AWS-RunPatchBaseline` SSM 문서에 대한 자세한 내용은 [패치를 위한 SSM 명령 문서: `AWS-RunPatchBaseline`](patch-manager-aws-runpatchbaseline.md) 섹션을 참조하세요.
### `AWS-RunPatchBaselineAssociation`
인스턴스에 패치를 설치하거나 인스턴스를 스캔하여 기준에 부합하는 패치의 누락 여부를 판단합니다. 모든 상용 AWS 리전에서 사용 가능합니다.
`AWS-RunPatchBaselineAssociation`은 다음과 같은 몇 가지 중요한 면에서 `AWS-RunPatchBaseline`과 다릅니다.
+ `AWS-RunPatchBaselineAssociation`은 주로 AWS Systems Manager의 도구인 Quick Setup을 사용하여 생성된 State Manager 연결에 사용하도록 만들어졌습니다. 특히 Quick Setup 호스트 관리 구성 유형을 사용하는 경우, **Scan instances for missing patches daily**(매일 인스턴스에서 누락된 패치 스캔) 옵션을 선택하면 작업에 `AWS-RunPatchBaselineAssociation`이 사용됩니다.
그러나 대부분의 경우 패치 작업을 직접 설정할 때 `AWS-RunPatchBaselineAssociation` 대신 [`AWS-RunPatchBaseline`](patch-manager-aws-runpatchbaseline.md) 또는 [`AWS-RunPatchBaselineWithHooks`](patch-manager-aws-runpatchbaselinewithhooks.md)를 선택해야 합니다.
자세한 내용은 다음 주제를 참조하세요.
+ [AWS Systems Manager Quick Setup](systems-manager-quick-setup.md)
+ [패치를 위한 SSM 명령 문서: `AWS-RunPatchBaselineAssociation`](patch-manager-aws-runpatchbaselineassociation.md)
+ `AWS-RunPatchBaselineAssociation`은 실행 시 대상 집합에 사용할 패치 기준 식별을 위해 태그 사용을 지원합니다.
+ `AWS-RunPatchBaselineAssociation`을 사용하는 패치 작업의 경우 패치 규정 준수 데이터는 특정 State Manager 연결 측면에서 컴파일됩니다. `AWS-RunPatchBaselineAssociation` 실행 시 수집된 패치 규정 준수 데이터는 `PutInventory` 명령 대신 `PutComplianceItems` API 명령을 사용하여 기록됩니다. 이렇게 하면 이 특정 연결과 연결되지 않은 규정 준수 데이터를 덮어쓰는 것을 방지할 수 있습니다.
Linux 운영 체제의 경우 인스턴스에 구성된 기본 소스 리포지토리와 사용자 지정 패치 기준에서 지정한 대체 소스 리포지토리의 패치에 대한 규정 준수 정보가 제공됩니다. 대체 소스 리포지토리에 대한 자세한 내용은 [대체 패치 소스 리포지토리를 지정하는 방법(Linux)](patch-manager-alternative-source-repository.md) 섹션을 참조하세요. Systems Manager Compliance 도구에 대한 자세한 내용은 [AWS Systems Manager Compliance](systems-manager-compliance.md) 섹션을 참조하세요.
**기존 문서 대체:**
+ **없음**
`AWS-RunPatchBaselineAssociation` SSM 문서에 대한 자세한 내용은 [패치를 위한 SSM 명령 문서: `AWS-RunPatchBaselineAssociation`](patch-manager-aws-runpatchbaselineassociation.md) 섹션을 참조하세요.
### `AWS-RunPatchBaselineWithHooks`
관리형 노드에 패치를 설치하거나 노드를 스캔하여 패치 주기 동안 세 지점에서 SSM 문서를 실행하는 데 사용할 수 있는 옵션 후크로 정규화된 패치의 누락 여부를 판단합니다. 모든 상용 AWS 리전에서 사용 가능합니다. macOS에서는 지원되지 않습니다.
`AWS-RunPatchBaselineWithHooks`는 `Install` 작업에 있어 `AWS-RunPatchBaseline`과 다릅니다.
`AWS-RunPatchBaselineWithHooks`는 관리형 노드 패치 중 지정된 지점에서 실행되는 수명 주기 후크를 지원합니다. 패치 설치 시 관리형 노드를 재부팅해야 하는 경우가 있기 때문에 패치 작업은 사용자 정의 기능을 지원하는 총 3개의 후크에 대한 2개의 이벤트로 나뉩니다. 첫 번째 후크는 `Install with NoReboot` 작업 전입니다. 두 번째 후크는 `Install with NoReboot` 작업 후입니다. 세 번째 후크는 노드 재부팅 후 사용할 수 있습니다.
**기존 문서 대체:**
+ **없음**
`AWS-RunPatchBaselineWithHooks` SSM 문서에 대한 자세한 내용은 [패치를 위한 SSM 명령 문서: `AWS-RunPatchBaselineWithHooks`](patch-manager-aws-runpatchbaselinewithhooks.md) 섹션을 참조하세요.
## 관리형 노드 패치를 위한 SSM 레거시
다음과 같은 4개의 SSM 문서는 일부 AWS 리전에서 계속 사용할 수 있습니다. 그러나 더 이상 업데이트되지 않으며 향후 지원되지 않을 수 있기 때문에 사용하지 않는 것이 좋습니다. 대신에 [관리형 노드 패치를 위한 권장 SSM 문서 정보](#patch-manager-ssm-documents-recommended)에 설명되어 있는 문서를 사용하세요.
**Topics**
+ [`AWS-ApplyPatchBaseline`](#patch-manager-ssm-documents-legacy-AWS-ApplyPatchBaseline)
+ [`AWS-FindWindowsUpdates`](#patch-manager-ssm-documents-legacy-AWS-AWS-FindWindowsUpdates)
+ [`AWS-InstallMissingWindowsUpdates`](#patch-manager-ssm-documents-legacy-AWS-InstallMissingWindowsUpdates)
+ [`AWS-InstallSpecificWindowsUpdates`](#patch-manager-ssm-documents-legacy-AWS-InstallSpecificWindowsUpdates)
### `AWS-ApplyPatchBaseline`
Windows Server 관리형 노드만 지원하지만, 이를 대체하는 `AWS-RunPatchBaseline`에 있는 패치 애플리케이션에 대한 지원은 포함하지 않습니다. 2017년 8월 이후에 출시된 AWS 리전에서는 사용할 수 없습니다.
**참고**
이 SSM 문서 `AWS-RunPatchBaseline`을 대체하려면 버전 2.0.834.0 이상의 SSM Agent가 필요합니다. `AWS-UpdateSSMAgent` 문서를 사용하여 최신 버전의 에이전트로 관리형 노드를 업데이트할 수 있습니다.
### `AWS-FindWindowsUpdates`
`AWS-InstallWindowsUpdates`에 의해 대체되지만, 동일한 모든 작업을 수행할 수 있습니다. 2017년 4월 이후에 출시된 AWS 리전에서는 사용할 수 없습니다.
이 레거시 SSM 문서에서와 동일한 결과를 얻으려면 권장되는 대체 문서인 `AWS-InstallWindowsUpdates`에서 다음과 같이 파라미터 구성을 사용합니다.
+ `Action` = `Scan`
+ `Allow Reboot` = `False`
### `AWS-InstallMissingWindowsUpdates`
`AWS-InstallWindowsUpdates`에 의해 대체되지만, 동일한 모든 작업을 수행할 수 있습니다. 2017년 4월 이후에 출시된 AWS 리전에서는 사용할 수 없습니다.
이 레거시 SSM 문서에서와 동일한 결과를 얻으려면 권장되는 대체 문서인 `AWS-InstallWindowsUpdates`에서 다음과 같이 파라미터 구성을 사용합니다.
+ `Action` = `Install`
+ `Allow Reboot` = `True`
### `AWS-InstallSpecificWindowsUpdates`
`AWS-InstallWindowsUpdates`에 의해 대체되지만, 동일한 모든 작업을 수행할 수 있습니다. 2017년 4월 이후에 출시된 AWS 리전에서는 사용할 수 없습니다.
이 레거시 SSM 문서에서와 동일한 결과를 얻으려면 권장되는 대체 문서인 `AWS-InstallWindowsUpdates`에서 다음과 같이 파라미터 구성을 사용합니다.
+ `Action` = `Install`
+ `Allow Reboot` = `True`
+ `Include Kbs` = *KB 문서를 쉼표로 분리한 목록*
## 관리형 노드 패치를 위한 SSM 문서의 알려진 제한 사항
### 외부 재부팅 중단
패치 설치 중에 노드의 시스템에서 재부팅을 시작하는 경우(예: 펌웨어 또는 SecureBoot와 같은 기능에 업데이트를 적용하기 위해) 패치가 성공적으로 설치되었더라도 패치 문서 실행이 중단되고 실패로 표시될 수 있습니다. 이는 SSM 에이전트가 외부 재부팅에서 문서 실행 상태를 유지하고 재개할 수 없기 때문에 발생합니다.
실행 실패 후 패치 설치 상태를 확인하려면 `Scan` 패치 작업을 실행한 다음 패치 관리자의 패치 규정 준수 데이터를 확인하여 현재 규정 준수 상태를 평가합니다.
# 패치를 위한 SSM 명령 문서: `AWS-RunPatchBaseline`
AWS Systems Manager는 AWS Systems Manager의 도구인 Patch Manager용 Systems Manager 문서(SSM 문서)인 `AWS-RunPatchBaseline`를 지원합니다. 이 SSM 문서는 보안 관련 업데이트 및 기타 유형의 업데이트 모두에 대해 관리형 노드에서 패치 작업을 수행합니다. 문서가 실행될 때 패치 그룹이 지정되지 않은 경우 운영 체제 유형에 대해 "기본값"으로 지정된 패치 기준을 사용합니다 그렇지 않으면 패치 그룹과 연결된 패치 기준을 사용합니다. 패치 그룹에 대한 자세한 내용은 [패치 그룹](patch-manager-patch-groups.md) 섹션을 참조하세요.
문서 `AWS-RunPatchBaseline`을 사용하면 운영 체제와 애플리케이션 모두를 패치할 수 있습니다. (Windows Server에서 애플리케이션 지원은 Microsoft에서 릴리스한 애플리케이션의 업데이트로 제한됩니다.)
이 문서는 Linux, macOS, 및 Windows Server관리형 노드를 지원합니다. 문서에서 각 플랫폼에 적합한 작업을 수행합니다.
**참고**
Patch Manager는 레거시 SSM 문서 `AWS-ApplyPatchBaseline`도 지원합니다. 단, 이 문서는 Windows 관리형 노드에 대한 패치 적용 작업만 지원합니다. `AWS-RunPatchBaseline`이 Linux, macOS 및 Windows Server 관리형 노드 모두에서 패치 작업을 지원하므로 이를 대신 사용하는 것이 좋습니다. `AWS-RunPatchBaseline` 문서를 사용하려면 SSM Agent 버전 2.0.834.0 이상이 필요합니다.
------
#### [ Windows Server ]
Windows Server 관리형 노드에서는 `AWS-RunPatchBaseline` 문서가 PowerShell 모듈을 다운로드하고 호출합니다. 그런 다음, 해당 관리형 노드에 적용되는 패치 기준의 스냅샷을 다운로드합니다. 이 패치 기준 스냅샷에는 Windows Server Update Services(WSUS) 서버에 대해 패치 기준을 쿼리하여 컴파일된 승인된 패치 목록이 포함되어 있습니다. 이 목록은 Windows Update API에 전달되며, 이 API가 승인된 패치를 적절하게 다운로드하고 설치하는 작업을 제어합니다.
------
#### [ Linux ]
Linux 관리형 노드에서는 `AWS-RunPatchBaseline` 문서가 Python 모듈을 호출합니다. 그런 다음, 해당 관리형 노드에 적용되는 패치 기준의 스냅샷을 다운로드합니다. 이 패치 기준 스냅샷은 정의된 규칙과 승인 및 차단된 패치 목록을 사용하여 각 노드 유형에 적합한 패키지 관리자를 실행합니다.
+ Amazon Linux 2, Oracle Linux 및 RHEL 7 관리형 노드는 YUM을 사용합니다. YUM 작업의 경우 `Python 2.6` 이상의 지원되는 버전(2.6\$13.12)이 Patch Manager에 필요합니다. Amazon Linux 2023은 DNF를 사용합니다. DNF 작업의 경우 지원되는 `Python 2` 또는 `Python 3` 버전(2.6\$13.12)이 Patch Manager에 필요합니다.
+ RHEL 8 관리형 노드는 DNF를 사용합니다. DNF 작업의 경우 지원되는 `Python 2` 또는 `Python 3` 버전(2.6\$13.12)이 Patch Manager에 필요합니다. (두 버전 모두 RHEL 8에 기본적으로 설치되어 있지 않습니다. 둘 중 하나를 수동으로 설치해야 합니다.)
+ Debian Server 및 Ubuntu Server 인스턴스는 APT를 사용합니다. APT 작업의 경우 지원되는 `Python 3` 버전(3.0\$13.12)이 Patch Manager에 필요합니다.
------
#### [ macOS ]
macOS 관리형 노드에서는 `AWS-RunPatchBaseline` 문서가 Python 모듈을 호출합니다. 그런 다음, 해당 인스턴스에 적용되는 패치 기준의 스냅샷을 다운로드합니다. 다음으로 Python 하위 프로세스는 노드에서 AWS Command Line Interface(AWS CLI)를 호출하여 지정된 패키지 관리자에 대한 설치 및 업데이트 정보를 검색하고 각 업데이트 패키지에 대해 적절한 패키지 관리자를 구동합니다.
------
각 스냅샷은 AWS 계정, 패치 그룹, 운영 체제 및 스냅샷 ID에 따라 다릅니다. 스냅샷은 스냅샷 생성 후 24시간이 지나면 만료되는 미리 서명된 Amazon Simple Storage Service(Amazon S3) URL을 통해 전송됩니다. 그러나 URL이 만료된 후 동일한 스냅샷 콘텐츠를 다른 관리형 노드에 적용하려는 경우 스냅샷이 생성된 후 최대 3일 이내에 미리 서명된 Amazon S3 URL을 새로 생성할 수 있습니다. 이렇게 하려면 [https://docs.aws.amazon.com/cli/latest/reference/ssm/get-deployable-patch-snapshot-for-instance.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/get-deployable-patch-snapshot-for-instance.html) 명령을 사용합니다.
승인되고 적용 가능한 모든 업데이트가 설치되고 필요한 만큼 재부팅이 수행되면, 패치 규정 준수 정보가 관리형 노드에 생성되며 Patch Manager에 다시 보고됩니다.
**참고**
`AWS-RunPatchBaseline` 문서에서 `RebootOption` 파라미터가 `NoReboot`로 설정되어 있으면 Patch Manager를 실행한 후 관리형 노드가 재부팅되지 않습니다. 자세한 내용은 [파라미터 이름: `RebootOption`](#patch-manager-aws-runpatchbaseline-parameters-norebootoption) 섹션을 참조하세요.
패치 규정 준수 데이터를 보는 방법에 대한 자세한 내용은 [패치 규정 준수 정보](compliance-about.md#compliance-monitor-patch) 섹션을 참조하세요.
## `AWS-RunPatchBaseline` 파라미터
`AWS-RunPatchBaseline`는 6개 파라미터를 지원합니다. `Operation` 파라미터가 필요합니다. `InstallOverrideList`, `BaselineOverride` 및 `RebootOption` 파라미터는 선택 항목입니다. `Snapshot-ID`는 엄밀히 말해 옵션이지만, 유지 관리 기간 이외에서 `AWS-RunPatchBaseline`을 실행하는 경우 이에 대한 사용자 정의 값을 제공하여, 유지 관리 기간 작업 동안에 문서가 실행되는 경우 Patch Manager가 값을 자동으로 제공하도록 하는 것이 좋습니다.
**Topics**
+ [파라미터 이름: `Operation`](#patch-manager-aws-runpatchbaseline-parameters-operation)
+ [파라미터 이름: `AssociationId`](#patch-manager-aws-runpatchbaseline-parameters-association-id)
+ [파라미터 이름: `Snapshot ID`](#patch-manager-aws-runpatchbaseline-parameters-snapshot-id)
+ [파라미터 이름: `InstallOverrideList`](#patch-manager-aws-runpatchbaseline-parameters-installoverridelist)
+ [파라미터 이름: `RebootOption`](#patch-manager-aws-runpatchbaseline-parameters-norebootoption)
+ [파라미터 이름: `BaselineOverride`](#patch-manager-aws-runpatchbaseline-parameters-baselineoverride)
+ [파라미터 이름: `StepTimeoutSeconds`](#patch-manager-aws-runpatchbaseline-parameters-steptimeoutseconds)
### 파라미터 이름: `Operation`
**사용 여부**: 필수.
**옵션**: `Scan` \$1 `Install`.
스캔
`Scan` 옵션을 선택하는 경우 `AWS-RunPatchBaseline`에 따라 관리형 노드의 패치 규정 준수 상태가 결정되며 이 정보가 Patch Manager에게 다시 보고됩니다. `Scan`은 업데이트를 설치하거나 관리형 노드를 재부팅하라는 메시지를 표시하지 않습니다. 대신, 작업이 승인되고 노드에 적용 가능한 업데이트가 누락된 위치를 식별해 줍니다.
설치
`Install` 옵션을 선택하는 경우 `AWS-RunPatchBaseline`이 관리형 노드에서 누락된 승인되고 적용 가능한 업데이트를 설치하려고 시도합니다. `Install` 작업의 일부로 생성된 패치 규정 준수 정보에는 누락된 업데이트가 나열되지 않지만, 어떠한 이유로든 업데이트 설치가 성공하지 못하면 실패 상태에 있는 업데이트를 보고할 수 있습니다. 관리형 노드에 업데이트가 설치될 때마다 업데이트가 설치되었는지 및 활성 상태인지를 확인하기 위해 노드가 재부팅됩니다. (예외: `AWS-RunPatchBaseline` 문서에서 `RebootOption` 파라미터가 `NoReboot`로 설정되어 있으면 Patch Manager를 실행한 후 관리형 노드가 재부팅되지 않습니다. 자세한 내용은 [파라미터 이름: `RebootOption`](#patch-manager-aws-runpatchbaseline-parameters-norebootoption) 섹션을 참조하세요.)
Patch Manager가 관리형 노드를 업데이트하기 *전에* 기준 규칙에 의해 지정된 패치가 설치된 경우 시스템이 예상대로 재부팅되지 않을 수도 있습니다. 이는 패치가 사용자에 의해 수동으로 설치되어 있거나 Ubuntu Server의 `unattended-upgrades` 패키지와 같은 다른 프로그램에 의해 자동으로 설치되어 있는 경우에 발생할 수 있습니다.
### 파라미터 이름: `AssociationId`
**사용 여부**: 선택.
`AssociationId`는 AWS Systems Manager의 도구인 State Manager에 있는 기존 연결의 ID입니다. 이 ID는 Patch Manager에서 지정된 연결에 규정 준수 데이터를 추가하는 데 사용됩니다. 이 연결은 의 [Quick Setup에서 패치 정책에 설정한](quick-setup-patch-manager.md) 패치 작업과 관련이 있습니다.
**참고**
`AWS-RunPatchBaseline`을 사용하면 패치 정책 기준선 재정의와 함께 `AssociationId` 값이 제공될 경우, 패치 적용이 `PatchPolicy` 작업으로 수행되며, `AWS:ComplianceItem`에 보고되는 `ExecutionType` 값도 `PatchPolicy`가 됩니다. `AssociationId` 값이 제공되지 않으면, 패치 적용이 `Command` 작업으로 수행되며 제출된 `AWS:ComplianceItem`에 대해 보고되는 `ExecutionType` 값도 `Command`가 됩니다.
사용하려는 연결이 아직 없는 경우 [https://docs.aws.amazon.com/cli/latest/reference/ssm/create-association.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/create-association.html) 명령을 실행하여 하나를 생성할 수 있습니다.
### 파라미터 이름: `Snapshot ID`
**사용 여부**: 선택.
`Snapshot ID`는 Patch Manager가 단일 작업으로 패치된 관리형 노드 집합 모두가 승인된 패치 집합과 정확히 일치하는지를 확인하기 위해 사용하는 고유 ID(GUID)입니다. 이 파라미터가 옵션으로 정의되어 있긴 하지만, 다음 표에 설명된 대로 유지 관리 기간에서 `AWS-RunPatchBaseline`를 실행하는지 여부에 따라 모범 사례 권장 사항이 달라집니다.
**`AWS-RunPatchBaseline` 모범 사례**
| Mode | 모범 사례 | 세부 정보 |
| --- | --- | --- |
| 유지 관리 기간 내 AWS-RunPatchBaseline 실행 | 스냅샷 ID를 제공하지 않습니다. Patch Manager가 제공합니다. | 유지 관리 기간을 사용하여 `AWS-RunPatchBaseline`을 실행하는 경우 자체 생성한 스냅샷 ID를 제공해선 안 됩니다. 이러한 경우에는 Systems Manager가 유지 관리 기간 실행 ID를 기반으로 GUID 값을 제공합니다. 이렇게 하면 해당 유지 관리 기간에 모든 `AWS-RunPatchBaseline` 호출에 올바른 ID가 사용됩니다. 이러한 경우에 값을 지정하는 경우 패치 기준선의 스냅샷이 3일 이상 적용되지 않을 수 있습니다. 해당 시간 경과 후에는 스냅샷 만료 후 동일한 ID를 지정하더라도 새로운 스냅샷이 생성됩니다. |
| 유지 관리 기간 외 AWS-RunPatchBaseline 실행 | 스냅샷 ID에 대해 사용자 정의 GUID 값을 생성하고 지정합니다.¹ | `AWS-RunPatchBaseline`을 실행하는 데 유지 관리 기간을 사용하고 있지 않은 경우 각 패치 기준에 대해 고유한 스냅샷 ID를 생성하고 지정하는 것이 좋습니다. 특히 동일한 작업에서 여러 관리형 노드에 `AWS-RunPatchBaseline` 문서를 실행하고 있는 경우 더욱 그러합니다. 이러한 경우에 ID를 지정하지 않으면 Systems Manager가 명령을 보내는 각 관리형 노드에 다른 스냅샷 ID를 생성합니다. 이렇게 되면 관리형 노드 간에 다양한 패치 집합이 지정될 수 있습니다. 예를 들어 AWS Systems Manager의 도구인 Run Command를 통해 직접 `AWS-RunPatchBaseline` 문서를 실행하고 50개의 관리형 노드로 이루어진 그룹을 대상으로 한다고 가정해 보겠습니다. 사용자 지정 스냅샷 ID를 지정하면 모든 노드를 평가하고 패치를 적용하는 데 사용되는 기준 스냅샷이 하나가 생성되어 일관적인 상태를 유지하도록 해줍니다. |
| ¹ GUID를 생성할 수 있는 도구라면 어떤 도구를 사용해서든 스냅샷 ID 파라미터의 값을 생성할 수 있습니다. 예를 들어 PowerShell의 경우 `New-Guid` cmdlet을 사용하여 `12345699-9405-4f69-bc5e-9315aEXAMPLE` 형식으로 GUID를 생성할 수 있습니다. |
### 파라미터 이름: `InstallOverrideList`
**사용 여부**: 선택.
`InstallOverrideList`를 사용하면 설치하려는 패치 목록에 대해 https URL 또는 Amazon S3 경로 스타일 URL을 지정할 수 있습니다. YAML 형식으로 관리되는 이 패치 설치 목록은 현재 기본 패치 기준으로 지정된 패치를 재정의합니다. 그러면 관리형 노드에 설치되는 패치를 세부적으로 제어할 수 있습니다.
**중요**
`InstallOverrideList` 파일 이름에는 백틱(`), 작은따옴표('), 큰따옴표("), 달러 기호(\$1) 문자를 포함할 수 없습니다.
`InstallOverrideList` 파라미터를 사용할 때의 패치 작업 동작은 Linux 및 macOS 관리형 노드와 Windows Server 관리형 노드가 다릅니다. Linux 및 macOS에서는 Patch Manager가 패치가 패치 기준 규칙과 일치하는지 여부와 관계없이 노드에 활성화된 모든 리포지토리의 `InstallOverrideList` 패치 목록에 포함된 패치를 적용하려고 시도합니다. 그러나 Windows Server 노드에서는 `InstallOverrideList` 패치 목록의 패치가 패치 기준 규칙과도 일치하는 경우에만 적용됩니다.
규정 준수 보고서에서는 `InstallOverrideList` 패치 목록에 지정된 항목이 아니라 패치 기준선에 지정된 항목에 따라 패치 상태를 반영합니다. 다시 말해 스캔 작업에서 `InstallOverrideList` 파라미터를 무시합니다. 그래야만 규정 준수 보고서에서 특정 패치 적용 작업에 대해 승인된 내용이 아닌 정책에 따라 패치 상태를 일관되게 반영합니다.
**참고**
IPv6만 사용하는 노드에 패치를 적용할 때는 제공된 URL에 노드에서 연결할 수 있는지 확인합니다. SSM Agent 구성 옵션 `UseDualStackEndpoint`가 `true`로 설정된 경우 S3 URL이 제공될 때 듀얼 스택 S3 클라이언트가 사용됩니다. 듀얼 스택을 사용하도록 에이전트를 구성하는 방법에 대한 자세한 내용은 [자습서: IPv6 전용 환경에서 서버 패치 적용](patch-manager-server-patching-iPv6-tutorial.md) 섹션을 참조하세요.
`InstallOverrideList` 파라미터를 사용하여 단일 패치 기준을 계속 사용하면서 서로 다른 유형의 유지 관리 기간 일정에 따라 대상 그룹에 서로 다른 유형의 패치를 적용하는 방법에 대한 설명은 [`AWS-RunPatchBaseline` 또는 `AWS-RunPatchBaselineAssociation`에 InstallOverrideList 파라미터를 사용하기 위한 샘플 시나리오](patch-manager-override-lists.md) 섹션을 참조하세요.
**유효한 URL 형식**
**참고**
파일이 공개적으로 사용 가능한 버킷에 저장된 경우 https URL 형식 또는 Amazon S3 경로 스타일 URL을 지정할 수 있습니다. 파일이 프라이빗 버킷에 저장된 경우 Amazon S3 경로 스타일 URL을 지정해야 합니다.
+ **https URL 형식**:
```
https://s3.aws-api-domain/amzn-s3-demo-bucket/my-windows-override-list.yaml
```
+ **Amazon S3 경로 스타일 URL**:
```
s3://amzn-s3-demo-bucket/my-windows-override-list.yaml
```
**유효한 YAML 콘텐츠 형식**
목록에서 패치를 지정하는 데 사용되는 형식은 관리형 노드의 운영 체제에 따라 다릅니다. 일반적인 형식은 다음과 같습니다.
```
patches:
-
id: '{patch-d}'
title: '{patch-title}'
{additional-fields}:{values}
```
YAML 파일에 추가 필드를 제공할 수 있지만 해당 필드는 패치 작업 중에 무시됩니다.
또한 S3 버킷에서 목록을 추가하거나 업데이트하기 전에 YAML 파일 형식이 올바른지 확인하는 것이 좋습니다. YAML 형식에 대한 자세한 내용은 [yaml.org](http://www.yaml.org)를 참조하세요. 유효한 도구 옵션을 보려면 웹에서 "yaml format validators"를 검색하세요.
------
#### [ Linux ]
**id**
**id** 필드는 필수입니다. 패키지 이름 및 아키텍처를 사용하여 패치를 지정하는 데 사용됩니다. 예를 들면 `'dhclient.x86_64'`입니다. id에서 와일드카드를 사용하여 여러 패키지를 나타낼 수 있습니다. 예를 들면 `'dhcp*'` 및 `'dhcp*1.*'` 등입니다.
**Title**
**title** 필드는 선택 사항이지만 Linux 시스템의 경우 이 필드는 추가 필터링 기능을 제공합니다. **title**을 사용할 경우 패키지 버전 정보를 다음 중 한 가지 형식으로 포함해야 합니다.
YUM/SUSE Linux Enterprise Server(SLES):
```
{name}.{architecture}:{epoch}:{version}-{release}
```
APT
```
{name}.{architecture}:{version}
```
Linux 패치 제목의 경우 임의의 위치에서 하나 이상의 와일드카드를 사용하여 패키지 일치 수를 확장할 수 있습니다. 예를 들면 `'*32:9.8.2-0.*.rc1.57.amzn1'`입니다.
예:
+ apt 패키지 버전 1.2.25가 관리형 노드에 현재 설치되어 있지만 버전 1.2.27을 지금 사용할 수 있습니다.
+ apt.amd64 버전 1.2.27을 패치 목록에 추가합니다. apt utils.amd64 버전 1.2.27을 사용하지만 apt-utils.amd64 버전 1.2.25가 목록에 지정되어 있습니다.
이 경우 apt 버전 1.2.27은 설치 시 차단되고 “Failed-NonCompliant”로 보고됩니다.
------
#### [ Windows Server ]
**id**
**id** 필드는 필수입니다. id 필드는 Microsoft Knowledge Base ID(예: KB2736693)와 Microsoft Security Bulletin ID(예: MS17-023)를 사용하여 패치를 지정하는 데 사용됩니다.
Windows에 대한 패치 목록에 제공하려는 다른 필드는 선택 사항이며 정보 제공의 목적으로만 사용됩니다. **title**, **classification**, **severity** 등과 같은 추가 필드를 사용하여 지정된 패치에 대한 자세한 정보를 제공할 수 있습니다.
------
#### [ macOS ]
**id**
**id** 필드는 필수입니다. **id** 필드의 값은 `{package-name}.{package-version}` 형식 또는 \$1package\$1name\$1 형식을 사용하여 제공할 수 있습니다.
------
**샘플 패치 목록**
+ **Amazon Linux 2**
```
patches:
-
id: 'kernel.x86_64'
-
id: 'bind*.x86_64'
title: '39.11.4-26.P2.amzn2.5.2'
id: 'glibc*'
-
id: 'dhclient*'
title: '*4.2.5-58.amzn2'
-
id: 'dhcp*'
title: '*4.2.5-77.amzn2'
```
+ **Debian Server**
```
patches:
-
id: 'apparmor.amd64'
title: '2.10.95-0ubuntu2.9'
-
id: 'cryptsetup.amd64'
title: '*2:1.6.6-5ubuntu2.1'
-
id: 'cryptsetup-bin.*'
title: '*2:1.6.6-5ubuntu2.1'
-
id: 'apt.amd64'
title: '*1.2.27'
-
id: 'apt-utils.amd64'
title: '*1.2.25'
```
+ **macOS**
```
patches:
-
id: 'XProtectPlistConfigData'
-
id: 'MRTConfigData.1.61'
-
id: 'Command Line Tools for Xcode.11.5'
-
id: 'Gatekeeper Configuration Data'
```
+ **Oracle Linux**
```
patches:
-
id: 'audit-libs.x86_64'
title: '*2.8.5-4.el7'
-
id: 'curl.x86_64'
title: '*.el7'
-
id: 'grub2.x86_64'
title: 'grub2.x86_64:1:2.02-0.81.0.1.el7'
-
id: 'grub2.x86_64'
title: 'grub2.x86_64:1:*-0.81.0.1.el7'
```
+ **Red Hat Enterprise Linux (RHEL)**
```
patches:
-
id: 'NetworkManager.x86_64'
title: '*1:1.10.2-14.el7_5'
-
id: 'NetworkManager-*.x86_64'
title: '*1:1.10.2-14.el7_5'
-
id: 'audit.x86_64'
title: '*0:2.8.1-3.el7'
-
id: 'dhclient.x86_64'
title: '*.el7_5.1'
-
id: 'dhcp*.x86_64'
title: '*12:5.2.5-68.el7'
```
+ **SUSE Linux Enterprise Server (SLES)**
```
patches:
-
id: 'amazon-ssm-agent.x86_64'
-
id: 'binutils'
title: '*0:2.26.1-9.12.1'
-
id: 'glibc*.x86_64'
title: '*2.19*'
-
id: 'dhcp*'
title: '0:4.3.3-9.1'
-
id: 'lib*'
```
+ **Ubuntu Server **
```
patches:
-
id: 'apparmor.amd64'
title: '2.10.95-0ubuntu2.9'
-
id: 'cryptsetup.amd64'
title: '*2:1.6.6-5ubuntu2.1'
-
id: 'cryptsetup-bin.*'
title: '*2:1.6.6-5ubuntu2.1'
-
id: 'apt.amd64'
title: '*1.2.27'
-
id: 'apt-utils.amd64'
title: '*1.2.25'
```
+ **Windows**
```
patches:
-
id: 'KB4284819'
title: '2018-06 Cumulative Update for Windows Server 2016 (1709) for x64-based Systems (KB4284819)'
-
id: 'KB4284833'
-
id: 'KB4284835'
title: '2018-06 Cumulative Update for Windows Server 2016 (1803) for x64-based Systems (KB4284835)'
-
id: 'KB4284880'
-
id: 'KB4338814'
```
### 파라미터 이름: `RebootOption`
**사용 여부**: 선택.
**옵션**: `RebootIfNeeded` \$1 `NoReboot`
**기본값**: `RebootIfNeeded`
**주의**
기본 옵션은 `RebootIfNeeded`입니다. 사용 사례에 맞는 올바른 옵션을 선택해야 합니다. 예를 들어 구성 프로세스를 완료하기 위해 관리형 노드를 즉시 재부팅해야 하는 경우, `RebootIfNeeded`를 선택합니다. 또는 예약된 재부팅 시간까지 관리형 노드 가용성을 유지해야 하는 경우, `NoReboot`을 선택합니다.
**중요**
Amazon EMR(이전 명칭: Amazon Elastic MapReduce)에서 클러스터 인스턴스 패치를 적용하는 데는 Patch Manager를 사용하지 않는 것이 좋습니다. 특히 `RebootOption` 파라미터에 `RebootIfNeeded` 옵션을 선택하지 마세요. (이 옵션은 `AWS-RunPatchBaseline`, `AWS-RunPatchBaselineAssociation` 및 `AWS-RunPatchBaselineWithHooks` 패치 적용에 대한 SSM 명령 문서에서 제공되지 않습니다.)
Patch Manager를 사용하는 패치 적용에 대한 기본 명령에서는 `yum` 및 `dnf` 명령을 사용합니다. 따라서 패키지 설치 방식 때문에 작업이 호환되지 않을 수 있습니다. Amazon EMR 클러스터의 소프트웨어 업데이트용으로 기본 설정된 방법에 대한 자세한 내용은 **Amazon EMR 관리 안내서의 [Amazon EMR용 기본 AMI 사용](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-default-ami.html)을 참조하세요.
RebootIfNeeded
`RebootIfNeeded` 옵션을 선택하면 다음과 같은 경우 관리형 노드가 재부팅됩니다.
+ Patch Manager가 하나 이상의 패치를 설치했습니다.
Patch Manager가 패치에 재부팅이 *필요*한지 여부를 평가하지 않습니다. 패치에 재부팅이 필요하지 않은 경우에도 시스템이 재부팅됩니다.
+ Patch Manager가 `Install` 작업 중 `INSTALLED_PENDING_REBOOT` 상태의 패치를 하나 이상 감지합니다.
`INSTALLED_PENDING_REBOOT` 상태는 `Install` 작업이 마지막으로 실행될 때 `NoReboot` 옵션이 선택되었거나 관리형 노드를 마지막으로 재부팅한 이후에 Patch Manager 외부에 패치가 설치되었다는 의미일 수 있습니다.
이 두 가지 경우에 관리형 노드를 재부팅하면 업데이트된 패키지가 메모리에서 플러시되고 모든 운영 체제에서 패치 및 재부팅 동작이 일관되게 유지됩니다.
NoReboot
`NoReboot` 옵션을 선택하면 Patch Manager가 `Install` 작업 중에 패치를 설치한 경우에도 관리형 노드를 재부팅하지 않습니다. 이 옵션은 패치된 후 관리형 노드를 재부팅할 필요가 없다는 것을 알고 있거나 패치 작업 재부팅으로 인해 중단되지 않아야 하는 노드에서 실행되는 애플리케이션 또는 프로세스가 있는 경우에 유용합니다. 유지 관리 기간을 사용하는 등 관리형 노드 재부팅 시간을 보다 정확하게 제어하려는 경우에도 유용합니다.
`NoReboot` 옵션을 선택하고 패치가 설치되면 패치에 `InstalledPendingReboot` 상태가 할당됩니다. 그러나 관리형 노드 자체는 `Non-Compliant`로 표시됩니다. 재부팅이 발생하고 `Scan` 작업이 실행되면 관리형 노드 상태가 `Compliant`로 업데이트됩니다.
`NoReboot` 옵션은 운영 체제 수준의 재시작만 막습니다. 서비스 수준 재시작은 패치 프로세스의 일부로 계속 이루어질 수 있습니다. 예를 들어 Docker가 업데이트되면 Amazon Elastic Container Service와 같은 종속 서비스는 `NoReboot`가 활성화되어도 자동으로 다시 시작될 수 있습니다. 중단해서는 안 되는 중요한 서비스가 있는 경우 서비스에서 인스턴스를 일시적으로 제거하거나 유지 관리 기간 동안 패치 적용을 예약하는 등의 추가 조치를 고려하세요.
**패치 설치 추적 파일(Patch installation tracking file)**: 패치 설치, 특히 마지막 시스템 재부팅 이후에 설치된 패치를 추적하기 위해 Systems Manager는 관리형 노드에서 파일을 유지 관리합니다.
**중요**
추적 파일을 삭제하거나 수정하지 않습니다. 이 파일이 삭제되거나 손상된 경우 관리형 노드에 대한 패치 준수 보고서가 부정확하게 됩니다. 이 경우 노드를 재부팅하고 패치 스캔 작업을 실행하여 파일을 복원합니다.
이 추적 파일은 관리형 노드의 다음 위치에 저장됩니다.
+ Linux 운영 체제:
+ `/var/log/amazon/ssm/patch-configuration/patch-states-configuration.json`
+ `/var/log/amazon/ssm/patch-configuration/patch-inventory-from-last-operation.json`
+ Windows Server 운영 체제:
+ `C:\ProgramData\Amazon\PatchBaselineOperations\State\PatchStatesConfiguration.json`
+ `C:\ProgramData\Amazon\PatchBaselineOperations\State\PatchInventoryFromLastOperation.json`
### 파라미터 이름: `BaselineOverride`
**사용 여부**: 선택.
`BaselineOverride` 파라미터를 사용하여 런타임에 패치 기본 설정을 정의할 수 있습니다. 이 기준 재정의는 S3 버킷에서 JSON 객체로 유지됩니다. 이는 패치 작업이 기본 패치 기준의 규칙을 적용하는 대신 호스트 운영 체제와 일치하는 제공된 기준을 사용하도록 합니다.
**중요**
`BaselineOverride` 파일 이름에는 백틱(`), 작은따옴표('), 큰따옴표("), 달러 기호(\$1) 문자를 포함할 수 없습니다.
`BaselineOverride` 파라미터 사용 방법에 대한 자세한 내용은 [BaselineOverride 파라미터 사용](patch-manager-baselineoverride-parameter.md) 섹션을 참조하세요.
### 파라미터 이름: `StepTimeoutSeconds`
**사용 여부**: 필수.
명령이 실패로 간주되기 전에 완료되어야 할 시간(초)으로, 1초\$136,000초(10시간) 사이여야 합니다.
# 패치를 위한 SSM 명령 문서: `AWS-RunPatchBaselineAssociation`
`AWS-RunPatchBaseline` 문서와 마찬가지로 `AWS-RunPatchBaselineAssociation`은 보안 관련 업데이트 및 기타 유형의 업데이트 모두에 대해 인스턴스에서 패치 작업을 수행합니다. 문서 `AWS-RunPatchBaselineAssociation`을 사용하면 운영 체제와 애플리케이션 모두를 패치할 수도 있습니다. (Windows Server에서 애플리케이션 지원은 Microsoft에서 릴리스한 애플리케이션의 업데이트로 제한됩니다.)
이 문서는 Linux, macOS 및 Windows Server용 Amazon Elastic Compute Cloud(Amazon EC2) 인스턴스를 지원합니다. [하이브리드 및 멀티클라우드](operating-systems-and-machine-types.md#supported-machine-types) 환경의 비 EC2 노드는 지원되지 않습니다. 이 문서는 Linux 및 macOS 인스턴스에서 Python 모듈을 호출하고 Windows 인스턴스에서 PowerShell 모듈을 호출하여 각 플랫폼에 대해 적절한 작업을 수행합니다.
그러나 `AWS-RunPatchBaselineAssociation`은 다음과 같은 점에서 `AWS-RunPatchBaseline`과 다릅니다.
+ `AWS-RunPatchBaselineAssociation`은 주로 AWS Systems Manager의 도구인 [Quick Setup](systems-manager-quick-setup.md)을 사용하여 생성된 State Manager 연결에 사용하도록 만들어졌습니다. 특히 Quick Setup 호스트 관리 구성 유형을 사용하는 경우, **Scan instances for missing patches daily**(매일 인스턴스에서 누락된 패치 스캔) 옵션을 선택하면 작업에 `AWS-RunPatchBaselineAssociation`이 사용됩니다.
그러나 대부분의 경우 패치 작업을 직접 설정할 때 `AWS-RunPatchBaselineAssociation` 대신 [`AWS-RunPatchBaseline`](patch-manager-aws-runpatchbaseline.md) 또는 [`AWS-RunPatchBaselineWithHooks`](patch-manager-aws-runpatchbaselinewithhooks.md)를 선택해야 합니다.
+ `AWS-RunPatchBaselineAssociation` 문서를 사용할 때 문서의 `BaselineTags` 파라미터 필드에 태그 키 페어를 지정할 수 있습니다. AWS 계정의 사용자 정의 패치 기준이 이러한 태그를 공유하는 경우 AWS Systems Manager의 도구인 Patch Manager는 운영 체제 유형에 대해 현재 지정된 ‘기본’ 패치 기준 대신 대상 인스턴스에서 실행할 때 태그가 지정된 기준을 사용합니다.
**참고**
Quick Setup을 사용하여 설정한 작업 이외의 패치 작업에서 `AWS-RunPatchBaselineAssociation`을 사용하도록 선택하고 옵션 `BaselineTags` 파라미터를 사용하려면 Amazon Elastic Compute Cloud(Amazon EC2) 인스턴스의 [인스턴스 프로파일](setup-instance-permissions.md)에 몇 가지 추가 권한을 제공해야 합니다. 자세한 내용은 [파라미터 이름: `BaselineTags`](#patch-manager-aws-runpatchbaselineassociation-parameters-baselinetags) 섹션을 참조하세요.
다음 두 형식 모두 `BaselineTags` 파라미터에 대해 유효합니다.
`Key=tag-key,Values=tag-value`
`Key=tag-key,Values=tag-value1,tag-value2,tag-value3`
**중요**
태그 키 및 값에는 백틱(`), 작은따옴표('), 큰따옴표("), 달러 기호(\$1) 문자가 포함될 수 없습니다.
+ `AWS-RunPatchBaselineAssociation` 실행 시 `AWS-RunPatchBaseline`에서 사용하는 `PutInventory` 명령 대신 `PutComplianceItems` API 명령을 사용하여 수집된 패치 규정 준수 데이터가 기록됩니다. 이 차이는 특정 *연결*별로 저장 및 보고되는 패치 규정 준수 정보를 의미합니다. 이 연결 외부에서 생성된 패치 규정 준수 데이터는 덮어쓰지 않습니다.
+ `AWS-RunPatchBaselineAssociation` 실행 후 보고되는 패치 규정 준수 정보는 인스턴스가 준수하는지 여부를 나타냅니다. 다음 AWS Command Line Interface(AWS CLI) 명령의 출력에서 알 수 있듯이 패치 수준 세부 정보는 포함되지 않습니다. 이 명령은 `Association`을 규정 준수 유형으로 필터링합니다.
```
aws ssm list-compliance-items \
--resource-ids "i-02573cafcfEXAMPLE" \
--resource-types "ManagedInstance" \
--filters "Key=ComplianceType,Values=Association,Type=EQUAL" \
--region us-east-2
```
시스템은 다음과 같은 정보를 반환합니다.
```
{
"ComplianceItems": [
{
"Status": "NON_COMPLIANT",
"Severity": "UNSPECIFIED",
"Title": "MyPatchAssociation",
"ResourceType": "ManagedInstance",
"ResourceId": "i-02573cafcfEXAMPLE",
"ComplianceType": "Association",
"Details": {
"DocumentName": "AWS-RunPatchBaselineAssociation",
"PatchBaselineId": "pb-0c10e65780EXAMPLE",
"DocumentVersion": "1"
},
"ExecutionSummary": {
"ExecutionTime": 1590698771.0
},
"Id": "3e5d5694-cd07-40f0-bbea-040e6EXAMPLE"
}
]
}
```
태그 키 페어 값이 `AWS-RunPatchBaselineAssociation` 문서의 파라미터로 지정된 경우 Patch Manager는 운영 체제 유형과 일치하고 동일한 태그 키 페어로 태그가 지정된 사용자 정의 패치 기준을 검색합니다. 이 검색은 현재 지정된 기본 패치 기준 또는 패치 그룹에 할당된 기준으로 제한되지 않습니다. 지정된 태그에 기준이 없으면 `AWS-RunPatchBaselineAssociation`을 실행하는 명령에 패치 그룹이 지정된 경우 Patch Manager는 다음으로 패치 그룹을 찾습니다. 일치하는 패치 그룹이 없으면 Patch Manager는 운영 체제 계정의 현재 기본 패치 기준으로 폴백합니다.
`AWS-RunPatchBaselineAssociation` 문서에 지정된 태그와 함께 둘 이상의 패치 기준이 발견되면 Patch Manager는 작업을 계속하기 위해 해당 키-값 페어로 하나의 패치 기준에만 태그를 지정할 수 있음을 나타내는 오류 메시지를 반환합니다.
**참고**
Linux 노드에서는 각 노드 유형에 대한 적절한 패키지 관리자가 패키지를 설치하는 데 사용됩니다.
Amazon Linux 2, Oracle Linux 및 RHEL 인스턴스는 YUM을 사용합니다. YUM 작업의 경우 `Python 2.6` 이상의 지원되는 버전(2.6\$13.12)이 Patch Manager에 필요합니다. Amazon Linux 2023은 DNF를 사용합니다. DNF 작업의 경우 지원되는 `Python 2` 또는 `Python 3` 버전(2.6\$13.12)이 Patch Manager에 필요합니다.
Debian Server 및 Ubuntu Server 인스턴스는 APT를 사용합니다. APT 작업의 경우 지원되는 `Python 3` 버전(3.0\$13.12)이 Patch Manager에 필요합니다.
검사가 완료된 후 또는 승인되고 적용 가능한 모든 업데이트가 설치된 후 필요에 따라 재부팅이 수행되면 패치 규정 준수 정보가 인스턴스에서 생성되고 Patch Compliance 서비스에 다시 보고됩니다.
**참고**
`AWS-RunPatchBaselineAssociation` 문서에서 `RebootOption` 파라미터가 `NoReboot`로 설정되어 있으면 Patch Manager를 실행한 후 인스턴스가 재부팅되지 않습니다. 자세한 내용은 [파라미터 이름: `RebootOption`](#patch-manager-aws-runpatchbaselineassociation-parameters-norebootoption) 섹션을 참조하세요.
패치 규정 준수 데이터를 보는 방법에 대한 자세한 내용은 [패치 규정 준수 정보](compliance-about.md#compliance-monitor-patch) 섹션을 참조하세요.
## `AWS-RunPatchBaselineAssociation` 파라미터
`AWS-RunPatchBaselineAssociation`은 5개 파라미터를 지원합니다 `Operation` 및 `AssociationId` 파라미터가 필요합니다. `InstallOverrideList`, `RebootOption` 및 `BaselineTags` 파라미터는 옵션입니다.
**Topics**
+ [파라미터 이름: `Operation`](#patch-manager-aws-runpatchbaselineassociation-parameters-operation)
+ [파라미터 이름: `BaselineTags`](#patch-manager-aws-runpatchbaselineassociation-parameters-baselinetags)
+ [파라미터 이름: `AssociationId`](#patch-manager-aws-runpatchbaselineassociation-parameters-association-id)
+ [파라미터 이름: `InstallOverrideList`](#patch-manager-aws-runpatchbaselineassociation-parameters-installoverridelist)
+ [파라미터 이름: `RebootOption`](#patch-manager-aws-runpatchbaselineassociation-parameters-norebootoption)
### 파라미터 이름: `Operation`
**사용 여부**: 필수.
**옵션**: `Scan` \$1 `Install`.
스캔
`Scan` 옵션을 선택하는 경우 `AWS-RunPatchBaselineAssociation`에 따라 인스턴스의 패치 규정 준수 상태가 결정되며 이 정보가 Patch Manager에게 다시 보고됩니다. `Scan`은 업데이트를 설치하거나 인스턴스를 재부팅하라는 메시지를 표시하지 않습니다. 대신, 승인되고 인스턴스에 적용 가능한 업데이트가 누락된 위치를 식별해 줍니다.
설치
`Install` 옵션을 선택하는 경우 `AWS-RunPatchBaselineAssociation`이 인스턴스에서 누락된 승인되고 적용 가능한 업데이트를 설치하려고 시도합니다. `Install` 작업의 일부로 생성된 패치 규정 준수 정보에는 누락된 업데이트가 나열되지 않지만, 어떠한 이유로든 업데이트 설치가 성공하지 못하면 실패 상태에 있는 업데이트를 보고할 수 있습니다. 인스턴스에 업데이트가 설치될 때마다 업데이트가 설치되었는지 및 활성 상태인지를 확인하기 위해 인스턴스가 재부팅됩니다. (예외: `AWS-RunPatchBaselineAssociation` 문서에서 `RebootOption` 파라미터가 `NoReboot`로 설정되어 있으면 Patch Manager를 실행한 후 인스턴스가 재부팅되지 않습니다. 자세한 내용은 [파라미터 이름: `RebootOption`](#patch-manager-aws-runpatchbaselineassociation-parameters-norebootoption) 섹션을 참조하세요.)
Patch Manager가 인스턴스를 업데이트하기 *전에* 기준 규칙에 의해 지정된 패치가 설치된 경우 시스템이 예상대로 재부팅되지 않을 수도 있습니다. 이는 패치가 사용자에 의해 수동으로 설치되어 있거나 Ubuntu Server의 `unattended-upgrades` 패키지와 같은 다른 프로그램에 의해 자동으로 설치되어 있는 경우에 발생할 수 있습니다.
### 파라미터 이름: `BaselineTags`
**사용 여부**: 선택.
`BaselineTags`는 사용자가 선택하여 개별 사용자 정의 패치 기준에 할당하는 고유한 태그 키-값 페어입니다. 이 파라미터에 대해 값을 하나 이상 지정할 수 있습니다. 다음 형식이 모두 유효합니다.
`Key=tag-key,Values=tag-value`
`Key=tag-key,Values=tag-value1,tag-value2,tag-value3`
**중요**
태그 키 및 값에는 백틱(`), 작은따옴표('), 큰따옴표("), 달러 기호(\$1) 문자가 포함될 수 없습니다.
`BaselineTags` 값은 Patch Manager가 단일 작업으로 패치된 인스턴스 집합 모두가 승인된 패치 집합과 정확히 일치하는지를 확인하기 위해 사용합니다. 패치 작업이 실행될 때 Patch Manager는 운영 체제 유형에 대한 패치 기준에 사용자가 `BaselineTags`에 대해 지정한 동일한 키-값 페어로 태그가 지정되었는지 확인합니다. 일치 항목이 있는 경우 이 사용자 정의 패치 기준이 사용됩니다. 일치 항목이 없는 경우 패치 작업에 대해 지정된 패치 그룹에 따라 패치 기준이 식별됩니다. 아무 것도 없는 경우 해당 운영 체제에 대해 미리 정의된 AWS 관리형 패치 기준이 사용됩니다.
**추가 권한 요구 사항**
Quick Setup을 사용하여 설정한 작업 이외의 패치 작업에서 `AWS-RunPatchBaselineAssociation`을 사용하는 경우 옵션 `BaselineTags` 파라미터를 사용하려면 Amazon Elastic Compute Cloud(Amazon EC2) 인스턴스의 [인스턴스 프로파일](setup-instance-permissions.md)에 다음 권한을 제공해야 합니다.
**참고**
Quick Setup 및 `AWS-RunPatchBaselineAssociation`은 온프레미스 서버와 가상 머신(VM)을 지원하지 않습니다.
```
{
"Effect": "Allow",
"Action": [
"ssm:DescribePatchBaselines",
"tag:GetResources"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"ssm:GetPatchBaseline",
"ssm:DescribeEffectivePatchesForPatchBaseline"
],
"Resource": "patch-baseline-arn"
}
```
*patch-baseline-arn*을 `arn:aws:ssm:us-east-2:123456789012:patchbaseline/pb-0c10e65780EXAMPLE` 형식으로 액세스를 제공하려는 패치 기준의 Amazon 리소스 이름(ARN)으로 바꿉니다.
### 파라미터 이름: `AssociationId`
**사용 여부**: 필수.
`AssociationId`는 AWS Systems Manager의 도구인 State Manager에 있는 기존 연결의 ID입니다. 이 ID는 Patch Manager에서 지정된 연결에 규정 준수 데이터를 추가하는 데 사용됩니다. 이 연결은 [Quick Setup에서 생성한 호스트 관리 구성](quick-setup-host-management.md)에 활성화되어 있는 패치 `Scan` 작업과 관련이 있습니다. 패치 결과를 인벤토리 규정 준수 데이터 대신 연결 규정 준수 데이터로 전송하면 패치 작업 후 또는 다른 연결 ID에 대해 인스턴스의 기존 인벤토리 규정 준수 정보를 덮어쓰지 않습니다. 사용하려는 연결이 아직 없는 경우 [https://docs.aws.amazon.com/cli/latest/reference/ssm/create-association.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/create-association.html) 명령을 실행하여 하나를 생성할 수 있습니다. 예제:
------
#### [ Linux & macOS ]
```
aws ssm create-association \
--name "AWS-RunPatchBaselineAssociation" \
--association-name "MyPatchHostConfigAssociation" \
--targets "Key=instanceids,Values=[i-02573cafcfEXAMPLE,i-07782c72faEXAMPLE,i-07782c72faEXAMPLE]" \
--parameters "Operation=Scan" \
--schedule-expression "cron(0 */30 * * * ? *)" \
--sync-compliance "MANUAL" \
--region us-east-2
```
------
#### [ Windows Server ]
```
aws ssm create-association ^
--name "AWS-RunPatchBaselineAssociation" ^
--association-name "MyPatchHostConfigAssociation" ^
--targets "Key=instanceids,Values=[i-02573cafcfEXAMPLE,i-07782c72faEXAMPLE,i-07782c72faEXAMPLE]" ^
--parameters "Operation=Scan" ^
--schedule-expression "cron(0 */30 * * * ? *)" ^
--sync-compliance "MANUAL" ^
--region us-east-2
```
------
### 파라미터 이름: `InstallOverrideList`
**사용 여부**: 선택.
`InstallOverrideList`를 사용하여 설치하려는 패치 목록에 대해 https URL 또는 Amazon Simple Storage Service(Amazon S3) 경로 스타일 URL을 지정합니다. YAML 형식으로 관리되는 이 패치 설치 목록은 현재 기본 패치 기준으로 지정된 패치를 재정의합니다. 그러면 인스턴스에 설치되는 패치를 세부적으로 제어할 수 있습니다.
**중요**
`InstallOverrideList` 파일 이름에는 백틱(`), 작은따옴표('), 큰따옴표("), 달러 기호(\$1) 문자를 포함할 수 없습니다.
`InstallOverrideList` 파라미터를 사용할 때의 패치 작업 동작은 Linux 및 macOS 관리형 노드와 Windows Server 관리형 노드가 다릅니다. Linux 및 macOS에서는 Patch Manager가 패치가 패치 기준 규칙과 일치하는지 여부와 관계없이 노드에 활성화된 모든 리포지토리의 `InstallOverrideList` 패치 목록에 포함된 패치를 적용하려고 시도합니다. 그러나 Windows Server 노드에서는 `InstallOverrideList` 패치 목록의 패치가 패치 기준 규칙과도 일치하는 경우에만 적용됩니다.
규정 준수 보고서에서는 `InstallOverrideList` 패치 목록에 지정된 항목이 아니라 패치 기준선에 지정된 항목에 따라 패치 상태를 반영합니다. 다시 말해 스캔 작업에서 `InstallOverrideList` 파라미터를 무시합니다. 그래야만 규정 준수 보고서에서 특정 패치 적용 작업에 대해 승인된 내용이 아닌 정책에 따라 패치 상태를 일관되게 반영합니다.
**유효한 URL 형식**
**참고**
파일이 공개적으로 사용 가능한 버킷에 저장된 경우 https URL 형식 또는 Amazon S3 경로 스타일 URL을 지정할 수 있습니다. 파일이 프라이빗 버킷에 저장된 경우 Amazon S3 경로 스타일 URL을 지정해야 합니다.
+ **https URL 형식 예시**:
```
https://s3.amazonaws.com/amzn-s3-demo-bucket/my-windows-override-list.yaml
```
+ **Amazon S3 경로 스타일 URL 예시**:
```
s3://amzn-s3-demo-bucket/my-windows-override-list.yaml
```
**유효한 YAML 콘텐츠 형식**
목록에서 패치를 지정하는 데 사용되는 형식은 인스턴스의 운영 체제에 따라 다릅니다. 일반적인 형식은 다음과 같습니다.
```
patches:
-
id: '{patch-d}'
title: '{patch-title}'
{additional-fields}:{values}
```
YAML 파일에 추가 필드를 제공할 수 있지만 해당 필드는 패치 작업 중에 무시됩니다.
또한 S3 버킷에서 목록을 추가하거나 업데이트하기 전에 YAML 파일 형식이 올바른지 확인하는 것이 좋습니다. YAML 형식에 대한 자세한 내용은 [yaml.org](http://www.yaml.org)를 참조하세요. 유효한 도구 옵션을 보려면 웹에서 "yaml format validators"를 검색하세요.
+ Microsoft Windows
**id**
**id** 필드는 필수입니다. id 필드는 Microsoft Knowledge Base ID(예: KB2736693)와 Microsoft Security Bulletin ID(예: MS17-023)를 사용하여 패치를 지정하는 데 사용됩니다.
Windows에 대한 패치 목록에 제공하려는 다른 필드는 선택 사항이며 정보 제공의 목적으로만 사용됩니다. **title**, **classification**, **severity** 등과 같은 추가 필드를 사용하여 지정된 패치에 대한 자세한 정보를 제공할 수 있습니다.
+ Linux
**id**
**id** 필드는 필수입니다. 패키지 이름 및 아키텍처를 사용하여 패치를 지정하는 데 사용됩니다. 예를 들면 `'dhclient.x86_64'`입니다. id에서 와일드카드를 사용하여 여러 패키지를 나타낼 수 있습니다. 예를 들면 `'dhcp*'` 및 `'dhcp*1.*'` 등입니다.
**제목**
**title** 필드는 선택 사항이지만 Linux 시스템의 경우 이 필드는 추가 필터링 기능을 제공합니다. **title**을 사용할 경우 패키지 버전 정보를 다음 중 한 가지 형식으로 포함해야 합니다.
YUM/Red Hat Enterprise Linux(RHEL):
```
{name}.{architecture}:{epoch}:{version}-{release}
```
APT
```
{name}.{architecture}:{version}
```
Linux 패치 제목의 경우 임의의 위치에서 하나 이상의 와일드카드를 사용하여 패키지 일치 수를 확장할 수 있습니다. 예를 들면 `'*32:9.8.2-0.*.rc1.57.amzn1'`입니다.
예:
+ apt 패키지 버전 1.2.25가 인스턴스에 현재 설치되어 있지만 버전 1.2.27을 지금 사용할 수 있습니다.
+ apt.amd64 버전 1.2.27을 패치 목록에 추가합니다. apt utils.amd64 버전 1.2.27을 사용하지만 apt-utils.amd64 버전 1.2.25가 목록에 지정되어 있습니다.
이 경우 apt 버전 1.2.27은 설치 시 차단되고 “Failed-NonCompliant”로 보고됩니다.
**기타 필드**
Linux에 대한 패치 목록에 제공하려는 다른 필드는 선택 사항이며 정보 제공의 목적으로만 사용됩니다. **classification**, **severity** 등과 같은 추가 필드를 사용하여 지정된 패치에 대한 자세한 정보를 제공할 수 있습니다.
**샘플 패치 목록**
+ **Windows**
```
patches:
-
id: 'KB4284819'
title: '2018-06 Cumulative Update for Windows Server 2016 (1709) for x64-based Systems (KB4284819)'
-
id: 'KB4284833'
-
id: 'KB4284835'
title: '2018-06 Cumulative Update for Windows Server 2016 (1803) for x64-based Systems (KB4284835)'
-
id: 'KB4284880'
-
id: 'KB4338814'
```
+ **APT**
```
patches:
-
id: 'apparmor.amd64'
title: '2.10.95-0ubuntu2.9'
-
id: 'cryptsetup.amd64'
title: '*2:1.6.6-5ubuntu2.1'
-
id: 'cryptsetup-bin.*'
title: '*2:1.6.6-5ubuntu2.1'
-
id: 'apt.amd64'
title: '*1.2.27'
-
id: 'apt-utils.amd64'
title: '*1.2.25'
```
+ **Amazon Linux 2**
```
patches:
-
id: 'kernel.x86_64'
-
id: 'bind*.x86_64'
title: '39.11.4-26.P2.amzn2.5.2'
id: 'glibc*'
-
id: 'dhclient*'
title: '*4.2.5-58.amzn2'
-
id: 'dhcp*'
title: '*4.2.5-77.amzn2'
```
+ **Red Hat Enterprise Linux (RHEL)**
```
patches:
-
id: 'NetworkManager.x86_64'
title: '*1:1.10.2-14.el7_5'
-
id: 'NetworkManager-*.x86_64'
title: '*1:1.10.2-14.el7_5'
-
id: 'audit.x86_64'
title: '*0:2.8.1-3.el7'
-
id: 'dhclient.x86_64'
title: '*.el7_5.1'
-
id: 'dhcp*.x86_64'
title: '*12:5.2.5-68.el7'
```
+ **SUSE Linux Enterprise Server (SLES)**
```
patches:
-
id: 'amazon-ssm-agent.x86_64'
-
id: 'binutils'
title: '*0:2.26.1-9.12.1'
-
id: 'glibc*.x86_64'
title: '*2.19*'
-
id: 'dhcp*'
title: '0:4.3.3-9.1'
-
id: 'lib*'
```
+ **Ubuntu Server **
```
patches:
-
id: 'apparmor.amd64'
title: '2.10.95-0ubuntu2.9'
-
id: 'cryptsetup.amd64'
title: '*2:1.6.6-5ubuntu2.1'
-
id: 'cryptsetup-bin.*'
title: '*2:1.6.6-5ubuntu2.1'
-
id: 'apt.amd64'
title: '*1.2.27'
-
id: 'apt-utils.amd64'
title: '*1.2.25'
```
+ **Windows**
```
patches:
-
id: 'KB4284819'
title: '2018-06 Cumulative Update for Windows Server 2016 (1709) for x64-based Systems (KB4284819)'
-
id: 'KB4284833'
-
id: 'KB4284835'
title: '2018-06 Cumulative Update for Windows Server 2016 (1803) for x64-based Systems (KB4284835)'
-
id: 'KB4284880'
-
id: 'KB4338814'
```
### 파라미터 이름: `RebootOption`
**사용 여부**: 선택.
**옵션**: `RebootIfNeeded` \$1 `NoReboot`
**기본값**: `RebootIfNeeded`
**주의**
기본 옵션은 `RebootIfNeeded`입니다. 사용 사례에 맞는 올바른 옵션을 선택해야 합니다. 예를 들어 구성 프로세스를 완료하기 위해 인스턴스를 즉시 재부팅해야 하는 경우, `RebootIfNeeded`를 선택합니다. 또는 예약된 재부팅 시간까지 인스턴스 가용성을 유지해야 하는 경우, `NoReboot`를 선택합니다.
**중요**
`NoReboot` 옵션은 운영 체제 수준의 재시작만 막습니다. 서비스 수준 재시작은 패치 프로세스의 일부로 계속 이루어질 수 있습니다. 예를 들어 Docker가 업데이트되면 Amazon Elastic Container Service와 같은 종속 서비스는 `NoReboot`가 활성화되어도 자동으로 다시 시작될 수 있습니다. 중단해서는 안 되는 중요한 서비스가 있는 경우 서비스에서 인스턴스를 일시적으로 제거하거나 유지 관리 기간 동안 패치 적용을 예약하는 등의 추가 조치를 고려하세요.
**중요**
Amazon EMR(이전 명칭: Amazon Elastic MapReduce)에서 클러스터 인스턴스 패치를 적용하는 데는 Patch Manager를 사용하지 않는 것이 좋습니다. 특히 `RebootOption` 파라미터에 `RebootIfNeeded` 옵션을 선택하지 마세요. (이 옵션은 `AWS-RunPatchBaseline`, `AWS-RunPatchBaselineAssociation` 및 `AWS-RunPatchBaselineWithHooks` 패치 적용에 대한 SSM 명령 문서에서 제공되지 않습니다.)
Patch Manager를 사용하는 패치 적용에 대한 기본 명령에서는 `yum` 및 `dnf` 명령을 사용합니다. 따라서 패키지 설치 방식 때문에 작업이 호환되지 않을 수 있습니다. Amazon EMR 클러스터의 소프트웨어 업데이트용으로 기본 설정된 방법에 대한 자세한 내용은 **Amazon EMR 관리 안내서의 [Amazon EMR용 기본 AMI 사용](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-default-ami.html)을 참조하세요.
RebootIfNeeded
`RebootIfNeeded` 옵션을 선택하면 다음과 같은 경우 인스턴스가 재부팅됩니다.
+ Patch Manager가 하나 이상의 패치를 설치했습니다.
Patch Manager가 패치에 재부팅이 *필요*한지 여부를 평가하지 않습니다. 패치에 재부팅이 필요하지 않은 경우에도 시스템이 재부팅됩니다.
+ Patch Manager가 `Install` 작업 중 `INSTALLED_PENDING_REBOOT` 상태의 패치를 하나 이상 감지합니다.
`INSTALLED_PENDING_REBOOT` 상태는 `Install` 작업이 마지막으로 실행될 때 `NoReboot` 옵션이 선택되었거나 관리형 노드를 마지막으로 재부팅한 이후에 Patch Manager 외부에 패치가 설치되었다는 의미일 수 있습니다.
이 두 가지 경우에 인스턴스를 재부팅하면 업데이트된 패키지가 메모리에서 플러시되고 모든 운영 체제에서 패치 및 재부팅 동작이 일관되게 유지됩니다.
NoReboot
`NoReboot` 옵션을 선택하면 Patch Manager가 `Install` 작업 중에 패치를 설치한 경우에도 인스턴스를 재부팅하지 않습니다. 이 옵션은 패치된 후 인스턴스를 재부팅할 필요가 없다는 것을 알고 있거나 패치 작업 재부팅으로 인해 중단되지 않아야 하는 인스턴스에서 실행되는 애플리케이션 또는 프로세스가 있는 경우에 유용합니다. 유지 관리 기간을 사용하는 등 인스턴스 재부팅 시간을 보다 정확하게 제어하려는 경우에도 유용합니다.
[**패치 설치 추적 파일(Patch installation tracking file)**]: 패치 설치, 특히 마지막 시스템 재부팅 이후에 설치된 패치를 추적하기 위해 Systems Manager는 관리형 인스턴스에서 파일을 유지 관리합니다.
**중요**
추적 파일을 삭제하거나 수정하지 않습니다. 이 파일이 삭제되거나 손상된 경우 인스턴스에 대한 패치 준수 보고서가 부정확하게 됩니다. 이 경우 인스턴스를 재부팅하고 패치 스캔 작업을 실행하여 파일을 복원합니다.
이 추적 파일은 관리형 인스턴스의 다음 위치에 저장됩니다.
+ Linux 운영 체제:
+ `/var/log/amazon/ssm/patch-configuration/patch-states-configuration.json`
+ `/var/log/amazon/ssm/patch-configuration/patch-inventory-from-last-operation.json`
+ Windows Server 운영 체제:
+ `C:\ProgramData\Amazon\PatchBaselineOperations\State\PatchStatesConfiguration.json`
+ `C:\ProgramData\Amazon\PatchBaselineOperations\State\PatchInventoryFromLastOperation.json`
# 패치를 위한 SSM 명령 문서: `AWS-RunPatchBaselineWithHooks`
AWS Systems Manager는 AWS Systems Manager의 도구인 Patch Manager용 Systems Manager 문서(SSM 문서)인 `AWS-RunPatchBaselineWithHooks`를 지원합니다. 이 SSM 문서는 보안 관련 업데이트 및 기타 유형의 업데이트 모두에 대해 관리형 노드에서 패치 작업을 수행합니다.
`AWS-RunPatchBaselineWithHooks`는 다음과 같은 점에서 `AWS-RunPatchBaseline`과 다릅니다.
+ **래퍼 문서** - `AWS-RunPatchBaselineWithHooks`는 `AWS-RunPatchBaseline`의 래퍼이며 일부 작업에 대해 `AWS-RunPatchBaseline`에 의존합니다.
+ **`Install` 작업** – `AWS-RunPatchBaselineWithHooks`은 관리형 노드 패치 중 지정된 지점에서 실행되는 수명 주기 후크를 지원합니다. 패치 설치 시 관리형 노드를 재부팅해야 하는 경우가 있기 때문에 패치 작업은 사용자 정의 기능을 지원하는 총 3개의 후크에 대한 2개의 이벤트로 나뉩니다. 첫 번째 후크는 `Install with NoReboot` 작업 전입니다. 두 번째 후크는 `Install with NoReboot` 작업 후입니다. 세 번째 후크는 관리형 노드 재부팅 후 사용할 수 있습니다.
+ **사용자 정의 패치 목록 지원 없음** - `AWS-RunPatchBaselineWithHooks`가 `InstallOverrideList` 파라미터를 지원하지 않습니다.
+ **SSM Agent 지원** - `AWS-RunPatchBaselineWithHooks`이 SSM Agent를 사용하려면 패치할 관리형 노드에 3.0.502 이상 버전이 설치되어 있어야 합니다.
문서가 실행될 때 패치 그룹이 지정되지 않은 경우 운영 체제 유형에 대해 "기본값"으로 현재 지정된 패치 기준을 사용합니다 그렇지 않으면 패치 그룹과 연결된 패치 기준을 사용합니다. 패치 그룹에 대한 자세한 내용은 [패치 그룹](patch-manager-patch-groups.md) 섹션을 참조하세요.
문서 `AWS-RunPatchBaselineWithHooks`을 사용하면 운영 체제와 애플리케이션 모두를 패치할 수 있습니다. (Windows Server에서 애플리케이션 지원은 Microsoft에서 릴리스한 애플리케이션의 업데이트로 제한됩니다.)
이 문서는 Linux 및 Windows Server 관리형 노드를 지원합니다. 문서에서 각 플랫폼에 적합한 작업을 수행합니다.
**참고**
`AWS-RunPatchBaselineWithHooks`는 macOS에서 지원되지 않습니다.
------
#### [ Linux ]
Linux 관리형 노드에서는 `AWS-RunPatchBaselineWithHooks` 문서가 Python 모듈을 호출합니다. 그런 다음, 해당 관리형 노드에 적용되는 패치 기준의 스냅샷을 다운로드합니다. 이 패치 기준 스냅샷은 정의된 규칙과 승인 및 차단된 패치 목록을 사용하여 각 노드 유형에 적합한 패키지 관리자를 실행합니다.
+ Amazon Linux 2, Oracle Linux 및 RHEL 7 관리형 노드는 YUM을 사용합니다. YUM 작업의 경우 `Python 2.6` 이상의 지원되는 버전(2.6\$13.12)이 Patch Manager에 필요합니다. Amazon Linux 2023은 DNF를 사용합니다. DNF 작업의 경우 지원되는 `Python 2` 또는 `Python 3` 버전(2.6\$13.12)이 Patch Manager에 필요합니다.
+ RHEL 8 관리형 노드는 DNF를 사용합니다. DNF 작업의 경우 지원되는 `Python 2` 또는 `Python 3` 버전(2.6\$13.12)이 Patch Manager에 필요합니다. (두 버전 모두 RHEL 8에 기본적으로 설치되어 있지 않습니다. 둘 중 하나를 수동으로 설치해야 합니다.)
+ Debian Server 및 Ubuntu Server 인스턴스는 APT를 사용합니다. APT 작업의 경우 지원되는 `Python 3` 버전(3.0\$13.12)이 Patch Manager에 필요합니다.
------
#### [ Windows Server ]
Windows Server 관리형 노드에서는 `AWS-RunPatchBaselineWithHooks` 문서가 PowerShell 모듈을 다운로드하고 호출합니다. 그런 다음, 해당 관리형 노드에 적용되는 패치 기준의 스냅샷을 다운로드합니다. 이 패치 기준 스냅샷에는 Windows Server Update Services(WSUS) 서버에 대해 패치 기준을 쿼리하여 컴파일된 승인된 패치 목록이 포함되어 있습니다. 이 목록은 Windows Update API에 전달되며, 이 API가 승인된 패치를 적절하게 다운로드하고 설치하는 작업을 제어합니다.
------
각 스냅샷은 AWS 계정, 패치 그룹, 운영 체제 및 스냅샷 ID에 따라 다릅니다. 스냅샷은 스냅샷 생성 후 24시간이 지나면 만료되는 미리 서명된 Amazon Simple Storage Service(Amazon S3) URL을 통해 전송됩니다. 그러나 URL이 만료된 후 동일한 스냅샷 콘텐츠를 다른 관리형 노드에 적용하려는 경우 스냅샷이 생성된 후 최대 3일 이내에 미리 서명된 Amazon S3 URL을 새로 생성할 수 있습니다. 이렇게 하려면 [https://docs.aws.amazon.com/cli/latest/reference/ssm/get-deployable-patch-snapshot-for-instance.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/get-deployable-patch-snapshot-for-instance.html) 명령을 사용합니다.
승인되고 적용 가능한 모든 업데이트가 설치되고 필요한 만큼 재부팅이 수행되면, 패치 규정 준수 정보가 관리형 노드에 생성되며 Patch Manager에 다시 보고됩니다.
`AWS-RunPatchBaselineWithHooks` 문서에서 `RebootOption` 파라미터가 `NoReboot`로 설정되어 있으면 Patch Manager를 실행한 후 관리형 노드가 재부팅되지 않습니다. 자세한 내용은 [파라미터 이름: `RebootOption`](patch-manager-aws-runpatchbaseline.md#patch-manager-aws-runpatchbaseline-parameters-norebootoption) 섹션을 참조하세요.
**중요**
`NoReboot` 옵션을 사용하면 운영 체제가 재시작되지 않지만 특정 패키지가 업데이트될 때 발생할 수 있는 서비스 수준 재시작을 막지는 않습니다. 예를 들어 Docker와 같은 패키지를 업데이트하면 `NoReboot`가 지정된 경우에도 종속 서비스(예: 컨테이너 오케스트레이션 서비스)가 자동으로 재시작될 수 있습니다.
패치 규정 준수 데이터를 보는 방법에 대한 자세한 내용은 [패치 규정 준수 정보](compliance-about.md#compliance-monitor-patch) 섹션을 참조하세요.
## `AWS-RunPatchBaselineWithHooks` 운영 단계
`AWS-RunPatchBaselineWithHooks`가 실행되면 다음 단계가 수행됩니다.
1. **스캔** - `AWS-RunPatchBaseline`을 사용하는 `Scan` 작업이 관리형 노드에서 실행되고 규정 준수 보고서가 생성되고 업로드됩니다.
1. **로컬 패치 상태 확인** - 선택한 작업과 1단계의 `Scan` 결과를 기반으로 수행할 단계를 결정하기 위해 스크립트가 실행됩니다.
1. 선택한 작업이 `Scan`이면 작업이 완료된 것으로 표시됩니다. 작업이 종료됩니다.
1. 선택한 작업이 `Install`이면 Patch Manager는 1단계의 `Scan` 결과를 평가하여 다음에 실행할 작업을 결정합니다.
1. 누락된 패치가 발견되지 않고 보류 중인 재부팅이 필요하지 않으면 사용자가 제공한 후크가 포함된 최종 단계(8단계)로 작업이 바로 진행됩니다. 그 사이의 모든 단계는 건너뜁니다.
1. 누락된 패치가 발견되지 않았지만 보류 중인 재부팅이 필요하고 선택한 재부팅 옵션이`NoReboot`이면 사용자가 제공한 후크가 포함된 최종 단계(8단계)로 작업이 바로 진행됩니다. 그 사이의 모든 단계는 건너뜁니다.
1. 그렇지 않으면 작업은 다음 단계로 진행됩니다.
1. **패치 전 후크 작업** - 첫 번째 수명 주기 후크인 `PreInstallHookDocName`에 대해 제공한 SSM 문서가 관리형 노드에서 실행됩니다.
1. **NoReboot로 설치** - 재부팅 옵션이 `NoReboot`이고 `AWS-RunPatchBaseline`을 사용하는 `Install` 작업이 관리형 노드에서 실행되고 규정 준수 보고서가 생성되어 업로드됩니다.
1. **설치 후 후크 작업** - 두 번째 수명 주기 후크인 `PostInstallHookDocName`에 대해 제공한 SSM 문서가 관리형 노드에서 실행됩니다.
1. **재부팅 확인** - 관리형 노드에 재부팅이 필요한지 여부와 실행할 단계를 결정하기 위해 스크립트가 실행됩니다.
1. 선택한 재부팅 옵션이 `NoReboot`인 경우 사용자가 제공한 후크가 포함된 최종 단계(8단계)로 작업이 바로 진행됩니다. 그 사이의 모든 단계는 건너뜁니다.
1. 선택한 재부팅 옵션이 `RebootIfNeeded`인 경우 Patch Manager는 4단계에서 수집된 인벤토리에서 필요한 보류 중인 재부팅이 있는지 확인합니다. 즉, 작업이 7단계로 계속 진행되고 다음과 같은 경우 관리형 노드가 재부팅됩니다.
1. Patch Manager가 하나 이상의 패치를 설치한 경우(Patch Manager가 패치에 재부팅이 필요한지 여부를 평가하지 않습니다. 패치에 재부팅이 필요하지 않은 경우에도 시스템이 재부팅됩니다.)
1. Patch Manager가 설치 작업 중 `INSTALLED_PENDING_REBOOT` 상태의 패치를 하나 이상 감지합니다. `INSTALLED_PENDING_REBOOT` 상태는 설치 작업이 마지막으로 실행될 때 `NoReboot` 옵션이 선택되었거나 관리형 노드를 마지막으로 재부팅한 이후에 Patch Manager 외부에 패치가 설치되었다는 의미일 수 있습니다.
이러한 기준을 충족하는 패치가 없으면 관리형 노드 패치 작업이 완료되고 작업은 사용자가 제공한 후크가 포함된 최종 단계(8단계)로 바로 진행됩니다. 그 사이의 모든 단계는 건너뜁니다.
1. **재부팅 및 보고** - 재부팅 옵션이 `RebootIfNeeded`인 설치 작업이 `AWS-RunPatchBaseline`을 사용하여 관리형 노드에서 실행되고 규정 준수 보고서가 생성되어 업로드됩니다.
1. **재부팅 후 후크 작업** - 세 번째 수명 주기 후크인 `OnExitHookDocName`에 대해 제공한 SSM 문서가 관리형 노드에서 실행됩니다.
`Scan` 작업의 경우 1단계가 실패하면 문서 실행 프로세스가 중지되고 단계가 실패로 보고되지만 후속 단계는 성공으로 보고됩니다.
`Install` 작업의 경우 작업 중 `aws:runDocument` 단계 중 하나라도 실패하면 해당 단계는 실패로 보고되고 작업은 사용자가 제공한 후크를 포함하는 최종 단계(8단계)로 바로 진행됩니다. 그 사이의 모든 단계는 건너뜁니다. 이 단계는 실패로 보고되고, 마지막 단계는 작업 결과의 상태를 보고하며, 그 사이의 모든 단계는 성공으로 보고됩니다.
## `AWS-RunPatchBaselineWithHooks` 파라미터
`AWS-RunPatchBaselineWithHooks`는 6개 파라미터를 지원합니다.
`Operation` 파라미터가 필요합니다.
`RebootOption`, `PreInstallHookDocName`, `PostInstallHookDocName` 및 `OnExitHookDocName` 파라미터는 옵션입니다.
`Snapshot-ID`는 기술적으로 옵션이지만 유지 관리 기간 외에 `AWS-RunPatchBaselineWithHooks`를 실행할 때 사용자 정의 값을 제공하는 것이 좋습니다. 유지 관리 기간 작업의 일부로 문서가 실행될 때 Patch Manager가 자동으로 값을 제공하도록 합니다.
**Topics**
+ [파라미터 이름: `Operation`](#patch-manager-aws-runpatchbaseline-parameters-operation)
+ [파라미터 이름: `Snapshot ID`](#patch-manager-aws-runpatchbaselinewithhook-parameters-snapshot-id)
+ [파라미터 이름: `RebootOption`](#patch-manager-aws-runpatchbaselinewithhooks-parameters-norebootoption)
+ [파라미터 이름: `PreInstallHookDocName`](#patch-manager-aws-runpatchbaselinewithhooks-parameters-preinstallhookdocname)
+ [파라미터 이름: `PostInstallHookDocName`](#patch-manager-aws-runpatchbaselinewithhooks-parameters-postinstallhookdocname)
+ [파라미터 이름: `OnExitHookDocName`](#patch-manager-aws-runpatchbaselinewithhooks-parameters-onexithookdocname)
### 파라미터 이름: `Operation`
**사용 여부**: 필수.
**옵션**: `Scan` \$1 `Install`.
스캔
`Scan` 옵션을 선택하는 경우 시스템이 `AWS-RunPatchBaseline` 문서를 사용하여 따라 관리형 노드의 패치 규정 준수 상태를 결정하며 이 정보가 Patch Manager에게 다시 보고됩니다. `Scan`은 업데이트를 설치하거나 관리형 노드를 재부팅하라는 메시지를 표시하지 않습니다. 대신, 작업이 승인되고 노드에 적용 가능한 업데이트가 누락된 위치를 식별해 줍니다.
설치
`Install` 옵션을 선택하는 경우 `AWS-RunPatchBaselineWithHooks`이 관리형 노드에서 누락된 승인되고 적용 가능한 업데이트를 설치하려고 시도합니다. `Install` 작업의 일부로 생성된 패치 규정 준수 정보에는 누락된 업데이트가 나열되지 않지만, 어떠한 이유로든 업데이트 설치가 성공하지 못하면 실패 상태에 있는 업데이트를 보고할 수 있습니다. 관리형 노드에 업데이트가 설치될 때마다 업데이트가 설치되었는지 및 활성 상태인지를 확인하기 위해 노드가 재부팅됩니다. (예외: `AWS-RunPatchBaselineWithHooks` 문서에서 `RebootOption` 파라미터가 `NoReboot`로 설정되어 있으면 Patch Manager를 실행한 후 관리형 노드가 재부팅되지 않습니다. 자세한 내용은 [파라미터 이름: `RebootOption`](#patch-manager-aws-runpatchbaselinewithhooks-parameters-norebootoption) 섹션을 참조하세요.)
Patch Manager가 관리형 노드를 업데이트하기 *전에* 기준 규칙에 의해 지정된 패치가 설치된 경우 시스템이 예상대로 재부팅되지 않을 수도 있습니다. 이는 패치가 사용자에 의해 수동으로 설치되어 있거나 Ubuntu Server의 `unattended-upgrades` 패키지와 같은 다른 프로그램에 의해 자동으로 설치되어 있는 경우에 발생할 수 있습니다.
### 파라미터 이름: `Snapshot ID`
**사용 여부**: 선택.
`Snapshot ID`는 Patch Manager가 단일 작업으로 패치된 관리형 노드 집합 모두가 승인된 패치 집합과 정확히 일치하는지를 확인하기 위해 사용하는 고유 ID(GUID)입니다. 이 파라미터가 옵션으로 정의되어 있긴 하지만, 다음 표에 설명된 대로 유지 관리 기간에서 `AWS-RunPatchBaselineWithHooks`를 실행하는지 여부에 따라 모범 사례 권장 사항이 달라집니다.
**`AWS-RunPatchBaselineWithHooks` 모범 사례**
| Mode | 모범 사례 | 세부 정보 |
| --- | --- | --- |
| 유지 관리 기간 내 AWS-RunPatchBaselineWithHooks 실행 | 스냅샷 ID를 제공하지 않습니다. Patch Manager가 제공합니다. | 유지 관리 기간을 사용하여 `AWS-RunPatchBaselineWithHooks`을 실행하는 경우 자체 생성한 스냅샷 ID를 제공해선 안 됩니다. 이러한 경우에는 Systems Manager가 유지 관리 기간 실행 ID를 기반으로 GUID 값을 제공합니다. 이렇게 하면 해당 유지 관리 기간에 모든 `AWS-RunPatchBaselineWithHooks` 호출에 올바른 ID가 사용됩니다. 이러한 경우에 값을 지정하는 경우 패치 기준선의 스냅샷이 3일 이상 적용되지 않을 수 있습니다. 해당 시간 경과 후에는 스냅샷 만료 후 동일한 ID를 지정하더라도 새로운 스냅샷이 생성됩니다. |
| 유지 관리 기간 외 AWS-RunPatchBaselineWithHooks 실행 | 스냅샷 ID에 대해 사용자 정의 GUID 값을 생성하고 지정합니다.¹ | `AWS-RunPatchBaselineWithHooks`을 실행하는 데 유지 관리 기간을 사용하고 있지 않은 경우 각 패치 기준에 대해 고유한 스냅샷 ID를 생성하고 지정하는 것이 좋습니다. 특히 동일한 작업에서 여러 관리형 노드에 `AWS-RunPatchBaselineWithHooks` 문서를 실행하고 있는 경우 더욱 그러합니다. 이러한 경우에 ID를 지정하지 않으면 Systems Manager가 명령을 보내는 각 관리형 노드에 다른 스냅샷 ID를 생성합니다. 이렇게 되면 노드 간에 다양한 패치 집합이 지정될 수 있습니다. 예를 들어 AWS Systems Manager의 도구인 Run Command를 통해 직접 `AWS-RunPatchBaselineWithHooks` 문서를 실행하고 50개의 관리형 노드로 이루어진 그룹을 대상으로 한다고 가정해 보겠습니다. 사용자 지정 스냅샷 ID를 지정하면 모든 관리형 노드를 평가하고 패치를 적용하는 데 사용되는 기준 스냅샷이 하나가 생성되어 일관적인 상태를 유지하도록 해줍니다. |
| ¹ GUID를 생성할 수 있는 도구라면 어떤 도구를 사용해서든 스냅샷 ID 파라미터의 값을 생성할 수 있습니다. 예를 들어 PowerShell의 경우 `New-Guid` cmdlet을 사용하여 `12345699-9405-4f69-bc5e-9315aEXAMPLE` 형식으로 GUID를 생성할 수 있습니다. |
### 파라미터 이름: `RebootOption`
**사용 여부**: 선택.
**옵션**: `RebootIfNeeded` \$1 `NoReboot`
**기본값**: `RebootIfNeeded`
**주의**
기본 옵션은 `RebootIfNeeded`입니다. 사용 사례에 맞는 올바른 옵션을 선택해야 합니다. 예를 들어 구성 프로세스를 완료하기 위해 관리형 노드를 즉시 재부팅해야 하는 경우, `RebootIfNeeded`를 선택합니다. 또는 예약된 재부팅 시간까지 관리형 노드 가용성을 유지해야 하는 경우, `NoReboot`을 선택합니다.
**중요**
Amazon EMR(이전 명칭: Amazon Elastic MapReduce)에서 클러스터 인스턴스 패치를 적용하는 데는 Patch Manager를 사용하지 않는 것이 좋습니다. 특히 `RebootOption` 파라미터에 `RebootIfNeeded` 옵션을 선택하지 마세요. (이 옵션은 `AWS-RunPatchBaseline`, `AWS-RunPatchBaselineAssociation` 및 `AWS-RunPatchBaselineWithHooks` 패치 적용에 대한 SSM 명령 문서에서 제공되지 않습니다.)
Patch Manager를 사용하는 패치 적용에 대한 기본 명령에서는 `yum` 및 `dnf` 명령을 사용합니다. 따라서 패키지 설치 방식 때문에 작업이 호환되지 않을 수 있습니다. Amazon EMR 클러스터의 소프트웨어 업데이트용으로 기본 설정된 방법에 대한 자세한 내용은 **Amazon EMR 관리 안내서의 [Amazon EMR용 기본 AMI 사용](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-default-ami.html)을 참조하세요.
RebootIfNeeded
`RebootIfNeeded` 옵션을 선택하면 다음과 같은 경우 관리형 노드가 재부팅됩니다.
+ Patch Manager가 하나 이상의 패치를 설치했습니다.
Patch Manager가 패치에 재부팅이 *필요*한지 여부를 평가하지 않습니다. 패치에 재부팅이 필요하지 않은 경우에도 시스템이 재부팅됩니다.
+ Patch Manager가 `Install` 작업 중 `INSTALLED_PENDING_REBOOT` 상태의 패치를 하나 이상 감지합니다.
`INSTALLED_PENDING_REBOOT` 상태는 `Install` 작업이 마지막으로 실행될 때 `NoReboot` 옵션이 선택되었거나 관리형 노드를 마지막으로 재부팅한 이후에 Patch Manager 외부에 패치가 설치되었다는 의미일 수 있습니다.
이 두 가지 경우에 관리형 노드를 재부팅하면 업데이트된 패키지가 메모리에서 플러시되고 모든 운영 체제에서 패치 및 재부팅 동작이 일관되게 유지됩니다.
NoReboot
`NoReboot` 옵션을 선택하면 Patch Manager가 `Install` 작업 중에 패치를 설치한 경우에도 관리형 노드를 재부팅하지 않습니다. 이 옵션은 패치된 후 관리형 노드를 재부팅할 필요가 없다는 것을 알고 있거나 패치 작업 재부팅으로 인해 중단되지 않아야 하는 노드에서 실행되는 애플리케이션 또는 프로세스가 있는 경우에 유용합니다. 유지 관리 기간을 사용하는 등 관리형 노드 재부팅 시간을 보다 정확하게 제어하려는 경우에도 유용합니다.
`NoReboot` 옵션을 선택하고 패치가 설치되면 패치에 `InstalledPendingReboot` 상태가 할당됩니다. 그러나 관리형 노드 자체는 `Non-Compliant`로 표시됩니다. 재부팅이 발생하고 `Scan` 작업이 실행되면 노드 상태가 `Compliant`로 업데이트됩니다.
**패치 설치 추적 파일(Patch installation tracking file)**: 패치 설치, 특히 마지막 시스템 재부팅 이후에 설치된 패치를 추적하기 위해 Systems Manager는 관리형 노드에서 파일을 유지 관리합니다.
**중요**
추적 파일을 삭제하거나 수정하지 않습니다. 이 파일이 삭제되거나 손상된 경우 관리형 노드에 대한 패치 준수 보고서가 부정확하게 됩니다. 이 경우 노드를 재부팅하고 패치 스캔 작업을 실행하여 파일을 복원합니다.
이 추적 파일은 관리형 노드의 다음 위치에 저장됩니다.
+ Linux 운영 체제:
+ `/var/log/amazon/ssm/patch-configuration/patch-states-configuration.json`
+ `/var/log/amazon/ssm/patch-configuration/patch-inventory-from-last-operation.json`
+ Windows Server 운영 체제:
+ `C:\ProgramData\Amazon\PatchBaselineOperations\State\PatchStatesConfiguration.json`
+ `C:\ProgramData\Amazon\PatchBaselineOperations\State\PatchInventoryFromLastOperation.json`
### 파라미터 이름: `PreInstallHookDocName`
**사용 여부**: 선택.
**기본값**: `AWS-Noop`.
`PreInstallHookDocName` 파라미터에 제공할 값은 선택한 SSM 문서의 이름 또는 Amazon 리소스 이름(ARN)입니다. AWS 관리형 문서의 이름이나 생성했거나 공유한 사용자 정의 SSM 문서의 이름 또는 ARN을 제공할 수 있습니다. (다른 AWS 계정에서 공유한 SSM 문서의 경우 `arn:aws:ssm:us-east-2:123456789012:document/MySharedDocument`와 같이 전체 리소스 ARN을 지정해야 합니다.)
지정한 SSM 문서는 `Install` 작업 전에 실행되며 관리형 노드에서 패치가 수행되기 전에 애플리케이션 상태 확인을 점검하는 셸 스크립트와 같이 SSM Agent에서 지원하는 모든 작업을 수행합니다. 작업 목록은 [Command 문서 플러그인 참조](documents-command-ssm-plugin-reference.md) 섹션을 참조하세요. 기본 SSM 문서 이름은 `AWS-Noop`이며 관리형 노드에서 작업을 수행하지 않습니다.
사용자 정의 SSM 문서 생성에 대한 자세한 내용은 [SSM 문서 콘텐츠 생성](documents-creating-content.md) 섹션을 참조하세요.
### 파라미터 이름: `PostInstallHookDocName`
**사용 여부**: 선택.
**기본값**: `AWS-Noop`.
`PostInstallHookDocName` 파라미터에 제공할 값은 선택한 SSM 문서의 이름 또는 Amazon 리소스 이름(ARN)입니다. AWS 관리형 문서의 이름이나 생성했거나 공유한 사용자 정의 SSM 문서의 이름 또는 ARN을 제공할 수 있습니다. (다른 AWS 계정에서 공유한 SSM 문서의 경우 `arn:aws:ssm:us-east-2:123456789012:document/MySharedDocument`과 같이 전체 리소스 ARN을 지정해야 합니다.)
지정한 SSM 문서는 `Install with NoReboot` 작업 후에 실행되며 재부팅 전에 서드 파티 업데이트를 설치하기 위한 셸 스크립트와 같이 SSM Agent가 지원하는 모든 작업을 수행합니다. 작업 목록은 [Command 문서 플러그인 참조](documents-command-ssm-plugin-reference.md) 섹션을 참조하세요. 기본 SSM 문서 이름은 `AWS-Noop`이며 관리형 노드에서 작업을 수행하지 않습니다.
사용자 정의 SSM 문서 생성에 대한 자세한 내용은 [SSM 문서 콘텐츠 생성](documents-creating-content.md) 섹션을 참조하세요.
### 파라미터 이름: `OnExitHookDocName`
**사용 여부**: 선택.
**기본값**: `AWS-Noop`.
`OnExitHookDocName` 파라미터에 제공할 값은 선택한 SSM 문서의 이름 또는 Amazon 리소스 이름(ARN)입니다. AWS 관리형 문서의 이름이나 생성했거나 공유한 사용자 정의 SSM 문서의 이름 또는 ARN을 제공할 수 있습니다. (다른 AWS 계정에서 공유한 SSM 문서의 경우 `arn:aws:ssm:us-east-2:123456789012:document/MySharedDocument`와 같이 전체 리소스 ARN을 지정해야 합니다.)
지정한 SSM 문서는 관리형 노드 재부팅 작업 후에 실행되며 패치 작업이 완료된 후 노드 상태를 확인하기 위한 셸 스크립트와 같이 SSM Agent에서 지원하는 모든 작업을 수행합니다. 작업 목록은 [Command 문서 플러그인 참조](documents-command-ssm-plugin-reference.md) 섹션을 참조하세요. 기본 SSM 문서 이름은 `AWS-Noop`이며 관리형 노드에서 작업을 수행하지 않습니다.
사용자 정의 SSM 문서 생성에 대한 자세한 내용은 [SSM 문서 콘텐츠 생성](documents-creating-content.md) 섹션을 참조하세요.
# `AWS-RunPatchBaseline` 또는 `AWS-RunPatchBaselineAssociation`에 InstallOverrideList 파라미터를 사용하기 위한 샘플 시나리오
AWS Systems Manager의 도구인 Patch Manager에서 현재 기본 패치 기준으로 지정된 패치를 재정의하려는 경우 `InstallOverrideList` 파라미터를 사용할 수 있습니다. 이 주제에서는 이 파라미터를 사용하여 다음을 수행하는 방법을 보여주는 예를 제공합니다.
+ 대상 관리형 노드 그룹에 서로 다른 패치 세트를 적용합니다.
+ 이러한 패치 세트를 다른 빈도에 적용합니다.
+ 두 작업 모두에 동일한 패치 기준선을 사용합니다.
Amazon Linux 2 관리형 노드에 서로 다른 두 가지 범주의 패치를 설치한다고 가정해 보겠습니다. 유지 관리 기간을 사용하여 이러한 패치를 다른 일정에 설치하려고 합니다. 매주 하나의 유지 관리 기간을 실행하고 모든 `Security` 패치를 설치하려고 합니다. 한 달에 한 번 다른 유지 관리 기간을 실행하고 사용 가능한 모든 패치 또는 `Security` 이외 범주의 패치를 설치하려고 합니다.
그러나 한 번에 하나의 패치 기준선만 운영 체제의 기본값으로 정의할 수 있습니다. 이 요구 사항은 한 패치 기준이 패치를 승인하는 반면 다른 패치 기준선이 패치를 차단하여, 충돌하는 버전 간에 문제가 발생할 수 있는 상황을 피하는 데 도움이 됩니다.
다음 전략으로 `InstallOverrideList` 파라미터를 사용하여 동일한 패치 기준선을 계속 사용하면서 서로 다른 일정에 따라 대상 그룹에 서로 다른 유형의 패치를 적용할 수 있습니다.
1. 기본 패치 기준선에서 `Security` 업데이트만 지정되었는지 확인합니다.
1. 매주 `AWS-RunPatchBaseline` 또는 `AWS-RunPatchBaselineAssociation`이 실행되는 유지 관리 기간을 생성합니다. 재정의 목록을 지정하지 않습니다.
1. 매월 적용하려는 모든 유형의 패치에 대한 재정의 목록을 생성하여 Amazon Simple Storage Service(Amazon S3) 버킷에 저장합니다.
1. 한 달에 한 번 실행되는 두 번째 유지 관리 기간을 생성합니다. 그러나 이 유지 관리 기간에 등록한 Run Command 태스크의 경우 재정의 목록의 위치를 지정합니다.
결과: 기본 패치 기준선에 정의된 `Security` 패치만 매주 설치됩니다. 사용 가능한 모든 패치 또는 정의한 패치의 하위 집합은 매월 설치됩니다.
**참고**
IPv6만 사용하는 노드에 패치를 적용할 때는 제공된 URL에 노드에서 연결할 수 있는지 확인합니다. SSM Agent 구성 옵션 `UseDualStackEndpoint`가 `true`로 설정된 경우 S3 URL이 제공될 때 듀얼 스택 S3 클라이언트가 사용됩니다. 듀얼 스택을 사용하도록 에이전트를 구성하는 방법에 대한 자세한 내용은 [자습서: IPv6 전용 환경에서 서버 패치 적용](patch-manager-server-patching-iPv6-tutorial.md) 섹션을 참조하세요.
자세한 내용과 샘플 목록은 [파라미터 이름: `InstallOverrideList`](patch-manager-aws-runpatchbaseline.md#patch-manager-aws-runpatchbaseline-parameters-installoverridelist) 섹션을 참조하세요.
# BaselineOverride 파라미터 사용
AWS Systems Manager의 도구인 Patch Manager의 기준 재정의 기능을 사용하여 런타임 시 패치 기본 설정을 정의할 수 있습니다. 이렇게 하려면 패치 기준 목록과 함께 JSON 객체를 포함하는 Amazon Simple Storage Service(Amazon S3) 버킷을 지정합니다. 패치 작업은 기본 패치 기준의 규칙을 적용하는 대신 호스트 운영 체제와 일치하는 JSON 객체에 제공된 기준을 사용합니다.
**중요**
`BaselineOverride` 파일 이름에는 백틱(`), 작은따옴표('), 큰따옴표("), 달러 기호(\$1) 문자를 포함할 수 없습니다.
패치 작업이 패치 정책을 사용하는 경우를 제외하고 `BaselineOverride` 파라미터를 사용해도 파라미터에 제공된 기준선의 패치 규정 준수를 덮어쓰지 않습니다. 출력 결과는 AWS Systems Manager의 도구인 Run Command의 Stdout 로그에 기록됩니다. 결과는 `NON_COMPLIANT`로 표시된 패키지만 인쇄합니다. 이는 패키지가 `Missing`, `Failed`, `InstalledRejected` 또는 `InstalledPendingReboot`로 표시되었음을 의미합니다.
그러나 패치 작업이 패치 정책을 사용하는 경우 시스템은 관련 S3 버킷의 재정의 파라미터를 전달하고 관리형 노드에 대한 규정 준수 값이 업데이트됩니다. 패치 정책 동작에 대한 자세한 내용은 [Quick Setup의 패치 정책 구성](patch-manager-policies.md) 섹션을 참조하세요.
**참고**
IPv6만 사용하는 노드에 패치를 적용할 때는 제공된 URL에 노드에서 연결할 수 있는지 확인합니다. SSM Agent 구성 옵션 `UseDualStackEndpoint`가 `true`로 설정된 경우 S3 URL이 제공될 때 듀얼 스택 S3 클라이언트가 사용됩니다. 듀얼 스택을 사용하도록 에이전트를 구성하는 방법에 대한 자세한 내용은 [자습서: IPv6 전용 환경에서 서버 패치 적용](patch-manager-server-patching-iPv6-tutorial.md) 섹션을 참조하세요.
## 스냅샷 ID 또는 설치 재정의 목록 파라미터에 패치 기준 재정의 사용
패치 기준 재정의에 주목할 만한 동작이 있는 두 가지 경우가 있습니다.
**기준 재정의 및 스냅샷 ID 동시 사용**
스냅샷 ID는 특정 패치 명령의 모든 관리형 노드가 모두 동일한 것을 적용하도록 합니다. 예를 들어 한 번에 1,000개의 노드를 패치하는 경우 패치는 동일합니다.
스냅샷 ID와 패치 기준 재정의를 모두 사용하는 경우 스냅샷 ID가 패치 기준 재정의보다 우선합니다. 기준 재정의 규칙은 계속 사용되지만 한 번만 평가됩니다. 이전 예에서 1,000개 관리형 노드의 패치는 여전히 항상 동일합니다. 패치 중간에 참조된 S3 버킷의 JSON 파일을 다른 파일로 변경한 경우 적용되는 패치는 여전히 동일합니다. 스냅샷 ID가 제공되었기 때문입니다.
**기준 재정의 및 설치 재정의 목록 동시 사용**
이 두 파라미터를 동시에 사용할 수 없습니다. 두 파라미터가 모두 제공되면 패치 문서가 실패하고 관리형 노드에서 스캔이나 설치를 수행하지 않습니다.
## 코드 예제
Python의 다음 코드 예제에서는 패치 기준 재정의를 생성하는 방법을 보여줍니다.
```
import boto3
import json
ssm = boto3.client('ssm')
s3 = boto3.resource('s3')
s3_bucket_name = 'my-baseline-override-bucket'
s3_file_name = 'MyBaselineOverride.json'
baseline_ids_to_export = ['pb-0000000000000000', 'pb-0000000000000001']
baseline_overrides = []
for baseline_id in baseline_ids_to_export:
baseline_overrides.append(ssm.get_patch_baseline(
BaselineId=baseline_id
))
json_content = json.dumps(baseline_overrides, indent=4, sort_keys=True, default=str)
s3.Object(bucket_name=s3_bucket_name, key=s3_file_name).put(Body=json_content)
```
이렇게 하면 다음과 같은 패치 기준 재정의가 생성됩니다.
```
[
{
"ApprovalRules": {
"PatchRules": [
{
"ApproveAfterDays": 0,
"ComplianceLevel": "UNSPECIFIED",
"EnableNonSecurity": false,
"PatchFilterGroup": {
"PatchFilters": [
{
"Key": "PRODUCT",
"Values": [
"*"
]
},
{
"Key": "CLASSIFICATION",
"Values": [
"*"
]
},
{
"Key": "SEVERITY",
"Values": [
"*"
]
}
]
}
}
]
},
"ApprovedPatches": [],
"ApprovedPatchesComplianceLevel": "UNSPECIFIED",
"ApprovedPatchesEnableNonSecurity": false,
"GlobalFilters": {
"PatchFilters": []
},
"OperatingSystem": "AMAZON_LINUX_2",
"RejectedPatches": [],
"RejectedPatchesAction": "ALLOW_AS_DEPENDENCY",
"Sources": []
},
{
"ApprovalRules": {
"PatchRules": [
{
"ApproveUntilDate": "2021-01-06",
"ComplianceLevel": "UNSPECIFIED",
"EnableNonSecurity": true,
"PatchFilterGroup": {
"PatchFilters": [
{
"Key": "PRODUCT",
"Values": [
"*"
]
},
{
"Key": "CLASSIFICATION",
"Values": [
"*"
]
},
{
"Key": "SEVERITY",
"Values": [
"*"
]
}
]
}
}
]
},
"ApprovedPatches": [
"open-ssl*"
],
"ApprovedPatchesComplianceLevel": "UNSPECIFIED",
"ApprovedPatchesEnableNonSecurity": false,
"GlobalFilters": {
"PatchFilters": []
},
"OperatingSystem": "SUSE",
"RejectedPatches": [
"python*"
],
"RejectedPatchesAction": "ALLOW_AS_DEPENDENCY",
"Sources": []
}
]
```
# 패치 기준
이 섹션의 주제에서는 관리형 노드에서 `Scan` 또는 `Install` 작업을 실행할 때, AWS Systems Manager의 도구인 Patch Manager에서 패치 기준의 작동 방식에 대한 정보를 제공합니다.
**Topics**
+ [미리 정의된 사용자 지정 패치 기준](patch-manager-predefined-and-custom-patch-baselines.md)
+ [승인 패치 및 거부 패치 목록의 패키지 이름 형식](patch-manager-approved-rejected-package-name-formats.md)
+ [패치 그룹](patch-manager-patch-groups.md)
+ [Microsoft에서 Windows Server에 릴리스한 애플리케이션 패치 적용](patch-manager-patching-windows-applications.md)
# 미리 정의된 사용자 지정 패치 기준
AWS Systems Manager의 도구인 Patch Manager는 Patch Manager에서 지원하는 운영 체제마다 미리 정의된 패치 기준을 제공합니다. 이러한 기준은 현재 구성된 대로 사용하거나(사용자 지정할 수 없음) 고유한 사용자 지정 패치 기준을 생성할 수 있습니다. 사용자 정의 패치 기준을 사용하면 환경에 대해 승인 또는 거부되는 패치를 더욱 효과적으로 제어할 수 있습니다. 또한 미리 정의된 기준은 해당 기준을 사용하여 설치된 모든 패치에 `Unspecified`의 규정 준수 수준을 할당합니다. 규정 준수 값을 할당하려면 미리 정의된 기준의 복사본을 생성하고 패치에 할당할 규정 준수 값을 지정할 수 있습니다. 자세한 내용은 [사용자 지정 기준](#patch-manager-baselines-custom) 및 [사용자 정의 패치 기준 작업](patch-manager-manage-patch-baselines.md)를 참조하세요.
**참고**
이 항목의 정보는 패치 작업에 사용하는 구성 방법 또는 유형에 관계없이 적용됩니다.
Quick Setup에서 구성된 패치 정책
Quick Setup에서 구성된 호스트 관리 옵션
패치 `Scan` 또는 `Install` 태스크를 실행하기 위한 유지 관리 기간
온디맨드 **Patch now**(지금 패치) 작업
**Topics**
+ [미리 정의된 기준](#patch-manager-baselines-pre-defined)
+ [사용자 지정 기준](#patch-manager-baselines-custom)
## 미리 정의된 기준
다음은 Patch Manager와 함께 제공되는 미리 정의된 패치 기준을 설명하는 표입니다.
Patch Manager가 지원하는 각 운영 체제 버전에 대한 자세한 내용은 [Patch Manager 필수 조건](patch-manager-prerequisites.md) 섹션을 참조하세요.
****
| 이름 | 지원되는 운영 체제 | 세부 정보 |
| --- | --- | --- |
| `AWS-AlmaLinuxDefaultPatchBaseline` | AlmaLinux | "Security"로 분류되고, 심각도 수준이 "Critical" 또는 "Important"로 분류되는 모든 운영 체제 패치를 승인합니다. 또한 'Bugfix'로 분류되는 모든 패치도 승인합니다. 패치는 릴리스되거나 업데이트되고 7일 후 자동 승인됩니다.¹ |
| AWS-AmazonLinux2DefaultPatchBaseline | Amazon Linux 2 | "Security"로 분류되고, 심각도 수준이 "Critical" 또는 "Important"로 분류되는 모든 운영 체제 패치를 승인합니다. 또한 'Bugfix'로 분류되는 모든 패치도 승인합니다. 패치는 릴리스 7일 후 자동 승인됩니다.¹ |
| AWS-AmazonLinux2023DefaultPatchBaseline | Amazon Linux 2023 | "Security"로 분류되고, 심각도 수준이 "Critical" 또는 "Important"로 분류되는 모든 운영 체제 패치를 승인합니다. 패치는 출시 7일 후 자동 승인됩니다. 또한 릴리스 후 7일간 "Bugfix"로 분류되는 모든 패치도 승인합니다. |
| AWS-CentOSDefaultPatchBaseline | CentOS Stream | 업데이트가 제공되고 7일 후에 모든 업데이트를 승인합니다(비보안 업데이트 포함). |
| AWS-DebianDefaultPatchBaseline | Debian Server | 우선순위가 "Required", "Important", "Standard," "Optional" 또는 "Extra"로 분류되는 모든 운영 체제 보안 관련 패치를 즉시 승인합니다. 신뢰할 수 있는 릴리스 날짜가 리포지토리에 제공되지 않으므로 승인되기까지 대기 시간이 없습니다. |
| AWS-MacOSDefaultPatchBaseline | macOS | “보안”으로 분류되는 모든 운영 체제 패치를 승인합니다. 또한 현재 업데이트가 있는 모든 패키지를 승인합니다. |
| AWS-OracleLinuxDefaultPatchBaseline | Oracle Linux | "Security"로 분류되고, 심각도 수준이 "Important" 또는 "Moderate"로 분류되는 모든 운영 체제 패치를 승인합니다. 또한 릴리스 후 7일간 'Bugfix'로 분류되는 모든 패치도 승인합니다. 패치는 릴리스되거나 업데이트되고 7일 후 자동 승인됩니다.¹ |
| `AWS-RedHatDefaultPatchBaseline` | Red Hat Enterprise Linux (RHEL) | "Security"로 분류되고, 심각도 수준이 "Critical" 또는 "Important"로 분류되는 모든 운영 체제 패치를 승인합니다. 또한 'Bugfix'로 분류되는 모든 패치도 승인합니다. 패치는 릴리스되거나 업데이트되고 7일 후 자동 승인됩니다.¹ |
| `AWS-RockyLinuxDefaultPatchBaseline` | Rocky Linux | "Security"로 분류되고, 심각도 수준이 "Critical" 또는 "Important"로 분류되는 모든 운영 체제 패치를 승인합니다. 또한 'Bugfix'로 분류되는 모든 패치도 승인합니다. 패치는 릴리스되거나 업데이트되고 7일 후 자동 승인됩니다.¹ |
| AWS-SuseDefaultPatchBaseline | SUSE Linux Enterprise Server (SLES) | "Security"로 분류되고, 심각도가 "Critical" 또는 "Important"로 분류되는 모든 운영 체제 패치를 승인합니다. 패치는 릴리스되거나 업데이트되고 7일 후 자동 승인됩니다.¹ |
| `AWS-UbuntuDefaultPatchBaseline` | Ubuntu Server | 우선순위가 "Required", "Important", "Standard," "Optional" 또는 "Extra"로 분류되는 모든 운영 체제 보안 관련 패치를 즉시 승인합니다. 신뢰할 수 있는 릴리스 날짜가 리포지토리에 제공되지 않으므로 승인되기까지 대기 시간이 없습니다. |
| AWS-DefaultPatchBaseline | Windows Server | "CriticalUpdates" 또는 "SecurityUpdates"로 분류되고, MSRC 심각도가 "Critical" 또는 "Important"로 분류되는 모든 Windows Server 운영 체제 패치를 승인합니다. 패치는 릴리스되거나 업데이트되고 7일 후 자동 승인됩니다.² |
| AWS-WindowsPredefinedPatchBaseline-OS | Windows Server | "CriticalUpdates" 또는 "SecurityUpdates"로 분류되고, MSRC 심각도가 "Critical" 또는 "Important"로 분류되는 모든 Windows Server 운영 체제 패치를 승인합니다. 패치는 릴리스되거나 업데이트되고 7일 후 자동 승인됩니다.² |
| AWS-WindowsPredefinedPatchBaseline-OS-Applications | Windows Server | Windows Server 운영 체제의 경우, "CriticalUpdates" 또는 "SecurityUpdates"로 분류되고, MSRC 심각도가 "Critical" 또는 "Important"로 분류되는 모든 운영 체제 패치를 승인합니다. Microsoft에서 릴리스한 애플리케이션의 경우 모든 패치를 승인합니다. OS 및 애플리케이션 모두에 해당하는 패치는 릴리스 또는 업데이트 7일 후 자동 승인됩니다.² |
¹ Amazon Linux 2의 경우 패치가 자동 승인되기까지의 7일 대기 시간은 `Release Date` 값이 아니라 `updateinfo.xml`의 `Updated Date` 값에서 계산됩니다. 다양한 요인이 `Updated Date` 값에 영향을 줄 수 있습니다. 다른 운영 체제에서는 릴리스 날짜와 업데이트 날짜를 다르게 처리합니다. 자동 승인 지연으로 인한 예상치 못한 결과를 방지하는 데 도움이 되는 정보를 알아보려면 [패키지 릴리스 날짜 및 업데이트 날짜 계산 방법](patch-manager-release-dates.md) 섹션을 참조하세요.
² Windows Server의 경우 기본 기준선에는 7일 자동 승인 지연이 포함됩니다. 릴리스 후 7일 내에 패치를 설치하려면 사용자 지정 기준선을 생성해야 합니다.
## 사용자 지정 기준
다음 정보를 사용하면 패치 적용 목표에 맞는 사용자 지정 패치 기준을 만들 수 있습니다.
**Topics**
+ [사용자 지정 기준에서 자동 승인 사용](#baselines-auto-approvals)
+ [패치 기준을 생성하는 데 필요한 추가 정보](#baseline-additional-info)
### 사용자 지정 기준에서 자동 승인 사용
자체 패치 기준선을 생성하는 경우 다음 카테고리를 사용하여 자동 승인할 패치를 선택할 수 있습니다.
+ **운영 체제**: Windows Server, Amazon Linux의 지원되는 버전, Ubuntu Server 등
+ **제품 이름**(운영 체제용): 예를 들어 RHEL 7.5, Amazon Linux 2023 2023.8.20250808, Windows Server 2012, Windows Server 2012 R2 등
+ **제품 이름**(Microsoft에서 릴리스한 Windows Server 기반 애플리케이션만 해당): 예를 들어 Word 2016, BizTalk Server 등
+ **분류**: 예를 들어 필수 업데이트, 보안 업데이트 등
+ **심각도**: 예를 들어 Critical, Important 등
생성한 각 승인 규칙에 대해 자동 승인 지연을 지정하거나 패치 승인 마감 날짜를 지정할 수 있습니다.
**참고**
Ubuntu Server에 대한 업데이트 패키지의 릴리스 날짜를 확실히 결정할 수 없으므로 이 운영 체제에서는 자동 승인 옵션이 지원되지 않습니다.
자동 승인 지연은 패치가 릴리스되거나 마지막으로 업데이트된 후 패치 적용을 위해 자동 승인되기까지 대기하는 일 수입니다. 예를 들어, `CriticalUpdates` 분류를 사용하여 규칙을 생성하고 자동 승인 지연 기간을 7일로 구성하면 7월 7일에 릴리스된 새 필수 패치가 7월 14일에 자동으로 승인됩니다.
Linux 리포지토리가 패키지 릴리스 날짜 정보를 제공하지 않는 경우 Patch Manager는 패키지의 빌드 시간을 Amazon Linux 2, Amazon Linux 2023, Red Hat Enterprise Linux(RHEL)의 자동 승인 날짜 사양 날짜로 사용합니다. 패키지의 빌드 시간을 확인할 수 없는 경우 Patch Manager는 기본 날짜인 1970년 1월 1일을 사용합니다. 이에 따라 Patch Manager에서 1970년 1월 1일 이후 모든 날짜에 대한 패치를 승인하도록 구성된 패치 기준의 자동 승인 날짜 사양이 무시됩니다.
자동 승인 마감 날짜를 지정하면 Patch Manager는 해당 날짜 또는 그 이전에 릴리스되거나 마지막으로 업데이트된 모든 패치를 자동으로 적용합니다. 예를 들어 2023년 7월 7일을 마감 날짜로 지정하면 2023년 7월 8일 당일 또는 이후에 릴리스되거나 마지막으로 업데이트된 모든 패치가 자동으로 설치되지 않습니다.
사용자 지정 패치 기준선을 생성할 때 해당 패치 기준선에서 승인된 패치의 규정 준수 심각도 수준을 지정할 수 있습니다(예: `Critical` 또는 `High`). 승인된 패치의 패치 상태가 `Missing`으로 보고되는 경우 패치 기준선의 전반적인 보고된 규정 준수 심각도는 사용자가 지정한 심각도 수준입니다.
### 패치 기준을 생성하는 데 필요한 추가 정보
패치 기준을 생성하는 경우 다음 사항에 유의하세요.
+ Patch Manager는 지원되는 운영 체제에 따라 미리 정의된 패치 기준이 있습니다. 고유한 패치 기준을 생성하고 이를 해당 운영 체제 유형의 기본값으로 지정하지 않는 한, 이 미리 정의된 패치 기준이 각 운영 체제 유형의 기본 패치 기준으로 사용됩니다.
**참고**
Windows Server에는 3개의 미리 정의된 패치 기준이 제공됩니다. 패치 기준 `AWS-DefaultPatchBaseline` 및 `AWS-WindowsPredefinedPatchBaseline-OS`는 Windows 운영 체제 자체에서 운영 체제 업데이트만 지원합니다. `AWS-DefaultPatchBaseline`은 다른 패치 기준을 지정하지 않는 한 Windows Server 관리형 노드의 기본 패치 기준으로 사용됩니다. 이러한 두 패치 기준의 구성 설정은 동일합니다. 둘 중 더 새로운 `AWS-WindowsPredefinedPatchBaseline-OS`는 Windows Server에 대해 미리 정의된 세 번째 패치 기준과 구별하기 위해 생성되었습니다. 해당 패치 기준인 `AWS-WindowsPredefinedPatchBaseline-OS-Applications`는 Windows Server 운영 체제 및 Microsoft에서 릴리스한 지원되는 애플리케이션을 패치하는 데 사용될 수 있습니다.
+ 기본적으로 Windows Server 2019 및 Windows Server 2022는 이후 업데이트로 대체되는 업데이트를 제거합니다. 따라서 Windows Server 패치 기준의 `ApproveUntilDate` 파라미터를 사용하지만 `ApproveUntilDate` 파라미터에서 선택한 날짜가 최신 패치 날짜 이전인 경우 패치 작업이 실행될 때 새 패치가 설치되지 않습니다. Windows Server 패치 규칙에 대한 자세한 내용은 [보안 패치 선택 방법](patch-manager-selecting-patches.md)의 Windows Server 탭을 참조하세요.
즉, 관리형 노드는 이전 달의 중요한 패치가 설치되지 않았더라도 Systems Manager 운영 측면에서 규정을 준수합니다. `ApproveAfterDays` 파라미터를 사용할 때도 이와 동일한 시나리오가 발생할 수 있습니다. Microsoft의 대체 패치 동작으로 인해 Microsoft에서 제공하는 최신 패치가 `ApproveAfterDays`의 일수가 경과하기 전에 릴리스되는 경우 Windows Server에 대한 패치가 설치되지 않도록 숫자(일반적으로 30일 이상)를 설정할 수 있습니다.
+ Windows Server에 한해 패치 기준에서 승인되지 않은 사용 가능한 보안 업데이트 패치는 사용자 지정 패치 기준에 정의된 규정 준수 값 `Compliant` 또는 `Non-Compliant`를 가질 수 있습니다.
패치 기준을 생성하거나 업데이트할 때 사용 가능하지만 패치 기준에 지정된 설치 기준을 충족하지 않아 승인되지 않은 보안 패치에 할당할 상태를 선택합니다. 예를 들어 설치 전에 패치가 릴리스된 후 장기간 대기하도록 지정한 경우 설치하려는 보안 패치를 건너뛸 수 있습니다. 지정된 대기 기간 동안 패치 업데이트가 릴리스되면 패치 설치 대기 기간이 다시 시작됩니다. 대기 기간이 너무 길면 여러 버전의 패치가 릴리스될 수 있지만 설치되지는 않습니다.
콘솔을 사용하여 패치 기준을 생성하거나 업데이트하려면 **사용 가능한 보안 업데이트 규정 준수 상태** 필드에서 이 옵션을 지정합니다. AWS CLI를 사용하여 [https://docs.aws.amazon.com/cli/latest/reference/ssm/create-patch-baseline.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/create-patch-baseline.html) 또는 [https://docs.aws.amazon.com/cli/latest/reference/ssm/update-patch-baseline.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/update-patch-baseline.html) 명령을 실행하는 경우 `available-security-updates-compliance-status` 파라미터에서 이 옵션을 지정합니다.
+ 온프레미스 서버 및 가상 머신(VM)의 경우 Patch Manager가 사용자 정의 기본 패치 기준을 사용하려고 시도합니다. 사용자 지정 기본 패치 기준선이 없는 경우 시스템은 해당 운영 체제에 사전 정의되어 있는 패치 기준선을 사용합니다.
+ 패치가 동일한 패치 기준선에 승인 및 거부로 나열되면 패치가 거부됩니다.
+ 관리형 노드마다 정의할 수 있는 패치 기준선은 각각 1개로 제한됩니다.
+ 패치 기준에 대한 승인된 패치 및 거부된 패치 목록에 추가할 수 있는 패키지 이름의 형식은 패치를 적용하는 운영 체제의 유형에 따라 다릅니다.
승인된 패치 및 거부된 패치 목록의 승인된 형식에 대한 자세한 내용은 [승인 패치 및 거부 패치 목록의 패키지 이름 형식](patch-manager-approved-rejected-package-name-formats.md) 섹션을 참조하세요.
+ Quick Setup에서 [패치 정책 구성](patch-manager-policies.md)을 사용하는 경우 사용자 지정 패치 기준선에 대한 업데이트는 한 시간에 한 번씩 Quick Setup과 동기화됩니다.
패치 정책에서 참조된 사용자 지정 패치 기준선이 삭제되면 해당 패치 정책의 Quick Setup **Configuration details**(구성 세부 정보) 페이지에 배너가 표시됩니다. 배너는 패치 정책에서 더 이상 존재하지 않는 패치 기준선을 참조하고 있으며 후속 패치 작업이 실패할 것임을 알려줍니다. 이 경우 Quick Setup **Configurations**(구성) 페이지로 돌아가서 Patch Manager 구성을 선택하고 **Actions**(작업), **Edit configuration**(구성 편집)을 선택합니다. 삭제된 패치 기준선 이름이 강조 표시되며, 영향을 받는 운영 체제의 새 패치 기준선을 선택해야 합니다.
+ `Classification` 및 `Severity` 값이 여러 개인 승인 규칙을 생성하면 사용 가능한 속성을 기반으로 패치가 승인됩니다. `Classification` 및 `Severity` 속성이 모두 있는 패키지는 두 필드 모두에 대해 선택한 기준 값과 일치합니다. `Classification` 속성만 있는 패키지는 선택한 기준 `Classification` 값과만 일치합니다. `Severity` 속성이 없는 패키지의 경우 동일한 규칙의 심각도 요구 사항은 무시됩니다.
패치 기준 생성에 대한 자세한 내용은 [사용자 정의 패치 기준 작업](patch-manager-manage-patch-baselines.md) 및 [자습서: AWS CLI를 사용한 서버 환경에 패치 적용](patch-manager-patch-servers-using-the-aws-cli.md) 섹션을 참조하세요.
# 승인 패치 및 거부 패치 목록의 패키지 이름 형식
승인된 패치 및 거부된 패치 목록에 추가할 수 있는 패키지 이름의 형식은 패치를 적용하는 운영 체제의 유형에 따라 다릅니다.
## Linux 운영 체제의 패키지 이름 형식
패치 기준의 승인 패치와 거부 패치에 지정할 수 있는 형식은 Linux 유형별로 다릅니다. 즉, 지원되는 형식은 Linux 운영 체제의 유형에서 사용하는 패키지 관리자에 따라 다릅니다.
**Topics**
+ [Amazon Linux 2, Amazon Linux 2023, Oracle Linux 및 Red Hat Enterprise Linux(RHEL)](#patch-manager-approved-rejected-package-name-formats-standard)
+ [Debian Server 및 Ubuntu Server](#patch-manager-approved-rejected-package-name-formats-ubuntu)
+ [SUSE Linux Enterprise Server (SLES)](#patch-manager-approved-rejected-package-name-formats-sles)
### Amazon Linux 2, Amazon Linux 2023, Oracle Linux 및 Red Hat Enterprise Linux(RHEL)
**패키지 관리자**: DNF를 패키지 관리자로 사용하는 Amazon Linux 2023 및 RHEL 8을 제외한 YUM.
**승인된 패치**: 승인 패치에 다음을 지정할 수 있습니다.
+ Bugzilla ID, `1234567` 형식(숫자로만 구성된 문자열만 Bugzilla ID로 처리됨)
+ CVE IDs, `CVE-2018-1234567` 형식
+ Advisory ID, `RHSA-2017:0864` 및 `ALAS-2018-123` 형식
+ 패키지 이름 지정에 사용할 수 있는 구성 요소 중 하나 이상을 사용하여 구성한 패키지 이름입니다. 예를 들어 `dbus.x86_64:1:1.12.28-1.amzn2023.0.1`이라는 패키지의 구성 요소는 다음과 같습니다.
+ `name`: `dbus`
+ `architecture`: `x86_64`
+ `epoch`: `1`
+ `version`: `1.12.28`
+ `release`: `1.amzn2023.0.1`
다음과 같은 구성의 패키지 이름이 지원됩니다.
+ `name`
+ `name.arch`
+ `name-version`
+ `name-version-release`
+ `name-version-release.arch`
+ `version`
+ `version-release`
+ `epoch:version-release`
+ `name-epoch:version-release`
+ `name-epoch:version-release.arch`
+ `epoch:name-version-release.arch`
+ `name.arch:epoch:version-release`
다음은 몇 가지 예제입니다.
+ `dbus.x86_64`
+ `dbus-1.12.28`
+ `dbus-1.12.28-1.amzn2023.0.1`
+ `dbus-1:1.12.28-1.amzn2023.0.1.x86_64`
+ 또한 다음과 같이 위 형식의 단일 와일드카드가 포함된 패키지 이름 구성 요소를 지원합니다.
+ `dbus*`
+ `dbus-1.12.2*`
+ `dbus-*:1.12.28-1.amzn2023.0.1.x86_64`
**거부된 패치**: 거부 패치에 다음을 입력할 수 있습니다.
+ 패키지 이름 지정에 사용할 수 있는 구성 요소 중 하나 이상을 사용하여 구성한 패키지 이름입니다. 예를 들어 `dbus.x86_64:1:1.12.28-1.amzn2023.0.1`이라는 패키지의 구성 요소는 다음과 같습니다.
+ `name`: `dbus`
+ `architecture`; `x86_64`
+ `epoch`: `1`
+ `version`: `1.12.28`
+ `release`: `1.amzn2023.0.1`
다음과 같은 구성의 패키지 이름이 지원됩니다.
+ `name`
+ `name.arch`
+ `name-version`
+ `name-version-release`
+ `name-version-release.arch`
+ `version`
+ `version-release`
+ `epoch:version-release`
+ `name-epoch:version-release`
+ `name-epoch:version-release.arch`
+ `epoch:name-version-release.arch`
+ `name.arch:epoch:version-release`
다음은 몇 가지 예제입니다.
+ `dbus.x86_64`
+ `dbus-1.12.28`
+ `dbus-1.12.28-1.amzn2023.0.1`
+ `dbus-1:1.12.28-1.amzn2023.0.1.x86_64`
+ 또한 다음과 같이 위 형식의 단일 와일드카드가 포함된 패키지 이름 구성 요소를 지원합니다.
+ `dbus*`
+ `dbus-1.12.2*`
+ `dbus-*:1.12.28-1.amzn2023.0.1.x86_64`
### Debian Server 및 Ubuntu Server
**패키지 관리자**: APT
**승인된 패치**와 **거부된 패치**: 승인 패치와 거부 패치 모두에 다음을 지정할 수 있습니다.
+ 패키지 이름, `ExamplePkg33` 형식
**참고**
Debian Server 목록 및 Ubuntu Server 목록의 경우 아키텍처나 버전 등의 요소가 포함되지 않습니다. 예를 들어 패치 목록에 다음을 모두 포함시키려면 `ExamplePkg33` 패키지 이름을 지정합니다.
`ExamplePkg33.x86.1`
`ExamplePkg33.x86.2`
`ExamplePkg33.x64.1`
`ExamplePkg33.3.2.5-364.noarch`
### SUSE Linux Enterprise Server (SLES)
**패키지 관리자**: Zypper
**승인된 패치**와 **거부된 패치**: 승인 패치와 거부 패치 목록 모두에 다음을 지정할 수 있습니다.
+ 전체 패키지 이름, 형식 예:
+ `SUSE-SLE-Example-Package-15-2023-123`
+ `example-pkg-2023.15.4-46.17.1.x86_64.rpm`
+ 와일드카드 한 개를 포함하는 패키지 이름, 예:
+ `SUSE-SLE-Example-Package-15-2023-*`
+ `example-pkg-2023.15.4-46.17.1.*.rpm`
## macOS의 패키지 이름 형식
**지원되는 패키지 관리자**: 소프트웨어 업데이트, 설치 관리자, Brew, Brew Cask
[**승인된 패치(Approved patches)**] 및 [**거부된 패치(rejected patches)**]: : 승인된 패치 목록과 거부된 패치 목록 모두에 대해 다음과 같은 형식으로 전체 패키지 이름을 지정합니다.
+ `XProtectPlistConfigData`
+ `MRTConfigData`
macOS에 대한 승인된 패치 및 거부된 패치 목록에서는 와일드카드가 지원되지 않습니다.
## Windows 운영 체제의 패키지 이름 형식
Windows 운영 체제의 경우 Microsoft Knowledge Base ID와 Microsoft Security Bulletin ID를 사용하여 패치를 지정합니다. 다음 예를 참조하세요.
```
KB2032276,KB2124261,MS10-048
```
# 패치 그룹
**참고**
패치 그룹은 *패치 정책*을 기반으로 하는 패치 적용 작업에 사용되지 않습니다. 패치 정책 작업에 대한 자세한 내용은 [Quick Setup의 패치 정책 구성](patch-manager-policies.md) 섹션을 참조하세요.
2022년 12월 22일에 패치 정책 지원이 릴리스될 당시에 패치 그룹을 사용하고 있지 않았던 계정-리전 페어에 대해서는 콘솔에서 패치 그룹 기능이 지원되지 않습니다. 이 날짜 이전에 패치 그룹을 사용하기 시작한 계정-리전 페어에서는 패치 그룹 기능을 계속 사용할 수 있습니다.
*패치 그룹*을 사용하여 AWS Systems Manager의 도구인 Patch Manager에서 관리형 노드를 특정 패치 기준과 연결할 수 있습니다. 패치 그룹을 사용하면 연결된 패치 기준 규칙을 기반으로 적절한 패치를 정확하게 해당 노드 집합에 배포할 수 있습니다. 패치 그룹은 거치기 전에 패치를 배포하는 것을 방지하는 데도 도움이 됩니다. 예를 들어 다양한 환경(예: 개발, 테스트 및 프로덕션)에 필요한 패치 그룹을 만들고 적절한 패치 기준에 각 패치 그룹을 등록할 수 있습니다.
`AWS-RunPatchBaseline` 또는 패치 작업을 위한 기타 SSM 명령 문서를 실행하면 ID 또는 태그를 사용하여 관리형 노드를 대상으로 지정할 수 있습니다. SSM Agent와 Patch Manager는 관리형 노드에 추가한 패치 그룹 값에 따라 사용할 패치 기준을 판단합니다.
## 태그를 사용하여 패치 그룹 정의
[하이브리드 및 멀티클라우드](operating-systems-and-machine-types.md#supported-machine-types) 환경의 Amazon Elastic Compute Cloud(Amazon EC2) 인스턴스와 비 EC2 노드에 적용된 태그를 사용하여 패치 그룹을 생성합니다. 패치 그룹에 태그를 사용하는 방법에 대한 다음 세부 정보를 참고하세요.
+
패치 그룹은 관리형 노드에 적용된 태그 키 `Patch Group` 또는 `PatchGroup`을 사용하여 정의해야 합니다. 패치 기준에 패치 그룹을 등록할 때 이 두 키에 지정된 동일한 *값*은 동일한 그룹의 일부로 해석됩니다. 예를 들어 다음 키-값 페어 중 첫 번째 페어로 노드 5개의 태그를 지정하고 두 번째 페어로 노드 5개의 태그를 지정했다고 가정해 보겠습니다.
+ `key=PatchGroup,value=DEV`
+ `key=Patch Group,value=DEV`
기준을 생성하는 Patch Manager 명령은 `DEV` 값을 기반으로 이러한 10개의 관리형 노드를 단일 그룹으로 결합합니다. 패치 그룹의 패치 기준을 생성하는 명령과 동등한 AWS CLI 명령은 다음과 같습니다.
```
aws ssm register-patch-baseline-for-patch-group \
--baseline-id pb-0c10e65780EXAMPLE \
--patch-group DEV
```
다른 키의 값을 단일 대상으로 결합하는 작업은 새 패치 그룹을 생성하기 위한 이 Patch Manager 명령에 고유하며 다른 API 작업에서는 지원되지 않습니다. 예를 들어 값이 동일한 `PatchGroup` 및 `Patch Group` 키를 사용하여 [https://docs.aws.amazon.com/cli/latest/reference/ssm/send-command.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/send-command.html) 작업을 실행하는 경우 완전히 다른 두 개의 노드 세트를 대상으로 합니다.
```
aws ssm send-command \
--document-name AWS-RunPatchBaseline \
--targets "Key=tag:PatchGroup,Values=DEV"
```
```
aws ssm send-command \
--document-name AWS-RunPatchBaseline \
--targets "Key=tag:Patch Group,Values=DEV"
```
+ 태그 기반 대상 지정에는 제한이 있습니다. `SendCommand`의 각 대상 배열은 최대 5개의 키-값 페어를 포함할 수 있습니다.
+ `PatchGroup`(공백 없음) 또는 `Patch Group`(공백 포함) 중 이러한 태그 키 규칙 중 하나만 선택하는 것이 좋습니다. 하지만 인스턴스의 [EC2 인스턴스 메타데이터에 태그를 허용](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html#allow-access-to-tags-in-IMDS)한 경우 `PatchGroup`을 사용해야 합니다.
+ 키는 대/소문자를 구분합니다. '웹 서버' 또는 'US-EAST-PROD'와 같이 해당 그룹의 리소스를 식별하고 대상으로 지정하는 데 도움이 되는 *값*을 지정할 수 있지만 키는 `Patch Group` 또는 `PatchGroup`이어야 합니다.
패치 그룹 및 태그 관리형 노드를 생성한 이후 패치 그룹을 패치 기준선에 등록할 수 있습니다. 패치 기준으로 패치 그룹을 등록하면 패치 그룹 내부의 노드가 연결된 패치 기준에 정의된 규칙을 사용합니다.
패치 그룹을 생성하고 패치 기준에 연결하는 방법에 대한 자세한 내용은 [패치 그룹 생성 및 관리](patch-manager-tag-a-patch-group.md) 및 [패치 기준에 패치 그룹 추가](patch-manager-tag-a-patch-group.md#sysman-patch-group-patchbaseline)를 참조하세요.
AWS Command Line Interface(AWS CLI)를 사용하여 패치 기준 및 패치 그룹을 생성하는 방법을 보려면 [자습서: AWS CLI를 사용한 서버 환경에 패치 적용](patch-manager-patch-servers-using-the-aws-cli.md) 섹션을 참조하세요. Amazon EC2 태그에 대한 자세한 내용은 *Amazon EC2 사용 설명서*의 [Amazon EC2 리소스에 태그 지정](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html)을 참조하세요.
## 작동 방법
시스템이 패치 기준을 관리형 노드에 적용하기 위해 태스크를 실행하면 SSM Agent는 패치 그룹 값이 해당 노드에 대해 정의되었는지 확인합니다. 노드가 패치 그룹에 할당되는 경우 Patch Manager는 이제 그 그룹에 등록되는 패치 기준을 확인합니다. 해당 그룹에 대한 패치 기준이 검색되면 Patch Manager는 SSM Agent에 해당 패치 기준 사용을 알립니다. 노드가 패치 그룹에 대해 구성되지 않은 경우 Patch Manager는 SSM Agent에 현재 구성된 기본 패치 기준을 자동으로 사용함을 알립니다.
**중요**
관리형 노드는 하나의 패치 그룹에만 있을 수 있습니다.
패치 그룹은 각 운영 체제 유형에 대해 하나의 패치 기준에만 등록할 수 있습니다.
**Allow tags in instance metadata**(인스턴스 메타데이터의 태그 허용) 옵션이 인스턴스에서 활성화된 경우 `Patch Group` 태그(공백 포함)를 Amazon EC2 인스턴스에 적용할 수 없습니다. 인스턴스 메타데이터에서 태그를 허용하면 태그 키 이름에 공백이 포함되지 않습니다. [EC2 인스턴스 메타데이터에 태그를 허용](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html#allow-access-to-tags-in-IMDS)한 경우 태그 키 `PatchGroup`(공백 없음)을 사용해야 합니다.
**다이어그램 1: 패치 작업 프로세스 흐름의 일반적인 예**
다음 그림은 Patch Manager를 사용하여 패치하기 위해 Run Command 태스크를 서버 플릿으로 보낼 때 Systems Manager가 수행하는 프로세스의 일반적인 예를 보여줍니다. 이러한 프로세스는 패치 작업에서 사용할 패치 기준을 결정합니다. (유지 관리 기간이 Patch Manager를 사용하여 패치할 명령을 보내도록 구성된 경우에도 유사한 프로세스가 사용됩니다.)
전체 프로세스는 그림 아래에 설명되어 있습니다.
![\[패치 작업을 수행할 때 사용할 패치 기준을 결정하기 위한 Patch Manager 워크플로입니다.\]](http://docs.aws.amazon.com/ko_kr/systems-manager/latest/userguide/images/patch-groups-how-it-works.png)
이 예제에서는 다음 태그가 적용된 세 개의 Windows Server용 EC2 인스턴스 그룹이 있습니다.
****
| EC2 인스턴스 그룹 | Tags |
| --- | --- |
| 그룹 1 | `key=OS,value=Windows` `key=PatchGroup,value=DEV` |
| 그룹 2 | `key=OS,value=Windows` |
| 그룹 3 | `key=OS,value=Windows` `key=PatchGroup,value=QA` |
이 예에서는 2개의 Windows Server 패치 기준도 있습니다.
****
| 패치 기준 ID | Default | 연결된 패치 그룹 |
| --- | --- | --- |
| `pb-0123456789abcdef0` | 예 | `Default` |
| `pb-9876543210abcdef0` | 아니요 | `DEV` |
AWS Systems Manager의 도구인 Run Command와 Patch Manager를 사용하여 패치를 검색하거나 설치하는 일반적인 프로세스는 다음과 같습니다.
1. **패치 명령 보내기**: Systems Manager 콘솔, SDK, AWS Command Line Interface(AWS CLI) 또는 AWS Tools for Windows PowerShell을 통해 문서 `AWS-RunPatchBaseline`을 사용하여 Run Command 태스크를 보냅니다. 이 다이어그램은 태그 `key=OS,value=Windows`를 대상으로 관리된 인스턴스를 패치하기 위한 Run Command 태스크를 보여줍니다.
1. **패치 기준 결정**: SSM Agent는 EC2 인스턴스에 적용된 패치 그룹 태그를 확인하고 Patch Manager에게 해당 패치 기준을 쿼리합니다.
+ **패치 기준과 연결된 일치하는 패치 그룹 값:**
1. 그룹 1의 EC2 인스턴스에 설치된 SSM Agent는 1단계에서 지시된 명령을 수신하여 패치 작업을 시작합니다. SSM Agent는 EC2 인스턴스에 패치 그룹 태그 값 `DEV`가 적용되었는지 확인하고 Patch Manager에게 연결된 패치 기준을 쿼리합니다.
1. Patch Manager는 패치 기준 `pb-9876543210abcdef0`에 패치 그룹 `DEV`가 연결되어 있는지 확인하고 SSM Agent에 알립니다.
1. SSM Agent는 `pb-9876543210abcdef0`에 구성된 승인 규칙 및 예외를 기반으로 Patch Manager에서 패치 기준 스냅샷을 검색하고 다음 단계로 진행합니다.
+ **패치 그룹 태그가 인스턴스에 추가되지 않은 경우:**
1. 그룹 2의 EC2 인스턴스에 설치된 SSM Agent는 1단계에서 지시된 명령을 수신하여 패치 작업을 시작합니다. SSM Agent는 EC2 인스턴스에 `Patch Group` 또는 `PatchGroup` 태그가 적용되지 않았음을 확인하고 그에 따라 SSM Agent는 Patch Manager에 기본 Windows 패치 기준선을 쿼리합니다.
1. Patch Manager는 기본 Windows Server 패치 기준이 `pb-0123456789abcdef0`인지 확인하고 SSM Agent에 알립니다.
1. SSM Agent는 기본 패치 기준 `pb-0123456789abcdef0`에 구성된 승인 규칙 및 예외를 기반으로 Patch Manager에서 패치 기준 스냅샷을 검색하고 다음 단계로 진행합니다.
+ **패치 기준과 연결된 일치하는 패치 그룹 값이 없는 경우:**
1. 그룹 3의 EC2 인스턴스에 설치된 SSM Agent는 1단계에서 지시된 명령을 수신하여 패치 작업을 시작합니다. SSM Agent는 EC2 인스턴스에 패치 그룹 태그 값 `QA`가 적용되었는지 확인하고 Patch Manager에게 연결된 패치 기준을 쿼리합니다.
1. Patch Manager는 패치 그룹 `QA`가 연결되어 있는 패치 기준을 찾지 못합니다.
1. Patch Manager는 SSM Agent에게 기본 Windows 패치 기준 `pb-0123456789abcdef0`을 사용할 것을 알립니다.
1. SSM Agent는 기본 패치 기준 `pb-0123456789abcdef0`에 구성된 승인 규칙 및 예외를 기반으로 Patch Manager에서 패치 기준 스냅샷을 검색하고 다음 단계로 진행합니다.
1. **패치 스캔 또는 설치**: 사용할 적절한 패치 기준을 결정한 후 SSM Agent는 1단계에서 지정한 작업 값을 기준으로 패치를 스캔하거나 설치합니다. 검사 또는 설치되는 패치는 Patch Manager가 제공하는 패치 기준 스냅샷에 정의된 승인 규칙 및 패치 예외에 의해 결정됩니다.
**추가 정보**
+ [패치 규정 준수 상태 값](patch-manager-compliance-states.md)
# Microsoft에서 Windows Server에 릴리스한 애플리케이션 패치 적용
이 주제의 정보를 사용하여 AWS Systems Manager의 도구인 Patch Manager로 Windows Server 기반 애플리케이션에 패치를 적용할 준비를 합니다.
**Microsoft 애플리케이션 패치**
Windows Server 관리형 노드의 애플리케이션에 대한 패치 지원은 Microsoft에서 릴리스한 애플리케이션으로 제한됩니다.
**참고**
경우에 따라 Microsoft는 업데이트된 날짜와 시간을 지정하지 않는 애플리케이션에 대한 패치를 릴리스합니다. 이 경우 업데이트된 `01/01/1970`의 날짜 및 시간은 기본적으로 제공됩니다.
**Microsoft에서 릴리스한 애플리케이션 패치를 위한 패치 기준**
Windows Server에는 3개의 미리 정의된 패치 기준이 제공됩니다. 패치 기준 `AWS-DefaultPatchBaseline` 및 `AWS-WindowsPredefinedPatchBaseline-OS`는 Windows 운영 체제 자체에서 운영 체제 업데이트만 지원합니다. `AWS-DefaultPatchBaseline`은 다른 패치 기준을 지정하지 않는 한 Windows Server 관리형 노드의 기본 패치 기준으로 사용됩니다. 이러한 두 패치 기준의 구성 설정은 동일합니다. 둘 중 더 새로운 `AWS-WindowsPredefinedPatchBaseline-OS`는 Windows Server에 대해 미리 정의된 세 번째 패치 기준과 구별하기 위해 생성되었습니다. 해당 패치 기준인 `AWS-WindowsPredefinedPatchBaseline-OS-Applications`는 Windows Server 운영 체제 및 Microsoft에서 릴리스한 지원되는 애플리케이션을 패치하는 데 사용될 수 있습니다.
Microsoft에서 릴리스한 Windows Server 시스템 기반 애플리케이션을 업데이트하는 사용자 정의 패치 기준을 생성할 수도 있습니다.
**Microsoft에서 릴리스한 온프레미스 서버, 엣지 디바이스, VM 및 기타 비EC2 노드 기반 애플리케이션 패치에 대한 지원**
Microsoft에서 릴리스한 가상 머신 및 기타 비 EC2 관리형 노드의 애플리케이션에 패치를 적용하려면 고급 인스턴스 티어를 설정해야 합니다. 고급 인스턴스 티어를 사용하는 데는 요금이 부과됩니다. **그러나 Microsoft에서 릴리스한 Amazon Elastic Compute Cloud(Amazon EC2) 인스턴스 기반 애플리케이션을 패치하는 데는 추가 요금이 부과되지 않습니다.** 자세한 내용은 [인스턴스 티어 구성](fleet-manager-configure-instance-tiers.md) 섹션을 참조하세요.
**“다른 Microsoft 제품”에 대한 Windows 업데이트 옵션**
Patch Manager가 Microsoft에서 릴리스한 Windows Server 관리형 노드 기반 애플리케이션을 패치할 수 있도록 관리형 노드에서 Windows 업데이트 옵션 **Windows를 업데이트할 때 다른 Microsoft 제품에 대한 업데이트 제공(Give me updates for other Microsoft products when I update Windows)**을 활성화해야 합니다.
단일 관리형 노드에서 이 옵션 허용에 대한 자세한 내용은 Microsoft Support 웹 사이트의 [Microsoft 업데이트를 사용하여 Office 업데이트](https://support.microsoft.com/en-us/office/update-office-with-microsoft-update-f59d3f9d-bd5d-4d3b-a08e-1dd659cf5282)를 참조하세요.
Windows Server 2016 이상을 실행하는 관리형 노드 플릿의 경우 그룹 정책 객체(GPO)를 사용하여 설정을 켤 수 있습니다. 그룹 정책 관리 편집기에서 [**컴퓨터 구성(Computer Configuration)**], [**관리 템플릿(Administrative Templates)**], [**Windows 구성 요소(Windows Components)**], [**Windows 업데이트(Windows Updates)**]로 이동하고 [**다른 Microsoft 제품에 대한 업데이트 설치(Install updates for other Microsoft products)**]를 선택합니다. 또한 계획되지 않은 자동 업데이트 및 Patch Manager 외부 재부팅을 방지하는 추가 파라미터를 사용하여 GPO를 구성하는 것이 좋습니다. 자세한 내용은 Microsoft 기술 문서 웹 사이트의 [Non-Active Directory 환경에서 자동 업데이트 구성](https://docs.microsoft.com/de-de/security-updates/windowsupdateservices/18127499)을 참조하세요.
Windows Server 2012 또는 2012 R2를 실행하는 관리형 노드 플릿의 경우 Microsoft Docs 블로그 웹 사이트의 [Enabling and Disabling Microsoft Update in Windows 7 via Script](https://docs.microsoft.com/en-us/archive/blogs/technet/danbuche/enabling-and-disabling-microsoft-update-in-windows-7-via-script)에 설명된 대로 스크립트를 사용하여 옵션을 설정할 수 있습니다. 예를 들어 다음을 수행할 수 있습니다.
1. 블로그 게시물의 스크립트를 파일로 저장합니다.
1. 파일을 Amazon Simple Storage Service(Amazon S3) 버킷 또는 기타 액세스 가능한 위치에 업로드합니다.
1. AWS Systems Manager의 도구인 Run Command로 다음과 같은 명령에 Systems Manager 문서(SSM 문서) `AWS-RunPowerShellScript`를 사용하여 관리형 노드에서 스크립트를 실행합니다.
```
Invoke-WebRequest `
-Uri "https://s3.aws-api-domain/amzn-s3-demo-bucket/script.vbs" `
-Outfile "C:\script.vbs" cscript c:\script.vbs
```
**최소 파라미터 요구 사항**
사용자 정의 패치 기준에 Microsoft에서 릴리스한 애플리케이션을 포함하려면 최소한 패치할 제품을 지정해야 합니다. 다음 AWS Command Line Interface(AWS CLI) 명령은 Microsoft Office 2016과 같이 제품을 패치하는 데 필요한 최소 요구 사항을 보여줍니다.
------
#### [ Linux & macOS ]
```
aws ssm create-patch-baseline \
--name "My-Windows-App-Baseline" \
--approval-rules "PatchRules=[{PatchFilterGroup={PatchFilters=[{Key=PRODUCT,Values='Office 2016'},{Key=PATCH_SET,Values='APPLICATION'}]},ApproveAfterDays=5}]"
```
------
#### [ Windows Server ]
```
aws ssm create-patch-baseline ^
--name "My-Windows-App-Baseline" ^
--approval-rules "PatchRules=[{PatchFilterGroup={PatchFilters=[{Key=PRODUCT,Values='Office 2016'},{Key=PATCH_SET,Values='APPLICATION'}]},ApproveAfterDays=5}]"
```
------
Microsoft 애플리케이션 제품군을 지정하는 경우, 지정하는 각 제품은 선택한 제품군의 지원 구성원이어야 합니다. 예를 들어 "Active Directory 권한 관리 서비스 클라이언트 2.0" 제품을 패치하려면 해당 제품군을 "Office"또는 "SQL Server"가 아닌 "Active Directory"로 지정해야 합니다. 다음 AWS CLI 명령은 제품군 및 제품으로 구성된 일치된 페어를 보여줍니다.
------
#### [ Linux & macOS ]
```
aws ssm create-patch-baseline \
--name "My-Windows-App-Baseline" \
--approval-rules "PatchRules=[{PatchFilterGroup={PatchFilters=[{Key=PRODUCT_FAMILY,Values='Active Directory'},{Key=PRODUCT,Values='Active Directory Rights Management Services Client 2.0'},{Key=PATCH_SET,Values='APPLICATION'}]},ApproveAfterDays=5}]"
```
------
#### [ Windows Server ]
```
aws ssm create-patch-baseline ^
--name "My-Windows-App-Baseline" ^
--approval-rules "PatchRules=[{PatchFilterGroup={PatchFilters=[{Key=PRODUCT_FAMILY,Values='Active Directory'},{Key=PRODUCT,Values='Active Directory Rights Management Services Client 2.0'},{Key=PATCH_SET,Values='APPLICATION'}]},ApproveAfterDays=5}]"
```
------
**참고**
일치하지 않는 제품 및 제품군 페어링에 대한 오류 메시지가 표시되는 경우 [문제: 일치하지 않는 제품군/제품 페어](patch-manager-troubleshooting.md#patch-manager-troubleshooting-product-family-mismatch)에서 문제 해결을 위한 도움말을 찾아보세요.
# Amazon Linux 2 관리형 노드에서 Kernel Live Patching 사용
Amazon Linux 2용 Kernel Live Patching을 사용하면 실행 중인 애플리케이션을 재부팅하거나 중단하지 않고 실행 중인 Linux 커널에 보안 취약성 및 중요 버그 패치를 적용할 수 있습니다. 이를 통해 서비스 및 애플리케이션 가용성을 향상하는 동시에 인프라를 최신 상태로 안전하게 유지할 수 있습니다. Kernel Live Patching은 Amazon EC2 인스턴스와 Amazon Linux 2를 실행하는 AWS IoT Greengrass 코어 디바이스, [온프레미스 가상 머신](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/amazon-linux-2-virtual-machine.html)에서 지원됩니다.
Kernel Live Patching에 대한 일반적인 내용은 *Amazon Linux 2 사용 설명서*에서 [AL2의 Kernel Live Patching](https://docs.aws.amazon.com/linux/al2/ug/al2-live-patching.html)을 참조하세요.
Amazon Linux 2 관리형 노드에서 Kernel Live Patching을 설정한 후 AWS Systems Manager의 도구인 Patch Manager를 사용하여 커널 라이브 패치를 인스턴스에 적용할 수 있습니다. 노드에서 기존 yum 워크플로를 사용하여 업데이트를 적용하는 대신 Patch Manager를 사용할 수 있습니다.
**시작하기 전 준비 사항**
Patch Manager를 사용하여 커널 라이브 패치를 Amazon Linux 2 관리형 노드에 적용하려면 노드가 올바른 아키텍처와 커널 버전을 기반으로 해야 합니다. 자세한 내용은 *Amazon EC2 사용 설명서*의 [지원되는 구성 및 사전 조건](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/al2-live-patching.html#al2-live-patching-prereq)을 참조하세요.
**Topics**
+ [Patch Manager를 사용하는 Kernel Live Patching](#about-klp)
+ [Patch Manager를 사용하는 Kernel Live Patching의 작동 방식](#how-klp-works)
+ [Run Command를 사용하여 Kernel Live Patching 설정](enable-klp.md)
+ [Run Command을 사용하여 커널 라이브 패치 적용](install-klp.md)
+ [Run Command를 사용하여 Kernel Live Patching을 해제하려면](disable-klp.md)
## Patch Manager를 사용하는 Kernel Live Patching
커널 버전 업데이트
커널 라이브 패치 업데이트를 적용한 후 관리형 노드를 재부팅할 필요가 없습니다. 그러나 AWS는 릴리스 후 최대 3개월 동안 Amazon Linux 2 커널 버전에 대한 커널 라이브 패치를 제공합니다. 3개월 후 커널 라이브 패치를 계속 받으려면 최신 커널 버전으로 업데이트해야 합니다. 유지 관리 기간을 사용하여 커널 버전 업데이트를 요청하는 메시지를 표시하도록 최소 3개월에 한 번 노드 재부팅을 예약하는 것이 좋습니다.
커널 라이브 패치 제거
커널 라이브 패치는 Patch Manager를 사용하여 제거할 수 없습니다. 대신 Kernel Live Patching을 해제하여 적용된 커널 라이브 패치에 대한 RPM 패키지를 제거할 수 있습니다. 자세한 내용은 [Run Command를 사용하여 Kernel Live Patching을 해제하려면](disable-klp.md) 섹션을 참조하세요.
커널 규정 준수
경우에 따라 현재 커널 버전에 대한 라이브 패치에서 모든 CVE 수정 사항을 설치하면 해당 커널이 최신 커널 버전과 동일한 규정 준수 상태가 될 수 있습니다. 이 경우 최신 버전은 `Installed`으로 보고되고 관리형 노드는 `Compliant`로 보고됩니다. 그러나 최신 커널 버전에서는 설치 시간이 보고되지 않습니다.
하나의 커널 라이브 패치, 여러 CVE
커널 라이브 패치가 여러 CVE를 해결하고 해당 CVE가 다양한 분류 및 심각도 값을 갖는 경우, CVE에서 가장 높은 분류 및 심각도만 해당 패치에 대해 보고됩니다.
이 섹션의 나머지 부분에서는 Patch Manager를 사용하여 이러한 요구 사항을 충족하는 관리형 노드에 커널 라이브 패치를 적용하는 방법을 설명합니다.
## Patch Manager를 사용하는 Kernel Live Patching의 작동 방식
AWS는 Amazon Linux 2를 위한 2가지 유형의 커널 라이브 패치인 보안 업데이트와 버그 수정 사항을 릴리스합니다. 이러한 유형의 패치를 적용하려면 다음 표에 나열된 분류 및 심각도만 대상으로 하는 패치 기준 문서를 사용합니다.
| 분류 | 심각도 |
| --- | --- |
| Security | Critical, Important |
| Bugfix | All |
이러한 패치만 대상으로 하는 사용자 지정 패치 기준을 생성하거나, 미리 정의된 `AWS-AmazonLinux2DefaultPatchBaseline` 패치 기준을 사용할 수 있습니다. 즉, Kernel Live Patching이 설정된 Amazon Linux 2 관리형 노드에서 `AWS-AmazonLinux2DefaultPatchBaseline`을 사용할 수 있으며 커널 라이브 업데이트가 적용됩니다.
**참고**
`AWS-AmazonLinux2DefaultPatchBaseline` 구성은 패치가 릴리스되거나 마지막으로 업데이트된 후 자동으로 설치되기 전에 7일의 대기 기간을 지정합니다. 7일 동안 커널 라이브 패치 자동 승인을 기다리지 않으려면 사용자 정의 패치 기준선을 생성하여 사용합니다. 패치 기준에서 자동 승인 대기 기간을 지정하거나 더 짧거나 긴 대기 기간을 지정할 수 있습니다. 자세한 내용은 [사용자 정의 패치 기준 작업](patch-manager-manage-patch-baselines.md) 섹션을 참조하세요.
커널 라이브 업데이트로 관리형 노드를 패치하려면 다음 전략을 사용하는 것이 좋습니다.
1. Amazon Linux 2 관리형 노드에서 Kernel Live Patching 활성화
1. AWS Systems Manager의 도구인 Run Command를 사용하여 미리 정의된 `AWS-AmazonLinux2DefaultPatchBaseline` 또는 심각도가 `Critical`과 `Important`로 분류되었고 `Bugfix` 심각도가 `All`인 `Security` 업데이트만 대상으로 하는 사용자 정의 패치 기준을 사용하여 관리형 노드에서 `Scan` 작업을 실행합니다.
1. AWS Systems Manager의 도구인 Compliance를 사용하여 스캔된 관리형 노드에 대해 패치 규정 미준수가 보고되는지 검토합니다. 그렇다면 노드 규정 준수 세부 정보를 보고, 관리형 노드에서 누락된 커널 라이브 패치가 있는지 확인합니다.
1. 누락된 커널 라이브 패치를 설치하려면 이전에 지정한 것과 동일한 패치 기준에서 Run Command을 사용합니다. 하지만 이번에는 `Scan` 작업 대신 `Install` 작업을 실행합니다.
커널 라이브 패치는 재부팅할 필요 없이 설치되므로 이 작업에 대해 `NoReboot` 재부팅 옵션을 선택할 수 있습니다.
**참고**
노드에 설치된 다른 유형의 패치가 필요하거나 최신 커널로 업데이트하려는 경우에도 관리형 노드를 재부팅할 수 있습니다. 이러한 경우 `RebootIfNeeded` 재부팅 옵션을 대신 선택합니다.
1. 규정 준수로 돌아가서 커널 라이브 패치가 설치되었는지 확인합니다.
# Run Command를 사용하여 Kernel Live Patching 설정
Kernel Live Patching을 설정하기 위해 관리형 노드에서 `yum` 명령을 실행하거나 Run Command와 생성한 사용자 정의 Systems Manager 문서(SSM 문서)를 사용할 수 있습니다.
관리형 노드에서 직접 `yum` 명령을 실행하여 Kernel Live Patching을 켜는 것에 대한 자세한 내용은 *Amazon EC2 사용 설명서*의 [Kernel Live Patching 활성화](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/al2-live-patching.html#al2-live-patching-prereq)를 참조하세요.
**참고**
커널 라이브 패칭을 설정할 때 관리형 노드에서 이미 실행 중인 커널이 `kernel-4.14.165-131.185.amzn2.x86_64`(지원되는 최소 버전)보다 *이전* 버전이면 프로세스가 사용 가능한 최신 커널 버전을 설치하고 관리형 노드를 재부팅합니다. 노드가 `kernel-4.14.165-131.185.amzn2.x86_64` 이상을 이미 실행하고 있는 경우 프로세스가 최신 버전을 설치하지 않고 노드를 재부팅하지 않습니다.
**Run Command를 사용하여 Kernel Live Patching을 설정하려면(콘솔)**
1. AWS Systems Manager 콘솔([https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/))을 엽니다.
1. 탐색 창에서 **Run Command**를 선택합니다.
1. **Run command**(Run 명령)를 선택합니다.
1. [**Command 문서(Command document)**] 목록에서 사용자 정의 SSM 문서 `AWS-ConfigureKernelLivePatching`을 선택합니다.
1. **명령 파라미터** 섹션에서 이 작업의 일부로 관리형 노드를 재부팅할지 여부를 지정합니다.
1. 이 페이지의 나머지 컨트롤 작업에 대한 자세한 내용은 [콘솔에서 명령 실행](running-commands-console.md) 섹션을 참조하세요.
1. **Run(실행)**을 선택합니다.
**Kernel Live Patching을 설정하려면(AWS CLI)**
+ 로컬 시스템에서 다음 명령을 실행합니다.
------
#### [ Linux & macOS ]
```
aws ssm send-command \
--document-name "AWS-ConfigureKernelLivePatching" \
--parameters "EnableOrDisable=Enable" \
--targets "Key=instanceids,Values=instance-id"
```
------
#### [ Windows Server ]
```
aws ssm send-command ^
--document-name "AWS-ConfigureKernelLivePatching" ^
--parameters "EnableOrDisable=Enable" ^
--targets "Key=instanceids,Values=instance-id"
```
------
*instance-id*를 기능을 설정할 Amazon Linux 2 관리형 노드의 ID로 바꿉니다(예: i-02573cafcfEXAMPLE). 여러 관리형 노드에서 기능을 설정하기 위해 다음 형식 중 하나를 사용할 수 있습니다.
+ `--targets "Key=instanceids,Values=instance-id1,instance-id2"`
+ `--targets "Key=tag:tag-key,Values=tag-value"`
명령에서 사용할 수 있는 기타 옵션에 대한 자세한 내용은 **AWS CLI 명령 레퍼런스의 [https://docs.aws.amazon.com/cli/latest/reference/ssm/send-command.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/send-command.html) 를 참조하세요.
# Run Command을 사용하여 커널 라이브 패치 적용
커널 라이브 패치를 적용하기 위해 관리형 노드에서 `yum` 명령을 실행하거나, Run Command 및 SSM 문서 `AWS-RunPatchBaseline`을 사용할 수 있습니다.
관리형 노드에서 직접 `yum` 명령을 실행하여 커널 라이브 패치를 적용하는 것에 대한 자세한 내용은 *Amazon EC2 사용 설명서*의 [커널 라이브 패치 적용](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/al2-live-patching.html#al2-live-patching-apply)을 참조하세요.
**Run Command을 사용하여 커널 라이브 패치를 적용하려면(콘솔)**
1. AWS Systems Manager 콘솔([https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/))을 엽니다.
1. 탐색 창에서 **Run Command**를 선택합니다.
1. **Run command**(Run 명령)를 선택합니다.
1. [**Command 문서(Command document)**] 목록에서 SSM 문서 `AWS-RunPatchBaseline`을 선택합니다.
1. **명령 파라미터** 섹션에서 다음 중 하나를 수행합니다.
+ 새 커널 라이브 패치가 사용 가능한지 확인하려는 경우 [**작업(Operation)**]에서 [`Scan`]을 선택합니다. 이 작업 후에 관리형 노드를 재부팅하지 않으려면 **재부팅 옵션(Reboot Option)**에서 `NoReboot`를 선택합니다. 작업이 완료되면 Compliance에서 새 패치 및 규정 준수 상태를 확인할 수 있습니다.
+ 패치 규정 준수를 이미 확인하고 사용 가능한 커널 라이브 패치를 적용할 준비가 된 경우 **작업**에서 `Install`를 선택합니다. 이 작업 후에 관리형 노드를 재부팅하지 않으려면 **재부팅 옵션(Reboot Option)**에서 `NoReboot`를 선택합니다.
1. 이 페이지의 나머지 컨트롤 작업에 대한 자세한 내용은 [콘솔에서 명령 실행](running-commands-console.md) 섹션을 참조하세요.
1. **Run(실행)**을 선택합니다.
**Run Command을 사용하여 커널 라이브 패치를 적용하려면(AWS CLI)**
1. Compliance에서 결과를 확인하기 전에 `Scan` 작업을 수행하려면 로컬 시스템에서 다음 명령을 실행합니다.
------
#### [ Linux & macOS ]
```
aws ssm send-command \
--document-name "AWS-RunPatchBaseline" \
--targets "Key=InstanceIds,Values=instance-id" \
--parameters '{"Operation":["Scan"],"RebootOption":["RebootIfNeeded"]}'
```
------
#### [ Windows Server ]
```
aws ssm send-command ^
--document-name "AWS-RunPatchBaseline" ^
--targets "Key=InstanceIds,Values=instance-id" ^
--parameters {\"Operation\":[\"Scan\"],\"RebootOption\":[\"RebootIfNeeded\"]}
```
------
명령에서 사용할 수 있는 기타 옵션에 대한 자세한 내용은 **AWS CLI 명령 레퍼런스의 [https://docs.aws.amazon.com/cli/latest/reference/ssm/send-command.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/send-command.html) 를 참조하세요.
1. Compliance에서 결과를 확인한 후 `Install` 작업을 수행하려면 로컬 시스템에서 다음 명령을 실행합니다.
------
#### [ Linux & macOS ]
```
aws ssm send-command \
--document-name "AWS-RunPatchBaseline" \
--targets "Key=InstanceIds,Values=instance-id" \
--parameters '{"Operation":["Install"],"RebootOption":["NoReboot"]}'
```
------
#### [ Windows Server ]
```
aws ssm send-command ^
--document-name "AWS-RunPatchBaseline" ^
--targets "Key=InstanceIds,Values=instance-id" ^
--parameters {\"Operation\":[\"Install\"],\"RebootOption\":[\"NoReboot\"]}
```
------
앞의 두 명령 모두에서 *instance-id*를 커널 라이브 패치를 적용할 Amazon Linux 2 관리형 노드의 ID로 바꿉니다(예: i-02573cafcfEXAMPLE). 여러 관리형 노드에서 기능을 설정하기 위해 다음 형식 중 하나를 사용할 수 있습니다.
+ `--targets "Key=instanceids,Values=instance-id1,instance-id2"`
+ `--targets "Key=tag:tag-key,Values=tag-value"`
이러한 명령에서 사용할 수 있는 기타 옵션에 대한 자세한 내용은 **AWS CLI 명령 레퍼런스의 [https://docs.aws.amazon.com/cli/latest/reference/ssm/send-command.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/send-command.html) 를 참조하세요.
# Run Command를 사용하여 Kernel Live Patching을 해제하려면
Kernel Live Patching을 해제하기 위해 관리형 노드에서 `yum` 명령을 실행하거나, Run Command 및 사용자 정의 SSM 문서 `AWS-ConfigureKernelLivePatching`을 사용할 수 있습니다.
**참고**
커널 라이브 패치를 더 이상 사용할 필요가 없는 경우 언제든지 해제할 수 있습니다. 대부분의 경우 이 기능을 해제할 필요가 없습니다.
관리형 노드에서 직접 `yum` 명령을 실행하여 Kernel Live Patching 설정을 비활성화하는 것에 대한 자세한 내용은 *Amazon EC2 사용 설명서*의 [Kernel Live Patching 활성화](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/al2-live-patching.html#al2-live-patching-enable)를 참조하세요.
**참고**
Kernel Live Patching을 해제하면 프로세스가 Kernel Live Patching 플러그인을 제거하고 관리형 노드를 재부팅합니다.
**Run Command를 사용하여 Kernel Live Patching을 해제하려면(콘솔)**
1. AWS Systems Manager 콘솔([https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/))을 엽니다.
1. 탐색 창에서 **Run Command**를 선택합니다.
1. **Run command**(Run 명령)를 선택합니다.
1. [**Command 문서(Command document)**] 목록에서 SSM 문서 `AWS-ConfigureKernelLivePatching`을 선택합니다.
1. **명령 파라미터** 섹션에서 필요한 파라미터의 값을 지정합니다.
1. 이 페이지의 나머지 컨트롤 작업에 대한 자세한 내용은 [콘솔에서 명령 실행](running-commands-console.md) 섹션을 참조하세요.
1. **Run(실행)**을 선택합니다.
**Kernel Live Patching을 해제하려면(AWS CLI)**
+ 다음과 유사한 명령을 실행합니다.
------
#### [ Linux & macOS ]
```
aws ssm send-command \
--document-name "AWS-ConfigureKernelLivePatching" \
--targets "Key=instanceIds,Values=instance-id" \
--parameters "EnableOrDisable=Disable"
```
------
#### [ Windows Server ]
```
aws ssm send-command ^
--document-name "AWS-ConfigureKernelLivePatching" ^
--targets "Key=instanceIds,Values=instance-id" ^
--parameters "EnableOrDisable=Disable"
```
------
*instance-id*를 기능을 비활성화할 Amazon Linux 2 관리형 노드의 ID로 바꿉니다(예: i-02573cafcfEXAMPLE). 여러 관리형 노드에서 기능을 비활성화하기 위해 다음 형식 중 하나를 사용할 수 있습니다.
+ `--targets "Key=instanceids,Values=instance-id1,instance-id2"`
+ `--targets "Key=tag:tag-key,Values=tag-value"`
명령에서 사용할 수 있는 기타 옵션에 대한 자세한 내용은 **AWS CLI 명령 레퍼런스의 [https://docs.aws.amazon.com/cli/latest/reference/ssm/send-command.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/send-command.html) 를 참조하세요.
# 콘솔을 사용하여 Patch Manager 리소스 및 규정 준수 작업
AWS Systems Manager의 도구인 Patch Manager를 사용하려면 다음 태스크를 완료합니다. 이러한 작업은 이 단원에서 더 자세히 설명합니다.
1. 사용 중인 각 운영 체제 유형에 따라 AWS 미리 정의된 패치 기준이 필요를 충족하는지 확인하십시오. 그렇지 않은 경우 해당 관리형 노드 유형에 대한 표준 패치 집합을 정의하는 패치 기준을 생성하고, 기본값으로 설정합니다.
1. Amazon Elastic Compute Cloud(Amazon EC2) 태그를 사용하여 관리형 노드를 패치 그룹으로 구성합니다(옵션이지만 권장됨).
1. 다음 중 하나를 수행하세요.
+ (권장) Systems Manager의 도구인 Quick Setup에서 패치 정책을 구성하여 전체 조직, 일부 조직 단위 또는 단일 AWS 계정의 일정에 따라 누락된 패치를 설치할 수 있습니다. 자세한 내용은 [Quick Setup 패치 정책을 사용한 조직 내 인스턴스에 대한 패치 적용 구성](quick-setup-patch-manager.md) 섹션을 참조하세요.
+ Run Command 태스크 유형에서 Systems Manager 문서(SSM 문서) `AWS-RunPatchBaseline`을 사용하는 유지 관리 기간을 생성합니다. 자세한 내용은 [자습서: 콘솔을 사용하여 패치를 위한 유지 관리 기간 생성](maintenance-window-tutorial-patching.md) 섹션을 참조하세요.
+ Run Command 작업에서 `AWS-RunPatchBaseline`을 수동으로 실행합니다. 자세한 내용은 [콘솔에서 명령 실행](running-commands-console.md) 섹션을 참조하세요.
+ **Patch now**(지금 패치) 기능을 사용하여 필요에 따라 노드를 수동으로 패치합니다. 자세한 내용은 [관리형 노드 온디맨드 패치](patch-manager-patch-now-on-demand.md) 섹션을 참조하세요.
1. 패치 적용을 모니터링하여 규정 준수 여부를 확인하고 오류를 조사합니다.
**Topics**
+ [패치 정책 생성](patch-manager-create-a-patch-policy.md)
+ [패치 대시보드 요약 보기](patch-manager-view-dashboard-summaries.md)
+ [패치 규정 준수 보고서 작업](patch-manager-compliance-reports.md)
+ [관리형 노드 온디맨드 패치](patch-manager-patch-now-on-demand.md)
+ [패치 기준 작업](patch-manager-create-a-patch-baseline.md)
+ [사용 가능한 패치 보기](patch-manager-view-available-patches.md)
+ [패치 그룹 생성 및 관리](patch-manager-tag-a-patch-group.md)
+ [Patch Manager와 AWS Security Hub CSPM 통합](patch-manager-security-hub-integration.md)
# 패치 정책 생성
패치 정책은 AWS Systems Manager의 도구인 Quick Setup을 사용하여 설정하는 구성입니다. 패치 정책은 다른 패치 구성 방법에서 제공되는 것보다 더 광범위하고 중앙 집중화된 패치 작업 제어 기능을 제공합니다. 패치 정책은 노드와 애플리케이션에 자동으로 패치를 적용할 때 사용할 일정과 기준선을 정의합니다.
자세한 정보는 다음 주제를 참조하세요.
+ [Quick Setup의 패치 정책 구성](patch-manager-policies.md)
+ [Quick Setup 패치 정책을 사용한 조직 내 인스턴스에 대한 패치 적용 구성](quick-setup-patch-manager.md)
# 패치 대시보드 요약 보기
Patch Manager의 **대시보드** 탭에서는 통합 보기에서 패치 작업을 모니터링하는 데 사용할 수 있는 콘솔의 요약 보기를 제공합니다. Patch Manager는 AWS Systems Manager의 도구입니다. **대시보드(Dashboard)** 탭에서 다음을 볼 수 있습니다.
+ 패치 규정을 준수 및 준수하지 않는 관리형 노드의 수를 보여주는 스냅샷입니다.
+ 관리형 노드에 대한 패치 규정 준수 결과 기간에 대한 스냅샷입니다.
+ 규정 미준수의 가장 일반적인 사유 각각에 대해 규정을 준수하지 않는 관리형 노드의 연결 수입니다.
+ 최신 패치 작업의 연결된 목록입니다.
+ 설정된 반복 패치 작업의 연결된 목록입니다.
**패치 대시보드 요약을 보려면**
1. [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)에서 AWS Systems Manager 콘솔을 엽니다.
1. 탐색 창에서 **Patch Manager**를 선택합니다.
1. **대시보드(Dashboard)** 탭을 선택합니다.
1. 보고자 하는 요약 데이터가 포함된 섹션으로 스크롤합니다.
+ **Amazon EC2 인스턴스 관리**
+ **규정 준수 요약**
+ **미준수 건수**
+ **규정 준수 보고서**
+ **비패치 정책 기반 작업**
+ **비패치 정책 기반 반복 태스크**
# 패치 규정 준수 보고서 작업
다음 주제의 정보를 사용하여 패치 규정 준수 보고서를 AWS Systems Manager의 도구인 Patch Manager에 생성하고 작업할 수 있습니다.
다음 항목의 정보는 패치 작업에 사용하는 구성 방법 또는 유형에 관계없이 적용됩니다.
+ Quick Setup에서 구성된 패치 정책
+ Quick Setup에서 구성된 호스트 관리 옵션
+ 패치 `Scan` 또는 `Install` 태스크를 실행하기 위한 유지 관리 기간
+ 온디맨드 **Patch now**(지금 패치) 작업
**중요**
패치 규정 준수 보고서는 성공적인 패치 작업에 의해서만 생성되는 특정 시점 스냅샷입니다. 각 보고서에는 규정 준수 상태가 계산된 때를 식별하는 캡처 시간이 포함되어 있습니다.
인스턴스에서 패치 규정 준수를 검사하기 위해 여러 유형의 작업을 수행하는 경우, 스캔할 때마다 이전 스캔의 패치 규정 준수 데이터를 덮어씁니다. 따라서 패치 규정 준수 데이터에 예상치 못한 결과가 발생할 수 있습니다. 자세한 내용은 [패치 규정 준수 데이터를 생성한 실행 식별](patch-manager-compliance-data-overwrites.md) 섹션을 참조하세요.
최신 규정 준수 정보를 생성하는 데 어떤 패치 기준선이 사용되었는지 확인하려면, Patch Manager의 **규정 준수 보고** 탭으로 이동하여 정보를 얻으려는 관리형 노드에 해당하는 행을 찾은 다음, **사용된 기준선 ID** 열에서 기준선 ID를 선택합니다.
**Topics**
+ [패치 규정 준수 결과 보기](patch-manager-view-compliance-results.md)
+ [.csv 패치 규정 준수 보고서 생성](patch-manager-store-compliance-results-in-s3.md)
+ [Patch Manager로 규정 미준수 관리형 노드 문제 해결](patch-manager-noncompliant-nodes.md)
+ [패치 규정 준수 데이터를 생성한 실행 식별](patch-manager-compliance-data-overwrites.md)
# 패치 규정 준수 결과 보기
다음 절차를 사용하여 관리형 노드에 대한 패치 규정 준수 정보를 봅니다.
이 절차는 `AWS-RunPatchBaseline` 문서를 사용하는 패치 작업에 적용됩니다. `AWS-RunPatchBaselineAssociation` 문서를 사용하는 패치 작업에 대한 패치 규정 준수 정보 보기에 대한 자세한 내용은 [규정 미준수 관리형 노드 식별](patch-manager-find-noncompliant-nodes.md) 섹션을 참조하세요.
**참고**
Quick Setup 및 Explorer에 대한 패치 검사 작업에서는 `AWS-RunPatchBaselineAssociation` 문서를 사용합니다. Quick Setup 및 Explorer는 둘 다 AWS Systems Manager의 도구입니다.
**특정 CVE 문제에 대한 패치 솔루션 식별(Linux)**
많은 Linux 기반 운영 체제의 경우 패치 규정 준수 결과에 따라 어느 일반적인 취약성 및 노출도(CVE) 게시판 문제가 어느 패치로 해결되는지 확인할 수 있습니다. 이 정보는 누락되거나 실패한 패치를 얼마나 긴급하게 설치해야 하는지를 결정하는 데 도움이 됩니다.
다음 운영 체제 유형의 지원되는 버전에 대한 CVE 세부 정보가 포함되어 있습니다.
+ AlmaLinux
+ Amazon Linux 2
+ Amazon Linux 2023
+ Oracle Linux
+ Red Hat Enterprise Linux (RHEL)
+ Rocky Linux
**참고**
기본적으로 CentOS Stream은 업데이트에 대한 CVE 정보를 제공하지 않습니다. 그러나 Fedora가 게시하는 EPEL(Extra Packages for Enterprise Linux) 리포지토리와 같은 서드 파티 리포지토리를 사용하여 이러한 지원을 허용할 수 있습니다. 자세한 내용은 Fedora Wiki의 [EPEL](https://fedoraproject.org/wiki/EPEL)을 참조하세요.
현재 CVE ID 값은 `Missing` 또는 `Failed` 상태인 패치에 대해서만 보고됩니다.
상황과 패치 목표가 보장하는 대로 패치 기준의 승인 또는 거부된 패치 목록에 CVE ID를 추가할 수도 있습니다.
승인 및 거부된 패치 목록 작업에 대한 자세한 내용은 다음 주제를 참조하세요.
+ [사용자 정의 패치 기준 작업](patch-manager-manage-patch-baselines.md)
+ [승인 패치 및 거부 패치 목록의 패키지 이름 형식](patch-manager-approved-rejected-package-name-formats.md)
+ [Linux 기반 시스템에서 패치 기준 규칙 사용 방법](patch-manager-linux-rules.md)
+ [패치 설치 방법](patch-manager-installing-patches.md)
**참고**
경우에 따라 Microsoft는 업데이트된 날짜와 시간을 지정하지 않는 애플리케이션에 대한 패치를 릴리스합니다. 이 경우 업데이트된 `01/01/1970`의 날짜 및 시간은 기본적으로 제공됩니다.
## 패치 규정 준수 결과 보기
AWS Systems Manager 콘솔에서 패치 규정 준수 결과를 보려면 다음 절차를 따릅니다.
**참고**
Amazon Simple Storage Service(Amazon S3) 버킷에 다운로드되는 패치 규정 준수 보고서 생성에 대한 자세한 내용은 [.csv 패치 규정 준수 보고서 생성](patch-manager-store-compliance-results-in-s3.md) 섹션을 참조하세요.
**패치 규정 준수 결과를 보려면**
1. 다음 중 하나를 수행하세요.
**옵션 1**(권장) - AWS Systems Manager의 도구인 Patch Manager에서 이동합니다.
+ 탐색 창에서 **Patch Manager**를 선택합니다.
+ **규정 준수 보고(Compliance reporting)** 탭을 선택합니다.
+ **노드 패치 적용 세부 정보**에서 패치 규정 준수 결과를 검토할 관리형 노드의 노드 ID를 선택합니다. `stopped` 또는 `terminated` 상태인 노드는 여기에 표시되지 않습니다.
+ **세부 정보** 영역의 **속성** 목록에서 **패치**를 선택합니다.
**옵션 2** - AWS Systems Manager의 도구인 Compliance에서 이동합니다.
+ 탐색 창에서 **Compliance**를 선택합니다.
+ [**Compliance 리소스 요약(Compliance resources summary)**]에서 검토하려는 패치 리소스 유형의 열(예: [**규정 미준수 리소스(Non-Compliant resources)**])에서 숫자를 선택합니다.
+ 아래의 **리소스** 목록에서 패치 규정 준수 결과를 검토할 관리형 노드의 ID를 선택합니다.
+ **세부 정보** 영역의 **속성** 목록에서 **패치**를 선택합니다.
**옵션 3** - AWS Systems Manager의 도구인 Fleet Manager에서 이동합니다.
+ 탐색 창에서 **Fleet Manager**를 선택합니다.
+ **관리형 인스턴스** 영역에서 패치 규정 준수 결과를 검토할 관리형 노드의 ID를 선택합니다.
+ **세부 정보** 영역의 **속성** 목록에서 **패치**를 선택합니다.
1. (옵션) 검색 상자(![\[The Search icon\]](http://docs.aws.amazon.com/ko_kr/systems-manager/latest/userguide/images/search-icon.png))에서 사용 가능한 필터 중에서 선택합니다.
예를 들어 Red Hat Enterprise Linux(RHEL)의 경우 다음 중에서 선택합니다.
+ 이름
+ 분류
+ State
+ 심각도
Windows Server에 대해 다음 중에서 선택합니다.
+ KB
+ 분류
+ State
+ 심각도
1. 선택한 필터 유형에 사용할 수 있는 값 중 하나를 선택합니다. 예를 들어 [**상태(State)**]를 선택한 경우 [**InstalledPendingReboot**], [**실패(Failed)**], [**누락(Missing)**] 등의 규정 준수 상태를 선택합니다.
**참고**
현재 CVE ID 값은 `Missing` 또는 `Failed` 상태인 패치에 대해서만 보고됩니다.
1. 관리형 노드의 규정 준수 상태에 따라 규정을 준수하지 않는 노드를 수정하기 위해 수행할 작업을 선택할 수 있습니다.
예를 들어 미준수 관리형 노드를 즉시 패치하도록 선택할 수 있습니다. 온디맨드로 관리형 노드 패치에 대한 자세한 내용은 [관리형 노드 온디맨드 패치](patch-manager-patch-now-on-demand.md) 섹션을 참조하세요.
패치 규정 준수 상태에 대한 자세한 내용은 [패치 규정 준수 상태 값](patch-manager-compliance-states.md) 섹션을 참조하세요.
# .csv 패치 규정 준수 보고서 생성
AWS Systems Manager 콘솔을 사용하여 선택한 Amazon Simple Storage Service(Amazon S3) 버킷에 .csv 파일로 저장되는 패치 규정 준수 보고서를 생성할 수 있습니다. 단일 온디맨드 보고서를 생성하거나 보고서를 자동으로 생성하는 일정을 지정할 수 있습니다.
단일 관리형 노드 또는 선택한 모든 AWS 계정 및 AWS 리전에 대해 보고서를 생성할 수 있습니다. 단일 노드의 경우 보고서의 경우 규정을 준수하지 않는 노드와 관련된 패치의 ID를 비롯한 포괄적인 세부 정보가 포함됩니다. 모든 관리형 노드에 대한 보고서의 경우 비준수 노드의 패치 수와 요약 정보만 제공됩니다.
보고서가 생성된 후 Amazon Quick과 같은 도구를 사용하여 데이터를 가져오고 분석할 수 있습니다. Quick은 대화형 시각적 환경에서 정보를 탐색하고 해석하는 데 사용할 수 있는 비즈니스 인텔리전스(BI) 서비스입니다. 자세한 내용은 [Amazon Quick 사용 설명서](https://docs.aws.amazon.com/quicksuite/latest/userguide/what-is.html)를 참조하세요.
**참고**
사용자 지정 패치 기준선을 생성할 때 해당 패치 기준선에서 승인된 패치의 규정 준수 심각도 수준을 지정할 수 있습니다(예: `Critical` 또는 `High`). 승인된 패치의 패치 상태가 `Missing`으로 보고되는 경우 패치 기준선의 전반적인 보고된 규정 준수 심각도는 사용자가 지정한 심각도 수준입니다.
보고서가 생성될 때 알림을 보내는 데 사용할 Amazon Simple Notification Service(Amazon SNS) 주제를 지정할 수도 있습니다.
**패치 규정 준수 보고서 생성을 위한 서비스 역할**
보고서를 처음 생성할 때 Systems Manager에서는 S3로 내보내기 프로세스에 사용할 `AWS-SystemsManager-PatchSummaryExportRole`이라는 Automation 수임 역할을 생성합니다.
**참고**
규정 준수 데이터를 암호화된 S3 버킷으로 내보내는 경우 연결된 AWS KMS 키 정책을 업데이트하여 필요한 `AWS-SystemsManager-PatchSummaryExportRole` 권한을 제공해야 합니다. 인스턴스의 경우 이와 비슷한 권한을 S3 버킷의 AWS KMS 정책에 추가합니다.
```
{
"Effect": "Allow",
"Action": [
"kms:GenerateDataKey"
],
"Resource": "role-arn"
}
```
*role-arn*을 계정에서 생성된 Amazon 리소스 이름(ARN)으로 바꿉니다(형식: `arn:aws:iam::111222333444:role/service-role/AWS-SystemsManager-PatchSummaryExportRole`).
자세한 내용은 AWS Key Management Service 개발자 안내서**의 [AWS KMS의 키 정책](https://docs.aws.amazon.com/kms/latest/developerguide/key-policies.html)을 참조하세요.
일정에 따라 보고서를 처음 생성할 때 Systems Manager는 내보내기 프로세스에 사용할 서비스 역할 `AWS-SystemsManager-PatchSummaryExportRole`(아직 생성되지 않은 경우)과 함께 `AWS-EventBridge-Start-SSMAutomationRole`이라는 다른 서비스 역할을 생성합니다. `AWS-EventBridge-Start-SSMAutomationRole`은 Amazon EventBridge가 실행서 [AWS-ExportPatchReportToS3](https://docs.aws.amazon.com/systems-manager-automation-runbooks/latest/userguide/automation-aws-exportpatchreporttos3)을 사용하여 자동화를 시작할 수 있도록 합니다.
이러한 정책 및 역할을 수정하지 않는 것이 좋습니다. 이렇게 하면 패치 규정 준수 보고서 생성이 실패할 수 있습니다. 자세한 내용은 [패치 규정 준수 보고서 생성 문제 해결](#patch-compliance-reports-troubleshooting) 섹션을 참조하세요.
**Topics**
+ [생성된 패치 규정 준수 보고서에는 무엇이 포함되어 있나요?](#patch-compliance-reports-to-s3-examples)
+ [단일 관리형 노드에 대한 패치 규정 준수 보고서 생성](#patch-compliance-reports-to-s3-one-instance)
+ [단일 관리형 노드에 대한 패치 규정 준수 보고서 생성](#patch-compliance-reports-to-s3-all-instances)
+ [패치 규정 준수 보고 기록 보기](#patch-compliance-reporting-history)
+ [패치 규정 준수 보고 일정 보기](#patch-compliance-reporting-schedules)
+ [패치 규정 준수 보고서 생성 문제 해결](#patch-compliance-reports-troubleshooting)
## 생성된 패치 규정 준수 보고서에는 무엇이 포함되어 있나요?
이 주제에서는 지정된 S3 버킷에 생성되어 다운로드되는 패치 규정 준수 보고서에 포함된 콘텐츠 유형에 대한 정보를 제공합니다.
### 단일 관리형 노드에 대한 보고서 형식
단일 관리형 노드에 대해 생성된 보고서는 요약 정보와 세부 정보를 모두 제공합니다.
[샘플 보고서 다운로드(단일 노드)](https://docs.aws.amazon.com/systems-manager/latest/userguide/samples/Sample-single-instance-patch-compliance-report.zip)
단일 관리형 노드에 대한 요약 정보에는 다음이 포함됩니다.
+ 인덱스
+ 인스턴스 ID
+ 인스턴스 이름
+ 인스턴스 IP
+ 플랫폼 이름
+ 플랫폼 버전
+ SSM Agent 버전
+ 패치 기준
+ 패치 그룹
+ 규정 준수 상태
+ 규정 준수 심각도
+ 규정 미준수 중요 심각도 패치 수
+ 규정 미준수 높음 심각도 패치 수
+ 규정 미준수 중간 심각도 패치 수
+ 규정 미준수 낮음 심각도 패치 수
+ 규정 미준수 정보 심각도 패치 수
+ 규정 미준수 지정되지 않음 심각도 패치 수
단일 관리형 노드에 대한 세부 정보에는 다음이 포함됩니다.
+ 인덱스
+ 인스턴스 ID
+ 인스턴스 이름
+ 패치 이름
+ KB ID/패치 ID
+ 패치 상태
+ 최근 보고 시간
+ Compliance 수준
+ 패치 심각도
+ 패치 분류
+ CVE ID
+ 패치 기준
+ 로그 URL
+ 인스턴스 IP
+ 플랫폼 이름
+ 플랫폼 버전
+ SSM Agent 버전
**참고**
사용자 지정 패치 기준선을 생성할 때 해당 패치 기준선에서 승인된 패치의 규정 준수 심각도 수준을 지정할 수 있습니다(예: `Critical` 또는 `High`). 승인된 패치의 패치 상태가 `Missing`으로 보고되는 경우 패치 기준선의 전반적인 보고된 규정 준수 심각도는 사용자가 지정한 심각도 수준입니다.
### 모든 관리형 노드에 대한 보고서 형식
모든 관리형 노드에 대해 생성된 보고서는 요약 정보만 제공합니다.
[샘플 보고서 다운로드(모든 관리형 노드)](https://docs.aws.amazon.com/systems-manager/latest/userguide/samples/Sample-all-instances-patch-compliance-report.zip)
모든 관리형 노드에 대한 요약 정보에는 다음이 포함됩니다.
+ 인덱스
+ 인스턴스 ID
+ 인스턴스 이름
+ 인스턴스 IP
+ 플랫폼 이름
+ 플랫폼 버전
+ SSM Agent 버전
+ 패치 기준
+ 패치 그룹
+ 규정 준수 상태
+ 규정 준수 심각도
+ 규정 미준수 중요 심각도 패치 수
+ 규정 미준수 높음 심각도 패치 수
+ 규정 미준수 중간 심각도 패치 수
+ 규정 미준수 낮음 심각도 패치 수
+ 규정 미준수 정보 심각도 패치 수
+ 규정 미준수 지정되지 않음 심각도 패치 수
## 단일 관리형 노드에 대한 패치 규정 준수 보고서 생성
다음 절차에 따라 AWS 계정의 단일 관리형 노드에 대한 패치 요약 보고서를 생성합니다. 단일 관리형 노드에 대한 보고서는 패치 이름 및 ID를 포함하여 규정을 위반하는 각 패치에 대한 세부 정보를 제공합니다.
**단일 관리형 노드에 대한 패치 규정 준수 보고서 생성**
1. [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)에서 AWS Systems Manager 콘솔을 엽니다.
1. 탐색 창에서 **Patch Manager**를 선택합니다.
1. **규정 준수 보고(Compliance reporting)** 탭을 선택합니다.
1. 보고서를 생성할 관리형 노드의 행에 대한 버튼을 선택한 다음 **세부 정보 보기(View detail)**를 선택합니다.
1. **패치 요약(Patch summary)** 섹션에서 **S3로 내보내기(Export to S3)**를 선택합니다.
1. [**보고서 이름(Report name)**]에 나중에 보고서를 식별하는 데 도움이 되는 이름을 입력합니다.
1. [**보고 빈도(Reporting frequency)**]에서 다음 중 하나를 선택합니다.
+ [**온디맨드(On demand)**] - 일회성 보고서를 생성합니다. 9단계로 건너뜁니다.
+ [**일정에 따라(On a schedule)**] - 보고서를 자동으로 생성하기 위한 반복 일정을 지정합니다. 계속해서 8단계를 진행합니다.
1. [**일정 유형(Schedule type)**]에서 3일마다와 같은 비율 표현식을 지정하거나 cron 표현식을 제공하여 보고서 빈도를 설정합니다.
Cron 표현식에 대한 자세한 내용은 [참조: Systems Manager용 Cron 및 Rate 표현식](reference-cron-and-rate-expressions.md) 섹션을 참조하세요.
1. [**버킷 이름(Bucket name)**]에서 .csv 보고서 파일을 저장할 S3 버킷의 이름을 선택합니다.
**중요**
2019년 3월 20일 이후에 시작된 AWS 리전에서 작업하는 경우 동일한 리전의 S3 버킷을 선택해야 합니다. 이 날짜 이후에 시작된 리전은 기본적으로 해제되어 있습니다. 자세한 내용과 이러한 리전의 목록은 **Amazon Web Services 일반 참조의 [리전 활성화](https://docs.aws.amazon.com/general/latest/gr/rande-manage.html#rande-manage-enable)를 참조하세요.
1. (옵션) 보고서가 생성될 때 알림을 보내려면 다음 위치에서 **SNS 주제(SNS topic)** 섹션을 확장하고, **Amazon Resource Name(ARN)**에서 기존 Amazon SNS 주제를 선택합니다.
1. **제출**을 선택합니다.
생성된 보고서의 기록 보기에 대한 자세한 내용은 [패치 규정 준수 보고 기록 보기](#patch-compliance-reporting-history) 섹션을 참조하세요.
생성한 보고 일정의 세부 정보 보기에 대한 자세한 내용은 [패치 규정 준수 보고 일정 보기](#patch-compliance-reporting-schedules) 섹션을 참조하세요.
## 단일 관리형 노드에 대한 패치 규정 준수 보고서 생성
다음 절차에 따라 AWS 계정의 모든 관리형 노드에 대한 패치 요약 보고서를 생성합니다. 모든 관리형 노드에 대한 보고서에는 규정을 위반하는 노드와 규정 미준수 패치 수가 나와 있습니다. 패치의 이름이나 다른 식별자는 제공하지 않습니다. 이러한 추가 세부 정보를 보려면 단일 관리형 노드에 대한 패치 규정 준수 보고서를 생성합니다. 자세한 내용은 이번 주제 전반부의 [단일 관리형 노드에 대한 패치 규정 준수 보고서 생성](#patch-compliance-reports-to-s3-one-instance) 섹션을 참조하세요.
**모든 관리형 노드에 대한 패치 규정 준수 보고서 생성**
1. [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)에서 AWS Systems Manager 콘솔을 엽니다.
1. 탐색 창에서 **Patch Manager**를 선택합니다.
1. **규정 준수 보고(Compliance reporting)** 탭을 선택합니다.
1. [**S3로 내보내기(Export to S3)**]를 선택합니다. (노드 ID를 먼저 선택하지 마세요.)
1. [**보고서 이름(Report name)**]에 나중에 보고서를 식별하는 데 도움이 되는 이름을 입력합니다.
1. [**보고 빈도(Reporting frequency)**]에서 다음 중 하나를 선택합니다.
+ [**온디맨드(On demand)**] - 일회성 보고서를 생성합니다. 8단계로 건너뜁니다.
+ [**일정에 따라(On a schedule)**] - 보고서를 자동으로 생성하기 위한 반복 일정을 지정합니다. 계속해서 7단계를 진행합니다.
1. [**일정 유형(Schedule type)**]에서 3일마다와 같은 비율 표현식을 지정하거나 cron 표현식을 제공하여 보고서 빈도를 설정합니다.
Cron 표현식에 대한 자세한 내용은 [참조: Systems Manager용 Cron 및 Rate 표현식](reference-cron-and-rate-expressions.md) 섹션을 참조하세요.
1. [**버킷 이름(Bucket name)**]에서 .csv 보고서 파일을 저장할 S3 버킷의 이름을 선택합니다.
**중요**
2019년 3월 20일 이후에 시작된 AWS 리전에서 작업하는 경우 동일한 리전의 S3 버킷을 선택해야 합니다. 이 날짜 이후에 시작된 리전은 기본적으로 해제되어 있습니다. 자세한 내용과 이러한 리전의 목록은 **Amazon Web Services 일반 참조의 [리전 활성화](https://docs.aws.amazon.com/general/latest/gr/rande-manage.html#rande-manage-enable)를 참조하세요.
1. (옵션) 보고서가 생성될 때 알림을 보내려면 다음 위치에서 **SNS 주제(SNS topic)** 섹션을 확장하고, **Amazon Resource Name(ARN)**에서 기존 Amazon SNS 주제를 선택합니다.
1. **제출**을 선택합니다.
생성된 보고서의 기록 보기에 대한 자세한 내용은 [패치 규정 준수 보고 기록 보기](#patch-compliance-reporting-history) 섹션을 참조하세요.
생성한 보고 일정의 세부 정보 보기에 대한 자세한 내용은 [패치 규정 준수 보고 일정 보기](#patch-compliance-reporting-schedules) 섹션을 참조하세요.
## 패치 규정 준수 보고 기록 보기
이 주제의 정보를 사용하여 AWS 계정에서 생성된 패치 규정 준수 보고서에 대한 세부 정보를 볼 수 있습니다.
**패치 규정 준수 보고 기록을 보려면**
1. [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)에서 AWS Systems Manager 콘솔을 엽니다.
1. 탐색 창에서 **Patch Manager**를 선택합니다.
1. **규정 준수 보고(Compliance reporting)** 탭을 선택합니다.
1. [**모든 S3 내보내기 보기(View all S3 exports)**]를 선택하고 [**내보내기 기록(Export history)**] 탭을 선택합니다.
## 패치 규정 준수 보고 일정 보기
이 주제의 정보를 사용하여 AWS 계정에서 생성된 패치 규정 준수 보고 일정에 대한 세부 정보를 볼 수 있습니다.
**패치 규정 준수 보고 기록을 보려면**
1. [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)에서 AWS Systems Manager 콘솔을 엽니다.
1. 탐색 창에서 **Patch Manager**를 선택합니다.
1. **규정 준수 보고(Compliance reporting)** 탭을 선택합니다.
1. **모든 S3 내보내기 보기(View all S3 exports)**를 선택하고 **보고서 예약 역할(Report schedule rules)** 탭을 선택합니다.
## 패치 규정 준수 보고서 생성 문제 해결
다음 정보를 사용하여 AWS Systems Manager의 도구인 Patch Manager에서 패치 규정 준수 보고서 생성 문제를 해결할 수 있습니다.
**Topics**
+ [`AWS-SystemsManager-PatchManagerExportRolePolicy` 정책이 손상되었다는 메시지가 나타납니다.](#patch-compliance-reports-troubleshooting-1)
+ [패치 규정 준수 정책 또는 역할을 삭제한 후 예약된 보고서가 성공적으로 생성되지 않습니다.](#patch-compliance-reports-troubleshooting-2)
### `AWS-SystemsManager-PatchManagerExportRolePolicy` 정책이 손상되었다는 메시지가 나타납니다.
**문제**: `AWS-SystemsManager-PatchManagerExportRolePolicy`가 손상되었음을 나타내는 다음과 비슷한 오류 메시지가 나타납니다.
```
An error occurred while updating the AWS-SystemsManager-PatchManagerExportRolePolicy
policy. If you have edited the policy, you might need to delete the policy, and any
role that uses it, then try again. Systems Manager recreates the roles and policies
you have deleted.
```
+ **솔루션**: 새 패치 규정 준수 보고서를 생성하기 전에 Patch Manager 콘솔 또는 AWS CLI를 사용하여 영향을 받는 역할과 정책을 삭제합니다.
**콘솔을 사용하여 손상된 정책을 삭제하는 방법**
1. IAM 콘솔([https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/))을 엽니다.
1. 다음 중 하나를 수행하세요.
**온디맨드 보고서** - 일회성 온디맨드 보고서를 생성하는 동안 문제가 발생한 경우 왼쪽 탐색에서 [**정책(Policies)**]을 선택하고 `AWS-SystemsManager-PatchManagerExportRolePolicy`를 검색한 다음 정책을 삭제합니다. 그런 다음 [**역할(Roles)**]을 선택하고 `AWS-SystemsManager-PatchSummaryExportRole`을 검색한 다음 역할을 삭제합니다.
**예약된 보고서** - 일정에 따라 보고서를 생성하는 동안 문제가 발생한 경우 왼쪽 탐색에서 **정책**을 선택하고, 한 번에 하나씩 `AWS-EventBridge-Start-SSMAutomationRolePolicy` 및 `AWS-SystemsManager-PatchManagerExportRolePolicy`를 검색하고, 각 정책을 삭제합니다. 그런 다음 [**역할(Roles)**]을 선택하고 한 번에 하나씩 `AWS-EventBridge-Start-SSMAutomationRole` 및 `AWS-SystemsManager-PatchSummaryExportRole`을 검색한 다음 각 역할을 삭제합니다.
**AWS CLI를 사용하여 손상된 정책을 삭제하는 방법**
*자리 표시자 값*을 계정 ID로 바꿉니다.
+ 일회성 온디맨드 보고서를 생성하는 동안 문제가 발생한 경우 다음과 같은 명령을 실행합니다.
```
aws iam delete-policy --policy-arn arn:aws:iam::account-id:policy/AWS-SystemsManager-PatchManagerExportRolePolicy
```
```
aws iam delete-role --role-name AWS-SystemsManager-PatchSummaryExportRole
```
일정에 따라 보고서를 생성하는 동안 문제가 발생한 경우 다음과 같은 명령을 실행합니다.
```
aws iam delete-policy --policy-arn arn:aws:iam::account-id:policy/AWS-EventBridge-Start-SSMAutomationRolePolicy
```
```
aws iam delete-policy --policy-arn arn:aws:iam::account-id:policy/AWS-SystemsManager-PatchManagerExportRolePolicy
```
```
aws iam delete-role --role-name AWS-EventBridge-Start-SSMAutomationRole
```
```
aws iam delete-role --role-name AWS-SystemsManager-PatchSummaryExportRole
```
두 절차 중 하나를 완료한 후 단계에 따라 새 패치 규정 준수 보고서를 생성하거나 예약합니다.
### 패치 규정 준수 정책 또는 역할을 삭제한 후 예약된 보고서가 성공적으로 생성되지 않습니다.
**문제**: 보고서를 처음 생성할 때 Systems Manager는 내보내기 프로세스에 사용할 서비스 역할과 정책을 생성합니다(`AWS-SystemsManager-PatchSummaryExportRole` 및 `AWS-SystemsManager-PatchManagerExportRolePolicy`). 일정에 따라 보고서를 처음 생성할 때 Systems Manager는 다른 서비스 역할과 정책을 생성합니다(`AWS-EventBridge-Start-SSMAutomationRole` 및 `AWS-EventBridge-Start-SSMAutomationRolePolicy`). 이를 통해 Amazon EventBridge는 실행서 [AWS-ExportPatchReportToS3](https://docs.aws.amazon.com/systems-manager-automation-runbooks/latest/userguide/automation-aws-exportpatchreporttos3)을 사용하여 자동화를 시작할 수 있습니다.
이러한 정책 또는 역할을 삭제하면 일정과 지정된 S3 버킷 및 Amazon SNS 주제 간의 연결이 끊어질 수 있습니다.
+ **해결 방법**: 이 문제를 해결하려면 이전 일정을 삭제하고 문제가 발생한 일정을 대체할 새 일정을 만드는 것이 좋습니다.
# Patch Manager로 규정 미준수 관리형 노드 문제 해결
이 섹션의 주제에서는 패치 규정을 위반하는 관리형 노드를 식별하는 방법과 노드가 규정을 준수하도록 하는 방법을 간략히 소개합니다.
**Topics**
+ [규정 미준수 관리형 노드 식별](patch-manager-find-noncompliant-nodes.md)
+ [패치 규정 준수 상태 값](patch-manager-compliance-states.md)
+ [규정 미준수 관리형 노드 패치 적용](patch-manager-compliance-remediation.md)
# 규정 미준수 관리형 노드 식별
2개의 AWS Systems Manager 문서(SSM 문서) 중 하나를 실행하면 규정 위반 관리형 노드가 식별됩니다. 이들 SSM 문서는 AWS Systems Manager의 도구인 Patch Manager의 각 관리형 노드에 대한 적절한 패치 기준을 참조합니다. 그런 다음 관리형 노드의 패치 상태를 평가하고 규정 준수 결과를 제공합니다.
규정 미준수 관리형 노드를 식별하거나 업데이트하는 데 사용하는 두 가지 SSM 문서가 있습니다(`AWS-RunPatchBaseline` 및 `AWS-RunPatchBaselineAssociation`). 각 문서는 서로 다른 프로세스에서 사용되며 규정 준수 결과는 여러 채널을 통해 제공됩니다. 다음 표에는 이러한 문서 간의 차이점이 요약되어 있습니다.
**참고**
Patch Manager에서 패치 규정 준수 데이터를 AWS Security Hub CSPM로 보낼 수 있습니다. Security Hub CSPM에서는 우선순위가 높은 보안 알림 및 규정 준수 상태를 포괄적으로 파악할 수 있습니다. 또한 플릿의 패치 상태를 모니터링합니다. 자세한 내용은 [Patch Manager와 AWS Security Hub CSPM 통합](patch-manager-security-hub-integration.md) 섹션을 참조하세요.
| | `AWS-RunPatchBaseline` | `AWS-RunPatchBaselineAssociation` |
| --- | --- | --- |
| 문서를 사용하는 프로세스 | **온디맨드로 패치** - **지금 패치(Patch now)** 옵션을 사용하여 온디맨드로 관리형 노드를 스캔하거나 패치할 수 있습니다. 자세한 내용은 [관리형 노드 온디맨드 패치](patch-manager-patch-now-on-demand.md) 섹션을 참조하세요. **Systems Manager Quick Setup 패치 정책** - AWS Systems Manager의 도구인 Quick Setup에서 전체 조직, 일부 조직 단위 또는 단일 AWS 계정에 대해 별도의 일정에 따라 누락된 패치를 검색하거나 설치할 수 있는 패치 구성 기능을 생성할 수 있습니다. 자세한 내용은 [Quick Setup 패치 정책을 사용한 조직 내 인스턴스에 대한 패치 적용 구성](quick-setup-patch-manager.md) 섹션을 참조하세요. **명령 실행** - AWS Systems Manager의 도구인 Run Command의 작업에서 `AWS-RunPatchBaseline`을 수동으로 실행할 수 있습니다. 자세한 내용은 [콘솔에서 명령 실행](running-commands-console.md) 섹션을 참조하세요. **유지 관리 기간** - Run Command 태스크 유형에서 SSM 문서 `AWS-RunPatchBaseline`을 사용하는 유지 관리 기간을 생성할 수 있습니다. 자세한 내용은 [자습서: 콘솔을 사용하여 패치를 위한 유지 관리 기간 생성](maintenance-window-tutorial-patching.md) 섹션을 참조하세요. | **Systems Manager Quick Setup 호스트 관리** - Quick Setup에서 Systems Manager 호스트 관리 구성 옵션을 활성화하여 관리형 인스턴스의 패치 규정 준수 여부를 검사할 수 있습니다. 자세한 내용은 [Quick Setup을 사용한 Amazon EC2 호스트 관리 설정](quick-setup-host-management.md) 섹션을 참조하세요. **Systems Manager [Explorer](Explorer.md)** - AWS Systems Manager의 도구인 Explorer를 허용하면 정기적으로 관리형 인스턴스의 패치 규정 준수 여부를 검사하여 Explorer 대시보드에 결과를 보고합니다. |
| 패치 검사 결과 데이터의 형식 | `AWS-RunPatchBaseline` 실행 후 Patch Manager가 AWS Systems Manager의 도구인 Inventory에 `AWS:PatchSummary` 객체를 전송합니다. 이 보고서는 패치 작업이 성공하는 경우에만 생성되며 규정 준수 상태가 계산된 시기를 식별하는 캡처 시간을 포함합니다. | `AWS-RunPatchBaselineAssociation` 실행 후 Patch Manager가 Systems Manager Inventory에 `AWS:ComplianceItem` 객체를 전송합니다. |
| 콘솔에서 패치 규정 준수 보고서 보기 | [Systems Manager Configuration Compliance](systems-manager-compliance.md) 및 [관리형 노드 작업](fleet-manager-managed-nodes.md)에서 `AWS-RunPatchBaseline`을 사용하는 프로세스에 대한 패치 규정 준수 정보를 볼 수 있습니다. 자세한 내용은 [패치 규정 준수 결과 보기](patch-manager-view-compliance-results.md) 섹션을 참조하세요. | Quick Setup을 사용하여 관리형 인스턴스의 패치 준수 여부를 스캔하는 경우에는 [Systems Manager Fleet Manager](fleet-manager.md)에서 규정 준수 보고서를 볼 수 있습니다. Fleet Manager 콘솔에서 관리형 노드의 노드 ID를 선택합니다. **일반** 메뉴에서 **구성 준수**를 선택합니다. Explorer를 사용하여 관리형 인스턴스의 패치 규정 준수 여부를 검사하는 경우 Explorer와 [Systems Manager OpsCenter](OpsCenter.md) 모두에서 규정 준수 보고서를 볼 수 있습니다. |
| 패치 규정 준수 결과를 보기 위한 AWS CLI 명령 | `AWS-RunPatchBaseline`을 사용하는 프로세스의 경우 다음 AWS CLI 명령을 사용하여 관리형 노드의 패치에 대한 요약 정보를 볼 수 있습니다. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/systems-manager/latest/userguide/patch-manager-find-noncompliant-nodes.html) | `AWS-RunPatchBaselineAssociation`을 사용하는 프로세스의 경우 다음 AWS CLI 명령을 사용하여 인스턴스의 패치에 대한 요약 정보를 볼 수 있습니다. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/systems-manager/latest/userguide/patch-manager-find-noncompliant-nodes.html) |
| 패치 작업 | `AWS-RunPatchBaseline`을 사용하는 프로세스의 경우 작업에서 `Scan` 작업만 실행할지 아니면 `Scan and install` 작업을 실행할지 지정합니다. (규정 미준수 관리형 노드를 식별하고 문제를 해결하지는 않는 것이 목표라면 `Scan` 작업만 실행합니다.) | AWS-RunPatchBaselineAssociation을 사용하는 Quick Setup 및 Explorer 프로세스는 Scan 작업만 실행합니다. |
| 추가 정보 | [패치를 위한 SSM 명령 문서: `AWS-RunPatchBaseline`](patch-manager-aws-runpatchbaseline.md) | [패치를 위한 SSM 명령 문서: `AWS-RunPatchBaselineAssociation`](patch-manager-aws-runpatchbaselineassociation.md) |
보고되는 다양한 패치 규정 준수 상태에 대한 자세한 내용은 [패치 규정 준수 상태 값](patch-manager-compliance-states.md) 섹션을 참조하세요.
패치 규정을 위반하는 관리형 노드 수정에 대한 자세한 내용은 [규정 미준수 관리형 노드 패치 적용](patch-manager-compliance-remediation.md) 섹션을 참조하세요.
# 패치 규정 준수 상태 값
관리형 노드의 패치에 대한 정보에는 각 개별 패치의 상태에 대한 보고서가 포함됩니다.
**작은 정보**
관리형 노드에 특정 패치 규정 준수 상태를 할당하려면 [https://docs.aws.amazon.com/cli/latest/reference/ssm/put-compliance-items.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/put-compliance-items.html) AWS Command Line Interface(AWS CLI) 명령 또는 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PutComplianceItems.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PutComplianceItems.html) API 작업을 사용합니다. 콘솔에서는 규정 준수 상태를 할당할 수 없습니다.
다음 표의 정보를 사용하여 관리형 노드가 패치 규정을 위반하는 이유를 식별할 수 있습니다.
## Debian Server 및 Ubuntu Server의 패치 규정 준수 값
Debian Server 및 Ubuntu Server의 경우 다양한 규정 준수 상태로 패키지를 분류하는 규칙은 다음 표에 설명되어 있습니다.
**참고**
`INSTALLED`, `INSTALLED_OTHER`, `MISSING` 상태 값을 평가할 때 다음 사항에 유의하세요. 패치 기준을 생성하거나 업데이트할 때 **비보안 업데이트 포함** 확인란을 선택하지 않으면 패치 후보 버전이 다음 리포지토리의 패치로 제한됩니다.
Ubuntu Server 16.04 LTS: `xenial-security`
Ubuntu Server 18.04 LTS: `bionic-security`
Ubuntu Server 20.04 LTS: `focal-security`
Ubuntu Server 22.04 LTS(`jammy-security`)
Ubuntu Server 24.04 LTS(`noble-security`)
Ubuntu Server 25.04(`plucky-security`)
`debian-security` (Debian Server)
[**비보안 업데이트 포함(Include nonsecurity updates)**] 확인란을 선택하면 다른 리포지토리의 패치도 고려됩니다.
| 패치 상태 | 설명 | 규정 준수 상태 |
| --- | --- | --- |
| **`INSTALLED`** | 패치가 패치 기준에 나열되고 관리형 노드에 설치됩니다. 개인이 수동으로 설치하거나 `AWS-RunPatchBaseline` 문서가 관리형 노드에서 실행되었을 때 개인이나 Patch Manager가 자동으로 설치했을 수 있습니다. | 규정 준수 |
| **`INSTALLED_OTHER`** | 패치가 기준에 포함되지 않았거나 기준에서 승인되지 않았지만 관리형 노드에 설치되었습니다. 패치가 수동으로 설치되었거나 패키지가 승인된 다른 패치의 필수 종속성이거나 패치가 InstallOverrideList 작업에 포함되었을 수 있습니다. [**거부된 패치(Rejected patches)**] 작업으로 `Block`을 지정하지 않으면 `INSTALLED_OTHER` 패치에는 설치되었지만 거부된 패치도 포함됩니다. | 규정 준수 |
| **`INSTALLED_PENDING_REBOOT`** | `INSTALLED_PENDING_REBOOT`는 다음 중 하나를 의미할 수 있습니다. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/systems-manager/latest/userguide/patch-manager-compliance-states.html) 어느 쪽도 모두 패치가 이 상태일 때 재부팅이 *필요*하다는 의미가 아니며, 패치가 설치된 이후 노드가 재부팅되지 않았다는 것만을 의미합니다. | 규정 미준수 |
| **`INSTALLED_REJECTED`** | 패치가 관리형 노드에 설치되었지만 **거부된 패치(Rejected patches)** 목록에 지정되었습니다. 이는 일반적으로 패치가 거부된 패치 목록에 추가되기 이전에 설치된 경우에 해당합니다. | 규정 미준수 |
| **`MISSING`** | 패치가 기준에 승인되었지만 관리형 노드에 설치되지 않았습니다. `AWS-RunPatchBaseline` 문서 태스크를 (설치 대신) 검사하도록 구성하는 경우 시스템은 검사 도중에 있었지만 설치되지는 않은 패치에 대해 이 상태를 보고합니다. | 규정 미준수 |
| **`FAILED`** | 패치가 기준에 승인되었지만 인스턴스에 설치될 수 없었습니다. 이 상황을 해결하려면 문제를 이해하는 데 도움이 될 수 있는 정보에 대한 명령 출력을 검토합니다. | 규정 미준수 |
## 다른 운영 체제의 패치 규정 준수 값
Debian Server 및 Ubuntu Server 외에 모든 운영 체제의 경우 다양한 규정 준수 상태로 패키지를 분류하는 규칙은 다음 표에 설명되어 있습니다.
| 패치 상태 | 설명 | Compliance 값 |
| --- | --- | --- |
| **`INSTALLED`** | 패치가 패치 기준에 나열되고 관리형 노드에 설치됩니다. 개인이 수동으로 설치하거나 `AWS-RunPatchBaseline` 문서가 노드에서 실행되었을 때 개인이나 Patch Manager가 자동으로 설치했을 수 있습니다. | 규정 준수 |
| 6 | 패치가 기준에 없지만 관리형 노드에 설치되었습니다. 이에 대한 원인은 다음 두 가지가 있을 수 있습니다. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/systems-manager/latest/userguide/patch-manager-compliance-states.html) | 규정 준수 |
| **`INSTALLED_REJECTED`** | 패치가 관리형 노드에 설치되었지만 거부된 패치(Rejected patches) 목록에 지정되었습니다. 이는 일반적으로 패치가 거부된 패치 목록에 추가되기 이전에 설치된 경우에 해당합니다. | 규정 미준수 |
| **`INSTALLED_PENDING_REBOOT`** | `INSTALLED_PENDING_REBOOT`는 다음 중 하나를 의미할 수 있습니다. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/systems-manager/latest/userguide/patch-manager-compliance-states.html) 어느 쪽도 모두 패치가 이 상태일 때 재부팅이 *필요*하다는 의미가 아니며, 패치가 설치된 이후 노드가 재부팅되지 않았다는 것만을 의미합니다. | 규정 미준수 |
| **`MISSING`** | 패치가 기준에 승인되었지만 관리형 노드에 설치되지 않았습니다. `AWS-RunPatchBaseline` 문서 태스크를 (설치 대신) 검사하도록 구성하는 경우 시스템은 검사 도중에 있었지만 설치되지는 않은 패치에 대해 이 상태를 보고합니다. | 규정 미준수 |
| **`FAILED`** | 패치가 기준에 승인되었지만 인스턴스에 설치될 수 없었습니다. 이 상황을 해결하려면 문제를 이해하는 데 도움이 될 수 있는 정보에 대한 명령 출력을 검토합니다. | 규정 미준수 |
| 6 | *이 규정 준수 상태는 Windows Server 운영 체제에 대해서만 보고됩니다.* 패치가 기준에 승인되었지만 패치를 사용하는 서비스 또는 기능이 관리형 노드에 설치되지 않았습니다. 예를 들어 인터넷 정보 서비스(IIS)와 같은 웹 서버 서비스에 대한 패치는 해당 패치가 기준에 승인되었지만 웹 서비스가 관리형 노드에 설치되지 않은 경우 `NOT_APPLICABLE`로 표시됩니다. 패치가 후속 업데이트로 대체된 경우에도 패치를 `NOT_APPLICABLE`로 표시할 수 있습니다. 즉, 이후 업데이트가 설치되고 `NOT_APPLICABLE` 업데이트가 더 이상 필요하지 않습니다. | 해당 사항 없음 |
| AVAILABLE\$1SECURITY\$1UPDATES | *이 규정 준수 상태는 Windows Server 운영 체제에 대해서만 보고됩니다.* 패치 기준에서 승인되지 않은 사용 가능한 보안 업데이트 패치는 사용자 지정 패치 기준에 정의된 규정 준수 값 `Compliant` 또는 `Non-Compliant`를 가질 수 있습니다. 패치 기준을 생성하거나 업데이트할 때 사용 가능하지만 패치 기준에 지정된 설치 기준을 충족하지 않아 승인되지 않은 보안 패치에 할당할 상태를 선택합니다. 예를 들어 설치 전에 패치가 릴리스된 후 장기간 대기하도록 지정한 경우 설치하려는 보안 패치를 건너뛸 수 있습니다. 지정된 대기 기간 동안 패치 업데이트가 릴리스되면 패치 설치 대기 기간이 다시 시작됩니다. 대기 기간이 너무 길면 여러 버전의 패치가 릴리스될 수 있지만 설치되지는 않습니다. 패치 요약 수에서 패치가 `AvailableSecurityUpdate`로 보고되면 패치는 항상 `AvailableSecurityUpdateCount`에 포함됩니다. 이러한 패치를 `NonCompliant`로 보고하도록 기준이 구성된 경우 `SecurityNonCompliantCount`에도 포함됩니다. 이러한 패치를 `Compliant`로 보고하도록 기준이 구성된 경우 `SecurityNonCompliantCount`에 포함되지 않습니다. 이러한 패치는 항상 심각도가 지정되지 않은 상태로 보고되며 `CriticalNonCompliantCount`에 포함되지 않습니다. | 사용 가능한 보안 업데이트에 대해 선택한 옵션에 따라 Compliant 또는 Non-Compliant. 콘솔을 사용하여 패치 기준을 생성하거나 업데이트하려면 **사용 가능한 보안 업데이트 규정 준수 상태** 필드에서 이 옵션을 지정합니다. AWS CLI를 사용하여 [https://docs.aws.amazon.com/cli/latest/reference/ssm/create-patch-baseline.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/create-patch-baseline.html) 또는 [https://docs.aws.amazon.com/cli/latest/reference/ssm/update-patch-baseline.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/update-patch-baseline.html) 명령을 실행하는 경우 `available-security-updates-compliance-status` 파라미터에서 이 옵션을 지정합니다. |
¹ 상태가 `INSTALLED_OTHER` 및 `NOT_APPLICABLE`인 패치의 경우 Patch Manager는 [https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-instance-patches.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-instance-patches.html) 명령에 기반을 둔 쿼리 결과에서 `Classification` 및 `Severity`의 값과 같은 일부 데이터를 생략합니다. 이 작업은 AWS Systems Manager의 도구인 Inventory의 개별 노드에 대한 데이터 제한을 초과하는 것을 방지하기 위해 실시됩니다. 모든 패치 세부 정보를 보려면 [https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-available-patches.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-available-patches.html) 명령을 사용합니다.
# 규정 미준수 관리형 노드 패치 적용
관리형 노드의 패치 규정 준수 여부를 확인하는 데 사용할 수 있는 것과 동일한 AWS Systems Manager 도구와 프로세스를 사용하여 노드가 현재 적용되는 패치 규정을 준수하도록 할 수 있습니다. 관리형 노드가 패치 규정을 준수하도록 하려면 AWS Systems Manager의 도구인 Patch Manager가 `Scan and install` 작업을 실행해야 합니다. (규정 미준수 관리형 노드를 식별만 하고 해결은 하지 않는 것이 목표라면 그 대신에 `Scan` 작업을 실행합니다. 자세한 내용은 [규정 미준수 관리형 노드 식별](patch-manager-find-noncompliant-nodes.md) 섹션을 참조하세요.)
**Systems Manager 사용하여 패치 설치**
여러 도구 중에서 선택하여 `Scan and install` 작업을 실행할 수 있습니다.
+ (권장) Systems Manager의 도구인 Quick Setup에서 패치 정책을 구성하여 전체 조직, 일부 조직 단위 또는 단일 AWS 계정의 일정에 따라 누락된 패치를 설치할 수 있습니다. 자세한 내용은 [Quick Setup 패치 정책을 사용한 조직 내 인스턴스에 대한 패치 적용 구성](quick-setup-patch-manager.md) 섹션을 참조하세요.
+ Run Command 태스크 유형에서 Systems Manager 문서(SSM 문서) `AWS-RunPatchBaseline`을 사용하는 유지 관리 기간을 생성합니다. 자세한 내용은 [자습서: 콘솔을 사용하여 패치를 위한 유지 관리 기간 생성](maintenance-window-tutorial-patching.md) 섹션을 참조하세요.
+ Run Command 작업에서 `AWS-RunPatchBaseline`을 수동으로 실행합니다. 자세한 내용은 [콘솔에서 명령 실행](running-commands-console.md) 섹션을 참조하세요.
+ [**지금 패치(Patch now)**] 옵션을 사용하여 온디맨드로 패치를 설치합니다. 자세한 내용은 [관리형 노드 온디맨드 패치](patch-manager-patch-now-on-demand.md) 섹션을 참조하세요.
# 패치 규정 준수 데이터를 생성한 실행 식별
패치 규정 준수 데이터는 가장 최근에 성공한 패치 작업의 특정 시점 스냅샷을 나타냅니다. 각 규정 준수 보고서에는 어떤 작업이 규정 준수 데이터를 언제 생성했는지 식별하는 데 도움이 되는 실행 ID와 캡처 시간이 모두 포함되어 있습니다.
인스턴스에서 패치 규정 준수를 검사하기 위해 여러 유형의 작업을 수행하는 경우, 스캔할 때마다 이전 스캔의 패치 규정 준수 데이터를 덮어씁니다. 따라서 패치 규정 준수 데이터에 예상치 못한 결과가 발생할 수 있습니다.
예를 들어 현지 시간으로 매일 오전 2시에 패치 규정 준수를 스캔하는 패치 정책을 생성한다고 가정해 보겠습니다. 이 패치 정책은 심각도가 `Critical`, `Important` 및 `Moderate`로 표시된 패치를 대상으로 하는 패치 기준선을 사용합니다. 이 패치 기준선은 몇 가지 명시적으로 거부된 패치도 지정합니다.
또한 현지 시간으로 매일 오전 4시에 동일한 관리형 노드 세트를 스캔하도록 유지 관리 기간이 이미 설정되어 있고, 사용자가 이 설정은 삭제하거나 비활성화하지 않는다고 가정해 보겠습니다. 해당 유지 관리 기간의 태스크에는 심각도 `Critical`인 패치만 대상으로 하고 특정 패치를 제외하지 않는 다른 패치 기준선을 사용합니다.
유지 관리 기간에 의해 이 두 번째 스캔이 수행되면 첫 번째 스캔의 패치 규정 준수 데이터가 삭제되고 두 번째 스캔의 패치 규정 준수로 교체됩니다.
따라서 패치 작업에서 스캔 및 설치에는 자동화된 한 가지 방법만 사용하는 것이 좋습니다. 패치 정책을 설정하는 경우 패치 규정 준수를 검사하는 다른 방법을 삭제하거나 비활성화해야 합니다. 자세한 내용은 다음 항목을 참조하세요.
+ 유지 관리 기간에서 패치 작업을 제거하려면 - [콘솔을 사용하여 유지 관리 기간 태스크 업데이트 또는 등록 취소](sysman-maintenance-update.md#sysman-maintenance-update-tasks)
+ State Manager 연결을 삭제하려면 – [연결 삭제](systems-manager-state-manager-delete-association.md).
호스트 관리 구성에서 일일 패치 규정 준수 검사를 비활성화하려면 Quick Setup에서 다음을 수행합니다.
1. 탐색 창에서 **Quick Setup**를 선택합니다.
1. 업데이트할 호스트 관리 구성을 선택합니다.
1. **Actions(작업), Edit configuration**(구성 편집)을 차례로 선택합니다.
1. **Scan instances for missing patches daily**(매일 누락된 패치에 대한 인스턴스 스캔) 확인란의 선택을 취소합니다.
1. **업데이트**를 선택합니다.
**참고**
**Patch now**(지금 패치) 옵션을 사용하여 관리형 노드의 규정 준수를 검사하면 패치 규정 준수 데이터도 덮어쓰여집니다.
# 관리형 노드 온디맨드 패치
AWS Systems Manager의 도구인 Patch Manager의 **지금 패치** 옵션을 사용하여 Systems Manager 콘솔에서 온디맨드 패치 작업을 실행할 수 있습니다. 즉, 관리형 노드의 규정 준수 상태를 업데이트하거나 비준수 노드에 패치를 설치하기 위해 일정을 생성할 필요가 없습니다. 또한 예약된 패치 기간을 설정하거나 수정하기 위해 AWS Systems Manager의 도구인 Patch Manager와 Maintenance Windows 사이에서 Systems Manager 콘솔을 전환할 필요가 없습니다.
**지금 패치(Patch now)**는 가능한 한 빨리 관리형 노드에 제로데이 업데이트를 적용하거나 다른 중요한 패치를 설치해야 할 때 특히 유용합니다.
**참고**
온디맨드 패치는 한 번에 하나의 AWS 리전-AWS 계정 쌍에 대해서만 지원됩니다. *패치 정책*을 기반으로 한 패치 작업에는 사용할 수 없습니다. 모든 관리형 노드를 규정 준수 상태로 유지하려면 패치 정책을 사용하는 것이 좋습니다. 패치 정책 작업에 대한 자세한 내용은 [Quick Setup의 패치 정책 구성](patch-manager-policies.md) 섹션을 참조하세요.
**Topics**
+ ['지금 패치(Patch now)' 작동 방식](#patch-on-demand-how-it-works)
+ ['지금 패치(Patch now)' 실행](#run-patch-now)
## '지금 패치(Patch now)' 작동 방식
**지금 패치(Patch now)**를 실행하려면 2가지 필수 설정만 지정하면 됩니다.
+ 누락된 패치만 스캔할지 아니면 관리형 노드에서 패치를 스캔 *및* 설치할지 여부
+ 작업을 실행할 관리형 노드
**지금 패치(Patch now)** 작업이 실행되면 다른 패치 작업에 대해 선택한 것과 동일한 방식으로 사용할 패치 기준선을 결정합니다. 관리형 노드가 패치 그룹과 연결된 경우 해당 그룹에 대해 지정된 패치 기준선이 사용됩니다. 관리형 노드가 패치 그룹에 연결되어 있지 않은 경우 작업은 관리형 노드의 운영 체제 유형에 대한 기본값으로 현재 설정된 패치 기준을 사용합니다. 미리 정의된 기준 또는 기본값으로 설정한 사용자 정의 기준일 수 있습니다. 패치 기준 선택에 대한 자세한 내용은 [패치 그룹](patch-manager-patch-groups.md) 섹션을 참조하세요.
**지금 패치(Patch now)**에 대해 지정할 수 있는 옵션으로는 패치 후 관리형 노드 재부팅 시기 또는 재부팅 여부 선택, 패치 작업을 위해 로그 데이터를 저장할 Amazon Simple Storage Service(Amazon S3) 버킷 지정, 패치 중 수명 주기 후크로 Systems Manager 문서(SSM 문서) 실행 등이 있습니다.
### '지금 패치'에 대한 동시성 및 오류 임계값
**패치 지금(Patch now)** 작업의 경우 동시성 및 오류 임계값 옵션은 Patch Manager에서 처리합니다. 한 번에 패치할 관리형 노드 수 또는 작업이 실패하기 전에 허용되는 오류 수를 지정할 필요가 없습니다. Patch Manager는 온디맨드로 패치할 때 다음 표에 설명된 동시성 및 오류 임계값 설정을 적용합니다.
**중요**
다음 임계값은 `Scan and install` 작업에만 적용됩니다. `Scan` 작업의 경우 Patch Manager는 최대 1,000개의 노드를 동시에 스캔하고 최대 1,000개의 오류가 발생할 때까지 계속 스캔합니다.
**동시성: 설치 작업**
| **지금 패치(Patch now)** 작업의 총 관리형 노드 수 | 한 번에 스캔 또는 패치되는 관리형 노드 수 |
| --- | --- |
| 25개 미만 | 1 |
| 25\$1100개 | 5% |
| 101\$11,000개 | 8% |
| 1,000개 이상 | 10% |
**오류 임계값: 설치 작업**
| **지금 패치(Patch now)** 작업의 총 관리형 노드 수 | 작업이 실패하기 전에 허용되는 오류 수 |
| --- | --- |
| 25개 미만 | 1 |
| 25\$1100개 | 5 |
| 101\$11,000개 | 10 |
| 1,000개 이상 | 10 |
### '지금 패치' 수명 주기 후크 사용
**지금 패치(Patch now)**에서는 패치 작업 `Install` 중에 SSM 명령 문서를 수명 주기 후크로 실행할 수 있는 기능을 제공합니다. 패치를 적용한 후 또는 재부팅 후 애플리케이션에 패치를 적용하거나 상태 확인을 실행하기 전에 애플리케이션을 종료하는 등의 작업에 이러한 후크를 사용할 수 있습니다.
수명 주기 후크 사용에 대한 자세한 내용은 [패치를 위한 SSM 명령 문서: `AWS-RunPatchBaselineWithHooks`](patch-manager-aws-runpatchbaselinewithhooks.md) 섹션을 참조하세요.
다음 표에는 각 후크에 대한 샘플 사용 외에도 세 가지 **지금 패치(Patch now)** 재부팅 옵션 각각에 사용할 수 있는 수명 주기 후크가 나열됩니다.
**수명 주기 후크 및 샘플 사용**
| 재부팅 옵션 | 후크: 설치 전 | 후크: 설치 후 | 후크: 종료 시 | 후크: 예약된 재부팅 후 |
| --- | --- | --- | --- | --- |
| 필요한 경우 재부팅 | 패치가 시작되기 전에 SSM 문서를 실행합니다. 사용 예: 패치 프로세스가 시작되기 전에 애플리케이션을 안전하게 종료합니다. | 패치 작업 종료 시 및 관리형 노드 재부팅 전에 SSM 문서를 실행합니다. 사용 예: 잠재적 재부팅 전에 서드 파티 애플리케이션 설치와 같은 작업을 실행합니다. | 패치 적용 작업이 완료되고 인스턴스가 재부팅되면 SSM 문서를 실행합니다. 사용 예: 패치 후 애플리케이션이 예상대로 실행되고 있는지 확인합니다. | 사용할 수 없음 |
| 인스턴스 재부팅 안 함 | 위와 동일합니다. | 패치 작업 종료 시 SSM 문서를 실행합니다. 사용 예시: 패치 후 애플리케이션이 예상대로 실행되고 있는지 확인합니다. | *사용할 수 없음* | *사용할 수 없음* |
| 재부팅 시간 예약 | 위와 동일합니다. | 인스턴스 재부팅 안 함과 동일합니다. | 사용할 수 없음 | 예약된 재부팅이 완료된 후 바로 SSM 문서를 실행합니다. 사용 예: 재부팅 후 애플리케이션이 예상대로 실행되고 있는지 확인합니다. |
## '지금 패치(Patch now)' 실행
다음 절차에 따라 온디맨드로 관리형 노드를 패치합니다.
**'지금 패치(Patch now)'를 실행하려면**
1. [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)에서 AWS Systems Manager 콘솔을 엽니다.
1. 탐색 창에서 **Patch Manager**를 선택합니다.
1. [**지금 패치(Patch now)**]를 선택합니다.
1. [**패치 작업(Patching operation)**]에서 다음 중 하나를 선택합니다.
+ **스캔(Scan)**: Patch Manager가 관리형 노드에서 누락된 패치를 찾지만 설치하지는 않습니다. [**Compliance**] 대시보드 또는 패치 규정 준수를 보는 데 사용하는 다른 도구에서 결과를 볼 수 있습니다.
+ **스캔 및 설치(Scan and install)**: Patch Manager가 관리형 노드에서 누락된 패치를 찾아 설치합니다.
1. 이전 단계에서 [**검사 후 설치(Scan and install)**]를 선택한 경우에만 이 단계를 사용합니다. [**재부팅 옵션(Reboot option)**]에서 다음 중 하나를 선택합니다.
+ **필요한 경우 재부팅(Reboot if needed)**: 설치 후 패치 설치를 완료하는 데 필요한 경우에만 Patch Manager가 관리형 노드를 재부팅합니다.
+ **인스턴스 재부팅 안 함(Don't reboot my instances)**: 설치 후 Patch Manager가 관리형 노드를 재부팅하지 않습니다. Patch Manager 밖에서 재부팅을 선택하거나 관리할 때 노드를 수동으로 재부팅할 수 있습니다.
+ **재부팅 시간 예약(Schedule a reboot time)**: Patch Manager가 관리형 노드를 재부팅할 날짜, 시간 및 UTC 시간대를 지정합니다. **지금 패치(Patch now)** 작업을 실행한 후, 예약된 재부팅이 `AWS-PatchRebootAssociation`이라는 이름과 함께 State Manager에 연결로 나열됩니다.
**중요**
기본 패치 작업이 시작된 후에 기본 패치 작업을 취소하면 State Manager의 `AWS-PatchRebootAssociation` 연결이 자동으로 취소되지 않습니다. 예기치 않은 재부팅을 방지하기 위해 예약된 재부팅이 발생하는 것을 더 이상 원하지 않는 경우 State Manager에서 `AWS-PatchRebootAssociation`을 수동으로 삭제해야 합니다. 이렇게 하지 않으면 예기치 않은 시스템 재부팅이 발생하여 프로덕션 워크로드에 영향을 미칠 수 있습니다. 이 연결은 Systems Manager 콘솔의 **State Manager** > **연결**에서 찾을 수 있습니다.
1. [**패치를 적용할 인스턴스(Instances to patch)**] 섹션에서 다음 중 하나를 선택합니다.
+ **모든 인스턴스 패치(Patch all instances)**: Patch Manager가 현재 AWS 리전의 AWS 계정에서 모든 관리형 노드에 대해 지정된 작업을 실행합니다.
+ **지정한 대상 인스턴스만 패치(Patch only the target instances I specify)**: 다음 단계에서 대상으로 지정할 관리형 노드를 지정합니다.
1. 이전 단계에서 [**지정한 대상 인스턴스만 패치(Patch only the target instances I specify)**]를 선택한 경우에만 이 단계를 사용합니다. **대상 선택(Target selection)** 섹션에서 태그를 지정하거나, 수동으로 노드를 선택하거나, 리소스 그룹을 지정하여 이 작업을 실행할 노드를 식별합니다.
**참고**
예상한 관리형 노드가 목록에 없으면 [관리형 노드 가용성 문제 해결](fleet-manager-troubleshooting-managed-nodes.md)에서 문제 해결 팁을 참조하세요.
리소스 그룹을 대상으로 선택하는 경우 AWS CloudFormation 스택을 기반으로 하는 리소스 그룹은 여전히 기본 `aws:cloudformation:stack-id` 태그로 태그를 지정해야 합니다. 제거된 경우 Patch Manager가 리소스 그룹에 속하는 관리형 노드를 확인하지 못할 수 있습니다.
1. (옵션) 이 패치 작업에서 로그를 생성하고 저장하려면 [**패치 로그 스토리지(Patching log storage)**]에서 로그를 저장할 S3 버킷을 선택합니다.
**참고**
데이터를 S3 버킷에 쓰는 기능을 부여하는 S3 권한은 이 작업을 수행하는 IAM 사용자의 권한이 아니라 인스턴스에 할당된 인스턴스 프로파일(EC2 인스턴스용) 또는 IAM 서비스 역할(하이브리드 정품 인증 시스템)의 권한입니다. 자세한 내용은 [Systems Manager에 필요한 인스턴스 권한 구성](setup-instance-permissions.md) 또는 [하이브리드 및 멀티클라우드 환경에서 Systems Manager에 필요한 IAM 서비스 역할 생성](hybrid-multicloud-service-role.md)을 참조하세요. 또한 지정된 S3 버킷이 다른 AWS 계정에 있는 경우 관리형 노드와 연결된 인스턴스 프로파일 또는 IAM 서비스 역할은 해당 버킷에 쓸 수 있는 권한이 있어야 합니다.
1. (옵션) 패치 작업의 특정 지점 동안 SSM 문서를 수명 주기 후크로 실행하려면 다음을 수행합니다.
+ [**수명 주기 후크 사용(Use lifecycle hooks)**]을 선택합니다.
+ 사용 가능한 각 후크에 대해 작업의 지정된 지점에서 실행할 SSM 문서를 선택합니다.
+ 설치 전
+ 설치 후
+ 종료 시
+ 예약된 재부팅 후
**참고**
기본 문서인 `AWS-Noop`은 작업을 실행하지 않습니다.
1. [**지금 패치(Patch now)**]를 선택합니다.
[**연결 실행 요약(Association execution summary)**] 페이지가 열립니다. (이제 패치 작업에 AWS Systems Manager의 도구인 State Manager의 연결이 사용됩니다.) **작업 요약(Operation summary)** 영역에서 지정한 관리형 노드의 스캔 또는 패치 상태를 모니터링할 수 있습니다.
# 패치 기준 작업
AWS Systems Manager의 도구인 Patch Manager의 패치 기준은 관리형 노드에 대한 설치가 승인되는 패치를 정의합니다. 패치 승인 또는 거부는 하나씩 지정할 수 있습니다. 또한 자동 승인 규칙을 생성하여 특정 유형의 업데이트(예: 필수 업데이트)가 자동 승인되도록 지정할 수도 있습니다. 거부된 목록은 규칙 및 승인 목록을 모두 재정의합니다. 승인된 패치 목록을 사용하여 특정 패키지를 설치하려면 먼저 모든 자동 승인 규칙을 제거하십시오. 임의 패치를 명시적으로 거부로 구분하면 해당 패치는 자동 승인 규칙의 모든 기준을 만족하더라도 승인 또는 설치되지 않습니다. 또한 패치가 해당 관리형 노드에 대해 승인되었더라도 노드의 소프트웨어에 적용되는 경우에만 패치가 관리형 노드에 설치됩니다.
**Topics**
+ [AWS가 미리 정의한 패치 기준 보기](patch-manager-view-predefined-patch-baselines.md)
+ [사용자 정의 패치 기준 작업](patch-manager-manage-patch-baselines.md)
+ [기존 패치 기준을 기본값으로 설정](patch-manager-default-patch-baseline.md)
**추가 정보**
+ [패치 기준](patch-manager-patch-baselines.md)
# AWS가 미리 정의한 패치 기준 보기
AWS Systems Manager의 도구인 Patch Manager에는 Patch Manager가 지원하는 각 운영 체제에 대해 미리 정의된 패치 기준이 있습니다. 이 패치 기준선을 사용하거나(기본 패치 기준선은 사용자 지정할 수 없음), 혹은 자체 기준선을 생성할 수도 있습니다. 다음 절차에서는 미리 정의된 패치 기준이 해당 요건을 충족하는지 확인하는 방법을 설명합니다. 패치 기준선에 대한 자세한 내용은 [미리 정의된 사용자 지정 패치 기준](patch-manager-predefined-and-custom-patch-baselines.md) 섹션을 참조하세요.
**AWS가 미리 정의한 패치 기준을 보려면**
1. [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)에서 AWS Systems Manager 콘솔을 엽니다.
1. 탐색 창에서 **Patch Manager**를 선택합니다.
1. 패치 기준 목록에서 미리 정의된 패치 기준 중 하나의 기준 ID를 선택하십시오.
-또는-
현재 AWS 리전에서 Patch Manager에 처음으로 액세스하는 경우 **개요로 시작**을 선택하고, **패치 기준선**을 선택한 다음에 사전 정의된 패치 기준선 중 하나의 기준선 ID를 선택합니다.
**참고**
Windows Server에는 3개의 미리 정의된 패치 기준이 제공됩니다. 패치 기준 `AWS-DefaultPatchBaseline` 및 `AWS-WindowsPredefinedPatchBaseline-OS`는 Windows 운영 체제 자체에서 운영 체제 업데이트만 지원합니다. `AWS-DefaultPatchBaseline`은 다른 패치 기준을 지정하지 않는 한 Windows Server 관리형 노드의 기본 패치 기준으로 사용됩니다. 이러한 두 패치 기준의 구성 설정은 동일합니다. 둘 중 더 새로운 `AWS-WindowsPredefinedPatchBaseline-OS`는 Windows Server에 대해 미리 정의된 세 번째 패치 기준과 구별하기 위해 생성되었습니다. 해당 패치 기준인 `AWS-WindowsPredefinedPatchBaseline-OS-Applications`는 Windows Server 운영 체제 및 Microsoft에서 릴리스한 지원되는 애플리케이션을 패치하는 데 사용될 수 있습니다.
자세한 내용은 [기존 패치 기준을 기본값으로 설정](patch-manager-default-patch-baseline.md) 섹션을 참조하세요.
1. **승인 규칙** 섹션에서 패치 기준선 구성을 검토합니다.
1. 구성이 관리형 노드에 적합한 경우 [패치 그룹 생성 및 관리](patch-manager-tag-a-patch-group.md) 절차로 건너뛸 수 있습니다.
-또는-
자체적으로 기본 패치 기준선을 생성하려면 [사용자 정의 패치 기준 작업](patch-manager-manage-patch-baselines.md) 주제를 계속 진행합니다.
# 사용자 정의 패치 기준 작업
AWS Systems Manager의 도구인 Patch Manager에는 Patch Manager가 지원하는 각 운영 체제에 대해 미리 정의된 패치 기준이 있습니다. 이 패치 기준선을 사용하거나(기본 패치 기준선은 사용자 지정할 수 없음), 혹은 자체 기준선을 생성할 수도 있습니다.
다음 절차에서는 사용자 정의 패치 기준을 직접 생성, 업데이트 및 삭제하는 방법을 설명합니다. 패치 기준선에 대한 자세한 내용은 [미리 정의된 사용자 지정 패치 기준](patch-manager-predefined-and-custom-patch-baselines.md) 섹션을 참조하세요.
**Topics**
+ [Linux를 위한 사용자 지정 패치 기준 생성](patch-manager-create-a-patch-baseline-for-linux.md)
+ [macOS를 위한 사용자 지정 패치 기준 생성](patch-manager-create-a-patch-baseline-for-macos.md)
+ [Windows Server를 위한 사용자 지정 패치 기준 생성](patch-manager-create-a-patch-baseline-for-windows.md)
+ [사용자 지정 패치 기준선 업데이트 또는 삭제](patch-manager-update-or-delete-a-patch-baseline.md)
# Linux를 위한 사용자 지정 패치 기준 생성
AWS Systems Manager의 도구인 Patch Manager에서 Linux 관리형 노드에 대한 사용자 정의 패치 기준을 생성하려면 다음 절차를 따릅니다.
macOS 관리형 노드의 패치 기준 생성에 대한 자세한 내용은 [macOS를 위한 사용자 지정 패치 기준 생성](patch-manager-create-a-patch-baseline-for-macos.md) 섹션을 참조하세요. Windows 관리형 노드의 패치 기준 생성에 대한 자세한 내용은 [Windows Server를 위한 사용자 지정 패치 기준 생성](patch-manager-create-a-patch-baseline-for-windows.md) 섹션을 참조하세요.
**Linux 관리형 노드의 사용자 정의 패치 기준 생성**
1. [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)에서 AWS Systems Manager 콘솔을 엽니다.
1. 탐색 창에서 **Patch Manager**를 선택합니다.
1. **패치 기준선** 탭을 선택한 다음 **패치 기준선 생성**을 선택합니다.
-또는-
현재 AWS 리전에서 처음으로 Patch Manager에 액세스한 경우 **개요를 통한 시작**을 선택하고 **패치 기준선** 탭을 선택한 다음, **패치 기준선 생성**을 선택합니다.
1. **Name(이름)** 필드에 새로운 패치 기준 이름(예: `MyRHELPatchBaseline`)을 입력합니다.
1. (선택 사항) **설명**에 이 패치 기준에 대한 설명을 입력합니다.
1. **Operating system**에서 운영 체제(예: `Red Hat Enterprise Linux`)를 선택합니다.
1. 이 패치 기준을 생성하는 즉시 선택한 운영 체제의 기본값으로 사용하려면 **Set this patch baseline as the default patch baseline for *operating system name* instances(이 패치 기준을 operating system name 인스턴스의 기본 패치 기준으로 설정)** 옆에 있는 확인란을 선택합니다.
**참고**
이 옵션은 2022년 12월 22일에 [패치 정책](patch-manager-policies.md)이 릴리스되기 전에 Patch Manager에 처음 액세스한 경우에만 사용할 수 있습니다.
기존 패치 기준을 기본값으로 설정하는 방법에 대한 자세한 내용은 [기존 패치 기준을 기본값으로 설정](patch-manager-default-patch-baseline.md) 섹션을 참조하세요.
1. **Approval rules for operating systems(운영 체제에 대한 승인 규칙)** 섹션에서 필드를 사용하여 자동 승인 규칙을 한 개 이상 생성합니다.
+ **제품**: 승인 규칙이 적용되는 운영 체제 버전입니다(예: `RedhatEnterpriseLinux7.4`). 기본 선택은 `All`입니다.
+ **Classification(분류)**: 승인 규칙이 적용되는 패치 유형입니다(예: `Security` 또는 `Enhancement`). 기본 선택은 `All`입니다.
**작은 정보**
패치 기준을 구성하여 RHEL 7.8과 같이 Linux용 부 버전 업그레이드의 설치 여부를 제어할 수 있습니다. 해당 리포지토리에서 업데이트할 수 있는 경우 Patch Manager를 통해 부 버전 업그레이드를 자동 설치할 수 있습니다.
Linux 운영 체제의 경우 부 버전 업그레이드는 일관되게 분류되지 않습니다. 동일한 커널 버전 내에서도 버그 수정 또는 보안 업데이트로 분류되거나 분류되지 않을 수 있습니다. 다음은 패치 기준으로 패치 설치 여부를 제어하는 몇 가지 옵션입니다.
**옵션 1**: 마이너 버전 업그레이드가 가능한 경우 설치되도록 하기 위한 가장 광범위한 승인 규칙은 **Classification(분류)**을 `All`(\$1)로 지정하고 **Include nonsecurity updates(비보안 업데이트 포함)** 옵션을 선택하는 것입니다.
**옵션 2**: 운영 체제 버전에 대한 패치가 설치되도록 하려면 와일드카드(\$1) 를 사용하여 기준의 **Patch exceptions(패치 예외)** 섹션에서 커널 형식을 지정할 수 있습니다. 예를 들어 RHEL 7.\$1의 커널 형식은 `kernel-3.10.0-*.el7.x86_64`입니다.
부 버전 업그레이드를 포함한 모든 패치가 RHEL 7.\$1 관리형 노드에 적용되도록 하려면 패치 기준의 **Approved patches(승인된 패치)** 목록에 `kernel-3.10.0-*.el7.x86_64`를 입력합니다. (부 버전 패치의 정확한 패키지 이름을 알고 있다면 대신 입력할 수 있음)
**옵션 3**: `AWS-RunPatchBaseline` 문서에서 [InstallOverrideList](patch-manager-aws-runpatchbaseline.md#patch-manager-aws-runpatchbaseline-parameters-installoverridelist) 파라미터를 사용하여 부 버전 업그레이드 등, 관리형 노드에 적용할 패치를 가장 많이 제어할 수 있습니다. 자세한 내용은 [패치를 위한 SSM 명령 문서: `AWS-RunPatchBaseline`](patch-manager-aws-runpatchbaseline.md) 섹션을 참조하세요.
+ **Severity**: 규칙이 적용될 패치의 심각도 값입니다(예: `Critical`). 기본 선택은 `All`입니다.
+ **Auto-approval**: 자동 승인을 위해 패치를 선택하는 방법입니다.
**참고**
Ubuntu Server에 대한 업데이트 패키지의 릴리스 날짜를 확실히 결정할 수 없으므로 이 운영 체제에서는 자동 승인 옵션이 지원되지 않습니다.
+ **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일 또는 그 이후에 릴리스되거나 마지막으로 업데이트된 패치가 자동으로 설치되지 않습니다.
+ (선택 사항) **규정 준수 보고**: 기준선에 따라 승인된 패치에 할당하려는 심각도 수준입니다(예: `Critical` 또는 `High`).
**참고**
규정 준수 보고 수준을 지정하고 승인된 패치의 패치 상태가 `Missing`으로 보고되는 경우 패치 기준선의 전반적인 보고된 규정 준수 심각도는 사용자가 지정한 심각도 수준입니다.
+ **Include non-security updates(비보안 업데이트 포함)**: 보안 관련 패치 외에, 소스 리포지토리에서 사용 가능한 비보안 Linux 운영 체제 패치도 설치하려면 확인란을 선택합니다.
사용자 지정 패치 기준의 승인 규칙 작업에 대한 자세한 내용은 [사용자 지정 기준](patch-manager-predefined-and-custom-patch-baselines.md#patch-manager-baselines-custom) 섹션을 참조하세요.
1. 승인 규칙을 준수하는 패치 이외에 모든 패치를 명시적으로 승인하려면 **패치 예외** 섹션에서 다음을 수행합니다.
+ **Approved patches(승인된 패치)**에 승인할 패치의 쉼표로 구분된 목록을 입력합니다.
승인된 패치 및 거부된 패치 목록의 승인된 형식에 대한 자세한 내용은 [승인 패치 및 거부 패치 목록의 패키지 이름 형식](patch-manager-approved-rejected-package-name-formats.md) 섹션을 참조하세요.
+ (선택 사항) **Approved patches compliance level(승인된 패치 규정 준수 수준)**에서 규정 준수 수준을 목록의 패치에 할당합니다.
+ 지정하는 승인된 패치가 보안과 관련되지 않은 경우 Linux 운영 체제에 이러한 패치를 설치하려면 **비보안 업데이트 포함** 확인란을 선택합니다.
1. 승인 규칙을 준수하는 패치를 명시적으로 거부하려면 **패치 예외** 섹션에서 다음을 수행합니다.
+ **Rejected patches(거부된 패치)**에 거부할 패치의 쉼표로 구분된 목록을 입력합니다.
승인된 패치 및 거부된 패치 목록의 승인된 형식에 대한 자세한 내용은 [승인 패치 및 거부 패치 목록의 패키지 이름 형식](patch-manager-approved-rejected-package-name-formats.md) 섹션을 참조하세요.
+ [**거부된 패치 작업(Rejected patches action)**]에서 Patch Manager가 [**거부된 패치(Rejected patches)**] 목록에 포함된 패치에 대해 수행할 작업을 선택합니다.
+ [**종속성으로 허용(Allow as dependency)**]: [**거부된 패치(Rejected patches)**] 목록에 있는 패키지는 다른 패키지에 종속성을 가질 때만 설치됩니다. 이 경우 패치 기준을 준수하는 것으로 간주되고 상태가 *InstalledOther*로 보고됩니다. 이는 옵션을 지정하지 않은 경우의 기본 작업입니다.
+ **차단**: **거부된 패치** 목록에 있는 패키지와 종속적으로 그것들을 포함하는 패키지는 어떠한 경우에도 Patch Manager에서 설치되지 않습니다. 패키지가 **거부된 패치** 목록에 추가되기 전에 설치되거나 이후에 Patch Manager 외부에 설치된 경우 패치 기준을 준수하지 않는 것으로 간주되고 상태가 *InstalledRejected*로 보고됩니다.
**참고**
Patch Manager는 패치 종속성을 재귀적으로 검색합니다.
1. (선택 사항) *AmazonLinux2016.03* 및 *AmazonLinux2017.09* 등의 다른 운영 체제 버전에 대해 대체 패치 리포지토리를 지정하려면 **패치 소스** 섹션에서 각 제품에 대해 다음을 수행합니다.
+ **Name**에 소스 구성을 식별하는 데 도움이 되는 이름을 입력합니다.
+ **Product**에서 패치 소스 리포지토리의 운영 체제 버전을 선택합니다(예: `RedhatEnterpriseLinux7.4`).
+ **구성**에서 사용할 yum 리포지토리 구성의 값을 적절한 형식으로 입력합니다.
------
#### [ Example for yum repositories ]
```
[main]
name=MyCustomRepository
baseurl=https://my-custom-repository
enabled=1
```
**작은 정보**
yum 리포지토리 구성에 사용할 수 있는 기타 옵션에 대한 자세한 내용은 [dnf.conf(5)](https://man7.org/linux/man-pages/man5/dnf.conf.5.html)를 참조하세요.
------
#### [ Examples for Ubuntu 서버 and Debian 서버 ]
`deb http://security.ubuntu.com/ubuntu jammy main`
`deb https://site.example.com/debian distribution component1 component2 component3`
Ubuntu Server 리포지토리에 대한 리포지토리 정보는 한 줄로 지정해야 합니다. 더 많은 예제 및 정보는 *Ubuntu Server Manuals* 웹 사이트의 [jammy (5) sources.list.5.gz](https://manpages.ubuntu.com/manpages/jammy/man5/sources.list.5.html) 및 *Debian Wiki*의 [sources.list format](https://wiki.debian.org/SourcesList#sources.list_format)을 참조하세요.
------
각 추가 운영 체제 버전(최대 20개)에 대해 소스 리포지토리를 지정하려면 **Add another source(다른 소스 추가)**를 선택합니다.
대체 소스 패치 리포지토리에 대한 자세한 내용은 [대체 패치 소스 리포지토리를 지정하는 방법(Linux)](patch-manager-alternative-source-repository.md) 섹션을 참조하세요.
1. (선택 사항) **Manage tags(태그 관리)**의 경우, 하나 이상의 태그 키 이름/값 페어를 패치 기준에 적용합니다.
태그는 리소스에 할당하는 선택적 메타데이터입니다. 태그를 사용하면 용도, 소유자 또는 환경을 기준으로 하는 등 리소스를 다양한 방식으로 분류할 수 있습니다. 예를 들어, 패치 기준에 태그를 지정하여 패치의 심각도 수준, 해당 패치가 적용되는 운영 체제 제품군 및 환경 유형을 식별할 수 있습니다. 이 경우 다음 키 이름/값 페어와 비슷한 태그를 지정할 수 있습니다.
+ `Key=PatchSeverity,Value=Critical`
+ `Key=OS,Value=RHEL`
+ `Key=Environment,Value=Production`
1. **패치 기준 생성**을 선택합니다.
# macOS를 위한 사용자 지정 패치 기준 생성
AWS Systems Manager의 도구인 Patch Manager에서 macOS 관리형 노드에 대한 사용자 정의 패치 기준을 생성하려면 다음 절차를 따릅니다.
Windows Server 관리형 노드의 패치 기준 생성에 대한 자세한 내용은 [Windows Server를 위한 사용자 지정 패치 기준 생성](patch-manager-create-a-patch-baseline-for-windows.md) 섹션을 참조하세요. Linux 관리형 노드의 패치 기준 생성에 대한 자세한 내용은 [Linux를 위한 사용자 지정 패치 기준 생성](patch-manager-create-a-patch-baseline-for-linux.md) 섹션을 참조하세요.
**참고**
일부 AWS 리전에서는 macOS가 지원되지 않습니다. macOS용 Amazon EC2 지원에 대한 자세한 내용은 *Amazon EC2 사용 설명서*의 [Amazon EC2 Mac 인스턴스](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-mac-instances.html)를 참조하세요.
**macOS 관리형 노드의 사용자 정의 패치 기준 생성**
1. [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)에서 AWS Systems Manager 콘솔을 엽니다.
1. 탐색 창에서 **Patch Manager**를 선택합니다.
1. **패치 기준선** 탭을 선택한 다음 **패치 기준선 생성**을 선택합니다.
-또는-
현재 AWS 리전에서 처음으로 Patch Manager에 액세스한 경우 **개요를 통한 시작**을 선택하고 **패치 기준선** 탭을 선택한 다음, **패치 기준선 생성**을 선택합니다.
1. **Name(이름)** 필드에 새로운 패치 기준 이름(예: `MymacOSPatchBaseline`)을 입력합니다.
1. (선택 사항) **설명**에 이 패치 기준에 대한 설명을 입력합니다.
1. **운영 체제**에서 macOS를 선택합니다.
1. 이 패치 기준을 생성하는 즉시 macOS의 기본값으로 사용하려면 [**이 패치 기준을 macOS 인스턴스의 기본 패치 기준으로 설정(Set this patch baseline as the default patch baseline for macOS instances)**] 옆에 있는 확인란을 선택합니다.
**참고**
이 옵션은 2022년 12월 22일에 [패치 정책](patch-manager-policies.md)이 릴리스되기 전에 Patch Manager에 처음 액세스한 경우에만 사용할 수 있습니다.
기존 패치 기준을 기본값으로 설정하는 방법에 대한 자세한 내용은 [기존 패치 기준을 기본값으로 설정](patch-manager-default-patch-baseline.md) 섹션을 참조하세요.
1. **Approval rules for operating systems(운영 체제에 대한 승인 규칙)** 섹션에서 필드를 사용하여 자동 승인 규칙을 한 개 이상 생성합니다.
+ **제품**: 승인 규칙이 적용되는 운영 체제 버전입니다(예: `BigSur11.3.1` 또는 `Ventura13.7`). 기본 선택은 `All`입니다.
+ **분류**: 패치 작업 중 패키지를 적용하려는 하나 이상의 패키지 관리자입니다. 사용자는 다음 중에서 선택할 수 있습니다.
+ softwareupdate
+ 설치 관리자
+ brew
+ brew cask
기본 선택은 `All`입니다.
+ (선택 사항) **규정 준수 보고**: 기준선에 따라 승인된 패치에 할당하려는 심각도 수준입니다(예: `Critical` 또는 `High`).
**참고**
규정 준수 보고 수준을 지정하고 승인된 패치의 패치 상태가 `Missing`으로 보고되는 경우 패치 기준선의 전반적인 보고된 규정 준수 심각도는 사용자가 지정한 심각도 수준입니다.
사용자 지정 패치 기준의 승인 규칙 작업에 대한 자세한 내용은 [사용자 지정 기준](patch-manager-predefined-and-custom-patch-baselines.md#patch-manager-baselines-custom) 섹션을 참조하세요.
1. 승인 규칙을 준수하는 패치 이외에 모든 패치를 명시적으로 승인하려면 **패치 예외** 섹션에서 다음을 수행합니다.
+ **Approved patches(승인된 패치)**에 승인할 패치의 쉼표로 구분된 목록을 입력합니다.
승인된 패치 및 거부된 패치 목록의 승인된 형식에 대한 자세한 내용은 [승인 패치 및 거부 패치 목록의 패키지 이름 형식](patch-manager-approved-rejected-package-name-formats.md) 섹션을 참조하세요.
+ (선택 사항) **Approved patches compliance level(승인된 패치 규정 준수 수준)**에서 규정 준수 수준을 목록의 패치에 할당합니다.
1. 승인 규칙을 준수하는 패치를 명시적으로 거부하려면 **패치 예외** 섹션에서 다음을 수행합니다.
+ **Rejected patches(거부된 패치)**에 거부할 패치의 쉼표로 구분된 목록을 입력합니다.
승인된 패치 및 거부된 패치 목록의 승인된 형식에 대한 자세한 내용은 [승인 패치 및 거부 패치 목록의 패키지 이름 형식](patch-manager-approved-rejected-package-name-formats.md) 섹션을 참조하세요.
+ [**거부된 패치 작업(Rejected patches action)**]에서 Patch Manager가 [**거부된 패치(Rejected patches)**] 목록에 포함된 패치에 대해 수행할 작업을 선택합니다.
+ [**종속성으로 허용(Allow as dependency)**]: [**거부된 패치(Rejected patches)**] 목록에 있는 패키지는 다른 패키지에 종속성을 가질 때만 설치됩니다. 이 경우 패치 기준을 준수하는 것으로 간주되고 상태가 *InstalledOther*로 보고됩니다. 이는 옵션을 지정하지 않은 경우의 기본 작업입니다.
+ **차단**: **거부된 패치** 목록에 있는 패키지와 종속적으로 그것들을 포함하는 패키지는 어떠한 경우에도 Patch Manager에서 설치되지 않습니다. 패키지가 **거부된 패치** 목록에 추가되기 전에 설치되거나 이후에 Patch Manager 외부에 설치된 경우 패치 기준을 준수하지 않는 것으로 간주되고 상태가 *InstalledRejected*로 보고됩니다.
1. (선택 사항) **Manage tags(태그 관리)**의 경우, 하나 이상의 태그 키 이름/값 페어를 패치 기준에 적용합니다.
태그는 리소스에 할당하는 선택적 메타데이터입니다. 태그를 사용하면 용도, 소유자 또는 환경을 기준으로 하는 등 리소스를 다양한 방식으로 분류할 수 있습니다. 예를 들어 패치 기준에 태그를 지정하여 지정한 패치의 심각도 수준, 적용되는 패키지 관리자 및 환경 유형을 식별할 수 있습니다. 이 경우 다음 키 이름/값 페어와 비슷한 태그를 지정할 수 있습니다.
+ `Key=PatchSeverity,Value=Critical`
+ `Key=PackageManager,Value=softwareupdate`
+ `Key=Environment,Value=Production`
1. **패치 기준 생성**을 선택합니다.
# Windows Server를 위한 사용자 지정 패치 기준 생성
AWS Systems Manager의 도구인 Patch Manager에서 Windows 관리형 노드에 대한 사용자 정의 패치 기준을 생성하려면 다음 절차를 따릅니다.
Linux 관리형 노드의 패치 기준 생성에 대한 자세한 내용은 [Linux를 위한 사용자 지정 패치 기준 생성](patch-manager-create-a-patch-baseline-for-linux.md) 섹션을 참조하세요. macOS 관리형 노드의 패치 기준 생성에 대한 자세한 내용은 [macOS를 위한 사용자 지정 패치 기준 생성](patch-manager-create-a-patch-baseline-for-macos.md) 섹션을 참조하세요.
Windows 서비스 팩 설치에만 제한되는 패치 기준 생성의 예는 [자습서: 콘솔을 사용한 Windows 서비스 팩 설치를 위한 패치 기준 생성](patch-manager-windows-service-pack-patch-baseline-tutorial.md) 섹션을 참조하세요.
**사용자 지정 패치 기준을 생성하려면(Windows)**
1. [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)에서 AWS Systems Manager 콘솔을 엽니다.
1. 탐색 창에서 **Patch Manager**를 선택합니다.
1. **패치 기준선** 탭을 선택한 다음 **패치 기준선 생성**을 선택합니다.
-또는-
현재 AWS 리전에서 처음으로 Patch Manager에 액세스한 경우 **개요를 통한 시작**을 선택하고 **패치 기준선** 탭을 선택한 다음, **패치 기준선 생성**을 선택합니다.
1. **Name(이름)** 필드에 새로운 패치 기준 이름(예: `MyWindowsPatchBaseline`)을 입력합니다.
1. (선택 사항) **설명**에 이 패치 기준에 대한 설명을 입력합니다.
1. **운영 체제**에서 `Windows`를 선택합니다.
1. **사용 가능한 보안 업데이트 규정 준수 상태**에서 사용 가능하지만 패치 기준에 지정된 설치 기준을 충족하지 않기 때문에 승인되지 않은 보안 패치에 할당하려는 상태(**Non-Compliant** 또는 **Compliant**)를 선택합니다.
예제 시나리오: 설치 전에 패치가 릴리스된 후 장기간 대기하도록 지정한 경우 설치하려는 보안 패치를 건너뛸 수 있습니다. 지정된 대기 기간 동안 패치 업데이트가 릴리스되면 패치 설치 대기 기간이 다시 시작됩니다. 대기 기간이 너무 길면 여러 버전의 패치가 릴리스될 수 있지만 설치되지는 않습니다.
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`). 기본 선택은 `All`입니다.
+ **Classification(분류)**: 승인 규칙이 적용되는 패치 유형입니다(예: `CriticalUpdates`, `Drivers` 및 `Tools`). 기본 선택은 `All`입니다.
**작은 정보**
`ServicePacks`를 포함하거나 [**분류(Classification)**] 목록에서 `All`을 선택하여 Windows 서비스 팩 설치를 승인 규칙에 포함할 수 있습니다. 문제 해결 예는 [자습서: 콘솔을 사용한 Windows 서비스 팩 설치를 위한 패치 기준 생성](patch-manager-windows-service-pack-patch-baseline-tutorial.md)을(를) 참조하세요.
+ **Severity**: 규칙이 적용될 패치의 심각도 값입니다(예: `Critical`). 기본 선택은 `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. (옵션) [**애플리케이션에 대한 승인 규칙(Approval rules for applications)**] 섹션에서 필드를 사용하여 자동 승인 규칙을 1개 이상 생성합니다.
**참고**
승인 규칙을 지정하는 대신 승인된 패치 및 거부된 패치 목록을 패치 예외로 지정할 수 있습니다. 10단계와 11단계를 참조하세요.
+ **Product family**: 규칙을 지정하려는 일반 Microsoft 제품군입니다(예: `Office` 또는 `Exchange Server`).
+ **제품**: 승인 규칙이 적용되는 애플리케이션 버전입니다(예: `Office 2016` 또는 `Active Directory Rights Management Services Client 2.0 2016`). 기본 선택은 `All`입니다.
+ **Classification**: 승인 규칙이 적용되는 패치 유형입니다(예: `CriticalUpdates`). 기본 선택은 `All`입니다.
+ **Severity**: 규칙이 적용되는 패치의 심각도 값입니다(예: `Critical`). 기본 선택은 `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일 또는 그 이후에 릴리스되거나 마지막으로 업데이트된 패치가 자동으로 설치되지 않습니다.
+ (선택 사항) **규정 준수 보고**: 기준선에 따라 승인된 패치에 할당하려는 심각도 수준입니다(예: `Critical` 또는 `High`).
**참고**
규정 준수 보고 수준을 지정하고 승인된 패치의 패치 상태가 `Missing`으로 보고되는 경우 패치 기준선의 전반적인 보고된 규정 준수 심각도는 사용자가 지정한 심각도 수준입니다.
1. (옵션) 승인 규칙에 따라 패치를 선택하는 대신 패치를 명시적으로 승인하려면 [**패치 예외(Patch exceptions)**] 섹션에서 다음을 수행합니다.
+ **Approved patches(승인된 패치)**에 승인할 패치의 쉼표로 구분된 목록을 입력합니다.
승인된 패치 및 거부된 패치 목록의 승인된 형식에 대한 자세한 내용은 [승인 패치 및 거부 패치 목록의 패키지 이름 형식](patch-manager-approved-rejected-package-name-formats.md) 섹션을 참조하세요.
+ (선택 사항) **Approved patches compliance level(승인된 패치 규정 준수 수준)**에서 규정 준수 수준을 목록의 패치에 할당합니다.
1. 승인 규칙을 준수하는 패치를 명시적으로 거부하려면 **패치 예외** 섹션에서 다음을 수행합니다.
+ **Rejected patches(거부된 패치)**에 거부할 패치의 쉼표로 구분된 목록을 입력합니다.
승인된 패치 및 거부된 패치 목록의 승인된 형식에 대한 자세한 내용은 [승인 패치 및 거부 패치 목록의 패키지 이름 형식](patch-manager-approved-rejected-package-name-formats.md) 섹션을 참조하세요.
+ [**거부된 패치 작업(Rejected patches action)**]에서 Patch Manager가 [**거부된 패치(Rejected patches)**] 목록에 포함된 패치에 대해 수행할 작업을 선택합니다.
+ **종속성으로 허용**: Windows Server에서는 패키지 종속성 개념을 지원하지 않습니다. **거부된 패치** 목록에 있는 패키지가 노드에 이미 설치되어 있는 경우 해당 상태가 `INSTALLED_OTHER`로 보고됩니다. 노드에 아직 설치되지 않은 패키지는 모두 건너뜁니다.
+ **차단**: **거부된 패치** 목록에 있는 패키지는 어떤 경우에도 Patch Manager에서 설치하지 않습니다. 패키지가 **거부된 패치** 목록에 추가되기 전에 설치되거나 이후에 Patch Manager 외부에 설치된 경우 패치 기준을 준수하지 않는 것으로 간주되고 상태가 `INSTALLED_REJECTED`로 보고됩니다.
거부된 패치 작업에 대한 자세한 내용은 [사용자 지정 패치 기준의 거부된 패치 목록 옵션](patch-manager-windows-and-linux-differences.md#rejected-patches-diff)을 참조하세요.
1. (선택 사항) **Manage tags(태그 관리)**의 경우, 하나 이상의 태그 키 이름/값 페어를 패치 기준에 적용합니다.
태그는 리소스에 할당하는 선택적 메타데이터입니다. 태그를 사용하면 용도, 소유자 또는 환경을 기준으로 하는 등 리소스를 다양한 방식으로 분류할 수 있습니다. 예를 들어, 패치 기준에 태그를 지정하여 패치의 심각도 수준, 해당 패치가 적용되는 운영 체제 제품군 및 환경 유형을 식별할 수 있습니다. 이 경우 다음 키 이름/값 페어와 비슷한 태그를 지정할 수 있습니다.
+ `Key=PatchSeverity,Value=Critical`
+ `Key=OS,Value=RHEL`
+ `Key=Environment,Value=Production`
1. **패치 기준 생성**을 선택합니다.
# 사용자 지정 패치 기준선 업데이트 또는 삭제
AWS Systems Manager의 도구인 Patch Manager에서 생성한 사용자 지정 패치 기준을 업데이트하거나 삭제할 수 있습니다. 패치 기준선을 업데이트할 때 이름 또는 설명, 승인 규칙 및 승인된 패치와 거부된 패치 예외를 변경할 수 있습니다. 패치 기준선에 적용된 태그를 업데이트할 수도 있습니다. 패치 기준선이 생성된 운영 체제 유형은 변경할 수 없으며 AWS에서 제공한 미리 정의된 패치 기준은 변경할 수 없습니다.
## 패치 기준선 업데이트 또는 삭제
다음 단계에 따라 패치 기준선을 업데이트하거나 삭제하십시오.
**중요**
Quick Setup의 패치 정책 구성에 사용될 수 있는 사용자 지정 패치 기준선을 삭제할 때는 주의해야 합니다.
Quick Setup에서 [패치 정책 구성](patch-manager-policies.md)을 사용하는 경우 사용자 지정 패치 기준선에 대한 업데이트는 한 시간에 한 번씩 Quick Setup과 동기화됩니다.
패치 정책에서 참조된 사용자 지정 패치 기준선이 삭제되면 해당 패치 정책의 Quick Setup **Configuration details**(구성 세부 정보) 페이지에 배너가 표시됩니다. 배너는 패치 정책에서 더 이상 존재하지 않는 패치 기준선을 참조하고 있으며 후속 패치 작업이 실패할 것임을 알려줍니다. 이 경우 Quick Setup **Configurations**(구성) 페이지로 돌아가서 Patch Manager 구성을 선택하고 **Actions**(작업), **Edit configuration**(구성 편집)을 선택합니다. 삭제된 패치 기준선 이름이 강조 표시되며, 영향을 받는 운영 체제의 새 패치 기준선을 선택해야 합니다.
**패치 기준선을 업데이트 또는 삭제하는 방법**
1. [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)에서 AWS Systems Manager 콘솔을 엽니다.
1. 탐색 창에서 **Patch Manager**를 선택합니다.
1. 업데이트 또는 삭제할 패치 기준선을 선택하고 다음 중 하나를 수행합니다.
+ AWS 계정에서 패치 기준선을 제거하려면 [**삭제(Delete)**]를 선택합니다. 시스템에 작업을 확인하라는 메시지가 표시됩니다.
+ 패치 기준선 이름 또는 설명, 승인 규칙 또는 패치 예외를 변경하려면 **편집**을 선택하십시오. **패치 기준선 편집** 페이지에서 원하는 값과 옵션을 변경한 다음 **변경 사항 저장**을 선택하십시오.
+ 패치 기준선에 적용된 태그를 추가, 변경 또는 삭제하려면 **태그** 탭을 선택한 다음 **태그 편집**을 선택하십시오. **Edit patch baseline tags(패치 기준선 태그 편집)** 페이지에서 패치 기준 태그를 업데이트한 다음 **변경 사항 저장**을 선택합니다.
선택 가능한 구성에 대한 자세한 내용은 [사용자 정의 패치 기준 작업](patch-manager-manage-patch-baselines.md) 섹션을 참조하세요.
# 기존 패치 기준을 기본값으로 설정
**중요**
여기서 선택한 기본 패치 기준선은 패치 정책을 기반으로 하는 패치 작업에 적용되지 않습니다. 패치 정책에서는 고유한 패치 기준선 사양을 사용합니다. 패치 정책에 대한 자세한 내용은 [Quick Setup의 패치 정책 구성](patch-manager-policies.md) 섹션을 참조하세요.
AWS Systems Manager의 도구인 Patch Manager에 사용자 정의 패치 기준을 생성할 때, 기준을 생성하는 즉시 연결된 운영 체제 유형의 기본값으로 설정할 수 있습니다. 자세한 내용은 [사용자 정의 패치 기준 작업](patch-manager-manage-patch-baselines.md) 섹션을 참조하세요.
기존 패치 기준을 운영 체제 유형의 기본값으로 설정할 수도 있습니다.
**참고**
2022년 12월 22일의 패치 정책 릴리스 이전 또는 이후에 처음 Patch Manager에 액세스했는지에 따라 사용자가 따르는 단계가 달라집니다. 해당 날짜 이전에 Patch Manager를 사용했다면 콘솔 절차를 사용할 수 있습니다. 그렇지 않으면 AWS CLI 절차를 사용합니다. 콘솔 절차에서 참조되는 **작업** 메뉴는 패치 정책 릴리스 이전에 Patch Manager가 사용되지 않은 리전에는 표시되지 않습니다.
**패치 기준을 기본값으로 설정하려면**
1. [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)에서 AWS Systems Manager 콘솔을 엽니다.
1. 탐색 창에서 **Patch Manager**를 선택합니다.
1. [**패치 기준(Patch baselines)**] 탭을 선택합니다.
1. 패치 기준 목록에서 현재 운영 체제 유형의 기본값으로 설정되지 않은 패치 기준의 버튼을 선택합니다.
**Default baseline(기본 기준)** 열은 현재 어떤 기준이 기본값으로 설정되어 있는지 나타냅니다.
1. **작업** 메뉴에서 **Set default patch baseline(기본 패치 기준 설정)**을 선택하십시오.
**중요**
2022년 12월 22일 이전에 현재 AWS 계정 및 리전에서 Patch Manager로 작업하지 않은 경우 **작업** 메뉴를 사용할 수 없습니다. 자세한 내용은 이 주제 앞부분의 **참고**를 참조하세요.
1. 확인 대화 상자가 나타나면 **Set default(기본값으로 설정)**를 선택합니다.
**패치 기준선을 기본값으로 설정하는 방법(AWS CLI)**
1. 사용 가능한 패치 기준선과 해당 ID, Amazon 리소스 이름(ARN) 목록을 보려면 [https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-patch-baselines.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-patch-baselines.html) 명령을 실행합니다.
```
aws ssm describe-patch-baselines
```
1. 기준선을 연결된 운영 체제의 기본값으로 설정하려면 [https://docs.aws.amazon.com/cli/latest/reference/ssm/register-default-patch-baseline.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/register-default-patch-baseline.html) 명령을 실행합니다. *baseline-id-or-ARN*을 사용할 사용자 지정 패치 기준선 또는 사전 정의된 기준선의 ID로 바꿉니다.
------
#### [ Linux & macOS ]
```
aws ssm register-default-patch-baseline \
--baseline-id baseline-id-or-ARN
```
다음은 사용자 지정 기준선을 기본값으로 설정하는 예제입니다.
```
aws ssm register-default-patch-baseline \
--baseline-id pb-abc123cf9bEXAMPLE
```
다음은 AWS에서 관리하는 사전 정의된 기준선을 기본값으로 설정하는 예제입니다.
```
aws ssm register-default-patch-baseline \
--baseline-id arn:aws:ssm:us-east-2:733109147000:patchbaseline/pb-0574b43a65ea646e
```
------
#### [ Windows Server ]
```
aws ssm register-default-patch-baseline ^
--baseline-id baseline-id-or-ARN
```
다음은 사용자 지정 기준선을 기본값으로 설정하는 예제입니다.
```
aws ssm register-default-patch-baseline ^
--baseline-id pb-abc123cf9bEXAMPLE
```
다음은 AWS에서 관리하는 사전 정의된 기준선을 기본값으로 설정하는 예제입니다.
```
aws ssm register-default-patch-baseline ^
--baseline-id arn:aws:ssm:us-east-2:733109147000:patchbaseline/pb-071da192df1226b63
```
------
# 사용 가능한 패치 보기
AWS Systems Manager의 도구인 Patch Manager로 지정된 운영 체제 및 특정 운영 체제 버전(옵션)에 대해 사용 가능한 패치를 모두 볼 수 있습니다.
**작은 정보**
사용 가능한 패치 목록을 생성하여 파일에 저장하려면 [https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-available-patches.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-available-patches.html) 명령을 사용하고 기본 설정 [출력](https://docs.aws.amazon.com/cli/latest/reference/ssm/cli-usage-output.html)을 지정합니다.
**사용 가능한 패치를 보려면**
1. [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)에서 AWS Systems Manager 콘솔을 엽니다.
1. 탐색 창에서 **Patch Manager**를 선택합니다.
1. [**패치(Patches)**] 탭을 클릭합니다.
-또는-
현재 AWS 리전에서 처음으로 Patch Manager에 액세스한 경우 **개요를 통한 시작**을 선택하고 **패치** 탭을 선택합니다.
**참고**
Windows Server의 경우 Windows Server 업데이트 서비스(WSUS)에서 사용할 수 있는 업데이트가 **패치** 탭에 표시됩니다.
1. [**운영 체제(Operating system)**]에서 사용 가능한 패치를 보려는 운영 체제(예: `Windows` 또는 `Amazon Linux`)를 선택합니다.
1. (옵션) [**제품(Product)**]에서 OS 버전(예 :`WindowsServer2019` 또는 `AmazonLinux2018.03`)을 선택합니다.
1. (옵션) 결과에 대한 정보 열을 추가하거나 제거하려면 [**패치(Patches)**] 목록 오른쪽 위에 있는 구성 버튼(![\[The icon to view configuration settings.\]](http://docs.aws.amazon.com/ko_kr/systems-manager/latest/userguide/images/configure-button.png))을 선택합니다. (기본적으로 [**패치(Patches)**] 탭에는 사용 가능한 패치 메타데이터 중 일부에 대한 열만 표시됩니다.)
뷰에 추가할 수 있는 메타데이터 유형에 대한 자세한 내용은 *AWS Systems Manager API Reference*의 [Patch](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_Patch.html)를 참조하세요.
# 패치 그룹 생성 및 관리
작업에서 패치 정책을 사용하지 **않는 경우 태그를 사용하여 패치 그룹에 관리형 노드를 추가하면 패치 적용 작업을 구성할 수 있습니다.
**참고**
패치 그룹은 *패치 정책*을 기반으로 하는 패치 적용 작업에 사용되지 않습니다. 패치 정책 작업에 대한 자세한 내용은 [Quick Setup의 패치 정책 구성](patch-manager-policies.md) 섹션을 참조하세요.
2022년 12월 22일에 패치 정책 지원이 릴리스될 당시에 패치 그룹을 사용하고 있지 않았던 계정-리전 페어에 대해서는 콘솔에서 패치 그룹 기능이 지원되지 않습니다. 이 날짜 이전에 패치 그룹을 사용하기 시작한 계정-리전 페어에서는 패치 그룹 기능을 계속 사용할 수 있습니다.
패치 적용 작업에 태그를 사용하려면 태그 키 `Patch Group` 또는 `PatchGroup`을 관리형 노드에 적용해야 합니다. 패치 그룹에 태그 값으로 제공할 이름도 지정해야 합니다. 값을 지정하는 데는 제한이 없지만 태그 키는 `Patch Group` 또는 `PatchGroup`이어야 합니다.
[EC2 인스턴스 메타데이터에서 태그를 허용](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html#allow-access-to-tags-in-IMDS)한 경우 `PatchGroup`(스페이스 사용 안 함)이 필요합니다.
태그를 사용하여 관리형 노드를 그룹화한 후에 패치 기준에 패치 그룹 값을 추가해야 합니다. 패치 그룹을 패치 기준선에 등록하여 패치 적용 작업 중 올바른 패치가 설치되는지 확인할 수 있습니다. 패치 그룹에 대한 자세한 내용은 [패치 그룹](patch-manager-patch-groups.md) 섹션을 참조하세요.
이 주제의 작업을 완료하여 태그를 노드 및 패치 기준선과 함께 사용하여 패치를 적용할 관리형 노드를 준비합니다. 작업 1은 Amazon EC2 인스턴스에 패치를 적용하는 경우에만 필요합니다. 작업 2는 [하이브리드 및 멀티클라우드](operating-systems-and-machine-types.md#supported-machine-types) 환경에서 비 EC2 인스턴스에 패치를 적용하는 경우에만 필요합니다. 작업 3은 모든 관리형 노드에 필요합니다.
**작은 정보**
AWS CLI 명령 `[https://docs.aws.amazon.com/cli/latest/reference/ssm/add-tags-to-resource.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/add-tags-to-resource.html)` 또는 Systems Manager API 작업 ssm-agent-minimum-s3-permissions-required`[https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_AddTagsToResource.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_AddTagsToResource.html)`를 사용하여 관리형 노드에 태그를 추가할 수도 있습니다.
**Topics**
+ [태스크 1: 태그를 사용하여 패치 그룹에 EC2 인스턴스 추가](#sysman-patch-group-tagging-ec2)
+ [태스크 2: 태그를 사용하여 패치 그룹에 관리형 인스턴스 추가](#sysman-patch-group-tagging-managed)
+ [작업 3: 패치 기준에 패치 그룹 추가](#sysman-patch-group-patchbaseline)
## 태스크 1: 태그를 사용하여 패치 그룹에 EC2 인스턴스 추가
Systems Manager 콘솔 또는 Amazon EC2 콘솔을 사용하여 EC2 인스턴스에 태그를 추가할 수 있습니다. 이 작업은 Amazon EC2 인스턴스에 패치를 적용하는 경우에만 필요합니다.
**중요**
**Allow tags in instance metadata**(인스턴스 메타데이터의 태그 허용) 옵션이 인스턴스에서 활성화된 경우 `Patch Group` 태그(공백 포함)를 Amazon EC2 인스턴스에 적용할 수 없습니다. 인스턴스 메타데이터에서 태그를 허용하면 태그 키 이름에 공백이 포함되지 않습니다. [EC2 인스턴스 메타데이터에 태그를 허용](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html#allow-access-to-tags-in-IMDS)한 경우 태그 키 `PatchGroup`(공백 없음)을 사용해야 합니다.
**옵션 1: 패치 그룹에 EC2 인스턴스를 추가하는 방법(Systems Manager 콘솔)**
1. [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)에서 AWS Systems Manager 콘솔을 엽니다.
1. 탐색 창에서 **Fleet Manager**를 선택합니다.
1. **관리형 인스턴스** 목록에서 패치 적용을 위해 구성하려는 관리형 EC2 인스턴스의 ID를 선택합니다. EC2 인스턴스의 노드 ID는 `i-`으로 시작합니다.
**참고**
Amazon EC2 콘솔과 AWS CLI를 사용하는 경우 Systems Manager에 사용하도록 아직 구성되지 않은 인스턴스에 `Key = Patch Group` 또는 `Key = PatchGroup` 태그를 적용할 수 있습니다.
예상한 관리형 노드가 목록에 없으면 [관리형 노드 가용성 문제 해결](fleet-manager-troubleshooting-managed-nodes.md)에서 문제 해결 팁을 참조하세요.
1. **태그** 탭을 선택한 다음에 **편집**을 선택합니다.
1. 왼쪽 열에 **Patch Group** 또는 **PatchGroup**을 입력합니다. [EC2 인스턴스 메타데이터에 태그를 허용](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html#allow-access-to-tags-in-IMDS)한 경우 `PatchGroup`(공백 없음)을 사용해야 합니다.
1. 오른쪽 열에서 패치 그룹의 이름으로 사용할 태그 값을 입력합니다.
1. **저장**을 선택합니다.
1. 이 절차를 반복하여 동일한 패치 그룹에 다른 EC2 인스턴스를 추가합니다.
**옵션 2: 패치 그룹에 EC2 인스턴스를 추가하는 방법(Amazon EC2 콘솔)**
1. [Amazon EC2 콘솔](https://console.aws.amazon.com/ec2/)을 열고 탐색 창에서 [**인스턴스(Instances)**]를 선택합니다.
1. 인스턴스 목록에서 패치로 구성할 인스턴스를 선택합니다.
1. **작업** 메뉴에서 **인스턴스 설정**, **태그 관리**를 선택합니다.
1. **새로운 태그 추가**를 선택합니다.
1. **Key**(키)에 **Patch Group** 또는 **PatchGroup**을 입력합니다. [EC2 인스턴스 메타데이터에 태그를 허용](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html#allow-access-to-tags-in-IMDS)한 경우 `PatchGroup`(공백 없음)을 사용해야 합니다.
1. **값**의 경우 패치 그룹의 이름으로 사용할 값을 입력합니다.
1. **저장**을 선택합니다.
1. 이 절차를 반복하여 동일한 패치 그룹에 다른 인스턴스를 추가합니다.
## 태스크 2: 태그를 사용하여 패치 그룹에 관리형 인스턴스 추가
이 주제의 단계에 따라 AWS IoT Greengrass 코어 디바이스와 비 EC2 하이브리드 정품 인증 관리형 노드에 태그를 추가합니다(mi-\$1). 이 작업은 하이브리드 및 멀티클라우드 환경에서 비 EC2 인스턴스에 패치를 적용하는 경우에만 필요합니다.
**참고**
Amazon EC2 콘솔을 사용하여 비 EC2 관리형 노드의 태그를 추가할 수 없습니다.
**패치 그룹에 비 EC2 관리형 노드를 추가하는 방법(Systems Manager 콘솔)**
1. [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)에서 AWS Systems Manager 콘솔을 엽니다.
1. 탐색 창에서 **Fleet Manager**를 선택합니다.
1. **관리형 노드** 목록에서 패치로 구성할 관리형 노드의 이름을 선택합니다.
**참고**
예상한 관리형 노드가 목록에 없으면 [관리형 노드 가용성 문제 해결](fleet-manager-troubleshooting-managed-nodes.md)에서 문제 해결 팁을 참조하세요.
1. **태그** 탭을 선택한 다음에 **편집**을 선택합니다.
1. 왼쪽 열에 **Patch Group** 또는 **PatchGroup**을 입력합니다. [EC2 인스턴스 메타데이터에 태그를 허용](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html#allow-access-to-tags-in-IMDS)한 경우 `PatchGroup`(공백 없음)을 사용해야 합니다.
1. 오른쪽 열에서 패치 그룹의 이름으로 사용할 태그 값을 입력합니다.
1. **저장**을 선택합니다.
1. 이 절차를 반복하여 동일한 패치 그룹에 다른 관리형 노드를 추가합니다.
## 작업 3: 패치 기준에 패치 그룹 추가
특정 패치 기준을 관리형 노드와 연결하려면 패치 기준에 패치 그룹 값을 추가해야 합니다. 패치 그룹을 패치 기준선에 등록하여 패치 적용 작업 중 올바른 패치가 설치되는지 확인할 수 있습니다. 이 작업 EC2 인스턴스, 비 EC2 관리형 노드 또는 둘 다에 패치를 적용하든 상관없이 필요합니다.
패치 그룹에 대한 자세한 내용은 [패치 그룹](patch-manager-patch-groups.md) 섹션을 참조하세요.
**참고**
2022년 12월 22일의 [패치 정책](patch-manager-policies.md) 릴리스 이전 또는 이후에 처음 Patch Manager에 액세스했는지에 따라 사용자가 따르는 단계가 달라집니다.
**패치 기준선에 패치 그룹을 추가하는 방법(Systems Manager 콘솔)**
1. [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)에서 AWS Systems Manager 콘솔을 엽니다.
1. 탐색 창에서 **Patch Manager**를 선택합니다.
1. 현재 AWS 리전에서 처음으로 Patch Manager에 액세스하고 Patch Manager 시작 페이지가 열리면 **개요로 시작**을 선택합니다.
1. **패치 기준선** 탭을 선택한 다음에 **패치 기준선** 목록에서 패치 그룹에 대해 구성하려는 패치 기준선의 이름을 선택합니다.
패치 정책 릴리스 이후까지 처음 Patch Manager에 액세스하지 않았다면 직접 생성한 사용자 지정 기준선을 선택해야 합니다.
1. **기준선 ID** 세부 정보 페이지에 **작업** 메뉴가 포함되어 있으면 다음을 수행합니다.
+ **작업**, **Modify patch groups(패치 그룹 수정)**을 선택합니다.
+ [태스크 2: 태그를 사용하여 패치 그룹에 관리형 인스턴스 추가](#sysman-patch-group-tagging-managed)에서 관리형 노드에 추가한 태그 값**을 입력한 다음에 **추가**를 선택합니다.
**기준선 ID** 세부 정보 페이지에 **작업** 메뉴가 포함되어 있지 **않으면 콘솔에서 패치 그룹을 구성할 수 없습니다. 그 대신에 다음 중 하나를 수행할 수 있습니다.
+ (권장) AWS Systems Manager의 도구인 Quick Setup에서 패치 정책을 설정하여 패치 기준을 하나 이상의 EC2 인스턴스에 매핑합니다.
자세한 내용은 [Quick Setup 패치 정책 사용](https://docs.aws.amazon.com/systems-manager/latest/userguide/patch-manager-policies.html) 및 [Quick Setup 패치 정책을 사용하여 조직 전반의 패치 적용 자동화](https://docs.aws.amazon.com/systems-manager/latest/userguide/quick-setup-patch-manager.html)를 참조하세요.
+ AWS Command Line Interface(AWS CLI) 의 [https://docs.aws.amazon.com/cli/latest/reference/ssm/register-patch-baseline-for-patch-group.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/register-patch-baseline-for-patch-group.html)명령을 사용하여 패치 그룹을 구성합니다.
# Patch Manager와 AWS Security Hub CSPM 통합
[AWS Security Hub CSPM](https://docs.aws.amazon.com/securityhub/latest/userguide/what-is-securityhub.html)는 AWS 내의 보안 상태에 대한 포괄적인 뷰를 제공합니다. Security Hub CSPM은 AWS 계정, AWS 서비스 및 지원되는 서드 파티 파트너 제품에서 보안 데이터를 수집합니다. Security Hub CSPM을 사용하면 환경에서 보안 업계 표준 및 모범 사례를 준수하는지 확인할 수 있습니다. Security Hub CSPM은 보안 추세를 분석하고 우선순위가 가장 높은 보안 문제를 식별하는 데 도움이 됩니다.
AWS Systems Manager의 도구인 Patch Manager와 Security Hub CSPM 간 통합을 사용하여 Patch Manager에서 Security Hub CSPM으로 규정 미준수 노드에 관한 조사 결과를 보낼 수 있습니다. 결과는 보안 점검 또는 보안 관련 감지의 관찰 가능한 기록입니다. 그러면 Security Hub CSPM은 보안 태세 분석에 이러한 패치 관련 결과를 포함할 수 있습니다.
다음 항목의 정보는 패치 작업에 사용하는 구성 방법 또는 유형에 관계없이 적용됩니다.
+ Quick Setup에서 구성된 패치 정책
+ Quick Setup에서 구성된 호스트 관리 옵션
+ 패치 `Scan` 또는 `Install` 태스크를 실행하기 위한 유지 관리 기간
+ 온디맨드 **Patch now**(지금 패치) 작업
**Contents**
+ [Patch Manager에서 Security Hub CSPM으로 조사 결과를 전송하는 방법](#securityhub-integration-sending-findings)
+ [Patch Manager이(가) 보내는 결과의 유형](#securityhub-integration-finding-types)
+ [조사 결과 전송 지연 시간](#securityhub-integration-finding-latency)
+ [Security Hub CSPM을 사용할 수 없을 때 다시 시도](#securityhub-integration-retry-send)
+ [Security Hub CSPM에서 조사 결과 보기](#securityhub-integration-view-findings)
+ [Patch Manager의 일반적 조사 결과](#securityhub-integration-finding-example)
+ [통합 설정 및 구성](#securityhub-integration-enable)
+ [결과 전송을 중지하는 방법](#securityhub-integration-disable)
## Patch Manager에서 Security Hub CSPM으로 조사 결과를 전송하는 방법
Security Hub CSPM에서는 보안 문제를 조사 결과와 같이 추적합니다. 일부 결과는 다른 AWS 서비스 또는 서드 파티에서 감지한 문제에서 비롯됩니다. Security Hub CSPM에는 보안 문제를 감지하고 조사 결과를 생성하는 데 사용하는 규칙 집합도 있습니다.
Patch Manager는 결과를 Security Hub CSPM으로 보내는 Systems Manager 도구 중 하나입니다. SSM 문서(`AWS-RunPatchBaseline`, `AWS-RunPatchBaselineAssociation` 또는 `AWS-RunPatchBaselineWithHooks`)를 실행하여 패치 작업을 수행하면 패치 정보가 AWS Systems Manager의 도구인 Inventory나 Compliance 또는 둘 다로 전송됩니다. Inventory나 Compliance 또는 둘 다 데이터를 수신한 후 Patch Manager가 알림을 수신합니다. 그런 다음 Patch Manager가 데이터의 정확성, 형식 및 규정 준수 여부를 평가합니다. 모든 조건이 충족되면 Patch Manager는 데이터를 Security Hub CSPM으로 전달합니다.
Security Hub CSPM은 이러한 모든 출처를 총망라하여 조사 결과를 관리할 도구를 제공합니다. 사용자는 조사 결과 목록을 조회하고 필터링할 수 있으며 주어진 조사 결과의 세부 정보를 조회할 수도 있습니다. 자세한 내용은 *AWS Security Hub User Guide*의 [Viewing findings](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-findings-viewing.html)를 참조하세요. 또한 주어진 조사 결과에 대한 조사 상태를 추적할 수도 있습니다. 자세한 내용은 *AWS Security Hub User Guide*의 [Taking action on findings](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-findings-taking-action.html)를 참조하세요.
Security Hub CSPM의 모든 조사 결과는 표준 JSON 형식을 사용합니다. 이를 AWS Security Finding Format(ASFF)이라고 합니다. ASFF에는 문제의 출처, 영향을 받은 리소스와 결과의 현재 상태 등에 관한 세부 정보가 포함됩니다. 자세한 내용은 *AWS Security Hub User Guide*의 [AWS Security Finding Format (ASFF)](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-findings-format.htm)을 참조하세요.
### Patch Manager이(가) 보내는 결과의 유형
Patch Manager는 [AWS Security Finding Format(ASFF)](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-findings-format.html)을 사용하여 결과를 Security Hub CSPM으로 보냅니다. ASFF의 경우, `Types` 필드가 조사 결과 유형을 제공합니다. Patch Manager의 결과는 `Types`의 값이 다음과 같습니다.
+ 소프트웨어 및 구성 확인/패치 관리
Patch Manager는 규정을 준수하지 않는 관리형 노드당 하나의 조사 결과를 보냅니다. 조사 결과는 리소스 유형 [https://docs.aws.amazon.com//securityhub/latest/userguide/securityhub-findings-format-attributes.html#asff-resourcedetails-awsec2instance](https://docs.aws.amazon.com//securityhub/latest/userguide/securityhub-findings-format-attributes.html#asff-resourcedetails-awsec2instance)로 보고되므로 조사 결과는 `AwsEc2Instance` 리소스 유형을 보고하는 다른 Security Hub CSPM 통합과 상호 연관될 수 있습니다. Patch Manager는 작업에서 관리형 노드가 비준수임을 발견한 경우에만 조사 결과를 Security Hub CSPM으로 전달합니다. 조사 결과에는 패치 요약 결과가 포함됩니다.
**참고**
규정 미준수 노드를 Security Hub CSPM에 보고한 후에 노드가 규정을 준수하면 Patch Manager는 Security Hub CSPM에 업데이트를 보내지 않습니다. 필요한 패치를 관리형 노드에 적용한 후 Security Hub CSPM에서 조사 결과를 수동으로 확인할 수 있습니다.
규정 준수 정의에 대한 자세한 내용은 [패치 규정 준수 상태 값](patch-manager-compliance-states.md) 섹션을 참조하세요. `PatchSummary`에 대한 자세한 내용은 *AWS Security Hub API Reference*의 [PatchSummary](https://docs.aws.amazon.com//securityhub/1.0/APIReference/API_PatchSummary.html)를 참조하세요.
### 조사 결과 전송 지연 시간
Patch Manager가 새로운 조사 결과를 생성하면 일반적으로 몇 초에서 2시간 이내에 Security Hub CSPM으로 결과가 전송됩니다. 속도는 해당 시간에 처리 중인 AWS 리전의 트래픽에 따라 달라집니다.
### Security Hub CSPM을 사용할 수 없을 때 다시 시도
서비스 중단이 발생하면 AWS Lambda 기능이 실행되어 서비스가 다시 실행된 후 메시지를 기본 대기열에 다시 넣습니다. 메시지가 기본 대기열에 있으면 다시 시도는 자동으로 수행됩니다.
Security Hub CSPM을 사용할 수 없는 경우 Patch Manager는 결과가 수신될 때까지 결과 전송을 재시도합니다.
### Security Hub CSPM에서 조사 결과 보기
이 절차에서는 패치 규정을 준수하지 않는 플릿의 관리형 노드에 대한 Security Hub CSPM의 조사 결과를 보는 방법을 설명합니다.
**패치 규정 준수에 대한 Security Hub CSPM 조사 결과를 검토하는 방법**
1. AWS Management Console에 로그인하고 [https://console.aws.amazon.com/securityhub/](https://console.aws.amazon.com/securityhub/)에서 AWS Security Hub CSPM 콘솔을 엽니다.
1. 탐색 창에서 **조사 결과**를 선택합니다.
1. **필터 추가**(![\[The Search icon\]](http://docs.aws.amazon.com/ko_kr/systems-manager/latest/userguide/images/search-icon.png)) 상자를 선택합니다.
1. 메뉴의 **필터**에서 **제품 이름**을 선택합니다.
1. 이때 열리는 대화 상자의 첫 번째 필드에서 **is**를 선택한 다음에 두 번째 필드에서 **Systems Manager Patch Manager**를 입력합니다.
1. **Apply(적용)**를 선택합니다.
1. 결과 범위를 좁히는 데 도움이 되도록 원하는 추가 필터를 추가합니다.
1. 자세한 내용을 알아보려는 조사 결과의 제목을 결과 목록에서 선택합니다.
화면 오른쪽에 리소스, 발견된 문제 및 권장 문제 해결에 대한 자세한 정보가 포함된 창이 열립니다.
**중요**
현재 Security Hub CSPM에서는 모든 관리형 노드의 리소스 유형을 `EC2 Instance`로 보고합니다. 여기에는 Systems Manager에서 사용하려고 등록한 온프레미스 서버와 가상 머신이 포함됩니다.
**심각도 분류**
**Systems Manager Patch Manager**의 결과 목록에는 조사 결과의 심각도에 대한 보고서가 포함됩니다. **심각도** 수준에는 최저부터 최고까지 다음이 포함됩니다.
+ **INFORMATIONAL ** – 찾은 문제가 없습니다.
+ **LOW** – 문제 해결이 필요하지 않습니다.
+ **MEDIUM** – 문제를 해결해야 하지만 긴급하지는 않습니다.
+ **HIGH** – 우선적으로 해결해야 할 문제입니다.
+ **CRITICAL** – 문제가 에스컬레이션되지 않도록 즉시 해결해야 합니다.
심각도는 인스턴스의 가장 심각한 규정 미준수 패키지에 의해 결정됩니다. 심각도 수준 여러 개인 패치 기준선이 여러 개 있을 수 있으므로 모든 규정 미준수 패키지 중에서 최고 심각도가 보고됩니다. 예를 들면, 패키지 A의 심각도는 "심각"이고 패키지 B의 심각도는 "낮음"인 2개의 규정 미준수 패키지가 있을 수 있습니다. "심각"이 심각도로 보고됩니다.
심각도 필드는 Patch Manager `Compliance` 필드와 직접적으로 연관됩니다. 이 필드는 규칙과 일치하는 개별 패치에 할당되도록 설정하는 필드입니다. 이 `Compliance` 필드는 개별 패치에 할당되므로 패치 요약 수준에서는 반영되지 않습니다.
**관련 콘텐츠**
+ **AWS Security Hub 사용 설명서의 [조사 결과](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-findings.html)
+ **AWS 관리 및 거버넌스 블로그의 [Patch Manager 및 Security Hub로 다중 계정 패치 규정 준수](https://aws.amazon.com/blogs/mt/multi-account-patch-compliance-with-patch-manager-and-security-hub/)
## Patch Manager의 일반적 조사 결과
Patch Manager는 [AWS Security Finding Format(ASFF)](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-findings-format.html)을 사용하여 조사 결과를 Security Hub CSPM으로 보냅니다.
다음은 Patch Manager의 일반적인 조사 결과를 예시로 나타낸 것입니다.
```
{
"SchemaVersion": "2018-10-08",
"Id": "arn:aws:patchmanager:us-east-2:111122223333:instance/i-02573cafcfEXAMPLE/document/AWS-RunPatchBaseline/run-command/d710f5bd-04e3-47b4-82f6-df4e0EXAMPLE",
"ProductArn": "arn:aws:securityhub:us-east-1::product/aws/ssm-patch-manager",
"GeneratorId": "d710f5bd-04e3-47b4-82f6-df4e0EXAMPLE",
"AwsAccountId": "111122223333",
"Types": [
"Software & Configuration Checks/Patch Management/Compliance"
],
"CreatedAt": "2021-11-11T22:05:25Z",
"UpdatedAt": "2021-11-11T22:05:25Z",
"Severity": {
"Label": "INFORMATIONAL",
"Normalized": 0
},
"Title": "Systems Manager Patch Summary - Managed Instance Non-Compliant",
"Description": "This AWS control checks whether each instance that is managed by AWS Systems Manager is in compliance with the rules of the patch baseline that applies to that instance when a compliance Scan runs.",
"Remediation": {
"Recommendation": {
"Text": "For information about bringing instances into patch compliance, see 'Remediating out-of-compliance instances (Patch Manager)'.",
"Url": "https://docs.aws.amazon.com/systems-manager/latest/userguide/patch-compliance-remediation.html"
}
},
"SourceUrl": "https://us-east-2.console.aws.amazon.com/systems-manager/fleet-manager/i-02573cafcfEXAMPLE/patch?region=us-east-2",
"ProductFields": {
"aws/securityhub/FindingId": "arn:aws:securityhub:us-east-2::product/aws/ssm-patch-manager/arn:aws:patchmanager:us-east-2:111122223333:instance/i-02573cafcfEXAMPLE/document/AWS-RunPatchBaseline/run-command/d710f5bd-04e3-47b4-82f6-df4e0EXAMPLE",
"aws/securityhub/ProductName": "Systems Manager Patch Manager",
"aws/securityhub/CompanyName": "AWS"
},
"Resources": [
{
"Type": "AwsEc2Instance",
"Id": "i-02573cafcfEXAMPLE",
"Partition": "aws",
"Region": "us-east-2"
}
],
"WorkflowState": "NEW",
"Workflow": {
"Status": "NEW"
},
"RecordState": "ACTIVE",
"PatchSummary": {
"Id": "pb-0c10e65780EXAMPLE",
"InstalledCount": 45,
"MissingCount": 2,
"FailedCount": 0,
"InstalledOtherCount": 396,
"InstalledRejectedCount": 0,
"InstalledPendingReboot": 0,
"OperationStartTime": "2021-11-11T22:05:06Z",
"OperationEndTime": "2021-11-11T22:05:25Z",
"RebootOption": "NoReboot",
"Operation": "SCAN"
}
}
```
## 통합 설정 및 구성
Patch Manager와 Security Hub CSPM 통합을 사용하려면 Security Hub CSPM을 설정해야 합니다. Security Hub CSPM을 설정하는 방법에 대한 자세한 내용은 *AWS Security Hub 사용 설명서*의 [Security Hub CSPM 설정](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-settingup.html)을 참조하세요.
다음 절차에서는 Security Hub CSPM이 이미 활성화되어 있지만 Patch Manager 통합이 해제된 경우 Patch Manager와 Security Hub CSPM을 통합하는 방법을 설명합니다. 통합이 수동으로 해제된 경우에만 이 절차를 수행합니다.
**Security Hub CSPM 통합에 Patch Manager를 추가하려면**
1. 탐색 창에서 **Patch Manager**를 선택합니다.
1. **설정** 탭을 선택합니다.
-또는-
현재 AWS 리전에서 처음으로 Patch Manager에 액세스한 경우 **개요를 통한 시작**을 선택하고 **설정** 탭을 선택합니다.
1. **Security Hub CSPM으로 내보내기** 섹션 아래의 **패치 규정 준수 결과가 Security Hub로 내보내지지 않음** 오른쪽에서 **사용**을 선택합니다.
## 결과 전송을 중지하는 방법
Security Hub CSPM으로 조사 결과를 전송하는 작업을 중지하려면 Security Hub CSPM 콘솔 또는 API를 사용하면 됩니다.
자세한 내용은 AWS Security Hub 사용 설명서**에서 다음 주제를 참조하세요.
+ [통합에서 결과의 흐름 사용 중지 및 사용 설정(콘솔)](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-integrations-managing.html#securityhub-integration-findings-flow-console)
+ [통합에서 결과의 흐름 사용 중지(Security Hub CSPM API, AWS CLI)](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-integrations-managing.html#securityhub-integration-findings-flow-disable-api)
# AWS CLI를 사용하여 Patch Manager 리소스 작업
이 섹션에는 AWS Systems Manager의 도구인 Patch Manager에 대한 구성 태스크를 수행하는 데 사용할 수 있는 AWS Command Line Interface(AWS CLI) 명령의 예시가 포함되어 있습니다.
AWS CLI를 사용하여 사용자 맞춤 패치 기준선에 따라 서버 환경을 패치하는 방법은 [자습서: AWS CLI를 사용한 서버 환경에 패치 적용](patch-manager-patch-servers-using-the-aws-cli.md) 섹션을 참조하세요.
AWS Systems Manager 태스크에 AWS CLI 사용에 대한 자세한 내용은 [AWS CLI Command Reference의 AWS Systems Manager 섹션](https://docs.aws.amazon.com/cli/latest/reference/ssm/index.html)을 참조하세요.
**Topics**
+ [패치 기준을 위한 AWS CLI 명령](#patch-baseline-cli-commands)
+ [패치 그룹을 위한 AWS CLI 명령](#patch-group-cli-commands)
+ [패치 요약 및 세부 정보 보기를 위한 AWS CLI 명령](#patch-details-cli-commands)
+ [관리형 노드 스캔 및 패치를 위한 AWS CLI 명령](#patch-operations-cli-commands)
## 패치 기준을 위한 AWS CLI 명령
**Topics**
+ [패치 기준선 생성](#patch-manager-cli-commands-create-patch-baseline)
+ [다른 OS 버전에 대한 사용자 지정 리포지토리가 있는 패치 기준 생성](#patch-manager-cli-commands-create-patch-baseline-mult-sources)
+ [패치 기준선 업데이트](#patch-manager-cli-commands-update-patch-baseline)
+ [패치 기준선 이름 변경](#patch-manager-cli-commands-rename-patch-baseline)
+ [패치 기준선 삭제](#patch-manager-cli-commands-delete-patch-baseline)
+ [모든 패치 기준선 나열](#patch-manager-cli-commands-describe-patch-baselines)
+ [AWS가 제공하는 모든 패치 기준 나열](#patch-manager-cli-commands-describe-patch-baselines-aws)
+ [사용자의 패치 기준선 나열](#patch-manager-cli-commands-describe-patch-baselines-custom)
+ [패치 기준선 표시](#patch-manager-cli-commands-get-patch-baseline)
+ [기본 패치 기준선 받기](#patch-manager-cli-commands-get-default-patch-baseline)
+ [사용자 지정 패치 기준을 기본값으로 설정](#patch-manager-cli-commands-register-default-patch-baseline)
+ [AWS 패치 기준을 기본값으로 재설정](#patch-manager-cli-commands-register-aws-patch-baseline)
+ [패치 기준선 태그 지정](#patch-manager-cli-commands-add-tags-to-resource)
+ [패치 기준선에 대한 태그 나열](#patch-manager-cli-commands-list-tags-for-resource)
+ [패치 기준선에서 태그 삭제](#patch-manager-cli-commands-remove-tags-from-resource)
### 패치 기준선 생성
다음 명령은 릴리스되고 5일 후 Windows Server 2012 R2에 대한 필수 및 중요 보안 업데이트를 모두 승인하는 패치 기준선을 생성합니다. 또한 승인된 패치 및 거부된 패치 목록에도 패치가 지정되었습니다. 또한 패치 기준에는 프로덕션 환경용임을 나타내는 태그가 지정되어 있습니다.
------
#### [ Linux & macOS ]
```
aws ssm create-patch-baseline \
--name "Windows-Server-2012R2" \
--tags "Key=Environment,Value=Production" \
--description "Windows Server 2012 R2, Important and Critical security updates" \
--approved-patches "KB2032276,MS10-048" \
--rejected-patches "KB2124261" \
--rejected-patches-action "ALLOW_AS_DEPENDENCY" \
--approval-rules "PatchRules=[{PatchFilterGroup={PatchFilters=[{Key=MSRC_SEVERITY,Values=[Important,Critical]},{Key=CLASSIFICATION,Values=SecurityUpdates},{Key=PRODUCT,Values=WindowsServer2012R2}]},ApproveAfterDays=5}]"
```
------
#### [ Windows Server ]
```
aws ssm create-patch-baseline ^
--name "Windows-Server-2012R2" ^
--tags "Key=Environment,Value=Production" ^
--description "Windows Server 2012 R2, Important and Critical security updates" ^
--approved-patches "KB2032276,MS10-048" ^
--rejected-patches "KB2124261" ^
--rejected-patches-action "ALLOW_AS_DEPENDENCY" ^
--approval-rules "PatchRules=[{PatchFilterGroup={PatchFilters=[{Key=MSRC_SEVERITY,Values=[Important,Critical]},{Key=CLASSIFICATION,Values=SecurityUpdates},{Key=PRODUCT,Values=WindowsServer2012R2}]},ApproveAfterDays=5}]"
```
------
시스템은 다음과 같은 정보를 반환합니다.
```
{
"BaselineId":"pb-0c10e65780EXAMPLE"
}
```
### 다른 OS 버전에 대한 사용자 지정 리포지토리가 있는 패치 기준 생성
Linux 관리형 노드에만 적용됩니다. 다음 명령은 Amazon Linux 운영 체제의 특정 버전에 사용할 패치 리포지토리를 지정하는 방법을 보여줍니다. 이 샘플에서는 Amazon Linux 2017.09에서 기본적으로 활성화되어 있는 소스 리포지토리를 사용하지만, 관리형 노드에 대해 구성한 다른 소스 리포지토리에도 적용할 수 있습니다.
**참고**
이 복잡한 명령을 보다 잘 설명하기 위해 여기서는 `--cli-input-json` 옵션과 외부 JSON 파일에 저장된 추가 옵션을 사용합니다.
1. `my-patch-repository.json`과 같은 이름의 JSON 파일을 만든 후 다음 내용을 파일에 추가합니다.
```
{
"Description": "My patch repository for Amazon Linux 2",
"Name": "Amazon-Linux-2",
"OperatingSystem": "AMAZON_LINUX_2",
"ApprovalRules": {
"PatchRules": [
{
"ApproveAfterDays": 7,
"EnableNonSecurity": true,
"PatchFilterGroup": {
"PatchFilters": [
{
"Key": "SEVERITY",
"Values": [
"Important",
"Critical"
]
},
{
"Key": "CLASSIFICATION",
"Values": [
"Security",
"Bugfix"
]
},
{
"Key": "PRODUCT",
"Values": [
"AmazonLinux2"
]
}
]
}
}
]
},
"Sources": [
{
"Name": "My-AL2",
"Products": [
"AmazonLinux2"
],
"Configuration": "[amzn-main] \nname=amzn-main-Base\nmirrorlist=http://repo./$awsregion./$awsdomain//$releasever/main/mirror.list //nmirrorlist_expire=300//nmetadata_expire=300 \npriority=10 \nfailovermethod=priority \nfastestmirror_enabled=0 \ngpgcheck=1 \ngpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-amazon-ga \nenabled=1 \nretries=3 \ntimeout=5\nreport_instanceid=yes"
}
]
}
```
1. 파일을 저장한 디렉터리에서 다음 명령을 실행합니다.
```
aws ssm create-patch-baseline --cli-input-json file://my-patch-repository.json
```
시스템은 다음과 같은 정보를 반환합니다.
```
{
"BaselineId": "pb-0c10e65780EXAMPLE"
}
```
### 패치 기준선 업데이트
다음 명령은 두 개의 패치를 거부된 것으로 추가하고 하나의 패치를 기존 패치 기준선에 승인된 대로 추가합니다.
승인된 패치 및 거부된 패치 목록의 승인된 형식에 대한 자세한 내용은 [승인 패치 및 거부 패치 목록의 패키지 이름 형식](patch-manager-approved-rejected-package-name-formats.md) 섹션을 참조하세요.
------
#### [ Linux & macOS ]
```
aws ssm update-patch-baseline \
--baseline-id pb-0c10e65780EXAMPLE \
--rejected-patches "KB2032276" "MS10-048" \
--approved-patches "KB2124261"
```
------
#### [ Windows Server ]
```
aws ssm update-patch-baseline ^
--baseline-id pb-0c10e65780EXAMPLE ^
--rejected-patches "KB2032276" "MS10-048" ^
--approved-patches "KB2124261"
```
------
시스템은 다음과 같은 정보를 반환합니다.
```
{
"BaselineId":"pb-0c10e65780EXAMPLE",
"Name":"Windows-Server-2012R2",
"RejectedPatches":[
"KB2032276",
"MS10-048"
],
"GlobalFilters":{
"PatchFilters":[
]
},
"ApprovalRules":{
"PatchRules":[
{
"PatchFilterGroup":{
"PatchFilters":[
{
"Values":[
"Important",
"Critical"
],
"Key":"MSRC_SEVERITY"
},
{
"Values":[
"SecurityUpdates"
],
"Key":"CLASSIFICATION"
},
{
"Values":[
"WindowsServer2012R2"
],
"Key":"PRODUCT"
}
]
},
"ApproveAfterDays":5
}
]
},
"ModifiedDate":1481001494.035,
"CreatedDate":1480997823.81,
"ApprovedPatches":[
"KB2124261"
],
"Description":"Windows Server 2012 R2, Important and Critical security updates"
}
```
### 패치 기준선 이름 변경
------
#### [ Linux & macOS ]
```
aws ssm update-patch-baseline \
--baseline-id pb-0c10e65780EXAMPLE \
--name "Windows-Server-2012-R2-Important-and-Critical-Security-Updates"
```
------
#### [ Windows Server ]
```
aws ssm update-patch-baseline ^
--baseline-id pb-0c10e65780EXAMPLE ^
--name "Windows-Server-2012-R2-Important-and-Critical-Security-Updates"
```
------
시스템은 다음과 같은 정보를 반환합니다.
```
{
"BaselineId":"pb-0c10e65780EXAMPLE",
"Name":"Windows-Server-2012-R2-Important-and-Critical-Security-Updates",
"RejectedPatches":[
"KB2032276",
"MS10-048"
],
"GlobalFilters":{
"PatchFilters":[
]
},
"ApprovalRules":{
"PatchRules":[
{
"PatchFilterGroup":{
"PatchFilters":[
{
"Values":[
"Important",
"Critical"
],
"Key":"MSRC_SEVERITY"
},
{
"Values":[
"SecurityUpdates"
],
"Key":"CLASSIFICATION"
},
{
"Values":[
"WindowsServer2012R2"
],
"Key":"PRODUCT"
}
]
},
"ApproveAfterDays":5
}
]
},
"ModifiedDate":1481001795.287,
"CreatedDate":1480997823.81,
"ApprovedPatches":[
"KB2124261"
],
"Description":"Windows Server 2012 R2, Important and Critical security updates"
}
```
### 패치 기준선 삭제
```
aws ssm delete-patch-baseline --baseline-id "pb-0c10e65780EXAMPLE"
```
시스템은 다음과 같은 정보를 반환합니다.
```
{
"BaselineId":"pb-0c10e65780EXAMPLE"
}
```
### 모든 패치 기준선 나열
```
aws ssm describe-patch-baselines
```
시스템은 다음과 같은 정보를 반환합니다.
```
{
"BaselineIdentities":[
{
"BaselineName":"AWS-DefaultPatchBaseline",
"DefaultBaseline":true,
"BaselineDescription":"Default Patch Baseline Provided by AWS.",
"BaselineId":"arn:aws:ssm:us-east-2:111122223333:patchbaseline/pb-0c10e65780EXAMPLE"
},
{
"BaselineName":"Windows-Server-2012R2",
"DefaultBaseline":false,
"BaselineDescription":"Windows Server 2012 R2, Important and Critical security updates",
"BaselineId":"pb-0c10e65780EXAMPLE"
}
]
}
```
다음은 AWS 리전의 모든 패치 기준을 나열하는 또 다른 명령입니다.
------
#### [ Linux & macOS ]
```
aws ssm describe-patch-baselines \
--region us-east-2 \
--filters "Key=OWNER,Values=[All]"
```
------
#### [ Windows Server ]
```
aws ssm describe-patch-baselines ^
--region us-east-2 ^
--filters "Key=OWNER,Values=[All]"
```
------
시스템은 다음과 같은 정보를 반환합니다.
```
{
"BaselineIdentities":[
{
"BaselineName":"AWS-DefaultPatchBaseline",
"DefaultBaseline":true,
"BaselineDescription":"Default Patch Baseline Provided by AWS.",
"BaselineId":"arn:aws:ssm:us-east-2:111122223333:patchbaseline/pb-0c10e65780EXAMPLE"
},
{
"BaselineName":"Windows-Server-2012R2",
"DefaultBaseline":false,
"BaselineDescription":"Windows Server 2012 R2, Important and Critical security updates",
"BaselineId":"pb-0c10e65780EXAMPLE"
}
]
}
```
### AWS가 제공하는 모든 패치 기준 나열
------
#### [ Linux & macOS ]
```
aws ssm describe-patch-baselines \
--region us-east-2 \
--filters "Key=OWNER,Values=[AWS]"
```
------
#### [ Windows Server ]
```
aws ssm describe-patch-baselines ^
--region us-east-2 ^
--filters "Key=OWNER,Values=[AWS]"
```
------
시스템은 다음과 같은 정보를 반환합니다.
```
{
"BaselineIdentities":[
{
"BaselineName":"AWS-DefaultPatchBaseline",
"DefaultBaseline":true,
"BaselineDescription":"Default Patch Baseline Provided by AWS.",
"BaselineId":"arn:aws:ssm:us-east-2:111122223333:patchbaseline/pb-0c10e65780EXAMPLE"
}
]
}
```
### 사용자의 패치 기준선 나열
------
#### [ Linux & macOS ]
```
aws ssm describe-patch-baselines \
--region us-east-2 \
--filters "Key=OWNER,Values=[Self]"
```
------
#### [ Windows Server ]
```
aws ssm describe-patch-baselines ^
--region us-east-2 ^
--filters "Key=OWNER,Values=[Self]"
```
------
시스템은 다음과 같은 정보를 반환합니다.
```
{
"BaselineIdentities":[
{
"BaselineName":"Windows-Server-2012R2",
"DefaultBaseline":false,
"BaselineDescription":"Windows Server 2012 R2, Important and Critical security updates",
"BaselineId":"pb-0c10e65780EXAMPLE"
}
]
}
```
### 패치 기준선 표시
```
aws ssm get-patch-baseline --baseline-id pb-0c10e65780EXAMPLE
```
**참고**
사용자 정의 패치 기준의 경우 패치 기준 ID 또는 전체 Amazon 리소스 이름(ARN)을 지정할 수 있습니다. AWS에서 제공한 패치 기준의 경우 전체 ARN을 지정해야 합니다. 예를 들어 `arn:aws:ssm:us-east-2:075727635805:patchbaseline/pb-0c10e65780EXAMPLE`입니다.
시스템은 다음과 같은 정보를 반환합니다.
```
{
"BaselineId":"pb-0c10e65780EXAMPLE",
"Name":"Windows-Server-2012R2",
"PatchGroups":[
"Web Servers"
],
"RejectedPatches":[
],
"GlobalFilters":{
"PatchFilters":[
]
},
"ApprovalRules":{
"PatchRules":[
{
"PatchFilterGroup":{
"PatchFilters":[
{
"Values":[
"Important",
"Critical"
],
"Key":"MSRC_SEVERITY"
},
{
"Values":[
"SecurityUpdates"
],
"Key":"CLASSIFICATION"
},
{
"Values":[
"WindowsServer2012R2"
],
"Key":"PRODUCT"
}
]
},
"ApproveAfterDays":5
}
]
},
"ModifiedDate":1480997823.81,
"CreatedDate":1480997823.81,
"ApprovedPatches":[
],
"Description":"Windows Server 2012 R2, Important and Critical security updates"
}
```
### 기본 패치 기준선 받기
```
aws ssm get-default-patch-baseline --region us-east-2
```
시스템은 다음과 같은 정보를 반환합니다.
```
{
"BaselineId":"arn:aws:ssm:us-east-2:111122223333:patchbaseline/pb-0c10e65780EXAMPLE"
}
```
### 사용자 지정 패치 기준을 기본값으로 설정
------
#### [ Linux & macOS ]
```
aws ssm register-default-patch-baseline \
--region us-east-2 \
--baseline-id "pb-0c10e65780EXAMPLE"
```
------
#### [ Windows Server ]
```
aws ssm register-default-patch-baseline ^
--region us-east-2 ^
--baseline-id "pb-0c10e65780EXAMPLE"
```
------
시스템은 다음과 같은 정보를 반환합니다.
```
{
"BaselineId":"pb-0c10e65780EXAMPLE"
}
```
### AWS 패치 기준을 기본값으로 재설정
------
#### [ Linux & macOS ]
```
aws ssm register-default-patch-baseline \
--region us-east-2 \
--baseline-id "arn:aws:ssm:us-east-2:123456789012:patchbaseline/pb-0c10e65780EXAMPLE"
```
------
#### [ Windows Server ]
```
aws ssm register-default-patch-baseline ^
--region us-east-2 ^
--baseline-id "arn:aws:ssm:us-east-2:123456789012:patchbaseline/pb-0c10e65780EXAMPLE"
```
------
시스템은 다음과 같은 정보를 반환합니다.
```
{
"BaselineId":"pb-0c10e65780EXAMPLE"
}
```
### 패치 기준선 태그 지정
------
#### [ Linux & macOS ]
```
aws ssm add-tags-to-resource \
--resource-type "PatchBaseline" \
--resource-id "pb-0c10e65780EXAMPLE" \
--tags "Key=Project,Value=Testing"
```
------
#### [ Windows Server ]
```
aws ssm add-tags-to-resource ^
--resource-type "PatchBaseline" ^
--resource-id "pb-0c10e65780EXAMPLE" ^
--tags "Key=Project,Value=Testing"
```
------
### 패치 기준선에 대한 태그 나열
------
#### [ Linux & macOS ]
```
aws ssm list-tags-for-resource \
--resource-type "PatchBaseline" \
--resource-id "pb-0c10e65780EXAMPLE"
```
------
#### [ Windows Server ]
```
aws ssm list-tags-for-resource ^
--resource-type "PatchBaseline" ^
--resource-id "pb-0c10e65780EXAMPLE"
```
------
### 패치 기준선에서 태그 삭제
------
#### [ Linux & macOS ]
```
aws ssm remove-tags-from-resource \
--resource-type "PatchBaseline" \
--resource-id "pb-0c10e65780EXAMPLE" \
--tag-keys "Project"
```
------
#### [ Windows Server ]
```
aws ssm remove-tags-from-resource ^
--resource-type "PatchBaseline" ^
--resource-id "pb-0c10e65780EXAMPLE" ^
--tag-keys "Project"
```
------
## 패치 그룹을 위한 AWS CLI 명령
**Topics**
+ [패치 그룹 생성](#patch-manager-cli-commands-create-patch-group)
+ [패치 그룹 ‘웹 서버’를 패치 기준선에 등록](#patch-manager-cli-commands-register-patch-baseline-for-patch-group-web-servers)
+ [패치 그룹 'Backend'를 AWS가 제공하는 패치 기준에 등록](#patch-manager-cli-commands-register-patch-baseline-for-patch-group-backend)
+ [패치 그룹 등록 표시](#patch-manager-cli-commands-describe-patch-groups)
+ [패치 기준선에서 패치 그룹 등록 취소](#patch-manager-cli-commands-deregister-patch-baseline-for-patch-group)
### 패치 그룹 생성
**참고**
패치 그룹은 *패치 정책*을 기반으로 하는 패치 적용 작업에 사용되지 않습니다. 패치 정책 작업에 대한 자세한 내용은 [Quick Setup의 패치 정책 구성](patch-manager-policies.md) 섹션을 참조하세요.
패치 작업을 쉽게 구성하려면 태그를 사용하여 관리형 노드를 패치 그룹에 추가하는 것이 좋습니다. 패치 그룹은 태그 키 `Patch Group` 또는 `PatchGroup`을 사용해야 합니다. [EC2 인스턴스 메타데이터에 태그를 허용](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html#allow-access-to-tags-in-IMDS)한 경우 `PatchGroup`(공백 없음)을 사용해야 합니다. 값을 지정하는 데는 제한이 없지만 태그 키는 `Patch Group` 또는 `PatchGroup`이어야 합니다. 패치 그룹에 대한 자세한 내용은 [패치 그룹](patch-manager-patch-groups.md) 섹션을 참조하세요.
태그를 사용하여 관리형 노드를 그룹화한 후에 패치 기준에 패치 그룹 값을 추가해야 합니다. 패치 그룹을 패치 기준선에 등록하여 패치 적용 작업 중 올바른 패치가 설치되는지 확인할 수 있습니다.
#### 태스크 1: 태그를 사용하여 패치 그룹에 EC2 인스턴스 추가
**참고**
Amazon Elastic Compute Cloud(Amazon EC2) 콘솔과 AWS CLI를 사용하는 경우 Systems Manager에 사용하도록 아직 구성되지 않은 인스턴스에 `Key = Patch Group` 또는 `Key = PatchGroup` 태그를 적용할 수 있습니다. `Patch Group` 또는 `Key = PatchGroup` 태그 적용 후 Patch Manager에서 예상되는 EC2 인스턴스가 목록에 없으면 [관리형 노드 가용성 문제 해결](fleet-manager-troubleshooting-managed-nodes.md)에서 문제 해결 팁을 확인하세요.
다음 명령을 실행해 EC2 인스턴스에 `PatchGroup` 태그를 추가합니다.
```
aws ec2 create-tags --resources "i-1234567890abcdef0" --tags "Key=PatchGroup,Value=GroupValue"
```
#### 태스크 2: 태그를 사용하여 패치 그룹에 관리형 인스턴스 추가
다음 명령을 실행해 관리형 노드에 `PatchGroup` 태그를 추가합니다.
------
#### [ Linux & macOS ]
```
aws ssm add-tags-to-resource \
--resource-type "ManagedInstance" \
--resource-id "mi-0123456789abcdefg" \
--tags "Key=PatchGroup,Value=GroupValue"
```
------
#### [ Windows Server ]
```
aws ssm add-tags-to-resource ^
--resource-type "ManagedInstance" ^
--resource-id "mi-0123456789abcdefg" ^
--tags "Key=PatchGroup,Value=GroupValue"
```
------
#### 작업 3: 패치 기준에 패치 그룹 추가
다음 명령을 실행하여 `PatchGroup` 태그 값을 지정된 패치 기준에 연결하십시오.
------
#### [ Linux & macOS ]
```
aws ssm register-patch-baseline-for-patch-group \
--baseline-id "pb-0c10e65780EXAMPLE" \
--patch-group "Development"
```
------
#### [ Windows Server ]
```
aws ssm register-patch-baseline-for-patch-group ^
--baseline-id "pb-0c10e65780EXAMPLE" ^
--patch-group "Development"
```
------
시스템은 다음과 같은 정보를 반환합니다.
```
{
"PatchGroup": "Development",
"BaselineId": "pb-0c10e65780EXAMPLE"
}
```
### 패치 그룹 ‘웹 서버’를 패치 기준선에 등록
------
#### [ Linux & macOS ]
```
aws ssm register-patch-baseline-for-patch-group \
--baseline-id "pb-0c10e65780EXAMPLE" \
--patch-group "Web Servers"
```
------
#### [ Windows Server ]
```
aws ssm register-patch-baseline-for-patch-group ^
--baseline-id "pb-0c10e65780EXAMPLE" ^
--patch-group "Web Servers"
```
------
시스템은 다음과 같은 정보를 반환합니다.
```
{
"PatchGroup":"Web Servers",
"BaselineId":"pb-0c10e65780EXAMPLE"
}
```
### 패치 그룹 'Backend'를 AWS가 제공하는 패치 기준에 등록
------
#### [ Linux & macOS ]
```
aws ssm register-patch-baseline-for-patch-group \
--region us-east-2 \
--baseline-id "arn:aws:ssm:us-east-2:111122223333:patchbaseline/pb-0c10e65780EXAMPLE" \
--patch-group "Backend"
```
------
#### [ Windows Server ]
```
aws ssm register-patch-baseline-for-patch-group ^
--region us-east-2 ^
--baseline-id "arn:aws:ssm:us-east-2:111122223333:patchbaseline/pb-0c10e65780EXAMPLE" ^
--patch-group "Backend"
```
------
시스템은 다음과 같은 정보를 반환합니다.
```
{
"PatchGroup":"Backend",
"BaselineId":"arn:aws:ssm:us-east-2:111122223333:patchbaseline/pb-0c10e65780EXAMPLE"
}
```
### 패치 그룹 등록 표시
```
aws ssm describe-patch-groups --region us-east-2
```
시스템은 다음과 같은 정보를 반환합니다.
```
{
"PatchGroupPatchBaselineMappings":[
{
"PatchGroup":"Backend",
"BaselineIdentity":{
"BaselineName":"AWS-DefaultPatchBaseline",
"DefaultBaseline":false,
"BaselineDescription":"Default Patch Baseline Provided by AWS.",
"BaselineId":"arn:aws:ssm:us-east-2:111122223333:patchbaseline/pb-0c10e65780EXAMPLE"
}
},
{
"PatchGroup":"Web Servers",
"BaselineIdentity":{
"BaselineName":"Windows-Server-2012R2",
"DefaultBaseline":true,
"BaselineDescription":"Windows Server 2012 R2, Important and Critical updates",
"BaselineId":"pb-0c10e65780EXAMPLE"
}
}
]
}
```
### 패치 기준선에서 패치 그룹 등록 취소
------
#### [ Linux & macOS ]
```
aws ssm deregister-patch-baseline-for-patch-group \
--region us-east-2 \
--patch-group "Production" \
--baseline-id "arn:aws:ssm:us-east-2:111122223333:patchbaseline/pb-0c10e65780EXAMPLE"
```
------
#### [ Windows Server ]
```
aws ssm deregister-patch-baseline-for-patch-group ^
--region us-east-2 ^
--patch-group "Production" ^
--baseline-id "arn:aws:ssm:us-east-2:111122223333:patchbaseline/pb-0c10e65780EXAMPLE"
```
------
시스템은 다음과 같은 정보를 반환합니다.
```
{
"PatchGroup":"Production",
"BaselineId":"arn:aws:ssm:us-east-2:111122223333:patchbaseline/pb-0c10e65780EXAMPLE"
}
```
## 패치 요약 및 세부 정보 보기를 위한 AWS CLI 명령
**Topics**
+ [패치 기준선이 정의한 모든 패치 받기](#patch-manager-cli-commands-describe-effective-patches-for-patch-baseline)
+ [분류 `SECURITY` 및 심각도 `Critical`의 AmazonLinux2018.03에 대한 모든 패치 가져오기](#patch-manager-cli-commands-describe-available-patches-linux)
+ [MSRC 심각도가 `Critical`인 Windows Server 2012에 대한 모든 패치 가져오기](#patch-manager-cli-commands-describe-available-patches)
+ [사용 가능한 모든 패치 받기](#patch-manager-cli-commands-describe-available-patches)
+ [관리형 노드별 패치 요약 상태 받기](#patch-manager-cli-commands-describe-instance-patch-states)
+ [관리형 노드에 대한 패치 규정 준수 세부 정보 받기](#patch-manager-cli-commands-describe-instance-patches)
+ [패치 규정 준수 결과 보기(AWS CLI)](#viewing-patch-compliance-results-cli)
### 패치 기준선이 정의한 모든 패치 받기
**참고**
이 명령은 Windows Server 패치 기준에만 지원됩니다.
------
#### [ Linux & macOS ]
```
aws ssm describe-effective-patches-for-patch-baseline \
--region us-east-2 \
--baseline-id "pb-0c10e65780EXAMPLE"
```
------
#### [ Windows Server ]
```
aws ssm describe-effective-patches-for-patch-baseline ^
--region us-east-2 ^
--baseline-id "pb-0c10e65780EXAMPLE"
```
------
시스템은 다음과 같은 정보를 반환합니다.
```
{
"NextToken":"--token string truncated--",
"EffectivePatches":[
{
"PatchStatus":{
"ApprovalDate":1384711200.0,
"DeploymentStatus":"APPROVED"
},
"Patch":{
"ContentUrl":"https://support.microsoft.com/en-us/kb/2876331",
"ProductFamily":"Windows",
"Product":"WindowsServer2012R2",
"Vendor":"Microsoft",
"Description":"A security issue has been identified in a Microsoft software
product that could affect your system. You can help protect your system
by installing this update from Microsoft. For a complete listing of the
issues that are included in this update, see the associated Microsoft
Knowledge Base article. After you install this update, you may have to
restart your system.",
"Classification":"SecurityUpdates",
"Title":"Security Update for Windows Server 2012 R2 Preview (KB2876331)",
"ReleaseDate":1384279200.0,
"MsrcClassification":"Critical",
"Language":"All",
"KbNumber":"KB2876331",
"MsrcNumber":"MS13-089",
"Id":"e74ccc76-85f0-4881-a738-59e9fc9a336d"
}
},
{
"PatchStatus":{
"ApprovalDate":1428858000.0,
"DeploymentStatus":"APPROVED"
},
"Patch":{
"ContentUrl":"https://support.microsoft.com/en-us/kb/2919355",
"ProductFamily":"Windows",
"Product":"WindowsServer2012R2",
"Vendor":"Microsoft",
"Description":"Windows Server 2012 R2 Update is a cumulative
set of security updates, critical updates and updates. You
must install Windows Server 2012 R2 Update to ensure that
your computer can continue to receive future Windows Updates,
including security updates. For a complete listing of the
issues that are included in this update, see the associated
Microsoft Knowledge Base article for more information. After
you install this item, you may have to restart your computer.",
"Classification":"SecurityUpdates",
"Title":"Windows Server 2012 R2 Update (KB2919355)",
"ReleaseDate":1428426000.0,
"MsrcClassification":"Critical",
"Language":"All",
"KbNumber":"KB2919355",
"MsrcNumber":"MS14-018",
"Id":"8452bac0-bf53-4fbd-915d-499de08c338b"
}
}
---output truncated---
```
### 분류 `SECURITY` 및 심각도 `Critical`의 AmazonLinux2018.03에 대한 모든 패치 가져오기
------
#### [ Linux & macOS ]
```
aws ssm describe-available-patches \
--region us-east-2 \
--filters Key=PRODUCT,Values=AmazonLinux2018.03 Key=SEVERITY,Values=Critical
```
------
#### [ Windows Server ]
```
aws ssm describe-available-patches ^
--region us-east-2 ^
--filters Key=PRODUCT,Values=AmazonLinux2018.03 Key=SEVERITY,Values=Critical
```
------
시스템은 다음과 같은 정보를 반환합니다.
```
{
"Patches": [
{
"AdvisoryIds": ["ALAS-2011-1"],
"BugzillaIds": [ "1234567" ],
"Classification": "SECURITY",
"CVEIds": [ "CVE-2011-3192"],
"Name": "zziplib",
"Epoch": "0",
"Version": "2.71",
"Release": "1.3.amzn1",
"Arch": "i686",
"Product": "AmazonLinux2018.03",
"ReleaseDate": 1590519815,
"Severity": "CRITICAL"
}
]
}
---output truncated---
```
### MSRC 심각도가 `Critical`인 Windows Server 2012에 대한 모든 패치 가져오기
------
#### [ Linux & macOS ]
```
aws ssm describe-available-patches \
--region us-east-2 \
--filters Key=PRODUCT,Values=WindowsServer2012 Key=MSRC_SEVERITY,Values=Critical
```
------
#### [ Windows Server ]
```
aws ssm describe-available-patches ^
--region us-east-2 ^
--filters Key=PRODUCT,Values=WindowsServer2012 Key=MSRC_SEVERITY,Values=Critical
```
------
시스템은 다음과 같은 정보를 반환합니다.
```
{
"Patches":[
{
"ContentUrl":"https://support.microsoft.com/en-us/kb/2727528",
"ProductFamily":"Windows",
"Product":"WindowsServer2012",
"Vendor":"Microsoft",
"Description":"A security issue has been identified that could
allow an unauthenticated remote attacker to compromise your
system and gain control over it. You can help protect your
system by installing this update from Microsoft. After you
install this update, you may have to restart your system.",
"Classification":"SecurityUpdates",
"Title":"Security Update for Windows Server 2012 (KB2727528)",
"ReleaseDate":1352829600.0,
"MsrcClassification":"Critical",
"Language":"All",
"KbNumber":"KB2727528",
"MsrcNumber":"MS12-072",
"Id":"1eb507be-2040-4eeb-803d-abc55700b715"
},
{
"ContentUrl":"https://support.microsoft.com/en-us/kb/2729462",
"ProductFamily":"Windows",
"Product":"WindowsServer2012",
"Vendor":"Microsoft",
"Description":"A security issue has been identified that could
allow an unauthenticated remote attacker to compromise your
system and gain control over it. You can help protect your
system by installing this update from Microsoft. After you
install this update, you may have to restart your system.",
"Classification":"SecurityUpdates",
"Title":"Security Update for Microsoft .NET Framework 3.5 on
Windows 8 and Windows Server 2012 for x64-based Systems (KB2729462)",
"ReleaseDate":1352829600.0,
"MsrcClassification":"Critical",
"Language":"All",
"KbNumber":"KB2729462",
"MsrcNumber":"MS12-074",
"Id":"af873760-c97c-4088-ab7e-5219e120eab4"
}
---output truncated---
```
### 사용 가능한 모든 패치 받기
```
aws ssm describe-available-patches --region us-east-2
```
시스템은 다음과 같은 정보를 반환합니다.
```
{
"NextToken":"--token string truncated--",
"Patches":[
{
"Classification": "SecurityUpdates",
"ContentUrl": "https://support.microsoft.com/en-us/kb/4074588",
"Description": "A security issue has been identified in a Microsoft software
product that could affect your system. You can help protect your system by
installing this update from Microsoft. For a complete listing of the issues
that are included in this update, see the associated Microsoft Knowledge Base
article. After you install this update, you may have to restart your system.",
"Id": "11adea10-0701-430e-954f-9471595ae246",
"KbNumber": "KB4074588",
"Language": "All",
"MsrcNumber": "",
"MsrcSeverity": "Critical",
"Product": "WindowsServer2016",
"ProductFamily": "Windows",
"ReleaseDate": 1518548400,
"Title": "2018-02 Cumulative Update for Windows Server 2016 (1709) for x64-based
Systems (KB4074588)",
"Vendor": "Microsoft"
},
{
"Classification": "SecurityUpdates",
"ContentUrl": "https://support.microsoft.com/en-us/kb/4074590",
"Description": "A security issue has been identified in a Microsoft software
product that could affect your system. You can help protect your system by
installing this update from Microsoft. For a complete listing of the issues that are included in this update, see the associated Microsoft Knowledge Base article. After you install this update, you may have to restart your system.",
"Id": "f5f58231-ac5d-4640-ab1b-9dc8d857c265",
"KbNumber": "KB4074590",
"Language": "All",
"MsrcNumber": "",
"MsrcSeverity": "Critical",
"Product": "WindowsServer2016",
"ProductFamily": "Windows",
"ReleaseDate": 1518544805,
"Title": "2018-02 Cumulative Update for Windows Server 2016 for x64-based
Systems (KB4074590)",
"Vendor": "Microsoft"
}
---output truncated---
```
### 관리형 노드별 패치 요약 상태 받기
관리형 노드별 요약은 패치 그룹에 대해 다음 'NotApplicable', 'Missing', 'Failed', 'InstalledOther', 'Installed' 상태에 있는 패치의 수를 알려 줍니다.
------
#### [ Linux & macOS ]
```
aws ssm describe-instance-patch-states \
--instance-ids i-08ee91c0b17045407 i-09a618aec652973a9
```
------
#### [ Windows Server ]
```
aws ssm describe-instance-patch-states ^
--instance-ids i-08ee91c0b17045407 i-09a618aec652973a9
```
------
시스템은 다음과 같은 정보를 반환합니다.
```
{
"InstancePatchStates":[
{
"InstanceId": "i-08ee91c0b17045407",
"PatchGroup": "",
"BaselineId": "pb-0c10e65780EXAMPLE",
"SnapshotId": "6d03d6c5-f79d-41d0-8d0e-00a9aEXAMPLE",
"InstalledCount": 50,
"InstalledOtherCount": 353,
"InstalledPendingRebootCount": 0,
"InstalledRejectedCount": 0,
"MissingCount": 0,
"FailedCount": 0,
"UnreportedNotApplicableCount": -1,
"NotApplicableCount": 671,
"OperationStartTime": "2020-01-24T12:37:56-08:00",
"OperationEndTime": "2020-01-24T12:37:59-08:00",
"Operation": "Scan",
"RebootOption": "NoReboot"
},
{
"InstanceId": "i-09a618aec652973a9",
"PatchGroup": "",
"BaselineId": "pb-0c10e65780EXAMPLE",
"SnapshotId": "c7e0441b-1eae-411b-8aa7-973e6EXAMPLE",
"InstalledCount": 36,
"InstalledOtherCount": 396,
"InstalledPendingRebootCount": 0,
"InstalledRejectedCount": 0,
"MissingCount": 3,
"FailedCount": 0,
"UnreportedNotApplicableCount": -1,
"NotApplicableCount": 420,
"OperationStartTime": "2020-01-24T12:37:34-08:00",
"OperationEndTime": "2020-01-24T12:37:37-08:00",
"Operation": "Scan",
"RebootOption": "NoReboot"
}
---output truncated---
```
### 관리형 노드에 대한 패치 규정 준수 세부 정보 받기
```
aws ssm describe-instance-patches --instance-id i-08ee91c0b17045407
```
시스템은 다음과 같은 정보를 반환합니다.
```
{
"NextToken":"--token string truncated--",
"Patches":[
{
"Title": "bind-libs.x86_64:32:9.8.2-0.68.rc1.60.amzn1",
"KBId": "bind-libs.x86_64",
"Classification": "Security",
"Severity": "Important",
"State": "Installed",
"InstalledTime": "2019-08-26T11:05:24-07:00"
},
{
"Title": "bind-utils.x86_64:32:9.8.2-0.68.rc1.60.amzn1",
"KBId": "bind-utils.x86_64",
"Classification": "Security",
"Severity": "Important",
"State": "Installed",
"InstalledTime": "2019-08-26T11:05:32-07:00"
},
{
"Title": "dhclient.x86_64:12:4.1.1-53.P1.28.amzn1",
"KBId": "dhclient.x86_64",
"Classification": "Security",
"Severity": "Important",
"State": "Installed",
"InstalledTime": "2019-08-26T11:05:31-07:00"
},
---output truncated---
```
### 패치 규정 준수 결과 보기(AWS CLI)
**단일 관리형 노드에 대한 패치 규정 준수 결과 확인**
단일 관리형 노드에 대한 패치 규정 준수 결과를 보려면 AWS Command Line Interface(AWS CLI)에서 다음 명령을 실행합니다.
```
aws ssm describe-instance-patch-states --instance-id instance-id
```
*instance-id*를 `i-02573cafcfEXAMPLE` 또는 `mi-0282f7c436EXAMPLE` 형식으로 결과를 보려는 관리형 노드의 ID로 바꿉니다.
시스템은 다음과 같은 정보를 반환합니다.
```
{
"InstancePatchStates": [
{
"InstanceId": "i-02573cafcfEXAMPLE",
"PatchGroup": "mypatchgroup",
"BaselineId": "pb-0c10e65780EXAMPLE",
"SnapshotId": "a3f5ff34-9bc4-4d2c-a665-4d1c1EXAMPLE",
"CriticalNonCompliantCount": 2,
"SecurityNonCompliantCount": 2,
"OtherNonCompliantCount": 1,
"InstalledCount": 123,
"InstalledOtherCount": 334,
"InstalledPendingRebootCount": 0,
"InstalledRejectedCount": 0,
"MissingCount": 1,
"FailedCount": 2,
"UnreportedNotApplicableCount": 11,
"NotApplicableCount": 2063,
"OperationStartTime": "2021-05-03T11:00:56-07:00",
"OperationEndTime": "2021-05-03T11:01:09-07:00",
"Operation": "Scan",
"LastNoRebootInstallOperationTime": "2020-06-14T12:17:41-07:00",
"RebootOption": "RebootIfNeeded"
}
]
}
```
**리전의 모든 EC2 인스턴스에 대한 패치 수 요약 확인**
`describe-instance-patch-states`는 한 번에 하나의 관리형 인스턴스에 대한 결과 검색만 지원합니다. 그러나 `describe-instance-patch-states` 명령에 사용자 정의 스크립트를 사용하면 보다 세부적인 보고서를 생성할 수 있습니다.
예를 들어 [jq 필터 도구](https://stedolan.github.io/jq/download/)가 로컬 시스템에 설치된 경우 다음 명령을 실행하여 특정 AWS 리전의 어느 EC2 인스턴스가 `InstalledPendingReboot` 상태인지 식별할 수 있습니다.
```
aws ssm describe-instance-patch-states \
--instance-ids $(aws ec2 describe-instances --region region | jq '.Reservations[].Instances[] | .InstanceId' | tr '\n|"' ' ') \
--output text --query 'InstancePatchStates[*].{Instance:InstanceId, InstalledPendingRebootCount:InstalledPendingRebootCount}'
```
*리전*은 미국 동부(오하이오) 리전의 `us-east-2` 같이 AWS Systems Manager이 지원하는 AWS 리전의 식별자를 나타냅니다. 지원되는 *리전* 값 목록은 **Amazon Web Services 일반 참조의 [Systems Manager 서비스 엔드포인트](https://docs.aws.amazon.com/general/latest/gr/ssm.html#ssm_region)에 있는 **리전** 열을 참조하세요.
예제:
```
aws ssm describe-instance-patch-states \
--instance-ids $(aws ec2 describe-instances --region us-east-2 | jq '.Reservations[].Instances[] | .InstanceId' | tr '\n|"' ' ') \
--output text --query 'InstancePatchStates[*].{Instance:InstanceId, InstalledPendingRebootCount:InstalledPendingRebootCount}'
```
시스템은 다음과 같은 정보를 반환합니다.
```
1 i-02573cafcfEXAMPLE
0 i-0471e04240EXAMPLE
3 i-07782c72faEXAMPLE
6 i-083b678d37EXAMPLE
0 i-03a530a2d4EXAMPLE
1 i-01f68df0d0EXAMPLE
0 i-0a39c0f214EXAMPLE
7 i-0903a5101eEXAMPLE
7 i-03823c2fedEXAMPLE
```
`InstalledPendingRebootCount` 외에도 검색할 수 있는 카운트 유형 목록은 다음과 같습니다.
+ `CriticalNonCompliantCount`
+ `SecurityNonCompliantCount`
+ `OtherNonCompliantCount`
+ `UnreportedNotApplicableCount `
+ `InstalledPendingRebootCount`
+ `FailedCount`
+ `NotApplicableCount`
+ `InstalledRejectedCount`
+ `InstalledOtherCount`
+ `MissingCount`
+ `InstalledCount`
## 관리형 노드 스캔 및 패치를 위한 AWS CLI 명령
다음 명령을 실행하여 패치 규정 준수 여부를 검사하거나 패치를 설치한 후 [패치 요약 및 세부 정보 보기를 위한 AWS CLI 명령](#patch-details-cli-commands) 섹션의 명령을 사용하여 패치 상태 및 규정 준수에 대한 정보를 볼 수 있습니다.
**Topics**
+ [패치 규정 준수를 위해 관리형 노드 스캔(AWS CLI)](#patch-operations-scan)
+ [관리형 노드에 패치 설치(AWS CLI)](#patch-operations-install-cli)
### 패치 규정 준수를 위해 관리형 노드 스캔(AWS CLI)
**패치 규정 준수를 위해 특정 관리형 노드 스캔**
다음 명령을 실행합니다.
------
#### [ Linux & macOS ]
```
aws ssm send-command \
--document-name 'AWS-RunPatchBaseline' \
--targets Key=InstanceIds,Values='i-02573cafcfEXAMPLE,i-0471e04240EXAMPLE' \
--parameters 'Operation=Scan' \
--timeout-seconds 600
```
------
#### [ Windows Server ]
```
aws ssm send-command ^
--document-name "AWS-RunPatchBaseline" ^
--targets Key=InstanceIds,Values="i-02573cafcfEXAMPLE,i-0471e04240EXAMPLE" ^
--parameters "Operation=Scan" ^
--timeout-seconds 600
```
------
시스템은 다음과 같은 정보를 반환합니다.
```
{
"Command": {
"CommandId": "a04ed06c-8545-40f4-87c2-a0babEXAMPLE",
"DocumentName": "AWS-RunPatchBaseline",
"DocumentVersion": "$DEFAULT",
"Comment": "",
"ExpiresAfter": 1621974475.267,
"Parameters": {
"Operation": [
"Scan"
]
},
"InstanceIds": [],
"Targets": [
{
"Key": "InstanceIds",
"Values": [
"i-02573cafcfEXAMPLE,
i-0471e04240EXAMPLE"
]
}
],
"RequestedDateTime": 1621952275.267,
"Status": "Pending",
"StatusDetails": "Pending",
"TimeoutSeconds": 600,
---output truncated---
}
}
```
**패치 그룹 태그로 관리형 노드에서 패치 규정 준수 여부 스캔**
다음 명령을 실행합니다.
------
#### [ Linux & macOS ]
```
aws ssm send-command \
--document-name 'AWS-RunPatchBaseline' \
--targets Key='tag:PatchGroup',Values='Web servers' \
--parameters 'Operation=Scan' \
--timeout-seconds 600
```
------
#### [ Windows Server ]
```
aws ssm send-command ^
--document-name "AWS-RunPatchBaseline" ^
--targets Key="tag:PatchGroup",Values="Web servers" ^
--parameters "Operation=Scan" ^
--timeout-seconds 600
```
------
시스템은 다음과 같은 정보를 반환합니다.
```
{
"Command": {
"CommandId": "87a448ee-8adc-44e0-b4d1-6b429EXAMPLE",
"DocumentName": "AWS-RunPatchBaseline",
"DocumentVersion": "$DEFAULT",
"Comment": "",
"ExpiresAfter": 1621974983.128,
"Parameters": {
"Operation": [
"Scan"
]
},
"InstanceIds": [],
"Targets": [
{
"Key": "tag:PatchGroup",
"Values": [
"Web servers"
]
}
],
"RequestedDateTime": 1621952783.128,
"Status": "Pending",
"StatusDetails": "Pending",
"TimeoutSeconds": 600,
---output truncated---
}
}
```
### 관리형 노드에 패치 설치(AWS CLI)
**특정 관리형 노드에 패치 설치**
다음 명령을 실행합니다.
**참고**
패치 설치를 완료하기 위해 필요에 따라 대상 관리형 노드가 재부팅됩니다. 자세한 내용은 [패치를 위한 SSM 명령 문서: `AWS-RunPatchBaseline`](patch-manager-aws-runpatchbaseline.md) 섹션을 참조하세요.
------
#### [ Linux & macOS ]
```
aws ssm send-command \
--document-name 'AWS-RunPatchBaseline' \
--targets Key=InstanceIds,Values='i-02573cafcfEXAMPLE,i-0471e04240EXAMPLE' \
--parameters 'Operation=Install' \
--timeout-seconds 600
```
------
#### [ Windows Server ]
```
aws ssm send-command ^
--document-name "AWS-RunPatchBaseline" ^
--targets Key=InstanceIds,Values="i-02573cafcfEXAMPLE,i-0471e04240EXAMPLE" ^
--parameters "Operation=Install" ^
--timeout-seconds 600
```
------
시스템은 다음과 같은 정보를 반환합니다.
```
{
"Command": {
"CommandId": "5f403234-38c4-439f-a570-93623EXAMPLE",
"DocumentName": "AWS-RunPatchBaseline",
"DocumentVersion": "$DEFAULT",
"Comment": "",
"ExpiresAfter": 1621975301.791,
"Parameters": {
"Operation": [
"Install"
]
},
"InstanceIds": [],
"Targets": [
{
"Key": "InstanceIds",
"Values": [
"i-02573cafcfEXAMPLE,
i-0471e04240EXAMPLE"
]
}
],
"RequestedDateTime": 1621953101.791,
"Status": "Pending",
"StatusDetails": "Pending",
"TimeoutSeconds": 600,
---output truncated---
}
}
```
**특정 패치 그룹의 관리형 노드에 패치 설치**
다음 명령을 실행합니다.
------
#### [ Linux & macOS ]
```
aws ssm send-command \
--document-name 'AWS-RunPatchBaseline' \
--targets Key='tag:PatchGroup',Values='Web servers' \
-parameters 'Operation=Install' \
--timeout-seconds 600
```
------
#### [ Windows Server ]
```
aws ssm send-command ^
--document-name "AWS-RunPatchBaseline" ^
--targets Key="tag:PatchGroup",Values="Web servers" ^
--parameters "Operation=Install" ^
--timeout-seconds 600
```
------
시스템은 다음과 같은 정보를 반환합니다.
```
{
"Command": {
"CommandId": "fa44b086-7d36-4ad5-ac8d-627ecEXAMPLE",
"DocumentName": "AWS-RunPatchBaseline",
"DocumentVersion": "$DEFAULT",
"Comment": "",
"ExpiresAfter": 1621975407.865,
"Parameters": {
"Operation": [
"Install"
]
},
"InstanceIds": [],
"Targets": [
{
"Key": "tag:PatchGroup",
"Values": [
"Web servers"
]
}
],
"RequestedDateTime": 1621953207.865,
"Status": "Pending",
"StatusDetails": "Pending",
"TimeoutSeconds": 600,
---output truncated---
}
}
```
# 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) 섹션을 참조하세요.
# Patch Manager 문제 해결
다음 정보를 사용하면 AWS Systems Manager의 도구인 Patch Manager 관련 문제를 해결하는 데 도움이 됩니다.
**Topics**
+ [문제: `baseline_overrides.json`에 대한 "Invoke-PatchBaselineOperation: 액세스 거부됨" 오류 또는 "S3에서 파일을 다운로드할 수 없음" 오류](#patch-manager-troubleshooting-patch-policy-baseline-overrides)
+ [문제: 명백한 원인 또는 오류 메시지 없이 패치 적용 실패](#race-condition-conflict)
+ [문제: 예기치 않은 패치 규정 준수 결과](#patch-manager-troubleshooting-compliance)
+ [Linux에서 `AWS-RunPatchBaseline` 실행 시 오류](#patch-manager-troubleshooting-linux)
+ [Windows Server에서 `AWS-RunPatchBaseline` 실행 시 오류](#patch-manager-troubleshooting-windows)
+ [macOS에서 `AWS-RunPatchBaseline` 실행 시 오류](#patch-manager-troubleshooting-macos)
+ [AWS Support Automation 런북 사용](#patch-manager-troubleshooting-using-support-runbooks)
+ [AWS Support 문의](#patch-manager-troubleshooting-contact-support)
## 문제: `baseline_overrides.json`에 대한 "Invoke-PatchBaselineOperation: 액세스 거부됨" 오류 또는 "S3에서 파일을 다운로드할 수 없음" 오류
**문제**: 패치 정책에 따라 지정된 패치 적용 작업을 실행하면 다음 예제와 비슷한 오류가 표시됩니다.
------
#### [ Example error on Windows Server ]
```
----------ERROR-------
Invoke-PatchBaselineOperation : Access Denied
At C:\ProgramData\Amazon\SSM\InstanceData\i-02573cafcfEXAMPLE\document\orchestr
ation\792dd5bd-2ad3-4f1e-931d-abEXAMPLE\PatchWindows\_script.ps1:219 char:13
+ $response = Invoke-PatchBaselineOperation -Operation Install -Snapsho ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : OperationStopped: (Amazon.Patch.Ba...UpdateOpera
tion:InstallWindowsUpdateOperation) [Invoke-PatchBaselineOperation], Amazo
nS3Exception
+ FullyQualifiedErrorId : PatchBaselineOperations,Amazon.Patch.Baseline.Op
erations.PowerShellCmdlets.InvokePatchBaselineOperation
failed to run commands: exit status 0xffffffff
```
------
#### [ Example error on Linux ]
```
[INFO]: Downloading Baseline Override from s3://aws-quicksetup-patchpolicy-123456789012-abcde/baseline_overrides.json
[ERROR]: Unable to download file from S3: s3://aws-quicksetup-patchpolicy-123456789012-abcde/baseline_overrides.json.
[ERROR]: Error loading entrance module.
```
------
**원인**: Quick Setup에서 패치 정책을 생성했으며, 연결된 인스턴스 프로파일(EC2 인스턴스의 경우) 또는 연결된 서비스 역할(비 EC2 시스템의 경우)이 이미 일부 관리형 노드에 있었습니다.
그러나 다음 이미지와 같이 **인스턴스에 연결된 기존 인스턴스 프로파일에 필수 IAM 정책 추가** 확인란을 선택하지 않았습니다.
![\[\]](http://docs.aws.amazon.com/ko_kr/systems-manager/latest/userguide/images/QS-instance-profile-option.png)
패치 정책을 생성하면 정책의 구성 `baseline_overrides.json` 파일을 저장하는 Amazon S3 버킷도 생성됩니다. 정책을 생성할 때 **인스턴스에 연결된 기존 인스턴스 프로파일에 필수 IAM 정책 추가** 확인란을 선택하지 않으면 S3 버킷의 `baseline_overrides.json`에 액세스하는 데 필요한 IAM 정책 및 리소스 태그가 기존 IAM 인스턴스 프로파일 및 서비스 역할에 자동으로 추가되지 않습니다.
**솔루션 1**: 기존 패치 정책 구성을 삭제한 다음에 대체 패치 정책 구성을 생성하고, **인스턴스에 연결된 기존 인스턴스 프로파일에 필수 IAM 정책 추가** 확인란을 반드시 선택합니다. 이렇게 선택하면 연결된 인스턴스 프로파일 또는 서비스 역할이 이미 있는 노드에 이 Quick Setup 구성을 통해 생성된 IAM 정책이 적용됩니다. (기본적으로 Quick Setup에서는 인스턴스 프로파일 또는 서비스 역할이 아직 **없는 인스턴스와 노드에 필수 정책을 추가합니다.) 자세한 내용은 [Quick Setup 패치 정책을 사용하여 조직 전반의 패치 적용 자동화](https://docs.aws.amazon.com/systems-manager/latest/userguide/quick-setup-patch-manager.html)를 참조하세요.
**솔루션 2**: Quick Setup에서 사용하는 각 IAM 인스턴스 프로파일 및 IAM 서비스 역할에 필수 권한과 태그를 수동으로 추가합니다. 지침은 [패치 정책 S3 버킷에 대한 권한](quick-setup-patch-manager.md#patch-policy-s3-bucket-permissions) 섹션을 참조하세요.
## 문제: 명백한 원인 또는 오류 메시지 없이 패치 적용 실패
**문제**: 오류 메시지가 반환되지 않고 패치 적용 작업이 실패합니다.
**가능한 원인**: 관리형 노드에 패치를 적용할 때 패치가 성공적으로 설치되었더라도 문서 실행이 중단되고 실패로 표시될 수 있습니다. 이는 패치 작업 중에 시스템이 예기치 않은 재부팅을 시작하는 경우(예: 펌웨어 또는 SecureBoot와 같은 기능에 업데이트를 적용하기 위해) 발생할 수 있습니다. SSM 에이전트는 외부 재부팅에서 문서 실행 상태를 유지하고 재개할 수 없으므로 실행이 실패한 것으로 보고됩니다.
**솔루션**: 실행 실패 후 패치 설치 상태를 확인하려면 `Scan` 패치 작업을 실행한 다음 패치 관리자의 패치 규정 준수 데이터를 확인하여 현재 규정 준수 상태를 평가합니다.
이 시나리오에서 외부 재부팅이 실패의 원인이 아니었다고 판단되면 [AWS Support](#patch-manager-troubleshooting-contact-support)에 문의하는 것이 좋습니다.
## 문제: 예기치 않은 패치 규정 준수 결과
**문제**: `Scan` 작업 후에 생성된 패치 규정 준수 세부 정보를 검토할 때, 결과에 패치 기준선에 설정된 규칙에 부합하지 않는 정보가 포함되어 있습니다. 패치 기준선의 **Rejected patches**(거부된 패치) 목록에 추가한 예외가 `Missing`으로 표시되는 경우를 예로 들 수 있습니다. 또는 패치 기준선에서 `Critical` 패치만 지정했는데도 `Important`로 분류된 패치가 누락된 것으로 표시됩니다.
**원인**: Patch Manager는 현재 다양한 `Scan` 작업 실행 방법을 지원합니다.
+ Quick Setup에서 구성된 패치 정책
+ Quick Setup에서 구성된 호스트 관리 옵션
+ 패치 `Scan` 또는 `Install` 태스크를 실행하기 위한 유지 관리 기간
+ 온디맨드 **Patch now**(지금 패치) 작업
`Scan` 작업이 실행되면 가장 최근 검사의 규정 준수 세부 정보를 덮어씁니다. `Scan` 작업을 실행하도록 설정된 방법이 2가지 이상이고, 해당 방법에서 서로 다른 규칙의 서로 다른 패치 기준선을 사용하는 경우 패치 규정 준수 결과가 달라집니다.
**해결 방법**: 예기치 않은 패치 규정 준수 결과를 방지하려면 Patch Manager `Scan` 작업을 실행할 때 한 번에 한 가지 방법만 사용하는 것이 좋습니다. 자세한 내용은 [패치 규정 준수 데이터를 생성한 실행 식별](patch-manager-compliance-data-overwrites.md) 섹션을 참조하세요.
## Linux에서 `AWS-RunPatchBaseline` 실행 시 오류
**Topics**
+ [문제: '해당 파일 또는 디렉터리가 없음(No such file or directory)' 오류](#patch-manager-troubleshooting-linux-1)
+ [문제: '다른 프로세스가 yum 잠금을 획득함(another process has acquired yum lock)' 오류](#patch-manager-troubleshooting-linux-2)
+ [문제: '권한 거부됨/명령 실행 실패(Permission denied / failed to run commands)'오류](#patch-manager-troubleshooting-linux-3)
+ [문제: '페이로드를 다운로드할 수 없음(Unable to download payload)' 오류](#patch-manager-troubleshooting-linux-4)
+ [문제: '지원되지 않는 패키지 관리자 및 python 버전 조합(unsupported package manager and python version combination)' 오류](#patch-manager-troubleshooting-linux-5)
+ [문제: Patch Manager가 특정 패키지를 제외하도록 지정된 규칙을 적용하지 않음](#patch-manager-troubleshooting-linux-6)
+ [문제: 패치가 실패하고 Patch Manager가 TLS에 대한 서버 이름 표시 확장을 사용할 수 없다고 보고함](#patch-manager-troubleshooting-linux-7)
+ [문제: Patch Manager가 '시도할 미러가 더 이상 없음(No more mirrors to try)' 보고](#patch-manager-troubleshooting-linux-8)
+ [문제: 'curl에서 반환된 오류 코드는 23'이라는 메시지와 함께 패치 적용 실패](#patch-manager-troubleshooting-linux-9)
+ [문제: 'rpm 패키지 압축 해제 오류…’라는 메시지와 함께 패치 적용 실패](#error-unpacking-rpm)
+ [문제: 'Encounter service side error when uploading the inventory' 오류 메시지와 함께 패치 적용 실패](#inventory-upload-error)
+ [문제: '패키지를 다운로드하는 동안 오류가 발생했습니다'라는 메시지와 함께 패치 적용 실패](#errors-while-downloading)
+ [문제: 메모리 부족(OOM) 오류와 함께 패치 적용 실패](#patch-manager-troubleshooting-linux-oom)
+ [문제: '퍼블릭 키를 사용할 수 없어 다음 서명을 확인할 수 없습니다'라는 메시지와 함께 패치 적용 실패](#public-key-unavailable)
+ [문제: 'NoMoreMirrorsRepoError' 메시지와 함께 패치 적용 실패](#no-more-mirrors-repo-error)
+ [문제: '페이로드를 다운로드할 수 없음' 메시지와 함께 패치 적용 실패](#payload-download-error)
+ [문제: '설치 오류: dpkg: 오류: dpkg 프런트엔드가 다른 프로세스에 의해 잠겼습니다'라는 메시지와 함께 패치 적용 실패](#dpkg-frontend-locked)
+ [문제: 'dpkg가 중단되었습니다' 오류로 Ubuntu Server의 패치 적용 실패](#dpkg-interrupted)
+ [문제: 패키지 관리자 유틸리티를 통해 패키지 종속성을 해결할 수 없음](#unresolved-dependency)
+ [문제: SLES 관리형 노드에서 Zypper 패키지 잠금 종속성 실패](#patch-manager-troubleshooting-linux-zypper-locks)
+ [문제: 잠금을 획득할 수 없습니다. 또 다른 패치 적용 작업이 진행 중입니다.](#patch-manager-troubleshooting-linux-concurrent-lock)
### 문제: '해당 파일 또는 디렉터리가 없음(No such file or directory)' 오류
**문제**: `AWS-RunPatchBaseline` 실행 시 다음 오류 중 하나와 함께 패치가 실패합니다.
```
IOError: [Errno 2] No such file or directory: 'patch-baseline-operations-X.XX.tar.gz'
```
```
Unable to extract tar file: /var/log/amazon/ssm/patch-baseline-operations/patch-baseline-operations-1.75.tar.gz.failed to run commands: exit status 155
```
```
Unable to load and extract the content of payload, abort.failed to run commands: exit status 152
```
**원인 1**: `AWS-RunPatchBaseline`을 실행하는 2개의 명령이 동일한 관리형 노드에서 동시에 실행되었습니다. 이로 인해 임시 `file patch-baseline-operations*`가 제대로 생성 또는 액세스되지 않는 경쟁 조건이 발생합니다.
**원인 2**: `/var` 디렉터리의 저장 공간이 부족합니다.
**해결 방법 1**: 유지 관리 기간에 동일한 우선순위 수준으로 `AWS-RunPatchBaseline`을 실행하고 동일한 대상 ID에서 실행되는 둘 이상의 Run Command 태스크가 없는지 확인합니다. 이 경우 우선순위를 다시 지정합니다. Run Command는 AWS Systems Manager의 도구입니다.
**해결 방법 2**: 한 번에 하나의 유지 관리 기간만 동일한 대상 및 동일한 일정에서 `AWS-RunPatchBaseline`을 사용하는 Run Command 태스크를 실행하고 있는지 확인합니다. 이 경우 일정을 변경합니다.
**해결 방법 3**: 하나의 State Manager 연결만 동일한 일정으로 `AWS-RunPatchBaseline`을 실행하고 동일한 관리형 노드를 대상으로 하는지 확인합니다. State Manager는 AWS Systems Manager의 도구입니다.
**해결 방법 4**: 업데이트 패키지를 위해 `/var` 디렉터리에 충분한 저장 공간을 확보합니다.
### 문제: '다른 프로세스가 yum 잠금을 획득함(another process has acquired yum lock)' 오류
**문제**: `AWS-RunPatchBaseline` 실행 시 다음 오류와 함께 패치가 실패합니다.
```
12/20/2019 21:41:48 root [INFO]: another process has acquired yum lock, waiting 2 s and retry.
```
**원인**: `AWS-RunPatchBaseline` 문서가 이미 다른 작업에서 실행 중이고 패키지 관리자 `yum` 프로세스를 획득한 관리형 노드에서 실행을 시작했습니다.
**해결 방법**: 일정에 따라 `AWS-RunPatchBaseline`을 실행하는 State Manager 연결, 유지 관리 기간 태스크 또는 기타 구성이 거의 같은 시간에 동일한 관리형 노드를 대상으로 하지 않도록 합니다.
### 문제: '권한 거부됨/명령 실행 실패(Permission denied / failed to run commands)'오류
**문제**: `AWS-RunPatchBaseline` 실행 시 다음 오류와 함께 패치가 실패합니다.
```
sh:
/var/lib/amazon/ssm/instanceid/document/orchestration/commandid/PatchLinux/_script.sh: Permission denied
failed to run commands: exit status 126
```
**원인**: `/var/lib/amazon/`이 `noexec` 권한으로 탑재되었을 수 있습니다. 이것은 SSM Agent가 `/var/lib/amazon/ssm`에 페이로드 스크립트를 다운로드하고 해당 위치에서 실행하기 때문에 문제입니다.
**해결 방법**: `/var/log/amazon` 및 `/var/lib/amazon`에 대한 배타적 파티션을 구성하고 `exec` 권한으로 탑재했는지 확인합니다.
### 문제: '페이로드를 다운로드할 수 없음(Unable to download payload)' 오류
**문제**: `AWS-RunPatchBaseline` 실행 시 다음 오류와 함께 패치가 실패합니다.
```
Unable to download payload: https://s3.amzn-s3-demo-bucket.region.amazonaws.com/aws-ssm-region/patchbaselineoperations/linux/payloads/patch-baseline-operations-X.XX.tar.gz.failed to run commands: exit status 156
```
**원인**: 지정된 Amazon Simple Storage Service(Amazon S3) 버킷에 액세스하는 데 필요한 권한이 관리형 노드에 없습니다.
**해결 방법**: S3 엔드포인트에 연결할 수 있도록 네트워크 구성을 업데이트합니다. 자세한 내용은 [AWS 관리형 S3 버킷과 SSM Agent 통신](ssm-agent-technical-details.md#ssm-agent-minimum-s3-permissions)의 Patch Manager에 대한 S3 버킷에 대한 필수 액세스에 대한 정보를 참조하세요.
### 문제: '지원되지 않는 패키지 관리자 및 python 버전 조합(unsupported package manager and python version combination)' 오류
**문제**: `AWS-RunPatchBaseline` 실행 시 다음 오류와 함께 패치가 실패합니다.
```
An unsupported package manager and python version combination was found. Apt requires Python3 to be installed.
failed to run commands: exit status 1
```
**원인**: Debian Server 또는 Ubuntu Server 인스턴스에 지원되는 python3 버전이 설치되어 있지 않습니다.
**솔루션**: Debian Server 및 Ubuntu Server 관리형 노드에 필요한 지원되는 python3 버전(3.0\$13.12)을 서버에 설치합니다.
### 문제: Patch Manager가 특정 패키지를 제외하도록 지정된 규칙을 적용하지 않음
**문제**: `/etc/yum.conf` 파일에 `exclude=package-name` 형식으로 지정하여 특정 패키지를 제외하려고 했지만 Patch Manager `Install` 작업 중에 제외되지 않았습니다.
**원인**: Patch Manager는 `/etc/yum.conf` 파일에 지정된 제외를 포함하지 않습니다.
**해결 방법**: 특정 패키지를 제외하려면 사용자 정의 패치 기준을 생성하고 설치하지 않으려는 패키지를 제외하는 규칙을 생성합니다.
### 문제: 패치가 실패하고 Patch Manager가 TLS에 대한 서버 이름 표시 확장을 사용할 수 없다고 보고함
**문제**: 패치 작업이 다음 메시지를 표시합니다.
```
/var/log/amazon/ssm/patch-baseline-operations/urllib3/util/ssl_.py:369:
SNIMissingWarning: An HTTPS request has been made, but the SNI (Server Name Indication) extension
to TLS is not available on this platform. This might cause the server to present an incorrect TLS
certificate, which can cause validation failures. You can upgrade to a newer version of Python
to solve this.
For more information, see https://urllib3.readthedocs.io/en/latest/advanced-usage.html#ssl-warnings
```
**원인**: 이 메시지는 오류를 나타내지 않습니다. 대신 운영 체제와 함께 배포된 이전 버전의 Python이 TLS 서버 이름 표시를 지원하지 않는다는 경고입니다. Systems Manager 패치 페이로드 스크립트는 SNI를 지원하는 AWS API에 연결할 때 이 경고를 표시합니다.
**해결 방법**: 이 메시지가 보고될 때 패치 실패 문제를 해결하려면 `stdout` 및 `stderr` 파일의 내용을 검토합니다. 이러한 파일을 S3 버킷 또는 Amazon CloudWatch Logs 저장하도록 패치 기준선을 구성하지 않은 경우 Linux 관리형 노드의 다음 위치에서 파일을 찾을 수 있습니다.
`/var/lib/amazon/ssm/instance-id/document/orchestration/Run-Command-execution-id/awsrunShellScript/PatchLinux`
### 문제: Patch Manager가 '시도할 미러가 더 이상 없음(No more mirrors to try)' 보고
**문제**: 패치 작업이 다음 메시지를 표시합니다.
```
[Errno 256] No more mirrors to try.
```
**원인**: 관리형 노드에 구성된 리포지토리가 제대로 작동하지 않습니다. 이에 대한 가능한 원인은 다음과 같습니다.
+ `yum` 캐시가 손상되었습니다.
+ 네트워크 관련 문제로 인해 리포지토리 URL에 연결할 수 없습니다.
**해결 방법**: Patch Manager는 관리형 노드의 기본 패키지 관리자를 사용하여 패치 작업을 수행합니다. 리포지토리가 제대로 구성되고 작동하는지 다시 확인합니다.
### 문제: 'curl에서 반환된 오류 코드는 23'이라는 메시지와 함께 패치 적용 실패
**문제**: 다음과 비슷한 오류로 `AWS-RunPatchBaseline`을 사용하는 패치 적용 작업이 실패합니다.
```
05/01/2025 17:04:30 root [ERROR]: Error code returned from curl is 23
```
**원인**: 파일 시스템에 쓰는 데 필요한 권한이 시스템에서 사용 중인 curl 도구에 없습니다. 이는 패키지 관리자의 기본 curl 도구가 다른 버전(예: snap으로 설치된 도구)으로 대체된 경우에 발생할 수 있습니다.
**솔루션**: 다른 버전이 설치되었을 때 패키지 관리자가 제공한 curl 버전이 제거되었다면 다시 설치합니다.
여러 curl 버전을 설치된 상태로 유지해야 하는 경우 패키지 관리자와 연결된 버전이 `PATH` 변수에 나열된 첫 번째 디렉터리에 있는지 확인합니다. `echo $PATH` 명령을 실행하여 시스템에서 실행 파일을 검사한 디렉터리의 현재 순서를 참조하면 이를 확인할 수 있습니다.
### 문제: 'rpm 패키지 압축 해제 오류…’라는 메시지와 함께 패치 적용 실패
**문제**: 다음과 비슷한 오류로 패치 적용 작업이 실패합니다.
```
Error : Error unpacking rpm package python-urllib3-1.25.9-1.amzn2.0.2.noarch
python-urllib3-1.25.9-1.amzn2.0.1.noarch was supposed to be removed but is not!
failed to run commands: exit status 1
```
**원인 1**: 특정 패키지가 여러 패키지 설치 관리자에 있으면(예: `pip` 및 `yum` 둘 다 또는 `dnf`) 기본 패키지 관리자를 사용할 때 충돌이 발생할 수 있습니다.
`pip`, `yum` 및 `dnf`에서 찾을 수 있는 일반적인 예가 `urllib3` 패키지에서 발생합니다.
**원인 2**: `python-urllib3` 패키지가 손상되었습니다. `rpm`이 이전에 `yum` 또는 `dnf`를 통해 설치된 패키지였던 이후에 `pip`을 통해 패키지 파일이 설치되거나 업데이트되었으면 이 문제가 발생할 수 있습니다.
**솔루션**: 기본 패키지 관리자(`yum` 또는 `dnf`)에서만 패키지가 유지되도록 `sudo pip uninstall urllib3` 명령을 실행하여 pip에서 `python-urllib3` 패키지를 제거합니다.
### 문제: 'Encounter service side error when uploading the inventory' 오류 메시지와 함께 패치 적용 실패
**문제**: `AWS-RunPatchBaseline` 문서를 실행할 때 다음 오류 메시지가 표시됩니다.
```
Encounter service side error when uploading the inventory
```
**원인**: `AWS-RunPatchBaseline`을 실행하는 2개의 명령이 동일한 관리형 노드에서 동시에 실행되었습니다. 이로 인해 패치 적용 작업 중에 boto3 클라이언트를 초기화할 때 경합 조건이 생성됩니다.
**해결 방법**: 일정에 따라 `AWS-RunPatchBaseline`을 실행하는 State Manager 연결, 유지 관리 기간 태스크 또는 기타 구성이 거의 같은 시간에 동일한 관리형 노드를 대상으로 하지 않도록 합니다.
### 문제: '패키지를 다운로드하는 동안 오류가 발생했습니다'라는 메시지와 함께 패치 적용 실패
**문제**: 패치를 적용하는 동안 다음과 비슷한 오류가 표시됩니다.
```
YumDownloadError: [u'Errors were encountered while downloading
packages.', u'libxml2-2.9.1-6.el7_9.6.x86_64: [Errno 5] [Errno 12]
Cannot allocate memory', u'libxslt-1.1.28-6.el7.x86_64: [Errno 5]
[Errno 12] Cannot allocate memory', u'libcroco-0.6.12-6.el7_9.x86_64:
[Errno 5] [Errno 12] Cannot allocate memory', u'openldap-2.4.44-25.el7_9.x86_64:
[Errno 5] [Errno 12] Cannot allocate memory',
```
**원인**: 이 오류는 관리형 노드에 사용할 수 있는 메모리가 부족할 때 발생할 수 있습니다.
**솔루션**: 스왑 메모리를 구성하거나 인스턴스를 다른 유형으로 업그레이드하여 메모리 지원을 늘립니다. 그런 다음에 새 패치 적용 작업을 시작합니다.
### 문제: 메모리 부족(OOM) 오류와 함께 패치 적용 실패
**문제**: `AWS-RunPatchBaseline`을 실행하면 관리형 노드의 메모리 부족으로 인해 패치 작업이 실패합니다. `Cannot allocate memory`, `Killed`(Linux OOM Killer에서 발생)와 같은 오류가 발생하거나 작업이 예기치 않게 실패할 수 있습니다. 이 오류는 RAM이 1GB 미만인 인스턴스에서 발생할 가능성이 높지만, 사용할 수 있는 업데이트가 많은 경우 메모리가 더 많은 인스턴스에도 영향을 줄 수 있습니다.
**원인**: Patch Manager는 관리형 노드의 네이티브 패키지 관리자를 사용하여 패치 작업을 실행합니다. 패치 작업 중에 필요한 메모리는 다음과 같은 여러 요인에 따라 달라집니다.
+ 관리형 노드에 설치된 패키지 수 및 사용 가능한 업데이트 수.
+ 사용 중인 패키지 관리자 및 해당 메모리 특성.
+ 패치 작업 시 관리형 노드에서 실행 중인 기타 프로세스.
설치된 패키지가 많거나 사용 가능한 업데이트가 많은 관리형 노드는 패치 작업 중에 더 많은 메모리가 필요합니다. 사용 가능한 메모리가 충분하지 않으면 패치 적용 프로세스가 실패하고 오류와 함께 종료됩니다. 운영 체제가 패치 프로세스를 종료할 수도 있습니다.
**해결 방법**: 다음 방법 중 하나 이상을 시도해 보세요.
+ 유지 관리 기간을 사용하는 등 관리형 노드에서 워크로드 활동이 적은 시간대에 패치 적용 작업을 예약합니다.
+ 인스턴스를 메모리가 더 많은 유형으로 업그레이드합니다.
+ 관리형 노드에서 스왑 메모리를 구성합니다. EBS 처리량이 제한된 인스턴스에서는 스왑 사용량이 많으면 성능이 저하될 수 있습니다.
+ 패치 작업 중에 관리형 노드에서 실행 중인 프로세스 수를 검토하고 줄입니다.
### 문제: '퍼블릭 키를 사용할 수 없어 다음 서명을 확인할 수 없습니다'라는 메시지와 함께 패치 적용 실패
**문제**: 다음과 비슷한 오류로 Ubuntu Server에서 패치 적용에 실패합니다.
```
02/17/2022 21:08:43 root [ERROR]: W:GPG error:
http://repo.mysql.com/apt/ubuntu bionic InRelease: The following
signatures couldn't be verified because the public key is not available:
NO_PUBKEY 467B942D3A79BD29, E:The repository ' http://repo.mysql.com/apt/ubuntu bionic
```
**원인**: GPG(GNU Privacy Guard) 키가 만료되었거나 누락되었습니다.
**솔루션**: GPG 키를 새로 고치거나 키를 다시 추가합니다.
예를 들어 이전에 표시된 오류를 사용하면 `467B942D3A79BD29` 키가 누락되었으며 추가해야 한다는 것을 알 수 있습니다. 이렇게 하려면 다음과 같은 명령 중 하나를 실행합니다.
```
sudo apt-key adv --keyserver hkps://keyserver.ubuntu.com --recv-keys 467B942D3A79BD29
```
```
sudo apt-key adv --keyserver hkp://keyserver.ubuntu.com:80 --recv-keys 467B942D3A79BD29
```
또는 모든 키를 새로 고치려면 다음 명령을 실행합니다.
```
sudo apt-key adv --keyserver hkps://keyserver.ubuntu.com --refresh-keys
```
이후에도 오류가 다시 발생하면 리포지토리를 유지 관리하는 조직에 문제를 보고하는 것이 좋습니다. 수정이 가능할 때까지 패치 적용 프로세스 중에 `/etc/apt/sources.list` 파일을 편집하여 리포지토리를 생략할 수 있습니다.
이렇게 하려면 편집할 `sources.list` 파일을 열고, 리포지토리의 줄을 찾고, 줄 시작 부분에 `#` 문자를 삽입하여 주석을 추가합니다. 그런 다음에 파일을 저장하고 닫습니다.
### 문제: 'NoMoreMirrorsRepoError' 메시지와 함께 패치 적용 실패
**문제**: 다음과 비슷한 오류가 표시됩니다.
```
NoMoreMirrorsRepoError: failure: repodata/repomd.xml from pgdg94: [Errno 256] No more mirrors to try.
```
**원인**: 소스 리포지토리에 오류가 있습니다.
**솔루션**: 리포지토리를 유지 관리하는 조직에 문제를 보고하는 것이 좋습니다. 오류가 수정될 때까지 운영 체제 수준에서 리포지토리를 비활성화할 수 있습니다. 이렇게 하려면 다음 명령을 실행하여 *repo-name*의 값을 리포지토리 이름으로 바꿉니다.
```
yum-config-manager --disable repo-name
```
다음은 한 예입니다.
```
yum-config-manager --disable pgdg94
```
이 명령을 실행한 후 다른 패치 적용 작업을 실행합니다.
### 문제: '페이로드를 다운로드할 수 없음' 메시지와 함께 패치 적용 실패
**문제**: 다음과 비슷한 오류가 표시됩니다.
```
Unable to download payload:
https://s3.dualstack.eu-west-1.amazonaws.com/aws-ssm-eu-west-1/patchbaselineoperations/linux/payloads/patch-baseline-operations-1.83.tar.gz.
failed to run commands: exit status 156
```
**원인**: 관리형 노드 구성에 오류가 있거나 불완전합니다.
**솔루션**: 관리형 노드에 다음이 구성되었는지 확인합니다.
+ 보안 그룹의 아웃바운드 TCP 443 규칙.
+ NACL의 송신 TCP 443 규칙.
+ NACL의 수신 TCP 1024-65535 규칙.
+ S3 엔드포인트에 대한 연결을 제공하는 라우팅 테이블의 NAT/IGW 인스턴스에 인터넷 액세스 권한이 없으면 S3 엔드포인트와 연결을 제공합니다. 이렇게 하려면 S3 게이트웨이 엔드포인트를 VPC에서 추가하고 관리형 노드의 라우팅 테이블과 통합합니다.
### 문제: '설치 오류: dpkg: 오류: dpkg 프런트엔드가 다른 프로세스에 의해 잠겼습니다'라는 메시지와 함께 패치 적용 실패
**문제**: 다음과 비슷한 오류로 패치 적용에 실패합니다.
```
install errors: dpkg: error: dpkg frontend is locked by another process
failed to run commands: exit status 2
Failed to install package; install status Failed
```
**원인**: 운영 체제 수준에서 관리형 노드의 다른 프로세스가 이미 패키지 관리자에서 실행되고 있습니다. 다른 프로세스를 완료하는 데 시간이 오래 걸리는 경우 Patch Manager 패치 적용 작업이 시간 초과로 실패할 수 있습니다.
**솔루션**: 패키지 관리자를 사용 중인 다른 프로세스가 완료된 후 새 패치 적용 작업을 실행합니다.
### 문제: 'dpkg가 중단되었습니다' 오류로 Ubuntu Server의 패치 적용 실패
**문제**: Ubuntu Server에서 다음과 비슷한 오류로 패치 적용에 실패합니다.
```
E: dpkg was interrupted, you must manually run
'dpkg --configure -a' to correct the problem.
```
**원인**: 하나 이상의 패키지가 잘못 구성되었습니다.
**해결 방법**: 다음 단계를 수행합니다.
1. 다음과 같은 명령을 한 번에 하나씩 실행하여 영향을 받는 패키지와 각 패키지의 문제를 확인합니다.
```
sudo apt-get check
```
```
sudo dpkg -C
```
```
dpkg-query -W -f='${db:Status-Abbrev} ${binary:Package}\n' | grep -E ^.[^nci]
```
1. 다음 명령을 실행하여 문제가 있는 패키지를 수정합니다.
```
sudo dpkg --configure -a
```
1. 이전 명령으로 문제가 완전히 해결되지 않으면 다음 명령을 실행합니다.
```
sudo apt --fix-broken install
```
### 문제: 패키지 관리자 유틸리티를 통해 패키지 종속성을 해결할 수 없음
**문제**: 관리형 노드의 네이티브 패키지 관리자를 통해 패키지 종속성을 해결할 수 없어 패치 적용에 실패합니다. 다음 오류 메시지 예제는 `yum`을 패키지 관리자로 사용하는 운영 체제의 이 오류 유형을 나타냅니다.
```
09/22/2020 08:56:09 root [ERROR]: yum update failed with result code: 1,
message: [u'rpm-python-4.11.3-25.amzn2.0.3.x86_64 requires rpm = 4.11.3-25.amzn2.0.3',
u'awscli-1.18.107-1.amzn2.0.1.noarch requires python2-botocore = 1.17.31']
```
**원인**: Linux 운영 체제의 Patch Manager에서는 시스템의 네이티브 패키지 관리자를 사용하여 패치 적용 작업을 실행합니다(예: `yum`, `dnf`, `apt` 및 `zypper`). 애플리케이션에서는 필요에 따라 종속 패키지를 자동으로 감지, 설치, 업데이트 또는 제거합니다. 그러나 다음과 같은 일부 조건에서는 패키지 관리자가 종속성 작업을 완료하지 못할 수 있습니다.
+ 충돌하는 리포지토리가 운영 체제에 여러 개 구성되어 있습니다.
+ 네트워크 관련 문제로 인해 원격 리포지토리 URL에 액세스할 수 없습니다.
+ 리포지토리에서 잘못된 아키텍처에 대한 패키지를 찾았습니다.
**솔루션**: 아주 다양한 사유의 종속성 문제 때문에 패치 적용에 실패할 수 있습니다. 따라서 AWS Support에 문의하여 문제 해결 도움을 받는 것이 좋습니다.
### 문제: SLES 관리형 노드에서 Zypper 패키지 잠금 종속성 실패
**문제**: SUSE Linux Enterprise Server 인스턴스에서 `Install` 작업을 사용하여 `AWS-RunPatchBaseline`을 실행하면 패키지 잠금과 관련된 종속성 검사 오류와 함께 패치 적용이 실패합니다. 다음과 비슷한 오류 메시지가 나타날 수 있습니다.
```
Problem: mock-pkg-has-dependencies-0.2.0-21.adistro.noarch requires mock-pkg-standalone = 0.2.0, but this requirement cannot be provided
uninstallable providers: mock-pkg-standalone-0.2.0-21.adistro.noarch[local-repo]
Solution 1: remove lock to allow installation of mock-pkg-standalone-0.2.0-21.adistro.noarch[local-repo]
Solution 2: do not install mock-pkg-has-dependencies-0.2.0-21.adistro.noarch
Solution 3: break mock-pkg-has-dependencies-0.2.0-21.adistro.noarch by ignoring some of its dependencies
Choose from above solutions by number or cancel [1/2/3/c] (c): c
```
이 예제에서는 패키지 `mock-pkg-standalone`이 잠기므로 `sudo zypper locks`를 실행하고 출력에서 이 패키지 이름을 찾아 확인할 수 있습니다.
또는 종속성 검사 실패를 나타내는 로그 항목이 표시될 수 있습니다.
```
Encountered a known exception in the CLI Invoker: CLIInvokerError(error_message='Dependency check failure during commit process', error_code='4')
```
**참고**
이 문제는 `Install` 작업 중에만 발생합니다. `Scan` 작업은 패키지 잠금을 적용하지 않으며 기존 잠금의 영향을 받지 않습니다.
**원인**: 이 오류는 zypper 패키지 잠금으로 인해 종속성 충돌 때문에 패키지 설치 또는 업데이트가 불가능한 경우에 발생합니다. 패키지 잠금은 다음과 같은 여러 가지 이유로 존재할 수 있습니다.
+ **고객 적용 잠금**: 사용자 또는 시스템 관리자가 `zypper addlock`과 같은 zypper 명령을 사용하여 패키지를 수동으로 잠갔습니다.
+ **Patch Manager 거부 패치**: 패치 기준의 **거부된 패치** 목록에 패키지를 지정하면 Patch Manager가 자동으로 패키지 잠금을 적용하여 설치를 방지합니다.
+ **중단된 작업으로 인한 잔존 잠금**: 드문 경우지만 Patch Manager가 임시 잠금을 정리하기 전에 패치 작업이 중단된 경우(예: 시스템 재부팅) 잔존 패키지 잠금이 관리형 노드에 남아 있을 수 있습니다.
**솔루션**: zypper 패키지 잠금 문제를 해결하려면 원인에 따라 다음 단계를 따르세요.
**1단계: 잠긴 패키지 식별**
SLES 관리형 노드에 연결하고 다음 명령을 실행하여 현재 잠긴 패키지를 모두 나열합니다.
```
sudo zypper locks
```
**2단계: 잠금 소스 확인**
+ 잠긴 패키지가 시스템 안정성을 위해 의도적으로 잠긴 패키지인 경우 잠금 상태로 유지해야 하는지 아니면 패치 적용을 위해 일시적으로 잠금 해제할 수 있는지 고려합니다.
+ 잠긴 패키지가 패치 기준의 **거부된 패치** 목록의 항목과 일치하는 경우 이는 중단된 패치 작업으로 인한 잔존 잠금일 수 있습니다. 정상 작업 중에 Patch Manager는 이러한 잠금을 일시적으로 적용하고 작업이 완료되면 자동으로 제거합니다. 거부된 패치 목록에서 패키지를 제거하거나 패치 기준 규칙을 수정할 수 있습니다.
+ 잠긴 패키지를 인식할 수 없고 해당 패키지가 의도적으로 잠기지 않았다면 이전에 중단된 패치 작업의 잔존 잠금일 수 있습니다.
**3단계: 필요에 따라 잠금 제거**
특정 패키지 잠금을 제거하려면 다음 명령을 사용합니다.
```
sudo zypper removelock package-name
```
모든 패키지 잠금을 제거하려면(주의 필요) 다음 명령을 실행합니다.
```
sudo zypper cleanlocks
```
**4단계: 패치 기준 업데이트(해당하는 경우)**
패치 기준에서 거부된 패치로 인해 잠금이 발생한 경우:
1. [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)에서 AWS Systems Manager 콘솔을 엽니다.
1. 탐색 창에서 **Patch Manager**를 선택합니다.
1. **패치 기준** 탭을 선택한 다음 사용자 지정 패치 기준을 선택합니다.
1. **작업**, **패치 기준 수정**을 선택합니다.
1. **거부된 패치** 섹션에서 나열된 패키지를 검토하고 설치를 허용해야 하는 패키지를 모두 제거합니다.
1. **변경 사항 저장**을 선택합니다.
**5단계: 패치 작업 재시도**
문제가 있는 잠금을 제거하고 필요한 경우 패치 기준을 업데이트한 후 `AWS-RunPatchBaseline` 문서를 다시 실행합니다.
**참고**
Patch Manager는 `Install` 작업 중에 거부된 패치에 대한 잠금을 적용하면 패치 작업이 완료된 후 이러한 잠금을 자동으로 정리하도록 설계되었습니다. `sudo zypper locks`를 실행할 때 이러한 잠금이 표시되면 정리가 발생하기 전에 이전 패치 작업이 중단되었음을 나타냅니다. 그러나 패치 작업이 중단되면 이 절차에 설명된 대로 수동 정리가 필요할 수 있습니다.
**방지**: 향후 zypper 잠금 충돌을 방지하려면
+ 패치 기준의 거부된 패치 목록을 주의 깊게 검토하여 실제로 제외하려는 패키지만 포함되어 있는지 확인합니다.
+ 보안 업데이트에 대한 종속성으로 필요할 수 있는 패키지를 수동으로 잠그지 마세요.
+ 패키지를 수동으로 잠가야 하는 경우 이유를 문서화하고 잠금을 주기적으로 검토합니다.
+ 패치 작업이 성공적으로 완료되고 시스템 재부팅 또는 기타 요인으로 인해 중단되지 않는지 확인합니다.
+ 패치 작업이 완료될 때까지 모니터링하고 시스템 재부팅 또는 적절한 임시 잠금 정리를 방해할 수 있는 기타 작업으로 패치 작업이 중단되지 않도록 합니다.
### 문제: 잠금을 획득할 수 없습니다. 또 다른 패치 적용 작업이 진행 중입니다.
**문제**: `AWS-RunPatchBaseline` 실행 시, 오류 코드 4와 다음 오류 메시지와 함께 패치가 실패합니다.
```
[ERROR]: Cannot acquire lock on /var/log/amazon/ssm/patch-baseline-concurrent.lock. Another patching operation is in progress.
```
**원인**: 이 오류는 여러 패치 적용 작업이 동일한 관리형 노드에서 동시에 실행을 시도할 때 발생합니다. 잠금 파일은 동시 패치 작업을 방지하여 충돌을 방지하고 시스템 안정성을 보장합니다.
**해결 방법**: 패치 작업이 동일한 관리형 노드에서 동시에 실행되도록 예약되지 않았는지 확인합니다. 다음 구성을 검토하여 일정 충돌을 식별하고 해결합니다.
+ **패치 정책**: 빠른 설정 패치 정책 구성을 확인하여 다른 패치 적용 일정과 겹치지 않도록 합니다.
+ **유지 관리 기간**: 유지 관리 기간 연결을 검토하여 겹치는 시간대에 여러 기간이 동일한 관리형 노드를 대상으로 패치 작업을 수행하지 않는지 확인합니다.
+ **수동 즉시 패치 작업**: 예약된 패치 적용이 진행되는 동안 수동 **즉시 패치 작업**을 시작하지 마세요.
## Windows Server에서 `AWS-RunPatchBaseline` 실행 시 오류
**Topics**
+ [문제: 일치하지 않는 제품군/제품 페어](#patch-manager-troubleshooting-product-family-mismatch)
+ [문제: `AWS-RunPatchBaseline` 출력에서 `HRESULT`(Windows Server) 반환](#patch-manager-troubleshooting-hresult)
+ [문제: 관리형 노드에 Windows 업데이트 카탈로그 또는 WSUS에 대한 액세스 권한이 없습니다.](#patch-manager-troubleshooting-instance-access)
+ [문제: PatchBaselineOperations PowerShell 모듈을 다운로드할 수 없음](#patch-manager-troubleshooting-module-not-downloadable)
+ [문제: 패치 누락](#patch-manager-troubleshooting-missing-patches)
+ [문제: 잠금을 획득할 수 없습니다. 또 다른 패치 적용 작업이 진행 중입니다.](#patch-manager-troubleshooting-windows-concurrent-lock)
### 문제: 일치하지 않는 제품군/제품 페어
**문제**: Systems Manager 콘솔에서 패치 기준을 생성할 때 제품군 및 제품을 지정합니다. 예를 들면 다음을 선택할 수 있습니다.
+ **제품군**: `Office`
**제품**: `Office 2016`
**원인**: 일치하지 않는 제품군/제품 페어로 패치 기준을 만들려고 하면 오류 메시지가 표시됩니다. 가능한 이유는 다음과 같습니다.
+ 유효한 제품군 및 제품 페어를 선택했지만 제품군 선택을 제거했습니다.
+ [**사용 가능 및 일치하는 옵션(Available and matching options)**] 하위 목록 대신 [**폐기되었거나 일치하지 않는 옵션(Obsolete or mismatched options)**] 하위 목록에서 제품을 선택했습니다.
실수로 제품 [**사용되지 않거나 일치하지 않는 옵션(Obsolete or mismatched options)**] 하위 목록의 항목이 SDK 또는 AWS Command Line Interface(AWS CLI) `create-patch-baseline` 명령을 통해 입력되었을 수 있습니다. 오타가 있거나 제품이 잘못된 제품군에 할당되었다는 뜻일 수 있습니다. 이전 패치 기준에 지정되었지만 Microsoft에서 제공하는 패치가 없는 경우에도 [**사용되지 않거나 일치하지 않는 옵션(Obsolete or mismatched options)**] 하위 목록에 제품이 포함됩니다.
**해결 방법**: 콘솔에서 이 문제를 방지하려면 항상 [**현재 사용 가능한 옵션(Currently available options)**] 하위 목록에서 옵션을 선택합니다.
AWS CLI에서 `[https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-patch-properties.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-patch-properties.html)` 명령을 사용하거나 `[https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_DescribePatchProperties.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_DescribePatchProperties.html)` 명령을 사용하여 사용 가능한 패치가 있는 제품을 볼 수도 있습니다.
### 문제: `AWS-RunPatchBaseline` 출력에서 `HRESULT`(Windows Server) 반환
**문제**: 다음과 같은 오류가 표시됩니다.
```
----------ERROR-------
Invoke-PatchBaselineOperation : Exception Details: An error occurred when
attempting to search Windows Update.
Exception Level 1:
Error Message: Exception from HRESULT: 0x80240437
Stack Trace: at WUApiLib.IUpdateSearcher.Search(String criteria)..
(Windows updates)
11/22/2020 09:17:30 UTC | Info | Searching for Windows Updates.
11/22/2020 09:18:59 UTC | Error | Searching for updates resulted in error: Exception from HRESULT: 0x80240437
----------ERROR-------
failed to run commands: exit status 4294967295
```
**원인**: 이 출력은 기본 Windows Update API가 패치 작업을 실행할 수 없음을 나타냅니다.
**해결 방법**: 다음 microsoft.com 항목에서 `HResult` 코드를 확인하여 오류 해결을 위한 문제 해결 단계를 식별합니다.
+ [구성 요소별 Windows 업데이트 오류 코드](https://learn.microsoft.com/en-us/windows/deployment/update/windows-update-error-reference)
+ [Windows 업데이트의 일반적인 오류 및 해결 방법](https://learn.microsoft.com/en-us/troubleshoot/windows-client/deployment/common-windows-update-errors)
### 문제: 관리형 노드에 Windows 업데이트 카탈로그 또는 WSUS에 대한 액세스 권한이 없습니다.
**문제**: 다음과 같은 오류가 표시됩니다.
```
Downloading PatchBaselineOperations PowerShell module from https://s3.aws-api-domain/path_to_module.zip to C:\Windows\TEMP\Amazon.PatchBaselineOperations-1.29.zip.
Extracting PatchBaselineOperations zip file contents to temporary folder.
Verifying SHA 256 of the PatchBaselineOperations PowerShell module files.
Successfully downloaded and installed the PatchBaselineOperations PowerShell module.
Patch Summary for
PatchGroup :
BaselineId :
Baseline : null
SnapshotId :
RebootOption : RebootIfNeeded
OwnerInformation :
OperationType : Scan
OperationStartTime : 1970-01-01T00:00:00.0000000Z
OperationEndTime : 1970-01-01T00:00:00.0000000Z
InstalledCount : -1
InstalledRejectedCount : -1
InstalledPendingRebootCount : -1
InstalledOtherCount : -1
FailedCount : -1
MissingCount : -1
NotApplicableCount : -1
UnreportedNotApplicableCount : -1
EC2AMAZ-VL3099P - PatchBaselineOperations Assessment Results - 2020-12-30T20:59:46.169
----------ERROR-------
Invoke-PatchBaselineOperation : Exception Details: An error occurred when attempting to search Windows Update.
Exception Level 1:
Error Message: Exception from HRESULT: 0x80072EE2
Stack Trace: at WUApiLib.IUpdateSearcher.Search(String criteria)
at Amazon.Patch.Baseline.Operations.PatchNow.Implementations.WindowsUpdateAgent.SearchForUpdates(String
searchCriteria)
At C:\ProgramData\Amazon\SSM\InstanceData\i-02573cafcfEXAMPLE\document\orchestration\3d2d4864-04b7-4316-84fe-eafff1ea58
e3\PatchWindows\_script.ps1:230 char:13
+ $response = Invoke-PatchBaselineOperation -Operation Install -Snapsho ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : OperationStopped: (Amazon.Patch.Ba...UpdateOperation:InstallWindowsUpdateOperation) [Inv
oke-PatchBaselineOperation], Exception
+ FullyQualifiedErrorId : Exception Level 1:
Error Message: Exception Details: An error occurred when attempting to search Windows Update.
Exception Level 1:
Error Message: Exception from HRESULT: 0x80072EE2
Stack Trace: at WUApiLib.IUpdateSearcher.Search(String criteria)
at Amazon.Patch.Baseline.Operations.PatchNow.Implementations.WindowsUpdateAgent.SearchForUpdates(String searc
---Error truncated----
```
**원인**: 이 오류는 Windows Update 구성 요소, Windows Update 카탈로그 또는 Windows Server Update Services(WSUS)에 대한 연결 부족과 관련이 있을 수 있습니다.
**해결 방법**: 관리형 노드가 인터넷 게이트웨이, NAT 게이트웨이 또는 NAT 인스턴스를 통해 [Microsoft Update 카탈로그](https://www.catalog.update.microsoft.com/home.aspx)에 연결되어 있는지 확인합니다. WSUS를 사용하는 경우 관리형 노드가 환경의 WSUS 서버에 연결되어 있는지 확인합니다. 의도한 대상에 연결할 수 있는 경우 Microsoft 설명서에서 `HResult 0x80072EE2`의 다른 잠재적 원인을 확인합니다. 이는 운영 체제 수준 문제를 나타낼 수 있습니다.
### 문제: PatchBaselineOperations PowerShell 모듈을 다운로드할 수 없음
**문제**: 다음과 같은 오류가 표시됩니다.
```
Preparing to download PatchBaselineOperations PowerShell module from S3.
Downloading PatchBaselineOperations PowerShell module from https://s3.aws-api-domain/path_to_module.zip to C:\Windows\TEMP\Amazon.PatchBaselineOperations-1.29.zip.
----------ERROR-------
C:\ProgramData\Amazon\SSM\InstanceData\i-02573cafcfEXAMPLE\document\orchestration\aaaaaaaa-bbbb-cccc-dddd-4f6ed6bd5514\
PatchWindows\_script.ps1 : An error occurred when executing PatchBaselineOperations: Unable to connect to the remote server
+ CategoryInfo : NotSpecified: (:) [Write-Error], WriteErrorException
+ FullyQualifiedErrorId : Microsoft.PowerShell.Commands.WriteErrorException,_script.ps1
failed to run commands: exit status 4294967295
```
**해결 방법**: Amazon Simple Storage Service(Amazon S3)에 대한 관리형 노드 연결 및 권한을 확인합니다. 관리형 노드의 AWS Identity and Access Management(IAM) 역할이 [AWS 관리형 S3 버킷과 SSM Agent 통신](ssm-agent-technical-details.md#ssm-agent-minimum-s3-permissions)에 언급된 최소 권한을 사용해야 합니다. 노드는 Amazon S3 게이트웨이 엔드포인트, NAT 게이트웨이 또는 인터넷 게이트웨이를 통해 Amazon S3 엔드포인트와 통신해야 합니다. AWS Systems ManagerSSM Agent (SSM Agent)에 대한 VPC 엔드포인트 요구 사항에 대한 자세한 내용은 [Systems Manager용 VPC 엔드포인트를 사용하여 EC2 인스턴스의 보안 개선](setup-create-vpc.md) 섹션을 참조하세요.
### 문제: 패치 누락
**문제**: `AWS-RunPatchbaseline`이 성공적으로 완료되었지만 일부 누락된 패치가 있습니다.
다음은 몇 가지 일반적인 원인과 해결 방법입니다.
**원인 1**: 기준이 유효하지 않습니다.
**해결 방법 1**: 이것이 원인인지 확인하려면 다음 절차를 따릅니다.
1. [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)에서 AWS Systems Manager 콘솔을 엽니다.
1. 탐색 창에서 **Run Command**를 선택합니다.
1. [**명령 기록(Command history)**] 탭을 선택하고 기준을 확인할 명령을 선택합니다.
1. 패치가 누락된 관리형 노드를 선택합니다.
1. [**1단계 - 출력(Step 1 - Output)**]을 선택하고 `BaselineId` 값을 찾습니다.
1. 할당된 [패치 기준 구성](patch-manager-predefined-and-custom-patch-baselines.md#patch-manager-baselines-custom), 즉 운영 체제, 제품 이름, 분류 및 패치 기준의 심각도를 확인합니다.
1. [Microsoft Update 카탈로그](https://www.catalog.update.microsoft.com/home.aspx)로 이동합니다.
1. Microsoft 기술 자료(KB) 문서 ID(예: KB3216916)를 검색합니다.
1. **제품(Product)** 아래의 값이 관리형 노드의 값과 일치하는지 확인하고 해당 **제목(Title)**을 선택합니다. 새로운 **Update Details(세부 정보 업데이트)** 창이 열립니다.
1. [**개요(Overview)**] 탭의 [**분류(classification)**] 및 [**MSRC 심각도(MSRC severity)**]가 이전에 찾은 패치 기준 구성과 일치해야 합니다.
**원인 2**: 패치가 교체되었습니다.
**해결 방법 2**: 이것이 맞는지 확인하려면 다음 절차를 따릅니다.
1. [Microsoft Update 카탈로그](https://www.catalog.update.microsoft.com/home.aspx)로 이동합니다.
1. Microsoft 기술 자료(KB) 문서 ID(예: KB3216916)를 검색합니다.
1. **제품(Product)** 아래의 값이 관리형 노드의 값과 일치하는지 확인하고 해당 **제목(Title)**을 선택합니다. 새로운 **Update Details(세부 정보 업데이트)** 창이 열립니다.
1. [**패키지 세부 정보(Package Details)**] 탭으로 이동합니다. [**이 업데이트는 다음 업데이트로 대체되었습니다.(This update has been replaced by the following updates:)**] 헤더 아래에서 항목을 찾습니다.
**원인 3**: WSUS 및 Window 온라인 업데이트는 Microsoft에서 독립적인 릴리스 채널로 처리하기 때문에 동일한 패치의 KB 번호가 다를 수 있습니다.
**해결 방법 3**: 패치 적격성을 확인합니다. WSUS에서 패키지를 사용할 수 없는 경우 [OS 빌드 14393.3115](https://support.microsoft.com/en-us/topic/july-16-2019-kb4507459-os-build-14393-3115-511a3df6-c07e-14e3-dc95-b9898a7a7a57)를 설치합니다. 모든 운영 체제 빌드에 패키지를 사용할 수 있는 경우 [OS 빌드 18362.1256 및 18363.1256](https://support.microsoft.com/en-us/topic/december-8-2020-kb4592449-os-builds-18362-1256-and-18363-1256-c448f3df-a5f1-1d55-aa31-0e1cf7a440a9)을 설치합니다.
### 문제: 잠금을 획득할 수 없습니다. 또 다른 패치 적용 작업이 진행 중입니다.
**문제**: `AWS-RunPatchBaseline` 실행 시, 오류 코드 4와 다음 오류 메시지와 함께 패치가 실패합니다.
```
Cannot acquire lock on C:\ProgramData\Amazon\SSM\patch-baseline-concurrent.lock. Another patching operation is in progress.
```
**원인**: 이 오류는 여러 패치 적용 작업이 동일한 관리형 노드에서 동시에 실행을 시도할 때 발생합니다. 잠금 파일은 동시 패치 작업을 방지하여 충돌을 방지하고 시스템 안정성을 보장합니다.
**해결 방법**: 패치 작업이 동일한 관리형 노드에서 동시에 실행되도록 예약되지 않았는지 확인합니다. 다음 구성을 검토하여 일정 충돌을 식별하고 해결합니다.
+ **패치 정책**: 빠른 설정 패치 정책 구성을 확인하여 다른 패치 적용 일정과 겹치지 않도록 합니다.
+ **유지 관리 기간**: 유지 관리 기간 연결을 검토하여 겹치는 시간대에 여러 기간이 동일한 관리형 노드를 대상으로 패치 작업을 수행하지 않는지 확인합니다.
+ **수동 즉시 패치 작업**: 예약된 패치 적용이 진행되는 동안 수동 **즉시 패치 작업**을 시작하지 마세요.
## macOS에서 `AWS-RunPatchBaseline` 실행 시 오류
**Topics**
+ [문제: 잠금을 획득할 수 없습니다. 또 다른 패치 적용 작업이 진행 중입니다.](#patch-manager-troubleshooting-macos-concurrent-lock)
### 문제: 잠금을 획득할 수 없습니다. 또 다른 패치 적용 작업이 진행 중입니다.
**문제**: `AWS-RunPatchBaseline` 실행 시, 오류 코드 4와 다음 오류 메시지와 함께 패치가 실패합니다.
```
[ERROR]: Cannot acquire lock on /var/log/amazon/ssm/patch-baseline-concurrent.lock. Another patching operation is in progress.
```
**원인**: 이 오류는 여러 패치 적용 작업이 동일한 관리형 노드에서 동시에 실행을 시도할 때 발생합니다. 잠금 파일은 동시 패치 작업을 방지하여 충돌을 방지하고 시스템 안정성을 보장합니다.
**해결 방법**: 패치 작업이 동일한 관리형 노드에서 동시에 실행되도록 예약되지 않았는지 확인합니다. 다음 구성을 검토하여 일정 충돌을 식별하고 해결합니다.
+ **패치 정책**: 빠른 설정 패치 정책 구성을 확인하여 다른 패치 적용 일정과 겹치지 않도록 합니다.
+ **유지 관리 기간**: 유지 관리 기간 연결을 검토하여 겹치는 시간대에 여러 기간이 동일한 관리형 노드를 대상으로 패치 작업을 수행하지 않는지 확인합니다.
+ **수동 즉시 패치 작업**: 예약된 패치 적용이 진행되는 동안 수동 **즉시 패치 작업**을 시작하지 마세요.
## AWS Support Automation 런북 사용
AWS Support는 패치 적용과 관련된 특정 문제를 해결하는 데 사용할 수 있도록 두 개의 Automation 런북을 제공합니다.
+ `AWSSupport-TroubleshootWindowsUpdate` - [https://docs.aws.amazon.com/systems-manager-automation-runbooks/latest/userguide/awssupport-troubleshoot-windows-update.html](https://docs.aws.amazon.com/systems-manager-automation-runbooks/latest/userguide/awssupport-troubleshoot-windows-update.html) 런북은 Amazon Elastic Compute Cloud(Amazon EC2) Windows Server 인스턴스에 대한 Windows Server 업데이트가 실패할 수 있는 문제를 식별하는 데 사용됩니다.
+ `AWSSupport-TroubleshootPatchManagerLinux` - [https://docs.aws.amazon.com/systems-manager-automation-runbooks/latest/userguide/automation-troubleshoot-patch-manager-linux.html](https://docs.aws.amazon.com/systems-manager-automation-runbooks/latest/userguide/automation-troubleshoot-patch-manager-linux.html) 런북은 Patch Manager를 사용하는 Linux 기반 관리형 노드에서 패치 적용 실패의 원인이 될 수 있는 일반적인 문제를 해결합니다. 이 런북의 주요 목표는 패치 명령 실패의 근본 원인을 식별하고 문제 해결 계획을 제안하는 것입니다.
**참고**
Automation 런북을 실행하려면 요금이 부과됩니다. 자세한 내용은 [AWS Systems Manager Automation 요금](https://aws.amazon.com/systems-manager/pricing/#Automation)을 참조하세요.
## AWS Support 문의
이 섹션이나 [AWS re:Post](https://repost.aws/tags/TA-UbbRGVYRWCDaCvae6itYg/aws-systems-manager)의 Systems Manager 개발자 포럼에서 문제 해결 방법을 찾을 수 없고 [Developer, Business 또는 Enterprise 지원 플랜](https://aws.amazon.com/premiumsupport/plans)이 있는 경우 [AWS Support](https://aws.amazon.com/premiumsupport/)에서 기술 지원 사례를 생성할 수 있습니다.
지원에 연락하기 전에 다음 항목을 수집합니다.
+ [SSM Agent 로그](ssm-agent-logs.md)
+ Run Command 명령 ID, 유지 관리 기간 ID 또는 Automation 실행 ID
+ Windows Server 관리형 노드를 위해서는 다음 항목도 수집합니다.
+ [패치 설치 방법](patch-manager-installing-patches.md)의 **Windows** 탭에 설명된 `%PROGRAMDATA%\Amazon\PatchBaselineOperations\Logs`
+ Windows 업데이트 로그: Windows Server 2012 R2 이상의 경우 `%windir%/WindowsUpdate.log`를 사용합니다. Windows Server 2016 이상에서는 `%windir%/WindowsUpdate.log`를 사용하기 전에 먼저 PowerShell 명령 [https://docs.microsoft.com/en-us/powershell/module/windowsupdate/get-windowsupdatelog?view=win10-ps](https://docs.microsoft.com/en-us/powershell/module/windowsupdate/get-windowsupdatelog?view=win10-ps)를 실행합니다.
+ Linux 관리형 노드를 위해서는 다음 항목도 수집합니다.
+ 디렉터리 `/var/lib/amazon/ssm/instance-id/document/orchestration/Run-Command-execution-id/awsrunShellScript/PatchLinux`의 내용
# AWS Systems Manager Run Command
AWS Systems Manager의 도구인 Run Command를 사용하여 관리형 노드의 구성을 원격으로 안전하게 관리할 수 있습니다. **관리형 노드는 Systems Manager용으로 구성된 [하이브리드 및 멀티클라우드](operating-systems-and-machine-types.md#supported-machine-types) 환경의 모든 Amazon Elastic Compute Cloud(Amazon EC2) 인스턴스 또는 비 EC2 시스템입니다. Run Command를 사용하면 일반적인 관리 작업을 자동화하고 대규모로 일회성 구성 변경을 수행할 수 있습니다. AWS Management Console, AWS Command Line Interface(AWS CLI), AWS Tools for Windows PowerShell 또는 AWS SDK에서 Run Command를 사용할 수 있습니다. Run Command는 무료로 제공됩니다. Run Command를 시작하려면 [Systems Manager 콘솔](https://console.aws.amazon.com//systems-manager/run-command)을 엽니다. 탐색 창에서 **Run Command**를 선택합니다.
관리자는 Run Command를 사용하여 부트스트랩 애플리케이션 설치, 배포 파이프라인 구축, Auto Scaling 그룹에서 인스턴스가 제거될 때 로그 파일 캡처, 인스턴스를 Windows 도메인에 조인합니다.
API를 지원하는 시스템의 분산 특성으로 인해 Run Command API는 결과적 일관성 모델을 따릅니다. 이것은 리소스에 영향을 미치는 API 명령을 실행한 결과가 모든 후속 명령에 즉시 표시되지 않을 수 있음을 의미합니다. 이전 API 명령 바로 다음에 API 명령을 실행할 때는 이 점을 염두에 두어야 합니다.
**시작하기**
아래 표에는 Run Command를 처음 사용하는 데 도움이 되는 정보가 나와 있습니다.
****
| 주제 | 세부 정보 |
| --- | --- |
| [AWS Systems Manager에 대한 관리형 노드 설정](systems-manager-setting-up-nodes.md) | [하이브리드 및 멀티클라우드](operating-systems-and-machine-types.md#supported-machine-types) 환경의 Amazon Elastic Compute Cloud(Amazon EC2) 인스턴스 및 비 EC2 시스템에 대한 설정 요구 사항을 완료했는지 확인합니다. |
| [Systems Manager로 하이브리드 및 멀티클라우드 환경에서 노드 관리](systems-manager-hybrid-multicloud.md) | (옵션) Run Command를 사용하여 관리할 수 있도록 온프레미스 서버와 VM을 AWS에 등록합니다. |
| [Systems Manager를 통한 엣지 디바이스 관리](systems-manager-setting-up-edge-devices.md) | (선택 사항) Run Command를 사용하여 관리할 수 있도록 엣지 디바이스를 구성합니다. |
| [관리형 노드에서 명령 실행](running-commands.md) | AWS Management Console을 사용하여 하나 이상의 관리되는 노드를 대상으로 하는 명령을 실행하는 방법에 대해 알아봅니다. |
| [Run Command 연습](run-command-walkthroughs.md) | Tools for Windows PowerShell 또는 AWS CLI를 사용하여 명령을 실행하는 방법에 대해 알아봅니다. |
**EventBridge 지원**
이 Systems Manager 도구는 Amazon EventBridge 규칙에서 *이벤트* 유형과 *대상* 유형으로 모두 지원됩니다. 자세한 내용은 [Amazon EventBridge로 Systems Manager 이벤트 모니터링](monitoring-eventbridge-events.md) 및 [참조: Systems Manager용 Amazon EventBridge 이벤트 패턴 및 유형](reference-eventbridge-events.md) 섹션을 참조하세요.
**추가 정보**
+ [EC2 인스턴스에서 원격으로 Run Command 실행(10분 자습서)](https://aws.amazon.com/getting-started/hands-on/remotely-run-commands-ec2-instance-systems-manager/)
+ **Amazon Web Services 일반 참조의 [Systems Manager 서비스 할당량](https://docs.aws.amazon.com/general/latest/gr/ssm.html#limits_ssm)
+ [AWS Systems Manager API 레퍼런스](https://docs.aws.amazon.com/systems-manager/latest/APIReference/)
**Topics**
+ [Run Command 설정](run-command-setting-up.md)
+ [관리형 노드에서 명령 실행](running-commands.md)
+ [명령에 종료 코드 사용](run-command-handle-exit-status.md)
+ [명령 상태 이해](monitor-commands.md)
+ [Run Command 연습](run-command-walkthroughs.md)
+ [Systems Manager Run Command 문제 해결](troubleshooting-remote-commands.md)
# Run Command 설정
AWS Systems Manager의 도구인 Run Command를 사용하여 노드를 관리하려면 먼저 명령을 실행할 사용자에 대해 AWS Identity and Access Management(IAM) 정책을 구성합니다. IAM 정책에서 `SendCommand` 작업에 글로벌 조건 키를 사용하는 경우 `aws:ViaAWSService` 조건 키를 포함하고 부울 값을 `true`로 설정해야 합니다. 다음은 예입니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ssm:SendCommand"
],
"Resource": [
"arn:aws:ssm:us-east-1:111122223333:document/YourDocument"
],
"Condition": {
"StringEquals": {
"aws:SourceVpce": [
"vpce-1234567890abcdef0"
]
}
}
},
{
"Effect": "Allow",
"Action": [
"ssm:SendCommand"
],
"Resource": [
"arn:aws:ssm:us-east-1:111122223333:document/YourDocument"
],
"Condition": {
"Bool": {
"aws:ViaAWSService": "true"
}
}
}
]
}
```
------
Systems Manager에 대한 노드를 구성해야 합니다. 자세한 내용은 [AWS Systems Manager에 대한 관리형 노드 설정](systems-manager-setting-up-nodes.md) 섹션을 참조하세요.
또한 다음과 같은 선택적 설정 작업을 완료하여 관리형 노드의 보안 상태 및 일상적인 관리를 최소화하는 것이 좋습니다.
Amazon EventBridge를 사용하여 명령 실행 모니터링
EventBridge를 사용하여 명령 실행 상태 변경 사항을 기록할 수 있습니다. 상태가 달라질 때마다 또는 관심이 있는 상태로 변경될 때 실행되는 규칙을 만들면 됩니다. EventBridge 이벤트가 발생할 때 Run Command를 대상 작업으로 지정할 수도 있습니다. 자세한 내용은 [Systems Manager 이벤트에 대해 EventBridge 구성](monitoring-systems-manager-events.md) 섹션을 참조하세요.
Amazon CloudWatch Logs를 사용하여 명령 실행 모니터링
모든 명령 출력 및 오류 로그를 정기적으로 Amazon CloudWatch 로그 그룹에 보내도록 Run Command를 구성할 수 있습니다. 거의 실시간으로 이러한 출력 로그를 모니터링하고, 특정 구문, 값 또는 패턴을 검색하며, 검색을 기반으로 경보를 생성할 수 있습니다. 자세한 내용은 [Run Command에 대한 Amazon CloudWatch Logs 구성](sysman-rc-setting-up-cwlogs.md) 섹션을 참조하세요.
특정 관리형 노드 Run Command 액세스 제한
AWS Identity and Access Management(IAM)을 사용하여 관리되는 노드에서 명령을 실행하는 사용자의 기능을 제한할 수 있습니다. 특히 사용자가 특정 태그에 지정된 관리형 노드에서만 명령을 실행할 수 있도록 하는 조건이 포함된 IAM 정책을 생성할 수 있습니다. 자세한 내용은 [태그를 기반으로 Run Command 액세스 제한](#tag-based-access) 섹션을 참조하세요.
## 태그를 기반으로 Run Command 액세스 제한
이 섹션에서는 IAM 정책에서 태그 조건을 지정하여 관리형 노드에서 명령을 실행하는 사용자의 기능을 제한하는 방법에 대해 설명합니다. 관리형 노드에는 Systems Manager용으로 구성된 [하이브리드 및 멀티클라우드](operating-systems-and-machine-types.md#supported-machine-types) 환경의 Amazon EC2 인스턴스 및 비 EC2 노드가 포함됩니다. 정보가 명시적으로 표시되지 않지만 관리형 AWS IoT Greengrass 코어 디바이스에 대한 액세스를 제한할 수도 있습니다. 시작하려면 AWS IoT Greengrass 디바이스에 태그를 지정해야 합니다. 자세한 내용은 *AWS IoT Greengrass Version 2 개발자 안내서*에서 [AWS IoT Greengrass Version 2 리소스 태그하기](https://docs.aws.amazon.com/greengrass/v2/developerguide/tag-resources.html) 섹션을 참조하세요.
사용자가 특정 태그에 지정된 관리형 노드에 대해서만 명령을 실행할 수 있도록 하는 조건이 포함된 IAM 정책을 생성하여 명령 실행을 특정 노드로 제한할 수 있습니다. 다음 예에서 사용자는 노드가 Finance WebServer(`ssm:resourceTag/Finance: WebServer`)인 상태에서 노드(`Resource: arn:aws:ec2:*:*:instance/*`)의 SSM 문서(`Resource: arn:aws:ssm:*:*:document/*`)를 통해 Run Command(`Effect: Allow, Action: ssm:SendCommand`)를 사용할 수 있습니다. 사용자가 태그 지정되지 않았거나 `Finance: WebServer` 이외의 태그가 있는 노드에 명령을 보내는 경우 실행 결과는 `AccessDenied`로 표시됩니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement":[
{
"Effect":"Allow",
"Action":[
"ssm:SendCommand"
],
"Resource":[
"arn:aws:ssm:*:*:document/*"
]
},
{
"Effect":"Allow",
"Action":[
"ssm:SendCommand"
],
"Resource":[
"arn:aws:ec2:*:*:instance/*"
],
"Condition":{
"StringLike":{
"ssm:resourceTag/Finance":[
"WebServers"
]
}
}
}
]
}
```
------
사용자가 여러 태그로 지정된 관리형 노드에 대해 명령을 실행하도록 허용하는 IAM 정책을 생성할 수 있습니다. 다음 정책은 두 태그를 포함하는 관리형 노드에서 사용자가 명령을 실행하도록 허용합니다. 사용자가 두 태그 모두에 지정되지 않은 노드에 명령을 전송할 경우 실행 결과가 `AccessDenied`로 표시됩니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement":[
{
"Effect":"Allow",
"Action":[
"ssm:SendCommand"
],
"Resource":"*",
"Condition":{
"StringLike":{
"ssm:resourceTag/tag_key1":[
"tag_value1"
],
"ssm:resourceTag/tag_key2":[
"tag_value2"
]
}
}
},
{
"Effect":"Allow",
"Action":[
"ssm:SendCommand"
],
"Resource":[
"arn:aws:ssm:us-west-1::document/AWS-*",
"arn:aws:ssm:us-east-2::document/AWS-*"
]
},
{
"Effect":"Allow",
"Action":[
"ssm:UpdateInstanceInformation",
"ssm:ListCommands",
"ssm:ListCommandInvocations",
"ssm:GetDocument"
],
"Resource":"*"
}
]
}
```
------
사용자가 여러 태그로 지정된 관리형 노드 그룹에 대해 명령을 실행하도록 허용하는 IAM 정책을 생성할 수도 있습니다. 다음 정책 예시는 태그 지정된 노드 그룹 중 하나 또는 두 그룹 모두에 대해 명령을 실행하도록 허용합니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement":[
{
"Effect":"Allow",
"Action":[
"ssm:SendCommand"
],
"Resource":"*",
"Condition":{
"StringLike":{
"ssm:resourceTag/tag_key1":[
"tag_value1"
]
}
}
},
{
"Effect":"Allow",
"Action":[
"ssm:SendCommand"
],
"Resource":"*",
"Condition":{
"StringLike":{
"ssm:resourceTag/tag_key2":[
"tag_value2"
]
}
}
},
{
"Effect":"Allow",
"Action":[
"ssm:SendCommand"
],
"Resource":[
"arn:aws:ssm:us-west-1::document/AWS-*",
"arn:aws:ssm:us-east-2::document/AWS-*"
]
},
{
"Effect":"Allow",
"Action":[
"ssm:UpdateInstanceInformation",
"ssm:ListCommands",
"ssm:ListCommandInvocations",
"ssm:GetDocument"
],
"Resource":"*"
}
]
}
```
------
IAM 정책 생성에 대한 자세한 내용은 **IAM 사용 설명서의 [관리형 정책과 인라인 정책](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html)을 참조하세요. 관리형 노드 태그 지정에 대한 자세한 내용은 *AWS Resource Groups 사용 설명서의 *[태그 에디터](https://docs.aws.amazon.com/ARG/latest/userguide/tag-editor.html)를 참조하세요.
# 관리형 노드에서 명령 실행
이 섹션에는 AWS Systems Manager 콘솔에서 관리형 노드로 명령을 전송하는 방법에 대한 정보가 포함되어 있습니다. 이 단원에는 명령을 취소하는 방법에 대한 정보도 나와 있습니다.
노드가 var 디렉터리에 대한 `noexec` 탑재 옵션으로 구성된 경우 Run Command는 명령을 성공적으로 실행할 수 없습니다.
**중요**
Run Command를 사용해 명령을 보낼 때 암호, 구성 데이터 또는 기타 보안 암호와 같이 민감한 정보는 일반 텍스트 형식으로 포함하지 않습니다. 계정의 모든 Systems Manager API 활동은 AWS CloudTrail 로그를 위해 S3 버킷에 기록됩니다. 즉, 해당 S3 버킷에 대한 액세스 권한이 있는 사용자는 그러한 보안 암호의 일반 텍스트 값을 볼 수 있습니다. 따라서 `SecureString` 파라미터를 생성하고 사용하여 Systems Manager 작업에 사용하는 민감한 데이터를 암호화하는 것이 좋습니다.
자세한 내용은 [IAM 정책을 사용하여 Parameter Store 파라미터에 대한 액세스 제한](sysman-paramstore-access.md) 섹션을 참조하세요.
**실행 이력 유지**
각 명령의 기록은 최대 30일 동안 사용할 수 있습니다. 또한 모든 로그 파일의 사본을 Amazon Simple Storage Service에 저장하거나 모든 API 직접 호출의 감사 추적을 AWS CloudTrail에서 보유할 수 있습니다.
**관련 정보**
다른 도구를 사용하여 명령을 전송하는 방법에 대한 자세한 내용은 아래 주제를 참조하세요.
+ [연습: Run Command에서 AWS Tools for Windows PowerShell 사용](walkthrough-powershell.md) 또는 [AWS Tools for PowerShell Cmdlet Reference의 AWS Systems Manager 섹션](https://docs.aws.amazon.com/powershell/latest/reference/items/AWS_Systems_Manager_cmdlets.html)에 있는 예제
+ [연습: Run Command에서 AWS CLI 사용](walkthrough-cli.md) 또는 [SSM CLI Reference](https://docs.aws.amazon.com/cli/latest/reference/ssm/)의 예제
**Topics**
+ [콘솔에서 명령 실행](running-commands-console.md)
+ [특정 문서 버전을 사용하여 명령 실행](run-command-version.md)
+ [대규모로 명령 실행](send-commands-multiple.md)
+ [명령 취소](cancel-run-command.md)
# 콘솔에서 명령 실행
AWS Management Console에서 AWS Systems Manager의 도구인 Run Command를 사용하여 로그인하지 않고도 관리형 노드를 구성할 수 있습니다. 이 주제에는 Run Command를 사용하여 관리형 노드에서 [SSM Agent를 업데이트](run-command-tutorial-update-software.md#rc-console-agentexample)하는 방법을 보여주는 예가 포함되어 있습니다.
**시작하기 전 준비 사항**
Run Command를 사용하여 명령을 보내기 전에 관리형 노드에서 모든 Systems Manager [설정 요구 사항](systems-manager-setting-up-nodes.md)을 충족하는지 확인합니다.
**Run Command를 사용하여 명령을 전송하려면**
1. AWS Systems Manager 콘솔([https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/))을 엽니다.
1. 탐색 창에서 **Run Command**를 선택합니다.
1. **Run command**(Run 명령)를 선택합니다.
1. **Command 문서(Command document)** 목록에서 Systems Manager 문서를 선택합니다.
1. **명령 파라미터** 섹션에서 필요한 파라미터의 값을 지정합니다.
1. **Targets**(대상) 섹션에서, 태그를 지정하거나, 수동으로 인스턴스나 엣지 디바이스를 선택하거나, 리소스 그룹을 지정하여 이 작업을 실행할 관리형 노드를 식별합니다.
**작은 정보**
예상한 관리형 노드가 목록에 없으면 [관리형 노드 가용성 문제 해결](fleet-manager-troubleshooting-managed-nodes.md)에서 문제 해결 팁을 참조하세요.
1. **Other parameters**(다른 파라미터):
+ **Comment**(설명)에 명령에 대한 정보를 입력합니다.
+ **제한 시간(초)**에서 전체 명령 실행이 실패할 때까지 시스템이 기다리는 시간을 초 단위로 지정합니다.
1. **Rate control**(속도 제어)에서
+ **Concurrency**(동시성)에서 명령을 동시에 실행할 관리형 노드의 백분율 또는 개수를 지정합니다.
**참고**
관리형 노드에 적용할 태그를 지정하거나, AWS 리소스 그룹을 지정하여 대상을 선택하였지만 대상으로 지정할 관리형 노드 수를 잘 모를 경우에는 백분율을 지정하여 동시에 문서를 실행할 수 있는 대상 수를 제한합니다.
+ **Error threshold**(오류 임계값)에서, 명령이 노드의 개수 또는 백분율에서 실패한 후 다른 관리형 노드에서 해당 명령의 실행을 중지할 시간을 지정합니다. 예를 들어 세 오류를 지정하면 네 번째 오류를 받았을 때 Systems Manager가 명령 전송을 중지합니다. 여전히 명령을 처리 중인 관리형 노드도 오류를 전송할 수 있습니다.
1. (선택 사항) 모니터링을 위해 명령에 적용할 CloudWatch 경보를 선택합니다. CloudWatch 경보를 명령에 연결하려면 명령을 실행하는 IAM 보안 주체에 `iam:createServiceLinkedRole` 작업에 대한 권한이 있어야 합니다. CloudWatch 경보에 대한 자세한 내용은 [Amazon CloudWatch 경보 사용](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)을 참조하세요. 경보가 활성화되면 보류 중인 명령 호출이 실행되지 않습니다.
1. (선택 사항) **Output options**(출력 옵션)에서 명령 출력을 파일에 저장하려면 **Write command output to an S3 bucket**(S3 버킷에 명령 출력 쓰기) 상자를 선택합니다. 상자에 버킷 및 접두사(폴더) 이름을 입력합니다.
**참고**
데이터를 S3 버킷에 쓰는 기능을 부여하는 S3 권한은 이 작업을 수행하는 IAM 사용자의 권한이 아니라 인스턴스에 할당된 인스턴스 프로파일(EC2 인스턴스용) 또는 IAM 서비스 역할(하이브리드 정품 인증 시스템)의 권한입니다. 자세한 내용은 [Systems Manager에 필요한 인스턴스 권한 구성](setup-instance-permissions.md)이나 [하이브리드 환경을 위한 IAM 서비스 역할 생성](hybrid-multicloud-service-role.md)을 참조하세요. 또한 지정된 S3 버킷이 다른 AWS 계정에 있는 경우 관리형 노드와 연결된 인스턴스 프로파일 또는 IAM 서비스 역할은 해당 버킷에 쓸 수 있는 권한이 있어야 합니다.
1. **SNS notifications**(SNS 알림) 섹션에서, 명령 실행 상태에 대한 알림이 전송되도록 하려면 **Enable SNS notifications**(SNS 알림 활성화) 확인란을 선택합니다.
Run Command에 대한 Amazon SNS 알림 구성에 대한 자세한 내용은 [Amazon SNS 알림을 사용하여 Systems Manager 상태 변경 모니터링](monitoring-sns-notifications.md) 섹션을 참조하세요.
1. **Run**(실행)을 선택합니다.
명령을 취소하는 방법에 대한 자세한 내용은 [명령 취소](cancel-run-command.md) 섹션을 참조하세요.
## 명령 실행
Systems Manager에는 Systems Manager 콘솔의 **Run Command** 페이지에서 명령을 다시 실행하는 2가지 옵션이 있습니다.
+ **Rerun(다시 실행)**: 이 버튼을 사용하면 명령을 변경하지 않고 동일한 명령을 실행할 수 있습니다.
+ **새로 복사(Copy to new)**: 이 버튼은 한 명령의 설정을 새 명령으로 복사하고 실행하기 전에 해당 설정을 편집할 수 있는 옵션을 제공합니다.
**명령을 다시 실행하려면**
1. AWS Systems Manager 콘솔([https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/))을 엽니다.
1. 탐색 창에서 **Run Command**를 선택합니다.
1. 다시 실행할 명령을 선택합니다. 명령 세부 정보 페이지에서 명령을 실행한 직후 명령을 다시 실행할 수 있습니다. 또는 **명령 기록(Command history)** 탭에서 이전에 실행한 명령을 선택할 수 있습니다.
1. **Rerun(다시 실행)**을 선택하여 동일한 명령을 변경 없이 실행하거나, 명령을 실행하기 전에 **새로 복사**를 선택하여 명령 설정을 편집합니다.
# 특정 문서 버전을 사용하여 명령 실행
문서 버전 파라미터를 사용하여 명령 실행 시 사용할 AWS Systems Manager 문서 버전을 지정할 수 있습니다. 이 파라미터에는 다음 옵션 중 하나를 지정할 수 있습니다.
+ \$1DEFAULT
+ \$1LATEST
+ 버전 번호
문서 버전 파라미터를 실행하여 명령을 실행하려면 다음 절차를 사용합니다.
------
#### [ Linux ]
**로컬 Linux 시스템에서 AWS CLI를 사용하여 명령을 실행하려면**
1. 아직 하지 않은 경우 AWS Command Line Interface(AWS CLI)을 설치하고 구성합니다.
자세한 내용은 [최신 버전의 AWS CLI 설치 또는 업데이트](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html)를 참조하세요.
1. 사용할 수 있는 모든 문서 나열
이 명령을 실행하면 AWS Identity and Access Management(IAM) 권한에 따라 계정에 사용할 수 있는 문서를 모두 나열합니다.
```
aws ssm list-documents
```
1. 다음 명령을 실행하여 문서의 여러 버전을 확인합니다. *document name*을 사용자의 정보로 바꿉니다.
```
aws ssm list-document-versions \
--name "document name"
```
1. 다음 명령을 실행하여 SSM 문서 버전을 사용하는 명령을 실행합니다. 각 *example resource placeholder*를 사용자의 정보로 바꿉니다.
```
aws ssm send-command \
--document-name "AWS-RunShellScript" \
--parameters commands="echo Hello" \
--instance-ids instance-ID \
--document-version '$LATEST'
```
------
#### [ Windows ]
**로컬 Windows 시스템에서 AWS CLI를 사용하여 명령을 실행하려면**
1. 아직 하지 않은 경우 AWS Command Line Interface(AWS CLI)을 설치하고 구성합니다.
자세한 내용은 [최신 버전의 AWS CLI 설치 또는 업데이트](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html)를 참조하세요.
1. 사용할 수 있는 모든 문서 나열
이 명령을 실행하면 AWS Identity and Access Management(IAM) 권한에 따라 계정에 사용할 수 있는 문서를 모두 나열합니다.
```
aws ssm list-documents
```
1. 다음 명령을 실행하여 문서의 여러 버전을 확인합니다. *document name*을 사용자의 정보로 바꿉니다.
```
aws ssm list-document-versions ^
--name "document name"
```
1. 다음 명령을 실행하여 SSM 문서 버전을 사용하는 명령을 실행합니다. 각 *example resource placeholder*를 사용자의 정보로 바꿉니다.
```
aws ssm send-command ^
--document-name "AWS-RunShellScript" ^
--parameters commands="echo Hello" ^
--instance-ids instance-ID ^
--document-version "$LATEST"
```
------
#### [ PowerShell ]
**Tools for PowerShell을 사용하여 명령을 실행하려면**
1. 아직 설치하지 않은 경우 AWS Tools for PowerShell(Tools for Windows PowerShell)을 설치하고 구성합니다.
자세한 내용은 [AWS Tools for PowerShell 설치](https://docs.aws.amazon.com/powershell/latest/userguide/pstools-getting-set-up.html)를 참조하세요.
1. 사용할 수 있는 모든 문서 나열
이 명령을 실행하면 AWS Identity and Access Management(IAM) 권한에 따라 계정에 사용할 수 있는 문서를 모두 나열합니다.
```
Get-SSMDocumentList
```
1. 다음 명령을 실행하여 문서의 여러 버전을 확인합니다. *document name*을 사용자의 정보로 바꿉니다.
```
Get-SSMDocumentVersionList `
-Name "document name"
```
1. 다음 명령을 실행하여 SSM 문서 버전을 사용하는 명령을 실행합니다. 각 *example resource placeholder*를 사용자의 정보로 바꿉니다.
```
Send-SSMCommand `
-DocumentName "AWS-RunShellScript" `
-Parameter @{commands = "echo helloWorld"} `
-InstanceIds "instance-ID" `
-DocumentVersion $LATEST
```
------
# 대규모로 명령 실행
AWS Systems Manager의 도구인 Run Command에서는 `targets`를 사용하여 관리형 노드의 플릿에 대해 명령을 실행할 수 있습니다. `targets` 파라미터는 관리형 노드에 대해 지정한 태그를 바탕으로 `Key,Value` 조합을 허용합니다. 명령을 실행하면 시스템에서 지정된 태그와 일치하는 모든 관리형 노드를 찾아 이러한 인스턴스에 대해 명령 실행을 시도합니다. 관리형 인스턴스의 태그 지정에 대한 자세한 내용은 **AWS 리소스 태그 지정 사용 설명서의 [AWS 리소스 태그 지정](https://docs.aws.amazon.com/tag-editor/latest/userguide/tag-editor.html)을 참조하세요. 관리형 IoT 디바이스 태그 지정에 대한 자세한 내용은 *AWS IoT Greengrass Version 2개발자 안내서*의 [AWS IoT Greengrass Version 2 리소스 태그하기](https://docs.aws.amazon.com/greengrass/v2/developerguide/tag-resources.html) 섹션을 참조하세요.
다음 섹션에 설명된 대로 `targets` 파라미터를 사용하여 특정 관리형 노드 ID 목록을 대상으로 지정할 수도 있습니다.
수백 또는 수천 개의 관리형 노드에 걸쳐 명령 실행을 제어할 수 있도록 Run Command에는 하나의 요청을 동시에 처리할 수 있는 노드의 수와 명령이 취소되기 전에 명령에서 발생시킬 수 있는 오류의 수를 제한하기 위한 파라미터가 포함되어 있습니다.
**Topics**
+ [다중 관리형 노드 대상 지정](#send-commands-targeting)
+ [비율 제어 사용](#send-commands-rate)
## 다중 관리형 노드 대상 지정
태그, AWS 리소스 그룹 이름, 또는 관리형 노드 ID를 지정하여 명령 및 대상 관리 노드를 실행할 수 있습니다.
다음 예시에서는 AWS Command Line Interface(AWS CLI)에서 Run Command를 사용할 경우의 명령 형식을 보여줍니다. *example resource placeholder*를 사용자의 정보로 바꿉니다. 이번 단원의 샘플 명령은 `[...]`를 사용해 잘립니다.
**예제 1: 태그를 대상으로 지정**
------
#### [ Linux & macOS ]
```
aws ssm send-command \
--document-name document-name \
--targets Key=tag:tag-name,Values=tag-value \
[...]
```
------
#### [ Windows ]
```
aws ssm send-command ^
--document-name document-name ^
--targets Key=tag:tag-name,Values=tag-value ^
[...]
```
------
**예제 2: AWS 리소스 그룹을 대상으로 지정**
명령 한 번마다 지정할 수 있는 리소스 그룹 이름은 최대 1개입니다. 리소스 그룹을 생성할 때는 그룹화 기준에서 `AWS::SSM:ManagedInstance`와 `AWS::EC2::Instance`를 리소스 유형으로 추가하는 것이 좋습니다.
**참고**
리소스 그룹을 대상으로 지정하는 명령을 전송하려면 먼저 해당 그룹에 속한 리소스를 나열하거나 볼 수 있는 AWS Identity and Access Management(IAM) 권한을 부여해야 합니다. 자세한 내용은 *AWS Resource Groups 사용 설명서*의 [권한 설정](https://docs.aws.amazon.com/ARG/latest/userguide/gettingstarted-prereqs.html#gettingstarted-prereqs-permissions)을 참조하세요.
------
#### [ Linux & macOS ]
```
aws ssm send-command \
--document-name document-name \
--targets Key=resource-groups:Name,Values=resource-group-name \
[...]
```
------
#### [ Windows ]
```
aws ssm send-command ^
--document-name document-name ^
--targets Key=resource-groups:Name,Values=resource-group-name ^
[...]
```
------
**예제 3: 리소스 유형별로 AWS 리소스 그룹 태그 지정**
명령 한 번마다 지정할 수 있는 리소스 그룹 유형은 최대 5개입니다. 리소스 그룹을 생성할 때는 그룹화 기준에서 `AWS::SSM:ManagedInstance`와 `AWS::EC2::Instance`를 리소스 유형으로 추가하는 것이 좋습니다.
**참고**
리소스 그룹을 대상으로 지정하는 명령을 전송하려면 먼저 해당 그룹에 속한 리소스를 나열하거나 볼 수 있는 IAM 권한을 부여해야 합니다. 자세한 내용은 *AWS Resource Groups 사용 설명서*의 [권한 설정](https://docs.aws.amazon.com/ARG/latest/userguide/gettingstarted-prereqs.html#gettingstarted-prereqs-permissions)을 참조하세요.
------
#### [ Linux & macOS ]
```
aws ssm send-command \
--document-name document-name \
--targets Key=resource-groups:ResourceTypeFilters,Values=resource-type-1,resource-type-2 \
[...]
```
------
#### [ Windows ]
```
aws ssm send-command ^
--document-name document-name ^
--targets Key=resource-groups:ResourceTypeFilters,Values=resource-type-1,resource-type-2 ^
[...]
```
------
**예제 4: 인스턴스 ID를 대상으로 지정**
다음 예에서는 `instanceids` 키와 `targets` 파라미터를 사용하여 관리형 노드를 대상으로 지정하는 방법을 보여줍니다. 각 디바이스에 mi-*ID\$1number*가 지정되어 있기 때문에 이 키를 사용하여 관리형 AWS IoT Greengrass 코어 디바이스를 대상으로 지정할 수 있습니다. AWS Systems Manager의 도구인 Fleet Manager에서 디바이스 ID를 볼 수 있습니다.
------
#### [ Linux & macOS ]
```
aws ssm send-command \
--document-name document-name \
--targets Key=instanceids,Values=instance-ID-1,instance-ID-2,instance-ID-3 \
[...]
```
------
#### [ Windows ]
```
aws ssm send-command ^
--document-name document-name ^
--targets Key=instanceids,Values=instance-ID-1,instance-ID-2,instance-ID-3 ^
[...]
```
------
`Environment`라는 `Key`와 `Development`, `Test`, `Pre-production` 및 `Production`의 `Values`를 사용하여 다양한 환경에 대해 관리형 노드에 태그를 지정한 경우에는 다음 구문과 함께 `targets` 파라미터를 사용해 이러한 환경 중 *하나*의 모든 관리형 노드로 명령을 보낼 수 있습니다.
------
#### [ Linux & macOS ]
```
aws ssm send-command \
--document-name document-name \
--targets Key=tag:Environment,Values=Development \
[...]
```
------
#### [ Windows ]
```
aws ssm send-command ^
--document-name document-name ^
--targets Key=tag:Environment,Values=Development ^
[...]
```
------
`Values` 목록에 추가하여 다른 환경의 추가 관리형 노드를 대상으로 지정할 수 있습니다. 쉼표를 사용하여 항목을 구분합니다.
------
#### [ Linux & macOS ]
```
aws ssm send-command \
--document-name document-name \
--targets Key=tag:Environment,Values=Development,Test,Pre-production \
[...]
```
------
#### [ Windows ]
```
aws ssm send-command ^
--document-name document-name ^
--targets Key=tag:Environment,Values=Development,Test,Pre-production ^
[...]
```
------
**번형**: `Key` 기준을 여러 개 사용하여 대상 세분화
`Key` 조건을 여러 개 포함시켜 명령의 대상 수를 세분화할 수 있습니다. `Key` 조건을 두 개 이상 포함시키면 시스템에서 *모든* 조건을 충족하는 관리형 노드를 대상으로 지정합니다. 다음 명령은 재무 부서에 대해 태그가 지정되고 *또한* 데이터베이스 서버 역할에 대해 태그가 지정된 모든 관리형 노드를 대상으로 지정합니다.
------
#### [ Linux & macOS ]
```
aws ssm send-command \
--document-name document-name \
--targets Key=tag:Department,Values=Finance Key=tag:ServerRole,Values=Database \
[...]
```
------
#### [ Windows ]
```
aws ssm send-command ^
--document-name document-name ^
--targets Key=tag:Department,Values=Finance Key=tag:ServerRole,Values=Database ^
[...]
```
------
**번형**: 여러 `Key` 및 `Value` 기준 사용
앞의 예제를 확장해 `Values` 조건에 항목을 추가로 포함시켜 여러 부서 및 여러 서버 역할을 대상으로 지정할 수 있습니다.
------
#### [ Linux & macOS ]
```
aws ssm send-command \
--document-name document-name \
--targets Key=tag:Department,Values=Finance,Marketing Key=tag:ServerRole,Values=WebServer,Database \
[...]
```
------
#### [ Windows ]
```
aws ssm send-command ^
--document-name document-name ^
--targets Key=tag:Department,Values=Finance,Marketing Key=tag:ServerRole,Values=WebServer,Database ^
[...]
```
------
**번형**: 여러 `Values` 기준을 사용하여 태그가 지정된 관리형 노드를 대상으로 지정
`Department`라는 `Key`와 `Sales`, `Finance`의 `Values`를 사용하여 다양한 환경에 대해 관리형 노드에 태그를 지정한 경우에는 다음 구문과 함께 `targets` 파라미터를 사용해 이러한 환경의 모든 노드로 명령을 보낼 수 있습니다.
------
#### [ Linux & macOS ]
```
aws ssm send-command \
--document-name document-name \
--targets Key=tag:Department,Values=Sales,Finance \
[...]
```
------
#### [ Windows ]
```
aws ssm send-command ^
--document-name document-name ^
--targets Key=tag:Department,Values=Sales,Finance ^
[...]
```
------
최대 5개의 키와 각 키에 대해 5개의 값을 지정할 수 있습니다.
태그 키(태그 이름) 또는 태그 값에 공백이 포함된 경우 다음 예와 같이 태그 키 또는 값을 인용 부호로 묶습니다.
**예**: `Value` 태그의 공백
------
#### [ Linux & macOS ]
```
aws ssm send-command \
--document-name document-name \
--targets Key=tag:OS,Values="Windows Server 2016" \
[...]
```
------
#### [ Windows ]
```
aws ssm send-command ^
--document-name document-name ^
--targets Key=tag:OS,Values="Windows Server 2016" ^
[...]
```
------
**예**: `tag` 키 및 `Value`의 공백
------
#### [ Linux & macOS ]
```
aws ssm send-command \
--document-name document-name \
--targets Key="tag:Operating System",Values="Windows Server 2016" \
[...]
```
------
#### [ Windows ]
```
aws ssm send-command ^
--document-name document-name ^
--targets Key="tag:Operating System",Values="Windows Server 2016" ^
[...]
```
------
**예**: `Values` 목록에서 한 항목의 공백
------
#### [ Linux & macOS ]
```
aws ssm send-command \
--document-name document-name \
--targets Key=tag:Department,Values="Sales","Finance","Systems Mgmt" \
[...]
```
------
#### [ Windows ]
```
aws ssm send-command ^
--document-name document-name ^
--targets Key=tag:Department,Values="Sales","Finance","Systems Mgmt" ^
[...]
```
------
## 비율 제어 사용
*동시성 제어*와 *오류 제어*를 사용하여 그룹의 관리형 노드로 명령이 전송되는 비율을 제어할 수 있습니다.
**Topics**
+ [동시성 제어 사용](#send-commands-velocity)
+ [오류 제어 사용](#send-commands-maxerrors)
### 동시성 제어 사용
`max-concurrency` 파라미터(**Run a command**(명령 실행) 페이지의 **Concurrency**(동시성) 옵션))로 명령을 동시에 실행하는 관리형 노드의 수를 제어할 수 있습니다. 관리형 노드의 절대 개수(예: **10**)를 지정하거나 대상 집합의 비율(예: **10%**)을 지정할 수 있습니다. 대기 중인 시스템은 단일 노드에 명령을 전송하고 시스템이 초기 호출을 승인할 때까지 기다렸다가 명령을 2개 더 많은 노드에 보냅니다. 시스템은 시스템이 `max-concurrency` 값을 충족할 때까지 기하급수적으로 더 많은 노드에 명령을 보냅니다. `max-concurrency`의 기본값은 50입니다. 다음 예는 `max-concurrency` 파라미터에 대한 값을 지정하는 방법을 보여줍니다.
------
#### [ Linux & macOS ]
```
aws ssm send-command \
--document-name document-name \
--max-concurrency 10 \
--targets Key=tag:Environment,Values=Development \
[...]
```
```
aws ssm send-command \
--document-name document-name \
--max-concurrency 10% \
--targets Key=tag:Department,Values=Finance,Marketing Key=tag:ServerRole,Values=WebServer,Database \
[...]
```
------
#### [ Windows ]
```
aws ssm send-command ^
--document-name document-name ^
--max-concurrency 10 ^
--targets Key=tag:Environment,Values=Development ^
[...]
```
```
aws ssm send-command ^
--document-name document-name ^
--max-concurrency 10% ^
--targets Key=tag:Department,Values=Finance,Marketing Key=tag:ServerRole,Values=WebServer,Database ^
[...]
```
------
### 오류 제어 사용
`max-errors` 파라미터(**명령 실행** 페이지의 **오류 임계값(Error threshold)** 필드)로 오류 제한을 설정하여 수백 또는 수천 개의 관리형 노드에 대한 명령 실행을 제어할 수도 있습니다. 이 파라미터는 시스템이 추가 관리형 노드로의 명령 전송을 중지하기까지 허용되는 오류 횟수를 지정합니다. 오류의 절대 개수(예: **10**)를 지정하거나 대상 집합의 비율(예: **10%**)을 지정할 수 있습니다. 예를 들어 **3**을 지정하면 네 번째 오류를 받았을 때 명령 전송이 중지됩니다. **0**을 지정하면 첫 번째 오류 결과가 반환된 후 추가 관리형 노드로의 명령 전송이 중지됩니다. 50개의관리형 노드로 명령을 보내고 `max-errors`을 **10%**로 설정하면 여섯 번째 오류를 받았을 때 추가 노드로의 명령 전송이 중지됩니다.
`max-errors`에 도달할 때 이미 명령을 실행 중인 호출은 완료될 수 있지만, 이런 호출 중 일부는 실패할 수도 있습니다. 실패한 호출 수가 `max-errors`보다 많지 않도록 해야 할 경우에는 호출이 한 번에 한 개를 초과하지 않도록 `max-concurrency`를 **1**로 설정하십시오. max-errors의 기본값은 0입니다. 다음 예는 `max-errors` 파라미터에 대한 값을 지정하는 방법을 보여줍니다.
------
#### [ Linux & macOS ]
```
aws ssm send-command \
--document-name document-name \
--max-errors 10 \
--targets Key=tag:Database,Values=Development \
[...]
```
```
aws ssm send-command \
--document-name document-name \
--max-errors 10% \
--targets Key=tag:Environment,Values=Development \
[...]
```
```
aws ssm send-command \
--document-name document-name \
--max-concurrency 1 \
--max-errors 1 \
--targets Key=tag:Environment,Values=Production \
[...]
```
------
#### [ Windows ]
```
aws ssm send-command ^
--document-name document-name ^
--max-errors 10 ^
--targets Key=tag:Database,Values=Development ^
[...]
```
```
aws ssm send-command ^
--document-name document-name ^
--max-errors 10% ^
--targets Key=tag:Environment,Values=Development ^
[...]
```
```
aws ssm send-command ^
--document-name document-name ^
--max-concurrency 1 ^
--max-errors 1 ^
--targets Key=tag:Environment,Values=Production ^
[...]
```
------
# 명령 취소
서비스에 명령이 보류 중 또는 실행 중 상태로 표시되는 경우 명령을 취소할 수 있습니다. 그러나 명령이 그러한 상태 중 하나인 경우에도 명령이 취소되고 기본 프로세스가 중지되는 것을 보장할 수 없습니다.
**콘솔을 사용하여 명령을 취소하려면**
1. AWS Systems Manager 콘솔([https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/))을 엽니다.
1. 탐색 창에서 **Run Command**를 선택합니다.
1. 취소하고 싶은 명령 호출을 선택합니다.
1. **명령 취소**를 선택합니다.
**AWS CLI를 사용하여 명령을 취소하려면**
다음 명령을 실행합니다. 각 *example resource placeholder*를 사용자의 정보로 바꿉니다.
------
#### [ Linux & macOS ]
```
aws ssm cancel-command \
--command-id "command-ID" \
--instance-ids "instance-ID"
```
------
#### [ Windows ]
```
aws ssm cancel-command ^
--command-id "command-ID" ^
--instance-ids "instance-ID"
```
------
취소된 명령의 상태에 대한 자세한 내용은 [명령 상태 이해](monitor-commands.md) 섹션을 참조하세요.
# 명령에 종료 코드 사용
경우에 따라 종료 코드를 사용하여 명령을 처리하는 방법을 관리해야 할 수도 있습니다.
## 명령에 종료 코드 지정
AWS Systems Manager의 도구인 Run Command를 사용하여 종료 코드를 지정함으로써 명령 처리 방법을 결정할 수 있습니다. 기본적으로 스크립트에서 실행된 마지막 명령의 종료 코드는 전체 스크립트의 종료 코드로 보고됩니다. 예를 들어 세 개의 명령이 포함된 스크립트가 있습니다. 첫 번째 명령은 실패하지만 다음 명령은 성공합니다. 마지막 명령이 성공했기 때문에 실행 상태는 `succeeded`로 보고됩니다.
**Shell 스크립트**
첫 번째 명령 실패 시 전체 스크립트를 실패하려면, 마지막 명령 이전에 명령이 실패하는 경우 셸 조건문을 포함하여 스크립트를 종료할 수 있습니다. 다음과 같은 접근 방식을 사용하지 마십시오.
```
if [ $? != 0 ]
then
exit
fi
```
다음 예제에서는 첫 번째 명령이 실패하면 전체 스크립트가 실패합니다.
```
cd /test
if [ $? != 0 ]
then
echo "Failed"
exit 1
fi
date
```
**PowerShell 스크립트**
PowerShell에서 종료 코드를 성공적으로 캡처하려면 Run Command에 대한 스크립트에서 `exit`를 명시적으로 호출해야 합니다.
```
if ($?) {}
else {exit }
exit
```
예:
```
cd C:\
if ($?) {echo "Success"}
else {exit 1}
date
```
# 명령 실행 시 재부팅 처리
AWS Systems Manager의 도구인 Run Command을 사용하여 관리형 노드를 재부팅하는 스크립트를 실행할 수 있으며, 스크립트에 종료 코드를 지정하는 것이 좋습니다. 다른 방식으로 스크립트에서 노드를 재부팅하려고 시도할 경우, 재부팅이 스크립트의 마지막 단계라 하더라도 스크립트 실행 상태가 올바로 업데이트되지 않을 수 있습니다. Windows 관리형 노드의 경우 스크립트에서 `exit 3010`을 지정합니다. Linux 및 macOS 관리형 노드의 경우 `exit 194`를 지정합니다. 종료 코드는 AWS Systems Manager 에이전트(SSM Agent)에 관리형 노드를 재부팅하라고 지시한 다음 재부팅이 완료되면 스크립트를 재시작합니다. 재부팅을 시작하기 전에 SSM Agent는 클라우드 내 Systems Manager 서비스에 서버를 재부팅하는 동안 통신이 중단됨을 알립니다.
**참고**
재부팅 스크립트는 `aws:runDocument` 플러그 인의 일부일 수 없습니다. 문서에 재부팅 스크립트가 포함되어 있고 다른 문서가 `aws:runDocument` 플러그 인을 통해 해당 문서를 실행하려고 할 경우 SSM Agent에 오류가 발생합니다.
**idempotent 스크립트 생성**
관리형 노드를 재부팅하는 스크립트를 개발할 때는 재부팅 후 떠난 곳에서 스크립트 실행을 계속하도록 idempotent 스크립트를 만듭니다. idempotent 스크립트는 상태를 관리하며 작업 수행 여부를 검증합니다. 이렇게 하면 한 번만 실행되도록 되어 있는 단계가 여러 번 실행되는 것을 방지할 수 있습니다.
다음은 관리형 노드를 여러 번 재부팅하는 idempotent 스크립트의 대략적인 예입니다.
```
$name = Get current computer name
If ($name –ne $desiredName)
{
Rename computer
exit 3010
}
$domain = Get current domain name
If ($domain –ne $desiredDomain)
{
Join domain
exit 3010
}
If (desired package not installed)
{
Install package
exit 3010
}
```
**예시**
다음 스크립트 샘플은 종료 코드를 사용하여 관리형 노드를 재시작합니다. Linux 예제에서는 Amazon Linux에 패키지 업데이트를 설치한 다음 노드를 다시 시작합니다. Windows Server 예시에서는 노드에 Telnet-Client를 설치한 다음 노드를 다시 시작합니다.
------
#### [ Amazon Linux 2 ]
```
#!/bin/bash
yum -y update
needs-restarting -r
if [ $? -eq 1 ]
then
exit 194
else
exit 0
fi
```
------
#### [ Windows ]
```
$telnet = Get-WindowsFeature -Name Telnet-Client
if (-not $telnet.Installed)
{
# Install Telnet and then send a reboot request to SSM Agent.
Install-WindowsFeature -Name "Telnet-Client"
exit 3010
}
```
------
# 명령 상태 이해
AWS Systems Manager의 도구인 Run Command는 어떤 명령을 처리하는 동안과 명령을 처리한 각 관리형 노드에 대해 그 명령이 거치게 되는 다양한 상태에 대한 자세한 상태 정보를 보고합니다. 다음 방법을 사용하여 명령 상태를 모니터링할 수 있습니다.
+ Run Command 콘솔 인터페이스의 **Commands**(명령) 탭에서 **Refresh**(새로 고침) 아이콘을 선택합니다.
+ AWS Command Line Interface(AWS CLI)를 사용하여 [list-commands](https://docs.aws.amazon.com/cli/latest/reference/ssm/list-commands.html) 또는 [list-command-invocations](https://docs.aws.amazon.com/cli/latest/reference/ssm/list-command-invocations.html)를 호출합니다. AWS Tools for Windows PowerShell을 사용하여 [Get-SSMCommand](https://docs.aws.amazon.com/powershell/latest/reference/items/Get-SSMCommand.html) 또는 [Get-SSMCommandInvocation](https://docs.aws.amazon.com/powershell/latest/reference/items/Get-SSMCommandInvocation.html)을 호출합니다.
+ 상태 변경에 응답하도록 Amazon EventBridge를 구성합니다.
+ 모든 상태 변경 또는 `Failed`, `TimedOut` 등의 특정 상태에 대해 알림을 보내도록 Amazon Simple Notification Service(SNS)를 구성합니다.
## Run Command 상태
Run Command는 플러그인, 호출, 전체 명령 상태라는 세 가지 영역에 대한 자세한 상태 정보를 보고합니다. *플러그인*은 명령의 SSM 문서에 정의된 코드 실행 블록입니다. 플러그인에 대한 자세한 내용은 [Command 문서 플러그인 참조](documents-command-ssm-plugin-reference.md) 섹션을 참조하세요.
동시에 여러 관리형 노드에 명령을 보내는 경우, 각 노드를 대상으로 하는 명령 사본 각각을 *명령 호출*이라고 합니다. 예를 들어 `AWS-RunShellScript` 문서를 사용하여 `ifconfig` 명령을 20개의 Linux 인스턴스에 보내는 경우 이 명령에는 20개의 호출이 있습니다. 각 명령 호출은 개별적으로 상태를 보고합니다. 지정된 명령 호출에 대한 플러그인 역시 상태를 개별적으로 보고합니다.
마지막으로, Run Command에는 모든 플러그인과 호출에 대한 총체적인 명령 상태가 포함되어 있습니다. 다음 표에 나와 있는 것처럼, 총체적인 명령 상태는 플러그인이나 호출에서 보고되는 상태와 다를 수 있습니다.
**참고**
`max-concurrency` 또는 `max-errors` 파라미터를 사용하여 많은 수의 관리형 노드에 명령을 실행할 경우 다음 표의 설명과 같이 명령 상태는 해당 파라미터에 따른 제한을 반영합니다. 이런 파라미터에 대한 자세한 내용은 [대규모로 명령 실행](send-commands-multiple.md) 섹션을 참조하세요.
**명령 플러그인 및 호출의 세부 상태**
| Status | 세부 정보 |
| --- | --- |
| 보류중 | 명령이 아직 관리형 노드로 전송되지 않았거나 SSM Agent에 의해 수신되지 않았습니다. 시간 제한(초)(Timeout (seconds)) 파라미터와 실행 시간 제한(Execution timeout) 파라미터의 합에 해당하는 시간이 경과하기 전에 에이전트가 명령을 수신하지 않으면 상태가 Delivery Timed Out로 변경됩니다. |
| InProgress | Systems Manager가 관리형 노드에 명령을 보내려고 시도하거나 SSM Agent에서 명령을 수신하고 인스턴스에서 실행을 시작했습니다. 모든 명령 플러그인의 결과에 따라 상태는 Success, Failed, Delivery Timed Out 또는 Execution Timed Out으로 변경됩니다. 예외: 에이전트가 노드에서 실행 중이 아니거나 사용 가능한 경우 명령 상태는 에이전트를 다시 사용할 수 있거나 실행 시간 제한에 도달할 때까지 In Progress으로 유지됩니다. 상태는 종료 상태로 변경됩니다. |
| Delayed | 시스템에서 관리형 노드로 명령 전송을 시도했지만 완료하지 못했습니다. 시스템이 다시 시도합니다. |
| Success | 이 상태는 다양한 조건에서 반환됩니다. 이 상태가 노드에서 명령이 처리되었다는 뜻은 아닙니다. 예를 들어 관리형 노드의 SSM Agent에 명령이 수신된 후 PowerShell ExecutionPolicy에서 명령 실행을 차단한 결과로 종료 코드 0이 반환될 수 있습니다. 이것은 종료 상태입니다. 명령에서 Success 상태를 반환하는 조건은 다음과 같습니다.[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/systems-manager/latest/userguide/monitor-commands.html) 리소스 그룹을 타켓팅할 때도 동일한 조건이 적용됩니다. 오류를 해결하거나 명령 실행에 대한 자세한 정보를 얻으려면 적절한 종료 코드(명령 실패에 대한 0 이외의 종료 코드)를 반환해 오류나 예외를 처리하는 명령을 전송합니다. |
| DeliveryTimedOut | 총 시간 제한 만료 전까지 명령이 관리형 노드로 전송되지 않았습니다. 상위 명령의 max-errors 제한에 총 시간 초과 횟수가 계산되지는 않지만, 상위 명령 상태를 Success, Incomplete 또는 Delivery Timed Out으로 표시할지 여부에는 영향을 미칩니다. 이것은 종료 상태입니다. |
| ExecutionTimedOut | 관리형 노드에서 명령 자동화가 시작되었지만, 실행 시간제한 만료 전까지 명령이 완료되지 않았습니다. 실행 시간 초과는 실패로 계산되며, 이 경우 0이 아닌 응답이 전송되고 Systems Manager는 명령 자동화 실행 시도를 종료하고 실패 상태를 보고합니다. |
| 실패 | 관리형 노드에서 명령 실행을 완료하지 못했습니다. 플러그인의 경우 이는 결과 코드가 0이 아니었음을 나타냅니다. 명령 호출의 경우 이는 하나 이상의 플러그인에 대한 결과 코드가 0이 아니었음을 나타냅니다. 호출 실패는 상위 명령의 max-errors 제한에 계산됩니다. 이것은 종료 상태입니다. |
| 취소됨 | 명령이 완료되기 전에 취소되었습니다. 이것은 종료 상태입니다. |
| Undeliverable | 관리형 노드로 명령을 전달할 수 없습니다. 해당 노드가 없거나 응답하지 않는 것일 수 있습니다. 배달할 수 없는 호출은 상위 명령의 max-errors 제한에 계산되지 않지만 상위 명령 상태를 Success 또는 Incomplete으로 표시할지 여부에 영향을 미치지도 않습니다. (예를 들어 명령의 모든 호출이 Undeliverable 상태인 경우 반환된 명령 상태는 Failed입니다. 그러나 명령에 5개 호출이 있는 경우 그 중 4개가 Undeliverable 상태를 반환하고 나머지 1개가 Success 상태를 반환하는 경우 상위 명령의 상태는 Success입니다.) 이것은 종료 상태입니다. |
| 종료됨 | 상위 명령이 max-errors 제한을 초과해 시스템에서 이후의 명령 호출을 취소했습니다. 이것은 종료 상태입니다. |
| InvalidPlatform | 선택한 문서에 지정된 필수 플랫폼과 일치하지 않는 관리형 노드로 명령이 전송되었습니다. Invalid Platform은 상위 명령의 최대 오류 제한에 포함되지 않지만 상위 명령 상태가 성공인지 실패인지 여부에 영향을 줍니다. (예를 들어 명령의 모든 호출이 Invalid Platform 상태인 경우 반환된 명령 상태는 Failed입니다. 그러나 명령에 5개 호출이 있는 경우 그 중 4개가 Invalid Platform 상태를 반환하고 나머지 1개가 Success 상태를 반환하는 경우 상위 명령의 상태는 Success입니다.) 이것은 종료 상태입니다. |
| AccessDenied | 명령을 시작하는 AWS Identity and Access Management(IAM) 사용자 또는 역할은 대상 지정된 관리형 노드에 액세스할 수 없습니다. Access Denied는 상위 명령의 max-errors 한도에 불리하게 작용하지 않지만 상위 명령 상태가 Success 또는 Failed인지 여부에 원인을 제공합니다. (예를 들어 명령의 모든 호출이 Access Denied 상태인 경우 반환된 명령 상태는 Failed입니다. 그러나 명령에 5개 호출이 있는 경우 그 중 4개가 Access Denied 상태를 반환하고 나머지 1개가 Success 상태를 반환하는 경우 상위 명령의 상태는 Success입니다.) 이것은 종료 상태입니다. |
**명령의 세부 상태**
| Status | 세부 정보 |
| --- | --- |
| 보류중 | 어떤 관리형 노드에서도 에이전트가 아직 명령을 받지 않았습니다. |
| InProgress | 1개 이상의 관리형 노드로 명령을 전송했지만 모든 노드에서 최종 상태에 도달하지는 못했습니다. |
| Delayed | 시스템에서 노드로 명령 전송을 시도했지만 완료하지 못했습니다. 시스템이 다시 시도합니다. |
| Success | 지정되었거나 대상이 된 모든 관리형 노드의 SSM Agent에 명령이 수신되었고 종료 코드 0을 반환했습니다. 모든 명령 호출이 터미널 상태에 도달했고 max-errors 값에 도달하지 않았습니다. 이 상태가 지정되었거나 대상이 된 모든 관리형 노드에서 명령이 처리되었다는 뜻은 아닙니다. 이것은 종료 상태입니다. 오류를 해결하거나 명령 실행에 대한 자세한 정보를 얻으려면 적절한 종료 코드(명령 실패에 대한 0 이외의 종료 코드)를 반환해 오류나 예외를 처리하는 명령을 전송합니다. |
| DeliveryTimedOut | 총 시간 제한 만료 전까지 명령이 관리형 노드로 전송되지 않았습니다. max-errors 이상의 명령 호출 값이 Delivery Timed Out 상태를 표시합니다. 이것은 종료 상태입니다. |
| 실패 | 관리형 노드에서 명령 실행을 완료하지 못했습니다. `max-errors` 이상의 명령 호출 값이 `Failed` 상태를 표시합니다. 이것은 종료 상태입니다. |
| 불완전 | 모든 관리형 노드에서 명령을 시도했고 값이 Success가 아닌 호출이 한 개 이상입니다. 하지만 Failed 상태가 될 정도로 많은 호출에 실패한 것은 아닙니다. 이것은 종료 상태입니다. |
| 취소됨 | 명령이 완료되기 전에 취소되었습니다. 이것은 종료 상태입니다. |
| RateExceeded | 명령의 대상이 되는 관리형 노드 수가 보류 중인 호출에 대한 계정 할당량을 초과했습니다. 시스템에서 이 명령을 어떤 노드에서 실행하기 전에 취소했습니다. 이것은 종료 상태입니다. |
| AccessDenied | 명령을 시작하는 사용자 또는 역할은 대상으로 지정된 리소스 그룹에 액세스할 수 없습니다. AccessDenied는 상위 명령의 max-errors 한도에 불리하게 작용하지 않지만 상위 명령 상태가 Success 또는 Failed인지 여부에 원인을 제공합니다. (예를 들어 명령의 모든 호출이 AccessDenied 상태인 경우 반환된 명령 상태는 Failed입니다. 그러나 명령에 5번의 호출이 있고 그 중 4번은 상태 AccessDenied를 반환하고 1번은 Success 상태를 반환하는 경우 상위 명령의 상태는 Success입니다.) 이것은 종료 상태입니다. |
| 태그에 인스턴스 없음 | 명령으로 대상 지정된 태그 키 페어 또는 리소스 그룹은 관리형 노드와 일치하지 않습니다. 이것은 종료 상태입니다. |
## 명령 제한 시간 값 이해
Systems Manager는 명령을 실행할 때 다음 시간 제한 값을 적용합니다.
**총 제한 시간**
Systems Manager 콘솔에서 **시간 제한(초)(Timeout (seconds))** 필드에 시간 제한 값을 지정합니다. 명령이 전송된 후 Run Command는 명령이 만료되었는지 여부를 확인합니다. 명령이 명령 만료 제한(총 시간 제한)에 도달하면 상태가 `InProgress`, `Pending` 또는 `Delayed`인 모든 호출에 대해 상태가 `DeliveryTimedOut`으로 변경됩니다.
![\[Systems Manager 콘솔의 시간 제한(초)(Timeout (seconds)) 필드\]](http://docs.aws.amazon.com/ko_kr/systems-manager/latest/userguide/images/run-command-delivery-time-out-time-out-seconds.png)
보다 기술적인 수준에서 총 시간 제한(**시간 제한(초)(Timeout (seconds))**)은 다음과 같이 두 가지 시간 제한 값의 조합입니다.
`Total timeout = "Timeout(seconds)" from the console + "timeoutSeconds": "{{ executionTimeout }}" from your SSM document`
예를 들어 Systems Manager 콘솔에서 **시간 제한(초)(Timeout (seconds))**의 기본값은 600초입니다. `AWS-RunShellScript`SSM 문서를 사용하여 명령을 실행하는 경우 다음 문서 샘플과 같이 **"timeoutSeconds": "\$1\$1 executionTimeout \$1\$1"**의 기본값은 3,600초입니다.
```
"executionTimeout": {
"type": "String",
"default": "3600",
"runtimeConfig": {
"aws:runShellScript": {
"properties": [
{
"timeoutSeconds": "{{ executionTimeout }}"
```
즉, 시스템이 명령 상태를 `DeliveryTimedOut`으로 설정하기 전에 명령이 4,200초(70분) 동안 실행됩니다.
**실행 제한 시간**
Systems Manager 콘솔의 **실행 시간 제한(Execution Timeout)** 필드에 실행 시간 제한 값을 지정합니다(사용 가능한 경우). 모든 SSM 문서에 실행 시간 제한을 지정해야 하는 것은 아닙니다. **Execution Timeout**(실행 시간 초과) 필드는 SSM 문서에 해당 입력 파라미터가 정의되어 있는 경우에만 표시됩니다. 지정된 경우 이 시간 내에 명령이 완료되어야 합니다.
**참고**
Run Command는 명령이 에이전트에 전송되었는지 여부를 판별하기 위해 SSM Agent 문서 터미널 응답에 의존합니다. SSM Agent는 `ExecutionTimedOut`으로 표시되는 호출 또는 명령에 대한 `ExecutionTimedOut` 신호를 보내야 합니다.
![\[Systems Manager 콘솔의 실행 시간 제한(Execution Timeout) 필드\]](http://docs.aws.amazon.com/ko_kr/systems-manager/latest/userguide/images/run-command-execution-timeout-console.png)
**기본 실행 제한 시간**
SSM 문서에서 실행 제한 시간 값을 명시적으로 지정할 필요가 없는 경우 Systems Manager는 하드 코딩된 기본 실행 제한 시간을 적용합니다.
**Systems Manager가 시간 제한을 보고하는 방법**
Systems Manager가 대상의 SSM Agent로부터 `execution timeout` 응답을 수신한 경우 Systems Manager는 명령 호출을 `executionTimeout`으로 표시합니다.
Run Command가 SSM Agent로부터 문서 터미널 응답을 받지 못하면 명령 호출은 `deliveryTimeout`으로 표시됩니다.
대상의 시간 제한 상태를 확인하기 위해 SSM Agent는 모든 파라미터와 SSM 문서의 콘텐츠를 결합하여 `executionTimeout`을 계산합니다. SSM Agent에서 명령이 시간 초과되었다고 판단하면 `executionTimeout`을 서비스로 전송합니다.
**시간 제한(초)(Timeout (seconds))**의 기본값은 3,600초입니다. **실행 시간 제한(Execution Timeout)**의 기본값도 3,600초입니다. 따라서 명령의 총 기본 시간 제한은 7,200초입니다.
**참고**
SSM Agent는 SSM 문서 유형 및SSM 문서 버전에 따라 `executionTimeout`을 다르게 처리합니다.
# Run Command 연습
이 섹션의 시연에서는 AWS Command Line Interface(AWS CLI) 또는 AWS Tools for Windows PowerShell 사용을 통해 AWS Systems Manager의 도구인 Run Command에서 명령을 실행하는 방법을 보여줍니다.
**Topics**
+ [Run Command를 사용하여 소프트웨어 업데이트](run-command-tutorial-update-software.md)
+ [연습: Run Command에서 AWS CLI 사용](walkthrough-cli.md)
+ [연습: Run Command에서 AWS Tools for Windows PowerShell 사용](walkthrough-powershell.md)
다음 참조에서도 명령 샘플을 볼 수 있습니다.
+ [Systems Manager AWS CLI 참조](https://docs.aws.amazon.com/cli/latest/reference/ssm/)
+ [AWS Tools for Windows PowerShell - AWS Systems Manager](https://docs.aws.amazon.com/powershell/latest/reference/items/SimpleSystemsManagement_cmdlets.html)
# Run Command를 사용하여 소프트웨어 업데이트
다음 절차에서는 관리형 노드에서 소프트웨어를 업데이트하는 방법을 설명합니다.
## Run Command를 사용하여 SSM Agent 업데이트
다음 절차에서는 관리형 노드에서 실행 중인 SSM Agent를 업데이트하는 방법을 설명합니다. SSM Agent의 최신 버전으로 업데이트하거나 이전 버전으로 다운그레이드할 수 있습니다. 명령을 실행하면 시스템은 AWS에서 버전을 다운로드하여 설치한 다음, 명령을 실행하기 이전에 있었던 버전을 제거합니다. 이 프로세스 중에 오류가 발생하면, 서버에서 명령을 실행하기 이전의 버전으로 롤백하며 명령 상태에 명령이 실패했다고 표시됩니다.
**참고**
인스턴스가 macOS 버전 13.0(Ventura) 이상을 실행하는 경우 SSM Agent 문서를 실행하려면 인스턴스의 AWS-UpdateSSMAgent 버전이 3.1.941.0 이상이어야 합니다. 인스턴스가 3.1.941.0 이전에 릴리스된 SSM Agent 버전을 실행 중인 경우 `brew update` 및 `brew upgrade amazon-ssm-agent` 명령을 실행하여 AWS-UpdateSSMAgent 문서를 실행하도록 SSM Agent를 업데이트할 수 있습니다.
SSM Agent 업데이트에 대해 알림을 수신하려면 GitHub에서 [SSM Agent 릴리스 정보](https://github.com/aws/amazon-ssm-agent/blob/mainline/RELEASENOTES.md) 페이지를 구독합니다.
**Run Command를 사용하여 SSM Agent를 업데이트하려면**
1. [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)에서 AWS Systems Manager 콘솔을 엽니다.
1. 탐색 창에서 **Run Command**를 선택합니다.
1. **Run command**(실행 명령)를 선택합니다.
1. **Command 문서(Command document)** 목록에서 **`AWS-UpdateSSMAgent`**를 선택합니다.
1. **명령 파라미터** 섹션에서, 원하는 경우 다음 파라미터의 값을 지정합니다.
1. (옵션) **버전(Version)**에 설치할 SSM Agent의 버전을 입력합니다. [이전 버전](https://github.com/aws/amazon-ssm-agent/blob/mainline/RELEASENOTES.md)의 에이전트를 설치할 수 있습니다. 버전을 지정하지 않으면 최신 버전으로 설치됩니다.
1. (옵션) **다운그레이드 허용(Allow Downgrade)**에서 **true**를 선택하여 이전 버전의 SSM Agent를 설치합니다. 이 옵션을 선택하는 경우 [이전](https://github.com/aws/amazon-ssm-agent/blob/mainline/RELEASENOTES.md) 버전 번호를 지정해야 합니다. 최신 서비스 버전을 설치하려면 **false**를 선택합니다.
1. **대상(Targets)** 섹션에서, 태그를 지정하거나, 수동으로 인스턴스나 엣지 디바이스를 선택하거나, 리소스 그룹을 지정하여 이 작업을 실행할 관리형 노드를 식별합니다.
**작은 정보**
예상한 관리형 노드가 목록에 없으면 [관리형 노드 가용성 문제 해결](fleet-manager-troubleshooting-managed-nodes.md)에서 문제 해결 팁을 참조하세요.
1. **Other parameters**(다른 파라미터):
+ **Comment**(설명)에 명령에 대한 정보를 입력합니다.
+ **제한 시간(초)**에서 전체 명령 실행이 실패할 때까지 시스템이 기다리는 시간을 초 단위로 지정합니다.
1. **Rate control**(속도 제어)에서
+ **Concurrency**(동시성)에서 명령을 동시에 실행할 관리형 노드의 백분율 또는 개수를 지정합니다.
**참고**
관리형 노드에 적용할 태그를 지정하거나, AWS 리소스 그룹을 지정하여 대상을 선택하였지만 대상으로 지정할 관리형 노드 수를 잘 모를 경우에는 백분율을 지정하여 동시에 문서를 실행할 수 있는 대상 수를 제한합니다.
+ **Error threshold**(오류 임계값)에서, 명령이 노드의 개수 또는 백분율에서 실패한 후 다른 관리형 노드에서 해당 명령의 실행을 중지할 시간을 지정합니다. 예를 들어 세 오류를 지정하면 네 번째 오류를 받았을 때 Systems Manager가 명령 전송을 중지합니다. 여전히 명령을 처리 중인 관리형 노드도 오류를 전송할 수 있습니다.
1. (선택 사항) **Output options**(출력 옵션)에서 명령 출력을 파일에 저장하려면 **Write command output to an S3 bucket**(S3 버킷에 명령 출력 쓰기) 상자를 선택합니다. 상자에 버킷 및 접두사(폴더) 이름을 입력합니다.
**참고**
데이터를 S3 버킷에 쓰는 기능을 부여하는 S3 권한은 이 작업을 수행하는 IAM 사용자의 권한이 아니라 인스턴스에 할당된 인스턴스 프로파일(EC2 인스턴스용) 또는 IAM 서비스 역할(하이브리드 정품 인증 시스템)의 권한입니다. 자세한 내용은 [Systems Manager에 필요한 인스턴스 권한 구성](setup-instance-permissions.md)이나 [하이브리드 환경을 위한 IAM 서비스 역할 생성](hybrid-multicloud-service-role.md)을 참조하세요. 또한 지정된 S3 버킷이 다른 AWS 계정에 있는 경우 관리형 노드와 연결된 인스턴스 프로파일 또는 IAM 서비스 역할은 해당 버킷에 쓸 수 있는 권한이 있어야 합니다.
1. **SNS notifications**(SNS 알림) 섹션에서, 명령 실행 상태에 대한 알림이 전송되도록 하려면 **Enable SNS notifications**(SNS 알림 활성화) 확인란을 선택합니다.
Run Command에 대한 Amazon SNS 알림 구성에 대한 자세한 내용은 [Amazon SNS 알림을 사용하여 Systems Manager 상태 변경 모니터링](monitoring-sns-notifications.md) 섹션을 참조하세요.
1. **Run**(실행)을 선택합니다.
## Run Command를 사용하여 PowerShell 업데이트
다음 절차에서는 Windows Server 2012 및 2012 R2 관리형 노드에서 PowerShell을 버전 5.1로 업데이트하는 방법을 설명합니다. 이 절차에서 제공하는 스크립트는 Windows Management Framework(WMF) 버전 5.1 업데이트를 다운로드하고 업데이트 설치를 시작합니다. WMF 5.1을 설치할 때 필요하기 때문에 이 프로세스 중 노드가 재부팅됩니다. 업데이트 다운로드 및 설치를 완료하는 데 5분 정도 걸립니다.
**Run Command를 사용하여 PowerShell을 업데이트하려면**
1. [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)에서 AWS Systems Manager 콘솔을 엽니다.
1. 탐색 창에서 **Run Command**를 선택합니다.
1. **Run command**(실행 명령)를 선택합니다.
1. **Command 문서(Command document)** 목록에서 **`AWS-RunPowerShellScript`**를 선택합니다.
1. **명령(Commands)** 섹션에 운영 체제에 대해 다음 명령을 붙여 넣습니다.
------
#### [ Windows Server 2012 R2 ]
```
Set-Location -Path "C:\Windows\Temp"
Invoke-WebRequest "https://go.microsoft.com/fwlink/?linkid=839516" -OutFile "Win8.1AndW2K12R2-KB3191564-x64.msu"
Start-Process -FilePath "$env:systemroot\system32\wusa.exe" -Verb RunAs -ArgumentList ('Win8.1AndW2K12R2-KB3191564-x64.msu', '/quiet')
```
------
#### [ Windows Server 2012 ]
```
Set-Location -Path "C:\Windows\Temp"
Invoke-WebRequest "https://go.microsoft.com/fwlink/?linkid=839513" -OutFile "W2K12-KB3191565-x64.msu"
Start-Process -FilePath "$env:systemroot\system32\wusa.exe" -Verb RunAs -ArgumentList ('W2K12-KB3191565-x64.msu', '/quiet')
```
------
1. **대상(Targets)** 섹션에서, 태그를 지정하거나, 수동으로 인스턴스나 엣지 디바이스를 선택하거나, 리소스 그룹을 지정하여 이 작업을 실행할 관리형 노드를 식별합니다.
**작은 정보**
예상한 관리형 노드가 목록에 없으면 [관리형 노드 가용성 문제 해결](fleet-manager-troubleshooting-managed-nodes.md)에서 문제 해결 팁을 참조하세요.
1. **Other parameters**(다른 파라미터):
+ **Comment**(설명)에 명령에 대한 정보를 입력합니다.
+ **제한 시간(초)**에서 전체 명령 실행이 실패할 때까지 시스템이 기다리는 시간을 초 단위로 지정합니다.
1. **Rate control**(속도 제어)에서
+ **Concurrency**(동시성)에서 명령을 동시에 실행할 관리형 노드의 백분율 또는 개수를 지정합니다.
**참고**
관리형 노드에 적용할 태그를 지정하거나, AWS 리소스 그룹을 지정하여 대상을 선택하였지만 대상으로 지정할 관리형 노드 수를 잘 모를 경우에는 백분율을 지정하여 동시에 문서를 실행할 수 있는 대상 수를 제한합니다.
+ **Error threshold**(오류 임계값)에서, 명령이 노드의 개수 또는 백분율에서 실패한 후 다른 관리형 노드에서 해당 명령의 실행을 중지할 시간을 지정합니다. 예를 들어 세 오류를 지정하면 네 번째 오류를 받았을 때 Systems Manager가 명령 전송을 중지합니다. 여전히 명령을 처리 중인 관리형 노드도 오류를 전송할 수 있습니다.
1. (선택 사항) **Output options**(출력 옵션)에서 명령 출력을 파일에 저장하려면 **Write command output to an S3 bucket**(S3 버킷에 명령 출력 쓰기) 상자를 선택합니다. 상자에 버킷 및 접두사(폴더) 이름을 입력합니다.
**참고**
데이터를 S3 버킷에 쓰는 기능을 부여하는 S3 권한은 이 작업을 수행하는 IAM 사용자의 권한이 아니라 인스턴스에 할당된 인스턴스 프로파일(EC2 인스턴스용) 또는 IAM 서비스 역할(하이브리드 정품 인증 시스템)의 권한입니다. 자세한 내용은 [Systems Manager에 필요한 인스턴스 권한 구성](setup-instance-permissions.md)이나 [하이브리드 환경을 위한 IAM 서비스 역할 생성](hybrid-multicloud-service-role.md)을 참조하세요. 또한 지정된 S3 버킷이 다른 AWS 계정에 있는 경우 관리형 노드와 연결된 인스턴스 프로파일 또는 IAM 서비스 역할은 해당 버킷에 쓸 수 있는 권한이 있어야 합니다.
1. **SNS notifications**(SNS 알림) 섹션에서, 명령 실행 상태에 대한 알림이 전송되도록 하려면 **Enable SNS notifications**(SNS 알림 활성화) 확인란을 선택합니다.
Run Command에 대한 Amazon SNS 알림 구성에 대한 자세한 내용은 [Amazon SNS 알림을 사용하여 Systems Manager 상태 변경 모니터링](monitoring-sns-notifications.md) 섹션을 참조하세요.
1. **Run**(실행)을 선택합니다.
관리형 노드가 재부팅되고 업데이트 설치가 완료되면 관리형 노드에 연결하여 PowerShell이 버전 5.1로 업그레이드되었는지 확인합니다. 노드에서 PowerShell의 버전을 확인하려면 PowerShell을 열고 `$PSVersionTable`을 입력합니다. 출력 테이블의 `PSVersion` 값은 업그레이드가 성공한 경우 5.1을 표시합니다.
`PSVersion` 값이 5.1과 다른 경우(예: 3.0 또는 4.0) **Windows 로그(Windows Logs)** 아래에 있는 이벤트 뷰어의 **설치(Setup)** 로그를 검토합니다. 이러한 로그에서 업데이트 설치가 실패한 이유를 확인할 수 있습니다.
# 연습: Run Command에서 AWS CLI 사용
다음 예제 시연에서는 AWS Command Line Interface(AWS CLI)를 사용하여 명령 및 명령 파라미터에 대한 정보를 보는 방법, 명령을 실행하는 방법, 해당 명령의 상태를 보는 방법을 보여줍니다.
**중요**
신뢰할 수 있는 관리자만 이번 주제에서 언급하는 AWS Systems Manager 사전 구성 문서를 사용할 수 있도록 허용해야 합니다. Systems Manager 문서에서 지정하는 명령 또는 스크립트는 관리형 노드에 대한 관리자 권한으로 실행됩니다. 미리 정의된 Systems Manager 문서(`AWS-`로 시작하는 모든 문서)를 실행할 권한이 있는 사용자는 해당 노드에 대한 관리자 권한도 보유합니다. 그 밖의 모든 사용자들에 대해서는 제한된 문서를 생성하여 그 문서를 특정 사용자와 공유해야 합니다.
**Topics**
+ [1단계: 시작하기](#walkthrough-cli-settings)
+ [2단계: 셸 스크립트를 실행하여 리소스 세부 정보 보기](#walkthrough-cli-run-scripts)
+ [3단계: `AWS-RunShellScript` 문서를 사용하여 간단한 명령 전송](#walkthrough-cli-example-1)
+ [4단계: Run Command을 사용하여 간단한 Python 스크립트 실행](#walkthrough-cli-example-2)
+ [5단계: Run Command를 사용하여 Bash 스크립트 실행](#walkthrough-cli-example-3)
## 1단계: 시작하기
구성할 관리형 노드에 대한 관리자 권한이 있거나 AWS Identity and Access Management(IAM)에서 적절한 권한을 부여받아야 합니다. 또한 이 예제에서는 미국 동부(오하이오) 리전(us-east-2)을 사용합니다. Run Command는 **Amazon Web Services 일반 참조의 [Systems Manager 서비스 엔드포인트](https://docs.aws.amazon.com/general/latest/gr/ssm.html#ssm_region)에 나열된 AWS 리전에서 사용할 수 있습니다. 자세한 내용은 [AWS Systems Manager에 대한 관리형 노드 설정](systems-manager-setting-up-nodes.md) 섹션을 참조하세요.
**AWS CLI을 사용하여 명령을 실행하려면**
1. 아직 하지 않은 경우 AWS Command Line Interface(AWS CLI)을 설치하고 구성합니다.
자세한 내용은 [최신 버전의 AWS CLI 설치 또는 업데이트](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html)를 참조하세요.
1. 사용할 수 있는 모든 문서를 나열합니다.
이 명령을 실행하면 IAM 권한에 따라 계정에 사용할 수 있는 문서를 모두 나열합니다.
```
aws ssm list-documents
```
1. 관리형 노드가 명령을 수신할 준비가 되었는지 확인합니다.
다음 명령의 출력은 관리형 노드가 온라인 상태인지 여부를 보여줍니다.
------
#### [ Linux & macOS ]
```
aws ssm describe-instance-information \
--output text --query "InstanceInformationList[*]"
```
------
#### [ Windows ]
```
aws ssm describe-instance-information ^
--output text --query "InstanceInformationList[*]"
```
------
1. 다음 명령을 실행하여 특정 관리형 노드에 대한 세부 정보를 봅니다.
**참고**
이 시연에서 명령을 실행하려면 인스턴스 및 명령 ID를 바꿉니다. 관리형 AWS IoT Greengrass 코어 디바이스에서, 인스턴스 ID로 mi-*ID\$1number*를 사용합니다. **send-command**의 응답으로 명령 ID가 반환됩니다. 인스턴스 ID는 AWS Systems Manager의 도구인 Fleet Manager서 제공됩니다.
------
#### [ Linux & macOS ]
```
aws ssm describe-instance-information \
--instance-information-filter-list key=InstanceIds,valueSet=instance-ID
```
------
#### [ Windows ]
```
aws ssm describe-instance-information ^
--instance-information-filter-list key=InstanceIds,valueSet=instance-ID
```
------
## 2단계: 셸 스크립트를 실행하여 리소스 세부 정보 보기
Run Command 및 `AWS-RunShellScript` 문서를 사용하면 로컬로 로그인한 것처럼 관리형 노드에서 명령이나 스크립트를 실행할 수 있습니다.
**설명 및 사용 가능한 파라미터 보기**
다음 명령을 실행하여 Systems Manager JSON 문서에 대한 설명을 봅니다.
------
#### [ Linux & macOS ]
```
aws ssm describe-document \
--name "AWS-RunShellScript" \
--query "[Document.Name,Document.Description]"
```
------
#### [ Windows ]
```
aws ssm describe-document ^
--name "AWS-RunShellScript" ^
--query "[Document.Name,Document.Description]"
```
------
다음 명령을 실행하여 사용 가능한 파라미터 및 해당 파라미터에 대한 세부 정보를 봅니다.
------
#### [ Linux & macOS ]
```
aws ssm describe-document \
--name "AWS-RunShellScript" \
--query "Document.Parameters[*]"
```
------
#### [ Windows ]
```
aws ssm describe-document ^
--name "AWS-RunShellScript" ^
--query "Document.Parameters[*]"
```
------
## 3단계: `AWS-RunShellScript` 문서를 사용하여 간단한 명령 전송
다음 명령을 실행하여 관리형 노드에 대한 IP 정보를 가져옵니다.
Windows Server 관리형 노드를 대상으로 지정했다면, `document-name`을 `AWS-RunPowerShellScript`로 바꾸고 `command`를 `ifconfig`에서 `ipconfig`로 바꿉니다.
------
#### [ Linux & macOS ]
```
aws ssm send-command \
--instance-ids "instance-ID" \
--document-name "AWS-RunShellScript" \
--comment "IP config" \
--parameters commands=ifconfig \
--output text
```
------
#### [ Windows ]
```
aws ssm send-command ^
--instance-ids "instance-ID" ^
--document-name "AWS-RunShellScript" ^
--comment "IP config" ^
--parameters commands=ifconfig ^
--output text
```
------
**응답 데이터와 함께 명령 정보 가져오기**
다음 명령은 이전 명령에서 반환된 명령 ID를 사용하여 명령 실행의 세부 정보와 응답 데이터를 가져옵니다. 명령이 완료되면 시스템에서 응답 데이터가 반환됩니다. 명령 실행에서 `"Pending"` 또는 `"InProgress"`가 표시되는 경우, 이 명령을 다시 실행하여 응답 데이터를 확인하십시오.
------
#### [ Linux & macOS ]
```
aws ssm list-command-invocations \
--command-id $sh-command-id \
--details
```
------
#### [ Windows ]
```
aws ssm list-command-invocations ^
--command-id $sh-command-id ^
--details
```
------
**사용자 식별**
다음 명령은 명령을 실행하는 기본 사용자를 표시합니다.
------
#### [ Linux & macOS ]
```
sh_command_id=$(aws ssm send-command \
--instance-ids "instance-ID" \
--document-name "AWS-RunShellScript" \
--comment "Demo run shell script on Linux managed node" \
--parameters commands=whoami \
--output text \
--query "Command.CommandId")
```
------
**명령 상태 가져오기**
다음 명령은 명령 ID를 사용하여 관리형 노드에서 명령 실행 상태를 가져옵니다. 이 예에서는 이전 명령에서 반환된 명령 ID를 사용합니다.
------
#### [ Linux & macOS ]
```
aws ssm list-commands \
--command-id "command-ID"
```
------
#### [ Windows ]
```
aws ssm list-commands ^
--command-id "command-ID"
```
------
**명령 세부 정보 가져오기**
다음 명령은 이전 명령의 명령 ID를 사용하여 관리형 노드 단위로 명령 실행 상태를 가져옵니다.
------
#### [ Linux & macOS ]
```
aws ssm list-command-invocations \
--command-id "command-ID" \
--details
```
------
#### [ Windows ]
```
aws ssm list-command-invocations ^
--command-id "command-ID" ^
--details
```
------
**특정 관리형 노드에 대한 응답 데이터로 명령 정보 가져오기**
다음 명령은 특정 관리형 노드에 대한 원래 `aws ssm send-command` 요청을 반환합니다.
------
#### [ Linux & macOS ]
```
aws ssm list-command-invocations \
--instance-id instance-ID \
--command-id "command-ID" \
--details
```
------
#### [ Windows ]
```
aws ssm list-command-invocations ^
--instance-id instance-ID ^
--command-id "command-ID" ^
--details
```
------
**Python 버전 표시**
다음 명령은 노드에서 실행되는 Python의 버전을 반환합니다.
------
#### [ Linux & macOS ]
```
sh_command_id=$(aws ssm send-command \
--instance-ids "instance-ID" \
--document-name "AWS-RunShellScript" \
--comment "Demo run shell script on Linux Instances" \
--parameters commands='python -V' \
--output text --query "Command.CommandId") \
sh -c 'aws ssm list-command-invocations \
--command-id "$sh_command_id" \
--details \
--query "CommandInvocations[].CommandPlugins[].{Status:Status,Output:Output}"'
```
------
## 4단계: Run Command을 사용하여 간단한 Python 스크립트 실행
다음 명령은 Run Command을 사용하여 간단한 Python “Hello World” 스크립트를 실행합니다.
------
#### [ Linux & macOS ]
```
sh_command_id=$(aws ssm send-command \
--instance-ids "instance-ID" \
--document-name "AWS-RunShellScript" \
--comment "Demo run shell script on Linux Instances" \
--parameters '{"commands":["#!/usr/bin/python","print \"Hello World from python\""]}' \
--output text \
--query "Command.CommandId") \
sh -c 'aws ssm list-command-invocations \
--command-id "$sh_command_id" \
--details \
--query "CommandInvocations[].CommandPlugins[].{Status:Status,Output:Output}"'
```
------
## 5단계: Run Command를 사용하여 Bash 스크립트 실행
이 섹션의 예에서는 Run Command를 사용하여 다음 bash 스크립트를 실행하는 방법을 보여줍니다.
Run Command를 사용하여 원격 위치에 저장된 스크립트를 실행하는 예는 [Amazon S3에서 스크립트 실행](integration-s3.md) 및 [GitHub에서 스크립트 실행](integration-remote-scripts.md)를 참조하세요.
```
#!/bin/bash
yum -y update
yum install -y ruby
cd /home/ec2-user
curl -O https://aws-codedeploy-us-east-2.s3.amazonaws.com/latest/install
chmod +x ./install
./install auto
```
이 스크립트는 *AWS CodeDeploy User Guide*의 [Create an Amazon EC2 instance for CodeDeploy](https://docs.aws.amazon.com/codedeploy/latest/userguide/instances-ec2-create.html)에 설명된 대로 Amazon Linux 및 Red Hat Enterprise Linux(RHEL) 인스턴스에 AWS CodeDeploy 에이전트를 설치합니다.
이 스크립트는 미국 동부(오하이오) 리전(us-east-2)인 `aws-codedeploy-us-east-2`의 AWS 관리형 S3 버킷에서 CodeDeploy 에이전트를 설치합니다.
**AWS CLI 명령에서 bash 스크립트 실행**
다음 샘플은 `--parameters` 옵션을 사용하여 CLI 명령에 bash 스크립트를 포함하는 방법을 보여줍니다.
------
#### [ Linux & macOS ]
```
aws ssm send-command \
--document-name "AWS-RunShellScript" \
--targets '[{"Key":"InstanceIds","Values":["instance-id"]}]' \
--parameters '{"commands":["#!/bin/bash","yum -y update","yum install -y ruby","cd /home/ec2-user","curl -O https://aws-codedeploy-us-east-2.s3.amazonaws.com/latest/install","chmod +x ./install","./install auto"]}'
```
------
**JSON 파일에서 bash 스크립트 실행**
다음 예에서는 bash 스크립트의 내용을 JSON 파일로 저장하고, `--cli-input-json` 옵션을 사용하여 해당 파일을 명령에 포함합니다.
------
#### [ Linux & macOS ]
```
aws ssm send-command \
--document-name "AWS-RunShellScript" \
--targets "Key=InstanceIds,Values=instance-id" \
--cli-input-json file://installCodeDeployAgent.json
```
------
#### [ Windows ]
```
aws ssm send-command ^
--document-name "AWS-RunShellScript" ^
--targets "Key=InstanceIds,Values=instance-id" ^
--cli-input-json file://installCodeDeployAgent.json
```
------
참조되는 `installCodeDeployAgent.json` 파일의 내용이 다음 예제에 나와 있습니다.
```
{
"Parameters": {
"commands": [
"#!/bin/bash",
"yum -y update",
"yum install -y ruby",
"cd /home/ec2-user",
"curl -O https://aws-codedeploy-us-east-2.s3.amazonaws.com/latest/install",
"chmod +x ./install",
"./install auto"
]
}
}
```
# 연습: Run Command에서 AWS Tools for Windows PowerShell 사용
다음 예에서는 AWS Tools for Windows PowerShell를 사용하여 명령 및 명령 파라미터에 대한 정보를 보는 방법, 명령을 실행하는 방법, 해당 명령의 상태를 보는 방법을 보여 줍니다. 이 연습에는 각 사전 정의 AWS Systems Manager 문서의 예가 포함되어 있습니다.
**중요**
신뢰할 수 있는 관리자만 이번 주제에서 언급하는 Systems Manager 사전 구성 문서를 사용할 수 있도록 허용해야 합니다. Systems Manager 문서에서 지정하는 명령 또는 스크립트는 관리형 노드에 대한 관리자 권한으로 실행됩니다. 미리 정의된 Systems Manager 문서(AWS로 시작하는 모든 문서)를 실행할 권한이 있는 사용자는 해당 노드에 대한 관리자 권한도 보유합니다. 그 밖의 모든 사용자들에 대해서는 제한된 문서를 생성하여 그 문서를 특정 사용자와 공유해야 합니다.
**Topics**
+ [AWS Tools for Windows PowerShell 세션 설정 구성](#walkthrough-powershell-settings)
+ [사용할 수 있는 모든 문서 나열](#walkthrough-powershell-all-documents)
+ [PowerShell 명령 또는 스크립트 실행](#walkthrough-powershell-run-script)
+ [`AWS-InstallApplication` 문서를 사용하여 애플리케이션 설치](#walkthrough-powershell-install-application)
+ [`AWS-InstallPowerShellModule` JSON 문서를 사용하여 PowerShell 모듈 설치](#walkthrough-powershell-install-module)
+ [`AWS-JoinDirectoryServiceDomain` JSON 문서를 사용하여 도메인에 관리형 노드 조인](#walkthrough-powershell-domain-join)
+ [`AWS-ConfigureCloudWatch` 문서를 사용하여 Amazon CloudWatch Logs로 Windows 지표 전송](#walkthrough-powershell-windows-metrics)
+ [`AWS-ConfigureWindowsUpdate` 문서를 사용하여 Windows 자동 업데이트 설정 또는 해제](#walkthrough-powershell-enable-windows-update)
+ [Run Command를 사용하여 Windows 업데이트 관리](#walkthough-powershell-windows-updates)
## AWS Tools for Windows PowerShell 세션 설정 구성
**자격 증명 지정**
로컬 컴퓨터에서 **Tools for Windows PowerShell**을 열고 다음 명령을 실행하여 자격 증명을 지정합니다. 구성할 관리형 노드에 대한 관리자 권한이 있거나 AWS Identity and Access Management(IAM)에서 적절한 권한을 부여받아야 합니다. 자세한 내용은 [AWS Systems Manager에 대한 관리형 노드 설정](systems-manager-setting-up-nodes.md) 섹션을 참조하세요.
```
Set-AWSCredentials –AccessKey key-name –SecretKey key-name
```
**기본 AWS 리전 설정**
다음 명령을 실행하여 PowerShell 세션의 리전을 설정합니다. 예제에서는 미국 동부(오하이오) 리전(us-east-2)을 사용합니다. Run Command는 **Amazon Web Services 일반 참조의 [Systems Manager 서비스 엔드포인트](https://docs.aws.amazon.com/general/latest/gr/ssm.html#ssm_region)에 나열된 AWS 리전에서 사용할 수 있습니다.
```
Set-DefaultAWSRegion `
-Region us-east-2
```
## 사용할 수 있는 모든 문서 나열
이 명령을 실행하면 계정에 사용 가능한 모든 문서가 나열됩니다.
```
Get-SSMDocumentList
```
## PowerShell 명령 또는 스크립트 실행
Run Command 및 `AWS-RunPowerShell` 문서를 사용하면 로컬로 로그인한 것처럼 관리형 노드에서 명령이나 스크립트를 실행할 수 있습니다. 명령을 내리거나 로컬 스크립트의 경로를 입력하여 명령을 실행할 수 있습니다.
**참고**
Run Command를 사용할 때 서버와 관리형 노드를 재부팅하여 스크립트를 호출하는 방법은 [명령 실행 시 재부팅 처리](send-commands-reboot.md) 섹션을 참조하세요.
**설명 및 사용 가능한 파라미터 보기**
```
Get-SSMDocumentDescription `
-Name "AWS-RunPowerShellScript"
```
**파라미터에 대한 자세한 내용 보기**
```
Get-SSMDocumentDescription `
-Name "AWS-RunPowerShellScript" | Select -ExpandProperty Parameters
```
### `AWS-RunPowerShellScript` 문서를 사용하여 명령 전송
다음 명령은 두 개의 관리형 노드에 대해 `"C:\Users"` 디렉터리의 내용과 `"C:\"` 디렉터리의 내용을 보여줍니다.
```
$runPSCommand = Send-SSMCommand `
-InstanceIds @("instance-ID-1", "instance-ID-2") `
-DocumentName "AWS-RunPowerShellScript" `
-Comment "Demo AWS-RunPowerShellScript with two instances" `
-Parameter @{'commands'=@('dir C:\Users', 'dir C:\')}
```
**명령 요청 세부 정보 가져오기**
다음 명령은 `CommandId`를 사용하여 두 관리형 노드에서 명령 실행 상태를 가져옵니다. 이 예에서는 이전 명령에서 반환된 `CommandId`를 사용합니다.
```
Get-SSMCommand `
-CommandId $runPSCommand.CommandId
```
이 예에서 명령 상태는 성공, 보류 중 또는 진행 중일 수 있습니다.
**관리형 노드당 명령 정보 가져오기**
다음 명령은 이전 명령의 `CommandId`를 사용하여 관리형 노드 단위로 명령 실행 상태를 가져옵니다.
```
Get-SSMCommandInvocation `
-CommandId $runPSCommand.CommandId
```
**특정 관리형 노드에 대한 응답 데이터로 명령 정보 가져오기**
다음 명령은 특정 관리형 노드에 대한 원래 `Send-SSMCommand` 출력을 반환합니다.
```
Get-SSMCommandInvocation `
-CommandId $runPSCommand.CommandId `
-Details $true `
-InstanceId instance-ID | Select -ExpandProperty CommandPlugins
```
### 명령 취소
다음 명령은 `AWS-RunPowerShellScript` 문서에 대한 `Send-SSMCommand`를 취소합니다.
```
$cancelCommand = Send-SSMCommand `
-InstanceIds @("instance-ID-1","instance-ID-2") `
-DocumentName "AWS-RunPowerShellScript" `
-Comment "Demo AWS-RunPowerShellScript with two instances" `
-Parameter @{'commands'='Start-Sleep –Seconds 120; dir C:\'}
Stop-SSMCommand -CommandId $cancelCommand.CommandId
```
**명령 상태 확인**
다음 명령은 `Cancel` 명령의 상태를 확인합니다.
```
Get-SSMCommand `
-CommandId $cancelCommand.CommandId
```
## `AWS-InstallApplication` 문서를 사용하여 애플리케이션 설치
Run Command 및 `AWS-InstallApplication` 문서를 사용하면 관리형 노드에 애플리케이션을 설치, 복구 또는 제거할 수 있습니다. 이 명령에는 MSI 경로 또는 주소가 필요합니다.
**참고**
Run Command를 사용할 때 서버와 관리형 노드를 재부팅하여 스크립트를 호출하는 방법은 [명령 실행 시 재부팅 처리](send-commands-reboot.md) 섹션을 참조하세요.
**설명 및 사용 가능한 파라미터 보기**
```
Get-SSMDocumentDescription `
-Name "AWS-InstallApplication"
```
**파라미터에 대한 자세한 내용 보기**
```
Get-SSMDocumentDescription `
-Name "AWS-InstallApplication" | Select -ExpandProperty Parameters
```
### `AWS-InstallApplication` 문서를 사용하여 명령 전송
다음 명령은 무인 모드로 관리형 노드에 Python 버전을 설치하고 `C:` 드라이브의 로컬 텍스트 파일에 출력을 로깅합니다.
```
$installAppCommand = Send-SSMCommand `
-InstanceId instance-ID `
-DocumentName "AWS-InstallApplication" `
-Parameter @{'source'='https://www.python.org/ftp/python/2.7.9/python-2.7.9.msi'; 'parameters'='/norestart /quiet /log c:\pythoninstall.txt'}
```
**관리형 노드당 명령 정보 가져오기**
다음 명령은 `CommandId`를 사용하여 명령 실행 상태를 가져옵니다.
```
Get-SSMCommandInvocation `
-CommandId $installAppCommand.CommandId `
-Details $true
```
**특정 관리형 노드에 대한 응답 데이터로 명령 정보 가져오기**
다음 명령은 Python 설치 결과를 반환합니다.
```
Get-SSMCommandInvocation `
-CommandId $installAppCommand.CommandId `
-Details $true `
-InstanceId instance-ID | Select -ExpandProperty CommandPlugins
```
## `AWS-InstallPowerShellModule` JSON 문서를 사용하여 PowerShell 모듈 설치
Run Command를 사용하여 관리형 노드에 PowerShell 모듈을 설치할 수 있습니다. PowerShell 모듈에 대한 자세한 내용은 [Windows PowerShell Modules](https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_modules?view=powershell-6) 섹션을 참조하세요.
**설명 및 사용 가능한 파라미터 보기**
```
Get-SSMDocumentDescription `
-Name "AWS-InstallPowerShellModule"
```
**파라미터에 대한 자세한 내용 보기**
```
Get-SSMDocumentDescription `
-Name "AWS-InstallPowerShellModule" | Select -ExpandProperty Parameters
```
### PowerShell 모듈 설치
다음 명령은 EZOut.zip 파일을 다운로드하여 설치한 다음, 명령을 추가로 실행하여 XPS 뷰어를 설치합니다. 마지막으로 이 명령의 출력이 “amzn-s3-demo-bucket”이라는 S3 버킷으로 업로드됩니다.
```
$installPSCommand = Send-SSMCommand `
-InstanceId instance-ID `
-DocumentName "AWS-InstallPowerShellModule" `
-Parameter @{'source'='https://gallery.technet.microsoft.com/EZOut-33ae0fb7/file/110351/1/EZOut.zip';'commands'=@('Add-WindowsFeature -name XPS-Viewer -restart')} `
-OutputS3BucketName amzn-s3-demo-bucket
```
**관리형 노드당 명령 정보 가져오기**
다음 명령은 `CommandId`를 사용하여 명령 실행 상태를 가져옵니다.
```
Get-SSMCommandInvocation `
-CommandId $installPSCommand.CommandId `
-Details $true
```
**특정 관리형 노드에 대한 응답 데이터로 명령 정보 가져오기**
다음 명령은 특정 `CommandId`에 대한 원래 `Send-SSMCommand` 출력을 반환합니다.
```
Get-SSMCommandInvocation `
-CommandId $installPSCommand.CommandId `
-Details $true | Select -ExpandProperty CommandPlugins
```
## `AWS-JoinDirectoryServiceDomain` JSON 문서를 사용하여 도메인에 관리형 노드 조인
Run Command를 사용하여 AWS Directory Service 도메인에 관리형 노드를 빠르게 조인할 수 있습니다. 이 명령을 실행하기 전에 [디렉터리를 생성](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ms_ad_getting_started_create_directory.html)합니다. 또한 Directory Service에 대해 자세히 알아보는 것이 좋습니다. 자세한 내용은 [AWS Directory Service 관리 안내서](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/)를 참조하세요.
도메인에 관리형 노드를 조인하는 것만 가능합니다. 도메인에서 노드를 제거할 수는 없습니다.
**참고**
Run Command를 사용하여 스크립트를 호출할 관리형 노드에 대한 자세한 내용은 [명령 실행 시 재부팅 처리](send-commands-reboot.md) 섹션을 참조하세요.
**설명 및 사용 가능한 파라미터 보기**
```
Get-SSMDocumentDescription `
-Name "AWS-JoinDirectoryServiceDomain"
```
**파라미터에 대한 자세한 내용 보기**
```
Get-SSMDocumentDescription `
-Name "AWS-JoinDirectoryServiceDomain" | Select -ExpandProperty Parameters
```
### 관리형 노드를 도메인에 조인
다음 명령은 관리되는 노드를 지정된 Directory Service 도메인에 조인하고, 생성된 모든 아웃풋을 예시 Amazon Simple Storage Service(Amazon S3) 버킷에 업로드합니다.
```
$domainJoinCommand = Send-SSMCommand `
-InstanceId instance-ID `
-DocumentName "AWS-JoinDirectoryServiceDomain" `
-Parameter @{'directoryId'='d-example01'; 'directoryName'='ssm.example.com'; 'dnsIpAddresses'=@('192.168.10.195', '192.168.20.97')} `
-OutputS3BucketName amzn-s3-demo-bucket
```
**관리형 노드당 명령 정보 가져오기**
다음 명령은 `CommandId`를 사용하여 명령 실행 상태를 가져옵니다.
```
Get-SSMCommandInvocation `
-CommandId $domainJoinCommand.CommandId `
-Details $true
```
**특정 관리형 노드에 대한 응답 데이터로 명령 정보 가져오기**
이 명령은 특정 `CommandId`에 대한 원래 `Send-SSMCommand`의 출력을 반환합니다.
```
Get-SSMCommandInvocation `
-CommandId $domainJoinCommand.CommandId `
-Details $true | Select -ExpandProperty CommandPlugins
```
## `AWS-ConfigureCloudWatch` 문서를 사용하여 Amazon CloudWatch Logs로 Windows 지표 전송
Windows용 이벤트 추적(ETW) 로그 및 시스템, 보안, 애플리케이션의 Windows Server 메시지를 Amazon CloudWatch Logs로 보낼 수 있습니다. 로그 기록을 처음 활성화하면 Systems Manager는 애플리케이션, 보안, ETW 로그를 업로드하기 시작한 시간부터 1분 내에 생성된 모든 로그를 전송합니다. 시작한 시간보다 1분 전에 발생한 로그는 포함되지 않습니다. 로깅을 해제했다가 나중에 다시 설정하면 Systems Manager는 중단된 시간부터 로그를 전송합니다. 사용자 정의 로그 파일 및 인터넷 정보 서비스(IIS) 로그의 경우 Systems Manager는 시작 지점부터 로그 파일을 읽습니다. 또한 Systems Manager는 성능 카운터 데이터를 CloudWatch Logs로 전송할 수도 있습니다.
이전에 EC2Config에서 CloudWatch 통합을 설정한 경우 Systems Manager 설정이 `C:\Program Files\Amazon\EC2ConfigService\Settings\AWS.EC2.Windows.CloudWatch.json` 파일의 관리형 노드에 로컬로 저장된 모든 설정을 재정의합니다. EC2Config를 사용하여 단일 관리형 노드에서 성능 카운터 및 로그를 관리하는 방법에 대한 자세한 내용은 *Amazon CloudWatch 사용 설명서*의 [CloudWatch 에이전트를 사용하여 Amazon EC2 인스턴스 및 온프레미스 서버로부터 지표 및 로그 수집](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Install-CloudWatch-Agent.html)을 참조하세요.
**설명 및 사용 가능한 파라미터 보기**
```
Get-SSMDocumentDescription `
-Name "AWS-ConfigureCloudWatch"
```
**파라미터에 대한 자세한 내용 보기**
```
Get-SSMDocumentDescription `
-Name "AWS-ConfigureCloudWatch" | Select -ExpandProperty Parameters
```
### CloudWatch로 애플리케이션 로그 전송
다음 명령은 관리형 노드를 구성하고 Windows 애플리케이션 로그를 CloudWatch로 이동합니다.
```
$cloudWatchCommand = Send-SSMCommand `
-InstanceID instance-ID `
-DocumentName "AWS-ConfigureCloudWatch" `
-Parameter @{'properties'='{"engineConfiguration": {"PollInterval":"00:00:15", "Components":[{"Id":"ApplicationEventLog", "FullName":"AWS.EC2.Windows.CloudWatch.EventLog.EventLogInputComponent,AWS.EC2.Windows.CloudWatch", "Parameters":{"LogName":"Application", "Levels":"7"}},{"Id":"CloudWatch", "FullName":"AWS.EC2.Windows.CloudWatch.CloudWatchLogsOutput,AWS.EC2.Windows.CloudWatch", "Parameters":{"Region":"region", "LogGroup":"my-log-group", "LogStream":"instance-id"}}], "Flows":{"Flows":["ApplicationEventLog,CloudWatch"]}}}'}
```
**관리형 노드당 명령 정보 가져오기**
다음 명령은 `CommandId`를 사용하여 명령 실행 상태를 가져옵니다.
```
Get-SSMCommandInvocation `
-CommandId $cloudWatchCommand.CommandId `
-Details $true
```
**특정 관리형 노드에 대한 응답 데이터로 명령 정보 가져오기**
다음 명령은 Amazon CloudWatch 구성 결과를 반환합니다.
```
Get-SSMCommandInvocation `
-CommandId $cloudWatchCommand.CommandId `
-Details $true `
-InstanceId instance-ID | Select -ExpandProperty CommandPlugins
```
### `AWS-ConfigureCloudWatch` 문서를 사용하여 CloudWatch로 성능 카운터 전송
다음 명령 예는 CloudWatch로 성능 카운터를 업로드합니다. 자세한 내용은 *[Amazon CloudWatch 사용 설명서](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/)*를 참조하세요.
```
$cloudWatchMetricsCommand = Send-SSMCommand `
-InstanceID instance-ID `
-DocumentName "AWS-ConfigureCloudWatch" `
-Parameter @{'properties'='{"engineConfiguration": {"PollInterval":"00:00:15", "Components":[{"Id":"PerformanceCounter", "FullName":"AWS.EC2.Windows.CloudWatch.PerformanceCounterComponent.PerformanceCounterInputComponent,AWS.EC2.Windows.CloudWatch", "Parameters":{"CategoryName":"Memory", "CounterName":"Available MBytes", "InstanceName":"", "MetricName":"AvailableMemory", "Unit":"Megabytes","DimensionName":"", "DimensionValue":""}},{"Id":"CloudWatch", "FullName":"AWS.EC2.Windows.CloudWatch.CloudWatch.CloudWatchOutputComponent,AWS.EC2.Windows.CloudWatch", "Parameters":{"AccessKey":"", "SecretKey":"","Region":"region", "NameSpace":"Windows-Default"}}], "Flows":{"Flows":["PerformanceCounter,CloudWatch"]}}}'}
```
## `AWS-ConfigureWindowsUpdate` 문서를 사용하여 Windows 자동 업데이트 설정 또는 해제
Run Command 및 `AWS-ConfigureWindowsUpdate` 문서를 사용하면 Windows Server 관리형 노드에서 Windows 자동 업데이트를 설정 또는 해제할 수 있습니다. 이 명령은 Windows Update 에이전트를 구성하여 사용자가 지정하는 요일과 시간에 Windows Update를 다운로드 및 설치합니다. 업데이트에 재부팅이 필요한 경우, 업데이트가 설치되고 15분 후 관리형 노드가 자동으로 재부팅됩니다. 이 명령을 사용하여 업데이트 설치가 아닌 확인을 위해 Windows Update를 구성할 수도 있습니다. `AWS-ConfigureWindowsUpdate` 문서는 Windows Server 2012 이상 버전에서 공식적으로 지원됩니다.
**설명 및 사용 가능한 파라미터 보기**
```
Get-SSMDocumentDescription `
–Name "AWS-ConfigureWindowsUpdate"
```
**파라미터에 대한 자세한 내용 보기**
```
Get-SSMDocumentDescription `
-Name "AWS-ConfigureWindowsUpdate" | Select -ExpandProperty Parameters
```
### Windows 자동 업데이트 설정
다음 명령은 Windows Update를 구성하여 매일 오후 10시에 업데이트를 자동으로 다운로드하고 설치합니다.
```
$configureWindowsUpdateCommand = Send-SSMCommand `
-InstanceId instance-ID `
-DocumentName "AWS-ConfigureWindowsUpdate" `
-Parameters @{'updateLevel'='InstallUpdatesAutomatically'; 'scheduledInstallDay'='Daily'; 'scheduledInstallTime'='22:00'}
```
**Windows 자동 업데이트 허용을 위한 명령 상태 보기**
다음 명령은 `CommandId`를 사용하여 Windows 자동 업데이트 허용을 위한 명령 실행 상태를 가져옵니다.
```
Get-SSMCommandInvocation `
-Details $true `
-CommandId $configureWindowsUpdateCommand.CommandId | Select -ExpandProperty CommandPlugins
```
### Windows 자동 업데이트 해제
다음 명령은 시스템에서 업데이트를 확인하지만 관리형 노드를 자동으로 업데이트하지 않도록 Windows 업데이트 알림 수준을 낮춥니다.
```
$configureWindowsUpdateCommand = Send-SSMCommand `
-InstanceId instance-ID `
-DocumentName "AWS-ConfigureWindowsUpdate" `
-Parameters @{'updateLevel'='NeverCheckForUpdates'}
```
**Windows 자동 업데이트 해제를 위한 명령 상태 보기**
다음 명령은 `CommandId`를 사용하여 Windows 자동 업데이트 해제를 위한 명령 실행 상태를 가져옵니다.
```
Get-SSMCommandInvocation `
-Details $true `
-CommandId $configureWindowsUpdateCommand.CommandId | Select -ExpandProperty CommandPlugins
```
## Run Command를 사용하여 Windows 업데이트 관리
Run Command 및 `AWS-InstallWindowsUpdates` 문서를 사용하면 Windows Server 관리형 노드에 대한 업데이트를 관리할 수 있습니다. 이 명령은 관리형 노드에 누락된 업데이트를 스캔하거나 설치하고 다음 설치를 선택적으로 재부팅합니다. 또한 사용자 환경에 설치할 업데이트에 대한 적절한 분류 및 심각도 수준을 지정할 수 있습니다.
**참고**
Run Command를 사용할 때 서버와 관리형 노드를 재부팅하여 스크립트를 호출하는 방법은 [명령 실행 시 재부팅 처리](send-commands-reboot.md) 섹션을 참조하세요.
다음 예제에서는 지정된 Windows 업데이트 관리 작업을 수행하는 방법을 보여 줍니다.
### 누락된 Windows 업데이트를 모두 검색
```
Send-SSMCommand `
-InstanceId instance-ID `
-DocumentName "AWS-InstallWindowsUpdates" `
-Parameters @{'Action'='Scan'}
```
### 특정 Windows 업데이트 설치
```
Send-SSMCommand `
-InstanceId instance-ID `
-DocumentName "AWS-InstallWindowsUpdates" `
-Parameters @{'Action'='Install';'IncludeKbs'='kb-ID-1,kb-ID-2,kb-ID-3';'AllowReboot'='True'}
```
### 누락된 중요 Windows 업데이트 설치
```
Send-SSMCommand `
-InstanceId instance-ID `
-DocumentName "AWS-InstallWindowsUpdates" `
-Parameters @{'Action'='Install';'SeverityLevels'='Important';'AllowReboot'='True'}
```
### 누락된 Windows 업데이트를 특정 항목을 배제하고 설치
```
Send-SSMCommand `
-InstanceId instance-ID `
-DocumentName "AWS-InstallWindowsUpdates" `
-Parameters @{'Action'='Install';'ExcludeKbs'='kb-ID-1,kb-ID-2';'AllowReboot'='True'}
```
# Systems Manager Run Command 문제 해결
AWS Systems Manager의 도구인 Run Command는 각 명령 실행에 대한 상태 정보를 제공합니다. 명령 상태에 대한 자세한 내용은 [명령 상태 이해](monitor-commands.md) 섹션을 참조하세요. 이 단원의 내용을 참조하여 Run Command와 관련된 문제를 해결할 수도 있습니다.
**Topics**
+ [일부 관리형 노드가 누락됨](#where-are-instances)
+ [스크립트의 단계가 실패했지만 전체 상태는 'succeeded(성공)'입니다.](#ts-exit-codes)
+ [SSM Agent가 제대로 실행되지 않음](#ts-ssmagent-linux)
## 일부 관리형 노드가 누락됨
**명령 실행(Run a command)** 페이지에서 실행할 SSM 문서를 선택하고 **대상(Targets)** 섹션에서 **수동으로 인스턴스 선택(Manually selecting instances)**을 선택한 후 명령을 실행하도록 선택할 수 있는 관리형 노드 목록이 표시됩니다.
예상한 관리형 노드가 목록에 없으면 [관리형 노드 가용성 문제 해결](fleet-manager-troubleshooting-managed-nodes.md)에서 문제 해결 팁을 참조하세요.
관리형 노드를 생성, 활성화, 재부팅 또는 재시작하거나, 노드에 Run Command를 설치하거나, AWS Identity and Access Management(IAM) 인스턴스 프로파일을 노드에 연결한 후, 목록에 관리형 노드가 추가되는 데 몇 분 정도 걸릴 수 있습니다.
## 스크립트의 단계가 실패했지만 전체 상태는 'succeeded(성공)'입니다.
Run Command를 사용하여 스크립트에서 종료 코드를 처리하는 방법을 정의할 수 있습니다. 기본적으로 스크립트에서 실행된 마지막 명령의 종료 코드는 전체 스크립트의 종료 코드로 보고됩니다. 그러나 마지막 명령 이전에 명령이 실패하는 경우 셸 조건문을 포함하여 스크립트를 종료할 수 있습니다. 자세한 내용 및 예제는 [명령에 종료 코드 지정](run-command-handle-exit-status.md#command-exit-codes) 섹션을 참조하세요.
## SSM Agent가 제대로 실행되지 않음
Run Command를 사용하여 명령을 실행하는 데 문제가 있는 경우 SSM Agent에 문제가 있을 수 있습니다. SSM Agent 문제 조사에 대한 자세한 내용은 [SSM Agent 문제 해결](troubleshooting-ssm-agent.md) 섹션을 참조하세요.
# AWS Systems Manager Session Manager
Session Manager는 완전 관리형 AWS Systems Manager 도구입니다. Session Manager를 사용하여 Amazon Elastic Compute Cloud(Amazon EC2) 인스턴스, 엣지 디바이스, 온프레미스 서버 및 가상 머신을 관리할 수 있습니다. 대화형 원클릭 브라우저 기반 쉘 또는 AWS Command Line Interface(AWS CLI)을 사용할 수 있습니다. Session Manager는 인바운드 포트를 열고 배스천 호스트를 유지 관리하거나 SSH 키를 관리할 필요 없이 안전한 노드 관리 기능을 제공합니다. 또한 Session Manager를 통해 노드에 대한 제어된 액세스를 요구하는 회사 정책, 엄격한 보안 관행을 손쉽게 준수하고, 관리형 노드 액세스 세부 정보가 포함된 로그를 제공하는 동시에 최종 사용자에게 관리형 노드에 대한 간단한 원 클릭 교차 플랫폼 액세스를 제공합니다. Session Manager를 시작하려면 [Systems Manager 콘솔](https://console.aws.amazon.com/systems-manager/session-manager)을 엽니다. 탐색 창에서 **Session Manager**를 선택합니다.
## Session Manager가 조직에 주는 이점은 무엇인가요?
Session Manager에서 제공하는 이점은 다음과 같습니다.
+ **IAM 정책을 사용하여 관리형 노드에 대한 중앙 집중식 액세스 제어**
관리자가 한 곳에서 관리형 노드에 대한 액세스 권한을 부여하고 취소할 수 있습니다. AWS Identity and Access Management(IAM) 정책만 사용하는 경우에는 Session Manager를 사용할 수 있는 조직 내 개별 사용자 또는 그룹과 이들이 액세스할 수 있는 관리형 노드를 제어할 수 있습니다.
+ **인바운드 포트를 열 필요가 없고 Bastion Host 또는 SSH 키를 관리할 필요가 없음**
관리형 노드에 인바운드 PowerShell 포트와 원격 PowerShell 포트를 열어 두면 관리형 노드에서 개체가 권한이 없거나 악의적인 명령을 실행할 위험이 매우 높아집니다. Session Manager에서는 이러한 인바운드 포트를 닫도록 하고, SSH 키 및 인증서, Bastion Host 및 점프박스를 관리할 필요가 없도록 해 보안 태세를 강화하도록 합니다.
+ **클릭 한 번으로 콘솔 및 CLI에서 관리형 노드에 액세스**
AWS Systems Manager 콘솔 또는 Amazon EC2 콘솔을 사용하여 한 번의 클릭으로 세션을 시작할 수 있습니다. AWS CLI를 사용하여 단일 명령 또는 일련의 명령을 실행하는 세션을 시작할 수도 있습니다. 관리형 노드에 대한 권한이 SSH 키 또는 기타 메커니즘을 대신 IAM 정책을 통해 제공되기 때문에 연결 시간이 크게 줄어듭니다.
+ **[하이브리드 및 멀티클라우드](operating-systems-and-machine-types.md#supported-machine-types) 환경의 Amazon EC2 인스턴스와 비 EC2 관리형 노드에 모두 연결**
[하이브리드 및 멀티클라우드](operating-systems-and-machine-types.md#supported-machine-types) 환경의 Amazon Elastic Compute Cloud(Amazon EC2) 인스턴스와 비 EC2 관리형 노드에 모두 연결할 수 있습니다.
Session Manager를 사용하여 비EC2 노드에 연결하려면 먼저 고급 인스턴스 티어를 활성화해야 합니다. **고급 인스턴스 티어를 사용하는 데는 요금이 부과됩니다.** 그러나 Session Manager를 사용하여 EC2 인스턴스에 연결하는 데는 추가 요금이 부과되지 않습니다. 자세한 내용은 [인스턴스 티어 구성](fleet-manager-configure-instance-tiers.md) 섹션을 참조하세요.
+ **포트 전달**
원격 관리형 노드 내부의 포트를 클라이언트의 로컬 포트로 리디렉션합니다. 그런 다음 로컬 포트에 연결하고 노드 내부에서 실행 중인 서버 애플리케이션에 액세스합니다.
+ **Windows, Linux 및 macOS에 대한 크로스 플랫폼 지원**
Session Manager에서는 단일 도구의 Windows, Linux 및 macOS에 대한 지원을 제공합니다. 예를 들면, Windows Server 관리형 노드의 Linux 및 macOS 관리형 노드 또는 RDP 연결에 SSH 클라이언트를 사용할 필요가 없습니다.
+ **세션 활동 로그**
조직의 작업 또는 보안 요구 사항을 충족하기 위해 관리형 노드에 대한 연결과 해당 인스턴스에서 실행된 명령에 대한 기록을 제공해야 할 수 있습니다. 또한 조직의 사용자가 세션 활동을 시작 또는 종료할 때 알림을 받을 수도 있습니다.
로깅 기능은 다음 AWS 서비스와의 통합을 통해 제공됩니다.
+ **AWS CloudTrail** - AWS CloudTrail에서는 AWS 계정에서 수행된 Session Manager API 호출에 대한 정보를 캡처해 지정한 Amazon Simple Storage Service(Amazon S3) 버킷에 저장되는 로그 파일에 기록합니다. 계정에 대한 모든 CloudTrail 로그를 저장하는 데 버킷 하나가 사용됩니다. 자세한 내용은 [AWS CloudTrail를 사용하여 AWS Systems Manager API 호출 로깅](monitoring-cloudtrail-logs.md) 섹션을 참조하세요.
+ **Amazon Simple Storage Service** - 디버깅 및 문제 해결을 위해 선택한 Amazon S3 버킷에 세션 로그 데이터를 저장하도록 선택할 수 있습니다. 로그 데이터는 AWS KMS key를 사용하여 암호화를 적용하거나 적용하지 않은 상태로 Amazon S3 버킷으로 전송할 수 있습니다. 자세한 내용은 [Amazon S3를 사용하여 세션 데이터 로깅(콘솔)](session-manager-logging-s3.md) 섹션을 참조하세요.
+ **Amazon CloudWatch Logs** - CloudWatch Logs를 사용하면 다양한 AWS 서비스의 로그 파일을 모니터링, 저장 및 액세스할 수 있습니다. 디버깅 및 문제 해결을 위해 CloudWatch Logs 로그 그룹으로 세션 로그 데이터를 전송할 수 있습니다. 로그 데이터는 KMS 키를 사용하여 AWS KMS 암호화를 적용하거나 적용하지 않은 상태로 로그 그룹으로 스트리밍할 수 있습니다. 자세한 내용은 [Amazon CloudWatch Logs를 사용하여 세션 데이터 로깅(콘솔)](session-manager-logging-cloudwatch-logs.md) 섹션을 참조하세요.
+ **Amazon EventBridge** 및 **Amazon Simple Notification Service** - EventBridge를 사용하면 지정한 AWS 리소스에 변경 사항이 발생할 때 이를 감지하는 규칙을 설정할 수 있습니다. 조직 내 사용자가 세션을 시작 또는 중지하면 이를 감지하는 규칙을 생성하면 Amazon SNS를 통해 해당 이벤트에 대한 알림(예: 문자 메시지 또는 이메일 메시지)을 받을 수 있습니다. 또한 다른 응답을 시작하도록 CloudWatch 이벤트를 구성할 수도 있습니다. 자세한 내용은 [Amazon EventBridge를 사용하여 세션 활동 모니터링(콘솔)](session-manager-auditing.md#session-manager-auditing-eventbridge-events) 섹션을 참조하세요.
**참고**
포트 전달 또는 SSH를 통해 연결하는 Session Manager 세션에는 로깅을 사용할 수 없습니다. 이는 SSH가 AWS CLI 엔드포인트와 Session Manager 엔드포인트 간에 설정된 보안 TLS 연결 내의 모든 세션 데이터를 암호화하고 Session Manager는 SSH 연결을 위한 터널 역할만 하기 때문입니다.
## Session Manager는 누가 사용해야 하나요?
+ 보안 태세를 개선하고, 관리형 노드의 액세스 제어를 중앙에서 관리하여 운영 오버헤드를 줄이고, 인바운드 노드를 줄이려고 하는 모든 AWS 고객
+ 관리형 노드 액세스와 활동을 모니터링하고 추적하며, 관리형 노드에서 인바운드 포트를 닫거나 퍼블릭 IP 없이 관리형 노드와 연결하기를 원하는 정보 보안 전문가
+ 단일 위치의 액세스 권한을 부여하고 취소하며 Linux, macOS 및 Windows Server 관리형 노드의 솔루션 하나를 사용자에게 제공하려는 관리자입니다.
+ SSH 키를 제공할 필요 없이 브라우저 또는 AWS CLI에서 한 번의 클릭으로 관리형 노드에 연결하고자 하는 사용자
## Session Manager의 주요 기능은 무엇입니까?
+ **Windows Server, Linux 및 macOS 관리형 노드 지원**
Session Manager를 사용하면 Amazon Elastic Compute Cloud(EC2) 인스턴스, 엣지 디바이스, 온프레미스 서버 및 가상 머신과의 보안 연결을 설정할 수 있습니다. 지원되는 운영 체제 유형의 목록은 [Session Manager 설정](session-manager-getting-started.md) 섹션을 참조하세요.
**참고**
Session Manager온프레미스 머신에 대한 지원은 고급 인스턴스 티어에만 제공됩니다. 자세한 내용은 [고급 인스턴스 티어 설정](fleet-manager-enable-advanced-instances-tier.md) 섹션을 참조하세요.
+ **콘솔 CLI 및 SDK를 통해 Session Manager 기능에 액세스**
다음과 같은 방식으로 Session Manager 작업을 수행할 수 있습니다.
**AWS Systems Manager 콘솔**에서는 관리자 및 최종 사용자 둘 다를 위한 모든 Session Manager 기능에 액세스할 수 있습니다. Systems Manager 콘솔을 사용하여 세션에 연결된 모든 태스크를 수행할 수 있습니다.
Amazon EC2 콘솔에서는 최종 사용자가 세션 권한이 부여된 EC2 인스턴스에 연결할 수 있는 기능을 제공합니다.
**AWS CLI**에서는 최종 사용자를 위한 Session Manager 기능에 액세스할 수 있습니다. AWS CLI를 사용해 세션을 시작하고, 세션 목록을 보고, 세션을 영구히 종료할 수 있습니다.
**참고**
AWS CLI를 사용하여 세션 명령을 실행하려면 CLI의 버전 1.16.12(또는 이상)를 사용하고 로컬 시스템에 Session Manager 플러그인을 설치해야 합니다. 자세한 내용은 [AWS CLI의 Session Manager 플러그인 설치](session-manager-working-with-install-plugin.md) 섹션을 참조하세요. GitHub의 플러그인을 보려면 [session-manager-plugin](https://github.com/aws/session-manager-plugin)을 참조하세요.
+ **IAM 액세스 제어**
IAM 정책 사용을 통해 관리형 노드에 대한 세션을 시작할 조직 내 멤버와 해당 멤버가 액세스할 수 있는 노드를 제어할 수 있습니다. 또한 관리형 노드에 대한 임시 액세스를 제공할 수도 있습니다. 예를 들어, 대기 중인 엔지니어(또는 대기 중인 엔지니어 그룹)에게 교대 근무 중에만 프로덕션 서버에 액세스할 수 있는 권한을 부여하려고 할 수 있습니다.
+ **로깅 지원**
Session Manager는 다른 여러 AWS 서비스와의 통합을 통해 AWS 계정에서 세션 기록을 로깅할 수 있는 옵션을 제공합니다. 자세한 내용은 [세션 활동 로그](session-manager-auditing.md) 및 [세션 로깅 활성화 및 비활성화](session-manager-logging.md)(을)를 참조하세요.
+ **구성 가능한 셸 프로파일**
Session Manager는 세션 내에서 기본 설정을 구성할 수 있는 옵션을 제공합니다. 이러한 사용자 정의 가능한 프로파일을 사용하면 셸 기본 설정, 환경 변수, 작업 디렉터리 및 세션 시작 시 여러 명령 실행과 같은 기본 설정을 정의할 수 있습니다.
+ **고객 키 데이터 암호화 지원**
Amazon Simple Storage Service(Amazon S3) 버킷으로 전송하거나 CloudWatch Logs 로그 그룹으로 스트리밍하는 세션 데이터 로그를 암호화하도록 Session Manager를 구성할 수 있습니다. 세션 중에 클라이언트 시스템과 관리형 노드 사이에 전송되는 데이터를 추가로 암호화하도록 Session Manager을 구성할 수도 있습니다. 자세한 내용은 [세션 로깅 활성화 및 비활성화](session-manager-logging.md) 및 [세션 기본 설정 구성](session-manager-getting-started-configure-preferences.md)을 참조하세요.
+ **퍼블릭 IP 주소 없이 관리형 노드에 대한 AWS PrivateLink 지원**
AWS PrivateLink로 Systems Manager용 VPC 엔드포인트를 설정하여 세션을 더욱 안전하게 보호할 수도 있습니다. AWS PrivateLink는 관리형 노드, Systems Manager 및 Amazon EC2 간의 모든 네트워크 트래픽을 Amazon 네트워크로 제한합니다. 자세한 내용은 [Systems Manager용 VPC 엔드포인트를 사용하여 EC2 인스턴스의 보안 개선](setup-create-vpc.md)을 참조하세요.
+ **터널링**
세션에서 세션 유형 AWS Systems Manager(SSM) 문서를 사용하여 트래픽을 터널링합니다(예: 클라이언트 시스템의 로컬 포트와 관리형 노드의 원격 포트 간 http 또는 사용자 정의 프로토콜).
+ **대화형 명령**
세션을 사용하여 단일 명령을 대화형으로 실행하고 사용자가 관리형 노드에서 할 수 있는 것을 관리할 방법을 제공하는 세션 유형 SSM 문서를 생성합니다.
## 세션이란 무엇입니까?
세션은 Session Manager를 사용한 관리형 노드 연결입니다. 세션은 클라이언트(사용자) 와 명령에 대한 입력 및 출력을 스트리밍하는 원격 관리형 노드 간의 안전한 양방향 통신 채널을 기반으로 합니다. 클라이언트와 관리형 노드 간의 트래픽은 TLS 1.2를 사용하여 암호화되며, 연결을 생성하기 위한 요청은 SigV4를 사용하여 서명됩니다. 이 양방향 통신을 통해 관리형 노드에 대한 대화형 bash 및 PowerShell 액세스가 가능합니다. AWS Key Management Service(AWS KMS) 키를 사용하여 기본 TLS 암호화 이상으로 데이터를 추가로 암호화할 수도 있습니다.
예를 들어, John이 IT 부서의 대기 중인 엔지니어라고 생각해 보겠습니다. John은 원격으로 관리형 노드에 액세스해야 하는 문제에 대한 알림을 받습니다(예: 문제 해결 또는 노드에 대한 간단한 구성 옵션을 변경하는 지침이 필요한 장애). John은 AWS Systems Manager 콘솔, Amazon EC2 콘솔 또는 AWS CLI를 사용해 관리형 노드에 연결하는 세션을 시작하고, 노드에서 태스크를 완료하는 데 필요한 명령을 실행한 다음 세션을 종료합니다.
John이 세션을 시작하라는 첫 번째 명령을 보내면 Session Manager서비스에서 John의 ID를 인증하고, IAM 정책에 따라 John에게 부여된 권한을 확인한 다음 구성 설정(예: 세션에 대해 허용된 제한 확인)을 확인하고 SSM Agent에 양방향 연결을 열라는 메시지를 보냅니다. 연결이 설정되어 John이 다음 명령을 입력하면 SSM Agent의 명령 출력이 이 통신 채널로 업로드되고 다시 John의 로컬 시스템으로 전송됩니다.
**Topics**
+ [Session Manager가 조직에 주는 이점은 무엇인가요?](#session-manager-benefits)
+ [Session Manager는 누가 사용해야 하나요?](#session-manager-who)
+ [Session Manager의 주요 기능은 무엇입니까?](#session-manager-features)
+ [세션이란 무엇입니까?](#what-is-a-session)
+ [Session Manager 설정](session-manager-getting-started.md)
+ [Session Manager 작업](session-manager-working-with.md)
+ [세션 활동 로그](session-manager-auditing.md)
+ [세션 로깅 활성화 및 비활성화](session-manager-logging.md)
+ [Session 문서 스키마](session-manager-schema.md)
+ [Session Manager 문제 해결](session-manager-troubleshooting.md)
# Session Manager 설정
AWS Systems Manager를 사용하여 계정 내 Session Manager 관리형 노드에 연결하기 전에 다음 주제의 단계를 완료합니다.
**Topics**
+ [1단계: Session Manager 사전 조건 완료](session-manager-prerequisites.md)
+ [2단계: Session Manager의 인스턴스 권한 확인 또는 추가](session-manager-getting-started-instance-profile.md)
+ [3단계: 관리형 노드에 대한 세션 액세스 제어](session-manager-getting-started-restrict-access.md)
+ [4단계: 세션 기본 설정 구성](session-manager-getting-started-configure-preferences.md)
+ [5단계: (선택 사항) 세션의 명령에 대한 액세스 제한](session-manager-restrict-command-access.md)
+ [6단계: (옵션) AWS PrivateLink를 사용하여 Session Manager에 대한 VPC 엔드포인트 설정](session-manager-getting-started-privatelink.md)
+ [7단계: (옵션) ssm-user 계정 관리 권한 설정 또는 해제](session-manager-getting-started-ssm-user-permissions.md)
+ [8단계: (선택 사항) Session Manager를 통한 SSH 연결에 대한 권한 허용 및 제어](session-manager-getting-started-enable-ssh-connections.md)
# 1단계: Session Manager 사전 조건 완료
Session Manager 사용을 시작하기 전에 환경이 다음 요구 사항을 충족하는지 확인하세요.
**Session Manager 필수 조건**
| 요구 사항 | 설명 |
| --- | --- |
| 지원되는 운영 체제 | Session Manager에서는 **고급 인스턴스 티어를 사용하는 [하이브리드 및 멀티클라우드](operating-systems-and-machine-types.md#supported-machine-types) 환경의 비 EC2 시스템 외에 Amazon Elastic Compute Cloud(Amazon EC2) 연결도 지원합니다. Session Manager에서 지원하는 운영 체제 버전은 다음과 같습니다. Session Manager에서는 **고급 인스턴스 티어를 사용하는 [하이브리드 및 멀티클라우드](operating-systems-and-machine-types.md#supported-machine-types) 환경의 EC2 인스턴스, 엣지 디바이스, 온프레미스 서버 및 가상 머신을 지원합니다. 전용 인스턴스에 대한 자세한 내용은 [인스턴스 티어 구성](fleet-manager-configure-instance-tiers.md) 섹션을 참조하세요. **Linux 및 **macOS**** Session Manager에서는 AWS Systems Manager에서 지원되는 모든 Linux 및 macOS버전을 지원합니다. 자세한 내용은 [지원되는 운영 체제 및 시스템 유형](operating-systems-and-machine-types.md) 섹션을 참조하세요. ** Windows ** Session Manager는 버전 Windows Server 2012 이상을 지원합니다. Microsoft Windows Server 2016 Nano는 지원되지 않습니다. |
| SSM Agent | 세션을 통해 연결하려는 관리형 노드에 AWS Systems Manager SSM Agent 버전 2.3.68.0 이상이 설치되어 있어야 합니다. AWS Key Management Service(AWS KMS)에서 생성한 키를 사용하여 세션 데이터를 암호화하는 옵션을 사용하려면 버전 2.3.539.0 이상의 SSM Agent가 관리형 노드에 설치되어 있어야 합니다. 세션에서 셸 프로파일을 사용하려면 관리형 노드에 SSM Agent 버전 3.0.161.0 이상이 설치되어 있어야 합니다. Session Manager 포트 전달 또는 SSH 세션을 시작하려면 관리형 노드에 SSM Agent 버전 3.0.222.0 이상이 설치되어 있어야 합니다. Amazon CloudWatch Logs를 사용하여 세션 데이터를 스트리밍하려면 관리형 노드에 SSM Agent 버전 3.0.284.0 이상이 설치되어 있어야 합니다. 인스턴스에서 실행 중인 버전 번호를 확인하는 방법에 대한 자세한 내용은 [SSM Agent 버전 번호 확인](ssm-agent-get-version.md) 섹션을 참조하세요. SSM Agent 수동 설치 또는 자동 업데이트에 대한 자세한 내용은 [SSM Agent 작업](ssm-agent.md) 섹션을 참조하세요. ssm-user 계정 정보 SSM Agent의 버전 2.3.50.0부터 에이전트는 `ssm-user`라는 루트 또는 관리자 권한으로 관리형 노드에 사용자 계정을 생성합니다. (2.3.612.0 이전 버전에서는 SSM Agent가 시작되거나 다시 시작될 때 계정이 생성됩니다. 버전 2.3.612.0 이상에서는 관리형 노드에서 세션이 처음 시작될 때 `ssm-user`가 생성됩니다.) 세션은 이 사용자 계정의 관리자 자격 증명을 사용하여 시작됩니다. 이 계정에 대한 관리 제어 제한에 대한 자세한 내용은 [ssm-user 계정 관리 권한 설정 또는 해제](session-manager-getting-started-ssm-user-permissions.md)를 참조하세요. Windows Server 도메인 컨트롤러의 ssm-user SSM Agent 버전 2.3.612.0부터 `ssm-user` 계정은 Windows Server 도메인 컨트롤러로 사용되는 관리형 노드에 자동으로 생성되지 않습니다. Windows Server 시스템에서 Session Manager를 도메인 컨트롤러로 사용하려면 `ssm-user` 계정이 없는 경우 수동으로 생성하고 사용자에게 도메인 관리자 권한을 할당해야 합니다. Windows Server에서 SSM Agent는 세션이 시작될 때마다 `ssm-user` 계정에 대한 새 암호를 설정하므로 계정을 만들 때 암호를 지정할 필요가 없습니다. |
| 엔드포인트에 연결 | 연결하려는 관리형 노드는 다음 엔드포인트에 대한 HTTPS(포트 443) 아웃바운드 트래픽도 허용해야 합니다. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/systems-manager/latest/userguide/session-manager-prerequisites.html) 자세한 내용은 다음 항목을 참조하세요. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/systems-manager/latest/userguide/session-manager-prerequisites.html) 또는 인터페이스 엔드포인트를 사용하여 필요한 엔드포인트에 연결할 수 있습니다. 자세한 내용은 [6단계: (옵션) AWS PrivateLink를 사용하여 Session Manager에 대한 VPC 엔드포인트 설정](session-manager-getting-started-privatelink.md) 섹션을 참조하세요. |
| AWS CLI | (옵션) AWS Systems Manager 콘솔 또는 Amazon EC2 콘솔 대신 AWS Command Line Interface(AWS CLI)를 사용하여 세션을 시작한 경우 로컬 시스템에 CLI 버전 1.16.12 이상이 설치되어 있어야 합니다. `aws --version`을 호출해 버전을 확인할 수 있습니다. CLI를 설치하거나 업그레이드해야 하는 경우 AWS Command Line Interface 사용 설명서의 [AWS Command Line Interface 설치](https://docs.aws.amazon.com/cli/latest/userguide/installing.html)를 참조하세요. SSM Agent의 업데이트된 버전은 Systems Manager에 새 도구가 추가되거나 기존 도구가 업데이트될 때마다 릴리스됩니다. 최신 버전의 에이전트를 사용하지 못하면 관리형 노드에서 다양한 Systems Manager 도구를 사용하지 못할 수 있습니다. 이러한 이유로 시스템의 SSM Agent 상태를 최신 상태로 유지하는 프로세스를 자동화하는 것이 좋습니다. 자세한 내용은 [SSM Agent 업데이트 자동화](ssm-agent-automatic-updates.md) 섹션을 참조하세요. SSM Agent 업데이트에 대해 알림을 수신하려면 GitHub에서 [SSM Agent 릴리스 정보](https://github.com/aws/amazon-ssm-agent/blob/mainline/RELEASENOTES.md) 페이지를 구독합니다. 또한 CLI를 사용해 Session Manager로 노드를 관리하려면 먼저, 로컬 시스템에 Session Manager 플러그 인을 설치해야 합니다. 자세한 내용은 [AWS CLI의 Session Manager 플러그인 설치](session-manager-working-with-install-plugin.md) 섹션을 참조하세요. |
| advanced-instances 티어 활성화([하이브리드 및 멀티클라우드](operating-systems-and-machine-types.md#supported-machine-types) 환경) | Session Manager를 사용하여 비 EC2 시스템에 연결하려면 하이브리드 정품 인증을 생성하여 비 EC2 시스템을 관리형 인스턴스로 등록하는 AWS 계정 및 AWS 리전에서 advanced-instances 티어를 활성화해야 합니다. 고급 인스턴스 티어를 사용하는 데는 요금이 부과됩니다. 고급 인스턴스 티어에 대한 자세한 내용은 [인스턴스 티어 구성](fleet-manager-configure-instance-tiers.md) 섹션을 참조하세요. |
| IAM 서비스 역할 권한 확인([하이브리드 및 멀티클라우드](operating-systems-and-machine-types.md#supported-machine-types) 환경) | 하이브리드 정품 인증 노드에서는 하이브리드 정품 인증에 지정된 AWS Identity and Access Management(IAM) 서비스 역할을 사용하여 Systems Manager API 작업과 통신합니다. 이 서비스 역할에는 Session Manager를 사용하여 [하이브리드 및 멀티클라우드](operating-systems-and-machine-types.md#supported-machine-types) 시스템에 연결하는 데 필요한 권한이 포함되어야 합니다. 서비스 역할이 AWS 관리형 정책 `AmazonSSMManagedInstanceCore`를 포함한다면, Session Manager에 대한 필수 권한이 이미 제공되어 있습니다. 서비스 역할에 필수 권한이 포함되어 있지 않은 경우 관리형 인스턴스를 등록 취소하고 필수 권한이 있는 IAM 서비스 역할을 사용하는 새 하이브리드 활성화에 등록해야 합니다. 관리형 인스턴스 등록 취소에 대한 자세한 내용은 [하이브리드 및 멀티클라우드 환경의 관리형 노드 등록 취소](fleet-manager-deregister-hybrid-nodes.md) 섹션을 참조하세요. Session Manager 권한이 있는 IAM 정책 생성에 대한 자세한 내용은 [2단계: Session Manager의 인스턴스 권한 확인 또는 추가](https://docs.aws.amazon.com/systems-manager/latest/userguide/session-manager-getting-started-instance-profile.html)를 참조하세요. |
# 2단계: Session Manager의 인스턴스 권한 확인 또는 추가
AWS Systems Manager는 기본적으로 인스턴스에서 작업을 수행할 권한이 없습니다. AWS Identity and Access Management(IAM) 역할을 사용하여 계정 수준에서 또는 인스턴스 프로파일을 사용하여 인스턴스 수준에서 인스턴스 권한을 제공할 수 있습니다. 사용 사례에서 허용하는 경우 기본 호스트 관리 구성을 사용하여 계정 수준에서 액세스 권한을 부여하는 것이 좋습니다. `AmazonSSMManagedEC2InstanceDefaultPolicy` 정책을 사용하여 계정의 기본 호스트 관리 구성을 이미 설정했으면 다음 단계를 진행할 수 있습니다. 기본 호스트 관리 구성에 대한 자세한 내용은 [기본 호스트 관리 구성을 사용한 자동 EC2 인스턴스 관리](fleet-manager-default-host-management-configuration.md) 섹션을 참조하세요.
또는 인스턴스 프로파일을 사용하여 인스턴스에 필요한 권한을 제공할 수 있습니다. 인스턴스 프로파일을 사용하여 Amazon EC2 인스턴스에 IAM 역할을 전달합니다. IAM 인스턴스 프로파일은 Amazon EC2 인스턴스를 시작할 때 해당 인스턴스에 연결하거나 이전에 시작한 인스턴스에 연결할 수 있습니다. 자세한 내용은 [인스턴스 프로파일 사용](https://docs.aws.amazon.com/IAM/latest/UserGuide/roles-usingrole-instanceprofile.html) 섹션을 참조하세요.
온프레미스 서버 또는 가상 머신(VM)의 경우, Systems Manager에 온프레미스 서버 및 VM을 등록하는 데 사용되는 하이브리드 활성화와 연결된 IAM 서비스 역할에 의해 권한이 제공됩니다. 온프레미스 서버 및 VM에서는 인스턴스 프로파일을 사용하지 않습니다.
다른 Systems Manager 도구(예: Run Command 또는 Parameter Store)를 이미 사용하고 있는 경우 Session Manager에 대한 필수 기본 권한을 가진 인스턴스 프로파일이 Amazon EC2 인스턴스에 이미 연결되어 있을 수 있습니다. AWS 관리형 정책 `AmazonSSMManagedInstanceCore`를 포함한 인스턴스 프로파일이 이미 인스턴스에 연결되어 있는 경우에는 Session Manager에 대한 필수 권한이 이미 제공되어 있습니다. 하이브리드 활성화에 사용된 IAM 서비스 역할이 `AmazonSSMManagedInstanceCore` 관리형 정책을 포함하는 경우에도 마찬가지입니다.
그러나 경우에 따라 인스턴스 프로파일에 연결된 권한을 수정해야 할 수 있습니다. 예를 들어 더 좁은 인스턴스 권한 집합을 제공하려 하고 인스턴스 프로파일에 대해 사용자 정의 정책을 생성했거나 또는 세션 데이터를 확보하기 위한 Amazon Simple Storage Service(Amazon S3) 암호화 또는 AWS Key Management Service(AWS KMS) 암호화 옵션을 사용하려고 합니다. 이러한 경우 인스턴스에 Session Manager 작업이 수행되도록 다음 중 하나를 실시할 수 있습니다.
+ **사용자 지정 IAM 역할의 Session Manager 작업용 임베드된 권한**
AWS 제공 기본 정책 `AmazonSSMManagedInstanceCore`에 의존하지 않는 기존 IAM 역할에 Session Manager 작업에 대한 권한을 추가하려면 [기존 IAM 역할에 Session Manager 권한 추가](getting-started-add-permissions-to-existing-profile.md)의 단계를 따르세요.
+ **Session Manager 권한만 있는 사용자 지정 IAM 역할 생성**
Session Manager 작업에 대한 권한만 있는 IAM 역할을 생성하려면 [Session Manager용 사용자 지정 IAM 역할 생성](getting-started-create-iam-instance-profile.md)의 단계를 수행합니다.
+ **모든 Systems Manager 작업에 대한 권한이 있는 새 IAM 역할 생성 및 사용**
모든 Systems Manager 권한을 부여하기 위해 AWS에서 제공하는 기본 정책을 사용하는 Systems Manager 관리형 인스턴스에 대한 IAM 역할을 생성하려면 [Systems Manager에 필요한 인스턴스 권한 구성](setup-instance-permissions.md)의 단계를 수행합니다.
**Topics**
+ [기존 IAM 역할에 Session Manager 권한 추가](getting-started-add-permissions-to-existing-profile.md)
+ [Session Manager용 사용자 지정 IAM 역할 생성](getting-started-create-iam-instance-profile.md)
# 기존 IAM 역할에 Session Manager 권한 추가
다음 절차를 사용하여 기존 AWS Identity and Access Management(IAM) 역할에 Session Manager 권한을 추가합니다. 기존 역할에 권한을 추가하면 인스턴스 권한에 대한 AWS `AmazonSSMManagedInstanceCore` 정책을 사용하지 않고 컴퓨팅 환경의 보안을 강화할 수 있습니다.
**참고**
다음과 같은 정보를 참고합니다.
이 절차에서는 기존 역할에 액세스를 허용하려는 작업에 대한 다른 Systems Manager `ssm` 권한이 이미 포함되어 있다고 가정합니다. 이 정책만으로는 Session Manager를 사용하는 데 충분하지 않습니다.
다음 정책 예제에는 `s3:GetEncryptionConfiguration` 작업이 포함되어 있습니다. Session Manager 로깅 기본 설정에서 **S3 로그 암호화 적용** 옵션을 선택한 경우 이 작업이 필요합니다.
IAM 인스턴스 프로파일 또는 IAM 서비스 역할에 연결된 정책에서 `ssmmessages:OpenControlChannel` 권한이 제거되면 관리형 노드의 SSM Agent와 클라우드의 Systems Manager 서비스의 연결이 끊어집니다. 그러나 권한이 제거된 후 연결이 종료되기까지 최대 1시간이 걸릴 수 있습니다. 이 동작은 IAM 인스턴스 역할 또는 IAM 서비스 역할이 삭제될 때와 동일합니다.
**Session Manager 권한을 기존 역할에 추가(콘솔)**
1. AWS Management Console에 로그인하여 [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)에서 IAM 콘솔을 엽니다.
1. 탐색 창에서 **역할**을 선택합니다.
1. 권한을 추가하려는 역할의 이름을 선택합니다.
1. **권한** 탭을 선택합니다.
1. **권한 추가**를 선택하고 **인라인 정책 추가**를 선택합니다.
1. **JSON** 탭을 선택합니다.
1. 기본 정책 콘텐츠를 다음과 같은 콘텐츠로 바꿉니다. *key-name*을 사용하려는 AWS Key Management Service 키(AWS KMS key)의 Amazon 리소스 이름(ARN)으로 바꿉니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ssmmessages:CreateControlChannel",
"ssmmessages:CreateDataChannel",
"ssmmessages:OpenControlChannel",
"ssmmessages:OpenDataChannel"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"s3:GetEncryptionConfiguration"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"kms:Decrypt"
],
"Resource": "arn:aws:kms:us-east-1:111122223333:key/key-name"
}
]
}
```
------
KMS 키를 사용하여 세션 데이터를 암호화하는 방법에 대한 자세한 내용은 [세션 데이터의 KMS 키 암호화를 설정하려면(콘솔)](session-preferences-enable-encryption.md) 섹션을 참조하세요.
세션 데이터에 AWS KMS 암호화를 사용하지 않으려면 정책에서 다음 콘텐츠를 제거할 수 있습니다.
```
,
{
"Effect": "Allow",
"Action": [
"kms:Decrypt"
],
"Resource": "key-name"
}
```
1. **다음: 태그**를 선택합니다.
1. (선택 사항) **태그 추가(Add tag)**를 선택하고 정책에 대한 기본 설정 태그를 입력하여 태그를 추가합니다.
1. **다음: 검토**를 선택합니다.
1. **Review policy(정책 검토)** 페이지에서 **Name(이름)**에 인라인 정책 이름을 입력합니다(예: **SessionManagerPermissions**)
1. (선택 사항) **설명**에 정책에 대한 설명을 입력합니다.
**정책 생성**을 선택합니다.
`ssmmessages` 작업에 대한 자세한 내용은 [참조: ec2messages, ssmmessages 및 기타 API 작업](systems-manager-setting-up-messageAPIs.md) 섹션을 참조하세요.
# Session Manager용 사용자 지정 IAM 역할 생성
Amazon EC2 관리형 인스턴스에서 작업을 수행하는 권한을 Session Manager에 부여하는 AWS Identity and Access Management(IAM) 역할을 생성할 수 있습니다. 세션 로그를 Amazon Simple Storage Service(S3) 및 Amazon CloudWatch Logs로 보내는 데 필요한 권한을 부여하는 정책도 포함할 수도 있습니다.
IAM 역할을 생성한 후에 인스턴스에 역할을 연결하는 방법에 대한 내용은 AWS re:Post 웹사이트에서 [인스턴스 프로파일 연결 또는 바꾸기](https://aws.amazon.com/premiumsupport/knowledge-center/attach-replace-ec2-instance-profile/)를 참조하세요. IAM 인스턴스 프로파일 및 역할에 대한 자세한 내용은 **IAM 사용 설명서의 [인스턴스 프로파일 사용](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-ec2_instance-profiles.html)과 *Linux 인스턴스용 Amazon Elastic Compute Cloud 사용 설명서*의 [Amazon EC2에 대한 IAM 역할](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-roles-for-amazon-ec2.html)을 참조하세요. 온프레미스 시스템용 IAM 서비스 역할을 생성하는 방법에 대한 자세한 내용은 [하이브리드 및 멀티클라우드 환경에서 Systems Manager에 필요한 IAM 서비스 역할 생성](https://docs.aws.amazon.com/systems-manager/latest/userguide/hybrid-multicloud-service-role.html)을 참조하세요.
**Topics**
+ [최소 Session Manager 권한을 사용하여 IAM 역할 생성(콘솔)](#create-iam-instance-profile-ssn-only)
+ [Session Manager, Amazon S3 및 CloudWatch Logs에 대한 권한이 있는 IAM 역할 생성(콘솔)](#create-iam-instance-profile-ssn-logging)
## 최소 Session Manager 권한을 사용하여 IAM 역할 생성(콘솔)
다음 절차에 따라 인스턴스에 대해 Session Manager 작업만 가능한 권한을 제공하는 정책을 사용해 사용자 지정 IAM 역할을 생성합니다.
**최소 Session Manager 권한을 사용하여 인스턴스 프로파일을 생성하려면(콘솔)**
1. AWS Management Console에 로그인하여 [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)에서 IAM 콘솔을 엽니다.
1. 탐색 창에서 **정책**을 선택한 후 **정책 생성**을 선택합니다. ([**시작하기(Get Started)**] 버튼이 표시되면 이 버튼을 선택한 후 [**정책 생성(Create Policy)**]을 선택합니다.)
1. **JSON** 탭을 선택합니다.
1. 기본 콘텐츠를 다음과 같은 정책으로 바꿉니다. AWS Key Management Service(AWS KMS)를 사용하여 세션을 암호화하려면 사용하려는 AWS KMS key의 Amazon 리소스 이름(ARN)으로 *key-name*을 바꿉니다.
**참고**
IAM 인스턴스 프로파일 또는 IAM 서비스 역할에 연결된 정책에서 `ssmmessages:OpenControlChannel` 권한이 제거되면 관리형 노드의 SSM Agent와 클라우드의 Systems Manager 서비스의 연결이 끊어집니다. 그러나 권한이 제거된 후 연결이 종료되기까지 최대 1시간이 걸릴 수 있습니다. 이 동작은 IAM 인스턴스 역할 또는 IAM 서비스 역할이 삭제될 때와 동일합니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ssm:UpdateInstanceInformation",
"ssmmessages:CreateControlChannel",
"ssmmessages:CreateDataChannel",
"ssmmessages:OpenControlChannel",
"ssmmessages:OpenDataChannel"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"kms:Decrypt"
],
"Resource": "arn:aws:kms:us-east-1:111122223333:key/key-name"
}
]
}
```
------
KMS 키를 사용하여 세션 데이터를 암호화하는 방법에 대한 자세한 내용은 [세션 데이터의 KMS 키 암호화를 설정하려면(콘솔)](session-preferences-enable-encryption.md) 섹션을 참조하세요.
세션 데이터에 AWS KMS 암호화를 사용하지 않으려면 정책에서 다음 콘텐츠를 제거할 수 있습니다.
```
,
{
"Effect": "Allow",
"Action": [
"kms:Decrypt"
],
"Resource": "key-name"
}
```
1. **다음: 태그**를 선택합니다.
1. (선택 사항) **태그 추가(Add tag)**를 선택하고 정책에 대한 기본 설정 태그를 입력하여 태그를 추가합니다.
1. **다음: 검토**를 선택합니다.
1. **Review policy(정책 검토)** 페이지에서 **Name(이름)**에 인라인 정책 이름을 입력합니다(예: **SessionManagerPermissions**)
1. (선택 사항) **설명**에 정책에 대한 설명을 입력합니다.
1. **정책 생성**을 선택합니다.
1. 탐색 창에서 **역할**을 선택한 후 **역할 생성**을 선택합니다.
1. **역할 생성** 페이지에서 **AWS 서비스( service)**를 선택하고 **사용 사례(Use case)**에 **EC2**를 선택합니다.
1. **다음(Next)**을 선택합니다.
1. **권한 추가** 페이지에서 방금 생성한 정책의 이름(예: **SessionManagerPermissions**) 왼쪽에 있는 확인란을 선택합니다.
1. **다음**을 선택합니다.
1. **이름, 검토 및 생성** 페이지에서 **역할 이름(Role name)**에 IAM 역할의 이름을 입력합니다(예: **MySessionManagerRole**).
1. (선택 사항) **역할 설명**에 인스턴스 프로파일에 대한 설명을 입력합니다.
1. (선택 사항) **태그 추가(Add tag)**를 선택하고 역할에 대한 기본 설정 태그를 입력하여 태그를 추가합니다.
**역할 생성**을 선택합니다.
`ssmmessages` 작업에 대한 자세한 내용은 [참조: ec2messages, ssmmessages 및 기타 API 작업](systems-manager-setting-up-messageAPIs.md) 섹션을 참조하세요.
## Session Manager, Amazon S3 및 CloudWatch Logs에 대한 권한이 있는 IAM 역할 생성(콘솔)
다음 절차에 따라 인스턴스에 대해 Session Manager 작업이 가능한 권한을 제공하는 정책을 사용해 사용자 지정 IAM 역할을 생성합니다. 이 정책은 세션 로그를 Amazon Simple Storage Service(Amazon S3) 버킷 및 Amazon CloudWatch Logs 로그 그룹에 저장하는 데 필요한 권한도 제공합니다.
**중요**
다른 AWS 계정에서 소유하는 Amazon S3 버킷에 세션 로그를 출력하려면 정책에 IAM 역할 정책에 `s3:PutObjectAcl` 권한을 추가해야 합니다. 소유하는 계정에서 사용하는 IAM 역할에 버킷 정책에서 크로스 계정 액세스 권한을 부여하여 관리형 인스턴스에 대한 Systems Manager 권한을 부여하는지도 확인해야 합니다. 버킷에서 Key Management Service(KMS) 암호화를 사용하는 경우에는 버킷의 KMS 정책에서도 이 크로스 계정 액세스 권한을 부여해야 합니다. Amazon S3의 크로스 계정 버킷 권한 구성에 대한 자세한 내용은 **Amazon Simple Storage Service 사용 설명서의 [크로스 계정 버킷 권한 부여](https://docs.aws.amazon.com/AmazonS3/latest/userguide/example-walkthroughs-managing-access-example2.html)를 참조하세요. 크로스 계정 권한이 추가되지 않으면 Amazon S3 버킷을 소유하는 계정에서 세션 출력 로그에 액세스할 수 없습니다.
세션 로그 저장에 대한 기본 설정 지정에 관한 자세한 내용은 [세션 로깅 활성화 및 비활성화](session-manager-logging.md) 섹션을 참조하세요.
**Session Manager, Amazon S3 및 CloudWatch Logs에 대한 권한이 있는 IAM 역할 생성(콘솔)**
1. AWS Management Console에 로그인하여 [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)에서 IAM 콘솔을 엽니다.
1. 탐색 창에서 **정책**을 선택한 후 **정책 생성**을 선택합니다. ([**시작하기(Get Started)**] 버튼이 표시되면 이 버튼을 선택한 후 [**정책 생성(Create Policy)**]을 선택합니다.)
1. **JSON** 탭을 선택합니다.
1. 기본 콘텐츠를 다음과 같은 정책으로 바꿉니다. 각 *리소스 자리 표시자 예*를 자신의 정보로 바꿉니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ssmmessages:CreateControlChannel",
"ssmmessages:CreateDataChannel",
"ssmmessages:OpenControlChannel",
"ssmmessages:OpenDataChannel",
"ssm:UpdateInstanceInformation"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"logs:CreateLogStream",
"logs:PutLogEvents",
"logs:DescribeLogGroups",
"logs:DescribeLogStreams"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"s3:PutObject"
],
"Resource": "arn:aws:s3:::amzn-s3-demo-bucket/s3-prefix/*"
},
{
"Effect": "Allow",
"Action": [
"s3:GetEncryptionConfiguration"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"kms:Decrypt"
],
"Resource": "arn:aws:kms:us-east-1:111122223333:key/key-name"
},
{
"Effect": "Allow",
"Action": "kms:GenerateDataKey",
"Resource": "*"
}
]
}
```
------
1. **다음: 태그**를 선택합니다.
1. (선택 사항) **태그 추가(Add tag)**를 선택하고 정책에 대한 기본 설정 태그를 입력하여 태그를 추가합니다.
1. **다음: 검토**를 선택합니다.
1. **Review policy(정책 검토)** 페이지에서 **Name(이름)**에 인라인 정책 이름을 입력합니다(예: **SessionManagerPermissions**)
1. (선택 사항) **설명**에 정책에 대한 설명을 입력합니다.
1. **정책 생성**을 선택합니다.
1. 탐색 창에서 **역할**을 선택한 후 **역할 생성**을 선택합니다.
1. **역할 생성** 페이지에서 **AWS 서비스( service)**를 선택하고 **사용 사례(Use case)**에 **EC2**를 선택합니다.
1. **다음(Next)**을 선택합니다.
1. **권한 추가** 페이지에서 방금 생성한 정책의 이름(예: **SessionManagerPermissions**) 왼쪽에 있는 확인란을 선택합니다.
1. **다음**을 선택합니다.
1. **이름, 검토 및 생성** 페이지에서 **역할 이름(Role name)**에 IAM 역할의 이름을 입력합니다(예: **MySessionManagerRole**).
1. (선택 사항) **Role description(역할 설명)**에 역할에 대한 설명을 입력합니다.
1. (선택 사항) **태그 추가(Add tag)**를 선택하고 역할에 대한 기본 설정 태그를 입력하여 태그를 추가합니다.
1. **역할 생성**을 선택합니다.
# 3단계: 관리형 노드에 대한 세션 액세스 제어
AWS Identity and Access Management(IAM) 정책을 사용하여 관리형 노드에 대한 Session Manager 액세스 권한을 부여하거나 취소할 수 있습니다. 정책을 생성하여 사용자 또는 그룹이 연결할 수 있는 관리형 노드를 지정하는 IAM 사용자 또는 그룹에 해당 정책을 연결할 수 있습니다. 사용자 또는 그룹이 해당 관리 노드에서 수행할 수 있는 Session Manager API 작업을 지정할 수도 있습니다.
Session Manager IAM 권한 정책을 시작하는 데 도움이 되도록 최종 사용자와 관리자 사용자를 위한 샘플 정책을 생성했습니다. 이러한 정책을 약간 변경하여 사용할 수 있습니다. 사용자 지정 IAM 정책을 생성하는 안내서로 사용할 수도 있습니다. 자세한 내용은 [Session Manager에 대한 샘플 IAM 정책](getting-started-restrict-access-quickstart.md) 섹션을 참조하세요. 정책을 생성하고 IAM 사용자 또는 그룹에 연결하는 방법에 대한 자세한 내용은 **IAM 사용 설명서의 [IAM 정책 생성](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html)과 [IAM 정책 추가 및 제거](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage-attach-detach.html)를 참조하세요.
**세션 ID ARN 형식 정보**
Session Manager 액세스를 위한 IAM 정책을 생성할 때 Amazon 리소스 이름(ARN)의 일부로 세션 ID를 지정합니다. 세션 ID에는 사용자 이름이 변수로 포함됩니다. 설명하는 데 도움이 되는 Session Manager ARN 형식과 예제가 있습니다.
```
arn:aws:ssm:region-id:account-id:session/session-id
```
예제:
```
arn:aws:ssm:us-east-2:123456789012:session/JohnDoe-1a2b3c4d5eEXAMPLE
```
IAM 정책에서 변수 사용에 대한 자세한 내용은 [IAM 정책 요소: 변수](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_variables.html)를 참조하세요.
**Topics**
+ [IAM 정책에서 기본 세션 문서를 지정하여 기본 쉘 세션을 시작합니다.](getting-started-default-session-document.md)
+ [IAM 정책에서 세션 문서를 지정하여 문서로 세션 시작](getting-started-specify-session-document.md)
+ [Session Manager에 대한 샘플 IAM 정책](getting-started-restrict-access-quickstart.md)
+ [Session Manager에 대한 추가 IAM 정책 샘플](getting-started-restrict-access-examples.md)
# IAM 정책에서 기본 세션 문서를 지정하여 기본 쉘 세션을 시작합니다.
Systems Manager 콘솔에서 AWS 계정의 Session Manager를 구성하거나 세션 기본 설정을 변경하면 시스템에서 `SSM-SessionManagerRunShell`이라는 SSM 세션 문서가 생성됩니다. 이 문서가 기본 세션 문서입니다. Session Manager에서는 이 문서를 사용하여 다음과 같은 정보가 포함된 세션 기본 설정을 저장합니다.
+ 세션 데이터를 저장하려는 위치(예: Amazon Simple Storage Service(S3) 버킷 또는 Amazon CloudWatch Logs 로그 그룹)입니다.
+ 세션 데이터 암호화용 AWS Key Management Service(AWS KMS) 키 ID입니다.
+ 세션에 Run As 지원이 허용되는지 여부입니다.
다음은 `SSM-SessionManagerRunShell` 세션 기본 설정 문서에 포함된 정보의 예입니다.
```
{
"schemaVersion": "1.0",
"description": "Document to hold regional settings for Session Manager",
"sessionType": "Standard_Stream",
"inputs": {
"s3BucketName": "amzn-s3-demo-bucket",
"s3KeyPrefix": "MyS3Prefix",
"s3EncryptionEnabled": true,
"cloudWatchLogGroupName": "MyCWLogGroup",
"cloudWatchEncryptionEnabled": false,
"kmsKeyId": "1a2b3c4d",
"runAsEnabled": true,
"runAsDefaultUser": "RunAsUser"
}
}
```
기본적으로 Session Manager에서는 사용자가 AWS Management Console에서 세션을 시작할 때 기본 세션 문서를 사용합니다. 이는 Systems Manager 콘솔의 Fleet Manager 또는 Session Manager나 Amazon EC2 콘솔의 EC2 Connect에 적용됩니다. Session Manager에서는 사용자가 다음 예제와 같은 AWS CLI 명령을 사용하여 세션을 시작할 때에도 기본 세션 문서를 사용합니다.
```
aws ssm start-session \
--target i-02573cafcfEXAMPLE
```
기본 쉘 세션을 시작하려면 다음 예제와 같이 IAM 정책에서 기본 세션 문서를 지정해야 합니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "EnableSSMSession",
"Effect": "Allow",
"Action": [
"ssm:StartSession"
],
"Resource": [
"arn:aws:ec2:us-east-1:111122223333:instance/instance-id",
"arn:aws:ssm:us-east-1:111122223333:document/SSM-SessionManagerRunShell"
]
},
{
"Effect": "Allow",
"Action": [
"ssmmessages:OpenDataChannel"
],
"Resource": [
"*"
]
}
]
}
```
------
# IAM 정책에서 세션 문서를 지정하여 문서로 세션 시작
기본 세션 문서를 사용하여 [start-session](https://docs.aws.amazon.com/cli/latest/reference/ssm/start-session.html) AWS CLI 명령을 사용하는 경우 문서 이름을 생략할 수 있습니다. 시스템에서 자동으로 `SSM-SessionManagerRunShell` 세션 문서를 호출합니다.
그 밖의 경우에는 `document-name` 파라미터의 값을 지정해야 합니다. 사용자가 명령에서 세션 문서의 이름을 지정하면 시스템에서는 IAM 정책을 점검하여 문서에 액세스할 권한이 있는지 확인합니다. 권한이 없으면 연결 요청에 실패합니다. 다음 예제에는 `document-name` 파라미터가 `AWS-StartPortForwardingSession` 세션 문서와 함께 포함되어 있습니다.
```
aws ssm start-session \
--target i-02573cafcfEXAMPLE \
--document-name AWS-StartPortForwardingSession \
--parameters '{"portNumber":["80"], "localPortNumber":["56789"]}'
```
IAM 정책에서 Session Manager 세션 문서를 지정하는 방법에 대한 예제는 [Session Manager에 대한 빠른 시작 최종 사용자 정책](getting-started-restrict-access-quickstart.md#restrict-access-quickstart-end-user) 섹션을 참조하세요.
**참고**
SSH를 사용하여 세션을 시작하려면 대상 관리형 노드와** 사용자의 로컬 컴퓨터에서 구성 단계를 완료해야 합니다. 자세한 내용은 [(선택 사항) Session Manager를 통한 SSH 연결에 대한 권한 허용 및 제어](session-manager-getting-started-enable-ssh-connections.md)를 참조하세요.
# Session Manager에 대한 샘플 IAM 정책
이 섹션에 나오는 샘플은 Session Manager 액세스에 가장 일반적으로 필요한 권한을 제공하는 AWS Identity and Access Management(IAM) 정책을 생성하는 데 유용합니다.
**참고**
또한 AWS KMS key 정책을 사용하면 KMS 키에 대한 액세스 권한이 부여될 IAM 엔터티(사용자 또는 역할) 및 AWS 계정를 제어할 수 있습니다. 자세한 내용은 *AWS Key Management Service Developer Guide*의 [Overview of Managing Access to Your AWS KMS Resources](https://docs.aws.amazon.com/kms/latest/developerguide/control-access-overview.html) 및 [Using Key Policies in AWS KMS](https://docs.aws.amazon.com/kms/latest/developerguide/key-policies.html)를 참조하세요.
**Topics**
+ [Session Manager에 대한 빠른 시작 최종 사용자 정책](#restrict-access-quickstart-end-user)
+ [Session Manager에 대한 빠른 시작 관리자 정책](#restrict-access-quickstart-admin)
## Session Manager에 대한 빠른 시작 최종 사용자 정책
다음 예를 사용하여 Session Manager에 대한 IAM 최종 사용자 정책을 생성합니다.
사용자가 Session Manager 콘솔과 AWS Command Line Interface(AWS CLI)에서만, Amazon Elastic Compute Cloud(Amazon EC2) 콘솔에서만 또는 세 가지 모두에서 세션을 시작할 수 있도록 허용하는 정책을 생성할 수 있습니다.
이러한 정책은 최종 사용자에게 특정 관리형 노드에 대한 세션을 시작할 수 있는 권한과 자신의 세션만 종료할 수 있는 권한을 제공합니다. 정책에 대해 수행하려는 사용자 지정에 대한 예는 [Session Manager에 대한 추가 IAM 정책 샘플](getting-started-restrict-access-examples.md) 섹션을 참조하세요.
다음 샘플 정책에서 각 *리소스 자리 표시자 예*를 자신의 정보로 바꿉니다.
다음 탭에서 선택하여 제공할 세션 액세스 범위에 대한 샘플 정책을 확인합니다.
------
#### [ 세션 관리자 and Fleet Manager ]
사용자에게 Session Manager 콘솔과 Fleet Manager에서만 세션을 시작하고 재개할 수 있는 권한을 제공하려면 이 샘플 정책을 사용합니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ssm:StartSession"
],
"Resource": [
"arn:aws:ec2:us-east-1:111122223333:instance/i-02573cafcfEXAMPLE",
"arn:aws:ssm:us-east-1:111122223333:document/SSM-SessionManagerRunShell"
]
},
{
"Effect": "Allow",
"Action": ["ssmmessages:OpenDataChannel"],
"Resource": ["arn:aws:ssm:*:*:session/${aws:userid}-*"]
},
{
"Effect": "Allow",
"Action": [
"ssm:DescribeSessions",
"ssm:GetConnectionStatus",
"ssm:DescribeInstanceProperties",
"ec2:DescribeInstances"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"ssm:TerminateSession",
"ssm:ResumeSession"
],
"Resource": [
"arn:aws:ssm:*:*:session/${aws:userid}-*"
]
},
{
"Effect": "Allow",
"Action": [
"kms:GenerateDataKey"
],
"Resource": "arn:aws:kms:us-east-1:111122223333:key/key-name"
}
]
}
```
------
------
#### [ Amazon EC2 ]
사용자에게 Amazon EC2 콘솔에서만 세션을 시작하고 재개할 수 있는 권한을 제공하려면 이 샘플 정책을 사용합니다. 이 정책은 Session Manager 콘솔과 AWS CLI에서 세션을 시작하는 데 필요한 모든 권한을 제공하지 않습니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ssm:StartSession",
"ssm:SendCommand"
],
"Resource": [
"arn:aws:ec2:us-east-1:111122223333:instance/i-02573cafcfEXAMPLE",
"arn:aws:ssm:us-east-1:111122223333:document/SSM-SessionManagerRunShell"
]
},
{
"Effect": "Allow",
"Action": ["ssmmessages:OpenDataChannel"],
"Resource": ["arn:aws:ssm:*:*:session/${aws:userid}-*"]
},
{
"Effect": "Allow",
"Action": [
"ssm:GetConnectionStatus",
"ssm:DescribeInstanceInformation"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"ssm:TerminateSession",
"ssm:ResumeSession"
],
"Resource": [
"arn:aws:ssm:*:*:session/${aws:username}-*"
]
}
]
}
```
------
------
#### [ AWS CLI ]
사용자에게 AWS CLI에서만 세션을 시작하고 재개할 수 있는 권한을 제공하려면 이 샘플 정책을 사용합니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ssm:StartSession",
"ssm:SendCommand"
],
"Resource": [
"arn:aws:ec2:us-east-1:111122223333:instance/i-02573cafcfEXAMPLE",
"arn:aws:ssm:us-east-1:111122223333:document/SSM-SessionManagerRunShell"
]
},
{
"Effect": "Allow",
"Action": ["ssmmessages:OpenDataChannel"],
"Resource": ["arn:aws:ssm:*:*:session/${aws:userid}-*"]
},
{
"Effect": "Allow",
"Action": [
"ssm:TerminateSession",
"ssm:ResumeSession"
],
"Resource": [
"arn:aws:ssm:*:*:session/${aws:userid}-*"
]
},
{
"Effect": "Allow",
"Action": [
"kms:GenerateDataKey"
],
"Resource": "arn:aws:kms:us-east-1:111122223333:key/key-name"
}
]
}
```
------
------
**참고**
`SSM-SessionManagerRunShell`은 Session Manager에서 세션 구성 설정을 저장할 목적으로 생성되는 SSM 문서의 기본 이름입니다. 그 밖에 사용자 정의 Session 문서를 생성한 후 정책에서 지정할 수도 있습니다. 또한 AWS에서 제공하는 문서인 `AWS-StartSSHSession`을 SSH로 세션을 시작하는 사용자에게 지정하는 방법도 있습니다. SSH로 세션을 지원하는 데 필요한 구성 단계에 대한 자세한 내용은 [(선택 사항) Session Manager를 통한 SSH 연결에 대한 권한 허용 및 제어](session-manager-getting-started-enable-ssh-connections.md)를 참조하세요.
`kms:GenerateDataKey` 권한을 사용하면 세션 데이터를 암호화하는 데 사용할 데이터 암호화 키를 만들 수 있습니다. 세션 데이터에 AWS Key Management Service(AWS KMS) 암호화를 사용하는 경우 *key-name*을 `arn:aws:kms:us-west-2:111122223333:key/1234abcd-12ab-34cd-56ef-12345EXAMPLE` 형식으로 사용하려는 KMS 키의 Amazon 리소스 이름(ARN)으로 바꿉니다. 세션 데이터에 KMS 키 암호화를 사용하지 않으려면 정책에서 다음 콘텐츠를 제거합니다.
```
{
"Effect": "Allow",
"Action": [
"kms:GenerateDataKey"
],
"Resource": "key-name"
}
```
세션 데이터 암호화에 AWS KMS 사용에 대한 내용은 [세션 데이터의 KMS 키 암호화를 설정하려면(콘솔)](session-preferences-enable-encryption.md) 섹션을 참조하세요.
사용자가 Amazon EC2 콘솔에서 세션을 시작하려고 시도하는 경우 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_SendCommand.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_SendCommand.html)에 대한 권한이 필요하지만, 먼저 Session Manager에 필요한 최소 버전으로 SSM Agent를 업데이트해야 합니다. Run Command를 사용하여 에이전트를 업데이트하라는 명령을 인스턴스에 전달합니다.
## Session Manager에 대한 빠른 시작 관리자 정책
다음 예를 사용하여 Session Manager에 대한 IAM 관리자 정책을 생성합니다.
이러한 정책은 관리자에게 `Key=Finance,Value=WebServers`로 태그가 지정된 관리형 노드에 대한 세션을 시작하는 권한, 기본 설정을 생성, 업데이트 및 삭제하는 권한, 자신의 세션만 종료할 수 있는 권한을 제공합니다. 정책에 대해 수행하려는 사용자 지정에 대한 예는 [Session Manager에 대한 추가 IAM 정책 샘플](getting-started-restrict-access-examples.md) 섹션을 참조하세요.
관리자가 Session Manager 콘솔과 AWS CLI에서만, Amazon EC2 콘솔에서만 또는 세 가지 모두에서 이러한 태스크를 수행할 수 있도록 허용하는 정책을 생성할 수 있습니다.
다음 샘플 정책에서 각 *리소스 자리 표시자 예*를 자신의 정보로 바꿉니다.
지원하려는 액세스 시나리오에 대한 샘플 정책을 보려면 다음 탭에서 선택하세요.
------
#### [ 세션 관리자 and CLI ]
관리자에게 Session Manager 콘솔과 AWS CLI에서만 세션 관련 태스크를 수행할 수 있는 권한을 제공하려면 이 샘플 정책을 사용합니다. 이 정책은 Amazon EC2 콘솔에서 세션 관련 태스크를 수행하는 데 필요한 모든 권한을 제공하지 않습니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ssm:StartSession"
],
"Resource": [
"arn:aws:ec2:*:111122223333:instance/*"
],
"Condition": {
"StringLike": {
"ssm:resourceTag/Finance": [
"WebServers"
]
}
}
},
{
"Effect": "Allow",
"Action": [
"ssmmessages:OpenDataChannel"
],
"Resource": [
"arn:aws:ssm:*:*:session/${aws:userid}-*"
]
},
{
"Effect": "Allow",
"Action": [
"ssm:DescribeSessions",
"ssm:GetConnectionStatus",
"ssm:DescribeInstanceProperties",
"ec2:DescribeInstances"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"ssm:CreateDocument",
"ssm:UpdateDocument",
"ssm:GetDocument",
"ssm:StartSession"
],
"Resource": "arn:aws:ssm:us-east-1:111122223333:document/SSM-SessionManagerRunShell"
},
{
"Effect": "Allow",
"Action": [
"ssmmessages:OpenDataChannel"
],
"Resource": [
"arn:aws:ssm:*:*:session/${aws:userid}-*"
]
},
{
"Effect": "Allow",
"Action": [
"ssm:TerminateSession",
"ssm:ResumeSession"
],
"Resource": [
"arn:aws:ssm:*:*:session/${aws:userid}-*"
]
}
]
}
```
------
------
#### [ Amazon EC2 ]
관리자에게 Amazon EC2 콘솔에서만 세션 관련 태스크를 수행할 수 있는 권한을 제공하려면 이 샘플 정책을 사용합니다. 이 정책은 Session Manager 콘솔 및 AWS CLI에서 세션 관련 작업을 수행하는 데 필요한 모든 권한을 제공하지 않습니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ssm:StartSession",
"ssm:SendCommand"
],
"Resource": [
"arn:aws:ec2:us-east-1:111122223333:instance/*"
],
"Condition": {
"StringLike": {
"ssm:resourceTag/tag-key": [
"tag-value"
]
}
}
},
{
"Effect": "Allow",
"Action": [
"ssm:StartSession"
],
"Resource": [
"arn:aws:ssm:us-east-1:111122223333:document/SSM-SessionManagerRunShell"
]
},
{
"Effect": "Allow",
"Action": ["ssmmessages:OpenDataChannel"],
"Resource": ["arn:aws:ssm:*:*:session/${aws:userid}-*"]
},
{
"Effect": "Allow",
"Action": [
"ssm:GetConnectionStatus",
"ssm:DescribeInstanceInformation"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"ssm:TerminateSession",
"ssm:ResumeSession"
],
"Resource": [
"arn:aws:ssm:*:*:session/${aws:userid}-*"
]
}
]
}
```
------
------
#### [ 세션 관리자, CLI, and Amazon EC2 ]
관리자에게 Session Manager 콘솔, AWS CLI 및 Amazon EC2 콘솔에서 세션 관련 태스크를 수행할 수 있는 권한을 제공하려면 이 샘플 정책을 사용합니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ssm:StartSession",
"ssm:SendCommand"
],
"Resource": [
"arn:aws:ec2:us-east-1:111122223333:instance/*"
],
"Condition": {
"StringLike": {
"ssm:resourceTag/tag-key": [
"tag-value"
]
}
}
},
{
"Effect": "Allow",
"Action": ["ssmmessages:OpenDataChannel"],
"Resource": ["arn:aws:ssm:*:*:session/${aws:userid}-*"]
},
{
"Effect": "Allow",
"Action": [
"ssm:DescribeSessions",
"ssm:GetConnectionStatus",
"ssm:DescribeInstanceInformation",
"ssm:DescribeInstanceProperties",
"ec2:DescribeInstances"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"ssm:CreateDocument",
"ssm:UpdateDocument",
"ssm:GetDocument",
"ssm:StartSession"
],
"Resource": "arn:aws:ssm:us-east-1:111122223333:document/SSM-SessionManagerRunShell"
},
{
"Effect": "Allow",
"Action": [
"ssm:TerminateSession",
"ssm:ResumeSession"
],
"Resource": [
"arn:aws:ssm:*:*:session/${aws:userid}-*"
]
}
]
}
```
------
------
**참고**
사용자가 Amazon EC2 콘솔에서 세션을 시작하려고 하는 경우 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_SendCommand.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_SendCommand.html)에 대한 권한이 필요하지만 먼저 SSM Agent를 업데이트하도록 명령을 보내야 합니다.
# Session Manager에 대한 추가 IAM 정책 샘플
다음 예제 정책을 참조하면 지원하려는 모든 Session Manager 사용자 액세스 시나리오에 대한 사용자 정의 AWS Identity and Access Management(IAM) 정책을 생성할 수 있습니다.
**Topics**
+ [예제 1: 콘솔의 문서 액세스 권한 부여](#grant-access-documents-console-example)
+ [예제 2: 특정 관리형 노드에 대한 액세스 제한](#restrict-access-example-instances)
+ [예제 3: 태그에 따라 액세스 제한](#restrict-access-example-instance-tags)
+ [예제 4: 사용자에게 자신이 시작한 세션만 종료하도록 허용](#restrict-access-example-user-sessions)
+ [예제 5: 모든 세션에 대한 전체(관리) 액세스 권한 허용](#restrict-access-example-full-access)
## 예제 1: 콘솔의 문서 액세스 권한 부여
사용자가 Session Manager 콘솔을 사용하여 세션을 시작할 때 사용자 지정 문서를 지정하도록 허용할 수 있습니다. 다음 예제 IAM 정책에서는 지정된 AWS 리전 및 AWS 계정에서 이름이 **SessionDocument-**로 시작하는 문서에 액세스하는 권한을 부여합니다.
이 정책을 사용하려면 각 *예제 리소스 자리 표시자*를 자신의 정보로 바꿉니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ssm:GetDocument",
"ssm:ListDocuments"
],
"Resource": [
"arn:aws:ssm:us-east-1:111122223333:document/SessionDocument-*"
]
}
]
}
```
------
**참고**
Session Manager 콘솔에서는 세션 기본 설정 정의에 사용되는 `Standard_Stream`의 `sessionType`이 있는 세션 문서만 지원됩니다. 자세한 내용은 [Session 문서 스키마](session-manager-schema.md) 섹션을 참조하세요.
## 예제 2: 특정 관리형 노드에 대한 액세스 제한
Session Manager로 사용자가 연결할 수 있는 관리형 노드를 정의하는 IAM 정책을 생성할 수 있습니다. 예를 들어, 다음 정책은 사용자에게 3개의 특정 노드에서 세션을 시작, 종료 및 재개할 수 있는 권한을 부여합니다. 이 정책은 사용자가 지정된 노드 이외의 노드에 연결하지 못하도록 제한합니다.
**참고**
페더레이션 사용자의 경우 [예제 4: 사용자에게 자신이 시작한 세션만 종료하도록 허용](#restrict-access-example-user-sessions) 섹션을 참조하세요.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ssm:StartSession"
],
"Resource": [
"arn:aws:ec2:us-east-1:111122223333:instance/i-1234567890EXAMPLE",
"arn:aws:ec2:us-east-1:111122223333:instance/i-abcdefghijEXAMPLE",
"arn:aws:ec2:us-east-1:111122223333:instance/i-0e9d8c7b6aEXAMPLE",
"arn:aws:ssm:us-east-1:111122223333:document/SSM-SessionManagerRunShell"
]
},
{
"Effect": "Allow",
"Action": ["ssmmessages:OpenDataChannel"],
"Resource": ["arn:aws:ssm:*:*:session/${aws:userid}-*"]
},
{
"Effect": "Allow",
"Action": [
"ssm:TerminateSession",
"ssm:ResumeSession"
],
"Resource": [
"arn:aws:ssm:*:*:session/${aws:userid}-*"
]
},
{
"Effect": "Allow",
"Action": ["ssmmessages:OpenDataChannel"],
"Resource": ["arn:aws:ssm:*:*:session/${aws:userid}-*"]
}
]
}
```
------
## 예제 3: 태그에 따라 액세스 제한
특정 태그를 기준으로 관리형 노드에 대한 액세스 권한을 제한할 수 있습니다. 다음 예제에서 사용자는 관리형 노드가 Finance WebServer(`ssm:resourceTag/Finance: WebServer`)인 상태에서 모든 관리형 노드(`Resource: arn:aws:ec2:region:987654321098:instance/*`)에 대해 세션(`Effect: Allow, Action: ssm:StartSession, ssm:ResumeSession`)을 시작하고 재개할 수 있습니다. 사용자가 태그 지정되지 않은 관리형 노드에 명령을 전송하거나 `Finance: WebServer` 이외의 태그가 있는 경우 명령 결과에 `AccessDenied`가 포함됩니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ssm:StartSession"
],
"Resource": [
"arn:aws:ec2:us-east-1:111122223333:instance/*"
],
"Condition": {
"StringLike": {
"ssm:resourceTag/Finance": [
"WebServers"
]
}
}
},
{
"Effect": "Allow",
"Action": ["ssmmessages:OpenDataChannel"],
"Resource": ["arn:aws:ssm:*:*:session/${aws:userid}-*"]
},
{
"Effect": "Allow",
"Action": [
"ssm:TerminateSession",
"ssm:ResumeSession"
],
"Resource": [
"arn:aws:ssm:*:*:session/${aws:userid}-*"
]
},
{
"Effect": "Allow",
"Action": [
"ssm:StartSession"
],
"Resource": [
"arn:aws:ssm:us-east-1:111122223333:document/SSM-SessionManagerRunShell"
]
}
]
}
```
------
사용자가 여러 태그로 지정된 관리형 노드에 대해 세션을 시작하도록 허용하는 IAM 정책을 생성할 수 있습니다. 다음 정책에서는 사용자가 관리형 노드에 적용된 태그를 둘 다 가지고 있는 인스턴스에 대한 세션을 시작하도록 합니다. 사용자가 두 태그 모두에 지정되지 않은 관리형 노드에 명령을 전송할 경우 명령 결과에 `AccessDenied`가 포함됩니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement":[
{
"Effect":"Allow",
"Action":[
"ssm:StartSession"
],
"Resource":"*",
"Condition":{
"StringLike":{
"ssm:resourceTag/tag-key1":[
"tag-value1"
],
"ssm:resourceTag/tag-key2":[
"tag-value2"
]
}
}
},
{
"Effect": "Allow",
"Action": ["ssmmessages:OpenDataChannel"],
"Resource": ["arn:aws:ssm:*:*:session/${aws:userid}-*"]
},
{
"Effect": "Allow",
"Action": [
"ssm:StartSession"
],
"Resource": [
"arn:aws:ssm:us-east-1:111122223333:document/SSM-SessionManagerRunShell"
]
}
]
}
```
------
IAM 정책 생성에 대한 자세한 내용은 **IAM 사용 설명서의 [관리형 정책과 인라인 정책](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html)을 참조하세요. 관리형 노드에 태그를 지정하는 방법에 대한 자세한 내용은 **Amazon EC2 사용 설명서에서 [Amazon EC2 리소스 태깅](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html)을 참조하세요(콘텐츠는 Windows 및 Linux 관리형 노드에 적용됨). 관리형 노드에서 무단 루트 수준 명령에 대한 보안 태세를 강화하는 방법은 [SSM Agent를 통한 루트 수준 명령에 대한 액세스 제한](ssm-agent-restrict-root-level-commands.md) 섹션을 참조하세요.
## 예제 4: 사용자에게 자신이 시작한 세션만 종료하도록 허용
Session Manager에서는 AWS 계정의 페더레이션 사용자가 종료할 수 있는 세션을 제어하는 두 가지 방법이 제공됩니다.
+ AWS Identity and Access Management(IAM) 권한 정책에서 `{aws:userid}` 변수를 사용합니다. 페더레이션 사용자는 자신이 시작한 세션만 종료할 수 있습니다. 페더레이션되지 않은 사용자의 경우 방법 1을 사용합니다. 페더레이션된 사용자의 경우 방법 2를 사용합니다.
+ IAM 권한 정책에서 AWS 태그에서 제공하는 태그를 사용합니다. 정책에서, 사용자가 AWS에서 제공한 특정 태그로 태그 달린 세션만 종료할 수 있는 조건을 포함시킵니다. 이 방법은 페더레이션 ID를 사용하여 AWS에 대한 액세스 권한을 부여하는 계정을 포함하여 모든 계정에 작동합니다.
### 방법 1: 변수 `{aws:username}`를 사용하여 TerminateSession에 권한 부여
다음 IAM 정책은 사용자가 계정에 있는 모든 세션의 ID를 볼 수 있도록 합니다. 그러나 사용자는 자신이 시작한 세션을 통해서만 관리형 노드와 상호 작용할 수 있습니다. 다음 정책이 할당된 사용자는 다른 사용자의 세션에 연결하거나 해당 세션을 종료할 수 없습니다. 이 정책은 변수 `{aws:username}`를 사용하여 이와 같이 제한합니다.
**참고**
이 방법은 페더레이션 ID를 사용하여 AWS에 대한 액세스 권한을 부여하는 계정에는 적용되지 않습니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Action": [
"ssm:DescribeSessions"
],
"Effect": "Allow",
"Resource": [
"*"
]
},
{
"Action": [
"ssm:TerminateSession"
],
"Effect": "Allow",
"Resource": [
"arn:aws:ssm:*:*:session/${aws:username}-*"
]
}
]
}
```
------
### 방법 2: AWS에서 제공한 태그를 사용하여 TerminateSession에 권한 부여
IAM 정책에 조건부 태그 키 변수를 포함하여 사용자가 종료할 수 있는 세션을 제어할 수 있습니다. 조건은 사용자가 이러한 특정 태그 키 변수와 지정된 값 중 하나 또는 둘 다로 태그가 지정된 세션만 종료할 수 있도록 지정합니다.
AWS 계정의 사용자가 세션을 시작하면 Session Manager에서는 두 개의 리소스 태그를 세션에 적용합니다. 첫 번째 리소스 태그는 `aws:ssmmessages:target-id`이며, 이 태그에서는 사용자가 종료할 수 있는 대상의 ID를 지정합니다. 다른 리소스 태그는 `aws:ssmmessages:session-id`이며, `role-id:caller-specified-role-name` 형식의 값입니다.
**참고**
Session Manager에서는 이 IAM 액세스 제어 정책에 대한 사용자 정의 태그를 지원하지 않습니다. 아래에 설명된 AWS에서 제공하는 리소스 태그를 사용해야 합니다.
** `aws:ssmmessages:target-id` **
이 태그 키를 사용하여 관리형 노드 ID를 값으로 정책에 포함시킵니다. 다음 정책 블록에서, 조건문을 사용하여 사용자가 i-02573cafcfEXAMPLE 노드만 종료할 수 있습니다.
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ssm:TerminateSession"
],
"Resource": "*",
"Condition": {
"StringLike": {
"ssm:resourceTag/aws:ssmmessages:target-id": [
"i-02573cafcfEXAMPLE"
]
}
}
}
]
}
```
사용자가 이 `TerminateSession` 권한이 부여되지 않은 세션을 종료하려고 시도하면 `AccessDeniedException` 오류가 발생합니다.
** `aws:ssmmessages:session-id` **
이 태그 키는 세션 ID에 대한 변수를 값으로 세션 시작 요청에 포함시킵니다.
다음 예제에서는 호출자 유형이 `User`인 경우에 대한 정책을 보여줍니다. `aws:ssmmessages:session-id`에 대해 제공하는 값은 사용자의 ID입니다. 이 예에서 `AIDIODR4TAW7CSEXAMPLE`은 AWS 계정에 있는 사용자의 ID를 나타냅니다. AWS 계정에서 사용자의 ID를 검색하려면 IAM 명령 `get-user`를 사용합니다. 자세한 내용은 *IAM User Guide*에서 AWS Identity and Access Management 섹션의 [get-user](https://docs.aws.amazon.com/IAM/latest/UserGuide/get-user.html)를 참조하세요.
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ssm:TerminateSession"
],
"Resource": "*",
"Condition": {
"StringLike": {
"ssm:resourceTag/aws:ssmmessages:session-id": [
"AIDIODR4TAW7CSEXAMPLE"
]
}
}
}
]
}
```
다음 예제에서는 호출자 유형이 `AssumedRole`인 경우에 대한 정책을 보여줍니다. `aws:ssmmessages:session-id`에서 제공한 값에 `{aws:userid}` 변수를 사용할 수 있습니다. 또는 `aws:ssmmessages:session-id`에서 제공한 값에 대해 역할 ID를 하드코딩할 수 있습니다. 역할 ID를 하드코딩하는 경우 값을 `role-id:caller-specified-role-name` 형식으로 제공해야 합니다. 예를 들어 `AIDIODR4TAW7CSEXAMPLE:MyRole`입니다.
시스템 태그를 적용하려면 제공하는 역할 ID에 다음 문자만 포함할 수 있습니다. 유니코드 문자, 0-9, 공백, `_`, `.`, `:`, `/`, `=`, `+`, `-`, `@` 및 `\`.
AWS 계정의 역할에 대한 역할 ID를 검색하려면 `get-caller-identity` 명령을 사용합니다. 자세한 내용은 AWS CLI Command Reference의 [get-caller-identity](https://docs.aws.amazon.com/cli/latest/reference/sts/get-caller-identity.html)를 참조하세요.
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ssm:TerminateSession"
],
"Resource": "*",
"Condition": {
"StringLike": {
"ssm:resourceTag/aws:ssmmessages:session-id": [
"${aws:userid}*"
]
}
}
}
]
}
```
사용자가 이 `TerminateSession` 권한이 부여되지 않은 세션을 종료하려고 시도하면 `AccessDeniedException` 오류가 발생합니다.
**`aws:ssmmessages:target-id`** 및 **`aws:ssmmessages:session-id`**
또한 이 예제에 표시된 대로 사용자가 두 시스템 태그로 태그가 지정된 세션을 종료할 수 있도록 하는 IAM 정책을 생성할 수도 있습니다.
****
```
{
"Version":"2012-10-17",
"Statement":[
{
"Effect":"Allow",
"Action":[
"ssm:TerminateSession"
],
"Resource":"*",
"Condition":{
"StringLike":{
"ssm:resourceTag/aws:ssmmessages:target-id":[
"i-02573cafcfEXAMPLE"
],
"ssm:resourceTag/aws:ssmmessages:session-id":[
"${aws:userid}*"
]
}
}
}
]
}
```
## 예제 5: 모든 세션에 대한 전체(관리) 액세스 권한 허용
다음 IAM 정책은 사용자가 다른 모든 사용자가 생성한 관리형 노드 및 세션 모두와 완벽하게 상호 작용하도록 허용합니다. 이러한 권한은 조직의 Session Manager 활동을 완벽하게 제정해야 하는 관리자에게만 부여해야 합니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Action": [
"ssm:StartSession",
"ssm:TerminateSession",
"ssm:ResumeSession",
"ssm:DescribeSessions",
"ssm:GetConnectionStatus"
],
"Effect": "Allow",
"Resource": [
"*"
]
},
{
"Effect": "Allow",
"Action": ["ssmmessages:OpenDataChannel"],
"Resource": ["arn:aws:ssm:*:*:session/${aws:userid}-*"]
}
]
}
```
------
# 4단계: 세션 기본 설정 구성
AWS Identity and Access Management(IAM) 정책의 관리 권한이 부여된 사용자는 다음을 포함하여 세션 기본 설정을 구성할 수 있습니다.
+ Linux 관리형 노드에 대한 Run As 지원을 활성화합니다. 그러면 AWS Systems Manager Session Manager가 관리형 노드에서 생성할 수 있는 `ssm-user` 계정의 자격 증명이 아닌 특정 운영 체제 사용자의 자격 증명을 사용해 세션을 시작할 수 있습니다.
+ AWS KMS key 암호화를 사용해 클라이언트 시스템과 관리형 노드 사이에서 전송되는 데이터를 추가로 보호할 수 있도록 Session Manager를 구성합니다.
+ 세션 기록 로그를 생성하여 Amazon Simple Storage Service(Amazon S3) 버킷 또는 Amazon CloudWatch Logs 로그 그룹으로 보내도록 Session Manager를 구성합니다. 그런 다음 저장된 로그 데이터는 세션 중 인스턴스에 대한 세션 연결과 관리형 노드에 대한 명령 실행을 보고하는 데 사용할 수 있습니다.
+ 세션 시간 제한을 구성합니다. 이 설정을 사용하여 일정 기간 동안 활동이 없으면 세션을 종료할 시기를 지정할 수 있습니다.
+ 구성 가능한 셸 프로파일을 사용하도록 Session Manager를 구성합니다. 이러한 사용자 정의 가능한 프로파일을 사용하면 셸 기본 설정, 환경 변수, 작업 디렉터리 및 세션 시작 시 여러 명령 실행과 같은 세션 내 기본 설정을 정의할 수 있습니다.
Session Manager 기본 설정 구성에 필요한 권한에 대한 자세한 내용은 [Session Manager 기본 설정을 업데이트하도록 사용자 권한 부여 또는 거부](preference-setting-permissions.md) 섹션을 참조하세요.
**Topics**
+ [Session Manager 기본 설정을 업데이트하도록 사용자 권한 부여 또는 거부](preference-setting-permissions.md)
+ [유휴 세션 시간 제한 값 지정](session-preferences-timeout.md)
+ [최대 세션 기간 지정](session-preferences-max-timeout.md)
+ [구성 가능한 셸 프로파일 허용](session-preferences-shell-config.md)
+ [Linux 및 macOS 관리형 노드에 대한 Run As 지원 활성화](session-preferences-run-as.md)
+ [세션 데이터의 KMS 키 암호화를 설정하려면(콘솔)](session-preferences-enable-encryption.md)
+ [Session Manager 기본 설정 문서 생성(명령줄)](getting-started-create-preferences-cli.md)
+ [Session Manager 기본 설정 업데이트(명령줄)](getting-started-configure-preferences-cli.md)
Systems Manager 콘솔에서 세션 데이터 로깅 옵션을 구성하는 방법에 대한 자세한 내용은 다음 주제를 참조하세요.
+ [Amazon S3를 사용하여 세션 데이터 로깅(콘솔)](session-manager-logging-s3.md)
+ [Amazon CloudWatch Logs를 사용하여 세션 데이터 스트리밍(콘솔)](session-manager-logging-cwl-streaming.md)
+ [Amazon CloudWatch Logs를 사용하여 세션 데이터 로깅(콘솔)](session-manager-logging-cloudwatch-logs.md)
# Session Manager 기본 설정을 업데이트하도록 사용자 권한 부여 또는 거부
계정 기본 설정은 각 AWS 리전에 대해 AWS Systems Manager(SSM) 문서로 저장됩니다. 사용자가 계정 내 세션에 대한 계정 기본 설정을 업데이트할 수 있으려면 기본 설정이 저장되는 SSM 문서 유형에 액세스할 수 있는 필수 권한을 부여 받은 상태여야 합니다. 이러한 권한은 AWS Identity and Access Management(IAM) 정책을 통해 부여됩니다.
**기본 설정이 생성 및 업데이트되도록 허용하는 관리자 정책**
관리자는 언제든지 기본 설정을 생성 및 업데이트할 수 있도록 다음 정책을 가지고 있을 수 있습니다. 다음 정책은 us-east-2 계정 123456789012에서 `SSM-SessionManagerRunShell` 문서에 액세스하고 해당 문서를 업데이트하는 권한을 허용합니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Action": [
"ssm:CreateDocument",
"ssm:GetDocument",
"ssm:UpdateDocument",
"ssm:DeleteDocument"
],
"Effect": "Allow",
"Resource": [
"arn:aws:ssm:us-east-1:111122223333:document/SSM-SessionManagerRunShell"
]
}
]
}
```
------
**기본 설정 업데이트를 방지하는 사용자 정책**
다음 정책을 사용하면 계정의 최종 사용자가 Session Manager 기본 설정을 업데이트 또는 재정의할 수 없습니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Action": [
"ssm:CreateDocument",
"ssm:GetDocument",
"ssm:UpdateDocument",
"ssm:DeleteDocument"
],
"Effect": "Deny",
"Resource": [
"arn:aws:ssm:us-east-1:111122223333:document/SSM-SessionManagerRunShell"
]
}
]
}
```
------
# 유휴 세션 시간 제한 값 지정
AWS Systems Manager의 도구인 Session Manager를 사용하여 시스템이 세션을 끝내기 전에 사용자의 비활성 상태를 허용하는 시간을 지정할 수 있습니다. 기본적으로 20분 동안 활동이 없으면 세션이 시간 초과됩니다. 이 설정을 수정하여 1\$160분 동안 비활성 상태이면 세션이 시간 초과되도록 지정할 수 있습니다. 일부 전문 컴퓨팅 보안 기관에서는 유휴 세션 시간 제한을 최대 15분으로 설정할 것을 권장합니다.
Session Manager가 클라이언트 측 입력을 수신하면 유휴 세션 제한 시간 타이머가 재설정됩니다. 이러한 입력에는 다음이 포함됩니다(이에 국한되지 않음).
+ 터미널의 키보드 입력
+ 터미널 또는 브라우저 창 크기 조정 이벤트
+ 세션 재연결(ResumeSession) - 네트워크 중단, 브라우저 탭 관리 또는 WebSocket 연결 해제로 인해 발생할 수 있음
이러한 이벤트는 유휴 타이머를 재설정하므로 직접 터미널 명령 없이도 세션이 구성된 제한 시간보다 오래 활성 상태로 유지될 수 있습니다.
보안 요구 사항에 따라 활동에 관계없이 엄격한 세션 기간 제한이 필요한 경우, 유휴 제한 시간 외에 *최대 세션 기간* 설정을 사용합니다. 자세한 내용은 [최대 세션 기간 지정](session-preferences-max-timeout.md) 섹션을 참조하세요.
**유휴 세션 시간 제한을 허용하려면(콘솔)**
1. [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)에서 AWS Systems Manager 콘솔을 엽니다.
1. 탐색 창에서 **Session Manager**를 선택합니다.
1. **기본 설정** 탭을 선택하고 **편집**을 선택합니다.
1. [**유휴 세션 시간 제한(Idle session timeout)**] 아래의 [**분(minutes)**] 필드에 세션이 종료되기 전 사용자가 비활성 상태일 수 있는 시간을 지정합니다.
1. **저장**을 선택합니다.
# 최대 세션 기간 지정
AWS Systems Manager의 도구인 Session Manager를 사용하면 세션이 종료되기 전의 최대 지속 시간을 지정할 수 있습니다. 기본적으로 세션에는 최대 기간이 없습니다. 최대 세션 기간에 대해 지정하는 값은 1\$11,440분 사이여야 합니다.
**최대 세션 기간 지정(콘솔)**
1. [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)에서 AWS Systems Manager 콘솔을 엽니다.
1. 탐색 창에서 **Session Manager**를 선택합니다.
1. **기본 설정** 탭을 선택하고 **편집**을 선택합니다.
1. **최대 세션 기간 활성화(Enable maximum session duration)** 옆의 체크박스를 선택합니다.
1. **최대 세션 기간(Maximum session duration)** 밑의 **분(minutes)** 필드에서 세션이 종료되기 전의 최대 지속 시간을 지정합니다.
1. **저장**을 선택합니다.
# 구성 가능한 셸 프로파일 허용
기본적으로 Linux용 EC2 인스턴스의 세션은 Bourne 쉘(sh)을 사용하여 시작합니다. 그러나 bash 등의 다른 셸을 사용하고자 할 수 있습니다. 구성 가능한 셸 프로파일을 허용하여 세션 내에서 셸 기본 설정, 환경 변수, 작업 디렉터리 및 세션이 시작될 때 여러 명령 실행과 같은 기본 설정을 사용자 지정할 수 있습니다.
**중요**
Systems Manager 는 셸 프로파일의 명령이나 스크립트를 검사하여 실행되기 전에 인스턴스에 어떤 변화가 있는지 확인하지 않습니다. 사용자가 셸 프로파일에 입력한 명령이나 스크립트를 수정할 수 있는 권한을 제한하려면 다음을 권장합니다.
AWS Identity and Access Management(IAM) 사용자 및 역할에 대한 사용자 지정된 세션 유형 문서를 생성합니다. 그런 다음 이러한 사용자 및 역할에 대한 IAM 정책을 수정하여 `StartSession` API 작업이 해당 사용자에 대해 생성한 세션 유형 문서만 사용할 수 있도록 합니다. 자세한 내용은 [Session Manager 기본 설정 문서 생성(명령줄)](getting-started-create-preferences-cli.md) 및 [Session Manager에 대한 빠른 시작 최종 사용자 정책](getting-started-restrict-access-quickstart.md#restrict-access-quickstart-end-user) 섹션을 참조하세요.
IAM 사용자 및 역할에 대한 IAM 정책을 수정하여 생성한 세션 유형 문서 리소스에 대한 `UpdateDocument` API 작업 액세스를 거부합니다. 이렇게 하면 사용자와 역할이 설정을 수정하지 않고도 세션 기본 설정에 대해 생성한 문서를 사용할 수 있습니다.
**구성 가능한 셸 프로파일을 설정하려면**
1. [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)에서 AWS Systems Manager 콘솔을 엽니다.
1. 탐색 창에서 **Session Manager**를 선택합니다.
1. **기본 설정** 탭을 선택하고 **편집**을 선택합니다.
1. 해당 운영 체제의 필드에서 세션이 시작될 때 실행할 환경 변수, 셸 기본 설정 또는 명령을 지정합니다.
1. **저장**을 선택합니다.
다음은 셸 프로파일에 추가할 수 있는 몇 가지 예제 명령입니다.
bash 쉘로 변경하고 Linux 인스턴스의 /usr 디렉터리로 변경합니다.
```
exec /bin/bash
cd /usr
```
세션 시작 시 타임스탬프 및 시작 메시지를 출력합니다.
------
#### [ Linux & macOS ]
```
timestamp=$(date '+%Y-%m-%dT%H:%M:%SZ')
user=$(whoami)
echo $timestamp && echo "Welcome $user"'!'
echo "You have logged in to a production instance. Note that all session activity is being logged."
```
------
#### [ Windows ]
```
$timestamp = (Get-Date).ToString("yyyy-MM-ddTH:mm:ssZ")
$splitName = (whoami).Split("\")
$user = $splitName[1]
Write-Host $timestamp
Write-Host "Welcome $user!"
Write-Host "You have logged in to a production instance. Note that all session activity is being logged."
```
------
세션 시작 시 동적 시스템 활동을 봅니다.
------
#### [ Linux & macOS ]
```
top
```
------
#### [ Windows ]
```
while ($true) { Get-Process | Sort-Object -Descending CPU | Select-Object -First 30; `
Start-Sleep -Seconds 2; cls
Write-Host "Handles NPM(K) PM(K) WS(K) VM(M) CPU(s) Id ProcessName";
Write-Host "------- ------ ----- ----- ----- ------ -- -----------"}
```
------
# Linux 및 macOS 관리형 노드에 대한 Run As 지원 활성화
기본적으로 Session Manager는 관리형 노드에 생성된 시스템 생성 `ssm-user` 계정의 보안 인증 정보를 사용하여 연결을 인증합니다. Linux 및 macOS 시스템에서는 이 계정이 `/etc/sudoers/`에 추가됩니다. 선택하는 경우, 대신 운영 체제(OS) 사용자 계정 또는 Active Directory에 가입한 인스턴스를 위한 도메인 사용자의 인증 정보를 사용하여 세션을 인증할 수 있습니다. 이 경우 Session Manager는 세션을 시작하기 전에 지정한 OS 계정이 노드 또는 도메인에 존재하는지 확인합니다. 노드 또는 도메인에 존재하지 않는 OS 계정을 사용하여 세션을 시작하려고 하면 연결이 실패합니다.
**참고**
Session Manager는 운영 체제의 `root` 사용자 계정을 사용한 연결 인증을 지원하지 않습니다. OS 사용자 계정을 사용하여 인증된 세션의 경우 로그인 제한 또는 시스템 리소스 사용 제한과 같은 노드의 OS 수준 및 디렉터리 정책이 적용되지 않을 수 있습니다.
**작동 방식**
세션에서 Run As 지원을 설정하면 시스템이 다음과 같이 액세스 권한 유무를 검사합니다.
1. 세션을 시작하는 사용자의 경우 IAM 엔터티(사용자 또는 역할)에 `SSMSessionRunAs = os user account name`으로 태그가 지정되어 있나요?
그렇다면 관리형 노드에 OS 사용자 이름이 존재하나요? 그렇다면 세션을 시작합니다. 그렇지 않다면 세션 시작을 허용하지 않습니다.
IAM 엔터티에 `SSMSessionRunAs = os user account name`으로 태그가 지정되지* *않은 경우 2단계로 계속 진행합니다.
1. IAM 엔터티에 `SSMSessionRunAs = os user account name`로 태그가 지정되어 있지 않은 경우 AWS 계정의 Session Manager 기본 설정에서 OS 사용자 이름이 지정되어 있나요?
그렇다면 관리형 노드에 OS 사용자 이름이 존재하나요? 그렇다면 세션을 시작합니다. 그렇지 않다면 세션 시작을 허용하지 않습니다.
**참고**
Run As 지원을 활성화하면 Session Manager가 관리형 노드에서 `ssm-user` 계정을 사용하여 세션을 시작할 수 없습니다. 즉, Session Manager가 지정된 OS 사용자 계정을 사용하여 연결하지 못하는 경우 기본 방법을 사용하는 연결로 되돌아가지 않습니다.
OS 계정을 지정하거나 IAM 엔터티에 태그를 지정하지 않고 Run As를 활성화하고 Session Manager 기본 설정에서 OS 계정을 지정하지 않은 경우 세션 연결 시도가 실패합니다.
**Linux 및 macOS 관리형 노드에 대한 Run As 지원을 활성화하는 방법**
1. [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)에서 AWS Systems Manager 콘솔을 엽니다.
1. 탐색 창에서 **Session Manager**를 선택합니다.
1. **기본 설정** 탭을 선택하고 **편집**을 선택합니다.
1. **Linux 인스턴스에 대한 Run As 지원 활성화** 옆에 있는 확인란을 선택합니다.
1. 다음 중 하나를 수행하세요.
+ **옵션 1**: **운영 체제 사용자 이름** 필드에 세션을 시작할 때 사용할 OS 사용자 계정의 이름을 입력합니다. 이 옵션을 사용하면 Session Manager를 사용하여 연결하는 AWS 계정의 모든 사용자에 대해 동일한 OS 사용자가 모든 세션을 실행합니다.
+ **옵션 2**(권장): **IAM 콘솔 열기** 링크를 선택합니다. 탐색 창에서 **사용자** 또는 **역할**을 선택합니다. 태그를 추가할 개체(사용자 또는 역할)와 **태그** 탭을 차례대로 선택합니다. 키 이름으로 `SSMSessionRunAs`를 입력합니다. 키 값에 대한 OS 사용자 계정의 이름을 입력합니다. **변경 사항 저장**을 선택합니다.
이 옵션을 사용하면 원하는 경우 서로 다른 IAM 엔터티에 대해 고유한 OS 사용자를 지정할 수 있습니다. IAM 개체(사용자 또는 역할) 태그 지정에 대한 자세한 내용은 *IAM 사용 설명서*의 [IAM 리소스 태그 지정](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_tags.html)을 참조하세요.
다음은 예입니다.
![\[Session Manager Run As 권한을 위한 태그를 지정하는 스크린샷.\]](http://docs.aws.amazon.com/ko_kr/systems-manager/latest/userguide/images/ssn-run-as-tags.png)
1. **저장**을 선택합니다.
# 세션 데이터의 KMS 키 암호화를 설정하려면(콘솔)
키를 생성하고 관리하려면 AWS Key Management Service(AWS KMS)을 사용합니다. AWS KMS로 다양한 AWS 서비스 및 애플리케이션의 암호화 사용을 제어할 수 있습니다. KMS 키 암호화를 사용하여 관리형 노드와 AWS 계정의 사용자 로컬 머신 사이에 전송되는 세션 데이터가 암호화되도록 지정할 수 있습니다. (이는 AWS에서 기본적으로 제공하는 TLS 1.2/1.3 암호화에 대한 추가 사항입니다.) Session Manager 세션 데이터를 암호화하려면 AWS KMS를 사용하여 대칭 KMS 키를 생성합니다.
`Standard_Stream`, `InteractiveCommands`, `NonInteractiveCommands` 세션 유형에 AWS KMS 암호화를 사용할 수 있습니다. AWS KMS(AWS Systems Manager)에서 생성한 키를 사용하여 세션 데이터를 암호화하는 옵션을 사용하려면 버전 2.3.539.0 이상의 SSM Agent가 관리형 노드에 설치되어 있어야 합니다.
**참고**
AWS Systems Manager 콘솔에서 관리형 노드의 암호를 재설정하려면 AWS KMS 암호화를 허용해야 합니다. 자세한 내용은 [관리형 노드의 암호 재설정](fleet-manager-reset-password.md#managed-instance-reset-a-password) 섹션을 참조하세요.
AWS 계정에서 생성한 키를 사용할 수 있습니다. 다른 AWS 계정에서 생성된 키를 사용할 수도 있습니다. 다른 AWS 계정에 있는 키 생성자는 키를 사용하는 데 필요한 권한을 제공해야 합니다.
세션 데이터에 대해 KMS 키 암호화를 설정하면 세션을 시작하는 사용자와 거기에 연결하는 관리형 노드 모두에 키를 사용할 권한이 있어야 합니다. Session Manager과 함께 AWS Identity and Access Management(IAM) 정책을 통해 KMS 키를 사용할 수 있는 권한을 제공합니다. 자세한 내용은 다음 주제를 참조하세요.
+ 계정의 사용자에 대한 AWS KMS 권한 추가: [Session Manager에 대한 샘플 IAM 정책](getting-started-restrict-access-quickstart.md).
+ 계정의 관리형 노드에 대한 AWS KMS 권한 추가: [2단계: Session Manager의 인스턴스 권한 확인 또는 추가](session-manager-getting-started-instance-profile.md).
KMS 키 생성 및 관리에 대한 자세한 내용은 [https://docs.aws.amazon.com/kms/latest/developerguide/](https://docs.aws.amazon.com/kms/latest/developerguide/)를 참조하세요.
계정에서 AWS CLI를 사용하여 세션 데이터의 KMS 키 암호화를 설정하는 방법에 대한 자세한 내용은 [Session Manager 기본 설정 문서 생성(명령줄)](getting-started-create-preferences-cli.md) 또는 [Session Manager 기본 설정 업데이트(명령줄)](getting-started-configure-preferences-cli.md) 섹션를 참조하세요.
**참고**
KMS 키 사용에 요금이 부과됩니다. 자세한 내용은 [AWS Key Management Service 요금](https://aws.amazon.com/kms/pricing/)을 참조하십시오.
**세션 데이터의 KMS 키 암호화를 설정하려면(콘솔)**
1. [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)에서 AWS Systems Manager 콘솔을 엽니다.
1. 탐색 창에서 **Session Manager**를 선택합니다.
1. **기본 설정** 탭을 선택하고 **편집**을 선택합니다.
1. **KMS 암호화 활성화(Enable KMS encryption)** 옆의 체크박스를 선택합니다.
1. 다음 중 하나를 수행하세요.
+ [**내 현재 계정에서 KMS 키 선택(Select a KMS key in my current account)**] 옆에 있는 버튼을 선택한 다음 목록에서 키를 선택합니다.
-또는-
**Enter a KMS key alias or KMS key ARN(KMS 키 별칭 또는 KMS 키 ARN 입력)** 옆의 버튼을 선택하십시오. 현재 계정에서 생성한 키의 KMS 키 별칭을 수동으로 입력하거나 다른 계정의 키에 대한 키 Amazon 리소스 이름(ARN)을 입력합니다. 예를 들어, 다음과 같습니다.
+ 키 별칭: `alias/my-kms-key-alias`
+ 키 ARN: `arn:aws:kms:us-west-2:111122223333:key/1234abcd-12ab-34cd-56ef-12345EXAMPLE`
-또는-
[**새 키 생성(Create new key)**]을 선택하여 계정에서 새 KMS 키를 생성합니다. 새 키를 생성한 후 **기본 설정** 탭으로 돌아가서 계정의 세션 데이터를 암호화할 키를 선택하십시오.
키 공유에 대한 자세한 내용은 *AWS Key Management Service Developer Guide*의 [Allowing External AWS 계정 to Access a key](https://docs.aws.amazon.com/kms/latest/developerguide/key-policy-modifying.html#key-policy-modifying-external-accounts)를 참조하세요.
1. **저장**을 선택합니다.
# Session Manager 기본 설정 문서 생성(명령줄)
다음 절차를 사용하여 AWS Systems Manager Session Manager 세션의 기본 설정을 정의하는 SSM 문서를 생성합니다. 문서를 사용하여 데이터 암호화, 세션 기간 및 로깅을 포함한 세션 옵션을 구성할 수 있습니다. 예를 들면, 기본 설정을 사용하여 Amazon Simple Storage Service(S3) 버킷 또는 Amazon CloudWatch Logs 로그 그룹에 세션 로그 데이터를 저장할지를 지정할 수 있습니다. AWS 계정 및 AWS 리전의 모든 세션에 대한 일반 기본 설정을 정의하거나 개별 세션의 기본 설정을 정의하는 문서를 생성할 수 있습니다.
**참고**
Session Manager 콘솔을 사용하여 일반 세션 기본 설정을 구성할 수도 있습니다.
Session Manager 기본 설정을 설정하는 데 사용하는 문서에는 `Standard_Stream`의 `sessionType`이 있어야 합니다. 세션 문서에 대한 자세한 내용은 [Session 문서 스키마](session-manager-schema.md) 섹션을 참조하세요.
명령줄을 사용하여 기존 Session Manager 기본 설정을 업데이트하는 방법에 대한 자세한 내용은 [Session Manager 기본 설정 업데이트(명령줄)](getting-started-configure-preferences-cli.md) 섹션을 참조하세요.
CloudFormation을 사용하여 세션 환경설정을 생성하는 방법의 예제는 *AWS CloudFormation 사용 설명서*의 [Session Manager 기본 설정에 대한 Systems Manager 문서 생성](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-ssm-document.html#aws-resource-ssm-document--examples)을 참조하세요.
**참고**
이 절차에서는 AWS 계정 수준에서 Session Manager 기본 설정을 설정하는 문서를 생성하는 방법을 설명합니다. 세션 수준 기본 설정을 설정하는 데 사용할 문서를 생성하려면 파일 이름 관련 명령 입력에 대한 `SSM-SessionManagerRunShell` 이외의 값을 지정합니다.
문서를 사용하여 AWS Command Line Interface(AWS CLI)에서 시작하는 세션의 기본 설정을 설정하려면 문서 이름을 `--document-name` 파라미터 값으로 제공합니다. Session Manager 콘솔에서 시작하는 세션의 기본 설정을 설정하려면 문서 이름을 입력하거나 목록에서 선택할 수 있습니다.
**Session Manager 기본 설정을 생성하려면(명령줄)**
1. 로컬 시스템에서 `SessionManagerRunShell.json`이라는 JSON 파일을 생성한 다음 이 파일에 다음 내용을 붙여 넣습니다.
```
{
"schemaVersion": "1.0",
"description": "Document to hold regional settings for Session Manager",
"sessionType": "Standard_Stream",
"inputs": {
"s3BucketName": "",
"s3KeyPrefix": "",
"s3EncryptionEnabled": true,
"cloudWatchLogGroupName": "",
"cloudWatchEncryptionEnabled": true,
"cloudWatchStreamingEnabled": false,
"kmsKeyId": "",
"runAsEnabled": false,
"runAsDefaultUser": "",
"idleSessionTimeout": "",
"maxSessionDuration": "",
"shellProfile": {
"windows": "date",
"linux": "pwd;ls"
}
}
}
```
다음 예와 같이 값을 하드코딩하는 대신 파라미터를 사용하여 세션 기본 설정에 값을 전달할 수도 있습니다.
```
{
"schemaVersion":"1.0",
"description":"Session Document Parameter Example JSON Template",
"sessionType":"Standard_Stream",
"parameters":{
"s3BucketName":{
"type":"String",
"default":""
},
"s3KeyPrefix":{
"type":"String",
"default":""
},
"s3EncryptionEnabled":{
"type":"Boolean",
"default":"false"
},
"cloudWatchLogGroupName":{
"type":"String",
"default":""
},
"cloudWatchEncryptionEnabled":{
"type":"Boolean",
"default":"false"
}
},
"inputs":{
"s3BucketName":"{{s3BucketName}}",
"s3KeyPrefix":"{{s3KeyPrefix}}",
"s3EncryptionEnabled":"{{s3EncryptionEnabled}}",
"cloudWatchLogGroupName":"{{cloudWatchLogGroupName}}",
"cloudWatchEncryptionEnabled":"{{cloudWatchEncryptionEnabled}}",
"kmsKeyId":""
}
}
```
1. 세션 데이터를 보낼 위치를 지정하십시오. S3 버킷 이름(선택적 접두사 사용) 또는 CloudWatch Logs 로그 그룹 이름을 지정할 수 있습니다. 로컬 클라이언트와 관리형 노드 사이에 데이터를 추가로 암호화하려면 암호화에 사용할 KMS 키를 제공하세요. 다음은 예입니다.
```
{
"schemaVersion": "1.0",
"description": "Document to hold regional settings for Session Manager",
"sessionType": "Standard_Stream",
"inputs": {
"s3BucketName": "amzn-s3-demo-bucket",
"s3KeyPrefix": "MyS3Prefix",
"s3EncryptionEnabled": true,
"cloudWatchLogGroupName": "MyLogGroupName",
"cloudWatchEncryptionEnabled": true,
"cloudWatchStreamingEnabled": false,
"kmsKeyId": "MyKMSKeyID",
"runAsEnabled": true,
"runAsDefaultUser": "MyDefaultRunAsUser",
"idleSessionTimeout": "20",
"maxSessionDuration": "60",
"shellProfile": {
"windows": "MyCommands",
"linux": "MyCommands"
}
}
}
```
**참고**
세션 로그 데이터를 암호화하지 않으려는 경우 `s3EncryptionEnabled`의 `true`를 `false`로 변경합니다.
Amazon S3 버킷 또는 CloudWatch Logs 로그 그룹에 로그를 보내지 않거나, 활성 세션 데이터를 암호화하지 않거나, 계정 세션에서 Run As 지원을 설정하지 않으려면 해당 옵션에 대한 행을 삭제할 수 있습니다. `inputs` 섹션의 마지막 줄은 쉼표로 끝나면 안 됩니다.
KMS 키 ID를 추가하여 세션 데이터를 암호화하면 세션을 시작하는 사용자와 거기에 연결하는 관리형 노드 모두에 키를 사용할 권한이 있어야 합니다. Session Manager와 함께 IAM 정책을 통해 KMS 키를 사용할 수 있는 권한을 제공합니다. 자세한 내용은 다음 주제를 참조하세요.
계정의 사용자에 대한 AWS KMS 권한 추가: [Session Manager에 대한 샘플 IAM 정책](getting-started-restrict-access-quickstart.md)
계정의 관리형 노드에 대한 AWS KMS 권한 추가: [2단계: Session Manager의 인스턴스 권한 확인 또는 추가](session-manager-getting-started-instance-profile.md).
1. 파일을 저장합니다.
1. JSON 파일을 생성한 디렉터리에서 다음 명령을 실행합니다.
------
#### [ Linux & macOS ]
```
aws ssm create-document \
--name SSM-SessionManagerRunShell \
--content "file://SessionManagerRunShell.json" \
--document-type "Session" \
--document-format JSON
```
------
#### [ Windows ]
```
aws ssm create-document ^
--name SSM-SessionManagerRunShell ^
--content "file://SessionManagerRunShell.json" ^
--document-type "Session" ^
--document-format JSON
```
------
#### [ PowerShell ]
```
New-SSMDocument `
-Name "SSM-SessionManagerRunShell" `
-Content (Get-Content -Raw SessionManagerRunShell.json) `
-DocumentType "Session" `
-DocumentFormat JSON
```
------
이 작업이 성공하면 다음과 비슷한 출력이 반환됩니다.
```
{
"DocumentDescription": {
"Status": "Creating",
"Hash": "ce4fd0a2ab9b0fae759004ba603174c3ec2231f21a81db8690a33eb66EXAMPLE",
"Name": "SSM-SessionManagerRunShell",
"Tags": [],
"DocumentType": "Session",
"PlatformTypes": [
"Windows",
"Linux"
],
"DocumentVersion": "1",
"HashType": "Sha256",
"CreatedDate": 1547750660.918,
"Owner": "111122223333",
"SchemaVersion": "1.0",
"DefaultVersion": "1",
"DocumentFormat": "JSON",
"LatestVersion": "1"
}
}
```
# Session Manager 기본 설정 업데이트(명령줄)
다음 절차에서는 기본 설정된 명령줄 도구를 사용하여 선택한 AWS 리전에서 AWS 계정에 대한 AWS Systems Manager Session Manager 기본 설정을 변경하는 방법을 설명합니다. Session Manager 기본 설정을 사용하여 Amazon Simple Storage Service(Amazon S3) 버킷 또는 Amazon CloudWatch Logs 로그 그룹에서 세션 데이터를 로그하는 옵션을 지정합니다. Session Manager 기본 설정을 사용하여 세션 데이터를 암호화할 수도 있습니다.
**Session Manager 기본 설정을 업데이트하려면(명령줄)**
1. 로컬 시스템에서 `SessionManagerRunShell.json`이라는 JSON 파일을 생성한 다음 이 파일에 다음 내용을 붙여 넣습니다.
```
{
"schemaVersion": "1.0",
"description": "Document to hold regional settings for Session Manager",
"sessionType": "Standard_Stream",
"inputs": {
"s3BucketName": "",
"s3KeyPrefix": "",
"s3EncryptionEnabled": true,
"cloudWatchLogGroupName": "",
"cloudWatchEncryptionEnabled": true,
"cloudWatchStreamingEnabled": false,
"kmsKeyId": "",
"runAsEnabled": true,
"runAsDefaultUser": "",
"idleSessionTimeout": "",
"maxSessionDuration": "",
"shellProfile": {
"windows": "date",
"linux": "pwd;ls"
}
}
}
```
1. 세션 데이터를 보낼 위치를 지정하십시오. S3 버킷 이름(선택적 접두사 사용) 또는 CloudWatch Logs 로그 그룹 이름을 지정할 수 있습니다. 로컬 클라이언트와 관리형 노드 사이에 데이터를 추가로 암호화하려면 암호화에 사용할 AWS KMS key를 제공하세요. 다음은 예입니다.
```
{
"schemaVersion": "1.0",
"description": "Document to hold regional settings for Session Manager",
"sessionType": "Standard_Stream",
"inputs": {
"s3BucketName": "amzn-s3-demo-bucket",
"s3KeyPrefix": "MyS3Prefix",
"s3EncryptionEnabled": true,
"cloudWatchLogGroupName": "MyLogGroupName",
"cloudWatchEncryptionEnabled": true,
"cloudWatchStreamingEnabled": false,
"kmsKeyId": "MyKMSKeyID",
"runAsEnabled": true,
"runAsDefaultUser": "MyDefaultRunAsUser",
"idleSessionTimeout": "20",
"maxSessionDuration": "60",
"shellProfile": {
"windows": "MyCommands",
"linux": "MyCommands"
}
}
}
```
**참고**
세션 로그 데이터를 암호화하지 않으려는 경우 `s3EncryptionEnabled`의 `true`를 `false`로 변경합니다.
Amazon S3 버킷 또는 CloudWatch Logs 로그 그룹에 로그를 보내지 않거나, 활성 세션 데이터를 암호화하지 않거나, 계정 세션에서 Run As 지원을 설정하지 않으려면 해당 옵션에 대한 행을 삭제할 수 있습니다. `inputs` 섹션의 마지막 줄은 쉼표로 끝나면 안 됩니다.
KMS 키 ID를 추가하여 세션 데이터를 암호화하면 세션을 시작하는 사용자와 거기에 연결하는 관리형 노드 모두에 키를 사용할 권한이 있어야 합니다. Session Manager과 함께 AWS Identity and Access Management(IAM) 정책을 통해 KMS 키를 사용할 수 있는 권한을 제공합니다. 자세한 내용은 다음 주제를 참조하세요.
계정의 사용자에 대한 AWS KMS 권한 추가: [Session Manager에 대한 샘플 IAM 정책](getting-started-restrict-access-quickstart.md).
계정의 관리형 노드에 대한 AWS KMS 권한 추가: [2단계: Session Manager의 인스턴스 권한 확인 또는 추가](session-manager-getting-started-instance-profile.md).
1. 파일을 저장합니다.
1. JSON 파일을 생성한 디렉터리에서 다음 명령을 실행합니다.
------
#### [ Linux & macOS ]
```
aws ssm update-document \
--name "SSM-SessionManagerRunShell" \
--content "file://SessionManagerRunShell.json" \
--document-version "\$LATEST"
```
------
#### [ Windows ]
```
aws ssm update-document ^
--name "SSM-SessionManagerRunShell" ^
--content "file://SessionManagerRunShell.json" ^
--document-version "$LATEST"
```
------
#### [ PowerShell ]
```
Update-SSMDocument `
-Name "SSM-SessionManagerRunShell" `
-Content (Get-Content -Raw SessionManagerRunShell.json) `
-DocumentVersion '$LATEST'
```
------
이 작업이 성공하면 다음과 비슷한 출력이 반환됩니다.
```
{
"DocumentDescription": {
"Status": "Updating",
"Hash": "ce4fd0a2ab9b0fae759004ba603174c3ec2231f21a81db8690a33eb66EXAMPLE",
"Name": "SSM-SessionManagerRunShell",
"Tags": [],
"DocumentType": "Session",
"PlatformTypes": [
"Windows",
"Linux"
],
"DocumentVersion": "2",
"HashType": "Sha256",
"CreatedDate": 1537206341.565,
"Owner": "111122223333",
"SchemaVersion": "1.0",
"DefaultVersion": "1",
"DocumentFormat": "JSON",
"LatestVersion": "2"
}
}
```
# 5단계: (선택 사항) 세션의 명령에 대한 액세스 제한
사용자 지정 `Session` 유형 AWS Systems Manager(SSM) 문서를 사용하여 사용자가 AWS Systems Manager Session Manager세션에서 실행할 수 있는 명령을 제한할 수 있습니다. 문서에서 사용자가 세션을 시작할 때 실행할 수 있는 명령과 사용자가 명령에 제공할 수 있는 파라미터를 정의합니다. `Session` 문서 `schemaVersion`은 1.0이어야 하고 문서의 `sessionType`은 `InteractiveCommands`여야 합니다. 그러면 직접 정의하는 `Session` 문서에만 사용자가 액세스할 수 있도록 허용하는 AWS Identity and Access Management(IAM) 정책을 생성할 수 있습니다. IAM 정책을 사용하여 세션의 명령에 대한 액세스를 제한하는 방법에 대한 자세한 내용은 [대화형 명령에 대한 IAM 정책 예제](#interactive-command-policy-examples) 섹션을 참조하세요.
`InteractiveCommands`의 `sessionType`이 포함된 문서는 AWS Command Line Interface(AWS CLI) 에서 시작된 세션의 경우에만 지원됩니다. 사용자는 사용자 지정 문서 이름을 `--document-name` 파라미터 값으로 제공하고 `--parameters` 옵션을 사용하여 모든 명령 파라미터 변수 값을 제공합니다. 대화형 명령 실행에 대한 자세한 내용은 [세션 시작(대화형 및 비대화형 명령)](session-manager-working-with-sessions-start.md#sessions-start-interactive-commands) 섹션을 참조하세요.
다음 절차를 사용하여 사용자가 실행할 수 있는 명령을 정의하는 사용자 지정 `Session` 유형 SSM 문서를 생성합니다.
## 세션의 명령에 대한 액세스 제한(콘솔)
**사용자가 Session Manager 세션에서 실행할 수 있는 명령을 제한하려면(콘솔)**
1. AWS Systems Manager 콘솔([https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/))을 엽니다.
1. 탐색 창에서 **Documents**를 선택합니다.
1. **명령 또는 세션 생성**을 선택합니다.
1. [**이름(Name)**]에 문서에 대한 설명이 포함된 이름을 입력합니다.
1. **문서 유형**에서 **세션 문서**를 선택합니다.
1. 다음 예제와 같이 사용자가 JSON 또는 YAML을 사용하여 Session Manager 세션에서 실행할 수 있는 명령을 정의하는 문서 내용을 입력합니다.
------
#### [ YAML ]
```
---
schemaVersion: '1.0'
description: Document to view a log file on a Linux instance
sessionType: InteractiveCommands
parameters:
logpath:
type: String
description: The log file path to read.
default: "/var/log/amazon/ssm/amazon-ssm-agent.log"
allowedPattern: "^[a-zA-Z0-9-_/]+(.log)$"
properties:
linux:
commands: "tail -f {{ logpath }}"
runAsElevated: true
```
------
#### [ JSON ]
```
{
"schemaVersion": "1.0",
"description": "Document to view a log file on a Linux instance",
"sessionType": "InteractiveCommands",
"parameters": {
"logpath": {
"type": "String",
"description": "The log file path to read.",
"default": "/var/log/amazon/ssm/amazon-ssm-agent.log",
"allowedPattern": "^[a-zA-Z0-9-_/]+(.log)$"
}
},
"properties": {
"linux": {
"commands": "tail -f {{ logpath }}",
"runAsElevated": true
}
}
}
```
------
1. **문서 생성**을 선택합니다.
## 세션의 명령에 대한 액세스 제한(명령줄)
**시작하기 전 준비 사항**
아직 하지 않은 경우 AWS Command Line Interface(AWS CLI) 또는 AWS Tools for PowerShell을 설치하고 구성합니다. 자세한 내용은 [최신 버전의 AWS CLI 설치 또는 업데이트](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html) 및 [AWS Tools for PowerShell 설치](https://docs.aws.amazon.com/powershell/latest/userguide/pstools-getting-set-up.html)를 참조하세요.
**사용자가 Session Manager 세션에서 실행할 수 있는 명령을 제한하려면(명령줄)**
1. 다음 예제와 같이 사용자가 Session Manager 세션에서 실행할 수 있는 명령을 정의하는 문서 내용에 JSON 또는 YAML 파일을 생성합니다.
------
#### [ YAML ]
```
---
schemaVersion: '1.0'
description: Document to view a log file on a Linux instance
sessionType: InteractiveCommands
parameters:
logpath:
type: String
description: The log file path to read.
default: "/var/log/amazon/ssm/amazon-ssm-agent.log"
allowedPattern: "^[a-zA-Z0-9-_/]+(.log)$"
properties:
linux:
commands: "tail -f {{ logpath }}"
runAsElevated: true
```
------
#### [ JSON ]
```
{
"schemaVersion": "1.0",
"description": "Document to view a log file on a Linux instance",
"sessionType": "InteractiveCommands",
"parameters": {
"logpath": {
"type": "String",
"description": "The log file path to read.",
"default": "/var/log/amazon/ssm/amazon-ssm-agent.log",
"allowedPattern": "^[a-zA-Z0-9-_/]+(.log)$"
}
},
"properties": {
"linux": {
"commands": "tail -f {{ logpath }}",
"runAsElevated": true
}
}
}
```
------
1. 다음 명령을 실행하여 사용자가 Session Manager 세션에서 실행할 수 있는 명령을 정의하는 내용을 사용하여 SSM 문서를 생성합니다.
------
#### [ Linux & macOS ]
```
aws ssm create-document \
--content file://path/to/file/documentContent.json \
--name "exampleAllowedSessionDocument" \
--document-type "Session"
```
------
#### [ Windows ]
```
aws ssm create-document ^
--content file://C:\path\to\file\documentContent.json ^
--name "exampleAllowedSessionDocument" ^
--document-type "Session"
```
------
#### [ PowerShell ]
```
$json = Get-Content -Path "C:\path\to\file\documentContent.json" | Out-String
New-SSMDocument `
-Content $json `
-Name "exampleAllowedSessionDocument" `
-DocumentType "Session"
```
------
## 대화형 명령 파라미터 및 AWS CLI
AWS CLI를 사용할 때 대화형 명령 파라미터를 제공할 수 있는 다양한 방법이 있습니다. AWS CLI가 있는 관리형 노드에 연결하는 데 사용하는 클라이언트 시스템의 운영 체제(OS)에 따라 특수 문자나 이스케이프 문자가 포함된 명령에 제공하는 구문이 다를 수 있습니다. 다음 예는 AWS CLI 사용 시 명령 파라미터를 제공할 수 있는 몇 가지 다른 방법과 특수 문자 또는 이스케이프 문자를 처리하는 방법을 보여줍니다.
Parameter Store에 저장된 파라미터는 다음 예와 같이 명령 파라미터에 대해 AWS CLI에서 참조할 수 있습니다.
------
#### [ Linux & macOS ]
```
aws ssm start-session \
--target instance-id \
--document-name MyInteractiveCommandDocument \
--parameters '{"command":["{{ssm:mycommand}}"]}'
```
------
#### [ Windows ]
```
aws ssm start-session ^
--target instance-id ^
--document-name MyInteractiveCommandDocument ^
--parameters '{"command":["{{ssm:mycommand}}"]}'
```
------
다음 예에서는 AWS CLI에 약식 구문을 사용하여 파라미터를 전달하는 방법을 보여줍니다.
------
#### [ Linux & macOS ]
```
aws ssm start-session \
--target instance-id \
--document-name MyInteractiveCommandDocument \
--parameters command="ifconfig"
```
------
#### [ Windows ]
```
aws ssm start-session ^
--target instance-id ^
--document-name MyInteractiveCommandDocument ^
--parameters command="ipconfig"
```
------
다음 예와 같이 JSON에서 파라미터를 제공할 수도 있습니다.
------
#### [ Linux & macOS ]
```
aws ssm start-session \
--target instance-id \
--document-name MyInteractiveCommandDocument \
--parameters '{"command":["ifconfig"]}'
```
------
#### [ Windows ]
```
aws ssm start-session ^
--target instance-id ^
--document-name MyInteractiveCommandDocument ^
--parameters '{"command":["ipconfig"]}'
```
------
파라미터를 JSON 파일에 저장하고 다음 예와 같이 AWS CLI에 제공할 수도 있습니다. 파일에서 AWS CLI 파라미터 사용에 대한 자세한 내용은 *AWS Command Line Interface 사용 설명서*의 [파일에서 AWS CLI 파라미터 로드](https://docs.aws.amazon.com/cli/latest/userguide/;cli-usage-parameters-file.html)를 참조하세요.
```
{
"command": [
"my command"
]
}
```
------
#### [ Linux & macOS ]
```
aws ssm start-session \
--target instance-id \
--document-name MyInteractiveCommandDocument \
--parameters file://complete/path/to/file/parameters.json
```
------
#### [ Windows ]
```
aws ssm start-session ^
--target instance-id ^
--document-name MyInteractiveCommandDocument ^
--parameters file://complete/path/to/file/parameters.json
```
------
다음 예와 같이 JSON 입력 파일에서 AWS CLI 스켈레톤을 생성할 수도 있습니다. JSON 입력 파일에서 AWS CLI 스켈레톤 생성에 대한 자세한 내용은 *AWS Command Line Interface 사용 설명서*의 [JSON 또는 YAML 입력 파일에서 AWS CLI 스켈레톤 및 입력 파라미터 생성](https://docs.aws.amazon.com/cli/latest/userguide/;cli-usage-skeleton.html)을 참조하세요.
```
{
"Target": "instance-id",
"DocumentName": "MyInteractiveCommandDocument",
"Parameters": {
"command": [
"my command"
]
}
}
```
------
#### [ Linux & macOS ]
```
aws ssm start-session \
--cli-input-json file://complete/path/to/file/parameters.json
```
------
#### [ Windows ]
```
aws ssm start-session ^
--cli-input-json file://complete/path/to/file/parameters.json
```
------
따옴표 안의 문자를 이스케이프 처리하려면 다음 예와 같이 이스케이프 문자에 백슬래시를 추가해야 합니다.
------
#### [ Linux & macOS ]
```
aws ssm start-session \
--target instance-id \
--document-name MyInteractiveCommandDocument \
--parameters '{"command":["printf \"abc\\\\tdef\""]}'
```
------
#### [ Windows ]
```
aws ssm start-session ^
--target instance-id ^
--document-name MyInteractiveCommandDocument ^
--parameters '{"command":["printf \"abc\\\\tdef\""]}'
```
------
AWS CLI에서 명령 파라미터에 따옴표를 사용에 대한 자세한 내용은 *AWS Command Line Interface 사용 설명서*의 [AWS CLI에서 문자열에 따옴표 사용](https://docs.aws.amazon.com/cli/latest/userguide/;cli-usage-parameters-quoting-strings.html)을 참조하세요.
## 대화형 명령에 대한 IAM 정책 예제
직접 정의한 `Session` 문서에만 사용자가 액세스할 수 있도록 허용하는 IAM정책을 생성할 수 있습니다. 이렇게 하면 사용자가 Session Manager 세션에서 실행할 수 있는 명령이 사용자 정의 `Session` 유형 SSM 문서에 정의된 명령으로만 제한됩니다.
**사용자가 단일 관리형 노드에서 대화형 명령을 실행하도록 허용**
****
```
{
"Version":"2012-10-17",
"Statement":[
{
"Effect":"Allow",
"Action":"ssm:StartSession",
"Resource":[
"arn:aws:ec2:us-east-1:444455556666:instance/i-02573cafcfEXAMPLE",
"arn:aws:ssm:us-east-1:444455556666:document/allowed-session-document"
]
},
{
"Effect": "Allow",
"Action": ["ssmmessages:OpenDataChannel"],
"Resource": ["arn:aws:ssm:*:*:session/${aws:userid}-*"]
}
]
}
```
**사용자가 모든 관리형 노드에서 대화형 명령을 실행하도록 허용**
****
```
{
"Version":"2012-10-17",
"Statement":[
{
"Effect":"Allow",
"Action":"ssm:StartSession",
"Resource":[
"arn:aws:ec2:us-east-1:444455556666:instance/*",
"arn:aws:ssm:us-east-1:444455556666:document/allowed-session-document"
]
},
{
"Effect": "Allow",
"Action": ["ssmmessages:OpenDataChannel"],
"Resource": ["arn:aws:ssm:*:*:session/${aws:userid}-*"]
}
]
}
```
**사용자가 모든 관리형 노드에서 여러 대화형 명령을 실행하도록 허용**
****
```
{
"Version":"2012-10-17",
"Statement":[
{
"Effect":"Allow",
"Action":"ssm:StartSession",
"Resource":[
"arn:aws:ec2:us-east-1:444455556666:instance/*",
"arn:aws:ssm:us-east-1:444455556666:document/allowed-session-document",
"arn:aws:ssm:us-east-1:444455556666:document/allowed-session-document-2"
]
},
{
"Effect": "Allow",
"Action": ["ssmmessages:OpenDataChannel"],
"Resource": ["arn:aws:ssm:*:*:session/${aws:userid}-*"]
}
]
}
```
# 6단계: (옵션) AWS PrivateLink를 사용하여 Session Manager에 대한 VPC 엔드포인트 설정
인터페이스 Virtual Private Cloud(VPC) 엔드포인트를 사용하도록 AWS Systems Manager를 구성하여 관리형 노드의 보안 태세를 개선할 수 있습니다. 인터페이스 엔드포인트는 프라이빗 IP 주소를 사용하여 Amazon Elastic Compute Cloud(Amazon EC2) 및 Systems Manager API에 비공개로 액세스할 수 있는 기술인 AWS PrivateLink로 구동됩니다.
AWS PrivateLink는 관리형 노드, Systems Manager 및 Amazon EC2 간의 모든 네트워크 트래픽을 Amazon 네트워크로 제한합니다. (관리형 노드는 인터넷에 액세스할 수 없음) 또한 인터넷 게이트웨이, NAT 디바이스 또는 가상 프라이빗 게이트웨이가 필요 없습니다.
VPC 엔드포인트 생성에 대한 자세한 내용은 [Systems Manager용 VPC 엔드포인트를 사용하여 EC2 인스턴스의 보안 개선](setup-create-vpc.md)을 참조하세요.
VPC 엔드포인트 사용의 대체 방법은 관리형 노드에서 아웃바운드 인터넷 액세스를 허용하는 것입니다. 이 경우 관리형 노드는 다음 엔드포인트에 대한 HTTPS(포트 443) 아웃바운드 트래픽도 허용해야 합니다.
+ `ec2messages.region.amazonaws.com`
+ `ssm.region.amazonaws.com`
+ `ssmmessages.region.amazonaws.com`
Systems Manager는 이러한 엔드포인트 중 마지막 엔드포인트인 `ssmmessages.region.amazonaws.com`을 사용하여 SSM Agent에서 클라우드의 Session Manager 서비스를 호출합니다.
AWS Key Management Service(AWS KMS)와 같은 선택적 기능을 사용하려면 암호화, Amazon CloudWatch Logs(CloudWatch 로그)로 로그를 스트리밍하고, Amazon Simple Storage Service(Amazon S3)로 로그를 전송하려면 HTTPS(포트 443) 아웃바운드 트래픽을 다음 엔드포인트로 허용해야 합니다.
+ `kms.region.amazonaws.com`
+ `logs.region.amazonaws.com`
+ `s3.region.amazonaws.com`
Systems Manager의 필수 엔드포인트에 대한 자세한 내용은 [참조: ec2messages, ssmmessages 및 기타 API 작업](systems-manager-setting-up-messageAPIs.md) 섹션을 참조하세요.
# 7단계: (옵션) ssm-user 계정 관리 권한 설정 또는 해제
AWS Systems Manager SSM Agent 버전 2.3.50.0부터 에이전트에서 `ssm-user`라는 로컬 사용자 계정을 생성하여 `/etc/sudoers`(Linux 및 macOS) 또는 관리자 그룹(Windows)에 추가합니다. 2.3.612.0 이전 버전의 에이전트에서 SSM Agent 최초 시작 또는 설치 후 재시작 시 계정이 생성됩니다. 2.3.612.0 이후 버전에서 `ssm-user` 계정은 노드에서 세션을 처음 시작할 때 생성됩니다. AWS Systems Manager Session Manager 세션이 시작될 때 `ssm-user`가 기본 운영 체제(OS) 사용자입니다. SSM Agent 버전 2.3.612.0은 2019년 5월 8일에 릴리스되었습니다.
Session Manager 사용자가 노드에서 관리 명령을 실행하지 못하도록 하려는 경우 `ssm-user` 계정 권한을 업데이트할 수 있습니다. 또한 제거한 후 이러한 권한을 복원할 수도 있습니다.
**Topics**
+ [Linux 및 macOS에서 ssm-user sudo 계정 권한 관리](#ssm-user-permissions-linux)
+ [Windows Server에서 ssm-user 관리자 계정 권한 관리](#ssm-user-permissions-windows)
## Linux 및 macOS에서 ssm-user sudo 계정 권한 관리
다음과 같은 절차 중 하나를 사용하여 Linux 및 macOS 관리형 노드에 대한 ssm-user 계정 sudo 권한을 설정하거나 해제합니다.
**Run Command을 사용하여 ssm-user sudo 권한 수정(콘솔)**
+ 다음 값을 사용해 [콘솔에서 명령 실행](running-commands-console.md)의 절차를 따릅니다.
+ **명령 문서(Command document**에서 `AWS-RunShellScript`를 선택합니다.
+ sudo 액세스 권한을 제거하려면 [**명령 파라미터(Command parameters)**] 영역에서 [**명령(Commands)**] 상자에 다음을 붙여 넣습니다.
```
cd /etc/sudoers.d
echo "#User rules for ssm-user" > ssm-agent-users
```
-또는-
sudo 액세스를 복원하려면 **명령 파라미터(Commands)** 영역에서 **명령(Commands)** 상자에 다음을 붙여 넣습니다.
```
cd /etc/sudoers.d
echo "ssm-user ALL=(ALL) NOPASSWD:ALL" > ssm-agent-users
```
**명령줄을 사용해 ssm-user sudo 권한 수정(AWS CLI)**
1. 관리형 노드에 연결하고 다음 명령을 실행합니다.
```
sudo -s
```
1. 다음 명령을 사용하여 작업 디렉터리를 변경합니다.
```
cd /etc/sudoers.d
```
1. 편집하기 위해 `ssm-agent-users` 파일을 엽니다.
1. sudo 액세스를 제거하려면 다음 줄을 삭제합니다.
```
ssm-user ALL=(ALL) NOPASSWD:ALL
```
-또는-
sudo 액세스를 복원하려면 다음 줄을 추가합니다.
```
ssm-user ALL=(ALL) NOPASSWD:ALL
```
1. 파일을 저장합니다.
## Windows Server에서 ssm-user 관리자 계정 권한 관리
다음 절차 중 하나를 수행해 Windows Server 관리형 노드에 대한 ssm-user 계정 관리자 권한을 설정하거나 해제합니다.
**Run Command를 사용하여 관리자 권한 수정(콘솔)**
+ 다음 값을 사용해 [콘솔에서 명령 실행](running-commands-console.md)의 절차를 따릅니다.
**명령 문서(Command document**에서 `AWS-RunPowerShellScript`를 선택합니다.
관리 액세스를 제거하려면 **명령 파라미터(Command parameters)** 영역의 **명령(Commands)** 상자에 다음 내용을 붙여 넣습니다.
```
net localgroup "Administrators" "ssm-user" /delete
```
-또는-
관리 액세스를 복원하려면 **명령 파라미터(Command parameters)** 영역의 **명령(Commands)** 상자에 다음 내용을 붙여 넣습니다.
```
net localgroup "Administrators" "ssm-user" /add
```
**PowerShell 또는 명령 프롬프트 창을 사용하여 관리자 권한 수정**
1. 관리형 노드에 연결하고 PowerShell 또는 명령 프롬프트 창을 엽니다.
1. 관리 액세스를 제거하려면 다음 명령을 실행합니다.
```
net localgroup "Administrators" "ssm-user" /delete
```
-또는-
관리 액세스를 복원하려면 다음 명령을 실행합니다.
```
net localgroup "Administrators" "ssm-user" /add
```
**Windows 콘솔을 사용하여 관리자 권한 수정**
1. 관리형 노드에 연결하고 PowerShell 또는 명령 프롬프트 창을 엽니다.
1. 명령줄에서 `lusrmgr.msc`를 실행하여 **Local Users and Groups(로컬 사용자 및 그룹)** 콘솔을 엽니다.
1. **사용자** 디렉터리를 열고 **ssm-user**를 엽니다.
1. **소속 그룹(Member Of)** 탭에서 다음 중 한 가지를 수행합니다.
+ 관리 액세스를 제거하려면 **관리자**를 선택하고 **제거**를 선택합니다.
-또는-
관리 액세스를 복원하려면 텍스트 상자에 **Administrators**를 입력한 다음 [**추가(Add)**]를 선택합니다.
1. **확인**을 선택합니다.
# 8단계: (선택 사항) Session Manager를 통한 SSH 연결에 대한 권한 허용 및 제어
AWS Command Line Interface(AWS CLI)를 사용하여 AWS Systems Manager Session Manager를 통해 관리형 노드에 SSH(Secure Shell) 연결을 설정하도록 AWS 계정의 사용자를 허용할 수 있습니다. SSH로 연결하는 사용자는 로컬 시스템과 관리형 노드 사이에서 SCP(Secure Copy Protocol)를 사용하여 파일을 복사하는 것도 가능합니다. 이 기능을 사용하면 인바운드 포트를 개방하거나 Bastion 호스트를 유지하지 않고도 관리형 노드에 연결할 수 있습니다.
Session Manager를 통해 SSH 연결을 설정하면 AWS CLI 및 SSM Agent가 TLS를 통해 Session Manager 엔드포인트에 대한 보안 WebSocket 연결을 생성합니다. SSH 세션은 이 암호화된 터널 내에서 실행되므로 관리형 노드에서 인바운드 포트를 열지 않고도 추가 보안 계층을 제공합니다.
SSH 연결을 허용한 후 AWS Identity and Access Management(IAM) 정책을 사용하여 사용자, 그룹 또는 역할이 Session Manager를 사용한 SSH 연결을 명시적으로 허용하거나 거부하도록 할 수 있습니다.
**참고**
포트 전달 또는 SSH를 통해 연결하는 Session Manager 세션에는 로깅을 사용할 수 없습니다. 이는 SSH가 AWS CLI 엔드포인트와 Session Manager 엔드포인트 간에 설정된 보안 TLS 연결 내의 모든 세션 데이터를 암호화하고 Session Manager는 SSH 연결을 위한 터널 역할만 하기 때문입니다.
**Topics**
+ [Session Manager의 SSH 연결 허용](#ssh-connections-enable)
+ [Session Manager를 통해 SSH 연결에 대한 사용자 권한 제어](#ssh-connections-permissions)
## Session Manager의 SSH 연결 허용
다음 단계를 사용하여 관리형 노드에서 Session Manager를 통해 SSH 연결을 허용합니다.
**Session Manager의 SSH 연결 허용**
1. SSH 연결을 허용할 관리형 노드에서 다음과 같이 실행합니다.
+ 관리형 노드에서 SSH가 실행 중인지 확인합니다. (노드에서 인바운드 포트를 폐쇄할 수 있습니다)
+ SSM Agent 2.3.672.0 이상이 관리형 노드에 설치되어 있는지 확인합니다.
관리형 노드에 SSM Agent를 설치하거나 업데이트하는 방법에 대한 자세한 내용은 다음 주제를 참조하세요.
+ [SSM Agent용 EC2 인스턴스에 수동으로 Windows Server 설치 및 제거](manually-install-ssm-agent-windows.md).
+ [Linux용 EC2 인스턴스에 수동으로 SSM Agent 설치 및 제거](manually-install-ssm-agent-linux.md)
+ [SSM Agent용 EC2 인스턴스에 수동으로 macOS 설치 및 제거](manually-install-ssm-agent-macos.md)
+ [하이브리드 Windows 노드에 SSM Agent를 설치하는 방법](hybrid-multicloud-ssm-agent-install-windows.md)
+ [하이브리드 Linux 노드에 SSM Agent를 설치하는 방법](hybrid-multicloud-ssm-agent-install-linux.md)
**참고**
관리형 노드로 활성화한 온프레미스 서버, 엣지 디바이스, 가상 머신에서 Session Manager를 사용하려면 고급 인스턴스 티어를 사용해야 합니다. 전용 인스턴스에 대한 자세한 내용은 [인스턴스 티어 구성](fleet-manager-configure-instance-tiers.md) 섹션을 참조하세요.
1. SSH로 관리형 노드에 연결할 로컬 시스템에서 다음과 같이 실행합니다.
+ Session Manager 플러그인 버전 1.1.23.0 이상이 설치되어 있는지 확인합니다.
Session Manager 플러그인 설치에 대한 자세한 내용은 [AWS CLI의 Session Manager 플러그인 설치](session-manager-working-with-install-plugin.md) 섹션을 참조하세요.
+ 프록시 명령 실행을 허용하여 Session Manager 세션을 시작할 수 있도록 SSH 구성 파일을 업데이트한 후 SSH 연결을 통해 모든 데이터를 전송합니다.
**Linux 및 macOS**
**작은 정보**
SSH 구성 파일은 일반적으로 `~/.ssh/config`에 있습니다.
로컬 시스템에서 다음과 같이 구성 파일에 추가합니다.
```
# SSH over Session Manager
Host i-* mi-*
ProxyCommand sh -c "aws ssm start-session --target %h --document-name AWS-StartSSHSession --parameters 'portNumber=%p'"
User ec2-user
```
** Windows **
**작은 정보**
SSH 구성 파일은 일반적으로 `C:\Users\\.ssh\config`에 있습니다.
로컬 시스템에서 다음과 같이 구성 파일에 추가합니다.
```
# SSH over Session Manager
Host i-* mi-*
ProxyCommand C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe "aws ssm start-session --target %h --document-name AWS-StartSSHSession --parameters portNumber=%p"
```
+ 관리형 노드에 연결 설정 시 사용할 Privacy Enhanced Mail 인증서(PEM 파일) 또는 최소 퍼블릭 키를 생성하거나 갖추고 있는지 확인합니다. 이 키는 관리형 노드와 이미 연결된 키여야 합니다. 사용자만 읽을 수 있도록 프라이빗 키 파일의 권한을 설정해야 합니다. 다음 명령을 사용하여 사용자만 읽을 수 있도록 프라이빗 키 파일의 권한을 설정할 수 있습니다.
```
chmod 400 .pem
```
예를 들어 Amazon Elastic Compute Cloud(Amazon EC2) 인스턴스의 경우 인스턴스를 생성할 때 선택 또는 생성한 키 페어 파일입니다. (세션을 시작하는 명령의 일부로 인증서 또는 키에 대한 경로를 지정합니다. SSH를 사용하여 세션 시작에 대한 자세한 내용은 [세션 시작(SSH)](session-manager-working-with-sessions-start.md#sessions-start-ssh) 섹션을 참조하세요.)
## Session Manager를 통해 SSH 연결에 대한 사용자 권한 제어
Session Manager를 통해 관리형 노드에서 SSH 연결을 활성화한 후 IAM 정책을 사용하여 사용자, 그룹 또는 역할이 Session Manager를 통해 SSH 연결을 수립할 수 있는 기능을 허용하거나 거부할 수 있습니다.
**Session Manager를 통한 SSH 연결을 허용하는 IAM 정책을 사용하려면**
+ 다음 옵션 중 하나를 사용하세요.
+ **옵션 1**: [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)에서 IAM 콘솔을 엽니다.
탐색 창에서 **정책**을 선택한 다음 Session Manager을 통해 SSH 연결을 시작할 수 있도록 허용할 사용자 또는 역할에 대한 권한 정책을 업데이트합니다.
예를 들어 [Session Manager에 대한 빠른 시작 최종 사용자 정책](getting-started-restrict-access-quickstart.md#restrict-access-quickstart-end-user)에서 생성한 빠른 시작 정책에 다음 요소를 추가합니다. 각 *리소스 자리 표시자 예*를 자신의 정보로 바꿉니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "ssm:StartSession",
"Resource": [
"arn:aws:ec2:us-east-1:111122223333:instance/instance-id",
"arn:aws:ssm:*:*:document/AWS-StartSSHSession"
]
},
{
"Effect": "Allow",
"Action": "ssmmessages:OpenDataChannel",
"Resource": "arn:aws:ssm:*:*:session/${aws:userid}-*"
}
]
}
```
------
+ **옵션 2**: AWS Management Console, AWS CLI 또는 AWS API를 사용하여 인라인 정책을 사용자 정책에 연결합니다.
선택한 방법을 사용하여 **옵션 1**의 정책 문을 AWS 사용자, 그룹 또는 역할에 대한 정책에 연결합니다.
자세한 내용은 *IAM User Guide*의 [Adding and Removing IAM Identity Permissions](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage-attach-detach.html)를 참조하세요.
**Session Manager를 통한 SSH 연결을 거부하는 IAM 정책을 사용하려면**
+ 다음 옵션 중 하나를 사용하세요.
+ **옵션 1**: [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)에서 IAM 콘솔을 엽니다. 탐색 창에서 **정책**을 선택한 다음, Session Manager 세션의 시작을 차단하도록 사용자 또는 역할에 대한 권한 정책을 업데이트합니다.
예를 들어 [Session Manager에 대한 빠른 시작 최종 사용자 정책](getting-started-restrict-access-quickstart.md#restrict-access-quickstart-end-user)에서 생성한 빠른 시작 정책에 다음 요소를 추가합니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Action": "ssm:StartSession",
"Resource": "arn:aws:ssm:*:*:document/AWS-StartSSHSession"
},
{
"Effect": "Allow",
"Action": "ssmmessages:OpenDataChannel",
"Resource": "arn:aws:ssm:*:*:session/${aws:userid}-*"
}
]
}
```
------
+ **옵션 2**: AWS Management Console, AWS CLI 또는 AWS API를 사용하여 인라인 정책을 사용자 정책에 연결합니다.
선택한 방법을 사용하여 **옵션 1**의 정책 문을 AWS 사용자, 그룹 또는 역할에 대한 정책에 연결합니다.
자세한 내용은 *IAM User Guide*의 [Adding and Removing IAM Identity Permissions](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage-attach-detach.html)를 참조하세요.
# Session Manager 작업
AWS Systems Manager 콘솔, Amazon Elastic Compute Cloud(Amazon EC2) 콘솔 또는 AWS Command Line Interface(AWS CLI)로 시스템 관리자가 AWS Identity and Access Management(IAM) 정책을 사용하여 액세스 권한을 부여한 관리형 노드에 연결하는 세션을 시작할 수 있습니다. 권한에 따라 세션에 대한 정보를 보거나, 시간이 초과되지 않은 비활성 세션을 다시 시작하고, 세션을 종료할 수 있습니다. 세션이 설정된 후에는 IAM 역할 세션 기간의 영향을 받지 않습니다. Session Manager의 세션 기간 제한에 대한 자세한 내용은 [유휴 세션 시간 제한 값 지정](session-preferences-timeout.md) 및 [최대 세션 기간 지정](session-preferences-max-timeout.md)의 내용을 참조하세요.
세션에 대한 자세한 내용은 [세션이란 무엇입니까?](session-manager.md#what-is-a-session) 섹션을 참조하세요.
**Topics**
+ [AWS CLI의 Session Manager 플러그인 설치](session-manager-working-with-install-plugin.md)
+ [세션 시작](session-manager-working-with-sessions-start.md)
+ [세션 종료](session-manager-working-with-sessions-end.md)
+ [세션 기록 보기](session-manager-working-with-view-history.md)
# AWS CLI의 Session Manager 플러그인 설치
AWS Command Line Interface(AWS CLI)를 사용하여 관리형 노드로 Session Manager 세션을 시작하려면 로컬 시스템에 **Session Manager 플러그인을 설치해야 합니다. Microsoft Windows Server, macOS, Linux, Ubuntu Server의 지원되는 버전에 플러그인을 설치할 수 있습니다.
**참고**
AWS CLI 플러그인을 사용하려면 로컬 시스템에 Session Manager 버전 1.16.12 이상이 설치되어 있어야 합니다. 자세한 내용은 [최신 버전의 AWS Command Line Interface 설치 또는 업데이트](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html)를 참조하세요.
**Topics**
+ [Session Manager 플러그인 최신 버전 및 릴리스 기록](plugin-version-history.md)
+ [Windows에 Session Manager 플러그 인 설치](install-plugin-windows.md)
+ [macOS에 Session Manager 플러그 인 설치](install-plugin-macos-overview.md)
+ [Linux에 Session Manager 플러그인 설치](install-plugin-linux-overview.md)
+ [Session Manager 플러그인 설치 확인](install-plugin-verify.md)
+ [GitHub에서 Session Manager 플러그인 켜기](plugin-github.md)
+ [(옵션) Session Manager 플러그인 로깅 설정](install-plugin-configure-logs.md)
# Session Manager 플러그인 최신 버전 및 릴리스 기록
로컬 시스템에서 Session Manager 플러그인의 지원되는 버전이 실행 중이어야 합니다. 현재 지원되는 최소 버전은 1.1.17.0입니다. 이전 버전을 실행 중인 경우 Session Manager 작업에 실패할 수 있습니다.
최신 버전이 설치되어 있는지 확인하려면 AWS CLI에서 다음 명령을 실행합니다.
**참고**
이 명령은 플러그인이 운영 체제 유형의 기본 설치 디렉터리에 있는 경우에만 결과를 반환합니다. 또한 플러그인을 설치한 디렉터리에 있는 `VERSION` 파일의 내용에서 버전을 확인할 수도 있습니다.
```
session-manager-plugin --version
```
다음 표에는 Session Manager 플러그인의 모든 릴리스와 각 릴리스에 포함된 기능 및 기능 향상이 나와 있습니다.
**중요**
항상 최신 버전을 실행하는 것이 좋습니다. 최신 버전에는 플러그인 사용 환경을 개선해주는 개선 사항이 포함되어 있습니다.
| 버전 | 릴리스 날짜 | 세부 정보 |
| --- | --- | --- |
| 1.2.792.0 | 2026년 3월 17일 | **버그 수정**: Windows에 대한 국제 키보드 지원을 추가합니다. |
| 1.2.779.0 | 2026년 2월 12일 | **기능 향상**: Dockerfile에서 Go 버전을 1.25로 업데이트합니다. **버그 수정**: debian 패키징 스크립트에 shebang 라인을 추가합니다. |
| 1.2.764.0 | 2025년 11월 19일 | **향상된 기능**: OpenDataChannel 요청에 서명하기 위한 지원이 추가되었습니다. **버그 수정**: 최신 Go 버전을 지원하도록 체크 스타일 문제를 수정합니다. |
| 1.2.707.0 | 2025년 2월 6일 | **기능 향상**: Dockerfile에서 Go 버전을 1.23으로 업그레이드했습니다. README에서 버전 구성 단계를 업데이트했습니다. |
| 1.2.694.0 | 2024년 11월 20일 | **버그 수정**: OpenDataChannel 요청에 자격 증명을 추가하는 변경 사항을 롤백했습니다. |
| 1.2.688.0 | 2024년 11월 6일 | **이 버전은 2024년 11월 20일에 사용 중지되었습니다.** **개선 사항**:[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/systems-manager/latest/userguide/plugin-version-history.html) |
| 1.2.677.0 | 2024년 10월 10일 | **개선 사항**: OpenDataChannel 요청과 함께 플러그인 버전을 전달하기 위한 지원이 추가되었습니다. |
| 1.2.650.0 | 2024년 7월 2일 | **향상된 기능**: aws-sdk-go를 1.54.10으로 업그레이드했습니다.**버그 수정**: gofmt 검사에 대한 코멘트의 형식을 수정했습니다. |
| 1.2.633.0 | 2024년 5월 30일 | 향상된 기능: Amazon Elastic Container Registry(Amazon ECR) 이미지를 사용하도록 Dockerfile이 업데이트되었습니다. |
| 1.2.553.0 | 2024년 1월 10일 | 향상된 기능: aws-sdk-go 및 종속 Golang 패키지가 업그레이드되었습니다. |
| 1.2.536.0 | 2023년 12월 4일 | 향상된 기능: [StartSession](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_StartSession.html) API 응답을 session-manager-plugin에 환경 변수로 전달하는 지원이 추가되었습니다. |
| 1.2.497.0 | 2023년 8월 1일 | 향상된 기능: Go SDK를 v1.44.302로 업그레이드했습니다. |
| 1.2.463.0 | 2023년 3월 15일 | 향상된 기능: macOS 번들 설치 관리자 및 서명된 설치 관리자에 Apple Mac(M1)에 대한 Mac with Apple silicon 지원이 추가되었습니다. |
| 1.2.398.0 | 2022년 10월 14일 | 개선 사항: golang 버전 1.17을 지원합니다. macOS의 기본 세션 관리자 플러그인 실행기가 python3을 사용하도록 업데이트합니다. SSMCLI에서 세션 관리자 플러그인으로 가져오기 경로를 업데이트합니다. |
| 1.2.339.0 | 2022년 6월 16일 | 버그 수정: 포트 세션의 유휴 세션 시간 초과를 수정했습니다. |
| 1.2.331.0 | 2022년 5월 27일 | 버그 수정: 시간 초과 전에 로컬 서버가 연결되지 않을 때 포트 세션이 조기에 닫히는 문제를 수정했습니다. |
| 1.2.323.0 | 2022년 5월 19일 | 버그 수정: 유휴 세션 시간 초과 기능을 사용하기 위해 smux 유지 기능을 비활성화합니다. |
| 1.2.312.0 | 2022년 3월 31일 | 기능 향상: 더 많은 출력 메시지 페이로드 유형을 지원합니다. |
| 1.2.295.0 | 2022년 1월 12일 | 버그 수정: 에이전트가 비활성화되고 start\$1publication 및 pause\$1publication 메시지에 대한 로그가 잘못되었을 때 클라이언트가 스트림 데이터를 재전송하여 세션이 중단되었습니다. |
| 1.2.279.0 | 2021년 10월 27일 | 향상된 기능: Windows 플랫폼용 Zip 패키징입니다. |
| 1.2.245.0 | 2021년 8월 19일 | 기능 향상: aws-sdk-go을(를) AWS IAM Identity Center을(를) 지원하는 최신 버전(v1.40.17)으로 업그레이드합니다. |
| 1.2.234.0 | 2021년 7월 26일 | 버그 수정: 대화형 세션 유형에서 세션이 갑자기 종료된 시나리오를 처리합니다. |
| 1.2.205.0 | 2021년 6월 10일 | 기능 향상: 서명된 macOS 설치 관리자에 대한 지원이 추가되었습니다. |
| 1.2.54.0 | 2021년 1월 29일 | 기능 향상: NonInteractiveCommands 실행 모드에서 세션 실행에 대한 지원이 추가되었습니다. |
| 1.2.30.0 | 2020년 11월 24일 | **기능 향상**: (포트 전달 세션만 해당) 전반적인 성능이 향상되었습니다. |
| 1.2.7.0 | 2020년 10월 15일 | **기능 향상**: (포트 전달 세션에만 해당) 대기 시간이 줄고 전반적인 성능이 향상되었습니다. |
| 1.1.61.0 | 2020년 4월 17일 | **기능 향상**: Linux 및 Ubuntu Server에 대한 ARM 지원이 추가되었습니다. |
| 1.1.54.0 | 2020년 1월 6일 | **버그 수정**: Session Manager 플러그인이 준비되지 않은 경우 패킷이 삭제되는 교착 상태 시나리오를 처리합니다. |
| 1.1.50.0 | 2019년 11월 19일 | **기능 향상**: 포트를 로컬 Unix 소켓에 전달하기 위한 지원이 추가되었습니다. |
| 1.1.35.0 | 2019년 11월 7일 | **기능 향상**: (포트 전달 세션에만 해당) 로컬 사용자가 SSM Agent을 누를 때 TerminateSession 명령을 `Ctrl+C`에 보냅니다. |
| 1.1.33.0 | 2019년 9월 26일 | 기능 향상: (포트 전달 세션만 해당) 클라이언트에서 TCP 연결이 해제되면 연결 해제 신호가 서버에 전송됩니다. |
| 1.1.31.0 | 2019년 9월 6일 | 기능 향상: 원격 서버가 연결을 종료할 때까지 포트 전달 세션을 열어 둘 수 있도록 업데이트되었습니다. |
| 1.1.26.0 | 2019년 7월 30일 | **기능 향상**: 세션 도중 데이터 전송 속도를 제한할 수 있도록 업데이트되었습니다. |
| 1.1.23.0 | 2019년 7월 9일 | **기능 향상**: Session Manager를 사용하여 SSH 세션을 실행할 수 있도록 지원이 추가되었습니다. |
| 1.1.17.0 | 2019년 4월 4일 | **기능 향상**: AWS Key Management Service(AWS KMS)를 사용하여 세션 데이터를 추가적으로 암호화할 수 있도록 지원이 추가되었습니다. |
| 1.0.37.0 | 2018년 9월 20일 | **향상된 기능**: Windows 버전의 버그를 수정했습니다. |
| 1.0.0.0 | 2018년 9월 11일 | Session Manager 플러그인의 최초 릴리스. |
# Windows에 Session Manager 플러그 인 설치
독립 실행형 설치 관리자를 사용하여 Windows Vista 이상에 Session Manager 플러그인을 설치할 수 있습니다.
업데이트가 릴리스되면 설치 프로세스를 반복하여 최신 버전의 Session Manager 플러그인을 가져와야 합니다.
**참고**
다음 정보를 참고하세요.
Session Manager 플러그인 설치 관리자가 플러그인을 설치하려면 관리자 권한이 필요합니다.
최상의 결과를 위해 Windows PowerShell 버전 5 이상을 사용하여 Windows에서 세션을 시작하는 것이 좋습니다. Windows 10의 Command 쉘을 사용할 수도 있습니다. Session Manager 플러그인에서는 PowerShell 및 Command 쉘만 지원됩니다. 서드 파티 명령줄 도구는 플러그인과 호환되지 않을 수 있습니다.
**EXE 설치 관리자를 사용하여 Session Manager 플러그인을 설치하려면**
1. 다음 URL을 사용하여 설치 관리자를 다운로드합니다.
```
https://s3.amazonaws.com/session-manager-downloads/plugin/latest/windows/SessionManagerPluginSetup.exe
```
또는 다음 URL을 사용하여 압축 버전의 설치 프로그램을 다운로드할 수 있습니다.
```
https://s3.amazonaws.com/session-manager-downloads/plugin/latest/windows/SessionManagerPlugin.zip
```
1. 다운로드한 설치 관리자를 실행하고 화면의 지침을 따릅니다. 압축된 버전의 설치 프로그램을 다운로드한 경우 먼저 설치 프로그램의 압축을 풀어야 합니다.
기본 디렉터리에 플러그인을 설치하려면 설치 위치 상자를 비워 둡니다.
+ `%PROGRAMFILES%\Amazon\SessionManagerPlugin\bin\`
1. 설치가 성공적인지 확인합니다. 자세한 내용은 [Session Manager 플러그인 설치 확인](install-plugin-verify.md) 섹션을 참조하세요.
**참고**
Windows에서 실행 파일을 찾을 수 없는 경우 명령 프롬프트를 다시 열거나 설치 디렉터리를 `PATH` 환경 변수에 수동으로 추가하는 것이 좋습니다. 자세한 내용은 문제 해결 주제 [명령줄 경로에 자동으로 추가되지 않는 Session Manager 플러그인(Windows)](session-manager-troubleshooting.md#windows-plugin-env-var-not-set) 섹션을 참조하세요.
# macOS에 Session Manager 플러그 인 설치
다음 주제 중 하나를 선택하여 macOS에 Session Manager 플러그인을 설치합니다.
**참고**
서명된 설치 프로그램은 서명된 `.pkg` 파일입니다. 번들 설치 프로그램은 `.zip` 파일을 사용합니다. 파일 압축을 풀고 나면 바이너리를 사용하여 플러그인을 설치할 수 있습니다.
## 서명된 설치 관리자로 macOS에 Session Manager 플러그인 설치
이 섹션에서는 서명된 설치 관리자를 사용하여 macOS에 Session Manager 플러그인을 설치하는 방법을 설명합니다.
**서명된 설치 관리자를 사용하여 Session Manager 플러그인을 설치하려면(macOS)**
1. 서명된 설치 관리자를 다운로드합니다.
------
#### [ x86\$164 ]
```
curl "https://s3.amazonaws.com/session-manager-downloads/plugin/latest/mac/session-manager-plugin.pkg" -o "session-manager-plugin.pkg"
```
------
#### [ Apple 실리콘 탑재 Mac ]
```
curl "https://s3.amazonaws.com/session-manager-downloads/plugin/latest/mac_arm64/session-manager-plugin.pkg" -o "session-manager-plugin.pkg"
```
------
1. 설치 명령을 실행합니다. 명령이 실패하는 경우 `/usr/local/bin` 폴더가 존재하는지 확인합니다. 존재하지 않으면 폴더를 생성하고 명령을 다시 실행합니다.
```
sudo installer -pkg session-manager-plugin.pkg -target /
sudo ln -s /usr/local/sessionmanagerplugin/bin/session-manager-plugin /usr/local/bin/session-manager-plugin
```
1. 설치가 성공적인지 확인합니다. 자세한 내용은 [Session Manager 플러그인 설치 확인](install-plugin-verify.md) 섹션을 참조하세요.
## macOS에 Session Manager 플러그 인 설치
이 섹션에서는 번들 설치 관리자를 사용하여 macOS에 Session Manager 플러그인을 설치하는 방법을 설명합니다.
**중요**
다음 중요 정보를 기록해 둡니다.
기본적으로 스크립트가 `/usr/local/sessionmanagerplugin` 시스템 디렉터리에 플러그인을 설치하기 때문에 설치 프로그램을 실행하려면 sudo 액세스 권한이 필요합니다. sudo를 사용하여 플러그인을 설치하지 않으려면 설치 프로그램 스크립트를 수동으로 업데이트하여 sudo 액세스가 필요하지 않은 디렉터리에 플러그인을 설치합니다.
번들 설치 관리자는 공백을 포함하는 경로에 설치하는 것을 지원하지 않습니다.
**번들 설치 관리자를 사용하여 Session Manager 플러그인을 설치하려면(macOS)**
1. 번들 설치 관리자를 다운로드합니다.
------
#### [ x86\$164 ]
```
curl "https://s3.amazonaws.com/session-manager-downloads/plugin/latest/mac/sessionmanager-bundle.zip" -o "sessionmanager-bundle.zip"
```
------
#### [ Apple 실리콘 탑재 Mac ]
```
curl "https://s3.amazonaws.com/session-manager-downloads/plugin/latest/mac_arm64/sessionmanager-bundle.zip" -o "sessionmanager-bundle.zip"
```
------
1. 패키지의 압축을 풉니다.
```
unzip sessionmanager-bundle.zip
```
1. 설치 명령을 실행합니다.
```
sudo ./sessionmanager-bundle/install -i /usr/local/sessionmanagerplugin -b /usr/local/bin/session-manager-plugin
```
**참고**
이 플러그인에는 Python 3.10 이상이 필요합니다. 기본적으로 설치 스크립트는 시스템 기본 버전의 Python에서 실행됩니다. 대체 버전의 Python을 설치하고 이를 사용하여 Session Manager 플러그인을 설치하려는 경우 Python 실행 파일에 대한 절대 경로로 해당 버전의 설치 스크립트를 실행합니다. 다음은 예입니다.
```
sudo /usr/local/bin/python3.11 sessionmanager-bundle/install -i /usr/local/sessionmanagerplugin -b /usr/local/bin/session-manager-plugin
```
설치 관리자는 `/usr/local/sessionmanagerplugin`에서 Session Manager 플러그인을 설치하고 `/usr/local/bin` 디렉터리에 symlink `session-manager-plugin`을 생성합니다. 이렇게 하면 사용자의 `$PATH` 변수에 설치 디렉터리를 지정할 필요가 없습니다.
`-i` 및 `-b` 옵션에 대한 설명을 보려면 `-h` 옵션을 사용합니다.
```
./sessionmanager-bundle/install -h
```
1. 설치가 성공적인지 확인합니다. 자세한 내용은 [Session Manager 플러그인 설치 확인](install-plugin-verify.md) 섹션을 참조하세요.
**참고**
플러그인을 제거하려면 다음 명령 2개를 표시된 순서로 실행합니다.
```
sudo rm -rf /usr/local/sessionmanagerplugin
```
```
sudo rm /usr/local/bin/session-manager-plugin
```
# Linux에 Session Manager 플러그인 설치
이 섹션에는 Session Manager 플러그인 설치 관리자 패키지의 서명을 확인하고 다음 Linux 배포판에 플러그인을 설치하는 방법에 대한 정보가 수록되어 있습니다.
+ Amazon Linux 2
+ AL2023
+ RHEL
+ Debian Server
+ Ubuntu Server
**Topics**
+ [Session Manager 플러그인의 서명을 확인합니다.](install-plugin-linux-verify-signature.md)
+ [Amazon Linux 2, Amazon Linux 2023 및 Red Hat Enterprise Linux 배포에 Session Manager 플러그인 설치](install-plugin-linux.md)
+ [Debian Server 및 Ubuntu Server에 Session Manager 플러그인 설치](install-plugin-debian-and-ubuntu.md)
# Session Manager 플러그인의 서명을 확인합니다.
Linux용 Session Manager 플러그인 RPM 및 Debian 설치 관리자 패키지는 암호화 서명됩니다. 퍼블릭 키를 사용하여 플러그인 바이너리 및 패키지가 원본이며 수정되지 않았는지 확인할 수 있습니다. 파일이 변경되거나 손상된 경우 확인에 실패합니다. GNU Privacy Guard(GPG) 도구를 사용하여 설치 관리자 패키지의 서명을 확인할 수 있습니다. 다음 정보는 Session Manager 플러그인 버전 1.2.707.0 이상에 적용됩니다.
다음 단계를 완료하여 Session Manager 플러그인 설치 관리자 패키지의 서명을 확인합니다.
**Topics**
+ [1단계: Session Manager 플러그인 설치 관리자 패키지 다운로드](#install-plugin-linux-verify-signature-installer-packages)
+ [2단계: 연결된 서명 파일 다운로드](#install-plugin-linux-verify-signature-packages)
+ [3단계: GPG 도구 설치](#install-plugin-linux-verify-signature-packages-gpg)
+ [4단계: Linux 서버에서 Session Manager 플러그인 설치 관리자 패키지 확인](#install-plugin-linux-verify-signature-packages)
## 1단계: Session Manager 플러그인 설치 관리자 패키지 다운로드
확인하려는 Session Manager 플러그인 설치 관리자 패키지를 다운로드합니다.
**Amazon Linux 2, AL2023 및 RHEL RPM 패키지**
------
#### [ x86\$164 ]
```
curl -o "session-manager-plugin.rpm" "https://s3.amazonaws.com/session-manager-downloads/plugin/latest/linux_64bit/session-manager-plugin.rpm"
```
------
#### [ ARM64 ]
```
curl -o "session-manager-plugin.rpm" "https://s3.amazonaws.com/session-manager-downloads/plugin/latest/linux_arm64/session-manager-plugin.rpm"
```
------
**Debian Server 및 Ubuntu Server Deb 패키지**
------
#### [ x86\$164 ]
```
curl -o "session-manager-plugin.deb" "https://s3.amazonaws.com/session-manager-downloads/plugin/latest/ubuntu_64bit/session-manager-plugin.deb"
```
------
#### [ ARM64 ]
```
curl -o "session-manager-plugin.deb" "https://s3.amazonaws.com/session-manager-downloads/plugin/latest/ubuntu_arm64/session-manager-plugin.deb"
```
------
## 2단계: 연결된 서명 파일 다운로드
설치 관리자 패키지를 다운로드한 후 패키지 확인을 위해 연결된 서명 파일을 다운로드합니다. 패키지 내에서 session-manager-plugin 바이너리 파일을 무단으로 복사하거나 사용하지 못하도록 추가적인 보호 계층을 제공하기 위해, AWS는 개별 바이너리 파일을 검증하는 데 사용할 수 있는 바이너리 서명도 제공합니다. 보안 요구 사항에 따라 이러한 바이너리 서명을 사용하도록 선택할 수 있습니다.
**Amazon Linux 2, AL2023 및 RHEL 서명 패키지**
------
#### [ x86\$164 ]
패키지:
```
curl -o "session-manager-plugin.rpm.sig" "https://s3.amazonaws.com/session-manager-downloads/plugin/latest/linux_64bit/session-manager-plugin.rpm.sig"
```
바이너리:
```
curl -o "session-manager-plugin.sig" "https://s3.amazonaws.com/session-manager-downloads/plugin/latest/linux_64bit/session-manager-plugin.sig"
```
------
#### [ ARM64 ]
패키지:
```
curl -o "session-manager-plugin.rpm.sig" "https://s3.amazonaws.com/session-manager-downloads/plugin/latest/linux_arm64/session-manager-plugin.rpm.sig"
```
바이너리:
```
curl -o "session-manager-plugin.sig" "https://s3.amazonaws.com/session-manager-downloads/plugin/latest/linux_arm64/session-manager-plugin.sig"
```
------
**Debian Server 및 Ubuntu Server Deb 서명 패키지**
------
#### [ x86\$164 ]
패키지:
```
curl -o "session-manager-plugin.deb.sig" "https://s3.amazonaws.com/session-manager-downloads/plugin/latest/ubuntu_64bit/session-manager-plugin.deb.sig"
```
바이너리:
```
curl -o "session-manager-plugin.sig" "https://s3.amazonaws.com/session-manager-downloads/plugin/latest/ubuntu_64bit/session-manager-plugin.sig"
```
------
#### [ ARM64 ]
패키지:
```
curl -o "session-manager-plugin.deb.sig" "https://s3.amazonaws.com/session-manager-downloads/plugin/latest/ubuntu_arm64/session-manager-plugin.deb.sig"
```
바이너리:
```
curl -o "session-manager-plugin.sig" "https://s3.amazonaws.com/session-manager-downloads/plugin/latest/ubuntu_arm64/session-manager-plugin.sig"
```
------
## 3단계: GPG 도구 설치
Session Manager 플러그인의 서명을 확인하려면 시스템에 GNU Privacy Guard(GPG) 도구가 설치되어 있어야 합니다. 이 확인 프로세스를 수행하려면 GPG 버전 2.1 이상이 필요합니다. GPG 버전은 다음 명령을 실행하여 확인할 수 있습니다.
```
gpg --version
```
GPG가 2.1 이전 버전인 경우, 확인 프로세스를 진행하기 전에 GPG를 업데이트합니다. 대부분의 시스템에서는 패키지 관리자를 사용하여 GPG 도구를 업데이트할 수 있습니다. 예를 들어 지원되는 Amazon Linux AMI 및 RHEL 버전에서는 다음 명령을 사용할 수 있습니다.
```
sudo yum update
sudo yum install gnupg2
```
지원되는 Ubuntu Server 및 Debian Server 시스템에서 다음 명령을 사용할 수 있습니다.
```
sudo apt-get update
sudo apt-get install gnupg2
```
확인 프로세스를 계속하기 전에 필요한 GPG 버전이 설치되어 있는지 확인합니다.
## 4단계: Linux 서버에서 Session Manager 플러그인 설치 관리자 패키지 확인
다음 절차에 따라 Linux 서버에서 Session Manager 플러그인 설치 관리자 패키지를 확인합니다.
**참고**
Amazon Linux 2는 GPG 도구 버전 2.1 이상을 지원하지 않습니다. Amazon Linux 2 인스턴스에서 다음 절차가 작동하지 않는 경우 Amazon Linux 2 인스턴스에 설치하기 전에 다른 플랫폼에서 서명을 확인합니다.
1. 다음 퍼블릭 키를 복사해 session-manager-plugin.gpg라는 파일에 저장합니다.
```
-----BEGIN PGP PUBLIC KEY BLOCK-----
mFIEZ5ERQxMIKoZIzj0DAQcCAwQjuZy+IjFoYg57sLTGhF3aZLBaGpzB+gY6j7Ix
P7NqbpXyjVj8a+dy79gSd64OEaMxUb7vw/jug+CfRXwVGRMNtIBBV1MgU1NNIFNl
c3Npb24gTWFuYWdlciA8c2Vzc2lvbi1tYW5hZ2VyLXBsdWdpbi1zaWduZXJAYW1h
em9uLmNvbT4gKEFXUyBTeXN0ZW1zIE1hbmFnZXIgU2Vzc2lvbiBNYW5hZ2VyIFBs
dWdpbiBMaW51eCBTaWduZXIgS2V5KYkBAAQQEwgAqAUCZ5ERQ4EcQVdTIFNTTSBT
ZXNzaW9uIE1hbmFnZXIgPHNlc3Npb24tbWFuYWdlci1wbHVnaW4tc2lnbmVyQGFt
YXpvbi5jb20+IChBV1MgU3lzdGVtcyBNYW5hZ2VyIFNlc3Npb24gTWFuYWdlciBQ
bHVnaW4gTGludXggU2lnbmVyIEtleSkWIQR5WWNxJM4JOtUB1HosTUr/b2dX7gIe
AwIbAwIVCAAKCRAsTUr/b2dX7rO1AQCa1kig3lQ78W/QHGU76uHx3XAyv0tfpE9U
oQBCIwFLSgEA3PDHt3lZ+s6m9JLGJsy+Cp5ZFzpiF6RgluR/2gA861M=
=2DQm
-----END PGP PUBLIC KEY BLOCK-----
```
1. 퍼블릭 키를 인증 키로 가져옵니다. 반환된 키 값은 `2C4D4AFF6F6757EE`여야 합니다.
```
$ gpg --import session-manager-plugin.gpg
gpg: key 2C4D4AFF6F6757EE: public key "AWS SSM Session Manager (AWS Systems Manager Session Manager Plugin Linux Signer Key)" imported
gpg: Total number processed: 1
gpg: imported: 1
```
1. 다음 명령을 실행하여 지문을 확인합니다.
```
gpg --fingerprint 2C4D4AFF6F6757EE
```
명령 출력의 지문은 다음과 일치해야 합니다.
```
7959 6371 24CE 093A D501 D47A 2C4D 4AFF 6F67 57EE
```
```
pub nistp256 2025-01-22 [SC]
7959 6371 24CE 093A D501 D47A 2C4D 4AFF 6F67 57EE
uid [ unknown] AWS SSM Session Manager (AWS Systems Manager Session Manager Plugin Linux Signer Key)
```
지문이 일치하지 않으면 플러그인을 설치하지 말고 AWS Support에 문의하세요.
1. 설치 관리자 패키지 서명을 확인합니다. 이 주제의 앞부분에 나열된 대로 서명 파일과 session-manager-plugin을 다운로드할 때 *signature-filename*과 *downloaded-plugin-filename*을 지정한 값으로 바꿉니다.
```
gpg --verify signature-filename downloaded-plugin-filename
```
예를 들어 Amazon Linux 2의 x86\$164 아키텍처에서 이 명령은 다음과 같습니다.
```
gpg --verify session-manager-plugin.rpm.sig session-manager-plugin.rpm
```
다음과 비슷한 출력이 반환됩니다.
```
gpg: Signature made Mon Feb 3 20:08:32 2025 UTC gpg: using ECDSA key 2C4D4AFF6F6757EE
gpg: Good signature from "AWS Systems Manager Session Manager (AWS Systems Manager Session Manager Plugin Linux Signer Key)" [unknown]
gpg: WARNING: This key is not certified with a trusted signature!
gpg: There is no indication that the signature belongs to the owner.
Primary key fingerprint: 7959 6371 24CE 093A D501 D47A 2C4D 4AFF 6F67 57EE
```
출력에 `BAD signature` 문구가 포함된 경우, 절차를 올바르게 수행했는지 확인합니다. 이 응답이 계속되면 AWS Support에 연락하고 패키지를 설치하지 않습니다. 신뢰에 대한 경고 메시지는 서명이 유효하지 않다는 의미가 아니라 퍼블릭 키를 확인하지 않았다는 의미입니다. 사용자 또는 사용자가 신뢰하는 사람이 서명한 키만 신뢰됩니다. 출력에 `Can't check signature: No public key`라는 문구가 포함된 경우 버전 1.2.707.0 이상의 Session Manager 플러그인을 다운로드했는지 확인합니다.
# Amazon Linux 2, Amazon Linux 2023 및 Red Hat Enterprise Linux 배포에 Session Manager 플러그인 설치
다음 절차에 따라 Amazon Linux 2, Amazon Linux 2023(AL2023) 및 RHEL 배포에 Session Manager 플러그인을 설치합니다.
1. Session Manager 플러그인 RPM 패키지를 다운로드하여 설치합니다.
------
#### [ x86\$164 ]
Amazon Linux 2 및 RHEL 7에서 다음 명령을 실행합니다.
```
sudo yum install -y https://s3.amazonaws.com/session-manager-downloads/plugin/latest/linux_64bit/session-manager-plugin.rpm
```
AL2023 및 RHEL 8 및 9에서 다음 명령을 실행합니다.
```
sudo dnf install -y https://s3.amazonaws.com/session-manager-downloads/plugin/latest/linux_64bit/session-manager-plugin.rpm
```
------
#### [ ARM64 ]
Amazon Linux 2 및 RHEL 7에서 다음 명령을 실행합니다.
```
sudo yum install -y https://s3.amazonaws.com/session-manager-downloads/plugin/latest/linux_arm64/session-manager-plugin.rpm
```
AL2023 및 RHEL 8 및 9에서 다음 명령을 실행합니다.
```
sudo dnf install -y https://s3.amazonaws.com/session-manager-downloads/plugin/latest/linux_arm64/session-manager-plugin.rpm
```
------
1. 설치가 성공적인지 확인합니다. 자세한 내용은 [Session Manager 플러그인 설치 확인](install-plugin-verify.md) 섹션을 참조하세요.
**참고**
플러그인을 제거하려는 경우 `sudo yum erase session-manager-plugin -y`를 실행합니다.
# Debian Server 및 Ubuntu Server에 Session Manager 플러그인 설치
1. Session Manager 플러그인 deb 패키지를 다운로드합니다.
------
#### [ x86\$164 ]
```
curl "https://s3.amazonaws.com/session-manager-downloads/plugin/latest/ubuntu_64bit/session-manager-plugin.deb" -o "session-manager-plugin.deb"
```
------
#### [ ARM64 ]
```
curl "https://s3.amazonaws.com/session-manager-downloads/plugin/latest/ubuntu_arm64/session-manager-plugin.deb" -o "session-manager-plugin.deb"
```
------
1. 설치 명령을 실행합니다.
```
sudo dpkg -i session-manager-plugin.deb
```
1. 설치가 성공적인지 확인합니다. 자세한 내용은 [Session Manager 플러그인 설치 확인](install-plugin-verify.md) 섹션을 참조하세요.
**참고**
플러그인을 제거하려는 경우 `sudo dpkg -r session-manager-plugin`를 실행합니다.
# Session Manager 플러그인 설치 확인
다음 명령을 실행하여 Session Manager 플러그인이 성공적으로 설치되었는지 확인합니다.
```
session-manager-plugin
```
설치에 성공하면 다음 메시지가 반환됩니다.
```
The Session Manager plugin is installed successfully. Use the AWS CLI to start a session.
```
[AWS Command Line Interface](https://aws.amazon.com/cli/)(AWS CLI)에서 [https://docs.aws.amazon.com/cli/latest/reference/ssm/start-session.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/start-session.html) 명령을 실행하여 설치를 테스트할 수도 있습니다. 다음 명령에서 *instance-id*를 자신의 정보로 바꿉니다.
```
aws ssm start-session --target instance-id
```
이 명령은 AWS CLI를 설치 및 구성했으며 Session Manager 관리자가 Session Manager를 사용하여 대상 관리형 노드에 액세스하는 데 필요한 IAM 권한을 부여한 경우에만 작동합니다.
# GitHub에서 Session Manager 플러그인 켜기
Session Manager 플러그인의 소스 코드는 [https://github.com/aws/session-manager-plugin](https://github.com/aws/session-manager-plugin)에 제공되므로 필요에 따라 플러그인을 조정할 수 있습니다. 포함하고 싶은 변경에 대해서는 [풀 요청](https://github.com/aws/session-manager-plugin/blob/mainline/CONTRIBUTING.md)을 제출하는 것이 좋습니다. 단, Amazon Web Services에서 이 소프트웨어의 수정된 사본 실행을 지원하지 않습니다.
# (옵션) Session Manager 플러그인 로깅 설정
Session Manager 플러그인에는 실행하는 세션에 대한 로깅을 허용하는 옵션이 있습니다. 기본적으로 로깅은 해제되어 있습니다.
로깅을 허용하면 Session Manager 플러그인에서는 로컬 시스템에서 발생한 애플리케이션 활동(`session-manager-plugin.log`) 및 오류(`errors.log`)에 대한 로그 파일이 생성됩니다.
**Topics**
+ [Session Manager 플러그인에 대한 로깅 켜기(Windows)](#configure-logs-windows)
+ [Session Manager 플러그인에 대한 로깅 활성화(Linux 및 macOS)](#configure-logs-linux)
## Session Manager 플러그인에 대한 로깅 켜기(Windows)
1. 플러그인에 대한 `seelog.xml.template` 파일을 찾습니다.
기본 위치는 `C:\Program Files\Amazon\SessionManagerPlugin\seelog.xml.template`입니다.
1. 이 파일의 이름을 `seelog.xml`로 변경합니다.
1. 파일을 열고 `minlevel="off"`를 `minlevel="info"` 또는 `minlevel="debug"`로 변경합니다.
**참고**
기본적으로 데이터 채널 열기 및 세션 다시 연결에 대한 항목은 **INFO** 수준에서 기록됩니다. 데이터 흐림(패킷 및 승인) 항목은 **DEBUG** 수준에서 기록됩니다.
1. 수정하려는 다른 구성 옵션을 변경합니다. 변경 가능한 옵션은 다음과 같습니다.
+ **디버그 수준**: 디버그 수준은 `formatid="fmtinfo"`에서 `formatid="fmtdebug"`로 변경할 수 있습니다.
+ **로그 파일 옵션**: 로그 파일 이름을 제외하고 로그가 저장되는 위치를 포함해 로그 파일 옵션을 변경할 수 있습니다.
**중요**
파일 이름을 변경하지 않습니다. 그렇지 않으면 로깅이 제대로 작동하지 않습니다.
```
```
1. 파일을 저장합니다.
## Session Manager 플러그인에 대한 로깅 활성화(Linux 및 macOS)
1. 플러그인에 대한 `seelog.xml.template` 파일을 찾습니다.
기본 위치는 `/usr/local/sessionmanagerplugin/seelog.xml.template`입니다.
1. 이 파일의 이름을 `seelog.xml`로 변경합니다.
1. 파일을 열고 `minlevel="off"`를 `minlevel="info"` 또는 `minlevel="debug"`로 변경합니다.
**참고**
기본적으로 데이터 채널 열기 및 세션 다시 연결에 대한 로그 항목은 **INFO** 수준에 기록됩니다. 데이터 흐림(패킷 및 승인) 항목은 **DEBUG** 수준에서 기록됩니다.
1. 수정하려는 다른 구성 옵션을 변경합니다. 변경 가능한 옵션은 다음과 같습니다.
+ **디버그 수준**: 디버그 수준은 `formatid="fmtinfo"`에서 `outputs formatid="fmtdebug"`로 변경할 수 있습니다.
+ **로그 파일 옵션**: 로그 파일 이름을 제외하고 로그가 저장되는 위치를 포함해 로그 파일 옵션을 변경할 수 있습니다.
**중요**
파일 이름을 변경하지 않습니다. 그렇지 않으면 로깅이 제대로 작동하지 않습니다.
```
```
**중요**
로그를 저장하는 데 지정된 기본 디렉터리를 사용하는 경우 **sudo**를 사용하여 세션 명령을 실행하거나 플러그인이 설치된 디렉터리에 전체 읽기 및 쓰기 권한을 부여해야 합니다. 이러한 제한 사항을 우회하려면 로그가 저장되는 위치를 바꿉니다.
1. 파일을 저장합니다.
# 세션 시작
AWS Systems Manager콘솔, Amazon Elastic Compute Cloud(Amazon EC2) 콘솔, AWS Command Line Interface(AWS CLI) 또는 SSH를 사용하여 세션을 시작할 수 있습니다.
**Topics**
+ [세션 시작(Systems Manager 콘솔)](#start-sys-console)
+ [세션 시작(Amazon EC2 콘솔)](#start-ec2-console)
+ [세션 시작(AWS CLI)](#sessions-start-cli)
+ [세션 시작(SSH)](#sessions-start-ssh)
+ [세션 시작(포트 전달)](#sessions-start-port-forwarding)
+ [세션 시작(원격 호스트로 포트 전달)](#sessions-remote-port-forwarding)
+ [세션 시작(대화형 및 비대화형 명령)](#sessions-start-interactive-commands)
## 세션 시작(Systems Manager 콘솔)
AWS Systems Manager 콘솔을 사용하여 계정의 관리형 노드와 관련된 세션을 시작할 수 있습니다.
**참고**
세션을 시작하기 전에 Session Manager에 대한 설정 단계를 완료했는지 확인합니다. 자세한 내용은 [Session Manager 설정](session-manager-getting-started.md) 섹션을 참조하세요.
**세션 시작(Systems Manager 콘솔)**
1. [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)에서 AWS Systems Manager 콘솔을 엽니다.
1. 탐색 창에서 **Session Manager**를 선택합니다.
1. **세션 시작**을 선택합니다.
1. (선택 사항) **세션 이유** 필드에 세션 설명을 입력합니다.
1. **대상 인스턴스**의 경우, 연결하려는 관리형 노드 왼쪽에 있는 옵션 버튼을 선택합니다.
원하는 노드가 목록에 없거나 노드를 선택했는데 구성 오류가 표시되는 경우 [관리형 노드를 사용할 수 없거나 Session Manager에 대해 구성되지 않음](session-manager-troubleshooting.md#session-manager-troubleshooting-instances)에서 문제 해결 단계를 참조하세요.
1. 세션을 즉시 시작하려면 **세션 시작**을 선택합니다.
-또는-
세션 옵션을 보려면 **다음**을 선택합니다.
1. (선택 사항) **세션 문서의** 경우 세션이 시작될 때 실행하려는 문서를 선택합니다. 문서에서 런타임 파라미터를 지원하는 경우 각 파라미터 필드에 쉼표로 구분된 값을 하나 이상 입력할 수 있습니다.
1. **다음**을 선택합니다.
1. **세션 시작**을 선택합니다.
연결된 후 다른 연결 유형을 사용할 때 bash 명령(Linux 및 macOS) 또는 PowerShell 명령(Windows)을 실행할 수 있습니다.
**중요**
Session Manager 콘솔에서 세션을 시작할 때 사용자가 문서를 지정할 수 있도록 하려면 다음을 참고하세요.
사용자에게 해당 IAM 정책의 `ssm:GetDocument` 및 `ssm:ListDocuments` 권한을 부여해야 합니다. 자세한 내용은 [콘솔의 사용자 지정 세션 문서 액세스 권한 부여](getting-started-restrict-access-examples.md#grant-access-documents-console-example) 섹션을 참조하세요.
콘솔에서는 `Standard_Stream`으로 정의된 `sessionType`이 있는 세션 문서만 지원합니다. 자세한 내용은 [Session 문서 스키마](session-manager-schema.md) 섹션을 참조하세요.
## 세션 시작(Amazon EC2 콘솔)
Amazon Elastic Compute Cloud(Amazon EC2) 콘솔을 사용하여 계정의 인스턴스로 세션을 시작할 수 있습니다.
**참고**
하나 이상의 Systems Manager 작업(`ssm:command-name`)을 수행할 권한이 없다는 오류가 수신되면 관리자에게 문의하여 도움을 받아야 합니다. 관리자는 로그인 보안 인증 정보를 제공한 사람입니다. Amazon EC2 콘솔에서 세션을 시작할 수 있도록 정책을 업데이트할 것을 관리자에게 요청합니다. 관리자인 경우 [Session Manager에 대한 샘플 IAM 정책](getting-started-restrict-access-quickstart.md) 섹션에서 자세한 내용을 참조하세요.
**세션을 시작하려면(Amazon EC2 콘솔)**
1. [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/)에서 Amazon EC2 콘솔을 엽니다.
1. 탐색 창에서 **인스턴스**를 선택합니다.
1. 인스턴스를 선택한 다음 **연결**을 선택합니다.
1. **연결 방법**에서 **Session Manager**를 선택합니다.
1. **연결**을 선택합니다.
연결된 후 다른 연결 유형을 사용할 때 bash 명령(Linux 및 macOS) 또는 PowerShell 명령(Windows)을 실행할 수 있습니다.
## 세션 시작(AWS CLI)
아직 하지 않은 경우 AWS Command Line Interface(AWS CLI)을 설치하고 구성합니다.
자세한 내용은 [최신 버전의 AWS CLI 설치 또는 업데이트](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html)를 참조하세요.
세션을 시작하기 전에 Session Manager에 대한 설정 단계를 완료했는지 확인합니다. 자세한 내용은 [Session Manager 설정](session-manager-getting-started.md) 섹션을 참조하세요.
AWS CLI를 사용하여 세션 명령을 실행하려면 Session Manager 플러그인도 로컬 시스템에 설치해야 합니다. 자세한 내용은 [AWS CLI의 Session Manager 플러그인 설치](session-manager-working-with-install-plugin.md) 섹션을 참조하세요.
AWS CLI를 사용하여 세션을 시작하려면 다음 명령을 실행하여 *instance-id*를 자신의 정보로 바꿉니다.
```
aws ssm start-session \
--target instance-id
```
**start-session** 명령과 함께 사용할 수 있는 다른 옵션에 대한 자세한 내용은 AWS CLI 명령 레퍼런스의 AWS Systems Manager 섹션에 있는 [https://docs.aws.amazon.com/cli/latest/reference/ssm/start-session.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/start-session.html)을 참조하세요.
## 세션 시작(SSH)
Session Manager SSH 세션을 시작하려면 관리형 노드에 SSM Agent 버전 2.3.672.0 이상이 설치되어 있어야 합니다.
**SSH 연결 요구 사항**
Session Manager를 통한 SSH를 사용하는 세션 연결에서는 다음과 같은 요구 사항 및 제한 사항에 유의합니다.
+ SSH 연결을 지원하도록 대상 관리형 노드를 구성해야 합니다. 자세한 내용은 [(선택 사항) Session Manager를 통한 SSH 연결에 대한 권한 허용 및 제어](session-manager-getting-started-enable-ssh-connections.md)를 참조하세요.
+ 다른 유형의 세션 연결에 사용되는 `ssm-user` 계정이 아닌 PEM(Privacy Enhanced Mail) 인증서와 연결된 관리형 노드 계정을 사용해서 연결해야 합니다. 예를 들면, Linux 및 macOS용 EC2 인스턴스의 기본 사용자는 `ec2-user`입니다. 각 인스턴스 유형의 기본 사용자를 식별하는 것에 대한 자세한 내용은 *Amazon EC2 사용 설명서*의 [인스턴스에 대한 정보 가져오기](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/connection-prereqs.html#connection-prereqs-get-info-about-instance)를 참조하세요.
+ 포트 전달 또는 SSH를 통해 연결하는 Session Manager 세션에는 로깅을 사용할 수 없습니다. 이는 SSH가 AWS CLI 엔드포인트와 Session Manager 엔드포인트 간에 설정된 보안 TLS 연결 내의 모든 세션 데이터를 암호화하고 Session Manager는 SSH 연결을 위한 터널 역할만 하기 때문입니다.
**참고**
세션을 시작하기 전에 Session Manager에 대한 설정 단계를 완료했는지 확인합니다. 자세한 내용은 [Session Manager 설정](session-manager-getting-started.md) 섹션을 참조하세요.
SSH를 사용하여 세션을 시작하려면 다음 명령을 실행합니다. 각 *example resource placeholder*를 사용자의 정보로 바꿉니다.
```
ssh -i /path/my-key-pair.pem username@instance-id
```
**작은 정보**
SSH를 사용해 세션을 시작할 때는 다음 명령 형식을 사용해 로컬 파일을 대상 관리형 노드에 복사할 수 있습니다.
```
scp -i /path/my-key-pair.pem /path/ExampleFile.txt username@instance-id:~
```
**start-session** 명령과 함께 사용할 수 있는 다른 옵션에 대한 자세한 내용은 AWS CLI 명령 레퍼런스의 AWS Systems Manager 섹션에 있는 [https://docs.aws.amazon.com/cli/latest/reference/ssm/start-session.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/start-session.html)를 참조하세요.
## 세션 시작(포트 전달)
Session Manager 포트 전달 세션을 시작하려면 관리형 노드에 SSM Agent 버전 2.3.672.0 이상이 설치되어 있어야 합니다.
**참고**
세션을 시작하기 전에 Session Manager에 대한 설정 단계를 완료했는지 확인합니다. 자세한 내용은 [Session Manager 설정](session-manager-getting-started.md) 섹션을 참조하세요.
AWS CLI를 사용하여 세션 명령을 실행하려면 Session Manager 플러그인을 로컬 시스템에 설치해야 합니다. 자세한 내용은 [AWS CLI의 Session Manager 플러그인 설치](session-manager-working-with-install-plugin.md) 섹션을 참조하세요.
운영 체제 및 명령줄 도구에 따라 따옴표의 배치가 다를 수 있으며 이스케이프 문자가 필요할 수 있습니다.
포트 전달 세션을 시작하려면 CLI에서 다음 명령을 실행합니다. 각 *example resource placeholder*를 사용자의 정보로 바꿉니다.
------
#### [ Linux & macOS ]
```
aws ssm start-session \
--target instance-id \
--document-name AWS-StartPortForwardingSession \
--parameters '{"portNumber":["80"], "localPortNumber":["56789"]}'
```
------
#### [ Windows ]
```
aws ssm start-session ^
--target instance-id ^
--document-name AWS-StartPortForwardingSession ^
--parameters portNumber="3389",localPortNumber="56789"
```
------
`portNumber`는 세션 트래픽을 리디렉션하려는 관리형 노드의 원격 포트입니다. 예를 들면, RDP(원격 데스크톱 프로토콜)를 사용하여 Windows 노드 연결에 `3389` 포트를 지정할 수도 있습니다. `portNumber` 파라미터를 지정하지 않으면 Session Manager에서는 `80`을 기본값으로 사용합니다.
`localPortNumber`는 트래픽이 시작되는 로컬 컴퓨터의 포트입니다(예: `56789`). 이 값은 클라이언트를 사용하여 관리형 노드에 연결할 때 입력하는 값입니다. 예를 들어 **localhost:56789**입니다.
**start-session** 명령과 함께 사용할 수 있는 다른 옵션에 대한 자세한 내용은 AWS CLI 명령 레퍼런스의 AWS Systems Manager 섹션에 있는 [https://docs.aws.amazon.com/cli/latest/reference/ssm/start-session.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/start-session.html)을 참조하세요.
포트 전달 세션에 대한 자세한 내용은 *AWS News Blog*의 [Port Forwarding Using AWS Systems ManagerSession Manager](https://aws.amazon.com/blogs/aws/new-port-forwarding-using-aws-system-manager-sessions-manager/)를 참조하세요.
## 세션 시작(원격 호스트로 포트 전달)
원격 호스트로의 Session Manager 포트 전달 세션을 시작하려면 관리형 노드에 SSM Agent 버전 3.1.1374.0 이상이 설치되어 있어야 합니다. 원격 호스트는 Systems Manager에서 관리할 필요가 없습니다.
**참고**
세션을 시작하기 전에 Session Manager에 대한 설정 단계를 완료했는지 확인합니다. 자세한 내용은 [Session Manager 설정](session-manager-getting-started.md) 섹션을 참조하세요.
AWS CLI를 사용하여 세션 명령을 실행하려면 Session Manager 플러그인을 로컬 시스템에 설치해야 합니다. 자세한 내용은 [AWS CLI의 Session Manager 플러그인 설치](session-manager-working-with-install-plugin.md) 섹션을 참조하세요.
운영 체제 및 명령줄 도구에 따라 따옴표의 배치가 다를 수 있으며 이스케이프 문자가 필요할 수 있습니다.
포트 전달 세션을 시작하려면 AWS CLI에서 다음 명령을 실행합니다. 각 *example resource placeholder*를 사용자의 정보로 바꿉니다.
------
#### [ Linux & macOS ]
```
aws ssm start-session \
--target instance-id \
--document-name AWS-StartPortForwardingSessionToRemoteHost \
--parameters '{"host":["mydb.example.us-east-2.rds.amazonaws.com"],"portNumber":["3306"], "localPortNumber":["3306"]}'
```
------
#### [ Windows ]
```
aws ssm start-session ^
--target instance-id ^
--document-name AWS-StartPortForwardingSessionToRemoteHost ^
--parameters host="mydb.example.us-east-2.rds.amazonaws.com",portNumber="3306",localPortNumber="3306"
```
------
`host` 값은 연결하려는 원격 호스트의 호스트 이름 또는 IP 주소를 나타냅니다. 관리형 노드와 원격 호스트 간의 일반적인 연결 및 이름 확인 요구 사항은 여전히 적용됩니다.
`portNumber`는 세션 트래픽을 리디렉션하려는 관리형 노드의 원격 포트입니다. 예를 들면, RDP(원격 데스크톱 프로토콜)를 사용하여 Windows 노드 연결에 `3389` 포트를 지정할 수도 있습니다. `portNumber` 파라미터를 지정하지 않으면 Session Manager에서는 `80`을 기본값으로 사용합니다.
`localPortNumber`는 트래픽이 시작되는 로컬 컴퓨터의 포트입니다(예: `56789`). 이 값은 클라이언트를 사용하여 관리형 노드에 연결할 때 입력하는 값입니다. 예를 들어 **localhost:56789**입니다.
**start-session** 명령과 함께 사용할 수 있는 다른 옵션에 대한 자세한 내용은 AWS CLI 명령 레퍼런스의 AWS Systems Manager 섹션에 있는 [https://docs.aws.amazon.com/cli/latest/reference/ssm/start-session.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/start-session.html)를 참조하세요.
### Amazon ECS 작업을 사용하여 세션 시작
Session Manager는 Amazon Elastic Container Service(Amazon ECS) 클러스터 내의 작업을 사용하여 포트 전달 세션을 시작하는 것을 지원합니다. 이렇게 하려면 ECS Exec을 활성화합니다. 자세한 내용은 *Amazon Elastic Container Service 개발자 안내서*의 [ECS Exec를 사용하여 Amazon Elastic Container Service 컨테이너 모니터링](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-exec.html)을 참조하세요.
다음 권한을 포함하도록 IAM에서 태스크 역할도 업데이트해야 합니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ssmmessages:CreateControlChannel",
"ssmmessages:CreateDataChannel",
"ssmmessages:OpenControlChannel",
"ssmmessages:OpenDataChannel"
],
"Resource": "*"
}
]
}
```
------
Amazon ECS 작업을 사용하여 포트 전달 세션을 시작하려면 AWS CLI에서 다음 명령을 실행합니다. 각 *example resource placeholder*를 사용자의 정보로 바꿉니다.
**참고**
`target` 파라미터에서 < and > 기호를 제거합니다. 이러한 기호는 독자의 설명을 위한 용도로만 제공됩니다.
------
#### [ Linux & macOS ]
```
aws ssm start-session \
--target ecs:__ \
--document-name AWS-StartPortForwardingSessionToRemoteHost \
--parameters '{"host":["URL"],"portNumber":["port_number"], "localPortNumber":["port_number"]}'
```
------
#### [ Windows ]
```
aws ssm start-session ^
--target ecs:__ ^
--document-name AWS-StartPortForwardingSessionToRemoteHost ^
--parameters host="URL",portNumber="port_number",localPortNumber="port_number"
```
------
## 세션 시작(대화형 및 비대화형 명령)
세션을 시작하기 전에 Session Manager에 대한 설정 단계를 완료했는지 확인합니다. 자세한 내용은 [Session Manager 설정](session-manager-getting-started.md) 섹션을 참조하세요.
AWS CLI를 사용하여 세션 명령을 실행하려면 Session Manager 플러그인도 로컬 시스템에 설치해야 합니다. 자세한 내용은 [AWS CLI의 Session Manager 플러그인 설치](session-manager-working-with-install-plugin.md) 섹션을 참조하세요.
대화형 명령 세션을 시작하려면 다음 명령을 실행합니다. 각 *example resource placeholder*를 사용자의 정보로 바꿉니다.
------
#### [ Linux & macOS ]
```
aws ssm start-session \
--target instance-id \
--document-name CustomCommandSessionDocument \
--parameters '{"logpath":["/var/log/amazon/ssm/amazon-ssm-agent.log"]}'
```
------
#### [ Windows ]
```
aws ssm start-session ^
--target instance-id ^
--document-name CustomCommandSessionDocument ^
--parameters logpath="/var/log/amazon/ssm/amazon-ssm-agent.log"
```
------
**start-session** 명령과 함께 사용할 수 있는 다른 옵션에 대한 자세한 내용은 AWS CLI 명령 레퍼런스의 AWS Systems Manager 섹션에 있는 [https://docs.aws.amazon.com/cli/latest/reference/ssm/start-session.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/start-session.html)를 참조하세요.
**추가 정보**
+ [AWS Systems ManagerSession Manager에서 포트 전달을 사용하여 원격 호스트에 연결](https://aws.amazon.com/blogs/mt/use-port-forwarding-in-aws-systems-manager-session-manager-to-connect-to-remote-hosts/)
+ [AWS Systems Manager을 사용한 Amazon EC2 인스턴스 포트 전달](https://aws.amazon.com/blogs/mt/amazon-ec2-instance-port-forwarding-with-aws-systems-manager/)
+ [Session Manager 포트 전달을 사용하여 AWS Managed Microsoft AD 리소스 관리](https://aws.amazon.com/blogs/mt/manage-aws-managed-microsoft-ad-resources-with-session-manager-port-forwarding/)
+ *AWS News Blog*의 [Port Forwarding Using AWS Systems ManagerSession Manager](https://aws.amazon.com/blogs/aws/new-port-forwarding-using-aws-system-manager-sessions-manager/).
# 세션 종료
AWS Systems Manager 콘솔 또는 AWS Command Line Interface(AWS CLI)을 사용하여 계정에서 시작한 세션을 종료할 수 있습니다. 콘솔에서 세션에 대한 **종료** 버튼을 선택하거나 AWS CLI를 사용하여 [TerminateSession](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_TerminateSession.html) API 작업을 직접 호출하면 Session Manager에서 세션을 영구적으로 종료하고 관리형 노드에서 Session Manager 클라이언트 및 SSM Agent 간 데이터 연결을 닫습니다. 종료된 세션은 재개할 수 없습니다.
20분 동안 열린 세션에 사용자 활동이 없는 경우 유휴 상태가 제한 시간을 트리거합니다. Session Manager에서는 `TerminateSession`을 직접 호출하지 않지만 기본 채널을 닫습니다. 유휴 제한 시간으로 인해 종료된 세션을 재개할 수 없습니다.
AWS CLI를 사용할 때는 `terminate-session` 명령을 사용하거나 콘솔을 사용할 때는 **종료** 버튼을 사용하여 항상 세션을 명시적으로 종료하는 것이 좋습니다. (**종료** 버튼은 세션 창과 기본 Session Manager 콘솔 페이지 모두에 있습니다.) 브라우저 또는 명령 창만 닫으면 세션이 30일 동안 콘솔에 **활성**으로 표시됩니다. 세션을 명시적으로 종료하지 않거나 세션 시간이 초과되면 해당 시점에 관리형 노드에서 실행 중인 모든 프로세스가 계속 실행됩니다.
**Topics**
+ [세션 종료(콘솔)](#stop-sys-console)
+ [세션 종료(AWS CLI)](#stop-cli)
## 세션 종료(콘솔)
AWS Systems Manager 콘솔을 사용하여 계정의 세션을 종료할 수 있습니다.
**세션을 종료하려면(콘솔)**
1. AWS Systems Manager 콘솔([https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/))을 엽니다.
1. 탐색 창에서 **Session Manager**를 선택합니다.
1. **세션**에서 종료할 세션 왼쪽에 있는 옵션 버튼을 선택합니다.
1. **종료**를 선택합니다.
## 세션 종료(AWS CLI)
AWS CLI를 사용하여 세션을 종료하려면 다음 명령을 실행합니다. *session-id*를 자신의 정보로 바꿉니다.
```
aws ssm terminate-session \
--session-id session-id
```
**terminate-session** 명령에 대한 자세한 내용은 AWS CLI 명령 레퍼런스 AWS Systems Manager 섹션의 [https://docs.aws.amazon.com/cli/latest/reference/ssm/terminate-session.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/terminate-session.html)을 참조하세요.
# 세션 기록 보기
AWS Systems Manager 콘솔이나 AWS Command Line Interface(AWS CLI)를 사용하여 계정의 세션에 대한 정보를 볼 수 있습니다. 콘솔에서 다음과 같은 세션 세부 정보를 확인할 수 있습니다.
+ 세션 ID
+ 세션을 통해 관리형 노드에 연결된 사용자
+ 관리형 노드의 ID
+ 세션이 시작 및 종료된 시점
+ 세션의 상태
+ (설정된 경우) 세션 로그를 저장하도록 지정된 위치
AWS CLI를 사용하여 계정의 세션 목록을 볼 수 있지만 콘솔에서 사용할 수 있는 추가 세부 정보를 확인할 수 없습니다.
세션 기록 정보 로깅에 대한 자세한 내용은 [세션 로깅 활성화 및 비활성화](session-manager-logging.md) 섹션을 참조하세요.
**Topics**
+ [세션 기록 보기(콘솔)](#view-console)
+ [세션 기록 보기(AWS CLI)](#view-history-cli)
## 세션 기록 보기(콘솔)
AWS Systems Manager 콘솔을 사용하여 계정의 세션에 대한 세부 정보를 볼 수 있습니다.
**세션 기록을 보려면(콘솔)**
1. [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)에서 AWS Systems Manager 콘솔을 엽니다.
1. 탐색 창에서 **Session Manager**를 선택합니다.
1. **세션 기록** 탭을 선택합니다.
-또는-
Session Manager 홈 페이지가 먼저 열리면 **기본 설정 구성**, **세션 기록** 탭을 차례로 선택합니다.
## 세션 기록 보기(AWS CLI)
AWS CLI를 사용하여 계정의 세션 목록을 보려면 다음 명령을 실행합니다.
```
aws ssm describe-sessions \
--state History
```
**참고**
이 명령은 Session Manager를 사용하여 시작된 대상에 대한 연결 결과만 반환합니다. RDP(Remote Desktop Protocol) 또는 SSH(Secure Shell Protocol)와 같은 다른 수단을 통해 이루어진 연결은 나열되지 않습니다.
**describe-sessions** 명령과 함께 사용할 수 있는 다른 옵션에 대한 자세한 내용은 AWS CLI 명령 레퍼런스의 AWS Systems Manager 섹션에 있는 [https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-sessions.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-sessions.html)를 참조하세요.
# 세션 활동 로그
Session Manager는 Systems Manager 콘솔에서 현재 세션과 완료된 세션에 대한 정보를 제공하는 것 외에 AWS CloudTrail을 사용하는 AWS 계정의 세션 활동을 로깅하는 기능을 제공합니다.
CloudTrail에서는 Systems Manager 콘솔, AWS Command Line Interface(AWS CLI) 및 Systems Manager SDK를 통해 API 호출을 캡처합니다. CloudTrail 콘솔에서 정보를 보고 지정된 Amazon Simple Storage Service(Amazon S3) 버킷에 저장할 수 있습니다. 계정에 대한 모든 CloudTrail 로그를 저장하는 데 Amazon S3 버킷 하나가 사용됩니다. 자세한 내용은 [AWS CloudTrail를 사용하여 AWS Systems Manager API 호출 로깅](monitoring-cloudtrail-logs.md) 섹션을 참조하세요.
**참고**
로그 파일의 반복 분석, 기록 분석 및 이론적 분석을 위해 [CloudTrail Lake](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-lake.html) 또는 유지 관리하는 테이블을 사용하여 CloudTrail 로그를 쿼리하는 방법을 고려합니다. 자세한 내용은 **AWS CloudTrail 사용 설명서의 [AWS CloudTrail 로그 쿼리](https://docs.aws.amazon.com/athena/latest/ug/cloudtrail-logs.html)를 참조하세요.
## Amazon EventBridge를 사용하여 세션 활동 모니터링(콘솔)
EventBridge를 사용하면 AWS 리소스 변경 시 이를 감지하기 위한 규칙을 설정할 수 있습니다. 조직 내 사용자가 세션을 시작 또는 종료하면 이를 감지하는 규칙을 생성하면 예를 들어 Amazon SNS를 통해 해당 이벤트에 대한 알림을 받을 수 있습니다.
Session Manager에 대한 EventBridge 지원은 CloudTrail에서 기록한 API 작업 기록에 의존합니다. CloudTrail과 EventBridge 통합을 사용하여 대부분의 AWS Systems Manager 이벤트에 응답할 수 있습니다. API 호출을 수행하지 않는 `exit` 명령과 같이 세션 내에서 발생하는 작업은 EventBridge에서 감지되지 않습니다.
다음 단계에서는 **StartSession**과 같은 Session Manager API 이벤트가 발생할 때 Amazon Simple Notification Service(Amazon SNS)를 통해 알림을 시작하는 방법을 간략하게 설명합니다.
**Amazon EventBridge를 사용하여 세션 활동을 모니터링하려면(콘솔)**
1. 추적하려는 Session Manager 이벤트 발생 시 알림을 보내는 데 사용할 Amazon SNS 주제를 생성합니다.
자세한 내용은 *Amazon Simple Notification Service Developer Guide*의 [Create a Topic](https://docs.aws.amazon.com/sns/latest/dg/CreateTopic.html)을 참조하세요.
1. 추적하려는 Session Manager 이벤트 유형의 Amazon SNS 대상을 호출할 EventBridge 규칙을 생성합니다.
규칙을 생성하는 방법에 대한 자세한 내용은 *Amazon EventBridge 사용 설명서*의 [이벤트에 대응하는 Amazon EventBridge 규칙 생성](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-create-rule.html)을 참조하세요.
규칙 생성 단계를 수행할 때 다음과 같이 선택하십시오.
+ **AWS service**(서비스)에서 **Systems Manager**를 선택합니다.
+ **Event Type**(이벤트 유형)에서 **AWS API Call through CloudTrail**(CloudTrail을 통한 API 호출)을 선택합니다.
+ **특정 작업**을 선택한 후 알림을 받고 싶은 Session Manager 명령을 한 번에 하나씩 입력합니다. **StartSession**, **ResumeSession** 및 **TerminateSession**을 선택할 수 있습니다. (EventBridge는`Get*`, ` List*` 및 `Describe*` 명령을 지원하지 않습니다.)
+ **대상 선택**에서 **SNS 주제**를 선택합니다. [**주제(Topic)**]에서 1단계에서 생성한 Amazon SNS 주제의 이름을 선택합니다.
자세한 내용은 *[Amazon EventBridge User Guide](https://docs.aws.amazon.com/eventbridge/latest/userguide/)* 및 *[Amazon Simple Notification Service Getting Started Guide](https://docs.aws.amazon.com/sns/latest/gsg/)*를 참조하세요.
# 세션 로깅 활성화 및 비활성화
세션 로깅은 Systems Manager 콘솔의 현재 세션과 완료된 세션에 대한 정보를 기록합니다. AWS 계정의 세션 중에 실행된 명령에 대한 세부 정보도 기록할 수 있습니다. 세션 로깅을 사용하여 다음을 수행할 수 있습니다.
+ 보관을 위해 세션 로그를 생성해 저장합니다.
+ 지난 30일 동안 Session Manager를 사용해 관리형 노드에 설정한 모든 연결에 대한 세부 정보를 보여주는 보고서를 생성합니다.
+ Amazon Simple Notification Service(SNS) 알림과 같이 AWS 계정의 세션 로깅에 대한 알림을 생성합니다.
+ 세션 중 수행된 작업의 결과로 AWS 리소스에 대한 다른 작업을 자동으로 시작합니다(AWS Lambda 기능 실행, AWS CodePipeline 파이프라인 시작 또는 AWS Systems Manager Run Command 문서 실행 등).
**중요**
Session Manager에 대한 다음 요구 사항 및 제한 사항에 유의하세요.
Session Manager는 세션 기본 설정에 따라 세션 중에 입력한 명령과 출력을 기록합니다. 암호와 같은 민감한 데이터가 세션 로그에 표시되지 않도록 하려면 세션 중에 민감한 데이터를 입력할 때 다음 명령을 사용하는 것이 좋습니다.
```
stty -echo; read passwd; stty echo;
```
```
$Passwd = Read-Host -AsSecureString
```
Windows Server 2012 이하를 사용하는 경우 로그의 데이터가 최적 상태로 지정되지 않을 수 있습니다. 최적 로그 형식을 위해 Windows Server 2012 R2 이상을 사용하는 것이 좋습니다.
Linux 또는 macOS 관리형 노드를 사용하는 경우 screen 유틸리티가 설치되어 있어야 합니다. 설치되지 않은 경우 로그 데이터가 잘릴 수 있습니다. Amazon Linux 2, AL2023, Ubuntu Server에는 기본적으로 화면 유틸리티가 설치됩니다. screen을 수동으로 설치하려면 Linux 버전에 따라 `sudo yum install screen` 또는 `sudo apt-get install screen`을 실행합니다.
포트 전달 또는 SSH를 통해 연결하는 Session Manager 세션에는 로깅을 사용할 수 없습니다. 이는 SSH가 AWS CLI 엔드포인트와 Session Manager 엔드포인트 간에 설정된 보안 TLS 연결 내의 모든 세션 데이터를 암호화하고 Session Manager는 SSH 연결을 위한 터널 역할만 하기 때문입니다.
세션 데이터 로그에 Amazon S3 또는 Amazon CloudWatch Logs를 사용하는 데 필요한 권한에 대한 자세한 내용은 [Session Manager, Amazon S3 및 CloudWatch Logs에 대한 권한이 있는 IAM 역할 생성(콘솔)](getting-started-create-iam-instance-profile.md#create-iam-instance-profile-ssn-logging) 섹션을 참조하세요.
Session Manager의 로깅 옵션에 대한 자세한 내용은 다음 주제를 참조하세요.
**Topics**
+ [Amazon CloudWatch Logs를 사용하여 세션 데이터 스트리밍(콘솔)](session-manager-logging-cwl-streaming.md)
+ [Amazon S3를 사용하여 세션 데이터 로깅(콘솔)](session-manager-logging-s3.md)
+ [Amazon CloudWatch Logs를 사용하여 세션 데이터 로깅(콘솔)](session-manager-logging-cloudwatch-logs.md)
+ [디스크에 세션 로깅 구성](session-manager-logging-disk.md)
+ [Session Manager 임시 로그 파일이 디스크에 저장되는 기간 조정](session-manager-logging-disk-retention.md)
+ [CloudWatch Logs 및 Amazon S3의 Session Manager 로깅 비활성화](session-manager-enable-and-disable-logging.md)
# Amazon CloudWatch Logs를 사용하여 세션 데이터 스트리밍(콘솔)
세션 데이터 로그의 연속 스트림을 Amazon CloudWatch Logs로 보낼 수 있습니다. 사용자가 세션에서 실행한 명령, 명령을 실행한 사용자의 ID, 세션 데이터가 CloudWatch Logs로 스트리밍되는 시간에 대한 타임스탬프와 같은 필수 세부 정보는 세션 데이터를 스트리밍할 때 포함됩니다. 세션 데이터를 스트리밍할 때 로그는 JSON 형식이므로 기존 로깅 솔루션과 통합할 수 있습니다. 대화형 명령에는 세션 데이터 스트리밍이 지원되지 않습니다.
**참고**
Windows Server 관리형 노드에서 세션 데이터를 스트리밍하려면 PowerShell 5.1 이상이 설치되어 있어야 합니다. 기본적으로 Windows Server 2016 이상에는 필요한 PowerShell 버전이 설치되어 있습니다. 그러나 Windows Server 2012 및 2012 R2에는 필요한 PowerShell 버전이 기본적으로 설치되어 있지 않습니다. 아직 Windows Server 2012 또는 2012 R2 관리형 노드에서 PowerShell을 업데이트하지 않은 경우 Run Command를 사용하여 업데이트할 수 있습니다. Run Command를 사용하는 PowerShell 업데이트에 대한 자세한 내용은 [Run Command를 사용하여 PowerShell 업데이트](run-command-tutorial-update-software.md#rc-console-pwshexample) 섹션을 참조하세요.
**중요**
Windows Server 관리형 노드에 **PowerShell 트랜스크립션(PowerShell Transcription)** 정책 설정이 구성되어 있으면 세션 데이터를 스트리밍할 수 없습니다.
**Amazon CloudWatch Logs를 사용하여 세션 데이터를 스트리밍하려면(콘솔)**
1. [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)에서 AWS Systems Manager 콘솔을 엽니다.
1. 탐색 창에서 **Session Manager**를 선택합니다.
1. **기본 설정** 탭을 선택하고 **편집**을 선택합니다.
1. [**CloudWatch 로깅(CloudWatch logging)**]에서 [**사용(Enable)**] 확인란을 선택합니다.
1. [**세션 로그 스트리밍**] 옵션을 선택합니다.
1. (권장) [**암호화된 CloudWatch 로그 그룹만 허용(Allow only encrypted CloudWatch log groups)**] 옆의 확인란을 선택합니다. 이 옵션을 설명하면 로그 데이터가 로그 그룹에 지정된 서버 측 암호화 키를 사용하여 암호화됩니다. CloudWatch Logs로 전송되는 로그 데이터를 암호화하지 않으려면 확인란을 선택 취소합니다. 로그 그룹에서 암호화가 허용되지 않는 경우에도 확인란의 선택을 취소해야 합니다.
1. [**CloudWatch 로그(CloudWatch logs)**]에 대해 세션 로그를 업로드할 AWS 계정의 기존 CloudWatch Logs 로그 그룹을 지정하려면 다음 중 하나를 선택합니다.
+ 세션 로그 데이터를 저장하기 위해 계정에 이미 생성된 로그 그룹의 이름을 텍스트 상자에 입력합니다.
+ [**로그 그루 찾아보기(Browse log groups)**]: 계정에서 이미 생성한 로그 그룹을 선택하여 세션 로그 데이터를 저장합니다.
1. **저장**을 선택합니다.
# Amazon S3를 사용하여 세션 데이터 로깅(콘솔)
디버깅 및 문제 해결을 위해 지정된 Amazon Simple Storage Service(Amazon S3) 버킷에 세션 로그 데이터를 저장하도록 선택할 수 있습니다. 기본 옵션은 암호화된 Amazon S3 버킷으로 전송할 로그에 적용됩니다. 암호화는 버킷에 지정한 키인 AWS KMS key 또는 Amazon S3 서버 측 암호화(SSE) 키(AES-256)를 사용하여 수행됩니다.
**중요**
Secure Sockets Layer(SSL)와 함께 가상 호스팅 방식의 버킷을 사용할 경우, SSL 와일드카드 인증서는 마침표가 포함되지 않은 버킷에만 연결됩니다. 이 문제를 해결하려면 HTTP를 사용하거나, 인증서 확인 로직을 직접 작성합니다. 가상 호스팅 방식의 버킷을 사용할 경우 버킷 이름에 마침표(".")를 사용하지 않는 것이 좋습니다.
**Amazon S3 버킷 암호화**
로그를 암호화된 Amazon S3 버킷으로 전송하려면 해당 버킷에서 암호화가 허용되어야 합니다. Amazon S3 버킷 암호화에 대한 자세한 내용은 [S3 버킷에 대한 Amazon S3 기본 암호화](https://docs.aws.amazon.com/AmazonS3/latest/dev/bucket-encryption.html)를 참조하세요.
**고객 관리형 키**
사용자가 스스로 관리하는 KMS 키를 사용해 버킷을 암호화하는 경우 인스턴스에 연결된 IAM 인스턴스 프로파일에는 키를 읽을 수 있는 명시적인 권한이 있어야 합니다. AWS 관리형 키을(를) 사용하는 경우 인스턴스에는 이러한 명시적 권한이 필요하지 않습니다. 인스턴스 프로파일에 키를 사용할 수 있는 액세스 권한 제공에 대한 자세한 내용은 *AWS Key Management Service Developer Guide*의 [Allows Key Users to Use the key](https://docs.aws.amazon.com/kms/latest/developerguide/key-policies.html#key-policy-default-allow-users)를 참조하세요.
다음 단계에 따라 Amazon S3 버킷에 세션 로그를 저장하도록 Session Manager를 구성합니다.
**참고**
또한 AWS CLI를 사용하여 세션 데이터가 전송되는 Amazon S3 버킷을 지정 또는 변경할 수 있습니다. 자세한 내용은 [Session Manager 기본 설정 업데이트(명령줄)](getting-started-configure-preferences-cli.md) 섹션을 참조하세요.
**Amazon S3를 사용하여 세션 데이터를 로그하려면(콘솔)**
1. [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)에서 AWS Systems Manager 콘솔을 엽니다.
1. 탐색 창에서 **Session Manager**를 선택합니다.
1. **기본 설정** 탭을 선택하고 **편집**을 선택합니다.
1. [**S3 로깅(S3 logging)**]에서 [**사용(Enable)**] 확인란을 선택합니다.
1. (권장) [**암호화된 S3 버킷만 허용(Allow only encrypted S3 buckets)**] 옆의 확인란을 선택합니다. 이 옵션을 설명하면 로그 데이터가 버킷에 지정된 서버 측 암호화 키를 사용하여 암호화됩니다. Amazon S3로 전송되는 로그 데이터를 암호화하지 않으려면 확인란을 선택 취소합니다. S3 버킷에서 암호화가 허용되지 않는 경우에도 확인란의 선택을 취소해야 합니다.
1. **S3 버킷 이름**에 대해 다음 중 한 가지를 선택합니다.
**참고**
가상 호스팅 방식의 버킷을 사용할 경우 버킷 이름에 마침표(".")를 사용하지 않는 것이 좋습니다. Amazon S3 버킷 명명 규칙에 대한 자세한 내용은 *Amazon Simple Storage Service 개발자 안내서*의 [버킷 규제 및 제한](https://docs.aws.amazon.com/AmazonS3/latest/dev/BucketRestrictions.html#bucketnamingrules)을 참조하세요.
+ **목록에서 버킷 이름 선택**: 계정에서 이미 생성한 Amazon S3 버킷을 선택하여 세션 로그 데이터를 저장합니다.
+ **텍스트 상자에 버킷 이름 입력**: 계정에서 이미 생성한 Amazon S3 버킷의 이름을 입력하여 세션 로그 데이터를 저장합니다.
1. (선택 사항) **S3 키 접두사**에 대해 선택한 버킷에서 로그를 저장할 기존 폴더 또는 새 폴더의 이름을 입력합니다.
1. **저장**을 선택합니다.
Amazon S3 및 Amazon S3 버킷 작업에 대한 자세한 내용은 *[Amazon Simple Storage Service 사용 설명서](https://docs.aws.amazon.com/AmazonS3/latest/userguide/)* 및 *[Amazon Simple Storage Service 사용 설명서](https://docs.aws.amazon.com/AmazonS3/latest/userguide/)*를 참조하세요.
# Amazon CloudWatch Logs를 사용하여 세션 데이터 로깅(콘솔)
Amazon CloudWatch Logs를 사용하면 다양한 AWS 서비스의 로그 파일을 모니터링, 저장 및 액세스할 수 있습니다. 디버깅 및 문제 해결을 위해 CloudWatch Logs 로그 그룹으로 세션 로그 데이터를 전송할 수 있습니다. 기본 옵션은 KMS 키를 사용하여 암호화된 로그 데이터를 전송하는 것이지만 암호화 여부에 상관없이 로그 그룹에 데이터를 보낼 수 있습니다.
다음 단계에 따라 세션 종료 시 세션 로그 데이터를 CloudWatch Logs 로그 그룹으로 보내도록 AWS Systems Manager Session Manager를 구성합니다.
**참고**
또한 AWS CLI를 사용하여 세션 데이터가 전송되는 CloudWatch Logs 로그 그룹을 지정할 수 있습니다. 자세한 내용은 [Session Manager 기본 설정 업데이트(명령줄)](getting-started-configure-preferences-cli.md) 섹션을 참조하세요.
**Amazon CloudWatch Logs를 사용하여 세션 데이터를 로그하려면(콘솔)**
1. [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)에서 AWS Systems Manager 콘솔을 엽니다.
1. 탐색 창에서 **Session Manager**를 선택합니다.
1. **기본 설정** 탭을 선택하고 **편집**을 선택합니다.
1. [**CloudWatch 로깅(CloudWatch logging)**]에서 [**사용(Enable)**] 확인란을 선택합니다.
1. [**세션 로그 업로드(Upload session logs)**] 옵션을 선택합니다.
1. (권장) [**암호화된 CloudWatch 로그 그룹만 허용(Allow only encrypted CloudWatch log groups)**] 옆의 확인란을 선택합니다. 이 옵션을 설명하면 로그 데이터가 로그 그룹에 지정된 서버 측 암호화 키를 사용하여 암호화됩니다. CloudWatch Logs로 전송되는 로그 데이터를 암호화하지 않으려면 확인란을 선택 취소합니다. 로그 그룹에서 암호화가 허용되지 않는 경우에도 확인란의 선택을 취소해야 합니다.
1. [**CloudWatch 로그(CloudWatch logs)**]에 대해 세션 로그를 업로드할 AWS 계정의 기존 CloudWatch Logs 로그 그룹을 지정하려면 다음 중 하나를 선택합니다.
+ **목록에서 로그 그룹 선택**: 계정에서 이미 생성한 로그 그룹을 선택하여 세션 로그 데이터를 저장합니다.
+ **텍스트 상자에 로그 그룹 이름 입력**: 계정에서 이미 생성한 로그 그룹의 이름을 입력하여 세션 로그 데이터를 저장합니다.
1. **저장**을 선택합니다.
CloudWatch Logs에 대한 자세한 내용은 *[Amazon CloudWatch Logs User Guide](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/)*를 참조하세요.
# 디스크에 세션 로깅 구성
CloudWatch 또는 Amazon S3에 Session Manager 로깅을 활성화하면 세션 중에 실행되는 모든 명령(및 해당 명령의 결과 출력)이 대상 인스턴스의 디스크에 있는 임시 파일에 로깅됩니다. 임시 파일의 이름은 `ipcTempFile.log`입니다.
`ipcTempFile.log`는 SSM Agent 구성 파일의 `SessionLogsDestination` 파라미터에 의해 제어됩니다. 이 파라미터는 다음 값 중 하나를 수락합니다.
+ **디스크**: 이 파라미터를 지정하고 CloudWatch 또는 Amazon S3에 대한 세션 로깅이 **활성화된 경우 SSM Agent는 `ipcTempFile.log` 임시 로그 파일을 생성하고 세션 명령을 로깅하고 디스크에 출력합니다. Session Manager는 로깅 구성에 따라 세션 중 또는 세션 후에 해당 로그를 CloudWatch 또는 S3에 업로드합니다. 그런 다음 로그는 SSM Agent `SessionLogsRetentionDurationHours` 구성 파라미터에 지정된 기간에 따라 삭제됩니다.
이 파라미터를 지정하고 CloudWatch 및 Amazon S3에 대한 세션 로깅을 *비활성화*하더라도 SSM Agent는 명령 기록 및 출력은 `ipcTempFile.log` 파일에 계속 로깅됩니다. 파일은 구성 SSM Agent `SessionLogsRetentionDurationHours` 파라미터에 지정된 기간에 따라 삭제됩니다.
+ **없음**: 이 파라미터를 지정하고 CloudWatch 또는 Amazon S3에 대한 세션 로깅이 *활성화*된 경우 디스크에 대한 로깅은 `disk` 파라미터를 지정한 것과 동일하게 작동합니다. SSM Agent는 CloudWatch 또는 Amazon S3에 대한 세션 로깅이 활성화된 경우 임시 파일을 필요로 합니다.
이 파라미터를 지정하고 CloudWatch 또는 Amazon S3에 대한 세션 로깅이 *비활성화*된 경우 SSM Agent는 `ipcTempFile.log` 파일을 생성하지 않습니다.
다음 절차에 따라 세션이 시작되는 경우 디스크에 대해 `ipcTempFile.log` 임시 로그 파일 생성을 활성화 또는 비활성화할 수 있습니다.
**디스크에 대한 Session Manager 임시 로그 파일 생성을 활성화 또는 비활성화하려면**
1. 인스턴스에 SSM Agent를 설치하거나 버전 3.2.2086 이상으로 업그레이드합니다. 에이전트 버전 번호를 확인하는 방법에 대한 자세한 내용은 [SSM Agent 버전 번호 확인](ssm-agent-get-version.md) 섹션을 참조하세요. 에이전트를 수동으로 설치하는 방법에 대한 자세한 내용은 다음 섹션에서 운영 체제의 절차를 참조하세요.
+ [Linux용 EC2 인스턴스에 수동으로 SSM Agent 설치 및 제거](manually-install-ssm-agent-linux.md)
+ [SSM Agent용 EC2 인스턴스에 수동으로 macOS 설치 및 제거](manually-install-ssm-agent-macos.md)
+ [SSM Agent용 EC2 인스턴스에 수동으로 Windows Server 설치 및 제거](manually-install-ssm-agent-windows.md)
1. 인스턴스에 연결하고 다음 위치에서 `amazon-ssm-agent.json` 파일을 찾습니다.
+ **Linux**: /etc/amazon/ssm/
+ **macOS**: /opt/aws/ssm/
+ **Windows Server**: C:\$1Program Files\$1Amazon\$1SSM
`amazon-ssm-agent.json` 파일이 없는 경우 `amazon-ssm-agent.json.template`의 콘텐츠를 동일한 디렉터리에 있는 새 파일에 복사합니다. 새 파일의 이름을 `amazon-ssm-agent.json`으로 바꿉니다.
1. `SessionLogsDestination` 파라미터에 대해 `none` 또는 `disk`를 지정합니다. 변경 내용을 저장합니다.
1. SSM Agent를 [다시 시작](https://docs.aws.amazon.com/systems-manager/latest/userguide/ssm-agent-status-and-restart.html)합니다.
`SessionLogsDestination` 파라미터에 `disk`를 지정한 경우 새 세션을 시작한 후 다음 위치에서 `ipcTempFile.log`를 찾아 SSM Agent가 임시 로그 파일을 생성하는지 확인할 수 있습니다.
+ **Linux**: /var/lib/amazon/ssm/*target ID*/session/orchestration/*session ID*/Standard\$1Stream/ipcTempFile.log
+ **macOS**: /opt/aws/ssm/data/*target ID*/session/orchestration/*session ID*/Standard\$1Stream/ipcTempFile.log
+ **Windows Server**: C:\$1ProgramData\$1Amazon\$1SSM\$1InstanceData\$1*target ID*\$1session\$1orchestration\$1*session ID*\$1Standard\$1Stream\$1ipcTempFile.log
**참고**
기본적으로 임시 로그 파일은 14일 동안 인스턴스에 저장됩니다.
여러 인스턴스에서 `SessionLogsDestination` 파라미터를 업데이트하려면 새 구성을 지정하는 SSM 문서를 생성하는 것이 좋습니다. 그런 다음 Systems Manager Run Command를 사용하여 인스턴스에 변경 사항을 구현할 수 있습니다. 자세한 내용은 [자체 AWS Systems Manager 문서 작성(블로그)](https://aws.amazon.com/blogs/mt/writing-your-own-aws-systems-manager-documents/) 및 [관리형 노드에서 명령 실행](running-commands.md) 섹션을 참조하세요.
# Session Manager 임시 로그 파일이 디스크에 저장되는 기간 조정
CloudWatch 또는 Amazon S3에 Session Manager 로깅을 활성화하면 세션 중에 실행되는 모든 명령(및 해당 명령의 결과 출력)이 대상 인스턴스의 디스크에 있는 임시 파일에 로깅됩니다. 임시 파일의 이름은 `ipcTempFile.log`입니다. 세션 중 또는 세션이 완료된 후 Session Manager는 이 임시 로그를 CloudWatch 또는 S3에 업로드합니다. 그런 다음 임시 로그는 SSM Agent `SessionLogsRetentionDurationHours` 구성 파라미터에 지정된 기간에 따라 삭제됩니다. 기본적으로 임시 로그 파일은 다음 위치에서 14일 동안 인스턴스에 저장됩니다.
+ **Linux**: /var/lib/amazon/ssm/*target ID*/session/orchestration/*session ID*/Standard\$1Stream/ipcTempFile.log
+ **macOS**: /opt/aws/ssm/data/*target ID*/session/orchestration/*session ID*/Standard\$1Stream/ipcTempFile.log
+ **Windows Server**: C:\$1ProgramData\$1Amazon\$1SSM\$1InstanceData\$1*target ID*\$1session\$1orchestration\$1*session ID*\$1Standard\$1Stream\$1ipcTempFile.log
다음 절차에 따라 Session Manager 임시 로그 파일이 디스크에 저장되는 기간을 조정할 수 있습니다.
**`ipcTempFile.log` 파일이 디스크에 저장되는 기간을 조정하려면**
1. 인스턴스에 연결하고 다음 위치에서 `amazon-ssm-agent.json` 파일을 찾습니다.
+ **Linux**: /etc/amazon/ssm/
+ **macOS**: /opt/aws/ssm/
+ **Windows Server**: C:\$1Program Files\$1Amazon\$1SSM
`amazon-ssm-agent.json` 파일이 없는 경우 `amazon-ssm-agent.json.template`의 콘텐츠를 동일한 디렉터리에 있는 새 파일에 복사합니다. 새 파일의 이름을 `amazon-ssm-agent.json`으로 바꿉니다.
1. `SessionLogsRetentionDurationHours`의 값을 원하는 시간으로 변경합니다. `SessionLogsRetentionDurationHours`를 0으로 설정하면 세션 중에 임시 로그 파일이 생성되고 세션이 완료되면 삭제됩니다. 이 설정은 세션이 종료된 후 로그 파일이 지속되지 않도록 합니다.
1. 변경 내용을 저장합니다.
1. SSM Agent를 [다시 시작](https://docs.aws.amazon.com/systems-manager/latest/userguide/ssm-agent-status-and-restart.html)합니다.
# CloudWatch Logs 및 Amazon S3의 Session Manager 로깅 비활성화
Systems Manager 콘솔 또는 AWS CLI를 사용하여계정의 세션 로깅을 비활성화할 수 있습니다.
**세션 로깅을 비활성화하는 방법(콘솔)**
1. [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)에서 AWS Systems Manager 콘솔을 엽니다.
1. 탐색 창에서 **Session Manager**를 선택합니다.
1. **기본 설정** 탭을 선택하고 **편집**을 선택합니다.
1. CloudWatch 로깅을 비활성화하려면 **CloudWatch 로깅** 섹션에서 **활성화** 확인란 선택을 취소합니다.
1. S3 로깅을 비활성화하려면 **S3 로깅** 섹션에서 **활성화** 확인란 선택을 취소합니다.
1. **저장**을 선택합니다.
**세션 로깅을 비활성화하는 방법(AWS CLI)**
AWS CLI를 사용하여 세션 로깅을 비활성화하려면 [Session Manager 기본 설정 업데이트(명령줄)](getting-started-configure-preferences-cli.md)의 지침을 따릅니다.
JSON 파일에서 `s3BucketName` 및 `cloudWatchLogGroupName` 입력에 값이 없는지 확인합니다. 예제:
```
"inputs": {
"s3BucketName": "",
...
"cloudWatchLogGroupName": "",
...
}
```
또는 JSON 파일에서 모든 `S3*` 및 `cloudWatch*` 입력을 제거하여 로깅을 비활성화할 수도 있습니다.
**참고**
구성에 따라 CloudWatch 또는 S3를 비활성화한 후에도 SSM Agent가 디스크에 임시 로그 파일을 생성할 수 있습니다. 디스크에 대한 로깅을 비활성화하는 방법에 대한 자세한 내용은 [디스크에 세션 로깅 구성](session-manager-logging-disk.md) 섹션을 참조하세요.
# Session 문서 스키마
다음 정보는 Session 문서의 스키마 요소에 대해 설명합니다. AWS Systems Manager Session Manager는 Session 문서를 사용하여 표준 세션, 포트 전달 세션 또는 대화형 명령을 실행하는 세션 등 시작할 세션 유형을 결정합니다.
[schemaVersion](#version)
Session 문서의 스키마 버전입니다. Session 문서는 버전 1.0만 지원합니다.
유형: 문자열
필수 항목 여부: 예
[description](#descript)
Session 문서에 대해 지정하는 설명입니다. 예를 들면 “Session Manager로 포트 전달 세션을 시작하기 위한 문서“입니다.
유형: 문자열
필수 여부: 아니요
[sessionType](#type)
Session 문서가 설정하는 데 사용되는 세션 유형입니다.
유형: 문자열
필수 항목 여부: 예
유효한 값: `InteractiveCommands` \$1 `NonInteractiveCommands` \$1 `Port` \$1 `Standard_Stream`
[inputs](#in)
이 Session 문서를 사용하여 설정된 세션에 사용할 세션 기본 설정입니다. 이 요소는 `Standard_Stream` 세션을 생성하는 데 사용되는 Session 문서에 필요합니다.
유형: StringMap
필수 여부: 아니요
[s3BucketName](#bucket)
세션 종료 시 세션 로그를 보내려는 Amazon Simple Storage Service(Amazon S3) 버킷입니다.
유형: 문자열
필수 여부: 아니요
[s3KeyPrefix](#prefix)
`s3BucketName` 입력에 지정한 Amazon S3 버킷으로 로그를 보낼 때 사용할 접두사입니다. Amazon S3에 저장된 객체에 공유 접두사 사용에 대한 자세한 내용은 *Amazon Simple Storage Service 사용 설명서*의 [S3 버킷에서 폴더를 어떻게 사용하나요?](https://docs.aws.amazon.com/AmazonS3/latest/user-guide/using-folders.html)를 참조하세요.
유형: 문자열
필수 여부: 아니요
[s3EncryptionEnabled](#s3Encrypt)
`true`로 설정하면 `s3BucketName` 입력에 지정한 Amazon S3 버킷을 암호화해야 합니다.
유형: 부울
필수 여부: 예
[cloudWatchLogGroupName](#logGroup)
세션 종료 시 세션 로그를 보내려는 Amazon CloudWatch Logs(CloudWatch Logs) 그룹의 이름입니다.
유형: 문자열
필수 여부: 아니요
[cloudWatchEncryptionEnabled](#cwEncrypt)
`true`로 설정하면 `cloudWatchLogGroupName` 입력에 지정한 로그 그룹을 암호화해야 합니다.
유형: 부울
필수 여부: 예
[cloudWatchStreamingEnabled](#cwStream)
`true`로 설정하면 세션 데이터 로그의 연속 스트림이 `cloudWatchLogGroupName` 입력에 지정한 로그 그룹으로 전송됩니다. `false`로 설정하면 세션 로그가 세션 종료 시 `cloudWatchLogGroupName` 입력에 지정한 로그 그룹으로 전송됩니다.
유형: 부울
필수 여부: 예
[kmsKeyId](#kms)
로컬 클라이언트 시스템과 연결하는 Amazon Elastic Compute Cloud(Amazon EC2) 관리형 노드 간의 데이터를 추가로 암호화하는 데 사용할 AWS KMS key의 ID입니다.
유형: 문자열
필수 여부: 아니요
[runAsEnabled](#run)
`true`로 설정하면 `runAsDefaultUser` 입력에 연결할 관리형 노드에 존재하는 사용자 계정을 지정해야 합니다. 그렇지 않으면 세션이 시작되지 않습니다. 기본적으로 세션은 AWS Systems Manager SSM Agent에서 생성된 `ssm-user` 계정을 사용하여 시작됩니다. 다음으로 실행 기능은 Linux 및 macOS 관리형 노드에 연결하는 경우에만 지원됩니다.
유형: 부울
필수 여부: 예
[runAsDefaultUser](#runUser)
`runAsEnabled` 입력이 `true`로 설정된 경우 Linux 및 macOS 관리형 노드에서 세션을 시작할 사용자 계정의 이름입니다. 이 입력에 대해 지정한 사용자 계정은 연결할 관리형 노드에 있어야 합니다. 그렇지 않으면 세션이 시작되지 않습니다.
유형: 문자열
필수 여부: 아니요
[idleSessionTimeout](#timeout)
세션이 종료되기 전에 허용할 비활성 시간입니다. 이 입력은 분 단위로 측정됩니다.
유형: 문자열
유효한 값은 1\$160입니다.
필수 여부: 아니요
[maxSessionDuration](#maxDuration)
세션이 종료되기 전에 허용할 최대 시간입니다. 이 입력은 분 단위로 측정됩니다.
유형: 문자열
유효한 값은 1\$11,440입니다.
필수 여부: 아니요
[shellProfile](#shell)
셸 기본 설정, 환경 변수, 작업 디렉터리 및 세션 시작 시 여러 명령 실행과 같이 세션 내에서 적용할 운영 체제별로 지정하는 기본 설정입니다.
유형: StringMap
필수 여부: 아니요
[windows](#win)
Windows Server 관리형 노드의 세션에 대해 지정하는 쉘 기본 설정, 환경 변수, 작업 디렉터리 및 명령입니다.
유형: 문자열
필수 여부: 아니요
[linux](#lin)
Linux 및 macOS 관리형 노드의 세션에 대해 지정하는 쉘 기본 설정, 환경 변수, 작업 디렉터리 및 명령입니다.
유형: 문자열
필수 여부: 아니요
[parameters](#param)
문서가 허용하는 파라미터를 정의하는 객체입니다. 문서 파라미터 정의에 대한 자세한 내용은 [최상위 데이터 요소](documents-syntax-data-elements-parameters.md#top-level)의 **파라미터**를 참조하세요. 자주 참조하는 파라미터의 경우에는 먼저 Systems Manager Parameter Store에 저장한 후 참조하는 것이 좋습니다. 이 문서 섹션에서는 `String` 및 `StringList` Parameter Store 파라미터를 참조할 수 있습니다. 이 문서 섹션에서는 `SecureString` Parameter Store 파라미터를 참조할 수 없습니다. 다음 형식을 사용하여 Parameter Store 파라미터를 참조할 수 있습니다.
```
{{ssm:parameter-name}}
```
Parameter Store에 대한 자세한 내용은 [AWS Systems Manager Parameter Store](systems-manager-parameter-store.md) 섹션을 참조하세요.
유형: StringMap
필수 여부: 아니요
[properties](#props)
`StartSession` API 작업에 사용되는 값을 지정하는 객체입니다.
`InteractiveCommands` 세션에 사용되는 Session 문서의 경우 속성 객체에는 지정한 운영 체제에서 실행할 명령이 포함됩니다. `runAsElevated` 부울 속성을 사용하여 명령이 `root`로 실행되는지도 판단할 수 있습니다. 자세한 내용은 [세션의 명령에 대한 액세스 제한](session-manager-restrict-command-access.md)을 참조하세요.
`Port` 세션에 사용되는 Session 문서의 경우 속성 객체에는 트래픽이 리디렉션되어야 하는 포트 번호가 포함됩니다. 예를 들어 이 주제 뒷부분의 `Port` 유형 Session 문서 예를 참조하세요.
유형: StringMap
필수 여부: 아니요
`Standard_Stream` 유형 Session 문서 예
------
#### [ YAML ]
```
---
schemaVersion: '1.0'
description: Document to hold regional settings for Session Manager
sessionType: Standard_Stream
inputs:
s3BucketName: ''
s3KeyPrefix: ''
s3EncryptionEnabled: true
cloudWatchLogGroupName: ''
cloudWatchEncryptionEnabled: true
cloudWatchStreamingEnabled: true
kmsKeyId: ''
runAsEnabled: true
runAsDefaultUser: ''
idleSessionTimeout: '20'
maxSessionDuration: '60'
shellProfile:
windows: ''
linux: ''
```
------
#### [ JSON ]
```
{
"schemaVersion": "1.0",
"description": "Document to hold regional settings for Session Manager",
"sessionType": "Standard_Stream",
"inputs": {
"s3BucketName": "",
"s3KeyPrefix": "",
"s3EncryptionEnabled": true,
"cloudWatchLogGroupName": "",
"cloudWatchEncryptionEnabled": true,
"cloudWatchStreamingEnabled": true,
"kmsKeyId": "",
"runAsEnabled": true,
"runAsDefaultUser": "",
"idleSessionTimeout": "20",
"maxSessionDuration": "60",
"shellProfile": {
"windows": "date",
"linux": "pwd;ls"
}
}
}
```
------
`InteractiveCommands` 유형 Session 문서 예
------
#### [ YAML ]
```
---
schemaVersion: '1.0'
description: Document to view a log file on a Linux instance
sessionType: InteractiveCommands
parameters:
logpath:
type: String
description: The log file path to read.
default: "/var/log/amazon/ssm/amazon-ssm-agent.log"
allowedPattern: "^[a-zA-Z0-9-_/]+(.log)$"
properties:
linux:
commands: "tail -f {{ logpath }}"
runAsElevated: true
```
------
#### [ JSON ]
```
{
"schemaVersion": "1.0",
"description": "Document to view a log file on a Linux instance",
"sessionType": "InteractiveCommands",
"parameters": {
"logpath": {
"type": "String",
"description": "The log file path to read.",
"default": "/var/log/amazon/ssm/amazon-ssm-agent.log",
"allowedPattern": "^[a-zA-Z0-9-_/]+(.log)$"
}
},
"properties": {
"linux": {
"commands": "tail -f {{ logpath }}",
"runAsElevated": true
}
}
}
```
------
`Port` 유형 Session 문서 예
------
#### [ YAML ]
```
---
schemaVersion: '1.0'
description: Document to open given port connection over Session Manager
sessionType: Port
parameters:
paramExample:
type: string
description: document parameter
properties:
portNumber: anyPortNumber
```
------
#### [ JSON ]
```
{
"schemaVersion": "1.0",
"description": "Document to open given port connection over Session Manager",
"sessionType": "Port",
"parameters": {
"paramExample": {
"type": "string",
"description": "document parameter"
}
},
"properties": {
"portNumber": "anyPortNumber"
}
}
```
------
특수 문자가 있는 Session 문서 예
------
#### [ YAML ]
```
---
schemaVersion: '1.0'
description: Example document with quotation marks
sessionType: InteractiveCommands
parameters:
Test:
type: String
description: Test Input
maxChars: 32
properties:
windows:
commands: |
$Test = '{{ Test }}'
$myVariable = \"Computer name is $env:COMPUTERNAME\"
Write-Host "Test variable: $myVariable`.`nInput parameter: $Test"
runAsElevated: false
```
------
#### [ JSON ]
```
{
"schemaVersion":"1.0",
"description":"Test document with quotation marks",
"sessionType":"InteractiveCommands",
"parameters":{
"Test":{
"type":"String",
"description":"Test Input",
"maxChars":32
}
},
"properties":{
"windows":{
"commands":[
"$Test = '{{ Test }}'",
"$myVariable = \\\"Computer name is $env:COMPUTERNAME\\\"",
"Write-Host \"Test variable: $myVariable`.`nInput parameter: $Test\""
],
"runAsElevated":false
}
}
}
```
------
# Session Manager 문제 해결
다음 정보를 사용하면 AWS Systems Manager Session Manager 관련 문제를 해결하는 데 도움이 됩니다.
**Topics**
+ [TerminateSession 작업을 직접적으로 호출할 때 AccessDeniedException](#session-manager-troubleshooting-access-denied-exception)
+ [문서 프로세스가 예기치 않게 실패: 문서 작업자 제한 시간 초과됨](#session-manager-troubleshooting-document-worker-timed-out)
+ [Session Manager는 Amazon EC2 콘솔에서 연결할 수 없습니다.](#session-manager-troubleshooting-EC2-console)
+ [세션을 시작할 권한 없음](#session-manager-troubleshooting-start-permissions)
+ [SSM Agent가 온라인 상태가 아님](#session-manager-troubleshooting-agent-not-online)
+ [세션 기본 설정을 변경할 권한 없음](#session-manager-troubleshooting-preferences-permissions)
+ [관리형 노드를 사용할 수 없거나 Session Manager에 대해 구성되지 않음](#session-manager-troubleshooting-instances)
+ [Session Manager 플러그인을 찾을 수 없음](#plugin-not-found)
+ [명령줄 경로에 자동으로 추가되지 않는 Session Manager 플러그인(Windows)](#windows-plugin-env-var-not-set)
+ [Session Manager 플러그 인이 응답하지 않음](#plugin-unresponsive)
+ [TargetNotConnected](#ssh-target-not-connected)
+ [세션 시작 후 빈 화면 표시](#session-manager-troubleshooting-start-blank-screen)
+ [장기 실행 세션 동안 관리형 노드가 응답하지 않음](#session-manager-troubleshooting-log-retention)
+ [StartSession 작업을 호출할 때 오류가 발생합니다(InvalidDocument)](#session-manager-troubleshooting-invalid-document)
## TerminateSession 작업을 직접적으로 호출할 때 AccessDeniedException
**문제**: 세션을 종료할 때 Systems Manager는 다음 오류를 반환합니다.
```
An error occurred (AccessDeniedException) when calling the TerminateSession operation:
User: is not authorized to perform: ssm:TerminateSession on resource:
because no identity-based policy allows the ssm:TerminateSession action.
```
**솔루션 A: [최신 버전의 Session Manager 플러그인](https://docs.aws.amazon.com/systems-manager/latest/userguide/plugin-version-history.html)이 노드에 설치되어 있는지 확인**
터미널에서 다음 명령을 입력하고 Enter 키를 누릅니다.
```
session-manager-plugin --version
```
**솔루션 B: 최신 버전의 플러그인 설치 또는 재설치**
자세한 내용은 [AWS CLI의 Session Manager 플러그인 설치](session-manager-working-with-install-plugin.md) 섹션을 참조하세요.
**솔루션 C: 노드에 대한 연결 재설정 시도**
노드가 요청에 응답하는지 확인합니다. 세션을 다시 설정해 봅니다. 또는 필요한 경우 Amazon EC2 콘솔을 열고 인스턴스가 실행 중 상태인지 확인합니다.
## 문서 프로세스가 예기치 않게 실패: 문서 작업자 제한 시간 초과됨
**문제**: Linux 호스트에 대한 세션을 시작할 때 Systems Manager는 다음 오류를 반환합니다.
```
document process failed unexpectedly: document worker timed out,
check [ssm-document-worker]/[ssm-session-worker] log for crash reason
```
[SSM Agent 로그 보기](ssm-agent-logs.md)에서 설명한 대로 SSM Agent 로깅을 구성한 경우 디버깅 로그에서 세부 정보를 볼 수 있습니다. 이 문제의 경우 Session Manager에서는 다음 로그 항목을 보여줍니다.
```
failed to create channel: too many open files
```
이 오류는 일반적으로 실행 중인 Session Manager 작업자 프로세스가 너무 많고 기본 운영 체제가 한도에 도달했음을 나타냅니다. 이 문제를 해결하기 위한 두 가지 옵션이 있습니다.
**해결 방법 A: 운영 체제 파일 알림 한도 증가**
별도의 Linux 호스트에서 다음 명령을 실행하여 한도를 늘릴 수 있습니다. 이 명령은 Systems Manager Run Command를 사용합니다. 지정된 값은 `max_user_instances`에서 8,192로 증가합니다. 이 값은 기본값인 128보다 상당히 높지만 호스트 리소스를 제한하지는 않습니다.
```
aws ssm send-command --document-name AWS-RunShellScript \
--instance-id i-02573cafcfEXAMPLE --parameters \
"commands=sudo sysctl fs.inotify.max_user_instances=8192"
```
**솔루션 B: 대상 호스트의 Session Manager에서 사용하는 파일 알림 감소 **
별도의 Linux 호스트에서 다음 명령을 실행하여 대상 호스트에서 실행되는 세션을 나열합니다.
```
aws ssm describe-sessions --state Active --filters key=Target,value=i-02573cafcfEXAMPLE
```
명령 출력을 검토하여 더 이상 필요하지 않은 세션을 식별합니다. 별도의 Linux 호스트에서 다음 명령을 실행하여 해당 세션을 종료할 수 있습니다.
```
aws ssm terminate-session —session-id session ID
```
선택적으로 원격 서버에서 더 이상 실행되는 세션이 없으면 별도의 Linux 호스트에서 다음 명령을 실행하여 추가 리소스를 해제할 수 있습니다. 이 명령은 원격 호스트에서 실행되는 모든 Session Manager 프로세스를 종료하고 이후 원격 호스트에 대한 모든 세션을 종료합니다. 이 명령을 실행하기 전에 유지하려는 진행 중인 세션이 없는지 확인합니다.
```
aws ssm send-command --document-name AWS-RunShellScript \
--instance-id i-02573cafcfEXAMPLE --parameters \
'{"commands":["sudo kill $(ps aux | grep ssm-session-worker | grep -v grep | awk '"'"'{print $2}'"'"')"]}'
```
## Session Manager는 Amazon EC2 콘솔에서 연결할 수 없습니다.
**문제**: 새 인스턴스를 생성한 후 Amazon Elastic Compute Cloud(Amazon EC2) 콘솔의 **연결** 버튼 > **Session Manager** 탭에 연결 옵션이 표시되지 않습니다.
**솔루션 A: 인스턴스 프로파일 생성**: 아직 그렇게(EC2 콘솔의 **Session Manager** 탭에 있는 정보의 지침대로) 하지 않았다면 Quick Setup을 사용하여 AWS Identity and Access Management(IAM) 인스턴스 프로파일을 생성합니다. Quick Setup은 AWS Systems Manager의 도구입니다.
인스턴스에 연결하려면 IAM 인스턴스 프로파일이 Session Manager에 필요합니다. Quick Setup으로 [호스트 관리 구성](https://docs.aws.amazon.com/systems-manager/latest/userguide/quick-setup-host-management.html)을 생성하면 인스턴스 프로파일을 생성하여 인스턴스에 할당할 수 있습니다. *호스트 관리 구성*에서는 필요한 권한이 있는 인스턴스 프로파일을 생성하여 인스턴스에 할당합니다. 또한 호스트 관리 구성에서는 다른 Systems Manager 도구를 활성화하고 해당 도구를 실행할 IAM 역할을 생성합니다. 호스트 관리 구성을 통해 활성화된 Quick Setup 또는 도구를 사용할 때 요금은 발생하지 않습니다. [Quick Setup을 열고 호스트 관리 구성을 생성합니다](https://console.aws.amazon.com/systems-manager/quick-setup/create-configuration&configurationType=SSMHostMgmt).
**중요**
호스트 관리 구성을 생성한 후 Amazon EC2에서 변경 사항을 등록하고 **Session Manager** 탭을 새로 고치는 데 몇 분 정도 걸릴 수 있습니다. 2분 후에도 탭에 **연결** 버튼이 표시되지 않으면 인스턴스를 재부팅 해보세요. 재부팅 후에도 연결 옵션이 표시되지 않으면 [빠른 설정을](https://console.aws.amazon.com/systems-manager/quick-setup/create-configuration&configurationType=SSMHostMgmt) 열고 호스트 관리 구성이 하나뿐인지 확인합니다. 구성이 2개라면 오래된 구성을 삭제하고 몇 분 정도 기다립니다.
호스트 관리 구성을 생성한 후에도 여전히 연결할 수 없거나 오류(SSM Agent에 대한 오류 포함)가 표시되는 경우 다음과 같은 솔루션 중 하나를 참조하세요.
+ [솔루션 방법 B: 오류가 없으나 여전히 연결할 수 없음](#session-manager-troubleshooting-EC2-console-no-error)
+ [솔루션 C: 누락 SSM Agent에 대한 오류](#session-manager-troubleshooting-EC2-console-no-agent)
### 솔루션 방법 B: 오류가 없으나 여전히 연결할 수 없음
호스트 관리 구성을 생성하고 연결을 시도하기 전에 몇 분 정도 기다렸는데도 연결할 수 없으면 호스트 관리 구성을 인스턴스에 수동으로 적용해야 할 수도 있습니다. 다음 절차를 사용하여 Quick Setup 호스트 관리 구성을 업데이트하고 인스턴스에 변경 사항을 적용합니다.
**Quick Setup을 사용하여 호스트 관리 구성을 업데이트하는 방법**
1. [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)에서 AWS Systems Manager 콘솔을 엽니다.
1. 탐색 창에서 **Quick Setup**을 선택합니다.
1. 생성한 **호스트 관리** 구성을 **구성** 목록에서 선택합니다.
1. **작업**을 선택한 다음에 **구성 편집**을 선택합니다.
1. **대상** 섹션 아래쪽의 **대상 인스턴스 지정 방식 선택**에서 **수동**을 선택합니다.
1. 생성한 인스턴스를 **인스턴스** 섹션에서 선택합니다.
1. **업데이트**를 선택합니다.
EC2에서 **Session Manager** 탭 새로 고침이 진행되는 동안 몇 분 정도 기다립니다. 그래도 연결할 수 없거나 오류가 표시되는 경우 이 문제에 대한 나머지 솔루션을 검토합니다.
### 솔루션 C: 누락 SSM Agent에 대한 오류
Quick Setup을 사용하여 호스트 관리 구성을 생성할 수 없거나 설치되지 않은 SSM Agent에 대한 오류가 표시되면 인스턴스에 수동으로 SSM Agent를 설치해야 할 수 있습니다. SSM Agent는 Session Manager를 사용하여 인스턴스에 연결하도록 Systems Manager를 활성화하는 Amazon 소프트웨어입니다. SSM Agent는 대부분의 Amazon Machine Image(AMI)에 기본적으로 설치되어 있습니다. 비표준 AMI 또는 오래된 AMI에서 인스턴스를 생성한 경우 에이전트를 수동으로 설치해야 할 수도 있습니다. SSM Agent 설치 절차는 인스턴스 운영 체제에 해당하는 다음 주제를 참조하세요.
+ [https://docs.aws.amazon.com/systems-manager/latest/userguide/manually-install-ssm-agent-windows.html](https://docs.aws.amazon.com/systems-manager/latest/userguide/manually-install-ssm-agent-windows.html)
+ [https://docs.aws.amazon.com/systems-manager/latest/userguide/manually-install-ssm-agent-macos.html](https://docs.aws.amazon.com/systems-manager/latest/userguide/manually-install-ssm-agent-macos.html)
+ [AlmaLinux](https://docs.aws.amazon.com/systems-manager/latest/userguide/agent-install-alma.html)
+ [Amazon Linux 2 및 AL2023](https://docs.aws.amazon.com/systems-manager/latest/userguide/agent-install-al2.html)
+ [https://docs.aws.amazon.com/systems-manager/latest/userguide/agent-install-deb.html](https://docs.aws.amazon.com/systems-manager/latest/userguide/agent-install-deb.html)
+ [https://docs.aws.amazon.com/systems-manager/latest/userguide/agent-install-oracle.html](https://docs.aws.amazon.com/systems-manager/latest/userguide/agent-install-oracle.html)
+ [https://docs.aws.amazon.com/systems-manager/latest/userguide/agent-install-rhel.html](https://docs.aws.amazon.com/systems-manager/latest/userguide/agent-install-rhel.html)
+ [https://docs.aws.amazon.com/systems-manager/latest/userguide/agent-install-rocky.html](https://docs.aws.amazon.com/systems-manager/latest/userguide/agent-install-rocky.html)
+ [https://docs.aws.amazon.com/systems-manager/latest/userguide/agent-install-ubuntu.html](https://docs.aws.amazon.com/systems-manager/latest/userguide/agent-install-ubuntu.html)
SSM Agent 관련 문제는 [SSM Agent 문제 해결](troubleshooting-ssm-agent.md)를 참조하세요.
## 세션을 시작할 권한 없음
**문제**: 세션을 시작하려고 했지만 필요한 권한이 없다고 표시됩니다.
+ **해결 방법**: 시스템 관리자가 Session Manager 세션을 시작할 수 있는 AWS Identity and Access Management(IAM) 정책 권한을 부여하지 않았습니다. 자세한 내용은 [인스턴스에 대한 사용자 세션 액세스 제어](session-manager-getting-started-restrict-access.md)를 참조하세요.
## SSM Agent가 온라인 상태가 아님
**문제**: Amazon EC2 인스턴스 **Session Manager** 탭에 "SSM Agent가 온라인 상태가 아닙니다. SSM Agent가 서비스에 등록하기 위해 Systems Manager 엔드포인트에 연결하지 못했습니다."라는 메시지가 표시됩니다.
**해결 방법**: SSM Agent는 Session Manager가 Amazon EC2 인스턴스에 연결할 수 있도록 해당 인스턴스에서 실행되는 Amazon 소프트웨어입니다. 이 오류가 표시되면 SSM Agent가 Systems Manager 엔드포인트와 연결을 설정할 수 없는 것입니다. 방화벽 제한, 라우팅 문제 또는 인터넷 연결 부재가 문제의 원인일 수 있습니다. 이 문제를 해결하려면 네트워크 연결 문제를 조사하세요. 자세한 내용은 [SSM Agent 문제 해결](troubleshooting-ssm-agent.md) 및 [관리형 노드 가용성 문제 해결](fleet-manager-troubleshooting-managed-nodes.md)(을)를 참조하세요. Systems Manager 엔드포인트에 대한 자세한 내용은 AWS 일반 참조에서 [AWS Systems Manager 엔드포인트 및 할당량](https://docs.aws.amazon.com/general/latest/gr/ssm.html)을 참조하세요.
## 세션 기본 설정을 변경할 권한 없음
**문제**: 조직에 대한 전역 세션 기본 설정을 업데이트하려고 했는데 필요한 권한이 없다는 메시지가 표시됩니다.
+ **해결 방법**: 시스템 관리자가 Session Manager 기본 설정을 지정할 수 있는 IAM 정책 권한을 부여하지 않았습니다. 자세한 내용은 [Session Manager 기본 설정을 업데이트하도록 사용자 권한 부여 또는 거부](preference-setting-permissions.md) 섹션을 참조하세요.
## 관리형 노드를 사용할 수 없거나 Session Manager에 대해 구성되지 않음
**문제 1**: **세션 시작(Start a session)** 콘솔 페이지에서 세션을 시작하려고 했지만 관리형 노드가 목록에 없습니다.
+ **솔루션 A**: 연결하려는 관리형 노드가 AWS Systems Manager에서 구성되지 않았을 수 있습니다. 자세한 내용은 [조직을 위한 Systems Manager 통합 콘솔 설정](systems-manager-setting-up-organizations.md) 섹션을 참조하세요.
**참고**
IAM 인스턴스 프로파일을 연결할 때 AWS Systems Manager SSM Agent가 이미 실행 중이면 **세션 시작(Start a session)** 콘솔 페이지에 관리형 노드가 나열되기 전에 에이전트를 다시 시작해야 할 수 있습니다.
+ **해결 방법 B**: 관리형 노드의 SSM Agent에 적용한 프록시 구성이 올바르지 않을 수 있습니다. 프록시 구성이 올바르지 않으면 관리형 노드가 필요한 서비스 엔드포인트에 연결할 수 없거나 노드가 Systems Manager에 다른 운영 체제로 보고할 수 있습니다. 자세한 내용은 [SSM Agent를 구성하여 Linux 노드에 프록시 사용](configure-proxy-ssm-agent.md) 및 [Windows Server 인스턴스에 프록시를 사용하도록 SSM Agent 구성](configure-proxy-ssm-agent-windows.md)(을)를 참조하세요.
**문제 2**: 연결하려는 관리형 노드가 **세션 시작(Start a session)** 콘솔 페이지의 목록에 있지만 이 페이지에 "선택한 인스턴스가 Session Manager를 사용하도록 구성되지 않았습니다.(The instance you selected isn't configured to use Session Manager.)"라는 메시지가 표시됩니다.
+ **해결 방법 A**: 관리형 노드가 Systems Manager 서비스에서 사용하도록 구성되어 있지만 노드에 연결된 IAM 인스턴스 프로파일에 Session Manager 도구에 대한 권한이 없을 수 있습니다. 자세한 내용은 [Session Manager 권한이 있는 IAM 인스턴스 프로파일 확인 또는 생성(Verify or Create an IAM Instance Profile with Session Manager Permissions)](session-manager-getting-started-instance-profile.md)을 참조하세요.
+ **해결 방법 B**: 관리형 노드가 Session Manager를 지원하는 SSM Agent 버전을 실행하지 않습니다. 노드에 대한 SSM Agent를 버전 2.3.68.0 이상으로 업데이트합니다.
운영 체제에 따라 [SSM Agent용 EC2 인스턴스에 수동으로 Windows Server 설치 및 제거](manually-install-ssm-agent-windows.md), [Linux용 EC2 인스턴스에 수동으로 SSM Agent 설치 및 제거](manually-install-ssm-agent-linux.md) 또는 [SSM Agent용 EC2 인스턴스에 수동으로 macOS 설치 및 제거](manually-install-ssm-agent-macos.md)의 단계를 수행하여 관리형 노드에 SSM Agent를 업데이트합니다.
또는 Run Command 문서 `AWS-UpdateSSMAgent`를 사용하여 한 번에 하나 이상의 관리형 노드에서 에이전트 버전을 업데이트하세요. 자세한 내용은 [Run Command를 사용하여 SSM Agent 업데이트](run-command-tutorial-update-software.md#rc-console-agentexample) 섹션을 참조하세요.
**작은 정보**
에이전트를 항상 최신 상태로 유지하려면 다음 방법 중 하나를 사용하여 정의한 자동화된 일정에 따라 SSM Agent를 최신 버전으로 업데이트하는 것이 좋습니다.
State Manager 연결의 일부로 `AWS-UpdateSSMAgent`를 실행합니다. 자세한 내용은 [연습: AWS CLI를 사용하여 SSM Agent를 자동으로 업데이트](state-manager-update-ssm-agent-cli.md) 섹션을 참조하세요.
`AWS-UpdateSSMAgent`를 유지 관리 기간의 일부로 실행합니다. 유지 관리 기간 작업에 대한 자세한 내용은 [콘솔을 사용하여 유지 관리 기간 생성 또는 선택](sysman-maintenance-working.md) 및 [자습서: AWS CLI를 사용한 유지 관리 기간 생성 및 구성](maintenance-windows-cli-tutorials-create.md) 섹션을 참조하세요.
+ **해결 방법 C**: 관리형 노드가 필수 서비스 엔드포인트에 연결할 수 없습니다. AWS PrivateLink에서 제공하는 인터페이스 엔드포인트를 사용하여 Systems Manager 엔드포인트에 연결하여 관리형 노드의 보안 태세를 개선할 수 있습니다. 인터페이스 엔드포인트 사용의 대체 방법은 관리형 노드에서 아웃바운드 인터넷 액세스를 허용하는 것입니다. 자세한 내용은 [PrivateLink를 사용하여 Session Manager에 대한 VPC 엔드포인트 설정](https://docs.aws.amazon.com/systems-manager/latest/userguide/session-manager-getting-started-privatelink.html)을 참조하세요.
+ **솔루션 D**: 관리형 노드에 사용 가능한 CPU 또는 메모리 리소스가 제한되어 있습니다. 관리형 노드가 작동할 수는 있지만 노드에 사용 가능한 리소스가 충분하지 않은 경우 세션을 설정할 수 없습니다. 자세한 내용은 [연결할 수 없는 인스턴스 문제 해결](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-console.html)을 참조하세요.
## Session Manager 플러그인을 찾을 수 없음
AWS CLI를 사용하여 세션 명령을 실행하려면 Session Manager 플러그인도 로컬 시스템에 설치해야 합니다. 자세한 내용은 [AWS CLI의 Session Manager 플러그인 설치](session-manager-working-with-install-plugin.md) 섹션을 참조하세요.
## 명령줄 경로에 자동으로 추가되지 않는 Session Manager 플러그인(Windows)
Windows에 Session Manager 플러그인을 설치하면 `session-manager-plugin` 실행 파일이 운영 체제의 `PATH` 환경 변수에 자동으로 추가되어야 합니다. Session Manager 플러그인이 제대로 설치되었는지 확인하기 위해 이 환경 변수를 실행한 후 명령에 실패하면(`aws ssm start-session --target instance-id`) 다음 절차를 수행하여 수동으로 설정해야 할 수 있습니다.
**PATH 변수(Windows)를 수정하려면**
1. Windows 키를 누르고 **environment variables**를 입력합니다.
1. **계정의 환경 변수 편집**을 선택합니다.
1. **PATH**를 선택한 후 **편집**을 선택합니다.
1. 다음 예제에 표시된 대로 세미콜론으로 구분하여 경로를 **변수 값** 필드에 추가합니다. *`C:\existing\path`*;*`C:\new\path`*
다음 예제들에 표시된 대로 *`C:\existing\path`*는 필드에 이미 있는 값을 나타내고, *`C:\new\path`*는 추가하려는 경로를 나타냅니다.
+ **64비트 시스템**: `C:\Program Files\Amazon\SessionManagerPlugin\bin\`
1. **확인**을 두 번 선택하여 새 설정을 적용합니다.
1. 실행 중인 명령 프롬프트를 모두 닫았다가 다시 엽니다.
## Session Manager 플러그 인이 응답하지 않음
포트 전달 세션 중에 로컬 컴퓨터에 바이러스 백신 소프트웨어가 설치되어 있는 경우 트래픽 전달을 중지할 수 있습니다. 어떤 경우에는 Session Manager 플러그 인이 포함된 바이러스 백신 소프트웨어가 프로세스 교착 상태를 일으킵니다. 이 문제를 해결하려면 바이러스 백신 소프트웨어에서 Session Manager 플러그 인을 허용하거나 제외합니다. Session Manager 플러그 인의 기본 설치 경로에 대한 자세한 내용은 [AWS CLI의 Session Manager 플러그인 설치](session-manager-working-with-install-plugin.md) 섹션을 참조하세요.
## TargetNotConnected
**문제**: 세션을 시작하려고 하지만 시스템에서 “StartSession 작업을 호출할 때 (TargetNotConnected) 오류가 발생했습니다. *InstanceID*가 연결되어 있지 않습니다.(An error occurred (TargetNotConnected) when calling the StartSession operation: InstanceID isn't connected.)” 오류 메시지를 반환합니다.
+ **해결 방법 A**: 세션에 대해 지정된 대상 관리형 노드가 세션 관리자에서 사용하도록 완전히 구성되지 않은 경우 이 오류가 반환됩니다. 자세한 내용은 [Session Manager 설정](session-manager-getting-started.md) 섹션을 참조하세요.
+ **해결 방법 B**: 서로 다른 AWS 계정 또는 AWS 리전에 위치한 관리형 노드에서 세션을 시작하려고 시도하는 경우에도 이 오류가 반환됩니다.
## 세션 시작 후 빈 화면 표시
**문제**: 세션을 시작하면 Session Manager에 빈 화면이 표시됩니다.
+ **해결 방법 A**: 이 문제는 관리형 노드의 루트 볼륨이 가득 찬 경우 발생할 수 있습니다. 디스크 공간 부족으로 인해 노드에서 SSM Agent 작동이 중지됩니다. 이 문제를 해결하려면 Amazon CloudWatch를 사용하여 운영 체제의 지표 및 로그를 수집합니다. 자세한 내용은 *Amazon CloudWatch 사용 설명서*의 [CloudWatch 에이전트를 사용하여 지표, 로그 및 추적 수집](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Install-CloudWatch-Agent.html)을 참조하세요.
+ **해결 방법 B**: 일치하지 않는 엔드포인트 및 리전 페어가 포함된 링크를 사용하여 콘솔에 액세스한 경우 빈 화면이 표시될 수 있습니다. 예를 들어 다음 콘솔 URL에서 `us-west-2`는 지정된 엔드포인트이지만 `us-west-1`이 지정된 AWS 리전입니다.
```
https://us-west-2.console.aws.amazon.com/systems-manager/session-manager/sessions?region=us-west-1
```
+ **해결 방법 C**: 관리형 노드가 VPC 엔드포인트를 사용하여 Systems Manager에 연결하고 있고 Session Manager 기본 설정에서 세션 출력을 Amazon S3 버킷 또는 Amazon CloudWatch Logs 로그 그룹에 기록하지만 `s3` 게이트웨이 엔드포인트 또는 `logs` 인터페이스 엔드포인트는 VPC에 존재하지 않습니다. 관리형 노드가 VPC 엔드포인트를 사용하여 Systems Manager에 연결하고 Session Manager 기본 설정이 Amazon S3 버킷에 세션 출력을 쓰는 경우 **`com.amazonaws.region.s3`** 형식의 `s3` 엔드포인트가 필요합니다. 대신 관리형 노드가 VPC 엔드포인트를 사용하여 Systems Manager에 연결하고 Session Manager 기본 설정이 CloudWatch Logs 로그 그룹에 세션 출력을 쓰는 경우 **`com.amazonaws.region.logs`** 형식의 `logs` 엔드포인트가 필요합니다. 자세한 내용은 [Systems Manager용 VPC 엔드포인트 생성](setup-create-vpc.md#create-vpc-endpoints) 섹션을 참조하세요.
+ **해결 방법 D**: 세션 기본 설정에서 지정한 로그 그룹 또는 Amazon S3 버킷이 삭제되었습니다. 이 문제를 해결하려면 유효한 로그 그룹 또는 S3 버킷으로 세션 기본 설정을 업데이트합니다.
+ **해결 방법 E**: 세션 기본 설정에서 지정한 로그 그룹 또는 Amazon S3 버킷은 암호화되지 않았지만 `cloudWatchEncryptionEnabled` 또는 `s3EncryptionEnabled` 입력을 `true`로 설정했습니다. 이 문제를 해결하려면 암호화된 로그 그룹 또는 Amazon S3 버킷으로 세션 기본 설정을 업데이트하거나 `cloudWatchEncryptionEnabled` 또는 `s3EncryptionEnabled` 입력을 `false`로 설정합니다. 이 시나리오는 명령줄 도구를 사용하여 세션 기본 설정을 생성하는 고객에게만 적용됩니다.
## 장기 실행 세션 동안 관리형 노드가 응답하지 않음
**문제**: 장기 실행 세션 중에 관리형 노드가 응답하지 않거나 충돌합니다.
**해결 방법**: Session Manager에 대한 SSM Agent 로그 보존 기간을 줄입니다.
**세션에 대한 SSM Agent 로그 보존 기간을 줄이려면**
1. Linux의 `/etc/amazon/ssm/` 디렉터리 또는 Windows의 `C:\Program Files\Amazon\SSM`에서 `amazon-ssm-agent.json.template`을 찾습니다.
1. `amazon-ssm-agent.json.template`의 내용을 동일한 디렉터리의 `amazon-ssm-agent.json`이라는 새 파일에 복사합니다.
1. `SSM` 속성에서 `SessionLogsRetentionDurationHours` 값의 기본값을 줄이고 파일을 저장합니다.
1. SSM Agent를 다시 시작합니다.
## StartSession 작업을 호출할 때 오류가 발생합니다(InvalidDocument)
**문제**: AWS CLI을(를) 사용하여 세션을 시작할 때 다음 오류가 발생합니다.
```
An error occurred (InvalidDocument) when calling the StartSession operation: Document type: 'Command' is not supported. Only type: 'Session' is supported for Session Manager.
```
**해결 방법**: `--document-name` 파라미터에 지정한 SSM 문서는 *세션* 문서가 아닙니다. 다음 절차에 따라 AWS Management Console에서 세션 문서의 목록을 봅니다.
**세션 문서 목록 보기**
1. AWS Systems Manager 콘솔([https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/))을 엽니다.
1. 탐색 창에서 **Documents**를 선택합니다.
1. **범주** 목록에서 **세션 문서**를 선택합니다.
# AWS Systems Manager State Manager
AWS Systems Manager의 도구인 State Manager는 안전하고 확장 가능한 구성 관리 서비스로서 관리형 노드 및 다른 AWS 리소스를 사용자가 정의한 상태로 유지하는 프로세스를 자동화합니다. State Manager를 시작하려면 [Systems Manager 콘솔](https://console.aws.amazon.com//systems-manager/state-manager)을 엽니다. 탐색 창에서 **State Manager**를 선택합니다.
**참고**
State Manager 및 Maintenance Windows가 관리형 노드에서 몇 가지 유사한 유형의 업데이트를 수행할 수 있습니다. 어느 유형의 업데이트를 선택할지는 시스템 규정 준수를 자동화해야 하는지 아니면 지정한 기간 동안 우선순위가 높고 시간에 민감한 태스크를 수행해야 하는지 여부에 따라 다릅니다.
자세한 내용은 [State Manager와 Maintenance Windows 중에서 선택](state-manager-vs-maintenance-windows.md) 섹션을 참조하세요.
## State Manager가 조직에 주는 이점은 무엇인가요?
사전 구성된 Systems Manager 문서(SSM 문서)를 사용하면 State Manager에서는 노드를 관리할 때 다음과 같은 이점을 제공합니다.
+ 시작 시 특정 소프트웨어로 노드 부트스트랩
+ 정의된 일정에 따라 SSM Agent를 포함하여 에이전트 다운로드 및 업데이트
+ 네트워크 설정 구성
+ 노드를 Microsoft Active Directory 도메인에 조인합니다.
+ 수명 주기 동안 Linux, macOS 및 Windows Server 관리형 노드에서 스크립트를 실행합니다.
다른 AWS 리소스 간에 구성 드리프트를 관리하기 위해서는 State Manager를 통해 Systems Manager 도구인 Automation을 사용하여 다음과 같은 유형의 작업을 수행할 수 있습니다.
+ Amazon Elastic Compute Cloud(Amazon EC2) 인스턴스에 연결하여 Systems Manager 역할을 *관리형 노드*로 만듭니다.
+ 보안 그룹에 원하는 인바운드 및 아웃바운드 규칙을 적용합니다.
+ Amazon DynamoDB 백업을 생성하거나 삭제합니다.
+ Amazon Elastic Block Store(Amazon EBS) 스냅샷을 생성하거나 삭제합니다.
+ Amazon Simple Storage Service(Amazon S3) 버킷에 대한 읽기 및 쓰기 권한을 해제합니다.
+ 관리형 노드 및 Amazon Relational Database Service(Amazon RDS) 인스턴스를 시작, 재시작 또는 중지합니다.
+ Linux, macOS 및 Window AMIs를 패치합니다.
Automation 실행서를 통한 State Manager 사용 방법에 대한 자세한 내용은 [State Manager 연결을 사용하여 자동화 예약](scheduling-automations-state-manager-associations.md) 섹션을 참조하세요.
## State Manager는 누가 사용해야 하나요?
State Manager는 AWS 리소스의 관리 및 거버넌스를 개선하고 구성 드리프트를 줄이려는 모든 AWS 사용자에게 적합합니다.
## State Manager에는 어떤 기능이 있나요?
State Manager의 주요 기능은 다음과 같습니다.
+
**State Manager 연결**
State Manager *연결*은 사용자가 자신의 AWS 리소스에 할당하는 구성입니다. 이러한 구성은 리소스에서 관리하려는 상태를 정의합니다. 예를 들어, 연결은 관리형 노드에서 안티바이러스 소프트웨어가 설치되어 실행 중이어야 하는지 또는 특정 포트가 닫혀 있어야 하는지를 지정할 수 있습니다.
연결은 구성 및 연결 대상을 적용할 시점의 일정을 지정합니다. 예를 들어, 안티바이러스 소프트웨어에 대한 연결은 AWS 계정의 관리형 노드에서 하루에 한 번 실행할 수 있습니다. 노드에 소프트웨어가 설치되어 있지 않으면 연결은 State Manager에 소프트웨어를 설치하도록 지시할 수 있습니다. 소프트웨어가 설치되어 있으나 서비스가 실행 중이 아닌 경우 연결이 State Manager에 해당 서비스의 시작을 지시할 수 있습니다.
+
**유연한 예약 옵션**
State Manager에서는 연결이 실행될 때 다음과 같은 예약 옵션을 제공합니다.
+ **즉각적인 처리 또는 지연된 처리**
연결을 생성하면 기본적으로 시스템은 지정된 리소스에서 연결을 즉시 실행합니다. 최초 실행 후 연결은 정의한 일정에 따른 간격으로 실행됩니다.
콘솔에서 **지정된 다음 Cron 간격에서만 연결 적용(Apply association only at the next specified Cron interval)** 옵션 또는 명령줄에서 `ApplyOnlyAtCronInterval` 파라미터를 사용하여 즉시 연결을 실행하지 말라고 State Manager에 지시할 수 있습니다.
+ **Cron 및 Rate 표현식**
연결을 생성하는 경우 State Manager이(가) 구성을 적용하는 시기의 일정을 지정합니다. State Manager은(는) 연결이 실행될 때 예약에 대한 가장 표준적인 cron 및 rate 표현식을 지원합니다. State Manager은(는) 또한 요일 및 숫자 기호(\$1)를 포함하는 cron 표현식을 지원하여 매달 *n* 번째 일을 지정하고, 연결 및 (L) 기호를 실행하고, 매월 마지막 *X*일을 지정합니다.
**참고**
State Manager은(는) 현재 연결에 대한 cron 표현식에서 월 지정을 지원하지 않습니다.
예를 들어, 화요일을 패치한 지 2일 후 연결을 실행하려는 경우 연결 실행 시기를 추가로 제어하려면 오프셋을 지정할 수 있습니다. *오프셋*을 통해 연결을 실행하도록 예약된 날짜 이후에 대기할 일 수를 정의할 수 있습니다.
cron 및 rate 표현식 작성에 대한 자세한 내용은 [참조: Systems Manager용 Cron 및 Rate 표현식](reference-cron-and-rate-expressions.md)을(를) 참조하세요.
+
**여러 대상 지정 옵션**
연결은 연결 대상도 지정합니다. State Manager는 태그, AWS Resource Groups, 개별 노드 ID 또는 현재 AWS 리전 및 AWS 계정의 모든 관리형 노드를 사용하여 AWS 리소스를 지원합니다.
+
**Amazon S3 지원**
선택한 Amazon S3 버킷에 연결 실행의 명령 출력을 저장합니다. 자세한 내용은 [Systems Manager에서 연결 작업](state-manager-associations.md) 섹션을 참조하세요.
+
**EventBridge 지원**
이 Systems Manager 도구는 Amazon EventBridge 규칙에서 *이벤트* 유형과 *대상* 유형으로 모두 지원됩니다. 자세한 내용은 [Amazon EventBridge로 Systems Manager 이벤트 모니터링](monitoring-eventbridge-events.md) 및 [참조: Systems Manager용 Amazon EventBridge 이벤트 패턴 및 유형](reference-eventbridge-events.md) 섹션을 참조하세요.
## State Manager를 사용하는 데 비용이 듭니까?
State Manager는 추가 요금 없이 사용할 수 있습니다.
**Topics**
+ [State Manager가 조직에 주는 이점은 무엇인가요?](#state-manager-benefits)
+ [State Manager는 누가 사용해야 하나요?](#state-manager-who)
+ [State Manager에는 어떤 기능이 있나요?](#state-manager-features)
+ [State Manager를 사용하는 데 비용이 듭니까?](#state-manager-cost)
+ [State Manager 작동 방식 이해](state-manager-about.md)
+ [Systems Manager에서 연결 작업](state-manager-associations.md)
+ [MOF 파일을 실행하는 연결 생성](systems-manager-state-manager-using-mof-file.md)
+ [Ansible 플레이북을 실행하는 연결 생성](systems-manager-state-manager-ansible.md)
+ [Chef 레시피를 실행하는 연결 생성](systems-manager-state-manager-chef.md)
+ [연습: AWS CLI를 사용하여 SSM Agent를 자동으로 업데이트](state-manager-update-ssm-agent-cli.md)
+ [연습: Windows Server용 EC2 인스턴스에서 PV 드라이버 자동 업데이트](state-manager-update-pv-drivers.md)
**추가 정보**
+ [Amazon EC2 Systems Manager 및 Windows PowerShell DSC를 사용하여 구성 불일치 방지](https://aws.amazon.com/blogs/mt/combating-configuration-drift-using-amazon-ec2-systems-manager-and-windows-powershell-dsc/)
+ [State Manager를 사용하여 Auto Scaling 그룹에서 Amazon EC2 인스턴스 구성](https://aws.amazon.com/blogs/mt/configure-amazon-ec2-instances-in-an-auto-scaling-group-using-state-manager/)
# State Manager 작동 방식 이해
AWS Systems Manager의 도구인 State Manager는 [하이브리드 및 멀티클라우드](operating-systems-and-machine-types.md#supported-machine-types) 인프라에서 관리형 노드를 사용자가 정의하는 상태로 유지하는 프로세스를 자동화하는 안전하고 확장 가능한 서비스입니다.
State Manager의 작동 방식은 다음과 같습니다.
**1. AWS 리소스에 적용하려는 상태를 결정합니다.**
안티바이러스 또는 멀웨어 애플리케이션 등의 특정 애플리케이션에서 관리형 노드를 구성하도록 하시겠나요? SSM Agent 또는 다른 AWS 패키지(예: `AWSPVDriver`) 업데이트 프로세스를 자동화하고 싶으신가요? 특정 포트가 열려 있거나 닫혀 있도록 해야 하나요? State Manager로 시작하려면 AWS 리소스에 적용하려는 상태를 결정합니다. 적용하려는 상태에 따라 State Manager 연결을 생성하는 데 사용할 SSM 문서가 결정됩니다.
State Manager *연결*은 사용자가 자신의 AWS 리소스에 할당하는 구성입니다. 이러한 구성은 리소스에서 관리하려는 상태를 정의합니다. 예를 들어, 연결은 관리형 노드에서 안티바이러스 소프트웨어가 설치되어 실행 중이어야 하는지 또는 특정 포트가 닫혀 있어야 하는지를 지정할 수 있습니다.
연결은 구성 및 연결 대상을 적용할 시점의 일정을 지정합니다. 예를 들어, 안티바이러스 소프트웨어에 대한 연결은 AWS 계정의 관리형 노드에서 하루에 한 번 실행할 수 있습니다. 노드에 소프트웨어가 설치되어 있지 않으면 연결은 State Manager에 소프트웨어를 설치하도록 지시할 수 있습니다. 소프트웨어가 설치되어 있으나 서비스가 실행 중이 아닌 경우 연결이 State Manager에 해당 서비스의 시작을 지시할 수 있습니다.
**2. 사전 구성된 SSM 문서가 AWS 리소스에서 원하는 상태를 생성하는 데 도움이 되는지 확인합니다.**
Systems Manager에는 연결을 생성하는 데 사용할 수 있는 수십 개의 사전 구성된 SSM 문서가 있습니다. 사전 구성된 문서는 애플리케이션 설치, Amazon CloudWatch 구성, AWS Systems Manager 자동화, PowerShell 및 셸 스크립트 실행, 관리형 노드를 Active Directory의 디렉터리 서비스 도메인에 조인 등의 일반적인 태스크를 수행할 준비가 되어 있습니다.
[Systems Manager 콘솔](https://console.aws.amazon.com/systems-manager/documents)에서 모든 SSM 문서를 볼 수 있습니다. 문서의 이름을 선택하여 각 문서에 대해 자세히 알아봅니다. [https://console.aws.amazon.com/systems-manager/documents/AWS-ConfigureAWSPackage/description](https://console.aws.amazon.com/systems-manager/documents/AWS-ConfigureAWSPackage/description)와 [https://console.aws.amazon.com/systems-manager/documents/AWS-InstallApplication/description](https://console.aws.amazon.com/systems-manager/documents/AWS-InstallApplication/description)의 두 가지 예가 있습니다.
**3. 연결을 생성합니다.**
Systems Manager 콘솔, AWS Command Line Interface(AWS CLI), AWS Tools for Windows PowerShell(Tools for Windows PowerShell) 또는 Systems Manager API를 사용하여 연결을 생성할 수 있습니다. 연결을 생성할 때 다음 정보를 지정할 수 있습니다.
+ 연결의 이름입니다.
+ SSM 문서의 파라미터(예: 설치할 애플리케이션 경로 또는 노드에서 실행할 스크립트)입니다.
+ 연결 대상. 태그를 지정하거나, 개별 인스턴스 ID를 선택하거나, AWS Resource Groups에서 그룹을 선택하여 관리형 노드를 대상으로 지정할 수 있습니다. 현재 AWS 리전 및 AWS 계정의 *모든* 관리형 노드를 대상으로 지정할 수도 있습니다. 대상에 1,000개 이상의 노드가 포함된 경우 시스템은 시간당 스로틀링 메커니즘을 사용합니다. 즉, 집계 프로세스는 노드의 실행 상태가 변경될 때만 시간당 실행되므로 상태 집계 수가 부정확할 수 있습니다.
+ 연결에서 사용자를 대신하여 작업을 수행하는 데 사용하는 역할입니다. State Manager는 이 역할을 수임하고 구성을 노드로 디스패치할 때 필요한 API를 직접 호출합니다. 사용자 지정으로 제공된 역할의 설정에 대한 자세한 내용은 [`AssociationDispatchAssumeRole` 역할 설정](#setup-assume-role) 섹션을 참조하세요. 역할이 제공되지 않으면 [Systems Manager의 서비스 연결 역할](https://docs.aws.amazon.com/systems-manager/latest/userguide/using-service-linked-roles.html)이 사용됩니다.
**참고**
사용자를 대신하여 작업을 수행할 때 State Manager가 갖는 권한을 완전히 제어할 수 있도록 사용자 지정 IAM 역할을 정의하는 것이 좋습니다.
State Manager의 서비스 연결 역할 지원을 단계적으로 중단하고 있습니다. 서비스 연결 역할에 의존하는 연결은 계속 제대로 작동하려면 향후 업데이트가 필요할 수 있습니다.
사용자 지정으로 제공된 역할의 사용 관리에 대한 자세한 내용은 [`ssm:AssociationDispatchAssumeRole`을 사용하여 AssociationDispatchAssumeRole 사용 관리](#context-key-assume-role) 섹션을 참조하세요.
+ 상태를 적용할 시간 또는 빈도에 대한 일정. cron 또는 rate 표현식을 지정할 수 있습니다. cron 및 rate 표현식을 사용하여 일정 생성에 대한 자세한 내용은 [연결에 대한 Cron 및 Rate 표현식](reference-cron-and-rate-expressions.md#reference-cron-and-rate-expressions-association) 섹션을 참조하세요.
**참고**
State Manager은(는) 현재 연결에 대한 cron 표현식에서 월 지정을 지원하지 않습니다.
연결 생성을 위한 명령을 실행하면 Systems Manager는 지정한 정보(일정, 대상, SSM 문서 및 파라미터)를 대상으로 지정된 리소스로 바인딩합니다. 시스템에서 모든 대상에 연결하고 연결에 지정된 상태를 *즉시* 적용하려고 하기 때문에 연결 상태는 처음에 "보류 중"으로 표시됩니다.
이전 연결이 실행 중인 상태에서 실행하도록 예정된 새 연결을 생성하면 이전 연결 시간이 초과되고 새 연결이 실행됩니다.
Systems Manager가 리소스에서 연결을 생성하기 위해 요청 상태를 보고합니다. [DescribeInstanceAssociationsStatus](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_DescribeInstanceAssociationsStatus.html) API 작업을 사용하여 콘솔 또는 (관리형 노드)의 상태 세부 정보를 볼 수 있습니다. 연결을 생성할 때 명령의 출력을 Amazon Simple Storage Service(Amazon S3)에 쓰기로 선택한 경우 지정한 Amazon S3 버킷에서 출력을 볼 수도 있습니다.
자세한 내용은 [Systems Manager에서 연결 작업](state-manager-associations.md) 섹션을 참조하세요.
연결 실행 중에 SSM 문서에 의해 시작된 API 작업은 AWS CloudTrail에 로깅되지 않습니다.
**4. 모니터링 및 업데이트합니다.**
연결을 생성하면 State Manager에서 연결에 정의된 일정에 따라 구성을 다시 적용합니다. 연결 상태는 콘솔의 [State Manager 페이지](https://console.aws.amazon.com/systems-manager/state-manager)에서 보거나 연결 생성 시 Systems Manager가 생성한 연결 ID를 직접 호출하여 볼 수 있습니다. 자세한 내용은 [연결 내역 보기](state-manager-associations-history.md) 섹션을 참조하세요. 연결 문서를 업데이트하고 필요에 따라 다시 적용할 수 있습니다. 여러 버전의 연결을 생성할 수도 있습니다. 자세한 내용은 [새로운 연결 버전 편집 및 생성](state-manager-associations-edit.md) 섹션을 참조하세요.
## 리소스에 연결이 적용되는 시기 이해
연결을 생성할 때 구성, 대상 리소스 목록 및 구성 적용 일정을 정의하는 SSM 문서를 지정합니다. 기본적으로 State Manager에서는 연결을 생성할 때와 이후에는 일정에 따라 연결을 실행합니다. State Manager는 또한 다음과 같은 상황에서 연결을 실행하려고 시도합니다.
+ **연결 편집** - State Manager는 사용자가 `DOCUMENT_VERSION`, `PARAMETERS`, `SCHEDULE_EXPRESSION`, `OUTPUT_S3_LOCATION` 연결 필드를 편집하고 변경 사항을 저장한 후 연결을 실행합니다.
+ **문서 편집** - State Manager는 사용자가 연결 구성 상태를 정의하는 SSM 문서를 편집하고 변경 사항을 저장한 이후에 연결을 실행합니다. 특히 연결은 문서를 다음과 같이 편집한 후에 실행됩니다.
+ 사용자가 새 `$DEFAULT` 문서 버전을 지정하고 `$DEFAULT` 버전을 사용하여 연결을 생성했습니다.
+ 사용자가 문서를 업데이트하고 `$LATEST` 버전을 사용하여 연결을 생성했습니다.
+ 사용자는 연결을 생성할 때 지정된 문서를 삭제합니다.
+ **수동 시작** - State Manager가 사용자가 Systems Manager 콘솔에서 또는 프로그래밍 방식으로 시작한 경우에 연결을 실행합니다.
+ **대상 변경** - State Manager는 대상 노드에서 다음 활동이 발생한 이후에 연결을 실행합니다.
+ 관리형 노드가 처음 온라인 상태로 전환됩니다.
+ 예약된 연결 실행을 지나친 후 관리형 노드가 온라인 상태로 전환됩니다.
+ 30일 넘게 중지된 경우 이후 관리형 노드가 온라인 상태로 전환됩니다.
**참고**
State Manager는 AWS 계정 전반의 연결에 사용되는 문서나 패키지를 모니터링하지 않습니다. 한 계정에서 문서 또는 패키지를 업데이트하는 경우 업데이트로 인해 두 번째 계정에서 연결이 실행되지 않습니다. 두 번째 계정에서 연결을 수동으로 실행해야 합니다.
**대상 변경 시 연결 실행 방지**
경우에 따라 관리형 노드로 구성된 대상이 변경될 때가 아니라, 지정된 일정에 따라 연결을 실행해야 할 수 있습니다.
**참고**
Automation 런북을 실행하면 비용이 발생합니다. Automation 런북과의 연결이 계정의 모든 인스턴스를 대상으로 하고 주기적으로 많은 수의 인스턴스를 시작하는 경우, 런북은 시작 시에 각 인스턴스에서 실행됩니다. 이로 인해 자동화 요금이 증가할 수 있습니다.
해당 연결의 대상이 변경될 때 연결이 실행되지 않도록 하려면, **지정된 다음 cron 간격에서만 연결 적용** 확인란을 선택합니다. 이 확인란은 **연결 생성** 및 **연결 편집** 페이지의 **일정 지정** 영역에 있습니다.
이 옵션은 Automation 런북 또는 SSM 문서를 통합하는 연결에 적용됩니다.
## Automation 런북을 사용한 대상 업데이트 정보
새 대상 노드가 감지될 때 Automation 런북으로 생성된 연결을 적용하려면 다음 조건이 True여야 합니다.
+ 연결은 [Quick Setup](systems-manager-quick-setup.md) 구성에 의해 생성되어야 합니다. Quick Setup은 AWS Systems Manager의 도구입니다. 다른 프로세스에서 생성한 연결은 현재 지원되지 않습니다.
+ Automation 런북은 명시적으로 리소스 유형 `AWS::EC2::Instance` 또는 `AWS::SSM::ManagedInstance`를 대상으로 지정해야 합니다.
+ 연결은 파라미터와 대상을 모두 지정해야 합니다.
콘솔에서 속도 제어 실행을 선택하면 **파라미터** 및 **대상** 필드가 표시됩니다.
![\[파라미터 및 대상 옵션은 속도 제어 실행을 위해 콘솔에 표시됩니다.\]](http://docs.aws.amazon.com/ko_kr/systems-manager/latest/userguide/images/sm_Rate_control_execution_options.png)
[https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreateAssociation.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreateAssociation.html), [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreateAssociationBatch.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreateAssociationBatch.html) 또는 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_UpdateAssociation.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_UpdateAssociation.html) API 작업을 사용하는 경우 `AutomationTargetParameterName` 및 `Targets` 입력을 사용하여 이러한 값을 지정할 수 있습니다. 이러한 각 API 작업에서 `ApplyOnlyAtCronInterval` 파라미터를 `true`로 설정하여 대상이 변경될 때마다 연결이 실행되지 않도록 할 수도 있습니다.
Automation 실행에 따른 예상치 못한 높은 비용을 방지하는 방법을 비롯하여, 콘솔을 사용하여 연결 실행 조건을 제어하는 방법에 대한 자세한 내용은 [리소스에 연결이 적용되는 시기 이해](#state-manager-about-scheduling) 섹션을 참조하세요.
## `AssociationDispatchAssumeRole` 역할 설정
State Manager가 사용자를 대신하여 작업을 수행할 때 수임하는 사용자 지정 디스패치 수임 역할을 설정하려면, 해당 역할은 `ssm.amazonaws.com`을 신뢰하고 연결 사용 사례에 따라 `ssm:SendCommand` 또는 `ssm:StartAutomationExecution`을 호출하는 데 필요한 권한을 보유해야 합니다.
샘플 신뢰 정책:
```
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "",
"Effect": "Allow",
"Principal": {
"Service": [
"ssm.amazonaws.com"
]
},
"Action": "sts:AssumeRole"
}
]
}
```
## `ssm:AssociationDispatchAssumeRole`을 사용하여 AssociationDispatchAssumeRole 사용 관리
State Manager가 사용자를 대신하여 작업을 수행할 때 수임하는 사용자 지정 디스패치 수임 역할의 사용을 관리하려면 `ssm:AssociationDispatchAssumeRole` 조건 키를 사용하세요. 이 조건은 사용자 지정 디스패치 수임 역할을 지정하지 않고 연결을 생성하거나 업데이트할 수 있는지 여부를 제어합니다.
다음 샘플 정책에서 `"Allow"` 문은 `AssociationDispatchAssumeRole` 파라미터가 지정된 경우에만 연결 생성 및 업데이트 API에 대한 권한을 부여합니다. API 요청에 이 파라미터가 없으면 해당 정책은 연결을 생성하거나 업데이트할 수 있는 권한을 부여하지 않습니다.
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ssm:CreateAssociation",
"ssm:UpdateAssociation",
"ssm:CreateAssociationBatch"
],
"Resource": "*",
"Condition": {
"StringLike": {
"ssm:AssociationDispatchAssumeRole": "*"
}
}
}
]
}
```
# Systems Manager에서 연결 작업
이 섹션에서는 AWS Systems Manager 콘솔, AWS Command Line Interface(AWS CLI) 및 AWS Tools for PowerShell을 사용하여 State Manager 연결을 생성하고 관리하는 방법을 설명합니다.
**Topics**
+ [State Manager 연결에서의 대상 및 속도 제어 이해](systems-manager-state-manager-targets-and-rate-controls.md)
+ [연결 생성](state-manager-associations-creating.md)
+ [새로운 연결 버전 편집 및 생성](state-manager-associations-edit.md)
+ [연결 삭제](systems-manager-state-manager-delete-association.md)
+ [연결을 사용하여 Auto Scaling 그룹 실행](systems-manager-state-manager-asg.md)
+ [연결 내역 보기](state-manager-associations-history.md)
+ [IAM을 사용한 연결 작업](systems-manager-state-manager-iam.md)
# State Manager 연결에서의 대상 및 속도 제어 이해
이 주제에서는 예약된 시간에 연결을 실행하는 노드 수를 제어하면서 수십 또는 수백 개의 노드에 대한 연결을 배포하는 데 도움이 되는 State Manager에 대해 설명합니다. State Manager는 AWS Systems Manager의 도구입니다.
## 대상 사용
State Manager 연결을 생성할 때 여기에 표시된 대로 Systems Manager 콘솔의 **대상(Targets)** 섹션에서 연결로 구성할 노드를 선택합니다.
![\[State Manager 연결 생성 시 노드를 대상으로 지정하는 다양한 옵션\]](http://docs.aws.amazon.com/ko_kr/systems-manager/latest/userguide/images/state-manager-targets.png)
AWS Command Line Interface(AWS CLI)와 같은 명령줄 도구를 사용하여 연결을 생성하는 경우 `targets` 파라미터를 지정합니다. 노드를 대상으로 지정하면 개별 노드 ID를 지정하거나 선택할 필요 없이 수십, 수백 또는 수천 개의 노드를 연결로 구성할 수 있습니다.
각 관리형 노드는 최대 20개 연결의 대상이 될 수 있습니다.
연결 생성 시 State Manager에는 다음과 같은 대상 옵션이 포함되어 있습니다.
**태그 지정**
이 옵션을 사용하여 태그 키와 노드에 지정된 태그 값(옵션)을 지정합니다. 요청을 실행하면 시스템은 지정된 태그 키 및 값과 일치하는 모든 노드를 찾아 해당 인스턴스에서 연결을 생성하려고 시도합니다. 여러 태그 값을 지정한 경우 연결은 해당 태그 값 중 적어도 하나 이상이 있는 모든 노드를 대상으로 합니다. 시스템은 처음 연결을 생성할 때 연결을 실행합니다. 이러한 최초 실행 후, 시스템은 사용자가 지정한 일정에 따라 연결을 실행합니다.
새 노드를 생성하고 지정된 태그 키 및 값을 해당 노드에 할당하면, 시스템은 자동으로 연결을 적용하고 즉시 실행하며 그 다음에는 일정에 따라 실행합니다. 이는 연결에서 Command 또는 Policy 문서를 사용하는 경우 적용되며 연결에서 Automation 실행서를 사용하는 경우에는 적용되지 않습니다. 노드에서 지정된 태그를 삭제하면 시스템은 더 이상 해당 노드에서 연결을 실행하지 않습니다.
**참고**
State Manager(으)로 Automation 실행서를 사용하며 태깅 제한으로 인해 특정 목표를 달성할 수 없는 경우 Amazon EventBridge로 Automation 실행서를 사용하는 것을 고려하세요. 자세한 내용은 [EventBridge 이벤트를 기반으로 자동화 실행](running-automations-event-bridge.md) 섹션을 참조하세요. State Manager(으)로 실행서를 사용하는 방법에 대한 자세한 내용은 [State Manager 연결을 사용하여 자동화 예약](scheduling-automations-state-manager-associations.md)을(를) 참조하세요.
명령 또는 정책 문서를 사용하는 연결을 생성할 때 태그를 사용하는 것이 가장 좋습니다. 오토 스케일링을 실행하는 연결을 생성할 때 태그를 사용하는 것도 좋습니다. 자세한 내용은 [연결을 사용하여 Auto Scaling 그룹 실행](systems-manager-state-manager-asg.md) 섹션을 참조하세요.
**참고**
다음 정보를 참고하세요.
AWS Management Console에서 태그를 사용하여 노드를 대상으로 하는 연결을 생성할 때 자동 연결에는 1개의 태그 키만 지정하고 명령 연결에는 5개의 태그 키만 지정할 수 있습니다. 연결에 지정된 *모든* 태그 키가 현재 노드에 할당되어 있어야 합니다. 그렇지 않으면 State Manager에서 노드를 연결 대상으로 지정하지 못합니다.
콘솔을 사용*하고* 자동 연결에 2개 이상의 태그 키를 사용하고 명령 연결에 5개의 태그 키를 사용하여 노드를 대상으로 지정하려면 AWS Resource Groups 그룹에 태그 키를 할당하고 노드를 추가합니다. 그러면 State Manager 연결을 생성할 때 **대상** 목록에서 **리소스 그룹** 옵션을 선택할 수 있습니다.
AWS CLI를 사용하여 최대 5개의 태그 키를 지정할 수 있습니다. AWS CLI를 사용하는 경우 `create-association` 명령에 지정된 *모든* 태그 키가 현재 노드에 할당되어 있어야 합니다. 그렇지 않으면 State Manager에서 노드를 연결 대상으로 지정하지 못합니다.
**수동으로 노드 선택**
이 옵션을 사용하면 연결을 생성하려는 노드를 수동으로 선택할 수 있습니다. **인스턴스(Instances)** 창에는 현재 AWS 계정 및 AWS 리전의 모든 Systems Manager 관리형 노드가 표시됩니다. 노드를 원하는 수만큼 수동으로 선택할 수 있습니다. 시스템은 처음 연결을 생성할 때 연결을 실행합니다. 이러한 최초 실행 후, 시스템은 사용자가 지정한 일정에 따라 연결을 실행합니다.
**참고**
예상한 관리형 노드가 목록에 없으면 [관리형 노드 가용성 문제 해결](fleet-manager-troubleshooting-managed-nodes.md)에서 문제 해결 팁을 참조하세요.
**리소스 그룹 선택**
이 옵션을 사용하면 AWS Resource Groups 태그 기반 또는 AWS CloudFormation 스택 기반 쿼리에서 반환된 모든 노드에서 연결을 생성할 수 있습니다.
다음은 연결을 위해 리소스 그룹을 대상으로 지정하는 방법에 대한 세부 정보입니다.
+ 새 노드를 그룹에 추가하면 시스템은 리소스 그룹을 대상으로 하는 연결에 해당 노드를 자동으로 매핑합니다. 변경 사항이 발견되면 시스템은 노드에 연결을 적용합니다. 이러한 최초 실행 후, 시스템은 사용자가 지정한 일정에 따라 연결을 실행합니다.
+ 리소스 그룹을 대상으로 지정하는 연결을 생성하고 해당 그룹에 대해 `AWS::SSM::ManagedInstance` 리소스 유형을 지정된 경우 [하이브리드 및 멀티클라우드](operating-systems-and-machine-types.md#supported-machine-types) 환경에서 Amazon Elastic Compute Cloud(Amazon EC2) 인스턴스와 비 EC2 노드에서 모두 연결이 실행되도록 설계되어 있습니다.
반대의 경우도 마찬가지입니다. 리소스 그룹을 대상으로 지정하는 연결을 생성하고 해당 그룹에 대해 `AWS::EC2::Instance` 리소스 유형이 지정된 경우 [하이브리드 및 멀티클라우드](operating-systems-and-machine-types.md#supported-machine-types) 환경의 비 EC2 노드와 (Amazon EC2) 인스턴스에서 모두 연결이 실행되도록 설계되어 있습니다.
+ 리소스 그룹을 대상으로 하는 연결을 생성하는 경우 리소스 그룹에 5개 이상의 태그 키가 할당되어 있거나 하나의 태그 키에 대해 5개 이상의 값이 지정되지 않아야 합니다. 이러한 조건 중 하나가 리소스 그룹에 할당된 태그 및 키에 적용되는 경우 연결이 실행되지 않고 `InvalidTarget` 오류를 반환합니다.
+ 태그를 사용하여 리소스 그룹을 대상으로 지정하는 연결을 생성하는 경우 태그 값에 대해 **(빈 값)** 옵션을 선택할 수 없습니다.
+ 리소스 그룹을 삭제하면 해당 그룹의 모든 인스턴스는 더 이상 연결을 실행하지 않습니다. 그룹을 대상으로 하는 연결을 삭제하는 것이 좋습니다.
+ 연결에 대해 단일 리소스 그룹만 대상으로 지정할 수 있습니다. 여러 그룹 또는 중첩된 그룹은 지원되지 않습니다.
+ 연결을 생성한 후 State Manager는 리소스 그룹의 리소스에 대한 정보를 이용해 연결을 주기적으로 업데이트합니다. 새 리소스를 리소스 그룹에 추가하는 경우, 시스템에서 새 리소스에 연결을 적용할 때의 일정은 몇 가지 요소에 따라 다릅니다. Systems Manager 콘솔의 State Manager 페이지에서 연결 상태를 확인할 수 있습니다.
**주의**
Amazon EC2 인스턴스의 리소스 그룹을 대상으로 하는 연결을 생성할 수 있는 권한을 가진 AWS Identity and Access Management(IAM) 사용자, 그룹 또는 역할은 해당 그룹의 모든 인스턴스에 대한 루트 수준 제어 권한을 자동으로 갖습니다. 신뢰할 수 있는 관리자에게만 연결 생성이 허용되어야 합니다.
Resource Groups에 대한 자세한 내용은 *AWS Resource Groups User Guide*의 [What Is AWS Resource Groups?](https://docs.aws.amazon.com/ARG/latest/userguide/)를 참조하세요.
**모든 노드 선택**
이 옵션을 사용하면 현재 AWS 계정 및 AWS 리전의 모든 노드를 대상으로 지정할 수 있습니다. 요청을 실행하면 시스템은 현재 AWS 계정 및 AWS 리전의 모든 노드를 찾아 해당 노드에서 연결을 생성하려고 시도합니다. 시스템은 처음 연결을 생성할 때 연결을 실행합니다. 이러한 최초 실행 후, 시스템은 사용자가 지정한 일정에 따라 연결을 실행합니다. 새 노드를 생성하면, 시스템은 자동으로 연결을 적용하고 즉시 실행하며 그 다음에는 일정에 따라 실행합니다.
## 비율 제어 사용
동시성 값과 오류 임계값을 지정하여 노드에서 연결 실행을 제어할 수 있습니다. 동시성 값은 연결을 동시에 실행할 수 있는 노드의 수를 지정합니다. 오류 임계값은 Systems Manager가 연결 실행을 중지하기 위해 해당 연결로 구성된 각 노드에 명령을 보내기 전에 실패할 수 있는 연결 실행 수를 지정합니다. 이 명령은 다음 예정된 실행까지 연결이 실행되는 것을 중지합니다. 동시성 및 오류 임계값 기능을 통칭하여 *속도 제어*라고 합니다.
![\[State Manager 연결 생성 시 다양한 속도 제어 옵션\]](http://docs.aws.amazon.com/ko_kr/systems-manager/latest/userguide/images/state-manager-rate-controls.png)
**동시성**
동시성은 한 번에 특정한 수의 노드만 연결을 처리하도록 지정하여 노드에 대한 영향을 제한할 수 있습니다. 노드의 절대 개수(예: 20)를 지정하거나 대상 집합의 노드 비율(예: 10%)을 지정할 수 있습니다.
State Manager 동시성에는 다음과 같은 제한 사항이 있습니다.
+ 대상을 사용하여 연결을 생성하도록 선택했으나 동시성 값을 지정하지 않은 경우 State Manager는 최대 동시성으로 노드 50개를 자동으로 적용합니다.
+ 동시성을 사용하는 연결이 실행 중인데 대상 기준을 충족하는 새 노드가 온라인 상태가 되면 동시성 값을 초과하지 않는 경우 새 노드가 연결을 실행합니다. 동시성 값이 초과되면 현재 연결 실행 간격 중에는 새 노드가 무시됩니다. 동시성 요구 사항을 준수할 때 노드는 예약된 다음 간격 중 연결을 실행합니다.
+ 동시성을 사용하는 연결을 업데이트하고 업데이트 시 하나 이상의 노드가 연결을 처리 중이면 연결을 실행 중인 모든 노드를 완료할 수 있습니다. 시작되지 않은 연결은 중지됩니다. 연결이 업데이트되었기 때문에 연결 실행이 완료되면 모든 대상 노드가 즉시 연결을 실행합니다. 연결이 다시 실행되면 동시성 값이 적용됩니다.
**오류 임계값**
오류 임계값은 Systems Manager가 해당 연결로 구성된 각 노드에 명령을 보내기 전에 실패가 허용되는 연결 실행 수를 지정합니다. 이 명령은 다음 예정된 실행까지 연결이 실행되는 것을 중지합니다. 오류의 절대 개수(예: 10개)를 지정하거나 대상 집합의 비율(예: 10%)을 지정할 수 있습니다.
예를 들어, 오류 절대 개수를 3으로 지정한 경우 4번째 오류가 반환되면 State Manager에서는 중지 명령을 전송합니다. 0을 지정하면 첫 번째 오류 결과가 반환된 후 State Manager는 중지 명령을 전송합니다.
예를 들어, 오류 임계값을 50개 연결의 10%로 지정한 경우 6번째 오류가 반환되면 State Manager에서는 중지 명령을 전송합니다. 오류 임계값에 도달했을 때 자동화를 이미 실행 중인 연결은 완료될 수도 있지만, 이러한 연결 중 일부가 실패할 수 있습니다. 오류 수가 오류 임계값에 지정된 수보다 많지 않도록 하려면 연결이 한 번에 하나씩 진행되도록 **동시성** 값을 1로 설정합니다.
State Manager 오류 임계값에는 다음과 같은 제한 및 제약이 있습니다.
+ 오류 임계값은 현재 간격에 대해 적용됩니다.
+ 단계 수준 세부 정보를 비롯해 각 오류에 대한 정보는 연결 내역에 기록됩니다.
+ 대상을 사용하여 연결을 생성하도록 선택했으나 오류 임계값을 지정하지 않은 경우 State Manager에서는 임계값으로 100% 실패를 자동으로 적용합니다.
# 연결 생성
AWS Systems Manager의 도구인 State Manager는 AWS 리소스를 구성 드리프트를 정의하고 줄일 수 있는 상태로 유지하는 데 도움이 됩니다. 이렇게 하기 위해 State Manager는 연결을 사용합니다. *연결*은 사용자가 자신의 AWS 리소스에 할당하는 구성입니다. 이러한 구성은 리소스에서 관리하려는 상태를 정의합니다. 예를 들어, 연결은 관리형 노드에서 안티바이러스 소프트웨어가 설치되어 실행 중이어야 하는지 또는 특정 포트가 닫혀 있어야 하는지를 지정할 수 있습니다.
연결은 구성 및 연결 대상을 적용할 시점의 일정을 지정합니다. 예를 들어, 안티바이러스 소프트웨어에 대한 연결은 AWS 계정의 관리형 노드에서 하루에 한 번 실행할 수 있습니다. 노드에 소프트웨어가 설치되어 있지 않으면 연결은 State Manager에 소프트웨어를 설치하도록 지시할 수 있습니다. 소프트웨어가 설치되어 있으나 서비스가 실행 중이 아닌 경우 연결이 State Manager에 해당 서비스의 시작을 지시할 수 있습니다.
**주의**
연결을 생성하는 경우 연결의 대상으로 관리형 노드의 AWS 리소스 그룹을 선택할 수 있습니다. AWS Identity and Access Management(IAM) 사용자, 그룹 또는 역할이 관리형 노드의 리소스 그룹을 대상으로 하는 연결을 생성할 수 있는 권한을 가진 경우, 해당 사용자, 그룹 또는 역할에는 그룹의 모든 노드에 대한 루트 수준 제어 권한이 자동으로 생깁니다. 신뢰할 수 있는 관리자에게만 연결 생성이 허용됩니다.
**연결 대상 및 속도 제어**
연결은 연결을 수신해야 하는 관리형 노드 또는 대상을 지정할 수 있습니다. State Manager에는 관리형 노드를 대상으로 지정하고 해당 대상으로 연결을 배포하는 방법을 제어하는 데 도움이 되는 몇 가지 기능이 포함되어 있습니다. 대상 및 속도 제어에 대한 자세한 내용은 [State Manager 연결에서의 대상 및 속도 제어 이해](systems-manager-state-manager-targets-and-rate-controls.md) 섹션을 참조하세요.
**연결 태그 지정**
AWS CLI 또는 AWS Tools for PowerShell 등의 명령줄 도구를 사용하여 연결을 생성할 때 연결에 태그를 할당할 수 있습니다. Systems Manager 콘솔을 사용하여 연결에 태그를 추가하는 것은 지원되지 않습니다.
**연결 실행**
기본적으로 State Manager는 연결을 생성한 직후 정의한 일정에 따라 실행합니다.
또한 시스템은 다음 규칙에 따라 연결을 실행합니다.
+ 간격 중에 State Manager는 지정되거나 대상으로 지정된 모든 노드에서 연결을 실행하려고 시도합니다.
+ (예를 들어, 동시성 값이 한 번에 연결을 처리할 수 있는 노드 수를 제한했기 때문에) 간격 동안 연결이 실행되지 않은 경우 State Manager에서는 다음 간격 중 해당 연결을 실행하려고 합니다.
+ State Manager는 연결의 구성, 대상 노드, 문서 또는 파라미터 변경 후 연결을 실행합니다. 자세한 내용은 [리소스에 연결이 적용되는 시기 이해](state-manager-about.md#state-manager-about-scheduling) 섹션을 참조하세요.
+ State Manager는 건너 뛴 모든 간격을 기록합니다. 이러한 기록은 **실행 내역** 탭에서 확인할 수 있습니다.
## 연결 예약
*10시간마다*와 같은 기본 간격으로 실행되도록 연결을 예약하거나 사용자 지정 cron 및 rate 표현식을 사용하여 고급 일정을 생성할 수 있습니다. 연결을 처음 생성할 때 연결이 실행되지 않도록 할 수도 있습니다.
**cron 및 rate 표현식을 사용하여 연결 실행 예약**
표준 cron 또는 rate 표현식 외에도 State Manager는 또한 요일 및 숫자 기호(\$1)를 포함하는 cron 표현식을 지원하여 연결을 실행할 매월 *n*번째 일을 지정할 수 있습니다. 매월 셋째 주 화요일 UTC 23:30에 cron 일정을 실행하는 예는 다음과 같습니다.
`cron(30 23 ? * TUE#3 *)`
매월 두 번째 목요일 UTC 자정에 실행하는 예는 다음과 같습니다.
`cron(0 0 ? * THU#2 *)`
또한 State Manager는 (L) 기호를 지원하여 매월 마지막 *X* 일을 표시합니다. 매월 마지막 화요일 UTC 자정에 cron 일정을 실행하는 예는 다음과 같습니다.
`cron(0 0 ? * 3L *)`
예를 들어, 화요일을 패치한 지 2일 후 연결을 실행하려는 경우 연결 실행 시기를 추가로 제어하려면 오프셋을 지정할 수 있습니다. *오프셋*을 통해 연결을 실행하도록 예약된 날짜 이후에 대기할 일 수를 정의할 수 있습니다. 예를 들어, `cron(0 0 ? * THU#2 *)`의 cron 일정을 지정한 경우 **일정 오프셋** 필드에 숫자 3을 지정하여 매월 두 번째 목요일 이후 매주 일요일에 연결을 실행할 수 있습니다.
**참고**
오프셋을 사용하려면 콘솔에서 **지정된 다음 Cron 간격에서만 연결 적용**을 선택하거나 명령줄에서 `ApplyOnlyAtCronInterval` 파라미터를 지정해야 합니다. 이러한 옵션 중 하나가 활성화되면 연결을 생성한 직후 State Manager가 연결을 실행하지 않습니다.
Cron 및 Rate 표현식에 대한 자세한 내용은 [참조: Systems Manager용 Cron 및 Rate 표현식](reference-cron-and-rate-expressions.md) 섹션을 참조하세요.
## 연결 생성(콘솔)
다음 절차에서는 Systems Manager 콘솔을 사용하여 State Manager 연결을 생성하는 방법을 설명합니다.
**참고**
다음 정보를 참고하세요.
이 절차에서는 `Command` 또는 `Policy` 문서를 사용하는 연결을 생성하여 관리형 노드를 대상으로 지정하는 방법에 대해 설명합니다. Automation 런북을 사용하는 연결을 생성하여 노드 또는 다른 유형의 AWS 리소스를 대상 지정하는 방법에 대한 자세한 내용은 [State Manager 연결을 사용하여 자동화 예약](scheduling-automations-state-manager-associations.md) 섹션을 참조하세요.
연결을 생성할 때 AWS Management Console을 사용하여 최대 5개의 태그 키를 지정할 수 있습니다. 연결에 지정된 *모든* 태그 키가 현재 노드에 할당되어 있어야 합니다. 그렇지 않은 경우 State 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. **연결 생성**을 선택합니다.
1. **이름(Name)** 필드에 이름을 지정합니다.
1. **문서** 목록에서 문서 이름 옆에 있는 옵션을 선택합니다. 문서 유형을 적어둡니다. 이 절차는 `Command` 및 `Policy` 문서에 적용됩니다. Automation 런북을 사용하는 연결 생성에 대한 자세한 내용은 [State Manager 연결을 사용하여 자동화 예약](scheduling-automations-state-manager-associations.md) 섹션을 참조하세요.
**중요**
State Manager는 해당 문서가 다른 계정에서 공유되는 경우 새 버전의 문서를 사용하는 연결 실행을 지원하지 않습니다. Systems Manager 콘솔이 새로운 버전이 처리되었음을 보여주더라도 상태 관리자는 언제나 다른 계정에서 공유된 문서의 `default` 버전을 실행합니다. 다른 계정에서 공유한 문서의 새 버전을 사용하여 연결을 실행하려면 문서 버전을 `default`로 설정해야 합니다.
1. **파라미터**에서 필요한 입력 파라미터를 지정합니다.
1. (선택 사항) **연결 디스패치 역할 수임**의 드롭다운에서 역할을 선택합니다. State Manager는 사용자를 대신하여 이 역할을 사용해 작업을 수행합니다. 사용자 지정으로 제공된 역할의 설정에 대한 자세한 내용은 [`AssociationDispatchAssumeRole` 역할 설정](state-manager-about.md#setup-assume-role) 섹션을 참조하세요.
**참고**
사용자를 대신하여 작업을 수행할 때 State Manager가 갖는 권한을 완전히 제어할 수 있도록 사용자 지정 IAM 역할을 정의하는 것이 좋습니다.
State Manager의 서비스 연결 역할 지원을 단계적으로 중단하고 있습니다. 서비스 연결 역할에 의존하는 연결은 계속 제대로 작동하려면 향후 업데이트가 필요할 수 있습니다.
사용자 지정으로 제공된 역할의 사용 관리에 대한 자세한 내용은 [`ssm:AssociationDispatchAssumeRole`을 사용하여 AssociationDispatchAssumeRole 사용 관리](state-manager-about.md#context-key-assume-role) 섹션을 참조하세요.
1. (선택 사항) 모니터링을 위해 연결에 적용할 CloudWatch 경보를 선택합니다.
**참고**
이 단계에 대한 다음 정보를 참조하세요.
알람 목록에는 최대 100개의 알람이 표시됩니다. 목록에 해당 경보가 표시되지 않으면 AWS Command Line Interface를 사용하여 연결을 생성합니다. 자세한 내용은 [연결 생성(명령줄)](#create-state-manager-association-commandline) 섹션을 참조하세요.
CloudWatch 경보를 명령에 연결하려면 연결을 생성하는 IAM 보안 주체에 `iam:createServiceLinkedRole` 작업에 대한 권한이 있어야 합니다. CloudWatch 경보에 대한 자세한 내용은 [Amazon CloudWatch 경보 사용](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)을 참조하세요.
경보가 활성화되면 보류 중인 명령 호출 또는 자동화가 실행되지 않습니다.
1. **대상**에서 옵션을 선택합니다. 태그 사용에 대한 자세한 내용은 [State Manager 연결에서의 대상 및 속도 제어 이해](systems-manager-state-manager-targets-and-rate-controls.md) 섹션을 참조하세요.
**참고**
새 대상 노드가 감지될 때 Automation 런북을 사용하여 생성된 연결을 적용하려면 특정 조건을 충족해야 합니다. 자세한 내용은 [Automation 런북을 사용한 대상 업데이트 정보](state-manager-about.md#runbook-target-updates) 섹션을 참조하세요.
1. **일정 지정** 섹션에서 **On Schedule(일정이 있을 때)** 또는 **No schedule(일정이 없을 때)**을 선택합니다. **On Schedule(일정이 있을 때)**을 선택한 경우 제공된 버튼을 사용하여 연결에 대한 cron 또는 rate 일정을 생성합니다.
연결을 생성한 직후에 연결을 실행하지 않으려면 **지정된 다음 Cron 간격에서만 연결 적용을** 선택합니다.
1. (선택 사항) **일정 오프셋(Schedule offset)** 필드에 1에서 6 사이의 숫자를 지정합니다.
1. [**고급 옵션(Advanced options)**] 섹션에서 [**규정 준수 심각도(Compliance severity)**]를 사용하여 연결의 심각도 수준을 선택하고 [**변경 일정(Change Calendars)**]을 사용하여 연결의 변경 일정을 선택합니다.
규정 준수 보고는 여기서 지정한 심각도 수준과 함께 연결 상태가 준수인지 아니면 미준수인지를 나타냅니다. 자세한 내용은 [State Manager 연결 규정 준수 정보](compliance-about.md#compliance-about-association) 섹션을 참조하세요.
변경 일정에 따라 연결 실행 시기가 결정됩니다. 일정이 닫혀 있으면 연결이 적용되지 않습니다. 일정이 열려 있으면 그에 따라 연결이 실행됩니다. 자세한 내용은 [AWS Systems Manager Change Calendar](systems-manager-change-calendar.md) 섹션을 참조하세요.
1. **속도 제어(Rate control)** 섹션의 여러 노드에서 연결을 실행하는 방법을 제어하는 옵션을 선택합니다. 속도 제어 사용에 대한 자세한 내용은 [State Manager 연결에서의 대상 및 속도 제어 이해](systems-manager-state-manager-targets-and-rate-controls.md) 섹션을 참조하세요.
**동시성** 섹션에서 옵션을 선택합니다.
+ **대상**을 선택하여 연결을 동시에 실행할 수 있는 대상 수(절대 개수)를 입력합니다.
+ **백분율**을 선택하여 연결을 동시에 실행할 수 있는 대상의 백분율을 입력합니다.
**오류 임계값** 섹션에서 옵션을 선택합니다.
+ **오류**를 선택하여 State Manager에서 추가 대상에 대한 연결 실행을 중지하기 전에 허용되는 절대 오류 수를 입력합니다.
+ **백분율**을 선택하여 State Manager에서 추가 대상에 대한 연결 실행을 중지하기 전에 허용되는 오류 비율을 입력합니다.
1. (선택 사항) **출력 옵션**에서 명령 출력을 파일에 저장하려면 **S3 버킷에 쓰기 활성화** 옆의 상자를 선택합니다. 상자에 버킷 및 접두사(폴더) 이름을 입력합니다.
**참고**
데이터를 S3 버킷에 쓰는 기능을 부여하는 S3 권한은 이 작업을 수행하는 IAM 사용자의 권한이 아닌 관리형 노드에 할당된 인스턴스 프로파일의 권한입니다. 자세한 내용은 [Systems Manager에 필요한 인스턴스 권한 구성](setup-instance-permissions.md)이나 [하이브리드 환경을 위한 IAM 서비스 역할 생성](hybrid-multicloud-service-role.md)을 참조하세요. 또한 지정된 S3 버킷이 다른 AWS 계정에 있는 경우 관리형 노드와 연결된 인스턴스 프로파일 또는 IAM 서비스 역할은 해당 버킷에 쓸 수 있는 권한이 있어야 합니다.
다음은 연결에 대해 Amazon S3 출력을 설정하는 데 필요한 최소 권한입니다. IAM 정책을 계정 내의 사용자 또는 역할에 연결하여 액세스를 추가로 제한할 수 있습니다. 최소한 Amazon EC2 인스턴스 프로파일에는 `AmazonSSMManagedInstanceCore` 관리형 정책과 다음 인라인 정책이 포함된 IAM 역할이 있어야 합니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:PutObject",
"s3:GetObject",
"s3:PutObjectAcl"
],
"Resource": "arn:aws:s3:::amzn-s3-demo-bucket/*"
}
]
}
```
------
최소 권한을 위해 내보내는 Amazon S3 버킷에 Amazon S3 콘솔에서 정의한 기본 설정이 있어야 합니다. Amazon S3 버킷 생성에 대한 자세한 내용은 *Amazon S3 사용 설명서*의 [버킷 생성](https://docs.aws.amazon.com/AmazonS3/latest/userguide/create-bucket-overview.html)을 참조하세요.
**참고**
연결 실행 중에 SSM 문서에 의해 시작된 API 작업은 AWS CloudTrail에 로깅되지 않습니다.
1. **연결 생성**을 선택합니다.
**참고**
생성한 연결을 삭제하면 연결은 더 이상 해당 연결의 대상에서 실행되지 않습니다.
## 연결 생성(명령줄)
다음 절차에서는 AWS CLI(Linux 또는 Windows Server) 또는 Tools for PowerShell을 사용하여 State Manager 연결을 생성하는 방법을 설명합니다. 이 섹션에는 대상 및 속도 제어를 사용하는 방법을 보여주는 몇 가지 예제가 포함되어 있습니다. 대상 및 속도 제어를 사용하면 수십 또는 수백 개의 노드에 연결을 할당하면서 이러한 연결의 실행을 제어할 수 있습니다. 대상 및 속도 제어에 대한 자세한 내용은 [State Manager 연결에서의 대상 및 속도 제어 이해](systems-manager-state-manager-targets-and-rate-controls.md) 섹션을 참조하세요.
**중요**
이 절차에서는 `Command` 또는 `Policy` 문서를 사용하는 연결을 생성하여 관리형 노드를 대상으로 지정하는 방법에 대해 설명합니다. Automation 런북을 사용하는 연결을 생성하여 노드 또는 다른 유형의 AWS 리소스를 대상 지정하는 방법에 대한 자세한 내용은 [State Manager 연결을 사용하여 자동화 예약](scheduling-automations-state-manager-associations.md) 섹션을 참조하세요.
**시작하기 전 준비 사항**
`targets` 파라미터는 지정한 `Key`-`Value` 조합을 사용하여 노드를 대상으로 지정하는 검색 조건의 배열입니다. `targets` 파라미터를 사용하여 수십 또는 수백 개의 노드에서 연결을 생성하려는 경우, 절차를 시작하기 전에 다음의 대상 지정 옵션을 검토하세요.
ID를 지정하여 특정 노드를 대상으로 지정
```
--targets Key=InstanceIds,Values=instance-id-1,instance-id-2,instance-id-3
```
```
--targets Key=InstanceIds,Values=i-02573cafcfEXAMPLE,i-0471e04240EXAMPLE,i-07782c72faEXAMPLE
```
태그를 사용하여 인스턴스를 대상으로 지정
```
--targets Key=tag:tag-key,Values=tag-value-1,tag-value-2,tag-value-3
```
```
--targets Key=tag:Environment,Values=Development,Test,Pre-production
```
AWS Resource Groups를 사용하여 노드 대상 지정
```
--targets Key=resource-groups:Name,Values=resource-group-name
```
```
--targets Key=resource-groups:Name,Values=WindowsInstancesGroup
```
현재 AWS 계정 및 AWS 리전의 모든 인스턴스를 대상으로 지정
```
--targets Key=InstanceIds,Values=*
```
**참고**
다음 정보를 참고하세요.
State Manager는 해당 문서가 다른 계정에서 공유되는 경우 새 버전의 문서를 사용하는 연결 실행을 지원하지 않습니다. Systems Manager 콘솔이 새로운 버전이 처리되었음을 보여주더라도 상태 관리자는 언제나 다른 계정에서 공유된 문서의 `default` 버전을 실행합니다. 다른 계정에서 새 버전의 문서 공유 양식을 사용하여 연결을 실행하려면 문서 버전을 `default`로 설정해야 합니다.
State Manager는 [TargetLocation](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_TargetLocation.html)에 `IncludeChildOrganizationUnits`, `ExcludeAccounts`, `TargetsMaxErrors`, `TargetsMaxConcurrency`, `Targets`, `TargetLocationAlarmConfiguration` 파라미터를 지원하지 않습니다.
AWS CLI를 사용하여 최대 5개의 태그 키를 지정할 수 있습니다. AWS CLI를 사용하는 경우 `create-association` 명령에 지정된 *모든* 태그 키가 현재 노드에 할당되어 있어야 합니다. 그렇지 않으면 State Manager에서 노드를 연결 대상으로 지정하지 못합니다.
연결을 생성할 때 언제 일정을 실행할지 지정합니다. Cron 및 Rate 표현식을 사용하여 일정을 지정합니다. Cron 및 Rate 표현식에 대한 자세한 내용은 [연결에 대한 Cron 및 Rate 표현식](reference-cron-and-rate-expressions.md#reference-cron-and-rate-expressions-association) 섹션을 참조하세요.
새 대상 노드가 감지될 때 Automation 런북을 사용하여 생성된 연결을 적용하려면 특정 조건을 충족해야 합니다. 자세한 내용은 [Automation 런북을 사용한 대상 업데이트 정보](state-manager-about.md#runbook-target-updates) 섹션을 참조하세요.
**연결을 생성하려면**
1. 아직 하지 않은 경우 AWS CLI 또는 AWS Tools for PowerShell을 설치하고 구성합니다.
자세한 내용은 [최신 버전의 AWS CLI 설치 또는 업데이트](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html) 및 [AWS Tools for PowerShell 설치](https://docs.aws.amazon.com/powershell/latest/userguide/pstools-getting-set-up.html)를 참조하세요.
1. 다음 형식을 사용하여 State Manager 연결을 생성하는 명령을 만듭니다. 각 *example resource placeholder*를 사용자의 정보로 바꿉니다.
------
#### [ Linux & macOS ]
```
aws ssm create-association \
--name document_name \
--document-version version_of_document_applied \
--instance-id instances_to_apply_association_on \
--parameters (if any) \
--targets target_options \
--association-dispatch-assume-role arn_of_role_to_be_used_when_dispatching_configurations \
--schedule-expression "cron_or_rate_expression" \
--apply-only-at-cron-interval required_parameter_for_schedule_offsets \
--schedule-offset number_between_1_and_6 \
--output-location s3_bucket_to_store_output_details \
--association-name association_name \
--max-errors a_number_of_errors_or_a_percentage_of_target_set \
--max-concurrency a_number_of_instances_or_a_percentage_of_target_set \
--compliance-severity severity_level \
--calendar-names change_calendar_names \
--target-locations aws_region_or_account \
--tags "Key=tag_key,Value=tag_value"
```
------
#### [ Windows ]
```
aws ssm create-association ^
--name document_name ^
--document-version version_of_document_applied ^
--instance-id instances_to_apply_association_on ^
--parameters (if any) ^
--targets target_options ^
--association-dispatch-assume-role arn_of_role_to_be_used_when_dispatching_configurations ^
--schedule-expression "cron_or_rate_expression" ^
--apply-only-at-cron-interval required_parameter_for_schedule_offsets ^
--schedule-offset number_between_1_and_6 ^
--output-location s3_bucket_to_store_output_details ^
--association-name association_name ^
--max-errors a_number_of_errors_or_a_percentage_of_target_set ^
--max-concurrency a_number_of_instances_or_a_percentage_of_target_set ^
--compliance-severity severity_level ^
--calendar-names change_calendar_names ^
--target-locations aws_region_or_account ^
--tags "Key=tag_key,Value=tag_value"
```
------
#### [ PowerShell ]
```
New-SSMAssociation `
-Name document_name `
-DocumentVersion version_of_document_applied `
-InstanceId instances_to_apply_association_on `
-Parameters (if any) `
-Target target_options `
-AssociationDispatchAssumeRole arn_of_role_to_be_used_when_dispatching_configurations `
-ScheduleExpression "cron_or_rate_expression" `
-ApplyOnlyAtCronInterval required_parameter_for_schedule_offsets `
-ScheduleOffSet number_between_1_and_6 `
-OutputLocation s3_bucket_to_store_output_details `
-AssociationName association_name `
-MaxError a_number_of_errors_or_a_percentage_of_target_set
-MaxConcurrency a_number_of_instances_or_a_percentage_of_target_set `
-ComplianceSeverity severity_level `
-CalendarNames change_calendar_names `
-TargetLocations aws_region_or_account `
-Tags "Key=tag_key,Value=tag_value"
```
------
다음 예제에서는 `"Environment,Linux"` 태그가 지정된 노드에 대해 연결을 생성합니다. 이 연결은 `AWS-UpdateSSMAgent` 문서를 사용하여 매주 일요일 오전 2시(협정 세계 표준시(UTC))에 대상 노드에 대해 SSM Agent를 업데이트합니다. 이 연결은 주어진 시간에 최대 10개의 노드에서 동시에 실행됩니다. 또한 이 연결은 오류 수가 5를 초과하는 경우 특정 실행 간격에 대해 더 많은 노드에서 실행을 중지합니다. 규정 준수 보고를 위해 이 연결에는 중간 심각도 수준이 할당됩니다.
------
#### [ Linux & macOS ]
```
aws ssm create-association \
--association-name Update_SSM_Agent_Linux \
--targets Key=tag:Environment,Values=Linux \
--name AWS-UpdateSSMAgent \
--association-dispatch-assume-role arn:aws:iam::123456789012:role/myAssociationDispatchAssumeRole \
--compliance-severity "MEDIUM" \
--schedule-expression "cron(0 2 ? * SUN *)" \
--max-errors "5" \
--max-concurrency "10"
```
------
#### [ Windows ]
```
aws ssm create-association ^
--association-name Update_SSM_Agent_Linux ^
--targets Key=tag:Environment,Values=Linux ^
--name AWS-UpdateSSMAgent ^
--association-dispatch-assume-role arn:aws:iam::123456789012:role/myAssociationDispatchAssumeRole ^
--compliance-severity "MEDIUM" ^
--schedule-expression "cron(0 2 ? * SUN *)" ^
--max-errors "5" ^
--max-concurrency "10"
```
------
#### [ PowerShell ]
```
New-SSMAssociation `
-AssociationName Update_SSM_Agent_Linux `
-Name AWS-UpdateSSMAgent `
-AssociationDispatchAssumeRole "arn:aws:iam::123456789012:role/myAssociationDispatchAssumeRole" `
-Target @{
"Key"="tag:Environment"
"Values"="Linux"
} `
-ComplianceSeverity MEDIUM `
-ScheduleExpression "cron(0 2 ? * SUN *)" `
-MaxConcurrency 10 `
-MaxError 5
```
------
다음 예는 와일드카드 값(\$1)을 지정하여 노드 ID를 대상으로 지정합니다. 이를 통해 Systems Manager는 현재 AWS 계정 및 AWS 리전의 *모든* 노드에 대한 연결을 생성할 수 있습니다. 이 연결은 주어진 시간에 최대 10개의 노드에서 동시에 실행됩니다. 또한 이 연결은 오류 수가 5를 초과하는 경우 특정 실행 간격에 대해 더 많은 노드에서 실행을 중지합니다. 규정 준수 보고를 위해 이 연결에는 중간 심각도 수준이 할당됩니다. 이 연결에서는 일정 오프셋을 사용합니다. 즉, 지정된 cron 일정 2일 후에 실행됩니다. 또한 `ApplyOnlyAtCronInterval` 파라미터를 포함하며, 이 파라미터는 일정 오프셋을 사용하는 데 필요합니다. 즉, 연결은 생성된 직후에는 실행되지 않습니다.
------
#### [ Linux & macOS ]
```
aws ssm create-association \
--association-name Update_SSM_Agent_Linux \
--name "AWS-UpdateSSMAgent" \
--association-dispatch-assume-role arn:aws:iam::123456789012:role/myAssociationDispatchAssumeRole \
--targets "Key=instanceids,Values=*" \
--compliance-severity "MEDIUM" \
--schedule-expression "cron(0 2 ? * SUN#2 *)" \
--apply-only-at-cron-interval \
--schedule-offset 2 \
--max-errors "5" \
--max-concurrency "10" \
```
------
#### [ Windows ]
```
aws ssm create-association ^
--association-name Update_SSM_Agent_Linux ^
--name "AWS-UpdateSSMAgent" ^
--association-dispatch-assume-role arn:aws:iam::123456789012:role/myAssociationDispatchAssumeRole ^
--targets "Key=instanceids,Values=*" ^
--compliance-severity "MEDIUM" ^
--schedule-expression "cron(0 2 ? * SUN#2 *)" ^
--apply-only-at-cron-interval ^
--schedule-offset 2 ^
--max-errors "5" ^
--max-concurrency "10" ^
--apply-only-at-cron-interval
```
------
#### [ PowerShell ]
```
New-SSMAssociation `
-AssociationName Update_SSM_Agent_All `
-Name AWS-UpdateSSMAgent `
-AssociationDispatchAssumeRole "arn:aws:iam::123456789012:role/myAssociationDispatchAssumeRole" `
-Target @{
"Key"="InstanceIds"
"Values"="*"
} `
-ScheduleExpression "cron(0 2 ? * SUN#2 *)" `
-ApplyOnlyAtCronInterval `
-ScheduleOffset 2 `
-MaxConcurrency 10 `
-MaxError 5 `
-ComplianceSeverity MEDIUM `
-ApplyOnlyAtCronInterval
```
------
다음 예에서는 Resource Groups의 노드에 연결을 생성합니다. 그룹 이름은 "HR-Department"입니다. 이 연결은 `AWS-UpdateSSMAgent` 문서를 사용하여 매주 일요일 오전 2시(협정 세계 표준시(UTC))에 대상 노드에 대해 SSM Agent를 업데이트합니다. 이 연결은 주어진 시간에 최대 10개의 노드에서 동시에 실행됩니다. 또한 이 연결은 오류 수가 5를 초과하는 경우 특정 실행 간격에 대해 더 많은 노드에서 실행을 중지합니다. 규정 준수 보고를 위해 이 연결에는 중간 심각도 수준이 할당됩니다. 이 연결은 지정된 cron 일정에서 실행됩니다. 연결이 생성된 직후에는 실행되지 않습니다.
------
#### [ Linux & macOS ]
```
aws ssm create-association \
--association-name Update_SSM_Agent_Linux \
--targets Key=resource-groups:Name,Values=HR-Department \
--name AWS-UpdateSSMAgent \
--association-dispatch-assume-role arn:aws:iam::123456789012:role/myAssociationDispatchAssumeRole \
--compliance-severity "MEDIUM" \
--schedule-expression "cron(0 2 ? * SUN *)" \
--max-errors "5" \
--max-concurrency "10" \
--apply-only-at-cron-interval
```
------
#### [ Windows ]
```
aws ssm create-association ^
--association-name Update_SSM_Agent_Linux ^
--targets Key=resource-groups:Name,Values=HR-Department ^
--name AWS-UpdateSSMAgent ^
-association-dispatch-assume-role arn:aws:iam::123456789012:role/myAssociationDispatchAssumeRole ^
--compliance-severity "MEDIUM" ^
--schedule-expression "cron(0 2 ? * SUN *)" ^
--max-errors "5" ^
--max-concurrency "10" ^
--apply-only-at-cron-interval
```
------
#### [ PowerShell ]
```
New-SSMAssociation `
-AssociationName Update_SSM_Agent_Linux `
-Name AWS-UpdateSSMAgent `
-AssociationDispatchAssumeRole "arn:aws:iam::123456789012:role/myAssociationDispatchAssumeRole" `
-Target @{
"Key"="resource-groups:Name"
"Values"="HR-Department"
} `
-ScheduleExpression "cron(0 2 ? * SUN *)" `
-MaxConcurrency 10 `
-MaxError 5 `
-ComplianceSeverity MEDIUM `
-ApplyOnlyAtCronInterval
```
------
다음 예에서는 특정 노드 ID로 태그가 지정된 노드에서 실행되는 연결을 생성합니다. 연결은 변경 일정이 열려 있을 때 SSM Agent 문서를 사용하여 대상 노드에서 SSM Agent를 한 번 업데이트합니다. 연결은 실행 시 일정 상태를 확인합니다. 시작 시 일정이 닫혀 있고 연결이 한 번만 실행되면 연결 실행 기간이 지나므로 열결이 다시 실행되지 않습니다. 일정이 열려 있으면 그에 따라 연결이 실행됩니다.
**참고**
변경 일정이 닫힐 때 연결이 작동하는 태그 또는 리소스 그룹에 새 노드를 추가하는 경우 변경 일정이 열리면 연결이 해당 노드에 적용됩니다.
------
#### [ Linux & macOS ]
```
aws ssm create-association \
--association-name CalendarAssociation \
--targets "Key=instanceids,Values=i-0cb2b964d3e14fd9f" \
--name AWS-UpdateSSMAgent \
--association-dispatch-assume-role arn:aws:iam::123456789012:role/myAssociationDispatchAssumeRole \
--calendar-names "arn:aws:ssm:us-east-1:123456789012:document/testCalendar1" \
--schedule-expression "rate(1day)"
```
------
#### [ Windows ]
```
aws ssm create-association ^
--association-name CalendarAssociation ^
--targets "Key=instanceids,Values=i-0cb2b964d3e14fd9f" ^
--name AWS-UpdateSSMAgent ^
--association-dispatch-assume-role arn:aws:iam::123456789012:role/myAssociationDispatchAssumeRole ^
--calendar-names "arn:aws:ssm:us-east-1:123456789012:document/testCalendar1" ^
--schedule-expression "rate(1day)"
```
------
#### [ PowerShell ]
```
New-SSMAssociation `
-AssociationName CalendarAssociation `
-Target @{
"Key"="tag:instanceids"
"Values"="i-0cb2b964d3e14fd9f"
} `
-Name AWS-UpdateSSMAgent `
-AssociationDispatchAssumeRole "arn:aws:iam::123456789012:role/myAssociationDispatchAssumeRole" `
-CalendarNames "arn:aws:ssm:us-east-1:123456789012:document/testCalendar1" `
-ScheduleExpression "rate(1day)"
```
------
다음 예에서는 특정 노드 ID로 태그가 지정된 노드에서 실행되는 연결을 생성합니다. 이 연결은 SSM Agent 문서를 사용하여 매주 일요일 오전 2시에 대상 노드에 대해 SSM Agent를 업데이트합니다. 이 연결은 변경 일정이 열려 있을 때 지정된 cron 일정에서만 실행됩니다. 연결은 생성 시 일정 상태를 확인합니다. 일정이 닫혀 있으면 연결이 적용되지 않습니다. 연결 적용 간격이 일요일 오전 2시에 시작되면 연결은 달력이 열려 있는지 확인합니다. 일정이 열려 있으면 그에 따라 연결이 실행됩니다.
**참고**
변경 일정이 닫힐 때 연결이 작동하는 태그 또는 리소스 그룹에 새 노드를 추가하는 경우 변경 일정이 열리면 연결이 해당 노드에 적용됩니다.
------
#### [ Linux & macOS ]
```
aws ssm create-association \
--association-name MultiCalendarAssociation \
--targets "Key=instanceids,Values=i-0cb2b964d3e14fd9f" \
--name AWS-UpdateSSMAgent \
--association-dispatch-assume-role arn:aws:iam::123456789012:role/myAssociationDispatchAssumeRole \
--calendar-names "arn:aws:ssm:us-east-1:123456789012:document/testCalendar1" "arn:aws:ssm:us-east-2:123456789012:document/testCalendar2" \
--schedule-expression "cron(0 2 ? * SUN *)"
```
------
#### [ Windows ]
```
aws ssm create-association ^
--association-name MultiCalendarAssociation ^
--targets "Key=instanceids,Values=i-0cb2b964d3e14fd9f" ^
--name AWS-UpdateSSMAgent ^
--association-dispatch-assume-role arn:aws:iam::123456789012:role/myAssociationDispatchAssumeRole ^
--calendar-names "arn:aws:ssm:us-east-1:123456789012:document/testCalendar1" "arn:aws:ssm:us-east-2:123456789012:document/testCalendar2" ^
--schedule-expression "cron(0 2 ? * SUN *)"
```
------
#### [ PowerShell ]
```
New-SSMAssociation `
-AssociationName MultiCalendarAssociation `
-Name AWS-UpdateSSMAgent `
-AssociationDispatchAssumeRole "arn:aws:iam::123456789012:role/myAssociationDispatchAssumeRole" `
-Target @{
"Key"="tag:instanceids"
"Values"="i-0cb2b964d3e14fd9f"
} `
-CalendarNames "arn:aws:ssm:us-east-1:123456789012:document/testCalendar1" "arn:aws:ssm:us-east-2:123456789012:document/testCalendar2" `
-ScheduleExpression "cron(0 2 ? * SUN *)"
```
------
**참고**
생성한 연결을 삭제하면 연결은 더 이상 해당 연결의 대상에서 실행되지 않습니다. 또한 `apply-only-at-cron-interval` 파라미터를 지정한 경우 이 옵션을 재설정할 수 있습니다. 이렇게 하려면 명령줄에서 연결을 업데이트할 때 `no-apply-only-at-cron-interval` 파라미터를 지정합니다. 이 파라미터는 연결을 업데이트한 직후 지정된 간격에 따라 연결을 강제로 실행합니다.
# 새로운 연결 버전 편집 및 생성
State Manager 연결을 편집하여 새 이름, 일정, 심각도 수준, 대상 또는 기타 값을 지정할 수 있습니다. SSM Command 유형 문서 기반 연결인 경우 명령의 출력을 Amazon Simple Storage Service(S3) 버킷에 쓰도록 선택할 수도 있습니다. 연결을 편집하면 State Manager에서 새로운 버전을 생성합니다. 다음 절차에 설명된 대로 편집 후에 다른 버전이 표시될 수 있습니다.
**참고**
새 대상 노드가 감지될 때 Automation 런북을 사용하여 생성된 연결을 적용하려면 특정 조건을 충족해야 합니다. 자세한 내용은 [Automation 런북을 사용한 대상 업데이트 정보](state-manager-about.md#runbook-target-updates) 섹션을 참조하세요.
다음 절차에서는 Systems Manager 콘솔, AWS Command Line Interface(AWS CLI) 및 AWS Tools for PowerShell(Tools for PowerShell)을 사용하여 새로운 연결 버전을 편집하고 생성하는 방법을 설명합니다.
**중요**
State Manager는 해당 문서가 다른 계정에서 공유되는 경우 새 버전의 문서를 사용하는 연결 실행을 지원하지 않습니다. State Manager는 Systems Manager 콘솔이 새 버전이 처리되었음을 보여주더라도 다른 계정에서 공유된 경우 문서의 `default` 버전을 항상 실행합니다. 다른 계정에서 새 버전의 문서 공유 양식을 사용하여 연결을 실행하려면 문서 버전을 `default`로 설정해야 합니다.
## 연결 편집(콘솔)
다음 절차에서는 Systems Manager 콘솔을 사용하여 새로운 연결 버전을 편집하고 생성하는 방법을 설명합니다.
**참고**
Automation 런북이 아닌 SSM Command 문서를 사용하는 연결의 경우 이 절차를 수행하려면 기존 Amazon S3 버킷에 대한 쓰기 액세스 권한이 있어야 합니다. 이전에 Amazon S3를 사용해 본 적이 없는 경우 Amazon S3 사용 요금이 부과되므로 주의하세요. 버킷을 생성하는 방법에 대한 자세한 내용은 [버킷 생성](https://docs.aws.amazon.com/AmazonS3/latest/userguide/CreatingABucket.html) 섹션을 참조하세요.
**State Manager 연결을 편집하려면**
1. [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)에서 AWS Systems Manager 콘솔을 엽니다.
1. 탐색 창에서 **State Manager**를 선택합니다.
1. 기존 연결을 선택하고 **편집**을 선택합니다.
1. 현재 요구 사항을 충족하도록 연결을 다시 구성합니다.
`Command` 및 `Policy` 문서를 사용한 옵션에 대한 자세한 내용은 [연결 생성](state-manager-associations-creating.md) 문서를 참조하세요. Automation 런북을 사용한 연결 옵션에 대한 자세한 내용은 [State Manager 연결을 사용하여 자동화 예약](scheduling-automations-state-manager-associations.md) 문서를 참조하세요.
1. **변경 사항 저장(Save Changes)**을 선택합니다.
1. (선택사항) **연결** 페이지에서 연결 정보를 보려면 편집한 연결의 이름을 선택한 후 **버전** 탭을 선택합니다. 생성하고 편집한 연결의 각 버전이 시스템에 나열됩니다.
1. (선택 사항) SSM `Command` 문서를 기반으로 한 연결의 출력을 보려면 다음을 수행합니다.
1. [https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/)에서 S3 콘솔을 엽니다.
1. 명령 출력을 저장하도록 지정한 Amazon S3 버킷의 이름을 선택한 후, 연결을 실행한 노드의 ID로 이름을 지정한 폴더를 선택합니다. (버킷의 폴더에 출력을 저장하도록 선택한 경우, 해당 폴더를 먼저 여세요.)
1. 몇 가지 수준을 드릴다운하여 `awsrunPowerShell` 폴더의 `stdout` 파일을 찾습니다.
1. **열기** 또는 **다운로드**를 선택하여 호스트 이름을 확인합니다.
## 연결 편집(명령줄)
다음 절차에서는 AWS CLI(Linux 또는 Windows Server) 또는 AWS Tools for PowerShell을 사용하여 새로운 연결 버전을 편집 및 생성하는 방법을 설명합니다.
**State Manager 연결을 편집하려면**
1. 아직 하지 않은 경우 AWS CLI 또는 AWS Tools for PowerShell을 설치하고 구성합니다.
자세한 내용은 [최신 버전의 AWS CLI 설치 또는 업데이트](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html) 및 [AWS Tools for PowerShell 설치](https://docs.aws.amazon.com/powershell/latest/userguide/pstools-getting-set-up.html)를 참조하세요.
1. 다음 형식을 사용하여 기존 State Manager 연결의 새로운 버전을 편집 및 생성할 명령을 만듭니다. 각 *example resource placeholder*를 사용자의 정보로 바꿉니다.
**중요**
`[https://docs.aws.amazon.com/cli/latest/reference/ssm/desupdatecribe-association.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/desupdatecribe-association.html)`을 호출할 때, 시스템은 요청의 모든 부가적인 파라미터를 드롭하고 이 파라미터를 null 값으로 덮어씁니다. 이것은 설계에 따른 것입니다. 파라미터를 변경하지 않더라도 호출에서 모든 선택적 파라미터를 지정해야 합니다. 여기에는 `--name` 파라미터가 포함됩니다. 이 작업을 호출하기 전에, `[https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-association.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-association.html)` 작업을 직접 호출하고 `update-association` 직접 호출에 필요한 모든 선택적 파라미터를 기록해 두는 것이 좋습니다.
------
#### [ Linux & macOS ]
```
aws ssm update-association \
--name document_name \
--document-version version_of_document_applied \
--instance-id instances_to_apply_association_on \
--parameters (if any) \
--targets target_options \
--association-dispatch-assume-role arn_of_role_to_be_used_when_dispatching_configurations \
--schedule-expression "cron_or_rate_expression" \
--schedule-offset "number_between_1_and_6" \
--output-location s3_bucket_to_store_output_details \
--association-name association_name \
--max-errors a_number_of_errors_or_a_percentage_of_target_set \
--max-concurrency a_number_of_instances_or_a_percentage_of_target_set \
--compliance-severity severity_level \
--calendar-names change_calendar_names \
--target-locations aws_region_or_account
```
------
#### [ Windows ]
```
aws ssm update-association ^
--name document_name ^
--document-version version_of_document_applied ^
--instance-id instances_to_apply_association_on ^
--parameters (if any) ^
--targets target_options ^
--association-dispatch-assume-role arn_of_role_to_be_used_when_dispatching_configurations ^
--schedule-expression "cron_or_rate_expression" ^
--schedule-offset "number_between_1_and_6" ^
--output-location s3_bucket_to_store_output_details ^
--association-name association_name ^
--max-errors a_number_of_errors_or_a_percentage_of_target_set ^
--max-concurrency a_number_of_instances_or_a_percentage_of_target_set ^
--compliance-severity severity_level ^
--calendar-names change_calendar_names ^
--target-locations aws_region_or_account
```
------
#### [ PowerShell ]
```
Update-SSMAssociation `
-Name document_name `
-DocumentVersion version_of_document_applied `
-InstanceId instances_to_apply_association_on `
-Parameters (if any) `
-Target target_options `
-AssociationDispatchAssumeRole arn_of_role_to_be_used_when_dispatching_configurations `
-ScheduleExpression "cron_or_rate_expression" `
-ScheduleOffset "number_between_1_and_6" `
-OutputLocation s3_bucket_to_store_output_details `
-AssociationName association_name `
-MaxError a_number_of_errors_or_a_percentage_of_target_set
-MaxConcurrency a_number_of_instances_or_a_percentage_of_target_set `
-ComplianceSeverity severity_level `
-CalendarNames change_calendar_names `
-TargetLocations aws_region_or_account
```
------
다음 예제에서는 이름을 `TestHostnameAssociation2`으로 변경하도록 기존 연결을 업데이트합니다. 새로운 연결 버전은 매 시간마다 실행되고 명령의 출력을 지정된 Amazon S3 버킷에 씁니다.
------
#### [ Linux & macOS ]
```
aws ssm update-association \
--association-id 8dfe3659-4309-493a-8755-01234EXAMPLE \
--association-name TestHostnameAssociation2 \
--parameters commands="echo Association" \
--association-dispatch-assume-role arn:aws:iam::123456789012:role/myAssociationDispatchAssumeRole \
--output-location S3Location='{OutputS3Region=us-east-1,OutputS3BucketName=amzn-s3-demo-bucket,OutputS3KeyPrefix=logs}' \
--schedule-expression "cron(0 */1 * * ? *)"
```
------
#### [ Windows ]
```
aws ssm update-association ^
--association-id 8dfe3659-4309-493a-8755-01234EXAMPLE ^
--association-name TestHostnameAssociation2 ^
--parameters commands="echo Association" ^
--association-dispatch-assume-role arn:aws:iam::123456789012:role/myAssociationDispatchAssumeRole ^
--output-location S3Location='{OutputS3Region=us-east-1,OutputS3BucketName=amzn-s3-demo-bucket,OutputS3KeyPrefix=logs}' ^
--schedule-expression "cron(0 */1 * * ? *)"
```
------
#### [ PowerShell ]
```
Update-SSMAssociation `
-AssociationId b85ccafe-9f02-4812-9b81-01234EXAMPLE `
-AssociationName TestHostnameAssociation2 `
-Parameter @{"commands"="echo Association"} `
-AssociationDispatchAssumeRole "arn:aws:iam::123456789012:role/myAssociationDispatchAssumeRole" `
-S3Location_OutputS3BucketName amzn-s3-demo-bucket `
-S3Location_OutputS3KeyPrefix logs `
-S3Location_OutputS3Region us-east-1 `
-ScheduleExpression "cron(0 */1 * * ? *)"
```
------
다음 예제에서는 이름을 `CalendarAssociation`으로 변경하도록 기존 연결을 업데이트합니다. 새로운 연결은 달력이 열릴 때 실행되고 명령 출력을 지정된 Amazon S3 버킷에 씁니다.
------
#### [ Linux & macOS ]
```
aws ssm update-association \
--association-id 8dfe3659-4309-493a-8755-01234EXAMPLE \
--association-name CalendarAssociation \
--parameters commands="echo Association" \
--output-location S3Location='{OutputS3Region=us-east-1,OutputS3BucketName=amzn-s3-demo-bucket,OutputS3KeyPrefix=logs}' \
--calendar-names "arn:aws:ssm:us-east-1:123456789012:document/testCalendar2"
```
------
#### [ Windows ]
```
aws ssm update-association ^
--association-id 8dfe3659-4309-493a-8755-01234EXAMPLE ^
--association-name CalendarAssociation ^
--parameters commands="echo Association" ^
--output-location S3Location='{OutputS3Region=us-east-1,OutputS3BucketName=amzn-s3-demo-bucket,OutputS3KeyPrefix=logs}' ^
--calendar-names "arn:aws:ssm:us-east-1:123456789012:document/testCalendar2"
```
------
#### [ PowerShell ]
```
Update-SSMAssociation `
-AssociationId b85ccafe-9f02-4812-9b81-01234EXAMPLE `
-AssociationName CalendarAssociation `
-AssociationName OneTimeAssociation `
-Parameter @{"commands"="echo Association"} `
-S3Location_OutputS3BucketName amzn-s3-demo-bucket `
-CalendarNames "arn:aws:ssm:us-east-1:123456789012:document/testCalendar2"
```
------
다음 예제에서는 이름을 `MultiCalendarAssociation`으로 변경하도록 기존 연결을 업데이트합니다. 새로운 연결은 달력이 열려 있을 때 실행되고 명령 출력을 지정된 Amazon S3 버킷에 씁니다.
------
#### [ Linux & macOS ]
```
aws ssm update-association \
--association-id 8dfe3659-4309-493a-8755-01234EXAMPLE \
--association-name MultiCalendarAssociation \
--parameters commands="echo Association" \
--output-location S3Location='{OutputS3Region=us-east-1,OutputS3BucketName=amzn-s3-demo-bucket,OutputS3KeyPrefix=logs}' \
--calendar-names "arn:aws:ssm:us-east-1:123456789012:document/testCalendar1" "arn:aws:ssm:us-east-2:123456789012:document/testCalendar2"
```
------
#### [ Windows ]
```
aws ssm update-association ^
--association-id 8dfe3659-4309-493a-8755-01234EXAMPLE ^
--association-name MultiCalendarAssociation ^
--parameters commands="echo Association" ^
--output-location S3Location='{OutputS3Region=us-east-1,OutputS3BucketName=amzn-s3-demo-bucket,OutputS3KeyPrefix=logs}' ^
--calendar-names "arn:aws:ssm:us-east-1:123456789012:document/testCalendar1" "arn:aws:ssm:us-east-2:123456789012:document/testCalendar2"
```
------
#### [ PowerShell ]
```
Update-SSMAssociation `
-AssociationId b85ccafe-9f02-4812-9b81-01234EXAMPLE `
-AssociationName MultiCalendarAssociation `
-Parameter @{"commands"="echo Association"} `
-S3Location_OutputS3BucketName amzn-s3-demo-bucket `
-CalendarNames "arn:aws:ssm:us-east-1:123456789012:document/testCalendar1" "arn:aws:ssm:us-east-2:123456789012:document/testCalendar2"
```
------
1. 새로운 연결 버전을 보려면 다음 명령을 실행합니다.
------
#### [ Linux & macOS ]
```
aws ssm describe-association \
--association-id b85ccafe-9f02-4812-9b81-01234EXAMPLE
```
------
#### [ Windows ]
```
aws ssm describe-association ^
--association-id b85ccafe-9f02-4812-9b81-01234EXAMPLE
```
------
#### [ PowerShell ]
```
Get-SSMAssociation `
-AssociationId b85ccafe-9f02-4812-9b81-01234EXAMPLE | Select-Object *
```
------
시스템은 다음과 같은 정보를 반환합니다.
------
#### [ Linux & macOS ]
```
{
"AssociationDescription": {
"ScheduleExpression": "cron(0 */1 * * ? *)",
"OutputLocation": {
"S3Location": {
"OutputS3KeyPrefix": "logs",
"OutputS3BucketName": "amzn-s3-demo-bucket",
"OutputS3Region": "us-east-1"
}
},
"Name": "AWS-RunPowerShellScript",
"Parameters": {
"commands": [
"echo Association"
]
},
"LastExecutionDate": 1559316400.338,
"Overview": {
"Status": "Success",
"DetailedStatus": "Success",
"AssociationStatusAggregatedCount": {}
},
"AssociationId": "b85ccafe-9f02-4812-9b81-01234EXAMPLE",
"DocumentVersion": "$DEFAULT",
"LastSuccessfulExecutionDate": 1559316400.338,
"LastUpdateAssociationDate": 1559316389.753,
"Date": 1559314038.532,
"AssociationVersion": "2",
"AssociationName": "TestHostnameAssociation2",
"Targets": [
{
"Values": [
"Windows"
],
"Key": "tag:Environment"
}
]
}
}
```
------
#### [ Windows ]
```
{
"AssociationDescription": {
"ScheduleExpression": "cron(0 */1 * * ? *)",
"OutputLocation": {
"S3Location": {
"OutputS3KeyPrefix": "logs",
"OutputS3BucketName": "amzn-s3-demo-bucket",
"OutputS3Region": "us-east-1"
}
},
"Name": "AWS-RunPowerShellScript",
"Parameters": {
"commands": [
"echo Association"
]
},
"LastExecutionDate": 1559316400.338,
"Overview": {
"Status": "Success",
"DetailedStatus": "Success",
"AssociationStatusAggregatedCount": {}
},
"AssociationId": "b85ccafe-9f02-4812-9b81-01234EXAMPLE",
"DocumentVersion": "$DEFAULT",
"LastSuccessfulExecutionDate": 1559316400.338,
"LastUpdateAssociationDate": 1559316389.753,
"Date": 1559314038.532,
"AssociationVersion": "2",
"AssociationName": "TestHostnameAssociation2",
"Targets": [
{
"Values": [
"Windows"
],
"Key": "tag:Environment"
}
]
}
}
```
------
#### [ PowerShell ]
```
AssociationId : b85ccafe-9f02-4812-9b81-01234EXAMPLE
AssociationName : TestHostnameAssociation2
AssociationVersion : 2
AutomationTargetParameterName :
ComplianceSeverity :
Date : 5/31/2019 2:47:18 PM
DocumentVersion : $DEFAULT
InstanceId :
LastExecutionDate : 5/31/2019 3:26:40 PM
LastSuccessfulExecutionDate : 5/31/2019 3:26:40 PM
LastUpdateAssociationDate : 5/31/2019 3:26:29 PM
MaxConcurrency :
MaxErrors :
Name : AWS-RunPowerShellScript
OutputLocation : Amazon.SimpleSystemsManagement.Model.InstanceAssociationOutputLocation
Overview : Amazon.SimpleSystemsManagement.Model.AssociationOverview
Parameters : {[commands, Amazon.Runtime.Internal.Util.AlwaysSendList`1[System.String]]}
ScheduleExpression : cron(0 */1 * * ? *)
Status :
Targets : {tag:Environment}
```
------
# 연결 삭제
다음 절차에 따라 AWS Systems Manager 콘솔을 사용하여 연결을 삭제합니다.
**연결을 삭제하려면**
1. [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)에서 AWS Systems Manager 콘솔을 엽니다.
1. 탐색 창에서 **State Manager**를 선택합니다.
1. 연결을 선택하고 **삭제**를 선택합니다.
AWS Systems Manager 콘솔에서 자동화를 실행하여 한 번의 작업으로 여러 개의 연결을 삭제할 수 있습니다. 삭제할 연결을 여러 개 선택하면 State Manager가 입력 파라미터 값으로 입력된 연결 ID를 사용하여 자동화 런북 시작 페이지를 시작합니다.
**한 번의 작업으로 여러 연결을 삭제하려면**
1. [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)에서 AWS Systems Manager 콘솔을 엽니다.
1. 탐색 창에서 **State Manager**를 선택합니다.
1. 삭제하려는 각 연결을 선택한 다음 **삭제**를 선택합니다.
1. (선택 사항) **추가 입력 파라미터** 영역에서 실행 중에 자동화가 사용할 **역할 수임을 위한 Amazon 리소스 이름(ARN)을 선택합니다. 새 역할 수임을 생성하려면 **생성**을 선택하세요.
1. **제출**을 선택합니다.
# 연결을 사용하여 Auto Scaling 그룹 실행
연결을 사용하여 Auto Scaling 그룹을 실행할 때 모범 사례는 태그 대상을 사용하는 것입니다. 태그를 사용하지 않으면 연결 제한에 도달하게 될 수 있습니다.
모든 노드에 동일한 키와 값으로 태그가 지정된 경우 Auto Scaling 그룹을 실행하는 데 하나의 연결만 필요합니다. 다음 절차에서는 이러한 연결을 생성하는 방법을 설명합니다.
**Auto Scaling 그룹을 실행하는 연결을 생성하려면**
1. Auto Scaling 그룹의 모든 노드에 동일한 키와 값으로 태그가 지정되었는지 확인합니다. 노드에 태그를 지정하는 자세한 지침은 *AWS Auto Scaling 사용 설명서*의 [Auto Scaling 그룹 및 인스턴스 태그 지정](https://docs.aws.amazon.com//autoscaling/ec2/userguide/autoscaling-tagging.html)을 참조하세요.
1. [Systems Manager에서 연결 작업](state-manager-associations.md)의 절차를 사용하여 연결을 생성합니다.
콘솔에서 작업 중인 경우 [**대상(Targets)**] 필드에서 [**인스턴스 태그 지정(Specify instance tags)**]을 선택합니다. [**인스턴스 태그(Instance tags)**]에 Auto Scaling 그룹의 [**태그(Tag)**] 키와 값을 입력합니다.
AWS Command Line Interface(AWS CLI)를 사용하는 경우 키와 값이 노드에 태그를 지정하는 데 사용한 것과 일치하는 `--targets Key=tag:tag-key,Values=tag-value`를 지정합니다.
# 연결 내역 보기
[DescribeAssociationExecutions](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_DescribeAssociationExecutions.html) API 작업을 사용하여 특정 연결 ID에 대한 모든 실행을 볼 수 있습니다. 이 작업을 사용하여 State Manager 연결의 상태, 세부 상태, 결과, 마지막 실행 시간 및 추가 정보를 봅니다. State Manager는 AWS Systems Manager의 도구입니다. 이 API 작업에는 지정한 기준에 따라 연결을 찾는 데 도움이 되는 필터도 포함됩니다. 예를 들어 정확한 날짜 및 시간을 지정하고 GREATER\$1THAN 필터를 사용하여 지정한 날짜 및 시간 이후에 처리된 실행을 볼 수 있습니다.
예를 들어 연결 실행에 실패한 경우 [DescribeAssociationExecutionTargets](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_DescribeAssociationExecutionTargets.html) API 작업을 사용하여 특정 실행의 세부 정보를 심층 분석할 수 있습니다. 이 작업은 연결이 실행된 노드 ID와 같은 리소스 및 다양한 연결 상태를 보여줍니다. 그러면 연결 실행에 실패한 리소스나 노드를 확인할 수 있습니다. 그런 다음 리소스 ID를 사용하여 명령 실행 세부 정보를 보고 명령의 어떤 단계가 실패했는지를 확인할 수 있습니다.
이 섹션의 예에는 [StartAssociationsOnce](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_StartAssociationsOnce.html) API 작업을 사용하여 생성 시 한 번 연결을 실행하는 방법에 대한 정보도 포함되어 있습니다. 실패한 연결 실행을 조사할 때 이 API 작업을 사용할 수 있습니다. 연결이 실패했음을 확인하는 경우 리소스를 변경한 다음 연결을 즉시 실행하여 리소스 변경으로 인해 연결을 성공적으로 실행할 수 있는지 여부를 확인할 수 있습니다.
**참고**
연결 실행 중에 SSM 문서에 의해 시작된 API 작업은 AWS CloudTrail에 로깅되지 않습니다.
## 연결 내역 보기(콘솔)
다음 절차를 사용하여 특정 연결 ID에 대한 실행 내역을 본 다음 하나 이상의 리소스에 대한 실행 세부 정보를 봅니다.
**특정 연결 ID에 대한 실행 내역을 보려면**
1. [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)에서 AWS Systems Manager 콘솔을 엽니다.
1. **State Manager**을 선택합니다.
1. **Association id(연결 ID)** 필드에서 내역을 보려는 연결을 선택합니다.
1. **세부 정보 보기(View details)** 버튼을 선택합니다.
1. **Execution history(실행 내역)** 탭을 선택합니다.
1. 리소스 레벨 실행 세부 정보를 보려는 연결을 선택합니다. 예를 들어, **Failed(실패)** 상태를 보여 주는 연결을 선택합니다. 그런 다음 연결을 실행하는 데 실패한 노드에 대한 실행 세부 정보를 볼 수 있습니다.
검색 상자 필터를 사용하여 세부 정보를 보려는 실행을 찾습니다.
![\[State Manager 연결 실행 목록 필터링\]](http://docs.aws.amazon.com/ko_kr/systems-manager/latest/userguide/images/sysman-state-executions-filter.png)
1. 실행 ID를 선택합니다. **Association execution targets(연결 실행 대상)** 페이지가 열립니다. 이 페이지에는 연결을 실행한 모든 리소스가 표시됩니다.
1. 리소스 ID를 선택하여 해당 리소스에 대한 구체적인 정보를 봅니다.
검색 상자 필터를 사용하여 세부 정보를 보려는 리소스를 찾습니다.
![\[State Manager 연결 실행 대상 목록 필터링\]](http://docs.aws.amazon.com/ko_kr/systems-manager/latest/userguide/images/sysman-state-executions-targets-filter.png)
1. 실행에 실패한 연결을 조사하는 경우 [**지금 연결 적용(Apply association now)**] 버튼을 사용하여 생성 시 연결을 한 번 실행할 수 있습니다. 연결 실행에 실패한 리소스를 변경한 후 탐색 이동 경로에서 **Association ID(연결 ID)** 랭크를 선택합니다.
1. **Apply association now(지금 연결 적용)** 버튼을 선택합니다. 실행이 완료된 후 해당 연결 실행이 성공했는지를 확인합니다.
## 연결 내역 보기(명령줄)
다음 절차에서는 AWS Command Line Interface(AWS CLI)(Linux 또는 Windows Server) 또는 AWS Tools for PowerShell을 사용하여 특정 연결 ID에 대한 실행 내역을 보는 방법을 설명합니다. 그런 다음, 하나 이상의 리소스에 대한 실행 세부 정보를 보는 방법을 설명합니다.
**특정 연결 ID에 대한 실행 내역을 보려면**
1. 아직 하지 않은 경우 AWS CLI 또는 AWS Tools for PowerShell을 설치하고 구성합니다.
자세한 내용은 [최신 버전의 AWS CLI 설치 또는 업데이트](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html) 및 [AWS Tools for PowerShell 설치](https://docs.aws.amazon.com/powershell/latest/userguide/pstools-getting-set-up.html)를 참조하세요.
1. 다음 명령을 실행하여 특정 연결 ID의 작업 실행 목록을 봅니다.
------
#### [ Linux & macOS ]
```
aws ssm describe-association-executions \
--association-id ID \
--filters Key=CreatedTime,Value="2018-04-10T19:15:38.372Z",Type=GREATER_THAN
```
**참고**
이 명령에는 특정 날짜 및 시간 이후에 발생한 실행으로만 결과를 제한하는 필터가 포함됩니다. 특정 연결 ID의 모든 실행을 보려는 경우 `--filters` 파라미터 및 ` Key=CreatedTime,Value="2018-04-10T19:15:38.372Z",Type=GREATER_THAN` 값을 제거합니다.
------
#### [ Windows ]
```
aws ssm describe-association-executions ^
--association-id ID ^
--filters Key=CreatedTime,Value="2018-04-10T19:15:38.372Z",Type=GREATER_THAN
```
**참고**
이 명령에는 특정 날짜 및 시간 이후에 발생한 실행으로만 결과를 제한하는 필터가 포함됩니다. 특정 연결 ID의 모든 실행을 보려는 경우 `--filters` 파라미터 및 ` Key=CreatedTime,Value="2018-04-10T19:15:38.372Z",Type=GREATER_THAN` 값을 제거합니다.
------
#### [ PowerShell ]
```
Get-SSMAssociationExecution `
-AssociationId ID `
-Filter @{"Key"="CreatedTime";"Value"="2019-06-01T19:15:38.372Z";"Type"="GREATER_THAN"}
```
**참고**
이 명령에는 특정 날짜 및 시간 이후에 발생한 실행으로만 결과를 제한하는 필터가 포함됩니다. 특정 연결 ID의 모든 실행을 보려는 경우 `-Filter` 파라미터 및 ` @{"Key"="CreatedTime";"Value"="2019-06-01T19:15:38.372Z";"Type"="GREATER_THAN"}` 값을 제거합니다.
------
시스템은 다음과 같은 정보를 반환합니다.
------
#### [ Linux & macOS ]
```
{
"AssociationExecutions":[
{
"Status":"Success",
"DetailedStatus":"Success",
"AssociationId":"c336d2ab-09de-44ba-8f6a-6136cEXAMPLE",
"ExecutionId":"76a5a04f-caf6-490c-b448-92c02EXAMPLE",
"CreatedTime":1523986028.219,
"AssociationVersion":"1"
},
{
"Status":"Success",
"DetailedStatus":"Success",
"AssociationId":"c336d2ab-09de-44ba-8f6a-6136cEXAMPLE",
"ExecutionId":"791b72e0-f0da-4021-8b35-f95dfEXAMPLE",
"CreatedTime":1523984226.074,
"AssociationVersion":"1"
},
{
"Status":"Success",
"DetailedStatus":"Success",
"AssociationId":"c336d2ab-09de-44ba-8f6a-6136cEXAMPLE",
"ExecutionId":"ecec60fa-6bb0-4d26-98c7-140308EXAMPLE",
"CreatedTime":1523982404.013,
"AssociationVersion":"1"
}
]
}
```
------
#### [ Windows ]
```
{
"AssociationExecutions":[
{
"Status":"Success",
"DetailedStatus":"Success",
"AssociationId":"c336d2ab-09de-44ba-8f6a-6136cEXAMPLE",
"ExecutionId":"76a5a04f-caf6-490c-b448-92c02EXAMPLE",
"CreatedTime":1523986028.219,
"AssociationVersion":"1"
},
{
"Status":"Success",
"DetailedStatus":"Success",
"AssociationId":"c336d2ab-09de-44ba-8f6a-6136cEXAMPLE",
"ExecutionId":"791b72e0-f0da-4021-8b35-f95dfEXAMPLE",
"CreatedTime":1523984226.074,
"AssociationVersion":"1"
},
{
"Status":"Success",
"DetailedStatus":"Success",
"AssociationId":"c336d2ab-09de-44ba-8f6a-6136cEXAMPLE",
"ExecutionId":"ecec60fa-6bb0-4d26-98c7-140308EXAMPLE",
"CreatedTime":1523982404.013,
"AssociationVersion":"1"
}
]
}
```
------
#### [ PowerShell ]
```
AssociationId : c336d2ab-09de-44ba-8f6a-6136cEXAMPLE
AssociationVersion : 1
CreatedTime : 8/18/2019 2:00:50 AM
DetailedStatus : Success
ExecutionId : 76a5a04f-caf6-490c-b448-92c02EXAMPLE
LastExecutionDate : 1/1/0001 12:00:00 AM
ResourceCountByStatus : {Success=1}
Status : Success
AssociationId : c336d2ab-09de-44ba-8f6a-6136cEXAMPLE
AssociationVersion : 1
CreatedTime : 8/11/2019 2:00:54 AM
DetailedStatus : Success
ExecutionId : 791b72e0-f0da-4021-8b35-f95dfEXAMPLE
LastExecutionDate : 1/1/0001 12:00:00 AM
ResourceCountByStatus : {Success=1}
Status : Success
AssociationId : c336d2ab-09de-44ba-8f6a-6136cEXAMPLE
AssociationVersion : 1
CreatedTime : 8/4/2019 2:01:00 AM
DetailedStatus : Success
ExecutionId : ecec60fa-6bb0-4d26-98c7-140308EXAMPLE
LastExecutionDate : 1/1/0001 12:00:00 AM
ResourceCountByStatus : {Success=1}
Status : Success
```
------
하나 이상의 필터를 사용하려 결과를 제한할 수 있습니다. 다음 예는 특정 날짜 및 시간 이전에 실행된 모든 연결을 반환합니다.
------
#### [ Linux & macOS ]
```
aws ssm describe-association-executions \
--association-id ID \
--filters Key=CreatedTime,Value="2018-04-10T19:15:38.372Z",Type=LESS_THAN
```
------
#### [ Windows ]
```
aws ssm describe-association-executions ^
--association-id ID ^
--filters Key=CreatedTime,Value="2018-04-10T19:15:38.372Z",Type=LESS_THAN
```
------
#### [ PowerShell ]
```
Get-SSMAssociationExecution `
-AssociationId 14bea65d-5ccc-462d-a2f3-e99c8EXAMPLE `
-Filter @{"Key"="CreatedTime";"Value"="2019-06-01T19:15:38.372Z";"Type"="LESS_THAN"}
```
------
다음은 특정 날짜 및 시간 이후에 *성공적으로* 실행된 모든 연결을 반환합니다.
------
#### [ Linux & macOS ]
```
aws ssm describe-association-executions \
--association-id ID \
--filters Key=CreatedTime,Value="2018-04-10T19:15:38.372Z",Type=GREATER_THAN Key=Status,Value=Success,Type=EQUAL
```
------
#### [ Windows ]
```
aws ssm describe-association-executions ^
--association-id ID ^
--filters Key=CreatedTime,Value="2018-04-10T19:15:38.372Z",Type=GREATER_THAN Key=Status,Value=Success,Type=EQUAL
```
------
#### [ PowerShell ]
```
Get-SSMAssociationExecution `
-AssociationId 14bea65d-5ccc-462d-a2f3-e99c8EXAMPLE `
-Filter @{
"Key"="CreatedTime";
"Value"="2019-06-01T19:15:38.372Z";
"Type"="GREATER_THAN"
},
@{
"Key"="Status";
"Value"="Success";
"Type"="EQUAL"
}
```
------
1. 다음 명령을 실행하여 특정 실행이 실행된 모든 대상을 봅니다.
------
#### [ Linux & macOS ]
```
aws ssm describe-association-execution-targets \
--association-id ID \
--execution-id ID
```
------
#### [ Windows ]
```
aws ssm describe-association-execution-targets ^
--association-id ID ^
--execution-id ID
```
------
#### [ PowerShell ]
```
Get-SSMAssociationExecutionTarget `
-AssociationId 14bea65d-5ccc-462d-a2f3-e99c8EXAMPLE `
-ExecutionId 76a5a04f-caf6-490c-b448-92c02EXAMPLE
```
------
하나 이상의 필터를 사용하려 결과를 제한할 수 있습니다. 다음 예는 특정 연결 실행에 실패한 모든 대상에 대한 정보를 반환합니다.
------
#### [ Linux & macOS ]
```
aws ssm describe-association-execution-targets \
--association-id ID \
--execution-id ID \
--filters Key=Status,Value="Failed"
```
------
#### [ Windows ]
```
aws ssm describe-association-execution-targets ^
--association-id ID ^
--execution-id ID ^
--filters Key=Status,Value="Failed"
```
------
#### [ PowerShell ]
```
Get-SSMAssociationExecutionTarget `
-AssociationId 14bea65d-5ccc-462d-a2f3-e99c8EXAMPLE `
-ExecutionId 76a5a04f-caf6-490c-b448-92c02EXAMPLE `
-Filter @{
"Key"="Status";
"Value"="Failed"
}
```
------
다음 예는 연결 실행에 실패한 특정 관리형 노드에 대한 정보를 반환합니다.
------
#### [ Linux & macOS ]
```
aws ssm describe-association-execution-targets \
--association-id ID \
--execution-id ID \
--filters Key=Status,Value=Failed Key=ResourceId,Value="i-02573cafcfEXAMPLE" Key=ResourceType,Value=ManagedInstance
```
------
#### [ Windows ]
```
aws ssm describe-association-execution-targets ^
--association-id ID ^
--execution-id ID ^
--filters Key=Status,Value=Failed Key=ResourceId,Value="i-02573cafcfEXAMPLE" Key=ResourceType,Value=ManagedInstance
```
------
#### [ PowerShell ]
```
Get-SSMAssociationExecutionTarget `
-AssociationId 14bea65d-5ccc-462d-a2f3-e99c8EXAMPLE `
-ExecutionId 76a5a04f-caf6-490c-b448-92c02EXAMPLE `
-Filter @{
"Key"="Status";
"Value"="Success"
},
@{
"Key"="ResourceId";
"Value"="i-02573cafcfEXAMPLE"
},
@{
"Key"="ResourceType";
"Value"="ManagedInstance"
}
```
------
1. 실행에 실패한 연결을 조사하는 경우 [StartAssociationsOnce](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_StartAssociationsOnce.html) API 작업을 사용하여 연결을 한 번만 즉시 실행할 수 있습니다. 연결 실행에 실패한 리소스를 변경한 후 다음 명령을 실행하여 연결을 한 번만 즉시 실행합니다.
------
#### [ Linux & macOS ]
```
aws ssm start-associations-once \
--association-id ID
```
------
#### [ Windows ]
```
aws ssm start-associations-once ^
--association-id ID
```
------
#### [ PowerShell ]
```
Start-SSMAssociationsOnce `
-AssociationId ID
```
------
# IAM을 사용한 연결 작업
State Manager의 도구인 AWS Systems Manager는 [대상](systems-manager-state-manager-targets-and-rate-controls.md#systems-manager-state-manager-targets-and-rate-controls-about-targets)을 사용하여 연결을 구성할 인스턴스를 선택합니다. 원래 연결은 문서 이름(`Name`)과 인스턴스 ID(`InstanceId`)를 지정하여 생성되었습니다. 그러면 문서와 인스턴스 또는 관리형 노드드 간 연결이 생성됩니다. 이러한 파라미터에 의해 식별되는 데 사용되는 연결입니다. 이러한 파라미터는 이제 더 이상 사용되지 않지만 여전히 지원됩니다. 리소스 `instance` 및 `managed-instance`가 `Name` 및 `InstanceId`와 함께 작업에 리소스로 추가되었습니다.
AWS Identity and Access Management(IAM) 정책 시행 동작은 지정된 리소스 유형에 따라 다릅니다. State Manager 작업을 위한 리소스는 전달된 요청에 따라서만 시행됩니다. State Manager는 사용자 계정에 있는 리소스의 속성에 대한 정밀 검사를 수행하지 않습니다. 요청 파라미터에 지정된 정책 리소스가 포함된 경우에만 요청이 정책 리소스에 대해 검증됩니다. 예를 들어 리소스 블록에 인스턴스를 지정하면 요청에서 `InstanceId` 파라미터를 사용하는 경우 정책이 시행됩니다. 계정의 각 리소스에 대한 `Targets` 파라미터는 해당 `InstanceId`에 대해 확인되지 않습니다.
다음은 혼란스러운 동작이 포함된 몇 가지 경우입니다.
+ [DescribeAssociation](https://docs.aws.amazon.com//systems-manager/latest/APIReference/API_DescribeActivations.html), [DeleteAssociation](https://docs.aws.amazon.com//systems-manager/latest/APIReference/API_DeleteAssociation.html) 및 [UpdateAssociation](https://docs.aws.amazon.com//systems-manager/latest/APIReference/API_UpdateAssociation.html)은 `instance`, `managed-instance` 및 `document` 리소스를 사용하여 더 이상 사용되지 않는 연결 참조 방법을 지정합니다. 여기에는 더 이상 사용되지 않는 `InstanceId` 파라미터로 생성된 모든 연결이 포함됩니다.
+ [CreateAssociation](https://docs.aws.amazon.com//systems-manager/latest/APIReference/API_CreateAssociation.html), [CreateAssociationBatch](https://docs.aws.amazon.com//systems-manager/latest/APIReference/API_CreateAssociationBatch.html) 및 [UpdateAssociation](https://docs.aws.amazon.com//systems-manager/latest/APIReference/API_UpdateAssociation.html)은 `instance` 및 `managed-instance` 리소스를 사용하여 더 이상 사용되지 않는 연결 참조 방법을 지정합니다. 여기에는 더 이상 사용되지 않는 `InstanceId` 파라미터로 생성된 모든 연결이 포함됩니다. `document` 리소스 유형은 더 이상 사용되지 않는 연결 참조 방법의 일부이며 연결의 실제 속성입니다. 즉, 문서 이름을 기반으로 `Create` 및 `Update` 작업 모두에 대해 `Allow` 또는 `Deny` 권한이 있는 IAM 정책을 구성할 수 있습니다.
Systems Manager에서 IAM 정책을 사용하는 방법에 대한 자세한 내용은 *Service Authorization Reference*의 [AWS Systems Manager의 I자격 증명 및 액세스 관리](security-iam.md) 또는 [Actions, resources, and condition keys for AWS Systems Manager](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awssystemsmanager.html)를 참조하세요.
# MOF 파일을 실행하는 연결 생성
MOF(Management Object Format) 파일을 실행하여 `AWS-ApplyDSCMofs` SSM 문서를 사용해 AWS Systems Manager의 도구인 State Manager에서 Windows Server 관리형 노드에 대해 원하는 상태를 적용할 수 있습니다. `AWS-ApplyDSCMofs` 문서에는 2가지 실행 모드가 있습니다. 첫 번째 모드에서는 관리형 노드가 지정된 MOF 파일에 정의된 원하는 상태인지 검사해 보고하도록 연결을 구성할 수 있습니다. 두 번째 모드에서는 MOF 파일에 정의된 리소스와 그 값을 기반으로 MOF 파일을 실행하고 노드의 구성을 변경할 수 있습니다. `AWS-ApplyDSCMofs` 문서를 사용하면 로컬 공유인 Amazon Simple Storage Service(Amazon S3) 또는 HTTPS 도메인을 사용하는 안전한 웹 사이트에서 MOF 구성 파일을 다운로드하고 실행할 수 있습니다.
State Manager는 각 연결 실행 중 개별 MOF 파일의 상태를 기록 및 보고합니다. State Manager는 또한 각 MOF 파일 실행의 출력도 규정 준수 이벤트로 보고하며, 이러한 내용은 [AWS Systems Manager 규정 준수](https://console.aws.amazon.com/systems-manager/compliance) 페이지에서 확인할 수 있습니다.
MOF 파일 실행은 PowerShell DSC(Windows PowerShell Desired State Configuration)에서 빌드됩니다. PowerShell DSC는 Windows 시스템 구성, 배포 및 관리에 사용되는 서술식 플랫폼입니다. PowerShell DSC를 사용해 관리자는 DSC 구성이라는 간단한 텍스트 문서의 형식으로 서버 구성 방식을 설명할 수 있습니다. PowerShell DSC 구성은 할 일이 명시된 특수화된 PowerShell 스크립트이지만 여기에는 할 일 수행 방식은 나와 있지 않습니다. 구성을 실행하면 MOF 파일이 생성됩니다. MOF 파일은 하나 이상의 서버에 적용해 해당 서버에 대해 원하는 구성을 얻을 수 있습니다. PowerShell DSC 리소스는 구성 적용의 실제 작업을 수행합니다. 자세한 내용은 [Windows PowerShell Desired State Configuration 개요](https://download.microsoft.com/download/4/3/1/43113F44-548B-4DEA-B471-0C2C8578FBF8/Quick_Reference_DSC_WS12R2.pdf)를 참조하세요.
**Topics**
+ [Amazon S3를 사용하여 아티팩트 저장](#systems-manager-state-manager-using-mof-file-S3-storage)
+ [MOF 파일에서 자격 증명 확인](#systems-manager-state-manager-using-mof-file-credentials)
+ [MOF 파일에서 토큰 사용](#systems-manager-state-manager-using-mof-file-tokens)
+ [MOF 파일을 실행하는 연결을 생성하기 위한 사전 조건](#systems-manager-state-manager-using-mof-file-prereqs)
+ [MOF 파일을 실행하는 연결 생성](#systems-manager-state-manager-using-mof-file-creating)
+ [MOF 파일을 실행하는 연결을 생성할 때 발생하는 문제 해결](#systems-manager-state-manager-using-mof-file-troubleshooting)
+ [DSC 리소스 규정 준수 세부 정보 보기](#systems-manager-state-manager-viewing-mof-file-compliance)
## Amazon S3를 사용하여 아티팩트 저장
Amazon S3를 사용하여 PowerShell 모듈, MOF 파일, 규정 준수 보고서 또는 상태 보고서를 저장하는 경우 AWS Systems Manager SSM Agent에서 사용하는 AWS Identity and Access Management(IAM) 역할에는 버킷에 대한 `GetObject` 및 `ListBucket` 권한이 있어야 합니다. 이러한 권한을 제공하지 않으면 시스템에서는 *액세스 거부됨* 오류가 반환됩니다. 다음은 Amazon S3에 아티팩트 저장에 대한 중요 정보입니다.
+ 버킷이 다른 AWS 계정에 있는 경우 해당 계정(또는 IAM 역할)에 `GetObject` 및 `ListBucket` 권한을 부여하는 버킷 리소스 정책을 생성합니다.
+ 사용자 정의 DSC 리소스를 사용하려는 경우 Amazon S3 버킷에서 이러한 리소스를 다운로드할 수 있습니다. 또한 PowerShell 갤러리에서 자동으로 설치할 수도 있습니다.
+ Amazon S3를 모듈 소스로 사용하는 경우 다음 대/소문자를 구분하는 *ModuleName*\$1*ModuleVersion*.zip 형식의 Zip 파일로 모듈을 업로드해야 합니다. 예: MyModule\$11.0.0.zip.
+ 모든 파일이 버킷 루트에 있어야 합니다. 폴더 구조는 지원되지 않습니다.
## MOF 파일에서 자격 증명 확인
자격 증명은 [AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/) 또는 [AWS Systems Manager Parameter Store](systems-manager-parameter-store.md)를 사용하여 확인합니다. 그러면 자동 자격 증명 교체를 설정할 수 있습니다. 또한 덕분에 DSC가 MOF를 다시 배포하지 않고 서버에 자격 증명을 자동으로 전파할 수 있습니다.
구성에 AWS Secrets Manager 암호를 사용하려면 사용자 이름이 자격 증명을 포함한 암호의 SecretId 또는 SecretARN인 PSCredential 객체를 생성합니다. 암호에 대해 모든 값을 지정할 수 있습니다. 이 값은 무시됩니다. 다음은 한 예입니다.
```
Configuration MyConfig
{
$ss = ConvertTo-SecureString -String 'a_string' -AsPlaintext -Force
$credential = New-Object PSCredential('a_secret_or_ARN', $ss)
Node localhost
{
File file_name
{
DestinationPath = 'C:\MyFile.txt'
SourcePath = '\\FileServer\Share\MyFile.txt'
Credential = $credential
}
}
}
```
구성 데이터의 PsAllowPlaintextPassword 설정을 사용하여 MOF를 컴파일합니다. 자격 증명에는 레이블만 포함되기 때문에 괜찮습니다.
Secrets Manager에서 노드가 IAM Managed 관리형 정책과 선택적으로 암호 리소스 정책(있는 경우)에 GetSecretValue 액세스를 가지고 있는지 확인합니다. DSC 작업을 수행하려면 암호가 다음과 같은 형식이어야 합니다.
```
{ 'Username': 'a_name', 'Password': 'a_password' }
```
암호에는 다른 속성(예: 교체에 사용되는 속성)이 있을 수 있지만 최소한 사용자 이름 및 암호 속성은 있어야 합니다.
두 개의 다른 사용자 및 암호가 있고 교체 AWS Lambda 함수가 이러한 사용자 및 암호 간에 전환하는 다중 사용자 교체 방법을 사용하는 것이 좋습니다. 이 방법을 사용하면 활성 계정을 여러 개 가질 수 있고, 교체 중 사용자를 잠글 위험이 사라집니다.
## MOF 파일에서 토큰 사용
토큰은 MOF 파일 컴파일 *후* 리소스 속성 값을 수정할 수 있는 기능을 제공합니다. 따라서 유사한 구성이 필요한 여러 서버에서 공통 MOF 파일을 다시 사용할 수 있습니다.
토큰 대체는 유형 `String`의 리소스 속성에 대해서만 작동합니다. 그러나 리소스에 중첩된 CIM 노드 속성이 있는 경우 해당 CIM 노드의 `String` 속성에서 토큰을 확인합니다. 숫자 또는 배열에는 토큰 대체를 사용할 수 없습니다.
예를 들어, xComputerManagement 리소스를 사용하고 DSC를 사용하여 컴퓨터의 이름을 바꾸려고 하는 시나리오에 대해 생각해 보세요. 일반적으로 해당 컴퓨터 전용 MOF 파일이 필요합니다. 그러나 토큰 지원을 통해 단일 MOF 파일을 생성해 모든 노드에 적용할 수 있습니다. MOF에 컴퓨터 이름을 하드 코딩하는 대신 `ComputerName` 속성에서 인스턴스 태그 유형 토큰을 사용할 수 있습니다. 이 값은 MOF 구문 분석 중 확인됩니다. 다음 예제를 참조하세요.
```
Configuration MyConfig
{
xComputer Computer
{
ComputerName = '{tag:ComputerName}'
}
}
```
그런 다음 Systems Manager 콘솔에서 관리형 노드에 태그를 설정하거나 Amazon EC2 콘솔에서 Amazon Elastic Compute Cloud(Amazon EC2) 태그를 설정합니다. 문서를 실행할 때 스크립트가 인스턴스 태그의 값에 대한 \$1tag:ComputerName\$1 토큰을 대체합니다.
또한 다음 예와 같이 여러 태그를 단일 속성으로 통합할 수도 있습니다.
```
Configuration MyConfig
{
File MyFile
{
DestinationPath = '{env:TMP}\{tag:ComputerName}'
Type = 'Directory'
}
}
```
사용 가능한 다음과 같은 5가지 다른 유형의 토큰이 있습니다.
+ **tag**: Amazon EC2 또는 관리형 노드 태그입니다.
+ **tagb64**: tag와 동일하지만 시스템에서 값을 디코딩하는 데 base64를 사용합니다. 따라서 태그 값에 특수 문자를 사용할 수 있습니다.
+ **env**: 환경 변수를 확인합니다.
+ **ssm**: Parameter Store 값입니다. String 및 Secure String 유형만 지원됩니다.
+ **tagssm**: tag와 동일하지만 tag가 노드에 대해 설정되지 않은 경우 시스템에서는 이름이 동일한 Systems Manager 파라미터에서 값을 확인하려고 합니다. 이는 '기본 전역 값'이 필요하지만 단일 노드에서 이 값을 재정의하길 원하는 경우 유용합니다(예: 단일 시스템 배포).
다음은 `ssm` 토큰 유형을 사용하는 Parameter Store 예입니다.
```
File MyFile
{
DestinationPath = "C:\ProgramData\ConnectionData.txt"
Content = "{ssm:%servicePath%/ConnectionData}"
}
```
토큰은 MOF 파일을 일반적이고 재사용 가능하게 만들어 중복 코드를 줄이는 데 중요한 역할을 합니다. 서버별 MOF 파일을 피할 수 있는 경우 MOF 구축 서비스가 필요 없습니다. MOF 컴파일 시 빌드 서버에 다른 모듈 버전이 설치되므로 MOF 구축 서비스를 사용하면 비용이 증가하고, 프로비저닝 시간이 늘어나고, 그룹화된 노드 간에 구성 편차 가능성이 커집니다.
## MOF 파일을 실행하는 연결을 생성하기 위한 사전 조건
MOF 파일을 실행하는 연결을 생성하기 전에 관리형 노드에 다음 사전 조건이 설치되어 있는지 확인합니다.
+ Windows PowerShell 버전 5.0 이상. 자세한 내용은 Microsoft.com에서 [Windows PowerShell System Requirements](https://docs.microsoft.com/en-us/powershell/scripting/install/windows-powershell-system-requirements?view=powershell-6)를 참조하세요.
+ [AWS Tools for Windows PowerShell](https://aws.amazon.com/powershell/) 버전 3.3.261.0 이상
+ SSM Agent 버전 2.2 이상
## MOF 파일을 실행하는 연결 생성
**MOF 파일을 실행하는 연결을 생성하려면**
1. [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)에서 AWS Systems Manager 콘솔을 엽니다.
1. 탐색 창에서 **State Manager**를 선택합니다.
1. **State Manager**를 선택하고 **Create association(연결 생성)**을 선택합니다.
1. **Name(이름)** 필드에 이름을 지정합니다. 이는 선택 사항이며, 권장 사항은 아닙니다. 이 이름으로 연결 생성 시 연결의 용도를 파악할 수 있습니다. 공백은 이름에 사용할 수 없습니다.
1. [**문서(Document)**] 목록에서 **`AWS-ApplyDSCMofs`**를 선택합니다.
1. **파라미터** 섹션에서 필요한 선택적 입력 파라미터를 지정합니다.
1. **Mofs To Apply(적용할 MOF)**: 연결 실행 시 실행할 MOF 파일을 하나 이상 지정합니다. 쉼표를 사용해 MOF 파일 목록을 구분합니다. Systems Manager는 MOF 파일 목록을 반복하면서 쉼표로 구분된 목록에 지정된 순서대로 실행합니다.
+ Amazon S3 버킷 이름입니다. 버킷 이름은 소문자여야 합니다. 다음 형식을 사용하여 이 정보를 지정합니다.
```
s3:amzn-s3-demo-bucket:MOF_file_name.mof
```
AWS 리전을 지정하려면 다음 형식을 사용합니다.
```
s3:bucket_Region:amzn-s3-demo-bucket:MOF_file_name.mof
```
+ 안전한 웹 사이트 다음 형식을 사용하여 이 정보를 지정합니다.
```
https://domain_name/MOF_file_name.mof
```
다음 예를 참고하세요
```
https://www.example.com/TestMOF.mof
```
+ 로컬 공유의 파일 시스템. 다음 형식을 사용하여 이 정보를 지정합니다.
```
\server_name\shared_folder_name\MOF_file_name.mof
```
다음 예를 참고하세요
```
\StateManagerAssociationsBox\MOFs_folder\MyMof.mof
```
1. [**서비스 경로(Service Path)**]: (옵션) 서비스 경로는 보고서 및 상태 정보를 작성하려는 Amazon S3 버킷 접두사이거나 Parameter Store 파라미터 기반 태그의 경로입니다. 파라미터 기반 태그를 확인할 때 시스템에서는 \$1ssm:%servicePath%/*parameter\$1name*을 사용하여 파라미터 이름에 servicePath 값을 삽입합니다. 예를 들어, 서비스 경로가 "WebServers/Production"인 경우 시스템에서는 이 파라미터를 WebServers/Production/*parameter\$1name*으로 확인합니다. 이는 동일한 계정에서 여러 환경을 실행하는 경우 유용합니다.
1. [**보고서 버킷 이름(Report Bucket Name)**]: (옵션) 규정 준수 데이터를 쓰려는 Amazon S3 버킷의 이름을 입력합니다. 보고서는 이 버킷에 JSON 형식으로 저장됩니다.
**참고**
버킷이 있는 리전으로 버킷 이름의 접두사를 지정할 수 있습니다. 예: us-west-2:MyMOFBucket. 특정 리전(us-east-1 제외)에서 Amazon S3 엔드포인트에 프록시를 사용하는 경우 리전으로 버킷 이름의 접두사를 지정합니다. 버킷 이름에 접두사가 지정되지 않은 경우 us-east-1 엔드포인트를 사용하여 자동으로 버킷 리전을 검색합니다.
1. [**Mof 작업 모드(Mof Operation Mode)**]: **`AWS-ApplyDSCMofs`** 연결을 실행할 때 State Manager 동작을 선택합니다.
+ **적용**: 규정을 준수하지 않는 노드 구성을 수정합니다.
+ **ReportOnly**: 노드 구성은 수정하지 않지만 대신 모든 규정 준수 데이터를 로깅하고 규정을 준수하지 않는 노드를 보고합니다.
1. [**상태 버킷 이름(Status Bucket Name)**]: (옵션) MOF 실행 상태 정보를 쓰려는 Amazon S3 버킷의 이름을 입력합니다. 이러한 상태 보고서는 노드의 최신 규정 준수 실행의 singleton 요약입니다. 즉, 이 보고서는 다음에 연결이 MOF 파일을 실행할 때 덮어씁니다.
**참고**
버킷이 있는 리전으로 버킷 이름의 접두사를 지정할 수 있습니다. 예를 들면 `us-west-2:amzn-s3-demo-bucket`입니다. 특정 리전(us-east-1 제외)에서 Amazon S3 엔드포인트에 프록시를 사용하는 경우 리전으로 버킷 이름의 접두사를 지정합니다. 버킷 이름에 접두사가 지정되지 않은 경우 us-east-1 엔드포인트를 사용하여 자동으로 버킷 리전을 검색합니다.
1. [**모듈 소스 버킷 이름(Module Source Bucket Name)**]: (옵션) PowerShell 모듈 파일이 포함된 Amazon S3 버킷의 이름을 입력합니다. [**없음(None)**]을 지정하는 경우 [**PS 갤러리 모듈 소스 허용(Allow PS Gallery Module Source)**] 옵션에 대해 [**True**]를 선택합니다.
**참고**
버킷이 있는 리전으로 버킷 이름의 접두사를 지정할 수 있습니다. 예를 들면 `us-west-2:amzn-s3-demo-bucket`입니다. 특정 리전(us-east-1 제외)에서 Amazon S3 엔드포인트에 프록시를 사용하는 경우 리전으로 버킷 이름의 접두사를 지정합니다. 버킷 이름에 접두사가 지정되지 않은 경우 us-east-1 엔드포인트를 사용하여 자동으로 버킷 리전을 검색합니다.
1. [**PS 갤러리 모듈 소스 허용(Allow PS Gallery Module Source)**]: (옵션) [https://www.powershellgallery.com/](https://www.powershellgallery.com/)에서 PowerShell 모듈을 다운로드하려면 **True**를 선택합니다. [**False**]를 선택하는 경우 이전 옵션인 **ModuleSourceBucketName**에 대해 소스를 지정합니다.
1. **Proxy Uri(프록시 Uri)**: (선택 사항) 프록시 서버에서 MOF 파일을 다운로드하려면 이 옵션을 사용합니다.
1. **Reboot Behavior(재부팅 동작)**: (선택 사항) MOF 파일을 실행하려면 재부팅해야 하는 경우 다음 재부팅 동작 중 하나를 지정합니다.
+ **AfterMof**: 모든 MOF 실행이 완료되면 노드를 재부팅합니다. 여러 MOF 실행 요청이 재부팅되더라도 시스템에서는 모든 MOF 실행이 재부팅을 완료할 때까지 대기합니다.
+ **즉시(Immediately)**: MOF 실행 시 요청할 때마다 노드를 재부팅합니다. 재부팅을 요청하는 MOF 파일을 여러 개 실행하는 경우 노드가 여러 번 재부팅됩니다.
+ **안 함(Never)**: MOF 실행이 명시적으로 재부팅을 요청하더라도 노드가 재부팅되지 않습니다.
1. [**보고에 컴퓨터 이름 사용(Use Computer Name For Reporting)**]: (옵션) 규정 준수 정보를 보고할 때 컴퓨터의 이름을 사용하려면 이 옵션을 설정합니다. 기본값은 **false**로, 규정 준수 정보를 보고할 때 시스템에서 노드 ID를 사용함을 의미합니다.
1. [**상세 정보 로깅 활성화(Enable Verbose Logging)**]: (옵션) 처음으로 MOF 파일을 배포하는 경우 상세 정보 로깅을 설정하는 것이 좋습니다.
**중요**
허용되면 상세 정보 로깅은 표준 연결 실행 로깅보다 Amazon S3 버킷에 더 많은 데이터를 씁니다. 이로 인해 성능이 저하되고 Amazon S3에 대한 스토리지 비용이 높아질 수 있습니다. 스토리지 크기 문제를 완화하기 위해 Amazon S3 버킷에 대해 수명 주기 정책을 설정하는 것이 좋습니다. 자세한 내용은 *Amazon Simple Storage Service 사용 설명서*의 [S3 버킷에 대한 수명 주기 정책을 생성하려면 어떻게 해야 하나요?](https://docs.aws.amazon.com/AmazonS3/latest/userguide/create-lifecycle.html) 섹션을 참조하세요.
1. [**Enable Debug Logging(디버그 로깅 설정)**]: (옵션) MOF 실패 문제를 해결하려면 디버그 로깅을 설정하는 것이 좋습니다. 또한 일반적인 사용에는 이 옵션을 비활성화하는 것이 좋습니다.
**중요**
허용되면 디버그 로깅은 표준 연결 실행 로깅보다 Amazon S3 버킷에 더 많은 데이터를 씁니다. 이로 인해 성능이 저하되고 Amazon S3에 대한 스토리지 비용이 높아질 수 있습니다. 스토리지 크기 문제를 완화하기 위해 Amazon S3 버킷에 대해 수명 주기 정책을 설정하는 것이 좋습니다. 자세한 내용은 *Amazon Simple Storage Service 사용 설명서*의 [S3 버킷에 대한 수명 주기 정책을 생성하려면 어떻게 해야 하나요?](https://docs.aws.amazon.com/AmazonS3/latest/userguide/create-lifecycle.html) 섹션을 참조하세요.
1. **규정 준수 유형**: (선택 사항) 규정 준수 정보를 보고할 때 사용할 규정 준수 유형을 지정합니다. 기본 규정 준수 유형은 **Custom:DSC**입니다. MOF 파일을 실행하는 연결을 여러 개 생성하는 경우 각 연결에 대해 규정 준수 유형을 다르게 지정해야 합니다. 그렇지 않은 경우 **Custom:DSC**를 사용하는 각각의 추가 연결이 기존 규정 준수 데이터를 덮어씁니다.
1. **Pre Reboot Script(재부팅 전 스크립트)**: (선택 사항) 구성에 재부팅이 필요하다고 표시된 경우 실행할 스크립트를 지정합니다. 이 스크립트는 재부팅 전에 실행됩니다. 이 스크립트는 한 줄이어야 합니다. 세미콜론을 사용하여 추가 행을 구분합니다.
1. **대상** 섹션에서 **태그 지정** 또는 **수동으로 인스턴스 선택**을 선택합니다. 태그를 사용하여 리소스를 대상으로 지정하기로 한 경우 태그 키와 태그 값을 제공된 필드에 입력합니다. 태그 사용에 대한 자세한 내용은 [State Manager 연결에서의 대상 및 속도 제어 이해](systems-manager-state-manager-targets-and-rate-controls.md) 섹션을 참조하세요.
1. **일정 지정** 섹션에서 **On Schedule(일정이 있을 때)** 또는 **No schedule(일정이 없을 때)**을 선택합니다. **On Schedule(일정이 있을 때)**을 선택한 경우 제공된 버튼을 사용하여 연결에 대한 cron 또는 rate 일정을 생성합니다.
1. **고급 옵션** 섹션에서:
+ **규정 준수 심각도**에서 연결에 대한 심각도를 선택합니다. 규정 준수 보고는 여기서 지정한 심각도 수준과 함께 연결 상태가 준수인지 아니면 미준수인지를 나타냅니다. 자세한 내용은 [State Manager 연결 규정 준수 정보](compliance-about.md#compliance-about-association) 섹션을 참조하세요.
1. **속도 제어(Rate control)** 섹션에서 관리형 노드 플릿 간에 State Manager 연결을 실행하기 위한 옵션을 구성합니다. 이러한 옵션에 대한 자세한 내용은 [State Manager 연결에서의 대상 및 속도 제어 이해](systems-manager-state-manager-targets-and-rate-controls.md) 섹션을 참조하세요.
**동시성** 섹션에서 옵션을 선택합니다.
+ **대상**을 선택하여 연결을 동시에 실행할 수 있는 대상 수(절대 개수)를 입력합니다.
+ **백분율**을 선택하여 연결을 동시에 실행할 수 있는 대상의 백분율을 입력합니다.
**오류 임계값** 섹션에서 옵션을 선택합니다.
+ **오류**를 선택하여 State Manager에서 추가 대상에 대한 연결 실행을 중지하기 전에 허용되는 절대 오류 수를 입력합니다.
+ **백분율**을 선택하여 State Manager에서 추가 대상에 대한 연결 실행을 중지하기 전에 허용되는 오류 비율을 입력합니다.
1. (선택 사항) **출력 옵션**에서 명령 출력을 파일에 저장하려면 **S3 버킷에 쓰기 활성화** 옆의 상자를 선택합니다. 상자에 버킷 및 접두사(폴더) 이름을 입력합니다.
**참고**
데이터를 S3 버킷에 쓰는 기능을 부여하는 S3 권한은 이 작업을 수행하는 IAM 사용자의 권한이 아닌 관리형 노드에 할당된 인스턴스 프로파일의 권한입니다. 자세한 내용은 [Systems Manager에 필요한 인스턴스 권한 구성](setup-instance-permissions.md)이나 [하이브리드 환경을 위한 IAM 서비스 역할 생성](hybrid-multicloud-service-role.md)을 참조하세요. 또한 지정된 S3 버킷이 다른 AWS 계정에 있는 경우 관리형 노드와 연결된 인스턴스 프로파일 또는 IAM 서비스 역할은 해당 버킷에 쓸 수 있는 권한이 있어야 합니다.
1. **연결 생성**을 선택합니다.
State Manager는 지정된 노드 또는 대상에 대해 연결을 생성하고 즉시 실행합니다. 최초 실행 후 연결은 정의한 일정에 따른 간격으로 다음 규칙에 따라 실행됩니다.
+ State Manager는 간격이 시작될 때 온라인 상태인 노드에서 연결을 실행하고 오프라인 노드를 건너뜁니다.
+ State Manager에서는 간격 중 구성된 모든 노드에 대해 연결을 실행하려고 합니다.
+ (예를 들어, 동시성 값이 한 번에 연결을 처리할 수 있는 노드 수를 제한했기 때문에) 간격 동안 연결이 실행되지 않은 경우 State Manager에서는 다음 간격 중 해당 연결을 실행하려고 합니다.
+ State Manager는 건너 뛴 모든 간격을 기록합니다. 이러한 기록은 **실행 내역** 탭에서 확인할 수 있습니다.
**참고**
`AWS-ApplyDSCMofs`는 Systems Manager Command 문서입니다. 즉, AWS Systems Manager의 도구인 Run Command를 사용하여 이 문서를 실행할 수도 있습니다. 자세한 내용은 [AWS Systems Manager Run Command](run-command.md) 섹션을 참조하세요.
## MOF 파일을 실행하는 연결을 생성할 때 발생하는 문제 해결
이 단원에는 MOF 파일을 실행하는 연결 생성과 관련된 문제를 해결하기 위한 정보가 포함되어 있습니다.
**향상된 로깅 설정**
문제 해결의 첫 번째 단계로, 고급 로깅을 설정합니다. 보다 구체적으로 다음을 수행하세요.
1. Amazon S3 또는 Amazon CloudWatch Logs(CloudWatch)에 명령 출력을 쓰도록 연결이 구성되었는지 확인합니다.
1. **Enable Verbose Logging(상세 정보 로깅 활성화)** 파라미터를 True로 설정합니다.
1. **Enable Debug Logging(디버그 로깅 활성화)** 파라미터를 True로 설정합니다.
상세 정보 및 디버그 로깅이 설정되면 **Stdout** 출력 파일에 스크립트 실행에 대한 세부 정보가 포함됩니다. 이 출력 파일은 스크립트가 실패한 위치를 식별하는 데 유용할 수 있습니다. **Stderr** 출력 파일에는 스크립트 실행 중 발생한 오류가 포함됩니다.
**MOF 파일을 실행하는 연결을 생성할 때 발생하는 일반적인 문제**
이 단원에는 MOF 파일을 실행하는 연결 생성 시 발생할 수 있는 일반적인 문제에 대한 정보와 이러한 문제 해결 단계가 나와 있습니다.
**내 MOF가 적용되지 않음**
State Manager에서 노드에 연결을 적용하지 못하면 **Stderr** 출력 파일을 검토하는 것으로 시작합니다. 이 파일은 문제의 근본 원인을 파악하는 데 도움이 될 수 있습니다. 또한 다음을 확인합니다.
+ 노드에는 모든 MOF 관련 Amazon S3 버킷에 필요한 액세스 권한이 있습니다. 구체적으로 설명하면 다음과 같습니다.
+ **s3:GetObject 권한**: 프라이빗 Amazon S3 버킷의 MOF 파일과 Amazon S3 버킷의 사용자 정의 모듈에 필요합니다.
+ **s3:PutObject 권한**: Amazon S3 버킷에 규정 준수 보고서 및 규정 준수 상태를 쓰려면 필요합니다.
+ 태그를 사용하는 경우 노드에 필요한 IAM 정책이 있는지 확인합니다. 태그를 사용하려면 정책이 `ec2:DescribeInstances` 및 `ssm:ListTagsForResource` 작업을 허용하도록 하기 위해 인스턴스 IAM 역할이 필요합니다.
+ 노드에 예상한 태그가 있거나 SSM 파라미터가 할당되어 있는지 확인합니다.
+ 태그 또는 SSM 파라미터에 오탈자가 없는지 확인합니다.
+ MOF 파일 자체와 관련된 문제가 없는지 확인하기 위해 노드에서 MOF를 로컬로 적용해 보세요.
**내 MOF가 실패한 것 같지만 Systems Manager 실행에는 성공함**
`AWS-ApplyDSCMofs` 문서가 성공적으로 실행되면 Systems Manager 실행 상태에 [**성공(Success)**]이라고 표시됩니다. 이 상태는 MOF 파일의 구성 요구 사항을 기준으로 한 노드의 규정 준수 상태를 반영하지 않습니다. 노드의 규정 준수 상태를 확인하려면 규정 준수 보고서를 확인합니다. JSON 보고서는 Amazon S3 보고서 버킷에서 볼 수 있습니다. 이 내용은 Run Command 및 State Manager 실행에 적용됩니다. 또한 State Manager의 경우 Systems Manager Compliance 페이지에서 규정 준수 세부 정보를 확인할 수 있습니다.
**Stderr 상태: 서비스 연결 시도 시 이름 확인 실패**
이 오류는 스크립트가 원격 서비스에 연결할 수 없음을 나타냅니다. 이 스크립트는 Amazon S3에 연결하지 못할 가능성이 매우 큽니다. 대부분 이 문제는 스크립트가 문서 파라미터에 제공된 Amazon S3 버킷에 규정 준수 보고서 또는 규정 준수 상태를 쓰려고 할 때 발생합니다. 일반적으로 이 오류는 컴퓨팅 환경이 방화벽 또는 허용 목록을 포함한 투명한 프록시를 사용하는 경우 발생합니다. 이 문제를 해결하려면:
+ 모든 Amazon S3 버킷 파라미터에 대해 리전별 버킷 구문을 사용합니다. 예를 들어, **Mofs to Apply(적용할 Mof)** 파라미터의 형식은 다음과 같아야 합니다.
s3:*bucket-region*:*amzn-s3-demo-bucket*:*mof-file-name*.mof.
예: ` s3:us-west-2:amzn-s3-demo-bucket:my-mof.mof`
보고서, 상태 및 모듈 소스 버킷 이름의 형식은 다음과 같아야 합니다.
*bucket-region*:*amzn-s3-demo-bucket*. 단순 예시: `us-west-1:amzn-s3-demo-bucket;`
+ 리전별 구문으로 문제가 해결되지 않으면 대상 노드가 원하는 리전에서 Amazon S3에 액세스할 수 있는지 확인합니다. 이를 확인하려면 다음을 수행합니다.
1. 적절한 Amazon S3 리전에서 Amazon S3의 엔드포인트 이름을 찾습니다. 자세한 내용은 **Amazon Web Services 일반 참조의 [Amazon S3 서비스 엔드포인트](https://docs.aws.amazon.com/general/latest/gr/s3.html#s3_region)를 참조하세요.
1. 대상 노드에 로그온해 다음 ping 명령을 실행합니다.
```
ping s3.s3-region.amazonaws.com
```
ping에 실패하면 이는 Amazon S3이 다운되었거나, 방화벽/투명한 프록시가 Amazon S3 리전에 대한 액세스를 차단했거나, 노드가 인터넷에 액세스할 수 없는 것입니다.
## DSC 리소스 규정 준수 세부 정보 보기
Systems Manager는 `AWS-ApplyDSCMofs` 문서를 실행했을 때 지정한 Amazon S3 [**상태 버킷(Status Bucket)**]에서 DSC 리소스 실패에 대한 규정 준수 정보를 수집합니다. Amazon S3 버킷에서 DSC 리소스 실패에 대한 정보를 검색하는 데는 시간이 많이 걸릴 수 있습니다. 대신, Systems Manager [**Compliance**] 페이지에서 이 정보를 볼 수 있습니다.
**규정 준수 리소스 요약** 섹션에 실패한 리소스의 수가 표시됩니다. 다음 예에서 **ComplianceType**은 **Custom:DSC**이고 한 개의 리소스가 규정 미준수입니다.
**참고**
Custom:DSC는 `AWS-ApplyDSCMofs` 문서에서 기본 [**ComplianceType**] 값입니다. 이 값은 사용자 지정 가능합니다.
![\[[Compliance] 페이지의 [Compliance 리소스 요약(Compliance resources summary)] 섹션에서 개수 보기.\]](http://docs.aws.amazon.com/ko_kr/systems-manager/latest/userguide/images/state-manager-mof-detailed-status-3.png)
[**리소스에 대한 세부 정보 개요(Details overview for resources)**] 섹션에는 규정 미준수 DSC 리소스가 있는 AWS 리소스에 대한 정보가 표시됩니다. 이 섹션에는 또한 MOF 이름, 스크립트 실행 단계, 및 세부 상태 정보를 볼 수 있는 **출력 보기** 링크(적용되는 경우)도 포함됩니다.
![\[MOF 실행 리소스 실패에 대한 규정 준수 세부 정보 보기\]](http://docs.aws.amazon.com/ko_kr/systems-manager/latest/userguide/images/state-manager-mof-detailed-status-1.png)
[**출력 보기(View output)**] 링크는 세부 상태의 마지막 4,000자를 표시합니다. Systems Manager는 첫 번째 요소로 예외를 시작한 다음 자세한 메시지를 다시 검사하고 4,000자 할당량에 도달할 때까지 가능한 한 많이 추가합니다. 이 프로세스는 예외가 발생되기 전에 출력된 긴 메시지(문제 해결을 위해 가장 관련성이 높은 메시지)를 표시합니다.
![\[MOF 리소스 규정 준수 문제에 대한 자세한 출력 보기\]](http://docs.aws.amazon.com/ko_kr/systems-manager/latest/userguide/images/state-manager-mof-detailed-status-2.png)
규정 준수 정보를 보는 방법에 대한 자세한 내용은 [AWS Systems Manager Compliance](systems-manager-compliance.md) 섹션을 참조하세요.
**규정 준수 보고에 영향을 미치는 상황**
State Manager 연결이 실패한 경우에는 규정 준수 데이터가 보고되지 않습니다. 보다 구체적으로, MOF가 처리되지 못한다면 연결이 실패하기 때문에 Systems Manager가 어떤 규정 준수 항목도 보고하지 않습니다. 예를 들어, Systems Manager가 노드에 액세스할 권한이 없는 Amazon S3 버킷에서 MOF를 다운로드하려고 시도하면 연결이 실패하고 어떠한 규정 준수 데이터도 보고되지 않습니다.
두 번째 MOF의 리소스가 실패하면 Systems Manager가 규정 준수 데이터를 *보고합니다*. 예를 들어 MOF가 존재하지 않는 드라이브에서 파일을 생성하려고 하면 `AWS-ApplyDSCMofs` 문서가 완전히 처리될 수 있기 때문에(즉, 연결이 성공적으로 실행될 수 있기 때문에) Systems Manager가 규정 준수를 보고합니다.
# Ansible 플레이북을 실행하는 연결 생성
`AWS-ApplyAnsiblePlaybooks` SSM 문서를 사용하여 Ansible 플레이북을 실행하는 State Manager 연결을 생성할 수 있습니다. State Manager는 AWS Systems Manager의 도구입니다. 이 문서는 플레이북 실행을 위해 다음과 같은 이점을 제공합니다.
+ 복잡한 플레이북 실행 지원
+ GitHub 및 Amazon Simple Storage Service(S3)에서 플레이북 다운로드 지원
+ 압축된 플레이북 구조 지원
+ 향상된 로깅
+ 플레이북이 번들로 제공될 때 실행할 플레이북 지정 가능
**참고**
Systems Manager에는 Ansible 플레이북을 실행하는 State Manager 연결을 생성하는 데 사용할 수 있는 SSM 문서가 2개(`AWS-RunAnsiblePlaybook`, `AWS-ApplyAnsiblePlaybooks`)가 포함되어 있습니다. `AWS-RunAnsiblePlaybook` 문서는 더 이상 사용되지 않습니다. Systems Manager에서 레거시용으로 제공됩니다. `AWS-ApplyAnsiblePlaybooks` 문서에 여기서 설명한 기능 향상 부분이 있으므로 이 문서를 사용하는 것이 좋습니다.
Ansible 플레이북을 실행하는 연결은 macOS에서 지원되지 않습니다.
**복잡한 플레이북 실행 지원**
`AWS-ApplyAnsiblePlaybooks` 문서는 지정된 주요 플레이북을 실행하기 전에 먼저 로컬 디렉터리에 전체 파일 구조를 복사하므로 번들로 제공되는 복잡한 플레이북을 지원합니다. 소스 플레이북은 zip 파일 또는 디렉터리 구조로 제공할 수 있습니다. Zip 파일이나 디렉터리는 GitHub 또는 Amazon S3에 저장할 수 있습니다.
**GitHub에서 플레이북 다운로드 지원**
`AWS-ApplyAnsiblePlaybooks` 문서는 `aws:downloadContent` 플러그인을 사용하여 플레이북 파일을 다운로드합니다. 파일은 GitHub에 한 개의 파일로 또는 결합된 플레이북 세트로 저장할 수 있습니다. GitHub에서 콘텐츠를 다운로드하려면 GitHub 리포지토리에 대한 정보를 JSON 형식으로 지정합니다. 다음 예를 참고하세요
```
{
"owner":"TestUser",
"repository":"GitHubTest",
"path":"scripts/python/test-script",
"getOptions":"branch:master",
"tokenInfo":"{{ssm-secure:secure-string-token}}"
}
```
**Amazon S3에서 플레이북 다운로드 지원**
Amazon S3에서 Ansible 플레이북을 단일 .zip 파일 또는 디렉터리 구조로 저장하고 다운로드할 수도 있습니다. Amazon S3에서 콘텐츠를 다운로드하려면 파일에 대한 경로를 지정합니다. 다음은 두 가지 예입니다.
**예 1: 특정 플레이북 파일 다운로드**
```
{
"path":"https://s3.amazonaws.com/amzn-s3-demo-bucket/playbook.yml"
}
```
**예 2: 디렉터리 콘텐츠 다운로드**
```
{
"path":"https://s3.amazonaws.com/amzn-s3-demo-bucket/ansible/webservers/"
}
```
**중요**
Amazon S3를 지정한 경우 관리형 노드의 AWS Identity and Access Management(IAM) 인스턴스 프로파일에 S3 버킷에 대한 권한이 포함되어야 합니다. 자세한 내용은 [Systems Manager에 필요한 인스턴스 권한 구성](setup-instance-permissions.md)을 참조하세요.
**압축된 플레이북 구조 지원**
`AWS-ApplyAnsiblePlaybooks` 문서를 사용하면 다운로드한 번들에서 압축된 .zip 파일을 실행할 수 있습니다. 문서는 압축된 파일이 다운로드한 파일에 .zip 형식으로 포함되어 있는지 점검합니다. .zip 파일이 있으면 문서는 자동으로 파일 압축을 푼 다음 지정된 Ansible 자동화를 실행합니다.
**향상된 로깅**
`AWS-ApplyAnsiblePlaybooks` 문서에는 다양한 로깅 수준을 지정하는 데 필요한 파라미터 옵션이 포함되어 있습니다. 세부 수준이 낮으면 -v를, 중간이면 -vvv를, 디버그 레벨 로깅 수준이면 -vvvv를 지정합니다. 이러한 옵션은 Ansible 세부 수준 옵션에 직접 매핑됩니다.
**플레이북이 번들로 제공될 때 실행할 플레이북 지정 가능**
`AWS-ApplyAnsiblePlaybooks` 문서에는 여러 개의 플레이북이 번들로 제공될 때 실행할 플레이북을 지정하는 데 필요한 파라미터가 포함되어 있습니다. 이 옵션을 사용하면 다양한 사용 사례를 지원하도록 플레이북을 유연하게 실행할 수 있습니다.
## 설치된 종속성 이해
**InstallDependencies** 파라미터에 **True**를 지정하면 Systems Manager는 노드에 다음 종속성이 설치되어 있는지 확인합니다.
+ **Ubuntu Server/Debian Server**: Apt-get(패키지 관리), Python 3, Ansible, Unzip
+ **Amazon Linux** 지원 버전: Ansible
+ **RHEL**: Python 3, Ansible, Unzip
이 종속성 중 하나 이상이 없다면 Systems Manager는 해당 종속성을 자동으로 설치합니다.
## Ansible 플레이북을 실행하는 연결 생성(콘솔)
다음 절차에서는 Systems Manager 콘솔을 사용하여 `AWS-ApplyAnsiblePlaybooks` 문서로 Ansible 플레이북을 실행하는 State Manager 연결을 생성하는 방법을 설명합니다.
**Ansible 플레이북을 실행하는 연결을 생성하려면(콘솔)**
1. [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)에서 AWS Systems Manager 콘솔을 엽니다.
1. 탐색 창에서 **State Manager**를 선택합니다.
1. **State Manager**를 선택하고 **Create association(연결 생성)**을 선택합니다.
1. **이름**에 연결의 목적을 기억하는 데 도움이 되는 이름을 지정합니다.
1. [**문서(Document)**] 목록에서 **`AWS-ApplyAnsiblePlaybooks`**를 선택합니다.
1. **파라미터** 섹션의 **소스 유형**에서 **GitHub** 또는 **S3**를 선택합니다.
**GitHub**
**GitHub**를 선택하는 경우 다음 형식으로 리포지토리 정보를 입력합니다.
```
{
"owner":"user_name",
"repository":"name",
"path":"path_to_directory_or_playbook_to_download",
"getOptions":"branch:branch_name",
"tokenInfo":"{{(Optional)_token_information}}"
}
```
**S3**
[**S3**]를 선택하는 경우 다음 형식으로 경로 정보를 입력합니다.
```
{
"path":"https://s3.amazonaws.com/path_to_directory_or_playbook_to_download"
}
```
1. **종속성 설치**에서 옵션을 선택합니다.
1. (선택 사항) **Playbook File(플레이북 파일)**에 파일 이름을 입력합니다. Zip 파일에 플레이북이 포함된 경우 Zip 파일에 대한 상대 경로를 지정합니다.
1. (선택 사항) **추가 변수**에서 실행 시간 동안 State Manager에서 Ansible에 전송할 변수를 입력합니다.
1. (선택 사항) **확인**에서 옵션을 선택합니다.
1. (선택 사항) **상세 표시**에서 옵션을 선택합니다.
1. **대상**에서 옵션을 선택합니다. 태그 사용에 대한 자세한 내용은 [State Manager 연결에서의 대상 및 속도 제어 이해](systems-manager-state-manager-targets-and-rate-controls.md) 섹션을 참조하세요.
1. **일정 지정** 섹션에서 **On Schedule(일정이 있을 때)** 또는 **No schedule(일정이 없을 때)**을 선택합니다. **On Schedule(일정이 있을 때)**을 선택한 경우 제공된 버튼을 사용하여 연결에 대한 cron 또는 rate 일정을 생성합니다.
1. **고급 옵션** 섹션의 **규정 준수 심각도**에서 연결에 대한 심각도 수준을 선택합니다. 규정 준수 보고는 여기서 지정한 심각도 수준과 함께 연결 상태가 준수인지 아니면 미준수인지를 나타냅니다. 자세한 내용은 [State Manager 연결 규정 준수 정보](compliance-about.md#compliance-about-association) 섹션을 참조하세요.
1. **Rate control(속도 제어)** 섹션에서 관리형 노드 플릿 간에 State Manager 연결을 실행하기 위한 옵션을 구성합니다. 속도 제어 사용에 대한 자세한 내용은 [State Manager 연결에서의 대상 및 속도 제어 이해](systems-manager-state-manager-targets-and-rate-controls.md) 섹션을 참조하세요.
**동시성** 섹션에서 옵션을 선택합니다.
+ **대상**을 선택하여 연결을 동시에 실행할 수 있는 대상 수(절대 개수)를 입력합니다.
+ **백분율**을 선택하여 연결을 동시에 실행할 수 있는 대상의 백분율을 입력합니다.
**오류 임계값** 섹션에서 옵션을 선택합니다.
+ **오류**를 선택하여 State Manager에서 추가 대상에 대한 연결 실행을 중지하기 전에 허용되는 절대 오류 수를 입력합니다.
+ **백분율**을 선택하여 State Manager에서 추가 대상에 대한 연결 실행을 중지하기 전에 허용되는 오류 비율을 입력합니다.
1. (선택 사항) **출력 옵션**에서 명령 출력을 파일에 저장하려면 **S3 버킷에 쓰기 활성화** 옆의 상자를 선택합니다. 상자에 버킷 및 접두사(폴더) 이름을 입력합니다.
**참고**
데이터를 S3 버킷에 쓰는 기능을 부여하는 S3 권한은 이 작업을 수행하는 IAM 사용자의 권한이 아닌 관리형 노드에 할당된 인스턴스 프로파일의 권한입니다. 자세한 내용은 [Systems Manager에 필요한 인스턴스 권한 구성](setup-instance-permissions.md)이나 [하이브리드 환경을 위한 IAM 서비스 역할 생성](hybrid-multicloud-service-role.md)을 참조하세요. 또한 지정된 S3 버킷이 다른 AWS 계정에 있는 경우 관리형 노드와 연결된 인스턴스 프로파일 또는 IAM 서비스 역할은 해당 버킷에 쓸 수 있는 권한이 있어야 합니다.
1. **연결 생성**을 선택합니다.
**참고**
태그를 사용하여 하나 이상의 대상 노드에 대해 연결을 생성한 다음 노드에서 태그를 제거하면 해당 노드가 더 이상 연결을 실행하지 않습니다. 이러한 노드는 State Manager 문서에서 연결 해제됩니다.
## Ansible 플레이북을 실행하는 연결 생성(CLI)
다음 절차에서는 AWS Command Line Interface(AWS CLI)을 사용하여 `AWS-ApplyAnsiblePlaybooks` 문서로 Ansible 플레이북을 실행하는 State Manager 연결을 생성하는 방법을 설명합니다.
**Ansible 플레이북을 실행하는 연결을 생성하려면(CLI)**
1. 아직 하지 않은 경우 AWS Command Line Interface(AWS CLI)을 설치하고 구성합니다.
자세한 내용은 [최신 버전의 AWS CLI 설치 또는 업데이트](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html)를 참조하세요.
1. 다음 명령 중 하나를 실행하면 태그로 노드를 대상 지정하여 Ansible 플레이북을 실행하는 연결을 생성할 수 있습니다. 각 *example resource placeholder*를 사용자의 정보로 바꿉니다. Command (A)는 소스 유형으로 GitHub를 지정합니다. Command (B)는 소스 유형으로 Amazon S3를 지정합니다.
**(A) GitHub 소스**
------
#### [ Linux & macOS ]
```
aws ssm create-association --name "AWS-ApplyAnsiblePlaybooks" \
--targets Key=tag:TagKey,Values=TagValue \
--parameters '{"SourceType":["GitHub"],"SourceInfo":["{\"owner\":\"owner_name\", \"repository\": \"name\", \"getOptions\": \"branch:master\"}"],"InstallDependencies":["True_or_False"],"PlaybookFile":["file_name.yml"],"ExtraVariables":["key/value_pairs_separated_by_a_space"],"Check":["True_or_False"],"Verbose":["-v,-vv,-vvv, or -vvvv"],"TimeoutSeconds":["3600"]}' \
--association-name "name" \
--schedule-expression "cron_or_rate_expression"
```
------
#### [ Windows ]
```
aws ssm create-association --name "AWS-ApplyAnsiblePlaybooks" ^
--targets Key=tag:TagKey,Values=TagValue ^
--parameters '{"SourceType":["GitHub"],"SourceInfo":["{\"owner\":\"owner_name\", \"repository\": \"name\", \"getOptions\": \"branch:master\"}"],"InstallDependencies":["True_or_False"],"PlaybookFile":["file_name.yml"],"ExtraVariables":["key/value_pairs_separated_by_a_space"],"Check":["True_or_False"],"Verbose":["-v,-vv,-vvv, or -vvvv"], "TimeoutSeconds":["3600"]}' ^
--association-name "name" ^
--schedule-expression "cron_or_rate_expression"
```
------
다음 예를 참고하세요
```
aws ssm create-association --name "AWS-ApplyAnsiblePlaybooks" \
--targets "Key=tag:OS,Values=Linux" \
--parameters '{"SourceType":["GitHub"],"SourceInfo":["{\"owner\":\"ansibleDocumentTest\", \"repository\": \"Ansible\", \"getOptions\": \"branch:master\"}"],"InstallDependencies":["True"],"PlaybookFile":["hello-world-playbook.yml"],"ExtraVariables":["SSM=True"],"Check":["False"],"Verbose":["-v"]}' \
--association-name "AnsibleAssociation" \
--schedule-expression "cron(0 2 ? * SUN *)"
```
**(B) S3 소스**
------
#### [ Linux & macOS ]
```
aws ssm create-association --name "AWS-ApplyAnsiblePlaybooks" \
--targets Key=tag:TagKey,Values=TagValue \
--parameters '{"SourceType":["S3"],"SourceInfo":["{\"path\":\"https://s3.amazonaws.com/path_to_Zip_file,_directory,_or_playbook_to_download\"}"],"InstallDependencies":["True_or_False"],"PlaybookFile":["file_name.yml"],"ExtraVariables":["key/value_pairs_separated_by_a_space"],"Check":["True_or_False"],"Verbose":["-v,-vv,-vvv, or -vvvv"]}' \
--association-name "name" \
--schedule-expression "cron_or_rate_expression"
```
------
#### [ Windows ]
```
aws ssm create-association --name "AWS-ApplyAnsiblePlaybooks" ^
--targets Key=tag:TagKey,Values=TagValue ^
--parameters '{"SourceType":["S3"],"SourceInfo":["{\"path\":\"https://s3.amazonaws.com/path_to_Zip_file,_directory,_or_playbook_to_download\"}"],"InstallDependencies":["True_or_False"],"PlaybookFile":["file_name.yml"],"ExtraVariables":["key/value_pairs_separated_by_a_space"],"Check":["True_or_False"],"Verbose":["-v,-vv,-vvv, or -vvvv"]}' ^
--association-name "name" ^
--schedule-expression "cron_or_rate_expression"
```
------
다음 예를 참고하세요
```
aws ssm create-association --name "AWS-ApplyAnsiblePlaybooks" \
--targets "Key=tag:OS,Values=Linux" \
--parameters '{"SourceType":["S3"],"SourceInfo":["{\"path\":\"https://s3.amazonaws.com/amzn-s3-demo-bucket/playbook.yml\"}"],"InstallDependencies":["True"],"PlaybookFile":["playbook.yml"],"ExtraVariables":["SSM=True"],"Check":["False"],"Verbose":["-v"]}' \
--association-name "AnsibleAssociation" \
--schedule-expression "cron(0 2 ? * SUN *)"
```
**참고**
State Manager 연결은 cron 및 rate 표현식 중 일부를 지원하지 않습니다. 연결에 대한 cron 및 rate 표현식을 생성하는 방법에 대한 자세한 내용은 [참조: Systems Manager용 Cron 및 Rate 표현식](reference-cron-and-rate-expressions.md) 섹션을 참조하세요.
시스템은 해당 노드에 연결을 생성하고 그 상태를 즉시 적용하려고 합니다.
1. 다음 명령을 실행하여 방금 생성한 연결의 업데이트된 상태를 확인합니다.
```
aws ssm describe-association --association-id "ID"
```
# Chef 레시피를 실행하는 연결 생성
Chef SSM 문서를 사용하여 AWS Systems Manager 레시피를 실행하는 State Manager 연결을 생성할 수 있습니다. State Manager는 `AWS-ApplyChefRecipes`의 도구입니다. `AWS-ApplyChefRecipes` SSM 문서를 사용하여 Linux 기반 Systems Manager 관리형 노드를 대상으로 지정할 수 있습니다. 이 문서는 Chef 레시피 실행을 위해 다음과 같은 이점을 제공합니다.
+ 여러 Chef 릴리스(Chef 11\$1Chef 18)를 지원합니다.
+ 대상 노드에 Chef 클라이언트 소프트웨어를 자동으로 설치합니다.
+ 선택적으로 대상 노드에 대해 [Systems Manager 규정 준수 점검](systems-manager-compliance.md)을 실행하고 규정 준수 점검 결과를 Amazon Simple Storage Service(Amazon S3) 버킷에 저장합니다.
+ 문서를 한 번 실행할 때 여러 쿡북과 레시피를 실행합니다.
+ 선택적으로 `why-run` 모드에서 레시피를 실행하여 변경하지 않고 대상 노드에서 변경되는 레시피를 표시합니다.
+ 선택적으로 사용자 지정 JSON 속성을 `chef-client` 실행에 적용합니다.
+ 사용자가 지정하는 위치에 저장된 소스 파일의 사용자 지정 JSON 속성을 선택적으로 적용합니다.
[Git](#state-manager-chef-git), [GitHub](#state-manager-chef-github), [HTTP](#state-manager-chef-http) 또는 [Amazon S3](#state-manager-chef-s3) 버킷을 `AWS-ApplyChefRecipes` 문서에서 사용자가 지정하는 Chef 쿡북 및 레시피의 다운로드 소스로 사용할 수 있습니다.
**참고**
Chef 레시피를 실행하는 연결은 macOS에서 지원되지 않습니다.
## 시작하기
`AWS-ApplyChefRecipes` 문서를 만들기 전에 Chef 쿡북과 쿡북 리포지토리를 준비합니다. 사용하려는 Chef 쿡북이 없는 경우 AWS에서 준비한 테스트 `HelloWorld` 쿡북을 사용하여 시작할 수 있습니다. `AWS-ApplyChefRecipes` 문서는 이미 기본적으로 이 쿡북을 가리키고 있습니다. 쿡북은 다음 디렉터리 구조와 유사하게 설정되어야 합니다. 다음 예에서 `jenkins` 및 `nginx`는 Chef 웹사이트의 [https://supermarket.chef.io/](https://supermarket.chef.io/)에서 사용할 수 있는 Chef 쿡북의 예입니다.
AWS에서 [https://supermarket.chef.io/](https://supermarket.chef.io/) 웹사이트의 쿡북을 공식적으로 지원할 수는 없지만 많은 사람들이 `AWS-ApplyChefRecipes` 문서를 사용합니다. 다음은 커뮤니티 쿡북을 테스트할 때 확인할 기준의 예입니다.
+ 쿡북은 대상으로 하는 Systems Manager 관리형 노드의 Linux 기반 운영 체제를 지원해야 합니다.
+ 쿡북은 사용자가 사용하는 Chef 클라이언트 버전(Chef 11\$1Chef 18)에 대해 유효해야 합니다.
+ 쿡북은 Chef Infra Client와 호환되며 Chef 서버가 필요하지 않습니다.
Systems Manager 문서(SSM 문서)가 실행될 때 실행 목록에 지정된 쿡북을 설치할 수 있도록 `Chef.io` 웹사이트에 연결할 수 있는지 확인합니다. 중첩된 `cookbooks` 폴더 사용은 지원되지만 필수는 아닙니다. 루트 수준 바로 아래에 쿡북을 저장할 수 있습니다.
```
└── cookbooks (optional level)
├── jenkins
│ ├── metadata.rb
│ └── recipes
└── nginx
├── metadata.rb
└── recipes
```
**중요**
Chef 레시피를 실행하는 State Manager 연결을 생성하기 전에 **Chef 클라이언트 버전** 값을 `None`으로 설정하지 않는 한 문서 실행 시 Systems Manager 관리형 노드에 Chef 클라이언트 소프트웨어가 설치된다는 점에 유의하세요. 이 작업은 Chef의 설치 스크립트를 사용하여 사용자 대신 Chef 구성 요소를 설치합니다. `AWS-ApplyChefRecipes` 문서를 실행하기 전에 기업이 Chef 소프트웨어 사용에 적용되는 라이선스 조건을 포함하여 적용 가능한 법적 요구 사항을 준수할 수 있는지 확인합니다. 자세한 내용은 [Chef 웹사이트](https://www.chef.io/)를 참조하세요.
Systems Manager는 규정 준수 보고서를 Systems Manager 콘솔인 S3 버킷에 제공하거나, Systems Manager API 명령에 대한 응답에서 규정 준수 결과를 사용하도록 만들 수 있습니다. Systems Manager 규정 준수 보고서를 실행하려면 Systems Manager 관리형 노드에 연결된 인스턴스 프로파일에 S3 버킷에 대한 쓰기 권한이 있어야 합니다. 인스턴스 프로파일에는 Systems Manager `PutComplianceItem` API를 사용할 권한이 있어야 합니다. Systems Manager 규정 준수에 대한 자세한 내용은 [AWS Systems Manager Compliance](systems-manager-compliance.md) 섹션을 참조하세요.
### 실행 문서 로깅
State Manager 연결을 사용하여 Systems Manager 문서(SSM 문서)를 실행할 때 문서 실행의 출력을 선택하도록 연결을 구성할 수 있으며 출력을 Amazon S3 또는 Amazon CloudWatch Logs(CloudWatch Logs)로 전송할 수 있습니다. 연결 실행이 완료될 때 문제 해결을 쉽게 하려면 연결이 Amazon S3 버킷 또는 CloudWatch Logs에 명령 출력을 쓰도록 구성되어 있는지 확인합니다. 자세한 내용은 [Systems Manager에서 연결 작업](state-manager-associations.md) 섹션을 참조하세요.
## 레시피 실행 시 대상에 JSON 속성 적용
연결 실행 중에 대상 노드에 적용할 Chef 클라이언트의 JSON 속성을 지정할 수 있습니다. 연결을 설정할 때 원시 JSON을 제공하거나 Amazon S3에 저장된 JSON 파일의 경로를 제공할 수 있습니다.
레시피가 실행되는 방식을 사용자 정의하려는 경우 레시피 자체를 수정할 필요 없이 JSON 속성을 사용합니다. 예를 들면 다음과 같습니다.
+ **소수의 속성 재정의**
사용자 지정 JSON을 사용하면 사소한 차이를 수용하기 위해 레시피를 여러 버전으로 유지하지 않아도 됩니다.
+ **변수 값 제공**
사용자 지정 JSON을 사용하여, 실행할 때마다 변경될 수 있는 값을 지정합니다. 예를 들어 Chef 쿡북이 결제를 허용하는 타사 애플리케이션을 구성하는 경우 사용자 지정 JSON을 사용하여 결제 엔드포인트 URL을 지정할 수 있습니다.
**원시 JSON에 속성 지정**
다음은 Chef 레시피의 사용자 지정 JSON 속성 지정에 사용할 수 있는 형식의 예제입니다.
```
{"filepath":"/tmp/example.txt", "content":"Hello, World!"}
```
**JSON 파일 경로 지정**
다음은 Chef 레시피의 사용자 지정 JSON 속성 경로 지정에 사용할 수 있는 형식의 예제입니다.
```
{"sourceType":"s3", "sourceInfo":"someS3URL1"}, {"sourceType":"s3", "sourceInfo":"someS3URL2"}
```
## 쿡북 소스로 Git 사용
`AWS-ApplyChefRecipes` 문서는[aws:downloadContent](documents-command-ssm-plugin-reference.md#aws-downloadContent) 플러그인을 사용하여 Chef 쿡북을 다운로드합니다. Git에서 콘텐츠를 다운로드하려면 Git 리포지토리에 대한 정보를 다음 예제와 같이 JSON 형식으로 지정합니다. 각 *example-resource-placeholder*를 자신의 정보로 바꿉니다.
```
{
"repository":"GitCookbookRepository",
"privateSSHKey":"{{ssm-secure:ssh-key-secure-string-parameter}}",
"skipHostKeyChecking":"false",
"getOptions":"branch:refs/head/main",
"username":"{{ssm-secure:username-secure-string-parameter}}",
"password":"{{ssm-secure:password-secure-string-parameter}}"
}
```
## GitHub을 쿡북 소스로 사용
`AWS-ApplyChefRecipes` 문서는 [aws:downloadContent](documents-command-ssm-plugin-reference.md#aws-downloadContent) 플러그인을 사용하여 쿡북을 다운로드합니다. GitHub에서 콘텐츠를 다운로드하려면 GitHub 리포지토리에 대한 정보를 다음 예제와 같이 JSON 형식으로 지정합니다. 각 *example-resource-placeholder*를 자신의 정보로 바꿉니다.
```
{
"owner":"TestUser",
"repository":"GitHubCookbookRepository",
"path":"cookbooks/HelloWorld",
"getOptions":"branch:refs/head/main",
"tokenInfo":"{{ssm-secure:token-secure-string-parameter}}"
}
```
## 쿡북 소스로 HTTP 사용
Chef 쿡북을 사용자 지정 HTTP 위치에 단일 `.zip` 또는 `tar.gz` 파일이나 디렉터리 구조로 저장할 수 있습니다. HTTP에서 콘텐츠를 다운로드하려면 파일 또는 디렉터리 경로를 다음 예제와 같이 JSON 형식으로 지정합니다. 각 *example-resource-placeholder*를 자신의 정보로 바꿉니다.
```
{
"url":"https://my.website.com/chef-cookbooks/HelloWorld.zip",
"allowInsecureDownload":"false",
"authMethod":"Basic",
"username":"{{ssm-secure:username-secure-string-parameter}}",
"password":"{{ssm-secure:password-secure-string-parameter}}"
}
```
## Amazon S3를 쿡북 소스로 사용
Amazon S3에서 Chef 쿡북을 단일 `.zip` 또는 `tar.gz` 파일이나 디렉터리 구조로 저장하고 다운로드할 수도 있습니다. Amazon S3에서 콘텐츠를 다운로드하려면 파일 경로를 다음 예제와 같이 JSON 형식으로 지정합니다. 각 *example-resource-placeholder*를 자신의 정보로 바꿉니다.
**예제 1: 특정 쿡북 다운로드**
```
{
"path":"https://s3.amazonaws.com/chef-cookbooks/HelloWorld.zip"
}
```
**예 2: 디렉터리 콘텐츠 다운로드**
```
{
"path":"https://s3.amazonaws.com/chef-cookbooks-test/HelloWorld"
}
```
**중요**
Amazon S3를 지정하면 `AmazonS3ReadOnlyAccess` 정책을 사용하여 관리형 노드에 있는 AWS Identity and Access Management(IAM) 노드 프로파일을 구성해야 합니다. 자세한 내용은 [Systems Manager에 필요한 인스턴스 권한 구성](setup-instance-permissions.md)을 참조하세요.
## Chef 레시피를 실행하는 연결 생성(콘솔)
다음 절차에서는 Systems Manager 콘솔을 사용하여 `AWS-ApplyChefRecipes` 문서로 Chef 쿡북을 실행하는 State Manager 연결을 생성하는 방법을 설명합니다.
1. [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)에서 AWS Systems Manager 콘솔을 엽니다.
1. 탐색 창에서 **State Manager**를 선택합니다.
1. **State Manager**를 선택하고 **Create association(연결 생성)**을 선택합니다.
1. **이름**에 연결의 목적을 기억하는 데 도움이 되는 이름을 입력합니다.
1. [**문서(Document)**] 목록에서 **`AWS-ApplyChefRecipes`**를 선택합니다.
1. **파라미터**에서 **소수 유형**은 **Git**, **GitHub**, **HTTP** 또는 **S3** 중에서 선택합니다.
1. **소스 정보**에는 6단계에서 선택한 **소스 유형**에 적합한 형식을 사용하여 쿡북 소스 정보를 입력합니다. 자세한 내용은 다음 항목을 참조하세요.
+ [쿡북 소스로 Git 사용](#state-manager-chef-git)
+ [GitHub을 쿡북 소스로 사용](#state-manager-chef-github)
+ [쿡북 소스로 HTTP 사용](#state-manager-chef-http)
+ [Amazon S3를 쿡북 소스로 사용](#state-manager-chef-s3)
1. **Run list(실행 목록)**에서 다음과 같이 각 레시피를 쉼표로 구분하여 실행할 레시피를 나열합니다. 쉼표 뒤에 공백을 넣지 않습니다. 각 *example-resource-placeholder*를 자신의 정보로 바꿉니다.
```
recipe[cookbook-name1::recipe-name],recipe[cookbook-name2::recipe-name]
```
1. (선택 사항) Chef 클라이언트를 통해 대상 노드에 전달하려는 사용자 지정 JSON 속성을 지정합니다.
1. **JSON 속성 콘텐츠**에서 Chef 클라이언트를 통해 대상 노드에 전달하려는 모든 속성을 추가합니다.
1. **JSON 속성 소스**에서 Chef 클라이언트를 통해 대상 노드에 전달하려는 모든 속성의 경로를 추가합니다.
자세한 내용은 [레시피 실행 시 대상에 JSON 속성 적용](#apply-custom-json-attributes) 섹션을 참조하세요.
1. **Chef 클라이언트 버전**에서 Chef 버전을 지정합니다. 유효한 값은 `11`\$1`18` 또는 `None`입니다. `11`부터 `18`까지의 숫자를 지정하면 Systems Manager에서는 대상 노드에 올바른 Chef 클라이언트 버전을 설치합니다. `None`을 지정한 경우 Systems Manager는 문서의 레시피를 실행하기 전에 대상 노드에 Chef 클라이언트를 설치하지 않습니다.
1. (옵션) **Chef 클라이언트 인수**에서 사용 중인 Chef 버전에 대해 지원되는 추가 인수를 지정합니다. 지원되는 인수에 대한 자세한 내용을 보려면 Chef 클라이언트를 실행하는 노드에서 `chef-client -h`를 실행하세요.
1. (옵션) **Why-run**을 설정하여 대상 노드를 실제로 변경하지 않고 레시피를 실행할 경우 대상 노드에 적용되는 변경 사항을 표시합니다.
1. [**규정 준수 심각도(Compliance severity)**]에서 보고할 Systems Manager Compliance 결과의 심각도를 선택합니다. 규정 준수 보고는 지정한 심각도 수준과 함께 연결 상태가 규정을 준수하는지 여부를 나타냅니다. Compliance 보고서는 [**Compliance 보고서 버킷(Compliance report bucket)**] 파라미터 값(14단계)으로 지정하는 S3 버킷에 저장됩니다. Compliance에 대한 자세한 내용은 이 가이드의 [규정 준수에 대해 자세히 알아보기](compliance-about.md) 섹션을 참조하세요.
규정 준수 검사는 Chef 레시피 및 노드 리소스에 지정된 구성 간의 드리프트를 측정합니다. 유효한 값은 `Critical`, `High`, `Medium`, `Low`, `Informational`, `Unspecified` 또는 `None`입니다. 규정 준수 보고를 건너뛰려면 `None`을 선택합니다.
1. **규정 준수 유형**에서 결과를 보고할 규정 준수 유형을 지정합니다. 유효한 값은 State Manager 연결의 경우 `Association` 또는 `Custom:`*custom\$1type*입니다. 기본값은 `Custom:Chef`입니다.
1. **Compliance 보고서 버킷**의 경우 리소스 구성 및 Compliance 결과를 포함하여 이 문서에서 수행한 모든 Chef에 대한 정보를 저장할 S3 버킷의 이름을 입력합니다.
1. **Rate control(속도 제어)**에서 관리형 노드 플릿 간에 State Manager 연결을 실행하기 위한 옵션을 구성합니다. 속도 제어 사용에 대한 자세한 내용은 [State Manager 연결에서의 대상 및 속도 제어 이해](systems-manager-state-manager-targets-and-rate-controls.md) 섹션을 참조하세요.
**동시성**에서 옵션을 선택합니다.
+ **대상**을 선택하여 연결을 동시에 실행할 수 있는 대상 수(절대 개수)를 입력합니다.
+ **백분율**을 선택하여 연결을 동시에 실행할 수 있는 대상의 백분율을 입력합니다.
**Error threshold(오류 임계값)**에서 옵션을 선택합니다.
+ **오류**를 선택하여 State Manager에서 추가 대상에 대한 연결 실행을 중지하기 전에 허용되는 절대 오류 수를 입력합니다.
+ **백분율**을 선택하여 State Manager에서 추가 대상에 대한 연결 실행을 중지하기 전에 허용되는 오류 비율을 입력합니다.
1. (선택 사항) **출력 옵션**에서 명령 출력을 파일에 저장하려면 **S3 버킷에 쓰기 활성화** 옆의 상자를 선택합니다. 상자에 버킷 및 접두사(폴더) 이름을 입력합니다.
**참고**
데이터를 S3 버킷에 쓰는 기능을 부여하는 S3 권한은 이 작업을 수행하는 IAM 사용자의 권한이 아닌 관리형 노드에 할당된 인스턴스 프로파일의 권한입니다. 자세한 내용은 [Systems Manager에 필요한 인스턴스 권한 구성](setup-instance-permissions.md)이나 [하이브리드 환경을 위한 IAM 서비스 역할 생성](hybrid-multicloud-service-role.md)을 참조하세요. 또한 지정된 S3 버킷이 다른 AWS 계정에 있는 경우 관리형 노드와 연결된 인스턴스 프로파일 또는 IAM 서비스 역할은 해당 버킷에 쓸 수 있는 권한이 있어야 합니다.
1. **연결 생성**을 선택합니다.
## Chef 레시피를 실행하는 연결 생성(CLI)
다음 절차에서는 AWS Command Line Interface(AWS CLI)를 사용하여 `AWS-ApplyChefRecipes` 문서로 Chef 쿡북을 실행하는 State Manager 연결을 생성하는 방법을 설명합니다.
1. 아직 하지 않은 경우 AWS Command Line Interface(AWS CLI)을 설치하고 구성합니다.
자세한 내용은 [최신 버전의 AWS CLI 설치 또는 업데이트](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html)를 참조하세요.
1. 다음과 같은 명령 중 하나를 실행하여 지정된 태그가 있는 대상 노드에서 Chef 쿡북을 실행하는 연결을 생성합니다. 쿡북 소스 유형 및 운영 체제에 적합한 명령을 사용합니다. 각 *example-resource-placeholder*를 자신의 정보로 바꿉니다.
1. **Git 소스**
------
#### [ Linux & macOS ]
```
aws ssm create-association --name "AWS-ApplyChefRecipes" \
--targets Key=tag:TagKey,Values=TagValue \
--parameters '{"SourceType":["Git"],"SourceInfo":["{\"repository\":\"repository-name\", \"getOptions\": \"branch:branch-name\", \"username\": \"{{ ssm-secure:username-secure-string-parameter }}\", \"password\": \"{{ ssm-secure:password-secure-string-parameter }}\"}"], "RunList":["{\"recipe[cookbook-name-1::recipe-name]\", \"recipe[cookbook-name-2::recipe-name]\"}"], "JsonAttributesContent": ["{custom-json-content}"], "JsonAttributesSources": "{\"sourceType\":\"s3\", \"sourceInfo\":\"s3-bucket-endpoint-1\"}, {\"sourceType\":\"s3\", \"sourceInfo\":\"s3-bucket-endpoint-2\"}", "ChefClientVersion": ["version-number"], "ChefClientArguments":["{chef-client-arguments}"], "WhyRun": boolean, "ComplianceSeverity": ["severity-value"], "ComplianceType": ["Custom:Chef"], "ComplianceReportBucket": ["s3-bucket-name"]}' \
--association-name "name" \
--schedule-expression "cron-or-rate-expression"
```
------
#### [ Windows ]
```
aws ssm create-association --name "AWS-ApplyChefRecipes" ^
--targets Key=tag:TagKey,Values=TagValue ^
--parameters '{"SourceType":["Git"],"SourceInfo":["{\"repository\":\"repository-name\", \"getOptions\": \"branch:branch-name\", \"username\": \"{{ ssm-secure:username-secure-string-parameter }}\", \"password\": \"{{ ssm-secure:password-secure-string-parameter }}\"}"], "RunList":["{\"recipe[cookbook-name-1::recipe-name]\", \"recipe[cookbook-name-2::recipe-name]\"}"], "JsonAttributesContent": ["{custom-json}"], "JsonAttributesSources": "{\"sourceType\":\"s3\", \"sourceInfo\":\"s3-bucket-endpoint-1\"}, {\"sourceType\":\"s3\", \"sourceInfo\":\"s3-bucket-endpoint-2\"}", "ChefClientVersion": ["version-number"], "ChefClientArguments":["{chef-client-arguments}"], "WhyRun": boolean, "ComplianceSeverity": ["severity-value"], "ComplianceType": ["Custom:Chef"], "ComplianceReportBucket": ["s3-bucket-name"]}' ^
--association-name "name" ^
--schedule-expression "cron-or-rate-expression"
```
------
1. **GitHub 소스**
------
#### [ Linux & macOS ]
```
aws ssm create-association --name "AWS-ApplyChefRecipes" \
--targets Key=tag:TagKey,Values=TagValue \
--parameters '{"SourceType":["GitHub"],"SourceInfo":["{\"owner\":\"owner-name\", \"repository\": \"name\", \"path\": \"path-to-directory-or-cookbook-to-download\", \"getOptions\": \"branch:branch-name\"}"], "RunList":["{\"recipe[cookbook-name-1::recipe-name]\", \"recipe[cookbook-name-2::recipe-name]\"}"], "JsonAttributesContent": ["{custom-json}"], "ChefClientVersion": ["version-number"], "ChefClientArguments":["{chef-client-arguments}"], "WhyRun": boolean, "ComplianceSeverity": ["severity-value"], "ComplianceType": ["Custom:Chef"], "ComplianceReportBucket": ["s3-bucket-name"]}' \
--association-name "name" \
--schedule-expression "cron-or-rate-expression"
```
------
#### [ Windows ]
```
aws ssm create-association --name "AWS-ApplyChefRecipes" ^
--targets Key=tag:TagKey,Values=TagValue \
--parameters '{"SourceType":["GitHub"],"SourceInfo":["{\"owner\":\"owner-name\", \"repository\": \"name\", \"path\": \"path-to-directory-or-cookbook-to-download\", \"getOptions\": \"branch:branch-name\"}"], "RunList":["{\"recipe[cookbook-name-1::recipe-name]\", \"recipe[cookbook-name-2::recipe-name]\"}"], "JsonAttributesContent": ["{custom-json}"], "ChefClientVersion": ["version-number"], "ChefClientArguments":["{chef-client-arguments}"], "WhyRun": boolean, "ComplianceSeverity": ["severity-value"], "ComplianceType": ["Custom:Chef"], "ComplianceReportBucket": ["s3-bucket-name"]}' ^
--association-name "name" ^
--schedule-expression "cron-or-rate-expression"
```
------
다음 예를 참고하세요
------
#### [ Linux & macOS ]
```
aws ssm create-association --name "AWS-ApplyChefRecipes" \
--targets Key=tag:OS,Values=Linux \
--parameters '{"SourceType":["GitHub"],"SourceInfo":["{\"owner\":\"ChefRecipeTest\", \"repository\": \"ChefCookbooks\", \"path\": \"cookbooks/HelloWorld\", \"getOptions\": \"branch:master\"}"], "RunList":["{\"recipe[HelloWorld::HelloWorldRecipe]\", \"recipe[HelloWorld::InstallApp]\"}"], "JsonAttributesContent": ["{\"state\": \"visible\",\"colors\": {\"foreground\": \"light-blue\",\"background\": \"dark-gray\"}}"], "ChefClientVersion": ["14"], "ChefClientArguments":["{--fips}"], "WhyRun": false, "ComplianceSeverity": ["Medium"], "ComplianceType": ["Custom:Chef"], "ComplianceReportBucket": ["ChefComplianceResultsBucket"]}' \
--association-name "MyChefAssociation" \
--schedule-expression "cron(0 2 ? * SUN *)"
```
------
#### [ Windows ]
```
aws ssm create-association --name "AWS-ApplyChefRecipes" ^
--targets Key=tag:OS,Values=Linux ^
--parameters '{"SourceType":["GitHub"],"SourceInfo":["{\"owner\":\"ChefRecipeTest\", \"repository\": \"ChefCookbooks\", \"path\": \"cookbooks/HelloWorld\", \"getOptions\": \"branch:master\"}"], "RunList":["{\"recipe[HelloWorld::HelloWorldRecipe]\", \"recipe[HelloWorld::InstallApp]\"}"], "JsonAttributesContent": ["{\"state\": \"visible\",\"colors\": {\"foreground\": \"light-blue\",\"background\": \"dark-gray\"}}"], "ChefClientVersion": ["14"], "ChefClientArguments":["{--fips}"], "WhyRun": false, "ComplianceSeverity": ["Medium"], "ComplianceType": ["Custom:Chef"], "ComplianceReportBucket": ["ChefComplianceResultsBucket"]}' ^
--association-name "MyChefAssociation" ^
--schedule-expression "cron(0 2 ? * SUN *)"
```
------
1. **HTTP 소스**
------
#### [ Linux & macOS ]
```
aws ssm create-association --name "AWS-ApplyChefRecipes" \
--targets Key=tag:TagKey,Values=TagValue \
--parameters '{"SourceType":["HTTP"],"SourceInfo":["{\"url\":\"url-to-zip-file|directory|cookbook\", \"authMethod\": \"auth-method\", \"username\": \"{{ ssm-secure:username-secure-string-parameter }}\", \"password\": \"{{ ssm-secure:password-secure-string-parameter }}\"}"], "RunList":["{\"recipe[cookbook-name-1::recipe-name]\", \"recipe[cookbook-name-2::recipe-name]\"}"], "JsonAttributesContent": ["{custom-json-content}"], "JsonAttributesSources": "{\"sourceType\":\"s3\", \"sourceInfo\":\"s3-bucket-endpoint-1\"}, {\"sourceType\":\"s3\", \"sourceInfo\":\"s3-bucket-endpoint-2\"}", "ChefClientVersion": ["version-number"], "ChefClientArguments":["{chef-client-arguments}"], "WhyRun": boolean, "ComplianceSeverity": ["severity-value"], "ComplianceType": ["Custom:Chef"], "ComplianceReportBucket": ["s3-bucket-name"]}' \
--association-name "name" \
--schedule-expression "cron-or-rate-expression"
```
------
#### [ Windows ]
```
aws ssm create-association --name "AWS-ApplyChefRecipes" ^
--targets Key=tag:TagKey,Values=TagValue ^
--parameters '{"SourceType":["HTTP"],"SourceInfo":["{\"url\":\"url-to-zip-file|directory|cookbook\", \"authMethod\": \"auth-method\", \"username\": \"{{ ssm-secure:username-secure-string-parameter }}\", \"password\": \"{{ ssm-secure:password-secure-string-parameter }}\"}"], "RunList":["{\"recipe[cookbook-name-1::recipe-name]\", \"recipe[cookbook-name-2::recipe-name]\"}"], "JsonAttributesContent": ["{custom-json-content}"], "JsonAttributesSources": "{\"sourceType\":\"s3\", \"sourceInfo\":\"s3-bucket-endpoint-1\"}, {\"sourceType\":\"s3\", \"sourceInfo\":\"s3-bucket-endpoint-2\"}", "ChefClientVersion": ["version-number"], "ChefClientArguments":["{chef-client-arguments}"], "WhyRun": boolean, "ComplianceSeverity": ["severity-value"], "ComplianceType": ["Custom:Chef"], "ComplianceReportBucket": ["s3-bucket-name"]}' \
--association-name "name" ^
--schedule-expression "cron-or-rate-expression"
```
------
1. **Amazon S3 소스**
------
#### [ Linux & macOS ]
```
aws ssm create-association --name "AWS-ApplyChefRecipes" \
--targets Key=tag:TagKey,Values=TagValue \
--parameters '{"SourceType":["S3"],"SourceInfo":["{\"path\":\"https://s3.amazonaws.com/path_to_Zip_file,_directory,_or_cookbook_to_download\"}"], "RunList":["{\"recipe[cookbook_name1::recipe_name]\", \"recipe[cookbook_name2::recipe_name]\"}"], "JsonAttributesContent": ["{Custom_JSON}"], "ChefClientVersion": ["version_number"], "ChefClientArguments":["{chef_client_arguments}"], "WhyRun": true_or_false, "ComplianceSeverity": ["severity_value"], "ComplianceType": ["Custom:Chef"], "ComplianceReportBucket": ["amzn-s3-demo-bucket"]}' \
--association-name "name" \
--schedule-expression "cron_or_rate_expression"
```
------
#### [ Windows ]
```
aws ssm create-association --name "AWS-ApplyChefRecipes" ^
--targets Key=tag:TagKey,Values=TagValue ^
--parameters '{"SourceType":["S3"],"SourceInfo":["{\"path\":\"https://s3.amazonaws.com/path_to_Zip_file,_directory,_or_cookbook_to_download\"}"], "RunList":["{\"recipe[cookbook_name1::recipe_name]\", \"recipe[cookbook_name2::recipe_name]\"}"], "JsonAttributesContent": ["{Custom_JSON}"], "ChefClientVersion": ["version_number"], "ChefClientArguments":["{chef_client_arguments}"], "WhyRun": true_or_false, "ComplianceSeverity": ["severity_value"], "ComplianceType": ["Custom:Chef"], "ComplianceReportBucket": ["amzn-s3-demo-bucket"]}' ^
--association-name "name" ^
--schedule-expression "cron_or_rate_expression"
```
------
다음 예를 참고하세요
------
#### [ Linux & macOS ]
```
aws ssm create-association --name "AWS-ApplyChefRecipes" \
--targets "Key=tag:OS,Values= Linux" \
--parameters '{"SourceType":["S3"],"SourceInfo":["{\"path\":\"https://s3.amazonaws.com/amzn-s3-demo-bucket/HelloWorld\"}"], "RunList":["{\"recipe[HelloWorld::HelloWorldRecipe]\", \"recipe[HelloWorld::InstallApp]\"}"], "JsonAttributesContent": ["{\"state\": \"visible\",\"colors\": {\"foreground\": \"light-blue\",\"background\": \"dark-gray\"}}"], "ChefClientVersion": ["14"], "ChefClientArguments":["{--fips}"], "WhyRun": false, "ComplianceSeverity": ["Medium"], "ComplianceType": ["Custom:Chef"], "ComplianceReportBucket": ["ChefComplianceResultsBucket"]}' \
--association-name "name" \
--schedule-expression "cron(0 2 ? * SUN *)"
```
------
#### [ Windows ]
```
aws ssm create-association --name "AWS-ApplyChefRecipes" ^
--targets "Key=tag:OS,Values= Linux" ^
--parameters '{"SourceType":["S3"],"SourceInfo":["{\"path\":\"https://s3.amazonaws.com/amzn-s3-demo-bucket/HelloWorld\"}"], "RunList":["{\"recipe[HelloWorld::HelloWorldRecipe]\", \"recipe[HelloWorld::InstallApp]\"}"], "JsonAttributesContent": ["{\"state\": \"visible\",\"colors\": {\"foreground\": \"light-blue\",\"background\": \"dark-gray\"}}"], "ChefClientVersion": ["14"], "ChefClientArguments":["{--fips}"], "WhyRun": false, "ComplianceSeverity": ["Medium"], "ComplianceType": ["Custom:Chef"], "ComplianceReportBucket": ["ChefComplianceResultsBucket"]}' ^
--association-name "name" ^
--schedule-expression "cron(0 2 ? * SUN *)"
```
------
시스템에서 연결이 생성되며, 지정된 cron 또는 rate 표현식이 이를 방해하지 않는 한 시스템에서는 대상 노드에서 연결을 실행합니다.
**참고**
State Manager 연결은 cron 및 rate 표현식 중 일부를 지원하지 않습니다. 연결에 대한 cron 및 rate 표현식을 생성하는 방법에 대한 자세한 내용은 [참조: Systems Manager용 Cron 및 Rate 표현식](reference-cron-and-rate-expressions.md) 섹션을 참조하세요.
1. 다음 명령을 실행하여 방금 생성한 연결의 상태를 봅니다.
```
aws ssm describe-association --association-id "ID"
```
## Chef 리소스 규정 준수 세부 정보 보기
Systems Manager는 `AWS-ApplyChefRecipes` 문서를 실행했을 때 지정한 Amazon S3 **Compliance 보고서 버킷** 값에서 Chef 관리형 리소스에 대한 규정 준수 정보를 수집합니다. S3 버킷에서 Chef 리소스 실패에 대한 정보를 검색하는 데는 시간이 많이 걸릴 수 있습니다. 대신, Systems Manager [**Compliance**] 페이지에서 이 정보를 볼 수 있습니다.
Systems Manager Compliance 검사는 가장 최근의 Chef 실행에서 생성되거나 확인된 관리형 노드의 리소스에 대한 정보를 수집합니다. 리소스에는 파일, 디렉터리, `systemd` 서비스, `yum` 패키지, 템플릿 파일, `gem` 패키지 및 종속 쿡북 등이 포함될 수 있습니다.
**규정 준수 리소스 요약** 섹션에 실패한 리소스의 수가 표시됩니다. 다음 예에서 **ComplianceType**은 **Custom:Chef**이고 한 개의 리소스가 규정 미준수입니다.
**참고**
`Custom:Chef`는 `AWS-ApplyChefRecipes` 문서의 기본 **ComplianceType** 값입니다. 이 값은 사용자 지정 가능합니다.
![\[[Compliance] 페이지의 [Compliance 리소스 요약(Compliance resources summary)] 섹션에서 개수 보기.\]](http://docs.aws.amazon.com/ko_kr/systems-manager/latest/userguide/images/state-manager-chef-compliance-summary.png)
[**리소스에 대한 세부 정보 개요(Details overview for resources)**] 섹션에 규정 미준수 AWS 리소스에 대한 정보가 표시됩니다. 이 섹션에는 규정 준수가 실행된 Chef 리소스 유형, 문제의 심각도, 규정 준수 상태 및 추가 정보(해당하는 경우)에 대한 링크도 포함됩니다.
![\[Chef 관리형 리소스 실패에 대한 규정 준수 세부 정보 보기\]](http://docs.aws.amazon.com/ko_kr/systems-manager/latest/userguide/images/state-manager-chef-compliance-details.png)
[**출력 보기(View output)**]는 세부 상태의 마지막 4,000자를 표시합니다. Systems Manager는 예외를 첫 번째 요소로 시작하여 자세한 메시지를 찾아 4,000자 할당량에 도달할 때까지 표시합니다. 이 프로세스는 예외가 발생되기 전에 출력된 긴 메시지(문제 해결을 위해 가장 관련성이 높은 메시지)를 표시합니다.
규정 준수 정보를 보는 방법에 대한 자세한 내용은 [AWS Systems Manager Compliance](systems-manager-compliance.md) 섹션을 참조하세요.
**중요**
State Manager 연결이 실패한 경우에는 규정 준수 데이터가 보고되지 않습니다. 예를 들어, Systems Manager가 노드에 액세스할 권한이 없는 S3 버킷에서 Chef 쿡북을 다운로드하려고 하면 연결이 실패하고 Systems Manager가 어떠한 규정 준수 데이터도 보고되지 않습니다.
# 연습: AWS CLI를 사용하여 SSM Agent를 자동으로 업데이트
다음 절차는 AWS Command Line Interface를 사용하여 State Manager 연결을 생성하는 과정을 안내합니다. 연결하면 지정한 일정에 따라 SSM Agent가 자동으로 업데이트됩니다. SSM Agent에 대한 자세한 내용은 [SSM Agent 작업](ssm-agent.md) 섹션을 참조하세요. 콘솔을 사용하여 SSM Agent의 업데이트 일정을 사용자 지정하려면 [SSM Agent 자동 업데이트](ssm-agent-automatic-updates.md#ssm-agent-automatic-updates-console) 섹션을 참조하세요.
SSM Agent 업데이트에 대해 알림을 수신하려면 GitHub에서 [SSM Agent 릴리스 정보](https://github.com/aws/amazon-ssm-agent/blob/master/RELEASENOTES.md) 페이지를 구독합니다.
**시작하기 전 준비 사항**
다음 절차를 완료하기 전에 Systems Manager에 대해 구성된 Amazon Elastic Compute Cloud(Amazon EC2) 인스턴스(Linux, macOS 또는 Windows Server용)가 1개 이상 실행되고 있는지 확인합니다. 자세한 내용은 [AWS Systems Manager에 대한 관리형 노드 설정](systems-manager-setting-up-nodes.md) 섹션을 참조하세요.
AWS CLI 또는 AWS Tools for Windows PowerShell 사용을 통해 연결을 생성한 경우 다음 예제에 표시된 것과 같이 `--Targets` 파라미터를 사용하여 인스턴스를 대상으로 지정합니다. `--InstanceID` 파라미터를 사용하지 마세요. `--InstanceID` 파라미터는 레거시 파라미터입니다.
**SSM Agent를 자동으로 업데이트하기 위해 연결을 생성하려면**
1. 아직 하지 않은 경우 AWS Command Line Interface(AWS CLI)을 설치하고 구성합니다.
자세한 내용은 [최신 버전의 AWS CLI 설치 또는 업데이트](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html)를 참조하세요.
1. 다음 명령을 실행하면 Amazon Elastic Compute Cloud(Amazon EC2) 태그로 인스턴스를 대상으로 지정하여 연결을 생성합니다. 각 *example resource placeholder*를 사용자의 정보로 바꿉니다. `Schedule` 파라미터는 매주 일요일 오전 2시(UTC)에 연결을 실행하는 일정을 설정합니다.
State Manager 연결은 cron 및 rate 표현식 중 일부를 지원하지 않습니다. 연결에 대한 cron 및 rate 표현식을 생성하는 방법에 대한 자세한 내용은 [참조: Systems Manager용 Cron 및 Rate 표현식](reference-cron-and-rate-expressions.md) 섹션을 참조하세요.
------
#### [ Linux & macOS ]
```
aws ssm create-association \
--targets Key=tag:tag_key,Values=tag_value \
--name AWS-UpdateSSMAgent \
--schedule-expression "cron(0 2 ? * SUN *)"
```
------
#### [ Windows ]
```
aws ssm create-association ^
--targets Key=tag:tag_key,Values=tag_value ^
--name AWS-UpdateSSMAgent ^
--schedule-expression "cron(0 2 ? * SUN *)"
```
------
쉼표로 구분된 목록으로 인스턴스 ID를 지정하여 여러 인스턴스를 대상으로 지정할 수도 있습니다.
------
#### [ Linux & macOS ]
```
aws ssm create-association \
--targets Key=instanceids,Values=instance_ID,instance_ID,instance_ID \
--name AWS-UpdateSSMAgent \
--schedule-expression "cron(0 2 ? * SUN *)"
```
------
#### [ Windows ]
```
aws ssm create-association ^
--targets Key=instanceids,Values=instance_ID,instance_ID,instance_ID ^
--name AWS-UpdateSSMAgent ^
--schedule-expression "cron(0 2 ? * SUN *)"
```
------
업데이트하려는 SSM Agent의 버전을 지정할 수 있습니다.
------
#### [ Linux & macOS ]
```
aws ssm create-association \
--targets Key=instanceids,Values=instance_ID,instance_ID,instance_ID \
--name AWS-UpdateSSMAgent \
--schedule-expression "cron(0 2 ? * SUN *)" \
--parameters version=ssm_agent_version_number
```
------
#### [ Windows ]
```
aws ssm create-association ^
--targets Key=instanceids,Values=instance_ID,instance_ID,instance_ID ^
--name AWS-UpdateSSMAgent ^
--schedule-expression "cron(0 2 ? * SUN *)" ^
--parameters version=ssm_agent_version_number
```
------
시스템은 다음과 같은 정보를 반환합니다.
```
{
"AssociationDescription": {
"ScheduleExpression": "cron(0 2 ? * SUN *)",
"Name": "AWS-UpdateSSMAgent",
"Overview": {
"Status": "Pending",
"DetailedStatus": "Creating"
},
"AssociationId": "123..............",
"DocumentVersion": "$DEFAULT",
"LastUpdateAssociationDate": 1504034257.98,
"Date": 1504034257.98,
"AssociationVersion": "1",
"Targets": [
{
"Values": [
"TagValue"
],
"Key": "tag:TagKey"
}
]
}
}
```
시스템은 해당 인스턴스에 연결 생성을 시도하고 생성 후 상태를 적용합니다. 연결 상태는 `Pending`으로 표시됩니다.
1. 다음 명령을 실행하여 생성한 연결의 업데이트된 상태를 확인합니다.
```
aws ssm list-associations
```
인스턴스에서 최신 버전의 SSM Agent를 실행하고 있지 *않은* 경우 상태가 `Failed`로 표시됩니다. 최신 버전의 SSM Agent가 발행되면 이 연결을 통해 새 에이전트가 자동으로 설치되고 상태가 `Success`로 표시됩니다.
# 연습: Windows Server용 EC2 인스턴스에서 PV 드라이버 자동 업데이트
Amazon Windows Server Amazon Machine Images(AMIs)는 가상화 하드웨어에 대한 액세스를 허용하는 드라이버 집합을 포함하고 있습니다. 이러한 드라이버는 Amazon Elastic Compute Cloud(Amazon EC2)에서 인스턴스 스토어 및 Amazon Elastic Block Store(Amazon EBS) 볼륨을 디바이스에 매핑하는 데 사용됩니다. Windows Server용 EC2 인스턴스의 안정성과 성능을 개선하려면 최신 드라이버를 설치하는 것이 좋습니다. PV 드라이버에 대한 자세한 내용은 [AWS PV 드라이버](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/xen-drivers-overview.html#xen-driver-awspv)를 참조하세요.
다음 시연에서는 드라이버를 사용할 수 있는 경우 새 AWS PV 드라이버를 자동으로 다운로드하여 설치하도록 State Manager 연결을 구성하는 방법을 보여줍니다. State Manager는 AWS Systems Manager의 도구입니다.
**시작하기 전 준비 사항**
다음 절차를 완료하기 전에 Systems Manager에 대해 구성된 Windows Server용 Amazon EC2 인스턴스가 1개 이상 실행되고 있는지 확인합니다. 자세한 내용은 [AWS Systems Manager에 대한 관리형 노드 설정](systems-manager-setting-up-nodes.md) 섹션을 참조하세요.
**PV 드라이버를 자동으로 업데이트하는 State Manager 연결을 생성하려면**
1. [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)에서 AWS Systems Manager 콘솔을 엽니다.
1. 탐색 창에서 **State Manager**를 선택합니다.
1. **연결 생성**을 선택합니다.
1. **이름** 필드에 연결에 대한 설명이 포함된 이름을 입력합니다.
1. [**문서(Document)**] 목록에서 `AWS-ConfigureAWSPackage`를 선택합니다.
1. **파라미터** 섹션에서 다음을 수행합니다.
+ **작업**에서 **설치**를 선택합니다.
+ [**설치 유형(Installation type)**]에서 [**제거 및 다시 설치(Uninstall and reinstall)**]를 선택합니다.
**참고**
이 패키지에는 현재 위치 업그레이드가 지원되지 않습니다. 제거한 후 다시 설치해야 합니다.
+ **이름**에 **AWSPVDriver**를 입력합니다.
**버전** 및 **추가 인수**에는 아무 것도 입력할 필요가 없습니다.
1. **Targets**(대상) 섹션에서, 태그를 지정하거나, 수동으로 인스턴스나 엣지 디바이스를 선택하거나, 리소스 그룹을 지정하여 이 작업을 실행할 관리형 노드를 식별합니다.
**작은 정보**
예상한 관리형 노드가 목록에 없으면 [관리형 노드 가용성 문제 해결](fleet-manager-troubleshooting-managed-nodes.md)에서 문제 해결 팁을 참조하세요.
**참고**
태그를 사용하여 인스턴스 대상을 지정하고 Linux 인스턴스에 매핑되는 태그를 지정할 경우 Windows Server 인스턴스에서는 연결이 성공하지만 Linux 인스턴스에서는 실패합니다. 전체 연결 상태는 **실패**로 표시됩니다.
1. **일정 지정** 영역에서 구성한 일정에 따라 연결을 실행할지 아니면 한 번만 실행할지 선택합니다. 업데이트된 PV 드라이버는 1년에 몇 번 릴리스되므로 원하는 경우 연결을 한 달에 한 번 실행하도록 예약할 수 있습니다.
1. **고급 옵션**의 **규정 준수 심각도**에서 연결의 심각도 수준을 선택합니다. 규정 준수 보고는 여기서 지정한 심각도 수준과 함께 연결 상태가 준수인지 아니면 미준수인지를 나타냅니다. 자세한 내용은 [State Manager 연결 규정 준수 정보](compliance-about.md#compliance-about-association) 섹션을 참조하세요.
1. **Rate control**(속도 제어)에서
+ **Concurrency**(동시성)에서 명령을 동시에 실행할 관리형 노드의 백분율 또는 개수를 지정합니다.
**참고**
관리형 노드에 적용할 태그를 지정하거나, AWS 리소스 그룹을 지정하여 대상을 선택하였지만 대상으로 지정할 관리형 노드 수를 잘 모를 경우에는 백분율을 지정하여 동시에 문서를 실행할 수 있는 대상 수를 제한합니다.
+ **Error threshold**(오류 임계값)에서, 명령이 노드의 개수 또는 백분율에서 실패한 후 다른 관리형 노드에서 해당 명령의 실행을 중지할 시간을 지정합니다. 예를 들어 세 오류를 지정하면 네 번째 오류를 받았을 때 Systems Manager가 명령 전송을 중지합니다. 여전히 명령을 처리 중인 관리형 노드도 오류를 전송할 수 있습니다.
1. (선택 사항) **출력 옵션**에서 명령 출력을 파일에 저장하려면 **S3 버킷에 쓰기 활성화** 옆의 상자를 선택합니다. 상자에 버킷 및 접두사(폴더) 이름을 입력합니다.
**참고**
데이터를 S3 버킷에 쓰는 기능을 부여하는 S3 권한은 이 작업을 수행하는 IAM 사용자의 권한이 아닌 관리형 노드에 할당된 인스턴스 프로파일의 권한입니다. 자세한 내용은 [Systems Manager에 필요한 인스턴스 권한 구성](setup-instance-permissions.md)이나 [하이브리드 환경을 위한 IAM 서비스 역할 생성](hybrid-multicloud-service-role.md)을 참조하세요. 또한 지정된 S3 버킷이 다른 AWS 계정에 있는 경우 관리형 노드와 연결된 인스턴스 프로파일 또는 IAM 서비스 역할은 해당 버킷에 쓸 수 있는 권한이 있어야 합니다.
1. (선택 사항) **CloudWatch 경보** 섹션에서 모니터링을 위해 연결에 적용할 CloudWatch 경보를 **경보 이름**으로 선택합니다.
**참고**
이 단계에 대한 다음 정보를 참조하세요.
알람 목록에는 최대 100개의 알람이 표시됩니다. 목록에 해당 경보가 표시되지 않으면 AWS Command Line Interface를 사용하여 연결을 생성합니다. 자세한 내용은 [연결 생성(명령줄)](state-manager-associations-creating.md#create-state-manager-association-commandline) 섹션을 참조하세요.
CloudWatch 경보를 명령에 연결하려면 연결을 생성하는 IAM 보안 주체에 `iam:createServiceLinkedRole` 작업에 대한 권한이 있어야 합니다. CloudWatch 경보에 대한 자세한 내용은 [Amazon CloudWatch 경보 사용](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)을 참조하세요.
경보가 활성화되면 보류 중인 명령 호출 또는 자동화가 실행되지 않습니다.
1. [**연결 생성(Create association)**], [**닫기(Close)**]를 차례로 선택합니다. 시스템은 해당 인스턴스에 연결을 생성하고 그 상태를 즉시 적용하려고 합니다.
1개 이상의 Windows Server용 Amazon EC2 인스턴스에 대해 연결을 생성한 경우 상태가 [**성공(Success)**]으로 변경됩니다. Systems Manager에 대해 인스턴스를 구성하지 않았거나 실수로 Linux 인스턴스를 대상으로 지정한 경우 상태가 [**실패(Failed)**]로 표시됩니다.
상태가 [**실패(Failed)**]인 경우 연결 ID와 [**리소스(Resources)**] 탭을 차례로 선택하고 Windows Server용 EC2 인스턴스에서 연결이 성공적으로 생성되었는지 확인합니다. Windows Server용 EC2 인스턴스의 상태가 [**실패(Failed)**]로 표시될 경우 SSM Agent가 인스턴스에서 실행 중이고 Systems Manager에 대한 AWS Identity and Access Management(IAM) 역할로 인스턴스가 구성되었는지 확인합니다. 자세한 내용은 [조직을 위한 Systems Manager 통합 콘솔 설정](systems-manager-setting-up-organizations.md) 섹션을 참조하세요.