Aurora Serverless v2 Nasıl Çalışır: Mimariye Derin Bakış

Aurora Serverless v2, çoğu zaman provisioned Aurora’dan bağımsız, ayrı bir veritabanı ürünüymüş gibi tanıtılır. Bu çerçeve mühendisleri yanlış varsayımlara götürür: replika sayısının otomatik arttığı, ölçekleme anında bağlantıların düştüğü, her ölçeklemede cache’in soğuduğu sanılır. Üçü de doğru değil; ama Kasım 2024’ten beri bir dördüncü kısmen doğru: sıfıra ölçekleme bir soğuk başlangıç yolu ima ediyor. Altta yatan gerçek şu: Serverless v2, provisioned cluster’ların da üzerinde çalıştığı aynı Aurora işlem ve depolama altyapısına eklenmiş bir scaling daemon ve faturalama sarmalayıcısıdır.

Adlandırma üzerine kısa bir not#

Nisan 2026’da AWS, “Aurora Serverless v2” adını “Aurora serverless” olarak değiştirdi. AWS Database Blog’un sıfıra ölçekleme duyuru yazısının başında şu banner duruyor: “April, 2026: Aurora Serverless v2 has been renamed Aurora serverless. No action required.” Eski v1 ürünü hâlâ ayrı bir teklif olarak duruyor ve aşamalı olarak kullanımdan kaldırılıyor. Okurların büyük kısmı hâlâ “Aurora Serverless v2” adıyla arıyor; dokümantasyon URL slug’ları da içeride v2 ifadesini korumaya devam ediyor, dolayısıyla aşağıda aynı terim kullanılıyor. “Serverless v2” geçtiği her yerde, AWS’in artık yalnızca “Aurora serverless” dediği ürün kastediliyor.

Mimari açıdan bu yeniden adlandırma, baştan beri doğru olan bir şeyi netleştiriyor: tek bir Aurora var; “serverless” ise onun üzerine eklenmiş bir faturalama ve çalıştırma modu. Alttaki işlem ve depolama katmanı 2014’ten bu yana provisioned cluster’ları besliyor. Bu çerçeveyi anlamlı şekilde zorlayan tek mekanizma sıfıra ölçekleme.

Depolama katmanı#

Aurora’nın performansı, dayanıklılığı veya ölçeklenmesi üzerine depolama katmanından başlamayan her tartışma kafa karışıklığıyla biter. Aurora’yı Aurora yapan depolama katmanıdır; işlem katmanı, çoğu açıdan görece sadedir. Aurora Serverless v2 bu katmanı dokunmadan devralır. Serverless v2 dokümantasyonu bu denkliği açıkça ifade ediyor: “Aurora serverless storage has the same reliability and durability characteristics as described in Amazon Aurora storage. That’s because the storage for Aurora DB clusters works the same whether the compute capacity uses Aurora serverless or provisioned.”

Üç availability zone’a yayılmış altı kopya#

Bir Aurora cluster volume, tüm verinin altı kopyasını üç availability zone’a yayarak saklar; bu, cluster’da kaç DB instance olduğundan bağımsızdır. Replikasyon faktörü işlem sayısından bağımsızdır. Tek instance’lı bir cluster, on beş instance’lı bir cluster’la aynı altı yönlü replikasyonu alır. Volume mantıksal olarak cluster’daki tüm işlem instance’larından erişilebilen paylaşılan bir cihazdır; talep üzerine 10 GiB’tan 128 TiB’a kadar, güncel Aurora PostgreSQL (17.5+, 16.9+, 15.13+) ve Aurora MySQL 3.10+ sürümlerinde ise Temmuz 2025’teki tavan artışıyla 256 TiB’a kadar otomatik olarak büyür.

Bu 6/3 yerleşimi, Verbitski ve arkadaşlarının SIGMOD 2018 makalesinde formalize ettiği quorum semantiğini mümkün kılar: yazma işlemleri altı kopyadan dördünün onayını gerektirir, okumalar altıdan üçünü. Asimetri kasıtlıdır. Üç AZ ile sistem, bir AZ’nin tamamının ve başka bir AZ’deki bir kopyanın kaybına rağmen yazmaya devam edebilir. Bir AZ’nin tamamı kaybedildiğinde de okumalar sürer. Depolama 10 GiB’lık “protection group”lara parçalanmıştır, her biri altı yönlü replike edilir ve birbirinden bağımsız onarılır; bu da kurtarma işlemlerinin volume bazında değil, protection group bazında çalışması anlamına gelir.

