S3 hakkında bilmenizi istemedikleri şeyler

 (blog.plerion.com)
2 puan yazan GN⁺ 2024-06-02 | 1 yorum | WhatsApp'ta paylaş
  • AWS veri sızıntısı risklerinde S3 bucket’larına yetkisiz erişim tekrar tekrar karşımıza çıkar; eski API tasarımı ve istisnai davranışlar nedeniyle basit bir “açık/kapalı” değerlendirmesi yapmak zordur
  • Birçok S3 işlemi genel AWS endpoint’i yerine bucket URL’sinin kendisine çağrı yapılarak gerçekleştirilir; hatalı bucket politikalarında kimlik doğrulamasız curl istekleriyle bile riskli işlemler mümkün olabilir
  • Yalnızca s3:ListBucket’ı engellemek güvenli sayılmak için yeterli değildir; ListBucketVersions, ListMultipartUploads, fetch-owner gibi yollar nesne anahtarlarını ve hesap tanımlayıcılarını açığa çıkarabilir
  • Yükleyici storage class, etiketler, Object Lock ve bazı yönlendirmeyle ilgili header’lar gibi nesne özelliklerini etkileyebilir; bu yüzden IAM koşulları ve yaşam döngüsü politikaları gibi ek kontroller gerekir
  • Yalnızca ACL ve public access block ayarlarına bakarak özel olduğunu varsayarsanız bazı yolları kaçırabilirsiniz; CloudFront dağıtımı veya Cognito identity pool üzerinden internet kullanıcıları S3 nesnelerine erişebilir

Eski S3 API tasarımı ve anonim çağrılar

  • S3, AWS’nin ilk hizmetlerinden biri olduğu için sağlam ve iyi test edilmiştir; ancak standartlaşmış tasarım kalıplarından önceki izler nedeniyle diğer AWS hizmetlerinden farklı bir API biçimine sahiptir
  • Bazı S3 API’leri s3.us-east-2.amazonaws.com gibi genel endpoint’leri kullanır, ancak birçok işlem doğrudan hedef bucket URL’sine istek göndermeyi gerektirir
    • Bucket listesini alma örneği, Host: [bucketname].s3.amazonaws.com biçiminde GET / isteğidir
    • Bucket etiketlerini alma da ilgili bucket host’una GET /?tagging gönderir
  • EC2 veya DynamoDB gibi birçok AWS hizmetinde genel endpoint kullanmak ve hedef kaynağı HTTP header’ı ya da parametre olarak iletmek yaygındır
  • S3 bucket’ları hem public access’i hem de kimlik doğrulamalı erişimi desteklediğinden, hangi API işlemlerinin kimlik doğrulaması olmadan yapılabildiği her zaman net değildir
  • Örnek bir bucket politikası, bucket kaynağı için Principal: "*" ve Action: "s3:*" izni verirse, kimlik doğrulaması olmayan isteklerle bile bucket silinebilir
  • Bazı işlemler anonim istekleri desteklemez ve s3:GetBucketOwnershipControls does not support Anonymous requests! gibi bir hata döner
  • Anonim API istekleri CloudTrail’de anonymous hesabı olarak kaydedilir
    • İstek kimliği doğrulanmamışsa bucket’ı kimin sildiğini, şifreleme ayarlarını veya logging durumunu kimin sorguladığını belirleyemezsiniz
  • /?logging, /?tagging, /?encryption gibi yollar tarayıcıda da test edilebilir
  • GetObjectTorrent gibi belgeleri hâlâ duran, ancak artık çalıştırılamayan işlemler de vardır

