Amazon RDS for SQL Server mı, EC2 Üzerinde SQL Server mı? Nasıl Seçilir?

İş yükünüz RDS’in belgelenmiş limitlerine sığıyorsa ve yedekleme, yama ve failover işlerini AWS’nin üstlenmesini istiyorsanız Amazon RDS for SQL Server’ı seçin. İşletim sistemi erişimine, RDS’in desteklemediği bir SQL Server özelliğine veya RDS’in bilerek vermediği bir instance kontrolüne ihtiyacınız varsa Amazon EC2 üzerinde SQL Server kullanın.

Bu iki cevap vakaların çoğunu kapsar, ancak taşımanın bir hafta sonu restore işi mi yoksa yeniden tasarım mı olacağını ayrıntılar belirler. Bu rehber iki seçeneği özellikler, yüksek erişilebilirlik, yedekleme, lisanslama ve geçiş yolları açısından karşılaştırır, taşımadan önce kontrol etmeniz gereken RDS kısıtlarını listeler ve bir karar ağacıyla biter. Teknik ifadelerin tamamı AWS dokümantasyonuna dayanır.

İki Seçenek Bir Dakikada

Amazon RDS for SQL Server yönetilen bir hizmettir. AWS size DB instance’ları, snapshot’lar, point-in-time restore ve otomatik yedekleme sunar; ancak shell erişimi vermez ve gelişmiş yetki gerektiren bazı sistem prosedürlerine ve tablolarına erişimi kısıtlar. SQL Server Management Studio gibi standart SQL istemcileriyle bağlanırsınız; Telnet, SSH veya Uzak Masaüstü ile doğrudan host erişimine izin verilmez.

Amazon EC2 üzerinde SQL Server, bir sanal makineye kendiniz kurup işlettiğiniz veya SQL Server içeren, AWS tarafından hazırlanmış bir Windows Server AMI’sinden başlattığınız SQL Server’dır. Instance sizin olduğu için kurulumu değiştirebilir, özellik ekleyebilir, yerinde (in-place) yükseltme yapabilir veya named instance ekleyebilirsiniz. AWS, lisans dahil AMI’lerin tam bu işler için C:\SQLServerSetup klasöründe kurulum medyası içerdiğini belgeler. Karşılığında yedekleme, yama stratejisi ve yüksek erişilebilirlik tasarımı sizin sorumluluğunuzdadır.

Karşılaştırma Tablosu

Tablo, kararı en sık değiştiren farkları özetler. Limitler SQL Server sürümüne, instance sınıfına ve AWS Bölgesine göre değişebilir; tasarımı kesinleştirmeden önce bağlantılı AWS sayfalarından doğrulayın.

Taşımadan Önce Kontrol Edilecek RDS for SQL Server Kısıtları

Projeleri kurtaran bölüm budur. Yönetilen hizmet bir takastır: AWS operasyonu üstlenir, karşılığında bazı yetenekleri kaldırır. RDS’e karar vermeden önce instance’ınızı aşağıdaki listeyle karşılaştırın.

RDS’in desteklemediği özellikler

AWS, şu SQL Server özelliklerini RDS’te desteklenmeyenler arasında sayar: Azure Arc özellikleri, Azure Blob Storage’a yedekleme, buffer pool extension, change event streaming, özel parola politikaları, Data Quality Services, database log shipping, database snapshot’lar (RDS yalnızca DB instance snapshot’larını destekler), xp_cmdshell dahil extended stored procedure’ler, FILESTREAM, file table’lar, Machine Learning ve R Services, maintenance plan’lar, Performance Data Collector, Policy-Based Management, PolyBase, replication, server seviyesi trigger’lar, Service Broker endpoint’leri, Stretch Database, TRUSTWORTHY veritabanı özelliği, T-SQL endpoint’leri ve WCF Data Services.

Bazıları hiç desteklenmemek yerine sınırlı desteklenir. Linked server’lar ve distributed query’ler kısıtlarla desteklenir; CLR, RDS for SQL Server 2016 ve öncesinde yalnızca SAFE modunda desteklenir, 2017 ve sonrasında desteklenmez. Bazı kısıtlar sürüme bağlıdır: SQL Server 2022 ve sonrasında SQL Server Analysis Services (SSAS) desteklenmez; SQL Server 2025’te ise SQL Server Integration Services (SSIS) ve ZSTD yedek sıkıştırma da desteklenmez.

