Deep Response Engine over AWS PrivateLink: Monitoring Your Infrastructure Without a Public Endpoint

How CloudThinker's Deep Response Engine reaches EKS, Prometheus, Redis, and other production services inside a customer VPC — without opening a single port to the internet.

01 — The Public Endpoint Problem

Every third-party monitoring tool needs a way in. The default answer — expose an endpoint, whitelist an IP, hand over a token — is also the one your security team dreads signing off on.

A public endpoint is a permanent addition to your attack surface, whether or not anyone ever exploits it. It's a load balancer with a DNS name that resolves from anywhere on earth, a target for credential-stuffing and port scanners, and a line item your auditor will ask about by name. For enterprise teams pursuing SOC 2 or ISO 27001, "we expose Prometheus and our internal NLB to the public internet for a third-party AI vendor" is not a sentence anyone wants to write in a control narrative. It invites exactly the finding compliance frameworks exist to prevent: an inbound path into production infrastructure that isn't fully under your control.

Deep Response Engine (DRE) — the incident investigation and remediation loop behind CloudThinker's AgenticOps platform — needs continuous access to real signal: Kubernetes events, Prometheus metrics, Redis health, Postgres performance, application latency from the API tier. That's a lot of surface area to reach from outside a customer's VPC. The question isn't whether DRE needs connectivity — it's whether that connectivity has to come at the cost of a public endpoint.

It doesn't.

02 — PrivateLink: The Private Backbone

CloudThinker runs outside every customer's VPC, as a multi-tenant SaaS platform. To let Pulse (DRE's signal ingestion layer) and the investigation agents reach a customer's infrastructure, we connect over AWS PrivateLink instead of the public internet.

Every hop between CloudThinker and a customer VPC stays on AWS's private backbone. No public IP is assigned, no security group opens a rule to the internet, and the customer's IAM policy decides who gets to connect at all.

The mechanics matter more than the marketing term. CloudThinker maintains an Interface VPC Endpoint with an ENI inside CloudThinker's own VPC. Traffic from that endpoint travels over AWS's private backbone to a VPC Endpoint Service the customer creates and owns. At no point does a packet get a public IP address, traverse an internet gateway, or leave AWS's network. There is no NAT gateway in the path and no firewall to route around — the "internet" simply isn't part of the path.

That single property collapses most of the attack surface argument. You can't port-scan a service that has no public IP. You can't credential-stuff an endpoint that only resolves inside AWS's backbone. And for compliance purposes, "traffic never traverses the public internet" is a control statement your auditor can verify directly against the VPC Endpoint Service configuration — not a claim resting on firewall rules staying correctly configured forever.

The customer keeps the steering wheel throughout. AllowedPrincipals on the VPC Endpoint Service is the authorization gate: only the specific IAM role CloudThinker connects with is on that list. Nothing else — no other AWS account, no other role — can even request a connection. The customer accepts the endpoint connection, and can revoke it at any time by editing that list or deleting the endpoint service outright. This is infrastructure the customer provisions and can tear down unilaterally; CloudThinker never holds the only copy of the off switch.

03 — Least Privilege, Even on a Private Path

A private network path answers "can anything on the internet reach this." It doesn't answer "what can CloudThinker do once connected." That's a separate question, and we treat it as one.

Every credential DRE uses to reach customer infrastructure is scoped down before it ever gets used. The Kubernetes ClusterRole granted to CloudThinker's service account allows get, list, and watch — full read access to observe cluster state, events, and logs — and nothing else. No create, no update, no delete, no patch. The IAM role authorized on the customer's VPC Endpoint Service carries the same shape: read-scoped policies, no wildcard actions, no administrative grants.

The reason this matters even inside a private network is straightforward: PrivateLink controls who can connect, not what a connection is allowed to do. If DRE's credentials were ever misused, replayed, or targeted, a read-only role limits the blast radius to "an attacker can see your metrics" — not "an attacker can delete your deployment." Network isolation and credential scoping are independent controls, and DRE relies on both rather than treating either as sufficient on its own.

04 — One Shared NLB, Not One Endpoint per Service

DRE needs signal from more than one system per cluster — typically the API tier, the primary database, the cache layer, the message queue, and Prometheus for metrics. Standing up a dedicated Network Load Balancer per service, each behind its own endpoint, is both an operational and a cost problem: more NLBs to provision, patch, and monitor, and more hourly charges for infrastructure that's mostly idle.

Instead of one Network Load Balancer per service, DRE's signal collectors reach every namespace through a single shared NLB, routed by port to the matching target group — fewer endpoints to provision, fewer to pay for, fewer to audit.

In practice, one internal NLB in front of the VPC Endpoint Service is enough. It routes by port to a separate target group per namespace — api, database, cache, messaging, monitoring — so five services share one load balancer and one endpoint connection instead of five. From the customer's side, this means a single artifact to review, approve, and audit, rather than five separate attack surfaces to track individually.

05 — What DRE Still Does With Less Access

None of this trades away investigative capability for safety. Pulse still ingests the full signal stream from every connected service, DRE still clusters noisy alerts into coherent incidents, and when a pattern crosses the escalation threshold, the AI investigation loop still runs full root-cause analysis across the same telemetry it would have with broader access.

Remediation follows the autonomy mode the customer configures — Manual, where DRE proposes a fix and an engineer approves it, or Auto, where DRE executes runbook-defined actions directly. Either way, DRE's own connection into the customer's environment stays read-only for observability; write actions during remediation are performed through the customer's own scoped automation, not by widening what DRE's monitoring credentials can touch. The engineer stays in the loop at the level they choose — reviewing and approving from outside the VPC, never needing standing access inside it.

06 — Getting Connected

Public endpoints trade a small amount of setup friction for a permanent increase in attack surface. PrivateLink asks for 30–60 minutes with your network team once, in exchange for a connection that never has a public IP to defend, and an access grant your security team can revoke on their own timeline.

For DRE specifically, that means full signal visibility and full investigative capability into EKS, Prometheus, Redis, Postgres, and Kafka — without opening a single inbound rule to the internet.

→ Read the Connections Guide — VPC Endpoint setup, step by step

→ Contact Us for PrivateLink Setup — enterprise connectivity with dedicated support