AWS Spot Instance Masih Dicharge 1 Jam? Ini Mitos Lama yang Masih Dipercaya Banyak Orang

Ada satu keyakinan yang terus hidup di kalangan engineer, bahkan yang sudah berpengalaman bertahun-tahun dengan AWS: kalau EC2 Spot Instance jalan 17 menit, tetap saja dicharge satu jam penuh. Keyakinan ini pernah benar — tapi sudah lama tidak relevan. Sayangnya, mitos ini masih sering muncul di diskusi teknis, review arsitektur, bahkan proposal cost optimization yang akhirnya ditolak karena perhitungan biaya yang keliru. Artikel ini membedah dari mana mitos ini berasal, bagaimana mekanisme billing Spot Instance yang sebenarnya berlaku hari ini, kapan model per jam masih relevan, dan kenapa kesalahpahaman ini bisa berdampak nyata ke keputusan arsitektur dan budget infrastruktur.

Asal-usul Mitos: Dulu Memang Per Jam

Sebelum tahun 2017, AWS EC2 menggunakan model hourly billing untuk semua jenis instance. Aturannya sederhana namun kaku:

Model billing sebelum 2017:
  Instance jalan 1 menit   → tetap dibayar 1 jam penuh
  Instance jalan 17 menit  → tetap dibayar 1 jam penuh
  Instance jalan 59 menit  → tetap dibayar 1 jam penuh

Aturan pembulatan ke atas ini berlaku merata untuk On-Demand, Reserved Instance, maupun Spot Instance. Tidak ada pengecualian — siapa pun yang menyalakan instance, walau hanya untuk satu menit, akan ditagih seolah-olah instance itu berjalan selama satu jam penuh.

Jadi secara historis, mitos ini memang fakta. Masalahnya bukan pada keyakinan itu sendiri saat pertama kali terbentuk, melainkan pada fakta bahwa AWS sudah mengubah model billing-nya secara fundamental, sementara banyak engineer tidak pernah meng-update asumsi lama ini ke kondisi terkini.

Pengalaman “dulu pernah pakai AWS dan memang dicharge per jam” bukan kesalahan ingatan — itu memang akurat untuk masanya. Yang jadi masalah adalah ketika pengalaman lama ini dianggap masih berlaku tanpa verifikasi ulang terhadap dokumentasi billing AWS saat ini.

Perubahan Besar: Per-Second Billing Sejak 2017

Pada tahun 2017, AWS memperkenalkan per-second billing untuk EC2 Linux, sebuah perubahan yang mengubah total kalkulasi biaya untuk workload yang berumur pendek.

flowchart LR
    A[Sebelum 2017] -->|Hourly Billing| B[Semua durasi dibulatkan ke atas ke 1 jam]
    C[Sejak 2017] -->|Per-Second Billing| D[Dihitung per detik dengan minimum 60 detik]
    A -.->|Perubahan model AWS| C

Aturan billing yang berlaku saat ini:

• Dihitung per detik, bukan per jam.
• Ada minimum charge 60 detik — instance yang hidup kurang dari satu menit tetap dibayar setara satu menit.
• Setelah melewati 60 detik, biaya dihitung berdasarkan durasi penggunaan yang sesungguhnya, hingga ke satuan detik.
• Berlaku untuk On-Demand Linux dan Spot Instance Linux.

Tabel berikut menunjukkan bagaimana durasi hidup instance diterjemahkan menjadi biaya di bawah model per-second billing:

Tidak ada pembulatan ke satu jam dalam kondisi apa pun di luar minimum charge 60 detik di awal. Inilah perubahan inti yang membuat mitos “dicharge 1 jam” tidak lagi akurat untuk EC2 Linux modern.

Bagaimana Sebenarnya Spot Instance Dicharge

Spot Instance tetap menggunakan model pay-as-you-go yang sama persis dengan On-Demand dalam hal billing. Tidak ada kontrak, tidak ada minimum jam pemakaian, tidak ada penalti saat instance di-terminate, dan tidak ada rounding ke satu jam.

Perbedaan Spot dengan On-Demand hanya terletak pada satu hal: Spot Instance bisa di-terminate oleh AWS kapan saja, ketika kapasitas yang dibutuhkan AWS untuk On-Demand atau Reserved meningkat di availability zone tersebut. Ini soal availability, bukan soal billing.

Diskon harga Spot Instance dibandingkan On-Demand adalah insentif AWS untuk memanfaatkan kapasitas yang sedang tidak terpakai. Trade-off-nya hanya risiko interruption, bukan beban tambahan apa pun di sisi billing.

Kenapa Masih Banyak yang Percaya Mitos Ini

