- Newest
- Most votes
- Most comments
I still haven't found a way to filter my targets to only include running instances, so I thought I'd share the work-a-round I am using in case it helps anyone else:
As I explained in OP, I already had the first step of my Automation checking instance status using the runbook action aws:assertAwsResourceProperty to call the DescribeInstanceStatus API and assert the answer is "running". Unfortunately, the way aws:assertAwsResourceProperty works, if response doesn't match the value you specify, it fails. I was unhappy with my executions being marked as failures in cases where instances were not running.
A colleague clued me in to a trick with aws:branch steps where you can set isEnd to true and provide no Default step, that essentially allows you to exit gracefully. I had to abandon assertAwsResourceProperty and make the DescribeInstanceStatus call directly in an aws:executeAwsApi step, so I could capture and evaluate the output myself in such a branch step. It looked like this:
...
"mainSteps": [
{
"name": "GetInstanceStatus",
"action":"aws:executeAwsApi",
"inputs": {
"Service": "ec2",
"Api": "DescribeInstanceStatus",
"InstanceIds": [
"{{InstanceId}}"
]
},
"outputs":[
{
"Name":"InstanceState",
"Selector": "$.InstanceStatuses[0].InstanceState.Name",
"Type": "String"
}
]
},
{
"name": "CheckInstanceStatus",
"action": "aws:branch",
"isEnd": true,
"inputs": {
"Choices": [
{
"NextStep": "TheRestOfMyRunbook",
"Variable": "{{GetInstanceStatus.InstanceState}}",
"StringEquals": "running"
}
]
}
},
{
"name": "TheRestOfMyRunbook",
...
},
...
Now, when a State Manager Association, or Event-driven Lambda, or whatever trigger, feeds my runbook a stopped instance, it exits at the second step and marks my execution as successful.
Another possible feature, that I often find myself reaching for and isn't there, that might have eased this would be an option for onFailure to "Skip" or "End". Some way to simply get out of a Runbook without Aborting and showing a failure.
Relevant content
- asked a year ago
AWS OFFICIALUpdated 2 years ago- AWS OFFICIALUpdated 2 years ago
This sounds like a use case for State Manager instead of an Automation Runbook. Is there a particular reason you're using the latter instead of the former?
Applying a different CloudWatch Agent config (Configs stored in SSM Parameters) to each environment, using tags to set an instance's environment. My Runbook determines an instance's environment, checks for a corresponding SSM Parameter Path, then installs and configures the Agent. When I previously tried with an SM Association, applied to all instances, it didn't execute when an instance environment tag changed or was created. I settled on an EventBridge aws.tag rule to trigger. I manually execute the Runbook on affected Resource Groups, however, when a config is updated or newly created.
You can invoke an association synchronously and on demand by calling the StartAssociationsOnce action, also available from the CLI. Have you tried that already? You can tie that to an EventBridge event via a Lambda function as well.
Yes, but if your automation is idempotent -- as any well-written automation should be -- it shouldn't adversely impact any of your existing instances.
That's true, but my other goal here is to limit the number of executions. My current approach, for example managing X number of instances and using a 10 step automation, would execute 10 steps each time a tag changed. If run on all instances, it becomes 10*X steps each time a tag changes. It also, I'm afraid, doesn't solve my original problem as it appears State Manager Association also attempts to invoke the Runbook on stopped instances