AWS Amplify resmi kılavuzunu izleyince 1.100 dolarlık fatura çıktı

 (elliott-king.github.io)
1 puan yazan GN⁺ 2024-11-15 | 1 yorum | WhatsApp'ta paylaş
  • AWS Amplify’nin OpenSearch entegrasyonuna yönelik resmi kılavuzu ile deneme yaptıktan sonra, kullanım yüksek olmamasına rağmen Amazon OpenSearch Service maliyeti bir ayda $1,124.88 seviyesine çıktı
  • Maliyetin nedeni, npx ampx sandbox tarafından oluşturulan OpenSearch domain kaynağının sandbox sonlandırılıp silindikten sonra da kalması ve sonraki çalıştırmalarda yeni domain’lerin eklenerek birikmesiydi
  • Resmi yapılandırma varsayılan olarak r5.large.search instance’ı oluşturuyor; en az aylık $134 seviyesindeki bu varsayılan, boilerplate kodda ya da kılavuzda görünür şekilde belirtilmemişti
  • AWS Support, OpenSearch ve depolama için tek seferlik kredi sağladı ve tekrarını önlemek için AWS Budgets ayarlanmasını istedi
  • Amplify ile OpenSearch birlikte kullanılırken, beklenmedik ücretlendirmeden kaçınmak için sandbox silindikten sonra geride kalan kaynakları ve varsayılan instance tipini doğrudan kontrol etmek gerekiyor

Beklenmedik OpenSearch ücretlendirmesi

  • AWS Amplify’de OpenSearch entegrasyonuna yönelik resmi kılavuzu izleyerek çalıştıktan birkaç hafta sonra, AWS faturası $1,200’ın üzerine çıktı
  • Support talebinde görünen servis Amazon OpenSearch Service idi ve bir aylık toplam tutar $1,124.88 oldu
  • 2020’de de Amplify ve OpenSearch kullanma deneyimi vardı; kişisel kullanım için bunun genelde pahalı olsa da ayda yaklaşık $50 seviyesinde olduğu, ancak $1,200 düzeyinde olmadığı belirtiliyor
  • AWS Customer Support, ayrıntılı incelemenin ardından beklenmeyen maliyet için one time courtesy niteliğinde bir billing adjustment uyguladı
  • Support sürecinde OpenSearch ve depolama servisi kredileri verildi, ayrıca AWS Budgets ayarlanması da istendi
    • AWS Budgets, belirli servisler ya da AWS geneli için gelecekteki harcamaları tahmin edebilir ve bütçenin aşılması beklendiğinde bildirim gönderebilir

Resmi kılavuzun oluşturduğu kaynaklar

  • Amplify quickstart, AWS’nin sağladığı kodla TODO notları için oyuncak bir uygulama oluşturuyor ve Amplify, DynamoDB veritabanı ile kimlik doğrulamalı CRUD istekleri yaratıyor
  • Yerelde çalıştırmak da mümkün, ancak Amplify aynı zamanda erişilebilir bir domain de oluşturuyor
  • OpenSearch yapılandırma aşamasında, Amplify kaynaklarını tanımlamak için TypeScript boilerplate’i yazılıyor
    • Pipeline içinde başvurmak için DynamoDB tablosu değişkene atanıyor
    • OpenSearch instance’ı, index ve indexMapping oluşturuluyor
    • OpenSearch’teki verilere erişen sorgular yazılıyor
    • Verileri DynamoDB’den OpenSearch’e kopyalayan OpenSearchIngestionService pipeline oluşturuluyor
  • İlgili yapılandırma, frontend koduyla birlikte depodaki TypeScript/JavaScript içinde yönetiliyor
  • npx ampx sandbox, AWS servislerini ayağa kaldırıyor ve yapılandırma değişikliklerini algılayarak mevcut AWS servislerini otomatik olarak güncelliyor

Sandbox silindikten sonra da kalan domain

  • Bu yapılandırma; bir DynamoDB veritabanı, 1 OpenSearch servisi, 1 adet OSIS pipeline, IAM rolü ve başka kaynaklar içeriyor
  • Resmi boilerplate varsayılan olarak r5.large.search OpenSearch instance’ı oluşturuyor
    • Bu varsayılan, boilerplate kodda ya da kılavuzda açıkça görünmüyordu
    • r5.large.search için minimum maliyet ayda $134
  • Günlük çalışma bitip CTRL-C ile sandbox durdurulduğunda, kalıcı olarak silinsin mi diye bir istem çıkıyor ve kullanıcı Y seçebiliyor
  • Bu sırada DynamoDB siliniyor, ancak AWS konsolunda bakıldığında OpenSearch domain olduğu gibi kalıyor
  • Ertesi gün npx ampx sandbox yeniden çalıştırıldığında yeni bir OpenSearch instance’ı oluşturuluyor ve npx ampx sandbox delete de ilk instance’ı silmiyor
  • Bu süreç tekrarlandığında, aynı proje için arka planda birden fazla OpenSearch domain kalıyor ve maliyet birikiyor

