Lab 3: Operations as Code

© 2026 Amazon Web Services, Inc. or its affiliates. All rights reserved. This work may not be reproduced or redistributed, in whole or in part, without prior written permission from Amazon Web Services, Inc. Commercial copying, lending, or selling is prohibited. All trademarks are the property of their owners.

Note: Do not include any personal, identifying, or confidential information into the lab environment. Information entered may be visible to others.

Corrections, feedback, or other questions? Contact us at AWS Training and Certification.

Lab overview

You are asked to create a process for deploying software configuration changes to multiple servers with a single command. To do this, you have decided to employ AWS Systems Manager command document. This command document will need to target a specific resource group. After setting up and deploying this new command document, you need to verify the document’s efficacy, confirm that the application is running, that the changes are in effect. After deploying the software change across your servers, you need to make a configuration change to the Amazon EC2 instance infrastructure itself. Finally, you should locate and review the log streams which were generated by running AWS Systems Manager command documents.

You create AWS Systems Manager command and automation documents to deploy an application, update file contents, and change infrastructure configurations. AWS Systems Manager provides a unified user interface to streamline the review of operational data from multiple AWS services and provides automation of operational and consistency tasks in an AWS environment. AWS Systems Manager documents bypass the need for logging into individual Amazon Elastic Compute Cloud (Amazon EC2) instances to perform repetitive actions. In addition to using AWS Systems Manager documents, students also create an Amazon CloudWatch log group for monitoring the outputs of their documents, ensuring that the changes made in their environment are fully auditable.

Objectives

By the end of this lab, you should be able to do the following:

Create a CloudWatch Log group for logging AWS Systems Manager outputs.
Create and run a command document with the AWS Systems Manager service.
Locate and run an automation document with the AWS Systems Manager service.
Audit the changes made in your environment through log stream inspection.

Technical knowledge prerequisites

This lab requires the following prerequisites:

Access to a computer with internet and Microsoft Windows, macOS X, or Linux.
An internet browser, such as Google Chrome, Mozilla Firefox, or Microsoft Internet Explorer 11 (previous versions of Internet Explorer are not supported).
Basic knowledge of Amazon EC2.

Icon key

Various icons are used throughout this lab to call attention to different types of instructions and notes. The following list explains the purpose for each icon:

Caution: Information of special interest or importance (not so important to cause problems with the equipment or data if you miss it, but it could result in the need to repeat certain steps).
Consider: A moment to pause to consider how you might apply a concept in your own environment or to initiate a conversation about the topic at hand.
Copy edit: A time when copying a command, script, or other text to a text editor (to edit specific variables within it) might be easier than editing directly in the command line or terminal.
File contents: A code block that displays the contents of a script or file you need to run that has been pre-created for you.
Note: A hint, tip, or important guidance.
Task complete: A conclusion or summary point in the lab.
Warning: An action that is irreversible and could potentially impact the failure of a command or process (including warnings about configurations that cannot be changed after they are made).

Start lab

To launch the lab, at the top of the page, choose Start Lab.

Caution: You must wait for the provisioned AWS services to be ready before you can continue.
To open the lab, choose Open Console .

You are automatically signed in to the AWS Management Console in a new web browser tab.

Warning: Do not change the Region unless instructed.

Error: You must first sign out

Log out error

If you see the message, You must first log out before logging into a different AWS account:

Choose the click here link.
Close your Amazon Web Services Sign In web browser tab and return to your initial lab page.
Choose Open Console again.

Error: Choosing Start Lab has no effect

In some cases, certain pop-up or script blocker web browser extensions might prevent the Start Lab button from working as intended. If you experience an issue starting the lab:

Add the lab domain name to your pop-up or script blocker’s allow list or turn it off.
Refresh the page and try again.

Lab environment

When you start the lab, the environment contains the resources shown in the following diagram:

The architecture diagram of the lab 3 environment.

