Workload guidance
Which Equinix building block fits which workload, the reasons, and the trade-offs, with the SDK entry point for each.
Building blocks#
| Building block | What it is | SDK entry point |
|---|---|---|
| Fabric port | A physical hand-off from your cage to Fabric | fabric.ports() |
| Virtual connection | A layer 2 or layer 3 circuit between two access points | fabric.connections() |
| Fabric Cloud Router | A managed layer 3 router in a metro | fabric.cloudRouters() |
| Fabric network | A multipoint layer 2 or IP-WAN service across metros | fabric.networks() |
| Service token | Delegated access to a port for another party | fabric.serviceTokens() |
| Network Edge device | A vendor network function as a virtual appliance | networkEdge.devices() |
| Internet Access | Transit in an IBX | internet.services() |
| Internet Exchange | Public peering in a metro | fabric.beta().exchangeServices() (Beta), planning with peeringIntelligence() |
| Precision Time | NTP or PTP over Fabric | fabric.precisionTimes() |
| Cross connect | A physical cable between two parties in an IBX | portal.crossConnects() |
| Native multicloud link | A provider-to-provider link, outside Equinix | Planned and priced only, see Cloud-to-cloud |
Selection by connectivity need#
| Need | First choice | Reason | Consider instead when |
|---|---|---|---|
| One cage to one cloud | Port to cloud, EVPL_VC | Fewest components; routing stays on your routers | You expect a second cloud: start with a Cloud Router |
| One cage to several clouds | Cloud Router with IP_VC to each cloud | One BGP policy; cloud-to-cloud traffic does not cross the cage | You need stateful inspection between clouds: add Network Edge or use your own firewalls and layer 2 connections |
| Cloud to cloud, no premises | Cloud Router | Works for any pair and any number of clouds; sizes from tens of Mbps | A single pair at a sustained rate above the break-even: native link |
| Two or three metros | Router-to-router IP_VC, or port-to-port EVPL_VC | Explicit bandwidth per pair | The count grows: IP-WAN network |
| Many metros, any-to-any | IP-WAN network with a Cloud Router per metro | One attachment per metro instead of a mesh | You need per-pair policy or segmentation: mesh or several networks |
| A metro without a cage | Network Edge device | No space, power or shipping; ready in hours | Throughput or hardware features beyond a virtual appliance |
| Hand-off to a partner or customer | Service token on your port, or a private service profile | The other party orders the connection; you set the limits | A long-lived, high-volume relationship in one IBX: cross connect |
| Internet breakout | Internet Access | One order, BGP or static | You need several carriers: cross connects to each |
| Reaching many networks cheaply | Internet Exchange peering | One port, many peers | The traffic is to a few large networks: private interconnection to each |
Guidance by workload type#
Transactional systems and APIs#
These systems need low latency and high availability and carry moderate bandwidth.
- Place the on-ramp in the metro nearest to the cloud region that the system runs in. The Metro Optimizer weighs that distance against the distance to the user sites.
- Use a redundant pair of connections to two provider locations, with BFD on both BGP sessions.
- Set a latency ceiling for the workload with
maxLatencyToleranceMs, which makes the optimizer reject designs that exceed it. - A second metro raises the resilience score and adds a router fee and a backbone link. The resilience objective gives the first figure and the TCO comparison the second.
Data replication and backup#
Replication and backup move large volumes, tolerate high latency, and are sensitive to egress cost.
- Size the connection from the change rate of the data and the replication window. The size of the whole dataset matters only for the first copy.
- Replication out of a cloud is billed as egress, so run the savings calculator before choosing a path.
- A backup target can use a single connection, because a backup can be repeated after an outage. A synchronous replica needs a redundant pair.
- A smaller connection has a lower fixed cost and falls behind when the change rate rises, which lengthens the recovery point. Estate analysis reports connections whose 95th percentile is near their bandwidth.
AI and ML training#
Training moves data in bursts and leaves the connection idle between runs.
- Compute the transfer time for the dataset at each bandwidth before choosing, as in AI and ML workloads.
- Prefer a dedicated cloud port with a resizable Fabric connection over a fixed hosted connection when runs are infrequent.
- Pin the training workload to the metro where the GPUs are, because the optimizer has no power or cooling data.
- A copy of the data next to the GPUs avoids egress charges on every run and adds storage to operate.
AI and ML inference#
Inference traffic is steady and has a latency budget per request.
- Place the serving metros by user population with
LATENCY_FIRST, in at least two metros. - The time the model takes adds to the network latency, so the latency ceiling for the network should leave room for it.
- Each additional serving metro lowers latency for the users near it and adds GPU capacity that is idle outside peak hours.
Real-time collaboration and voice#
These workloads are more sensitive to jitter and packet loss than to bandwidth.
- Use private paths to the SaaS provider where it publishes a service profile on Fabric, and regional internet breakout otherwise.
- Use several small deployments in metros near the users.
EDGE_COMPUTEandREALTIME_COLLABORATIONset critical latency sensitivity in the optimizer. - Private connectivity to a SaaS provider carries only the traffic that the provider accepts on it, and media streams often still use the internet.
Trading and market data#
Trading systems need predictable latency and accurate time.
- Place the systems in the same IBX as the venue and connect with cross connects, because a virtual connection adds a shared device to the path.
- Use Precision Time with PTP for timestamping.
- Measure the latency of the path. The SDK's latency figures are round trips between metros and fibre floors, which serve for planning and are far coarser than the microsecond figures a trading path is judged by.
Disaster recovery#
A recovery path is used rarely and has to work when it is used.
- Use two metros with on-ramps in both, and configure BGP so that failover needs no manual change, as described under Disaster recovery.
- Size the backbone for the traffic it carries during a failure, and test the failover every quarter.
- The standby path is billed every month. A smaller standby that is enlarged during a failover costs less and adds a manual step to the failover.
Colocation-heavy estates#
An estate with many cages involves physical work and depends on facility conditions.
- Automate the reads first (order history, power events and port state), as in Colocation operations.
- Require an approval before every order, because the portal APIs define no dry run.
- Feed IBX SmartView data into the monitoring that already holds network data.
Layer 2 or layer 3#
Layer 2: EVPL_VC, EPL_VC, EVP-LAN | Layer 3: Cloud Router, IP_VC, IP-WAN | |
|---|---|---|
| Routing runs on | Your devices | The Cloud Router, with your BGP policy |
| Cloud-to-cloud | Through your devices | On the router |
| Control | Full: any protocol, your own firewalls inline | BGP attributes, route filters, aggregation |
| Operational load | VLANs and sessions on your hardware per connection | Managed router; one session per neighbour |
| Fixed cost | No router fee | Router fee per metro |
| Fits | Existing routers in a cage; strict control over the path | No cage, several clouds, or a small team |
Choosing a bandwidth#
- Start from a measurement of the traffic.
fabric.metrics()returns the history of an existing connection. - Size to the 95th percentile with headroom. Estate analysis uses a factor of 1.3 by default.
- Check the tiers that the service profile offers, because a request is rounded up to the next tier.
- Check whether the provider object can be resized in place.
- Validate with
dryRun().
Redundancy levels#
| Level | Survives | Typical cost over a single connection |
|---|---|---|
| Single connection | Nothing | Baseline |
| Redundant connection pair, one port | A connection or provider device failure | One more connection |
| Two ports on different Fabric devices | A port or Fabric device failure | One more port and cross connect |
| Two Cloud Routers in a metro | A router failure | One more router fee |
| Two metros | A metro or cloud region failure | About twice the design, plus a backbone |
Each workload can have its own level. One estate can hold a backup target at the first level and a payment system at the fourth.
Design layer or direct calls#
| Situation | Approach |
|---|---|
| The metro and the topology are known and small | Direct API calls with dryRun() |
| The metros are open, or stakeholders need to see the trade-offs | DesignSpec and the Metro Optimizer |
| Several metros with routers, on-ramps and a backbone | Deployment Wizard, executed or exported to Terraform |
| An estate exists and its sizing is in doubt | Estate analysis |
| A cost question from finance | Savings and TCO, with your contract rates in a custom rate card |
| An exploratory design session | The MCP server with the design toolset |