Log, veritabanının kendisidir#

Aurora’nın en belirleyici tasarım kararı, işlemden depolamaya ağ üzerinden yalnızca redo log kayıtlarının iletilmesidir; tam veri sayfaları değil. Bir işlem (transaction) bir compute instance üzerinde commit edildiğinde, instance etkilenen protection group’lar için tüm altı depolama düğümüne log kayıtlarını gönderir. Depolama düğümleri sayfaları talep üzerine materyalize etmek için log kayıtlarını uygular; compute instance sayfa yazma yolunda değildir. SIGMOD 2017 bu prensibi “log is the database” sloganıyla tanıtır ve sayfa gönderen geleneksel replikasyona kıyasla ağ trafiğindeki azalmayı sayılarla gösterir.

Buradan doğrudan üç sonuç çıkar. Birincisi, durum alt katmanda durduğu için işlem (compute) esnek olabilir; bir ölçekleme olayı sayfaları taşımak zorunda değildir, yalnızca işlem katmanının yakın log konumlarını yenilemesi yeterlidir. İkincisi, dayanıklılık tamamen instance yaşam süresinden bağımsız hâle gelir; bir compute instance işlem ortasında çökse bile, kurtarma depolamadaki log’tan ilerler. Üçüncüsü, read replika’lar bir replikasyon kanalı üzerinden writer’dan değil, aynı paylaşılan volume’dan okurlar; replika gecikmesi (replica lag) işlem yeniden oynatma değil, buffer pool invalidasyonlarının cluster içinde yayılmasıdır.

Serverless v2 üzerindeki etkisi#

Bu üç özelliğin hepsi Serverless v2 davranışının ön koşuludur. Yerinde ölçekleme mümkündür çünkü depolama altta paylaşılır ve dayanıklıdır. Sıfıra ölçekleme mümkündür çünkü dayanıklılık, çalışan herhangi bir compute instance’ın yokluğunda da yaşar. Karışık modlu cluster’lar işler çünkü her reader ve writer, instance ister provisioned ister serverless olsun, aynı cluster volume’a bağlanır. Serverless v2 dokümanları “depolama katmanı değişmedi” derken gerçek bir iş yapıyorlar: scaling daemon’u küçük tutan şey bu tek olgudur.

İşlem katmanı#

Aurora Serverless v2’nin işlem katmanı, provisioned Aurora ile aynı işlem altyapısının üzerinde, yalnızca esnek kapasiteyle çalışır. Kapasite birimi Aurora Capacity Unit, kısaca ACU’dur. AWS, 1 ACU’yu yaklaşık 2 GiB RAM ile orantılı CPU ve ağ kapasitesi olarak tanımlar; karşılaştırılabilir bir provisioned Aurora instance ile uyumlu olacak şekilde kalibre edilmiştir. Kapasite, minimum ve maksimum ile 0.5 ACU adımlarında belirtilen bir aralık olarak yapılandırılır. Güncel aralık 0 ACU ile 256 ACU arasıdır; 256 ACU tavanı 3 Ekim 2024’te duyuruldu, 0 ACU tabanı ise Kasım 2024’teki sıfıra ölçekleme duyurusuyla geldi.

Buffer pool (MySQL’de innodb_buffer_pool_size, PostgreSQL’de shared_buffers), o anki ACU değeriyle birlikte ölçeklenir. Instance büyürken buffer pool büyür; küçülürken küçülür. Bu alışılmadık bir durumdur: çoğu veritabanı buffer pool’u açılışta sabit bir tahsis olarak ele alır ve yeniden boyutlandırmak çevrim dışı bir işlemdir. Aurora’nın işlem katmanı, buffer pool belleğinin yerinde yeniden boyutlandırılması için mühendisliği yapılmıştır. Scaling daemon’un etkili olabilmesini sağlayan yetenek budur. Buna karşılık max_connections açılışta sabittir ve cluster için yapılandırılan maksimum ACU değerinden türetilir. Aşağı ölçekleme max_connections değerini düşürmez, yani instance küçüldüğünde kurulmuş bağlantılar düşmez. Bir veritabanı işlem katmanı için doğru varsayılan budur. Anlamı şu: maksimumu 4 ACU olan bir cluster, gerçekte hangi noktada çalıştığından bağımsız olarak max_connections’ı 4 ACU’ya uygun değerde yapılandırır.

