2025'te AWS: Bildiğinizi Sandığınız Ama Artık Yanlış Olan Şeyler

 (lastweekinaws.com)
8 puan yazan GN⁺ 2025-08-21 | 3 yorum | WhatsApp'ta paylaş
  • AWS'nin temel servisleri hızla evrim geçiriyor
  • EC2, S3, Lambda gibi başlıca özellikler artık geçmiştekinden farklı olarak kullanıcı beklentilerini aşan performans ve esneklik sunuyor
  • Ağ, kimlik doğrulama, maliyet tasarrufu yöntemleri gibi alanlarda da çok sayıda değişim ve optimizasyon yapıldı
  • Eski ve güncelliğini yitirmiş blog yazıları ya da bilgiler kafa karışıklığına yol açabiliyor
  • En güncel güncellemeleri ve değişen politikaları bilmek, AWS'yi verimli kullanmak için artık şart

AWS 2025: Geçmişteki Algı ile Bugünkü Gerçeklik Arasındaki Fark

  • AWS, yaklaşık 20 yıllık geçmişe sahip bir bulut platformu ve bu yüzden servislerle ilgili “genel kabul gören bilgiler” sürekli değişiyor
  • Mevcut kullanıcıların bile değişim hızını takip etmekte zorlanacağı kadar çok sayıda temel özellik iyileştirildi
  • Hâlâ eski bilgi veren çok sayıda blog yazısı bulunduğundan, yapılandırmaların gerçekte nasıl değiştiğini doğru biçimde bilmek önemli

EC2

  • EC2 instance'larının security group'ları ve IAM rolleri artık kesinti olmadan değiştirilebiliyor
  • Çalışan bir instance üzerinde EBS volume boyutunu değiştirme, bağlama/ayırma işlemleri yapılabiliyor
  • Son dönemde EC2 instance'ları zorla durdurulabiliyor veya sonlandırılabiliyor, bu da uzun timeout sürelerini bekleme ihtiyacını ortadan kaldırıyor
  • Fiziksel host'lar arasında live migration özelliği geldiği için, instance performans düşüşü uyarıları artık daha nadir
  • Instance güvenilirliği ciddi ölçüde arttı; eskisi gibi instance'ların habersiz şekilde ortadan kaybolması artık neredeyse olmuyor
  • Spot instance fiyat değişimleri kademeli hâle geldi, bu yüzden fiyatları borsa gibi gerçek zamanlı izleme ihtiyacı azaldı
  • Dedicated instance gerektiren senaryolar artık son derece nadir (HIPAA BAA için de yaklaşık 10 yıldır neredeyse gerekli değil)
  • AMI Block Public Access, yeni hesaplarda varsayılan olarak etkin durumda (2023 itibarıyla 90 günden uzun süredir public AMI sahibi olmayan hesaplara da uygulanıyor)

S3

  • S3 artık Eventually Consistent değil; Read-After-Write Consistency sağlıyor
  • Object key'in ilk bölümünü rastgeleleştirmeye gerek kalmadı; böylece veri dağılımı ve hotspot sorunları konusunda endişe azaldı
  • ACL'ler (Access Control List) artık önerilmiyor ve yeni bucket'larda varsayılan olarak kapalı geliyor
  • Yeni bucket'larda Block Public Access varsayılan olarak etkin
  • Depolanan verilerin şifrelenmesi otomatik olarak uygulanıyor
  • Glacier, S3'ün bir storage class'ı olmadan önce ayrı bir servisti; bugün ise S3 ile birleşmiş durumda. Bunun izleri daha çok faturalandırma kayıtlarında kaldı
  • Glacier restore maliyeti ve hızı, geçmişe kıyasla çok daha öngörülebilir ve ucuz hâle geldi. Eskiden anlatılan korkutucu restore maliyetleri artık gerçeği yansıtmıyor

