Serverless Maliyet Optimizasyonu 11 dk okuma

Serverless Maliyet Optimizasyonu: AWS Lambda ve Azure Functions Maliyetlerini Düşürme Rehberi

AWS Lambda ve Azure Functions serverless faturanızı %20-40 oranında düşürmenin yolları. Bellek right-sizing, ARM/Graviton2 geçişi, cold start optimizasyonu ve 2025 INIT fazı faturalandırma değişikliğine karşı pratik stratejiler ve kod örnekleri.

Editorial Team

Serverless Faturanız Neden Beklediğinizden Yüksek Geliyor?

Serverless mimariye geçtiğinizde size şu söylendi: "Yalnızca kullandığın kadar öde, sunucu yönetimi yok, ölçeklendirme otomatik." Kulağa harika geliyordu, değil mi? Ama birkaç ay sonra AWS veya Azure faturanıza baktığınızda bir şok yaşadıysanız — inanın, yalnız değilsiniz. Bunu yaşamamış serverless kullanıcısı tanımıyorum açıkçası.

2026 verilerine göre kuruluşların %30-50'si serverless harcamalarını gereğinden fazla yapıyor. Yanlış bellek yapılandırması, gereksiz çağrılar, gizli veri aktarım maliyetleri ve Ağustos 2025'te gelen INIT fazı faturalandırma değişikliği — bunların hepsi faturanızı sessizce şişiriyor. Yani sorun serverless'ın kendisinde değil, nasıl kullandığımızda.

Bu rehberde, AWS Lambda ve Azure Functions maliyetlerini somut adımlarla nasıl düşüreceğinizi göstereceğiz. Bellek right-sizing'den ARM mimarisine geçişe, cold start optimizasyonundan gereksiz çağrıları ortadan kaldırmaya kadar pratik kod örnekleriyle ilerleyeceğiz. Hedefimiz net: serverless faturanızı %20-40 oranında azaltmak.

AWS Lambda ve Azure Functions: Fiyatlandırma Modelleri Nasıl Çalışıyor?

AWS Lambda Fiyatlandırma Matematiği

Gelin bir bakalım Lambda'nın fiyatlandırması nasıl çalışıyor. Temelde üç bileşenden oluşuyor:

  • İstek ücretleri: Her 1 milyon istek için 0,20 dolar. Burası genelde faturanın küçük kısmı.
  • İşlem süresi (GB-saniye): Tahsis edilen bellek (GB) x çalışma süresi (saniye). Asıl canavarın yaşadığı yer burası.
  • Veri aktarım maliyetleri: Bölgeler arası veri transferi ve internet çıkış trafiği için ek ücretler. Çoğu kişi bunu hesaba katmayı unutuyor.

Ücretsiz katman aylık 1 milyon istek ve 400.000 GB-saniye sunuyor. Ama dikkat edin, burada bir tuzak var: 1.024 MB bellekle yapılandırılmış bir fonksiyon, her 500 ms'lik çağrıda 0,5 GB-saniye tüketir. Bu durumda ücretsiz kotanız 1 milyon değil, 800.000 çağrıda biter. Orta düzey trafikli bir API, bu limiti 24 saat içinde aşabilir.

Kritik bir detay daha var ki bunu ilk öğrendiğimde epey şaşırmıştım: bellek tahsisi yalnızca RAM'i değil, CPU gücünü de doğrudan etkiliyor. 1.769 MB'de bir fonksiyon tam 1 vCPU alır. 2.048 MB'lik bir fonksiyon, 1.024 MB'lik olana göre iki kat hızlı çalışır ama saniye başına dört kat daha pahalıdır. Yani bellek artırmak her zaman "daha iyi" demek değil.

Azure Functions Fiyatlandırma Seçenekleri

Azure Functions tarafında üç farklı plan var:

  • Consumption Plan (Tüketim Planı): AWS Lambda'ya benzer kullandıkça öde modeli. Aylık 1 milyon istek ve 400.000 GB-saniye ücretsiz. Milisaniye düzeyinde faturalandırma sayesinde kısa süreli fonksiyonlarda AWS'den daha avantajlı olabilir.
  • Premium Plan: Önceden ısıtılmış (pre-warmed) instance'lar sunar. Cold start'ı tamamen ortadan kaldırır ama sabit bir taban maliyet oluşturur — bunu göze almak lazım.
  • Dedicated (App Service) Plan: Sabit kapasiteli VM'ler üzerinde çalışır. Sürekli yüksek yüklü uygulamalar için uygundur.

