패치를 위한 SSM 명령 문서: AWS-RunPatchBaselineWithHooks - AWS Systems Manager
AWS-RunPatchBaselineWithHooks 운영 단계AWS-RunPatchBaselineWithHooks 파라미터

패치를 위한 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 이상 버전이 설치되어 있어야 합니다.

문서가 실행될 때 패치 그룹이 지정되지 않은 경우 운영 체제 유형에 대해 "기본값"으로 현재 지정된 패치 기준을 사용합니다 그렇지 않으면 패치 그룹과 연결된 패치 기준을 사용합니다. 패치 그룹에 대한 자세한 내용은 패치 그룹 섹션을 참조하세요.

문서 AWS-RunPatchBaselineWithHooks을 사용하면 운영 체제와 애플리케이션 모두를 패치할 수 있습니다. (Windows Server에서 애플리케이션 지원은 Microsoft에서 릴리스한 애플리케이션의 업데이트로 제한됩니다.)

이 문서는 Linux 및 Windows Server 관리형 노드를 지원합니다. 문서에서 각 플랫폼에 적합한 작업을 수행합니다.

참고

AWS-RunPatchBaselineWithHooks는 macOS에서 지원되지 않습니다.

Linux

Linux 관리형 노드에서는 AWS-RunPatchBaselineWithHooks 문서가 Python 모듈을 호출합니다. 그런 다음, 해당 관리형 노드에 적용되는 패치 기준의 스냅샷을 다운로드합니다. 이 패치 기준 스냅샷은 정의된 규칙과 승인 및 차단된 패치 목록을 사용하여 각 노드 유형에 적합한 패키지 관리자를 실행합니다.

  • Amazon Linux 1, Amazon Linux 2, CentOS, Oracle Linux, RHEL 7 관리형 노드는 YUM을 사용합니다. YUM 작업의 경우 Python 2.6 이상의 지원되는 버전(2.6~3.10)이 Patch Manager에 필요합니다.

  • RHEL 8 관리형 노드는 DNF를 사용합니다. DNF 작업의 경우 지원되는 Python 2 또는 Python 3 버전(2.6~3.10)이 Patch Manager에 필요합니다. (두 버전 모두 RHEL 8에 기본적으로 설치되어 있지 않습니다. 둘 중 하나를 수동으로 설치해야 합니다.)

  • Debian Server, Raspberry Pi OS 및 Ubuntu Server 인스턴스는 APT를 사용합니다. APT 작업의 경우 지원되는 Python 3 버전(3.0~3.10)이 Patch Manager에 필요합니다.

  • SUSE Linux Enterprise Server 관리형 노드는 Zypper를 사용합니다. Zypper 작업의 경우 Python 2.6 이상의 지원되는 버전(2.6~3.10)이 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을 새로 생성할 수 있습니다. 이렇게 하려면 get-deployable-patch-snapshot-for-instance 명령을 사용합니다.

승인되고 적용 가능한 모든 업데이트가 설치되고 필요한 만큼 재부팅이 수행되면, 패치 규정 준수 정보가 관리형 노드에 생성되며 Patch Manager에 다시 보고됩니다.

참고

AWS-RunPatchBaselineWithHooks 문서에서 RebootOption 파라미터가 NoReboot로 설정되어 있으면 Patch Manager를 실행한 후 관리형 노드가 재부팅되지 않습니다. 자세한 내용은 파라미터 이름: RebootOption 단원을 참조하십시오.

패치 규정 준수 데이터를 보는 방법에 대한 자세한 내용은 패치 규정 준수 정보 섹션을 참조하세요.

AWS-RunPatchBaselineWithHooks 운영 단계

