AWS 2025: Hal-Hal yang Anda Kira Sudah Tahu, tetapi Kini Salah

• Layanan inti AWS berkembang sangat cepat
• Fitur-fitur utama seperti EC2, S3, Lambda kini memberikan kinerja dan fleksibilitas yang melampaui ekspektasi pengguna dibanding masa lalu
• Banyak perubahan dan optimasi juga telah dilakukan pada jaringan, autentikasi, dan cara penghematan biaya
• Kebingungan bisa muncul karena posting blog lama atau informasi usang
• Memahami pembaruan terbaru dan perubahan kebijakan adalah hal yang esensial untuk memanfaatkan AWS

---

AWS 2025: Kondisi Saat Ini yang Berbeda dari Persepsi Masa Lalu

• AWS adalah platform cloud dengan sejarah hampir 20 tahun, dan karena itu “pengetahuan umum” tentang layanannya terus berubah
• Bahkan pengguna lama pun bisa kesulitan mengikuti cepatnya perubahan, karena begitu banyak fitur inti yang telah ditingkatkan
• Masih banyak posting blog yang menyajikan informasi lama, jadi penting untuk memahami dengan tepat perubahan pada konfigurasi yang sebenarnya

EC2

• Security group dan IAM role untuk instance EC2 kini dapat diubah tanpa downtime
• Pada instance yang sedang berjalan, kini dimungkinkan untuk mengubah ukuran volume EBS serta melakukan attach/detach
• Instance EC2 terbaru dapat dipaksa stop atau terminate, sehingga tidak perlu menunggu timeout yang panjang
• Fitur live migration antar host fisik telah diperkenalkan, sehingga peringatan penurunan performa instance kini jauh lebih jarang
• Keandalan instance meningkat drastis, sehingga hampir tidak ada lagi kasus instance menghilang tanpa peringatan seperti dulu
• Fluktuasi harga Spot instance kini berubah secara bertahap, sehingga tidak perlu lagi memantaunya terus-menerus seperti arena spekulasi
• Kasus yang benar-benar memerlukan dedicated instance kini sangat jarang (bahkan HIPAA BAA hampir 10 tahun lalu pun sudah tidak memerlukannya)
• AMI Block Public Access diaktifkan sebagai default pada akun baru (per 2023, juga berlaku pada akun yang tidak memiliki public AMI selama lebih dari 90 hari)

S3

• S3 tidak lagi Eventually Consistent, melainkan menyediakan Read-After-Write Consistency
• Tidak perlu lagi mengacak bagian awal object key, sehingga kekhawatiran soal distribusi data dan hotspot berkurang
• ACLs (Access Control List) tidak lagi direkomendasikan, dan pada bucket baru dinonaktifkan secara default
• Bucket baru memiliki Block Public Access sebagai pengaturan default
• Enkripsi data tersimpan diterapkan secara otomatis
• Glacier dulunya adalah layanan terpisah sebelum menjadi storage class di S3, tetapi sekarang sudah digabung. Jejaknya hanya tersisa di hal seperti rincian tagihan
• Biaya dan kecepatan restore Glacier kini jauh lebih dapat diprediksi dan lebih murah dibanding masa lalu. Ketakutan lama soal biaya restore yang mengerikan sudah tidak lagi benar

Jaringan (Networking)

• EC2-Classic telah hilang sepenuhnya
• Alamat IPv4 publik kini tidak lagi gratis, dan dikenakan biaya yang sama seperti Elastic IP
• Sebagai pengganti VPC Peering, kini ada opsi yang lebih baik seperti Transit Gateway, berbagi VPC/resource, dan Cloud WAN
• VPC Lattice dan Tailscale memungkinkan penyelesaian masalah jaringan yang kompleks dengan lebih mudah
• Waktu propagasi pembaruan CloudFront dipangkas dari 45 menit menjadi sekitar 5 menit (meski saat menunggu deployment CloudFormation tetap bisa terasa lama)
• ELB Classic mengenakan biaya transfer data lintas AZ, sedangkan ALB hanya mengenakan biaya LCU. Perlu diperhatikan bahwa NLB masih mengenakan biaya lintas AZ
• Network Load Balancer kini mendukung security group
• Dulu ID Availability Zone berbeda untuk tiap akun, tetapi kini penyelarasan Zone ID dimungkinkan melalui Resource Access Manager

