기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.

# CloudWatch 배포 계획
<a name="planning-cloudwatch-deployment"></a>

로깅 및 모니터링 솔루션의 복잡성과 범위는 다음과 같은 여러 요인에 따라 달라집니다.
+ 사용되는 환경, 리전 및 계정 수와이 수가 증가할 수 있는 방식.
+ 기존 워크로드 및 아키텍처의 다양성과 유형입니다.
+ 로깅하고 모니터링해야 하는 컴퓨팅 유형 및 OSs.
+ 온프레미스 위치와 AWS 인프라가 모두 있는지 여부.
+ 여러 시스템 및 애플리케이션의 집계 및 분석 요구 사항입니다.
+ 로그 및 지표의 무단 노출을 방지하는 보안 요구 사항입니다.
+ 운영 프로세스를 지원하기 위해 로깅 및 모니터링 솔루션과 통합해야 하는 제품 및 솔루션.

로깅 및 모니터링 솔루션을 정기적으로 검토하고 새 워크로드 배포 또는 업데이트된 워크로드 배포로 업데이트해야 합니다. 로깅, 모니터링 및 경보에 대한 업데이트는 문제가 관찰될 때 식별하고 적용해야 합니다. 그런 다음 이러한 문제를 사전에 식별하고 예방할 수 있습니다.

로그 및 지표를 캡처하고 수집하기 위한 소프트웨어 및 서비스를 지속적으로 설치하고 구성해야 합니다. 설정된 로깅 및 모니터링 접근 방식은 다양한 도메인(예: 보안, 성능, 네트워킹 또는 분석)에 대해 여러 AWS 또는 독립 소프트웨어 공급업체(ISV) 서비스 및 솔루션을 사용합니다. 각 도메인에는 고유한 배포 및 구성 요구 사항이 있습니다.

