Optimasi Biaya AWS S3 2026: Panduan Lif…

Q: Bagaimana cara menghapus incomplete multipart upload yang sudah ada?

Jalankan aws s3api list-multipart-uploads --bucket NAMA untuk melihat daftarnya, lalu abort masing-masing dengan aws s3api abort-multipart-upload --bucket NAMA --key OBJECT_KEY --upload-id UPLOAD_ID . Setelah itu, pasang lifecycle rule AbortIncompleteMultipartUpload dengan DaysAfterInitiation: 7 agar kasus serupa tidak terulang.

Diperbarui: 13 Juni 2026

Optimasi biaya AWS S3 adalah proses memindahkan objek ke storage class yang lebih murah, menghapus data yang tidak terpakai, serta mengurangi biaya request dan data transfer. Di tahun 2026, kombinasi S3 Intelligent-Tiering, lifecycle policy, dan penghapusan incomplete multipart upload rata-rata memangkas tagihan S3 sebesar 40–70% tanpa mengubah satu baris kode pun. Jujur saja, ini area FinOps dengan ROI tercepat yang pernah saya tangani. Di panduan ini saya akan tunjukkan langkah demi langkah cara mengaudit bucket, memilih storage class yang tepat, dan menyusun lifecycle policy yang aman untuk produksi.

S3 Intelligent-Tiering otomatis memindahkan objek antar tier dengan biaya monitoring hanya $0,0025 per 1.000 objek per bulan, cocok untuk pola akses yang sulit diprediksi.
Lifecycle policy yang menargetkan transisi ke Glacier Instant Retrieval setelah 90 hari dapat menurunkan biaya penyimpanan hingga 68% dibanding S3 Standard.
Incomplete multipart upload yang tidak dihapus bisa menyumbang 5–20% dari total tagihan S3. Selalu pasang rule AbortIncompleteMultipartUpload.
S3 Storage Lens versi gratis memberikan 28 metrik tingkat akun untuk mengidentifikasi bucket boros tanpa biaya tambahan.
Glacier Deep Archive ($0,00099/GB/bulan) adalah pilihan termurah untuk data yang diakses kurang dari sekali per tahun.
Data transfer keluar (egress) sering kali lebih mahal daripada biaya penyimpanan itu sendiri. Manfaatkan VPC Endpoint dan CloudFront untuk menekannya.

Memahami Anatomi Tagihan AWS S3

Sebelum mulai mengoptimalkan, Anda perlu memahami bahwa tagihan S3 terdiri dari empat komponen utama: biaya penyimpanan ($/GB/bulan per storage class), biaya request (GET, PUT, LIST, DELETE), biaya data transfer keluar (ke internet atau region lain), dan biaya fitur tambahan seperti S3 Replication, S3 Object Lock, atau S3 Inventory. Dari pengalaman saya menangani lebih dari 50 audit FinOps, kesalahan terbesar tim engineering Indonesia adalah hanya fokus pada biaya penyimpanan dan mengabaikan komponen lainnya. Padahal biaya request dan egress sering kali menyumbang 30–50% dari total tagihan.

Langkah pertama, pecah tagihan menggunakan Cost Explorer dengan filter Service = "Amazon S3" dan group by "Usage Type". Anda akan melihat baris seperti USE1-TimedStorage-ByteHrs (storage Standard), USE1-Requests-Tier1 (PUT/POST/LIST), dan USE1-DataTransfer-Out-Bytes. Kalau baris DataTransfer atau Requests jauh lebih besar dari ekspektasi, masalahnya bukan di storage class, melainkan di pola akses aplikasi atau konfigurasi CDN yang salah.

Gunakan query AWS Cost and Usage Report (CUR) berikut untuk memetakan biaya per bucket:

SELECT
  line_item_resource_id AS bucket,
  line_item_usage_type,
  SUM(line_item_unblended_cost) AS cost_usd
FROM aws_cur_v2
WHERE line_item_product_code = 'AmazonS3'
  AND year = '2026' AND month = '6'
GROUP BY 1, 2
ORDER BY cost_usd DESC
LIMIT 50;

Storage Class S3 di 2026: Harga & Kapan Digunakan

AWS menawarkan delapan storage class utama dengan trade-off antara harga, latensi, dan durabilitas. Memilih kelas yang tepat adalah pengungkit terbesar untuk menekan biaya. Tabel berikut merangkum harga di region ap-southeast-3 (Jakarta) per Juni 2026 dan kasus penggunaan yang ideal.