Operasyonel limitler

• Host erişimi yok. DB instance üzerinde SSH veya Uzak Masaüstü kullanamazsınız; bazı sistem prosedürleri ve tablolar kısıtlıdır.
• Veritabanı sayısı. Desteklenen azami veritabanı sayısı instance sınıfına ve erişilebilirlik moduna bağlıdır: örneğin xlarge ile 16xlarge sınıflarında Single-AZ’de 100, database mirroring’li Multi-AZ’de 50, Always On availability group’lu Multi-AZ’de 75. Daha küçük sınıflar 30 destekler.
• Depolama. Azami boyut General Purpose SSD’de 16 TiB, Provisioned IOPS’ta 64 TiB’dır. Daha fazlası için AWS, instance’lar arasında sharding önerir; bu, uygulamada veriye bağlı yönlendirme mantığı gerektirir.
• Rezerve portlar. 1234, 1434, 3260, 3343, 3389, 47001 ve 49152-49156 portları DB instance için kullanılamaz.
• Standard Edition işlemci limitleri. Çok büyük instance sınıflarında Standard Edition, AWS’nin listelediği yazılım limitleri nedeniyle işlemcilerin yalnızca bir alt kümesini kullanır.
• Recovery model. Amazon RDS, point-in-time recovery için kullanılan log zincirini bozabileceği için SQL Server veritabanlarının recovery model’ini değiştirmeyi desteklemez.
• Yedekleme sırasında I/O. SQL Server’da otomatik yedekleme primary üzerinden alındığı için depolama I/O’su hem Single-AZ hem Multi-AZ’de kısa süreliğine askıya alınır.
• Restore sonrası veritabanları arası tutarlılık. Point-in-time restore sonrasında her veritabanı diğerlerinin 1 saniye içinde bir noktaya döner; birden fazla veritabanına yayılan işlemler tutarsız geri yüklenebilir.
• Master Data Services. RDS, Data Quality Services veya Master Data Services’in aynı sunucuda çalışmasını desteklemez; AWS bunlar için EC2’yi veya on-premises SQL Server’ı önerir.

Multi-AZ uyarıları

• Bölgeler arası (cross-Region) Multi-AZ desteklenmez, Multi-AZ SQL Server instance’ı durduramazsınız ve standby okuma işlemi kabul etmez.
• Önce Multi-AZ’yi kapatmadan Multi-AZ instance’ta veritabanı adını değiştiremezsiniz ve Multi-AZ dağıtımında offline veritabanı bulunamaz.
• Her şey standby’a kopyalanmaz. Database mirroring veya Always On availability group ile linked server’lar kopyalanmaz, Server Audit’ler kısmen kopyalanır ve msdb izinleri kopyalanmaz. SQL Server Agent job’ları yalnızca job replication’ı açarsanız ve yalnızca T-SQL adımları için kopyalanır.
• Senkron replikasyon nedeniyle Single-AZ’ye göre daha yüksek gecikme görebilirsiniz ve büyük işlemler failover süresini uzatır.
• Standby’ın Availability Zone’unu seçemezsiniz; bu nedenle uygulama sunucularını zonlara dengeli dağıtmanız gerekir.

Yüksek Erişilebilirlik ve Felaket Kurtarma

RDS’te yüksek erişilebilirlik, Multi-AZ dağıtımı demektir. RDS dağıtımı izler, sağlıksız instance’ları onarır, senkronizasyonu yeniden kurar ve failover başlatır; failover yalnızca standby ile primary tam senkronken gerçekleşir. Primary ve standby tek bir endpoint’i paylaşır, bu yüzden uygulamayı yeniden yapılandırmanız gerekmez. Yine de uygulamalar bağlantı hatalarında yeniden denemelidir.

Bölgeler arası felaket kurtarma için AWS’nin belgelediği seçenekler farklı araçlardır. Yalnızca Enterprise Edition’da bulunan read replica’lar bölgeler arası oluşturulabilir. Veritabanı snapshot’ları için AWS, bölgeler arası DR’de native yedekler yerine snapshot’ı başka bir Bölgeye kopyalamayı önerir. Read replica’dan point-in-time recovery desteklenmez.

EC2’de HA tasarımını siz seçer ve kurarsınız; neyin mümkün olduğunu SQL Server edition’ınız belirler. Lisanslama burada da önemlidir: lisans dahil instance’lar kullanırsanız pasif failover instance’larını lisanslamanız gerekir; Software Assurance’lı lisansları default-tenancy EC2’ye getirirseniz, SQL Server lisansı gerekmeyen, eşit veya daha küçük boyutta bir pasif instance’a izin verilir. Motor seviyesindeki seçenekler şirket içindekiyle aynıdır: edition’ınızın sınırları içinde Always On availability group ve failover cluster instance gibi. Karşılaştırması için SQL Server High Availability rehberimize bakın.

Yedekleme ve Restore

RDS’te otomatik yedekler, tek tek veritabanlarının değil bütün DB instance’ın depolama hacmi snapshot’ını alır ve belirlediğiniz saklama süresince tutar. Bu süre içindeki herhangi bir ana geri dönebilirsiniz. RDS, transaction log’ları her beş dakikada bir Amazon S3’e yükler ve point-in-time restore kaynağın üzerine yazmak yerine yeni bir DB instance oluşturur. Manuel snapshot’lar otomatik yedeklerden bağımsızdır, instance silindiğinde silinmez ve Bölge başına 100 manuel snapshot ile sınırlıdır.

Native backup ve restore, veritabanlarını içeri ve dışarı taşımanın yoludur. RDS, Amazon S3’te saklanan full ve differential .bak dosyalarını destekler. On-premises bir veritabanını S3’e yedekleyip RDS’e restore edebilir veya bir RDS veritabanını yedekleyip başka yerde, on-premises dahil, restore edebilirsiniz. SQLSERVER_BACKUP_RESTORE seçeneğini içeren bir option group ve S3 bucket’ına erişimi olan bir IAM rolü gerekir; yeniden başlatma gerektirmez. Planlamanız gereken limitler:

• S3 bucket’ı DB instance ile aynı Bölgede olmalıdır.
• RDS for SQL Server’dan native log yedeği alamazsınız.
• FILESTREAM file group’u içeren bir veritabanı restore edilemez.
• Yedekleme ve restore dosya başına 5 TB ile (daha büyük veritabanları için multifile yedek kullanın), aynı anda 10 dosya ve iki eşzamanlı görevle sınırlıdır.
• Native yedek, günlük RDS yedekleme penceresiyle çakışırsa iptal edilir; bakım penceresinde veya snapshot alınırken native yedek çalıştıramazsınız.
• Multi-AZ instance’larda yalnızca full recovery model’de yedeklenmiş veritabanlarını native olarak restore edebilirsiniz.

EC2’de yedekler, sizin zamanladığınız, sakladığınız ve test ettiğiniz standart SQL Server yedekleridir. Sizin yerinize hiçbir şey alınmaz.

Lisanslama: Lisans Dahil mi, Kendi Lisansınız mı?

Fiyatlar Bölgeye, edition’a ve sözleşmeye göre değiştiği için burada fiyat vermiyoruz; rakamlar için AWS fiyatlandırma sayfalarını ve hesaplayıcısını kullanın. Karar için önemli olan, her seçeneğin hangi lisans modellerini desteklediğidir.

• RDS, Lisans Dahil (License Included): ayrıca SQL Server lisansı satın almazsınız; RDS fiyatı lisansı, donanımı ve yönetimi içerir. Enterprise, Standard, Web ve Express için sunulur.
• RDS, Bring Your Own Media (BYOM): RDS SQL Server lisans ücreti almaz; mevcut lisanslarınızı Software Assurance üzerinden License Mobility ile kullanırsınız. Aktif Software Assurance ve License Mobility haklarına sahip geçerli bir lisans gerekir, Enterprise, Standard ve Developer’ı kapsar; altyapı ve Windows işletim sistemi lisans ücretlerini yine ödersiniz. Developer Edition yalnızca üretim dışı kullanım içindir.
• EC2, lisans dahil AMI’ler: AWS Web, Standard ve Enterprise edition’larını, ayrıca lisans ücreti olmayan Express’i sunar. Lisans dahil instance’lar CAL gerektirmez.
• EC2, BYOL: aktif Software Assurance’lı lisanslar License Mobility ile default (paylaşımlı) tenancy’ye getirilebilir; bunun için Microsoft doğrulama formu gerekir. Software Assurance’sız lisanslar EC2 Dedicated Host’larda yalnızca dar bir durumda çalıştırılabilir: 1 Ekim 2019’dan önce satın alınmış veya bu tarihten önce yürürlüğe girmiş bir Enterprise Enrollment kapsamında true-up olarak eklenmiş olmalı ve yalnızca o tarihten önce çıkmış sürümlere yükseltilebilir. Server/CAL modelinde satın aldıysanız CAL’lar on-premises’ta kalır.

