El qué, el por qué y el cómo de migraciones de SQL Server a AWS.

Por Francisco Fagas, Arquitecto de Soluciones senior en AWS,
Rene Martínez, Arquitecto de Soluciones senior en AWS.

Por qué migrar

El elemento que más potencia el uso de bases de datos comerciales en la actualidad no son las funcionalidades, no es el rendimiento y evidentemente menos el costo, es la inercia. Inercia que se va generando a lo largo de los años de uso de estos productos que hace parecer muy difícil realizar un cambio a un motor de base de datos libre y moderno. Este efecto es real y predomina en muchos clientes a pesar de que existen razones suficientes para migrar, razones como:

• Costo: estas bases de datos comerciales son costosas, no solo desde el punto de vista de licenciamiento, que a veces representa el triple del costo de hardware, sino de soporte y mantenimiento
• Propietarias: se cuenta sólo con las funcionalidades específicas de cada motor sin posibilidad de utilizar otras a diferencia de la innovación y flexibilidad que brinda el “software libre”
• Términos contractuales: estos proveedores usualmente operan con contratos a largo plazo con clausulas que encarecen más su terminación que su renovación. Otro punto es que hay ciertas características, estructuras y sintaxis que funcionan exclusivamente en cada uno de los motores.
• Licenciamiento: los proveedores cambian sus términos de licenciamiento de forma unilateral sin importar el impacto que esto tenga en sus clientes. Por ejemplo, hemos visto como duplican los costos de correr sus productos en una nube pública que no sea la propia. No brindan soporte a algunas funcionalidades si la base de datos no opera “On Premises” o en su nube. Y más recientemente, hemos visto que sencillamente no permiten ejecutar las últimas versiones de sus productos fuera de su oferta de nube.
• Auditorias. hemos conversado con grandes corporaciones a nivel mundial que utilizan bases de datos comerciales, y la gran mayoría ha recibido, en algún momento, notificaciones para ser auditadas. Auditorias que son obligatorias y que están diseñadas para encontrar irregularidades, que una vez encontradas, implican multas multimillonarias o incluso litigios judiciales.

Por estos motivos, en AWS hemos construido varias herramientas, servicios y programas que simplifican las migraciones de base de datos hacia nuestra nube, ya sea manteniendo el mismo motor de base de datos, o bien migrando a una variante libre. En este blog post abordaremos cuales son los caminos de migración más adecuados, las herramientas disponibles y las buenas prácticas que existen.

Hacia qué servicio migrar

Antes de iniciar su proceso de migración de sus bases de datos basadas en Microsoft SQL Server, es importante analizarlas para entender su complejidad, compatibilidad y costos de migración. Esto le brindará mayor información acerca de las dependencias de sus aplicaciones y las relaciones con sus bases datos para construir y evaluar una estrategia de migración que utilice el servicio que más se adecue a sus necesidades.

En AWS, sus bases de datos SQL Server pueden ser migradas hacia (1) instancias auto-gestionadas de Amazon Elastic Compute Cloud (EC2), proporcionando capacidad de computo (servidores virtuales) elástica y segura, (2) Amazon Relational Database Service (RDS) para SQL Server, nuestro servicio de bases de datos relacionales totalmente administrado para SQL Server, (3) Amazon Relational Database Service (Amazon RDS) Custom es un servicio de base de datos administrado para aplicaciones legadas, personalizadas y empaquetadas que requieren acceso al entorno de base de datos y sistema operativo, (4) Amazon Aurora, nuestro servicio de base de datos relacional totalmente administrada compatible con MySQL y PostgreSQL, que les brinda el rendimiento y disponibilidad de bases de datos comerciales a una décima parte del costo.

El interrogante que surge es qué tipo de migración realizar. Por un lado, si mantener el motor de base de datos (migración homogénea) o cambiarlo (migración heterogénea) durante el proceso de migración. Por otro, si mantener el esfuerzo operativo actual de mantenimiento una vez finalizada la migración. Esto nos permite vincular nuestra estrategia de migración teniendo en cuenta tipo y modelo operacional con los servicios de AWS.

