Using Run Command for Adhoc Operations - TriNimbus

Using Run Command for Adhoc Operations

One of my favorite AWS Services that I don’t hear much discussion about over the last year is EC2 Run Command (part of the Amazon EC2 Systems Manager suite). This is a very versatile tool that has gotten incremental features added over the last year to make it a compelling solution to help manage virtual machines. Run Command provides a secure way to remotely execute tasks on EC2 Instances, and even machines located on-premise or running in other public clouds. Commands are quickly executed in parallel and have a fast response time. Results are returned to a central location for easy viewing.

Command execution is supported on both Windows and Linux platforms.  Agents check in to a central queue to find out if any execution directives exist. Connections to the queue are made over outbound HTTPS connections, so no inbound firewall exceptions are required.

Commands can be restrictive or open based on your designs. They are built using the Simple System Manager (SSM) Document  format, and can leverage built in plugins for specific tasks, including utilizing the full capabilities of Linux shell scripts and Windows PowerShell scripts. Commands can be access controlled, audited, and shared with other AWS Accounts.

By leveraging Run Command operational support becomes easy to do without having to log into an operating system with a user credential.  You can remotely do things like installing updates, restarting services and checking the state of a system.

As an example, let’s run a Command using the AWS Console.

First, in order to test Run Command on a Windows EC2 instance target, it needs to be setup as follows:

  • Be in the same region as the Command is defined
  • Have an IAM Instance Profile linked to a IAM Role granting permissions to use Run Command. An example policy can be found here, or you can use the AmazonEC2RoleforSSM managed policy for testing.
  • The instance must have the EC2 Config service enabled/running and with a version that supports using SSM. Most general release Windows instances less than a year old should work.
  • The instance needs to communicate with the AWS Public API endpoints either directly, or via NAT, using a HTTPS connection.  Confirm routing rules, outbound rules on Security Groups and NACL entries (inbound & outbound) will allow this.

To test against a Linux system, you will also need to have the SSM Agent installed instead of the EC2 Config service. For directions on how to install the SSM agent on setup of a new instance click here.

Once you have a testing instance ready, log into the Console at

Note: The region should be changed to the region you want to execute commands in. Regional availability information for this service can be found here.

This will load the EC2 > Commands page in the Console. If you have not previously visited this page you will see a page like the following, click Run a Command:

Click the Run a command button:

To test against Windows instances, use AWS-RunPowerShellScript. For Linux instances, use AWS-RunShellScript.

Next select the instance(s) you want to run the command against.

Note: If your instance(s) are missing, validate the criteria mentioned above and make sure you choosen the correct command.

With our example, we’re going to simply check the free space on the root volume. Update the Commands textbox based on the operating system.



The other options on the page aren’t required for now, you can simply click the Run button at the bottom of the page.

A result page will load with the Command ID, click the link and go to the Output tab in the details section to use the View Output link to see the result.


For Linux systems, a result like this should return:

For Windows systems, a result like this should return:

As you can see this is a great way to interact with instances quickly. Consider using the same method to restart a Web Server application on 20 Instances, it would be done the same way and would execute in parallel to give a much faster experience than remotely connecting to all 20 instances.  Additionally Run Command can also be executed from scripts rather than using the console, so you can add even more efficiency for common repeatable tasks.

Finally I want to point out what you don’t see in this blog post. Whenever I first introduce people to this service, the interest turns into excitement when they realize the result is there before they click the View Output link. I strongly urge you to try it out, not just read about it, to get a better idea of how powerful this really is.

In upcoming posts I will share more details on ways to use this service. If you are trying to increase your efficiency and have specific needs not covered by these blog posts, TriNimbus can engage with you to help develop your toolkit for efficiently managing your infrastructure.