Las instancias EC2 tipo T están en el grupo de propósito general, lo cual significa que su configuración es la más estándar posible y podría usarse para cargas de trabajo (workloads) que impliquen un balanceo moderado de recursos, tanto de CPU, memoria, red y acceso al almacenamiento.

Concretamente los siguientes son los casos de uso de las instancias EC2 tipo T recomendados por Amazon Web Services:

1. En desarrollo y pruebas: ¿necesitas un lugar para probar nuevas ideas sin estresar tus principales servidores? las instancias tipo T pueden ser la respuesta, ya que manejan a la perfección picos ocasionales de CPU.
2. En sitios Web y aplicaciones de bajo tráfico: ¿tu sitio Web o aplicación no tiene tráfico masivo 24/7? las instancias tipo T podrían ser tu solución ideal, ya que tienen un costo más económico (especialmente la Txg), y puedes servir ese sistema ERP, CRM, etc. con una inversión moderada.
3. En microservicios: si tus microservicios necesitan un picos ocasionales para manejar tareas intensivas de CPU, las instancias tipo T están listas y pueden ayudar. Aunque hay otras opciones de cómputo, puedes usar este esquema y pasar a otro si la carga es intensiva o impredecible.
4. Para pequeñas bases de datos: para bases de datos que no necesitan siempre estar a pleno rendimiento, una instancia tipo T podría ser una opción eficiente y económica. Cabe señalar que si tienes muchos I/O en el disco es recomendable combinar esta instancia con volúmenes #AmazonEBS de tipo io2.
5. Para servidores de respaldo: ¿tienes servidores que están en stand-by la mayoría del tiempo?, es decir están ahí para planes de continuidad. Las instancias tipo T son ideales gracias a su modelo de rendimiento “burstable” que ayudarán hasta reactivar tu esquema principal.

Hay que tomar en cuenta que las instancias tipo T no son las más adecuadas para cargas de trabajo que requieren un alto rendimiento constante de CPU (ahí necesitaras instancias tipo C o M). pero para muchas otras tareas, son excelentes.

Hay otros tipos de instancias de propósito general y puedes ver más información en Tipos de instancias EC2 en AWS., donde encontrarás sus variantes como T4g, T3, T3a y T2.

Cada variante tienen unas características de hardware específicas, así T4g significa que usa el procesador Graviton o T3a significa que usa el procesador AMD.

La respuesta corta a esta pregunta es a través de su servicio AWS Systems Manager (con la abreviatura SSM) y en concreto con la funcionalidad Patch Manager.

Sin embargo, hay que mencionar que la solución AWS Systems Manager no solamente nos ayuda con la aplicación de parches a nivel del Sistema Operativo y a nivel del Software instalado, también nos ofrece una administración y monitorización completa de los recursos desplegados en AWS e incluso de los recursos On-premises que deseemos adicionar a su gestión.

Es realmente impresionante el nivel de gestión que se puede alcanzar con esta herramienta para toda tu infraestructura, te animo mirar todas las posibilidades en la página Características de AWS Systems Manager. Por supuesto, si deseas tener una versión resumida de esta herramienta, me dejas saber en los comentarios .

Aplicando parches en instancias EC2 en AWS

Vale resaltar que no es lo mismo parchear 2 o 3 instancias EC2 que parchear decenas, cientos o miles de instancias distribuidas en varias regiones a lo largo de AWS.

A continuación vamos a describir un conjunto de pasos para poder aplicar los parches en instancias EC2 en AWS:

El primer paso, y parte de las buenas prácticas de aprovisionamiento de recursos en AWS, es marcar los mismos a través de AWS Tags, que son etiquetas asociadas a los recursos aprovisionados en AWS que nos permitirán identificarlos y clasificarlos de acuerdo a nuestra estrategia de Gobierno TI.

Ya ingresando al servicio AWS Systems Manager o SSM, el segundo paso es usar una Línea Base (Baseline) predefinida en la opción Patch Manager de este servicio; esta es una definición de Sistema Operativo y criticidad de actualizaciones preestablecida, y que es aplicable a nuestras instancias EC2.

