{"id":7269,"date":"2021-08-27T09:06:05","date_gmt":"2021-08-27T09:06:05","guid":{"rendered":"https:\/\/rax-stg-wp-aws.com\/blogs\/how-rackspace-uses-aws-systems-manager-for-instance-patching-across-multi-cloud-and-hybrid-environments\/"},"modified":"2026-11-03T19:28:22","modified_gmt":"2026-11-03T19:28:22","slug":"how-rackspace-uses-aws-systems-manager-for-instance-patching-across-multi-cloud-and-hybrid-environments","status":"publish","type":"blogs","link":"https:\/\/www.rackspace.com\/en-gb\/blogs\/how-rackspace-uses-aws-systems-manager-for-instance-patching-across-multi-cloud-and-hybrid-environments\/","title":{"rendered":"How Rackspace uses AWS Systems Manager for instance patching across multi-cloud and hybrid environments"},"content":{"rendered":"

Now that cloud technology has become ubiquitous, companies have many options for hosting servers and building out solutions. From the use of multiple cloud providers to bare metal devices to private cloud, or even to on-premises resources. Rackspace Technology<\/strong> engages with customers across a diverse portfolio of providers. The customer\u2019s structure can stem from a business need (for example, an interest in diversifying their cloud presence). Or it might be due to the early stage of their migration to a cloud environment. The customer might be waiting for their on-premises contracts to end. No matter the reason, customers commonly ask the same question: How can we consolidate our patching across multiple cloud platforms and hybrid and on-premises environments? <\/p>\n

In multi-platform situations, managing virtual machines (VMs) across each platform can be tedious and time-consuming. In many cases, administrators must use Secure Shell (SSH) or Remote Desktop Protocol (RDP) to connect to each instance or VM on each platform on a scheduled basis to perform patching, maintenance, or upgrades. Something as minor as applying an update can take hours. These manual processes are also error-prone and can result in accidental misconfiguration. Companies that rely on manual processes can also wind up creating a knowledge gap in which only a select group of employees know how to perform the steps in the process. It works against modern DevOps practices. All of these issues combine to increase risks to a company\u2019s security and operational health.<\/p>\n

Rackspace is an AWS Premier Consulting Partner<\/a> with seven AWS Competencies<\/a>, including  Migration and DevOps. As a member of the AWS Managed Service Provider (MSP) Program<\/a> and AWS Well-Architected Partner Program<\/a>, Rackspace is often tasked with creating solutions to fit the unique and evolving needs of customers. <\/p>\n

In this post, we explain how Rackspace uses AWS Systems Manager<\/a> (SSM) management and patching across multiple platforms to provide support for all hosting strategies. Using Systems Manager reduces the time, effort, and risks commonly associated  with more manual processes.<\/p>\n

Interact, track, and resolve operational issues with AWS Systems Manager <\/strong><\/p>\n

The Systems Manager Agent<\/a> is Amazon software that can be installed and configured on an (Amazon EC2) instance, an on-premises server, or a VM<\/a>. The SSM Agent makes it possible for the Systems Manager to update, manage, and configure the resources that it is installed on. It pulls requests sent to the Systems Manager and then runs them as specified based on the request. When the operation is complete, the SSM Agent sends status and execution information back to Systems Manager<\/a><\/p>\n

\nRackspace uses other Systems Manager features, such as:<\/p>\n

The <a href=””><\/a> is Amazon software that can be installed and configured on an Amazon Elastic Compute Cloud (Amazon EC2)<\/a> instance, an on-premises server, or a VM. The  SSM Agent makes it possible for the Systems Manager to update, manage, and configure the resources that it is installed on. It pulls requests sent to the Systems Manager and then runs them as specified based on the request. When the operation is complete, the SSM Agent sends status and execution information back to the Systems Manager.<\/p>\n

Rackspace uses other Systems Manager features, such as Session Manager<\/a> and Patch Manager<\/a>, to provide remote access and automation for customers without the need for direct network access. For patching automation, Rackspace uses built-in patch management features like patch baselines<\/a> and patch groups<\/a> to control which patches are applied to which instances and maintenance windows<\/a> to control when these changes occur. These Systems Manager features come together to provide a centralized source of data about a customer\u2019s patching experience that can be used to provide customized views and reporting across their entire landscape.<\/p>\n

Rackspace uses other Systems Manager <\/a>features, such as Session Manager<\/a>, Patch Manager<\/a>, patch baselines<\/a>, patch groups<\/a>, and maintenance windows<\/a>, to control when these changes occur. These Systems Manager features come together to provide a centralized source of data about a customer\u2019s patching experience that can be used to provide customized views and reporting across their entire landscape.
\n <\/p>\n

Design considerations<\/strong><\/p>\n

Although the installation, configuration, and activation of the SSM Agent is simple, orchestrating this SSM agent setup process across numerous disparate platforms with varying features raised some interesting design considerations.<\/p>\n

First, to ensure that the SSM Agent activation requests received by Rackspace could be verifiably traced to a customer, Rackspace had to design a method for gathering metadata from each VM during enrollment. They used metadata services from Microsoft Azure and Google Cloud Platform. These services, like the metadata instance metadata service in Amazon EC2,<\/a> provide signed data to a VM that includes the instance ID, project or subscription ID, and so on. During the SSM Agent installation and registration process, that instance data is captured and sent to Rackspace as part of the SSM Agent activation request. The signed information is verified, which allows the request to be traced back to a customer. For VMware, Rackspace developed a similar solution that uses a signed JWT stored in vCenter that is fetched during the installation process.<\/p>\n

Figure 1 below shows the entire architecture<\/p>\n

\"ASM<\/p>\n

Next, Rackspace needed to devise a solution to properly handle managed instances from different customers. One idea was to use a single AWS account to host managed instances for all customers, but this approach raised security and operational concerns. Rackspace decided to partition each customer\u2019s account into a separate AWS account for all Systems Manager resources (known as a systems account). Thus, each Google Cloud Platform, Azure, and VMware account is assigned its own AWS systems account. The account is created transparently, in the background, when a registration event is received. This approach offers more access control, partitioning, and flexibility for each account.  <\/p>\n

Since Rackspace rolled out this capability for VMware private cloud, VMware Cloud on AWS, native AWS customers, and  Google Cloud Platform customers, it has increased operational security and efficiency for customers.<\/p>\n

Consolidated management and patching<\/strong>
\nTo take advantage of consolidated management and patching, sign in to your Rackspace account here<\/a> and navigate to the VM Management portal to enroll. <\/p>\n

\"VM<\/p>\n

If you aren\u2019t already enrolled, you will see the following:<\/p>\n

\"VM<\/p>\n

 
\nChoose the Learn More About VM Management button. Your Rackspace account team will contact you to discuss your patching requirements and the onboarding process. In most cases, you\u2019ll receive a link to a startup script that installs and activates the SSM Agent on VMs. For native EC2 instances, the SSM Agent is already installed. (It is already installed on many AMIs, so no installation script is required.) If you are using a custom AMI that does not have the SSM Agent installed, you will need to install it or build it into your AMI before you enroll in VM Management. <\/p>\n

For more information, including how to install SSM Agent manually, check About SSM Agent<\/a>.<\/p>\n

Rackspace will need to verify or help you configure some networking and operating system requirements for Systems Manager. For more information, see Systems Manager prerequisites<\/a> and Patch Manager prerequisite<\/a>s<\/a>.<\/p>\n

 <\/p>\n

An end-to-end solution powered by AWS Systems Manager  <\/strong><\/p>\n

After you have enrolled in Rackspace VM Management, you can create an instance and register it for patching. For most platforms, you use the startup script and the cloud platform\u2019s native tagging functionality (for example, EC2 tags, Google Cloud Platform VM labels, and Azure VM tags). <\/p>\n

The registration process captures information about the instance and communicates it to Rackspace\u2019s VM Management service. If this is the first registration for the account, the service transparently creates the systems account that will house all SSM-related resources for the linked customer account. After the systems account is set up, the service configures SSM on that account and passes the registration information to the startup script on the VM to finalize the SSM Agent installation. You can now manage the VM for multiple services through SSM. <\/p>\n

Here is the step-by-step process that serves as a demonstration of what happens behind the scenes:<\/strong><\/p>\n

Create an instance and specify the appropriate startup script and tags provided during the enrollment process. This example uses a GCP instance, but there are other options available such as AWS EC2 instances. For GCP, adding the \u201cstartup-script-url\u201d metadata ensures that the SSM install script is executed when the GCP instance boots. In addition, setting the \u201crackspace-addon-patching\u201d label to \u201ctrue\u201d causes Rackspace\u2019s automation to configure patching resources on the AWS systems account. The \u201crackspace-addon-patching-patchgroup\u201d label defines what patch group this VM should be enrolled in, if it is not provided, 
\nthe VM will be enrolled in a default patch group.<\/p>\n

\"ASM<\/p>\n

 Create an instance in Google Cloud Platform<\/strong><\/p>\n

The SSM Agent is installed on the instance and activated in the systems account. The patch group defined in the \u201crackspace-addon-patching-patchgroup\u201d label on the GCP VM is copied over to the Patch Group tag on the managed instance. The Patch Group tag links the  VM to a specific patch baseline that indicates what patches are installed.<\/p>\n

\"ASM<\/p>\n

 SSM Agent<\/strong><\/p>\n

\"Fleet<\/p>\n

 Fleet Manager Pic 6<\/p>\n

\"Pic<\/p>\n

 Managed instance in Systems Manager console <\/p>\n

\nRackspace\u2019s automation sets up Systems Manager options like maintenance windows, targets, inventory, and custom patch baselines on the AWS systems account. By default, custom patch baselines are created for Windows, Ubuntu, Debian, CentOS, Red Hat Enterprise Linux, Oracle Linux, Amazon Linux, and Amazon Linux 2. In addition, default patch groups are created that correspond to the age of patches installed \u2013 \u201cearly\u201d for patches that are 0 or more days old, \u201con-time\u201d for patches that are 7 or more days old, and \u201clate\u201d for patches that are 14 or more days old.<\/p>\n

\"ASM<\/p>\n

Patch baseline associations in the Systems Manager console <\/p>\n

\"Picture<\/p>\n

 Maintenance window in the Systems Manager console<\/p>\n

\"Pic<\/p>\n

 Targets in the Systems Manager console<\/p>\n

\"Picture<\/p>\n

Consolidated view of patching across platforms on Rackspace site <\/p>\n

\"Pic<\/p>\n

Conclusion <\/strong><\/p>\n

Rackspace now offers a solution for you to manage the patching and maintenance of instances across multiple platforms. To learn more about how Rackspace can help you with business challenges related to management and governance, visit the Rackspace VM Management and AWS Systems Manager webpage.
\n <\/p>\n","protected":false},"excerpt":{"rendered":"

How Rackspace uses AWS Systems Manager for instance patching across multi-cloud and hybrid environments<\/p>\n","protected":false},"author":2,"featured_media":7271,"menu_order":0,"comment_status":"open","ping_status":"open","template":"","format":"standard","meta":{"content-type":"","nid":"26351","content_type":"blog","created_by":"10130","authored_on":"2023-12-07T10:06:05+00:00","field_article_industries":"","tag_category":"Technical","field_blog_author_text":"by Rackspace Technology Staff","seo_description":"Features and functions of Oracle Property Manager for property portfolio management. Integration and decision-making processes.\r\n","field_featured_image":"","insights_image":"\/wp-content\/uploads\/2026\/blog_technical_images\/26351-insights_image-aws-technical-blog-1-insights.png","field_partners":"","rxt_platforms":"","product":"Amazon Web Services (AWS)","publisheddate":"2021-08-27T09:06:05","rxt_solutions":"Cloud, Cloud Management & Operations","opengraph_tag":"","x_tag":"","teaser_flag":"Technical Blog","seo_titile":"AWS Systems Manager instance patching | Rackspace","field_topics":"","field_slug":"aws-systems-manager-for-instance-patching","footnotes":""},"categories":[178],"tags":[204],"class_list":["post-7269","blogs","type-blogs","status-publish","format-standard","has-post-thumbnail","hentry","category-blog","tag-technical"],"_links":{"self":[{"href":"https:\/\/www.rackspace.com\/en-gb\/wp-json\/wp\/v2\/blogs\/7269","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.rackspace.com\/en-gb\/wp-json\/wp\/v2\/blogs"}],"about":[{"href":"https:\/\/www.rackspace.com\/en-gb\/wp-json\/wp\/v2\/types\/blogs"}],"author":[{"embeddable":true,"href":"https:\/\/www.rackspace.com\/en-gb\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/www.rackspace.com\/en-gb\/wp-json\/wp\/v2\/comments?post=7269"}],"version-history":[{"count":2,"href":"https:\/\/www.rackspace.com\/en-gb\/wp-json\/wp\/v2\/blogs\/7269\/revisions"}],"predecessor-version":[{"id":9319,"href":"https:\/\/www.rackspace.com\/en-gb\/wp-json\/wp\/v2\/blogs\/7269\/revisions\/9319"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.rackspace.com\/en-gb\/wp-json\/wp\/v2\/media\/7271"}],"wp:attachment":[{"href":"https:\/\/www.rackspace.com\/en-gb\/wp-json\/wp\/v2\/media?parent=7269"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.rackspace.com\/en-gb\/wp-json\/wp\/v2\/categories?post=7269"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.rackspace.com\/en-gb\/wp-json\/wp\/v2\/tags?post=7269"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}