AWS DevOps Agent: Investigasi Incident, Biaya dan Akurasi

Janji sebuah AI SRE selalu sama: alarm berbunyi jam 2 pagi, dan saat Anda membuka laptop sudah ada yang menarik metrics, membaca riwayat deploy, dan menuliskan hipotesis. AWS meresmikan janji itu pada 31 Maret 2026 saat DevOps Agent keluar dari preview, lengkap dengan credit pemakaian yang ikut dalam paket AWS Support, sehingga ia menjadi pembanding default bagi AI SRE lainnya.

Saya belum menjalankannya di akun production, jadi tulisan ini hasil membaca, bukan laporan lapangan. Semuanya berasal dari pengumuman AWS, halaman pricing, dan tiga halaman user guide yang saya baca ulang pada 17 Oktober 2026, ditambah satu tulisan independen dari Versent. Bila sebuah angka hanyalah klaim AWS dan bukan hasil ukur siapa pun, saya katakan demikian, dan sepertiga terakhir tulisan ini membahas cara mengukurnya di stack Anda sendiri.

Apa yang terjadi antara alert dan jawaban

Sebuah investigation adalah pipeline, bukan chat. User guide menjelaskan lima tahap, dan mengetahuinya memberi tahu di mana Anda perlu memasang kontrol sendiri.

1. Trigger. Investigation dimulai dari integrasi bawaan seperti ServiceNow, dari webhook (contoh di guide adalah tiket PagerDuty dan alarm Grafana), atau secara manual dari tab Incident Response di web app agent space.
2. Triage. Event eksternal diproses dalam hitungan detik untuk memutuskan apakah ia investigation baru atau bagian dari investigation yang sedang berjalan.
3. Investigation. Agent menyusun rencana, mengumpulkan temuan, dan dapat mendelegasikan ke sub-agent paralel. Masing-masing muncul di timeline lengkap dengan jumlah tool call dan durasinya, misalnya ec2-cpu-metrics dengan 5 tool call dan 50s.
4. Steering. Anda dapat mengirim pesan ke investigation yang sedang berjalan atau sudah selesai. Pesan itu masuk antrean dan dibaca di antara langkah reasoning, tidak pernah di tengah tool call, dengan panjang maksimal 32.768 karakter. Anda juga bisa fork sebuah investigation untuk menguji hipotesis lain tanpa kehilangan yang asli.
5. Mitigation. Setelah root cause analysis, agent menampilkan usulan mitigation langsung di halaman. Tiap usulan memuat tindakan yang disarankan, hasil yang diharapkan, dan prasyaratnya; Anda bisa menyesuaikan parameternya dan memilih apakah akan menerapkannya.

Dua detail penting untuk bagian berikutnya. Pertama, agent mengorelasikan telemetry, kode, dan data deployment; pengumuman GA menyebut CloudWatch, Datadog, Dynatrace, New Relic, Splunk, GitHub Actions, GitLab CI/CD, ServiceNow, dan Slack sebagai integrasi yang sudah ada, dengan PagerDuty, Grafana, Azure DevOps, dan EventBridge ditambahkan saat GA. Kedua, tulisan Versent di masa preview menyebutnya read-only dan bersifat advisory, sedangkan guide saat ini menyatakan Anda memilih apakah tiap usulan diterapkan. Saya tidak menguji apa yang terjadi saat usulan diterapkan, jadi periksa sendiri jalur write-nya di space Anda sebelum bergantung pada salah satu deskripsi itu.

Triage menentukan apakah Anda membayar investigation kedua

Triage adalah tahap yang paling langsung mengatur biaya, karena alert duplikat yang di-link tidak memulai investigation sendiri. Agent membandingkan incident baru dengan investigation aktif dalam look-back window yang menurut guide biasanya 20 menit, dengan menimbang kemiripan komponen, region geografis, dan pola waktu.