Claro que tú puedes crear tu propia Línea Base, si tienes algún requerimiento especial que no encuentres en las múltiples opciones que encontrarás predefinidas allí.

Luego, como tercer paso, y que mi criterio es muy recomendado, especialmente si tienes desde decenas de servidores o un nivel de continuidad de negocio que lo exige, es crear Grupos para Parches (Patch groups) en tu definición de Línea Base. La idea es identificar con una etiqueta a un grupo de instancias a parchear que contengan esa definición en sus AWS Tags.

¡Ten cuidado!, y por esto es importante tener definidos Grupos para Parches, ya que AWS no prueba los parches antes de ponerlos a disposición en Patch Manager, porque pertenecen en su mayoría a los fabricantes del Software.

AWS no prueba los parches antes de ponerlos a disposición en Patch Manager.

La definición de una ventana de cambios (Maintenance Windows) viene a ser el cuarto paso, y se la define a través del servicio AWS Systems Manager. Aquí vamos a especificar el horario, la duración y la recurrencia en la cual se va a ejecutar las acciones asociadas a la misma.

El quinto paso, y el más largo, es asociar la ventana de mantenimiento con la Línea Base y el Grupo para Parches, aunque también podrías asociarla con instancias específicas EC2 lo cual no sería recomendado y práctico.

El comando objetivo para correr la Línea Base definida es “AWS-RunPatchBaseline” y lo observarás en las opciones correspondientes en Patch Manager.

Patch Manager no admite actualizaciones de versiones principales (major versions) de Sistemas Operativos como ir de Windows Server 2019 a 2022 o RHEL 7 a RHEL 8.

¡Listo!, una vez realizado estos pasos, está automatizado el proceso de aplicación de parches en tus instancias EC2 en AWS y lo podrás monitorizar desde la opción Managed Instances en el servicio AWS Systems Manager.

Te recomiendo ver una versión más detallada de este proceso en el Blog Aplicación de parches a sus instancias de Windows EC2 con AWS Systems Manager Patch Manager de Stefan Minhas .

Conclusiones

Es completamente posible automatizar la aplicación de parches en los recursos en AWS incluso en instancias On-premises que han sido asociadas al servicio AWS Systems Manager.

AWS Systems Manager es un servicio para la gestión y monitorización de los recursos en AWS que nos permite mantener una administración adecuada de la Nube.

Patch Manager nos provee de Líneas Base predefinidas para mantener actualizados a nuestros servidores de forma automática, pero es importante comprender que AWS no prueba estás actualizaciones previamente ya que en su mayoría son de terceros, por lo que debemos considerarlo en nuestra estrategia de gestión.

Patch Manager maneja solamente actualizaciones menores (minor versions), no está pensado para hacer migraciones de versiones principales.

Hay muchas otras opciones de Patch Manager que no se han visto en esta guía de como parchear los servidores en AWS, como notificaciones, reportes y evaluación de cumplimiento; sin embargo, son muy útiles ya en un escenario empresarial y deberían considerarse.

Vamos a ver en esta ficha técnica de tipos de instancias EC2 en AWS, el grupo de Instancias de Propósito General; sin embargo, existen otros tipos de instancias para necesidades más específicas como instancias optimizadas para cómputo, para uso memoria, para procesamiento gráfico u para optimizar el acceso al almacenamiento. Puedes encontrar toda de esa oferta especializada en Tipos de Instancias en Amazon EC2.

Tipos de Instancias EC2 en AWS – Ficha Técnica – Propósito General

La siguiente ficha técnica presenta las principales características de los tipos de instancias EC2 en AWS que son consideradas de propósito general.

Cabe aclarar que el “Precio por Hora” publicado en el documento, es basado en el modelo de costos llamado “bajo demanda” (on-demand); sin embargo existen otros modelos de costo como “instancia reservada” (reserve instance) o “precio de contado” (spot price), en los cuales puede bajar significativamente el costo a cambio una compromiso a largo plazo o en periodos de tiempo establecidos.

Sin embargo, en cualquier caso, los precios de estos modelos de costo son proporcionales a los precios on-demand.

