• 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 도구에 대한 일반 사용 사례 및 모범 사례를 다룹니다. 경우에 따라 이 주제에는 관련 블로그 게시물과 기술 문서의 링크도 포함됩니다.
**참고**
여기에서 각 섹션의 제목은 기술 문서의 해당 섹션으로 연결되는 활성 링크입니다.
**[자동화](systems-manager-automation.md)**
+ 인프라용 셀프 서비스 Automation 런북을 생성합니다.
+ AWS Systems Manager의 도구인 Automation을 사용하여 퍼블릭 Systems Manager 문서(SSM 문서)를 사용하거나 고유한 워크플로를 작성하여 AWS Marketplace 또는 사용자 정의 AMIs에서 Amazon Machine Images(AMIs)를 간단하게 생성합니다.
+ `AWS-UpdateLinuxAmi` 및 `AWS-UpdateWindowsAmi` Automation 런북을 사용하거나 직접 생성한 사용자 정의 Automation 런북을 사용하여 [AMIs를 구축하고 유지 관리](automation-tutorial-update-ami.md)합니다.
**[규정 준수](systems-manager-compliance.md)**
+ 보안 모범 사례로 관리형 노드에서 사용하는 AWS Identity and Access Management(IAM) 역할을 업데이트하여 노드의 [PutComplianceItems](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PutComplianceItems.html) API 작업 사용 기능을 제한하는 것이 좋습니다. 이 API 작업은 Amazon EC2 인스턴스 또는 관리형 노드와 같은 지정된 리소스에 규정 준수 유형 및 기타 규정 준수 세부 정보를 등록합니다. 자세한 내용은 [규정 준수에 대한 권한 구성](compliance-permissions.md) 섹션을 참조하세요.
**[인벤토리](systems-manager-inventory.md)**
+ AWS Config와 함께 AWS Systems Manager의 도구인 Inventory를 사용하여 시간 경과에 따른 애플리케이션 구성을 감사합니다.
**[Maintenance Windows](maintenance-windows.md)**
+ 운영 체제(OS) 패치, 드라이버 업데이트 또는 소프트웨어 설치 등 노드에 방해가 될 가능성이 있는 작업의 일정을 정의합니다.
+ AWS Systems Manager의 도구인 State Manager와 Maintenance Windows의 차이에 대한 자세한 내용은 [State Manager와 Maintenance Windows 중에서 선택](state-manager-vs-maintenance-windows.md) 섹션을 참조하세요.
**[Parameter Store](systems-manager-parameter-store.md)**
+ AWS Systems Manager의 도구인 Parameter Store를 사용하여 글로벌 구성 설정을 중앙에서 관리합니다.
+ [AWS Systems ManagerParameter Store의 AWS KMS 활용 방식](https://docs.aws.amazon.com/kms/latest/developerguide/services-parameter-store.html)
+ [Parameter Store 파라미터에서 AWS Secrets Manager 암호 참조](integration-ps-secretsmanager.md).
**[Patch Manager](patch-manager.md)**
+ AWS Systems Manager의 도구인 Patch Manager를 사용하여 대규모로 패치를 롤아웃하고 여러 노드에 걸쳐 플릿 규정 준수 가시성을 높입니다.
+ [Patch Manager를 AWS Security Hub CSPM와 통합](patch-manager-security-hub-integration.md)하여 플릿의 노드가 규정을 준수하지 않을 때 알림을 받고 보안 관점에서 플릿의 패치 상태를 모니터링합니다. Security Hub CSPM 사용 시 요금이 부과됩니다. 자세한 내용은 [요금](https://aws.amazon.com/security-hub/pricing/)을 참조하세요.
+ 관리형 노드의 패치 규정 준수를 검사할 때는 한 번에 한 가지 방법만 사용하여 [규정 준수 데이터를 실수로 덮어쓰지 않도록](patch-manager-compliance-data-overwrites.md) 하세요.
**[Run Command](run-command.md)**
+ [EC2 Run Command를 이용해 SSH 액세스 없이 대규모 인스턴스를 관리합니다](https://aws.amazon.com/blogs/aws/manage-instances-at-scale-without-ssh-access-using-ec2-run-command/).
+ AWS CloudTrail을 사용하여 AWS Systems Manager의 도구인 Run Command에 의해 또는 이를 대신하여 실행된 모든 API 직접 호출을 감사합니다.
+ Run Command를 사용해 명령을 보낼 때 암호, 구성 데이터 또는 기타 보안 암호와 같이 민감한 정보는 일반 텍스트 형식으로 포함하지 않습니다. 계정의 모든 Systems Manager API 활동은 AWS CloudTrail 로그를 위해 S3 버킷에 기록됩니다. 즉, 해당 S3 버킷에 대한 액세스 권한이 있는 사용자는 그러한 보안 암호의 일반 텍스트 값을 볼 수 있습니다. 따라서 `SecureString` 파라미터를 생성하고 사용하여 Systems Manager 작업에 사용하는 민감한 데이터를 암호화하는 것이 좋습니다.
자세한 내용은 [IAM 정책을 사용하여 Parameter Store 파라미터에 대한 액세스 제한](sysman-paramstore-access.md) 섹션을 참조하세요.
**참고**
기본적으로 CloudTrail이 버킷에 제공하는 로그 파일은 [Amazon S3가 관리하는 암호화 키(SSE-S3)를 사용하는 서버 측 암호화](https://docs.aws.amazon.com/AmazonS3/latest/userguide/UsingServerSideEncryption.html)를 사용하여 암호화됩니다. 직접 관리할 수 있는 보안 계층을 제공하려면 CloudTrail 로그 파일에 대한 [AWS KMS 관리형 키(SSE-KMS)를 사용하는 서버 측 암호화](https://docs.aws.amazon.com/AmazonS3/latest/userguide/UsingKMSEncryption.html)를 대신 사용하면 됩니다.
자세한 내용은 *AWS CloudTrail 사용 설명서*의 [AWS KMS–관리형 키(SSE-KMS)로 CloudTrail 로그 파일 암호화](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/encrypting-cloudtrail-log-files-with-aws-kms.html)를 참조하세요.
+ [Run Command의 대상 및 속도 제어 기능을 사용하여 단계별 명령 작업을 수행합니다.](send-commands-multiple.md)
+ [AWS Identity and Access Management(IAM) 정책을 사용하여 Run Command 및 모든 Systems Manager 도구에 대해 세분화된 액세스 권한을 사용합니다](security_iam_id-based-policy-examples.md#customer-managed-policies).
**[Session Manager](session-manager.md)**
+ [AWS CloudTrail을 사용하여 AWS 계정의 세션 활동을 기록합니다](session-manager-auditing.md).
+ [Amazon CloudWatch Logs 또는 Amazon S3를 사용하여 AWS 계정의 세션 데이터를 로그합니다](session-manager-logging.md).
+ [인스턴스에 대한 사용자 세션 액세스를 제어합니다](session-manager-getting-started-restrict-access.md).
+ [세션의 명령에 대한 액세스를 제한합니다](session-manager-restrict-command-access.md).
+ [ssm-user 계정 관리 권한을 설정하거나 해제합니다](session-manager-getting-started-ssm-user-permissions.md).
**[State Manager](systems-manager-state.md)**
+ [사전 구성된 `AWS-UpdateSSMAgent` 문서를 사용하여 적어도 한 달에 한 번 SSM Agent를 업데이트합니다](state-manager-update-ssm-agent-cli.md).
+ (Windows) PowerShell 또는 DSC 모듈을 Amazon Simple Storage Service(Amazon S3)에 업로드하고 `AWS-InstallPowerShellModule`을 사용합니다.
+ 태그를 이용해 노드에 대한 애플리케이션 그룹을 생성합니다. 그런 다음 개별 노드 ID를 지정하는 대신 `Targets` 파라미터를 사용하여 노드를 대상으로 합니다.
+ [Systems Manager를 사용하여 Amazon Inspector에서 생성된 결과를 자동으로 수정합니다](https://aws.amazon.com/blogs/security/how-to-remediate-amazon-inspector-security-findings-automatically/).
+ [SSM 문서에 중앙 집중식 구성 리포지토리를 사용하고 조직 전체에 걸쳐 문서를 공유합니다](documents-ssm-sharing.md).
+ State Manager와 Maintenance Windows의 차이에 대한 자세한 내용은 [State Manager와 Maintenance Windows 중에서 선택](state-manager-vs-maintenance-windows.md) 섹션을 참조하세요.
**[관리형 노드](fleet-manager-managed-nodes.md)**
+ Systems Manager는 작업을 수행하기 위해 정확한 시간 참조가 필요합니다. 노드의 날짜와 시간이 잘못 설정되어 있으면 API 요청의 서명 날짜와 일치하지 않을 수 있습니다. 이로 인해 오류 또는 불완전한 기능이 발생할 수 있습니다. 예를 들어 시간 설정이 올바르지 않은 노드는 관리형 노드 목록에 포함되지 않게 됩니다.
노드에 대한 자세한 정보는 [Amazon EC2 인스턴스의 시간 설정](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/set-time.html)을 참조하세요.
+ Linux 관리 노드에서는 [서명을 확인합니다 SSM Agent](verify-agent-signature.md).
**추가 정보**
+ [Systems Manager의 보안 모범 사례](security-best-practices.md)
# Systems Manager 리소스 및 아티팩트 삭제
더 이상 해당 리소스에 대한 데이터를 보거나 아티팩트를 사용할 필요가 없는 경우 Systems Manager 리소스 및 아티팩트를 삭제하는 것이 좋습니다. 다음 표에는 각 Systems Manager 도구 또는 아티팩트와 Systems Manager에서 만든 리소스 또는 아티팩트 삭제에 대한 자세한 정보가 있는 링크가 나열됩니다.
****
| 기능 또는 아티팩트 | 세부 정보 |
| --- | --- |
| Application Manager | Application Manager에서 애플리케이션을 삭제할 수 없지만, 기본 [태그](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_RemoveTagsFromResource.html), [Resource Groups](https://docs.aws.amazon.com/ARG/latest/userguide/deleting-resource-groups.html) 또는 [AWS CloudFormation 스택](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cfn-console-delete-stack.html)을 삭제하여 서비스에서 애플리케이션을 제거할 수 있습니다. |
| 자동화 | Systems Manager 자동화를 사용하여 AWS 리소스를 만드는 경우, 해당 AWS Management Console을 사용하여 이러한 리소스를 수동으로 삭제해야 합니다. 사용자 지정 실행서를 만든 경우 기본 SSM 문서를 삭제할 수 있습니다. 자세한 내용은 [사용자 지정 SSM 문서 삭제 중](deleting-documents.md) 섹션을 참조하세요. |
| Change Calendar | change calendar 및 change calendar 이벤트를 삭제할 수 있습니다. 자세한 내용은 [Change Calendar 삭제](change-calendar-delete.md) 및 [Change Calendar 이벤트 삭제](change-calendar-delete-event.md) 섹션을 참조하세요. |
| Change Manager | 변경 템플릿을 삭제할 수 있습니다. 자세한 내용은 [변경 템플릿 삭제](change-templates-delete.md) 섹션을 참조하세요. |
| 규정 준수 | Systems Manager Compliance는 Patch Manager 패치 및 State Manager 연결에 대한 규정 준수 데이터를 자동으로 표시합니다. 이 데이터는 삭제할 수 없습니다. S3 버킷에서 규정 준수 데이터를 중앙 집중화하도록 리소스 데이터 동기화를 구성한 경우, 동기화를 삭제할 수 있습니다. 자세한 내용은 [Compliance의 리소스 데이터 동기화 삭제](systems-manager-compliance-delete-RDS.md) 섹션을 참조하세요. |
| Distributor | Distributor에서 패키지를 삭제할 수 있습니다. 자세한 내용은 [Distributor 패키지 삭제](distributor-working-with-packages-dpkg.md) 섹션을 참조하세요. |
| Explorer | Explorer가 OpsData를 수집하는 소스를 연결 중지시킬 수 있습니다. 자세한 내용은 [Systems Manager Explorer 데이터 원본 편집](Explorer-using-editing-data-sources.md) 섹션을 참조하세요. Explorer에서 여러 AWS 리전 및 계정의 OpsData 및 OpsItems을(를) 집계하는 데 사용하는 리소스 데이터 동기화를 Amazon Simple Storage Service(Amazon S3) 버킷 하나로 삭제할 수도 있습니다. 자세한 내용은 [Systems Manager Explorer 리소스 데이터 동기화 삭제](Explorer-using-resource-data-sync-delete.md) 섹션을 참조하세요. S3 버킷 삭제에 대한 자세한 내용은 **Amazon Simple Storage Service 사용 설명서서의 [버킷 삭제](https://docs.aws.amazon.com/AmazonS3/latest/userguide/delete-bucket.html)를 참조하세요. |
| Fleet Manager | Fleet Manager를 사용하여 관리형 노드를 삭제할 수 없습니다. Amazon Elastic Compute Cloud(Amazon EC2)를 사용해야 합니다. 자세한 내용은 [인스턴스 종료(Linux)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/terminating-instances.html) 및 [인스턴스 종료(Windows)](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/terminating-instances.html)를 참조하세요. |
| 인벤토리 | 메타데이터를 수집할 일정 및 리소스를 정의하는 State Manager 연결을 삭제하여 Inventory 데이터 수집을 중지할 수 있습니다. 자세한 내용은 [데이터 수집 중지 및 인벤토리 데이터 삭제](systems-manager-inventory-delete.md) 섹션을 참조하세요. 더 이상 AWS Systems Manager Inventory를 사용하여 AWS 리소스에 대한 메타데이터를 보고 싶지 않다면, 인벤토리 데이터 수집에 사용되는 리소스 데이터 동기화를 삭제하는 것이 좋습니다. 자세한 내용은 [Inventory 리소스 데이터 동기화 삭제](systems-manager-inventory-delete.md#systems-manager-inventory-delete-RDS) 섹션을 참조하세요. |
| Maintenance Windows | 유지 관리 기간, 유지 관리 기간 대상, 유지 관리 기간 작업을 삭제할 수 있습니다. 자세한 내용은 [콘솔을 사용하여 유지 관리 기간 리소스 업데이트 또는 삭제](sysman-maintenance-update.md) 섹션을 참조하세요. |
| OpsCenter | AWS Command Line Interface 또는 AWS SDK를 사용하여 API 작업 [삭제OpsItem](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_DeleteOpsItem.html)를 호출하면 개인 OpsItem을(를) 삭제할 수 있습니다. AWS Management Console에서는 OpsItem을(를) 삭제할 수 없습니다. 자세한 내용은 [OpsItems 삭제](OpsCenter-delete-OpsItems.md) 섹션을 참조하세요. |
| Parameter Store | 생성한 파라미터를 삭제할 수 있습니다. 자세한 내용은 [Parameter Store에서 파라미터 삭제](deleting-parameters.md) 섹션을 참조하세요. |
| Patch Manager | 사용자 지정 패치 기준을 삭제할 수 있습니다. 자세한 내용은 [사용자 지정 패치 기준선 업데이트 또는 삭제](patch-manager-update-or-delete-a-patch-baseline.md) 섹션을 참조하세요. |
| 빠른 설정 | 빠른 설정으로 생성된 연결을 삭제할 수 있습니다. 연결은 State Manager에서 저장 및 처리됩니다. 자세한 내용은 [연결 삭제](systems-manager-state-manager-delete-association.md) 섹션을 참조하세요. |
| Run Command | 명령이 처리를 완료하면 해당 명령에 대한 정보가 **명령 기록(Command history)** 탭에 저장됩니다. **명령 기록(Command history)** 탭에서 정보를 삭제할 수 없습니다. |
| 자동화 | 자동화가 처리를 완료하면 해당 작업에 대한 정보가 **실행** 탭에 저장됩니다. **실행** 탭의 정보는 삭제할 수 없습니다. |
| 서비스 연결 역할 | Systems Manager는 [일부 도구](using-service-linked-roles.md)에 대한 서비스 연결 역할을 자동으로 생성합니다. 이러한 역할을 삭제할 수 있습니다. 자세한 내용은 [Systems Manager에 대한 `AWSServiceRoleForAmazonSSM` 서비스 연결 역할 삭제](using-service-linked-roles-service-action-1.md#delete-service-linked-role-service-action-1) 섹션을 참조하세요. |
| Session Manager | 세션을 종료한 후에는 Session Manager가 리소스에 대한 데이터를 보존하지 않습니다. 세션을 종료하려면 [세션 종료](session-manager-working-with-sessions-end.md) 섹션을 참조하세요. |
| SSM Agent | 노드에서 SSM Agent를 수동으로 제거할 수 있습니다. 자세한 내용은 다음 항목을 참조하세요. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/systems-manager/latest/userguide/systems-manager-best-practices-delete-resources.html) |
| State Manager | 연결을 삭제할 수 있습니다. 자세한 내용은 [연결 삭제](systems-manager-state-manager-delete-association.md) 섹션을 참조하세요. |
| Systems Manager 문서 서비스 | AWS 또는 AWS Support에서 제공한 실행서는 삭제할 수 없지만, 사용자 지정 실행서는 삭제할 수 있습니다. 자세한 내용은 [사용자 지정 SSM 문서 삭제 중](deleting-documents.md) 섹션을 참조하세요. |
# State Manager와 Maintenance Windows 중에서 선택
AWS Systems Manager의 도구인 State Manager 및 Maintenance Windows가 관리형 노드에서 몇 가지 유사한 유형의 업데이트를 수행할 수 있습니다. 어느 유형의 업데이트를 선택할지는 시스템 규정 준수를 자동화해야 하는지 아니면 지정한 기간 동안 우선순위가 높고 시간에 민감한 태스크를 수행해야 하는지 여부에 따라 다릅니다.
## State Manager 및 Maintenance Windows: 주요 사용 사례
AWS Systems Manager의 도구인 State Manager는 AWS 계정 내의 관리형 노드와 AWS 리소스에 대한 목표 상태 구성을 설정하고 유지 관리합니다. 구성 및 대상의 조합을 연결 객체로 정의할 수 있습니다. State Manager는 계정의 모든 관리형 노드를 일관된 상태로 유지하려는 경우 Amazon EC2 Auto Scaling을 사용하여 새 노드를 생성하려는 경우 또는 계정의 관리형 노드에 대한 엄격한 규정 준수 보고 요구 사항이 있는 경우에 권장되는 도구입니다.
State Manager의 주요 사용 사례는 다음과 같습니다.
+ **Auto Scaling 시나리오: **State Manager는 계정 내에서 시작된 모든 새 노드를 수동으로 또는 Auto Scaling 그룹을 통해 모니터링할 수 있습니다. 새 노드를 대상으로 하는 계정에 연결이 있는 경우(태그 또는 모든 노드를 통해) 해당 특정 연결이 새 노드에 자동으로 적용됩니다.
+ **규정 준수 보고:** State Manager는 계정의 리소스에 대한 필요한 상태의 준수 보고를 유도할 수 있습니다.
+ **모든 노드 지원:** State Manager는 지정된 계정 내의 모든 노드를 대상으로 지정할 수 있습니다.
**유지 관리 기간**은 지정된 기간 내에 AWS 리소스에 대해 하나 이상의 작업을 수행합니다. 시작 및 종료 시간으로 단일 유지 관리 기간을 정의할 수 있습니다. 이 유지 관리 기간 내에서 실행할 여러 태스크를 지정할 수 있습니다. 우선순위가 높은 작업에 관리형 노드 패치, 업데이트 기간 동안 노드에서 여러 유형의 태스크 실행 또는 노드에서 업데이트 작업을 실행할 수 있는 시점 제어가 포함되는 경우 AWS Systems Manager의 도구인 Maintenance Windows를 사용합니다.
Maintenance Windows의 주요 사용 사례는 다음과 같습니다.
+ **여러 문서 실행:** 유지 관리 기간은 여러 태스크를 실행할 수 있습니다. 태스크마다 다른 문서 유형을 사용할 수 있습니다. 따라서 단일 유지 관리 기간 내에서 여러 태스크를 사용하여 복잡한 워크플로를 구축할 수 있습니다.
+ **패치 적용:** 유지 관리 기간에서는 특정 태그 또는 리소스 그룹으로 태그가 지정된 단일 리전의 모든 관리형 노드에 대한 패치 적용 지원이 제공될 수 있습니다. 패치에는 일반적으로 노드 중단(예: 로드 밸런서에서 노드 제거), 패치 및 사후 처리(노드를 프로덕션으로 다시 배치)가 포함되기 때문에 지정된 패치 기간 내에서 일련의 태스크로 패치를 수행할 수 있습니다.
**참고**
유지 관리 기간을 사용하면 패치 적용 작업이 단일 계정의 단일 리전으로 제한됩니다. Systems Manager의 도구인 Quick Setup에서 생성된 패치 정책을 사용하여, AWS Organizations에서 생성된 조직의 일부 또는 모든 계정 및 리전에 대한 패치 적용을 구성할 수도 있습니다. 자세한 내용은 [Quick Setup의 패치 정책 구성](patch-manager-policies.md) 섹션을 참조하세요.
+ **기간 작업:** 유지 관리 기간은 특정 기간 내에 시작되는 하나 이상의 작업 집합을 만들 수 있습니다. 해당 기간 외에는 유지 관리 기간이 시작되지 않습니다. 이미 시작된 작업은 해당 기간 외에도 완료될 때까지 계속됩니다.
다음 표에서는 State Manager와 Maintenance Windows의 주요 기능을 비교합니다.
| 기능 | State Manager | Maintenance Windows |
| --- | --- | --- |
| **CloudFormation ** 통합 | AWS CloudFormation 템플릿은 State Manager 연결을 지원합니다. | CloudFormation 템플릿은 유지 관리 기간, 기간 대상 및 기간 태스크를 지원합니다. |
| **규정 준수** | 모든 State Manager 연결은 대상 리소스의 필요한 상태에 대한 규정 준수를 보고합니다. Compliance 대시보드를 사용하여 보고된 규정 준수를 집계하고 볼 수 있습니다. | 해당 사항 없음. |
| **구성 관리 통합** | State Manager는 Microsoft PowerShell Desired State Configuration(DSC), Ansible 플레이북, Chef 레시피와 같은 외부의 목표 상태 솔루션을 지원합니다. State Manager 연결을 사용하여 구성 관리 솔루션이 작동하는지 테스트하고 준비가 되면 해당 구성 변경 사항을 노드에 적용할 수 있습니다. | 해당 사항 없음. |
| **문서** | State Manager 구성은 Amazon Simple Storage Service(Amazon S3) 버킷과 같은 AWS 리소스에 대한 Policy 문서(인벤토리 정보 수집용), Automation 실행서 또는 관리형 노드용 Systems Manager Command 문서(SSM 문서)로 정의할 수 있습니다. | Maintenance Windows 구성은 자동화 문서(선택적 승인 워크플로가 있는 다단계 작업) 또는 SSM 문서(관리형 노드의 필요한 상태)로 정의할 수 있습니다. |
| 모니터링 | State Manager는 노드의 구성, 연결 또는 상태의 변경 사항(예: 새 노드가 온라인 상태가 됨)을 모니터링합니다. State Manager가 이러한 변경 사항을 감지하면 해당 연결로 원래 대상이 지정된 노드에 지정된 연결이 다시 적용됩니다. | 해당 사항 없음. |
| **태스크 내 우선순위** | 해당 사항 없음. | 유지 관리 기간 내의 태스크에 우선순위를 할당할 수 있습니다. 우선순위가 같은 태스크는 모두 병렬로 실행됩니다. 우선순위가 낮은 태스크는 우선순위가 높은 태스크가 최종 상태에 도달한 후에 실행됩니다. 조건부로 태스크를 실행할 수 있는 방법은 없습니다. 우선순위가 높은 태스크가 최종 상태에 도달하면 이전 태스크의 상태에 관계없이 다음 우선순위 태스크가 실행됩니다. |
| **안전 제어** | State Manager는 대규모 플릿 전체에 구성을 배포할 때 두 가지 안전 제어를 지원합니다. 최대 동시성을 사용하여 구성을 적용해야 하는 동시 노드 또는 리소스 수를 정의할 수 있습니다. 플릿 전체에서 특정 수 또는 비율의 오류가 발생하는 경우 State Manager 연결을 일시 중지하는 데 사용할 수 있는 최대 오류율을 정의할 수 있습니다. | 유지 관리 기간은 대규모 플릿 전체에 구성을 배포할 때 두 가지 안전 제어를 지원합니다. 최대 동시성을 사용하여 구성을 적용해야 하는 동시 노드 또는 리소스 수를 정의할 수 있습니다. 플릿 전체에서 특정 수 또는 비율의 오류가 발생하는 경우 유지 관리 기간에서 작업을 일시 중지하는 데 사용할 수 있는 최대 오류율을 정의할 수 있습니다. |
| 일정 예약 | 온디맨드로, 특정 cron 간격으로, 지정된 속도로 또는 생성된 후 한 번 State Manager 연결을 실행할 수 있습니다. 이는 일관되고 시기 적절한 방식으로 필요한 리소스 상태를 유지하려는 경우에 유용합니다. State Manager 연결에 대한 Cron 표현식은 월 필드를 지원하지 않습니다(예: 3월 한 달 동안 `03` 또는`MAR`) 월별 또는 분기별 구성 업데이트가 필요한 경우 유지 관리 기간이 요구 사항을 가장 잘 충족할 수 있습니다. 자세한 내용은 [참조: Systems Manager용 Cron 및 Rate 표현식](reference-cron-and-rate-expressions.md) 섹션을 참조하세요. | 유지 관리 기간은 `at` 표현식(예: `"at(2021-07-07T13:15:30)"`), cron 및 rate 표현식, 오프셋이 있는 cron, 유지 관리 기간이 실행되어야 하는 시작 및 종료 시간, 지정된 기간 내에 예약을 중지할 시점을 지정하는 마감 시간을 비롯한 여러 예약 옵션을 지원합니다. |
| **대상 지정** | State Manager 연결은 노드 ID, 태그 또는 리소스 그룹을 사용하여 하나 이상의 노드를 대상으로 할 수 있습니다. State Manager는 지정된 계정 내의 모든 관리형 노드를 대상으로 할 수 있습니다. | 유지 관리 기간은 노드 ID, 태그 또는 리소스 그룹을 사용하여 하나 이상의 노드를 대상으로 할 수 있습니다. |
| **유지 관리 기간 내의 태스크** | 해당 사항 없음. | 유지 관리 기간은 각 태스크가 특정 Automation 실행서 또는 Command 문서 작업을 대상으로 하는 하나 이상의 태스크를 지원할 수 있습니다. 태스크마다 다른 우선순위가 설정되지 않는 한 유지 관리 기간 내의 모든 태스크가 병렬로 실행됩니다. 전반적으로 유지 관리 기간은 다음과 같은 4가지 유형의 태스크를 지원합니다. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/systems-manager/latest/userguide/state-manager-vs-maintenance-windows.html) |