¿Cuál es la diferencia entre RDS y RDS Custom para SQL Server?

Con Amazon RDS Custom para SQL Server, los clientes pueden personalizar el host y el sistema operativo de su servidor de base de datos y cambiar algunas de las configuraciones de la base de datos para permitir funciones adicionales o eventos de aplicaciones de terceros que requieren acceso privilegiado al sistema operativo. Gracias a los beneficios de ahorro de tiempo de un servicio administrado, Amazon RDS Custom para SQL Server permite que el cliente dedique más tiempo a generar valor a través de actividades de innovación en lugar de administrar la infraestructura de una manera muy similar a como lo hace Amazon RDS en general. Amazon RDS Custom maneja por Ud. tareas como copias de seguridad, monitoreo y otras operaciones relacionadas con la base de datos. También proporciona a la infraestructura de bases de datos escalabilidad basada en nube para mantenerse al día con el ritmo de crecimiento del negocio.

En su lanzamiento, RDS Custom para SQL Server se dirige principalmente a cargas de trabajo de SQL Server que:

• Requiere un control granular sobre el sistema operativo o la base de datos para habilitar funciones como CLR, XP_cmdshell o servidores vinculados que no se ofrecen con RDS SQL Server.
• Habilite el lift and shift de aplicaciones como Microsoft Sharepoint o Microsoft Dynamics con mínimos esfuerzos/cambios.
• Cree una configuración de recuperación ante desastres junto con un entorno autogestionado (instancias locales o de Amazon EC2) utilizando características como SQL Server Always On Availability Group
• No se puede migrar a Amazon RDS para SQL Server debido a la falta de acceso a nivel de host, el límite de 100 bases de datos por instancia o las funciones no admitidas en la oferta estándar de RDS.

Además de consideraciones y/o requerimientos técnicos (por ejemplo, tamaño de las bases de datos, IOPs, redes, dependencias entre bases de datos, RPO, RTO y SLAs) es importante considerar los siguientes puntos:

• Licenciamiento: las opciones de licenciamiento son uno de los factores importantes al momento de seleccionar el servicio para ejecutar su base de datos.

En AWS, puede hacer uso de instancias con licencia incluida y estar en conformidad con el licenciamiento Microsoft con Amazon EC2 o Amazon RDS para SQL Server, pagando según su uso sin costos anticipados ni inversiones a largo plazo. Bajo este modelo, AWS administra la conformidad de las licencias, le permite el uso de versiones actuales y legadas, y no son necesarias las licencias de acceso de cliente (CAL) de Windows Server.

Si usted ya compró y posee licencias de SQL Server, tiene la opción de traerlas (BYOL, sujeto a los términos de licenciamiento de Microsoft). Lo que usted debe tener claro es si esas licencias tienen o no Software Assurance, que permite tener acceso a los beneficios de movilidad de licencias. Si no cuenta con Software Assurance y la compra de las licencias o la renovación del contrato que incluye las licencias fue antes del 1 de octubre de 2019 puede utilizar nuestros host dedicados de Amazon EC2 para ejecutar sus instancias de bases de datos. En caso de contar con Software Assurance activo para sus licencias de Microsoft SQL Server, el beneficio de movilidad de licencias le permite traer sus licencias a instancias de Amazon EC2. (importante consultar los términos de licenciamiento de Microsoft, y chequear si hay algún cambio en las condiciones anteriormente descritas).

La siguiente calculadora le puede ayudar a recomendarle la mejor opción de Amazon EC2 considerando su licenciamiento de Windows y SQL Server.

• Soporte de Versiones: otro de los aspectos a considerar es la versión y edición de SQL Server que está utilizando para evaluar si están soportadas, sobre todo cuando está evaluando migrar hacia Amazon RDS para SQL Server. Puede revisar las versiones soportadas por Amazon RDS aquí.

