Menuju AI Agentik di AWS

Re:Invent 2025 menandai titik balik bagi AWS, beralih dari AI generatif ke AI agen, dengan agen otonom yang mampu berkolaborasi dengan anggota tim. Agentcore batuan dasar adalah contohnya.

Keluarga Agen Perbatasan

Dalam visi ini, AWS memperkenalkan rangkaian baru Agen Frontier yang mencakup seluruh siklus hidup perangkat lunak:

• Agen Otonomi Kiro“pengembang virtual” berorientasi pengembangan berbasis spesifikasi yang telah kita bicarakan di blog, yang dimulai dari spesifikasi yang dapat dieksekusi untuk merancang, mengimplementasikan, dan mengembangkan aplikasi Anda.
• Agen AWS DevOpsAgen yang akan kita bahas disini diposisikan sebagai SRE virtual yang bertanggung jawab menjaga layanan dalam kondisi operasional.
• Agen Keamanan AWSinsinyur keamanan virtual yang melakukan industrialisasi tinjauan desain, tinjauan kode, dan uji intrusi sepanjang siklus hidup aplikasi.

Cara Kerja Agen AWS DevOps

AWS Devops Agent adalah agen AI otonom yang memetakan infrastruktur Anda, menggunakan sinyal observabilitas, dan mengotomatiskan sebagian besar proses. Hal ini dapat dipicu oleh peringatan (CloudWatch, Datadog, Dynatrace, New Relic, Grafana, Splunk, dll.), melalui tiket, atau melalui interaksi obrolan sederhana. Dia menyelidiki insiden tersebut, mengusulkan tindakan remediasi, dan dapat berkomunikasi dengan tim yang dijalankan melalui Slack, ServiceNow, atau PagerDuty untuk membagikan analisis dan rencana tindakannya.

Untuk berintegrasi dengan sistem eksternal, ini bergantung pada server MCP (Model Context Protocol), yang memungkinkan untuk menghubungkan alat internal atau platform SaaS. Panggilannya ke layanan AWS tetap diatur oleh kebijakan IAM, yang secara tepat membatasi ruang lingkup tindakannya (hanya baca, remediasi otomatis, dll.) dan memfasilitasi audit.

Peran SRE Virtual

AWS menghadirkan Agen DevOps sebagai SRE panggilan virtual, yang selalu tersedia, yang menginvestigasi insiden dan mengusulkan rencana remediasi seperti yang dilakukan SRE.

Ia mempelajari topologi aplikasi Anda (layanan, database, antrian pesan, dependensi eksternal) dengan melintasi metadata, metrik, log, dan jejak AWS, ia juga mengambil informasi dari pipeline CI/CD dan repositori Git.

Ketika peringatan tiba, agen secara otomatis memulai penyelidikan, mengkorelasikan sinyal, mengidentifikasi satu atau lebih kemungkinan penyebab dan mengusulkan rencana tindakan terperinci (rollback, penyesuaian kapasitas, modifikasi konfigurasi, dll.).

Sepanjang insiden tersebut, ia mendokumentasikan pendekatannya (hipotesis, metrik yang dikonsultasikan, jejak, perubahan kode terkait) yang sebagian menggantikan tiket insiden tradisional dan menyederhanakan otopsi.

Integrasi

Saat masuk, agen menghubungkan:

• Layanan observasi: CloudWatch, tetapi juga Datadog, Dynatrace, New Relic, Grafana, Splunk, dll.
• Untuk alat tiket/insiden: ServiceNow, PagerDuty, dan lebih umum lagi apa pun yang dapat menerbitkan webhook (misalnya peringatan Grafana atau insiden PagerDuty).
• Untuk CI/CD dan sistem manajemen kode: GitHub, GitLab, Azure DevOps, untuk menghubungkan setiap insiden dengan penerapan terbaru dan perubahan kode.

Visi full-stack ini memungkinkannya untuk tidak membatasi dirinya pada “ada lebih dari 500 kesalahan”, namun kembali ke penerapan atau perubahan infrastruktur yang memicu masalah.

Sebagai hasilnya, Agen DevOps dapat:

• Bagikan analisis Anda di Slack, ServiceNow, atau PagerDuty, dengan rangkaian investigasi yang dapat Anda ikuti seperti Anda mengikuti saluran ruang perang.
• Memicu otomatisasi di sisi AWS: panggilan API, playbook, integrasi EventBridge, atau bahkan menjalankan prosedur internal yang dikemas dalam keterampilan khusus.
• Lakukan eskalasi ke manusia, termasuk membuka tiket AWS Support yang telah diisi sebelumnya dengan semua konteks investigasi.

Untuk tim lari, ini terlihat seperti seorang kolega yang mengambil alih penyelidikan, memposting hipotesisnya di saluran insiden, dan mengusulkan rencana tindakan yang kemudian dapat divalidasi atau dibiarkan dieksekusi secara otomatis.

Perbedaan nyata dengan agen yang terhubung ke CloudWatch adalah integrasinya melalui Model Context Protocol (MCP).

MCP memungkinkan Anda untuk mengekspos alat eksternal (API internal, platform SaaS, basis dokumentasi, CMDB internal, dll.) yang dapat dihubungi oleh agen.
Daripada menulis integrasi spesifik untuk setiap alat, Anda mengekspos serangkaian fungsi di sisi MCP (misalnya: mengambil topologi jaringan pusat data lokal, menanyakan log aplikasi historis, membaca CMDB) dan Agen DevOps menemukan dan mengaturnya seperti alat lainnya.

