Cloudfront

Amazon CloudFront, AWS’in küresel İçerik Dağıtım Ağı (CDN) hizmetidir. CDN’ler, içerik kopyalarını dünya genelindeki sunucularda önbelleğe alarak kullanıcılara en yakın noktadan sunar. Bu sayede verinin kullanıcıya ulaşması için kat etmesi gereken mesafe azalır, gecikme (latency) ve yükleme süreleri düşer. CloudFront, yüzlerce Edge Location (uç nokta) üzerinden statik ve dinamik web içeriklerini, video/medya dosyalarını ve API yanıtlarını yüksek hız ve düşük gecikmeyle iletir. Aynı zamanda AWS Shield ve AWS WAF ile entegre çalışarak DDoS ve uygulama katmanı saldırılarına karşı koruma sağlar.

CloudFront’un çalışma prensibi şöyle özetlenebilir: Bir kullanıcı bir içerik istediğinde (ör. bir resim veya sayfa), istek otomatik olarak en yakın Edge Location’a yönlendirilir. Edge sunucu, istenen içeriğin önbelleğinde olup olmadığına bakar. Cache hit durumunda (içerik mevcutsa) doğrudan edge sunucudan kullanıcıya iletilir. Cache miss durumunda ise CloudFront edge sunucusu isteği kaynağa (Origin sunucu) iletir; orijin sunucudan içeriği aldıktan sonra hem kullanıcıya iletir hem de ilerideki istekler için bu Edge Location’da önbelleğe alır. Böylece sonraki kullanıcılar aynı içeriği çok daha hızlı bir şekilde en yakın edge konumundan alabilir ve orijin sunucuya yapılan istek sayısı azalır.

Gerçek dünya senaryosunda, örneğin web sitenizin sunucusu İrlanda’da olsun ve kullanıcılar Paris’ten siteye erişsin. CloudFront kullanmazsanız her bir kullanıcı isteği Avrupa’daki orijin sunucuya kadar gitmek zorunda kalır ve özellikle büyük boyutlu dosyalar (resimler, videolar) için ağ gecikmesi olur. CloudFront dağıtımı yapılandırdığınızda ise Paris’teki bir kullanıcı siteye girdiğinde isteği Paris’e en yakın Edge Location üzerinden karşılanır; eğer istenen içerik o edge’de yoksa ilk sefer İrlanda’daki orijinden alınıp edge’e kaydedilir, sonraki Paris’li kullanıcılar aynı içeriği direkt yakın konumdaki edge sunucusundan alır. Bu, daha düşük gecikme ve daha yüksek hız anlamına gelir ve orijin sunucunun yükünü azaltır.

Bir Edge Location, AWS’nin dünya çapına yayılmış veri merkezlerinden oluşan bir noktasıdır (AWS Region bölgelerinden ve AZ’lerden ayrıdır). CloudFront istemci DNS isteğini, genellikle en düşük gecikmeye sahip en yakın Edge Location’a yönlendirir. CloudFront ayrıca Regional Edge Cache adı verilen, orijin ile edge konumları arasında konumlanan daha büyük önbellek katmanları da kullanır. Bölgesel önbellekler, daha az popüler içeriklerin bile bir süre daha bölge içinde tutulmasını sağlayarak orijine dönüşleri daha da azaltır ve tutarlılığı artırır. Sonuç olarak CloudFront, sık istenen dosyaları uç noktalarda, daha az istenenleri ise bölgesel önbelleklerde tutarak hem yüksek performanslı içerik teslimi yapar hem de orijin kaynaklarını verimli kullanır.

2. Temel Yapılandırmalar

Bir CloudFront distribution (dağıtım) oluştururken belirlediğimiz temel yapılandırmalar, CloudFront’un hangi kaynaktan içerik çekeceğini ve istemcilere bu içeriği nasıl sunacağını kontrol eder. Önemli yapılandırma bileşenleri şunlardır:

• Origin Domain Name: CloudFront’un içerik aldığı orijin sunucunun alan adı. Bu, dağıtıma eklediğiniz kaynak sunucudur. Orijin olarak bir AWS S3 Bucket, bir HTTP sunucusu (EC2 instance veya kendi veri merkezinize ait), bir Elastic Load Balancer ya da hatta bir API Gateway uç noktası belirlenebilir. Örneğin orijin alan adınızı example.com veya bir S3 bucket’ı için my-bucket.s3.amazonaws.com şeklinde tanımlarsınız. CloudFront, uç kullanıcı isteklerini bu orijin adresine yönlendirerek içerik çeker.

• Origin Path: Orijin sunucuda istekte bulunulacak isteğe bağlı alt dizin. Bu ayar, CloudFront’un orijine istek yaparken varsayılan olarak ekleyeceği bir yol tanımlamanızı sağlar. Örneğin, orijin domain’iniz bir S3 bucket ise ve sadece images/ klasöründeki içerikleri dağıtmak istiyorsanız Origin Path olarak /images belirtebilirsiniz. Böylece CloudFront’a gelen bir istek yolu logo.png ise orijine /images/logo.png şeklinde istek gönderilir. Origin Path alanını boş bırakırsanız CloudFront istek yolunu doğrudan orijine iletir (not: bir CloudFront dağıtımında birden fazla orijin ve ona bağlı cache behavior tanımlayarak farklı alt dizinleri farklı orijinlere yönlendirebilmek de mümkündür).

• Origin Response Timeout: CloudFront’un orijin sunucudan yanıt beklerken harcayacağı maksimum süredir. Bu süre içinde orijinden herhangi bir yanıt gelmezse isteği zamanaşımına uğratır. Varsayılan orijin okuma zaman aşımı 30 saniyedir (en fazla 60 saniyeye kadar artırılabilir). Yüksek gecikmeli veya yavaş yanıt veren orijinler için gerekirse bu değer ayarlanabilir. Örneğin büyük bir dosya üretip dönen bir sunucu için zaman aşımı süresini artırmak isteyebilirsiniz.

• Origin Keep-Alive Timeout: CloudFront’un orijin ile açık tuttuğu TCP bağlantısını, yanıt aldıktan sonra ne kadar süre boyunca açık/boşta tutacağını belirler. Varsayılan olarak CloudFront, orijin bağlantısını 5 saniye boşta kalınca kapatır (en fazla 60 saniyeye kadar artırılabilir). Keep-alive, birden fazla istek için aynı TCP bağlantısını tekrar kullanarak performansı artırır. Eğer orijine ardışık çoklu istekler bekleniyorsa keep-alive süresini artırmak yararlı olabilir; aksi halde gereksiz yere uzun tutmak sunucu kaynaklarını meşgul edebilir.

• SSL Sertifikası Seçimi: CloudFront dağıtımınızı HTTPS üzerinden kendi özel alan adınızla sunmak isterseniz, bir SSL/TLS sertifikası kullanmanız gerekir. CloudFront, Default CloudFront Certificate (*.cloudfront.net etki alanı için otomatik atanmış sertifika) veya Custom SSL Certificate (kendi alan adınıza ait, AWS Certificate Manager’dan sağlanan) şeklinde sertifika kullanımını destekler. Dağıtım ayarlarında Alternate Domain Names (CNAMEs) kısmına eklediğiniz özel alan adları için ACM (AWS Certificate Manager) hizmetinde oluşturulmuş bir sertifika seçebilirsiniz. Örneğin sitenizi cdn.ornekalan.com üzerinden CloudFront ile sunmak isterseniz, o domain için ACM’de sertifika oluşturup dağıtımınızda “Custom SSL Certificate” olarak bunu belirlemelisiniz. CloudFront, TLS bağlantılarını bu sertifika ile sonlandıracak ve istemciler içerikleri sizin özel alan adınız üzerinden güvenli bir şekilde alacaktır. (Not: CloudFront özel sertifikaları sadece us-east-1 (N. Virginia) bölgesindeki ACM’den alır, bu nedenle sertifikanızı o bölgede oluşturmanız gerekir.)

