Iniciando su trayectoria en la nube de forma sencilla

Por Marilia Brito, Technical Trainer en AWS Brasil

Cuando hablamos de computación en la Nube, pensamos automáticamente en las ventajas que disfrutaremos al incorporar este modelo de operación, donde ya no seremos directamente responsables por la administración de los datacenters, sino que nos centraremos en construir una arquitectura que satisfaga las necesidades de nuestros negocios.

Al contar con un portafolio de aproximadamente 175 servicios, podemos poner una idea en práctica con unos pocos clics, en cualquiera de las 24 regiones que forman parte de la infraestructura global de AWS. La consola de AWS es como un lienzo en blanco, esperando que su obra maestra se cree.

Pero ¿Cómo empezar en la nube de AWS? ¿Cuál camino elegir? El objetivo de este artículo es crear un servidor web, basado en las mejores prácticas de AWS. Iremos a través de los pasos necesarios, sin pensar solamente en los aspectos técnicos que involucran esta tarea.

Comenzando con el pie derecho

Para comenzar esta ruta hacia la Nube, es conveniete establecer desde el principio cuáles son las mejores prácticas. Para esto, podemos contar con las directrices de diseño del Well Architected Framework, una guía que nos ayudará a adecuar y a optimizar las infraestructuras para que sean seguras, resilientes, eficientes, y de alto rendimiento. El Well-Architected Framework está formado por 5 pilares: Excelencia Operativa, Seguridad, Confiabilidad, Eficiencia de Rendimiento y Optimización de los Costos.

Ahora debemos decidir en cuál región construiremos nuestra arquitectura. Las Regiones son zonas geográficas separadas en las que AWS tiene sus datacenters. Estos datacenters se agrupan lógicamente en Zonas de Disponibilidad. AWS tiene 77 Zonas de Disponibilidad y cada una de ellas tiene uno o más data centers.

Como clientes de AWS, tenemos control total sobre cuál región elegir, para almacenar nuestros datos. Al elegir una región, es clave considerar factores como: conformidad y gobernanza, proximidad a los clientes, y costos. Siempre que sea posible, debemos adoptar una estrategia multirregión para contar con una arquitectura resiliente frente a cualquier desastre.

Si queremos conocer mejor la infraestructura global de AWS, este enlace nos llevará a una página web totalmente interactiva en la que podemos “navegar” por las regiones y puntos de presencia (donde están disponibles los servicios globales) de AWS.

Figura 1 – Infraestructura Global de AWS, disponible en la página web infrastructure.aws

Si recientemente hemos creado una cuenta de AWS, debemos realizar algunas configuraciones de seguridad. ¡La seguridad es la prioridad máxima en AWS, y también debe ser la nuestra! Así que protejamos nuestra cuenta.

Usuario Root – “Un gran poder conlleva una gran responsabilidad”

Al acceder a la consola de AWS, utilizando el correo electrónico y contraseña de creación de la cuenta de AWS, estamos utilizando el usuario root. El usuario root tiene poderes ilimitados. Cualquier acceso a los recursos en la cuenta de AWS estará disponible, y se podrán usar sus privilegios para realizar grandes cambios. Por ejemplo, se tiene el privilegio administrativo para borrar la cuenta de AWS, y consecuentemente todos los recursos que hayan sido aprovisionados dentro de ella. Para no tener que convivir con este tipo de riesgo, ejecutaremos las siguientes acciones, que pueden consultar en el dashboard del servicio Identity and Access Management, o AWS IAM.

Delete your root access keys – Las llaves de acceso del usuario root (access key y secret key) no deben utilizarse, porque su uso proveerá acceso irrestricto a todos los recursos de la cuenta de AWS. Entonces, no deberían utilizarse estas llaves para interactuar con los endpoints y APIs de AWS. Vea aquí como borrarlas.

Activate MFA on your root account – Añadir una capa de seguridad para efectuar la autenticación durante el registro. Consulte la lista de mecanismos disponibles.

Create individual IAM users – Crear usuarios con políticas de acceso que contengan el mínimo privilegio posible, es decir, un usuario sólo debe tener permisos de acceso que sean relativos estrictamente a los servicios que él o ella deberán utilizar, y solamente con las acciones que deberán ejecutar. También existen políticas que niegan el acceso a un determinado recurso.

¡Vamos a crear nuestro primer usuario! El usuario Admin que crearemos es un usuario que aún tiene amplios poderes en la cuenta, pero no tiene el poder de borrarla. Es muy fácil crear este o cualquier otro usuario; ¡basta con definir las formas de interacción que utilizará con los servicios de AWS (programática o por la consola), seleccionar las políticas que este usuario tendrá, cargar las llaves de acceso y listo! En el caso del usuario Admin, utilizaremos una política administrada por AWS llamada AdministratorAccess.

El servicio IAM cuenta con políticas gestionadas por AWS que ya están creadas y pueden ser utilizadas inmediatamente. Un usuario con los permisos suficientes también puede crearlas manualmente o utilizando el generador de políticas, disponible en la opción Create Policy de la consola de IAM. Entonces, aunque no entendamos cómo crear políticas desde cero usando el formato JSON, seremos capaces de crear nuestras propias políticas personalizadas mediante el editor visual.

Muy fácil, ¿verdad? Si deseamos vincular los permisos de visualización de la facturación de nuestra cuenta y gestión de costos, debemos ingresar una política gestionada llamada Billing.

A partir de ahora no accederemos más a la consola con el usuario root sino mediante el usuario Admin, utilizando el nombre de usuario y la contraseña a través de un enlace, estructurado como se muestra abajo:

https://<número_de_la_cuenta_de_aws>.signin.thinkwithwp.com/console

Para la administración de los usuarios que utilizarán esta cuenta, una práctica recomendada es crear grupos de usuarios, con la finalidad de definir los permisos de acceso en cada uno de estos grupos y posteriormente, introducir los usuarios que formarán parte de cada grupo. Al hacer esto, un usuario dentro de un grupo recibirá las políticas que tiene el grupo. Esto es mucho más práctico y seguro que vincular las políticas directamente a cada usuario.

Usuario root seguro, grupos y usuarios definidos. Es el momento de usar nuestro primer servicio en la nube de AWS.

Comenzando de forma sencilla con Amazon S3

Amazon Simple Storage Service, como su nombre lo indica, es un servicio de almacenamiento en internet fácil de utilizar. Amazon S3 almacena cualquier tipo de archivo como un objeto. Un objeto es básicamente un archivo y todos los metadatos opcionales que lo describen. Estos deben tener como máximo 5 TB y serán almacenados en la región elegida con una durabilidad de 99.999999999%.

Amazon S3 es ideal para almacenar cualquier cantidad de datos, ya que cuenta con espacio ilimitado. Además, funciona totalmente sin servidores, y es totalmente gestionado; puede utilizarse para diferentes casos de uso, como backups, data lakes, y puede incluso usarse como estructura para servir un sitio web estático.

Para utilizar Amazon S3, basta con crear un bucket, definiendo un nombre único globalmente, y empezar a introducir nuestros objetos.

Cuando creamos un bucket, éste solamente puede ser accedido por quien lo creó. Para facilitar el acceso a los objetos almacenados en el bucket, es necesario crear políticas que lo permitan.

Amazon S3 tiene diversas clases de almacenamiento, desde estrategias con acceso frecuente a los objetos (S3 Standard), hasta el archivado de datos para retención a largo plazo y de bajo costo, usando Amazon S3 Glacier.

Ahora, necesitamos poder computacional para poner en marcha una aplicación.

¡Si usted forma parte del equipo de infraestructura, este es su momento! Si usted no sabe absolutamente nada sobre redes, explicaremos de manera sencilla lo que es necesario configurar para nuestra red privada en AWS, la cual nos permitirá acceder al servidor web.

Amazon VPC – Su red virtual en la nube

¡No importa si somos partidarios del IPv4 o del IPv6, utilizando VPC, podemos elegir IPv4 solamente, u optar por ambos! En nuestra arquitectura nos enfocaremos en IPv4.

Antes de empezar la construcción de nuestra VPC, asignaremos una Elastic IP, siguiendo las instrucciones de la documentación. ¡Necesitaremos de esta IP estático!

¡El paso a paso para crear una VPC nos facilitará el proceso para definir y configurar la red que necesitaremos para asignar nuestros recursos! Seguiremos las mejores prácticas y seleccionaremos la opción con una subred (subnet) pública y una privada, con el fin de aislar los recursos que no queremos que se comuniquen de forma directa con Internet.

