That meant taking on a challenge no one in the industry had fully solved: Can an AI system understand a networking request well enough to translate it into pricing, feasibility checks, and full provisioning in real time—safely and reliably?

Here are some of the biggest lessons we learned along the way.

1. Natural language can be messy

Networking is deterministic, but language is anything but.

People describe the same requirement in wildly different ways:

“Connect AWS to Azure”
“Build a link between my cloud environments”
“I need multi-cloud connectivity in US-East”
“Give me a 100G path from LAX1 to NYC2”

Teaching a model to understand these nuances required far more than prompt engineering. We had to deeply constrain and structure how the system interprets requests, because ambiguity is acceptable in conversation—but not in infrastructure.

That meant doing things like:

• Defining a canonical dictionary of networking concepts
• Teaching the system which phrases map to which service types
• Building guardrails so the model never “hallucinates” nonexistent products or configurations

The platform doesn’t just respond to language. It interprets intent and reliably maps that intent to real, deployable infrastructure.

2. Validation matters as much as generation

In consumer AI, a small error is usually tolerable. In infrastructure, it’s not.

A model cannot:

• Quote a link that doesn’t exist
• Return an impossible configuration
• Provision a service incorrectly

So we designed the system so generation is never the final step. Instead, every request follows a strict flow:

• The AI proposes a solution
• The provisioning engine verifies feasibility
• Pricing is pulled from actual contracts and inventory
• Only then does provisioning occur

This hybrid approach—combining AI interpretation with deterministic automation—became essential. The AI accelerates understanding and interaction, but the underlying systems enforce accuracy and safety.

3. Speed shouldn’t come at the cost of safety

Provisioning connectivity in seconds is transformative (but only if it’s safe by default).

That meant building the platform to actively slow things down when it should. In practice, this looks like a system that:

• Rejects unsafe or incomplete requests
• Prompts for clarification when intent is unclear
• Respects region, product, and policy constraints
• Ensures the user has the authority to create or modify services

The result is a system that moves quickly when it can—and deliberately when it must. Instant doesn’t mean ungoverned.

4. AI changes who can provision, not just how fast it happens

One of the more surprising insights was that AI interfaces don’t just make experts faster—they also expand who can meaningfully interact with the network.

A cloud architect who isn’t a deep networking specialist can now express a requirement in plain language:

“Connect my AWS environment in LAX1 to Azure in NYC2 with 100 Gbps.”

The system handles the translation, validation, and execution. This reduces dependency bottlenecks, shortens feedback loops, and allows specialists to focus on higher-order design decisions instead of repetitive task handling.

Importantly, this isn’t about replacing network engineers. It’s about removing friction so their expertise is applied where it matters most.

5. The biggest breakthroughs weren’t technical—they were experiential

The real transformation wasn’t in building a provisioning engine (that already existed). It was in changing the entry point to the network: From portals to language.

That shift changes the entire relationship between users and their infrastructure.

Engineers can test ideas immediately. Teams can iterate without waiting for workflow cycles. Businesses can scale without friction at the request layer.

AI didn’t replace networking. It removed the unnecessary barriers around it.

The result: a new way to interact with the network

By the time we finished the early architecture of the platform, it was clear we weren’t just creating a feature. We were creating a new category:

AI-native networking—where intent becomes infrastructure in seconds.

And this is just the beginning. As models improve, validation layers expand, and provisioning workflows evolve, the possibilities extend far beyond instant services. We’re entering a world where networks will:

• Anticipate needs
• Recommend optimal architectures
• Detect anomalies before impact
• Help engineers make smarter decisions at scale

We built this platform not to remove humans from networking, but to return the network to what it was always meant to be: a powerful tool in the hands of the people who understand it best.

Test out PacketFabric.ai for yourself today.

The post What We Learned While Building an AI-Native Networking Platform appeared first on PacketFabric.

We talk to IT leaders and network architects every day. Whether they’re managing cloud migrations, spinning up AI infrastructure, or just trying to get support tickets resolved, the pain points are surprisingly consistent.

Here are the top five challenges we hear from customers about legacy network providers—and how Network-as-a-Service (NaaS) can help you build something better.

1. “Everything takes too long.”

What we hear:
“Provisioning new services or making changes takes forever. Even simple requests feel like pulling teeth.”

Why it happens:
Traditional telecom still runs on manual provisioning and long lead times. Each change is a ticket, a queue, a delay.

How NaaS helps:
Modern NaaS platforms give you self-service control and instant provisioning. Need to spin up a secure cloud connection? Scale bandwidth for a big migration? With NaaS, it’s a matter of minutes—not months. That agility helps teams move at the speed of their business. See how we spin up a backbone connection in less than a minute.

2. “We’re worried about downtime—and performance.”

What we hear:
“The infrastructure feels outdated. We’re constantly hoping nothing breaks during a big app launch or data transfer.”

Why it happens:
Legacy networks often rely on aging physical hardware and static configurations that struggle to support today’s real-time workloads.

