AWS Recharge AWS EC2 cross account image migration

Why “cross account image migration” sounds scarier than it is

“AWS EC2 cross account image migration” is the kind of phrase that makes people immediately imagine complicated Terraform spells, mysterious IAM policies, and a spinning wheel labeled “AccessDenied.” To be fair, AWS can absolutely humble you. But the actual workflow for moving EC2 images between AWS accounts is pretty logical once you understand the moving parts.

In plain English: an “image” in EC2 is usually an AMI (Amazon Machine Image). An AMI is made of metadata plus one or more underlying snapshots. When those snapshots are encrypted, you also get KMS keys in the mix. And when you want to move an image to another AWS account, you have to make sure the destination account can access the AMI and the snapshots, and that any encryption rules are satisfied. That’s it. The rest is bureaucracy in a trench coat.

This article shows a practical, readable approach to cross-account EC2 image migration: what to plan, what to execute, and what to verify. We’ll cover both “sharing then copying” and “direct copying” patterns, and we’ll address the most common reasons migrations fail: missing permissions, wrong KMS key policies, and the classic “I shared the AMI but not the snapshots” misconception.

Before you touch anything: understand AMIs, snapshots, and permissions

Let’s untangle the terminology so the rest of the article doesn’t feel like reading a recipe where every ingredient is named after a distant moon.

What an AMI actually includes

An AMI is a description of a bootable template. For typical Linux/Windows instances, it usually references one or more EBS snapshots:

• The root device snapshot (the main boot volume)
• Optional additional snapshots for attached EBS volumes captured in the AMI
• Block device mapping details

The AMI itself has settings like architecture, virtualization type, and launch permissions. But when it comes to copying between accounts, the real “meat” is snapshots and how they’re encrypted and shared.

Copying AMIs: you’re copying metadata, and also (usually) snapshots

When you “copy” an AMI to another region or account, AWS creates a new AMI in the destination account and ensures the underlying snapshots are copied or accessible as needed. In many cases, you’ll end up with destination-side snapshots that the destination can use. That’s why permissions and KMS policies matter so much.

Why cross-account access is not just “share the AMI”

Sharing an AMI is like inviting someone to your party. It tells them the party exists. But if the snacks are stored in a locked basement with a key your guest doesn’t have, they won’t get to eat. In AWS, the locked basement is often:

• EBS snapshot encryption requirements
• KMS key policies that control decrypt permissions
• Snapshot sharing settings (or inability to share due to encryption policy)

So yes, launch permissions on the AMI matter. But if the snapshots are encrypted with a customer-managed KMS key, you also need to grant decrypt access to the destination account (or copy using appropriate KMS permissions).

Plan the migration like a responsible adult (or at least like someone who owns a checklist)

Before executing any commands, decide the following:

Define the source and destination accounts

• Source account ID (where the original AMI lives)
• Destination account ID (where you want the AMI to exist)

Also confirm the AWS regions involved. Cross-account AMI copying is often discussed with cross-region copying too. You can do one without the other, but real life tends to involve both.

Decide the strategy: share-then-copy vs direct copy

• Share-then-copy: In the source account, share the AMI with the destination account. Then in the destination account, copy the shared AMI into the destination account’s AMI catalog.
• Direct copy: In some workflows, you can copy an AMI directly if you have the right access to the source resources. Depending on the setup, “direct copy” is not as straightforward when permissions and encryption rules are strict.

For most teams, share-then-copy is the calm, predictable approach.

Inventory the AMIs you’re migrating

Make a list. Include:

• AMI ID(s)
• AWS Recharge Region(s)
• Whether they’re encrypted
• Associated KMS key ID(s) (if customer-managed encryption)
• AWS Recharge Any specific instance type or OS constraints you rely on

If you skip this step, you’ll find out later—usually during launch testing—that one AMI was “almost the same” but not actually the same. That’s when you learn new emotions.

Identify encryption details (KMS is the usual plot twist)

For EC2 EBS-backed AMIs:

• If snapshots are encrypted with AWS-managed keys (or default encryption), the story is simpler.
• If snapshots are encrypted with a customer-managed KMS key, the destination must be allowed to decrypt (or AWS must be allowed to copy and re-encrypt appropriately).

Without the correct KMS key policy, the AMI might appear shareable but fail to copy, or fail during instance launch.

