Shared Services of the Integration Platform¶
The Integration Platform offers four shared services next to your spoke: Service Bus, Event Hubs, API Management and a container registry. A shared service is costly or commonly used integration infrastructure that serves several workloads, with its own lifecycle, owned by the platform team. This page describes what is specific to integration for each service. The generic mechanics are in the MCP documentation: how a spoke connects to a shared service (Shared services) and what each spoke extension creates (Spoke extensions).
Optional, set per platform
Which shared services exist on your platform, in which environments and in which configuration, differs per platform. Two of the designs below (API Management and Event Hubs) are marked Proposed in the decision records: they describe the intended offer, not necessarily what is running. Ask your platform team.
Overview¶
| Service | What it is for | Connection to your spoke | Detail |
|---|---|---|---|
| Service Bus | Enterprise messaging with queues and topics | extensions.servicebus and the JSON automation |
Service Bus |
| Event Hubs | High-volume event streaming | extensions.eventhub (an event hub of your own in the shared namespace) |
Event Hubs |
| API Management | One gateway to publish and secure APIs | extensions.apim, then APIOps |
API Management |
| Container registry | Private container images, also holds published platform ingredients | extensions.acr |
Container registry |
Enabling an extension is a standard change: the platform team sets enabled to true for it in your spoke file, and it takes
effect at the next spoke deployment (Spoke JSON).
All traffic between your spoke and a shared service passes the hub firewall and needs a rule where it is not already allowed. The shared services are reachable by private endpoint only (Architecture).
Which messaging service?¶
The platform offers both services, because they solve different problems.
| Event Hubs | Service Bus | |
|---|---|---|
| Pattern | Event streaming (a series of events) | Enterprise messaging (discrete messages) |
| Typical use | Telemetry, log aggregation, data pipelines, Kafka workloads, replay | Orders, commands, request-reply, sessions, transactions |
| Consumers | Partitioned consumers, several readers | Competing consumers, one reader per message |
| Ordering | Per partition | Strict order with sessions |
| Retention | Events can be replayed | Stored until consumed |
| Protocols | AMQP, Kafka, HTTPS | AMQP, HTTPS |
| Failed messages | Not designed for dead-letter handling | Dead-letter queues, deferral, scheduled delivery |
Choose Service Bus when delivery guarantees and error handling matter. Choose Event Hubs for volume and replay.
Container registry¶
A shared Azure Container Registry holds private images for custom integrations and the packages of the platform's published ingredients. It is the one shared service in the base deployment of the shared services spoke, because the platform itself needs it.
- Access. Workload deployment identities push and pull. The extension gives your spoke two groups and two managed identities, one to pull and one to push (Shared services). Access is Entra ID only. Do not use admin keys.
- Deleting images is reserved for the platform team, so teams cannot delete each other's images.
- Use by modules. A Container App module pulls its images with a managed identity that you name (Modules).
- Deployment. The reference design deploys one registry for the whole landscape, because a registry is not expensive and holds no business data.
- Availability. In the reference analysis the registry has zone redundancy switched off, and Container Apps depend on it to pull images. The analysis recommends enabling it (Availability).
Event Hubs¶
Status: proposed
The decision record is in the Proposed state (ADR-016).
The design offers Azure Event Hubs as a shared service, instead of an Event Hubs namespace per workload, to centralise streaming infrastructure and limit cost.
| Topic | Proposed design |
|---|---|
| Tier | Premium. It supports private endpoints, isolates resources between tenants, supports customer-managed keys and runtime audit logs, includes capture, allows partitions to be increased after creation, and keeps events up to 90 days. Scales in processing units (1 to 16). |
| Why not Standard | No resource isolation, shorter retention, no customer-managed keys, capture billed separately, no dynamic partitions |
| Why not Dedicated | Higher minimum cost and less elasticity. To be considered when sustained throughput passes what Premium supports. |
| Networking | Private endpoints, public network access off |
| Availability | Availability zones are used automatically in the supported tiers |
| Your access | Through extensions.eventhub: an event hub of your own in the shared namespace. The extension gives your Owners, Contributors and Readers groups the roles listed in What each extension creates. |
API Management¶
Status: proposed
The decision record is in the Proposed state (ADR-015). Monitoring and hostname configuration are not yet described in it.
A shared API Management instance centralises APIs for the organisation: one gateway, consistent authentication, versioning and lifecycle, a developer portal, monitoring, rate limiting and transformation. It is cheaper than an instance per workload.
Two offers¶
| Premium (classic) | Standard v2 | |
|---|---|---|
| Network isolation | Full: VNet injection, nothing exposed directly | Reduced: private endpoints and VNet integration, public access off. The management plane and developer portal stay publicly reachable (with authentication). |
| Internet exposure | Through Application Gateway with WAF | Through Application Gateway with WAF |
| Availability | Zones, optional multi-region. 99.95% in one region, 99.99% in multi-region | One region, one zone. 99.95% |
| Scale | 1 to 99 units (by decision record) | 1 to 10 units |
| Cost | Higher | Lower |
The decision record recommends Standard v2 with private endpoints for most enterprise scenarios, and Premium when complete network isolation is a (regulatory) requirement or zone redundancy is needed. Use the Developer tier of the classic family for non-production only when you accept its limits. Zone failures cause a full outage on a single-zone setup. Where the platform runs in one region, a redeployment through APIOps and infrastructure as code can meet the recovery objectives.
Do not expose API Management directly to the internet. Publish it through the Application Gateway with WAF. When workspaces are off and Defender for Cloud is used, Defender for APIs can protect the APIs.
Isolation between workloads: central or workspaces¶
| Model | How isolation works | When |
|---|---|---|
| Central (default) | One instance. Separate APIs by products and subscriptions, and by Azure RBAC with custom roles. Tags and naming help. | One team manages all APIs (central operating model) |
| Workspaces (opt-in) | A workspace per workload that exposes APIs. Teams manage their own APIs, products and subscriptions inside it. | Decentral model, when the workspace limits are acceptable |
Workspaces on the shared gateway come with limits: no managed-identity authentication policy, no Key Vault integration for workspace secrets, no GraphQL resolvers or validation, no authorization-context policies, aggregated metrics only (not per workspace), no workspace-specific analytics, no Defender for APIs, and shared compute with the main service. The number of workspaces is limited per tier (up to 30 on Premium, 5 on Standard, 1 on Basic and Developer). Dedicated workspace gateways are not supported in the offer, and neither are self-hosted gateways. The managed gateway is the default.
The spoke extension reflects this choice: in the central model your groups get roles on the whole instance, in the decentral model on a workspace of your own (What each extension creates).
APIOps¶
Workload teams maintain their APIs in Git: OpenAPI specifications, policies, products, named values and configuration templates for several environments, deployed through the pipeline. This is the GitOps idea applied to APIs. Do not commit subscription keys; reference Key Vault secrets (Shared services).
Scaling and policies¶
- Scaling is manual. The integration platform engineers watch the load and change the number of scale units, then redeploy the shared service. Scaling does not cause downtime for the gateway or the developer portal.
- Two optional policies are foreseen: only centralised API Management (workloads may not deploy their own) and no publicly available API Management (public access cannot be enabled).