Kedua jalur koreksi itu manual. Anda juga bisa menulis aturan korelasi sendiri sebagai skill dan menempelkannya ke tahap triage; itu tuas yang akan saya coba pertama bila dua alarm yang tidak berhubungan terus digabung. Triage juga tempat termurah untuk menahan noise: incident yang di-skip dibuang tanpa investigation, sedangkan investigation untuk alarm yang flapping memakan agent time yang ditagih.

Setup lewat CLI, bukan console

CLI onboarding guide menyebut seluruh setup memakan sekitar 20 menit dan tersedia di enam Region: N. Virginia, Oregon, Sydney, Tokyo, Frankfurt, dan Ireland. Ada dua role. Agent space role dipakai agent untuk membaca resource Anda, dan trust policy-nya dikunci ke akun Anda dan ke agent space di akun Anda. Operator app role terpisah, dengan managed policy AIDevOpsOperatorAppAccessPolicy, memberi akses web app kepada manusia. Blok pertama membuat agent space role dan sebuah agent space.

# 1. The agent space role. The trust policy is what stops a confused deputy:
#    only an agent space in YOUR account may assume it.
cat > devops-agentspace-trust-policy.json << 'EOF'
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": { "Service": "aidevops.amazonaws.com" },
      "Action": "sts:AssumeRole",
      "Condition": {
        "StringEquals": { "aws:SourceAccount": "<MONITORING_ACCOUNT_ID>" },
        "ArnLike": {
          "aws:SourceArn": "arn:aws:aidevops:<REGION>:<MONITORING_ACCOUNT_ID>:agentspace/*"
        }
      }
    }
  ]
}
EOF

aws iam create-role --region <REGION> \
  --role-name DevOpsAgentRole-AgentSpace \
  --assume-role-policy-document file://devops-agentspace-trust-policy.json

# AWS-managed policy. Start here, then narrow it for production.
aws iam attach-role-policy \
  --role-name DevOpsAgentRole-AgentSpace \
  --policy-arn arn:aws:iam::aws:policy/AIDevOpsAgentAccessPolicy

# 2. One agent space per application, not one per company.
aws devops-agent create-agent-space \
  --name "checkout-service" \
  --description "AgentSpace for the checkout service" \
  --region <REGION>

# 3. Associate the account. "monitor" = the account that hosts the agent
#    and is used for topology discovery. Extra accounts use "source".
aws devops-agent associate-service \
  --agent-space-id <AGENT_SPACE_ID> \
  --service-id aws \
  --configuration '{
    "aws": {
      "assumableRoleArn": "arn:aws:iam::<MONITORING_ACCOUNT_ID>:role/DevOpsAgentRole-AgentSpace",
      "accountId": "<MONITORING_ACCOUNT_ID>",
      "accountType": "monitor"
    }
  }' \
  --region <REGION>

Skill dan trigger adalah tempat runbook Anda sendiri masuk. Skill adalah file SKILL.md yang dimuat agent saat relevan. Pengumuman GA menyebut skill bisa menarget agent On-demand, Incident Triage, Incident RCA, Incident Mitigation, atau Evaluation, dan contoh di guide memakai tipe agent generik. Blok kedua menunjukkan contoh skill dan trigger harian dari guide.

# A skill the agent loads when relevant. Procedures live here, not in a prompt.
aws devops-agent create-asset \
  --agent-space-id <AGENT_SPACE_ID> \
  --asset-type skill \
  --metadata '{"name":"rds-performance-investigation","description":"Investigation procedures for RDS performance issues.","agent_types":["GENERIC"]}' \
  --content '{"file":{"path":"SKILL.md","body":{"text":"# RDS Performance Investigation\nUse this skill when investigating database latency, connection errors, or query timeouts."}}}' \
  --region <REGION>

# A time-based trigger that runs a custom agent daily. Pause it with
# update-trigger --status Inactive instead of deleting it.
aws devops-agent create-trigger \
  --agent-space-id <AGENT_SPACE_ID> \
  --type TIME_BASED \
  --condition '{"schedule":{"expression":"rate(1 day)"}}' \
  --action '{"actionType":"create:task","task":{"agent":"custom:<CUSTOM_AGENT_ASSET_ID>"}}' \
  --status Active \
  --region <REGION>