Prerequisites: IAM permissions and KMS key policies

Now that we know what we’re moving, let’s ensure AWS won’t block us with a polite but firm “No.”

IAM permissions needed (high-level)

Typically, you’ll need:

• In the source account: permission to modify AMI launch permissions (or to share AMIs), and ability to describe AMIs and snapshots.
• In the destination account: permission to copy images, describe available images, and create new AMIs.
• For encrypted snapshots: KMS permissions for decrypt (on the source KMS key) during copying, and KMS permissions for use in the destination if re-encrypting.

You can grant these via roles (recommended) or via user policies (workable but less elegant). The most important part is that the principal performing the copy has the required permissions.

KMS key policy: the “let them decrypt” moment

If the AMI’s snapshots are encrypted with a customer-managed KMS key, you must update that key policy so the destination account (or the specific role used to perform the copy) can decrypt. In KMS-speak, the principal needs permission for actions such as decrypt and create grant (depending on the situation).

Common failure pattern: teams share the AMI launch permissions but forget to allow the destination account to use the source KMS key for decrypt. The copy then fails with errors that look like “You are not authorized to perform kms:Decrypt” or similar.

Another failure pattern: teams allow decrypt but not through the correct principal (for example, allowing an account root but your copy is done by a specific IAM role in the destination). You want to align the KMS policy principals with the actual role ARN that AWS uses for the copy action.

Step-by-step: share an AMI from the source account

Let’s start with the share-then-copy workflow. The goal is to make the AMI available to the destination account.

1) Confirm the AMI is present and identify its region

In the source account, open EC2 in the AWS console and verify the AMI exists in the intended region. If you have multiple regions, be aware that AMI IDs are region-scoped.

If you prefer CLI: the idea is to describe the AMI and confirm its details, including encryption-related hints. (You may need to inspect snapshots to see which KMS key is used.)

2) Share the AMI by enabling launch permissions

In the EC2 console, you typically modify the AMI’s launch permissions to include the destination account ID. In CLI terms, you’re setting launch permissions so that instances can be launched (or copied) from that AMI by the destination account.

The key here is: you’re not granting snapshot access directly—you’re allowing the destination account to use the AMI as a source.

3) Verify sharing worked (and that you didn’t share the wrong thing)

After modifying launch permissions, re-check the AMI permissions and confirm the destination account ID appears in the list.

Also confirm you didn’t accidentally share a staging AMI (a common “oops” scenario when teams create multiple versions during bake workflows).

Step-by-step: copy the AMI into the destination account

Once the destination account can access the AMI, it can copy it into its own AMI catalog. This is where encrypted snapshot and KMS key policies often show their teeth.

1) In the destination account, locate the shared AMI

In the destination account’s EC2 console, the AMI may appear under “Owned by me” or “Shared with me,” depending on how AWS surfaces it. You should be able to see the AMI metadata.

If the AMI doesn’t show up: revisit the source account sharing step and confirm launch permissions are correct.

2) Use “copy AMI” (same region or different region)

Now choose the AMI and start the copy operation. You’ll select a destination region (if different) and optionally specify encryption behavior, including whether the destination should use its own KMS key.

For cross-account migration, the usual best practice is to copy into the destination account and re-encrypt using a destination-managed KMS key. This reduces future coupling to the source account’s KMS configuration.

3) Choose destination-side KMS settings carefully

When copying encrypted AMIs, you often specify a KMS key in the destination account for re-encryption. If you don’t specify properly, you may be forced to use the source KMS key (or you may run into permissions issues if AWS cannot handle the encryption workflow you requested).

So, for sanity:

• Create or identify a KMS key in the destination account appropriate for AMI snapshot encryption.
• Ensure the role performing the copy has permissions to use that destination KMS key.
• Ensure the source KMS key policy allows decrypt for the copy operation.

AWS Recharge Yes, that’s two keys. Yes, it’s annoying. No, it’s not negotiable if encryption is involved.

4) Monitor the copy task and wait for completion

AMI copies take time because snapshots have to be copied or their data has to be made accessible. During this phase, it’s tempting to keep retrying commands like a caffeinated squirrel.

Better approach: wait, check the AMI copy state, and confirm there are no error messages. If the copy fails, AWS usually gives a clue: either KMS permissions or source AMI access. Treat that clue as a breadcrumb, not as decorative text.