How NaaS helps:
NaaS is built on modern, cloud-native architectures—typically with fully redundant backbones and intelligent routing. That means more uptime, lower latency, and better performance for demanding apps like AI/ML, video, and large-scale data workflows.

3. “Managing our network is complex and expensive.”

What we hear:
“We’re spending a lot—but we’re not even sure on what. The billing is confusing, and managing services takes too much time.”

Why it happens:
Legacy models often bundle hidden fees, overprovisioned capacity, and opaque billing structures. And every small change can require manual intervention.

How NaaS helps:
NaaS simplifies both the technical complexity and financial unpredictability. You get:

• Transparent, consumption-based pricing
• Real-time visibility and management
• Automation that replaces ticket queues

The result? A network that’s easier to run and easier to justify on a budget sheet.

4. “Support is reactive, not proactive.”

What we hear:
“We’re always chasing them. When something breaks, it’s on us to figure it out first—and escalate.”

Why it happens:
Support at many legacy providers is structured around tiers and tickets, not outcomes. And often, they’re managing a patchwork of old systems behind the scenes.

How NaaS helps:
NaaS platforms are designed for automation-first support—meaning fewer issues to begin with. And when you do need help, you’re working with a team that’s focused on resolution, not red tape.

Many customers also love the self-service aspect: make changes, view metrics, or troubleshoot instantly, without waiting on anyone.

5. “Our network is holding back our cloud and AI projects.”

What we hear:
“We’re trying to innovate, but our network can’t keep up with cloud adoption or data-intensive workloads.”

Why it happens:
Legacy networking models weren’t built for multi-cloud, hybrid architectures, or the kind of east-west traffic that AI workloads demand.

How NaaS helps:
NaaS is inherently cloud-native. You can instantly connect to major cloud providers (like AWS, Azure, GCP, Oracle) with dedicated, high-bandwidth circuits—perfect for training models, running analytics, or scaling across clouds. It’s not just about connectivity; it’s about enabling innovation.

The Takeaway: Your Network Should Be a Launchpad, Not a Limiter

We believe your network should never slow you down. If these frustrations sound familiar, you’re not alone—but you do have better options.

Network-as-a-Service provides a more agile, transparent, and resilient way to manage enterprise connectivity. And for many of the IT leaders we speak with, it’s been the difference between firefighting and forward-thinking.

Ready to provision a real connection in minutes?
Explore our platform and start building now: Launch the portal

Want a quick look before diving in?
Watch a 2-minute demo to see how easy it is to get started: Watch the demo

The post What Our Customers Say About Legacy Networks—and Why They Switched appeared first on PacketFabric.

It’s a model that belongs to the past.

The future? Instant provisioning and on-demand control—enabled by Network as a Service (NaaS).

The Traditional Telco Bottleneck

Legacy telecom provisioning was designed for an era when infrastructure was static and change was slow. Ordering a new circuit involved multiple teams, lengthy installations, and time-consuming coordination. Bandwidth was fixed, and scaling required additional contracts and often, more waiting.

But today’s businesses are anything but static. Cloud-first architectures, distributed teams, and continuous delivery pipelines demand agility and responsiveness. When network provisioning becomes a roadblock, digital transformation slows down—and opportunity is lost.

How NaaS Changes the Game

PacketFabric’s NaaS platform makes provisioning a new circuit as simple as deploying a virtual machine. With a self-service portal and full automation, you can build and scale your network in minutes, not months.

Key benefits include:

• Instant provisioning of ports, circuits, and cloud connectivity
• Real-time scalability, so your network evolves with your needs
• Self-service control without tickets or manual processes
• Transparent pricing, with month-to-month, 12, 24, and 36-month terms available

Instead of relying on static infrastructure, you gain a dynamic network that adapts as your business grows.

From Delay to Delivery in Minutes

One PacketFabric customer needed to connect new regions to their cloud environment in less than 48 hours. With a traditional carrier, this would’ve taken 30+ days. Using PacketFabric, they created and tested the connection the same afternoon, no red tape, no delay.

That kind of speed isn’t just convenient—it’s transformative. It allows teams to respond to business needs instantly, accelerate cloud initiatives, and reduce time-to-market for critical services.

The Business Case for Instant Networking

In 2025, your network should never be the thing that holds you back. Whether you’re expanding into new markets, connecting to additional cloud providers, or rearchitecting for scale, the ability to provision quickly and flexibly is a key competitive differentiator.

With PacketFabric, you can:

• Deploy secure, private connectivity on demand
• Eliminate provisioning delays and complexity
• Only pay for what you provision, with no hidden costs

Ready to build your network at cloud speed? Start provisioning in minutes.

The post Why Waiting for Circuits Is a Thing of the Past appeared first on PacketFabric.

The Challenge of Egress Costs

Cloud service providers often impose charges for egress traffic, which can vary based on the provider, destination, and volume of data transferred. These costs can be unpredictable and challenging to budget for, especially when dealing with large-scale data operations. For instance, transferring 2 petabytes of data (1PB ingress and 1PB egress) could amount to over $90,000 per month, equating to $1.08 million annually. ​

