Managed Private Cloud Flex

MPC Flex is the shared-infrastructure service variant of Managed Private Cloud (MPC) for customers that require flexibility and scalability. It uses a shared tenancy model that enables dynamic allocation of resources based on workload requirements.

MPC Flex delivers compute, storage, and networking resources in a shared environment hosted in Equinix IBX data centers. Resources are provisioned on demand and consumed through an OPEX model, with Equinix responsible for operations, management, and compliance.

MPC Flex provides a multi-tenant compute environment deployed as an Organizational Virtual Data Center (OVDC) with logical separation between tenants, supporting scalability and administrative control. An OVDC provides compute resources (vCPU and vRAM) and storage resources for creating virtual machines. Multiple OVDCs can be combined in different variants and sizes to support different use cases. Security policies can be configured on virtual networks and interconnections. Compute, storage, and networking resources are managed from the MPC Operational Console.

---

MPC Compute defines the processing capacity available to an OVDC and is measured in vCPUs. Each OVDC can be configured with one of the following vCPU variants:

• Optimized (Default) - Balances CPU capacity across the OVDC for an optimized performance.
• Full - Provides 100% of the CPU capacity.

Recommended vCPU utilization:

VCPU Variant	Use (Examples)
Optimized (Default)	• Generic production servers • OTA servers
Full	• Terminal servers • High-load application servers • Latency-sensitive application servers

---

MPC Memory consists of memory in GB vRAM available for the OVDC. Memory in the OVDC is provided as vRAM, available at 100% of its capacity and measured in gigabytes (GB). The sales volume for MPC Flex uses a default compute‑to‑memory ratio:

• MPC Flex Optimized: 1 vCPU : 4 GB vRAM
• MPC Flex Full: 1 vCPU : 16 GB vRAM

---

Purchase MPC Compute in Purchase Units (PUs) of vCPU and GB of vRAM, using Baseline and Overage calculation types.

• Baseline represents the committed volume of PUs with a fixed monthly recurring charge.
• Overage represents additional consumption beyond the Baseline, metered and calculated monthly

Purchase Unit & UOM	CPU Variant	Calculation Type	Description
vCPU	Optimized Full	Baseline	Committed volume of PUs
vCPU	Optimized Full	Overage	Additional consumption above Baseline

Purchase Unit	UOM	Calculation Type	Description
GB vRAM	GB vRAM	Baseline	Committed volume of PUs
GB vRAM	GB vRAM	Overage	Additional consumption above Baseline

The default ratio of combined compute purchase units is one vCPU plus four GB vRAM (1vCPU+4GBvRAM).

OVDCs are provisioned with additional capacity for flexible consumption. This additional capacity is calculated as a percentage of the Baseline volume, with a maximum of 25%.

---

MPC Storage provides two performance tiers represented as storage policies. Storage capacity is associated with a specific OVDC.

A virtual disk for a virtual machine (VM) can be created within the customer‑assigned storage capacity and placed on the storage policy (performance tier) that matches the VM’s workload. An OVDC can support multiple storage policies, allowing VMs within the same OVDC to use different policies.

Storage Policy	Use
High Performance	Database workloads, logs, RDS/SBC, VDI, and other low‑latency–sensitive workloads
Performance (Default)	Generic VMs, applications and web services, high‑performance file services, and object storage

The following features apply when using storage policies in the MPC environment:

• Storage capacity is allocated per policy per OVDC.
• MPC Storage includes encryption at rest
• The recommended virtual disk size per VM is between 40 GB and 8 TB.
• MPC Storage is measured in purchase units (PUs) of 1 TB per storage policy, with Baseline and Overage calculation types.

Purchase Unit	Tier	Calculation Type	UOM	Description
MPC Storage	High Performance	Baseline	1 TB	Baseline charge for the committed storage quantity, measured in whole TBs.
MPC Storage	Performance	Overage	1 TB	Charge for storage usage that exceeds the Baseline quantity, measured in TBs with up to 3 decimal places.

Storage capacity is calculated based on the following assumptions: 1TB = 1000GB. Storage capacity is not transferable to other OVDCs. MPC Storage is provisioned per storage policy with additional capacity available for flexible consumption. Additional capacity is calculated as a percentage of the Baseline volume, with a maximum of 25% or 10 TB.

MPC Storage consumption per policy is measured as allocated capacity for:

• VM disks
• VM swap files
• Snapshots
• Files in a library (vApp templates and ISOs)

---

MPC Connectivity integrates MPC into customer (multi) cloud architectures and supports connections to the following:

• Equinix Colocation
• Equinix Network Edge
• WAN Providers
• Cloud Service Providers (CSP)
• MPC environments in another metro
• Equinix Internet Access (EIA) via Equinix Fabric

Connectivity is supported only through Equinix Fabric (Virtual Circuits). Other connectivity options are not supported.

Network requirements determine how customer networks connect to an MPC OVDC. The following connectivity types are available:

• Connectivity Routed - routing managed by Equinix
• Connectivity Customer Routed - routing managed by the customer
• Managed Private Firewall (MPF) - routing managed by Equinix

Each OVDC has a single connectivity type. When multiple OVDCs are used, supported combinations of connectivity types are available.

Connectivity Routed offers layer-3 connectivity to the MPC OVDC for connectivity. This option provides the customer with a ready for use and built-in routing engine. Configurable via the Operational Console. Each MPC internal (routed) network created is automatically part of the customer routing domain.

Connectivity Customer Routed uses a customer-provided, installed and managed virtual routing appliance (VM) within MPC. External networks ordered by Equinix are made available in the Operational Console. Additional external networks can be ordered separately. External networks must be connected to the virtual routing appliance. MPC internal (isolated) networks must be connected to the routing appliance.

note

1. Only isolated internal networks are available in this option; routed internal networks are not supported. Internal networks can be used to connect customer VMs to the virtual routing appliance.
2. The number of connected VLANs must not exceed the number of virtual NICs, with up to 10 minus the NICs used for external communication.
3. Trunking is not supported on internal networks, so VLAN tagging inside the guest OS is not possible.
4. External networks are required to connect the virtual routing appliance for external connectivity (2 virtual circuits per connection).
5. Although MPC provides high availability, using an HA setup with two VMs as the virtual routing appliances is recommended.
6. Using VMware Tools on any appliance or VM is recommended to support graceful management.

When using Managed Private Firewall (MPF), external connectivity terminates at MPF, which provides routing and logging. MPF connects to the built-in MPC routing. North-south traffic is processed by MPF and MPC routing. East-west routing is handled by MPC. This option provides a routing solution consisting of:

• MPF routing configured by Equinix
• MPC routing configurable via the operational console

Each MPC internal routed network created is automatically part of the customer routing domain, while internal isolated networks are not.

Networking with Multiple OVDCs allows each OVDC within the same metro to use a different combination of connectivity types, since connectivity is defined per OVDC and each configuration provides a distinct set of capabilities.

• Multiple OVDCs with Connectivity Routed - When using multiple OVDCs in one metro, customers can choose either a dedicated Gateway per OVDC or a shared Gateway instance for both OVDCs (Routed Joined). When a network must be available in multiple OVDCs and the Customer Routed connectivity option is used, the External Network function can make external networks available to both OVDCs by using a Datacenter Group.

