• AWS Systems Manager CloudWatch 대시보드는 2026년 4월 30일 이후에는 더 이상 사용할 수 없습니다. 고객은 Amazon CloudWatch 콘솔을 계속 사용하여 현재와 마찬가지로 Amazon CloudWatch 대시보드를 보고, 생성하고, 관리할 수 있습니다. 자세한 내용은 [Amazon CloudWatch 대시보드 설명서](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html)를 참조하세요. # 패치를 위한 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시간) 사이여야 합니다.