Introduction

How many times has it happened that you need to have a tunnel or a simple port-forward from an EC2 Instance in a private subnet or without open ports?

This blog covers an elegant and secure way to access these instances without any extra EC2 jump hosts or open ports on the instance.

All using the power of AWS Systems Manager’s (SSM) System Session Manager.

For your convenience

All automation and scripts are present here incase you want to skip the manual steps and test out yourselves.

GitHub - one2nc/terraform-ssm-private-ec2-instance: Simple Automation to spin up a private EC2 Instance with SSM Access.

What are your options?

Let’s start with the options available to you, for port forwarding from EC2 to other hosts/local.

1. Opening port 22 on the EC2 host.

2. Setting Up Bastion (You End Up Managing and paying for your bastion host as well as Egress costs)

3. P2S VPN with SaaS Offerings such as TailScale (Costs an arm and leg as your hosts increase)

4. AWS VPN: S2S VPN with IPSec.

5. P2S Setup with AWS VPN (Hacky but doable check this)

6. Manual VPN setup with Wireshark/OpenVPN (Free to set up, but a hassle to configure).

Let’s do better

There is a solution that addresses the limitations of the above solutions, one which:

1. Avoids vendor lock-in.

2. Avoids Proprietary VPN Setup.

3. AWS Native.

What is AWS SSM?

AWS Systems Manager (SSM) is a service that helps manage and automate operational tasks across AWS resources. It provides features like:

• Session Manager – Secure shell access (SSH/RDP) to EC2 instances without opening ports.

• Parameter Store – Secure storage for configuration data and secrets.

• Patch Manager – Automates OS patching for EC2 and on-premises servers.

• Automation – Orchestrates repetitive tasks like instance provisioning.

• Inventory & Compliance – Collects system data and ensures compliance.

SSM is commonly used for secure EC2 management, configuration automation, and compliance enforcement. It eliminates the need for bastion hosts and SSH key management.

Example Architecture

Fig: Example Architecture we are working on.

I have created a terraform script to recreate the shown infra here . If you prefer a manual setup you can refer to our earlier blog here.

This automation will create:

1. An AWS VPC.

2. A NAT Gateway.

3. An Internet Gateway

4. A Private Instance in a private subnet

5. VPC Endpoints for SSM. (Not required, needed in case of air-gapped environments, where you do not want to allow outbound traffic via a NAT Gateway, also, you do not require NAT Gateway in this case)

Pre-requisites

1. An EC2 Instance with SSM Agent installed. (AMIs exist with pre-installed SSM Agent).

2. Attach an IAM role with AWSSSMManagedInstanceCore Policy, read more about the policy here.

Starting a session to access the instance

Let us access the instance via AWS SSM Session Manager via AWS CLI, and install a web server. We could use EC2 User data, but for the sake of demonstration, I’ll do it manually, to demonstrate the capabilities of AWS SSM.

Let’s tie this together via a script and access the instance

The script:

1. Takes CLI input of the name of the instance to connect to.

2. Uses AWS SSM Session Manager to start the session

3. Now we can move on to the next step.

#!/bin/bash

export AWS_REGION=$REGION

# Get the instance ID using the provided name
INSTANCE_ID=$(aws ec2 describe-instances \\
    --filters "Name=tag:Name,Values=$INSTANCE_NAME" "Name=instance-state-name,Values=running" \\
    --query "Reservations[0].Instances[0].InstanceId" --output text --region $REGION)

if [ "$INSTANCE_ID" == "None" ] || [ -z "$INSTANCE_ID" ]; then
    echo "Error: Instance not found or not running."
    exit 1
fi

echo "Instance ID: $INSTANCE_ID"

aws ssm start-session --target $INSTANCE_ID

Execute the script and enter the required details to get into the session (You can also start the session using AWS Session Manager)

#Replace REGION and INSTANCE_NAME with your own values
REGION="ap-south-1" INSTANCE_NAME="PrivateWebServer"

You will drop inside the shell on your instance logged in as ssm-user

Let’s install nginx on the server

sudo apt install nginx 
sudo systemctl start

To test the connection inside the machine let’s do

curl

You will get the following response

Fig: Verifying NGINX Server inside the instance

Now this instance is in a private subnet, how do I port forward from the instance to my local machine?

Let’s answer that in the next section.

Fig: My instance does not have a public IP

Starting a Tunnel for Port Forwarding

Again I’ve written a small convenience script for the same, that you can run on your machine

#!/bin/bash

export AWS_REGION=$REGION

# Get the instance ID using the provided name
INSTANCE_ID=$(aws ec2 describe-instances \\
    --filters "Name=tag:Name,Values=$INSTANCE_NAME" "Name=instance-state-name,Values=running" \\
    --query "Reservations[0].Instances[0].InstanceId" --output text --region $REGION)

if [ "$INSTANCE_ID" == "None" ] || [ -z "$INSTANCE_ID" ]; then
    echo "Error: Instance not found or not running."
    exit 1
fi

echo "Instance ID: $INSTANCE_ID"

aws ssm start-session --target $INSTANCE_ID \\
                       --document-name AWS-StartPortForwardingSession \\
                       --parameters "{\\"portNumber\\":[\\"$INSTANCE_PORT\\"],\\"localPortNumber\\":[\\"$LOCAL_PORT\\"]}"

The script executes the AWS-StartPortForwardingSession document and sets up a port forward.

Let’s execute it

REGION="ap-south-1" INSTANCE_NAME="PrivateWebServer" INSTANCE_PORT=80 LOCAL_PORT=3000

Fig: Starting a Port Forward without SSH.

Let’s verify this on our browser at http://localhost:3000/

Fig: Accessing remote NGINX from the local machine.

Advantages of this approach

The key advantages of this approach are:

1. Decrease in attack surface.

2. AWS Native Solution.

3. There is no need to expose ports on the internet.

4. No Jump hosts are needed.

Common Gotchas

At times the SSM agent fails on the first boot of the instance, this can be fixed by restarting AWS SSM Session Manager on the instance at the first boot using EC2 User data. For more info on managing and installing SSM Agent based on your AMI visit here: https://docs.aws.amazon.com/systems-manager/latest/userguide/ssm-agent.html

Also, ensure the SSM Agent can connect to the following endpoints (can be achieved via NAT Gateway or VPC Endpoints).

1. com.amazonaws.ap-south-1.ec2messages

2. com.amazonaws.ap-south-1.ssmmessages

3. com.amazonaws.ap-south-1.ssm