A wider pool of matching agents
A customer reaches your Frankfurt contact centre. The right agent is available in London. Can the call reach that agent during a normal working day, without waiting for a disaster-recovery event?
With cross-Region routing in Amazon Connect Global Resiliency, it can. AWS announced the capability on 31 August 2026. The routing decision can consider matching agents across both linked Regions, offering the contact to the longest-available match.
Global Resiliency already linked a source instance and a replica, with controls for distributing voice traffic and agents. Both Regions could receive live traffic. Global routing changes which agents can receive a contact after it arrives.
A Frankfurt call, answered in London
Imagine a Polish-language support call arriving in Frankfurt. The routing service can evaluate matching agents in both Regions as part of the same decision.
- The call arrives in the Frankfurt instance.
- The flow sets the queue and routing requirements.
- The matching Frankfurt agents are busy.
- A matching agent is available in London.
- Amazon Connect offers the contact to that agent.
One interaction, two regional contexts
If the call starts in Frankfurt and a London agent answers, the contact stays in Frankfurt throughout its lifecycle. The contact’s origin Region and the agent’s active Region are different pieces of information.
This matters to CRM integrations, custom desktops, monitoring and disposition handling. A direct UpdateContactAttributes call must target Frankfurt for this contact. A PutUserStatus call must target London for this agent. Supported native Streams and Agent Workspace SDK operations handle cross-Region invocation; direct AWS API integrations need to choose the correct endpoint.
- Frankfurt: the contact record, call recording and Kinesis Video Streams live audio.
- Frankfurt: API operations that change the contact.
- London: API operations that change the agent, and the full agent event stream.
- Read operations such as DescribeContact can use either linked Region under consolidated search.
A shared view, with regional pipelines
Agents can handle supported cross-Region contacts through the normal Agent Workspace or a supported custom Contact Control Panel. A separate agent process is not needed just because the contact started in the paired Region.
Supervisors get consolidated real-time and historical metrics, plus contact search covering both Regions. GetCurrentMetricData, GetMetricDataV2 and GetCurrentUserData return a global view. Consolidated contact search requires the global sign-in endpoint.
The underlying event and data pipelines still need regional design. Contact events are emitted in both Regions. Full agent events come from the agent’s active Region; the alternate Region receives only Login and Offline events. Contact records remain in their origin Region.
For reporting, WFM, media processing, retention and deletion, account for both Regions. A combined search screen does not establish data residency or remove regional data ownership.
Where the feature fits today
Global routing works within the supported Global Resiliency pairings. This is a linked pair of instances, with a defined set of supported channels and dependencies.
Supported Region pairs
N. Virginia ↔ Oregon and Frankfurt ↔ London. For the Japan pairing, AWS specifies Tokyo as the source and Osaka as the replica.
Supported conversations
Voice, chats, tasks and email are supported with channel-specific considerations. Queued callbacks and customer-first callbacks can route across Regions once the customer leg is accepted and queued.
Agent routing and monitoring
Agent queues, preferred-agent routing and the Interrupt agent block are supported. Enhanced multi-party voice monitoring and barge, plus enhanced chat monitoring, are supported.
Salesforce integration
AWS documents global-routing support with CTI Adapter v5.33 and Salesforce Lambda package v5.27. Verify the installed versions and configuration against the current guide before rollout.
The limits belong in the delivery plan
Routing support does not give every feature the same behaviour across Regions. Include these constraints when agreeing the service journey and acceptance criteria.
- In-app, web and video calling, plus screen sharing, are not supported for cross-Region routing.
- Screen recordings are not generated for cross-Region contacts.
- Three-party call monitoring is not supported cross-Region. Use the supported enhanced multi-party monitoring capabilities where appropriate.
- Transfer to agent (beta) does not support cross-Region routing. AWS documents Set working queue with the agent queue, followed by Transfer to queue, as the alternative.
- Chat quick responses, task templates and email message templates need separate replication.
- Third-party Agent Workspace applications must be associated with both instances, with approved origins configured where required.
Readiness starts before you enable it
For new Global Resiliency instances created on or after 1 September 2026, global routing, consolidated analytics and consolidated contact search are enabled by default. Existing deployments need to request access through AWS and follow the migration process.
The Global Resiliency prerequisites still apply: an existing production SAML 2.0-enabled instance in a supported Region, AWS Enterprise Support or AWS Unified Operations, matched source and replica quotas, and the appropriate phone-number setup. Lambda, Lex and other dependencies need regional readiness too.
Global routing uses Region-prefixed aliases, such as eu-central-1.example.my.connect.aws and eu-west-2.example.my.connect.aws. Custom desktops need both instance URLs and the relevant Global Resiliency configuration. Update network allowlists and verify the identity-provider configuration.
Agents who were signed in when global routing was enabled must sign out and back in before they can accept cross-Region contacts. Treat the migration and validation steps as rollout work.
Routing and recovery need separate tests
Global routing decides which matching agent receives a contact. Traffic distribution controls where new inbound voice traffic arrives and where agents are active. Distribution remains configurable in 10% increments, including 100/0 and 0/100.
Changing distribution does not move existing contacts. Queued contacts stay in their origin Region. Agents in the other Region can handle them while that origin environment remains operational enough to support the contact.
UpdateCrossRegionRouting can temporarily disable or re-enable cross-Region routing. Disabling it does not disconnect existing cross-Region contacts; consolidated reporting, search and resource replication continue.
A practical go-live checklist
Start with representative customer journeys. Agree expected behaviour, observe both regional contexts, and record who owns each dependency.
- Routing: queues, matching requirements, callbacks, transfers and cross-Region handling in both directions.
- Agent access: SAML, regional aliases, firewall rules, custom desktops and Salesforce configuration where applicable.
- Dependencies: Lambda, Lex, templates, quick responses and third-party apps in both Regions.
- Integrations: the correct endpoints for contact and agent operations, plus consumers for regional events and media.
- Data: recording location, retention, deletion, access controls and regional compliance requirements.
- Recovery: regional impairment exercises and full-workload capacity tests, assessed separately from normal routing.
Shared capacity, clear ownership
For teams operating across markets, the useful opportunity is access to matching agent capacity across a linked pair of Regions, with a more consistent supervisory view.
The architecture still has regional boundaries. Make them visible in integration contracts, data workflows and recovery plans. That is how a broader routing capability becomes a service your operations team can understand and support.
THE TAKEAWAY
A contact can use matching agent capacity across the linked Regions while remaining in its origin Region. Design around both regional contexts, and test recovery separately from everyday routing.