Lambda

• Batas waktu eksekusi Lambda meningkat dari 5 menit menjadi 15 menit, dan kini mendukung container image (Docker), shared storage EFS, hingga 10GB RAM, serta /tmp 10GB
• Kecepatan pemanggilan Lambda di dalam VPC meningkat drastis
• Masalah cold start jauh lebih teredam dibanding masa lalu

EFS

• Penyesuaian performa I/O EFS kini dapat diatur terpisah dari kapasitas, sehingga tidak perlu lagi memenuhi ruang dengan data yang tidak bermakna

EBS

• Volume EBS baru dapat langsung menggunakan performa maksimum jika tidak memiliki data dasar
• Volume yang dibuat dari snapshot bisa lambat saat pembacaan data pertama, sehingga disarankan membaca seluruh disk sekali (opsi yang lebih cepat juga tersedia)
• Volume io1 dapat dihubungkan secara bersamaan ke beberapa instance EC2, tetapi pada praktiknya hanya direkomendasikan untuk situasi yang sangat khusus

DynamoDB

• Kini mengizinkan field kosong di dalam item
• Performanya menjadi jauh lebih konsisten, sehingga kebutuhan memantau masalah hot key dengan alat terpisah seperti dulu makin berkurang
• Dengan perubahan pricing, bagi kebanyakan pengguna tipe On Demand kini lebih masuk akal

Opsi Penghematan Biaya (Cost Savings Vehicles)

• Reserved Instances secara bertahap menuju penghentian, dan Savings Plans menjadi standar ke depan. Tingkat diskon Savings Plan memang turun dibanding RI, tetapi fleksibilitasnya lebih tinggi
• Biaya penggunaan EC2 kini ditagihkan per detik, sehingga menyalakan instance untuk waktu yang sangat singkat pun tetap efisien dari sisi biaya
• Cost Anomaly Detector mendeteksi pola penggunaan tak terduga dengan akurasi tinggi dan tersedia gratis
• Compute Optimizer memberikan rekomendasi yang andal untuk berbagai resource seperti EBS. Rekomendasi Trusted Advisor masih kurang konsisten

Autentikasi (Authentication)

• Pemberian izin melalui IAM role direkomendasikan, sementara IAM user hanya cocok untuk aplikasi lama
• IAM Identity Center menggantikan AWS SSO dan digunakan untuk akses akun. Hal ini menimbulkan sedikit kebingungan
• Kini dimungkinkan mendaftarkan beberapa perangkat MFA pada akun root
• Tidak perlu mengonfigurasi kredensial root secara terpisah untuk akun anggota organisasi

Lain-lain (Miscellaneous)

• Keandalan dan durabilitas us-east-1 jauh meningkat dibanding sebelumnya. Gangguan yang dulu sering terjadi kini justru cukup langka hingga layak menjadi berita
• Deprecation layanan AWS masih jarang terjadi, tetapi trennya meningkat, sehingga ketergantungan pada layanan kecil perlu dipertimbangkan
• Fenomena titik terakhir pada data CloudWatch yang tampil tidak normal karena ketidakkonsistenan dan terlihat terlalu rendah kini sudah tidak terjadi lagi
• Dari akun root, kini dimungkinkan untuk langsung menutup akun AWS anggota di dalam organisasi

[roxie]

Wah, benar-benar banyak berubah ya.

[howudoin]

AWS sekarang tidak bisa lagi dipakai dengan memilih satu layanan saja.
Kalau mau mengerjakan satu hal, harus mengaitkan dan memakai macam-macam layanan sekaligus.
Sama sekali tidak sederhana.
Kalau dipakai di venture, yang harus dibayar bukan cuma biaya cloud, tetapi juga biaya tenaga kerja devops.
Kalau ingin membangunnya dengan benar, beban kerja malah melonjak tidak sebanding sampai-sampai waktu pengembangan habis tersita.
Selain itu, makin banyak kasus di mana lebih baik memakai managed service, sehingga sejak level kode pun sudah menjadi bergantung pada platform.

