Blog

El comando terraform import nos permite importar en HashiCorp Terraform recursos que ya existían previamente en el proveedor con el que estemos trabajando, es este caso AWS. Sin embargo, sólo permite importar dichos registros uno por uno, con una ejecución de terraform import cada vez. Esto, aparte de ser tremendamente tedioso, en algunas situaciones se vuelve directamente impracticable. Este es el caso de los registros de una zona DNS de Route53. La tarea puede resultar inabarcable si tenemos varias zonas DNS, y cada una tiene decenas o cientos de registros. En este artículo te ofrezco un script en bash que te permitirá importar en Terraform todos los registros de una zona DNS de Route53 en cuestión de segundos o de pocos minutos.

Si tenemos una AMI que no está encriptada podremos compartirla con otra cuenta de forma directa sin hacer nada especial. Pero si la AMI está cifrada, la cosa se complica, ya que la cuenta de destino no dispondrá de la clave de cifrado para poder descifrar sus snapshots y no podremos compartirla.

Por ello, si necesitamos compartir una AMI cifrada de una instancia EC2 de una cuenta a otra en AWS llevaremos a cabo el siguiente procedimiento:

El pasado diciembre Amazon anunció sus nuevos volúmenes EBS gp3, los cuales ofrecen mejores prestaciones y un ahorro en el coste del 20% respecto a los que se venían utilizando hasta ahora, los gp2. Pues bien, tras probar satisfactoriamente estos nuevos volúmenes en varios clientes, no puedo hacer otra cosa más que recomendar su utilización, pues son todo ventajas y en estos 2 meses y medio que han transcurrido desde el anuncio no he apreciado ningún problema ni efecto secundario.

Uno de los mayores fastidios cuando trabajamos con AWS y nuestra conexión a Internet tiene IP dinámica es que cuándo ésta cambia, automáticamente dejamos de tener acceso a todos los servidores y servicios que habíamos protegido mediante un grupo de seguridad EC2 cuyas reglas sólo permiten el tráfico a ciertas IP’s específicas en lugar de abrir las conexiones a todo el mundo (0.0.0.0/0).

Ciertamente lo más sencillo es siempre indicar en el grupo de seguridad que permitimos el tráfico en un puerto a todo el mundo, de modo que aunque tengamos IP dinámica en nuestra conexión a Internet siempre podremos continuar accediendo aunque ésta cambie. Pero abrir el tráfico a un puerto a todo el mundo no es la forma correcta de proceder desde el punto de vista de la seguridad, pues entonces cualquier atacante podrá tener acceso a ese puerto sin restricciones, y eso no es lo que queremos.

Son muchas las personas y empresas que por la crisis del coronavirus (Covid-19) se están viendo obligadas a adoptar distintas formas de teletrabajo en estos días. Como arquitecto de soluciones en la nube (Cloud Computing) y administrador de sistemas freelance llevo ya muchos años teletrabajando de forma remota satisfactoriamente, por lo que varias de ellas me están pidiendo durante los últimos días consejo sobre qué estrategias seguir y qué aplicaciones útiles manejar para teletrabajar desde casa de forma eficiente. Es por ello que he decidido ir un paso más allá y escribir este artículo en el que recopilo una serie de recomendaciones y de herramientas que espero que sirvan de ayuda a mucha gente que se ve obligada a desempeñar su trabajo a distancia en estos tiempos del coronavirus, aunque también espero que os resulte útil a todas aquellas personas y empresas que veáis una oportunidad en todo esto y optéis por apostar definitivamente por el trabajo en remoto, ya sea de forma parcial o total.

El siguiente procedimiento describe cómo permitir en Linux el uso simultáneo de 2 interfaces de red conectadas a la misma subred de AWS y que la comunicación funcione tanto a nivel interno (máquinas en la misma subred) como externo (ambas interfaces visibles desde Internet). Esto puede ser útil por ejemplo cuando queremos que una misma instancia aloje un servidor web que sirva peticiones http ó https y al mismo tiempo disponga de un servidor de websockets ws:// o wss:// que escuche en el mismo puerto 80 ó 443 respectivamente. Aunque hay otras formas de conseguirlo como configurar Nginx para que sea capaz de discriminar el tráfico web (http) del tráfico de websockets (ws) y actuar como proxy para redirigir las peticiones correspondientes al servidor de websockets, esta otra solución que planteo me parece más sencilla y en cierta medida más eficiente porque no es necesario redirigir el tráfico, lo cual siempre introducirá una pequeña latencia, y permite mantener ambos servidores totalmente independientes dentro de la misma máquina. La única pega es que necesitaremos asignar 2 direcciones IP elásticas (Elastic IP) a la misma máquina en lugar de 1, pero al mismo tiempo esto nos aportará mayor flexibilidad a la hora de establecer reglas en los grupos de seguridad o en las reglas NAT de la subred.