Intro

Después de asistir a la última edición en Madrid del AWSomeday, he tenido por fin tiempo de convertir los apuntes anotados en este artículo, para que cualquiera pueda tener una idea de lo que nos puede ofrecer Amazon.

Ha sido un seminario orientado a responsables técnicos, profesionales de IT y desarrolladores que quieren iniciarse en el uso de la plataforma AWS y aprender más acerca de la informática en la nube.

A través de presentaciones y demostraciones en vivo paso a paso, he tenido la oportunidad de ver cómo se pueden construir y desplegar aplicaciones escalables y seguras en la nube, incluyendo servidores virtuales, almacenamiento, bases de datos y redes.
 

Un poco de historia

Pero, ¿cómo ha empezado todo? ¿De dónde ha salido AWS? ¿Por qué gente que vende zapatos y electrodomésticos por Internet se ha lanzado en el mundo de la arquitectura IT?

Básicamente es debido a este dibujo que vemos al lado: tener una gran variedad de productos, que atraen a muchos consumidores, que generan mucho tráfico y volúmenes de venta, que atraen a más vendedores que aumentan la variedad de productos, que pueden ser vendidos a más consumidores… y a empezar otra vez.

En cada vuelta, como no, podemos aplicar las bajadas de costes de infraestructura y los relativos precios de productos más bajos respecto a la competencia.

Hablando de infraestructura, la que utilizaban en el 2006 de repente se les ha hecho…. pequeña. De manera exponencial podemos decir, demasiado volumen de venta que no podía ser gestionado por los servidores entonces utilizados. Ya no era un problema de simple “escalabilidad” y se convirtió en un verdadero cuello de botella a nivel global. Había que pensar en grande, muy grande. Había que invertir muchos recursos en varias partes del mundo a la vez, para resolver los problemas de latencia y alta disponibilidad de los servicios ofrecidos, y así fue.



Después de 11 años, Amazon es uno de los “monstruos” más grandes de la Internet entera, y parece decidido a no parar de crecer. Y dado que era bastante evidente que lo habían hecho muy bien por su propio negocio, y que las soluciones utilizadas eran muy eficientes, alguien se preguntó… “¿por qué no ofrecemos nuestra infraestructura también a otros?” Y así nacieron los Amazon Web Services, o AWS.


 

A día de hoy la nube de AWS funciona en 42 zonas de disponibilidad (cluster de datacenter aislados de otros datacenter en caso de desastres) en 16 regiones geográficas de todo el mundo (zonas que no son necesariamente identificadas con un país, que cuentan con no menos de dos zonas de disponibilidad), con planes anunciados para ocho zonas de disponibilidad y tres regiones más.

Volvemos entonces al círculo de crecimiento que hemos visto antes: más disponibilidad de infraestructura, más clientes que quieren utilizarla, más usuarios, etc.

De esta manera obtenemos más tiempo para el negocio, y menos esfuerzos (o ninguno) para la infraestructura. Y el número de clientes y servicios que utilizan el cloud AWS lo testimonia.


 

1 – AWS FOUNDATIONAL SERVICES

Se componen de diferentes elementos/áreas:

1. Amazon Elastic Compute Cloud (EC2)
2. Amazon Virtual Private Cloud (VPC)
3. Amazon Storage Services:
   • Simple Storage Server (S3 almacenamiento a objetos -> ficheros)
   • Elastic block Store (EBS almacenamiento a bloques -> discos)

ELASTIC COMPUTE CLOUD (EC2)

Se trata de instancias de sistemas operativos con mejoras debidas a su uso en la nube:

• capacidad de escalado según requerimientos
• pago solo por uso efectivo de los recursos
• despliegue entre regiones y zonas de disponibilidad automático
• uso de tags para una gestión eficiente de las instancias
• tiempos extremamente reducidos para obtener e iniciar una instancia

En cuatro sencillos pasos ya puedes tener una máquina en AWS:

1. elegir la región de la instancia (más cerca de los usuarios, menos latencia)
2. lanzar la instancia desde una imagen pre-configurada (AMI)
3. elegir las características según las exigencias (CPU, memoria, disco, network)
4. configurar la red, dirección IP, grupos de seguridad, tags y llave de seguridad

Al final tendremos algo así:

VIRTUAL PRIVATE CLOUD

Pone a disposición una red (virtual) privada y aislada en la nube AWS, completamente bajo el control del usuario. Igualmente, hay la posibilidad de crear subnet, o sea rangos de IP donde se pueden lanzar instancias AWS. Deben residir en una zona de disponibilidad y no compartir otras zonas (es transparente para el usuario).

Hay dos tipos de subnet:

• subnet publica -> para recursos que se pueden compartir en Internet

• subnet privada -> para recursos no compartidos en Internet

La parte inherente a la seguridad en una VPC es gestionada a través de Grupos de Seguridad, lista de controles de acceso (ACL) y sistemas de Key Pairs.

Hemos dicho que el servicio AWS se paga según su uso, pero cuando queremos parar/reiniciar una instancia, ¿seguimos pagando? Y los datos, ¿se mantienen? ¿Y la IP?  ¿Hay otros estados de ciclo de vida de una instancia?

Resumiendo:



 

STORAGE SERVICES: TIPO S3

El Simple Storage Server es un tipo de almacenamiento dirigido al uso en internet, para accesos http online. Permite de guardar y descargar cualquier cantidad de datos, en cualquier momento, desde donde uno quiera. Este servicio es escalable, de confianza, veloz y estable. Es posible almacenar un número ilimitado de objetos (ficheros) en un “bucket” (un repositorio), el límite de tamaño de un objeto son 5TB, mientras que el bucket no tiene límites de dimensión.

Puede utilizar el protocolo HTTPS/SSL, como otras herramientas de encriptado tanto lado servidor como lado cliente (AWS SDKs por ejemplo). El control de acceso puede ser realizado a través de ACLs (Access Control List), policies de bucket, IAM (Identity Access Management) policies.

Se puede utilizar para almacenamiento y backup, hosting de aplicativos y media, software delivery y almacenamiento de AMI y snapshot de instancias.

Como indicado, S3 almacena los objetos en buckets. Un objeto está compuesto por un fichero y opcionalmente por cualquier metadada que describa ese fichero. Por supuesto el usuario tiene el completo control de acceso a un bucket y a sus objetos.

Una medida de seguridad añadida es el versioning. Esta modalidad protege los ficheros de borrados accidentales o sobreescrituras, sin incidir en el rendimiento. Básicamente para cada upload se genera una copia de la nueva versión y de esta manera se permite la recuperación de los objetos borrados o el rollback de la versión previa. Tiene tres estados: deshabilitado (por defecto), habilitado o suspenso.

Igual que para las instancias EC2, el usuario paga solo por el almacenamiento efectivamente utilizado, y cuyo precio depende de la localización del bucket utilizado. Se puede calcular un presupuesto según el precio de almacenamiento, acceso y transferimiento de los objetos almacenados (el upload es gratuito).

Una alternativa menos eficiente, pero ideal para accesos infrecuentes, es Glacier. A través de esta herramienta los usuarios pueden almacenar sus objetos a largo plazo, a un precio muy muy bajo (0.01$ por GB al mes). El acceso a estos ficheros puede tardar hasta 5 horas.



 

STORAGE SERVICES: TIPO EBS

El Elastic Block Store es lo que más se acerca a un disco duro en AWS. Ofrece resultados de muy baja latencia y funciones de réplica automática de los datos en su zona de disponibilidad. Los snapshot de este tipo de almacenamiento se pueden guardar en S3.

El ciclo de vida de un almacenamiento EBS se divide en:

• creación (hasta 16TB) del volume
• anexado del mismo a una instancia EC2
• uso del volume en la instancia (SO y drive mount)
• creación (opcional) de un snapshot a un bucket S3
• detach del volume de la instancia EC2
• borrado del volume

Hay dos tipos de volúmes EBS:

• SSD-backed: optimizados para cargas transaccionales con frecuentes operaciones de R/W sobre I/O pequeños.
• HDD-backed: optimizados para cargas largas de streaming de datos, en los cuales el throughtput es esencial.

Su estructura es ideal para instalar sistemas operativos (boot/root volume, secondary volume), databases (escalables), aplicativos críticos y realizar snapshot de backup.

