Active-active Amazon Connect: the resilience lesson

On August 31, 2026, AWS announced that Amazon Connect Global Resiliency now supports cross-region routing of contacts to agents across two linked regions. The published example is straightforward: a contact entering US East (N. Virginia) can be offered to the longest-available matching agent whether that agent is in US East or US West (Oregon). The same idea applies to the documented regional pairs: N. Virginia/Oregon, Frankfurt/London, and Osaka/Tokyo.

The change matters operationally because it moves the architecture away from a passive design. Previously, many contact-center DR designs relied on a replica, phone numbers associated with a Traffic Distribution Group, and runbooks to move traffic. Those parts still matter, but the new point is that both regions stop being a promise. They exercise configuration, authentication, routing, integrations, metrics, and contact search as part of normal operation.

I would treat this capability as a maturity step, not as permission to relax engineering discipline. Active-active increases confidence, but it also increases failure surface. Everything that used to remain hidden in the secondary region now appears in production: asymmetric quotas, Lambda functions with different names, flows with fixed ARNs, incomplete IAM permissions, SaaS integrations without regional allowlists, and dashboards that aggregate without explaining origin.

The first change I would make in a critical operation is to turn the secondary region into an ordinary path, even with a small initial share. Global Resiliency allows traffic and agents to be distributed across regions in 10% increments, or moved all at once. I would start with a small and deliberate slice, for example 10% of new contacts in a lower-risk queue and an agent group trained to operate on both sides. The goal on day one is not perfect balancing; it is discovering drift with controlled impact.

That choice has cost and discipline attached to it. If both regions carry traffic, both need equivalent quotas, useful alarms, configuration pipelines, flow tests, and identity integration. The documentation is explicit about points I would not treat as details: the instance must be in supported regions, access to the feature requires engagement with AWS, and AWS recommends monthly failover testing. There is also a strong practical requirement: for flows that call Lambda, function names should be consistent across regions, and hardcoded ARNs need to be removed wherever the regional parameter is supported.

In a financial environment, I would also add a post-deploy validation pipeline. After any change to queue, routing profile, security profile, flow, Lex bot, Lambda, or external integration, a canary should execute a minimal journey in both regions: entry, routing, enrichment, recording, after-contact work, and analytical event.

The biggest trap in this architecture is assuming contact-center resilience ends when the contact finds an agent. In practice, service depends on a chain that includes SAML, CCP/Agent Workspace, CRM, internal APIs, profile stores, recording, transcription, classification, fraud controls, audit, and sometimes a conversational journey with Lex or AI agents. Amazon Connect may route the contact correctly, but the experience fails if the agent receives an empty screen or if an eligibility lookup gets stuck behind a regional API.

That is why I would design integrations with explicit regional contracts. A Lambda called by a flow should have the same name in both regions when required by the Global Resiliency pattern. IAM permissions should constrain by aws:RequestedRegion, connect:InstanceId where applicable, and environment-scoped resources rather than improvised names. For internal APIs behind API Gateway, I would use idempotency keys based on contactId, initialContactId, and logical step, stored in DynamoDB with TTL to avoid duplicate charges during retries or re-offers.

I would also separate operational state from analytical state. What is required to serve the customer must be available on the hot path with predictable latency. What is required for audit can move through EventBridge, Kinesis, or Firehose into S3 with replication and later reconciliation. Mixing both paths increases coupling exactly during failure.

The unified analytics and contact-search visibility across regions is relevant, but I would not let operations depend only on aggregated dashboards. Aggregated dashboards are useful for management; incident investigation needs slicing by origin, active region, queue, routing profile, flow, integration, and quota. The Global Resiliency model itself exposes metadata such as origin region, active region, and Traffic Distribution Group in contact structures, and I would use that as a telemetry dimension from the start.

My minimum signals would be: rate of contacts routed across regions, queue time by active region, error rate by flow block, p95/p99 latency of Lambdas invoked by flows, SAML authentication failures, contacts in after-contact work during a regional change, Amazon Connect API throttling, quota utilization by instance, and applied-capacity differences between regions. In CloudWatch, quota alarms should not wait for 100%; I usually start at 70% for trend and 80% for action, adjusted by criticality and seasonality.

I also like creating explicit operational events for distribution changes: who changed it, from what to what, ticket, reason, window, expected rollback, and observed result after 15 and 60 minutes. That can go to EventBridge and to an immutable S3 bucket with Object Lock when the organization needs a stronger audit trail. In serious incidents, the question is not only 'is it back?'. It is 'do we know exactly what was shifted, by whom, and with what effect?'.

In a contact center, capacity is not only concurrent calls. It is limits for users, queues, profiles, flows, numbers, APIs per second, integrations, recording, storage, and third parties. A poorly calibrated active-active design can fail in a counterintuitive way: region B receives only 10% of traffic for months, but one morning it must absorb 100%. If B's quotas were not raised at the same pace as A's, failover works in the routing plane and fails in the capacity plane.

The Global Resiliency requirements documentation advises requesting that all quotas in the replica match the source. A recent AWS article on quotas reinforces a point I consider critical: Service Quotas requests are regional, and after initial replication, increases must be kept in sync by region. This is a good example of invisible operational debt. The team increases capacity on the side under daily pressure and forgets the other side because it looks quiet.

I would solve this with declarative automation: daily inventory of applied quotas by instance and region, automatic diff, alert when the difference becomes non-zero for critical resources, and change blocking when a planned distribution exceeds estimated capacity. The practical rule is simple: if region B must receive 100% tomorrow, it must be measured as capable of receiving 100% today.