Önemli bir fark: Azure Functions Consumption Plan'da 20 dakikalık hareketsizlikten sonra cold start yaşanır ve bu süreler onlarca saniyeye çıkabilir — özellikle .NET uygulamalarında. Bunu production'da ilk yaşadığınızda hoş bir sürpriz olmuyor, söyleyeyim.

2025'in Büyük Değişikliği: INIT Fazı Artık Faturalandırılıyor

Şimdi burada duralım bir saniye, çünkü bu konu gerçekten önemli.

Ağustos 2025'te AWS, serverless maliyetlerini temelden değiştiren bir güncelleme yaptı: ZIP paketi kullanan ve yönetilen runtime'larla çalışan Lambda fonksiyonlarının INIT (başlatma) fazı artık faturalandırılıyor.

Daha önce ne oluyordu? Lambda fonksiyonu cold start yaşadığında INIT fazında kütüphaneler yüklenir, veritabanı bağlantıları kurulur ve bağımlılıklar hazırlanırdı — ve bu süre faturalandırılmıyordu. Aslında bir nevi "bedava" başlatma süresi alıyorduk. Şimdi ise bu süre doğrudan Billed Duration'a dahil ediliyor.

Maliyet Etkisi Ne Kadar?

Rakamlar açıkçası çarpıcı: değişiklik öncesi cold start maliyeti milyon çağrı başına yaklaşık 0,80 dolar iken, değişiklik sonrası 17,80 dolara yükseldi — 22 kat artış. Evet, yanlış okumadınız.

