Integration Platform: Architecture¶

This page describes the high-level design of the Integration Platform: the layers, the workloads and spokes, the environments, networking, identity, security and resilience. It is the reference design. Your deployment may differ in the number of environments, the shared services that are enabled and the options chosen. Ask your platform team.

Principles¶

The Integration Platform inherits the design principles of the MCP (Design principles) and adds four of its own.

Principle	Meaning
Cloud-first	Use cloud-native Azure services for scalability, reliability and cost efficiency.
Standardised yet extensible	Standard patterns remove infrastructure complexity and give reuse. When a new pattern appears, a new building block can be added in a controlled way.
Event-driven	Integrations respond in real time, scale independently and stay loosely coupled.
You build it, you run it	The team that builds an integration is accountable for it over its whole life: deployment, monitoring and remediation. Automation and DevOps practices support this.

Capabilities¶

The platform expresses its offer as technology-agnostic capabilities. The reference design maps each capability to ingredients. A capability may be required or not required by an organisation. What is required is a choice per platform.

Capability	What it covers	Typical ingredients
Message and event brokering	Asynchronous, event-based communication with ordering, delivery guarantees, deduplication	Service Bus, Event Hubs
API management	Develop, publish, secure, monitor and analyse APIs	API Management
Low-code modules	Integrations built with configuration, workflows and drag-and-drop	Logic App, Data Factory
High-code modules	Integration logic in a programming language, with the runtime and infrastructure provided	Function App, Container App
Triggers and jobs	Scheduled and event-triggered processing, batch jobs	Container jobs, Logic Apps, Data Factory
Infrastructure	Platform infrastructure and infrastructure for new integrations, including shared build runners	Spoke canvas, modules, container registry
Recipes and documentation	Guidance, examples and best practices for builders	Documentation generation
Provisioning and automation	Deployment pipeline templates, no manual infrastructure	Terraform modules, reusable workflow
Collaboration	Source code and automation in the repository platform, work items in a ticket tool	GitHub (reference design)

Further capabilities that a platform can add when there is a clear need: source system connections, document processing, an integration directory, AI augmentation and B2B integration (EDI, AS2). They are not part of the reference design.

Layers¶

The design separates what runs on what (ADR-010, ADR-011).

flowchart TB
    subgraph L3["Consumption"]
        iw["Integration workloads<br/>Logic Apps, Function Apps, Container Apps, Data Factory, API definitions"]
    end
    subgraph L2["Platform core"]
        ssw["Shared services workload<br/>Service Bus, Event Hubs, API Management, ACR"]
        cpw["Control plane workload<br/>configuration, access control, governance of the shared services"]
        cpw -->|"configures"| ssw
    end
    subgraph L1["Foundation: MCP"]
        hub["Hub: network, firewall, DNS, identity governance"]
        sp["Spokes (spoke canvas)"]
    end
    iw -->|"consumes"| ssw
    L2 -->|"runs on"| L1
    L3 -->|"runs on"| L1

Layer	Responsibility	Realised as
Foundation	Network, firewalling, DNS, identity governance, security boundaries ("the dial tone")	MCP hub and spokes. The platform does not build its own network backbone.
Platform core	The engines (shared services) and the control plane that manages their configuration and access	A shared services spoke, and a control plane deployment
Consumption	The integrations that builders create	Integration workload spokes

Splitting engine and control plane lets the control plane be redeployed or updated without affecting the uptime of the shared services. The price is coordination: both must agree on what is deployed, and traffic between them passes the hub firewall.

Workloads, spokes and environments¶

A workload consists of one or more environments, and each environment is a spoke, which is its own Azure subscription with the base infrastructure of the spoke canvas (What you get). Every spoke virtual network is peered with the hub.

Workload	Contains
Shared services workload	The enabled shared services. The base deployment contains only the Azure Container Registry, because the platform needs it to publish ingredients. Others are added when workloads need them.
Integration Platform workload	The enabled platform services. The base deployment contains DNS, for example for the name resolution of externally exposed APIs.
Integration workloads	The integrations. Each uses spoke extensions to connect to the shared services it needs, and modules to deploy its integration services.

flowchart TB
    hub["MCP hub: firewall, DNS"]
    subgraph prd["Production"]
        ssp["Shared services spoke (prod)"]
        ipp["Integration Platform spoke (prod)"]
        w1p["Integration workload spoke (prod)"]
    end
    subgraph nprd["Non-production"]
        ssn["Shared services spoke (non-prod)"]
        ipn["Integration Platform spoke (non-prod)"]
        w1n["Integration workload spoke (non-prod)"]
    end
    hub --- ssp & ipp & w1p
    hub --- ssn & ipn & w1n
    w1p -.->|"extension"| ssp
    w1n -.->|"extension"| ssn

Design choices of the reference design:

Two environments for the platform, production and non-production, so new versions of shared services can be tested outside production. More environments can be added, because a platform instance can be deployed again by automation. Cost and complexity are the reason to keep it at two.
Workloads follow their environment. Production workloads connect to the production platform, non-production workloads to the non-production platform. The number of spokes per workload is chosen per workload.
A resource that is cheap and holds no business data can be deployed once. An Azure Container Registry, for example, is typically deployed once for the whole landscape rather than per environment.
Connections are never implicit. Every connection between workloads, or to the outside, passes the hub firewall and needs a rule (Firewall rules and IP groups). An integration workload does not use a shared service by default. A workload may use none.
Integrations with on-premises systems pass the hub and its firewall. They are expected to be temporary in a migration.

