Spoke Hub Model - Integration services

Question

Hi there,

I am going through Microsoft documentation and have some questions regarding the placement of services within the hub-and-spoke network model. Based on my understanding, the hub is the place for shared services such as DNS, Firewall, VPN, and other components. It is better to host integration services like APIM and Service Bus in a subscription within a spoke. Here are my arguments, and I would like to hear other experts' thoughts on this as well.

======
 with regard to the Microsoft spoke-hub reference architecture, Spoke Vnet is defined as below [2]:

"Spoke virtual networks isolate and manage workloads separately in each spoke. Each workload can include multiple tiers, with multiple subnets connected through Azure load balancers. Spokes can exist in different subscriptions and represent different environments, such as Production and Non-production."

With regards to the services that can be hosted in the hub, on the same page Microsoft states, "The hub virtual network hosts shared Azure services." The definition of shared services is not clarified clearly on this page, but in the reference architecture diagram of the same page, Azure Bastion, Firewall, and VPN Gateway are placed in the hub [2]. Moreover, later down the page, it provides some examples of shared services as " Shared services might include DNS IDs, Network Time Protocol (NTP), or Active Directory Domain Services (AD DS). Shared services are placed in the hub virtual network, and each environment deploys to a different spoke to maintain isolation."

Another Microsoft reference architecture diagram [4] shows Firewall and App Gateway hosted in the hub, which agrees with the earlier documentation. Later, on the same source (i.e. [4]), a few paragraphs below the diagram, Microsoft states:

"the hub often contains the common service components that the spokes consume. Examples of common central services are:

·         A DNS service resolves naming the workload in the spokes to access resources on-premises and on the internet if Azure DNS isn't used.

·         A __public key infrastructure i__mplements single sign-on for workloads.

·         TCP and UDP traffic flow is controlled between the spoke network zones and the internet.

·         Flow is controlled between the spokes and on-premises.

·         Flow is controlled between one spoke and another, if needed.

The role of each spoke can be to host different types of workloads. The spokes also provide a modular approach for repeatable deployments of the same workloads. Examples include dev/test, user acceptance testing, staging, and production.

 

The Application Gateway shown in the diagram above can live in spoke with the application it's serving for better management and scale. However, corporate policy might dictate you place the Application Gateway in the hub for centralized management and segregation of duty.

"

Moreover, in the Azure landing zone reference diagram [5], DNS, VPN, Firewall, and ExpressRoute gateways are hosted in the hub.

Based on Microsoft documentation [6 , 7], APIM, Service Bus, Function Apps, and a few others are referenced as integration services, and not shared services. Moreover, based on the integration services architecture [8], APIM, Service Bus, and other integration services are clearly hosted in the same subscription.

References:

1 https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/ready/azure-setup-guide/organize-resources

2 https://learn.microsoft.com/en-us/azure/architecture/networking/architecture/hub-spoke?tabs=cli

3 https://learn.microsoft.com/en-us/azure/architecture/

4 https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/ready/azure-best-practices/hub-spoke-network-topology

5 https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/ready/landing-zone/

6 https://learn.microsoft.com/en-us/azure/service-bus-messaging/service-bus-premium-messaging

7 https://learn.microsoft.com/en-us/azure/architecture/integration/integration-start-here

8 https://learn.microsoft.com/en-us/azure/architecture/example-scenario/integration/app-gateway-internal-api-management-function

Answer 1

Hi - this is a somewhat complex answer based on your infra architecture and requirements

Therefore I can only generalize (as I dont know those things)

APIM (Premium sku - which is currently the only sku supporting private in AND private out)

If you use a hub spoke model where the Firewall is used to control intra spoke (and intra network) traffic including n/s (internet) then it's common to deploy APIM to it's own spoke - along with an App GW if you need that to proxy internet ingress into APIM. Doing so allows you to "plug in" APIM through the Firewall which remains central to ensuring APIM can only reach the services it should reach and clients can only reach APIM , that should reach APIM. Consider also that APIM may not be operated by the same team that operates hub + networking services.

Service Bus

This doesnt live in your network at all, it's a externalized multitenant PaaS service.
In the premium sku publishers and subscribers can access via a private endpoint
Networking for Service Bus is always one way, client , be that publisher or subscriber, dials in. Service bus NEVER dials out. So then it's more a case of where you need your private endpoints - these tend to be deployed close to the app that needs the private endpoint. For example, if you have a web app which need to integrate with service bus and that is deployed in a spoke as a publisher into service bus (for example), then it makes sense for the private endpoint into service bus used by the web app to be in an adjacent subnet of the same spoke.
If the subscriber to those messages is a back office system which exists in another spoke, then it's private endpoint would also be in the same VNET

Logic Apps/Functions Apps

Logic Apps Standard , Web Apps and Function (premium) Apps all run on App Service plans . Logic App WS plans are a superset of Functions Elastic Premium Plans which are closely related to regular App Service Plans
With that in mind, App Service also exists outside of the vnet/spoke. You can deploy private endpoints for ingress into the App Service (or funcs/logic apps etc) and if you need to communicate with downstream depends on the network then you can utilise "regional vnet integration" for outbound traffic. In both cases it makes sense for the subnets required to be in the same vnet/spoke for the workload

Functions consumption and Logic Apps consumption cannot be linked to a virtual network.

---

Typically you would have a app/workload per env and it would generally make sense for these to be represented by different spokes (for isolation)