512 MB bellekli bir fonksiyon için milyon cold start başına ek maliyetler:

  • Python 3.12: +2,08 dolar
  • Node.js 20: +2,50 dolar
  • Java 17 (SnapStart olmadan): +16,67 dolar (Java'cılar burada acı çekiyor)

Java ve C# uygulamalarında, ağır başlatma mantığı nedeniyle Lambda maliyetleri %10-50 oranında artış gösterebilir. AWS, çoğu kullanıcının toplam faturasında minimal etki göreceğini söylese de, düşük trafikli veya bursty (ani yoğunluklu) iş yükleri için durum pek öyle değil. Ekibinizde bunu deneyimlemiş biriyseniz bilirsiniz, bu tarz yükler en sert darbeyi alıyor.

INIT Fazı Maliyetini Nasıl Kontrol Altına Alırsınız?

Önce mevcut durumu görmemiz lazım. Aşağıdaki CloudWatch metriği ile INIT sürelerinizi izleyerek başlayın:

# Lambda fonksiyonlarınızın INIT sürelerini izleme
aws cloudwatch get-metric-statistics \
  --namespace AWS/Lambda \
  --metric-name InitDuration \
  --dimensions Name=FunctionName,Value=my-function \
  --start-time 2026-02-01T00:00:00Z \
  --end-time 2026-03-01T00:00:00Z \
  --period 86400 \
  --statistics Average Maximum \
  --output table

INIT süreniz 1 saniyeyi aşıyorsa, harekete geçme zamanı gelmiş demektir:

  1. Lambda SnapStart kullanın: Java fonksiyonlarında başlatılmış ortamın anlık görüntüsünü alarak cold start'ı neredeyse sıfıra indirir. Ciddi fark yaratıyor.
  2. Bağımlılıkları minimuma indirin: Gereksiz kütüphaneleri kaldırın. Her ek bağımlılık INIT süresini uzatır — mesela kullanmadığınız bir SDK modülü bile saniyeler ekleyebilir.
  3. Lazy initialization uygulayın: Veritabanı bağlantıları gibi kaynakları INIT'te değil, ilk kullanımda başlatın.

Bellek Right-Sizing: Lambda Power Tuning ile Adım Adım Optimizasyon

Serverless maliyet optimizasyonunun en etkili yöntemi bellek right-sizing'dır. Sorun şu ki (ve bence hepimiz bunu yapıyoruz): çoğu geliştirici bir bellek değeri seçip onu asla değiştirmiyor. 512 MB güzel bir sayı gibi görünüyor, atıyoruz oraya, hayat devam ediyor. Halbuki doğru bellek ayarı, maliyeti düşürürken aynı anda performansı da artırabiliyor.

AWS Lambda Power Tuning, açık kaynaklı bir araç olup AWS Step Functions ile çalışarak fonksiyonlarınızı farklı bellek yapılandırmalarında test eder ve maliyet-performans dengesinin en iyi noktasını bulur.

Adım 1: Aracı Dağıtın

En kolay yol AWS Serverless Application Repository üzerinden dağıtım:

# AWS SAM ile Lambda Power Tuning dağıtımı
sam deploy \
  --template-uri https://raw.githubusercontent.com/alexcasalboni/aws-lambda-power-tuning/master/template.yml \
  --stack-name lambda-power-tuning \
  --capabilities CAPABILITY_IAM \
  --region eu-west-1

Terraform kullanıyorsanız bu da bir seçenek:

# Terraform ile dağıtım
module "lambda_power_tuning" {
  source  = "andybkay/lambda-power-tuning/aws"
  version = "~> 4.0"
}

output "state_machine_arn" {
  value = module.lambda_power_tuning.state_machine_arn
}

Adım 2: Benchmark Testini Çalıştırın

Step Functions konsolunda oluşturulan state machine'i bulun ve şu JSON girişiyle çalıştırın:

{
  "lambdaARN": "arn:aws:lambda:eu-west-1:123456789:function:my-api-handler",
  "powerValues": [128, 256, 512, 1024, 1536, 2048, 3008],
  "num": 50,
  "payload": {
    "httpMethod": "GET",
    "path": "/api/users"
  },
  "parallelInvocation": true,
  "strategy": "balanced",
  "balancedWeight": 0.5
}

Parametreleri kısaca açıklayayım:

  • powerValues: Test edilecek bellek boyutları (MB). 128'den 10.240'a kadar seçebilirsiniz.
  • num: Her yapılandırma için çalıştırılacak test sayısı. En az 50 önerilir, daha az olursa sonuçlar güvenilir olmayabiliyor.
  • strategy: cost (en ucuz), speed (en hızlı) veya balanced (dengeli).
  • balancedWeight: 0 = maliyet odaklı, 1 = performans odaklı. 0.5 iyi bir başlangıç noktası.

Adım 3: Sonuçları Analiz Edin ve Uygulayın

Test tamamlandığında, çıktıda önerilen bellek değeri, ortalama gecikme süresi, çağrı başına maliyet ve interaktif bir grafik URL'si bulacaksınız. Bir gerçek dünya örneği vereyim:

  • 700 MB: 3.097 ms süre, çağrı başına 0,000036 dolar
  • 1.000 MB: 2.135 ms süre, çağrı başına 0,000035 dolar
  • 1.500 MB: 1.422 ms süre, çağrı başına 0,000035 dolar
  • 2.000 MB: 1.420 ms süre, çağrı başına 0,000047 dolar (plato noktası)

Bu örnekte 1.500 MB en verimli nokta. Süre %54 düşerken maliyet neredeyse aynı kalıyor. 2.000 MB'den sonra ise süre düşmüyor ama maliyet artıyor — yani daha fazla para veriyorsunuz ama karşılığında bir şey almıyorsunuz. Tam burayı yakalamak önemli.

Otomatik uygulama için JSON girişine şunu ekleyin:

{
  "autoOptimize": true,
  "autoOptimizeAlias": "prod"
}

Bu ayar, test sonucunda bulunan en iyi bellek değerini otomatik olarak uygular ve prod alias'ına atar. Ama production'da bunu ilk kez yapıyorsanız önce staging'de deneyin derim.

ARM/Graviton2 Mimarisine Geçiş: Anında %20 Tasarruf

AWS Lambda'da x86'dan ARM (Graviton2) mimarisine geçmek, muhtemelen yapabileceğiniz en kolay ve en hızlı maliyet optimizasyonudur. Tek bir yapılandırma değişikliğiyle %20 maliyet düşüşü elde ediyorsunuz — ve çoğu durumda performans da artıyor. Bunu ilk denediğimizde "bu kadar basit olamaz" demiştik, ama gerçekten bu kadar basit.

Geçiş Nasıl Yapılır?

# AWS CLI ile mevcut fonksiyonu ARM mimarisine geçirme
aws lambda update-function-configuration \
  --function-name my-api-handler \
  --architectures arm64

# Terraform ile yeni fonksiyon tanımlama
resource "aws_lambda_function" "api_handler" {
  function_name = "my-api-handler"
  runtime       = "python3.12"
  handler       = "main.handler"
  architectures = ["arm64"]
  memory_size   = 1536
  timeout       = 30

  filename         = "deployment.zip"
  source_code_hash = filebase64sha256("deployment.zip")
  role             = aws_iam_role.lambda_role.arn
}

Python, Node.js, Java, .NET, Ruby ve özel runtime'lar ARM'ı destekliyor. Çoğu uygulama sıfır kod değişikliği ile geçiş yapabiliyor. Ama birkaç şeye dikkat etmeniz lazım:

  • Native binary bağımlılıkları olan paketler (mesela C extension kullanan Python kütüphaneleri) ARM için yeniden derlenmelidir.
  • Docker container tabanlı Lambda fonksiyonlarında base image'ın ARM uyumlu olduğundan emin olun.
  • Geçiş öncesi mutlaka test ortamında doğrulama yapın. Ciddiyim, bunu atlamamanız lazım.

Cold Start Maliyetlerini Azaltmanın 4 Yolu

INIT fazı faturalandırması sonrası cold start artık yalnızca bir performans sorunu değil, doğrudan bir maliyet sorunu. İşte cold start maliyetlerinizi minimize etmenin yolları:

1. Lambda SnapStart (Java İçin)

Lambda SnapStart, Java fonksiyonlarında başlatılmış ortamın anlık görüntüsünü alarak sonraki cold start'larda bu görüntüden başlatma yapar. Cold start süresini saniyelerden milisaniyelere düşürür. Java kullanan bir ekipseniz buna mutlaka bakmanız lazım.

# SAM template ile SnapStart etkinleştirme
Resources:
  MyFunction:
    Type: AWS::Serverless::Function
    Properties:
      Handler: com.example.Handler::handleRequest
      Runtime: java21
      SnapStart:
        ApplyOn: PublishedVersions
      AutoPublishAlias: live
      MemorySize: 1024
      Timeout: 30

2. Provisioned Concurrency (Seçici Kullanım)

Provisioned Concurrency, fonksiyonlarınızı sürekli sıcak tutar ve cold start'ı tamamen ortadan kaldırır.

Ama dikkat: maliyeti yüksektir. Hadi bir hesap yapalım. 50 fonksiyon x 5 provisioned instance = yıllık yaklaşık 19.000 dolar. Aynı senaryoda INIT faturalandırmasını kabul etmek ise yalnızca 600 dolar. Aradaki fark devasa.

Provisioned Concurrency'yi yalnızca şu durumlarda kullanın:

  • Gecikmeye duyarlı, kullanıcı odaklı API'ler
  • Kullanım oranı sürekli %60'ın üzerinde olan fonksiyonlar
  • SLA gereksinimleri nedeniyle cold start kabul edilemez olan senaryolar

Bunların dışında, açıkçası parasına değmiyor.

3. Paket Boyutunu Küçültün

Daha küçük dağıtım paketi = daha kısa INIT süresi = daha düşük maliyet. Basit bir denklem aslında. Python'da şu yaklaşımı kullanabilirsiniz:

# Gereksiz dosyaları temizleyerek paket boyutunu küçültme
pip install -r requirements.txt -t ./package --no-cache-dir

# Test dosyalarını, dokümantasyonu ve gereksiz bileşenleri kaldırın
cd package
find . -type d -name "__pycache__" -exec rm -rf {} + 2>/dev/null
find . -type d -name "tests" -exec rm -rf {} + 2>/dev/null
find . -type d -name "*.dist-info" -exec rm -rf {} + 2>/dev/null
find . -name "*.pyc" -delete 2>/dev/null

# Sadece ihtiyacınız olan modülleri dahil edin
zip -r9 ../deployment.zip . -x "boto3/*" -x "botocore/*"
cd .. && zip -g deployment.zip main.py

İpucu: boto3 ve botocore Lambda runtime'ında zaten mevcut olduğundan pakete dahil etmeyin. Bu tek hamle paket boyutunu 50 MB+ azaltabilir. Bunu bilmeyip pakete dahil eden o kadar çok proje gördüm ki...

4. Azure Functions'da Premium Plan Stratejisi

Azure Functions Consumption Plan'da 20 dakikalık hareketsizlikten sonra cold start kaçınılmaz. Kritik fonksiyonlar için Premium Plan'a geçerek önceden ısıtılmış instance'lar kullanabilirsiniz:

// Azure Bicep ile Premium Plan tanımlama
resource hostingPlan 'Microsoft.Web/serverfarms@2023-12-01' = {
  name: 'my-premium-plan'
  location: resourceGroup().location
  sku: {
    name: 'EP1'
    tier: 'ElasticPremium'
  }
  properties: {
    maximumElasticWorkerCount: 10
    reserved: true
  }
}

resource functionApp 'Microsoft.Web/sites@2023-12-01' = {
  name: 'my-critical-function'
  location: resourceGroup().location
  kind: 'functionapp,linux'
  properties: {
    serverFarmId: hostingPlan.id
    siteConfig: {
      appSettings: [
        {
          name: 'FUNCTIONS_WORKER_RUNTIME'
          value: 'python'
        }
        {
          name: 'WEBSITE_MAX_DYNAMIC_APPLICATION_SCALE_OUT'
          value: '10'
        }
      ]
      linuxFxVersion: 'Python|3.11'
    }
  }
}

Gereksiz Çağrıları Ortadan Kaldırma

En ucuz Lambda çağrısı, hiç yapılmayan çağrıdır. Kulağa basit geliyor ama ciddiyim. Birçok senaryoda Lambda fonksiyonuna gerek bile yok:

  • API Gateway → DynamoDB: API Gateway'in VTL (Velocity Template Language) entegrasyonu ile basit CRUD işlemlerini Lambda olmadan yapabilirsiniz. Arada Lambda'ya gerek yok, direkt bağlayın.
  • EventBridge Pipes: SQS → DynamoDB gibi aktarımlarda aradaki Lambda'yı ortadan kaldırır.
  • Step Functions: Bekleme gerektiren iş akışlarında Lambda'yı boşta tutmak yerine Step Functions kullanın — bekleme süresi için ödeme yapmazsınız.

Ayrıca olay kaynağı filtreleme ile gereksiz tetiklenmeleri engelleyin. Bu kısım özellikle önemli:

# S3 olay filtreleme ile yalnızca belirli dosyaları işleme
Resources:
  ProcessUploads:
    Type: AWS::Serverless::Function
    Properties:
      Handler: processor.handler
      Runtime: python3.12
      Architectures: [arm64]
      Events:
        S3Upload:
          Type: S3
          Properties:
            Bucket: !Ref UploadBucket
            Events: s3:ObjectCreated:*
            Filter:
              S3Key:
                Rules:
                  - Name: prefix
                    Value: uploads/
                  - Name: suffix
                    Value: .csv

Bu yapılandırma ile fonksiyon yalnızca uploads/ klasörüne yüklenen .csv dosyaları için tetiklenir. Gereksiz çağrıları filtrelemek, özellikle yoğun S3 bucket'larında binlerce dolar tasarruf sağlayabiliyor. Bunu uygulamayan bir projede her thumbnail upload'unda bile ana işlem fonksiyonunun tetiklendiğini görmüştüm — fatura korkunçtu.

Maliyet İzleme ve Uyarı Sistemi Kurma

Optimizasyon tek seferlik bir iş değil. Bu noktayı gerçekten vurgulamak istiyorum. Fonksiyonlarınız sürekli değişir, trafik desenleri dalgalanır. Bu nedenle sürekli izleme şart.

AWS Cost Explorer ile Fonksiyon Bazlı Analiz

Lambda maliyetlerinizi fonksiyon bazında analiz etmek için etiketleme (tagging) kullanın. Etiket koymadığınız fonksiyonların maliyetini izlemek neredeyse imkansızdır, o yüzden bunu ilk günden yapın:

# Lambda fonksiyonlarınıza maliyet etiketleri ekleyin
aws lambda tag-resource \
  --resource arn:aws:lambda:eu-west-1:123456789:function:my-api-handler \
  --tags '{"cost-center":"backend","project":"user-api","environment":"production"}'

# AWS Cost Explorer API ile belirli bir etiketin maliyetini sorgulayın
aws ce get-cost-and-usage \
  --time-period Start=2026-02-01,End=2026-03-01 \
  --granularity MONTHLY \
  --metrics "UnblendedCost" \
  --filter '{
    "Tags": {
      "Key": "project",
      "Values": ["user-api"]
    }
  }' \
  --group-by Type=DIMENSION,Key=SERVICE

