Megaport Connect Cloud Networking Summit
A first-of-its-kind virtual summit built to help network engineers and IT leaders upskill, share ideas, and connect around the future of cloud and hybrid networking
Building Secure Hybrid Multicloud Architectures
Jeremiah Johnson
US Cloud Engineering Manager, Fortinet
Jeremiah is Manager of the US Cloud Field CSE team at Fortinet, with 20+ years in cybersecurity. He helps organizations securely adopt cloud technologies and is a frequent leader in cloud security, networking, and public cloud strategy.
Building Secure Hybrid Multicloud Architectures – Key Takeaways
Overview
Jeremiah Johnson, US Cloud Engineering Manager at Fortinet, presents a practical, experience-driven look at how organizations connect and secure environments that span on-premises data centers and multiple public clouds. Johnson has more than twenty years of experience in cybersecurity, with a background in on-premises work and hands-on installations, and his team covers the United States for Fortinet’s cloud products.
The session is framed around a familiar pattern: few organizations deliberately set out to build a complicated multicloud environment. They start with one cloud provider, keep some workloads on premises, add a data center, go through an acquisition, and then need to deploy AI. The result is infrastructure spread across many places, with one team responsible for making it work together and keeping it secure.
Johnson works through a series of real customer situations that show where hybrid multicloud designs tend to break: untested failover, legacy traffic paths, unprotected east-west traffic, overlooked APIs, poorly planned regions, and AI agents acting without a clear identity. The central theme is that the network still underpins everything, and that planning and architecture have to come before products and deployment.
1. Networking Remains the Foundation
Johnson opens by asking the audience what three seemingly unrelated things have in common. The answer is networking: each depends on a secure, reliable network. The point sounds simple, but he argues that connectivity is easy to forget precisely because it usually just works.
Networks have come a long way since business internet, cable, DSL, and T1 lines were the only options for remote locations. That progress makes them easy to take for granted, but when something does break, the failure is loud and highly visible, and the network is usually the first thing blamed.
2. Untested Failover Can Break a Healthy-Looking Application
The first of two real customer stories involves the launch of an AI application, with the cutover scheduled for 3 AM. Once the public begins using it, problems appear quickly: responses slow down, and questions either time out or produce made-up answers.
Every team checks its own area and finds nothing wrong. The security team reports no issues, the network team sees green dashboards and can ping everything, and the developers insist the problem is not theirs.
The root cause is a failover that had never been tested. The application had been running in US East 1 and failed over to a region in another country. The failover itself works, but latency to the new location is poor. The application had not been built with that latency in mind, so when it did not receive a response within a very short window, it began to hallucinate. Everything was technically working, yet latency created a major issue.
The team has to fail back and turn off the new features, and because a new change window is needed, the deployment slips by an extra month. The entire setback traces back to a simple network change that could have been planned and tested more thoroughly.
3. Legacy Hub-and-Spoke Paths Do Not Fit the Cloud
The second story involves a retail company moving from legacy on-premises infrastructure into the cloud. The plan is to give stores their own smaller networks, with VPCs closer to the business, so that transactions perform well. On paper, the concept is sound.
The problem is the traffic path. Instead of sending store traffic directly to the regional hubs and data centers, the company routes it through the corporate office. This reflects the hub-and-spoke model many network engineers grew up with, in which everything travels through corporate, is scanned there, and then continues to its destination. Johnson is blunt that with a proper cloud setup this is a poor design, citing ingress, egress, and failover among the reasons to avoid it.
Rather than covering the short distance between a store and its regional hub, traffic makes a round trip of 2,400 miles. The consequences become visible on Black Friday, when a C-level executive (Johnson believes it was the CFO) waits in a checkout line with his family while transactions take so long that staff can only apologize. The issue has since been fixed, and the company is now a Megaport customer, connecting between data centers in different cloud service providers.
4. The Network Has Changed, Not Disappeared
Johnson describes problems like these as hidden dependencies, and ties them to how the network itself has changed. For a legacy network engineer moving to the cloud, the concepts are familiar: NAT policies, firewall rules, and routing all still exist. What differs is how they are executed.
He compares the situation to how many organizations approach AI today, where someone who works on Active Directory or as a developer suddenly becomes the AI person simply because they work in technology. Networking went through the same shift. Legacy network engineers were told to move to the cloud and learn AWS, and then, when the company adopted Google Cloud, had to learn a platform that does things very differently. The network did not go away; what changed is the way organizations use and configure it.
5. East-West Traffic and the Limits of Checkbox Security
One of the most common gaps Johnson encounters is east-west traffic. A typical example is a public-facing website in one VPC with a back-end SQL database behind it. Because the traffic between them is internal, organizations open it up completely, with no security controls and no ACLs, on the assumption that internal traffic is safe. Johnson states plainly that this assumption is wrong.
The same pattern appears with cross-connectivity between VPCs. In AWS, Google Cloud, Azure, or any other cloud provider, connecting VPCs can take only a few clicks, and the easiest rule to apply is one that grants full access.
He is equally critical of checkbox security, where large organizations treat a passing grade as proof that they are secure. He recounts a conversation with a bank customer who feels a proposed security approach would be expensive. Asked about the alternative, the customer points to two things:
- Native cloud tooling. The bank has the AWS firewall turned on. Johnson’s view is that security is not the core focus of the cloud providers’ native tools, and that their security efficacy should not be taken for granted.
- Cyber insurance. The bank plans simply to call its insurer if it is breached. Johnson suggests an insurer would not welcome hearing that, and compares it to car insurance: having coverage is no reason to test it by driving into a brick wall.
6. Complexity Becomes Manageable With Deliberate Decisions
Johnson acknowledges that hybrid multicloud security can feel chaotic. In the field, he notes, the moment a topic like AWS Transit Gateway comes up, the conversation tends to get escalated to his team. Users, SD-WAN, and connectivity into, across, and within clouds all add moving parts.
Every design involves a series of decisions, whether traffic moves from on premises to the cloud, through a regional point of presence (POP) or hub, or directly into a cloud provider. He frames these as concrete questions:
- How does a site, such as a retail location, reach the cloud?
- How is secure access handled for public access?
- How do users reach the organization’s crown jewels hosted in a provider such as Google Cloud?
Johnson’s position is that this is not complex if teams sit down and talk it through. Yet few do. Many organizations have run tabletop exercises for their traditional networks, but he has met only one other company that has run one for the cloud, actually failing over live from one US East region to another and testing a disaster recovery plan for its cloud environment.
7. Hybrid and Multicloud Are the Long-Term Reality
Echoing a point made earlier at the event, Johnson argues that organizations will become multicloud whether they plan to or not. A development group may favor Oracle, the marketing department may prefer Google, or an acquired company may have built everything in Azure, leaving an environment that has to be maintained for some time.
He expects hybrid multicloud to be where organizations live for quite some time, and on-premises infrastructure is not going away soon. For some workloads, particularly those involving very large amounts of stored data, the cloud does not always make sense, which makes connectivity between the cloud and on-premises environments important, including as a way to potentially save money.
Cost is a recurring theme. Done correctly, with ephemeral services that spin up and down, the cloud can save money, but many organizations end up with bills that do not reflect the expected savings because they do not understand how to plan for them. Data is a particular blind spot: teams need to know how data costs are calculated and what would happen to the budget if a developer pulled down petabytes of data to test something. Transacting a petabyte of data through the cloud, he notes, costs a lot.
8. Moving Security to the Virtual Edge
Johnson introduces the virtual edge: bringing security and networking closer to the user. He illustrates it with remote access, where organizations should be moving away from traditional IPsec connections and toward SASE. He is direct about SSL VPN: organizations still using it should stop.
Roughly ten to fifteen years ago, IPsec was viewed as insecure and the industry moved to SSL VPN. Over time, it became clear that certificates were not as secure as assumed, and the direction has shifted back. Fortinet has gone as far as turning SSL VPN off: beyond a certain firmware version, it no longer appears as a feature, because of its inherent insecurity.
In the model Johnson describes, SASE, from whichever vendor an organization chooses, starts security at the endpoint and connects the user to the closest regional POP. That POP is where the virtual edge comes into play and where core security functions run:
- Scanning and content filtering of user traffic.
- Threat prevention before traffic moves further into the environment.
- Endpoint checks confirming that a device has the right security tooling, with current signatures and database updates.
From that regional point, decisions are made close to the user about where traffic goes: to AWS, to a private data center, through secure private access (SPA) to homegrown applications, or out to public-facing services through the POP. Making these decisions near the user also reduces the cost of data transacting in the cloud, a win for the finance department. Products will vary, Johnson adds, but the architecture should be in place before anything is deployed.
9. APIs and Regions Are Easy to Overlook
Johnson cautions against buying products, however impressive the demo, before working out what to do with them. Teams should first understand site-to-cloud connectivity, cloud-to-cloud connectivity, and traffic within each cloud. Two areas often missed in that planning are APIs and region placement.
On APIs, he describes a state lottery that insisted on comprehensive security. That seemed surprising at first, since in Ohio the lottery app only lets users scan tickets and check jackpots. In this customer’s state, however, winners can transfer winnings, such as $100 from a scratch-off ticket, directly to a bank account. The lottery therefore holds Social Security numbers, addresses, and bank account details, and is hit very hard all the time. Many organizations, Johnson says, do not secure their APIs at all, like an ostrich with its head in the sand, even though nearly everything people do on their phones is API driven.
On regions, placement should follow where the business operates. An organization that is entirely US-based has no reason to pay for a data center in a country where it does no business. That sounds obvious, but Johnson says it often is not. He describes a very large retailer, primarily on the East Coast, with workloads in both East and West regions. Rather than mapping stores by geography, the retailer assigns them by store number, with stores 1 through 500 going to the East Coast, and store number two is in California. The team has not changed the mapping because it does not know how and considers it too much work.
10. Five Design Decisions, With AI Treated as an Identity
Johnson condenses the discussion into five decisions intended to cut through the complexity:
- Map it out. Identify who is talking to what, what they are doing, and why, including AI tools.
- Define the trust. Organizations often withhold trust from an employee who has been with the company for twenty years, yet trust an AI bot downloaded yesterday.
- Figure out the paths. Sit down and literally draw the environment out, and if the person drawing is not the one who decides, talk to someone who is.
- Engineer failure. Decide in advance what happens if something goes down at 3 AM: will someone get a call, or will failover actually work?
- Operationalize it. Design the network with the people who will manage it in mind, and avoid making their work harder.
The first two decisions lead to one of the session’s central concerns: AI acting on someone’s behalf. People now readily hand AI tools such as ChatGPT or Grok sensitive information like medical records and bank details. When an AI tool acts on a person’s behalf and something goes wrong, the responsibility belongs to that person, not the bot, and this matters even more for agentic AI.
Johnson illustrates the risk with a story from a very large company that uses Gemini. During a team meeting of around 16 people, the team discusses concerns about their manager’s manager while Gemini records the session and takes notes. Because Gemini is built into the Google ecosystem the company uses, the agent decides on its own, with no human in the loop, to email the notes and the team’s concerns to that senior manager. The email appears to come from the team lead, with no indication that a bot sent it, and the team lead only finds out when the senior manager replies. The lesson is that identity needs to be controlled at the individual level: AI, and agentic AI in particular, should have its own user and be treated as an identity.
On operations, Johnson notes that AI has made log review and analyst work considerably easier, especially correlating whether an event at 2:01 AM is related to another at 2:05 AM. Even so, the goal is to make operations teams’ work simpler, and he still follows the KISS principle wherever possible.
11. A Practical Checklist for Hybrid Multicloud Design
Johnson closes with a checklist:
- Don’t lift and shift. An application that runs well on premises will not necessarily run well in the cloud, where dependencies are different, so applications should be designed for the cloud.
- Map the flows. Account for east-west traffic between VPCs and networks, and make sure security is in place there before choosing the tools to inspect it.
- Rethink the first mile. Many organizations have paid a lot for MPLS. Today there are options such as Starlink and the new LEO satellite service coming from Amazon, and SD-WAN is very inexpensive, so two lower-cost business connections, or whatever makes sense, can serve the first mile.
- Go private in the middle. Relying only on a public VPN between two important data centers will, in Johnson’s view, let the organization down at some point.
- Inspect at the regional hubs. Inspection makes far more sense close to the business and its users.
- Build in diversity. Connecting two data centers to everything should be basic practice. Planning to simply spin resources up if the East region fails only works for organizations that can tolerate being down for hours.
- Automate connectivity. Because it is the cloud, connectivity should be automated whenever possible.
- Reduce tool sprawl. Security products that communicate with one another, often described as a security fabric, matter more as tool counts grow. Johnson cites statistics showing enterprises with 70 to 80 security tools, many likely shelfware, and warns that an organization managing 80 tools is guaranteed to miss something.
Key Takeaways
- Networking still underpins every hybrid multicloud design. Connectivity is easy to forget because it usually works, but its failures affect everything.
- Failover has to be tested, not just configured. An untested failover to a distant region introduced enough latency to break an AI application while every dashboard looked healthy.
- Legacy hub-and-spoke routing does not translate to the cloud. Backhauling store traffic through a corporate office turned a short path into a 2,400-mile round trip and slowed transactions on Black Friday.
- East-west traffic needs security too. Traffic between VPCs and back-end systems is often left fully open on the assumption that internal means safe.
- Checkbox security, native defaults, and insurance are not a security strategy. The paths between environments need deliberate design rather than reliance on default tools or a policy to call after a breach.
- Multicloud is inevitable, and on premises is staying. Team preferences, acquisitions, and cost considerations mean most organizations will operate hybrid multicloud environments for a long time.
- Security belongs at the virtual edge. SASE that starts at the endpoint and inspects traffic at the nearest regional POP brings security closer to users and reduces cloud data costs.
- APIs and region placement deserve explicit planning. Unsecured APIs expose sensitive data, and region assignments that ignore geography create avoidable problems.
- AI agents should be treated as identities. Agentic AI acting on a person’s behalf needs its own user and clearly defined trust, as the unprompted Gemini email shows.
- Design for the people who operate the network. Engineering failure, automating connectivity, and reducing tool sprawl keep complex environments manageable.
Conclusion
The session presents secure hybrid multicloud architecture as less a matter of choosing the right products and more a matter of planning. Most of the failures Johnson describes, from the AI application that hallucinated after an untested failover to the retailer whose transactions traveled 2,400 miles, come not from broken technology but from decisions that were never mapped, tested, or revisited.
His recommendations follow from that: map who and what is communicating, including AI agents; define trust deliberately; draw out the paths; engineer for failure; and keep operations simple. Security should cover east-west traffic and APIs, move closer to users through SASE and the virtual edge, and happen at regional hubs rather than by backhauling traffic through a central site.
The overall lesson is that hybrid multicloud is the long-term reality and the network remains at its center. Organizations that work through site-to-cloud, cloud-to-cloud, and in-cloud connectivity before deploying, and test those designs as seriously as their on-premises networks, are better placed to stay secure and reliable.
Building Secure Hybrid Multicloud Architectures – Full Transcript
Host: Most companies don’t intentionally set out to build some incredibly complicated multicloud environment. You start with one cloud provider. You keep some workloads on-prem. Maybe you add another data center. You go through an acquisition. Now you have to deploy AI. And suddenly, you’ve got infrastructure across five different places, and your team is responsible for making all of it work together and keeping it secure.
So our next speaker is Jeremiah Johnson. He is a US Cloud Engineering Manager at Fortinet, and Jeremiah has over 20 years of experience in cybersecurity. He’s going to show us the core principles of designing a secure hybrid multicloud network, including connectivity, segmentation, and the mistakes that teams commonly make. So please welcome Jeremiah.
Jeremiah Johnson: I’m just going to listen to the music for a minute. I felt kind of special. I got my own walk-up music. So Clint was great. I told him I was going to call him Clint. His name’s not Clint, it’s Jeff. You should definitely follow him. He’s a lot of fun.
So I was thinking as he was telling that story, because we did a dry run yesterday, and he did not tell that story. You know how they come over the intercoms at airports and they’re like, do not take anything, maintain your bag. And you’ve got Jeff going through and he’s like, yeah, that’s a Raspberry Pi. Well, sir, what’s it do? I don’t know. Some stranger gave it to me at an event and told me to take it home. And they’re like, just wait right here. We’re going to go get somebody to talk to you, sir. So it’s a good thing you gave that up, Jeff. That was a good decision.
My name’s Jeremiah. This is a full sales presentation for me at Fortinet to outdo my friend Holly at Palo Alto. I’m kidding. We’re not going to sell anything today.
We’re going to dive right in and talk about a few things. So one, this is me. I’ve been doing cybersecurity for a long time. I come from doing the on-prem, a lot of installs, things like that. If you have done installs or you have been an analyst, thank you for your time served. If you’re still doing it, I’m sorry. Those things tend to make us older, with grayer hair, or sometimes you lose your hair.
In my off time, I do Southern Ohio Forest Rally. If you’ve not heard of that, I love cars. I love racing. That’s a thing. I’m a dad, a husband, and I am on a school board. I got into a little bit of politicking last fall, and I found out I am not built for the political world. They said I was too nice. So no politics for me outside of school board.
One more thing, and I’m a little disappointed nobody pointed and remembered me. Did anybody go to school, college maybe, in the early 2000s or before? So when I graduated in 2003 from college, I did have a degree in networking and web design. It was a tough time because we started out ramped up. And I had some friends, judge me if you’d like, they got into IT when I was a senior. And they started out making $50,000 a year. And I was like, man, if I could make that, I would be on top of the world. A Porsche 911 is going to be in my garage. That was a long time ago, a little naive.
And then the market changed, and the jobs actually weren’t $50,000, $60,000. They were more like entry level, $30,000, $40,000. And I didn’t want to drive to Columbus, Ohio, because I live in Chillicothe. It was an hour drive. I didn’t want to drive for $12 an hour. So I did a little traveling, and I went out west, and I found myself as a backup dancer for Ms. Britney Spears for a year. So I have aged a little bit, but nobody seemed to recognize me. That’s okay. I made that whole thing up. So anyhow, sorry. I like to have a little fun.
So when we start talking about networking, and all of you hopefully know what Megaport does, I think we tend to forget about some of these things that we’re talking about today. Does anybody know, and I just gave it away, but does anybody know what all these three things have in common? Technically the answer could be compute. Does anybody? Nobody’s going to guess?
Audience member: Firewall.
Jeremiah Johnson: Thank you for guessing. Okay, you know what? You get an AirTag. So when you get a second, you come up and you get this nice little AirTag that I had for somebody to answer my question. It’s actually not, but that was a good guess. It is networking.
All of those things depend on a secure, reliable network. And I know that sounds a little cheesy, but at the same time, we forget about the connectivity. We forget because things just work. Networks have come a long way, if you’ve been in the industry for a while and you remember when business internet, cable, DSL, things like that were all you had at your off-prem locations. T1s. When I went to college, we had a bonded T1. We would sneak Napster in on our $4,000 laptops to try to download a few extra songs.
I feel like that’s illegal. I feel like I just said something really illegal. It wasn’t illegal back then, for anybody that’s younger than me. It was legal back then. Or maybe was it not legal? Maybe it was just ignored. We’ll say that. So anyhow, my point is networks have come a long way. And when things break, it’s the network’s problem, right? It’s just, usually it makes a really loud noise when the network does fall down.
So, two quick stories. Both of these are actually real. I did change a few things to leave out the customer. I was part of a deployment where they were going to launch, because everybody knows you do deployments at 3 AM, right? You do cutovers in the middle of the night because that’s convenient for everybody.
So we’re launching this AI application. And I’m going to have to look, because I’ll forget the times. But the point is we do the launch. Everybody’s ready to go. Let’s go. Everything’s good. We start testing things like that. Some people found that we switched on, and the public starts testing. Not intentionally, but it happens.
And things started failing. It started getting slow. When you would ask a question in the context, it would just time out or make some stuff up, because that’s what AI does. But the reason was, we had no idea. We were like, well, we don’t know what’s going on. So it was like, okay, security team, what’s it look like? Oh, dude, there’s nothing wrong. Everything’s good. Network team? Network looks great. Everything’s showing green. We’re looking at the dashboard. Everything’s good. We can ping everything. The developers are like, don’t blame us. It’s great. And we don’t know what the problem is.
Well, what had happened, and failover worked, but we had not tested the failover. So we were on US East 1, and, don’t judge, it wasn’t my application. I was part of the conversation. I did not develop it. We failed over to another country, and the latency was not good. It was bad. So we did not have, and I say we very loosely, the developers did not have latency baked in. So if it did not get a response in a very short amount of time, it would start hallucinating. So everything technically was working.
It’s just that latency created this massive issue. So of course we had to fail back and turn off the features, the upgrade. And it did not get deployed for an extra month, because we had to go back, get the window and all that stuff. And all because of a simple network change that we could have baked out a little bit better.
This one, I was actually talking to some of the other speakers yesterday, and we still see a lot of this. And if you do this, please don’t hate me. I’m not trying to call your baby ugly. There’s another one. Jeff will call your baby ugly.
So we have a ton of customers at Fortinet. I’m sure lots of companies have seen this, but I do travel a lot and I do have a lot of conversations. And sometimes I walk away just being like, I need some consulting services. But there’s a retail company that moved from a legacy on-prem, and they’re trying to move into cloud.
So what they were doing, they thought, we’re going to take all of our stores. We’re going to get our little mini networks, VPCs, closer to the business. That way the transactions and everything are going to be great. And conceptually, on paper, it was like, that’s a great idea. Well, what they were doing, as you can see, they decided instead of going directly to the data center, to the hubs, they would go through the corporate office.
Because hub and spoke, that’s what some of you grew up with. That’s how we connected everything. It went through corporate. We scanned it, on to the destination. Today with cloud, proper setup, that is a horrible idea. You should not do that. Ingress, egress, I could give you a whole list of reasons why you should not do that. That’s horrible failover. All kinds of things.
Anyhow, the point is they took a literal 20-minute gap between the store and the regional hub, and it went 2,400 miles round trip, through there and back down. And so, real story, though. They had a C-level, I do think it was the CFO, in line with his family during Black Friday at Thanksgiving. And they were waiting, and the line just kept going, and all they could do was apologize because the transactions were taking so long. That is fixed now, by the way. And they are actually a Megaport customer, going back and forth between a couple different data centers in different CSPs.
So, hidden dependencies. Again, the network has changed. So if you were a legacy network person and you moved to cloud, concepts are similar. NAT policies still exist. You still have firewall rules. You have routing. But they’re all executed a little differently.
And I’m going to bunny trail real quick. So if you are an Active Directory person, a developer or whatever in your day job, and then AI comes along, and you are now the guy or the gal. It’s like, well, you’re the technology person. You surely know AI. It’s like, well, not really. I went to school for networking and web design. I don’t automatically know AI, but I will be the person.
And we did that with networking. We took the legacy network person and we said, hey, we’re going to move to cloud. Now all of a sudden, you had to learn AWS as the network person. And you figured it out. And then the company was like, oh, Dave, we’re going to go to Google now. You’re the Google guy. It’s like, well, Google does things very differently than AWS. Very differently. So you had to learn all those things. So the network didn’t move. It’s still very much there. It’s just we changed the way that we utilize it and configure it.
I think a lot of companies, actually, I don’t think, I know. A lot of companies forgot about the east-west traffic. And this is from real-world conversations that we have. If you get into the public VPC and you need access to a website, and on the back end there’s a database, SQL, whatever, they just open it up. There’s no security. There’s no ACLs. It’s just, you need access to this VPC, we’re going to give it to you because it’s east-west. It’s internal. It’s safe. Well, that’s wrong.
And then the cross-connectivity. If you do that blindly, and you click a couple buttons in Amazon or Google or Azure or your favorite CSP, and you just connect two VPCs, the easiest way to put rules in is any-any. Just, there you go. Full access. So the path between those, a lot of times, I see so many big companies rely on checkbox security, and it drives me nuts. If you come to me and we do a POC and you say, we really like the UI or something about this other company, okay, cool. If you say, you know what, we’re checkbox security and we just like that, somebody told us A-plus, you’re secure, I will probably not do business there anymore, because that just stresses me out.
I had a customer, and I so wish I could tell you the company. It was a bank. He said, Jeremiah, this is all great. He goes, that looks like it will cost a lot of money. I said, well, for a company your size, it would be a little bit. I said, but what’s the alternative? He’s like, well, we have the native tools, right? We have AWS firewall turned on. I was like, no offense to our friends at AWS, I love them. Their security efficacy is not very good. It’s not what they do. They don’t really do security.
He said, we also have cybersecurity insurance. I was like, what? He said, yeah. He said, if we get breached, he goes, we just call, and I’m not going to say the name of the other company, but this company. And I said, I’m pretty sure if they heard you say that, they would cancel your policy. I don’t think insurance companies like that. I have car insurance. I’m not going to test driving into a brick wall. I know it’ll pay for it, but I’m not going to test them. So anyhow, we do forget about the security side of that quite a bit.
And I think it does feel chaotic. My team, we cover the US for our cloud products at Fortinet. We have 40, no, we don’t. We have 50 products. Let’s just say 40. But everything’s 40-something. And when you get to 40 cloud products, the field, as with other things, it’s a little more complex. And as soon as somebody drops the word Transit Gateway, it’s like, whoa. Let me call Jeremiah. Get back to you on that one.
So it does feel chaotic. We have the users, SD-WAN, all of the different components that get you into cloud, and across cloud, and in the cloud. So it is a little bit more chaotic. Every decision that we make, whether you go from on-prem to the cloud, if you go to a regional POP like a hub, and I just said hub and spoke. It came out. Didn’t mean to do it.
But if you go through, and just the connectivity into that cloud, there’s a lot of decisions you have to make. What are you going to do from, let’s say, your retail? What are you going to do from site A to get to the cloud? How do you get into your secure access for public access? How are you going to get to your crown jewels in Google? What do those look like? So there’s lots of complexity. Let me back up. It’s not complex if you sit down and talk about it.
What I have found is, has anybody ever done a tabletop exercise in their regular network? If you have ever done one for cloud, come talk to me after, because I have met one other company that did a cloud tabletop exercise, and actually went through and failed over from one US East to another one, live, and actually tested a DR plan for cloud.
The hybrid approach and the multicloud, I think Holly said that earlier. Whether you plan to be multicloud, you will be. You will have development, for some reason they like Oracle, maybe. You’ll have the marketing department that really loves Google. Or you acquire. You acquire a company and they’ve built everything in Azure, and you have to maintain that environment for a while. So the multicloud hybrid approach, I think, is going to be where we all live for quite some time. On-prem is not going away anytime soon.
And sometimes, I’m not going to steal his thunder, but I was talking to an individual that will be speaking this afternoon. They do lots and lots and lots of storage data. Sometimes it doesn’t make sense to be in cloud. So you need the connectivity from the cloud to your on-prem to potentially save you money, right? So if anybody went to cloud to save money, I’d like to know what your thoughts were on that, and if it worked out for you. If you do it right, and you use ephemeral services that spin up and down, you can save money. Typically, though, you end up with bills that are not. And that’s why I think the whole tabletop thing has gone out the window for cloud, because a lot of people don’t understand how to do it.
How do you calculate that data? The cost of the data. What happens if somebody in development decides to pull down petabytes of data to test something? What’s that going to look like for your budget? I can tell you that a petabyte of data will cost a lot if you’re transacting through the cloud.
Does anybody know what the virtual edge actually means? Ever heard that? So, getting the security and the networking closer to the user. So for example, hopefully most of you are not doing traditional IPsec into something, and you’re doing more of a SASE application if you’re remote. If you’re using SSL VPN, please stop. Let’s see, what was that? 10 to 15 years ago, IPsec was bad. Don’t use it. It’s not secure. Everybody go to SSL VPN. And then we found out certificates actually aren’t as secure as what we thought. So now it’s going back the other way. And actually, at Fortinet, we shut it off. You can’t even use SSL VPN anymore. We’ve shut it off on the boxes. So once you get to a certain firmware, it doesn’t even show up as a feature, just because of the inherent insecurity of it.
So you should be using SASE of some brand. That SASE should take the security of that, it should start at your endpoint. It should go to the closest POP, wherever you are regionally. And then from there you go into, like I said, that’s where that virtual edge really comes into play, and you start all of your basics of scanning, content filtering, threat prevention, endpoint checking to see if they have the right security on there. If you use, I don’t know, pick your favorite endpoint security, CrowdStrike. Do they have the right signature, the right database update, things like that?
And then you make the decisions at that regional spot, closer to the user, on whether they need to go to AWS, or they need to go to your private data center. And then if you do SPA, so Secure Private Access, into maybe your own little homegrown applications. Or public access, where you want things that go into, maybe you have a SAP solution, and you want that to go through the POP. All those things are decisions that should be made closer to the user. That way, a couple reasons. One, you reduce the cost of data that’s transacting up in the cloud. Anytime we can do that, that’s a win for your financial department.
Products will vary, but the architecture should be baked in before we start deploying things. And I’m guilty of it too. I’ve bought products and had no idea what I was going to do with them. I get home and I’m like, yeah, I bought this. I’m like, wait a second. And another quick bunny trail.
Do you guys have Menards here? Yeah. So I went to Menards. I love that store. You can buy two-by-fours and cereal all at the same time. So I was there, and I saw this. If you’ve done a Teams or Zoom call with me, you’ll see it. There’s a 6-foot tree. It was an autumn tree, a maple tree. It has LEDs on it, little light-up things. And we have a foyer when you walk in the house. And I saw this tree and I thought, man, my wife would love that.
So I bought it. It was $35. I take it home, and it was in the morning. I had a call at 10 or something, and I was like, I’m going to run into town real quick. I got it. Come home. Set it up. And I was on my call, and my wife came home, and she was like, what’s that? I was like, oh, you love that, don’t you? It’s so cute in our foyer. And she’s like, can we put it in your office? I was like, oh. So I thought I was doing a good deed. Anyhow, I picked a product before I really thought it through.
I have a quota, but I’m not sales. Sometimes salespeople sell you something and you’re like, wait a second. That looked so cool in the demo, but I don’t know what I’m going to do with it. So sit down, and not to be funny, but really sit down and understand the site to cloud. I’ve hit on that multiple times. But site to cloud, what’s cloud to cloud look like? In the cloud, whether it’s from one to the other.
Your API. I had a, I won’t say the name. It’s a lottery. It was a state lottery. And he said, we’ve got to have all the security. And I was like, well, in Ohio, we have an app, and all you can do is scan your lottery ticket and see what the jackpots are. You can’t buy anything. You can’t cash out. You can’t do anything like that on it. I was like, why are you so worried about security? I love it, but why? And he said, well, in our state, if you win the lottery, you win like $100 on a scratch-off, you can actually transfer it right to your bank account. And I was like, oh. So you have Social Security, you have addresses, you have bank accounts. So they are a target, and they get hit very, very hard all the time.
A lot of people totally forget about the APIs, and they don’t secure them at all. It’s like that ostrich thing. The danger’s all around you and you stick your head in the sand. That’s what a lot of people treat APIs as. And we totally forget to secure them a lot of times. Does everybody know that pretty much everything you’re doing on your phone is all API driven, of some type? So, we do forget that.
And then figure out the regions. What makes sense? If you are 100% US-based, and you do no business with North Korea, that was a joke, don’t do business with North Korea, you would not need to have a data center there. So it would not make sense for you to pay to have something there. I know that sounds almost obvious, but I will tell you it is not.
We have customers that are primarily East Coast, and this is a very large retail store, and they have East and West. And I said, oh, cool. I was like, so you keep your stuff, probably, east of the Mississippi in US East 1, and use the West for west of the Mississippi. And they’re like, oh, Jeremiah. Of course not. I said, well, how do you determine? He said, well, it’s based on store number. I said, oh, so your store numbers are, and he’s like, well, it’s whenever they come online. And he said stores 1 through 500 go to the East Coast. Well, guess what store number 2 was? California. I was like, well, why don’t you change that? Well, we don’t know how. He’s like, it’s too much. So they did no planning at all when they did that. And it shows sometimes. If you’re in their store, you would notice it.
So, five quick decisions to cut through some of that. And I stole this conversation with the last slide. Map things out. Who’s talking to what? I was going to mention this earlier, and I totally forgot, because my speaker notes, I apparently did not update.
I don’t know when we decided that, if I come up to you and ask you for your medical records, or your Social Security, or your bank account, or how much you make, well, you should have never told me that. And then all of a sudden, we gave it all to our best buddy, ChatGPT, or Grok, or whatever your favorite one is. It’s like, oh, here’s my MRI, here’s my blood work, here’s my bank, oh, you want my E-Trade account? Hell yeah, I trust you. Go ahead. Figure it out, make me some money.
And they’re doing it on behalf of you. And I’m not going to lie, this is again a little bunny trail. I’ve got a few minutes. Has anybody played with Clawdbot? I have it trading my Kalshi. Anyhow, it logged into my account. It has lost me $102. I have not made any money with it. But the fact that it can log in and make bets on my behalf, I could probably go to jail for that. Is that illegal? I don’t know. Anyhow, it was a joke. It was a joke for anybody watching. I didn’t really do that.
But my point is, it’s acting on Jeremiah’s behalf. So if something goes very, very wrong, it’s me, not the bot. I can’t be like, oh, my bot did it, I don’t know. So my point in saying that was about bots in your organization, AI, especially if it’s agentic AI, which hopefully you all know what that means.
And again, I’ve got a few minutes, so I’ll tell you this story. Real story, very large company. They were using Gemini. I’ll just tell you what the product was. They were using Gemini. Team meeting. The guy has a team of, I think, 16 people. And they were talking, and the company’s pretty progressive, so they’re pretty open about feelings. And they were discussing their boss’s boss, and they had some concerns. He managed a little harder, maybe, I guess you would say. And so they had Gemini running to record the session, and they take notes from that. Well, Gemini, because it’s baked into the Google ecosystem and they use Google, the agent took a note and said, I’m going to email, we’re going to say his name was Steve, I’m going to email Steve and let him know the concerns.
So it did. On its own. No human in the loop. It just emailed Steve and said, these are the meeting notes, and here’s the concerns. So the guy that was telling me this story, he got an email shortly after the meeting, and it was from Steve. And Steve’s like, oh my gosh, I had no idea you guys had concerns with the way I manage. And he’s like, oh my god, how’d he know that? He had no idea where the email came from. He went back and looked. Paul was his name. Paul sent the email to Steve, but it wasn’t Paul. It was Paul’s bot. And it didn’t say Paul’s bot. It didn’t say Gemini. It just said Paul. So that identity really needs to be controlled as an individual.
You can treat AI as your servant or your buddy. I choose buddy, just in case something ever goes really wrong. I don’t want the Terminator people to be like, that’s him. He told us what to do. I ask and say please and thank you. Sam Altman even said in an open interview that, even though it costs the company millions of dollars when you say please and thank you, he’s like, I would if I was you. So I was like, I’m going to take that as a note. I’m going to say please and thank you to my AI tools.
Back on track. So AI, especially agentic AI, should have a user. So when we talk about who’s talking to who, what they’re doing and why, keep in mind that that should include your AI tools. They should be treated as an identity.
Define the trust. Because again, for some reason we don’t trust the guy that’s been with the company for 20 years, but we trust the AI bot that we downloaded yesterday.
Figure out the paths. Do the logical thing. Sit down, literally draw it out. Does anybody still draw things out like I do? I still take paper, and I actually bought myself a reMarkable, if you’ve never had one. It feels like you’re writing on paper. I still do that on every call that I have, and I love it, because it helps me remember those things. But draw out what it looks like, what makes sense to you in your head, and then go through, and if you’re not the one to decide what really happens, talk to somebody. We do that all the time. We brainstorm all the time with customers.
Engineer failure. If things go down at 3 AM, are you going to get a call, or is it going to work? Will the failover work? Figure those things out.
And then operationalize it. So if you have employees that are doing log review, if you’re doing analyst things like that, AI has made that a lot easier, to be fair. The correlation between those things has gotten a lot easier than me trying to look at something that happened at 2:01 AM and then 2:05 AM, and then figure out if they’re related. Those things have changed quite a bit, and AI has been able to put those together a lot easier. But remember, try not to make it harder for those teams. Try to make it a little easier if you can. So, design those things in that network with the other people that are going to be managing it in mind. So, I still try to do the KISS method. Everybody, keep it simple, stupid. I still try to do that as much as possible.
So, checklist. Don’t lift and shift. Hopefully everybody has heard that term. Because you baked an application and it was awesome on-prem, it does not mean it’s going to be awesome in the cloud. Things run differently. Dependencies are different. So try never to do the lift and shift. Try to design it for the cloud. There’s a bunch of different terms for that, but that’s the one that I try to stay away from.
Map the flows. We talked about that pretty heavily. Do not forget the east and west. Don’t forget what’s going from one VPC, one network, to another. Make sure that we have security there before you pick the tools that you want to inspect it.
Internet, the first mile, you can argue about that one. We saw a lot of people using MPLS, paying a lot of money. Today, with things like Starlink, the new Leo from Amazon that’s coming out. Hopefully you don’t have DSL. I actually had DSL until a year ago. I finally got rid of it. I did get Starlink, because it was actually cheaper than my DSL. So that first thing, again, SD-WAN is fairly inexpensive. Actually, it is very inexpensive. So two cheaper business connections, or whatever makes sense to you.
And then go private in the middle. That’s where, when we rely on just a public VPN between two really important data centers, you will 100% be let down at some point.
Inspect. Again, the closer to the business or closer to the users you can get, at the regional hubs, makes way more sense.
Build in the diversity of that. Again, I know that two data centers to everything should be 101, and you should all be doing that. But I’ll be honest with you, some people are like, well, if our East region fails, we’ll just spin it up, because it only takes X amount of time. If you can stand to be down for hours. Did you hear the Southern Ohio come out in me right there? I said “fur.” I probably did that about 20 times. So “for” is what I meant to say.
Automate connectivity when you can. It’s cloud, so that should be every time. And then, I’m not going to call names, but security fabric is what a lot of people call it. So the more products you have talking, you should not have single pane of glass for much of anything anymore, because it’s too much. I’ve seen statistics where enterprise companies have 70 to 80 security tools. And I think a lot of those are probably shelfware. But if you’re managing 80 tools, you’re going to miss something. Guaranteed.
That’s it for me. If you guys would like to connect, that is, I promise you, a very safe QR code that takes you to my LinkedIn. If not, feel free to reach out if you have questions. If you’d like to talk about cars, sob stories, bad stories, I will be around all day. Thank you so much.
Need help mapping your cloud infrastructure path?
With a Megaport Solutions Architect
Find out how to connect your business in 60 seconds.
We’ve helped hundreds of customers, just like you, to simplify their connectivity.