At Cycle, we've taken a distinctive approach to VPN services, integrating them at the environment level of our platform. In a landscape where complexity can escalate quickly, anchoring each VPN to an environment - a VPC spanning the nodes of a cluster - simplifies management and maintains a high level of isolation.
Taking a look at how to configure a VPN on Cycle is the best way to understand the why of our architectural decision making. VPNs can be configured in an environment by enabling the VPN container, downloading the configuration credentials, and adding the connection to your local client.
There are two ways a user can authenticate to Cycle VPNs:
Cycle logins allow users with the environments-vpn capability to connect using their Cycle portal login credentials. VPN accounts are configured in the browser (or through the API). The easiest way to manage authentication as environments scale up to 10s, 100s, or 1000s is using Cycle logins, but both authentication options exist because the platform wants to expose the building blocks of VPN authentication that are right for the given environment(s).
With the VPN enabled and authentication set up, a user can connect to an environment VPN and gain access to the environment network.
Assume there is a MySQL database in the environment and it's set to public network disabled. In this sense, the database would be unreachable from a user's local network, but by using the VPN, that user can now reach the database and run some queries against it.
From the picture above, the user is connected to the VPN and has used that connection to facilitate a remote MySQL session through MySQLWorkbench. Now that the user is connected we can run whatever commands against this database we might want like: showing the available databases, seeing if a table exists, and selecting data from that table.
When it comes to setting up VPN services for other container platforms like ECS, Cloud Run, App Service, or Kubernetes (EKS, AKS, GKE, etc), there are a few ways a user can go. Generally, this is due to the fact that the IaaS provider (AWS, Google Cloud, Azure) has a specific way they want entry points set up that have access into the VPCs created on their platforms.
Taking AWS for example, whether the user chooses Kubernetes EKS or even ECS they'll be using either a site-to-site or client VPN. Here's an example setup for both.
In this case, the main difference to observe between Cycle and AWS services involves the ongoing mental bandwidth, internal documentation, and overall technical power needed. These resources are essential to decide, implement, and maintain this type of VPN.
On Cycle, the user never deals with updates to the VPN. Each VPN can be configured to work the exact same way as each of the other VPNs so they're standardized and easy to reason about, and the user isn't responsible for "opening up" anything in order to get the VPN to work with the rest of the environment.
If that's not enough, the simple fact that authentication can be set to Cycle logins should make a meaningful case for why Cycle's VPN architecture is more technically efficient than IaaS-level VPNs.
Cycle VPNs are designed, like other Cycle services, to be developer friendly, standardized, and scalable. This not only minimizes the setup complexity and maintenance overhead associated with VPNs in traditional cloud environments, but also enhances security and operational consistency.
💡 Interested in trying the Cycle platform? Create your account today! Want to drop in and have a chat with the Cycle team? We'd love to have you join our public Cycle Slack community!