[GN⁺]

Pendapat Hacker News

• Melihat bahwa "Block Public Access" di S3 sekarang diterapkan secara default pada bucket baru, menurut saya itu keputusan yang jelas benar; selama ini sudah banyak kebocoran data besar terjadi karena bucket S3 yang salah konfigurasi. Tapi kadang saya memang ingin membuat bucket S3 dengan izin baca publik untuk menyajikan file secara terbuka, dan setiap kali selalu ada sesuatu yang berubah, sehingga resep lama tidak berlaku lagi dan saya harus belajar lagi dari awal.
  • Saya ingin bilang: perhatikan baik-baik pengaturan "Block Public Access". Ini semacam pengaman agar orang tidak melakukan kesalahan besar. Bahkan jika Anda mengatur bucket policy atau ACL yang sangat longgar (meski ACL sudah kuno, masih tetap dipakai), akses publik tetap tidak akan mungkin jika Block Public Access aktif. Sebaliknya, jika Block Public Access dimatikan dan Anda memakai bucket policy yang dirancang dengan baik, itu juga tidak masalah. Bucket policy sepenuhnya menentukan siapa yang bisa mengakses. Tentu saja dalam jangka panjang, policy bisa berubah tanpa sengaja, peran IAM bisa ditambahkan tanpa diduga, atau trust policy bisa berubah, jadi pengelolaan untuk hal-hal seperti itu tetap penting.
  • Saya sering memakai LLM untuk situasi seperti ini. Saya minta ia membaca dokumentasi dan mengambilkan kode demo yang tersebar di berbagai halaman dokumentasi resmi AWS. Setelah dapat, saya langsung minta penyesuaian kustom yang saya inginkan.
  • Ini terasa seperti déjà vu, seperti “bukankah ini dulu juga pernah terjadi?” Rasanya 10 tahun lalu semua orang juga membiarkan bucket terbuka, lalu tindakan seperti ini diterapkan karena itu.
  • Perubahan seperti ini membuat pertanyaan wawancara seperti “apakah Anda familiar dengan teknologi ini?” jadi sangat ambigu. Teknologinya berubah tiap bulan, jadi saya ingin bertanya: tahunya berdasarkan kondisi kapan?
  • Kalau mau belajar secara resmi, mereka dengan senang hati akan meminta Anda membayar $250 dan ikut ujian sertifikasi.
• Di EC2, kemampuan mengganti security group atau peran IAM tanpa menghentikan instance sebenarnya sudah ada sejak beberapa tahun lalu. Spot Instance dulu adalah pasar lelang, tapi sekarang mekanisme lelangnya sendiri sudah hilang, jadi justru jauh lebih baik karena tidak ada lagi fluktuasi harga yang tajam atau akses yang hanya tersedia bagi pengguna tertentu. Dan dulu kita harus membuat prefix object key secara acak untuk menghindari hotspot, tetapi sekarang itu tidak perlu lagi. Saya butuh waktu lama untuk meyakinkan rekan kerja soal ini, tapi toh mereka hanya menyimpan file-file super kecil yang sama sekali tidak terkait dengan bottleneck backend S3. Lambda dulu punya batas 5 menit dan tidak mendukung container image, tetapi sekarang mendukung runtime 15 menit, image Docker, berbagi EFS, RAM hingga 10GB, dan ruang penyimpanan /tmp hingga 10GB. Saya juga menyadari satu hal: global scope Python juga bisa bertahan seperti /tmp.
• Pemulihan Glacier sekarang tidak harus terasa lambat dan menyakitkan. Dengan gaya menebak ala Amazon, saya dulu membayangkan Glacier lama benar-benar berjalan di suatu gudang logistik Amazon; ketika data diminta, seorang pekerja akan mengambil media portabel dari rak lalu mencolokkannya ke server. Rasanya mirip cara backup pita pada komputer timesharing zaman dulu, ketika pitanya benar-benar harus diganti secara fisik.
  • Saya rasa kemungkinan besar mereka sebenarnya memakai perangkat otomatis seperti robot pita, contoh foto terkait. Bukan manusia, melainkan robot yang mencari pita, memasukkannya ke drive, menggulung ke offset yang tepat, membaca, lalu menggulung kembali dan mengembalikannya. Waktu tunggu muncul karena pencarian pita, proses rewind, dan antrean drive. Mungkin demi efisiensi, sekali sebuah pita dimasukkan, semua permintaan pada pita itu diproses dulu sebelum dikeluarkan lagi.
  • Saya tidak bisa membicarakan detail internal, tetapi saya belum pernah melihat orang yang menebak desain Glacier dengan tepat. Saya juga dulu pernah bekerja di AWS, dan yang bisa saya katakan adalah Glacier tetap dioperasikan di data center yang sama dengan layanan AWS lainnya. Dalam engineering maupun product management, yang penting adalah mengelola ekspektasi pelanggan dengan baik. Jika Anda mengatakan batas unggahan adalah 10 tetapi diam-diam membiarkan 12, pelanggan akan terus berekspektasi 12. Mengelola ekspektasi itu penting.
  • Karena hard disk itu seragam, saya mengira bagian gudangnya dijalankan dengan robot otomatis. Manusia biasanya dipakai untuk menangani hal-hal nonstandar seperti ukuran dan bentuk yang beragam.
  • Bagaimanapun juga, peralatan seperti ini memang sudah dirobotisasi sejak puluhan tahun lalu.
