Setting the file. One moment.
Subchapter 25.22
references/phases/clarify/clarify-identity.mdMarkdown6 KBView on GitHub
Fragment unit. See
clarify.mdfor how it is composed into the phase.This fragment asks nothing. It returns rows;
clarify-assemble.mdpresents them.
Category J, and it always fires — every Azure estate has an Entra ID tenant behind it,
even when no identity resource appears in the inventory. That is exactly why the category is
unconditional: absence of Microsoft.ManagedIdentity/* resources means the workloads use
keys, not that there is no identity story.
One shallow question. Human identity migration is a large topic and this is a startup-weighted skill, so the row establishes a direction and stops.
Keeping these apart is the whole reason this fragment is small:
| Where it lives | |
|---|---|
| Workload identity — managed identities, role assignments, what an app is allowed to read | already handled without a question. Microsoft.ManagedIdentity/userAssignedIdentities → IAM Role is a fast-path row; roleAssignments is a Skip Mapping because IAM policy is authored against the AWS design rather than translated |
| Human identity — who logs in, from where, with what MFA | this fragment, and it is not a resource mapping at all |
A one-to-one translation of Azure RBAC would encode Azure’s scope hierarchy (management group → subscription → resource group → resource) into IAM, which has no such nesting. That is why the workload half is deliberately not a question.
| Read | Resolves |
|---|---|
count of Microsoft.ManagedIdentity/userAssignedIdentities | how much workload identity exists, for the row’s context |
presence of Microsoft.Authorization/roleAssignments | whether RBAC is in active use |
presence of Microsoft.KeyVault/vaults | whether secrets are already centralised |
None of these change the answer. They make the row’s context line concrete.
Disposition: PROPOSED. Default: identity_center_reinvite.
How should people sign in to AWS?
[A] Fresh start with IAM Identity Center — create users and groups
in AWS and re-invite your team (default)
[B] Federate with Entra ID — keep Entra as the identity provider
and use it for AWS sign-in via SAML or OIDCConsequence line: Assuming a fresh IAM Identity Center directory → the simplest path, and no dependency on Azure after cutover. Choose federation if you are keeping Entra ID for other reasons, such as Microsoft 365.
Why [A] is the default rather than [B]. Federation is the more sophisticated answer and the wrong assumption here. Defaulting to it would mean the migration retains a dependency on the cloud the customer is leaving — the exit is not an exit if AWS sign-in breaks when the Entra tenant lapses. A team keeping Microsoft 365 has a real reason to federate, and that is precisely the sort of reason only they know.
For a startup-sized team, re-inviting people to a fresh directory is usually hours of work. Say that in the row so [A] does not read as a cop-out.
"identity": {
"disposition": "PROPOSED",
"value": null,
"default": "identity_center_reinvite",
"context": "3 user-assigned managed identities, 0 role assignments, 1 Key Vault in the inventory"
}| Row | Consumer |
|---|---|
identity | design-refs/identity.md (build step 5, not yet written) and Generate’s IAM Identity Center scaffolding |
identity.md is still missing, and index.md routes one type to it. That is a real gap
rather than a decision: this row is currently recorded and not yet consumed by any rubric.
Note it on the sheet as recorded-for-later rather than implying it shapes the design today.
Each of these is a genuine question that a real migration has to answer, and each is out of scope for a startup-weighted skill. Listing them is the honest alternative to pretending one shallow row covers identity:
If the estate shows heavy Entra investment — many role assignments, custom role definitions, several app registrations — say on the sheet that identity migration is likely to need its own workstream. That is a more useful thing to tell someone than a fourth question they cannot answer here.
Implemented. Sourced from architect-for-startups/references/migration-azure-to-aws.md,
which keeps the pre-decision advisory conversation while this skill handles real migration
intent.