Caspian altyapısı#

Aurora işlem birimlerini fiziksel host’lar üzerine yerleştiren ısı yönetimi (heat management) altyapısının iç adı Caspian’dır. AWS dokümanları bu adı kullanmaz; herkese açık kanonik referans, Marc Brooker’ın aşırı abone (oversubscribed) host’lardaki ısı yönetimini ayrıntılı tartıştığı Resource Management in Aurora Serverless (yeni sekmede açılır) yazısıdır. Caspian’ın işi, çok sayıda Aurora compute instance’ını paylaşılan host’lara sığdırmak ve bir instance’ın talebi komşularının verebileceğinden daha hızlı büyüdüğünde onu host’lar arasında taşımaktır. Cluster perspektifinden bu görünmezdir: bir ölçekleme olayı ACU tahsisini büyütür; ya o anki host’un kapasitesi yeter ya da Caspian instance’ı boşluğu olan bir host’a taşır.

Kaçınılması gereken ifade şudur: “bu, önceden hazırlanmış instance’lardan oluşan sıcak bir havuzdur.” O, Serverless v1 modeliydi ve v2 öyle çalışmıyor. Atanmayı bekleyen sıcak yedek instance havuzu yoktur. Her biri pek çok kiracı instance çalıştıran bir Aurora compute host filosu ve yük değiştikçe kaynakları bu host’ların içinde ve arasında yeniden dağıtan bir altyapı vardır. Yukarı ölçekleme hızlı görünür çünkü mevcut instance’a o anki host üzerinde daha fazla bellek ve CPU tahsis edilir ya da instance boşluğu olan bir host’a taşınır.

Scaling daemon#

Scaling daemon, yükü gözlemleyen ve ACU tahsisini ayarlayan bileşendir. Girdileri CPU, bellek ve ağ kullanımıdır; AWS dokümanları bunları topluca “the load” olarak adlandırır. Çıktısı, yapılandırılan minimum ve maksimum ile sınırlanmış bir hedef ACU değeridir. Tetikleyiciler sayısal olarak yayımlanmamıştır; dokümanlar, kapasitenin bu üç boyuttan herhangi birinde sıkıştığında ya da Aurora’nın ölçeklemeyle çözebileceği performans sorunlarını algıladığında ölçeklemenin gerçekleştiğini söyler. Her writer ve her reader instance birbirinden bağımsız ölçeklenir.

Ölçekleme yerinde gerçekleşir. Dokümanlar her durumda sıfır bağlantı kaybı sözü vermez, ama tipik bir ölçekleme olayı failover içermez, motoru yeniden başlatmaz ve kurulmuş oturumları düşürmez. ACU değeri değiştikçe buffer pool boyutu da ayarlanır. Motor sayfaları boşaltıp yeniden yüklemez; alttaki bellek tahsisi büyür veya küçülür, motorun kullanılabilir önbellek alanına dair görüşü de buna uyar.

AWS sayısal bir ölçekleme gecikmesi SLA’i yayımlamaz. Dokümanlar “rapidly” sözcüğünü kullanır ve ölçeklemeyi saniye düzeyinde, adım adım gerçekleşen bir süreç olarak tanımlar. Beklentiyi kalibre etmek için doğru yer burasıdır: 1 ACU’dan 32 ACU’ya geçiş anlık değildir çünkü daemon adımlarla tırmanır, ancak her bir adım hızla tamamlanır.

Aurora Auto Scaling: kasıtlı bir eksik#

CPU kullanımına göre yeni reader replika ekleyen eski Aurora Auto Scaling özelliği, Serverless v2 üzerinde açıkça desteklenmemektedir. Requirements dokümantasyonu şöyle der: “Aurora Auto Scaling isn’t supported. This type of scaling adds new readers to handle additional read-intensive workload, based on CPU usage. However, scaling based on CPU usage isn’t meaningful for Aurora serverless.”

