Skip to content
Get started

Move Encrypted EC2 Across Regions Without Breaking Compliance

Jacob Heinz
Jacob Heinz |

You don’t need to share KMS keys across Regions to move encrypted EC2—copy, re-encrypt, launch.

Here’s the nightmare. You need to move EC2 to another Region, and it’s all encrypted. KMS keys, EBS volumes, snapshots, the whole thing. Compliance hawks circling overhead. One wrong move and you’re writing a post‑mortem no one wants.

Here’s the relief. AWS gives you clean ways to move encrypted stuff across Regions without sharing KMS keys. You pick the lane, re‑encrypt in the target, and keep auditors calm.

If you’re a solutions architect at a big retail shop that’s migrating, this is your playbook. We’ll cover AWS MGN for minimal downtime, AMI and snapshot copy for stateless fleets, AWS Backup for policy‑driven DR, and how AWS Nitro handles in‑transit encryption by default.

The punchline: plan your KMS setup before you copy a single byte. Everything else gets predictable.

One more thing before we dive in. Migrations feel scary because they mix speed with risk. The win is to break it into repeatable steps, test every assumption, and log everything. You’re not just moving servers—you’re proving control.

  • TL;DR
  • Use AWS MGN for “lift‑and‑shift” with minimal downtime. It encrypts in transit and supports EBS encryption at rest in the target Region.
  • Copy encrypted AMIs or EBS snapshots across Regions and re‑encrypt with a KMS key in the destination—no key sharing required.
  • AWS Nitro provides encryption in transit between EC2 and EBS when EBS encryption is enabled.
  • Design KMS: create destination keys, set policies/grants, log with CloudTrail, and validate IAM least privilege.
  • For compliance, automate evidence with AWS Config rules, CloudTrail, and AWS Backup reporting.

What encrypted and compliant means

At rest vs in transit

“AWS EC2 encryption at rest” means EBS volumes, snapshots, and AMIs use KMS keys. When you copy an encrypted EBS snapshot to another Region, AWS decrypts it in the source Region with the source key, then re‑encrypts it with a KMS key you pick in the destination Region. You never expose the source key or share key material.

“In transit” is handled by the AWS Nitro System for Nitro‑based instances. With EBS encryption on, Nitro encryption in transit protects data moving between EC2 and EBS automatically. You focus on picking the right keys and policies—Nitro handles the wire.

Add a couple practical notes:

  • Encryption by default: Many accounts enable EBS encryption by default. That means any new volume and any snapshot or AMI you create will be encrypted unless you override it. With that default on, your copy and launch flows inherit encryption without extra clicks.
  • Snapshot lineage: A snapshot copied to another Region is a new snapshot with its own ID and its own KMS key in that Region. Treat it like a new asset with its own lifecycle, tags, and retention.
  • Access context: The service doing the copy needs permission to use the source key to decrypt in the source Region and permission to use the destination key to encrypt in the target Region. You don’t move keys; you allow specific actions.

KMS keys are regional

KMS keys are Regional resources. That’s a feature, not a bug. Instead of sharing keys, copy encrypted artifacts and re‑encrypt in the target Region. If you need consistent crypto identities across Regions, consider KMS multi‑Region keys. Those are distinct keys in each Region that are cryptographically equivalent and built for cross‑Region use.

Werner Vogels said it best: “Dance like nobody’s watching; encrypt like everyone is.” Assume someone will ask you to prove the encryption story end to end.

Helpful docs: EC2 EBS encryption and AMI or snapshot copy behavior; KMS multi‑Region keys.

And a quick MRK sanity check:

  • MRKs don’t “replicate” key material like a database. AWS creates related keys in different Regions that are designed to work together.
  • You still enforce Region‑level blast radius. Rotate keys on your schedule, and document who can create grants and aliases in each Region.
  • Use MRKs when apps or logs need the same key ID semantics across Regions, like dedup or signature checks. For most EC2 or EBS moves, a standard customer managed key per Region is plenty.

Pick your migration lane

AWS MGN

AWS Application Migration Service (AWS MGN) replicates your servers into a staging area in the destination Region over TLS. You can configure EBS encryption at rest for staging and for the final launched instances using an AWS managed key or a customer managed key in the target Region. MGN handles block‑level replication, test launches, and cutover with minimal downtime.

Use this when you can’t handle long maintenance windows or you’re moving complex, stateful workloads that don’t love being baked into AMIs.

