AWS and M365 under one operator, not two

A new engineer joins Northwind Logistics on a Monday. By Tuesday they need a mailbox, a Teams account, an AWS console login scoped to the staging environment, and single sign-on that ties all of it together. You filed the request with the firm that runs Microsoft 365, because that is where identity starts. They created the user in Entra, set up the mailbox, and closed the ticket. Clean.

Then the engineer cannot reach AWS. The role mapping that turns their Entra identity into AWS permissions was never touched, because that is the other firm's job, and the other firm is waiting on a confirmation that the user exists, which they cannot see because they do not administer your tenant. So you become the messenger. You forward one firm's reply to the other, paraphrase what each means, and three days later the engineer has the access they needed on day one.

Nobody did anything wrong. Both firms did their half. The problem is the half nobody owned: the part where M365 identity becomes AWS access. That part does not belong to either contract. It belongs to you, by default, because you are the only person standing in both rooms.

Splitting AWS from M365 sounds tidy on paper. One firm handles the productivity stack, another handles the cloud infrastructure, each does what it knows best. The trouble is that the two stacks are no longer separate. They share a spine, and that spine is identity.

In a modern setup, Microsoft Entra is usually the identity provider for everything, including AWS. You federate AWS IAM Identity Center to Entra so that the same login governs both worlds (AWS documentation on configuring Microsoft Entra ID as an external identity provider for IAM Identity Center). When that federation works, a person joins once and gets the right access in both places. When it breaks, you have a user who exists in one world and is a ghost in the other.

The seams cluster in a few predictable spots:

• A joiner gets an Entra account but no AWS role mapping, so they are half-onboarded.
• A leaver gets disabled in M365 but keeps a working path into AWS, because deprovisioning stopped at the tenant boundary.
• A Conditional Access change in Entra quietly alters who can reach the AWS console, and the cloud firm never hears about it.

Each of these is invisible from inside a single contract. The M365 firm sees a tidy tenant. The AWS firm sees a tidy account. The gap between them is the one place neither is looking, and it is the place that matters most, because it is where access is granted and revoked.

The standard fix for this is a meeting. You get both firms on a call, agree on a process, write it down, and hope the next joiner follows the path. That works until the path has an exception, which is always, because real onboarding has contractors, service accounts, and the person who needs AWS but not a mailbox.

The deeper issue is accountability. When a handoff fails, the M365 firm points at the AWS firm and the AWS firm points back, and both are telling the truth about their own scope. You cannot escalate a problem that lives in the space between two contracts. There is no owner to escalate to. The runbook everyone agreed to is a description of the seam, not a fix for it; it just tells you, in advance, where the messenger work will land.

A handoff between two vendors is not a process. It is a place where accountability goes to die, because the only person who can see both sides is the one who hired both firms.

This is the quiet tax of split coverage. It does not show up as a failed audit or an outage. It shows up as your week: the forwarding, the paraphrasing, the standing translation between two teams who each did their job and still left you holding the part in the middle.

We run both layers, so here is the concrete difference. When the same operator administers Entra and the AWS account, the handoff stops being a handoff. The joiner gets the Entra identity, the role mapping into AWS IAM Identity Center, and the Conditional Access policy that governs both, in one motion, because one team can see the whole path. The leaver gets cut off everywhere at once, because deprovisioning does not stop at a contract boundary. A federation change gets made with full knowledge of what it touches on the other side.

This is not magic and it is not a bigger vendor. It is the same work, minus the seam. The integration that used to live in your inbox lives inside one operating team instead.

A few things follow from that:

• Identity, M365, and AWS access change together, so a user is never half-provisioned.
• The activity log covers the whole path, not two disconnected halves, which is what an auditor wants to see anyway.
• When something does break, there is one number to call and no one to point at.

The honest trade-off: if your AWS estate is large enough to need deep platform engineering, you may still want a specialist who lives in that account full time, and we will say so before we stretch to cover it. The unified-operator case is strongest for the small-to-midsize environment where the real risk is the seam, not the depth.

Walk back to the engineer who could not reach AWS on their first day. The mailbox worked. The console did not. And the reason was not incompetence at either firm; it was that the wiring between M365 identity and AWS access was a job with no name on it.

That is the whole argument for one operator over two. The point is not fewer invoices or a simpler vendor list. The point is that identity now runs through both your productivity stack and your cloud, and whoever owns one without the other leaves you owning the most important part by accident. So the next time a request bounces between two teams who both did their half, ask yourself the quiet question: who owns the part in the middle, and is it supposed to be you?