AWS'ye geri döndüm ve neden ayrıldığımı yeniden hatırladım

 (fourlightyears.blogspot.com)
18 puan yazan GN⁺ 2026-05-11 | 1 yorum | WhatsApp'ta paylaş
  • Başlangıçtan beri AWS'yi desteklemiş olsa da, *karmaşık ücretlendirme yapısı ve platform genelindeki karmaşıklık gibi biriken memnuniyetsizlikler nedeniyle artık AWS'yi sevmez hale geldiğini söylüyor
  • DynamoDB'nin yüksek maliyeti, gigabayt başına 9 sente ulaşan egress ücretleri ve iç veri hareketleri için yapılan çiftli-üçlü ücretlendirmelerin hâlâ pahalı ve anlaşılması zor olduğunu düşünüyor
  • AWS Bedrock üzerinde Claude testi ve 192 çekirdekli makine benchmark'ı için geri döndüğünde, uzun süredir pasif olan hesapta aniden etkinlik görülmesi nedeniyle güvenlik ihlali şüphesi uyarısı tetiklendi ve hesap askıya alındı
  • Hesabın askıya alınmasıyla iş için kullandığı AWS WorkMail de durdu ve ücretsiz destek planında 4 gün boyunca hesap geri yüklenmedi
  • AWS'de bıraktığı servislerin tamamını da taşımak ve tamamen ayrılmak gerektiği sonucuna vardı

İlk AWS savunuculuğundan kopuşa

  • AWS'nin SQS, S3, EC2 ve SimpleDB merkezli daha küçük bir servis olduğu dönemlerden beri güçlü bir savunucusuydu; hatta Melbourne'da ABD'den gelen AWS temsilcilerinin AWS'yi tanıttığı ilk etkinliği de organize etti
  • Bulut bilişim, girişimlerin veri merkezlerine sistem kurup işletmeden dakikalar içinde kendi bilgisayar sistemlerini çalıştırabilmesini sağlayan büyük bir değişimdi
  • Yaklaşık 15 yıl boyunca AWS'ye güçlü şekilde inandı, ancak zamanla rahatsız edici unsurlar birikti ve bir noktadan sonra artık AWS'yi sevmediğini fark etti

Zamanla biriken AWS memnuniyetsizlikleri

  • İstemci kütüphaneleri ve Python geçişi

    • AWS, ilk 6 yıl boyunca kendi istemci kütüphanelerini üretmeyip Python gibi diller için kütüphanelerin topluluk tarafından yazılmasına izin verdi; bu da ücretsiz emek harcayan programcılara yük yıkmak gibi görüldü
    • AWS'nin Python 2'den Python 3'e geçmekte aşırı yavaş kalması da büyük bir memnuniyetsizlik kaynağı oldu

  • DynamoDB ve maliyet deneyimi

    • DynamoDB kullandığı ilk gün 75 dolar fatura çıktı; sadece maliyet değil, sistemin kendisi de hayal edilebilecek en kötü biçimde tasarlanmış gibi hissettirdi

  • Veri aktarım maliyetleri ve karmaşık ücretlendirme

    • AWS'nin veri çıkış maliyeti geçmişte GB başına 20 sent idi, daha sonra GB başına 9 sente düştü, ancak hâlâ çok pahalı olduğunu düşünüyor
    • AWS içindeki sistemler arası veri hareketlerinde bile ücret alınması ve bazı durumlarda bunun çiftli-üçlü ücretlendirme gibi hissettirmesi nedeniyle, sistemi derinlemesine anlamadan ücret tuzaklarından kaçınmanın zor olduğunu söylüyor

  • IAM ve genel karmaşıklık

    • IAM (kimlik doğrulama ve erişim kontrol sistemi) son derece karmaşık bir yapı
    • AWS savunucuları kendi Linux, donanım, ağ ve güvenlik altyapısını işletmenin fazla karmaşık olduğunu, bu yüzden AWS kullanılması gerektiğini söylese de, AWS'nin neredeyse her alanının da devasa bir karmaşıklık taşıdığını ve sonuçta yine pahalı uzman ekipler gerektirdiğini düşünüyor

  • AWS Lambda ve lock-in

    • “Ölçeklenebilir” olma avantajından etkilenmiş olsa da, yavaş cold start süreleri ve büyük geliştirme karmaşıklığı sorun yarattı
    • Kendi web sunucusuna kıyasla pratikte bir avantaj sunmadığını, dezavantajlarının daha ağır bastığını ve AWS'den ayrılırken Lambda'nın sökülmesi en zor parça olduğunu; bunun da vendor lock-in'in ne kadar ciddi olduğunu gösterdiğini söylüyor

  • Açık kaynak projeleri ve hosting gelirleri

    • AWS'nin, Elasticsearch, Redis ve MongoDB gibi projeler kopyalanıp gelir elde edilmesini istemediklerini belirtmelerine rağmen OpenSearch, Valkey ve DocumentDB'yi öne sürdüğünü düşünüyor
    • Bu topluluklar ve şirketler pazarı oluşturduktan sonra AWS'nin hosting servis gelirini topladığını; bunun sonucunda SSPL, Elastic License, RSAL gibi savunmacı lisansların ve source-available modelinin yaygınlaştığını savunuyor

