This is the third post in our AWS DevOps Agent series.
Most real applications don't live in a single AWS account — a service might run in one account while its data layer, shared networking, or a sibling microservice sits in another. If AWS DevOps Agent can only see the account it's deployed in, every investigation touching a resource outside that boundary hits a blind spot. Cross-account monitoring closes that gap, letting one Agent Space see across your entire application footprint instead of just its home account.
Prerequisites
Before adding a secondary account, make sure you have:
- Access to the AWS DevOps Agent console in the primary account
- IAM permissions to create roles in the secondary account
IAM Policies Behind Cross-Account Access
Every secondary account connection rests on three separate policy components, and understanding what each one does makes the setup steps below a lot less mechanical:
- Trust policy — lets the AWS DevOps Agent service principal (aidevops.amazonaws.com) assume the role directly. It includes
aws:SourceAccountandaws:SourceArnconditions specifically for confused deputy prevention — a security control ensuring only your Agent Space in the primary account can use this trust relationship, not any other AWS DevOps Agent deployment anywhere else. -
AIDevOpsAgentAccessPolicy— an AWS-managed policy providing the core read-only permissions the agent needs to investigate resources. AWS maintains and updates this as new capabilities ship. - Inline policy — generated from your specific Agent Space configuration, covering permissions tied to whichever integrations or features you've enabled.
Setting It Up via the Console
Step 1 : Go to respective agent space -> Add Secondary Account -> Select AWS Account
Step 2 : In this we need create IAM roles in secondary account, which will have trust policy from primary account and agent space. Adding account will give you below wizard.
Step 3 :Create the role in the secondary account. In a new browser tab, sign into the secondary account's IAM console → Roles → Create role → Custom trust policy, and paste in the trust policy from Step 2.
Step 4 — Attach the AWS managed policy. Search for and select AIDevOpsAgentAccessPolicy.
Step 5 — Name and create the role. Use the same name you specified in Step 2, add an optional description, and create it.
Step 6 — Attach the inline policy. On the new role's Permissions tab, choose Add permissions → Create inline policy, switch to the JSON tab, and paste the policy the console gave you alongside the trust policy. Name it something identifiable (e.g. DevOpsAgentInlinePolicy) and create it.
Step 7 — Complete the configuration. Back in the primary account's AWS DevOps Agent console, choose Next and confirm the connection status shows Active.
Demo: Seeing Cross-Account Value in Action
The best way to feel why cross-account monitoring matters isn't reading about it — it's watching an investigation hit a wall without it, then watching it succeed with it.
The setup:
- Account A (primary, where your Agent Space lives) — a Lambda function and a CloudWatch alarm on its Errors metric
- Account B (secondary, connected per the steps above) — a DynamoDB table with a resource-based policy granting Account A's Lambda role write access
For demo purpose, I deliberatly modify resource policy on dynamodb, from PutItem to GetItem, this introduce lambda errors.
I have Cloudwatch alarm for lambda errors which gets triggers and corresponding devops agent lambda do API call in devops agent space.
In few minutes, devops agent suggest us root cause & remediation
And since I have connectivity with JIRA as well (previous blog), ticket got created in JIRA
I hope this blog gave you how we can do cross-account setup in DevOps agent.
Key Takeaways
- Cross-account monitoring exists because most real applications span more than one AWS account, and an agent that can't see the full picture investigates with blind spots.
- Access rests on three policies — a trust policy with confused-deputy prevention, the AWS-managed AIDevOpsAgentAccessPolicy, and an Agent-Space-specific inline policy.
- Removing a secondary account from the Agent Space doesn't delete its IAM role — budget that into your offboarding checklist.
Top comments (0)