Yalnızca ListBucket’ı engellemek nesne anahtarlarının sızmasını önlemeye yetmez

  • Bir S3 nesnesini indirmek için her nesnenin anahtarı gerekir; anahtar, dosya yolu gibi kullanılır
  • Kök bucket’a yapılan GET isteği koşullara bağlı olarak bucket içeriğini döndürebilir; bu yüzden s3:ListBucket’ı reddetmek yaygın bir savunma gibi görünür
  • public-read ACL ile s3:ListBucket reddetme politikasını birlikte kullansanız bile nesne anahtarlarını elde etmenin yolları kalır
    • GET /?versions, yani s3:ListBucketVersions, bucket içindeki nesne sürümlerinin metaverisini döndürür
    • GET /?uploads, yani s3:ListMultipartUploads, devam eden multipart upload listesini döndürür
  • HeadBucket belgelerinde bucket’ın varlığını ve erişim yetkisini kontrol etmeye dair ifadeler vardır; ancak pratikte ListBucket işlemini yapma yetkisi olup olmadığını kontrol eder
  • Yalnızca ListBucket’ın reddedilip reddedilmediğini doğrularsanız S3 nesne anahtarlarının açığa çıkma olasılığını kaçırabilirsiniz

Tamamlanmamış multipart upload’ların maliyeti ve sızıntısı

  • Multipart upload, create-multipart-upload ile başlatılır ve parçalar upload-part ile yüklenir
  • Tamamlanmamış multipart upload’ları web konsolunda görmek kolay değildir; /?uploads veya aws s3api list-multipart-uploads --bucket [bucket-name] ile kontrol edilebilir
  • Tamamlama isteği başarıyla gönderilmezse Amazon S3 parçaları birleştirmez ve nesneyi de oluşturmaz
    • Yüklenen parçalar multipart upload tamamlanana veya iptal edilene kadar hesapta kalır
    • Saklanan parçalar için S3 depolama maliyeti oluşur
  • Tamamlanmadan önce nesnenin parçalarını indirmenin bir yolunu bulamadım, ancak silmek mümkündür
  • AWS, belirli bir gün sayısından sonra tamamlanmamış upload’ları silen yaşam döngüsü kuralı uygulanmasını önerir
  • /?uploads ile tamamlanmamış multipart upload’ları listelediğinizde, upload’ı başlatan principal’ın ARN’i döner
    • Hesap ID’si ve ARN gibi tanımlayıcıları hassas görmeyen bir bakış açısı için bu sorun olmayabilir
    • Saldırganlar için faydalı olabilecek tanımlayıcıların açığa çıkmasını istemiyorsanız bunu bir sızıntı olarak görebilirsiniz

ACL ve e-posta tabanlı hesap doğrulama

  • S3 ACL belgelerinde, AWS hesaplarının root kullanıcı e-postasıyla tanımlandığı dönemden kalma izler bulunur
  • PutBucketACL işlemi grantee’yi e-posta adresiyle belirtebilir
    • Type: AmazonCustomerByEmail ve EmailAddress kullanılır
  • Belirtilen e-postaya bağlı bir AWS hesabı yoksa UnresolvableGrantByEmailAddress hatası oluşur
    • Hata mesajı “sağlanan e-posta adresi kayıtlardaki hiçbir hesapla eşleşmiyor” biçimindedir
  • Bu davranış nedeniyle belirli bir e-posta adresinin kayıtlı bir AWS hesabına sahip olup olmadığı doğrulanabilir

Yükleyicinin seçebileceği storage class ve nesne metaverisi

  • S3’ün storage class’ı bucket’a değil, nesneye uygulanır
  • Bucket düzeyinde istenen storage class’ı sabitleyen bir ayar yoktur; upload yapan taraf nesnenin storage class’ını belirleyebilir
    • Örnek: aws s3 cp "my.txt" "s3://mybucket/myobject.txt" --storage-class [CLASS]
  • Yükleyici, önceden tanımlanmış liste içinden, bucket sahibinin üstleneceği GB başına depolama ve erişim maliyetlerini etkileyebilir
  • IAM politikasında s3:x-amz-storage-class koşul anahtarı kullanılırsa izin verilen storage class’lar sınırlandırılabilir
    • Örnek politika, s3:PutObject için yalnızca STANDARD’a izin verir
  • Yaşam döngüsü politikası ayarlanırsa belirli bir süreden sonra tüm nesneler belirli bir storage class’a taşınabilir
  • Pre-signed URL kullanan upload’larda AWS Signature Version 4, X-Amz- ile başlayan tüm header’ların imzalanmasını gerektirir
    • Storage class, x-amz-storage-class header’ı ile belirtilir
    • Uygulama çok hatalı uygulanmadıysa bunu hemen manipüle etmenin belirgin bir yolu yoktur

