Megaport Connect Cloud Networking Summit

Internet vs Private Connectivity: Choosing the Right Architecture for Cloud – Full Transcript

Host: There’s one question that comes up in almost every cloud architecture conversation. Can anyone guess what it is? When should you use the public internet, and when does private connectivity make more sense? The answer to that really depends on what you’re trying to accomplish. Different workloads have different performance requirements, security considerations, and cost constraints, and there isn’t necessarily one right answer for every environment.

Our next speaker is Kori Rongey, a federal solutions engineering leader at Cisco. Kori works with teams supporting mission-critical environments, and today, she’s going to help us break down the differences between internet and private connectivity and how to choose the right approach. Please welcome Kori.

Kori Rongey: Life is a highway, Rascal Flatts. So is connectivity. Thank you, guys. And thank you to the Megaport team for having me here, and the rest of you guys for spending the next 30 or so minutes with me talking about the highways, the roads that get us to the cloud and to our users. By way of introduction, I’m Kori Rongey. Like Alexis said, I am a solutions engineering leader at Cisco. I work for our federal scientific agencies.

I’ll mention who they are because, one, I love who they are and what they do and what I get to do with them. But most importantly, these are organizations that move serious data and have serious security requirements. I support the Department of Energy, the Department of Commerce, and a little space agency called NASA.

I’m an engineer. I’m a leader. I am a mom of one precious 13-year-old boy. And hopefully, by the end of this presentation, that count is still only one. I am currently baking number two. So if I sit down or take pauses, it’s because I’m very pregnant.

I am also an avid adventurer. You can find me happiest on a trail or on a flight somewhere, although do not trust me to pick the road on an adventure, because I most surely will get you lost. But luckily, my directional challenges don’t translate to networking. So let’s get started. This is not optional participation. I will hunt you down and find each and every one of you. So let’s start with a few questions.

One, raise your hand if you run production workloads on the internet. All right. Now keep your hand raised if you have at least one private cloud connection. Okay. And thank you to the folks online who are also raising your hands. I promise I cannot see you, so feel free to put them down. Your work-from-home colleagues may think you’re a little crazy right now.

But keep your hand raised if you’ve ever been asked, hey, why are we paying for that circuit? And a sigh falls over the crowd. Research has found that for more than 90% of midsize and large enterprises, a single hour of downtime costs over $300,000. So next time you’re asked why are we paying for that circuit, that is why.

And the internet is a busy place. It’s often not your gear that fails. Uptime Institute’s 2026 analysis showed about two-thirds of publicly reported outages traced back to third parties: cloud providers, internet, and telco providers. And the internet’s very busy too. ThousandEyes, which is a part of Cisco, tracks over 300 global network outage events every single week.

The internet is busy. And what I want to point out is that most of you are already using both public and private connections, and neither one of them is perfect. So this is not a conversation of which path is better and which one wins. It’s how we select the path for the situation that we’re in.

I’m going to give a quick map of the ride that we’re on, this highway, if you will. We’re going to talk about our three paths to the cloud, then the five lenses we use to evaluate which path we select, a couple of myths I want to retire, brief guidelines for real-life workloads, and then finally, a framework that you can take back and start implementing on Monday.

Our three roads to the cloud. Russ gave a great example last year, and you know what they say? If it’s not broke, don’t fix it. We’re going to stick with it. But I want to outline our options here.

The public internet is more like the city bus. It’s cheap. It goes everywhere. It’s ready in minutes, and you don’t need anybody’s permission to ride. But it’s a shared route, it’s best effort, and you don’t control the stops. And if you’re a Chicago local, much like the L during a morning commute, you may be a little delayed, and nobody’s saying sorry.

Next up is our dedicated private path. That is more like a private helicopter. Your Direct Connects, your Google Cloud Interconnects, your Oracle FastConnects, you own the path. It’s predictable. It’s isolated. But you need a helipad to get there, whether this be a data center or a connection point. And it’s expensive. It’s isolated from the internet, but you’re paying for that connection whether you use it or not. You’re still paying for that helipad.

Next up is the rideshare, the network as a service. You need one physical port to connect to many clouds. You can stand it up quickly, but you don’t own the car. You don’t own the roads, but you can spin it up and spin it down in minutes, and you pay for what you use.

Key point: these aren’t three tiers of good, better, best. Although I will say, I have never ridden in a private helicopter, so some may correct me on that. That may be the best mode of transportation. But no, simply, when we’re talking about networking, these are just three different tools. And most mature architectures use at least two of them. And it is not uncommon to see all three of these in our environment.

