Appendix: Design Decisions on Private Cloud Automation for VMware Cloud Foundation

The design decisions determine the deployment configuration, resource sizing, and automation support of VMware Aria Automation in the SDDC.

Deployment Specification

Table 1. Design Decisions on Deployment of VMware Aria Automation

Decision ID	Design Decision	Design Justification	Design Implication
PCA-VAA-CFG-001	Deploy VMware Aria Automation as a cluster of three nodes in the default management vSphere cluster.	VMware Aria Automation can manage one or more VMware Cloud Foundation instances from a single implementation. The VMware Aria Automation deployment can also manage VMware Cloud on AWS and public cloud instances, if network access is permitted.	You must deploy the clustered Workspace ONE Access nodes as medium-size appliances to support the scalability of the VMware Aria Automation cluster deployment.​ You must maintainVMware Aria Automation within its scalability and concurrency maximums.
PCA-VAA-CFG-002	Deploy VMware Aria Automation in a VMware Aria Suite Lifecycle logical environment in VMware Cloud Foundation mode.	The VMware Aria Automation cluster is added to the SDDC Manager inventory for life cycle management. SDDC Manager automates the configuration of the NSX load balancer on a dedicated NSX Tier-1 gateway in the management domain to load balance the connections across the VMware Aria Automation cluster nodes.	You must deploy VMware Aria Automation in a cluster configuration. You must use NSX for VMware Aria Automation cluster load-balancing services. Only a single VMware Aria Automation deployment can be deployed in VMware Cloud Foundation mode and imported into the SDDC Manager inventory.
PCA-VAA-CFG-003	Protect the VMware Aria Automation cluster virtual machines by using vSphere High Availability.	Supports the availability objectives for VMware Aria Automation without requiring manual intervention during an ESXi host failure event.	None.
PCA-VAA-CFG-004	Apply vSphere Distributed Resource Scheduler anti-affinity rules for the VMware Aria Automation cluster virtual machines.	vSphere Distributed Resource Scheduler prevents the VMware Aria Automation cluster virtual machines from residing on the same ESXi host and risking the high availability of the deployment.	You must perform an additional configuration to set up an anti-affinity rule. For a default management vSphere cluster that consists of four ESXi hosts, you can put in maintenance mode only a single ESXi host at a time.
PCA-VAA-CFG-005	Add a VM group for the VMware Aria Automation cluster virtual machines and set a VM rule to restart the Workspace ONE Access VM group before the VMware Aria Automation VM group.	You can define the startup order of virtual machines regarding the service dependency. The startup order ensures that vSphere High Availability powers on the virtual machines for VMware Aria Automation in an order that respects product dependencies.	You must manage the VM group and VM rules for the VMware Aria Automation cluster virtual machines.
PCA-VAA-CFG-006	Place the VMware Aria Automation cluster virtual machines in a designated virtual machine folder.	Provides the organization of the VMware Aria Automation cluster virtual machines in the management domain vSphere inventory.	You must create the virtual machine folder during or after the deployment.

Table 2. Design Decisions on Deployment of VMware Aria Automation in Multiple Availability Zones

Decision ID	Design Decision	Design Justification	Design Implication
PCA-VAA-CFG-007	When using two availability zones, add the VMware Aria Automation cluster virtual machines to the VM group for the first availability zone.	Ensures that, by default, the VMware Aria Automation cluster virtual machines are powered on in the primary availability zone hosts group.	After the implementation of the second availability zone for the management domain, you must update the VM group for the primary availability zone virtual machines to include the VMware Aria Automation cluster virtual machines. You must update the VM group for the primary availability zone virtual machines to also include the Workspace ONE Access cluster virtual machines, which are a dependency.

Table 3. Design Decisions on Sizing of VMware Aria Automation Sizing

Decision ID	Design Decision	Design Justification	Design Implication
PCA-VAA-CFG-008	Deploy the VMware Aria Automation cluster nodes as medium-size or larger appliances.	A medium-size VMware Aria Automation appliance is typically sufficient, but can be scaled-up for increased workload scalability.	The ESXi hosts in the default management vSphere cluster must have physical CPUs with a minimum of 8 cores per socket. In total, the VMware Aria Automation cluster uses 36 vCPUs and 126 GB of memory in the default management vSphere cluster. When you exceed the scalability and concurrency of the medium-size profile, scale up the cluster nodes size by using VMware Aria Suite Lifecycle.

Network Design

Table 4. Design Decisions on the Network Segment for VMware Aria Automation

Decision ID	Design Decision	Design Justification	Design Implication
PCA-VAA-NET-001	Place the VMware Aria Automation cluster nodes on the cross-instance NSX network segment.	Provides a consistent deployment model for management applications and a potential to extend to a second VMware Cloud Foundation instance for disaster recovery.	You must use an implementation of NSX to support this networking configuration.

Table 5. Design Decisions on the IP Addressing for VMware Aria Automation

Decision ID	Design Decision	Design Justification	Design Implication
PCA-VAA-NET-002	Allocate statically assigned IP addresses from the cross-instance NSX segment to the VMware Aria Automation cluster nodes and the NSX load balancer virtual server.	Using statically assigned IP addresses ensures stability of the deployment and makes it simpler to maintain and easier to track.	Requires precise IP address management.

Table 6. Design Decisions on Name Resolution for VMware Aria Automation

