Sharing an AWS Well-Architected workload

The Well-Architected Tool provides a feature to share resources.
You can share "Workloads," "Lenses," "Profiles," and "Templates."
You can specify "IAM users," "AWS accounts," "Organizations," or "Organizational Units (OUs)" as the recipients of the share.

This post will examine the behavior and limitations of sharing workloads.
Can you share with a different organization? Can you restrict permissions for sharing? Let's investigate these questions.

How to Share

Management Console

You can share from the Workloads tab by selecting "Create" under the Shares section.

AWS CLI

You can share using the wellarchitected create-workload-share.
API specifications are here.

aws wellarchitected create-workload-share \
--workload-id <value> \
--shared-with <value> \
--permission-type <value>

Share Recipients

Sharing with IAM Users

The shared workload can be accessed, and the invitation is accepted only when the specified user is logged in. The specified user can belong to a different organization from the sharing source.

Sharing via Management Console

Enter the IAM user ARN in the Principal field.

Sharing via AWS CLI

aws wellarchitected create-workload-share  \
--workload-id 0123456789abcdef0123456789abcdef  \
--shared-with arn:aws:iam::123456789012:user/username  \
--permission-type READONLY

Specify the workload-id as the 32-character ID following workload/ in the workload's ARN.

Sharing with an AWS Account

Users with the appropriate permissions in the specified account can accept the invitation and access the shared workload. The specified account can belong to a different organization from the sharing source.

Specifying via Management Console

Enter the 12-digit AWS account ID.

Specifying via AWS CLI

aws wellarchitected create-workload-share  \
--workload-id 0123456789abcdef0123456789abcdef  \
--shared-with 123456789012  \
--permission-type READONLY

Sharing with an Organization

You can share within the Organization to which the sharing source belongs.
No invitation approval is required. Once shared, workloads can be accessed from accounts within the Organization.

Specifying via Management Console

The ID of the Organization to which the sharing source belongs is pre-filled and cannot be changed.

Specifying via AWS CLI

aws wellarchitected create-workload-share  \
--workload-id 0123456789abcdef0123456789abcdef  \
--shared-with o-123456789a  \
--permission-type READONLY

Suppose you specify an Organization ID other than the one you belong to. In that case, the operation will fail with the error message: "The shared with principal can only be shared to an organization that you belong to."

Sharing with an Organizational Unit (OU)

You can share with an Organizational Unit (OU) within the Organization to which the sharing source belongs.
No invitation approval is required. Once shared, workloads can be accessed from accounts within the specified OU.

Specifying via Management Console

Enter the ID of the OU.

If you enter the ID of an OU that belongs to a different Organization, the share will fail with the message: "Failed: Unable to fetch organization details."

Specifying via AWS CLI

aws wellarchitected create-workload-share  \
--workload-id 0123456789abcdef0123456789abcdef  \
--shared-with ou-1234-abcdefgh  \
--permission-type READONLY

Permissions

The permission required to share a workload is "wellarchitected:CreateWorkloadShare".

Workloads may contain sensitive information such as the workload name, description, and review notes. In certain scenarios, you may not want to accidentally share this information outside the organization, or even within the organization to unintended OUs or accounts.

Can you restrict the recipients of the share?

No, you cannot. The Principal refers to the requester, so conditions such as aws:PrincipalOrgID or aws:PrincipalOrgPaths cannot restrict recipients. To implement such a control, you may need to create custom rules in AWS Config to detect these settings.

Use Case

Establishing mechanisms, standardization, culture, and rules at the organizational level, not just for individual projects, is often necessary to adhere to AWS Well-Architected best practices. By viewing, aggregating, and analyzing workload review reports across the Organization, you can identify areas where standardization and mechanisms are lacking and weaknesses in the Organization.