Las subredes se encuentran dentro de una Zona de Disponibilidad.

Ahora, debemos poner un nombre a nuestra VPC, y usar el Elastic IP, previamente creado.

¡La VPC ha sido creada! Vamos a explorar las tablas de rutas que el paso a paso ha creado en cada una de nuestras subredes. Empezando por la Subred Pública

Todos los recursos que sean asignados en la Subred Pública tendrán acceso a Internet, ya que la tabla de rutas asociada tiene enrutamiento a un gateway que posibilita la comunicación de nuestra VPC con Internet. A propósito, este gateway es lo que llamamos Internet Gateway, un recurso con alta disponibilidad nativa e integralmente gestionada por AWS. Al crear manualmente una VPC sin el auxilio del paso a paso, la creación y conexión del IGW a la VPC debe realizarse manualmente, dado que la configuración por defecto de la VPC es totalmente privada y los recursos que están allí solamente pueden comunicarse localmente.

En la tabla de rutas de la Subred Privada, podemos verificar que no hay una ruta definida al Internet Gateway.

En este caso existe una ruta hacia Internet (0.0.0.0/0) indicando como destino el nat-<id_del_nat_gateway>. Fue para este recurso que hemos creado la Elastic IP. El NAT Gateway direcciona el tráfico de la subred privada a Internet, sin exponer las direcciones IPs de estos recursos, sino solamente la Elastic IP fija que le asignemos. El NAT está ubicado en la Subred Pública, ya que, como hemos podido ver en la imagen anterior, ésta tiene una tabla de rutas que proporciona acceso a Internet, mediante la comunicación con el IGW.

¡Es hora de cargar nuestra aplicación!

Amazon EC2 – Un servicio para sacarle provecho

Personalmente, lo que más me gusta con relación a las instancias EC2 es la posibilidad de tomar diversas malas decisiones y no recibir penalizaciones por esto, teniendo que lidiar con hardware juntando polvo en mi datacenter, o ejecutando mi aplicación sin alcanzar el rendimiento deseado, muchas veces, debido a una compra basada en una estimación un tanto incorrecta. Llegó el momento de sonreir, estamos en la nube y aquí los recursos pueden tratarse como “desechables”. ¡Es un espacio para explorar, experimentar, e incluso fallar! Sí, porque solamente basta con eliminar el recurso, y recomenzar con otro que tenga mayor sentido para nuestro caso de uso.

Las instancias EC2 están divididas en familias, y cada familia tiene una finalidad específica. Por ejemplo, tenemos familias de instancias en General Purpose, Compute Optimized y Memory Optimized. Además, las instancias tienen un tamaño. Usaremos como ejemplo las instancias r5 de la familia Memory Optimized.

A medida que aumenta el tamaño de mi instancia, o sea large, xlarge, 2xlarge y así sucesivamente, más poderosa será. Por lo tanto, es muy simple escalar una instancia verticalmente aumentando su tamaño, consecuentemente aumentando la cantidad de vCPUs, memoria, y demás atributos.

Podemos disfrutar sin ningún costo de una instancia de la familia General Purpose llamada t2.micro, que ofrece 750 horas de poder computacional por mes, durante 12 meses, de forma gratuita a través del AWS Free Tier. De hecho, algunos servicios tienen un nivel gratuito que no se limita a 12 meses. Para conocer más sobre ellos visite la página AWS Free Tier.

¡Crear una instancia es muy fácil! Con unos pocos clics, la instancia estará disponible para iniciar la construcción de nuestra aplicación.

Toda instancia EC2 es deplegada a partir de una AMI (Amazon Machine Image). Las AMIs son proporcionadas por AWS con sistemas operativos de código abierto, o con licencia incluida, y puede contener algunas aplicaciones y paquetes previamente instalados. También podemos crear nuestras propias AMIs con todo lo que las aplicaciones necesitan, o utilizar una imagen del AWS Marketplace con soluciones de terceros, ya listas para utilizarse.

Tras realizar esta selección y definir cuál será la familia y el tamaño de nuestra instancia, vamos a seleccionar la VPC y la subred en las que esta instancia será provisionada.