• Multiple OVDCs with Connectivity Routed and Customer Routed - When using multiple OVDCs in one metro, the customer can choose to use a combination of Routed for one OVDC and Customer Routed for the other. The customer will have two options for implementation:

  • OVDCs are connected: When connected, a VLAN is created between the Customer Routed appliance and the Routed Gateway. The customer can create networks between the 2 different OVDCs.
  • OVDCs are not connected: Where there is no connectivity between the two OVDCs the OVDCs work as a stand-alone environment.

The following virtual connection options are supported:

Connection	#	Type	Description
Equinix Colocation	1	Self‑Service VC	Customer‑created and managed connection via the Equinix Fabric Portal using an EMS service profile or service token.
Equinix Network Edge	2	Self‑Service VC	Customer‑created and managed connection via the Equinix Fabric Portal using an EMS service profile or service token.
WAN Providers	3	Managed VC	Equinix‑created and managed connection. Part of the MPC order.
Cloud Service Providers (CSP)	4	Managed VC	Equinix‑created and managed connection. Part of the MPC order.
MPC environment in another Metro	5	Managed VC	Equinix‑created and managed connection. Part of the MPC order.
Equinix Internet Access (EIA) via Equinix Fabric	6	Managed Internet Access	Equinix‑created and managed connection. Part of the MPC order.

• Self-Service VC - Customers initiate VCs via the Equinix Fabric Portal. Equinix Managed Solutions configures the MPC side. Each connection requires two VCs.

• Managed VC - VCs are created as part of the MPC order. Configuration parameters are collected during fulfillment.

note

All connections require two Virtual Circuits for redundancy.

If customer requires Internet as part of the MPC environment, Managed Internet Access uses Fabric Internet Access (EIA) with fixed bandwidth and no bursting. Supported bandwidths are up to 10 Gbps. IP address space must be ordered separately. Third-party internet services on Equinix Fabric are supported but must be contracted separately.

note

Two connections are required for redundancy with third-party providers.

---

MPC Virtual Networking provides a set of virtual network functions that can be configured in the MPC Operational Console. The following list shows which functions are included as part of the service and which require an additional charge.

Function	Charge Type	Routed and Managed Firewall	Customer Routed
Standard firewall	Included	Y	N
Distributed or advanced firewall	Charged	Y	Y
Routing, IPv4 static and dynamic (BGP)	Included	Y	N
Routing, IPv6	Included	Y	N
NAT	Included	Y	N
DHCP	Included	Y	N
VPN (Layer 2)	Included	Y	N
VPN IPsec Layer‑3 site to site	Included	Y	N
Route advertisement	Included	Y	N

Internal networks can be created per OVDC via the MPC Operational Console. Up to 1000 internal networks per OVDC are supported. Networks can span multiple OVDCs within the same IBX when configured in a datacenter group. Internal network types include:

• Routed - Uses the Edge Gateway as the router and provides access to WAN, colocation, CSPs, or internet. Routed networks are available only with Connectivity Routed.
• Isolated - No access to external networks unless attached to a self-managed router under Customer Routed connectivity.

Inter Site Networks allow two MPC sites in different datacenters to be connected by requesting a Managed Virtual Circuit between them. The network configuration depends on the selected connectivity type. Connectivity between the two datacenters is charged as a Managed Virtual Circuit. Connectivity between more than two datacenters is supported but requires a Fabric Cloud Router (FCR), Equinix Fabric IPWAN, and two Virtual Connections from the MPC zone and the Fabric Cloud Router.

note

Ordering and configuration of Fabric Cloud Router and IPWAN are outside the Managed Solutions scope.

---

Purchase Units Connectivity

Purchase Item	UOM	Calculation Type	Description
Connectivity Type	Once	Baseline	Routing instance per OVDC: • Routed • Customer Routed • Managed Firewall • Joined Routing
Managed Virtual Circuit	VC	Baseline	Available bandwidth options: 10 / 50 / 200 / 500 Mbps and 1, 2, 5, 10 Gbps Two (2) VCs are required per connection for redundancy
Managed Internet Access	Each	Baseline	Internet Access available at: 10 / 50 / 100 / 200 / 500 Mbps and 1, 2.5, and 10 Gbps Managed Virtual Circuits are included in Managed Internet Access.
Allocated IP space	Block	Baseline	Supported IPv4 /24 to / 29 and IPv6
Distributed Firewall (DFW)	vCPU Optimized vCPU Full	Baseline Overage	Additional functionality to support micro‑segmentation

---

MPC Operational Console provides automation tools and an API to manage MPC resources, including the following:

• Manage OVDCs across multiple Equinix data centers
• Create, import, and manage VMs and vApps
• Size VMs (scale up and down)
• Create VM snapshots
• Access VM consoles
• View performance statistics
• Create and populate the Library with ISO and OVA files
• Access the MPC self-service portal and VM consoles directly via web browser without VPN requirements
• Extensive options for scripting and automation (API)
• Separate or group VMs for availability or performance
• Manage firewall rules and microsegmentation
• Create and manage static and dynamic routing rules for IPv4
• Create and manage static routing rules for IPv6
• Create and manage NAT, DHCP, and VPN (Layer 2)
• Create and manage IPsec VPN Layer 3 site-to-site tunnels
• Create and manage route advertisements (VRF)

Accessing MPC Flex

To access Managed Private Cloud (MPC), go to the Customer Portal. From there, you can access the following:

• Managed Solutions Portal (MSP) – used to raise tickets, submit service requests, and view MPC usage insights.
• Operational Console – used to manage and operate MPC resources.

Regions

The Operational Console provides access to MPC resources within a specific region. MPC is available in four regions: South America, North America, Europe, and Asia.

Each MPC instance is associated with a region. When an instance exists in a region, you can open its corresponding Operational Console by selecting the regional option from the Managed Solutions area of the Customer Portal.

After you sign in to the appropriate regional console, your access to resources is organized by Organization and Organizational Virtual Datacenters (OVDCs).

Organization

An Organization (Org) represents the customer within the Operational Console. The Org can be viewed as a container for all MPC resources in that region, including virtual data centers, users, and content libraries. The Org name is required when signing in to the MPC Operational Console.

Organizational Virtual Datacenter (OVDC)

An Organizational Virtual Datacenter (OVDC) groups the compute, storage, and networking resources you use to run workloads. A single Org can contain multiple OVDCs, which may differ by IBX location (for example, Amsterdam, London, or Ashburn) or by compute performance profile. If you require additional capacity or an additional OVDC, contact your assigned Service Delivery Manager or Account Manager to request it.

Tenant Roles

note

The following Tenant Roles apply only to the Managed Private Cloud Single Tenant and Managed Private Cloud FLEX variants.

Tenant roles define the permissions and actions available to users within an MPC tenant. Roles are assigned to users after they are added through the Customer Portal. Roles determine what actions users can perform in the Operational Console and which API capabilities are available to them.

During the initial deployment of a new MPC environment, Equinix creates the first customer administrator account as part of the onboarding process. This account is created using the customer-provided name and email address, and is automatically assigned the Tenant Admin role, which provides full access to the MPC Operational Console, including tenant-level administration and configuration capabilities.

The following roles are supported:

Tenant Admin - The Tenant Admin role provides full administrative access to an MPC tenant. Users assigned this role can manage tenant configuration, user access, and automation capabilities across the environment. Tenant Admin permissions include:

• Access the VM console
• Create and delete snapshots
• Create and delete personal API tokens
• Create, modify, and delete organization-wide service accounts
• Create, modify, and delete virtual machines within the tenant scope
• Create, modify, and delete vApps within the tenant scope
• Create, modify, and delete networks within the tenant scope
• Create, modify, and delete content libraries and library content within the tenant scope
• Configure edge gateways within the tenant scope
• Configure affinity rules
• View tasks and event logs within the tenant scope

Tenant User - The Tenant User role allows users to create and manage workloads and selected resources within an MPC tenant, without access to tenant-wide administrative settings. Tenant User permissions include:

• Access the virtual machines console
• Create and delete snapshots
• Create and delete personal API tokens
• Start and stop virtual machines within the tenant scope
• Start and stop vApps within the tenant scope
• Update VM tools within the tenant scope
• View tasks and event logs within the tenant scope

Tenant Viewer - The Tenant Viewer role provides read-only access to tenant configuration and resource status. Users assigned this role can view the same resources and information available to the Tenant User role, with the following restrictions:

• No create, modify, or delete (CRUD) permissions for virtual machines or vApps
• No Console Access

Managing MPC Flex

User Management

Users of the Operational Console are managed through the Customer Portal. See User and Password management. Once users are added, a Service Request must be submitted to assign the MPC tenant role to the user.

To use a different identity source, identity federation can be configured in the Customer Portal to integrate with an external identity provider. This enables users to sign in using their company credentials.

API Access

Access to the Managed Private Cloud (MPC) Operational Console API is intended for programmatic access and automation. Common automation tools include Terraform, Ansible, Python, and XML- or JSON-based API calls. Authentication to the API requires generating access tokens in the Operational Console. Two access methods are supported, each designed for a different use case.

Method	Details
API tokens	• API access to the Operational Console on behalf of the Customer Portal or federated user accounts for individual programmatic access. • Can be configured by all Customer Portal or federated user accounts.
Service accounts	• API access to the Operational Console using standalone accounts intended for organization-wide automation and third-party tools or applications. • Can be configured only by users with the Tenant Admin role. • Can be assigned one of the supported roles. • Supports API access only.

Terraform Automation

Terraform is an infrastructure-as-code tool that allows cloud and on-premises resources to be defined using human-readable configuration files. These files can be versioned, reused, and shared, enabling a consistent workflow for provisioning and managing infrastructure throughout its lifecycle.

Terraform can be used to manage low-level resources such as compute, storage, and networking. Most Operational Console functionality is available through the API or Terraform. For more information, see the Terraform provider documentation.

API tokens

API tokens can be created by the Customer Portal or federated user account in the Operational Console and are used for personal programmatic access. Here's how to create an API token:

1. Sign in to the Operational Console. Open User preferences from the top-right menu.
2. Go to the API Tokens section and select New.
3. Enter a name for the token and select Create.
4. Copy and store the generated token in a secure location. The token is displayed only once and cannot be viewed again after closing this screen. If the token is lost, a new one must be generated.
5. After creation, the token appears in the API Tokens list and can be revoked when no longer needed.

Service Accounts

Service accounts can be created, viewed, and deleted only by users with the Tenant Admin role due to the sensitive nature of these accounts. Here's how to create a service account:

note

A service account is the owner of any objects it creates in the Operational Console.

1. Sign in to the Operational Console. Open Administration, then select Service Accounts and choose New.
2. Enter a name for the service account, assign a role, and use the magic wand to generate a unique ID. Select Next to continue.
3. (Optional) Assign one or more quota limits to the service account.
4. Select Finish to create the service account.
5. After creation, the API key is displayed in the Client ID field when viewing the service account properties. Most service account settings can be modified later by selecting Edit.

API Explorer

The API Explorer provides a graphical interface for viewing, testing, and executing API calls and is accessible through the Operational Console.

1. In the Operational Console, open the top-right menu and select Help > API Explorer.
2. The API Explorer exposes the Swagger‑based JSON API and allows API calls to be executed on behalf of the currently signed-in user account.

Operational Console

When a user is logged into the Customer Portal, the Operational Console can be accessed by navigating to the Managed Solutions Portal, selecting Managed Private Cloud, and then selecting the desired region.

If the Operational Console is accessed directly through its URL and Sign In is selected, the user is redirected to the Customer Portal to authenticate with Customer Portal credentials. The Customer Portal also supports configuration of SAML-based federation with an organization’s identity provider, enabling users to access the Operational Console using their company credentials.

From the Operational Console, actions can be performed to create virtual machines, networks, and security rules.

vApp

A vApp is a group of virtual machines within a virtual data center, for example, representing an application landscape. Virtual machines can be managed as a group, such as taking a snapshot or restarting them, and individual virtual machines can also be managed separately within a vApp. Virtual machines and vApps can be assigned a lease period, after which they are automatically removed. The default lease is set to never expire.

A vApp can be created with or without virtual machines. Creating a vApp without virtual machines can be useful when setting up the vApp network before creating the virtual machines.

Create a new vApp

1. Go to the main page under Applications > vApps, select Build New vApp, provide a name and description, and select Build. Wait for the process to complete.
2. Options in the vApp window:
   • Select Power to turn the vApp on, shut it down, restart it, or pause it. These actions are available only if the vApp contains a virtual machine.
   • Select More to add or remove a virtual machine from the vApp.
   • Select Details to view or modify additional information.

Virtual Machines

Virtual machines can be created either as part of a vApp or as standalone virtual machines. Creating virtual machines within a vApp is recommended. A vApp can contain up to 100 virtual machines, and virtual machines can be moved between vApps. Networks can also be created between virtual machines that reside in different vApps.

Creating virtual machines as part of a vApp provides several benefits, such as grouping virtual machines by task, function, or retention requirements; configuring startup and shutdown order; improving visibility of network configuration through the vApp network diagram; and enabling delegated management through role-based access.

Allocated storage resources and allocated GB RAM are counted as used storage under the assigned storage policy. When a virtual machine is started, compute resources are deducted from the compute quota of the organization virtual data center (OVDC).

The most common operating system installation method for a new virtual machine includes selecting an ISO file from the private or shared Equinix catalog, allowing the virtual machine to boot from the ISO file when powered on and begin the installation process. Another option is to create a new virtual machine and vApp from an OVF or OVA file on the administrator’s workstation during the creation workflow.

Create a virtual machine

1. Go to Applications > Virtual Machines and select Create VM, or select More on a vApp and choose Add VM.
2. Follow the steps in the creation dialog, then select OK and wait for the virtual machine to be created.
   1. Enter a name and computer name.
   2. Select New for the type.
   3. Choose whether the virtual machine should start automatically after creation.
   4. Select the OS family, guest OS, and boot image.
   5. Configure boot options, including EFI Secure Boot and boot setup.
   6. Configure Trusted Platform Module (TPM) settings, if required.
   7. Configure compute resources, including CPU, cores, and memory.
   8. Configure storage, including storage policy and disk size.
   9. Configure networking settings.
3. In the Virtual Machines screen:
   1. Select Power to turn the virtual machine on or off, restart it, or pause it.
   2. Select More to mount installation media, manage snapshots, open the console, or delete the virtual machine.
   3. Select View to display or modify configuration details and additional settings.

Link installation media from catalog to a VM

If a catalog is already available and installation media has been uploaded, it can be attached to the virtual machine.