• Funcionalidad de las ediciones de SQL Server: relacionado con el punto anterior, recomendamos analizar y entender que funcionalidades y características de su edición y versión de SQL Server están siendo utilizadas, ya que un cambio de ediciones (por ejemplo, Enterprise a Standard) puede implicar una reducción de costos de licenciamiento.

• Tiempo de inactividad durante la migración: finalmente, identificar y determinar la ventana de migración disponible para planificar cómo ejecutarla y establecer si es necesario realizarla en línea u offline.

Cómo migrar

Entendidas las razones y los destinos de la migración, enfoquémonos en las herramientas que ofrece AWS para facilitar este proceso, sin perder de perspectiva el tipo de migración que vayamos a realizar.

Si es una migración del tipo heterogénea, por ejemplo, de SQL Server a PostgreSQL, es necesario transformar el esquema actual, o sea, tablas, vistas, tipos de datos y funciones hacia uno compatible en el motor destino. Para realizar esta tarea de forma automática contamos con AWS Schema Convertion Tool. Tal cómo su nombre lo indica, convierte la mayoría de los objetos de la base de datos origen al formato equivalente en el destino. Asimismo, es capaz de recomendar cual es el motor destino con mayor grado de compatibilidad, como se observa a continuación.

Para cada objeto de la base de datos que no pueda ser convertido automáticamente, AWS Schema Convertion Tool genera una alerta e indica cual es el procedimiento oficial con referencias a la documentación para ejecutarlo manualmente. Dichas alertas y recomendaciones forman parte de un reporte que incluye estimaciones de complejidad, como vemos en la siguiente imagen.

Esta herramienta se puede instalar en sistemas operativos Windows, MacOS, Linux Fedora (rpm) y Linux Ubuntu (deb). Es compatible con 16 tipos de bases de datos, incluyendo motores relacionales (OLTP), analíticos (OLAP) y no relacional (NoSQL), tanto en bases de datos de origen como de destino en AWS.

Si la migración es homogénea, o ya se realizó la conversión del esquema, el siguiente paso es migrar los datos. Para esta tarea contamos con el servicio AWS Database Migration Service (DMS), que es compatible con los mismo tipos y motores que AWS Schema Convertion Tool. Es un servicio administrado compuesto por varios componentes que en su conjunto hacen posible una migración automática, altamente disponible, eficaz, segura, costo efectiva y consistente, no solo para información histórica, sino también para cambios constantes que ocurren en la base de datos origen.

Pero, ¿porqué se consiguen estas características al migrar con AWS DMS?

• Automática. Sólo es necesario apuntar hacía la base de datos de origen, de destino y el servicio se encargará del descubrimiento de los objetos, de ir migrando poco a poco los datos existentes y luego ir replicando los cambios que sucedan mediante la lectura de los logs de transacciones.
• Altamente Disponible. Es posible activar una migración con instancias Multi-AZ y tener un respaldo automático en caso de falla en el almacenamiento. Esta opción es recomendada sobretodo para las tareas de replicación de datos continuas que podrían estar ejecutándose por largos períodos de tiempo.
• Eficaz. Los discos SSD utilizados por las instancias de migración pueden aumentar hasta 3000 IOPS. También puede activarse una opción de carga de tablas en paralelo si el motor de base de datos de origen soporta carga extra. Las instancias son compatibles con las familias basadas en AWS Nitro System C5 y R5 ofreciendo hasta 96 CPUs y 768 GB de RAM.
• Segura. Es posible conectarse a la base origen de forma privada mediante un enlace dedicado o conexión VPN. Es posible almacenar las credenciales de las bases de datos en AWS Secrets Manager y utilizar roles de AWS Identity and Access Management (IAM) para acceder a los servicios de AWS. También es posible encriptar los datos en reposo con llaves de encriptación y los datos en tránsito mediante una conexión TLS a las bases de datos.
• Costo efectivo. El servicio genera gastos solamente durante el proceso de migración – es posible migrar una base de datos de un terabyte de tamaño por unos costos de $3 aproximadamente. Otro punto es que, si el destino de la migración es Amazon Aurora, Amazon Redshift, Amazon DynamoDB o Amazon DocumentDB se puede utilizar el servicio de forma gratuita durante 6 meses.
• Consistente. Adicionalmente a las métricas y trazas que genera automáticamente el servicio en Amazon CloudWatch y Amazon CloudTrail, es posible realizar una validación automática de los datos migrados tal como se muestra en la siguiente imagen.

Ya vimos como se pueden convertir los esquemas y migrar los datos de forma relativamente fácil y segura, pero probablemente, muchos se estén preguntando que pasa con la aplicación, sobretodo en aquellas que no incorporen una capa de abstracción de la base de datos (por ejemplo un Object Relational Mapping, ORM).

Además de la conversión de código aplicativo que provee AWS Schema Convertion Tool, en re:Invent 2020 (evento anual de AWS enfocado a clientes y socios), anunciamos Babelfish for PostgreSQL. Este nuevo servicio, por el momento en preview, permite realizar migraciones de punta a punta sin necesidad de reescribir el código fuente de las aplicaciones.

Con Babelfish no es necesario cambiar los drivers ni modificar el código fuente. Tampoco significa depender de T-SQL para siempre, sino que uno puede ir modernizando su aplicación para que incorpore funcionalidades nativas de PostgreSQL en paralelo a las legadas de SQL Server. El objetivo es que uno pueda hacer una migración tranquila, a su ritmo y que la aplicación continúe operando como si estuviese conectada a la misma base SQL Server de siempre.

¿Porqué PostgreSQL? Porque es un motor de base de datos completamente guiado por la comunidad que lleva alrededor de 20 años intentando ofrecer una solución similar. Además,  últimamente PostgreSQL ha venido ganando popularidad frente a los otros motores de bases de datos más adoptados (ver imagen, más detalles en el estudio original).

Optimizaciones

Hay muchas formas en las que uno puede optimizar las cargas de trabajo de Microsoft SQL en AWS. A continuación, repasaremos algunas de las opciones que, según nuestra experiencia, tienen el mayor impacto positivo para nuestros clientes.

Licenciamiento:

Hemos observado que, al momento de elegir el tipo y tamaño de una instancia para SQL Server, la memoria es el factor determinante la mayoría de las veces. Por ejemplo, si una base de datos requiere 128 GB de memoria para operar de manera óptima, lo indicado sería seleccionar una instancia optimizada para memoria para obtener el mayor rendimiento de la manera más rentable.

Las familias de instancias de AWS establecen proporciones de vCPU por memoria; por ejemplo, la familia r5 ofrece 8 GB de memoria por vCPU, la familia m5 ofrece 4 GB de memoria por vCPU y la familia c5 ofrece 2 GB de memoria por vCPU.

Por lo tanto, y continuando con nuestro ejemplo de 128 GB de memoria, la mayoría de las veces sería conveniente optar por una instancia r5.4xlarge ya que la familia r5 está optimizada para la memoria. Esta instancia proporciona 16 CPU virtuales. En ciertos casos, serán necesarias todas las vCPU para ejecutar la carga de trabajo de SQL de manera eficiente, pero a menudo vemos que menos vCPU son suficientes (normalmente el 50%).

Asimismo, el factor más importante que afecta el costo de una instancia de SQL Server, ya sea local, en Amazon EC2 o en Amazon RDS, es el costo de las licencias de SQL. En el caso de SQL Server, el licenciamiento se realiza en función a la cantidad de cores. Mientras más cores tenga la instancia, más licencias necesitará, sean utilizadas o no.