• Custom Header Kullanımı: CloudFront, orijine ilettiği isteklerle beraber özel HTTP header’ları eklemenize imkân tanır. Bu Custom Origin Headers genellikle çoklu CDN kullanımı veya kaynak ayrımı senaryolarında yararlıdır. Örneğin, aynı orijin sunucuya birden fazla CDN veya farklı CloudFront dağıtımları bağlanıyorsa, her isteğin hangi dağıtımdan geldiğini orijin tarafında ayırt etmek için özel bir header kullanılabilir. Siz de CloudFront dağıtımınızda X-CDN-Source: CloudFront-A gibi bir header tanımlayarak, orijin sunucu loglarında veya uygulamanızda bu header’a bakıp isteğin belirli bir CloudFront dağıtımı üzerinden geldiğini anlayabilirsiniz. Benzer şekilde, güvenlik amaçlı yalnızca CloudFront üzerinden gelen istekleri kabul etmek için orijinde özel header kontrolü yapabilirsiniz (ör. CloudFront dağıtımınızın her isteğe X-Allowed: true header’ını eklediğini varsayarak, orijin uygulamanız sadece bu header mevcutsa yanıt verebilir). Custom header’lar birden fazla CDN’nin aynı orijini kullanması durumunda tanımlama bilgisi niteliğinde de değerlendirilebilir; HTTP log analizi yaparken hangi CDN’in ne kadar trafik getirdiğini bu sayede ayırt edebilirsiniz.

3. Cache Davranışı (Önbellekleme Ayarları)

CloudFront, içerik önbellekleme konusunda oldukça esnek yapılandırma seçenekleri sunar. Cache Behavior adı verilen ayarlar grubu, hangi içeriklerin nasıl önbelleğe alınacağını ve istemci isteklerinin nasıl yönlendirileceğini belirler. Bir dağıtımda birden fazla cache behavior tanımlayarak, farklı yol desenleri için farklı önbellek ve yönlendirme kuralları uygulayabilirsiniz (örneğin /static/* için ayrı, /api/* için ayrı davranışlar gibi). Dağıtım oluşturulduğunda varsayılan olarak tüm yolları kapsayan bir “Default (*)” cache behavior bulunur.

Cache Behavior Ayarları

Her bir cache behavior, şu temel seçenekleri içerir:

• Path Pattern (Yol Deseni): Bu davranışın uygulanacağı URL yolu desenini belirtir (ör. images/*, /*.html gibi). Varsayılan davranışın deseni * olup tüm istekleri kapsar. Daha spesifik desenli davranışlar ekleyerek belirli içerikler için özel kurallar koyabilirsiniz. CloudFront, gelen istek URL’sine en çok uyan (longest match) desene sahip davranışı uygular.

• Allowed HTTP Methods (İzinli HTTP Yöntemleri): Hangi HTTP istek türlerinin CloudFront üzerinden orijine iletilebileceğini tanımlar. Varsayılan olarak yalnızca GET ve HEAD yöntemleri izinlidir (sadece okuma amaçlı istekler, CDN önbelleklemesi için uygundur). Ancak dilerseniz OPTIONS ve yazma yöntemlerini (PUT, POST, PATCH, DELETE) de etkinleştirebilirsiniz. Yazma işlemlerine izin verildiğinde CloudFront bu istekleri de orijine iletir (not: GET/HEAD dışındaki yöntemlerin yanıtları genellikle önbelleğe alınmaz, her seferinde orijine iletilirler). Hangi yöntemlerin kullanılacağını belirlemek, dağıtımınızın amacına göre güvenlik ve performans dengesini sağlar. Örneğin, yalnızca statik web sitesi içerikleri dağıtıyorsanız GET, HEAD yeterliyken, bir API’yi CloudFront arkasına aldıysanız GET, HEAD, OPTIONS, POST, PUT, DELETE, PATCH gibi yöntemleri eklemeniz gerekir.

• Cache Based on Selected Request Headers: Hangi istekküçük HTTP header alanlarının önbellek anahtarını etkileyeceğini belirler. Varsayılan olarak CloudFront, orijine iletilmesi gereken asgari header’ları iletir ve önbellek anahtarına (cache key) sadece seçili bazı header’ları dahil eder. Örneğin, tarayıcı Accept-Language header’ına göre farklı dillerde içerik sunuyorsanız bu header’ı cache key’e dahil edebilirsiniz ki farklı dil istekleri ayrı ayrı önbelleğe alınsın. Aksi halde, header’ı dikkate almadan önbelleğe almak yanlış içerik sunumlarına yol açabilir. CloudFront ayrıca bütün header’ları orijine forward edebileceğiniz bir “All” seçeneği sunar, ancak bu durumda önbellek verimliliği düşebilir (her farklı header kombinasyonu için ayrı cache oluşur). Bu ayar, varyant içeriğin (cihaza göre, dile göre, cihaza göre vs.) doğru işlenmesi için kritiktir.

• Query String Forwarding and Caching: URL query string (sorgu parametrelerini) önbellek anahtarına dahil edip etmeyeceğinizi kontrol eder. Varsayılan olarak CloudFront, sorgu stringlerini orijine iletmez ve önbellek anahtarında dikkate almaz (ya da isteğe göre Forward all, cache based on all yapabilir). Eğer uygulamanız URL parametrelerine göre farklı sonuçlar dönüyorsa (ör. /search?q=abc), bu parametrelerin forward edilmesi ve caching davranışının uygun seçilmesi gerekir. “Forward all, cache based on whitelist” gibi alt seçeneklerle sadece belirli parametrelere göre önbellek ayrımı yapabilirsiniz. Yanlış yapılandırma, ya parametrelere duyarsız caching (farklı arama sonuçlarında aynı cache kullanılması) ya da gereksiz düşük caching (her benzersiz parametre kombinasyonu için ayrı cache) gibi sonuçlar doğurabilir.

• Object Compression: CloudFront’un orijinden aldığı içerikleri (özellikle metin bazlı dosyaları: HTML, CSS, JS, JSON, XML vs.) istemcilere sıkıştırarak (gzip/brotli) sunmasını sağlar. “Compress Objects Automatically” seçeneği açıldığında, orijin sıkıştırma yapmasa bile CloudFront desteklenen türdeki içerikleri otomatik sıkıştırıp istemciye iletir. Bu bant genişliği tasarrufu ve hız için faydalıdır. İstemci tarafında Accept-Encoding header’ına göre CloudFront brotli veya gzip seçimini yapar. Not: Eğer orijin zaten sıkıştırılmış içerik yolluyorsa (ör. S3’ten .gz versiyonu), CloudFront ikinci defa sıkıştırmaz.

• Smooth Streaming: Bu seçenek özellikle Microsoft Smooth Streaming protokolünü kullanan medya içerikleri için vardır. Bir cache behavior’da Smooth Streaming işaretlenirse, CloudFront .ism manifest dosyalarını ve medya parçalarını Smooth Streaming formatına uygun şekilde işler ve önbelleğe alır. Bu konunun detayına aşağıdaki Canlı Yayın ve Medya Dağıtımı bölümünde değineceğiz, ancak özetle: Smooth Streaming etkinleştirildiğinde CloudFront istemciden gelen Smooth Streaming istek URL’lerini (ör. video.ism/Manifest gibi) tanır ve gereğine göre orijinden çekerek dağıtır.

Yukarıdaki ayarlar, her cache behavior için ihtiyaçlara göre düzenlenmelidir. Örneğin, genel olarak çoğu web sitesi için tek bir cache behavior (/) yeterli olurken, API’lar veya farklı içerik türleri barındıran sitelerde farklı path pattern’lerle birden fazla davranış konfigüre edilebilir.

Object Caching Seçenekleri (TTL Ayarları)

CloudFront, içeriklerin önbellekte ne kadar süreyle tutulacağını kontrol etmek için TTL (Time to Live) değerlerini kullanır. Önbelleğe alma stratejiniz, içeriğin güncellenme sıklığına ve tazelik ihtiyacına göre şekillenmelidir. CloudFront’ta önbellek süresini belirlemenin iki yolu vardır:

1. Origin Tarafında Ayarlama: Orijin sunucu, yanıtlarının HTTP header’larında Cache-Control: max-age, Cache-Control: s-maxage (sadece proxy/CDN için) veya Expires header’ları göndererek her bir obje için önbellekte kalma süresini belirtebilir. CloudFront, varsayılan durumda bu header değerlerine uyarak objeyi belirtilen süre boyunca önbellekte tutar. Örneğin orijin bir resim yanıtında Cache-Control: max-age=86400 (24 saat) belirtmişse, CloudFront o resmi 24 saat boyunca cache’ler (daha sonra istek gelirse orijine 304 ile durumu sorar veya cache tazelemesi yapar). Origin tarafında Cache-Control: no-cache veya kısa max-age değerleri ayarlayarak CloudFront’un sık sık orijine danışmasını da sağlayabilirsiniz (ancak bu, CDN avantajını azaltır).

2. CloudFront Tarafında Zorlama: Her cache behavior için Minimum TTL, Default TTL ve Maximum TTL değerleri tanımlanabilir. Bu değerler, orijin header’larından bağımsız olarak CloudFront önbellek süresini sınırlar veya varsayılanı belirler:

   • Default TTL: Orijin bir max-age belirtmediği durumlarda CloudFront’un varsayılan olarak objeyi önbellekte tutacağı süre. Varsayılan Default TTL 24 saattir. Yani orijin herhangi bir cache yönlendirici header vermediyse CloudFront objeyi 24 saat saklar. Bu değeri artırmak, statik ve nadiren değişen içerikler için orijine istekleri azaltır; düşürmek ise daha dinamik içerikler için güncelliği artırır.

   • Minimum TTL: CloudFront’un önbellekte tutacağı en kısa süre. Orijin çok kısa bir süre verse bile (hatta no-cache dese bile), CloudFront bu minimum süre boyunca objeyi cache’te tutar. Varsayılan minimum TTL 0 saniyedir (yani orijinin no-cache demesine izin verir). Eğer minimum TTL’i 0’dan büyük yaparsanız, CloudFront her durumda objeyi en az o süre cache’ler. Örneğin min TTL 300 sn iken orijin Cache-Control: max-age=0, no-cache dese bile CloudFront 5 dakika saklar. Bu ayar dikkatli kullanılmalıdır; genelde min TTL = 0 bırakılır ki orijin “bu içerik değişken, cache’leme” dediğinde CloudFront buna uysun.

   • Maximum TTL: CloudFront’un önbellekte tutacağı en uzun süre. Orijin çok uzun bir süre belirtse bile CloudFront bu değeri aşan sürelerde içeriği tutmaz. Varsayılan max TTL pratikte genellikle 1 yıla denk gelir (AWS panelinde 31536000 saniye gibi yüksek bir değer olabilir). Örneğin max TTL 3600 sn (1 saat) ise, orijin Cache-Control: max-age=86400 (24 saat) verse dahi CloudFront en fazla 1 saat sonra yeniden orijine kontrol eder. Max TTL, orijinin fazla uzun cache sürelerine karşı bir emniyet sağlar.

Bu TTL ayarlarının orijin headerlarıyla etkileşimi şöyle özetlenebilir: CloudFront, her obje için geçerli cache süresini hesaplarken orijin tarafından sağlanan Cache-Control: max-age/s-maxage veya Expires değeri ile yukarıdaki min/default/max TTL sınırlarını birlikte değerlendirir. Örneğin:

• Eğer orijin max-age 10 dakika dedi ve CloudFront Default TTL 1 saat ise, CloudFront 10 dakikayı esas alır (orijin daha kısa).

• Eğer orijin max-age 2 saat dedi ama CloudFront Max TTL 1 saat ise, CloudFront 1 saat sonra yine orijine uğrar (CloudFront daha kısa sınır koymuş).

• Eğer orijin hiçbir şey demediyse CloudFront Default TTL değerini kullanır (varsayılan 24 saat, isteğe göre değiştirilebilir).

Önbellek sürelerini yönetmenin en iyi yolu genellikle origin tarafında doğru headerları göndermek ve CloudFront’ta makul TTL sınırları koymaktır. Bu sayede içerikleriniz gerektiği kadar süreyle edge’de kalır; ne çok bayat ne de çok sık tazelenir. Ayrıca, duyarlı içerik değişikliklerinde cache invalidation mekanizmasıyla elle temizleme yapabileceğinizi unutmayın (aşağıda açıklanmıştır).

Not: CloudFront önbelleğinde bir obje TTL süresi dolmadan önce de bellekten atılabilir. Eğer bir edge location’da uzun süre istek almayan bir içerik varsa, CloudFront onu TTL bitmeden de bellekten çıkarıp daha popüler içeriklere yer açabilir. Bu durumda sonraki istekte orijine tekrar gidilir ancak bu beklenen bir davranıştır; TTL, içeriğin en fazla ne kadar tutulabileceğini garantiler, en azı değil.

Invalidations (Önbelleği Elle Temizleme)

CloudFront, normal koşullarda TTL süreleriyle önbelleği yönetirken, bazen içerik güncellemelerini hemen yansıtmak gerekebilir. Örneğin, yayına aldığınız bir dosyada kritik bir hata buldunuz ve hemen düzeltip yenisini dağıttınız. Varsayılan TTL nedeniyle CloudFront edge’leri eski dosyayı ellerinde tutmaya devam edebilir. Bu gibi durumlarda Invalidation mekanizmasını kullanarak CloudFront önbelleğini manuel olarak temizleyebilirsiniz.

Bir invalidation isteği, CloudFront’a belirttiğiniz yollarla eşleşen önbellek nesnelerini silmesi talimatını verir. Örneğin sadece /styles/app.css dosyasını yeni sürümle güncellediniz; CloudFront panelinden veya CLI komutuyla bir invalidation oluşturup /styles/app.css yolunu belirtebilirsiniz. Bu işlem sonrasında tüm edge location’larda bu dosyanın önbellekteki kopyası silinecektir. Sonraki kullanıcı isteğinde CloudFront tekrar orijine gidip güncel dosyayı alır. İsterseniz wildcard kullanarak bir klasördeki tüm içerikleri (ör. /styles/*) veya bütün siteyi (/*) de invalide edebilirsiniz.

Invalidation istekleri genellikle birkaç dakika içinde tüm noktaları etkiler. Çoğu durumda 60–300 saniye arasında tamamlanır ve tüm dünyadaki edge sunucular eski içeriği bırakır. CloudFront, ilk 1000 adet path bazlı invalidation talebini aylık ücretsiz sunar; 1000’i aşan her bir yol için düşük bir ücret uygulanır. (Not: /* bir path kabul edilir ve tüm dağıtımı temizler, ama bu yaygın kullanılmamalıdır; yerine spesifik path’leri temizlemek daha iyidir.)

Invalidation işlemi özellikle cache süresini uzun tuttuğunuz (performans için) ama gerektiğinde anında güncelleme yapmanız gereken durumlar için hayat kurtarıcıdır. Örneğin bir kampanya görselini güncellediniz ve kullanıcıların eski görseli görmesini istemiyorsunuz; invalidation ile anında yenileyebilirsiniz. Alternatif yaklaşım olarak, dosyalarınızı versiyonlayarak (örn. style.v2.css gibi) isim değişikliği yapmak da bir yöntemdir – CloudFront yeni ismi ayrı bir içerik olarak görür ve orijinden çeker, eskiyi de TTL dolana kadar zamanla bırakır. Ancak versiyonlama her zaman uygulanamayabilir, bu yüzden invalidation esnek bir çözümdür.

4. HTTP Yöntemleri

CloudFront, HTTP protokolünün tüm standart yöntemlerini destekler ancak dağıtım yapılandırmanıza bağlı olarak bazılarını kısıtlayabilirsiniz. İzin verilen yöntemler, hem istemcilerin neler yapabileceğini hem de önbellekleme davranışını etkiler. Aşağıda yaygın HTTP yöntemlerini ve kullanım amaçlarını örneklerle bulabilirsiniz (tüm örnekler HTTP/1.1 formatındadır):

1. GET: Sunucudan veri almak için kullanılır. Sunucudaki bir kaynağı okumaya yönelik istekler GET ile yapılır. Örnek: Bir kullanıcının profil bilgilerini almak için GET isteği:

   GET /users/1 HTTP/1.1  
   Host: example.com

   Bu istek, sunucudan ID’si 1 olan kullanıcının bilgilerini getirmeyi amaçlar. (CloudFront üzerinden GET istekleri genellikle önbellekten karşılanabilir.)

2. POST: Sunucuya yeni veri göndermek ve kaydetmek/oluşturmak için kullanılır. Bir kaynak üzerinde yan etki oluşturan (yeni kayıt eklemek gibi) işlemler POST ile yapılır. Örnek: Yeni bir kullanıcı oluşturmak için POST isteği:

   POST /users HTTP/1.1  
   Host: example.com  
   Content-Type: application/json
   
   {
     "name": "Mert",
     "email": "[e-mail]"
   }

   Bu istekte istemci, sunucuya JSON formatında bir kullanıcı nesnesi göndererek yeni bir kullanıcı kaydı oluşturmayı amaçlar. (CloudFront, POST isteklerini de orijine iletebilir ancak GET kadar önbellek avantajı sağlamaz.)

3. PUT: Sunucudaki mevcut bir kaynağı tamamen güncellemek (yenisiyle değiştirmek) için kullanılır. Gönderilen veriler mevcut kaynağın yerini alır. Örnek: ID’si 1 olan kullanıcının bilgilerini tamamen güncellemek:

   PUT /users/1 HTTP/1.1  
   Host: example.com  
   Content-Type: application/json
   
   {
     "name": "Mert Arslan",
     "email": "[e-mail]"
   }

   Bu istek, sunucudaki ID 1 kullanıcısının tüm kayıtlı bilgilerini verilen JSON ile değiştirmeyi amaçlar (varsa eski tüm alanlar yeni gönderilenlerle güncellenir, gönderilmeyen alanlar boş kabul edilebilir).

4. PATCH: Sunucudaki mevcut bir kaynağın bir kısmını güncellemek (kısmi güncelleme) için kullanılır. Yalnızca değişecek alanları içerir. Örnek: ID’si 1 olan kullanıcının sadece adını değiştirmek için PATCH isteği:

   PATCH /users/1 HTTP/1.1  
   Host: example.com  
   Content-Type: application/json
   
   {
     "name": "Mert Arslan"
   }

   Bu istek, sunucudaki ID 1 kullanıcısının sadece ad bilgisini “Mert Arslan” olarak günceller; diğer alanlar etkilenmez. (PATCH, kısmi güncellemelerde veri tasarrufu sağlar.)

5. DELETE: Sunucudaki bir kaynağı silmek için kullanılır. Örnek: Bir kullanıcıyı silmek için DELETE isteği:

   DELETE /users/1 HTTP/1.1  
   Host: example.com

   Bu istek, sunucuda ID’si 1 olan kullanıcı kaydını silmeyi amaçlar. Başarılı olursa sunucu genelde 204 No Content veya 200 OK (silindiğine dair mesajla) dönebilir.

6. HEAD: Sunucudan, bir kaynağın sadece header (başlık) bilgilerini almak için kullanılır. GET’in aynısını yapar ama gövde (body) içermez. Bu yöntem, bir kaynağın varlığını veya meta bilgisini kontrol etmek için idealdir. Örnek: Bir dosyanın sunucuda var olup olmadığını kontrol etmek:

   HEAD /file.zip HTTP/1.1  
   Host: example.com

   Bu istek, file.zip adlı dosyanın mevcut olup olmadığını test eder. Sunucu dosya varsa 200 OK (sadece header’lar ile), yoksa 404 Not Found döner. Dosya içeriği iletilmez, böylece gereksiz veri transferi olmadan kontrol sağlanır.

7. OPTIONS: Bir kaynağın hangi HTTP yöntemlerini desteklediğini sormak için kullanılır. İstemci, sunucuya erişim için ön bilgi talep eder. Özellikle CORS (Cross-Origin Resource Sharing) preflight isteklerinde tarayıcılar tarafından otomatik yapılır. Örnek: /users kaynağının hangi yöntemleri desteklediğini kontrol etmek:

   OPTIONS /users HTTP/1.1  
   Host: example.com

   Bu isteğe sunucu örneğin Allow: GET, POST, OPTIONS gibi bir header ile cevap verebilir. Tarayıcılar, farklı origin’ler arası isteklerde (CORS) hedef sunucunun izin verdiği yöntem ve header’ları öğrenmek için OPTIONS isteği yollar.

8. TRACE: Bir isteğin sunucuya ulaşırken hangi ara noktalardan geçtiğini test etmek (diagnostic amaçlı) için kullanılır. Sunucu genelde aldığı isteği aynen geri döndürür. Bu, ağ üzerindeki proxy veya değişiklikleri izlemek için kullanılır ancak güvenlik nedeniyle çoğu sunucuda devre dışı olabilir. Örnek: Bir isteğin yolunu izlemek (tanılama):

   TRACE /users HTTP/1.1  
   Host: example.com

   Bu istek, sunucudan (ve aradaki ara sunuculardan) isteğin hangi aşamalardan geçtiğini görmek amacıyla yapılır. Sunucu genellikle isteği değişmeden yanıt gövdesine yansıtır. (Birçok modern sunucu ve CDN, XSS riskleri nedeniyle TRACE’i kapatır.)

9. CONNECT: HTTP üzerinden bir tünel açmak için kullanılır. Genellikle HTTPS gibi TLS bağlantıları için proxy sunucular tarafından kullanılır. İstemci, CONNECT ile bir ara proxy’den hedef sunucuya tünel kurmasını ister; başarılı olursa ham TLS el sıkışması bu tünel üzerinden ilerler. Örnek: Bir proxy aracılığıyla güvenli HTTPS bağlantısı kurmak:

   CONNECT www.example.com:443 HTTP/1.1  
   Host: www.example.com:443

   Bu istek, istemcinin bir proxy sunucuya, hedef olarak example.com’un 443 portuna bir tünel açması talimatını verir. Amaç, proxy üzerinden doğrudan şifreli bir bağlantı kurup son sunucuyla güvenli iletişim sağlamaktır. (CONNECT yöntemini tarayıcılar genelde içsel olarak kullanır; uygulama geliştirirken pek rastlanmaz.)

CloudFront dağıtımınızın Allowed HTTP Methods ayarına bağlı olarak yukarıdaki yöntemlerin tamamı veya bir kısmı etkin olabilir (CloudFront panelinde GET, HEAD veya GET, HEAD, OPTIONS ya da Tümünü İzin Ver (All) şeklinde seçim yapılabiliyor). Önbellekleme yönünden GET/HEAD yöntemleri önbelleğe uygundur. OPTIONS istekleri de CloudFront önbelleğinde kısa süreli tutulabilir (CORS preflight yanıtları genelde 1 saat veya daha az süreyle). POST, PUT, PATCH, DELETE, TRACE, CONNECT gibi yöntemler ise genellikle her seferinde orijine iletilir ve anlık işlem yapar, bunlar için CloudFront daha çok bir iletim ve hızlandırma rolü oynar (TCP optimizasyonu, TLS offload vs.) ancak içerik önbelleği rolü olmaz.

HTTP yöntemleri ve CloudFront ilişkisini planlarken, güvenlik ve gereksinimler göz önünde bulundurulmalıdır. Siteniz yalnızca okuma işlemi yapıyorsa yazma yöntemlerini kapalı tutmak yüzeye saldırı riskini azaltır. Öte yandan, bir API dağıtıyorsanız tüm gerekli yöntemleri açmalısınız. CloudFront, HTTPS istekleri ve yöntemleri destekler; mümkün olduğunca dağıtımınızı HTTPS Only yaparak güvenli iletişimi zorunlu kılmanız da tavsiye edilir.

5. Lambda@Edge ve API Gateway Entegrasyonu

Lambda@Edge Nedir ve Ne İşe Yarar?

Lambda@Edge, Amazon CloudFront ile entegre çalışan bir sunucusuz kod çalıştırma özelliğidir. Geliştiricilerin, CloudFront’un uç noktalarında (Edge Locations) kendi yazdıkları küçük kod parçalarını (AWS Lambda fonksiyonları) çalıştırabilmesini sağlar. Böylece isteklere coğrafi olarak en yakın noktada müdahale ederek özelleştirilmiş yanıtlar üretmek veya isteği modifiye etmek mümkün olur, hem de ek bir sunucu altyapısı kurmadan. Lambda@Edge, kullanıcıların bulunduğu lokasyona en yakın AWS konumlarında kod çalıştırarak son kullanıcılara en düşük gecikmeyle yanıt vermenize imkân tanır.

Lambda@Edge çalışma mantığı şöyle özetlenebilir: Mevcut bir AWS Lambda fonksiyonunun belirli bir CloudFront olayı gerçekleştiğinde tetiklenmesini yapılandırırsınız. Bu olaylar dört çeşittir:

• Viewer Request (Görüntüleyici İsteği): Bir istemci CloudFront’a istek gönderdiğinde, içerik önbellekten sunulmadan hemen ÖNCE tetiklenir.

• Viewer Response (Görüntüleyici Yanıtı): Edge sunucu orijinden aldığı veya önbellekteki yanıtı istemciye göndermeden hemen ÖNCE tetiklenir.

• Origin Request (Kaynak İsteği): CloudFront, içerik için orijin sunucuya bir istek göndermek üzereyken (örneğin edge cache’de yok veya TTL süresi doldu) tetiklenir.

• Origin Response (Kaynak Yanıtı): Orijinden bir yanıt alındığında ve istemciye iletilmeden hemen önce tetiklenir.

Bu tetikleme noktalarında çalışan Lambda@Edge kodunuz, isteği veya yanıtı inceleyip değiştirebilir, tamamen farklı bir yanıt üretebilir veya farklı bir kaynağa yönlendirebilir. Üstelik tüm bunlar uç konumlarda gerçekleştiği için, merkezi sunucuya ulaşan istek sayısını azaltabilir veya kullanıcılara çok daha yakın konumda dinamik içerik sunabilirsiniz. Lambda@Edge, özellikle kullanıcılarınız dünya çapına dağılmışsa ve gecikmeye duyarlı uygulamalarınız varsa büyük avantaj sağlar; coğrafi konuma, cihaz tipine veya isteğin diğer özelliklerine göre kararları kullanıcıya en yakın noktada vererek yanıt sürelerini düşürür.

Lambda@Edge Ne Zaman Kullanılır? Tipik kullanım senaryoları:

• İçerik Kişiselleştirme: Örneğin kullanıcının ülkesine göre sayfada özel mesaj göstermek. Lambda@Edge, viewer request aşamasında isteğin IP’sinden ülke bilgisine bakıp (CloudFront’ın isteğe eklediği Geo-headers veya IP veritabanı ile) isteği ilgili ülkeye özgü sayfaya yönlendirebilir veya response aşamasında yanıtın içine dinamik içerik ekleyebilir.

• A/B Test / Yüzde Bazlı Yönlendirme: Yeni bir uygulama sürümünü kademeli yayınlamak istiyorsunuz diyelim. Lambda@Edge fonksiyonu yazarak gelen isteklerin küçük bir bölümünü alternatif bir orijine yönlendirebilirsiniz. Örneğin, “%10 kullanıcıyı yeni siteye gönder” kuralı uygulamak. Bunu gerçekleştirmek için viewer request aşamasında rastgele bir sayı üreten kod, %10 olasılıkla isteğin URL’sini veya Host header’ını değiştirip CloudFront’un farklı bir origin’e yönelmesini sağlayabilir. Böylece kullanıcıların küçük bir dilimi yeni sürümü görür, çoğunluğu eski sürüme devam eder. Bu yöntemle canlı A/B testler veya kademeli dağıtım (canary release) yapılabilir.

• URL Yeniden Yazma / Yönlendirme: Lambda@Edge ile gelen istek URL’lerini manipüle edebilirsiniz. Örneğin SEO veya kullanıcı dostu URL’ler sağlamak adına /kategori/urun şeklinde istek gelince bunu origin için /prod.php?cat=kategori&item=urun olarak çevirebilirsiniz. Veya belirli koşullarda isteği tamamen farklı bir URL’ye 301/302 yönlendirmesi yapabilirsiniz (ör. mobil cihazdan gelen kullanıcıları mobil site alt alanına yönlendirmek).

• Güvenlik ve Erişim Kontrolü: Örneğin Viewer Request aşamasında gelen istekte özel bir auth token var mı kontrol edebilir, yoksa isteği engelleyebilir (CloudFront’un kendisinde WAF olsa da bazı özel durumları Lambda@Edge ile ele alabilirsiniz). Yine yanıt aşamasında hassas içerikleri gömmeden önce ek doğrulamalar yapabilirsiniz.

• Response Manipülasyonu: Lambda@Edge, origin response aşamasında orijinden dönen içerik üzerinde değişiklik yapabilir. Örneğin tüm yanıtların içine belirli header’lar eklemek (CORS header’ı, Security header’ları gibi) ya da cache-control header’larını düzenlemek mümkün. Statik bir web sitede, S3’ten gelen objelere Cache-Control veya Set-Cookie eklemek için kullanılabilir.

• Gerçek-zamanlı Görüntü İşleme/Transkod: Basit işlemler için Lambda@Edge kullanılabilir. Örneğin bir görüntü optimizasyon senaryosu: Kullanıcı küçük boyutlu resim isterse, Lambda@Edge istek yolundan parametre okuyup S3’ten dönen resmi anlık olarak yeniden boyutlandırıp yanıtlayabilir (belirli bellek ve işlem sınırları dahilinde).

Lambda@Edge fonksiyonları Node.js veya Python dilleriyle yazılabilir ve AWS Lambda’ya yüklenir. CloudFront panelinde ilgili dağıtımın cache behavior’ına bu fonksiyonu ilişkilendirirsiniz (Lambda Function Associations). Her tetikleme noktası için bir fonksiyon versiyonu bağlanabilir. Kodunuzun idempotent ve yüksek performanslı olması önemlidir, zira her istek için çalışabilir. Ayrıca bellek, CPU ve yürütme süresi sınırları normal Lambda’ya göre kısıtlı olabilir (şu an 128 MB bellek ve 5 saniye limit gibi kısıtlar var). Yine de çoğu hafif iş için fazlasıyla yeterlidir. CloudFront dünya genelinde birçok edge konumunda isteklere göre otomatik Lambda fonksiyon çağrılarını ölçekler; sizin elle dağıtım yapmanıza gerek kalmaz.

API Gateway ile Mikroservislerde Kullanım

AWS API Gateway, REST ve HTTP API’lar oluşturmak için yönetilen bir servistir. CloudFront ise daha çok statik içerik ve web dağıtımı için düşünülse de, API Gateway ile birlikte kullanıldığında mikroservis mimarilerinde de fayda sağlayabilir. İki şekilde entegrasyon mümkündür:

1. Edge-Optimized API Gateway vs CloudFront: API Gateway’in “Edge-Optimized” seçeneği, arka planda bir CloudFront dağıtımı kullanarak istemcilere daha yakın uç noktalar sunar. Ancak bu yönetilen CloudFront, sadece API Gateway’in kendi altyapısı içindir ve içerik önbelleği sağlamaz – sadece TCP bağlantılarını optimize eder. Bu nedenle, global bir API’nin yanıtlarını önbelleğe almak ve ilave özellikler eklemek istiyorsanız kendi CloudFront dağıtımınızı API Gateway’in önüne koymak mantıklı olabilir.

2. CloudFront’u API Gateway Önüne Koymak: Mikroservisleriniz API Gateway arkasında çalışıyorsa, CloudFront dağıtımını orijin olarak API Gateway URL’inize yönlendirebilirsiniz. Bu mimarinin başlıca faydaları:

   • Küresel Önbellekleme ve Düşük Gecikme: CloudFront, API Gateway’den dönen GET gibi idempotent yanıtları uçlarda önbelleğe alarak, dünyanın diğer ucundaki istemciler için bile düşük gecikmeli yanıtlar sunabilir. Örneğin, Frankfurt bölgesindeki API Gateway’inizden bir veri alan ABD’li kullanıcı, CloudFront sayesinde yanıtı Amerika’daki edge’den alabilir. Bu hem gecikmeyi azaltır hem de aynı verinin orijine (API) tekrar tekrar istek yapılmasını önler.

   • Maliyet ve Yük Azaltma: API Gateway’in kendi cache mekanizması sadece REST API’lerde ve ek ücrete tabidir, ayrıca invalidation esnekliği yoktur. CloudFront ile önbellekleme kullanmak daha ekonomiktir ve istek trafiğinin büyük kısmını CloudFront karşılayacağı için API Gateway çağrı sayısı ve arka uç yükü azalır. Ayrıca CloudFront veri transfer ücretleri, API Gateway’e kıyasla genelde daha düşüktür; CloudFront–API Gateway arası trafik AWS içi olduğundan ücretsizdir.

   • Tek Noktadan Dağıtım ve Alan Adı: CloudFront, birden fazla farklı kökeni tek bir dağıtım altında birleştirebilir. Örneğin, /api/* isteklerini API Gateway’e, /web/* isteklerini S3’de barınan web sitesine yönlendirecek şekilde tek bir CloudFront ile entegre edebilirsiniz. Bu sayede tüm içerikleriniz (statik web, dinamik API, vs.) aynı alan adı üzerinden sunulabilir. Kullanıcılar için tutarlı bir deneyim olur ve alan adı yönetimi kolaylaşır.

   • Güvenlik Entegrasyonları: CloudFront, AWS WAF (Web Application Firewall) ile tam uyumlu çalışır; API Gateway ise WAF’ı doğrudan entegre edemeyebilir (sadece Lambda Authorizer veya Cognito ile kısıtlı kalabilir). CloudFront’u önde kullanarak WAF ile istekleri filtreleyebilir, ayrıca AWS Shield Advanced desteğinden yararlanabilirsiniz (Shield, doğrudan API Gateway’i korumaz ama CloudFront’u koruyabilir). Coğrafi engelleme (geo-blocking) gibi CloudFront özellikleri de API’ye gelen isteklere uygulanabilir.

   • Lambda@Edge ile Ön İşlem: Yukarıda bahsedilen Lambda@Edge yetenekleri, API Gateway’e gelen istekler için de uygulanabilir. Örneğin, CloudFront viewer request’te JWT token kontrolü yapıp API Gateway’e ancak doğrulanan isteği gönderebilir; ya da belirli kullanıcı gruplarını farklı API versiyonuna yönlendirebilir. Bu şekilde API Gateway’i daha “ince” tutup bazı logic’leri edge’de halledebilirsiniz.

Özetle, CloudFront + API Gateway kombinasyonu global ölçekte mikroservis mimarileri için güçlü bir çözüm olabilir. Mikroservislerinizi dünyanın her yanındaki kullanıcılara hızlıca ulaştırırken, yüksek ölçeklenebilirlik, güvenlik ve esneklik kazanırsınız. Elbette, her ek katman gibi CloudFront da mimarinize biraz karmaşıklık ekleyecektir; bu yüzden gerçekten ihtiyaç duyduğunuz özellikler (önbellekleme, coğrafi dağıtım, WAF, vs.) varsa kullanılmalıdır. AWS, edge-optimized API Gateway seçeneğini basit durumlar için sunmuş olsa da, özelleştirilebilir CloudFront dağıtımı birçok ek fayda sağlayabilir.

Not: API Gateway’in WebSocket API gibi türleri de CloudFront arkasında çalışabilir, ancak WebSocket için CloudFront distribution yerine API Gateway’in kendisi edge konumlu çalıştığından genelde ayrıca CloudFront gerekmez. REST ve HTTP API’lar için CloudFront entegrasyonu yaygındır.

6. Güvenlik ve Erişim Kontrolleri

CloudFront, içerik dağıtımında sadece performans değil, güvenlik ve erişim denetimleri konusunda da çeşitli özellikler sunar.

Restrict Viewer Access (İstemci Erişimini Kısıtlama)

Eğer dağıttığınız içerik herkese açık olmaması gereken, yalnızca belirli kullanıcılara (örneğin ödeme yapmış abonelere veya şirket içi çalışanlara) özel bir içerik ise CloudFront’un Private Content özelliğini kullanabilirsiniz. Bu özellik etkinleştirildiğinde, CloudFront üzerinden gelen isteklerin imzalı URL’ler veya imzalı cookie’ler taşımasını zorunlu kılar. Yani, her istemci isteği, önceden sizin tarafınızdan oluşturulmuş geçerli bir signature (dijital imza) içermedikçe CloudFront o içeriği sunmaz.

CloudFront üzerinde bir dağıtım ayarlarında “Restrict Viewer Access” seçeneğini Yes yaptığınızda, artık o dağıtım altındaki içeriklere doğrudan (imzasız) erişim engellenir. Bu noktada iki mekanizma vardır:

• Signed URL (İmzalı URL): Her bir dosya veya yol için, süreli ve imzalı özel URL’ler oluşturursunuz. URL’nin sonuna eklenen imza, son kullanma zamanı ve opsiyonel olarak IP kısıtı gibi parametreler içerir. İstemci bu özel URL ile CloudFront’a istekte bulunduğunda CloudFront, URL içindeki imzanın geçerliliğini kontrol eder (bunun için önceden tanımladığınız Trusted Key Group içindeki public key’leri kullanır). İmza doğrulanır ve süre geçerli ise içerik teslim edilir; aksi halde 403 Forbidden hatası döner.

• Signed Cookies (İmzalı Çerezler): Birden çok dosyaya erişim izni vermek istediğinizde her dosya için ayrı URL üretmek yerine, CloudFront’un domaini için kullanıcı tarayıcısına imzalı bir cookie yerleştirebilirsiniz. Bu cookie, o kullanıcıya belirli bir süreyle (örn. 1 saat) dağıtımdaki korumalı içeriklere erişim hakkı tanır. Sonraki isteklerinde CloudFront cookie’yi okuyarak yetkisini doğrular. Bu yöntem, örneğin bir video sitesinde tek oturum açma ile birçok dosyayı ardışık izletmek için kullanışlıdır.

İmzalı URL/cookie mekanizmasında, imzaların oluşturulması ve yönetimi geliştiricinin sorumluluğundadır. AWS, imza oluşturmak için RSA anahtar çiftleri kullanır. Siz bir public-private key çifti oluşturur, public key’i CloudFront dağıtımınıza (Key Group olarak) yüklersiniz. Ardından uygulamanızda bir kullanıcı izin aldığında (ör. ödeme yaptı), ona özel bir URL imzalayıp verirsiniz (private key ile). CloudFront, eline gelen imzalı isteği, kendisindeki public key ile doğrulayarak kontrol eder.

Bu şekilde, aslında içerik CloudFront edge sunucularında önbelleklense bile URL olmadan kimse doğrudan erişemez; URL de olsa imza olmadan erişemez. İmzanın geçerlilik süresini kısa tutarak (örneğin birkaç dakika) URL’nin paylaşılmasını anlamsız hale getirebilirsiniz (süresi dolar). Veya uzun süreli imzalarla (günler/haftalar) belirli kullanıcı gruplarına kalıcı erişim verebilirsiniz.

Örnek Senaryo: Bir yazılım firmasısınız ve belirli ücretli müşterilere yazılım indirme linkleri sunuyorsunuz. Bu dosyalar S3’te private olarak duruyor ve CloudFront ile dağıtılıyor. “Restrict Viewer Access”i açıp sadece imzalı URL ile erişim moduna geçirirsiniz. Kullanıcı ödeme yaptığında, uygulamanız ona https://d111111abcdef8.cloudfront.net/software/setup.exe?Expires=1700000000&Signature=abc123...&Key-Pair-Id=KABCDEFGHI gibi karmaşık bir URL oluşturur. Bu URL’de son kullanma zamanını (Expires) ve imzayı görür. Kullanıcı bu linke tıkladığında CloudFront imzayı kontrol eder, doğru ise S3’ten dosyayı çekip sunar. Linki kopyalayıp paylaşırsa bile, süre dolunca çalışmaz hale gelir. Bu şekilde, içerik sadece izni olanlara, belirli bir zaman aralığında sunulmuş olur.

CloudFront imzalı URL/cookie özelliği, S3 ile birlikte kullanıldığında Origin Access Control/Identity ile de güçlendirilir (S3’ü tamamen private yapıp sadece CloudFront’un okumasına izin verebilirsiniz). Bu sayede kullanıcılar CloudFront korumasını aşarak doğrudan S3’ten de çekemezler. Tüm istekler CloudFront üzerinden ve CloudFront da sadece imzalı şekilde çalışır. Sonuç olarak, CloudFront ile güvenli dağıtım yaparak paralı içerik, lisanslı video, üyeye özel belge gibi varlıklarınızı koruma altına alabilirsiniz.

Coğrafi Erişim Kontrolü (Geo-Restriction)

CloudFront, istemcinin IP adresine göre bulunduğu ülkeyi belirleyerek coğrafi kısıtlamalar uygulamanıza imkân tanır. Dağıtım ayarlarında Geographic Restrictions kısmında iki moddan birini seçebilirsiniz: Whitelist (Allow List) veya Blacklist (Block List).

• Allow List (İzin Listesi – Beyaz Liste): Sadece belirttiğiniz ülkelerden gelen kullanıcıların içeriğe erişmesine izin verir; diğer tüm ülkeleri bloklar. Örneğin yalnızca Türkiye ve Almanya’ya içerik sunmak istiyorsanız bu iki ülkeyi allow list’e eklersiniz. Başka bir ülkeden istek gelirse CloudFront isteği reddeder.

• Block List (Yasaklı Liste – Kara Liste): Belirttiğiniz ülkelerden gelen erişimleri engeller, diğer tüm ülkeler erişebilir. Örneğin içerik dağıtım hakkınız olmayan veya yüksek risk gördüğünüz 5 ülke var, bunları block list’e ekleyerek sadece o ülkeleri kısıtlayabilirsiniz; diğer herkese servis devam eder.

CloudFront, kullanıcının ülkesini IP adresine göre bir veritabanıyla eşler. Bu eşlemenin yaklaşık %99.8 doğruluk payı vardır (bölgeye göre değişebilir). Eğer ülke tespit edilemezse (veritabanında yoksa IP aralığı), CloudFront o isteği izin verir (yani belirsiz durumları engellemiyor). Ülke kısıtlaması, dağıtımdaki tüm içerikler için topyekûn uygulanır; eğer içeriklerinizin bir kısmına farklı kural uygulamak isterseniz, bunu farklı CloudFront dağıtımlarına bölmeniz veya Lambda@Edge gibi yöntemlerle özel mantık yazmanız gerekir.

Örnekler:

• Küresel bir streaming servisi, lisans anlaşmaları gereği sadece belirli ülkelerde yayın yapabiliyor diyelim. Bu durumda CloudFront allow list kullanarak yalnızca lisanslı olduğu ülkeleri listeleyebilir. Örneğin dağıtım ayarlarından “Allow List: USA, CAN, GBR, AUS” seçerse, bu dört ülke dışından gelen istekler 403 Forbidden ile reddedilir.

• Bir başka senaryoda, bir bankanın iç uygulaması CloudFront ile dağıtılıyor ve sadece Türkiye içinden erişim olsun isteniyor. Allow list’e TR (Türkiye) eklenerek yurt dışı erişimler engellenebilir. Tam tersi şekilde, örneğin bir medya sitesi bazı ülkelerden gelen trafiğin bot saldırısı olduğunu düşünüp geçici olarak o ülkeleri block list’e alabilir.

Coğrafi engelleme uygulandığında, CloudFront reddedilen isteklere varsayılan olarak 403 durum kodu döndürür. İsterseniz Custom Error Page özelliğiyle kullanıcıya özel bir mesaj sayfası gösterebilirsiniz (örn. “Bu içerik bulunduğunuz ülkede sunulamıyor” gibi bir HTML sayfası). Ayrıca bu hata yanıtlarının ne kadar süre cache’leneceğini de (default 10 sn) ayarlayabilirsiniz.

CloudFront erişim loglarında, coğrafi nedenle reddedilen istekler 403 koduyla görünecektir ancak 403’ün sebebini loglardan direkt anlamak mümkün değildir (403 başka nedenle de olabilir). İsterseniz logları IP bazlı bir geolocation servis ile post-process ederek hangi 403’lerin geo-block kaynaklı olduğunu çıkarabilirsiniz.

Sonuç olarak, Geo Restriction özelliği içerik dağıtımınızı coğrafi olarak kontrol altında tutmanızı sağlar. Bu sayede lisans, telif, yasa veya hedef kitle sınırlamaları gibi gereksinimleri kolayca uygulayabilirsiniz. Üstelik bu işlem CloudFront seviyesinde yapıldığı için istemci daha içeriğe erişmeden engellenmiş olur, orijin sunucuya hiç yük binmez. Coğrafi kısıtlamaları daha hassas (ülke altı, şehir bazlı) uygulamak isterseniz CloudFront ile Lambda@Edge veya üçüncü parti geolocation API’ları kullanarak kendi mantığınızı da implemente edebilirsiniz, ancak basit ülke engelleme için CloudFront’un yerleşik özelliği yeterlidir.

Diğer Güvenlik Özellikleri

CloudFront, yukarıda anlatılan imzalı URL ve coğrafi filtreleme dışında, güvenlikle ilgili birçok entegrasyona sahiptir:

• AWS WAF Entegrasyonu: CloudFront dağıtımlarınıza Web Application Firewall (WAF) kuralları uygulayabilirsiniz. Bu sayede SQL enjeksiyonu, XSS, kötü amaçlı botlar veya belirli IP engellemeleri gibi gelişmiş korumaları dağıtım seviyesinde alırsınız. WAF, CloudFront ile tam entegre çalışır ve kural eşleşmeleri anında edge’de uygulanır (orijine ulaşmadan).

• HTTPS Zorunlu Kılma: CloudFront dağıtım ayarlarında Viewer Protocol Policy’yi “Redirect HTTP to HTTPS” yaparak tüm kullanıcıları HTTPS’e yönlendirebilir veya “HTTPS Only” ile direkt HTTP isteklerini reddedebilirsiniz. Bu, verinin şifrelenmesi ve güvenliği için önemlidir.

• Origin Access Control/Identity (S3 için): CloudFront ile S3’ü kullanıyorsanız, S3 bucket’ınızı public erişime kapatıp sadece CloudFront’un okuma yetkisi olması için OAC/OAI yapılandırabilirsiniz. Bu, CloudFront’ı baypas ederek doğrudan bucket’tan erişimi engeller.

• Response Header Policy: CloudFront modern özellikleri arasında, güvenlik header’ları eklemeye yarayan Response Header Policy’ler bulunur. Örneğin HSTS (Strict-Transport-Security), Content-Security-Policy, X-Frame-Options gibi header’ları CloudFront uç noktada ekleyerek tüm yanıtlarınızın bu güvenlik header’larıyla gelmesini sağlayabilirsiniz.

• Field-Level Encryption: CloudFront, hassas form alanlarını (kredi kartı numarası gibi) istemci tarafında public key ile şifreleyip orijine şifreli iletme özelliği sunar. Bu sayede uçtan uca belirli veri parçaları sadece hedef sunucu tarafından çözülebilir.

• DDoS Koruması: CloudFront dağıtımları AWS Shield varsayılan korumasından faydalanır (özellikle dünya genelinde dağıtık yapıda olduğu ve büyük kapasitede isteği emebildiği için). Shield Advanced abonesiyseniz CloudFront dağıtımlarınızı kapsayacak şekilde gelişmiş DDoS koruması ve 24/7 ekip desteği alabilirsiniz. Unutmayın, CloudFront’un kendisi de büyük oranda DDoS’a dayanıklı bir ön uç katmanıdır.

• Özel SSL ve Ciphers: CloudFront, TLS müzakeresinde hangi protokol ve şifre kümelerini kullanacağını da belirlemenize izin verir (Security Policy ayarı). Örneğin yalnızca TLSv1.2+ kullanımı, eski tarayıcı desteği vb. seçilebilir. Bu da güvenlik vs uyumluluk dengesini ayarlamada yardımcıdır.

Özetle, CloudFront ile içeriğinizin kimlere, nasıl ulaşacağı konusunda ince ayarlar yapabilirsiniz. Hem ticari senaryolarda (ör. bölgesel lisans, ödeme duvarı) hem de kurumsal güvenlik gereksinimlerinde (ör. sadece şirket ağına açık, hassas veriler şifreli) CloudFront’un bu kontrol özelliklerini etkin kullanmak gerekir.

7. Canlı Yayın ve Medya Dağıtımı

CloudFront, sadece statik dosyalar için değil, video akışı (streaming) ve canlı yayın senaryoları için de optimize edilmiş özellikler sunar. Yüksek bant genişliği gerektiren medya içeriklerini, küresel izleyicilere düşük gecikme ve yüksek kalitede ulaştırmak için CloudFront sıkça kullanılır.

On-Demand Video Streaming: Örneğin bir video platformunuz var ve kullanıcılar istedikleri zaman video izliyor. Bu durumda videolarınızı çeşitli bitratelerde parçalara (segmentlere) ayırıp bir origin sunucusunda barındırırsınız (S3, MediaPackage veya kendi medya sunucunuz olabilir). CloudFront, bu video segmentlerini ve manifest dosyalarını kullanıcıya en yakın edge’den sunarak oynatmanın kesintisiz ve akıcı olmasını sağlar. CloudFront’un desteklediği başlıca isteğe bağlı (VoD) streaming protokolleri:

• Apple HLS (HTTP Live Streaming): .m3u8 oynatma listeleri ve .ts/.m4s segmentleriyle adaptif bitrate sağlayan, HTTP tabanlı yaygın protokoldür. CloudFront, HLS içeriğini (özellikle AWS Elemental MediaPackage ile birlikte) sorunsuz dağıtır. HLS, canlı yayınlarda da kullanılır.

• DASH (MPEG-DASH): .mpd manifest ve segmentler ile benzer adaptif streaming protokolü. CloudFront üzerinden DASH içerik de iletilebilir.

• Microsoft Smooth Streaming: CloudFront 2014’ten beri Microsoft Smooth Streaming’i doğal olarak destekler. Smooth Streaming .ism manifest ve .ismv/.isma fragmentlerini HTTP ile sunar. CloudFront dağıtımınızda Smooth Streaming seçeneğini ilgili cache behavior’da etkinleştirirseniz, CloudFront Smooth istek URL’lerini (ör. BigBuckBunny.ism/Manifest) tanır ve bir medya sunucusu gerektirmeden S3 gibi bir origin’den bu parçaları çekip uygun şekilde iletiraws.amazon.com. Bu, ekstra bir medya sunucu (IIS Media Services) çalıştırmaksızın adaptif yayın yapmanızı sağlar.

• Adobe HDS (HTTP Dynamic Streaming): Çok kullanılmasa da .f4m manifest kullanan Adobe protokolü de CloudFront üzerinden normal dosya dağıtımı şeklinde çalışabilir.

• RTMP (Real Time Messaging Protocol): CloudFront geçmişte RTMP streaming distribution desteği sunuyordu (FMS/Flash tabanlı eski protokol). Ancak Adobe Flash’ın devri kapandığından AWS bu desteği sonlandırdı. Şu an CloudFront RTMP dağıtımları yeni oluşturulamıyor, yerine HTTP tabanlı modern protokoller öneriliyor.

Canlı Yayın (Live Streaming): Canlı bir etkinliği (örneğin spor maçı, konser veya canlı yayın platformu akışı) dünya çapına iletmek için CloudFront ideal bir dağıtım katmanıdır. Genellikle canlı yayın mimarisi şöyle olur: Bir yayın kaynağınız (kamera/encoder) yayını AWS Elemental MediaLive gibi servislere gönderir, oradan MediaPackage veya MediaStore ile çoklu bitrate’te HLS/DASH segmentleri üretilir. CloudFront da bu paketleyici origin’in önüne konur ve izleyiciler media player’larıyla CloudFront URL’lerinden segmentleri çeker. CloudFront’un geniş ağı sayesinde, on binlerce eşzamanlı izleyici bile farklı coğrafyalardan gecikmesiz şekilde beslenir; tüm yük merkezi origin yerine edge’ler tarafından karşılanır.

CloudFront canlı yayınlarda şu avantajları getirir:

• Düşük Gecikme ve Buffer Azaltma: İzleyiciler en yakın edge’den segmentleri aldığı için ağ gecikmeleri minimuma iner. Bu, özellikle canlı spor gibi birkaç saniyenin bile önemli olduğu durumlarda kritik. CloudFront ayrıca segment dosyaları gelir gelmez iletmeye başlar (chunked transfer); böylece oynatıcı bir segmenti indirirken segmentin tamamını beklemez, anında yayın ilerler.

• Ölçekleme: CloudFront, trafik patlamalarını otomatik karşılar. Bir anda milyonlarca kullanıcı bağlansa bile, AWS’nin global ağı bu trafiği dağıtır. Origin’inize çok sınırlı sayıda istek gider (her edge her segmenti bir kez çekip binlerce kullanıcıya hizmet edebilir). AWS’in dünya çapındaki omurgasıyla omuzlandığı için, internet erişim noktalarında tıkanma ihtimali de azalır.

• Protokol Desteği: Yukarıda bahsedilen adaptif protokoller (HLS, DASH, Smooth) canlı modda sorunsuz çalışır. Örneğin HLS’de her 6 saniyede bir yeni .ts segmenti üretilirken CloudFront bunları anında cache’leyip yerel izleyicilere sunar. CloudFront bu segmentleri bir süre de tutacağı için, yayın anında yetişemeyen bir izleyici geri sarıp yakın geçmişi tekrar izleyebilir (DVR özelliği) – segmentler TTL dolana kadar edge’de kalır.

• Kesintisiz Deneyim: CloudFront, paket kaybı veya bölgesel internet sorunlarına karşı çok dayanıklıdır. Örneğin bir ülkedeki bir ISP ile olan bağlantıda sorun çıksa bile, kullanıcı diğer yakındaki edge üzerinden çekmeye devam edebilir (genellikle DNS yönlendirmesi otomatik optimize olur). Bu da canlı yayının olabildiğince kesintisiz kalmasını sağlar.

• Güvenlik ve Dağıtım Kontrolü: CloudFront ile canlı yayınlarınızı da coğrafi kısıtlamaya tabi tutabilir, imzalı URL ile sadece bilet alanlara izletmek gibi kontroller yapabilirsiniz. Örneğin bir canlı konser yayını, satın alan kullanıcılara özel token ile izlenebilir hale getirilebilir (CloudFront signed cookie ile). Ayrıca HTTPS üzerinden yayın akışı güvenceye alınır ki üçüncü taraflar akışı çalamasın.

Smooth Streaming Özelinde: Microsoft Smooth Streaming protokolünü kullanıyorsanız, CloudFront dağıtımınızda bir cache behavior’da Smooth Streaming: Yes seçeneğini işaretlemelisiniz. Bu durumda CloudFront, istemciden gelen manifest isteklerini ve fragment isteklerini özel şekilde yönlendirir. Aslında perde arkasında CloudFront, Smooth Streaming istemci manifest isteği (Manifest) geldiğinde arka planda orijine bir .ism ve ardından istenen fragmentler için .ismv isteklerini yapar. AWS bloguna göre CloudFront, Smooth Streaming URL yapısını tanır ve origin tarafında ekstra bir medya sunucusu ihtiyacını ortadan kaldırır. S3 gibi bir origin üzerinde .ism, .ismv dosyaları barındırarak streaming yapabilirsiniz. CloudFront Smooth Streaming desteği geldiğinden beri Amazon’un kendi hizmetleri (ör. Amazon Prime Video) bile CloudFront’u bu şekilde kullanmıştır.

Medya İçin Önbellek Ayarları: Video segmentleri genelde kısa süre aralıklıdır (her segment 2-6 saniye arası içerik taşır). Bu dosyalar için çok uzun TTL gerekmez, çünkü yayın ilerledikçe eski segmentler önemini yitirir. Ancak canlı yayında DVR özelliği isteniyorsa, CloudFront TTL’ini biraz daha uzun tutup (örn. 1 saat) izleyicilerin yayını geri sarmasına izin vermek mümkün olur – eski segmentler edge’de tutulduğu için orijine dönmeden oynatma yapılabilir. Tabii bu, bellek kullanımı ile dengelenmeli (çok uzun TTL edge önbelleğini doldurabilir).

Canlı Olmayan Medya (VoD) Desteği: CloudFront ile büyük video dosyalarını isterseniz progressive download şeklinde de sunabilirsiniz. Yani dosyanın tamamı tek parça ise, CloudFront onu da cache’ler ve kullanıcıya iletir. Ancak adaptif streaming protokolleri günümüzde daha verimlidir. CloudFront, VoD platformlarında örneğin birkaç TB’lık 4K filmleri bile rahatlıkla dünya geneline dağıtır. Netflix, Disney+ gibi devler CloudFront benzeri CDN yapılarıyla bu işi çözer. Adaptif protokoller sayesinde CloudFront, uç kullanıcıya uygun bitrateli segmentleri seçer (aslında bu seçim istemci tarafından yapılır ama CloudFront her kalite segmentini ayrı cache’leyerek hızlı sunar).

Örnek: Bir haber sitesi, canlı yayın yapacak (bir basın toplantısı). MediaLive ile RTMP ingest alıyor, MediaPackage bunu HLS’e çeviriyor. CloudFront’u MediaPackage’ın endpoint’ine bağladılar. İzleyiciler https://dxxx.cloudfront.net/live/playlist.m3u8 adresinden yayını alıyor. Yayın başladığında belki 100 kişi vardı, fakat 5 dakika sonra 50 bin kişi oldu. CloudFront bu trafiği otomatik olarak kenarlara yaydı, MediaPackage’a belki her segment için birkaç yüz istek gitti sadece (her edge bulunduğu bölgedeki tüm izleyiciler için bir kez aldı segmenti). Sonuç: Yayın kesintisiz aktı, merkez sunucu yükü değişmedi, kullanıcılar da coğrafi olarak yakın edge’den akışı izlediği için takılma/arıza yaşanmadı.

Sonuç olarak, CloudFront medya dağıtımında yüksek performanslı, ölçeklenebilir ve güvenilir bir altyapı sunar. İster bir video streaming startup’ı olun, ister küresel canlı etkinlik yayını yapın, CloudFront’un CDN kabiliyeti sayesinde kullanıcılarınıza pürüzsüz bir deneyim sağlayabilirsiniz. Ek olarak, AWS Elemental Media Services (MediaPackage, MediaStore, CloudFront kombinasyonu) ile tam uçtan uca yayın çözümleri de elde edilebilir. CloudFront dağıtımınızı doğru protokol ve ayarlarla yapılandırdığınızda (örn. Smooth Streaming on, TTL’ler ayarlı, geoblocking vs.), gerisini AWS altyapısının gücüne bırakabilirsiniz.