WARNING

This page has not been translated yet and is shown in English. A localized version is coming soon.

Amazon EC2 as a source

This guide covers migrating instances out of Amazon EC2 into an Awanio target:

• a single KVM/libvirt host managed by Awanio Vapor;
• a host fleet managed by Awanio Cockpit;
• an Awanio CEP site (KubeVirt).

The target side of the wizard is the one described in VMware to Vapor, VMware to Cockpit and VMware to CEP. Everything that differs is on the source side and is described here.

An EC2 instance migrates cold, from a snapshot of its EBS volumes. Warm migration is not available for an AWS source yet.

Before you start

• Sign in to Condensa from the overview.
• Add the target provider first — Vapor, Cockpit or CEP.
• Have an IAM user for Condensa with the policy below, and an access key for it.
• Have outbound HTTPS (port 443) from the Condensa host to AWS in the instance's region.
• For a Vapor or Cockpit target, install qemu-img with its HTTP driver on the Condensa host: sudo apt install qemu-utils qemu-block-extra.
• For a CEP target, set CONDENSA_PUBLIC_URL to an address the site's cluster can reach. See A CEP target fetches the disk from Condensa.
• Read What AWS bills — every migration moves its disks out of AWS.

How the disk moves

1. Condensa takes a snapshot of every EBS volume of the instance. The instance keeps running.

2. Condensa reads each snapshot through the EBS direct APIs. What happens next depends on the target:

   • Vapor or Cockpit — Condensa writes the disk straight into the target's storage, over an encrypted, short-lived channel.
   • CEP — the site's importer fetches the disk from Condensa over HTTPS, with a link valid only for that disk of that migration. Condensa reads each block from the snapshot as the site asks for it.

   Either way, the disk is never staged on Condensa, so Condensa needs no scratch space.

3. Condensa creates the VM on the target and, if you asked for it, starts it.

4. Condensa deletes the snapshots. This happens whether the migration succeeds, fails or is cancelled. If Condensa restarts during a migration, it deletes them when it comes back up.

Every snapshot carries the tag condensa:migration with the migration's number, so you can find any that remain in the EC2 console under Snapshots.

The copy is crash-consistent

The snapshot captures the volume at one instant while the instance runs. The migrated guest boots and recovers its filesystems as it would after a power loss. Changes made on the instance after the snapshot are not migrated.

For a fully consistent copy, stop the instance in the EC2 console before you start the migration, and keep it stopped until the migration finishes. Condensa does not stop or start the instance itself.

What AWS bills

Moving a disk out of AWS is billed

AWS bills the account for:

• Data transfer out, for the full size of every volume. Blocks that hold only zeros count too: an 8 GiB volume costs 8 GiB of transfer even when the guest uses 2 GiB.
• EBS direct API requests: one GetSnapshotBlock request per 512 KiB of volume, which is 2,048 requests per GiB.
• Snapshot storage, for as long as the snapshots exist. Condensa deletes them when the migration ends.

A retry after a failed transfer reads the disks from AWS again, and is billed again.

The wizard shows the amount for the selected instances on the VM step and again on Review. The migration log repeats it when each instance starts, and records the bytes actually read when it ends. Prices depend on the region: see AWS's pricing for data transfer and EBS direct APIs.

Create an IAM user for Condensa

Give Condensa an IAM user of its own, allowed only what a migration needs. Never use the account's root keys.

1. In the AWS console, open IAM → Users → Create user. Give it a name such as condensa, and leave console access off.

2. On the permissions step, choose Attach policies directly, then create an inline policy from this JSON:

   {
     "Version": "2012-10-17",
     "Statement": [
       {
         "Sid": "CondensaEC2",
         "Effect": "Allow",
         "Action": [
           "ec2:DescribeInstances",
           "ec2:DescribeVolumes",
           "ec2:DescribeInstanceTypes",
           "ec2:DescribeSnapshots",
           "ec2:CreateSnapshot",
           "ec2:DeleteSnapshot",
           "ec2:CreateTags"
         ],
         "Resource": "*"
       },
       {
         "Sid": "CondensaEBSDirect",
         "Effect": "Allow",
         "Action": [
           "ebs:ListSnapshotBlocks",
           "ebs:ListChangedBlocks",
           "ebs:GetSnapshotBlock"
         ],
         "Resource": "*"
       }
     ]
   }

