When building applications in the cloud, one common requirement is to keep servers such as databases and backend services inside private subnets so they are not directly accessible from the internet. But this creates an important question:
How do we securely access a server that does not have a public IP address?
One common solution is a Jump Host, also known as a Bastion Host.
In this article, we will understand what a jump host is, why we need one, how it works, and how to implement a simple jump-host architecture using AWS EC2, VPC, public subnets, and private subnets.
What Is a Jump Host?
A Jump Host is a specially configured server that acts as an intermediate point between an administrator and servers located inside a private network.
As shown above, private servers can be accessed directly via SSH. Alternatively, we can use an intermediary Jump Host to securely connect to the private server, as illustrated below.
The jump host is normally placed in a public subnet, while the servers that need protection are placed in private subnets.
Simple Example
The image above illustrates a simple Jump Host architecture. Imagine an AWS VPC containing:
- A public subnet
- A private subnet
- A private application server
- A private database server
The key point is that the API and database servers do not require public IP addresses. A Jump Host provides secure access to these private servers.
Why Do We Need a Jump Host?
Let's consider a typical production environment.
This is a good architecture because the EC2 and database servers are not directly exposed to the internet. But now imagine that you need to troubleshoot the api server. From the diagram we can see that API server has a private IP address. So, you need to run:
ssh ubuntu@192.168.0.10
Your laptop is on the public internet. You cannot directly reach that private IP. This is where a jump host becomes useful.
Public Subnet vs Private Subnet
Before understanding the jump host, we need to understand the difference between public and private subnets.
Public Subnet
A subnet is considered public when it has a route to an Internet Gateway (IGW).
An EC2 instance in this subnet can potentially have a public IPv4 address and communicate with the internet.
Private Subnet
A private subnet does not have a direct route to an Internet Gateway (IGW).
The application server can communicate with other resources inside the VPC, but it does not have a public IP for direct internet access.
This is usually where we want to place:
- Application servers
- Backend servers
- Internal APIs
- Databases
- Internal services
AWS Security Groups
An AWS security group acts as a virtual firewall for your cloud resources, such as Amazon EC2 instances. It controls incoming (inbound) and outgoing (outbound) traffic based on rules you define for protocols, ports, and IP addresses.
A jump host should not be treated like an ordinary EC2 instance, and its Security Group must be configured carefully. Suppose the jump host has the private IP 192.168.0.8, while the App and DB servers have private IPs 192.168.0.9 and 192.168.0.10, respectively.
We can create three separate Security Groups: SG-JumpHost, SG-App, and SG-DB, with access rules defined based on the required communication paths.
Jump Host Security Group
SSH access to the jump host (192.168.0.8) should be restricted to trusted administrator IP addresses only. Allow inbound TCP port 22 exclusively from the administrator’s specific public IP address (for example, 203.0.113.10/32) instead of allowing access from 0.0.0.0/0. This significantly reduces the attack surface and helps prevent unauthorized SSH access.
App and DB Security Group
The App Server (192.168.0.9) and DB Server (192.168.0.10) should not allow SSH access from the public internet. Instead, their Security Groups should permit TCP port 22 only from SG-JumpHost, ensuring that administrative SSH access is routed through the jump host (192.168.0.8). This approach prevents direct internet access to the private servers and significantly improves the overall security of the environment.
Example: Accessing Private MySQL
To securely access a private MySQL server, you can create an SSH tunnel through the jump host instead of exposing MySQL to the internet. For example, if the jump host is 3.18.20.30 and the MySQL server is 192.168.0.10:3306, use ssh -L 3306:192.168.0.10:3306 ubuntu@3.18.20.30 to forward the MySQL port locally. You can then connect using mysql -h 127.0.0.1 -P 3306 -u appuser -p. This approach keeps MySQL private and avoids exposing TCP port 3306 to 0.0.0.0/0, significantly reducing the attack surface.
Jump Host Best Practices
A jump host is a security-sensitive server and therefore requires strong security controls. The following security best practices should be followed:
1. Restrict SSH Access
Never unnecessarily expose TCP 22 → 0.0.0.0/0 prefer TCP 22 → Your IP/32 or another tightly controlled source.
2. Use SSH Keys
Use SSH key authentication instead of passwords. For an example ssh -i my-key.pem ubuntu@3.18.20.30. Disable password authentication where appropriate.
3. Keep the Jump Host Updated
Regularly update the packages.
sudo apt update
sudo apt upgrade
An outdated jump host can become a major security vulnerability.
4. Use a Minimal OS
Use a minimal OS on the jump host and install only the software required for administrative access. Avoid running additional services such as web servers, databases, applications, Docker registries, or monitoring tools. Keeping the jump host’s purpose narrow reduces its attack surface and security risk.
5. Monitor Login Activity
Monitor the jump host regularly for SSH logins, failed login attempts, system logs, user activity, and network connections. For example, use sudo journalctl -u ssh to review SSH-related logs and identify suspicious or unauthorized activity.
6. Avoid Sharing SSH Keys
Avoid sharing SSH keys among administrators. Each administrator should use their own credentials or SSH key pair instead of a shared key such as admin.pem. This improves accountability, auditing, key rotation, and access revocation.
When Should You Use a Jump Host?
A jump host can be useful when:
- You need controlled SSH access to private servers.
- Your environment requires traditional SSH workflows.
- Engineers need administrative access to private EC2 instances.
- You need SSH tunneling to private databases.
- Your organization already has a bastion-host security model.
- You need a controlled entry point into a private network.
Conclusion
A Jump Host is a simple but powerful way to provide controlled administrative access to servers inside a private network.
Instead of exposing every EC2 instance to the public internet, we can keep application servers and databases in private subnets and allow administrators to access them through a dedicated, secured jump host.
A properly configured jump host should have restricted SSH access, strong authentication, minimal software, regular security updates, monitoring, and tightly controlled network permissions.
However, a jump host is not the only solution. In modern AWS environments, services such as AWS Systems Manager Session Manager, VPNs, and other private-access solutions can provide secure administrative access without requiring a publicly reachable bastion host.
Ultimately, the goal is not simply to deploy a jump host. The goal is to design an architecture where administrative access is controlled, private resources remain private, and every network path exists for a specific reason.
If you're designing an AWS environment, always ask:
How can I give administrators the access they need while exposing as little infrastructure as possible?
That mindset is the foundation of a secure cloud architecture.
Top comments (0)