AWS Services in CSDM

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
07-13-2022 12:09 PM
Hello Everyone, I'm having a hard time thinking through how to classify the AWS Services that my company supports within the CMDB. Below is what our cloud management team sent me as to how they group and support their services. I have turned this around in my head enough times that I could make a case for building it a few different ways. Does anyone have any thoughts on how they have seen this done at other orgs? We need these in the portfolio to be able to track some compliance related items on each individual service like if it has been approved for use through compliance, etc.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
07-16-2022 04:37 PM
We have a Service Graph connector for AWS that provides a comprehensive mapping of AWS types to CI's. Look at the published documentation and release notes for the details.
There is also an existing discovery pattern you should reference in DOCS and use too.
Both of these are updated periodically as new types of entities are created by the cloud providers.
If you are looking to create a logical grouping of these based on the deployment of an application, I would leverage the Application Service and TAG based mapping to relate the entities to the Application Service. This video explains the overarching process, and in this video Navin and I explain the different types of Application Services.

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
07-21-2022 09:47 AM
Super helpful information about how the discovery process populates data from AWS into our environment, but I don't think it meets what I am trying to do. What I am trying to represent is the support structure of these items. If this team supports all of these different items should I build Technical Services for each of these? Would the Technical Service Offerings be the things inside the CI Description Column?

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
07-25-2022 05:59 PM
If you haven't worked this out already....
Your inclination is mostly correct. The key piece, which you mentioned, is the Technical Service Offerings. I would probably group them into Technical Services differently.
For example, you could put EC2 in a TS named 'Virtual Compute' with VMware vCenter, and put AWS App runner and Batch into an 'Automation Services' TS.
The goal here is putting the TSOs into logical groupings (i.e. the same type of service, regardless of technology) vs by the group that supports / manages them. That information is managed at, and can be reported on, at the TSO level using the various 'Group' attributes. In addition the redundancy of managing your TSs at the support / management team level, you also run into a mess when one of the TSOs gets changed to a different support / management team.
Following the guidance above gives you an additional reporting option based on the type of Service that is provided without having to manually manage the filter criteria.
Steve
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
07-26-2022 08:56 PM
The support structure follows the typical Technical or Business Service / Offering as explained in this video to determine technical vs. business service. This video will help choose the Technical Service approach, as some AWS resources can be through a Dynamic CI Group instead of the Application Service. Establishing he Application Service is the critical part that will connect the AWS CI's to the specific support groups and commitments in the respective offerings.