Este artículo describe el proceso para mover una instancia desde una VPC (red privada virtual) a otra en AWS.

AWS no permite mover una instancia entre VPCs sino que se deben crear instancias nuevas a partir de snapshots. Por esta razón el procedimiento consiste en apagar la instancia; crear un snapshot y AMI (imagen de máquina virtual); y finalmente levantar una nueva instancia a partir del snapshot en la otra VPC.

Crear snapshot y AMI

Para comenzar, apagar la instancia:

root@debian:~# poweroff
root@debian:~# Connection to 192.168.34.61 closed by remote host.
Connection to 192.168.34.61 closed.

Desde la consola de EC2, acceder a "Snapshots" y crear una instantánea fresca de la instancia apagada:

Esperar que finalice el snapshot (cambio de estado "pending" a "completed"). Luego seleccionar el snapshot y acceder a "Actions > Create Image":

Crear una AMI a partir del snapshot y esperar que finalice.

Crear la nueva instancia

Mientras tanto, desde la lista de instancias, renombrar la instancia original (para diferenciarla y eliminarla luego) y presionar "Save".

Al finalizar la creación de la AMI, lanzar una nueva instancia a partir de la misma desde el menú "AMIs" presionando "Launch". Seleccionar el mismo tipo de instancia (en la medida que sea posible). En este caso se trata de una instancia "t3.small".

Luego configurar la VPC y subred:

En el paso 6, seleccionar el grupo de seguridad creado junto con la nueva VPC:

Finalmente, crear o seleccionar una clave de acceso SSH.

Esperar que finalice la creación de la nueva instancia...

Reconfigurar la IP elástica

Si la instancia tenía asociada una IP elástica, el siguiente paso consiste en asociarla a la nueva instancia. Desde la consola de EC2, acceder a "Elastic IPs". Seleccionar la IP correspondiente a la instancia y abrir el menú "Actions > Associate Elastic IP address".

Elegir la nueva instancia:

Seleccionar la dirección IP privada asignada a la nueva instancia en la nueva subred:

Permitir que la IP elástica sea reasociada (siempre es recomendable permitir la reasociación, justamente para estos casos).

Verificar el acceso por SSH

Al intentar acceder por SSH falla, ya que se trata de una nueva instancia:

emi@vaio:~$ ssh debian
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the ECDSA key sent by the remote host is
SHA256:xxxx.
Please contact your system administrator.
Add correct host key in /home/emi/.ssh/known_hosts to get rid of this message.
Offending ECDSA key in /home/emi/.ssh/known_hosts:146
  remove with:
  ssh-keygen -f "/home/emi/.ssh/known_hosts" -R "[192.168.34.61]:22"
ECDSA host key for [192.168.34.61]:22 has changed and you have requested strict checking.
Host key verification failed.

Eliminar el viejo fingerprint borrando la línea 146 del archivo ~/.ssh/known_hosts:

emi@vaio:~$ ssh-keygen -f "/home/emi/.ssh/known_hosts" -R "[192.168.34.61]:22"

Volver a intentar el acceso:

emi@vaio:~$ ssh debian
The authenticity of host '[192.168.34.61]:22 ([192.168.34.61]:22)' can't be established.
ECDSA key fingerprint is SHA256:zzzz.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '[192.168.34.61]:22' (ECDSA) to the list of known hosts.
Linux ip-192-168-34-61 4.19.0-13-cloud-amd64 #1 SMP Debian 4.19.160-2 (2020-11-28) x86_64

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Thu Dec 10 12:47:09 2020 from 181.197.199.132
webmaster@ip-192-168-34-61:~$

Finalmente cambiar el hostname.

Backup

Si la instancia tiene configurados planes de backup por ID de instancia, es necesario reconfigurarlos. Acceder a la consola de AWS Backup, abrir el plan de backup y bajar hasta "Resource assignments".

Borrar la regla existente y volver a crearla replicando los parámetros de la regla anterior.

DNS

Para finalizar, migrar el/los registro/s DNS correspondientes a la nueva zona de Route 53.

Referencias

Compartí este artículo