Azure Reference Architecture

Page last updated:

Warning: Pivotal Cloud Foundry (PCF) v2.6 is no longer supported because it has reached the End of General Support (EOGS) phase as defined by the Support Lifecycle Policy. To stay up to date with the latest software and security updates, upgrade to a supported version.

This topic describes a reference architecture for Pivotal Cloud Foundry (PCF) on Azure. It builds on the common base architectures described in Platform Architecture and Planning Overview.

For additional requirements and installation instructions for running PCF on Azure, see Installing PCF on Azure.


Azure Virtual Data Center (VDC) uses a hub and spoke model for extending on-premises data centers. For more information about VDC, see the Azure Virtual Datacenter e-book.

When installing PCF, you can use this model to place resources in resource groups. For example, a PCF installation contains:

  • Hub:

    • A central IT resource group included in Azure VDC setup. This is where you define firewall, access control, and security policies.
  • Spokes:

    • A Network resource group for all network resources.
    • PAS/PKS resource groups for all PAS/PKS resources.


The diagram below illustrates the reference architecture for PAS on Azure using the hub and spoke model described above:

This diagram illustrates PCF with PAS on Azure using Availability Sets. For specific details about the components and communication represented in this diagram, see the base and Azure reference architectures.

View a larger version of this diagram.

The sections below provide guidance about the resources that you use for running PCF on Azure.


The following sections provide guidance about networking resources.

General Requirements and Recommendations

The following are general requirements and recommendations related to networking when running PCF on Azure:

  • You must enable Virtual Network peering between hub and spoke resource groups. For more information, see Virtual network peering in the Microsoft Azure documentation.

  • You must have separate subscriptions for each resource group. This includes:

    • The central network resource group. This is the hub.
    • Each workspace where workloads run. These are the spokes.
  • Use ExpressRoutes for a dedicated connection from an on-premises datacenter to VDC. For more information, see the ExpressRoute documentation. As a back up for when ExpressRoutes goes down, you can use Azure VPN Gateways, which pass encrypted data into VDC through the internet.

  • Use a central firewall in the hub resource group and a network appliance to prevent data infiltration and exfiltration.

  • You can place network resources, such as DNS and NTP servers, either on-premises or on Azure Cloud.


For your PCF domains, use a sub-zone of an Azure DNS zone.

Azure DNS supports DNS delegation, which allows sub-level domains to be hosted within Azure. For example, a company domain of has a PCF zone in Azure DNS of

Azure DNS does not support recursion. To properly configure Azure DNS:

  1. Create an NS record with your registrar that points to the four name servers supplied by your Azure DNS Zone configuration.

  2. Create the required wildcard A records for the PCF app and system domains, as well as any other records desired for your PCF deployments.

You do not need to make any configuration changes in PCF to support Azure DNS.

Load Balancing

Use Standard Azure Load Balancers (ALBs). To allow internet ingress, you must create the ALBs with elastic IP addresses.

During installation, you configure ALBs for PAS Gorouters. For more information, see Create Load Balancers in Deploying Ops Manager on Azure Manually. When applicable, TCP routers and SSH Proxies also require load balancers.

The PAS system and app domains must resolve to your ALB and have either a private or a public IP address assigned. You set these domains in the Domains pane of the PAS tile.


PCF requires the networks defined in the base reference architectures for PAS and PKS. For more information, see the Networks sections in Platform Architecture and Planning Overview.

PAS on a Single Resource Group

If shared network resources do not exist in an Azure subscription, you can use a single resource group to deploy PCF and define network constructs.

High Availability (HA)

Note: As of PCF v2.5.3, PCF on Azure supports both availability zones (AZs) and Availability Sets.

Use AZs instead of Availability Sets in all Azure regions where they are available. AZs solve the placement group pinning issue associated with Availability Sets and allow greater control when defining high-availability configuration when using multiple Azure services.

For additional guidance depending on your use case, see the table below:

Foundation Type Guidance
New foundation If you do not have strict requirements, select AZ-enabled regions. Examples of strict requirements include existing ExpressRoute connections from non-AZ enabled regions to customer data centers and app-specific latency requirements.
Existing foundation in AZ-enabled region Migrate to a new PCF v2.5.3 or later foundation so that you can use AZs. These existing foundations, especially those using older families of VMs such as DS_v2, risk running out of capacity as they scale.
Existing foundation not in AZ-enabled region Evaluate your requirements to determine the cost/benefit of migrating to an AZ enabled region.

For more information about availability modes in Azure, see the following:

Availability Zones

AZs are an Azure primitive that supports HA within a region. They are physically separate data centers in the same region, each with of separate power, cooling, and network.

The following diagram illustrates PAS deployed on Azure using AZs:

This diagram illustrates PCF with PAS on Azure using AZs. For specific details about the components and communication represented in this diagram, see the base and Azure reference architectures.

View a larger version of this diagram.

AZs have the following advantages:

  • VMs and other zonal services deployed to independent zones provide greater physical separation than Fault Domains and avoid the placement group pinning issue associated with Availability Sets.

  • Zonal services are effectively in separate Update Domains as updates are rolled out to one zone at a time.

  • AZs are visible and configurable. Two zonal services placed in the same logical zone are also placed in the same physical zone. This allows services of different types to take advantage of the highly available qualities that a zone provides.

Availability Sets

Availability Sets were the first Azure primitive to support high availability within a region.

Warning: Availability Sets are implemented at the hardware rack level, which can cause issues when deploying PCF on Azure. For more information, see Placement Group Pinning Issues below.

Availability Sets have the following properties:

  • They are a logical concept that ensures multiple VMs in the same set are spread evenly across three Fault Domains and either five or 20 Update Domains.

  • When a hardware issue occurs, VMs on independent Fault Domains are guaranteed not to share power supply or networking and therefore maintain availability of a subset of VMs in the set.

  • When updates are rolled out to a Cluster, VMs in independent Update Domains are not updated at the same time, ensuring downtime incurred by an update does not affect the availability of the set.

Placement Group Pinning Issues

In PCF on Azure in Availability Set HA mode, VMs for a particular job are pinned to a placement group determined when the first VM in the Availability Set is provisioned. This is because BOSH places VMs for each job within the same Availability Set.

Cluster-pinning causes:

  • Issues migrating jobs from one family of VMs to another, backed by different hardware, such as DS_v2 and DS_v3

  • Issues scaling up if there is no capacity remaining in the placement group


For storage, Pivotal recommends:

  • For the storage account type, use the premium performance tier.

  • Configure storage accounts for Zone Redundant Storage (ZRS) in AZ-enabled Regions.

    Note: In non-AZ enabled regions, locally Redundant Storage (LRS) is sufficient.

  • Configure VMs to use managed disks instead of manually-managed VHDs on storage accounts. Managed disks are an Azure feature that handles the correct distribution of VHDs over storage accounts to maintain high IOPS as well as high availability for the VMs.

  • Use five storage accounts. PCF on Azure requires five storage accounts: one for BOSH, one for Ops Manager, and three for PAS. Each account comes with a set amount of disk space. Azure storage accounts have an IOPs limit of about 20k per account, which generally corresponds to a BOSH job/VM limit of 20 VMs each.

SQL Server

The Internal MySQL database provided by PAS is sufficient for production use.

Blobstore Storage Account

Use Azure Blob Storage as the external file storage option for PCF. This provides redundancy for high-availability deployments of PCF and unlimited scaling. Azure Blob Storage provides fully-redundant hot, cold, or archival storage in either local, regional, or global offerings.

Ops Manager requires a bucket for the BOSH blobstore.

PAS requires the following buckets:

  • Buildpacks

  • Droplets

  • Packages

  • Resources

These buckets require an associated role for read/write access.

Identity Management

Use unique managed identities to deploy Ops Manager, BOSH Director, Microsoft Azure Service Broker, and any other tiles that require independent credentials. Ensure that each managed identity is scoped to the least privilege necessary to operate.

Azure uses managed identities to handle service authorization. For more information, see What is managed identities for Azure resources? in the Microsoft Azure documentation.