Para ayudar a evitar esta situación, AWS ofrece la capacidad de controlar la cantidad de vCPU disponibles para la instancia y expuestas al sistema operativo durante el lanzamiento de una nueva instancia de Amazon EC2. Con este método, usted puede reducir la cantidad de vCPU activas y, por lo tanto, la cantidad de licencias SQL necesarias. Vale la pena señalar que esta opción sólo es efectiva si uno trae sus licencias SQL a AWS. Si usa instancias con licencia SQL incluidas, la optimización del recuento de CPUs no reducirá el gasto en licencias.

Almacenamiento:

Pasemos a la tecnología: cómo optimizar el almacenamiento, la configuración y los tipos de instancia para cargas de trabajo SQL. Pero primero, hagamos un repaso rápido de los componentes internos de almacenamiento de una base de datos SQL Server.

SQL Server tiene 4 tipos de archivos principales:

• Archivos de registro de transacciones (“Transaction Log files” – .ldf): las transacciones y/o modificaciones se escriben en estos registros antes de escribirse los datos.
• Archivos de datos (“Data Files” – .mdf, .ndf): los datos se almacenan aquí y se accede a ellos de forma secuencial o aleatoria según las consultas SQL.
• Archivos de bases de datos temporales, o “TempDB”, se utilizan cuando el sistema está realizando operaciones de bases de datos temporales y son muy aleatorios.
• Archivos de copia de seguridad (“Backup files”): se utilizan para copias de seguridad de bases de datos y, por lo general, se accede a ellos de forma secuencial.

Los grupos de archivos de SQL Server pueden utilizarse para dividir objetos de la base de datos en varios archivos que luego pueden alojarse en discos separados.

Cuando se trata de almacenar sus datos de SQL Server, Amazon Elastic Block Store (EBS) es la opción más utilizada dentro de AWS.

Un volumen de Amazon EBS es un dispositivo de almacenamiento duradero basado en bloques que puede adjuntar a sus instancias. Después de adjuntarlo a una instancia de Amazon EC2, puede usarlo como lo haría con un disco duro físico. Los volúmenes de EBS son elásticos: para volúmenes de generación actual adjuntos a tipos de instancias de generación actual, puede aumentar dinámicamente el tamaño, modificar la capacidad de IOPS aprovisionada y cambiar el tipo de volumen en vivo.

Amazon EBS ofrece una variedad de opciones que le permiten optimizar el rendimiento del almacenamiento y el costo de su carga de trabajo. Estas opciones se dividen en dos categorías principales:

• almacenamiento respaldado por SSD: para cargas de trabajo transaccionales, como bases de datos y volúmenes de arranque (donde el rendimiento depende principalmente de IOPS), puede escoger entre discos de uso general SSD de última generación (gp3) que proporcionan un rendimiento independiente a la capacidad de almacenamiento y a un precio por GB hasta un 20% más bajo que los volúmenes gp2, la generación anterior (gp2) que equilibran el precio y el rendimiento para una amplia variedad de datos transaccionales, o también puede optar por un mayor rendimiento a través de discos Provisioned IOPS SSDs (io1 y la nueva opción io2) para cargas de trabajo transaccionales sensibles a la latencia.
• almacenamiento respaldado por HDD: para cargas de trabajo intensivas en rendimiento, como procesamiento de registros y copias de seguridad (donde el rendimiento depende principalmente del MB/s throughput), puede escoger entre “Throughput Optimized HDD” (st1) para cargas de trabajo intensivas en rendimiento de acceso frecuente y “Cold HDD” (sc1) de menor costo para datos de acceso menos frecuente.

Para cargas de trabajo de SQL Server, los volúmenes gp3, gp2, io2 e io1 son candidatos óptimos para el almacenamiento de datos y archivos de registro.

El almacenamiento de instancias (instance store) ofrece almacenamiento temporal a nivel de bloque para su instancia y consta de uno o más volúmenes expuestos como dispositivos de bloque. El tamaño de un “instance store”, así como la cantidad de dispositivos disponibles, varía según el tipo de instancia. Por ejemplo, las instancias r5d, z1d e i3 tienen un almacenamiento de instancias NVMe extremadamente rápido.

