• 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 도구 사용에 대한 역할, 사용자 계정, 권한, 초기 리소스를 설정하고 구성합니다. 이 섹션에서 설명하는 작업은 일반적으로 AWS 계정 및 시스템 관리자가 수행합니다. 이러한 단계를 완료한 후에는 조직의 사용자가 Systems Manager를 사용하여 *관리형 노드*를 구성, 관리 및 액세스할 수 있습니다. 관리형 노드는 [하이브리드 및 멀티클라우드](operating-systems-and-machine-types.md#supported-machine-types) 환경에서 Systems Manager와 함께 사용하도록 구성된 모든 시스템입니다.
**참고**
[하이브리드 및 멀티클라우드](operating-systems-and-machine-types.md#supported-machine-types) 환경에서 Amazon EC2 인스턴스 **및 자체 컴퓨팅 리소스를 사용할 계획인 경우, [Systems Manager를 사용한 EC2 인스턴스 관리](systems-manager-setting-up-ec2.md)의 단계를 따릅니다. 이 주제에서는 EC2 인스턴스 및 비 EC2 시스템에 대한 Systems Manager 설정을 완료하는 단계를 최상의 순서로 설명합니다.
다른 AWS 서비스를 이미 사용하는 경우 이러한 단계 중 일부를 완료한 것입니다. 하지만 다른 단계는 Systems Manager에 특정합니다. 따라서 이 섹션 전체를 검토하여 모든 Systems Manager 도구를 사용할 준비가 되었는지 확인하는 것이 좋습니다.
**Topics**
+ [Systems Manager를 사용한 EC2 인스턴스 관리](systems-manager-setting-up-ec2.md)
+ [Systems Manager로 하이브리드 및 멀티클라우드 환경에서 노드 관리](systems-manager-hybrid-multicloud.md)
+ [Systems Manager를 통한 엣지 디바이스 관리](systems-manager-setting-up-edge-devices.md)
+ [Systems Manager에 대한 AWS Organizations 위임 관리자 생성](setting_up_delegated_admin.md)
+ [AWS Systems Manager에 대한 일반 설정](#setting_up_prerequisites)
# Systems Manager를 사용한 EC2 인스턴스 관리
이 섹션의 태스크를 수행하여 AWS Systems Manager에 대한 역할, 권한 및 초기 리소스를 설정하고 구성합니다. 이 섹션에서 설명하는 작업은 일반적으로 AWS 계정 및 시스템 관리자가 수행합니다. 이러한 단계를 완료한 후에는 조직의 사용자가 Systems Manager를 사용하여 자신의 계정에서 Amazon Elastic Compute Cloud(Amazon EC2) 인스턴스를 구성, 관리 및 액세스할 수 있습니다.
**참고**
Systems Manager를 사용하여 온프레미스 시스템을 관리하고 구성하려면 [Systems Manager로 하이브리드 및 멀티클라우드 환경에서 노드 관리](systems-manager-hybrid-multicloud.md)의 설정 단계를 따릅니다. [하이브리드 및 멀티클라우드](operating-systems-and-machine-types.md#supported-machine-types) 환경에서 Amazon EC2 인스턴스 **및 비 EC2 시스템을 모두 사용할 계획인 경우 먼저 여기의 단계를 따릅니다. 이 섹션에서는 Systems Manager 작업에서 사용할 역할, 사용자, 권한 및 초기 리소스를 구성하는 권장되는 순서의 단계를 제공합니다.
다른 AWS 서비스를 이미 사용하는 경우 이러한 단계 중 일부를 완료한 것입니다. 하지만 다른 단계는 Systems Manager에 특정합니다. 따라서 이 섹션 전체를 검토하여 모든 Systems Manager 도구를 사용할 준비가 되었는지 확인하는 것이 좋습니다.
**Topics**
+ [Systems Manager에 필요한 인스턴스 권한 구성](setup-instance-permissions.md)
+ [Systems Manager용 VPC 엔드포인트를 사용하여 EC2 인스턴스의 보안 개선](setup-create-vpc.md)
# Systems Manager에 필요한 인스턴스 권한 구성
AWS Systems Manager는 기본적으로 인스턴스에서 작업을 수행할 권한이 없습니다. AWS Identity and Access Management(IAM) 역할을 사용하여 계정 수준에서 또는 인스턴스 프로파일을 사용하여 인스턴스 수준에서 인스턴스 권한을 제공할 수 있습니다. 사용 사례에서 허용하는 경우 기본 호스트 관리 구성을 사용하여 계정 수준에서 액세스 권한을 부여하는 것이 좋습니다.
**참고**
이 단계를 건너뛰고 통합 콘솔을 설정하는 경우에는 Systems Manager가 인스턴스에 필요한 권한을 대신 적용하도록 허용할 수 있습니다. 자세한 내용은 [AWS Systems Manager 설정](systems-manager-setting-up-console.md) 섹션을 참조하세요.
## EC2 인스턴스 권한에 대한 권장 구성
기본 호스트 관리 구성을 통해 Systems Manager는 Amazon EC2 인스턴스를 자동으로 관리할 수 있습니다. 이 설정을 켜면 AWS 리전에서 인스턴스 메타데이터 서비스 버전 2(IMDSv2)를 사용하는 모든 인스턴스와 SSM Agent 버전 3.2.582.0 이상이 설치된 AWS 계정이 자동으로 관리형 인스턴스가 됩니다. 기본 호스트 관리 구성은 인스턴스 메타데이터 서비스 버전 1을 지원하지 않습니다. IMDSv2로 전환에 대한 자세한 내용은 *Amazon EC2 사용 설명서*의 [인스턴스 메타데이터 서비스 버전 2 사용으로 전환](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-metadata-transition-to-version-2.html)을 참조하세요. 인스턴스에 설치된 SSM Agent 버전 확인에 대한 자세한 내용은 [SSM Agent 버전 번호 확인](ssm-agent-get-version.md) 섹션을 참조하세요. SSM Agent 업데이트에 대한 자세한 내용은 [SSM Agent 자동 업데이트](ssm-agent-automatic-updates.md#ssm-agent-automatic-updates-console) 섹션을 참조하세요. 관리형 인스턴스의 이점은 다음과 같습니다.
+ Session Manager를 사용하여 안전하게 인스턴스에 연결합니다.
+ Patch Manager를 사용하여 자동 패치 스캔을 수행합니다.
+ Systems Manager Inventory를 사용하여 인스턴스에 대한 세부 정보를 봅니다.
+ Fleet Manager를 사용하여 인스턴스를 추적하고 관리합니다.
+ SSM Agent를 자동으로 최신 상태로 유지합니다.
Fleet Manager, Inventory, Patch Manager, Session Manager는 AWS Systems Manager의 도구입니다.
기본 호스트 관리 구성을 사용하면 인스턴스 프로파일을 사용하지 않고 인스턴스를 관리할 수 있으며 Systems Manager에 리전 및 계정의 모든 인스턴스를 관리할 수 있는 권한이 있는지 확인할 수 있습니다. 제공된 권한이 사용 사례에 충분하지 않은 경우 기본 호스트 관리 구성에서 생성된 기본 IAM 역할에 정책을 추가할 수도 있습니다. 또는 기본 IAM 역할에서 제공하는 모든 기능에 대한 권한이 필요하지 않은 경우 사용자 지정 역할과 정책을 직접 생성할 수 있습니다. 기본 호스트 관리 구성에 대해 선택한 IAM 역할의 모든 변경 사항은 리전 및 계정의 모든 관리형 Amazon EC2 인스턴스에 적용됩니다. 기본 호스트 관리 구성에서 사용하는 정책에 대한 자세한 내용은 [AWS 관리형 정책: AmazonSSMManagedEC2InstanceDefaultPolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-AmazonSSMManagedEC2InstanceDefaultPolicy) 섹션을 참조하세요. 기본 호스트 관리 구성에 대한 자세한 내용은 [기본 호스트 관리 구성을 사용한 자동 EC2 인스턴스 관리](fleet-manager-default-host-management-configuration.md) 섹션을 참조하세요.
**중요**
기본 호스트 관리 구성을 사용하여 등록된 인스턴스는 `/lib/amazon/ssm` 또는 `C:\ProgramData\Amazon` 디렉터리에 로컬로 등록 정보를 저장합니다. 이러한 디렉토리 또는 해당 파일을 제거하면 인스턴스가 기본 호스트 관리 구성을 사용하여 시스템 관리자에 연결하는 데 필요한 보안 인증을 획득하지 못하게 됩니다. 이러한 경우 인스턴스 프로파일을 사용하여 인스턴스에 필요한 권한을 제공하거나 인스턴스를 다시 생성해야 합니다.
**참고**
이 절차는 관리자만 수행할 수 있습니다. 개인이 기본 호스트 관리 구성을 구성하거나 수정할 수 있도록 허용할 때 최소 권한 액세스를 구현합니다. Amazon EC2 인스턴스를 자동으로 관리하려는 각 AWS 리전에서 기본 호스트 관리 구성을 켜야 합니다.
**기본 호스트 관리 구성 설정 켜기**
Fleet Manager 콘솔에서 기본 호스트 관리 구성을 켤 수 있습니다. AWS Management 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"
]
}
}
}
]
}
```
------
시작하기 전에 Amazon EC2 인스턴스에 연결된 인스턴스 프로파일이 있는 경우`ssm:UpdateInstanceInformation` 작업을 허용하는 모든 권한을 제거합니다. SSM Agent는 기본 호스트 관리 구성 권한을 사용하기 전에 인스턴스 프로파일 권한 사용을 시도합니다. 인스턴스 프로파일에서 `ssm:UpdateInstanceInformation` 작업을 허용하면 인스턴스가 기본 호스트 관리 구성 권한을 사용하지 않습니다.
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 도구를 활성화하는 데 사용되는 IAM 역할을 선택합니다. 기본 호스트 관리 구성에서 제공하는 기본 역할을 사용하는 것이 좋습니다. 여기에는 Systems Manager를 사용하여 Amazon EC2 인스턴스를 관리하는 데 필요한 최소 권한 세트가 포함되어 있습니다. 사용자 지정 역할을 사용하는 것을 선호하는 경우 역할의 신뢰 정책에서 Systems Manager를 신뢰할 수 있는 엔터티로 허용해야 합니다.
1. **구성**을 선택하여 설정을 완료합니다.
기본 호스트 관리 구성을 켠 후 인스턴스가 선택한 역할의 자격 증명을 사용하는 데 30분 정도 걸릴 수 있습니다. Amazon EC2 인스턴스를 자동으로 관리하려는 각 리전에서 기본 호스트 관리 구성을 켜야 합니다.
## EC2 인스턴스 권한에 대한 대체 구성
AWS Identity and Access Management(IAM) 인스턴스 프로파일을 사용하여 개별 인스턴스 수준에서 액세스 권한을 부여할 수 있습니다. 인스턴스 프로파일은 시작 시 Amazon Elastic Compute Cloud(Amazon EC2) 인스턴스에 IAM 역할 정보를 전달하는 컨테이너입니다. 새로운 역할이나 이미 생성된 역할에 필요한 권한을 정의하는 IAM 정책을 하나 이상 연결하여 Systems Manager에 대한 인스턴스 프로파일을 생성할 수 있습니다.
**참고**
AWS Systems Manager의 도구인 Quick Setup을 사용하여 AWS 계정의 모든 인스턴스에서 인스턴스 프로파일을 빠르게 구성할 수 있습니다. Quick Setup은 또한 Systems Manager가 사용자를 대신하여 인스턴스에서 명령을 안전하게 실행할 수 있도록 하는 IAM 서비스 역할이나 *수임* 역할을 생성할 수 있습니다. Quick Setup을 사용하여 이 단계(3단계)와 4단계를 건너뛸 수 있습니다. 자세한 내용은 [AWS Systems Manager Quick Setup](systems-manager-quick-setup.md) 섹션을 참조하세요.
IAM 인스턴스 프로파일 생성에 대한 다음 세부 정보를 참조하세요.
+ Systems Manager용 [하이브리드 및 멀티클라우드](operating-systems-and-machine-types.md#supported-machine-types) 환경에서 비 EC2 시스템을 구성하는 경우에는 인스턴스 프로파일을 생성할 필요가 없습니다. 그 대신에 IAM 서비스 역할을 사용할 서버와 VM을 구성합니다. 자세한 내용은 [하이브리드 및 멀티클라우드 환경에서 Systems Manager에 필요한 IAM 서비스 역할 생성](hybrid-multicloud-service-role.md)을 참조하세요.
+ IAM 인스턴스 프로파일을 변경한 경우에는 인스턴스 자격 증명이 갱신될 때까지 시간이 걸릴 수 있습니다. 갱신이 되어야 SSM Agent가 요청을 처리하기 시작합니다. SSM Agent 또는 인스턴스를 다시 시작하여 갱신 프로세스의 속도를 높일 수 있습니다.
인스턴스 프로파일의 역할을 새로 생성하려는 경우 또는 기존 역할에 필요한 권한을 추가하려는 경우에 각각 다음 절차 중 하나를 사용합니다.
**Systems Manager 관리형 인스턴스의 인스턴스 프로파일을 생성하려면(콘솔)**
1. [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)에서 IAM 콘솔을 엽니다.
1. 탐색 창에서 **역할(Roles)**을 선택한 후 **역할 생성(Create role)**을 선택합니다.
1. **신뢰할 수 있는 엔터티 유형**(Trusted entity type)에 **AWS 서비스**을 선택합니다.
1. **사용 사례(Use case)**에서 **EC2**를 선택한 후 **다음(Next)**을 선택합니다.
1. **권한 추가** 페이지에서 다음을 수행합니다.
+ **검색(Search)** 필드를 사용하여 **AmazonSSMManagedInstanceCore** 정책을 찾습니다. 다음 그림과 같이 이름 옆에 있는 확인란을 선택합니다.
![\[AmazonSSMManagedInstanceCore 행에서 확인란이 선택되어 있습니다.\]](http://docs.aws.amazon.com/ko_kr/systems-manager/latest/userguide/images/setup-instance-profile-2.png)
이 콘솔은 사용자가 다른 정책을 검색하더라도 사용자의 선택을 유지합니다.
+ 이전 절차에서 사용자 지정 S3 버킷 정책 [(선택 사항) S3 버킷 액세스에 대한 사용자 지정 정책 생성](#instance-profile-custom-s3-policy)를 생성한 경우 해당 이름을 검색하고 이름 옆의 확인란을 선택합니다.
+ Directory Service에 의해 관리되는 Active Directory에 인스턴스를 조인하려는 경우 **AmazonSSMDirectoryServiceAccess**를 검색하고 이름 옆의 확인란을 선택합니다.
+ 인스턴스를 관리하거나 모니터링하기 위해 EventBridge 또는 CloudWatch Logs를 사용하려는 경우 **CloudWatchAgentServerPolicy**를 검색하고 이름 옆의 확인란을 선택합니다.
1. **다음**을 선택합니다.
1. **역할 이름(Role name)**에 새 인스턴스 프로파일의 이름(예: **SSMInstanceProfile**)을 입력합니다.
**참고**
역할 이름을 기록해 둡니다. 이 역할은 Systems Manager를 사용하여 관리할 새 인스턴스를 생성할 때 선택합니다.
1. (선택) **설명(Description)**에 이 인스턴스 프로파일에 대한 설명을 입력합니다.
1. (선택) **태그(Tags)**에서 이 역할에 대한 액세스를 구성, 추적 또는 제어할 태그-키 값 페어를 하나 이상 추가한 후 **역할 생성(Create role)**을 선택합니다. 그러면 **역할** 페이지로 돌아갑니다.
**Systems Manager의 인스턴스 프로파일 권한을 기존 역할에 추가하려면(콘솔)**
1. IAM 콘솔([https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/))을 엽니다.
1. 탐색 창에서 **역할(Roles)**을 선택한 후, Systems Manager 작업을 위한 인스턴스 프로파일과 연결하려는 기존 역할을 선택합니다.
1. **권한(Permissions)** 탭에서 **권한 추가, 정책 연결(Add permissions, Attach policies)**을 선택합니다.
1. **정책 연결** 페이지에서 다음 작업을 수행합니다.
+ **검색(Search)** 필드를 사용하여 **AmazonSSMManagedInstanceCore** 정책을 찾습니다. 이름 옆의 확인란을 선택합니다.
+ 사용자 지정 S3 버킷 정책을 생성한 경우 검색하고 이름 옆의 확인란을 선택합니다. 인스턴스 프로파일의 사용자 지정 S3 버킷 정책에 대한 내용은 [(선택 사항) S3 버킷 액세스에 대한 사용자 지정 정책 생성](#instance-profile-custom-s3-policy)을 참조하세요.
+ Directory Service에 의해 관리되는 Active Directory에 인스턴스를 조인하려는 경우 **AmazonSSMDirectoryServiceAccess**를 검색하고 이름 옆의 확인란을 선택합니다.
+ 인스턴스를 관리하거나 모니터링하기 위해 EventBridge 또는 CloudWatch Logs를 사용하려는 경우 **CloudWatchAgentServerPolicy**를 검색하고 이름 옆의 확인란을 선택합니다.
1. **정책 연결**을 선택합니다.
역할을 업데이트하여 신뢰할 수 있는 엔터티를 포함하거나 액세스를 추가로 제한하는 방법에 대한 자세한 내용은 *IAM 사용 설명서*의 [역할 변경](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_manage_modify.html)을 참조하세요.
## (선택 사항) S3 버킷 액세스에 대한 사용자 지정 정책 생성
Amazon S3 액세스를 위한 사용자 정의 정책 생성은 Systems Manager 작업에서 VPC 종단점을 사용 중이거나 자체의 S3 버킷을 사용 중인 경우에만 필요합니다. 기본 호스트 관리 구성에서 생성한 기본 IAM 역할 또는 이전 절차에서 생성한 인스턴스 프로파일에 이 정책을 연결할 수 있습니다.
다음 정책에서 액세스 권한을 제공하는 AWS 관리형 S3 버킷에 대한 내용은 [AWS 관리형 S3 버킷과 SSM Agent 통신](ssm-agent-technical-details.md#ssm-agent-minimum-s3-permissions) 섹션을 참조하세요.
1. [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)에서 IAM 콘솔을 엽니다.
1. 탐색 창에서 **정책**을 선택한 후 **정책 생성**을 선택합니다.
1. **JSON** 탭을 선택하고 기본 텍스트를 다음과 같이 바꿉니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "s3:GetObject",
"Resource": [
"arn:aws:s3:::aws-ssm-us-east-2/*",
"arn:aws:s3:::aws-windows-downloads-us-east-2/*",
"arn:aws:s3:::amazon-ssm-us-east-2/*",
"arn:aws:s3:::amazon-ssm-packages-us-east-2/*",
"arn:aws:s3:::us-east-2-birdwatcher-prod/*",
"arn:aws:s3:::aws-ssm-distributor-file-us-east-2/*",
"arn:aws:s3:::aws-ssm-document-attachments-us-east-2/*",
"arn:aws:s3:::patch-baseline-snapshot-us-east-2/*"
]
},
{
"Effect": "Allow",
"Action": [
"s3:GetObject",
"s3:PutObject",
"s3:PutObjectAcl",
"s3:GetEncryptionConfiguration"
],
"Resource": [
"arn:aws:s3:::amzn-s3-demo-bucket/*",
"arn:aws:s3:::amzn-s3-demo-bucket"
]
}
]
}
```
------
**참고**
첫 번째 `Statement` 요소는 VPC 엔드포인트를 사용 중인 경우에만 필요합니다.
두 번째 `Statement` 요소는 Systems Manager 작업에서 사용하기 위해 생성한 S3 버킷을 사용 중인 경우에만 필요합니다.
`PutObjectAcl` 액세스 제어 목록 권한은 다른 계정에서 S3 버킷에 대한 교차 계정 액세스를 지원하려는 경우에만 필요합니다.
`GetEncryptionConfiguration` 요소는 암호화를 사용하기 위해 S3 버킷을 구성할 경우 필요합니다.
암호화를 사용하기 위해 S3 버킷을 구성할 경우 S3 버킷 루트(예: `arn:aws:s3:::amzn-s3-demo-bucket`)가 **리소스** 섹션에 있어야 합니다. 사용자, 그룹 또는 역할은 루트 버킷에 대한 액세스 권한을 사용하여 구성해야 합니다.
1. 작업에 VPC 엔드포인트를 사용 중인 경우 다음을 수행합니다.
첫 번째 `Statement` 요소에서, 각 *region* 자리 표시자를 이 정책이 사용되는 AWS 리전의 식별자로 대체합니다. 예를 들어 미국 동부(오하이오) 리전의 경우 `us-east-2`를 사용합니다. 지원되는 *리전* 값 목록은 **Amazon Web Services 일반 참조의 [Systems Manager 서비스 엔드포인트](https://docs.aws.amazon.com/general/latest/gr/ssm.html#ssm_region)에 있는 **리전** 열을 참조하세요.
**중요**
이 정책에서는 특정 리전 대신에 와일드카드 문자(\$1)를 사용하지 않는 것이 좋습니다. 예를 들어, `arn:aws:s3:::aws-ssm-*/*`는 사용하지 마시고 `arn:aws:s3:::aws-ssm-us-east-2/*`를 사용하세요. 와일드카드를 사용하면 액세스 권한을 부여하도록 의도하지 않은 S3 버킷에 액세스할 수 있습니다. 둘 이상의 리전에 대해 인스턴스 프로파일을 사용하려는 경우, 각 리전에 대해 첫 번째 `Statement` 요소를 반복하는 것이 좋습니다.
-또는-
작업에서 VPC 엔드포인트를 사용하고 있지 않다면, 첫 번째 `Statement` 요소를 삭제할 수 있습니다.
1. Systems Manager 작업에 자체의 S3 버킷을 사용 중인 경우 다음을 수행합니다.
두 번째 `Statement` 요소에서, *amzn-s3-demo-bucket*을 계정에 있는 S3 버킷의 이름으로 대체합니다. 이 버킷은 Systems Manager 작업을 위해 사용되며, 리소스로 `"arn:aws:s3:::my-bucket-name/*"`을 사용하여 버킷의 객체에 대한 권한을 제공합니다. 버킷 또는 버킷의 객체에 대한 권한 제공에 대한 자세한 내용은 *Amazon Simple Storage Service 개발자 안내서*의 [Amazon S3 작업](https://docs.aws.amazon.com/AmazonS3/latest/dev/using-with-s3-actions.html) 및 AWS 블로그 게시물 [IAM 정책, 버킷 정책 및 ACLs\$1를 참조하세요. ACL (S3 리소스에 대한 액세스 제어)](https://aws.amazon.com/blogs/security/iam-policies-and-bucket-policies-and-acls-oh-my-controlling-access-to-s3-resources/).
**참고**
둘 이상의 버킷을 사용하는 경우 각각에 대한 ARN을 제공합니다. 버킷에 대한 권한은 다음 예를 참조하세요.
```
"Resource": [
"arn:aws:s3:::amzn-s3-demo-bucket1/*",
"arn:aws:s3:::amzn-s3-demo-bucket2/*"
]
```
-또는-
Systems Manager 작업에서 자체의 S3 버킷을 사용하고 있지 않다면 두 번째 `Statement` 요소를 삭제할 수 있습니다.
1. **다음: 태그**를 선택합니다.
1. (선택 사항) **태그 추가(Add tag)**를 선택하고 정책에 대한 기본 설정 태그를 입력하여 태그를 추가합니다.
1. **다음: 검토**를 선택합니다.
1. **이름(Name)**에 이 정책을 식별할 수 있는 이름(예: **SSMInstanceProfileS3Policy**)을 입력합니다.
1. **정책 생성**을 선택합니다.
## 관리형 인스턴스에 대한 추가 정책 고려 사항
이 섹션에서는 기본 호스트 관리 구성에서 생성한 기본 IAM 역할 또는 AWS Systems Manager용 인스턴스 프로파일에 추가할 수 있는 몇 가지 정책에 대해 설명합니다. 인스턴스와 Systems Manager API 간 통신에 권한을 부여하려면 시스템 요구 사항과 보안 요구 사항을 반영하는 사용자 정의 정책을 만드는 것이 좋습니다. 운영 계획에 따라, 다른 정책 중 하나 이상에 제시된 권한이 필요할 수 있습니다.
**정책: `AmazonSSMDirectoryServiceAccess`**
Windows Server의 Amazon EC2 인스턴스를 Microsoft AD 디렉터리에 조인하려는 경우에만 필요합니다.
이 AWS 관리형 정책은 SSM Agent가 관리형 인스턴스의 도메인 조인 요청을 위해 사용자 대신 AWS Directory Service에 액세스하도록 허용합니다. 자세한 내용은 *AWS Directory Service 관리 안내서*의 [Windows EC2 인스턴스를 원활하게 조인](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/launching_instance.html)을 참조하세요.
**정책: `CloudWatchAgentServerPolicy`**
인스턴스에서 지표 및 로그 데이터를 읽고 Amazon CloudWatch에 쓰기 위해 인스턴스에서 CloudWatch 에이전트를 설치하고 실행하려는 경우에만 필요합니다. 이렇게 하면 AWS 리소스의 문제 및 변경을 모니터링, 분석하고 빠르게 대응할 수 있습니다.
기본 호스트 관리 구성 또는 인스턴스 프로파일에서 생성된 기본 IAM 역할에는 Amazon EventBridge 또는 Amazon CloudWatch Logs와 같은 기능을 사용하는 경우에만 이 정책이 필요합니다. (예를 들어 특정 CloudWatch Logs 로그 스트림에 대한 쓰기 액세스를 제어하는 더 제한적인 정책을 생성할 수도 있습니다.)
EventBridge 및 CloudWatch Logs 기능 사용은 선택 사항입니다. 그러나 사용하기로 한 경우에는 Systems Manager 구성 프로세스 시작 시 옵션을 설정하는 것이 좋습니다. 자세한 내용은 *[Amazon EventBridge User Guide](https://docs.aws.amazon.com/eventbridge/latest/userguide/)*와 *[Amazon CloudWatch Logs User Guide](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/)*를 참조하세요.
추가 Systems Manager 도구에 대한 권한이 있는 IAM 정책을 생성하려면 다음 리소스를 참조하세요.
+ [IAM 정책을 사용하여 Parameter Store 파라미터에 대한 액세스 제한](sysman-paramstore-access.md)
+ [Automation 설정](automation-setup.md)
+ [2단계: Session Manager의 인스턴스 권한 확인 또는 추가](session-manager-getting-started-instance-profile.md)
## 인스턴스에 Systems Manager 인스턴스 프로파일 연결(콘솔)
다음 절차에서는 Amazon EC2 콘솔을 사용하여 IAM 인스턴스 프로파일을 Amazon EC2 인스턴스에 연결하는 방법을 설명합니다.
1. AWS Management Console에 로그인하고 [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/)에서 Amazon EC2 콘솔을 엽니다.
1. 탐색 창의 **인스턴스**에서 **인스턴스**를 선택합니다.
1. 목록에서 EC2 인스턴스를 찾아서 선택합니다.
1. **작업(Actions)** 메뉴에서 **보안(Security)**, **IAM 역할 수정(Modify IAM role)**을 선택합니다.
1. **IAM 역할(IAM role)**에 [EC2 인스턴스 권한에 대한 대체 구성](#instance-profile-add-permissions)의 절차를 사용하여 생성한 인스턴스 프로파일을 선택합니다.
1. **IAM 역할 업데이트(Update **IAM role**)**를 선택합니다.
인스턴스에 IAM 역할 연결에 대한 자세한 내용은 선택한 운영 체제 유형에 따라 다음 중 하나를 참조하세요.
+ *Amazon EC2 사용 설명서*의 [인스턴스에 IAM 역할 연결](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-roles-for-amazon-ec2.html#attach-iam-role)
+ *Amazon EC2 사용 설명서*의 [인스턴스에 IAM 역할 연결](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/iam-roles-for-amazon-ec2.html#attach-iam-role)
계속해서 [Systems Manager용 VPC 엔드포인트를 사용하여 EC2 인스턴스의 보안 개선](setup-create-vpc.md)로 이동하세요.
# Systems Manager용 VPC 엔드포인트를 사용하여 EC2 인스턴스의 보안 개선
Amazon Virtual Private Cloud(VPC)에서 인터페이스 VPC 엔드포인트를 사용하도록 AWS Systems Manager를 구성하여 관리형 노드([하이브리드 및 멀티클라우드](operating-systems-and-machine-types.md#supported-machine-types) 환경의 비 EC2 시스템 포함)의 보안 태세를 개선할 수 있습니다. 인터페이스 VPC 엔드포인트(인터페이스 엔드포인트)를 사용하면 AWS PrivateLink에 의해 구동되는 서비스에 연결할 수 있습니다. AWS PrivateLink는 프라이빗 IP 주소를 사용하여 Amazon Elastic Compute Cloud(Amazon EC2) 및 Systems Manager API에 비공개로 액세스할 수 있는 기술입니다.
AWS PrivateLink는 관리형 인스턴스, Systems Manager 및 Amazon EC2 간의 모든 네트워크 트래픽을 Amazon 네트워크로 제한합니다. 즉, 관리형 인스턴스는 인터넷에 액세스할 수 없습니다. AWS PrivateLink를 사용하는 경우 인터넷 게이트웨이, NAT 디바이스 또는 가상 프라이빗 게이트웨이가 필요 없습니다.
AWS PrivateLink를 구성하는 것이 필수는 아니지만 구성하는 것이 좋습니다. AWS PrivateLink 및 VPC 엔드포인트에 대한 자세한 내용은 [AWS PrivateLink 및 VPC 엔드포인트](https://docs.aws.amazon.com/vpc/latest/userguide/endpoint-services-overview.html)를 참조하세요.
**참고**
VPC 엔드포인트 사용의 대체 방법은 관리형 인스턴스에서 아웃바운드 인터넷 액세스를 허용하는 것입니다. 이 경우 관리형 인스턴스는 다음 엔드포인트에 대한 HTTPS(포트 443) 아웃바운드 트래픽도 허용해야 합니다.
`ssm.region.amazonaws.com`
`ssmmessages.region.amazonaws.com`
`ec2messages.region.amazonaws.com`
SSM Agent는 클라우드의 Systems Manager 서비스에 대한 모든 연결을 시작합니다. 이러한 이유로 Systems Manager의 인스턴스에 대한 인바운드 트래픽을 허용하도록 방화벽을 구성할 필요가 없습니다.
이러한 엔드포인트 호출에 대한 자세한 내용은 [참조: ec2messages, ssmmessages 및 기타 API 작업](systems-manager-setting-up-messageAPIs.md) 섹션을 참조하세요.
IPv6*만* 지원하는 환경에서 Systems Manager를 사용하는 경우 다음 엔드포인트로의 아웃바운드 트래픽도 허용해야 합니다.
`ssm.region.api.aws`
`ssmmessages.region.api.aws`
`ec2messages.region.api.aws`
듀얼 스택 서비스 엔드포인트에 대한 자세한 내용은 *AWS 일반 참조 안내서*의 [듀얼 스택 엔드포인트](https://docs.aws.amazon.com/general/latest/gr/rande.html#dual-stack-endpoints)를 참조하세요.
또한 [참조: 패치 작업을 위한 Amazon S3 버킷](https://docs.aws.amazon.com/systems-manager/latest/userguide/patch-operations-s3-buckets.html)에 설명된 대로 노드에서 패치 작업 버킷에 연결할 수 있는지 확인해야 합니다.
**Amazon VPC 정보**
Amazon Virtual Private Cloud(Amazon VPC)를 사용하면 AWS 클라우드 내에서 논리적으로 격리된 자체 영역에 *Virtual Private Cloud(VPC)*라고 하는 가상 네트워크를 정의할 수 있습니다. 인스턴스와 같은 AWS 리소스를 VPC에서 시작할 수 있습니다. VPC는 고객의 자체 데이터 센터에서 운영하는 기존 네트워크와 매우 유사하지만 AWS의 확장 가능한 인프라를 사용한다는 이점을 제공합니다. 해당 IP 주소 범위를 선택하고, 서브넷을 만든 후 라우팅 테이블, 네트워크 게이트웨이 및 보안 설정을 구성하여 VPC를 구성할 수 있습니다. VPC의 인스턴스를 인터넷에 연결합니다. VPC를 사내 데이터 센터에 연결하여 AWS 클라우드에서 데이터 센터를 확장할 수 있습니다. 각의 서브넷에서 리소스를 보호하기 위해 보안 그룹 및 네트워크 액세스 제어 목록을 포함한 다중 보안 계층을 사용할 수 있습니다. 자세한 내용은 [Amazon VPC 사용 설명서](https://docs.aws.amazon.com/vpc/latest/userguide/)를 참조하세요.
**Topics**
+ [VPC 엔드포인트 제약 및 제한](#vpc-requirements-and-limitations)
+ [Systems Manager용 VPC 엔드포인트 생성](#create-vpc-endpoints)
+ [인터페이스 VPC 엔드포인트 정책 생성](#create-vpc-interface-endpoint-policies)
## VPC 엔드포인트 제약 및 제한
Systems Manager에 대해 VPC 엔드포인트를 구성하기 전에 다음 제한 사항에 유의합니다.
**VPC 피어링 연결**
VPC 인터페이스 엔드포인트는 *리전 내* 및 *리전 간* VPC 피어링 연결을 통해 액세스할 수 있습니다. VPC 인터페이스 엔드포인트에 대한 VPC 피어링 연결 요청에 대한 자세한 내용은 *Amazon Virtual Private Cloud 사용 설명서*의 [VPC 피어링 연결(할당량)](https://docs.aws.amazon.com/vpc/latest/userguide/amazon-vpc-limits.html#vpc-limits-peering)을 참조하세요.
VPC 게이트웨이 엔드포인트 연결은 VPC 외부로 확장할 수 없습니다. VPC의 VPC 피어링 연결의 반대편에 있는 리소스는 게이트웨이 엔드포인트를 사용하여 게이트웨이 엔드포인트 서비스의 리소스와 통신할 수 없습니다. VPC 게이트웨이 엔드포인트에 대한 VPC 피어링 연결 요청에 대한 자세한 내용은 *Amazon Virtual Private Cloud 사용 설명서*의 [VPC 엔드포인트(할당량)](https://docs.aws.amazon.com/vpc/latest/userguide/amazon-vpc-limits.html#vpc-limits-endpoints)를 참조하세요.
**수신 연결**
VPC 종단점에 연결된 보안 그룹은 관리형 인스턴스의 프라이빗 서브넷에서 443 포트로 들어오는 연결을 허용해야 합니다. 수신 연결을 허용하지 않으면 관리형 인스턴스가 SSM 및 EC2 엔드포인트에 연결할 수 없습니다.
**DNS 확인**
사용자 지정 DNS 서버를 사용하는 경우 `amazonaws.com` 도메인에 대한 모든 쿼리의 조건부 전달자를 VPC의 Amazon DNS 서버에 추가해야 합니다.
**S3 버킷**
VPC 엔드포인트 정책이 최소한 [AWS 관리형 S3 버킷과 SSM Agent 통신](ssm-agent-technical-details.md#ssm-agent-minimum-s3-permissions)에 열거된 Amazon S3 버킷에 대해 액세스를 허용해야 합니다.
**참고**
온프레미스 방화벽을 사용하고 Patch Manager를 사용하려는 경우 해당 방화벽에서 적절한 패치 기준 엔드포인트에 대한 액세스도 허용해야 합니다.
**Amazon CloudWatch Logs**
인스턴스가 인터넷에 액세스하는 것을 허용하지 않는 경우 CloudWatch Logs에 로그를 보내는 기능을 사용하도록 CloudWatch Logs에 대한 VPC 엔드포인트를 생성합니다. CloudWatch Logs용 엔드포인트 생성에 대한 자세한 내용은 *Amazon CloudWatch Logs User Guide*의 [Creating a VPC endpoint for CloudWatch Logs](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/cloudwatch-logs-and-interface-VPC.html#create-VPC-endpoint-for-CloudWatchLogs)를 참조하세요.
**하이브리드 및 멀티클라우드 환경의 DNS**
[하이브리드 및 멀티클라우드](operating-systems-and-machine-types.md#supported-machine-types) 환경에서 AWS PrivateLink 엔드포인트로 작업하도록 DNS를 구성하는 방법에 대한 자세한 내용은 **Amazon VPC 사용 설명서의 [인터페이스 엔드포인트의 프라이빗 DNS](https://docs.aws.amazon.com/vpc/latest/privatelink/vpce-interface.html#vpce-private-dns)를 참조하세요. 자신의 DNS를 사용하는 경우에는 Route 53 해석기를 사용할 수 있습니다. 자세한 내용은 *Amazon Route 53 개발자 안내서*의 [VPC와 네트워크 간 DNS 쿼리 해석](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver.html)을 참조하세요.
## Systems Manager용 VPC 엔드포인트 생성
다음 정보를 사용하여 AWS Systems Manager에 대한 VPC 인터페이스 엔드포인트를 생성합니다. 이 주제는 *Amazon VPC 사용 설명서*의 절차에 연결됩니다.
**참고**
*리전*은 미국 동부(오하이오) 리전의 `us-east-2` 같이 AWS Systems Manager이 지원하는 AWS 리전의 식별자를 나타냅니다. 지원되는 *리전* 값 목록은 **Amazon Web Services 일반 참조의 [Systems Manager 서비스 엔드포인트](https://docs.aws.amazon.com/general/latest/gr/ssm.html#ssm_region)에 있는 **리전** 열을 참조하세요.
[인터페이스 엔드포인트 생성](https://docs.aws.amazon.com/vpc/latest/privatelink/vpce-interface.html#create-interface-endpoint)의 단계에 따라 다음 인터페이스 엔드포인트를 생성합니다.
+ **`com.amazonaws.region.ssm`**: Systems Manager 서비스의 엔드포인트입니다.
+ **`com.amazonaws.region.ec2messages`**: Systems Manager는 이 엔드포인트를 사용하여 SSM Agent에서 Systems Manager 서비스를 호출합니다. SSM Agent 버전 3.3.40.0부터 Systems Manager는 가능한 경우 `ec2messages:*` 엔드포인트(Amazon Message Delivery Service) 대신 `ssmmessages:*` 엔드포인트(Amazon Message Gateway Service)를 사용하기 시작했습니다.
+ **`com.amazonaws.region.ec2`**: Systems Manager를 사용하여 VSS 지원 스냅샷을 만든 경우 EC2 서비스에 대한 엔드포인트가 있어야 합니다. EC2 엔드포인트가 정의되어 있지 않으면 연결된 Amazon EBS 볼륨을 표시하는 호출이 실패하고 이에 따라 Systems Manager 명령에 실패합니다.
+ **`com.amazonaws.region.s3`** - Systems Manager는 이 엔드포인트를 사용하여 SSM Agent를 업데이트합니다. Systems Manager는 선택적으로 버킷에 저장된 스크립트나 기타 파일을 검색하거나 출력 로그를 버킷에 업로드하도록 선택하는 경우에도 이 엔드포인트를 사용합니다. 인스턴스와 연결된 보안 그룹이 아웃바운드 트래픽을 제한하는 경우 Amazon S3의 접두사 목록에 대한 트래픽을 허용하는 규칙을 추가해야 합니다. 자세한 내용은 *AWS PrivateLink Guide*의 [Modify your security group](https://docs.aws.amazon.com/vpc/latest/privatelink/vpce-gateway.html#vpc-endpoints-security)을 참조하세요.
+ **`com.amazonaws.region.ssmmessages`** – 이 엔드포인트는 SSM Agent가 Systems Manager 서비스와 통신하기 위해, Run Command를 위해, 그리고 Session Manager를 사용하여 보안 데이터 채널을 통해 인스턴스에 연결하는 경우 필요합니다. 자세한 내용은 [AWS Systems Manager Session Manager](session-manager.md) 및 [참조: ec2messages, ssmmessages 및 기타 API 작업](systems-manager-setting-up-messageAPIs.md)(을)를 참조하세요.
+ (선택 사항) **`com.amazonaws.region.kms`** - Session Manager 또는 Parameter Store 파라미터에 AWS Key Management Service(AWS KMS) 암호화를 사용하려는 경우 이 엔드포인트를 생성합니다.
+ (선택 사항) **`com.amazonaws.region.logs`** - Session Manager, Run Command 또는 SSM Agent 로그를 위해 Amazon CloudWatch Logs(CloudWatch Logs)를 사용하려는 경우 이 엔드포인트를 만드세요.
SSM Agent가 액세스할 수 있어야 하는 AWS 관리형 S3 버킷에 대한 자세한 내용은 [AWS 관리형 S3 버킷과 SSM Agent 통신](ssm-agent-technical-details.md#ssm-agent-minimum-s3-permissions) 섹션을 참조하세요. Systems Manager 작업에서 Virtual Private Cloud(VPC) 엔드포인트를 사용하는 경우 Systems Manager를 위한 Amazon EC2 인스턴스 프로파일 또는 [하이브리드 및 멀티클라우드](operating-systems-and-machine-types.md#supported-machine-types) 환경의 비 EC2 관리형 노드를 위한 서비스 역할에 명시적 권한을 제공해야 합니다.
## 인터페이스 VPC 엔드포인트 정책 생성
AWS Systems Manager에 대한 VPC 인터페이스 엔드포인트의 정책을 생성할 수 있습니다. 이 정책에서 다음을 지정할 수 있습니다.
+ 작업을 수행할 수 있는 보안 주체.
+ 수행할 수 있는 작업
+ 수행되는 작업을 가질 수 있는 리소스
자세한 내용은 *Amazon VPC 사용 설명서*의 [VPC 엔드포인트를 통해 서비스에 대한 액세스 제어](https://docs.aws.amazon.com/vpc/latest/privatelink/vpc-endpoints-access.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
```
# Systems Manager를 통한 엣지 디바이스 관리
이 섹션에서는 계정 및 시스템 관리자가 AWS IoT Greengrass 코어 디바이스의 구성 및 관리를 활성화하기 위해 수행하는 설정 작업을 설명합니다. 이러한 태스크를 수행한 후, AWS 계정 관리자에게 권한을 부여받은 관리자는 AWS Systems Manager를 사용해 조직의 AWS IoT Greengrass 코어 디바이스를 구성하고 관리할 수 있습니다.
**참고**
AWS IoT Greengrass용 SSM Agent는 macOS 및 Windows 10에서 지원되지 않습니다. Systems Manager 도구를 사용하여 이러한 운영 체제를 사용하는 엣지 디바이스를 관리하고 구성할 수 없습니다.
Systems Manager는 AWS IoT Greengrass 코어 디바이스로 구성되지 않은 엣지 디바이스도 지원합니다. Systems Manager를 사용하여 AWS IoT 코어 디바이스 및 비 AWS 엣지 디바이스를 관리하려면 하이브리드 정품 인증을 사용하여 구성해야 합니다. 자세한 내용은 [Systems Manager로 하이브리드 및 멀티클라우드 환경에서 노드 관리](systems-manager-hybrid-multicloud.md) 섹션을 참조하세요.
엣지 디바이스에서 Session Manager 및 Microsoft 애플리케이션 패치를 사용하려면 고급 인스턴스 티어를 사용해야 합니다. 자세한 내용은 [고급 인스턴스 티어 설정](fleet-manager-enable-advanced-instances-tier.md) 섹션을 참조하세요.
**시작하기 전 준비 사항**
엣지 디바이스가 다음 요구 사항을 충족하는지 확인합니다.
+ AWS IoT Greengrass 코어 디바이스로 구성되려면, 엣지 디바이스는 요구 사항을 충족해야 합니다. 자세한 내용은 *AWS IoT Greengrass Version 2 개발자 안내서*의 [AWS IoT Greengrass 코어 디바이스 설정](https://docs.aws.amazon.com/greengrass/v2/developerguide/setting-up.html) 섹션을 참조하세요.
+ 엣지 디바이스는 AWS Systems Manager 에이전트(SSM Agent)와 호환되어야 합니다. 자세한 내용은 [Systems Manager가 지원되는 운영 체제](operating-systems-and-machine-types.md#prereqs-operating-systems) 섹션을 참조하세요.
+ 엣지 디바이스는 클라우드의 Systems Manager 서비스와 통신할 수 있어야 합니다. Systems Manager는 연결이 끊긴 엣지 디바이스를 지원하지 않습니다.
**엣지 디바이스 설정 정보**
Systems Manager용 AWS IoT Greengrass 디바이스 설정에는 다음 프로세스가 포함됩니다.
**참고**
엣지 디바이스에서의 SSM Agent 제거에 대한 자세한 내용은 *AWS IoT Greengrass Version 2개발자 안내서*의 [AWS Systems Manager 에이전트 제거](https://docs.aws.amazon.com/greengrass/v2/developerguide/uninstall-systems-manager-agent.html)를 참조하세요.
## 엣지 디바이스에 대한 IAM 서비스 역할 생성
AWS IoT Greengrass 코어 디바이스는 AWS Identity and Access Management(IAM) 서비스 역할을 사용하여 AWS Systems Manager과 통신합니다. 역할이 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 계정에 대해 한 번만 서비스 역할을 생성하면 됩니다. AWS IoT Greengrass 디바이스에 SSM Agent 구성 요소를 구성하고 배포할 때 `RegistrationRole` 파라미터를 위한 이 역할을 지정하게 됩니다. [하이브리드 및 멀티클라우드](operating-systems-and-machine-types.md#supported-machine-types) 환경의 비 EC2 노드를 설정하면서 이 역할을 이미 생성했다면 이 단계를 건너뛸 수 있습니다.
**참고**
엣지 디바이스를 기반으로 Systems Manager를 사용할 회사 또는 조직의 사용자에게는 IAM에서 Systems Manager API를 호출할 수 있는 권한이 주어져야 합니다.
**S3 버킷 정책 요구 사항**
다음 사례 중 하나에 해당되는 경우 이 절차를 완료하기 전에 Amazon Simple Storage Service(Amazon S3) 버킷에 대한 사용자 정의 IAM 권한 정책을 생성해야 합니다.
+ **사례 1**: VPC 엔드포인트를 사용하여 VPC를 지원되는 AWS 서비스 및 AWS PrivateLink에 의해 제공되는 VPC 엔드포인트 서비스에 비공개로 연결하고 있습니다.
+ **사례 2**: S3 버킷에 대한 Run Command 명령 또는 Session Manager 세션의 출력을 저장하기 위한 작업 등 Systems Manager 작업의 일부로 생성되는 S3 버킷을 사용할 계획입니다. 진행하기 전에 [인스턴스 프로파일에 대한 사용자 정의 S3 버킷 정책 생성](setup-instance-permissions.md#instance-profile-custom-s3-policy)의 단계를 수행합니다. 해당 주제의 S3 버킷 정책에 대한 정보 또한 서비스 역할에 적용됩니다.
**참고**
디바이스가 방화벽으로 보호되고 Patch Manager를 사용할 계획인 경우, 방화벽은 패치 기준 엔드포인트 `arn:aws:s3:::patch-baseline-snapshot-region/*`에 액세스를 허용해야 합니다.
*리전*은 미국 동부(오하이오) 리전의 `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 CLI ]
**AWS IoT Greengrass 환경(AWS CLI)을 위한 IAM 서비스 역할 생성**
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` 파일 확장명으로 저장해야 합니다.
**참고**
이름을 기록해 둡니다. AWS IoT Greengrass 코어 디바이스에 SSM Agent를 배포할 때 이를 지정하게 됩니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": {
"Effect": "Allow",
"Principal": {
"Service": "ssm.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
}
```
------
1. AWS CLI를 열고, JSON 파일을 생성한 디렉터리에서 [create-role](https://docs.aws.amazon.com/cli/latest/reference/iam/create-role.html) 명령을 사용하여 서비스 역할을 생성합니다. 각 *example resource placeholder*를 사용자의 정보로 바꿉니다.
**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) 인스턴스를 위한 인스턴스 프로파일을 생성하는 데 사용되는 정책과 동일합니다. 다음 명령에 사용되는 IAM 정책에 대한 자세한 내용은 [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* 및 *my-bucket-policy-name*을 AWS 계정 ID 및 버킷 이름으로 바꿉니다.
**Linux & macOS**
```
aws iam attach-role-policy \
--role-name SSMServiceRole \
--policy-arn arn:aws:iam::account_ID:policy/my_bucket_policy_name
```
**Windows**
```
aws iam attach-role-policy ^
--role-name SSMServiceRole ^
--policy-arn arn:aws:iam::account_id:policy/my_bucket_policy_name
```
(선택) 다음 명령을 실행하여 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 ]
**AWS IoT Greengrass 환경(AWS Tools for Windows PowerShell)을 위한 IAM 서비스 역할 생성**
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` 파일 확장명으로 저장해야 합니다.
**참고**
이름을 기록해 둡니다. AWS IoT Greengrass 코어 디바이스에 SSM Agent를 배포할 때 이를 지정하게 됩니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": {
"Effect": "Allow",
"Principal": {
"Service": "ssm.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
}
```
------
1. 관리 모드에서 PowerShell을 열고 JSON 파일을 생성한 디렉터리에서 [New-IAMRole](https://docs.aws.amazon.com//powershell/latest/reference/items/Register-IAMRolePolicy.html)을 실행해 다음과 같이 서비스 역할을 생성합니다.
```
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를 사용하여 명령을 실행할 수 있도록 엣지 디바이스 권한을 부여합니다.
**참고**
AWS IoT Greengrass 환경의 엣지 디바이스를 위한 서비스 역할을 위해 추가하는 정책은 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
```
------
## AWS IoT Greengrass를 위한 엣지 디바이스를 구성
엣지 디바이스를 AWS IoT Greengrass 코어 디바이스로 설정합니다. 설치 프로세스에는 디바이스에 AWS IoT Greengrass 코어 소프트웨어를 설치하고 구성하는 것뿐만 아니라 지원되는 운영 체제 및 시스템 요구 사항을 확인하는 일이 포함됩니다. 자세한 내용은 [AWS IoT Greengrass 개발자 안내서](https://docs.aws.amazon.com/greengrass/v2/developerguide/setting-up.html)의 *AWS IoT Greengrass Version 2 코어 디바이스 설정* 섹션을 참조하세요.
## AWS IoT Greengrass 토큰 교환 역할 업데이트 및 엣지 디바이스에 SSM Agent 설치
Systems Manager용 AWS IoT Greengrass 코어 디바이스 설정 및 구성을 위한 마지막 단계에서는 *토큰 교환 역할*이라고도 부르는 AWS IoT Greengrass AWS Identity and Access Management(IAM) 디바이스 서비스 역할을 업데이트해야 하며 AWS IoT Greengrass 디바이스에 AWS Systems Manager 에이전트(SSM Agent)를 배포해야 합니다. **이러한 프로세스에 대한 자세한 내용은 AWS IoT Greengrass Version 2 개발자 안내서의 [AWS Systems Manager 에이전트 설치](https://docs.aws.amazon.com/greengrass/v2/developerguide/install-systems-manager-agent.html)를 참조하세요.
디바이스에 SSM Agent를 배포하고 나면, AWS IoT Greengrass가 자동으로 Systems Manager에 디바이스를 등록합니다. 추가 등록은 필요하지 않습니다. Systems Manager 도구를 사용하여 AWS IoT Greengrass 디바이스의 액세스, 관리 및 구성 작업을 시작할 수 있습니다.
**참고**
엣지 디바이스는 클라우드의 Systems Manager 서비스와 통신할 수 있어야 합니다. Systems Manager는 연결이 끊긴 엣지 디바이스를 지원하지 않습니다.
# Systems Manager에 대한 AWS Organizations 위임 관리자 생성
**Change Manager 가용성 변경**
AWS Systems Manager Change Manager는 2025년 11월 7일부터 신규 고객에게 더 이상 공개되지 않습니다. Change Manager를 사용하려면 해당 날짜 이전에 가입하세요. 기존 고객은 정상적으로 서비스를 계속 이용할 수 있습니다. 자세한 내용은 [AWS Systems Manager Change Manager 가용성 변경](https://docs.aws.amazon.com/systems-manager/latest/userguide/change-manager-availability-change.html)을 참조하세요.
AWS Organizations에서 조직을 설정할 때 모든 AWS 서비스의 모든 관리 작업을 수행하는 관리 계정을 할당합니다. 관리 계정 사용자는 Systems Manager에서 Change Manager, Explorer 및 OpsCenter의 관리 작업을 수행할 수 있는 **위임된 관리자 계정만 할당할 수 있습니다. AWS Organizations는 조직을 생성하고 이러한 계정을 중앙에서 관리하는 AWS 계정를 할당하는 데 사용할 수 있는 계정 관리 서비스입니다. AWS Organizations에 대한 자세한 내용은 *AWS Organizations 사용 설명서*의 [AWS Organizations](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_introduction.html) 섹션을 참조하세요.
AWS Systems Manager의 도구인 Change Manager, Explorer 및 OpsCenter에서는 AWS Organizations을 사용하여 조직의 모든 멤버 계정에 대한 태스크를 수행합니다. 모든 Systems Manager 도구의 위임된 관리자를 한 사람만 할당할 수 있습니다. 위임된 관리자 계정은 해당 계정이 할당된 조직의 멤버여야 합니다.
**Topics**
+ [Change Manager에 위임된 관리자 사용](#setting_up_delegated_administrator_change_manager)
+ [Explorer에 위임된 관리자 사용](#setting_up_delegated_administrator_explorer)
+ [OpsCenter에 위임된 관리자 사용](#setting_up_delegated_administrator_opscenter)
+ [Quick Setup에 위임된 관리자 사용](#setting_up_delegated_administrator_quick_setup)
## Change Manager에 위임된 관리자 사용
Change Manager는 애플리케이션 구성 및 인프라에 대한 운영 변경을 요청, 승인, 구현 및 보고하기 위한 엔터프라이즈 변경 관리 프레임워크입니다.
조직 전체에서 Change Manager를 사용하는 경우 위임된 관리자 계정을 할당하여 모든 멤버 계정의 변경 템플릿, 승인 및 보고를 관리합니다. Quick Setup을 사용하면 조직에서 사용하는 Change Manager를 설정하고 위임된 관리자 계정을 선택할 수 있습니다. AWS 계정 하나로 Change Manager를 사용하는 경우 위임된 관리자 계정이 필요하지 않습니다.
기본적으로 Change Manager에는 위임된 관리자 계정의 모든 변경 관련 작업이 표시됩니다. 조직의 Change Manager를 설정하는 동안 위임된 관리자를 구성하는 방법에 대한 지침은 [조직용 Change Manager 설정(관리 계정)](change-manager-organization-setup.md)을 참조하세요.
**중요**
조직 전체에서 Change Manager를 사용하는 경우 항상 위임된 관리자 계정에서 변경하는 것이 좋습니다. 조직의 다른 계정에서 변경할 수 있지만 이러한 변경 사항은 위임된 관리자 계정에서 보고되거나 볼 수 없습니다.
## Explorer에 위임된 관리자 사용
Explorer는 전체 AWS 리전에서 AWS 계정에 대한 운영 데이터(OpsData)를 집계한 보기를 보고하는 사용자 지정 가능한 운영 대시보드입니다.
AWS Organizations에서 리소스 데이터 동기화를 사용하여 여러 리전 및 계정의 Explorer 데이터를 집계하도록 Systems Manager의 위임된 관리자를 구성할 수 있습니다. 위임된 관리자는 AWS Management Console, AWS Command Line Interface(AWS CLI) 또는 AWS Tools for Windows PowerShell을 사용하여 Explorer 데이터를 검색, 필터링 및 집계할 수 있습니다.
Explorer의 위임된 관리자 계정을 사용하면 위임된 관리자는 다중 계정 및 리전 리소스 데이터 동기화를 생성하거나 삭제할 수 있는 관리자 수가 개별 AWS 계정으로 제한됩니다.
Explorer를 사용하여 조직의 모든 AWS 계정 계정에서 작업 데이터를 동기화할 수 있습니다. Explorer에서 위임된 관리자를 할당하는 방법에 대한 자세한 내용은 [Explorer를 위한 위임된 관리자 구성](Explorer-setup-delegated-administrator.md)를 참조하세요.
## OpsCenter에 위임된 관리자 사용
OpsCenter에서는 운영 엔지니어 및 IT 전문가가 AWS 리소스와 관련된 운영 작업 항목(OpsItems)을 관리할 수 있는 중앙 위치를 제공합니다. OpsCenter를 사용하여 여러 계정의 OpsItems를 중앙에서 관리하려면 AWS Organizations에서 조직을 설정해야 합니다.
OpsCenter에 Quick Setup을 사용하여 위임된 관리자 계정을 할당하고 중앙에서 OpsItems를 관리하도록 OpsCenter를 구성할 수 있습니다. 자세한 내용은 [(선택 사항) Quick Setup을 사용하여 여러 계정의 OpsItems를 관리하도록 OpsCenter 구성](OpsCenter-quick-setup-cross-account.md) 섹션을 참조하세요.
## Quick Setup에 위임된 관리자 사용
Quick Setup은 자주 사용하는 AWS 서비스 및 기능을 권장 모범 사례와 함께 신속하게 구성할 수 있도록 지원하는 Systems Manager의 도구입니다. Quick Setup을 위한 위임된 관리자 계정을 구성하여 AWS Organizations를 통해 계정 및 리전 전반에 걸쳐 구성을 배포하고 관리하는 데 도움을 받을 수 있습니다. Quick Setup의 위임된 관리자는 조직에서 구성 관리자 리소스를 생성, 업데이트, 확인, 삭제할 수 있습니다. Systems Manager는 위임된 관리자를 Quick Setup에 통합 콘솔 환경 설정 프로세스의 일부로 등록합니다. 자세한 내용은 [조직을 위한 Systems Manager 통합 콘솔 설정](systems-manager-setting-up-organizations.md) 섹션을 참조하세요.
## AWS Systems Manager에 대한 일반 설정
아직 가입하지 않았다면 AWS 계정에 가입하고 관리자를 생성합니다.
### AWS 계정에 가입
AWS 계정이 없는 경우 다음 절차에 따라 계정을 생성합니다.
**AWS 계정에 가입하려면**
1. [https://portal.aws.amazon.com/billing/signup](https://portal.aws.amazon.com/billing/signup)을 엽니다.
1. 온라인 지시 사항을 따르세요.
등록 절차 중 전화 또는 텍스트 메시지를 받고 전화 키패드로 확인 코드를 입력하는 과정이 있습니다.
*AWS 계정 루트 사용자*에 가입하면 AWS 계정루트 사용자가 만들어집니다. 루트 사용자에게는 계정의 모든 AWS 서비스및 리소스에 액세스할 권한이 있습니다. 보안 모범 사례는 사용자에게 관리 액세스 권한을 할당하고, 루트 사용자만 사용하여 [루트 사용자 액세스 권한이 필요한 작업](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html#root-user-tasks)을 수행하는 것입니다.
가입 프로세스가 완료되면 AWS은 사용자에게 확인 이메일을 전송합니다. 언제든지 [https://aws.amazon.com/](https://aws.amazon.com/)으로 이동하고 **내 계정**을 선택하여 현재 계정 활동을 확인하고 계정을 관리할 수 있습니다.
### 관리자 액세스 권한이 있는 사용자 생성
AWS 계정에 가입하고 AWS 계정 루트 사용자에 보안 조치를 한 다음, AWS IAM Identity Center을 활성화하고 일상적인 작업에 루트 사용자를 사용하지 않도록 관리 사용자를 생성합니다.
**귀하의 AWS 계정 루트 사용자보호**
1. **루트 사용자**를 선택하고 AWS 계정 이메일 주소를 입력하여 [AWS Management Console](https://console.aws.amazon.com/)에 계정 소유자로 로그인합니다. 다음 페이지에서 비밀번호를 입력합니다.
루트 사용자를 사용하여 로그인하는 데 도움이 필요하면 *AWS Sign-In사용 설명서*의 [루트 사용자로 로그인](https://docs.aws.amazon.com/signin/latest/userguide/console-sign-in-tutorials.html#introduction-to-root-user-sign-in-tutorial)을 참조하세요.
1. 루트 사용자의 다중 인증(MFA)을 활성화합니다.
지침은 *IAM 사용 설명서*의 [AWS 계정루트 사용자용 가상 MFA 디바이스 활성화(콘솔)](https://docs.aws.amazon.com/IAM/latest/UserGuide/enable-virt-mfa-for-root.html)를 참조하세요.
**관리자 액세스 권한이 있는 사용자 생성**
1. IAM Identity Center를 활성화합니다.
지침은 *AWS IAM Identity Center사용 설명서*의 [AWS IAM Identity Center설정](https://docs.aws.amazon.com//singlesignon/latest/userguide/get-set-up-for-idc.html)을 참조하세요.
1. IAM Identity Center에서 사용자에게 관리 액세스 권한을 부여합니다.
IAM Identity Center 디렉터리를 ID 소스로 사용하는 방법에 대한 자습서는 *AWS IAM Identity Center사용 설명서*의 [기본 IAM Identity Center 디렉터리로 사용자 액세스 구성](https://docs.aws.amazon.com//singlesignon/latest/userguide/quick-start-default-idc.html)을 참조하세요.
**관리 액세스 권한이 있는 사용자로 로그인**
+ IAM IDentity Center 사용자로 로그인하려면 IAM Identity Center 사용자를 생성할 때 이메일 주소로 전송된 로그인 URL을 사용합니다.
IAM Identity Center 사용자로 로그인하는 데 도움이 필요한 경우 *AWS Sign-In 사용 설명서*의 [AWS액세스 포털에 로그인](https://docs.aws.amazon.com/signin/latest/userguide/iam-id-center-sign-in-tutorial.html)을 참조하세요.
**추가 사용자에게 액세스 권한 할당**
1. IAM Identity Center에서 최소 권한 적용 모범 사례를 따르는 권한 세트를 생성합니다.
지침은 *AWS IAM Identity Center 사용 설명서*의 [Create a permission set](https://docs.aws.amazon.com//singlesignon/latest/userguide/get-started-create-a-permission-set.html)를 참조하세요.
1. 사용자를 그룹에 할당하고, 그룹에 Single Sign-On 액세스 권한을 할당합니다.
지침은 *AWS IAM Identity Center 사용 설명서*의 [그룹 추가](https://docs.aws.amazon.com//singlesignon/latest/userguide/addgroups.html)를 참조하세요.