AWS S3 Maliyetlerini Düşürmenin 7 Gerçekçi Yolu

Amazon S3 ile çalışmaya başlamanın ne kadar kolay olduğunu biliriz: Bir bucket oluştur, dosyayı yükle, işlem tamam. Ancak "nasıl olsa ucuz" düşüncesiyle hareket edip arkamızı döndüğümüzde, S3 aylar sonra gelen faturalarda şaşırtıcı bir maliyet kalemine dönüşebilir.

Bu rehberde, S3 maliyetlerinin gözden kaçan kaynaklarını ve bu maliyetleri %70'e kadar azaltmanızı sağlayacak 7 pratik yöntemi masaya yatıracağız.

S3 Maliyetleri Nereden Geliyor?

S3, verileri klasik bir dosya sistemi gibi hiyerarşik klasörlerde değil, her biri benzersiz bir ID'ye sahip bağımsız nesneler (object) olarak saklayan, internet ölçeğinde bir depolama hizmetidir. Onu sadece bir "bulut diski" olarak görmek eksik olur; S3 aynı zamanda veri gölleri (data lakes) ve küresel içerik dağıtımı için de bir merkezdir. İşte bu esneklik, yanlış yapılandırıldığında maliyet tuzaklarına zemin hazırlar.

Temel maliyet kalemleri şunlardır:

Depolama (Storage): Verinizin kapladığı alan için GB başına ödediğiniz ücret.
İstekler (Requests): GET, PUT, LIST gibi veriye yönelik her bir etkileşim.
Veri Transferi (Data Transfer): Verinin S3 dışına veya farklı AWS bölgelerine taşınması.

Şimdi, bu maliyetleri kontrol altına alacak 7 adıma geçelim.

1. Verinize Uygun Storage Class'ı Seçin

S3 optimizasyonunun altın kuralı, doğru Storage Class (Depolama Sınıfı) seçimidir. Mantık son derece basittir: Veriye ne kadar nadir ve yavaş erişim kabul edilebilir ise depolama maliyeti de o kadar düşer.

S3 Standard: Sık erişilen, "sıcak" veriler için varsayılan seçenektir. En yüksek maliyetli sınıftır.
S3 Intelligent-Tiering: Erişim sıklığı belirsiz veya değişken veriler için en akıllıca tercihtir. AWS, veriyi sizin yerinize otomatik olarak daha ucuz katmanlara taşır.
S3 Standard-IA: Nadiren erişilen ama anında gereken "ılık" veriler (örneğin, eski loglar, ara sıra bakılan yedekler) için idealdir. Depolama ucuzdur, ancak veriyi çekerken ek ücret alınır.
S3 Glacier Deep Archive: Yasal zorunluluklar gibi nedenlerle yıllarca saklanması gereken, neredeyse hiç erişilmeyen arşivler için kullanılır. En düşük depolama maliyetini sunar, fakat veriye erişim saatler sürebilir.

Hızlı Kazanım: Verinizin erişim deseninden emin değilseniz, hiç düşünmeden Intelligent-Tiering kullanın. Bu sınıf, kural tabanlı optimizasyona harcayacağınız zamandan tasarruf ettirerek anında fayda sağlar.

2. Lifecycle Kuralları ile "Hayalet Veri"yi Temizleyin

Lifecycle kuralı tanımlamadan Versioning (Sürüm Oluşturma) özelliğini etkinleştirmek, maliyetleri şişiren bir saatli bombadır. Siz dosyaları sildiğinizi sanırken, eski sürümler "Hayalet Veri" (Ghost Data) olarak birikmeye devam eder ve faturanızda sessizce yer kaplar.

Çözüm: Her S3 bucket'ı için mutlaka bir lifecycle kuralı oluşturun:

Güncel olmayan (non-current) versiyonları 30 gün sonra otomatik olarak Glacier gibi daha soğuk bir katmana taşıyın.
Bu eski versiyonları 365 gün sonra kalıcı olarak silin.
Yarım kalmış çok parçalı yüklemeleri (multipart uploads) 7 gün içinde temizleyin. Bu artıklar ciddi yer kaplayabilir.

3. Kontrolsüz API İsteklerini Durdurun

S3, sadece depolama için değil, yapılan her bir API isteği (GET, LIST vb.) için de ücret yazar. Milyonlarca nesneniz varsa, kodunuzdaki verimsiz bir döngü, depolama maliyetini kolayca aşabilir. Özellikle LIST istekleri, binlerce nesneyi listelerken fark edilmeyen ciddi bir maliyet kalemi oluşturur.

Öneri: Uygulama kodunuzda LIST operasyonlarınıza sınır getirin. Örneğin, belirli bir prefix (ön ek) altındaki nesneleri listeleyerek tarama alanını daraltın.

4. Bölgeler Arası Veri Transferini Optimize Edin

Veri, AWS bölgeleri arasında hareket ettiğinde ek ücrete (egress cost) tabidir. S3 bucket'ınız ile onu işleyen EC2 veya Lambda fonksiyonlarınız farklı bölgelerdeyse, aralarındaki her veri alışverişi faturaya yansır.

Çözüm: Veriyi işlediğiniz ve sakladığınız tüm AWS servislerinin aynı bölgede çalıştığından emin olarak bu maliyeti sıfırlayın.