Otra aclaración importante, es que los precios varían dependiendo de la region en donde son aprovisionados, y en esta ficha técnica de tipos de instancias EC2 en AWS, se publican los precios de la región de Virginia en Estados Unidos.

¿Como elegir una instancia EC2 en AWS apropiada para mi caso de uso?

Elegir una instancia ec2 en AWS puede ser muy complicado, y a menudo solemos sobre estimar las capacidades que requerimos al aprovisionar un servidor; y claro, esto es normal ya no tenemos la información suficiente al momento de optar por una tipo de instancia u otra. Pero en general, los aspectos principales a tener en cuenta en una aplicación son: cuanto CPU es necesario para el procesamiento de información?, cuanta memoria RAM requiere para almacenamiento temporal de datos?, cuanto espacio en disco requiere para almacenar la información y cuál es la velocidad apropiada de acceso al mismo? y cuánto tráfico de datos tiene que manejar la interfaz de red que la comunica con otros servidores y/o clientes?.

En general, tenemos tres escenarios: despliegue de una nueva aplicación, despliegue de una aplicación existente o despliegue de un Producto de Software de un proveedor.

En el caso de Productos de Software, tal vez la decisión es más sencilla, pues seguramente tenemos ya especificaciones de Hardware definidas por el vendedor, las mismas que debemos tratar de cumplir eligiendo la instancia EC2 correcta. Incluso hay ya muchos Productos de Software de vendedores que traen una especificación clara para su funcionamiento en la Nube.

En el caso de aplicaciones existentes, debemos tener métricas históricas acerca del desempeño y uso de recursos informáticos On-premises (CPU, RAM, almacenamiento y Red) como soporte para seleccionar el tipo de instancia EC2 apropiada. Sin embargo, hay que tomar en cuenta también otros aspectos de la aplicación como su arquitectura, sus dependencias y las estrategias de resiliencia definidas por el negocio, ya que no hacerlo nos va a significar dolores de cabeza relacionados con reinstalaciones, reconfiguraciones y sobre todo problemas de latencia.

El último y más frecuente caso suele ser las aplicaciones nuevas, en donde no tenemos un histórico de funcionamiento, pero si podemos hacer una proyección a tres meses de concurrencia de usuarios, número de transacciones diarias y capacidades mínimas del Software base. Partiendo de allí, la recomendación es elegir una instancia EC2 en AWS, lo más modesta posible, y medir la utilización de recursos en la misma, y el rendimiento de la aplicación semanalmente de forma que podamos ir aumentando las capacidades del tipo de instancia EC2 inicial, o cambiar de tipo de instancia para optimizar costos.

Es clave usar inicialmente un modelo de precios On-demand, que aunque no es el menos costoso, te permitirá en los 3 a 6 primeros meses aprender de la real demanda de tu aplicación o Productos de Software para luego confirmar o cambiar el tipo de instancia adecuada; para luego adquirir la misma en un modelo de precios más conveniente como el Reservado o Spot.

Si hablamos de otro caso como aprovisionar un servicio NFS, un FTP, una base de datos MySQL, o algo similar; pero hacerlo a través de una instancia EC2 tal vez no sea el mejor camino dado que AWS tiene servicios especializados para estos fines y la recomendación siempre será usar preferentemente tal servicio.

Conclusiones

Fue muy interesante revisar estas características técnicas, pues aclaran el propósito de cada tipo de instancia. Suele ser confuso y abrumador leer tanta documentación o tener tantas opciones, y esta ficha técnica puede ayudarte en el primer momento a saber que camino profundizar.

Estos son los puntos importantes que en mi opinión destacan en esta ficha técnica de tipos de instancias EC2 en AWS:

• Ya tenemos una opción para obtener una máquina Mac a un precio excelente y cubrir la necesidad de desarrollos para esa plataforma.
• Elegir T4g siempre que se pueda, esto significa siempre que el software base que necesitemos este disponible en esta arquitectura, porque supone menores costos. si la aplicación no soporta AMD la elección natural sería T3.
• Elegir T3a o T3 por sobre T2, considerando también la compatibilidad del software base. Aunque la mayoría de Sistemas Operativos y programas son ampliamente soportados en procesadores AMD.
• Si la necesidad es un servidor mediano o grande, ir por las instancias M; por ejemplo, servidores de aplicaciones como SAP, Sharepoint, IAS, JBOSS, etc.
• De los servidores M la mejor opción es el M6g por costo-rendimiento, pero de igual forma el software base es clave aquí. Los procesadores Graviton son espectaculares y cuestan menos por su significativo ahorro de energía lo que supone menos contaminación también ;). Puedes encontrar más en AWS y sus procesadores Graviton.
• Si tienes un poco mas de presupuesto te recomiendo usar un M7g sobre un M6g ya que es solo un 5% más costoso pero te da em promedio un 25% mayor performance, lo cual parece ser un buen trato.
• Si requieres alto tráfico de red (throughput) piense en instancias M5n o M5zn.

** Finalmente, te animamos a contribuir con ideas para mejorar esta Ficha Técnica de Instancias en AWS, puedes obtener una copia del archivo original en el enlace Tipos de Instancias EC2 en AWS – Ficha Técnica para tus modificaciones

EC2 (Elastic Cloud Compute) es un servicio que nos ofrece capacidad de cómputo, y dentro de su oferta de configuraciones presenta tipos de instancias con procesadores Graviton basados en núcleos Arm Neoverse de 64 bits.

Estos procesadores son creados desde el inicio pensando en la optimización del Cloud Computing, principalmente en la relación procesamiento / watt.

En el 2018 AWS anunció su primera generación en la familia de instancias A1. Estas instancias son diseñadas principalmente para cómputo de servidores web, microservicios y bases de datos medianas.

En el re:invent del 2019 anunciaron su nueva versión Graviton2 mucho más potenciada y optimizada para familias de instancias M6g, C6g y R6g.

• M6g como nueva generación de la familia para servidores web, microservicios y bases de datos medianas.
• G6g para cargas de trabajo HPC (High Compute Performance).
• R6g para instancias que requieran de una RAM optimizada, como bases de datos PostgreSQL, sistemas de cache Redis, etc.

Ofrecen una mejora de hasta el 40% frente a familias de instancias con arquitectura x86 que hacen el trabajo similar, como un T3 o una M5; y además disponible en configuraciones con más de 4 núcleos.

Excelentes noticias!, entonces si quieren optimizar costos con un mejor rendimiento, pueden optar por estos procesadores y su amplia gama de servicios y sistemas operativos soportados con AWS y sus procesadores Graviton.

Tipos de Bases de Datos

Antes de empezar a describir las alternativas queremos puntualizar en esta sección los tipos de Bases de Datos comunes que podemos implementar en AWS, para posteriormente analizarlas cada una:

• Relacionales: aquí tenemos las tradicionales que se conceptualizan en base a relaciones de datos, como por ejemplo PostgreSQL, Oracle o SQL Server.
• NO SQL: aquí tenemos las bases de datos que definen a los mismos como Documentos y/o por Clave-Valor, como MongoDB o Redis.
• Datawarehouse: son aquellas usadas para OLAP, en donde se agrupan y procesan grandes cantidades de diferentes fuentes de datos para obtener un resultado, por ejemplo Teradata o Oracle Exadata.

Bases de Datos Relacionales

AWS nos ofrece seis soluciones de Base de Datos como Servicio (DBaaS) que son las siguientes: SQL Server, Oracle, MySQL Server, PostgreSQL, Aurora y MariaDB.

Todas estas incluyen el licenciamiento de uso (si se requiere) y la gestión de actualizaciones y updates del Sistema Operativo, incluido en el servicio, por lo que no tendrá que preocuparse de estos aspectos y costos.

Adicionalmente a la caracterización de cada una, AWS proporciona servicios de Alta Disponibilidad de Disaster Recovery para cada engine, de forma que puede automáticamente recuperarse y gestionar los respaldos; para esto usa Snapshots y varios Data Centers (AZ).

Puede optar por un servicio post pago por hora (on-demand) o pre pago por años (upfront) para el uso, y, tiene al alcance varias configuraciones con diferentes características de RAM y CPU e IOPS (I/O por segundo), además de múltiples opciones de auto escalamiento y monitoreo.