Sumber pihak ketiga bekerja dengan cara yang sama. Mendaftarkan Dynatrace, Splunk, New Relic, atau Datadog lalu memanggil associate-service mengembalikan informasi webhook yang bisa Anda arahkan dari alerting mereka, sedangkan GitHub dan Datadog harus didaftarkan dulu lewat alur OAuth di console. Aktifkan log bertipe APPLICATION_LOGS sejak awal: ia mencatat event seperti inbound event dropped, third-party provider call failed, dan webhook validation fails, yaitu kegagalan senyap khas pipeline alert.

Apa yang ditagih, dan hitungannya

Tagihannya $0.0083 per agent-second untuk investigation, evaluation, dan on-demand SRE task. Halaman pricing mendefinisikan agent time sebagai waktu kumulatif agent bekerja aktif di semua aktivitas untuk sebuah task, dan menyatakan tidak ada biaya saat agent idle atau menunggu. Itu $0.498 per agent-minute, jadi investigation 8 menit sekitar $3.98. Tabel ini menyalin contoh dari halaman pricing sendiri; durasi 8 menit adalah asumsi AWS, bukan hasil pengukuran.

Ada dua pengurang. Pelanggan baru mendapat free trial 2 bulan, tiap bulan mencakup hingga 10 agent space, 20 jam investigation, 15 jam evaluation, dan 20 jam on-demand task. Pelanggan paket AWS Support berbayar mendapat credit bulanan yang dihitung dari tagihan Support bulan sebelumnya: 100% untuk Unified Operations, 75% untuk Enterprise Support, dan 30% untuk Business Support+. Credit itu kedaluwarsa di akhir bulan, jadi ia diskon, bukan saldo.

Baca kalimat terakhir halaman pricing sebelum menyusun budget: layanan AWS lain yang di-query agent, seperti CloudWatch Logs Insights query atau pengambilan trace, ditagih oleh layanan itu dengan tarif standarnya. Tarif agent-second karena itu hanyalah batas bawah biaya sebuah investigation, dan semakin besar log group yang dipindai, semakin kecil artinya.

Alarm budget harian, karena saya tidak menemukan spend cap

Saya tidak menemukan pengaturan yang membatasi agent time bulanan di halaman pricing maupun halaman guide yang saya baca, dan tagihan dihitung dari durasi, jadi alarm berisik yang memicu investigation panjang adalah jalan menuju tagihan mengejutkan. Layanan ini menerbitkan metrics CloudWatch sendiri, cukup untuk membangun pengaman. Contoh di guide membuat alarm pada ConsumedOnDemandTime dengan statistik Sum, period 1 hari, dan threshold 36000 detik, yaitu 10 jam atau $298.80. Blok di bawah menerapkan ide yang sama untuk investigation; threshold 9600 detik adalah contoh saya, 20 investigation masing-masing 8 menit, bukan rekomendasi.

# metrics.json: a daily budget alarm over ConsumedInvestigationTime.
# Metric math alarms cannot use SEARCH(), so list each agent space explicitly.
# FILL(..., 0) stops a quiet space from turning the sum into "no data".
[
  {
    "Id": "space1",
    "MetricStat": {
      "Metric": {
        "Namespace": "AWS/AIDevOps",
        "MetricName": "ConsumedInvestigationTime",
        "Dimensions": [{ "Name": "AgentSpaceUUID", "Value": "<SPACE_1_UUID>" }]
      },
      "Period": 86400,
      "Stat": "Sum"
    },
    "ReturnData": false
  },
  {
    "Id": "space2",
    "MetricStat": {
      "Metric": {
        "Namespace": "AWS/AIDevOps",
        "MetricName": "ConsumedInvestigationTime",
        "Dimensions": [{ "Name": "AgentSpaceUUID", "Value": "<SPACE_2_UUID>" }]
      },
      "Period": 86400,
      "Stat": "Sum"
    },
    "ReturnData": false
  },
  {
    "Id": "total",
    "Expression": "FILL(space1, 0) + FILL(space2, 0)",
    "Label": "Investigation seconds per day",
    "ReturnData": true
  }
]

