Optimasi Biaya AWS Lambda 2026: Memory Tuning, Graviton ARM64 & SnapStart

Diperbarui: 20 Agustus 2026

Optimasi biaya AWS Lambda pada 2026 bertumpu pada empat pengungkit utama: memory right-sizing dengan Lambda Power Tuning, migrasi arsitektur ke ARM64 (Graviton2) untuk diskon 20%, penggunaan SnapStart pada runtime Java/Python/.NET untuk memangkas cold start, dan pemilihan Provisioned Concurrency yang tepat sasaran (bukan pukul rata). Jujur saja, saya sudah menerapkan pola ini di lebih dari dua lusin akun AWS, dan kombinasi keempatnya konsisten memangkas tagihan Lambda 30–45% tanpa menyentuh kode bisnis. Panduan ini merangkum angka SKU terbaru, kalkulasi break-even, dan rekomendasi Compute Optimizer.

• Memory adalah dial utama biaya Lambda: CPU, network, dan bandwidth berskala linear terhadap memory yang dialokasikan, jadi konfigurasi 128 MB belum tentu paling murah.
• ARM64 Graviton2 memberi diskon 20% pada harga per GB-second dan tambahan 19% peningkatan performa/watt dibanding x86, cukup dengan perubahan 2 baris konfigurasi.
• SnapStart menghilangkan biaya cold start 3–10 detik untuk Java, Python, dan .NET, kini tersedia gratis untuk Python & .NET (Java tetap $0.0000015036 per GB-second snapshot).
• Provisioned Concurrency baru menguntungkan jika utilisasi >60% per jam; di bawahnya lebih murah pakai on-demand.
• Compute Optimizer merekomendasikan konfigurasi memory optimal berbasis 14 hari data CloudWatch, aktifkan gratis di semua akun via AWS Organizations.
• Compute Savings Plans mencakup Lambda dengan diskon hingga 17% untuk komitmen 1 tahun No Upfront.

Anatomi biaya AWS Lambda 2026

Sebelum menekan tagihan, pahami dulu SKU-nya. AWS Lambda mengenakan tiga komponen biaya utama pada 2026, dan hampir semua overspend bermula dari salah memahami hubungan antara memory, durasi, dan arsitektur CPU.

• Request charges: $0.20 per 1 juta request untuk x86 dan ARM64. Ini flat dan sulit dihindari, jadi fokus optimasi ada di komponen kedua.
• Duration charges (GB-second): $0.0000166667 per GB-detik pada x86, $0.0000133334 per GB-detik pada ARM64. Perbedaan 20% inilah alasan utama migrasi Graviton.
• Ephemeral storage: gratis hingga 512 MB, lalu $0.0000000309 per GB-detik di atas itu. Hindari alokasi di atas 1024 MB kecuali beban kerja Anda benar-benar butuh scratch space besar.

Kunci yang sering terlewat: memory adalah pengganda linear untuk CPU dan network. Fungsi 1024 MB mendapat sekitar 1 vCPU penuh, 1769 MB mendapat 1 vCPU utuh yang setara compute per unit, dan 10240 MB mendapat 6 vCPU. Jadi menggandakan memory tidak selalu menggandakan biaya. Sering kali durasi terpotong lebih dari 50% karena CPU-bound workload jadi selesai lebih cepat. Ini sebabnya memory tuning menjadi pengungkit optimasi biaya nomor satu, bahkan sebelum arsitektur.

Untuk gambaran menyeluruh soal pilar FinOps di luar Lambda, silakan cek 12 strategi optimasi biaya cloud 2026 yang saya susun sebelumnya. Lambda memang pengecualian menarik karena unit ekonominya berbasis waktu, bukan instance-hour.

Bagaimana cara mengurangi biaya AWS Lambda dengan memory tuning?

Cara paling cepat menurunkan biaya Lambda tanpa refactor adalah menjalankan setiap fungsi lewat AWS Lambda Power Tuning, sebuah state machine open-source yang menjalankan fungsi Anda pada beberapa nilai memory berbeda dan memplot titik "biaya minimum" versus "waktu minimum". Menurut pengalaman saya, sekitar 60% fungsi produksi yang di-default 128 MB oleh developer sebenarnya lebih murah pada 512 MB atau 1024 MB.

Alurnya sederhana. Deploy state machine Power Tuning di akun Anda (satu klik dari Serverless Application Repository), lalu jalankan input JSON berikut untuk fungsi target:

{
  "lambdaARN": "arn:aws:lambda:us-east-1:123456789012:function:process-order",
  "powerValues": [128, 256, 512, 1024, 1536, 1769, 3008],
  "num": 50,
  "payload": { "orderId": "sample-123" },
  "parallelInvocation": true,
  "strategy": "cost"
}

