Penyesuaian Ukuran dan Compute Optimizer

Salah satu kesalahan paling umum dan mahal dalam arsitektur cloud adalah penyediaan berlebihan — mengalokasikan lebih banyak sumber daya daripada yang sebenarnya dibutuhkan beban kerja. Tim IT sering melakukan penyediaan berlebihan karena kebiasaan dari lingkungan lokal (membeli kapasitas untuk beban puncak), takut terjadi penurunan performa, atau sekadar tidak pernah meninjau kembali keputusan penentuan ukuran awal. Di AWS, EC2 instances, EBS volumes, dan fungsi Lambda yang disediakan secara berlebihan membuang biaya setiap menit saat berjalan. Penentuan ukuran yang tepat adalah proses sistematis untuk mengidentifikasi dan menghilangkan pemborosan ini.

AWS Compute Optimizer menganalisis metrik pemanfaatan historis dari CloudWatch dan menggunakan machine learning untuk merekomendasikan sumber daya komputasi AWS yang optimal. Layanan ini mencakup EC2 instances, EC2 Auto Scaling Groups, EBS volumes, fungsi Lambda, dan Amazon ECS on Fargate. Compute Optimizer memerlukan riwayat metrik setidaknya selama 30 hari untuk menghasilkan rekomendasi yang andal. Layanan ini gratis untuk diaktifkan dan memberikan rekomendasi beserta estimasi penghematan bulanan serta tingkat risiko perubahan.

Compute Optimizer menganalisis pemanfaatan CPU EC2, pemanfaatan memori (melalui CloudWatch agent), throughput jaringan, dan IOPS EBS selama 3, 14, atau lebih dari 30 hari terakhir. Setelah itu, layanan ini merekomendasikan salah satu dari empat temuan: Dioptimalkan (ukuran saat ini sudah sesuai), Disediakan berlebihan (dapat diperkecil), Disediakan kurang (sebaiknya diperbesar), atau Tidak dioptimalkan (data tidak memadai). Selalu tinjau risiko performa — Compute Optimizer menetapkan risiko VeryLow, Low, Medium, High untuk setiap rekomendasi.

Fungsi Lambda ditagihkan berdasarkan setiap milidetik waktu eksekusi dikalikan dengan memori yang dialokasikan. Mengalokasikan lebih banyak memori daripada yang diperlukan membuang biaya, tetapi memori yang lebih besar juga berarti CPU yang lebih besar — sehingga keseimbangan yang tepat adalah pengaturan memori yang meminimalkan biaya per pemanggilan. Compute Optimizer menganalisis durasi pemanggilan Lambda, tingkat kesalahan, dan metrik batas waktu untuk merekomendasikan pengaturan memori yang optimal. Alat Lambda Power Tuning sumber terbuka juga dapat memanggil fungsi Anda dengan berbagai pengaturan memori untuk menemukan konfigurasi dengan biaya optimal secara empiris.

EBS volumes sering kali disediakan berlebihan, baik dari segi ukuran (ruang disk yang tidak digunakan) maupun IOPS (IOPS yang disediakan tetapi tidak pernah digunakan). Compute Optimizer menganalisis metrik VolumeReadOps, VolumeWriteOps, VolumeReadBytes, VolumeWriteBytes. Rekomendasi umum: migrasikan dari gp2 ke gp3 (yang memisahkan ukuran dari IOPS) — Anda dapat menentukan ukuran IOPS secara terpisah, sehingga sering menghemat 20%. Identifikasi juga EBS volumes yang tidak terpasang (instances dihentikan tetapi volumes ditinggalkan), lalu buat snapshot atau hapus volumes tersebut.

Compute Optimizer menganalisis pemanfaatan ASG di seluruh instances dalam grup dan merekomendasikan perubahan launch template untuk tipe instance. Jika semua instances dalam ASG terus-menerus disediakan secara berlebihan, beralih ke tipe instance yang lebih kecil akan mengurangi biaya dalam skala besar. Misalnya, jika sebuah ASG rata-rata memiliki 10 instances m5.large, beralih ke m5.medium menghemat 50% per instance. Compute Optimizer juga merekomendasikan instances berbasis Graviton jika perangkat lunak Anda kompatibel, sehingga memberikan peningkatan performa sekaligus pengurangan biaya.

