Amazon Connect is a cloud-based contact center platform — but out of the box its reporting capabilities are limited. If you want real analytics — agent performance, queue trends, SLA tracking — you need to build the pipeline yourself. Here's the full CTR (Contact Trace Record) analytics stack I use in production.

The architecture

The pipeline follows a standard AWS streaming pattern:

  1. Amazon Connect → Kinesis Data Stream — Connect natively streams CTRs to a Kinesis stream as each contact ends.
  2. Kinesis Data Stream → Kinesis Data Firehose — Firehose buffers and delivers to S3, with optional Lambda transform in the middle.
  3. S3 — Raw and transformed CTR data lands here, partitioned by date.
  4. AWS Glue + Athena — Glue crawlers catalog the data; Athena queries it with standard SQL.
  5. Amazon QuickSight — Dashboards and visualizations on top of Athena.

Enabling CTR streaming in Connect

First, create a Kinesis Data Stream, then enable data streaming in the Connect instance settings. Under Data streaming → Contact Trace Records, select your Kinesis stream. That's it — every completed contact will now push a CTR event.

# Create the Kinesis stream
aws kinesis create-stream \
  --stream-name connect-ctr-stream \
  --shard-count 2

Firehose delivery with Lambda transform

The raw CTR JSON from Connect is fairly verbose. Before it hits S3, I run a Lambda transform in Firehose to flatten the structure and drop fields I don't need. This keeps the S3 footprint manageable and makes Athena queries faster.

# Key CTR fields worth keeping
{
  "ContactId": "...",
  "InitiationTimestamp": "...",
  "DisconnectTimestamp": "...",
  "Queue": { "Name": "...", "Duration": ... },
  "Agent": { "Username": "...", "AfterContactWorkDuration": ... },
  "Channel": "VOICE",
  "InitiationMethod": "INBOUND"
}

The Lambda transform receives a batch of records, processes each one, and returns them with a result field of Ok, Dropped, or ProcessingFailed. Keep your transform fast — Firehose has a 3-minute timeout per batch.

S3 partition strategy

Partition by year/month/day. Firehose supports dynamic partitioning with a prefix expression:

Prefix: ctr-data/year=!{timestamp:yyyy}/month=!{timestamp:MM}/day=!{timestamp:dd}/
ErrorOutputPrefix: ctr-errors/!{firehose:error-output-type}/

This gives you Hive-compatible partitions that Glue can catalog automatically and Athena can prune efficiently on date-range queries.

Glue crawler and Athena

Set up a Glue crawler pointing at your S3 prefix. Run it daily (or on-demand after large ingestion windows). Once cataloged, Athena queries are straightforward:

-- Average handle time by queue, last 7 days
SELECT
  queue_name,
  AVG(agent_interaction_duration) AS avg_handle_time_sec,
  COUNT(*) AS contact_count
FROM connect_ctr_db.ctr_data
WHERE year = '2023' AND month = '08'
GROUP BY queue_name
ORDER BY contact_count DESC;

QuickSight dashboards

Connect QuickSight to Athena as the data source. The most useful dashboards I've built:

  • Queue performance — contacts handled, abandoned rate, average wait time by queue and hour-of-day
  • Agent metrics — handle time, after-contact work, occupancy rate by agent
  • SLA tracking — % of contacts answered within target threshold (typically 20 or 30 seconds)
  • Daily trend — volume over rolling 30 days to spot seasonality

Watch-outs

A few things that will bite you if you skip them:

  • CTR data only appears after the contact is fully closed — including after-contact work. Don't expect real-time data; there's inherent lag.
  • Shard count matters. One shard handles ~1,000 records/sec. Size your stream for peak contact volume plus headroom.
  • Firehose buffer size and interval interact — smaller buffers mean more frequent (and smaller) S3 files, which hurts Athena performance. Buffer at least 5 minutes or 64 MB.
  • QuickSight SPICE has a data refresh limit. For near-real-time dashboards, use direct query mode instead.

Wrapping up

This pipeline gives you a complete analytics layer over Amazon Connect that the native reporting can't match. The Kinesis → Firehose → S3 → Athena path is battle-tested, and QuickSight on top of Athena is fast enough for operational dashboards. The main investment is the Lambda transform and the Athena schema design — get those right and everything downstream is easy.