Hal inilah yang memungkinkannya, misalnya, untuk menyelidiki insiden pada beban kerja lokal menggunakan alat pemantauan Anda sendiri yang diekspos melalui MCP. untuk memperkaya penyelidikan dengan data dari sistem di luar AWS (CMDB, inventaris klaster Kubernetes, observabilitas internal, dll.).

Agen Pengembang mendukung AWS

Selain pengelolaan infrastruktur di luar AWS dengan agen DevOps melalui mcp, dimungkinkan juga untuk membangun Agen DevOps yang dibuat khusus secara internal. Memang AWS menyediakan server MCP untuk beberapa layanan pratinjau. Mereka mencakup dokumentasi tertentu, kemampuan observasi, database, antrian pesan, dan beberapa blok penyusun AI. Oleh karena itu, di sebagian besar lingkungan AWS, Anda dapat mengatur agen DevOps dengan LLM pilihan Anda, memicunya pada peringatan CloudWatch atau alat observabilitas eksternal. Oleh karena itu, kami mempertahankan logika yang mendekati logika Agen Frontier, sekaligus mengendalikan model biaya dan penerapannya.

Daftar server mcp yang tersedia di AWS:

Keamanan dan Tata Kelola

Memberikan hak kepada agen AI untuk bertindak atas produk Anda jelas menimbulkan pertanyaan keamanan dan tata kelola.

Cakupan tindakan Agen DevOps ditentukan oleh:

• peran iam dan kebijakan yang Anda tetapkan padanya, yang secara ketat membatasi API yang dapat dipanggil (hanya baca, tindakan remediasi yang ditargetkan, pembuatan tiket, dll.).
• Agent Spaces, yang menentukan lingkungan mana yang dilihat agen (beberapa akun AWS, serangkaian proyek, cakupan tim) dan integrasi eksternal mana yang dapat mereka akses.

Anda dapat, misalnya, memulai dengan ruang baca-saja di lingkungan pementasan, atau membatasi agen pada penyelidikan (tidak ada remediasi otomatis) dalam produksi. Semua aktivitas melewati log dan CloudTrail, yang membuat pelacakan lebih mudah.

Harga

Di sisi penagihan, metode perhitungan sedikit mengubah refleks kami sebagai cloud engineer.

Agen DevOps ditagih berdasarkan waktu agen, dalam hitungan detik, sesuai dengan waktu yang dihabiskan untuk melakukan investigasi, analisis pencegahan, atau tugas SRE sesuai permintaan, apa pun mode pemicunya (peringatan, tiket, obrolan, tugas terjadwal).

Tidak ada pertanyaan tentang token di sini seperti yang dapat ditemukan pada model LLM klasik.
Tidak ada biaya kepemilikan: selama agen tidak bekerja, Anda tidak perlu membayar apa pun.

Sebuah insiden besar yang dianalisis secara mendalam dapat memakan waktu beberapa ratus atau ribuan detik bagi agen, namun sebagai imbalannya adalah berkurangnya waktu pemulihan layanan dan lebih sedikit orang yang dimobilisasi serta menghemat pergantian.

Tugas tinjauan preventif (analisis rutin atas insiden masa lalu, rekomendasi untuk perbaikan) dapat direncanakan tetapi harus dianggap seperti kumpulan mahal lainnya di sisi cloud.

Untuk tim FinOps / run, jenis biaya baru ini perlu diintegrasikan ke dalam model total biaya kepemilikan proses: bandingkan biaya agen dengan pengurangan waktu panggilan, peningkatan produktivitas, dan pencegahan insiden.

Meskipun artikel ini berfokus pada Agen DevOps, ada baiknya untuk secara singkat menempatkan Agen Keamanan AWS dalam gambar.

Agen Frontier ini menerapkan logika serupa, namun berorientasi pada keamanan: ia melakukan industrialisasi tinjauan desain, tinjauan kode, pemindaian infrastruktur, dan uji intrusi berkelanjutan, yang terintegrasi sejak awal dalam siklus pengembangan.
Kita dapat, misalnya, mempercayakannya dengan analisis proyek baru dari fase arsitektur, kemudian peninjauan otomatis MR sensitif dan pengujian rutin sebagai kampanye kode pada lingkungan pra-produksi atau bahkan produksi yang terkendali.

Sebuah visi global

Kombinasi Kiro + Agen DevOps + Agen Keamanan menguraikan visi AWS tentang pengelolaan yang dijalankan dengan arsitektur agen: rantai lengkap tempat agen khusus berkolaborasi sepanjang siklus hidup, mulai dari spesifikasi, implementasi hingga operasi termasuk keamanan.

Frontier Agent DevOps tidak menggantikan keterampilan SRE, tetapi mengubah distribusi pekerjaan: Agen mengambil alih bagian penyelidikan, korelasi sinyal, dan dokumentasi insiden.

Dengan demikian, manusia dapat kembali fokus dalam menentukan batasan yang tepat (IAM, perimeter, keterampilan), pada arsitektur, dan pada keputusan yang berdampak besar.

Pelarian menjadi lebih “sebagai kode”: keterampilan SRE mengkristal dalam bentuk keterampilan, buku pedoman, dan integrasi MCP yang dapat digunakan kembali oleh Agen Frontier.

Kiro dirilis di GA pada November 2025 dan Frontier Agent Devops pada 31 Maret 2026. Pada tanggal artikel ini (2 Juni 2026) hanya tersedia di 6 wilayah AWS. Agen Keamanan AWS juga menggunakan GA pada tanggal 31 Maret dan diterapkan di wilayah yang sama dengan Agen Frontier.