Workload-type capacity in Amazon Connect: what actually changes

The old model is easy to describe: the routing profile sets Maximum contacts per agent per channel, plus one CrossChannelBehavior per channel. Four channels, four rows, done.

The new model inserts a dimension between the channel and the contact. There is a system predefined attribute, connect:WorkloadType, that you populate with your own values — Dispute-Review, KYC-Refresh, Statement-Request. The contact gets the value from the Set contact attributes flow block or from the UpdateContact API. In the routing profile, the Task or Email channel stops having one row and gets up to five, each with its own concurrency from 1 to 10 and its own cross-channel behavior.

Cross-channel behavior now has three options, and the middle one is the interesting one: no other channels or workload types, only other workload types of the same channel, allow other channels concurrently. You can state that an agent on Dispute-Review receives absolutely nothing else, while an agent on Statement-Request stacks three of the same class and still accepts a chat.

Two hard constraints. First: a channel cannot mix the two models — enabling workload-type concurrency disables channel-level concurrency on that channel, and the old fields go inactive. Second: a contact with no explicit workload type falls back to its subtype, which means a partial migration does not break existing traffic, as long as a row exists for that subtype.

Take a payments operation with two kinds of email in the same queue. Statement-Request is a system lookup and a template reply: four minutes, no attachments, no decision. Dispute-Review is a dossier — receipts, authorization history, a regulatory clock running, and a decision that turns into money refunded or not refunded.

Under channel-level concurrency with Concurrency = 5, the agent gets all five. Four are templates and one is a dossier, and the dossier loses. It does not lose for lack of staffing: it loses because the agent is interrupted by four trivial items while reading an authorization statement. What shows up in the report is average handle time drifting upward with no culprit.

The new configuration says the obvious out loud: Dispute-Review at concurrency 1 with no other channels or workload types; Statement-Request at concurrency 3 with only other workload types of the same channel. That sums to 4, inside the per-channel ceiling of 10.

Two numbers sit next to this. Email costs US$ 0.080 per message sent or received — every thread reopened by a rushed reply is a direct cost on top of the rework. And an email contact expires after 14 days by default, adjustable up to 90 through the connect:ContactExpiry attribute. In a dispute with a regulatory deadline, those two numbers have to line up with the rule's clock before anyone argues about concurrency.

Here is my most serious criticism of the launch, and it is not about routing: it is about how the configuration travels between environments.

The public API that touches routing profile concurrency is UpdateRoutingProfileConcurrency, and the object it takes is MediaConcurrency. That object documents exactly three fields: Channel with values VOICE | CHAT | TASK | EMAIL, Concurrency from 1 to 10, and CrossChannelBehavior. There is no workload-type field. Configuring the five rows per channel is described as an admin console flow — and what has no API shape has no Terraform module shape, no plan, no pull request diff.

The practical consequence is familiar to anyone who has operated a contact center for a while: production configuration starts drifting from staging along paths nobody reviews. In an audited operation — BACEN, PCI-DSS, any regime that demands change control — "someone with the right security profile changed it in the console" is an expensive answer to defend.

What I would do meanwhile: keep the workload-type taxonomy as a versioned artifact in the repository, with an owner, a definition and a target concurrency per routing profile; run a daily job that reads DescribeRoutingProfile and ListPredefinedAttributes and compares against the artifact; and treat drift as an incident, not a backlog item. It is manual reconciliation — but it is auditable reconciliation, which is what the audit actually asks for.

The promise is capacity that matches reality. Three signals prove it, and it is worth checking the dimensionality of each one on your instance before promising anyone a report.

Slots. SLOTS_AVAILABLE — surfaced as Availability — counts how many free slots each agent has for new contacts, respecting the routing profile limits and ignoring agents in a custom status. SLOTS_ACTIVE counts the ones occupied by contacts that are connected, on hold, in ACW or paused. Both come from GetCurrentMetricData, capped at 5 TPS with a burst of 8 — this is not an endpoint for one-second polling.

Real concurrency. AVG_AGENT_CONCURRENCY, in GetMetricDataV2, is concurrent handle time divided by handle plus idle time. A value near 1 means the agent is working sequentially. If you configured concurrency 3 on a workload type and the metric sits at 1.1, the configuration is not being exercised — either there is no volume, or the cross-channel rule is blocking upstream.

Instance saturation. ConcurrentEmails and ConcurrentEmailsPercentage in CloudWatch guard the ceiling of 1,000 active emails per instance; for Task the ceiling is 2,500 concurrent. The documentation's own recommendation is an alarm at 80% of quota. Breaching it does not degrade gracefully: the API call fails with a quota-exceeded error.

The signal that does not exist out of the box is the one for the failure mode above. Oldest contact age per workload type, alarmed at a multiple of expected wait, is the proxy that closes that gap.