Linux Automation on AWS: Where the Friendly Parts Actually Live

Q: Can user-data run on every boot, not just the first?

Yes, with `MIME multipart` user-data and a script in `/var/lib/cloud/scripts/per-boot/`. But this is rare; user-data is usually first-boot only.

Q: How do I know if a Run Command succeeded?

Check the command status in the console, or use the `GetCommandInvocation` API. The team that monitors SSM command status has alerts on failures.

Linux automation on AWS lives in three places: user-data scripts at launch, AWS Systems Manager (SSM) for ongoing state, and EventBridge for event-driven work. The right tool depends on what you’re trying to automate.

The three automation layers
User-data at launch
SSM for ongoing state
EventBridge for event-driven
The wrong choices
The deep dive into SSM Run Command
AWS OpsWorks vs SSM vs custom
FAQ

The three automation layers

Each layer fits a different use case:

User-data (launch-time). The script that runs when the EC2 instance boots. The right place for installation, configuration, and bootstrap.
SSM (ongoing). The right place for patching, command execution, parameter storage, and session management on running instances.
EventBridge (event-driven). The right place for things that should react to events (a new S3 object, a CloudWatch alarm, an SQS message).

The team that picks the right layer for the job has clean automation. The team that uses user-data for everything has a mess of bootstrapping scripts and no good way to update them.

User-data at launch

The right tool for “make this instance ready when it boots”:

#!/bin/bash
apt update && apt install -y nginx
systemctl enable nginx

Pass to the EC2 instance as the user-data script. AWS runs it as root at first boot. The team that wants to test the script locally runs it in a cloud-init environment first.

The downside: user-data runs once at boot. The team that needs to update the script on a running fleet uses SSM Run Command instead.

SSM for ongoing state

SSM has four pieces that matter for Linux automation:

Run Command. Execute a shell command on one or many instances. The right tool for “patch this CVE on every instance in the fleet”.
Session Manager. SSH-in-the-browser, without exposing port 22. The right tool for the team that doesn’t want to manage SSH keys.
Parameter Store. A key-value store for config and secrets. The right tool for “store the database password and read it at boot”.
State Manager. Maintain a desired state on instances (associations). The right tool for “every instance should have nginx running and the right config”.

EventBridge for event-driven

The right tool for “do X when Y happens”:

An S3 object is created -> trigger a Lambda to process it.
A CloudWatch alarm fires -> send a notification or trigger an SSM automation.
An EC2 instance state changes -> trigger a Lambda to update DNS.

EventBridge replaces the older SNS/SQS patterns. The team that wires up EventBridge to Lambda has the modern automation pattern.

The wrong choices

The four patterns to avoid:

Baking everything into the AMI. The team that builds a custom AMI with the entire application baked in has a 30-minute AMI rebuild cycle for every config change.
Using user-data for everything. User-data is for bootstrap, not for ongoing automation. The team that crams a 500-line user-data script has a script that’s hard to update.
Using SSH for fleet-wide operations. The team that SSHes into 50 instances to run a command should be using SSM Run Command instead.
Not using SSM at all. The team that doesn’t install the SSM agent on instances misses out on the cleanest automation path AWS offers.

The deep dive into SSM Run Command

SSM Run Command is the workhorse of AWS Linux automation. The right use cases:

Patch a CVE across the fleet. Target a tag, run yum update or apt upgrade, capture the output to S3.
Rotate secrets. Run a script that updates the credentials file, restarts the service, verifies the new credentials work.
Gather inventory. Run a script that collects installed packages, listening ports, disk usage; write to a central S3 bucket.
Deploy configuration changes. Update /etc/nginx/nginx.conf and reload nginx across the fleet.

The right pattern:

Write the script once. Store it in S3 or SSM Parameter Store.
Use the SSM document framework. Define parameters (what package to upgrade, which tag to target) so the script is reusable.
Target by tag. tag:Environment=production to run only on prod.
Capture output to S3. Use the output S3BucketName parameter.
Alert on failure. CloudWatch Events trigger on command failure.

The team that uses Run Command this way automates 90% of routine Linux operations.

AWS OpsWorks vs SSM vs custom

The right way to choose between AWS automation tools:

AWS OpsWorks. Managed Chef/Puppet. The right choice for teams that have existing Chef/Puppet cookbooks. Otherwise, the operational overhead isn’t worth it.
AWS Systems Manager. The right choice for most teams. SSM Document framework, Run Command, State Manager, Parameter Store, Session Manager. The full suite.
Custom (Lambda + EventBridge + Run Command). The right choice for complex orchestrations. Use when the logic doesn’t fit in a single SSM Document.
Third-party (Ansible Tower, Chef Automate, Puppet Enterprise). The right choice for teams with existing third-party tool expertise.

The team that picks SSM as the default has the simplest architecture. The team that uses a mix (SSM for ad-hoc, Ansible for configuration, Lambda for orchestration) has the most flexibility.

FAQ

Do I need SSM agent on every EC2 instance?

Yes, if you want to use SSM Run Command, Session Manager, or State Manager. The agent is pre-installed on Amazon Linux 2 and most AWS-published AMIs. The team that uses custom AMIs has to install it.

Can user-data run on every boot, not just the first?

Yes, with MIME multipart user-data and a script in /var/lib/cloud/scripts/per-boot/. But this is rare; user-data is usually first-boot only.

What’s the difference between EventBridge and SNS?

SNS is a pub/sub messaging service. EventBridge is an event bus that understands AWS event sources and routes events to targets. EventBridge is the modern replacement for the SNS event pattern.

Should I use user-data or a configuration management tool?

User-data for first-boot bootstrap. Ansible, Chef, Puppet, or Salt for ongoing configuration management. The team that picks Ansible + SSM has the right architecture.

Does SSM agent need internet access?

It can work with VPC endpoints (no internet) or Systems Manager VPC interface endpoints. The team that runs SSM in a private subnet uses VPC endpoints; the team that doesn’t has SSM agent that requires NAT gateway or public subnet.

Can SSM run scripts on Windows?

Yes. SSM supports both Linux and Windows. The document framework handles the differences; the team that uses SSM doesn’t write two sets of scripts.

How do I know if a Run Command succeeded?

Check the command status in the console, or use the GetCommandInvocation API. The team that monitors SSM command status has alerts on failures.

If you are sizing the infrastructure for the kind of project this post covers, the RunxBuild hosting calculator is the right place to model the line items. The compute, the memory, the storage, the bandwidth, the database - each one is a separate number, and the team’s mental model for the platform is the sum of those numbers. The RunxBuild dashboard is where the team sees the actual usage in one place.

Useful related references: