Which Access Method Should You Choose for a Cloud Server: SSH Keys, VPN, or a Bastion Host

Choosing between SSH keys, a VPN, and a Bastion Host is not really about “what feels more familiar,” but about choosing the right access model for a cloud server.

If access is needed only to one or two VMs, the network is simple, and the risks are controlled through strict rules and tightly limited ingress, then direct SSH with keys can still be a perfectly reasonable option.

If access is needed not just to one server, but to an entire internal segment, then it usually makes more sense to look toward a VPN. A VPN gives entry to the private environment as a whole, not just to one specific point.

If, on the other hand, the working VMs should not be exposed externally, you do not want to grant access to the entire internal segment, and what you need is a controlled gateway into the private network, then the logic starts pointing toward a Bastion Host.

Put simply, the rule of thumb looks like this:

The key here is not to pick a “favorite tool,” but to choose the access model that matches the scale of the infrastructure, the network design, and the level of risk.

Where to Start When Choosing an Access Method

The best place to start when choosing access to a cloud server is not with the tool you already know, but with a simpler question: what exactly needs to be accessed, and through what kind of network path?

It is one thing to have one or two VMs and a clearly defined group of administrators. It is another to deal with a private segment, several internal services, a jump server, working machines without public IPs, and stricter requirements for controlled access.

That is exactly why SSH keys, VPN, and Bastion Host are not three interchangeable buttons. They solve different problems at different layers.

Why You Should Choose Not by Habit, but by Risk Level and Network Design

The most common mistake here is to choose access the way “we always used to do it.”

For example, a team may continue opening SSH to the Internet and working only with keys out of habit, even though the infrastructure has already grown and the working VMs should no longer be publicly exposed. Or the opposite happens: the team introduces a VPN immediately, even though access is needed only to one server and for just a couple of administrators.

In practice, it is more useful to look at a few simple things:

• Is access needed to one VM, or to the entire internal segment?
• Do the working machines have public IPs?
• How many administrators are there, and how often do they connect?
• Do you need to concentrate access into one controlled point?
• How important is it to reduce the external attack surface and remove direct Internet access?

This becomes clearer in a simple example.

Imagine a small merch platform: it has a website, an internal panel for managers, a database, a couple of service VMs, and a separate server for background tasks.

If engineers only occasionally need to log into one external Linux server, then under strict firewall rules and key-based access (or password + key as a basic MFA-style measure), direct SSH can still be a reasonable option. If the team needs access to several internal services and private VMs at once, a VPN becomes the more logical model. And if the working machines should not have any external address at all, and the team wants to concentrate administrative entry into one point with clearer control, then a Bastion Host starts to make sense.

So the order of thinking is actually quite simple: first understand what access model the network itself requires, and only then choose the tool that fits that model.

Once that is clear, it becomes much easier to examine each option separately — not as “three technologies in general,” but as answers to a specific access scenario.

SSH Keys: When Direct Access Is Still a Perfectly Reasonable Option

SSH keys do not solve the network architecture question by themselves, but in small and straightforward scenarios, direct SSH access can still be a perfectly reasonable model.

This is especially true where the team has only a few servers, the group of administrators is limited, and external access is tightly restricted by a firewall so that connections are allowed only from specific IPs, password login is disabled, and other baseline hardening measures are already in place.

Put simply, SSH keys work well not instead of the whole access model, but in situations where the overall design is still simple.

Here is a short guide to where this option usually makes sense:

The main principle that follows from this is simple: SSH keys are a good fit where access remains narrow and does not expand into a separate access environment of its own.

This is especially noticeable in a small setup where the team has only one or two external Linux VMs, a limited set of administrators, password login is disabled, and access is allowed only from a known list of IP addresses. In that kind of model, direct SSH with keys often remains the simplest and healthiest choice.

But this approach reaches its limits fairly quickly. As soon as the number of servers grows, private VMs appear, internal panels and databases without external IPs are added, or the team wants to remove working machines from public exposure altogether, direct SSH begins to look too rough as a model.

At that point, the question shifts: it is no longer just about how to log into one machine, but about how to access the entire internal environment — or at least how to do it through one controlled point. That is exactly where the logic for VPN and Bastion Host begins to appear.

VPN: When You Need Access Not to One Server, but to the Internal Environment

A VPN becomes relevant at the moment when it is no longer enough for the team simply to log into one specific machine.

If engineers need access to several private VMs, internal dashboards, databases, service APIs, or other resources inside the cloud network, the logic changes. In that kind of setup, it is more convenient not to expose a separate external entry point for every server, but to connect the administrator first to the private network environment itself.

That is exactly the main point of a VPN.

It provides not a narrow entry point to one host, but access into the network, after which the engineer can work with the required resources as though they were already inside that segment.

Here is a short guide to the situations where this option usually makes sense:

The main principle that follows from this is simple: a VPN works well where the need is not for access to one point, but for entry into the internal perimeter itself.

This is easy to picture.

If the team needs to administer not only one Linux server, but also an internal database, a monitoring dashboard, a restricted API, and a few service VMs without public IPs, then direct SSH starts to look too rough as a model. In that case, VPN access creates a more understandable design: first connect to the private network, then work with the needed resources inside it.

But this approach also has its limit.

A VPN works well when access is genuinely needed to the segment as a whole. If the task is no longer to let the engineer into the internal network broadly, but to provide a narrower and more controlled path into private VMs through one specific entry point, then the logic begins to shift toward a bastion host.

Bastion Host: When It Makes Sense to Concentrate Access into One Controlled Point

A Bastion Host becomes useful at the moment when the team no longer wants the working VMs exposed externally, does not want to admit engineers broadly into the internal perimeter through a VPN, but still needs remote administrative access to those hosts.

In that kind of design, what remains externally reachable is not every server individually, but one controlled entry point. The engineer first connects to the bastion host, and only then, through it, reaches the required private VM over its internal address.

The real value of this model is not in some “special way to SSH,” but in the fact that access becomes more centralized and more manageable.

Instead of many working machines each having their own way in from the outside, the team gets one gateway through which administrative access flows. This becomes especially useful when the infrastructure has already grown, several private VMs exist inside the internal segment, and direct Internet access to them looks too crude. A VPN may also be a poor fit if it grants broader network access than desired, or if there are audit requirements from internal policy or regulators around administrative actions.

Here is a short guide to the situations where a bastion host usually looks appropriate:

EU Cloud Infrastructure You Control

Run production workloads on dedicated resources across EU data centres. Transparent pricing, no hidden costs. Full control over compute, storage, and networking.

Explore Infrastructure

Predictable Virtual Machines for Production

Dedicated vCPUs, consistent performance, no noisy neighbours. Deploy and scale VMs in minutes. Full root access, fixed pricing.

View VM Plans

Up to €22,000 to Migrate Your Workloads

Cut OPEX when migrating to EU infrastructure. Get migration support, cost assessment, and infrastructure credits with no upfront commitment.

Apply for Bonus

Kubernetes with Full Control

Deploy production-ready clusters with control over node configuration, storage, and networking. Predictable costs and direct access to infrastructure.

Deploy Cluster

The main principle that follows from this is simple: a bastion host is a good fit where the goal is not merely to connect to a server, but to centralize and narrow the administrative path into the internal infrastructure itself.

But it has its own boundary too.

If engineers do not need a gateway to a few private VMs but broad and regular access to an entire private segment, then a VPN is often the more logical model. And if the infrastructure is very small and really consists of only one or two machines under tight network controls, then a bastion host may end up being an unnecessary extra layer compared with direct SSH.

How Not to Get the Choice Wrong in Practice

How the Three Main Approaches Differ

At this point, it is useful to bring all three approaches into one picture and look at how they differ in practice.

Here is the comparison:

A simple and useful thought comes out of this table: the choice here almost never comes down to the question of “which one is more secure in general.”

A much more useful question is this: where exactly should the engineer end up after connecting?