1. Locate the virtual machine and select More.
2. Select Insert Media and choose the installation file. The file is connected as a virtual CD-ROM.
3. After the job completes, it is recommended to detach the installation file by selecting Eject Media.

VM Console

A virtual machine can be managed through the Operational Console. Two console types are available:

• Web Console which works from your browser.
• VM Remote Console which requires installing a plug-in.

Installation media (ISO) cannot be used directly from a local device. Media must be uploaded to a catalog before it can be mounted to a virtual machine.

The VM Remote Console plug-in for Windows devices is available in the shared catalog. For macOS and Linux (including Windows via Workstation), VMRC functionality is included in VMware Fusion Pro and VMware Workstation Pro. These applications require separate licensing and are not included with MPC or provided by Equinix.

1. Locate the virtual machine from the vApp or the Virtual Machines overview.
2. Select More and choose the desired console type: the Web Console (no plug-in required) or the VM Remote Console (plug-in required).

Snapshots

A snapshot captures the state of a complete virtual machine or vApp before an action is performed. The Operational Console allows only one snapshot at a time, with or without the active memory state. Taking a snapshot temporarily doubles the storage usage of the virtual machine or vApp. Snapshots can affect virtual machine performance. It is recommended to retain snapshots for a maximum of 2-3 days; snapshots older than one week are removed automatically. For longer-term preservation of a virtual machine state, create a clone or perform a backup of the virtual machine or vApp.

1. Locate the virtual machine or vApp, select Actions > Snapshot, and choose Create Snapshot, then confirm.
2. To restore the virtual machine to the snapshot state, select Revert to Snapshot and confirm.
3. To delete the snapshot, select Remove Snapshot and confirm.

note

When a new snapshot is created from a VM with an existing snapshot, the old snapshot is removed. To have access to all snapshot options, VMware Tools must be installed on the VM.

Catalogs

The catalog in the Operational Console stores vApps, virtual machines, and media files (such as ISO images). Equinix provides a shared catalog with a set of ISO files. The shared catalog is associated with the OVDC, specifically the environment's metro.

A private catalog can also be created to store installation media or templates. Files can be uploaded directly, or templates can be created from existing virtual machines or vApps. Files stored in the private catalog count toward the OVDC storage quota. All uploaded software must comply with vendor licensing requirements and Equinix policies. The catalog may be used only for ISO and OVF files.

Create a catalog

To store installation media or templates, a catalog must first be created.

1. On the home screen, select the menu icon (three horizontal lines).
2. In the Content Hub screen, select Catalogs, then choose New.
3. Enter a name and description for the catalog. Catalogs can be stored on any available storage profile. By default, the fastest profile is selected. To choose a specific storage profile, enable Pre-provision on a specific storage policy, select the ORGOVDC, and choose the required storage policy.

Add installation media

When the catalog is available, installation media can be uploaded to it.

1. Go to Content Libraries > Media & Other and select Add.
2. In the new screen, select the catalog, click the upload icon (arrow pointing up) to open the file browser. Select the installation file and confirm with OK.
3. Edit the name if required and select OK to start the upload. In the Media & Other overview, a rotating indicator appears while the upload is in progress. A green check mark appears when the upload is complete. The file is then ready for use.
4. Selecting the three dots next to the file name provides options to delete the file or download it to the workstation.

Create a vApp Template

A vApp template can be created by uploading a file from a local workstation or by using an existing vApp. A template for a single virtual machine based on a vApp can only be created if the vApp contains exactly one virtual machine.

1. Locate the vApp to be used as the source, select More, and choose Add to Catalog. Select the destination catalog and enter a name. An exact copy can be created, or virtual machine settings can be adjusted if VMware Tools are installed before template creation.
2. To access the vApp template, go to Content Hub > Catalogs and open the relevant catalog. Once available, the template can be used to deploy new virtual machines.

Shared Catalogs

Equinix provides a shared catalog (OS-CATALOG-1) per MPC metro that contains a set of operating system variants. Select the catalog associated with the metro where the virtual machine will be deployed. The shared catalog is associated with the MPC variant (FLEX or ST) in that metro. If both MPC FLEX and MPC ST are used in the same metro, two catalogs for that metro will be visible.

Connectivity

The Operational Console provides several options for connecting and accessing services within the organization or externally. Depending on the selected connectivity model, an OVDC is created with either Bridging (MPC Connectivity Customer Routed in the order) or Routing (MPC Connectivity Routed in the order).

Networks

The available network functions in the Operational Console vary depending on whether Customer Routed or Routed connectivity is selected.

In the Operational Console, two types of networks can be created through Self-Service:

• Isolated network (internally connected): An isolated network exists only for virtual machines within the OVDC.
• Routed network (externally connected): A routed network provides access to external networks outside the OVDC through the edge gateway.

MPC Connectivity Type	Isolated	Routed
Bridging	Yes	No
Routing	Yes	Yes

MPC Gateway Firewall Architecture

MPC uses a layered gateway firewall architecture that combines perimeter and workload-level controls to secure both North–South and East–West traffic. The MPC Firewall design includes two main types or layers of firewalls:

• Gateway Firewalls (North–South): Protect the MPC perimeter and handle traffic entering or leaving the environment.

• Distributed Firewall (East–West): Protect workloads at the vNIC level and provide micro‑segmentation within the OVDC.

Create an isolated OVDC Network

An organization virtual data center (OVDC) network enables virtual machines (VMs) to communicate with each other and, optionally, with external networks. A single OVDC can contain multiple networks.

1. In the Operational Console Virtual Datacenters dashboard, select the OVDC where the network will be created.
2. In the left navigation panel, select Networks.
3. Click New.
4. Under Scope, select the current OVDC for the isolated network.
5. In the Network Type page of the New Organization VDC Network dialog box, select Isolated, then click Next.
6. In the General page, enter a Name and Description for the network.
7. In the Gateway CIDR field, select the IP space for the network from the dropdown list. This list is pre-populated by Equinix based on customer input during deployment.
8. Dual Stack can be enabled when IPv6 is required.
9. Guest VLAN Allowed can be enabled to permit multiple VLANs within connected VMs.
10. Click Next.
11. (Optional) In Static IP Pools, enter a range of IP addresses for VMs on this network and click Add. This allows the Operational Console to automatically assign IP addresses during VM creation. If not configured, IP assignment must be done manually during VM creation. Example: If the gateway address is 192.168.1.1/24, a static IP pool of 192.168.1.10–192.168.1.100 provides 91 usable IP addresses. Additional ranges can be added later if needed.
12. When finished, click Next.
13. (Optional) In the DNS page, enter DNS information, then click Next. If omitted, DNS settings must be entered manually when creating VMs.
14. On the Ready to Complete page, review all settings and click Finish.

Create a routed OVDC Network

A routed OVDC network enables virtual machines (VMs) to communicate with each other and to external networks using Layer 3 (L3) routing. A single OVDC can contain multiple routed networks. The creation process differs depending on whether Distributed Firewall functionality is used.

