Design Your Solution

To enable the best experience for our customers, we must ensure the process to connect to your services is clearly defined, simple, and automated wherever possible.

It’s important to understand how customers will request to connect to your service over Equinix Fabric, and ultimately how they will order and provision your services.

Customers typically enable Fabric connectivity to service providers in the following use cases:

  • Customer-Ordered Access – Access XaaS over Equinix Fabric where connections are made from the customer’s port or other virtual asset to your public service profile over Fabric.

  • Provider-Ordered Access – Access Digital Infrastructure services from your offered service.
    By enabling connectivity from your service to other services over Equinix Fabric, customers can access digital infrastructure services on demand globally. Whether it be routers, firewalls, storage or other services, turn them up or down as needed and expand based on supported software-defined network service offers.

  Customer-Ordered Provider-Ordered
Use Case XaaS Ecosystem Access
Incoming/Outgoing VCs Incoming Outgoing
Billed Entity Customer Provider
Service Tokens Z-side A-Side
Managed-Service Capable No Yes
Public Service Profile Yes No

Customer-Ordered Access

Customer-ordered access, or XaaS, is initiated in the Equinix Fabric portal when the customer requests to connect to your services. Once the services are made publicly available by creating a public service profile, you can accept or enable the Equinix Fabric connection with an API or directly in the Equinix Fabric portal.

The customer journey can take one of two paths to enable customer-ordered access to your services on Equinix Fabric:

  • Portal-First – In this scenario, customers request to connect to a service provider through the Equinix Fabric Portal. Once your public service profile is enabled, customers can “discover” your services and request to connect in several ways. You will then receive notification of the connection request both in the Equinix Fabric portal as well as via email. Upon notification, provider would perform any necessary tasks to enable the service, then accept the connection request by assigning a port and VLAN. The limitation with this flow is that the customer must wait for the provider to accept the request unless the provider has API-integrated with Equinix Fabric.

  • Token-First – In this scenario, the customer first gets a Z-side token from their provider, then redeems that Z-side token in the Equinix Fabric portal.

Z-side Service Tokens

If your customer wants to connect to your service over Equinix Fabric, you can issue a Z-side service token to authorize the connection. Connections made to your services in the Equinix Fabric portal using a Z-side service token will be auto-provisioned and will not require the customer to wait for acceptance of the connection request. For more information about Z-side service tokens, see Service Tokens.

Note: A connection made with a Z-side service token will be billed to the customer who is the initiator of the connection, not to the service provider.

Keep the following things in mind regarding customer-provided access (either portal-first or provider-first):

  • Customers do not need to physically reside in the local Equinix metro/IBX, they can connect to your service from any of the 50+ Equinix Fabric locations provided you allow Remote Access.

  • Each connection request will have a unique ID that is displayed on the connection success page and can be copied and shared with the service provider. This unique connection ID may be used to accept the connection when ordering portal-first.

  • When a connection request from a customer is accepted, or when the Z-side token is generated, the port and VLAN to associated with that connection will be selected by the service provider.

  • Connection will not be billed or provisioned until provider has accepted the request. Connections created using Z-side service tokens will be automatically provisioned and commence billing.

  • Providers can include a link or information in the Equinix Fabric portal to direct customers to the provider portal to complete the service.

  • Providers can specify the workflow to connect to their services within the Equinix Fabric portal when creating a service profile in the Service Customization steps of the service profile creation process.

Provider-Ordered Access

Service providers can order connections from their provider ports to another service provider, customer/partner cage, device, or other virtual asset, giving your customer access to a vast ecosystem of over 200 types of service providers. This allows customers who subscribe to your services to connect to any other Equinix Fabric participant whether that be the customers’ own digital or physical infrastructure, another cloud provider on Equinix Fabric, or any other service offered over Equinix Fabric.

Provider-ordered access gives control of the connection to the provider including costs. In this scenario, unlimited ports may be more economical as all location connections created from unlimited ports are $0. Remote or inter-metro connections will require that the provider understand the price for the connection, best achieved using APIs for real-time accuracy.

There are two types of provider-ordered Access:

  1. Managed Service Model – where the provider creates the connection on behalf of the customer and customers do not need to login to the Equinix Fabric portal to create a connection. Connections can be made to any other service provider available on Equinix Fabric (ex. AWS), and/or to any another Equinix customer (who may also be your customer).

    • When connecting to a customer cage, that customer will need an Equinix Fabric port that is connected to their cage, or another virtual asset to which the provider can connect. The customer can issue a Z-side token to the provider to authorize the connection to their own port/cage.

    • When connecting to another service provider or public service profile, select that service profile and enter any required information to complete the connection.

  1. Self-Service Model – The service provider can issue an a-side token and allow their customers to create connections to their own cage and/or any other service provider on Equinix Fabric using the service provider’s ports and service.

    Note: In the self-service model, customers can connect to any available service provider on Equinix Fabric, or they connect to their own cage. This introduces options to enable your customer to connect digitally to partners, clouds, other providers, Equinix Metal, or any other available destination on Equinix Fabric.

A-side Service Tokens

A-side tokens allow a customer or partner to connect to a third-party service provider available on Equinix Fabric where the origin or A-side of the connection is owned and managed by you, the reseller/service provider. The customer or partner does not need to be an existing Equinix Fabric user. If your customer already has a service with you and would like to connect through this service to another Equinix Fabric service provider, you can issue your customers an A-side service token to authorize the Fabric connection originating on your port. For more information about A-side service tokens, see Service Tokens.

A connection made with an A-side service token will be billed to the owner of the A-side port (service provider/reseller).

Depending on which provider will be the Z-side or destination of the connection, certain workflows and restrictions may apply. Connection requests to a third-party service provider may or may not be auto-accepted and provisioned immediately.

In either provider-ordered scenario (managed or self-service), providers need the ability to bill the customer for Equinix Fabric VCs. If remote connections are allowed, prices vary and may change from time to time. We suggest you use the Fabric v4 Pricing APIs to get a consistently accurate price to offer your customers. Local VC charges are more consistent and may be completely avoided using unlimited ports.

API Integration Options

A full set of APIs to automate any of the Equinix Fabric functions and features are available at the Equinix Developer Platform.

API integration allows you to:

  • Eliminate manual processes and steps

  • Save resources and time when provisioning services

  • Decrease errors

  • Provide a better customer experience

  • Embed the provisioning of Fabric VCs or virtual devices into your Terraform automation scripts

Providers typically integrate with Fabric APIs at different levels of completeness. Some have almost fully automated the process of connecting to their services over Fabric, some have automated only certain steps and others have chosen to solely use the Fabric portal to order interconnection services.

One integration option would be to receive connection requests through the Equinix Messaging Gateway (EMG), where you can also receive other notifications. API integration would allow you to perform automation flows based on receiving a connection request.

Automation opens several additional use cases for providing software-defined services. Becoming a service provider on Equinix Fabric enables programmatic connectivity to your services from any Equinix data center which can be combined with other virtual services to develop simple to complex solutions and offers for your customers.

Technical Architecture Options

Even though Equinix Fabric is designed to be a highly available service, redundancy and diversity are often a concern for Fabric customers, particularly when customers are connecting to their networks or other mission-critical services. Equinix supports several configurations when achieving port redundancy. For more information, see Port Architectures. For detailed information about port architecture options for Service Providers, see Port Architectures for Service Providers.