AWS Trusted Advisor adalah alat lain yang memberikan wawasan optimasi biaya, selain pemeriksaan keamanan, performa, toleransi kesalahan, dan batas layanan. Pemeriksaan biaya utama: Low Utilization EC2 Instances (CPU kurang dari 10% selama 4 hari atau lebih), Unassociated Elastic IP Addresses (dikenai biaya saat tidak terpasang), Underutilized EBS Volumes, Idle Load Balancers (tidak memiliki target yang sehat), dan Unused Reserved Instances. Pemeriksaan dasar Trusted Advisor gratis; seluruh rangkaian pemeriksaan memerlukan dukungan Business atau Enterprise.

AWS secara berkala merilis generasi EC2 instances baru yang lebih efisien dan menawarkan performa lebih baik dengan biaya yang lebih rendah atau sama. Beralih dari generasi ke-5 (m5, c5, r5) ke generasi ke-7 (m7g, c7g, r7g) dapat memberikan performa komputasi 40% lebih baik dengan biaya yang serupa atau lebih rendah. Compute Optimizer secara khusus menandai peluang untuk meningkatkan ke generasi yang lebih baru, termasuk instances berbasis Graviton. Peningkatan instance sering kali merupakan tindakan penentuan ukuran yang tepat paling sederhana — konfigurasi sama, perangkat keras lebih baru, performa lebih baik, biaya lebih rendah.

RDS instances mahal dan sering kali disediakan berlebihan. Gunakan CloudWatch metrics untuk mengevaluasi pemanfaatan RDS: CPUUtilization, FreeableMemory, ReadIOPS, dan WriteIOPS. Jika CPU tetap di bawah 20% dan memori terus-menerus tinggi, pertimbangkan untuk memperkecil ukuran. Untuk database produksi dengan Multi-AZ, penentuan ukuran yang tepat menggandakan penghematan karena primary dan standby sama-sama diubah. Pertimbangkan juga untuk beralih dari RDS MySQL/PostgreSQL ke Aurora, yang sering memberikan performa lebih baik dengan biaya serupa dan lebih efisien dari segi biaya dalam skala besar.

Penentuan ukuran yang tepat harus menjadi proses berkelanjutan, bukan kegiatan sekali saja. Tetapkan jadwal review bulanan atau kuartalan: ambil rekomendasi Compute Optimizer, evaluasi rekomendasi yang aman untuk diterapkan, terapkan perubahan dalam jendela pemeliharaan, dan ukur penghematannya. Otomatiskan tindakan yang mudah: pembersihan EBS volumes yang tidak terpasang, pelepasan Elastic IP yang tidak digunakan, dan penghapusan load balancer yang tidak aktif dapat dibuat dalam script. Buat Cost Optimisation Dashboard di CloudWatch yang melacak pengeluaran bulanan berdasarkan layanan dan menyoroti kenaikan yang tidak biasa.

Penentuan ukuran yang tepat mengatasi penyediaan berlebihan dalam arsitektur yang ada, tetapi terkadang arsitekturnya sendiri merupakan masalah. Satu EC2 instance besar yang menjalankan beberapa aplikasi mungkin memerlukan pemecahan arsitektur (microservices di Fargate), bukan sekadar instance yang lebih kecil. Database monolitik mungkin memerlukan sharding atau caching, bukan sekadar memperkecil ukuran instance. Penentuan ukuran yang tepat adalah langkah pertama dan tercepat. Optimasi arsitektur (serverless, containers, caching) memberikan penghematan yang lebih besar dan berkelanjutan, tetapi memerlukan lebih banyak upaya. Pilar Cost Optimisation merekomendasikan penerapan keduanya.

Uji pemahaman Anda tentang konsep AWS Solutions Architect (SAA-C03) dari pelajaran ini.

Dalam pelajaran ini Anda mempelajari bahwa: AWS Compute Optimizer menggunakan machine learning pada metrik CloudWatch untuk merekomendasikan sumber daya komputasi dengan ukuran yang tepat, penentuan ukuran yang tepat berlaku untuk EC2, Lambda, EBS, ASG, dan ECS on Fargate, dan peningkatan ke generasi instance yang lebih baru (terutama Graviton) memberikan peningkatan biaya dan performa. Jadikan penentuan ukuran yang tepat sebagai praktik berulang, bukan kegiatan sekali saja. Selanjutnya, kita akan membahas Reserved Instances, Savings Plans, dan model pembelian Spot.