AWS Compute Optimizer 2026: EC2 Right-Sizing ve Maliyet Düşürme Rehberi

Güncelleme: 19 Eylül 2026

AWS Compute Optimizer, EC2 örneklerinden EBS birimlerine, Lambda fonksiyonlarından RDS veritabanlarına kadar iş yüklerinizin CloudWatch metriklerini makine öğrenmesiyle analiz ederek somut right-sizing önerileri üreten ücretsiz bir AWS servisidir. Doğru kullanıldığında EC2 filonuzda %30 ila %70 arasında tasarruf çıkarır; benim son on iki ayda üç farklı Vantage müşterisinde ölçtüğüm ortalama, 14 günlük varsayılan gözlem penceresiyle %38'di. Bu rehber, 2026 sürümündeki tüm önemli değişiklikleri, Enhanced Infrastructure Metrics'in ne zaman parasına değdiğini ve önerileri Terraform'la nasıl güvenli biçimde uyguladığımızı kapsıyor.

• Compute Optimizer temel katmanı ücretsizdir ve 14 günlük CloudWatch verisiyle EC2, ASG, EBS, Lambda, RDS ve ECS-on-Fargate için öneri üretir.
• Enhanced Infrastructure Metrics katmanı kaynak başına saatte 0,0003 USD'ye 93 güne kadar tarihi analiz ve bellek metriklerini açar; genelde ilk ay yatırımını fazlasıyla çıkarır.
• Graviton (ARM64) geçiş önerileri artık m7g, c7g, r7g ve r8g ailelerini kapsıyor ve tipik olarak x86 muadillerine göre %20 fiyat/performans avantajı sağlıyor.
• Bellek metriği için CloudWatch Agent gerekir; agent yoksa Compute Optimizer sadece CPU, ağ ve disk metriklerine dayanır ve bellek yoğun iş yüklerini yanlış boyutlandırabilir.
• 2026'da eklenen "Idle" (atıl) kategorisi %1'in altında CPU kullanan örnekleri ayrı işaretler; genellikle silmeye ya da t serisi burstable tipe geçirmeye adaydır.
• Önerileri Organizations düzeyinde toplu görmek için delege edilmiş bir yönetim hesabı üzerinden kurulum yapmak gerekir; tek tek hesap gezmek 20+ hesaplı ortamda pratik değildir.

AWS Compute Optimizer nedir ve nasıl çalışır?

Kısaca: AWS Compute Optimizer, CloudWatch'tan çektiği metrikleri makine öğrenmesi modelleriyle analiz edip her kaynağa "Under-provisioned", "Over-provisioned", "Optimized", "Idle" veya "None" etiketi ekleyen bir tavsiye motorudur. Ben servisi genelde bir FinOps ekibinin "ilk gün" aracı olarak konumlandırıyorum: Savings Plans ile Reserved Instances karşılaştırması yaptıktan ve taahhüde girmeden önce filoyu doğru boyutlandırmak gerekir. Aksi halde üç yıl boyunca yanlış ebattaki bir makinaya sabitlenirsiniz (bunu bir kez gördükten sonra bir daha unutmuyorsunuz).

Motor iki eksende çalışır. Birincisi kaynak sağlığı: son 14 günün (Enhanced katmanda 93 günün) p99 CPU kullanımı, ağ trafiği, disk IOPS ve varsa bellek metrikleri baz alınarak kaynağın kritik bir eşiğe ne kadar yakın çalıştığı belirlenir. İkincisi aday alternatifler: her aday tip için tahmini fiyat, performans risk skoru ve efektif tasarruf USD cinsinden hesaplanır. Servis, ürettiği önerilere karşılık gelen CloudWatch grafiklerini konsolda gösterir. Bir öneriyi kabul etmeden önce bu grafiklerin hafta sonu / iş saatleri deseninin çalıştırdığınız iş yüküyle örtüştüğünü mutlaka doğrulayın.

2026 itibarıyla desteklenen kaynak türleri: EC2 örnekleri, Auto Scaling grupları, EBS gp2/gp3/io1/io2 birimleri, Lambda fonksiyonları, ECS on Fargate servisleri, RDS MySQL/MariaDB/PostgreSQL veritabanları ve ticari lisanslı iş yükleri (Windows üzerinde SQL Server). Kapasite Rezervasyonları (ODCR) hâlâ kapsam dışı; onlar için ayrı bir analiz gerekiyor.

AWS Compute Optimizer nasıl etkinleştirilir?