3. Open the new user, go to Security credentials → Create access key, and choose the use case for an application running outside AWS.

4. Copy the Access key ID and the Secret access key. AWS shows the secret only once.

ec2:DescribeInstanceTypes is required: an instance's memory size comes from its instance type, and Condensa does not create a VM whose memory it does not know.

Encrypted volumes

An encrypted EBS volume is read through its KMS key. Also allow the IAM user kms:Decrypt on that key. For a customer-managed key, the key's own policy must permit it too.

Add the AWS provider

One AWS provider covers one region of one account. Add a provider per region you migrate from.

Click the Provider tab, then Add Provider. In the form:

1. Vendor — choose Amazon EC2.
2. Name — a display name (e.g. AWS Singapore). Add an optional Label to tell apart several AWS providers, and an optional Description.
3. Region — the region code, e.g. ap-southeast-1 (Singapore) or ap-southeast-3 (Jakarta).
4. Access key ID and Secret access key — from the IAM user above. Both are stored encrypted.
5. Click Create Provider, then Test Connection on the new card. The test checks the key and that it may list the region's instances. When AWS refuses, the result lists the permissions the IAM user needs.

A CEP target fetches the disk from Condensa

This section applies only to a CEP target. Vapor and Cockpit targets do not fetch anything from Condensa.

A CEP site imports each disk itself, from Condensa's public URL. Two things must hold for that to work.

The site must reach Condensa. Set CONDENSA_PUBLIC_URL on the Condensa server to an address the site's cluster nodes can reach, for example:

CONDENSA_PUBLIC_URL=https://condensa.example.com:8080

Condensa refuses to start the migration when the URL is not set.

The site must trust Condensa's certificate. Condensa checks this before it takes any snapshot. It uses the first of these that applies:

1. Publicly trusted certificate — nothing to do.

2. The certificate travels with the request — when Condensa serves its own certificate, such as the one it generates itself, it hands that certificate to the site with each disk. This needs a CEP platform that accepts a certificate with the request; current platforms do.

3. Trusted source CA ConfigMap — for an older platform, create a ConfigMap on the target cluster, in the organization's namespace (the organization UUID), holding Condensa's CA under the key ca.pem:

   kubectl -n <organization-uuid> create configmap trusted-source-ca --from-file=ca.pem=condensa-ca.crt

   Then enter its name in Trusted source CA ConfigMap on the target CEP provider. This is the same field CEP-to-CEP migrations use; see Awanio CEP as a source.

When none of these applies, the start is refused and the message says which one is missing. Nothing has been snapshotted at that point, so nothing has been billed.

Create the migration

Click the Migrations tab, then Create Migration.

Step 1 — Basic info and target

Fill in the Migration Name and choose the Target Provider. Then fill in the fields for that target:

• Vapor — the Target Storage Pool.
• Cockpit — the Target Host and the Target Storage Pool.
• CEP — the Target Organization and, optionally, the Target Project. There is no storage pool to choose; the disks go to the organization's storage.

These fields behave exactly as in the VMware guides.

Step 2 — Source provider

Select the Amazon EC2 provider. There is no datacenter to pick; Condensa lists every instance in the provider's region.

Step 3 — Select instances and map networks

Pick one or more instances. Each row shows the instance's state, vCPUs, memory and volumes, and a Snapshot pill: the instance is copied from a snapshot whether it is running or stopped. A box above the table shows what AWS will bill for the selection.

Some instances cannot be selected. The reason appears under the row:

Shown	Why
Arm64 guest	A Graviton instance runs an operating system built for Arm, which cannot run on an x86 target.
No EBS volume	The instance has no EBS volume, so there is no disk to migrate.

Some rows carry a note instead and can still be migrated:

• Encrypted volume — the IAM user needs kms:Decrypt on its key (see above).
• Instance-store disks — these live on the AWS host and are not migrated; only EBS volumes move.
• Windows with license included — a Windows license included in the EC2 price does not move with the disk; the target needs its own license.

If an instance's memory shows as unknown, the IAM user lacks ec2:DescribeInstanceTypes, and creating the migration is refused until it has it.

Under each instance, the Networks block lists the subnet of each of its interfaces (subnet-…). Map each one to the target network that interface should join, or to No NIC for this interface to leave it off. An instance with no mapped interface arrives without a network, and you can attach one on the target later.

On a CEP target, Create default network also attaches the site's pod network, which holds the guest's default route.

Step 4 — Review

Check the target, the networks, and what AWS will bill, then click Create Migration.

What arrives on the target

• vCPUs and memory of the instance type.
• Firmware — UEFI or BIOS, as the instance booted on EC2.
• Every EBS volume, root first, attached on SATA. Every Linux distribution's initramfs carries the SATA driver, so the guest finds its root device without a conversion step.
• Every network interface that you mapped, on virtio, each with its EC2 MAC address kept.
• The VM name is the instance's Name tag, or its ID when it has none, after any prefix you set.

The guest's own network configuration may still expect the EC2 environment. On first boot, cloud-init looks for the EC2 metadata service, which the target does not have. On a CEP target it runs the document Condensa sends instead, which keeps the guest's SSH host keys and leaves password SSH as the guest had it; see Awanio CEP as a source. Check the guest's network and any EC2-specific agents after the first boot.

Tested guests

Ubuntu 24.04 (UEFI) is tested on Vapor, Cockpit and CEP targets and reaches its login prompt on each. Windows guests are not tested yet: they need virtio drivers for the network interface, and EC2's license-included Windows does not move with the disk.

Start and monitor the migration

1. Open the action menu (three dots on the right of the row) and select Start Migration.
2. The status changes to Running. The log shows the snapshot's progress, then the copy of each disk. The instance's data plane reads Cold · From EBS snapshot.
3. On completion the status becomes Success. Click the migration name for per-disk detail and the log, including the amount read from AWS.

A failed migration can be restarted from the same action menu with Retry. It starts a fresh attempt, takes new snapshots, and is billed again.

Size and time remaining

While data is being copied, the Migrations table shows a line under the progress bar, for example 12.4 GiB of 40.0 GiB · 14 min left. The detail view shows Copied, Remaining, Speed, Time remaining, Estimated finish and Estimated total duration, and each disk shows its own copied amount, speed and time left. The CEP guide explains each field.

• While Condensa takes the EBS snapshots, only the percentage and the phase are shown.
• On a Vapor or Cockpit target, a disk's total is the data its snapshot stores, which is smaller than the disk: blocks the instance never wrote are not read. On a CEP target, the figures cover the whole disk.

What must reach what

Target	From	To	Why
Any	Condensa	AWS EC2 and EBS endpoints of the region (443)	Inventory, snapshots, and reading the disks
Vapor or Cockpit	Condensa	The target host, on its migration port range	Writing the disk into the target's storage
CEP	Condensa	The site's API (443)	Asking the site to import each disk, and creating the VM
CEP	The site's cluster nodes	Condensa, at CONDENSA_PUBLIC_URL	Fetching each disk

The target never needs to reach AWS.

For a Vapor or Cockpit target, Condensa needs no public address. The target opens its disk intake on a port from a configurable range. On Vapor 3.0.2 and later, set the range under Host → System → Migration (on each host of a fleet), and permit that range from the Condensa host to the target host. If Condensa cannot reach the address Cockpit knows a host by, set the target provider's Disk stream address to one it can.

Verify on the target

Vapor or Cockpit — open the target host's dashboard and go to Virtualization. Confirm the migrated VM is present and running.

CEP — open the site's console and find the VM in the target organization. Confirm it is running.

Then check inside the guest that the network you mapped came up.

The EC2 instance is left exactly as it was, still running or stopped. Stop or terminate it yourself once you are satisfied with the migrated VM.

For credit-based licensing and how migrations consume credits, see Licensing.