New Term-Based Discounts for Equinix Fabric Are Here
We're excited to introduce Equinix Fabric Term-Based Discounts for inter-metro i.e. remote virtual connections (VCs) between your own assets and to your service providers including hyperscalers such as AWS, Azure, Google Cloud and Oracle. This new pricing option is designed to help you save more while enjoying the high-performance connectivity you rely on. What's New? You now have the option to select 12, 24, or 36-month contracts for inter-metro VCs from your Fabric ports, Network Edge virtual devices and Fabric Cloud Router instances. Here's how you'll benefit: Lower Monthly Rates: Save between 15% and 50% compared to on-demand pricing. For example, a 1 Gbps inter-metro virtual connection between London to New York drops from $1005/month to just $503/month with a 36-month term-based plan. See how much you can save using the Fabric pricing calculator, accessible via the Fabric portal. Simple Provisioning: No approvals required. Just select your term in the self-service portal or Fabric API and enjoy the savings. Broad Capability Support: Applicable across Point-to-Point (EPL & EVPL), Multipoint-to-Multipoint (EP-LAN & EVP-LAN) and IP-WAN services supported by Fabric Cloud Router. Also supported for Z-side service tokens. Predictable Cost Structure: Term based contracts provided set monthly rates, making it easier for you to manage your annual budget. Things to Note Discounts are available only for inter-metro VCs (intra-metro i.e. local VCs are not eligible. Discounts are currently not supported on Network Edge virtual devices to AWS, but are coming soon. Term-based discounts cannot be added to existing VCs, so you’ll need to create a new VC with your chosen term. Why This Matters By locking in discounted rates, you can optimize costs and achieve predictable spending without sacrificing performance, reliability, or flexibility. This is the perfect opportunity to create cost-efficient connectivity solutions tailored to the demands of your business. We'd Love to Hear From You Tap into these savings today by selecting a term-based discount during your next VC provisioning. We’d love to hear how this pricing option benefits your operations. Share your feedback with the team!Why Unified Observability Is the Future of Infrastructure Management
Today’s organizations juggle a mix of physical equipment and digital services, spanning on-premises, cloud, SaaS, and remote locations. But as IT and OT environments grow more intertwined, so do the challenges of managing them. Siloed teams, fragmented data, and reactive monitoring are holding businesses back from true operational efficiency. What if you could gain a single, unified view of all your technology assets—no matter where they reside? Imagine proactively preventing outages, streamlining operations, and boosting cost efficiency with insights from across your IT and OT environments. In one of our latest blogs, we explore: • Why the convergence of IT and OT is reshaping infrastructure management • The business benefits of a unified observability approach across OT and IT • How leading organizations are breaking down silos for better decision making 👉 Read the full blog now!Layer-2 Networking with Interconnection and AWS
Those already using Ansible can now take advantage of templates to demonstrate configuring Layer 2 connectivity to AWS S3. You can also follow the prerequisites in the related GitHub repo to test this as a new user. Step 1: Use the initial template to rapidly create a project, VLAN, VRF, and prep for BGP peering on the virtual circuit. Step 2: Finish setting up the interconnection in Fabric console manually and accept the Direct Connect request in AWS. Step 3: Use the final playbook which takes care of deploying the VPC, the S3 VPC endpoint, the Virtual Private Gateway attached to your Direct Connect, and finally configures the end to end BGP peering. This playbook has been added to the examples section of the Ansible Collection Equinix page.
Fabric APIv4, Connection to azure, Technical background vlanSTag in zSide
Hello, I'd like to configure a redundant connection to Azure using dot1q encapsulation. The documentation for migration from v3 to v4 states that we need to include "linkProtocol": { "type": "QINQ", "vlanSTag": 2002 }, in the zSide definition. That was not necessary in the v3 API. I'm not sure what the technical background for that value is. Specifically: Can we always use the same VLAN ID in connections to different Azure environments when using unique VLAN IDs on the aSide? Any help is appreciated.New Fabric APIs expand usablity
Connect Using Service Token - Equinix APIs use OAuth 2.0 protocol to authenticate the requests you make to API endpoints. In order to interact with Equinix APIs, you need a bearer acess token. Bearer determines the type of authentication scheme and is a part of the OAuth 2.0 protocol. https://developer.equinix.com/docs