Decision ID	Design Decision	Design Justification	Design Implication
PCA-VAA-NET-003	Configure forward and reverse DNS records for each VMware Aria Automation cluster node IP address and for the NSX load balancer virtual server IP address.	VMware Aria Automation is accessible by using a fully qualified domain name instead of by using IP addresses only.	You must provide DNS records for each VMware Aria Automation cluster node and the NSX load balancer virtual server IP address. Firewalls between the VMware Aria Automation cluster nodes and the DNS servers must allow DNS traffic.
PCA-VAA-NET-004	Configure DNS servers for each VMware Aria Automation cluster node.	Ensures that VMware Aria Automation has accurate name resolution on which its services are dependent.	DNS infrastructure services should be highly-available in the environment. Firewalls between the VMware Aria Automation cluster nodes and the DNS servers must allow DNS traffic. You must provide two or more DNS servers unless a DNS geographic load balancing is activated.

Table 7. Design Decisions on Load Balancing for VMware Aria Automation

Decision ID	Design Decision	Design Justification	Design Implication
PCA-VAA-NET-005	Use the small-size NSX load balancer that is configured by SDDC Manager on the dedicated NSX Tier-1 gateway in the management domain to load balance the clustered Workspace ONE Access deployment, to also load balance the connections across the VMware Aria Automation cluster nodes.	Required to deploy VMware Aria Automation as a cluster deployment type. The VMware Aria Automation cluster can handle a greater load and obtain a higher level of service availability. During the deployment of VMware Aria Automation by using VMware Aria Suite Lifecycle, SDDC Manager automates the configuration of the NSX load balancer for the VMware Aria Automation cluster on a standalone NSX Tier-1 gateway.	You must use the NSX load balancer that is configured by SDDC Manager and the integration with VMware Aria Suite Lifecycle to support this network configuration.

Table 8. Design Decisions on Time Synchronization for VMware Aria Automation

Decision ID	Design Decision	Design Justification	Design Implication
PCA-VAA-NET-006	Configure NTP servers for each VMware Aria Automation cluster node.	Ensures that VMware Aria Automation has accurate time synchronization on which its services are dependent. Assists in the prevention of time mismatch between the VMware Aria Automation nodes and dependencies.	NTP infrastructure services should be highly-available in the environment. Firewalls between the VMware Aria Automation cluster nodes and the NTP servers must allow NTP traffic. You must provide two or more NTP servers unless an NTP geographic load balancing is activated.

Life Cycle Management

Table 9. Design Decisions on the Life Cycle Management of VMware Aria Automation

Decision ID	Design Decision	Design Justification	Design Implication
PCA-VAA-LCM-001	For VMware Cloud Foundation 4.4, use VMware Aria Suite Lifecycle to perform the life cycle management of VMware Aria Automation. For VMware Cloud Foundation 4.3.1 and earlier, use SDDC Manager to apply VMware Aria Automation upgrades.	For VMware Cloud Foundation 4.4, VMware Aria Suite Lifecycle manages the product binaries and VMware Aria Automation upgrades. For VMware Cloud Foundation 4.3.1 and earlier, SDDC Manager provides the upgrade bundles to VMware Aria Suite Lifecycle and manages VMware Aria Operations for Logs upgrades through the integration with VMware Aria Suite Lifecycle.	You must deploy VMware Aria Suite Lifecycle by using SDDC Manager. VMware Aria Suite Lifecycle manages patches, updates, and hot fixes for VMware Aria Automation.
PCA-VAA-LCM-002	Use VMware Aria Suite Lifecycle to apply VMware Aria Automation patches and hot fixes.	Patches, updates, and hot fixes for VMware Aria Automation are not managed by SDDC Manager.	Before applying the updates to VMware Aria Automation, you must use VMware Aria Suite Lifecycle to automate the download or manually upload the product binaries to VMware Aria Suite Lifecycle.

VMware Aria Automation Assembler Design

Table 10. Design Decisions on Tagging for VMware Aria Automation Assembler in VMware Aria Automation

Decision ID	Design Decision	Design Justification	Design Implication
PCA-VAA-CA-CFG-001	Establish and publish a well-defined strategy, implementation, and taxonomy for the tagging of cloud resources.	With capability and constraint tags, you can organize and activate cloud resources and profiles for resource consumption by using the declarative nature of cloud templates to define deployment configurations.	Your strategy must account for external tags, for example, vSphere and NSX tags, and internal user-defined tags managed through VMware Aria Automation Assembler.
PCA-VAA-CA-CFG-002	Apply constraint tags to the cloud template YAML structure.	During a provisioning operation, capabilities are matched with constraints, each expressed as tags, in cloud templates and images to determine the deployment configuration.	You must manage the capability tags on your cloud resources, such as cloud zones, storage and storage profiles, networks and network profiles.

Table 11. Design Decisions on Cloud Accounts for VMware Aria Automation Assembler in VMware Aria Automation

Decision ID	Design Decision	Design Justification	Design Implication
PCA-VAA-CA-CFG-003	Add a cloud account for the vCenter Server instance for each VI workload domain in each VMware Cloud Foundation instance.	You can integrate the vCenter Server instance for each VI workload domains with VMware Aria Automation for provisioning.	You must manage the cloud account credentials and the life cycle management of the related service accounts. You must manage capability tags for the cloud account.
PCA-VAA-CA-CFG-004	Add a cloud account for the NSX Manager cluster for each VI workload domain in each VMware Cloud Foundation instance. Note: For an environment with NSX Federation, add a cloud account for each VI workload domain NSX Local Manager cluster.	You can integrate the NSX Manager cluster for one or more VI workload domains with VMware Aria Automation for provisioning.	You must manage the cloud account credentials and the life cycle management of the related service accounts. VMware Aria Automation supports adding more than one vCenter Server cloud account that shares an NSX Manager cluster. If using an NSX Manager cluster for more than one vCenter Server cloud account, you must manage the NSX Manager-to-vCenter Server associations in the NSX Manager cloud accounts. You must manage capability tags for the cloud account. Each member of an NSX Manager cluster has a certain scalability - the main limit is 199 concurrent API sessions. An NSX Manager cluster assigns the cluster VIP to a single NSX Manager cluster member at any given time. All API requests from VMware Aria Automation are directed to this cluster member through the NSX cloud account. For environments that require a higher concurrent API session count, an external load balancer is required to distribute the API sessions across all NSX Manager cluster members for the workload domain.
PCA-VAA-CA-CFG-005	Use the default POLICY mode for each NSX Manager cloud account.	Ensures that all NSX entities created by VMware Aria Automation use the Policy API instead of the legacy Manager API. There is no migration path from MANAGER mode to POLICY mode.	None.

