Don’t bring your network to the cloud

I recently had the opportunity to facilitate a workshop at the annual Cloud Forum hosted by Cornell. The purpose of the workshop was to discuss whether to bring your networking to the cloud, meaning develop a hub and spoke architecture in AWS using transit gateways and then connecting to your campus network using VPN or Direct Connect. Or is it best to use cloud native networking and connect through the internet.

Why would you bring your networking to the cloud?

Let’s explore some of the reasons why you may consider bringing your network to the cloud. Some being very legitimate reasons, while others are perceived benefits.

Funneling all network traffic through your campus network and then through VPN is considered more secure. Initially, this sounds logical, forcing all your network traffic through your networking and firewalls allows you utilize existing security tools, risk assessments, monitoring, filtering, and SIEM. With this architecture, you need to ensure you lock down all cloud services for being exposed to the internet and force all services through your hub and spoke model. Your attack vector may be reduced but if your on-premise infrastructure is compromised, the attacker will still be able to access your cloud resources. Seems like a win-win scenario and it may be.

One downside of this architecture is the limitations of bandwidth of the VPN tunnel and the cost of direct connections. You also need to account for redundancy in this model, which will increase costs. Many higher education institutions have multiple high speed ISP connections for performance and redundancy. By not using the commodity ISP, you lose redundancy and high bandwidth.

Having your data travel across wild west of the internet adds a layer of complexity when debugging performance issues with applications and services. Whereas, the Direct Connect model comes with expectation of performance.

DDoS attacks are real and can bring the institution’s access to the internet to a crawl or be decommissioned altogether. This mean that during an attack, access to cloud services through the ISPs will be inaccessible. Campus resources will continue to function and more than likely the Direct Connect will be unaffected by the attack, so cloud direct services will be accessible. Of course, the simple answer is to connect to those cloud resources from an alternative location such as remote home office, but this can be disruptive for higher education institutions.

Argument for not bringing your networking to the cloud

As noted, most higher education institutions have multiple high speed ISPs. By not forcing traffic through your network, you can take advantage of those high bandwidth connections and inherent redundancies. You lose the additional data transfer costs and connection fees associated with VPN and Direct Connect.

By relying solely on cloud services, you gain the benefit of building redundancy and resilience for your applications and services by using elastic load balancers, Route 53, auto-scaling, and design architectures across availability zones and regions. Many cloud networking services have solid integration with other services you will be utilizing.

Bringing traditional networking to the cloud can add complexity and, in some regards, less secure. It may mean adding 3rd party appliances or services to match on-premise architecture. Whereas, using cloud native networking, you utilize cloud services to the fullest, improve security within your architecture, and is often more cost efficient. Just as in lift and shift model of moving servers into the cloud, you lose the value of cloud services. Don’t do the same with your networking.

No one solutions for every use case

Something to consider is Software Defined Networking (SDN) and how it can be used to bridge the gaps between on-premise networks and the cloud by providing a central view of all networks, allowing for agility, virtualization, and portability.

The important takeaways from this are that you don’t need to limit your networking architect to one model or path, you can bring both your network to the cloud and use cloud native networking. You’ll need to consider security, costs, performance, supportability, and user experience when selecting the path to the cloud. Selecting the right networking architecture can be challenging but keep in mind some of these points and use cases.

Special thanks and credits to John Bailey. Asst. Director, Cloud Systems at Washington University in St. Louis. John initially held a lightning round session and lead the workshop design for this topic.