Summary

Radius needs a durable way to associate output resources that refer to the same physical cloud resource even when they are produced by different recipe drivers.

This came up while fixing #11838. Terraform AWS recipes and AWS Bicep/CloudControl recipes can legitimately produce different Radius output-resource IDs for the same AWS resource:

/planes/aws/aws/accounts/817312594854/regions/us-west-2/providers/AWS.S3/Bucket/shared-radius-817312594854

/planes/aws/aws/accounts/817312594854/regions/global/providers/Terraform.AWS/aws_s3_bucket/shared-radius-817312594854

Those IDs are both valid because they come from different producers:

• AWS Bicep/CloudControl output resources use CloudControl-shaped resource types such as AWS.S3/Bucket.
• Terraform AWS output resources use Terraform-shaped resource types such as Terraform.AWS/aws_s3_bucket.

However, Radius still needs to understand that both output resources may point at the same physical cloud resource.

User Scenario

Two teams use separate Radius environments and share a common S3 bucket.

1. Team 1 has an environment with a Bicep recipe that creates or references the S3 bucket.
2. Team 1 is the first to provision the bucket, so the resource is originally created through the Bicep recipe.
3. Team 2 has a separate environment with a Terraform recipe that references the same existing S3 bucket.
4. When Team 2 tries to delete their Radius resource, Radius should warn that the underlying S3 bucket is also referenced by Team 1's app or environment.

This requires Radius to compare output resources by a producer-independent physical identity, not only by Radius output-resource ID equality.

Proposed Direction

Persist a producer-independent consistentPhysicalId for output resources when the recipe driver can determine one.

For AWS, the first implementation uses the ARN when available:

{
  "additionalProperties": {
    "arn": "arn:aws:s3:::shared-radius-817312594854",
    "consistentPhysicalId": "arn:aws:s3:::shared-radius-817312594854"
  }
}

Then shared-resource detection can compare:

1. additionalProperties.consistentPhysicalId when both output resources have it.
2. The existing output-resource ID equality fallback otherwise.

This lets Radius preserve provider-specific output-resource IDs while still detecting shared ownership across Bicep and Terraform producers.

Open Questions

• Should consistentPhysicalId be standardized across all cloud providers or remain an output-resource convention?
• For AWS resources without ARNs, what producer-independent identifier should be used?
• Should AWS Bicep resources always store ARN when available, including explicit result.resources references to existing resources?
• Should delete warnings surface the matching consistentPhysicalId to help users understand why Radius thinks two resources are shared?

Related

• Terraform recipe fails for AWS resource S3 bucket with empty account in ARN #11838
• Draft implementation: Fix AWS Terraform output resource IDs #11999