Aurora vs RDS: Amazon Aurora Ne Zaman Tercih Edilmeli (Mimari ve Maliyet)

Amazon Aurora ile standart RDS arasında seçim yapmak basit değil. Aurora, 5x MySQL ve 3x PostgreSQL performansı, 128TB’ye kadar otomatik storage scaling ve %99.99 availability vaat ediyor. Ama I/O pricing modeline aşina olmayan ekipleri şaşırtabilecek ek karmaşıklık ve maliyetle geliyor.

Karar; workload özelliklerine, operasyonel gereksinimlere ve maliyet kısıtlarına bakıyor. High availability ya da beşten fazla read replica gerektiren production MySQL veya PostgreSQL workload’ları için makul varsayılan Aurora Standard. I/O, faturanın kabaca dörtte birini aştığında I/O-Optimized’a geç; engine bunların dışındaysa ya da workload küçük, öngörülebilir ve bütçesi darsa RDS’te kal.

Amazon Aurora Nedir?#

Amazon Aurora, MySQL ve PostgreSQL ile uyumlu cloud-native bir relational database engine. Standart RDS’in cloud altyapısında vanilla database’leri çalıştırmasının aksine, Aurora distributed cloud mimarisinden yararlanmak için sıfırdan inşa edildi.

Temel Mimari Farklar:

• Storage Ayrımı: Compute (database instance’ları) storage’dan (distributed layer) ayrılmış
• Otomatik Scaling: Storage 10GB’den 128TB’ye 10GB’lik artışlarla büyüyor, downtime yok
• Yerleşik Replication: Varsayılan olarak 3 Availability Zone’da verinin 6 kopyası
• Sınırlı Engine Desteği: Sadece MySQL ve PostgreSQL (Aurora diğer engine’leri desteklemiyor)

Aurora’nın AWS Veritabanı Ekosistemindeki Yeri#

Aurora, her biri belirli bir erişim pattern’i için tasarlanmış birçok AWS database servisinden biri.

Relational Veritabanları (SQL)#

Servis	Engine’ler	En İyi Kullanım
Amazon RDS	MySQL, PostgreSQL, MariaDB, Oracle, SQL Server, Db2	Standart relational workload’lar, geniş engine uyumluluğu
Amazon Aurora	Sadece MySQL, PostgreSQL	High availability, read-heavy workload’lar, cloud-native özellikler
Amazon Redshift	PostgreSQL-tabanlı	Data warehousing, analytics, OLAP workload’ları

NoSQL Veritabanları#

Servis	Tip	En İyi Kullanım
Amazon DynamoDB	Key-value, Document	Serverless uygulamalar, gaming, IoT, tek haneli milisaniye latency
Amazon DocumentDB	Document (MongoDB-uyumlu)	MongoDB workload’ları, JSON document storage
Amazon Keyspaces	Wide-column (Cassandra-uyumlu)	Cassandra migration’ları, time-series data
Amazon Neptune	Graph	Sosyal ağlar, fraud detection, knowledge graph’lar
Amazon Timestream	Time-series	IoT metrikleri, DevOps monitoring, uygulama telemetrisi

In-Memory ve Caching#

Servis	Tip	En İyi Kullanım
Amazon ElastiCache	Redis, Memcached	Caching, session storage, real-time analytics
Amazon MemoryDB	Redis-uyumlu	Dayanıklı in-memory database, mikrosaniye okuma

Özelleşmiş Servisler#

Servis	Amaç
Amazon QLDB	Değiştirilemez ledger, audit trail’leri, kriptografik doğrulama
Amazon OpenSearch	Full-text arama, log analytics, uygulama monitoring

Aurora’nın Uygun Olmadığı Durumlar#

• SQL Server, Oracle veya Db2 mi gerekiyor? → RDS kullan (Aurora bunları desteklemiyor)
• MongoDB uyumlu document storage mı gerekiyor? → DocumentDB kullan
• Scale’de tek haneli ms latency ile key-value mi gerekiyor? → DynamoDB kullan
• Data warehousing/analytics mi gerekiyor? → Redshift kullan
• Graph ilişkileri mi gerekiyor? → Neptune kullan
• Time-series data mı gerekiyor? → Timestream kullan

