ASP.NET Core için Windows IIS Sunucu Kiralama Rehberi

ASP.NET Core sunucu kiralama, kurumsal web portallarını, API servislerini, B2B uygulamalarını ve SQL Server ile çalışan .NET projelerini kendi yönetiminde barındırmak isteyen şirketler için bir altyapı seçeneğidir. Ancak teklif alırken yalnız “Windows Server, 8 vCPU, 32 GB RAM” yazmak yeterli değildir. Kullanılan .NET sürümü, IIS ve ASP.NET Core Hosting Bundle, uygulama havuzu ayarları, SQL erişimi, TLS, yedekleme ve teknik destek kapsamı birlikte değerlendirilmelidir.

Kısa cevap: Önce mevcut uygulamanın ASP.NET Core mu yoksa eski ASP.NET/.NET Framework mü olduğunu ve hedef .NET sürümünü belirleyin. Uygulama, IIS ve veritabanı bağımlılıklarını listeleyin. Sunucuyu kullanıcı sayısına göre değil, gerçek istek yoğunluğu, işlemci/bellek tüketimi, SQL gecikmesi ve kurtarma hedefleriyle seçin. Aynı teknik şartnameyi kullanarak VPS ve bulut sunucu ile diğer seçenekleri karşılaştırın; sonra ASP.NET Core sunucu kiralama teklifi alın.

Bu rehber; .NET yazılım şirketleri, iç uygulama geliştiren BT ekipleri ve ASP.NET tabanlı kurumsal portallarını veri merkezine taşımak isteyen karar vericiler içindir. Amaç tek bir paket satmak değil, çalışır, güvenli ve desteklenebilir bir yayın altyapısının hangi kalemlerden oluştuğunu açıklamaktır.

1. Windows IIS sunucu kiralama kimler için uygun?

Windows Server ve Internet Information Services (IIS), Windows Authentication veya belirli Windows bileşenlerini kullanması gereken ASP.NET Core uygulamalarında değerlendirilebilir. IIS; HTTPS uç noktası, uygulama havuzları, site bağlamaları ve uygun dağıtım yöntemleriyle uygulamayı yönetmeye yardımcı olur.

İç müşteri portalı, şirket içi üretim takip uygulaması, .NET API, ERP entegrasyonu ve Windows kimlik doğrulaması kullanan özel yazılımlar örnek kullanım alanlarıdır. Ancak ASP.NET Core platformlar arası çalışabildiğinden her .NET uygulaması mutlaka Windows sunucusu gerektirir demek doğru değildir. Windows bağımlılığı olmayan iş yükleri için Linux barındırma da teknik seçenek olabilir.

Başlangıçta uygulamanın Windows servisleri, COM bileşenleri, Active Directory, yerel dosya yolları veya IIS'e özgü modüllere bağımlı olup olmadığını belgeleyin. Bu envanter, gereksiz Windows lisansı giderini veya sonradan çıkan uygulama uyumsuzluğunu önlemeye yardımcı olur.

2. ASP.NET Core ile eski ASP.NET Framework aynı mıdır?

Hayır. ASP.NET Core, modern .NET üzerinde çalışan ve farklı işletim sistemlerine dağıtılabilen bir web uygulaması çerçevesidir. Eski ASP.NET Web Forms veya .NET Framework uygulamaları ise farklı çalışma zamanı ve IIS bağımlılıklarına sahip olabilir. Her projenin yalnız dosyalarını kopyalayarak yeni .NET sürümüne geçirilebileceği varsayılmamalıdır.

Müşterinin uygulama adını bilmek yeterli değildir. Proje dosyasındaki Target Framework, kullanılan paketler, Windows bağımlılıkları, özel IIS modülleri, yapılandırma dosyaları ve uygulama başlatma davranışı incelenmelidir. Özellikle Web Forms kullanan bir proje için modern ASP.NET Core'a geçiş ayrı bir yazılım dönüşümü gerektirebilir.

Sunucu teklifi almadan önce uygulama geliştiricisinden şu üç bilgiyi yazılı isteyin: hedef çalışma zamanı ve destek bitişi, gerekli Windows Server sürümü ve tercih edilen yayın yöntemi. Bu bilgiler olmadan “her .NET sürümü çalışır” iddiası güvenilir değildir.

3. IIS üzerinde ASP.NET Core yayını nasıl çalışır?

Microsoft'un IIS üzerinde ASP.NET Core barındırma rehberi uygulama havuzu, ASP.NET Core Module ve IIS yapılandırmasını açıklar. Sunucuda uygun Web Server (IIS) rolünün ve seçilen dağıtım modeline göre gerekli .NET bileşenlerinin bulunması gerekir.

.NET Hosting Bundle, uygun .NET Runtime ve ASP.NET Core Module bileşenlerini kurarak uygulamanın IIS ile birlikte çalışmasını sağlar. Framework-dependent dağıtımda sunucudaki uygun runtime gerekir; self-contained dağıtım uygulamanın hedef runtime'ını paketler. Her iki modelin yama, dağıtım boyutu ve sorumlulukları farklıdır.

ASP.NET Core uygulama havuzunda No Managed Code seçimi Microsoft tarafından önerilen yaygın ayardır; bu, uygulamanın yönetilen kod kullanmadığı anlamına gelmez. Modern .NET çalışma zamanı, klasik masaüstü .NET CLR yükleme modeliyle aynı şekilde başlatılmaz. Hedef mimari ve bitlik bilgisi ayrıca doğrulanmalıdır.

4. Windows VPS mi dedicated sunucu mu seçilmeli?

Sanal sunucu çoğu uygulama için hızlı devreye alma ve kademeli kaynak artırma olanağı sunabilir. Dedicated fiziksel sunucu ise sürekli yoğun işlem yükü, özel donanım veya fiziksel izolasyon gerektiren projelerde değerlendirilebilir. Bu kararın tek girdisi toplam kullanıcı sayısı değildir.

Örneğin az sayıda kullanıcının ağır raporlar ürettiği bir B2B uygulaması, çok sayıda kullanıcının basit bilgi ekranı açtığı uygulamadan daha fazla CPU veya veritabanı I/O tüketebilir. Aynı vCPU ve RAM rakamı yazılan iki teklif, farklı işlemci ve depolama altyapısında aynı gecikmeyi sunmayabilir.

Kaynak seçiminde eşzamanlı istek sayısı, istek süresi, işlemci kullanım tepe değerleri, ayrılmış RAM, disk gecikmesi, ağ kapasitesi ve büyüme birlikte değerlendirilmelidir. Ön keşifte ölçülemeyen kalemler varsayım olarak açıkça yazılmalı ve pilot yük testiyle doğrulanmalıdır.

5. .NET 8, .NET 9 ve .NET 10 destek süreleri neden önemli?

Uygulama güvenliği ve sonraki sürüm yükseltmeleri açısından kullanılan .NET'in destek döngüsü önemlidir. Microsoft'un .NET sürümleri ve destek tablosuna göre 24 Ekim 2026 itibarıyla .NET 10 LTS desteklenmektedir; .NET 8 LTS ve .NET 9 STS için destek bitişi Kasım 2026'dır. Sunucu kiralarken yalnız mevcut sürümü değil, uygulamanın hangi dönemde yükseltileceğini de planlayın.

Bir sunucuda birden fazla runtime kurulması her sürümün kalıcı olarak güvenli kalacağı anlamına gelmez. Özellikle geliştirme ekibi eski bağımlılık kullanıyorsa sürüm geçişi için staging testleri, paket güncellemeleri ve geri dönüş yöntemi gerekir.

Teklifte işletim sistemi güncellemeleri, .NET Hosting Bundle yamaları ve uygulamanın kod güncellemelerinin kimin sorumluluğunda olduğu belirtilmelidir. Hosting sağlayıcısı çalışma ortamını güncellediğinde uygulamanın yeni runtime ile çalışacağını kim test edecek sorusunun yazılı cevabı bulunmalıdır.

6. SQL Server uygulaması için NVMe, RAM ve CPU nasıl planlanır?

ASP.NET Core API'sinin hızlı açılması, arkasındaki SQL sorgularının hızlı tamamlandığını garanti etmez. Bir işlemde veritabanı bağlantı gecikmesi, eksik indeksler, ağır sorgular, beklemeler ve yetersiz disk performansı toplam yanıt süresini belirleyebilir.

Microsoft'un SQL Server disk I/O sorunlarını inceleme rehberi disk gecikmesinin işletim sistemi ve veritabanı tarafında beraber ölçülmesini önerir. NVMe etiketi tek başına performans garantisi değildir. Gerçek veritabanı hacmi, işlem profili, okuma/yazma yoğunluğu ve izleme verileriyle depolama seçilmelidir.

Uygulama ve SQL'in aynı sunucuda bulunması küçük veya belirli iş yüklerinde yönetimi sadeleştirebilir. Ayrı SQL katmanı ise kaynak izolasyonu ve bağımsız ölçekleme açısından uygun olabilir; fakat ek ağ, lisans, yedekleme ve yönetim maliyetleri doğurur. Kararı uygulama ölçümleri ve güvenlik gereksinimleriyle verin.

7. IIS güvenliği, TLS ve uygulama havuzu izinleri nasıl olmalı?

Bir kurumsal IIS sunucusunda HTTPS sertifikası, kısıtlanmış yönetim erişimi, güncel güvenlik yamaları ve asgari yetkili uygulama kimliği temel kontrollerdir. Her uygulamanın dosya sistemine ve veritabanına hangi hesapla eriştiği belgelenmelidir. Uygulama havuzunun geniş yönetici yetkileriyle çalışması gerekmiyorsa bu haklar verilmemelidir.

Microsoft'un ASP.NET Core IIS kurulum dokümanı üretim güvenliği için dosya ACL, HTTPS ve Data Protection konularının ayrıca yapılandırılması gerektiğini vurgular. Oturum çerezleri ve kriptografik anahtarlar için uygulamanın uygun Data Protection anahtar yönetimi önemli olabilir.

İnternete RDP veya SQL yönetim portları açmak yerine uygun kısıtlamalar, çok faktörlü erişim ve gerektiğinde firewall ve VPN hizmetleri kullanılmalıdır. Web üzerinden hizmet verilen uygulamaya ait herkese açık HTTPS erişimi ile yalnız yöneticiye açık sunucu erişimi ayrı ağ politikalarıyla korunmalıdır.

8. ASP.NET Core 500.30 veya IIS 500.19 hatası neyi gösterir?

Bir dağıtımın başarılı görünmesi, uygulamanın açılacağını kanıtlamaz. 500.30, sık karşılaşılan bir ASP.NET Core başlatma hatası sınıfıdır; hedef çalışma zamanının eksikliği, yanlış yapılandırma veya uygulama başlangıç istisnası gibi nedenler incelenebilir. 500.19 ise IIS yapılandırma veya ilgili yetki sorunlarına işaret edebilir.

Microsoft'un ASP.NET Core IIS hata rehberi, olay günlüğü, uygun hosting modülü, uygulama havuzu kimliği ve gerekli runtime sürümü gibi kontrolleri açıklar. Hatayı kapatmak için üretim ortamında kalıcı ayrıntılı hata ekranı açmak yerine logları güvenli şekilde inceleyin.

Bir yayın planında yalnız “dosyalar kopyalandı” kaydı değil; uygulamanın sağlık URL'si, kritik veritabanı sorgusu, oturum açma, form gönderme ve gerektiğinde ödeme/entegrasyon testleri de bulunmalıdır. Böylece başarısız dağıtım kullanıcıya yansımadan tespit edilebilir.

9. GitHub CI/CD, staging ve geri dönüş planı nasıl oluşturulur?

Kaynak kodu ayrı tutulan geliştirme, staging ve production ortamlarında ilerletmek sürüm kontrolünü kolaylaştırır. Aynı uygulama için test veritabanı, üretimden ayrılmış erişim anahtarları ve hatalı sürümde geri alınabilir dağıtım paketi tasarlayın.

CI/CD sistemi kaynak testlerini, bağımlılık güvenliğini, üretim derlemesini ve yapılandırma doğrulamalarını yapabilir. Ancak başarılı GitHub Actions çalışması, IIS üzerindeki canlı sitenin çalıştığı anlamına gelmez. Canlı health check ve gerektiğinde uygulama içi işlem testiyle yayın kabulünü tamamlayın.