Olası hata ve varsayılan instance tipi

  • Bu davranış ciddi bir footgun gibi göründü ve AWS Support bileti açıldıktan sonra da o sırada çözülmemişti
  • Bununla ilgili eski hata raporları vardı, ancak son 1 yıl içinde bir kayıt bulunamadı
  • OpenSearch domain’in v1’de düzgün silinip v2’de silinmemesi mümkün olabilir, ancak kesin neden bu değil
  • Güncel akış artık Amplify CLI ile değil, npx üzerinden çalışıyor
  • Varsayılan makine tipinin r5.large.search olması da başlı başına risk olarak kalıyor
    • Varsayılan yerine zorunlu alan olarak belirtilmesi daha iyi olabilir
    • Kılavuz r5.large.search değerini varsayılan olarak gösterse, kullanıcı bunu daha kolay fark edebilir
    • Bu varsayılan yalnızca Amplify’ye özgü değil, AWS CDK’nin bir parçası; bu yüzden yalnızca Amplify ekibinin sorumluluğu olarak görülmüyor

Amplify ve OpenSearch kullanırken dikkat edilmesi gerekenler

  • Yeni teknolojilerde geliştirme hızını artıran araçların bare metal çözümlerden daha pahalı olabileceği bekleniyordu, ancak bu maliyetin bunun da ötesine geçtiği düşünülüyor
  • AWS’nin budget konsolu kullanılarak, beklenen harcama bütçeyi aştığında uyarı alınabiliyor
  • Yalnızca OpenSearch bölümünü izlemek bile IAM hesabı, OpenSearch domain, OSIS pipeline, log group ve S3 storage oluşturduğu için çok sayıda gizli kaynak ortaya çıkıyor
  • OpenSearch, kurumsal müşterilerin sık kullandığı bir servis olduğundan daha “ileri seviye” bir servis sayılıyor ve kullanıcının AWS ekosistemini daha iyi anladığı varsayılıyor olabilir
  • geo_point bounding-box sorgu desteği nedeniyle OpenSearch kullanıldı, ancak bunun daha basit bir ürünle yapılıp yapılamayacağından emin olunmuyor
  • Güncellemeye göre AWS kılavuzu daha sonra düzeltildi; sorun ilk kez 3 ay önce gündeme getirildiğinde henüz güncellenmemişti, ancak yazı yayımlanmadan önce belge PR çalışmasının başladığı görülüyor

İlgili okumalar

