Over the past few years most organizations have significantly increased their reliance on the Internet, primarily due to the outsourcing of utility applications like email, unified communications, ERP, CRM, etc. to SaaS providers. Cloud-based applications provide IT organizations with an agile and cost effective means for expanding the range of services they provide and delivering new productivity tools requested by teams, departments or lines of business.
Despite this growing adoption of cloud services, many enterprises have resisted connecting their remote offices directly to application providers over the public Internet. This is due to the fact that direct access at every branch introduces compliance issues. The only way to mitigate these is by creating extensive security policies at each location. Imagine having 3,000 sites with each requiring its own set of policies that need to be set-up and maintained. This is the definition of a management nightmare.
In addition to adopting SaaS applications, enterprises are now beginning to use PaaS and IaaS offerings from AWS, Microsoft Azure, etc. to lease cloud-based storage, physical and virtual server instances, and in some cases load balancing resources.
Given these shifts, there is a general consensus that WAN connectivity must employ alternate transports to MPLS for the following reasons.
Cost: MPLS circuits have not kept up with the speed and cost of public Internet based circuits. For example, a typical on net 10 Mbs MPLS circuit costs approximately $500-$700 per month and an off net is approximately $800-$1,000 per month. Meanwhile, a 100 Mbs broadband circuit ranges from $189 to $249 per month.
Agility: Provisioning an MPLS circuit can take anywhere from three weeks to two months depending on whether the carrier has a footprint in the location or if they need to lease a connection from a local exchange carrier (LEC).
Capacity: Due to the increased use of multimedia applications, WAN bandwidth demands have increased anywhere from 25-30 percent per year while enterprise IT budgets have remained flat.
Cloud User Experience: Most enterprises currently backhaul all Internet bound traffic to the corporate data center, which sometimes is not even located on the same coast as the user or the SaaS provider. This negatively impacts the cloud user experience.
Due to these factors, enterprises have started using Internet based connections to augment their MPLS circuits. In most cases they try to create an overlay network with a centralized Internet exit, in some industries like retail, enterprises do provide local Internet exit. However, due to the lack of security on public connections, these cannot be used as a local exit in regulated industries like financial services and healthcare due to compliance reasons.
In order to provide branch locations with local Internet access to a SaaS provider (for taking the best performing path), these companies must vet that the cloud service provider can meet the compliance requirements they are subject to.
Consider this example from the financial services industry where a branch can interact with three lines of business:
This doesn’t include a fourth category: partners. These can include HVAC vendors, video surveillance partners, etc. and even guest Wi-Fi.
Since most cloud service providers are moving to metropolitan colocation (colo) facilities, establishing peering connections to provide a better user experience by setting up mini-DMZs makes sense. To avoid compliance violations, using regional colo facilities is a good option.
In this scenario, the retail segment can use the regional colo for local Internet if they need to access the YouTube channel for training. Security could be provided by a regional MSSP (managed service security provider). Access to applications like Microsoft Office 365 or Salesforce.com would be blocked since retail employees are not permitted to upload data to SaaS providers.
Meanwhile, investment bank and mortgage lending users would have to exit from the corporate DMZ, since regulatory requirements prevent them from using public exits due to data leak risks.
Finally, all branch-to-branch voice and video traffic could avoid being backhauled to the data center. This is an exception to the rule, since 90 percent of the time there is no need for any kind of data traffic to flow branch to branch.
Using this approach, voice traffic is treated as peer to peer while data traffic uses hub and spoke connections. As more diverse applications are introduced into the network, each line of business may require its own topology for compliance reasons.
As this scenario illustrates, networks now need the flexibility to connect based on business requirements, which is difficult to achieve using current architectures that are based on physical topologies.
To support cloud deployments, network security should be very closely tied to IT operations and compliance. This requires a network architecture that can provide centralized control, and support distributed and fluid data flow based on policy not topology.
This article is published as part of the IDG Contributor Network. Want to Join?