Strategies to Reduce Egress Costs

To mitigate egress expenses, businesses can adopt several strategies:

1. Use Virtual Cloud Routers

Implementing Virtual Cloud Routers allows for more efficient data routing, reducing the need for data to traverse the public internet. This approach not only enhances security but also lowers egress charges by minimizing data transfer over public networks. For example, we helped our customer reduce their NAT costs by $310,000 per month by optimizing their network design to route data through a virtual cloud router instead of using traditional NAT gateways. 

2. Leverage Private Connectivity Solutions

Establishing private, high-speed connections between cloud environments can significantly cut egress costs. Solutions like PacketFabric’s Quick Connect enable secure, direct connections without the need for public internet traversal, thereby reducing egress fees. This method offers predictable pricing and enhanced performance, making it a cost-effective alternative to traditional data transfer methods

3. Optimize Multi-Cloud Architectures

Designing a well-structured multi-cloud network can lead to cost savings by strategically routing data to minimize egress charges. Utilizing a network fabric simplifies multi-cloud connectivity, reduces operational expenses, and can lower data transfer fees by over 60% compared to internet egress. This approach ensures that data flows efficiently between clouds without incurring unnecessary costs. 

4. Rethink Network Address Translation (NAT) Usage

NAT gateways can become costly when handling large volumes of data due to charges applied per gigabyte processed. Exploring alternatives, such as using NAT instances or high-bandwidth virtual cloud routers with NAT capabilities, can lead to significant savings. Read our blog on the advantages and disadvantages of NAT Gateways here.

Start Cutting Egress Costs Today

Egress costs are a significant consideration in cloud networking expenses, but with strategic planning and the adoption of advanced networking solutions, businesses can effectively reduce these costs. By implementing Virtual Cloud Routers, leveraging private connectivity, optimizing multi-cloud architectures, and reevaluating NAT usage, organizations can achieve more predictable and lower data transfer expenses, contributing to a more efficient and cost-effective cloud strategy.

Ready to start saving? Explore our self-service portal.

The post 4 Ways to Lower Egress Costs and Optimize Cloud Data Transfer appeared first on PacketFabric.

Whether you’re modernizing legacy infrastructure or building out a multi-cloud strategy, staying ahead of these trends is critical to staying competitive.

Here are the key trends that will define networking in 2025 and beyond—and what they mean for your business.

1. Network-as-a-Service (NaaS) Becomes the New Standard

NaaS is transforming the way enterprises consume and manage connectivity. Instead of relying on static, hardware-defined infrastructure, organizations are shifting toward flexible, software-driven models that offer on-demand provisioning, usage-based billing, and seamless scalability.

Why it matters:
NaaS reduces CapEx, accelerates deployments, and allows teams to focus on business outcomes instead of infrastructure management.

2. The Rise of Software-Defined Networking (SDN) and Network Function Virtualization (NFV)

SDN and NFV continue to gain traction as organizations prioritize agility, automation, and centralized control. SDN decouples the control plane from the data plane, while NFV replaces dedicated hardware with virtualized network functions.

Why it matters:
These technologies reduce operational complexity, enable faster service rollout, and allow for dynamic policy enforcement across environments.

3. Network Automation Becomes Business-Critical

Automation is no longer a nice-to-have—it’s essential. AI- and ML-driven tools are now managing everything from traffic optimization to anomaly detection and remediation, reducing human error and improving network reliability.

Why it matters:
With automation, IT teams can focus on strategic initiatives instead of firefighting, while reducing downtime and speeding up incident response.

4. AI and Machine Learning Revolutionize Network Management

AI is driving the next generation of “self-healing” networks, with intelligent systems predicting failures, optimizing traffic patterns, and making real-time decisions.

Why it matters:
Predictive analytics, smart routing, and intent-based networking are enabling better performance, fewer outages, and lower operational costs.

5. Edge Computing and Decentralized Architectures Go Mainstream

As IoT and real-time applications proliferate, more computation is happening closer to the source—at the edge. Edge computing reduces latency and eases bandwidth constraints by minimizing round-trip data transfer to centralized clouds.

Why it matters:
From autonomous vehicles to remote healthcare, low-latency performance is no longer optional. Edge-ready networks will be critical to innovation.

6. Zero Trust Becomes the Default Security Model

The perimeter-based security model is obsolete. In 2025, Zero Trust is the rule, not the exception. This model verifies every user and device—every time—regardless of where they’re accessing the network from.

Why it matters:
With distributed teams, cloud adoption, and growing threat vectors, enforcing strict identity and access controls is foundational to any security strategy.

7. Quantum Networking Enters Early-Stage Adoption

While still in its infancy, quantum networking is beginning to make its mark—particularly in research and high-security sectors. With the potential for unbreakable encryption and massive speed gains, early use cases are already emerging.