Table 12. Design Decisions on Cloud Zones for VMware Aria Automation Assembler in VMware Aria Automation

Decision ID	Design Decision	Design Justification	Design Implication
PCA-VAA-CA-CFG-006	Create a cloud zone for each VI workload domain.	Provides provisioning on a specific workload domain.	None.
PCA-VAA-CA-CFG-007	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.
PCA-VAA-CA-CFG-008	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.
PCA-VAA-CA-CFG-009	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. Note: The destination folder, where the cloud templates are deployed, must exist. The destination folder cannot be created by VMware Aria Automation Assembler without extensibility.
PCA-VAA-CA-CFG-010	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 VMware Aria Automation is integrated to VMware Aria Operations and is monitoring the VI workload domain vCenter Server.	Does not provide advanced workload placement across cloud zones and the related cloud accounts.

Table 13. Design Decisions on Integrations for VMware Aria Automation Assembler in VMware Aria Automation

Decision ID	Design Decision	Design Justification	Design Implication
PCA-VAA-CA-CFG-011	Use the default integration to the VMware Aria Automation Orchestrator cluster that is embedded in VMware Aria Automation.	The use of the embedded VMware Aria Automation Orchestrator cluster has the following advantages over the use of an external VMware Aria Automation Orchestrator instance: Operates in cluster mode. Provides a faster time to value. Reduces the number of appliances to manage. Provides an easier upgrade path and better supportability. Improves performance. Removes the requirement for an external database. Using the embedded instance of VMware Aria Automation Orchestrator is applicable in most use cases. For information about the use cases for using the external VMware Aria Automation Orchestrator, refer to the product documentation.	It might be less efficient to run a workflow in a multi-instance deployment from a centralized cluster. However, it is simpler to manage.

Table 14. Design Decisions on Projects for VMware Aria Automation Assembler in VMware Aria Automation

Decision ID	Design Decision	Design Justification	Design Implication
PCA-VAA-CA-CFG-012	For each project, add one or more cloud zones based on the project requirements and allowed cloud resources.	Provides one or more cloud zones and their resources for project consumption.	None.
PCA-VAA-CA-CFG-013	For each project, set a provisioning priority for each cloud zone based on your deployment prioritization.	Prioritizes one cloud zone over another within a project. The default priority is 0 (highest priority).	You must manage the provisioning priority for each cloud zone in each project.
PCA-VAA-CA-CFG-014	For each project, set limits for the project cloud zones as required.	Sets the maximum number of workload instances and resources provisioned in the cloud zone for the project. The default limit is 0 (unlimited).	If a value greater than 0 (unlimited) is used for the instance or resource limit, you must manage the limit for each cloud zone in each project when requirements change.
PCA-VAA-CA-CFG-015	For each project, specify network, storage, and extensibility constraints that must be applied to all requests in the project.	Ensures proper placement of the workloads in a project and its cloud zones.	If the same constraint or the same constraint category is specified in both the project, for example, region:us-west-1, and the cloud template, for example, region:us-east-1, the constraint specified in the project takes precedence, for example, region:us-west-1.
PCA-VAA-CA-CFG-016	For each project, add one or more custom properties, for example, project:foo.	Custom properties can be used for provisioning or capturing additional metadata. For example, for reporting or extensibility actions.	If the same custom property is specified in both the project, for example, project:foo, and the cloud template, for example, project:bar, the property value specified in the project takes precedence, for example, project:foo.
PCA-VAA-CA-CFG-017	For each project, add a custom naming template to be used for virtual machine names provisioned in the project.	The template provides a custom virtual machine name and does not affect the host name of the virtual machine. Note: Custom naming can also be managed using extensibility.	The template substitutes auto-generated virtual machine names by using available properties, such as resource properties, custom properties, endpoint properties, project properties, and a random number with a specified number of digits. You must ensure that the template generates unique names for this project and between other projects.

Table 15. Design Decisions on Flavor Mappings for VMware Aria Automation Assembler in VMware Aria Automation

Decision ID	Design Decision	Design Justification	Design Implication
PCA-VAA-CA-CFG-018	Create standardized flavor mappings based on a common taxonomy and deployment intent.	Provides a simple, natural language naming to define common deployment size specifications.	You must publish and communicate the updates to cloud template developers and consumers.
PCA-VAA-CA-CFG-019	For each flavor mapping, add all applicable account regions.	Provides a simple, natural language naming to define common deployment size specifications when used in a specific account region.	You must maintain the mapping for any image mapping create or update operation.

Table 16. Design Decisions on Image Mappings for VMware Aria Automation Assembler in VMware Aria Automation

