Tag: awscloud

Pendahuluan Seiring pertumbuhan organisasi dalam menggunakan AWS di banyak akun dan region, mengelola serta memantau ketahanan aplikasi (resilience) menjadi semakin kompleks. Jika penilaian dilakukan secara terpisah di setiap workload, akun, atau region, hasilnya sering tidak konsisten, lambat, bahkan bisa menimbulkan celah risiko. Tantangan ini semakin terasa pada arsitektur terdistribusi yang menggunakan berbagai Infrastructure as Code (IaC) seperti CloudFormation atau Terraform. Untuk menjawab tantangan ini, AWS Resilience Hub hadir sebagai layanan terpusat yang memudahkan pemantauan dan penilaian ketahanan aplikasi di seluruh akun AWS. Layanan ini memungkinkan organisasi untuk menentukan target ketahanan, melacak pencapaiannya, dan menerapkan rekomendasi perbaikan. Resilience Hub juga bisa diintegrasikan dengan Amazon SNS untuk memberikan notifikasi real-time saat ada perubahan yang memengaruhi ketahanan aplikasi. Apa itu AWS Resilience Hub? AWS Resilience Hub adalah pusat kontrol di konsol AWS untuk mengelola dan meningkatkan ketahanan aplikasi. Anda bisa mendefinisikan target ketahanan berupa: RTO (Recovery Time Objective): seberapa cepat aplikasi harus pulih setelah gangguan. RPO (Recovery Point Objective): seberapa banyak data maksimal yang boleh hilang. Resilience Hub memberikan gambaran menyeluruh tentang ketahanan aplikasi, mendeteksi risiko, dan memberikan rekomendasi untuk perbaikan. Semua ini didasarkan pada AWS Well-Architected Framework, sehingga sesuai dengan praktik terbaik AWS. Tantangan dengan Penilaian Terpisah Jika ketahanan dinilai per akun atau per workload tanpa integrasi terpusat, biasanya akan muncul masalah: Evaluasi terfragmentasi Setiap tim menilai dengan caranya sendiri, sehingga hasil tidak konsisten. Sulit melihat gambaran besar dari seluruh sistem. Tidak ada standar kebijakan RTO dan RPO bisa berbeda-beda antar tim. Hal ini bisa menyebabkan ketidaksesuaian dengan rencana keberlangsungan bisnis. Sulit menggabungkan data Data ketahanan dari berbagai akun dan region harus dikompilasi manual. Proses ini memakan waktu, rawan kesalahan, dan membuat deteksi titik lemah jadi lambat. Solusi Arsitektur Solusi ini menggunakan model hub-and-spoke: Hub account: Menjadi pusat administrasi Resilience Hub. Mengelola kebijakan, menampilkan hasil penilaian, dan mengoordinasikan strategi. Menerima notifikasi dari SNS jika ada perubahan ketahanan. Spoke accounts: Menyimpan workload dan sumber daya yang dievaluasi. Terhubung dengan hub melalui peran IAM khusus. IAM Roles: AWSResilienceHubAssessmentRole (di hub account): mengelola konfigurasi dan menilai aplikasi lintas akun. AWSResilienceHubCrossAccountRole (di spoke account): melakukan penilaian workload dan mengirim hasil kembali ke hub. Trust Relationship: Mengizinkan peran di hub untuk mengakses peran di spoke secara aman. Resilience Hub juga bisa melakukan penilaian otomatis setiap 24 jam, dan mengirim hasil drift detection ke SNS agar tim segera mendapat peringatan. Langkah Implementasi Siapkan CloudFormation Template Unduh template IAM roles, workload sample, dan SNS. Deploy IAM Role Di hub account: buat AWSResilienceHubAssessmentRole. Di spoke account: buat AWSResilienceHubCrossAccountRole dengan trust ke hub. Buat SNS Topic Agar bisa menerima notifikasi saat ada perubahan ketahanan aplikasi. Deploy Sample Workload di Spoke Account Workload contoh ini berupa aplikasi tiga tier: CloudFront (CDN & caching) S3 (penyimpanan objek) EC2 (web server) RDS (database) Workload ini sengaja tidak sesuai best practice, agar Resilience Hub bisa menunjukkan gap dan memberi rekomendasi perbaikan. Tambahkan Aplikasi ke Resilience Hub Masukkan ARN stack CloudFormation dari workload. Tentukan kebijakan ketahanan (misalnya MissionCritical dengan RTO 10 menit dan RPO 4 menit). Aktifkan penilaian otomatis harian dan notifikasi SNS. Jalankan Assessment Pilih Assess Application di konsol Resilience Hub. Tunggu hingga laporan selesai dibuat. Meninjau Hasil Assessment Setelah selesai, laporan akan menampilkan: Ringkasan kepatuhan workload terhadap kebijakan (RTO/RPO). Rekomendasi untuk perbaikan, seperti konfigurasi alarm, SOP, atau pengujian tambahan. Detail rekomendasi per komponen (misalnya perbaikan pada database RDS). Dari sini, tim aplikasi dan infrastruktur bisa langsung melakukan perbaikan agar sistem lebih tahan terhadap gangguan. Kesimpulan Solusi ini memberikan cara terpusat untuk menilai dan meningkatkan ketahanan aplikasi di banyak akun AWS sekaligus. Manfaat utama: Satu tempat untuk mengelola semua kebijakan ketahanan. Penilaian otomatis harian dengan notifikasi real-time. Mendukung workload yang dideploy via CloudFormation maupun Terraform. Menggunakan IAM Role untuk keamanan lintas akun. Dengan AWS Resilience Hub, organisasi bisa mengubah pengelolaan ketahanan dari yang reaktif menjadi proaktif. Sistem menjadi lebih siap menghadapi kegagalan, sesuai dengan praktik terbaik Well-Architected Framework. Bagi organisasi yang infrastrukturnya semakin kompleks, Resilience Hub menjadi alat penting untuk menjaga continuity plan, disaster recovery, dan resilience posture aplikasi secara konsisten di seluruh AWS environment. Infrastruktur IT yang kuat adalah kunci produktivitas perusahaan. Dengan awscloud indonesia, Anda bisa mendapatkan solusi IT lengkap yang sesuai dengan kebutuhan Anda. iLogo Indonesia sebagai mitra terpercaya siap mengintegrasikan semuanya agar bisnis Anda tetap berjalan lancar dan aman. Hubungi kami sekarang atau kunjungi awscloud.ilogoindonesia.id untuk informasi lebih lanjut!