RDS’te Multi-AZ için ek lisans gerekmez. Core ve CAL lisanslarının Software Assurance ile ilişkisi için SQL Server lisanslama rehberimize bakın.

Geçiş Yolları

Yolu bildiğiniz araca göre değil, kabul edebileceğiniz kesinti süresine göre seçin.

• RDS’e native backup ve restore. AWS, yedek dosyası oluşturulup kopyalanırken ve restore edilirken veritabanı offline olabiliyorsa bunu önerir. Native yedek; veriyi, şemaları, stored procedure’leri, trigger’ları ve diğer veritabanı kodunu taşır. Dokümantasyon ayrıca log yedeklerinin restore edilmesini ve restore’un tamamlanmasını da kapsar; cutover öncesinde sonraki değişiklikleri bu şekilde uygularsınız.
• AWS Database Migration Service (AWS DMS). AWS, on-premises veritabanı offline olamıyorsa bunu önerir. DMS tek seferlik geçiş yapabilir veya devam eden değişiklikleri replike edebilir. Ön koşulları kontrol edin: SQL Server tam yedekler için yapılandırılmış olmalı ve replikasyon başlamadan önce bir yedek alınmalıdır; devam eden replikasyon için recovery model bulk-logged veya full olmalıdır. Belgelenmiş limitler arasında kaynakta columnstore index’lerin, memory-optimized tabloların ve accelerated database recovery açık veritabanlarının desteklenmemesi yer alır; truncate komutları yakalanmaz. RDS SQL Server hedefinde DMS hesabının en az db_owner rolüne ihtiyacı vardır ve Windows kimlik doğrulaması desteklenmez. DMS varsayılan olarak hedefte tabloları ve primary key’leri yoksa oluşturur; bu yüzden diğer nesnelerin hedefe nasıl ulaşacağını planlayın.
• RDS’ten geri çıkış. S3’e alınan native yedekler on-premises’ta veya başka bir SQL Server instance’ında restore edilebilir; RDS uymamaya başlarsa çıkış yolunuz budur.

EC2’ye geçişte, iki sunucu arasında olduğu gibi standart SQL Server araçları geçerlidir. Microsoft’un bulutunu da değerlendiriyorsanız, Azure SQL karar rehberimiz aynı soruları Azure SQL Database, Managed Instance ve Azure VM için ele alıyor. Bu geçişleri nasıl yürüttüğümüz için veritabanı migrasyon hizmeti sayfamıza bakın.

RDS’in “yedek” dediği iki özelliği karıştırmayın. Otomatik yedekler ve snapshot’lar bütün instance’ın depolama yedekleridir ve yeni bir instance’a geri yüklenir. Native yedekler S3’teki veritabanı bazlı .bak dosyalarıdır. Geçişiniz ve kurtarma planınız büyük olasılıkla ikisini de kullanacaktır; her runbook adımının hangisine dayandığını yazın.

Karar Ağacı

Soruları sırayla izleyin ve ilk uyan yanıtta durun.

1. İşletim sistemi erişimine, SQL Server’ın yanında kurulu yazılıma veya desteklenmeyen özellikler listesindeki bir özelliğe (xp_cmdshell, FILESTREAM, replication, log shipping, maintenance plan, PolyBase, SQL Server 2017 veya sonrasında CLR) ihtiyacınız var mı? EC2 üzerinde SQL Server seçin.
2. Tek bir instance, RDS’in desteklediğinden daha fazla depolama veya veritabanı mı gerektiriyor? Limitlere bakın (16 TiB veya 64 TiB; 30 ile 100 veritabanı). Shard veya konsolide edemiyorsanız EC2 seçin.
3. Lisans durumunuz bir engel mi? RDS BYOM, License Mobility’li Software Assurance gerektirir. Software Assurance’sız lisansların EC2’de dar bir Dedicated Host yolu vardır. Karar vermeden önce bunu Microsoft lisanslama danışmanınızla netleştirin.
4. Okunabilir bir secondary’ye ihtiyacınız var mı? Multi-AZ standby okunamaz. RDS read replica’ları Enterprise Edition gerektirir; aksi halde okuma ölçeklemeyi EC2 üzerinde kendiniz tasarlayın.
5. Yedekleme, yama ve failover’ı AWS’nin yürütmesini istiyor ve iş yükünüz yukarıdaki limitlere sığıyor mu? Üretim için Multi-AZ ile Amazon RDS for SQL Server seçin.
6. Hâlâ emin değil misiniz? Instance’ın değerlendirmesini yapın. 1. sorunun cevabı çoğunlukla en geç keşfedilendir.

