How should Azure Resource Groups be structured for enterprise integration workloads?

When designing an enterprise integration platform in Azure, Resource Group structure can have a significant impact on ownership, lifecycle management, RBAC and operations.

Consider an integration platform containing:

For example, consider an integration platform containing API Management, Azure Functions, Service Bus, Key Vault and networking.

A simple approach is to group resources by Azure service type. But in production environments, I have found that a more useful question is:

Should Resource Groups primarily reflect technology, workload ownership, resource lifecycle, or operational responsibility?

For example, should all integration components belong to one Resource Group? Or should shared infrastructure and workload-specific resources have separate boundaries?

My view is that Resource Groups should primarily reflect ownership, lifecycle and operational responsibility rather than simply grouping resources by technology.

I recently explored this topic in the first article of a new series on Azure architecture:

Are Azure Resource Groups Just Folders?

The article discusses workload-based Resource Group design, environment boundaries, shared infrastructure and RBAC considerations.

I would be interested to hear how others structure Resource Groups for enterprise integration workloads in Azure.

Article: https://www.linkedin.com/pulse/azure-resource-groups-just-folders-chethan-raj-fakac