Equinix Metal deploys infrastructure across nearly 20 regions, such as New York, Amsterdam, Silicon Valley, and Frankfurt. At Equinix, we call each of those a "metro."
Within each metro, we may utilize just one physical data center, but increasingly we're deployed across a number of facilities. A great example is New York, where we have a legacy facility in Parsippany NJ (EWR), a deployment in Equinix NY5, and soon another expansion in Equinix NY7.
In order to help users consume more easily, we've been hard at work on a number of adjustments that launched today. Here are the highlights, and there are some detailed FAQ's below and in our documentation.
- New deploys through our portal will feature a metro name (e.g. Silicon Valley) instead of a data center name (e.g. SJC1 or SV15).
- Our system will choose which data center to deploy your server into based upon capacity and other factors. In metros with both legacy and new Equinix facilities, we will generally preference our shiny, new, Equinix facilities.
- Everything you would expect (BGP, backend transfer, Elastic IPs) will work across facilities within a metro. Magic!
- There are no bandwidth charges between facilities within a metro.
- Existing VLANs will need to be recreated to span across facilities in a metro, but new ones will work by default.
- We have a new "metros" endpoint in our API. Over time you'll want to use this instead of the "facilities" endpoint. However, there are no plans to deprecate this endpoint so you don't have to change anything you do today.
- We'll release a new version of our Terraform provider shortly, but you'll need to pay close attention to this upgrade if you have existing infrastructure. We'll include full details in the release notes, and are happy to chat with you about it.
In short, metros is a big change to our backend systems, but for users, it should work something like this:
Let's See the FAQ's!
What is a Metro?
A Metro is an Equinix-wide concept for data centers that are grouped together geographically. At Equinix Metal, data centers within a metro now share capacity and networking features.
What is new or different about Metros?
The biggest difference is that servers are provisioned at the Metro level and not the Facility level. When you provision a server you select the Metro where you want your server to live. Our API will then determine which specific facility within the Metro your server physically resides (based on capacity and other factors).
Metro-based provisioning is supported through all the deployment options: On-Demand, Spot Market, Reserved Hardware, and Batch Deployments.
What if I really need a server in a specific facility?
If your use case requires servers in a specific facility, you can use the "facilities" endpoint in our API. The API remains backward compatible and you can also continue to use any automation integrations.
You can also contact us with details about your deployment or application needs and we can assist you, probably with the help of a Hardware Reservation.
What other features do Metros have?
The facilities within each Metro are interconnected by high-speed links with an average latency of 5 milliseconds or less. There is no billing for traffic between facilities within a Metro. Additionally, many of our Networking features are designed to take advantage of this:
- VLANs - When you provision a VLAN in a Metro, all servers in that Metro are able to connect to it.
- Elastic Public IPv4 Addresses - When you request an Elastic Public IPv4 address, you will be able to assign it to any server in the Metro where you requested it.
- Private IPv4 Addresses - While the blocks of private IPv4 addresses are facility-based, all the servers within a project in the same Metro can use them to connect to each other.
- Backend Transfer and Local BGP will work across facilities in a Metro.
I already have existing servers and VLANs. Will these continue to work?
Existing VLANs will continue to work, but traffic will be limited to servers within a single facility. To enable traffic between servers across all facilities in a Metro, you will need to create new Metro-level VLANs and add any servers to the new VLANs.
What is the impact if I’m a Terraform user?
Our 2.0.0 Terraform provider will expose the new metro concept, which is also available via the /metros endpoint in our API. You can continue using Terraform to manage your existing devices in the facilities model and begin to manage new deployments with the newer Metro model. For a detailed changelog, please follow our discussion on GitHub.
Is the Metros concept the same as Availability Zones in AWS, Azure or GCP?
Equinix Metal does not provide a public cloud-style high availability construct, and our Metros feature is not intended to provide this. If you are looking for high availability or disaster recovery at the regional level, we recommend deploying across distinct metros. Diversity within a metro can often be achieved through Hardware Reservations. Please contact our team for options!