Ada beberapa penyebab umum kenapa kesalahpahaman ini masih bertahan, bahkan di kalangan engineer senior.

Ingatan Lama yang Tidak Di-update

Engineer yang pernah memakai AWS sebelum 2017, tidak pernah mengecek ulang detail billing setelahnya, dan mengandalkan “pengalaman dulu” sebagai sumber kebenaran adalah pola yang sangat umum. Infrastruktur cloud berubah cepat, dan model billing termasuk salah satu hal yang jarang dicek ulang karena dianggap sudah “diketahui”.

Salah Menyalahkan Resource Lain

Ini penyebab yang lebih halus dan sering luput dari perhatian. Sering kali EC2 hidup hanya 17 menit, tapi tagihan bulanan tetap menunjukkan pola seperti per jam. Masalahnya bukan EC2-nya — melainkan komponen lain dalam arsitektur yang memang masih dicharge per jam:

EC2-nya sendiri sudah per detik, tapi komponen pendukung seperti NAT Gateway, ALB, atau Elastic IP yang menganggur tetap hourly-based. Saat melihat total tagihan tanpa memecah per line item, mudah keliru menyimpulkan bahwa EC2 yang jadi penyebab pola “per jam” tersebut.

Windows Instance — Edge Case yang Masih Relevan

Untuk EC2 Windows, billing masih per jam, dan ini berlaku juga untuk Spot Instance berbasis Windows. Namun mayoritas workload modern yang cocok untuk Spot — CI/CD runner, batch processing, worker queue — umumnya berjalan di atas Linux, sehingga edge case ini sering tidak relevan secara praktis, meski ikut menyeret reputasi mitos billing per jam secara umum.

Jika workload spesifik kamu memang berjalan di Windows EC2, verifikasi ulang model billing-nya secara terpisah — generalisasi “semua EC2 sudah per detik” tidak berlaku universal untuk Windows.

Mekanisme Spot Interruption dan Billing-nya

Salah satu kekhawatiran umum soal Spot Instance adalah: bagaimana jika AWS men-terminate instance secara sepihak di tengah proses? Apakah ada biaya tambahan atau penalti?

sequenceDiagram
    participant App as Workload (CI/CD, Batch, dll)
    participant EC2 as Spot Instance
    participant AWS as AWS Capacity Manager
    App->>EC2: Job berjalan
    AWS->>EC2: Interruption notice (2 menit sebelum terminate)
    EC2->>App: Sinyal untuk graceful shutdown / checkpoint
    AWS->>EC2: Terminate instance
    Note over EC2: Billing dihitung sampai detik terakhir instance hidup

Saat terjadi spot interruption — baik karena AWS membutuhkan kembali kapasitas tersebut, maupun karena harga Spot melebihi batas maksimum yang ditetapkan — billing-nya tetap mengikuti aturan yang sama:

• Dihitung sampai detik terakhir instance benar-benar hidup.
• Tidak dibulatkan ke jam.
• Tidak ada termination fee atau penalti tambahan apa pun.

Sebagai contoh konkret: jika instance hidup selama 20 menit sebelum AWS men-terminate-nya karena alasan kapasitas, biaya yang ditagih adalah untuk 20 menit tersebut saja — bukan satu jam penuh.

AWS juga memberikan interruption notice sekitar dua menit sebelum instance benar-benar diterminate, memberi waktu singkat bagi aplikasi untuk melakukan graceful shutdown, menyimpan checkpoint, atau memindahkan state penting — sebuah detail penting untuk desain workload yang resilient terhadap interruption, terlepas dari soal billing.

Cara Membuktikan Sendiri via AWS Cost Explorer

Daripada berdebat berdasarkan opini atau ingatan lama, cara paling objektif untuk memverifikasi klaim ini adalah melihat langsung data billing dari AWS.

Langkah-langkahnya:

1. Buka AWS Cost Explorer dari AWS Console.
2. Filter berdasarkan Service: EC2 - Other atau EC2 - Compute, lalu persempit dengan Usage Type yang mengandung SpotUsage.
3. Lihat detail granularitas usage — akan terlihat breakdown dalam satuan jam desimal (misalnya 0.283 jam, bukan dibulatkan ke 1.0 jam), yang setara dengan menit dan detik aktual penggunaan.

Untuk verifikasi yang lebih presisi hingga ke level individual instance, Cost and Usage Report (CUR) bisa memberikan data dengan granularitas waktu mulai dan waktu berhenti instance secara eksplisit, sehingga durasi pemakaian sesungguhnya bisa dihitung manual dan dibandingkan langsung dengan angka biaya yang muncul.