AWS-RunPatchBaselineWithHooks가 실행되면 다음 단계가 수행됩니다.

  1. 스캔 - AWS-RunPatchBaseline을 사용하는 Scan 작업이 관리형 노드에서 실행되고 규정 준수 보고서가 생성되고 업로드됩니다.

  2. 로컬 패치 상태 확인 - 선택한 작업과 1단계의 Scan 결과를 기반으로 수행할 단계를 결정하기 위해 스크립트가 실행됩니다.

    1. 선택한 작업이 Scan이면 작업이 완료된 것으로 표시됩니다. 작업이 종료됩니다.

    2. 선택한 작업이 Install이면 Patch Manager는 1단계의 Scan 결과를 평가하여 다음에 실행할 작업을 결정합니다.

      1. 누락된 패치가 발견되지 않고 보류 중인 재부팅이 필요하지 않으면 사용자가 제공한 후크가 포함된 최종 단계(8단계)로 작업이 바로 진행됩니다. 그 사이의 모든 단계는 건너뜁니다.

      2. 누락된 패치가 발견되지 않았지만 보류 중인 재부팅이 필요하고 선택한 재부팅 옵션이NoReboot이면 사용자가 제공한 후크가 포함된 최종 단계(8단계)로 작업이 바로 진행됩니다. 그 사이의 모든 단계는 건너뜁니다.

      3. 그렇지 않으면 작업은 다음 단계로 진행됩니다.

  3. 패치 전 후크 작업 - 첫 번째 수명 주기 후크인 PreInstallHookDocName에 대해 제공한 SSM 문서가 관리형 노드에서 실행됩니다.

  4. NoReboot로 설치 - 재부팅 옵션이 NoReboot이고 AWS-RunPatchBaseline을 사용하는 Install 작업이 관리형 노드에서 실행되고 규정 준수 보고서가 생성되어 업로드됩니다.

  5. 설치 후 후크 작업 - 두 번째 수명 주기 후크인 PostInstallHookDocName에 대해 제공한 SSM 문서가 관리형 노드에서 실행됩니다.

  6. 재부팅 확인 - 관리형 노드에 재부팅이 필요한지 여부와 실행할 단계를 결정하기 위해 스크립트가 실행됩니다.

    1. 선택한 재부팅 옵션이 NoReboot인 경우 사용자가 제공한 후크가 포함된 최종 단계(8단계)로 작업이 바로 진행됩니다. 그 사이의 모든 단계는 건너뜁니다.

    2. 선택한 재부팅 옵션이 RebootIfNeeded인 경우 Patch Manager는 4단계에서 수집된 인벤토리에서 필요한 보류 중인 재부팅이 있는지 확인합니다. 즉, 작업이 7단계로 계속 진행되고 다음과 같은 경우 관리형 노드가 재부팅됩니다.

      1. Patch Manager가 하나 이상의 패치를 설치한 경우(Patch Manager가 패치에 재부팅이 필요한지 여부를 평가하지 않습니다. 패치에 재부팅이 필요하지 않은 경우에도 시스템이 재부팅됩니다.)

      2. Patch Manager가 설치 작업 중 INSTALLED_PENDING_REBOOT 상태의 패치를 하나 이상 감지합니다. INSTALLED_PENDING_REBOOT 상태는 설치 작업이 마지막으로 실행될 때 NoReboot 옵션이 선택되었거나 관리형 노드를 마지막으로 재부팅한 이후에 Patch Manager 외부에 패치가 설치되었다는 의미일 수 있습니다.

      이러한 기준을 충족하는 패치가 없으면 관리형 노드 패치 작업이 완료되고 작업은 사용자가 제공한 후크가 포함된 최종 단계(8단계)로 바로 진행됩니다. 그 사이의 모든 단계는 건너뜁니다.

  7. 재부팅 및 보고 - 재부팅 옵션이 RebootIfNeeded인 설치 작업이 AWS-RunPatchBaseline을 사용하여 관리형 노드에서 실행되고 규정 준수 보고서가 생성되어 업로드됩니다.

  8. 재부팅 후 후크 작업 - 세 번째 수명 주기 후크인 OnExitHookDocName에 대해 제공한 SSM 문서가 관리형 노드에서 실행됩니다.

Scan 작업의 경우 1단계가 실패하면 문서 실행 프로세스가 중지되고 단계가 실패로 보고되지만 후속 단계는 성공으로 보고됩니다.

Install 작업의 경우 작업 중 aws:runDocument 단계 중 하나라도 실패하면 해당 단계는 실패로 보고되고 작업은 사용자가 제공한 후크를 포함하는 최종 단계(8단계)로 바로 진행됩니다. 그 사이의 모든 단계는 건너뜁니다. 이 단계는 실패로 보고되고, 마지막 단계는 작업 결과의 상태를 보고하며, 그 사이의 모든 단계는 성공으로 보고됩니다.

AWS-RunPatchBaselineWithHooks 파라미터

AWS-RunPatchBaselineWithHooks는 6개 파라미터를 지원합니다.

