Skip to content
EC2 Instance Access (SSM)

EC2 Instance Access (SSM)

Overview

This pattern grants access to EC2 Windows instances through AWS Systems Manager (SSM) Run Command — no inbound RDP or bastion needed. At checkout the broker creates a temporary account on the target instance; at checkin it removes it. Three variants cover different needs:

VariantCreatesUse for
AddLocalAdminTemporary local administratorStandalone Windows instances
AddADUserTemporary domain userDomain-joined instances
MultiInstanceAccount across multiple instancesFleet-wide access in one checkout

Before You Begin

  • The Access Broker is deployed and connected
  • AWS CLI on the broker host, with permission to call ssm send-command
  • Target instances have the SSM Agent running and an instance profile allowing SSM (see the SSM agents notes)
  • For AddADUser: the instance is domain-joined and the service account can manage AD users

EC2 instances ship with the SSM Agent pre-installed on Amazon Windows AMIs. On-prem/hybrid servers need a manual agent install and an SSM activation — there is no per-instance IAM granularity for hybrid.

How It Works

checkout → ssm send-command (AddLocalAdmin / AddADUser) → create account → return credentials
checkin  → ssm send-command → remove account

Configure in Britive

Create the permission

Resource Manager → Resource Type Permissions → New Permission. Language = PowerShell or Shell (the scripts invoke aws ssm send-command). Paste the checkout/checkin routines for your chosen variant. Declare an INSTANCE (or instance-list) variable and the AWS region; the requesting user is system-defined. Attach a response template surfacing the returned credentials.

Create a profile and policy

Create a profile (e.g. 2h), associate the instances (by resource label), add the permission, and add a policy assigning members by tag.

Verify

Check out and connect

Check out the profile, then RDP to the instance with the returned credentials.

Check in and confirm removal

After checkin, the account is removed — confirm with Get-LocalUser (local admin) or Get-ADUser (domain) on the instance.

Troubleshoot

SymptomCauseFix
send-command finds no instanceInstance not SSM-managedConfirm the SSM Agent is running and the instance profile allows SSM
AccessDeniedBroker IAM can’t call SSMGrant ssm:SendCommand and ssm:ListCommandInvocations
AD variant failsInstance not domain-joined or service account lacks rightsUse AddLocalAdmin for standalone hosts; grant AD user-management rights for domain hosts
Account remains after checkinCheckin command failedCheck the SSM command invocation status and broker logs

Next Steps

Last updated on