• Saya sudah tidak bisa login ke akun AWS saya lagi karena saya tidak menyiapkan MFA sebelumnya. Untuk menerbitkan perangkat pun saya harus login dulu. Saya memang sudah diperingatkan sebelumnya, tetapi struktur yang tidak memungkinkan pengajuan perangkat MFA tanpa login itu cukup menjengkelkan.
  • Sepertinya sebaiknya hubungi tim dukungan.
    Hubungi AWS Support
  • Ini terlihat seperti masalah yang seharusnya mudah diselesaikan oleh tim support.
• Saya rasa ada banyak orang seperti saya yang sekarang ingin meninggalkan gaya AWS yang biasa—kerumitan menyetel API Gateway, serverless Lambda, sampai peran IAM—dan hanya ingin memakai EC2 atau VPS LightSail, bucket S3, lalu menghubungkan domain lewat Route53 tanpa memikirkan sisanya.
  • Kalau hanya akan memakai storage + VPS, VPS tradisional jauh lebih murah daripada AWS. Filsafat saya justru: kalau sudah memakai AWS, pakailah dengan benar dan sebanyak mungkin. Serahkan semua yang bisa didelegasikan ke Amazon untuk efisiensi dan penghematan biaya. Step Functions, Lambda, dan DynamoDB juga sudah mengungguli alternatifnya. Hanya saja, menurut saya para developer sering kali tidak cukup baik dalam mengoptimalkan pemanfaatan vendor.
  • Memang ada banyak industri yang menyederhanakan penggunaan cloud, dan alasannya adalah keterbatasan wilayah layanan atau penagihan yang lebih dapat diprediksi.
  • Mengelola IAM sangat menghabiskan waktu; terasa seperti waktu yang dulu dipakai untuk administrasi sistem sekarang habis seluruhnya untuk mengelola izin. IAM terlalu sulit, jadi secara praktik justru rugi bersih. Mungkin ada sweet spot di antara VPS dan pengelolaan least privilege serverless yang berlebihan. Fargate tampaknya kandidat untuk itu, jadi saya ingin terus bereksperimen sambil lebih banyak berpindah ke sana.
• Saya berharap AWS lebih fokus pada "layanan dasar tapi penting" yang memang sudah mereka kuasai, alih-alih terlihat berantakan dengan merilis banyak hal di sisi AI hanya demi mengejar bidang lain. Rasanya kepemimpinan AWS kehilangan arah di area GenAI, tetapi mereka tetap jago membuat infrastruktur dasar. Karena AI, mereka tampak panik, dan dari sudut pandang pelanggan ini terasa terlalu kacau dan tidak nyaman.
  • Arah kepemimpinan saat ini adalah membuat infrastruktur sehingga semua orang bisa dengan mudah memilih model dan langsung memakainya. Mereka mengejar lingkungan yang bisa langsung digunakan tanpa kerumitan setup.