# 9600 seconds = 20 investigations of 8 minutes = about $79.68 at $0.0083/s.
aws cloudwatch put-metric-alarm \
  --alarm-name devops-agent-daily-investigation-budget \
  --metrics file://metrics.json \
  --comparison-operator GreaterThanThreshold \
  --threshold 9600 \
  --evaluation-periods 1 \
  --treat-missing-data notBreaching \
  --alarm-actions arn:aws:sns:<REGION>:<MONITORING_ACCOUNT_ID>:finops-alerts

Semua metrics berada di namespace AWS/AIDevOps dengan satu dimension, AgentSpaceUUID, dan query tanpa dimension itu tidak mengembalikan data point. Metrics diterbitkan setiap 5 menit kecuali metric topology. Metrics menghitung detik, bukan dolar, jadi kalikan sendiri dengan 0.0083.

Satu jebakan dari guide: agent space yang dibuat sebelum 13 Maret 2026 tidak mendapat metrics ini sampai Anda membuat sendiri service-linked role AWSServiceRoleForAIDevOps dengan aws iam create-service-linked-role dan nama service aidevops.amazonaws.com. Space yang lebih baru mendapatkannya otomatis. Karena metrics hanya mencakup agent time, ia juga tidak akan memperingatkan Anda soal biaya query CloudWatch di bagian sebelumnya.

Menguji klaim akurasi root cause 94%

Pengumuman GA mengaitkan hingga 75% MTTR lebih rendah, investigation 80% lebih cepat, akurasi root cause 94%, dan resolusi incident 3 sampai 5x lebih cepat dengan pelanggan dan partner di masa preview. Cara pengukurannya tidak dijelaskan: tidak ada jumlah incident, tidak ada siapa yang menilai root cause benar, dan tidak ada keterangan apakah root cause yang butuh steering manusia tetap dihitung. Dua kisah pelanggan hanyalah incident tunggal. Western Governors University turun dari perkiraan dua jam menjadi 28 menit, yang oleh AWS disebut perbaikan 77%, dan Zenchef dari perkiraan 1 sampai 2 jam menjadi 20 sampai 30 menit. Di keduanya, baseline-nya adalah perkiraan.

Itu tidak berarti klaimnya salah. Artinya klaim itu tidak bisa dibandingkan dengan angka dari sistem Anda sebelum Anda punya angkanya. Produknya menyediakan alatnya: setelah investigation selesai Anda bisa menambah feedback dengan verdict wajib, root cause sebenarnya bila agent salah, apakah steering dibutuhkan, dan apakah mitigation-nya benar. Anda juga bisa meminta agent di chat merangkum riwayat feedback, dan ia melaporkan jumlah, persentase akurasi, dan rincian per verdict. Menandai investigation sebagai salah beserta penyebab sebenarnya juga menulis memory agar alarm yang sama lebih kecil kemungkinannya mengulang kesalahan.

// Wilson score interval for "k root causes judged correct out of n".
// The point estimate hides how little n tells you.
function wilson(k, n, z = 1.96) {
  const p = k / n;
  const d = 1 + (z * z) / n;
  const centre = (p + (z * z) / (2 * n)) / d;
  const margin = (z * Math.sqrt((p * (1 - p)) / n + (z * z) / (4 * n * n))) / d;
  return [centre - margin, centre + margin];
}

wilson(18, 20);   // 90% observed  -> about 0.70 to 0.97
wilson(47, 50);   // 94% observed  -> about 0.84 to 0.98
wilson(94, 100);  // 94% observed  -> about 0.88 to 0.97