El precio se basa en la región de uso y puede calcularse según el almacenamiento utilizado o los IOPS ejecutados. Como medida de seguridad los volúmenes están replicados sobre diferentes servidores en una única zona de disponibilidad.

2 – SECURITY, IDENTITY & ACCESS MANAGEMENT

Podemos agregar la seguridad de AWS en dos macro-zonas:

• a cargo de los usuarios: son responsables de la seguridad EN la nube
• a cargo de AWS: es responsable de la seguridad DE la nube

es interesante echar un vistazo a la seguridad de la nube realizada por Amazon:

• staff de seguridad disponible 24/7
• centros de datos “escondidos” y no mapeados
• doble autenticación para los equipos autorizados
• autorización a nivel responsable para acceso al data center
• cambios controlados sobre cada elemento software/hardware/network
• servidores que graban cualquier acceso a la estructura
• firewall a diferentes niveles de acceso
• herramienta de monitoring de AWS

Para las instancias Ec2 y el VPC, completan el cuadro de seguridad las conexiones SSL entre endpoints utilizando protocolo HTTPS, creación de reglas de firewall a nivel de grupo de seguridad, y la posibilidad de montar subnets publicas o privadas, NAT o VPN en la nube para crear accesos restringidos de bajo nivel a los recursos.


 

IAM BEST PRACTICES

• borrar la clave de acceso root después de la creación del account y de usuarios estándar
• crear usuarios IAM individuales
• utilizar grupos para asignar permisos a los usuarios IAM
• conceder privilegios limitados (menos gente que toca, ¡menos problemas!)
• configurar una politica de seguridad de password eficiente
• habilitar acceso multi-factor para usuarios privilegiados
• utilizar roles para las aplicaciones ejecutadas sobre instancias Ec2
• utilizar la delegación de roles en lugar de compartir credenciales
• cambio periódico de credenciales
• borrado de credenciales y usuarios ya no necesarios
• monitorización las actividad en los account AWS

Una herramienta útil para este último punto es la AWS CloudTrail. Básicamente se ocupa de grabar las llamadas API para las cuentas activas de un usuario, y envía ficheros de log a un bucket S3. Las llamadas se realizan utilizando la consola de gestión, los SDK’s, o la interfaz de linea de comando.

3 – DATABASES

AWs ofrece compatibilidad con los dos macro grupos principales de bases de datos:

