• 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 Inventory
AWS Systems Manager Inventory는 AWS 컴퓨팅 환경에 대한 가시성을 제공합니다. Inventory를 사용하여 관리형 노드에서 *메타데이터*를 수집할 수 있습니다. 이 메타데이터를 중앙 Amazon Simple Storage Service(Amazon S3) 버킷에 저장한 후 기본 제공 도구를 사용하여 데이터를 쿼리하고 어느 노드에서 소프트웨어 정책이 요구하는 소프트웨어 및 구성을 실행 중인지, 어느 노드를 업데이트해야 하는지 빠르게 확인할 수 있습니다. 원클릭 절차를 사용하여 모든 관리형 노드에 대해 인벤토리를 구성할 수 있습니다. 또한 Amazon Athena를 사용하여 여러 AWS 리전 및 AWS 계정의 인벤토리 데이터를 구성하고 볼 수 있습니다. 인벤토리를 시작하려면 [Systems Manager 콘솔](https://console.aws.amazon.com//systems-manager/inventory)을 엽니다. 탐색 창에서 [**Inventory**]를 선택합니다.
Systems Manager Inventory가 수집하는 미리 구성된 메타데이터 형식이 요구 사항을 충족하지 않을 경우 사용자 정의 Systems Manager Inventory를 생성할 수 있습니다. 사용자 지정 인벤토리는 사용자가 제공하고 특정 디렉터리에서 관리형 노드에 추가하는 정보를 포함하는 단순한 JSON 파일입니다. Systems Manager Inventory가 데이터를 수집할 때 이 사용자 정의 인벤토리 데이터를 캡처합니다. 예를 들어 대규모 데이터 센터를 운영하는 경우 각 서버의 랙 위치를 사용자 지정 인벤토리로 지정할 수 있습니다. 그러면 다른 인벤토리 데이터를 볼 때 랙 공간 데이터를 볼 수 있습니다.
**중요**
Systems Manager Inventory는 관리형 노드에서*만* 메타데이터를 수집합니다. Inventory는 독점 정보 또는 데이터에 액세스하지 않습니다.
다음 표에서는 Systems Manager Inventory로 수집할 수 있는 데이터 형식을 설명합니다. 또한 이 표에서는 노드를 대상으로 하는 다양한 오퍼링과 지정할 수 있는 수집 간격에 대해 설명합니다.
****
| 구성 | 세부 사항 |
| --- | --- |
| 메타데이터 형식 | 다음 유형의 데이터를 수집할 인벤토리를 구성할 수 있습니다. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/systems-manager/latest/userguide/systems-manager-inventory.html) 인벤토리에서 수집한 모든 메타데이터의 목록을 보려면 [인벤토리에서 수집한 메타데이터](inventory-schema.md) 섹션을 참조하세요. |
| 대상 노드 | AWS 계정에서 관리되는 모든 노드의 인벤토리를 선택하고, 태그를 사용하여 개별적으로 노드 또는 대상 노드 그룹을 선택할 수 있습니다. 모든 관리형 노드에서 인벤토리 데이터를 수집하는 방법에 대한 자세한 내용은 [AWS 계정의 모든 관리형 노드에 대한 인벤토리 작성](inventory-collection.md#inventory-management-inventory-all) 섹션을 참조하세요. |
| 정보 수집 시기 | 수집 간격을 분, 시간 및 일 단위로 지정할 수 있습니다. 가장 짧은 수집 간격은 30분입니다. |
**참고**
수집하는 데이터의 용량에 따라 시스템이 데이터를 지정된 출력 경로에 보고하는 데 몇 분이 걸릴 수 있습니다. 정보가 수집된 후 보안 HTTPS 채널을 통해 AWS 계정에서만 액세스할 수 있는 일반 텍스트 AWS 스토어로 데이터가 전송됩니다.
Systems Manager 콘솔의 [**Inventory**] 페이지에서 데이터를 볼 수 있으며, 손쉽게 데이터를 쿼리할 수 있도록 여러 개의 미리 정의된 카드가 포함됩니다.
![\[Systems Manager 콘솔의 Systems Manager Inventory 카드\]](http://docs.aws.amazon.com/ko_kr/systems-manager/latest/userguide/images/inventory-cards.png)
**참고**
Inventory 카드가 [*종료됨(Terminated)*] 및 [*중지됨(Stopped)*] 상태의 Amazon EC2 관리형 인스턴스를 자동으로 필터링하여 제외합니다. 온프레미스와 AWS IoT Greengrass 코어 디바이스 관리형 노드의 경우 인벤토리 카드가 *종료됨* 상태의 노드를 자동으로 필터링하여 제외합니다.
리소스 데이터 동기화를 생성하여 단일 Amazon S3 버킷에 모든 데이터를 저장하고 동기화하는 경우 [**인벤토리 세부 정보 뷰(Inventory Detailed View)**] 페이지에서 데이터를 세부적으로 확인할 수 있습니다. 자세한 내용은 [여러 리전 및 계정에서 인벤토리 데이터 쿼리](systems-manager-inventory-query.md) 섹션을 참조하세요.
**EventBridge 지원**
이 Systems Manager 도구는 Amazon EventBridge 규칙에서 *이벤트* 유형으로 지원됩니다. 자세한 내용은 [Amazon EventBridge로 Systems Manager 이벤트 모니터링](monitoring-eventbridge-events.md) 및 [참조: Systems Manager용 Amazon EventBridge 이벤트 패턴 및 유형](reference-eventbridge-events.md) 섹션을 참조하세요.
**Topics**
+ [Systems Manager Inventory에 대해 자세히 알아보기](inventory-about.md)
+ [Systems Manager Inventory 설정](systems-manager-inventory-setting-up.md)
+ [인벤토리 수집 구성](inventory-collection.md)
+ [여러 리전 및 계정에서 인벤토리 데이터 쿼리](systems-manager-inventory-query.md)
+ [필터를 사용하여 인벤토리 수집 쿼리](inventory-query-filters.md)
+ [인벤토리 데이터 집계](inventory-aggregate.md)
+ [사용자 정의 인벤토리 작업](inventory-custom.md)
+ [인벤토리 이력 및 변경 사항 추적 보기](inventory-history.md)
+ [데이터 수집 중지 및 인벤토리 데이터 삭제](systems-manager-inventory-delete.md)
+ [관리형 노드에 사용자 지정 인벤토리 메타데이터 할당](inventory-custom-metadata.md)
+ [AWS CLI를 사용하여 인벤토리 데이터 수집 구성](inventory-collection-cli.md)
+ [연습: 리소스 데이터 동기화를 사용하여 인벤토리 데이터 집계](inventory-resource-data-sync.md)
+ [Systems Manager Inventory 관련 문제 해결](syman-inventory-troubleshooting.md)
# Systems Manager Inventory에 대해 자세히 알아보기
AWS Systems Manager 인벤토리를 구성할 때 수집할 메타데이터의 유형, 메타데이터를 수집할 관리형 노드, 메타데이터 모음에 대한 일정을 지정해야 합니다. 이러한 구성은 AWS 계정에 AWS Systems Manager State Manager 연결로 저장됩니다. 연결은 단순히 구성일 뿐입니다.
**참고**
인벤토리는 메타데이터만 수집합니다. 개인 정보나 독점 정보는 수집하지 않습니다.
**Topics**
+ [인벤토리에서 수집한 메타데이터](inventory-schema.md)
+ [파일 및 Windows 레지스트리 인벤토리 관련 작업](inventory-file-and-registry.md)
# 인벤토리에서 수집한 메타데이터
다음 샘플은 각 AWS Systems Manager Inventory 플러그인에서 수집한 메타데이터의 전체 목록을 보여줍니다.
```
{
"typeName": "AWS:InstanceInformation",
"version": "1.0",
"attributes":[
{ "name": "AgentType", "dataType" : "STRING"},
{ "name": "AgentVersion", "dataType" : "STRING"},
{ "name": "ComputerName", "dataType" : "STRING"},
{ "name": "InstanceId", "dataType" : "STRING"},
{ "name": "IpAddress", "dataType" : "STRING"},
{ "name": "PlatformName", "dataType" : "STRING"},
{ "name": "PlatformType", "dataType" : "STRING"},
{ "name": "PlatformVersion", "dataType" : "STRING"},
{ "name": "ResourceType", "dataType" : "STRING"},
{ "name": "AgentStatus", "dataType" : "STRING"},
{ "name": "InstanceStatus", "dataType" : "STRING"}
]
},
{
"typeName" : "AWS:Application",
"version": "1.1",
"attributes":[
{ "name": "Name", "dataType": "STRING"},
{ "name": "ApplicationType", "dataType": "STRING"},
{ "name": "Publisher", "dataType": "STRING"},
{ "name": "Version", "dataType": "STRING"},
{ "name": "Release", "dataType": "STRING"},
{ "name": "Epoch", "dataType": "STRING"},
{ "name": "InstalledTime", "dataType": "STRING"},
{ "name": "Architecture", "dataType": "STRING"},
{ "name": "URL", "dataType": "STRING"},
{ "name": "Summary", "dataType": "STRING"},
{ "name": "PackageId", "dataType": "STRING"}
]
},
{
"typeName" : "AWS:File",
"version": "1.0",
"attributes":[
{ "name": "Name", "dataType": "STRING"},
{ "name": "Size", "dataType": "STRING"},
{ "name": "Description", "dataType": "STRING"},
{ "name": "FileVersion", "dataType": "STRING"},
{ "name": "InstalledDate", "dataType": "STRING"},
{ "name": "ModificationTime", "dataType": "STRING"},
{ "name": "LastAccessTime", "dataType": "STRING"},
{ "name": "ProductName", "dataType": "STRING"},
{ "name": "InstalledDir", "dataType": "STRING"},
{ "name": "ProductLanguage", "dataType": "STRING"},
{ "name": "CompanyName", "dataType": "STRING"},
{ "name": "ProductVersion", "dataType": "STRING"}
]
},
{
"typeName": "AWS:AWSComponent",
"version": "1.0",
"attributes":[
{ "name": "Name", "dataType": "STRING"},
{ "name": "ApplicationType", "dataType": "STRING"},
{ "name": "Publisher", "dataType": "STRING"},
{ "name": "Version", "dataType": "STRING"},
{ "name": "InstalledTime", "dataType": "STRING"},
{ "name": "Architecture", "dataType": "STRING"},
{ "name": "URL", "dataType": "STRING"}
]
},
{
"typeName": "AWS:WindowsUpdate",
"version":"1.0",
"attributes":[
{ "name": "HotFixId", "dataType": "STRING"},
{ "name": "Description", "dataType": "STRING"},
{ "name": "InstalledTime", "dataType": "STRING"},
{ "name": "InstalledBy", "dataType": "STRING"}
]
},
{
"typeName": "AWS:Network",
"version":"1.0",
"attributes":[
{ "name": "Name", "dataType": "STRING"},
{ "name": "SubnetMask", "dataType": "STRING"},
{ "name": "Gateway", "dataType": "STRING"},
{ "name": "DHCPServer", "dataType": "STRING"},
{ "name": "DNSServer", "dataType": "STRING"},
{ "name": "MacAddress", "dataType": "STRING"},
{ "name": "IPV4", "dataType": "STRING"},
{ "name": "IPV6", "dataType": "STRING"}
]
},
{
"typeName": "AWS:PatchSummary",
"version":"1.0",
"attributes":[
{ "name": "PatchGroup", "dataType": "STRING"},
{ "name": "BaselineId", "dataType": "STRING"},
{ "name": "SnapshotId", "dataType": "STRING"},
{ "name": "OwnerInformation", "dataType": "STRING"},
{ "name": "InstalledCount", "dataType": "NUMBER"},
{ "name": "InstalledPendingRebootCount", "dataType": "NUMBER"},
{ "name": "InstalledOtherCount", "dataType": "NUMBER"},
{ "name": "InstalledRejectedCount", "dataType": "NUMBER"},
{ "name": "NotApplicableCount", "dataType": "NUMBER"},
{ "name": "UnreportedNotApplicableCount", "dataType": "NUMBER"},
{ "name": "MissingCount", "dataType": "NUMBER"},
{ "name": "FailedCount", "dataType": "NUMBER"},
{ "name": "OperationType", "dataType": "STRING"},
{ "name": "OperationStartTime", "dataType": "STRING"},
{ "name": "OperationEndTime", "dataType": "STRING"},
{ "name": "InstallOverrideList", "dataType": "STRING"},
{ "name": "RebootOption", "dataType": "STRING"},
{ "name": "LastNoRebootInstallOperationTime", "dataType": "STRING"},
{ "name": "ExecutionId", "dataType": "STRING", "isOptional": "true"},
{ "name": "NonCompliantSeverity", "dataType": "STRING", "isOptional": "true"},
{ "name": "SecurityNonCompliantCount", "dataType": "NUMBER", "isOptional": "true"},
{ "name": "CriticalNonCompliantCount", "dataType": "NUMBER", "isOptional": "true"},
{ "name": "OtherNonCompliantCount", "dataType": "NUMBER", "isOptional": "true"}
]
},
{
"typeName": "AWS:PatchCompliance",
"version":"1.0",
"attributes":[
{ "name": "Title", "dataType": "STRING"},
{ "name": "KBId", "dataType": "STRING"},
{ "name": "Classification", "dataType": "STRING"},
{ "name": "Severity", "dataType": "STRING"},
{ "name": "State", "dataType": "STRING"},
{ "name": "InstalledTime", "dataType": "STRING"}
]
},
{
"typeName": "AWS:ComplianceItem",
"version":"1.0",
"attributes":[
{ "name": "ComplianceType", "dataType": "STRING", "isContext": "true"},
{ "name": "ExecutionId", "dataType": "STRING", "isContext": "true"},
{ "name": "ExecutionType", "dataType": "STRING", "isContext": "true"},
{ "name": "ExecutionTime", "dataType": "STRING", "isContext": "true"},
{ "name": "Id", "dataType": "STRING"},
{ "name": "Title", "dataType": "STRING"},
{ "name": "Status", "dataType": "STRING"},
{ "name": "Severity", "dataType": "STRING"},
{ "name": "DocumentName", "dataType": "STRING"},
{ "name": "DocumentVersion", "dataType": "STRING"},
{ "name": "Classification", "dataType": "STRING"},
{ "name": "PatchBaselineId", "dataType": "STRING"},
{ "name": "PatchSeverity", "dataType": "STRING"},
{ "name": "PatchState", "dataType": "STRING"},
{ "name": "PatchGroup", "dataType": "STRING"},
{ "name": "InstalledTime", "dataType": "STRING"},
{ "name": "InstallOverrideList", "dataType": "STRING", "isOptional": "true"},
{ "name": "DetailedText", "dataType": "STRING", "isOptional": "true"},
{ "name": "DetailedLink", "dataType": "STRING", "isOptional": "true"},
{ "name": "CVEIds", "dataType": "STRING", "isOptional": "true"}
]
},
{
"typeName": "AWS:ComplianceSummary",
"version":"1.0",
"attributes":[
{ "name": "ComplianceType", "dataType": "STRING"},
{ "name": "PatchGroup", "dataType": "STRING"},
{ "name": "PatchBaselineId", "dataType": "STRING"},
{ "name": "Status", "dataType": "STRING"},
{ "name": "OverallSeverity", "dataType": "STRING"},
{ "name": "ExecutionId", "dataType": "STRING"},
{ "name": "ExecutionType", "dataType": "STRING"},
{ "name": "ExecutionTime", "dataType": "STRING"},
{ "name": "CompliantCriticalCount", "dataType": "NUMBER"},
{ "name": "CompliantHighCount", "dataType": "NUMBER"},
{ "name": "CompliantMediumCount", "dataType": "NUMBER"},
{ "name": "CompliantLowCount", "dataType": "NUMBER"},
{ "name": "CompliantInformationalCount", "dataType": "NUMBER"},
{ "name": "CompliantUnspecifiedCount", "dataType": "NUMBER"},
{ "name": "NonCompliantCriticalCount", "dataType": "NUMBER"},
{ "name": "NonCompliantHighCount", "dataType": "NUMBER"},
{ "name": "NonCompliantMediumCount", "dataType": "NUMBER"},
{ "name": "NonCompliantLowCount", "dataType": "NUMBER"},
{ "name": "NonCompliantInformationalCount", "dataType": "NUMBER"},
{ "name": "NonCompliantUnspecifiedCount", "dataType": "NUMBER"}
]
},
{
"typeName": "AWS:InstanceDetailedInformation",
"version":"1.0",
"attributes":[
{ "name": "CPUModel", "dataType": "STRING"},
{ "name": "CPUCores", "dataType": "NUMBER"},
{ "name": "CPUs", "dataType": "NUMBER"},
{ "name": "CPUSpeedMHz", "dataType": "NUMBER"},
{ "name": "CPUSockets", "dataType": "NUMBER"},
{ "name": "CPUHyperThreadEnabled", "dataType": "STRING"},
{ "name": "OSServicePack", "dataType": "STRING"}
]
},
{
"typeName": "AWS:Service",
"version":"1.0",
"attributes":[
{ "name": "Name", "dataType": "STRING"},
{ "name": "DisplayName", "dataType": "STRING"},
{ "name": "ServiceType", "dataType": "STRING"},
{ "name": "Status", "dataType": "STRING"},
{ "name": "DependentServices", "dataType": "STRING"},
{ "name": "ServicesDependedOn", "dataType": "STRING"},
{ "name": "StartType", "dataType": "STRING"}
]
},
{
"typeName": "AWS:WindowsRegistry",
"version":"1.0",
"attributes":[
{ "name": "KeyPath", "dataType": "STRING"},
{ "name": "ValueName", "dataType": "STRING"},
{ "name": "ValueType", "dataType": "STRING"},
{ "name": "Value", "dataType": "STRING"}
]
},
{
"typeName": "AWS:WindowsRole",
"version":"1.0",
"attributes":[
{ "name": "Name", "dataType": "STRING"},
{ "name": "DisplayName", "dataType": "STRING"},
{ "name": "Path", "dataType": "STRING"},
{ "name": "FeatureType", "dataType": "STRING"},
{ "name": "DependsOn", "dataType": "STRING"},
{ "name": "Description", "dataType": "STRING"},
{ "name": "Installed", "dataType": "STRING"},
{ "name": "InstalledState", "dataType": "STRING"},
{ "name": "SubFeatures", "dataType": "STRING"},
{ "name": "ServerComponentDescriptor", "dataType": "STRING"},
{ "name": "Parent", "dataType": "STRING"}
]
},
{
"typeName": "AWS:Tag",
"version":"1.0",
"attributes":[
{ "name": "Key", "dataType": "STRING"},
{ "name": "Value", "dataType": "STRING"}
]
},
{
"typeName": "AWS:ResourceGroup",
"version":"1.0",
"attributes":[
{ "name": "Name", "dataType": "STRING"},
{ "name": "Arn", "dataType": "STRING"}
]
},
{
"typeName": "AWS:BillingInfo",
"version": "1.0",
"attributes": [
{ "name": "BillingProductId", "dataType": "STRING"}
]
}
```
**참고**
`"typeName": "AWS:InstanceInformation"`의 경우에, `InstanceStatus`는 Active, ConnectionLost, Stopped, Terminated 중 하나일 수 있습니다.
버전 2.5의 릴리스에서 RPM Package Manager는 일련 속성을 Epoch로 교체했습니다. Epoch 속성은 일련처럼 단조 증가하는 정수입니다. `AWS:Application` 유형을 이용해 인벤토리를 작성할 때 큰 Epoch 값은 새 버전을 의미합니다. Epoch 값이 동일하거나 빈 경우에는 버전 또는 릴리스 속성의 값으로 새 버전을 판단합니다.
일부 메타데이터는 Linux 인스턴스에서 제공되지 않습니다. 특히 "typeName": "AWS:Network"의 경우 다음과 같은 메타데이터 유형은 아직 Linux 인스턴스에 대해 지원되지 않습니다. Windows의 경우에는 지원됩니다.
\$1 "name": "SubnetMask", "dataType": "STRING"\$1,
\$1 "name": "DHCPServer", "dataType": "STRING"\$1,
\$1 "name": "DNSServer", "dataType": "STRING"\$1,
\$1 "name": "Gateway", "dataType": "STRING"\$1,
# 파일 및 Windows 레지스트리 인벤토리 관련 작업
AWS Systems Manager Inventory를 통해 Windows Server, Linux 및 macOS 운영 체제에서 파일을 검색하고 인벤토리로 만들 수 있습니다. 또한 Windows 레지스트리를 검색하고 인벤토리로 만들 수 있습니다.
**Files**: 몇 가지 예를 들자면 파일 이름, 파일 생성 시각, 파일을 마지막으로 수정하고 액세스한 시간, 파일 크기 등 파일에 관한 메타데이터 정보를 수집할 수 있습니다. 파일 인벤토리 수집을 시작하려면 인벤토리를 수행할 파일 경로, 인벤토리로 만들고자 하는 파일의 유형을 정의하는 패턴 한 개 이상, 그리고 그 경로가 반복적으로 통과하는지 여부를 지정합니다. Systems Manager는 패턴과 일치하는 지정된 경로의 파일에 대한 모든 파일 메타데이터의 인벤토리를 작성합니다. 파일 인벤토리에서는 다음 파라미터 입력을 사용합니다.
```
{
"Path": string,
"Pattern": array[string],
"Recursive": true,
"DirScanLimit" : number // Optional
}
```
+ **Path**: 파일을 인벤토리로 만들고자 하는 디렉터리 경로. Windows에서는 해당 환경 변수가 단일 디렉터리 경로와 매핑되는 경우에 한해 `%PROGRAMFILES% `와 같은 환경 변수를 사용할 수 있습니다. 예를 들어 여러 디렉터리 경로에 매핑되는 %PATH%를 사용하는 경우 Inventory에는 오류가 발생합니다.
+ **Pattern**: 파일을 식별할 패턴의 어레이
+ **Recursive**: Inventory가 디렉터리를 반복적으로 통과하는지 여부를 나타내는 부울 값
+ **DirScanLimit**: 몇 개의 디렉터리를 검사할 수 있는지 지정하는 값(선택 사항). 이 파라미터를 사용하여 해당 노드의 성능 저하를 최소화합니다. Inventory는 최소 5,000개의 디렉터리를 검사합니다.
**참고**
Inventory는 지정된 모든 경로에서 최소 500개 파일에 대해 메타데이터를 수집합니다.
다음은 파일에 대한 인벤토리 작업을 수행할 때 파라미터를 지정하는 방법을 보여주는 예제입니다.
+ Linux 및 macOS에서는 `/home/ec2-user` 디렉터리(하위 디렉터리는 모두 제외)에 .sh 파일에 대한 메타데이터를 수집합니다.
```
[{"Path":"/home/ec2-user","Pattern":["*.sh", "*.sh"],"Recursive":false}]
```
+ Windows에서는 모든 ".exe" 파일에 대한 메타데이터를 Program Files 폴더(하위 디렉터리 포함)에 반복적으로 수집합니다.
```
[{"Path":"C:\Program Files","Pattern":["*.exe"],"Recursive":true}]
```
+ Windows에서는 특정 로그 패턴의 메타데이터를 수집합니다.
```
[{"Path":"C:\ProgramData\Amazon","Pattern":["*amazon*.log"],"Recursive":true}]
```
+ 반복 수집을 수행할 때는 디렉터리 개수를 제한합니다.
```
[{"Path":"C:\Users","Pattern":["*.ps1"],"Recursive":true, "DirScanLimit": 1000}]
```
**Windows 레지스트리**: Windows 레지스트리 키 및 값을 수집할 수 있습니다. 키 경로를 선택하고 모든 키와 값을 반복적으로 수집할 수 있습니다. 특정 경로에 대해 특정 레지스트리 키와 그 값을 수집할 수도 있습니다. 인벤토리는 키 경로, 이름 및 값을 수집합니다.
```
{
"Path": string,
"Recursive": true,
"ValueNames": array[string] // optional
}
```
+ **Path**: 레지스트리 키의 경로
+ **Recursive**: 인벤토리가 레지스트리 경로를 반복적으로 통과하는지 여부를 나타내는 부울 값
+ **ValueNames**: 레지스트리 키에 대한 인벤토리 작업을 위한 값 이름의 어레이. 이 파라미터를 사용하는 경우 Systems Manager는 지정된 경로에 대한 지정된 값 이름만 인벤토리로 만듭니다.
**참고**
인벤토리는 지정된 모든 경로에 대해 최소 250개 레지스트리 키 값을 수집합니다.
다음은 Windows 레지스트리에 대한 인벤토리 작업을 수행할 때 파라미터를 지정하는 방법을 보여주는 예제입니다.
+ 특정 경로에 대해 모든 키와 값을 반복적으로 수집합니다.
```
[{"Path":"HKEY_LOCAL_MACHINE\SOFTWARE\Amazon","Recursive": true}]
```
+ 특정 경로에 대해 모든 키와 값을 수집합니다(반복 검색은 해제됨).
```
[{"Path":"HKEY_LOCAL_MACHINE\SOFTWARE\Intel\PSIS\PSIS_DECODER", "Recursive": false}]
```
+ `ValueNames` 옵션을 사용하여 특정 키를 수집합니다.
```
{"Path":"HKEY_LOCAL_MACHINE\SOFTWARE\Amazon\MachineImage","ValueNames":["AMIName"]}
```
# Systems Manager Inventory 설정
AWS Systems Manager Inventory를 사용하여 관리형 노드에서 실행 중인 애플리케이션, 서비스, AWS 구성 요소 등에 대한 메타데이터를 수집하기 전에 단일 Amazon Simple Storage Service(Amazon S3) 버킷의 인벤토리 데이터 스토리지를 중앙 집중화하도록 리소스 데이터 동기화를 구성하는 것이 좋습니다. 또한 인벤토리 이벤트의 Amazon EventBridge 모니터링을 구성하는 것이 좋습니다. 이러한 프로세스를 통해 인벤토리 데이터 및 수집을 보다 쉽게 보고 관리할 수 있습니다.
**Topics**
+ [인벤토리의 리소스 데이터 동기화 생성](inventory-create-resource-data-sync.md)
+ [EventBridge를 사용한 Inventory 이벤트 모니터링](systems-manager-inventory-setting-up-eventbridge.md)
# 인벤토리의 리소스 데이터 동기화 생성
이 주제에서는 AWS Systems Manager 인벤토리에 대한 리소스 데이터 동기화를 설정하고 구성하는 방법에 대해 설명합니다. Systems Manager Explorer의 리소스 데이터 동기화에 대한 자세한 내용은 [여러 계정 및 리전에서 데이터를 표시하도록 Systems Manager Explorer 설정](Explorer-resource-data-sync.md) 단원을 참조하세요.
## 리소스 데이터 동기화 정보
Systems Manager 리소스 데이터 동기화를 사용하여 모든 관리형 노드에서 수집된 인벤토리 데이터를 단일 Amazon Simple Storage Service(Amazon S3) 버킷으로 전송합니다. 이제 새로운 인벤토리 데이터가 수집될 때마다 리소스 데이터 동기화가 중앙 데이터를 자동으로 업데이트합니다. 모든 인벤토리 데이터가 대상 Amazon S3 버킷에 저장되면 Amazon Athena와 Amazon Quick 같은 서비스를 사용하여 수집한 데이터에 대한 쿼리를 실행하거나 분석할 수 있습니다.
예를 들어 150개 관리형 노드 플릿에서 실행 중인 운영 체제(OS) 및 애플리케이션에 대한 데이터를 수집할 수 있도록 인벤토리를 구성하였다고 가정하겠습니다. 이러한 노드 중 일부는 노드는 온프레미스 데이터 센터에 있고, 다른 노드는 여러 AWS 리전의 Amazon Elastic Compute Cloud(Amazon EC2)에서 실행되고 있습니다. 리소스 데이터 동기화를 구성하지 *않았다면* 각 노드마다 수집된 인벤토리 데이터를 수동으로 수집하거나, 혹은 스크립트를 생성하여 이 정보를 수집해야 합니다. 그런 다음 쿼리를 통해 데이터를 분석하려면 데이터를 애플리케이션으로 포팅해야 합니다.
리소스 데이터 동기화를 사용하면 작업 한 번으로 모든 관리형 노드에서 수집된 인벤토리 데이터를 모두 동기화할 수 있습니다. 동기화가 성공적으로 생성되면 Systems Manager가 모든 인벤토리 데이터의 기준을 만들어서 대상 Amazon S3 버킷에 저장합니다. 이후 새로운 인벤토리 데이터가 수집되면 Systems Manager가 Amazon S3 버킷의 데이터를 자동 업데이트합니다. 이후부터는 데이터를 빠르고 경제적으로 Amazon Athena 및 Amazon Quick에 포팅할 수 있습니다.
다이어그램 1에서는 리소스 데이터 동기화를 통해 [하이브리드 및 멀티클라우](operating-systems-and-machine-types.md#supported-machine-types)드 환경의 Amazon EC2 및 기타 시스템 유형에서 대상 Amazon S3 버킷으로 인벤토리 데이터를 집계하는 방법을 보여줍니다. 또한 리소스 데이터 동기화가 여러 AWS 계정 및 AWS 리전에서 어떻게 작동하는지도 보여줍니다.
**다이어그램 1: 여러 AWS 계정 및 AWS 리전에서 리소스 데이터 동기화**
![\[Systems Manager 리소스 데이터 동기화 아키텍처\]](http://docs.aws.amazon.com/ko_kr/systems-manager/latest/userguide/images/inventory-resource-data-sync-updated.png)
관리형 노드가 삭제되더라도 리소스 데이터 동기화가 삭제된 노드의 인벤토리 파일을 보존합니다. 하지만 실행 노드의 경우에는 새로운 파일이 생성되어 Amazon S3 버킷에 작성되면 리소스 데이터 동기화가 이전 인벤토리 파일을 자동으로 덮어씁니다. 시간 경과에 따른 인벤토리 변경 사항을 추적하고 싶다면 AWS Config 서비스를 사용하여 `SSM:ManagedInstanceInventory` 리소스 유형을 추적할 수 있습니다. 자세한 내용은 [AWS Config 시작하기](https://docs.aws.amazon.com/config/latest/developerguide/getting-started.html) 섹션을 참조하세요.
이 섹션의 절차에 따라 Amazon S3 및 AWS Systems Manager 콘솔을 사용하여 Inventory에 대한 리소스 데이터 동기화를 생성할 수 있습니다. AWS CloudFormation을 사용하여 리소스 데이터 동기화를 생성하거나 삭제할 수도 있습니다. CloudFormation을 사용하려면 CloudFormation 템플릿에 [https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-ssm-resourcedatasync.html](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-ssm-resourcedatasync.html) 리소스를 추가합니다. 자세한 내용은 다음 설명서 리소스 중 하나를 참조하세요.
+ [AWS CloudFormation resource for resource data sync in AWS Systems Manager](https://aws.amazon.com/blogs/mt/aws-cloudformation-resource-for-resource-data-sync-in-aws-systems-manager/)(블로그)
+ *AWS CloudFormation 사용 설명서*의 [AWS CloudFormation 템플릿 작업](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/template-guide.html)
**참고**
AWS Key Management Service(AWS KMS)를 사용하여 Amazon S3 버킷의 인벤토리 데이터를 암호화할 수 있습니다. AWS Command Line Interface(AWS CLI)를 사용하여 암호화된 동기화를 생성하는 방법과 Amazon Athena 및 Amazon Quick에서 중앙 데이터를 사용하는 방법에 대한 예는 [연습: 리소스 데이터 동기화를 사용하여 인벤토리 데이터 집계](inventory-resource-data-sync.md) 섹션을 참조하세요.
## 시작하기 전 준비 사항
리소스 데이터 동기화를 생성하기 전에 다음 절차를 사용하여 집계된 인벤토리 데이터를 저장할 중앙 Amazon S3 버킷을 생성합니다. 이 절차에서는 Systems Manager가 여러 계정에서 버킷에 인벤토리 데이터를 쓸 수 있는 버킷 정책을 할당하는 방법을 설명합니다. 리소스 데이터 동기화를 위해 인벤토리 데이터를 집계하는 데 사용할 Amazon S3 버킷이 이미 있는 경우 다음 절차에서 정책을 사용하도록 버킷을 구성해야 합니다.
**참고**
지정된 Amazon S3 버킷이 Object Lock을 사용하도록 구성된 경우 Systems Manager Inventory는 해당 버킷에 데이터를 추가할 수 없습니다. 리소스 데이터 동기화를 위해 생성하거나 선택한 Amazon S3 버킷이 Amazon S3 Object Lock을 사용하도록 구성되지 않았는지 확인합니다. 자세한 내용은 *Amazon Simple Storage Service 사용 설명서*의 [Amazon S3 Object Lock 작동 방식](https://docs.aws.amazon.com/AmazonS3/latest/userguide/object-lock-overview.html)을 참조하세요.
**리소스 데이터 동기화를 위해 Amazon S3 버킷을 생성하고 구성하려면**
1. [https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/)에서 S3 콘솔을 엽니다.
1. 수집한 인벤토리 데이터를 저장할 버킷을 생성합니다. 자세한 내용은 *Amazon Simple Storage Service 사용 설명서*의 [버킷 생성](https://docs.aws.amazon.com/AmazonS3/latest/userguide/CreatingABucket.html)을 참조하세요. 버킷 이름과 버킷을 생성한 AWS 리전을 따로 적어둡니다.
1. **권한** 탭을 선택한 후 **버킷 정책**을 선택합니다.
1. 다음 버킷 정책을 복사하여 정책 편집기에 붙여 넣습니다. *amzn-s3-demo-bucket*을 생성한 S3 버킷의 이름으로 바꿉니다. *account\$1ID\$1number*를 유효한 AWS 계정 ID 번호로 바꿉니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "SSMBucketPermissionsCheck",
"Effect": "Allow",
"Principal": {
"Service": "ssm.amazonaws.com"
},
"Action": "s3:GetBucketAcl",
"Resource": "arn:aws:s3:::amzn-s3-demo-bucket"
},
{
"Sid": " SSMBucketDelivery",
"Effect": "Allow",
"Principal": {
"Service": "ssm.amazonaws.com"
},
"Action": "s3:PutObject",
"Resource": [
"arn:aws:s3:::amzn-s3-demo-bucket/*/accountid=111122223333/*",
"arn:aws:s3:::amzn-s3-demo-bucket/*/accountid=444455556666/*",
"arn:aws:s3:::amzn-s3-demo-bucket/*/accountid=123456789012/*",
"arn:aws:s3:::amzn-s3-demo-bucket/*/accountid=777788889999/*"
],
"Condition": {
"StringEquals": {
"s3:x-amz-acl": "bucket-owner-full-control",
"aws:SourceAccount": "111122223333"
},
"ArnLike": {
"aws:SourceArn": "arn:aws:ssm:*:111122223333:resource-data-sync/*"
}
}
}
]
}
```
------
1. 변경 내용을 저장합니다.
## Inventory의 리소스 데이터 동기화 생성
Systems Manager Inventory의 리소스 데이터 동기화는 Systems Manager 콘솔에서 다음 절차에 따라 생성합니다. AWS CLI를 사용하여 리소스 데이터 동기화를 만드는 방법에 대한 자세한 내용은 [AWS CLI를 사용하여 인벤토리 데이터 수집 구성](inventory-collection-cli.md) 섹션을 참조하세요.
**리소스 데이터 동기화 생성**
1. [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)에서 AWS Systems Manager 콘솔을 엽니다.
1. 탐색 창에서 **Fleet Manager**를 선택합니다.
1. [**계정 관리(Account management)**] 메뉴에서 [**리소스 데이터 동기화(Resource data sync)**]를 선택합니다.
1. **Create resource data sync(리소스 데이터 동기화 생성)**를 선택합니다.
1. [**동기화 이름(Sync name)**] 필드에 동기화 구성 이름을 입력합니다.
1. [**버킷 이름(Bucket name)**] 필드에 **리소스 데이터 동기화를 위한 Amazon S3 버킷을 생성하고 구성하려면** 절차를 사용하여 생성한 Amazon S3 버킷의 이름을 입력합니다.
1. (옵션) [**버킷 접두사(Bucket prefix)**] 필드에 Amazon S3 버킷 접두사(하위 디렉터리)의 이름을 입력합니다.
1. 생성한 Amazon S3 버킷이 현재 AWS 리전에 위치하면 [**버킷 리전(Bucket region)**] 필드에서 [**이 리전(This region)**]을 선택합니다. 버킷이 다른 AWS 리전에 위치하면 [**다른 리전(Another region)**]을 선택하고 리전 이름을 입력합니다.
**참고**
동기화와 대상 Amazon S3 버킷이 서로 다른 리전에 위치하는 경우에는 데이터 전송 요금이 부과될 수 있습니다. 자세한 내용은 [Amazon S3 요금](https://aws.amazon.com/s3/pricing/)을 참조하세요.
1. (옵션) [**KMS Key ARN**] 필드에 Amazon S3의 인벤토리 데이터를 암호화할 KMS 키 ARN을 입력하거나 붙여 넣습니다.
1. **생성(Create)**을 선택합니다.
여러 AWS 리전의 인벤토리 데이터를 동기화하려면 *각* 리전에서 리소스 데이터 동기화를 생성해야 합니다. 인벤토리 데이터를 수집해 중앙 Amazon S3 버킷으로 보내려는 각 AWS 리전에서 이 절차를 반복합니다. 각 리전에서 동기화를 생성할 때 [**버킷 이름(Bucket name)**] 필드에 중앙 Amazon S3 버킷을 지정합니다. 그런 다음 [**버킷 리전(Bucket region)**] 옵션을 사용하여 다음 스크린샷에 표시된 것처럼 중앙 Amazon S3 버킷을 생성한 리전을 선택합니다. 연결이 실행되어 인벤토리 데이터를 수집하고 나면 Systems Manager가 중앙 Amazon S3 버킷에 데이터를 저장합니다.
![\[여러 AWS 리전에서 Systems Manager 리소스 데이터 동기화\]](http://docs.aws.amazon.com/ko_kr/systems-manager/latest/userguide/images/inventory-rds-multiple-regions.png)
## AWS Organizations에 정의된 계정에 대한 인벤토리 리소스 데이터 동기화 생성
AWS Organizations에 정의된 AWS 계정의 인벤토리 데이터를 중앙 Amazon S3 버킷으로 동기화할 수 있습니다. 다음 절차를 완료하면 인벤토리 데이터가 중앙 버킷의 *개별* Amazon S3 키 접두사와 동기화됩니다. 각 키 접두사는 서로 다른 AWS 계정 ID를 나타냅니다.
**시작하기 전 준비 사항**
시작하기 전에 AWS Organizations에서 AWS 계정를 설정하고 구성했는지 확인합니다. 자세한 내용은 [https://docs.aws.amazon.com/organizations/latest/userguide/rgs_getting-started.html](https://docs.aws.amazon.com/organizations/latest/userguide/rgs_getting-started.html)를 참조하세요.
또한 AWS Organizations에 정의된 AWS 리전과 AWS 계정 각각에 대해 조직 기반 자원 데이터 동기화를 생성해야 합니다.
### 중앙 Amazon S3 버킷 생성
다음 절차를 사용하여 집계된 인벤토리 데이터를 저장할 중앙 Amazon S3 버킷을 생성합니다. 이 절차에서는 Systems Manager가 AWS Organizations 계정 ID에서 버킷에 인벤토리 데이터를 쓸 수 있는 버킷 정책을 할당하는 방법을 설명합니다. 리소스 데이터 동기화를 위해 인벤토리 데이터를 집계하는 데 사용할 Amazon S3 버킷이 이미 있는 경우 다음 절차에서 정책을 사용하도록 버킷을 구성해야 합니다.
**AWS Organizations에 정의된 여러 계정의 리소스 데이터 동기화를 위한 Amazon S3 버킷을 생성하고 구성하려면**
1. [https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/)에서 S3 콘솔을 엽니다.
1. 집계된 인벤토리 데이터를 저장할 버킷을 생성합니다. 자세한 내용은 *Amazon Simple Storage Service 사용 설명서*의 [버킷 생성](https://docs.aws.amazon.com/AmazonS3/latest/userguide/CreatingABucket.html)을 참조하세요. 버킷 이름과 버킷을 생성한 AWS 리전을 따로 적어둡니다.
1. **권한** 탭을 선택한 후 **버킷 정책**을 선택합니다.
1. 다음 버킷 정책을 복사하여 정책 편집기에 붙여 넣습니다. *amzn-s3-demo-bucket* 및 *organization-id*를 사용자가 생성한 Amazon S3 버킷 이름 및 유효한 AWS Organizations 계정 ID로 바꿉니다.
원할 경우 *bucket-prefix*를 Amazon S3 접두사(하위 디렉터리) 이름으로 바꿉니다. 접두사를 생성하지 않았을 경우에는 다음 정책의 ARN에서 *bucket-prefix/*를 제거하세요.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "SSMBucketPermissionsCheck",
"Effect": "Allow",
"Principal": {
"Service": "ssm.amazonaws.com"
},
"Action": "s3:GetBucketAcl",
"Resource": "arn:aws:s3:::amzn-s3-demo-bucket"
},
{
"Sid": " SSMBucketDelivery",
"Effect": "Allow",
"Principal": {
"Service": "ssm.amazonaws.com"
},
"Action": "s3:PutObject",
"Resource": [
"arn:aws:s3:::amzn-s3-demo-bucket/bucket-prefix/*/accountid=*/*"
],
"Condition": {
"StringEquals": {
"s3:x-amz-acl": "bucket-owner-full-control",
"aws:SourceOrgID": "organization-id"
}
}
},
{
"Sid": " SSMBucketDeliveryTagging",
"Effect": "Allow",
"Principal": {
"Service": "ssm.amazonaws.com"
},
"Action": "s3:PutObjectTagging",
"Resource": [
"arn:aws:s3:::amzn-s3-demo-bucket/bucket-prefix/*/accountid=*/*"
]
}
]
}
```
------
### AWS Organizations에 정의된 계정에 대한 인벤토리 리소스 데이터 동기화 생성
다음 절차에서는 AWS CLI를 사용하여 AWS Organizations에 정의된 계정에 대한 리소스 데이터 동기화를 만드는 방법을 설명합니다. 이 작업을 수행하려면 AWS CLI를 사용해야 합니다. AWS Organizations에 정의된 AWS 리전과 AWS 계정에 대해서도 각각 이 절차를 수행해야 합니다.
**AWS Organizations(AWS CLI)에 정의된 계정에 대한 리소스 데이터 동기화를 생성하려면**
1. 아직 하지 않은 경우 AWS Command Line Interface(AWS CLI)을 설치하고 구성합니다.
자세한 내용은 [최신 버전의 AWS CLI 설치 또는 업데이트](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html)를 참조하세요.
1. 다음 명령을 실행하여 다른 *AWS Organizations 기반* 리소스 데이터 동기화가 없는지 확인합니다. 여러 표준 동기화 및 Organizations 기반 동기화를 비롯한 다양한 동기화를 사용할 수 있습니다. 그러나 Organizations 기반 리소스 데이터 동기화는 하나만 가질 수 있습니다.
```
aws ssm list-resource-data-sync
```
명령이 다른 Organizations 기반 리소스 데이터 동기화를 반환하는 경우 이를 삭제하거나 새 동기화를 생성하지 않도록 선택해야 합니다.
1. 다음 명령을 실행하여 AWS Organizations에 정의된 계정에 대한 리소스 데이터 동기화를 생성합니다. amzn-s3-demo-bucket에 이 주제의 앞부분에서 생성한 Amazon S3 버킷의 이름을 지정합니다. 버킷의 접두사(하위 디렉터리)를 생성한 경우 *prefix-name*에 이 정보를 지정합니다.
```
aws ssm create-resource-data-sync --sync-name name --s3-destination "BucketName=amzn-s3-demo-bucket,Prefix=prefix-name,SyncFormat=JsonSerDe,Region=AWS 리전, for example us-east-2,DestinationDataSharing={DestinationDataSharingType=Organization}"
```
1. 중앙 Amazon S3 버킷에 데이터를 동기화하려는 모든 AWS 리전 및 AWS 계정에 대해 2단계와 3단계를 반복합니다.
### 리소스 데이터 동기화 관리
각 AWS 계정에서는 AWS 리전당 리소스 데이터 동기화가 5회씩 발생할 수 있습니다. AWS Systems Manager Fleet Manager콘솔을 사용하여 리소스 데이터 동기화를 관리할 수 있습니다.
**리소스 데이터 동기화를 보는 방법**
1. [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)에서 AWS Systems Manager 콘솔을 엽니다.
1. 탐색 창에서 **Fleet Manager**를 선택합니다.
1. **계정 관리** 드롭다운에서 **리소스 데이터 동기화**를 선택합니다.
1. 테이블에서 리소스 데이터 동기화를 선택한 다음에 **세부 정보 보기**를 선택하여 리소스 데이터 동기화에 대한 정보를 봅니다.
**리소스 데이터 동기화 삭제**
1. [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)에서 AWS Systems Manager 콘솔을 엽니다.
1. 탐색 창에서 **Fleet Manager**를 선택합니다.
1. **계정 관리** 드롭다운에서 **리소스 데이터 동기화**를 선택합니다.
1. 테이블에서 리소스 데이터 동기화를 선택한 다음에 **삭제**를 선택합니다.
# EventBridge를 사용한 Inventory 이벤트 모니터링
AWS Systems Manager Inventory 리소스 상태 변경에 대한 응답으로 이벤트를 생성하도록 Amazon EventBridge에서 규칙을 구성할 수 있습니다. EventBridge는 다음과 같은 Inventory 상태 변경에 대한 이벤트를 지원합니다. 모든 이벤트는 최선의 작업을 기반으로 전송됩니다.
**특정 인스턴스에 대해 사용자 정의 인벤토리 유형이 삭제됨**: 이 이벤트를 모니터링하도록 규칙이 구성된 경우 특정 관리형의 사용자 정의 인벤토리 유형이 삭제될 때 EventBridge가 이벤트를 생성합니다. EventBridge는 사용자 정의 인벤토리 유형별로 노드당 하나의 이벤트를 보냅니다. 다음은 샘플 이벤트 패턴입니다.
```
{
"timestampMillis": 1610042981103,
"source": "SSM",
"account": "123456789012",
"type": "INVENTORY_RESOURCE_STATE_CHANGE",
"startTime": "Jan 7, 2021 6:09:41 PM",
"resources": [
{
"arn": "arn:aws:ssm:us-east-1:123456789012:managed-instance/i-12345678"
}
],
"body": {
"action-status": "succeeded",
"action": "delete",
"resource-type": "managed-instance",
"resource-id": "i-12345678",
"action-reason": "",
"type-name": "Custom:MyCustomInventoryType"
}
}
```
**모든 인스턴스에 대한 사용자 정의 인벤토리 유형이 삭제됨**: 이 이벤트를 모니터링하도록 규칙이 구성된 경우 모든 관리형 노드의 사용자 정의 인벤토리 유형이 삭제될 때 EventBridge가 이벤트를 생성합니다. 다음은 샘플 이벤트 패턴입니다.
```
{
"timestampMillis": 1610042904712,
"source": "SSM",
"account": "123456789012",
"type": "INVENTORY_RESOURCE_STATE_CHANGE",
"startTime": "Jan 7, 2021 6:08:24 PM",
"resources": [
],
"body": {
"action-status": "succeeded",
"action": "delete-summary",
"resource-type": "managed-instance",
"resource-id": "",
"action-reason": "The delete for type name Custom:SomeCustomInventoryType was completed. The deletion summary is: {\"totalCount\":1,\"remainingCount\":0,\"summaryItems\":[{\"version\":\"1.1\",\"count\":1,\"remainingCount\":0}]}",
"type-name": "Custom:MyCustomInventoryType"
}
}
```
**이전 스키마 버전으로 [PutInventory](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PutInventory.html) 호출**: 이 이벤트를 모니터링하도록 규칙이 구성된 경우 현재 스키마보다 낮은 스키마 버전을 사용하는 PutInventory 호출이 수행될 때 EventBridge가 이벤트를 생성합니다. 이 이벤트는 모든 인벤토리 유형에 적용됩니다. 다음은 샘플 이벤트 패턴입니다.
```
{
"timestampMillis": 1610042629548,
"source": "SSM",
"account": "123456789012",
"type": "INVENTORY_RESOURCE_STATE_CHANGE",
"startTime": "Jan 7, 2021 6:03:49 PM",
"resources": [
{
"arn": "arn:aws:ssm:us-east-1:123456789012:managed-instance/i-12345678"
}
],
"body": {
"action-status": "failed",
"action": "put",
"resource-type": "managed-instance",
"resource-id": "i-01f017c1b2efbe2bc",
"action-reason": "The inventory item with type name Custom:MyCustomInventoryType was sent with a disabled schema verison 1.0. You must send a version greater than 1.0",
"type-name": "Custom:MyCustomInventoryType"
}
}
```
이러한 이벤트를 모니터링하도록 EventBridge 구성하는 방법에 대한 자세한 내용은 [Systems Manager 이벤트에 대해 EventBridge 구성](monitoring-systems-manager-events.md) 섹션을 참조하세요.
# 인벤토리 수집 구성
이 섹션에서는 Systems Manager 콘솔을 사용하여 관리형 노드 1개 이상에 대한 AWS Systems Manager Inventory 수집을 구성하는 방법에 대해서 설명합니다. AWS Command Line Interface(AWS CLI)를 사용하여 인벤토리 수집을 구성하는 방법의 예는 [AWS CLI를 사용하여 인벤토리 데이터 수집 구성](inventory-collection-cli.md) 섹션을 참조하세요.
인벤토리 수집을 구성할 때 AWS Systems Manager State Manager 연결을 생성하는 것으로 시작합니다. Systems Manager는 연결이 실행될 때 인벤토리 데이터를 수집합니다. 연결을 먼저 생성하지 않고 AWS Systems Manager Run Command 등을 사용하여 `aws:softwareInventory` 플러그 인을 호출하려고 하면 시스템이 다음 오류를 반환합니다. `The aws:softwareInventory plugin can only be invoked via ssm-associate.`
**참고**
관리형 노드에 대해 여러 인벤토리 연결을 만드는 경우 다음 동작을 유의하세요.
각 노드에 *모든* 노드(--targets "Key=InstanceIds,Values=\$1")를 대상으로 하는 인벤토리 연결이 할당될 수 있습니다.
태그 키/값 페어 또는 AWS 리소스 그룹을 사용하는 특정 연결이 각 노드에 할당될 수도 있습니다.
노드에 여러 인벤토리 연결이 할당된 경우 실행되지 않은 연결에 대해 상태가 *건너뜀(Skipped)*으로 표시됩니다. 가장 최근에 실행된 연결은 인벤토리 연결의 실제 상태를 표시합니다.
노드에 여러 인벤토리 연결이 할당되고 각각 태그 키/값 페어를 사용하는 경우 태그 충돌로 인해 해당 인벤토리 연결이 노드에서 실행되지 않습니다. 태그 키/값 충돌이 없는 노드에서 연결이 계속 실행됩니다.
**시작하기 전**
인벤토리 수집을 구성하기 전에 다음 작업을 수행하세요.
+ 인벤토리로 만들고 싶은 노드에서 AWS Systems Manager SSM Agent를 업데이트합니다. SSM Agent 최신 버전을 실행하여 지원되는 모든 인벤토리 유형에 대한 메타데이터를 수집할 수 있는지 확인합니다. SSM Agent를 사용해 State Manager 를 업데이트하는 방법에 대한 자세한 내용은 [연습: AWS CLI를 사용하여 SSM Agent를 자동으로 업데이트](state-manager-update-ssm-agent-cli.md) 섹션을 참조하세요.
+ [하이브리드 및 멀티클라우드](operating-systems-and-machine-types.md#supported-machine-types) 환경의 Amazon Elastic Compute Cloud(Amazon EC2) 인스턴스 및 비 EC2 시스템에 대한 설정 요구 사항을 완료했는지 확인합니다. 자세한 내용은 [AWS Systems Manager에 대한 관리형 노드 설정](systems-manager-setting-up-nodes.md) 섹션을 참조하세요.
+ Microsoft Windows Server 노드의 경우 노드가 Windows PowerShell 3.0 이상으로 구성되었는지 확인합니다. SSM Agent는 PowerShell에서 `ConvertTo-Json` cmdlet을 사용하여 Windows 업데이트 인벤토리 데이터를 필요한 형식으로 변환합니다.
+ (옵션) 리소스 데이터 동기화를 생성하여 Amazon S3 버킷에 인벤토리 데이터를 중앙 집중식으로 저장합니다. 그러면 새 인벤토리 데이터가 수집될 때 리소스 데이터 동기화에 의해 중앙 데이터가 자동으로 업데이트됩니다. 자세한 내용은 [연습: 리소스 데이터 동기화를 사용하여 인벤토리 데이터 집계](inventory-resource-data-sync.md) 섹션을 참조하세요.
+ (선택 사항) JSON 파일을 생성하여 사용자 정의 인벤토리를 수집합니다. 자세한 내용은 [사용자 정의 인벤토리 작업](inventory-custom.md) 섹션을 참조하세요.
## AWS 계정의 모든 관리형 노드에 대한 인벤토리 작성
전역 인벤토리 연결을 생성하면 AWS 계정의 모든 관리형 노드에 대한 인벤토리를 쉽게 작성할 수 있습니다. 전역 인벤토리 연결은 다음 작업을 수행합니다.
+ AWS 계정에 있는 모든 관리형 노드에 전역 인벤토리 구성(연결)을 자동으로 적용합니다. 전역 인벤토리 연결이 적용되어 실행될 경우, 이미 인벤토리 연결이 있는 관리형 노드는 건너뜁니다. 노드를 건너뛰면 `Overridden By Explicit Inventory Association`이라는 자세한 상태 메시지가 표시됩니다. 이러한 노드는 전역 연결에서 건너뛰지만 각자 할당된 인벤토리 연결을 실행할 때는 인벤토리를 보고합니다.
+ AWS 계정에 생성된 새로운 노드를 전역 인벤토리 연결에 자동으로 추가합니다.
**참고**
전역 인벤토리 연결을 구성한 관리형 노드에 특정 연결을 할당하면 Systems Manager Inventory에서 전역 연결의 우선순위를 무시하고 특정 연결을 적용합니다.
전역 인벤토리 연결은 SSM Agent 버전 2.0.790.0 이상에서 사용할 수 있습니다. 노드에서 SSM Agent를 업데이트하는 자세한 방법은 [Run Command를 사용하여 SSM Agent 업데이트](run-command-tutorial-update-software.md#rc-console-agentexample) 섹션을 참조하세요.
### 원클릭 절차로 인벤토리 수집 구성(콘솔)
다음 절차에 따라 AWS 계정 및 단일 AWS 리전의 모든 관리형 노드에 대해 Systems Manager Inventory를 구성합니다.
**Systems Manager Inventory의 현재 리전에서 모든 관리형 노드 구성**
1. [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)에서 AWS Systems Manager 콘솔을 엽니다.
1. 탐색 창에서 [**Inventory**]를 선택합니다.
1. **Managed instances with inventory enabled(인벤토리가 활성화된 관리형 인스턴스)** 카드에서 **Click here to enable inventory on all instances(모든 인스턴스에서 인벤토리를 활성화하려면 여기를 클릭)**를 선택합니다.
![\[모든 관리형 노드에서 Systems Manager Inventory를 활성화하는 중입니다.\]](http://docs.aws.amazon.com/ko_kr/systems-manager/latest/userguide/images/inventory-one-click-1.png)
성공하면 콘솔에 다음 메시지가 표시됩니다.
![\[모든 관리형 노드에서 Systems Manager Inventory를 활성화하는 중입니다.\]](http://docs.aws.amazon.com/ko_kr/systems-manager/latest/userguide/images/inventory-one-click-2.png)
계정에 포함된 관리형 노드 수에 따라 전역 인벤토리 연결이 적용되는 데 몇 분이 걸릴 수 있습니다. 몇 분 동안 기다린 다음 페이지를 새로 고칩니다. 그래픽이 바뀌어 모든 관리형 노드에서 인벤토리가 구성된 것으로 나타내는지 확인합니다.
### 콘솔을 사용하여 수집 구성
이 섹션에는 Systems Manager 콘솔을 사용하여 관리형 노드에서 메타데이터를 수집하도록 Systems Manager Inventory를 구성하는 방법이 나와 있습니다. 특정 AWS 계정의 모든 노드(및 그 계정에서 만들 수 있는 향후의 모든 노드)에서 빠르게 메타데이터를 수집하거나 태그 또는 노드 ID를 사용하여 선택적으로 인벤토리 데이터를 수집할 수 있습니다.
**참고**
이 절차를 완료하기 전에 전역 인벤토리 연결이 이미 존재하는지 확인합니다. 전역 인벤토리 연결이 이미 존재하는 경우 새 인스턴스를 시작할 때마다 연결이 해당 인스턴스에 적용되고 새 인스턴스가 인벤토리에 추가됩니다.
**인벤토리 수집을 구성하려면**
1. [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)에서 AWS Systems Manager 콘솔을 엽니다.
1. 탐색 창에서 [**Inventory**]를 선택합니다.
1. **인벤토리 설정**을 선택합니다.
1. **대상** 섹션에서, 다음 중 하나를 선택하여 이 작업을 실행할 노드를 식별합니다.
+ **이 계정의 모든 관리형 인스턴스 선택** - 이 옵션은 인벤토리 연결이 존재하지 않는 모든 관리형 노드를 선택합니다. 이 옵션을 선택하면 인벤토리 연결이 이미 있는 노드들이 인벤토리 수집에서 무시되고, 인벤토리 결과에 **건너뜀** 상태로 표시됩니다. 자세한 내용은 [AWS 계정의 모든 관리형 노드에 대한 인벤토리 작성](#inventory-management-inventory-all) 섹션을 참조하세요.
+ **태그 지정(Specifying a tag)** - 태그 하나를 지정하여 계정에서 인벤토리를 수집할 노드를 식별하려면 이 옵션을 사용합니다. 태그를 사용하는 경우 그 이후로 이와 동일한 태그를 사용하여 생성되는 노드도 인벤토리를 보고합니다. 모든 노드와 연결된 인벤토리 연결이 존재하는 경우, 태그를 사용하여 특정 노드를 여러 인벤토리에 대한 대상으로 선택하면 **모든 관리형 인스턴스** 대상 그룹의 노드 멤버십을 무시합니다. 지정한 태그를 가진 관리형 노드는 이후에 수행되는 **모든 관리형 인스턴스**의 인벤토리 수집에서 무시됩니다.
+ **수동으로 인스턴스 선택(Manually selecting instances)** - 계정에서 특정 관리형 노드를 선택하려면 이 옵션을 사용합니다. 이 옵션을 사용하여 특정 노드를 명시적으로 선택하면 **모든 관리형 인스턴스** 대상의 인벤토리 연결을 무시합니다. 노드는 이후에 수행되는 **모든 관리형 인스턴스**의 인벤토리 수집에서 무시됩니다.
**참고**
예상한 관리형 노드가 목록에 없으면 [관리형 노드 가용성 문제 해결](fleet-manager-troubleshooting-managed-nodes.md)에서 문제 해결 팁을 참조하세요.
1. **일정** 섹션에서 시스템이 노드로부터 인벤토리 메타데이터를 수집하는 간격을 선택합니다.
1. [**파라미터(Parameters)**] 섹션에서 목록을 사용하여 다양한 유형의 인벤토리 수집을 설정하거나 해제합니다. 파일 및 Windows 레지스트리 인벤토리를 수집하는 방법에 대한 자세한 내용은 [파일 및 Windows 레지스트리 인벤토리 관련 작업](inventory-file-and-registry.md) 섹션을 참조하세요.
1. Amazon S3 버킷에 연결 실행 상태를 저장하고 싶으면 [**고급(Advanced)**] 섹션에서 [**인벤토리 실행 로그를 Amazon S3 버킷에 동기화(Sync inventory execution logs to an Amazon S3 bucket)**]를 선택합니다.
1. **인벤토리 설정**을 선택합니다. Systems Manager가 State Manager 연결을 생성하고 노드에 대해 Inventory를 즉시 실행합니다.
1. 탐색 창에서 **State Manager**를 선택합니다. `AWS-GatherSoftwareInventory` 문서를 사용하는 새로운 연결이 생성되었는지 확인합니다. 연결 일정표는 rate 표현식을 사용합니다. 또한 **상태** 필드에 **성공**이 표시되는지 확인합니다. [**Amazon S3 버킷으로 인벤토리 실행 로그 동기화(Sync inventory execution logs to an Amazon S3 bucket)**] 옵션을 선택하는 경우 몇 분 후 Amazon S3에서 로그 데이터를 볼 수 있습니다. 특정 노드에 대한 인벤토리 데이터를 보려는 경우 탐색 창에서 **관리형 인스턴스**를 선택합니다.
1. 노드를 선택한 후 **세부 정보 보기(View detail)**를 선택합니다.
1. 노드 세부 정보 페이지에서 **인벤토리(Inventory)**를 선택합니다. **인벤토리 유형** 목록을 사용하여 인벤토리를 필터링합니다.
# 여러 리전 및 계정에서 인벤토리 데이터 쿼리
AWS Systems Manager Inventory가 Amazon Athena와 통합되어 여러 AWS 리전 및 AWS 계정에서 인벤터리 데이터를 쿼리하는 데 도움이 됩니다. Athena 통합은 리소스 데이터 동기화를 사용하므로 AWS Systems Manager 콘솔의 **세부 정보 보기** 페이지에서 모든 관리형 노드의 인벤토리 데이터를 볼 수 있습니다.
**중요**
이 기능은 AWS Glue를 사용하여 Amazon Simple Storage Service(Amazon S3) 버킷의 데이터를 크롤링하고 Amazon Athena를 사용하여 데이터를 쿼리합니다. 탐색하는 데이터의 양에 다라 이러한 서비스 사용에 대한 비용이 청구될 수 있습니다. AWS Glue는 시간당 요금제이며, 크롤러(데이터 검색) 및 ETL 작업(데이터 처리 및 로드)의 경우 초 단위로 비용이 청구됩니다. Athena에서는 각 쿼리가 검사한 데이터의 양을 기준으로 요금이 청구됩니다. Systems Manager Inventory와 Amazon Athena의 통합을 사용하기 전에 이러한 서비스에 대한 요금 자침을 확인하는 것이 좋습니다. 자세한 내용은 [Amazon Athena 요금](https://aws.amazon.com/athena/pricing/) 및 [AWS Glue 요금](https://aws.amazon.com/glue/pricing/)을 참조하세요.
Amazon Athena를 사용할 수 있는 모든 AWS 리전의 **세부 정보 보기(Detailed View)** 페이지에서 인벤토리 데이터를 볼 수 있습니다. 지원되는 리전 목록은 **Amazon Web Services 일반 참조의 [Amazon Athena 서비스 엔드포인트](https://docs.aws.amazon.com/general/latest/gr/athena.html#athena_region)를 참조하세요.
**시작하기 전 준비 사항**
Athena 통합은 리소스 데이터 동기화를 사용합니다. 이 기능을 사용하려면 리소스 데이터 동기화를 설정 및 구성해야 합니다. 자세한 내용은 [연습: 리소스 데이터 동기화를 사용하여 인벤토리 데이터 집계](inventory-resource-data-sync.md) 섹션을 참조하세요.
또한 **세부 정보 보기(Detailed View)** 페이지에 리소스 데이터 동기화에서 사용하는 중앙 Amazon S3 버킷의 *소유자*에 대한 인벤토리 데이터가 표시됩니다. 중앙 Amazon S3 버킷의 소유자가 아닌 경우에는 **세부 정보 보기(Detailed View)** 페이지에서 인벤토리 데이터가 표시되지 않습니다.
## 액세스 구성
Systems Manager 콘솔의 **세부 정보 보기** 페이지에서 여러 계정 및 리전의 데이터를 쿼리하고 보려면 먼저 데이터를 볼 수 있는 권한이 있는 IAM 엔터티를 구성해야 합니다.
인벤토리 데이터가 AWS Key Management Service(AWS KMS) 암호화를 사용하는 Amazon S3 버킷에 저장된 경우 AWS KMS 암호화를 위해 IAM 엔터티와 `Amazon-GlueServiceRoleForSSM` 서비스 역할 또한 구성해야 합니다.
**Topics**
+ [세부 정보 보기 페이지에 액세스하도록 IAM 엔터티 구성](#systems-manager-inventory-query-iam-user)
+ [(선택 사항) AWS KMS 암호화 데이터를 볼 수 있는 권한 구성](#systems-manager-inventory-query-kms)
### 세부 정보 보기 페이지에 액세스하도록 IAM 엔터티 구성
다음은 **상세 보기** 페이지에서 인벤토리 데이터를 보는 데 필요한 최소 권한에 대한 설명입니다.
`AWSQuicksightAthenaAccess` 관리형 정책
다음 `PassRole` 및 추가 필수 권한 블록
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowGlue",
"Effect": "Allow",
"Action": [
"glue:GetCrawler",
"glue:GetCrawlers",
"glue:GetTables",
"glue:StartCrawler",
"glue:CreateCrawler"
],
"Resource": "*"
},
{
"Sid": "iamPassRole",
"Effect": "Allow",
"Action": "iam:PassRole",
"Resource": [
"arn:aws:iam::111122223333:role/SSMInventoryGlueRole",
"arn:aws:iam::111122223333:role/SSMInventoryServiceRole"
],
"Condition": {
"StringEquals": {
"iam:PassedToService": "glue.amazonaws.com"
}
}
},
{
"Sid": "iamRoleCreation",
"Effect": "Allow",
"Action": [
"iam:CreateRole",
"iam:AttachRolePolicy"
],
"Resource": "arn:aws:iam::111122223333:role/*"
},
{
"Sid": "iamPolicyCreation",
"Effect": "Allow",
"Action": "iam:CreatePolicy",
"Resource": "arn:aws:iam::111122223333:policy/*"
}
]
}
```
------
(선택 사항) 인벤토리 데이터를 저장하는 데 사용되는 Amazon S3 버킷이 AWS KMS를 사용하여 암호화된 경우 다음 블록도 정책에 추가해야 합니다.
```
{
"Effect": "Allow",
"Action": [
"kms:Decrypt"
],
"Resource": [
"arn:aws:kms:Region:account_ID:key/key_ARN"
]
}
```
액세스 권한을 제공하려면 사용자, 그룹 또는 역할에 권한을 추가하세요.
+ AWS IAM Identity Center의 사용자 및 그룹:
권한 세트를 생성합니다. *AWS IAM Identity Center 사용자 안내서*에서 [권한 세트 생성](https://docs.aws.amazon.com//singlesignon/latest/userguide/howtocreatepermissionset.html)의 지침을 따릅니다.
+ ID 제공업체를 통해 IAM에서 관리되는 사용자:
ID 페더레이션을 위한 역할을 생성합니다. *IAM 사용자 설명서*의 [Create a role for a third-party identity provider (federation)](https://docs.aws.amazon.com//IAM/latest/UserGuide/id_roles_create_for-idp.html)의 지침을 따릅니다.
+ IAM 사용자:
+ 사용자가 맡을 수 있는 역할을 생성합니다. *IAM 사용자 설명서*에서 [Create a role for an IAM user](https://docs.aws.amazon.com//IAM/latest/UserGuide/id_roles_create_for-user.html)의 지침을 따릅니다.
+ (권장되지 않음) 정책을 사용자에게 직접 연결하거나 사용자를 사용자 그룹에 추가합니다. *IAM 사용 설명서*에서 [사용자(콘솔)에 권한 추가](https://docs.aws.amazon.com//IAM/latest/UserGuide/id_users_change-permissions.html#users_change_permissions-add-console)의 지침을 따릅니다.
### (선택 사항) AWS KMS 암호화 데이터를 볼 수 있는 권한 구성
인벤토리 데이터를 저장하는 데 사용되는 Amazon S3 버킷이 AWS Key Management Service(AWS KMS)를 사용하여 암호화된 경우, AWS KMS 키에 대한 `kms:Decrypt` 권한으로 IAM 엔터티 및 **Amazon-GlueServiceRoleForSSM** 역할을 구성해야 합니다.
**시작하기 전 준비 사항**
AWS KMS 키에 대한 `kms:Decrypt` 권한을 제공하려면 IAM 엔터티에 다음 정책 블록을 추가합니다.
```
{
"Effect": "Allow",
"Action": [
"kms:Decrypt"
],
"Resource": [
"arn:aws:kms:Region:account_ID:key/key_ARN"
]
}
```
아직 수행하지 않은 경우 해당 절차를 완료하고 AWS KMS 키에 대해 `kms:Decrypt` 권한을 추가합니다.
다음 절차에 따라 AWS KMS 키에 대한 `kms:Decrypt` 권한으로 **Amazon-GlueServiceRoleForSSM** 역할을 구성합니다.
**`kms:Decrypt` 권한을 가진 **Amazon-GlueServiceRoleForSSM** 역할을 구성하려면**
1. IAM 콘솔([https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/))을 엽니다.
1. 탐색 창에서 **역할(Roles)**을 선택한 다음 검색 필드를 사용하여 **Amazon-GlueServiceRoleForSSM** 역할을 찾습니다. **요약** 페이지가 열립니다.
1. 검색 필드를 사용하여 **Amazon-GlueServiceRoleForSSM** 역할을 찾습니다. 역할 이름을 선택합니다. **요약** 페이지가 열립니다.
1. 역할 이름을 선택합니다. **요약** 페이지가 열립니다.
1. **인라인 정책 추가**를 선택합니다. **정책 생성** 페이지가 열립니다.
1. **JSON** 탭을 선택합니다.
1. 편집기에서 기존 JSON 텍스트를 삭제하고 다음 정책을 복사한 다음 JSON 편집기에 붙여 넣습니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"kms:Decrypt"
],
"Resource": [
"arn:aws:kms:us-east-1:111122223333:key/key_ARN"
]
}
]
}
```
------
1. [**정책 검토(Review policy)**]를 선택합니다.
1. **정책 검토** 페이지에서 **이름** 필드에 이름을 입력합니다.
1. **정책 생성**을 선택합니다.
## 인벤토리 세부 정보 보기(Inventory Detail View) 페이지에서 데이터 쿼리
다음 절차에 따라 Systems Manager Inventory [**세부 정보 뷰(Detailed View)**] 페이지에서 여러 AWS 리전과 AWS 계정의 인벤토리 데이터를 봅니다.
**중요**
Inventory [**세부 정보 뷰(Detailed View)**] 페이지는 Amazon Athena를 제공하는 AWS 리전에서만 사용할 수 있습니다. 다음 탭이 Systems Manager Inventory 페이지에 표시되지 않는 경우 Athena는 리전에서 사용할 수 없으며 **세부 정보 보기(Detailed View)**를 사용하여 데이터를 쿼리할 수 없습니다.
![\[인벤토리 대시보드 | 세부 정보 보기 | 설정 탭 표시\]](http://docs.aws.amazon.com/ko_kr/systems-manager/latest/userguide/images/inventory-detailed-view-for-error.png)
**AWS Systems Manager 콘솔에서 여러 리전과 계정의 인벤토리 데이터를 보려면**
1. [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)에서 AWS Systems Manager 콘솔을 엽니다.
1. 탐색 창에서 [**Inventory**]를 선택합니다.
1. **세부 정보 보기(Detailed View)** 탭을 선택합니다.
![\[AWS Systems Manager 인벤토리 세부 정보 보기 페이지에 액세스\]](http://docs.aws.amazon.com/ko_kr/systems-manager/latest/userguide/images/inventory-detailed-view.png)
1. 데이터를 쿼리할 리소스 데이터 동기화를 선택합니다.
![\[AWS Systems Manager 콘솔에서 인벤토리 데이터 표시\]](http://docs.aws.amazon.com/ko_kr/systems-manager/latest/userguide/images/inventory-display-data.png)
1. **인벤토리 유형** 목록에서 쿼리하려는 인벤토리 데이터의 유형을 선택한 후 Enter를 누릅니다.
![\[AWS Systems Manager 콘솔에서 인벤토리 유형 선택\]](http://docs.aws.amazon.com/ko_kr/systems-manager/latest/userguide/images/inventory-type.png)
1. 데이터를 필터링하려면 필터 막대를 선택한 후 필터 옵션을 선택합니다.
![\[AWS Systems Manager 콘솔에서 인벤토리 데이터 필터링\]](http://docs.aws.amazon.com/ko_kr/systems-manager/latest/userguide/images/inventory-filter.png)
**CSV로 내보내기** 버튼을 사용해 현재 쿼리 세트를 Microsoft Excel 등과 같은 스프레드시트 애플리케이션에서 볼 수 있습니다. [**쿼리 기록(Query History)**] 및 [**고급 쿼리 실행(Run Advanced Queries)**] 버튼을 사용해 Amazon Athena에서 기록 세부 정보를 보고 데이터와 상호 작용할 수도 있습니다.
### AWS Glue 크롤러 예약 편집
AWS Glue는 기본적으로 중앙 Amazon S3 버킷에서 매일 두 번씩 인벤토리 데이터를 크롤링합니다. 노드에서 수집하는 데이터 유형을 자주 변경하는 경우 다음 절차의 설명에 따라 데이터를 더욱 자주 탐색할 수 있습니다.
**중요**
AWS Glue는 AWS 계정에 시간당 요금을 부과하며, 크롤러(데이터 검색) 및 ETL 작업(데이터 처리 및 로드)의 경우 초 단위로 비용이 청구됩니다. 크롤러 일정을 변경하기 전에 [AWS Glue 요금](https://aws.amazon.com/glue/pricing/) 페이지를 확인하세요.
**인벤토리 데이터 크롤러 일정을 변경하려면**
1. [https://console.aws.amazon.com/glue/](https://console.aws.amazon.com/glue/)에서 AWS Glue 콘솔을 엽니다.
1. 탐색 창에서 **크롤러**를 선택합니다.
1. 크롤러 목록에서 Systems Manager Inventory 데이터 크롤러 옆의 옵션을 선택합니다. 크롤러 이름의 형식은 다음과 같습니다.
`AWSSystemsManager-s3-bucket-name-Region-account_ID`
1. **작업**을 선택한 후 **크롤러 편집**을 선택합니다.
1. 탐색 창에서 **일정**을 선택합니다.
1. **Cron 표현식** 필드에서 cron 형식을 사용하여 새 일정을 지정합니다. cron 형식에 대한 자세한 내용은 *AWS Glue 개발자 안내서*의 [크롤러와 작업을 위한 시간 기반 일정](https://docs.aws.amazon.com/glue/latest/dg/monitor-data-warehouse-schedule.html)을 참조하세요.
**중요**
AWS Glue에서 더 이상 요금이 발생하지 않도록 크롤러를 일시 중지할 수 있습니다. 크롤러를 일시 중지하거나 데이터 크롤링 횟수를 줄이도록 빈도를 변경하면 인벤토리 [**세부 정보 뷰(Detailed View)**]에 최신이 아닌 데이터가 표시될 수 있습니다.
# 필터를 사용하여 인벤토리 수집 쿼리
인벤토리 데이터를 수집했으면 AWS Systems Manager의 필터 기능을 사용하여 특정 필터 조건에 맞는 관리형 노드 목록을 쿼리할 수 있습니다.
**인벤토리 필터를 기반으로 노드 쿼리**
1. [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)에서 AWS Systems Manager 콘솔을 엽니다.
1. 탐색 창에서 [**Inventory**]를 선택합니다.
1. **Filter by resource groups, tags or inventory types(리소스 그룹, 태그 또는 인벤토리 유형별로 필터링)** 섹션에서 필터 상자를 선택합니다. 미리 정의된 필터의 목록이 표시됩니다.
1. 필터를 적용할 속성을 선택합니다. 이 예에서는 [`AWS:Application`]을 선택합니다. 메시지가 나타나면 필터를 적용할 두 번째 속성을 선택합니다. 이 예에서는 [`AWS:Application.Name`]을 선택합니다.
1. 목록에서 구분 기호를 선택합니다. 예를 들어 **Begin with(다음으로 시작)**를 선택합니다. 필터에 텍스트 상자가 표시됩니다.
1. 텍스트 상자에 값을 입력합니다. 예를 들어 *Amazon*을 입력합니다(SSM Agent의 이름은 *Amazon SSM Agent*로 지정됨).
1. Enter을 누릅니다. *Amazon*이라는 단어로 시작하는 애플리케이션 이름이 들어 있는 관리형 노드 목록이 반환됩니다.
**참고**
여러 필터를 결합하여 검색 범위를 좁힐 수 있습니다.
# 인벤토리 데이터 집계
AWS Systems Manager 인벤토리용 관리형 노드를 구성한 뒤에는 집계된 인벤토리 데이터 수를 볼 수 있습니다. 예를 들어 `AWS:Application` 인벤토리 유형을 수집하기 위해 관리형 노드를 수십, 수백 개 정도 구성했다고 가정하겠습니다. 그 경우 이 섹션의 정보를 이용하여 이 데이터를 수집하도록 구성된 노드가 몇 개인지 정확한 수를 알아볼 수 있습니다.
데이터 유형으로 집계하여 특정한 인벤토리 세부 정보를 확인할 수도 있습니다. 예를 들어 `AWS:InstanceInformation` 인벤토리 유형은 `Platform` 데이터 형식의 운영 체제 플랫폼 정보를 수집합니다. `Platform` 데이터 형식으로 데이터를 집계함으로써 Windows, Linux, Windows Server 및 macOS를 실행하는 노드가 각각 몇 개인지 빠르게 파악할 수 있습니다.
이 섹션의 절차에서는 AWS Command Line Interface(AWS CLI)를 사용하여 집계된 인벤토리 데이터 수를 보는 방법을 설명합니다. AWS Systems Manager 콘솔의 **인벤토리** 페이지에서 사전 구성된 집계 개수를 볼 수도 있습니다. 이렇게 사전 구성된 대시보드를 *인벤토리 인사이트*라고 부르며, 이를 통해 인벤토리 구성 문제를 클릭 한 번으로 해결할 수 있습니다.
다음은 인벤토리 데이터 집계 개수에 관한 중요한 세부 정보입니다.
+ 인벤토리 데이터를 수집하도록 구성된 관리형 노드를 종료하면 Systems Manager는 인벤토리 데이터를 30일 동안 보관한 다음 삭제합니다. 실행 노드의 경우 30일이 경과한 인벤토리 데이터가 삭제됩니다. 인벤토리 데이터를 30일 이상 저장해야 하는 경우 AWS Config를 사용하여 이력을 기록하거나 정기적으로 데이터를 쿼리하여 Amazon Simple Storage Service(Amazon S3) 버킷에 업로드하면 됩니다.
+ 노드가 이전에 `AWS:Network`와 같이 특정한 인벤토리 데이터 형식을 보고하도록 구성된 경우 나중에 구성을 변경하여 해당 유형의 수집을 중지하도록 하더라도, 해당 노드를 종료하고 30일이 지날 때까지 집계 개수에는 여전히 `AWS:Network` 데이터가 표시됩니다.
특정 AWS 계정의 모든 노드(및 그 계정에서 만들 수 있는 향후의 모든 노드)에서 인벤토리 데이터를 빠르게 구성하고 수집하는 방법에 대한 자세한 내용은 [AWS 계정의 모든 관리형 노드에 대한 인벤토리 작성](inventory-collection.md#inventory-management-inventory-all) 섹션을 참조하세요.
**Topics**
+ [인벤토리 데이터를 집계하여 지정된 유형의 데이터를 수집하는 노드 개수를 확인](#inventory-aggregate-type)
+ [인벤토리 유형을 수집하도록 구성된 노드와 그렇지 않은 노드를 파악하기 위해 인벤토리 데이터를 그룹으로 집계](#inventory-aggregate-groups)
## 인벤토리 데이터를 집계하여 지정된 유형의 데이터를 수집하는 노드 개수를 확인
AWS Systems Manager [GetInventory](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_GetInventory.html) API 작업을 사용하여 하나 이상의 Inventory 유형 및 데이터 형식을 수집하는 노드의 집계 개수를 볼 수 있습니다. 예를 들어 `AWS:InstanceInformation` Inventory 유형을 사용하면 `AWS:InstanceInformation.PlatformType` 데이터 형식과 함께 GetInventory API 작업을 사용하여 운영 체제의 집계를 볼 수 있습니다. 다음은 예 AWS CLI 명령과 출력입니다.
```
aws ssm get-inventory --aggregators "Expression=AWS:InstanceInformation.PlatformType"
```
시스템은 다음과 같은 정보를 반환합니다.
```
{
"Entities":[
{
"Data":{
"AWS:InstanceInformation":{
"Content":[
{
"Count":"7",
"PlatformType":"windows"
},
{
"Count":"5",
"PlatformType":"linux"
}
]
}
}
}
]
}
```
**시작하기**
개수를 보려는 인벤토리 유형과 데이터 유형을 결정합니다. AWS CLI에서 다음 명령을 실행하여 집계가 지원되는 인벤토리 유형 및 데이터 유형의 목록을 볼 수 있습니다.
```
aws ssm get-inventory-schema --aggregator
```
이 명령은 집계가 지원되는 인벤토리 유형 및 데이터 유형의 JSON 목록을 반환합니다. **TypeName** 필드에는 지원되는 인벤토리 유형이 표시됩니다. 그리고 **Name** 필드에는 데이터 유형이 각각 표시됩니다. 예를 들어 아래의 목록에서 `AWS:Application` 인벤토리 유형에는 `Name` 및 `Version` 데이터 형식이 포함됩니다.
```
{
"Schemas": [
{
"TypeName": "AWS:Application",
"Version": "1.1",
"DisplayName": "Application",
"Attributes": [
{
"DataType": "STRING",
"Name": "Name"
},
{
"DataType": "STRING",
"Name": "Version"
}
]
},
{
"TypeName": "AWS:InstanceInformation",
"Version": "1.0",
"DisplayName": "Platform",
"Attributes": [
{
"DataType": "STRING",
"Name": "PlatformName"
},
{
"DataType": "STRING",
"Name": "PlatformType"
},
{
"DataType": "STRING",
"Name": "PlatformVersion"
}
]
},
{
"TypeName": "AWS:ResourceGroup",
"Version": "1.0",
"DisplayName": "ResourceGroup",
"Attributes": [
{
"DataType": "STRING",
"Name": "Name"
}
]
},
{
"TypeName": "AWS:Service",
"Version": "1.0",
"DisplayName": "Service",
"Attributes": [
{
"DataType": "STRING",
"Name": "Name"
},
{
"DataType": "STRING",
"Name": "DisplayName"
},
{
"DataType": "STRING",
"Name": "ServiceType"
},
{
"DataType": "STRING",
"Name": "Status"
},
{
"DataType": "STRING",
"Name": "StartType"
}
]
},
{
"TypeName": "AWS:WindowsRole",
"Version": "1.0",
"DisplayName": "WindowsRole",
"Attributes": [
{
"DataType": "STRING",
"Name": "Name"
},
{
"DataType": "STRING",
"Name": "DisplayName"
},
{
"DataType": "STRING",
"Name": "FeatureType"
},
{
"DataType": "STRING",
"Name": "Installed"
}
]
}
]
}
```
다음 구문을 사용하는 명령을 만들어 목록의 인벤토리 유형에 대한 데이터를 집계할 수 있습니다.
```
aws ssm get-inventory --aggregators "Expression=InventoryType.DataType"
```
여기 몇 가지 예가 있습니다.
**예제 1**.
이 예에서는 해당 노드에서 사용하는 Windows 역할 개수를 집계합니다.
```
aws ssm get-inventory --aggregators "Expression=AWS:WindowsRole.Name"
```
**예제 2**.
이 예에서는 해당 노드에 설치된 애플리케이션 개수를 집계합니다.
```
aws ssm get-inventory --aggregators "Expression=AWS:Application.Name"
```
**여러 집계자 결합**
명령 하나에 여러 가지 인벤토리 유형과 데이터 유형을 결합하면 데이터를 더 잘 이해할 수 있습니다. 여기 몇 가지 예가 있습니다.
**예제 1**.
이 예에서는 해당 노드에서 사용하는 운영 체제 유형의 개수를 집계합니다. 또한 운영 체제의 구체적인 이름도 반환합니다.
```
aws ssm get-inventory --aggregators '[{"Expression": "AWS:InstanceInformation.PlatformType", "Aggregators":[{"Expression": "AWS:InstanceInformation.PlatformName"}]}]'
```
**예제 2**.
이 예에서는 해당 노드에서 실행 중인 애플리케이션 개수와 각 애플리케이션의 특정 버전을 집계합니다.
```
aws ssm get-inventory --aggregators '[{"Expression": "AWS:Application.Name", "Aggregators":[{"Expression": "AWS:Application.Version"}]}]'
```
원한다면 하나 이상의 인벤토리 유형과 데이터 유형으로 된 집계 표현식을 JSON 파일로 만들고 AWS CLI에서 그 파일을 호출할 수 있습니다. 이 파일의 JSON은 다음 구문을 사용해야 합니다.
```
[
{
"Expression": "string",
"Aggregators": [
{
"Expression": "string"
}
]
}
]
```
.json 파일 확장자로 파일을 저장해야 합니다.
다음은 여러 가지 인벤토리 유형과 데이터 유형을 사용하는 예제입니다.
```
[
{
"Expression": "AWS:Application.Name",
"Aggregators": [
{
"Expression": "AWS:Application.Version",
"Aggregators": [
{
"Expression": "AWS:InstanceInformation.PlatformType"
}
]
}
]
}
]
```
다음 명령을 사용하여 AWS CLI에서 해당 파일을 호출합니다.
```
aws ssm get-inventory --aggregators file://file_name.json
```
명령은 다음과 같은 정보를 반환합니다.
```
{"Entities":
[
{"Data":
{"AWS:Application":
{"Content":
[
{"Count": "3",
"PlatformType": "linux",
"Version": "2.6.5",
"Name": "audit-libs"},
{"Count": "2",
"PlatformType": "windows",
"Version": "2.6.5",
"Name": "audit-libs"},
{"Count": "4",
"PlatformType": "windows",
"Version": "6.2.8",
"Name": "microsoft office"},
{"Count": "2",
"PlatformType": "windows",
"Version": "2.6.5",
"Name": "chrome"},
{"Count": "1",
"PlatformType": "linux",
"Version": "2.6.5",
"Name": "chrome"},
{"Count": "2",
"PlatformType": "linux",
"Version": "6.3",
"Name": "authconfig"}
]
}
},
"ResourceType": "ManagedInstance"}
]
}
```
## 인벤토리 유형을 수집하도록 구성된 노드와 그렇지 않은 노드를 파악하기 위해 인벤토리 데이터를 그룹으로 집계
Systems Manager Inventory의 그룹으로 관리형 노드 중 하나 이상의 Inventory 유형을 수집하도록 구성된 인스턴스 수와 그렇지 않은 인스턴스 수를 빠르게 파악할 수 있습니다. 그룹을 통해 하나 이상의 인벤토리 유형과 `exists` 연산자를 사용하는 필터를 지정합니다.
예를 들어, 다음 인벤토리 유형을 수집하도록 구성한 관리형 노드가 4개 있다고 가정하겠습니다.
+ 노드 1: `AWS:Application`
+ 노드 2: `AWS:File`
+ 노드 3: `AWS:Application`, `AWS:File`
+ 노드 4: `AWS:Network`
AWS CLI에서 다음 명령을 실행하여 `AWS:Application`과 `AWS:File inventory` 인벤토리 유형을 둘 다 수집하도록 구성된 노드가 몇 개인지 확인할 수 있습니다. 응답에는 이러한 두 가지 인벤토리 유형을 모두 수집하도록 구성되지 않은 노드 개수도 반환됩니다.
```
aws ssm get-inventory --aggregators 'Groups=[{Name=ApplicationAndFile,Filters=[{Key=TypeName,Values=[AWS:Application],Type=Exists},{Key=TypeName,Values=[AWS:File],Type=Exists}]}]'
```
명령의 응답은 `AWS:Application` 및 `AWS:File` 인벤토리 유형을 둘 다 수집하도록 구성된 관리형 노드가 하나뿐임을 보여줍니다.
```
{
"Entities":[
{
"Data":{
"ApplicationAndFile":{
"Content":[
{
"notMatchingCount":"3"
},
{
"matchingCount":"1"
}
]
}
}
}
]
}
```
**참고**
그룹은 데이터 유형 개수를 반환하지 않습니다. 또한 결과를 심층 분석하여 인벤토리 유형을 수집하도록 구성된 노드와 그렇지 않은 노드 ID를 파악할 수도 없습니다.
원한다면 하나 이상의 인벤토리 유형으로 된 집계 표현식을 JSON 파일로 만들고 AWS CLI에서 그 파일을 호출할 수 있습니다. 이 파일의 JSON은 다음 구문을 사용해야 합니다.
```
{
"Aggregators":[
{
"Groups":[
{
"Name":"Name",
"Filters":[
{
"Key":"TypeName",
"Values":[
"Inventory_type"
],
"Type":"Exists"
},
{
"Key":"TypeName",
"Values":[
"Inventory_type"
],
"Type":"Exists"
}
]
}
]
}
]
}
```
.json 파일 확장자로 파일을 저장해야 합니다.
다음 명령을 사용하여 AWS CLI에서 해당 파일을 호출합니다.
```
aws ssm get-inventory --cli-input-json file://file_name.json
```
**추가 예제**
다음 예에서는 지정된 인벤토리 유형을 수집하도록 구성된 관리형 노드와 그렇지 않은 노드를 파악하기 위해 인벤토리 데이터를 집계하는 방법을 보여줍니다. 이 예제에서는 AWS CLI를 사용합니다. 각 예제에 전체 명령과 필터가 나와 있으므로 정보를 파일에 입력하는 방법을 선호한다면 명령줄에서 이 명령과 샘플 input.json 파일을 실행하면 됩니다.
**예제 1**.
이 예에서는 `AWS:Application` 또는 `AWS:File` 인벤토리 유형을 수집하도록 구성된 노드와 그렇지 않은 노드의 개수를 집계합니다.
AWS CLI에서 다음 명령을 실행합니다.
```
aws ssm get-inventory --aggregators 'Groups=[{Name=ApplicationORFile,Filters=[{Key=TypeName,Values=[AWS:Application, AWS:File],Type=Exists}]}]'
```
파일을 사용하려면 다음 샘플을 복사하여 파일에 붙여 넣은 다음 이 파일을 input.json으로 저장합니다.
```
{
"Aggregators":[
{
"Groups":[
{
"Name":"ApplicationORFile",
"Filters":[
{
"Key":"TypeName",
"Values":[
"AWS:Application",
"AWS:File"
],
"Type":"Exists"
}
]
}
]
}
]
}
```
AWS CLI에서 다음 명령을 실행합니다.
```
aws ssm get-inventory --cli-input-json file://input.json
```
명령은 다음과 같은 정보를 반환합니다.
```
{
"Entities":[
{
"Data":{
"ApplicationORFile":{
"Content":[
{
"notMatchingCount":"1"
},
{
"matchingCount":"3"
}
]
}
}
}
]
}
```
**예제 2**.
이 예에서는 `AWS:Application`, `AWS:File` 및 `AWS:Network` 인벤토리 유형을 수집하도록 구성된 노드와 그렇지 않은 노드의 개수를 집계합니다.
AWS CLI에서 다음 명령을 실행합니다.
```
aws ssm get-inventory --aggregators 'Groups=[{Name=Application,Filters=[{Key=TypeName,Values=[AWS:Application],Type=Exists}]}, {Name=File,Filters=[{Key=TypeName,Values=[AWS:File],Type=Exists}]}, {Name=Network,Filters=[{Key=TypeName,Values=[AWS:Network],Type=Exists}]}]'
```
파일을 사용하려면 다음 샘플을 복사하여 파일에 붙여 넣은 다음 이 파일을 input.json으로 저장합니다.
```
{
"Aggregators":[
{
"Groups":[
{
"Name":"Application",
"Filters":[
{
"Key":"TypeName",
"Values":[
"AWS:Application"
],
"Type":"Exists"
}
]
},
{
"Name":"File",
"Filters":[
{
"Key":"TypeName",
"Values":[
"AWS:File"
],
"Type":"Exists"
}
]
},
{
"Name":"Network",
"Filters":[
{
"Key":"TypeName",
"Values":[
"AWS:Network"
],
"Type":"Exists"
}
]
}
]
}
]
}
```
AWS CLI에서 다음 명령을 실행합니다.
```
aws ssm get-inventory --cli-input-json file://input.json
```
명령은 다음과 같은 정보를 반환합니다.
```
{
"Entities":[
{
"Data":{
"Application":{
"Content":[
{
"notMatchingCount":"2"
},
{
"matchingCount":"2"
}
]
},
"File":{
"Content":[
{
"notMatchingCount":"2"
},
{
"matchingCount":"2"
}
]
},
"Network":{
"Content":[
{
"notMatchingCount":"3"
},
{
"matchingCount":"1"
}
]
}
}
}
]
}
```
# 사용자 정의 인벤토리 작업
AWS Systems Manager Inventory *사용자 정의 인벤토리*를 생성하여 원하는 메타데이터를 노드에 할당할 수 있습니다. 예를 들어 데이터 센터에서 여러 랙에 다수의 서버를 설치하여 관리하고 있으며, 이 서버들은 Systems Manager 관리형 노드로 구성되었다고 가정하겠습니다. 현재는 서버 랙 위치에 대한 정보를 스프레드시트에 저장하고 있습니다. 하지만 사용자 정의 인벤토리를 사용하면 각 노드의 랙 위치를 노드에 대한 메타데이터로 지정할 수 있습니다. Systems Manager를 사용하여 인벤토리를 수집할 경우에는 메타데이터가 다른 인벤토리 메타데이터와 함께 수집됩니다. 그런 다음 [리소스 데이터 동기화](inventory-resource-data-sync.html)를 사용하여 모든 인벤토리 메타데이터를 중앙 Amazon S3 버킷으로 포팅하고 데이터를 쿼리할 수 있습니다.
**참고**
Systems Manager는 AWS 계정당 최대 20개의 사용자 정의 인벤토리 유형을 지원합니다.
노드에 사용자 정의 인벤토리를 할당하려면 [관리형 노드에 사용자 지정 인벤토리 메타데이터 할당](inventory-custom-metadata.md)에 설명된 대로 Systems Manager [PutInventory](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PutInventory.html) API 작업을 사용할 수 있습니다. 아니면, 사용자 정의 인벤토리 JSON 파일을 생성하여 노드에 업로드하는 방법이 있습니다. 이번 단원에서는 JSON 파일을 생성하는 방법에 대해서 설명합니다.
다음 예제 JSON 파일은 온프레미스 서버의 랙 정보를 지정하는 사용자 지정 인벤토리를 포함하고 있습니다. 이 예제는 `Content` 아래에 데이터를 설명하는 여러 항목을 포함하는 한 사용자 지정 인벤토리 데이터 형식(`"TypeName": "Custom:RackInformation"`)을 지정합니다.
```
{
"SchemaVersion": "1.0",
"TypeName": "Custom:RackInformation",
"Content": {
"Location": "US-EAST-02.CMH.RACK1",
"InstalledTime": "2016-01-01T01:01:01Z",
"vendor": "DELL",
"Zone" : "BJS12",
"TimeZone": "UTC-8"
}
}
```
다음 예제에 나온 것처럼 `Content` 섹션에 개별 항목을 지정할 수도 있습니다.
```
{
"SchemaVersion": "1.0",
"TypeName": "Custom:PuppetModuleInfo",
"Content": [{
"Name": "puppetlabs/aws",
"Version": "1.0"
},
{
"Name": "puppetlabs/dsc",
"Version": "2.0"
}
]
}
```
사용자 정의 인벤토리에 사용되는 JSON 스키마는 `SchemaVersion` `TypeName` 및 `Content` 섹션이 필요하지만 이 섹션의 정보를 정의할 수 있습니다.
```
{
"SchemaVersion": "user_defined",
"TypeName": "Custom:user_defined",
"Content": {
"user_defined_attribute1": "user_defined_value1",
"user_defined_attribute2": "user_defined_value2",
"user_defined_attribute3": "user_defined_value3",
"user_defined_attribute4": "user_defined_value4"
}
}
```
`TypeName` 값은 100자로 제한됩니다. 또한 `TypeName` 값은 대문자로 된 `Custom` 단어로 시작해야 합니다. 예를 들어 `Custom:PuppetModuleInfo`입니다. 따라서 이 예시(`CUSTOM:PuppetModuleInfo`, `custom:PuppetModuleInfo`)에서는 예외가 발생합니다.
`Content` 섹션에는 속성과 *data*가 포함됩니다. 이들 항목은 대/소문자를 구분하지 않습니다. 하지만 속성을 정의하는 경우에는(예: "`Vendor`": "DELL") 사용자 정의 인벤토리 파일에서 이 속성을 일관적으로 참조해야 합니다. 한 파일에서 "`Vendor`": "DELL"(`vendor`에서 대문자 “V” 사용)을 지정한 다음 다른 파일에서 "`vendor`": "DELL"(`vendor`에서 소문자 “v” 사용)을 지정하면 시스템이 오류 메시지를 반환합니다.
**참고**
파일을 `.json` 확장자로 저장해야 하며 정의한 인벤토리는 문자열 값으로만 구성되어야 합니다.
파일을 생성한 후에는 노드에 저장해야 합니다. 다음은 노드에서 사용자 정의 인벤토리 JSON 파일을 저장해야 하는 위치를 나타낸 표입니다.
****
| 운영 체제 | 경로 |
| --- | --- |
| Linux | /var/lib/amazon/ssm/*node-id*/inventory/custom |
| macOS | `/opt/aws/ssm/data/node-id/inventory/custom` |
| Windows Server | %SystemDrive%\$1ProgramData\$1Amazon\$1SSM\$1InstanceData\$1*node-id*\$1inventory\$1custom |
사용자 지정 인벤토리를 사용하는 방법의 예제는 [EC2 Systems Manager 사용자 지정 인벤토리 유형을 사용하여 플릿의 디스크 사용률 얻기](https://aws.amazon.com/blogs/mt/get-disk-utilization-of-your-fleet-using-ec2-systems-manager-custom-inventory-types/)를 참조하십시오.
## 사용자 지정 인벤토리 삭제
[DeleteInventory](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_DeleteInventory.html) API 작업을 사용하여 사용자 정의 Inventory 유형 및 해당 유형과 연결된 데이터를 삭제할 수 있습니다. AWS Command Line Interface(AWS CLI)를 사용하여 delete-inventory 명령을 호출함으로써 인벤토리 유형의 모든 데이터를 삭제합니다. `SchemaDeleteOption`과 함께 delete-inventory 명령을 호출하여 사용자 지정 인벤토리 유형을 삭제합니다.
**참고**
인벤토리 유형을 인벤토리 스키마라고도 합니다.
`SchemaDeleteOption` 파라미터에는 다음과 같은 옵션이 있습니다.
+ **DeleteSchema**: 이 옵션은 지정한 사용자 지정 유형 및 해당 유형과 연결된 모든 데이터를 삭제합니다. 원한다면 나중에 스키마를 다시 만들 수 있습니다.
+ [**DisableSchema**]: 이 옵션을 선택하면 시스템에서 현재 버전을 해제하고, 현재 버전에 대한 모든 데이터를 삭제하고, 해당 버전이 해제된 버전과 같거나 이전 버전일 경우 새 데이터를 모두 무시합니다. 해제된 버전보다 높은 버전에 대해 [PutInventory](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PutInventory.html) 작업을 호출함으로써 이 Inventory 유형을 다시 허용할 수 있습니다.
**AWS CLI를 사용하여 사용자 정의 인벤토리를 삭제하거나 해제하려면**
1. 아직 하지 않은 경우 AWS Command Line Interface(AWS CLI)을 설치하고 구성합니다.
자세한 내용은 [최신 버전의 AWS CLI 설치 또는 업데이트](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html)를 참조하세요.
1. `dry-run` 옵션으로 시스템에서 삭제할 데이터를 확인하려면 다음 명령을 실행하십시오. 이 명령은 어떤 데이터도 삭제하지 않습니다.
```
aws ssm delete-inventory --type-name "Custom:custom_type_name" --dry-run
```
시스템은 다음과 같은 정보를 반환합니다.
```
{
"DeletionSummary":{
"RemainingCount":3,
"SummaryItems":[
{
"Count":2,
"RemainingCount":2,
"Version":"1.0"
},
{
"Count":1,
"RemainingCount":1,
"Version":"2.0"
}
],
"TotalCount":3
},
"TypeName":"Custom:custom_type_name"
}
```
인벤토리 삭제 요약을 이해하는 방법은 [인벤토리 삭제 요약 이해하기](#delete-custom-inventory-summary) 섹션을 참조하세요.
1. 다음 명령을 실행하여 사용자 지정 인벤토리 유형의 데이터를 모두 삭제합니다.
```
aws ssm delete-inventory --type-name "Custom:custom_type_name"
```
**참고**
이 명령의 출력에는 삭제 진행 상황이 표시되지 않습니다. 그러므로 [총 개수(TotalCount)]와 [남은 개수(Remaining Count)]는 항상 동일합니다. 아직 아무것도 삭제되지 않았기 때문입니다. 이 주제 후반부에서 설명하는 방법으로 describe-inventory-deletions 명령을 사용하여 삭제 진행 상황을 표시할 수 있습니다.
시스템은 다음과 같은 정보를 반환합니다.
```
{
"DeletionId":"system_generated_deletion_ID",
"DeletionSummary":{
"RemainingCount":3,
"SummaryItems":[
{
"Count":2,
"RemainingCount":2,
"Version":"1.0"
},
{
"Count":1,
"RemainingCount":1,
"Version":"2.0"
}
],
"TotalCount":3
},
"TypeName":"custom_type_name"
}
```
그러면 Systems Manager Inventory 서비스에서 지정된 사용자 정의 Inventory 유형의 데이터가 모두 삭제됩니다.
1. 다음 명령을 실행합니다. 이 명령은 현재 버전을 해제하고, 해당하는 데이터를 모두 삭제하고, 해제된 버전 이하의 버전에서는 신규 데이터를 모두 무시하는 등의 작업을 현재 버전의 인벤토리 유형에 대해 수행합니다.
```
aws ssm delete-inventory --type-name "Custom:custom_type_name" --schema-delete-option "DisableSchema"
```
시스템은 다음과 같은 정보를 반환합니다.
```
{
"DeletionId":"system_generated_deletion_ID",
"DeletionSummary":{
"RemainingCount":3,
"SummaryItems":[
{
"Count":2,
"RemainingCount":2,
"Version":"1.0"
},
{
"Count":1,
"RemainingCount":1,
"Version":"2.0"
}
],
"TotalCount":3
},
"TypeName":"Custom:custom_type_name"
}
```
다음 명령으로 해제된 인벤토리 유형을 볼 수 있습니다.
```
aws ssm get-inventory-schema --type-name Custom:custom_type_name
```
1. 다음 명령을 실행하여 인벤토리 유형을 삭제합니다.
```
aws ssm delete-inventory --type-name "Custom:custom_type_name" --schema-delete-option "DeleteSchema"
```
지정된 사용자 지정 유형의 스키마와 인벤토리 데이터가 모두 삭제됩니다.
시스템은 다음과 같은 정보를 반환합니다.
```
{
"DeletionId":"system_generated_deletion_ID",
"DeletionSummary":{
"RemainingCount":3,
"SummaryItems":[
{
"Count":2,
"RemainingCount":2,
"Version":"1.0"
},
{
"Count":1,
"RemainingCount":1,
"Version":"2.0"
}
],
"TotalCount":3
},
"TypeName":"Custom:custom_type_name"
}
```
### 삭제 상태 보기
`describe-inventory-deletions` AWS CLI 명령으로 삭제 작업의 상태를 확인할 수 있습니다. 특정한 삭제 작업의 상태를 보려면 삭제 ID를 지정하십시오. 아니면 삭제 ID를 생략하고 최근 30일간 실행된 전체 삭제 작업 목록을 볼 수도 있습니다.
****
1. 다음 명령을 실행하여 삭제 작업의 상태를 확인합니다. 시스템에서는 delete-inventory 요약을 통해 삭제 ID를 반환했습니다.
```
aws ssm describe-inventory-deletions --deletion-id system_generated_deletion_ID
```
시스템에서 최신 상태를 반환합니다. 삭제 작업이 아직 종료되지 않았을 수 있습니다. 시스템은 다음과 같은 정보를 반환합니다.
```
{"InventoryDeletions":
[
{"DeletionId": "system_generated_deletion_ID",
"DeletionStartTime": 1521744844,
"DeletionSummary":
{"RemainingCount": 1,
"SummaryItems":
[
{"Count": 1,
"RemainingCount": 1,
"Version": "1.0"}
],
"TotalCount": 1},
"LastStatus": "InProgress",
"LastStatusMessage": "The Delete is in progress",
"LastStatusUpdateTime": 1521744844,
"TypeName": "Custom:custom_type_name"}
]
}
```
삭제 작업이 성공하면 `LastStatusMessage` 상태: 삭제 성공이 반환됩니다.
```
{"InventoryDeletions":
[
{"DeletionId": "system_generated_deletion_ID",
"DeletionStartTime": 1521744844,
"DeletionSummary":
{"RemainingCount": 0,
"SummaryItems":
[
{"Count": 1,
"RemainingCount": 0,
"Version": "1.0"}
],
"TotalCount": 1},
"LastStatus": "Complete",
"LastStatusMessage": "Deletion is successful",
"LastStatusUpdateTime": 1521745253,
"TypeName": "Custom:custom_type_name"}
]
}
```
1. 다음 명령을 실행하여 최근 30일간 실행된 전체 삭제 작업 목록을 볼 수도 있습니다.
```
aws ssm describe-inventory-deletions --max-results a number
```
```
{"InventoryDeletions":
[
{"DeletionId": "system_generated_deletion_ID",
"DeletionStartTime": 1521682552,
"DeletionSummary":
{"RemainingCount": 0,
"SummaryItems":
[
{"Count": 1,
"RemainingCount": 0,
"Version": "1.0"}
],
"TotalCount": 1},
"LastStatus": "Complete",
"LastStatusMessage": "Deletion is successful",
"LastStatusUpdateTime": 1521682852,
"TypeName": "Custom:custom_type_name"},
{"DeletionId": "system_generated_deletion_ID",
"DeletionStartTime": 1521744844,
"DeletionSummary":
{"RemainingCount": 0,
"SummaryItems":
[
{"Count": 1,
"RemainingCount": 0,
"Version": "1.0"}
],
"TotalCount": 1},
"LastStatus": "Complete",
"LastStatusMessage": "Deletion is successful",
"LastStatusUpdateTime": 1521745253,
"TypeName": "Custom:custom_type_name"},
{"DeletionId": "system_generated_deletion_ID",
"DeletionStartTime": 1521680145,
"DeletionSummary":
{"RemainingCount": 0,
"SummaryItems":
[
{"Count": 1,
"RemainingCount": 0,
"Version": "1.0"}
],
"TotalCount": 1},
"LastStatus": "Complete",
"LastStatusMessage": "Deletion is successful",
"LastStatusUpdateTime": 1521680471,
"TypeName": "Custom:custom_type_name"}
],
"NextToken": "next-token"
```
### 인벤토리 삭제 요약 이해하기
인벤토리 삭제 요약을 이해하려면 다음 예제를 생각해 보십시오. 사용자가 노드 세 개에 Custom:RackSpace 인벤토리를 할당했습니다. 인벤토리 항목 1과 2는 사용자 지정 유형 버전 1.0을 사용합니다("SchemaVersion":"1.0"). 인벤토리 항목 3은 사용자 지정 유형 버전 2.0을 사용합니다("SchemaVersion":"2.0").
RackSpace 사용자 지정 인벤토리 1
```
{
"CaptureTime":"2018-02-19T10:48:55Z",
"TypeName":"CustomType:RackSpace",
"InstanceId":"i-1234567890",
"SchemaVersion":"1.0" "Content":[
{
content of custom type omitted
}
]
}
```
RackSpace 사용자 지정 인벤토리 2
```
{
"CaptureTime":"2018-02-19T10:48:55Z",
"TypeName":"CustomType:RackSpace",
"InstanceId":"i-1234567891",
"SchemaVersion":"1.0" "Content":[
{
content of custom type omitted
}
]
}
```
RackSpace 사용자 지정 인벤토리 3
```
{
"CaptureTime":"2018-02-19T10:48:55Z",
"TypeName":"CustomType:RackSpace",
"InstanceId":"i-1234567892",
"SchemaVersion":"2.0" "Content":[
{
content of custom type omitted
}
]
}
```
사용자는 다음 명령을 실행하여 삭제할 데이터를 미리 봅니다.
```
aws ssm delete-inventory --type-name "Custom:RackSpace" --dry-run
```
시스템은 다음과 같은 정보를 반환합니다.
```
{
"DeletionId":"1111-2222-333-444-66666",
"DeletionSummary":{
"RemainingCount":3,
"TotalCount":3,
TotalCount and RemainingCount are the number of items that would be deleted if this was not a dry run. These numbers are the same because the system didn't delete anything.
"SummaryItems":[
{
"Count":2, The system found two items that use SchemaVersion 1.0. Neither item was deleted.
"RemainingCount":2,
"Version":"1.0"
},
{
"Count":1, The system found one item that uses SchemaVersion 1.0. This item was not deleted.
"RemainingCount":1,
"Version":"2.0"
}
],
},
"TypeName":"Custom:RackSpace"
}
```
사용자는 다음 명령을 실행하여 Custom:RackSpace 인벤토리를 삭제합니다.
**참고**
이 명령의 출력에는 삭제 진행 상황이 표시되지 않습니다. 그러므로 `TotalCount`와 `RemainingCount`는 항상 동일합니다. 아직 아무것도 삭제되지 않았기 때문입니다. `describe-inventory-deletions` 명령을 사용하여 삭제 진행 상황을 표시합니다.
```
aws ssm delete-inventory --type-name "Custom:RackSpace"
```
시스템은 다음과 같은 정보를 반환합니다.
```
{
"DeletionId":"1111-2222-333-444-7777777",
"DeletionSummary":{
"RemainingCount":3, There are three items to delete
"SummaryItems":[
{
"Count":2, The system found two items that use SchemaVersion 1.0.
"RemainingCount":2,
"Version":"1.0"
},
{
"Count":1, The system found one item that uses SchemaVersion 2.0.
"RemainingCount":1,
"Version":"2.0"
}
],
"TotalCount":3
},
"TypeName":"RackSpace"
}
```
### EventBridge에서 인벤토리 삭제 작업 보기
사용자가 사용자 정의 인벤토리를 삭제할 때마다 이벤트를 생성하도록 Amazon EventBridge를 구성할 수 있습니다. EventBridge는 사용자 정의 인벤토리 삭제 작업에 대해 다음과 같은 3가지 유형의 이벤트를 제공합니다.
+ **Delete action for an instance(인스턴스에 대한 삭제 작업)**: 지정된 관리형 노드에 대한 사용자 지정 인벤토리가 무사히 삭제되었는지 여부.
+ **Delete action summary(삭제 작업 요약)**: 삭제 작업의 요약.
+ [**해제된 사용자 정의 Inventory 유형 경고(Warning for turned off custom inventory type)**]: 이전에 해제한 사용자 정의 Inventory 유형 버전에 [PutInventory](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PutInventory.html) API 작업을 호출할 경우 등장하는 경고 이벤트.
다음은 각 이벤트의 예입니다.
**Delete action for an instance(인스턴스에 대한 삭제 작업)**
```
{
"version":"0",
"id":"998c9cde-56c0-b38b-707f-0411b3ff9d11",
"detail-type":"Inventory Resource State Change",
"source":"aws.ssm",
"account":"478678815555",
"time":"2018-05-24T22:24:34Z",
"region":"us-east-1",
"resources":[
"arn:aws:ssm:us-east-1:478678815555:managed-instance/i-0a5feb270fc3f0b97"
],
"detail":{
"action-status":"succeeded",
"action":"delete",
"resource-type":"managed-instance",
"resource-id":"i-0a5feb270fc3f0b97",
"action-reason":"",
"type-name":"Custom:MyInfo"
}
}
```
**Delete action summary(삭제 작업 요약)**
```
{
"version":"0",
"id":"83898300-f576-5181-7a67-fb3e45e4fad4",
"detail-type":"Inventory Resource State Change",
"source":"aws.ssm",
"account":"478678815555",
"time":"2018-05-24T22:28:25Z",
"region":"us-east-1",
"resources":[
],
"detail":{
"action-status":"succeeded",
"action":"delete-summary",
"resource-type":"managed-instance",
"resource-id":"",
"action-reason":"The delete for type name Custom:MyInfo was completed. The deletion summary is: {\"totalCount\":2,\"remainingCount\":0,\"summaryItems\":[{\"version\":\"1.0\",\"count\":2,\"remainingCount\":0}]}",
"type-name":"Custom:MyInfo"
}
}
```
**해제된 사용자 정의 인벤토리 유형 경고**
```
{
"version":"0",
"id":"49c1855c-9c57-b5d7-8518-b64aeeef5e4a",
"detail-type":"Inventory Resource State Change",
"source":"aws.ssm",
"account":"478678815555",
"time":"2018-05-24T22:46:58Z",
"region":"us-east-1",
"resources":[
"arn:aws:ssm:us-east-1:478678815555:managed-instance/i-0ee2d86a2cfc371f6"
],
"detail":{
"action-status":"failed",
"action":"put",
"resource-type":"managed-instance",
"resource-id":"i-0ee2d86a2cfc371f6",
"action-reason":"The inventory item with type name Custom:MyInfo was sent with a disabled schema version 1.0. You must send a version greater than 1.0",
"type-name":"Custom:MyInfo"
}
}
```
사용자 정의 인벤토리 삭제 작업에 EventBridge 규칙을 생성하려면 다음 절차를 따릅니다. 이 절차는 사용자 정의 인벤토리 삭제 작업에 대한 알림을 Amazon SNS 주제에 전송하도록 규칙을 생성하는 방법입니다. 시작하기 전에 Amazon SNS 주제가 있는지 확인하고 없으면 새로 생성합니다. 자세한 내용은 *Amazon Simple Notification Service Developer Guide*의 [Getting Started](https://docs.aws.amazon.com/sns/latest/dg/GettingStarted.html)를 참조하세요.
**인벤토리 삭제 작업에 EventBridge를 구성하려면**
1. [https://console.aws.amazon.com/events/](https://console.aws.amazon.com/events/)에서 Amazon EventBridge 콘솔을 엽니다.
1. 탐색 창에서 **규칙**을 선택합니다.
1. **규칙 생성**을 선택합니다.
1. 규칙에 대해 이름과 설명을 입력하세요.
규칙은 동일한 리전과 동일한 이벤트 버스의 다른 규칙과 동일한 이름을 가질 수 없습니다.
1. **이벤트 버스**에서 이 규칙과 연결할 이벤트 버스를 선택합니다. 이 규칙이 자신의 AWS 계정에서 오는 일치하는 이벤트에 응답하도록 하려면 **default**(기본)를 선택합니다. 계정의 AWS 서비스이(가) 이벤트를 출력하면 항상 계정의 기본 이벤트 버스로 이동합니다.
1. **규칙 유형**에서 **이벤트 패턴이 있는 규칙**을 선택합니다.
1. **다음**을 선택합니다.
1. **이벤트 소스(Event source)**에서 **AWS 이벤트 또는 EventBridge 파트너 이벤트(Events or EventBridge partner events)**를 선택합니다.
1. **이벤트 패턴(Event pattern)**섹션에서 **이벤트 패턴 양식(Event pattern form)**을 선택합니다.
1. **이벤트 소스**에서 **AWS 서비스**를 선택합니다.
1. **AWS service**(서비스)에서 **Systems Manager**를 선택합니다.
1. [**이벤트 유형(Event type)**]으로 [**인벤토리**]를 선택합니다.
1. **Specific detail type(s)**(특정 상세 유형)에서 **Inventory Resource State Change**(인벤토리 리소스 상태 변경)을 선택합니다.
1. **다음**을 선택합니다.
1. **대상 유형**에서 **AWS서비스**를 선택합니다.
1. **Select a target**(대상 선택)에서 **SNS topic**(SNS 주제)을 선택한 후 **Topic**(주제)에서 주제를 선택합니다.
1. **Additional settings**(추가 설정) 섹션의 **Configure target input**(대상 입력 구성)에서 **Matched event**(일치하는 이벤트)가 선택되었는지 확인합니다.
1. **다음**을 선택합니다.
1. (선택 사항)규칙에 대해 하나 이상의 태그를 입력하세요. 자세한 내용은 *Amazon EventBridge User Guide*의 [Tagging Your Amazon EventBridge Resources](https://docs.aws.amazon.com/eventbridge/latest/userguide/eventbridge-tagging.html)를 참조하세요.
1. **다음**을 선택합니다.
1. 규칙의 세부 정보를 검토하고 **규칙 생성**을 선택합니다.
# 인벤토리 이력 및 변경 사항 추적 보기
[AWS Config](https://docs.aws.amazon.com/config/latest/developerguide/)를 사용하여 모든 관리형 노드에 대한 AWS Systems Manager Inventory 기록 및 변경 사항 추적을 확인할 수 있습니다. AWS Config에서는 AWS 계정에 있는 AWS 리소스의 구성을 자세히 보여줍니다. 이러한 보기에는 리소스 간에 어떤 관계가 있는지와 리소스가 과거에 어떻게 구성되었는지도 포함되므로, 시간이 지나면서 구성과 관계가 어떻게 변하는지 확인할 수 있습니다. 인벤토리 기록과 변경 사항 추적을 보려면 AWS Config에서 다음 리소스를 설정해야 합니다.
+ SSM:ManagedInstanceInventory
+ SSM:PatchCompliance
+ SSM:AssociationCompliance
+ SSM:FileData
**참고**
Inventory 기록 및 변경 추적에 대한 다음과 같은 중요한 세부 정보에 유의합니다.
AWS Config를 사용하여 시스템의 변경 사항을 추적하는 경우 AWS Config(`SSM:FileData`)에서 파일 변경 사항을 볼 수 있도록 `AWS:File` 메타데이터를 수집하도록 Systems Manager Inventory를 구성해야 합니다. 그렇지 않으면 AWS Config가 시스템의 파일 변경 사항을 추적하지 않습니다.
SSM:PatchCompliance 및 SSM:AssociationCompliance를 설정하여 Systems Manager Patch Manager 패치와 Systems Manager State Manager 연결의 Compliance 기록 및 변경 사항 추적을 확인할 수 있습니다. 이러한 리소스의 규정 준수 관리에 대한 자세한 내용은 [규정 준수에 대해 자세히 알아보기](compliance-about.md) 섹션을 참조하세요.
다음 절차에서는 AWS Command Line Interface(AWS CLI)를 사용하여 AWS Config에서 인벤토리 기록 및 변경 사항 추적의 기록을 설정하는 방법을 설명합니다. AWS Config에서 이러한 리소스를 선택하고 구성하는 방법에 대한 자세한 내용은 *AWS Config Developer Guide*의 [Selecting Which Resources AWS Config Records](https://docs.aws.amazon.com/config/latest/developerguide/select-resources.html)를 참조하세요. AWS Config 요금에 대한 자세한 내용은 [요금](https://aws.amazon.com/config/pricing/)을 참조하세요.
**시작하기 전에**
AWS Config에 AWS Identity and Access Management(IAM) 권한이 있어야 Systems Manager 리소스에 대한 구성 세부 정보를 가져올 수 있습니다. 다음 절차에서는 IAM 역할의 Amazon 리소스 이름(ARN)을 지정하여 Systems Manager 리소스에 대한 권한을 AWS Config에 부여해야 합니다. `AWS_ConfigRole` 관리형 정책을 AWS Config에 할당한 IAM 역할에 연결할 수 있습니다. 이 역할에 대한 자세한 내용은 *AWS Config 개발자 안내서*의 [AWS 관리형 정책: AWS\$1ConfigRole](https://docs.aws.amazon.com/config/latest/developerguide/security-iam-awsmanpol.html#security-iam-awsmanpol-AWS_ConfigRole)을 참조하세요. IAM 역할을 생성하고 해당 역할에 `AWS_ConfigRole` 관리형 정책을 할당하는 방법에 대한 자세한 내용은 *IAM 사용 설명서*의 [AWS 서비스에 권한을 위임하는 역할 생성](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-service.html)을 참조하세요.
**AWS Config에서 인벤토리 기록 및 변경 사항 추적의 기록을 설정하려면**
1. 아직 하지 않은 경우 AWS Command Line Interface(AWS CLI)을 설치하고 구성합니다.
자세한 내용은 [최신 버전의 AWS CLI 설치 또는 업데이트](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html)를 참조하세요.
1. 다음 JSON 샘플을 복사하여 단순한 텍스트 파일에 붙여 넣고 recordingGroup.json으로 저장합니다.
```
{
"allSupported":false,
"includeGlobalResourceTypes":false,
"resourceTypes":[
"AWS::SSM::AssociationCompliance",
"AWS::SSM::PatchCompliance",
"AWS::SSM::ManagedInstanceInventory",
"AWS::SSM::FileData"
]
}
```
1. 다음 명령을 실행하여 recordingGroup.json 파일을 AWS Config에 로드합니다.
```
aws configservice put-configuration-recorder --configuration-recorder name=myRecorder,roleARN=arn:aws:iam::123456789012:role/myConfigRole --recording-group file://recordingGroup.json
```
1. 다음 명령을 실행하여 인벤토리 이력 및 변경 사항 추적의 기록을 시작합니다.
```
aws configservice start-configuration-recorder --configuration-recorder-name myRecorder
```
기록 및 변경 내용 추적을 구성한 후 Systems Manager 콘솔에서 **AWS Config** 버튼을 선택하여 특정 관리형 노드에 대한 기록을 드릴다운할 수 있습니다. **관리형 인스턴스(Managed Instances)** 페이지 또는 **Inventory** 페이지에서 **AWS Config** 버튼에 액세스할 수 있습니다. 모니터 크기에 따라 페이지 오른쪽으로 스크롤해야 이 버튼이 보일 수도 있습니다.
# 데이터 수집 중지 및 인벤토리 데이터 삭제
더 이상 AWS Systems Manager Inventory를 사용하여 AWS 리소스에 대한 메타데이터를 보고 싶지 않다면, 데이터 수집을 중지하고 이미 수집된 데이터를 삭제할 수 있습니다. 이 섹션에는 다음 정보가 포함됩니다.
**Topics**
+ [데이터 수집 중지](#systems-manager-inventory-delete-association)
+ [Inventory 리소스 데이터 동기화 삭제](#systems-manager-inventory-delete-RDS)
## 데이터 수집 중지
인벤토리 데이터를 수집하도록 Systems Manager를 처음 구성하면 시스템에서 일정 및 메타데이터를 수집할 리소스를 정의하는 State Manager 연결을 생성합니다. `AWS-GatherSoftwareInventory` 문서를 사용하는 State Manager 연결을 삭제하여 데이터 수집을 중지할 수 있습니다.
**Inventory 연결을 삭제하려면**
1. [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)에서 AWS Systems Manager 콘솔을 엽니다.
1. 탐색 창에서 **State Manager**를 선택합니다.
1. `AWS-GatherSoftwareInventory` 문서를 사용하는 연결을 선택한 다음 **삭제(Delete)**를 선택합니다.
1. `AWS-GatherSoftwareInventory` 문서를 사용하는 나머지 연결에 대해 3단계를 반복합니다.
## Inventory 리소스 데이터 동기화 삭제
더 이상 AWS Systems Manager Inventory를 사용하여 AWS 리소스에 대한 메타데이터를 보고 싶지 않다면, 인벤토리 데이터 수집에 사용되는 리소스 데이터 동기화를 삭제하는 것이 좋습니다.
**Inventory 리소스 데이터 동기화를 삭제하려면**
1. [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)에서 AWS Systems Manager 콘솔을 엽니다.
1. 탐색 창에서 [**Inventory**]를 선택합니다.
1. **리소스 데이터 동기화(Resource data sync)**를 선택합니다.
1. 목록에서 동기화를 선택합니다.
**중요**
Inventory에 사용되는 동기화를 선택해야 합니다. Systems Manager는 여러 도구에 대한 리소스 데이터 동기화를 지원합니다. 잘못된 동기화를 선택하면 Systems Manager Explorer 또는 Systems Manager Compliance의 데이터 집계가 중단될 수 있습니다.
1. **삭제(Delete)**를 선택합니다.
1. 삭제할 나머지 리소스 데이터 동기화에 대해 이 단계를 반복합니다.
1. 데이터가 저장된 Amazon Simple Storage Service(Amazon S3) 버킷을 삭제합니다. Amazon S3 버킷 삭제에 대한 자세한 내용은 [버킷 삭제](https://docs.aws.amazon.com/AmazonS3/latest/userguide/delete-bucket.html)를 참조하세요.
# 관리형 노드에 사용자 지정 인벤토리 메타데이터 할당
다음 절차는 AWS Systems Manager [PutInventory](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PutInventory.html) API 작업을 사용하여 관리형 노드에 사용자 정의 인벤토리 메타데이터를 할당하는 프로세스를 안내합니다. 이번 예에서는 노드에 랙 위치 정보를 할당합니다. 사용자 지정 인벤토리에 대한 자세한 내용은 [사용자 정의 인벤토리 작업](inventory-custom.md) 섹션을 참조하세요.
**사용자 지정 인벤토리 메타데이터를 노드에 할당**
1. 아직 하지 않은 경우 AWS Command Line Interface(AWS CLI)을 설치하고 구성합니다.
자세한 내용은 [최신 버전의 AWS CLI 설치 또는 업데이트](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html)를 참조하세요.
1. 다음 명령을 실행하여 노드에 랙 위치 정보를 할당합니다.
**Linux**
```
aws ssm put-inventory --instance-id "ID" --items '[{"CaptureTime": "2016-08-22T10:01:01Z", "TypeName": "Custom:RackInfo", "Content":[{"RackLocation": "Bay B/Row C/Rack D/Shelf E"}], "SchemaVersion": "1.0"}]'
```
**Windows**
```
aws ssm put-inventory --instance-id "ID" --items "TypeName=Custom:RackInfo,SchemaVersion=1.0,CaptureTime=2021-05-22T10:01:01Z,Content=[{RackLocation='Bay B/Row C/Rack D/Shelf F'}]"
```
1. 다음 명령을 실행하여 이 노드의 사용자 정의 인벤토리 항목을 확인합니다.
```
aws ssm list-inventory-entries --instance-id ID --type-name "Custom:RackInfo"
```
시스템은 다음과 같은 정보로 응답합니다.
```
{
"InstanceId": "ID",
"TypeName": "Custom:RackInfo",
"Entries": [
{
"RackLocation": "Bay B/Row C/Rack D/Shelf E"
}
],
"SchemaVersion": "1.0",
"CaptureTime": "2016-08-22T10:01:01Z"
}
```
1. 다음 명령을 실행하여 사용자 정의 인벤토리 스키마를 확인합니다.
```
aws ssm get-inventory-schema --type-name Custom:RackInfo
```
시스템은 다음과 같은 정보로 응답합니다.
```
{
"Schemas": [
{
"TypeName": "Custom:RackInfo",
"Version": "1.0",
"Attributes": [
{
"DataType": "STRING",
"Name": "RackLocation"
}
]
}
]
}
```
# AWS CLI를 사용하여 인벤토리 데이터 수집 구성
다음 절차에서는 관리형 노드에서 메타데이터를 수집하도록 AWS Systems Manager 인벤토리를 구성하는 프로세스를 설명합니다. 인벤토리 수집을 구성할 때 Systems Manager State Manager 연결을 생성하는 것으로 시작합니다. Systems Manager는 연결이 실행될 때 인벤토리 데이터를 수집합니다. 연결을 먼저 생성하지 않고 Systems Manager Run Command 등을 사용하여 `aws:softwareInventory` 플러그인을 호출하려고 하면 시스템이 다음 오류를 반환합니다.
`The aws:softwareInventory plugin can only be invoked via ssm-associate`.
**참고**
노드에는 한 번에 하나의 인벤토리 연결만 구성할 수 있습니다. 둘 이상의 인벤토리 연결로 노드를 구성할 경우 연결이 실행되지 않으며 인벤토리 데이터가 수집되지 않습니다.
## 빠르게 인벤토리에 대한 모든 관리형 노드 구성(CLI)
AWS 계정 및 현재 리전의 모든 관리형 노드에서 인벤토리 데이터를 수집하도록 빠르게 구성할 수 있습니다. 이를 전역 인벤토리 연결 생성이라고 합니다. AWS CLI를 사용하여 전역 인벤토리 연결을 생성하려면 다음 절차에 나와 있듯이 `instanceIds` 값에 와일드카드 옵션을 사용하십시오.
**AWS 계정 및 현재 리전의 모든 관리형 노드에서 인벤토리 구성(CLI)**
1. 아직 하지 않은 경우 AWS Command Line Interface(AWS CLI)을 설치하고 구성합니다.
자세한 내용은 [최신 버전의 AWS CLI 설치 또는 업데이트](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html)를 참조하세요.
1. 다음 명령을 실행합니다.
------
#### [ Linux & macOS ]
```
aws ssm create-association \
--name AWS-GatherSoftwareInventory \
--targets Key=InstanceIds,Values=* \
--schedule-expression "rate(1 day)" \
--parameters applications=Enabled,awsComponents=Enabled,customInventory=Enabled,instanceDetailedInformation=Enabled,networkConfig=Enabled,services=Enabled,windowsRoles=Enabled,windowsUpdates=Enabled
```
------
#### [ Windows ]
```
aws ssm create-association ^
--name AWS-GatherSoftwareInventory ^
--targets Key=InstanceIds,Values=* ^
--schedule-expression "rate(1 day)" ^
--parameters applications=Enabled,awsComponents=Enabled,customInventory=Enabled,instanceDetailedInformation=Enabled,networkConfig=Enabled,services=Enabled,windowsRoles=Enabled,windowsUpdates=Enabled
```
------
**참고**
이 명령은 Inventory가 Windows 레지스트리 또는 파일에 대한 메타데이터를 수집하는 것을 허용하지 않습니다. 이러한 데이터 형식을 인벤토리하려면 다음 절차를 사용하십시오.
## 관리형 노드에서 수동으로 인벤토리 구성(CLI)
다음 절차를 사용하여 수동으로 인스턴스 ID 또는 태그를 사용해 관리형 노드에 AWS Systems Manager 인벤토리를 구성합니다.
**수동으로 관리형 노드에서 인벤토리 구성(CLI)**
1. 아직 하지 않은 경우 AWS Command Line Interface(AWS CLI)을 설치하고 구성합니다.
자세한 내용은 [최신 버전의 AWS CLI 설치 또는 업데이트](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html)를 참조하세요.
1. 다음 명령을 실행하여 노드에서 Systems Manager Inventory를 실행하는 State Manager 연결을 생성합니다. 각 *example resource placeholder*를 사용자의 정보로 바꿉니다. 이 명령은 6시간마다 서비스를 실행하고 노드에서 네트워크 구성, Windows 업데이트, 애플리케이션 메타데이터를 수집하도록 구성합니다.
------
#### [ Linux & macOS ]
```
aws ssm create-association \
--name "AWS-GatherSoftwareInventory" \
--targets "Key=instanceids,Values=an_instance_ID" \
--schedule-expression "rate(240 minutes)" \
--output-location "{ \"S3Location\": { \"OutputS3Region\": \"region_ID, for example us-east-2\", \"OutputS3BucketName\": \"amzn-s3-demo-bucket\", \"OutputS3KeyPrefix\": \"Test\" } }" \
--parameters "networkConfig=Enabled,windowsUpdates=Enabled,applications=Enabled"
```
------
#### [ Windows ]
```
aws ssm create-association ^
--name "AWS-GatherSoftwareInventory" ^
--targets "Key=instanceids,Values=an_instance_ID" ^
--schedule-expression "rate(240 minutes)" ^
--output-location "{ \"S3Location\": { \"OutputS3Region\": \"region_ID, for example us-east-2\", \"OutputS3BucketName\": \"amzn-s3-demo-bucket\", \"OutputS3KeyPrefix\": \"Test\" } }" ^
--parameters "networkConfig=Enabled,windowsUpdates=Enabled,applications=Enabled"
```
------
시스템은 다음과 같은 정보로 응답합니다.
```
{
"AssociationDescription": {
"ScheduleExpression": "rate(240 minutes)",
"OutputLocation": {
"S3Location": {
"OutputS3KeyPrefix": "Test",
"OutputS3BucketName": "Test bucket",
"OutputS3Region": "us-east-2"
}
},
"Name": "The name you specified",
"Parameters": {
"applications": [
"Enabled"
],
"networkConfig": [
"Enabled"
],
"windowsUpdates": [
"Enabled"
]
},
"Overview": {
"Status": "Pending",
"DetailedStatus": "Creating"
},
"AssociationId": "1a2b3c4d5e6f7g-1a2b3c-1a2b3c-1a2b3c-1a2b3c4d5e6f7g",
"DocumentVersion": "$DEFAULT",
"LastUpdateAssociationDate": 1480544990.06,
"Date": 1480544990.06,
"Targets": [
{
"Values": [
"i-02573cafcfEXAMPLE"
],
"Key": "InstanceIds"
}
]
}
}
```
대규모 노드 그룹을 대상으로 EC2 태그와 `Targets` 파라미터를 사용할 수 있습니다. 다음 예제를 참조하세요.
------
#### [ Linux & macOS ]
```
aws ssm create-association \
--name "AWS-GatherSoftwareInventory" \
--targets "Key=tag:Environment,Values=Production" \
--schedule-expression "rate(240 minutes)" \
--output-location "{ \"S3Location\": { \"OutputS3Region\": \"us-east-2\", \"OutputS3BucketName\": \"amzn-s3-demo-bucket\", \"OutputS3KeyPrefix\": \"Test\" } }" \
--parameters "networkConfig=Enabled,windowsUpdates=Enabled,applications=Enabled"
```
------
#### [ Windows ]
```
aws ssm create-association ^
--name "AWS-GatherSoftwareInventory" ^
--targets "Key=tag:Environment,Values=Production" ^
--schedule-expression "rate(240 minutes)" ^
--output-location "{ \"S3Location\": { \"OutputS3Region\": \"us-east-2\", \"OutputS3BucketName\": \"amzn-s3-demo-bucket\", \"OutputS3KeyPrefix\": \"Test\" } }" ^
--parameters "networkConfig=Enabled,windowsUpdates=Enabled,applications=Enabled"
```
------
표현식과 함께 `files` 및 `windowsRegistry` 유형의 인벤토리를 사용하여 Windows Server 노드에서 파일 및 Windows 레지스트리 키를 인벤토리로 만들 수도 있습니다. 이러한 인벤토리 유형에 대한 자세한 내용은 [파일 및 Windows 레지스트리 인벤토리 관련 작업](inventory-file-and-registry.md)를 참조하십시오.
------
#### [ Linux & macOS ]
```
aws ssm create-association \
--name "AWS-GatherSoftwareInventory" \
--targets "Key=instanceids,Values=i-0704358e3a3da9eb1" \
--schedule-expression "rate(240 minutes)" \
--parameters '{"files":["[{\"Path\": \"C:\\Program Files\", \"Pattern\": [\"*.exe\"], \"Recursive\": true}]"], "windowsRegistry": ["[{\"Path\":\"HKEY_LOCAL_MACHINE\\Software\\Amazon\", \"Recursive\":true}]"]}' \
--profile dev-pdx
```
------
#### [ Windows ]
```
aws ssm create-association ^
--name "AWS-GatherSoftwareInventory" ^
--targets "Key=instanceids,Values=i-0704358e3a3da9eb1" ^
--schedule-expression "rate(240 minutes)" ^
--parameters '{"files":["[{\"Path\": \"C:\\Program Files\", \"Pattern\": [\"*.exe\"], \"Recursive\": true}]"], "windowsRegistry": ["[{\"Path\":\"HKEY_LOCAL_MACHINE\\Software\\Amazon\", \"Recursive\":true}]"]}' ^
--profile dev-pdx
```
------
1. 다음 명령을 실행하여 연결 상태를 확인합니다.
```
aws ssm describe-instance-associations-status --instance-id an_instance_ID
```
시스템은 다음과 같은 정보로 응답합니다.
```
{
"InstanceAssociationStatusInfos": [
{
"Status": "Pending",
"DetailedStatus": "Associated",
"Name": "reInvent2016PolicyDocumentTest",
"InstanceId": "i-1a2b3c4d5e6f7g",
"AssociationId": "1a2b3c4d5e6f7g-1a2b3c-1a2b3c-1a2b3c-1a2b3c4d5e6f7g",
"DocumentVersion": "1"
}
]
}
```
# 연습: 리소스 데이터 동기화를 사용하여 인벤토리 데이터 집계
다음 시연에서는 AWS Command Line Interface(AWS CLI)를 사용하여 AWS Systems Manager Inventory에 대한 리소스 데이터 동기화 구성을 생성하는 방법을 설명합니다. 리소스 데이터 동기화는 모든 관리형 노드의 인벤토리 데이터를 중앙의 Amazon Simple Storage Service(Amazon S3) 버킷으로 자동 포팅합니다. 새로운 인벤토리 데이터가 발견될 때마다 동기화를 통해 중앙의 Amazon S3 버킷 데이터가 자동으로 업데이트됩니다.
이번 시연에서는 Amazon Athena 및 Amazon Quick을 사용하여 수집한 데이터에 대해 쿼리를 실행하고 분석하는 방법에 대해서 설명합니다. AWS Management Console에서 Systems Manager를 사용하여 리소스 데이터 동기화를 생성하는 방법에 대한 자세한 내용은 [연습: 리소스 데이터 동기화를 사용하여 인벤토리 데이터 집계](#inventory-resource-data-sync) 섹션을 참조하세요. AWS Management Console의 Systems Manager를 사용하여 여러 AWS 리전 및 계정의 인벤토리를 쿼리하는 방법에 대한 자세한 내용은 [여러 리전 및 계정에서 인벤토리 데이터 쿼리](systems-manager-inventory-query.md) 섹션을 참조하세요.
**참고**
이 연습에는 AWS Key Management Service(AWS KMS)를 사용하여 동기화를 암호화하는 방법에 대한 정보가 포함되어 있습니다. 암호화는 옵션이므로 인벤토리에서는 사용자별 데이터, 독점 데이터 또는 민감한 데이터를 수집하지 않습니다. AWS KMS에 대한 자세한 내용은 [AWS Key Management Service Developer Guide](https://docs.aws.amazon.com/kms/latest/developerguide/)를 참조하세요.
**시작하기 전 준비 사항**
이 섹션에서 연습을 시작하기 전에 다음 작업을 검토하거나 완료합니다.
+ 관리형 노드에서 인벤토리 데이터를 수집합니다. 이번 시연의 Amazon Athena 및 Amazon Quick 섹션 목적에 따라 애플리케이션 데이터의 수집을 권장합니다. 인벤토리 데이터를 수집하는 방법에 대한 자세한 내용은 [인벤토리 수집 구성](inventory-collection.md) 또는 [AWS CLI를 사용하여 인벤토리 데이터 수집 구성](inventory-collection-cli.md) 섹션을 참조하세요.
+ (선택 사항) 인벤토리 데이터가 AWS Key Management Service(AWS KMS) 암호화를 사용하는 Amazon Simple Storage Service(Amazon S3) 버킷에 저장된 경우, AWS KMS 암호화를 위해 IAM 계정과 `Amazon-GlueServiceRoleForSSM` 서비스 역할 또한 구성해야 합니다. IAM 계정과 이 역할을 구성하지 않는 경우 콘솔의 **세부 정보 보기(Detailed View)** 탭을 선택하면 Systems Manager가 `Cannot load Glue tables`를 표시합니다. 자세한 내용은 [(선택 사항) AWS KMS 암호화 데이터를 볼 수 있는 권한 구성](systems-manager-inventory-query.md#systems-manager-inventory-query-kms) 섹션을 참조하세요.
+ (선택 사항) AWS KMS를 사용하여 리소스 데이터 동기화를 암호화하려면 다음 정책을 포함하는 새 키를 생성하거나 기존 키를 업데이트하고 이 정책을 키에 추가해야 합니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Id": "ssm-access-policy",
"Statement": [
{
"Sid": "ssm-access-policy-statement",
"Action": [
"kms:GenerateDataKey"
],
"Effect": "Allow",
"Principal": {
"Service": "ssm.amazonaws.com"
},
"Resource": "arn:aws:kms:us-east-1:123456789012:key/KMS_key_id",
"Condition": {
"StringLike": {
"aws:SourceAccount": "123456789012"
},
"ArnLike": {
"aws:SourceArn": "arn:aws:ssm:*:123456789012:resource-data-sync/*"
}
}
}
]
}
```
------
**인벤토리의 리소스 데이터 동기화를 생성하려면**
1. [https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/)에서 S3 콘솔을 엽니다.
1. 집계된 인벤토리 데이터를 저장할 버킷을 생성합니다. 자세한 내용은 *Amazon Simple Storage Service 사용 설명서*에서 [버킷 생성](https://docs.aws.amazon.com/AmazonS3/latest/userguide/create-bucket-overview.html)을 참조하세요. 버킷 이름과 버킷을 생성한 AWS 리전을 따로 적어둡니다.
1. 버킷을 생성한 후 **권한** 탭, **버킷 정책**을 차례로 선택합니다.
1. 다음 버킷 정책을 복사하여 정책 편집기에 붙여 넣습니다. 이때 amzn-s3-demo-bucket 및 *account-id*를 사용자가 생성한 Amazon S3 버킷 이름 및 유효한 AWS 계정 ID로 바꿉니다. 여러 계정을 추가할 때 계정마다 조건 문자열과 ARN을 추가합니다. 계정 하나를 추가할 때 예제에서 추가 자리 표시자를 제거합니다. 원할 경우 *bucket-prefix*를 Amazon S3 접두사(하위 디렉터리) 이름으로 바꿉니다. 접두사를 생성하지 않았으면 정책의 ARN에서 *bucket-prefix/*를 제거합니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": " SSMBucketDelivery",
"Effect": "Allow",
"Principal": {
"Service": "ssm.amazonaws.com"
},
"Action": "s3:PutObject",
"Resource": [
"arn:aws:s3:::amzn-s3-demo-bucket/bucket-prefix/*/accountid=111122223333/*"
],
"Condition": {
"StringEquals": {
"s3:x-amz-acl": "bucket-owner-full-control",
"aws:SourceAccount": [
"111122223333",
"444455556666",
"123456789012",
"777788889999"
]
},
"ArnLike": {
"aws:SourceArn": [
"arn:aws:ssm:*:111122223333:resource-data-sync/*",
"arn:aws:ssm:*:444455556666:resource-data-sync/*",
"arn:aws:ssm:*:123456789012:resource-data-sync/*",
"arn:aws:ssm:*:777788889999:resource-data-sync/*"
]
}
}
}
]
}
```
------
1. (선택 사항) 동기화를 암호화하려면 앞 단계에 나열된 정책에 다음 조건을 추가해야 합니다. `StringEquals` 섹션에 추가하세요.
```
"s3:x-amz-server-side-encryption":"aws:kms",
"s3:x-amz-server-side-encryption-aws-kms-key-id":"arn:aws:kms:region:account_ID:key/KMS_key_ID"
```
다음 예를 참고하세요
```
"StringEquals": {
"s3:x-amz-acl": "bucket-owner-full-control",
"aws:SourceAccount": "account-id",
"s3:x-amz-server-side-encryption":"aws:kms",
"s3:x-amz-server-side-encryption-aws-kms-key-id":"arn:aws:kms:region:account_ID:key/KMS_key_ID"
}
```
1. 아직 하지 않은 경우 AWS Command Line Interface(AWS CLI)을 설치하고 구성합니다.
자세한 내용은 [최신 버전의 AWS CLI 설치 또는 업데이트](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html)를 참조하세요.
1. (옵션) 동기화를 암호화하려면 다음 명령을 실행하여 버킷 정책에서 AWS KMS 키 요구 사항을 실행하는지 확인합니다. 각 *example resource placeholder*를 사용자의 정보로 바꿉니다.
------
#### [ Linux & macOS ]
```
aws s3 cp ./A_file_in_the_bucket s3://amzn-s3-demo-bucket/prefix/ \
--sse aws:kms \
--sse-kms-key-id "arn:aws:kms:region:account_ID:key/KMS_key_id" \
--region region, for example, us-east-2
```
------
#### [ Windows ]
```
aws s3 cp ./A_file_in_the_bucket s3://amzn-s3-demo-bucket/prefix/ ^
--sse aws:kms ^
--sse-kms-key-id "arn:aws:kms:region:account_ID:key/KMS_key_id" ^
--region region, for example, us-east-2
```
------
1. 다음 명령을 실행하여 이 절차를 시작할 때 생성한 Amazon S3 버킷에서 리소스 데이터 동기화 구성을 생성합니다. 이 명령은 로그인되어 있는 AWS 리전에서 동기화를 생성합니다.
**참고**
동기화와 대상 Amazon S3 버킷이 서로 다른 리전에 위치하는 경우에는 데이터 전송 요금이 부과될 수 있습니다. 자세한 내용은 [Amazon S3 요금](https://aws.amazon.com/s3/pricing/)을 참조하세요.
------
#### [ Linux & macOS ]
```
aws ssm create-resource-data-sync \
--sync-name a_name \
--s3-destination "BucketName=amzn-s3-demo-bucket,Prefix=prefix_name, if_specified,SyncFormat=JsonSerDe,Region=bucket_region"
```
------
#### [ Windows ]
```
aws ssm create-resource-data-sync ^
--sync-name a_name ^
--s3-destination "BucketName=amzn-s3-demo-bucket,Prefix=prefix_name, if_specified,SyncFormat=JsonSerDe,Region=bucket_region"
```
------
`region` 파라미터를 사용하여 동기화 구성을 생성할 리전을 지정할 수 있습니다. 다음 예에서는 us-west-1 리전의 인벤토리 데이터가 us-west-2 리전에 속한 Amazon S3 버킷에서 동기화됩니다.
------
#### [ Linux & macOS ]
```
aws ssm create-resource-data-sync \
--sync-name InventoryDataWest \
--s3-destination "BucketName=amzn-s3-demo-bucket,Prefix=HybridEnv,SyncFormat=JsonSerDe,Region=us-west-2"
--region us-west-1
```
------
#### [ Windows ]
```
aws ssm create-resource-data-sync ^
--sync-name InventoryDataWest ^
--s3-destination "BucketName=amzn-s3-demo-bucket,Prefix=HybridEnv,SyncFormat=JsonSerDe,Region=us-west-2" ^ --region us-west-1
```
------
(선택 사항) AWS KMS를 사용하여 동기화를 암호화하려면 다음 명령을 실행하여 동기화를 생성합니다. 동기화를 암호화한 경우 AWS KMS 키와 Amazon S3 버킷이 같은 리전에 있어야 합니다.
------
#### [ Linux & macOS ]
```
aws ssm create-resource-data-sync \
--sync-name sync_name \
--s3-destination "BucketName=amzn-s3-demo-bucket,Prefix=prefix_name, if_specified,SyncFormat=JsonSerDe,AWSKMSKeyARN=arn:aws:kms:region:account_ID:key/KMS_key_ID,Region=bucket_region" \
--region region
```
------
#### [ Windows ]
```
aws ssm create-resource-data-sync ^
--sync-name sync_name ^
--s3-destination "BucketName=amzn-s3-demo-bucket,Prefix=prefix_name, if_specified,SyncFormat=JsonSerDe,AWSKMSKeyARN=arn:aws:kms:region:account_ID:key/KMS_key_ID,Region=bucket_region" ^
--region region
```
------
1. 다음 명령을 실행하여 동기화 구성 상태를 확인합니다.
```
aws ssm list-resource-data-sync
```
동기화 구성을 다른 리전에 생성한 경우에는 아래 예제와 같이 `region` 파라미터를 지정해야 합니다.
```
aws ssm list-resource-data-sync --region us-west-1
```
1. 동기화 구성이 성공적으로 생성된 후에는 Amazon S3의 대상 버킷을 검사합니다. 몇 분 내에 인벤토리 데이터가 표시되어야 합니다.
**Amazon Athena의 데이터 작업**
아래 섹션에서는 Amazon Athena에서 데이터를 확인하거나 쿼리를 실행하는 방법에 대해 설명합니다. 시작하기 전에 Athena에 대해 알아보는 것이 좋습니다. 자세한 내용은 *Amazon Athena User Guide*의 [What is Amazon Athena?](https://docs.aws.amazon.com/athena/latest/ug/what-is.html) 및 [Working with Data](https://docs.aws.amazon.com/athena/latest/ug/work-with-data.html)를 참조하세요.
**Amazon Athena에서 데이터를 보고 쿼리하려면**
1. [https://console.aws.amazon.com/athena/](https://console.aws.amazon.com/athena/home)에서 Athena 콘솔을 엽니다.
1. 다음 문을 복사하여 쿼리 편집기에 붙여 넣은 다음 **쿼리 실행**을 선택합니다.
```
CREATE DATABASE ssminventory
```
시스템이 ssminventory라는 이름의 데이터베이스를 생성합니다.
1. 다음 문을 복사하여 쿼리 편집기에 붙여 넣은 다음 **쿼리 실행**을 선택합니다. 이때 amzn-s3-demo-bucket 및 *bucket\$1prefix*를 Amazon S3 대상의 이름 및 접두사로 바꿉니다.
```
CREATE EXTERNAL TABLE IF NOT EXISTS ssminventory.AWS_Application (
Name string,
ResourceId string,
ApplicationType string,
Publisher string,
Version string,
InstalledTime string,
Architecture string,
URL string,
Summary string,
PackageId string
)
PARTITIONED BY (AccountId string, Region string, ResourceType string)
ROW FORMAT SERDE 'org.openx.data.jsonserde.JsonSerDe'
WITH SERDEPROPERTIES (
'serialization.format' = '1'
) LOCATION 's3://amzn-s3-demo-bucket/bucket_prefix/AWS:Application/'
```
1. 다음 문을 복사하여 쿼리 편집기에 붙여 넣은 다음 **쿼리 실행**을 선택합니다.
```
MSCK REPAIR TABLE ssminventory.AWS_Application
```
시스템이 테이블을 분할합니다.
**참고**
추가되는 AWS 리전 또는 AWS 계정에서 리소스 데이터 동기화를 생성하는 경우에는 위 명령을 다시 실행하여 파티션을 업데이트해야 합니다. Amazon S3 버킷 정책도 업데이트해야 할 수 있습니다.
1. 데이터를 미리 보려면 `AWS_Application` 테이블 옆에 있는 보기 아이콘을 선택합니다.
![\[Amazon Athena 미리 보기 데이터 아이콘.\]](http://docs.aws.amazon.com/ko_kr/systems-manager/latest/userguide/images/sysman-inventory-resource-data-sync-walk.png)
1. 다음 문을 복사하여 쿼리 편집기에 붙여 넣은 다음 **쿼리 실행**을 선택합니다.
```
SELECT a.name, a.version, count( a.version) frequency
from aws_application a where
a.name = 'aws-cfn-bootstrap'
group by a.name, a.version
order by frequency desc
```
쿼리는 Linux, macOS 및 Windows Server용 Amazon Elastic Compute Cloud(Amazon EC2) 인스턴스에 있는 AWS 애플리케이션인 `aws-cfn-bootstrap`의 여러 버전 수를 반환합니다.
1. 다음 문을 개별적으로 복사하여 쿼리 편집기에 붙여 넣고 amzn-s3-demo-bucket 및 *bucket-prefix*를 Amazon S3에 대한 정보로 바꾼 다음, **쿼리 실행**을 선택합니다. 아래 문들은 Athena의 인벤토리 테이블을 추가로 설정합니다.
```
CREATE EXTERNAL TABLE IF NOT EXISTS ssminventory.AWS_AWSComponent (
`ResourceId` string,
`Name` string,
`ApplicationType` string,
`Publisher` string,
`Version` string,
`InstalledTime` string,
`Architecture` string,
`URL` string
)
PARTITIONED BY (AccountId string, Region string, ResourceType string)
ROW FORMAT SERDE 'org.openx.data.jsonserde.JsonSerDe'
WITH SERDEPROPERTIES (
'serialization.format' = '1'
) LOCATION 's3://amzn-s3-demo-bucket/bucket-prefix/AWS:AWSComponent/'
```
```
MSCK REPAIR TABLE ssminventory.AWS_AWSComponent
```
```
CREATE EXTERNAL TABLE IF NOT EXISTS ssminventory.AWS_WindowsUpdate (
`ResourceId` string,
`HotFixId` string,
`Description` string,
`InstalledTime` string,
`InstalledBy` string
)
PARTITIONED BY (AccountId string, Region string, ResourceType string)
ROW FORMAT SERDE 'org.openx.data.jsonserde.JsonSerDe'
WITH SERDEPROPERTIES (
'serialization.format' = '1'
) LOCATION 's3://amzn-s3-demo-bucket/bucket-prefix/AWS:WindowsUpdate/'
```
```
MSCK REPAIR TABLE ssminventory.AWS_WindowsUpdate
```
```
CREATE EXTERNAL TABLE IF NOT EXISTS ssminventory.AWS_InstanceInformation (
`AgentType` string,
`AgentVersion` string,
`ComputerName` string,
`IamRole` string,
`InstanceId` string,
`IpAddress` string,
`PlatformName` string,
`PlatformType` string,
`PlatformVersion` string
)
PARTITIONED BY (AccountId string, Region string, ResourceType string)
ROW FORMAT SERDE 'org.openx.data.jsonserde.JsonSerDe'
WITH SERDEPROPERTIES (
'serialization.format' = '1'
) LOCATION 's3://amzn-s3-demo-bucket/bucket-prefix/AWS:InstanceInformation/'
```
```
MSCK REPAIR TABLE ssminventory.AWS_InstanceInformation
```
```
CREATE EXTERNAL TABLE IF NOT EXISTS ssminventory.AWS_Network (
`ResourceId` string,
`Name` string,
`SubnetMask` string,
`Gateway` string,
`DHCPServer` string,
`DNSServer` string,
`MacAddress` string,
`IPV4` string,
`IPV6` string
)
PARTITIONED BY (AccountId string, Region string, ResourceType string)
ROW FORMAT SERDE 'org.openx.data.jsonserde.JsonSerDe'
WITH SERDEPROPERTIES (
'serialization.format' = '1'
) LOCATION 's3://amzn-s3-demo-bucket/bucket-prefix/AWS:Network/'
```
```
MSCK REPAIR TABLE ssminventory.AWS_Network
```
```
CREATE EXTERNAL TABLE IF NOT EXISTS ssminventory.AWS_PatchSummary (
`ResourceId` string,
`PatchGroup` string,
`BaselineId` string,
`SnapshotId` string,
`OwnerInformation` string,
`InstalledCount` int,
`InstalledOtherCount` int,
`NotApplicableCount` int,
`MissingCount` int,
`FailedCount` int,
`OperationType` string,
`OperationStartTime` string,
`OperationEndTime` string
)
PARTITIONED BY (AccountId string, Region string, ResourceType string)
ROW FORMAT SERDE 'org.openx.data.jsonserde.JsonSerDe'
WITH SERDEPROPERTIES (
'serialization.format' = '1'
) LOCATION 's3://amzn-s3-demo-bucket/bucket-prefix/AWS:PatchSummary/'
```
```
MSCK REPAIR TABLE ssminventory.AWS_PatchSummary
```
**Amazon Quick의 데이터 작업**
아래 섹션에서는 Amazon Quick의 시각화 빌드를 위해 참조할 수 있는 링크에 대해서 간략히 소개합니다.
**Amazon Quick에서 시각화를 구축하려면**
1. [Amazon Quick](https://quicksight.aws/)에 가입한 후 QuickSight 콘솔에 로그인합니다.
1. `AWS_Application` 테이블과 생성한 다른 테이블에서 데이터 집합을 생성합니다. 자세한 내용은 *Amazon Quick 사용 설명서*의 [Amazon Athena 데이터를 사용하여 데이터 세트 생성](https://docs.aws.amazon.com/quicksuite/latest/userguide/create-a-data-set-athena.html)을 참조하세요.
1. 테이블을 조인합니다. 예를 들어 다른 인벤토리 테이블의 `resourceid` 열과 일치하기 때문에 `AWS_InstanceInformation`의 `instanceid` 열을 조인할 수 있습니다. 테이블 조인에 대한 자세한 내용은 *Amazon Quick 사용 설명서*의 [데이터 조인](https://docs.aws.amazon.com/quicksuite/latest/userguide/joining-data.html)을 참조하세요.
1. 시각화를 빌드합니다. 자세한 내용은 *Amazon Quick 사용 설명서*의 [분석 및 보고서: Amazon Quick Sight에서 데이터 시각화](https://docs.aws.amazon.com/quicksuite/latest/userguide/working-with-visuals.html)를 참조하세요.
# Systems Manager Inventory 관련 문제 해결
여기서는 AWS Systems Manager 인벤토리와 관련된 일반적인 오류나 문제를 해결하는 방법을 설명합니다. Systems Manager에서 노드를 보는 데 문제가 있는 경우 [관리형 노드 가용성 문제 해결](fleet-manager-troubleshooting-managed-nodes.md) 섹션을 참조하세요.
**Topics**
+ [문서 '`AWS-GatherSoftwareInventory`'와의 다중 적용 모든 연결은 지원되지 않습니다.](#systems-manager-inventory-troubleshooting-multiple)
+ [Inventory 실행 상태가 계속 보류 중임](#inventory-troubleshooting-pending)
+ [`AWS-ListWindowsInventory` 문서 실행 실패](#inventory-troubleshooting-ListWindowsInventory)
+ [콘솔은 인벤토리 대시보드 \$1 세부 정보 보기 \$1 설정 탭을 표시하지 않습니다.](#inventory-troubleshooting-tabs)
+ [UnsupportedAgent](#inventory-troubleshooting-unsupported-agent)
+ [건너뜀](#inventory-troubleshooting-skipped)
+ [실패](#inventory-troubleshooting-failed)
+ [Amazon EC2 인스턴스에 대한 인벤토리 규정 준수 실패](#inventory-troubleshooting-ec2-compliance)
+ [S3 버킷 객체에 이전 데이터가 포함되어 있음](#systems-manager-inventory-troubleshooting-s3)
## 문서 '`AWS-GatherSoftwareInventory`'와의 다중 적용 모든 연결은 지원되지 않습니다.
`Multiple apply all associations with document 'AWS-GatherSoftwareInventory' are not supported` 오류는 *모든 노드에 대한* Inventory 연결을 구성하려는 하나 이상의 AWS 리전이 모든 노드에 대한 인벤토리 연결로 이미 구성되었음을 의미합니다. 필요한 경우 모든 노드에 대한 기존 인벤토리 연결을 삭제한 다음 새로 생성할 수 있습니다. 기존 인벤토리 연결을 보려면 Systems Manager 콘솔에서 **State Manager**를 선택한 다음 `AWS-GatherSoftwareInventory` SSM 문서를 사용하는 연결을 찾습니다. 모든 노드에 대한 기존 인벤토리 연결이 여러 리전에 걸쳐 생성되었고 새로 생성하려는 경우 기존 연결이 있는 각 리전에서 기존 연결을 삭제해야 합니다.
## Inventory 실행 상태가 계속 보류 중임
인벤토리 수집이 계속 `Pending` 상태인 이유는 두 가지입니다.
+ 선택된 AWS 리전에 노드가 없습니다.
Systems Manager Quick Setup을 사용하여 글로벌 인벤토리 연결을 생성하는 경우 선택한 리전에 사용 가능한 노드가 없으면 인벤토리 연결(`AWS-GatherSoftwareInventory` 문서)의 상태가 `Pending`으로 표시됩니다.****
+ 권한 부족
하나 이상의 노드에 Systems Manager Inventory를 실행할 권한이 없는 경우 인벤토리 연결이 `Pending`으로 표시됩니다. AWS Identity and Access Management(IAM) 인스턴스 프로파일에 **AmazonSSMManagedInstanceCore** 관리형 정책이 포함되어 있는지 확인합니다. 인스턴스 프로파일에 이 정책을 추가하는 방법에 대한 자세한 내용은 [EC2 인스턴스 권한에 대한 대체 구성](setup-instance-permissions.md#instance-profile-add-permissions) 섹션을 참조하세요.
최소한 인스턴스 프로파일에 다음 IAM 권한이 있어야 합니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ssm:DescribeAssociation",
"ssm:ListAssociations",
"ssm:ListInstanceAssociations",
"ssm:PutInventory",
"ssm:PutComplianceItems",
"ssm:UpdateAssociationStatus",
"ssm:UpdateInstanceAssociationStatus",
"ssm:UpdateInstanceInformation",
"ssm:GetDocument",
"ssm:DescribeDocument"
],
"Resource": "*"
}
]
}
```
------
## `AWS-ListWindowsInventory` 문서 실행 실패
`AWS-ListWindowsInventory` 문서는 더 이상 사용되지 않습니다. 이 문서를 사용하여 인벤토리를 수집하지 마세요. 대신 [인벤토리 수집 구성](inventory-collection.md)에 설명된 프로세스 중 하나를 사용하세요.
## 콘솔은 인벤토리 대시보드 \$1 세부 정보 보기 \$1 설정 탭을 표시하지 않습니다.
Inventory [**세부 정보 뷰(Detailed View)**] 페이지는 Amazon Athena를 제공하는 AWS 리전에서만 사용할 수 있습니다. 다음 탭이 인벤토리(Inventory) 페이지에 표시되지 않는 경우 Athena는 리전에서 사용할 수 없으며 **세부 정보 보기(Detailed View)**를 사용하여 데이터를 쿼리할 수 없습니다.
![\[인벤토리 대시보드 | 세부 정보 보기 | 설정 탭 표시\]](http://docs.aws.amazon.com/ko_kr/systems-manager/latest/userguide/images/inventory-detailed-view-for-error.png)
## UnsupportedAgent
인벤토리 연결의 세부 상태가 **UnsupportedAgent**로 표시되고, **연결 상태**가 **실패**로 표시되는 경우 관리형 노드의 AWS Systems Manager SSM Agent 버전이 올바르지 않은 것입니다. 예를 들어 전역 인벤토리 연결을 생성하여 해당 AWS 계정의 모든 노드에 대한 인벤토리를 작성하려면 SSM Agent 버전 2.0.790.0 이상을 사용해야 합니다. 각 노드에서 실행 중인 에이전트 버전은 **관리형 인스턴스** 페이지의 **에이전트 버전** 열에서 볼 수 있습니다. 노드에서 SSM Agent를 업데이트하는 자세한 방법은 [Run Command를 사용하여 SSM Agent 업데이트](run-command-tutorial-update-software.md#rc-console-agentexample) 섹션을 참조하세요.
## 건너뜀
노드에 대한 인벤토리 연결 상태가 **건너뜀**으로 표시되면 해당 노드에서 우선순위가 더 높은 인벤토리 연결이 이미 실행 중임을 의미합니다. Systems Manager는 동일한 관리형 노드에 여러 인벤토리 연결을 적용할 수 있는 경우 특정 우선 순위를 따릅니다.
### 인벤토리 연결 우선 순위
Systems Manager는 다음 우선 순위에 따라 인벤토리 연결을 적용합니다.
1. **Quick Setup 인벤토리 연결** - Quick Setup 및 통합 콘솔을 사용하여 생성된 연결입니다. 이러한 연결은 이름이 `AWS-QuickSetup-SSM-CollectInventory-`로 시작하고 모든 관리형 노드를 대상으로 합니다.
1. **명시적 인벤토리 연결** - 다음을 사용하여 특정 관리형 노드를 대상으로 하는 연결입니다.
+ 인스턴스 ID
+ 태그 키-값 페어
+ AWS 리소스 그룹
1. **글로벌 인벤토리 연결** - 모든 관리형 노드를 대상으로 하지만(`--targets "Key=InstanceIds,Values=*"` 사용) Quick Setup을 통해 생성되지 **않은** 연결입니다.
### 일반적인 시나리오
**시나리오 1: Quick Setup 연결이 명시적 연결을 재정의**
+ 모든 인스턴스를 대상으로 하는 Quick Setup 인벤토리 연결이 있습니다.
+ 태그별로 특정 관리형 노드를 대상으로 하는 수동 연결을 생성합니다.
+ 결과: 수동 연결에 `Skipped` 및 세부 상태 `OverriddenByExplicitInventoryAssociation`이 표시됩니다.
+ Quick Setup 연결은 모든 인스턴스에서 인벤토리를 계속 수집합니다.
**시나리오 2: 명시적 연결이 글로벌 연결을 재정의**
+ 모든 인스턴스를 대상으로 하는 글로벌 인벤토리 연결이 있습니다(Quick Setup에서 생성하지 않음).
+ 특정 인스턴스를 대상으로 하는 연결을 생성합니다.
+ 결과: 글로벌 연결이 특정 대상 인스턴스에 대해 `Skipped`를 표시합니다.
+ 명시적 연결이 대상 인스턴스에서 실행됩니다.
### 해결 단계
**Quick Setup 대신 자체 인벤토리 연결을 사용하려는 경우:**
1. **Quick Setup 연결 식별**: Systems Manager 콘솔에서 State Manager로 이동하여 이름이 `AWS-QuickSetup-SSM-CollectInventory-`로 시작하는 연결을 찾습니다.
1. **Quick Setup 구성 제거**:
+ Systems Manager 콘솔에서 Quick Setup으로 이동합니다.
+ 인벤토리 수집 구성을 찾습니다.
+ Quick Setup 구성을 삭제합니다(연결된 인벤토리 연결이 제거됨).
**참고**
Quick Setup에서 생성한 연결은 수동으로 삭제할 필요가 없습니다.
1. **연결 실행 확인**: Quick Setup 구성을 제거한 후 명시적 인벤토리 연결이 성공적으로 실행되기 시작해야 합니다.
**기존 동작을 수정하려는 경우:**
+ 기존 인벤토리 연결을 모두 보려면 Systems Manager 콘솔에서 **State Manager**를 선택한 다음 `AWS-GatherSoftwareInventory` SSM 문서를 사용하는 연결을 찾습니다.
+ 각 관리형 노드는 한 번에 하나의 활성 인벤토리 연결만 가질 수 있습니다.
**중요**
할당된(우선 순위가 더 높은) 인벤토리 연결이 실행될 때 건너뛴 노드에서 인벤토리 데이터가 계속 수집됩니다.
Quick Setup 인벤토리 연결은 명시적 대상 지정이 있는 유형까지 포함하여 다른 모든 유형보다 우선합니다.
연결 유형에 관계없이 우선 순위가 더 높은 연결로 재정의되는 경우 세부 상태 메시지 `OverriddenByExplicitInventoryAssociation`이 표시됩니다.
## 실패
인스턴스의 인벤토리 연결 상태가 **실패(Failed)**인 경우, 해당 인스턴스에 여러 개의 인벤토리 연결이 할당되었을 수 있습니다. 하나의 노드는 한 번에 한 개의 인벤토리 연결만 가질 수 있습니다. 인벤토리 연결은 `AWS-GatherSoftwareInventory` AWS Systems Manager 문서(SSM 문서)를 사용합니다. AWS Command Line Interface(AWS CLI)에서 다음 명령을 실행하여 노드에 대한 연결 목록을 볼 수 있습니다.
```
aws ssm describe-instance-associations-status --instance-id instance-ID
```
## Amazon EC2 인스턴스에 대한 인벤토리 규정 준수 실패
인스턴스에 여러 인벤토리 연결을 할당하면 Amazon Elastic Compute Cloud(Amazon EC2) 인스턴스에 대한 인벤토리 규정 준수가 실패할 수 있습니다.
이 문제를 해결하려면 인스턴스에 할당된 인벤토리 연결을 하나 이상 삭제합니다. 자세한 내용은 [연결 삭제](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-state-manager-delete-association.html)를 참조하세요.
**참고**
관리형 노드에 대해 여러 인벤토리 연결을 만드는 경우 다음 동작을 유의하세요.
각 노드에 *모든* 노드(--targets "Key=InstanceIds,Values=\$1")를 대상으로 하는 인벤토리 연결이 할당될 수 있습니다.
태그 키-값 페어 또는 AWS 리소스 그룹을 사용하는 특정 연결이 각 노드에 할당될 수도 있습니다.
노드에 여러 인벤토리 연결이 할당된 경우 실행되지 않은 연결에 대해 상태가 *건너뜀(Skipped)*으로 표시됩니다. 가장 최근에 실행된 연결은 인벤토리 연결의 실제 상태를 표시합니다.
노드에 여러 인벤토리 연결이 할당되고 각각 태그 키-값 페어를 사용하는 경우 태그 충돌로 인해 해당 인벤토리 연결이 노드에서 실행되지 않습니다. 태그 키-값 충돌이 없는 노드에서 연결이 계속 실행됩니다.
## S3 버킷 객체에 이전 데이터가 포함되어 있음
Amazon S3 버킷 객체 내부의 데이터는 인벤토리 연결이 성공하고 새 데이터가 발견되면 업데이트됩니다. Amazon S3 버킷 객체는 연결이 실행되고 실패할 때 노드마다 업데이트되지만, 이 경우 객체 내부의 데이터는 업데이트되지 않습니다. Amazon S3 버킷 객체 내부의 데이터는 연결이 성공적으로 실행될 때만 업데이트됩니다. 인벤토리 연결에 실패하면 Amazon S3 버킷 객체에 이전 데이터가 표시됩니다.