Designing a Secure Remote Access Solution for On-Prem IoT Devices using AWS Services

Enterprises deploying IoT devices in restricted on-premises environments often need to remotely access device services such as HTTP dashboards or SSH terminals. Since these devices reside inside private networks with no inbound internet access, a secure tunneling mechanism is needed.

In this blog, we will explore a real-world scenario and two AWS-native approaches to it:

1. AWS IoT Secure Tunneling via Greengrass Gateway (with localproxy)
2. AWS Systems Manager (SSM) Port Forwarding via Gateway

Scenario

• On-Premises Infrastructure

  • AWS IoT Greengrass Gateway (Linux, outbound internet access enabled).
  • Device A connected locally to the gateway, exposing an HTTP dashboard at http://deviceA:8080/dashboard.
• Cloud Environment

  • Cloud Operator VM in AWS Cloud.
  • Operator wants to securely open Device A's dashboard in their browser.

The goal is to access Device A's HTTP service from the Cloud without opening firewall ports or VPNs.

Approach 1: AWS IoT Greengrass + IoT Secure Tunneling (with Localproxy)

Architecture

1. The Cloud operator initiates a tunnel request from their Cloud VM, which creates a tunnel and generates source and destination tokens.
2. Device A exposes dashboard on HTTP port 8080.
3. The Greengrass Gateway runs the localproxy binary and maintains an outbound connection to AWS IoT Core.
4. On the Cloud VM, the operator also runs localproxy, which maps a local port (e.g., 8080) to the tunnel endpoint.
5. Requests flow: Browser → Cloud VM (localproxy) → AWS IoT Core → Gateway (localproxy) → Device A (HTTP service).

Sample Flow

1. Cloud Operator opens tunnel on Cloud VM.
2. Download localproxy binary (available for Linux, Windows, macOS).
3. On Cloud VM, run localproxy.
4. On Gateway, run localproxy.
5. The operator opens http://localhost:8080 and sees Device A's dashboard securely.

Advantages

• Outbound-only traffic from both the gateway and Cloud VM.
• Works for any TCP service (HTTP, SSH, custom).
• Designed for IoT fleet-scale operations.

Limitations

• Requires localproxy binaries on both sides.
• Tunnel sessions are temporary (maximum validity is 12 Hours).

Approach 2: AWS Systems Manager (SSM) Port Forwarding

Architecture

1. Gateway runs SSM Agent and registers as a managed instance.
2. Cloud Operator starts an SSM Port Forwarding session from their Cloud VM.
3. SSM routes traffic securely from Cloud VM → Gateway → Device A.
4. No extra binaries needed (only AWS CLI).

Sample Flow

1. Forward Device A's HTTP port through the gateway via AWS CLI.
2. Operator opens http://localhost:8080 to access Device A's dashboard.

Advantages

• No IoT Core or localproxy required.
• IAM-based fine-grained session access.
• Built-in logging via SSM.

Limitations

• Gateway must be configured as an SSM-managed instance.
• Gateway-centric model (not per-device like IoT Secure Tunneling).

Comparison

Conclusion

In this scenario, Device A’s HTTP dashboard is securely accessed by the Cloud operator in two different ways:

1. IoT Secure Tunneling with localproxy – Ideal for IoT-native deployments where each device or service requires secure, per-session connectivity.
2. SSM Port Forwarding – Simpler to set up if the gateway already uses the Systems Manager for hybrid cloud management.

Both approaches avoid inbound firewall changes and provide auditable, secure, and temporary remote access to on-prem IoT services.

Alpesh Bhavsar is a Senior Technical Architect with over 18 years of progressive experience in DevOps implementation, cloud architecture, and IT infrastructure management. He has successfully led the design and delivery of secure, scalable, and universally available cloud solutions for both SMBs and large enterprises. Alpesh specializes in architecture design, cost and effort estimation, cloud migration planning, and DevOps culture enablement across organizations.