Introduction

The InvalidInstanceId error from Systems Manager SendCommand usually means the target instance is not a valid managed node from Systems Manager’s point of view. That is broader than “the EC2 ID is wrong”: the instance can exist in EC2 and still be invalid for SendCommand because the region, permissions, agent status, or registration state is wrong.

What SendCommand Expects

SendCommand is part of AWS Systems Manager Run Command. It can target managed nodes by InstanceIds or by tag-based Targets.

A simple CLI example looks like this:

1aws ssm send-command \
2  --document-name "AWS-RunShellScript" \
3  --instance-ids i-0123456789abcdef0 \
4  --parameters commands='["uname -a"]' \
5  --region us-east-1

If Systems Manager cannot treat that instance as a valid managed node for the request, InvalidInstanceId is returned.

Common Causes

The most common causes are:

• The instance ID is wrong or malformed
• You are calling the API in the wrong AWS Region
• The instance does not have SSM Agent running or registered
• The instance is not in a valid lifecycle state
• Your IAM permissions do not let you target that managed node

The important point is that this error is about Systems Manager visibility and manageability, not just EC2 existence.

Verify the Region First

An instance ID is region-specific in practice. If the instance lives in us-west-2 but your CLI profile or SDK call uses us-east-1, Systems Manager will not find the right managed node.

Check both commands in the same region:

1aws ec2 describe-instances \
2  --instance-ids i-0123456789abcdef0 \
3  --region us-east-1
4
5aws ssm describe-instance-information \
6  --region us-east-1

If the EC2 instance exists but does not appear in describe-instance-information, Systems Manager is not managing it correctly yet.

Confirm the Instance Is a Managed Node

For Run Command to work, the machine must be registered with Systems Manager. In a standard EC2 setup that usually requires:

• An attached instance profile with Systems Manager permissions
• SSM Agent installed and running
• Network connectivity to the SSM endpoints

A useful check is:

aws ssm describe-instance-information \
  --query "InstanceInformationList[?InstanceId=='i-0123456789abcdef0']"

If this returns an empty list, the node is not registered as a valid managed node for Systems Manager.

Check Agent and Instance State

According to AWS API documentation, InvalidInstanceId can also occur if SSM Agent is not running, not registered, or if the instance is not in a valid state for the operation.

That means you should verify:

• The instance is not terminated or shutting down
• The SSM Agent service is running on the machine
• The IAM role attached to the instance includes the Systems Manager permissions you expect

For Amazon Linux or Ubuntu, the agent status is often checked with a system service command such as:

sudo systemctl status amazon-ssm-agent

IAM Can Also Surface as InvalidInstanceId

This surprises many people. If your user or role does not have permission to access the target managed node, Systems Manager can respond with InvalidInstanceId. So do not assume this is only a typo problem.

Check the caller identity and the IAM policies involved:

aws sts get-caller-identity

Then confirm that the caller can use ssm:SendCommand and target the requested nodes.

Common Pitfalls

A common mistake is verifying the instance only in EC2 and not in Systems Manager. An EC2 instance can exist while still being unavailable to SendCommand.

Another mistake is forgetting the CLI region or profile. The command may look correct but silently target the wrong region or account.

A third mistake is focusing on the instance ID string while ignoring SSM Agent, instance profile, or registration status. Those are just as likely to be the real cause.

Summary

• 'InvalidInstanceId in SendCommand means Systems Manager cannot treat the target as a valid managed node for the request.'
• Check the AWS Region, account, and instance ID first.
• Confirm the instance appears in ssm describe-instance-information.
• Verify SSM Agent, instance profile permissions, and node state.
• Do not assume the error is only a typo; IAM and registration problems can trigger it too.