1. In the Operational Console Virtual Datacenters dashboard, select the OVDC where the network will be created.
2. In the left navigation panel, select Networks, then click New.
3. Under Scope, select Current Organization Virtual Data Center if Distributed Firewall is not being used.
4. In the Network Type page of the New OVDC Network dialog box, select Routed, then click Next.
5. Under Edge Connection, select the Edge Gateway that the routed segment will connect to.
6. In the General page, enter a Name and Description for the network.
7. In the Gateway CIDR field, select the IP space for the network from the dropdown list. This list is pre-populated by Equinix based on the customer inputs provided during deployment.
8. Enable Dual Stack if IPv6 is required.
9. Enable Guest VLAN Allowed to permit multiple VLANs within connected VMs.
10. Click Next.
11. (Optional) In the DNS page, enter DNS settings, then click Next. If not configured here, DNS information must be added manually during VM creation.
12. On the Ready to Complete page, review the selections then click Finish. After the network has been created and connected to the OVDC, the Edge Gateway can be configured to control which traffic is allowed into and out of the OVDC.

When using a Distributed routed network:

• Traffic between Distributed networks is firewalled using the Distributed Firewall because it does not traverse the Edge Gateway.
• Traffic entering or leaving the environment passes through the Edge Gateway, where gateway firewalling applies.
• The Distributed Firewall requires the MPC Service Option for Distributed Firewall, which must be ordered as part of the MPC contract.

note

If Distributed Routing is enabled, Gateway Firewalls are not available for this network and the Distributed Firewall (DFW) must be used. North–South firewalling remains available. If Distributed Routing is disabled, only Gateway Firewalls are available for this routed network.

Guest VLAN Allowed

Enabling this option allows VLAN tags (802.1Q TAGs) to be configured on the network interfaces of virtual machines. This allows multiple VLANs to be operated on the same routed or isolated network segment.

Create Gateway Firewall Rules

The Operational Console provides a fully featured Layer 4 firewall to control traffic moving across security boundaries—both North-South (traffic between the OVDC and external networks) and East-West (traffic within and between OVDC networks). When specifying networks or IP addresses for firewall rules, the following formats are supported:

• A single IP address
• IP ranges (e.g., 192.168.1.10–192.168.1.50)
• CIDR notation (e.g., 192.168.2.0/24)
• Keywords: internal, external, or any

1. In the Operational Console Virtual Datacenters dashboard, select the OVDC containing the Edge Gateway where the firewall rules will be created.
2. In the left navigation panel, click Edges. The available Edge Gateways will appear on the right.
3. Select the Edge Gateway to configure, then open the Firewall tab.
4. In the Firewall tab, firewall rules can be created and managed.
5. Click New to add a new rule. For the new rule, specify the following fields:
   • Name
   • Applications
   • Context
   • Source (IP address, IP sets, Static Groups)
   • Destination (IP address, IP sets, Static Groups)
   • Action (Allow, Drop, Reject)
   • Protocol (IPv4, IPv6, or both)
   • Logging
   • Comments
6. In the Source and Destination fields, define the addresses for the rule. To specify an IP or range, click IP and enter the Value, then click Keep. To reuse groups of IPs, go to Grouping Objects and click + to create an IP Set. This IP Set can then be selected for multiple rules.
7. In the Application field, click + then in the Add Service dialog box, specify the Protocol, Source Port and Destination Port. Or define a custom protocol/port combination. When done, click Keep. Custom applications can also be created in advance and applied to firewall rules.
8. Choose whether the rule’s Action is Accept (Allow) or Deny (Drop/Reject). If a syslog server is configured, select Enable logging.
9. Click Save changes to finalize the rule.

An example of a firewall rule is to allow HTTPS traffic from the internet. This example uses allocated public IP addresses. The source is any (any IP address within the OVDC). The source port is also any. The destination is a private IP address and the destination port is 443 for HTTPS. For this to work you need a DNAT configuration.

Create NAT rules

Network Address Translation (NAT) allows the source or destination IP address to be changed so that traffic can pass through a router or gateway. The most common types of NAT on the Edge Gateway are:

• Destination NAT (DNAT) - changes the destination IP address of the packet.
• Source NAT (SNAT) - changes the source IP address of the packet.

Other options are:

• NO DNAT
• NO SNAT
• REFLEXIVE

For a virtual machine (VM) to access an external network resource from its OVDC, NAT may be required in certain use cases. In these cases, use one of the following options:

• Public internet IP addresses provided by Equinix.
• Private networks via MPC Connect.

note

• This functionality is primarily applicable when the Edge Gateway is configured with public IP addresses and VMs are using private IP addresses.
• NAT rules function only when the firewall is enabled. The firewall should remain enabled at all times.

DNAT changes the destination IP address of a packet and performs the reverse operation for reply traffic. DNAT can be used to expose a service running on a private network through a public IP address.

1. In the Operational Console Virtual Datacenters dashboard, select the OVDC that contains the Edge Gateway where the DNAT rule is created.
2. In the left navigation panel, click Edges. Select the NAT tab and add a new NAT rule.
3. In the NAT section, click + DNAT Rule.
4. In NAT Action, select the type of NAT rule.
5. Enter an External IP (for example, 10.30.40.95).
6. Enter an External Port (for example, 443).
7. Enter an Internal IP (for example, 192.168.1.10).
8. Advanced Settings
   • State - enables or disables the rule
   • Logging - logs the rule
   • Priority - lower values mean a higher priority while 0 is the default value
   • Firewall Match
     • Match Internal Address
     • Match External Address
     • Bypass
   • Applied To - leave blank
9. If a syslog server is configured, select Enable logging.
10. When finished, click Keep, then Save changes.

Create SNAT rules

SNAT changes the source IP address of a packet and performs the reverse operation for reply traffic. When accessing external networks, such as the internet, an SNAT rule is required to translate internal IP addresses to an address available on the external network.

1. In the Operational Console Virtual Datacenters dashboard, select the OVDC that contains the Edge Gateway where the SNAT rule is created.
2. In the left navigation panel, click Edges. Select the NAT tab and add a new NAT rule.
3. In the NAT section, click + SNAT Rule.
4. In NAT Action, select SNAT.
5. External IP - the external network (usually named VCD_CUSTOMER_WAN).
6. Internal IP - the network or IP address translated for internet access.
7. Advanced Settings
   • State - enables or disables the rule
   • Logging - logs the rule
   • Priority - lower values mean a higher priority while 0 is the default value
   • Firewall Match
     • Match Internal Address
     • Match External Address
     • Bypass
   • Applied To - leave blank
8. When finished, click Keep, then Save changes.

Create NO SNAT rules

NO SNAT rules negate existing SNAT rules. A NO SNAT rule can be created to bypass SNAT for traffic destined for a specific IP address. To ensure correct processing order, the NO SNAT rule must be assigned a higher priority (lower numerical value) than the SNAT rule. The default priority is 0, which is the highest priority.

1. In the Operational Console Virtual Datacenters dashboard, select the OVDC that contains the Edge Gateway where the NO SNAT rule is created.
2. In the left navigation panel, click Edges. Select the NAT tab and add a new NAT rule.
3. In the NAT section, click + No SNAT Rule.

Configure IPsec VPN

Operational Console supports the following types of site-to-site VPN connections:

• An Edge Gateway within the same organization
• An Edge Gateway in another organization (Equinix or another vCloud service provider)
• A remote network that provides an IPsec VPN endpoint, such as a cloud service provider or a colocation environment

Depending on the connection type, IP addressing must be configured for both endpoints, along with a shared secret. The OVDC networks that are permitted to communicate over the VPN connection must also be specified.

