The short answer
Choose based on traffic shape and risk, not on the label. A site-to-site VPN builds an encrypted tunnel over the public internet. A private interconnect is a dedicated or hosted circuit into a cloud provider edge.
If traffic is light, bursty, or the sites change often, a site-to-site VPN usually fits. If you move large volumes every day, run latency sensitive systems, or need a private path for policy reasons, a private interconnect is worth the effort. Many teams run both: interconnect as the primary path and VPN as backup.
An interconnect is not automatically encrypted. A VPN is not automatically slow or unsafe. Ask four questions. How much data crosses each day? How sensitive is the workload to latency and jitter? What encryption is required? How long can you wait for setup and redundancy?
The answer can differ by site and by workload. A factory with a small link to one cloud app does not need the same design as a data platform moving backups and replicas across regions.
| Aspect | Private interconnect | Site-to-site VPN |
|---|---|---|
| Path | Dedicated or hosted circuit to the cloud provider edge, off the public internet | Encrypted tunnel over public internet paths |
| Encryption | Not on by default, add MACsec or IPsec if required | IPsec encryption is part of the tunnel |
| Setup time | Weeks to months for cross-connect and carrier work | Hours to days when public IPs and firewall access exist |
| Bandwidth | Committed port speed with a clear capacity plan | Limited by internet circuits and encryption capacity |
| Latency and jitter | More predictable, based on provider paths | Follows internet conditions and can vary |
| Redundancy | Needs two ports, two devices, and diverse paths | Needs two tunnels, two gateways, and ideally two internet providers |
| Operations | BGP, VLANs, carrier coordination, route limits | Tunnel settings, MTU and MSS, rekey, dead peer detection |
| Best fit | Heavy, steady, latency sensitive, or policy driven traffic | Small sites, temporary links, dev and test, backup paths |
How a private interconnect works
You order a port from the cloud provider or from a partner that offers a hosted connection. At your site or colocation cage, you arrange a cross-connect to the carrier or provider. The provider issues a letter of authorization, assigns a VLAN, and you configure a subinterface on your router. The cloud side has a virtual gateway or edge device. You peer with BGP using your own autonomous system number and advertise the prefixes you want reachable.
Traffic then travels from your edge to the cloud edge over the provider network. It does not cross the public internet. That does not make it a private line all the way to every server. The provider network is shared, and the cloud network is shared. Encryption is a separate choice. Some links support MACsec at layer 2. You can also run IPsec over the interconnect when a policy requires it.
Redundancy needs design, not just a second cable. Order two ports, terminate them on two routers, use two carriers or two paths into the colocation, and test failover. Watch prefix limits, BGP timers, maximum transmission unit, and route preference. Provisioning can take weeks to months because of cross-connects and carrier circuits. Run a site-to-site VPN in the meantime and keep it as a tested fallback.
How a site-to-site VPN works
You configure a customer gateway at your site and a VPN gateway in the cloud. Both sides agree on IKEv2 settings, a pre-shared key or certificate, encryption and integrity algorithms, and perfect forward secrecy. Routes are static or learned through BGP. Cloud VPN gateways usually provide two tunnels so you can terminate them on separate customer devices.
Traffic is encrypted, then sent over the public internet. Throughput depends on the internet circuits and on the encryption capacity of your firewall or router. Latency and jitter follow the internet path. Set maximum segment size clamping and a correct maximum transmission unit, or large packets will stall. Enable dead peer detection and check how the tunnel rekeys.
Common problems are overlapping address space, NAT on one side, a single firewall, and a single internet provider. Fix the first two before deployment. For availability, use two customer gateways, two internet providers, and two tunnels. A site-to-site VPN can be ready in hours when public IPs and firewall access are in place, which makes it useful for new sites, temporary projects, and backup paths.
When to choose a private interconnect
Pick a private interconnect when you have sustained, predictable traffic. Examples include nightly and continuous backup, storage replication, data lake ingest, and database traffic between a data center and a cloud region. The same applies when an application is sensitive to latency and jitter and users notice small changes in response time.
Choose it when policy or architecture requires a path that avoids the public internet. That may be a customer contract, an internal security standard, or a regulated workload. It also helps when you run many virtual networks or virtual private clouds and want a central egress or shared services model. Dedicated bandwidth gives you a clearer capacity plan than internet links.
Be honest about the conditions. You need budget for redundant ports and circuits, staff who can run BGP, and time for carrier coordination. One interconnect circuit is a single point of failure, even if the cloud side is redundant. An interconnect to one cloud provider does not connect you to another. Each provider sells its own product, with its own gateway and routing model.
When to choose a site-to-site VPN
A site-to-site VPN fits small offices, branch sites, development and test environments, and temporary projects. It also fits a new cloud region where you need connectivity before a circuit can be installed. If the traffic is modest and the application tolerates internet latency, encryption over the internet is a practical design.
Use it as a backup path for a private interconnect. Keep the tunnels configured, monitor them, and test failover on a schedule. A backup that has never carried production traffic is only a hope. Size the VPN for the critical flows you need during an outage, not for the full peak of the primary circuit.
A site-to-site VPN also works well when you need encryption on a path that crosses untrusted networks and you do not control the underlay. Use strong IKEv2 settings, certificates where you can manage them, and separate tunnels on separate devices. If encryption throughput becomes the limit, scale the firewall or move bulk flows to an interconnect.
Costs and effort to consider
The cost models differ. A private interconnect has port charges, cross-connect fees, carrier circuits, router capacity, redundant hardware, and staff time. A site-to-site VPN has firewall or cloud gateway capacity, internet circuits, and staff time. Both can carry data transfer charges from the cloud provider, so read the egress terms for the services you use. The cheapest design is often the one your team can operate well.
The effort differs too. Interconnect work involves vendors, cross-connect schedules, VLANs, BGP troubleshooting, and maintenance windows. VPN work is simpler to start but needs tunnel tuning, monitoring, and failover testing. In both cases, alert on link state, BGP session state, latency, packet loss, and throughput. Track route changes and keep a diagram that matches reality.
A common pattern is a private interconnect as the primary path and a site-to-site VPN as the backup. Document which routes prefer which path, how failover works, and who tests it. Run the test on a schedule. If you want a second opinion before committing, Cloudverg's Expert architecture session is a one-time $450 for 90 minutes, one option among others.
Frequently asked questions
Is a private interconnect encrypted by default?
No. It avoids the public internet, but encryption is a separate layer. Use MACsec where the provider and your equipment support it, or run IPsec over the circuit. Check the requirement for the specific workload.
Can I use a site-to-site VPN as backup for a private interconnect?
Yes. This is a common design. Set route preference so the interconnect is primary and the VPN takes over on failure. Keep the tunnels monitored and test failover on a schedule.
How long does a private interconnect take to set up?
It depends on the provider, colocation, and carrier. Cross-connects and local circuits can take weeks to months. A site-to-site VPN can run in the meantime, and many teams keep it as a permanent fallback.