Bakın şimdi, yıllardır aynı soruyu duyup duruyoruz: “Madem her şey S3’te, neden onu klasör gibi bağlayamıyoruz?” Açık konuşayım, bu soru kötü değil. Tam tersine çok mantıklı. Çünkü bir geliştirici olarak elinizin alıştığı şey şu: dosyayı aç, düzenle, kaydet. Ama S3 size baştan beri bambaşka bir oyun oynuyordu — ve bu oyunun kurallarını kimse pek anlatmadı. 2026’da AWS’nin S3 Files hamlesiyle bu tartışma biraz daha az sinir bozucu hale geldi… ama mesele hâlâ o kadar basit değil (inanın bana)
Geçen ay, İstanbul’da bir fintech ekibinin mimari toplantısına uzaktan katıldığımda tam da bu konu döndü dolaştı önüme geldi (ki bu çoğu kişinin gözünden kaçıyor). Bir mühendis arkadaş “Abi biz EFS kullanmak yerine S3’ü mount etsek olmaz mı?” dedi. Masadaki herkes güldü. Çünkü o cümleyi ben de 2021’de kendi projemde kurmuştum — ve sonrasında günlerce şunu anlattım: nesne depolama başka şeydir, dosya sistemi başka şey. İkisi kuzen bile değil aslında.
Ve işler burada ilginçleşiyor.
Sorunun kökü: Aynı görünen üç farklı dünya
Aslında, AWS tarafında depolama deyince çoğu kişinin kafası karışıyor. Dışarıdan bakınca hepsi “veri tutuyor” gibi görünüyor. Evet, öyle görünüyor. Ama işin aslı şu ki biri kitaplık gibi çalışıyor, biri bilgisayarınızdaki disk gibi, diğeri de ofiste ortak kullanılan dolap gibi davranıyor —. Bu üçü arasındaki farkı kavramadan mimari karar vermek, nasıl desem, biraz kör uçuşa benziyor.
S3 nesne depolama; EBS blok depolama; EFS ise ağ üzerinden erişilen dosya sistemi. Hani marketten ekmek almakla fırını kiralamak arasında fark var ya — işte öyle bir ayrım var burada. Kullanım senaryosu yanlış seçilirse sistem çalışır görünür. Performans patlar, maliyet şişer ya da ekip gecenin köründe log kovalamaya başlar. Daha açık söyleyeyim, bu kadar.
Ben 2023 sonbaharında Ankara’da bir SaaS projesinde buna yakından şahit oldum. Ekibin elinde eğitim videoları ve model çıktıları vardı; herkes bunları tek yerde tutmak istiyordu. İlk refleks yine aynıydı: “S3 var ya, ne gerek var ekstra servise?” Kağıt üstünde süperdi — sonra canlı testlerde küçük yazma işlemlerinin bile akışı bozduğunu gördük, pratikte ise sonuç biraz hayal kırıklığı oldu.
S3 neden baştan beri drive gibi değildi?
S3’ün temel mantığı basit ama serttir. Nesneyi koyarsınız, sonra onu bütün halinde okursunuz ya da yeniden yüklersiniz. İçinden ufak bir satırı çekip değiştirip geri yazmak yoktur — yok, olmuyor, olmuyor işte. Bu yüzden veritabanı dump’ları, medya arşivleri ve yedekler için fena değildir; hatta baya iş görüyor.
Bir dosya sistemi ise daha farklı düşünür. Siz editörde “Ctrl+S” yaptığınızda sadece birkaç bayt değişmiş olabilir, ama altta işler daha ince yürür; kilitleme olur, blok bazlı yazma olur, eşzamanlı erişim olur… Bunlar kulağa sıkıcı geliyor biliyorum. Ama kurumsal dünyada olayın kalbi tam orasıdır, şaşırdım açıkçası bunu kaç kişi kavramadan mimari kuruyordu diye.
S3 ile ilgili en büyük yanılgı şu: “Dosya saklıyor” diye düşününce file system sanılıyor. Hayır; nesne saklıyor ve bunu oldukça inatçı biçimde yapıyor.
Bu yüzden AWS uzun süre boyunca insanlara aynı şeyi söyledi: Eğer paylaşımlı klasör istiyorsan EFS kullan; yüksek performanslı bağlı disk istiyorsan EBS kullan; geniş ölçekli arşiv gerekiyorsa S3’e git. Basit mi? Aslında evet. Tatmin edici mi? Pek sayılmaz. Bu konuyla ilgili Nylas timezone info: Terminalde Saat Karmaşasını Bitiren Komut yazımıza da göz atmanızı tavsiye ederim.
Bir dakika — bununla bitmedi.
S3 Files gelince ne değişti?
2026 Nisan’ında duyurulan S3 Files tam olarak bu can sıkıcı boşluğu doldurmaya çalışıyor gibi okunabilir. Yani AWS “tamam tamam, sizi anladık” demiş oldu diyebiliriz. Hemen heyecanlanıp eski ezberi çöpe atmayın derim ama.
Sahada böyle yeni servisler çıktığında ilk baktığım şey hep aynıdır: Bu gerçekten yeni bir ihtiyaç mı çözüyor, yoksa pazarlama cilası mı? Burada cevap bence ortada duruyor —. Ekiplerin yıllardır yaptığı geçici çözümleri azaltmaya aday bir yapıdan söz ediyoruz, özellikle veri bilimi ekiplerinde veya içerik üretim hatlarında bu tarz bağlantılı kullanım senaryoları çok can sıkıyordu, valla gerçekten sıkıyordu. Bu konuyla ilgili Butterfly CSS: 2026’da Dikkat Çeken Hafif Bir Seçenek yazımıza da göz atmanızı tavsiye ederim.
Mesela geçen hafta Berlin’de çalışan bir arkadaşım bana şunu anlattı (adı önemli değil): model eğitimi yapan job’lar çıktıları doğrudan paylaşımlı klasöre atmak istiyor, ama obje depoda bunu düzgün yapmak için ayrı araç zinciri kuruyorlardı ve süreç çorba oluyordu. Yeni yaklaşım burada işleri sadeleştiriyor olabilir. Peki bunu neden söylüyorum? Ama henüz her uç vakayı çözmüş değiliz — bunu da söylemek lazım. Bu konuyla ilgili Qwen3-TTS’te Ses Klonlama Sınırı Kalkıyor: .qvoice Dönemi yazımıza da göz atmanızı tavsiye ederim. Arzum Okka Elite: Türk Kahvesinde Gösteriş mi, Konfor mu? yazımızda bu konuya da değinmiştik.
Hangi işte hangisi? Küçük startup ile enterprise farkı
Küçük startup tarafında mesele genelde hızdır. Yani hemen ayağa kalksın yeter denir. Beş kişilik ekipte kimse gidip karmaşık storage mimarisi kurmak istemez; herkes ürünü çıkarmaya bakar (şaşırtıcı ama gerçek). Bu tip ekiplerde S3 Files gibi seçenekler ciddi rahatlık sağlar çünkü operasyon yükünü azaltır — bu kadar basit. Daha fazla bilgi için PDF Dünyasında Bir Nefes: Ücretsiz ve Limitsiz Araçlar yazımıza bakabilirsiniz.
Bak şimdi, Büyük kurumlarda tablo biraz değişiyor. Orada tek sorun teknik uygunluk değildir; uyumluluk vardır, yetki modeli vardır, denetim izi vardır, maliyet merkezi vardır… Hatta bazen ürün ekibi isterken güvenlik ekibi frene basar — ve haklıdır da. Ben bunu 2024’te kurumsal bir e-ticaret platformunda açıkça gördüm; storage kararını vermek neredeyse proje yönetiminin yarısıydı. Abartmıyorum.
| Seçenek | En iyi olduğu yer | Zayıf tarafı |
|---|---|---|
| S3 | Nesne arşivi, yedek, medya, veri gölü | Dosya sistemi hissi vermez |
| EBS | Düşük gecikmeli bağlı disk ihtiyacı | Paylaşım senaryosu sınırlıdır |
| EFS | Birden fazla sunucunun ortak klasör ihtiyacı | Maliyet ve performans dengesi dikkat ister |
| S3 Files | Sade mount deneyimi isteyen modern iş akışları | Tüm klasik file system beklentilerini birebir karşılamayabilir |
Mimaride nerede güzel durur?
Bana göre en mantıklı kullanım alanları AI/ML pipeline’ları ile medya işleme hatları olacak. Çünkü bu alanlarda insanlar sürekli ara çıktı üretiyor, dosyaları paylaşmak istiyor. Her seferinde özel entegrasyon yazmaktan bıkmış durumda oluyorlar — bunu bizzat yaşadım, acı tecrübe — valla güzel iş çıkarmışlar —. Bir de devasa log koleksiyonlarıyla uğraşan platform ekipleri var; onların gözünde zaman kazancı altın değerinde.
Kendi deneyimimden konuşuyorum, Neyse uzatmayalım; bazı senaryolarda klasik SFTP kutuları, NFS katmanları ya da geçici dosya sunucuları artık biraz yaşlandı diyebiliriz. Geçen yıl kendi not defterimde şöyle yazmışım: “Eğer her yeni proje için ‘dosya paylaşımı nasıl olacak?’ sorusuna iki gün harcıyorsak mimari eksik.” Bugün dönüp bakınca bunun karşılığını görüyorum.
- Veri bilimcilerinin ortak çalışma alanlarına hızlı erişmesi gereken projeler (bence en önemlisi)
- CI/CD sırasında artifact paylaşımı yapan sistemler
- Medya render kuyruğu olan uygulamalar
- Legacy uygulamadan modern buluta taşınan ara katmanlar
- Birden fazla compute node’un aynı dizini görmesi gereken hafif-orta ölçekli işler
Peki risk yok mu? Var tabii!
Şöyle söyleyeyim, Açık konuşayım, her yeni servis geldiğinde insanlar önce seviniyor sonra ayrıntıları okumayınca duvara tosluyor (en azından benim deneyimim böyle). Burada da durum farklı değil. Mount edilebilir olması otomatik olarak “klasik POSIX dosya sistemiyle birebir aynı davranır” anlamına gelmiyor — gelmiyor işte. Farklılıkların üstünü örterseniz ileride sürpriz yaşarsınız; garanti.
Beni en çok düşündüren kısım latency konusu oldu. İlk demo videolarında her şey pürüzsüz görünebilir ama gerçek trafik altında durum değişir. Bilhassa küçük I/O çağrılarının yoğun olduğu işlerde ne kadar iyi hissettirdiği önemli — çünkü kullanıcı hız algısını oradan kuruyor. Siz ne dersiniz? Kullanıcı gitmeden önce beklemez meselesini anlatırken hep söylerim: milisaniye bazen bütçe kadar kıymetlidir.
# Kaba seçim rehberi
if workload == "archive" or workload == "backup":
use = "S3"
elif workload == "single_instance_low_latency_disk":
use = "EBS"
elif workload == "shared_mount_for_multiple_servers":
use = "EFS"
elif workload == "simple_mount_experience_on_object_data":
use = "S3 Files"
else:
use = "Test etmeden karar verme"
print(use)
}Bende bıraktığı his ne?
Editör masasında haberi ilk gördüğümde içimden şu geçti: “AWS sonunda yıllardır gelen o garip soruya kısa cevap verecek.” Ve evet, kısmen öyle oldu. Ama dürüst olayım, ben yine de — kendi adıma konuşayım — sihirli değnek etkisi beklemiyorum. Çünkü altyapıda sihir nadiren işe yarar; net trade-off işe yarar. Bu kadar.
Daha doğrusu şöyle söyleyeyim: S3 Files bence mevcut çizgiyi bozmaz, aksine çizgiyi okunur hale getirir (eh, fena değil). Yeni başlayan ekiplerin hata yapmasını azaltabilir, kurumsalda ise standartlaştırmayı kolaylaştırabilir. Yine de bazı workload’lar için eski reçete geçerli kalacak — her şeyi tek sepete atmaya gerek yok.
Aklımdaki en sağlam çıkarım şu: bulutta doğru hizmet seçimi hâlâ mühendislik refleksi gerektiriyor. AWS sana yeni seçenek veriyor diye eski karar verme kaslarını kapatamazsın. Tam tersine — daha dikkatli olman gerekir (kendi tecrübem)
Sıkça Sorulan SorularS3 Files nedir?
S3 Files,Amazon S3 verisini daha dosya sistemi benzeri şekilde kullanmayı hedefleyen yeni yaklaşım olarak öne çıkıyor. Ama onu klasik diskin birebir aynısı sanmamak lazım. İş yüküne göre test etmek şart.
EKS veya EC2 üzerinde EFS yerine kullanılabilir mi? >Bazı paylaşımlı klasör senaryolarında evet,ama bu doğrudan “her yerde yerine geçer” demek değil. Gecikme,eşzamanlı erişim ve uygulamanızın beklentileri belirleyici olur. Küçük test ortamıyla başlayıp ölçmek en sağlıklısı.
Küçük startup için hangisi daha mantıklı?
Eğer hedefiniz hızlı ilerlemekse öncelik genelde basitlik olur. Çoğu startup için varsayılan seçim hala S3 + gerektiğinde EBS/EFS kombinasyonu olabilir. Yeni servis varsa önce operasyon yükünü azaltıyor mu ona bakarım.
Kurumsal projelerde en büyük risk ne? >Lisanslama ya da fiyatlandırmadan önce güvenlik ve uyumluluk gelir. Yetki modeli oturmayan hiçbir storage çözümü uzun süre rahat ettirmez. Denetim izi zayıfsa kağıt üstünde iyi görünen yapı sahada yorucu olur.
Kaynaklar ve İleri Okuma?>
2 ?>
20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.
İlgili Yazılar
Bu içerik işinize yaradı mı?
Benzer içerikleri kaçırmamak için beni sosyal medyada takip edin.
