AWS SSM Session Manager

AWS SSM Session Manager replaces many traditional SSH workflows with browser or CLI sessions brokered through AWS Systems Manager. For DevOps teams, it matters because it reduces the need for bastion hosts, key pair distribution, and open inbound port 22 on every managed instance. Instead of relying on one fragile manual configuration, you can design a repeatable service boundary that stays stable while the workload behind it changes.

Core ideas

The main ideas to understand are instances need the SSM Agent and an IAM role that permits Systems Manager connectivity; operators can open sessions from the console or CLI without exposing SSH to the public internet; because Session Manager is integrated with AWS, access can be controlled through IAM and recorded through CloudTrail; and this approach is often easier to standardise than juggling many key pairs across accounts and environments. These details shape architecture decisions, but they also shape day-to-day operations. When a team chooses defaults without understanding how the service behaves under failure, scale, or security review, the platform often becomes harder to debug than the application itself.

From an operations perspective, the goal is to make interactive access the exception and keep it auditable when it is required for troubleshooting. The comparison below highlights the choices that usually matter first. It is often better to start with a simpler design and add sophistication only after metrics, incidents, or delivery requirements prove the change is necessary.

Practical commands

aws ssm start-session --target i-0123456789abcdef0
aws cloudtrail lookup-events --lookup-attributes AttributeKey=EventName,AttributeValue=StartSession --max-results 10

Practical CLI checks make the service easier to support in real environments. Use the commands below to inspect the current state and confirm that automation matches intent. Before you promote a change, verify session permissions, instance agent status, and logging configuration before retiring SSH-based access paths. A safe default is deny direct SSH by default once Session Manager is proven and operational runbooks are updated. That discipline makes later troubleshooting, scaling, and security reviews far less painful.