Azure Uygulaması Hizmetlerini başka bir bölgeye yeniden taşıma

Bu makalede, App Service kaynaklarının farklı bir Azure bölgesine nasıl taşındığı açıklanır.

Mevcut Azure kaynaklarınızı bir bölgeden diğerine taşımak istemenizin çeşitli nedenleri vardır. Şunu yapmak isteyebilirsiniz:

• Yeni bir Azure bölgesinden yararlanın.
• Yalnızca belirli bölgelerde kullanılabilen özellikleri veya hizmetleri dağıtın.
• İç ilke ve idare gereksinimlerini karşılayın.
• Şirket birleşmeleri ve alımlarıyla uyumlu hale getirme
• Kapasite planlama gereksinimlerini karşılayın.

App Service kaynakları bölgeye özgü olup bölgeler arasında taşınamaz. Hedef bölgede mevcut App Service kaynaklarınızın bir kopyasını oluşturup içeriğinizi yeni uygulamaya yeniden taşımanız gerekir. Kaynak uygulamanız özel bir etki alanı kullanıyorsa, yeniden konumlandırma tamamlandıktan sonra hedef bölgedeki yeni uygulamaya geçirebilirsiniz.

Uygulamanızı kopyalamayı kolaylaştırmak için tek tek App Service uygulamasını yedekleyebilir ve başka bir bölgedeki app Service planına geri yükleyebilirsiniz.

Önkoşullar

• App Service uygulamasının taşımak istediğiniz Azure bölgesinde olduğundan emin olun.
• Hedef bölgenin App Service'i ve kaynaklarını taşımak istediğiniz ilgili hizmetleri desteklediğinden emin olun.
• App Service kaynaklarını hedef aboneliğe ve bölgeye dağıtmak için yeterli iznin mevcut olduğunu doğrulayın.
• Herhangi bir Azure ilkesinin bölge kısıtlaması ile atanarak atanmadığını doğrulayın.
• İşlem kaynağı fiyatları bölgeden bölgeye değişe kadar tüm işletim maliyetlerini göz önünde bulundurun. Olası maliyetlerinizi tahmin etmek için bkz . Fiyatlandırma hesaplayıcısı.

Hazırlama

Kullanmakta olduğunuz tüm App Service kaynaklarını belirleyin. Örneğin:

• App Service uygulamaları
• App Service planları
• Dağıtım yuvaları
• Azure'da satın alınan özel etki alanları
• TLS/SSL sertifikaları
• Azure Sanal Ağ tümleştirmesi
• Karma bağlantılar.
• Yönetilen kimlikler
• Yedekleme ayarları

İçeri aktarılan sertifikalar veya karma bağlantılar gibi bazı kaynaklar diğer Azure hizmetleriyle tümleştirme içerir. Bu kaynakları bölgeler arasında taşıma hakkında bilgi için ilgili hizmetlerin belgelerine bakın.

Planlama

Bu bölüm, aşağıdaki alanlardaki bir planlama denetim listesidir:

• Durum, Depolama ve aşağı akış bağımlılıkları
• Sertifikalar
• Yapılandırma
• Sanal Ağ Bağlantısı / Özel Adlar / DNS
• Kimlikler
• Hizmet Uç Noktaları

Durum, depolama ve aşağı akış bağımlılıkları

• App Service Uygulamanızın durum bilgisi olup olmadığını belirleyin. App Service Apps'in durum bilgisi olmayan olması ve sürücüdeki %HOME%\site dosyaların yalnızca dağıtılan uygulamayı geçici dosyalarla çalıştırmak için gereken dosyalar olması gerekse de, sanal sürücüde %HOME%\site çalışma zamanı uygulama durumunu depolamak mümkündür. Uygulamanız paylaşılan depolama yolunda durum yazıyorsa, kaynak taşıma sırasında bu durumu nasıl yönetebileceğinizi planladığınızdan emin olun.

  İpucu

  Kudu'yu portal erişimiyle birlikte dizin altındaki %HOME%\site dosyaları okuyabilen/yazabilen bir dosya erişim API'sini (Sanal Dosya Sistemi (VFS)) sağlamak için kullanabilirsiniz. Daha fazla bilgi için bkz . Kudu Wiki.

• Uygulama kodunda iç önbelleğe alma ve durum denetimi.

