Add support to enable automatic scaling for App Service Environment

[ShilpiRach]

Description

This PR adds support to enable automatic scaling for the Azure App Service Plan not enabled by default. This option is made available as it is considered a best practice to improve an app's performance and avoid cold start issues.

The change introduces an extension method WithAutomaticScaling for the AzureAppServiceEnvironment to enable automatic scaling. Customers can enable it with WithAutomaticScaling() or WithAutomaticScaling(true).

Testing

• Tested deploying an Aspire project using aspire deploy and ensured that the properties related to automatic scaling are set correctly for the app service plan and app services.
• Tested deploying an Aspire project WithAutomaticScaling(false) to ensure the properties related to PerSiteScaling are set correctly for the app service plan and app services.

Relevant properties for App Service Plan:

• perSiteScaling - false for automatic scaling, true otherwise
• elasticScaleEnabled - true for automatic scaling, false otherwise
• maximumElasticWorkerCount - applicable only when elasticScaleEnabled is true

Relevant properties for App Service

• numberOfWorkers - 1 for dashboard, max(30) for others
• functionAppScaleLimit - 1 for dashboard, not set for others

Checklist

• Is this feature complete?
  • Yes. Ready to ship.
  • No. Follow-up changes expected.
• Are you including unit tests for the changes and scenario tests if relevant?
  • Yes
  • No
• Did you add public API?
  • Yes
    • If yes, did you have an API Review for it?
      • Yes
      • No
    • Did you add <remarks /> and <code /> elements on your triple slash comments?
      • Yes
      • No
  • No
• Does the change make any security assumptions or guarantees?
  • Yes
    • If yes, have you done a threat model and had a security review?
      • Yes
      • No
  • No
• Does the change require an update in our Aspire docs?
  • [] Yes
    • Link to aspire-docs issue (consider using one of the following templates):
      • New (or update) doc-idea template
      • New breaking-change template
      • New diagnostic template
  • No

[github-actions]

🚀 Dogfood this PR with:

⚠️ WARNING: Do not do this without first carefully reviewing the code of this PR to satisfy yourself it is safe.

curl -fsSL https://raw.githubusercontent.com/dotnet/aspire/main/eng/scripts/get-aspire-cli-pr.sh | bash -s -- 12305

Or

• Run remotely in PowerShell:

iex "& { $(irm https://raw.githubusercontent.com/dotnet/aspire/main/eng/scripts/get-aspire-cli-pr.ps1) } 12305"

[Copilot]

Pull Request Overview

This PR enables automatic scaling for Azure App Service Plans by default to improve performance and avoid cold start issues. The change introduces a new WithAutomaticScaling extension method that allows customers to opt out if needed.

Key changes:

• Automatic scaling is now enabled by default for App Service Plans
• New WithAutomaticScaling(bool) extension method allows disabling the feature
• App Service Plan configuration now includes elasticScaleEnabled, perSiteScaling, and maximumElasticWorkerCount properties
• Dashboard configuration includes scale limit settings to ensure single-instance operation

Reviewed Changes

Copilot reviewed 9 out of 9 changed files in this pull request and generated 4 comments.

Show a summary per file

File	Description
AzureAppServiceEnvironmentExtensions.cs	Adds WithAutomaticScaling extension method and updates App Service Plan configuration logic
AzureAppServiceEnvironmentResource.cs	Adds EnableAutomaticScaling internal property with default value of true
AzureAppServiceEnvironmentUtility.cs	Updates dashboard site configuration to include scale limits
AzureAppServiceTests.cs	Adds test for disabling automatic scaling
*.verified.bicep	Updates snapshot tests to reflect new automatic scaling properties

[Copilot]

The XML documentation is incomplete for a public API. According to Aspire's documentation standards, public APIs require comprehensive documentation including <remarks> and <example> sections. Add a <remarks> section explaining when/why to use this method and an <example> section showing practical usage with code.

[Copilot]

The return value documentation should follow the standard pattern for fluent APIs: "A reference to the <see cref="IResourceBuilder{T}"/> for chaining additional configuration."

[mitchdenny]

@ShilpiRach thanks for the contribution. I'm not sure that we'll take this change but I'm interested in @davidfowl and @maddymontaquila for input.

My issue with the change is really twofold:

1. It opts customers into a higher level of cost by default.
2. Applications are not always by default cluster tolerant.

Whilst we would want applications to be able to scale up, the app first needs to work correctly and its something that developers will need to assess on a case by case basis.

[ShilpiRach]

@mitchdenny - is your main concern about making automatic scaling the default option? If yes, I am fine with making it non-default.

Tagging @btardif to comment on your first comment about higher cost - who might have more data about this.

For the 2nd point, Applications deployed on cloud should usually work with scaling out. But you might be right about existing Aspire customers trying out App Service.

[ShilpiRach]

@mitchdenny - is your main concern about making automatic scaling the default option? If yes, I am fine with making it non-default.

Tagging @btardif to comment on your first comment about higher cost - who might have more data about this.

For the 2nd point, Applications deployed on cloud should usually work with scaling out. But you might be right about existing Aspire customers trying out App Service.

Made this change

[mitchdenny]

Thanks @ShilpiR. Just need to decide if we want to add this to the API surface now. We don't do these scaling options anywhere else.