En cuanto a seguridades, se puede activar la encriptación de datos que complementado con redes privadas, administración de accesos de red con firewall (Security Groups) y gestión de usuarios y accesos (IAM) aseguran completamente la información.

Bases de Datos No SQL

AWS ofrece DynamoDB, ElastiCache (Redis y Memcached) como alternativas DBaaS, soluciones orientadas a Documentos y Clave-Valor completamente tolerantes a fallos, altamente disponibles y extremadamente escalables, con latencia de entre milisegundos a microsegundos según la configuración.

DynamoDB es operable a través de un API de acceso y a través de la consola de Administración y funciona completamente en el sentido Serverless. La característica Serverless nos permite solo preocuparnos por crear definiciones, y todo el almacenamiento, respaldos, alta disponibilidad y escalamiento es completamente transparente al uso.

ElastiCache tiene dos opciones Redis y Memcached, que funcionan con el protocolo propio, por lo que no requieren algo adicional en las aplicaciones.

Se puede optar por el uso post pago, tanto por petición o por capacidad provisionada, lo que significa que pagamos por el número de peticiones realizadas en un período o por hora de disponibilidad de una capacidad provisionada dependiendo del servicio. También existe la opción de pre-pago por nodo (instancia) reservada entre 1 a 3 años.

Tienen características de Backup y Restore automático y en el caso de DynamoDB cuenta con el concepto PITR (Point in Time Recovery) llegando a recuperar datos en le periodo de 5 minutos a 35 días en el pasado.

En cuanto las seguridades los datos pueden o son encriptados (dependiendo del engine) usando KMS, lo que de igual forma sumado a estrategias de VPN, Direct Connect, y, gestión de usuarios y accesos (IAM) aseguran completamente la información.

Bases de Datos Datawarehouse

Presentamos en esta sección al Servicio de Amazon Redshift como DBaaS, diseñado para gestionar un Datawarehouse y/o Business Intelligent.

Se trata de una base de datos relacional con excelente performance que puede escalar en orden de los Pentabytes y es almacenada por columna y no por registro, en el concepto “Store Data”, lo que reduce el IOPS (I/O por segundo).

Tiene la opción de gestión de backups automáticos con periodos de retención de 1 a 35 días y cuenta con opciones de configuración por nodos, desde un solo nodo hasta un máximo de 128 nodos. La ventaja de múltiples nodos, significa más computo en paralelo consiguiendo procesar datos y cálculos más rápidamente y tener indicadores en tiempo real.

De igual forma se puede optar por post pago (on-demand) o pre pago (upfront) de 1 a 3 años. El costo esta en relación al número de nodos utilizados/reservados y la configuración de RAM y CPU de cada nodo. Además se cancela un costo por backups y transferencias de datos entre lugares de la VPC (Virtual Private Cloud).

En cuanto a las consideraciones de seguridades, Redshift usa SSL para el tránsito de información y los datos están cifrados con AES-256. De igual forma como en los anteriores escenarios las estrategias firewall (Security Groups), redes privadas y gestión de usuarios y accesos (IAM) complementa la completa seguridad de la información.

EC2 y las Bases de Datos

Evidentemente existe la opción, completamente factible, de gestionar una Base de Datos de forma manual, a través del servicio IaaS AWS Elastic Cloud Computing (EC2).

EC2 nos permitirá provisionar Servidores en AWS con diferentes opciones de Sistemas Operativos y configuraciones en capacidad, como la RAM , el CPU y el Disco Duro, si desea saber más puede ver la Introducción al uso de Servidores en AWS.

Estos servidores combinados con discos de almacenamiento sean Elastic Block Storage (EBS) o Elastic File System (EFS) y un estratégía de Recuperación y Respaldos, nos dan la posibilidad de tener cualquiera de las altenativas descritas (incluso DynamoDB) implementadas manualmente de acuerdo a nuestro requerimiento.

En este escenario es importante considerar que los parches y actualizaciones del Sistema Operativo y el engine de Base de Datos son responsabilidad del usuario.