Decision ID	Design Decision	Design Justification	Design Implication
PCA-VAA-CA-CFG-020	Use the vSphere content library to synchronize machine images across VI workload domains and VMware Cloud Foundation instances.	The vSphere content library is built into vSphere and meets all the requirements to synchronize machine images across VI workload domains and VMware Cloud Foundation instances. VMware Aria Automation can consume both Open Virtual Format (OVF) images or virtual machine templates from the vSphere content library. Open source solutions, such as HashiCorp Packer, can be use to build machine images in the virtual machine template and OVA formats.	The vSphere content library permissions are connected to global permissions in the permissions hierarchy. To allow VMware Aria Automation Assembler to synchronize and use images in the content library, the user and role must be applied at the global permissions level. You must provide storage space for machine images. You must ensure that the service account used for the cloud account for vCenter Server has the minimum required permissions to consume machine images from the vSphere content library. You must ensure that the number, size, and structure of the machine images are kept within the vSphere content library configuration maximums. You must ensure HTTPS communications between all VI workload domain vCenter Server instances. Deployment of OVF-based machine images from the vSphere content library might be slower than cloning of native vSphere templates. Deployment of VM template-based machine images from the vSphere content library might be impacted during host maintenance/failure or until ownership update and VMware Aria Automation image collection updates.
PCA-VAA-CA-CFG-021	Create standardized image mappings based on similar operating systems, functional deployment intent, and cloud zone availability.	You can create a simple taxonomy to map images to cloud templates.	You must publish and communicate the image-mapping standards and updates to cloud template developers.
PCA-VAA-CA-CFG-022	For each machine image in an image mapping, add a constraint tag, if applicable.	Refines the machine image selection in an image mapping by matching constraints.	You must manage multiple machine images in each account region based on the use of constraint tags in your organization.

Table 17. Design Decisions on Network Profiles for VMware Aria Automation Assembler in VMware Aria Automation

Decision ID	Design Decision	Design Justification	Design Implication
PCA-VAA-CA-CFG-023	For each account region, add one or more network profiles based on network characteristics available for consumption.	You can add networks with predefined characteristics that can be consumed during a deployment process.	You must manage network profiles for each account region as updated across VMware Cloud Foundation instances.
PCA-VAA-CA-CFG-024	For each network in a network profile, add one or more capability tags.	You use capability tags to manage the workload network placement logic during the deployment process.	You must manage capability tagging on each network profile for workflow placement selection during a deployment process.

Table 18. Design Decisions on Storage Profiles for VMware Aria Automation Assembler in VMware Aria Automation

Decision ID	Design Decision	Design Justification	Design Implication
PCA-VAA-CA-CFG-025	For each account region, add one or more storage profiles based on storage characteristics available for consumption.	You can add storage with defined characteristics that can be consumed during a deployment process.	You must manage storage profiles for each account region as storage is added, removed, and updated across VMware Cloud Foundation instances.
PCA-VAA-CA-CFG-026	For each storage profile, add one or more capability tags.	You use capability tags to manage the workload storage placement logic during the deployment process.	You must manage capability tagging on each storage profile for the workflow placement logic during a deployment process.

Table 19. Design Decisions on Action-Based Extensibility for VMware Aria Automation Assembler in VMware Aria Automation

Decision ID	Design Decision	Design Justification	Design Implication
PCA-VAA-CA-CFG-027	Use the embedded on-premises functions-as-a-service (FaaS) provider in VMware Aria Automation for action-based extensibility.	You can use the native VMware Aria Automation functions-as-a-service provider for the execution of lightweight actions through event subscriptions without the requirement for a public cloud account provider, such as Amazon Web Services Lambda or Microsoft Azure Functions.	The use of action-based extensibility requires the VMware Aria Automation instance to have outbound access to the Internet to pull container images from publicly available Internet repositories, for example, to resolve any dependencies included in the actions. If VMware Aria Automation is deployed on an isolated network that does not allow outbound traffic to the Internet, an HTTP proxy must be configured and applied using the vracli proxy command option.

VMware Aria Automation Service Broker Design

Table 20. Design Decisions on Content Sources for VMware Aria Automation Service Broker in VMware Aria Automation

Decision ID	Design Decision	Design Justification	Design Implication
PCA-VAA-SB-CFG-001	Add a cloud template content source for each VMware Aria Automation Assembler project where cloud templates are authored and released.	Provides the ability to share released cloud templates with project members or other projects.	None.
PCA-VAA-SB-CFG-002	Add an extensibility actions content source for each VMware Aria Automation Assembler project where actions are authored and released.	Provides the ability to share released actions with project members.	None.
PCA-VAA-SB-CFG-003	Add a VMware Aria Automation Orchestrator workflows content source for each VMware Aria Automation Assembler project, as required.	Provides the ability to share specific workflows with project members.	None.

Table 21. Design Decisions on Content Customization for VMware Aria Automation Service Broker in VMware Aria Automation

Decision ID	Design Decision	Design Justification	Design Implication
PCA-VAA-SB-CFG-004	For each shared content item, customize the form based on the catalog item and user experience requirements.	You can create an intuitive user experience by using simple and discoverable forms that capture additional user inputs and in-form validations.	Requires customization of request forms per catalog item.

Table 22. Design Decisions on Policies for VMware Aria Automation Service Broker in VMware Aria Automation

Decision ID	Design Decision	Design Justification	Design Implication
PCA-VAA-SB-CFG-005	Identify and apply goals for your organization and each project based on the applicability of available policy types.	By understanding how the policies are processed, you can meet organizational goals without creating an excessive and unmanageable number of policies.	For each policy type, you must determine the applicability and your organizational goals to design policy enforcement and scope that results in the desired effective policy.

Table 23. Design Decisions on Notifications for VMware Aria Automation Service Broker in VMware Aria Automation