Aurora’nın Distributed Storage Mimarisi#

Aurora’nın storage layer’ı Protection Group’ları kullanıyor - 10GB’lık segment’ler üç availability zone’da altı kopya olarak replicate ediliyor. Bu tasarım, traditional replication overhead’i olmadan hızlı recovery ve high availability sağlıyor.

Quorum-Based Write’lar: Aurora, bir write’ın commit edilmesi için 6 kopyanın 4’ünden acknowledgment bekliyor. Yani tüm bir availability zone artı bir ek kopya kaybedilse bile write availability etkilenmiyor.

Redo Log Mimarisi: Aurora storage’a sadece redo log’ları gönderiyor, full data page’leri değil. Bu, traditional database’lerin full page’leri artı transaction log’ları yazmasına kıyasla write amplification’ı önemli ölçüde azaltıyor.

Self-Healing Storage: Storage layer otomatik olarak disk arızalarını tespit edip onarıyor, genellikle 10GB’lık bir segment’i manuel müdahale olmadan bir dakikanın altında recover ediyor.

Aurora vs RDS: Teknik Karşılaştırma#

Özellik	RDS (MySQL/PostgreSQL)	Aurora
Storage	Instance’lara bağlı EBS volume’lar	Distributed storage layer (6 kopya, 3 AZ)
Storage Scaling	Manuel, downtime gerektirir	Otomatik, 128TB’ye kadar, downtime yok
Replication	Binary/streaming (max 5 replica)	Log-based, shared storage (max 15 replica)
Replica Lag	Saniyeler ile dakikalar arası olabilir	Genellikle millisaniye
Write Metodu	Full page write + double-write buffer	Sadece redo log
Failover Süresi	1-2 dakika (DNS-based)	30-120 saniye, AWS driver’larla daha hızlı
HA SLA	%99.95 (Multi-AZ)	%99.99
Backup Etkisi	Snapshot sırasında I/O pause	Sürekli, performans etkisi yok

Write Performance Özellikleri#

Aurora’nın redo-log-only yaklaşımı write’lar için I/O operation sayısını azaltıyor. Traditional database’ler şunları yazıyor:

1. Storage’a data page
2. Storage’a transaction log
3. Double-write buffer’a data page (MySQL)

Aurora sadece redo log entry’sini yazıyor. Storage layer bu değişiklikleri asenkron olarak uygulayarak birçok workload için write amplification’ı 5-7x’ten yaklaşık 1x’e düşürüyor.

Ne Zaman Aurora, Ne Zaman RDS Seçilmeli#

Aurora’yı Şu Durumlarda Seç:#

• High availability önemliyse: Multi-AZ RDS’in %99.95’ine karşı %99.99 uptime SLA, sub-minute failover ve işin 1-2 dakikalık kesintiyi gerçekten tolere edemediği durumlar.
• Beşten fazla read replica’ya ihtiyaç duyan ya da read traffic write’lardan önemli ölçüde fazla olduğu için replication lag’in milisaniye seviyesinde kalması gereken bir servis, Aurora’nın shared storage layer’ından gerçek değer görüyor.
• Tahmin edilemeyen storage büyümesi bakım penceresini ortadan kaldırıyor: provisioning’i yönetmek istemeyen, beklenmedik spike’lar bekleyen ya da over-provisioning maliyetlerinden kaçınmak isteyen ekipler, bunun yerine otomatik scaling elde ediyor.
• Multi-region read veya failover gerekiyorsa. Sub-second lag ile cross-region replication, hızlı disaster recovery ve global read distribution, Aurora Global Database’in var oluş nedeni.
• Günlük traffic’in 10x değiştiği ya da kimsenin kullanmadığında hiçbir maliyet çıkarmaması gereken non-production environment’lar, Serverless v2’nin auto-scaling ve scale-to-zero özelliklerinin hedefi.

RDS’i Şu Durumlarda Seç:#

