What Is a Bastion Host, and Do You Really Need One for Access to Cloud VMs

A bastion host is an intermediary server through which administrators access cloud VMs, especially when the working machines themselves do not have public IP addresses. Google Cloud describes a bastion host in exactly this way: as an external point of entry for connecting to VMs over their internal IPs.

In practice, that means a simple model: first, the administrator connects to the bastion host, and only then, through it, to the required virtual machine inside the private segment. This makes it possible to avoid exposing SSH or RDP directly on every VM.

A bastion host is most often useful when it is important to:

But a bastion host is not always necessary. In many scenarios, it is replaced by a VPN, a managed Bastion service, or tools like AWS Systems Manager Session Manager, which allow teams to manage instances without open inbound ports and without a classic bastion host. Azure Bastion follows the same general idea as well: secure access to VMs without exposing a public IP on the machines themselves.

That is why the main practical question here is not whether you have cloud VMs, but how exactly you want to organize administrative access. If what you need is a simple, controlled path into private VMs, a bastion host can be a good solution. But if the cloud platform already provides a more convenient managed mechanism, a separate bastion can sometimes do nothing but make the setup more complicated.

Bastion Host: What It Is and Why It Is Used at All

A bastion host (also often called a jump host or jump server) is a separate server through which administrators connect to virtual machines inside an internal network segment.

It is usually used where the working VMs themselves should not accept SSH or RDP directly from the Internet. Instead, one controlled entry point is exposed externally, and from there traffic continues onward to the required machine over its internal address.

Put simply, the logic looks like this:

• The administrator connects to the bastion host
• The bastion host sits inside the required network
• From there, access continues to the private VM
• The working machines themselves do not need to be exposed externally

That is the core idea: not to hand out external access to every VM individually, but to concentrate administrative entry into a single point.

This approach is usually needed not for architectural elegance, but for clearer control. When you have dozens of machines, it is much easier to monitor one entry point than to keep public SSH or RDP enabled on every single one of them.

Here is a short table that makes the role of a bastion host immediately clear:

The table shows the main point: a bastion host is useful not because cloud VMs cannot be accessed without it, but because it helps organize access in a cleaner and safer way.

How a Bastion Host Differs from a Regular VM with a Public IP

Now let us look at the difference more directly. At first glance, it may seem small: in both cases, there is a server you can reach over SSH or RDP.

But a regular VM with a public IP is simply a machine that is reachable from the outside. A bastion host is a deliberately dedicated entry point whose purpose is not to run business workloads, but to provide controlled access to internal resources.

That is exactly why a bastion host is usually kept as narrow in role as possible: minimal services, strict access rules, a limited group of users, login auditing, and carefully defined security rules. Azure Bastion, for example, is built entirely around this idea as a managed service: it provides RDP and SSH access to VMs over their private IPs without requiring public IPs on the machines themselves.

Do You Actually Need a Bastion Host to Access Cloud VMs

The short answer is no, not always.

A bastion host is not inherently required for access to cloud VMs. Virtual machines can be accessed in several different ways: directly, through a VPN, through a managed Bastion service, through identity-aware access, or through agent-based services such as Session Manager.

AWS explicitly states that Session Manager makes it possible to manage instances without open inbound ports and without bastion hosts. Azure Bastion and Google Cloud bastion scenarios show the same broader point: what matters here is not one single tool, but the chosen model for administrative access.

That is why the better question is not, “Do we have VMs in the cloud?” but rather, “How exactly do we want to organize access to them?”

When You Can Do Without One

In many cases, a separate bastion host really is not necessary.

If you have a small environment, one or two VMs, a limited group of administrators, and no strict requirement to remove the working machines from public reach, then another option may simply be easier. This is especially true where the cloud already provides a built-in managed mechanism, and the team does not want to maintain a separate jump server, track its updates, logging, and access rules.

Here is a short summary of the situations where a bastion host is often unnecessary:

The main point this shows is simple: a bastion host is needed not for the mere fact of connecting to a VM, but for a specific way of making that connection more centralized and more isolated.

When a Bastion Host Is Genuinely Justified

There are also the opposite scenarios, where a bastion host no longer looks like unnecessary extra layering, but like a perfectly logical choice.

Most often, it is justified when you need to:

• Give administrators access to private VMs without public IPs
• Concentrate SSH or RDP entry into one controlled point
• Reduce the number of external entry points into the internal environment

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


• Create a stricter separation between working machines and external access
• Simplify audit, logging, and control of administrative connections
• Avoid exposing direct access to every VM individually
• Pass internal or external access reviews more easily
• Better support regulatory and compliance requirements, where access to systems and data must be controlled and traceable

That is exactly the kind of environment where a bastion host shows its value most clearly. It is especially appropriate in infrastructures where there are already many working VMs, those VMs live in private subnets, and the team needs a clear and predictable administrative entry gateway. This is particularly useful where companies need not only to limit external access, but also to demonstrate who connected, when, and to which resources.

A bastion host is justified because it helps build a cleaner access model. If that is the actual goal, then it is useful. And if that goal is combined with audit, compliance, or regulatory requirements such as GDPR, the value of such an entry point becomes even more obvious. But if the cloud platform already provides a more convenient way to solve the same problem, then a separate bastion can end up adding only another unnecessary layer to the architecture.

What the Alternatives Are

A bastion host is not the only way to organize access to cloud VMs.

In many modern environments, it is either complemented by other approaches or replaced by them altogether. The reason is simple: a separate jump server also has to be administered, updated, logged, and secured. That is why teams are increasingly looking not only at the classic bastion model, but also at more manageable alternatives.

Below are the most common options.

VPN, Managed Bastion, Session Manager, and Identity-Aware Access

A bastion host has several viable alternatives, and the difference between them is not only in the name, but in the entire access model.

In some cases, the administrator first connects into the network itself. In others, access goes through a provider-managed entry point. And in some models, access is organized without a bastion host at all and without open inbound ports.

There is also a more mature layer of solutions: PAM systems (Privileged Access Management). These do not solve only the problem of entering the internal environment, but also the problem of controlling what privileged users actually do after they get access.

A comparison of the main approaches:

PAM systems are especially useful where it is no longer enough for the business simply to concentrate SSH or RDP in one place. In those environments, it matters not only to restrict external access, but also to control exactly who obtained privileged access, to which systems, on what basis, and what they actually did during the session.

Depending on the implementation, PAM can add RBAC, detailed logging, session recording, restrictions or filtering of individual commands, and alerts for the security team when suspicious actions occur. At that point, the discussion is no longer only about protecting the entry point from outside threats, but about a more mature level of control over administrative activity inside the environment itself.

The right choice usually depends on how much control, isolation, and operational effort the team needs. In some cases, a classic jump server under your own control is enough. In others, a managed or identity-driven model is more practical because it reduces manual maintenance and avoids building extra infrastructure around the entry point.

And when the company has higher requirements for auditability, compliance, and control over privileged activity, it becomes logical to look toward a PAM-based approach. In those situations, what matters is not only the entry point itself, but also much more mature control over who does what, how, and where inside an administrative session.

Conclusion

A bastion host is not a mandatory component for access to cloud VMs, but one of the ways to organize administrative entry into an internal environment in a clean and controlled way. It is especially useful where working machines should not have direct public exposure and the team needs a single controlled entry point to private VMs.

But it should not be treated as a universal solution. In many scenarios, the same goal is more conveniently handled by a VPN, a managed Bastion service, Session Manager, or identity-aware access — especially when the team wants less manual maintenance and less self-managed infrastructure around the entry point.

That is why the main conclusion is simple: a bastion host is not something you need “for every VM in the cloud,” but only when it genuinely fits your access model and your required level of control.

FAQ

Are a bastion host and a jump host the same thing?

They are often used almost interchangeably. In practice, a bastion host is essentially the same kind of jump server, but with stronger emphasis on being a secure and controlled entry point into an internal environment. Google Cloud describes a bastion host in exactly that way: as an external point of entry for VMs without external IP addresses.

Do you need a bastion host if the VM already has a public IP?

Not necessarily. Technically, you can connect directly to such a VM. A bastion host makes sense when you do not want to expose external access on every machine individually and instead want to concentrate administrative entry into a single point.

Can you do without a bastion host and without any open inbound ports at all?

Yes. AWS Systems Manager Session Manager is explicitly positioned as a way to manage instances without inbound ports, without bastion hosts, and without managing SSH keys.

If I have only one or two cloud VMs, won’t a bastion host be excessive?

Sometimes it will. In a very small environment, a separate jump server can add more operational overhead than practical value. In that case, it is often more reasonable to look at a managed Bastion service, Session Manager, or another built-in access mechanism if the provider offers one.

Is a bastion host only for SSH?

No. The idea is not limited to SSH. Azure Bastion, for example, is designed for RDP and SSH access to VMs, while Google Cloud IAP TCP forwarding can proxy SSH, RDP, and other TCP traffic to instances.

What is better to choose: a bastion host, a VPN, or identity-aware access?

That depends on the access model. A bastion host is convenient as a single controlled entry point. A VPN is useful when access is needed to the entire private segment. An identity-aware model is especially helpful when access should be built around identity and IAM policies rather than just around a network entry point. Google Cloud IAP specifically emphasizes granular control over who can establish tunnels to which VMs.

Sources

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

2. AWS — Systems Manager Session Manager

3. Microsoft Learn — What is Azure Bastion?

4. Google Cloud — Using IAP for TCP forwarding