Bu, doküman ekibinin mimari modeli yazılı olarak onaylamasıdır. Serverless v2’de ölçekleme birimi instance’ın kendisidir. Her reader, daha fazla kapasiteye ihtiyaç duyduğunda kendi kendini büyütür. Yeni reader eklemek hâlâ kasıtlı bir operatör eylemidir; tek bir instance’ın boyutundan bağımsız olarak karşılayamayacağı bir okuma eşzamanlılığı oluştuğunda yapılır. Otomatik ölçeklemenin sağladığı bir yetenek değildir. Yük altında bir Serverless v2 cluster’ının kendiliğinden reader ekleyeceğini bekleyen mühendisler, provisioned modelden analoji yaparak akıl yürütüyorlar; dokümanlar bu kapıyı açıkça kapatıyor.

CPU temelli replika ekleme Serverless v2 için “anlamlı” değil çünkü her Serverless v2 reader zaten CPU baskısına ACU tahsisini büyüterek yanıt veriyor. Yeni bir reader eklemek, ölçekleme tepkisinin üzerine daha yavaş, daha kaba taneli bir sinyali bindirirdi. Bu sınırlama bir tasarım kararını kayda geçiriyor: v2 mimarisi, v1 ve provisioned Aurora’nın harici bir denetleyiciyle yaptığı işi kendi içine almış.

Sıfıra ölçekleme: mimarideki tek dikiş yeri#

Sıfıra ölçekleme Kasım 2024’te kullanıma sunuldu. Minimum ACU’yu 0 olarak ayarlamak, --serverless-v2-scaling-configuration flag’i üzerindeki SecondsUntilAutoPause parametresi ile kontrol edilen bir otomatik duraklatma davranışı etkinleştirir; parametre 300 saniye ile 86.400 saniye arasında yapılandırılabilir. Yapılandırılan boş bekleme aralığı, niteliğe uygun bir etkinlik olmadan tamamlanırsa instance duraklatılır; sonraki bağlantı denemesinde geri açılır.

“İnce scaling daemon” çerçevesinin gerçekten zorlandığı tek nokta burasıdır. Orijinal Aurora tasarımı uzun ömürlü compute instance’ları varsayar; duraklatma ve geri açılma bu resmin içinde değildir. AWS bunun için daha derin bir uyku durumu ve ölçülü bir geri açılma yolu tasarladı; yine de dikiş yeri, duraklatma sonrası ilk isteğin gecikmesi olarak uygulama tarafında görünür.

Motor sürümü alt sınırı#

Sıfıra ölçekleme yeni motor sürümleri gerektirir: Aurora PostgreSQL en az 16.3, 15.7, 14.12 veya 13.15; Aurora MySQL en az 3.08.0. Aynı parameter family üzerindeki eski motor sürümleri sıfıra ölçekleme alamaz. Bu, mevcut bir filo üzerinde Serverless v2’yi değerlendirirken kolayca gözden kaçan türden bir gerekliliktir: örneğin Aurora PostgreSQL 15.4 çalıştıran bir cluster, Serverless v2’de çalışır, ama otomatik duraklatma devreye girmez.

Otomatik duraklatmayı engelleyen koşullar#

Otomatik duraklatma dokümantasyonu, bir duraklatmayı bloklayan koşulları listeler. Mimari olarak ilginç olanlar arasında şunlar var:

• Kullanıcı tarafından başlatılmış herhangi bir açık bağlantı. Yönetimsel health-check bağlantıları sayılmaz.
• Devam eden patching veya yükseltme işlemleri.
• PostgreSQL logical replication veya MySQL binlog replication açıksa: writer ve failover-tier-0 veya tier-1 reader’lar duraklamaz; bu yapılandırmada yalnızca failover önceliği 2 veya daha yüksek olan reader’lar duraklayabilir.
• Bazı yapılandırmalarda ilişkili bir RDS Proxy.