Why it matters:
Organizations that rely on ultra-secure or high-throughput communication should start paying attention to the quantum roadmap now.

8. Smart, Scalable Infrastructure Supports Explosive IoT Growth

IoT is driving exponential increases in data volume and connectivity requirements. In response, networks are becoming more intelligent and scalable, leveraging automation and analytics to manage device sprawl and optimize performance.

Why it matters:
Enterprises must plan for rapid growth in endpoints—and ensure their network can support that scale without compromising performance or security.

Looking Ahead

The common thread across all these trends? Flexibility, automation, and intelligence.

Legacy networks weren’t built for the speed and complexity of today’s business environment. As workloads move to the cloud, users go remote, and devices multiply, IT teams need networks that adapt in real time.

That’s why the shift to modern, software-defined, service-based infrastructure isn’t just a trend—it’s a necessity.

Build for What’s Next

PacketFabric is built for this future. Our platform brings together instant provisioning, private connectivity, and fully automated control—so you can move fast, stay secure, and scale on your terms.

Ready to modernize your network for 2025 and beyond? Start building now.

The post 8 Trends That Will Define Networking in 2025 and Beyond appeared first on PacketFabric.

As part of our ongoing efforts to enhance operational efficiency, we recently made some strategic changes to our team. These decisions, while difficult to make, were important in order to optimize our operations and prepare us to continue to deliver great value to our customers and their businesses in the future.

The PacketFabric Promise

While some of our team has changed, PacketFabric remains strong and resilient. We continue to innovate Network as a Service with leading-edge solutions and robust network infrastructure, providing unparalleled network connectivity to empower users and businesses worldwide. Our focus as a company is unchanged: to support our customers with the highest standards of service. 

PacketFabric is committed to outperforming the market for Network as a Service, enabling customers to:

• Configure on-demand services that can be scaled in minutes through our self-service portal
• Save 50-60% (or more) on egress fees when connecting to public cloud
• Transfer data at scale, with the only 100G/multi-100G enabled solution on the market

Looking Forward

If you are a current PacketFabric customer or partner and you have any questions or concerns, please don’t hesitate to reach out to your account team.

We look forward to continuing to serve your network needs, and we’re excited for the shared successes yet to come.

The post Team Updates and the Future of PacketFabric appeared first on PacketFabric.

According to the Uptime Institute’s 2024 Outage Analysis, between 10 and 20 “high-profile IT outages or data center events” occur every year. The study revealed that while power is the main cause of data center outages, network issues are the leading cause of outages across all IT services. These outages make headlines and have serious consequences, disrupting business for customers and damaging company reputations.

More than half of respondents said their most recent major outage cost them over $100,000, and 16% reported that it cost more than $1 million. Here are some key takeaways from the Uptime Institute’s annual report and what you can do to mitigate the risk of a high-profile outage on your network. 

Leading causes of network outages

The leading causes of network-related outages typically fall under one (or more) of these categories:

• Design & Configuration: Gaps in design, incorrect IP addressing, routing table errors, and lack of redundancy or failover methods can lead to network vulnerabilities that result in downtime.
• Hardware: Problems with equipment such as routers, firewalls, or switches, as well as cabling errors and cooling system malfunctions, can disrupt network communications. Power outages, especially with the increasing variability of renewable power grids globally, can be a key factor in hardware-related outages.
• Capacity: The increased demand for connectivity and bandwidth can strain networks and legacy infrastructure, leading to slowdowns and downtime. Insufficient IP addresses, processing power, or memory also pose a threat.
• Software: Glitches in code can compromise network devices or services, leading to unexpected crashes and memory leaks. Software issues can also make networks vulnerable to cyberattacks.
• Environmental Threats: As we saw in the major bank outages late last year, issues such as data center overheating or humidity control failures can quickly damage network equipment. With extreme weather events becoming more frequent worldwide, environmental factors are increasingly challenging to manage.

To err is human

According to the Uptime Institute’s study, direct and indirect human error contributes to approximately 66% to 80% of all downtime incidents. This can be attributed to factors such as the absence of preventive procedures or resources, inadequate training, worker fatigue, or the growing complexity of the technology being used. Examples of human error include employees inadvertently granting attackers access to company data or systems or failing to adhere to proper procedures during maintenance or a routine network upgrade.

Software-defined networking can help mitigate outage risk

There’s no easy button to make a network less prone to outages, but using Network-as-a-Service (NaaS) software platforms can help make it easier to build a more robust, diverse, and resilient network.

• Design & Configuration: By using the right NaaS platform, you can turn up redundant connections to sites quickly and easily online. In my blog on upgrading network backbones, I told the story of a customer that waited 12 months for diverse services to be installed by their carrier. With a software-defined network operator, you can design your network for redundancy and configure the connectivity you need immediately. If your ports are in place with their cross-connects, services can be provisioned and live within minutes, not months. 
• Hardware: With a NaaS platform, you don’t have to manage routers, switches, or cables. The more hardware you have to manage, the higher the probability that network-impacting human errors can occur.
• Capacity: On a NaaS platform, you can turn up or upgrade private connectivity easily, with flexible and high-bandwidth options, and avoid the bandwidth-throttling that can happen when you connect over the public Internet or use dedicated Internet access from your carrier.
• Software: With NaaS, you don’t have to deal with potential software issues on customer premises equipment. Your network service operator can direct your traffic to alternate paths to avoid downtime.