State machine akan mengeksekusi 50 invocation paralel pada tujuh konfigurasi memory dan mengembalikan grafik biaya-versus-durasi. Untuk fungsi CPU-bound (parsing, kompresi, hashing), hasilnya sering mengejutkan: 1769 MB (1 vCPU penuh) hampir selalu lebih murah dibanding 512 MB karena durasi anjlok 4x lipat. Untuk I/O-bound (menunggu DynamoDB atau HTTP downstream), memory besar hanya buang-buang karena Lambda tidur menunggu response.

Rule of thumb yang saya pakai di lapangan

• CPU-bound / kompresi / kripto: 1769 MB atau 3008 MB, hampir selalu lebih murah dari 512 MB.
• I/O-bound (menunggu DB/HTTP): 512–1024 MB. Di atas itu biaya naik tanpa manfaat.
• Cold-start-sensitive (API Gateway sinkron): minimum 1024 MB agar init lebih cepat, lalu evaluasi SnapStart.
• Batch processing (SQS/Kinesis): maksimalkan memory + batchSize tinggi untuk amortisasi cold start.

Apakah Lambda ARM64 Graviton2 benar-benar lebih murah?

Ya. Migrasi ke arsitektur ARM64 (Graviton2) memberi diskon 20% pada harga durasi dan peningkatan performa/watt sekitar 19%. Kombinasi ini secara efektif menekan biaya total 25–34% untuk sebagian besar workload. Perubahan yang dibutuhkan biasanya hanya satu baris di Infrastructure as Code Anda.

Contoh SAM template:

Resources:
  OrderProcessor:
    Type: AWS::Serverless::Function
    Properties:
      Runtime: nodejs22.x
      Architectures:
        - arm64          # bukan x86_64
      MemorySize: 1024
      Timeout: 30
      Handler: index.handler

Terraform:

resource "aws_lambda_function" "order_processor" {
  function_name = "order-processor"
  runtime       = "nodejs22.x"
  architectures = ["arm64"]
  memory_size   = 1024
  timeout       = 30
  handler       = "index.handler"
  role          = aws_iam_role.lambda_role.arn
  filename      = "function.zip"
}

Kapan Anda tidak boleh migrasi ARM64?

Ada beberapa footgun yang harus dicek sebelum flip switch di production. Saya pernah kena bug sharp di ARM64 saat merilis image processing service, jadi daftar ini benar-benar patut dibaca:

• Dependency native yang di-compile untuk x86 (misalnya sharp, bcrypt, puppeteer-core dengan Chromium x86). Rebuild lewat Docker --platform linux/arm64.
• Lambda Layer publik yang belum tersedia versi ARM64 (semakin jarang di 2026, tapi cek dulu).
• Fungsi yang memakai AWS Compute Optimizer sebagai referensi. Pastikan Anda benchmark ulang, karena recommendation memory berbeda antara arsitektur.
• Extensions komersial (Datadog, New Relic, Sentry). Versi ARM64 kini standar, tapi konfirmasi tag di ARN.

Untuk stack Node.js dan Python murni, migrasi biasanya 15 menit deploy plus 24 jam observasi. Untuk workload Java dengan JIT hotspot yang matang, uji latensi p99 setidaknya satu minggu. Graviton2 mengeksekusi JIT dengan profil berbeda dan kadang butuh -XX:+TieredCompilation tuning.

SnapStart, provisioned concurrency, dan cold start

Cold start dulunya menjadi alasan tim memasang Provisioned Concurrency mahal secara pukul rata. Pada 2026, Lambda SnapStart mengubah kalkulasinya secara fundamental. SnapStart mengambil snapshot dari Firecracker microVM yang sudah selesai init, lalu memakainya untuk seluruh invocation dingin berikutnya, memangkas cold start 3–10 detik pada JVM menjadi <300 ms.

Strategi	Cold start	Biaya tambahan	Cocok untuk
On-demand murni	200 ms – 10 s	Tidak ada	Batch async, event-driven low RPS
SnapStart (Java/Python/.NET)	<300 ms konsisten	Snapshot cache: $0 (Python/.NET), $0.0000015036 GB-s (Java)	API sinkron dengan traffic bursty
Provisioned Concurrency	0 ms	$0.0000041667 per GB-detik terjaga + duration diskon 30%	API dengan traffic konstan tinggi
Lambda@Edge	50–150 ms	$0.60 per 1M request + $0.00005001 per GB-s	Latensi rendah global via CloudFront

Kapan Provisioned Concurrency sebenarnya menghemat?

