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)

AWS Veritabanı Ekosistemi: Aurora Nerede Konumlanıyor

Aurora, her biri belirli bir erişim pattern’i için tasarlanmış birçok AWS database servisinden biri. Aurora’yı bu haritada doğru yere oturtmak, Aurora-RDS sorusuna gelmeden önce karşılaştırmayı daraltıyor.

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

Alternatifleri anlamak, Aurora’nın doğru seçim olduğu durumları netleştiriyor:

• 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 özellikle high availability, read scalability ve cloud-native özellikler gerektiren MySQL ve PostgreSQL workload’larında öne çıkıyor. Diğer kullanım senaryoları için AWS amaca yönelik alternatifler sunuyor.

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ç:

1. High Availability Kritik

• Multi-AZ RDS’in %99.95’i yerine %99.99 uptime SLA gerekiyor
• Sub-minute failover gereksinimleri
• İş 1-2 dakikalık database kesintilerini tolere edemiyor

2. Read-Heavy Workload’lar

• 5’ten fazla read replica gerekiyor
• Millisaniye replication lag gerekiyor
• Read traffic write’lardan önemli ölçüde fazla

3. Öngörülemeyen Storage Büyümesi

• Storage provisioning yönetmek istemiyorsun
• Storage ihtiyaçları beklenmedik şekilde artabilir
• Over-provisioning storage maliyetlerinden kaçınmak istiyorsun

4. Multi-Region Gereksinimleri

• Sub-second lag ile cross-region replication gerekiyor
• Hızlı failover ile disaster recovery
• Global read distribution

5. Değişken Workload’lar

• Traffic pattern’leri önemli ölçüde değişiyor (günlük 10x dalgalanmalar)
• Serverless v2 auto-scaling’den faydalanabilirsin
• Non-production environment’lar için sıfıra scale etmek istiyorsun

RDS’i Şu Durumlarda Seç:

1. Maliyet Hassasiyeti Olan Projeler

• Öngörülebilir, düşük-orta seviye workload
• Aurora premium’unun haklı çıkmadığı bütçe kısıtlamaları
• I/O pattern’leri yüksek Aurora maliyetlerini tetiklemeyecek

2. Daha Geniş Engine Desteği Gerekiyor

• SQL Server, Oracle, MariaDB veya Db2 gerekiyor
• Aurora’da bulunmayan spesifik engine özellikleri
• Aurora-compatible olmayan engine’lere mevcut uygulama bağımlılıkları

3. Basit Gereksinimler

• Single-AZ development veya test environment’ları
• Basit backup ve restore yeterli
• Advanced özelliklere ihtiyaç yok

4. Düşük I/O Workload

• Ayda 1 milyar request’in altında öngörülebilir I/O pattern’leri
• Aurora’nın I/O cost trap’ine düşmeyecek
• Standart storage ve IOPS provisioning 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’u için varsayılan seçim
• 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. Önlenen her I/O operation milyon başına $0.20 tasarruf sağlıyor.

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:

• 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)

Bu pahalı olabilir. Global Database’i sadece iş gereksinimleri gerçekten multi-region active-active read’ler veya sub-minute regional failover gerektirdiğinde implement et.

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

Yaygın Tuzaklar ve Çözümleri

1. DNS Caching Sorunları

Sorun: Uygulama database endpoint DNS’ini çok uzun süre cache’liyor, failover sonrası yeniden bağlanmada başarısız oluyor.

Çözüm: Uygulama DNS resolver’ını 30 saniyeden az TTL ile konfigüre et. Gerçek recovery süresini ölçmek için staging’de failover senaryolarını test et.

// 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

Sorun: 40TB üzerindeki production workload’lar için t2/t3/t4g burstable instance’lar kullanılması.

Çözüm: Production için r6g veya r6i instance family’leri kullan. Burstable instance’lar development için çalışıyor, ama production database’leri tutarlı performansa ihtiyaç duyuyor.

3. CPU Credit Tükenmesinden Replica Lag

Sorun: T-instance read replica’ları CPU credit’lerini tüketiyor, replication lag dramatik artıyor, instance’lar restart oluyor.

Çözüm: CPUCreditBalance metric’ini izle. Production read replica’ları için non-burstable instance type’ları kullan.

4. Connection Tükenmesi

Sorun: Serverless uygulamalar binlerce kısa ömürlü connection oluşturuyor, database connection’larını tüketiyor.

Çözüm: RDS Proxy veya application-side connection pooling implement et. Lambda için bu neredeyse zorunlu.

5. Parallel Query Cost Artışı

Sorun: Parallel query’yi etkinleştirmek buffer cache’i bypass ettiği için beklenmedik şekilde I/O maliyetlerini artırıyor.

Çözüm: Parallel query’yi etkinleştirdikten sonra VolumeReadIOPs’u izle. Parallel query workload’ın için kritikse I/O-Optimized’ı değerlendir.

6. CloudFormation Veri Kaybı Riski

Sorun: CloudFormation stack güncellemeleri instance’ları yeniden oluşturabilir, potansiyel olarak veri kaybedebilir.

Çözüm: Database resource’larında her zaman DeletionPolicy: Retain kullan. Uygulamadan önce CloudFormation change set’leri dikkatlice incele.

7. Binary Logging Performansı

Sorun: Büyük transaction’lar (1M+ insert) binary logging etkinken çok yavaş oluyor.

Çözüm: Daha küçük transaction’lara böl (10K-50K insert) veya 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

Sub-minute failover, beşten fazla read replica veya bakım penceresi olmadan büyüyen storage gerektiren production MySQL ve PostgreSQL cluster’ları için varsayılan Aurora Standard olarak kalıyor. 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 Serverless v2’ye bak.

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 bu varsayılanı bırak. 5x MySQL ve 3x PostgreSQL rakamları AWS’nin kendi benchmark’ları; bağlanmadan önce kendi query’lerinle ölç.

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? - Aurora’nın mimarisi, cluster modeli ve MySQL ile PostgreSQL uyumluluğunun resmi genel bakışı
• Amazon Aurora Depolama ve Güvenilirlik - 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 - Aurora failover mekanizmaları, okuma replikası promosyonu ve multi-AZ cluster davranışı
• Amazon Aurora Ürün Sayfası - Özellik genel bakışı, fiyatlandırma modeli seçenekleri ve standart RDS ile karşılaştırma
• Amazon Aurora DB Cluster’ları - Birincil ve okuyucu instance rolleri, endpoint türleri ve cluster volume yönetimi
• Amazon RDS Proxy Dokümantasyonu - Aurora için bağlantı havuzu proxy’si; sunucusuz ve Lambda tabanlı iş yükleri için önemli