• Oturum benzitesi ayarını devre dışı bırakın. Mümkün olduğunda, oturum benşimi ayarını devre dışı bırakmanızı öneririz. Oturum bennizimini devre dışı bırakmak, yatay ölçek genişletme için yük dengelemeyi geliştirir. Herhangi bir iç durum, özellikle sıfır azaltma süresi gerekliyse, iş yükünün kesilmesine yönelik planlamayı etkileyebilir. Mümkün olduğunda, taşıma hazırlığında uygulamayı durum bilgisi olmayan hale getirmek için herhangi bir uygulama durumunun yeniden düzenlenmesi yararlı olabilir.

• Veritabanı bağlantı dizesi analiz etme. Veritabanı bağlantı dizesi Uygulama Ayarları'nda bulunabilir. Ancak, uygulamayla birlikte gönderilen yapılandırma dosyalarında da sabit kodlanmış veya yönetilebilirler. İş yükünü taşımaya yönelik üst düzey planlamanın bir parçası olarak veri geçişini/çoğaltmasını analiz edin ve planlayın. Gevezen veya Gecikme Süresi Açısından Kritik Uygulamalar için, hedef bölgedeki uygulamanın kaynak bölgedeki veri kaynaklarına geri ulaşması iyi bir performans sağlamaz.

• Dış önbelleğe almayı analiz etme (örneğin Redis). Uygulama önbellekleri uygulamaya mümkün olduğunca yakın dağıtılmalıdır. Önbelleklerin doldurulma şeklini, süre sonu/çıkarma ilkelerini ve bir soğuk önbelleğin kesinti sonrasında iş yüküne ilk erişen kullanıcılar üzerindeki etkisini analiz edin.

• Api (veya uygulama) bağımlılıklarını analiz etme ve planlama Hedef bölgedeki uygulama hala kaynak bölgede bulunan bağımlılıklara ulaşırsa bölgeler arası iletişim önemli ölçüde daha az performans gösterir. İş yükü yeniden konumlandırma işleminin bir parçası olarak tüm aşağı akış bağımlılıklarını yeniden konumlandırmanızı öneririz. Ancak *şirket içi* kaynaklar, özellikle de hedef bölgeye coğrafi olarak daha yakın olan kaynaklar (geri gönderme senaryolarında olduğu gibi) özel durumdur.

  Azure Container Registry, App Service için Özel Kapsayıcı Görüntülerine karşı çalışacak şekilde yapılandırılmış bir aşağı akış (çalışma zamanı) bağımlılığı olabilir. Container Registry'nin Uygulamanın kendisiyle aynı bölgede olması daha mantıklıdır. Gerekli görüntüleri hedef alma bölgesindeki yeni bir ACR'ye yüklemeyi göz önünde bulundurun. Aksi takdirde, görüntüleri kaynak bölgede tutmayı planlıyorsanız coğrafi çoğaltma özelliğini kullanmayı göz önünde bulundurun.

• Bölgesel hizmetleri analiz etme ve planlama. Application Insights ve Log Analytics verileri bölgesel hizmetlerdir. Hedef bölgede yeni Application Insights ve Log Analytics depolama alanı oluşturmayı düşünün. App Insights için yeni bir kaynak, Uygulama Yapılandırması'deki değişikliğin bir parçası olarak güncelleştirilmiş olması gereken bağlantı dizesi de etkiler.

Sertifikalar

App Service yeniden konumlandırmanızı planladığınızda dikkate alınması gereken çeşitli sertifika türleri vardır:

• App Service'ten Ücretsiz Yönetilen Sertifika dışarı aktarılamaz.
• Azure Key Vault aracılığıyla app service sertifikası PS1/CLI kullanılarak dışarı aktarılabilir.
• App Service dışında yönettiğiniz bir sertifika.
• Azure Key Vault aracılığıyla yönetilmeyen bir App Service Sertifikası dışarı aktarılabilir.
• App Service sertifika kaynakları yeni bir Kaynak Grubuna veya Aboneliğe taşınabilir ancak bölgeler arası taşınamayabilir. Bölgeler arası yeniden konumlandırmalar App Service Sertifikaları tarafından desteklenmez.
• Azure Key Vault'ta yönettiğiniz ve depoladığınız Yönetilen Sertifikalar'ın önce kaynak Anahtar Kasası'ndan dışarı aktarılması ve hedef uygulamayla ilişkilendirilmiş Hedef Anahtar Kasası'na yeniden içeri aktarılması gerekir.