AWS'den ayrıldıktan sonra bıraktığı bazı servisler

  • AWS'ye olan bağlılığı koptuktan sonra her şeyi AWS dışına taşıdı ve hesaplarının neredeyse tamamını kapattı
  • Yine de o dönemde gerçekten doğru çözüm olduğunu düşündüğü bazı servisleri bıraktı
  • Domain'leri Route53'te, bazı yedekleri S3'te, iş e-postasını ise AWS WorkMail üzerinde bıraktı
    • AWS WorkMail için 12 ay içinde hizmetin sona ereceği bildirildi

AWS'ye kısa süreli dönüş nedeni

  • Son dönemde araştırma ve test amacıyla AWS'ye yeniden giriş yaptı
  • Claude/Anthropic'in AWS Bedrock üzerinde ne kadar iyi çalıştığını görmek istedi; Claude Code açısından çalışması aynıydı ama daha yavaştı ve Anthropic aboneliğinden çok daha pahalıydı
  • Elindeki en hızlı ev sistemi 20 çekirdekli CPU ve 32GB RAM'di; kodunun 192 çekirdek ve 1TB RAM bulunan bir sistemde ne kadar hızlı çalıştığını benchmark etmek istedi
  • Yaklaşık bir ay önce AWS Bedrock testi sorunsuz tamamlandı ve testten sonra her şeyi kapattı
  • AWS Bedrock gizlilik gerektiğinde faydalı olabilir, ancak maliyet nedeniyle Claude'u bir daha AWS Bedrock üzerinden kullanmayacağını söylüyor

EC2 Spot testi sırasında yaşanan hesap kısıtlaması

  • Daha sonra 192 çekirdekli bir EC2 Spot instance başlatıp yaklaşık 3 saat test yaparken AWS'den “Suspected security breach of your account” e-postası aldı
  • Uzun süredir neredeyse pasif olan hesabın aniden pahalı işlem kaynakları kullanmaya başlamasının AWS iç güvenlik alarmını tetiklemiş olabileceğini düşünüyor
  • AWS'nin kullanıcıyı korumaya çalışma niyetini ise anladığını ve olumlu karşıladığını belirtiyor
  • Ancak AWS hesabı askıya aldı ya da kısıtladı; bunun sonucunda ana iş e-posta hesabı olarak kullandığı AWS WorkMail çalışmaz hale geldi
  • Artık kimse e-posta gönderemiyor, herhangi bir AWS kaynağı oluşturulamıyor ve yapmayı planladığı test de sürdürülemiyordu