RDS, maliyet hassasiyeti olan projelere en iyi oturuyor: Aurora premium’unun haklı çıkmadığı, öngörülebilir düşük-orta seviye bir workload ve yüksek Aurora maliyetlerini tetiklemeyecek I/O pattern’leri. Daha geniş engine gereksinimlerini de kapsıyor: SQL Server, Oracle, MariaDB, Db2 ya da zaten Aurora-compatible olmayan bir engine’e bağımlı bir uygulama. Single-AZ development veya test environment’larında basit backup ve restore yeterli, advanced özelliklere gerek yok. Düşük I/O workload’lar (ayda 1 milyar request’in altında öngörülebilir pattern’ler) standart storage ve IOPS provisioning ile Aurora’nın I/O cost trap’ine düşmeden iyi çalışıyor.

Karar Çerçevesi#

Hızlı Referans:

• Turuncu (RDS): MySQL/PostgreSQL dışındaki engine’ler veya bütçe kısıtlı düşük I/O workload’ları için en iyisi
• Mavi (Aurora Standard): Çoğu production MySQL/PostgreSQL workload’unun düştüğü yer
• Mor (Aurora I/O-Optimized): I/O maliyetleri Aurora faturasının %25’ini aştığında

Maliyet Analizi ve I/O Tuzağı#

Aurora’nın pricing’i üç bileşenden oluşuyor: compute, storage ve I/O. I/O bileşeni genellikle ilk migration’larını yapan ekipleri şaşırtıyor.

Pricing Dağılımı#

Aurora Standard:

• Instance: Eşdeğer RDS instance type ile aynı fiyat
• Storage: $0.10/GB-ay (kullandığın kadar öde)
• I/O: Milyon request başına $0.20
• Backup’lar: İlk backup ücretsiz (cluster storage boyutu), ek backup $0.021/GB-ay

Aurora I/O-Optimized (2023’te tanıtıldı):

• Instance: Standard’dan %30 daha pahalı
• Storage: $0.225/GB-ay (Standard’ın 2.25 katı)
• I/O: $0 (dahil)
• Backup’lar: Standard ile aynı

I/O Tuzağı Nasıl Oluşuyor#

Birçok ekip Aurora maliyetini instance ve storage fiyatlarına bakarak tahmin ediyor, sonra I/O kalemi karşısında şaşırıyor. Bir production workload kolayca ayda 50-100 milyar I/O request üretebilir.

Örnek Hesaplama:

interface AuroraConfig {
  instanceType: string;
  storageGB: number;
  monthlyIORequests: number;
}

interface CostBreakdown {
  compute: number;
  storage: number;
  io: number;
  total: number;
}

function calculateAuroraCost(
  config: AuroraConfig,
  optimized: boolean = false
): CostBreakdown {
  // us-east-1 için örnek pricing
  const instancePricing: Record<string, number> = {
    'db.r6g.2xlarge': optimized ? 0.806 : 0.62, // saat başına
  };

  const storagePricing = optimized ? 0.225 : 0.10; // GB-ay başına
  const ioPricing = optimized ? 0 : 0.20; // milyon request başına

  const hoursPerMonth = 730;

  const computeCost = instancePricing[config.instanceType] * hoursPerMonth;
  const storageCost = config.storageGB * storagePricing;
  const ioCost = optimized ? 0 : (config.monthlyIORequests / 1_000_000) * ioPricing;

  return {
    compute: computeCost,
    storage: storageCost,
    io: ioCost,
    total: computeCost + storageCost + ioCost
  };
}

// Örnek: Yüksek I/O workload
const highIOWorkload: AuroraConfig = {
  instanceType: 'db.r6g.2xlarge',
  storageGB: 2000,
  monthlyIORequests: 50_000_000_000, // 50 milyar I/O request
};

const standardCost = calculateAuroraCost(highIOWorkload, false);
const optimizedCost = calculateAuroraCost(highIOWorkload, true);

console.log('Aurora Standard:', standardCost);
// { compute: 452.6, storage: 200, io: 10000, total: 10652.6 }

console.log('Aurora I/O-Optimized:', optimizedCost);
// { compute: 588.38, storage: 450, io: 0, total: 1038.38 }