Replikasyon maddesi vurgulanmaya değer. Analitik, change data capture veya bölgeler arası yayılım için başka bir sisteme logical replication yapan bir cluster’ın writer’ı duraklayamaz. Bu doğrudur: writer duraklarsa, replikasyon akışı durur. Bu aynı zamanda yaygın bir üretim yapılandırmasının, yani aşağı akıştaki bir veri platformunu besleyen logical replication’ın, writer tarafındaki otomatik duraklatmayla yapısal olarak uyumsuz olduğu anlamına gelir.

Geri açılma mekanikleri#

Yakın geçmişteki bir duraklamadan tipik geri açılma gecikmesi yaklaşık 15 saniyedir. 24 saatten uzun süren bir duraklamanın ardından Aurora instance’ı daha derin bir uyku durumuna alır ve geri açılma gecikmesi yaklaşık 30 saniyeye veya daha fazlasına çıkar. Dokümantasyon, istemci connectTimeout değerinin en az 15 saniyeye, uzun duraklama olasılığı olan cluster’lar için en az 30 saniyeye ayarlanmasını önerir. Bu, sıfıra ölçeklemenin uygulama tarafındaki en görünür etkisidir ve özelliğin bir iş yüküne uyup uymadığını en doğrudan belirleyen olgudur: 15 saniyelik bir soğuk başlangıca tahammülü olmayan senkron bir istek yolu, birincil veritabanında sıfıra ölçeklemeyi kullanamaz.

Soğuk başlangıç etkisi#

Otomatik duraklatma dokümantasyonunda yük taşıyan bir cümle var: “a relatively small capacity and scales up from there. This starting capacity applies even if the DB instance had some higher capacity immediately before it was automatically paused.” Başka bir deyişle, geri açılma duraklama öncesi kapasiteyi geri yüklemez. Düşük bir ACU değerinde başlar ve scaling daemon’un yeniden tırmanmasına izin verir.

Bu cümle, buffer pool sıcaklığı hikâyesini baştan yazar. Olağan yerinde yukarı ve aşağı ölçeklemede buffer pool, ACU tahsisi ile boyut değiştirir, ama daha küçük boyutta zaten önbelleğe alınmış girdiler mümkün olduğunca korunur: yukarı ölçekleme bellek ekler, önbelleği silmez. Otomatik duraklatma sonrası instance soğuk başlar: buffer pool boştur, plan cache soğuktur ve ilk sorgular tam sayfa-getirme ve ayrıştırma maliyetlerini öder. Büyük sıcak çalışma kümesi olan iş yüklerinde sıfıra ölçeklemenin asıl bedeli, önbellek yeniden ısınırken dakikalarca süren bozulmuş gecikmedir. 15 saniyelik geri açılma, bu faturanın küçük kısmı.

Mimari dikiş yeri budur. Sıfıra ölçekleme, önbellek maliyetinin küçük olduğu düşük trafikli cluster’lar için, gecikmenin önemsiz olduğu geliştirme cluster’ları için ve yavaş bir ilk sorguyu absorbe edebilen read replika’lar için uygundur. Gecikmeye duyarlı trafik taşıyan, üretimdeki birincil veritabanında ise bedelsiz bir anahtar değildir.

Karışık modlu cluster’lar#

Tek bir Aurora cluster, Serverless v2 ve provisioned instance’ları herhangi bir kombinasyonda karıştırabilir. Depolama katmanı paylaşılır ve işlem katmanı modu ne olursa olsun aynı cluster volume’a bağlandığı için, instance’ları modlar arasında değiştirmek cluster düzeyinde değil instance düzeyinde bir işlemdir.

Üretimde iki yapı tekrarlanır:

Birincisi, provisioned writer ve Serverless v2 reader’lar. Bu, istikrarlı ve öngörülebilir yazma hızlarına ve değişken okuma yüklerine sahip iş yüklerine ya da Serverless v2 tavanının şu anda absorbe edebileceğinin ötesinde ölçekteki yazma iş yüklerine uyar. Provisioned writer, kararlı ve öngörülebilir yazma throughput’u verir; Serverless v2 reader’lar, okuma fan-out değişkenliğini operatör müdahalesi olmadan absorbe eder.