Decision ID	Design Decision	Design Justification	Design Implication
PCA-VAA-SB-CFG-006	Configure VMware Aria Automation Service Broker to use an outbound (SMTP) mail server to route notifications for system events.	VMware Aria Automation event notifications are provided by email for an enhanced user experience.	You must configure an SMTP server to relay messages from VMware Aria Automation.

VMware Aria Automation Orchestrator Design

Table 24. Design Decisions on vCenter Server Plug-In for VMware Aria Automation Orchestrator in VMware Aria Automation

Decision ID	Design Decision	Design Justification	Design Implication
PCA-VAA-VAAO-CFG-001	Register each VI workload domain vCenter Server instance with the embedded VMware Aria Automation Orchestrator instance. Do not use per session authentication.	Required for communication from the embedded VMware Aria Automation Orchestrator to the VI workload domain vCenter Server instances.	You cannot use per-session authentication for VMware Aria Automation Orchestratorr communication to vSphere, because vCenter Server does not accept the token from VMware Aria Automation and the registration. When VI workload domains are added or removed, you must add or remove the vCenter Server instance in VMware Aria Automation Orchestrator. When the service account password changes during its life cycle, you must run the Update a vCenter Server Instance workflow with updated credentials.

Information Security and Access Control Design

Table 25. Design Decisions on Identity Management for VMware Aria Automation

Decision ID	Design Decision	Design Justification	Design Implication
PCA-VAA-SEC-001	Limit the use of the local accounts for both interactive or API access and solution integration.	Local accounts are not specific to user identity and do not offer complete auditing from an endpoint back to the user identity.	You must define and manage service accounts, security groups, group membership, and security controls in Active Directory.
PCA-VAA-SEC-002	Limit the scope and privileges for accounts used for both interactive or API access and solution integration.	The principle of least privilege is a critical aspect of access management and must be part of a comprehensive defense-in-depth security strategy.	You might need to define and manage custom roles and security controls to limit the scope and privileges used for interactive access or solution integration.
PCA-VAA-SEC-003	Assign Active Directory user accounts to security groups following your organization's access policies	Allows Active Directory security groups to be assigned to roles in SDDC components for streamlined management of access and administrative privileges.	You must define and manage security groups, group membership, and security controls in Active Directory.
PCA-VAA-SEC-004	Assign Active Directory security groups to default or custom roles, as applicable, for interactive or API access to solution components based on your organization's business and security requirements.	Using Active Directory security group membership provides greater flexibility in granting access to roles across solution components. Ensuring that each user logs in with a unique Active Directory user account provides greater visibility for auditing. Each organization has its own internal processes. Evaluate the needs for additional role separation in your organization and implement mapping from Active Directory users to Active Directory security groups and default or custom roles.	You must manage the privileges assigned to custom roles. You must manage the assignment and scope of the based on the business and security requirements. Additional Active Directory security groups must be created in advance to assigning roles. You must maintain the life cycle and availability of Active Directory security groups outside of the SDDC stack. The principle of least privilege is only one aspect of access management and should be part of a comprehensive defense-in-depth security strategy that's aligned with organization personas.
PCA-VAA-SEC-005	Activate VMware Aria Automation integration with Active Directory by using the clustered Workspace ONE Access deployment.	Allows authentication for VMware Aria Automation using Active Directory as the identity provider. Allows authorization through the assignment of both VMware Aria Automation organization and service roles to users and security groups defined in Active Directory.	You must deploy and configure the clustered Workspace ONE Access nodes to establish the integration between VMware Aria Automation and Active Directory. The clustered Workspace ONE Access deployment must be sized and scaled to support the VMware Aria Automation size and scale.
PCA-VAA-SEC-006	Assign VMware Aria Automation organization service and project roles to designated Active Directory. security groups synchronized to the clustered Workspace ONE Access deployment.	By assigning Active Directory security groups to organization and service roles, you can simplify and manage user access to VMware Aria Automation based on the Active Directory security group membership.	You must define and manage the security groups, group membership, and security controls in Active Directory for those directory services objects used by VMware Aria Automation.

Table 26. Design Decisions on Service Accounts for VMware Aria Automation Assembler Cloud Accounts in VMware Aria Automation