Banyak organisasi menggunakan AWS CloudTrail untuk mencatat semua aktivitas API di akun AWS mereka. Tantangannya, semakin besar infrastruktur AWS yang digunakan, semakin besar pula volume data CloudTrail yang dihasilkan. Dalam organisasi dengan banyak akun, jutaan panggilan API per hari bisa dengan cepat menumpuk menjadi terabyte data log. Saat tim keamanan melakukan investigasi insiden atau audit aktivitas akun, menjalankan query di Amazon Athena bisa memakan waktu dan biaya tinggi. Hal ini karena Athena biasanya harus memindai seluruh tabel untuk setiap query, sehingga proses menjadi lambat dan mahal. Sebenarnya AWS sudah menyediakan panduan untuk melakukan partisi manual pada CloudTrail logs, namun proses manual ini tidak efisien jika jumlah akun dan log terus berkembang. Oleh karena itu, dalam artikel ini kita akan membahas solusi otomatis untuk membuat dan mengelola tabel Athena yang terpartisi, sehingga query menjadi lebih cepat dan biaya jauh lebih rendah. Kenapa Perlu Optimasi? CloudTrail berfungsi sebagai catatan lengkap aktivitas API di AWS. Athena adalah layanan query interaktif berbasis SQL tanpa perlu mengelola server. Model harganya adalah pay-per-query, artinya biaya ditentukan berdasarkan banyaknya data yang dipindai setiap query. Dengan memanfaatkan tabel terpartisi, kita hanya akan memindai data yang relevan, bukan seluruh dataset. Misalnya, jika kita ingin mencari aktivitas mencurigakan dari satu akun selama seminggu terakhir, Athena cukup membaca partisi akun dan tanggal tersebut saja, bukan semua data. Gambaran Solusi Solusi ini menggunakan dua fungsi AWS Lambda untuk mengelola partisi CloudTrail di Athena: CloudTrailLogsPartitionedByAccount Membuat tabel Athena khusus untuk setiap akun AWS yang ditemukan (misalnya trail_123456789012). Tabel otomatis dipartisi berdasarkan Region dan tanggal. Memudahkan tim untuk fokus menganalisis log di akun tertentu. CloudTrailLogsPartitionedAllAccounts Membuat tabel gabungan (all_accounts_trail) yang berisi log dari seluruh akun dalam organisasi. Dipartisi berdasarkan Account ID, Region, dan tanggal. Cocok untuk investigasi lintas akun atau analisis organisasi secara menyeluruh. Kedua fungsi Lambda ini menggunakan partition projection dan melakukan update tabel setiap hari agar selalu sinkron dengan perubahan organisasi. Dengan begitu, tidak ada lagi kebutuhan untuk mengelola partisi secara manual. Persiapan Sebelum mulai, pastikan: Memiliki izin untuk membuat stack CloudFormation. CloudTrail sudah dikonfigurasi dan menyimpan log ke bucket S3. Athena sudah memiliki lokasi hasil query (query result location). Punya akses ke bucket S3 untuk CloudTrail logs dan hasil query Athena. Prefix bucket CloudTrail berbeda tergantung jenis trail: Untuk organizational trail: ORG_ID/AWSLogs/ORG_ID Untuk account-level trail: AWSLogs/ Untuk mengecek prefix, gunakan perintah berikut: aws cloudtrail describe-trails –trail-name-list NAMA_TRAIL Jika tidak ada field S3KeyPrefix, berarti menggunakan prefix default. Langkah-Langkah 1. Deploy CloudFormation Template Unduh template CloudFormation yang sudah disediakan. Buka AWS CloudFormation Console, buat stack baru, pilih Upload a template file, lalu unggah file template. Isi detail: Nama stack (misalnya: cloudtrail-athena-partitioner). Nama bucket CloudTrail (misalnya: aws-controltower-logs-123456789012-us-east-1). Prefix yang sesuai (AWSLogs/ atau ORG_ID/AWSLogs/ORG_ID). Nama bucket untuk hasil query Athena. Pilih Next, centang izin pembuatan IAM, lalu submit. Setelah stack selesai dibuat, Lambda akan otomatis mengatur tabel Athena terpartisi. 2. Query CloudTrail di Athena Buka Athena Console. Pilih database yang sudah dibuat (default: ct-central). Pergi ke Saved Queries untuk mencoba query bawaan. Contoh query: Find most frequent console users, yang akan menampilkan frekuensi login AWS Console berdasarkan user ARN. Jalankan query dan perhatikan hasilnya lebih cepat dan biaya lebih rendah dibanding query di tabel tanpa partisi. Pertimbangan Biaya Solusi ini membuat 2 fungsi Lambda yang dijalankan sekali per hari. Biaya tergantung durasi runtime Lambda di lingkungan Anda. Biaya tambahan akan timbul dari Athena sesuai volume data yang dipindai. Detail harga bisa dicek di halaman resmi Lambda pricing dan Athena pricing. Membersihkan (Cleaning Up) Jika sudah selesai atau tidak lagi digunakan, hapus CloudFormation stack untuk menghindari biaya berkelanjutan. Kesimpulan Dengan mengoptimasi query CloudTrail menggunakan tabel Athena yang terpartisi: Biaya query lebih rendah, karena Athena hanya membaca partisi yang diperlukan. Investigasi keamanan lebih cepat, baik untuk per akun maupun lintas organisasi. Administrasi lebih mudah, karena partisi dikelola otomatis oleh Lambda. Solusi ini juga menyertakan query bawaan yang bisa langsung digunakan untuk skenario umum, dan bisa menjadi dasar membuat query khusus sesuai kebutuhan tim. Jika organisasi Anda menggunakan AWS dalam skala besar, mulailah menerapkan solusi ini untuk meningkatkan efisiensi dan kecepatan analisis CloudTrail logs di Athena. Infrastruktur IT yang kuat adalah kunci produktivitas perusahaan. Dengan awscloud indonesia, Anda bisa mendapatkan solusi IT lengkap yang sesuai dengan kebutuhan Anda. iLogo Indonesia sebagai mitra terpercaya siap mengintegrasikan semuanya agar bisnis Anda tetap berjalan lancar dan aman. Hubungi kami sekarang atau kunjungi awscloud.ilogoindonesia.id untuk informasi lebih lanjut!

