This content originally appeared on DEV Community and was authored by Shuichi
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.
# Permissions
The permission required to share a workload is "wellarchitected:CreateWorkloadShare".
### 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.
This content originally appeared on DEV Community and was authored by Shuichi
Shuichi | Sciencx (2024-09-30T14:23:56+00:00) Sharing an AWS Well-Architected workload. Retrieved from https://www.scien.cx/2024/09/30/sharing-an-aws-well-architected-workload/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.