Bypassing VPN Failure with AWS SSM Port Forwarding

Secure RDP Tunnel via AWS SSM Port Forwarding

The Critical Need: Bypassing VPN Failure

Story: Imagine the alarm sirens going off today: a critical database server is nearing 100% disk usage. But disaster strikes twice. The corporate VPN is down, blocking all traditional access to servers in private subnets. With time running out, the on-call engineer cannot RDP in to clear logs or manage the database, risking a server crash that brings down a core service. This procedure ensures that service management remains possible, even when the VPN or corporate network access fails, by using the secure, out-of-band AWS backbone.

This document details how to use AWS Systems Manager (SSM) Port Forwarding to create a secure tunnel for Remote Desktop Protocol (RDP) access to a Windows EC2 instance. This method securely bypasses the need for a VPN or open network ports.

---

TL;DR

Critical servers become inaccessible when corporate VPN fails—database at 100% disk usage, services crashing, but no way to RDP in to fix the problem. AWS SSM Port Forwarding provides secure out-of-band emergency access through the AWS backbone, independent of corporate network infrastructure. Annual savings: $1,109-$7,289 by eliminating bastion hosts and VPN complexity.

The Emergency Solution: Use SSM Port Forwarding to create secure tunnels for RDP (port 3389) or SSH (port 22) access. Authenticate via AWS IAM (not corporate IdP), route traffic through AWS backbone (not corporate network), connect via SSM Agent (not open ports).

Key Takeaways:

1. Out-of-band access prevents total lockout - Primary access (VPN, corporate network) and emergency access (SSM, AWS backbone) use completely separate infrastructure. VPN outage, firewall misconfiguration, or corporate network failure doesn't lock you out.
2. More secure than bastion hosts - No open ports (22/3389) in security groups. IAM-based access with MFA and temporary credentials. Full CloudTrail audit trail. No SSH keys to rotate, distribute, or compromise.
3. Local port binding simplifies access - Remote RDP port 3389 becomes localhost:13389 on your machine. Connect multiple servers simultaneously with unique local ports (13390, 13391). Each tunnel in own terminal window.
4. Cost savings: $1,109-$7,289 annually - Eliminate bastion hosts ($15/month), ALB ($16/month), EIP ($3.65/month), VPN solutions ($50-500/month), SSH key tools ($20-100/month). SSM is FREE.

How It Works: AWS CLI initiates SSM session with port forwarding to target instance. Remote service (RDP/SSH) becomes accessible on localhost. Traffic encrypted end-to-end through AWS backbone. Terminal must remain open—closing terminates tunnel.

Core Principle: Out-of-band management—primary and emergency access paths should use separate infrastructure. When one fails, the other remains available. Separation ensures resilience during infrastructure failures.

---

The Principle: Out-of-Band Access

The core principle here is out-of-band management. Your primary access path (VPN) and your emergency access path (SSM) should use completely separate infrastructure. When one fails, the other remains available.

SSM Port Forwarding works by:

1. Authenticating through AWS IAM (not your corporate identity provider)
2. Routing traffic through the AWS backbone (not your corporate network)
3. Using the SSM Agent on the instance (not SSH or RDP ports)

This separation ensures that a VPN outage, corporate network issue, or firewall misconfiguration doesn't lock you out of critical systems.

---

Prerequisites

Before using SSM Port Forwarding, ensure:

• AWS CLI: Configured and authenticated with appropriate IAM permissions
• SSM Agent: Installed and running on the target EC2 instance
• Instance IAM Role: Must include the AmazonSSMManagedInstanceCore managed policy
• Network Connectivity: Instance needs access to SSM endpoints (via NAT Gateway, VPC Endpoints, or public IP)

---

How It Works

Step 1: Start the Tunnel

Use the AWS CLI to initiate an SSM session with port forwarding. The command specifies:

• Target instance ID
• Remote port to forward (3389 for RDP, 22 for SSH)
• Local port to bind on your machine

The key principle is local port binding. The remote service (RDP on port 3389) becomes accessible on your local machine (localhost:13389).

Important: The terminal running this command must remain open. Closing it terminates the tunnel.

Step 2: Connect via RDP Client

With the tunnel active, connect your RDP client to localhost:13389 instead of the instance's private IP. The traffic flows through the SSM tunnel, encrypted end-to-end.

---

Connecting to Multiple Servers

To access multiple instances simultaneously, start separate SSM sessions with unique local ports:

Each session requires its own terminal window. The principle is port isolation. Each tunnel gets a unique local port to avoid conflicts.

---

Cost Savings Breakdown

Before: Traditional SSH + Bastion

After: SSM Session Manager

Annual Savings: $1,109 - $7,289

---

Security Principles

Why SSM is More Secure Than Bastion Hosts

1. No open ports: SSM doesn't require port 22 or 3389 open in security groups
2. IAM-based access: Leverage existing IAM policies, MFA, and temporary credentials
3. Full audit trail: Every session logged in CloudTrail
4. No key management: No SSH keys to rotate, distribute, or revoke
5. Encrypted by default: All traffic encrypted through the AWS backbone

Best Practices

• Enable session logging: Send session output to CloudWatch Logs or S3
• Use IAM conditions: Restrict access by IP, time, or instance tags
• Implement MFA: Require multi-factor authentication for SSM access
• Set session timeouts: Automatically terminate idle sessions
• Regular audits: Review CloudTrail logs for SSM session activity

---

When to Use This Pattern

Use SSM Port Forwarding when:

• VPN is down and you need emergency access
• Accessing instances in private subnets without bastion hosts
• You want to eliminate SSH key management
• Compliance requires full session audit trails
• You need temporary, revocable access for contractors

Consider alternatives when:

• You need persistent, always-on tunnels (use VPN or Direct Connect)
• Accessing non-AWS resources
• The instance doesn't have the SSM Agent installed

---

This procedure provides a vital contingency plan for access and management while delivering significant cost savings.

Facing Similar Infrastructure Challenges?

At ZSoftly, we understand the critical importance of maintaining secure and reliable access to your cloud infrastructure. Our team of certified DevOps and AWS experts specializes in implementing robust solutions that ensure your systems remain operational, even during unexpected outages.

Whether you need help with AWS SSM configurations, VPN alternatives, or comprehensive cloud security strategies, we provide tailored services to keep your business running smoothly.

Ready to strengthen your infrastructure resilience? Contact ZSoftly today for a free consultation and discover how our professional DevOps and cloud services protect your operations.

• Email: info@zsoftly.com
• Phone: +1 (343) 503-0513
• Website: zsoftly.com