Teori: Penerapan Konsep SLO pada Amazon Product Search Dalam seri blog ini, tim Amazon Product Search akan berbagi bagaimana kami memantau sistem penting menggunakan Service Level Objectives (SLO), serta perjalanan kami bermigrasi dari sistem monitoring internal ke Amazon CloudWatch Application Signals. Amazon Product Search adalah sistem besar yang terdiri dari lebih dari 40 layanan backend dan melayani puluhan ribu permintaan setiap detik. Apa yang Akan Dibahas di Bagian 1? Keterbatasan monitoring tradisional Dasar-dasar SLO dan konsep burn rate Kapan sebaiknya menggunakan SLO untuk monitoring Keputusan penting dalam merancang sistem monitoring berbasis SLO Monitoring Tradisional Tidak Lagi Cukup Apa Tujuan Monitoring di Amazon Search? Kami ingin membuat alarm yang: Memberi tahu engineer hanya saat ada kejadian penting Tidak terlalu sering memunculkan alarm yang tidak penting Bisa menangkap insiden yang benar-benar berdampak Contoh masalah dengan pendekatan lama: Alarm palsu: Kadang terjadi lonjakan error sesaat di tengah malam karena bot, tapi sistem pulih sendiri. Tidak perlu membangunkan engineer untuk hal ini. Degradasi diam-diam: Kadang layanan makin lambat sedikit demi sedikit selama beberapa minggu. Masalah seperti ini tidak langsung terdeteksi oleh alarm biasa. Itulah sebabnya kami mulai mempertimbangkan pendekatan berbasis SLO. Mengenal SLO (Service Level Objectives) Istilah Penting: SLI (Service Level Indicator): Metode untuk mengukur apakah layanan bekerja dengan baik (contoh: waktu respon) SLO (Service Level Objective): Target performa layanan, seperti “99,9% permintaan harus direspons di bawah 1 detik dalam 28 hari” SLA (Service Level Agreement): Janji formal ke pelanggan soal performa layanan Error Budget: Toleransi yang bisa diterima jika performa tidak 100% sempurna (misalnya, 0.1% error masih bisa ditoleransi) Contoh Konversi SLO: Bahasa manusia: 99,9% permintaan harus selesai di bawah 1000 ms dalam 28 hari Variabel: SLI: Latensi Threshold: 1000 ms Interval: 28 hari Target: 99,9% Bagaimana Cara Membuat Alarm Berdasarkan SLO? Konsep Burn Rate Burn rate bisa diibaratkan seperti “speedometer” untuk error budget. Ia menunjukkan seberapa cepat kita “menghabiskan” jatah error dibanding target SLO. Burn rate = 1 → Penggunaan error budget pas sesuai rencana Burn rate > 1 → Error budget habis lebih cepat dari target Burn rate < 1 → Masih aman, penggunaan error budget lambat Kapan Burn Rate Lebih Baik dari Threshold? Kasus 1: Lonjakan sesaat Threshold-based: Langsung munculkan alarm walau cuma 1 spike (tidak perlu diproses jam 3 pagi) Burn rate: Tidak akan munculkan alarm kecuali lonjakan cukup besar untuk menghabiskan error budget secara signifikan Kasus 2: Spike berkala Threshold-based: Sering terlewat karena spike hanya sesaat dan tidak berturut-turut Burn rate: Bisa menangkap pola berulang karena memperhitungkan total konsumsi error budget Kasus 3: Gangguan besar Threshold-based: Bisa terlambat karena butuh banyak data poin dulu baru alarm menyala Burn rate: Langsung deteksi dan munculkan alarm saat error budget habis dengan cepat Pendekatan Burn Rate Multi-Window Kenapa Multi-Window? Jika kita hanya pakai 1 jendela waktu (window): Window pendek → terlalu sensitif, banyak false alarm Window panjang → tidak responsif, alarm bisa terlambat kembali ke normal Solusi: Gunakan Dua Window: Window Panjang (misal 1 jam): Memastikan kita tetap patuh terhadap SLO Window Pendek (misal 5 menit): Membuat alarm bisa cepat kembali ke normal dan mendeteksi masalah baru lebih cepat Contoh Pengaturan: Alarm jika 2% error budget habis dalam 1 jam Alarm jika 5% error budget habis dalam 6 jam Tiket (bukan alarm) jika 10% error budget habis dalam 3 hari Perbedaan Perhitungan Error Budget: Period-Based vs Request-Based Period-Based SLO Error budget hanya berkurang Jika habis, harus berhenti rilis fitur dan fokus perbaikan layanan Request-Based SLO Error budget bisa naik turun Bisa “mengisi ulang” error budget kalau performa layanan membaik Bisa kehabisan error budget lebih dari satu kali dalam periode yang sama Manfaat Monitoring Berbasis SLO Dengan menerapkan monitoring SLO: Lebih fokus pada apa yang penting untuk pelanggan Bisa bedakan antara alarm yang benar-benar penting dan yang bisa ditunda Membantu tim on-call lebih fokus, tidak kewalahan oleh alarm yang tidak relevan Infrastruktur IT yang kuat adalah kunci produktivitas perusahaan. Dengan awscloud indonesia, Anda bisa mendapatkan solusi IT lengkap yang sesuai dengan kebutuhan Anda. iLogo Indonesia sebagai mitra terpercaya siap mengintegrasikan semuanya agar bisnis Anda tetap berjalan lancar dan aman. Hubungi kami sekarang atau kunjungi awscloud.ilogoindonesia.id untuk informasi lebih lanjut!