If the goal is access to one specific machine, that is one model. If access is needed to the internal network as a whole, that is a different one. And if what is needed is a narrow and controlled gateway into private VMs, then the logic points toward the third option.

How to Match the Access Model to Your Infrastructure

The first thing to understand is how many real access points you have and which of them should be visible from the outside.

If you have one or two external VMs, a small admin group, and clear network restrictions, then direct SSH with keys can be a perfectly sensible starting point. If engineers work constantly with several internal resources, private machines, and service dashboards, a VPN becomes more convenient. And if the working VMs should not have any external access at all, while you want to concentrate entry into one controlled point, then the logic begins to favor a bastion host.

It is also useful to look at scale and frequency of use.

If access to one machine is needed only occasionally, building a full VPN environment may be excessive. But if the team works with the internal network every day, direct SSH to individual nodes quickly turns into an inconvenient and poorly governed design.

It is worth evaluating the required level of control separately as well.

If the goal is simply to log into one server securely, one model may be enough. But if the goal is to shrink the external perimeter, remove public IPs from working VMs, centralize administrative entry, or separate admin access from ordinary network connectivity, then the right choice may be different. Google, for example, explicitly recommends restricting network access for SSH, and the bastion model is built precisely around the idea of not exposing working VMs externally.

If reduced to a very short rule of thumb, it looks like this:

• SSH keys — when you need targeted access to a small number of machines
• VPN — when you need entry into the internal environment as a whole
• Bastion Host — when you need a narrow and controlled gateway to private VMs

The main practical rule is simple: choose not the most fashionable access method, but the one that matches the scale of the network and the way engineers actually work with the infrastructure.

Conclusion

SSH keys, VPN, and a Bastion Host are not competitors for the exact same role, but three different access models.

One is better suited for targeted access to a small number of machines. Another works better for operating inside a private network segment. The third is designed for controlled access to private VMs through a dedicated entry point. That is why the right choice starts not with the tool the team happens to like most, but with an understanding of the network itself and what actually needs to be reachable from the outside.

If you want a short practical takeaway, it looks like this:

• Do not introduce a VPN where narrow, targeted access is enough
• Do not keep direct SSH exposed externally longer than it is genuinely justified
• Do not deploy a bastion host just because it “looks more serious”
• First decide whether you need access to one VM, to the whole segment, or to one controlled entry point
• Only then choose the specific model

Companies with stricter security requirements may also combine these approaches. For example, access to the Bastion Host can be allowed only through a VPN, while access from that bastion to specific VMs can still rely on personal SSH keys.

In that order, access to a cloud server stops being a bundle of habits and becomes a proper architectural decision.

FAQ

Are SSH keys and a Bastion Host the same thing?

No. SSH keys are an authentication method, while a bastion host is a separate access point to private VMs. You can still use SSH keys through a bastion, but that is already a different network-access model.

If I have only one VM, is a VPN already overkill?

In many cases, yes. If access is needed to only one machine and ingress is tightly restricted at the network level, direct SSH with keys is often simpler and more appropriate. A VPN usually starts making sense when access is needed not to one server, but to the whole internal segment.

Is a Bastion Host more secure than a VPN?

Not “in general,” but within its own use case. A bastion is good as a narrow, controlled entry point to private VMs. A VPN is good when access is needed to the whole internal network. These are different models, and it is more useful to compare them not by abstract security, but by the kind of access you actually need.

Can you avoid public IPs on working VMs entirely?

Yes. That is exactly why teams often choose a VPN or a bastion host, including managed bastion services.

Do SSH keys by themselves already solve the access-security problem?

No. They matter, but without network restrictions, source-access control, and a sound entry model, they are not enough.

What should a small team choose for private VMs?

If access is needed to several private VMs through one entry point, a bastion host is usually the logical fit. If the team needs access to the whole internal segment and other services inside the network, a VPN is more often the better choice.

Sources

1. Google Cloud — SSH best practices: Control network access

2. AWS — What is AWS Client VPN?

3. Google Cloud — Connect to Linux VMs using a bastion host