When business systems move out of the office into a data center, a colocation facility or a cloud platform, every user who depends on them now depends on the path in between. That path often crosses more than one provider: your office network, an access provider, a transport or internet provider, the facility, and the cloud or hosting platform itself. Each handoff is a place where performance, security and responsibility can be left undefined.
There are three common ways to build that path. None is best in general. The right choice depends on what runs over it.
The three path types
1. Internet path. Your office reaches the environment over its internet connection. For SaaS and public-cloud applications this is the normal way in, and their traffic is commonly protected at the application layer with TLS (HTTPS). For private network traffic between your office and your own systems in a data center or cloud, the path across the internet should use appropriate cryptographic protection, commonly an IPsec tunnel with IKEv2. It is the quickest to deploy and uses capacity you already have, but performance depends on the public internet beyond your provider’s network.
2. Direct connection to a data center. A dedicated circuit runs from your office to the facility where your systems are hosted, without crossing the public internet. Typically this is a point-to-point Layer 2 link (an Ethernet circuit) handed off inside the facility to your equipment or to the hosting provider. It is usually more predictable within the defined circuit scope, but it is only possible where a provider, or an approved transport or delivery partner, can deliver the circuit to that facility and establish the required handoff there.
3. Site-to-site interconnection. Offices, branches and the data center are joined into one private network. This can be built with Layer 2 circuits, with a provider-operated Layer 3 VPN (the MPLS-based design described in RFC 4364), or with encrypted tunnels over internet connections. It suits organisations whose sites work as one network with shared systems.
Comparing the options
| Question | Internet path | Direct connection to a data center | Site-to-site interconnection |
|---|---|---|---|
| Best suited to | SaaS and cloud services; smaller hosted workloads | Systems hosted in one facility that many users depend on | Several offices sharing systems as one network |
| Crosses the public internet | Yes | No | Depends on the design |
| Performance predictability | Depends on networks beyond your provider | More predictable within the defined circuit scope | Depends on the transport: private circuits or internet tunnels |
| Encryption | SaaS: application-layer TLS (HTTPS). Private office-to-environment traffic: IPsec/IKEv2 or equivalent | Engineered per topology (for example MACsec on suitable Layer 2 links) | IPsec for routed and internet-based designs; MACsec for suitable Layer 2 designs |
| Availability | Wherever the site has internet | Where a provider or its delivery partner can deliver the circuit and the facility handoff | Depends on every site’s access |
| Addressing and routing | Public addressing; BGP if you announce your own IP space | Private addressing, or BGP across the link | Private routing between sites; BGP or static routing |
| Who operates it | Your provider up to its handoff; the internet beyond | The circuit provider up to the facility handoff | One or more providers, each up to a defined handoff |
Start from the workload, not the circuit
Ask four questions about what will run over the path:
- How sensitive is it to delay and loss? Voice, video, virtual desktops, database replication and ERP sessions suffer from variable latency. Email and file sync usually do not.
- How much traffic, in which direction? Backups and replication to a data center are upload-heavy from the office. Size the path for the upload, not only the download.
- What happens to the business if the path fails? If failure of the path stops the business, the risk may justify a second path designed to avoid the same failure points.
- Where does the environment actually sit? A cloud region outside the country, a data center in Dhaka, or a facility in Chattogram are different engineering problems. A direct connection depends on whether a provider, or an approved transport partner, can deliver a circuit to that facility.
As a rule of thumb: SaaS and public cloud services are reached over a well-engineered internet path; a data center that hosts your core systems often justifies a direct connection; and organisations with several offices sharing those systems usually need site-to-site interconnection, with the data center as one of the sites.
Responsibility at every handoff
Operational delays often appear at the boundaries between networks, especially when responsibility at the handoff is unclear. Write down, for each segment, who operates it and where their responsibility ends:
- Your office network: your team, unless a managed service is contracted.
- Access and transport to the facility or internet: the connectivity provider, up to its defined handoff.
- The facility: the data-center operator, including cross-connects, power and cooling inside the building.
- The hosting or cloud platform: the platform provider.
Then check that the handoffs line up: the physical interface and handoff point at each end, who orders and pays for cross-connects inside the facility, who monitors which segment, and who you call first when users report a problem. A path with four operators and no defined handoffs has four places to disclaim responsibility.
Addressing and routing decisions
Two early decisions shape everything else:
- Address space. If offices and the environment use overlapping private address ranges, connecting them later requires translation and becomes fragile. Plan address ranges across all sites before you connect them.
- Routing. Small designs often use static routes. Organisations that need control over how traffic enters and leaves their network, or that announce their own public IP space, use BGP (RFC 4271) with their own Autonomous System Number. If you expect to need this, ask early whether the provider supports customer BGP, your own ASN and IPv6 prefix announcement.
Encryption is a design decision per segment
Whether, and how, traffic is encrypted depends on the traffic and the topology. SaaS and public-cloud applications usually encrypt their own traffic at the application layer with TLS (RFC 8446). Private site-to-site or office-to-environment network traffic that crosses the public internet should use appropriate cryptographic protection, commonly IPsec with IKEv2 (RFC 4301, RFC 7296). Suitable Layer 2 links can be protected with MACsec (IEEE 802.1AE), which encrypts at the Ethernet layer. Be cautious of any offer that describes a path as “secure” or “encrypted” without saying which mechanism protects which segment.
Questions to ask before choosing
- Which of the three path types do you recommend for this workload, and why?
- Can you deliver a circuit to the facility where our systems are hosted, and who builds each part of it?
- Where exactly is each handoff, and who is responsible on each side of it?
- Who orders and manages cross-connects inside the facility?
- How is each segment protected: which encryption, on which part of the path?
- What is the second path if this one fails, and what does it share with the first?
- Can we use our own IP space and ASN, and is IPv6 available?
- Who monitors the path, and who contacts whom when it fails?
For the access connection at each office, what a dedicated connection actually commits explains the properties to check, and how to read an internet SLA covers the service levels.