Dokumentasi adalah hal yang sangat penting bagi para pengguna AWS. Kami telah bekerja keras untuk meningkatkan struktur, kejelasan, dan kemudahan menemukan konten dalam Dokumentasi AWS. Berikut kami bagikan beberapa kemajuan utama yang telah dicapai, tantangan yang kami hadapi, dan arah kami ke depan — termasuk bagaimana kami menggunakan kecerdasan buatan (AI) untuk mendukung proses ini. Tim global technical writer kami membuat dan mengelola ratusan ribu halaman dokumentasi teknis untuk lebih dari 200 layanan AWS. Tim ini juga didukung oleh bagian produk, engineering, strategi konten, dan program khusus yang membangun alat bantu, sistem otomatisasi, serta mengelola situs Dokumentasi AWS. Fokus utama kami: terus menyempurnakan pengalaman dokumentasi untuk pengguna. Berdasarkan data umpan balik (seperti thumbs-up, thumbs-down, survei, dan lainnya), kami melihat kemajuan yang bagus, tapi kami tahu masih banyak ruang untuk perbaikan. Tujuan kami bukan hanya membuat dokumentasi yang baik, tapi menjadikannya yang terbaik di industri. Dokumentasi AWS Kini Lebih Mudah Dibaca dan Dipahami Selama setahun terakhir, kami melakukan perombakan besar-besaran terhadap sebagian besar panduan pengguna dan pengembang AWS. Ini bukan sekadar membersihkan tampilan — tapi juga menyusun ulang struktur agar lebih konsisten dan mudah dibaca. Kami juga sadar bahwa banyak developer sekarang belajar tentang AWS lewat alat berbasis AI. Maka, konten kami sekarang lebih ramah bagi model bahasa besar (LLM), agar alat seperti Amazon Q atau ChatGPT bisa memberi jawaban akurat soal AWS. Kami menggandakan jumlah code sample dalam dokumentasi untuk mencakup lebih banyak layanan. Banyak developer bilang, “Jangan suruh saya baca panjang-panjang, tunjukkan aja kodenya.” Maka kami sediakan lebih banyak contoh kode yang jelas, sesuai standar, dan sudah diuji — ini bermanfaat untuk developer maupun model AI. Kami juga meningkatkan aksesibilitas konten, termasuk teks alternatif pada gambar dan struktur heading yang lebih baik. Kami akan terus berinvestasi agar dokumentasi AWS bisa diakses semua orang. Panduan Pengambilan Keputusan: Membantu Pilih Layanan yang Tepat Salah satu tantangan terbesar saat menggunakan AWS adalah memilih layanan yang sesuai dengan kebutuhan. Misalnya, AWS punya banyak layanan untuk menjalankan container — itu bagus, tapi juga bisa membingungkan. Daripada membaca dokumentasi setiap layanan satu per satu, kami membuat panduan keputusan (decision guides) untuk kategori layanan tertentu seperti database, container, komputasi, AI, dan lainnya. Panduan ini menjelaskan perbedaan layanan dalam satu kategori dan kegunaan masing-masing. Respon pengguna sangat positif, sehingga kami akan terus kembangkan panduan ini dan menyebarkannya lebih luas dalam dokumentasi. Peningkatan Website: Navigasi dan Pencarian Lebih Mudah Selain konten, kami juga meningkatkan struktur, navigasi, dan tampilan situs dokumentasi AWS. Mulai dari homepage baru yang menampilkan tautan paling sering dikunjungi — dan jujur saja, tampilannya sekarang jauh lebih enak dilihat, terutama dalam mode gelap! Kami juga menambahkan navigasi yang lebih baik di seluruh situs, termasuk tautan langsung ke referensi API, AWS CLI, SDK, serta tugas yang disarankan. Navigasi global di bagian atas memudahkan Anda menuju alat developer dan contoh kode hanya dalam beberapa klik. Pencarian juga kami tingkatkan — sekarang ada fitur saran otomatis (auto-suggest) dan hasil pencarian yang lebih relevan dengan ringkasan singkat. Karena banyak developer mencari dokumentasi lewat Google, kami juga mengoptimalkan struktur dan metadata agar lebih mudah ditemukan lewat mesin pencari. Untuk pengguna yang ingin fokus membaca panduan tanpa gangguan, kami menambahkan “focus mode” yang menyembunyikan navigasi dan hanya menampilkan kontennya saja. Data menunjukkan fitur ini sangat disukai. AI Membantu Proses Pembuatan Dokumentasi Kemajuan AI, terutama generative AI, membuka peluang baru dalam proses penulisan dokumentasi. Untuk fitur-fitur AWS yang benar-benar baru, LLM belum tentu memahami konsepnya. Maka, penulis kami tetap membuat konten awal (“content primitives”) yang akurat, lalu model AI bisa bantu membuat draf awal berdasarkan informasi internal seperti dokumen desain atau spesifikasi API. Ini mempercepat proses pembuatan dokumentasi. AI juga sangat bagus untuk membuat konten turunan dari informasi yang sudah ada. Misalnya, membuat panduan langkah demi langkah untuk deploy website statis di AWS. Tapi, AI kadang masih memberi informasi yang kurang akurat atau tidak sesuai praktik terbaik. Karena itu, kami gunakan pendekatan “AI menulis draf, manusia menyempurnakan” — hasil akhirnya jauh lebih baik dan ini juga membantu model belajar lebih banyak dari konten yang benar. Contoh nyatanya: banyak panduan keputusan (decision guides) kami mulai dari draf buatan AI, lalu kami uji dan edit agar sesuai standar dokumentasi AWS sebelum dipublikasikan. Dokumentasi resmi AWS harus menjadi sumber kebenaran utama, dan kami sangat menjaga itu. Konten AI tetap harus ditinjau manusia agar benar-benar akurat sebelum diterbitkan. Jika ada konten yang dihasilkan AI dan belum ditinjau, kami beri label dengan jelas bahwa itu adalah versi awal. AI juga menjanjikan kemajuan di bidang penerjemahan konten dan mendeteksi bagian dokumentasi yang sudah usang. Kami sedang membangun alat dan platform baru untuk memanfaatkan potensi AI ini dan terus meningkatkan pengalaman pengguna dokumentasi AWS. Langkah Selanjutnya Menuju 2025 Kami sadar bahwa meskipun banyak hal sudah kami perbaiki, pekerjaan ini belum selesai. Tujuan kami bukan cuma membuat dokumentasi yang bagus — tapi dokumentasi yang sangat membantu dan bebas hambatan. Akan ada lebih banyak fitur di website, konten tambahan, serta integrasi AI yang lebih dalam dalam proses dokumentasi. Ke depannya, kami juga akan membagikan bagaimana AI digunakan dalam seluruh siklus hidup dokumentasi. Generative AI membawa semangat dan energi baru, tidak hanya bagi saya tapi juga bagi banyak orang di tim kami. Masa depan dokumentasi AWS terlihat menjanjikan — dan kami ingin memastikan itu memberi manfaat maksimal bagi Anda. Infrastruktur IT yang kuat adalah kunci produktivitas perusahaan. Dengan awscloud inondesia, Anda bisa mendapatkan solusi IT lengkap yang sesuai dengan kebutuhan Anda. iLogo Indonesia sebagai mitra terpercaya siap mengintegrasikan semuanya agar bisnis Anda tetap berjalan lancar dan aman. Hubungi kami sekarang atau kunjungi awscloud.ilogoindonesia.id untuk informasi lebih lanjut!

