---
title: "Configure Managed Cloud"
slug: "configure-managed-cloud"
abstract: "Learn how to configure your Managed Cloud solution to best suit the needs of your organization."
---
# Configure Managed Cloud

This topic describes how to scale, size, and tune your Managed Cloud container solutions. It describes how to find and work with the configuration files in the infrastructure and application repositories.

<details>
<summary><h2>Manage the size of Azure components</h2></summary>

You might want to customize your Azure Kubernetes Service (AKS) cluster size, SQL database, and/or Azure Container Registry (ACR) tier size.

To manage the size of Azure components:

1. In the Infrastructure repository, go to: `.\config\resources\resources.json`

    ![resources.json example](https://doc.sitecore.com/api/markdown-image/xp/en/developers/101/managed-cloud/images/MCC-scale.png)

2. Manage the AKS cluster size, SQL database, and/or ACR tier size by updating the following parameters:

    | Parameter | Description |
    | --- | --- |
    | windows_vm_size | The Windows VM AKS size. |
    | windows_scaled_vm_size | The Windows Scaled VM Size. Used for more efficient scaling of Content Delivery and XDBCollection pods. |
    | windows_node_count | The amount of Windows nodes. A minimum of two windows nodes is required to support in-place node upgrades. |
    | windows_scaled_node_count | The amount of Windows nodes for scaled resources. Could be set to 0 for some SKU tiers. If the value is *0*, scaled pods (cd and xdb collection) are deployed to regular Windows VMs. |
    | linux_node_count | The amount of Linux nodes. |
    | windows_node_priority | The node priority for Windows. For production scenarios always use `regular`. |
    | size_gb | SQL pool size in Gb. |
    | sku_capacity | SQL pool SKU capacity. |
    | sku_name | SQL pool SKU name. |
    | sku_family | SQL pool SKU family. |
    | sku_tier | SQL pool SKU tier. |
    | sku | ACR tier size. |

</details>

<details>
<summary><h2>Schedule maintenance windows for AKS</h2></summary>

You can use [Planned Maintenance](https://docs.microsoft.com/en-us/azure/aks/planned-maintenance) to schedule maintenance windows for your AKS cluster. Planned Maintenance lets you schedule weekly maintenance windows and minimizes workload impact. Once scheduled, all your maintenance will occur during the window you selected.

To add a maintenance window:

- In Azure CLI, add the `az aks maintenanceconfiguration` command:

    ```text
    az aks maintenanceconfiguration add -g MyResourceGroup --cluster-name myAKSCluster --name default --weekday Monday  --start-hour 1
    ```

</details>

<details>
<summary><h2>Tune limits for AKS pods</h2></summary>

You can manage the limits of every Sitecore deployment pod in the AKS cluster.

To tune limits for AKS pods:

1. In the Application repository, open `.\config\resources\resources.json`. You can see the list of all pods running in the AKS cluster. For example:

    ![Pods in resources.json example](https://doc.sitecore.com/api/markdown-image/xp/en/developers/101/managed-cloud/images/MCC-tune-limits-aks-pods.png)

2. Tune the pods by updating the following parameters:

    | Parameter | Description |
    | --- | --- |
    | replicas | The number of Sitecore replicas. |
    | request_memory | The default pod memory. |
    | request_cpu | The default pod CPU. |
    | limit_memory | The maximum pod memory limit. |
    | limit_cpu | The maximum pod CPU limit. |

</details>

<details>
<summary><h2>Use regular Virtual Machines for nonproduction environments</h2></summary>

By default, for nonproduction environments, Azure Kubernetes Service uses the *Regular* instance type of Virtual Machines. If you think the Regular instance is not appropriate for your nonproduction setup, you must switch the Windows node type to *Spot*. They are cheaper than regular Virtual Machines and can be evicted at any time. This makes Spot instances ideal for nonproduction test environments, but not so much for production.

To switch the Windows node type from *Regular* to *Spot*:

- Go to `config/resources/resources.json` and change the `windows_node_priority` to *Spot*.

    ![Windows node priority in resources.json](https://doc.sitecore.com/api/markdown-image/xp/en/developers/101/managed-cloud/images/MCC-Spot.png)

</details>

<details>
<summary><h2>Add a custom image</h2></summary>

To store custom images, Sitecore uses Private Azure Container Registry (ACR). Private ACR is created as part of Sitecore Managed Cloud Infrastructure.

To add an image to Private ACR:

1. Build a new version of an image based on an existing Sitecore image.
2. Push your image to Private ACR.
3. Update the `docker-images.json` file with the new image.

    > [!important]
    > To change `docker-images.json`, you must [create a pull request](https://doc.sitecore.com/xp/en/developers/101/managed-cloud/trigger-the-infrastructure-and-application-pipelines-automatically.html "Trigger the Infrastructure and Application pipelines automatically") to main.

</details>

<details>
<summary><h2>Update external images</h2></summary>

To update external images:

- Update `docker-images.json` with a new image version.

The application pipeline runs automatically and applies new images from the file as soon as the main branch is updated.

</details>

<details>
<summary><h2>Deploy new images by running the Application pipeline</h2></summary>

The Application pipeline uses a set of images to deploy the Sitecore environment. All image names and locations are specified in the `Application` repository `.\config\docker-images\docker-images.json` file. Sitecore uses Ansible to deploy your Docker container images. To deploy, Ansible gathers the images from the `docker-images.json` file located here:

`application\config\docker-images.json`

This file contains a list of images that are required to deploy the Sitecore application.

The `docker-images.json` file has the following structure:

```csharp
{
  ...
  "sitecore": {
    "sitecore role name": "{image repository}/{role name}:{image tag}"
  }
  ...
  "entity name": {
     "image name": "{image repository}/{role name}:{image tag}"
   }
  ...
}

```

To update Sitecore images:

- Go to `application\config\` and open the `docker-images.json` file. You can replace existing roles with your custom images based on existing base Sitecore images.

</details>

<details>
<summary><h2>Add a new infrastructure module</h2></summary>

You can create new resources in Azure by adding custom infrastructure modules. To add an infrastructure module, you must create a new Terraform module - a set of terraform configuration files in a single directory.

To add a new infrastructure module:

This example deploys the Azure Log Analytics workspace module. You can use a similar procedure to deploy any Azure resource.

1. Go to the Infrastructure repository and create a new folder for the module, for example: `.\modules\log-analytics-workspace`.
2. In the new folder, create `main.tf` with a resource description and the module name:

    ```csharp
    resource "azurerm_log_analytics_workspace" "alaw" {
      name                = var.alaw_name
      location            = var.location
      resource_group_name = var.resource_group_name
      sku                 = var.sku
      retention_in_days   = var.retention_in_days
    }
    ```

3. In the new folder, create `variables.tf` with a variables list:

    ```csharp
    variable "location" {
      type = string
    }

    variable "resource_group_name" {
      type = string
    }

    variable "alaw_name" {
      type = string
    }

    variable "sku" {
      type = string
      default = "PerGB2018"
    }

    variable "retention_in_days" {
      type = string
      default = 30
    }
    ```

4. In the root folder, edit the original `.\main.tf` and add the new module and pass the desired variable values:

    ```csharp
    Module "alaw" {
      count               = 1
      source              = "./modules/log-analytics-workspace"
      location            = local.location
      resource_group_name = var.resource_group_name
      alaw_name           = "${local.infrastructure_id}alaw"
    }
    ```

5. Complete the pull request and the `Infrastructure` pipeline is executed automatically and the changes are applied.

    Alternatively, you can run the `Infrastructure` pipeline from the branch - this will not apply the changes and will only show the planned changes.

</details>

<details>
<summary><h2>Change the Sitecore topology size</h2></summary>

By default, all parameters are configured based on the original Sitecore topology size. In the `.\sku\` folder, there are sets of predefined Sitecore topology sizes. You can use these configuration files to scale topology sizes.

As soon as you commit changes to the main branch, the `Infrastructure` or `Application` pipeline is triggered automatically and applies changes from the file. If you must apply a new topology size, make the relevant changes in the Infrastructure repository first. Wait until the Infrastructure pipeline is completed successfully and then apply the necessary changes to the Application repository.`.\config\resources\resources.json`

To change the topology size:

- In the Infrastructure repository, copy `.\sku\resources.{size}.json` and rename the file to `resources.json`.

</details>

<details>
<summary><h2>Change Sitecore administrator credentials</h2></summary>

Before you deploy your Sitecore installation, you must [change the administrator password to a strong password](https://doc.sitecore.com/xp/en/developers/101/platform-administration-and-architecture/change-the-administrator-password.html). After you change these credentials, you must update the following secrets in the Azure Key Vault:

- Sitecore administrator username: `sitecore-admin-username`
- Sitecore administrator password: `sitecore-admin-password`

</details>