I Tried Registering Google Cloud VMs as Managed Nodes with Systems Manager Cloud Connector and Running Run Command
This page has been translated by machine translation. View original
Introduction
On November 13, 2026, AWS announced Google Cloud support for Systems Manager Cloud Connector.
Cloud Connector automatically installs SSM Agent on Google Cloud VMs and lets you handle them as Systems Manager managed nodes. I investigated whether processes can be run on Google Cloud VMs from the AWS side. Using one e2-micro VM, I tried registration as a managed node, Run Command, and Inventory.
Setup
Configuration
The AWS region is ap-northeast-1. I created one VM in asia-northeast1-b. The machine type is e2-micro and the OS is Debian 12. The Cloud Connector host project and the target project are the same Google Cloud project. I created the Cloud Connector using the CLI procedure in the official documentation, without using the console setup script.
The resources I prepared on the AWS side and the Google Cloud side are as follows.
| Cloud | What I prepared |
|---|---|
| AWS | IAM outbound web identity federation (enabled before the verification) |
| AWS | IAM role for federation |
| AWS | IAM role for Automation |
| AWS | IAM role for Dispatch |
| AWS | IAM role for managed instances |
| AWS | Cloud Connector |
| AWS | State Manager association |
| Google Cloud | Enabling APIs |
| Google Cloud | Workload Identity pool and OIDC provider |
| Google Cloud | Service account for the connector |
| Google Cloud | OS Config settings (project metadata, feature settings, permissions for the service agent) |
| Google Cloud | Custom role awsSsmVmRunCommand |
Cloud Connector
Replace the uppercase placeholders (such as HOST_PROJECT_NUMBER and ACCOUNT_ID) in the following commands and configuration files with the values for your own environment.
Save the Cloud Connector configuration as create-cloud-connector-configuration.json. Pass this file to create-cloud-connector to create it.
{
"GcpConfiguration": {
"WorkloadIdentityPoolProvider": "projects/HOST_PROJECT_NUMBER/locations/global/workloadIdentityPools/ssm-verify-pool/providers/ssm-verify-oidc",
"ServiceAccountEmail": "ssm-connector@HOST_PROJECT_ID.iam.gserviceaccount.com",
"Targets": {"Projects": [{"ProjectId": "HOST_PROJECT_ID"}]}
}
}
aws ssm create-cloud-connector \
--display-name gcpverify \
--configuration file://create-cloud-connector-configuration.json \
--role-arn arn:aws:iam::ACCOUNT_ID:role/service-role/SSM-GCPRole-gcpverify
Specify the provider and service account created on the Google Cloud side for WorkloadIdentityPoolProvider and ServiceAccountEmail. Specify the IAM role for federation for --role-arn.
Onboarding
To make the VM a managed node, run the AWS-InstallSSMAgentOnGCP document with a State Manager association. Save the parameters as create-association-parameters.json.
{
"AutomationAssumeRole": ["arn:aws:iam::ACCOUNT_ID:role/service-role/SSM-GCPAssumeRole-gcpverify"],
"ManagedInstanceIamRole": ["service-role/AmazonEC2RunCommandRoleForManagedInstances"],
"CloudConnector": ["CLOUD_CONNECTOR_ID"]
}
aws ssm create-association \
--association-name AWSSSMGcpConnector-CLOUD_CONNECTOR_ID \
--name AWS-InstallSSMAgentOnGCP \
--association-dispatch-assume-role arn:aws:iam::ACCOUNT_ID:role/service-role/SSM-GCPDispatchRole-gcpverify \
--parameters file://create-association-parameters.json \
--schedule-expression "rate(48 hours)"
The VM was already running before I created the association. Measured once with one VM, it took about 6 minutes from creating the association to being registered as a managed node. It took about 12 minutes until the Automation launched by the association (AWS-InstallSSMAgentOnGCP) succeeded.
Results
List of managed nodes
The output of describe-instance-information showed one Google Cloud VM.
aws ssm describe-instance-information
{
"InstanceInformationList": [
{
"InstanceId": "mi-0123456789abcdef0",
"PingStatus": "Online",
"AgentVersion": "3.3.5828.0",
"PlatformType": "Linux",
"PlatformName": "Debian GNU/Linux",
"PlatformVersion": "12",
"RegistrationDate": "2026-11-15T15:26:42.122000+09:00",
"ResourceType": "ManagedInstance",
"Name": "HOST_PROJECT_ID:asia-northeast1-b:ssm-verify-vm",
"ComputerName": "HOST_PROJECT_ID.ssm-verify-vm",
"SourceType": "compute.googleapis.com/Instance",
"SourceLocation": "asia-northeast1"
}
]
}
The Name of this VM was in a format that joins the project ID, zone, and VM name with colons.
A tag with the key CloudConnector and the Cloud Connector ID as its value was automatically attached to the managed node. When I specified this tag in a tag:CloudConnector filter, the Google Cloud VM was returned. This one is the only managed node in the account I tested.
aws ssm describe-instance-information \
--filters "Key=tag:CloudConnector,Values=CLOUD_CONNECTOR_ID" \
--query "InstanceInformationList[].[InstanceId,Name,PingStatus,ResourceType,SourceType,PlatformName,PlatformVersion]" \
--output json
Run Command
Using AWS-RunShellScript, I retrieve the OS and kernel information, hostname, number of CPUs, memory, and the zone returned by the Google Cloud metadata server. Save the commands to run as run-command-os-info.json.
{
"commands": [
"cat /etc/os-release | head -4",
"uname -srm",
"hostname",
"nproc",
"free -m | head -2",
"curl -s -H 'Metadata-Flavor: Google' http://metadata.google.internal/computeMetadata/v1/instance/zone"
]
}
aws ssm send-command \
--document-name AWS-RunShellScript \
--instance-ids mi-0123456789abcdef0 \
--parameters file://run-command-os-info.json \
--comment "devio gcp verify os info" \
--query "Command.[CommandId,Status,DocumentName]" \
--output json
Specify the CommandId returned by send-command to retrieve the result.
aws ssm get-command-invocation \
--command-id COMMAND_ID \
--instance-id mi-0123456789abcdef0 \
--query "[Status,ResponseCode,StandardOutputContent,StandardErrorContent]" \
--output json
Status was Success, ResponseCode was 0, and StandardOutputContent was as follows.
PRETTY_NAME="Debian GNU/Linux 12 (bookworm)"
NAME="Debian GNU/Linux"
VERSION_ID="12"
VERSION="12 (bookworm)"
Linux 6.1.0-54-cloud-amd64 x86_64
ssm-verify-vm
2
total used free shared buff/cache available
Mem: 969 407 214 0 484 562
projects/HOST_PROJECT_NUMBER/zones/asia-northeast1-b
The last line is the zone returned by the Google Cloud metadata server, which shows that the command was executed inside the Google Cloud VM.
Inventory
I created an association for AWS-GatherSoftwareInventory targeting one managed node.
aws ssm create-association \
--name AWS-GatherSoftwareInventory \
--targets Key=InstanceIds,Values=mi-0123456789abcdef0 \
--association-name devio-gcp-verify-inventory \
--schedule-expression "rate(30 minutes)" \
--parameters applications=Enabled,awsComponents=Enabled,networkConfig=Enabled,instanceDetailedInformation=Enabled \
--query "AssociationDescription.[AssociationId,Overview.Status]" \
--output json
When I ran list-inventory-entries about 40 seconds after creating the association, Entries were returned. CaptureTime is about 2 seconds after the association was created.
aws ssm list-inventory-entries \
--instance-id mi-0123456789abcdef0 \
--type-name AWS:InstanceDetailedInformation \
--output json
{
"TypeName": "AWS:InstanceDetailedInformation",
"InstanceId": "mi-0123456789abcdef0",
"SchemaVersion": "1.0",
"CaptureTime": "2026-11-15T06:34:11Z",
"Entries": [
{
"CPUCores": "1",
"CPUHyperThreadEnabled": "true",
"CPUModel": "Intel(R) Xeon(R) CPU @ 2.20GHz",
"CPUSockets": "1",
"CPUs": "2",
"KernelVersion": "6.1.0-54-cloud-amd64"
}
]
}
Summary
With conventional hybrid activation, you had to create an activation, manually install SSM Agent on each VM, and register it with the activation code and ID. Cloud Connector simplifies this registration effort.
Using Cloud Connector, I was able to handle a Google Cloud VM as a Systems Manager managed node without manually installing SSM Agent on it. I also confirmed that Run Command execution and retrieval of CPU and kernel information through Inventory work.
If you already manage EC2 with Systems Manager and want to centralize the management of Google Cloud VMs and job execution as well, give it a try.
