Nested templates are a relatively new feature in ARM templates compared to external linked templates.

Nested templates do not define resources in external files. The resources are defined within the caller template itself and within the deployments resource, as shown here:

"resources": [
  {
    "apiVersion": "2017-05-10",
    "name": "nestedTemplate",
    "type": "Microsoft.Resources/deployments",
    "properties": {
      "mode": "Incremental",
      "template": {
        "$schema": "https://schema.management.azure.com/schemas/2015-
              01-01/deploymentTemplate.json#",
        "contentVersion": "1.0.0.0",
        "resources": [
          {
            "type": "Microsoft.Storage/storageAccounts",
            "name": "[variables('storageName')]",
            "apiVersion": "2015-06-15",
            "location": "West US",
            "properties": {
              "accountType": "Standard_LRS"
            }
          }
        ]
      }
    }
  }
]

In this code segment, we can see that the storage account resource is nested within the original template as part of the deployments resource. Instead of using the templateLink and parametersLink attributes, a resources array is used to create multiple resources as part of a single deployment. The advantage of using a nested deployment is that resources within a parent can be used to reconfigure them by using their names. Usually, a resource with a name can exist only once within a template. Nested templates allow us to use them within the same template. Nested templates ensure that all templates are self-sufficient rather than storing them separately, and they might or might not be accessible to those external files.

Now that we understand the technology behind modular arm templates, however, how should we divide a large template into smaller templates?

There are multiple ways a large template can be decomposed into smaller templates. Microsoft recommends the following pattern for the decomposition of ARM templates:

When we decompose a large template into smaller templates, there is always a main template that is used for deploying the solution. This main or master template internally invokes other nested or linked templates and they, in turn, invoke other templates, and finally the templates containing Azure resources are deployed.

The main template can invoke a known configuration resource template, which in turn will invoke templates comprising Azure resources. The known configuration resource template is specific to a project or solution and they do not have much of reusable factor associated with them. The Member Resources templates are reusable templates invoked by the known configuration resources template.

Optionally, the master template can invoke shared resource templates and other resource templates if they exist.

It is important to understand known configurations. Templates can be authored as known configurations or as free-flow configurations.