Agen AI otonom adalah evolusi besar berikutnya dalam dunia kecerdasan buatan. Berbeda dari chatbot biasa, agen ini bisa berpikir, merencanakan, dan menyelesaikan tugas — baik bersama manusia maupun sepenuhnya sendiri. Contohnya: meriset informasi, membayar tagihan, merencanakan liburan, atau mengelola aplikasi perusahaan. Penggunaan agen AI otonom berkembang pesat dan sudah mulai diadopsi di perusahaan. Ini didorong oleh model AI yang makin canggih dan hemat biaya, infrastruktur data yang aman, dan munculnya alat bantu pengembangan. Para pemimpin bisnis kini menghadapi peluang besar — sekaligus tantangan — karena teknologi ini mulai digunakan sebagai bagian inti dari operasional bisnis, bukan hanya eksperimen semata. Memahami Agen AI Otonom: Lebih dari Sekadar Otomatisasi Sama seperti mobil otonom yang berkembang dari mode cruise control hingga bisa menyetir sendiri, kemampuan agen AI juga makin meningkat. Berikut tingkatannya: Level 1 – Chain (Rantai): Otomatisasi berbasis aturan. Semua langkah sudah ditentukan. Contoh: menyalin data dari PDF ke database. Level 2 – Workflow (Alur Kerja): Langkah-langkah sudah ditentukan, tapi urutannya bisa berubah sesuai situasi. Contoh: membuat email balasan pelanggan otomatis. Level 3 – Semi-Otonom: Agen bisa merencanakan dan menjalankan tugas berdasarkan tujuan, dengan pengawasan minim. Contoh: menyelesaikan tiket bantuan pelanggan dengan mengakses beberapa sistem. Level 4 – Otonom Penuh: Agen bisa bekerja tanpa pengawasan, menetapkan tujuan sendiri, dan memilih alat bantu sesuai kebutuhan. Contoh: agen riset strategis yang merangkum informasi tanpa bantuan manusia. Saat ini (Q1 2025), kebanyakan aplikasi AI baru sampai di Level 1 dan 2. Hanya sedikit yang sudah ke Level 3, dan itu pun di bidang tertentu. Agen AI yang benar-benar otonom bisa mengevaluasi hasil kerjanya sendiri, menyesuaikan rencana, dan bekerja tanpa campur tangan manusia. Dampak Ekonomi: Prediksi Pasar dan Transformasi Bisnis Menurut McKinsey, AI generatif (gen AI) diperkirakan menyumbang $2,6–$4,4 triliun per tahun terhadap ekonomi global. Gartner memprediksi 15% keputusan kerja akan dibuat oleh agen AI pada 2028 — naik dari 0% di tahun 2024. Pasar agen AI sendiri diproyeksikan tumbuh hingga $52,6 miliar pada 2030 (tumbuh 45% per tahun). Contoh penerapannya: Agen riset & inovasi: Genentech menggunakan agen AI di AWS untuk mempercepat riset medis. Agen ini menyusun langkah kerja dinamis dan menyesuaikan prosesnya saat berjalan. Ini mempercepat penemuan obat baru. Agen produktivitas kerja: Amazon menggunakan agen di Amazon Q Developer untuk memperbarui ribuan aplikasi Java secara otomatis. Proses yang biasanya lama kini jadi cepat, hemat waktu dan biaya. Agen alur kerja bisnis: Rocket Mortgage menggunakan agen AI untuk memberikan rekomendasi hipotek secara personal. Sistem ini menganalisis 10 petabyte data keuangan dan memberikan panduan real-time untuk pelanggan mereka. Alat atau Rekan Kerja? Masa Depan Kolaborasi Manusia & AI Agen AI otonom bukan hanya alat, tapi bisa jadi rekan kerja. Manusia punya pengalaman, intuisi, dan etika. Agen AI unggul dalam kecepatan, ketepatan, dan kerja tanpa lelah. Walau agen tidak punya kesadaran atau nilai moral, mereka bisa bertindak seolah seperti manusia — tergantung bagaimana manusia mendesain dan memberi arahan. Di masa depan, peran manusia akan berubah. Kita akan lebih fokus pada pengawasan, penentuan tujuan, dan memastikan hasil kerja agen bertanggung jawab. Keterampilan baru akan dibutuhkan: bukan hanya mengoperasikan agen, tapi memahami, mengawasi, dan berkolaborasi dengan mereka. Contohnya: Pemimpin layanan pelanggan akan mengelola tim agen. Analis bisnis akan mengevaluasi hasil kerja agen AI. Etika dan Tata Kelola dalam Dunia Agen AI Agar adopsi agen AI sukses, perusahaan harus mengatur etika dan tata kelola sejak awal. Dua hal utama yang perlu diperhatikan: Akuntabilitas (Siapa yang bertanggung jawab?): Agen AI bukan pihak yang bisa disalahkan jika terjadi kesalahan. Perusahaan harus membuat struktur tanggung jawab bersama. Misalnya: Engineer AI bertanggung jawab memastikan data tidak bias. Tim pengembang mengatur izin akses dan pengamanan data. Tim bisnis menyetujui penggunaan setelah pengujian ketat. Setiap tindakan agen harus bisa dilacak, agar bila terjadi kesalahan, bisa dianalisis penyebabnya. Privasi (Siapa yang boleh mengakses dataku?): Agen AI bisa menggabungkan data dari banyak sumber dan menggunakannya secara tak terduga. Perusahaan harus melampaui sistem akses biasa, dan menerapkan pengawasan kontekstual serta kontrol real-time. Tugas Pemimpin IT (CIO): Penggerak Inovasi Agen AI CIO (Chief Information Officer) akan memainkan peran kunci dalam menyukseskan agen AI. Bukan sekadar sebagai penjaga teknologi, tapi sebagai penggerak kolaborasi AI di seluruh organisasi. Apa yang bisa dilakukan CIO? Buat roadmap pengembangan agen AI, mulai dari otomatisasi sederhana hingga sistem yang benar-benar otonom — sambil menerapkan prinsip tata kelola dari awal. Dorong budaya kerja sama antara manusia dan agen. Bangun keterampilan baru bagi karyawan. Pastikan keamanan dan privasi sesuai dengan kebutuhan agen AI yang dinamis. Fasilitasi adopsi agen AI di tiap departemen, tapi tetap awasi dengan standar yang seragam. Ingin tahu apakah perusahaan Anda siap bekerja bersama agen AI? Hubungi kami untuk mengevaluasi strategi, keterampilan, dan kesiapan risiko Anda. Infrastruktur IT yang kuat adalah kunci produktivitas perusahaan. Dengan awscloud indonesia, Anda bisa mendapatkan solusi IT lengkap yang sesuai dengan kebutuhan Anda. iLogo Indonesia sebagai mitra terpercaya siap mengintegrasikan semuanya agar bisnis Anda tetap berjalan lancar dan aman. Hubungi kami sekarang atau kunjungi awscloud.ilogoindonesia.id untuk informasi lebih lanjut!