Break-even matematisnya lugas. Provisioned Concurrency ($0.0000041667 per GB-detik terjaga) sebanding dengan on-demand ketika utilisasi jam >60%. Untuk fungsi 1024 MB:

• Biaya Provisioned Concurrency terjaga per jam: 1 GB × 3600 detik × $0.0000041667 = $0.015
• Biaya on-demand ekuivalen (durasi rata-rata 100 ms, 6.000 request/jam): 6000 × 0.1 × $0.0000133334 = $0.008

Pada volume itu, on-demand ARM64 masih lebih murah. Baru pada >22.500 request/jam per fungsi, Provisioned Concurrency mulai lebih ekonomis. Kesalahan umum: developer memasang ProvisionedConcurrentExecutions: 10 untuk semua fungsi kritis "untuk jaga-jaga". Ini praktis membakar $110+ per fungsi per bulan tanpa manfaat berarti.

# Aktifkan SnapStart via SAM (Python 3.13, Java 21, .NET 8)
Resources:
  CheckoutApi:
    Type: AWS::Serverless::Function
    Properties:
      Runtime: python3.13
      Architectures: [arm64]
      MemorySize: 1024
      SnapStart:
        ApplyOn: PublishedVersions
      AutoPublishAlias: live
      Handler: app.handler

Rekomendasi AWS Compute Optimizer untuk Lambda

AWS Compute Optimizer, gratis di setiap akun, menganalisis 14 hari data CloudWatch dan merekomendasikan konfigurasi memory optimum per fungsi. Buat saya, ini adalah starting line, bukan finish line. Angkanya konservatif, tapi hampir selalu mengidentifikasi over-provisioning ekstrem.

Aktifkan lintas seluruh AWS Organization dalam 5 menit:

aws compute-optimizer update-enrollment-status \
    --status Active \
    --include-member-accounts \
    --region us-east-1

Setelah 14 hari, tarik rekomendasi Lambda:

aws compute-optimizer get-lambda-function-recommendations \
    --account-ids 111122223333 \
    --filters name=Finding,values=NotOptimized \
    --region us-east-1 \
    --query 'lambdaFunctionRecommendations[*].[functionArn,currentMemorySize,memorySizeRecommendationOptions[0].memorySize,memorySizeRecommendationOptions[0].savingsOpportunity.savingsOpportunityPercentage]' \
    --output table

Output akan menampilkan fungsi yang di-tag Over-provisioned atau Under-provisioned. Untuk portofolio >200 fungsi, saya mengalirkan output ke tabel Athena dan menjadikannya bagian dari weekly FinOps review. Dokumentasi lengkap ada di panduan resmi AWS Compute Optimizer untuk Lambda.

Menggabungkan dengan cost allocation tags

Compute Optimizer tidak menampilkan biaya potensial per team; Anda harus menyilangkannya dengan cost allocation tags. Pastikan fungsi Lambda ditandai Team, Environment, dan CostCenter. Untuk pola tagging yang skalabel, saya bahas di strategi tagging AWS 2026, dan pola yang sama berlaku persis untuk resource Lambda.

Compute Savings Plans untuk Lambda

Sedikit tim tahu ini, tetapi Lambda tercakup dalam Compute Savings Plans (bukan EC2-only). Komitmen $/hour selama 1 atau 3 tahun memberi diskon hingga 17% (1 tahun No Upfront) atau 27% (3 tahun All Upfront) pada duration charges. Request charges tidak diskon.

Perhitungannya penting: Savings Plan diterapkan ke Lambda, Fargate, dan EC2 dari satu committed spend. Untuk workload yang campur ketiganya, pakai halaman harga Lambda resmi sebagai baseline, lalu tambahkan Lambda ke rekomendasi Cost Explorer. Ini biasanya menghasilkan angka commit 15–20% lebih tinggi dibanding rekomendasi default yang hanya menganalisis EC2.

Untuk perbedaan mendasar antara Savings Plans dan Reserved Instances, saya sudah menuliskannya panjang lebar di AWS Savings Plans vs Reserved Instances 2026. Kesimpulannya untuk Lambda: Savings Plans hampir selalu menang karena Lambda tidak punya opsi RI.

Observability: cara memantau biaya Lambda per fungsi

Optimasi tanpa observability sama dengan menembak dalam gelap. Tiga sinyal wajib di dashboard Anda:

1. GB-seconds per fungsi per hari. Kalikan dengan harga durasi untuk biaya harian aktual. Tarik dari CloudWatch metric Duration × MemorySize/1024.
2. Invocation efficiency. Persentase durasi yang dihabiskan pada init phase. Nilai >15% mengindikasikan cold start berlebih, jadi kandidat SnapStart.
3. Utilisasi memory maksimum. Via REPORT log Lambda, ekstrak Max Memory Used. Fungsi yang konsisten memakai <40% memory yang di-provision adalah kandidat right-sizing.

