EC2 Security Groups, manejo de IPs y últimos datos sobre EC2: Camino a la Certificación AWS (4)

Security Groups

Son fundamentales para la seguridad de la red en AWS. Controlan cómo es permitido el tráfico hacia y desde las máquinas EC2.

En nuestro Dashboard e información de la instancia, podemos visualizar los Security Groups:

Si clickeamos en nuestro security group, podemos ver las propiedades:

Abajo hay una descripción, inbout, outbound y tags:

  • Inbound: Estas son las reglas que permiten el tráfico hacia nuestra máquina EC2. Por defecto no hay reglas, y la que creamos al crear la instancia fue la regla SSH. (Si borráramos esta regla, ya no podríamos acceder con SSH a la máquina.)
  • Outbound: Por defecto, todo el tráfico está permitido desde la máquina.
  • Tags: Tags que podemos agregar a la regla.

Security Groups en mayor profundidad

  • Los security groups actúan como un firewall en las instancias EC2.
  • Regulan:
    • Accesos a los puertos
    • Rangos IP autorizados – IPv4 y IPv6
    • Controlan la red inbound (desde una lugar a la instancia)
    • Controlan la red outbound (desde la instancia a otro lugar)

Es importante saber

  • Los security groups pueden ser añadidos a múltiples instancias.
  • Están bloqueados a una combinación región/VPC, así, si cambiamos la región o VPC, hay que crear un nuevo security group.
  • Es buena práctica tener un security group separado para el acceso SSH.
  • Si la aplicación no se puede acceder (timeout), entonces hay un problema con el security group.
  • Si la aplicación entrega un Connection refused, entonces, es un error en la aplicación o que no está siendo lanzada.
  • Por defecto, todo el tráfico inbound está bloqueado.
  • Por defecto, todo el tráfico outbound está autorizado.

Referenciando security groups desde otros security groups

Por ejemplo, tenemos una instancia, que tiene un security group llamado Grupo 1. En las reglas inbound está autorizando al Security Group 1 y Security Group 2.

¿ Por qué hacer esto? Si creamos ahora una nueva instancia EC2 y tiene añadido el Security Group 2, usando el Security Group 1, estamos básicamente permitiendo a nuestra Instancia conectarse de manera inbound a nuestra primera instancia EC2.

De manera similar, si tenemos otra instancia EC2 añadida al Security Group 1, también autorizamos a esta máquina a conectarse de manera inbound a nuestras instancias, sólo por tener el correcto Security Group.

Por otro lado, si tenemos otra EC2, añadida al Security Group 3, como no tiene permisos, no podrá acceder a las máquinas.

Esto es interesante, ya que nos hace preocuparnos sólo de los grupos de seguridad y no de las IPs.

Manejo de IPs por parte de AWS

Por defecto, las máquinas de EC2 traen:

  • Una IP Privada para la red interna de AWS.
  • Una IP pública, para conexión con toda la web.

Cuando hacemos un SSH a nuestra instancia:

  • No podemos usar la IP privada, porque no tenemos acceso a la misma red.
  • Sólo podemos usar la IP pública.
  • Si reiniciamos la instancia EC2, la IP pública podría cambiar.

Instalando Apache en un EC2

Vamos a empezar ahora a trabajar un poco nuestra instancia EC2. Para ello instalaremos un Apache Web Server para poder mostrar una página web. Y simplemente crearemos un html para mostrar algún Hola Mundo.

Lo primero es acceder mediante SSH a nuestra máquina:

Una vez entramos a nuestra máquina, lo primero que debe hacerse es actualizar los packages de la máquina:

yum update -y

Con todo actualizado podemos partir instalando httpd:

yum install -y httpd.x86_64

Nota: Los -y de los comandos indica que queremos darle a YES en cada pregunta.

Una vez instalamos el servidor, podemos inicializarlo con el siguiente comando:

systemctl start httpd.service

Y podemos hacer que el servidor esté habilitado aún después de reiniciarlo

systemctl enable httpd.service

Con esto ya habilitamos el servidor, y podemos visualizarlo mediante un navegador, simplemente usando la dirección de la ip pública de la máquina y el puerto 80.

Si nos fijamos, esto no está cargando, ocurre un error por timeout. Esto seguramente pasa por algún error con nuestros Security Groups

Si vemos en el Dashboard, en las reglas Inbound podemos apreciar lo siguiente:

Según esto, sólo permite conexiones con el puerto 22, pero nuestro servidor apache disponibiliza el 80, por lo tanto, sólo debemos habilitar el puerto 80 para que se pueda acceder. Para ello, abrimos las reglas de seguridad:

Y agregamos a las reglas Inbound una nueva regla HTTP que permita ver el puerto 80:

Y ahora si abrimos la página, podemos visualizarla:

Y para hacer nuestro hola mundo, sólo debemos crear un archivo html en la ruta /var/www/html/

echo "Hola Mundo" > /var/www/html/index.html

Y ahora, si volvemos a abrir nuestra ip en el navegador, podemos visualizar el mensaje:

EC2: User Data

Es posible hacer bootstrap (lanzar comandos cuando una máquina se inicializa) en nuestras instancias usando un script de EC2 User Data.

¿Cuál es el objetivo de esto? Permite automatizar tareas de boteo como instalar actualizaciones del equipo, instalar software, bajar archivos comunes desde internet, entre muchas otras cosas. Hay que tener en cuenta que estos comandos se lanzan como sudo.

Cómo realizarlo

Al momento de crear una nueva instancia de EC2, en la configuración, está la opción para indicar los scripts que deseemos lanzar al inicializar la máquina:

La estructura de un script es la siguiente:

#!/bin/bash

#install httpd
yum update -y
yum install -y httpd.x86_64
systemctl start httpd.service
systemctl enable httpd.service
echo "Hola Mundo" > /var/www/html/index.html

Este pequeño script hace lo mismo que hicimos anteriormente para instalar Apache.

Finalmente, seguimos los pasos, y ya podemos seleccionar nuestro security group que creamos anteriormente:

Finalmente, si todo salió correctamente, podemos ir a la IP pública y ver nuestro Hola Mundo:

Tipos de lanzamiento de Instancias

Existen varios tipos de lanzamiento para nuestras instancias:

  • On demand: Poca carga de trabajo, precio predecible.
    • Pagar por lo que se utiliza.
    • Tiene el mayor costo, pero no hay pago por adelantado.
    • No hay un acuerdo a largo plazo, por lo que se puede detener cuando se quiera y dejar de pagarlo.
    • Recomendado para períodos cortos y cargas ininterrumpidas, donde no se puede predecir cómo se comportará la aplicación.
  • Instancias reservadas: Alta carga de trabajo, en tiempo mayor o igual a un año.
    • Descuento de un 75% comparado con el ondemand.
    • Se paga por adelantado.
    • La reserva puede ser de 1 o 3 años.
    • Se reserva un tipo de instancia específico.
    • Recomendado para uso estable al usar aplicaciones (como una base de datos).
  • Instancias reservadas convertibles: Alta carga de trabajo con instancias flexibles
    • Pueden cambiar el tipo de instancia EC2
    • Su valor es 54% comparado con las on demand
  • Instancias reservadas calendarizadas: Lanzadas en ventanas de tiempo definidas.
    • Se lanzan en ventanas de tiempo definidas que sean reservadas.
    • Útiles cuando se necesitan sólo una fracción de tiempo.
  • Spot Instances: Baja carga de trabajo, más barata, pero con el riesgo de perder instancias.
    • Descuento de un 90% de las on demand
    • Funciona como una subasta, se hace una oferta y se obtiene la instancia por el tiempo que esté bajo ese precio.
    • El precio varía basado en la oferta y demanda.
    • Cuando la oferta es superada, llega una notificación con 2 minutos indicando que el precio ha subido.
    • Usado para hacer batch jobs, análisis Big Data, o cargas de trabajo que son resistentes a fallos.
  • Instancias dedicadas: Nadie más compartirá el hardware.
    • Las instancias corren en hardware que está dedicado al usuario.
    • Podría compartir hardware con otras intancias en la misma cuenta.
    • No hay control sobre la colocación de instancia. (Si se detiene e inicia una instancia, podría ser movida de hardware).
  • Hosts dedicados: Agendar un servidor físico completo, controlando la colocación de las instancias.
    • Es un servidor EC2 dedicado para que sea usado.
    • Hay control absoluto de la colocación de instancias.
    • Hay visibilidad a los sockets y cores físicos del hardware
    • Son asignados a la cuenta por periodos de 3 años.
    • Es más caro.
    • Útiles para software que tienen modelos de licencia complicados.
    • Útiles para compañías que tienen necesidades muy reguladas.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: