One Fleet, Multiple Clouds: Centralized VM Management with AWS Systems Manager

Unified Visibility in a Multi-Cloud World

Organizations increasingly operate in multi-cloud environments, taking advantage of best-in-class services from different cloud providers to meet specific business requirements. While this approach offers flexibility and agility, it also introduces operational complexity, especially when it comes to managing infrastructure across platforms. One of the more challenging aspects of running a multi-cloud architecture is managing the lifecycle of virtual machines in different clouds. Tasks like patch management, regular application updates, inventory collection, remote command execution and compliance reporting often need to be duplicated across management tools specific to each cloud provider. This leads to fragmentation of processes and increased operational overhead. 

‍

AWS Systems Manager (SSM) offers a powerful solution to this challenge. Traditionally used for managing AWS resources, Systems Manager can also be extended to non-AWS environments through a feature known as Hybrid Activations. This capability allows administrators to register on-premises or third-party cloud instances as managed nodes in AWS. Once registered, these instances can be managed using the same automation, patching and compliance workflows already established for AWS EC2 instances.

‍

In this post, we explore how to integrate Google Cloud Platform (GCP) virtual machines into your AWS Systems Manager fleet. Through an architecture that integrates AWS API Gateway and AWS Lambda, we demonstrate how GCP VMs can request and apply activation codes at boot time, enabling seamless registration into the AWS Systems Manager ecosystem.

‍

The Operational Case for Centralized Management

While a multi-cloud strategy offers organizations resilience and vendor flexibility, it also introduces significant challenges that are not immediately obvious, especially as the number of managed virtual machines grows across platforms like AWS, Google Cloud Platform (GCP) and other cloud providers. One of the most complex of these challenges is operational fragmentation: the division of tooling, policies and workflows that occurs when infrastructure is distributed across cloud providers with different native management stacks. 

‍

Without a centralized approach, teams often end up managing each cloud’s virtual machines in isolation, using platform-specific tools such as AWS Systems Manager for EC2 and GCP’s OS Config. While each tool might be effective in its own context, the separation between platforms means that teams must maintain separate workflows for patch management, application updates, state tracking and even basic troubleshooting tasks like remote shell access. Over time, this separation creates technical debt and operational drift - a scenario where the actual state of systems begins to deviate from defined configurations and expectations, simply because enforcing consistency becomes too hard to manage and maintain. This drift doesn’t just affect applying best practices - it directly impacts security and compliance. When systems in different clouds are patched on different schedules or when state and inventory data is collected differently, it becomes difficult to produce consistent audit and compliance reports. For example, a vulnerability patch that’s applied to AWS-based instances within 24 hours may sit unapproved in GCP for weeks simply because the processes are not consistent. Depending on the industry and the regulation standards, that discrepancy could be the difference between passing and failing critical compliance audits. From a scaling perspective, centralized management also reduces the per-instance overhead of administration. With Systems Manager, administrators can define tagging strategies, patch baselines, software updates and state configuration documents once, then apply them to entire fleets regardless of where those virtual machines live. As new environments are rolled out, whether for testing, development or entirely new projects, there is no need to replicate and maintain complex, cloud-specific management pipelines. Additionally, Systems Manager natively supports multi-account environments, making it easier to manage infrastructure across organizational units and cloud accounts from a centralized operations hub [1].

‍

Centralized VM management is not just about convenience, it’s a strategic choice. It enables better governance, tighter security, faster recovery and overall more efficient operations. AWS Systems Manager, when extended with hybrid activations, becomes a unified management interface for all your infrastructure, allowing organizations to scale their multi-cloud environments without scaling their complexity.

‍

Building the Cross-Cloud Bridge: Architecture Overview

To extend AWS Systems Manager to manage GCP virtual machines, we can architect a simple, secure workflow using Amazon API Gateway and AWS Lambda. The core idea is to expose an internal API endpoint that GCP VMs can contact at startup to retrieve the necessary activation credentials for Systems Manager.

‍

Figure 1. “Hybrid cloud fleet management architecture”

‍

First, it is necessary to create a Lambda function in AWS that interfaces with Systems Manager’s CreateActivation API. This API generates an activation code and activation ID, which are required for registering a non-AWS machine with Systems Manager. The credentials are temporary and can be scoped to specific use cases, such as registering a VM during its bootstrapping phase [2]. Next, this Lambda function is exposed through an Amazon API Gateway REST API. The API acts as a bridge, securely handling requests from external sources - in this case, new VMs in GCP. When a GCP virtual machine starts, it runs a startup script [3] that performs the following steps:

‍

1. Retrieves identity token from Compute Engine’s Metadata Server to prove the instance’s identity.

2. Sends a request to the API Gateway endpoint, including identifying information through the identity token.

3. Receives an activation code and activation ID in the response.

4. Downloads and installs the Systems Manager agent if it’s not already present (stored in a public S3 bucket).

5. Uses these credentials to register with AWS Systems Manager using the amazon-ssm-agent.

6. Starts the SSM agent service on the VM.

For example, the following script executes the steps above to install the ssm-agent on an Ubuntu Server in GCP and register it into the SSM fleet [4]: 

#!/bin/bash

# Define metadata

REGION="eu-west-1"

API-ID="xxxxxxxxxx"

ACTIVATION_ENDPOINT="https://${API-ID}.execute-api.${REGION}.amazonaws.com/activation"

