How do you decide what belongs in an Azure Resource Group?

One of the Azure design decisions that looks simple at first but becomes surprisingly important in production is how we structure Resource Groups.

The common approach is to group related Azure resources together. But in enterprise environments, I have found that a more useful question is:

Should a Resource Group represent technology, application, workload ownership, or resource lifecycle?

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

Would you put everything into one Resource Group?

Or would you separate shared infrastructure from workload-specific resources?

In my experience, ownership, lifecycle and operational responsibility are often better boundaries than simply grouping resources by Azure service type.

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

Are Azure Resource Groups Just Folders?

The article covers workload-based Resource Group design, environment boundaries, shared infrastructure, RBAC and some production lessons learned.

I would be interested to hear how others approach Resource Group design in production Azure environments.

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