Moving a resource reference from one AWS account to another on paper — updating a cross-account trust policy, rewriting a Terraform variable, copying an example into a different environment’s runbook — usually means retyping an ARN by hand and hoping the account id is the only thing that changed. Cross-Account ARN Generator does that substitution mechanically: give it a source ARN and a target 12-digit account id, and it rebuilds the ARN with only the account field swapped, leaving the partition, service, region, resource type and resource id exactly as they were.
The swap works by parsing the source ARN with the same field-splitting logic used across these ARN tools — the fixed header up to the fifth colon becomes partition, service, region and account, and everything after that is the resource, split into a resource type and resource id on whichever of / or : appears first. Only the account field from that breakdown is replaced; the resource type, resource id, and the separator between them are carried over unchanged, so a Lambda alias like function:my-func:PROD or a nested IAM role path like role/service-role/my-role survives the swap intact rather than getting mangled by a naive find-and-replace on the account digits.
Because a wrong or malformed account id defeats the entire point of the tool, the target account id is checked before anything is generated: it must be exactly 12 digits, the shape every real AWS account id has. Typing anything else — too few digits, letters, a placeholder like XXXXXXXXXXXX — produces a specific error naming what was typed, rather than silently building an ARN with a bogus account segment.
Not every ARN has an account field to begin with. S3 bucket ARNs are the clearest example — arn:aws:s3:::my-bucket has nothing between its fourth and fifth colons, because S3 bucket names are globally unique and AWS does not scope them by account in the ARN itself. IAM ARNs likewise sometimes carry no region. Rather than fabricating an account segment where none belongs, or silently producing an ARN that looks plausible but is not what a cross-account swap should mean for that service, the tool detects the empty account field and explains directly that a swap is not applicable here and why — so you are not misled into thinking the resulting ARN reflects a real per-account resource when it does not.
The result is shown as a before/after comparison: the parsed source ARN, the target and source account ids side by side, and the newly built ARN string with a one-click copy. This is deliberately a narrow, mechanical tool — it does not check whether the target account exists, whether you have access to it, or whether the resource actually exists there, since none of that is knowable without contacting AWS, which this page never does. What it does guarantee is that the only thing changed between the source and result ARNs is the account id, everything else is preserved exactly, and any case where that guarantee cannot hold — a malformed source, an invalid target, or an ARN with no account segment — is called out explicitly instead of producing a silently wrong answer.
Everything runs client-side. Given that both the source ARN and the target account id here are frequently real AWS account numbers, nothing you type is ever sent anywhere.