Banyak organisasi menggunakan alat monitoring pihak ketiga untuk mengambil data metrik dari Amazon CloudWatch guna ditampilkan dalam dashboard dan sistem notifikasi mereka. Hal ini sering menyebabkan penggunaan API GetMetricData yang sangat tinggi dan menghasilkan biaya CloudWatch yang besar. Tantangan yang sering dihadapi oleh tim optimasi biaya adalah mengetahui siapa atau apa yang menyebabkan biaya tinggi tersebut, terutama jika bukan bagian dari alur kerja operasional utama. ❗ Masalah Sebelumnya Dulu, tidak ada data langsung yang tersedia untuk pelanggan guna mengidentifikasi klien yang melakukan panggilan GetMetricData secara berlebihan. Biasanya, pelanggan harus menghubungi AWS Support untuk mendapatkan detail seperti IAM Role atau IP Address yang digunakan. ✅ Solusi Baru Kini, dengan diperkenalkannya CloudTrail data events untuk GetMetricData, pelanggan bisa melacak sendiri siapa yang melakukan panggilan API tersebut melalui CloudTrail trail atau CloudTrail Lake. Hal ini memungkinkan analisis lebih cepat dan tindakan yang lebih tepat. 🔍 Tujuan Panduan Ini Mengaktifkan CloudWatch data events di CloudTrail Menggunakan metrik penggunaan API AWS untuk menemukan lonjakan aktivitas Menganalisis log GetMetricData menggunakan Athena dan CloudWatch Log Insights Menerapkan praktik terbaik untuk menghindari biaya berlebih 📋 Syarat Awal Pastikan Anda sudah memiliki CloudTrail trail aktif di region yang ingin dianalisis. Anda bisa menambahkan data event CloudWatch secara sementara untuk investigasi. Setelah selesai, trail bisa dihapus agar tidak menimbulkan biaya tambahan. 🛠️ Langkah-Langkah Solusi 1. Aktifkan CloudWatch Data Events di CloudTrail Catatan: Fitur ini tidak aktif secara default dan bisa menimbulkan biaya tambahan. Langkah-langkah: Buka AWS Console → CloudTrail → Trails Pilih trail yang ingin digunakan → klik Edit di bagian Data events Centang Data events, lalu pilih Switch to advanced event selectors Pada Resource type, pilih CloudWatch metric Klik Save Changes Setelah itu, tunggu beberapa menit sampai aktivitas API mulai dicatat. 2. Identifikasi Waktu Aktivitas Tinggi Gunakan namespace AWS/Usage di CloudWatch untuk melihat metrik seperti: CallCount: jumlah panggilan sukses ErrorCount: jumlah gagal ThrottleCount: jumlah yang dibatasi Untuk melihat grafik penggunaan GetMetricData selama 30 hari terakhir: Buka CloudWatch Console Pilih Metrics → All Metrics Cari GetMetricData Pilih Usage by AWS Resource → CallCount Ubah statistik ke SUM, periode ke 1 hari Pilih rentang waktu (custom / last 4 weeks) Dari grafik, Anda bisa melihat kapan lonjakan terjadi, misalnya tanggal 5 Februari. 3. (Opsional) Buat Tabel Athena Jika ingin menggunakan Amazon Athena untuk menganalisis log CloudTrail, Anda perlu membuat tabel terlebih dahulu. Namun jika menggunakan CloudWatch Log Insights, Anda bisa langsung query tanpa membuat tabel. 4. Analisis Data Menggunakan Athena / Log Insights Berikut beberapa contoh query untuk menganalisis sumber API GetMetricData: a. Berdasarkan IAM Role atau User Athena: SELECT userIdentity.arn AS IAM, count(*) AS CallCount FROM “default”.”cloudtrail_logs_ops” WHERE eventname = ‘GetMetricData’ AND eventtime BETWEEN ‘2025-02-05T00:00:00Z’ AND ‘2025-02-06T00:00:00Z’ GROUP BY userIdentity.arn ORDER BY CallCount DESC; Log Insights: SELECT `userIdentity.arn` AS IAM_Role_User, count(*) AS CallCount FROM `cloudtrail_logs_ops` WHERE eventName = ‘GetMetricData’ GROUP BY `userIdentity.arn` ORDER BY CallCount DESC; b. Berdasarkan UserAgent dan IP Address Athena: SELECT useragent, sourceipaddress AS ClientIP, count(*) AS CallCount FROM “default”.”cloudtrail_logs_ops” WHERE eventname = ‘GetMetricData’ AND eventtime BETWEEN ‘2025-02-05T00:00:00Z’ AND ‘2025-02-06T00:00:00Z’ GROUP BY useragent, sourceipaddress ORDER BY CallCount DESC; Log Insights: SELECT `userAgent`, `sourceIPAddress` AS ClientIP, count(*) AS CallCount FROM `cloudtrail_logs_ops` WHERE eventName = ‘GetMetricData’ GROUP BY `userAgent`, `sourceIPAddress` ORDER BY CallCount DESC; c. Berdasarkan AWS Account ID Athena: SELECT userIdentity.accountId, count(*) AS CallCount FROM “default”.”cloudtrail_logs_ops” WHERE eventname = ‘GetMetricData’ AND eventtime BETWEEN ‘2025-02-05T00:00:00Z’ AND ‘2025-02-06T00:00:00Z’ GROUP BY userIdentity.accountId ORDER BY CallCount DESC; Log Insights: SELECT `userIdentity.accountId` AS Account_ID, count(*) AS CallCount FROM `cloudtrail_logs_ops` WHERE eventName = ‘GetMetricData’ GROUP BY `userIdentity.accountId` ORDER BY CallCount DESC; 💡 Tips untuk Mengurangi Biaya GetMetricData Mengacu pada harga CloudWatch, GetMetricData dikenakan biaya berdasarkan jumlah metrik yang diambil ($0.01 per 1000 metrik). Untuk menekan biaya: Ambil hanya metrik yang benar-benar dibutuhkan untuk dashboard atau alert Batasi region tempat pengambilan data jika tidak ada aktivitas Cabut izin IAM yang tidak perlu menggunakan GetMetricData Kurangi frekuensi pengambilan data Pertimbangkan migrasi ke CloudWatch Metric Streams, yang lebih murah dan push data ke alat pemantauan pihak ketiga secara real-time 🧹 Pembersihan Setelah Analisis Hapus CloudWatch Data Events Buka CloudTrail Console → Trails → pilih trail Anda Klik Edit di bagian Data events → klik Remove → Save Changes Hapus Trail atau Tabel Athena jika tidak diperlukan DROP TABLE IF EXISTS “default”.”cloudtrail_logs_ops”; 🎯 Kesimpulan Dalam panduan ini, Anda telah mempelajari cara: Melacak penggunaan API GetMetricData Mengidentifikasi siapa (IAM, IP, akun) yang menyebabkannya Menerapkan praktik terbaik untuk mengurangi biaya CloudWatch Dengan CloudTrail dan Athena, kini Anda bisa menghemat biaya CloudWatch secara proaktif dan mengoptimalkan penggunaan API dengan cepat dan efisien. Infrastruktur IT yang kuat adalah kunci produktivitas perusahaan. Dengan awscloud indonesia, Anda bisa mendapatkan solusi IT lengkap yang sesuai dengan kebutuhan Anda. iLogo Indonesia sebagai mitra terpercaya siap mengintegrasikan semuanya agar bisnis Anda tetap berjalan lancar dan aman. Hubungi kami sekarang atau kunjungi awscloud.ilogoindonesia.id untuk informasi lebih lanjut!