Storage Class	Harga (USD/GB/bulan)	Min. Durasi	Latensi Akses	Kapan Dipakai
S3 Standard	$0,025	Tidak ada	Milidetik	Data aktif, frekuensi akses tinggi
S3 Intelligent-Tiering	$0,025 → $0,00099	Tidak ada	Milidetik	Pola akses tidak terprediksi
S3 Standard-IA	$0,0138	30 hari	Milidetik	Akses 1x/bulan, butuh cepat
S3 One Zone-IA	$0,011	30 hari	Milidetik	Data yang bisa di-regenerate
Glacier Instant Retrieval	$0,005	90 hari	Milidetik	Arsip dengan akses sesekali
Glacier Flexible Retrieval	$0,0042	90 hari	Menit-jam	Backup, archive log
Glacier Deep Archive	$0,00099	180 hari	12 jam	Arsip compliance jangka panjang

Catatan penting: minimum durasi billable berarti jika Anda menghapus objek sebelum durasi tersebut, AWS tetap menagih sisa periode. Contoh nyata, objek 1TB di Standard-IA yang dihapus setelah 10 hari tetap ditagih untuk 30 hari penuh. Inilah alasan transisi ke IA atau Glacier hanya menguntungkan untuk objek yang benar-benar jarang diakses dan tidak akan dihapus dalam waktu dekat. Saya pernah menyaksikan tim memindahkan ratusan TB log harian ke Standard-IA, lalu menyesal karena rotasi penghapusan tujuh hari menggandakan tagihan mereka.

S3 Intelligent-Tiering: Otomasi Tier Tanpa Risiko

S3 Intelligent-Tiering adalah fitur favorit saya untuk tim yang tidak punya bandwidth menganalisis pola akses tiap bucket. AWS secara otomatis memantau setiap objek dan memindahkannya antara Frequent Access, Infrequent Access, Archive Instant Access, Archive Access, dan Deep Archive Access berdasarkan pola akses 30 hari terakhir. Anda cuma membayar biaya monitoring $0,0025 per 1.000 objek per bulan. Tidak ada biaya retrieval, tidak ada minimum durasi.

Aktivasi Intelligent-Tiering paling efektif untuk bucket dengan objek >128 KB (objek lebih kecil tetap di Frequent Access dan tidak mendapat manfaat). Berikut perintah AWS CLI untuk mengaktifkannya pada bucket existing:

aws s3api put-bucket-intelligent-tiering-configuration \
  --bucket nama-bucket-anda \
  --id "OptimizeAll" \
  --intelligent-tiering-configuration '{
    "Id": "OptimizeAll",
    "Status": "Enabled",
    "Tierings": [
      {"Days": 90, "AccessTier": "ARCHIVE_ACCESS"},
      {"Days": 180, "AccessTier": "DEEP_ARCHIVE_ACCESS"}
    ]
  }'

Untuk objek baru, set storage class langsung pada saat upload:

aws s3 cp ./laporan-2026.parquet s3://nama-bucket-anda/ \
  --storage-class INTELLIGENT_TIERING

Kalau Anda sudah pernah membaca 12 strategi optimasi biaya cloud 2026, prinsip "otomasi sebelum optimasi manual" terbukti pas di sini. Intelligent-Tiering menggeser keputusan tier dari manusia ke algoritma AWS, dan biasanya algoritma menang.

Cara Membuat Lifecycle Policy yang Aman

Lifecycle policy adalah aturan yang mengotomasi transisi storage class dan penghapusan objek berdasarkan umurnya. Berbeda dengan Intelligent-Tiering yang reaktif terhadap pola akses, lifecycle policy proaktif berdasarkan waktu. Kombinasi keduanya menghasilkan penghematan optimal: gunakan Intelligent-Tiering untuk data berukuran besar dengan akses tidak terprediksi, dan lifecycle policy untuk data dengan pola usia yang jelas (log, backup, arsip transaksi).

Template lifecycle policy yang saya rekomendasikan untuk bucket log aplikasi:

{
  "Rules": [
    {
      "ID": "log-archival-2026",
      "Status": "Enabled",
      "Filter": { "Prefix": "logs/" },
      "Transitions": [
        { "Days": 30, "StorageClass": "STANDARD_IA" },
        { "Days": 90, "StorageClass": "GLACIER_IR" },
        { "Days": 365, "StorageClass": "DEEP_ARCHIVE" }
      ],
      "Expiration": { "Days": 2555 },
      "AbortIncompleteMultipartUpload": { "DaysAfterInitiation": 7 }
    }
  ]
}