Bütçe Alarmı Oluşturma

Beklenmedik maliyet artışlarını yakalamak için CloudWatch alarm kurun. Bu adımı atlayan ekiplerin başına neler geldiğini anlatmama gerek yok sanırım:

# Aylık Lambda bütçesi aşıldığında uyarı
Resources:
  LambdaBudget:
    Type: AWS::Budgets::Budget
    Properties:
      Budget:
        BudgetName: lambda-monthly-budget
        BudgetLimit:
          Amount: 500
          Unit: USD
        TimeUnit: MONTHLY
        BudgetType: COST
        CostFilters:
          Service:
            - AWS Lambda
      NotificationsWithSubscribers:
        - Notification:
            NotificationType: ACTUAL
            ComparisonOperator: GREATER_THAN
            Threshold: 80
          Subscribers:
            - SubscriptionType: EMAIL
              Address: [email protected]
        - Notification:
            NotificationType: FORECASTED
            ComparisonOperator: GREATER_THAN
            Threshold: 100
          Subscribers:
            - SubscriptionType: EMAIL
              Address: [email protected]

Bu yapılandırma iki durumda bildirim gönderir: Lambda harcamanız bütçenin %80'ine ulaştığında ve tahmini harcama bütçeyi aşacağında. İkinci kısım özellikle değerli çünkü ay sonunu beklemeden müdahale şansı veriyor.