Image description: The preceding diagram depicts the use of AWS Systems Manager service to enact operational changes on Amazon EC2 instances in a Resource Group. Then, you use the AWS Systems Manager service to enact a configuration change to a single Amazon EC2 instance in the environment. Finally, you review Amazon CloudWatch logs which were generated from the tasks completed by AWS Systems Manager actions.

Task 1: Create an Amazon CloudWatch log group for logging AWS Systems Manager command document output

In this task, you setup a unique CloudWatch log group. This log group is where the output generated by AWS Systems Manager command documents is sent.

When you send a command using Run Command, you can specify where you want to send the logs generated from command document to be stored. By default, Systems Manager returns only the first 48,000 characters of the command output to the console. If you want to view the full details of the command output, you can specify an Amazon Simple Storage Service (Amazon S3) bucket, or you can specify Amazon CloudWatch Logs. If you specify CloudWatch Logs, Run Command periodically sends all command output and error logs to CloudWatch Logs. You can monitor the logs in near real-time, create CloudWatch dashboards, search for specific phrases, values, or patterns, and create CloudWatch alarms based the search query.

Note: Additionally, the AWS Systems Manager Agent (SSM Agent) writes information about executions, commands, scheduled actions, errors, and health status to log files on each instance. You can view log files by manually connecting to an instance or you can automatically send logs to Amazon CloudWatch Logs. The SSM Agent log files are located in the following directory for Linux OS

/var/log/amazon/ssm/

or in

%PROGRAMDATA%\Amazon\SSM\Logs\

for Windows OS. This lab is not scoped to cover setting up pushing SSM Agent log files from Amazon EC2 instances to CloudWatch Logs.

Setting up Systems Manager to work with Amazon EC2 instances is covered in Lab 1. In this lab no additional configuration is needed at the instance level in order to log the run commands sent from Systems Manager to the Amazon EC2 instance. This is because AWS Systems Manager already manages the WebServer instances. The instances are using the AWS managed policies AmazonSSMManagedInstanceCore and CloudWatchAgentServerPolicy in the associated AWS Identity and Access Management (IAM) role.

Note: If you plan to create custom IAM roles and policies in your own AWS environment then the following policy actions need to be included for logging the outputs from command documents.

{
   "Effect":"Allow",
   "Action":[
      "logs:CreateLogGroup",
      "logs:CreateLogStream",
      "logs:DescribeLogGroups",
      "logs:DescribeLogStreams",
      "logs:PutLogEvents"
   ],
   "Resource":"arn:aws:logs:::log-group:/aws/ssm/*"
},

At the top of the AWS Management Console, in the search bar, search for and choose
CloudWatch
.
Locate the CloudWatch navigation menu on the left of the console. If necessary, expand the service navigation menu by choosing the menu.
In the left navigation pane, under Logs, choose Log Management.
Choose Create log group.

The Create log group page is displayed.
Enter
WebServerSSMAgentLogGroup
for Log group name in the Log group details section.
Choose Create.

The CloudWatch Logs page is displayed with the WebServerSSMAgentLogGroup.

Task complete: A new CloudWatch Log Group has been created.

Task 2: Create and run AWS Systems Manager command documents

In this task, you use the AWS Systems Manager service to complete actions defined in command documents, targeted at specific resource groups in the AWS environment. You create a command document to install a software package on all Amazon EC2 instances in a specific resource group. Next, you create another command document to change the contents of a file used by the software on all Amazon EC2 instances in the targeted resource group.

Task 2.1: Creating a Systems Manager command document to install applications

Create a command document for the purpose of installing a new application on all Amazon EC2 instances in a resource group.

This command document, written for the Amazon Linux 2 OS, updates all installed packages that are currently registered with the package manager utility YUM. After that, the Apache webserver package ‘httpd’ is installed. Finally, the new webserver service is configured to be in the on state for the current OS run level. This run level configuration is added to the /etc/rc[0-6].d file hierarchy so that the run level configuration is preserved through reboots.