Ağ (Networking)

  • EC2-Classic tamamen ortadan kalktı
  • Public IPv4 adresleri artık ücretsiz değil ve Elastic IP ile aynı ücret uygulanıyor
  • VPC Peering yerine Transit Gateway, VPC/resource sharing, Cloud WAN gibi daha iyi seçenekler geldi
  • VPC Lattice ve Tailscale ile karmaşık ağ sorunları daha kolay çözülebiliyor
  • CloudFront güncelleme yansıma süresi 45 dakikadan yaklaşık 5 dakikaya indi (CloudFormation dağıtımını beklerken yine de uzun gelebilir)
  • ELB Classic için cross-AZ veri aktarım ücreti vardı; ALB'de ise yalnızca LCU ücreti alınıyor. NLB'de cross-AZ ücretinin hâlâ uygulandığına dikkat etmek gerekiyor
  • Network Load Balancer için security group desteği eklendi
  • Availability Zone ID'leri hesaplar arasında farklıydı, ancak artık Resource Access Manager ile Zone ID hizalaması yapılabiliyor

Lambda

  • Lambda'nın 5 dakikalık sınırı, 15 dakikaya çıktı; ayrıca container image (Docker), EFS paylaşımlı depolama, en fazla 10 GB RAM ve /tmp 10 GB desteği eklendi
  • VPC içindeki Lambda çağrılarının hızı büyük ölçüde iyileşti
  • Cold start sorunu geçmişe göre ciddi biçimde hafifledi

EFS

  • EFS IO performans ayarı artık kapasiteden bağımsız biçimde yapılabiliyor; bu sayede alanı anlamsız verilerle doldurmaya gerek kalmıyor

EBS

  • Yeni EBS volume'leri, temel veri yoksa anında maksimum performansla kullanılabiliyor
  • Snapshot'tan oluşturulan volume'ler ilk veri okumasında yavaş olabilir; bu yüzden tüm diski bir kez okumak önerilir (daha hızlı seçenekler de sunuluyor)
  • io1 volume'leri birden fazla EC2 instance'ına aynı anda bağlanabilir, ancak pratikte yalnızca çok özel durumlarda önerilir

DynamoDB

  • Bir öğe içinde boş alanlara artık izin veriliyor
  • Performans çok daha tutarlı hâle geldi; bu yüzden eskisi gibi hot key sorunu için ayrı araçlarla sürekli izleme yapma ihtiyacı azaldı
  • Pricing değişiklikleri nedeniyle çoğu kullanıcı için On Demand tipi daha mantıklı

Maliyet Tasarrufu Seçenekleri (Cost Savings Vehicles)

  • Reserved Instances kademeli olarak kullanımdan kalkıyor; geleceğin standardı Savings Plans. Savings Plans'ın indirim oranı RI'lara göre düşmüş olsa da, esnekliği daha yüksek
  • EC2 kullanım ücretleri saniye bazında faturalandığı için, instance'ları çok kısa süre açmak da maliyet açısından verimli olabiliyor
  • Cost Anomaly Detector, beklenmedik kullanım kalıplarını yüksek doğrulukla tespit ediyor ve ücretsiz
  • Compute Optimizer, EBS dahil çeşitli kaynaklar için öneriler sunuyor ve güvenilirliği yüksek. Trusted Advisor önerileri ise hâlâ yeterince tutarlı değil

Kimlik Doğrulama (Authentication)

  • Yetkilendirme için IAM rolleri öneriliyor; IAM kullanıcıları ise daha çok legacy uygulamalar için uygun
  • IAM Identity Center, AWS SSO'nun yerini aldı ve hesap erişiminde kullanılıyor. Bu nedenle bir miktar kafa karışıklığı oluşmuş durumda
  • Root hesap için birden fazla MFA cihazı kaydedilebiliyor
  • Organizasyon altındaki üye hesaplar için ayrıca root kimlik bilgileri yapılandırmak gerekmiyor

Diğer (Miscellaneous)

  • us-east-1'in güvenilirliği ve dayanıklılığı geçmişe göre büyük ölçüde iyileşti. Eskiden sık yaşanan kesintiler artık haber olacak kadar sıra dışı olaylar hâline geldi
  • AWS servislerinde kullanımdan kaldırma (Deprecation) hâlâ nadir, ancak artış eğiliminde; bu yüzden küçük servislerde bağımlılık kararını dikkatli vermek gerekiyor
  • CloudWatch verilerindeki son noktanın tutarsızlık nedeniyle anormal derecede düşük görünmesi sorunu artık yaşanmıyor
  • Root hesaptan, organizasyon içindeki üye hesapların AWS hesapları doğrudan kapatılabiliyor

İlgili okumalar