Sıkça Sorulan Sorular (FAQ)

AWS Lambda mı yoksa Azure Functions mı daha ucuz?

Bu soruyu çok alıyorum ve dürüst cevap: duruma göre değişir. İkisinin de temel fiyatlandırması benzer (kullandıkça öde, 1 milyon ücretsiz istek/ay). Azure Functions milisaniye düzeyinde faturalandırma sunarken, AWS Lambda da 2024'ten beri milisaniye bazlı faturalandırmaya geçti. Asıl fark, kullandığınız ek hizmetlerde ve operasyonel disiplinde ortaya çıkıyor. Hangi sağlayıcıyı seçtiğinizden çok, fonksiyonlarınızı ne kadar iyi optimize ettiğiniz önemli aslında.

Lambda bellek ayarını nasıl optimize ederim?

AWS Lambda Power Tuning aracını kullanarak fonksiyonlarınızı farklı bellek boyutlarında (128 MB'den 10 GB'a kadar) test edin. Araç, maliyet ve performans arasındaki en iyi dengeyi gösteren interaktif bir grafik üretir. Ayrıca AWS Compute Optimizer da geçmiş kullanım verilerine dayalı otomatik bellek önerileri sunuyor. En az çeyrekte bir bellek ayarlarınızı gözden geçirmenizi öneririm — trafik desenleri değişiyor, optimum nokta da değişebilir.