Decision ID	Design Decision	Design Justification	Design Implication
PCA-VAA-SEC-007	Define a custom vCenter Server role for VMware Aria Automation that has minimum privileges required to support a vCenter Server cloud account.	VMware Aria Automation integrates with VI workload domain vCenter Server instances in VMware Cloud Foundation instances using the minimum set of privileges and permissions scope required to support the cloud account.	You must maintain the privileges required by the custom vSphere role. If additional VMware Cloud Foundation instances are not in the same vCenter Single Sign-On domain, the custom role must be applied to each vCenter Single Sign-On domain.
PCA-VAA-SEC-008	For each VMware Cloud Foundation instance, use an Active Directory user account as a service account for each vCenter Server for application-to-application communication from VMware Aria Automation to vCenter Server.	Provides the following access control features: VMware Aria Automation services, such as VMware Aria Automation Assembler, access VI workload domain vCenter Server instances with the minimum set of required permissions. If there is a compromised account, the accessibility to the destination cloud account remains restricted. You can introduce an improved accountability in tracking request-response interactions between the VMware Aria Automation and the vCenter Server endpoint in the cloud account.	You must maintain the life cycle, availability, and security controls for the account in Active Directory. You must maintain the scope of permissions assigned to the service account across the VMware Cloud Foundation instances. To reduce the potential fault domain for a cloud account, you can create a service account per VI workload domain for the vCenter Server cloud account.
PCA-VAA-SEC-009	Assign vCenter Server global permissions for the VMware Aria Automation-to-vCenter Server integration accounts for each VMware Cloud Foundation instance.	VMware Aria Automation accesses VI workload domain vCenter Server instances with the minimum set of permissions that are required to support a vCenter Server cloud account.	You must set the permissions scope for the service account used by the vCenter Server cloud account to the default No access vSphere role for the management domain vCenter Server instances or other VI workload domains not used by VMware Aria Automation, to ensure that service account access to the workload domains is restricted. You must set the permissions scope for the service account used by the vCenter Server cloud account to the default No access vSphere role for vSphere inventory objects that should be excluded from VMware Aria Automation workload placement or on-boarding. To reduce the potential fault domain for a cloud account, you can create a service account per VI workload domain for the vCenter Server cloud account.
PCA-VAA-SEC-010	Use an Active Directory user account as an integration account for each NSX Manager cluster for application-to-application communication from VMware Aria Automation to NSX.	Provides the following access control features: VMware Aria Automation services, such as VMware Aria Automation Assembler, accesses NSX Manager with the minimum set of required permission. If there is a compromised account, the accessibility to the destination cloud account remains restricted. You can introduce an improved accountability in tracking request-response interactions between the VMware Aria Automation and the NSX Manager endpoint in the cloud account.	You must maintain the life cycle, availability, and security controls for the account in Active Directory. To reduce the potential fault domain for a cloud account, you can create a service account per VI workload domain for the NSX cloud account. Important: This solution is based on the use of Active Directory over LDAP with SSL used as the identity provider using Workspace ONE Access. If Active Directory Federation Services (ADFS) is used as an identity provider for NSX Manager, VMware Aria Automation cannot authenticate to an NSX Manager. A limitation exists where API-based logins to a system that uses a third-party identity provider, for example, ADFS with Workspace ONE Access. The username and password cannot be sent over SAML to the identity provider for authentication.
PCA-VAA-SEC-011	Assign the NSX Manager Enterprise admin role to the VMware Aria Automation-to-NSX integration accounts for VI workload domains.	VMware Aria Automation accesses designated VI workload domain NSX Manager clusters in VMware Cloud Foundation instances with the minimum set of permissions that are required to support NSX in the NSX Manager cloud accounts.	You must configure and manage the integration of Workspace ONE Access with NSX. Important: This solution is based on the use of Active Directory over LDAP with SSL used as the identity provider using Workspace ONE Access. If Active Directory Federation Services (ADFS) is used as an identity provider for NSX Manager, VMware Aria Automation cannot authenticate to NSX Manager. A limitation exists where API-based logins to a system that uses a third-party identity provider, for example, ADFS with Workspace ONE Access. The user name and password cannot be sent over SAML to the identity provider for authentication.

Table 27. Design Decisions on Service Accounts for VMware Aria Automation Orchestrator in VMware Aria Automation

Decision ID	Design Decision	Design Justification	Design Implication
PCA-VAA-SEC-012	For each VMware Cloud Foundation instance, use an Active Directory user account as a service account for each VI workload domain vCenter Server for application-to-application communication from VMware Aria Automation Orchestrator to vCenter Server.	Provides the following access control features: VMware Aria Automation Orchestrator services access VI workload domain vCenter Server instances with the minimum set of required permissions. If there is a compromised account, the accessibility to the destination integration remains restricted. You can introduce an improved accountability in tracking request-response interactions between the VMware Aria Automation Orchestrator and the vCenter Server instances.	You must maintain the life cycle, availability, and security controls for the account in Active Directory. You must maintain the scope of permissions assigned to the service account across VMware Cloud Foundation instances. To reduce the potential fault domain for the integration, you can create a service account per VI workload domain for the VMware Aria Automation Orchestrator integration.
PCA-VAA-SEC-013	Add the integration account used for application-to-application communication between VMware Aria Automation Orchestrator and vCenter Server to an Active Directory security group. Add any named users to the Active Directory security group.	Allows only accounts defined in the Active Directory security group membership to administer the VMware Aria Automation Orchestrator instance.	You must define and manage security groups, group membership, and security controls in Active Directory.
PCA-VAA-SEC-014	Create and apply a custom vSphere role for the service account used to add VI workload domain vCenter Server instances to the VMware Aria Automation Orchestrator configuration.	VMware Aria Automation Orchestrator integrates with VI workload domain vCenter Servers instances using the minimum set of privileges required to support the vCenter Server registration.	You must maintain the privileges required by the custom vSphere role. If additional VMware Cloud Foundation instances are not in the same vCenter Single Sign-On domain, the custom role must be applied to each vCenter Single Sign-On domain. VMware Aria Automation Orchestrator requires Administrator-level privileges to register a vCenter Server instance with VMware Aria Automation Orchestrator and can not be restricted based a registration account and another with the privileges required by workflows executed against VI workload domain vCenter Server instances. After the addition of VI workload domain, you can decide to update and reduce the privileges for the custom role.
PCA-VAA-SEC-015	Assign vCenter Server global permissions for the VMware Aria Automation Orchestrator-to-vCenter Server integration accounts for VMware Cloud Foundation instance workload domains.	VMware Aria Automation Orchestrator registers VI workload domain vCenter Servers instances with the required set of permissions. VMware Aria Automation Orchestrator can register a VI workload domain vCenter Server when added to a VMware Cloud Foundation instance.	You must set the permissions scope for the service account used by VMware Aria Automation Orchestrator to the default No access vSphere role for the management domain vCenter Server instances to ensure that service account access to the management domains is restricted. You should set the permissions scope for the service account used by the VMware Aria Automation Orchestrator to the default No access vSphere role for vSphere inventory objects that should be excluded from VMware Aria Automation Orchestrator scope. If additional VMware Cloud Foundation instances are not in the same vCenter Single Sign-On domain, the service account scope must be applied to each VMware Cloud Foundation instance.