In short, managing all the things that can go wrong with your network equipment and your network teams can add up to a lot of work. One of the many benefits of using NaaS software platforms is that much of that work can be offloaded to a network operator with service-level agreements for uptime.

Have you experienced high-profile network outages?

Mitigating the risk of serious outages is at or near the top of every network team’s priorities. By increasing the usage of NaaS software platforms, you can quickly and easily design and deploy flexible, resilient networks that can be configured for high availability for mission-critical applications of all types.

Chat with one of our sales engineers and let us know how we can help you.

The post Takeaways From The Uptime Institute’s Annual Outage Analysis Report appeared first on PacketFabric.

Customers can deploy a variety of ways to connect their WAN within their topologies depending on their business objectives. Just as there’s no superior WAN topology, no one connectivity method is dominant over any other. Each has its own features, advantages, and disadvantages. 

In this blog, I’ll run through the common WAN topologies and ways to connect your WAN, and use customer use cases to illustrate why companies choose one or a set of connectivity methods over others.  

Common WAN topologies

Point-to-Point WAN

Locations and devices on a point-to-point WAN are connected using a dedicated circuit at layer 2. If you have Site A in one city and Site B in another, the network diagram might look like this, courtesy of Cisco Press:

Use Cases

We have many different types of customers who use a P2P WAN topology. 

In the case of a leading data warehousing company, it uses six different data center operators across 11 locations in the US and Europe. The company uses PacketFabric to connect these data centers with long-haul EPL (P2P) circuits, provisioned virtually on our portal. 

Examples of connections include: 

• a 100G long-haul circuit from a data center in Salt Lake City to a data center in Denver to support their cloud storage deployments. 
• Redundant 100G long-haul circuits from Ashburn, Virginia to Chicago, Illinois
• Redundant 10G virtual circuits between data centers in London and Frankfurt 

Another example was highlighted on our blog. A visual effects studio with on-prem infrastructure in Oregon used a 100G dedicated cloud connection from PacketFabric to connect to Google Cloud in Oregon in order to lower latency.

Point to Multi-point WAN

Point to Multi-point (P2MP) WAN is also known as a hub-and-spoke or Tree WAN design. Sites are connected to a central site or hub so a simple version of the network might look like this, courtesy of CCNA:

Use Cases

Often there are elements of one WAN topology in another. In the case of the data warehousing customer, within their overall P2P WAN topology, they used P2MP as well, connecting data centers in Boston and Chicago with redundancy to their Ashburn data center, without connecting the Boston and Chicago data centers together. In this case, the Ashburn data center becomes the hub.

Another example of a P2MP WAN topology is when traffic from multiple sites is aggregated at a PacketFabric Virtual Cloud Router. The Virtual Cloud Router is the hub, while the data centers and cloud deployments end up being spokes in the network.

Mesh WAN

Also known as a Star WAN topology, a meshed WAN connects numerous sites not just one to the other to the next, but also together. Here’s what a full mesh WAN and a partial meshed WAN might look like, courtesy of TechTarget.

You can see in the full mesh example, the network connections resemble a star.

Use Cases

A full mesh six-site WAN topology was used as an example in our blog “Three Reasons to Upgrade Your Network Backbone.” In that case, six data centers were connected with virtual circuits to a Virtual Cloud Router, creating a “mesh” as every data center could conceivably pass traffic to any other in an any-to-any software-defined network (SDN). 

The blog also features a diagram of how that full mesh WAN was designed with nailed-up connections as well. To build a full meshed WAN with P2P connections, you have to provision many more connections. By using a Virtual Cloud Router as a hub, you can reduce the number of connections you need, making your network more efficient both from a data transfer and cost perspective.

MPLS

Multi-Protocol Label Switching (MPLS) is a technology that uses routers to forward data across the network. The routers use labels applied to data packets, which helps the network identify the best path for the packet to take to its destination. 

An MPLS topology might look like this:

MPLS was originally developed in 1990s and is now considered an aging technology. But many companies still prefer the speed and reliability of an MPLS network. While an MPLS network is typically performant and reliable, it has a high-per-megabit cost and is sold by traditional telcos. It also involves purchasing and managing Customer Premises Equipment (CPE).

As you can tell from the diagram above, an MPLS network can also be more complex to manage than other WAN topologies.

Use Cases

We’ve worked with companies to simplify their WAN, and featured one of these use cases in this blog about a fintech’s multi-cloud network. Many companies are moving away from MPLS to a more modern WAN technology, one that’s becomes an oft-used analyst buzzword in this decade.