Etiketler, Object Lock ve yönlendirme de yükleyicinin etki alanındadır

  • S3 nesneleriyle ilgili birçok özellik yükleyici tarafından kontrol edilir
  • Nesne etiketleri upload sırasında belirtilebilir
    • Örnek: --tagging "AllYourTags=AreBelong&To=Us"
  • Etiket değerlerine göre otomasyon yapan sistemler, yükleyicinin oluşturduğu etiket değerlerinden etkilenebilir
  • Object Lock, bucket’ta object locking etkinse nesne saklama ve legal hold ayarlamaya olanak tanır
    • Örnek komut --object-lock-retain-until-date "2099-01-01T00:00:00+0000", --object-lock-legal-hold-status "ON", --object-lock-mode "COMPLIANCE" kullanır
  • Statik web sitesi barındırma etkin olan bucket’larda, yüklenen dosya ayarları kullanılarak open redirect yapılabilir
  • PutObject’in desteklediği tüm header listesine de dikkat edilmelidir
    • Pre-signed URL’lerde sınırlamalar vardır
    • Cognito identity ve IAM politikalarına dayanan yapılandırmalarda, kimliği doğrulanmış Cognito bağlamıyla istek imzalanabilir

Bucket sahibi ve hesap tanımlayıcılarının açığa çıkması

  • Belirli bir hesap ID’sinin erişilebilir bir bucket’ın sahibi olup olmadığını kontrol etmek için ListBucket isteğine x-amz-expected-bucket-owner header’ı eklenebilir
    • Yanlış hesap ID’si girilirse AccessDenied döner
    • Doğru hesap ID’si girilir ve çağıranın ListBucket yetkisi varsa normal yanıt döner
  • ListBucket API’sinin fetch-owner=true parametresi kullanıldığında yanıttaki her anahtara Owner öğesi eklenir
  • Owner içindeki ID, AWS belgelerinde canonical user ID olarak adlandırılan 64 karakterlik onaltılık bir dizgedir
    • AWS hesap ID’sinin gizlenmiş bir biçimidir
  • Canonical user ID, IAM politikasının Principal alanına CanonicalUser olarak eklenip kaydedildikten sonra sayfa yenilenirse AWS hesap ID’si olarak çözümlenir
  • ListBucketVersions ve ListMultipartUploads da fetch-owner olmadan benzer şekilde davranır

S3 nesne anahtarları dosya adı gibi görünür ama farklı çalışır

  • S3 nesne anahtarları büyük/küçük harfe duyarlıdır
  • Adları aynı görünse bile büyük/küçük harf farklıysa birden fazla nesne yüklenebilir
  • Bir uygulama S3 nesne anahtarlarını büyük/küçük harfe duyarsız dosya adları gibi ele alırsa sorunlar ortaya çıkabilir
    • Örnek uygulama kullanıcı parolalarını S3 dosyasında saklar ve dosya adını kullanıcı adı olarak kullanır
    • Kayıt sırasında yalnızca dosyanın var olup olmadığını kontrol eder; parola değiştirirken kullanıcı adını küçük harfe çevirip dosyaya yazar
    • jeff zaten var olsa bile JEFF kaydı yapılabilir; JEFF kullanıcısı parola değiştirerek jeff’in dosyasının üzerine yazabilir
  • S3 nesne anahtarlarında herhangi bir UTF-8 karakter kullanılabilir
    • Belirli karakterler bazı uygulamalar ve protokollerde sorun çıkarabilir
    • Boşluk, eğik çizgi ve yüzde karakteri gibi karakterler de nesne anahtarında geçerlidir