Table 28. Design Decisions on Password Policies for VMware Aria Automation

Decision ID	Design Decision	Design Justification	Design Implication
PCA-VAA-SEC-016	Configure the password expiration policy for the VMware Aria Automation appliances.	You configure the password expiration policy for the VMware Aria Automationappliances to align with the requirements of your organization which might be based on industry compliance standards. The policy is applicable only to the local VMware Aria Automation users.	You can manage the password expiration policy on the VMware Aria Automation appliances by using the virtual appliance console or a Secure Shell (SSH) client.
PCA-VAA-SEC-017	Configure the password complexity policy for the VMware Aria Automation appliances.	You configure the password complexity policy for VMware Aria Automation appliances to align with the requirements of your organization which might be based on industry compliance standards. The policy is applicable only to the local VMware Aria Automationusers.	You can manage the password complexity policy on the VMware Aria Automation appliances by using the virtual appliance console or a Secure Shell (SSH) client.
PCA-VAA-SEC-018	Configure the account lockout policy for the VMware Aria Automation appliances.	You configure the account lockout policy for VMware Aria Automation appliances to align with the requirements of your organization which might be based on industry compliance standards. The policy is applicable only to the local VMware Aria Automation users.	You can manage the account lockout policy on the VMware Aria Automation appliances by using the virtual appliance console or a Secure Shell (SSH) client.

Table 29. Design Decisions on Password Management for VMware Aria Automation

Decision ID	Design Decision	Design Justification	Design Implication
PCA-VAA-SEC-019	Change the VMware Aria Automationroot password on a recurring or event-initiated schedule by using the SDDC Manager user interface or API.	By default, the password for the VMware Aria Automationroot account expires every 365 days. When VMware Aria Automation is deployed into a VMware Cloud Foundation environment in VMware Aria Suite Lifecycle, the root password is managed from the SDDC Manager user interface or API, not from the vRealize Suite Lifecycle Manager.	By using SDDC Manager, you manage the password change or automate password rotation schedule for the VMware Aria Automationroot account in accordance with your organizational policies and regulatory standards.

Table 30. Design Decisions on Certificates for VMware Aria Automation

Decision ID	Design Decision	Design Justification	Design Implication
PCA-VAA-SEC-020	Use a certificate authority signed certificate containing the FQDNs of the VMware Aria Automation cluster nodes and the virtual server FQDN in the SAN attributes, when deploying VMware Aria Automation.	Ensures that all communications to the externally facing VMware Aria Automation browser-based UI and API, and between the components, are encrypted.	Using certificates signed by a certificate authority might increase the deployment preparation time as certificate requests are generated and delivered. You must manage the life cycle of the certificate replacement by using VMware Aria Suite Lifecycle. If multi-tenancy is activated for VMware Aria Automation, the on-boarding of tenants requires a service interruption for all tenants during certificate replacement.
PCA-VAA-SEC-021	Use a SHA-2 or higher algorithm for certificate signing.	The SHA-1 algorithm is considered less secure and has been deprecated.	Not all certificate authorities support SHA-2 or higher.

Table 31. Design Decisions on Trusted Certificates for VMware Aria Automation Orchestrator in VMware Aria Automation

Decision ID	Design Decision	Design Justification	Design Implication
PCA-VAA-SEC-022	Import the certificate authority root certificate to the embedded VMware Aria Automation Orchestrator instance in VMware Aria Automation.	Ensures that the certificate for each VI workload domain vCenter Server instance is trusted by the embedded VMware Aria Automation Orchestrator instance in VMware Aria Automation. Ensures that other endpoints with certificates issued from the same certificate authority, for example, NSX Manager and VMware Aria Operations, are trusted.	If the certificate authority certificate is reissued, you must import an updated certificate to the embedded VMware Aria Automation Orchestrator instance in VMware Aria Automation.

Solution Interoperability Design

Table 32. Design Decisions on Monitoring and Alerting for Private Cloud Automation