Otro aspecto importante es que los temas de Failover y Continuidad de Negocio se debe gestionar igualmente de forma manual, con estrategias como disponer nuestras Bases de Datos en diferentes AZ (Data Centers) y/o Regiones y uso de herramientas relacionadas.

En cuanto al tema de costos, se debe considerar aquellos relacionados a las instancias EC2, asi como los discos EBS y/o EFS utilizados, y probablemente la tranferencia de datos entre AZ y/o Regiones que demandaría un esquema de alta disponibilidad (HA).

Declaración

Existen muchas otras soluciones en AWS menos frecuentes pero disponibles, que no se mencionaron en esta Introducción a Bases de Datos en AWS, por temas de tiempo y al ser una introducción.

Las enumeramos con el fin de que ustedes puedan en algún momento investigar más; por supuesto si desean profundizar en alguna lo pueden solicitar en los comentarios. Los Servicios de Base de Datos son: DocumentDB, Keyspaces, Neptune, Timestream y QLDB.

Pensamientos Finales

Esperamos que les sea útil esta Introducción a Bases de Datos en AWS, y podamos haber provisto un vistazo, de forma muy general, a las opciones que disponen aquí.

Hemos visto las alternativas más omunes en diferentes casos e uso de las Bases de Datos y las cuestiones principales relacionadas a las características, su forma de uso, las configuraciones, los costos y las seguridades.

Les animamos a solicitar en los comentarios y/o redes sociales si desean profundizar en algun tema de los revisados.

EC2 es un servicio con el cual en segundos podemos provisionar máquinas virtuales o físicas para nuestro uso.

Donde funcionan

Estas máquinas son ubicadas en un Data Center (conocido en AWS como Availability Zone), dicho Data Center es respaldado por al menos un Data Center en un mismo Centro de Computo ubicado en alguna Región del mundo. Actualmente hay 24 Regiones a lo largo de todo el mundo.

Como se provisionan

Podemos optar por provisionar un servidor a demanda (On Demand), un servidor fijo nuestro (Reserved), un servidor usando posible recursos disponibles y en oferta (Spot) o un servidor fijo nuestro y en un hardware dedicado a nosotros (Dedicate Host).

Dependiendo de la opción de provisionamiento podríamos elegir pagar el costo por hora de computo o por periodos de hasta tres años.

En esta Introducción al uso de Servidores en AWS, también queremos mencionar que EC2 cuenta con tipos de servidores creados o pensados para diferentes tipos de cómputo, así tenemos entre otros:

• Optimizados para uso de CPU.
• Optimizados para uso de GPU.
• Optimizados para uso de Memoria.
• Optimizados para uso de Almacenamiento.
• De propósito General.

Existen actualmente 13 familias de servidores de las cuales se puede elegir y con más o con menos recursos de computo.

Usando plantillas

AWS además provee plantillas de servidores (AMI), que especifican como se va a provisionar un servidor; desde su tecnología de virtualización, pasando por el Sistema Operativo, hasta software ya pre-instalado. En el caso de Sistemas Operativos, muchos de ellos ya tienen incluido el licenciamiento.

Finalmente, y con el objeto de no hacer más larga la introducción a servidores en AWS, EC2 presenta innumerables ventajas automatizadas, y rápida y fácilmente podemos respaldos, auto escalamiento, monitoreo, resilencia, etc.

Esperamos que esta breve descripción de 1 de los servicios (oportunidades) de AWS sea de su utilidad y les animamos a comentar sus dudas.

AWS ha venido desde hace algún tiempo trabajando en mejorar la forma de desplegar aplicaciones en Amazon EC2, dado que este proceso tenía muchas oportunidades de mejora ha creado una nueva herramienta pensada desde cero para hacer simple y rápido el despliegue de aplicaciones en Amazon EC2.

La idea es pasar de nuestra visión de la infraestructura hacia la implementación rápidamente y dejar los conceptos comunes de una arquitectura en la nube como red, blanaceadores, pipelines, storage, etc. se autogeneren de forma confiable y eficiente.

Más en: Introducing AWS Copilot