Dikkate alınması gereken bazı diğer noktalar:

• App Service uygulamasının SSL bağlantısının belirli bir uygulama tarafından belirlenen IP'ye bağlı olduğu Uygulama Atanan Adresler, üçüncü taraf ağlardan App Service'e yapılan çağrıların listelenmesi için kullanılabilir. Örneğin, bir ağ /BT yöneticisi statik, iyi bilinen bir adres kullanmak için şirket içi ağdan veya sanal ağdan giden çağrıları kilitlemek isteyebilir. Bu nedenle, Uygulama Tarafından Atanan Adres özelliği kullanılıyorsa, uygulamaya arayanlar için iç, dış veya üçüncü taraflar gibi yukarı akış güvenlik duvarı kuralları denetlenmeli ve yeni adres hakkında bilgilendirilmelidir. Güvenlik duvarı kuralları, iş ortakları veya iyi bilinen müşteriler gibi iç, dış veya üçüncü taraflar olabilir.

• Herhangi bir yukarı akış Ağ Sanal Gereci (NVA) veya Ters Ara Sunucu kullanmayı göz önünde bulundurun. Konak üst bilgisini veya ve/veya SSL sonlandırıcısını yeniden yazarsanız NVA yapılandırmasının değişmesi gerekebilir.

Not

App Service Ortamı, SSL üzerinden aşağı akış uygulama bağımlılıklarına yönelik aşağı akış çağrılarına olanak tanıyan tek App Service teklifidir. Burada SSL, standart olmayan Kök CA sertifikalarıyla oluşturulmuş otomatik olarak imzalanan/PKI'ya dayanır. Çok kiracılı hizmet, müşterilerin güvenilen sertifika deposuna yüklemesine erişim sağlamaz.

App Service Ortamı bugün SSL sertifikası satın alınmasına izin vermiyor, yalnızca Kendi Sertifikalarınızı Getirin. IP-SSL mümkün değildir (ve anlamlı değildir), ancak SNI'dir. İç App Service Ortamı bir genel etki alanıyla ilişkilendirilmez ve bu nedenle kullanılan SSL sertifikaları müşteri tarafından sağlanmalıdır ve bu nedenle PKI kullanılarak oluşturulan iç kullanım sertifikaları gibi taşınabilir. Dış modda App Service Ortamı v3, normal çok kiracılı App Service ile aynı özellikleri paylaşır.

Yapılandırma

• Ortama ve bölgeye özgü, değiştirilmesi gerekebilecek ayarlar için Uygulama Yapılandırması gözden geçirin. Uygulama Ayarları ile geçersiz kılınabilen veya geçersiz kılınmayan disk dosyası yapılandırmasını içerdiğini denetlediğinden emin olun.

• Yapılandırmanın merkezi (aşağı akış) veritabanı bağımlılığından veya Azure Uygulaması lication Yapılandırması gibi bir hizmetten de yönetilebileceğini düşünün.

• App Service Key Vault başvurularını yeniden oluşturun. Key Vault başvuruları kaynağa atanan benzersiz MSI ile ilgilidir (KV veri düzlemi erişimi vardır) ve Key Vault'un büyük olasılıkla aynı kaynak bölgede olması gerekir. Az Key Vault içeriği Bir Azure coğrafi sınırı boyunca dışarı aktarılamaz.

Sanal Ağ Bağlantısı / Özel Adlar / DNS

• App Service Ortamı, sanal ağ tarafından eklenen tek kiracı hizmetidir. App Service Ortamı ağ, "Özel Uç Noktalar" veya "Bölgesel Sanal Ağ tümleştirmesi" gerektiren çok kiracılı App Service'ten farklıdır. Diğer seçenekler arasında eski P2S VPN tabanlı sanal ağ tümleştirmesi ve Karma Bağlantılar (bir Azure Relay hizmeti) bulunur.

  Not

  ASEv3 Ağı basitleştirilmiştir- Azure Yönetim trafiği ve App Service Ortamı kendi aşağı akış bağımlılıkları müşteri Sanal Ağ tarafından görülmeyebilir; bu da müşterinin tüm trafik için zorlama tüneli kullandığı veya giden trafiğin bir alt kümesini ağ sanal gereci/güvenlik duvarı aracılığıyla gönderdiği yapılandırmayı büyük ölçüde basitleştirir.

  Karma Bağlantılar (Azure Relay) bölgeseldir. Karma Bağlantılar kullanılıyorsa ve bir Azure Relay Ad Alanı başka bir bölgeye taşınabiliyor olsa da, Karma Bağlantıyı yeniden dağıtmak (Hedef kaynakların dağıtılmasıyla yeni bölgede Karma bağlantının ayarlandığından emin olun) ve Karma Bağlantı Yöneticisi yeniden bağlamak daha kolay olabilir. Karma Bağlantı Yöneticisi konumu dikkatle dikkate alınmalıdır.

