Consider supporting subscription IDs in existing resource scope

[captainsafia]

Is there an existing issue for this?

• I have searched the existing issues

Is your feature request related to a problem? Please describe the problem.

The existing resource support that we added in 9.1 allows referencing existing resources that have been provisioned in the same or a different resource group. Although it is possible to reference existing resources in Bicep in different subscriptions, we don't support this.

Describe the solution you'd like

Expose overloads and additional APIs that allow setting the subscription ID on an existing resource. This would consist of:

• Updates to the ExistingAzureResourceAnnotation to reference different subscription IDs
• Update to the manifest schema to encode the subscription ID referenced for consumption by deployment tools
• Updates to the local Bicep provisioner to support referencing resources in different subscriptions
• Updates to the existing extension methods and configure infrastructure calls to encode the subscription ID

Additional context

No response

[mafiheron]

+1 in order for us to use aspire properly and follow recommendations set in azure cloud adoption framework of ideally separating environments in different environments(https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/ready/landing-zone/design-area/management-application-environments#environments-subscriptions-and-management-groups) we need this functionality.

Also when using e.g. a shared azure container registry in an organization in order to take full advantage of namespaces this is a required feature.

[tebeco]

Agreed, this would indeed allow for teams to be able to reproduce with specific sets of data that are present in different location / sub / teams.

Having a global static config isn't generally a good sign and is close to have a public static string mutable in code, never fun to deal with.