Estamos creando un servidor web, por lo tanto, éste debería quedar en la Subred Pública. Por esto habilitamos las configuraciones de IP pública. Podemos configurar también alguna acción que deberá ejecutarse en el momento en que la instancia es creada, por ejemplo, instalar e iniciar una versión de Apache Web Server. Estamos hablando del user data, un atributo de la instancia EC2. Basta expandir el Advanced Details e introducir los comandos a ejecutarse como texto o dentro de un archivo.

Ya elegimos el poder computacional de nuestra instancia, elegimos la red a la que estará conectada, pero aún tenemos que definir sus dispositivos de almacenamiento.

Almacenamiento de bloques persistente, altamente disponible para diversos casos de uso

Amazon EBS es el servicio que proporciona el almacenamiento de bloques para nuestra instancia EC2.  Es persistente, porque puede ser independiente del ciclo de vida de la instancia. Es altamente disponible, porque nativamente se replica dentro de la Zona de Disponibilidad en que ha sido creado. Hay 4 tipos de discos entre las opciones SSD (mejor desempeño para IOPS) y HDD (ideal para las aplicaciones que dependen principalmente del throughput).

Figura 2: Tipos de volúmenes de Amazon EBS, disponibles en https://docs.thinkwithwp.com/AWSEC2/latest/UserGuide/ebs-volume-types.html

Además de elegir el volumen de arranque root, podemos añadir más volúmenes EBS, para almacenar datos. Mientras nuestra instancia esté en ejecución, debemos recordar mantener con regularidad una rutina de copias de seguridad de los volúmenes EBS, a través de snapshots.

Al inicio de este artículo, hablamos sobre priorizar la seguridad y ponerla en primer lugar. Esto no ha cambiado. Nuestro servidor web contará con un firewall virtual para protegerlo.

Security Group – Control del tráfico que se recibe en las instancias EC2

El Security Group es un firewall virtual, con reglas especificadas por el usuario, las cuales determinan las interacciones de red que están permitidas en las instancias protegidas por él. Al tratarse se un firewall stateful, todos los permisos concedidos en las reglas de entrada admitirán no solamente el tráfico entrante sino también el tráfico saliente identificado como respuesta al tráfico ya admitido, y visceversa.

En nuestro web server, será posible acceder a la instancia mediante el protocolo SSH por el puerto 22, desde una única dirección IP (la nuestra). Además, se aceptará el tráfico originado en Internet por el puerto 80 (HTTP).

Si no hubiera ninguna norma explícita en el security group, la instancia no aceptaría ningún tipo de comunicación entrante.

¡Sólo queda un paso! Seleccionamos un key pair (par de llaves) ya existente o creamos uno nuevo. Debemos guardar la llave privada de este par de llaves para poder establecer una sesión remota con el sistema operativo de nuestra instancia.

¡Finalmente, nuestro servidor web ya está en línea!

El servidor web está listo para recibir los archivos del sitio y presentarlos en Internet. Veamos a continuación la arquitectura que hemos construido:

¡En la segunda parte de este artículo, crearemos un servidor de aplicación, una base de datos, y convertiremos esta arquitectura en altamente disponible!

Sobre la autora

Marilia Brito es Technical Trainer en AWS y forma parte del equipo de Training and Certification Latam. Ha iniciado en AWS un programa de formación de arquitectos de soluciones y actualmente enseña de forma sencilla y sin complicaciones desde el cliente que está iniciando su ruta en la nube, hasta aquellos que ya están en una fase más avanzada de conocimiento.

Sobre los revisores

Bruno Lopes es Technical Trainer en el equipo de AWS Brasil. Trabaja con soluciones de TI hace más de 12 años, teniendo en su cartera inúmeras experiencias en workloads Microsoft, ambientes híbridos y formación técnica de clientes. Como Trainer, ya está hace más de 6 años se dedicando a enseñar sobre las tecnologías de punta a los clientes de América Latina.

Vinicius Alves es Technical Trainer en AWS y forma parte del equipo de Training and Certification Latam. Licenciado en Ingeniería Mecánica por la FEI (São Bernardo do Campo), comenzó en AWS en un programa de capacitación para arquitectos de soluciones y ahora se enfoca en enseñar todos los conceptos aprendidos para facilitar el viaje de los clientes a la nube.

Revisor

Ricardo Bermudez es AWS Cloud Technical Trainer en AWS Colombia.