SD-WAN

Software-Defined Wide Area Networking is a network where SD-WAN devices are deployed to connect branch offices, and network teams can orchestrate and monitor these devices with software. SD-WAN often involves the deployment of firewalls and other devices to secure company traffic. In most cases, SD-WAN devices rely on internet connectivity, which can make network performance unreliable. 

SD-WAN technology came to the forefront when office workers started using social media in the workplace. Traffic was so heavy within private corporate networks that companies needed a solution that enabled workers to use less expensive internet bandwidth while maintaining network security at the branch-office level.

Here’s a video that explains how SD-WAN changes traditional WAN topologies:

Use Cases

One of the main disadvantages of SD-WAN is that it uses low-cost internet connectivity instead of more reliable MPLS connectivity. SD-WAN enables companies to better manage, orchestrate, and secure network traffic, but often at the cost of application performance.

We’ve spoken to customers who have deployed firewalls at multiple branch offices only to become frustrated with frequent outages. We’ve designed alternate WAN solutions in which SD-WAN traffic gets aggregated on Virtual Cloud Routers. Traffic is then brought onto PacketFabric’s private network, where bandwidth is less likely to be throttled and security is stronger than the public internet.

Common WAN Connectivity Methods

Now that we’ve gone over different WAN topologies, let’s look at how sites can be connected within these network designs. As I mentioned above, choosing WAN connectivity methods often boils down to whether or not you can put up with the unreliable network performance and untrustworthy security aspects of public internet connectivity. 

Broadband or T1 (internet)

Broadband, such as DSL, is equivalent to standard internet connectivity. It’s the easiest, cheapest way to connect sites on your WAN. T1 is another internet option that’s typically delivered over copper  wires. It’s a stronger internet connection (1.544 Mbps), but still has the security and bandwidth limitations of broadband.

For applications that don’t necessarily require optimal user experience, broadband or T1 connectivity may be the most cost-effective options.

Ethernet

There are several types of Ethernet connections. Ethernet Private Lines (EPL) are used for point-to-point connections, while Ethernet Virtual Private Lines (EVPL) can be used for point-to-multipoint connections. Bandwidths start at 1G, so from a speed perspective, they’re a step up from broadband or T1s. They’re also private lines so they’re more secure than internet connectivity.

Both are layer 2 connections, meaning there’s a physical connection and a software interface that allows you to control and see where your data goes. The virtual interface enables you to turn up EPLs and EVPLs via software-defined networking platforms like the PacketFabric portal. 

On our private, carrier-grade network, for example, if there’s an issue with the Ethernet line, data can be routed to an alternate path without service interruption. The customer does not have to deal with physical infrastructure. 

Use cases include large-scale data migrations or file transfer, data center interconnectivity, and disaster recovery.

Wavelengths

Wavelengths transmit data with light over a fiber optic cable. Most carriers offer waves with bandwidths up to 100G, and some offer even higher bandwidths. 

Waves are layer 1 connections, meaning they’re physical and static–data moves unidirectionally from one node to another. Waves have to be ordered and installed by your carriers, and in many cases, installation can take weeks or even months, particularly if you’re using them for long-haul transit. 

If there are issues with your waves, like a gopher chews through your cable, it has to be physically repaired, so designing your network for redundancy is key.We’ve seen that companies in industries with more stringent compliance and regulatory requirements tend to prefer procuring physical connections prefer wavelength connectivity.

MPLS circuits

Carriers offer several types of MPLS circuits, including layer 2 point-to-point and VPN. These are typically either internet or Ethernet connections to MPLS routers. These connections also tend to be pricier as they’re part of carrier-managed MPLS offerings.

MPLS has been a popular technology for decades, particularly for companies that need to connect numerous branch office locations to data centers.

Summary

Here is a table of the different ways to connect your WAN ranked by business criteria (1 being best and 4 being worst). Choose the most important ones and rank them to help you make decisions for your use case.

Using Software-Defined Connectivity

No matter what your WAN topology is, PacketFabric offers almost any WAN connectivity option on our portal. You can connect WAN sites using dedicated internet access and Ethernet (both EPL and EVPL) connectivity as a virtual alternative to physical wavelengths, all at bandwidths up to 100G. 

With almost every company using one or more cloud service providers, hybrid and multi-cloud connectivity are also key components of a typical enterprise’s WAN. We covered ways to connect to multi-cloud in this blog.

Our sales engineers will also help you design a network based on your business objectives, which could be maximum resilience and redundancy or optimal cost efficiency. 

Reach out to one of our sales engineers if you’re looking to modernize your WAN.

The post Ways to Connect Your WAN: Topologies, Connectivity Methods, and Use Cases appeared first on PacketFabric.

• Data migrations
• Disaster recovery
• Data sovereignty 
• Application development and testing

Common ways to connect multi-cloud to enable data transfers between virtual private clouds (VPCs) include:

• IPsec VPN over the public internet
• Managed VPN
• Partner interconnect
• Dedicated cloud connection
• Virtual Cloud Router