When I was early in my career, I went to a conference and somebody was giving a presentation about bake-offs and how to do a successful bake-off. I am not telling you that you need to do a bake-off every time you’re making a connection to the cloud, but something that she presented really stuck with me. The most important rule when making a technical decision was to define your criteria and stick to it. That way you weren’t making an emotional decision or falling back on habits or thinking about which vendor you talked to last or who wooed you the most with the fancy T-shirt or the water bottle, even though we love Megaport’s T-shirts and water bottles.

Really, technical decisions need to have emotion taken out of them. So these are the five lenses that I would use to evaluate that decision. We’ll call them the Fab Five, because why not make it cute? And the note is, no road is going to win every single one of these five, and that’s why this is a design decision and not a default rule. Next, we’re going to talk through performance, reliability, security, cost, and operations outcomes for the three roads that we have in front of us.

First, I wanted to talk about performance, because it’s what our users feel the most. The public internet is often fast on average, and then it isn’t. You hit work hours, you hit the evening, and you run into latency. BGP picks a path for reachability. It doesn’t choose the path to make your application look good or so your users have a good day. You can have congestion at peering points, reroutes, and that packet loss shows up as jitter.

Now private paths trade that for consistency. It’s a known path, stable latency, and high throughput for sustained workflows. So what this means is SaaS applications, web traffic, and bursty user traffic usually do great on the internet. Now, sensitive workloads like replication, storage, voice, and video applications, these feel every second of variance.

Now you may be saying, okay, Kori, if I run the averages on this chart here, the internet is better on average than a private connection. Is that true? Well, no, because the average is a lie. And I promise you, and we all know, that our users are not calling into our leadership or opening a ticket to tell us about the great experience that they had with the average performance. No.

We need to build for the worst-case scenario. How do our users still operate even on the worst of days? So if we have an application that can’t withstand jitter or loss, we need to consider not going over the public internet.

Now, as I mentioned earlier, the internet is a very busy place. ThousandEyes, the week that I created this PowerPoint deck, saw 531 global outage events within that single week. Of those, 246 were ISP outages, and 187 were public cloud network outages. Now the internet is massively resilient as a system, but you don’t control the paths, and nobody gives you an end-to-end SLA, because nobody owns the entire road.

Private connectivity may bring you an SLA and a known path, but there’s one catch. One circuit is a failure domain. And the backhoe that just ran over your wires doesn’t care about your SLA. Fun fact: construction crews are one of the number one causes of direct connectivity outages. And that’s great if you get some money back because you got an SLA. Great. Discount on the next bill. What it doesn’t get is your reputation back. It doesn’t get your traffic back.

So we need to design for failure. If we have a private path, we need to know that that path may fail, may get run over by a construction crew or compressed by a train line. And so the most common pattern we see is private as primary and internet VPN as backup. Or we may see two private paths. But note that two paths don’t automatically mean redundancy. If they’re coming out of the same building and going over the same geographic environment, it’s just as good as one. So two paths over diverse sites for your crown jewels. Private is not redundant unless you build it that way.

The next very hot topic I’m going to talk about is security. And I want to break this down into two things, security and isolation. Private connectivity does keep your traffic off the public internet, and that does shrink your attack surface. That gives compliance teams comfort, not because it’s giving us security, but because it’s isolating us from the broader environment. Every piece of traffic that’s being passed over the internet is being hit with denial of service. It’s being sniffed. People are looking at it.

Most private links are not encrypted by default. And if the data needs protecting in transit, we do seriously need to add MACsec on the link or IPsec over it. But the internet also does need securing. The internet has gotten much easier to defend. We have strong encryption everywhere. Plus, with zero trust and SSE, we’re able to put identity at the center rather than the network path.

So in regulated industries, what I’m seeing is a push towards private paths, but we’re still adding that encryption layer on top. And when we are using the internet, we’re adding that identity-based security on top. So that way, when we need exposure reduction, we’re getting that with a private path. We are always, always building for security.

Now, the thing that many of our bosses care about: how much is this going to cost me? And there’s a reason why we don’t just have a million dedicated, direct private connections coming out of our headquarters buildings. The volume makes a big difference. For the internet, we have low fixed costs and high variable. For private connections, we may have a high fixed cost or high front-end cost and a low variable cost.

