Private Connectivity
A private path from your offices to the cloud, never over the internet
Your company's dedicated carrier circuit is received on Nesnet's data centre network in a segment of its own and connected straight to your cloud network. Branches reach cloud applications with their existing IP plans, without crossing any public network.
Why now
- Your branches have reached head office over an MPLS network for years, and new applications are moving to the cloud. Management doesn't want branches reaching them over the internet.
- The nightly backup from your data centre to the cloud doesn't finish by morning and is still filling the office internet line at 8:30. Staff start the day on a crawling connection.
- One of your customers' contracts says the application handling its data must never be reached over the internet. Moving that application to the cloud runs straight into that clause.
- You want to replicate your data centre's database continuously to a copy in the cloud. Latency swings on the internet leave replication lagging behind several times a day.
- Your cloud migration plan says 'renumber the branch IP addresses', and that step alone will take months. You want the existing network to reach into the cloud as it is.
What changes
| Today | With Nesnet |
|---|---|
| Traffic from branches to the cloud crosses the internet. | Your dedicated circuit connects straight to your cloud network, and traffic never touches a public network. |
| Large transfers fill the office internet line and slow everyday work. | Backup and replication traffic takes its own path, leaving the internet line for your staff. |
| Moving to the cloud means rewriting the branches' IP plan. | Branch and head-office networks are introduced to the cloud with static routes or BGP, and existing addresses stay as they are. |
| When the link fails, carrier and cloud provider point at each other. | The Nesnet team that runs the cloud network terminates and connects the circuit, so the whole inside of the path to the cloud sits with one team. |
| Traffic on the private path goes unchecked. | Every connection arriving over the circuit passes your gateway firewall rules, and you decide which branch reaches which server. |
From today to live: how it works
- 1
Discovery call
Work out with Nesnet's team which locations connect, which cloud networks they need and the IP plan of your remote networks. You leave knowing the circuit layout and what drives the price.
- 2
Circuit order
Order the circuit from your carrier for delivery to Nesnet's data centre. Nesnet prepares the delivery details for you to pass on to the carrier.
- 3
Build on the Nesnet side
Your dedicated VLAN is opened on the data centre network, brought into the cloud portal as an external network and attached to your gateway as an uplink.
- 4
Routes and rules
Your remote networks are introduced on the gateway with static routes or BGP, and the firewall rule is written. Once the cloud networks are announced on your own device, the link is tested.
- 5
Go-live
One branch or a single application goes first, then the rest of the traffic moves onto the private path. The old path stays open for a while as a way back.
What you get
Traffic never touches the internet
Traffic between your remote network and your cloud networks passes through your gateway without ever reaching the internet. There's no public network between a branch request and your server; the path is a matter of design, not of chance.
A dedicated circuit and segment
Your carrier circuit is received on Nesnet's data centre network in a VLAN dedicated to you. It never shares a segment with other customers' traffic, and plugs straight into your gateway through an external network of its own.
An external network of your own in the portal
Your circuit shows in the cloud portal as an external network only you can see, attached to your gateway as an extra uplink. You can see which circuit is attached to which gateway and follow its routes and rules in the same place.
A cloud site on your MPLS network
If your branches are linked by a carrier's MPLS network, the cloud joins it as a new site. To a user at a branch, the cloud behaves like the server room at the other end of the network, and nobody's habits change.
Your IP plan as it is
Branch and head-office networks are defined as routes on the cloud side and introduced to the cloud with their existing addresses. The 'renumber the branches' step drops out of your migration plan, along with months of readdressing work.
Simple routing with static routes
By default, your remote networks are defined as static routes on the gateway. If your network doesn't change often, a few lines of routes get every branch to the cloud without running a routing protocol.
Dynamic routing with BGP
When routes should be learned by protocol rather than entered by hand, BGP runs on a provider gateway dedicated to you. BGP neighbours, IP prefix lists and route advertisements for your networks are defined there, and a new branch network is learned by the cloud on its own.
More than one circuit
A customer can connect several private circuits, for example two separate MPLS uplinks into the same gateway. Each one appears and is managed as its own external network on your gateway.
A backup path with two circuits
For critical links, two circuits are ordered from different carriers and both connect to the same gateway. If one carrier's circuit fails, traffic keeps reaching the cloud over the other.
A firewall on circuit traffic too
Every connection over the circuit is inspected by the gateway firewall, just like those from the internet. A private path doesn't mean a compromised computer on your internal network can roam freely across every cloud server.
Each branch reaches only what it needs
Your remote networks appear in rules as separate sources. The depot gets only the stock application, the finance office only the ERP server, and branches can't see each other's cloud resources.
Internet and VPN on the same gateway
Private Connectivity doesn't replace your internet uplink; internet egress and IPsec VPN run on the same gateway. Sites with a circuit use it, while a small office without one connects to the same cloud network through an IPsec tunnel.
A tunnel as backup for circuit outages
An IPsec tunnel defined on the same gateway serves as a second path for critical branches during a prolonged carrier outage. Work carries on, encrypted over the internet, until the circuit is repaired.
Side by side with SD-WAN branches
Branches connected through SD-WAN reach the cloud through the same gateway model. Large sites use the private circuit, small branches use SD-WAN over internet lines, and all of them meet on the same cloud network.
Large transfers don't compete with the internet
Nightly backups, archive transfers and database replication travel over your dedicated circuit rather than the office internet line. When staff arrive in the morning, the internet line isn't still busy with last night's backup.
A fixed path for replication
When you replicate a database or file server from your own data centre to a copy in the cloud, traffic isn't caught in the internet's latency swings. Only the replication ports are allowed on the gateway firewall.
Nesnet's team does the build
Nesnet's team handles every step on the Nesnet side: your dedicated VLAN, network segment, external network, gateway attachment, routes and the first firewall rule. What's left for you is introducing the cloud networks on the device at your end of the circuit.
A redundant gateway
The gateway the circuit attaches to runs active-standby, so a failure on the active side doesn't cut the circuit. The standby takes over, and traffic from your branches keeps passing with the same routes and rules.
Why Nesnet
The team running the cloud terminates the circuit
The circuit is terminated on Nesnet's data centre network by the Nesnet team and connected straight to your cloud gateway. There's no second intermediary, so responsibility never bounces between two companies when something goes wrong.
A segment and external network of your own
The circuit is received on Nesnet's network in a VLAN dedicated to you and shows in the cloud portal as an external network only you can see. It sits in its own segment and external network, apart from every other customer's.
A private path is not an unchecked path
Traffic arriving over the circuit still passes the firewall rules on your gateway. Your remote networks are defined as sources in those rules, so you still decide which cloud server a branch can reach, and on which port.
A model in live use that works with other links
This delivery model already runs live for several Nesnet customers. SD-WAN and IPsec links attach through the same gateway model, so connection types don't exclude each other; they run side by side.
The cloud end of the path is in Türkiye
The circuit terminates on Nesnet's network in the Equinix Istanbul (Dudullu) and Türk Telekom Ankara data centres. Traffic from your branches to the cloud, and your data in the cloud, stay in Türkiye.
Example scenarios
An organisation adding a cloud site to its MPLS network
Situation
An organisation's branches have been linked to head office over MPLS for years. New applications are moving to the cloud, but branches shouldn't reach them over the internet.
Outcome
A new cloud site is added to the MPLS network, and the circuit is received on Nesnet's network in a segment dedicated to the organisation. Branch networks are defined as routes on the gateway, and branches reach cloud applications with their existing IP plan.
A replication path between data centre and cloud
Situation
A company wants to replicate the database in its own data centre continuously to a copy in the cloud. Sending that traffic over the internet breaks company policy, and in internet tests replication kept falling behind.
Outcome
A private circuit links the two ends, and replication traffic reaches the company's cloud gateway without touching the internet. Only the replication ports are allowed on the firewall.
A nightly backup that finishes by morning
Situation
A manufacturer's nightly backups go to the cloud over the office internet line and are still running at 8:30 in the morning. Staff start the day on a slow connection.
Outcome
Backup traffic moves to the dedicated circuit, and the internet line is left for staff. With no internet traffic to compete with, the backup finishes overnight.
An application whose contract bans internet access
Situation
One of an organisation's customers requires by contract that the application handling its data is never reached over the internet.
Outcome
The application servers run in the cloud, and users reach them only over the private circuit. Internet egress on the same gateway is used only for permitted work, and firewall rules decide which traffic takes which path.
Head office on a circuit, small branches on SD-WAN
Situation
A retailer's head office and warehouse carry heavy traffic, while its shops each run on a single internet line.
Outcome
Head office and the warehouse connect to the cloud over private circuits, and the shops over SD-WAN. They all meet on the same cloud network and are managed with the same firewall rules.
Who does what
| Nesnet | You |
|---|---|
| Opens your dedicated VLAN on the data centre network and defines the network segment. | Order the circuit from your carrier and share the list of branch and head-office networks that should appear in the cloud. |
| Brings the segment into the cloud portal as an external network and attaches it to your gateway as an uplink. | Introduce your cloud networks on the device at your end of the circuit. |
| Defines static routes or BGP settings for your remote networks, plus the first firewall rule. | Manage your firewall rules in the portal once the link is live. |
| Runs the gateway in an active-standby setup. |
Who it is for
Multi-branch organisations on MPLS
Organisations whose branches have reached head office over a carrier's private circuit (MPLS) network for years. The cloud joins that network as a new site, and cloud applications look to branches just like servers at head office.
Companies with their own data centre
Companies that want a fixed path between their own data centre and the Nesnet cloud that never touches the internet. Database replication and backup traffic travel that path without competing with internet traffic.
Organisations that can't send app traffic over the internet
Organisations whose internal policy or customer contracts forbid carrying application traffic over the internet. Applications run in the cloud, and users reach them only over the private circuit.
Teams moving large volumes of data
Teams that send large backup files or archives to the cloud every night. Transfers don't fill the office internet line, and everyday work doesn't slow down.
IT teams planning a cloud move
Teams moving servers to the cloud without wanting to change how branches connect or how they're addressed. The existing network stays as it is, and the path to the cloud becomes part of it.
May not be the right fit
If an internet connection is good enough to link a few offices to the cloud, Site-to-Site VPN, which needs no carrier circuit, is the right choice.
Private Connectivity isn't for individual staff connecting from outside; it joins locations, not people.
Under the hood
With Private Connection, the carrier circuit is handed off on a VLAN reserved for you in Nesnet's data centre network. That VLAN is defined in the software-defined network layer as a segment of its own and imported into the cloud portal as an external network. The external network is attached to your dedicated edge gateway as an additional uplink, using a small transit subnet for the handoff. Your remote networks are defined on the edge as static routes, so they reach the cloud without changes to your existing IP plan. Where dynamic routing is needed, BGP neighbours and route advertisement can be set up on a provider gateway dedicated to you. The edge gateway runs active/standby, and internet egress and IPsec VPN can run on the same edge alongside the circuit. Nesnet's team builds and runs this whole chain, and the same per-customer edge model is used for SD-WAN connections.
Building blocks
- Dedicated customer gateway
- the VLAN segment reserved for you and the edge gateway
- Cloud portal and API
- your dedicated external network, edge and BGP management
- Edge firewall
- rules applied to traffic arriving over the circuit
- Static routing or BGP
- announces your remote networks to the cloud
How it compares
| Option | When it is the right choice |
|---|---|
| Site-to-Site VPN | If carrying office-to-cloud traffic over the internet inside IPsec is acceptable, this is enough. The tunnel ends on the same edge and no carrier circuit is needed. |
| SD-WAN | If you have many branches and want to manage them centrally over their existing internet lines, SD-WAN is the better fit. The SD-WAN connection reaches the cloud through the same per-customer edge model. |
Technical specifications
| How it appears in the cloud | Dedicated external network |
|---|---|
| Source of the external network | Network-layer segment brought into the portal |
| Handoff | One VLAN per customer + edge gateway + external network + static routes |
| VLAN | A VLAN reserved for you, on its own network segment |
| Edge attachment | Additional uplink; small transit subnet |
| Termination | In Nesnet's data centre network, by Nesnet's team |
| Routing | Static routes |
|---|---|
| IP plan | Announced unchanged |
| Multiple circuits | Supported |
| Firewall | Circuit traffic passes edge rules |
| Traffic path | Off the internet, through the customer's edge |
| Other paths on the same edge | Internet egress and IPsec VPN |
| Dynamic routing | BGP: neighbours, prefix lists, route advertisement |
| Edge gateway | Active/standby |
|---|---|
| Status | In production with several customers |
| Compatible connection | SD-WAN |
| Data centres | Equinix Istanbul (Dudullu) and Türk Telekom Ankara |
If something breaks
The active side of the edge fails
The edge gateway runs active/standby, so a failure on the active side does not cut the circuit. The standby side takes over and circuit traffic keeps passing through the edge.
A physical host in the cloud fails
If the physical host under the virtual servers your circuit reaches goes down, the platform restarts those virtual machines on other hosts automatically.
Frequently asked questions
Pricing and first steps
Pricing
The cloud resources you reach through Private Connectivity are billed monthly, with invoices issued as e-Invoice or e-Archive documents. The price of the link itself depends on your locations and circuit details, while the carrier circuit is billed under your contract with the carrier.
What the price depends on
- Number and size of the cloud virtual servers you reach over the circuit
- Storage used by those servers (GB)
- Internet traffic leaving through the same edge (GB)
How to get started
- 1.Tell us which locations to connect and which carrier you use, through the form or by calling 0800 606 1071.
- 2.The circuit layout and price are worked out in one call.
- 3.Once your circuit is delivered, Nesnet connects the cloud side and your first branch reaches the cloud over the private path.
Take your cloud traffic off the internet
Tell Nesnet's team which locations you want to connect and which carrier you work with today; you'll hear back within the same business day. Your circuit is received in a segment of its own and connected straight to your cloud network.