Destek süreci ve gecikme

  • AWS destek bildirimine yanıt verip hesabın hacklenmediğini, bir sorun ya da anormal ücretlendirme olmadığını bildirdi ancak yanıt alamadı
  • Premium destek kullanmadığı için AWS'nin belirttiği 24 saatlik yanıt süresini beklemek zorunda kaldı; 3 gün geçmesine rağmen destekten dönüş olmadı
  • AWS forumunda yardım istedikten sonra, e-postadaki talimatları uygulaması ve web yerine chat kullanması tavsiye edildi
  • Şifre değiştirme, erişim token'larını silme, fatura kayıtlarını kontrol etme gibi istenen tüm adımları tamamladı ve chat bağlantısı için yaklaşık 30 dakika bekledikten sonra AWS temsilcisiyle uzun bir görüşme yaptı
  • Temsilci ikna olmuş gibi görünüyordu ve ilgili iç ekibe işlemi ileteceğini söyledi, ancak 24 saat geçmesine rağmen kısıtlama kaldırılmadı
  • 8 saat sonra yapılan takipte ise sadece “bekleyin” yanıtını aldı

Yeniden doğrulanan sonuç

  • Hesabın kısıtlanmasının üzerinden 4 gün geçmesine rağmen, büyük makinelerde test etmek istediği işler hâlâ duruyordu ve bunun için yeniden “quota” talebi açmak zorunda kalma ihtimali onu endişelendiriyordu
  • İş için kullandığı e-posta sistemi hâlâ çalışmıyor
  • Bu geri dönüş deneyimi, AWS'den neden ayrıldığını yeniden doğruladı; AWS WorkMail'den çıkıp Route53 üzerindeki domain'leri de taşıyarak bir daha geri dönmemesi gerektiği sonucuna vardı
  • Geçmişte AWS'den büyük ölçüde çıkmış olmasının ne kadar doğru olduğunu gördü; ancak güvenip bıraktığı e-posta sisteminin AWS'ye dönüş sürecinde kesintiye uğraması gerçek zarara yol açtı
  • AWS bir gün hesap kısıtlamasını kaldırabilir, ancak bunun ne zaman olacağı bilinmiyor

İlgili okumalar