İkincisi, Serverless v2 writer ve provisioned reader’lar. Bu, dalgalı yazma ve kararlı, iyi anlaşılmış okuma profili olan iş yüklerine uyar. Serverless v2 writer, yazma dalgasıyla birlikte ölçeklenir; provisioned reader’lar, okuma tarafı için kararlı, öngörülebilir maliyet ve kapasite sağlar. Bu iki yapı, otomatik duraklatma sayfasında açıkça önerilen yapılandırmalardır; sırasıyla geliştirme/test sistemleri ve yüksek erişilebilirlikli üretim sistemleri için kanonik düzenler olarak sunulur.

Yükseltme yolu üzerine pratik bir not: bazı Aurora motor sürüm yükseltmeleri, eski minor sürümlerden başlarken provisioned writer ile başlamayı ve sonrasında Serverless v2’ye dönüştürmeyi gerektirir. Bu, sürüm-sürüm yükseltme ön koşullarının bir parçası olarak belgelenmiştir; doğru kontrol noktası requirements sayfasıdır. Serverless v2 dönüşümüyle birlikte bir major sürüm yükseltmesi planlayan ekipler, iki işlemin tek adımda olabileceğini varsaymamalıdır.

Katman yığınına bir bakış#

Diyagram bağımlılık açısından bilinçli olarak aşağıdan yukarı okunur. Depolama katmanı, geri kalanın üzerine kurulduğu temeldir. İşlem katmanı, Caspian-yönetimli bir host üzerinde belirli bir ACU tahsisinde çalışan Aurora motorudur. Scaling daemon, yükü gözlemleyen ve ACU tahsisini ayarlayan bir denetleyicidir. Faturalama yüzeyi, müşterinin faturada gördüğüdür. Her katman, altındaki depolama katmanına kıyasla incedir.

Mimariden gelen sınırlar#

Serverless v2’nin birçok sınırlaması doğrudan yukarıdaki mimariden çıkar. Requirements dokümantasyonu bunları sıralar.

Database Activity Streams (DAS) Serverless v2’de desteklenmiyor. DAS, provisioned Aurora’da uyumluluk ve denetim kullanım örnekleri için veritabanı etkinliğini Kinesis’e akıtır. Serverless işlem katmanında mevcut değil. DAS’ı zorunlu kılan uyumluluk gereksinimleri olan ekipler bu iş yüklerini bugün Serverless v2’de çalıştıramaz.

Aurora PostgreSQL için cluster cache management devre dışıdır. Writer üzerinde bir replika’nın önbelleğini önceden ısıtarak hızlı crash recovery sağlayan apg_ccm_enabled parametresinin Serverless v2 instance’larında etkisi yoktur. Özellik, önbellek içeriklerinin kararlı olduğu sabit boyutlu provisioned reader’lar için vardır; Serverless v2’de önbellek içeriği ACU değeriyle değişir ve önceden ısıtma anlamlı değildir.

Aurora Auto Scaling, yukarıda tartışıldığı gibi desteklenmez ve anlamlı değildir. Reader sayısı operatör tarafından yönetilir; reader başına kapasite otomatiktir.

Bölgesel kullanılabilirlik tek tip değildir. Supported regions and engines sayfası yetkili referanstır; son eklemeler (özellikle AWS GovCloud ve bazı yeni ticari bölgeler) özelliklerin duyuru tarihinden aylar sonra gelir. Daha az yaygın bölgelerde çalışan ekipler, sıfıra ölçeklemenin veya 256 ACU tavanının yerel olarak mevcut olduğunu varsaymadan önce bölgeler matrisine doğrudan bakmalıdır.

Motor sürüm gereksinimleri evrilmeye devam ediyor. Aurora MySQL 8.0, aurora-mysql8.0 parameter family ile destekleniyor. Aurora PostgreSQL 13’ten 17’ye, aurora-postgresql13 ile aurora-postgresql17 arasındaki family’lerle destekleniyor. Serverless v2 üzerinde PostgreSQL 17 desteği, birçok eski yazının ima ettiğinden daha yeni ve desteklenen sürüm kümesi değişmeye devam ediyor; güncel sürüm matrisi bölgeler sayfasında duruyor.

Kapanış#

