​

Compute on Private Networks

Inferable’s architecture is designed to allow your compute to be completely self-contained and run in a private VPC, or a private subnet in your on-premise infrastructure. Inferable does not need an ingress connection to your infrastructure.

​

How Inferable Communicates

1. Outbound Connections Only: The Inferable SDK initiates all connections from within your infrastructure to the Inferable control plane. There’s no need for inbound connections from Inferable to your services.

2. Long-Polling Mechanism: Inferable uses a long-polling approach to receive instructions from the control plane. Your services periodically check for new tasks, eliminating the need for open inbound ports.

​

Security Benefits

1. Reduced Attack Surface: With no incoming connections, there’s no direct way for external actors to initiate connections to your infrastructure through Inferable.

2. Mitigation of MITM Attacks: Man-in-the-Middle (MITM) attacks typically exploit inbound connections. By eliminating these, Inferable significantly reduces the risk of such attacks targeting your VPC via Inferable integration.

3. Simplified Firewall Rules: You only need to configure outbound rules, simplifying your firewall configuration and reducing the chance of misconfiguration.

​

Deployment Advantages

1. No Complex ALB Configuration: Since there’s no need to route incoming traffic, you can avoid complex Application Load Balancer (ALB) setups typically required for incoming connections.

2. Private Subnet Deployment: Inferable workers can be deployed entirely within private subnets. They only require outbound internet access, which can be provided via a NAT gateway or similar mechanism.

3. Reduced Infrastructure Costs: By eliminating the need for load balancers and other components typically used to manage incoming traffic, you can potentially reduce your infrastructure costs.

​

How It Works

1. Your services, running the Inferable SDK, initiate outbound connections to the Inferable control plane.

2. These connections use long-polling to check for new tasks or instructions.

3. When tasks are available, they’re returned via the same outbound connection.

4. Your services process these tasks locally within your VPC.