developersIO
Systems Manager Cloud Connector で Google Cloud の VM を管理対象ノードに登録して Run Command を実行してみた

Systems Manager Cloud Connector で Google Cloud の VM を管理対象ノードに登録して Run Command を実行してみた

AWS Systems Manager の Cloud Connector が Google Cloud に対応したので、Compute Engine の VM を 1台登録しました。管理対象ノードの一覧に表示されることを確認し、Run Command と Inventory で OS や CPU の情報を取得できました。
AWS Systems Manager（SSM）AWSGoogle Cloud (GCP)アップデートAWS Systems Manager Run Command
suzuki.ryo
2026.11.15

はじめに

AWS は 2026年11月13日、Systems Manager Cloud Connector の Google Cloud 対応を発表しました。

https://aws.amazon.com/jp/about-aws/whats-new/2026/11/systems-manager-google-cloud-support/

Cloud Connector は、Google Cloud の VM に SSM Agent を自動でインストールし、Systems Manager の管理対象ノードとして扱えるようにします。AWS 側から Google Cloud の VM で処理を実行できるかを調べました。e2-micro の VM 1台を使い、管理対象ノードとしての登録、Run Command、Inventory を試しました。

セットアップ

構成

AWS のリージョンは ap-northeast-1 です。VM は asia-northeast1-b に1台作成しました。マシンタイプは e2-micro、OS は Debian 12 です。Cloud Connector のホストプロジェクトと対象プロジェクトは同じ Google Cloud プロジェクトです。Cloud Connector は、コンソールのセットアップスクリプトを使わず、公式ドキュメントの CLI 手順で作成しました。

AWS 側と Google Cloud 側で用意したものは次のとおりです。

クラウド 用意したもの
AWS IAM のアウトバウンド Web アイデンティティ連携（検証前から有効）
AWS フェデレーション用 IAM ロール
AWS Automation 用 IAM ロール
AWS Dispatch 用 IAM ロール
AWS マネージドインスタンス用 IAM ロール
AWS Cloud Connector
AWS State Manager association
Google Cloud API の有効化
Google Cloud Workload Identity プールと OIDC プロバイダ
Google Cloud コネクタ用サービスアカウント
Google Cloud OS Config の設定（プロジェクトメタデータ、機能設定、サービスエージェントへの権限）
Google Cloud カスタムロール awsSsmVmRunCommand

Cloud Connector

以降のコマンドと設定ファイルに含まれる大文字のプレースホルダー（HOST_PROJECT_NUMBER、ACCOUNT_ID など）は、自分の環境の値に置き換えてください。

Cloud Connector の設定を create-cloud-connector-configuration.json として保存します。このファイルを create-cloud-connector に渡して作成します。

{
  "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

WorkloadIdentityPoolProvider と ServiceAccountEmail には Google Cloud 側で作ったプロバイダとサービスアカウントを指定します。--role-arn にはフェデレーション用 IAM ロールを指定します。

オンボーディング

VM を管理対象ノードにするには、State Manager association で AWS-InstallSSMAgentOnGCP ドキュメントを実行します。パラメータは 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)"

VM は association を作成する前から起動していました。VM 1台で1回だけ測ったところ、association の作成から管理対象ノードとして登録されるまでが約6分でした。association が起動する Automation（AWS-InstallSSMAgentOnGCP）が成功するまでは約12分でした。

確認結果

管理対象ノードの一覧

describe-instance-information の出力に、Google Cloud の VM が 1件表示されました。

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"
        }
    ]
}

今回の VM の Name は、プロジェクト ID、ゾーン、VM 名をコロンでつないだ形式でした。

管理対象ノードには、キーが CloudConnector、値が Cloud Connector の ID であるタグが自動で付きました。このタグを tag:CloudConnector のフィルタに指定すると、Google Cloud の VM が返りました。検証したアカウントの管理対象ノードはこの1台だけです。

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

AWS-RunShellScript で、OS とカーネルの情報、ホスト名、CPU 数、メモリ、Google Cloud のメタデータサーバーが返すゾーンを取得します。実行するコマンドは 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

send-command が返す CommandId を指定して、結果を取得します。

aws ssm get-command-invocation \
  --command-id COMMAND_ID \
  --instance-id mi-0123456789abcdef0 \
  --query "[Status,ResponseCode,StandardOutputContent,StandardErrorContent]" \
  --output json

Status は Success、ResponseCode は 0 で、StandardOutputContent は次の内容でした。

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

最終行は Google Cloud のメタデータサーバーが返したゾーンで、コマンドが Google Cloud の VM の中で実行されたことを示します。

Inventory

管理対象ノード 1台を対象に、AWS-GatherSoftwareInventory の association を作成しました。

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

association の作成から約40秒後に list-inventory-entries を実行すると、Entries が返りました。CaptureTime は association の作成から約2秒後です。

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"
        }
    ]
}

まとめ

従来のハイブリッドアクティベーションでは、アクティベーションを作り、VM ごとに SSM Agent を手動でインストールして、アクティベーションコードと ID で登録する必要がありました。Cloud Connector により、この登録の手間が簡略化されました。

Cloud Connector を使って、Google Cloud の VM に SSM Agent を手動でインストールせずに、Systems Manager の管理対象ノードとして扱えました。Run Command の実行と、Inventory での CPU・カーネル情報の取得も確認できました。

既に EC2 を Systems Manager で管理していて、Google Cloud の VM の管理やジョブの実行も一元化したい場合は、お試しください。

この記事をシェアする

AWSのお困り事はクラスメソッドへ

関連記事

SSM Inventory + AWS Config で EC2 に禁止されたアプリケーションがインストールされているか監視してみた
片方 裕人
2025.08.09
CloudWatchエージェントをState Managerで自動更新を設定してみた。
岩崎智哉
2025.05.09
CloudWatch Agent をマネジメントコンソール画面からインストール・起動する方法
立神 皓基
2025.09.16
【小ネタ】 AWS CLI コマンドを利用して、SSM のマネージドノードとして登録されていない EC2 インスタンスの調査方法
片方 裕人
2025.12.09