Aunque los competidores están empezando a coger carrerilla, decir hoy en día que Amazon Web Services es el proveedor de cloud más utilizado, con más funcionalidades y servicios interesantes es como decir que el cielo es azul. AWS se ha transformado en un monstruo en el que probablemente casi nadie puede estar al día de todos los cambios y funcionalidades en detalle que va adoptando. En este post vamos a ver algunas de las funcionalidades y características de AWS que probablemente si no has trabajado un poco con AWS no conozcas.

ALIAS

En route 53 podemos crear registros DNS con ALIAS, no penséis que Amazon ha reinventado el protocolo DNS ni nada por el estilo. Ésta característica ha salido por un lado porque al apex de un dominio (raíz), no se le puede asignar un registro CNAME y esto es un problema en un entorno cloud dónde las IPs no son fijas y todo puede cambiar. A parte también interesa tener registros DNS que apunten a componentes de AWS (como por ejemplo un ELB) y que en caso de que cambie la IP del componente en cuestión el registro sea actualizado.
Al crear un registro DNS , podemos configurar que sea de tipo ALIAS y el componente al que apunta, ésto nos permite apuntar a componentes con IP cambiante y a parte poder configurar un apex de un dominio como un registro que aunque sea de tipo A, es dinámico.

EC2 Metadata

Aunque probablemente todos los que hemos trasteado un poco con EC2 vemos que mágicamente se nos configuran algunos parámetros de la máquina automáticamente como el hostname, se ejecuta el user-data que le hemos pasado, se crea un usuario estándar con nuestra clave pública,… ¿De dónde proviene todo esto? ¿Como puedo recoger toda esta información y actuar si me preparo una AMI de zero?
La respuesta está en el servicio de metadatos, el servicio de metadatos es un servicio http que se encuentra en la dirección 169.254.169.254 de cada máquina. Si ejecutamos por ejemplo:

curl http://169.254.169.254/latest/meta-data/

Podremos ver todos los metadatos relacionados con la instancia. Si ejecutamos:

curl http://169.254.169.254/latest/meta-data/public-keys/0/openssh-key

Podremos ver la clave pública con la que AWS nos configura el usuario ec2-user.
Con ésto podemos ejecutar nuestros propios scripts para que nuestro servidor arranque con las configuraciones que nos interesen del meta-data. Otra posibilidad es instalar cloud-init, el cual nos permite configurar los parámetros del meta-data cómo queremos que se comporten. Las AMIs oficiales de AWS llevan cloud-init instalado por defecto.

ASG Termination Policy

En los autoscaling groups de Amazon se puede configurar la política para de terminar las máquinas virtuales. Por defecto siempre se borra la que más cerca de llegar a un numero entero de horas del Launch Configuration más viejo del Availability Zone en el que tengamos más máquinas.
Si queremos cambiar éste comportamiento, podemos cambiar la termination policy a uno de estos parámetros:

  • OldestInstance – Dentro del Auto Scaling group seleccionado (el que tenga más instancias) se selecciona la instancia más vieja.
  • NewestInstance – Se termina la instancia más recientemente creada.
  • OldestLaunchConfiguration – Se termina la instancia del Launch Configuration más viejo.
  • ClosestToNextInstanceHour – Se termina la instancia que más a punto está de cumplir un múltiplo de 60 minutos.
  • Default – Se termina con la política por defecto explicada más arriba.

ASG Health Checks

En los AutoScaling Groups, AWS utiliza health checks para detectar si una instancia está en buen estado. En caso de que una instancia no esté respondiendo, es terminada y en caso de que sea necesario escalará agregando nuevas instancias. Por defecto el health check se coge del estado general de EC2 y aunque es la configuración recomendada, en caso de tener un Elastic Load Balancer asociado al AutoScaling Group se puede hacer que los health checks se cojan del estado que está detectando el balanceador. Ésta última configuración puede dar raíz a problemas, imaginemos que de repente nos llega mucha carga y nuestras instancias dejan de responder un código 200 a los balanceadores que hemos configurado como healthcheck, ¿que pasará? El resultado será que en vez de escalar nuestro AutoScaling Group las instancias que no respondían serán eliminadas teniendo el efecto contrario al deseado. Más información aquí.

Multi-Factor Authentication

Con Multi-Factor Authentication, AWS permite la autenticación con dos factores, por un lado tenemos el usuario y contraseña y por el otro tenemos el segundo factor que puede ser con dispositivos virtuales como Google Authenticator, o la virtual MFA de AWS. También se puede utilizar Gemalto como dispositivo físico, el cual  nos dará aún más seguridad que los dispositivos virtuales.

AWS Direct Connect


Aunque el diagrama lo dice casi todo, DirectConnect trata de tener conectividad directa hacia los Centros de Datos de AWS, ¿como se hace esto? Pues básicamente debemos tirar un enlace a uno de los routers de Direct Connect y tenemos ancho de banda dedicado con AWS, la parte de conectividad del router a los centros de datos de AWS es gestionado por AWS. +Info aquí

Aplicación para dispositivos móviles

Y para terminar, y más como curiosidad que otra cosa, vemos que existe una aplicación de AWS para móviles. Se puede encontrar en el PlayStore de Android y en el AppStore de Apple. Después de probar la aplicación si que vemos que aunque es útil para visualizar el estado de nuestra infraestructura, no nos sirve para poder lanzar nueva infraestructura o cambiar configuraciones.
Esto es todo cloudadmins, si tienen cualquier duda o sugerencia pongan sus comentarios!
Saludos,
Oriol Marti
Cloud Admin