• Sıcak bir bekleme bölgesi için stratejiyi izleyin. Kaynak yeniden konumlandırmadan önce çekirdek ağ ve bağlantı, Merkez ağı, etki alanı denetleyicileri, DNS, VPN veya Express Route vb. mevcut ve test edilmiş olduğundan emin olun.

• Yukarı veya aşağı akış ağ ACL'lerini ve yapılandırmalarını doğrulayın. Örneğin, yalnızca Uygulama trafiğinizi izin veren bir dış aşağı akış hizmeti düşünün. Daha sonra çok kiracılı bir App Service için yeni bir Uygulama Planı'na yeniden konumlandırma, giden IP adreslerinde yapılan bir değişiklik olacaktır.

• Çoğu durumda, hedef bölge sanal ağlarının benzersiz adres alanına sahip olduğundan emin olmak en iyisidir. Benzersiz bir adres alanı, örneğin verileri çoğaltmak için gerekliyse sanal ağ bağlantısını kolaylaştırır. Bu nedenle, bu senaryolarda değiştirmek için örtük bir gereksinim vardır:

  • Özel DNS
  • Kaynaklara IP adresine göre başvuran sabit kodlanmış veya dış yapılandırmalar (konak adı olmadan)
  • Ağ Güvenlik Grupları ve Güvenlik Duvarı yapılandırması da dahil olmak üzere ağ ACL'leri (şirket içi NVA'ların üzerindeki etkiyi burada da göz önünde bulundurun)
  • Tüm yönlendirme kuralları, Kullanıcı Tanımlı Yol Tabloları

  Ayrıca, var olan DevOps dağıtım kaynaklarını taşıyorsanız bölgeye özgü IP Aralıkları / Hizmet Etiketleri de dahil olmak üzere yapılandırmayı denetlediğinden emin olun.

• Azure etki alanları ve Azure DNS Özel Bölgeleri için Azure'a iletecek şekilde yapılandırılmış, müşteri tarafından dağıtılan özel DNS için daha az değişiklik gereklidir. Ancak, Özel Uç Noktalar bir kaynak FQDN'sini temel aldığı için ve bu genellikle kaynak adı olduğundan (hedef bölgede farklı olması beklenebilir), yapılandırmada başvurulan FQDN'lerin uygun şekilde güncelleştirildiğinden emin olmak için yapılandırmayı çapraz denetlemeyi unutmayın.

• Kullanılırsa hedef bölgede Özel Uç Noktaları yeniden oluşturun. Aynı durum Bölgesel Sanal Ağ tümleştirmesi için de geçerlidir.

• App Service Ortamı için DNS genellikle müşterilerin özel özel DNS çözümü aracılığıyla yönetilir (uygulama başına temel ayarlarda el ile geçersiz kılma özelliği vardır). App Service Ortamı giriş/çıkış için bir yük dengeleyici sağlarken App Service'in kendisi Konak üst bilgilerinde filtrelenir. Bu nedenle, birden çok özel ad aynı App Service Ortamı giriş uç noktasına işaret edilebilir. App Service Ortamı etki alanı doğrulaması gerektirmez.

  Not

  App Service Ortamı v3 için Kudu uç noktası yalnızca adresinde {resourcename}.scm.{asename}.appserviceenvironment.netkullanılabilir. v3 DNS ve Ağ App Service Ortamı hakkında daha fazla bilgi için bkz. ağ App Service Ortamı.

  App Service Ortamı için müşteri yönlendirmeye ve dolayısıyla kesme için kullanılan kaynaklara sahiptir. Dışarıdan App Service Ortamı erişimin etkinleştirildiği her yerde (genellikle Katman 7 NVA veya Ters Ara Sunucu - Traffic Manager aracılığıyla) veya Azure Front Door/Diğer L7 Genel Yük Dengeleme Hizmeti kullanılabilir.