In this blog, we’ll provide the pros and cons of each method to connect multi-cloud along with reference diagrams to help you choose the best one for your needs. 

IPsec VPN over the public internet

By connecting VPCs with IPsec VPN tunnels over the public internet, data passes back and forth from one cloud to another via public IP addresses.

Here’s a diagram of a VPN connecting AWS and Google Cloud:

Pros

VPNs are easy to implement: Cloud providers allow you to create a VPN connection from their console. All you have to do is create a route for ingress traffic, configure your VM to send and receive traffic, and test. 

Cons

Network performance can be unpredictable: Data will be traversing the public internet, which is best-effort by nature. You’ll have to manage the routing or load balancing to avoid bandwidth throttling. For workloads that require more reliable application performance, you’ll likely need connections that are more stable and have higher bandwidth.

Security vulnerability: VPNs are more vulnerable to Border Gateway Protocol (BGP) hijacking than a dedicated connection on a private network.

Data transfer costs: You’re also likely subject to higher egress fees, though the leading cloud providers are starting to waive them under some circumstances.

Best For

Applications that are not mission- or business-critical: Examples of applications for which network performance can be best-effort include cloud storage and interoffice email and messaging.

Managed VPN

An alternative to a simple VPN connection is to use the managed VPN service of a cloud service provider. This option encrypts your traffic and lets you transfer data between private IP addresses. Each of the hyperscalers offer their own managed VPN services (e.g. AWS Site-to-Site VPN, Azure VPN Gateway, and Google HA VPN).

This video shows you how to configure a managed VPN from Google Cloud for high availability.

Pros

Improved security: A managed VPN adds encryption and uses private IPs.

Cons

Network performance can be unpredictable: Data moving through a managed VPN still goes over the public internet. For higher bandwidth use cases, you can deploy multiple VPN tunnels to improve throughput, but that means you’ll have to spend time managing them to make sure they don’t break.

Best For

Applications that deal with sensitive data: Examples include the cloud storage of patient records for a healthcare organization or historical employee data for a conglomerate.

Partner interconnect

A partner interconnect, also known as a hosted cloud connection, is a fast way to connect your multi-cloud infrastructure via a CSP’s private, direct connection service (e.g. AWS Direct Connect, Azure ExpressRoute, and Google Cloud Dedicated Interconnect).

A partner interconnect uses a virtual circuit to a port that is already connected to a CSP’s edge device. This port is shared, meaning that others might be using the circuit at the same time. 

Pros

Fast provisioning: A partner interconnect or hosted cloud connection can be provisioned virtually in less than ten minutes on a software-defined networking portal like PacketFabric’s.

Greater reliability: Unlike VPNs, a partner interconnect typically comes with Service Level Agreements (SLAs) when used with redundancy. 

Stronger security: Connecting multi-cloud via a hybrid multi-cloud network design enables security teams to run their data security policies at their on-prem data centers. 

Cons

Increased latency from backhauling traffic: Because the port is shared with other companies, a partner interconnect is best used for low-bandwidth (sub-10G) use cases. Increased latency may also be an issue as transferring data out of one cloud back to an on-prem data center and then out to a second cloud increases the distance data has to travel. This practice is called hairpinning or traffic backhauling. 

Best For

Mission- or business-critical applications: Connecting multi-cloud with partner interconnects works well for applications where network performance and security are high priorities. Examples include the production environment of a banking app or connectivity to point-of-sale systems. 

Dedicated cloud connections

A dedicated cloud connection is a port provisioned exclusively for your use. Once provisioned, a cross connect must be installed between your dedicated port and a CSP’s edge device in a data center with a cloud on-ramp. The following diagram shows you how a dedicated cloud connection works on PacketFabric’s carrier-grade network.

Pros

Optimal network performance: A dedicated cloud connection is designed for network teams that have important cloud workloads that require optimal application performance all the time and therefore need high-bandwidth, dedicated connections. 

Cons

Increased provisioning time: Provisioning of a dedicated cloud connection can take a couple of days because a cross connect has to be installed between a port and a CSP edge device within a data center with a cloud on-ramp. While installation time for a dedicated cloud connection is longer than setting up a VPN connection or a partner interconnect, it’s still typically much shorter than the weeks or months it might take a telco to install a private line. 

More expensive: A dedicated cloud connection is also more costly than a partner interconnect because the port is exclusive and the cost of the cross connect must be factored in.

Best For

Mission- or business-critical applications with stringent security and compliance requirements: Examples include financial institutions, state and local government, or medical organizations.

Virtual Cloud Routers

Using Virtual Cloud Routers can be a way to connect multi-cloud environments together while reducing the number of cloud connections you need. Virtual Cloud Routers provide private connectivity at layer 2 and layer 3.

Here’s an example of PacketFabric Virtual Cloud Routers connecting four different CSPs in four different regions in a Layer 3 Virtual Connection Mesh.

Pros