1 yorum

 
GN⁺ 2026-05-11
Hacker News yorumları

  • Birkaç yıl önce bir şirkete katılıp geliştirme ekibinin başına geçtim ve benden 3 ay içinde ürünü yayına almam istendi; AWS'de yeni bir makine eklemeye çalışırken fiyatın arayüzde görünmemesi yapısının kendisi bana düşmanca ve sömürücü bir ilişkinin işareti gibi göründü
    Özellik tablosu ile fiyat listesini ayrı ayrı açıp karşılaştırmak gerekiyordu ve geçmiş deneyimlerime göre böyle işaretleri görüp de ayrılmazsam sonrasının sorumluluğu bana ait olurdu
    Bu yüzden bir DigitalOcean hesabı açtım, her şeyi oraya taşıdım, CI/CD'yi de oraya dağıtacak şekilde ayarladım ve kalan iki ayda ürüne odaklanıp söz verilenden bir ay önce yayına aldım
    Eskiden nehir kıyısına bir çukur kazıp nehirle çukuru bir boruyla bağlayarak balıkların kendi kendine tuzağa girdiği bir video görmüştüm; en az dirençli yolu seçmenin ve hataları geri almamanın insanı o balıklar gibi bir sona götürdüğü izlenimi bende çok güçlü kalmıştı

    • Azure'da hoşuma giden şeylerden biri, tek tek kalemler oluştururken fiyatı aşırı şekilde göze sokmaması ama pahalı olabilecek kalemlerde genel olarak fiyatı gösteren bir denge kurması
      Şimdiye kadar fatura yüzünden şaşırmadım
    • Amazon'un mühendislik kültürü epey mühendis odaklı bir ürün kültürü olduğu için geliştiriciler çoğu zaman UX ve akıştan da sorumlu oluyor olabilir
      Eskiden AWS stajını bitirmiş junior bir geliştiriciyi işe almıştım; yaz boyunca ürün yöneticisi ya da tasarımcı desteği almadan tek başına yaptığı bir dashboard göstermişti ve gerçekten korkunç görünüyordu
      Bazı geliştiricilerin ürün/UX sezgisi iyidir ama çoğunluk UX konusunda ciddi biçimde zayıf, dolayısıyla bu kasıtlı olmaktan çok kötü bir UX kültürü de olabilir
    • Doğru yaklaşım, yayına çıkmanıza yardımcı olan bir altyapı sağlayıcısı seçmektir
      AWS iyi ama herkese uygun değil; Heroku benzeri servislerle bare metal arasında bir yerde durup bakım işini büyük ölçüde soyutlarken ölçeklenen mimari üzerinde size bir miktar kontrol de bırakıyor
      Yani AWS, bulut sağlayıcısı olarak ölçeklenmeye yardımcı olur ama en ucuz ve en basit düzeni kurmak için tasarlanmış bir araç değildir
      VC yatırımı aldıysanız ve büyümeyi öne çıkarıyorsanız AWS güvenli bir tercih olabilir; ayrıca hızlandırıcılar üzerinden gelen 2 yıllık startup kredileri sayesinde ilk 18 ay altyapı bütçesinden çok inşa etmeye odaklanabilirsiniz
      Bootstrapped ya da indie geliştiriciyseniz karşılayabileceğiniz kadar basit bir şey seçin; Hetzner veya DigitalOcean gayet yeterli olur
    • AWS'in oldukça iyi bir fiyat hesaplayıcısı ve işe yarar preset'leri var ama elbette tamamen ayrı bir uygulama
      Amazon fiyat bilgisini kolayca görme sürecinde biraz sürtünme olmasını istiyor olabilir ama asıl neden Conway yasası gibi görünüyor
      AWS hâlâ organizasyon şemasını ürün olarak dışarı veriyor
    • Bir ölçüde katılıyorum ama AWS fiyatlandırması, arayüzde görünen tek bir statik sayıdan ne ödeyeceğinizi çıkarabileceğiniz kadar basit değil
      Maliyet karşılaştırması için iki sekme açmak size zahmet geliyorsa yalnızca AWS'den değil tüm bulut sağlayıcılarından uzak durmanız daha iyi olabilir
      NAT Gateway, CloudFront, S3, auto scaling, load balancer devreye girince maliyet hesabı kesin bir bilimden çok bir sanata yaklaşıyor
      Bunları kullanmıyorsanız AWS kullanmanız için pek sebep yok; ucuz VPS sağlayıcısı çok

  • Sadece OpenSearch ve Valkey'e bakarsak, “AWS fork yaparak lisans değişikliğine yol açtı” açıklaması tamamen tersine çevrilmiş bir anlatı
    AWS ancak upstream proje lisansı değiştirdikten sonra fork yaptı ve özellikle Valkey, eski Redis çekirdek ekibindeki geliştiriciler tarafından oluşturuldu

    • Bu projelerin önemli bir kısmı, çekirdek ürünü açık kaynak olarak yayımlayıp gelişmiş servisler, kurulum, bakım ve managed hizmet sunan bir iş modeliyle çalışıyor
      AWS managed hizmet sunarak onları by-pass ettiği için bu konuda proje üreticilerinin tarafındayım
      Temelde AWS onların ekmek kapısını ellerinden aldı ve lisansı değiştirmek zorunda kaldılar
    • O lisans değişikliği de zaten AWS'nin upstream projenin emeğini sürdürülemez biçimde gelirleştirmesine verilen bir yanıttı
    • Amazon, sattığı açık kaynak yazılımın üretici ve bakımcılarına her faturalama dönemi için kullanım başına 1 cent ödese bunun ne kadar etkisi olurdu diye merak ediyorum
      Böyle bir şey açık kaynak ekipleri için kayda değer bir para olabilir; ayrıca ürünü risk almadan iyileştirmeye katkı vermelerini de teşvik edebilir
    • Redis'e ilk patch'imi gönderdiğimde bir committer mesajıma cevap vermek yerine patch'i kendi adıyla eklemişti; o günden beri birçok açık kaynak projesinin felsefesine duyduğum sempati azaldı
      Valkey başlarına gelmeyi hak etmiş olabilir
      JBoss ve Marc Fleury'yi de hâlâ hatırlıyorum
    • AWS'nin o projenin kodundan para kazanamaması için lisans değiştirildikten sonra fork yapması gayet doğal
      Meselenin özü tam olarak bu

  • Bulut hizmetleriyle self-hosting arasında birkaç kez gidip geldim
    İlk başta Vercel kullandım; proje Next.js olduğu için deneyim iyiydi ama 100 kullanıcıyı bile bulmayan bir proje için aylık 20 dolar, düşük performans gereksinimli bir servis açısından pahalı geldi
    Sonra Hetzner ve Coolify ile kendi sunucumu kurdum; Coolify açık kaynak olduğu için yalnızca VPS ücretini ödüyordum ve aylık 5 dolara bir PostgreSQL instance'ı ile web sunucusu çalıştırabiliyordum
    Ama PostgreSQL ve Redis bakımı yine de çok emek istiyordu; Docker container içinde olsalar bile servisler arasında sistem değişkenleri ve environment variable aktarmak zahmetliydi
    Bu yüzden daha sonra Cloudflare Workers, D1 Database, Cloudflare KV tarafına geçtim; Worker içinden doğrudan çağrılabildiği için environment variable taşımam gerekmiyordu
    Yerel geliştirme deneyimi de iyi, fiyatı da makul olduğu için sonrasında Cloudflare ürün ailesini kullanmaya devam ettim

    • Cloudflare'ın sundukları, benim AWS'de olmasını istediğim şeye daha çok benzemeye başladı
      Temel full-stack uygulama ve dosya dağıtımı çok daha basit ve AWS artık self-hosting'den bile çok daha zor hale geldi
    • Docker'ın PostgreSQL yönetimini gerçekten kolaylaştırıp kolaylaştırmadığını merak ediyorum
      PostgreSQL'de yaşadığım tek sorun, yeni major sürüme geçerken biraz migration işi çıkması oluyor
      Servisler arasında sistem değişkenleri ve environment variable aktarma işi Docker yüzünden daha zorlaşmış da olabilir mi diye düşünüyorum
    • Cloudflare Workers'ı sevmek istiyordum ve teknik olarak sevmek için iyi nedenler de var ama e-posta etkinleştirme gibi işler için Wrangler projesi kullanma zorunluluğu platforma kilitlenmenin bir adım öncesi gibi hissettirdi
      E-postaya izin vermek için gerekli binding'leri kurmanız gerekiyor ama bunlar konsoldan ayarlanamıyor ve Wrangler ayarladıktan sonra da görünmüyor gibiydi

  • Yazarın DynamoDB'den hoşlanmaması şaşırtıcı
    Benim en sevdiğim AWS servislerinden biri; erişilebilirliği iyi, operasyon yükü yok ve kullandığım her seferde maliyeti de oldukça düşük oldu
    Yalnız veri modelini baştan tasarlamak için zaman ayırmanız gerekiyor ve bunun için servis dokümantasyonunu okuyup anlamalısınız

    • DynamoDB, amaçlandığı şekilde kullanılırsa oldukça iyi
      Esasen iyi dayanıklılık sağlayan ve tablo boyutunu neredeyse sınırsız ölçekleyebilen nispeten basit bir key-value store olarak görmek lazım; SQL veritabanı gibi kullanmaya çalışmamak gerekir
      Prototip kodla 75 dolarlık fatura üretmenin en kolay yolu, onu JOIN ve GROUP BY yapan bir SQL veritabanı gibi ele alacak şekilde vibe coding yapmak
      Asıl parladığı yer, küçük kalıcı depolama için 1-2 tabloya ihtiyaç duyduğunuz ama tam bir RDBMS yönetmek istemediğiniz durumlar ya da çok büyük tek bir tabloyu basit sorgularla okuyacağınız ve bunu RDBMS'e uydurmak istemediğiniz senaryolar
    • DynamoDB ve Lambda gibi pek çok servisin çok belirli kullanım senaryoları var
      Neşeli bir key-value store'u veritabanı gibi kullanmamak gerek
    • Birkaç yıl önce uygulama geliştirirken yaklaşık 50 milyon kayıt, ayda yaklaşık 10 bin okuma+yazma ve 1 indeks saklayacak bir veritabanına ihtiyacım vardı
      İlk yükleme maliyeti yaklaşık 50 dolardı; sonrasında bakım maliyeti aylık 10 cent civarıydı

  • Böyle yazılar beni hep güldürüyor
    Hem doğru hem yanlışlar ve sistemler “mümkün olduğunca basit, ama bundan daha basit değil” olacak şekilde kurulmalı
    Ayrıntıları geçiştirebileceğinizi sanırsanız daha sonra daha büyük uğraşlarla karşılaşırsınız
    IAM düpedüz karmaşık
    Kullanıcılar, gruplar, roller, policy'ler, identity provider'lar ve OIDC'yi gerçekten basit uygulayan bir örnek aklıma gelmiyor
    Eskiden Kubernetes'e “fazla karmaşık” diye karşı çıkan birinin sonunda Vault, Consul, systemd, Nomad, iSCSI, Ansible, Jenkins, Puppet, Bash ve biraz tükürükle çimenden oluşan malzemelerle Kubernetes'i kötü ve geçici bir şekilde yeniden icat edip tonla hata yaptığını görmüştüm
    Bazı özelliklere ihtiyacınız olmadığını düşünürsünüz ama sonunda ihtiyaç duyarsınız
    Startup'ta tek altyapı sorumlusu olarak çalışmış biri olarak AWS'nin büyük kısmı çoğu insanın öğrenebileceği sınırlar içinde ve rezil kısımlardan genelde kaçınılabilir
    Lambda'dan hoşlanmıyorsanız kullanmayın; EKS, ECS, EC2 kullanın

    • İçeriden bakınca IAM'de binlerce seçenek var ama özü şu: “Bu rol neye erişebilir ve ne yapabilir (aksiyon + kaynak)” ile “Bu role kim erişebilir?”
      10 bin feet yükseklikten bakınca hepsi bu
      IAM'in iyi yanı, dışarıya ve içeriye aynı şekilde uygulanması
      AWS iç ekipleri diye daha fazla erişim hakları olmuyor; belirli bir servisi sunmak için müşteri hesabında bir şey yapma yetkisi alıyorlarsa bu, müşterinin IAM trust relationship içine service principal ekleyip erişim verdiği anlamına geliyor ve müşteri bunu görüp denetleyebiliyor
      Örneğin Lambda'nın bir Lambda rolü var; çünkü “biz AWS'yiz, otomatik erişiriz” diye Lambda servisinin gidip bir S3 bucket okumasını istemezsiniz
      AWS iç erişimi bile müşteri tarafından açıkça görülebilir ve kontrol edilebilir
    • “X fazla karmaşık” deyip benimsenmesini engelledikten sonra sonunda X'i kötü biçimde yeniden icat etme paterni teknoloji ve yazılım dünyasında şaşırtıcı derecede yaygın
      Bazı şeyler artık açıkça standart olsa da birçok kişi bunları gerçekten öğrenmeye zaman ayırmayı reddediyor
    • AWS self-hosting'den pahalı olabilir ama o tasarruf mühendislik maliyetinin yanında küçük kalır
      İyi bir altyapı mühendisi “para tasarruf edeceğim” diye bir OVH kurulumuna iki ay harcarsa, sadece Fargate veya RDS kullanmayarak biriktireceği paradan daha fazlasını tüketmiş olur

  • Anthropic ve OpenAI gibi yerler için de aynı şeylerin ne zaman söylenmeye başlayacağını merak ediyorum
    Şu anki AI akımı AWS'nin ilk dönemleri gibi kokuyor; herkes atladı ama sonra kolay sökülemeyen büyük bir bağımlılık biriktirdiklerini fark edecekler gibi

  • Lambda gerçekten harika ve baş ağrıtmadan hızlı iterasyon döngüsüyle dağıtım servisi işletmenin en iyi yolu olabilir
    Mutlaka microservice'e gitmeniz ya da kodu milyarlarca küçük repo'ya bölmeniz gerekmiyor
    Sunucu içi durumu istekler arasında paylaşabileceğinizi varsaymıyorsanız standart bir web sunucusunu Lambda üzerine taşıyabilirsiniz

  • O alanda çalışmadığım için AWS'ye bazen sadece kişisel eğlence projeleri için dokunuyorum ve her seferinde kâbus gibi geliyor
    Deneysel bir kart oyunu sunucusu kurmaya çalışıyorum, yeni bir finans kurumu inşa etmiyorum; ama her şey sanki yarın sonsuz ölçeklenecekmiş, bin kişilik bir organizasyon ve VC bütçesi varmış gibi görünüyor
    Neyse ki Netlify gibi servisler üstünü kapatıyor da denizi kaynatmak zorunda kalmıyorsun
    Belki bir gün gerçekten IAM, VPN ve daha adını bile bilmediğim şeyleri öğrenmem gerekecek ama o zamana kadar AWS'ye her dokunduğumda gözlerim fırlayacak gibi oluyor

    • EC2 ya da Lightsail üzerinde ham bir VPS ayağa kaldırıp public IP ekleyin ve bitirin
      Tüm enterprise kalıplarını uygulamak zorunda değilsiniz
    • Heroku'nun neredeyse 20 yıl önce çoğu web uygulamasının ihtiyaç duyduğu şeyi ne kadar isabetli yakaladığını görmek etkileyici
    • Azure ile uğraşmadıysanız AWS size tek başına kâbus gibi gelebilir
    • Cloudflare'a geçtim ve gerçekten nefes aldım
      İhtiyacım olan her şey var ve fiyatı da makul
    • AWS kişisel projeler için değil, enterprise için tasarlanıyor
      Kişisel projelerde eninde sonunda sadece maliyet önemli oluyor, bu yüzden AWS'ye anlamlı bir gelir bırakmıyorlar

  • 2023'ten beri AWS'de teknik kadrolar sistematik biçimde boşaltılıyor
    Bu ya büyük işten çıkarmalarla ya da iki tur performance improvement plan ile oldu; pre-sales ya da support tarafında çok yetenekli olan eski çalışma arkadaşlarımın çoğu artık AWS'de değil
    Buna karşılık iş geçmişi en muğlak görünen insanların kaldığını ve terfi aldığını sık sık gördüm
    AWS'yi herkes kendi riskini alarak kullanmalı; Paul Vixie gelip kurtarmayacak

  • Uzun zamandır ElastiCache özellikle sinirimi bozuyor
    RDS ölçeklenebilirlik, makul ölçüde optimize ayarlar ve uğraşmadan alınan yedekler gibi bir değer kattığı için para vermeye razı olabiliyorum
    Ama ElastiCache neredeyse hiç katma değer sunmuyor ve fiyatı sömürücü hissettiriyor
    Temel Redis kurulumuna göre daha yavaş, daha az optimize, daha az stabil; ayrıca hiç ayar yapılmamış bir Redis birden fazla DB desteklerken ElastiCache yalnızca birini destekliyor
    Ölçeklenebilirlikte bazı kazanımları var ama sıradan Redis benzer instance'larda ElastiCache'i o kadar büyük farkla geçtiği için bu kazanımların gerçekten lazım olduğu durumlar çok nadir

    • ElastiCache kesinlikle self-hosting düşünmeye değer servislerden biri
      AWS'nin API veya genel olgunluk açısından kattığı şey çok fazla değil; buna karşılık Redis/Valkey doğrudan host etmesi en basit servislerden biri