GCP Maliyet Optimizasyonu 2026: CUD, Spot VM ve Sustained Use Discount Rehberi
GCP faturanızı %55-80 düşürmek için Committed Use Discounts, Sustained Use Discounts, Spot VM ve right-sizing tekniklerinin 2026 itibarıyla nasıl birlikte uygulanacağını adım adım anlatan FinOps rehberi.
GCP maliyet optimizasyonu, Google Cloud Platform faturanızı düşürmek için Committed Use Discounts (CUD), Sustained Use Discounts (SUD), Spot VM ve doğru boyutlandırma (right-sizing) tekniklerinin birlikte uygulanmasıdır. Çoğu kuruluş bu dört kaldıraçla on-demand fiyata kıyasla %55 ile %80 arasında tasarruf sağlayabilir. Bu rehberde 2026 itibarıyla geçerli olan fiyatlandırma modellerini, Recommender API ile otomatik öneri akışlarını ve BigQuery slot rezervasyonlarını birlikte çalışan bir FinOps disipliniyle ele alıyorum.
Spend-based CUD'lar 2026'da Compute Engine, Cloud Run, GKE Autopilot ve Cloud SQL'i tek bir taahhüt altında birleştirebiliyor. Kaynak-tabanlı CUD'lardan daha esnek, ama indirim oranı düşük (yaklaşık %20–%28).
Spot VM'ler önceki Preemptible VM'lerin yerini aldı ve on-demand fiyata göre %60–%91 indirim sunar. 24 saatlik maksimum yaşam süresi sınırı kaldırıldı.
Sustained Use Discount'lar otomatik uygulanır. N1/N2/N2D ailelerinde aylık kullanımın %25'inden sonra otomatik başlar ve ekstra kontrat gerektirmez.
Recommender API; idle VM, kullanılmayan disk, eski snapshot ve aşırı boyutlandırılmış makine önerilerini tek API'den döndürür ve Cloud Asset Inventory ile birleştirilebilir.
BigQuery için 2023'te tanıtılan editions modeli (Standard, Enterprise, Enterprise Plus) flat-rate slotların yerini aldı. Sorgu yoğunluğunuza göre on-demand ile autoscaling slot arasında matematik yapmak şart.
Network egress maliyetleri çoğu zaman gizli faturanın %15 ile %30'unu oluşturur. Private Service Connect ve Cloud Interconnect ile kontrol altına alınabilir.
GCP fiyatlandırma modeline genel bakış
GCP'nin fiyatlandırma yapısı, AWS ve Azure'a göre belirgin biçimde farklıdır. Ve bu fark tam olarak burada para kazandırır. Üç ana indirim kaldıracı var: kontrat-tabanlı (CUD), kullanım-tabanlı (SUD) ve kesinti-tabanlı (Spot). AWS'de Reserved Instances ve Savings Plans gibi tek bir kontrat ailesine sıkışmazsınız; GCP'nin SUD'u herhangi bir taahhüt olmadan otomatik devreye girer. Bu da GCP'de yapılan en büyük hatalardan birini açıklar: ekipler SUD'un zaten faturalandığını fark etmeden CUD satın alıp aynı kullanım için çift indirim hesabı yapıyor.
Çok hesaplı (multi-account) bir kurulumda, ki ben her zaman folder bazlı organizasyon hiyerarşisini tavsiye ederim, CUD'lar billing account seviyesinde paylaşılır. Yani bir projede satın alınan kontrat, başka bir projede kullanılabilir. AWS Organizations'taki Savings Plans paylaşımına benzer, ama daha geniş kapsamlıdır. Pratik sonuç: kontratlarınızı tek bir billing account altında toplayın ki tüm projeler aynı havuzdan faydalansın.
Resmi fiyat detayları için Compute Engine fiyatlandırma sayfasına bakmanızı tavsiye ederim. Bölgesel fiyat farkları %15'e kadar çıkıyor ve bu tek başına workload taşıma kararını değiştirebilir.
Committed Use Discount nedir ve nasıl çalışır?
Committed Use Discount, 1 veya 3 yıllık kullanım taahhüdü karşılığında %20 ile %70 arası indirim sağlayan GCP kontratıdır. İki türü var ve 2026'da bu ayrımı bilmemek doğrudan para kaybettirir.
Kaynak-tabanlı CUD
Belirli bir makine ailesi, bölge ve sayıda vCPU/RAM için taahhüt verirsiniz. İndirim oranları yüksek (1 yıl için yaklaşık %37, 3 yıl için %55–%70), ama esneklik düşük: n2-standard taahhüdü n2d-standard'a uygulanmaz. Stabil, tahmin edilebilir workload'lar için doğru seçim. Örneğin production veritabanı sunucuları, sabit boyutlu Kubernetes node pool'ları.
Spend-based CUD (Flex CUD)
Aylık dolar bazlı bir taahhüt verirsiniz ($X/saat veya $Y/ay) ve indirim Compute Engine, Cloud Run, GKE Autopilot, Cloud SQL, AlloyDB gibi hizmetlere otomatik uygulanır. İndirim oranı düşük (1 yıl %20, 3 yıl %28), ama bölge, makine ailesi veya servis değiştirseniz bile geçerliliğini korur. Bu, Savings Plans'in GCP karşılığıdır.
Sustained Use Discount nasıl hesaplanır?
Sustained Use Discount, bir VM'nin aylık çalışma süresi belirli eşikleri aştığında otomatik uygulanan indirimdir; satın alma veya rezervasyon gerektirmez. SUD yalnızca N1, N2, N2D, M1, M2, M3 ve C2/C2D ailelerinde geçerlidir. E2 ve T2D'de SUD yoktur. Bu detayı atlayan çoğu mimar, maliyet karşılaştırmalarında E2'yi yanlış konumlandırıyor. Bir önceki projemde bu yüzden çıkan bir maliyet hesabı hatasını ben de bizzat yakalamıştım.
Formül kabaca şudur (N1 için): ayın %25'i boyunca çalıştırdığınız vCPU'lar normal fiyatla, sonraki %25 için %20 indirim, sonraki %25 için %40 indirim, son %25 için %60 indirim uygulanır. Ay sonu efektif indirim genelde %30 civarındadır. N2/N2D'de basamaklar farklı ve maksimum indirim %20'ye kadar düşer.
# Bir N1 VM'in aylık SUD sonrası maliyetini hesaplayan basit Python
# Faturada SUD otomatik yansır; bu hesap forecast için kullanılır.
def n1_sud_cost(on_demand_hourly: float, hours_used: int, hours_in_month: int = 730) -> float:
usage_ratio = hours_used / hours_in_month
tiers = [
(0.25, 1.00), # ilk %25: indirim yok
(0.50, 0.80), # %25-50: %20 indirim
(0.75, 0.60), # %50-75: %40 indirim
(1.00, 0.40), # %75-100: %60 indirim
]
total = 0.0
prev_threshold = 0.0
for threshold, multiplier in tiers:
applied_ratio = max(0.0, min(usage_ratio, threshold) - prev_threshold)
total += applied_ratio * hours_in_month * on_demand_hourly * multiplier
prev_threshold = threshold
return total
# Örnek: n1-standard-4, us-central1, $0.1900/saat, ay boyunca çalışıyor
print(f"On-demand: ${0.1900 * 730:.2f}")
print(f"SUD sonrası: ${n1_sud_cost(0.1900, 730):.2f}")
# Çıktı yaklaşık: On-demand: $138.70 / SUD sonrası: $97.09
Önemli detay: SUD vCPU ve bellek bazında hesaplanır, VM bazında değil. Yani gün içinde scale up/down yapan bir auto-scaling grup yine de SUD'tan tam yararlanır, çünkü toplam vCPU-saat kümülatif olarak değerlendirilir. Bu mantığın resmi açıklaması için SUD belgelerine bakın.
Spot VM ile Preemptible VM arasındaki fark nedir?
Spot VM, Google'ın 2021'de Preemptible VM'lerin yerine geçirdiği kesintili kapasite ürünüdür ve 2026 itibarıyla Preemptible VM'ler tamamen kullanımdan kaldırılmıştır. İki ürün arasındaki üç temel fark, FinOps açısından kritiktir:
Özellik
Preemptible VM (eski)
Spot VM (güncel)
Maksimum yaşam süresi
24 saat (sabit)
Sınırsız (kapasite varsa)
İndirim oranı
%60–%80 (sabit)
%60–%91 (talebe göre dinamik)
Fiyat değişkenliği
Aylık değişir
Real-time piyasa fiyatı
30 saniye ön bildirim
Var
Var
GKE entegrasyonu
Sınırlı
Native node pool desteği
Stopped state çıkışı
TERMINATED
STOPPED veya TERMINATED (seçilebilir)
Pratikte Spot VM'lerin yaşam süresi sınırının kalkması batch işlemlerin yeniden tasarlanmasını mümkün kıldı. Örneğin 4 saat süren bir veri pipeline'ı artık baştan başlatma korkusu olmadan Spot üzerinde çalıştırılabilir. Yine de checkpoint mantığı şart: 30 saniyelik SIGTERM bildirimi geldiğinde state'i Cloud Storage'a yazmazsanız iş kaybedilir. Bunu acı bir şekilde, bir ETL job'unun gece 3'te düşmesiyle öğrenmiştim.
# Spot VM'i terraform ile bir GKE node pool olarak tanımlamak
resource "google_container_node_pool" "spot_workers" {
name = "spot-pool"
cluster = google_container_cluster.primary.name
location = "europe-west4"
node_count = 3
node_config {
machine_type = "n2d-standard-4"
spot = true # 2021 öncesinde preemptible = true idi
# Spot node'ları normal workload'lardan ayırmak için taint
taint {
key = "cloud.google.com/gke-spot"
value = "true"
effect = "NO_SCHEDULE"
}
labels = {
workload-type = "batch"
cost-tier = "spot"
}
}
autoscaling {
min_node_count = 0
max_node_count = 20
}
}
Right-sizing ve Recommender API ile otomatik öneri
Right-sizing, GCP'de Recommender API üzerinden büyük ölçüde otomatize edilebilen, ama hâlâ insan onayı gerektiren bir süreçtir. Recommender, CPU ve RAM metriklerini 8 günlük pencere üzerinden değerlendirir ve makine tipini küçültme, durdurma veya farklı bir aileye geçirme önerileri üretir. Bu sürecin nasıl kurgulanacağına dair daha geniş bir bakış için serverless maliyet optimizasyonu rehberindeki auto-scaling mantığını da incelemenizi öneririm. Prensipler aynı, sadece kontrol düzlemi değişiyor.
Recommender API'yi gcloud ile çalıştırma
# Tüm projedeki idle VM önerilerini listele
gcloud recommender recommendations list \
--project=my-prod-project \
--location=europe-west4-a \
--recommender=google.compute.instance.IdleResourceRecommender \
--format="table(content.overview.resource,primaryImpact.costProjection.cost.units,stateInfo.state)"
# Right-sizing (makine tipini küçültme) önerilerini al
gcloud recommender recommendations list \
--project=my-prod-project \
--location=europe-west4-a \
--recommender=google.compute.instance.MachineTypeRecommender \
--format=json > rightsizing-recommendations.json
# Önerileri JSON üzerinden işleyip CSV'ye dök (spreadsheet'e taşımak için)
jq -r '.[] | [.name, .content.overview.recommenderSubtype, .primaryImpact.costProjection.cost.units] | @csv' \
rightsizing-recommendations.json > rightsizing.csv
Pratikte ben bu çıktıyı her hafta Pazartesi sabah otomatik bir Cloud Scheduler + Cloud Function ile çekip Google Sheet'e bastırıyorum. Mühendislik liderleri kendi takımlarının önerilerini görüyor, onay verilen değişiklikleri Terraform PR olarak açıyoruz. Otomatik uygulamadan kaçınmamın sebebi basit: Recommender bazen production workload'ları idle olarak işaretliyor. Bir cron job ayda iki kez tetikleniyorsa, 8 günlük pencerede idle görünür, ama kritik olabilir.
Active Assist ile cross-recommender görünüm
Active Assist, Recommender API üzerine kurulu yönetim katmanıdır ve Cloud Console'da tek bir dashboard'da tüm öneri kategorilerini birleştirir: idle resources, unattached persistent disks, idle Cloud SQL instances, eski snapshot'lar, kullanılmayan static IP'ler. Özellikle 30 günden eski persistent disk snapshot'ları ve unattached IP'ler, sessiz sedasız ayda yüzlerce dolar yiyen iki klasik sorundur.
BigQuery maliyetleri nasıl optimize edilir?
BigQuery fiyatlandırması 2023'te editions modeline geçti ve eski flat-rate / slot reservation modelini bir geçiş süreciyle değiştirdi. 2026'da üç edition mevcut: Standard ($0.04/slot-hour), Enterprise ($0.06) ve Enterprise Plus ($0.10). Bunların yanında klasik on-demand fiyatlandırma da hâlâ var ($6.25/TB taranan veri için, us-multi-region). Resmi liste ve sürekli güncellenen detaylar için BigQuery pricing belgesini takip etmek en sağlıklısı.
On-demand mı, slot reservation mı?
Eşik genelde şudur: aylık 50 TB+ taranan veri veya saatte 100+ slot-saat tutarlı kullanım varsa, Standard edition autoscaling slot reservation on-demand'den ucuza geliyor. Bunun altındaki yükler için on-demand kalmak doğru. Autoscaling slot'larında 60 saniyelik minimum faturalama yüzünden seyrek sorgu yapan projelerde slot rezervasyonu pahalıya patlayabiliyor.
-- Hangi sorguların en çok veri taradığını bulun (son 30 gün)
SELECT
user_email,
query,
total_bytes_processed / POW(1024, 4) AS tb_processed,
total_bytes_processed * 6.25 / POW(1024, 4) AS estimated_usd,
creation_time
FROM `region-us`.INFORMATION_SCHEMA.JOBS_BY_PROJECT
WHERE
creation_time >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 30 DAY)
AND job_type = 'QUERY'
AND state = 'DONE'
ORDER BY total_bytes_processed DESC
LIMIT 50;
Standart optimizasyonlar (partitioning, tipik olarak tarih sütununa göre; clustering, en sık WHERE/JOIN'de kullanılan sütunlar; SELECT * yerine sütun seçimi; materialized view kullanımı) birkaç ay içinde tipik bir analytics workload'ında %40–%60 tarama azaltabilir. Etiketleme stratejisi, maliyetleri sorguya/kullanıcıya/takıma ayrıştırmak için kritik. Konuyu daha derinden ele alan bir başlangıç için bulut etiketleme ile maliyet tahsisi rehberini öneririm.
Cloud Storage sınıfları ve lifecycle politikaları
Cloud Storage'ın dört sınıfı vardır ve hangi sınıfın hangi erişim örüntüsüne uyduğunu bilmek, aylık storage faturasını yarıya indirebilir. Pratik kural: ne kadar nadir erişim, o kadar düşük storage fiyatı, ama o kadar yüksek erişim/early-deletion ücreti.
Bu politikayı gsutil lifecycle set lifecycle.json gs://my-bucket ile uygularsınız. Dikkat etmeniz gereken iki tuzak var: (1) erken silme/sınıf değiştirme cezası. Bir nesneyi Nearline'a aldıktan 10 gün sonra silmek, 30 günlük minimum sürenin geri kalanını faturanıza ekler. (2) storageClass filtresi olmadan kural yazarsanız, Archive'daki veriyi tekrar Nearline'a alma riski var. Pahalı bir hata, bunu deneyimleyenler iyi bilir.
Network egress ve veri transfer maliyetleri
Network egress, GCP faturasının en az anlaşılan kalemidir ve çoğu organizasyonda toplamın %15 ile %30'una ulaşır. Bölgeler arası transfer (örneğin europe-west4 → us-central1) GB başına $0.02 ile $0.08 arasında değişir; internete egress ise ilk 1 GB ücretsiz, sonrasında $0.085 ile $0.12 arasındadır. Aynı bölgede, aynı zone içinde transfer ücretsizdir; farklı zone'lar arasında GB başına $0.01'dır.
Yüksek hacimli egress için üç optimizasyon kaldıracı var: Network Service Tiers üzerinden Standard tier'a geçmek (Premium'a göre %25 ile %35 ucuz, ama latency biraz yükselir), Cloud CDN ile cacheable içeriği kaynaktan tekrar tekrar serve etmemek, ve büyük data warehouse-to-analytics transferleri için Cloud Interconnect veya Private Service Connect kullanmak. Multi-region projelerde data residency gereksinimi yoksa servisleri tek bir bölgede toplamak en pratik tasarruftur. Söylemesi kolay, kuruluş geneline yaymak zor.
Etiketleme, labels ve FinOps disiplini
Tüm bu indirimler, hangi takımın hangi maliyeti yarattığını göremiyorsanız anlamsızdır. GCP'de labels (kaynak seviyesi) ve tags (IAM koşullu, organizasyon seviyesi) iki farklı mekanizmadır ve sık karıştırılır. FinOps maliyet tahsisi için labels kullanılır; tags daha çok policy-as-code için.
Zorunlu label seti olarak şu beşliyi öneririm: cost-center, environment, team, product, lifecycle-stage. Bunları Organization Policy ile constraints/gcp.requireResourceTagging üzerinden zorunlu hale getirin. Etiketlenmemiş kaynak yaratma denemesi reddedilir; mevcut etiketsiz kaynaklar için BigQuery'ye export edilen billing data üzerinden haftalık "unallocated cost" raporu çıkarın.
-- Billing export'tan etiketsiz harcamaları bul (son 30 gün)
SELECT
service.description AS service,
project.id AS project_id,
SUM(cost) AS total_cost
FROM `billing_export.gcp_billing_export_resource_v1_XXXX`
WHERE
DATE(_PARTITIONTIME) >= DATE_SUB(CURRENT_DATE(), INTERVAL 30 DAY)
AND (labels IS NULL OR ARRAY_LENGTH(labels) = 0)
GROUP BY service, project_id
HAVING total_cost > 50
ORDER BY total_cost DESC;
AWS tarafında benzer bir disiplin nasıl kurulur sorusu için AWS Savings Plans vs Reserved Instances karşılaştırmasında bahsettiğim CUR (Cost & Usage Report) yaklaşımı uygulanabilir. Temel mantık her üç bulutta aynı: ayrıştırılamayan maliyet, optimize edilemeyen maliyettir.
Sıkça sorulan sorular
GCP'de Sustained Use Discount otomatik olarak uygulanır mı?
Evet. SUD herhangi bir kontrat, rezervasyon veya manuel ayar gerektirmez. N1, N2, N2D, M1/M2/M3 ve C2/C2D ailelerinde bir VM aylık çalışma süresinin belirli yüzdelerini aştığında otomatik olarak faturaya yansır. Ay sonu efektif indirim N1'de yaklaşık %30, N2 ve N2D'de %20'ye kadardır. E2 ve T2D ailelerinde SUD yoktur.
CUD satın aldıktan sonra iptal edebilir miyim?
Hayır. Hem kaynak-tabanlı hem spend-based CUD'lar 1 veya 3 yıllık taahhüt olup geri alınamaz. Spend-based CUD'lar başka servislere kayabildiği için CUD'unuzu boşa çıkarmak daha zor olur, ama yine de kullanılmayan kontrat parası tam olarak ödenir. Bu yüzden taahhüt verirken son 3 ayın stabil baseline kullanımını esas alın, beklenen büyümeyi değil.
Spot VM ile Preemptible VM aynı şey mi?
Hayır. Spot VM, Preemptible VM'in 2021'deki güncellenmiş halidir ve 2026'da Preemptible VM tamamen kullanımdan kaldırılmıştır. Temel farklar: Spot'ta 24 saatlik maksimum yaşam süresi sınırı kalktı, fiyat real-time piyasaya göre değişiyor (%60–%91 indirim aralığında) ve GKE node pool'larında native destek geldi.
BigQuery'de on-demand mı slot reservation mı daha ucuz?
Aylık taranan veri 50 TB'ın altındaysa veya sorgular sıkıştırılmış aralıklarda gelmiyorsa, on-demand ($6.25/TB) genelde daha ucuzdur. 50 TB'ın üstünde veya saatte tutarlı 100+ slot-saat kullanım varsa, Standard edition autoscaling slot reservation devreye girer ve %30 ile %50 tasarruf sağlayabilir. Kararı vermeden önce INFORMATION_SCHEMA.JOBS_BY_PROJECT üzerinden son 30 günün slot-saatini ve taranan veriyi çıkarıp her iki modelin maliyetini paralel hesaplayın.
GCP egress maliyetlerini nasıl düşürebilirim?
Üç ana kaldıraç var: (1) Network Service Tier'ı Premium'dan Standard'a düşürmek (latency toleransı olan workload'larda %25 ile %35 tasarruf), (2) cacheable içerikler için Cloud CDN kullanmak, (3) cross-region transferi mümkün olduğunca aynı bölgeye konsolide etmek. Yüksek hacimli sürekli transferler için Cloud Interconnect veya Private Service Connect, kamuya açık internet egress'e göre çok daha ucuza gelir.
Recommender API'nin önerilerini otomatik uygulamak güvenli mi?
Production ortamlarında otomatik uygulamayı önermiyorum. Recommender 8 günlük metrik penceresi kullanır ve seyrek tetiklenen cron job'ları veya aylık batch süreçleri idle olarak işaretleyebilir. Pratik akış: önerileri haftalık olarak çekin, Slack veya Google Sheet üzerinden ilgili takıma sunun, onay sonrası değişikliği Terraform PR olarak yaratın. Bu hem güvenlik hem hesap verebilirlik sağlar.