Kami sangat senang menyambut Anda di AWS re:Inforce, yang akan diselenggarakan di Philadelphia, Pennsylvania, pada 16–18 Juni 2025. Tahun ini, sesi Governance, Risk, and Compliance (GRC) akan membahas topik seperti otomatisasi kepatuhan, peningkatan visibilitas risiko, pemanfaatan GenAI untuk pertumbuhan bisnis, dan menjaga keamanan dalam skala besar. Akan ada: 5 sesi breakout 8 sesi builder 7 sesi chalk talk 2 sesi code talk 4 workshop 4 lightning talk Berikut adalah sorotan dari sesi-sesi GRC utama yang bisa membantu Anda bergerak lebih cepat sambil tetap menjaga standar keamanan, operasional, dan kepatuhan Anda. 🔹 Sesi Breakout GRC GRC303 | Memberdayakan sektor infrastruktur kritikal melalui tata kelola cloud Pelajari bagaimana sektor penting seperti energi dan transportasi bisa menghadapi tantangan keamanan dan kepatuhan menggunakan AWS Control Tower. Sesi ini menampilkan kisah sukses nyata dari Moeve dan membahas arsitektur multi-akun dan kepatuhan otomatis. GRC302 | Tata kelola GenAI: Membangun dan memvalidasi kontrol cloud Sesi teknis ini menunjukkan cara membangun kerangka validasi untuk beban kerja GenAI. Anda akan belajar menggunakan VPC, IAM, dan KMS untuk kontrol dasar, serta menggunakan AWS Config, CloudTrail, dan Control Tower untuk memvalidasinya dan membuat dashboard kepatuhan otomatis. 🔧 Sesi Builder GRC (Hands-on) GRC354 | Praktik terbaik menggunakan GenAI untuk kepatuhan cloud Pelajari cara menggunakan Amazon Q Developer untuk membuat pengecekan kepatuhan, otomatisasi perbaikan, dan laporan kepatuhan menggunakan GenAI. Wajib bawa laptop. GRC355 | Bangun alur kerja kepatuhan otomatis dengan Amazon Q Bangun pipeline pengumpulan bukti kepatuhan dengan Systems Manager, AWS Config, CloudTrail, dan Amazon Q. Fokus pada monitoring berkelanjutan dan otomatisasi skrip. Wajib bawa laptop. GRC356 | Tata kelola AI otonom: Mengelola risiko dari desain hingga implementasi Pelajari cara memantau interaksi agen AI, menetapkan batas kepatuhan, dan menerapkan kontrol audit dengan AWS Control Tower dan Config Rules. Wajib bawa laptop. 🧑‍🏫 Chalk Talk GRC (Diskusi Interaktif) GRC333 | Membangun alur kerja otomatis yang aman dengan AWS Systems Manager Pelajari cara membuat alur kerja otomatis yang aman, menggunakan akses shell aman dan pipeline berbasis event untuk audit dan tiket insiden. GRC335 | Memperkuat kontrol keamanan dengan layanan observabilitas AWS Gabungkan CloudWatch, CloudTrail, dan OpenSearch untuk pemantauan terpusat, dashboard real-time, dan respons ancaman otomatis. GRC336 | Kepatuhan AI sejak awal: Membangun solusi yang bertanggung jawab Pelajari strategi membangun AI yang patuh terhadap regulasi baru (seperti EU AI Act), menggunakan Amazon Bedrock, guardrails, dan praktik AI yang bertanggung jawab. GRC337 | Bangun AI yang patuh: Implementasi kontrol untuk regulasi baru Pelajari lanskap regulasi global untuk AI dan data, dan cara memetakan persyaratan hukum ke fitur AWS. Juga ditunjukkan bagaimana GenAI membantu menilai risiko dan membuat panduan kepatuhan. 💻 Code Talk GRC GRC442 | Melampaui shift-left: Menanamkan kontrol ke pipeline infrastruktur Pelajari bagaimana menggabungkan CDK dan Terraform untuk memastikan kontrol kepatuhan otomatis tanpa menghambat tim developer. 🛠️ Workshop GRC (Praktek Langsung) GRC372 | Kontrol kepatuhan dan privasi data untuk beban kerja sensitif Pelajari cara mengidentifikasi risiko, memilih kontrol, menerapkannya di AWS, dan menghasilkan bukti audit. Wajib bawa laptop. GRC373 | Praktik monitoring keamanan: Implementasi observabilitas AWS Praktik langsung membuat dashboard, alert otomatis, dan workflow respons menggunakan CloudWatch, CloudTrail, dan AWS Config. ⚡ Lightning Talk GRC (Sesi Singkat & Cepat) GRC225 | Gunakan GenAI untuk pertumbuhan bisnis di tengah regulasi Strategi untuk menyeimbangkan inovasi dan kepatuhan dengan menggunakan AWS AI/ML, sambil tetap mematuhi regulasi yang terus berubah. GRC321 | Bangun kontrol keamanan multi-akun dengan Q CLI Chat Gunakan Amazon Q CLI dengan perintah bahasa alami untuk membuat template CloudFormation, Config Rules, dan workflow otomatis. GRC421 | Monitoring dan respons keamanan dalam skala besar Gunakan CloudTrail Lake dan fitur endpoint VPC untuk pemantauan jaringan pribadi dan audit aktivitas, dengan query berbasis AI dan dashboard lengkap. ✅ Pesan Kursi untuk Sesi Favorit Anda! Jika Anda tertarik mengikuti sesi di atas, segera pesan kursi Anda. Pemesanan kursi tersedia untuk peserta terdaftar melalui portal acara: masuk, buka bagian “Event” → “Sessions”. Kesimpulan AWS re:Inforce 2025 menyediakan berbagai sesi GRC yang bisa disesuaikan dengan tahap keamanan dan kepatuhan Anda saat ini. Baik Anda ingin: Mengotomatisasi kontrol keamanan Menerapkan kepatuhan untuk AI otonom Menggunakan GenAI untuk strategi kepatuhan Meningkatkan visibilitas dan keamanan dalam skala besar Semua itu tersedia di jalur GRC. Anda bisa belajar praktik terbaik, berdiskusi interaktif, dan mendapat insight praktis untuk menghadapi tantangan nyata. Jangan lupa kunjungi booth GRC di AWS Village dalam area Expo, dan jika Anda tidak bisa hadir langsung, sesi breakout akan tersedia di YouTube AWS setelah acara. Ingin tahu lebih lanjut atau ingin menghadirkan ahlinya langsung ke tim Anda? Hubungi tim akun AWS Anda. Infrastruktur IT yang kuat adalah kunci produktivitas perusahaan. Dengan awscloud indonesia, Anda bisa mendapatkan solusi IT lengkap yang sesuai dengan kebutuhan Anda. iLogo Indonesia sebagai mitra terpercaya siap mengintegrasikan semuanya agar bisnis Anda tetap berjalan lancar dan aman. Hubungi kami sekarang atau kunjungi awscloud.ilogoindonesia.id untuk informasi lebih lanjut!

