Inferable’s architecture is designed to allow your function’s 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 in order to call functions.
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.
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.
Reduced Attack Surface:
With no incoming connections, there’s no direct way for external actors to initiate connections to your infrastructure through Inferable.
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.
Simplified Firewall Rules:
You only need to configure outbound rules, simplifying your firewall configuration and reducing the chance of misconfiguration.
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.
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.
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.