“Özel bucket” gibi görünse de erişim yolları kalabilir

  • ACL kapalı, kaynak politikası dar ayarlanmış ve block public access etkin olsa bile bucket herkese açık şekilde erişilebilir olabilir
  • En yaygın yol Amazon CloudFront dağıtımıdır
    • S3 bucket’ın önüne CDN konduğunda genellikle amaç internet üzerinden içerik sunmaktır
    • Güvenlik araçları, bucket kaynak politikası CloudFront ile sınırlandırılmışsa bunu public olarak değerlendirmeyebilir
  • Örnekte get-bucket-policy-status, IsPublic: false döndürür
    • Bucket’a doğrudan istek atıldığında AccessDenied döner
    • Aynı istek CloudFront dağıtım domain’ine gönderildiğinde nesne içeriği döner
  • Cognito identity pool da sınırlı kaynak politikasına sahip bucket’ları açığa çıkarabilir
    • Cognito, başarılı girişten sonra önceden ayarlanmış rolün geçici AWS kimlik bilgilerini sağlar
    • Bu rolde s3:ListBucket ve s3:GetObject yetkileri varsa kullanıcı S3 API’yi çağırabilir
  • Public access kapsamına girebilecek iki Cognito ayarı vardır
    • Self-registration: İnternet kullanıcıları uygulamaya kaydolup giriş yapabiliyorsa bu fiilen public access olur
    • Guest access: Kimliği doğrulanmamış kullanıcılara benzersiz tanımlayıcı ve AWS kimlik bilgileri sağlar
  • Guest access örneği, get-id ile IdentityId alıp get-credentials-for-identity ile geçici kimlik bilgileri aldıktan sonra ilgili profille aws s3 ls çalıştırma akışıdır
  • CloudFront ve Cognito identity pool, internette gerçekten sık kullanılan ancak güvenlik araçlarında nadiren gösterilen public access yollarıdır

İlgili okumalar