Yazılım geliştirme ekipleri için sunucu çözümleri seçerken uygulamanın tek IIS sitesinde mi, birden çok uygulama havuzunda mı veya ayrı staging makinelerinde mi çalışacağı değerlendirilebilir. Dağıtım sonrası sorunlarda rollback yetkisinin kimde olduğu da sözleşmede net olmalıdır.

10. IIS ve SQL için yedekleme ile felaket kurtarma aynı şey mi?

Hayır. IIS site dosyaları ve web sunucusu yapılandırmasıyla, SQL Server içindeki işlem verileri farklı koruma ihtiyaçlarına sahiptir. Bir uygulamanın kod deposu bulunması, üretimdeki kullanıcı dosyalarının, şifreleme anahtarlarının veya veritabanının yedeği olduğu anlamına gelmez.

Yedekleme planında uygulama tutarlı SQL yedeği, uygun saklama politikası, üretimden ayrılmış kopyalar, şifreleme anahtarlarının güvenli yönetimi ve test ortamında geri yükleme bulunmalıdır. RPO, kabul edilebilir veri kaybı aralığıdır; RTO, sistemin geri dönüş hedefidir. Bu değerler satın alma ve iş birimleri tarafından tanımlanmalıdır.

Teklifte yedekleme ve felaket kurtarma hizmetlerini karşılaştırırken yalnız yedek kapasitesini değil, test sıklığını ve hangi öğelerin geri yükleneceğini de sorun: web uygulaması, veritabanı, sertifikalar, görevler, kullanıcı dosyaları ve ilgili bağımlılıklar. Bunlar olmadan sunucu açılsa bile uygulama çalışmayabilir.

11. ASP.NET uygulamasını yeni Windows Server'a nasıl taşırsınız?

Taşıma envanterinde IIS site bağlamaları, uygulama havuzları, Target Framework, Hosting Bundle, Windows Authentication, TLS sertifikaları, çevre değişkenleri, servis hesapları, zamanlanmış işler, SQL veritabanı ve dış API bağlantıları yer almalıdır. Eski .NET Framework uygulamalarında ayrıca COM veya IIS modülü gibi bağımlılıklar bulunabilir.

Önerilen aşamalar; envanter → yedek → hedef Windows/IIS hazırlığı → staging yayın → işlevsel test → son veri eşitleme → DNS/bağlantı geçişi → canlı kontrol → geri dönüş penceresi şeklindedir. DNS TTL ayarı tek başına sıfır kesinti garantisi sağlamaz; veritabanına iki farklı ortamdan eşzamanlı yazma riskini ayrıca ele alın.

Kurumsal müşteriler için geçiş maliyeti bazen sunucu aylık bedelinden daha önemli olabilir. Sağlayıcıdan uygulama geçişi, geliştirici desteği, SSL, veri tabanı taşıma ve iş saatleri dışındaki bakım penceresinin hangi kapsamda olduğunu yazılı olarak isteyin.

12. Windows IIS sunucu kiralama teklifinde neler karşılaştırılmalı?

Sunucu kiralamada en düşük aylık fiyat, eksik lisans, zayıf yedek veya tanımsız yönetim hizmeti nedeniyle toplam maliyette en uygun seçenek olmayabilir. Aynı ihtiyaç listesiyle gelen teklifleri ayrı kalemler halinde karşılaştırın.

Basit TCO yaklaşımı: 12 aylık toplam maliyet = başlangıç kurulum ve taşıma bedeli + 12 × (aylık sunucu + lisans + yedekleme + destek) + öngörülen ek giderler. Bu bir hesap yöntemi; gerçek fiyat veya tasarruf vaadi değildir. Paketlerin genel yaklaşımı için sunucu kiralama fiyatlandırmasını inceleyebilirsiniz.

13. Satış ve BT için kopyalanabilir teklif ihtiyaç listesi

Bir ASP.NET Core projesi için teklif isteğinde bulunurken şu bilgileri paylaşın: uygulama tipi ve .NET sürümü, IIS/Windows bağımlılıkları, SQL Server sürümü ve veri hacmi, tahmini ve eşzamanlı istek profili, kullanıcı/şube sayısı, API entegrasyonları, trafik ve depolama büyümesi, mevcut sunucu metrikleri, staging/production ihtiyacı ve istenen destek kapsamı.

Güvenlik için HTTPS, kimlik doğrulama, VPN, dosya izinleri ve yönetim erişimi beklentinizi belirtin. Kesinti toleransı, RPO/RTO, geri yükleme testi, uygulama taşıma tarihi ve sorumluluk matrisi de yazılı olmalıdır. Teklif formuna müşteri verisi, parolalar, özel anahtar veya gizli yapılandırma dosyası eklemeyin.

Netsun Bilişim ile teknik keşif: Mevcut IIS altyapınızı taşıma, yeni bir ASP.NET Core API için Windows sunucu kiralama veya SQL Server barındırma ihtiyacınız varsa sistem envanterini paylaşarak çözüm isteyebilirsiniz. Donanım ve lisans değerleri uygulamanın gerçek ihtiyaçlarına göre belirlenir. Windows IIS ve ASP.NET Core sunucusu için teklif alın.

Resmî kaynaklar

Kurulum ve güvenlik için Microsoft ASP.NET Core IIS barındırma, IIS'e yayınlama, IIS hata ayıklama, .NET sürüm ve destek tarihleri ve SQL Server disk I/O incelemesi belgelerini kullanın. Ürün sürümü, lisans ve barındırma modeli için nihai teknik koşullar sözleşme öncesinde doğrulanmalıdır.

Sık sorulan sorular

1. ASP.NET Core uygulaması için Windows sunucu şart mı?

Hayır. ASP.NET Core birden fazla işletim sisteminde çalışabilir. IIS, Windows Authentication veya başka Windows bağımlılıkları gerekiyorsa Windows Server uygun bir seçenek olabilir.

2. IIS üzerinde ASP.NET Core çalıştırmak için Hosting Bundle gerekir mi?

Uygun IIS/ASP.NET Core Module entegrasyonu gereklidir. Framework-dependent kurulumda hedef runtime'ın sunucuda bulunması gerekir; self-contained yaklaşımda runtime uygulamayla dağıtılabilir. Kesin kurulum yöntemi kullanılan sürüme göre doğrulanmalıdır.

3. .NET 10 ile .NET Framework 4.x uygulaması aynı mıdır?

Hayır. Modern .NET ve .NET Framework farklı çalışma zamanlarıdır. Eski Web Forms veya özel IIS bağımlılıkları bulunan uygulamalar için taşıma öncesinde uyumluluk analizi gerekir.

4. ASP.NET Core uygulaması için kaç GB RAM gerekir?

Tek bir genel kapasite yoktur. Eşzamanlı istek sayısı, bellek profili, SQL yükü, önbellek ve diğer servisler ölçülerek boyutlandırma yapılır.

5. SQL Server aynı IIS sunucusunda mı olmalı?

Küçük belirli iş yüklerinde aynı sunucuda olabilir; izolasyon ve performans gereksinimlerinde ayrı veri katmanı daha uygun olabilir. Nihai seçim ölçüm ve lisans maliyetiyle yapılmalıdır.

6. ASP.NET Core 500.30 hatası nasıl çözülür?

Uygulama başlangıç hatası ve runtime uyumluluğu kontrol edilmeli; Windows Event Log, ASP.NET Core Module ve IIS yapılandırması incelenmelidir. Gerçek neden loglara göre bulunmalıdır.

7. Windows IIS sunucu kiralama ücretine SQL lisansı ve yedekleme dahil midir?

Her teklifte değildir. Windows, SQL, yedekleme, güvenlik ve yönetilen hizmet kapsamını ayrı ayrı yazılı isteyin.

8. ASP.NET Core sunucu kiralama için nasıl teklif alabilirim?

.NET ve SQL sürümlerinizi, kullanıcı/istek profilinizi, mevcut performans ve taşıma ihtiyacınızı, yedekleme ve güvenlik beklentilerinizi paylaşın. Kurumsal Windows sunucu teklif formunu doldurun.