Este almacenamiento se encuentra en discos que están conectados físicamente al host. Los volúmenes del tipo “instance store” son ideales para el almacenamiento temporal de información que cambia con frecuencia, como búferes, cachés, datos y/o contenidos temporales, o para datos que se replican en una flota de instancias, como un grupo de servidores web con balanceo de carga. En relación a SQL Server, los “instance store” son una gran opción para los archivos TempDB.

Amazon FSx para Windows File Server proporciona almacenamiento de archivos escalable, altamente confiable y totalmente administrado al que se puede acceder a través del protocolo Server Message Block (SMB).

Amazon FSx para Windows File Server se basa en Windows Server y ofrece una amplia gama de funciones administrativas, como cuotas de usuario, restauración de archivos de usuario final e integración de Microsoft Active Directory (AD). El servicio también ofrece opciones de implementación en una o varias zonas de disponibilidad, copias de seguridad totalmente gestionadas y cifrado de datos en reposo y en tránsito.

Puede escalar el almacenamiento y cambiar el rendimiento de su sistema de archivos en cualquier momento.

Con la funcionalidad de uso compartido de archivos continuamente disponible, Amazon FSx para Windows File Server es ideal para su uso como almacenamiento compartido para clústeres de failover de Microsoft SQL, lo que reduce la necesidad de implementar “SQL Enterprise Edition” para soportar grupos de disponibilidad “AlwaysOn”, lo cual le permite ahorrar licencias y simplificar la configuración y la administración.

Amazon FSx para Windows File Server proporciona dos tipos de almacenamiento que permiten optimizar el costo y el rendimiento acompañando las necesidades de su carga de trabajo.

• unidades de disco duro (HDD): está diseñado para un amplio espectro de cargas de trabajo, incluidos directorios de inicio, recursos compartidos de usuarios y departamentos, y sistemas de administración de contenido.
• unidades de estado sólido (SSD): está diseñado para las cargas de trabajo de mayor rendimiento y sensibles a la latencia, inculyendo bases de datos, cargas de trabajo de procesamiento de medios y aplicaciones de análisis de datos.

Implementación típica de Microsoft SQL para alta disponibilidad y recuperación de desastres On-Premises

 Cuando se planifica un despliegue de SQL Server en alta disponibilidad, normalmente hablamos de una instancia para “failover” o de un grupo de disponibilidad. La figura de abajo muestra un diseño de grupo de disponibilidad “Always On” con dos nodos configurados con “commit síncrono en el centro de datos principal, y un nodo configurado con “commit” asíncrono en el centro de datos de recuperación de desastres (DR).

Este diseño debe proteger ante la caída de cualquiera de los nodos en el centro de datos primario, así como de una falla completa del mismo. Si eso sucediera, el tercer nodo podría activarse en el centro de datos de DR, pero con cierta cantidad de pérdida de datos debido al “commit” asíncrono, después de una invocación manual.

Implementación en AWS con Multi-AZ.

 En AWS, no es necesario tener un tercer nodo en un sitio de recuperación ante desastres. Las zonas de disponibilidad dentro de AWS son centros de datos discretos y geográficamente separados conectados a través de enlaces de muy baja latencia. En AWS, en lugar de ejecutar su clúster SQL Server de dos nodos en un único centro de datos corporativo principal, puede hacerlo con un nodo en una zona de disponibilidad y otro en una segunda zona de disponibilidad. Los enlaces entre zonas de disponibilidad permiten que, en la mayoría de los casos, pueda ejecutar su clúster en modo síncrono sin que el rendimiento se vea afectado y, por lo tanto, puede eliminar el requisito de un tercer nodo.