Before configuring IPsec VPN settings, take note of the IP address of the Edge Gateway to be used as the tunnel endpoint.

• In the Operational Console Virtual Datacenters dashboard, select the OVDC that contains the Edge Gateway to be configured.
• In the left navigation panel, click Edges.
• On the Edges page, select the Edge Gateway.
• In the Services tab, locate the IPsec VPN option and click New to create a new IPsec VPN configuration.

Configure the edge gateway IPsec VPN settings

1. Configure a name, enable Login to view logs, and leave the remaining options set to their default values.
2. Peer Authentication Mode

• Pre-Shared Key: The shared secret used to authenticate and encrypt the connection. It must be an alphanumeric string between 32 and 128 characters and include at least one uppercase letter, one lowercase letter, and one number. This value must be the same on both sites.
• Certificate: To use a certificate, upload the certificate and the CA certificate.

3. Endpoint Configuration

   Local Endpoint

   • IP Address: The external IP address of the edge gateway.
   • Networks: Enter the organization networks that can access the VPN. Separate multiple local subnets with commas.

   Remote Endpoint

   • IP Address: The external IP address of the remote site, on‑premises firewall, or edge gateway where the VPN is configured.
   • Networks: The subnet on the on‑premises network that should be accessible from the OVDC. For example, if on‑premises networks use the 172.20.0.0/16 range, enter 172.20.0.0/16, or a smaller subnet such as 172.20.0.0/25.
   • Remote ID:
     • This value uniquely identifies the peer site and depends on the tunnel authentication mode. If not specified, the remote ID defaults to the remote IP address.
     • Pre-shared Key: The remote ID depends on whether NAT is configured. If NAT is configured on the remote ID, enter the private IP address of the remote site. Otherwise, use the public IP address of the remote device terminating the VPN tunnel.
     • Certificate: The remote ID must match the SAN (Subject Alternative Name) of the remote endpoint certificate, if present. If the remote certificate does not include a SAN, the remote ID must match the distinguished name of the certificate used to secure the remote endpoint.

4. When configuration is complete, click Keep to create the edge end of the VPN tunnel, then click Save changes.

Create the second VPN gateway

If this endpoint is in a different OVDC, repeat the steps to create the tunnel. After the tunnel is created, update firewall settings and validate the connection. If connecting to an external data center, configure the tunnel on those premises.

IKE Phase 1 and Phase 2

IKE (Internet Key Exchange) is a standard mechanism for establishing secure, authenticated communications. The following lists the supported configuration parameters for Phase 1 and Phase 2.

Phase 1 parameters

Phase 1 establishes peer authentication, negotiates cryptographic parameters, and generates session keys. Supported Phase 1 parameters are:

• Main mode
• AES/AES256/AES-GCM (user configurable)
• Diffie-Hellman group
• Pre-shared secret (user configurable)
• SA lifetime of 28800 seconds (eight hours), with no kbytes rekeying
• ISAKMP aggressive mode disabled

Phase 2 parameters

IKE Phase 2 negotiates the IPsec tunnel by generating keying material, either by deriving it from the Phase 1 keys or by performing a new key exchange. Supported Phase 2 parameters are:

• AES/AES256/AES-GCM (matches the Phase 1 setting)
• ESP tunnel mode
• Diffie-Hellman group
• Perfect forward secrecy for rekeying (only if enabled on both endpoints)
• SA lifetime of 3600 seconds (one hour), with no kbytes rekeying
• Selectors for all IP protocols and all ports between the two networks, using IPv4 subnets

Configure the edge gateway firewall for VPN

After the VPN tunnel is established, create firewall rules on the edge gateway for traffic passing over the tunnel.

• Create firewall rules for both traffic directions: data center to OVDC and OVDC to data center.
• For data center to OVDC, set:
  • Source to the source IP range of the external OVDC or data center network
  • Destination to the destination IP range of the OVDC network
• For OVDC to data center, set:
  • Source to the source IP range of the OVDC network
  • Destination to the destination IP range of the data center or VDC network

Validating the tunnel

After both ends of the IPsec tunnel are configured, the connection should establish automatically.

To verify tunnel status in the Operational Console:

1. On the Edges page, select the edge to configure and click Configure Services.
2. Select the Statistics tab, then select the IPsec VPN tab.
3. For each configured tunnel, a tick indicates that the tunnel is operational. If a different status is displayed, review the tunnel configuration and firewall rules.
4. Traffic can now be sent over the VPN.

note

After the tunnel is established, it can take up to two minutes for the VPN connection to be shown as active.

Create OVDC Distributed Firewall Rules

At the Org OVDC level, the distributed firewall can be used to apply micro‑segmentation via the Operational Console.

note

Using distributed firewall rules requires the MPC service option Distributed Firewall to be enabled.

Before you begin

• IP Set: Used as a source or destination in a rule. Create an IP Set for use in firewall rules and DHCP relay configuration. IP Sets are commonly used to group resources outside the VCD organization, such as the internet or a company WAN. In these cases, IP addresses or subnets are used.
• Static Groups: A static group contains one or more networks. When a static group is used in a distributed firewall rule, the rule applies to all VMs connected to the networks in the group.
• Dynamic Groups: Used to group VMs based on VM name, security tag, or both. By default, a dynamic group contains one criterion and one rule. It can be extended to up to three criteria, with up to four rules each.

Create distributed firewall rules

1. In the Operational Console Virtual Datacenters dashboard, select the OVDC that contains the distributed firewall to configure.
2. In the left navigation panel, click Networking / Datacenter Groups / Distributed Firewall.
3. Click + to add a new row to the firewall rules table.
4. For the New Rule, specify a Name.
5. In the Source and Destination fields, specify the source and destination addresses for the firewall rule.

• Firewall groups

• IP Sets: Select NEW, then provide a name, description, and IP range or CIDR.

• Static Groups: Select NEW, provide a name, and click Save.

  Select Manage members to add new members.

  Select a network to add to the static group.

  The Associated VMs view shows which VMs are connected to the attached networks.

• Dynamic Groups: Select NEW, provide a name, and select the criteria type to use.

• Firewall IP Addresses: Add an IP address, CIDR, or range, then select Keep.

  1. Select Action (Allow, Drop, or Reject).
  2. Select IP Protocol (IPv4, IPv6, or both).
  3. Configure Logging, if required.
  4. Select Save.

Service Description

MPC Flex Service Options

MPC Flex includes several service options that are ordered separately.

VM Replication for Disaster Recovery

MPC Disaster Recovery is a self‑service option that provides crash‑consistent VM replication using three customer‑selectable SLA profiles. It supports replication between FLEX and ST deployments, including mixed configurations. The secondary datacenter VDC may use lower‑capacity compute or storage, provided it is sufficient for the expected workload.

For disaster recovery to succeed, the VDC and network topology must support connectivity to the internet, on‑premises locations, or a cabinet in the secondary datacenter. Self‑service testing of VM failovers is supported to verify that failover behavior meets requirements.

To configure the service, virtual machines can be assigned to an SLA profile in the Operational Console. When replication is activated, VM data is replicated to the selected secondary VDC.

MPC Disaster Recovery provides the following SLAs:

Parameter	Value	Description
RPO	Gold: 1 hour Silver: 4 hours Bronze: 24 hours	Timeframe in which the replication is finished.
RTO	30 minutes	Timeframe within which the VM must be started in the secondary datacenter after customer‑initiated failover. RTO starts after failover is initiated by customer.
# Retention points	Gold: latest + 8 points Silver: latest + 6 points Bronze: latest + 2 points	All profiles consist of the latest restore point plus a defined number of automatically stored restore points. Maximum restore point age is 2 days.

The disaster recovery feature uses I/O filter-based capture technology. This approach avoids performance impact associated with snapshot-based replication.

When a failover is required, the customer can initiate the failover of workloads to the secondary datacenter through the Operational Console. Virtual machines are replicated according to the selected SLA profile, and the replication networks are operated and monitored by Equinix as part of the service.

Customer-related connectivity, including VM and application attachment, is outside the scope of the MPC Disaster Recovery option and must be prepared in advance to ensure connectivity between datacenters, the internet, cabinets, and on‑premises locations.

When the primary datacenter becomes operational again, the customer reverses the replication direction in the Operational Console. After replication is restored, VMs and applications can be moved back to the primary datacenter at a suitable time chosen by the customer.

Responsibilities for effective disaster recovery include understanding which activities affect performance and capacity, and how they are divided between Equinix and the customer.

Activities	Equinix	Customer
Selecting suitable MPC compute and storage for the DR site	I	RAC
Making the selected SLA profile available in the Operational Console	I	RAC
Configuring disaster recovery in the Operational Console	I	RAC
Ensuring DR site capacity is sufficient for disaster recovery	I	RAC
Managing replication infrastructure and connectivity	RAC	I
Configuring customer connectivity and networks during failover	I	RAC

Purchase Units for the MPC Disaster Recovery feature are based on a per‑VM, per‑month model tied to the selected SLA profile in the primary datacenter, and pricing includes the replication connectivity and bandwidth. Compute and storage capacity consumed in the secondary datacenter are part of the MPC service, while multi‑site networking connectivity for VMs is required separately.

Purchase Item	Tier	UOM	Calculation Type	Description
Service Option – Disaster Recovery	Bronze Silver Gold	VM	Baseline Overage	Replication of a VM to a selected secondary MPC VDC in another datacenter, according to the selected SLA.

Metering is calculated by counting replicated VMs daily based on their assigned SLA profiles, with VMs that move between SLA profiles during a month billed according to the duration spent on each applicable profile.

Relations and Dependencies

• MPC Disaster Recovery is available only with MPC Flex and/or MPC ST.
• The service option requires two MPC VDCs in different datacenters.
• The service option is available only for selected datacenter combinations.

Backup and Restore for MPC resources are provided through the Managed Private Backup Service, which is ordered separately. The service includes backup of VM data or application data.

A Software Catalog is available in the self-service portal. The catalog lists software that can be used in VMs running in OVDCs and includes both open-source and licensed software. The licensed software catalog includes Microsoft SPLA - Windows Server.

Software Licensing Purchase Units

Purchase Unit	Type	Charge Type	UOM	Ordering and Billing
Windows Server per vCPU	Standard	Baseline and Overage	vCPU	Baseline and overage model per vCPU for the vCPUs of VMs that are powered on.

In addition to the catalog, software licenses can be ordered through the Equinix Software License Service.

Bring Your Own License allows customers to use existing software licenses, subject to validation of vendor licensing terms, with customers remaining fully responsible for compliance with all software vendor licensing requirements.

The Support Plan provides additional services, including service requests, enhanced support, reporting, and design assistance. The Managed Solutions Premier Support Plan is a prepaid program offering monthly or annual support hour blocks at a discounted rate. Support time is calculated in 15-minute increments. Without a prepaid plan, support is charged per hour at the Premier Support Service standard rate, calculated in 15-minute increments.

Purchase Unit	Type	Charge Type	UOM	Ordering and Billing
Technical Support Plan	Monthly	Baseline	Hour	Monthly reservation of hours for technical support
Technical Support Plan	Annual	Baseline	Hour	Yearly reservation of hours for technical support

The support plan applies to all Managed Solutions products. If allocated hours are exceeded, additional hours are billed at standard Premier Support Service rates. Unused monthly or prepaid hours do not roll over and are forfeited. Usage beyond prepaid limits is billed at standard rates unless the plan is upgraded. The plan is country-specific and not tied to a specific IBX datacenter.

Migration Support enables customers to move workloads from on‑premises environments to MPC using tooling that supports VMware workloads from vSphere or Cloud Director without application refactoring. Customers deploy an appliance in their VMware environment that pairs with the MPC environment, using asynchronous replication. Migration is supported over the internet by default, or over a private Equinix Fabric connection on request. Fabric‑based migration requires dedicated virtual circuits and supports speeds up to 10 Gbps; internet-based migration supports speeds up to 400 Mbps. The tooling is free to use, with additional assistance available through the Support Plan.

Connection	Speed	Network Configuration
Internet	Up to 1 Gbps	No
Fabric	Up to 10 Gbps	Yes, set up VLANs

MPC Flex Service Demarcation and Enabling Services

With MPC, Equinix provides an Infrastructure‑as‑a‑Service platform that includes datacenter facilities, datacenter networking, compute, storage, and virtual networking. Equinix manages the service up to the hypervisor layer and provides the platform licensing for virtualization. Resources are delivered in a logically separated environment, and an Operational Console is available for customers to manage their environment.

Customers are responsible for managing their own workloads. This includes creating and managing virtual machines, storage, virtual networks, security policies, and capacity, as well as providing the required licenses for operating systems and applications.

Limitations

MPC Flex is a managed service with limitations on self-service access and functionality to maintain performance, availability, and security.

General

• Access to vSphere or vCenter functionality is available only through the MPC Operational Console and APIs.
• Integration with vCenter and vSphere is limited to the functionality exposed through the MPC Operational Console.

Compute

• Creating VM snapshots is limited to a single concurrent snapshot per VM.

Virtual disks

• Moving virtual disks between VMs through the MPC Operational Console or APIs is not supported; a support ticket must be created through the Equinix support desk.
• Sharing a virtual disk between multiple VMs is not supported; Microsoft Windows Server Failover Clustering (WSFC) with shared disks is not supported.

Network

• Single Root I/O Virtualization (SR-IOV) and direct physical NIC access from VMs are not supported.

MPC Flex Purchase Units

The MPC service is charged monthly based on Baseline values or Baseline with Overage charge types. Service functionality is described in the relevant sections of this service description.

Charge Types

• Baseline - The specific volume of the service unit of measure as defined in the order
• Overage - The quantity of the service consumed that exceeds the contracted Baseline volume

Catalog of Purchase Units

The table lists the purchase units for Managed Private Cloud, including unit of measure and billing method:

Category	Purchase Unit	UOM	Install Fee	Billing Method	Overage
MPC Service	Connectivity – Routed	Each		Baseline
	Connectivity – Customer Routed	Each		Baseline
	Connectivity – Managed Firewall	Each		Baseline
	Connectivity – Joined	Each		Baseline
MPC Compute	vCPU – Full	vCPU		Baseline	Yes
	vCPU – Optimized	vCPU		Baseline	Yes
MPC Memory	vRAM	GB		Baseline	Yes
MPC Storage	High Performance	TB		Baseline	Yes
	Performance	TB		Baseline	Yes
