How it works
The Cloud Collector is one of two AWS-side services Operata installs. The other is the Cloud Orchestrator, which generates synthetic traffic. The Cloud Collector ingests real traffic — it sits on the path between your Amazon Connect instance and Operata, not the other way round. Three components make up the Cloud Collector: an Amazon EventBridge Pipe that reads Contact Trace Records from the Amazon Connect Kinesis stream; a Lambda function that applies the active redaction config and enriches the record; and an EventBridge API destination that posts the filtered result to Operata. The Lambda function is the redaction enforcement point — see Privacy and redaction for the model it implements. The Lambda caches the active redaction config and polls the Operata API every 30 minutes to refresh it. If a refresh fails, the Lambda falls back to the mandatory minimum so a network outage cannot expand what the Cloud Collector ships. Each CTR passes through the Lambda once; allowed fields are forwarded, dropped fields stay in your AWS account. The Cloud Collector runs under two IAM roles: an EventBridge Pipe role that reads Kinesis, invokes the Lambda, and posts to the API destination; and a Lambda service role that executes the function, reads the Operata API token from Secrets Manager, and — when configured for VPC deployment — manages its network interfaces. The default CloudFormation template creates both roles with least-privilege policies scoped to the specific Pipe, Lambda, secret, and API destination ARNs. IAM Role and Policies documents the policy contract in full.Why redaction runs in your account
Running ingestion and redaction inside your AWS account, not Operata’s, is the structural guarantee behind the privacy model. The dropped fields are never read by anything outside your account — the filter runs before the record crosses the boundary. That guarantee only holds if the components live where the data lives, so the Cloud Collector is an in-account install rather than a service Operata operates centrally. The split into Pipe, Lambda, and API destination follows AWS-native shapes. EventBridge Pipes handle the source-to-target plumbing; Lambda handles per-record logic; API destinations handle outbound HTTP with retry. Each component has its own IAM surface, its own CloudWatch metrics, and its own failure mode, which makes troubleshooting per-record rejections straightforward. The 30-minute config refresh is a deliberate latency-for-safety trade. A faster refresh would react to policy changes sooner; a slower one would survive Operata API outages longer. Thirty minutes keeps the cached config fresh enough for most rollouts while leaving the Cloud Collector functional during transient upstream failures. Outside the refresh window, the Lambda enforces whatever config it last read — there is no live call to Operata per record.Related
- Privacy and redaction — the allow-list / deny-list model the Cloud Collector enforces.
- Cloud Orchestrator — the sibling AWS-side service that generates synthetic traffic.
- Signals and observations — what the filtered record becomes once Operata stores it.
- Why Kinesis Streams — why the Cloud Collector reads from a stream rather than polling.
- Data redaction — the reference index for the config the Cloud Collector reads.
- Get redaction config — inspects the active config the Cloud Collector caches.
- Update redaction config — replaces the config; the change propagates on the next refresh.
- Webhooks events — fires once Operata has stored the filtered record as observations.