Handling the common failure modes (a.k.a. how to not lose your weekend)

Let’s list the usual ways cross-account AMI migration goes sideways, and what to do about each.

Failure mode 1: “The AMI is shared, but the copy fails”

This often indicates snapshot encryption and KMS policy issues. Launch permissions alone didn’t make the underlying encrypted snapshots usable.

Fix checklist:

• Identify the KMS key used to encrypt the AMI’s backing snapshots in the source account.
• Update that KMS key policy to allow decrypt for the destination principal performing the copy.
• Confirm your destination principal is the one actually used during the copy operation (role ARN alignment).
• Retry the copy.

Failure mode 2: “AccessDenied” for KMS actions

If your error mentions kms:Decrypt (or similar), your KMS policy doesn’t allow the necessary action.

Fix checklist:

• Ensure the KMS key policy includes decrypt for the destination account or specific role.
• Confirm the policy isn’t blocked by other constraints (for example, overly restrictive principals).
• Verify any conditions in the KMS policy match the actual call context.

Failure mode 3: “The AMI copies but launches fail”

Sometimes the AMI copy completes but instance launch fails afterward. This usually means the new AMI references snapshots that are not encrypted with a key that the launch role can use, or the instance role lacks KMS permissions.

Fix checklist:

• Confirm the destination KMS key used for the copied snapshots is correct.
• Ensure instance launch roles (and any required roles) have permissions to use that KMS key.
• Test launch with a minimal instance role to isolate the problem.

Failure mode 4: “Snapshots didn’t copy the way we expected”

AWS Recharge Even if everything is “mostly” correct, you may discover later that:

• Some snapshots exist in the destination but not all were copied
• The copied AMI includes additional volumes you didn’t plan for
• The AMI’s block device mappings don’t match your expectations

Fix checklist:

• Compare source AMI and destination AMI metadata (block device mappings).
• List snapshots associated with both AMIs and ensure counts match.
• Launch a small test instance to validate boot and disk availability.

Validation: how to prove your migration didn’t quietly lie to you

Validation is where you earn confidence and avoid “it worked in the console” syndrome.

Validate AMI metadata

Check in the destination account:

• AMI architecture (x86_64 vs arm64)
• Virtualization type
• Root device type and size
• Block device mappings

If you use EC2 Image Builder or bake pipelines, metadata should match closely. If it doesn’t, investigate before launching production instances.

Validate snapshot encryption and key ownership

Confirm that the snapshots referenced by the destination AMI are encrypted and owned by the destination account (or are decryptable with the destination keys). If you’re following the best practice of re-encrypting with destination KMS keys, verify that the snapshots show the expected KMS key IDs.

Launch a test instance and actually use it

Security and reliability folks love to say “validate” while meaning “stare at a green checkmark.” Try something more real:

• Launch a small instance from the destination AMI
• Confirm OS boots
• Confirm disks mount correctly
• Verify application-level checks if applicable (at least basic service startup)

AWS Recharge This catches subtle issues like wrong boot configuration or missing drivers. It also catches the amusing case where the AMI name suggests a Linux distribution but actually boots a different one. AWS won’t judge you, but your team will.

Operational considerations: naming, versioning, and rollback

Cross-account migrations are usually not one-and-done. They repeat, they evolve, and sometimes they need rollback when someone decides that “latest” wasn’t really latest.

Naming and tagging: treat AMIs like production artifacts

In the destination account, ensure AMIs are tagged appropriately. Common tagging conventions:

• Source AMI ID
• Application name and environment
• Build pipeline version or timestamp
• Owner/team

Tags become your breadcrumbs later when someone asks, “Which AMI did we use last time?” and you want the answer to be more than a shrug.

Versioning strategy

Decide whether you:

• Copy every AMI build with unique IDs (recommended)
• Maintain an “approved” alias (like a mapping in your deployment tooling)

There is no “correct” approach, but there is definitely an approach that avoids chaos: consistent identifiers and predictable selection in deployment workflows.

Rollback basics

Rollback in AMI migrations usually means:

• Keep the previous destination AMI version available
• Update deployment configs back to the old AMI if needed

If you delete old AMIs too aggressively, rollback becomes “re-copy from source,” which is basically a delay disguised as a strategy.

Security best practices (so you can sleep)

Security is not a vibe. It’s a set of guardrails. Cross-account sharing and KMS permissions can become dangerous if handled sloppily.

Prefer least privilege IAM roles

Instead of granting broad permissions to whole accounts, use roles and scope policies to only what’s needed:

• AWS Recharge Limit AMI actions to specific resources if possible
• Limit KMS actions to the required keys
• Avoid wildcard KMS permissions unless you’re forced by legacy constraints

Limit AMI sharing scope

When sharing AMIs, only grant launch permissions to the destination account(s) that require it. Remove sharing after copying if you don’t need continued access. This reduces the “long-term exposure window.”

Re-encrypt into destination-owned KMS keys

Even if you can leave snapshots encrypted with the source key, re-encrypting into destination-owned keys is usually cleaner:

• Less coupling to source account KMS policies
• Clearer ownership and auditing
• Simpler lifecycle management in the destination environment

Putting it together: a practical migration playbook

AWS Recharge Here’s a concise, end-to-end playbook you can follow without inventing new steps out of frustration.

Playbook step 1: Gather info

• List AMI ID(s) in source account
• Confirm region(s)
• Identify whether snapshots are encrypted and which KMS key(s) are used
• Identify destination KMS key to use for re-encryption (create if needed)

Playbook step 2: Update source account permissions

• Modify AMI launch permissions to include destination account
• Ensure any required KMS key policies allow decrypt by the destination principal performing the copy

Playbook step 3: Copy in destination account

• Locate shared AMI
• Start copy into destination AMI catalog
• Specify destination KMS key for encryption if re-encrypting
• Wait for copy completion

Playbook step 4: Validate by launching

• AWS Recharge Launch test instance from copied AMI
• Confirm OS boot and storage availability
• Verify application/service basics if applicable

Playbook step 5: Cleanup and governance

• Remove AMI sharing permissions if no longer needed
• Keep previous AMI versions for rollback
• Tag destination AMIs with metadata for future audits

Frequently asked questions (because everyone has the same questions at the worst times)

Do I need to share snapshots separately?

Usually, no. You typically share the AMI launch permissions and ensure KMS decrypt permissions are in place. During the copy operation, AWS handles snapshot copying or access based on the permissions and encryption configuration. If your workflow involves direct snapshot manipulation, then you might deal with snapshot sharing directly, but most AMI copy flows don’t require you to manually share snapshots.

Can I copy an AMI between accounts without re-encrypting?

Sometimes you can, but it’s not always desirable. If you leave snapshots under the source KMS key, you maintain coupling to the source account’s KMS configuration. Re-encrypting with a destination-managed KMS key is typically cleaner for operations and security boundaries.

What if the AMI is public?

Public AMIs may simplify sharing requirements, but encryption and KMS permissions can still complicate matters if the AMI uses encrypted snapshots with customer-managed KMS keys. In those cases, you still need to ensure the destination account can decrypt or otherwise access what’s required to copy and launch.

Does this work for both Linux and Windows?

Yes. The underlying EC2 mechanics are the same: AMIs reference EBS snapshots and encryption settings. The difference is in what your OS does on first boot, not in how the image is transported between accounts.

A final note: automate after you succeed manually

It’s tempting to jump straight into automation because humans are allergic to repetitive work. However, automation is most reliable once you’ve succeeded manually at least once and verified the result with a test instance. After that, you can codify the process using scripts, Infrastructure as Code, or pipeline steps.

The goal is to turn this from “tribal knowledge that lives in one person’s brain” into “a repeatable procedure your team can run without summoning the AccessDenied spirit.”

Conclusion: cross-account image migration, demystified

AWS EC2 cross-account image migration is essentially a permissions and encryption puzzle wrapped in an image copy workflow. If you:

• Share the AMI with launch permissions to the destination account
• Handle KMS key policies for encrypted snapshots
• Copy the AMI into the destination account (preferably re-encrypting with destination KMS)
• Validate by launching a test instance

…then you’ll have a smooth migration instead of a dramatic failure story you tell at meetings for sport.

And if it still fails? Congratulations—you’re learning the one AWS lesson that never goes out of style: trust errors as breadcrumbs, not as insults. Follow the breadcrumbs, fix the permissions, and eventually your AMI will land in the right account like a well-delivered package.