CloudWatch Logs Insights query yang saya pakai untuk audit bulanan:

filter @type = "REPORT"
| stats
    avg(@duration) as avg_ms,
    max(@duration) as max_ms,
    avg(@maxMemoryUsed / 1024 / 1024) as avg_memory_mb,
    max(@maxMemoryUsed / 1024 / 1024) as max_memory_mb,
    count(*) as invocations
  by bin(1d)
| sort @timestamp desc

Untuk portfolio besar (>1000 fungsi), tarik metric ini ke CUR (Cost and Usage Report) via AWS Data Exports dan analisis di Athena atau QuickSight. Attribusi per team lewat cost allocation tag menjadikan konversasi FinOps jauh lebih produktif: bukan lagi "kenapa Lambda mahal", tapi "team X boros $2.400/bulan di fungsi Y karena over-provision memory".

Checklist FinOps Lambda 2026

So, mari kita bungkus dengan ringkasan actionable yang saya bagikan ke customer di sesi Well-Architected Framework Review:

1. Aktifkan Compute Optimizer di semua akun via AWS Organizations (5 menit).
2. Tarik daftar fungsi Over-provisioned dan Under-provisioned, prioritaskan >$100/bulan.
3. Jalankan Lambda Power Tuning pada 20 fungsi paling mahal untuk validasi rekomendasi.
4. Migrasi arsitektur ke ARM64 untuk semua fungsi Node.js/Python/Go yang dependency-nya kompatibel.
5. Aktifkan SnapStart pada fungsi Java, Python 3.12+, atau .NET 8 dengan cold start >500 ms yang melayani API sinkron.
6. Audit setiap konfigurasi Provisioned Concurrency, hitung utilisasi jam, hapus yang di bawah 60%.
7. Kurangi ephemeral storage >512 MB kecuali benar-benar dipakai.
8. Tambahkan Lambda ke rekomendasi Compute Savings Plans di Cost Explorer.
9. Pasang cost allocation tag wajib Team, Environment, CostCenter lewat Service Control Policy.
10. Jadwalkan Compute Optimizer review setiap 30 hari sebagai bagian dari FinOps cadence.

Ikuti sepuluh langkah ini pada akun dengan spend Lambda >$10.000/bulan, dan Anda hampir selalu bisa memangkas 30–40% dalam satu quarter, tanpa memaksa developer mengubah kode aplikasi mereka.

Pertanyaan yang sering diajukan

Berapa memory optimal untuk AWS Lambda?

Tidak ada satu angka. Untuk workload CPU-bound (kompresi, kripto, parsing besar), titik optimum biasanya 1769 MB, yaitu ketika Lambda memberi 1 vCPU penuh. Untuk workload I/O-bound (menunggu DB atau HTTP), 512–1024 MB paling ekonomis. Selalu validasi dengan AWS Lambda Power Tuning, jangan menebak.

Apakah Lambda SnapStart mengurangi biaya?

SnapStart tidak menurunkan harga per GB-second, tetapi memangkas init duration cold start Java hingga 90%, sehingga total GB-second yang tercatat lebih rendah. Untuk Python 3.12+ dan .NET 8, SnapStart bahkan gratis pada 2026. Efek bersihnya biasanya penghematan 5–15% pada fungsi cold-start-heavy.

Apakah ARM64 Lambda kompatibel dengan semua runtime?

Ya untuk Node.js 18+, Python 3.9+, Java 11+, Ruby 3.2+, .NET 6+, dan Go. Yang perlu diperhatikan adalah dependency native (misalnya sharp, bcrypt, atau Chromium) yang harus di-rebuild untuk linux/arm64. Lambda Layer publik kini standar tersedia dalam versi ARM64.

Kapan sebaiknya menggunakan Provisioned Concurrency?

Hanya ketika utilisasi jam >60% dan Anda punya API sinkron dengan SLA latensi ketat (misalnya <100 ms p95). Di bawah utilisasi itu, on-demand ARM64 dengan SnapStart hampir selalu lebih murah. Hindari menyalakan Provisioned Concurrency "untuk jaga-jaga", karena ini pemborosan biaya paling umum yang saya temui.

Apakah Compute Savings Plans mencakup AWS Lambda?

Ya. Compute Savings Plans mendiskon biaya durasi Lambda hingga 17% untuk komitmen 1 tahun No Upfront dan hingga 27% untuk 3 tahun All Upfront. Request charges tidak tercakup. Untuk workload campuran Lambda + Fargate + EC2, komitmen tunggal berlaku fleksibel di ketiganya.