CloudWatch를 사용하여 여러 OSs 및 컴퓨팅 유형에 대한 로그와 지표를 캡처하고 수집하는 것이 좋습니다. 많은 AWS 서비스에서 CloudWatch를 사용하여 추가 구성 없이 로그 및 지표를 로깅, 모니터링 및 게시합니다. CloudWatch는 다양한 OS 및 환경에 설치 및 구성할 수 있는 [소프트웨어 에이전트](https://docs.aws.amazon.com//AmazonCloudWatch/latest/monitoring/Install-CloudWatch-Agent.html)를 제공합니다. OSs 다음 섹션에서는 여러 계정, 리전 및 구성에 대해 CloudWatch 에이전트를 배포, 설치 및 구성하는 방법을 간략하게 설명합니다.

**Topics**
+ [중앙 집중식 또는 분산 계정에서 CloudWatch 사용](cloudwatch-centralized-distributed-accounts.md)
+ [CloudWatch 에이전트 구성 파일 관리](create-store-cloudwatch-configurations.md)

# 중앙 집중식 또는 분산 계정에서 CloudWatch 사용
<a name="cloudwatch-centralized-distributed-accounts"></a>

CloudWatch는 한 계정 및 리전의 AWS 서비스 또는 리소스를 모니터링하도록 설계되었지만 중앙 계정을 사용하여 여러 계정 및 리전의 로그와 지표를 캡처할 수 있습니다. 둘 이상의 계정 또는 리전을 사용하는 경우 중앙 집중식 계정 접근 방식을 사용할지 아니면 개별 계정을 사용하여 로그 및 지표를 캡처할지 평가해야 합니다. 일반적으로 보안, 분석, 운영 및 워크로드 소유자의 요구 사항을 지원하기 위해 다중 계정 및 다중 리전 배포에는 하이브리드 접근 방식이 필요합니다.

다음 표에는 중앙 집중식, 분산형 또는 하이브리드 접근 방식을 사용하기로 선택할 때 고려해야 할 영역이 나와 있습니다.


****  

|  |  | 
| --- |--- |
| 계정 구조 | 조직에 여러 개의 개별 계정(예: 비프로덕션 및 프로덕션 워크로드에 대한 계정) 또는 특정 환경의 단일 애플리케이션에 대한 수천 개의 계정이 있을 수 있습니다. 워크로드가 실행되는 계정에 애플리케이션 로그 및 지표를 유지하여 워크로드 소유자에게 로그 및 지표에 대한 액세스 권한을 부여하는 것이 좋습니다. 이를 통해 로깅 및 모니터링에서 활성 역할을 가질 수 있습니다. 또한 별도의 로깅 계정을 사용하여 분석, 집계, 추세 및 중앙 집중식 작업을 위한 모든 워크로드 로그를 집계하는 것이 좋습니다. 보안, 아카이빙 및 모니터링, 분석에 별도의 로깅 계정을 사용할 수도 있습니다. | 
| 액세스 요구 사항 | 팀원(예: 워크로드 소유자 또는 개발자)은 문제를 해결하고 개선하기 위해 로그 및 지표에 액세스해야 합니다. 액세스 및 문제 해결을 더 쉽게 하려면 워크로드 계정에서 로그를 유지 관리해야 합니다. 로그 및 지표가 워크로드와 별도의 계정에 유지 관리되는 경우 사용자는 정기적으로 계정을 바꿔야 할 수 있습니다.중앙 집중식 계정을 사용하면 워크로드 계정에 대한 액세스 권한을 부여하지 않고 권한 있는 사용자에게 로그 정보를 제공합니다. 이를 통해 여러 계정에서 실행되는 워크로드에서 집계가 필요한 분석 워크로드의 액세스 요구 사항을 간소화할 수 있습니다. 중앙 집중식 로깅 계정에는 Amazon OpenSearch Service 클러스터와 같은 대체 검색 및 집계 옵션도 있을 수 있습니다. Amazon OpenSearch Service[는 로그에 대한 필드 수준까지 세분화된 액세스 제어를](https://docs.aws.amazon.com//opensearch-service/latest/developerguide/fgac.html) 제공합니다. 특수한 액세스 및 권한이 필요한 민감한 데이터나 기밀 데이터가 있는 경우 세분화된 액세스 제어가 중요합니다. | 
| 운영 | 많은 조직에 중앙 집중식 운영 및 보안 팀 또는 모니터링을 위해 로그에 액세스해야 하는 운영 지원을 위한 외부 조직이 있습니다. 중앙 집중식 로깅 및 모니터링을 사용하면 모든 계정 및 워크로드에서 추세를 쉽게 식별하고, 검색하고, 집계하고, 분석을 수행할 수 있습니다. 조직에서 DevOps에 대해 '[구축하여 실행'](https://aws.amazon.com//blogs/enterprise-strategy/enterprise-devops-why-you-should-run-what-you-build/) 접근 방식을 사용하는 경우 워크로드 소유자는 계정에 로깅 및 모니터링 정보가 필요합니다. 분산 워크로드 소유권 외에도 중앙 운영 및 분석을 충족하기 위해 하이브리드 접근 방식이 필요할 수 있습니다. | 
| 환경 |  프로덕션 계정의 중앙 위치에 로그 및 지표를 호스팅하고 보안 요구 사항 및 계정 아키텍처에 따라 다른 환경(예: 개발 또는 테스트)에 대한 로그 및 지표를 동일하거나 별도의 계정에 보관하도록 선택할 수 있습니다. 이렇게 하면 프로덕션 중에 생성된 민감한 데이터에 더 많은 사용자가 액세스하는 것을 방지할 수 있습니다.   | 

CloudWatch는 CloudWatch 구독 필터를 사용하여 로그를 실시간으로 처리할 수 있는 [여러 옵션을](https://docs.aws.amazon.com//AmazonCloudWatch/latest/logs/Subscriptions.html) 제공합니다. 구독 필터를 사용하여 사용자 지정 처리, 분석 및 다른 시스템으로 로드하기 위해 AWS 서비스에 실시간으로 로그를 스트리밍할 수 있습니다. 이는 중앙 집중식 계정 및 리전 외에도 개별 계정 및 리전에서 로그 및 지표를 사용할 수 있는 하이브리드 접근 방식을 취하는 경우 특히 유용할 수 있습니다. 다음 목록은 이를 위해 사용할 수 있는 AWS 서비스의 예를 제공합니다.
+ [Amazon Data Firehose](https://docs.aws.amazon.com//firehose/latest/dev/what-is-this-service.html) – Firehose는 생성되는 데이터 볼륨에 따라 자동으로 규모를 조정하고 크기를 조정하는 스트리밍 솔루션을 제공합니다. Amazon Kinesis 데이터 스트림의 샤드 수를 관리할 필요가 없으며 추가 코딩 없이 Amazon Simple Storage Service(Amazon S3), Amazon OpenSearch Service 또는 Amazon Redshift에 직접 연결할 수 있습니다. Firehose는 해당 AWS 서비스의 로그를 중앙 집중화하려는 경우 효과적인 솔루션입니다.
+ [Amazon Kinesis Data Streams](https://docs.aws.amazon.com//streams/latest/dev/introduction.html) – Kinesis Data Streams는 Firehose가 지원하지 않는 서비스와 통합하고 추가 처리 로직을 구현해야 하는 경우 적절한 솔루션입니다. 중앙 계정의 Kinesis 데이터 스트림과 스트림에 레코드를 배치할 수 있는 권한을 부여하는 AWS Identity and Access Management (IAM) 역할을 지정하는 Amazon CloudWatch Logs 대상을 계정 및 리전에 생성할 수 있습니다. Kinesis Data Streams는 다양한 옵션에서 사용할 수 있는 로그 데이터를 위한 유연한 개방형 랜딩 존을 제공합니다. Kinesis Data Streams 로그 데이터를 계정으로 읽고, 사전 처리를 수행하고, 선택한 대상으로 데이터를 전송할 수 있습니다.

  그러나 스트림의 샤드를 구성하여 생성된 로그 데이터에 맞게 크기를 적절하게 조정해야 합니다. Kinesis Data Streams는 로그 데이터에 대한 임시 중개자 또는 대기열 역할을 하며 1\$1365일 동안 Kinesis 스트림 내에 데이터를 저장할 수 있습니다. Kinesis Data Streams는 재생 기능도 지원하므로 사용하지 않은 데이터를 재생할 수 있습니다.
+ [Amazon OpenSearch Service](https://docs.aws.amazon.com//opensearch-service/latest/developerguide/what-is.html) – CloudWatch Logs는 로그 그룹의 로그를 개별 또는 중앙 집중식 계정의 OpenSearch 클러스터로 스트리밍할 수 있습니다. OpenSearch 클러스터로 데이터를 스트리밍하도록 로그 그룹을 구성하면 로그 그룹과 동일한 계정 및 리전에 Lambda 함수가 생성됩니다. Lambda 함수는 OpenSearch 클러스터와 네트워크 연결이 있어야 합니다. Amazon OpenSearch Service로 수집을 사용자 지정하는 것 외에도 추가 사전 처리를 수행하도록 Lambda 함수를 사용자 지정할 수 있습니다. Amazon OpenSearch Service를 사용한 중앙 집중식 로깅을 사용하면 클라우드 아키텍처의 여러 구성 요소에서 문제를 더 쉽게 분석, 검색 및 해결할 수 있습니다.
+ [Lambda](https://docs.aws.amazon.com//lambda/latest/dg/welcome.html) - Kinesis Data Streams를 사용하는 경우 스트림의 데이터를 소비하는 컴퓨팅 리소스를 프로비저닝하고 관리해야 합니다. 이를 방지하기 위해 로그 데이터를 처리를 위해 Lambda로 직접 스트리밍하고 로직에 따라 대상으로 전송할 수 있습니다. 즉, 수신 데이터를 처리하기 위해 컴퓨팅 리소스를 프로비저닝하고 관리할 필요가 없습니다. Lambda를 사용하기로 선택한 경우 솔루션이 [Lambda 할당량](https://docs.aws.amazon.com//lambda/latest/dg/gettingstarted-limits.html)과 호환되는지 확인합니다.

CloudWatch Logs에 저장된 로그 데이터를 파일 형식으로 처리하거나 공유해야 할 수 있습니다. 내보내기 작업을 생성하여 특정 날짜 또는 시간 범위에 대해 [로그 그룹을 Amazon S3로 내보낼](https://docs.aws.amazon.com//AmazonCloudWatch/latest/logs/S3Export.html) 수 있습니다. 예를 들어 분석 및 감사를 위해 매일 Amazon S3로 로그를 내보내도록 선택할 수 있습니다. Lambda를 사용하여이 솔루션을 자동화할 수 있습니다. 또한이 솔루션을 Amazon S3 복제와 결합하여 여러 계정 및 리전의 로그를 하나의 중앙 집중식 계정 및 리전으로 전송하고 중앙 집중화할 수 있습니다.

CloudWatch 에이전트 구성은 [`agent` 섹션에서](https://docs.aws.amazon.com//AmazonCloudWatch/latest/monitoring/CloudWatch-Agent-Configuration-File-Details.html#CloudWatch-Agent-Configuration-File-Agentsection) `credentials` 필드를 지정할 수도 있습니다. 이는 지표와 로그를 다른 계정으로 전송할 때 사용할 IAM 역할을 지정합니다. 지정된 경우이 필드에 `role_arn` 파라미터가 포함됩니다. 이 필드는 특정 중앙 집중식 계정 및 리전에서 중앙 집중식 로깅 및 모니터링만 필요한 경우에 사용할 수 있습니다.

[AWS SDK](https://aws.amazon.com/developer/tools/)를 사용하여 원하는 언어로 사용자 지정 처리 애플리케이션을 작성하고, 계정에서 로그 및 지표를 읽고, 추가 처리 및 모니터링을 위해 중앙 집중식 계정 또는 기타 대상으로 데이터를 전송할 수도 있습니다.

# CloudWatch 에이전트 구성 파일 관리
<a name="create-store-cloudwatch-configurations"></a>

모든 Amazon Elastic Compute Cloud(Amazon EC2) 인스턴스 및 온프레미스 서버에서 캡처하려는 시스템 로그 및 지표가 포함된 표준 Amazon CloudWatch 에이전트 구성을 생성하는 것이 좋습니다.Amazon EC2 CloudWatch 에이전트 [구성 파일 마법사](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/create-cloudwatch-agent-configuration-file-wizard.html)를 사용하여 구성 파일을 생성할 수 있습니다. 구성 마법사를 여러 번 실행하여 다양한 시스템 및 환경에 대한 고유한 구성을 생성할 수 있습니다. 구성 파일 [스키마를 사용하여 구성 파일을](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Agent-Configuration-File-Details.html) 수정하거나 변형을 생성할 수도 있습니다. CloudWatch 에이전트 구성 파일은 [AWS Systems Manager 파라미터 스토어](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-parameter-store.html) 파라미터에 저장할 수 있습니다.  [CloudWatch 에이전트 구성 파일이 여러](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Agent-common-scenarios.html#CloudWatch-Agent-multiple-config-files) 개 있는 경우 별도의 파라미터 스토어 파라미터를 생성할 수 있습니다. 여러 AWS 계정 또는 AWS 리전을 사용하는 경우 각 계정 및 리전에서 파라미터 스토어 파라미터를 관리하고 업데이트해야 합니다. 또는 CloudWatch 구성을 Amazon S3의 파일 또는 원하는 버전 제어 도구로 중앙에서 관리할 수 있습니다. 

CloudWatch 에이전트에 포함된 `amazon-cloudwatch-agent-ctl` 스크립트를 사용하면 구성 파일, 파라미터 스토어 파라미터 또는 에이전트의 기본 구성을 지정할 수 있습니다. 기본 구성은 사전 정의된 기본 지표 세트에 맞게 조정되고 메모리 및 디스크 공간 지표를 CloudWatch에 보고하도록 에이전트를 구성합니다. 그러나 로그 파일 구성은 포함되지 않습니다. CloudWatch 에이전트에 [Systems Manager 빠른 설정을](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-quick-setup.html) 사용하는 경우에도 기본 구성이 적용됩니다.

기본 구성에는 로깅이 포함되지 않고 요구 사항에 맞게 사용자 지정되지 않으므로 요구 사항에 맞게 사용자 지정된 자체 CloudWatch 구성을 생성하고 적용하는 것이 좋습니다.

## CloudWatch 구성 관리
<a name="store-cloudwatch-configuration-s3"></a>

기본적으로 CloudWatch 구성은 파라미터 스토어 파라미터 또는 CloudWatch 구성 파일로 저장 및 적용할 수 있습니다. 최선의 선택은 요구 사항에 따라 달라집니다. 이 섹션에서는이 두 옵션의 장단점에 대해 설명합니다. 여러 AWS 계정 및 AWS 리전에 대한 CloudWatch 구성 파일을 관리하기 위한 대표적인 솔루션도 자세히 설명되어 있습니다.

**Systems Manager 파라미터 스토어 파라미터**

작은 AWS 계정 및 리전 집합에서 적용하고 관리하려는 표준 CloudWatch 에이전트 구성 파일이 하나 있는 경우 파라미터 스토어 파라미터를 사용하여 CloudWatch 구성을 관리하는 것이 좋습니다. CloudWatch CloudWatch 구성을 파라미터 스토어 파라미터로 저장할 때 CloudWatch 에이전트 구성 도구(`amazon-cloudwatch-agent-ctl`Linux 기반)를 사용하여 구성 파일을 인스턴스에 복사할 필요 없이 파라미터 스토어에서 구성을 읽고 적용할 수 있습니다. **AmazonCloudWatch-ManageAgent **Systems Manager Command 문서를 사용하여 한 번의 실행으로 여러 EC2 인스턴스에서 CloudWatch 구성을 업데이트할 수 있습니다. 파라미터 스토어 파라미터는 리전 파라미터이므로 각 AWS 리전 및 AWS 계정에서 CloudWatch 파라미터 스토어 파라미터를 업데이트하고 유지 관리해야 합니다. 각 인스턴스에 적용하려는 CloudWatch 구성이 여러 개 있는 경우 이러한 파라미터를** **포함하도록 **AmazonCloudWatch-ManageAgent** Command 문서를 사용자 지정해야 합니다.

**CloudWatch 구성 파일**

AWS 계정과 리전이 많고 여러 CloudWatch 구성 파일을 관리하는 경우 CloudWatch 구성을 파일로 관리하는 것이 효과적일 수 있습니다. 이 접근 방식을 사용하면 폴더 구조에서 탐색, 구성 및 관리할 수 있습니다.   개별 폴더 또는 파일에 보안 규칙을 적용하여 업데이트 및 읽기 권한과 같은 액세스를 제한하고 부여할 수 있습니다. 공동 작업을 위해 AWS 외부에서 공유 및 전송할 수 있습니다. 파일을 버전 관리하여 변경 사항을 추적하고 관리할 수 있습니다. 각 CloudWatch 구성 파일을 개별적으로 적용하지 않고 구성 파일을 CloudWatch 에이전트 구성 디렉터리에 복사하여 CloudWatch 구성을 일괄 적용할 수 있습니다. Linux의 경우 CloudWatch 구성 디렉터리는에 있습니다`/opt/aws/amazon-cloudwatch-agent/etc/amazon-cloudwatch-agent.d`. Windows의 경우 구성 디렉터리는에 있습니다`C:\ProgramData\Amazon\AmazonCloudWatchAgent\Configs`.

CloudWatch 에이전트를 시작하면 에이전트는 이러한 디렉터리에 있는 각 파일을 자동으로 추가하여 CloudWatch 복합 구성 파일을 생성합니다. 구성 파일은 필요한 계정 및 리전에서 액세스할 수 있는 중앙 위치(예: S3 버킷)에 저장해야 합니다. 이 접근 방식을 사용하는 예제 솔루션이 제공됩니다.

**CloudWatch 구성 구성**

CloudWatch 구성을 관리하는 데 사용되는 접근 방식에 관계없이 CloudWatch 구성을 구성합니다. 다음과 같은 접근 방식을 사용하여 구성을 파일 또는 파라미터 스토어 경로로 구성할 수 있습니다.


|  |  | 
| --- |--- |
| */config/standard/windows/ec2* | Amazon EC2에 대한 표준 Windows별 CloudWatch 구성 파일을 저장합니다. 이 폴더 아래의 다양한 Windows 버전, EC2 인스턴스 유형 및 환경에 대한 표준 운영 체제(OS) 구성을 추가로 분류할 수 있습니다. | 
| */config/standard/windows/onpremises* | 온프레미스 서버에 대한 표준 Windows별 CloudWatch 구성 파일을 저장합니다. 또한이 폴더에서 다양한 Windows 버전, 서버 유형 및 환경에 대한 표준 OS 구성을 추가로 분류할 수 있습니다. | 
| */config/standard/linux/ec2* | Amazon EC2에 대한 표준 Linux별 CloudWatch 구성 파일을 저장합니다. 이 폴더 아래의 다양한 Linux 배포, EC2 인스턴스 유형 및 환경에 대한 표준 OS 구성을 추가로 분류할 수 있습니다. | 
| */config/standard/linux/온프레미스* | 온프레미스 서버에 대한 표준 Linux별 CloudWatch 구성 파일을 저장합니다. 이 폴더에서 다양한 Linux 배포, 서버 유형 및 환경에 대한 표준 OS 구성을 추가로 분류할 수 있습니다. | 
| */config/ecs* | Amazon ECS 컨테이너 인스턴스를 사용하는 경우 Amazon Elastic Container Service(Amazon ECS)와 관련된 CloudWatch 구성 파일을 저장합니다. 이러한 구성은 Amazon ECS 특정 시스템 수준 로깅 및 모니터링을 위한 표준 Amazon EC2 구성에 추가할 수 있습니다. | 
| */config/<application\$1name>* | 애플리케이션별 CloudWatch 구성 파일을 저장합니다. 환경 및 버전에 대한 추가 폴더 및 접두사를 사용하여 애플리케이션을 추가로 분류할 수 있습니다. | 

## 예: S3 버킷에 CloudWatch 구성 파일 저장
<a name="example"></a>

이 섹션에서는 Amazon S3를 사용하여 CloudWatch 구성 파일을 저장하는 예제와 CloudWatch 구성 파일을 검색하고 적용하는 사용자 지정 Systems Manager 실행서를 제공합니다. 이 접근 방식은 CloudWatch 구성에 Systems Manager Parameter Store 파라미터를 대규모로 사용할 때 발생하는 몇 가지 문제를 해결할 수 있습니다.
+ 여러 리전을 사용하는 경우 각 리전의 파라미터 스토어에서 CloudWatch 구성 업데이트를 동기화해야 합니다. Parameter Store는 리전 서비스이며 CloudWatch 에이전트를 사용하는 각 리전에서 동일한 파라미터를 업데이트해야 합니다.
+ CloudWatch 구성이 여러 개 있는 경우 각 Parameter Store 구성의 검색 및 적용을 시작해야 합니다. 파라미터 스토어에서 각 CloudWatch 구성을 개별적으로 검색하고 새 구성을 추가할 때마다 검색 방법을 업데이트해야 합니다. 반면 CloudWatch는 구성 파일을 저장하기 위한 구성 디렉터리를 제공하며, 구성 파일을 개별적으로 지정할 필요 없이 디렉터리에 각 구성을 적용합니다.
+ 여러 계정을 사용하는 경우 각 새 계정에 파라미터 스토어에 필요한 CloudWatch 구성이 있는지 확인해야 합니다. 또한 향후 이러한 계정 및 해당 리전에 구성 변경 사항이 적용되도록 해야 합니다.

CloudWatch 구성을 모든 계정 및 리전에서 액세스할 수 있는 S3 버킷에 저장할 수 있습니다. 그런 다음 Systems Manager Automation 실행서 및 Systems Manager 상태 관리자를 사용하여 S3 버킷에서 CloudWatch 구성 디렉터리로 이러한 구성을 복사할 수 있습니다. [cloudwatch-config-s3-bucket.yaml](https://github.com/aws-samples/logging-monitoring-apg-guide-examples/blob/main/cloudwatch-config-s3-bucket.yaml) AWS CloudFormation 템플릿을 사용하여 AWS Organizations의 조직 내 여러 계정에서 액세스할 수 있는 S3 버킷을 생성할 수 있습니다. AWS Organizations 템플릿에는 [조직](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_getting-started_concepts.html) 내 모든 계정에 대한 읽기 액세스 권한을 부여하는 파라미터가 포함되어 `OrganizationID` 있습니다.

이 가이드의 [상태 관리자 및 Distributor for CloudWatch 에이전트 배포 및 구성 설정 섹션에 제공된 증강 샘플 Systems Manager](https://docs.aws.amazon.com/prescriptive-guidance/latest/implementing-logging-monitoring-cloudwatch/install-cloudwatch-systems-manager.html#set-up-systems-manager-distributor) 실행서는 [cloudwatch-config-s3-bucket.yaml](https://github.com/aws-samples/logging-monitoring-apg-guide-examples/blob/main/cloudwatch-config-s3-bucket.yaml) AWS CloudFormation 템플릿으로 생성된 S3 버킷을 사용하여 파일을 검색하도록 구성됩니다.

또는 버전 관리 시스템(예: GitHub)을 사용하여 구성 파일을 저장할 수 있습니다. 버전 관리 시스템에 저장된 구성 파일을 자동으로 검색하려면 자격 증명 스토리지를 관리 또는 중앙 집중화하고 계정 및 전체에서 자격 증명을 검색하는 데 사용되는 Systems Manager Automation 런북을 업데이트해야 합니다 AWS 리전.