Data dari Cost Explorer atau CUR adalah bukti yang tidak bisa dibantah opini — jika tim atau stakeholder masih ragu, ajak mereka melihat langsung breakdown usage di akun AWS yang sedang dipakai.

Dampak Mitos Ini ke Keputusan Arsitektur

Kesalahpahaman soal billing ini bukan sekadar trivia teknis — ia bisa memengaruhi keputusan arsitektur dan budget secara langsung.

Dampak negatif yang umum terjadi ketika mitos ini dipercaya:

✗ CI/CD pipeline tetap pakai On-Demand, padahal Spot jauh lebih cocok
✗ Batch job dijalankan di On-Demand karena "Spot nanti tetap mahal kalau short-lived"
✗ Proposal cost optimization ditolak karena over-estimate biaya Spot
✗ Tim ragu mengadopsi auto-scaling dengan instance berumur pendek

Padahal kenyataannya, Spot Instance justru ideal untuk jenis workload yang berumur pendek dan tidak butuh state jangka panjang:

Karakteristik bersama dari workload-workload ini: hidup sebentar, bisa di-retry tanpa efek samping, dan tidak bergantung pada state lokal yang hilang jika instance tiba-tiba mati. Kombinasi karakteristik inilah — bukan asumsi soal billing per jam — yang seharusnya jadi pertimbangan utama saat memutuskan apakah Spot Instance cocok dipakai atau tidak.

Strategi Praktis Mengadopsi Spot Instance

Setelah mitos billing per jam tidak lagi jadi penghalang, langkah berikutnya adalah mengadopsi Spot Instance dengan strategi yang mengakomodasi risiko interruption-nya — bukan risiko cost.

flowchart TD
    A[Workload baru] --> B{Stateless & bisa retry?}
    B -- Tidak --> C[Pertimbangkan On-Demand atau Reserved]
    B -- Ya --> D{Toleran terhadap interruption mendadak?}
    D -- Tidak sama sekali --> C
    D -- Ya, dengan graceful handling --> E[Kandidat kuat untuk Spot Instance]
    E --> F[Kombinasikan dengan Mixed Instance Policy / Spot Fleet untuk redundansi]

Beberapa pendekatan yang umum dipakai untuk menambah resiliency saat mengadopsi Spot:

• Mixed Instance Policy pada Auto Scaling Group — mengombinasikan Spot dan On-Demand dalam satu group, sehingga jika kapasitas Spot di satu jenis instance tidak tersedia, group tetap bisa fallback ke On-Demand atau tipe instance Spot lain.
• Spot Fleet dengan diversifikasi tipe instance — mengurangi risiko semua instance ter-interrupt bersamaan dengan menyebar permintaan ke beberapa instance type dan availability zone.
• Interruption handler di level aplikasi — memanfaatkan jendela waktu sekitar dua menit dari interruption notice untuk checkpoint, deregister dari load balancer, atau memindahkan job yang sedang berjalan.

Checklist singkat sebelum memutuskan memakai Spot Instance: workload tidak menyimpan state penting secara lokal, proses bisa di-restart atau di-retry tanpa efek samping, dan ada mekanisme (baik dari AWS service maupun custom) untuk menangani interruption secara graceful.

Ringkasan

• Mitos “Spot Instance dicharge 1 jam walau cuma jalan 17 menit” memang fakta sebelum 2017, tapi sudah tidak berlaku sejak AWS memperkenalkan per-second billing.
• EC2 Linux (On-Demand maupun Spot) dihitung per detik dengan minimum charge 60 detik — tidak ada pembulatan ke satu jam dalam kondisi apa pun setelahnya.
• Perbedaan Spot dengan On-Demand murni soal availability — Spot bisa di-terminate AWS kapan saja — bukan soal model billing.
• Tagihan yang terlihat seperti per jam sering kali berasal dari resource lain seperti NAT Gateway, Application Load Balancer, atau Elastic IP idle, bukan dari EC2 itu sendiri.
• EC2 Windows masih billing per jam dan berlaku juga untuk Spot — edge case ini valid tapi jarang relevan untuk workload modern berbasis Linux.
• Saat Spot Instance di-terminate AWS, biaya dihitung sampai detik terakhir instance hidup, tanpa termination fee.
• AWS Cost Explorer dan Cost and Usage Report adalah cara paling objektif untuk memverifikasi granularitas billing secara langsung dari data akun sendiri.
• Spot Instance ideal untuk workload stateless dan retry-able seperti CI/CD runner, batch processing, dan queue worker — kombinasikan dengan Mixed Instance Policy atau Spot Fleet untuk menambah resiliency terhadap interruption.