• Hizmetin genel çok kiracılı sürümü için, veri düzlemi uç noktaları için varsayılan bir ad {resourcename}.azurwwebsites.net ve Kudu (SCM) uç noktası için varsayılan bir ad sağlanır. Hizmet varsayılan olarak bir genel uç nokta sağladığından, etki alanı sahipliğini kanıtlamak için bağlamanın doğrulanması gerekir. Ancak bağlama gerçekleştikten sonra yeniden doğrulama gerekmez ve genel DNS kayıtlarının App Service uç noktasını işaret etmeleri de gerekmez.

• Özel bir etki alanı kullanıyorsanız, bunu hedef uygulamaya önceden bağlayın. Hedef uygulamada etki alanını doğrulayın ve etkinleştirin.

Kimlikler

• App Service Yönetilen Hizmet Kimliklerini yeni hedef bölgede yeniden oluşturun.

• Yeni MSI kimlik bilgisi aşağı akış hizmeti erişimini (RBAC) atayın. Genellikle, otomatik olarak oluşturulan bir Microsoft Entra ID Uygulaması (EasyAuth tarafından kullanılan uygulama) varsayılan olarak Uygulama kaynak adını kullanır. Hedef bölgede yeni bir kaynağı yeniden oluşturmak için burada dikkat edilmesi gereken noktalar olabilir. Hedef dağıtım kaynaklarına ek erişim izinleriyle hem kaynağa hem de hedefe uygulanaabildiği için kullanıcı tanımlı bir Hizmet Sorumlusu yararlı olabilir.

• Kimlik Sağlayıcısı'nı (IDP) hedef bölgeye yeniden konumlandırmayı planlayın. Microsoft Entra ID genel bir hizmet olsa da, bazı çözümler yerel (veya şirket içi aşağı akış) IDP'sini temel alır.

• Kudu FTP kimlik bilgilerini kullanabilecek tüm kaynakları App Service'e güncelleştirin.

Hizmet uç noktaları

Azure Uygulaması Hizmeti için sanal ağ hizmet uç noktaları, belirtilen bir sanal ağa erişimi kısıtlar. Uç noktalar ayrıca IPv4 (internet protokolü sürüm 4) adres aralıkları listesine erişimi kısıtlayabilir. Event Hubs'a bu kaynakların dışından bağlanan tüm kullanıcıların erişimi reddedilir. Hizmet uç noktaları Event Hubs kaynağının kaynak bölgesinde yapılandırıldıysa, hedef bölgede de aynı işlem yapılması gerekir.

Azure Uygulaması Hizmeti'nin hedef bölgeye başarıyla yeniden oluşturulması için sanal ağ ve alt ağ önceden oluşturulmalıdır. Bu iki kaynağın taşınması Azure Kaynak Taşıyıcı aracıyla gerçekleştiriliyorsa, hizmet uç noktaları otomatik olarak yapılandırılmaz. Bu nedenle bunların el ile yapılandırılması gerekir. Bu yapılandırma Azure portalı, Azure CLI veya Azure PowerShell üzerinden yapılabilir.

Taşımak

App Service kaynaklarını yeniden dağıtmak için Azure portalını veya Kod Olarak Altyapı'yı (IaC) kullanabilirsiniz.

Azure portalını kullanarak yeniden yer değiştirme

Azure portalını kullanarak yeniden taşınmanın en büyük avantajı basitliğidir. Uygulama, plan ve içeriklerin yanı sıra birçok ayar yeni App Service kaynağına ve planına kopyalanmıştır.

App Service Ortamı (Yalıtılmış) katmanlar için önce tüm App Service Ortamı başka bir bölgede yeniden dağıtmanız gerektiğini ve ardından yeni bölgedeki yeni App Service Ortamı tek tek planları yeniden dağıtmaya başlayabileceğinizi unutmayın.

Azure portalını kullanarak App Service kaynaklarınızı yeni bir bölgeye yeniden dağıtmak için:

1. Kaynak uygulamanın bir yedeklemesini oluşturun.
2. Hedef bölgede yeni bir App Service planında uygulama oluşturun.
3. Hedef uygulamada yedeklemeyi geri yükleme
4. Özel bir etki alanı kullanıyorsanız, ile hedef uygulamaya asuid. önceden bağlayın ve hedef uygulamada etki alanını etkinleştirin.
5. Hedef uygulamanızdaki diğer her şeyi kaynak uygulamayla aynı olacak şekilde yapılandırın ve yapılandırmanızı doğrulayın.
6. Özel etki alanının hedef uygulamaya işaret etmeye hazır olduğunuzda etki alanı adını yeniden eşleyin.