Mimari dikiş yeri sıfıra ölçeklemedir. Tanıtıldığı gibi çalışır, ama geri açılma hem ACU düzeyinde hem önbellek düzeyinde soğuk başlar; bu kombinasyon, herhangi bir cluster’da özelliği açıp açmama kararını yönlendirmelidir.

Bu modelden çıkan tavsiye şu: iş yükü yeterince değişkense Serverless v2’yi seçin. Ölçüt, otomatik doğru boyutlandırmanın operasyonel kazancının paylaşılan ve aşırı abone edilmiş işlem üzerinde çalışmanın bedelini aşmasıdır. İş yükü kararlıysa, önbellek düzeyinde gecikmeye duyarlıysa veya serverless katmanın henüz desteklemediği DAS gibi özellikler gerekiyorsa provisioned Aurora’ya yönelin. Sıfıra ölçekleme, düşük trafikli ve geliştirme cluster’larında açılacak bir koldur; senkron kullanıcı trafiği taşıyan üretim writer’larında değil.

Kaynaklar#

• Using Aurora serverless (yeni sekmede açılır) - Aurora serverless dokümantasyonunun kanonik giriş noktası; tüm alt sayfalar buradan dallanır, URL slug’ı v2’yi korur.
• How Aurora serverless works (yeni sekmede açılır) - Ölçekleme tetikleyicileri, yerinde ölçekleme semantiği, provisioned ile depolama eşdeğerliği, karışık modlu cluster yapılandırmaları.
• Performance and scaling for Aurora serverless (yeni sekmede açılır) - ACU tanımı, buffer pool ölçekleme davranışı, max_connections semantiği, kapasite için CloudWatch metrikleri.
• Requirements and limitations for Aurora serverless (yeni sekmede açılır) - 0.5 ACU adımlarındaki kapasite aralığı, DAS ve Aurora Auto Scaling dahil desteklenmeyen özellikler, motor ve platform bağımlılıkları.
• Scaling to Zero ACUs with automatic pause and resume (yeni sekmede açılır) - Motor sürümü alt sınırı, otomatik duraklatmayı engelleyen koşullar, geri açılma gecikme rakamları, replikasyon-engelleme kuralları.
• Aurora storage and reliability (yeni sekmede açılır) - Üç AZ’a yayılmış altı kopya, cluster volume mekanikleri, otomatik yeniden boyutlandırma davranışı.
• Supported Regions and engines for Aurora serverless (yeni sekmede açılır) - Bölge ve motor sürüm kullanılabilirlik matrisi; hangi özelliğin hangi bölgede açık olduğunun yetkili listesi.
• Introducing scaling to 0 capacity with Amazon Aurora Serverless v2 (yeni sekmede açılır) - Otomatik duraklatmanın Kasım 2024 AWS Database Blog duyuru yazısı; Nisan 2026 yeniden adlandırma banner’ını taşır.
• Aurora Serverless v2 now supports up to 256 ACUs (yeni sekmede açılır) - 3 Ekim 2024 duyurusu, tavanı 128 ACU’dan 256 ACU’ya çıkardı.
• Amazon Aurora: Design Considerations for High Throughput Cloud-Native Relational Databases (SIGMOD 2017) (yeni sekmede açılır) - Verbitski ve arkadaşları; depolama katmanı, redo offload ve “log is the database” prensibini kapsayan kurucu Aurora mimari makalesi.
• Amazon Aurora: On Avoiding Distributed Consensus for I/O, Commit, and Membership Changes (SIGMOD 2018) (yeni sekmede açılır) - Verbitski ve arkadaşları; Aurora’nın 4/6 yazma ve 3/6 okuma quorum semantiğini formalize eder ve Paxos’un neden sıcak yolda olmadığını açıklar.
• Marc Brooker: Resource Management in Aurora Serverless (yeni sekmede açılır) - AWS Databases Principal Engineer; Caspian, aşırı abonelik ve Aurora Serverless’taki ısı yönetimi üzerine en erişilebilir açık yazı.
• Amazon Aurora design: cloud-native relational database (All Things Distributed) (yeni sekmede açılır) - Werner Vogels’in Aurora tasarım anlatısını çerçeveleyişi; bağlam için yararlı, Serverless v2’den öncedir.