No hardware: There’s no customer physical equipment involved because Virtual Cloud Router instances are virtual. 

Lower latency: When partner interconnect or dedicated cloud connections are used to connect your cloud regions to a Virtual Cloud Router, the traffic is directed over a private and secure network instead of the best-effort public internet. 

High bandwidth: High-capacity virtual cloud routers like PacketFabric’s 100G Virtual Cloud Router can enable high-bandwidth data transfer between clouds, speeding up data migrations and optimizing network performance. 

Cost-effective NAT functionality: Virtual Cloud Routers can also serve as Network Address Translation (NAT) devices, giving customers an alternative to cloud NAT gateways, a managed service that can be very expensive when transferring large amounts of data because the pricing is metered by bandwidth and time used.

Cons

Less control: Virtual Cloud Routers are mostly hands-off solutions for the customer. Some customers prefer to manage their own equipment, perhaps for compliance reasons. Some customers may want to backhaul traffic to on-premises infrastructure, where they can apply security policies.

Best For

Multi-cloud applications: Virtual Cloud Routers are best for application workloads running in different clouds that need to speak with each other.

Need help interconnecting multi-cloud?

With many companies using three or more cloud service providers and so many options for multi-cloud interconnection, multi-cloud network connectivity can get complex quickly. 

We’ve helped customers redesign their cloud networks to be more performant, cost-efficient, and easier to manage. If you’d like to talk to one of our sales engineers or get a product demo, don’t hesitate to reach out.

The post Ways to Connect Multi-cloud: Pros, Cons, and Diagrams appeared first on PacketFabric.

Private subnets are often the default option in how-to guides to set up cloud services. One, private subnets are less vulnerable to attacks. Two, there are limits to how many public IPs you can get on an account. 

Once you choose to have a private subnet, you’ll have to decide whether you want to NAT your traffic in order for your virtual machines (VMs) to communicate with external applications over the public internet. You want to be able to protect your internal endpoints, but you also want your applications to poll third-party APIs and run software updates. 

One of the easiest ways to NAT your traffic is to use the CSP’s NAT gateway. In this blog, we’ll break down the advantages and disadvantages of using this fully managed service so you can decide whether a NAT gateway is appropriate for your use cases.   

Advantages

Scalability

Cloud NAT gateways don’t use proxy devices, which can end up being a choke point for traffic. In the case of Google Cloud NAT, for example, each virtual instance is given a unique pool of NAT IP addresses and port ranges, enabling greater scalability and giving each instance as much bandwidth as those on a public subnet. For AWS NAT gateway, they require Elastic IPs (EIPs), which are static and public IPv4 addresses, to enable NAT.

Cuts operational labor

If you had to set up NAT yourself with your own devices, here are just a few things you’d have to do:

• Reserve a pool of static IP address
• Create compute instance groups
• Set up health checks to monitor those instances
• Create default routes
• Set up and maintain a NAT proxy appliance over time.

With a fully managed NAT gateway, many of those tasks are taken care of for you.

Configurability via Software-Defined Networking

When you use a NAT gateway, it’s configurable via a software-defined network interface. In Google Cloud, you can set up Cloud NAT in the regions your VMs are in, set up a Virtual Cloud Router, and choose the NAT IP addresses, which can be automatically allocated or you can bring your own static IPs in. 

In AWS, you can configure an internet gateway, add a NAT gateway as a public subnet, and configure your routing tables in your private subnets to forward internet traffic through your NAT gateway.

Disadvantages

Doesn’t do inbound NAT

Cloud NAT services are designed to secure your internal endpoints and improve your security posture, but there may be times when you want to configure ingress NAT, particularly when your applications in the private subnet of one cloud provider need to communicate with applications in another cloud provider’s VPC and vice versa.

Metered pricing

The most common complaint about NAT gateways is the pricing model. The CSPs charge by the hour for device usage, and then they charge data transfer fees of five cents a GB. There are no volume discounts for escalating traffic levels. There’s also no free tier for lower levels of traffic.

So that means that if you NAT 1GB of traffic, it’s five cents per GB, and if you NAT petabytes of data, it’s still five cents. At higher levels of data transfer, your NAT gateway bill can get expensive fast.

Not appropriate for every cloud use case

As mentioned above, using private subnets is often a default for cloud developers because private means more secure, and if you go private, you’ll probably want to consider NAT. But not every cloud use case requires NAT and therefore, not all of your traffic needs to go through a NAT gateway even if you choose to use one. 

There are other ways to achieve NAT, including setting up your own bastion host or adding VPC endpoints. For applications that are less mission- or business-critical, using public subnets might be the way to go.

Are you looking for an alternative to NAT gateways?

We covered alternatives to NAT gateways, including using PacketFabric Virtual Cloud Router for NAT functions, in a previous blog. If you’re wondering whether a NAT gateway is right for your use case, we’re happy to talk to you about it. Reach out to one of our sales engineers.

The post NAT Gateways: Advantages and Disadvantages appeared first on PacketFabric.