IaC kullanarak yeniden yer değiştirme

Mevcut bir Sürekli Tümleştirme ve Sürekli Teslim/Dağıtım (CI/CD) işlem hattı mevcut olduğunda veya oluşturulduğunda IaC kullanın. Ci/CD işlem hattı etkinken, App Service kaynağınız bir dağıtım eylemi veya Kudu zip dağıtımı yoluyla hedef bölgede oluşturulabilir.

SLA gereksinimleri, ne kadar ek çaba gerektiğini belirlemelidir. Örneğin: Bu, sınırlı kapalı kalma süresine sahip bir yeniden dağıtım mı yoksa minimum veya hiç kapalı kalma süresi olmadan neredeyse gerçek zamanlı bir kesme mi gerekiyor?

Traffic Manager veya Azure Front Door gibi dış, genel trafik yönlendirme uç hizmetlerinin dahil edilmesi, dış kullanıcılar ve uygulamalar için kesintiyi kolaylaştırmaya yardımcı olur.

İpucu

Özel uç noktaların arkasında App Services yük devretmesi yaparken Traffic Manager 'ı (ATM) kullanmak mümkündür. Özel uç noktalara Traffic Manager Yoklamaları tarafından erişilemiyor olsa da, tüm uç noktaların düzeyi düşürülmüşse ATM yönlendirmeye izin verir. Daha fazla bilgi için bkz. Azure Traffic Manager ile Azure Uygulaması Hizmeti trafiğini denetleme.

Doğrulama

Yeniden konumlandırma tamamlandıktan sonra, önerilen yönergelerle Azure Uygulaması Hizmetini test edin ve doğrulayın:

• Azure Uygulaması Hizmeti hedef bölgeye yeniden konumlandırıldıktan sonra bir duman ve tümleştirme testi çalıştırın. Bir betik aracılığıyla el ile test edebilir veya test çalıştırabilirsiniz. Tüm yapılandırmaların ve bağımlı kaynakların düzgün bir şekilde bağlandığını ve yapılandırılan tüm verilerin erişilebilir olduğunu doğrulayın.

• Tüm Azure Uygulaması Hizmeti bileşenlerini ve tümleştirmeyi doğrulayın.

• Tüm resmi regresyon testleri dahil olmak üzere hedef bölge dağıtımında tümleştirme testi gerçekleştirin. Tümleştirme testi, iş yükü için geçerli olan her zamanki İş Ritmi dağıtım ve test süreçleriyle uyumlu olmalıdır.

• Özellikle yeniden konumlandırmanın güncelleştirmeleri, uygulamalarda veya Azure Kaynaklarında yapılan değişiklikleri veya kullanım profilindeki değişiklikleri içerdiği bazı senaryolarda, yeni iş yükünün amaca uygun olduğunu doğrulamak için yük testini kullanın. Yük testi, işlemleri ve izleme kapsamını doğrulamak için de bir fırsattır. Örneğin, gerekli altyapının ve uygulama günlüklerinin doğru oluşturulduğunu doğrulamak için yük testini kullanın. Yük testleri, yerleşik iş yükü performans temellerine göre ölçülmelidir.

İpucu

App Service'in yeniden yerleştirilmesi, Kullanılabilirlik ve Olağanüstü Durum Kurtarma planlamasının yeniden değerlendirilmesi için de bir fırsattır. App Service ve App Service Ortamı (App Service Ortamı v3) kullanılabilirlik alanlarını destekler ve kullanılabilirlik alanı yapılandırmasıyla yapılandırmanız önerilir. Dağıtım, fiyatlandırma ve sınırlamalar için önkoşulları göz önünde bulundurun ve bunları kaynak taşıma planlamasına dahil edin. Kullanılabilirlik alanları ve App Service hakkında daha fazla bilgi için bkz. Azure Uygulaması Hizmetinde Güvenilirlik.

Temizleme

Kaynak uygulamayı ve App Service planını silin. Ücretsiz olmayan katmandaki bir App Service planı, içinde çalışan bir uygulama olmasa bile ücret taşır.

Sonraki adımlar

PowerShell Kullanarak hizmet uygulamasını kopyalamayı Azure Uygulaması