Frequently asked questions for Azure Cloud Services (extended support)

• Cloud Services (classic): microsoft.classiccompute/domainnames
• Cloud Services (extended support): microsoft.compute/cloudservices

Cloud Services (extended support) is available in all public and sovereign cloud regions.

Customers need to request quota using the same processes as any other Azure Resource Manager product. Quota in Azure Resource Manager is regional and a separate quota request is needed for each region.

Cloud Services (extended support) doesn't support the logical concept of a hosted service, which included two slots (Production & Staging). Each deployment is an independent Cloud Service (extended support) deployment. To test and stage a new release of a cloud service, deploy a cloud service (extended support) and tag it as VIP swappable with another cloud service (extended support)

The concept of hosted service names doesn't exist anymore, you can't create an empty Cloud Service (extended support).

No, Cloud Services (extended support) doesn't support Resource Health Check (RHC).

There are no changes in the role instance metrics.

There are no changes to the design, architecture, or components of web and worker roles.

When multiple Scale calls happen on the same Cloud Service (for different roles) at the same approximate time, due to a race condition, the Microsoft Platform components go out of sync leading to failures. Microsoft is actively working on resolving this issue. The workaround suggested for the interim isn't to auto scale all roles simultaneously.

There are no changes to the design, architecture, or components of the role instances.

There are no changes to the rollout method. Cloud Services (classic) and Cloud Services (extended support) get the same updates.

Cloud Services (extended support) deployment only supports the Stopped- Allocated state, which appears as "stopped" in the Azure portal. Stopped- Deallocated state isn't supported.

Cloud Services (extended support) deployments can't scale across multiple clusters, availability zones, and regions.

Deployment ID, also known as Private ID, can be accessed using the CloudServiceInstanceView API. It's also available on the Azure portal under the Role and Instances blade of the Cloud Service (extended support)

Cloud Services (extended support) uses Azure Key Vault and Basic (Azure Resource Manager) Public IP addresses. Customers requiring certificates need to use Azure Key Vault for certificate management (learn more about Azure Key Vault pricing.)  Each Public IP address for Cloud Services (extended support) is charged separately (learn more about Public IP Address pricing.)

A bug in Bandwidth billing was fixed in November 2022, resulting in customers possibly seeing increased billing based on their data transfer out to other regions or internet. For further reference, visit the Azure bandwidth pricing page.

The Service Level Agreement (SLA) for Cloud Services (extended support) is same as SLA for Cloud Services (classic). Refer Licensing Documents.

Load balancers, network security groups, and route tables need to live in the same region and resource group.

Key Vault, virtual network, public IP addresses, network security groups, and route tables need to live in the same region.

Public IP addresses, load balancers, network security groups, and route tables need to live in the same virtual network.

Template and parameter files can be passed as a parameter using REST, PowerShell, and CLI. They can also be uploaded using the Azure portal.

Template and parameter files are only used for deployment automation. Like Cloud Services (classic), you can manually create dependent resources first and then a Cloud Services (extended support) deployment using PowerShell, CLI commands or through Portal with existing csdef, cscfg.

There are no changes required for your application code packaged in cspkg. Your existing applications continue to work as before.

CTP package format isn't supported in Cloud Services (extended support). However, it allows an enhanced package size limit of 800 MB

CSES doesn't support Managed Identity Support. So, Storage account by design doesn't allow CSES to access the package files when storage account is enabled only selected virtual network in the setting.

No, Cloud Service (extended support) deployments are tied to a cluster like Cloud Services (classic). Therefore, allocation failures continue to exist if the cluster is full.

Estimating the time required and complexity migration depends on a range of variables. Planning is the most effective step to understand the scope of work, blockers, and complexity of migration.

Virtual networks are a required resource for any deployment on Azure Resource Manager. Cloud Services (extended support) deployment must live inside a virtual network.

In Azure Resource Manager, components of your Cloud Services (extended support) deployment are exposed as a resource for better visibility and improved control. The same type of resources were used in Cloud Services (classic) however they were hidden. One example of such a resource is the Public Load Balancer, which is now an explicit 'read only' resource automatically created by the platform

A subnet containing Cloud Services (extended support) deployments can't be shared with deployments from other compute products such as Virtual Machines, Virtual Machines Scale Sets, Service Fabric, etc.

Cloud Services (extended support) supports dynamic & static IP allocation methods. Static IP addresses are referenced as reserved IPs in the cscfg file.

Customers are billed for IP Address use on Cloud Services (extended support) just as users are billed for IP addresses associated with virtual machines.

A reserved IP can't be added, removed, or changed during deployment update or upgrade. If the IP addresses need to be changed, use a swappable Cloud Service or deploy two Cloud Services with a CName in Azure DNS\Traffic Manager so that the IP can be pointed to either of them.

Yes. Cloud Services (extended support) can also be given a DNS name. With Azure Resource Manager, the DNS label is an optional property of the public IP address that is assigned to the Cloud Service. The format of the DNS name for Azure Resource Manager based deployments is <userlabel>.<region>.cloudapp.azure.com

No. Virtual network reference is mandatory during the creation of a cloud service. For an existing cloud service, the virtual network reference can't be changed. The virtual network address space itself can be modified using virtual network APIs.

Cloud Services (extended support) adopted the same process as other compute offerings where certificates reside within customer managed Key Vaults. This process enables customers to have complete control over their secrets & certificates.

No. Key Vault is a regional resource and customers need one Key Vault in each region. However, one Key Vault can be used for all deployments within a given region.

Yes. We don't allow cross subscription key vault references in Cloud Services to guard against escalation of privilege attacks through CS-ES. The subscription isn't a boundary that CS-ES crosses for references to secrets. The reason we don't allow cross subscription references is as an important final step to prevent malicious users from using CS-ES as a privilege escalation mechanism to access other users secrets. Subscription isn’t a security boundary, but defense in depth is a requirement. However, you can use the Key Vault extension to get cross subscription and cross region support for your certificates. Refer to the documentation here

Yes. The reason that we enforce region boundaries is to prevent users from creating architectures that have cross region dependencies. Regional isolation is a key design principle of cloud based applications. However, you can use the Key Vault extension to get cross subscription and cross region support for your certificates. Refer to the documentation here

When multiple Scale calls happen on the same Cloud Service (for different roles) at the same approximate time, due to a race condition, the Microsoft Platform components go out of sync leading to failures. Microsoft is actively working on resolving this issue. The workaround suggested for the interim isn't to auto scale all roles simultaneously.

This scenario isn't supported via Visual Studio. Deploy via PowerShell or Portal.

Next steps

To start using Cloud Services (extended support), see Deploy a Cloud Service (extended support) using PowerShell