Using AWS Systems Manager (Lab): Fleet Manager, Inventory, Run Command, Documents & Parameter Store

aws #systemsmanager #ansible #tutorial

Using AWS Systems Manager

INTRO
This lab is about AWS Systems Manager — a service that lets you manage a whole fleet of servers from one central place. Instead of logging into each machine one by one, you use it to check what's installed on your instances, run commands across many of them at once, store configuration values in one spot, and even get a shell on a server — all without ever opening an SSH port.

Now, if you've worked with Ansible before, a lot of this is going to feel familiar, just with different names. So alongside every step, I'll point out the Ansible equivalent — that way, instead of learning something brand new, you're really just learning AWS's word for something you probably already do.

THE BIG PICTURE FIRST — HOW THIS IS DIFFERENT FROM ANSIBLE
Before the steps, one important difference that's worth understanding upfront, because it explains why AWS built things this way:

Ansible is agentless. It reaches out to a server over SSH, runs its tasks, and leaves. No software has to sit running on the target machine.

Systems Manager works the opposite way. It's agent-based — every managed instance runs the SSM Agent in the background. That agent constantly checks in with AWS, waiting for work to do. That's why you never need to open an SSH port or manage keys with Systems Manager — the instance is calling home to AWS instead of AWS calling in to the instance.

Keep that one idea in mind, and everything else in this lab makes a lot more sense.

TASK 1: FLEET MANAGER — LIKE RUNNING ansible -m setup
In Ansible, when you want to know what's actually installed on a box — OS version, packages, running services — you gather facts. That's literally a module call: ansible -m setup.

Fleet Manager's Inventory feature does the same job, just continuously and automatically instead of on-demand.

To set it up:

1. Search Systems Manager in the console, then go to Fleet Manager on the left
2. Under Account management, choose Set up inventory
3. Name it Inventory-Association
4. Under targets, choose Manually selecting instances and pick your Managed Instance
5. Leave everything else default and choose Setup Inventory

Once it's running, click the Node ID, then the Inventory tab — you'll see every application installed on that instance. No SSH needed to find out what's running there. That's the whole point.

TASK 2: RUN COMMAND — LIKE RUNNING AN ANSIBLE PLAYBOOK
This is where the comparison gets really direct. In Ansible, you write a playbook — a YAML file describing tasks to run — and point it at a group of hosts.

In Systems Manager, the equivalent of a playbook is called an SSM Document.

It's AWS's pre-packaged (or custom) definition of "here's what to run." Run Command is what actually executes that document against your targets — same relationship as ansible-playbook executing a playbook.

In this task, you'll run a document that installs a small web app (Apache, PHP, the app itself) and starts the web server — basically a mini playbook run.

1. Go to Node Management → Run Command → Run command
2. Search documents by Owner → Owned by me, and select the one described as Install Dashboard App
3. Under target selection, choose Choose instances manually and pick your Managed Instance
4. Under Output options, turn off Enable an S3 bucket
5. Expand the AWS CLI command section — this shows you the exact CLI command behind the button, which you could drop into a script instead of clicking through the console every time (same idea as saving a playbook instead of running one-off ansible commands)
6. Choose Run, wait a minute or two for the status to hit Success

Then grab the instance's public IP from the lab details panel and open it in a browser — you should see the Widget Manufacturing Dashboard you just installed, all without ever logging into the box directly.

One more parallel worth knowing: Ansible lets you target a whole group of hosts using inventory groups. Systems Manager does the same thing using tags — tag a batch of instances, and you can run one document against all of them at once.

TASK 3: PARAMETER STORE — LIKE ANSIBLE VAULT / GROUP VARS
In Ansible, you keep configuration values and secrets outside your playbooks — in group_vars, host_vars, or encrypted with Ansible Vault if it's sensitive. The playbook reads those values instead of having them hardcoded.

Parameter Store is AWS's version of that same idea — a place to store config values and secrets, as plain text or encrypted, referenced by name instead of baked into your application.

1. In Systems Manager, go to Application Management → Parameter Store → Create parameter
2. Name: /dashboard/show-beta-features
3. Description: Display beta features
4. Leave Tier and Type as default
5. Value: True
6. Choose Create parameter

Go back to the dashboard app in your browser and refresh it — a third chart appears. The app was already built to check for that parameter; it just needed the value to exist. This is the same pattern as "dark launching" a feature in Ansible-managed config — the feature is already deployed, just waiting on a variable to flip it on.

(Optional: delete the parameter and refresh again — the chart disappears. That's the value being read live, not cached.)

TASK 4: SESSION MANAGER — THE PART ANSIBLE DOESN'T REALLY HAVE
This is where the comparison breaks a little, and that's worth calling out rather than forcing a fake parallel. Ansible doesn't really have an interactive shell feature — it's built to run tasks and exit, not to give you a live terminal.

Session Manager, on the other hand, gives you a browser-based shell straight into the instance — no SSH key, no open port, no bastion host. It rides on the same SSM Agent connection that Fleet Manager and Run Command already use.

1. Go to Node Management → Session Manager → Start session
2. Select your Managed Instance and choose Start session

A shell opens right in your browser. Try:

ls /var/www/html

You'll see the app files Run Command installed earlier.

Then run this to pull instance details through the CLI, right from inside the session:

AZ=`curl -s http://169.254.169.254/latest/meta-data/placement/availability-zone`
export AWS_DEFAULT_REGION=${AZ::-1}
aws ec2 describe-instances

That second block grabs the region the instance is running in, then uses it to list EC2 instance details in JSON — all without you ever needing an SSH key for this box. You could even go check the instance's security group afterward and confirm port 22 isn't open at all. The access is happening entirely through IAM and the SSM Agent instead.

WHY THIS MATTERS

• If you already think in Ansible terms, don't relearn from scratch — map the concept: Document = Playbook, Run Command = ansible-playbook, Inventory = fact-gathering, Parameter Store = vars/Vault, tags = inventory groups
• The one thing that doesn't map over is the connection model itself — Ansible pushes over SSH, Systems Manager relies on an agent pulling instructions. That single difference is why SSM never needs an open SSH port
• Session Manager plus closed SSH ports means every login is going through IAM permissions and gets logged in CloudTrail — that's a real audit trail, not just "someone SSH'd in with a shared key"
• None of these four tools work in isolation — Fleet Manager tells you what's there, Run Command changes it, Parameter Store configures it, and Session Manager lets you get hands-on when you need to

AWS #SystemsManager #Ansible #DevOps #CloudComputing #Automation