Microsoft 365 Outage: Could Your Agents Still Log In to Amazon Connect?

What happened, in Microsoft's own words

According to The Register, the problems started around 18:00 UTC on 12 November, which is about 5 am on Friday 13 November in Melbourne. Exchange Online (the service behind Outlook email), Teams, Microsoft 365 Copilot and Defender for Office 365 were affected, and administrators also lost Intune, Microsoft's device management service. Security Affairs adds SharePoint Online to the list, citing Microsoft's admin notice MO1550821.

On the cause, Microsoft's updates have changed as it learned more. It first described elevated load across multiple regions. It then said, as reported by CNBC, that the load was not driven by an increase in traffic, and that a number of servers had become unexpectedly unavailable, “straining the remaining infrastructure”. In a later update quoted by The Register, Microsoft said “a core process on the affected servers is becoming overwhelmed” and that it was analysing diagnostic data. As of the reports we checked, Microsoft had not confirmed a root cause or given a time for full recovery, so we will not guess at one here. The live picture is on Microsoft's service status page.

Amazon Web Services told CNBC it was “operating normally”, and none of the reports we read describe an Amazon Connect outage. They also do not say that Microsoft sign-in itself was down. The point of this post is what would happen if it were.

Why sign-in is the weak point for a contact centre

Many organisations connect Amazon Connect to their Microsoft identity system (Entra ID, formerly Azure AD) using SAML single sign-on. It is a good setup: one password, one place to remove access when someone leaves. AWS's identity management guide is plain about what it means, though: with SAML, “users can only log in” through the link configured in your identity provider.

So if Microsoft sign-in has a bad morning, the phones still ring, the contact flows still run and callers still land in your queues. What changes is that agents starting a shift, or whose session has timed out, cannot get in to answer. From the caller's side, the line simply rings on with nobody there.

Two details make this harder to fix in the moment. The same guide says you cannot change an instance's identity option after it is created, so you cannot flip the live instance to local logins mid-incident. And an outage like this one also takes out the tools a team normally uses to coordinate, such as Teams chat and email, right when supervisors need to reach agents.

The backup pattern we recommend

This is the design we recommend to anyone running Amazon Connect with single sign-on. It is deliberately simple, because a backup that nobody understands at 5 am does not get used.

1. A second Amazon Connect instance with its own logins. Set it up with Amazon Connect's own user management, so nothing about signing in depends on Microsoft. Every agent who might need to take calls gets an account there in advance, with credentials handled through your normal secure process.
2. One queue and one phone number on the backup. No menus or complex routing. Calls that arrive go to whoever is signed in.
3. A staffing check at the start of the main flow, before the menu. The Check staffing block can test whether any agents are online for a queue. We check for agents who are signed in (online), not just free, so a busy morning never triggers it.
4. If nobody is signed in, a short hold message, then a transfer. The caller hears one line saying they are being connected, then the Transfer to phone number block sends them to the backup instance's number. That block only dials countries on your allowlist, so check the backup's country is on it.
5. If the check or the transfer fails, the normal menu plays. Every error path leads back to today's behaviour, so the change cannot leave a caller worse off than they are now.
6. Tag the transferred calls. Set a contact attribute before the transfer, so reporting can show how many calls went to the backup and when.
7. Rollback is one step. Remove the check and publish the flow, and you are back where you started.

On cost, Amazon Connect has no seat licences or upfront fees. A backup instance that sits idle costs the daily charge for its phone number, plus per-minute usage on the days it takes calls.

The parts that usually get missed

• A break-glass way into the admin website. AWS provides an emergency login from the Amazon Connect console (choose the instance, then “Log in for emergency access”). It needs an AWS console sign-in, so if your AWS console login also runs through Microsoft, keep at least one tightly controlled admin account that does not.
• A change that is already approved. If your change process needs a board or a sign-off, get the switch-on approved in advance, with the steps written down. The day you need it is not the day to start that conversation.
• A copy of the knowledge base agents can reach. If your agents' answers live in SharePoint, it was caught up in this outage too. A read-only copy on a separate site, refreshed on a schedule, means agents on the backup can still answer accurately.
• A simple way to record cases during the outage. If your CRM signs in through Microsoft as well, agents need somewhere to note who called and what they needed, such as a short form on the backup site. Import those records into the CRM once it is back, so nobody is forgotten.
• A way to tell agents. If Teams and email are down, agents need another way to hear “sign in to the backup”: an SMS list, a phone tree, or a printed card at each desk with the backup login address.
• A test, out of hours. On a test queue, sign every agent out, call in, and confirm the call reaches the backup and is tagged. Then break the transfer on purpose and confirm the caller hears the normal menu. A backup that has never been tested is a hope, and finding that out on a quiet Sunday is much better than on a busy Monday.

Five questions to answer this week

1. How do our agents sign in to Amazon Connect, and what does that depend on?
2. If that sign-in failed at 8 am on a weekday, what would a caller hear?
3. Who can get into the Amazon Connect admin website without Microsoft, and have they tried it?
4. How would we tell every agent what to do if Teams and email were also down?
5. Is the switch to a backup approved in advance, or would it need a meeting first?

If any of those answers is “not sure”, that is where to start. None of this needs a big project. Most of it is a second instance, a few flow blocks and a short runbook. If you would like a second pair of eyes on your answers, the free check below covers all five.

Frequently asked questions

Is Amazon Connect down because of the Microsoft 365 outage?

No. No outage of Amazon Connect was reported, AWS told CNBC it was operating normally, and Microsoft sign-in kept working, as far as the reports show. The risk is for another day: agents who sign in through Microsoft cannot log in if Microsoft sign-in fails, even while Amazon Connect works.

What did Microsoft say caused it?

As of the reports we checked, Microsoft had not confirmed a root cause. Its updates moved from elevated load across regions to servers becoming unexpectedly unavailable and failing health checks.

Can we switch our live instance to its own logins during an outage?

No. AWS documents that an instance's identity option cannot be changed after it is created, which is why the backup has to be a second instance set up in advance.

How do calls reach the backup automatically?

A staffing check near the start of the main flow. If no agents are signed in to the main queue, the caller hears a short hold line and is transferred to the backup's number. If anything in that path fails, they hear the normal menu.

What does the backup cost to keep ready?

No seat licences: an idle backup costs the daily charge for its phone number, plus per-minute usage on the days it takes calls.

How do admins get in if single sign-on is down?

Through AWS's emergency login in the Amazon Connect console, which needs an AWS console sign-in that does not itself depend on the identity provider that is down.

Sources

• The Register, “Microsoft struggling to fix massive cloud outage that's taken down email and Intune”, 12 Nov 2026: start time, affected services, Microsoft's statements.
• CNBC, “Widespread Microsoft outage takes down Outlook and other 365 services”, 12 Nov 2026: Microsoft's updates on cause, AWS operating normally.
• Security Affairs, “Microsoft Cloud Outage Hits Outlook, Teams, Copilot and AI Services”, 12 Nov 2026: admin notice MO1550821, affected services.
• Microsoft service health status: live status.
• AWS, identity management in Amazon Connect: SAML sign-in and why the option cannot be changed later.
• AWS, emergency login to the Amazon Connect admin website
• AWS, Check staffing flow block and Transfer to phone number flow block
• AWS, Amazon Connect pricing