3 yorum

 
roxie 2025-08-23

Vay canına, gerçekten çok değişmiş.
 
howudoin 2025-08-23

AWS artık tek bir hizmet seçip kullanabileceğiniz bir yapı değil.
Bir şey yapmak için oraya buraya bağlı pek çok şeyi birlikte kullanmanız gerekiyor.
Kesinlikle basit değil.
Bir girişimde kullanacaksanız, bulut maliyetinin yanı sıra DevOps personel maliyetini de karşılamanız gerekiyor.
Düzgün kurmak isterseniz, geliştirme zamanını elinizden alacak kadar iş yükü asıl işten daha büyük hale gelerek hızla artıyor.
Üstelik managed service kullanmanın daha iyi olduğu durumlar arttığı için, kod seviyesinde bile zaten platforma bağımlı hale geliyorsunuz.
 
GN⁺ 2025-08-21
Hacker News görüşleri
  • S3'teki "Block Public Access" ayarının artık yeni bucket'lara varsayılan olarak uygulanmasını görünce bunun açıkça doğru karar olduğunu düşündüm; şimdiye kadar yanlış yapılandırılmış S3 bucket'ları yüzünden çok büyük veri sızıntıları yaşandı. Ama bazen dosyaları herkese açık servis etmek için public read izni olan bir S3 bucket oluşturmak istiyorum ve her seferinde bir şeyler değiştiği için eski tarifler işe yaramıyor, en baştan yeniden öğrenmek zorunda kalıyorum.
    • "Block Public Access" ayarına dikkatle bakmanızı söylemek isterim; bu, insanların büyük hatalar yapmasını engelleyen bir tür emniyet kilidi. Çok gevşek bir bucket policy ya da ACL (eski usul ama hâlâ kullanılıyor) ayarlasanız bile, Block Public Access açıksa public access mümkün olmaz. Tersine, Block Public Access'i kapatıp çok iyi tasarlanmış bir bucket policy kullanırsanız sorun olmaz. Bucket policy kimin erişebileceğini tamamen belirler. Tabii uzun vadede policy yanlışlıkla değişebilir, beklenmedik IAM rolleri eklenebilir ya da trust policy değişebilir; bunların yönetimi önemli.
    • Ben bu tür durumlarda sık sık LLM kullanıyorum. Dokümantasyonu okutuyor, AWS resmi belgelerinin çeşitli yerlerine gömülmüş demo kodları çıkarmasını istiyorum. Sonra da istediğim özel değişiklikleri hemen soruyorum.
    • Bunu daha önce de yapmamışlar mıydı diye bir déjà vu hissi var. 10 yıl önce de herkes bucket'ları açık bırakıyordu; sanırım bu yüzden benzer önlemler alınmıştı.
    • Bu tür değişiklikler yüzünden mülakatlarda "Bu teknolojiye hakim misiniz?" sorusu çok muğlak hale geliyor. Teknoloji her ay değişiyor; hangi tarihe göre bildiğimi sormak geliyor içimden.
    • Resmî olarak öğrenmek isterseniz $250 verip bir de sertifika sınavına girmenize izin veriyorlar.
  • EC2'de instance'ı sonlandırmadan security group ya da IAM role değiştirebilmek aslında yıllardır mümkündü. Spot instance'lar eskiden teklif piyasasıydı ama şimdi teklif sistemi tamamen kalktı; böylece ani fiyat dalgalanmaları ya da yalnızca belirli kullanıcıların erişebilmesi gibi durumlar ortadan kalktı ve çok daha iyi oldu. Eskiden hotspot'tan kaçınmak için object key'lerin başını rastgele yapmak gerektiği söylenirdi ama artık buna gerek kalmadı. Ekip arkadaşlarımı ikna etmem uzun sürdü, ama zaten bunlar S3 backend darboğazıyla ilgisi olmayan aşırı küçük dosyalar saklıyordu. Lambda eskiden 5 dakika sınırına sahipti ve container image da desteklemiyordu; şimdi ise 15 dakikalık çalışma süresi, Docker image, EFS paylaşımı, 10 GB'a kadar RAM ve 10 GB /tmp depolama alanı destekliyor. Benim için bir başka aydınlanma da Python global scope'un da /tmp gibi yaşamaya devam ettiğini fark etmek oldu.
  • Glacier restore işlemlerinin artık acı verecek kadar yavaş olması gerekmiyor. Amazon tarzı tahmin edecek olursam, eski Glacier'in bir yerlerde gerçek bir Amazon deposunda çalıştığı gibi bir fikrim vardı. Veriyi istediğinizde bir görevlinin raftan taşınabilir medyayı bulup sunucuya taktığı bir düzen hayal ediyordum. Eski zaman paylaşımlı bilgisayarlardaki teyp yedekleme sistemleri gibiydi; o zamanlar teybin fiziksel olarak değiştirilmesi gerekirdi.
    • Gerçekte teyp robotları gibi otomatik ekipman kullanmış olmaları daha olası. İlgili fotoğraf örneği. İnsan yerine robot teybi bulup sürücüye takar, offset'e sarar, okur, sonra geri sarıp yerine koyar. Gecikme; teybi bulma, geri sarma ve sürücü sırası beklemeden kaynaklanır. Muhtemelen verimlilik için bir kez takılan teypteki tüm istekleri işleyip sonra çıkarıyorlardı.
    • İç işleyiş hakkında konuşamam ama Glacier tasarımını tam doğru tahmin eden birini hiç görmedim. Ben de eskiden AWS'deydim ve şunu söyleyebilirim: Glacier de diğer AWS servisleriyle aynı veri merkezlerinde çalışıyordu. Mühendislikte ve ürün yönetiminde önemli olan, müşterinin beklentilerini iyi yönetmektir. Yükleme sınırı 10 deyip 12 yüklemeye izin verirseniz müşteri sürekli 12 beklemeye başlar. Beklenti yönetimi önemlidir.
    • Sabit diskler standart olduğu için depolamanın otomatik robotlarla yürütüldüğünü düşünüyorum. İnsanlar daha çok boyut, biçim gibi standart dışı durumları işlemek için kullanılıyor.
    • Zaten bu tür ekipmanlar onlarca yıldır robotlaştırılıyor.
  • Artık AWS hesabıma giriş yapamıyorum; çünkü MFA'yı önceden ayarlamamıştım. Cihaz almak istesem bile önce giriş yapmam gerekiyor. Önceden uyarı duymuştum ama giriş yapmadan MFA cihazı talep edememek gerçekten sinir bozucu.
    • Support ekibiyle iletişime geçmek iyi olabilir.
      AWS Support ile iletişim
    • Support'un kolayca çözebileceği bir sorun gibi görünüyor.
  • Benim gibi çok kişi olduğunu düşünüyorum. Artık AWS tarzındaki o karmaşıklığı — API Gateway, serverless Lambda, IAM role ayarlamalarıyla boğuşmayı — bırakıp sadece EC2 ya da LightSail VPS, bir S3 bucket ve Route53 ile domain bağlayıp gerisini düşünmemek istiyorum.
    • Yalnızca storage + VPS kullanacaksanız, geleneksel VPS'ler AWS'den çok daha ucuz. Benim felsefem ise AWS kullanıyorsam gerçekten yoğun ve doğru biçimde kullanmak. Delege edilebilen her şeyi Amazon'a bırakıp verim ve maliyet avantajı sağlamak lazım. Step Functions, Lambda ve DynamoDB alternatiflerinden daha iyi çıktı. Ama geliştiricilerin vendor optimizasyonundan beklenenden az yararlanması üzücü.
    • Gerçekte bulutu sadeleştiren çok sayıda şirket de var; sebep genelde bölgesel hizmet kısıtları ya da öngörülebilir faturalama.
    • IAM yönetimi çok zaman alıyor; eskiden sistem yönetimine ayırdığım zamanın şimdi tamamı permission yönetimine gidiyor gibi. IAM o kadar zor ki pratikte net zarar gibi hissettiriyor. VPS ile aşırı serverless least-privilege yönetimi arasında bir tatlı nokta olmalı. Fargate bunun adayı olabilir; daha fazla taşıma yapıp denemeyi düşünüyorum.
  • AWS'nin, başka alanları yakalama telaşıyla yapay zeka tarafında dağınık biçimde her şeyi çıkarmasındansa, zaten iyi yaptığı "temel ama kritik servisler"e daha çok odaklanmasını isterim. AWS liderliğinin GenAI tarafında yönünü kaybetmiş gibi geldiğini düşünüyorum ama temel altyapıyı iyi kuruyorlar. Yapay zeka yüzünden panik halinde görünüyorlar ve müşteri açısından bu dağınıklık rahatsız edici.
    • Mevcut liderliğin yönü, altyapıyı herkesin basitçe model seçip hemen kullanabileceği hale getirmek gibi görünüyor. Kurulum karmaşası olmadan doğrudan kullanılabilen bir ortam hedefleniyor.
  • S3 bucket, VPC ile aynı bölgede olsa bile public internet üzerinden gidince NAT Gateway ücreti çıkması gerçekten saçma. Varsayılanın opt-out olması gerekirken opt-in olması muhtemelen AWS'nin bu yapıdan ek gelir elde etmesinden kaynaklanıyor. Mevcut yolu gerçekten isteyen kullanıcı çok azdır.
    • Bu, güvenliğin varsayılan olmasını temel alan bir tasarım. NAT Gateway, VPC Gateway Endpoint (S3) ya da başka internet çıkışları ayarlanmadıkça workload S3'e erişemez. Networking'in kapalı olması doğrudur; kullanıcı yolları tam anlamadan bir şey kuruyorsa sorumluluk müşteriye aittir. AWS'nin yalnızca ham Infrastructure as a Service (IaaS) araçları sunduğunu düşünmek gerekir.
    • S3 VPC Gateway Endpoint tam olarak bunun için var ve ücretsizdir.
      AWS resmi dokümanı
    • VPC, subnet, PrivateLink endpoint gibi şeyleri kurup bitirdikten sonra gerçekten saçma geliyor. PrivateLink ismini bulmaya bile epey uğraşmışlar gibi (teknik olarak anlamlı olsa da); bence bunların baştan kurulum gerektirmeden varsayılan gelmesi gerekirdi. Hatta private subnet kullanıyorsanız S3 gibi servislere erişmenin tek yolu da PrivateLink değil mi? Bu da tuhaf.
    • Bence tüm VPC endpoint'ler ücretsiz ve varsayılan açık olmalı. Kendi servis API'larını kullanmak için bile ayrıca ücret çıkması biraz fazla.
    • Bu fiyat ayrıştırması yapmak için böyle. Fiyata duyarsız müşteriler zaten umursamıyor. Duyarlı olanlar ise maliyet azaltmaya çalışıyor ve o durumda bile çoğu zaman mecburen AWS kullanmak zorunda kalıyorlar.
  • Bu yazı sayesinde rahatladım. Amazon'un büyük bir şeyi değiştirip zorunlu migration dayatmasından hep endişe ediyordum ama 2013'ten beri EC2 instance'larımı neredeyse hiç yönetmeden sorunsuz kullanıyordum. Beklenmedik bir değişiklik olmaması sevindirici.
  • Geçmişte Availability Zone'ların hesap bazında rastgele eşleniyor olması şok edici.
    • Bunun amacı yük dağılımıydı. Birçok hesap 1b gibi belirli bir AZ'yi sabit seçtiğinde, gerçek fiziksel dağılımın dengeli olması sağlanıyordu. Sonradan AZ başına canonical isim verildi; muhtemelen hotspot oluşturan hesaplarla metadata'ya ihtiyaç duyan hesaplar farklı olduğu içindi.
    • Herkes varsayılan ayarlarda us-east-1a seçerse belirli AZ'lere yığılmayı önlemek istiyorlardı diye düşünüyorum.
    • Başta yük dengeleme için iyiydi ama birden fazla hesap arasında ağ bağlantısı kurarken (PrivateLink vb.) hangi AZ'nin hangisine denk geldiğini tek tek kontrol etmek gerektiğinden kafa karıştırıcıydı. Bu yüzden hesap bazlı bire bir eşleme metodolojisi oluşturup dahili lookup tabloları bile kurduk. Sonra AWS metadata'ya zone ID ekleyerek bunu kolay sorgulanır hale getirdi.
    • Bu politika yüzünden gerçekten çok uğraştım.
  • Düzeltmek istediğim bir şey var; anlamsız bilgi kırıntılarının hepsi altüst olabilir.
    Weird Al: Everything You Know is Wrong
    Firesign Theatre: Everything You Know is Wrong