‍

# Obtain identity token from Metadata server

IDENTITY_TOKEN=$(curl -s -H "Metadata-Flavor: Google" \

"http://metadata/computeMetadata/v1/instance/service-accounts/default/identity?audience=${ACTIVATION_ENDPOINT}")

‍

# Obtain activation keys

CREDENTIALS=$(curl -s -H "Authorization: Bearer ${IDENTITY_TOKEN}" "${ACTIVATION_ENDPOINT}")

ACTIVATION_CODE=$(echo $CREDENTIALS | jq -r '.ActivationCode') 

ACTIVATION_ID=$(echo $CREDENTIALS | jq -r '.ActivationId') 

# Install the SSM agent

mkdir /tmp/ssm

sudo yum erase amazon-ssm-agent --assumeyes

‍

curl https://amazon-ssm-${REGION}.s3.${REGION}.amazonaws.com/latest/linux_amd64/ssm-setup-cli -o /tmp/ssm/ssm-setup-cli

sudo chmod +x /tmp/ssm/ssm-setup-cli

# Register the instance into SSM through the hybrid activation

sudo /tmp/ssm/ssm-setup-cli -register -activation-code $ACTIVATION_CODE -activation-id $ACTIVATION_ID -region ${REGION}

‍

Once registered, the GCP VM appears in the AWS Systems Manager console as a managed instance, just like any EC2 instance. It can now participate in patching workflows, automation runbooks and compliance reports defined in AWS.

‍

Ensuring Secure Fleet Registrations Across Clouds

As with any cross-cloud integration, security is crucial. Opening an API Gateway endpoint to external traffic requires careful design to prevent unauthorized access. If this endpoint was publicly accessible without safeguards, anyone with the URL could potentially register instances in your Systems Manager environment. Therefore, several mechanisms should be employed to secure this architecture. For example, authenticating requests from GCP VMs using service account identity tokens. GCP allows VMs to obtain identity tokens that are signed by Google and can be validated by the AWS Lambda function whenever a request is made to the API Gateway. Once validated, the Lambda function can access the payload of the identity token which includes the “instance_id”, “project_id”, and “zone” values. Combined, these values are globally unique and could be used to confirm that the API Gateway is receiving requests from the correct instance in the desired project [5]. Alternatively, a scoped API key could be injected into VM metadata or encrypted parameter storage, although this method is more involved and less reliable than the signed identity tokens.

‍

When it comes to the Lambda function itself, ensure that it is only allowed to call CreateActivation API under tightly scoped IAM permissions. The IAM role assumed by Lambda should only permit activation creation within defined parameters - such as instance ids, project names,  default tags, etc.

‍

It is important to know that each hybrid activation is associated with an IAM Role, different than the Lambda’s execution role, which is assumed by the SSM service on behalf of the managed instances. This role is critical - it defines what the registered external instance can do once it joins your AWS fleet. It is best practice to define a least-privilege IAM role that permits only the actions necessary for that instance - such as executing automation documents, applying patches, installing software updates, tracking state, etc. This role is assumed by the SSM agent on the registered instance, making it a critical component of your security boundary.

‍

By combining the techniques of identity validation and scoped IAM roles, you can confidently register and manage external VMs in the SSM fleet without opening unwanted security and access holes in your infrastructure.

‍

Conclusion

As multi-cloud strategies become the norm in certain businesses, the need for consistent and centralized operations workflow grows more critical. AWS Systems Manager’s hybrid activation capability, when integrated with services like API Gateway and Lambda, provides a scalable and secure pattern for managing virtual machines beyond the boundaries of AWS. Enabling Google Cloud VMs to register themselves dynamically as managed instances during their boot process allows you to eliminate the overhead of maintaining segmented operational tooling and workflows for each cloud provider. This architecture not only simplifies daily administration tasks such as patching, state management and application updates, but also strengthens your organization in areas like governance, audit and incident response. Security is preserved through identity validation using GCP service account tokens and tightly scoped IAM roles, ensuring that only verified instances are registered into the fleet and operate strictly within their designated permissions. This approach allows infrastructure teams to treat their cloud environments as one unified fleet - whether your virtual machines run in AWS, GCP or even on-premises, Systems Manager becomes your central control console, making hybrid fleet management simpler, more secure and more efficient. By reducing operational drift and consolidating automation processes, businesses are better positioned to meet modern requirements for agility, compliance and resilience in a heterogeneous cloud environment.

‍

References

“Running automations in multiple AWS Regions and accounts”, “AWS Docs”,

https://docs.aws.amazon.com/systems-manager/latest/userguide/running-automations-multiple-accounts-regions.html [1]

‍

“AWS Systems Manager Hybrid Activations”, “AWS Docs”,

https://docs.aws.amazon.com/systems-manager/latest/userguide/activations.html [2]

‍

“Using startup scripts on Linux VMs”, “Google Cloud Documentation”,

https://cloud.google.com/compute/docs/instances/startup-scripts/linux [3]

‍

“Install SSM Agent on hybrid Linux nodes”, “AWS Docs”,

https://docs.aws.amazon.com/systems-manager/latest/userguide/hybrid-multicloud-ssm-agent-install-linux.html [4]

‍

“Verify VM identity”, “Google Cloud Documentation”,

https://cloud.google.com/compute/docs/instances/verifying-instance-identity [5]

‍