Systems Manager: The End of the Bastion Host

The Problem with SSH

Traditionally, to manage a private server, you needed a Bastion Host — a publicly accessible "jump box" that you SSH into first, then hop from there to your private instances. This required:

1. A dedicated EC2 instance running 24/7 just to be a jump box.
2. Port 22 open in your Security Group, visible to the internet.
3. SSH key pairs distributed to every developer who needs access.

This is a significant security risk. SSH keys get lost, stolen, or forgotten on decommissioned laptops. Open ports are continuously probed by automated scanners. And when a developer leaves the company, you have to hunt down and revoke every key they ever had.

The Solution: Session Manager

AWS Systems Manager Session Manager allows you to open a secure, interactive shell on an EC2 instance directly from the AWS Console or CLI — without opening any inbound ports, without SSH keys, and without a bastion host.

How it works mechanically:

1. The SSM Agent is pre-installed on Amazon Linux 2 and Amazon Linux 2023 AMIs. For other operating systems, you install it manually.
2. The agent runs as a background process on the instance and polls the SSM service endpoint outbound over HTTPS (port 443). The instance initiates the connection to AWS — no inbound connection is ever made.
3. When you start a session, AWS routes your terminal input through the SSM service to the agent, which executes it locally on the instance.
4. Authentication is entirely IAM-based. If your IAM user or role has the ssm:StartSession permission on that instance, you can connect. No keys to manage.
5. Every command typed in the session is logged to S3 or CloudWatch Logs. You get a full, timestamped transcript of what was done. This is impossible to achieve with standard SSH without additional tooling.

Starting a session is a single call that takes nothing but the target instance ID and drops you directly into a shell on that instance. No key pair. No port 22. No bastion.

Parameter Store

SSM also includes Parameter Store, a hierarchical key-value store for configuration data — database connection strings, feature flags, API endpoints, and secrets.

Why it matters: Without a service like this, configuration values get hardcoded into application code or baked into AMIs. When a database password rotates, you'd have to redeploy every application. With Parameter Store, the application fetches the value at runtime, and you update it in one place.

Two tiers:

SecureString parameters are encrypted at rest using AWS KMS. This gives you a lightweight secrets management solution without the cost of AWS Secrets Manager (which adds automatic rotation, cross-account access, and deeper service integrations).

Writing and reading a SecureString are both single API calls: storing one takes a name, a value, and the SecureString type; reading it back takes the same name plus a flag telling SSM to decrypt the value before returning it.