Now, that’s the classic crossover. Importantly, these alone are going to break even surprisingly early. But that math shifts when you start looking at network as a service providers. In this chart, you can see that crossover happens much sooner when we have NaaS, because we have a lower cost to deploy. We have a lower fixed cost and a lower variable cost.

I’m going to talk about speed to deploy. This is a huge consideration, and this isn’t just a fun fact that Megaport is going to talk to you about when you go into a sales meeting with them. Speed to deploy is a business requirement. It doesn’t matter how great your connection is and how fast the traffic moves once you have it stood up. How long is it going to take us to actually stand this up?

Internet VPN could take minutes to hours. Virtual cross connects over an existing NaaS port could take minutes. I think Megaport says 30 minutes or something like that. I’m probably getting that number wrong.

Audience member: 60 seconds.

Kori Rongey: Oh my gosh. It’s even better than I could have thought. So network as a service could stand up a new connection in 60 seconds. Now a new dedicated circuit is typically going to take you weeks to months, depending on the location and the carrier and, I’m convinced, a little bit of sheer luck.

And the complexity scales too. You have BGP design, dual providers, routing policies, and monitoring across multiple clouds. And you can’t fix what you can’t see. So whichever road you take, I do want to make sure that we’re talking about the importance of investing in end-to-end path visibility. That way you know whether it’s the app, your telco provider, the internet, or your Direct Connect that’s causing a slowdown for your users. So the rule of thumb is optimize for agility early and add control where the workloads need it.

Now, five myths that I want to bust while we’re here. One, a private path is automatically secure. No. Just because it’s isolated does not mean that it’s encrypted. Two, the internet is always cheaper. No. At scale, egress can flip that math very quickly. Three, one private circuit equals high availability. Absolutely not. One circuit is a critical failure domain. And two circuits, when not designed properly, can still be a failure domain.

Four, the internet isn’t enterprise grade. That’s absolutely not true. For SaaS and remote users, it’s oftentimes the best path. And if we need enterprise-grade security, we can add that on top of our internet path. Five, and I lost count here. Five, you have to pick one. No, you absolutely don’t. And quite frankly, you shouldn’t. Mature architectures are mixing connection types, so I’d encourage you to consider diversifying your connections.

I promised I would leave you with a little bit of real-world examples. Again, every decision you make should use the decision matrix specific to your environment. But as a general rule of thumb, distributed workforce and SaaS applications are great over the internet. Secure them with SSE and zero trust, and the apps that live on the internet don’t have to hairpin users back through a data center.

Database replication, ERP, paths to the cloud, you want to go over a private connection. It’s steady. It’s high volume. They’re latency-sensitive workloads, and they’re often regulated.

Now AI. I wouldn’t get through this without saying AI. Research and AI data pipelines, private connections or network as a service. Think about a national lab that’s moving petabytes to GPU capacity. Throughput and egress economics will push us towards private connections and network as a service, because the ability to burst up for a campaign and then back down gives us flexibility when it comes to how we’re spending money.

Now multicloud applications, going cloud to cloud over network as a service. You have an application in one cloud and data in another, and you need to connect them directly. Skip the data center. Connect the clouds.

As a bonus pattern, dev and test environments and pilots often are starting on the internet and then graduating to a private path when they come into production or when the IT staff gets ahold of them. So don’t be surprised if we’re seeing workloads start on the internet and then move as they become a reality.

Now, last year, Russ showed this cheat sheet. And I populated it for us, looking at what each path does best. And I’m not just giving our network as a service column a lot of green lights just because we’re speaking at a Megaport event. The truth is that this does balance the best of both worlds. But again, it depends on your specific scenario, your workloads, and your enterprise.

So, five questions to ask every workload. One, how sensitive is my application to latency and jitter? How much data do I need to move, and how much does the stability matter during that move? What compliance is required of me? What does an hour of downtime cost my business or my research center? And how fast do we need this connection to stand up, and how long does it need to stay for? And as a bonus, always keep a second path, redundancy.

So it’s not internet versus private. It’s which is the right road for each workload. Three things to take home: match the workload, design for failure on every path, and revisit the decision often. Connectivity is a design. This is not a one-time project. This is an architecture that’s going to live and breathe in your environment. Just because a workload starts moving over the internet doesn’t mean that’s where it needs to live forever.

Thank you all for the time and for spending your last 30 minutes of Connect with me. And I think we’re all wrapped up.