Systems Manager (SSM) for Hybrid Environments

The "Universal Remote"

Imagine you're an IT administrator responsible for 100 servers in AWS and 50 physical Dell servers sitting in your office closet. You need to apply a security patch to all 150 of them by end of day. Without a unified tool, you'd need two separate workflows, two sets of credentials, and two different patching systems. That's exactly the problem SSM Hybrid Activations solves.

AWS Systems Manager (SSM) is AWS's operations platform for managing fleets of compute resources. It handles patching, configuration, command execution, secrets retrieval, and remote shell access. By default, it manages EC2 instances. With Hybrid Activations, you extend that same management plane to any server anywhere — physical servers in your data center, VMs in Azure or Google Cloud, or Raspberry Pis on a factory floor.

How It Works: The mi- Prefix

The registration process is straightforward and follows a one-time setup pattern:

1. Create a Service Role

Create an IAM Role that the on-premises server will assume, trusted by the SSM service principal and with the managed policy AmazonSSMManagedInstanceCore attached. This grants the server permission to call SSM APIs (receive commands, send heartbeats, upload logs).

2. Generate an Activation

An activation is a time-limited credential pair (Code + ID) that authorizes a server to register itself with SSM — a single call naming the target IAM role, a registration limit (how many servers can use this code), and an expiration date, returning the ActivationId and ActivationCode.

The activation expires (default 24 hours, configurable up to 30 days). After expiration, the code cannot be used to register new servers — but already-registered servers continue to function.

3. Install the SSM Agent and Register

On the on-premises Linux server: install the SSM Agent package, run it once with the -register flag passing the activation's code, ID, and region, then enable and start it as a system service.

4. The Result

Within 60 seconds, the server appears in the SSM Fleet Manager console with a managed instance ID starting with mi- (e.g., mi-0123456789abcdef0). This prefix distinguishes hybrid-registered servers from EC2 instances (which use i-). From this point forward, the server is a first-class citizen in SSM — you can patch it, run commands on it, access it via Session Manager, and store its inventory data.

The Security Superpower: Zero Inbound Ports

Traditional remote management requires punching holes in your firewall. SSH needs port 22 open inbound. RDP needs port 3389. Every open inbound port is an attack surface — a door that an adversary can knock on.

SSM inverts this model entirely.

The SSM Agent running on your server opens an outbound HTTPS connection (port 443) to the SSM service endpoint in AWS. It then long-polls: "Do you have any commands for me?" When you trigger a Session Manager session or a Run Command job, AWS queues the work, and the agent picks it up on its next poll.

Your firewall needs zero inbound rules for SSM to work. You only need to allow outbound 443 to the SSM service endpoints — which most corporate firewalls already permit for general HTTPS traffic.

This means:
- No SSH keys to rotate or lose
- No RDP credentials to manage
- No VPN required for shell access
- Full audit trail of every session in CloudTrail

Senior depth — network endpoint options: In environments where outbound internet access is also restricted (air-gapped or highly regulated networks), SSM can communicate via VPC Endpoints (AWS PrivateLink). You create interface endpoints for ssm, ssmmessages, and ec2messages in your VPC, and traffic never leaves the AWS network. For on-premises servers connecting through Direct Connect, this means SSM traffic flows through your private network connection rather than the public internet — satisfying strict compliance requirements.