Terapkan rule menggunakan AWS CLI:

aws s3api put-bucket-lifecycle-configuration \
  --bucket nama-bucket-anda \
  --lifecycle-configuration file://lifecycle.json

Menghapus Incomplete Multipart Upload

Multipart upload memungkinkan klien S3 mengunggah file besar dalam potongan paralel. Masalahnya, kalau upload gagal di tengah jalan (jaringan putus, proses crash), potongan yang sudah terunggah tetap tersimpan di S3 dan ditagih sebagai storage Standard, tapi tidak terlihat di aws s3 ls. Honestly, ini "biaya tersembunyi" terbesar di S3 dan saya pernah menemukannya menggerogoti 18% tagihan klien fintech selama hampir setahun.

Untuk mengecek berapa banyak storage terbuang:

aws s3api list-multipart-uploads --bucket nama-bucket-anda \
  --query 'Uploads[*].[Key,Initiated]' --output table

Solusi permanennya, tambahkan rule AbortIncompleteMultipartUpload ke semua lifecycle policy seperti contoh sebelumnya. AWS akan menghapus potongan upload yang lebih tua dari 7 hari secara otomatis. Berdasarkan data AWS Storage Blog, fitur ini saja rata-rata menyelamatkan 5–20% tagihan bucket dengan workload upload tinggi.

Menggunakan S3 Storage Lens untuk Audit

S3 Storage Lens adalah dashboard analitik tingkat akun yang memberikan visibilitas penuh terhadap penggunaan dan tren biaya storage. Versi gratis (default dashboard) mencakup 28 metrik dengan retensi 14 hari, sementara versi advanced ($0,20 per juta objek per bulan) menambahkan rekomendasi optimasi dan retensi 15 bulan. Dokumentasi resmi tersedia di AWS S3 Storage Lens documentation, dan referensi pricing terbaru bisa Anda cek di halaman harga resmi Amazon S3.

Tiga metrik kunci yang harus Anda pantau setiap bulan:

Incomplete Multipart Upload Bytes: harus mendekati 0 setelah lifecycle policy diterapkan.
Non-Current Version Bytes: kalau versioning aktif, jumlah ini bisa membengkak diam-diam.
Storage Class Distribution: proporsi data di Standard vs IA vs Glacier. Tim FinOps yang matang biasanya memiliki <30% data di Standard.

Strategi optimasi container yang serupa juga saya jelaskan di panduan optimasi biaya Kubernetes 2026. Pola "ukur dulu, optimasi kemudian" adalah dasar dari FinOps yang baik, dan ini berlaku untuk hampir semua layanan AWS yang saya tangani.

Mengurangi Biaya Request dan Data Transfer

Biaya request S3 sering diabaikan karena terlihat kecil per unit ($0,005 per 1.000 PUT, $0,0004 per 1.000 GET di region Jakarta). Tapi untuk workload analitik yang membaca jutaan objek kecil, biaya ini bisa melampaui biaya storage. Tiga teknik untuk menekannya:

Konsolidasi objek kecil: gabungkan file log per jam menjadi satu file harian dalam format Parquet atau ORC. Mengubah 1 juta objek 10 KB menjadi 100 objek 100 MB menurunkan request count 10.000x.
S3 Select / S3 Object Lambda: kueri sebagian objek dengan SQL alih-alih mengunduh seluruhnya. Sangat efektif untuk file CSV/JSON besar.
Caching dengan CloudFront: request berulang ke objek statis dilayani dari edge cache, menghilangkan biaya GET dan egress S3.

Untuk data transfer keluar, biaya $0,09 per GB ke internet adalah komponen paling mahal dalam ekosistem AWS. Selalu gunakan S3 Gateway Endpoint (gratis) untuk lalu lintas dari VPC ke S3 di region yang sama. Tanpa endpoint ini, traffic Anda dirutekan melalui NAT Gateway yang menambah biaya $0,045/GB. Diskusi mendalam mengenai pola hemat lainnya bisa Anda temukan di perbandingan AWS Savings Plans vs Reserved Instances 2026.

Dampak Versioning dan Replication terhadap Biaya

S3 Versioning sangat berguna untuk perlindungan dari penghapusan tidak sengaja dan ransomware, tapi setiap versi objek ditagih terpisah. Saya pernah menemukan bucket dokumen 800 GB di mana 60% biayanya berasal dari noncurrent versions yang berusia lebih dari dua tahun. Solusinya, buat lifecycle rule khusus untuk versi non-current:

{
  "Rules": [{
    "ID": "expire-old-versions",
    "Status": "Enabled",
    "Filter": {},
    "NoncurrentVersionTransitions": [
      { "NoncurrentDays": 30, "StorageClass": "GLACIER_IR" }
    ],
    "NoncurrentVersionExpiration": { "NoncurrentDays": 365 }
  }]
}

Untuk Cross-Region Replication (CRR) dan Same-Region Replication (SRR), Anda membayar tiga kali: storage di region tujuan, biaya replication PUT, dan biaya data transfer antar-region (untuk CRR). Pertimbangkan apakah Anda benar-benar butuh replikasi real-time, atau cukup snapshot harian dengan AWS Backup yang lebih murah. Untuk requirement compliance yang fleksibel, replikasi ke Glacier Deep Archive di region tujuan dapat menghemat hingga 95% dari biaya CRR ke Standard.

Checklist FinOps S3 Bulanan

Berikut workflow bulanan yang saya rekomendasikan untuk tim FinOps yang baru mulai. Jalankan rutinitas ini setiap awal bulan dan dokumentasikan delta-nya di sprint review:

Tarik laporan Cost Explorer untuk S3, group by Usage Type dan Bucket Tag. Tandai bucket dengan kenaikan biaya >15% MoM.
Buka S3 Storage Lens dashboard dan periksa metrik Incomplete Multipart Upload, Noncurrent Version, dan Storage Class Distribution.
Audit bucket TOP 10 termahal: pastikan masing-masing memiliki lifecycle policy aktif dan tag cost-center serta owner.
Verifikasi semua VPC yang mengakses S3 memiliki Gateway Endpoint terdaftar. Cek dengan aws ec2 describe-vpc-endpoints.
Review aturan CloudFront caching untuk bucket yang melayani objek publik. Pastikan TTL minimal 1 jam untuk asset statis.
Update inventory storage class dengan AWS S3 Inventory report (CSV/Parquet harian), masukkan ke Athena untuk analisis lebih dalam.

Pertanyaan yang Sering Diajukan

Berapa potensi penghematan dari S3 Intelligent-Tiering?

Untuk bucket dengan pola akses campuran, Intelligent-Tiering biasanya menghemat 30–68% dibanding S3 Standard murni. Penghematan terbesar terjadi pada objek yang lebih besar dari 128 KB dan tidak diakses selama lebih dari 90 hari, di mana AWS otomatis memindahkannya ke Archive Instant Access dengan harga $0,005/GB/bulan.

Apakah lifecycle policy bisa diubah atau dibatalkan setelah berjalan?

Ya, Anda bisa mengubah atau menghapus lifecycle policy kapan saja melalui konsol atau API. Namun transisi yang sudah terjadi tidak otomatis reversibel. Mengembalikan objek dari Glacier ke Standard memerlukan operasi restore yang berbiaya retrieval dan minimum durasi billable 90/180 hari sesuai tier.

Kapan sebaiknya menggunakan Glacier Deep Archive vs Glacier Flexible Retrieval?

Gunakan Deep Archive ($0,00099/GB) untuk data yang diakses kurang dari sekali per tahun dan tahan menunggu restore 12 jam, misalnya arsip compliance atau backup jangka panjang. Pilih Flexible Retrieval ($0,0042/GB) jika Anda butuh restore dalam menit hingga 5 jam untuk skenario audit atau forensik.

Apakah S3 Storage Lens versi gratis cukup untuk audit?

Untuk akun dengan kurang dari 100 bucket dan kebutuhan audit bulanan, dashboard gratis cukup memadai. Versi advanced ($0,20 per juta objek) hanya worth it kalau Anda butuh prefix-level analytics, rekomendasi otomatis Cost Optimization, atau retensi 15 bulan untuk audit compliance.

Bagaimana cara menghapus incomplete multipart upload yang sudah ada?

Jalankan aws s3api list-multipart-uploads --bucket NAMA untuk melihat daftarnya, lalu abort masing-masing dengan aws s3api abort-multipart-upload --bucket NAMA --key OBJECT_KEY --upload-id UPLOAD_ID. Setelah itu, pasang lifecycle rule AbortIncompleteMultipartUpload dengan DaysAfterInitiation: 7 agar kasus serupa tidak terulang.