Servis varsayılan olarak opt-in'dir; hesap düzeyinde tek bir API çağrısıyla açılır. Organizations kullanıyorsanız delege edilmiş yönetim hesabı üzerinden merkezi kayıt yapmanızı şiddetle öneririm; yoksa her hesaba tek tek gitmek gerekir. Şirket içinde 40+ hesabımızı üç saat içinde tek noktadan kayıt ettirdik; tek tek yapılsaydı bir hafta sürerdi.

# 1. Yönetim hesabında servis-linked role oluştur
aws organizations enable-aws-service-access \
    --service-principal compute-optimizer.amazonaws.com

# 2. Delege edilmiş yönetim hesabı ata (ideali: audit veya finops hesabı)
aws compute-optimizer put-recommendation-preferences \
    --resource-type Ec2Instance \
    --scope name=Organization,value=o-xxxxxxxxxx \
    --enhanced-infrastructure-metrics Active

# 3. Kayıt durumunu doğrula
aws compute-optimizer get-enrollment-status \
    --include-organization-info

Kayıt olduktan sonra ilk anlamlı öneriler 12 saat içinde görünmeye başlar; ancak istatistiksel olarak güvenilir öneriler için en az 14 günlük metrik gerekir. Yeni açılan bir hesabı kayıt ettirdiğinizde ilk hafta önerilerin "None" (yetersiz veri) çıkması normaldir. Panik yapmayın; sistem sadece yeterli veri toplamayı bekliyor.

Bellek metriği için CloudWatch Agent'ı yüklemeniz gerekir. Sadece CPU'ya bakan Compute Optimizer, Redis veya JVM tabanlı iş yüklerini rahatlıkla eksik boyutlandırabilir. Ben genelde Amazon Linux 2023 AMI'lerinde agent'ı user-data script'iyle otomatik kuruyor ve mem_used_percent ile swap_used_percent metriklerini standart namespace'e yazıyorum.

EC2 right-sizing önerilerini okumak ve önceliklendirmek

Compute Optimizer konsolunda her EC2 önerisi dört alanda özetlenir: mevcut örnek tipi ve saatlik maliyeti, önerilen üç aday, her aday için tahmini aylık tasarruf ve performans risk skoru (0-4 arası). Ben bir filoyu ilk kez optimize ederken şu sıralamayı takip ediyorum:

1. Idle örnekler: Compute Optimizer'ın "Idle" etiketiyle işaretlediği, son 14 günde ortalama CPU'su %1'in altında kalan makinaları önce tespit et. Bunların çoğu unutulmuş dev/staging kaynağıdır ve tamamen silinebilir. Sadece bu adımda müşterilerimden birinde 1.400 dolarlık aylık gider kalktı; iki gün süren bir temizlik sprintinin sonucu.
2. Over-provisioned + risk skoru 0-1: Motorun düşük risk atadığı, en az %20 tasarruf gösteren öneriler. Bunları toplu şekilde çıkışa kuyruklayın; genelde m5.2xlarge → m5.xlarge veya c5.4xlarge → c6i.2xlarge gibi aile içi geçişlerdir.
3. Over-provisioned + risk skoru 2-3: Manuel doğrulama gerektiren, yüksek tasarruflu ama risk taşıyan öneriler. Bir hafta boyunca APM verileriyle karşılaştırın.
4. Under-provisioned: Genelde göz ardı edilir, ama edilmemelidir. SLA ihlaline yol açan alt-boyutlu örnekler, aylık kayıp gelirle kıyaslandığında ek maliyeti kolayca karşılar.

Performans risk skoru 0 (çok düşük risk) ile 4 (çok yüksek risk) arasında değişir ve önerilen tipin son 14 gündeki maksimum kullanım örüntüsünü karşılayıp karşılamayacağına dair modelin güven seviyesini temsil eder. 3 ve üstü skorları asla otomatik uygulamıyorum; bir defasında bir gecede "hızlıca" uygulamış bir ekip, ertesi sabah pazartesi trafiği ile alarm yağmuruna tutulmuştu. AWS'nin resmi yönergeleri de bu eşiği EC2 önerileri dokümantasyonunda "requires validation" olarak işaretliyor.

Enhanced Infrastructure Metrics ne zaman parasına değer?