Mengelola infrastruktur hybrid (gabungan antara AWS dan lingkungan on-premises) bisa menjadi rumit. Banyak tim menggunakan alat yang berbeda untuk mengelola node (server atau komputer) tergantung pada platformnya. Ada juga yang menggunakan software RMM (Remote Monitoring and Management) berbayar. Dengan AWS Systems Manager Hybrid Activations, Anda bisa mengelola node on-premises, Amazon EC2, dan bahkan node multicloud dengan satu alat terpadu. AWS Systems Manager membantu meningkatkan efisiensi dengan menyederhanakan tugas manajemen seperti instalasi software, patching, dan pemecahan masalah. Namun, banyak tim kesulitan dalam mendaftarkan node hybrid karena harus mengelola activation code yang kadaluarsa setiap 30 hari. Dalam panduan ini, Anda akan belajar cara otomatisasi instalasi node Windows yang dikelola oleh AWS Systems Manager menggunakan Group Policy Active Directory dan skrip PowerShell. Ringkasan Solusi Untuk mengotomatiskan instalasi node Windows ke Systems Manager: Anda akan membuat Group Policy yang menjalankan Scheduled Task segera. Scheduled Task akan mengeksekusi skrip PowerShell untuk mendaftarkan node ke Systems Manager. Activation Code dan Activation ID diperoleh dari AWS CLI atau Console saat Anda membuat Hybrid Activation. Activation berlaku maksimal 30 hari dan memiliki batas jumlah pendaftaran node. Jenis Instance Systems Manager Standard Instance: Maksimal 1.000 node per akun dan region. Advanced Instance: Untuk lebih dari 1.000 node, patching aplikasi Microsoft, atau menggunakan Session Manager. Aktifkan jika diperlukan. Cara Kerja Otomatisasi Skrip PowerShell akan dijalankan di utility server (Windows EC2 instance) yang: Membuat Hybrid Activation baru. Menyimpan Activation Code dan ID ke dalam file variabel PowerShell. Menyimpan file ke folder jaringan (network share) yang digunakan oleh Group Policy. Langkah-langkah Langkah 1 – Persiapan Anda membutuhkan: Akun AWS dengan akses ke Systems Manager, EC2, dan IAM. Akses untuk membuat dan menghubungkan Group Policy di Active Directory. Folder jaringan yang bisa diakses oleh komputer domain dan akun servis tertentu. Akun servis Active Directory untuk otomatisasi. EC2 instance Windows yang bergabung dengan domain (utility server). Unduh dua skrip dari GitHub: win-ssm-activate.ps1 dan win-ssm-script-automation.ps1. Langkah 2 – Buat IAM Role Role 1 – Untuk node hybrid: Layanan: EC2 Izin: AmazonSSMManagedInstanceCore, CloudWatchAgentServerPolicy Nama Role: SSMHybridNodeRole Role 2 – Untuk utility server: Layanan: EC2 Izin: Sama seperti Role 1 Nama Role: SSMUtilityServerRole Tambahkan inline policy berikut (ganti YOURAWSACCOUNTNUMBER dengan nomor akun Anda): json CopyEdit { “Version”: “2012-10-17”, “Statement”: [ { “Sid”: “CreateSSMActivations”, “Effect”: “Allow”, “Action”: “ssm:CreateActivation”, “Resource”: “*” }, { “Sid”: “PassRolePermission”, “Effect”: “Allow”, “Action”: “iam:PassRole”, “Resource”: “arn:aws:iam::YOURAWSACCOUNTNUMBER:role/SSMHybridNodeRole” } ] } Langkah 3 – Otomatisasi Aktivasi Systems Manager Login ke utility server. Edit skrip win-ssm-script-automation.ps1 dan isi variabel: $SharedFolder: Lokasi folder jaringan. $LocalFolder: Folder lokal tempat skrip disimpan. $Region: Region AWS Anda. $RegistrationLimit: Jumlah maksimum node per aktivasi. $HybridActivationRole: Role IAM yang digunakan node hybrid. Buat Scheduled Task: Buka Task Scheduler > Create Task. Tab General: Jalankan dengan akun servis dan centang Run whether user is logged in or not. Tab Triggers: Harian, setiap 15 hari. Tab Actions: Program: powershell.exe Argument: -ExecutionPolicy Bypass -File “c:\scripts\win-ssm-script-automation.ps1” Langkah 4 – Buat Group Policy Deployment Edit win-ssm-activate.ps1, isi variabel $Region dan $SharedFolder. Salin skrip ke folder jaringan. Buat GPO: Buka Group Policy Management > Buat GPO baru. Edit GPO: Computer Configuration > Preferences > Control Panel Settings > Scheduled Tasks Tambah Immediate Task: Program: powershell.exe Argument: -ExecutionPolicy Bypass -File “\\server\folder\win-ssm-activate.ps1” Link GPO ke OU target. Pembersihan Jika ingin menghapus solusi: Hapus skrip scripts.zip dan file PowerShell dari server dan shared folder. Hapus EC2 instance jika tidak diperlukan. Hapus IAM role yang dibuat. Hapus GPO yang dibuat. Deregister node hybrid dari AWS Systems Manager. Kesimpulan Anda telah belajar bagaimana mengotomatiskan pendaftaran node Windows on-premise ke AWS Systems Manager menggunakan Group Policy dan PowerShell. Dengan solusi ini, semua node domain yang berjalan di luar EC2 bisa dikelola bersama melalui AWS Systems Manager—memudahkan patching, pemeliharaan, dan akses yang aman. Infrastruktur IT yang kuat adalah kunci produktivitas perusahaan. Dengan awscloud indonesia, Anda bisa mendapatkan solusi IT lengkap yang sesuai dengan kebutuhan Anda. iLogo Indonesia sebagai mitra terpercaya siap mengintegrasikan semuanya agar bisnis Anda tetap berjalan lancar dan aman. Hubungi kami sekarang atau kunjungi awscloud.ilogoindonesia.id untuk informasi lebih lanjut!

Kabar baik untuk para pengguna AWS! Sekarang, AWS CloudTrail mendukung network activity events khusus untuk VPC Endpoint. Dengan fitur baru ini, Anda bisa melihat dan melacak aktivitas jaringan yang terjadi pada VPC Endpoint secara lebih detail—langsung dari CloudTrail. Ini adalah langkah besar untuk meningkatkan visibilitas, keamanan, dan audit jaringan di lingkungan AWS Anda. Apa Itu VPC Endpoint? Sebelum kita masuk lebih jauh, mari kita ulas sedikit. VPC Endpoint adalah cara untuk menghubungkan layanan AWS seperti S3, DynamoDB, dan lainnya ke dalam VPC (Virtual Private Cloud) Anda tanpa harus keluar ke internet. Artinya, komunikasi tetap aman, cepat, dan privat. Namun sebelumnya, saat terjadi masalah atau aktivitas mencurigakan di jaringan VPC Endpoint, Anda mungkin kesulitan mengetahui apa yang sebenarnya terjadi. Nah, fitur baru dari CloudTrail ini hadir untuk mengatasi hal tersebut. Kenapa Ini Penting? Dengan adanya Network Activity Events untuk VPC Endpoint di CloudTrail, Anda kini bisa: Melihat siapa yang mengakses layanan melalui VPC Endpoint Melacak koneksi keluar dan masuk Mendeteksi aktivitas mencurigakan secara lebih awal Mempermudah proses audit dan compliance Singkatnya, fitur ini membantu Anda untuk lebih memahami dan mengamankan lalu lintas jaringan internal AWS Anda. Apa Saja yang Dicatat CloudTrail? CloudTrail sekarang mencatat data seperti: Alamat IP sumber dan tujuan Port yang digunakan Protokol komunikasi Status koneksi (berhasil atau gagal) Semua informasi ini bisa dilihat lewat log CloudTrail dan dapat dikirim ke Amazon S3, CloudWatch Logs, atau dikaitkan dengan Amazon Athena untuk analisis lebih lanjut. Siapa yang Paling Diuntungkan? Fitur ini sangat berguna untuk: Tim keamanan (SecOps): Bisa mendeteksi potensi ancaman jaringan lebih cepat. Tim kepatuhan (Compliance): Lebih mudah melakukan audit karena aktivitas jaringan dicatat otomatis. Tim DevOps & Networking: Bisa melakukan troubleshooting koneksi VPC dengan lebih efisien. Cara Mengaktifkan Fitur Ini Untuk mulai menggunakan fitur ini, Anda cukup mengaktifkan data event pada trail CloudTrail Anda dan pilih sumber “Network Activity” untuk tipe log. Selanjutnya, pilih VPC Endpoint mana saja yang ingin Anda monitor. Panduan lebih lengkapnya bisa ditemukan di dokumentasi resmi AWS CloudTrail. Penutup Peluncuran fitur Network Activity Events untuk VPC Endpoint di AWS CloudTrail merupakan langkah besar dalam meningkatkan transparansi dan keamanan jaringan di lingkungan cloud. Dengan fitur ini, Anda punya kendali dan wawasan lebih besar atas apa yang terjadi di balik layar jaringan AWS Anda. Sudah saatnya Anda memanfaatkan log jaringan untuk mengamankan sistem Anda lebih baik dari sebelumnya! Infrastruktur IT yang kuat adalah kunci produktivitas perusahaan. Dengan awscloud indonesia, Anda bisa mendapatkan solusi IT lengkap yang sesuai dengan kebutuhan Anda. iLogo Indonesia sebagai mitra terpercaya siap mengintegrasikan semuanya agar bisnis Anda tetap berjalan lancar dan aman. Hubungi kami sekarang atau kunjungi awscloud.ilogoindonesia.id untuk informasi lebih lanjut!