Using AWS Systems Manager (SSM) for Secure Instance Management

For decades, Secure Shell (SSH) has been the standard for accessing and managing remote servers. In the cloud, this often involves managing SSH keys, opening port 22 in security groups, and deploying dedicated "bastion hosts" to act as a secure gateway to private instances. This entire setup is complex, hard to audit, and creates a significant attack surface.

There is a better way. AWS Systems Manager (SSM) provides a suite of tools that allow you to securely manage your EC2 instances (and on-premises servers) without ever needing to open an inbound port or manage an SSH key.

This guide focuses on two core components of SSM: Session Manager for interactive shells and Run Command for executing scripts.

The Magic Behind SSM: The SSM Agent

SSM works via the SSM Agent, which is pre-installed on Amazon Linux 2 and many other common AMIs. This agent makes a secure, outbound connection to the SSM service endpoint in your region. Because the connection is outbound, you don't need to open any inbound ports in your security groups, dramatically improving your security posture.

To use SSM, you just need to ensure your instances have:

1. The SSM Agent installed and running.
2. An IAM instance profile attached with the AmazonSSMManagedInstanceCore policy.
3. Network connectivity to the SSM endpoint (e.g., via an internet gateway or a VPC endpoint).

Interactive Access with Session Manager

Session Manager allows you to start a secure, interactive shell session on an instance directly from the AWS console or your local command line.

Why it's better than SSH:

• No Open Ports: You can close port 22 in your security groups for good.
• Centralized Access Control: Access is controlled entirely through IAM policies. You can grant specific users or roles permission to start sessions on specific instances (e.g., by using tags).
• Full Auditing: Every session and every command run within it can be logged to CloudWatch Logs or S3, providing a complete audit trail of who did what, and when.

How to Use It:

1. From the AWS Console: Navigate to the EC2 console, select your instance, and click "Connect." Choose the "Session Manager" tab and click "Connect" again. A new browser tab will open with a full shell session.

2. From the AWS CLI: If you have the Session Manager plugin for the AWS CLI installed, you can start a session from your local terminal:

   aws ssm start-session --target i-0123456789abcdef0
   

This gives you the same familiar shell experience as SSH, but with all the security and auditing benefits of SSM.

Automated Execution with Run Command

Run Command allows you to execute a script or a single command across a fleet of instances. It's perfect for automated tasks like installing software, patching, or gathering information.

Why it's better than manual scripting:

• Scalability: You can run a command on hundreds of instances at once, targeting them by tags, resource groups, or instance IDs.
• Reliability: SSM manages the execution, ensuring the command is run and capturing the output, status, and any errors for each instance.
• Pre-built Documents: AWS provides a library of pre-built SSM Documents (which are essentially scripts) for common tasks, such as AWS-RunPatchBaseline for patching or AWS-RunShellScript for running a custom script.

How to Use It:

Let's say you want to check the disk space on a group of web servers tagged with Role: WebServer.

1. From the AWS Console: Go to AWS Systems Manager -> Run Command.
2. Click "Run command."
3. Choose the AWS-RunShellScript document.
4. In the "Commands" box, enter df -h.
5. In the "Targets" section, specify instances by tags and select the Role: WebServer tag.
6. Run the command. SSM will execute the script on all matching instances, and you can view the output for each one directly in the console.

Conclusion

AWS Systems Manager fundamentally changes how you should think about instance management. By replacing the traditional SSH and bastion host model with SSM Session Manager and Run Command, you can create a far more secure, auditable, and automated operational environment.

If you are still opening port 22 on your EC2 instances, it's time to reconsider. Make the switch to SSM and embrace a modern, secure, and more efficient way to manage your fleet.