At the top of the AWS Management Console, in the search bar, search for and choose
Systems Manager
.
In the left navigation pane, under Change Management Tools, choose Documents.
Choose the Create document drop-down.
Select Command or Session from the drop-down menu.

The Create document page is displayed.
In the Document details section, for Name, enter
myInstallApache
.
In the Content section, choose YAML.

Copy edit: Paste the following code into the code editor, overwriting the existing sample that is there:

schemaVersion: '2.2'
mainSteps:
- action: 'aws:runShellScript'
  name: 'configureApache'
  inputs:
    runCommand:
    - 'sudo yum update -y'
    - 'sudo yum install -y httpd'
    - 'sudo service httpd start'
    - 'sudo chkconfig httpd on'
    - 'sudo chkconfig httpd --add'

Warning: If you receive the error “InvalidDocumentContent: null” check the YAML syntax, and try again.

Choose Create document.

The Documents page is displayed, and the new command document is successfully created.

Task complete: You have created a command document to install and activate Apache web server.

Task 2.2: Running a Systems Manager command document

In this task you run a command document to deploy an application to a resource group of Amazon EC2 instances.

On the AWS Systems Manager Documents page, choose the Owned by me tab.
Choose the link for the myInstallApache command document. Do not select the radio switch next to the document.
Choose Run command.

The Run a command page is displayed.
Locate the Target selection section of the page.
Select Choose a resource group.

A resource group named ProductionWebServers is automatically selected in the Resource group field. Resource group creation was covered in Lab 2. For this lab, a resource group is provided to you and consists of the environment’s WebServer resources. If you have multiple resource groups already existing in your personal AWS environment, then this is the place to configure the correct target for the command document.

Note: The other two options for selecting targets of a command document, ‘Specify instance tags’ and ‘Choose instances manually’ are both viable options. However, imagine a scenario where you have an infrastructure with hundreds of web server Amazon EC2 instances mixed among other Amazon EC2 instance types meant for different workloads. The manual work of choosing all the correct Amazon EC2 instances is no longer efficient, especially when more than one command document needs to be run on those targets in a day. Also imagine a second scenario, where the infrastructure you are dealing with is a mix of on-premise and cloud resources, as well as a mix of environment types, and the resources do not have uniform tag values. In that scenario, the ‘specify instance tags’ option is no longer a good choice for efficiently selecting targets of the command document. For these types of scenarios, and others, setting up appropriate resource groups ahead of time makes your work more efficient.
Locate the Output Options section.
Clear the checkbox next to Enable an S3 bucket.
Select Enable CloudWatch logs.
Enter
WebServerSSMAgentLogGroup
into the box for Log group name - optional.
Choose Run.

The Run Command summary page is displayed.
Refresh the page periodically until the Status column displays Success for all the Amazon EC2 instances in the resource group.

Task complete: You have run a command document and installed Apache web server on the WebServer Amazon EC2 instances.

Task 2.3 Manually confirm the command document ran by verifying the installation of the Apache web server on one of the Amazon EC2 instances

Manually verify the Apache web server is running by connecting to a webpage hosted on the Amazon EC2 instance.

To the left of these lab instructions are the public Domain Name System (DNS) values for the WebServer Amazon EC2 instances.

Copy the public DNS value for one of the WebServer instances.
Paste the DNS value in a new web browser tab.

Warning: Do not include https:// prefix in the DNS name when testing the web server. If you include the https:// prefix in the DNS name, you will receive an error and not be able to view the page. This is because Secure Socket Layer (SSL) certificates are not present on your Amazon EC2 instances. If your browser automatically adds https://, change it to http://.

If the Apache web server test page is displayed, you have verified the command run by Systems Manager was successful. You may close the Apache web server test page.

Task complete: You created an Apache web server using Amazon EC2 instances, resource groups, command documents, and Systems Manager.

Task 2.4: Creating a Systems Manager command document to update content on WebServer Amazon EC2 instances