Serverless cold start maliyeti 2025'ten sonra ne kadar arttı?

Ağustos 2025'te AWS, ZIP paketli ve yönetilen runtime kullanan Lambda fonksiyonlarının INIT fazını faturalandırmaya başladı. Bu değişiklik, cold start başına maliyeti yaklaşık 22 kat artırdı (0,80 dolardan 17,80 dolara/milyon cold start). Java ve C# uygulamaları en çok etkilenen diller olup, toplam Lambda maliyetlerinde %10-50 artış gözlemlenebilir. Lambda SnapStart, paket boyutu küçültme ve seçici Provisioned Concurrency kullanarak bu etkiyi minimize edebilirsiniz.

Serverless'tan ne zaman vazgeçip container'a geçmeliyim?

Lambda, kısa süreli (15 dakikaya kadar) ve olay odaklı iş yükleri için ideal. Ama sürekli yüksek trafikli, uzun süreli işlem gerektiren veya her saniye düzinelerce eşzamanlı istek alan uygulamalarda container (ECS/Fargate veya Kubernetes) daha maliyet-etkin olabiliyor. Genel kural olarak: Lambda fonksiyonunuz günde milyonlarca çağrı alıyorsa ve ortalama çalışma süresi 1 saniyeyi aşıyorsa, bir container tabanlı çözümle maliyet karşılaştırması yapmanız faydalı olacaktır. Yani serverless her derde deva değil — doğru iş yükü için doğru araç her zaman en iyi stratejidir.

Serverless maliyetlerimi izlemek için hangi araçları kullanmalıyım?

AWS tarafında AWS Cost Explorer, CloudWatch ve AWS Compute Optimizer yerleşik araçlar ve başlangıç için gayet yeterli. Azure tarafında Azure Cost Management + Billing kullanabilirsiniz. Daha detaylı görünürlük istiyorsanız, üçüncü parti araçlardan Dashbird, Lumigo ve Datadog Serverless Monitoring fonksiyon düzeyinde maliyet analizi sunuyor. Ama hangi aracı kullanırsanız kullanın, en önemlisi tüm fonksiyonlarınıza proje, ortam ve maliyet merkezi etiketleri eklemek. Etiketsiz fonksiyon = görünmez maliyet.

Yazar Hakkında Editorial Team

Our team of expert writers and editors.