• Sangat tidak masuk akal bahwa bucket S3 yang berada di region yang sama dengan VPC tetap menimbulkan biaya NAT Gateway jika lalu lintasnya lewat internet publik. Seharusnya default-nya opt-out, tetapi yang jadi default justru opt-in; saya menduga itu karena AWS mendapat pemasukan tambahan dari struktur ini. Sangat sedikit pengguna yang benar-benar menginginkan rute seperti sekarang.
  • Ini dirancang dengan mempertimbangkan bahwa keamanan adalah default. Tanpa mengatur NAT Gateway, VPC Gateway Endpoint (S3), atau jalur keluar internet lain, workload memang tidak bisa mengakses S3. Networking seharusnya tertutup; jika pengguna membuat sesuatu tanpa benar-benar memahami jalurnya, tanggung jawabnya ada pada pelanggan. AWS harus dipandang hanya menyediakan alat-alat mentah Infrastructure as a Service (IaaS).
  • S3 VPC Gateway Endpoint memang ada tepat untuk tujuan ini, dan gratis.
    Dokumentasi resmi AWS
  • Setelah benar-benar menyiapkan VPC, subnet, endpoint PrivateLink, dan sebagainya, ini terasa sangat konyol. Mereka bahkan sangat memikirkan penamaan PrivateLink (meski secara teknis memang ada artinya), padahal hal seperti ini semestinya tersedia secara default tanpa perlu setup. Bahkan jika memakai private subnet, bukankah akses ke S3 dan sejenisnya memang hanya mungkin lewat PrivateLink? Rasanya aneh.
  • Saya rasa semua VPC endpoint seharusnya diterapkan gratis secara default. Struktur biaya tambahan bahkan untuk memakai API layanan mereka sendiri terasa keterlaluan.
  • Ini demi diferensiasi harga. Pelanggan yang tidak sensitif terhadap harga tidak akan terlalu peduli. Yang peduli akan berusaha menekan biaya, dan bahkan dalam situasi seperti itu pun sering kali tetap terpaksa memakai AWS.
• Artikel ini justru membuat saya tenang. Saya selalu khawatir Amazon akan mengubah sesuatu secara besar-besaran lalu memaksa migrasi, tetapi sejak 2013 saya hampir tidak perlu mengelola instance EC2 sama sekali dan semuanya berjalan baik. Syukurlah tidak ada perubahan tak terduga.
• Mengejutkan bahwa dulu Availability Zone dipetakan secara acak per akun.
  • Itu untuk pemerataan beban. Jika banyak akun memakai AZ tertentu seperti 1b secara tetap, tujuannya adalah agar distribusi fisik yang sebenarnya tetap tersebar merata. Belakangan nama kanonis per AZ disediakan, mungkin karena akun yang benar-benar membuat hotspot berbeda dengan akun yang membutuhkan metadata.
  • Saya rasa tujuannya adalah mencegah semua orang memilih us-east-1a pada konfigurasi default lalu menumpuk di AZ tertentu.
  • Awalnya ini bagus untuk pemerataan beban, tetapi ketika menghubungkan jaringan antar akun—seperti dengan PrivateLink—jadi membingungkan karena harus memeriksa satu per satu AZ mana yang cocok dengan yang mana. Karena itu kami sampai membuat metodologi pemetaan satu lawan satu per akun dan membangun tabel lookup internal, tetapi belakangan AWS menambahkan zone ID ke metadata sehingga bisa dicek dengan mudah.
  • Saya benar-benar banyak menderita gara-gara kebijakan ini.
• Ada satu hal yang ingin saya luruskan: pengetahuan remeh yang tampak tak berarti pun bisa jungkir balik.
  Weird Al: Everything You Know is Wrong
  Firesign Theatre: Everything You Know is Wrong