Note: This task is similar to a previous task named Running a Systems Manager command document where a new application was installed to the Amazon EC2 instances in the resource group named ProductionWebServers. However, in this task the use case is to utilize command documents to make content updates or configuration changes to files stored on the Amazon EC2 instances in a resource group.

Return to the AWS Systems Manager console.
In the left navigation pane, under Change Management Tools, choose Documents.
Choose the Create document drop-down.
Select Command or Session from the drop-down menu.

The Create document page is displayed.
In the Document details section, for Name, enter
myIndexContentUpdate
.
In the Content section, choose YAML.

Copy edit: Paste the following code into the code editor, overwriting the existing sample that is there:

---
schemaVersion: '2.2'
mainSteps:
- action: 'aws:runShellScript'
  name: 'configureApache'
  inputs:
    runCommand:
    - 'sudo bash -c "echo Hello World from $(hostname -f) > /var/www/html/index.html"'

Warning: If you receive the error “InvalidDocumentContent: null” check the YAML syntax, and try again.

Choose Create document.

The Documents page is displayed and the new document is successfully created.

Task complete: You have created a command document to update specific file contents.

Task 2.5: Running a Systems Manager command document

In this task you run a command document to update a file on a resource group of Amazon EC2 instances.

On the AWS Systems Manager Documents page, choose the Owned by me tab.
Choose the link for the myIndexContentUpdate command document. Do not select the radio switch next to the document.
Choose Run command.

The Run a command page is displayed.
In the Target selection section, select Choose a resource group.

A resource group named ProductionWebServers is automatically selected in the Resource group field.
In the Output Options section, clear the checkbox next to Enable an S3 bucket.
Select Enable CloudWatch logs.
Enter
WebServerSSMAgentLogGroup
into the box for Log group name - optional.
Choose Run.

The Run Command summary page is displayed.
Refresh the page periodically until the Status column displays Success for all the Amazon EC2 instances in the resource group.

Task complete: You have updated the contents of a file for all Amazon EC2 instances in a resource group using command documents and the Systems Manager service.

Task 2.6 Manually confirm the command document ran by verifying the updated content to the Apache web server on one of the Amazon EC2 instances

In this task you manually verify the updated Apache web server content is displayed by connecting to the webpage hosted on a WebServer Amazon EC2 instance.

To the left of these lab instructions are the public DNS values for the WebServer Amazon EC2 instances.

Copy the public DNS value for one of the WebServer instances.
Paste the DNS value in a new browser tab.

Warning: Do not include https:// prefix in the DNS name when testing the web server. If you include the https:// prefix in the DNS name, you will receive an error and not be able to view the page. This is because SSL certificates are not present on your EC2 instances. If your browser automatically adds https://, change it to http://.

The page now displays the new content instead of the default Apache web server test page. You may close the Apache web server page.

Task complete: You have used command documents in Systems Manager to deploy a change to the contents of the index.html file on all the Amazon EC2 instances in the ProductionWebServers resource group and you have manually verified the command document ran successfully.

Task 3: Use AWS Systems Manager automation to deploy a configuration change in your AWS environment

In this task, you use the automation feature of AWS Systems Manager to change the configuration of an Amazon EC2 instance. The development team has recently completed a performance review of the applications. Based on the findings, the company has asked you to take the action to increase the size of a currently deployed AppServer Amazon EC2 instance, to better match the WebServer workloads. Your company has not yet implemented strict maintenance windows for this particular application, so you are free to make the changes without waiting for a particular time frame.

Task 3.1: Automation documents

Search the AWS automation documents library for an appropriate automation document to resize an Amazon EC2 instance and run it.

Return to the Systems Manager console.
In the left navigation pane, under Change Management Tools, choose Automation.
Choose Execute runbook.

The Choose runbook page is displayed.
Choose the Owned by Amazon tab.
Enter
AWS-ResizeInstance
into Automation runbook search and press the Enter key.
Choose the link for the runbook titled AWS-ResizeInstance.
Choose the Content tab to review the YAML code that makes up this document.