5. Akıllı Veri Formatları Kullanarak Maliyetleri Azaltın

Özellikle analiz amaçlı veriler için JSON veya CSV gibi metin tabanlı formatlar yerine, hem depolama alanını hem de sorgu maliyetlerini düşüren modern, sütun bazlı (columnar) formatlar kullanın.

Columnar Formatlar (Apache Parquet, ORC): Athena gibi servislerle sorgulama yaparken tüm dosyayı taramak yerine sadece ihtiyaç duyulan sütunları okur. Bu, sorgu maliyetini ve süresini %90'a varan oranlarda düşürebilir.
Sıkıştırma (Gzip, Snappy): Veriyi sıkıştırmak, hem depolama hem de transfer maliyetlerini doğrudan azaltan temel bir adımdır.

Altın Kural: Analiz edilecek tüm verileri daima Parquet formatında ve sıkıştırılmış olarak saklayın.

6. Athena için Veriyi Bölümlere (Partition) Ayırın

Athena ile S3 üzerindeki veriyi SQL kullanarak sorgularken, veriyi bölümlere ayırmadan (partitioning) kullanmak, her sorguda tüm veri setini taramak anlamına gelir. Bu, yavaş olduğu kadar inanılmaz derecede pahalıdır.

Doğru Yapı: Verilerinizi, sorgulama sıklığınıza uygun bir anahtara (genellikle tarih) göre klasörlere ayırın: s3://logs/year=2025/month=08/day=12/

Bu yapı sayesinde Athena, sorguyu çalıştırırken sadece ilgili günün verisini tarar ve maliyetler dramatik bir şekilde düşer.

7. Prod S3 Bucket Kontrol Listesi ve Kaçınılması Gerekenler

Son olarak, S3 kullanımınızı denetlemek için bir kontrol listesi ve sık yapılan hatalar:

Checklist (Yapılacaklar)

✅ Varsayılan Olarak Intelligent-Tiering: Erişim deseni belirsiz tüm yeni bucket'lar için S3 Intelligent-Tiering ile başlayın.
✅ Her Bucket için Lifecycle Kuralı: Hiçbir bucket'ı başıboş bırakmayın. En azından yarım kalmış yüklemeleri temizleyen bir kural ekleyin.
✅ Maliyet Alarmları: Beklenmedik bir artışı faturanız gelmeden fark etmek için AWS Budgets ile alarmlar kurun.
✅ Güvenlik Önceliktir: Public erişimi varsayılan olarak engelleyin ve IAM policy'lerini "minimum yetki" prensibiyle yapılandırın.
✅ Analiz için Parquet: Athena veya benzeri servislerle analiz edilecek tüm verileri Parquet formatında ve bölümlenmiş (partitioned) olarak saklayın.

Anti-Pattern’ler (Uzak Durulması Gerekenler)

❌ Her Şeyi Standard Sınıfında Tutmak: "Nasıl olsa ucuz" diyerek tüm veriyi S3 Standard'da unutmak.
❌ Kuralsız Versioning: Eski sürümleri temizlemeden versioning özelliğini açmak. Bu, "Hayalet Veri" birikmesine ve faturanızın şişmesine neden olur.
❌ Kör Sorgular: Veriyi bölümlemeden Athena ile SELECT * FROM table gibi genel sorgular çalıştırmak.
❌ Bölgeler Arası Gereksiz Trafik: Sık etkileşimde olan S3 bucket ve EC2/Lambda gibi servisleri farklı bölgelere yerleştirmek.

Sonuç: Maliyet Optimizasyonu Bir Kez Değil, Sürekli Bir Alışkanlıktır

Amazon S3, modern bulut mimarilerinin temel taşıdır. Bu servisin maliyetlerini etkin yönetmek, sadece faturaları düşürmekle kalmaz, aynı zamanda daha verimli, performanslı ve sürdürülebilir sistemler kurmanın da bir parçasıdır. Gördüğümüz gibi, S3 maliyetleri genellikle büyük ve tek bir hatadan çok, zamanla biriken küçük ihmallerin bir sonucudur.

Bu rehberde ele aldığımız yöntemler, yalnızca birer maliyet kısma tekniği değil, aynı zamanda iyi bir bulut yönetişim (governance) modelinin de temel prensipleridir:

Veriyi Tanıyın: Her verinin yaşam döngüsündeki değerini ve erişim sıklığını anlayarak onu doğru depolama sınıfına yerleştirin.
Veriyi Yönetin: Lifecycle kuralları ile verinin yaşam döngüsünü otomatikleştirin ve "sonsuza dek saklama" zihniyetinden uzaklaşın.
Veriye Akıllıca Erişin: Veri formatlarınızı, sorgu desenlerinizi ve transfer yöntemlerinizi en başından doğru planlayarak görünmez maliyetleri ortadan kaldırın.

Unutmayın, S3 maliyet optimizasyonu bir defalık bir proje değil, sürekli bir farkındalık ve alışkanlık gerektirir. Bu prensipleri mimarinizin bir parçası haline getirdiğinizde, S3 en güçlü ve en uygun maliyetli araçlarınızdan birine dönüşecektir.

Sizin bu konuda ne gibi tecrübeleriniz var? Kendi optimizasyon ipuçlarınızı yorumlarda paylaşarak bu rehberi birlikte daha da zenginleştirelim! 🚀