Operation 파라미터가 필요합니다.

RebootOption, PreInstallHookDocName, PostInstallHookDocName 및 OnExitHookDocName 파라미터는 옵션입니다.

Snapshot-ID는 기술적으로 옵션이지만 유지 관리 기간 외에 AWS-RunPatchBaselineWithHooks를 실행할 때 사용자 정의 값을 제공하는 것이 좋습니다. 유지 관리 기간 작업의 일부로 문서가 실행될 때 Patch Manager가 자동으로 값을 제공하도록 합니다.

파라미터 이름: Operation

사용 여부: 필수.

옵션: Scan | Install.

스캔

Scan 옵션을 선택하는 경우 시스템이 AWS-RunPatchBaseline 문서를 사용하여 따라 관리형 노드의 패치 규정 준수 상태를 결정하며 이 정보가 Patch Manager에게 다시 보고됩니다. Scan은 업데이트를 설치하거나 관리형 노드를 재부팅하라는 메시지를 표시하지 않습니다. 대신, 작업이 승인되고 노드에 적용 가능한 업데이트가 누락된 위치를 식별해 줍니다.

Install

Install 옵션을 선택하는 경우 AWS-RunPatchBaselineWithHooks이 관리형 노드에서 누락된 승인되고 적용 가능한 업데이트를 설치하려고 시도합니다. Install 작업의 일부로 생성된 패치 규정 준수 정보에는 누락된 업데이트가 나열되지 않지만, 어떠한 이유로든 업데이트 설치가 성공하지 못하면 실패 상태에 있는 업데이트를 보고할 수 있습니다. 관리형 노드에 업데이트가 설치될 때마다 업데이트가 설치되었는지 및 활성 상태인지를 확인하기 위해 노드가 재부팅됩니다. (예외: AWS-RunPatchBaselineWithHooks 문서에서 RebootOption 파라미터가 NoReboot로 설정되어 있으면 Patch Manager를 실행한 후 관리형 노드가 재부팅되지 않습니다. 자세한 내용은 파라미터 이름: RebootOption 섹션을 참조하세요.)

참고

Patch Manager가 관리형 노드를 업데이트하기 전에 기준 규칙에 의해 지정된 패치가 설치된 경우 시스템이 예상대로 재부팅되지 않을 수도 있습니다. 이는 패치가 사용자에 의해 수동으로 설치되어 있거나 Ubuntu Server의 unattended-upgrades 패키지와 같은 다른 프로그램에 의해 자동으로 설치되어 있는 경우에 발생할 수 있습니다.

파라미터 이름: Snapshot ID

사용 여부: 선택.

Snapshot ID는 Patch Manager가 단일 작업으로 패치된 관리형 노드 집합 모두가 승인된 패치 집합과 정확히 일치하는지를 확인하기 위해 사용하는 고유 ID(GUID)입니다. 이 파라미터가 옵션으로 정의되어 있긴 하지만, 다음 표에 설명된 대로 유지 관리 기간에서 AWS-RunPatchBaselineWithHooks을 실행하는지 여부에 따라 모범 사례 권장 사항이 달라집니다.

AWS-RunPatchBaselineWithHooks 모범 사례
Mode 모범 사례 Details
유지 관리 기간 내 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 | 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 사용을 참조하세요.

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 문서 플러그인 참조 섹션을 참조하세요. 기본 SSM 문서 이름은 AWS-Noop이며 관리형 노드에서 작업을 수행하지 않습니다.

사용자 정의 SSM 문서 생성에 대한 자세한 내용은 SSM 문서 콘텐츠 생성 섹션을 참조하세요.

파라미터 이름: 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 문서 플러그인 참조 섹션을 참조하세요. 기본 SSM 문서 이름은 AWS-Noop이며 관리형 노드에서 작업을 수행하지 않습니다.

사용자 정의 SSM 문서 생성에 대한 자세한 내용은 SSM 문서 콘텐츠 생성 섹션을 참조하세요.

파라미터 이름: 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 문서 플러그인 참조 섹션을 참조하세요. 기본 SSM 문서 이름은 AWS-Noop이며 관리형 노드에서 작업을 수행하지 않습니다.

사용자 정의 SSM 문서 생성에 대한 자세한 내용은 SSM 문서 콘텐츠 생성 섹션을 참조하세요.