Problem solve Get help with specific problems with your technologies, process and projects.

Cloud access: Alternatives to Internet connectivity

The Internet's unreliability and questionable security keep many enterprises from adopting cloud services. But companies can consider these alternative cloud access options.

Most enterprises will employ the Internet for cloud access, but Internet connectivity to the cloud is "best effort"...

and may not be suitable for all applications. Some companies find that basic SSL or IPsec security for over-the-Internet cloud connectivity is insufficient because endpoints can still be accessed on the Internet.

For those enterprises that want to move beyond the Internet for public cloud access, the key question is whether the cloud provider will support the alternative you pick, and that will depend in part on just what that alternative is. There are three general options for non-Internet connectivity to the cloud, and enterprises report that none of these is universally accepted by cloud providers. Each of the three choices has its own benefits, which have to be weighed against how each type of connectivity could limit your cloud service options.

Here are three non-Internet cloud access options:

  • Leased lines and virtual circuit services(frame relay and ATM). Enterprises say that some cloud providers will agree to support these technologies for a fee or for a large customer. As noted below, these services may add a layer of complexity to the cloud/network relationship, but they offer the most stringent service level agreements (SLAs) and highest performance levels.
  • "Provisioned" virtual private networks (VPNs) based on MPLS and BGP, often called "Layer 3 VPNs." These VPNs are separated from the Internet; they do not inherit the Internet's performance issues, and they can be obtained with a specific SLA. It's fairly easy to find Infrastructure as a Service (IaaS) cloud providers that will support Layer 3 VPN access to cloud services, which effectively adjoin the cloud sites to a customer VPN. PaaS or SaaS support for this type of connection is reportedly more difficult to obtain.
  • Virtual LAN (VLAN) services. These are Layer 2 or Ethernet-like services that can be based on IEEE Ethernet standards or on Ethernet-over-MPLS, which includes virtual private LAN (VPLS) services and Overlay Transport Virtualization (OTV). Enterprises report that finding support for this type of WAN service among cloud providers is difficult.

Special network connections to public cloud services are difficult to obtain because the devices needed to connect to cloud services are normally dedicated to a single enterprise customer. This means the cloud provider charges for the cloud service as well as the dedicated space in their cloud data center for the equipment needed. Often, the facilities needed to connect to these cloud services need to be duplicated in each location where an enterprise's cloud application might be run -- further raising costs. Any time a cloud provider agrees to allow a special network connection, it's important to understand just how that special connection might influence the way user applications are assigned to resources and how differences in the assignment might affect performance. All of this complicates the cloud provider-to-cloud user relationship. It complicates cloud resource assignment, support and problem isolation. Sometimes it also creates issues when the cloud provider has an outage and has to reconfigure, as cloud providers tend to forget about users with special circumstances during those situations.

Another factor to consider is the nature of the cloud access connection the service provides, i.e., the "layer" or "level" of network connectivity. The Internet provides Layer 3 addressing of its users and applications, and that same level is provided by Layer 3 VPNs. The other special service connection options operate at a lower layer (leased lines and virtual circuits are Layer 1 and VLANs Layer 2), which means that Layer 3 connection architecture must be built over the lower-layer services -- typically by using routers. Adding a cloud provider to what is essentially a private router network has significant operational and security implications for both the enterprise and the cloud provider. That may add costs both for you and your cloud provider; it may also create an ongoing operations issue in coordinating problem isolation and other situations.

Cloud access considerations for connecting to hybrid cloud environments

Hybrid cloud applications have additional points to consider. You can create a hybrid cloud in two basic ways -- connecting at the front or back end of the application. Front-end clouds connect the public cloud and data center or private cloud to the same network -- the Internet or a VPN -- and enterprise users select one source or the other for their application, either directly or via a directory service such as DNS or UDDI. In back-end hybrid clouds, the enterprise data center is connected to the cloud data center. This is normally done with a point-to-point leased line or fiber trunk, or via a VLAN service. Few cloud providers offer this type of back-end integration except on a "special order" basis, and it is usually associated with high-end data center backup or workload overflow scheduling applications.

Any time you plan to use a Layer 2 or VLAN service in cloud connectivity, it's important to ensure that the cloud service supports the LAN standards you use in your operation, particularly for back-end data center cloud connection. There are a variety of new LAN standards that address the scalability and performance of Ethernet in clouds, including IEEE 802.1Qbg (Edge Virtual Bridging), IEEE 801.QBR (formerly IEEE 802.Qbh) and Bridge Port Extensions. For Layer 2 over MPLS, there are the Virtual Ethernet Port Aggregation (VEPA) and Transparent Interconnection of Lots of Links (TRILL) standards.

If any of these standards are required either in your own LAN or by the cloud provider, you'll need to support them in both your own network and the cloud. Some users may also need and providers may support IEEE 801.Qbb Priority Flow Control for Quality of Service (QoS) management in VLANs. Not only must the cloud support any of these standards that you expect to use in your cloud-connected WAN, that support must also be guaranteed for the future or you'll have problems later on.

A service provider with your cloud service is the cheapest option

A final point on special communications options for the cloud: Enterprises that require them will likely find that getting the communications service and cloud services from the same provider will increase the chances of having the right options available at the most favorable price. Clearly, any requirement for special services to access the cloud will reduce your cloud service choices and increase your costs, so be sure the decision is justified before you proceed. 

This was last published in January 2012

Dig Deeper on Cloud Networking