MPC Service Option	Network – Managed Virtual Circuit (xx Mbps)	Each	Yes	Baseline
	Network – Managed Internet Access (xx Mbps)	Each		Baseline
	Network – Additional IP space /24/25/26/27/28/29	Each		Baseline
	Network – External network	Each	Yes	Baseline
	Network – Distributed Firewall per vCPU – Full	vCPU		Baseline	Yes
	Network – Distributed Firewall per vCPU – Optimized	vCPU		Baseline	Yes
	License – Windows Server per vCPU	vCPU		Baseline	Yes
	Disaster Recovery Gold/Silver/Bronze	VM		Baseline

Calculation of Overage Values measures MPC consumption multiple times per day, using the maximum daily value for the Overage calculation. The monthly Overage value is determined by summing the daily maximums and dividing by the number of days in the billing month. The number of days is defined as the period from the second‑to‑last day before the start of the month through the second‑to‑last day of the following month. For example, Overage for October is based on consumption from 29 September to 30 October.

MPC Flex Roles & Responsibilities

Service fulfillment and delivery involve responsibilities for both Equinix and the customer.

Onboarding

Activities	Equinix	Customer
Schedule / execute project kickoff meeting	RA	CI
Schedule / execute customer onboarding	RA	CI
Delivery of the OVDC in accordance with the order	RA	I¹
Delivery of the agreed compute capacity in accordance with the order	RA	I¹
Delivery of the agreed storage capacity in accordance with the order	RA	I¹
Delivery of the connectivity type in accordance with the order	RA	I¹
Delivery of the Managed Virtual Circuits in accordance with the order	RA	C
Delivery of the Managed Internet Access in accordance with the order	RA	C
Delivering the agreed network functionality in accordance with design (optional)	RA	C
Delivery of the MPC Operational Console	RA	I¹
Delivery of the admin account for the Operational Console	RA	I¹

Acceptance into Service

After onboarding activities are completed, testing activities confirm that the product has been delivered successfully and is ready for billing.

Activities	Equinix	Customer
Test access to MPC product page on Managed Solutions Portal	CI	RA
Test access to MPC documentation on docs.equinix.com	CI	RA
Test access to MPC operational console	CI	RA
Confirm MPC fulfillment based on preview evidence	CI	RA
Set product as enabled for customer on internal systems	RA	I

Operational

After Managed Private Cloud is enabled for customers, the following operational items apply:

Activities	Equinix	Customer
Technical management of the service (overall)	RAC	I¹
Functional management of the customer environment within the service (overall)	I²	RAC
MPC infrastructure monitoring and maintenance	RA	I
Create, import, and manage VMs and vApps	I²	RAC
Scale VMs up and down	I²	RACI
Manage VM snapshots		RACI
Manage access to VMs with console		RACI
Request performance statistics		RACI
Create and fill Library with customer’s own ISO/OVA files		RACI
Separate or group VMs for availability or performance	I²	RAC
NFV: Virtual L2 networks	I²	RAC
NFV: Standard firewalling	I²	RAC
NFV: Routing (static)	I²	RAC
NFV: Routing (dynamic OSPF / BGP)	I²	RAC
NFV: NAT	I²	RAC
NFV: DHCP	I²	RAC
NFV: Load balancing	I²	RAC
NFV: VPN (IPsec, Client)	I²	RAC
Setup and manage scripting and automation capabilities		RACI

RACI stands for Responsible, Accountable, Consulted and Informed.

1. Informing is only mandatory for tasks that have an impact on the functioning of the user environment.
2. Informing is only required for tasks that have an impact on the operation and/or management of the service.

MPC Flex Incident Management

Incident Management is included as part of service support. All incidents are handled based on priority. Priority is determined after an incident is reported and assessed by Equinix based on the information provided.

Priority	Impact / Urgency	Description
P1 High	Unforeseen unavailability of a service or environment delivered and managed by Equinix, in accordance with the service description, due to a disruption. The user cannot fulfil its obligations toward its users. The user suffers direct demonstrable damage due to the unavailability of this functionality.	The service must be restored immediately; the production environments are unavailable, with platform‑wide disruptions.
P2 Medium	The service does not offer full functionality or has partial functionality or reduced performance, because of which users are impacted. The user suffers direct demonstrable damage due to limited availability of this functionality.	The service must be repaired the same working day; the management environment is not available.
P3 Low	The service functions with limited availability for one or more users, and there is a workaround in place.	The moment of repair of the service is determined in consultation with the reporting person.

note

This above classification does not apply to disruptions that are, for example, caused by user-specific applications, actions by the user, or dependent on third parties. The incidents can be submitted through the Customer Portal in the Managed Solutions section. P1 incidents need to be submitted by phone.

MPC Flex Service Requests

Service requests are used to report service issues or to request implementation or assistance with changes. Service requests can be raised for configuration changes that cannot be implemented through self-service in the Operational Console. Support for the Managed Private Cloud service is available 24x7x365. Two types of service requests are available:

• Included - Service requests that are within the scope of the service and do not incur additional charges
• Additional - Service requests that are outside the scope of the service and incur additional charges

Request Name	Included / Additional
Create a DC group over multiple OVDCs	Additional
Change external access OVDC API	Additional
Add a user for the Operational Console	Included
Remove a user from the Operational Console	Included
Change permissions for a user	Included

Changes not listed above can be requested by selecting Change in the service request module. Equinix performs an impact analysis to determine feasibility, associated costs, and lead time. Any charges related to service requests are deducted from the Premier Support Plan balance (see the Premier Support service description for details). If the balance is insufficient, charges are invoiced in arrears at the prevailing rate. Requests that impact baseline capacity, ordered quantities, or monthly service fees must be submitted through the sales team.

MPC Flex Reporting

As part of the service, customers receive monthly service reports covering the following topics:

• Raised tickets against SLA parameters
• Capacity per OVDC

MPC Flex Service Levels

This Service Level Agreement (SLA) defines the measurable performance levels applicable to the MPC service and specifies the remedies available to the customer if Equinix fails to meet these levels. The service credits listed below are the sole and exclusive remedy for failure to meet the service level thresholds defined in this section. The SLA for support applies to the incident registration and resolution.

Priority	Response Time¹	Resolution Time²	Execution of Work	SLA³
P1	< 30 min	< 4 hours	24 × 7	95 %
P2	< 60 min	< 24 hours	24 × 7	95 %
P3	< 120 min	< 5 days	24 × 7	95 %

1. Response time is from submitting the Trouble tickets and an Equinix Managed Service specialist sending a formal response.
2. Resolution time of a case is from registering to resolve or cancelling the Trouble Ticket in the ITSM Tool or the hand over to IBX Support.
3. SLA applies to the response time, details on the SLA can be found in the Product Policy.

The Availability Level of the MPC service refers to the availability of a single OVDC. The MPC service is considered Unavailable when a failure in infrastructure managed by Equinix causes the OVDC to enter an error state and directly results in an interruption to the customer’s services.

Availability Service Level	Description
99.95%+	Achieved when total OVDC unavailability is less than 22 minutes over a calendar month.

A service credit regime applies to the availability SLA as defined in the Product Policy. Availability of the MPC service does not include data restoration. Customers are responsible for restoring their data. When Managed Private Backup is contracted, data can be restored through self-service using the Managed Private Backup Operational Console. If Managed Private Backup is not contracted, data restoration is the responsibility of the customer.