3 Secure and Effective Strategies for Migrating Corporate Applications to the Cloud

With the increased demand for remote work due to the pandemic, many businesses have turned their attention to the cloud. According to International Data Corporation, by 2022, around 90% of enterprises worldwide will rely on hybrid clouds. But how can you migrate applications to the cloud in the most efficient and secure way?

At Apriorit, we’ve worked on several projects that involved making corporate resources accessible for both on-site and remote users. Based on this experience, we’ll describe three different scenarios for migrating the existing applications to the cloud. You can use them as a basis for planning your own cloud migration strategy.

Ensuring availability of corporate resources

The cloud offers a wide range of possibilities for businesses: effective online collaboration, data storage, improved application and service availability. Gartner suggests moving at least seven critical workloads to the cloud, including collaboration and content management, remote workstation management, and even disaster recovery solutions.

Transferring critical applications and processes to the cloud provides businesses with meaningful benefits. For instance, it improves the availability of corporate resources. And smart infrastructure planning ensures that cloud-hosted apps and services are secure and well-performing.

But to make the most of cloud migration, it’s important to ensure that access to all cloud-hosted resources is effectively secured.

Organizations usually have three categories of resources:

• On-premises resources distributed among a company’s offices
• Resources located in a closed private network with limited access
• Resources hosted in the cloud

The problem is that if a remote user wants to access corporate resources hosted in the cloud, they’ll most likely be able to do it from any location. But applications and services running on-premises can only be accessed from a particular office (see Figure 1).

As you can see, the biggest challenge here is to provide all users with secure and comfortable access to applications and services that are only available at the company’s offices. Let’s find out how we can make these resources equally available for both on-site and remote users by migrating applications to the cloud.

Establishing a secure cloud network

When we move apps to the cloud, our main goal is to provide users with easy and secure access to an organization’s resources. To do so, let’s do some network management: we need to configure a private network uniting all corporate applications and services into a single secure system that a user can log in to over the internet.

Access to this system can be provided via a virtual private network (VPN) connection. On the server side, we install and configure a VPN server and make it accessible online. Then, a user needs to install a VPN client and specify the server to connect to and other connection information provided by the corporate system administrator.

There are many VPN tools on the market, but we usually use WireGuard, OpenVPN, or SoftEther, as they’re secure and comfortable to work with.

As things on the user’s side are rather simple, let’s focus on what’s happening on the server. In this article, we’ll overview three ways to migrate applications to the cloud:

• Using a single VPN server for all services
• Deploying multiple VPN servers
• Placing a VPN server inside a Docker container

Let’s start with the easiest approach.

1. A single VPN server for all services

For this approach to work, all users and service-providing servers should install the same VPN client and connect it to a single VPN server.

Then all traffic going from a client through the VPN tunnel will successfully reach the private addresses of applications connected to the VPN server. As for applications that are already hosted in the cloud, we can make them accessible only for specific IP addresses. To do so, we’ll need to route all traffic to these applications using our VPN server’s network address translation (NAT) firewall.

Most of the previously mentioned VPN services support DNS integration or provide a built-in DNS service that can associate issued IP addresses with the DNS names of services.

Now let’s take a look at the key advantages and drawbacks of this method.

Pros:

• Configuration is rather simple
• All traffic is encrypted by the chosen VPN server

Cons:

• A VPN client should be installed on every service-providing server, which isn’t suitable for large organizations.
• It’s difficult to configure load balancing and dynamically change the addresses of connected services.
• As the number of servers providing a particular service may vary, it’s difficult to configure a DNS service that requires entering specific IP addresses.
• There may be significant delays, as traffic routed from a VPN client may travel around the world before it reaches its destination.
• If the VPN server crashes, all services and applications will be unavailable.

Despite all its downsides, this approach can be effectively applied by organizations that don’t use too many external services. In the next section, we analyze possible improvements to this cloud migration strategy.

2. A network with multiple VPN servers

Let’s slightly improve the architecture described in the previous section. One of the key drawbacks of the single-server approach is that our entire network is fully dependent on one VPN server. If we deploy more VPN servers and unite them into a single mesh network, we can successfully solve this issue.

Let’s analyze the key strengths and weaknesses of this approach.

Pros:

• No single point of failure
• Easier to ensure proper load balancing
• Fewer delays, as client traffic can be routed through the closest VPN server
• In local subnets, a dedicated gateway can be deployed for routing traffic between the office subnet and the VPN server
• Can specify the office network DNS server on a VPN server without changing the DNS server and DNS service names in the office subnet

Cons:

• Increased support complexity, as we need to manage a group of servers
• Necessary to configure gateways in private subnets, although this can be done by either a private network admin or a network perimeter provider
• Increased costs, as the network perimeter provider has to allocate and maintain more hardware resources

Despite some downsides, this approach effectively serves its purpose, which is why many organizations end up choosing this type of cloud migration.

3. A VPN server inside a container

This approach works a bit differently than the two previous approaches to moving applications to the cloud. While we still provide access to our private network via a VPN server, the server itself is located inside a container. Furthermore, it only serves a particular user.

To simplify the maintenance of such a network, we can create and allocate new containerized VPN servers from a template. For instance, we can use a Docker container with all the needed services installed and configured.

For each user, we dynamically allocate a Docker container on one of the closest nodes. Before launching such a container, we need to specify which user it will serve.

We can launch containers independently in Docker swarm or Kubernetes. However, all our containers should be located in the same subnet as the VPN server that connects us to the applications from the office network.

Let’s overview the main benefits and implications of this strategy.

Pros: 

• Several organizations can be securely hosted on a single hardware resource, as we allocate a separate container for each and place it in an isolated Docker network.
• Depending on the number of connected users, it’s possible to dynamically allocate the needed hardware resources.
• User traffic processed by a gateway can be managed depending on the access rights of a particular user, as there’s a personal gateway to the corporate network for each user.
• All suspicious activity can be halted by blocking a particular container. In the case of compromised user credentials, only the gateway assigned to the user can be affected.
• To enhance proxying, protection, and analysis of traffic entering the corporate network, we can deploy and configure different HTTP/HTTPS or SOCKS proxies inside a container with a VPN server.

Cons:

• This is the most technically complex architecture among those we’ve described.
• This approach requires implementing an entity that performs user authorization, load balancing, and container management.

Depending on the size of your organization and the available DevOps resources, you can pick the approach that best fits your needs. The first approach would work best for small organizations and companies that don’t have too many service-providing servers in their infrastructures.

The second approach would suit both midsize businesses and large enterprises looking for a well-balanced and effective cloud migration strategy.

The last approach offers the highest level of access granularity and security improvements but requires extensive maintenance efforts. Therefore, it will be most suitable for large enterprise-level organizations that have enough qualified DevOps professionals.

Conclusion

When it comes to application migration to the cloud, it’s essential to ensure proper security of all corporate resources moved to a cloud network. In this article, we discussed how to move apps to the cloud. We overviewed three strategies that will be suitable for organizations of different sizes, and outlined key steps for moving applications to the cloud. However, it’s noteworthy that all three require working with a VPN, firewalls, and DevOps specialists.

At Apriorit, we have a team of true DevOps experts who have mastered the art of cloud infrastructure configuration and maintenance. Get in touch with us and we’ll gladly assist you in improving your cloud-based project.