Commit ·
975da6d
0
Parent(s):
Initial commit: Tech Advisor fine-tuned on AWS DevOps Agent docs
Browse files- Gradio chat app using fine-tuned Llama-3.1-Nemotron-Nano-4B
- QLoRA training pipeline (1,230 pairs from 66 doc pages)
- Model hosted at aslanconfig/tech-advisor-nemotron-4b
This view is limited to 50 files because it contains too many changes. See raw diff
- .gitignore +9 -0
- CLAUDE.md +42 -0
- README.md +177 -0
- app.py +87 -0
- requirements.txt +5 -0
- training/README.md +65 -0
- training/data/raw/about-aws-devops-agent-agent-instructions.md +103 -0
- training/data/raw/about-aws-devops-agent-devops-agent-memories.md +98 -0
- training/data/raw/about-aws-devops-agent-devops-agent-skills.md +255 -0
- training/data/raw/about-aws-devops-agent-learned-skills.md +42 -0
- training/data/raw/about-aws-devops-agent-managing-assets.md +112 -0
- training/data/raw/about-aws-devops-agent-supported-regions.md +49 -0
- training/data/raw/about-aws-devops-agent-what-are-devops-agent-spaces.md +29 -0
- training/data/raw/about-aws-devops-agent-what-is-a-devops-agent-topology.md +54 -0
- training/data/raw/about-aws-devops-agent-what-is-a-devops-agent-web-app.md +25 -0
- training/data/raw/about-aws-devops-agent.md +52 -0
- training/data/raw/aws-devops-agent-security-compliance-validation.md +7 -0
- training/data/raw/aws-devops-agent-security-devops-agent-iam-permissions.md +41 -0
- training/data/raw/aws-devops-agent-security-encryption-at-rest-for-devops-agent.md +38 -0
- training/data/raw/aws-devops-agent-security-limiting-agent-access-in-an-aws-account.md +59 -0
- training/data/raw/aws-devops-agent-security-setting-up-external-identity-provider-idp-authentication.md +52 -0
- training/data/raw/aws-devops-agent-security-setting-up-iam-identity-center-authentication.md +53 -0
- training/data/raw/aws-devops-agent-security-vpc-endpoints-aws-privatelink.md +27 -0
- training/data/raw/aws-devops-agent-security.md +46 -0
- training/data/raw/configuring-capabilities-for-aws-devops-agent-aws-eks-access-setup.md +20 -0
- training/data/raw/configuring-capabilities-for-aws-devops-agent-connecting-azure-index.md +17 -0
- training/data/raw/configuring-capabilities-for-aws-devops-agent-connecting-mcp-servers.md +46 -0
- training/data/raw/configuring-capabilities-for-aws-devops-agent-connecting-multiple-aws-accounts.md +118 -0
- training/data/raw/configuring-capabilities-for-aws-devops-agent-connecting-remote-a2a-agents.md +109 -0
- training/data/raw/configuring-capabilities-for-aws-devops-agent-connecting-telemetry-sources-index.md +65 -0
- training/data/raw/configuring-capabilities-for-aws-devops-agent-connecting-to-cicd-pipelines-index.md +11 -0
- training/data/raw/configuring-capabilities-for-aws-devops-agent-connecting-to-privately-hosted-tools.md +48 -0
- training/data/raw/configuring-capabilities-for-aws-devops-agent-connecting-to-ticketing-and-chat-index.md +8 -0
- training/data/raw/configuring-capabilities-for-aws-devops-agent-integrating-devops-agent-into-event-driven-applications-using-amazon-eventbridge-index.md +39 -0
- training/data/raw/configuring-capabilities-for-aws-devops-agent-invoking-devops-agent-through-webhook.md +56 -0
- training/data/raw/configuring-capabilities-for-aws-devops-agent-migrating-from-public-preview-to-general-availability.md +41 -0
- training/data/raw/configuring-capabilities-for-aws-devops-agent-vended-logs-and-metrics.md +43 -0
- training/data/raw/configuring-capabilities-for-aws-devops-agent.md +16 -0
- training/data/raw/connecting-azure-connecting-azure-devops.md +31 -0
- training/data/raw/connecting-azure-connecting-azure-resources.md +38 -0
- training/data/raw/connecting-telemetry-sources-connecting-datadog.md +98 -0
- training/data/raw/connecting-telemetry-sources-connecting-dynatrace.md +121 -0
- training/data/raw/connecting-telemetry-sources-connecting-grafana.md +115 -0
- training/data/raw/connecting-telemetry-sources-connecting-new-relic.md +120 -0
- training/data/raw/connecting-telemetry-sources-connecting-splunk.md +46 -0
- training/data/raw/connecting-to-cicd-pipelines-connecting-github.md +37 -0
- training/data/raw/connecting-to-cicd-pipelines-connecting-gitlab.md +29 -0
- training/data/raw/connecting-to-ticketing-and-chat-connecting-pagerduty.md +29 -0
- training/data/raw/connecting-to-ticketing-and-chat-connecting-servicenow.md +34 -0
- training/data/raw/connecting-to-ticketing-and-chat-connecting-slack.md +25 -0
.gitignore
ADDED
|
@@ -0,0 +1,9 @@
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| 1 |
+
__pycache__/
|
| 2 |
+
*.pyc
|
| 3 |
+
.env
|
| 4 |
+
.venv/
|
| 5 |
+
venv/
|
| 6 |
+
*.egg-info/
|
| 7 |
+
dist/
|
| 8 |
+
build/
|
| 9 |
+
.DS_Store
|
CLAUDE.md
ADDED
|
@@ -0,0 +1,42 @@
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| 1 |
+
# CLAUDE.md
|
| 2 |
+
|
| 3 |
+
This file provides guidance to Claude Code (claude.ai/code) when working with code in this repository.
|
| 4 |
+
|
| 5 |
+
## Project Overview
|
| 6 |
+
|
| 7 |
+
Tech Advisor: a Gradio chatbot fine-tuned on AWS DevOps Agent documentation. Uses NVIDIA Llama-3.1-Nemotron-Nano-4B-v1.1 as the base model, fine-tuned with QLoRA. Deployed to Hugging Face Spaces with ZeroGPU (no cloud APIs at inference).
|
| 8 |
+
|
| 9 |
+
## Architecture
|
| 10 |
+
|
| 11 |
+
- `app.py` — Gradio text chat interface using `@spaces.GPU` decorator for ZeroGPU. Loads model via transformers `AutoModelForCausalLM` + `AutoTokenizer`. Text-only (no vision).
|
| 12 |
+
- `training/` — Offline pipeline (runs on EC2 with GPU, not in the Space):
|
| 13 |
+
- `prepare_data.py` — Converts raw markdown docs in `training/data/raw/` into instruction-response JSONL pairs
|
| 14 |
+
- `train.py` — QLoRA fine-tuning (4-bit NF4, LoRA r=16 on q/k/v/o projections)
|
| 15 |
+
- `push_to_hub.py` — Merges adapter into base model and pushes to HF Hub
|
| 16 |
+
|
| 17 |
+
## Commands
|
| 18 |
+
|
| 19 |
+
```bash
|
| 20 |
+
# Run the Gradio app locally (requires GPU or will be very slow on CPU)
|
| 21 |
+
python app.py
|
| 22 |
+
|
| 23 |
+
# Training pipeline (run on GPU instance)
|
| 24 |
+
python training/prepare_data.py # raw docs → training/data/train.jsonl
|
| 25 |
+
pip install -r training/requirements.txt
|
| 26 |
+
python training/train.py # QLoRA fine-tune → training/output/
|
| 27 |
+
python training/push_to_hub.py # merge + push to HF Hub
|
| 28 |
+
```
|
| 29 |
+
|
| 30 |
+
## Deployment
|
| 31 |
+
|
| 32 |
+
Two git remotes:
|
| 33 |
+
- `origin` → GitHub
|
| 34 |
+
- `space` → Hugging Face Space (`git push space main` to deploy)
|
| 35 |
+
|
| 36 |
+
Hardware: ZeroGPU in HF Spaces. No secrets or API keys needed.
|
| 37 |
+
|
| 38 |
+
## Key Configuration
|
| 39 |
+
|
| 40 |
+
- `MODEL_ID` in `app.py` controls which model is loaded at inference (base or fine-tuned)
|
| 41 |
+
- `HUB_REPO` in `training/push_to_hub.py` is the target HF repo for the merged model
|
| 42 |
+
- Training hyperparams in `training/train.py`: epochs=3, batch=2, grad_accum=8, lr=2e-4, max_seq_length=4096
|
README.md
ADDED
|
@@ -0,0 +1,177 @@
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| 1 |
+
---
|
| 2 |
+
title: Tech Advisor
|
| 3 |
+
emoji: 🔧
|
| 4 |
+
colorFrom: blue
|
| 5 |
+
colorTo: green
|
| 6 |
+
sdk: gradio
|
| 7 |
+
sdk_version: "5.0"
|
| 8 |
+
app_file: app.py
|
| 9 |
+
pinned: false
|
| 10 |
+
tags:
|
| 11 |
+
- build-small-hackathon
|
| 12 |
+
- nemotron
|
| 13 |
+
- aws
|
| 14 |
+
- fine-tuning
|
| 15 |
+
- off-the-grid
|
| 16 |
+
---
|
| 17 |
+
|
| 18 |
+
# 🔧 Tech Advisor
|
| 19 |
+
|
| 20 |
+
An AI expert on **AWS DevOps Agent** — fine-tuned on the latest documentation so it knows everything about the service: features, pricing, integrations, getting started, and best practices. Powered by **NVIDIA Llama-3.1-Nemotron-Nano-4B** (~5B params, well under the 32B cap).
|
| 21 |
+
|
| 22 |
+
## What it does
|
| 23 |
+
|
| 24 |
+
1. **Answers AWS DevOps Agent questions** — features, pricing, integrations, architecture, getting started
|
| 25 |
+
2. **Analyzes visuals** — upload console screenshots or architecture diagrams for contextual answers
|
| 26 |
+
3. **Provides accurate details** — trained on official documentation, FAQs, and pricing pages
|
| 27 |
+
|
| 28 |
+
## Tech Stack
|
| 29 |
+
|
| 30 |
+
- **Model**: [NVIDIA Llama-3.1-Nemotron-Nano-4B-v1.1](https://huggingface.co/nvidia/Llama-3.1-Nemotron-Nano-4B-v1.1) — fine-tuned with QLoRA on AWS DevOps Agent docs
|
| 31 |
+
- **Frontend**: Gradio chat interface
|
| 32 |
+
- **Hardware**: Zero GPU (HF Spaces)
|
| 33 |
+
- **Training**: QLoRA (4-bit NF4, LoRA r=16) on AWS EC2 g5.xlarge (A10G)
|
| 34 |
+
- **Training Data**: 66 pages of AWS DevOps Agent User Guide → 1,230 instruction-response pairs
|
| 35 |
+
- **Badge**: Off the Grid — runs fully locally, no cloud APIs at inference 🔌
|
| 36 |
+
|
| 37 |
+
## How to use
|
| 38 |
+
|
| 39 |
+
1. Ask about AWS DevOps Agent (e.g., "What is an Agent Space?", "How much does it cost?")
|
| 40 |
+
2. Get detailed, accurate answers based on the latest documentation
|
| 41 |
+
|
| 42 |
+
## Training Pipeline
|
| 43 |
+
|
| 44 |
+
The model is fine-tuned on AWS documentation using QLoRA, then pushed to HF Hub.
|
| 45 |
+
|
| 46 |
+
```
|
| 47 |
+
training/
|
| 48 |
+
├── prepare_data.py # Convert raw docs → training JSONL
|
| 49 |
+
├── train.py # QLoRA fine-tuning script
|
| 50 |
+
├── push_to_hub.py # Merge adapter + push to HF Hub
|
| 51 |
+
├── requirements.txt # Training dependencies
|
| 52 |
+
└── data/
|
| 53 |
+
├── raw/ # AWS documentation markdown files
|
| 54 |
+
└── train.jsonl # Generated training pairs
|
| 55 |
+
```
|
| 56 |
+
|
| 57 |
+
**Steps:**
|
| 58 |
+
1. Add AWS docs to `training/data/raw/` (one markdown file per topic) ✅ Done
|
| 59 |
+
2. `python training/prepare_data.py` — generate training data
|
| 60 |
+
3. `python training/train.py` — fine-tune on AWS EC2 with GPU
|
| 61 |
+
4. `python training/push_to_hub.py` — push merged model to HF Hub
|
| 62 |
+
5. Update `MODEL_ID` in `app.py` and deploy
|
| 63 |
+
|
| 64 |
+
See [`training/README.md`](training/README.md) for full details.
|
| 65 |
+
|
| 66 |
+
## Setup (Deployment)
|
| 67 |
+
|
| 68 |
+
No API keys or secrets needed — the model runs fully locally on Zero GPU hardware.
|
| 69 |
+
Select "ZeroGPU" as the hardware in your Space settings.
|
| 70 |
+
|
| 71 |
+
## Git Remotes
|
| 72 |
+
|
| 73 |
+
This repo uses two remotes:
|
| 74 |
+
|
| 75 |
+
- `origin` → GitHub: `https://github.com/hugotp-ui/20260607smallmodelshackathon.git`
|
| 76 |
+
- `space` → HF Space: `https://huggingface.co/spaces/build-small-hackathon/tech-advisor`
|
| 77 |
+
|
| 78 |
+
```bash
|
| 79 |
+
git push origin main # GitHub
|
| 80 |
+
git push space main # Deploy to Hugging Face Space
|
| 81 |
+
```
|
| 82 |
+
|
| 83 |
+
## Current Progress
|
| 84 |
+
|
| 85 |
+
- [x] Project scaffolding (Gradio app, training pipeline, README)
|
| 86 |
+
- [x] Raw training data collected (66 AWS DevOps Agent docs — full User Guide)
|
| 87 |
+
- [x] Data preparation script generates 1,230 instruction-response pairs
|
| 88 |
+
- [x] QLoRA training script ready (4-bit NF4, LoRA r=16, 3 epochs)
|
| 89 |
+
- [x] HF Space created under `build-small-hackathon/tech-advisor`
|
| 90 |
+
- [x] GPU instance launched (g5.xlarge, A10G 24GB, us-west-2)
|
| 91 |
+
- [x] Docker training environment built (PyTorch 2.5.1 + CUDA 12.4 + mamba-ssm)
|
| 92 |
+
- [ ] Run fine-tuning on GPU instance
|
| 93 |
+
- [ ] Push merged model to HF Hub
|
| 94 |
+
- [ ] Update `MODEL_ID` in app.py to fine-tuned model
|
| 95 |
+
- [ ] Deploy to HF Space
|
| 96 |
+
- [ ] Record demo video
|
| 97 |
+
- [ ] Social media post
|
| 98 |
+
|
| 99 |
+
## Training Cost
|
| 100 |
+
|
| 101 |
+
| Item | Duration | Cost |
|
| 102 |
+
|------|----------|------|
|
| 103 |
+
| EC2 g5.xlarge (A10G 24GB) | ~2 hours total (includes setup + training) | ~$2.02 |
|
| 104 |
+
| Training time only | 35 minutes | ~$0.59 |
|
| 105 |
+
| EBS storage (100GB gp3) | 2 hours | ~$0.01 |
|
| 106 |
+
| **Total** | | **~$2.03** |
|
| 107 |
+
|
| 108 |
+
g5.xlarge on-demand rate: $1.006/hr in us-west-2. The actual fine-tuning of a 4B model with QLoRA costs under $1 in compute.
|
| 109 |
+
|
| 110 |
+
## Training Infrastructure
|
| 111 |
+
|
| 112 |
+
- **Instance**: g5.xlarge (NVIDIA A10G, 24GB VRAM) in us-west-2
|
| 113 |
+
- **Instance ID**: `i-0249ed98db8a6480b`
|
| 114 |
+
- **AMI**: Deep Learning OSS Nvidia Driver AMI GPU PyTorch 2.7 (Ubuntu 22.04) — `ami-0ca70308d230e8a6e`
|
| 115 |
+
- **SSH**: `ssh -i ~/.ssh/hackathon-gpu.pem ubuntu@54.69.43.246`
|
| 116 |
+
- **Runtime**: PyTorch 2.7 + CUDA 12.8 (pre-installed via `/opt/pytorch`)
|
| 117 |
+
|
| 118 |
+
## Reproducible Setup Commands
|
| 119 |
+
|
| 120 |
+
```bash
|
| 121 |
+
# 1. Create EC2 key pair
|
| 122 |
+
aws ec2 create-key-pair --key-name hackathon-gpu --query 'KeyMaterial' --output text > ~/.ssh/hackathon-gpu.pem
|
| 123 |
+
chmod 400 ~/.ssh/hackathon-gpu.pem
|
| 124 |
+
|
| 125 |
+
# 2. Create security group with SSH access
|
| 126 |
+
aws ec2 create-security-group --group-name hackathon-gpu-sg --description "SSH access for hackathon GPU training"
|
| 127 |
+
aws ec2 authorize-security-group-ingress --group-id <sg-id> --protocol tcp --port 22 --cidr 0.0.0.0/0
|
| 128 |
+
|
| 129 |
+
# 3. Launch g5.xlarge instance
|
| 130 |
+
aws ec2 run-instances \
|
| 131 |
+
--image-id ami-0ca70308d230e8a6e \
|
| 132 |
+
--instance-type g5.xlarge \
|
| 133 |
+
--key-name hackathon-gpu \
|
| 134 |
+
--security-group-ids <sg-id> \
|
| 135 |
+
--block-device-mappings '[{"DeviceName":"/dev/sda1","Ebs":{"VolumeSize":100,"VolumeType":"gp3"}}]' \
|
| 136 |
+
--tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=hackathon-training}]'
|
| 137 |
+
|
| 138 |
+
# 4. Copy project files to instance
|
| 139 |
+
scp -i ~/.ssh/hackathon-gpu.pem -r ./ ubuntu@<instance-ip>:~/hackathon/
|
| 140 |
+
|
| 141 |
+
# 5. SSH in
|
| 142 |
+
ssh -i ~/.ssh/hackathon-gpu.pem ubuntu@<instance-ip>
|
| 143 |
+
|
| 144 |
+
# 6. Build Docker training image
|
| 145 |
+
cd ~/hackathon
|
| 146 |
+
docker build -t hackathon-train -f Dockerfile .
|
| 147 |
+
|
| 148 |
+
# 7. Run training in Docker
|
| 149 |
+
docker run --gpus all --rm -v ~/hackathon/20260607smallmodelshackathon:/workspace hackathon-train \
|
| 150 |
+
bash -c "cd /workspace && python training/train.py"
|
| 151 |
+
|
| 152 |
+
# 8. Push merged model to HF Hub
|
| 153 |
+
docker run --gpus all --rm -v ~/hackathon/20260607smallmodelshackathon:/workspace hackathon-train \
|
| 154 |
+
bash -c "cd /workspace && huggingface-cli login --token <HF_TOKEN> && python training/push_to_hub.py"
|
| 155 |
+
```
|
| 156 |
+
|
| 157 |
+
### Dockerfile
|
| 158 |
+
|
| 159 |
+
```dockerfile
|
| 160 |
+
FROM pytorch/pytorch:2.5.1-cuda12.4-cudnn9-devel
|
| 161 |
+
|
| 162 |
+
WORKDIR /workspace
|
| 163 |
+
|
| 164 |
+
RUN pip install --no-cache-dir packaging ninja
|
| 165 |
+
ENV TORCH_CUDA_ARCH_LIST="8.6"
|
| 166 |
+
RUN pip install --no-cache-dir --no-build-isolation causal-conv1d
|
| 167 |
+
RUN pip install --no-cache-dir --no-build-isolation mamba-ssm
|
| 168 |
+
RUN pip install --no-cache-dir transformers peft trl bitsandbytes datasets accelerate
|
| 169 |
+
```
|
| 170 |
+
|
| 171 |
+
## Demo
|
| 172 |
+
|
| 173 |
+
<!-- Link to demo video here -->
|
| 174 |
+
|
| 175 |
+
## Social Post
|
| 176 |
+
|
| 177 |
+
<!-- Link to social media post here -->
|
app.py
ADDED
|
@@ -0,0 +1,87 @@
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| 1 |
+
import gradio as gr
|
| 2 |
+
import spaces
|
| 3 |
+
import torch
|
| 4 |
+
from transformers import AutoModelForCausalLM, AutoTokenizer
|
| 5 |
+
|
| 6 |
+
# --- Configuration ---
|
| 7 |
+
MODEL_ID = "aslanconfig/tech-advisor-nemotron-4b"
|
| 8 |
+
|
| 9 |
+
SYSTEM_PROMPT = """/no_think
|
| 10 |
+
You are Tech Advisor, an expert on AWS cloud services with deep knowledge of AWS DevOps Agent.
|
| 11 |
+
|
| 12 |
+
You have comprehensive knowledge of AWS DevOps Agent including:
|
| 13 |
+
- What it is and how it works (Agent Spaces, topology, dual-console architecture)
|
| 14 |
+
- Key features: autonomous incident response, proactive prevention, on-demand SRE tasks
|
| 15 |
+
- Integrations: CloudWatch, Datadog, Dynatrace, New Relic, Splunk, Grafana, PagerDuty, GitHub, GitLab, Azure DevOps, ServiceNow, Slack
|
| 16 |
+
- GA features: Azure/on-prem support, Triage Agent, Learned/Custom Skills, Code Indexing, Private Connections
|
| 17 |
+
- Pricing: $0.0083 per agent-second, free trial details, AWS Support credits
|
| 18 |
+
- Getting started: Agent Spaces, connecting tools, running investigations
|
| 19 |
+
- Security: encryption, customer managed keys, IdP integration, CloudTrail auditing
|
| 20 |
+
- Available regions: US East, US West, Frankfurt, Ireland, Sydney, Tokyo
|
| 21 |
+
|
| 22 |
+
Be concise and structured. Use bullet points where appropriate. Provide accurate, detailed answers."""
|
| 23 |
+
|
| 24 |
+
|
| 25 |
+
# --- Load model ---
|
| 26 |
+
tokenizer = AutoTokenizer.from_pretrained(MODEL_ID)
|
| 27 |
+
model = AutoModelForCausalLM.from_pretrained(
|
| 28 |
+
MODEL_ID,
|
| 29 |
+
torch_dtype=torch.bfloat16,
|
| 30 |
+
device_map="auto",
|
| 31 |
+
).eval()
|
| 32 |
+
|
| 33 |
+
|
| 34 |
+
@spaces.GPU
|
| 35 |
+
def respond(message: str, history: list[dict]) -> str:
|
| 36 |
+
"""Generate a response using the fine-tuned Llama-3.1-Nemotron-Nano-4B."""
|
| 37 |
+
|
| 38 |
+
messages = [{"role": "system", "content": SYSTEM_PROMPT}]
|
| 39 |
+
|
| 40 |
+
for msg in history:
|
| 41 |
+
messages.append(msg)
|
| 42 |
+
|
| 43 |
+
messages.append({"role": "user", "content": message})
|
| 44 |
+
|
| 45 |
+
inputs = tokenizer.apply_chat_template(
|
| 46 |
+
messages, return_tensors="pt", add_generation_prompt=True
|
| 47 |
+
).to(model.device)
|
| 48 |
+
|
| 49 |
+
with torch.no_grad():
|
| 50 |
+
generated_ids = model.generate(
|
| 51 |
+
inputs,
|
| 52 |
+
max_new_tokens=2048,
|
| 53 |
+
do_sample=True,
|
| 54 |
+
temperature=0.3,
|
| 55 |
+
top_p=0.9,
|
| 56 |
+
eos_token_id=tokenizer.eos_token_id,
|
| 57 |
+
)
|
| 58 |
+
|
| 59 |
+
output_text = tokenizer.decode(
|
| 60 |
+
generated_ids[0][inputs.shape[1]:],
|
| 61 |
+
skip_special_tokens=True,
|
| 62 |
+
)
|
| 63 |
+
|
| 64 |
+
return output_text
|
| 65 |
+
|
| 66 |
+
|
| 67 |
+
# --- Gradio UI ---
|
| 68 |
+
demo = gr.ChatInterface(
|
| 69 |
+
fn=respond,
|
| 70 |
+
type="messages",
|
| 71 |
+
title="🔧 Tech Advisor",
|
| 72 |
+
description=(
|
| 73 |
+
"Ask about AWS DevOps Agent — features, pricing, integrations, getting started, "
|
| 74 |
+
"and best practices. Powered by a fine-tuned Llama-3.1-Nemotron-Nano-4B. "
|
| 75 |
+
"No cloud APIs. 🔌 Off the Grid."
|
| 76 |
+
),
|
| 77 |
+
examples=[
|
| 78 |
+
"What is AWS DevOps Agent and how does it work?",
|
| 79 |
+
"How much does AWS DevOps Agent cost? What's included in the free trial?",
|
| 80 |
+
"What observability tools does AWS DevOps Agent integrate with?",
|
| 81 |
+
"How do I get started with AWS DevOps Agent? What's an Agent Space?",
|
| 82 |
+
],
|
| 83 |
+
theme=gr.themes.Soft(),
|
| 84 |
+
)
|
| 85 |
+
|
| 86 |
+
if __name__ == "__main__":
|
| 87 |
+
demo.launch()
|
requirements.txt
ADDED
|
@@ -0,0 +1,5 @@
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| 1 |
+
gradio>=4.0
|
| 2 |
+
torch
|
| 3 |
+
transformers>=4.44
|
| 4 |
+
accelerate
|
| 5 |
+
spaces
|
training/README.md
ADDED
|
@@ -0,0 +1,65 @@
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| 1 |
+
# Training Pipeline
|
| 2 |
+
|
| 3 |
+
Fine-tune Nemotron Nano 12B v2 VL on AWS service documentation so the model has built-in knowledge of new/recent AWS services and features.
|
| 4 |
+
|
| 5 |
+
## Overview
|
| 6 |
+
|
| 7 |
+
- **Base model**: `nvidia/NVIDIA-Nemotron-Nano-12B-v2-VL-BF16`
|
| 8 |
+
- **Method**: QLoRA (4-bit quantization + LoRA adapters)
|
| 9 |
+
- **Data**: AWS documentation converted to instruction-response pairs
|
| 10 |
+
- **Target**: Push fine-tuned model to HF Hub for deployment
|
| 11 |
+
|
| 12 |
+
## Directory Structure
|
| 13 |
+
|
| 14 |
+
```
|
| 15 |
+
training/
|
| 16 |
+
├── prepare_data.py # Convert raw docs → training JSONL
|
| 17 |
+
├── train.py # QLoRA fine-tuning script
|
| 18 |
+
├── push_to_hub.py # Merge adapter + push to HF Hub
|
| 19 |
+
├── requirements.txt # Training dependencies
|
| 20 |
+
└── data/
|
| 21 |
+
├── raw/ # Put AWS documentation markdown files here
|
| 22 |
+
└── train.jsonl # Generated training data (output of prepare_data.py)
|
| 23 |
+
```
|
| 24 |
+
|
| 25 |
+
## Steps
|
| 26 |
+
|
| 27 |
+
### 1. Gather AWS documentation
|
| 28 |
+
|
| 29 |
+
Add markdown files to `training/data/raw/`. One file per service or feature:
|
| 30 |
+
|
| 31 |
+
```
|
| 32 |
+
training/data/raw/
|
| 33 |
+
├── amazon-q.md
|
| 34 |
+
├── s3-express-one-zone.md
|
| 35 |
+
├── aurora-serverless-v2.md
|
| 36 |
+
├── bedrock.md
|
| 37 |
+
└── ...
|
| 38 |
+
```
|
| 39 |
+
|
| 40 |
+
### 2. Generate training data
|
| 41 |
+
|
| 42 |
+
```bash
|
| 43 |
+
python training/prepare_data.py
|
| 44 |
+
```
|
| 45 |
+
|
| 46 |
+
This reads the raw docs and creates `training/data/train.jsonl` with instruction-response pairs.
|
| 47 |
+
|
| 48 |
+
### 3. Train on AWS (EC2 with GPU)
|
| 49 |
+
|
| 50 |
+
```bash
|
| 51 |
+
pip install -r training/requirements.txt
|
| 52 |
+
python training/train.py
|
| 53 |
+
```
|
| 54 |
+
|
| 55 |
+
Recommended: `g5.2xlarge` (A10G, 24GB VRAM) or `p3.2xlarge` (V100, 16GB).
|
| 56 |
+
|
| 57 |
+
### 4. Push to Hugging Face Hub
|
| 58 |
+
|
| 59 |
+
```bash
|
| 60 |
+
python training/push_to_hub.py
|
| 61 |
+
```
|
| 62 |
+
|
| 63 |
+
### 5. Update app.py
|
| 64 |
+
|
| 65 |
+
Change `MODEL_ID` in `app.py` to point at your fine-tuned model.
|
training/data/raw/about-aws-devops-agent-agent-instructions.md
ADDED
|
@@ -0,0 +1,103 @@
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| 1 |
+
# Agent instructions
|
| 2 |
+
|
| 3 |
+
Use agent instructions to provide always-on guidance that AWS DevOps Agent applies to every session. A session is a single conversation or investigation with an agent. On the **Knowledge** page in your Agent Space Operator Web App, choose the **Instructions** tab to set instructions that apply to all agents, or set instructions for a specific managed agent such as Chat or Incident triage. These instructions are stored as an AGENTS.md file. Unlike DevOps Agent Skills, which load on demand when the agent matches a skill description to the current task, agent instructions are always present from the start of every session, regardless of what the agent is working on.
|
| 4 |
+
|
| 5 |
+
## What are agent instructions
|
| 6 |
+
|
| 7 |
+
Agent instructions provide unconditional, always-on guidance for your agents. At the start of every session, the agent service retrieves the instructions configured for your Agent Space and injects their content directly into the agent system prompt. The agent does not decide whether to load them; they are always present.
|
| 8 |
+
|
| 9 |
+
Each agent session receives instructions from both the global instructions and the relevant agent-specific instructions.
|
| 10 |
+
|
| 11 |
+
Agent instructions are stored as AGENTS.md files and differ from DevOps Agent Skills in several important ways:
|
| 12 |
+
|
| 13 |
+
| Aspect | Skill | Agent instructions (AGENTS.md) |
|
| 14 |
+
| --- | --- | --- |
|
| 15 |
+
| Name and description | Required | Not applicable |
|
| 16 |
+
| Content format | Markdown or ZIP bundle | Markdown only |
|
| 17 |
+
| Resource files | Supported | Not supported |
|
| 18 |
+
| Context injection | On demand (agent decides via skill description matching) | Always (unconditional, every session) |
|
| 19 |
+
| Uniqueness | Multiple per Agent Space | One per agent |
|
| 20 |
+
|
| 21 |
+
## Why use agent instructions
|
| 22 |
+
|
| 23 |
+
Agent instructions give you a reliable way to ensure certain guidance is always in context, without depending on the agent's skill-loading decisions.
|
| 24 |
+
|
| 25 |
+
**Key benefits:**
|
| 26 |
+
+ **Predictability:** Instructions are always present, regardless of what task the agent is working on.
|
| 27 |
+
+ **Guaranteed coverage:** Unlike Skills, which the agent may or may not load depending on task relevance, agent instructions are always injected at the start of every session.
|
| 28 |
+
+ **Standing policies:** Use agent instructions for standing operational policies, security guidelines, coding standards, or any guidance that must apply to every session without exception.
|
| 29 |
+
+ **Targeted scope:** You can apply instructions to all agent types at once using global instructions, or restrict instructions to a specific agent type.
|
| 30 |
+
|
| 31 |
+
## How agent instructions work
|
| 32 |
+
|
| 33 |
+
When a session starts, the agent service retrieves the instructions configured for your Agent Space and injects their content into the agent system prompt before the session begins. This happens automatically for every session.
|
| 34 |
+
|
| 35 |
+
Each new session loads the instructions fresh at startup. If you update your instructions, the change takes effect immediately for sessions that start after you save.
|
| 36 |
+
|
| 37 |
+
## Agent type scoping
|
| 38 |
+
|
| 39 |
+
Scoping controls which agent sessions receive a given set of instructions:
|
| 40 |
+
+ **Global instructions:** Applies to all agent types in your Agent Space.
|
| 41 |
+
+ **Agent-specific:** Applies only to sessions of the selected agent type.
|
| 42 |
+
|
| 43 |
+
The managed agents available for agent-specific instructions are:
|
| 44 |
+
+ **Chat** - Ad-hoc questions and requests during chat sessions.
|
| 45 |
+
+ **Incident triage** - Alarm filtering, severity classification, and initial scoping.
|
| 46 |
+
+ **Incident RCA** - Root cause analysis with evidence collection and validation.
|
| 47 |
+
+ **Incident mitigation** - Short-term remediation and long-term fix recommendations.
|
| 48 |
+
+ **Evaluation** - Agent performance scoring and policy compliance checks.
|
| 49 |
+
|
| 50 |
+
## Content size guidance
|
| 51 |
+
|
| 52 |
+
+ **Hard limit:** 25 KB
|
| 53 |
+
+ **Recommended size:** 120 lines
|
| 54 |
+
|
| 55 |
+
Focus your instructions on guidance that must be present in every session. For specialized investigation procedures, consider using DevOps Agent Skills instead.
|
| 56 |
+
|
| 57 |
+
## Example
|
| 58 |
+
|
| 59 |
+
```
|
| 60 |
+
# Agent Instructions
|
| 61 |
+
|
| 62 |
+
## Investigation approach
|
| 63 |
+
- Always check CloudWatch alarms and recent deployments before proposing a root cause.
|
| 64 |
+
|
| 65 |
+
## Response format
|
| 66 |
+
- Lead with a one-sentence summary of findings before listing details.
|
| 67 |
+
- Include the AWS region and resource identifier for any resource you reference.
|
| 68 |
+
- Use bullet points for lists of findings or recommendations.
|
| 69 |
+
|
| 70 |
+
## Security
|
| 71 |
+
- Never log, display, or suggest storing credentials or secrets in plaintext.
|
| 72 |
+
- When recommending IAM changes, follow least-privilege principles.
|
| 73 |
+
```
|
| 74 |
+
|
| 75 |
+
## Setting agent instructions
|
| 76 |
+
|
| 77 |
+
Each agent has exactly one set of instructions. When you save new content, it overwrites the existing content for that agent.
|
| 78 |
+
|
| 79 |
+
**To set global instructions (applies to all agents):**
|
| 80 |
+
1. Navigate to the **Knowledge** page in your Agent Space Operator Web App.
|
| 81 |
+
2. Choose the **Instructions** tab.
|
| 82 |
+
3. Choose **View** next to **All agents**.
|
| 83 |
+
4. Enter your markdown instructions in the editor.
|
| 84 |
+
5. Choose **Save**.
|
| 85 |
+
|
| 86 |
+
**To set instructions for a specific agent:**
|
| 87 |
+
1. Navigate to the **Knowledge** page in your Agent Space Operator Web App.
|
| 88 |
+
2. Choose the **Instructions** tab.
|
| 89 |
+
3. Choose **View** next to the agent you want to configure.
|
| 90 |
+
4. Enter your markdown instructions in the editor.
|
| 91 |
+
5. Choose **Save**.
|
| 92 |
+
|
| 93 |
+
## Managing agent instructions
|
| 94 |
+
|
| 95 |
+
**Viewing instructions:** Navigate to the **Knowledge** page, choose the **Instructions** tab, and choose **View** next to the agent.
|
| 96 |
+
|
| 97 |
+
**Editing instructions:** Open the agent, modify the content, and choose **Save**.
|
| 98 |
+
|
| 99 |
+
**Uploading instructions from a file:** Choose the **Upload** button to upload a markdown file.
|
| 100 |
+
|
| 101 |
+
**Downloading instructions:** Choose the **Download** button to download the current content.
|
| 102 |
+
|
| 103 |
+
**Deleting instructions:** Choose the **Delete** button and confirm the deletion.
|
training/data/raw/about-aws-devops-agent-devops-agent-memories.md
ADDED
|
@@ -0,0 +1,98 @@
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| 1 |
+
# DevOps Agent Memories
|
| 2 |
+
|
| 3 |
+
Memories are informational knowledge items that AWS DevOps Agent builds and maintains to supplement its capabilities with synthesized, high-signal context specific to your Agent Space. Unlike DevOps Agent Skills, which encode procedural knowledge and extend agent capabilities, memories encode informational knowledge that helps agents make faster and more accurate decisions during investigations.
|
| 4 |
+
|
| 5 |
+
## What are memories
|
| 6 |
+
|
| 7 |
+
A *memory* is a single markdown file that captures synthesized information relevant to your Agent Space. Examples include recurring root causes for a specific alarm, known environmental quirks, or user-specific preferences. Memories do not extend agent capabilities; they provide context the agent uses to make better decisions.
|
| 8 |
+
|
| 9 |
+
A *memory store* is a collection of related memory files. Each memory store has a name and description that agents use to decide whether to browse its contents. Memory stores are the organizational containers that group memories by topic.
|
| 10 |
+
|
| 11 |
+
Memories differ from other knowledge item types in key ways:
|
| 12 |
+
|
| 13 |
+
| Aspect | Skill | Agent instructions | Memory |
|
| 14 |
+
| --- | --- | --- | --- |
|
| 15 |
+
| Knowledge type | Procedural (instructions) | Procedural (always-on instructions) | Informational (synthesized context) |
|
| 16 |
+
| Content format | Markdown or ZIP bundle | Markdown only | Markdown only |
|
| 17 |
+
| Context injection | On demand (agent decides via description matching) | Always (every session) | On demand (agent decides via description matching) |
|
| 18 |
+
| Created by | User (UI, CLI), DevOps Agent | User (UI, CLI) | User (via Chat), DevOps Agent (Learning agent) |
|
| 19 |
+
|
| 20 |
+
## Why use memories
|
| 21 |
+
|
| 22 |
+
Memories give agents access to historical patterns and environmental knowledge that would otherwise be lost between sessions.
|
| 23 |
+
|
| 24 |
+
**Key benefits:**
|
| 25 |
+
+ **Faster investigations** - Agents recall recent root causes for specific monitors, avoiding redundant diagnostic steps when a recurring issue fires again.
|
| 26 |
+
+ **Environmental awareness** - Memories capture environment-specific details such as known noisy alarms, infrastructure quirks, or component relationships that are difficult to re-discover each session.
|
| 27 |
+
+ **Continuous improvement** - As the DevOps Agent resolves more incidents, it automatically builds a richer knowledge base of patterns and root causes specific to your infrastructure.
|
| 28 |
+
+ **User preferences** - Memories record communication preferences and directives so the agent consistently behaves according to your expectations.
|
| 29 |
+
|
| 30 |
+
## How memories work
|
| 31 |
+
|
| 32 |
+
When an agent session starts, the agent receives a list of memory stores with their names and descriptions. During an investigation, the agent evaluates whether a memory store is relevant to the current task. If it is, the agent lists the memories within that store and reads the specific memory files it needs. This progressive-disclosure pattern keeps context consumption low while making all relevant knowledge accessible.
|
| 33 |
+
|
| 34 |
+
Each memory is versioned. Every update creates a new immutable version, enabling audit trails and rollback to previous content.
|
| 35 |
+
|
| 36 |
+
## Managed memory stores
|
| 37 |
+
|
| 38 |
+
DevOps Agent creates and maintains the following managed memory stores automatically as it learns from sessions in your Agent Space:
|
| 39 |
+
|
| 40 |
+
### monitors
|
| 41 |
+
|
| 42 |
+
Per-monitor recurring root cause history. Each memory file corresponds to a specific monitor (alarm or metric) and lists the cause categories that have produced incidents for that alarm, with per-investigation evidence. Agents read the entry matching the firing alarm before triaging to quickly identify whether the current incident matches a known pattern.
|
| 43 |
+
|
| 44 |
+
When there are investigations in the past 2 weeks in the Agent Space, a Learning agent runs once per day to analyze recent investigations, then extract and store memories in this store. Memory items in this store are deleted when they have no updates for 2 weeks.
|
| 45 |
+
|
| 46 |
+
### directives
|
| 47 |
+
|
| 48 |
+
User-authored directives that steer agent behavior. Use this store to record standing instructions the agent should follow, such as infrastructure conventions or naming preferences.
|
| 49 |
+
|
| 50 |
+
Examples:
|
| 51 |
+
+ "Lambdas are no longer used. The service uses Fargate."
|
| 52 |
+
+ "The storage service is called Orders Storage Service."
|
| 53 |
+
|
| 54 |
+
## Viewing memories
|
| 55 |
+
|
| 56 |
+
You can view all memory stores and their contents from the **Knowledge** page in your Agent Space Operator Web App.
|
| 57 |
+
|
| 58 |
+
**To view memory stores:**
|
| 59 |
+
1. Navigate to the **Knowledge** page in your Agent Space Operator Web App.
|
| 60 |
+
2. Choose the **Memories** tab.
|
| 61 |
+
3. Browse the list of managed memory stores.
|
| 62 |
+
|
| 63 |
+
**To view memories within a store:**
|
| 64 |
+
1. On the **Memories** tab, choose **View** next to the memory store you want to explore.
|
| 65 |
+
2. The store detail page lists all memories with their name, description, version number, and last modified date.
|
| 66 |
+
|
| 67 |
+
**To view a specific memory:**
|
| 68 |
+
1. From the store detail page, choose **View** next to the memory you want to read.
|
| 69 |
+
2. The memory detail page displays the rendered markdown content along with creation date, last modified date, and a version selector.
|
| 70 |
+
|
| 71 |
+
## Activating and deactivating memories
|
| 72 |
+
|
| 73 |
+
You can toggle individual memory stores or individual memories active or inactive without deleting them.
|
| 74 |
+
|
| 75 |
+
**To toggle a memory store:**
|
| 76 |
+
1. On the **Memories** tab, use the toggle switch next to the memory store.
|
| 77 |
+
2. When inactive, agents do not access any memories within that store.
|
| 78 |
+
|
| 79 |
+
**To toggle an individual memory:**
|
| 80 |
+
1. Navigate into a memory store to see its list of memories.
|
| 81 |
+
2. Use the toggle switch next to the memory you want to activate or deactivate.
|
| 82 |
+
|
| 83 |
+
## Editing memories with Chat
|
| 84 |
+
|
| 85 |
+
You can create, update, or delete memories by chatting with the DevOps Agent in the Chat interface.
|
| 86 |
+
|
| 87 |
+
**Examples of Chat commands:**
|
| 88 |
+
+ "Remember that the storage service is called Orders Storage Service"
|
| 89 |
+
+ "Update the memory for the canary alarm to note that it is flaky during deployments"
|
| 90 |
+
+ "Delete the memory about the old database connection string"
|
| 91 |
+
|
| 92 |
+
## Memory limits
|
| 93 |
+
|
| 94 |
+
| Resource | Limit |
|
| 95 |
+
| --- | --- |
|
| 96 |
+
| Memory stores per Agent Space | 50 |
|
| 97 |
+
| Memories per memory store | 200 |
|
| 98 |
+
| Individual memory content size | 100 KB |
|
training/data/raw/about-aws-devops-agent-devops-agent-skills.md
ADDED
|
@@ -0,0 +1,255 @@
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| 1 |
+
# DevOps Agent Skills
|
| 2 |
+
|
| 3 |
+
AWS DevOps Agent Skills are modular instruction sets that extend the agent's capabilities with specialized domain knowledge and investigation methodologies tailored to your infrastructure and operational workflows.
|
| 4 |
+
|
| 5 |
+
## What are Skills
|
| 6 |
+
|
| 7 |
+
Skills are self-contained directories containing Markdown instructions that provide specialized capabilities to AWS DevOps Agent. AWS DevOps Agent supports a subset of the Agent Skills specification—an open standard for packaging agent instructions and resources—supporting only non-executable documents: Markdown instructions, PDFs, images, and data files.
|
| 8 |
+
|
| 9 |
+
Every skill requires a SKILL.md file containing instructions you want to provide for your AWS DevOps Agent. In addition to the required SKILL.md file, skills can include:
|
| 10 |
+
+ **Investigation workflows** for specific scenarios or infrastructure types.
|
| 11 |
+
+ **Reference materials** including architecture patterns and operational procedures.
|
| 12 |
+
+ **Agent type targeting** – Skills can be targeted to specific agent types (Generic, On-demand, Incident Triage, Incident RCA, Incident Mitigation, Evaluation) to reduce context consumption and improve agent focus.
|
| 13 |
+
|
| 14 |
+
## Why use Skills
|
| 15 |
+
|
| 16 |
+
Skills transform AWS DevOps Agent from a general-purpose assistant into a specialist for your infrastructure and operational workflows. Unlike one-time instructions provided in a chat message, Skills are reusable capabilities that load automatically when relevant to tasks performed by AWS DevOps Agent.
|
| 17 |
+
|
| 18 |
+
**Key benefits:**
|
| 19 |
+
+ **Specialize your agent** – Tailor AWS DevOps Agent with investigation procedures, best practices, and organizational knowledge specific to your infrastructure and operational patterns.
|
| 20 |
+
+ **Reduce repetition** – Create investigation workflows once and AWS DevOps Agent uses them automatically across all relevant investigations, eliminating the need to provide the same guidance repeatedly.
|
| 21 |
+
+ **Compose capabilities** – Combine multiple Skills to build end-to-end investigation workflows. AWS DevOps Agent reads multiple skills during execution, such as a skill to retrieve deployments from your custom CI/CD pipeline and a skill to search your code repositories.
|
| 22 |
+
+ **Amplify custom tools** – Create skills that guide AWS DevOps Agent in using your custom MCP server tools effectively. Skills can document when to invoke specific tools, what parameters to use for different scenarios, and how to interpret results to accomplish workflows specific to your infrastructure.
|
| 23 |
+
|
| 24 |
+
## How Skills work
|
| 25 |
+
|
| 26 |
+
When AWS DevOps Agent encounters a relevant task, it loads the appropriate skills and follows the instructions to guide its investigation. For example, a "Database Performance Investigation" skill might include step-by-step procedures for analyzing RDS throttling issues, enabling the agent to systematically check alarm status, analyze connection metrics, and identify slow queries.
|
| 27 |
+
|
| 28 |
+
## Skill structure
|
| 29 |
+
|
| 30 |
+
A skill is organized as a directory containing:
|
| 31 |
+
|
| 32 |
+
```
|
| 33 |
+
my-skill/
|
| 34 |
+
├── SKILL.md # Main skill instructions
|
| 35 |
+
├── references/ # Optional: additional reference documentation
|
| 36 |
+
└── assets/ # Optional: images, diagrams, data files
|
| 37 |
+
```
|
| 38 |
+
|
| 39 |
+
### SKILL.md
|
| 40 |
+
|
| 41 |
+
The `SKILL.md` is the only mandatory file. It contains the core instructions written in Markdown format. This file should:
|
| 42 |
+
+ Describe when and how to use the skill.
|
| 43 |
+
+ Provide step-by-step investigation procedures.
|
| 44 |
+
+ Include decision trees for different scenarios.
|
| 45 |
+
+ Document expected outputs and success criteria.
|
| 46 |
+
|
| 47 |
+
### Frontmatter
|
| 48 |
+
|
| 49 |
+
Frontmatter is the metadata block at the top of a `SKILL.md` file, enclosed between `---` delimiters. It contains the `name` and `description` fields that AWS DevOps Agent uses to determine when to activate the Skill during an investigation or task.
|
| 50 |
+
|
| 51 |
+
```
|
| 52 |
+
---
|
| 53 |
+
name: rds-performance-investigation
|
| 54 |
+
description: Investigation procedures for RDS performance issues including
|
| 55 |
+
connection exhaustion, slow queries, replication lag, and storage capacity.
|
| 56 |
+
Use this skill when investigating database latency, connection errors, or
|
| 57 |
+
read/write performance degradation.
|
| 58 |
+
---
|
| 59 |
+
```
|
| 60 |
+
|
| 61 |
+
**name** – A unique identifier for the Skill. Use lowercase letters, numbers, and hyphens only (maximum 64 characters). Must not start or end with a hyphen.
|
| 62 |
+
|
| 63 |
+
**description** – A detailed explanation of when and why AWS DevOps Agent should use this Skill. AWS DevOps Agent evaluates this field to decide whether the Skill is relevant to the current task. A vague or missing description can cause the agent to skip the Skill entirely, even if the instructions are well-written.
|
| 64 |
+
|
| 65 |
+
**Important** – Write the description from the agent's perspective. Include the specific scenarios, services, error types, or symptoms that should trigger the Skill.
|
| 66 |
+
|
| 67 |
+
When you create a Skill in the UI, the system generates frontmatter automatically from the name and description you provide. Skills uploaded as zip files must include frontmatter in the `SKILL.md` file.
|
| 68 |
+
|
| 69 |
+
## Example: Complete skill
|
| 70 |
+
|
| 71 |
+
The following example shows a complete, well-formed skill for investigating RDS performance issues.
|
| 72 |
+
|
| 73 |
+
**Directory structure:**
|
| 74 |
+
|
| 75 |
+
```
|
| 76 |
+
rds-performance-investigation/
|
| 77 |
+
├── SKILL.md
|
| 78 |
+
├── references/
|
| 79 |
+
│ └── rds-metrics-reference.md
|
| 80 |
+
└── assets/
|
| 81 |
+
└── rds-investigation-flowchart.png
|
| 82 |
+
```
|
| 83 |
+
|
| 84 |
+
**SKILL.md:**
|
| 85 |
+
|
| 86 |
+
```
|
| 87 |
+
---
|
| 88 |
+
name: rds-performance-investigation
|
| 89 |
+
description: Investigation procedures for RDS performance issues including
|
| 90 |
+
connection exhaustion, slow queries, replication lag, and storage capacity.
|
| 91 |
+
Use this skill when investigating database latency, connection errors, or
|
| 92 |
+
read/write performance degradation.
|
| 93 |
+
---
|
| 94 |
+
|
| 95 |
+
# RDS Performance Investigation
|
| 96 |
+
|
| 97 |
+
Use this skill when customers report database latency, connection errors,
|
| 98 |
+
query timeouts, or read/write performance degradation.
|
| 99 |
+
|
| 100 |
+
## Step 1: Check alarm status
|
| 101 |
+
|
| 102 |
+
Query CloudWatch for active alarms on the affected RDS instance. Look for:
|
| 103 |
+
- `DatabaseConnections` exceeding 80% of max_connections
|
| 104 |
+
- `ReadLatency` or `WriteLatency` above 20ms
|
| 105 |
+
- `FreeStorageSpace` below 20% of total storage
|
| 106 |
+
- `ReplicaLag` above 30 seconds (read replicas only)
|
| 107 |
+
|
| 108 |
+
## Step 2: Analyze connection metrics
|
| 109 |
+
|
| 110 |
+
Retrieve `DatabaseConnections` over the past hour. If connections are near
|
| 111 |
+
the max_connections limit, check for connection pool misconfiguration or
|
| 112 |
+
long-running idle connections.
|
| 113 |
+
|
| 114 |
+
## Step 3: Identify slow queries
|
| 115 |
+
|
| 116 |
+
Use Performance Insights (`pi:GetResourceMetrics`) to retrieve the top SQL
|
| 117 |
+
statements by average active sessions. Focus on queries with high `db.load`
|
| 118 |
+
contribution or frequent I/O waits.
|
| 119 |
+
|
| 120 |
+
## Step 4: Summarize findings
|
| 121 |
+
|
| 122 |
+
Provide a summary with:
|
| 123 |
+
1. Current performance status (healthy / degraded / critical)
|
| 124 |
+
2. Root cause hypothesis with supporting metrics
|
| 125 |
+
3. Recommended remediation steps ranked by priority
|
| 126 |
+
```
|
| 127 |
+
|
| 128 |
+
**references/rds-metrics-reference.md:**
|
| 129 |
+
|
| 130 |
+
```
|
| 131 |
+
# RDS CloudWatch Metrics Reference
|
| 132 |
+
|
| 133 |
+
| Metric | Normal Range | Investigation Threshold |
|
| 134 |
+
|---|---|---|
|
| 135 |
+
| DatabaseConnections | < 70% max_connections | > 80% max_connections |
|
| 136 |
+
| ReadLatency | < 5ms | > 20ms |
|
| 137 |
+
| WriteLatency | < 5ms | > 20ms |
|
| 138 |
+
| FreeStorageSpace | > 30% total storage | < 20% total storage |
|
| 139 |
+
| ReplicaLag | < 5 seconds | > 30 seconds |
|
| 140 |
+
| CPUUtilization | < 70% | > 85% |
|
| 141 |
+
```
|
| 142 |
+
|
| 143 |
+
## Example: Incident filtering skill
|
| 144 |
+
|
| 145 |
+
Skills targeted to the **Incident Triage** agent type can define criteria for automatically skipping incidents. Use this to filter incidents that don't require investigation.
|
| 146 |
+
|
| 147 |
+
**SKILL.md:**
|
| 148 |
+
|
| 149 |
+
```
|
| 150 |
+
---
|
| 151 |
+
name: skip-scheduled-maintenance
|
| 152 |
+
description: Skip low-priority incidents during a scheduled maintenance window.
|
| 153 |
+
Use this skill to automatically filter MEDIUM and LOW severity alarms that
|
| 154 |
+
fire during planned maintenance, avoiding unnecessary investigations for
|
| 155 |
+
expected disruptions.
|
| 156 |
+
---
|
| 157 |
+
|
| 158 |
+
# Skip Scheduled Maintenance
|
| 159 |
+
|
| 160 |
+
Skip all incidents that meet BOTH of the following criteria:
|
| 161 |
+
|
| 162 |
+
1. The incident arrived between **2025-03-15 02:00 UTC** and **2025-03-15 06:00 UTC**
|
| 163 |
+
2. Severity is MEDIUM or LOW
|
| 164 |
+
|
| 165 |
+
Do NOT skip HIGH or CRITICAL severity incidents, even during the maintenance window.
|
| 166 |
+
```
|
| 167 |
+
|
| 168 |
+
## Creating Skills
|
| 169 |
+
|
| 170 |
+
You can create skills in two ways depending on your workflow preferences and skill complexity.
|
| 171 |
+
|
| 172 |
+
### Creating a skill in the UI
|
| 173 |
+
|
| 174 |
+
Skills created in the AWS DevOps Agent Operator Web App contain a name, description, and instructions in a single SKILL.md file.
|
| 175 |
+
|
| 176 |
+
**To create a skill in the UI:**
|
| 177 |
+
+ Navigate to the **Knowledge** page in your Agent Space Operator Web App and choose the **Skills** tab.
|
| 178 |
+
+ Click "Add skill".
|
| 179 |
+
+ Select "Create skill" from the modal.
|
| 180 |
+
+ Fill out the skill form:
|
| 181 |
+
+ **Name** – Lowercase letters, numbers, and hyphens only (maximum 64 characters). Must not start or end with a hyphen.
|
| 182 |
+
+ **Description** – Brief explanation of when to use this skill (minimum 100 characters recommended, maximum 1,024 characters).
|
| 183 |
+
+ **Status** – Set to Active (default) or Inactive.
|
| 184 |
+
+ **Agent Type** – Select one or more agent types that can use this skill.
|
| 185 |
+
+ **Instructions** – Step-by-step procedures in Markdown format.
|
| 186 |
+
+ Choose "Create" to save the skill.
|
| 187 |
+
|
| 188 |
+
### Uploading a skill
|
| 189 |
+
|
| 190 |
+
Skills uploaded as zip files contain a SKILL.md file plus additional resources such as reference materials or assets.
|
| 191 |
+
|
| 192 |
+
**Skill structure:**
|
| 193 |
+
|
| 194 |
+
```
|
| 195 |
+
my-skill.zip
|
| 196 |
+
├── SKILL.md # Required: main skill instructions
|
| 197 |
+
├── references/ # Optional: reference documentation
|
| 198 |
+
│ ├── architecture.md
|
| 199 |
+
│ └── troubleshooting.md
|
| 200 |
+
└── assets/ # Optional: images, diagrams, data files
|
| 201 |
+
├── topology.png
|
| 202 |
+
└── metrics.csv
|
| 203 |
+
```
|
| 204 |
+
|
| 205 |
+
**To create a skill via zip upload:**
|
| 206 |
+
+ Create a directory with your skill files following the structure above.
|
| 207 |
+
+ Ensure SKILL.md includes proper frontmatter (name and description).
|
| 208 |
+
+ Compress the directory into a .zip file.
|
| 209 |
+
+ Navigate to the **Knowledge** page and choose the **Skills** tab.
|
| 210 |
+
+ Click "Add skill".
|
| 211 |
+
+ Select "Upload skill" from the modal.
|
| 212 |
+
+ Drag and drop your .zip file or choose to browse (ZIP files only, maximum 6 MB).
|
| 213 |
+
+ Select one or more agent types.
|
| 214 |
+
+ Choose "Upload" to add the skill to your Agent Space.
|
| 215 |
+
|
| 216 |
+
### Importing a skill from a repository
|
| 217 |
+
|
| 218 |
+
You can import skills directly from a GitHub repository directory. AWS DevOps Agent fetches the skill content from the repository, extracts the name and description from the SKILL.md frontmatter, and creates the skill in your Agent Space.
|
| 219 |
+
|
| 220 |
+
**Prerequisites:**
|
| 221 |
+
+ A GitHub account associated with your Agent Space.
|
| 222 |
+
+ A GitHub repository containing a valid skill directory with a SKILL.md file at the root.
|
| 223 |
+
|
| 224 |
+
**To import a skill from a repository:**
|
| 225 |
+
+ Navigate to the **Knowledge** page and choose the **Skills** tab.
|
| 226 |
+
+ Click "Add skill".
|
| 227 |
+
+ Select "Import from repository" from the modal.
|
| 228 |
+
+ Enter the GitHub directory URL that contains your SKILL.md file.
|
| 229 |
+
+ Select one or more agent types.
|
| 230 |
+
+ Set the lifecycle status (Active or Inactive).
|
| 231 |
+
+ Click "Import skill".
|
| 232 |
+
|
| 233 |
+
## Sample skills
|
| 234 |
+
|
| 235 |
+
The AWS DevOps Agent Skills samples repository on GitHub contains community-contributed skills you can use as-is or as a starting point for writing your own.
|
| 236 |
+
|
| 237 |
+
## Managing Skills
|
| 238 |
+
|
| 239 |
+
AWS DevOps Agent provides comprehensive skill management capabilities through the Operator Web App:
|
| 240 |
+
|
| 241 |
+
**Listing skills** – View all Skills in your Agent Space on the Knowledge page Skills tab.
|
| 242 |
+
|
| 243 |
+
**Viewing skills** – Choose any skill to see its detail view.
|
| 244 |
+
|
| 245 |
+
**Selecting agents for a skill** – Configure which agent types can use each skill.
|
| 246 |
+
|
| 247 |
+
**Activating and deactivating skills** – Temporarily disable skills without deleting them.
|
| 248 |
+
|
| 249 |
+
**Updating skills** – Modify existing skills based on how they were created.
|
| 250 |
+
|
| 251 |
+
**Deleting skills** – Permanently remove skills from your Agent Space.
|
| 252 |
+
|
| 253 |
+
## Migrating from Runbooks
|
| 254 |
+
|
| 255 |
+
Existing Runbooks are automatically migrated to Skills with no customer action required. When your Agent Space transitions to the Skills model, all Runbooks are converted to Skills and appear in your Skills UI.
|
training/data/raw/about-aws-devops-agent-learned-skills.md
ADDED
|
@@ -0,0 +1,42 @@
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| 1 |
+
# Learned Skills
|
| 2 |
+
|
| 3 |
+
## What Are Learned Skills?
|
| 4 |
+
|
| 5 |
+
Learned skills are structured knowledge files that the DevOps Agent generates from your Agent Space data. Each learned skill encodes a specific type of knowledge that the AWS DevOps Agent uses as it performs tasks. At launch, two learned skills are available: Agent Space Understanding and Tool Use Best Practices.
|
| 6 |
+
|
| 7 |
+
### Agent Space Understanding
|
| 8 |
+
|
| 9 |
+
The Agent Space Understanding skill (`understanding-agent-space`) analyzes your connected cloud accounts, code repositories, and telemetry integrations to build a map of the resources and relationships in an Agent Space.
|
| 10 |
+
|
| 11 |
+
The skill produces a main `SKILL.md` file and a set of reference files. The main file contains a plain-language system overview with key domain concepts, the deployment environments (AWS account and region pairs, Azure subscriptions and regions, and so on), a container-level architecture diagram showing how logical services connect, the request paths that are central to your application with the components they traverse, and a mapping of code repositories to containers.
|
| 12 |
+
|
| 13 |
+
Each logical container receives a dedicated reference file describing its internal components (compute, data, messaging, network, and others) with resource types and physical identifiers such as ARNs, table names, and queue URLs. The reference file also captures observability coverage, including the alarms, dashboards, and monitors linked to each component. It also maps each component to its associated code repositories, packages, and infrastructure-as-code definitions, providing a complete traceability chain from source code to deployed resources.
|
| 14 |
+
|
| 15 |
+
Each critical request path receives a dedicated reference file describing the full end-to-end request flow at component granularity, from the entry point through each intermediate service, data store, and external dependency. The file includes a sequenced flow diagram showing the order of operations and interaction mechanisms between components, along with the responsibility of each participant. It also catalogs the observability signals relevant to the path: log group patterns for each hop, key metrics (latency, error rates, throttling, token quotas) with their alarm names and dimensions, and distributed trace spans that can be correlated across services and accounts.
|
| 16 |
+
|
| 17 |
+
### Tool Use Best Practices
|
| 18 |
+
|
| 19 |
+
The Tool Use Best Practices skill analyzes past investigation tool uses to extract effective usage patterns, common failure modes, and parameter guidance. This helps the DevOps Agent avoid known pitfalls and run investigations with fewer wasted steps. The skill produces a main file and a set of per-tool reference files. The main file serves as a routing index that lists each tool with the investigation scenarios it supports and links to the corresponding reference file.
|
| 20 |
+
|
| 21 |
+
Each per-tool reference file can include up to three sections:
|
| 22 |
+
+ **Best Practices** — Investigation-driven techniques extracted from successful tool usage, such as CloudWatch Logs Insights query templates, environment-specific metric namespaces and dimensions, and CloudTrail event source filters.
|
| 23 |
+
+ **Common Errors** — Recurring failure modes and their fixes. Each entry describes a specific error condition and provides a corrective action so the agent can avoid or recover from the error without wasting investigation steps.
|
| 24 |
+
+ **Output Management** — Guidance for tool calls that tend to return large responses. Each entry describes a parameter change or processing strategy that reduces output size while preserving diagnostic value.
|
| 25 |
+
|
| 26 |
+
When live infrastructure access is available, the skill validates patterns against your environment before including them. Confirmed patterns are stated with confidence, unconfirmed patterns use cautious language, and disproved patterns are excluded.
|
| 27 |
+
|
| 28 |
+
## Managing Learned Skills
|
| 29 |
+
|
| 30 |
+
**Updates** — The DevOps Agent automatically generates and updates learned skills based on activity in your Agent Space.
|
| 31 |
+
|
| 32 |
+
The DevOps Agent generates an updated **Tool Use Best Practices** skill every 30 investigations.
|
| 33 |
+
|
| 34 |
+
The **Agent Space Understanding** skill is generated by the learning agent, which runs whenever you add, update, or remove an Agent Space capability or integration. It is also periodically refreshed every 3 days for active Agent Spaces. An Agent Space is considered active if it has had at least one investigation in the last 30 days. If your Agent Space has no investigations for 30 days, skill refresh pauses automatically. It resumes when a new investigation starts.
|
| 35 |
+
|
| 36 |
+
To regenerate learned skills manually, choose the **Regenerate** button on the Topology page in the operator app, or chat with the agent and ask it to update the learned skills.
|
| 37 |
+
|
| 38 |
+
**Deactivation** — Learned skills are active by default. When active, the DevOps Agent loads them at the start of each DevOps Agent task. To stop a learned skill from being applied, deactivate it from the **Knowledge** page **Skills** tab in the operator app.
|
| 39 |
+
|
| 40 |
+
**Topology view** — The Topology page in your Agent Space's web app uses the Agent Space Understanding Skill to visually display your Agent Space environment as logical containers and components.
|
| 41 |
+
|
| 42 |
+
**Summary report** — The summary report is a versioned, read-only view of what the DevOps Agent knows about your environment, derived from the Agent Space Understanding skill. You can find it in two places: the **Summary report** tab on the Agent Space details page in the AWS DevOps Agent admin console, and the **Artifacts** section of the DevOps Agent web app.
|
training/data/raw/about-aws-devops-agent-managing-assets.md
ADDED
|
@@ -0,0 +1,112 @@
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| 1 |
+
# Managing Assets
|
| 2 |
+
|
| 3 |
+
AWS DevOps Agent stores the configuration and reference material for an Agent Space as **assets**, the customer-managed resources that shape what the agent knows and how it behaves. Skills, AGENTS.md files, and attachments are all assets, and you can create, read, update, and delete them programmatically through the Asset API.
|
| 4 |
+
|
| 5 |
+
## When to use the Asset API
|
| 6 |
+
|
| 7 |
+
The Operator Web App is the fastest way to author a single skill or upload an AGENTS.md file interactively. The Asset API exposes the same operations programmatically so that scripts and automation can manage assets without going through the Web App. Common reasons to call the Asset API directly include:
|
| 8 |
+
+ Authoring or updating an asset from a script, terminal, or notebook instead of the Web App.
|
| 9 |
+
+ Bulk-loading a starter set of skills or AGENTS.md files into a new Agent Space.
|
| 10 |
+
+ Reading an asset's contents to back it up or compare versions.
|
| 11 |
+
|
| 12 |
+
Every operation in the Asset API is exposed through the AWS CLI as `aws devops-agent <operation>` and through the AWS SDKs as the `devops-agent` client.
|
| 13 |
+
|
| 14 |
+
## Asset API operations
|
| 15 |
+
|
| 16 |
+
| Operation | Description | IAM action | Resource |
|
| 17 |
+
| --- | --- | --- | --- |
|
| 18 |
+
| ListAssetTypes | List the asset types supported by AWS DevOps Agent. | aidevops:ListAssetTypes | * |
|
| 19 |
+
| CreateAsset | Create a new asset in an Agent Space. | aidevops:CreateAsset | Agent Space |
|
| 20 |
+
| GetAsset | Retrieve an asset's metadata and version information. | aidevops:GetAsset | Agent Space |
|
| 21 |
+
| UpdateAsset | Update the metadata or content of an existing asset. | aidevops:UpdateAsset | Agent Space |
|
| 22 |
+
| DeleteAsset | Delete an asset and all of its files from an Agent Space. | aidevops:DeleteAsset | Agent Space |
|
| 23 |
+
| ListAssets | List assets in an Agent Space, with optional filtering. | aidevops:ListAssets | Agent Space |
|
| 24 |
+
| ListAssetVersions | List the historical versions of an asset. | aidevops:ListAssetVersions | Agent Space |
|
| 25 |
+
| GetAssetContent | Download an asset's full content as a zip bundle. | aidevops:GetAssetContent | Agent Space |
|
| 26 |
+
| CreateAssetFile | Add a new file to an existing asset. | aidevops:CreateAssetFile | Agent Space |
|
| 27 |
+
| GetAssetFile | Retrieve a single file from an asset by its path. | aidevops:GetAssetFile | Agent Space |
|
| 28 |
+
| UpdateAssetFile | Replace the content or metadata of an existing file. | aidevops:UpdateAssetFile | Agent Space |
|
| 29 |
+
| DeleteAssetFile | Remove a single file from an asset. | aidevops:DeleteAssetFile | Agent Space |
|
| 30 |
+
| ListAssetFiles | List the files within an asset. | aidevops:ListAssetFiles | Agent Space |
|
| 31 |
+
|
| 32 |
+
## Asset types
|
| 33 |
+
|
| 34 |
+
Every asset has an `assetType` string that identifies what kind of resource it is. Three asset types can be created through the Asset API: `skill`, `agents_md`, and `attachment`.
|
| 35 |
+
|
| 36 |
+
### skill
|
| 37 |
+
|
| 38 |
+
A `skill` asset packages instructions and reference material that the agent loads when relevant. A simple skill is a single `SKILL.md` file; a complex skill is a zip bundle.
|
| 39 |
+
|
| 40 |
+
**Required metadata properties:**
|
| 41 |
+
+ **name** (string) – A unique identifier for the skill. Lowercase letters, numbers, and hyphens only, 1-64 characters.
|
| 42 |
+
+ **description** (string) – A 1-1024 character explanation of when the agent should use the skill.
|
| 43 |
+
+ **agent_types** (array of strings) – One or more agent types this skill applies to.
|
| 44 |
+
|
| 45 |
+
**Optional metadata properties:**
|
| 46 |
+
+ **skill_type** (string) – Defaults to `USER`.
|
| 47 |
+
+ **status** (string) – `ACTIVE` or `INACTIVE`. Defaults to `ACTIVE`.
|
| 48 |
+
+ **enable_tools** (array of strings) – A list of tool identifiers the agent can call when it loads this skill.
|
| 49 |
+
|
| 50 |
+
### agents_md
|
| 51 |
+
|
| 52 |
+
An `agents_md` asset is a markdown file containing standing agent instructions for a specific agent type.
|
| 53 |
+
|
| 54 |
+
**Required metadata properties:**
|
| 55 |
+
+ **agent_type** (string) – The agent type the AGENTS.md file applies to.
|
| 56 |
+
|
| 57 |
+
**Limits:** Each Agent Space can contain at most one AGENTS.md per agent_type. Maximum 25 KB.
|
| 58 |
+
|
| 59 |
+
### attachment
|
| 60 |
+
|
| 61 |
+
An `attachment` asset stores a binary or text file that the agent can reference during investigations.
|
| 62 |
+
|
| 63 |
+
**Required metadata properties:**
|
| 64 |
+
+ **filename** (string) – The original file name.
|
| 65 |
+
+ **extension** (string) – The file extension without the leading dot.
|
| 66 |
+
+ **size** (number) – The size of the file in bytes.
|
| 67 |
+
|
| 68 |
+
## Managing a skill end-to-end
|
| 69 |
+
|
| 70 |
+
### Create a skill from a single text file
|
| 71 |
+
|
| 72 |
+
```
|
| 73 |
+
aws devops-agent create-asset \
|
| 74 |
+
--agent-space-id 8f6187a7-0388-4926-8217-3a0fe32f757c \
|
| 75 |
+
--asset-type skill \
|
| 76 |
+
--metadata '{
|
| 77 |
+
"name": "rds-performance-investigation",
|
| 78 |
+
"description": "Investigation procedures for RDS performance issues.",
|
| 79 |
+
"agent_types": ["GENERIC"]
|
| 80 |
+
}' \
|
| 81 |
+
--content '{
|
| 82 |
+
"file": {
|
| 83 |
+
"path": "SKILL.md",
|
| 84 |
+
"body": {
|
| 85 |
+
"text": "# RDS Performance Investigation\n\nUse this skill when customers report database latency."
|
| 86 |
+
}
|
| 87 |
+
}
|
| 88 |
+
}'
|
| 89 |
+
```
|
| 90 |
+
|
| 91 |
+
### Create a skill from a zip bundle
|
| 92 |
+
|
| 93 |
+
```
|
| 94 |
+
base64 -w 0 rds-performance-investigation.zip > skill.zip.b64
|
| 95 |
+
aws devops-agent create-asset --cli-input-json file://create-skill.json
|
| 96 |
+
```
|
| 97 |
+
|
| 98 |
+
### Get, list, update, and delete
|
| 99 |
+
|
| 100 |
+
```
|
| 101 |
+
aws devops-agent get-asset --agent-space-id <id> --asset-id <assetId>
|
| 102 |
+
aws devops-agent list-assets --agent-space-id <id> --max-results 50
|
| 103 |
+
aws devops-agent update-asset --agent-space-id <id> --asset-id <assetId> --metadata '{ "agent_types": ["INCIDENT_TRIAGE"] }'
|
| 104 |
+
aws devops-agent delete-asset --agent-space-id <id> --asset-id <assetId>
|
| 105 |
+
```
|
| 106 |
+
|
| 107 |
+
### Activating and deactivating skills
|
| 108 |
+
|
| 109 |
+
```
|
| 110 |
+
aws devops-agent update-asset --agent-space-id <id> --asset-id <assetId> --metadata '{ "status": "INACTIVE" }'
|
| 111 |
+
aws devops-agent update-asset --agent-space-id <id> --asset-id <assetId> --metadata '{ "status": "ACTIVE" }'
|
| 112 |
+
```
|
training/data/raw/about-aws-devops-agent-supported-regions.md
ADDED
|
@@ -0,0 +1,49 @@
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| 1 |
+
# Supported Regions
|
| 2 |
+
|
| 3 |
+
This topic describes the AWS Regions where you can use AWS DevOps Agent.
|
| 4 |
+
|
| 5 |
+
## Cross-Region resource monitoring
|
| 6 |
+
|
| 7 |
+
AWS DevOps Agent can monitor and investigate resources in AWS accounts located in any AWS Region, regardless of which supported Region you create your Agent Space in. When you associate an AWS account with an Agent Space, the agent discovers and maps resources across all Regions within that account. This means you do not need an Agent Space in every Region where your workloads run.
|
| 8 |
+
|
| 9 |
+
Choose a supported Region based on your preferred data residency, proximity to your operations team, or organizational requirements.
|
| 10 |
+
|
| 11 |
+
## Supported Regions
|
| 12 |
+
|
| 13 |
+
AWS DevOps Agent is available in the following AWS Regions.
|
| 14 |
+
|
| 15 |
+
| Region Name | Region Code |
|
| 16 |
+
| --- | --- |
|
| 17 |
+
| US East (N. Virginia) | us-east-1 |
|
| 18 |
+
| US West (Oregon) | us-west-2 |
|
| 19 |
+
| Canada (Central) | ca-central-1 |
|
| 20 |
+
| South America (Sao Paulo) | sa-east-1 |
|
| 21 |
+
| Asia Pacific (Mumbai) | ap-south-1 |
|
| 22 |
+
| Asia Pacific (Singapore) | ap-southeast-1 |
|
| 23 |
+
| Asia Pacific (Sydney) | ap-southeast-2 |
|
| 24 |
+
| Asia Pacific (Tokyo) | ap-northeast-1 |
|
| 25 |
+
| Europe (Frankfurt) | eu-central-1 |
|
| 26 |
+
| Europe (Ireland) | eu-west-1 |
|
| 27 |
+
| Europe (London) | eu-west-2 |
|
| 28 |
+
|
| 29 |
+
## Service endpoints
|
| 30 |
+
|
| 31 |
+
| Region Name | Region Code | Endpoint | Protocol |
|
| 32 |
+
| --- | --- | --- | --- |
|
| 33 |
+
| US East (N. Virginia) | us-east-1 | aidevops.us-east-1.amazonaws.com | HTTPS |
|
| 34 |
+
| US West (Oregon) | us-west-2 | aidevops.us-west-2.amazonaws.com | HTTPS |
|
| 35 |
+
| Canada (Central) | ca-central-1 | aidevops.ca-central-1.amazonaws.com | HTTPS |
|
| 36 |
+
| South America (Sao Paulo) | sa-east-1 | aidevops.sa-east-1.amazonaws.com | HTTPS |
|
| 37 |
+
| Asia Pacific (Mumbai) | ap-south-1 | aidevops.ap-south-1.amazonaws.com | HTTPS |
|
| 38 |
+
| Asia Pacific (Singapore) | ap-southeast-1 | aidevops.ap-southeast-1.amazonaws.com | HTTPS |
|
| 39 |
+
| Asia Pacific (Sydney) | ap-southeast-2 | aidevops.ap-southeast-2.amazonaws.com | HTTPS |
|
| 40 |
+
| Asia Pacific (Tokyo) | ap-northeast-1 | aidevops.ap-northeast-1.amazonaws.com | HTTPS |
|
| 41 |
+
| Europe (Frankfurt) | eu-central-1 | aidevops.eu-central-1.amazonaws.com | HTTPS |
|
| 42 |
+
| Europe (Ireland) | eu-west-1 | aidevops.eu-west-1.amazonaws.com | HTTPS |
|
| 43 |
+
| Europe (London) | eu-west-2 | aidevops.eu-west-2.amazonaws.com | HTTPS |
|
| 44 |
+
|
| 45 |
+
## Considerations
|
| 46 |
+
|
| 47 |
+
+ **Agent Space Region selection** — An Agent Space and its data are stored in the Region where you create it. Choose a Region that meets your data residency requirements.
|
| 48 |
+
+ **Cross-Region monitoring** — Resources in AWS accounts associated with an Agent Space are monitored regardless of which Region those resources are deployed in.
|
| 49 |
+
+ **Third-party integrations** — Connections to CI/CD providers, observability tools, and MCP servers are configured per Agent Space and are not Region-dependent.
|
training/data/raw/about-aws-devops-agent-what-are-devops-agent-spaces.md
ADDED
|
@@ -0,0 +1,29 @@
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| 1 |
+
# What are DevOps Agent Spaces?
|
| 2 |
+
|
| 3 |
+
A DevOps Agent Space is a logical container that defines the tools and infrastructure that AWS DevOps Agent has access to. Each Agent Space operates independently with its own AWS account access, third-party integrations, and user permissions.
|
| 4 |
+
|
| 5 |
+
An Agent Space represents the boundary of what AWS DevOps Agent can access and investigate during incident response. When you create an Agent Space, you define which AWS accounts the agent can access, which external tools it can connect to, and which users in your organization can interact with the agent.
|
| 6 |
+
|
| 7 |
+
Each Agent Space functions as an independent deployment of AWS DevOps Agent. You configure the Agent Space through the AWS Management Console, while your operations teams use the Agent Space's web app to conduct investigations and review recommendations within that space.
|
| 8 |
+
|
| 9 |
+
## How Agent Spaces are isolated
|
| 10 |
+
|
| 11 |
+
Agent Spaces maintain isolation to ensure security and prevent unintended access across different environments or teams:
|
| 12 |
+
+ **AWS account isolation** – Each Agent Space uses dedicated IAM roles that grant access only to specific AWS accounts and resources. The agent cannot access AWS resources outside of those explicitly configured for the Agent Space.
|
| 13 |
+
+ **User access isolation** – You control which users or groups can access each Agent Space. This allows you to align access permissions with your organizational structure, ensuring teams only interact with their designated Agent Spaces.
|
| 14 |
+
+ **Data isolation** – Investigation data, incident history, and recommendations are maintained separately within each Agent Space. Information from one Agent Space is not visible or accessible from another Agent Space.
|
| 15 |
+
+ **Chat data isolation** - Chat conversation history is also isolated within each Agent Space. Conversations and queries in one Agent Space are not visible or accessible from another Agent Space.
|
| 16 |
+
|
| 17 |
+
## Agent Space Web App
|
| 18 |
+
|
| 19 |
+
Each Agent Space has a dedicated web app that is accessible outside of the AWS Management Console. See What is a DevOps Agent Web App? to learn more about the web app.
|
| 20 |
+
|
| 21 |
+
## When to use multiple Agent Spaces
|
| 22 |
+
|
| 23 |
+
Consider creating multiple Agent Spaces to support different organizational needs:
|
| 24 |
+
+ **Team separation** – Create dedicated Agent Spaces for different application teams or business units to maintain clear ownership boundaries in the Agent Space.
|
| 25 |
+
+ **Environment isolation** – Separate production and non-production environments into different Agent Spaces to prevent accidental cross-environment access.
|
| 26 |
+
+ **Service boundaries** – Align Agent Spaces with specific services or application boundaries to keep investigations focused and relevant.
|
| 27 |
+
+ **Compliance requirements** – Configure separate Agent Spaces with different access controls or data residency settings to meet regulatory requirements.
|
| 28 |
+
|
| 29 |
+
**Note:** When creating multiple Agent Spaces, you can use a dedicated AWS account as the primary account for an Agent Space and connect distinct application accounts as secondary accounts. This approach allows you to maintain granular access controls while ensuring that each Agent Space can access only the resources specific to its intended scope, even when using automatic role creation.
|
training/data/raw/about-aws-devops-agent-what-is-a-devops-agent-topology.md
ADDED
|
@@ -0,0 +1,54 @@
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| 1 |
+
# What is a DevOps Agent Topology?
|
| 2 |
+
|
| 3 |
+
AWS DevOps Agent's automatically discovers and visualizes the resources and relationships within your applications and uses the resulting topology to understand your infrastructure during incident investigations and when making preventative recommendations.
|
| 4 |
+
|
| 5 |
+
## How topology graphs are created
|
| 6 |
+
|
| 7 |
+
AWS DevOps Agent builds topology graphs through several automated processes:
|
| 8 |
+
+ **Resource discovery** – The agent automatically scans your AWS accounts to identify resources like compute instances, storage services, networking components, and databases that are part of your applications.
|
| 9 |
+
+ **Relationship detection** – The agent analyzes configuration data, CloudFormation stacks, and resource tags to determine how resources relate to one another.
|
| 10 |
+
+ **Code and deployment mapping** – When connected to CI/CD pipelines, the agent links infrastructure resources back to their deployment processes and changed application and infrastructure code.
|
| 11 |
+
+ **Observability behavior mapping** – Data from observability systems such as Amazon CloudWatch Application Signals and Dynatrace are used to identify observed behaviors that indicate relationships between resources.
|
| 12 |
+
|
| 13 |
+
## Key capabilities
|
| 14 |
+
|
| 15 |
+
Resource mapping provides several capabilities that enhance incident investigation and prevention:
|
| 16 |
+
+ **Interactive visualization** – Explore your application topology through an interactive graph in the Operator Web App. You can zoom and navigate the topology to understand complex relationships between resources. You can also use Chat to query topology information using natural language, such as 'Show me all Lambda functions connected to this DynamoDB table' or 'What resources are affected by this alarm?'.
|
| 17 |
+
+ **Contextual investigation** – During incident investigations, AWS DevOps Agent is assisted by the resource topology to identify affected components, understand blast radius, and trace the impact path through your systems.
|
| 18 |
+
+ **Root cause analysis** – The detailed understanding of resource relationships helps pinpoint where issues originate, even in complex distributed systems with many interdependencies.
|
| 19 |
+
+ **Impact assessment** – When analyzing incidents, the agent can better determine which downstream services might be affected by identifying dependency chains in the topology.
|
| 20 |
+
+ **Preventative recommendations** – The agent uses topology insights to make targeted recommendations for resilience improvements, suggesting changes that will have the most significant impact on system stability.
|
| 21 |
+
|
| 22 |
+
## Topology views
|
| 23 |
+
|
| 24 |
+
The topology visualization in the Topology page in the Operator Web App offers multiple levels of detail, organized into two categories:
|
| 25 |
+
|
| 26 |
+
### Learned
|
| 27 |
+
|
| 28 |
+
Learned view is generated from the Agent Space understanding and pipeline skill and display structured summaries of your infrastructure. The following learned views are available:
|
| 29 |
+
+ **Topology** – The default view, generated from the Agent Space Understanding skill. Displays a structured summary of your infrastructure organized by logical services and request paths.
|
| 30 |
+
+ **Pipeline** – Displays your CI/CD pipeline topology, showing deployment stages, actions, and their relationships to infrastructure resources. This view is only available when pipeline topology has been generated for your agent space.
|
| 31 |
+
|
| 32 |
+
### Others
|
| 33 |
+
|
| 34 |
+
This view shows your infrastructure at different levels of granularity based on raw resource discovery data:
|
| 35 |
+
+ **System** – Shows high-level account and region boundaries.
|
| 36 |
+
+ **Container** – Displays deployment stacks like CloudFormation stacks that contain related resources.
|
| 37 |
+
+ **Components** – Shows individual components within containers and their relationships.
|
| 38 |
+
+ **All Resources** – Shows the complete view with all discovered resources and their relationships.
|
| 39 |
+
|
| 40 |
+
## Resource discovery
|
| 41 |
+
|
| 42 |
+
Resources are discovered through two methods:
|
| 43 |
+
+ **CloudFormation stacks** – The agent lists all CloudFormation stacks and their resources in the primary AWS account and any connected secondary accounts. This is supported for any infrastructure-as-code tooling that uses CloudFormation for deployment, including AWS Cloud Development Kit (AWS CDK).
|
| 44 |
+
+ **Resource Explorer** – For resources not deployed from CloudFormation, tagged resources are discovered from AWS Resource Explorer. The target AWS account must have Resource Explorer enabled. This is useful for identifying application boundaries for resources deployed through the AWS Management Console, the AWS service APIs, or other infrastructure-as-code frameworks.
|
| 45 |
+
|
| 46 |
+
## Investigation scope beyond topology
|
| 47 |
+
|
| 48 |
+
While the application topology provides important context during investigations, AWS DevOps Agent is not limited to investigating only the resources shown in the topology. The agent may use additional data sources, such as AWS service APIs or connected observability tools, to investigate resources that are not in the application topology.
|
| 49 |
+
|
| 50 |
+
To limit the resources the agent has access to, restrict the policy for the role assigned to the agent to access cross-account resources. For more information, see Limiting Agent Access in an AWS Account.
|
| 51 |
+
|
| 52 |
+
## Topology and the Agent Space Understanding skill
|
| 53 |
+
|
| 54 |
+
The topology graph feeds into the Agent Space Understanding learned skill, which encodes a structured summary of your infrastructure for use during investigations. When topology discovery completes for a new agent space, the system automatically generates the Agent Space Understanding skill. For more information about learned skills, see Learned Skills.
|
training/data/raw/about-aws-devops-agent-what-is-a-devops-agent-web-app.md
ADDED
|
@@ -0,0 +1,25 @@
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| 1 |
+
# What is a DevOps Agent Web App?
|
| 2 |
+
|
| 3 |
+
AWS DevOps Agent uses a dual-console architecture that separates administrative functions from day-to-day operational activities. This design enables administrators to configure the service while operations teams focus on incident response and prevention.
|
| 4 |
+
|
| 5 |
+
## Consoles
|
| 6 |
+
|
| 7 |
+
AWS DevOps Agent provides two distinct interfaces:
|
| 8 |
+
+ **AWS Management Console** – Administrators use the AWS Management Console to set up and manage AWS DevOps Agent. In this console, you can create an Agent Space, connect AWS services and third-party tools, and manage access permissions for your organization.
|
| 9 |
+
+ **DevOps Agent web app** – Operations teams use DevOps Agent Space web apps for daily incident response activities. This standalone application provides an interface where on-call engineers can launch investigations, interact with the agent through natural language chat, view application topologies, and review incident prevention recommendations.
|
| 10 |
+
|
| 11 |
+
## Web app capabilities
|
| 12 |
+
|
| 13 |
+
The DevOps Agent web app provides the following primary capabilities:
|
| 14 |
+
+ **Incident Response** – The page is where you create and track incident investigations as well as generate mitigation plans to resolve incidents.
|
| 15 |
+
+ **Incident Prevention** – Found in the Prevention page, this is where you will find recommendations to improve your observability posture, delivery processes, and infrastructure architecture to prevent future incidents.
|
| 16 |
+
+ **Topology** – The Topology page provides an interactive visual representation of the account resources and their relationships across all of the resources in the connected accounts. You can view the topology with different levels of detail using the "Show" dropdown to switch between System, Container, and Resource views.
|
| 17 |
+
+ **Skills** – Modular instruction sets that extend AWS DevOps Agent with specialized capabilities. Skills contain domain knowledge, investigation methodologies, and tool configurations tailored to your infrastructure. Each skill enables specific tools and provides progressive disclosure of instructions only when relevant to the investigation.
|
| 18 |
+
+ **Natural language Chat interface** – Available throughout the web app, Chat is an AI-powered conversational assistant that enables you to query your infrastructure, analyze system health, and work with investigations using natural language. Chat provides context-aware responses based on the page you're viewing.
|
| 19 |
+
|
| 20 |
+
## Authentication
|
| 21 |
+
|
| 22 |
+
AWS DevOps Agent supports flexible authentication methods to accommodate different organizational requirements:
|
| 23 |
+
+ **IAM Identity Center integration (User access)** – Organizations can use AWS Identity Center (IAM Identity Center) to centrally manage user access to the DevOps Agent Space web apps. IAM Identity Center can federate with external identity providers through standard OIDC and SAML protocols, including providers like Okta, Ping Identity, and Microsoft Entra ID. This method supports multi-factor authentication from your identity provider.
|
| 24 |
+
+ **External identity provider (IdP) authentication** – Organizations can connect an OIDC-compatible identity provider, such as Okta or Microsoft Entra ID, directly to the Agent Space web app without requiring IAM Identity Center. Users sign in with their corporate credentials through the IdP.
|
| 25 |
+
+ **IAM authentication link (Admin access)** – An alternative method provides direct access to the web app from the AWS Management Console using your existing console session. This option is useful before implementing full Identity Center integration, but sessions are limited to 10 minutes.
|
training/data/raw/about-aws-devops-agent.md
ADDED
|
@@ -0,0 +1,52 @@
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| 1 |
+
# About AWS DevOps Agent
|
| 2 |
+
|
| 3 |
+
AWS DevOps Agent is a frontier agent that resolves and proactively prevents incidents, continuously improving reliability and performance.
|
| 4 |
+
|
| 5 |
+
AWS DevOps Agent investigates incidents and identifies operational improvements as an experienced DevOps engineer.
|
| 6 |
+
|
| 7 |
+
The agent works by:
|
| 8 |
+
+ Learning your resources and their relationships.
|
| 9 |
+
+ Working with your observability tools, skills, code repositories, and CI/CD pipelines.
|
| 10 |
+
+ Correlating telemetry, code, and deployment data to understand relationships between your application resources.
|
| 11 |
+
+ Supporting applications in multicloud and hybrid environments.
|
| 12 |
+
|
| 13 |
+
## Key features
|
| 14 |
+
|
| 15 |
+
AWS DevOps Agent provides comprehensive incident response and prevention capabilities through the following features:
|
| 16 |
+
|
| 17 |
+
### Always-on, autonomous incident response
|
| 18 |
+
|
| 19 |
+
AWS DevOps Agent autonomously investigates issues the moment they occur:
|
| 20 |
+
+ **Automated incident investigation** – Begins investigating immediately when an alert or support ticket comes in
|
| 21 |
+
+ **AWS DevOps Agent Chat** - Query your infrastructure, analyze system health, and guide investigations using natural language throughout the DevOps Agent Space web app. Chat provides context-aware responses based on the page you're viewing, whether asking about resources in Topology, steering an investigation, or filtering recommendations in Prevention.
|
| 22 |
+
+ **Detailed mitigation plans** – Provides specific actions to resolve incidents, validate success, and revert changes if needed
|
| 23 |
+
+ **Automated incident coordination** – Routes observations, findings, and mitigation steps through your preferred communication channels like Slack and ServiceNow
|
| 24 |
+
+ **AWS Support integration** – Create AWS Support cases directly from an investigation with immediate context provided to AWS Support experts
|
| 25 |
+
|
| 26 |
+
### Prevent future incidents
|
| 27 |
+
|
| 28 |
+
AWS DevOps Agent analyzes patterns across historical incidents to help you move from reactive firefighting to proactive operational improvement:
|
| 29 |
+
+ **Targeted recommendations** – Delivers specific, actionable improvements that strengthen four key areas: observability (monitoring, alerting, logging), infrastructure optimization (autoscaling, capacity tuning), and deployment pipeline enhancement (testing, validation).
|
| 30 |
+
+ **Continuous learning** – Refines recommendations based on your team's feedback
|
| 31 |
+
|
| 32 |
+
### Get more from your DevOps tools
|
| 33 |
+
|
| 34 |
+
AWS DevOps Agent integrates with your existing tools without changing your workflows:
|
| 35 |
+
+ **Application resource mapping** – Builds a topology graph of your application resources and their relationships
|
| 36 |
+
+ **Built-in integrations** – Works with popular observability tools (Amazon CloudWatch, Dynatrace, Datadog, New Relic, and Splunk), code repositories, and CI/CD pipelines (GitHub Actions and repositories, GitLab workflows and repositories)
|
| 37 |
+
+ **Custom tool integration** – Extend capabilities by connecting to your own Model Context Protocol (MCP) servers for additional tools
|
| 38 |
+
+ **Conversational infrastructure queries** – Use natural language to query AWS resources, system metrics and alarm status without navigating multiple consoles. Chat understands context and maintains conversation history for follow-up questions.
|
| 39 |
+
|
| 40 |
+
## How AWS DevOps Agent works
|
| 41 |
+
|
| 42 |
+
AWS DevOps Agent operates through a dual-console architecture. Administrators use the AWS Management Console to create and manage Agent Spaces, configure integrations, and set up access controls. Operations teams use the AWS DevOps Agent web app for day-to-day incident response and investigation activities. The web app is where operators can interact with agent investigations, browse cross-account application topology, and learn about preventative improvements to observability, code, pipelines, and infrastructure architectures. To learn more, see Proactive incident prevention.
|
| 43 |
+
|
| 44 |
+
The service is organized around Agent Spaces, which are logical containers that define what AWS DevOps Agent can access and investigate. Each Agent Space contains your AWS account configurations, third-party tool integrations, and access permissions. To learn more, see What are DevOps Agent Spaces?.
|
| 45 |
+
|
| 46 |
+
AWS DevOps Agent automatically builds an application topology that maps your resources and their relationships. This topology helps the service understand your application architecture during investigations. To learn more, see What is a DevOps Agent Topology?.
|
| 47 |
+
|
| 48 |
+
## Benefits
|
| 49 |
+
+ **Reduce mean time to resolution (MTTR)** – Autonomous investigation starts immediately, accelerating incident resolution from hours to minutes
|
| 50 |
+
+ **Prevent recurring incidents** – Targeted recommendations address root causes and strengthen system resilience
|
| 51 |
+
+ **Improve operational efficiency** – Free your team from repetitive investigation tasks to focus on innovation
|
| 52 |
+
+ **Work within existing workflows** – Integrates with your existing tools and processes without disruption
|
training/data/raw/aws-devops-agent-security-compliance-validation.md
ADDED
|
@@ -0,0 +1,7 @@
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| 1 |
+
# Compliance validation for AWS DevOps Agent
|
| 2 |
+
|
| 3 |
+
AWS DevOps Agent is in scope for the following compliance programs: BIO, C5, CISPE, CPSTIC, ENS High, FINMA, GNS, GSMA, HITRUST, IRAP, ISMAP, ISO (ISO/IEC 27001, 27017, 27018, 27701, 22301, 20000, 9001), CSA STAR, MTCS, OSPAR, PCI, Pinakes, PiTuKri, and SOC.
|
| 4 |
+
|
| 5 |
+
AWS DevOps Agent is HIPAA eligible.
|
| 6 |
+
|
| 7 |
+
Download third-party audit reports using AWS Artifact.
|
training/data/raw/aws-devops-agent-security-devops-agent-iam-permissions.md
ADDED
|
@@ -0,0 +1,41 @@
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| 1 |
+
# DevOps Agent IAM permissions
|
| 2 |
+
|
| 3 |
+
AWS DevOps Agent uses IAM actions in the `aidevops:` namespace to control access.
|
| 4 |
+
|
| 5 |
+
## Agent Space management actions
|
| 6 |
+
+ aidevops:GetAgentSpace - View Agent Space details
|
| 7 |
+
+ aidevops:GetAssociation - View account association details
|
| 8 |
+
+ aidevops:ListAssociations - List AWS account associations
|
| 9 |
+
+ aidevops:CreateAgentSpace - Create new Agent Spaces
|
| 10 |
+
+ aidevops:DeleteAgentSpace - Delete Agent Spaces
|
| 11 |
+
+ aidevops:UpdateAgentSpace - Update Agent Space configuration
|
| 12 |
+
+ aidevops:ListAgentSpaces - List all Agent Spaces
|
| 13 |
+
|
| 14 |
+
## Investigation and execution actions
|
| 15 |
+
+ aidevops:ListExecutions - View execution metadata
|
| 16 |
+
+ aidevops:GetExecution - Get execution details
|
| 17 |
+
+ aidevops:CreateTask - Create investigation tasks
|
| 18 |
+
+ aidevops:ListTasks - List tasks
|
| 19 |
+
+ aidevops:GetTask - Get task details
|
| 20 |
+
+ aidevops:UpdateTask - Update task priority/status
|
| 21 |
+
|
| 22 |
+
## Chat actions
|
| 23 |
+
+ aidevops:ListChats - View chat history
|
| 24 |
+
+ aidevops:CreateChat - Create new conversations
|
| 25 |
+
+ aidevops:SendMessage - Send messages and receive responses
|
| 26 |
+
|
| 27 |
+
## Knowledge management actions
|
| 28 |
+
+ aidevops:CreateAsset - Create skills, AGENTS.md, attachments
|
| 29 |
+
+ aidevops:GetAsset - Retrieve asset metadata
|
| 30 |
+
+ aidevops:UpdateAsset - Update assets
|
| 31 |
+
+ aidevops:DeleteAsset - Delete assets
|
| 32 |
+
+ aidevops:ListAssets - List assets
|
| 33 |
+
|
| 34 |
+
## Service and integration actions
|
| 35 |
+
+ aidevops:RegisterService - Register third-party services
|
| 36 |
+
+ aidevops:AssociateService - Associate services with Agent Spaces
|
| 37 |
+
+ aidevops:EnableOperatorApp - Enable web app access
|
| 38 |
+
|
| 39 |
+
## AWS managed policies
|
| 40 |
+
+ **AIDevOpsAgentAccessPolicy** - Read-only permissions for agent investigations
|
| 41 |
+
+ **AIDevOpsOperatorAppAccessPolicy** - Operator web app access permissions
|
training/data/raw/aws-devops-agent-security-encryption-at-rest-for-devops-agent.md
ADDED
|
@@ -0,0 +1,38 @@
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| 1 |
+
# Encryption at rest for AWS DevOps Agent
|
| 2 |
+
|
| 3 |
+
AWS DevOps Agent encrypts all customer data at rest. By default, AWS owned keys are used at no additional charge. You can optionally use a customer managed KMS key.
|
| 4 |
+
|
| 5 |
+
## Customer managed keys
|
| 6 |
+
|
| 7 |
+
You can specify a customer managed key when creating:
|
| 8 |
+
+ **Agent Space** – Encrypts Agent Space details, investigations, skills, and chat
|
| 9 |
+
+ **Service** – Encrypts third-party service credentials
|
| 10 |
+
|
| 11 |
+
### Step 1: Create a customer managed key
|
| 12 |
+
Requirements:
|
| 13 |
+
| Property | Requirement |
|
| 14 |
+
| --- | --- |
|
| 15 |
+
| Key type | Symmetric |
|
| 16 |
+
| Key spec | SYMMETRIC_DEFAULT |
|
| 17 |
+
| Key usage | ENCRYPT_DECRYPT |
|
| 18 |
+
|
| 19 |
+
### Step 2: Set the key policy
|
| 20 |
+
Required KMS actions: kms:DescribeKey, kms:GenerateDataKey, kms:Decrypt, kms:Encrypt, kms:ReEncrypt
|
| 21 |
+
|
| 22 |
+
Grant permissions to both caller credentials (synchronous operations) and aidevops.amazonaws.com service principal (asynchronous operations like investigations).
|
| 23 |
+
|
| 24 |
+
### Step 3: Specify the key when creating a resource
|
| 25 |
+
In console: Advanced Configuration > Encryption key type > Customer managed key
|
| 26 |
+
In API: Include kmsKeyArn parameter
|
| 27 |
+
|
| 28 |
+
## Encryption context
|
| 29 |
+
```
|
| 30 |
+
{
|
| 31 |
+
"aws-crypto-ec:aws:aidevops:arn": "arn:aws:aidevops:{region}:{accountId}:{resourceType}/{resourceId}"
|
| 32 |
+
}
|
| 33 |
+
```
|
| 34 |
+
|
| 35 |
+
## Key management
|
| 36 |
+
+ Disabling/deleting KMS key prevents data access
|
| 37 |
+
+ Cannot change key after resource creation
|
| 38 |
+
+ Monitor key usage via CloudTrail
|
training/data/raw/aws-devops-agent-security-limiting-agent-access-in-an-aws-account.md
ADDED
|
@@ -0,0 +1,59 @@
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| 1 |
+
# Limiting Agent Access in an AWS Account
|
| 2 |
+
|
| 3 |
+
Control what AWS service APIs and resources the agent can access through IAM policies.
|
| 4 |
+
|
| 5 |
+
## Understanding IAM roles
|
| 6 |
+
+ **Primary account role** - Access to Agent Space account resources
|
| 7 |
+
+ **Secondary account roles** - Access to additional connected accounts
|
| 8 |
+
|
| 9 |
+
## Understanding permission guardrails
|
| 10 |
+
|
| 11 |
+
The agent applies a session policy (guardrail) that limits effective permissions to the intersection of:
|
| 12 |
+
1. Your IAM role policies (what you intend)
|
| 13 |
+
2. The permission guardrail (maximum the agent can ever do)
|
| 14 |
+
|
| 15 |
+
### Default permissions
|
| 16 |
+
AIDevOpsAgentAccessPolicy provides default read-only permissions included in the guardrail.
|
| 17 |
+
|
| 18 |
+
### Supported additional permissions (opt-in)
|
| 19 |
+
| Service | Actions | Use case |
|
| 20 |
+
| --- | --- | --- |
|
| 21 |
+
| Amazon Athena | athena:GetQuery*, athena:StartQueryExecution | Run Athena queries |
|
| 22 |
+
| Amazon S3 | s3:GetObject, s3:ListBucket | Read logs/data in S3 |
|
| 23 |
+
| AWS Direct Connect | directconnect:Describe* | Network connectivity issues |
|
| 24 |
+
| AWS Glue | glue:GetPartitions | Glue Data Catalog for Athena |
|
| 25 |
+
| AWS KMS | kms:Decrypt | Decrypt encrypted resources |
|
| 26 |
+
|
| 27 |
+
### Permissions blocked by guardrail
|
| 28 |
+
Write operations (s3:PutObject, ec2:TerminateInstances, etc.) are always blocked.
|
| 29 |
+
|
| 30 |
+
## Restricting service access
|
| 31 |
+
Grant only read-only permissions for necessary services:
|
| 32 |
+
```json
|
| 33 |
+
{
|
| 34 |
+
"Effect": "Allow",
|
| 35 |
+
"Action": ["cloudwatch:GetMetricData", "logs:GetLogEvents", "ec2:DescribeInstances"],
|
| 36 |
+
"Resource": "*"
|
| 37 |
+
}
|
| 38 |
+
```
|
| 39 |
+
|
| 40 |
+
## Restricting resource access
|
| 41 |
+
Use ARN patterns:
|
| 42 |
+
```json
|
| 43 |
+
{"Resource": "arn:aws:lambda:*:*:function:production-*"}
|
| 44 |
+
```
|
| 45 |
+
|
| 46 |
+
Use tag-based restrictions:
|
| 47 |
+
```json
|
| 48 |
+
{"Condition": {"StringEquals": {"aws:ResourceTag/Environment": "production"}}}
|
| 49 |
+
```
|
| 50 |
+
|
| 51 |
+
## Restricting regional access
|
| 52 |
+
```json
|
| 53 |
+
{"Condition": {"StringEquals": {"aws:RequestedRegion": ["us-east-1", "us-west-2"]}}}
|
| 54 |
+
```
|
| 55 |
+
|
| 56 |
+
## Best practices
|
| 57 |
+
+ Grant only read-only permissions
|
| 58 |
+
+ Use resource-level permissions when possible
|
| 59 |
+
+ Regularly review and audit permissions
|
training/data/raw/aws-devops-agent-security-setting-up-external-identity-provider-idp-authentication.md
ADDED
|
@@ -0,0 +1,52 @@
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| 1 |
+
# Setting Up External Identity Provider (IdP) Authentication
|
| 2 |
+
|
| 3 |
+
External IdP authentication allows using an OIDC-compatible identity provider (Okta or Microsoft Entra ID) to manage user access without requiring IAM Identity Center.
|
| 4 |
+
|
| 5 |
+
## Prerequisites
|
| 6 |
+
+ OIDC-compatible identity provider (Okta or Microsoft Entra ID)
|
| 7 |
+
+ Administrator access to your identity provider
|
| 8 |
+
+ Administrator permissions for AWS DevOps Agent console
|
| 9 |
+
|
| 10 |
+
## How it works
|
| 11 |
+
+ Users navigate to the Agent Space web app URL
|
| 12 |
+
+ Redirected to identity provider login page
|
| 13 |
+
+ After authenticating, redirected back to web app
|
| 14 |
+
+ Sessions valid for up to 8 hours with automatic refresh
|
| 15 |
+
|
| 16 |
+
## Configuring external IdP authentication
|
| 17 |
+
|
| 18 |
+
### Step 1: Register an application in your identity provider
|
| 19 |
+
|
| 20 |
+
#### Option A: Okta
|
| 21 |
+
1. Create OIDC Web Application
|
| 22 |
+
2. Enable Authorization Code and Refresh Token grant types
|
| 23 |
+
3. Note Client ID, Client secret, and Okta domain (Issuer URL)
|
| 24 |
+
|
| 25 |
+
#### Option B: Microsoft Entra ID
|
| 26 |
+
1. Create App Registration
|
| 27 |
+
2. Create client secret
|
| 28 |
+
3. Issuer URL: https://login.microsoftonline.com/{tenant-id}/v2.0
|
| 29 |
+
|
| 30 |
+
### Step 2: Enable the Operator App with IdP authentication
|
| 31 |
+
1. Select Agent Space > Access tab
|
| 32 |
+
2. Choose External identity provider
|
| 33 |
+
3. Configure: Identity Provider, Issuer URL, Client ID, Client Secret
|
| 34 |
+
4. Choose role option
|
| 35 |
+
5. Copy the Callback URL
|
| 36 |
+
6. Choose Connect
|
| 37 |
+
|
| 38 |
+
### Step 3: Add the callback URL to your identity provider
|
| 39 |
+
Add: https://{agentSpaceId}.aidevops.global.app.aws/authorizer/idp/callback
|
| 40 |
+
|
| 41 |
+
## Session management
|
| 42 |
+
+ Session duration: up to 8 hours
|
| 43 |
+
+ Automatic refresh using OIDC refresh tokens
|
| 44 |
+
+ MFA supported when configured in IdP
|
| 45 |
+
|
| 46 |
+
## Updating IdP configuration
|
| 47 |
+
+ Rotate client secret without disconnecting via Rotate client secret option
|
| 48 |
+
+ Other changes require disconnect and reconfigure
|
| 49 |
+
|
| 50 |
+
## Disconnecting external IdP
|
| 51 |
+
1. Access tab > Disconnect
|
| 52 |
+
2. Removes IdP configuration and user history
|
training/data/raw/aws-devops-agent-security-setting-up-iam-identity-center-authentication.md
ADDED
|
@@ -0,0 +1,53 @@
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| 1 |
+
# Setting Up IAM Identity Center Authentication
|
| 2 |
+
|
| 3 |
+
IAM Identity Center authentication provides a centralized way to manage user access to the AWS DevOps Agent Space web application.
|
| 4 |
+
|
| 5 |
+
## Prerequisites
|
| 6 |
+
+ IAM Identity Center enabled in your organization or account
|
| 7 |
+
+ Administrator permissions in AWS DevOps Agent
|
| 8 |
+
+ An Agent Space configured
|
| 9 |
+
|
| 10 |
+
## Authentication options
|
| 11 |
+
|
| 12 |
+
+ **IAM Identity Center authentication** – Recommended for production. Centralized user management, sessions up to 12 hours.
|
| 13 |
+
+ **Admin access (IAM authentication)** – Quick access for administrators. Sessions limited to 30 minutes.
|
| 14 |
+
|
| 15 |
+
## Configuring IAM Identity Center during Agent Space creation
|
| 16 |
+
|
| 17 |
+
### Step 1: Navigate to the Web app configuration
|
| 18 |
+
1. After configuring Agent Space details, proceed to the Access tab
|
| 19 |
+
|
| 20 |
+
### Step 2: Configure IAM Identity Center integration
|
| 21 |
+
1. Verify the IAM Identity Center instance
|
| 22 |
+
2. Select role option:
|
| 23 |
+
+ Auto-create a new DevOps Agent role (recommended)
|
| 24 |
+
+ Assign an existing role
|
| 25 |
+
+ Create a new role using a policy template
|
| 26 |
+
|
| 27 |
+
The system automatically creates the IAM Identity Center application, trust relationships, and OAuth 2.0 flows.
|
| 28 |
+
|
| 29 |
+
## Adding users and groups
|
| 30 |
+
|
| 31 |
+
Required permissions: aidevops:EnableOperatorApp, sso:CreateApplicationAssignment, sso:DeleteApplicationAssignment, sso:ListApplicationAssignments, sso:DescribeApplication
|
| 32 |
+
|
| 33 |
+
1. Select Agent Space > Access tab
|
| 34 |
+
2. Under User Access, choose Manage Users and Groups
|
| 35 |
+
3. Choose Add Users or Groups
|
| 36 |
+
4. Search and select users/groups from IAM Identity Center directory
|
| 37 |
+
|
| 38 |
+
## How users access the web app
|
| 39 |
+
|
| 40 |
+
1. Navigate to the Agent Space web app URL
|
| 41 |
+
2. Redirected to IAM Identity Center login page
|
| 42 |
+
3. Enter credentials (and MFA if configured)
|
| 43 |
+
4. Redirected back to web app
|
| 44 |
+
|
| 45 |
+
## Session management
|
| 46 |
+
+ Default session duration: 8 hours (configurable 1-12 hours)
|
| 47 |
+
+ HTTP-only cookies for security
|
| 48 |
+
+ Multi-factor authentication supported
|
| 49 |
+
+ 15-minute SigV4 credentials renewed automatically
|
| 50 |
+
|
| 51 |
+
## Disconnecting Identity Center
|
| 52 |
+
1. Choose Actions > Disconnect from IAM Identity Center
|
| 53 |
+
2. Confirm in dialog
|
training/data/raw/aws-devops-agent-security-vpc-endpoints-aws-privatelink.md
ADDED
|
@@ -0,0 +1,27 @@
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| 1 |
+
# VPC Endpoints (AWS PrivateLink)
|
| 2 |
+
|
| 3 |
+
Use AWS PrivateLink to create a private connection between your VPC and AWS DevOps Agent without using an internet gateway.
|
| 4 |
+
|
| 5 |
+
## VPC endpoint service names
|
| 6 |
+
|
| 7 |
+
| Category | Endpoint suffix |
|
| 8 |
+
| --- | --- |
|
| 9 |
+
| Control Plane API Actions | aidevops |
|
| 10 |
+
| Runtime Operations | aidevops-dataplane |
|
| 11 |
+
| Webhook Events | event-ai |
|
| 12 |
+
|
| 13 |
+
## Create an interface endpoint
|
| 14 |
+
|
| 15 |
+
Service names:
|
| 16 |
+
+ com.amazonaws.{region}.aidevops
|
| 17 |
+
+ com.amazonaws.{region}.aidevops-dataplane
|
| 18 |
+
+ com.amazonaws.{region}.event-ai
|
| 19 |
+
|
| 20 |
+
Enable Private DNS Name for default Regional DNS:
|
| 21 |
+
+ cp.aidevops.{region}.api.aws
|
| 22 |
+
+ dp.aidevops.{region}.api.aws
|
| 23 |
+
+ event-ai.{region}.api.aws
|
| 24 |
+
|
| 25 |
+
## Endpoint policy
|
| 26 |
+
|
| 27 |
+
Attach custom endpoint policies to control access from your VPC to AWS DevOps Agent.
|
training/data/raw/aws-devops-agent-security.md
ADDED
|
@@ -0,0 +1,46 @@
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| 1 |
+
# AWS DevOps Agent Security
|
| 2 |
+
|
| 3 |
+
## Multi-layered security
|
| 4 |
+
AWS DevOps Agent implements security at multiple layers with internal access controls limiting scope of actions.
|
| 5 |
+
|
| 6 |
+
## Agent Spaces
|
| 7 |
+
Primary security boundary. Each Agent Space operates independently with its own configurations, permissions, and data isolation.
|
| 8 |
+
|
| 9 |
+
## Regional processing and data flow
|
| 10 |
+
+ Data stored in Agent Space region
|
| 11 |
+
+ Inference processed within geography (EU in EU, US in US, Australia in Australia, Japan in Japan)
|
| 12 |
+
+ Cross-region inference for Singapore, Mumbai, Sao Paulo routes globally
|
| 13 |
+
|
| 14 |
+
## Identity and access management
|
| 15 |
+
+ IAM Identity Center (OAuth 2.0, sessions up to 12 hours)
|
| 16 |
+
+ External IdP (Okta, Microsoft Entra ID)
|
| 17 |
+
+ IAM authentication link (10-minute sessions)
|
| 18 |
+
|
| 19 |
+
## Data protection
|
| 20 |
+
+ Encryption at rest with AWS-managed or customer-managed KMS keys
|
| 21 |
+
+ Encryption in transit for all data
|
| 22 |
+
+ PII not filtered - recommended to redact before storing in logs
|
| 23 |
+
|
| 24 |
+
## Agent journal and audit logging
|
| 25 |
+
+ Logs every reasoning step and action
|
| 26 |
+
+ Immutable once recorded
|
| 27 |
+
+ CloudTrail integration for all API calls
|
| 28 |
+
|
| 29 |
+
## Prompt injection protection
|
| 30 |
+
+ Limited write capabilities (only tickets/support cases)
|
| 31 |
+
+ Account boundary enforcement
|
| 32 |
+
+ AI safety protections (ASL-3)
|
| 33 |
+
+ Immutable audit trail
|
| 34 |
+
|
| 35 |
+
## Integration security
|
| 36 |
+
+ Native bidirectional integrations
|
| 37 |
+
+ MCP servers (OAuth 2.0, API keys)
|
| 38 |
+
+ Webhook triggers (HMAC)
|
| 39 |
+
+ Outbound communication (Slack, ticketing)
|
| 40 |
+
|
| 41 |
+
## Shared responsibility model
|
| 42 |
+
**AWS:** Security of retrieved data, native tools, infrastructure
|
| 43 |
+
**Customer:** User access management, trusted data sources, MCP server security, IAM role scoping, PII redaction
|
| 44 |
+
|
| 45 |
+
## Data usage
|
| 46 |
+
AWS does not use agent data to train models or improve the product.
|
training/data/raw/configuring-capabilities-for-aws-devops-agent-aws-eks-access-setup.md
ADDED
|
@@ -0,0 +1,20 @@
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| 1 |
+
# AWS EKS access setup
|
| 2 |
+
|
| 3 |
+
You can enable AWS DevOps Agent to investigate issues in your Amazon EKS clusters by running read-only kubectl commands against both public and private clusters.
|
| 4 |
+
|
| 5 |
+
Once connected, the agent can help diagnose operational issues — describing resources, retrieving pod logs, inspecting cluster events, checking node health, and more. The agent cannot create, modify, or delete any resources in your cluster.
|
| 6 |
+
|
| 7 |
+
## Prerequisites
|
| 8 |
+
|
| 9 |
+
Ensure that your EKS cluster's authentication mode includes the EKS API. Check on the Access tab in the Amazon EKS console.
|
| 10 |
+
|
| 11 |
+
## Setup
|
| 12 |
+
|
| 13 |
+
1. Go to the Access tab in the EKS console.
|
| 14 |
+
2. Create a new IAM access entry with your primary cloud source IAM role ARN.
|
| 15 |
+
3. Select the AmazonAIOpsAssistantPolicy access policy with Cluster access scope.
|
| 16 |
+
4. Review and create the access entry.
|
| 17 |
+
|
| 18 |
+
## Troubleshooting
|
| 19 |
+
|
| 20 |
+
If the agent can't reach your cluster, verify that the access entry is using the correct IAM role ARN and that the AmazonAIOpsAssistantPolicy access policy is attached.
|
training/data/raw/configuring-capabilities-for-aws-devops-agent-connecting-azure-index.md
ADDED
|
@@ -0,0 +1,17 @@
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| 1 |
+
# Connecting Azure
|
| 2 |
+
|
| 3 |
+
Azure integration enables AWS DevOps Agent to investigate resources in your Azure environment and correlate Azure DevOps pipeline deployments with operational incidents.
|
| 4 |
+
|
| 5 |
+
Azure integration consists of two independent capabilities:
|
| 6 |
+
+ **Azure Resources** – Enables the agent to discover and investigate Azure cloud resources such as virtual machines, AKS clusters, databases, and networking components.
|
| 7 |
+
+ **Azure DevOps** – Enables the agent to access Azure DevOps repositories and pipeline execution history.
|
| 8 |
+
|
| 9 |
+
## Registration methods
|
| 10 |
+
|
| 11 |
+
+ **Admin Consent** – A consent-based flow where you authorize the AWS DevOps Agent Entra application in your Azure tenant.
|
| 12 |
+
+ **App Registration** – A self-managed approach where you create your own Entra application with federated identity credentials.
|
| 13 |
+
|
| 14 |
+
## Known limitations
|
| 15 |
+
+ Admin Consent: one AWS account per Azure tenant
|
| 16 |
+
+ App Registration: unique application per registration
|
| 17 |
+
+ Azure DevOps: source code access requires separate repository connection
|
training/data/raw/configuring-capabilities-for-aws-devops-agent-connecting-mcp-servers.md
ADDED
|
@@ -0,0 +1,46 @@
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| 1 |
+
# Connecting MCP Servers
|
| 2 |
+
|
| 3 |
+
Model Context Protocol (MCP) servers extend AWS DevOps Agent's investigation capabilities by providing access to data from your external observability tools, custom monitoring systems, and operational data sources.
|
| 4 |
+
|
| 5 |
+
## Requirements
|
| 6 |
+
+ Streamable HTTP transport protocol
|
| 7 |
+
+ Authentication: OAuth 2.0 (Client Credentials or 3LO), API key/token, or AWS SigV4
|
| 8 |
+
|
| 9 |
+
## Security considerations
|
| 10 |
+
+ Allowlist only specific tools needed per Agent Space
|
| 11 |
+
+ Maximum tool name length: 64 characters
|
| 12 |
+
+ Only allowlist read-only MCP tools
|
| 13 |
+
+ Custom MCP servers can introduce prompt injection risks
|
| 14 |
+
|
| 15 |
+
## Registering an MCP server (account-level)
|
| 16 |
+
|
| 17 |
+
### Step 1: MCP server details
|
| 18 |
+
+ Name, Endpoint URL, Description
|
| 19 |
+
+ Optional: Enable Dynamic Client Registration
|
| 20 |
+
+ Optional: Connect using private connection
|
| 21 |
+
|
| 22 |
+
### Step 2: Authorization flow
|
| 23 |
+
Select: OAuth Client Credentials, OAuth 3LO, API Key, or AWS SigV4
|
| 24 |
+
|
| 25 |
+
### Step 3: Authorization configuration
|
| 26 |
+
|
| 27 |
+
**OAuth Client Credentials:** Client ID, Client Secret, Exchange URL, Scopes
|
| 28 |
+
**OAuth 3LO:** Client ID, Client Secret, Exchange URL, Authorization URL, Scopes
|
| 29 |
+
**API Key:** Key name, header name, key value
|
| 30 |
+
**AWS SigV4:** IAM role, Region, Service Name, Custom Headers
|
| 31 |
+
|
| 32 |
+
### Step 4: Review and submit
|
| 33 |
+
|
| 34 |
+
## Configuring MCP tools in an Agent Space
|
| 35 |
+
|
| 36 |
+
1. Select Agent Space > Capabilities tab
|
| 37 |
+
2. MCP Servers section > Add
|
| 38 |
+
3. Select MCP server
|
| 39 |
+
4. Choose Allow all tools or Select specific tools
|
| 40 |
+
5. Choose Add
|
| 41 |
+
|
| 42 |
+
## Creating an IAM role for SigV4 authentication
|
| 43 |
+
|
| 44 |
+
Trust policy must allow aidevops.amazonaws.com with confused deputy protection (aws:SourceAccount, aws:SourceArn conditions).
|
| 45 |
+
|
| 46 |
+
For multi-region signing (SigV4a), enter * as the Region.
|
training/data/raw/configuring-capabilities-for-aws-devops-agent-connecting-multiple-aws-accounts.md
ADDED
|
@@ -0,0 +1,118 @@
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| 1 |
+
# Connecting Multiple AWS Accounts
|
| 2 |
+
|
| 3 |
+
You can connect secondary AWS accounts to AWS DevOps Agent for cross-account investigation. This allows the agent to access resources, logs, and metrics in accounts other than the one where it is deployed.
|
| 4 |
+
|
| 5 |
+
## Overview
|
| 6 |
+
|
| 7 |
+
When DevOps Agent needs to investigate issues that span multiple AWS accounts, you must configure cross-account IAM roles that grant the agent access to the secondary accounts. The agent assumes these roles to perform read operations in those accounts.
|
| 8 |
+
|
| 9 |
+
## Steps to Connect a Secondary Account
|
| 10 |
+
|
| 11 |
+
### Step 1: Start Configuration
|
| 12 |
+
|
| 13 |
+
In the DevOps Agent console, navigate to **Settings > AWS Accounts** and select **Add account**.
|
| 14 |
+
|
| 15 |
+
Provide:
|
| 16 |
+
- The AWS account ID of the secondary account
|
| 17 |
+
- A descriptive name for the account connection
|
| 18 |
+
- The IAM role name that DevOps Agent will assume
|
| 19 |
+
|
| 20 |
+
### Step 2: Specify the Role Name
|
| 21 |
+
|
| 22 |
+
Choose a role name for the cross-account role. The recommended naming convention is:
|
| 23 |
+
|
| 24 |
+
```
|
| 25 |
+
AIDevOpsAgentCrossAccountRole
|
| 26 |
+
```
|
| 27 |
+
|
| 28 |
+
This role will be created in the secondary account and assumed by DevOps Agent from the primary account.
|
| 29 |
+
|
| 30 |
+
### Step 3: Create the Role in the Secondary Account
|
| 31 |
+
|
| 32 |
+
In the secondary AWS account, create an IAM role with a trust policy that allows the DevOps Agent service role in your primary account to assume it.
|
| 33 |
+
|
| 34 |
+
Trust policy:
|
| 35 |
+
|
| 36 |
+
```json
|
| 37 |
+
{
|
| 38 |
+
"Version": "2012-10-17",
|
| 39 |
+
"Statement": [
|
| 40 |
+
{
|
| 41 |
+
"Effect": "Allow",
|
| 42 |
+
"Principal": {
|
| 43 |
+
"AWS": "arn:aws:iam::<primary-account-id>:role/AIDevOpsAgentServiceRole"
|
| 44 |
+
},
|
| 45 |
+
"Action": "sts:AssumeRole",
|
| 46 |
+
"Condition": {
|
| 47 |
+
"StringEquals": {
|
| 48 |
+
"sts:ExternalId": "<external-id-from-console>"
|
| 49 |
+
}
|
| 50 |
+
}
|
| 51 |
+
}
|
| 52 |
+
]
|
| 53 |
+
}
|
| 54 |
+
```
|
| 55 |
+
|
| 56 |
+
### Step 4: Attach AIDevOpsAgentAccessPolicy
|
| 57 |
+
|
| 58 |
+
Attach the AWS managed policy `AIDevOpsAgentAccessPolicy` to the role. This policy grants read-only access to the AWS services that DevOps Agent needs to investigate issues:
|
| 59 |
+
|
| 60 |
+
- CloudWatch Logs and Metrics
|
| 61 |
+
- AWS CloudTrail
|
| 62 |
+
- Amazon ECS and EKS
|
| 63 |
+
- AWS Lambda
|
| 64 |
+
- Amazon EC2
|
| 65 |
+
- AWS Systems Manager
|
| 66 |
+
- Amazon S3 (for log access)
|
| 67 |
+
|
| 68 |
+
### Step 5: Create an Inline Policy
|
| 69 |
+
|
| 70 |
+
Create an inline policy for any additional permissions specific to your environment. For example, if you use custom KMS keys for encryption:
|
| 71 |
+
|
| 72 |
+
```json
|
| 73 |
+
{
|
| 74 |
+
"Version": "2012-10-17",
|
| 75 |
+
"Statement": [
|
| 76 |
+
{
|
| 77 |
+
"Effect": "Allow",
|
| 78 |
+
"Action": [
|
| 79 |
+
"kms:Decrypt",
|
| 80 |
+
"kms:DescribeKey"
|
| 81 |
+
],
|
| 82 |
+
"Resource": "arn:aws:kms:<region>:<secondary-account-id>:key/<key-id>"
|
| 83 |
+
}
|
| 84 |
+
]
|
| 85 |
+
}
|
| 86 |
+
```
|
| 87 |
+
|
| 88 |
+
### Step 6: Complete Configuration
|
| 89 |
+
|
| 90 |
+
Return to the DevOps Agent console and complete the account connection setup. DevOps Agent will verify it can assume the role in the secondary account.
|
| 91 |
+
|
| 92 |
+
## Understanding Required Policies
|
| 93 |
+
|
| 94 |
+
### Trust Policy
|
| 95 |
+
|
| 96 |
+
The trust policy defines who can assume the role. It must specify:
|
| 97 |
+
- The principal (DevOps Agent service role ARN from the primary account)
|
| 98 |
+
- An external ID condition for security
|
| 99 |
+
- The `sts:AssumeRole` action
|
| 100 |
+
|
| 101 |
+
### Managed Policy (AIDevOpsAgentAccessPolicy)
|
| 102 |
+
|
| 103 |
+
This AWS-managed policy provides baseline read-only permissions across services commonly used during incident investigation. AWS maintains and updates this policy as DevOps Agent capabilities expand.
|
| 104 |
+
|
| 105 |
+
### Inline Policy
|
| 106 |
+
|
| 107 |
+
The inline policy provides account-specific permissions that go beyond the managed policy, such as:
|
| 108 |
+
- Access to customer-managed KMS keys
|
| 109 |
+
- Access to specific S3 buckets with custom resource policies
|
| 110 |
+
- Permissions for custom or third-party AWS services
|
| 111 |
+
|
| 112 |
+
## Best Practices
|
| 113 |
+
|
| 114 |
+
- Use the external ID condition in the trust policy to prevent confused deputy attacks.
|
| 115 |
+
- Regularly audit cross-account role usage via CloudTrail.
|
| 116 |
+
- Apply the principle of least privilege when creating inline policies.
|
| 117 |
+
- Tag cross-account roles for easy identification and management.
|
| 118 |
+
- Test the connection after setup to verify DevOps Agent can access resources.
|
training/data/raw/configuring-capabilities-for-aws-devops-agent-connecting-remote-a2a-agents.md
ADDED
|
@@ -0,0 +1,109 @@
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| 1 |
+
# Connecting Remote A2A Agents
|
| 2 |
+
|
| 3 |
+
You can extend the capabilities of AWS DevOps Agent by connecting remote agents that support the Agent-to-Agent (A2A) protocol. Remote A2A agents allow DevOps Agent to delegate specialized tasks to external agent systems.
|
| 4 |
+
|
| 5 |
+
## Requirements
|
| 6 |
+
|
| 7 |
+
To connect a remote A2A agent, it must meet the following requirements:
|
| 8 |
+
|
| 9 |
+
- **A2A Protocol Support**: The remote agent must implement the A2A protocol specification, exposing a valid agent card at a discoverable endpoint.
|
| 10 |
+
- **Authentication**: The remote agent must support one of the authentication methods recognized by DevOps Agent.
|
| 11 |
+
- **Network Accessibility**: The agent endpoint must be reachable from AWS DevOps Agent (either publicly or via a private connection).
|
| 12 |
+
|
| 13 |
+
## Security Considerations
|
| 14 |
+
|
| 15 |
+
When connecting remote A2A agents, consider the following:
|
| 16 |
+
|
| 17 |
+
- Remote agents receive context from DevOps Agent investigations, which may include sensitive operational data.
|
| 18 |
+
- Ensure the remote agent endpoint uses TLS encryption.
|
| 19 |
+
- Use the least-privilege authentication method appropriate for your use case.
|
| 20 |
+
- Regularly rotate credentials used for agent authentication.
|
| 21 |
+
- Monitor agent invocations through CloudWatch logs and metrics.
|
| 22 |
+
|
| 23 |
+
## Registration
|
| 24 |
+
|
| 25 |
+
### Agent Card Endpoint
|
| 26 |
+
|
| 27 |
+
The remote agent must expose an agent card at a well-known endpoint. The agent card describes the agent's capabilities, supported tasks, and authentication requirements.
|
| 28 |
+
|
| 29 |
+
```
|
| 30 |
+
https://your-agent-host/.well-known/agent.json
|
| 31 |
+
```
|
| 32 |
+
|
| 33 |
+
The agent card must include:
|
| 34 |
+
|
| 35 |
+
- Agent name and description
|
| 36 |
+
- Supported task types
|
| 37 |
+
- Input/output schemas
|
| 38 |
+
- Authentication requirements
|
| 39 |
+
|
| 40 |
+
### Authentication Methods
|
| 41 |
+
|
| 42 |
+
DevOps Agent supports the following authentication methods when connecting to remote A2A agents:
|
| 43 |
+
|
| 44 |
+
| Method | Description | Use Case |
|
| 45 |
+
|--------|-------------|----------|
|
| 46 |
+
| API Key | Static API key passed in a header | Simple integrations, development |
|
| 47 |
+
| Bearer Token | OAuth 2.0 bearer token | Token-based auth systems |
|
| 48 |
+
| OAuth 2.0 | Full OAuth 2.0 client credentials flow | Enterprise identity providers |
|
| 49 |
+
| SigV4 | AWS Signature Version 4 | AWS-hosted agents, IAM-based auth |
|
| 50 |
+
|
| 51 |
+
#### API Key Authentication
|
| 52 |
+
|
| 53 |
+
```json
|
| 54 |
+
{
|
| 55 |
+
"auth_type": "api_key",
|
| 56 |
+
"api_key_header": "X-API-Key",
|
| 57 |
+
"api_key_secret_arn": "arn:aws:secretsmanager:us-east-1:123456789012:secret:my-agent-key"
|
| 58 |
+
}
|
| 59 |
+
```
|
| 60 |
+
|
| 61 |
+
#### Bearer Token Authentication
|
| 62 |
+
|
| 63 |
+
```json
|
| 64 |
+
{
|
| 65 |
+
"auth_type": "bearer_token",
|
| 66 |
+
"token_secret_arn": "arn:aws:secretsmanager:us-east-1:123456789012:secret:my-agent-token"
|
| 67 |
+
}
|
| 68 |
+
```
|
| 69 |
+
|
| 70 |
+
#### OAuth 2.0 Authentication
|
| 71 |
+
|
| 72 |
+
```json
|
| 73 |
+
{
|
| 74 |
+
"auth_type": "oauth2",
|
| 75 |
+
"token_endpoint": "https://auth.example.com/oauth/token",
|
| 76 |
+
"client_id": "your-client-id",
|
| 77 |
+
"client_secret_arn": "arn:aws:secretsmanager:us-east-1:123456789012:secret:oauth-secret",
|
| 78 |
+
"scopes": ["agent:invoke"]
|
| 79 |
+
}
|
| 80 |
+
```
|
| 81 |
+
|
| 82 |
+
#### SigV4 Authentication
|
| 83 |
+
|
| 84 |
+
```json
|
| 85 |
+
{
|
| 86 |
+
"auth_type": "sigv4",
|
| 87 |
+
"service_name": "execute-api",
|
| 88 |
+
"region": "us-east-1"
|
| 89 |
+
}
|
| 90 |
+
```
|
| 91 |
+
|
| 92 |
+
## Associating with Agent Spaces
|
| 93 |
+
|
| 94 |
+
After registering a remote A2A agent, you must associate it with one or more Agent Spaces for it to be available during investigations.
|
| 95 |
+
|
| 96 |
+
1. Navigate to the Agent Space configuration.
|
| 97 |
+
2. Under **Connected Agents**, select **Add remote agent**.
|
| 98 |
+
3. Choose the registered A2A agent from the list.
|
| 99 |
+
4. Configure invocation permissions and any task-specific settings.
|
| 100 |
+
5. Save the Agent Space configuration.
|
| 101 |
+
|
| 102 |
+
The remote agent will now be available to DevOps Agent when working within that Agent Space. DevOps Agent will automatically determine when to delegate tasks to the remote agent based on the agent card's declared capabilities and the current investigation context.
|
| 103 |
+
|
| 104 |
+
## Managing Remote Agents
|
| 105 |
+
|
| 106 |
+
- **List registered agents**: View all registered remote A2A agents in the DevOps Agent console under Settings > Remote Agents.
|
| 107 |
+
- **Update credentials**: Rotate authentication credentials by updating the referenced Secrets Manager secret.
|
| 108 |
+
- **Remove an agent**: Disassociate from all Agent Spaces first, then delete the registration.
|
| 109 |
+
- **Monitor usage**: Check CloudWatch metrics for invocation counts, latency, and error rates per remote agent.
|
training/data/raw/configuring-capabilities-for-aws-devops-agent-connecting-telemetry-sources-index.md
ADDED
|
@@ -0,0 +1,65 @@
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| 1 |
+
# Connecting Telemetry Sources
|
| 2 |
+
|
| 3 |
+
AWS DevOps Agent can ingest telemetry data from multiple observability platforms to enrich its investigations. There are three ways to connect telemetry sources.
|
| 4 |
+
|
| 5 |
+
## Integration Types
|
| 6 |
+
|
| 7 |
+
### Built-in 2-Way Integrations
|
| 8 |
+
|
| 9 |
+
Two-way integrations allow DevOps Agent to both receive alerts from and query data in the telemetry platform.
|
| 10 |
+
|
| 11 |
+
| Platform | Capabilities |
|
| 12 |
+
|----------|-------------|
|
| 13 |
+
| Dynatrace | Receive incidents, query metrics/traces/logs, create mitigations |
|
| 14 |
+
|
| 15 |
+
With 2-way integrations, DevOps Agent can proactively pull additional context during investigations, such as related metrics, traces, and topology information.
|
| 16 |
+
|
| 17 |
+
### Built-in 1-Way Integrations
|
| 18 |
+
|
| 19 |
+
One-way integrations allow DevOps Agent to receive alerts and query data from the telemetry platform via MCP (Model Context Protocol) endpoints.
|
| 20 |
+
|
| 21 |
+
| Platform | Protocol | Capabilities |
|
| 22 |
+
|----------|----------|-------------|
|
| 23 |
+
| Amazon CloudWatch | Native AWS | Metrics, logs, alarms |
|
| 24 |
+
| Amazon S3 | Native AWS | Log files, data objects |
|
| 25 |
+
| Datadog | MCP over OAuth | Metrics, monitors, events |
|
| 26 |
+
| Grafana | MCP over Service Account | Dashboards, alerts, datasources |
|
| 27 |
+
| New Relic | MCP over API Key | APM, infrastructure, alerts |
|
| 28 |
+
| Splunk | MCP over Bearer Token | Search, alerts, dashboards |
|
| 29 |
+
|
| 30 |
+
One-way integrations receive webhook notifications for alerts and can query the platform for additional data during investigations.
|
| 31 |
+
|
| 32 |
+
### Bring-Your-Own via Webhook/MCP
|
| 33 |
+
|
| 34 |
+
For observability platforms not covered by built-in integrations, you can connect custom sources using:
|
| 35 |
+
|
| 36 |
+
- **Generic Webhooks**: Send alert data to DevOps Agent using the generic webhook endpoint with a standardized payload format.
|
| 37 |
+
- **Custom MCP Servers**: Connect any MCP-compatible server to provide DevOps Agent with access to custom data sources.
|
| 38 |
+
|
| 39 |
+
## Choosing an Integration Type
|
| 40 |
+
|
| 41 |
+
| Consideration | 2-Way | 1-Way | Bring-Your-Own |
|
| 42 |
+
|---------------|-------|-------|----------------|
|
| 43 |
+
| Setup complexity | Medium | Low | Variable |
|
| 44 |
+
| Data richness | Highest | High | Depends on implementation |
|
| 45 |
+
| Bidirectional actions | Yes | No | No |
|
| 46 |
+
| Maintenance | Managed by AWS | Managed by AWS | Customer-managed |
|
| 47 |
+
|
| 48 |
+
## Getting Started
|
| 49 |
+
|
| 50 |
+
1. Identify which telemetry platforms your team uses.
|
| 51 |
+
2. Check if a built-in integration exists for your platform.
|
| 52 |
+
3. Follow the platform-specific setup guide to register the integration.
|
| 53 |
+
4. Associate the telemetry source with an Agent Space.
|
| 54 |
+
5. Configure webhooks in your telemetry platform to send alerts to DevOps Agent.
|
| 55 |
+
|
| 56 |
+
## Common Configuration Steps
|
| 57 |
+
|
| 58 |
+
Regardless of the integration type, most telemetry connections follow this pattern:
|
| 59 |
+
|
| 60 |
+
1. **Register** the telemetry source with DevOps Agent (provide credentials and endpoint information).
|
| 61 |
+
2. **Enable** the source in one or more Agent Spaces.
|
| 62 |
+
3. **Configure** the external platform to send webhooks to DevOps Agent.
|
| 63 |
+
4. **Verify** the connection by triggering a test alert.
|
| 64 |
+
|
| 65 |
+
See the individual platform guides for detailed instructions.
|
training/data/raw/configuring-capabilities-for-aws-devops-agent-connecting-to-cicd-pipelines-index.md
ADDED
|
@@ -0,0 +1,11 @@
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| 1 |
+
# Connecting to CI/CD pipelines
|
| 2 |
+
|
| 3 |
+
CI/CD pipeline integration enables AWS DevOps Agent to monitor deployments and correlate code changes with operational incidents during investigations.
|
| 4 |
+
|
| 5 |
+
Two-step process:
|
| 6 |
+
1. Account-level registration – Register your CI/CD provider once
|
| 7 |
+
2. Agent Space connection – Connect specific projects or repositories
|
| 8 |
+
|
| 9 |
+
## Supported CI/CD providers
|
| 10 |
+
+ **GitHub** – Connect repositories from GitHub.com using the AWS DevOps Agent GitHub app.
|
| 11 |
+
+ **GitLab** – Connect projects from GitLab.com, managed GitLab instances, or publicly accessible self-hosted GitLab deployments.
|
training/data/raw/configuring-capabilities-for-aws-devops-agent-connecting-to-privately-hosted-tools.md
ADDED
|
@@ -0,0 +1,48 @@
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| 1 |
+
# Connecting to privately hosted tools
|
| 2 |
+
|
| 3 |
+
## Private connections overview
|
| 4 |
+
|
| 5 |
+
Private connections let you securely connect your Agent Space to services in your VPC without public internet exposure. Uses Amazon VPC Lattice for connectivity.
|
| 6 |
+
|
| 7 |
+
Works with: MCP servers, self-hosted Grafana/Splunk, GitHub Enterprise Server, GitLab Self-Managed.
|
| 8 |
+
|
| 9 |
+
## How private connections work
|
| 10 |
+
|
| 11 |
+
1. You provide VPC, subnets, and security groups
|
| 12 |
+
2. AWS DevOps Agent creates a service-managed resource gateway with ENIs
|
| 13 |
+
3. Traffic routes privately through the resource gateway to your service
|
| 14 |
+
|
| 15 |
+
## Security
|
| 16 |
+
+ No public internet exposure
|
| 17 |
+
+ Service-controlled resource gateway (read-only in your account)
|
| 18 |
+
+ Your security groups control traffic
|
| 19 |
+
+ Service-linked role with least privilege
|
| 20 |
+
|
| 21 |
+
## Create a private connection
|
| 22 |
+
|
| 23 |
+
### Prerequisites
|
| 24 |
+
+ Active Agent Space
|
| 25 |
+
+ Privately reachable target service (HTTPS, TLS 1.2+)
|
| 26 |
+
+ 1-20 subnets in your VPC
|
| 27 |
+
+ (Optional) Up to 5 security groups
|
| 28 |
+
|
| 29 |
+
### Using the console
|
| 30 |
+
1. Capability providers > Private connections > Create
|
| 31 |
+
2. Enter Name, VPC, Subnets, IP address type
|
| 32 |
+
3. (Optional) Security groups, Port ranges
|
| 33 |
+
4. Enter Host address (IP or DNS)
|
| 34 |
+
5. (Optional) Certificate public key for private CA
|
| 35 |
+
6. Create connection (up to 10 minutes)
|
| 36 |
+
|
| 37 |
+
### Using AWS CLI
|
| 38 |
+
```
|
| 39 |
+
aws devops-agent create-private-connection \
|
| 40 |
+
--name my-connection \
|
| 41 |
+
--mode '{"serviceManaged": {"hostAddress": "mcp.internal.example.com", "vpcId": "vpc-xxx", "subnetIds": ["subnet-xxx"], "portRanges": ["443"]}}'
|
| 42 |
+
```
|
| 43 |
+
|
| 44 |
+
## Use with capability providers
|
| 45 |
+
Select "Connect to endpoint using a private connection" during registration of MCP Server, GitHub, GitLab, or Grafana.
|
| 46 |
+
|
| 47 |
+
## Advanced: Self-managed mode
|
| 48 |
+
Provide your own VPC Lattice resource configuration ARN instead of having AWS DevOps Agent create one.
|
training/data/raw/configuring-capabilities-for-aws-devops-agent-connecting-to-ticketing-and-chat-index.md
ADDED
|
@@ -0,0 +1,8 @@
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| 1 |
+
# Connecting to ticketing and chat
|
| 2 |
+
|
| 3 |
+
AWS DevOps Agent participates in your team's existing communication channels. Connect to ticketing and alarming systems like ServiceNow and PagerDuty to automatically launch investigations from incident tickets. Connect to Slack to receive activity summaries in a chat channel.
|
| 4 |
+
|
| 5 |
+
Supported integrations:
|
| 6 |
+
+ **PagerDuty** - Trigger investigations from PagerDuty incidents using OAuth 2.0 Scoped OAuth
|
| 7 |
+
+ **ServiceNow** - Trigger investigations from ServiceNow tickets and receive updates in originating tickets
|
| 8 |
+
+ **Slack** - Receive investigation findings, root cause analyses, and mitigation plans in Slack channels
|
training/data/raw/configuring-capabilities-for-aws-devops-agent-integrating-devops-agent-into-event-driven-applications-using-amazon-eventbridge-index.md
ADDED
|
@@ -0,0 +1,39 @@
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| 1 |
+
# Integrating AWS DevOps Agent with Amazon EventBridge
|
| 2 |
+
|
| 3 |
+
AWS DevOps Agent sends events to Amazon EventBridge when investigation or mitigation states change. Create EventBridge rules to take action based on these events.
|
| 4 |
+
|
| 5 |
+
## How EventBridge routes events
|
| 6 |
+
1. AWS DevOps Agent sends event to default event bus
|
| 7 |
+
2. EventBridge evaluates against your rules
|
| 8 |
+
3. Matching events sent to specified targets
|
| 9 |
+
|
| 10 |
+
## Supported investigation events
|
| 11 |
+
| detail-type | Description |
|
| 12 |
+
| --- | --- |
|
| 13 |
+
| Investigation Created | Investigation created |
|
| 14 |
+
| Investigation In Progress | Active analysis started |
|
| 15 |
+
| Investigation Completed | Finished with findings |
|
| 16 |
+
| Investigation Failed | Error encountered |
|
| 17 |
+
| Investigation Timed Out | Exceeded max duration |
|
| 18 |
+
| Investigation Cancelled | Canceled before completion |
|
| 19 |
+
| Investigation Pending Triage | Awaiting triage |
|
| 20 |
+
| Investigation Linked | Linked to related incident |
|
| 21 |
+
| Investigation Skipped | Matched skip criteria |
|
| 22 |
+
|
| 23 |
+
## Supported mitigation events
|
| 24 |
+
| detail-type | Description |
|
| 25 |
+
| --- | --- |
|
| 26 |
+
| Mitigation In Progress | Started |
|
| 27 |
+
| Mitigation Completed | Finished |
|
| 28 |
+
| Mitigation Failed | Error |
|
| 29 |
+
| Mitigation Timed Out | Exceeded duration |
|
| 30 |
+
| Mitigation Cancelled | Canceled |
|
| 31 |
+
|
| 32 |
+
## Event patterns
|
| 33 |
+
|
| 34 |
+
Match all: `{"source": ["aws.aidevops"]}`
|
| 35 |
+
Match investigations only: `{"source": ["aws.aidevops"], "detail-type": [{"prefix": "Investigation"}]}`
|
| 36 |
+
Match specific space: `{"source": ["aws.aidevops"], "detail": {"metadata": {"agent_space_id": ["your-id"]}}}`
|
| 37 |
+
|
| 38 |
+
## Permissions
|
| 39 |
+
No additional permissions needed for event delivery. Configure target-specific permissions as needed.
|
training/data/raw/configuring-capabilities-for-aws-devops-agent-invoking-devops-agent-through-webhook.md
ADDED
|
@@ -0,0 +1,56 @@
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| 1 |
+
# Invoking DevOps Agent through Webhook
|
| 2 |
+
|
| 3 |
+
Webhooks allow external systems to automatically trigger AWS DevOps Agent investigations.
|
| 4 |
+
|
| 5 |
+
## Webhook types
|
| 6 |
+
+ **Integration-specific webhooks** – Auto-generated with third-party integrations
|
| 7 |
+
+ **Generic webhooks** – Manually created, use HMAC authentication
|
| 8 |
+
+ **Grafana alert webhooks** – Through Grafana contact points
|
| 9 |
+
|
| 10 |
+
## Authentication methods
|
| 11 |
+
|
| 12 |
+
**HMAC authentication** – Used by Dynatrace and generic webhooks
|
| 13 |
+
**Bearer token authentication** – Used by Splunk, Datadog, New Relic, ServiceNow, Slack, Grafana
|
| 14 |
+
|
| 15 |
+
| Consideration | HMAC | Bearer token |
|
| 16 |
+
| --- | --- | --- |
|
| 17 |
+
| Setup complexity | More complex | Simpler |
|
| 18 |
+
| Payload integrity | Verified | Not verified |
|
| 19 |
+
| Replay protection | Built-in | Not built-in |
|
| 20 |
+
| Secret exposure risk | Lower | Higher |
|
| 21 |
+
|
| 22 |
+
## Webhook request format
|
| 23 |
+
|
| 24 |
+
### HMAC (Version 1)
|
| 25 |
+
Headers: Content-Type, x-amzn-event-signature, x-amzn-event-timestamp
|
| 26 |
+
|
| 27 |
+
### Bearer token (Version 2)
|
| 28 |
+
Headers: Content-Type, Authorization: Bearer <token>
|
| 29 |
+
|
| 30 |
+
### Payload schema
|
| 31 |
+
```json
|
| 32 |
+
{
|
| 33 |
+
"eventType": "incident",
|
| 34 |
+
"incidentId": "string",
|
| 35 |
+
"action": "created | updated | closed | resolved",
|
| 36 |
+
"priority": "CRITICAL | HIGH | MEDIUM | LOW | MINIMAL",
|
| 37 |
+
"title": "string",
|
| 38 |
+
"description": "string",
|
| 39 |
+
"timestamp": "string",
|
| 40 |
+
"service": "string",
|
| 41 |
+
"data": {}
|
| 42 |
+
}
|
| 43 |
+
```
|
| 44 |
+
|
| 45 |
+
## Example (cURL, HMAC)
|
| 46 |
+
```bash
|
| 47 |
+
TIMESTAMP=$(date -u +%Y-%m-%dT%H:%M:%S.000Z)
|
| 48 |
+
PAYLOAD='{"eventType":"incident","incidentId":"test-123","action":"created","priority":"HIGH","title":"Test Alert"}'
|
| 49 |
+
SIGNATURE=$(echo -n "${TIMESTAMP}:${PAYLOAD}" | openssl dgst -sha256 -hmac "$SECRET" -binary | base64)
|
| 50 |
+
curl -X POST "$WEBHOOK_URL" -H "Content-Type: application/json" -H "x-amzn-event-timestamp: $TIMESTAMP" -H "x-amzn-event-signature: $SIGNATURE" -d "$PAYLOAD"
|
| 51 |
+
```
|
| 52 |
+
|
| 53 |
+
## Troubleshooting
|
| 54 |
+
+ No 200 response: Check authentication/headers
|
| 55 |
+
+ 200 but no investigation: Check payload format, ensure unique incidentId/timestamp
|
| 56 |
+
+ Investigation immediately cancelled: May have hit monthly limit
|
training/data/raw/configuring-capabilities-for-aws-devops-agent-migrating-from-public-preview-to-general-availability.md
ADDED
|
@@ -0,0 +1,41 @@
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| 1 |
+
# Migrating from public preview to general availability
|
| 2 |
+
|
| 3 |
+
If you used AWS DevOps Agent during public preview, you must update your IAM roles before the GA release.
|
| 4 |
+
|
| 5 |
+
## What's changing
|
| 6 |
+
|
| 7 |
+
1. On-demand chat histories during preview are no longer accessible
|
| 8 |
+
2. New managed policies replace policies available during preview
|
| 9 |
+
3. Agent Spaces may have an outdated IAM Identity Center application access scope
|
| 10 |
+
|
| 11 |
+
## New Managed Policies
|
| 12 |
+
|
| 13 |
+
| Role type | Remove | Add |
|
| 14 |
+
| --- | --- | --- |
|
| 15 |
+
| Monitoring | AIOpsAssistantPolicy managed policy | AIDevOpsAgentAccessPolicy managed policy |
|
| 16 |
+
| Operator (IAM and IDC) | Inline policy | AIDevOpsOperatorAppAccessPolicy managed policy |
|
| 17 |
+
|
| 18 |
+
## Step 1: Update monitoring roles
|
| 19 |
+
|
| 20 |
+
Update the monitoring role in your primary account and each secondary account:
|
| 21 |
+
1. Remove the AIOpsAssistantPolicy AWS managed policy
|
| 22 |
+
2. Attach the AIDevOpsAgentAccessPolicy managed policy
|
| 23 |
+
3. Update inline policy for Resource Explorer service-linked role creation
|
| 24 |
+
|
| 25 |
+
## Step 2: Update the operator role (IAM)
|
| 26 |
+
|
| 27 |
+
1. Remove the existing inline policy
|
| 28 |
+
2. Attach the AIDevOpsOperatorAppAccessPolicy managed policy
|
| 29 |
+
3. Update trust policy to include sts:TagSession
|
| 30 |
+
|
| 31 |
+
## Step 3: Update operator roles (IDC)
|
| 32 |
+
|
| 33 |
+
If you use IAM Identity Center:
|
| 34 |
+
1. Remove existing inline policy
|
| 35 |
+
2. Attach AIDevOpsOperatorAppAccessPolicy
|
| 36 |
+
3. Update trust policy with TrustedIdentityPropagation statement
|
| 37 |
+
4. Create inline policy for sso:ListInstances, identitystore:DescribeUser
|
| 38 |
+
|
| 39 |
+
## Reconnect IAM Identity Center (if applicable)
|
| 40 |
+
|
| 41 |
+
Agent Spaces created during preview may have outdated scope (awsaidevops:read_write instead of aidevops:read_write). Disconnect and reconnect IAM Identity Center to update.
|
training/data/raw/configuring-capabilities-for-aws-devops-agent-vended-logs-and-metrics.md
ADDED
|
@@ -0,0 +1,43 @@
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| 1 |
+
# Vended Logs and Metrics
|
| 2 |
+
|
| 3 |
+
Monitor agent spaces using CloudWatch metrics and vended logs.
|
| 4 |
+
|
| 5 |
+
## Vended CloudWatch metrics
|
| 6 |
+
|
| 7 |
+
Namespace: `AWS/AIDevOps`
|
| 8 |
+
|
| 9 |
+
| Metric name | Description | Unit |
|
| 10 |
+
| --- | --- | --- |
|
| 11 |
+
| ConsumedChatRequests | Chat requests consumed | Count |
|
| 12 |
+
| ConsumedInvestigationTime | Time spent on investigations | Seconds |
|
| 13 |
+
| ConsumedEvaluationTime | Time spent on evaluations | Seconds |
|
| 14 |
+
| TopologyCompletionCount | Topology processing completions | Count |
|
| 15 |
+
|
| 16 |
+
Dimension: AgentSpaceUUID
|
| 17 |
+
|
| 18 |
+
### Service-Linked Role
|
| 19 |
+
AWS DevOps Agent creates AWSServiceRoleForAIDevOps automatically. Customers before March 13, 2026 must create manually.
|
| 20 |
+
|
| 21 |
+
## Vended logs
|
| 22 |
+
|
| 23 |
+
Log type: APPLICATION_LOGS
|
| 24 |
+
|
| 25 |
+
Destinations:
|
| 26 |
+
+ Amazon CloudWatch Logs
|
| 27 |
+
+ Amazon S3
|
| 28 |
+
+ Amazon Data Firehose
|
| 29 |
+
|
| 30 |
+
### Log event types
|
| 31 |
+
| Event | Level |
|
| 32 |
+
| --- | --- |
|
| 33 |
+
| Agent inbound event received | INFO |
|
| 34 |
+
| Topology creation queued/started/finished | INFO |
|
| 35 |
+
| Resource discovery failed | ERROR |
|
| 36 |
+
| Service registration failed | ERROR |
|
| 37 |
+
| Webhook validation fails | ERROR |
|
| 38 |
+
| Association validation status updates | ERROR/INFO |
|
| 39 |
+
|
| 40 |
+
### Configure log delivery
|
| 41 |
+
Use the AWS DevOps Agent console (Settings or Agent Space Configuration tab) or CloudWatch Logs API (PutDeliverySource, PutDeliveryDestination, CreateDelivery).
|
| 42 |
+
|
| 43 |
+
Required permission: aidevops:AllowVendedLogDeliveryForResource
|
training/data/raw/configuring-capabilities-for-aws-devops-agent.md
ADDED
|
@@ -0,0 +1,16 @@
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| 1 |
+
# Configuring capabilities for AWS DevOps Agent
|
| 2 |
+
|
| 3 |
+
AWS DevOps Agent capabilities extend your agent's functionality by connecting it to your existing tools and infrastructure. Configure these capabilities to enable comprehensive incident investigation, automated response workflows, and seamless integration with your DevOps ecosystem.
|
| 4 |
+
|
| 5 |
+
The following capabilities help you maximize your DevOps Agent's effectiveness:
|
| 6 |
+
+ **AWS EKS Access Setup** - Enable introspection of Kubernetes clusters, pod logs, and cluster events for both public and private EKS environments
|
| 7 |
+
+ **Azure Integration** - Connect Azure subscriptions and Azure DevOps organizations to investigate Azure resources and correlate Azure DevOps deployments with incidents
|
| 8 |
+
+ **CI/CD Pipeline Integration** - Connect GitHub and GitLab pipelines to correlate deployments with incidents and track code changes during investigations
|
| 9 |
+
+ **MCP Server Connections** - Extend investigation capabilities by connecting external observability tools and custom monitoring systems through Model Context Protocol
|
| 10 |
+
+ **Multi-Account AWS Access** - Configure secondary AWS accounts to investigate resources across your entire organization during incident response
|
| 11 |
+
+ **Telemetry Source Integration** - Connect monitoring platforms like Datadog, Dynatrace, Grafana, New Relic, and Splunk for comprehensive observability data access
|
| 12 |
+
+ **Ticketing and Chat Integration** - Connect ServiceNow, PagerDuty, and Slack to automate incident response workflows and enable team collaboration
|
| 13 |
+
+ **Webhook Configuration** - Allow external systems to automatically trigger DevOps Agent investigations through HTTP requests
|
| 14 |
+
+ **Amazon EventBridge Integration** - Incorporate AWS DevOps Agent into event-driven applications by routing investigation and mitigation lifecycle events to Amazon EventBridge targets
|
| 15 |
+
|
| 16 |
+
You can configure each capability independently based on your team's specific needs and existing tool stack.
|
training/data/raw/connecting-azure-connecting-azure-devops.md
ADDED
|
@@ -0,0 +1,31 @@
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| 1 |
+
# Connecting Azure DevOps
|
| 2 |
+
|
| 3 |
+
Azure DevOps integration enables AWS DevOps Agent to access repositories and pipeline execution history in your Azure DevOps organization.
|
| 4 |
+
|
| 5 |
+
## Registering Azure DevOps via Admin Consent
|
| 6 |
+
|
| 7 |
+
1. Navigate to Capability Providers > Azure DevOps > Register
|
| 8 |
+
2. Enter Azure DevOps organization name
|
| 9 |
+
3. Complete admin consent flow
|
| 10 |
+
4. Complete user authorization
|
| 11 |
+
5. Grant access in Azure DevOps
|
| 12 |
+
|
| 13 |
+
## Registering Azure DevOps via App Registration
|
| 14 |
+
|
| 15 |
+
If already completed for Azure Resources, skip to Granting access.
|
| 16 |
+
|
| 17 |
+
## Granting access in Azure DevOps
|
| 18 |
+
|
| 19 |
+
1. In Azure DevOps: Organization Settings > Users > Add Users
|
| 20 |
+
2. Search for the application
|
| 21 |
+
3. Set access level to Basic
|
| 22 |
+
4. Select projects to access
|
| 23 |
+
5. Assign Project Readers group
|
| 24 |
+
|
| 25 |
+
**Security Requirement:** Assign only the Project Readers group for read-only access.
|
| 26 |
+
|
| 27 |
+
## Associating a project with an Agent Space
|
| 28 |
+
|
| 29 |
+
1. Select Agent Space > Capabilities tab
|
| 30 |
+
2. Pipelines section > Add > Azure DevOps
|
| 31 |
+
3. Select the project
|
training/data/raw/connecting-azure-connecting-azure-resources.md
ADDED
|
@@ -0,0 +1,38 @@
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| 1 |
+
# Connecting Azure Resources
|
| 2 |
+
|
| 3 |
+
Azure Resources integration enables AWS DevOps Agent to discover and investigate resources in your Azure subscriptions during incident investigations.
|
| 4 |
+
|
| 5 |
+
## Registering Azure Resources via Admin Consent
|
| 6 |
+
|
| 7 |
+
1. Navigate to Capability Providers page and Register Azure Cloud
|
| 8 |
+
2. Select Admin Consent method
|
| 9 |
+
3. Complete admin consent on Microsoft Entra page
|
| 10 |
+
4. Complete user authorization
|
| 11 |
+
5. Assign Reader role to the application in Azure Portal
|
| 12 |
+
|
| 13 |
+
## Registering Azure Resources via App Registration
|
| 14 |
+
|
| 15 |
+
1. Navigate to Capability Providers and Register
|
| 16 |
+
2. Select App Registration method
|
| 17 |
+
3. Create/configure Entra application with federated identity credentials
|
| 18 |
+
4. Provide Tenant ID, Client ID, Audience
|
| 19 |
+
5. Assign Reader role
|
| 20 |
+
|
| 21 |
+
## Assigning Azure roles
|
| 22 |
+
|
| 23 |
+
1. In Azure Portal, navigate to subscription > Access Control (IAM)
|
| 24 |
+
2. Add role assignment > Reader role
|
| 25 |
+
3. Select the application (AWS DevOps Agent or your Entra app)
|
| 26 |
+
|
| 27 |
+
**Security Requirement:** Only assign the Reader role. The Reader role restricts the agent to read-only operations.
|
| 28 |
+
|
| 29 |
+
### AKS access setup (optional)
|
| 30 |
+
|
| 31 |
+
1. Assign Azure Kubernetes Service Cluster User Role
|
| 32 |
+
2. For Kubernetes API access, use Azure RBAC (recommended) or Azure AD + Kubernetes RBAC
|
| 33 |
+
|
| 34 |
+
## Associating a subscription with an Agent Space
|
| 35 |
+
|
| 36 |
+
1. Select Agent Space > Capabilities tab
|
| 37 |
+
2. Secondary sources > Add > Azure
|
| 38 |
+
3. Provide Subscription ID
|
training/data/raw/connecting-telemetry-sources-connecting-datadog.md
ADDED
|
@@ -0,0 +1,98 @@
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| 1 |
+
# Connecting Datadog
|
| 2 |
+
|
| 3 |
+
AWS DevOps Agent supports a 1-way integration with Datadog. This integration allows DevOps Agent to receive alert notifications from Datadog and query Datadog for metrics, monitors, and events during investigations via an MCP endpoint.
|
| 4 |
+
|
| 5 |
+
## Prerequisites
|
| 6 |
+
|
| 7 |
+
- Datadog account with admin permissions
|
| 8 |
+
- An API Key and Application Key with appropriate scopes
|
| 9 |
+
- AWS DevOps Agent deployed and configured
|
| 10 |
+
|
| 11 |
+
## Step 1: Connect (MCP Endpoint with OAuth)
|
| 12 |
+
|
| 13 |
+
Register the Datadog integration with DevOps Agent by providing the MCP endpoint and OAuth credentials.
|
| 14 |
+
|
| 15 |
+
1. In the DevOps Agent console, navigate to **Telemetry Sources > Add > Datadog**.
|
| 16 |
+
2. Select your Datadog site region (determines the API endpoint).
|
| 17 |
+
3. Provide your Datadog API Key and Application Key.
|
| 18 |
+
4. DevOps Agent will configure the MCP endpoint for querying Datadog.
|
| 19 |
+
|
| 20 |
+
### Datadog Site Endpoints
|
| 21 |
+
|
| 22 |
+
| Site | Region | API Endpoint |
|
| 23 |
+
|------|--------|-------------|
|
| 24 |
+
| US1 | US (Virginia) | `https://api.datadoghq.com` |
|
| 25 |
+
| US3 | US (Oregon) | `https://api.us3.datadoghq.com` |
|
| 26 |
+
| US5 | US (Ohio) | `https://api.us5.datadoghq.com` |
|
| 27 |
+
| EU1 | EU (Frankfurt) | `https://api.datadoghq.eu` |
|
| 28 |
+
| AP1 | Asia Pacific (Tokyo) | `https://api.ap1.datadoghq.com` |
|
| 29 |
+
| AP2 | Asia Pacific (Sydney) | `https://api.ap2.datadoghq.com` |
|
| 30 |
+
|
| 31 |
+
Ensure you select the correct site that matches your Datadog organization.
|
| 32 |
+
|
| 33 |
+
## Step 2: Enable in Agent Space
|
| 34 |
+
|
| 35 |
+
Associate the Datadog integration with one or more Agent Spaces.
|
| 36 |
+
|
| 37 |
+
1. Navigate to the Agent Space configuration.
|
| 38 |
+
2. Under **Telemetry Sources**, select **Add source**.
|
| 39 |
+
3. Choose the registered Datadog integration.
|
| 40 |
+
4. Configure which Datadog services or tags to scope the integration (optional).
|
| 41 |
+
5. Save the Agent Space configuration.
|
| 42 |
+
|
| 43 |
+
## Step 3: Configure Webhooks
|
| 44 |
+
|
| 45 |
+
Configure Datadog to send alert notifications to DevOps Agent when monitors trigger.
|
| 46 |
+
|
| 47 |
+
1. In Datadog, navigate to **Integrations > Webhooks**.
|
| 48 |
+
2. Create a new webhook:
|
| 49 |
+
- **Name**: `aws-devops-agent`
|
| 50 |
+
- **URL**: The webhook URL provided in the DevOps Agent console
|
| 51 |
+
- **Payload**: Use the following JSON template:
|
| 52 |
+
|
| 53 |
+
```json
|
| 54 |
+
{
|
| 55 |
+
"event_type": "alert",
|
| 56 |
+
"source": "datadog",
|
| 57 |
+
"monitor_id": "$ALERT_ID",
|
| 58 |
+
"monitor_name": "$ALERT_TITLE",
|
| 59 |
+
"status": "$ALERT_TRANSITION",
|
| 60 |
+
"priority": "$ALERT_PRIORITY",
|
| 61 |
+
"tags": "$TAGS",
|
| 62 |
+
"hostname": "$HOSTNAME",
|
| 63 |
+
"message": "$TEXT_ONLY_MSG",
|
| 64 |
+
"snapshot_url": "$SNAPSHOT",
|
| 65 |
+
"timestamp": "$DATE"
|
| 66 |
+
}
|
| 67 |
+
```
|
| 68 |
+
|
| 69 |
+
3. **Custom Headers**: Add the authentication header:
|
| 70 |
+
- For HMAC: `X-Signature: <computed-hmac>`
|
| 71 |
+
- For Bearer: `Authorization: Bearer <token>`
|
| 72 |
+
|
| 73 |
+
4. **Assign to monitors**: Add the `@webhook-aws-devops-agent` notification to the monitors you want to route to DevOps Agent.
|
| 74 |
+
|
| 75 |
+
## Capabilities
|
| 76 |
+
|
| 77 |
+
With the Datadog integration, DevOps Agent can:
|
| 78 |
+
|
| 79 |
+
- Receive real-time monitor alert notifications
|
| 80 |
+
- Query metric timeseries data for specific hosts and services
|
| 81 |
+
- List and inspect monitor configurations
|
| 82 |
+
- Retrieve recent events and their context
|
| 83 |
+
- Correlate Datadog alerts with AWS resource state
|
| 84 |
+
|
| 85 |
+
## Scoping the Integration
|
| 86 |
+
|
| 87 |
+
You can limit which Datadog data DevOps Agent can access by:
|
| 88 |
+
|
| 89 |
+
- Restricting the Application Key's scopes
|
| 90 |
+
- Using tag-based filtering when associating with Agent Spaces
|
| 91 |
+
- Configuring monitor-specific webhook notifications
|
| 92 |
+
|
| 93 |
+
## Troubleshooting
|
| 94 |
+
|
| 95 |
+
- **Authentication failures**: Verify the API Key and Application Key are valid and have not been revoked.
|
| 96 |
+
- **Wrong endpoint**: Confirm you selected the correct Datadog site region.
|
| 97 |
+
- **Webhooks not firing**: Ensure the `@webhook-aws-devops-agent` mention is included in monitor notification messages.
|
| 98 |
+
- **Missing metrics**: Check that the Application Key has the `metrics_read` scope.
|
training/data/raw/connecting-telemetry-sources-connecting-dynatrace.md
ADDED
|
@@ -0,0 +1,121 @@
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| 1 |
+
# Connecting Dynatrace
|
| 2 |
+
|
| 3 |
+
AWS DevOps Agent supports a 2-way integration with Dynatrace SaaS. This integration allows DevOps Agent to receive incident notifications from Dynatrace and actively query the Dynatrace environment for metrics, traces, logs, and topology data during investigations.
|
| 4 |
+
|
| 5 |
+
## Prerequisites
|
| 6 |
+
|
| 7 |
+
- Dynatrace SaaS environment (not Dynatrace Managed)
|
| 8 |
+
- Dynatrace account with admin permissions to create OAuth clients
|
| 9 |
+
- AWS DevOps Agent deployed and configured
|
| 10 |
+
|
| 11 |
+
## Onboarding
|
| 12 |
+
|
| 13 |
+
### Step 1: Connect (OAuth Client Setup)
|
| 14 |
+
|
| 15 |
+
Create an OAuth client in Dynatrace to allow DevOps Agent to authenticate.
|
| 16 |
+
|
| 17 |
+
1. In Dynatrace, navigate to **Account Management > Identity & access management > OAuth clients**.
|
| 18 |
+
2. Create a new OAuth client with the following scopes:
|
| 19 |
+
- `storage:logs:read`
|
| 20 |
+
- `storage:metrics:read`
|
| 21 |
+
- `storage:events:read`
|
| 22 |
+
- `storage:entities:read`
|
| 23 |
+
- `storage:bizevents:read`
|
| 24 |
+
- `environment-api:metrics:read`
|
| 25 |
+
- `environment-api:entities:read`
|
| 26 |
+
- `environment-api:events:read`
|
| 27 |
+
- `environment-api:problems:read`
|
| 28 |
+
- `environment-api:slo:read`
|
| 29 |
+
3. Note the client ID and client secret.
|
| 30 |
+
4. In the DevOps Agent console, navigate to **Telemetry Sources > Add > Dynatrace**.
|
| 31 |
+
5. Enter the OAuth client ID and client secret.
|
| 32 |
+
|
| 33 |
+
### Step 2: Enable (Environment and Entity Configuration)
|
| 34 |
+
|
| 35 |
+
Configure which Dynatrace environment and entities DevOps Agent should monitor.
|
| 36 |
+
|
| 37 |
+
1. Provide the **Environment ID** of your Dynatrace SaaS environment.
|
| 38 |
+
- Found in your Dynatrace URL: `https://<environment-id>.live.dynatrace.com`
|
| 39 |
+
2. Specify **Entity IDs** to scope the integration:
|
| 40 |
+
- Host groups
|
| 41 |
+
- Management zones
|
| 42 |
+
- Specific services or applications
|
| 43 |
+
3. Associate the Dynatrace connection with an Agent Space.
|
| 44 |
+
|
| 45 |
+
### Step 3: Configure Dynatrace Environment
|
| 46 |
+
|
| 47 |
+
Install and configure the SRE Agents app in your Dynatrace environment.
|
| 48 |
+
|
| 49 |
+
1. In Dynatrace, go to the **Hub** and install the **SRE Agents** app.
|
| 50 |
+
2. Open the SRE Agents app and configure the webhook destination:
|
| 51 |
+
- Webhook URL: Provided in the DevOps Agent console after registration
|
| 52 |
+
- Authentication: HMAC signature verification
|
| 53 |
+
3. Configure which problem types should trigger notifications to DevOps Agent.
|
| 54 |
+
|
| 55 |
+
## Supported Event Schemas
|
| 56 |
+
|
| 57 |
+
### Incident Events
|
| 58 |
+
|
| 59 |
+
Dynatrace sends incident events when problems are detected:
|
| 60 |
+
|
| 61 |
+
```json
|
| 62 |
+
{
|
| 63 |
+
"event_type": "incident",
|
| 64 |
+
"source": "dynatrace",
|
| 65 |
+
"problem_id": "P-12345",
|
| 66 |
+
"title": "High CPU on host-001",
|
| 67 |
+
"severity": "CRITICAL",
|
| 68 |
+
"status": "OPEN",
|
| 69 |
+
"impact_level": "SERVICE",
|
| 70 |
+
"affected_entities": [
|
| 71 |
+
{
|
| 72 |
+
"entity_id": "HOST-ABC123",
|
| 73 |
+
"entity_type": "HOST",
|
| 74 |
+
"entity_name": "host-001"
|
| 75 |
+
}
|
| 76 |
+
],
|
| 77 |
+
"root_cause": {
|
| 78 |
+
"entity_id": "PROCESS_GROUP_INSTANCE-XYZ",
|
| 79 |
+
"entity_type": "PROCESS_GROUP_INSTANCE"
|
| 80 |
+
},
|
| 81 |
+
"start_time": "2024-01-15T10:30:00Z"
|
| 82 |
+
}
|
| 83 |
+
```
|
| 84 |
+
|
| 85 |
+
### Mitigation Events
|
| 86 |
+
|
| 87 |
+
DevOps Agent can send mitigation actions back to Dynatrace:
|
| 88 |
+
|
| 89 |
+
```json
|
| 90 |
+
{
|
| 91 |
+
"event_type": "mitigation",
|
| 92 |
+
"source": "aws_devops_agent",
|
| 93 |
+
"problem_id": "P-12345",
|
| 94 |
+
"action": "scale_up",
|
| 95 |
+
"status": "EXECUTED",
|
| 96 |
+
"details": {
|
| 97 |
+
"resource": "arn:aws:ecs:us-east-1:123456789012:service/my-service",
|
| 98 |
+
"previous_count": 2,
|
| 99 |
+
"new_count": 4
|
| 100 |
+
},
|
| 101 |
+
"timestamp": "2024-01-15T10:35:00Z"
|
| 102 |
+
}
|
| 103 |
+
```
|
| 104 |
+
|
| 105 |
+
## Capabilities
|
| 106 |
+
|
| 107 |
+
With the 2-way Dynatrace integration, DevOps Agent can:
|
| 108 |
+
|
| 109 |
+
- Receive real-time problem notifications
|
| 110 |
+
- Query metrics for affected entities
|
| 111 |
+
- Retrieve distributed traces for failing services
|
| 112 |
+
- Access log data related to detected problems
|
| 113 |
+
- Understand service topology and dependencies
|
| 114 |
+
- Correlate Dynatrace problems with AWS resource events
|
| 115 |
+
- Report mitigation actions taken back to Dynatrace
|
| 116 |
+
|
| 117 |
+
## Troubleshooting
|
| 118 |
+
|
| 119 |
+
- **OAuth errors**: Verify the client ID and secret, and ensure all required scopes are granted.
|
| 120 |
+
- **No events received**: Check that the SRE Agents app is installed and the webhook URL is correctly configured.
|
| 121 |
+
- **Missing data in queries**: Ensure the entity IDs are correct and the OAuth client has the necessary read scopes.
|
training/data/raw/connecting-telemetry-sources-connecting-grafana.md
ADDED
|
@@ -0,0 +1,115 @@
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| 1 |
+
# Connecting Grafana
|
| 2 |
+
|
| 3 |
+
AWS DevOps Agent supports integration with Grafana 9.0 and later. This integration allows DevOps Agent to receive alert notifications from Grafana and query dashboards, datasources, and alert rules during investigations.
|
| 4 |
+
|
| 5 |
+
## Prerequisites
|
| 6 |
+
|
| 7 |
+
- Grafana 9.0 or later (self-hosted or Grafana Cloud)
|
| 8 |
+
- Grafana service account with appropriate permissions
|
| 9 |
+
- AWS DevOps Agent deployed and configured
|
| 10 |
+
|
| 11 |
+
## Step 1: Register with Service Account Token
|
| 12 |
+
|
| 13 |
+
Create a Grafana service account and generate a token for DevOps Agent.
|
| 14 |
+
|
| 15 |
+
1. In Grafana, navigate to **Administration > Service Accounts**.
|
| 16 |
+
2. Create a new service account:
|
| 17 |
+
- **Name**: `aws-devops-agent`
|
| 18 |
+
- **Role**: Viewer (minimum required)
|
| 19 |
+
3. Generate a token for the service account and note it securely.
|
| 20 |
+
4. In the DevOps Agent console, navigate to **Telemetry Sources > Add > Grafana**.
|
| 21 |
+
5. Provide:
|
| 22 |
+
- **Grafana URL**: The base URL of your Grafana instance (e.g., `https://grafana.example.com`)
|
| 23 |
+
- **Service Account Token**: The token generated above
|
| 24 |
+
6. DevOps Agent will validate the connection and register the MCP endpoint.
|
| 25 |
+
|
| 26 |
+
## Step 2: Add to Agent Space
|
| 27 |
+
|
| 28 |
+
Associate the Grafana integration with an Agent Space.
|
| 29 |
+
|
| 30 |
+
1. Navigate to the Agent Space configuration.
|
| 31 |
+
2. Under **Telemetry Sources**, select **Add source**.
|
| 32 |
+
3. Choose the registered Grafana integration.
|
| 33 |
+
4. Optionally scope to specific folders or dashboards.
|
| 34 |
+
5. Save the configuration.
|
| 35 |
+
|
| 36 |
+
## Step 3: Configure Alert Webhooks
|
| 37 |
+
|
| 38 |
+
Configure Grafana to send alert notifications to DevOps Agent.
|
| 39 |
+
|
| 40 |
+
### Create a Contact Point
|
| 41 |
+
|
| 42 |
+
1. In Grafana, go to **Alerting > Contact points**.
|
| 43 |
+
2. Create a new contact point:
|
| 44 |
+
- **Name**: `aws-devops-agent`
|
| 45 |
+
- **Type**: Webhook
|
| 46 |
+
- **URL**: The webhook URL from the DevOps Agent console
|
| 47 |
+
- **HTTP Method**: POST
|
| 48 |
+
- **Authorization Header**: Bearer token or HMAC as configured
|
| 49 |
+
|
| 50 |
+
### Custom Notification Template
|
| 51 |
+
|
| 52 |
+
Create a custom notification template for the webhook payload:
|
| 53 |
+
|
| 54 |
+
1. Go to **Alerting > Notification templates**.
|
| 55 |
+
2. Create a new template:
|
| 56 |
+
|
| 57 |
+
```
|
| 58 |
+
{{ define "devops_agent_payload" }}
|
| 59 |
+
{
|
| 60 |
+
"event_type": "alert",
|
| 61 |
+
"source": "grafana",
|
| 62 |
+
"alert_name": "{{ .CommonLabels.alertname }}",
|
| 63 |
+
"status": "{{ .Status }}",
|
| 64 |
+
"severity": "{{ .CommonLabels.severity }}",
|
| 65 |
+
"summary": "{{ .CommonAnnotations.summary }}",
|
| 66 |
+
"description": "{{ .CommonAnnotations.description }}",
|
| 67 |
+
"dashboard_url": "{{ .CommonAnnotations.dashboard_url }}",
|
| 68 |
+
"panel_id": "{{ .CommonAnnotations.panel_id }}",
|
| 69 |
+
"values": {{ .Values | toJSON }},
|
| 70 |
+
"labels": {{ .CommonLabels | toJSON }},
|
| 71 |
+
"starts_at": "{{ .StartsAt }}",
|
| 72 |
+
"ends_at": "{{ .EndsAt }}"
|
| 73 |
+
}
|
| 74 |
+
{{ end }}
|
| 75 |
+
```
|
| 76 |
+
|
| 77 |
+
3. Assign the template to the `aws-devops-agent` contact point.
|
| 78 |
+
|
| 79 |
+
### Create a Notification Policy
|
| 80 |
+
|
| 81 |
+
1. Go to **Alerting > Notification policies**.
|
| 82 |
+
2. Create a policy that routes relevant alerts to the `aws-devops-agent` contact point.
|
| 83 |
+
3. Use label matchers to control which alerts are sent (e.g., `team=platform` or `severity=critical`).
|
| 84 |
+
|
| 85 |
+
## Capabilities
|
| 86 |
+
|
| 87 |
+
With the Grafana integration, DevOps Agent can:
|
| 88 |
+
|
| 89 |
+
- Receive real-time alert notifications
|
| 90 |
+
- Query dashboard panels for metric visualizations
|
| 91 |
+
- List and inspect alert rules and their states
|
| 92 |
+
- Access datasource queries for additional context
|
| 93 |
+
- Retrieve annotation data for correlation
|
| 94 |
+
|
| 95 |
+
## Limitations
|
| 96 |
+
|
| 97 |
+
### ClickHouse Not Supported
|
| 98 |
+
|
| 99 |
+
DevOps Agent cannot directly query ClickHouse datasources through the Grafana integration. If your Grafana dashboards use ClickHouse as a backend, the agent can view dashboard panels but cannot execute arbitrary ClickHouse queries.
|
| 100 |
+
|
| 101 |
+
### Amazon Managed Grafana Webhook Limitations
|
| 102 |
+
|
| 103 |
+
When using Amazon Managed Grafana:
|
| 104 |
+
|
| 105 |
+
- Webhooks must be configured through the AWS-managed alert notification channels.
|
| 106 |
+
- Some self-hosted Grafana webhook features may not be available.
|
| 107 |
+
- Ensure the Managed Grafana workspace has outbound network access to the DevOps Agent webhook endpoint.
|
| 108 |
+
- VPC endpoint configuration may be required for private connectivity.
|
| 109 |
+
|
| 110 |
+
## Troubleshooting
|
| 111 |
+
|
| 112 |
+
- **Authentication errors**: Verify the service account token is valid and has Viewer role.
|
| 113 |
+
- **Connection timeout**: Ensure the Grafana URL is reachable from DevOps Agent. Use a private connection if Grafana is not publicly accessible.
|
| 114 |
+
- **Missing dashboards**: Check that the service account has access to the folders containing the dashboards.
|
| 115 |
+
- **Webhooks not received**: Verify the notification policy routes alerts to the correct contact point.
|
training/data/raw/connecting-telemetry-sources-connecting-new-relic.md
ADDED
|
@@ -0,0 +1,120 @@
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| 1 |
+
# Connecting New Relic
|
| 2 |
+
|
| 3 |
+
AWS DevOps Agent supports a 1-way integration with New Relic. This integration allows DevOps Agent to receive alert notifications from New Relic and query APM, infrastructure, and alert data during investigations.
|
| 4 |
+
|
| 5 |
+
## Prerequisites
|
| 6 |
+
|
| 7 |
+
- New Relic account with a **Full Platform User** license
|
| 8 |
+
- New Relic User API Key (not the license key or ingest key)
|
| 9 |
+
- AWS DevOps Agent deployed and configured
|
| 10 |
+
|
| 11 |
+
## Step 1: Register
|
| 12 |
+
|
| 13 |
+
Register the New Relic integration with DevOps Agent.
|
| 14 |
+
|
| 15 |
+
1. In the DevOps Agent console, navigate to **Telemetry Sources > Add > New Relic**.
|
| 16 |
+
2. Provide the following:
|
| 17 |
+
- **API Key**: A New Relic User API Key with Full Platform User permissions
|
| 18 |
+
- **Account ID**: Your New Relic account ID (found in **Administration > Account settings**)
|
| 19 |
+
- **Region**: Select your New Relic data center region
|
| 20 |
+
|
| 21 |
+
### New Relic Regions
|
| 22 |
+
|
| 23 |
+
| Region | API Endpoint |
|
| 24 |
+
|--------|-------------|
|
| 25 |
+
| US | `https://api.newrelic.com` |
|
| 26 |
+
| EU | `https://api.eu.newrelic.com` |
|
| 27 |
+
|
| 28 |
+
3. DevOps Agent will validate the credentials and configure the MCP endpoint.
|
| 29 |
+
|
| 30 |
+
## Step 2: Enable in Agent Space
|
| 31 |
+
|
| 32 |
+
Associate the New Relic integration with an Agent Space.
|
| 33 |
+
|
| 34 |
+
1. Navigate to the Agent Space configuration.
|
| 35 |
+
2. Under **Telemetry Sources**, select **Add source**.
|
| 36 |
+
3. Choose the registered New Relic integration.
|
| 37 |
+
4. Optionally configure:
|
| 38 |
+
- Specific application names to monitor
|
| 39 |
+
- Tag-based filtering for entities
|
| 40 |
+
5. Save the Agent Space configuration.
|
| 41 |
+
|
| 42 |
+
## Step 3: Configure Webhooks
|
| 43 |
+
|
| 44 |
+
Configure New Relic to send alert notifications to DevOps Agent.
|
| 45 |
+
|
| 46 |
+
### Create a Notification Destination
|
| 47 |
+
|
| 48 |
+
1. In New Relic, navigate to **Alerts & AI > Destinations**.
|
| 49 |
+
2. Create a new destination:
|
| 50 |
+
- **Type**: Webhook
|
| 51 |
+
- **Name**: `aws-devops-agent`
|
| 52 |
+
- **Endpoint URL**: The webhook URL from the DevOps Agent console
|
| 53 |
+
- **Authentication**: Add the appropriate auth header (Bearer token or HMAC)
|
| 54 |
+
|
| 55 |
+
### Create a Notification Channel
|
| 56 |
+
|
| 57 |
+
1. Navigate to **Alerts & AI > Workflows**.
|
| 58 |
+
2. Create a new workflow or edit an existing one.
|
| 59 |
+
3. Add a notification channel:
|
| 60 |
+
- **Destination**: Select the `aws-devops-agent` webhook destination
|
| 61 |
+
- **Payload template**:
|
| 62 |
+
|
| 63 |
+
```json
|
| 64 |
+
{
|
| 65 |
+
"event_type": "alert",
|
| 66 |
+
"source": "new_relic",
|
| 67 |
+
"condition_name": "{{ conditionName }}",
|
| 68 |
+
"policy_name": "{{ policyName }}",
|
| 69 |
+
"account_id": "{{ accountId }}",
|
| 70 |
+
"status": "{{ state }}",
|
| 71 |
+
"severity": "{{ priority }}",
|
| 72 |
+
"incident_id": "{{ incidentId }}",
|
| 73 |
+
"details": "{{ details }}",
|
| 74 |
+
"entity": {
|
| 75 |
+
"name": "{{ entitiesData.names }}",
|
| 76 |
+
"type": "{{ entitiesData.types }}",
|
| 77 |
+
"id": "{{ entitiesData.ids }}"
|
| 78 |
+
},
|
| 79 |
+
"timestamp": "{{ createdAt }}",
|
| 80 |
+
"violation_url": "{{ violationChartUrl }}"
|
| 81 |
+
}
|
| 82 |
+
```
|
| 83 |
+
|
| 84 |
+
### Configure Workflow Filters
|
| 85 |
+
|
| 86 |
+
Use workflow filters to control which alerts are sent to DevOps Agent:
|
| 87 |
+
|
| 88 |
+
- Filter by policy name
|
| 89 |
+
- Filter by condition priority (Critical, High, Medium, Low)
|
| 90 |
+
- Filter by entity tags
|
| 91 |
+
|
| 92 |
+
## Capabilities
|
| 93 |
+
|
| 94 |
+
With the New Relic integration, DevOps Agent can:
|
| 95 |
+
|
| 96 |
+
- Receive real-time alert and incident notifications
|
| 97 |
+
- Query APM data (transactions, errors, throughput)
|
| 98 |
+
- Access infrastructure metrics (CPU, memory, disk)
|
| 99 |
+
- Retrieve alert condition configurations
|
| 100 |
+
- Query NRQL for custom data exploration
|
| 101 |
+
- Correlate New Relic incidents with AWS events
|
| 102 |
+
|
| 103 |
+
## API Key Requirements
|
| 104 |
+
|
| 105 |
+
The API Key must belong to a user with **Full Platform User** access. This ensures DevOps Agent can:
|
| 106 |
+
|
| 107 |
+
- Read APM application data
|
| 108 |
+
- Query infrastructure metrics
|
| 109 |
+
- Access alert policies and conditions
|
| 110 |
+
- Execute NRQL queries
|
| 111 |
+
- Read entity relationships
|
| 112 |
+
|
| 113 |
+
Keys from Basic or Core users will not have sufficient permissions.
|
| 114 |
+
|
| 115 |
+
## Troubleshooting
|
| 116 |
+
|
| 117 |
+
- **401 Unauthorized**: Verify the API Key is valid and belongs to a Full Platform User.
|
| 118 |
+
- **Wrong region**: Ensure US vs. EU region matches your New Relic account's data center.
|
| 119 |
+
- **Missing data**: Check that the account ID is correct and the API Key has access to the relevant accounts.
|
| 120 |
+
- **Webhook delivery failures**: Verify the endpoint URL is correct and the authentication header matches.
|
training/data/raw/connecting-telemetry-sources-connecting-splunk.md
ADDED
|
@@ -0,0 +1,46 @@
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| 1 |
+
# Connecting Splunk
|
| 2 |
+
|
| 3 |
+
## Built-in, 1 way integration
|
| 4 |
+
|
| 5 |
+
AWS DevOps Agent supports Splunk with built-in 1-way integration enabling:
|
| 6 |
+
+ **Automated Investigation triggering** - Splunk events can trigger investigations via webhooks.
|
| 7 |
+
+ **Telemetry introspection** - AWS DevOps Agent can introspect Splunk telemetry via the remote MCP server.
|
| 8 |
+
|
| 9 |
+
## Prerequisites
|
| 10 |
+
|
| 11 |
+
### Splunk Administrator steps
|
| 12 |
+
+ Enable REST API access
|
| 13 |
+
+ Enable token authentication
|
| 14 |
+
+ Create a new role 'mcp_user'
|
| 15 |
+
+ Assign 'mcp_user' role to authorized users
|
| 16 |
+
+ Create tokens with audience 'mcp'
|
| 17 |
+
|
| 18 |
+
### Splunk User steps
|
| 19 |
+
+ Get a token with audience 'mcp'
|
| 20 |
+
|
| 21 |
+
## Onboarding
|
| 22 |
+
|
| 23 |
+
### Step 1: Connect
|
| 24 |
+
|
| 25 |
+
1. Go to Capability Providers page
|
| 26 |
+
2. Find Splunk under Telemetry and choose Register
|
| 27 |
+
3. Enter details:
|
| 28 |
+
+ Server Name - Unique identifier
|
| 29 |
+
+ Endpoint URL: `https://<YOUR_SPLUNK_DEPLOYMENT_NAME>.api.scs.splunk.com/<YOUR_SPLUNK_DEPLOYMENT_NAME>/mcp/v1/`
|
| 30 |
+
+ Token Name and Token Value
|
| 31 |
+
|
| 32 |
+
### Step 2: Enable
|
| 33 |
+
|
| 34 |
+
1. Select Agent Space > Capabilities tab
|
| 35 |
+
2. Telemetry section > Add > Splunk
|
| 36 |
+
3. Review and Save
|
| 37 |
+
4. Copy Webhook URL and API Key
|
| 38 |
+
|
| 39 |
+
### Step 3: Configure webhooks
|
| 40 |
+
|
| 41 |
+
Use bearer token authentication with the API Key from Step 2.
|
| 42 |
+
|
| 43 |
+
## Removal
|
| 44 |
+
|
| 45 |
+
1. Remove from agent space (Capabilities > Telemetry > Splunk > Remove)
|
| 46 |
+
2. Deregister from account (Capability Providers > Deregister)
|
training/data/raw/connecting-to-cicd-pipelines-connecting-github.md
ADDED
|
@@ -0,0 +1,37 @@
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| 1 |
+
# Connecting GitHub
|
| 2 |
+
|
| 3 |
+
GitHub integration enables AWS DevOps Agent to access code repositories and receive deployment events during incident investigations. Supports both GitHub.com and GitHub Enterprise Server.
|
| 4 |
+
|
| 5 |
+
## Prerequisites
|
| 6 |
+
+ AWS DevOps Agent admin console access
|
| 7 |
+
+ GitHub user account or organization with admin permissions
|
| 8 |
+
+ Authorization to install GitHub apps
|
| 9 |
+
|
| 10 |
+
## Registering GitHub (account-level)
|
| 11 |
+
|
| 12 |
+
1. Navigate to Capabilities tab > Pipeline > Add > GitHub
|
| 13 |
+
2. Choose connection type (User or Organization)
|
| 14 |
+
3. For GitHub Enterprise Server, check "Use GitHub Enterprise Server" and enter HTTPS URL
|
| 15 |
+
4. Submit to begin GitHub App setup
|
| 16 |
+
5. Install the AWS DevOps Agent GitHub app
|
| 17 |
+
6. Select repositories (All or specific)
|
| 18 |
+
7. Choose Install & Authorize
|
| 19 |
+
|
| 20 |
+
## Connecting repositories to an Agent Space
|
| 21 |
+
|
| 22 |
+
1. Select Agent Space > Capabilities tab
|
| 23 |
+
2. Pipeline section > Add > GitHub
|
| 24 |
+
3. Select repositories
|
| 25 |
+
4. Choose Add
|
| 26 |
+
|
| 27 |
+
## Understanding the GitHub app
|
| 28 |
+
|
| 29 |
+
The app:
|
| 30 |
+
+ Requests repository access
|
| 31 |
+
+ Receives deployment events
|
| 32 |
+
+ Allows correlating code changes with incidents
|
| 33 |
+
+ Can be uninstalled through GitHub settings
|
| 34 |
+
|
| 35 |
+
## GitHub App permission updates
|
| 36 |
+
|
| 37 |
+
AWS DevOps Agent may request permission updates for new features. Accept requests when notified.
|
training/data/raw/connecting-to-cicd-pipelines-connecting-gitlab.md
ADDED
|
@@ -0,0 +1,29 @@
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| 1 |
+
# Connecting GitLab
|
| 2 |
+
|
| 3 |
+
GitLab integration enables AWS DevOps Agent to monitor deployments from GitLab Pipelines to inform causal investigations.
|
| 4 |
+
|
| 5 |
+
## Registering GitLab (account-level)
|
| 6 |
+
|
| 7 |
+
1. Navigate to Capability Providers > GitLab > Register
|
| 8 |
+
2. Select connection type (Personal or Group)
|
| 9 |
+
3. Select instance type (GitLab.com or self-hosted)
|
| 10 |
+
4. Provide personal access token with permissions:
|
| 11 |
+
+ read_repository
|
| 12 |
+
+ read_virtual_registry
|
| 13 |
+
+ read_registry
|
| 14 |
+
+ api
|
| 15 |
+
+ self_rotate
|
| 16 |
+
5. Set token expiration (max 365 days)
|
| 17 |
+
6. Submit registration
|
| 18 |
+
|
| 19 |
+
## Connecting projects to an Agent Space
|
| 20 |
+
|
| 21 |
+
1. Select Agent Space > Capabilities tab
|
| 22 |
+
2. Pipeline section > Add > GitLab
|
| 23 |
+
3. Select projects
|
| 24 |
+
4. Choose Save
|
| 25 |
+
|
| 26 |
+
## Managing GitLab connections
|
| 27 |
+
+ Update access token at account level if expired
|
| 28 |
+
+ View connected projects in Capabilities tab
|
| 29 |
+
+ Remove connections from Pipeline section
|
training/data/raw/connecting-to-ticketing-and-chat-connecting-pagerduty.md
ADDED
|
@@ -0,0 +1,29 @@
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| 1 |
+
# Connecting PagerDuty
|
| 2 |
+
|
| 3 |
+
PagerDuty integration enables AWS DevOps Agent to access and update incident data, on-call schedules, and service information using OAuth 2.0.
|
| 4 |
+
|
| 5 |
+
**Important:** Only PagerDuty OAuth 2.0 (Scoped OAuth) is supported. Legacy OAuth with redirect URI is not supported.
|
| 6 |
+
|
| 7 |
+
## PagerDuty requirements
|
| 8 |
+
+ PagerDuty account with OAuth client ID and client secret
|
| 9 |
+
+ PagerDuty account subdomain
|
| 10 |
+
|
| 11 |
+
## Registering PagerDuty
|
| 12 |
+
|
| 13 |
+
1. Go to Capability Providers > PagerDuty > Register
|
| 14 |
+
2. Select region (US or EU) and enter subdomain
|
| 15 |
+
3. Create app in PagerDuty: Integrations > App Registration > OAuth 2.0 Scoped OAuth
|
| 16 |
+
4. Required scopes: incidents.read, incidents.write, services.read, webhook_subscriptions.read, webhook_subscriptions.write
|
| 17 |
+
5. Enable Events Integration
|
| 18 |
+
6. Enter Client name, Client ID, Client secret
|
| 19 |
+
7. Submit
|
| 20 |
+
|
| 21 |
+
## Adding PagerDuty to an Agent Space
|
| 22 |
+
|
| 23 |
+
1. Select Agent Space > Capabilities tab
|
| 24 |
+
2. Communications > Add > PagerDuty
|
| 25 |
+
3. Save
|
| 26 |
+
|
| 27 |
+
## Webhook support
|
| 28 |
+
|
| 29 |
+
Only PagerDuty V3 webhooks are supported.
|
training/data/raw/connecting-to-ticketing-and-chat-connecting-servicenow.md
ADDED
|
@@ -0,0 +1,34 @@
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| 1 |
+
# Connecting ServiceNow
|
| 2 |
+
|
| 3 |
+
Connect ServiceNow to automatically initiate investigations when tickets are created and post findings into originating tickets.
|
| 4 |
+
|
| 5 |
+
## Initial Setup
|
| 6 |
+
|
| 7 |
+
### Create a ServiceNow OAuth application client
|
| 8 |
+
1. Enable client credential system property: glide.oauth.inbound.client.credential.grant_type.enabled = true
|
| 9 |
+
2. Navigate to System OAuth > Application Registry
|
| 10 |
+
3. Create New > OAuth - Client Credentials Grant
|
| 11 |
+
4. Set OAuth application user to "Problem Administrator"
|
| 12 |
+
|
| 13 |
+
### Connect OAuth client to AWS DevOps Agent
|
| 14 |
+
1. Navigate to Capability Providers > ServiceNow > Register
|
| 15 |
+
2. Enter Client Name, Client ID, Client Secret, Instance URL
|
| 16 |
+
3. Save webhook URL and secret
|
| 17 |
+
|
| 18 |
+
### Configure ServiceNow Business Rule
|
| 19 |
+
1. Navigate to Activity Subscriptions > Business Rules > New
|
| 20 |
+
2. Set Table to "Incident [incident]"
|
| 21 |
+
3. Check Advanced, set to run after Insert, Update, Delete
|
| 22 |
+
4. Add webhook script with your webhook secret and URL
|
| 23 |
+
|
| 24 |
+
## ServiceNow ticket updates
|
| 25 |
+
|
| 26 |
+
During investigations, DevOps Agent posts findings, root cause analyses, and mitigation plans as comments on the originating ticket.
|
| 27 |
+
|
| 28 |
+
## Ticket routing examples
|
| 29 |
+
|
| 30 |
+
### Filtering incidents
|
| 31 |
+
Use Business Rule filter conditions to send only specific tickets (e.g., by source, category, urgency).
|
| 32 |
+
|
| 33 |
+
### Routing across multiple Agent Spaces
|
| 34 |
+
Create separate Business Rules with different conditions routing to different Agent Space webhooks.
|
training/data/raw/connecting-to-ticketing-and-chat-connecting-slack.md
ADDED
|
@@ -0,0 +1,25 @@
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| 1 |
+
# Connecting Slack
|
| 2 |
+
|
| 3 |
+
Configure AWS DevOps Agent to update Slack channels with investigation findings, root cause analyses, and mitigation plans.
|
| 4 |
+
|
| 5 |
+
## Prerequisites
|
| 6 |
+
+ Slack workspace with ability to install third-party apps
|
| 7 |
+
+ Identified target Slack channels
|
| 8 |
+
|
| 9 |
+
## Register Slack integration
|
| 10 |
+
|
| 11 |
+
1. From Capability Providers > Slack > Register
|
| 12 |
+
2. Redirected to Slack for authorization
|
| 13 |
+
3. Install directly to workspaces (not organization level)
|
| 14 |
+
4. Choose workspace, review scopes, choose Allow
|
| 15 |
+
|
| 16 |
+
## Associate Slack with Agent Space
|
| 17 |
+
|
| 18 |
+
1. From Capabilities tab > Communications > Slack
|
| 19 |
+
2. Select Add Slack
|
| 20 |
+
3. Enter Channel ID
|
| 21 |
+
4. Choose Create
|
| 22 |
+
|
| 23 |
+
**Note:** The bot must be added to private channels before it can post messages.
|
| 24 |
+
|
| 25 |
+
**Important:** Avoid uninstalling the Slack app as it may prevent reinstallation.
|