// Temel kural: I/O total maliyetin %25'ini aştığında I/O-Optimized'a geç
const ioPercentage = (standardCost.io / standardCost.total) * 100;
console.log(`I/O toplam maliyetin %${ioPercentage.toFixed(1)}'i`);
// I/O toplam maliyetin %93.9'u - kesinlikle I/O-Optimized kullan!

Maliyet Optimizasyon Stratejileri#

1. İlk Günden I/O Metric’lerini İzle Migration’dan hemen sonra CloudWatch’ta VolumeReadIOPs ve VolumeWriteIOPs’u takip et. Bu metric’ler ölçülmüş tüketimi veriyor; maliyet modelindeki tahmini yerinden ediyorlar.

2. Buffer Cache’i Artır Daha fazla memory’ye sahip daha büyük instance’lar cache hit ratio’larını iyileştirerek I/O’yu azaltıyor. Bazen daha büyük bir instance için ödeme yapmak I/O maliyetlerinde tasarruf sağlıyor.

3. Query Optimizasyonu Daha iyi indexing, query optimization ve full table scan’lerden kaçınarak gereksiz I/O’yu azalt.

4. Stratejik Olarak I/O-Optimized’a Geç I/O maliyetleri toplam Aurora faturasının %25’ini aştığında, I/O-Optimized neredeyse her zaman daha ucuza mal oluyor. Spesifik öneriler için AWS Compute Optimizer kullan.

5. Değişken Workload’lar için Serverless v2 Development ve staging için 0 ACU minimum (Kasım 2024 özelliği) boştaki saatlerde compute ücretini sıfıra indiriyor. Storage ve backup faturalanmaya devam ediyor, Standard’da I/O da sayılıyor; yani boştaki maliyet sıfırlanmıyor, küçülüyor. Aşağıdaki örnek hesap yalnızca compute’u karşılaştırıyor ve eşdeğer bir provisioned instance’ın yaklaşık %77 altında kalıyor.

Aurora Serverless v2#

Aurora Serverless v2, geleneksel provisioned instance’ların scaling sınırlamalarını gerçek yüke dayalı otomatik kapasite ayarlamasıyla çözüyor.

Temel Özellikler (2024/2025 Güncellemeleri)#

• 256 ACU’ya Instant Scaling (Ekim 2024): Önceden 128 ACU ile sınırlıydı
• 0 ACU’ya Scale (Kasım 2024): Önceden minimum 0.5 ACU’ydu
• Fine-Grained Scaling: 0.5 ACU artışlarla ayarlama
• Full Feature Desteği: Global Database, Performance Insights ve tüm Aurora özellikleriyle çalışıyor

1 ACU = yaklaşık 2GB memory + orantılı CPU ve network bandwidth

Serverless v2 Konfigürasyonu#

import * as rds from 'aws-cdk-lib/aws-rds';
import * as ec2 from 'aws-cdk-lib/aws-ec2';

const serverlessCluster = new rds.DatabaseCluster(this, 'ServerlessCluster', {
  engine: rds.DatabaseClusterEngine.auroraPostgres({
    version: rds.AuroraPostgresEngineVersion.VER_16_1,
  }),
  vpc,
  writer: rds.ClusterInstance.serverlessV2('writer', {
    autoMinorVersionUpgrade: true,
  }),
  readers: [
    rds.ClusterInstance.serverlessV2('reader1', {
      scaleWithWriter: true, // Reader writer ile birlikte scale oluyor
    }),
  ],
  serverlessV2MinCapacity: 0, // Sıfıra scale (Kas 2024 özelliği)
  serverlessV2MaxCapacity: 256, // 256 ACU'ya kadar (Ekim 2024 özelliği)
});

// Not: 0 ACU minimum PostgreSQL 13.15+, 14.12+, 15.7+, 16.3+
// veya MySQL 3.08+ gerektiriyor

Serverless v2 Kullanım Senaryoları#

1. Değişken/Öngörülemeyen Workload’lar Flash sale’ler sırasında e-ticaret, mevsimsel uygulamalar veya pazarlama kampanyası traffic artışları.

2. Development ve Staging Environment’ları Kullanılmadığında sıfıra scale. Günde 8 saat, haftada 5 gün kullanılan bir development database’i compute maliyetinde yaklaşık %77 tasarruf sağlıyor.

3. Multi-Tenant SaaS Bağımsız scaling ile tenant başına database’ler. Her tenant’ın database’i kendi gerçek kullanımına göre scale oluyor.

4. Seyrek Batch Job’lar Günlük veya haftalık çalışan data processing. Çalışmalar arasında minimum’a scale.

Pricing Örneği#

// Serverless v2 pricing (us-east-1)
const acuPricePerHour = 0.12; // PostgreSQL

// Örnek: Dev environment
// Günde 8 saat, haftada 5 gün ortalama 2 ACU'da kullanılıyor
// Kullanılmadığında 0 ACU'ya scale oluyor

const monthlyHoursActive = 8 * 5 * 4.33; // ~ayda 173 saat
const avgACUs = 2;

const serverlessV2Cost = monthlyHoursActive * avgACUs * acuPricePerHour;
// = 173 * 2 * 0.12 = $41.52/ay

// Eşdeğer provisioned instance (db.r6g.large = 2 ACU eşdeğeri)
const provisionedCost = 730 * 0.246; // $179.58/ay

const savings = ((provisionedCost - serverlessV2Cost) / provisionedCost) * 100;
// = %76.9 tasarruf

RDS’den Aurora’ya Migration#

Migration Metodları#

1. Aurora Read Replica (Önerilen - Minimal Downtime)

Bu metod mevcut RDS instance’ından bir Aurora read replica oluşturuyor, sonra onu standalone cluster’a promote ediyor.

# Adım 1: RDS MySQL instance'ından Aurora Read Replica oluştur
aws rds create-db-instance-read-replica \
    --db-instance-identifier myapp-aurora-replica \
    --source-db-instance-identifier myapp-rds-mysql \
    --db-instance-class db.r6g.2xlarge \
    --engine aurora-mysql

# Adım 2: Replication lag'i izle
aws cloudwatch get-metric-statistics \
    --namespace AWS/RDS \
    --metric-name AuroraReplicaLag \
    --dimensions Name=DBInstanceIdentifier,Value=myapp-aurora-replica \
    --start-time 2025-11-29T00:00:00Z \
    --end-time 2025-11-29T01:00:00Z \
    --period 60 \
    --statistics Average

# Adım 3: Lag sıfıra yaklaştığında Aurora replica'yı promote et
aws rds promote-read-replica-db-cluster \
    --db-cluster-identifier myapp-aurora-cluster

Downtime: Promotion ve application cutover sırasında 15-30 dakika

2. Snapshot Migration

RDS snapshot’ını Aurora cluster olarak restore et. Büyük database’ler için daha hızlı ama cutover sırasında downtime gerektiriyor.

aws rds restore-db-cluster-from-snapshot \
    --db-cluster-identifier myapp-aurora \
    --snapshot-identifier myapp-rds-snapshot \
    --engine aurora-postgresql \
    --engine-version 16.1

Downtime: Snapshot restore’un tam süresi artı test süresi

3. AWS DMS (Database Migration Service)

En esnek ama en karmaşık. Cross-account, cross-VPC senaryolar veya encrypted/unencrypted database dönüşümleri için iyi.

4. pg_dump/mysqldump

Basit ama yavaş. Sadece 500GB altındaki database’ler için pratik.

Migration Öncesi Kontrol Listesi#

• Aurora’nın RDS engine versiyonunu desteklediğini doğrula
• CloudWatch metric’lerini kullanarak I/O maliyetlerini tahmin et
• Staging environment’ta uygulamayı Aurora ile test et
• Connection pooling stratejisini planla (RDS Proxy düşün)
• Rollback prosedürünü dokümante et
• RDS’de auto minor version upgrade’leri devre dışı bırak
• Migration’ı düşük traffic döneminde planla
• Yeni Aurora cluster için monitoring ve alerting hazırla

Multi-Region için Global Database#

Aurora Global Database, sub-second lag ile cross-region replication sağlayarak global read distribution ve hızlı disaster recovery’yi mümkün kılıyor.

Mimari#

• 1 Primary Region: Read ve write traffic kabul ediyor
• 10’a Kadar Secondary Region: Read-only (Mayıs 2025’te 5’ten artırıldı)
• Tipik Replication Lag: 1 saniyeden az
• Dedicated Infrastructure: Replication public internet kullanmıyor

Global Database Kurulumu#

import * as rds from 'aws-cdk-lib/aws-rds';
import * as ec2 from 'aws-cdk-lib/aws-ec2';

// Primary region (us-east-1)
const primaryCluster = new rds.DatabaseCluster(this, 'PrimaryCluster', {
  engine: rds.DatabaseClusterEngine.auroraPostgres({
    version: rds.AuroraPostgresEngineVersion.VER_16_1,
  }),
  vpc: primaryVpc,
  writer: rds.ClusterInstance.provisioned('writer', {
    instanceType: ec2.InstanceType.of(ec2.InstanceClass.R6G, ec2.InstanceSize.XLARGE2),
  }),
});

// Global database oluştur
const globalCluster = new rds.CfnGlobalCluster(this, 'GlobalCluster', {
  globalClusterIdentifier: 'myapp-global',
  sourceDbClusterIdentifier: primaryCluster.clusterArn,
  engine: 'aurora-postgresql',
  engineVersion: '16.1',
});

// Secondary region (eu-west-1) - ayrı stack'te deploy ediliyor
const secondaryCluster = new rds.DatabaseCluster(secondaryStack, 'SecondaryCluster', {
  engine: rds.DatabaseClusterEngine.auroraPostgres({
    version: rds.AuroraPostgresEngineVersion.VER_16_1,
  }),
  vpc: secondaryVpc,
  writer: rds.ClusterInstance.provisioned('writer', {
    instanceType: ec2.InstanceType.of(ec2.InstanceClass.R6G, ec2.InstanceSize.XLARGE2),
  }),
});

// Secondary'yi global database'e attach et
new rds.CfnDBCluster(secondaryStack, 'SecondaryAttach', {
  globalClusterIdentifier: 'myapp-global',
  dbClusterIdentifier: secondaryCluster.clusterIdentifier,
});

Failover Yetenekleri#

Planlı Switchover (Managed):

• Sıfır veri kaybı
• Cluster topology’sini koruyor
• Kullanım durumu: Regional rotation, compliance gereksinimleri

Plansız Failover:

• Secondary’yi yaklaşık 1 dakikada primary’ye promote ediyor
• Potansiyel veri kaybı failure anındaki replication lag’e bağlı
• RPO tipik olarak saniyeler, RTO yaklaşık 1 dakika

Maliyet Değerlendirmeleri#

Global Database birkaç alanda maliyet ekliyor ve sadece iş gereksinimleri gerçekten multi-region active-active read’ler veya sub-minute regional failover gerektirdiğinde uygulamaya değiyor:

• Cross-region data transfer charge’ları
• Tüm region’lara replicate edilen storage
• Her region’da instance maliyetleri
• Her region’da I/O charge’ları (Standard) veya artırılmış instance maliyetleri (I/O-Optimized)

RDS Proxy ile Connection Management#

Aurora’nın hızlı failover yetenekleri akıllı connection management ile birleştirildiğinde en iyi şekilde çalışıyor. RDS Proxy connection pooling sağlıyor ve failover’ı transparent şekilde handle ediyor.

import * as rds from 'aws-cdk-lib/aws-rds';
import * as ec2 from 'aws-cdk-lib/aws-ec2';
import * as cdk from 'aws-cdk-lib';

const proxy = new rds.DatabaseProxy(this, 'AuroraProxy', {
  proxyTarget: rds.ProxyTarget.fromCluster(auroraCluster),
  secrets: [auroraCluster.secret!],
  vpc,
  dbProxyName: 'myapp-aurora-proxy',
  // Connection pooling konfigürasyonu
  maxConnectionsPercent: 90,
  maxIdleConnectionsPercent: 50,
  connectionBorrowTimeout: cdk.Duration.seconds(120),
  // Session pinning filter'ları - gereksiz pinning'den kaçın
  sessionPinningFilters: [
    rds.SessionPinningFilter.EXCLUDE_VARIABLE_SETS,
  ],
  requireTLS: true,
});

