How to Share Systems Manager Documents Easily?

Hello readers! Suppose that your company operates on 50 AWS accounts and has one well-tuned System Manager document created by the operations team. Then imagine having to manage a different list of shares every time you add another AWS account to your system.

It does not sound like too much to do initially. However, what if you have several hundred or even thousands of accounts?

This is when you need to share Systems Manager documents. Systems Manager allows creating documents that contain descriptions of operational tasks, whereas AWS Resource Access Manager, or AWS RAM, allows you to easily share them with other users from within an AWS Organization or organizational units.

The thing I consider to be a key difference in such a solution appears rather easy to understand. The idea of managing each AWS account separately goes out the window since you can think of your organization's structure and share a document once with all eligible member accounts.

AWS released such RAM-based functionality in 2026 to help with the management of SSM document access.

Share Systems Manager Documents: What Makes It Essential?

Think of an organization with a central cloud operations team. This team uses a proven SSM document for some repetitive procedures.

Without an efficient solution for sharing, it becomes necessary to assign permissions to every single AWS account. Moreover, as the organization grows, somebody has to update those permissions accordingly.

There was an account-based approach in AWS documentation, with up to 1,000 AWS accounts per document limitation. In addition, all the documents were supposed to be located in the same AWS Region where the AWS accounts were used.

Now the new AWS RAM approach allows managing the situation differently.

How to Share Systems Manager Documents?

It is possible to simplify the description of the process as if there were a single central account possessing the SSM document.

Then, the owner of the document shares it with other accounts by creating an AWS RAM resource share with the document assigned to it. The owner can choose either the whole AWS Organization, some organizational unit, or specific accounts as targets.

Step 1. Create the SSM Document

It begins with the owner of the document.

A centralized team creates an SSM document or Automation runbook that would be used for one operational procedure. The team needs to validate the document prior to sharing it, since other accounts might require it for their operational purposes.

Let’s consider the scenario of creating a document called Standard-Patch-Runbook. This document includes all necessary instructions for performing the standard patching procedure.

The central operations account owns this document.

Step 2. Build AWS RAM Resource Share

Subsequently, the owner shares the resource using AWS RAM.

This functions as a bridge between the specific SSM document and those organizational units, or accounts which can use them. 

SSM document is included as a resource to be shared, and the necessary managed permission is chosen. The default managed permission AWS RAM Permission SSM Document is used; however, another managed permission may also be used.

Step 3. Determine Whom to Grant Access to the Document

It is this step that makes the proposed model particularly beneficial for large businesses.

As a principal, you can choose your AWS Organization, a particular OU, or your AWS accounts.

Let us take a company that has OUs like Development, Testing, and Production. Let the operations team want to limit the usage of a runbook to only production accounts. It can share the document with the Production OU without adding all production accounts manually.

And what if the company changes somehow?

With an organization-based sharing model, the access will stay synchronized with the organizational structure.

Step 4. Work with the Shared Document

When access is ready, the consumer account can use a shared SSM document.

It does not require duplicating the document for running. An account can refer to a shared document using its complete ARN.

For instance, the Automation execution can refer to a document ARN from the central account.

There is a great operational benefit in this. The central team manages the document while others can use it based on permissions in a resource share.

Conventional Sharing Vs AWS RAM Sharing

Why Does AWS RAM Facilitate Document Sharing?

The most critical advantage of RAM, in my opinion, is that of eliminating administrative overhead.

Take, for instance, an organization with 300 AWS accounts. This organization has created a runbook that every single account needs to have.

In the absence of RAM, this organization maintains a large list of account IDs since the configuration of the sharing process is based on the accounts.

However, in an organization where this is possible, things work differently.

The organization shares the document with the concerned OU, and thereby, the organizational structure will become the access boundary.

Same Document Can Effectively Support Several Teams

Another benefit of centralized ownership is the reduction of duplicate copies.

Suppose every AWS account has its own copy of the runbook related to domain join. Now, one account team may update its copy while the other team may forget to update its copy. Thus, the organization might end up having several copies of the same operational process.

AWS itself illustrates the point by offering an Active Directory domain-join Automation runbook. In this example, a central team will write the runbook once, share it with the Workloads OU, and allow accounts from it. 

