Azure Cloud
The Azure Cloud connector reads the resource inventory of an Azure subscription (read-only, via a service principal you create) and maps it to your architecture model: the as-built view of what is actually running. See Connectors for the general workflow.
Prerequisites
Section titled “Prerequisites”You need an Entra ID app registration (service principal) with the Reader role on the subscription.
- In the Azure portal, go to Microsoft Entra ID → App registrations → New registration. Name it (e.g.
archngn-discovery) and register. No redirect URI is needed. - On the app’s Overview page, copy the Application (client) ID and the Directory (tenant) ID.
- Go to Certificates & secrets → Client secrets → New client secret. Copy the secret Value immediately. It is shown only once, and it is the Value you need, not the Secret ID.
- Grant the app read access to the subscription: Subscriptions → your subscription → Access control (IAM) → Add → Add role assignment. Choose the Reader role, then under Members select the app registration you created.
- Copy the Subscription ID from the subscription’s Overview page.
Configuration
Section titled “Configuration”| Field | Value |
|---|---|
| Subscription ID | From the subscription’s Overview page |
| Tenant ID | The Directory (tenant) ID from the app’s Overview page |
| Client ID | The Application (client) ID from the app’s Overview page |
| Secret Key | The client secret Value |
The Subscription, Tenant, and Client IDs are non-secret identifiers and stay in the connector configuration. The client secret is stored in an encrypted secrets store and never shown again. Client secrets expire. When yours does, create a new one in Certificates & secrets and enter it over the placeholder.
What a Run Produces
Section titled “What a Run Produces”The connector lists every resource group and resource in the subscription, enriched with Container Apps and App Service container images and Key Vault configuration references, all through the same read-only role. The AI then maps the inventory to your metamodel:
- Objects on the Technology and Data layers only: managed services become Technology Service, VMs/containers/serverless become Compute, networks and load balancers become Network, databases and storage become Data Store. Well-known resource types are classified deterministically from the resource ID.
- Associations backed by concrete evidence, including Configures edges from Key Vaults to the Container Apps that reference their secrets, and co-location within resource groups. No evidence, no edge.
- Cross-layer links: container images are captured from Container Apps and Web App for Containers so as-built objects can be linked (Deployed To) to the Application objects discovered by the GitHub connector.
Your Application and Business layers are never invented from infrastructure. The logical view comes from code and document sources and is linked to the as-built objects instead.
- Resources are grouped by resource group, which gives Azure estates a strong built-in co-location signal.
- AKS pod images live behind the Kubernetes API rather than Azure Resource Manager and are not captured.
- Re-runs are stable: resources are matched by resource ID, so renames update objects in place.
- Each subscription is its own estate. Same-named workloads in different clouds or subscriptions are kept as separate objects, never merged.