> ## Documentation Index
> Fetch the complete documentation index at: https://docs.operata.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Cloud Orchestrator

> Runs inside your AWS account to drive synthetic Heartbeat checks and Virtual Agent calls against your Amazon Connect instance, surfacing failures before real customers see them.

Cloud Orchestrator is the AWS-side service Operata deploys into your account to run synthetic checks against Amazon Connect — placing test calls, exercising contact flows, and reporting the result back to Operata.

## How it works

Cloud Orchestrator is distinct from the [Cloud Collector](/docs/concepts-cloud-collector). The Cloud Collector ingests real contacts; Cloud Orchestrator generates synthetic ones. They share an AWS account and an Operata account but no runtime components — they can be installed independently.

Cloud Orchestrator runs on Amazon ECS with Fargate inside a dedicated VPC. The install stack creates the VPC and isolates it from other workloads in your account; only egress to the Operata API gateway leaves the VPC, and nothing routes in. A Lambda function handles orchestration logic — picking which check to run next, when, and against which contact flow — and ECS containers place the actual calls.

Two products run on Cloud Orchestrator: **Heartbeat**, the synthetic monitoring service that exercises a contact flow on a schedule and surfaces failures before customers see them; and the **Virtual Agent**, a container-based bot that plays the caller side of a Heartbeat call. The Orchestrator also creates and reads from a Kinesis stream when one is not already configured by Amazon Connect.

```mermaid theme={null}
flowchart LR
    A[Heartbeat schedule] --> B[Cloud Orchestrator Lambda]
    B --> C[Virtual Agent ECS task]
    C -->|Places call| D[Amazon Connect contact flow]
    D --> E[Result + signals]
    E --> F[Operata API]
```

## Why synthetic checks run inside your account

Synthetic monitoring needs to look exactly like a real customer to be useful. Running the Virtual Agent inside the same AWS account as your Amazon Connect instance means the call traverses the same networking, the same instance configuration, and the same regional routing — a failure detected by Heartbeat is a failure your real customers would see.

The separate VPC is deliberate. The Virtual Agent places outbound calls and holds credentials in AWS Secrets Manager; keeping it isolated from other workloads keeps the blast radius small and the IAM surface auditable. All AWS-side charges accrue to your account because the calls, containers, and Kinesis records live there.

The split between Lambda orchestration and ECS execution exists because the two have different shapes: orchestration decisions are short, infrequent, and event-driven (a good fit for Lambda), while running a voice bot in a container requires long-lived process state (a good fit for Fargate).

## Related

* [Cloud Collector](/docs/concepts-cloud-collector) — the sibling AWS-side service that ingests real contacts.
* [Signals and observations](/docs/concepts-signals-and-observations) — the data Cloud Orchestrator emits on each synthetic run.
* [Customer Journey Trace](/docs/concepts-customer-journey-trace) — Heartbeat journeys are traces too, so the same cross-platform model applies.
* [EventBridge](/docs/concepts-eventbridge) — how Cloud Orchestrator delivers run results to your downstream systems.
* [Webhooks events](/docs/api-webhooks-events) — `heartbeat.run.completed` and Virtual Agent events fire on every synthetic check, with the result and timing.
* [Contact summary](/docs/api-contact-summary) — Heartbeat calls appear as contacts with a synthetic flag, so you can filter them in or out of dashboards.
* [Webhooks overview](/docs/api-webhooks-overview) — how to subscribe to the events emitted by Cloud Orchestrator.