Masalahnya ada pada ukuran sampel. Persentase dari 20 investigation yang direview itu lebar. Dengan Wilson score interval, 18 dari 20 benar berarti 90% teramati tetapi masuk akal berada di antara sekitar 70% dan 97%, dan bahkan 94 dari 100 mencakup sekitar 88% sampai 97%. Hitungan itu milik saya, bukan AWS, tetapi ia menjelaskan mengapa tim dengan 10 incident tidak bisa mengonfirmasi atau membantah angka headline. Catat steering terpisah dari kebenaran, karena jawaban yang benar hanya setelah Anda mengarahkannya adalah produk yang berbeda dari jawaban yang benar sendirian.

Di mana ia bisa membuat biaya membengkak, dan di mana ia bisa menyesatkan

Mode kegagalan yang pertama akan saya antisipasi bukan jawaban salah, melainkan jawaban yakin yang dibangun di atas topology yang tidak cocok dengan kenyataan. Empat batasan ini langsung dari dokumentasi dan uji Versent.

• Bentuk environment menentukan kualitas. Dalam uji preview Versent di beberapa akun dengan ratusan service, agent menyimpulkan struktur workload dari konvensi penamaan, dan penamaan yang konsisten membantu. Ringkasan mereka: garbage in, garbage out.
• Triage bisa menggabungkan incident yang tidak berhubungan. Link yang salah berarti satu investigation membawa dua masalah sampai manusia melakukan unlink, dan look-back window-nya biasanya 20 menit.
• Biaya mengikuti durasi, bukan jumlah incident. Sepuluh investigation singkat bisa lebih murah daripada satu yang berkelana, dan saya tidak menemukan cap keras, hanya alarm di atas.
• Eskalasi membagikan data. Ask for human support meneruskan investigation timeline, resource terdampak, metrics, log, dan trace yang relevan, perubahan terbaru, dan upaya remediation ke AWS Support. Basic Support tidak bisa membuat technical case, dan Developer Support bisa membuatnya tetapi harus memakai Support Center untuk berkorespondensi.

Catatan soal tanggal: pengujian Versent dilakukan pada preview, sebelum tahap triage, skill, dan code indexing yang disebut pengumuman GA, jadi temuannya adalah prior, bukan vonis. Uji ulang di estate Anda sendiri.

Yang dikerjakan hari Senin

Perlakukan free trial sebagai eksperimen dengan aturan berhenti, bukan rollout. Tujuannya dua puluh investigation yang direview dan sebuah keputusan, bukan sebuah dashboard.

1. Pilih satu aplikasi yang terstruktur baik, sebaiknya di akun non-production, dan buat satu agent space untuknya dengan role berbasis managed policy AIDevOpsAgentAccessPolicy.
2. Hubungkan sumber alert yang sudah Anda pakai untuk paging, webhook PagerDuty atau Grafana atau ServiceNow, dan aktifkan pengiriman APPLICATION_LOGS agar event yang dibuang dan kegagalan validasi webhook terlihat.
3. Buat alarm budget harian sebelum investigation nyata pertama, dengan ukuran sesuai batas trial yang ingin Anda patuhi.
4. Putar ulang incident terbaru yang sudah selesai dengan memulai investigation secara manual; dialognya memungkinkan Anda menyesuaikan tanggal dan jam incident. Tambahkan feedback dengan verdict pada setiap investigation, dan catat apakah steering dibutuhkan.
5. Setelah sekitar dua puluh investigation direview, hitung intervalnya dan putuskan. Pada saat yang sama, cek apakah persentase credit paket Support Anda menutup proyeksi agent time.

Bila batas bawah interval Anda lebih rendah daripada akurasi yang akan Anda terima dari engineer on-call junior, jawabannya sudah ada: pakai untuk triage dan pengumpulan evidence, dan biarkan keputusan root cause tetap di tangan manusia.

Aturan yang saya bawa dari sini: hargai sebuah AI SRE dari agent time yang bisa Anda pasangi alarm, dan nilai dari verdict yang Anda catat sendiri. AWS DevOps Agent memungkinkan keduanya lewat tagihan per detik, metrics CloudWatch, dan form feedback, tetapi ia tidak menyertakan spend cap maupun angka akurasi milik Anda, jadi yang pertama Anda bangun dan yang kedua Anda dapatkan sendiri.