Amazon Connect's October 7 Sign-in Migration: Check Domains First

Who needs to check, and who is outside this migration?

AWS plans to move remaining non-SAML Amazon Connect contact-center instances to the new sign-in experience October 7, 2026. Existing credentials remain usable. A stalled new page calls for endpoint checks first, not an assumption that the account or password expired.

The timeline has three stages: new instances default to the experience April 7; instances able to access endpoints migrate July 7; remaining instances migrate October 7. This is an existing deadline reminder. The guide gives no precise time or time zone and does not prove a particular instance has migrated now.

The scope is non-SAML instances using Connect-managed users or an existing directory. SAML 2.0 authentication is unaffected. Agents, supervisors, administrators, and networking staff should identify authentication configuration before deciding what action applies.

Ask networking staff to check these domains

The sign-in guide requires *.apps.signin.aws, *.signin.aws, and *.threat-mitigation.aws.amazon.com. Asterisks denote subdomain scope, not literal browser addresses. Apply patterns using the enterprise network equipment's supported method.

Also allow *.s3.dualstack.[Region].amazonaws.com for us-east-1, us-west-2, and the Connect instance Region. If the instance uses either of the first two, deduplicate the list; do not invent another region.

AWS GovCloud (US) has additional dedicated sign-in domains. Follow its list in the official sign-in guide instead of assuming a commercial-region configuration is complete. Authorized staff should make bounded changes under policy, not disable the entire firewall.

Why allowing only the instance Region is insufficient

Sign-in resources are not limited to the instance Region. Domain-based rules need the S3 dualstack patterns above. IP allowlists need S3 address ranges for us-east-1, us-west-2, and the instance Region; a domain string is not an IP entry.

The CCP networking guide lists S3 as outbound TCP 443 without a GLOBAL requirement. Existing EC2 and CLOUDFRONT ranges cover other new sign-in endpoints; CloudFront IP allowlisting still requires global scope and must not be reduced to the instance Region.

Obtain ranges from AWS's current published address data rather than copying static IPs into permanent configuration. These are migration-specific checks; calls, attachments, and other functions have their own conditions in the full CCP guide.

Verify through your instance, not just an accessible console

In an authorized AWS console, select the instance Region, open the Connect instance list, and confirm its actual URL. The entry may use my.connect.aws or the older awsapps.com/connect format. Do not guess an alias or use someone else's instance link.

For my.connect.aws, the documented check is https://[instance-alias].my.connect.aws/login?use-new-experience=true. Replace [instance-alias] with the actual console alias; this is a URL pattern, not a usable example account.

The older format is https://[instance-alias].awsapps.com/connect/login?use-new-experience=true. Sign in with existing credentials and verify the correct instance. The parameter selects the experience, not migration status or permission bypass. An accessible AWS console alone is insufficient.

A hypothetical example: Correct password, missing S3 regions

Suppose an ap-southeast-1 instance is used only through a corporate VPN. New signin domains are allowed, but S3 access covers only ap-southeast-1 and the page stalls. This is a fictional troubleshooting example; no real enterprise instance was accessed.

Ask staff to check S3 requirements for us-east-1, us-west-2, and ap-southeast-1 and inspect actually blocked requests. If logs show denied resources, amend the relevant rules through authorization and retry the same office path. A stalled page alone does not prove this cause.

If the page loads but rejects credentials, check username, password, and autofill. The new URL may not select the existing password-manager record. Verify the target and enter your own credentials rather than repeatedly changing networks or assuming every failure is expiry.

Completion checks and evidence for support

Verify real working conditions, not only one administrator's computer. AWS recommends common agent browsers, corporate firewalls and VPNs, and agent, supervisor, and administrator roles. Record instance, Region, path, and error to identify condition-specific failures.

For forgotten passwords, use Reset password on the new page, enter the username, and follow its instructions. Reset emails come from [email protected]; check spam and filters if missing. A changed sender does not require every account to register again.

Completion means reaching the correct instance. Softphone use then needs separate CCP checks: login is not voice-network acceptance. AWS also warns some proxies' WebSocket handling may affect functions. Observe network and authentication separately.

Administrators can use official support with instance ID or ARN, Region, and redacted errors. Screenshots help but must conceal credentials and customer information. A support request does not establish a migration defect or service outage.