How to make MGN predictable:

  • Before replication: Pre‑create the destination KMS keys and aliases you want MGN to use. Confirm the MGN service has permission to use those keys for Encrypt and Decrypt as needed.
  • Staging area: Choose instance profiles, subnets, and security groups in the target Region that match production closely. Encrypt staging disks too—compliance will ask.
  • Test launches: Use them. Boot replicas in an isolated subnet, run health checks, and confirm bootstrapping and app secrets retrieval, like from SSM Parameter Store using KMS, work.
  • Cutover: Plan a short freeze, sync the delta, and flip traffic. Keep rollback steps ready in your runbook.

Pitfalls to avoid:

  • Skipping key policy updates. If the MGN service‑linked role can’t use your CMK, replication or launch might fail late.
  • Forgetting to tag replicas. Without tags, your cost and audit views get messy fast.
  • Under‑sizing replication servers or staging disks, causing backlog and long catch‑up windows.

AMI snapshot copy

If your app is stateless or easy to rehydrate, copy the encrypted AMI to the target Region. During the copy, select a KMS key that lives in the destination Region. AWS decrypts with the source key in the source Region, re‑encrypts with the destination key, and hands you a Region‑local AMI. Launch and go.

This path is simple, scriptable, and pairs well with IaC and EC2 Image Builder pipelines.

Make AMI copy a one‑button move:

  • Clean images: Bake images that include only what you need. Smaller AMIs copy faster and restore faster.
  • Launch templates: In the target Region, create or update launch templates to reference the new AMI ID and the right KMS key alias for new EBS volumes.
  • Permissions: If the source AMI is encrypted with a customer key, make sure the account doing the copy has permission on that key to use it for the copy. Same story in the destination with the destination key.
  • Validate boot: After copy, launch a small instance and verify userdata runs, agents connect, like SSM or CloudWatch, and storage mounts as expected.

Common gotchas:

  • Copying the AMI but forgetting parameters or secrets, like Parameter Store SecureStrings using a different key alias in the new Region. Map those dependencies.
  • Assuming old AMI IDs work in other Regions. They don’t. Treat AMI IDs as Region‑scoped.

AWS Backup

AWS Backup can copy backups across Regions on a schedule, enforce backup policies, and use Backup Vault Lock for immutability. For EC2 or EBS, it creates restorable images and volumes in the destination Region, encrypted with the KMS key you choose there. Great for DR readiness and audit trails.

Real‑world example: you’re moving retail catalog services across Regions. For the payment gateway, which is stateful, you pick AWS MGN. For the stateless image resizer fleet, you copy encrypted AMIs. For databases and EFS shares, you use AWS Backup with cross‑Region copy and vault lock.

To get the most from AWS Backup:

  • Centralize policies: Use backup plans to define frequency, lifecycle, and cross‑Region copy rules. Tag resources so policies catch new workloads automatically.
  • Vault Lock: Enable it to enforce write‑once, read‑many controls. This helps satisfy immutability and retention requirements.
  • Reporting: Turn on built‑in compliance reports so you can show coverage, last successful backup, and copy status during audits.

Design the KMS plan

Keys in the target Region

Decide your KMS key strategy up front. Options:

  • AWS managed key, aws/ebs: easiest, good for many workloads.
  • Customer managed key: needed when you want custom rotation, grants, key policies, and strict access boundaries.
  • KMS multi‑Region keys: keep crypto continuity across Regions without moving key material.

Use clear aliases per environment and Region, like alias/prod‑ebs‑usw2. Document which services can use which keys and why.

Add a naming rubric you can live with:

  • Alias: alias/-- (example: alias/prod‑payments‑use1)
  • Key policy comments: why this key exists, which services use it, and who owns it.
  • Tags: Environment, DataClassification, Owner, RotationOwner, and Ticket or ChangeID for migration traceability.

Policies grants and org guardrails

Write explicit key policies that allow needed principals to use the key for encryption and decryption, including service‑linked roles, like MGN, Backup, or EC2 copy operations. Use least privilege with IAM, and prefer KMS grants for time‑bound access during migration.

Add organization‑level guardrails. Service Control Policies to restrict Regions, CloudTrail to log every KMS API call, and AWS Config rules to flag unencrypted EBS volumes and snapshots.

Helpful refinements:

  • Grants vs policy edits: use KMS grants for short‑lived permissions, like a migration automation role. They’re easy to revoke and audit.
  • Endpoint policies: if you use VPC interface endpoints for KMS, apply endpoint policies to restrict which principals and which KMS API calls can traverse the endpoint.
  • Separation of duties: keep key admins separate from key users. Admins manage policy and rotation; apps and services use Encrypt and Decrypt.

Validate before cutover