Si la base de datos tiene un rendimiento extremadamente alto, por supuesto puede ejecutar dos nodos en una zona de disponibilidad, y un tercer nodo en una segunda zona de disponibilidad. Muchas veces esto no suele ser necesario, y por eso mismo recomendamos ejecutar una prueba de concepto antes de comprometerse con un diseño de 3 nodos. En los casos más extremos puede incluso utilizar grupos de ubicación de clústeres (“Cluster Placement Groups”) para asegurarse de que sus nodos estén cercanos dentro de una zona de disponibilidad para obtener el máximo rendimiento de la red y la menor latencia posible.

Amazon FSx para Windows File Server simplifica las implementaciones de SQL Server en alta disponibilidad.

 Los grupos de disponibilidad no son la única forma en que puede ejecutar sus implementaciones SQL Server en alta disponiblidad en AWS. También puede usar instancias de “failover”, con almacenamiento compartido proporcionado por Amazon FSx para Windows File Server.

Por lo general, en las instalaciones, es raro encontrar una solución de almacenamiento que pueda proporcionar almacenamiento compartido en varios centros de datos, por lo que los grupos de disponibilidad y las licencias de SQL Server Enterprise eran a menudo la única opción.

Con Amazon FSx para Windows File Server, usted tiene un servicio administrado que proporciona recursos compartidos de archivos disponibles continuamente para sus instancias de SQL Server, en varias zonas de disponibilidad. Esto significa que puede tener fácilmente un failover automático entre las zonas de disponibilidad, mientras utiliza licencias de SQL Standard, y tampoco necesita implementar, administrar ni pagar licencias para las soluciones de software de replicación de almacenamiento.

Conclusiones

Si ya no desea administrar la infraestructura de sus bases de datos, el sistema operativo, actualizaciones, respaldos y parcheo de Windows y SQL Server, entonces, Amazon RDS para SQL Server es una excelente opción. Puede configurar alta disponibilidad en múltiples zonas de disponibilidad con unos pocos clics, puede aumentar el tamaño de su instancia de SQL Server fácilmente y puede habilitar el escalamiento automático del almacenamiento.

Puede que existan buenas razones para continuar ejecutando SQL Server para sus aplicaciones en el futuro, pero si desea alejarse de licencias cada vez más restrictivas, y disfrutar de la libertar e innovación que promueve el “open source”, AWS proporciona las herramientas gratuitas para ayudarlo y acelerar su migración.

Si desea mantener los mismos niveles de rendimiento y confiabilidad a una décima parte del costo, lo puede conseguir utilizando Amazon Aurora. Amazon Aurora tiene características muy interesantes que los invitamos a revisar, como por ejemplo soporte para AWS Graviton 2 (35% mejora en rendimiento) y Aurora Serverless versión 2 (ahorro de hasta 90% de costos).

Sobre los autores

Francisco Fagas es arquitecto de soluciones senior en AWS con foco en tecnologías de Microsoft. Francisco tiene mas de 15 años de experiencia trabajando con Tecnologías de la Información y disfruta de ayudar a los clientes a obtener los beneficios de correr sus cargas de trabajo en la nube.

Rene Martínez es arquitecto de soluciones senior en AWS, con 13 años de experiencia profesional en el rubro TI y más de 5 con tecnologías de nube específicamente. En su rol actual apoya a los clientes a encontrar las mejores arquitecturas y soluciones para sus necesidades, en especial, clientes del segmento Enterprise e industria financiera.

Revisores

Federico Feijo es parte del equipo de la gerencia de Arquitectura de Soluciones de LATAM enfocado en Argentina, Paraguay y Uruguay. En su rol actual, apoya a los arquitectos de soluciones de su equipo a desbloquear posibles desafíos y a aportar una mirada mas de negocio en sus compromisos.

Luis Felipe Flórez es Ingeniero en Informática, con experiencia en desarrollo y arquitectura de Software; hoy se desempeña como arquitecto de soluciones para Partners, donde busca ayudar a sus clientes a Innovar por medio del uso de Servicios de Tecnología basados en AWS.