Consequences of Document Updating

Version management deserves some additional considerations.

As noted by AWS, all versions of a shared document are available for access from the accounts. Consumers usually use the default version of the document and can also select a specific version for running.

Both ease of use and certain precautions apply here.

For example, let's say that your central team has published version 4 of the runbook and made it the default version. In this case, consumers running the default version can get the new version.

Thus, it is appropriate to be careful when performing such actions.

Personally, I would not perform an update of a widely used production runbook without prior testing. Even a minor change in a command or parameter will impact a lot of accounts since one shared document is used for an extensive environment.

It looks reasonable to perform testing of the changes before making the new version the default one.

Organizations must track and investigate activity in employees’ AWS accounts to explore changes and attempts. 

A Real-Life Example of Document Sharing

Consider a business organization having a central cloud platform team and application teams.

The platform team creates an SSM Automation document for standard Windows EC2 setup and maintains it centrally from their central AWS account. After that, they create an AWS RAM resource share and include the document in it.

Rather than picking up hundreds of accounts, the team picks the Workloads OU. All the accounts belonging to this OU can now make use of the shared document.

When any new application account is added to this OU, it can also get access to the document without requiring another sharing action.

This example highlights the integration of document sharing and governance through Organization.

On a different note, companies have the option to make the best use of Amazon CloudWatch Logs in order to boost their operational visibility. 

What Sharing Does Not Share?

One thing deserves particular consideration here.

Sharing an SSM document does not mean sharing all the resources required by the document.

For instance, there can be an Automation runbook that uses an AWS Secrets Manager secret, an IAM role, or any other resource. It requires permissions and the resources for the account that consumes it.

AWS domain-join example demonstrates the difference clearly. While sharing a runbook does not mean sharing secrets from Secrets Manager, each member account should have a means of accessing those secrets and resources.

This is important because the shared document describes a workflow but not everything in it.

Security Aspects You Should Not Forget

Firstly, document sharing can make some aspects easier but can also amplify the effect of an incorrectly prepared document.

Commands contained within an SSM document can be used to adjust the settings of instances or make administrative changes. It is recommended to carefully examine any document that is shared and use documents from trusted sources only.

You should avoid storing sensitive data in SSM documents too.

It is essential to remove all sensitive data, like credentials, from any document. Restrictive IAM policies should be applied so that users have only the necessary permissions to access certain documents and perform certain actions.

Companies should be well aware of different cloud security threats to prevent any type of attack.

For organizations that utilize command parameters, AWS recommends environment-variable interpolation for String parameters to avoid the risk of command injection. It would be essential for you to follow the AWS security best practices to reduce security risks and strengthen access controls. 

Do Not Share Abundantly

The principle is quite simple. You should share a document with the smallest group of users possible. 

There might be no need to share your runbook throughout all OUs if only production accounts require it.

Similarly, it is important to apply extra precautions to sharing an SSM document with highly privileged operational actions than a diagnostic one.

AWS RAM makes it easy for organizations to share resources, but this should not replace access control. 

Conclusion

So, how exactly is sharing Systems Manager documents performed?

Well, the principle behind that process is rather simple. One centralized AWS account owns an SSM document, creates an AWS RAM resource share, includes the document, sets proper permissions, and then shares it with either an AWS Organization, an Organization unit, or particular AWS accounts.

The main benefit is the ability to get rid of managing long lists of accounts manually. If you link the process of sharing with the organizational model of AWS, you can utilize your organizational structure for access management purposes.

It may help to automate the process in the case of large-scale AWS environments, avoid duplication, and simplify governance in general. It is still vital for you to properly verify the content of the document, secure confidential data, handle IAM permissions, as well as test the latest document versions before utilization. 

I would recommend that you author your operational workflow once prior to sharing it via AWS RAM, and leverage it through proper AWS accounts. 

FAQs (Frequently Asked Questions)

Q1. What is your understanding of SSM documents?

This is a document that has commands that can be used by AWS Systems Manager in performing tasks on managed resources.

Q2. Is there any way of sharing SSM documents via AWS accounts?

Yes, there is.

Q3. What does SSM document stand for?

SSM Document stands for AWS Systems Manager document.