Documentation Index

Fetch the complete documentation index at: https://navigator.apprentice.io/llms.txt

Use this file to discover all available pages before exploring further.

Establishing Private Connectivity with Apprentice

Prev Next
This content is currently unavailable in Ja - 日本語. You are viewing the default (English) version.

Overview

Apprentice supports private connectivity for customers who require secure communication between their environment and Apprentice services. Depending on the customer's infrastructure, connectivity can be established using either AWS PrivateLink or a Site-to-Site (S2S) VPN.

The first step is determining which connectivity model best fits your environment.

Step 1: Determine Your Connectivity Method

If your systems are hosted in AWS, Apprentice can establish connectivity using AWS PrivateLink.

PrivateLink allows traffic to remain on private AWS networks without traversing the public internet.

Customers utilizing AWS PrivateLink will be responsible for establishing the required AWS networking infrastructure, including load balancers and related AWS resources required to expose services to Apprentice.

Additional AWS networking configuration and coordination may be required.

Site-to-Site VPN

If your systems are hosted on-premises or outside AWS, connectivity is typically established using a Site-to-Site VPN.

Apprentice utilizes a standard AWS Site-to-Site VPN configuration to establish secure communication between environments.

This approach is commonly used for:

  • Ignition SCADA

  • Data historians (Aveva/OSIsoft PI)

  • OPC UA servers

  • Manufacturing Execution Systems (MES)

  • Other Level 2 Operational Technology (OT) systems

Typical VPN Architecture

For VPN-based connectivity, traffic typically follows the path below:

Customer Service/Application

Customer Firewall

VPN Tunnel

Apprentice Load Balancer

Apprentice Applications

All communication occurs through the encrypted VPN tunnel using approved routes and designated endpoints.

Static IP addressing is required for VPN connectivity.

Step 2: Information Required from the Customer

For Site-to-Site VPN implementations, the customer must provide the following information.

VPN Endpoint Information

  • Public IP address of the customer VPN appliance or gateway

  • VPN device vendor/model (if available)

Note: Apprentice requires a static public IP address for the customer VPN endpoint.

Internal Network Information

The internal systems Apprentice will need to access through the VPN, including:

  • Internal IP addresses

  • Hostnames (if applicable)

  • Network ranges/subnets

Systems exposed through the VPN should utilize stable internal addressing to ensure reliable connectivity.

Service Information

For each service Apprentice will connect to, provide:

  • Hostname or IP address

  • Port number

  • Protocol

Examples include:

Service Type

Protocol

Typical Port

OPC/UA Server

TCP

4840

REST API

HTTPS

443

Web Service

HTTP

80

Custom Application

TCP

Customer Defined

Most implementations utilize standard TCP-based communications.

Step 3: Information Provided by Apprentice

Once the required customer information has been received, Apprentice will provide:

  • AWS Site-to-Site VPN configuration details

  • Pre-Shared Key (PSK)

  • VPN tunnel configuration information

  • Required networking parameters

This information is used by the customer's infrastructure team to configure the VPN connection.

Step 4: Service Exposure Requirements

To support reliable connectivity, customer services should be exposed via static IP and port,  optionally through a load balancer or highly available endpoint whenever possible.

The customer provided endpoint should:

  • Route traffic to the appropriate backend service

  • Allow traffic from the Apprentice VPN

    • Traffic will originate from an Apprentice provided VPN subnet range

    • Return traffic from the endpoint to the Apprentice subnet range must also be allowed

  • If a load balancer or HA solution is used, it should:

    • Perform any necessary health checks

    • Verify services are listening and responding

Apprentice services connect to these provided endpoints through the VPN tunnel.

Once the VPN tunnel, routes, and service endpoints have been configured and validated, additional VPN configuration changes are typically not required unless network architecture changes occur.

Step 5: Connectivity Setup and Validation

After configuration information has been exchanged, both teams work together to establish connectivity.

This phase typically involves multiple rounds of testing and troubleshooting while network routing, firewall rules, and VPN configuration are validated.

Common activities include:

  • VPN tunnel establishment

  • Route validation

  • Firewall verification

  • Endpoint accessibility testing

  • Service-level connectivity testing

It is common for customer infrastructure teams to make adjustments to network routing, firewall rules, or VPN configuration during this process. Apprentice will work directly with the customer's networking and infrastructure teams to troubleshoot and validate connectivity.

Step 6: Connectivity Verification

Connectivity is considered operational when:

  • VPN tunnels are successfully established

  • Required routes are available

  • Target services are reachable

  • Customer services are responding appropriately

  • Apprentice load balancer health checks report healthy status

Health checks showing a healthy (green) status on the Apprentice side indicate that the configured service endpoints are reachable and responding as expected.

Step 7: Environment Enablement

After connectivity has been validated, Apprentice will establish connectivity to the required implementation environments.

Typical implementation progression follows:

  1. Development (DEV)

  2. Validation/Test (VAL)

  3. Production (PROD)

Environment sequencing may vary based on customer requirements and implementation plans.

Supported Protocols

Apprentice supports standard industrial and enterprise integration protocols, including:

  • OPC UA

  • HTTPS

  • REST APIs

  • HTTP

  • Standard TCP-based communications

Additional protocols may be supported depending on integration requirements and technical review.

Additional Connectivity Scenarios

Some customers operate more complex network architectures, including:

  • Multiple manufacturing sites

  • Dedicated vendor networks

  • Separate business units

  • Hybrid AWS and on-premises environments

In these scenarios:

  • Multiple VPN tunnels may be required.

  • Separate subnets and routing configurations may exist for each site or network segment.

  • Customers operating dedicated vendor networks may require separate VPN connectivity for each network.

  • AWS PrivateLink may be used for AWS-hosted services while VPN connectivity is used for on-premises systems.

  • Additional network coordination may be necessary.

Apprentice will work with the customer's infrastructure team to determine the appropriate architecture and connectivity model before implementation begins.

Connectivity Support

Apprentice Professional Services and Infrastructure teams will work directly with customer networking resources throughout implementation to:

  • Review architecture

  • Configure connectivity

  • Validate communication paths

  • Troubleshoot network issues

  • Support environment enablement activities

Providing complete network, endpoint, protocol, and service information as early as possible will help accelerate implementation and reduce delays during connectivity setup.