• AWS Systems Manager CloudWatch 대시보드는 2026년 4월 30일 이후에는 더 이상 사용할 수 없습니다. 고객은 Amazon CloudWatch 콘솔을 계속 사용하여 현재와 마찬가지로 Amazon CloudWatch 대시보드를 보고, 생성하고, 관리할 수 있습니다. 자세한 내용은 [Amazon CloudWatch 대시보드 설명서](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html)를 참조하세요.
# Systems Manager로 하이브리드 및 멀티클라우드 환경에서 노드 관리
AWS Systems Manager를 사용하여 Amazon Elastic Compute Cloud(EC2) 인스턴스와 다양한 비 EC2 시스템 유형을 모두 관리할 수 있습니다. 이 섹션에서는 계정 및 시스템 관리자가 **[하이브리드 및 멀티클라우드](operating-systems-and-machine-types.md#supported-machine-types) 환경에서 Systems Manager를 사용하여 비 EC2 시스템을 관리하려고 수행하는 설정 작업을 설명합니다. 이러한 설정을 완료하면 AWS 계정 관리자가 권한을 부여한 사용자는 Systems Manager를 사용하여 조직의 비 EC2 시스템을 구성하고 관리할 수 있습니다.
Systems Manager와 함께 사용하도록 구성된 모든 시스템을 **관리형 노드라고 합니다.
**참고**
다른 비 EC2 시스템과 동일한 하이브리드 정품 인증 단계를 사용하여 엣지 디바이스를 관리형 노드로 등록할 수 있습니다. 이러한 유형의 엣지 디바이스에는 AWS IoT 디바이스 이외의 디바이스와 AWS IoT 디바이스가 모두 포함됩니다. 이 섹션에서 설명하는 프로세스에 따라 이러한 유형의 엣지 디바이스를 설정합니다.
Systems Manager AWS IoT Greengrass 코어 소프트웨어를 사용하는 엣지 디바이스도 지원합니다. AWS IoT Greengrass 코어 디바이스의 설정 프로세스 및 요구 사항은 AWS 엣지 디바이스 이외의 디바이스와 AWS IoT 디바이스의 설정 프로세스 및 요구 사항과 다릅니다. Systems Manager에 사용할 AWS IoT Greengrass 디바이스를 등록하는 방법에 대한 자세한 내용은 [Systems Manager를 통한 엣지 디바이스 관리](systems-manager-setting-up-edge-devices.md) 섹션을 참조하세요.
비 EC2 macOS 시스템에서는 Systems Manager 하이브리드 및 멀티클라우드 환경이 지원되지 않습니다.
Systems Manager를 사용하여 Amazon Elastic Compute Cloud(Amazon EC2) 인스턴스를 관리하거나 하이브리드 및 멀티클라우드 환경에서 Amazon EC2 인스턴스와 비 EC2 시스템을 모두 사용하려는 경우 먼저 [Systems Manager를 사용한 EC2 인스턴스 관리](systems-manager-setting-up-ec2.md)의 단계를 따릅니다.
Systems Manager에 대한 하이브리드 및 멀티클라우드 환경을 구성하면 다음을 수행할 수 있습니다.
+ 한곳에서 동일한 도구와 스크립트를 사용하여 하이브리드 및 멀티클라우드 워크로드를 원격으로 관리할 수 있는 일관성 있고 안전한 수단이 됩니다.
+ AWS Identity and Access Management(IAM)를 통해 서버와 VM에서 수행할 수 있는 작업에 대한 액세스 제어를 중앙 집중화합니다.
+ AWS CloudTrail에 기록된 API 활동을 확인하여 시스템에 대해 수행되는 작업에 대한 감사를 중앙 집중화합니다.
CloudTrail을 사용한 Systems Manager 작업 모니터링에 대한 자세한 내용은 [AWS CloudTrail를 사용하여 AWS Systems Manager API 호출 로깅](monitoring-cloudtrail-logs.md) 섹션을 참조하세요.
+ 서비스 실행 성공에 대한 알림을 보내도록 Amazon EventBridge 및 Amazon Simple Notification Service(Amazon SNS)를 구성하여 모니터링을 중앙 집중화합니다.
EventBridge를 사용하여 Systems Manager 이벤트 모니터링에 대한 자세한 내용은 [Amazon EventBridge로 Systems Manager 이벤트 모니터링](monitoring-eventbridge-events.md) 섹션을 참조하세요.
**관리형 노드 정보**
이 섹션에 설명된 대로 Systems Manager용 비 EC2 시스템 구성을 마치면 하이브리드 정품 인증 시스템이 AWS Management Console에 나열되고 **관리형 노드로 설명됩니다. 콘솔에서는 하이브리드 정품 인증 관리형 노드의 ID가 접두사 "mi-"로 Amazon EC2 인스턴스와 구별됩니다. Amazon EC2 인스턴스 ID는 접두사 “i-”를 사용합니다.
관리형 노드는 Systems Manager에 사용하도록 구성된 시스템입니다. 이전에는 관리형 노드를 모두 관리형 인스턴스라고 했습니다. 이제 인스턴스라는 용어는 EC2 인스턴스만을 지칭합니다.** [deregister-managed-instance](https://docs.aws.amazon.com/cli/latest/reference/ssm/deregister-managed-instance.html) 명령은 이러한 용어 변경 이전에 이름이 붙여졌습니다.
자세한 내용은 [관리형 노드 작업](fleet-manager-managed-nodes.md) 섹션을 참조하세요.
**중요**
수명 종료(EOL)에 도달한 OS 버전은 사용하지 않는 것이 좋습니다. AWS를 포함한 OS 공급업체는 일반적으로 EOL에 도달한 버전의 보안 패치 또는 기타 업데이트를 제공하지 않습니다. EOL 시스템을 계속 사용하면 보안 수정 사항과 기타 운영 문제를 포함한 업그레이드를 적용할 수 없는 위험이 크게 증가합니다. AWS는 EOL에 도달한 OS 버전에서 Systems Manager 기능을 테스트하지 않습니다.
**인스턴스 사용자 정보**
Systems Manager에서는 하이브리드 및 멀티클라우드 환경의 비 EC2 관리형 노드에 대한 표준 인스턴스 티어와 고급 인스턴스 티어를 제공합니다. 표준 인스턴스 티어를 사용하면 한 AWS 리전의 AWS 계정당 최대 1,000개의 하이브리드 정품 인증 시스템을 등록할 수 있습니다. 단일 계정 및 리전에 1,000개가 넘는 비 EC2 시스템을 등록해야 하는 경우에는 고급 인스턴스 티어를 사용합니다. 고급 인스턴스에서는 AWS Systems Manager Session Manager를 사용하여 비 EC2 시스템에도 연결할 수 있습니다. Session Manager에서는 관리형 노드에 대한 대화형 쉘 액세스 권한를 제공합니다.
자세한 내용은 [인스턴스 티어 구성](fleet-manager-configure-instance-tiers.md) 섹션을 참조하세요.
**Topics**
+ [하이브리드 및 멀티클라우드 환경에서 Systems Manager에 필요한 IAM 서비스 역할 생성](hybrid-multicloud-service-role.md)
+ [하이브리드 활성화를 생성하여 Systems Manager에 노드 등록](hybrid-activation-managed-nodes.md)
+ [하이브리드 Linux 노드에 SSM Agent 설치](hybrid-multicloud-ssm-agent-install-linux.md)
+ [하이브리드 Windows Server 노드에 SSM Agent 설치](hybrid-multicloud-ssm-agent-install-windows.md)
# 하이브리드 및 멀티클라우드 환경에서 Systems Manager에 필요한 IAM 서비스 역할 생성
[하이브리드 및 멀티클라우드](operating-systems-and-machine-types.md#supported-machine-types) 환경의 비 EC2(Amazon Elastic Compute Cloud) 시스템에서 AWS Systems Manager 서비스와 통신하려면 AWS Identity and Access Management(IAM) 서비스 역할이 필요합니다. 역할이 Systems Manager 서비스에 AWS Security Token Service(AWS STS) [https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html) 신뢰를 부여합니다. AWS 계정마다 한 번만 하이브리드 및 멀티클라우드 환경의 서비스 역할을 생성하면 됩니다. 그러나 하이브리드 및 멀티클라우드 환경의 시스템에 다양한 권한이 필요한 경우 다양한 하이브리드 정품 인증을 위한 여러 서비스 역할 생성을 선택할 수 있습니다.
다음 절차에서는 Systems Manager 콘솔 또는 기본 명령줄 도구를 사용하여 필수 서비스 역할을 생성하는 방법을 설명합니다.
## AWS Management Console을 사용하여 Systems Manager 하이브리드 활성화를 위한 IAM 서비스 역할 생성
다음 절차를 사용하여 용 IAM 서비스 역할을 생성합니다. 이 절차에서는 Systems Manager 코어 기능을 위한 `AmazonSSMManagedInstanceCore` 정책을 사용합니다. 사용 사례에 따라 온프레미스 컴퓨터가 다른 Systems Manager 도구나 AWS 서비스에 액세스하려면 서비스 역할에 정책을 추가해야 할 수 있습니다. 예를 들어, 필수 AWS 관리형 Amazon Simple Storage Service(Amazon S3) 버킷에 액세스하지 않으면 Patch Manager 패치 적용 작업이 실패합니다.
**서비스 역할을 만들려면(콘솔)**
1. [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)에서 IAM 콘솔을 엽니다.
1. 탐색 창에서 **역할(Roles)**을 선택한 후 **역할 생성(Create role)**을 선택합니다.
1. **신뢰할 수 있는 엔터티 선택(Select trusted entity)**에서 다음을 선택합니다.
1. **신뢰할 수 있는 엔터티 유형**에서 **AWS 서비스**를 선택합니다.
1. **기타 AWS 서비스 사용 사례**에서 **Systems Manager**를 선택합니다.
1. **Systems Manager**를 선택합니다.
다음 이미지에서는 Systems Manager 옵션의 위치를 강조 표시합니다.
![\[Systems Manager는 사용 사례의 옵션 중 하나입니다.\]](http://docs.aws.amazon.com/ko_kr/systems-manager/latest/userguide/images/iam_use_cases_for_MWs.png)
1. **다음**을 선택합니다.
1. **권한 추가** 페이지에서 다음을 수행합니다.
+ **검색(Search)** 필드를 사용하여 **AmazonSSMManagedInstanceCore** 정책을 찾습니다. 다음 그림과 같이 이름 옆에 있는 확인란을 선택합니다.
![\[AmazonSSMManagedInstanceCore 행에서 확인란이 선택되어 있습니다.\]](http://docs.aws.amazon.com/ko_kr/systems-manager/latest/userguide/images/setup-instance-profile-2.png)
**참고**
이 콘솔은 사용자가 다른 정책을 검색하더라도 사용자의 선택을 유지합니다.
+ [(선택 사항) S3 버킷 액세스에 대한 사용자 지정 정책 생성](setup-instance-permissions.md#instance-profile-custom-s3-policy) 절차에서 사용자 지정 S3 버킷 정책을 생성한 경우 해당 이름을 검색하고 이름 옆의 확인란을 선택합니다.
+ Directory Service에서 관리하는 Active Directory에 비 EC2 시스템을 조인하려는 경우 **AmazonSSMDirectoryServiceAccess**를 검색하고 이름 옆의 확인란을 선택합니다.
+ EventBridge 또는 CloudWatch Logs를 사용하여 관리형 노드를 관리하거나 모니터링하려는 경우 **CloudWatchAgentServerPolicy**를 검색하고 이름 옆의 확인란을 선택합니다.
1. **다음**을 선택합니다.
1. **역할 이름**의 경우 새 IAM 서버 역할의 이름(예: **SSMServerRole**)을 입력합니다.
**참고**
역할 이름을 기록해 둡니다. 이 역할은 Systems Manager를 사용하여 관리하려는 새 시스템을 등록할 때 선택하게 됩니다.
1. (선택 사항) **설명**의 경우 이 IAM 서버 역할에 대한 설명을 업데이트합니다.
1. (선택 사항) **Tags**(태그)에서 이 역할에 대한 액세스를 구성, 추적 또는 제어할 태그-키 값 페어를 하나 이상 추가합니다.
1. **역할 생성**을 선택합니다. 그러면 **역할** 페이지로 돌아갑니다.
## AWS CLI을 사용하여 Systems Manager 하이브리드 활성화를 위한 IAM 서비스 역할 생성
다음 절차를 사용하여 용 IAM 서비스 역할을 생성합니다. 이 절차에서는 `AmazonSSMManagedInstanceCore` 정책 Systems Manager 코어 기능을 사용합니다. 사용 사례에 따라 [하이브리드 및 멀티클라우드](operating-systems-and-machine-types.md#supported-machine-types) 환경의 비 EC2 시스템에서 기타 도구 또는 AWS 서비스에 액세스할 수 있도록 서비스 역할에 추가 정책을 추가하는 것이 좋습니다.
**S3 버킷 정책 요구 사항**
다음 사례 중 하나에 해당되는 경우 이 절차를 완료하기 전에 Amazon Simple Storage Service(Amazon S3) 버킷에 대한 사용자 정의 IAM 권한 정책을 생성해야 합니다.
+ **사례 1** - VPC 엔드포인트를 사용하여 VPC를 지원되는 AWS 서비스 및 AWS PrivateLink에 의해 제공되는 VPC 엔드포인트 서비스에 비공개로 연결하고 있습니다.
+ **사례 2** - Amazon S3 버킷에 대한 Run Command 명령 또는 Session Manager 세션의 출력을 저장하기 위한 작업 등 Systems Manager 작업의 일부로 생성되는 S3 버킷을 사용할 계획입니다. 진행하기 전에 [인스턴스 프로파일에 대한 사용자 정의 S3 버킷 정책 생성](setup-instance-permissions.md#instance-profile-custom-s3-policy)의 단계를 수행합니다. 해당 주제의 S3 버킷 정책에 대한 정보 또한 서비스 역할에 적용됩니다.
------
#### [ AWS CLI ]
**하이브리드 및 멀티클라우드 환경의 IAM 서비스 역할 생성 방법(AWS CLI)**
1. 아직 하지 않은 경우 AWS Command Line Interface(AWS CLI)을 설치하고 구성합니다.
자세한 내용은 [최신 버전의 AWS CLI 설치 또는 업데이트](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html)를 참조하세요.
1. 로컬 컴퓨터에서 다음 신뢰 정책과 함께 `SSMService-Trust.json`과 같은 이름으로 텍스트 파일을 생성합니다. 파일을 `.json` 파일 확장명으로 저장해야 합니다. 하이브리드 활성화를 생성한 ARN에서 AWS 계정 및 AWS 리전를 지정해야 합니다. 계정 ID와 리전의 *placeholder values*를 자신의 정보로 바꿉니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement":[
{
"Sid":"",
"Effect":"Allow",
"Principal":{
"Service":"ssm.amazonaws.com"
},
"Action":"sts:AssumeRole",
"Condition":{
"StringEquals":{
"aws:SourceAccount":"123456789012"
},
"ArnEquals":{
"aws:SourceArn":"arn:aws:ssm:us-east-1:111122223333:*"
}
}
}
]
}
```
------
1. AWS CLI를 열고, JSON 파일을 생성한 디렉터리에서 [create-role](https://docs.aws.amazon.com/cli/latest/reference/iam/create-role.html) 명령을 사용하여 서비스 역할을 생성합니다. 이 예제에서는 `SSMServiceRole`라는 역할을 생성합니다. 원하는 경우 다른 이름을 선택할 수 있습니다.
------
#### [ Linux & macOS ]
```
aws iam create-role \
--role-name SSMServiceRole \
--assume-role-policy-document file://SSMService-Trust.json
```
------
#### [ Windows ]
```
aws iam create-role ^
--role-name SSMServiceRole ^
--assume-role-policy-document file://SSMService-Trust.json
```
------
1. 다음과 같이 [attach-role-policy](https://docs.aws.amazon.com/cli/latest/reference/iam/attach-role-policy.html) 명령을 실행하여, 방금 생성한 서비스 역할이 세션 토큰을 생성할 수 있도록 허용합니다. 세션 토큰은 Systems Manager를 사용하여 명령을 실행할 수 있도록 관리형 노드 권한을 부여합니다.
**참고**
하이브리드 및 멀티클라우드 환경의 관리형 노드를 위한 서비스 프로파일을 위해 추가하는 정책은 Amazon Elastic Compute Cloud(Amazon EC2) 인스턴스를 위한 인스턴스 프로파일을 생성하는 데 사용되는 정책과 동일합니다. 다음 명령에 사용되는 AWS 정책에 대한 자세한 내용은 [Systems Manager에 필요한 인스턴스 권한 구성](setup-instance-permissions.md)을 참조하세요.
(필수) 다음 명령을 실행하여 관리형 노드가 AWS Systems Manager 서비스 핵심 기능을 사용할 수 있게 허용합니다.
------
#### [ Linux & macOS ]
```
aws iam attach-role-policy \
--role-name SSMServiceRole \
--policy-arn arn:aws:iam::aws:policy/AmazonSSMManagedInstanceCore
```
------
#### [ Windows ]
```
aws iam attach-role-policy ^
--role-name SSMServiceRole ^
--policy-arn arn:aws:iam::aws:policy/AmazonSSMManagedInstanceCore
```
------
서비스 역할을 위한 사용자 정의 S3 버킷 정책을 생성한 경우 다음 명령을 실행하여 AWS Systems Manager Agent(SSM Agent)가 정책에서 지정한 버킷에 액세스할 수 있게 합니다. *account-id* 및 *amzn-s3-demo-bucket*을 AWS 계정 ID 및 버킷 이름으로 바꿉니다.
------
#### [ Linux & macOS ]
```
aws iam attach-role-policy \
--role-name SSMServiceRole \
--policy-arn arn:aws:iam::account-id:policy/amzn-s3-demo-bucket
```
------
#### [ Windows ]
```
aws iam attach-role-policy ^
--role-name SSMServiceRole ^
--policy-arn arn:aws:iam::account-id:policy/amzn-s3-demo-bucket
```
------
(선택) 다음 명령을 실행하여 SSM Agent가 관리형 노드의 도메인 조인 요청을 위해 사용자 대신 Directory Service에 액세스하도록 허용합니다. 노드를 Microsoft AD 디렉터리에 조인하는 경우에만 서비스 역할에 이 정책이 필요합니다.
------
#### [ Linux & macOS ]
```
aws iam attach-role-policy \
--role-name SSMServiceRole \
--policy-arn arn:aws:iam::aws:policy/AmazonSSMDirectoryServiceAccess
```
------
#### [ Windows ]
```
aws iam attach-role-policy ^
--role-name SSMServiceRole ^
--policy-arn arn:aws:iam::aws:policy/AmazonSSMDirectoryServiceAccess
```
------
(선택) 다음 명령을 실행하여 CloudWatch 에이전트가 관리형 노드에서 실행되도록 허용합니다. 이 명령을 사용하면 노드에서 정보를 읽고 CloudWatch에 쓸 수 있습니다. Amazon EventBridge 또는 Amazon CloudWatch Logs 등의 서비스를 사용할 경우에만 서비스 프로파일에 이 정책이 필요합니다.
```
aws iam attach-role-policy \
--role-name SSMServiceRole \
--policy-arn arn:aws:iam::aws:policy/CloudWatchAgentServerPolicy
```
------
#### [ Tools for PowerShell ]
**하이브리드 및 멀티클라우드 환경의 IAM 서비스 역할 생성 방법(AWS Tools for Windows 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. 로컬 컴퓨터에서 다음 신뢰 정책과 함께 `SSMService-Trust.json`과 같은 이름으로 텍스트 파일을 생성합니다. 파일을 `.json` 파일 확장명으로 저장해야 합니다. 하이브리드 활성화를 생성한 ARN에서 AWS 계정 및 AWS 리전를 지정해야 합니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "",
"Effect": "Allow",
"Principal": {
"Service": "ssm.amazonaws.com"
},
"Action": "sts:AssumeRole",
"Condition": {
"StringEquals": {
"aws:SourceAccount": "123456789012"
},
"ArnEquals": {
"aws:SourceArn": "arn:aws:ssm:us-east-1:123456789012:*"
}
}
}
]
}
```
------
1. 관리 모드에서 PowerShell을 열고 JSON 파일을 생성한 디렉터리에서 [New-IAMRole](https://docs.aws.amazon.com//powershell/latest/reference/items/Register-IAMRolePolicy.html)을 실행해 다음과 같이 서비스 역할을 생성합니다. 이 예제에서는 `SSMServiceRole`라는 역할을 생성합니다. 원하는 경우 다른 이름을 선택할 수 있습니다.
```
New-IAMRole `
-RoleName SSMServiceRole `
-AssumeRolePolicyDocument (Get-Content -raw SSMService-Trust.json)
```
1. 다음과 같이 [Register-IAMRolePolicy](https://docs.aws.amazon.com/powershell/latest/reference/items/Register-IAMRolePolicy.html)를 사용하여, 생성한 서비스 역할이 세션 토큰을 생성할 수 있도록 허용합니다. 세션 토큰은 Systems Manager를 사용하여 명령을 실행할 수 있도록 관리형 노드 권한을 부여합니다.
**참고**
하이브리드 및 멀티클라우드 환경의 관리형 노드를 위한 서비스 프로파일을 위해 추가하는 정책은 EC2 인스턴스를 위한 인스턴스 프로파일을 생성하는 데 사용되는 정책과 동일합니다. 다음 명령에 사용되는 AWS 정책에 대한 자세한 내용은 [Systems Manager에 필요한 인스턴스 권한 구성](setup-instance-permissions.md)을 참조하세요.
(필수) 다음 명령을 실행하여 관리형 노드가 AWS Systems Manager 서비스 핵심 기능을 사용할 수 있게 허용합니다.
```
Register-IAMRolePolicy `
-RoleName SSMServiceRole `
-PolicyArn arn:aws:iam::aws:policy/AmazonSSMManagedInstanceCore
```
서비스 역할을 위한 사용자 정의 S3 버킷 정책을 생성한 경우 다음 명령을 실행하여 SSM Agent가 정책에서 지정한 버킷에 액세스할 수 있게 허용합니다. *account-id* 및 *my-bucket-policy-name*을 AWS 계정 ID 및 버킷 이름으로 바꿉니다.
```
Register-IAMRolePolicy `
-RoleName SSMServiceRole `
-PolicyArn arn:aws:iam::account-id:policy/my-bucket-policy-name
```
(선택) 다음 명령을 실행하여 SSM Agent가 관리형 노드의 도메인 조인 요청을 위해 사용자 대신 Directory Service에 액세스하도록 허용합니다. 노드를 Microsoft AD 디렉터리에 조인하는 경우에만 서버 역할에 이 정책이 필요합니다.
```
Register-IAMRolePolicy `
-RoleName SSMServiceRole `
-PolicyArn arn:aws:iam::aws:policy/AmazonSSMDirectoryServiceAccess
```
(선택) 다음 명령을 실행하여 CloudWatch 에이전트가 관리형 노드에서 실행되도록 허용합니다. 이 명령을 사용하면 노드에서 정보를 읽고 CloudWatch에 쓸 수 있습니다. Amazon EventBridge 또는 Amazon CloudWatch Logs 등의 서비스를 사용할 경우에만 서비스 프로파일에 이 정책이 필요합니다.
```
Register-IAMRolePolicy `
-RoleName SSMServiceRole `
-PolicyArn arn:aws:iam::aws:policy/CloudWatchAgentServerPolicy
```
------
계속해서 [하이브리드 활성화를 생성하여 Systems Manager에 노드 등록](hybrid-activation-managed-nodes.md)로 이동하세요.
# 하이브리드 활성화를 생성하여 Systems Manager에 노드 등록
Amazon Elastic Compute Cloud(EC2) 인스턴스 이외의 시스템을 [하이브리드 및 멀티클라우드](operating-systems-and-machine-types.md#supported-machine-types) 환경의 관리형 노드로 설정하려면 **하이브리드 정품 인증을 생성하여 적용합니다. 정품 인증을 완료하면 정품 인증 코드와 정품 인증 ID가 **즉시 콘솔 페이지 상단에 표시됩니다. 하이브리드 및 멀티클라우드 환경의 비 EC2 시스템에 AWS Systems Manager SSM Agent를 설치할 때 이 코드 및 ID 조합을 지정합니다. 코드 및 ID는 관리형 노드에서 Systems Manager 서비스에 대한 보안 액세스를 제공합니다.
**중요**
활성화를 생성한 방법에 따라, Systems Manager는 활성화 코드 및 ID를 콘솔이나 명령 창에 즉시 반환합니다. 이 정보를 복사하여 안전한 장소에 보관하십시오. 콘솔에서 벗어나거나 명령 창을 닫으면 이 정보가 손실될 수 있습니다. 이 정보가 손실하면 새로운 정품 인증을 생성해야 합니다.
**정품 인증 만료 정보**
*활성화 만료*란 온프레미스 시스템을 Systems Manager에 등록할 수 있는 기간을 말합니다. 활성화가 만료되어도 Systems Manager에 이전에 등록한 서버나 VM에는 영향을 주지 않습니다. 활성화가 만료되면 해당 정품 인증으로는 추가로 서버나 VM을 Systems Manager에 등록할 수 없게 됩니다. 새로 만들어야 합니다.
이전에 등록한 모든 온프레미스 서버와 VM은 명시적으로 등록 취소할 때까지 Systems Manager 관리형 노드로 여전히 등록됩니다. 다음과 같은 방법으로 비 EC2 관리형 노드의 등록을 취소할 수 있습니다.
+ Systems Manager 콘솔에서 Fleet Manager의 **관리형 노드** 탭 사용
+ AWS CLI 명령 [https://docs.aws.amazon.com/cli/latest/reference/ssm/deregister-managed-instance.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/deregister-managed-instance.html) 사용
+ API 작업 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_DeregisterManagedInstance.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_DeregisterManagedInstance.html) 사용.
자세한 내용은 다음 항목을 참조하세요.
+ [관리형 노드 등록 취소 및 다시 등록(Linux)](hybrid-multicloud-ssm-agent-install-linux.md#systems-manager-install-managed-linux-deregister-reregister)
+ [관리형 노드 등록 취소 및 다시 등록(Windows Server)](hybrid-multicloud-ssm-agent-install-windows.md#systems-manager-install-managed-win-deregister-reregister)
**관리형 노드 정보**
관리형 노드는 AWS Systems Manager의 대상으로 구성된 모든 관리형 노드입니다. AWS Systems Manager는 Amazon Elastic Compute Cloud(Amazon EC2) 인스턴스, 엣지 디바이스, 온프레미스 서버, 또는 다른 클라우드 환경의 VM을 포함한 가상 머신(VM)을 지원합니다. 이전에는 관리형 노드를 모두 관리형 인스턴스라고 했습니다. 이제 인스턴스라는 용어는 EC2 인스턴스만을 지칭합니다.** [deregister-managed-instance](https://docs.aws.amazon.com/cli/latest/reference/ssm/deregister-managed-instance.html) 명령은 이러한 용어 변경 이전에 이름이 붙여졌습니다.
**정품 인증 태그 정보**
AWS Command Line Interface(AWS CLI) 또는 AWS Tools for Windows PowerShell을 사용하여 활성화를 생성하는 경우 태그를 지정할 수 있습니다. 태그는 리소스에 할당하는 선택적 메타데이터입니다. 태그를 사용하면 용도, 소유자 또는 환경을 기준으로 하는 등 리소스를 다양한 방식으로 분류할 수 있습니다. 다음은 미국 동부(오하이오) 리전의 옵션 태그가 포함된 로컬 Linux 시스템에서 실행할 AWS CLI 샘플 명령입니다.
```
aws ssm create-activation \
--default-instance-name MyWebServers \
--description "Activation for Finance department webservers" \
--iam-role service-role/AmazonEC2RunCommandRoleForManagedInstances \
--registration-limit 10 \
--region us-east-2 \
--tags "Key=Department,Value=Finance"
```
정품 인증을 생성할 때 태그를 지정하면 해당 태그는 온프레미스 서버 및 VM 활성화 시 관리형 노드에 자동으로 할당됩니다.
기존 정품 인증에 태그를 추가하거나 기존 정품 인증에서 태그를 삭제할 수 없습니다. 정품 인증을 사용하여 온프레미스 서버 및 VM에 태그를 자동으로 할당하지 않으려면 나중에 온프레미스 서버 및 VM에 태그를 추가할 수 있습니다. 더 명확히 말하면, 온프레미스 서버 및 VM이 Systems Manager에 처음으로 연결된 후 온프레미스 서버 및 VM에 태그를 지정할 수 있습니다. 온프레미스 서버 및 VM은 연결된 후 관리형 노드 ID를 할당받고 ‘mi-’라는 접두사가 붙는 ID와 함께 Systems Manager 콘솔에 열거됩니다.
**참고**
Systems Manager 콘솔을 사용하여 활성화를 생성하는 경우 태그를 활성화에 할당할 수 없습니다. AWS CLI 또는 Tools for Windows PowerShell를 사용하여 생성해야 합니다.
더 이상 Systems Manager를 사용하여 온프레미스 서버 또는 가상 머신(VM)을 관리하지 않으려면 등록을 취소할 수 있습니다. 자세한 내용은 [하이브리드 및 멀티클라우드 환경의 관리형 노드 등록 취소](fleet-manager-deregister-hybrid-nodes.md) 섹션을 참조하세요.
**Topics**
+ [AWS Management Console을 사용하여 Systems Manager에 관리형 노드를 등록하기 위한 활성화 생성](#create-managed-node-activation-console)
+ [명령줄을 사용하여 Systems Manager에 관리형 노드를 등록하기 위한 활성화 생성](#create-managed-node-activation-command-line)
## AWS Management Console을 사용하여 Systems Manager에 관리형 노드를 등록하기 위한 활성화 생성
**관리형 노드 활성화를 생성하려면**
1. [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)에서 AWS Systems Manager 콘솔을 엽니다.
1. 탐색 창에서 **하이브리드 정품 인증**을 선택합니다.
1. **정품 인증 생성**을 선택합니다.
-또는-
현재 AWS 리전의 **하이브리드 정품 인증(Hybrid Activations)**에 처음으로 액세스하는 경우 **정품 인증 생성(Create an Activation)**을 선택합니다.
1. (선택 사항) **정품 인증 설명(Activation description)** 필드에 이 정품 인증에 대한 설명을 입력합니다. 많은 수의 서버 및 VM을 정품 인증하려는 경우 설명을 입력하는 것이 좋습니다.
1. **Instance limit**(인스턴스 한도)에서 AWS를 이 활성화의 일부로 사용하여 등록하려는 노드의 총 수를 지정합니다. 기본값은 인스턴스 1개입니다.
1. **IAM 역할(IAM role)**에서 서버와 VM이 클라우드에서 AWS Systems Manager와 통신할 수 있도록 하는 서비스 역할 옵션을 선택합니다.
+ **옵션 1**: **시스템에서 생성한 기본 역할 사용(Use the default role created by the system)**을 선택하여 AWS에서 제공하는 역할 및 관리형 정책을 사용합니다.
+ **옵션 2**: 앞에서 생성한 선택적 사용자 정의 역할을 사용하려면 **필요한 권한을 가진 기존 사용자 정의 IAM 역할 선택(Select an existing custom IAM role that has the required permissions)**을 선택합니다. 이 역할에는 `"Service": "ssm.amazonaws.com"`을 지정하는 신뢰 관계 정책이 있어야 합니다. IAM 역할이 신뢰 관계 정책에서 이 원칙을 지정하지 않으면 다음 오류가 발생합니다.
```
An error occurred (ValidationException) when calling the CreateActivation
operation: Not existing role: arn:aws:iam:::role/SSMRole
```
이 역할 생성에 관한 자세한 내용은 [하이브리드 및 멀티클라우드 환경에서 Systems Manager에 필요한 IAM 서비스 역할 생성](hybrid-multicloud-service-role.md) 섹션을 참조하세요.
1. **정품 인증 만료 날짜(Activation expiry date)**에서 정품 인증 만료 날짜를 지정합니다. 만료 날짜는 미래 날짜여야 하며 향후 30일 이내여야 합니다. 기본값은 24시간입니다.
**참고**
만료 날짜 이후에 추가 관리형 노드를 등록하려는 경우 새로운 활성화를 생성해야 합니다. 만료 날짜는 등록된 노드 및 실행 중인 노드에 영향을 미치지 않습니다.
1. (선택) **기본 인스턴스 이름** 필드에 이 활성화와 연관된 모든 관리형 노드에 대해 표시할 이름 값을 지정합니다.
1. **정품 인증 생성**을 선택합니다. Systems Manager는 즉시 활성화 코드와 ID를 콘솔에 반환합니다.
## 명령줄을 사용하여 Systems Manager에 관리형 노드를 등록하기 위한 활성화 생성
다음 절차에서는 AWS Command Line Interface(AWS CLI)(Linux 또는 Windows Server) 또는 AWS Tools for PowerShell을 사용하여 관리형 노드 활성화를 생성하는 방법을 설명합니다.
**정품 인증을 생성하려면**
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. 다음 명령을 실행하여 정품 인증을 생성합니다.
**참고**
다음 명령에서 *region*을 자신의 정보로 바꿉니다. 지원되는 *리전* 값 목록은 **Amazon Web Services 일반 참조의 [Systems Manager 서비스 엔드포인트](https://docs.aws.amazon.com/general/latest/gr/ssm.html#ssm_region)에 있는 **리전** 열을 참조하세요.
*iam-role* 파라미터에 대해 지정하는 역할에는 `"Service": "ssm.amazonaws.com"`을 지정하는 신뢰 관계 정책이 있어야 합니다. AWS Identity and Access Management(IAM) 역할이 신뢰 관계 정책에서 이 원칙을 지정하지 않으면 다음 오류가 발생합니다.
```
An error occurred (ValidationException) when calling the CreateActivation
operation: Not existing role: arn:aws:iam:::role/SSMRole
```
이 역할 생성에 관한 자세한 내용은 [하이브리드 및 멀티클라우드 환경에서 Systems Manager에 필요한 IAM 서비스 역할 생성](hybrid-multicloud-service-role.md) 섹션을 참조하세요.
`--expiration-date`의 경우 활성화 코드가 만료되는 날짜를 `"2021-07-07T00:00:00"`과 같은 타임스탬프 형식으로 제공합니다. 최대 30일 전에 날짜를 지정할 수 있습니다. 만료 날짜를 제공하지 않으면 활성화 코드는 24시간 후에 만료됩니다.
------
#### [ Linux & macOS ]
```
aws ssm create-activation \
--default-instance-name name \
--iam-role iam-service-role-name \
--registration-limit number-of-managed-instances \
--region region \
--expiration-date "timestamp" \\
--tags "Key=key-name-1,Value=key-value-1" "Key=key-name-2,Value=key-value-2"
```
------
#### [ Windows ]
```
aws ssm create-activation ^
--default-instance-name name ^
--iam-role iam-service-role-name ^
--registration-limit number-of-managed-instances ^
--region region ^
--expiration-date "timestamp" ^
--tags "Key=key-name-1,Value=key-value-1" "Key=key-name-2,Value=key-value-2"
```
------
#### [ PowerShell ]
```
New-SSMActivation -DefaultInstanceName name `
-IamRole iam-service-role-name `
-RegistrationLimit number-of-managed-instances `
–Region region `
-ExpirationDate "timestamp" `
-Tag @{"Key"="key-name-1";"Value"="key-value-1"},@{"Key"="key-name-2";"Value"="key-value-2"}
```
------
다음 예를 참고하세요
------
#### [ Linux & macOS ]
```
aws ssm create-activation \
--default-instance-name MyWebServers \
--iam-role service-role/AmazonEC2RunCommandRoleForManagedInstances \
--registration-limit 10 \
--region us-east-2 \
--expiration-date "2021-07-07T00:00:00" \
--tags "Key=Environment,Value=Production" "Key=Department,Value=Finance"
```
------
#### [ Windows ]
```
aws ssm create-activation ^
--default-instance-name MyWebServers ^
--iam-role service-role/AmazonEC2RunCommandRoleForManagedInstances ^
--registration-limit 10 ^
--region us-east-2 ^
--expiration-date "2021-07-07T00:00:00" ^
--tags "Key=Environment,Value=Production" "Key=Department,Value=Finance"
```
------
#### [ PowerShell ]
```
New-SSMActivation -DefaultInstanceName MyWebServers `
-IamRole service-role/AmazonEC2RunCommandRoleForManagedInstances `
-RegistrationLimit 10 `
–Region us-east-2 `
-ExpirationDate "2021-07-07T00:00:00" `
-Tag @{"Key"="Environment";"Value"="Production"},@{"Key"="Department";"Value"="Finance"}
```
------
정품 인증이 성공적으로 생성되면 시스템에서 정품 인증 코드 및 ID가 즉시 반환됩니다.
# 하이브리드 Linux 노드에 SSM Agent 설치
이 주제에서는 [하이브리드 및 멀티클라우드](operating-systems-and-machine-types.md#supported-machine-types) 환경의 비 EC2(Amazon Elastic Compute Cloud) Linux 시스템에 AWS Systems Manager SSM Agent를 설치하는 방법을 설명합니다. Linux용 EC2 인스턴스에 SSM Agent 설치에 대한 자세한 내용은 [Linux용 EC2 인스턴스에 수동으로 SSM Agent 설치 및 제거](manually-install-ssm-agent-linux.md) 섹션을 참조하세요.
시작하기 전에 [하이브리드 활성화를 생성하여 Systems Manager에 노드 등록](hybrid-activation-managed-nodes.md)에 설명된 대로 하이브리드 활성화 프로세스 중에 생성된 활성화 코드 및 활성화 ID를 찾습니다. 다음 절차에서 코드 및 ID를 지정합니다.
**하이브리드 및 멀티클라우드 환경의 비 EC2 시스템에 SSM Agent를 설치하는 방법**
1. 하이브리드 및 멀티클라우드 환경의 서버 또는 VM에 로그온합니다.
1. HTTP 또는 HTTPS 프록시를 사용하는 경우 현재 셸 세션에서 `http_proxy` 또는 `https_proxy` 환경 변수를 설정해야 합니다. 프록시를 사용하지 않는 경우 이 단계를 건너뛸 수 있습니다.
HTTP 프록시 서버의 경우 명령줄에 다음 명령을 입력합니다.
```
export http_proxy=http://hostname:port
export https_proxy=http://hostname:port
```
HTTPS 프록시 서버의 경우 명령줄에 다음 명령을 입력합니다.
```
export http_proxy=http://hostname:port
export https_proxy=https://hostname:port
```
1. 다음 명령 블록 중 하나를 복사하여 SSH에 붙여 넣습니다. 하이브리드 활성화 프로세스 중에 생성된 활성화 코드 및 활성화 ID와 SSM Agent를 다운로드하려는 AWS 리전의 식별자로 자리 표시자 값을 바꾸고 `Enter` 키를 누릅니다.
**중요**
다음과 같은 중요 세부 정보에 주의합니다.
비 EC2 설치에 `ssm-setup-cli`를 사용하면 Systems Manager 설치 및 구성의 보안이 극대화됩니다.
루트 사용자인 경우 `sudo`가 필요 없습니다.
하이브리드 활성화가 생성된 동일한 AWS 리전에서 `ssm-setup-cli`를 다운로드합니다.
`ssm-setup-cli`에서는 에이전트가 다운로드되는 소스를 결정하는 `manifest-url` 옵션을 지원합니다. 조직에서 요구하지 않는 한 이 옵션의 값을 지정하지 않습니다.
인스턴스를 등록할 때는 `ssm-setup-cli`에 대해 제공된 다운로드 링크만 사용합니다. `ssm-setup-cli`는 나중에 사용할 수 있도록 별도로 보관해서는 안 됩니다.
[여기](https://github.com/aws/amazon-ssm-agent/blob/mainline/Tools/src/setupcli_data_integrity_linux.sh)에 제공된 스크립트를 사용하여 `ssm-setup-cli` 서명을 검증할 수 있습니다.
*리전*은 미국 동부(오하이오) 리전의 `us-east-2` 같이 AWS Systems Manager이 지원하는 AWS 리전의 식별자를 나타냅니다. 지원되는 *리전* 값 목록은 **Amazon Web Services 일반 참조의 [Systems Manager 서비스 엔드포인트](https://docs.aws.amazon.com/general/latest/gr/ssm.html#ssm_region)에 있는 **리전** 열을 참조하세요.
또한 `ssm-setup-cli`에는 다음 옵션도 포함됩니다.
+ `version` - 유효 값은 `latest` 및 `stable`입니다.
+ `downgrade` - SSM Agent를 이전 버전으로 다운그레이드할 수 있습니다. 이전 버전의 에이전트를 설치하려면 `true`를 지정합니다.
+ `skip-signature-validation` - 에이전트 다운로드 및 설치 중에 서명 검증을 건너뜁니다.
## Amazon Linux 2, RHEL 7.x 및 Oracle Linux
```
mkdir /tmp/ssm
curl https://amazon-ssm-region.s3.region.amazonaws.com/latest/linux_amd64/ssm-setup-cli -o /tmp/ssm/ssm-setup-cli
sudo chmod +x /tmp/ssm/ssm-setup-cli
sudo /tmp/ssm/ssm-setup-cli -register -activation-code "activation-code" -activation-id "activation-id" -region "region"
```
## RHEL 8.x
```
mkdir /tmp/ssm
curl https://amazon-ssm-region.s3.region.amazonaws.com/latest/linux_amd64/ssm-setup-cli -o /tmp/ssm/ssm-setup-cli
sudo chmod +x /tmp/ssm/ssm-setup-cli
sudo /tmp/ssm/ssm-setup-cli -register -activation-code "activation-code" -activation-id "activation-id" -region "region"
```
## Debian Server
```
mkdir /tmp/ssm
curl https://amazon-ssm-region.s3.region.amazonaws.com/latest/debian_amd64/ssm-setup-cli -o /tmp/ssm/ssm-setup-cli
sudo chmod +x /tmp/ssm/ssm-setup-cli
sudo /tmp/ssm/ssm-setup-cli -register -activation-code "activation-code" -activation-id "activation-id" -region "region"
```
## Ubuntu Server
+ **.deb 패키지 사용**
```
mkdir /tmp/ssm
curl https://amazon-ssm-region.s3.region.amazonaws.com/latest/debian_amd64/ssm-setup-cli -o /tmp/ssm/ssm-setup-cli
sudo chmod +x /tmp/ssm/ssm-setup-cli
sudo /tmp/ssm/ssm-setup-cli -register -activation-code "activation-code" -activation-id "activation-id" -region "region"
```
+ **Snap 패키지 사용**
`snap` 명령은 [Snap 앱 스토어](https://snapcraft.io/amazon-ssm-agent)([https://snapcraft.io](https://snapcraft.io))에서 에이전트를 자동으로 다운로드하기 때문에 다운로드를 위해 URL을 지정할 필요는 없습니다.
Ubuntu Server 20.04, 18.04 및 16.04 LTS에서는 에이전트 바이너리 및 구성 파일을 포함한 SSM Agent 설치 관리자 파일이 `/snap/amazon-ssm-agent/current/` 디렉터리에 저장됩니다. 이 디렉터리의 구성 파일을 변경하는 경우 `/snap` 디렉터리에서 `/etc/amazon/ssm/` 디렉터리로 이러한 파일을 복사해야 합니다. 로그 및 라이브러리 파일이 변경되지 않았습니다(`/var/lib/amazon/ssm`, `/var/log/amazon/ssm`).
```
sudo snap install amazon-ssm-agent --classic
sudo systemctl stop snap.amazon-ssm-agent.amazon-ssm-agent.service
sudo /snap/amazon-ssm-agent/current/amazon-ssm-agent -register -code "activation-code" -id "activation-id" -region "region"
sudo systemctl start snap.amazon-ssm-agent.amazon-ssm-agent.service
```
**중요**
Snap Store의 *후보(candidate)* 채널에는 최신 버전의 SSM Agent가 있습니다. 안정적인 채널은 아닙니다. 후보 채널에서 SSM Agent 버전 정보를 추적하려면 Ubuntu Server 18.04 및 16.04 LTS 64비트 관리형 노드에서 다음 명령을 실행합니다.
```
sudo snap switch --channel=candidate amazon-ssm-agent
```
명령을 통해 하이브리드 및 멀티클라우드 환경의 하이브리드 정품 인증 시스템에 SSM Agent를 다운로드하고 설치합니다. 명령을 통해 SSM Agent를 중지한 다음에 시스템을 Systems Manager 서비스에 등록합니다. 이제 시스템이 관리형 노드입니다. Systems Manager에 대해 구성된 Amazon EC2 인스턴스도 관리형 노드입니다. 그러나 Systems Manager 콘솔에서는 하이브리드 정품 인증 노드는 접두사 "mi-"로 Amazon EC2 인스턴스와 구별됩니다.
계속해서 [하이브리드 Windows Server 노드에 SSM Agent 설치](hybrid-multicloud-ssm-agent-install-windows.md)로 이동하세요.
## 프라이빗 키 자동 교체 설정
보안 태세를 강화하기 위해 하이브리드 및 멀티클라우드 환경의 프라이빗 키를 자동으로 교체하도록 AWS Systems Manager 에이전트(SSM Agent)를 구성할 수 있습니다. SSM Agent 버전 3.0.1031.0 이상을 사용하여 이 기능에 액세스할 수 있습니다. 다음 절차에 따라 이 기능을 설정합니다.
**하이브리드 및 멀티클라우드 환경의 프라이빗 키를 교체하도록 SSM Agent를 구성하는 방법**
1. `/etc/amazon/ssm/`(Linux 시스템) 또는 `C:\Program Files\Amazon\SSM`(Windows 시스템)으로 이동합니다.
1. `amazon-ssm-agent.json.template`의 내용을 `amazon-ssm-agent.json`이라는 새 파일에 복사합니다. `amazon-ssm-agent.json.template`이 위치한 동일한 디렉터리에 `amazon-ssm-agent.json`을 저장합니다.
1. `Profile`, `KeyAutoRotateDays`를 찾습니다. 자동 프라이빗 키 교체 간격(일)을 입력합니다.
1. SSM Agent를 다시 시작합니다.
구성을 변경할 때마다 SSM Agent를 다시 시작합니다.
동일한 절차를 사용하여 SSM Agent의 다른 기능을 사용자 정의할 수 있습니다. 사용 가능한 구성 속성 및 기본값의 최신 목록은 [Config 속성 정의](https://github.com/aws/amazon-ssm-agent#config-property-definitions)를 참조하세요.
## 관리형 노드 등록 취소 및 다시 등록(Linux)
AWS CLI 또는 Tools for Windows PowerShell에서 [DeregisterManagedInstance](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_DeregisterManagedInstance.html) API 작업을 호출하여 하이브리드 정품 인증 관리형 노드 등록을 취소할 수 있습니다. 다음은 CLI 명령의 예입니다.
`aws ssm deregister-managed-instance --instance-id "mi-1234567890"`
에이전트의 나머지 등록 정보를 제거하려면 `amazon-ssm-agent.json` 파일에서 `IdentityConsumptionOrder` 키를 제거합니다. 이후 설치 유형에 따라 다음 명령 중 하나를 실행합니다.
Snap 패키지를 사용하여 SSM Agent가 설치된 Ubuntu Server 노드:
```
sudo /snap/amazon-ssm-agent/current/amazon-ssm-agent -register -clear
```
다른 모든 Linux 설치:
```
amazon-ssm-agent -register -clear
```
**참고**
지정된 활성화 코드 및 ID에 대한 인스턴스 제한에 도달하지 않았다면 동일한 활성화 코드 및 ID를 사용하여 온프레미스 서버, 엣지 디바이스 또는 VM을 다시 등록할 수 있습니다. AWS CLI를 사용하여 [describe-activations](https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-activations.html) API를 호출하면 활성화 코드 및 ID에 대한 인스턴스 제한을 확인할 수 있습니다. 명령을 실행한 후 `RegistrationCount`의 값이 `RegistrationLimit`를 초과하지 않는지 확인합니다. 이 경우 다른 활성화 코드와 ID를 사용해야 합니다.
**비 EC2 Linux 시스템의 관리형 노드를 다시 등록하는 방법**
1. 시스템에 연결합니다.
1. 다음 명령을 실행합니다. 자리표시자 값을 관리형 노드 활성화를 생성할 때 생성된 활성화 코드 및 활성화 ID와 SSM Agent를 다운로드하려는 리전의 식별자로 바꿔야 합니다.
```
echo "yes" | sudo /tmp/ssm/ssm-setup-cli -register -activation-code "activation-code" -activation-id "activation-id" -region "region
```
## 비 EC2 Linux 시스템의 SSM Agent 설치 문제 해결
다음 정보를 사용하면 [하이브리드 및 멀티클라우드](operating-systems-and-machine-types.md#supported-machine-types) 환경에서 하이브리드 정품 인증 Linux 시스템에 SSM Agent를 설치하는 문제를 해결하는 데 도움이 됩니다.
### DeliveryTimedOut 오류 발생
**문제**: 하나의 AWS 계정에 시스템을 별도의 AWS 계정에 대한 관리형 노드로 구성하는 동안 대상 시스템에 SSM Agent를 설치하는 명령을 실행한 후 `DeliveryTimedOut` 오류가 표시됩니다.
**해결 방법**: `DeliveryTimedOut`은 이 시나리오에 대한 예상 응답 코드입니다. 대상 노드에 SSM Agent를 설치하는 명령은 소스 노드의 노드 ID를 변경합니다. 노드 ID가 변경되었기 때문에 소스 노드는 명령 실행 중 실패, 완료 또는 시간 초과된 대상 노드에 응답할 수 없습니다.
### 노드 연결을 로드할 수 없음
**문제**: 설치 명령을 실행한 후 SSM Agent 오류 로그에 다음 오류가 표시됩니다.
`Unable to load instance associations, unable to retrieve associations unable to retrieve associations error occurred in RequestManagedInstanceRoleToken: MachineFingerprintDoesNotMatch: Fingerprint doesn't match`
재부팅 후 시스템 ID가 유지되지 않는 경우 이 오류가 표시됩니다.
**해결 방법**: 이 문제를 수정하려면 다음 명령을 실행합니다. 이 명령은 재부팅 후에도 시스템 ID가 유지되도록 합니다.
```
umount /etc/machine-id
systemd-machine-id-setup
```
# 하이브리드 Windows Server 노드에 SSM Agent 설치
이 주제에서는 [하이브리드 및 멀티클라우드](operating-systems-and-machine-types.md#supported-machine-types) 환경의 Windows Server 시스템에 AWS Systems Manager SSM Agent를 설치하는 방법을 설명합니다. Windows Server용 EC2 인스턴스에 SSM Agent 설치에 대한 자세한 내용은 [SSM Agent용 EC2 인스턴스에 수동으로 Windows Server 설치 및 제거](manually-install-ssm-agent-windows.md) 섹션을 참조하세요.
시작하기 전에 [하이브리드 활성화를 생성하여 Systems Manager에 노드 등록](hybrid-activation-managed-nodes.md)에 설명된 대로 하이브리드 활성화 프로세스 중에 생성된 활성화 코드 및 활성화 ID를 찾습니다. 다음 절차에서 코드 및 ID를 지정합니다.
**하이브리드 및 멀티클라우드 환경의 비 EC2 Windows Server 시스템에 SSM Agent를 설치하는 방법**
1. 하이브리드 및 멀티클라우드 환경의 서버 또는 VM에 로그온합니다.
1. HTTP 또는 HTTPS 프록시를 사용하는 경우 현재 셸 세션에서 `http_proxy` 또는 `https_proxy` 환경 변수를 설정해야 합니다. 프록시를 사용하지 않는 경우 이 단계를 건너뛸 수 있습니다.
HTTP 프록시 서버의 경우 다음 변수를 설정합니다.
```
http_proxy=http://hostname:port
https_proxy=http://hostname:port
```
HTTPS 프록시 서버의 경우 다음 변수를 설정합니다.
```
http_proxy=http://hostname:port
https_proxy=https://hostname:port
```
PowerShell의 경우 WinINet 프록시 설정을 구성합니다.
```
[System.Net.WebRequest]::DefaultWebProxy
$proxyServer = "http://hostname:port"
$proxyBypass = "169.254.169.254"
$WebProxy = New-Object System.Net.WebProxy($proxyServer,$true,$proxyBypass)
[System.Net.WebRequest]::DefaultWebProxy = $WebProxy
```
**참고**
PowerShell 작업에는 WinINet 프록시 구성이 필요합니다. 자세한 내용은 [SSM Agent 프록시 설정 및 Systems Manager 서비스](configure-proxy-ssm-agent-windows.md#ssm-agent-proxy-services) 섹션을 참조하세요.
1. 승격된(관리) 권한 모드에서 Windows PowerShell을 엽니다.
1. 다음 명령 블록을 복사하여 Windows PowerShell에 붙여 넣습니다. 각 *example resource placeholder*를 사용자의 정보로 바꿉니다. 예를 들면, 관리형 노드 정품 인증을 생성할 때 생성된 정품 인증 코드 및 정품 인증 ID와 SSM Agent를 다운로드하려는 AWS 리전의 식별자로 바꿔야 합니다.
**중요**
다음과 같은 중요 세부 정보에 주의합니다.
비 EC2 설치에 `ssm-setup-cli`를 사용하면 Systems Manager 설치 및 구성의 보안이 극대화됩니다.
`ssm-setup-cli`에서는 에이전트가 다운로드되는 소스를 결정하는 `manifest-url` 옵션을 지원합니다. 조직에서 요구하지 않는 한 이 옵션의 값을 지정하지 않습니다.
[여기](https://github.com/aws/amazon-ssm-agent/blob/mainline/Tools/src/setupcli_data_integrity_windows.ps1)에 제공된 스크립트를 사용하여 `ssm-setup-cli` 서명을 검증할 수 있습니다.
인스턴스를 등록할 때는 `ssm-setup-cli`에 대해 제공된 다운로드 링크만 사용합니다. `ssm-setup-cli`는 나중에 사용할 수 있도록 별도로 보관해서는 안 됩니다.
*리전*은 미국 동부(오하이오) 리전의 `us-east-2` 같이 AWS Systems Manager이 지원하는 AWS 리전의 식별자를 나타냅니다. 지원되는 *리전* 값 목록은 **Amazon Web Services 일반 참조의 [Systems Manager 서비스 엔드포인트](https://docs.aws.amazon.com/general/latest/gr/ssm.html#ssm_region)에 있는 **리전** 열을 참조하세요.
또한 `ssm-setup-cli`에는 다음 옵션도 포함됩니다.
+ `version`-유효 값은 `latest` 및 `stable`입니다.
+ `downgrade` - 에이전트를 이전 버전으로 되돌립니다.
+ `skip-signature-validation`-에이전트 다운로드 및 설치 중에 서명 검증을 건너뜁니다.
------
#### [ 64-bit ]
```
[System.Net.ServicePointManager]::SecurityProtocol = 'TLS12'
$code = "activation-code"
$id = "activation-id"
$region = "us-east-1"
$dir = $env:TEMP + "\ssm"
New-Item -ItemType directory -Path $dir -Force
cd $dir
(New-Object System.Net.WebClient).DownloadFile("https://amazon-ssm-$region.s3.$region.amazonaws.com/latest/windows_amd64/ssm-setup-cli.exe", $dir + "\ssm-setup-cli.exe")
./ssm-setup-cli.exe -register -activation-code="$code" -activation-id="$id" -region="$region"
Get-Content ($env:ProgramData + "\Amazon\SSM\InstanceData\registration")
Get-Service -Name "AmazonSSMAgent"
```
------
1. `Enter`을 누릅니다.
**참고**
명령이 실패할 경우 실행하는 AWS Tools for PowerShell이 최신 버전인지 확인합니다.
명령은 다음 작업을 수행합니다.
+ SSM Agent를 시스템에 다운로드하고 설치합니다.
+ Systems Manager 서비스에 시스템을 등록합니다.
+ 다음과 비슷한 응답을 요청에 반환합니다.
```
Directory: C:\Users\ADMINI~1\AppData\Local\Temp\2
Mode LastWriteTime Length Name
---- ------------- ------ ----
d----- 07/07/2018 8:07 PM ssm
{"ManagedInstanceID":"mi-008d36be46EXAMPLE","Region":"us-east-2"}
Status : Running
Name : AmazonSSMAgent
DisplayName : Amazon SSM Agent
```
이제 시스템이 *관리형 노드*입니다. 이러한 관리형 노드는 이제 접두사 ‘mi-’로 식별됩니다. AWS CLI 명령 [https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-instance-information.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-instance-information.html)을 사용하거나 API 명령 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_DescribeInstanceInformation.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_DescribeInstanceInformation.html)을 사용하여 Fleet Manager의 **관리형 노드** 페이지에서 관리형 노드를 볼 수 있습니다.
## 프라이빗 키 자동 교체 설정
보안 태세를 강화하기 위해 하이브리드 및 멀티클라우드 환경의 프라이빗 키를 자동으로 교체하도록 AWS Systems Manager 에이전트(SSM Agent)를 구성할 수 있습니다. SSM Agent 버전 3.0.1031.0 이상을 사용하여 이 기능에 액세스할 수 있습니다. 다음 절차에 따라 이 기능을 설정합니다.
**하이브리드 및 멀티클라우드 환경의 프라이빗 키를 교체하도록 SSM Agent를 구성하는 방법**
1. `/etc/amazon/ssm/`(Linux 시스템) 또는 `C:\Program Files\Amazon\SSM`(Windows Server 시스템)으로 이동합니다.
1. `amazon-ssm-agent.json.template`의 내용을 `amazon-ssm-agent.json`이라는 새 파일에 복사합니다. `amazon-ssm-agent.json.template`이 위치한 동일한 디렉터리에 `amazon-ssm-agent.json`을 저장합니다.
1. `Profile`, `KeyAutoRotateDays`를 찾습니다. 자동 프라이빗 키 교체 간격(일)을 입력합니다.
1. SSM Agent를 다시 시작합니다.
구성을 변경할 때마다 SSM Agent를 다시 시작합니다.
동일한 절차를 사용하여 SSM Agent의 다른 기능을 사용자 정의할 수 있습니다. 사용 가능한 구성 속성 및 기본값의 최신 목록은 [Config 속성 정의](https://github.com/aws/amazon-ssm-agent#config-property-definitions)를 참조하세요.
## 관리형 노드 등록 취소 및 다시 등록(Windows Server)
AWS CLI 또는 Tools for Windows PowerShell에서 [DeregisterManagedInstance](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_DeregisterManagedInstance.html) API 작업을 호출하여 관리형 노드를 등록 취소할 수 있습니다. 다음은 CLI 명령의 예입니다.
`aws ssm deregister-managed-instance --instance-id "mi-1234567890"`
에이전트의 나머지 등록 정보를 제거하려면 `amazon-ssm-agent.json` 파일에서 `IdentityConsumptionOrder` 키를 제거합니다. 그런 다음, 다음 명령을 실행합니다.
`amazon-ssm-agent -register -clear`
**참고**
지정된 활성화 코드 및 ID에 대한 인스턴스 제한에 도달하지 않았다면 동일한 활성화 코드 및 ID를 사용하여 온프레미스 서버, 엣지 디바이스 또는 VM을 다시 등록할 수 있습니다. AWS CLI를 사용하여 [describe-activations](https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-activations.html) API를 호출하면 활성화 코드 및 ID에 대한 인스턴스 제한을 확인할 수 있습니다. 명령을 실행한 후 `RegistrationCount`의 값이 `RegistrationLimit`를 초과하지 않는지 확인합니다. 이 경우 다른 활성화 코드와 ID를 사용해야 합니다.
**Windows Server 하이브리드 시스템에서 관리형 노드를 다시 등록하려면**
1. 시스템에 연결합니다.
1. 다음 명령을 실행합니다. 자리 표시자 값을 관리형 노드 활성화를 생성할 때 생성된 정품 인증 코드 및 정품 인증 ID와 SSM Agent를 다운로드하려는 리전의 식별자로 바꿔야 합니다.
```
$dir = $env:TEMP + "\ssm"
cd $dir
Start-Process ./ssm-setup-cli.exe -ArgumentList @(
"-register",
"-activation-code=$code",
"-activation-id=$id",
"-region=$region"
) -Wait -NoNewWindow
```