Decision ID	Design Decision	Design Justification	Design Implication
PCA-VAA-MON-001	Configure the VMware Aria Automation integration in VMware Aria Operations.	Provides the ability to share common constructs, such as cloud accounts, cloud zones, and projects, across VMware Aria Operations and VMware Aria Automation. Provides the ability to understand the deployment cost. Evaluate upfront costs on VMware Aria Automation. Monitor ongoing costs per virtual machine, deployment, or project.	You must manage the password life cycle of this endpoint.
PCA-VAA-MON-002	Configure the VMware Aria Automation integration in VMware Aria Operations to use the default collector group.	Cross-instance components are configured to use the default collector group.	The load on the analytics cluster, though minimal, increases.
PCA-VAA-MON-003	Add an integration in VMware Aria Automation Assembler for VMware Aria Operations deployment.	You can use data from VMware Aria Operations in VMware Aria Automation to display live vSphere-based virtual machine metrics for CPU, memory, storage IOPS, and network MBps after placement. Metrics for the past day, week, or month are available. You can use data from VMware Aria Operations in VMware Aria Automation to apply and display the cost estimation at the time of deployment and over time.	When configuring the integration, you must use a service account that is created for application-to-application integration for VMware Aria Automation to VMware Aria Operations. When the service account password is updated, you must manage the service account password in the integration configuration. You must configure VMware Aria Operations with VMware Aria Automation to ensure that both applications are set to the same time zone. VMware Aria Automation uses only UTC. You must configure VMware Aria Operations with a currency setting to consume the VMware Aria Operations cost engine for VMware Aria Automation cost estimation. The VMware Aria Operations integration is not used for workload placement in this design. The integration does not support resource pools in vCenter Server or vSAN datastores for workload placement. Project costs include only the costs for private cloud workloads. If a project contains deployments that belong to public clouds, the costs for these deployments are not included in the project cost.
PCA-VAA-MON-004	Use the ADVANCED placement policy for each VMware Aria Automation cloud zone that is monitored by VMware Aria Operations.	By default, the workload placement evaluation uses the VMware Aria Operations recommendation.	You must integrate VMware Aria Automation with VMware Aria Operations in VMware Aria Automation Assembler. The ADVANCED option for VMware Aria Operations does not support workload placement when resource pools in vCenter Server for workload placement are in use. If resource pools must be activated in a workload domain, the workload placement falls back to the DEFAULT placement policy. By default, all vSphere clusters have the vSphere Distributed Resource Scheduler activated to optimize initial and ongoing workload placement within a cluster.
PCA-VAA-MON-005	Add a Ping adapter for the VMware Aria Automation cluster nodes.	Provides metrics on the availability of VMware Aria Automation nodes.	You must add the adapter instances manually.

Table 33. Design Decision on Service Accounts for Monitoring and Alerting for Private Cloud Automation

Design Decision ID	Design Decision	Design Justification	Design Implication
PCA-VAA-MON-006	Assign the Organization Owner default role and the Assembler administrator service role to an enterprise directory service account user for the application-to-application communication from VMware Aria Operations to VMware Aria Automation.	Provides the following access control features: VMware Aria Operations accesses VMware Aria Automation with the minimum set of required permissions for the integration. If there is a compromised account, the accessibility in the destination application remains restricted. You can introduce improved accountability in tracking request-response interactions between the VMware Aria Operations and VMware Aria Automation integration.	None.
PCA-VAA-MON-007	Assign the ReadOnly role to an Active Directory user account as an integration account for the application-to-application communication from VMware Aria Automation to VMware Aria Operations.	Provides the following access control features: VMware Aria Automation integrates VMware Aria Operations with the minimum set of required permissions. If there is a compromised account, the accessibility in the destination application remains restricted. You can introduce improved accountability in tracking request-response interactions between the VMware Aria Automation and VMware Aria Operations.	You must maintain the life cycle, availability, and security controls for the account in Active Directory. You must maintain the synchronization and availability of the service account in Workspace ONE Access and VMware Aria Operations. You must use the format of user@domain@source when configuring the integration to use a service account backed by Workspace ONE Access. For example, [email protected]@WorkspaceONE. Important: This solution is based on the use of Active Directory over LDAP with SSL used as the identity provider using Workspace ONE Access. If Active Directory Federation Services (ADFS) is used as an identity provider for VMware Aria Operations, VMware Aria Automation cannot authenticate to VMware Aria Operations. A limitation exists where API-based logins to a system that uses a third-party identity provider, for example, ADFS with Workspace ONE Access. The user name and password cannot be sent over SAML to the identity provider for authentication.

Table 34. Design Decisions on Logging for Private Cloud Automation

Decision ID	Design Decision	Design Justification	Design Implication
PCA-VAA-LOG-001	Use the VMware Aria Operations for Logs content pack for VMware Aria Automation.	Provides an additional granular monitoring on the virtual infrastructure. The content pack is installed by SDDC Manager.	None.
PCA-VAA-LOG-002	Use the default configuration to transmit logs from VMware Aria Automation to the adjacent VMware Aria Operations for Logs in the VMware Cloud Foundation instance using the VMware Aria Operations for Logs ingestion API, cfapi, on port 9000.	Ensures the transmission of logs from the VMware Aria Automation services to be forwarded to the adjacent VMware Aria Operations for Logs using the VMware Aria Operations for Logs plugin for Fluentd. Provides the ability to configure a planned failover or disaster recovery of VMware Aria Automation to another VMware Cloud Foundation instance with minimal reconfiguration of VMware Aria Automation. VMware Cloud Foundation does not support the ability select the cfapi port used for the VMware Aria Automation integration with VMware Aria Operations for Logs.	The default configuration is unencrypted. To ensure that the transmission of logs between VMware Aria Automation and VMware Aria Operations for Logs is encrypted using SSL, you must update the default configuration for VMware Aria Automation to send logs to VMware Aria Operations for Logs using the ingestion API, cfapi, on port 9543 using the VMware Aria Automationvracli. For example, on the primary VMware Aria Automation cluster node, run the command vracli vrli set https://<vaol_ilb_fqdn>:9543 See Configuring Log Forwarding to vRealize Log Insight in the VMware Aria Automation documentation.
PCA-VAA-LOG-003	Use the VMware Aria Operations for Logs content pack for VMware Aria Automation Orchestrator.	Provides an additional granular monitoring on the virtual infrastructure. Install the content pack manually as this installation is not yet automated by SDDC Manager.	None.
PCA-VAA-LOG-004	Configure a dedicated agent group in the VMware Aria Operations for Logs cluster to include all FQDNs of the VMware Aria Automation cluster nodes.	Provides a standardized configuration to all VMware Aria Operations for Logs agents in each of the groups. Defines the VMware Aria Operations for Logs agent configuration for log collection and parsing in the context of the SDDC components, such as specific log directories, files, and formats.	Adds minimal load to VMware Aria Operations for Logs.