1 yorum

 
GN⁺ 2024-11-15
Hacker News yorumları

  • Ödeme uyarıları şaka gibi; aslında sert harcama limitleri sunmaları gerekiyor
    Onboarding sırasında bu limiti ayarlamanın yolunu da sağlamalılar
    Açık çekler ve kazara ücretlendirme üzerine iş kurmak şüpheli ve benimseme eşiğini de yükseltiyor
    Geliştiriciler “20 dakikalık bir öğreticiyi izledim, ömür boyu biriktirdiğim para kadar fatura geldi; müşteri desteği bu seferlik sildi ama bir dahakine evi de alacak gibiydiler” türü örnekleri gördükçe AWS ürünlerini keşfetmek istemez oluyor

    • Bu yalnızca AWS’ye özgü bir sorun değil; bulut sağlayıcıları genel olarak iki tür gibi görünüyor
      AWS ya da DigitalOcean gibi riski müşteriye yıkanlar ve şüpheli “sınırsız”/“ölçüm yok” tarifeler satanlar
      İkisi de istediğim model değil
      Net ve belgelenmiş limitlerle kapasite planlamasını doğru yapabileceğim, erişilebilirlik riskini müşterinin üstlendiği ama finansal riski sağlayıcının üstlendiği bir sağlayıcı olsa keşke
      Aşırı olmadığı sürece daha yüksek sabit ücret ödemeye de razıyım
    • Sert harcama limitleri, AWS’nin ana müşterisi olan kurumsal müşteriler için neredeyse ters etki yaratır
      Kritik uygulamalarda kesinti ya da veri kaybı yaratmaktan daha ucuz olan kazara ücretlendirme çok azdır
      Yalnızca opsiyon olarak bulunsa bile muhasebe ekibi kullanımını dayatabilir ve sorun çıktığında veri kaybı olayına dönüşme riski vardır
      Bağımsız geliştiricilere ya da KOBİ’lere odaklanan bulut şirketleri için mantıklı olabilir
    • HN yorumlarında birkaç kez, AWS faturalandırma kodunun devasa bir spagetti kod olduğu ve içeride büyük değişikliklere dokunmaktan ciddi çekinildiği söylendi
      Burada öğrendiğim iç işleyiş ayrıntıları arasında epey ilginç olanlardan biri
    • AWS’ye ilgim vardı ama bu gibi nedenlerle hiçbir zaman gerçekten adım atamadım
      Pişman olmaktansa ucuz ve sabit ücretli bir VPS kullanmak daha güvenli
    • Düzenleme getirilmeli
      Amazon’dan bir şey yapmasını istemek pek anlamlı değil
      Amazon’u ve diğer şirketleri, kullanıcıların parasına saygı göstermeye yasayla zorlamak gerekiyor
      Şirketler temelde etik ya da ekonomi için iyi olanı değil, para kazandıranı yapar

  • Kıyaslayınca küçük sayılır ama ECS’ye bir uygulama dağıtmaya çalışırken 100 dolarlık fatura alınca AWS’yi bir daha kullanmamaya karar verdim
    Servisin ayağa kalkmama hatası benim uygulamamdan kaynaklanıyordu ama CloudWatch loglarının yalnızca yaklaşık %20’si görünüyordu; log alabilmek için beş kez yeniden dağıtım yapıp düzeltme yaptıktan sonra yine beş kez dağıtmam gerekti
    Her başarısız dağıtım ücretlendirildi ve yaklaşık iki gün uğraştıktan sonra hesabı silip DigitalOcean App Platform’a dağıttım
    Orada da uygulama hatası yüzünden dağıtım başarısız oldu ama loglar her seferinde geldi; 10 dakika içinde düzeltip çalıştırdım ve toplam fatura birkaç sentti
    O günden sonra seçenek varsa AWS’yi asla kullanmamaya ve önermemeye yemin ettim

    • Yalnızca Azure kullandım; ECS, Azure Container Apps’in karşılığı gibi görünüyor
      Geliştirme ve test için tüketime dayalı fiyatlandırma modeli çok ucuzdu
      Büyük iş yüklerinde nasıldır bilmiyorum ama her dağıtım için ücret almak garip
    • GCP gibi konteyneri doğrudan EC2’ye dağıtamayacağımı öğrenince AWS’den vazgeçtim
      Büyük bir projede destek daha iyi olabilir ama küçükten orta ölçeğe kadar GCP çok daha iyi
      Günümüz konteyner kullanım biçimine uyan temel yapı taşları var; BigQuery de var

  • O npx komutunun çalıştırdığı betikte bariz bir bug var gibi görünüyor
    Yazar haklı; bu bir öğreticiyse %100 en ucuz kaynakları seçmeli ve delete alt betiği çalıştırıldığında kaynakları temizlemeli
    Böyle bir şeyi çalıştırdıktan sonra geliştiricinin AWS hesabının tamamını paranoyakça tarayıp başıboş kaynak aramasını beklemek adil değil
    Bir startup böyle davransaydı “böyle şeyler olur, dikkat etmek gerekir” diye geçer miydik?
    AWS’ye neden farklı bir standart uygulandığını bilmiyorum

    • AWS’de en sinir bozucu nokta tam da bu
      Şu anda para ödediğim tüm kaynakları kolayca görmenin bir yolu yok
      Varsa bile ben bulamadım
      Anlaşılır bir genel bakış yoksa hesabım üzerinde tam kontrolüm yokmuş gibi hissediyorum
    • Yeni bir şey kullanmam gerektiğinde ilk kontrol ettiğim şey, her ay sabit bir fatura alıp alamayacağım
      Bunun üzerine çıkarsam ne olacağını ve beklenmedik ücretleri sınırlayıp sınırlayamayacağımı da inceliyorum
      Olmuyorsa başka bir şey arıyorum
      Birkaç yıl önceki Google Maps fiyatlandırma değişikliğinden sonra “ücretsiz” Google servislerine derinlemesine bağlanma konusunda da çok temkinliyiz; sonunda pahalıya patladı
    • AWS hesabında var olan tüm kaynakları basitçe listelemenin bir yolu gerçekten var mı?
      Hep servis bazında, bölge bazında kontrol etmek zorunda kaldım; sıkıcı ve hataya açık
    • Amazon açısından kolayca 1000 dolar kazanabildiği için bu bir bug değil, özellik
      Bug olduğunu düşünseler bile, kendi kâr-zararlarını doğrudan etkileyen başka işlerden çok daha düşük öncelikte olacaktır
    • Geliştiriciden paranoyakça kontrol beklemenin adil olmadığına katılıyorum
      Ama pratikte makul
      AWS’de bir şey geliştirirken AWS’ye kontrolden çıkmış düşmanca bir finans kurumu gibi davranıyorum

  • Bu tür örnekler yüzünden yıllardır AWS’i kurcalamayı erteliyorum
    Kredi kartı bilgisi istemeden insanların ücretsiz deney yapabileceği standart bir eğitim programı olmalı
    Bunun yerine, “kullanıcı hatası” diye oradan buradan binlerce dolar çekilebileceğini hesaplayan beyaz yakalılar var gibi görünüyor
    Bu tür ücretlendirmelere itiraz etmek de zor, hatta bazı durumlarda tamamen imkânsız
    Yüklü bir faturayla karşılaşabileceğine dair makul korku yüzünden AWS ortamından uzak duran tek kişi muhtemelen ben değilim

    • Böyle bir durumda AWS’in iade yapmaması çok sıra dışı; bu yüzden bunu kullanıcı hatalarından binlerce dolar sızdırmaya yönelik bir strateji olarak görmek zor
      Doğru ve ucuz eğitimler sunmaktansa iade işlemlerini yönetmenin daha az yük getirdiğine karar vermiş olmaları daha olası
      Bu davranışı haklı çıkarmaz ama AWS Textract kullanırken meşru şekilde oluşan 600 dolarlık bir faturayı bile iptal ettirdiğim olmuştu
      O sırada milyarlarca dolarlık bir şirkette çalışıyordum
    • İnsanların bu tür ödeme durumlarına düşmesinin sebebinin aslında AWS’i derinlemesine kurcalamamaları olduğunu düşünüyorum
      Fiyat listesine erişmek kolay ve her zaman anlaşılır olmasa da maliyetlerin çoğu neredeyse doğrusal artar; bu yüzden test etmek nispeten kolaydır
      AWS Amplify, CloudFormation ve çeşitli Stack türleri gibi sarmalayıcı servislerden kaçınmak iyi olur
      Temel servisleri doğrudan kullanmak yeterli
      Her servisin bir API’si var ve bir IAM kullanıcısına bağlı API anahtarı almak bir düğmeye tıklamak kadar basit
      Geri kalanı uygun önbellekleme ve maliyet modelini gelir modeline uydurmakla yönetilebilir
      Otomatik ölçeklenen servislerin maliyetini, mevcut talepten bağımsız olarak gelirin neredeyse sabit bir oranı olacak şekilde kurgulamak gerekir
      Bant genişliği AWS’te gerçek bir kâbus ama konsolda otomatik uzun vadeli indirimler sunuluyor; satış temsilcisi üzerinden de biraz daha iyi sözleşme indirimleri alınabiliyor
      Bu yüzden EC2’den kaçınmanın, EC2’nin iç bant genişliği de daha pahalı olduğundan Lambda + S3 + CloudFront’u doğrudan kullanmanın daha iyi olduğunu düşünüyorum
      Yaklaşık 3 ay sonra, kullanıcıya dönük yeni bir özellik geliştirirken hangi servis kombinasyonunun en maliyet verimli olacağını oldukça kolay tahmin edebilir hâle gelmiştim
    • A Cloud Guru / Pluralsight’ta “Cloud Playground” ya da “sandboxes” dedikleri bir özellik var
      Bu amaçla kullanılabilir olabilir ama kendim denemediğim için emin değilim
    • Bu tür kullanıcı hatalarından gelen para, AWS’in geneline bakıldığında devede kulak kalır
      Benim deneyimime göre AWS, itibar zedelenmesiyle daha büyük maliyet doğuracak sorunlardan kaçınmaya daha yakındı
      AWS ucuz değil ve bazı durumlarda, özellikle veri aktarım maliyetleri gibi kalemlerde aşırı pahalı; ama müşterileri kandırıp kazara birkaç yüz dolar daha harcatmak onların tarzı değil diye düşünüyorum

  • Tam AWS’lik bir durum bence
    Birkaç ay önce Llama 2 çalıştırmak için resmi SageMaker hızlı başlangıç rehberini izledim; gerçekten çok hızlı ayağa kalktı ama ertesi gün baktığımda günde 400 dolar gidiyordu
    Faturayı iptal ettirdim ama resmi rehberlere güvenmemek gerektiğini kesin olarak öğrenmiş oldum

    • SageMaker ürün açısından en hayal kırıklığı yaratanlardan biri ve enshittification için net bir örnek
      Ürünün ilk dönemlerinde, 2017–2018’de, kurulum oldukça sezgiseldi
      Notebook instance, inference, servis için REST API, biraz EFS ve servisin merkezinde S3 olduğu netti
      Fiyatlandırma da kapalı bir biçimdeydi, sürpriz yoktu
      Genel olarak DigitalOcean hissi veriyordu; altyapı hakkında temel bilgisi ve merakı olan bir veri bilimci bile ucuz, öngörülebilir ve basit bir yapı kurabiliyordu
      Şimdi Wrangler, Feature Store, RStudio var; notebook konsolu kullanıcı deneyimi berbat ve içeride birden çok servis verileri taşıyıp bunun ücretini kesiyor

  • AWS’in şişkin SDK’sı yerine mecburen ham HTTP istekleri göndermem gerekti; content-type: application/json başlığıyla başarısız oluyor, content-type: application/x-amz-json-1.0 ile başarılı oluyordu
    Bu tür saçmalıklar gerçekten bitsin artık

    • Kariyerim boyunca dokunduğum AWS’in neredeyse her parçasında benzer hissettim
      Belirgin bir getirisi olmadan aşırı şişkin, aşırı karmaşık ya da tuhaf özel uygulamalarla dolu
    • Açıkçası bu, iç detayların dışarı sızması
      Çünkü içeride uygulamaların çoğu eski Coral framework’ünü kullanıyor ve girdi, çıktı ve hata biçimleri iyi tanımlanmış olan bu JSON formatını kullanıyor

  • Tüm resmi AWS rehberleri mümkün olduğunca çok AWS servisi kullandıracak şekilde tasarlanmış; bu da harcama riskini aynı ölçüde artırıyor
    AWS’in önerdiği şeylere, yani GUI varsayılanlarına, CLI araçlarına, rehberlere ve önerilen mimarilere son derece eleştirel bakmak gerekiyor
    Şirketlerde AWS’i maliyet verimli ve düşük riskli kullanmaları için meslektaşları yönlendiren yüksek maaşlı pozisyonların olmasının bir nedeni var

    • Aynen
      Küçük dağıtımlarda veya testlerde en pahalı kısım neredeyse her zaman yan unsurlar ya da daha basit alternatifler yerine önerilen en yeni servisler oluyor

  • geo_point bounding box sorgusu yüzünden OpenSearch kullanıyorsan, PostgreSQL + PostGIS nasıl olur?
    https://postgis.net/docs/using_postgis_query.html

  • Bu kadar sürtünmesiz kurulum, sezgiselliği düşük kullanıcı deneyimi ve arayüz, kredi kartı kaydına karşı düşük temkin, AWS Batch + Lambda + EC2 gibi servisler arası paket hâlinde ücretlendirme bence iş modelinin bir parçası
    Nasıl ifade edeceğimi bilmiyorum ama giriş ücreti ödedikten sonra tüm oyuncaklara, hatta tuvalete bile ayrı para verdiğin modern bir lunaparka benziyor

    • Ben de öyle hissediyorum
      Bulut ücretlendirme modeli, “esneklik” ve “özelleştirme” adı altında sorumluluğu kullanıcıya yıkıyor
      Bir araç kiralama şirketinin motor eksantrik mili dönüşü, lastik dönüşü, silecek çalışması, koltuk ısıtma süresi gibi her parçayı milisaniye bazında ücretlendirdiğini ve her kalem için bildirim ayarlayabildiğiniz için müşterinin kullanımını ve bütçesini “kontrol ettiğini” söylediğini hayal etmek yeterli
      Varsayılan hâliyle kullanıcıya düşman ve tehlikeli bir maliyet modeli