Best practices regarding organizing Logic Apps into resource groups

Question

In many situations, in the context of software development and building apps and services, various components (i.e. resources within Azure) related to a particular solution can be organised into some kind of a logical grouping. These are reflected in Azure as resource groups.

There are multiple heuristics one can use here, one obvious rule-of-thumb being that one puts such components into a single resource group which should be deployed simultaneously and form some type of an integrated solution - a functional "(sub)system" with its constituents sharing a lifecycle. The nature of ARM templates reflect this - a single template describes (the contents of) a single resource group.

Does this also apply to Logic Apps specifically? If not, what principles should one follow when making these decisions? In other words, do some best practices exist on how to organise LAs into resource groups?

Logic Apps are the sole iPaaS offering in Azure and advertised as such. Lots of experts in the field are familiar with on-premises integration products and bring in their own preconceived notions on how things are done here - in the context of these (largely, but not always) monolithic platforms.

In Azure, I have seen solutions where tens or hundreds of LAs are placed within a single RG (with an optional group for "shared" resources) - some of which are completely unrelated. And all the way from a single LA per group to attempts to create some type of a logical set of associated workflows. I'm sure no correct answer exists - but what would some of the guiding principles look like? Should LAs be treated differently than any other resource within Azure?

Answer 1

Personally, I would not treat them any different to other resources. Resource groups should be used to group resources logically, i.e. by application sharing a lifecycle so unrelated applications generally should have their resources placed in different resource groups.

The second reason is for access control. You may not want to give a particular user access to every logic app in a single resource group and trying to manage permissions by individual resources is far too difficult to maintain especially at a larger scale.