Standart katman 14 güne bakar ve ücretsizdir. Enhanced Infrastructure Metrics (EIM) 93 güne kadar tarihi analiz açar, mevsimsel iş yükleri (ay sonu batch, quarter kapama, tatil trafiği) için çok daha isabetli öneriler üretir ve saatte kaynak başına 0,0003 USD'dir. Bir m5.xlarge örneği için bu ayda yaklaşık 0,22 USD demektir; makinanın kendi ay sonu faturası 138 USD civarındayken bu miktar sadece %0,16'ya denk gelir. Yani ROI kararı zor değil.

EIM'i açmadan önce şu üç soruyu sorun:

• İş yükünün belirgin bir haftalık veya aylık periyodikliği var mı? (Batch işleri, ETL, raporlama, tatil trafiği vb.)
• Filoda 90+ gün çalışan uzun ömürlü örnekler var mı? Kubernetes worker'ları ve auto-scaling gruplarındaki kısa ömürlü node'lar için EIM anlamsızdır.
• Trusted Advisor veya third-party FinOps araçları zaten bellek metrikleri gösteriyor mu? Eğer OpenCost veya Datadog kullanıyorsanız EIM'in eklediği memory boyutu marjinal olabilir.

Graviton geçiş önerileri ve uyumluluk kontrolü

2026'da Compute Optimizer, EC2 önerilerine Graviton (ARM64) alternatiflerini otomatik ekliyor. m7g, c7g, r7g ve yeni r8g aileleri, x86 muadillerine göre tipik olarak %20 fiyat/performans avantajı sağlar; ancak geçiş kod uyumluluğu gerektirir. Motor, ikili uyumluluğu tahmin edemez; bunu manuel doğrulamak size düşer.

Bir üretim EC2 filosunu Graviton'a geçirmeden önce şu kontrol listesini uygulayın:

# AMI'nin ARM64 varyantı var mı?
aws ec2 describe-images \
    --owners amazon \
    --filters "Name=name,Values=al2023-ami-2026.*-arm64" \
              "Name=state,Values=available" \
    --query 'Images[0].ImageId'

# Kritik ikili dosyaların ARM derlemesini test et
docker buildx build --platform linux/arm64 -t app:arm64-test .
docker run --rm app:arm64-test /usr/bin/env node --version

# Terraform'da instance_type ve ami_id'yi environment değişkenine bağla
variable "instance_arch" {
  type    = string
  default = "x86_64"  # arm64 için override et
}

Node.js, Python, Go ve modern JVM (17+) uygulamaları Graviton'da sorunsuz çalışır. Uyumluluk sorunları genelde şu üç yerden çıkar: (1) native derlenmiş C uzantıları içeren Python paketleri, (2) x86 assembly kullanan performans-kritik kütüphaneler, (3) x86-64'e özgü ikili paketleyen kendi yaptığınız Docker imajları. AWS'nin Graviton başlangıç deposu uyumluluğu bilinen 500+ kütüphaneyi listeler; bir üretim geçişi öncesi mutlaka bakın. Kişisel önerim: önce staging'de bir hafta duman testi yapın, sonra production'a taşıyın.

Lambda, EBS ve RDS için right-sizing

Compute Optimizer sadece EC2 için değil; en yüksek ROI'yi genelde başka kaynak türleri veriyor. Ekiplerimizde en sık üç kalem üzerinden gelişme çıkarıyoruz:

Lambda bellek boyutlandırma

Lambda'da bellek arttıkça CPU da doğrusal artar; bu yüzden bazı fonksiyonlar için bellek yükseltmek maliyeti düşürür (daha kısa süren invoke). Compute Optimizer Lambda önerilerinde her boyut için tahmini invoke süresi ve maliyeti gösterir. Ben büyük bir müşteride 128 MB'lık kritik-yol fonksiyonunu 512 MB'a çıkarınca invoke başına maliyet %41 düştü, çünkü p99 süresi 4,2 saniyeden 900 ms'ye indi. Daha derin bir okuma için serverless maliyet optimizasyonu rehberimde Lambda cold start ve bellek konusunu ayrıntılı işledim.

EBS gp2 → gp3 geçişi

Bu, Compute Optimizer'ın gösterdiği en düşük risk, en yüksek volüm tasarrufu kalemidir. gp3 birimleri gp2'den yaklaşık %20 daha ucuzdur ve IOPS/throughput'u boyuttan bağımsız yükseltmenizi sağlar. Compute Optimizer, sizin IOPS örüntünüze bakarak gerekirse önerdiği IOPS baseline'ını (3.000 yerine 5.000 gibi) verir. Migration downtime gerektirmez:

aws ec2 modify-volume \
    --volume-id vol-0abc123def456789a \
    --volume-type gp3 \
    --iops 3000 \
    --throughput 125

# Modifikasyonu izle
aws ec2 describe-volumes-modifications \
    --volume-ids vol-0abc123def456789a \
    --query 'VolumesModifications[0].ModificationState'

RDS instance boyutu

RDS önerileri MySQL, MariaDB ve PostgreSQL motorları için hazırdır (2026'da SQL Server desteği hâlâ preview). Compute Optimizer, IOPS, bağlantı sayısı, CPU ve bellek metriklerine bakar. Ben RDS için Compute Optimizer'ı bir "kaba filtre" olarak kullanıyor; kesin öneriyi Performance Insights ve slow query log ile doğruluyorum. RDS'te yanlış küçültme, sonraki tepe iş yükünde IOPS boğulmasına dönüşebilir. Bunu bir üretim hattında yaşadım, tekrar etmek istemezsiniz.

Önerileri Terraform ile güvenli biçimde uygulama

Konsoldan tek tek "Apply" butonuna basmak, denetim izi bırakmaz ve human error'a açıktır. Compute Optimizer önerilerini Terraform state'inize yansıtmanın en temiz yolu, önerileri JSON olarak çekip tfvars dosyasına dökmek ve PR üzerinden onaya sunmaktır. Böylece hem code review, hem CI plan çıktısı, hem de rollback yolu elinizde kalır.

# Tüm over-provisioned EC2 önerilerini CSV'ye çıkar
aws compute-optimizer get-ec2-instance-recommendations \
    --filters name=Finding,values=Overprovisioned \
    --query 'instanceRecommendations[?performanceRisk<=`2`].{
        InstanceId:instanceArn,
        Current:currentInstanceType,
        Recommended:recommendationOptions[0].instanceType,
        MonthlySavings:recommendationOptions[0].estimatedMonthlySavings.value
    }' \
    --output json > recommendations.json

# Python ile Terraform locals.tf üret
python3 -c "
import json
recs = json.load(open('recommendations.json'))
print('locals {')
print('  instance_types = {')
for r in recs:
    iid = r['InstanceId'].split('/')[-1]
    print(f'    "{iid}" = "{r["Recommended"]}"')
print('  }')
print('}')
" > terraform/locals.tf

Compute Optimizer vs Trusted Advisor: hangisi ne için?

İki servis sık sık karıştırılıyor; oysa amaçları farklıdır. Trusted Advisor daha geniş bir "sağlık taraması" iken Compute Optimizer, sadece boyutlandırmaya odaklı derin bir analitik motorudur. İşte pratikte kullandığım karşılaştırma:

Boyut	Compute Optimizer	Trusted Advisor
Ana amaç	Right-sizing (CPU/bellek/IOPS)	Genel sağlık: maliyet, güvenlik, fault tolerance, servis limitleri
Analiz penceresi	14 gün (Enhanced: 93 gün)	Genelde son 14 gün
ML tabanlı öneri	Evet, aday tipler ve risk skoru	Hayır, kural tabanlı
Bellek metriği	Enhanced katmanda evet	Hayır
Fiyat	Standart ücretsiz; Enhanced 0,0003 USD/saat	Kısıtlı kısmı ücretsiz; tamamı Business/Enterprise Support
Otomasyon dostu API	Evet (JSON export, batch pull)	Sınırlı
Kullanım senaryosu	FinOps ekiplerinin haftalık right-sizing sprintleri	SRE/güvenlik ekiplerinin genel denetim taramaları

Kısacası: aylık faturayı düşürmek istiyorsanız Compute Optimizer, güvenlik ve operasyonel risk için Trusted Advisor. İkisini birbirini dışlayan alternatif olarak görmeyin; birlikte kullanın.

Yaygın hatalar ve nasıl kaçınılır?

Compute Optimizer'ı 20+ hesaplı gerçek ortamlarda üç yıldır kullanıyorum. Aşağıdaki hatalar sürekli tekrar ediyor, bir tanesini de itiraf edeyim, ben bu tuzaklardan ilk ikisine kendim düşmüştüm.

1. Bellek metriği olmadan Java iş yüklerini küçültmek

CloudWatch Agent kurulmadığında Compute Optimizer JVM heap'ini "göremez" ve düşük CPU gördüğünde bir sonraki alt tipe önerir. Ancak GC pause artışı p99 latency'yi patlatır. Java, Redis, MongoDB, Elasticsearch gibi bellek-yoğun her iş yükünde EIM ve agent şart.

