Why MCM Discovery
The problems with managing cloud resources individually and how MCM Discovery solves them.
Why MCM Discovery
Modern infrastructure is rarely confined to a single cloud. Teams run workloads across AWS and Azure, manage source code on GitHub, deploy containers via Docker, and operate bare-metal Ubuntu hosts — each with its own console, APIs, and tagging model. Keeping track of what exists, where it lives, and who owns it becomes a full-time job before any real work begins.
Challenges & How MCM Solves Them
Each challenge below is a real friction point teams face when managing infrastructure across multiple providers without a unified layer.
1. Fragmented Visibility
Each provider has its own console and SDK. Engineers must context-switch between the AWS Console, Azure Portal, GitHub, and Docker Hub just to answer "what do we have running right now?"
How MCM solves it: MCM Discovery provides a single screen to search, filter, and group resources across all accounts and providers. No console-switching required.
2. No Unified Inventory
EC2 instances, Azure VMs, S3 buckets, and GitHub repos are siloed in separate systems. There is no single place to search or filter across all of them.
How MCM solves it: Every resource — regardless of provider — is stored in the same normalised schema: ID, name, type, provider, account, region, status, tags, and provider-specific details. One inventory for everything.
3. Resource Sprawl
Forgotten or untagged resources accumulate across accounts and regions. Without a centralised view, it is easy to lose track of what is running and what is stale.
How MCM solves it: Discovery runs automatically on a configurable schedule, continuously refreshing the inventory. Stale and untagged resources surface in the same view as active ones — nothing is hidden.
4. Inconsistent Metadata
AWS, Azure, and GitHub each enforce different tag schemas. Maintaining consistent naming conventions or cost allocation tags across clouds requires manual discipline across every team.
How MCM solves it: MCM adds a custom tag layer on top of provider tags. Define organisation-wide tags (e.g. team, environment, cost-centre) once and apply them consistently across AWS and Azure regardless of each provider's native tag constraints.
5. Invisible Topology
The relationship between a VPC, its subnets, and the EC2 instances inside it is buried in nested console menus. Cross-cloud relationships are impossible to visualise.
How MCM solves it: Resource relationships (VPC → Subnet → EC2) are rendered as navigable topology graphs, making infrastructure layout immediately clear without digging through nested menus.
MCM vs Managing Clouds Individually
| Aspect | Individual Provider Consoles | MCM Discovery |
|---|---|---|
| Coverage | One cloud per view |      all in one view |
| Unified inventory | Not available | Single searchable inventory across all providers |
| Custom tags | Provider-native tags only | Provider tags + MCM-defined custom tags |
| Cross-cloud grouping | Not supported | Group by type, region, or tags across all clouds |
| Topology view | Requires manual console navigation | Visual graph of resource relationships |
| Inventory sync | Manual console refresh | Scheduled auto-discovery + on-demand trigger |
| Module integration | Provider ecosystem only | Feeds FinOps, SecOps, Governance, Orchestration, Observability |
| Unified search | Per-provider only | Search across all accounts and providers at once |
Features
| Feature | Description |
|---|---|
| Multi-provider support | Discover resources across AWS, Azure, GitHub, Docker Hub, Docker, and Ubuntu from a single platform |
| Multiple inventory views | Switch between Table, Topology, Grid, and Map views to explore your infrastructure |
| Advanced filtering | Filter by account, provider, region, resource type, status, and tags — including multi-select and tag key/value hierarchies |
| Resource detail inspection | Inspect any resource with dedicated tabs for Overview, Network, Storage, Metadata, and Custom Tags |
| Custom tag management | Define org-specific tags and apply them to resources across AWS and Azure |
| Resource grouping | Group the inventory by resource type, category, region, or custom tags |
| Scheduled and manual discovery | Set an auto-discovery interval or trigger a manual run at any time |
| Cross-module context | Each resource shows which MCM modules (FinOps, SecOps, Governance, Orchestration, Observability) can act on it |
Resources
MCM Discovery gives you a unified, always-current inventory of every resource across all connected providers and accounts. Rather than navigating each provider's console separately, you can work with all your infrastructure from a single screen.
All Resources
The All Resources view surfaces every discovered resource — EC2 instances, Azure VMs, S3 buckets, GitHub repositories, Docker images, Ubuntu hosts — in one place. Each resource entry shows its provider, account, region, type, status, and tags at a glance. Clicking any resource opens a detailed panel with tabs for Overview, Network, Storage, Metadata, and Custom Tags.
What you get: A complete picture of your infrastructure without opening a single cloud console. You can answer "what do we have and where is it?" in seconds rather than hours.
Multiple Filter Options
The inventory can be filtered by any combination of provider, account, region, resource type, status, and tag key/value pairs. Filters support multi-select, so you can simultaneously scope to AWS + Azure, two specific accounts, and a team=platform tag without multiple separate queries.
What you get: Instant ability to isolate exactly the slice of infrastructure you care about — whether that is all running EC2 instances in us-east-1, or every resource tagged to a specific team across all clouds.
Multiple Group By Options
Resources can be grouped by type, category, region, account, or any custom tag key. Grouping collapses the inventory into logical buckets — for example, group by environment tag to see how many resources exist in production versus staging, or group by region to understand geographic spread.
What you get: Structural insight into your inventory without writing any queries. You can spot imbalances, orphaned groups, or unexpected concentrations in your infrastructure at a glance.
Multiple View Options
Discovery provides four view modes for the same underlying inventory:
| View | Best For |
|---|---|
| Table | Bulk search, sorting, and export across all resources |
| Topology | Visualising relationships (VPC → Subnet → EC2) as a navigable graph |
| Grid | Card-based browsing when resource thumbnails are more useful than rows |
| Map | Geographic distribution of resources by region across the world map |
Switch views without leaving the page — filters and groupings carry across.
Custom Tags
Cloud providers each have their own tag constraints — AWS limits tag keys to 128 characters; Azure has different validation rules; GitHub has no native tagging at all. Maintaining a consistent team, environment, or cost-centre taxonomy across all providers requires a layer that sits above native tags.
MCM Custom Tags let you define organisation-specific tag keys and values once, then apply them to resources across AWS and Azure regardless of each provider's native tagging rules. Custom tags are stored in MCM alongside provider tags, so you can filter and group by them just like any native tag.
What you get: A single, consistent metadata layer across all providers. Your team=platform tag means the same thing whether it is on an EC2 instance or an Azure VM — no per-provider workarounds.
Execution History
Every discovery job — scheduled or manually triggered — is recorded in the execution history. Each entry shows the start time, duration, number of resources discovered, and any errors encountered during the run.
What you get: A full audit trail of when your inventory was last refreshed and whether the run succeeded. If a provider connection fails or credentials expire, the execution history surfaces the failure immediately so you can act before data goes stale.