Question

A security team operates a dedicated security-tooling account within an AWS Organization. When GuardDuty detects a compromised EC2 instance in any member (workload) account, an EventBridge rule in the security account must trigger a Systems Manager Automation runbook that tags the instance, detaches it from its Auto Scaling group, and applies an isolation security group — all executed against the affected member account. The team wants a scalable, least-privilege mechanism that avoids storing long-term credentials for each member account. Which approach best enables the Automation runbook to perform these actions in the member accounts?

Accepted Answer

Use Systems Manager Automation with the AutomationAssumeRole configured to assume a dedicated cross-account IAM role in each member account that has only the required EC2, Auto Scaling, and tagging permissions, and establish a trust relationship allowing the security account's automation role to assume it.

Answer

Create an IAM user in each member account with programmatic access keys scoped to the required actions, store the keys in Secrets Manager in the security account, and have the runbook retrieve them at execution time.

Answer

Attach an IAM role to the compromised EC2 instance in the member account granting full EC2 and Auto Scaling permissions, and have the runbook run on the instance itself via SSM Agent.

Answer

Enable AWS Resource Access Manager (RAM) to share the security account's Automation runbook with member accounts, then invoke it locally with the member account's default service-linked role.