Sık Yapılan Hatalar

• Değerlendirme yerine özellik listesine bakarak karar vermek. Dokümantasyon neyin desteklenmediğini söyler; hangisini kullandığınızı yalnızca kendi instance’ınızın taraması gösterir.
• Multi-AZ’yi yedek sanmak. Host ve zon arızasına karşı korur, silinmiş bir tabloya karşı korumaz. Test edilmiş yedekleri ve point-in-time restore’u koruyun.
• Sunucu seviyesi nesnelerin kendiliğinden taşınacağını varsaymak. Linked server’lar, server audit’ler, msdb izinleri ve Agent job’ları Multi-AZ’de ayrıca ilgi ister.
• Yalnızca instance fiyatına bakmak. Yedek depolamayı, standby kapasitesini, lisanslamayı ve her modelin kaldırdığı ya da eklediği operasyon süresini karşılaştırın.
• Bakım penceresini unutmak. Native yedekler, Agent job’ları ve otomatik yedekler bakım ve yedekleme pencereleriyle çakışabilir.

Uygulamada kararı sunucu bazında değil veritabanı bazında verin. Instance seviyesi bağımlılıkları genellikle birkaç veritabanı taşır; RDS ile EC2 arasındaki kararı onlar belirler, geri kalanlar daha basit seçeneğe taşınabilir.

SSS

Aryasoft RDS mi EC2 mi Kararında Nasıl Yardımcı Olur?

Aryasoft’un AWS veritabanı değerlendirmesi, SQL Server instance’larınızın ve her veritabanının kullandığı instance seviyesi özelliklerin envanteriyle başlar. Bu envanteri yukarıdaki RDS kısıtlarıyla karşılaştırır, lisans durumunuzu kontrol eder ve her iş yükü için bir geçiş yolu ile geri dönüş noktası belirleriz. Çıktı, bütçe sahibinize götürebileceğiniz yazılı bir hedef mimaridir. Daha geniş kapsam için AWS hizmet sayfamıza bakın.

Kaynaklar

Bu rehberdeki teknik ifadeler, aşağıdaki AWS dokümantasyonuna karşı 19 Ekim 2026 tarihinde kontrol edildi. AWS dokümantasyon sayfaları son güncelleme tarihi göstermez; verilen tarih sayfaları okuduğumuz tarihtir. Limitler, sürümler ve özellikler değişir; tasarımı kesinleştirmeden önce bağlantılı sayfadan doğrulayın.

1. Amazon RDS for Microsoft SQL Server (genel bakış ve kısıtlar)
2. Features not supported and features with limited support
3. Multi-AZ deployments for Amazon RDS for Microsoft SQL Server
4. Microsoft SQL Server Multi-AZ deployment limitations, notes, and recommendations
5. Licensing Microsoft SQL Server on Amazon RDS
6. Understand licensing options and considerations for Microsoft SQL Server on Amazon EC2
7. Importing and exporting SQL Server databases using native backup and restore
8. Support for native backup and restore in SQL Server
9. Introduction to backups (Amazon RDS)
10. Managing automated backups (Amazon RDS)
11. Restoring a DB instance to a specified time for Amazon RDS
12. Working with read replicas for Microsoft SQL Server in Amazon RDS
13. Using SQL Server Agent for Amazon RDS
14. Using a Microsoft SQL Server database as a source for AWS DMS
15. Using a Microsoft SQL Server database as a target for AWS DMS
16. What is AWS Database Migration Service?
17. Upgrades of the Microsoft SQL Server DB engine