Note: The AWS-ResizeInstance document is fairly straight forward to follow, but automation documents can be much more complex and run Python or PowerShell scripting languages, call other AWS API’s, and make conditional choices in the automation steps. If you are curious what an automation document that makes use of a scripting language is like, then examine another document named
AWS-RunPacker
which uses the HashiCorp Packer tool to validate, fix, or build packer templates that are used to create machine images. Can you find other automation documents that interest you?
Choose Execute automation.

The Execute automation runbook page is displayed.
Choose Simple execution.
In the Input parameters section, ensure that Show interactive instance picker is selected.
Select the instance named AppServer1.
For Instance Type, enter
t2.small
in InstanceType.

Consider: Because the current instance size of AppServer1 does not match the desired instance size configured in the automation document, the assertInstanceType step of the automation document fails. This step failure causes the other steps in the automation document to proceed and the automation reaches an overall successful execution state. Once the command document has changed the instance size, if you ran this same automation document a second time with the same settings, the assertInstanceType step would succeed and the subsequent steps defined in the automation document would never start. The overall automation process again reaches an overall successful execution state. This is an example of the conditional steps in action, as defined in the automation document.
Choose Execute.

The automation document begins implementing the actions defined in the command document. A banner is displayed at the top of the page with text similar to, ‘Execution has been initiated’

The output from each step in the automation document is displayed in the Executed steps section.

The automation document has finished running once the Overall status has a status of Success in the Execution status section.
Wait for the automation document to finish.
Choose the Step ID link for the Failed step named assertInstanceType from the Executed steps section.
Review the failure message.

Notice that the reason for step failure is that the instance size value returned by the API call to Amazon EC2 does not match the desired value in the command document. You specified the desired value in the input parameter section of this command document prior to running it.

Task complete: You ran an automation document and made a configuration change to an EC2 resource in your AWS environment.

Task 3.2: Verify the configuration change to the Amazon EC2 instance named AppServer1

Manually verify that the automation document made the correct change to the AppServer1 Amazon EC2 instance.

At the top of the AWS Management Console, in the search bar, search for and choose
EC2
.
In the left navigation pane, under Instances, choose Instances.
Locate and select the instance named
AppServer1
.
On the Details tab, verify the value for Instance type is
t2.small
.

Task complete: You have verified that the automation document correctly resized and restarted the AppServer1 Amazon EC2 instance.

Task 4: Check the command document logs in the CloudWatch Log group

In this task, you review entries made by Systems Manager in a log group you created.

At the top of the AWS Management Console, in the search bar, search for and choose
CloudWatch
.
In the left navigation pane, under Logs, choose Log Management.
Select the link for the log group named WebServerSSMAgentLogGroup.

The details page of the WebServerSSMAgentLogGroup is displayed. The logs in this log group were generated when you ran SSM documents in lab tasks.

There are two types of logs collected from command documents standard output and standard error. Depending on the type of log stream you choose to read, different information can be obtained.
Select one of the log streams and review the time stamped entries in the log. What do the entries in this log stream tell you?

Task complete: You used CloudWatch log groups to locate and review log streams generated from command documents you ran in Systems Manager.

Conclusion

You have successfully done the following:

Created a CloudWatch Log group for logging AWS Systems Manager outputs.
Created and run a command document with the AWS Systems Manager service.
Located and run an automation document with the AWS Systems Manager service.
Audited the changes made in your environment through log stream inspection.

End lab

Follow these steps to close the console and end your lab.

Return to the AWS Management Console.
At the upper-right corner of the page, choose AWSLabsUser, and then choose Sign out.
Choose End Lab and then confirm that you want to end your lab.

For more information about AWS Training and Certification, see https://aws.amazon.com/training/.

Your feedback is welcome and appreciated.
If you would like to share any feedback, suggestions, or corrections, please provide the details in our AWS Training and Certification Contact Form.