Prerequisites¶

projectx-prod-vpc has been created with subnets configured.
My-Desktop-Key-Pair key pair exists.
AWS CLI configured with appropriate IAM credentials.

Note

This guide provides general awareness of when and how SSM Manager helps defend against common cloud risks. SSM Session Manager avoids opening SSH/RDP ports (as in Metadata SSRF / EC2), reduces credential exposure (as in Hardcoded Secrets), and improves auditability and patch hygiene.

Network Topology¶

Overview¶

AWS Systems Manager (SSM) provides secure, agent-based management of EC2 instances and hybrid workloads without opening inbound SSH or RDP ports. By using the SSM agent and IAM roles, you can connect, run commands, patch systems, and retrieve secrets without exposing credentials or managing keys.

SSM helps you move from traditional remote access (SSH, RDP) to a model where instances are managed through AWS APIs and temporary sessions—reducing the attack surface and improving visibility.

No SSH or RDP Required¶

SSM Session Manager lets you connect to instances through the AWS Console or CLI without SSH keys, bastion hosts, or open inbound ports. The SSM agent runs on the instance and establishes an outbound connection to SSM endpoints. Your access is brokered by IAM, so you never need to store or distribute SSH keys or RDP credentials.

This eliminates many risks: exposed SSH ports, stolen or leaked keys, and lateral movement paths that rely on traditional remote access. Instances can remain in private subnets with no public IP and still be fully manageable.

Credential Theft Prevention¶

SSM integrates with AWS security services to avoid credential exposure:

STS tokens: Session Manager uses temporary credentials and IAM roles instead of long-lived access keys or static passwords. There are no SSH keys or RDP credentials to steal from config files or memory.
AWS Secrets Manager: You can use SSM Parameter Store (SecureString) or AWS Secrets Manager to store application secrets. Instances retrieve them at runtime via IAM—no hardcoded credentials in user data, config files, or environment variables.

By combining SSM with Secrets Manager and IAM, you keep credentials out of code, configs, and interactive sessions.

Patch Management¶

SSM Patch Manager automates patching across EC2 and hybrid instances. You define maintenance windows, select patches (OS or application), and SSM applies them on schedule. You can scope patching by tags, patch groups, or baseline rules, and get compliance reports in the console or via APIs.

This reduces the window where unpatched systems can be exploited and helps maintain a consistent, auditable patch state across your fleet.

Session Logging¶

SSM Session Manager can log all interactive sessions to Amazon S3 and optionally to CloudWatch Logs. Every command and output is captured, giving you a full audit trail for compliance and forensics. You can also enable S3 session logs and enforce encryption and retention policies.

Session logging helps answer who did what, when, and from where, without relying on host-based logs that an attacker might modify.

Connect To EC2 Through SSM Manager¶

This is an easy one.

Ensure your instances have the SSM agent installed (they already come pre-installed on Amazon Linux 2, Ubuntu 16.04+, and Windows Server 2016+ AMIs).

Create an IAM role with AmazonSSMManagedInstanceCore (and optional CloudWatchAgentServerPolicy for logging).

While provisioning the EC2 instance or adjusting an existing one, create a Security Group with outbound HTTPS (443) to SSM endpoints. The EC2 instance must reside in a non-default VPC that has an Internet Gateway or NAT Gateway available.

In the EC2 console, select an instance ➔ Connect ➔ Session Manager ➔ Connect to verify access.

Or through the aws cli:

aws ssm start-session --target <instance-id>

That's it!

Cleanup¶

Warning

Disable or remove SSM-related IAM roles, S3 session log buckets, and CloudWatch log groups when finished to avoid ongoing charges and unnecessary retention.