1 yorum

 
GN⁺ 2024-06-02
Hacker News yorumları

  • İlginç birçok nokta var, ancak dosya sisteminin büyük/küçük harfe duyarlı olmasını bir şikâyet konusu olarak görmeye katılmak zor
    Zaten böyle olması gerektiğini düşünüyorum; macOS’un böyle yapmaması asıl can sıkıcı olan

    • “Zaten böyle olması gerekir” kısmının neden öyle olduğunu bilmiyorum. Windows da büyük/küçük harfe duyarlı değil; dolayısıyla S3 neredeyse evrensel bir teamülü bozuyor da değil
      Dosya adlarında büyük/küçük harf duyarlılığı teknik olmayan kullanıcılar için de şaşırtıcı gelebilir. Biri “Book Draft 1.docx” gönderdiğini söylediğinde posta kutusunda “Book draft 1.docx” varsa, normalde “Sanırım farklı bir dosya göndermişsiniz?” demezsiniz
      Yazıda da büyük/küçük harf çoğu zaman anlamı değiştirmez. “Hi, how are you?” ile “hi, how are you?” aynı anlama gelir; büyük harfin anlamı değiştirdiği durumlar da özel adlarla cins adları ayırmak gibi şeylerdir ki dosya adlarında bu nadiren önem verilen bir konudur
    • Teknik uygulama açısından 'A' ile 'a'nın farklı karakterler olduğu ASCII, Unicode vb. içinde iyi yerleşmiş bir durum
      Kişisel tercihler bir yana, bir geliştiricinin ya da sistem yöneticisinin dosya sisteminin büyük/küçük harfe duyarlı olmasına şaşırmasını veya sinirlenmesini anlamak zor. Gerekirse geliştirici bunu arama sonuçlarında olduğu gibi son kullanıcı için soyutlayabilir
    • Yazının sahibiyim. Bu bir şikâyetten çok gözlem. Mutlak olarak iyi/kötü meselesi değil; uygulama tasarlarken dikkate alınması gereken bir unsur
    • Dosya adlarının büyük/küçük harfe duyarlı olmasının tam olarak ne fayda sağladığını bilmiyorum. Tersi olsaydı en başta ortaya çıkamayacak birçok yaygın hataya kapı açıyor
      Kodlamada olduğu gibi kod stilini zorlayıp okunabilirliğe yardımcı olan bir şey de değil. Programlamada bile IDE’ler değişken adı yazım hatalarını yakalayacak kadar akıllı hale gelmeden önce bu bir hata kaynağı olabiliyordu. Pascal’ın C’ye kıyasla güzel yanlarından biri büyük/küçük harfi dert etmemesiydi
    • macOS büyük/küçük harfi korur. Kişisel olarak iki tarafın avantajlarını iyi harmanlayan bir yöntem olduğunu düşünüyorum
      Dosya adını istediğiniz stilde yazabilirsiniz ve o yazım korunur; ancak ararken veya işlerken o stili tam olarak hatırlamanız gerekmez. Çünkü arama büyük/küçük harfe duyarlı değildir

  • Büyük/küçük harf duyarlılığı kolay sayılır; daha az sezgisel olan şey S3 yollarının sahte olmasıdır
    S3 “/builds/1/installer.exe” yüklemesini kabul eder ve /builds içindeki listeyi de gösterir, ama gerçekte adına '/' dahil olan '/builds/1/installer.exe' adlı tek bir key yüklemiş olursunuz
    Bu yüzden “/builds/1//installer.exe” ve “/builds//1/installer.exe” de yüklenebilir ve tamamen farklı dosyalardır. Bunlar yalnızca key adıdır; gerçek dizin yoktur

    • Doğru. Ancak yeni S3 Directory buckets [1] kullanırsanız bu bir istisna; bu da aslında bütünü daha da kafa karıştırıcı hale getiriyor
      [1] https://docs.aws.amazon.com/AmazonS3/latest/userguide/direct...
    • "/" karakterinin yalnızca varsayılan yol ayırıcı karakter olduğunu da kaçırmamak gerekir. Dosya adında "/" gerekiyorsa ayırıcı olarak istediğiniz başka bir karakteri kullanabilirsiniz: https://docs.aws.amazon.com/AmazonS3/latest/API/API_ListObje...
    • Yolları standart bir biçimde yorumlamak, örneğin yinelenen / karakterlerini birleştirmek dışında, gerçek dizinlerin öneklerden özünde ne farkı olduğunu bilmiyorum
    • Önek yaklaşımı gerçekten çok fazla bug üretir. AWS’nin neden böyle yaptığını anlıyorum ve aslında akıllıca bir yaklaşım, ama yine de birçok geliştirici buna takılıyor
      Bu yıl bizim üretim sistemimiz de tuhaf bir bug yaşadı ve ancak 5 kişi uğraşınca bulabildik. Sebep, adı birebir “/” olan bir nesneydi; yazılım bunu dosya değil yol gibi ele almaya çalışmıştı

  • S3’e ya da başka AWS hizmetlerine güvenerek kullanmak zor. Sezgisel hiçbir şey yok, çalışan parça sayısı çok fazla, okunması gereken doküman da çok fazla
    Bunu yapsanız bile, kaynak yazıda olduğu gibi yanlışlıkla her şeyi dünyaya açık hale getirebilirsiniz. Ben bunun yerine Hetzner Storage Boxes veya DigitalOcean Spaces gibi gerçekten basit hizmetleri kullanırım

    • DigitalOcean Spaces’i seviyorum ama orada da can sıkıcı tuhaflıklar var
      Yakın zamanda birkaç MB’tan büyük video dosyalarını pipe ile yükleyince dönen Location içinde https:// kısmını atladığını fark ettim. Bu yüzden her dosya yüklemesinde Location’ın https ile başlayıp başlamadığını kontrol etmek, yoksa eklemek gerekiyor
      Elbette S3 Node istemcisi GitHub issue’sunda “DigitalOcean bug’ı gibi görünüyor” deniyor; DigitalOcean forumunda ise “S3 Node istemcisi bug’ı gibi görünüyor” deniyor
    • DigitalOcean’ın gizli değerleri ele alış biçimi herkesi ürkütecek cinsten. Container Registry kullanıp K8S’in otomatik erişmesini ayarlarsanız, o hizmetin Spaces’a tam erişimi olan bir secret oluşturduğunu biliyor muydunuz?
    • Birkaç yıl bulut geliştirmeye ara verip ağırlıklı olarak istemci tarafında çalıştıktan sonra yakın zamanda geri döndüm; bu süre içinde biriken karmaşıklığa ve public cloud’da kurşun geçirmez çözümler oluşturmak için gereken bilişsel yüke şaşırdım
      Başta bazı özel durumlara yardımcı olmak için tasarlanmış sayısız özellik ve tuhaflık artık genel protokolün parçası haline gelmiş. İş açısından kimsenin geri dönüp vazgeçmemesini sağlamaya çalışınca böyle olmuş gibi görünüyor

  • On milyarlarca nesneyi silerken de dikkatli olmak gerekir. Silme API'sini doğrudan çağırmak pahalıya mal olabilir
    Bunun yerine joker karakterler ya da tüm bucket için sona erme zamanını now olarak ayarlayan yaşam döngüsü kuralını ücretsiz tanımlayabilirsiniz. Böylece depolama ücretlendirmesi hemen durur ve AWS silme işlemini kendi halleder

    • Kesin konuşmak gerekirse silme çağrıları ücretsizdir; maliyetli olan, nesneleri almak için yapılan listeleme çağrılarıdır. Teorik olarak hangi nesnelerin var olduğunu başka bir kaynaktan biliyorsanız ücretsizdir
    • Yaşam döngüsü kuralının etkisi anlık değildir. Günde bir kez çalışan toplu iş olarak uygulandığı için kaldırma hemen gerçekleşmez
    • Çünkü AWS gerçek silme zamanını seçebilir. Metadata'da nesnenin silindiği işaretlenir, AWS de silmeyi kullanımın düşük olduğu saatlerde işleyebilir
      S3 API sunucusunun saniyedeki istek sayısıyla dövülmesini de önleyebilir

  • Başarısız multipart upload'ların görünmeden kalması ve açıkça yaşam döngüsü ayarı yapmazsanız depolama maliyeti bile çıkarması gerçekten kötü
    “Simple”daki S'nin sadelik anlamına geldiğini sanıyordum

    • Evet, bu kötü. O dönemde S3 GM'i olan ahenry@'yi suçlayabilirsiniz
      Benim önerim, tamamlanmamış upload'ların parçalarının son etkinlikten sonra yalnızca 24 saat kalması ve bu süre boyunca depolama ücreti de alınmamasıydı. ahenry@ bunu reddetti
    • Bu sorun yüzünden binlerce dolar kaybettik
      Çok eski bir sunucuda, neredeyse 10 yıl boyunca her gece multipart upload başlatan bir cron betiği çalışıyordu. Yedekleri bir bucket'a göndermek içindi; o bucket aynı zamanda kullanıcıların yüklediği içerikleri de sakladığından her gün biraz büyümesi normal görünüyordu
      Betik “çalışmıyor” durumdaydı, bu yüzden yedek verilerine güvenmiyorduk; S3'te de dosyalar görünmüyordu ve bucket boyutu düzenli ama aşırı olmayan şekilde artıyordu. Fakat bu ilkbaharda baktığımızda neredeyse 3 TB tamamlanmamış multipart upload sakladığını gördük
      Elbette bu anekdotun kötü uygulamalarla dolu olduğunu biliyorum
    • O S, maliyetleri fırlatmanın basit yolundaki S
    • “Simple” adı, alternatifin diskli bir sunucu sürüsünü bizzat yönetmek olduğu dönemde verildi. Zaman her şeyi değiştiriyor
    • Ben de depolama maliyeti mayınına bastım. Neyse ki birkaç centti ama konsolun ilgili bilgileri gösterme biçimi o kadar berbat ki epey sinirleniyorum

  • Büyük/küçük harf duyarlı/duyarsız tartışmaları genel olarak fazla İngilizce merkezli geliyor
    Başka bir deyişle, özellikle IT'de dil konulu tartışmalar çoğu zaman aşırı İngilizce merkezli oluyor

    • İngilizce merkezli olmasının aksine iyi bir şey olduğunu düşünüyorum. Çünkü ASCII, Unicode'a göre çok daha kolay ele alınıyordu
      Ana dili İngilizce olmayan biri olarak söyleyeyim: programlamada zaten fazlasıyla kavram ve unsur var. Buna 101 farklı dili daha düşünerek karmaşıklık eklememek daha iyi
      Unicode ve zaman dilimleri, programlamada daha fazla dil ve kültürü hesaba katmaya çalışan başlıca unsurlar; sonuçta İngilizce konuşmayan programcılar dahil herkes için en büyük acıyı yaratıyorlar
      Kendi ana dilimde program yazmak istemiyorum. Bunun bedeli, programlama yaparken tüm büyük dilleri hesaba katmak olacaksa hiç istemem. IT tartışmalarının İngilizce merkezli olması sorun değil. Çeşitlilik karmaşıklıktır; İngilizce de birinin sahip olduğu bir dil değil, insanların iletişim için kullandığı bir araçtır
      O ortak dil sayesinde Hindistan, Çin, Japonya, Güney Amerika ve başka pek çok yerdeki insana düşüncelerimi ifade edebiliyorum. İngilizce konuşmaya karar verdikleri anda onlar da İngilizceye sahip olur. IT'ye çeşitlilik siyasetini taşımaya gerek yok; bunu teknik düzlemde bırakmak daha iyi
    • İngilizce dışı kültürlerden söz açılmışken, Japoncada büyük/küçük harfe duyarsız sistemler hiragana ve katakana arasında ayrım yapıyor mu?
      Bir bakıma bu iki hece yazısı büyük/küçük harfli alfabe gibi hissettiriyor

  • Birkaç nokta daha var
    Multipart upload, instance kimlik bilgilerine sahip birden fazla makineden yapılamaz. Çünkü principal farklı olduğundan birbirlerinin multipart upload’larına erişemezler. Birden fazla makinede tek bir multipart upload’ı birleştirmek istiyorsanız gerçek bir IAM kullanıcısı gerekir
    LIST istekleri yalnızca yavaş değil, büyük ölçekte çok pahalıdır. “bucket inventory” gibi geçici çözümler var ama ne kullanışlı ne de ucuz
    Bucket oluşturma içeride DNS kullandığı için yazma sonrası okuma tutarlılığı yoktur. Bu yüzden bucket’ı oluşturduktan hemen sonra erişemeyebilir ya da değişikliğin yayılması için yeterince beklemeden yeni oluşturduğunuz bucket’ı silemeyebilirsiniz. Bkz. https://github.com/julik/talks/blob/master/euruko-2019-no-su...
    Aynı anda “foo” adlı bir nesne ve “foo/bar” adlı bir nesne oluşturabilirsiniz. Böyle olunca dosyanın dizinin üstüne yazdığı bir yapı oluşur ve bucket verileri dosya sistemi yapısına taşınamaz hale gelir
    S3 büyük/küçük harfe duyarlı olduğu için dosya sistemi yapısına taşınması mümkün olmayan nesneler oluşturabilirsiniz. Rails dosya deposu büyük/küçük harfe duyarlı depolama varsaydığı için macOS’ta ciddi şekilde bozulmuştu; sonrasında tanımlayıcıları her zaman küçük harfle kullanacak şekilde düzeltildi
    Çoğu S3 ayarı GET’e izin verir ama HEAD’e izin vermez. Bu, nesnenin var olup olmadığının keşfedilmesini engellemek için kullanılan bir yöntem gibi görünüyor ama emin değilim. Her durumda, HEAD isteğiyle nesne boyutunu kontrol eden cache dostu akış, özellikle pre-signed URL’lerde çalışmaz. Bunun yerine Range’i çok küçük tutan bir GET, örneğin yalnızca ilk byte’ı almak gibi bir yöntemle etrafından dolaşmanız gerekir
    Çok sayıda pre-signed URL üretiyorsanız üretim hızını 10–40 kat artırma ihtimaliniz var: https://github.com/WeTransfer/wt_s3_signer
    Tamamlanmamış multipart upload’ların depolama maliyetini de hâlâ ödersiniz. Kullanıcıların bu tür upload’ları başlatabildiği bir mimariniz varsa özellikle dikkatli olmalısınız. Belirli bir süre sonra tamamlanmamış multipart upload’ları otomatik silen bir ayar var; başınız ağrımasın istiyorsanız açmalısınız
    Paradoksal biçimde S3 devrim niteliğindeydi ve hâlâ birçok katmanda harika bir ürün. Ancak çok fazla özelliği olduğu kadar çok fazla tuzağı da var

    • Birkaç hafta önce beni yakalayan şey, multipart upload’daki minimum ilk chunk boyutu 5MiB sınırıydı: https://docs.aws.amazon.com/AmazonS3/latest/userguide/qfacts...
      Elixir’de Stream.transform(https://hexdocs.pm/elixir/Stream.html#transform/3) kullanarak sütunları değiştiren ve ekleyen bir streaming CSV son işleme pipeline’ı oluşturdum. Elixir’in AWS ve CSV modülleri gelen streaming veriyi işliyor; ancak çıkan stream’in toplamı 5MiB’den küçükse AWS modülü multipart upload kullandığı için S3 hata verdi, bu da üzücüydü

  • Bir iş arkadaşımla birkaç gün analiz edip teşhis ettiğimiz başka ilginç bir sorun daha var. S3, tek bir TCP bağlantısı 100 HTTP isteği gönderdikten sonra sonraki istekleri sessizce çöpe atıyor
    https://github.com/aws/aws-sdk-go/issues/2825

    • Aslında sessizce çöpe atmıyor; TCP bağlantısını kapattığını belirten bir header gönderiyor
      Performans nedeniyle keep-alive istemek ama istemcinin çok uzun süre bağlı kalıp yük dengeleyicide hotspot oluşturmasını engellemek istediğinizde bu yaygın bir paterndir

  • S3’ün standart storage class’ta gecikmesinin yüksek olması nedeniyle web sunumu için uygun olmaması da var
    Birçok kişi görseller veya fontlar gibi web sitesi kaynaklarını doğrudan S3’ten host edebileceğini düşünüyor ama kullanıcı deneyimi kötüleşebilir
    “applications can achieve consistent small object latencies (and first-byte-out latencies for larger objects) of roughly 100–200 milliseconds.”
    Kaynak: https://docs.aws.amazon.com/AmazonS3/latest/userguide/optimi...

    • Çoğu kişi içerik sunumu için S3’ü AWS CloudFront’un origin’i olarak kullanır
      CloudFront signed cookies kullanırsanız belirli bir kullanıcıya yalnızca S3’te kendisine ait içeriğe CDN erişimi de verebilirsiniz. Oldukça güzel
    • Web varlıklarını sunmak için genellikle S3 ile CloudFront birlikte kullanılır
      Sık erişilen varlıkları cache’leyerek gecikmeyi azaltabilir, maliyeti de epey düşürebilirsiniz
    • S3, web sitelerini doğrudan sunmak için optimize edilmemiştir; neredeyse sınırsız veriyi dayanıklı biçimde depolamak ve geri almak için optimize edilmiştir

  • Kuralları uploader’ın belirlemesi epey sert. Ayarları gevşek bir web sitesi söz konusuysa, yeterince motive bir kullanıcının kullanıcı içeriğini Amazon Glacier’a yükletip daha sonra oradan servis edilmesini sağlaması anlamına mı geliyor?