Dry‑run the copy with a non‑production instance. Confirm that:

  • The AMI or snapshot lands encrypted with the destination Region’s KMS key.
  • Launch templates reference the right key alias.
  • CloudTrail shows expected kms:Decrypt and kms:Encrypt events.
  • Instances boot and apps can read any encrypted data they need, like user data secrets via KMS plus SSM Parameter Store.

Also validate:

  • Backup restore: restore a volume or AMI from AWS Backup in the destination Region and boot it. Measure time‑to‑restore.
  • Failure modes: temporarily remove a grant or deny kms:Decrypt to the instance role. Confirm the app fails closed and shows a clear error.
  • Monitoring: alarms on KMS throttling, EBS burst balance, and instance status checks during migration windows.

Halftime cheat sheet

  • Pick the lane by workload: AWS MGN for stateful, AMI copy for stateless, AWS Backup for DR policy and immutability.
  • Never share KMS keys across Regions; copy and re‑encrypt with a destination key.
  • Nitro handles encryption in transit between EC2 and EBS when EBS encryption is on.
  • Pre‑create KMS keys, policies, and aliases in the destination Region.
  • Prove compliance: CloudTrail logs, Config rules, and backup reports.
  • If you google “aws move resources to another region,” you’ll see many paths—these are the safe defaults.

Bonus sanity checks:

  • Map dependencies like Parameter Store or Secrets Manager keys and aliases across Regions.
  • Track AMI and snapshot lineage with tags so you can trace the chain during audits or rollbacks.
  • Keep a cleanup checklist for staging artifacts post‑cutover.

Make the network boring

AWS Nitro encryption in transit

On Nitro‑based instances, enabling EBS encryption ensures data between your instance and EBS volumes is encrypted in transit. Combine that with encryption at rest on volumes and snapshots, and you cover the critical paths. This is one reason Nitro anchors modern EC2 security.

If you still run legacy instance types, check compatibility and plan upgrades. The security and performance gains are worth it.

What to check:

  • Instance families: confirm your instance types are Nitro‑based so you get in‑transit protection when EBS encryption is on.
  • EBS encryption default: turn it on at the account and Region level so every new volume and snapshot follows the rule without manual steps.
  • Benchmark: run basic IO tests before and after enabling Fast Snapshot Restore to understand performance at launch.

Keep calls off internet

Lock down your API paths:

  • Use VPC endpoints, AWS PrivateLink, for KMS so encryption and decryption API calls don’t hit the public internet.
  • Add VPC endpoints for EC2, SSM, and CloudWatch where it makes sense.
  • Route migration traffic over AWS Direct Connect or VPN if you’re replicating from on‑prem and need predictable, private connectivity.

These steps cut attack surface and simplify your compliance story.

Extra credit:

  • Endpoint policies can restrict which IAM roles in which subnets can hit KMS.
  • Use SSM Session Manager for maintenance access to test instances so you can avoid opening SSH during migration.
  • Flow logs: enable VPC Flow Logs on the subnets used for migration to verify traffic stays private.

Throughput quotas and warm reads

Plan for service limits and performance:

  • Snapshot copy and KMS request quotas exist—check and request increases before big moves.
  • Enable Fast Snapshot Restore in the destination Region for critical volumes so instances launch with predictable IO.
  • For MGN, right‑size the replication servers and staging disks to avoid bottlenecks.

Bandwidth, quotas, and pre‑warming often decide whether cutover takes minutes or hours.

More tuning tips:

  • Stagger large snapshot copies to avoid blasting past KMS or EBS API quotas.
  • Use parallelism wisely. A few well‑sized copies beat dozens of tiny, competing jobs.
  • Time your FSR enablement so you’re not paying for idle pre‑warmed snapshots longer than needed.

Prove it

Evidence your auditors will love

Turn on CloudTrail in all Regions and verify it logs KMS and EC2 events. Enable AWS Config rules such as encrypted‑volumes and encrypted‑snapshots to flag drift. For AWS Backup, use built‑in reports and Backup Vault Lock to show immutability and retention compliance.

Come audit time, you want to export reports, not write essays.

Evidence you can export fast:

  • CloudTrail queries showing who did kms:CreateKey, kms:Encrypt, kms:Decrypt, and snapshot copy actions.
  • AWS Backup reports showing last successful backup, cross‑Region copy status, and vault lock compliance.
  • Config compliance snapshots showing all volumes and snapshots are encrypted in the target Region.

Tagging and lineage matter

Tag everything: source Region, destination Region, workload, data classification, and key alias. Capture lineage, like source snapshot ID and new snapshot ID, so you can trace an AMI or volume across Regions. This makes rollback and investigations sane.

