Improving Cloud Resource Integration in Compass for Better Visibility in Jira Service Management

[Darryl H]

I've been exploring ways to better integrate "Cloud Resources" into our architecture using Compass, particularly with a focus on AWS Accounts. I believe that having cloud resources show up as "services" in Compass could significantly enhance our visibility into interdependencies.

For example, we could define each cloud resource (like AWS S3, AWS RDS, VPCs, etc.) as a component within Compass, explicitly associating it with the specific AWS Account it belongs to. This would allow us to track which services are dependent on particular cloud resources and across which AWS Accounts, thereby giving us a clearer picture of our architecture.

Currently, I'm having to switch all items like AWS accounts, VPCs, and other cloud resources that were imported as "Cloud Resource" components into "Service" components to make them show in Jira Service Management, especially when they are required for a change request or incident. This additional step can be cumbersome and seems to be a workaround rather than a seamless integration.

Is there a recommended approach for bringing AWS Accounts and cloud resources into Compass as first-class "Service" components, and if not, could this be a potential area for improvement? How might we enhance Compass to support these use cases more effectively and improve integration with Jira Service Management?

[Jason U]

Hi Darryl 👋

That’s a very thoughtful observation — and you’re absolutely right that the current Compass → JSM relationship around Cloud Resource components still requires some manual bridging.

1. Current behavior (by design)

At the moment, Compass treats Cloud Resources (like AWS S3, EC2, VPCs, etc.) as “component types” rather than first-class “Service” components.
That’s why they don’t automatically appear inside Jira Service Management — JSM only pulls data from Services in Compass when linking for incidents, requests, or CMDB visibility.

So, your manual conversion step (Cloud Resource → Service) is indeed expected behavior right now.

2. Why this matters

The “Service” entity in Compass is intentionally designed to represent a user-facing or operationally owned system, while Cloud Resources are considered infrastructure dependencies.
This means Compass sees S3/VPC/etc. as supporting components, not primary “services” — hence why JSM ignores them by default when showing “linked services”.

That said, your use case (AWS account visibility in JSM for change management or incident impact) is 100% valid and aligns with several community requests.

3. Possible workarounds

Until a native integration improves this behavior, you can streamline the workflow in a few ways:

Option A – Use Compass REST API or Forge automation

You can automatically promote certain Cloud Resource components to Service status by:

• Using the Compass GraphQL API to duplicate/mirror Cloud Resource metadata into Service components when specific tags or ownership rules apply.
• Or building a small Forge automation that triggers on component creation with type = "Cloud Resource" → converts or links it to a Service-type component.

Option B – Create dependency visibility in JSM

If your goal is visibility in JSM (not duplication):

• Use Jira Assets (CMDB) to import Cloud Resources from Compass via API.
• Map them as “infrastructure dependencies” and link them to their parent Services.
  This gives you impact mapping in JSM without reclassifying all components.

Option C – Request enhancement

There’s an open feature idea around this already in the Atlassian ecosystem:

“Allow Compass Cloud Resources to sync with JSM Assets or Service Registry automatically.”
You can follow or upvote it in Compass Product Feedback.

4. Summary

• Current behavior = by design (Services sync, Cloud Resources don’t).
• Workaround = API or automation to sync Cloud Resources as Services.
• Recommended enhancement = direct visibility of Cloud Resources in JSM Assets or Service Registry.

Your suggestion — treating Cloud Resources as first-class “Service” components — actually fits perfectly with the direction Compass is evolving (service dependency mapping, observability linkage, etc.).