// Uygulama cluster endpoint yerine proxy endpoint'e bağlanıyor
const proxyEndpoint = proxy.endpoint;

Faydaları:

• Lambda invocation’lar arasında connection pool’u koruyor
• Application-level retry logic olmadan failover’ı handle ediyor
• Serverless workload’lar için database connection’ları %90+ azaltıyor
• Ek güvenlik için IAM authentication zorunlu kılıyor

RDS Proxy’nin Gerekli Olduğu Durumlar:

• Serverless uygulamalar (Lambda function’lar)
• Connection storm’lu uygulamalar
• Birçok bağımsız service’li microservice’ler
• Tenant başına connection pattern’li multi-tenant uygulamalar

Aurora Deployment’ları Production’da Nerede Kırılıyor#

1. DNS Caching Sorunları#

Uygulama, database endpoint’inin DNS’ini çok uzun süre cache’lediğinde failover sonrası yeniden bağlanamıyor. 30 saniyenin altında bir resolver TTL’i, staging’de gerçek bir failover testiyle doğrulandığında, bunu production’a ulaşmadan yakalıyor.

// Node.js DNS cache konfigürasyonu
import dns from 'dns';
dns.setDefaultResultOrder('ipv4first');

// DNS TTL'ye saygı gösteren connection library kullan
import { Pool } from 'pg';
const pool = new Pool({
  host: process.env.DB_HOST,
  // Connection'ları süresiz cache'leme
  idleTimeoutMillis: 30000,
  connectionTimeoutMillis: 3000,
});

2. Yanlış Instance Class Seçimi#

40TB üzerindeki production workload’lar bazen t2/t3/t4g burstable instance’larda kalıyor; bunlar development’ta sorun çıkarmaz ama production’ın ihtiyaç duyduğu tutarlı performansı sürdüremez, bu yüzden r6g veya r6i instance family’leri burada daha güvenli seçim.

3. CPU Credit Tükenmesinden Replica Lag#

T-instance read replica’ları CPU credit’lerini tükettiğinde replication lag dramatik artıyor ve instance’lar sonunda restart oluyor. CPUCreditBalance metric’i tükenmeyi erken yakalıyor; non-burstable instance type’ları ise production read replica’larında bu sorunu baştan önlüyor.

4. Connection Tükenmesi#

Serverless uygulamalar binlerce kısa ömürlü connection oluşturarak database’in connection limitini tüketebiliyor, Lambda için ise çözüm neredeyse zorunlu hale geliyor: RDS Proxy ya da application-side connection pooling.

5. Parallel Query Cost Artışı#

Parallel query’yi etkinleştirmek buffer cache’i bypass ettiği için beklenmedik şekilde I/O maliyetlerini artırıyor; etkinleştirdikten hemen sonra VolumeReadIOPs’a bakmak bunu yakalıyor. Parallel query workload için kritikse I/O-Optimized bu artışı karşılıyor.

6. CloudFormation Veri Kaybı Riski#

CloudFormation stack güncellemeleri instance’ları yeniden oluşturabilir ve bu sırada veri kaybedebilir; bu yüzden database resource’larında DeletionPolicy: Retain ayarlamak ve change set’leri uygulamadan önce dikkatlice incelemek gerekiyor.

7. Binary Logging Performansı#

Büyük transaction’lar (1M+ insert) binary logging etkinken çok yavaş oluyor. Daha küçük transaction’lara böl (10K-50K insert) ya da point-in-time recovery gerekli değilse binary logging’i devre dışı bırak.

Monitoring ve Operasyonlar#

İzlenecek Temel Metric’ler#

Performans Metric’leri:

• CPUUtilization: Ortalama %80’den az hedefle
• DatabaseConnections: max_connections ayarına göre izle
• BufferCacheHitRatio: %95’ten büyük hedefle
• AuroraReplicaLag: 100ms’den az hedefle

I/O ve Storage Metric’leri:

• VolumeReadIOPs, VolumeWriteIOPs: Maliyet artışlarını izle
• VolumeBytesUsed: Otomatik storage büyümesini takip et
• DiskQueueDepth: I/O darboğazlarını gösterir

Availability Metric’leri:

• FailoverLatency: Gerçek failover süresini ölç
• DeadlockCount: Uygulama tasarım sorunları
• CommitLatency: Write performansı

Operasyonel Best Practice’ler#

1. Enhanced Monitoring’i Etkinleştir 1 saniyelik granülaritede OS-level metric’ler (memory, CPU, disk I/O) sağlıyor. Production troubleshooting için kritik.

2. Performance Insights Kullan Query-level analiz hangi query’lerin resource tükettiğini gösteriyor. Free tier 7 günlük retention içeriyor.

3. CloudWatch Alarm’ları Ayarla Sorun olmadan önce temel metric’lerde alarm ver:

• 5 dakika boyunca CPU > %80
• Replica lag > 1 saniye
• Connection’lar max_connections’ın %80’ini aşıyor
• BufferCacheHitRatio < %90

4. Çeyrek Yılda Failover Test Et Düzenli failover testleri gerçek RTO’yu doğruluyor. Birçok ekip DNS caching veya connection pool sorunlarını ancak production incident’ları sırasında keşfediyor.

5. AWS Compute Optimizer Kullan Gerçek kullanım pattern’lerine dayalı rightsizing önerileri sağlıyor. I/O-Optimized’a geçme veya instance downsize fırsatlarını belirleyebiliyor.

Aurora Ne Zaman Karşılığını Veriyor#

Sınır; engine desteği, workload büyüklüğü ve I/O payı boyunca çiziliyor. Sub-minute failover, beşten fazla read replica veya bakım penceresi olmadan büyüyen storage gerektiren production MySQL ve PostgreSQL cluster’ları Aurora Standard’a ait; VolumeReadIOPs ve VolumeWriteIOPs I/O’yu faturanın dörtte birinin üzerine taşıdığında I/O-Optimized’a geç, haftanın çoğunu boş geçiren environment’lar için de Serverless v2 daha iyi oturuyor.

Bu sınırı ters yönde geç: engine’in Oracle, SQL Server, MariaDB veya Db2 olması gerektiğinde, workload provisioned RDS storage ve IOPS’a rahatça sığacak kadar küçük ve öngörülebilir olduğunda ya da DynamoDB, Redshift, Neptune gibi amaca yönelik bir servis erişim pattern’ine daha iyi oturduğunda. 5x MySQL ve 3x PostgreSQL rakamları AWS’nin kendi benchmark’ları.

En ucuz ilk adım, mevcut RDS instance’ından bir haftalık CloudWatch I/O verisi toplamak. O sayı hem pricing modunu hem de migration’ın gerçekten gerekli olup olmadığını belirliyor.

Kaynaklar#

• Amazon Aurora Nedir? (yeni sekmede açılır) - Aurora’nın mimarisi, cluster modeli ve MySQL ile PostgreSQL uyumluluğunun resmi genel bakışı
• Amazon Aurora Depolama ve Güvenilirlik (yeni sekmede açılır) - Aurora’nın dağıtık depolama katmanı ve Kullanılabilirlik Bölgeleri genelinde altı yönlü replikasyonun ayrıntılı açıklaması
• Amazon Aurora için Yüksek Erişilebilirlik (yeni sekmede açılır) - Aurora failover mekanizmaları, okuma replikası promosyonu ve multi-AZ cluster davranışı
• Amazon Aurora Ürün Sayfası (yeni sekmede açılır) - Özellik genel bakışı, fiyatlandırma modeli seçenekleri ve standart RDS ile karşılaştırma
• Amazon Aurora DB Cluster’ları (yeni sekmede açılır) - Birincil ve okuyucu instance rolleri, endpoint türleri ve cluster volume yönetimi
• Amazon RDS Proxy Dokümantasyonu (yeni sekmede açılır) - Aurora için bağlantı havuzu proxy’si; sunucusuz ve Lambda tabanlı iş yükleri için önemli