How to cut a workload¶

An integration workload can be demarcated in several ways, alone or combined. Start with one or a few workloads and split them when needed.

Cut	Strength	Watch out for
Per team	Clear accountability and autonomy, fast decisions	Duplication when teams do not share knowledge
Per functional domain	Fits domain-driven design, reuse inside a domain	Coordination for cross-cutting concerns
Per system	Simple lifecycle, system-specific controls	Blurred ownership when several teams touch the system, hard for integrations that span systems
Per flow (everything between system A and B)	Traceability, isolation, simple troubleshooting	Many small workloads, operational overhead per flow

Networking¶

The Integration Platform applies the same segregation as the MCP. By default the hub firewall allows traffic within a spoke only. To allow traffic to or from a source or destination outside the spoke, you file a standard change with the platform team (Firewall rules and IP groups). Traffic to and from on-premises is blocked by default.

Shared services and modules use private networking by default. Azure offers three levels of isolation:

Level	What it does	Direction
VNet integration	The service sends outbound traffic into the VNet and peered VNets over the Azure backbone	Outbound
VNet injection (subnet delegation)	The service runs in a dedicated subnet with its own private IPs	Inbound and outbound
Private Link with private endpoints	The service gets a private IP in a subnet and its public access can be switched off	Inbound only

VNet injection is preferred when the service supports it, but it can cost more because of dedicated compute. Otherwise private endpoints are combined with VNet integration. API Management shows the difference: the Premium (classic) tier supports injection, Standard v2 only integration with private endpoints (Shared services).

Private endpoints in the platform need name resolution from your own networks too. The required DNS forwarding is on Private endpoint DNS. The MCP design is in DNS design.

If an API or endpoint must be reachable from the internet, put it behind the Application Gateway with WAF of the hub (Shared services). The hub provides DDoS protection on the Application Gateway public IP.

Identity and access¶

The Integration Platform follows the RBAC and PIM standards of the MCP (Identity and access model, Access, groups and PIM): least privilege and just-in-time.

On top of that, the platform uses two patterns, both described in Decisions:

Group-based access delegation (ADR-005). Resources never get role assignments for individual identities. Each permission (for example "send to queue X") is an Entra ID group. The workload team owns the membership and changes it without a pipeline run.
Administrative units (ADR-004). The automation that creates groups is limited to an Entra ID administrative unit. A compromised automation identity cannot change groups outside it.

Spoke extensions create the base groups and role assignments per spoke. Read what an extension creates in Spoke extensions.

Security¶

Topic	Reference design
Policies	No policies besides those of the MCP. Optional extra policies can be added, enforced and remediated later. A workload or spoke can, for example, switch on a regulatory policy initiative on its own subscription.
Defender for Cloud	The platform's plans plus Defender for APIs on the integration subscriptions. Cost is part of the subscription cost. Note that Defender for APIs is not available for workspace APIs in API Management.
Encryption in transit and at rest	MCP standards. Customer-managed keys where a shared service supports it.
IP allow lists	API Management can restrict callers by IP address. Recommended for well-known internet-hosted systems.
Scope of the platform	The platform manages the management plane (resources and RBAC). Data-plane actions and data-plane RBAC of the deployed resources are the responsibility of the workload owner.

Delivery of the platform and of ingredients¶

The platform is deployed and managed from the repository platform with pipelines. All deployment logic, environment parameters and automation scripts are code, so deployments are repeatable and auditable. The platform is bootstrapped by predefined workflows that deploy the core components, such as the shared services.

Integration spokes are deployed by the platform team through the normal spoke pipeline: first a regular spoke, optionally extended with spoke extensions that give the spoke access to the shared services (Spoke extensions). After that, builders can start.

Publishing and using an ingredient:

flowchart LR
    pe["Integration platform engineer<br/>adds or updates ingredient code"] --> build["Build automation<br/>creates a package"]
    build --> reg["Container registry<br/>(shared service)"]
    ib["Integration builder<br/>references the ingredient, sets parameters"] --> tpl["Build templates of the platform"]
    reg --> tpl
    tpl --> spoke["Deploy into the workload spoke(s)"]

Access to the registry is protected with Entra ID.

Resilience¶

Topic	Reference design
Region	One region. Availability zones spread the services over data centres, which protects against a data centre outage but not against a regional outage.
Disaster recovery	Follows the MCP. The platform and shared services can be deployed again in another region within hours, in line with a recovery time objective of 24 hours and a recovery point objective of 48 hours. Both values are set per platform.
Workloads	A workload that only uses shared services and modules of the platform can also be redeployed in another region, because the modules accept a location. Other resources are the workload team's responsibility.
Availability	Depends on the configuration: for example the replica count of a Container App or the number of instances of a Logic App plan. Service-level agreements of Azure services are not the same as the availability objectives you promise to your consumers.
Configuration	The platform configuration is code in a Git repository.

More detail, dependencies and composite availability per integration pattern: Availability.

Monitoring¶

Logging extends the logging of the MCP.

Integration Platform spoke: no extra alert rules besides those of the MCP. The team can add custom rules.
Shared services: may add logging of their own. The API Management shared service, for example, deploys an Application Insights resource connected to the Log Analytics workspace of its spoke.
Modules: send logs to the Log Analytics workspace of the spoke, in some cases through an Application Insights resource. They may add an action group and alert rules. Some require the workload team to implement extra items (Modules).