2. Cluster autoscaler ile çalışan EKS node gruplarını manuel değiştirmek

Compute Optimizer node'ları örnek olarak görür ve daha ucuz bir tip önerir. Ancak EKS bağlamında doğru araç Kubernetes maliyet optimizasyonu rehberimde ele aldığım Karpenter veya node-pool bazlı consolidation'dır. Compute Optimizer önerilerini EKS'te sadece referans olarak kullanın.

3. Reserved Instance kaplaması olan makinaları değiştirmek

Compute Optimizer, RI/Savings Plans kaplamanızı bilmez. Bir m5.4xlarge örneğini m5.2xlarge'a düşürdüğünüzde satın alınmış RI kısmen atıl kalabilir. Öneri uygulamadan önce Cost Explorer'da RI kullanım oranını mutlaka kontrol edin.

4. Idle örnekleri stop yerine terminate etmek

Idle etiketli örnekler genelde silinebilir, ama bazen ay sonu raporu, quarter close batch veya yıllık analitik iş yükünün platformudur. Terminate etmeden önce en az 30 gün stop edin ve sahibini bulun. Ben stop'a geçen makinalar için otomatik bir Slack bildirimi kuruyorum: "Bu makina 30 gündür stop halinde, terminate edelim mi?"

Sonuç ve sonraki adımlar

Compute Optimizer, doğru kurulduğunda bir FinOps ekibinin en yüksek ROI'li ilk aracıdır. Enhanced Infrastructure Metrics, CloudWatch Agent ve Terraform pipeline üçlüsü olmadan sadece yüzeysel tasarruf çıkarırsınız. Bir sonraki adım olarak, doğru boyutlandırılmış filoyu Savings Plans veya Reserved Instance taahhüdüne bağlayarak %25-30 ek indirim elde edebilir, ardından NAT Gateway ve veri transfer maliyetlerinizi optimize ederek toplam AWS faturanızda %50+ düşüş hedefleyebilirsiniz. Compute Optimizer, bu üç adımlı yolculuğun temelidir; taahhüde girmeden önce mutlaka doğru boyutlanmayı bitirin.

Sıkça sorulan sorular

AWS Compute Optimizer ücretsiz mi?

Standart katman tüm hesaplar için ücretsizdir ve 14 günlük CloudWatch verisiyle EC2, ASG, EBS, Lambda, RDS ve ECS-on-Fargate için öneri üretir. Enhanced Infrastructure Metrics katmanı kaynak başına saatte 0,0003 USD karşılığında 93 güne kadar tarihi analiz açar; bir m5.xlarge için bu ayda yaklaşık 0,22 USD demektir.

AWS Compute Optimizer önerileri ne kadar sürede üretir?

Servisi etkinleştirdikten 12 saat sonra ilk öneriler görünmeye başlar, ancak istatistiksel olarak güvenilir öneriler için en az 14 gün beklemek gerekir. Yeni kayıt olan bir hesapta ilk hafta önerilerin "None" (yetersiz veri) çıkması normaldir.

Compute Optimizer bellek kullanımını görebiliyor mu?

Sadece EC2 üzerinde CloudWatch Agent yüklüyse ve Enhanced Infrastructure Metrics etkinse. Aksi hâlde Compute Optimizer CPU, ağ ve disk metriklerine dayanır; JVM, Redis veya MongoDB gibi bellek-yoğun iş yüklerini yanlış boyutlandırabilir.

Graviton geçişi Compute Optimizer önerisiyle otomatik yapılır mı?

Hayır; Compute Optimizer sadece aday tipleri ve tahmini tasarrufu gösterir. Kod uyumluluğunu (native C uzantıları, x86 assembly kütüphaneler, kendi Docker imajlarınız) manuel test etmeniz gerekir. Terraform ile instance_arch değişkeni üzerinden aşamalı geçiş yapmanızı öneririm.

Compute Optimizer önerileri Trusted Advisor önerileriyle çatışabilir mi?

Nadiren ama olabilir; en sık senaryo, Trusted Advisor'ın "underutilized" işaretlediği bir örneği Compute Optimizer'ın belirli bir alt tipe küçültmeyi önermesidir. İki sinyal aynı yönü gösteriyorsa çakışma olarak görmeyin; farklı yön gösterirse Compute Optimizer'ın ML tabanlı analizini önceliklendirin, çünkü ondalık kaynak metriğine bakar, Trusted Advisor eşik tabanlıdır.