HPE Zerto has replaced a manual, fragmented troubleshooting workflow with an on‑premises agentic troubleshooting system that leverages Amazon Bedrock for natural‑language interaction. The change matters because it consolidates alerts, documentation, and live environment data behind a chat interface, cutting the time engineers spend gathering context and enabling faster, more consistent remediation.
Why Engineers Should Care
Operators of hybrid and multi‑cloud protection platforms routinely juggle product alerts, event logs, and runbooks spread across dashboards. The new system lets them ask questions in plain language and receive answers that are grounded in the current state of the Zerto environment. This reduces context‑switching, lowers the barrier for less‑experienced staff, and provides managers with quick risk summaries during incidents.
System Architecture
The solution is deployed as a pod inside the Zerto product stack, keeping all processing on‑premises. Three logical layers are defined:
- UI layer – a chat widget embedded in the existing Zerto UI. Responses stream to the browser via Server‑Sent Events, giving users live visibility into the investigation progress.
- Agentic layer – agents built with the Strands Agents framework. They have access to:
- Session history stored locally for context retention.
- An internal
Model Context Protocol(MCP) server that exposes ZVM (Zerto Manager) APIs, allowing the agent to query live protection status, SLA compliance, and other structured data. - External knowledge fetchers that pull public documentation, runbooks, and operational knowledge as needed.
- Foundation model layer – Amazon Bedrock provides the large language model that interprets the user prompt, orchestrates the agent actions, and generates the natural‑language response.
Implementation and Operational Implications
Running the system on‑premises means the organization retains control over data flow and can enforce local network policies. Engineers must provision a Kubernetes‑compatible environment capable of hosting the pod and ensure the MCP server can reach ZVM APIs without exposing them externally. Because the model is invoked through Bedrock, the deployment must maintain an AWS credential set with permission to call the chosen foundation model and to use Bedrock Guardrails.
Operationally, the chat interface introduces a new observable component. Logging of agent actions, model prompts, and Bedrock responses should be integrated with existing observability pipelines to detect latency spikes or unexpected model behavior. Model selection is a trade‑off between quality, latency, and cost; the architecture allows evaluation of multiple Bedrock models before settling on a production choice.
Security and Governance
Amazon Bedrock was selected for its built‑in support for enterprise security and governance. Guardrails are applied to both incoming prompts and outgoing model output, helping align AI usage with company policy, compliance, and data‑protection requirements while preventing the model from leaking sensitive information.
Because all data stays within the on‑premises pod, the only external traffic is the Bedrock API call, which can be restricted to a VPC endpoint or private link if required. Practitioners should treat the Guardrails configuration as a policy enforcement point rather than a hard authorization boundary; additional access controls around the MCP server and the pod’s network interfaces remain necessary.
Related CloudNinjas coverage: AWS.
What This Means For Practitioners
Adopting an agentic troubleshooting system introduces a new layer that blends LLM inference with existing operational APIs. Teams should evaluate their ability to host the pod, manage Bedrock credentials, and integrate Guardrails into their compliance workflow. Monitoring the latency and cost of model calls, and establishing clear logging for agent actions, will be essential to keep the system reliable and auditable. The pattern shows that on‑premises LLM‑driven assistants are feasible for high‑stakes environments, provided security and observability are treated as first‑class concerns.