• SQL       -> relational database (Amazon RDS)
• noSQL  -> metadata/documents database (Amazon DynamoDB

Hay que elegir entre una categoría u otra, teniendo en cuenta:

• el formato de los datos
• la dimensión de los datos
• la frecuencia de ejecución de las queries
• la velocidad de acceso que se necesita
• el tiempo de retención de los datos

AMAZON RELATIONAL DATABASE SERVICE (RDS)

Es el tipo de base de datos clásico, de bajo coste y de dimensión ajustable y que cuenta con una interfaz de gestión para las tareas de administración del DB. Es plenamente compatible con otros productos de la misma categoría (Aurora, mySQL, MariaDB, MS SQL Server, Oracle, postgresSQL).


Las características principales a favor de este tipo de database son:

• fácil y rápido de desplegar
• puede gestionar las tareas comunes de administración
• compatible con las aplicaciones de usuario
• buenas prestaciones y rendimiento
• fácil y rápido de escalar según las necesidades
• seguro
• cost-effective

Dado que estos elementos son una parte crítica del proceso productivo de una empresa, se ha dado mucha relevancia a la seguridad de los datos guardados en la nube. Por eso podemos contar con:

Backup automáticos

• permiten restaurar una base de datos en un determinado punto en el tiempo
• activados por default
• pueden estar almacenados por un máximo de 35 días

Snapshot manuales

• una nueva instancia puede ser lanzada desde un snapshot en particular
• son realizados por el usuario según las necesidades
• persistentes hasta su cancelación
• almacenados en entorno S3 de Amazon

Además contamos con los Snapshot Cross-Region, básicamente se trata de copias de snapshot almacenados en diferentes regiones y zonas de disponibilidad. Útiles en caso de disaster recovery o en caso de migración del entorno de producción a otra región.

Aparte de la seguridad “física” de las base de datos, hay que tener en cuenta unas cuantas normas de comportamiento para tener el acceso a los datos lo más seguro posible:

• ejecutar las instancias DB en una VPC
• utilizar políticas de IAM para garantizar el acceso a los recursos (o no)
• utilizar grupos de seguridad
• utilizar conexiones SSL
• utilizar la encriptación RDS de Amazon sobre instancias y snapshot no activos
• en caso de uso de instancias Oracle o MS SQL Server utilizar encriptación de red y herramienta TDE
• utilizar todas las medidas de seguridad del DB engine elegido para el control de acceso a la instancia

Llegados a este punto, ya podemos tener una idea de la arquitectura que podemos llegar a tener en AWS:



 

Si se quiere añadir aún más seguridad o redundancia a los datos, es posible implementar la Multi Availability Zone RDS de manera que se obtenga una HA completa sobre los datos utilizados. Básicamente estos se replican de manera síncrona (en tiempo real) en otra zona de disponibilidad de la misma región. Las operaciones de failover se realizan de manera automática.

RDS BEST PRACTICES

• monitorizar los elementos de memoria, CPU y disco.
• utilizar despliegues multi zonas para tener instancias en standby sincronizadas en otra zona de disponibilidad
• habilitar backup automáticos
• configurar el backup en horas de bajo write IOPS
• aumentar la capacidad de I/O de la instancia
• configurar un valor TTL inferior a 30 segundos
• comprobar el failover de la instancia!

Amazon DynamoDB

Características principales:

• permite el almacenamiento de cualquier cantidad de datos sin límites
• prestaciones muy altas debido al uso de discos SSD
• posibilidad de cambiar fácilmente la provisión y la capacidad requerida para cada tabla
• gestión completa de las tareas de administración requeridas

En un database de tipo DynamoDB el usuario puede especificar el mismo la capacidad de throughput aprovisionada que se requiere para las lecturas y las escrituras en el DB. Este se ocupará automáticamente de poner a disposición los recursos necesarios para realizar las operaciones.

En este caso, la arquitectura en la nube AWS seria la siguiente:


 

Comparación rápida entre RDS y DynamoDB

¿Cómo elegir el modelo correcto de DB?

4 – AWS Elasticity and Management Tools

La AWS elesticity es la función clave de los servicios Amazon en la nube. El de los recursos siempre ha sido el mayor problema de los medios/grandes servicios online: escasos en caso de avalanchas de usuarios en momentos concretos (por ej. la venta de billetes de la salida a la venta de un concierto), excesivos en caso de bajo uso en otros (por ej. cuando no hay eventos).

En términos de servidores físicos propios, en el primer caso podemos llegar a sufrir caídas en los momentos menos oportunos debido a la carga excesiva de usuarios. Así que para evitar outages, hay que comprar más hardware, contratar más operadores para su monitorización 24×7 y tener en cuenta su mantenimiento diario. Así podemos hacer frente a las subidas puntuales y hacer frente a los picos, pero el problema inverso es el resto del tiempo de uso de las máquinas, que resultan infra-utilizadas.

Entonces, ¿es posible una solución intermedia? Probablemente sí, pero la solución mejor es ajustar los recursos a la carga del momento. ¡Y mejor aún si se realiza en automático! Para hacer esto los servicios AWS se basan en este concepto lógico:


 

Si por ejemplo tenemos dos instancias EC2 corriendo en un grupo de auto escalado, el uso conjunto de un ELB y una herramienta de CloudWatch pueden determinar si es necesario añadir o quitar una instancia, según la latencia y el uso de las mismas.

Esto nos permite distribuir el tráfico sobre múltiples instancias EC2 en múltiplas zonas de disponibilidad. Al mismo tiempo el usuario puede beneficiarse de un healt check de instancias y de la posibilidad de utilizar protocolos HTTTP/S, SSL y TCP.

Más específicamente se trata de registrar las instancias como “targets”, organizadas en grupos y dirigir el tráfico hacia estos.


 

Amazon CloudWatch

Es la herramienta que se ocupa de la monitorización de las instancias en la nube y de los aplicativos de usuarios que se ejecutan sobre ella. Tiene visibilidad sobre el uso de los recursos, el rendimiento de las operaciones realizadas y básicamente sobre todos los patterns requeridos. A través de esta herramienta es además posible sacar gráficas y estadísticas de motorización y configurar alarmas, según la necesidad.