Keep an inventory of KMS keys per environment, with who‑can‑use‑what documented. Avoid “mystery keys” that no one wants to rotate.

Useful tag examples:

  • MigrationBatch: 2025‑BlackFriday‑DR
  • SourceRegion: us‑east‑1
  • TargetRegion: us‑west‑2
  • KeyAlias: alias/prod‑ebs‑usw2
  • DataClass: Confidential
  • Owner: retail‑platform

Run a game day

Do a full test. Replicate, launch test instances, run health checks, measure performance, and validate encryption. Practice failure. Revoke a grant and confirm the app fails securely. Document time to restore and your MTTR. Then do it again until it’s boring.

When your runbook feels like muscle memory, you’re ready.

Include in your game day:

  • A mock change window with real stakeholders and paging.
  • A rollback drill: terminate the target, roll back traffic, and restore the source in minutes.
  • A log roundup: gather CloudTrail, Config, and Backup evidence into a single folder for quick review.

FAQ

Move encrypted EC2 without sharing

Yes. Copy the encrypted AMI or EBS snapshot to the destination Region and choose a KMS key in that Region. AWS decrypts with the source key in the source Region and re‑encrypts with the destination key. No key sharing or export required.

Decrypt volumes before copying

No. You copy encrypted snapshots or AMIs as‑is. The service performs decrypt‑then‑re‑encrypt under the hood. You just need permissions to use the source key for the copy and access to the destination Region’s key for encryption.

Lowest downtime option

AWS MGN. It replicates blocks continuously over TLS and supports test launches. At cutover, you stop the source, sync the tail, and boot in the target Region. Use EBS encryption at rest on staging and final volumes to maintain compliance.

EC2 and Nitro encryption

EBS encryption with KMS protects data at rest on volumes and snapshots. On Nitro‑based instances, enabling EBS encryption also encrypts data in transit between the instance and EBS. Together, they cover storage and the data path.

Cross account organization migrations

Create or replicate keys in the destination account and Region. Use KMS key policies and grants to permit copy operations. AWS Backup supports cross‑account, cross‑Region copies with vaults in each account. Multi‑Region keys help keep crypto continuity without sharing material.

Plan for costs

Snapshot storage, cross‑Region data transfer for copies, KMS API requests, Fast Snapshot Restore, and temporary MGN resources. Right‑size replication, compress where possible, and clean up staging artifacts post‑cutover to avoid drift costs.

Need PrivateLink to be compliant

It depends on your controls. Many teams require private API paths for KMS, EC2, SSM, and CloudWatch to prove no control‑plane calls hit the public internet. PrivateLink plus endpoint policies makes that story simple.

Automate all of this

Yes. Use IaC, like CloudFormation or Terraform, for KMS keys, aliases, endpoint policies, and launch templates. EC2 Image Builder for AMIs. AWS Backup policies for DR. And scripted snapshot or AMI copy pipelines. Automation reduces drift and creates repeatable evidence.

Your encrypted EC2 move playbook

  • Pick the migration lane: AWS MGN for stateful, AMI copy for stateless, or AWS Backup for policy and DR.
  • In the destination Region: create KMS keys, aliases, and key policies; enable CloudTrail and Config rules.
  • Set up private access: VPC endpoints for KMS and EC2; confirm SSM connectivity.
  • For MGN: install agent, configure staging area with EBS encryption, start replication, test launch.
  • For AMI or snapshot: copy with “encrypt with destination KMS key”; document source and destination IDs.
  • Enable Fast Snapshot Restore where needed; request quota increases if required.
  • Cut over during a window; validate app health, encryption, and logs; decommission sources.
  • Export evidence: CloudTrail, Config, Backup reports; tag and archive runbooks.

Add a pre‑flight checklist:

  • Keys created and aliases set in target Region
  • Key policies reviewed; temporary grants created as needed
  • Endpoint policies applied; PrivateLink tested
  • Launch templates updated; AMI IDs swapped for target Region
  • Backup plans enabled and reporting on
  • Cost monitors set for snapshots, FSR, and data transfer

Here’s the bottom line: multi‑Region isn’t a science project—it’s process. If you’re deliberate about keys, policies, and logs, moving encrypted EC2 across Regions becomes repeatable, fast, and boring, the good kind. Nitro covers encryption in transit; KMS covers at rest; you cover the paper trail. Start small with a canary workload, prove the flow, then scale it across your fleet. Your future self—and your auditors—will thank you.

References

Share this post

Keep reading