Cloud zones in Cloud Assembly are a method of partitioning the resources that cloud accounts provide to projects.

You create cloud zones to define a set of resources within a cloud account. Each cloud zone is associated with a Cloud Assembly project. Cloud zones can be shared across multiple groups of users and are not limited by a one-to-one relationship.

You can add or remove tags to filter the compute resources that are used in the cloud zone. For example, you can have multiple clusters within a VI workload domain provided by a vCenter Server cloud account. The clusters can serve different purposes for specific functional or non-functional constraints, or classifications.

Cloud zones do not control how CPU and memory are allocated during periods of resource contention based on workload classifications. This function can be performed by the use of vSphere resource pools on a vCenter Server cloud account. Activate vSphere resource pools with scalable shares to ensure resource availability when a workload domain is activated for vSphere with Tanzu or if workloads require fine-grained control of resources based on classifications during periods of resource contention.

Table 1. Resource Pools in a VI Workload Domain

Resource Pool



The resource pool created for the NSX Edge cluster components deployed on the first cluster in a VI workload domain. Objects in this resource pool can be moved to the parent or root resource pool if no other resource pools are required.


Do not place workloads in the resource pool created by the NSX Edge cluster automation.


The resource pool created in a VI workload domain when vSphere with Tanzu is activated. Additional nested resource pools are created for the workload management supervisor cluster and each namespace.


The resource pools created for statically or dynamically deployed virtual machines for organization workloads. These resource pools must be created alongside the sibling resource pools in vSphere clusters that are running NSX Edge clusters and vSphere with Tanzu.

By default, on vCenter Server-backed cloud zones, workloads are placed on random hosts. Optionally, one of the following placement policies can be applied to a cloud zone.

Table 2. Placement Policies for Cloud Assembly Cloud Zones




Uses random hosts for workload placement.


The most loaded host with enough resources to run the workload is selected for workload placement.


Evenly spreads workloads across hosts during workload placement.


Uses vRealize Operations recommendations, if integrated, for workload placement.

By default, workloads are placed in the default data center folder. Workload placement can be set by defining a relative path within the data center in the cloud template YAML.

For a vCenter Server cloud account, you can deploy the workload in an alternate folder. You can set the target folder with a cloud template expression that evaluates end-state values. For example, if you set the targetCloud value to vmc, the folderName property value is set to Workload. The else option can apply an alternative value to folderName - a blank value ("") or another input value ${input.myFolderName}. See the following sample YAML snippet for a cloud template:

    type: Cloud.vSphere.Machine
        image: ''${input.operatingSystem}''
        flavor: ''${input.nodeSize}''
        FolderName: ‘${input.targetCloud == “vmc” ? “Workload” : ${input.targetEnvironment}’
            - network: ''${}''
            - tag: ''${"cloud:" + to_lower(input.targetCloud)}'''

You can add capability tags to match cloud template constraints to a cloud zone. Capability tags are optional because the tags on compute resources, such as vSphere clusters and resource pools, are also used as capability tags for a cloud zone, for example, cloud:private, region:sfo, region:us-west-1, region:us-west-2, env:prod, env:dev, env:dmz.

Table 3. Design Decisions on Cloud Zones for Cloud Assembly in vRealize Automation

Decision ID

Design Decision

Design Justification

Design Implication


Create a cloud zone for each VI workload domain.

Provides provisioning on a specific workload domain.



Add tags to each cloud zone.

Ensures that deployments can be targeted for a designated cloud account region.

  • You must ensure that you manage the tagging of cloud zones.

  • You must ensure that constraint tags are included in the cloud template YAML if a cloud account region-specific targeting is required.


For each cluster added to a VI workload domain, add tags to the vSphere cluster.

  • Ensures that, as you add new vSphere clusters to a VI workload domain, you can dynamically include compute resources for workload provisioning by adding the appropriate tags.

  • Ensures that deployments can be targeted for designated clusters of the VI workload domain.

  • You must ensure that you manage the tagging of compute resources as you add clusters to a VI workload domain.

  • You must ensure that constraint tags are included in the cloud template YAML.

  • If resource pools must be activated in a VI workload domain, add tags only to the required resource pools in the VI workload domain clusters for cloud zones.


Add a workload folder in the vCenter Server data center for each VI workload domain.

Ensures that cloud templates that do not include the folderName value are deployed in a default workload folder.

  • You must add the default workload folder to all VI workload domains.

  • To override the default folder, you must add logic in your cloud template YAML code to deploy cloud templates in alternative folders.


The destination folder, where the cloud templates are deployed, must exist. The destination folder cannot be created by Cloud Assembly without extensibility.


Use the DEFAULT placement policy for each cloud zone, by default.

  • All vSphere clusters have the vSphere Distributed Resource Scheduler activated to optimize initial and ongoing workload placement within a cluster.

  • The ADVANCED option is supported only when vRealize Automation is integrated to vRealize Operations Manager and is monitoring the VI workload domain vCenter Server.

Does not provide advanced workload placement across cloud zones and the related cloud accounts.