기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
# AWS DevOps Agent에 대한 기능 구성
AWS DevOps 에이전트 기능은 에이전트를 기존 도구 및 인프라에 연결하여 에이전트의 기능을 확장합니다. 이러한 기능을 구성하여 포괄적인 인시던트 조사, 자동화된 대응 워크플로, DevOps 에코시스템과의 원활한 통합을 지원합니다.
다음 기능은 DevOps 에이전트의 효과를 극대화하는 데 도움이 됩니다.
+ **AWS EKS 액세스 설정** - 퍼블릭 및 프라이빗 EKS 환경 모두에 대해 Kubernetes 클러스터, 포드 로그 및 클러스터 이벤트의 내부 검사 활성화
+ **Azure 통합** - Azure 구독 및 Azure DevOps 조직을 연결하여 Azure 리소스를 조사하고 Azure DevOps 배포와 인시던트의 상관관계를 파악합니다.
+ **CI/CD 파이프라인 통합** - GitHub 및 GitLab 파이프라인을 연결하여 배포를 인시던트와 연관시키고 조사 중에 코드 변경을 추적합니다.
+ **MCP 서버 연결** - 모델 컨텍스트 프로토콜을 통해 외부 관찰성 도구와 사용자 지정 모니터링 시스템을 연결하여 조사 기능 확장
+ **다중 계정 AWS 액세스 -** 인시던트 대응 중에 전체 조직의 리소스를 조사하도록 보조 AWS 계정을 구성합니다.
+ **원격 측정 소스 통합** - 포괄적인 관찰성 데이터 액세스를 위해 Datadog, Dynatrace, Grafana, New Relic 및 Splunk와 같은 모니터링 플랫폼을 연결합니다.
+ **티켓팅 및 채팅 통합** - ServiceNow, PagerDuty 및 Slack을 연결하여 인시던트 대응 워크플로를 자동화하고 팀 협업을 활성화합니다.
+ **Webhook 구성** - 외부 시스템이 HTTP 요청을 통해 DevOps 에이전트 조사를 자동으로 트리거하도록 허용
+ **Amazon EventBridge 통합** - 조사 및 완화 수명 주기 이벤트를 Amazon EventBridge 대상으로 라우팅하여 이벤트 기반 애플리케이션에 AWS DevOps 에이전트 통합
팀의 특정 요구 사항과 기존 도구 스택에 따라 각 기능을 독립적으로 구성할 수 있습니다. 인시던트 대응 워크플로에 가장 중요한 통합으로 시작한 다음 필요에 따라 추가 기능으로 확장합니다.
# 공개 미리 보기에서 정식 출시로 마이그레이션
공개 미리 보기 중에 AWS DevOps 에이전트를 사용한 경우 GA 릴리스 전에 IAM 역할을 업데이트해야 합니다. 이 가이드에서는 계정의 모니터링 역할 및 운영자 역할을 업데이트하는 방법을 안내합니다.
## 변경 사항
1. [미리 보기 중 온디맨드 채팅 기록에 더 이상 액세스할 수 없음](#on-demand-chat-history-from-public-preview)
1. [새로운 관리형 정책은 미리 보기 중에 사용 가능한 정책을 대체합니다.](#new-managed-policies)
1. [에이전트 스페이스에는 오래된 IAM Identity Center 애플리케이션 액세스 범위가 있을 수 있습니다.](#reconnect-iam-identity-center-if-applicable)
## 공개 미리 보기의 온디맨드 채팅 기록
GA 릴리스에는 채팅 기록에 대한 액세스 제어를 강화하기 위한 추가 보안 조치가 도입되었습니다. 이러한 변경으로 인해 공개 미리 보기 기간(2026년 3월 30일 이전)의 온디맨드 채팅 기록에 더 이상 액세스할 수 없습니다. 공개 미리 보기 중에 생성된 조사 저널 및 조사 결과는 영향을 받지 않습니다. **이 변경 사항은 온디맨드 채팅 대화에만 적용됩니다.**
## 새로운 관리형 정책
GA의 경우 미리 보기 기간 정책을 대체하는 새 관리형 정책을 AWS 제공합니다.
| 역할 유형 | 제거 | 더하기 |
| --- | --- | --- |
| 모니터링 | AIOpsAssistantPolicy 관리형 정책 | AIDevOpsAgentAccessPolicy 관리형 정책 |
| 연산자(IAM 및 IDC) | 인라인 정책 | AIDevOpsOperatorAppAccessPolicy 관리형 정책 |
또한 운영자 역할에는 업데이트된 신뢰 정책이 필요하고 IDC 운영자 역할에는 새 인라인 정책이 필요합니다.
### 사전 조건
+ DevOps 에이전트 역할이 구성된 AWS 계정에 대한 액세스(기본 및 모든 보조 계정)
+ 역할, 정책 및 신뢰 관계를 수정할 수 있는 IAM 권한
+ 에이전트 스페이스 ID, AWS 계정 ID 및 리전( DevOps 에이전트 콘솔에서 볼 수 있음)
### 1단계: 모니터링 역할 업데이트
기본 계정 및 각 보조 계정에서 모니터링 역할을 업데이트합니다. 다음은 에이전트 공간의 **기능** 탭 아래에 구성된 기본/보조 소스 역할입니다(예: 기본/보조 역할: `DevOpsAgentRole-AgentSpace-3xj2396z`).
1. DevOps 에이전트 콘솔에서 에이전트 공간으로 이동하여 **기능** 탭을 선택합니다.
1. 기본/보조 소스의 모니터링 역할(예: `DevOpsAgentRole-AgentSpace-3xj2396z`)을 찾아 **편집**을 선택합니다.
1. **권한 정책**에서 `AIOpsAssistantPolicy` AWS 관리형 정책을 제거합니다.
1. **권한 추가**, **정책 연결을** 선택하고 `AIDevOpsAgentAccessPolicy` 관리형 정책을 연결합니다.
1. 인라인 정책을 편집하고 해당 내용을 다음으로 대체하여 계정 ID를 대체합니다.
```
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowCreateServiceLinkedRoles",
"Effect": "Allow",
"Action": [
"iam:CreateServiceLinkedRole"
],
"Resource": [
"arn:aws:iam:::role/aws-service-role/resource-explorer-2.amazonaws.com/AWSServiceRoleForResourceExplorer"
]
}
]
}
```
1. 모니터링 역할에 대한 신뢰 정책은 변경할 필요가 없습니다. 다음과 일치하는지 확인합니다.
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "aidevops.amazonaws.com"
},
"Action": "sts:AssumeRole",
"Condition": {
"StringEquals": {
"aws:SourceAccount": ""
},
"ArnLike": {
"aws:SourceArn": "arn:aws:aidevops:::agentspace/*"
}
}
}
]
}
```
+ 각 보조 계정의 모니터링 역할에 대해 2\$16단계를 반복합니다.
### 2단계: 연산자 역할 업데이트(IAM)
1. DevOps 에이전트 콘솔에서 **액세스** 탭을 선택하고 운영자 역할을 찾습니다.
1. IAM 콘솔에서 연산자 역할에서 기존 인라인 정책을 제거합니다.
1. **권한 추가**, **정책 연결을** 선택하고 `AIDevOpsOperatorAppAccessPolicy` 관리형 정책을 연결합니다.
1. **신뢰 관계** 탭을 선택하고 **신뢰 정책 편집**을 선택합니다. 계정 ID, 리전 및 에이전트 스페이스 ID를 대체하여 신뢰 정책을 다음으로 바꿉니다.
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "aidevops.amazonaws.com"
},
"Action": ["sts:AssumeRole", "sts:TagSession"],
"Condition": {
"StringEquals": {
"aws:SourceAccount": ""
},
"ArnEquals": {
"aws:SourceArn": "arn:aws:aidevops:::agentspace/"
}
}
}
]
}
```
### 3단계: 운영자 역할 업데이트(IDC)
DevOps 에이전트와 함께 IAM Identity Center를 사용하는 경우 각 IDC 운영자 역할을 업데이트합니다.
1. IAM 콘솔에서 **역할**로 이동하여를 검색`WebappIDC`하여 DevOps 에이전트 IDC 역할(예: `DevOpsAgentRole-WebappIDC-`)을 찾습니다.
1. 각 IDC 역할에 대해:
a. 기존 인라인 정책을 제거합니다.
b. **권한 추가**, **정책 연결을** 선택하고 `AIDevOpsOperatorAppAccessPolicy` 관리형 정책을 연결합니다.
c. **신뢰 관계** 탭을 선택하고 **신뢰 정책 편집**을 선택합니다. 계정 ID, 리전 및 에이전트 스페이스 ID를 대체하여 신뢰 정책을 다음으로 바꿉니다.
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "aidevops.amazonaws.com"
},
"Action": ["sts:AssumeRole", "sts:TagSession"],
"Condition": {
"StringEquals": {
"aws:SourceAccount": ""
},
"ArnEquals": {
"aws:SourceArn": "arn:aws:aidevops:::agentspace/"
}
}
},
{
"Sid": "TrustedIdentityPropagation",
"Effect": "Allow",
"Principal": {
"Service": "aidevops.amazonaws.com"
},
"Action": "sts:SetContext",
"Condition": {
"StringEquals": {
"aws:SourceAccount": ""
},
"ArnEquals": {
"aws:SourceArn": "arn:aws:aidevops:::agentspace/"
},
"ForAllValues:ArnEquals": {
"sts:RequestContextProviders": [
"arn:aws:iam::aws:contextProvider/IdentityCenter"
]
},
"Null": {
"sts:RequestContextProviders": "false"
}
}
}
]
}
```
d. 계정 ID를 대체하여 다음 권한으로 새 인라인 정책을 생성합니다.
```
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowDevOpsAgentSSOAccess",
"Effect": "Allow",
"Action": [
"sso:ListInstances",
"sso:DescribeInstance"
],
"Resource": "*"
},
{
"Sid": "AllowDevOpsAgentIDCUserAccess",
"Effect": "Allow",
"Action": "identitystore:DescribeUser",
"Resource": [
"arn:aws:identitystore:::identitystore/*",
"arn:aws:identitystore:::user/*"
]
}
]
}
```
## IAM Identity Center 다시 연결(해당하는 경우)
공개 미리 보기 중에 생성된 에이전트 공간에는 오래된 액세스 범위로 구성된 IAM Identity Center 애플리케이션이 있을 수 있습니다. GA의 경우 올바른 범위는 입니다**`aidevops:read_write`**. IAM Identity Center 애플리케이션에 이전 범위(**`awsaidevops:read_write`**)가 있는 경우 IAM Identity Center의 연결을 끊었다가 다시 연결해야 합니다.
### IAM Identity Center 애플리케이션 범위를 확인하는 방법
다음 AWS CLI 명령을 실행하여 IAM Identity Center 애플리케이션의 범위를 확인합니다. 애플리케이션 아래의 IAM Identity Center 콘솔에서 **애플리케이션** ARN을 찾을 수 있습니다.
```
aws sso-admin list-application-access-scopes \
--application-arn arn:aws:sso:::application//
```
출력에 올바른 범위가 표시되어야 합니다**`aidevops:read_write`**.
```
{
"Scopes": [
{
"Scope": "aidevops:read_write"
}
]
}
```
범위에가 표시되면 오래된 **`awsaidevops:read_write`**것입니다. 아래 단계에 따라 업데이트합니다.
### IAM Identity Center를 다시 연결하는 방법
AWS 관리형 IAM Identity Center 애플리케이션의 액세스 범위는 직접 업데이트할 수 없습니다. 연결을 끊었다가 다시 연결해야 합니다.
1. AWS DevOps 에이전트 콘솔에서 에이전트 공간으로 이동하여 **액세스** 탭을 선택합니다.
1. IAM Identity Center 구성 옆에 있는 **연결 해제**를 선택합니다.
1. 연결 해제를 확인합니다.
1. **연결을** 선택하여 IAM Identity Center를 다시 설정합니다. 서비스는 올바른 범위를 가진 새 IAM Identity Center 애플리케이션을 생성합니다.
1. IAM Identity Center 콘솔에서 새 애플리케이션에 사용자 및 그룹을 재할당합니다.
**중요**
연결을 해제하면 IAM Identity Center 사용자 계정과 연결된 개별 사용자 채팅 및 아티팩트 기록이 제거됩니다. 사용자는 다시 연결한 후 다시 로그인해야 합니다.
## Verification(확인)
모든 단계를 완료한 후:
1. DevOps 에이전트 콘솔로 돌아가 에이전트 스페이스 **액세스** 탭에 권한 오류가 나타나지 않는지 확인합니다.
1. 연산자 웹 앱을 테스트하여 올바르게 로드되고 작동하는지 확인합니다.
1. IDC를 사용하는 경우 사용자가 운영자 환경을 인증하고 액세스할 수 있는지 확인합니다.
## 문제 해결
**마이그레이션 후 권한 거부 오류**
+ 이 제거`AIOpsAssistantPolicy`되었고 모니터링 역할에 `AIDevOpsAgentAccessPolicy` 연결되어 있는지 확인합니다.
+ 이전 인라인 정책`AIDevOpsOperatorAppAccessPolicy`이 제거되었고 운영자 역할에 연결되어 있는지 확인합니다.
+ 연산자 신뢰 정책에가 포함되어 있는지 확인합니다`sts:TagSession`.
+ 모든 자리 표시자 값(``, ``, ``)을 실제 값으로 바꾸었는지 확인합니다.
**보조 계정이 작동하지 않음**
+ 각 보조 계정의 모니터링 역할은 독립적으로 업데이트해야 합니다. 각 계정에 로그인하고 1단계를 반복합니다.
**IDC 인증 실패**
+ IDC 신뢰 정책에 `sts:AssumeRole`/`sts:TagSession` 문과 `TrustedIdentityPropagation` 문이 모두 포함되어 있는지 확인합니다.
+ `sso:ListInstances`, `sso:DescribeInstance`및를 사용하여 인라인 정책이 생성`identitystore:DescribeUser`되었는지 확인합니다.
**마이그레이션 후 온디맨드 채팅 기록 누락**
+ GA 릴리스 후에는 공개 미리 보기 기간의 온디맨드 채팅 기록에 액세스할 수 없습니다. 이는 GA에 도입된 향상된 보안 조치로 인해 예상되는 동작입니다. 조사 저널 및 공개 미리 보기 결과는 영향을 받지 않습니다.
# AWS EKS 액세스 설정
퍼블릭 클러스터와 프라이빗 클러스터 모두에 대해 읽기 전용 `kubectl` 명령을 실행하여 Amazon EKS 클러스터의 문제를 조사 AWS DevOps 할 수 있습니다. 원하는 수의 EKS 클러스터를 동일한 에이전트 스페이스에 연결할 수 있습니다.
연결되면 에이전트는 리소스 설명, 포드 로그 검색, 클러스터 이벤트 검사, 노드 상태 확인 등 클러스터의 운영 문제를 진단하는 데 도움이 될 수 있습니다. 에이전트는 클러스터에서 리소스를 생성, 수정 또는 삭제할 수 없습니다.
## 사전 조건
EKS 액세스를 설정하기 전에 EKS 클러스터의 인증 모드에 EKS API가 포함되어 있는지 확인합니다. [Amazon EKS 콘솔](https://console.aws.amazon.com/eks)의 **액세스** 탭에서 이를 확인할 수 있습니다. 모드에 EKS API가 포함되지 않은 경우 진행하기 전에에서 수행하는 모드를 선택합니다.
## 설정
이러한 단계는 액세스 항목을 생성하려는 각 클러스터의 [Amazon EKS 콘솔](https://console.aws.amazon.com/eks)에서 완료해야 합니다. IAM 역할 ARN은 에이전트 스페이스( 참조[에이전트 스페이스 생성](getting-started-with-aws-devops-agent-creating-an-agent-space.md))의 **기능 > 클라우드 > 기본 소스 > 편집**에서 찾을 수 있습니다.
1. **액세스** 탭으로 이동합니다. 인증 모드에 이미 EKS API가 표시된 경우 액세스 항목을 추가할 수 있습니다. 그렇지 않으면 EKS API가 포함된 모드를 선택합니다.
1. 액세스 탭에서 새 IAM 액세스 항목을 생성합니다. 기본 클라우드 소스 IAM 역할 ARN을 복사하여 액세스 항목의 IAM 보안 주체로 입력합니다. **다음**을 클릭합니다.
1. AWS 관리형 **AmazonAIOpsAssistantPolicy** 액세스 정책을 선택하고 액세스 범위에 대해 **클러스터**를 선택합니다. (또는 에이전트가 특정 네임스페이스에만 액세스하도록 하려면 원하는 **Kubernetes 네임스페이스**를 선택합니다.) **정책 추가**를 클릭한 **후 다음을** 클릭합니다.
1. 변경 사항을 검토하고 올바른 액세스 항목 정책 및 IAM 역할이 선택되었는지 확인하고 **"생성"**을 클릭하여 액세스 항목을 생성합니다.
EKS 액세스가 올바르게 구성되었는지 확인하려면 운영자 앱으로 이동하여 에이전트에게 "기본 네임스페이스의 모든 포드 나열" 또는 "클러스터의 최근 이벤트 표시"와 같은 클러스터에 대한 질문을 하여 새 조사를 시작합니다.
## 문제 해결
에이전트가 클러스터에 연결할 수 없는 경우 액세스 항목이 설정 대화 상자에 표시된 올바른 IAM 역할 ARN을 사용하고 있고 **AmazonAIOpsAssistantPolicy** 액세스 정책이 연결되어 있는지 확인합니다.
# Azure 연결
Azure 통합을 통해 AWS DevOps Agent는 Azure 환경의 리소스를 조사하고 Azure DevOps 파이프라인 배포와 운영 인시던트의 상관관계를 파악할 수 있습니다. 에이전트는 Azure를 연결하여 Azure 인프라에 대한 가시성을 확보하고 AWS 및 Azure 리소스 모두에서 근본 원인 분석을 수행할 수 있습니다.
Azure 통합은 두 가지 독립적인 기능으로 구성됩니다.
+ **Azure 리소스** - 에이전트가 가상 머신, Azure Kubernetes Service(AKS) 클러스터, 데이터베이스 및 네트워킹 구성 요소와 같은 Azure 클라우드 리소스를 검색하고 조사할 수 있습니다. 에이전트는 Azure 리소스 그래프를 사용하여 인시던트 조사 중에 리소스를 쿼리합니다.
+ **Azure DevOps** - 에이전트가 Azure DevOps 리포지토리 및 파이프라인 실행 내역에 액세스할 수 있습니다. 에이전트는 코드 변경 및 배포를 인시던트와 연관시켜 잠재적 근본 원인을 식별할 수 있습니다.
각 기능은 AWS 계정 수준에서 등록된 다음 개별 에이전트 스페이스와 연결할 수 있습니다.
## 등록 방법
AWS DevOps Agent는 Azure에 연결하는 두 가지 방법을 지원합니다.
+ **관리자 동의** - Azure 테넌트에서 AWS DevOps 에이전트 Entra 애플리케이션을 승인하는 간소화된 동의 기반 흐름입니다. 콘솔에서 관리자 **동의** 옵션으로 표시됩니다. 이 방법을 사용하려면 Microsoft Entra ID에서 관리자 동의를 수행할 권한이 있는 계정으로 로그인해야 합니다.
+ **앱 등록** - 아웃바운드 자격 증명 연동을 사용하여 페더레이션 자격 증명으로 자체 Entra 애플리케이션을 생성하는 자체 관리형 접근 방식입니다. 콘솔에서 **앱 등록** 옵션으로 표시됩니다. 이 방법은 애플리케이션 구성을 더 잘 제어해야 하거나 관리자 동의 권한을 사용할 수 없는 경우에 적합합니다.
두 방법 모두 동일한 기능을 제공합니다. 동일한 AWS 계정 내에서 하나 또는 두 가지 방법을 모두 사용할 수 있습니다.
## 알려진 제한 사항
+ **관리자 동의: Azure 테넌트당 AWS 계정 1**개 - 각 Azure 테넌트는 한 번에 하나의 AWS 계정과 연결된 AWS DevOps 에이전트 Entra 앱만 가질 수 있습니다. 동일한 테넌트를 다른 AWS 계정과 연결하려면 먼저 기존 등록을 등록 취소해야 합니다.
+ **앱 등록: 등록당 고유한 애플리케이션** - 각 앱 등록은 다른 애플리케이션(클라이언트 ID)을 사용해야 합니다. 동일한 클라이언트 ID로 여러 구성을 등록할 수 없습니다.
+ **Azure DevOps: 소스 코드 액세스** - Azure DevOps 통합은 소스 코드가 호스팅되는 위치에 관계없이 파이프라인 실행 기록에 대한 액세스를 제공합니다. 그러나 실제 소스 코드에 액세스하려면 지원되는 소스 공급자(예: )를 통해 리포지토리를 별도로 연결해야 합니다[GitHub 연결](connecting-to-cicd-pipelines-connecting-github.md). Bitbucket에서 호스팅되는 소스 코드는 Azure DevOps 통합을 통해 직접 액세스할 수 없습니다.
## 주제
+ [Azure 리소스 연결](connecting-azure-connecting-azure-resources.md)
+ [Azure DevOps 연결](connecting-azure-connecting-azure-devops.md)
# Azure 리소스 연결
Azure 리소스 통합을 통해 AWS DevOps Agent는 인시던트 조사 중에 Azure 구독의 리소스를 검색하고 조사할 수 있습니다. 에이전트는 리소스 검색에 Azure 리소스 그래프를 사용하며 Azure 환경 전반의 지표, 로그 및 구성 데이터에 액세스할 수 있습니다.
이 통합은 AWS 계정 수준에서 Azure를 등록한 다음 특정 Azure 구독을 개별 에이전트 스페이스와 연결하는 2단계 프로세스를 따릅니다.
## 사전 조건
Azure 리소스를 연결하기 전에 다음이 있는지 확인합니다.
+ AWS DevOps 에이전트 콘솔에 대한 액세스
+ 대상 구독에 액세스할 수 있는 Azure 계정
+ 관리자 동의 방법의 경우: Microsoft Entra ID에서 관리자 동의를 수행할 권한이 있는 계정
+ 앱 등록 방법의 경우: 페더레이션 자격 증명을 구성할 수 있는 권한이 있는 Entra 애플리케이션 및 AWS 계정에서 활성화된 [아웃바운드 자격 증명 페더레이션](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_enable-federation.html)
**참고:** 에이전트 스페이스 내에서 등록을 시작할 수도 있습니다. **보조 소스**로 이동하여 **추가**를 클릭하고 **Azure**를 선택합니다. Azure Cloud가 아직 등록되지 않은 경우 콘솔이 먼저 등록을 안내합니다.
## 관리자 동의를 통한 Azure 리소스 등록
관리자 동의 메서드는 AWS DevOps 에이전트 관리형 애플리케이션과 함께 동의 기반 흐름을 사용합니다.
### 1단계: 등록 시작
1. AWS Management Console에 로그인하고 AWS DevOps 에이전트 콘솔로 이동합니다.
1. **기능 공급자** 페이지로 이동
1. **Azure 클라우드** 섹션을 찾아 **등록**을 클릭합니다.
1. **관리자 동의** 등록 방법 선택
### 2단계: 관리자 동의 완료
1. 요청 중인 권한 검토
1. 계속하려면 클릭 - Microsoft Entra 관리자 동의 페이지로 리디렉션됩니다.
1. 관리자 동의를 수행할 권한이 있는 사용자 보안 주체 계정으로 로그인
1. AWS DevOps 에이전트 애플리케이션 검토 및 동의 부여
### 3단계: 사용자 권한 부여 완료
1. 관리자 동의 후 권한 있는 테넌트의 멤버 자격 증명을 확인하기 위한 사용자 권한 부여 메시지가 표시됩니다.
1. 동일한 Azure 테넌트에 속한 계정으로 로그인
1. 권한 부여 후 성공 상태의 AWS DevOps 에이전트 콘솔로 다시 리디렉션됩니다.
### 4단계: 역할 할당
아래 [Azure 역할 할당](#assigning-azure-roles)을 참조하세요. 멤버를 선택할 때 **AWS DevOps 에이전트**를 검색합니다.
## 앱 등록을 통해 Azure 리소스 등록
앱 등록 메서드는 페더레이션 자격 증명이 있는 자체 Entra 애플리케이션을 사용합니다.
### 1단계: 등록 시작
1. AWS DevOps 에이전트 콘솔에서 **기능 공급자** 페이지로 이동합니다.
1. **Azure 클라우드** 섹션을 찾아 **등록**을 클릭합니다.
1. **앱 등록** 방법 선택
### 2단계: Entra 애플리케이션 생성 및 구성
콘솔에 표시된 지침에 따라 다음을 수행합니다.
1. AWS 계정에서 아웃바운드 자격 증명 연동 활성화(IAM 콘솔에서 **계정 설정** → **아웃바운드 자격 증명 연동**으로 이동)
1. Microsoft Entra ID에서 Entra 애플리케이션을 생성하거나 기존 애플리케이션을 사용합니다.
1. 애플리케이션에서 페더레이션 자격 증명 구성
### 3단계: 등록 세부 정보 제공
등록 양식에 다음을 입력합니다.
+ **테넌트 ID** - Azure 테넌트 식별자
+ **테넌트 이름** - 테넌트의 표시 이름입니다.
+ **클라이언트 ID** - 생성한 Entra 애플리케이션의 애플리케이션(클라이언트) ID입니다.
+ **대상** - 페더레이션 자격 증명의 대상 식별자입니다.
### 4단계: IAM 역할 생성
콘솔을 통해 등록을 제출하면 IAM 역할이 자동으로 생성됩니다. 이를 통해 AWS DevOps 에이전트는 자격 증명을 수임하고를 호출할 수 있습니다`sts:GetWebIdentityToken`.
### 5단계: 역할 할당
아래 [Azure 역할 할당](#assigning-azure-roles)을 참조하세요. 멤버를 선택할 때 생성한 Entra 애플리케이션을 검색합니다.
### 6단계: 등록 완료
1. AWS DevOps 에이전트 콘솔에서 구성 확인
1. **제출**을 클릭하여 등록을 완료합니다.
## Azure 역할 할당
등록 후 애플리케이션에 Azure 구독에 대한 읽기 액세스 권한을 부여합니다. 이 단계는 관리자 동의 및 앱 등록 방법 모두에서 동일합니다.
1. Azure 포털에서 대상 구독으로 이동합니다.
1. **액세스 제어(IAM)**로 이동
1. **추가** > **역할 할당 추가**를 클릭합니다.
1. **독자** 역할을 선택하고 **다음을** 클릭합니다.
1. **멤버 선택을** 클릭하고 애플리케이션(관리자 동의용 **AWS DevOps 에이전트** 또는 앱 등록용 자체 Entra 애플리케이션)을 검색합니다.
1. 애플리케이션을 선택하고 **검토 \$1 할당**을 클릭합니다.
1. (선택 사항) 에이전트가 Azure Kubernetes Service(AKS) 클러스터에 액세스할 수 있도록 하려면 다음 AKS 액세스 설정을 완료합니다.
**보안 요구 사항:** 서비스 보안 주체에는 **리더** 역할(및 선택적으로 아래 나열된 AKS 읽기 전용 역할)만 할당해야 합니다. 리더 역할은 에이전트를 읽기 전용 작업으로 제한하고 간접 프롬프트 주입 공격의 영향을 제한하는 보안 경계 역할을 합니다. 쓰기 또는 작업 권한이 있는 역할을 할당하면 프롬프트 주입의 폭발 반경이 크게 증가하여 Azure 리소스가 손상될 수 있습니다. AWS DevOps Agent는 읽기 작업만 수행합니다. 에이전트는 Azure 리소스를 수정, 생성 또는 삭제하지 않습니다.
### AKS 액세스 설정(선택 사항)
#### 1단계: Azure Resource Manager(ARM) 수준 액세스
**Azure Kubernetes 서비스 클러스터 사용자 역할을** 애플리케이션에 할당합니다.
Azure 포털에서 **구독** → 구독 선택 → **액세스 제어(IAM)** → **역할 할당 추가** → **Azure Kubernetes 서비스 클러스터 사용자 역할** 선택 → 애플리케이션에 할당(관리자 동의용 **AWS DevOps 에이전트** 또는 앱 등록용 자체 Entra 애플리케이션)으로 이동합니다.
여기에는 구독의 모든 AKS 클러스터가 포함됩니다. 특정 클러스터로 범위를 지정하려면 대신 리소스 그룹 또는 개별 클러스터 수준에서를 할당합니다.
#### 2단계: Kubernetes API 액세스
클러스터의 인증 구성을 기반으로 한 가지 옵션을 선택합니다.
**옵션 A: Kubernetes용 Azure 역할 기반 액세스 제어(RBAC)(권장)**
1. 아직 활성화되지 않은 경우 클러스터에서 Azure RBAC 활성화: Azure 포털 → AKS 클러스터 → **설정** → **보안 구성** → **인증 및 권한** 부여 → **Azure RBAC** 선택
1. 읽기 전용 역할 할당: Azure 포털 → **구독** → 구독 선택 → **액세스 제어(IAM)** → **역할 할당 추가** → **Azure Kubernetes Service RBAC Reader** 선택 → 애플리케이션에 할당
여기에는 구독의 모든 AKS 클러스터가 포함됩니다.
**옵션 B: Azure Active Directory(Azure AD) \$1 Kubernetes RBAC**
클러스터가 이미 기본 Azure AD 인증 구성을 사용하고 Azure RBAC를 활성화하지 않으려는 경우이 옵션을 사용합니다. 이를 위해서는 클러스터당 `kubectl` 설정이 필요합니다.
1. 다음 매니페스트를 로 저장합니다`devops-agent-reader.yaml`.
```
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: devops-agent-reader
rules:
- apiGroups: [""]
resources: ["namespaces", "pods", "pods/log", "services", "events", "nodes"]
verbs: ["get", "list"]
- apiGroups: ["apps"]
resources: ["deployments", "replicasets", "statefulsets", "daemonsets"]
verbs: ["get", "list"]
- apiGroups: ["metrics.k8s.io"]
resources: ["pods", "nodes"]
verbs: ["get", "list"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: devops-agent-reader-binding
subjects:
- kind: User
name: ""
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: ClusterRole
name: devops-agent-reader
apiGroup: rbac.authorization.k8s.io
```
1. 를 서비스 보안 주체의 객체 ID``로 바꿉니다. 이를 찾으려면 Azure 포털 → Entra ID → 엔터프라이즈 애플리케이션 → 애플리케이션 이름(관리자 동의용 **AWS DevOps 에이전트** 또는 앱 등록용 자체 Entra 애플리케이션)을 검색합니다.
1. 각 클러스터에 적용:
```
az aks get-credentials --resource-group --name
kubectl apply -f devops-agent-reader.yaml
```
**참고:** 로컬 계정만 사용하는 클러스터(Azure AD 제외)는 지원되지 않습니다. 이 기능을 사용하려면 클러스터에서 Azure AD 통합을 활성화하는 것이 좋습니다.
### 최소 권한 사용자 지정 역할(선택 사항)
더 엄격한 액세스 제어를 위해 광범위한 리더 역할 대신 AWS DevOps 에이전트가 사용하는 리소스 공급자로만 범위가 지정된 사용자 지정 Azure 역할을 생성할 수 있습니다.
```
{
"Name": "AWS DevOps Agent - Azure Reader",
"Description": "Least-privilege read-only access for AWS DevOps Agent incident investigations.",
"Actions": [
"Microsoft.AlertsManagement/*/read",
"Microsoft.Compute/*/read",
"Microsoft.ContainerRegistry/*/read",
"Microsoft.ContainerService/*/read",
"Microsoft.ContainerService/managedClusters/commandResults/read",
"Microsoft.DocumentDB/*/read",
"Microsoft.Insights/*/read",
"Microsoft.KeyVault/vaults/read",
"Microsoft.ManagedIdentity/*/read",
"Microsoft.Monitor/*/read",
"Microsoft.Network/*/read",
"Microsoft.OperationalInsights/*/read",
"Microsoft.ResourceGraph/resources/read",
"Microsoft.ResourceHealth/*/read",
"Microsoft.Resources/*/read",
"Microsoft.Sql/*/read",
"Microsoft.Storage/*/read",
"Microsoft.Web/*/read"
],
"NotActions": [],
"DataActions": [],
"NotDataActions": [],
"AssignableScopes": [
"/subscriptions/{your-subscription-id}"
]
}
```
## 에이전트 스페이스와 구독 연결
계정 수준에서 Azure를 등록한 후 특정 구독을 에이전트 스페이스와 연결합니다.
1. AWS DevOps 에이전트 콘솔에서 에이전트 스페이스를 선택합니다.
1. **기능** 탭으로 이동
1. **보조 소스** 섹션에서 **추가**를 클릭합니다.
1. **Azure** 선택
1. 연결할 Azure **구독의 구독 ID**를 제공합니다.
1. **추가**를 클릭하여 연결을 완료합니다.
여러 구독을 동일한 에이전트 스페이스와 연결하여 Azure 환경 전체에서 에이전트에게 가시성을 제공할 수 있습니다.
## Azure 리소스 연결 관리
+ **연결된 구독 보기 **- **기능** 탭의 **보조 소스** 섹션에는 연결된 모든 Azure 구독이 나열됩니다.
+ **구독 제거** - 에이전트 스페이스에서 구독을 연결 해제하려면 **보조 소스** 목록에서 구독을 선택하고 **제거**를 클릭합니다. 이는 계정 수준 등록에는 영향을 주지 않습니다.
+ **등록 제거** - Azure 클라우드 등록을 완전히 제거하려면 **기능 공급자** 페이지로 이동하여 등록을 삭제합니다. 먼저 모든 에이전트 스페이스 연결을 제거해야 합니다.
# Azure DevOps 연결
Azure DevOps 통합을 통해 AWS DevOps 에이전트는 Azure DevOps 조직의 리포지토리 및 파이프라인 실행 기록에 액세스할 수 있습니다. 에이전트는 코드 변경 및 배포를 운영 인시던트와 연관시켜 잠재적 근본 원인을 식별할 수 있습니다.
**참고:** Azure DevOps 파이프라인은 Azure Repos, GitHub 또는 Bitbucket의 소스 코드를 사용할 수 있습니다. Azure DevOps 통합은 소스 공급자에 관계없이 파이프라인 실행 기록에 대한 액세스를 제공합니다. 그러나 조사 중에 실제 소스 코드에 액세스하려면와 같이 지원되는 통합을 통해 리포지토리를 별도로 연결해야 합니다[GitHub 연결](connecting-to-cicd-pipelines-connecting-github.md). Bitbucket의 소스 코드는이 통합을 통해 직접 액세스할 수 없습니다.
이 통합은 AWS 계정 수준에서 Azure DevOps를 등록한 다음 특정 프로젝트를 개별 에이전트 스페이스와 연결하는 2단계 프로세스를 따릅니다.
## 사전 조건
Azure DevOps를 연결하기 전에 다음이 있는지 확인합니다.
+ AWS DevOps 에이전트 콘솔에 대한 액세스
+ 리포지토리 및 파이프라인 기록이 포함된 프로젝트가 하나 이상 있는 Azure DevOps 조직
+ Azure DevOps 조직에 사용자를 추가할 수 있는 권한
+ 관리자 동의 방법의 경우: Microsoft Entra ID에서 관리자 동의를 수행할 권한이 있는 계정
+ 앱 등록 방법의 경우: 페더레이션 ID 자격 증명을 구성할 수 있는 권한이 있는 Entra 애플리케이션 및 AWS 계정에서 활성화된 [아웃바운드 자격 증명 페더레이션](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_enable-federation.html)
**참고:** 에이전트 스페이스 내에서 등록을 시작할 수도 있습니다. **파이프라인** 섹션으로 이동하여 **추가**를 클릭하고 **Azure DevOps**를 선택합니다. Azure DevOps가 아직 등록되지 않은 경우 콘솔이 먼저 등록을 안내합니다.
## 관리자 동의를 통한 Azure DevOps 등록
관리자 동의 메서드는 AWS DevOps 에이전트 관리형 애플리케이션과 함께 동의 기반 흐름을 사용합니다.
### 1단계: 등록 시작
1. AWS Management Console에 로그인하고 AWS DevOps 에이전트 콘솔로 이동합니다.
1. **기능 공급자** 페이지로 이동
1. **Azure DevOps** 섹션을 찾아 **등록**을 클릭합니다.
1. 메시지가 표시되면 **Azure DevOps 조직 이름을** 입력합니다.
### 2단계: 관리자 동의 완료
1. 계속하려면 클릭 - Microsoft Entra 관리자 동의 페이지로 리디렉션됩니다.
1. 관리자 동의를 수행할 권한이 있는 사용자 보안 주체 계정으로 로그인
1. AWS DevOps 에이전트 애플리케이션 검토 및 동의 부여
### 3단계: 사용자 권한 부여 완료
1. 관리자 동의 후 권한 있는 테넌트의 멤버 자격 증명을 확인하기 위한 사용자 권한 부여 메시지가 표시됩니다.
1. 동일한 Azure 테넌트에 속한 계정으로 로그인
1. 권한 부여 후 성공 상태의 AWS DevOps 에이전트 콘솔로 다시 리디렉션됩니다.
### 4단계: Azure DevOps에서 액세스 권한 부여
아래 [Azure DevOps에서 액세스 권한 부여](#granting-access-in-azure-devops)를 참조하세요. 사용자를 추가할 때 **AWS DevOps 에이전트**를 검색합니다.
## 앱 등록을 통해 Azure DevOps 등록
앱 등록은 Azure 리소스와 Azure DevOps 간에 공유됩니다. Azure 리소스에 대한 앱 등록을 이미 완료한 경우 [Azure DevOps에서 액세스 권한 부여](#granting-access-in-azure-devops)로 건너뛸 수 있습니다.
### 1단계: ADO 앱 등록 시작
1. AWS DevOps 에이전트 콘솔에서 **기능 공급자** 페이지로 이동합니다.
1. **Azure 클라우드** 섹션을 찾아 **등록**을 클릭합니다.
1. **앱 등록** 방법 선택
### 2단계: Entra 애플리케이션 생성 및 구성
콘솔에 표시된 지침에 따라 다음을 수행합니다.
1. AWS 계정에서 아웃바운드 자격 증명 연동 활성화(IAM 콘솔에서 **계정 설정** → **아웃바운드 자격 증명 연동**으로 이동)
1. Microsoft Entra ID에서 Entra 애플리케이션을 생성하거나 기존 애플리케이션을 사용합니다.
1. 애플리케이션에서 페더레이션 ID 자격 증명 구성
### 3단계: 등록 세부 정보 제공
등록 양식에 다음을 입력합니다.
+ **테넌트 ID** - Azure 테넌트 식별자
+ **테넌트 이름** - 테넌트의 표시 이름입니다.
+ **클라이언트 ID** - Entra 애플리케이션의 애플리케이션(클라이언트) ID입니다.
+ **대상 **- 페더레이션 자격 증명의 대상 식별자입니다.
### 4단계: IAM 역할 생성
콘솔을 통해 등록을 제출하면 IAM 역할이 자동으로 생성됩니다. 이를 통해 AWS DevOps 에이전트는 자격 증명을 수임하고를 호출할 수 있습니다`sts:GetWebIdentityToken`.
### 5단계: 등록 완료
1. AWS DevOps 에이전트 콘솔에서 구성 확인
1. **제출**을 클릭하여 등록을 완료합니다.
### 6단계: Azure DevOps에서 액세스 권한 부여
아래 [Azure DevOps에서 액세스 권한 부여](#granting-access-in-azure-devops)를 참조하세요. 사용자를 추가할 때 앱 등록 중에 생성한 Entra 애플리케이션을 검색합니다.
## Azure DevOps에서 액세스 권한 부여
등록 후 Azure DevOps 조직에 애플리케이션 액세스 권한을 부여합니다. 이 단계는 관리자 동의 및 앱 등록 방법 모두에서 동일합니다.
1. Azure DevOps에서 **조직 설정** > **사용자** > **사용자 추가**로 이동합니다.
1. 애플리케이션 검색(관리자 동의용 **AWS DevOps 에이전트** 또는 앱 등록용 자체 Entra 애플리케이션)
1. 액세스 수준을 **기본**으로 설정
1. **프로젝트에 추가**에서 에이전트가 액세스할 프로젝트를 선택합니다.
1. **Azure DevOps 그룹에서** **프로젝트 리더를** 선택합니다.
1. **추가**를 클릭하여 완료
**보안 요구 사항:** **Project Readers 그룹만 할당합니다**. 읽기 전용 액세스는 에이전트를 읽기 전용 작업으로 제한하고 간접 프롬프트 주입 공격의 영향을 제한하는 보안 경계 역할을 합니다. 쓰기 또는 작업 권한이 있는 그룹을 할당하면 프롬프트 주입의 폭발 반경이 크게 증가하여 Azure DevOps 리소스가 손상될 수 있습니다.
## 프로젝트를 에이전트 스페이스와 연결
계정 수준에서 Azure DevOps를 등록한 후 특정 프로젝트를 에이전트 스페이스와 연결합니다.
1. AWS DevOps 에이전트 콘솔에서 에이전트 스페이스를 선택합니다.
1. **기능** 탭으로 이동
1. **파이프라인** 섹션에서 **추가**를 클릭합니다.
1. 사용 가능한 공급자 목록에서 **Azure DevOps**를 선택합니다.
1. 사용 가능한 프로젝트 드롭다운에서 프로젝트를 선택합니다.
1. **추가**를 클릭하여 연결을 완료합니다.
## Azure DevOps 연결 관리
+ **연결된 프로젝트 보기** - **기능** 탭의 **파이프라인** 섹션에는 연결된 모든 Azure DevOps 프로젝트가 나열됩니다.
+ **프로젝트 제거** - 에이전트 공간에서 프로젝트를 연결 해제하려면 **파이프라인** 섹션에서 프로젝트를 선택하고 **제거**를 클릭합니다.
+ **등록 제거** - Azure DevOps 등록을 완전히 제거하려면 **기능 공급자** 페이지로 이동하여 등록을 삭제합니다. 먼저 모든 에이전트 스페이스 연결을 제거해야 합니다.
# CI/CD 파이프라인에 연결
CI/CD 파이프라인 통합을 통해 AWS DevOps Agent는 배포를 모니터링하고 조사 중에 코드 변경 사항을 운영 인시던트와 연관시킬 수 있습니다. 에이전트는 CI/CD 공급자를 연결하여 배포 이벤트를 추적하고 AWS 리소스와 연결하여 인시던트 대응 중에 잠재적 근본 원인을 식별할 수 있습니다.
AWS DevOps Agent는 2단계 프로세스를 통해 인기 있는 CI/CD 플랫폼과의 통합을 지원합니다.
1. **계정 수준 등록 -** AWS 계정 수준에서 CI/CD 공급자를 한 번 등록합니다.
1. **에이전트 스페이스 연결** - 조직의 요구 사항에 따라 특정 프로젝트 또는 리포지토리를 개별 에이전트 스페이스에 연결
이 접근 방식을 사용하면 여러 에이전트 스페이스에서 CI/CD 공급자 등록을 공유하는 동시에 각 스페이스에서 모니터링하는 프로젝트를 세부적으로 제어할 수 있습니다.
## 지원되는 CI/CD 공급자
AWS DevOps Agent는 다음 CI/CD 플랫폼을 지원합니다.
+ **GitHub** - AWS DevOps 에이전트 GitHub 앱을 사용하여 [GitHub.com](http://GitHub.com)에서 리포지토리를 연결합니다. GitHub
+ **GitLab** - [GitLab.com,](http://gitlab.com) 관리형 GitLab 인스턴스 또는 공개적으로 액세스할 수 있는 자체 호스팅 GitLab 배포에서 프로젝트를 연결합니다.
**주제**
+ [GitHub 연결](connecting-to-cicd-pipelines-connecting-github.md)
+ [GitLab 연결](connecting-to-cicd-pipelines-connecting-gitlab.md)
# GitHub 연결
GitHub 통합을 통해 AWS DevOps Agent는 코드 리포지토리에 액세스하고 인시던트 조사 중에 배포 이벤트를 수신할 수 있습니다. 이 통합은 GitHub의 계정 수준 등록 후 특정 리포지토리를 개별 에이전트 스페이스에 연결하는 2단계 프로세스를 따릅니다.
AWS DevOps Agent는 GitHub.com(SaaS) 및 GitHub Enterprise Server(자체 호스팅) 인스턴스를 모두 지원합니다.
## 사전 조건
GitHub를 연결하기 전에 다음이 있는지 확인합니다.
+ AWS DevOps 에이전트 관리자 콘솔에 대한 액세스
+ 관리자 권한이 있는 GitHub 사용자 계정 또는 조직
+ 계정 또는 조직에 GitHub 앱을 설치하기 위한 권한 부여
GitHub Enterprise Server의 경우 다음 사항도 필요합니다.
+ HTTPS를 통해 액세스할 수 있는 GitHub Enterprise Server 인스턴스(버전 3.x 이상)
+ GitHub Enterprise Server 인스턴스의 HTTPS URL(예: `https://github.example.com`)
+ (선택 사항) GitHub Enterprise Server 인스턴스에 공개적으로 액세스할 수 없는 경우의 프라이빗 연결
## GitHub 등록(계정 수준)
GitHub는 AWS 계정 수준에서 등록되고 해당 계정의 모든 에이전트 스페이스 간에 공유됩니다. GitHub는 AWS 계정당 한 번만 등록하면 됩니다.
### 1단계: 파이프라인 공급자로 이동
1. AWS Management Console에 로그인
1. AWS DevOps 에이전트 콘솔로 이동
1. **기능** 탭으로 이동
1. **파이프라인** 섹션에서 **추가**를 클릭합니다.
1. 사용 가능한 공급자 목록에서 **GitHub**를 선택합니다.
GitHub가 아직 등록되지 않은 경우 먼저 등록하라는 메시지가 표시됩니다.
### 2단계: 연결 유형 선택
"GitHub 계정/조직 등록" 화면에서 사용자 또는 조직으로 연결할지 여부를 선택합니다.
+ **사용자** - 사용자 이름과 프로필이 있는 개인 GitHub 계정
+ **조직** - 여러 사람이 여러 프로젝트에서 한 번에 협업할 수 있는 공유 GitHub 계정
GitHub Enterprise Server 인스턴스에 연결하는 경우 ** GitHub Enterprise Server 사용** 확인란을 선택하고 인스턴스의 HTTPS URL(예: `https://github.example.com`)을 입력합니다.
GitHub Enterprise Server 인스턴스에 공개적으로 액세스할 수 없는 경우 선택적으로 프라이빗 연결을 구성하여 AWS DevOps 에이전트가 인스턴스에 안전하게 연결할 수 있도록 할 수 있습니다. 자세한 내용은 [프라이빗 호스팅 도구에 연결](configuring-capabilities-for-aws-devops-agent-connecting-to-privately-hosted-tools.md) 단원을 참조하십시오.
**참고**
** URL에 `/api/v3` 또는 후행 경로를 포함하지 마십시오. 기본 URL만 입력합니다.
### 3단계: GitHub 앱 설정
**제출**을 클릭하여 앱 설정 프로세스를 시작합니다. 다음 단계는 GitHub.com에 연결하는지 아니면 GitHub Enterprise Server에 연결하는지에 따라 다릅니다.
#### GitHub.com의 경우
1. AWS DevOps 에이전트 GitHub 앱을 설치하기 위해 GitHub로 리디렉션됩니다.
1. 앱을 설치할 계정 또는 조직을 선택합니다.
1. 앱은 AWS DevOps 에이전트가 연결된 리포지토리에서 배포 이벤트를 포함한 이벤트를 수신할 수 있도록 허용합니다.
#### GitHub Enterprise Server의 경우
GitHub Enterprise Server는 인스턴스에 새 GitHub 앱을 자동으로 설정하는 GitHub 앱 매니페스트 흐름을 사용합니다. 여기에는 GitHub Enterprise Server 인스턴스에 대한 두 개의 리디렉션이 포함됩니다.
1. 브라우저가 GitHub Enterprise Server 인스턴스의 "GitHub 앱 생성" 페이지로 리디렉션됩니다.
1. 앱 이름이 미리 채워져 표시됩니다. 필요에 따라 이름을 자유롭게 변경할 수 있습니다. **GitHub 앱 생성을** 클릭합니다.
1. 매니페스트 코드를 앱 자격 증명으로 교환하는 AWS DevOps 에이전트로 다시 리디렉션됩니다.
### 4단계: 리포지토리 선택 및 설치 완료
1. GitHub 앱의 **설치 및 권한 부여** 페이지가 표시됩니다.
1. 앱이 액세스할 수 있도록 허용할 리포지토리를 선택합니다.
+ **모든 리포지토리** - 모든 현재 및 향후 리포지토리에 대한 액세스 권한 부여
+ **리포지토리만 선택** - 계정 또는 조직에서 특정 리포지토리를 선택합니다.
1. **설치 및 권한 부여를** 클릭합니다.
1. AWS DevOps 에이전트 콘솔로 다시 리디렉션됩니다. 여기서 GitHub는 계정 수준에서 등록된 것으로 표시됩니다.
## 에이전트 스페이스에 리포지토리 연결
계정 수준에서 GitHub를 등록한 후 특정 리포지토리를 개별 에이전트 스페이스에 연결할 수 있습니다.
1. AWS DevOps 에이전트 콘솔에서 에이전트 스페이스를 선택합니다.
1. **기능** 탭으로 이동
1. **파이프라인** 섹션에서 **추가**를 클릭합니다.
1. 사용 가능한 공급자 목록에서 **GitHub**를 선택합니다.
1. 이 에이전트 스페이스와 관련된 리포지토리의 하위 집합 선택
1. **추가**를 클릭하여 연결을 완료합니다.
조직의 필요에 따라 서로 다른 리포지토리 세트를 서로 다른 에이전트 스페이스에 연결할 수 있습니다.
## GitHub 앱 이해
AWS DevOps 에이전트 GitHub 앱:
+ 리포지토리에 대한 읽기 전용 액세스 요청
+ 배포 이벤트 및 기타 리포지토리 이벤트를 수신합니다.
+ 코드 변경 사항을 운영 인시던트와 연관시킬 수 있는 Allow AWS DevOps Agent
+ GitHub 설정을 통해 언제든지 제거할 수 있습니다.
GitHub Enterprise Server의 경우 GitHub 앱은 등록 중에 인스턴스에 자동으로 생성됩니다. **설정 > 애플리케이션 > 설치된 GitHub 앱을 통해 앱의 리포지토리 액세스를 관리하거나 제거할 수 있습니다**. 앱 정의를 완전히 삭제하려면 **설정 > 개발자 설정 > GitHub 앱으로** 이동합니다.
## GitHub 연결 관리
+ **리포지토리 액세스 업데이트** - GitHub 앱이 액세스할 수 있는 리포지토리를 변경하려면 GitHub 계정 또는 조직 설정(또는 GitHub Enterprise Server 인스턴스 설정)으로 이동하여 설치된 GitHub 앱으로 이동하여 AWS DevOps Agent 앱 구성을 수정합니다.
+ **연결된 리포지토리 보기** - AWS DevOps 에이전트 콘솔에서 에이전트 스페이스를 선택하고 기능 탭으로 이동하여 파이프라인 섹션에서 연결된 리포지토리를 봅니다.
+ **GitHub 연결 제거** - 에이전트 공간에서 GitHub를 연결 해제하려면 파이프라인 섹션에서 연결을 선택하고 **제거**를 클릭합니다. GitHub 앱을 완전히 제거하려면 GitHub 계정 또는 조직 설정에서 제거합니다. GitHub Enterprise Server의 경우 GitHub 앱은 등록 중에 인스턴스에서 직접 생성되므로 선택적으로 다음 두 가지를 모두 수행하여 앱을 완전히 정리할 수 있습니다.
+ **앱 제거** - **설정 > 애플리케이션 > 설치된 GitHub 앱**으로 이동하여 앱에서 **구성을** 클릭한 다음 제거합니다.
+ **앱 삭제** - **설정 > 개발자 설정 > GitHub 앱**으로 이동하여 앱을 선택하고 **고급** 탭으로 이동한 다음 ** GitHub 앱 삭제**를 선택합니다. **경고:** GitHub 앱 삭제는 영구적이며 실행 취소할 수 없습니다. 삭제하는 경우 AWS DevOps 에이전트 콘솔의 처음부터 GitHub Enterprise Server를 다시 등록하여 새 앱을 생성해야 합니다.
# GitLab 연결
GitLab 통합을 통해 AWS DevOps Agent는 GitLab Pipelines의 배포를 모니터링하여 인시던트 대응 중에 인과 조사를 알릴 수 있습니다. 이 통합은 GitLab의 계정 수준 등록 후 특정 프로젝트를 개별 에이전트 스페이스에 연결하는 2단계 프로세스를 따릅니다.
## GitLab 등록(계정 수준)
GitLab은 AWS 계정 수준에서 등록되고 해당 계정의 모든 에이전트 스페이스 간에 공유됩니다. 그러면 개별 에이전트 스페이스는 에이전트 스페이스에 적용할 특정 프로젝트를 선택할 수 있습니다.
### 1단계: 파이프라인 공급자로 이동
1. AWS Management Console에 로그인
1. AWS DevOps 에이전트 콘솔로 이동
1. **기능 공급자** 페이지로 이동(측면 탐색에서 액세스 가능)
1. **파이프라인** 아래의 **사용 가능한** 공급자 섹션에서 **GitLab**을 찾고 **등록**을 클릭합니다.
### 2단계: GitLab 연결 구성
GitLab 등록 페이지에서 다음을 구성합니다.
**연결 유형** - 개인 또는 그룹으로 연결할지 여부를 선택합니다.
+ **개인**(기본값) - 사용자 이름과 프로필이 있는 개별 GitLab 사용자 계정
+ **그룹** - GitLab에서는 그룹을 사용하여 하나 이상의 관련 프로젝트를 동시에 관리합니다.
**GitLab 인스턴스 유형** - 연결할 GitLab 인스턴스 유형을 선택합니다.
+ **GitLab.com**(기본값) - 퍼블릭 GitLab 서비스
+ **공개적으로 액세스할 수 있는 자체 호스팅 GitLab -** ** GitLab 자체 호스팅 엔드포인트 사용** 확인란을 선택하고 GitLab 인스턴스에 URL을 제공합니다.
**참고**
** 현재 공개적으로 액세스할 수 있는 GitLab 인스턴스만 지원됩니다.
**액세스 토큰** - GitLab 개인 액세스 토큰을 제공합니다.
1. 별도의 브라우저 탭에서 GitLab 계정에 로그인합니다.
1. 사용자 설정으로 이동하여 **액세스 토큰을** 선택합니다.
1. 다음 권한을 사용하여 새 개인 액세스 토큰을 생성합니다.
+ `read_repository` - 리포지토리 콘텐츠에 액세스하는 데 필요합니다.
+ `read_virtual_registry` - 가상 레지스트리 정보에 액세스하는 데 필요합니다.
+ `read_registry` - 레지스트리 정보에 액세스하는 데 필요합니다.
+ `api` - 읽기 및 쓰기 API 액세스에 필요합니다.
+ `self_rotate` - 토큰 교체에 필요합니다. 이 기능은 현재 AWS DevOps Agent에서 지원되지 않지만 나중에 지원됩니다. 이제를 추가하면 향후 새 토큰을 생성할 필요가 없습니다.
1. 토큰 만료를 현재 날짜로부터 최대 365일로 설정합니다.
1. 생성된 토큰 복사
1. AWS DevOps 에이전트 콘솔로 돌아가기
1. 토큰을 “토큰 액세스” 필드에 붙여넣습니다.
### 3단계: 등록 완료
**(선택 사항) 태그 **- 조직용으로 GitLab 등록에 AWS 태그를 추가합니다.
**다음을** 클릭하여 구성을 검토한 다음 **제출**을 클릭하여 GitLab 등록 프로세스를 완료합니다. 시스템에서 액세스 토큰을 검증하고 연결을 설정합니다.
## 에이전트 스페이스에 프로젝트 연결
계정 수준에서 GitLab을 등록한 후 특정 프로젝트를 개별 에이전트 스페이스에 연결할 수 있습니다.
1. AWS DevOps 에이전트 콘솔에서 에이전트 스페이스를 선택합니다.
1. **기능** 탭으로 이동
1. **파이프라인** 섹션에서 **추가**를 클릭합니다.
1. 사용 가능한 공급자 목록에서 **GitLab**을 선택합니다.
1. 에이전트 스페이스와 관련된 GitLab 프로젝트를 선택합니다.
1. **저장**을 클릭합니다.
AWS DevOps Agent는 이러한 프로젝트의 GitLab Pipelines 배포를 모니터링하여 인과 조사를 알립니다.
## GitLab 연결 관리
+ **액세스 토큰 업데이트 **- 액세스 토큰이 만료되거나 업데이트해야 하는 경우 계정 수준에서 GitLab 등록을 수정하여 AWS DevOps 에이전트 콘솔에서 업데이트할 수 있습니다.
+ **연결된 프로젝트 보기** - AWS DevOps 에이전트 콘솔에서 에이전트 스페이스를 선택하고 기능 탭으로 이동하여 파이프라인 섹션에서 연결된 프로젝트를 봅니다.
+ **GitLab 연결 제거** - 에이전트 공간에서 GitLab 프로젝트를 연결 해제하려면 파이프라인 섹션에서 연결을 선택하고 **제거**를 클릭합니다. GitLab 등록을 완전히 제거하려면 먼저 모든 에이전트 스페이스에서 제거한 다음 계정 수준에서 등록을 삭제합니다.
# MCP 서버 연결
모델 컨텍스트 프로토콜(MCP) 서버는 외부 관찰성 도구, 사용자 지정 모니터링 시스템 및 운영 데이터 소스의 데이터에 대한 액세스를 제공하여 AWS DevOps 에이전트의 조사 기능을 확장합니다. 이 가이드에서는 MCP 서버를 AWS DevOps Agent에 연결하는 방법을 설명합니다.
## 요구 사항
MCP 서버를 연결하기 전에 서버가 다음 요구 사항을 충족하는지 확인합니다.
+ **스트리밍 가능한 HTTP 전송 프로토콜** - 스트리밍 가능한 HTTP 전송 프로토콜을 구현하는 MCP 서버만 지원됩니다.
+ **인증 지원** - MCP 서버는 OAuth 2.0 인증 흐름 또는 API 키/토큰 기반 인증을 지원해야 합니다.
## 보안 고려 사항
MCP 서버를 AWS DevOps Agent에 연결할 때 다음 보안 측면을 고려하세요.
+ **도구 허용 목록 - ** MCP 서버의 모든 도구를 노출하는 대신 에이전트 스페이스에 필요한 특정 도구만 허용 목록으로 지정해야 합니다. [에이전트 공간당 목록 도구를 허용하는 방법은 에이전트 공간에서 MCP 도구 구성을](#configuring-capabilities-for-aws-devops-agent-connecting-mcp-servers) 참조하세요.
MCP 도구의 최대 도구 길이는 64입니다.
+ **프롬프트 주입 위험** - 사용자 지정 MCP 서버는 프롬프트 주입 공격의 추가 위험을 초래할 수 있습니다. 자세한 내용은 [프롬프트 주입 방지: AWS DevOps 에이전트 보안을](aws-devops-agent-security.md) 참조하세요.
+ **읽기 전용 도구 및 액세스 **- 읽기 전용 MCP 도구만 허용하고 인증 자격 증명이 읽기 전용 액세스만 허용되도록 합니다.
프롬프트 주입 및 공동 책임 모델에 대한 [AWS DevOps 에이전트 보안](aws-devops-agent-security.md) 자세한 내용은 섹션을 참조하세요.
**참고**
MCP 서버가 프라이빗 네트워크에 있는 경우 섹션을 참조하세요. [프라이빗 호스팅 도구에 연결](configuring-capabilities-for-aws-devops-agent-connecting-to-privately-hosted-tools.md)
## MCP 서버 등록(계정 수준)
MCP 서버는 AWS 계정 수준에서 등록되고 해당 계정의 모든 에이전트 스페이스 간에 공유됩니다. 그러면 개별 에이전트 스페이스가 각 MCP 서버에 필요한 특정 도구를 선택할 수 있습니다.
### 1단계: MCP 서버 세부 정보
1. AWS Management Console에 로그인
1. AWS DevOps 에이전트 콘솔로 이동
1. **기능 공급자** 페이지로 이동(측면 탐색에서 액세스 가능)
1. **사용 가능한** 공급자 섹션에서 **MCP 서버를** 찾아 **등록**을 클릭합니다.
1. **MCP 서버 세부** 정보 페이지에서 다음 정보를 입력합니다.
+ **이름** - MCP 서버의 설명 이름을 입력합니다.
+ **엔드포인트 URL** - MCP 서버 엔드포인트의 전체 HTTPS URL을 입력합니다.
+ **설명**(선택 사항) - 서버의 목적을 식별하는 데 도움이 되는 설명을 추가합니다.
+ **동적 클라이언트 등록 활성화** - MCP 서버의 권한 부여 서버에 AWS DevOps 에이전트가 자동으로 등록하도록 허용하려면이 확인란을 선택합니다.
1. **다음**을 클릭합니다.
**참고**
** MCP 서버 엔드포인트 URL은 계정의 AWS CloudTrail 로그에 표시됩니다.
### 2단계: 권한 부여 흐름
MCP 서버의 인증 방법을 선택합니다.
**OAuth 클라이언트 자격 증명** - MCP 서버가 OAuth 클라이언트 자격 증명 흐름을 사용하는 경우:
1. **OAuth 클라이언트 자격 증명** 선택
1. **다음**을 클릭합니다.
**OAuth 3LO(3레깅 OAuth) -** MCP 서버가 인증에 OAuth 3LO를 사용하는 경우:
1. **OAuth 3LO** 선택
1. **다음**을 클릭합니다.
**API 키** - MCP 서버가 API 키 인증을 사용하는 경우:
1. **API 키** 선택
1. **다음**을 클릭합니다.
### 3단계: 권한 부여 구성
선택한 인증 방법을 기반으로 추가 권한 부여 파라미터를 구성합니다.
**OAuth 클라이언트 자격 증명의 경우:**
1. **클라이언트 ID** - OAuth 클라이언트의 클라이언트 ID를 입력합니다.
1. **클라이언트 보안 암호** - OAuth 클라이언트의 클라이언트 보안 암호를 입력합니다.
1. **Exchange URL** - OAuth 토큰 교환 엔드포인트 URL을 입력합니다.
1. **Exchange 파라미터** - 서비스 인증을 위한 OAuth 토큰 교환 파라미터를 입력합니다.
1. **범위 추가 **- 인증을 위한 OAuth 범위 추가
1. **다음**을 클릭합니다.
**OAuth 3LO의 경우:**
1. **클라이언트 ID** - OAuth 클라이언트의 클라이언트 ID를 입력합니다.
1. **클라이언트 보안 암호** - OAuth 클라이언트에 필요한 경우 OAuth 클라이언트의 클라이언트 보안 암호를 입력합니다.
1. **Exchange URL** - OAuth 토큰 교환 엔드포인트 URL을 입력합니다.
1. **권한 부여 URL ** - OAuth 권한 부여 엔드포인트 URL을 입력합니다.
1. **코드 챌린지 지원 ** - OAuth 클라이언트가 코드 챌린지를 지원하는 경우이 확인란을 선택합니다.
1. **범위 추가 **- 인증을 위한 OAuth 범위 추가
1. **다음**을 클릭합니다.
**API 키의 경우:**
1. API 키 이름 입력
1. 요청에 API 키를 포함할 헤더의 이름을 입력합니다.
1. API 키 값 입력
1. **다음**을 클릭합니다.
### 4단계: 검토 및 제출
1. 모든 MCP 서버 구성 세부 정보 검토
1. **제출**을 클릭하여 등록을 완료합니다.
1. AWS DevOps 에이전트가 MCP 서버에 대한 연결을 검증합니다.
1. 검증에 성공하면 MCP 서버가 계정 수준에서 등록됩니다.
## 에이전트 스페이스에서 MCP 도구 구성
계정 수준에서 MCP 서버를 등록한 후 해당 서버에서 특정 에이전트 스페이스에 사용할 수 있는 도구를 구성할 수 있습니다.
1. AWS DevOps 에이전트 콘솔에서 에이전트 스페이스를 선택합니다.
1. **기능** 탭으로 이동
1. **MCP 서버** 섹션에서 **추가**를 클릭합니다.
1. 이 에이전트 스페이스에 연결할 등록된 MCP 서버를 선택합니다.
1. 이 MCP 서버의 도구를 에이전트 스페이스에서 사용할 수 있도록 구성합니다.
+ **모든 도구 허용** - MCP 서버의 모든 도구를 사용할 수 있도록 설정합니다.
+ **특정 도구 선택** - 허용 목록에 추가할 도구를 선택할 수 있습니다.
1. **추가**를 클릭하여 MCP 서버를 에이전트 스페이스에 연결합니다.
이제AWS DevOps 에이전트는이 에이전트 스페이스에서 조사하는 동안 MCP 서버의 허용 목록에 있는 도구를 사용할 수 있습니다.
## MCP 서버 연결 관리
**인증 자격 증명 업데이트 **- 인증 자격 증명을 업데이트해야 하는 경우 MCP 서버를 다시 등록해야 합니다. AWS DevOps 에이전트 콘솔의 **기능 공급자** 페이지로 이동하여 MCP 서버를 찾고 활성 연결을 제거한 다음 **등록 취소**를 클릭합니다. 그런 다음 새 인증 자격 증명으로 MCP 서버를 **등록**하고 에이전트 스페이스와 필요한 연결을 다시 생성합니다.
**연결된 MCP 서버 보기** - 에이전트 스페이스에 연결된 모든 MCP 서버를 보려면 에이전트 스페이스를 선택하고 **기능** 탭으로 이동하여 **MCP 서버** 섹션을 확인합니다. 여기에서 선택한 도구를 업데이트할 수도 있습니다.
**MCP 서버 연결 제거** - 에이전트 공간에서 MCP 서버를 연결 해제하려면 **MCP 서버 섹션에서 서버를** 선택하고 **제거**를 클릭합니다. MCP 서버 등록을 완전히 삭제하려면 먼저 모든 에이전트 스페이스에서 제거한 다음 계정 수준 등록을 삭제합니다.
## 관련 주제
+ in AWS DevOps 에이전트의 보안
+ 에이전트 스페이스 설정
+ 프롬프트 주입 보호
# 여러 AWS 계정 연결
보조 AWS 계정을 사용하면 AWS DevOps Agent가 조직의 여러 AWS 계정에서 리소스를 조사할 수 있습니다. 애플리케이션이 여러 계정에 걸쳐 있는 경우 보조 계정을 추가하면 인시던트 조사 중에 에이전트가 모든 관련 리소스를 볼 수 있습니다. 애플리케이션을 구성하는 계정 및 리소스에 대한 액세스 권한이 높을수록 조사 정확도가 높아집니다.
## 사전 조건
보조 AWS 계정을 추가하기 전에 다음이 있는지 확인합니다.
+ 기본 계정의 AWS DevOps 에이전트 콘솔에 대한 액세스
+ 보조 AWS 계정에 대한 관리 액세스
+ 보조 계정에서 역할을 생성할 수 있는 IAM 권한
## 보조 AWS 계정 추가
아래 단계 외에도를 사용하여 보조 계정을 [AWS DevOps Agent CLI 온보딩 가이드](getting-started-with-aws-devops-agent-cli-onboarding-guide.md) 프로그래밍 방식으로 추가할 수 있습니다.
### 1단계: 보조 계정 구성 시작
1. AWS Management Console에 로그인하고 AWS DevOps 에이전트 콘솔로 이동합니다.
1. 에이전트 스페이스 선택
1. **기능** 탭으로 이동
1. **클라우드** 섹션에서 **보조 소스** 하위 섹션을 찾습니다.
1. **추가**를 클릭합니다.
### 2단계: 역할 이름 지정
1. **역할 이름 지정** 필드에 보조 계정에서 생성할 역할의 이름을 입력합니다.
1. 이 이름 참고 - 보조 계정에서 역할을 생성할 때 다시 사용합니다.
1. 콘솔에 제공된 신뢰 정책을 복사하여 스크래치 공간에 저장합니다.
### 3단계: 보조 계정에서 역할 생성
1. 새 브라우저 탭을 열고 보조 AWS 계정의 IAM 콘솔에 로그인합니다.
1. **IAM >** **역할** > **역할 생성**으로 이동합니다.
1. **사용자 지정 신뢰 정책** 선택
1. 2단계에서 복사한 신뢰 정책 붙여넣기
1. **다음**을 클릭합니다.
### 4단계: AWS 관리형 정책 연결
1. **권한 정책** 섹션에서 **AIOpsAssistantPolicy**를 검색합니다.
1. **AIOpsAssistantPolicy** 관리형 정책 옆의 확인란을 선택합니다.
1. **다음**을 클릭합니다.
### 5단계: 역할 이름 지정 및 생성
1. **역할 이름** 필드에 2단계에서 제공한 것과 동일한 역할 이름을 입력합니다.
1. (선택 사항) 역할의 목적을 식별하는 데 도움이 되는 설명을 추가합니다.
1. 신뢰 정책 및 연결된 권한 검토
1. **역할 생성을** 클릭합니다.
### 6단계: 인라인 정책 연결
1. IAM 콘솔에서 방금 생성한 역할을 찾아 선택합니다.
1. **권한** 탭으로 이동
1. **권한 추가** > **인라인 정책 생성을** 클릭합니다.
1. **JSON** 탭으로 전환
1. 2단계에서 저장한 정책 붙여넣기
1. IAM 콘솔의 JSON 편집기에 정책 붙여넣기
1. **다음**을 클릭합니다.
1. 인라인 정책의 이름을 입력합니다(예: "DevOpsAgentInlinePolicy").
1. **정책 생성을** 클릭합니다.
### 7단계: 구성 완료
1. 기본 계정의 AWS DevOps 에이전트 콘솔로 돌아가기
1. **다음을** 클릭하여 보조 계정 구성을 완료합니다.
1. 연결 상태가 **활성**으로 표시되는지 확인
## 필수 정책 이해
AWS DevOps Agent는 보조 계정의 리소스에 액세스하려면 세 가지 정책 구성 요소가 필요합니다.
+ **신뢰 정책** - 기본 계정의 AWS DevOps 보조 계정의 역할을 수임하도록 허용합니다. 이렇게 하면 계정 간의 신뢰 관계가 설정됩니다.
+ **AIOpsAssistantPolicy(AWS 관리형 정책)** - 보조 계정의 리소스를 조사하는 데 필요한 핵심 읽기 전용 권한 AWS DevOps Agent를 제공합니다. 이 정책은에서 유지 AWS 관리하며 새 기능이 추가되면 업데이트됩니다.
+ **인라인 정책** - 에이전트 공간 구성과 관련된 추가 권한을 제공합니다. 이 정책은 에이전트 공간 설정을 기반으로 생성되며 특정 통합 또는 기능에 대한 권한을 포함할 수 있습니다.
기본 계정에서 AWS DevOps 에이전트 IAM 역할은 보조 계정에서 생성된 역할을 수임할 수 있어야 합니다.
## 보조 계정 관리
+ **연결된 계정 보기** - **기능** 탭의 **보조 소스** 하위 섹션에는 연결된 모든 보조 계정이 연결 상태로 나열됩니다.
+ **IAM 역할 업데이트 **- 권한을 수정해야 하는 경우 보조 계정의 역할에 연결된 인라인 정책을 업데이트합니다. 변경 사항은 즉시 적용됩니다.
+ **보조 계정 제거** - 보조 계정의 연결을 해제하려면 **보조 소스** 목록에서 해당 계정을 선택하고 **제거**를 클릭합니다. 이렇게 해도 보조 계정의 IAM 역할은 삭제되지 않습니다.
# 원격 측정 소스 연결
AWS DevOps Agent는 원격 측정 소스에 연결하는 세 가지 방법을 제공합니다.
## 기본 제공 양방향 통합
현재 AWS DevOps 에이전트는 다음을 지원하는 기본 제공 양방향 통합을 통해 Dynatrace 사용자를 지원합니다.
+ **토폴로지 리소스 매핑** - AWS DevOps 에이전트는 DevOps 에이전트가 호스팅하는 Dynatrace MCP 서버를 통해 사용할 수 있는 엔터티 및 관계로 AWS DevOps 에이전트 스페이스 토폴로지를 강화합니다.
+ **자동 조사 트리거 **- Dynatrace 문제에서 인시던트 해결 조사를 트리거하도록 Dynatrace 워크플로를 구성할 수 있습니다.
+ **원격 측정 내부 검사** - AWS DevOps 에이전트는 AWS DevOps 에이전트 호스팅 Dynatrace MCP 서버를 통해 문제를 조사할 때 Dynatrace 원격 측정을 내부 검사할 수 있습니다.
+ **상태 업데이트** - AWS DevOps Agent는 주요 조사 결과, 근본 원인 분석 및 생성된 완화 계획을 Dynatrace 사용자 인터페이스에 게시합니다.
양방향 통합에 대한 자세한 내용은 섹션을 참조하세요.
+ [Dynatrace 연결](connecting-telemetry-sources-connecting-dynatrace.md)
## 기본 제공 단방향 통합
현재 AWS DevOps 에이전트는 내장된 단방향 통합을 통해 AWS CloudWatch, Datadog, Grafana, New Relic 및 Splunk 사용자를 지원합니다.
**보안 모범 사례:** 기본 제공 단방향 통합을 위한 자격 증명을 구성할 때는 API 키와 토큰을 읽기 전용 액세스로 조정하는 것이 좋습니다. AWS DevOps Agent는 원격 측정 내부 검사에만 이러한 자격 증명을 사용하며 원격 측정 공급자에 대한 쓰기 액세스가 필요하지 않습니다.
AWS CloudWatch 기본 제공 단방향 통합은 추가 설정이 필요하지 않으며 다음을 활성화합니다.
+ **토폴로지 리소스 매핑** - AWS DevOps 에이전트는 구성된 기본 및 보조 AWS 클라우드 계정을 통해 사용할 수 있는 엔터티 및 관계로 DevOps 에이전트 스페이스 토폴로지를 강화합니다.
+ **원격 측정 내부 검사** - AWS DevOps Agent는 기본 및 보조 AWS 클라우드 계정 구성 중에 제공된 IAM 역할(들)을 통해 문제를 조사할 때 AWS CloudWatch 원격 측정을 내부 검사할 수 있습니다.
Datadog, Grafana, New Relic 및 Splunk 기본 제공 단방향 통합에는 다음을 설정하고 활성화해야 합니다.
+ **자동 조사 트리거 **- Datadog, Grafana, New Relic 및 Splunk 이벤트를 AWS DevOps 에이전트 웹후크를 통해 AWS DevOps 에이전트 인시던트 해결 조사를 트리거하도록 구성할 수 있습니다.
+ **원격 측정 내부 검사** - AWS DevOps Agent는 각 공급자의 원격 MCP 서버를 통해 문제를 조사할 때 Datadog, Grafana, New Relic 및 Splunk 원격 측정을 내부 검사할 수 있습니다.
단방향 통합에 대한 자세한 내용은 다음을 참조하세요.
+ [DataDog 연결](connecting-telemetry-sources-connecting-datadog.md)
+ [Grafana 연결](connecting-telemetry-sources-connecting-grafana.md)
+ [새 복제본 연결](connecting-telemetry-sources-connecting-new-relic.md)
+ [Splunk 연결](connecting-telemetry-sources-connecting-splunk.md)
## Bring-your-own
Prometheus 지표를 포함한 다른 원격 측정 소스의 경우 웹후크와 MCP 서버 통합 모두에 대한 AWS DevOps 에이전트의 지원을 활용할 수 있습니다.
bring-your-own 통합에 대한 자세한 내용은 다음을 참조하세요.
+ [Webhook를 통해 DevOps 에이전트 호출](configuring-capabilities-for-aws-devops-agent-invoking-devops-agent-through-webhook.md)
+ [MCP 서버 연결](configuring-capabilities-for-aws-devops-agent-connecting-mcp-servers.md)
# Dynatrace 연결
## 기본 제공 양방향 통합
현재 AWS DevOps 에이전트는 다음을 지원하는 기본 제공 양방향 통합을 통해 Dynatrace 사용자를 지원합니다.
+ **토폴로지 리소스 매핑** - AWS DevOps 에이전트는 Dynatrace 환경에서 사용할 수 있는 엔터티 및 관계로 DevOps 에이전트 스페이스 토폴로지를 강화합니다.
+ **자동 조사 트리거 **- Dynatrace 문제에서 인시던트 해결 조사를 트리거하도록 Dynatrace 워크플로를 구성할 수 있습니다.
+ **원격 측정 내부 검사** - AWS DevOps 에이전트는 AWS DevOps 에이전트 호스팅 Dynatrace MCP 서버를 통해 문제를 조사할 때 Dynatrace 원격 측정을 내부 검사할 수 있습니다.
+ **상태 업데이트** - AWS DevOps Agent는 주요 조사 결과, 근본 원인 분석 및 생성된 완화 계획을 Dynatrace 사용자 인터페이스에 게시합니다.
## 온보딩
### 온보딩 프로세스
Dynatrace 관찰성 시스템 온보딩에는 세 단계가 포함됩니다.
1. **연결** - 필요한 모든 환경에서 계정 액세스 자격 증명을 구성하여 Dynatrace에 대한 연결을 설정합니다.
1. **활성화** - 특정 Dynatrace 환경의 특정 에이전트 공간에서 Dynatrace 활성화
1. **Dynatrace 환경 구성** - 워크플로 및 대시보드를 다운로드하고 Dynatrace로 가져와 지정된 에이전트 공간에서 조사를 트리거하기 위한 웹후크 세부 정보를 기록해 둡니다.
### 1단계: 연결
Dynatrace 환경에 대한 연결 설정
#### 구성
1. **기능 공급자** 페이지로 이동(측면 탐색에서 액세스 가능)
1. **텔레메트**리 아래의 **사용 가능한** 공급자 섹션에서 **Dynatrace**를 찾고 **등록**을 클릭합니다.
1. **자세한 권한을 사용하여 Dynatrace에서 OAuth 클라이언트를 생성합니다.**
1. [Dynatrace 설명서](https://docs.dynatrace.com/docs/shortlink/aws-devops-agent) 참조
1. 준비가 되면 다음을 누릅니다.
1. 여러 Dynatrace 환경을 연결하고 나중에 보유한 각 DevOps 에이전트 스페이스의 특정 환경에 범위를 지정할 수 있습니다.
1. OAuth 클라이언트 설정에서 Dynatrace 세부 정보를 입력합니다.
+ **클라이언트 이름**
+ **클라이언트 ID**
+ **클라이언트 보안 암호**
+ **계정 URN**
1. 다음을 클릭합니다.
1. 검토 및 추가
### 2단계: 활성화
특정 에이전트 공간에서 Dynatrace를 활성화하고 적절한 범위 지정을 구성합니다.
#### 구성
1. 에이전트 공간 페이지에서 에이전트 공간을 선택하고 세부 정보 보기를 누릅니다.
1. 기능 탭을 선택합니다.
1. 텔레메트리 섹션을 찾아 추가를 누릅니다.
1. '등록됨' 상태의 Dynatrace가 표시됩니다. 추가를 클릭하여 에이전트 스페이스에 추가합니다.
1. Dynatrace 환경 ID -이 DevOps 에이전트 공간과 연결할 Dynatrace 환경 ID를 제공합니다.
1. 하나 이상의 Dynatrace 엔터티 IDs 입력합니다. 이를 통해 DevOps 에이전트가 가장 중요한 리소스를 검색할 수 있습니다. 예를 들면 서비스 또는 애플리케이션일 수 있습니다. **확실하지 않은 경우 제거를 누릅니다.**
1. 검토 후 저장을 누릅니다.
1. Webhook URL 및 Webhook 보안 암호를 복사합니다. 이러한 자격 증명을 [Dynatrace에 추가하려면 Dynatrace 설명서를](https://docs.dynatrace.com/docs/shortlink/aws-devops-agent) 참조하세요.
### 3단계: Dynatrace 환경 구성
Dynatrace 설정을 완료하려면 Dynatrace 환경에서 특정 설정 단계를 수행해야 합니다. [Dynatrace 설명서](https://docs.dynatrace.com/docs/shortlink/aws-devops-agent)의 지침을 따릅니다.
#### 지원되는 이벤트 스키마
AWS DevOps 에이전트는 웹후크를 사용하여 Dynatrace의 두 가지 유형의 이벤트를 지원합니다. 지원되는 이벤트 스키마는 아래에 설명되어 있습니다.
##### 인시던트 이벤트
인시던트 이벤트는 조사를 트리거하는 데 사용됩니다. 이벤트 스키마는 다음과 같습니다.
```
{
"event.id": string;
"event.status": "ACTIVE" | "CLOSED";
"event.status_transition": string;
"event.description": string;
"event.name": string;
"event.category": "AVAILABILITY" | "ERROR" | "SLOWDOWN" | "RESOURCE_CONTENTION" | "CUSTOM_ALERT" | "MONITORING_UNAVAILABLE" | "INFO";
"event.start"?: string;
"affected_entity_ids"?: string[];
}
```
##### 완화 이벤트
완화 이벤트는 다음 단계에 대한 조사를 위한 완화 보고서 생성을 트리거하는 데 사용됩니다. 이벤트 스키마는 다음과 같습니다.
```
{
"task_id": string;
"task_version": number;
"event.type": "mitigation_request";
}
```
## 제거
원격 측정 소스는 에이전트 공간 수준과 계정 수준에서 두 가지 수준으로 연결됩니다. 완전히 제거하려면 먼저 에이전트 공간이 사용되는 모든 에이전트 공간에서 제거한 다음 등록을 취소할 수 있습니다.
### 1단계: 에이전트 공간에서 제거
1. 에이전트 공간 페이지에서 에이전트 공간을 선택하고 세부 정보 보기를 누릅니다.
1. 기능 탭을 선택합니다.
1. 아래로 스크롤하여 원격 측정 섹션으로 이동합니다.
1. Dynatrace 선택
1. 제거를 누릅니다.
### 2단계: 계정에서 등록 취소
1. **기능 공급자** 페이지로 이동(측면 탐색에서 액세스 가능)
1. **현재 등록된** 섹션으로 스크롤합니다.
1. 에이전트 공간 수가 0인지 확인합니다(다른 에이전트 공간에서 위의 1단계를 반복하지 않는 경우).
1. Dynatrace 옆의 등록 취소를 누릅니다.
# DataDog 연결
## 기본 제공, 단방향 통합
현재 AWS DevOps 에이전트는 기본 제공 단방향 통합을 통해 Datadog 사용자를 지원하므로 다음을 사용할 수 있습니다.
+ **자동 조사 트리거링** - AWS DevOps 에이전트 웹후크를 통해 AWS DevOps 에이전트 인시던트 해결 조사를 트리거하도록 Datadog 이벤트를 구성할 수 있습니다.
+ **원격 측정 내부 검사** - AWS DevOps Agent는 각 공급자의 원격 MCP 서버를 통해 문제를 조사할 때 Datadog 원격 측정을 내부 검사할 수 있습니다.
## 온보딩
### 1단계: 연결
계정 액세스 자격 증명을 사용하여 Datadog 원격 MCP 엔드포인트에 대한 연결 설정
#### 구성
1. **기능 공급자** 페이지로 이동(측면 탐색에서 액세스 가능)
1. **텔레메트**리 아래의 **사용 가능한** 공급자 섹션에서 **Datadog**을 찾고 **등록**을 클릭합니다.
1. Datadog MCP 서버 세부 정보를 입력합니다.
+ **서버 이름** - 고유 식별자(예: my-datadog-server)
+ **엔드포인트 URL** - Datadog MCP 서버 엔드포인트입니다. 엔드포인트 URL은 Datadog 사이트에 따라 다릅니다. 아래 Datadog 사이트 엔드포인트 표를 참조하세요.
+ **설명** - 선택적 서버 설명
1. 다음을 클릭합니다.
1. 검토 및 제출
#### Datadog 사이트 엔드포인트
MCP 엔드포인트 URL은 Datadog 사이트에 따라 다릅니다. 사이트를 식별하려면 Datadog에 로그인할 때 브라우저의 URL을 확인하거나 [Datadog 사이트 액세스를](https://docs.datadoghq.com/getting_started/site/#access-the-datadog-site) 참조하세요.
| Datadog 사이트 | 사이트 도메인 | MCP 엔드포인트 URL |
| --- | --- | --- |
| US1(기본값) | datadoghq.com | https://mcp.datadoghq.com/api/unstable/mcp-server/mcp |
| US3 | us3.datadoghq.com | https://mcp.us3.datadoghq.com/api/unstable/mcp-server/mcp |
| US5 | us5.datadoghq.com | https://mcp.us5.datadoghq.com/api/unstable/mcp-server/mcp |
| EU1 | datadoghq.eu | https://mcp.datadoghq.eu/api/unstable/mcp-server/mcp |
| AP1 | ap1.datadoghq.com | https://mcp.ap1.datadoghq.com/api/unstable/mcp-server/mcp |
| AP2 | ap2.datadoghq.com | https://mcp.ap2.datadoghq.com/api/unstable/mcp-server/mcp |
#### 권한 부여
다음을 통해 OAuth 권한 부여 완료:
+ Datadog OAuth 페이지에서 사용자 권한 부여
+ 로그인하지 않은 경우 허용, 로그인을 클릭한 다음 권한 부여를 클릭합니다.
구성되면 모든 에이전트 스페이스에서 Datadog을 사용할 수 있게 됩니다.
### 2단계: 활성화
특정 에이전트 공간에서 DataDog를 활성화하고 적절한 범위 지정을 구성합니다.
#### 구성
1. 에이전트 스페이스 페이지에서 에이전트 스페이스를 선택하고 세부 정보 보기를 누릅니다(에이전트 스페이스를 아직 생성하지 않은 경우 참조[에이전트 스페이스 생성](getting-started-with-aws-devops-agent-creating-an-agent-space.md)).
1. 기능 탭을 선택합니다.
1. 아래로 스크롤하여 원격 측정 섹션으로 이동합니다.
1. 추가를 누릅니다.
1. Datadog 선택
1. 다음
1. 검토 후 저장을 누릅니다.
1. Webhook URL 및 API 키 복사
### 3단계: 웹후크 구성
Webhook URL 및 API 키를 사용하여 예를 들어 경보에서 조사를 트리거하는 이벤트를 보내도록 Datadog을 구성할 수 있습니다.
DevOps 에이전트가 전송된 이벤트를 사용할 수 있도록 하려면 웹후크로 전송된 데이터가 아래에 지정된 데이터 스키마와 일치하는지 확인합니다. 이 스키마와 일치하지 않는 이벤트는 DevOps Agent에서 무시할 수 있습니다.
메서드 및 헤더 설정
```
method: "POST",
headers: {
"Content-Type": "application/json",
"Authorization": "Bearer ",
},
```
본문을 JSON 문자열로 전송합니다.
```
{
eventType: 'incident';
incidentId: string;
action: 'created' | 'updated' | 'closed' | 'resolved';
priority: "CRITICAL" | "HIGH" | "MEDIUM" | "LOW" | "MINIMAL";
title: string;
description?: string;
timestamp?: string;
service?: string;
// The original event generated by service is attached here.
data?: object;
}
```
Datadog [https://docs.datadoghq.com/integrations/webhooks/](https://docs.datadoghq.com/integrations/webhooks/) 웹후크를 전송합니다(권한 부여 없음을 선택하고 대신 사용자 지정 헤더 옵션을 사용).
자세히 알아보기: [Datadog 원격 MCP 서버](https://www.datadoghq.com/blog/datadog-remote-mcp-server/)
## 제거
원격 측정 소스는 에이전트 공간 수준과 계정 수준에서 두 가지 수준으로 연결됩니다. 완전히 제거하려면 먼저 에이전트 공간이 사용되는 모든 에이전트 공간에서 제거한 다음 등록을 취소할 수 있습니다.
### 1단계: 에이전트 공간에서 제거
1. 에이전트 공간 페이지에서 에이전트 공간을 선택하고 세부 정보 보기를 누릅니다.
1. 기능 탭을 선택합니다.
1. 아래로 스크롤하여 원격 측정 섹션으로 이동합니다.
1. Datadog 선택
1. 제거를 누릅니다.
### 2단계: 계정에서 등록 취소
1. **기능 공급자** 페이지로 이동(측면 탐색에서 액세스 가능)
1. **현재 등록된** 섹션으로 스크롤합니다.
1. 에이전트 공간 수가 0인지 확인합니다(다른 에이전트 공간에서 위의 1단계를 반복하지 않는 경우).
1. Datadog 옆의 등록 취소를 누릅니다.
# Grafana 연결
Grafana 통합을 통해 AWS DevOps Agent는 인시던트 조사 중에 Grafana 인스턴스에서 지표, 대시보드 및 알림 데이터를 쿼리할 수 있습니다. 이 통합은 Grafana의 계정 수준 등록 후 개별 에이전트 스페이스에 연결하는 2단계 프로세스를 따릅니다.
보안을 개선하기 위해 Grafana 통합은 읽기 전용 도구만 활성화합니다. 쓰기 도구는 비활성화되어 있으며 활성화할 수 없습니다. 즉, 에이전트는 Grafana 인스턴스에서 데이터를 쿼리하고 읽을 수 있지만 대시보드, 알림 또는 주석과 같은 Grafana 리소스를 생성, 수정 또는 삭제할 수는 없습니다. 자세한 내용은 [Security in AWS DevOps Agent](https://docs.aws.amazon.com/devopsagent/latest/userguide/aws-devops-agent-security.html)를 참조하세요.
## Grafana 요구 사항
Grafana를 연결하기 전에 다음을 확인하세요.
+ Grafana 버전 9.0 이상. 일부 기능, 특히 데이터 소스 관련 작업은 API 엔드포인트 누락으로 인해 이전 버전에서 제대로 작동하지 않을 수 있습니다.
+ HTTPS를 통해 액세스할 수 있는 Grafana 인스턴스입니다. 퍼블릭 및 프라이빗 네트워크 엔드포인트가 모두 지원됩니다. 프라이빗 네트워크 연결을 사용하면 퍼블릭 인터넷 액세스 없이 VPC 내에서 Grafana 인스턴스를 호스팅할 수 있습니다. 자세한 내용은 [프라이빗 호스팅 도구에 연결](configuring-capabilities-for-aws-devops-agent-connecting-to-privately-hosted-tools.md)을 참조하세요.
+ 적절한 읽기 권한이 있는 액세스 토큰이 있는 Grafana 서비스 계정
## Grafana 등록(계정 수준)
Grafana는 AWS 계정 수준에서 등록되며 해당 계정의 모든 에이전트 스페이스 간에 공유됩니다.
### 1단계: Grafana 구성
1. AWS Management Console에 로그인
1. AWS DevOps 에이전트 콘솔로 이동
1. **기능 공급자** 페이지로 이동(측면 탐색에서 액세스 가능)
1. **텔레메트리** 아래의 **사용 가능한** 공급자 섹션에서 **Grafana**를 찾고 **등록**을 클릭합니다.
1. **Grafana 구성** 페이지에서 다음 정보를 입력합니다.
+ **서비스 이름**(필수) - 영숫자, 하이픈 및 밑줄만 사용하여 Grafana 서버의 설명 이름을 입력합니다. 예를 들어 `my-grafana-server`입니다.
+ **Grafana URL**(필수) - Grafana 인스턴스의 전체 HTTPS URL을 입력합니다. 예를 들어 `https://myinstance.grafana.net`입니다.
+ **서비스 계정 액세스 토큰**(필수) - Grafana 서비스 계정 액세스 토큰을 입력합니다. 토큰은 일반적으로 로 시작합니다`glsa_`. 서비스 계정 토큰을 생성하려면 Grafana 인스턴스로 이동하여 **관리 > 서비스 계정으로** 이동하여 최종 사용자 역할이 있는 서비스 계정을 생성하고 토큰을 생성합니다.
+ **설명**(선택 사항) - 서버의 목적을 식별하는 데 도움이 되는 설명을 추가합니다. 예를 들어 `Production Grafana server for monitoring`입니다.
1. (선택 사항) 조직의 목적으로 등록에 AWS 태그를 추가합니다.
1. **다음**을 클릭합니다.
### 2단계: Grafana 등록 검토 및 제출
1. 모든 Grafana 구성 세부 정보 검토
1. **제출**을 클릭하여 등록을 완료합니다.
1. 등록에 성공하면 Grafana가 기능 공급자 페이지의 **현재 등록된** 섹션에 나타납니다.
## 에이전트 스페이스에 Grafana 추가
계정 수준에서 Grafana를 등록한 후 개별 에이전트 스페이스에 연결할 수 있습니다.
1. AWS DevOps 에이전트 콘솔에서 에이전트 스페이스를 선택합니다.
1. **기능** 탭으로 이동
1. **원격 측정** 섹션에서 **추가**를 클릭합니다.
1. 사용 가능한 공급자 목록에서 **Grafana**를 선택합니다.
1. **저장**을 클릭합니다.
## Grafana 알림 웹후크 구성
Grafana 연락 지점을 통해 웹후크를 전송하여 알림이 실행될 때 자동으로 AWS DevOps 에이전트 조사를 트리거하도록 Grafana를 구성할 수 있습니다. 웹후크 인증 방법 및 자격 증명 관리에 대한 자세한 내용은 섹션을 참조하세요[Webhook를 통해 DevOps 에이전트 호출](configuring-capabilities-for-aws-devops-agent-invoking-devops-agent-through-webhook.md).
### 1단계: 사용자 지정 알림 템플릿 생성
Grafana 인스턴스에서 **알림 > 연락 지점 > 알림 템플릿**으로 이동하여 다음 콘텐츠가 포함된 새 템플릿을 생성합니다.
```
{{ define "devops-agent-payload" }}
{
"eventType": "incident",
"incidentId": "{{ (index .Alerts 0).Labels.alertname }}-{{ (index .Alerts 0).Fingerprint }}",
"action": "{{ if eq .Status "resolved" }}resolved{{ else }}created{{ end }}",
"priority": "{{ if eq .Status "resolved" }}MEDIUM{{ else }}HIGH{{ end }}",
"title": "{{ (index .Alerts 0).Labels.alertname }}",
"description": "{{ (index .Alerts 0).Annotations.summary }}",
"service": "{{ if (index .Alerts 0).Labels.job }}{{ (index .Alerts 0).Labels.job }}{{ else }}grafana{{ end }}",
"timestamp": "{{ (index .Alerts 0).StartsAt }}",
"data": {
"metadata": {
{{ range $k, $v := (index .Alerts 0).Labels }}
"{{ $k }}": "{{ $v }}",
{{ end }}
"_source": "grafana"
}
}
}
{{ end }}
```
이 템플릿은 Grafana 알림을 AWS DevOps Agent에서 예상하는 웹후크 페이로드 구조로 포맷합니다. 알림 레이블, 주석 및 상태를 적절한 필드에 매핑하고 모든 알림 레이블을 메타데이터로 포함합니다.
**참고:**이 템플릿은 그룹의 첫 번째 알림만 처리합니다. Grafana는 기본적으로 여러 실행 알림을 단일 알림으로 그룹화합니다. 각 알림이 개별적으로 전송되도록 하려면 별로 그룹화하도록 알림 정책을 구성합니다`alertname`. 또한이 템플릿은 레이블 값 또는 주석에서 특수 JSON 문자를 이스케이프 처리하지 않습니다. 알림 레이블과 `summary` 주석에 큰따옴표 또는 줄 바꿈과 같은 문자가 포함되어 있어서 잘못된 JSON이 생성되지 않는지 확인합니다.
### 2단계: Webhook 연락 지점 생성
1. Grafana에서 **알림 > 연락 지점**으로 이동하여 **연락 지점 추가**를 클릭합니다.
1. **Webhook**를 통합 유형으로 선택
1. **URL**을 your AWS DevOps Agent 웹후크 엔드포인트로 설정
1. **선택적 웹후크 설정**에서 웹후크 유형에 따라 인증 헤더를 구성합니다. 자세한 내용은 [Webhook 인증 방법을](configuring-capabilities-for-aws-devops-agent-invoking-devops-agent-through-webhook.md) 참조하세요.
1. 사용자 지정 템플릿을 사용하도록 **메시지** 필드를 설정합니다. `{{ template "devops-agent-payload" . }}`
1. **연락 지점 저장**을 클릭합니다.
### 3단계: 알림 정책에 연락 지점 할당
1. **알림 > 알림 정책**으로 이동
1. 기존 정책 편집 또는 새 정책 생성
1. 연락 지점을 생성한 웹후크 연락 지점으로 설정합니다.
1. **정책 저장**을 클릭합니다.
일치하는 알림이 실행되면 Grafana는 형식이 지정된 페이로드를 AWS DevOps 에이전트로 전송하여 조사를 자동으로 시작합니다.
## 제한 사항
+ **ClickHouse 데이터 소스 도구** - ClickHouse 데이터 소스 도구는 현재 지원되지 않습니다.
+ **선제적 인시던트 예방** - [선제적 인시던트 예방](working-with-devops-agent-proactive-incident-prevention.md)는 현재 Grafana 도구를 사용하지 않습니다. 향후 릴리스에 대한 지원이 계획되어 있습니다.
### Amazon Managed Grafana 고려 사항
[Amazon Managed Grafana](https://aws.amazon.com/grafana/)(AMG)를 사용하는 경우 다음 제한 사항에 유의하세요.
+ **Webhook 연락 지점은 지원되지 않음** - AMG는 현재 알림 구성에서 Webhook 연락 지점을 지원하지 않습니다. AMG를 사용하여 알림 웹후크를 AWS DevOps Agent로 직접 보낼 수 없습니다. 자세한 내용은 [Amazon Managed Grafana의 연락 지점 알림을 참조하세요](https://docs.aws.amazon.com/grafana/latest/userguide/v9-alerting-explore-contacts.html).
+ **서비스 계정 토큰 만료** - AMG 서비스 계정 토큰의 최대 만료 기간은 30일입니다. 토큰이 만료되기 AWS DevOps 전에 토큰을 교체하고 Grafana 등록을 업데이트해야 합니다. 자격 증명을 업데이트하는 방법은 [Grafana 연결 관리를](#managing-grafana-connections) 참조하세요. AMG 토큰 제한에 대한 자세한 내용은 [Amazon Managed Grafana의 서비스 계정을](https://docs.aws.amazon.com/grafana/latest/userguide/service-accounts.html) 참조하세요.
## Grafana 연결 관리
+ **자격 증명 업데이트 **- 서비스 계정 토큰이 만료되거나 업데이트해야 하는 경우 기능 공급자 페이지에서 Grafana 등록을 취소하고 새 토큰으로 다시 등록합니다.
+ **연결된 인스턴스 보기** - AWS DevOps 에이전트 콘솔에서 에이전트 스페이스를 선택하고 기능 탭으로 이동하여 연결된 원격 측정 소스를 봅니다.
+ **Grafana 제거** - 에이전트 공간에서 Grafana를 연결 해제하려면 원격 측정 섹션에서 Grafana를 선택하고 **제거**를 클릭합니다. 등록을 완전히 제거하려면 먼저 모든 에이전트 스페이스에서 제거한 다음 기능 공급자 페이지에서 등록을 취소합니다.
# 새 복제본 연결
## 기본 제공, 단방향 통합
현재 AWS DevOps Agent는 기본 제공 단방향 통합을 통해 New Relic 사용자를 지원하므로 다음을 사용할 수 있습니다.
+ **자동 조사 트리거링** - AWS DevOps 에이전트 웹후크를 통해 AWS DevOps 에이전트 인시던트 해결 조사를 트리거하도록 새 Relic 이벤트를 구성할 수 있습니다.
+ **원격 측정 내부 검사** - AWS DevOps Agent는 각 공급자의 원격 MCP 서버를 통해 문제를 조사할 때 New Relic 원격 측정을 내부 검사할 수 있습니다.
## 온보딩
### 1단계: 연결
계정 액세스 자격 증명을 사용하여 New Relic 원격 MCP 엔드포인트에 대한 연결 설정
New Relic MCP 도구를 활성화하려면 New relic의 전체 플랫폼 사용자(기본/코어 아님)를 사용하세요.
#### 구성
1. **기능 공급자** 페이지로 이동(측면 탐색에서 액세스 가능)
1. **텔레메트**리 아래의 **사용 가능한** 공급자 섹션에서 **새 복제본**을 찾고 **등록**을 클릭합니다.
1. 지침에 따라 New Relic API 키를 가져옵니다.
1. New Relic MCP 서버 API 키 세부 정보를 입력합니다.
+ **계정 ID:** 위에서 얻은 New Relic 계정 ID를 입력합니다.
+ **API 키:** 위에서 얻은 API 키를 입력합니다.
+ New Relic 계정의 위치에 따라 **미국 또는 EU 리전을 선택합니다**.
1. 추가를 클릭합니다.
### 2단계: 활성화
특정 에이전트 공간에서 New Relic을 활성화하고 적절한 범위 지정을 구성합니다.
#### 구성
1. 에이전트 공간 페이지에서 에이전트 공간을 선택하고 세부 정보 보기를 누릅니다(에이전트 공간을 아직 생성하지 않은 경우 참조[에이전트 스페이스 생성](getting-started-with-aws-devops-agent-creating-an-agent-space.md)).
1. 기능 탭 선택
1. 아래로 스크롤하여 원격 측정 섹션으로 이동합니다.
1. 추가를 누릅니다.
1. 새 복제본 선택
1. 다음
1. 검토 후 저장을 누릅니다.
1. Webhook URL 및 API 키 복사
### 3단계: 웹후크 구성
Webhook URL 및 API 키를 사용하여 경보에서와 같이 조사를 트리거하는 이벤트를 보내도록 New Relic을 구성할 수 있습니다. 웹후크 설정에 대한 자세한 내용은 [변경 추적 웹후크를 참조하세요](https://docs.newrelic.com/docs/change-tracking/change-tracking-webhooks/).
DevOps 에이전트가 전송된 이벤트를 사용할 수 있도록 하려면 웹후크로 전송된 데이터가 아래에 지정된 데이터 스키마와 일치하는지 확인합니다. 이 스키마와 일치하지 않는 이벤트는 DevOps Agent에서 무시할 수 있습니다.
메서드 및 헤더 설정
```
method: "POST",
headers: {
"Content-Type": "application/json",
"Authorization": "Bearer ",
},
```
본문을 JSON 문자열로 전송합니다.
```
{
eventType: 'incident';
incidentId: string;
action: 'created' | 'updated' | 'closed' | 'resolved';
priority: "CRITICAL" | "HIGH" | "MEDIUM" | "LOW" | "MINIMAL";
title: string;
description?: string;
timestamp?: string;
service?: string;
// The original event generated by service is attached here.
data?: object;
}
```
New Relic [https://newrelic.com/instant-observability/webhook-notifications](https://newrelic.com/instant-observability/webhook-notifications) 웹후크를 전송합니다. 권한 부여 유형에 대해 보유자 토큰을 선택하거나 권한 부여 없음을 선택하고 대신를 사용자 지정 헤더`Authorization: Bearer `로 추가할 수 있습니다.
자세히 알아보기: [https://docs.newrelic.com/docs/agentic-ai/mcp/overview/](https://docs.newrelic.com/docs/agentic-ai/mcp/overview/)
## 제거
원격 측정 소스는 에이전트 스페이스 수준과 계정 수준에서 두 가지 수준으로 연결됩니다. 완전히 제거하려면 먼저 에이전트 공간이 사용되는 모든 에이전트 공간에서 제거한 다음 등록을 취소할 수 있습니다.
### 1단계: 에이전트 공간에서 제거
1. 에이전트 스페이스 페이지에서 에이전트 스페이스를 선택하고 세부 정보 보기를 누릅니다.
1. 기능 탭 선택
1. 아래로 스크롤하여 원격 측정 섹션으로 이동합니다.
1. 새 복제본 선택
1. 제거를 누릅니다.
### 2단계: 계정에서 등록 취소
1. **기능 공급자** 페이지로 이동(측면 탐색에서 액세스 가능)
1. **현재 등록된** 섹션으로 스크롤합니다.
1. 에이전트 공간 수가 0인지 확인합니다(다른 에이전트 공간에서 위의 1단계를 반복하지 않는 경우).
1. New Relic 옆의 등록 취소를 누릅니다.
# Splunk 연결
## 기본 제공, 단방향 통합
현재 AWS DevOps Agent는 기본 제공 단방향 통합을 통해 Splunk 사용자를 지원하므로 다음을 사용할 수 있습니다.
+ **자동 조사 트리거 **- Splunk 이벤트는 AWS DevOps 에이전트 웹후크를 통해 AWS DevOps 에이전트 인시던트 해결 조사를 트리거하도록 구성할 수 있습니다.
+ **원격 측정 내부 검사** - AWS DevOps Agent는 각 공급자의 원격 MCP 서버를 통해 문제를 조사할 때 Splunk 원격 측정을 내부 검사할 수 있습니다.
## 사전 조건
### Splunk API 토큰 가져오기
Splunk를 연결하려면 MCP URL과 토큰이 필요합니다.
### Splunk 관리자 단계
Splunk 관리자는 다음 단계를 수행해야 합니다.
+ [REST API 액세스 ](https://docs.splunk.com/Documentation/SplunkCloud/latest/RESTTUT/RESTandCloud)활성화
+ 배포에서 [토큰 인증을 활성화합니다](https://help.splunk.com/en/splunk-cloud-platform/administer/manage-users-and-security/9.2.2406/authenticate-into-the-splunk-platform-with-tokens/enable-or-disable-token-authentication).
+ 새 역할 'mcp\$1user'를 생성하면 새 역할에 기능이 없어도 됩니다.
+ MCP 서버를 사용할 권한이 있는 배포의 모든 사용자에게 'mcp\$1user' 역할을 할당합니다.
+ 대상을 'mcp'로 하는 권한 있는 사용자에 대한 토큰을 생성하고, 사용자에게 토큰을 직접 생성할 권한이 없는 경우 적절한 만료를 설정합니다.
### Splunk 사용자 단계
Splunk 사용자는 다음 단계를 수행해야 합니다.
+ Splunk 관리자로부터 적절한 토큰을 가져오거나 권한이 있는 경우 직접 토큰을 생성합니다. 토큰의 대상은 'mcp'여야 합니다.
## 온보딩
### 1단계: 연결
계정 액세스 자격 증명을 사용하여 Splunk 원격 MCP 엔드포인트에 대한 연결 설정
#### 구성
1. **기능 공급자** 페이지로 이동(측면 탐색에서 액세스 가능)
1. 사용 **가능한** 공급자 섹션의 **원격 측정**에서 **Splunk**를 찾고 **등록**을 클릭합니다.
1. Splunk MCP 서버 세부 정보를 입력합니다.
+ **서버 이름** - 고유 식별자(예: my-splunk-server)
+ **엔드포인트 URL** - Splunk MCP 서버 엔드포인트:
`https://.api.scs.splunk.com//mcp/v1/`
+ **설명** - 선택적 서버 설명
+ **토큰 이름** - 인증을 위한 보유자 토큰의 이름: `my-splunk-token`
+ **토큰 값** 인증을 위한 보유자 토큰 값
### 2단계: 활성화
특정 에이전트 공간에서 Splunk를 활성화하고 적절한 범위 지정을 구성합니다.
#### 구성
1. 에이전트 스페이스 페이지에서 에이전트 스페이스를 선택하고 세부 정보 보기를 누릅니다(에이전트 스페이스를 아직 생성하지 않은 경우 참조[에이전트 스페이스 생성](getting-started-with-aws-devops-agent-creating-an-agent-space.md)).
1. 기능 탭을 선택합니다.
1. 아래로 스크롤하여 원격 측정 섹션으로 이동합니다.
1. 추가를 누릅니다.
1. Splunk 선택
1. 다음
1. 검토 후 저장을 누릅니다.
1. Webhook URL 및 API 키 복사
### 3단계: 웹후크 구성
Webhook URL 및 API 키를 사용하여 경보에서와 같이 조사를 트리거하는 이벤트를 보내도록 Splunk를 구성할 수 있습니다.
DevOps 에이전트가 전송된 이벤트를 사용할 수 있도록 하려면 웹후크로 전송된 데이터가 아래에 지정된 데이터 스키마와 일치하는지 확인합니다. 이 스키마와 일치하지 않는 이벤트는 DevOps Agent에서 무시할 수 있습니다.
메서드 및 헤더 설정
```
method: "POST",
headers: {
"Content-Type": "application/json",
"Authorization": "Bearer ",
},
```
본문을 JSON 문자열로 전송합니다.
```
{
eventType: 'incident';
incidentId: string;
action: 'created' | 'updated' | 'closed' | 'resolved';
priority: "CRITICAL" | "HIGH" | "MEDIUM" | "LOW" | "MINIMAL";
title: string;
description?: string;
timestamp?: string;
service?: string;
// The original event generated by service is attached here.
data?: object;
}
```
Splunk [https://help.splunk.com/en/splunk-enterprise/alert-and-respond/alerting-manual/9.4/configure-alert-actions/use-a-webhook-alert-action](https://help.splunk.com/en/splunk-enterprise/alert-and-respond/alerting-manual/9.4/configure-alert-actions/use-a-webhook-alert-action) 사용하여 웹후크 전송(권한 부여 없음 선택 대신 사용자 지정 헤더 옵션 사용)
### 자세히 알아보기:
+ Splunk의 MCP 서버 설명서: [https://help.splunk.com/en/splunk-cloud-platform/mcp-server-for-splunk-platform/about-mcp-server-for-splunk-platform ](https://help.splunk.com/en/splunk-cloud-platform/mcp-server-for-splunk-platform/about-mcp-server-for-splunk-platform)
+ Splunk Cloud Platform REST API의 액세스 요구 사항 및 제한 사항: [https://docs.splunk.com/Documentation/SplunkCloud/latest/RESTTUT/RESTandCloud ](https://docs.splunk.com/Documentation/SplunkCloud/latest/RESTTUT/RESTandCloud)
+ Splunk Cloud Platform에서 인증 토큰 관리: [https://help.splunk.com/en/splunk-cloud-platform/administer/manage-users-and-security/9.3.2411/authenticate-into-the-splunk-platform-with-tokens/manage-or-delete-authentication-tokens ](https://help.splunk.com/en/splunk-cloud-platform/administer/manage-users-and-security/9.3.2411/authenticate-into-the-splunk-platform-with-tokens/manage-or-delete-authentication-tokens)
+ Splunk Web을 사용하여 역할 생성 및 관리: [https://docs.splunk.com/Documentation/SplunkCloud/latest/Security/Addandeditroles ](https://docs.splunk.com/Documentation/SplunkCloud/latest/Security/Addandeditroles)
## 제거
원격 측정 소스는 에이전트 공간 수준과 계정 수준에서 두 가지 수준으로 연결됩니다. 완전히 제거하려면 먼저 에이전트 공간이 사용되는 모든 에이전트 공간에서 제거한 다음 등록을 취소할 수 있습니다.
### 1단계: 에이전트 공간에서 제거
1. 에이전트 공간 페이지에서 에이전트 공간을 선택하고 세부 정보 보기를 누릅니다.
1. 기능 탭을 선택합니다.
1. 아래로 스크롤하여 원격 측정 섹션으로 이동합니다.
1. Splunk 선택
1. 제거를 누릅니다.
### 2단계: 계정에서 등록 취소
1. **기능 공급자** 페이지로 이동(측면 탐색에서 액세스 가능)
1. **현재 등록된** 섹션으로 스크롤합니다.
1. 에이전트 공간 수가 0인지 확인합니다(다른 에이전트 공간에서 위의 1단계를 반복하지 않는 경우).
1. Splunk 옆의 등록 취소를 누릅니다.
# 티켓팅 및 채팅에 연결
AWS DevOps 에이전트는 팀의 기존 커뮤니케이션 채널에 참여하여 팀의 구성원 역할을 하도록 설계되었습니다. DevOps 에이전트를 ServiceNow 및 PagerDuty와 같은 티켓팅 및 경보 시스템에 연결하여 인시던트 티켓에서 조사를 자동으로 시작하여 기존 워크플로 내에서 인시던트 대응을 가속화하여 의도한 복구 시간(MTTR)을 줄일 수 있습니다. 또한 DevOps 에이전트를 Slack과 같은 팀 협업 시스템에 연결하여 채팅 채널에서 DevOps 에이전트로부터 활동 요약을 받을 수 있습니다.
티켓팅 및 채팅 통합 연결에 대한 자세한 내용은 다음을 참조하세요.
+ [PagerDuty 연결](connecting-to-ticketing-and-chat-connecting-pagerduty.md)
+ [ServiceNow 연결](connecting-to-ticketing-and-chat-connecting-servicenow.md)
+ [Slack 연결](connecting-to-ticketing-and-chat-connecting-slack.md)
# PagerDuty 연결
PagerDuty 통합을 통해 AWS DevOps Agent는 인시던트 조사 및 자동 대응 중에 PagerDuty 계정에서 인시던트 데이터, 대기 일정 및 서비스 정보에 액세스하고 업데이트할 수 있습니다. 이 통합은 보안 인증을 위해 OAuth 2.0을 사용합니다.
**중요**
** AWS DevOps Agent는 최신 PagerDuty OAuth 2.0(범위 지정 OAuth)만 지원합니다. 리디렉션 uri가 있는 레거시 PagerDuty OAuth는 지원되지 않습니다.
## PagerDuty 요구 사항
PagerDuty를 연결하기 전에 다음을 확인해야 합니다.
+ OAuth 클라이언트 ID 및 클라이언트 보안 암호가 있는 PagerDuty 계정
+ PagerDuty 계정 하위 도메인(예: PagerDuty URL이 `https://your-company.pagerduty.com`인 경우 하위 도메인은 `your-company`)
## PagerDuty 등록
PagerDuty는 AWS 계정 수준에서 등록되고 해당 계정의 모든 에이전트 스페이스 간에 공유됩니다.
### 1단계: PagerDuty에서 액세스 구성
1. AWS Management Console에 로그인
1. AWS DevOps 에이전트 콘솔로 이동
1. **기능 공급자** 페이지로 이동(측면 탐색에서 액세스 가능)
1. **통신** 아래의 **사용 가능한** 공급자 섹션에서 **PagerDuty**를 찾고 **등록**을 클릭합니다.
1. **PagerDuty의 액세스 구성** 페이지에서 안내 설정을 따릅니다.
**서비스 리전 및 하위 도메인을 확인합니다.**
+ **계정 범위** - PagerDuty 리전(**미국** 또는 **EU**)을 선택하고 PagerDuty 하위 도메인을 입력합니다. 예를 들어 PagerDuty URL이 인 경우 `https://your-company.pagerduty.com`를 입력합니다`your-company`.
**PagerDuty에서 새 앱을 생성합니다.**
+ 별도의 브라우저 탭에서 PagerDuty에 로그인하고 **통합 > 앱 등록으로 이동합니다.**
+ **OAuth 2.0 범위 OAuth**를 사용하여 새 앱 생성
+ **권한**에서 , `incidents.read` `incidents.write`및 최소 필수 범위를 부여합니다. `services.read`
+ **Events Integration**을 활성화하여 AWS DevOps 에이전트와 PagerDuty 간의 양방향 통신 허용
**OAuth 자격 증명 구성:**
+ **권한 범위** - 최소 필수 범위는 `incidents.read`, `incidents.write`, 입니다. `services.read`
+ **클라이언트 이름** - OAuth 클라이언트에 대한 설명이 포함된 이름을 입력합니다.
+ **클라이언트 ID** - PagerDuty 앱 등록의 OAuth 클라이언트 ID를 입력합니다.
+ **클라이언트 보안 암호** - PagerDuty 앱 등록의 OAuth 클라이언트 보안 암호를 입력합니다.
### 2단계: PagerDuty 등록 검토 및 제출
1. 모든 PagerDuty 구성 세부 정보 검토
1. **제출**을 클릭하여 등록을 완료합니다.
1. 등록에 성공하면 PagerDuty가 기능 공급자 페이지의 **현재 등록된** 섹션에 나타납니다.
## 에이전트 스페이스에 PagerDuty 추가
계정 수준에서 PagerDuty를 등록한 후 개별 에이전트 스페이스에 연결할 수 있습니다.
1. AWS DevOps 에이전트 콘솔에서 에이전트 스페이스를 선택합니다.
1. **기능** 탭으로 이동
1. **커뮤니케이션** 섹션에서 **추가**를 클릭합니다.
1. 사용 가능한 공급자 목록에서 **PagerDuty**를 선택합니다.
1. **저장**을 클릭합니다.
## PagerDuty 연결 관리
+ **자격 증명 업데이트 **- OAuth 자격 증명을 업데이트해야 하는 경우 기능 공급자 페이지에서 PagerDuty 등록을 취소하고 새 자격 증명으로 다시 등록합니다.
+ **연결 보기** - AWS DevOps 에이전트 콘솔에서 에이전트 스페이스를 선택하고 기능 탭으로 이동하여 연결된 통신 통합을 확인합니다.
+ **PagerDuty 제거** - 에이전트 공간에서 PagerDuty를 연결 해제하려면 통신 섹션에서 선택한 다음 **제거**를 클릭합니다. 등록을 완전히 제거하려면 먼저 모든 에이전트 스페이스에서 제거한 다음 기능 공급자 페이지에서 등록을 취소합니다.
## Webhook 지원
AWS DevOps Agent는 PagerDuty V3 웹후크만 지원합니다. 이전 웹후크 버전은 지원되지 않습니다.
PagerDuty V3 웹후크 구독에 대한 자세한 내용은 PagerDuty 개발자 설명서의 [Webhooks 개요를](https://developer.pagerduty.com/docs/webhooks-overview#webhook-subscriptions) 참조하세요.
# ServiceNow 연결
이 자습서에서는 ServiceNow 인스턴스를 AWS DevOps Agent에 연결하여 티켓이 생성될 때 인시던트 대응 조사를 자동으로 시작하고 주요 조사 결과를 발신 티켓에 게시할 수 있도록 안내합니다. 또한 특정 티켓만 DevOps 에이전트 스페이스로 전송하도록 ServiceNow 인스턴스를 구성하는 방법과 여러 DevOps 에이전트 스페이스에서 티켓 라우팅을 오케스트레이션하는 방법에 대한 예제도 포함되어 있습니다.
## 초기 설정
첫 번째 단계는 ServiceNow에서 ServiceNow 인스턴스에 액세스하는 데 AWS DevOps가 사용할 수 있는 OAuth 애플리케이션 클라이언트를 생성하는 것입니다.
### ServiceNow OAuth 애플리케이션 클라이언트 생성
1. 인스턴스의 클라이언트 자격 증명 시스템 속성 활성화
1. 필터 검색 상자에서 검색한 다음 Enter`sys_properties.list`를 누릅니다(옵션은 표시되지 않지만 Enter를 누르면 작동함).
1. 새로 만들기를 선택합니다.
1. 이름을 로, 값을 true에 추가`glide.oauth.inbound.client.credential.grant_type.enabled`하고 유형은 true \$1 false
![\[alt text not found\]](http://docs.aws.amazon.com/ko_kr/devopsagent/latest/userguide/images/09ed6d5ff911.png)
1. 필터 검색 상자에서 시스템 OAuth > 애플리케이션 레지스트리로 이동합니다.
1. “New” > “New Inbound Integration Experience” > “New Integration” > “OAuth - Client Credentials Grant”를 선택합니다.
1. 이름을 선택하고 OAuth 애플리케이션 사용자를 “문제 관리자”로 설정하고 “저장”을 클릭합니다.
![\[alt text not found\]](http://docs.aws.amazon.com/ko_kr/devopsagent/latest/userguide/images/aeff4c127f7c.png)
### ServiceNow OAuth 클라이언트를 AWS DevOps 에이전트에 연결
1. 이 프로세스는 두 곳에서 시작할 수 있습니다. 먼저 **기능 공급자** 페이지로 이동하여 **통신**에서 **ServiceNow**를 찾은 다음 **등록**을 클릭합니다. 또는 생성한 DevOps 에이전트 스페이스를 선택하고 기능 → 통신 → 추가 → ServiceNow로 이동하여 등록을 클릭할 수 있습니다.
1. 그런 다음 방금 생성한 OAuth 애플리케이션 클라이언트를 사용하여 DevOps Agent가 ServiceNow 인스턴스에 액세스할 수 있도록 권한을 부여합니다.
![\[alt text not found\]](http://docs.aws.amazon.com/ko_kr/devopsagent/latest/userguide/images/3db5a9aafc5f.png)
+ 다음 단계에 따라 Webhook에 대한 결과 정보를 저장합니다.
**중요**
이 정보는 다시 표시되지 않습니다.
![\[alt text not found\]](http://docs.aws.amazon.com/ko_kr/devopsagent/latest/userguide/images/80d0a319f87e.png)
### ServiceNow 비즈니스 규칙 구성
연결을 설정한 후에는 ServiceNow에서 비즈니스 규칙을 구성하여 DevOps 에이전트 스페이스(들)에 티켓을 보내야 합니다.
1. 활동 구독 → 관리 → 비즈니스 규칙으로 이동하여 새로 만들기를 클릭합니다.
1. “Table” 필드를 “Incident [incident]”로 설정하고 “Advanced” 상자를 선택한 다음 삽입, 업데이트 및 삭제 후 실행되도록 규칙을 설정합니다.
![\[alt text not found\]](http://docs.aws.amazon.com/ko_kr/devopsagent/latest/userguide/images/6f2a7370e2c0.png)
1. “고급” 탭으로 이동하여 다음 웹후크 스크립트를 추가하고 표시된 위치에 웹후크 보안 암호와 URL을 삽입한 다음 제출을 클릭합니다.
```
(function executeRule(current, previous /*null when async*/ ) {
var WEBHOOK_CONFIG = {
webhookSecret: GlideStringUtil.base64Encode('<<< INSERT WEBHOOK SECRET HERE >>>'),
webhookUrl: '<<< INSERT WEBHOOK URL HERE >>>'
};
function generateHMACSignature(payloadString, secret) {
try {
var mac = new GlideCertificateEncryption();
var signature = mac.generateMac(secret, "HmacSHA256", payloadString);
return signature;
} catch (e) {
gs.error('HMAC generation failed: ' + e);
return null;
}
}
function callWebhook(payload, config) {
try {
var timestamp = new Date().toISOString();
var payloadString = JSON.stringify(payload);
var payloadWithTimestamp =`${timestamp}:${payloadString}`;
var signature = generateHMACSignature(payloadWithTimestamp, config.webhookSecret);
if (!signature) {
gs.error('Failed to generate signature');
return false;
}
gs.info('Generated signature: ' + signature);
var request = new sn_ws.RESTMessageV2();
request.setEndpoint(config.webhookUrl);
request.setHttpMethod('POST');
request.setRequestHeader('Content-Type', 'application/json');
request.setRequestHeader('x-amzn-event-signature', signature);
request.setRequestHeader('x-amzn-event-timestamp', timestamp);
request.setRequestBody(payloadString);
var response = request.execute();
var httpStatus = response.getStatusCode();
var responseBody = response.getBody();
if (httpStatus >= 200 && httpStatus < 300) {
gs.info('Webhook sent successfully. Status: ' + httpStatus);
return true;
} else {
gs.error('Webhook failed. Status: ' + httpStatus + ', Response: ' + responseBody);
return false;
}
} catch (ex) {
gs.error('Error sending webhook: ' + ex.getMessage());
return false;
}
}
function createReference(field) {
if (!field || field.nil()) {
return null;
}
return {
link: field.getLink(true),
value: field.toString()
};
}
function getStringValue(field) {
if (!field || field.nil()) {
return null;
}
return field.toString();
}
function getIntValue(field) {
if (!field || field.nil()) {
return null;
}
var val = parseInt(field.toString());
return isNaN(val) ? null : val;
}
var eventType = (current.operation() == 'insert') ? "create" : "update";
var incidentEvent = {
eventType: eventType.toString(),
sysId: current.sys_id.toString(),
priority: getStringValue(current.priority),
impact: getStringValue(current.impact),
active: getStringValue(current.active),
urgency: getStringValue(current.urgency),
description: getStringValue(current.description),
shortDescription: getStringValue(current.short_description),
parent: getStringValue(current.parent),
incidentState: getStringValue(current.incident_state),
severity: getStringValue(current.severity),
problem: createReference(current.problem),
additionalContext: {}
};
incidentEvent.additionalContext = {
number: current.number.toString(),
opened_at: getStringValue(current.opened_at),
opened_by: current.opened_by.nil() ? null : current.opened_by.getDisplayValue(),
assigned_to: current.assigned_to.nil() ? null : current.assigned_to.getDisplayValue(),
category: getStringValue(current.category),
subcategory: getStringValue(current.subcategory),
knowledge: getStringValue(current.knowledge),
made_sla: getStringValue(current.made_sla),
major_incident: getStringValue(current.major_incident)
};
for (var key in incidentEvent.additionalContext) {
if (incidentEvent.additionalContext[key] === null) {
delete incidentEvent.additionalContext[key];
}
}
gs.info(JSON.stringify(incidentEvent, null, 2)); // Pretty print for logging only
if (WEBHOOK_CONFIG.webhookUrl && WEBHOOK_CONFIG.webhookSecret) {
callWebhook(incidentEvent, WEBHOOK_CONFIG);
} else {
gs.info('Webhook not configured.');
}
})(current, previous);
```
**기능 공급자** 페이지에서 ServiceNow 연결을 등록하기로 선택한 경우 이제 ServiceNow 인시던트 티켓을 조사하려는 DevOps 에이전트 공간으로 이동하여 기능 → 통신을 선택한 다음 기능 공급자 페이지에 등록한 ServiceNow 인스턴스를 등록해야 합니다. 이제 모든 것을 설정해야 하며 호출자가 “문제 관리자”( AWS DevOps OAuth 클라이언트에 부여한 권한을 모방하기 위해)로 설정된 모든 인시던트는 구성된 DevOps 에이전트 스페이스에서 인시던트 대응 조사를 트리거합니다. ServiceNow에서 새 인시던트를 생성하고 인시던트의 발신자 필드를 “문제 관리자”로 설정하여 이를 테스트할 수 있습니다.
![\[alt text not found\]](http://docs.aws.amazon.com/ko_kr/devopsagent/latest/userguide/images/4c7d24a85f88.png)
### ServiceNow 티켓 업데이트
트리거된 모든 인시던트 대응 조사 중에 DevOps 에이전트는 주요 조사 결과, 근본 원인 분석 및 완화 계획에 대한 업데이트를 원래 티켓에 제공합니다. 에이전트 조사 결과는 인시던트의 설명에 게시되며, 현재는 유형 , `finding`, `cause``investigation_summary``mitigation_summary`, 및 조사 상태 업데이트(예: `AWS DevOps Agent started/finished its investigation`)의 에이전트 레코드만 게시합니다.
## 티켓 라우팅 및 오케스트레이션 예제
### 시나리오: DevOps 에이전트 스페이스로 전송되는 인시던트 필터링
이는 간단한 시나리오이지만 인시던트 소스를 추적하기 위해 ServiceNow에서 필드를 생성하려면 ServiceNow에서 일부 구성이 필요합니다. 이 예제에서는 SNOW 양식 빌더를 사용하여 새 소스(u\$1source) 필드를 생성합니다. 이렇게 하면 인시던트 소스를 추적하고 이를 사용하여 특정 소스에서 DevOps 에이전트 스페이스로 요청을 라우팅할 수 있습니다. 라우팅은 Service Now Business 규칙을 생성하고 실행 시기 탭에서 “시기” 트리거 및 “조건 필터링”을 설정하여 수행됩니다. 이 예제에서 필터 조건은 다음과 같이 설정됩니다.
![\[alt text not found\]](http://docs.aws.amazon.com/ko_kr/devopsagent/latest/userguide/images/fac7a186beee.png)
### 시나리오: 여러 DevOps 에이전트 스페이스에서 인시던트 라우팅
이 예제는 긴급성이 , 범주가 `1`, `Software` 서비스가 인 경우 DevOps 에이전트 스페이스 B에서 조사를 트리거하고 서비스가 `AWS`, `AWS`소스가 인 경우 DevOps 에이전트 스페이스 A에서 조사를 트리거하는 방법을 보여줍니다`Dynatrace`.
이 시나리오는 두 가지 방법으로 수행할 수 있습니다. 이 비즈니스 로직을 포함하도록 웹후크 스크립트 자체를 업데이트할 수 있습니다. 이 시나리오에서는 투명성을 높이고 디버깅을 간소화하기 위해 ServiceNow 비즈니스 규칙을 사용하여 이를 수행하는 방법을 보여줍니다. 라우팅은 Service Now Business 규칙 2개를 생성하여 수행됩니다.
+ ServiceNow에서 DevOps 에이전트 공간 A에 대한 비즈니스 규칙을 생성하고 조건 빌더를 사용하여 지정된 조건에 따라 이벤트만 전송하는 조건을 생성합니다.
![\[alt text not found\]](http://docs.aws.amazon.com/ko_kr/devopsagent/latest/userguide/images/bca2f3928bf0.png)
+ 그런 다음 ServiceNow for AgentSpace B에서 서비스가 AWS 이고 소스가 Dynatrace인 경우에만 비즈니스 규칙이 트리거되는 다른 비즈니스 규칙을 생성합니다.
![\[alt text not found\]](http://docs.aws.amazon.com/ko_kr/devopsagent/latest/userguide/images/bc29e4db1a76.png)
이제 지정된 조건과 일치하는 새 인시던트를 생성하면 DevOps 에이전트 스페이스 A 또는 DevOps 에이전트 스페이스 B에 대한 조사를 트리거하여 인시던트 라우팅을 세밀하게 제어할 수 있습니다.
# Slack 연결
선택한 Slack 채널을 인시던트 대응 조사 주요 조사 결과, 근본 원인 분석 및 생성된 완화 계획으로 업데이트하도록 AWS DevOps 에이전트를 구성할 수 있습니다.
## 시작하기 전 준비 사항
Slack을 에이전트 스페이스에 추가하려면 먼저 DevOps 에이전트에 등록해야 합니다. Slack과 AWS DevOps 에이전트를 통합하려면 다음 요구 사항을 충족해야 합니다.
+ 타사 애플리케이션을 설치하고 승인할 수 있는 기능을 갖춘 Slack 워크스페이스에 액세스할 수 있습니다.
+ AWS DevOps 에이전트가 알림을 보낼 Slack 채널을 식별했습니다.
## Slack과 AWS DevOps 에이전트 통합 등록
![\[alt text not found\]](http://docs.aws.amazon.com/ko_kr/devopsagent/latest/userguide/images/4034f56fad96.png)
1. AWS DevOps 에이전트 콘솔의 **기능 공급자** 페이지에서 **통신** 아래의 **사용 가능한** 공급자 섹션에서 **Slack**을 찾아 **등록**을 클릭합니다.
1. **등록** 버튼을 선택합니다.
1. 워크스페이스에 대한 AWS DevOps 에이전트 애플리케이션을 승인하기 위해 Slack으로 리디렉션됩니다.
1. Slack 권한 부여 페이지에서 조직 수준이 아닌 워크스페이스에 직접를 설치합니다.
1. 드롭다운에서 워크스페이스를 선택합니다. 엔터프라이즈 그리드를 선택하지 마십시오.
1. 조직에 필요한 워크스페이스별로를 설치합니다.
1. 요청된 범위를 검토하고 **허용**을 클릭하여 통합을 승인합니다.
1. 권한 부여 후 AWS DevOps 에이전트 콘솔로 돌아갑니다.
## Slack을 DevOps 에이전트 스페이스(들)와 연결
DevOps 에이전트 스페이스에 Slack을 등록한 후 DevOps 에이전트 스페이스(들)와 연결할 수 있습니다.
1. 구성된 AgentSpace 내의 **기능** 탭에서 **통신** > **Slack**으로 이동합니다.
1. **Slack 추가**를 선택합니다.
1. 채널 ID를 입력합니다.
1. **생성을** 선택하여 Slack 구성을 완료합니다.
**참고**
** 에이전트의 봇 사용자는 메시지를 게시하기 전에 프라이빗 채널에 추가해야 합니다.
**중요**
** Slack 앱을 제거하면 Slack 앱을 다시 설치할 수 없게 될 수 있습니다. Slack 앱을 제거하지 마십시오.
# Webhook를 통해 DevOps 에이전트 호출
Webhook를 사용하면 외부 시스템이 자동으로 AWS DevOps 에이전트 조사를 트리거할 수 있습니다. 이를 통해 티켓팅 시스템, 모니터링 도구 및 인시던트 발생 시 HTTP 요청을 보낼 수 있는 기타 플랫폼과 통합할 수 있습니다.
## 사전 조건
웹후크 액세스를 구성하기 전에 다음을 갖추어야 합니다.
+ in AWS DevOps 에이전트에 구성된 에이전트 공간
+ AWS DevOps 에이전트 콘솔에 대한 액세스
+ Webhook 요청을 전송할 외부 시스템
## Webhook 유형
AWS DevOps Agent는 다음과 같은 유형의 웹후크를 지원합니다.
+ **통합별 웹후크 -** Dynatrace, Splunk, Datadog, New Relic, ServiceNow 또는 Slack과 같은 타사 통합을 구성할 때 자동으로 생성됩니다. 이러한 웹후크는 특정 통합과 연결되며 통합 유형에 따라 결정되는 인증 방법을 사용합니다.
+ **일반 웹후크 **- 특정 통합에서 다루지 않는 소스에서 조사를 트리거하기 위해 수동으로 생성할 수 있습니다. 일반 웹후크는 현재 **HMAC** 인증을 사용합니다(베어러 토큰은 현재 사용할 수 없음).
+ **Grafana 알림 웹후크** - Grafana는 웹후크 연락 지점을 통해 AWS DevOps 에이전트에 직접 알림 알림을 보낼 수 있습니다. 사용자 지정 알림 템플릿을 포함한 설정 지침은 [Grafana 연결을](connecting-telemetry-sources-connecting-grafana.md) 참조하세요.
## Webhook 인증 방법
웹후크의 인증 방법은 연결된 통합에 따라 다릅니다.
**HMAC 인증** - 다음에서 사용:
+ Dynatrace 통합 웹후크
+ 일반 웹후크(특정 타사 통합에 연결되지 않음)
**베어러 토큰 인증** - 다음에서 사용:
+ Splunk 통합 웹후크
+ Datadog 통합 웹후크
+ New Relic 통합 웹후크
+ ServiceNow 통합 웹후크
+ Slack 통합 웹후크
## 웹후크 액세스 구성
### 1단계: Webhook 구성으로 이동
1. AWS Management Console에 로그인하고 AWS DevOps 에이전트 콘솔로 이동합니다.
1. 에이전트 스페이스 선택
1. **기능** 탭으로 이동
1. **Webhook** 섹션에서 **구성을** 클릭합니다.
### 2단계: Webhook 자격 증명 생성
**통합별 웹후크의 경우:**
타사 통합 구성을 완료하면 Webhook가 자동으로 생성됩니다. Webhook 엔드포인트 URL 및 자격 증명은 통합 설정 프로세스가 끝날 때 제공됩니다.
**일반 웹후크의 경우:**
1. **웹후크 생성을 클릭합니다.**
1. 시스템에서 HMAC 키 페어를 생성합니다.
1. 생성된 키와 보안 암호를 안전하게 저장합니다. 다시 검색할 수 없습니다.
1. 제공된 웹후크 엔드포인트 URL 복사
### 3단계: 외부 시스템 구성
Webhook 엔드포인트 URL 및 자격 증명을 사용하여 외부 시스템이 AWS DevOps Agent에 요청을 보내도록 구성합니다. 특정 구성 단계는 외부 시스템에 따라 다릅니다.
## Webhook 자격 증명 관리
**자격 증명 제거** - 웹후크 자격 증명을 삭제하려면 웹후크 구성 섹션으로 이동하여 **제거**를 클릭합니다. 자격 증명을 제거한 후에는 새 자격 증명을 생성할 때까지 웹후크 엔드포인트가 더 이상 요청을 수락하지 않습니다.
**자격 증명 재생성** - 새 자격 증명을 생성하려면 먼저 기존 자격 증명을 제거한 다음 새 키 페어 또는 토큰을 생성합니다.
## Webhook 사용
### Webhook 요청 형식
조사를 트리거하려면 외부 시스템이 HTTP POST 요청을 웹후크 엔드포인트 URL로 보내야 합니다.
**버전 1(HMAC 인증)의 경우:**
헤더:
+ `Content-Type: application/json`
+ `x-amzn-event-signature: `
+ `x-amzn-event-timestamp: <+%Y-%m-%dT%H:%M:%S.000Z>`
HMAC 서명은 SHA-256을 사용하여 보안 키로 요청 본문에 서명하여 생성됩니다.
**버전 2(베어러 토큰 인증)의 경우:**
헤더:
+ `Content-Type: application/json`
+ `Authorization: Bearer `
**요청 본문:**
요청 본문에는 인시던트에 대한 정보가 포함되어야 합니다.
```
json
{
"title": "Incident title",
"severity": "high",
"affectedResources": ["resource-id-1", "resource-id-2"],
"timestamp": "2025-11-23T18:00:00Z",
"description": "Detailed incident description",
"data": {
"metadata": {
"region": "us-east-1",
"environment": "production"
}
}
}
```
### 예제 코드
**버전 1(HMAC 인증) - JavaScript:**
```
const crypto = require('crypto');
// Webhook configuration
const webhookUrl = 'https://your-webhook-endpoint.amazonaws.com/invoke';
const webhookSecret = 'your-webhook-secret-key';
// Incident data
const incidentData = {
eventType: 'incident',
incidentId: 'incident-123',
action: 'created',
priority: "HIGH",
title: 'High CPU usage on production server',
description: 'High CPU usage on production server host ABC in AWS account 1234 region us-east-1',
timestamp: new Date().toISOString(),
service: 'MyTestService',
data: {
metadata: {
region: 'us-east-1',
environment: 'production'
}
}
};
// Convert data to JSON string
const payload = JSON.stringify(incidentData);
const timestamp = new Date().toISOString();
const hmac = crypto.createHmac("sha256", webhookSecret);
hmac.update(`${timestamp}:${payload}`, "utf8");
const signature = hmac.digest("base64");
// Send the request
fetch(webhookUrl, {
method: 'POST',
headers: {
'Content-Type': 'application/json',
'x-amzn-event-timestamp': timestamp,
'x-amzn-event-signature': signature
},
body: payload
})
.then(res => {
console.log(`Status Code: ${res.status}`);
return res.text();
})
.then(data => {
console.log('Response:', data);
})
.catch(error => {
console.error('Error:', error);
});
```
**버전 1(HMAC 인증) - cURL:**
```
#!/bin/bash
# Configuration
WEBHOOK_URL="https://event-ai.us-east-1.api.aws/webhook/generic/YOUR_WEBHOOK_ID"
SECRET="YOUR_WEBHOOK_SECRET"
# Create payload
TIMESTAMP=$(date -u +%Y-%m-%dT%H:%M:%S.000Z)
INCIDENT_ID="test-alert-$(date +%s)"
PAYLOAD=$(cat <
### 200을 받지 못한 경우
200과 웹후크와 같은 메시지가 수신되면 인증이 통과되었고 시스템에서 확인 및 처리할 수 있도록 메시지가 대기열에 있음을 나타냅니다. 200은 얻지 못하지만 4xx는 인증 또는 헤더에 문제가 있을 가능성이 높습니다. 인증을 디버깅하는 데 도움이 되도록 curl 옵션을 사용하여 수동으로 전송해 보세요.
### 200을 수신했지만 조사가 시작되지 않는 경우
잘못된 페이로드가 원인일 수 있습니다.
1. 타임스탬프와 인시던트 ID가 모두 업데이트되고 고유한지 확인합니다. 중복 메시지는 중복 제거됩니다.
1. 메시지가 유효한 JSON인지 확인합니다.
1. 형식이 올바른지 확인합니다.
### 200을 수신하고 조사가 즉시 취소되는 경우
해당 월의 한도에 도달했을 가능성이 높습니다. 해당하는 경우 AWS 연락처에 문의하여 속도 제한 변경을 요청하십시오.
## 관련 주제
+ [에이전트 스페이스 생성](getting-started-with-aws-devops-agent-creating-an-agent-space.md)
+ [DevOps 에이전트 웹 앱이란 무엇입니까?](about-aws-devops-agent-what-is-a-devops-agent-web-app.md)
+ [DevOps 에이전트 IAM 권한](aws-devops-agent-security-devops-agent-iam-permissions.md)
# Amazon EventBridge와 AWS DevOps 에이전트 통합
조사 및 완화 수명 주기 동안 발생하는 이벤트를 사용하여 이벤트 기반 애플리케이션과 AWS DevOps 에이전트를 통합할 수 있습니다. AWS DevOps 에이전트는 조사 또는 완화 상태가 변경될 때 Amazon EventBridge로 이벤트를 전송합니다. 그런 다음 이러한 이벤트를 기반으로 조치를 취하는 EventBridge 규칙을 생성할 수 있습니다.
예를 들어 다음 작업을 수행하는 규칙을 생성할 수 있습니다.
+ 조사가 완료되면 AWS Lambda 함수를 호출하여 조사 결과를 처리합니다.
+ 조사가 실패하거나 시간이 초과되면 Amazon SNS 알림을 보냅니다.
+ 새 조사가 생성되면 티켓팅 시스템을 업데이트합니다.
+ 완화 작업이 완료되면 AWS Step Functions 워크플로를 시작합니다.
## EventBridge가 AWS DevOps 에이전트 이벤트를 라우팅하는 방법
AWS DevOps Agent는 EventBridge 기본 이벤트 버스로 이벤트를 전송합니다. 그런 다음 EventBridge는 생성한 규칙을 기준으로 이벤트를 평가합니다. 이벤트가 규칙의 이벤트 패턴과 일치하면 EventBridge는 이벤트를 지정된 대상으로 보냅니다.
다음 다이어그램은 EventBridge가 AWS DevOps 에이전트 이벤트를 라우팅하는 방법을 보여줍니다.
![\[alt text not found\]](http://docs.aws.amazon.com/ko_kr/devopsagent/latest/userguide/images/eventbridge-integration-how-it-works.png)
1. AWS DevOps Agent는 조사 또는 완화 수명 주기 상태가 변경될 때 EventBridge 기본 이벤트 버스로 이벤트를 전송합니다.
1. EventBridge는 생성한 규칙을 기준으로 이벤트를 평가합니다.
1. 이벤트가 규칙의 이벤트 패턴과 일치하면 EventBridge는 규칙에 지정된 대상으로 이벤트를 보냅니다.
## AWS DevOps 에이전트 이벤트
AWS DevOps Agent는 다음 이벤트를 EventBridge로 전송합니다. 모든 이벤트는 소스를 사용합니다`aws.aidevops`.
### 지원되는 조사 이벤트
| detail-type | 설명 |
| --- | --- |
| Investigation Created | 에이전트 공간에 조사가 생성되었습니다. |
| Investigation Priority Updated | 조사의 우선 순위가 변경되었습니다. |
| Investigation In Progress | 조사가 활성 분석을 시작했습니다. |
| Investigation Completed | 조사 결과가 성공적으로 완료되었습니다. |
| Investigation Failed | 조사에서 오류가 발생하여 완료할 수 없습니다. |
| Investigation Timed Out | 조사가 최대 허용 기간을 초과했습니다. |
| Investigation Cancelled | 완료 전에 조사가 취소되었습니다. |
| Investigation Pending Triage | 활성 분석이 시작되기 전에 조사가 분류를 기다리고 있습니다. |
| Investigation Linked | 조사가 관련 인시던트 또는 티켓과 연결되었습니다. |
### 지원되는 완화 이벤트
| detail-type | 설명 |
| --- | --- |
| Mitigation In Progress | 완화 작업이 시작되었습니다. |
| Mitigation Completed | 완화 작업이 성공적으로 완료되었습니다. |
| Mitigation Failed | 완화 작업에서 오류가 발생하여 완료할 수 없습니다. |
| Mitigation Timed Out | 완화 작업이 최대 허용 기간을 초과했습니다. |
| Mitigation Cancelled | 완료 전에 완화 작업이 취소되었습니다. |
자세한 필드 설명 및 예제 이벤트는 섹션을 참조하세요[AWS DevOps 에이전트 이벤트 세부 정보 참조](integrating-devops-agent-into-event-driven-applications-using-amazon-eventbridge-devops-agent-events-detail-reference.md).
## AWS DevOps 에이전트 이벤트와 일치하는 이벤트 패턴 생성
EventBridge 규칙은 이벤트 패턴을 사용하여 이벤트를 선택하고 대상으로 라우팅합니다. 이벤트 패턴은 처리하는 이벤트의 구조와 일치합니다. 이벤트 필드를 기반으로 이벤트 패턴을 생성하여 filter AWS DevOps 에이전트 이벤트를 필터링합니다.
다음 예제에서는 일반적인 사용 사례에 대한 이벤트 패턴을 보여줍니다.
**all AWS DevOps 에이전트 이벤트 일치**
다음 이벤트 패턴은 AWS DevOps Agent의 모든 이벤트와 일치합니다.
```
{
"source": ["aws.aidevops"]
}
```
**조사 이벤트만 일치**
다음 이벤트 패턴은 접두사 일치를 사용하여 조사 수명 주기 이벤트만 선택합니다.
```
{
"source": ["aws.aidevops"],
"detail-type": [{"prefix": "Investigation"}]
}
```
**완료 및 실패 이벤트만 일치**
다음 이벤트 패턴은 완료되거나 실패한 조사 및 완화에 대한 이벤트와 일치합니다.
```
{
"source": ["aws.aidevops"],
"detail-type": [
"Investigation Completed",
"Investigation Failed",
"Mitigation Completed",
"Mitigation Failed"
]
}
```
**특정 에이전트 스페이스에 대한 이벤트 일치**
다음 이벤트 패턴은 특정 에이전트 공간의 이벤트와 일치합니다.
```
{
"source": ["aws.aidevops"],
"detail": {
"metadata": {
"agent_space_id": ["your-agent-space-id"]
}
}
}
```
이벤트 패턴에 대한 자세한 내용은 *Amazon EventBridge 사용 설명서*에서 [Amazon EventBridge 이벤트 패턴](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-event-patterns.html)을 참조하세요.
## Amazon EventBridge 권한
AWS DevOps Agent는 EventBridge에 이벤트를 전송하는 데 추가 권한이 필요하지 않습니다. 이벤트는 기본 이벤트 버스로 자동으로 전송됩니다.
EventBridge 규칙에 대해 구성하는 대상에 따라 특정 권한을 추가해야 할 수 있습니다. 대상에 필요한 권한에 대한 자세한 내용은 [Amazon EventBridge 사용 설명서의 Amazon EventBridge에 대한 리소스 기반 정책 사용을](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-use-resource-based.html) 참조하세요. * EventBridge *
## 추가 EventBridge 리소스
EventBridge 개념 및 구성에 대한 자세한 내용은 *Amazon EventBridge 사용 설명서*의 다음 주제를 참조하세요.
+ [EventBridge 이벤트 버스](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-event-bus.html)
+ [EventBridge 이벤트](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-events.html)
+ [EventBridge 이벤트 패턴](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-event-patterns.html)
+ [EventBridge 규칙](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-rules.html)
+ [EventBridge 대상](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-targets.html)
# AWS DevOps 에이전트 이벤트 세부 정보 참조
AWS 서비스의 이벤트에는 , , `source`, `detail-type``account``region`, 등 공통 메타데이터 필드가 있습니다`time`. 이러한 이벤트에는 서비스와 관련된 데이터가 있는 `detail` 필드도 포함됩니다. For AWS DevOps 에이전트 이벤트의 경우 `source`는 항상 `aws.aidevops` 이고는 특정 이벤트를 `detail-type` 식별합니다.
## 조사 이벤트
다음 `detail-type` 값은 조사 이벤트를 식별합니다.
+ `Investigation Created`
+ `Investigation Priority Updated`
+ `Investigation In Progress`
+ `Investigation Completed`
+ `Investigation Failed`
+ `Investigation Timed Out`
+ `Investigation Cancelled`
+ `Investigation Pending Triage`
+ `Investigation Linked`
`source` 및 `detail-type` 필드는 AWS DevOps 에이전트 이벤트에 대한 특정 값을 포함하므로 아래에 포함되어 있습니다. 모든 이벤트에 포함된 다른 메타데이터 필드의 정의는 *Amazon EventBridge 이벤트 참조*의 [이벤트 구조](https://docs.aws.amazon.com/eventbridge/latest/ref/overiew-event-structure.html)를 참조하세요.
다음은 조사 이벤트에 대한 JSON 구조입니다.
```
{
. . .,
"detail-type" : "string",
"source" : "aws.aidevops",
. . .,
"detail" : {
"version" : "string",
"metadata" : {
"agent_space_id" : "string",
"task_id" : "string",
"execution_id" : "string"
},
"data" : {
"task_type" : "string",
"priority" : "string",
"status" : "string",
"created_at" : "string",
"updated_at" : "string",
"summary_record_id" : "string"
}
}
}
```
**`detail-type`** 이벤트 유형을 식별합니다. 조사 이벤트의 경우 이는 이전에 나열된 이벤트 이름 중 하나입니다.
**`source`** 이벤트를 생성한 서비스를 식별합니다. For AWS DevOps 에이전트 이벤트의 경우이 값은 입니다`aws.aidevops`.
**`detail`** 이벤트별 데이터가 포함된 JSON 객체입니다. `detail` 객체에는 다음 필드가 포함됩니다.
+ `version` (문자열) - 이벤트 세부 정보의 스키마 버전입니다. 현재 입니다`1.0.0`.
+ `metadata.agent_space_id` (문자열) - 이벤트가 시작된 에이전트 공간의 고유 식별자입니다.
+ `metadata.task_id` (문자열) - 작업의 고유 식별자입니다.
+ `metadata.execution_id` (문자열) - 실행 실행의 고유 식별자입니다. 실행이 조사에 할당되었을 때 표시됩니다.
+ `data.task_type` (문자열) - 작업 유형입니다. 값: `INVESTIGATION`.
+ `data.priority` (문자열) - 우선 순위 수준입니다. 값: `CRITICAL`, `HIGH`, `MEDIUM`, `LOW`, `MINIMAL`.
+ `data.status` (문자열) - 현재 상태입니다. 값: `PENDING_START`, `IN_PROGRESS`, `COMPLETED`, `FAILED`, `TIMED_OUT`, `CANCELLED`, `PENDING_TRIAGE`, `LINKED`.
+ `data.created_at` (문자열) - 작업이 생성되었을 때 ISO 8601 타임스탬프입니다.
+ `data.updated_at` (문자열) - 작업이 마지막으로 업데이트된 시점의 ISO 8601 타임스탬프입니다.
+ `data.summary_record_id` (문자열) - 조사 결과가 포함된 요약 레코드의 식별자입니다. 완료된 조사에 대한 요약이 생성될 때 포함됩니다. 이 식별자를 사용하여 레코드 유형이 인 저널 레코드를 조회하여 AWS DevOps 에이전트 API를 통해 요약 콘텐츠를 검색할 수 있습니다`investigation_summary_md`.
**예: 조사 완료 이벤트**
```
{
"version": "0",
"id": "12345678-1234-1234-1234-123456789015",
"detail-type": "Investigation Completed",
"source": "aws.aidevops",
"account": "123456789012",
"time": "2026-03-12T18:10:00Z",
"region": "us-east-1",
"resources": [
"arn:aws:aidevops:us-east-1:123456789012:agentspace/8f6187a7-0388-4926-8217-3a0fe32f757c"
],
"detail": {
"version": "1.0.0",
"metadata": {
"agent_space_id": "8f6187a7-0388-4926-8217-3a0fe32f757c",
"task_id": "a1b2c3d4-5678-90ab-cdef-example11111",
"execution_id": "b2c3d4e5-6789-01ab-cdef-example22222"
},
"data": {
"task_type": "INVESTIGATION",
"priority": "CRITICAL",
"status": "COMPLETED",
"created_at": "2026-03-12T18:00:00Z",
"updated_at": "2026-03-12T18:10:00Z",
"summary_record_id": "d4e5f6g7-6789-01ab-cdef-example44444"
}
}
}
```
**예: 조사 실패 이벤트**
```
{
"version": "0",
"id": "12345678-1234-1234-1234-123456789016",
"detail-type": "Investigation Failed",
"source": "aws.aidevops",
"account": "123456789012",
"time": "2026-03-12T18:10:00Z",
"region": "us-east-1",
"resources": [
"arn:aws:aidevops:us-east-1:123456789012:agentspace/8f6187a7-0388-4926-8217-3a0fe32f757c"
],
"detail": {
"version": "1.0.0",
"metadata": {
"agent_space_id": "8f6187a7-0388-4926-8217-3a0fe32f757c",
"task_id": "a1b2c3d4-5678-90ab-cdef-example11111",
"execution_id": "b2c3d4e5-6789-01ab-cdef-example22222"
},
"data": {
"task_type": "INVESTIGATION",
"priority": "CRITICAL",
"status": "FAILED",
"created_at": "2026-03-12T18:00:00Z",
"updated_at": "2026-03-12T18:10:00Z"
}
}
}
```
## 완화 이벤트
다음 `detail-type` 값은 완화 이벤트를 식별합니다.
+ `Mitigation In Progress`
+ `Mitigation Completed`
+ `Mitigation Failed`
+ `Mitigation Timed Out`
+ `Mitigation Cancelled`
`source` 및 `detail-type` 필드는 AWS DevOps 에이전트 이벤트에 대한 특정 값을 포함하므로 아래에 포함되어 있습니다. 모든 이벤트에 포함된 다른 메타데이터 필드의 정의는 *Amazon EventBridge 이벤트 참조*의 [이벤트 구조](https://docs.aws.amazon.com/eventbridge/latest/ref/overiew-event-structure.html)를 참조하세요.
다음은 완화 이벤트에 대한 JSON 구조입니다.
```
{
. . .,
"detail-type" : "string",
"source" : "aws.aidevops",
. . .,
"detail" : {
"version" : "string",
"metadata" : {
"agent_space_id" : "string",
"task_id" : "string",
"execution_id" : "string"
},
"data" : {
"task_type" : "string",
"priority" : "string",
"status" : "string",
"created_at" : "string",
"updated_at" : "string",
"summary_record_id" : "string"
}
}
}
```
**`detail-type`** 이벤트 유형을 식별합니다. 완화 이벤트의 경우 이는 이전에 나열된 이벤트 이름 중 하나입니다.
**`source`** 이벤트를 생성한 서비스를 식별합니다. For AWS DevOps 에이전트 이벤트의 경우이 값은 입니다`aws.aidevops`.
**`detail`** 이벤트별 데이터가 포함된 JSON 객체입니다. `detail` 객체에는 다음 필드가 포함됩니다.
+ `version` (문자열) - 이벤트 세부 정보의 스키마 버전입니다. 현재 입니다`1.0.0`.
+ `metadata.agent_space_id` (문자열) - 이벤트가 시작된 에이전트 공간의 고유 식별자입니다.
+ `metadata.task_id` (문자열) - 작업의 고유 식별자입니다.
+ `metadata.execution_id` (문자열) - 실행 실행의 고유 식별자입니다. 실행이 완화에 할당되었을 때 표시됩니다.
+ `data.task_type` (문자열) - 작업 유형입니다. 값: `INVESTIGATION`.
+ `data.priority` (문자열) - 우선 순위 수준입니다. 값: `CRITICAL`, `HIGH`, `MEDIUM`, `LOW`, `MINIMAL`.
+ `data.status` (문자열) - 현재 상태입니다. 값: `IN_PROGRESS`, `COMPLETED`, `FAILED`, `TIMED_OUT`, `CANCELLED`.
+ `data.created_at` (문자열) - 작업이 생성되었을 때 ISO 8601 타임스탬프입니다.
+ `data.updated_at` (문자열) - 작업이 마지막으로 업데이트된 시점의 ISO 8601 타임스탬프입니다.
+ `data.summary_record_id` (문자열) - 완화 조사 결과를 포함하는 요약 레코드의 식별자입니다. 완료된 완화를 위한 요약이 생성될 때 포함됩니다. 이 식별자를 사용하여 레코드 유형이 인 저널 레코드를 조회하여 AWS DevOps 에이전트 API를 통해 요약 콘텐츠를 검색할 수 있습니다`mitigation_summary_md`.
**예: 완화 완료 이벤트**
```
{
"version": "0",
"id": "12345678-1234-1234-1234-12345678901c",
"detail-type": "Mitigation Completed",
"source": "aws.aidevops",
"account": "123456789012",
"time": "2026-03-12T18:20:00Z",
"region": "us-east-1",
"resources": [
"arn:aws:aidevops:us-east-1:123456789012:agentspace/8f6187a7-0388-4926-8217-3a0fe32f757c"
],
"detail": {
"version": "1.0.0",
"metadata": {
"agent_space_id": "8f6187a7-0388-4926-8217-3a0fe32f757c",
"task_id": "a1b2c3d4-5678-90ab-cdef-example11111",
"execution_id": "c3d4e5f6-7890-12ab-cdef-example33333"
},
"data": {
"task_type": "INVESTIGATION",
"priority": "CRITICAL",
"status": "COMPLETED",
"created_at": "2026-03-12T18:00:00Z",
"updated_at": "2026-03-12T18:20:00Z",
"summary_record_id": "e5f6g7h8-7890-12ab-cdef-example55555"
}
}
}
```
**예: 완화 실패 이벤트**
```
{
"version": "0",
"id": "12345678-1234-1234-1234-12345678901d",
"detail-type": "Mitigation Failed",
"source": "aws.aidevops",
"account": "123456789012",
"time": "2026-03-12T18:20:00Z",
"region": "us-east-1",
"resources": [
"arn:aws:aidevops:us-east-1:123456789012:agentspace/8f6187a7-0388-4926-8217-3a0fe32f757c"
],
"detail": {
"version": "1.0.0",
"metadata": {
"agent_space_id": "8f6187a7-0388-4926-8217-3a0fe32f757c",
"task_id": "a1b2c3d4-5678-90ab-cdef-example11111",
"execution_id": "c3d4e5f6-7890-12ab-cdef-example33333"
},
"data": {
"task_type": "INVESTIGATION",
"priority": "CRITICAL",
"status": "FAILED",
"created_at": "2026-03-12T18:00:00Z",
"updated_at": "2026-03-12T18:20:00Z"
}
}
}
```
# 판매 로그 및 지표
판매된 Amazon CloudWatch 지표 및 로그를 사용하여 에이전트 공간 및 서비스 작업을 모니터링할 수 있습니다. 이 주제에서는 AWS DevOps 에이전트가 계정에 자동으로 게시하는 CloudWatch 지표와 원하는 대상으로 전송하도록 구성할 수 있는 판매 로그에 대해 설명합니다.
## 판매된 CloudWatch 지표
AWS DevOps Agent는 계정의 Amazon CloudWatch에 지표를 자동으로 게시합니다. 이러한 지표는 구성 없이 사용할 수 있습니다. 이를 사용하여 사용량을 모니터링하고, 운영 활동을 추적하고, 경보를 생성할 수 있습니다.
### 서비스 연결 역할
Amazon CloudWatch 지표가이 서비스에 대한 계정에 게시되도록 하기 위해 AWS DevOps 에이전트는 [서비스 연결 역할](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create-service-linked-role.html) **AWSServiceRoleForAIDevOps** 서비스 연결 역할을 자동으로 생성합니다. API를 호출하는 IAM 역할에 적절한 권한이 없는 경우 InvalidParameterException과 함께 리소스 생성이 실패합니다.
**중요**
2026년 3월 13일 이전에 AgentSpace를 생성한 고객은 **AWSServiceRoleForAIDevOps** 서비스 연결 역할을 수동으로 생성하여 계정에 AWS DevOps 에이전트에 대한 CloudWatch 지표를 게시해야 합니다.
### 서비스 연결 역할 수동 생성(기존 고객의 경우)
다음 중 하나를 수행하세요.
+ IAM 콘솔에서 **AWS DevOps 에이전트** 서비스 아래에 **AWSServiceRoleForAIDevOps** 역할을 생성합니다.
+ AWS CLI에서 다음 명령을 실행합니다.
```
aws iam create-service-linked-role --aws-service-name aidevops.amazonaws.com
```
### 네임스페이스
모든 지표는 `AWS/AIDevOps` 네임스페이스 아래에 게시됩니다.
### 측정 기준
모든 지표에는 다음 차원이 포함됩니다.
| 차원 | 설명 |
| --- | --- |
| AgentSpaceUUID | 에이전트 공간의 고유 식별자입니다. 계정의 모든 에이전트 공간에서 지표를 집계하려면 CloudWatch 수학 표현식을 사용하거나 차원 필터를 생략합니다. |
### 지표 참조
| 지표 이름 | 설명 | 단위 | 게시 빈도 | 유용한 통계 |
| --- | --- | --- | --- | --- |
| ConsumedChatRequests | 에이전트 공간이 사용한 채팅 요청 수입니다. 계정의 총 개수를 가져오려면 모든 SUM 차원에서 통계를 사용합니다AgentSpaceUUID. | 개수 | 5분마다 | 합계, 평균 |
| ConsumedInvestigationTime | 에이전트 공간에서 조사를 실행하는 데 소요된 시간입니다. | 초 | 5분마다 | 합계, 평균, 최대 |
| ConsumedEvaluationTime | 에이전트 공간에서 평가를 실행하는 데 소요된 시간입니다. | 초 | 5분마다 | 합계, 평균, 최대 |
| TopologyCompletionCount | 토폴로지 처리 완료 횟수입니다. AWS DevOps Agent는 온보딩 중 초기 생성부터 수동 업데이트 또는 예약된 일일 새로 고침까지 토폴로지 처리가 완료되면이 지표를 내보냅니다. | 개수 | 이벤트 기반(완료할 때마다 발생) | 합계, SampleCount |
### CloudWatch 콘솔에서 지표 보기
1. [CloudWatch 콘솔](https://console.aws.amazon.com/cloudwatch/)을 엽니다.
1. 탐색 창에서 **지표**를 선택한 다음 **모든 지표**를 선택합니다.
1. **AWS/AIDevOps** 네임스페이스를 선택합니다.
1. **에이전트 공간에 대한 지표를 보려면 AgentSpace별**을 선택합니다.
**참고**
** 이러한 지표에 CloudWatch 경보를 생성하여 사용량이 임계값을 초과할 때 알림을 받을 수 있습니다. 예를 들어에서 경보를 생성`ConsumedChatRequests`하여 채팅 요청 소비를 모니터링합니다.
## 사전 조건
로그 전송을 구성하기 전에 다음이 있는지 확인합니다.
+ AWS DevOps 에이전트 콘솔에 액세스할 수 있는 활성 AWS 계정
+ CloudWatch Logs 전송 APIs에 대한 권한이 있는 IAM 보안 주체
+ (선택 사항) 로그 대상으로 사용할 계획인 경우 Amazon S3 버킷 또는 Amazon Data Firehose 전송 스트림
## 벤딩 로그
AWS DevOps Agent는 에이전트 스페이스 및 서비스 등록이 처리하는 이벤트에 대한 가시성을 제공하는 판매 로그를 지원합니다. 판매 로그는 Amazon CloudWatch Logs 인프라를 사용하여 원하는 대상으로 로그를 전송합니다.
판매 로그를 사용하려면 전송 대상을 구성해야 합니다. 지원되는 대상은 다음과 같습니다.
+ **Amazon CloudWatch Logs** – 계정의 로그 그룹
+ **Amazon S3** - 계정의 S3 버킷
+ **Amazon Data Firehose** – 계정의 Firehose 전송 스트림
### 지원되는 로그 유형
단일 로그 유형이 지원됩니다`APPLICATION_LOGS`. 이 로그 유형은 서비스가 내보내는 모든 운영 이벤트를 포함합니다.
### 로그 이벤트 유형
다음 표에는 AWS DevOps 에이전트가 로깅하는 이벤트가 요약되어 있습니다.
| 이벤트 | 설명 | 로그 수준 |
| --- | --- | --- |
| 에이전트 인바운드 이벤트 수신 | 에이전트는 통합 소스에 의해 트리거되고 인바운드 이벤트(예: PagerDuty 인시던트 이벤트)를 수신합니다. | INFO |
| 에이전트 인바운드 이벤트 삭제됨 | 인바운드 이벤트는 에이전트가 처리하기 전에 삭제되었습니다. 로그에는 이유(예: 잘못된 형식의 데이터)가 포함됩니다. | 미정 |
| 에이전트 아웃바운드 통신 실패 | 타사 통합에 대한 아웃바운드 통신이 실패했습니다. 로그에는 작업 ID와 대상 식별자(예: 인증 오류)가 포함됩니다. | 미정 |
| 대기 중인 토폴로지 생성 | 토폴로지 생성 작업이 처리를 위해 대기열에 추가되었습니다. | INFO |
| 토폴로지 생성 시작됨 | 토폴로지 생성 작업이 처리를 시작했습니다. | INFO |
| 토폴로지 생성 완료 | 토폴로지 생성 작업 처리가 완료되었습니다. 이 이벤트는 초기 생성, 업데이트 및 일일 새로 고침에 적용됩니다. | INFO |
| 리소스 검색 실패 | 토폴로지 생성 중 리소스 검색에 오류가 발생했습니다. | 오류 |
| 서비스 등록 실패 | 서비스 등록에서 복구할 수 없는 실패 발생 | 오류 |
| Webhook 검증 실패 | Devops 에이전트가 수신한 웹후크가 예상 스키마와 일치하지 않는 경우 | 오류 |
| 연결 검증 상태 업데이트 | 에이전트 스페이스 연결(일반적인 기본/보조 계정)이 유효에서 유효하지 않음으로 바뀌고 그 반대의 경우도 마찬가지입니다(예: 잘못된 역할로 인해 발생하며 서비스에서 수임할 수 없음). | 오류/정보 |
### 권한
AWS DevOps Agent는 [CloudWatch 벤딩 로그(V2 권한)](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AWS-vended-logs-permissions-V2.html)를 사용하여 로그를 전송합니다. 로그 전송을 설정하려면 전송을 구성하는 IAM 역할에 다음 권한이 있어야 합니다.
+ `aidevops:AllowVendedLogDeliveryForResource` - 에이전트 스페이스 리소스에 대한 로그 전송을 허용하는 데 필요합니다.
+ CloudWatch Logs 전송 APIs(`logs:PutDeliverySource`, `logs:PutDeliveryDestination``logs:CreateDelivery`, 및 관련 작업)에 대한 권한입니다.
+ 선택한 전송 대상과 관련된 권한입니다.
각 대상 유형에 필요한 전체 IAM 정책은 *Amazon CloudWatch Logs 사용 설명서*의 다음 주제를 참조하세요.
+ [CloudWatch Logs로 전송된 로그](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AWS-logs-infrastructure-V2-CloudWatchLogs.html)
+ [Amazon S3로 보낸 로그](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AWS-logs-infrastructure-V2-S3.html)
+ [Firehose로 전송된 로그](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AWS-logs-infrastructure-V2-Firehose.html)
### 로그 전송 구성(콘솔)
AWS DevOps Agent는 AWS 관리 콘솔에서 로그 전송을 구성하기 위한 두 위치를 제공합니다.
+ **서비스 등록 설정 페이지** - 서비스 수준 이벤트에 대한 로그 전송을 구성합니다. 이러한 로그는 서비스 ARN(`arn:aws:aidevops:::service/`)을 리소스로 사용합니다.
+ **에이전트 스페이스 페이지** - 개별 에이전트 스페이스와 관련된 이벤트에 대한 로그 전송을 구성합니다. 이러한 로그는 에이전트 공간 ARN(`arn:aws:aidevops:::agentspace/`)을 리소스로 사용합니다.
#### 서비스 등록에 대한 로그 전송을 구성하려면
1. AWS 관리 콘솔에서 AWS DevOps 에이전트 콘솔을 엽니다.
1. 탐색 창에서 **설정**을 선택합니다.
1. **기능 공급자** **>** **로그** 탭에서 **구성을** 선택합니다.
1. **대상 유형**에서 다음 중 하나를 선택합니다.
1. **CloudWatch Logs** - 로그 그룹을 선택하거나 생성합니다.
1. **Amazon S3** - S3 버킷 ARN을 입력합니다.
1. **Amazon Data Firehose** - Firehose 전송 스트림을 선택하거나 생성합니다.
1. **추가 설정** - *선택 사항*의 경우 다음 옵션을 지정할 수 있습니다.
1. **필드 선택**에서 대상으로 전송할 로그 필드 이름을 선택합니다. [액세스 로그 필드](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/standard-logs-reference.html#BasicDistributionFileFormat) 및 [실시간 액세스 로그 필드](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/standard-logging.html#standard-logging-real-time-log-selection)의 하위 집합을 선택할 수 있습니다.
1. (Amazon S3만 해당) **파티셔닝**에서 로그 파일 데이터를 파티셔닝할 경로를 지정합니다.
1. (Amazon S3만 해당) **Hive 호환 파일 형식**에서 확인란을 선택하여 Hive 호환 S3 경로를 사용할 수 있습니다. 이렇게 하면 Hive 호환 도구에 새 데이터를 쉽게 로드할 수 있습니다.
1. **출력 형식**에서 원하는 형식을 지정합니다.
1. **필드 구분 기호**에서 로그 필드를 구분하는 방법을 지정합니다.
1. **저장**을 선택합니다.
1. 전송 상태가 **활성**으로 표시되는지 확인합니다.
#### 에이전트 공간에 대한 로그 전송을 구성하려면
1. AWS 관리 콘솔에서 AWS DevOps 에이전트 콘솔을 엽니다.
1. 구성할 에이전트 공간을 선택합니다.
1. **구성** 탭에서 **구성을** 선택합니다.
1. **[대상 유형](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AWS-logs-and-resource-policy.html#AWS-vended-logs-permissions-V2:~:text=sts%3AAssumeRole%22%0A%20%20%20%20%7D%0A%20%20%5D%0A%7D-,Logging%20that%20requires%20additional%20permissions%20%5BV2%5D,-Some%20AWS%20services)**에서 다음 중 하나를 선택합니다.
1. **CloudWatch Logs** - 로그 그룹을 선택하거나 생성합니다.
1. **Amazon S3** - S3 버킷 ARN을 입력합니다.
1. **Amazon Data Firehose** - Firehose 전송 스트림을 선택하거나 생성합니다.
1. **추가 설정 - \$1선택 사항** \$1의 경우 다음 옵션을 지정할 수 있습니다.
1. **필드 선택**에서 대상으로 전송할 로그 필드 이름을 선택합니다. [액세스 로그 필드](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/standard-logs-reference.html#BasicDistributionFileFormat) 및 [실시간 액세스 로그 필드](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/standard-logging.html#standard-logging-real-time-log-selection)의 하위 집합을 선택할 수 있습니다.
1. (Amazon S3만 해당) **파티셔닝**에서 로그 파일 데이터를 파티셔닝할 경로를 지정합니다.
1. (Amazon S3만 해당) **Hive 호환 파일 형식**에서 확인란을 선택하여 Hive 호환 S3 경로를 사용할 수 있습니다. 이렇게 하면 Hive 호환 도구에 새 데이터를 쉽게 로드할 수 있습니다.
1. **출력 형식**에서 원하는 형식을 지정합니다.
1. **필드 구분 기호**에서 로그 필드를 구분하는 방법을 지정합니다.
1. **저장**을 선택합니다.
1. 전송 상태가 **활성**으로 표시되는지 확인합니다.
### 로그 전송 구성(CloudWatch API)
CloudWatch Logs API를 사용하여 프로그래밍 방식으로 로그 전송을 구성할 수도 있습니다. 작동하는 로그 전송은 다음 세 가지 요소로 구성됩니다.
+ **DeliverySource** - 로그를 생성하는 AWS DevOps 에이전트 스페이스 리소스를 나타냅니다.
+ **DeliveryDestination** - 로그가 기록되는 대상을 나타냅니다.
+ **전송** - 전송 소스를 전송 대상에 연결합니다.
#### 1단계: 전송 소스 생성
[PutDeliverySource](https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_PutDeliverySource.html) 작업을 사용하여 전송 소스를 생성합니다. AWS DevOps 에이전트 스페이스 리소스의 ARN을 전달하고를 로그 유형`APPLICATION_LOGS`으로 지정합니다.
다음 예시에서는 에이전트 공간에 대한 전송 소스를 생성합니다.
```
{
"name": "my-agent-space-delivery-source",
"resourceArn": "arn:aws:aidevops:us-east-1:123456789012:agentspace/my-agent-space-id",
"logType": "APPLICATION_LOGS"
}
```
다음 예시에서는 서비스에 대한 전송 소스를 생성합니다.
```
{
"name": "my-service-delivery-source",
"resourceArn": "arn:aws:aidevops:us-east-1:123456789012:service",
"logType": "APPLICATION_LOGS"
}
```
#### 2단계: 전송 대상 생성
[PutDeliveryDestination](https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_PutDeliveryDestination.html) 작업을 사용하여 로그가 저장되는 위치를 구성합니다. Amazon CloudWatch Logs, Amazon S3 또는 Amazon Data Firehose를 선택할 수 있습니다.
다음 예시에서는 CloudWatch Logs 대상을 생성합니다.
```
{
"name": "my-cwl-destination",
"deliveryDestinationConfiguration": {
"destinationResourceArn": "arn:aws:logs:us-east-1:123456789012:log-group:/aws/aidevops/my-agent-space"
},
"outputFormat": "json"
}
```
다음 예시에서는 Amazon S3 대상을 생성합니다.
```
{
"name": "my-s3-destination",
"deliveryDestinationConfiguration": {
"destinationResourceArn": "arn:aws:s3:::my-aidevops-logs-bucket"
},
"outputFormat": "json"
}
```
다음 예시에서는 Amazon Data Firehose 대상을 생성합니다.
```
{
"name": "my-firehose-destination",
"deliveryDestinationConfiguration": {
"destinationResourceArn": "arn:aws:firehose:us-east-1:123456789012:deliverystream/my-aidevops-log-stream"
},
"outputFormat": "json"
}
```
**참고**
** 교차 계정을 통해 로그를 전송하는 경우 대상 계정에서 [PutDeliveryDestinationPolicy](https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_PutDeliveryDestinationPolicy.html)를 사용하여 전송을 승인해야 합니다.
CloudFormation을 사용하려면 다음을 사용할 수 있습니다.
+ [Delivery](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-logs-delivery.html)
+ [DeliveryDestination](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-logs-deliverydestination.html)
+ [DeliverySource](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-logs-deliverysource.html)
`ResourceArn`은 `AgentSpaceArn`이며 `LogType`은 지원되는 로그 유형의 `APPLICATION_LOGS`여야 합니다.
#### 3단계: 전송 생성
[CreateDelivery](https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_CreateDelivery.html) 작업을 사용하여 전송 소스를 전송 대상에 연결합니다.
```
{
"deliverySourceName": "my-agent-space-delivery-source",
"deliveryDestinationArn": "arn:aws:logs:us-east-1:123456789012:delivery-destination:my-cwl-destination"
}
```
#### AWS CloudFormation
다음 리소스와 함께 AWS CloudFormation을 사용하여 로그 전송을 구성할 수도 있습니다.
+ [AWS::Logs::DeliverySource](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-logs-deliverysource.html)
+ [AWS::Logs::DeliveryDestination](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-logs-deliverydestination.html)
+ [AWS::Logs::Delivery](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-logs-delivery.html)
`ResourceArn`를 AWS DevOps 에이전트 공간 또는 서비스 ARN으로 설정하고를 `LogType`로 설정합니다`APPLICATION_LOGS`.
### 로그 스키마 참조
AWS DevOps Agent는 모든 이벤트 유형에서 공유 로그 스키마를 사용합니다. 모든 로그 이벤트가 모든 필드를 사용하는 것은 아닙니다.
다음 표에서는 로그 스키마의 필드를 설명합니다.
| Field | Type | 설명 |
| --- | --- | --- |
| event\$1timestamp | Long | 이벤트 발생 시점의 Unix 타임스탬프 |
| resource\$1arn | 문자열 | 이벤트를 생성한 리소스의 ARN |
| optional\$1account\$1id | 문자열 | AWS 로그와 연결된 계정 ID입니다. |
| optional\$1level | 문자열 | 로그 수준: INFO, WARN, ERROR |
| optional\$1agent\$1space\$1id | 문자열 | 에이전트 공간의 식별자입니다. |
| optional\$1association\$1id | 문자열 | 로그의 연결 식별자입니다. |
| optional\$1status | 문자열 | 토폴로지 작업의 상태입니다. |
| optional\$1webhook\$1id | 문자열 | Webhook 식별자입니다. |
| optional\$1mcp\$1endpoint\$1url | 문자열 | MCP 서버 엔드포인트 URL |
| optional\$1service\$1type | 문자열 | 서비스 유형: DYNATRACE, DATADOG, GITHUB, SLACK, SERVICENOW. |
| optional\$1service\$1endpoint\$1url | 문자열 | 타사 통합을 위한 엔드포인트 URL입니다. |
| optional\$1service\$1id | 문자열 | 소스의 식별자입니다. |
| request\$1id | 문자열 | AWS CloudTrail 또는 지원 티켓과의 상관관계를 확인하기 위한 요청 식별자입니다. |
| optional\$1operation | 문자열 | 수행된 작업의 이름입니다. |
| optional\$1task\$1type | 문자열 | 에이전트 백로그 작업 유형: INVESTIGATION 또는 EVALUATION |
| optional\$1task\$1id | 문자열 | 에이전트 백로그 작업 IDAgent 백로그 작업 식별자입니다. |
| optional\$1reference | 문자열 | 에이전트 작업의 참조(예: Jira 티켓). |
| optional\$1error\$1type | 문자열 | 오류 유형 |
| optional\$1error\$1message | 문자열 | 작업이 실패할 때 오류 설명입니다. |
| optional\$1details | 문자열(JSON) | 작업 파라미터 및 결과가 포함된 서비스별 이벤트 페이로드입니다. |
### 로그 전송 관리 및 비활성화
AWS 관리 콘솔의 AWS DevOps 에이전트 콘솔에서 또는 CloudWatch Logs API를 사용하여 언제든지 로그 전송을 수정하거나 제거할 수 있습니다.
#### 로그 전송 관리(콘솔)
1. AWS 관리 콘솔에서 AWS DevOps 에이전트 콘솔을 엽니다.
1. **설정** 페이지(서비스 수준 로그의 경우) 또는 특정 **에이전트 스페이스** 페이지(에이전트 스페이스 수준 로그의 경우)로 이동합니다.
1. **구성** 탭(에이전트 스페이스 수준 로그의 경우) 또는 **기능 공급자** **>** **로그** 탭(서비스 수준 로그의 경우)에서 수정할 전송을 선택합니다.
1. 필요에 따라 구성을 업데이트하고 **저장**을 선택합니다.
**참고:** 기존 전송의 대상 유형은 변경할 수 없습니다. 대상 유형을 변경하려면 현재 전송을 삭제하고 새 전송을 생성합니다.
#### 로그 전송 비활성화(콘솔)
1. AWS 관리 콘솔에서 AWS DevOps 에이전트 콘솔을 엽니다.
1. **설정** 페이지(서비스 수준 로그의 경우) 또는 특정 **에이전트 스페이스** 페이지(에이전트 스페이스 수준 로그의 경우)로 이동합니다.
1. **구성** 탭(에이전트 스페이스 수준 로그의 경우) 또는 **기능 공급자** **>** **로그** 탭(서비스 수준 로그의 경우)에서 제거할 전송을 선택합니다.
1. **삭제**를 선택하고 확인합니다.
#### 로그 전송 비활성화(API)
API를 사용하여 로그 전송을 제거하려면 다음 순서로 리소스를 삭제합니다.
1. [DeleteDelivery](https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_DeleteDelivery.html)를 사용하여 전송을 삭제합니다.
1. [DeleteDeliverySource](https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_DeleteDeliverySource.html)를 사용하여 전송 소스를 삭제합니다.
1. (선택 사항) 전송 대상이 더 이상 필요하지 않은 경우 [DeleteDeliveryDestination](https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_DeleteDeliveryDestination.html)을 사용하여 삭제합니다.
**중요**
** 로그를 생성하는 에이전트 공간 리소스를 삭제한 후(예: 에이전트 공간을 삭제한 후) 로그 전송 리소스를 제거하는 것은 사용자의 책임입니다. 이러한 리소스를 제거하지 않으면 분리된 전송 구성이 남아 있을 수 있습니다.
## 가격 책정
AWS DevOps 에이전트는 벤딩 로그 활성화에 대해 요금을 부과하지 않습니다. 그러나 선택한 로그 전송 대상에 따라 전송, 수집, 스토리지, 액세스에 대한 요금이 발생할 수 있습니다. 요금 세부 정보는 [Amazon CloudWatch 요금](https://aws.amazon.com/cloudwatch/pricing/)**의 로그 탭에서 판매** 로그를 참조**하세요**.
대상별 요금은 다음을 참조하세요.
+ [Amazon CloudWatch Logs 요금](https://aws.amazon.com/cloudwatch/pricing/)
+ [Amazon S3 요금](https://aws.amazon.com/s3/pricing/)
+ [Amazon Data Firehose 요금](https://aws.amazon.com/kinesis/data-firehose/pricing/)
# 프라이빗 호스팅 도구에 연결
## 프라이빗 연결 개요
AWS DevOps 에이전트는 사용자 지정 모델 컨텍스트 프로토콜(MCP) 도구 및 에이전트에게 프라이빗 패키지 레지스트리, 자체 호스팅 관찰성 플랫폼, 내부 설명서 APIs 및 소스 제어 인스턴스와 같은 내부 시스템에 대한 액세스 권한을 부여하는 기타 통합을 통해 확장할 수 있습니다( 참조[AWS DevOps Agent에 대한 기능 구성](configuring-capabilities-for-aws-devops-agent.md)). 이러한 서비스는 퍼블릭 인터넷 액세스가 제한되거나 없는 [Amazon Virtual Private Cloud(Amazon VPC)](https://docs.aws.amazon.com/vpc/latest/userguide) 내에서 실행되는 경우가 많습니다. 즉, AWS DevOps Agent는 기본적으로 해당 서비스에 연결할 수 없습니다.
프라이빗 연결 AWS DevOps 에이전트를 사용하면 에이전트 스페이스를 퍼블릭 인터넷에 노출하지 않고 VPC에서 실행되는 서비스에 안전하게 연결할 수 있습니다. 프라이빗 연결은 MCP 서버, 자체 호스팅 Grafana 또는 Splunk 인스턴스, GitHub Enterprise Server 및 GitLab 자체 관리형과 같은 소스 제어 시스템을 포함하여 프라이빗 엔드포인트에 도달해야 하는 모든 통합과 함께 작동합니다.
**참고**
** 프라이빗 호스팅 도구가 VPC 내에서 AWS DevOps 에이전트에 아웃바운드 요청을 하는 경우 네트워크 내에 유지되도록 VPC 엔드포인트를 사용하여이 트래픽을 보호할 수도 있습니다 AWS . 예를 들어 웹후크 이벤트를 통해 DevOps 에이전트를 트리거하는 도구와 함께 사용할 수 있습니다( 참조[Webhook를 통해 DevOps 에이전트 호출](configuring-capabilities-for-aws-devops-agent-invoking-devops-agent-through-webhook.md)). 자세한 내용은 [VPC 엔드포인트(AWS PrivateLink)](aws-devops-agent-security-vpc-endpoints-aws-privatelink.md) 단원을 참조하십시오.
### 프라이빗 연결 작동 방식
프라이빗 연결은 AWS DevOps 에이전트와 VPC의 대상 리소스 간에 보안 네트워크 경로를 생성합니다. 후드에서 AWS DevOps 에이전트는 Amazon [VPC Lattice](https://docs.aws.amazon.com/vpc-lattice/latest/ug/)를 사용하여이 보안 프라이빗 연결 경로를 설정합니다. VPC Lattice는 기본 네트워크 인프라를 관리하지 않고도 VPCs, 계정 및 컴퓨팅 유형 전반의 애플리케이션 간 통신을 연결, 보호 및 모니터링할 수 있는 애플리케이션 네트워킹 서비스입니다.
프라이빗 연결을 생성하면 다음이 발생합니다.
+ 대상 서비스에 네트워크로 연결된 VPC, 서브넷 및 (선택 사항) 보안 그룹을 제공합니다.
+ AWS DevOps Agent는 서비스 관리형 [리소스 게이트웨이](https://docs.aws.amazon.com/vpc/latest/privatelink/resource-gateway.html)를 생성하고 지정한 서브넷에 탄력적 네트워크 인터페이스(ENIs)를 프로비저닝합니다.
+ 에이전트는 리소스 게이트웨이를 사용하여 프라이빗 네트워크 경로를 통해 트래픽을 대상 서비스의 IP 주소 또는 DNS 이름으로 라우팅합니다.
리소스 게이트웨이는 AWS DevOps Agent에서 완벽하게 관리되며 계정에 읽기 전용 리소스(명명)로 표시됩니다`aidevops-{your-private-connection-name}`. 구성하거나 유지 관리할 필요가 없습니다. VPC에서 생성된 유일한 리소스는 지정한 서브넷의 ENIs입니다. 이러한 ENIs 프라이빗 트래픽의 진입점 역할을 하며 전적으로 서비스에 의해 관리됩니다. 인터넷으로부터의 인바운드 연결을 허용하지 않으며 자체 보안 그룹을 통해 트래픽을 완전히 제어할 수 있습니다.
### 보안
프라이빗 연결은 여러 보안 계층으로 설계되었습니다.
+ **퍼블릭 인터넷 노출 없음** - AWS DevOps 에이전트와 대상 서비스 간의 모든 트래픽은 AWS 네트워크에 남아 있습니다. 서비스에 퍼블릭 IP 주소나 인터넷 게이트웨이가 필요하지 않습니다.
+ **서비스 제어 리소스 게이트웨이** - 서비스 관리형 리소스 게이트웨이는 계정에서 읽기 전용입니다. AWS DevOps 에이전트만 사용할 수 있으며 다른 서비스 또는 보안 주체는 트래픽을 라우팅할 수 없습니다. 모든 VPC Lattice API 호출을 기록하는 [AWS CloudTrail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/) 로그에서 이를 확인할 수 있습니다.
+ **보안 그룹 및 규칙** - 소유하고 관리하는 보안 그룹을 통해 ENIs에 대한 인바운드 및 아웃바운드 트래픽을 제어합니다. 보안 그룹을 지정하지 않으면 AWS DevOps Agent는 정의한 포트로 범위가 지정된 기본 보안 그룹을 생성합니다.
+ **최소 권한이 있는 서비스 연결 역할 -** AWS DevOps Agent는 [서비스 연결 역할을](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html) 사용하여 필요한 VPC Lattice 및 Amazon EC2 리소스만 생성합니다. 이 역할은 태그가 지정된 리소스로 범위가 지정`AWSAIDevOpsManaged`되며 계정의 다른 리소스에 액세스할 수 없습니다.
**참고**
** 조직에 VPC Lattice API 작업을 제한하는 [서비스 제어 정책(SCPs)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html)이 있는 경우 서비스 연결 역할을 통해 서비스 관리형 리소스 게이트웨이가 생성됩니다. SCPs 서비스 연결 역할에 필요한 작업을 허용하는지 확인합니다.
### 아키텍처
다음 다이어그램은 프라이빗 연결의 네트워크 경로를 보여줍니다.
![\[alt text not found\]](http://docs.aws.amazon.com/ko_kr/devopsagent/latest/userguide/images/7cd6182e6b8d.png)
이 아키텍처에서,
+ AWS DevOps Agent는 대상 서비스에 대한 요청을 시작합니다.
+ Amazon VPC Lattice는 VPC의 서비스 관리형 리소스 게이트웨이를 통해 요청을 라우팅합니다. 자체 VPC Lattice 리소스를 사용한 고급 설정은 [기존 VPC Lattice 리소스를 사용한 고급 설정을](#advanced-setup-using-existing-vpc-lattice-resources) 참조하세요.
+ VPC의 ENI는 트래픽을 수신하여 대상 서비스의 IP 주소 또는 DNS 이름으로 전달합니다.
+ 보안 그룹은 ENIs.
+ 대상 서비스의 관점에서 요청은 VPC 내 ENIs의 프라이빗 IP 주소에서 시작됩니다.
## 프라이빗 연결 생성
AWS Management Console 또는 AWS CLI를 사용하여 프라이빗 연결을 생성할 수 있습니다.
**참고**
** VPC Lattice에서 지원하지 않는 가용 영역은 `use1-az3`, , `usw1-az2`, `apne1-az3`, `apne2-az2`, `euc1-az2``euw1-az4`, , `cac1-az3`입니다`ilc1-az2`.
### 사전 조건
프라이빗 연결을 생성하기 전에 다음이 있는지 확인합니다.
+ **활성 에이전트 스페이스** - 계정에 기존 에이전트 스페이스가 필요합니다. 없으면 [AWS DevOps 에이전트 시작하기](getting-started-with-aws-devops-agent.md) 섹션을 참조하세요.
+ **비공개로 연결할 수 있는 대상 서비스** - 리소스 게이트웨이가 배포된 VPC의 알려진 프라이빗 IP 주소 또는 DNS 이름에서 MCP 서버, 관찰성 플랫폼 또는 기타 서비스에 연결할 수 있어야 합니다. 리소스 게이트웨이 서브넷에서 라우팅할 수 있는 한 서비스는 동일한 VPC, 피어링된 VPC 또는 온프레미스에서 실행할 수 있습니다. 서비스는 연결을 생성할 때 지정한 포트에서 최소 TLS 버전이 1.2인 HTTPS 트래픽을 제공해야 합니다.
+ **VPC의 서브넷** - ENIs될 서브넷 1\$120개를 식별합니다. 고가용성을 위해 여러 가용 영역에서 서브넷을 선택하는 것이 좋습니다. 이러한 서브넷에는 대상 서비스에 대한 네트워크 연결이 있어야 합니다. VPC Lattice는 가용 영역당 하나의 서브넷을 사용할 수 있습니다.
+ **(선택 사항) 보안 그룹** - 특정 규칙으로 트래픽을 제어하려면 ENIs에 연결할 보안 그룹 IDs를 최대 5개까지 준비합니다. 보안 그룹을 생략하면 AWS DevOps 에이전트가 기본 보안 그룹을 생성합니다.
프라이빗 연결은 계정 수준 리소스입니다. 프라이빗 연결을 생성한 후 동일한 호스트에 연결해야 하는 여러 통합 및 에이전트 스페이스에서 프라이빗 연결을 재사용할 수 있습니다.
### 콘솔을 사용하여 프라이빗 연결 생성
1. AWS DevOps 에이전트 콘솔을 엽니다.
1. 탐색 창에서 **기능 공급자**를 선택한 다음 **프라이빗 연결을** 선택합니다.
1. **새 연결 생성**을 선택합니다.
1. **이름**에와 같이 연결을 설명하는 이름을 입력합니다`my-mcp-tool-connection`.
1. **VPC**에서 리소스 게이트웨이 ENIs 배포할 VPC를 선택합니다.
1. **서브넷에서** 하나 이상의 서브넷(최대 20개)을 선택합니다. 두 개 이상의 가용 영역에서 서브넷을 선택하는 것이 좋습니다.
1. **IP 주소 유형**에서 대상 서비스의 IP 주소 유형(`IPv4`, `IPv6`또는 `DualStack`)을 선택합니다.
1. (선택 사항) ** IPv4 주소 수에** IP 주소 유형으로 IPv4 또는 듀얼 스택을 선택한 경우 리소스 게이트웨이의 ENI당 IPv4 주소 수를 입력할 수 있습니다. 기본값은 ENI당 16개의 IPv4 주소입니다.
1. (선택 사항) **보안 그룹에서** 기존 보안 그룹(최대 5개)을 선택하여 대상 서비스에 도달할 수 있는 트래픽을 제한합니다. 선택하지 않으면 기본 보안 그룹이 생성됩니다.
1. (선택 사항) **포트 범위에서** 대상 애플리케이션이 수신하는 TCP 포트(예: `443` 또는 )를 지정합니다`8080-8090`. 최대 11개의 포트 범위를 지정할 수 있습니다.
1. **호스트 주소**에 대상 서비스의 IP 주소 또는 DNS 이름(예: `mcp.internal.example.com` 또는 `10.0.1.50`)을 입력합니다. 선택한 VPC에서 서비스에 연결할 수 있어야 합니다. DNS 이름을 선택하는 경우 선택한 VPC에서 확인할 수 있어야 합니다.
1. (선택 사항) **인증서 퍼블릭 키**의 경우 지정한 호스트 주소가 프라이빗 인증 기관에서 발급한 TLS 인증서를 사용하는 경우 인증서의 PEM 인코딩 퍼블릭 키를 입력합니다. 이렇게 하면 AWS DevOps 에이전트가 대상 서비스에 대한 TLS 연결을 신뢰할 수 있습니다.
1. **연결 생성**을 선택합니다.
연결 상태가 **생성 진행 중**으로 변경됩니다. 이 프로세스는 최대 10분이 걸릴 수 있습니다. 상태가 **활성**으로 변경되면 네트워크 경로가 준비된 것입니다.
상태가 **생성 실패**로 변경되면 다음을 확인합니다.
+ 지정한 서브넷에 사용 가능한 IP 주소가 있습니다.
+ 계정이 VPC Lattice 서비스 할당량에 도달하지 않았습니다.
+ 제한적인 IAM 정책으로 인해 서비스 연결 역할이 리소스를 생성할 수 없습니다.
**참고**
** 이러한 단계는 기능 공급자를 등록하는 `Create a new private connection` 동안를 선택하여 수행할 수도 있습니다. 자세한 내용은 [기능 공급자와의 프라이빗 연결 사용을 참조하세요](#use-a-private-connection-with-a-capability-provider).
### AWS CLI를 사용하여 프라이빗 연결 생성
다음 명령을 실행하여 프라이빗 연결을 생성합니다. 자리 표시자 값을 자신의 값으로 바꿉니다.
```
aws devops-agent create-private-connection \
--name my-mcp-tool-connection \
--mode '{
"serviceManaged": {
"hostAddress": "mcp.internal.example.com",
"vpcId": "vpc-0123456789abcdef0",
"subnetIds": [
"subnet-0123456789abcdef0",
"subnet-0123456789abcdef1"
],
"securityGroupIds": [
"sg-0123456789abcdef0"
],
"portRanges": ["443"]
}
}'
```
응답에는 연결 이름과 상태가 포함됩니다`CREATE_IN_PROGRESS`.
```
{
"name": "my-mcp-tool-connection",
"status": "CREATE_IN_PROGRESS",
"resourceGatewayId": "rgw-0123456789abcdef0",
"hostAddress": "mcp.internal.example.com",
"vpcId": "vpc-0123456789abcdef0"
}
```
연결 상태를 확인하려면 `describe-private-connection` 명령을 사용합니다.
```
aws devops-agent describe-private-connection \
--name my-mcp-tool-connection
```
상태가 이면 프라이빗 연결을 사용할 준비가 된 `ACTIVE`것입니다.
## 기능 공급자와의 프라이빗 연결 사용
프라이빗 연결을 사용하려면 기능 공급자를 등록하는 동안 프라이빗 연결에 연결할 수 있습니다. 프라이빗 연결에 사용할 수 있는 지원되는 기능은 `GitHub`, `GitLab`, `MCP Server`및 입니다`Grafana`. AWS Management Console 또는 AWS CLI를 사용하여이 단계를 수행할 수 있습니다.
**참고**
** 기능 공급자를 등록할 때 AWS DevOps Agent는 엔드포인트에 연결할 수 있고 응답하는지 확인합니다. 등록을 완료하기 전에 대상 서비스가 실행 중이고 연결을 수락하고 있는지 확인합니다.
### 콘솔을 사용하여 기능 공급자와의 프라이빗 연결 사용
AWS DevOps 에이전트 콘솔에서 "프라이빗 연결을 사용하여 엔드포인트에 연결" 옵션을 선택하여 등록 중에 프라이빗 연결을 기능에 연결할 수 있습니다.
![\[alt text not found\]](http://docs.aws.amazon.com/ko_kr/devopsagent/latest/userguide/images/a2a7ffb70ffe.png)
1. AWS DevOps 에이전트 콘솔을 열고 에이전트 공간으로 이동합니다.
1. **기능 공급자 섹션에서 등록을** 선택합니다. ****
1. 프라이빗 연결에 사용할 기능 유형에 대해 **등록**을 선택합니다.
1. 등록 세부 정보 보기에서 프라이빗 연결을 사용하여 연결하려는 엔드포인트 URL(예: `https://mcp.internal.example.com`)을 입력합니다.
1. **프라이빗 연결을 사용하여 엔드포인트에 연결을** 선택합니다.
1. 연결하려는 엔드포인트 URL에 해당하는 기존 프라이빗 연결을 선택하거나 **새 프라이빗 연결 생성을** 선택하여 생성합니다.
1. 기능 공급자의 등록 프로세스를 완료합니다.
### AWS CLI를 사용하여 기능 공급자와의 프라이빗 연결 사용
`private-connection-name` 인수를 포함하여 프라이빗 연결에 기능을 등록할 수 있습니다. 다음은 `my-mcp-tool-connection` 프라이빗 연결을 사용하여 API 키 권한 부여로 MCP 서버를 등록하는 예입니다. 자리 표시자 값을 자신의 값으로 바꿉니다.
```
aws devops-agent register-service \
--service mcpserver \
--private-connection-name my-mcp-tool-connection \
--service-details '{
"mcpserver": {
"name": "my-mcp-tool",
"endpoint": "https://mcp.internal.example.com",
"authorizationConfig": {
"apiKey": {
"apiKeyName": "api-key",
"apiKeyValue": "secret-value",
"apiKeyHeader": "x-api-key"
}
}
}
}' \
--region us-east-1
```
## 프라이빗 연결 확인
프라이빗 연결이 **활성** 상태에 도달하고 기능 공급자가 이를 활용한 후 AWS DevOps 에이전트가 대상 서비스에 도달할 수 있는지 확인합니다.
1. AWS DevOps 에이전트 콘솔을 열고 에이전트 공간으로 이동합니다.
1. 새 채팅 세션을 시작합니다.
1. 프라이빗 연결에서 지원하는 통합을 사용하는 명령을 호출합니다. 예를 들어 MCP 도구가 내부 지식 기반에 대한 액세스를 제공하는 경우 에이전트에게 해당 지식 기반이 필요한 질문을 합니다.
1. 에이전트가 프라이빗 서비스의 결과를 반환하는지 확인합니다.
연결이 실패하면 다음을 확인합니다.
+ **VPC Lattice 제한** - 리소스 게이트웨이 또는 기타 [VPC Lattice 할당량](https://docs.aws.amazon.com/vpc-lattice/latest/ug/quotas.html) 제한에 도달하지 않았는지 확인합니다.
+ **보안 그룹 규칙** - ENIs에 연결된 보안 그룹이 서비스가 수신하는 포트에서 아웃바운드 트래픽을 허용하는지 확인합니다. 또한 서비스의 보안 그룹이 대상 포트에서 인바운드 트래픽을 허용하는지 확인합니다. 트래픽은 VPC CIDR 범위 내의 VPC Lattice 데이터 영역 IPs에서 도착합니다. 보안 그룹 참조(ENI 보안 그룹을 소스로 허용)를 사용하거나 VPC CIDR에서 인바운드를 허용할 수 있습니다.
+ **서브넷 연결** - 선택한 서브넷이 서비스로 트래픽을 라우팅할 수 있는지 확인합니다. 서비스가 다른 서브넷에서 실행되는 경우 라우팅 테이블이 둘 사이의 트래픽을 허용하는지 확인합니다.
+ **서비스 가용성** - 서비스가 실행 중이고 예상 포트에서 연결을 수락하고 있는지 확인합니다.
+ **지원되지 않는 가용 영역** - 서브넷이 지원되는 가용 영역에 있는지 확인합니다. 를 실행`aws ec2 describe-subnets --subnet-ids --query 'Subnets[*].[SubnetId,AvailabilityZoneId]'`하고 위에 나열된 지원되지 않는 가용 영역을 확인합니다.
## 프라이빗 연결 삭제
AWS Management Console 또는 AWS CLI를 사용하여 미사용 프라이빗 연결을 삭제할 수 있습니다.
### 콘솔을 사용하여 프라이빗 연결 삭제
1. AWS DevOps 에이전트 콘솔을 엽니다.
1. 탐색 창에서 **기능 공급자**를 선택한 다음 **프라이빗 연결을** 선택합니다.
1. 삭제할 프라이빗 연결의 **작업** 메뉴를 선택하고 **제거**를 선택합니다.
프라이빗 연결은 "연결 제거" 상태로 표시되는 반면 AWS , DevOps Agent는 VPC에서 관리형 리소스 게이트웨이와 ENIs 제거합니다. 삭제가 완료되면 프라이빗 연결 목록에 연결이 더 이상 표시되지 않습니다.
### AWS CLI를 사용하여 프라이빗 연결 삭제
```
aws devops-agent delete-private-connection \
--name my-mcp-tool-connection
```
응답은 상태를 반환합니다`DELETE_IN_PROGRESS`. AWS DevOps 에이전트는 VPC에서 관리형 리소스 게이트웨이 및 ENIs 제거합니다. 삭제가 완료되면 프라이빗 연결 목록에 연결이 더 이상 표시되지 않습니다.
## 기존 VPC Lattice 리소스를 사용한 고급 설정
조직에서 이미 Amazon VPC Lattice를 사용하고 자체 리소스 구성을 관리하는 경우 자체 관리형 모드에서 프라이빗 연결을 생성할 수 있습니다. AWS DevOps 에이전트가 리소스 게이트웨이를 생성하도록 하는 대신 대상 서비스를 가리키는 기존 리소스 구성의 Amazon 리소스 이름(ARN)을 제공합니다.
이 접근 방식은 다음과 같은 경우에 유용합니다.
+ 리소스 게이트웨이 및 리소스 구성 수명 주기를 완전히 제어하고자 합니다.
+ 여러 AWS 계정 또는 서비스에서 리소스 구성을 공유해야 합니다.
+ 자세한 트래픽 모니터링을 위해 VPC Lattice 액세스 로그가 필요합니다.
+ hub-and-spoke 네트워크 아키텍처를 실행합니다.
AWS CLI를 사용하여 자체 관리형 프라이빗 연결을 생성하려면:
```
aws devops-agent create-private-connection \
--name my-advanced-connection \
--mode '{
"selfManaged": {
"resourceConfigurationId": "arn:aws:vpc-lattice:us-east-1:123456789012:resourceconfiguration/rcfg-0123456789abcdef0"
}
}'
```
VPC Lattice 리소스 게이트웨이 및 리소스 구성 설정에 대한 자세한 내용은 [Amazon VPC Lattice 사용 설명서를](https://docs.aws.amazon.com/vpc-lattice/latest/ug/) 참조하세요.
## 관련 주제
+ [VPC 엔드포인트(AWS PrivateLink)](aws-devops-agent-security-vpc-endpoints-aws-privatelink.md)
+ [MCP 서버 연결](configuring-capabilities-for-aws-devops-agent-connecting-mcp-servers.md)
+ [AWS DevOps Agent에 대한 기능 구성](configuring-capabilities-for-aws-devops-agent.md)
+ [AWS DevOps 에이전트 보안](aws-devops-agent-security.md)
+ [DevOps 에이전트 IAM 권한](aws-devops-agent-security-devops-agent-iam-permissions.md)