Amazon Aurora es un servicio de base de datos relacional moderno que ofrece rendimiento y alta disponibilidad a gran escala, ediciones de código abierto totalmente compatibles con MySQL y PostgreSQL y una amplia gama de herramientas para desarrolladores para crear aplicaciones sin servidor y controladas por machine learning (ML).

Aurora ofrece un sistema de almacenamiento distribuido, tolerante a errores y de recuperación automática que está desacoplado de los recursos de computación y que escala verticalmente de forma automática hasta 128 TiB por instancia de base de datos. Proporciona alto rendimiento y disponibilidad con hasta 15 réplicas de lectura de baja latencia, recuperación a un momento dado, generación de copias de seguridad continua en Amazon Simple Storage Service (Amazon S3) y replicación en tres zonas de disponibilidad (AZ).

Además, Aurora es un servicio completamente administrado que automatiza las tareas de administración que consumen mucho tiempo, como el aprovisionamiento de hardware, la configuración de la base de datos, la aplicación de parches y las copias de seguridad, mientras brinda la seguridad, la disponibilidad y la fiabilidad de las bases de datos comerciales por una décima parte del costo.

Amazon Aurora es directamente compatible con las bases de datos de código abierto de MySQL existentes y agrega compatibilidad para los lanzamientos nuevos de forma periódica. Esto significa que puede migrar con facilidad bases de datos de MySQL a Aurora y desde Aurora mediante el uso de instantáneas o herramientas de importación y exportación estándares. Esto significa que la mayor parte del código, las aplicaciones, los controladores y las herramientas que ya utiliza con bases de datos MySQL también se pueden utilizar con Aurora con cambios mínimos o incluso sin necesidad de realizar ninguna modificación. Esto facilita la migración de aplicaciones entre los dos motores.

Puede ver la información de compatibilidad de la versión actual de Amazon Aurora MySQL en la documentación.

Amazon Aurora es directamente compatible con las bases de datos de código abierto de PostgreSQL existentes y agrega compatibilidad para los lanzamientos nuevos de manera periódica. Esto significa que puede migrar con facilidad bases de datos de PostgreSQL a Aurora y desde Aurora mediante el uso de instantáneas o herramientas de importación/exportación estándares. Esto también significa que la mayor parte del código, las aplicaciones, los controladores y las herramientas que ya utiliza con bases de datos PostgreSQL también se pueden utilizar con Aurora con cambios mínimos o incluso sin necesidad de realizar ninguna modificación.

Puede ver la información de compatibilidad de la versión actual de Amazon Aurora PostgreSQL en la documentación.

Amazon es completamente compatible con Aurora PostgreSQL y todas las extensiones disponibles con Aurora. Si necesita asistencia para Aurora PostgreSQL, póngase en contacto con AWS Support. Si tiene una cuenta de AWS Premium Support activa, puede contactar con AWS Premium Support para conocer cuestiones específicas de Aurora.

Para probar Aurora, inicie sesión en la Consola de administración de AWS, seleccione RDS en la categoría Database (Base de datos) y elija Amazon Aurora como motor de base de datos. Para obtener una guía y recursos detallados, consulte nuestra página Introducción a Amazon Aurora.

Puede ver la disponibilidad de la región de Aurora aquí.

Si quiere migrar de MySQL a Aurora y viceversa, tiene varias opciones:

• Puede utilizar el servicio mysqldump estándar para exportar datos desde MySQL y el servicio mysqlimport para importar datos a Aurora y viceversa.
• También puede utilizar la característica de migración Instantánea de base de datos de Amazon RDS para migrar una instantánea de base de datos de Amazon RDS para MySQL a Aurora mediante la consola de administración de AWS.

La migración a Aurora se completa para la mayoría de los clientes en menos de una hora, aunque la duración depende del formato y del tamaño del conjunto de datos. Para obtener más información, consulte Prácticas recomendadas para migrar bases de datos MySQL a Amazon Aurora.

Si desea migrar de PostgreSQL a Aurora y viceversa, tiene varias opciones:

• Puede emplear la utilidad pg_dump estándar para exportar datos desde PostgreSQL y la utilidad pg_restore para importar datos a Aurora y viceversa.
• También puede utilizar la característica de migración Instantánea de base de datos de Amazon RDS para migrar una instantánea de base de datos de Amazon RDS para PostgreSQL a Aurora mediante la consola de administración de AWS.

La migración a Aurora se completa para la mayoría de los clientes en menos de una hora, aunque la duración depende del formato y del tamaño del conjunto de datos.

Para migrar bases de datos de SQL Server a una edición compatible con PostgreSQL de Amazon Aurora, puede utilizar Babelfish para Aurora PostgreSQL. Las aplicaciones funcionarán sin ningún cambio. Consulte la documentación de Babelfish para obtener más información.

No, Aurora funciona con controladores de bases de datos PostgreSQL estándar.

Amazon Aurora ofrece mejoras importantes en comparación con el rendimiento de MySQL, ya que realiza una estrecha integración del motor de base de datos con la capa de almacenamiento virtualizado de uso general (SSD) para cargas de trabajo de base de datos, reduce las escrituras en el sistema de almacenamiento, minimiza la contención de bloqueos y elimina los retrasos que ocasionan los subprocesos del procesamiento de bases de datos.

Nuestras pruebas con SysBench en instancias r3.8xlarge revelan que Amazon Aurora ofrece más de 500 000 SELECT/segundo y más de 100 000 UPDATE/segundo, cinco veces más que cuando MySQL se ejecuta en el mismo hardware con la misma referencia. En la Guía de referencia de rendimiento de la edición compatible con MySQL de Amazon Aurora, se incluyen instrucciones detalladas sobre esta referencia y cómo replicarla.

Amazon Aurora ofrece mejoras importantes en comparación con el desempeño de PostgreSQL, ya que realiza una estrecha integración del motor de base de datos con la capa de almacenamiento virtualizado basado en SSD para cargas de trabajo de base de datos, reduce las escrituras en el sistema de almacenamiento, minimiza la contención de bloqueos y elimina los retrasos que ocasionan los subprocesos del procesamiento de bases de datos.

Nuestras pruebas con SysBench en instancias r4.16xlarge revelan que Amazon Aurora ofrece una métrica de SELECT/segundo y UPDATE/segundo tres veces superior que cuando PostgreSQL se ejecuta en el mismo hardware con la misma referencia. En la Guía de referencia de rendimiento de la edición compatible con PostgreSQL de Amazon Aurora, se incluyen instrucciones detalladas sobre esta referencia y cómo replicarla.

Amazon Aurora está diseñado para ser compatible con MySQL, de forma que las herramientas y las aplicaciones de MySQL ya existentes puedan ejecutarse sin necesidad de realizar ninguna modificación. Sin embargo, un aspecto en el que Amazon Aurora supera a MySQL es en las cargas de trabajo con alto nivel de simultaneidad. Para maximizar el rendimiento de la carga de trabajo en Amazon Aurora, le aconsejamos que cree sus aplicaciones de manera que generen una gran cantidad de transacciones y consultas simultáneas.

Amazon Aurora está diseñado para ser compatible con PostgreSQL, de forma que las herramientas y las aplicaciones de PostgreSQL ya existentes puedan ejecutarse sin necesidad de realizar ninguna modificación. Sin embargo, un aspecto en el que Amazon Aurora supera a PostgreSQL es en las cargas de trabajo con alto nivel de simultaneidad. Para maximizar el rendimiento de la carga de trabajo en Amazon Aurora, aconsejamos que cree sus aplicaciones de manera que generen una gran cantidad de transacciones y consultas simultáneas.

Para obtener información actualizada de los precios, consulte la página de precios de Aurora.

Por el momento, no hay ninguna oferta de nivel gratuito de AWS para Aurora. Sin embargo, Aurora almacena los datos de forma duradera en tres zonas de disponibilidad en una región y solo cobra por una copia de los datos. No se le cobrará por las copias de seguridad de hasta el 100 % del tamaño del clúster de bases de datos. Tampoco se cobrarán las instantáneas durante el periodo de retención de copias de seguridad configurado para el clúster de bases de datos.

No, la replicación de Aurora está incluida en el precio. Los cargos se aplicarán en función del almacenamiento que la base de datos consuma en la capa de la base de datos, no por el almacenamiento consumido en la capa de almacenamiento virtual de Aurora.

E/S se refiere a las operaciones entrantes y salientes que realiza el motor de base de datos de Aurora en la capa de almacenamiento virtualizado basado en SSD. Cada operación de lectura de la página de la base de datos cuenta como una E/S.
El motor de la base de datos de Aurora emite lecturas contra la capa de almacenamiento para obtener páginas de la base de datos que no están presentes en la memoria en la caché:

• Si el tráfico de consultas puede entregarse totalmente desde la memoria o la caché, no se cobrará por recuperar ninguna página de datos desde la memoria.
• Si el tráfico de consultas no puede entregarse completamente desde la memoria, se cobrará por las páginas de datos que deban recuperarse del almacenamiento.
  Cada página de la base de datos tiene 16 KB en la edición compatible con MySQL de Amazon Aurora y 8 KB en la edición compatible con PostgreSQL de Aurora.

Aurora se diseñó para eliminar operaciones de E/S innecesarias. Esto permite reducir costos y garantizar que los recursos estén disponibles cuando se necesiten para el tráfico de lectura y escritura. Las operaciones de E/S de escritura solo se consumen cuando se conservan registros de rehacer en la edición compatible con MySQL de Aurora o se escriben registros de avance en la edición compatible con PostgreSQL de Aurora en la capa de almacenamiento con el fin de hacer duraderas las escrituras.

Las operaciones de E/S de escritura se cuentan en unidades de 4 KB. Por ejemplo, un registro que tiene 1024 bytes se cuenta como una operación de E/S. Sin embargo, si el registro es mayor de 4 KB, se necesitará más de una operación de E/S de escritura para conservarlo.

Las operaciones de escritura simultáneas cuyo registro tenga menos de 4 KB se pueden agrupar por lotes en el motor de base de datos de Aurora para optimizar el consumo de operaciones de E/S. A diferencia de los motores de bases de datos tradicionales, Aurora nunca coloca páginas de datos incorrectos en el almacenamiento.

Para ver la cantidad de operaciones de E/S que consume una instancia de Aurora, diríjase a la consola de administración de AWS. Para buscar el consumo de operaciones de E/S, vaya a la sección Amazon RDS de la consola, observe la lista de instancias, seleccione las instancias de Aurora y, luego, busque las métricas VolumeReadIOPs y VolumeWriteIOPs en la sección de supervisión.

Para obtener más información sobre los precios de las operaciones de E/S, consulte la página de precios de Aurora. Se cobrará por las operaciones de E/S de lectura y escritura cuando configure los clústeres de bases de datos según la configuración de Aurora Standard. No se cobrará por las operaciones de E/S de lectura y escritura cuando configure los clústeres de bases de datos para que estén optimizados para Amazon Aurora I/O Optimized.

Aurora ofrece la flexibilidad de optimizar su gasto en bases de datos al elegir entre dos opciones de configuración en función de sus necesidades de precio-rendimiento y previsibilidad de precios. Las dos opciones de configuración son Aurora estándar y Aurora optimizado para E/S. Ninguna de las dos opciones requiere un aprovisionamiento inicial de E/S o almacenamiento y ambas pueden escalar las operaciones de E/S para dar soporte a las aplicaciones más exigentes.

Aurora estándar es una configuración de clústeres de bases de datos que ofrece precios rentables para la gran mayoría de las aplicaciones con un uso de E/S bajo o moderado. Con Aurora Standard, usted paga por las instancias de bases de datos, el almacenamiento y las E/S de pago por solicitud.

Aurora optimizado para E/S es una configuración de clústeres de bases de datos que ofrece una mejor relación precio-rendimiento para aplicaciones con un uso intensivo de E/S, como los sistemas de procesamiento de pagos, los sistemas de comercio electrónico y las aplicaciones financieras. Además, si su gasto en E/S supera el 25 % del gasto total en bases de datos de Aurora, puede ahorrar hasta un 40 % en los costos de las cargas de trabajo intensivas de E/S con Aurora optimizado para E/S. Aurora optimizado para E/S ofrece precios predecibles para todas las aplicaciones, ya que no se cobran cargos por las operaciones de E/S de lectura y escritura, lo que hace que esta configuración sea ideal para cargas de trabajo con una alta variabilidad de E/S.

Aurora I/O-Optimized es la opción ideal cuando necesita costos predecibles para cualquier aplicación. Ofrece una mejor relación precio-rendimiento para aplicaciones con uso intensivo de E/S, que requieren un alto rendimiento de escritura o ejecutan consultas de análisis que procesan grandes cantidades de datos. Para los clientes con un gasto de E/S superior al 25 % de su factura de Aurora, puede ahorrar hasta un 40 % en los costos de las cargas de trabajo intensivas de E/S con Aurora optimizado para E/S.

Puede utilizar la experiencia de un solo clic disponible en la Consola de administración de AWS para cambiar el tipo de almacenamiento de los clústeres de bases de datos existentes de modo que estén optimizados para Aurora I/O-Optimized. También puede invocar la Interfaz de la línea de comandos de AWS (AWS CLI) o el SDK de AWS para realizar este cambio.

Puede cambiar a Aurora I/O-Optimized los clústeres de bases de datos existentes una vez cada 30 días. Puede volver a Aurora Standard en cualquier momento.

Sí, Aurora I/O-Optimized funciona con las instancias reservadas de Aurora existentes. Aurora contabiliza automáticamente la diferencia de precio entre Aurora Standard y Aurora I/O-Optimized con instancias reservadas. Con los descuentos de instancias reservadas con Aurora I/O-Optimized, puede ahorrar aún más en sus gastos de E/S.

No hay cambios en el precio de la retroactividad, la instantánea, la exportación o la copia de seguridad continua con Aurora I/O-Optimized.

Sí, se siguen cobrando los cargos por las operaciones de E/S necesarias para replicar datos en todas las regiones. Aurora optimizado para E/S no cobra por las operaciones de E/S de lectura y escritura, lo cual es diferente de la replicación de datos.

No hay cargos adicionales por Amazon Aurora Optimized Reads para Aurora PostgreSQL, aparte del precio de las instancias R6id con tecnología de Intel y R6gd con tecnología de Graviton. Para más información, consulte la página de precios de Aurora.

El límite mínimo de almacenamiento es de 10 GB. El almacenamiento de Amazon Aurora aumentará de forma automática en función del uso de la base de datos, hasta 128 TB, en incrementos de 10 GB, sin que ello incida en el rendimiento de la base de datos. No es necesario aprovisionar el almacenamiento por adelantado.

Existen dos formas de escalar los recursos de computación asociados a mi instancia de base de datos de Amazon Aurora: a través de Aurora sin servidor y mediante un ajuste manual.

Puede utilizar Aurora sin servidor, una configuración bajo demanda de autoescalado para Amazon Aurora cuyo objetivo es escalar recursos de computación de bases de datos según la demanda de las aplicaciones. Esta configuración le permite ejecutar su base de datos en la nube, sin que tenga de preocuparse por la administración de la capacidad de la base de datos. Puede especificar el rango de capacidad de base de datos deseado y su base de datos escalará en función de las necesidades de la aplicación. Puede obtener más información en la Guía del usuario de Aurora sin servidor.

También puede escalar de manera manual sus recursos de computación asociados a su base de datos si selecciona el tipo de instancia de base de datos deseado en la consola de administración de AWS. El cambio solicitado se aplicará durante el periodo de mantenimiento que haya especificado; también puede utilizar la opción “Apply Immediately” (Aplicar de inmediato) para cambiar el tipo de instancia de base de datos de manera inmediata.

Ambas opciones afectarán la disponibilidad durante algunos minutos mientras se ejecuta la operación de escalado. Tenga en cuenta que también se aplicarán los demás cambios pendientes en el sistema.

Las copias de seguridad automáticas siempre están habilitadas en las instancias de base de datos de Amazon Aurora. Las copias de seguridad no afectan el rendimiento de la base de datos.

Sí. Además, la realización de instantáneas no afecta el rendimiento. Tenga en cuenta que, para restablecer datos a partir de instantáneas de base de datos, es necesario crear una nueva instancia de base de datos.

Amazon Aurora hace que sus datos duren de forma automática en tres zonas de disponibilidad (AZ) de una región e intentará recuperar automáticamente su base de datos en una AZ en buen estado sin pérdida de datos. En el extraño caso de que los datos no se encuentren disponibles en el almacenamiento de Amazon Aurora, puede restablecerlos a partir de una instantánea de base de datos o realizar una operación de restablecimiento puntual en una instancia nueva. Tenga en cuenta que el tiempo restablecible para una operación de restablecimiento en un momento dado puede llevarse a cabo dentro de los cinco minutos anteriores.

Puede optar por crear una instantánea de base de datos final al eliminar la instancia de base de datos. De ser así, puede usar esta instantánea de base de datos para restablecer la instancia de base de datos eliminada en un momento posterior. Amazon Aurora retiene esta instantánea de base de datos definitiva creada por el usuario junto con todas las demás instantáneas de bases de datos creadas manualmente después de haber eliminado la instancia de base de datos. Después de eliminar una instancia de base de datos, solo se retienen las instantáneas de base de datos (es decir, no se retienen las copias de seguridad automáticas creadas para un restablecimiento a un momento dado).

Sí. Aurora le permite crear instantáneas de sus bases de datos, que puede usar más adelante para restaurar una base de datos. Puede compartir una instantánea con una cuenta distinta de AWS. El propietario de la cuenta de destino podrá usar esta instantánea para restaurar una base de datos que contenga sus datos. Incluso puede elegir que sus instantáneas sean públicas. Es decir, cualquiera podría restaurar una base de datos que contenga sus datos (públicos).

Puede usar esta característica para compartir datos entre diferentes entornos (producción, desarrollo/pruebas, ensayos, etc.) que tengan cuentas distintas, así como también conservar copias de seguridad de todos los datos seguras en una cuenta independiente en caso de que alguna vez su cuenta principal de AWS esté comprometida.

Compartir instantáneas entre cuentas no conlleva ningún cargo. Sin embargo, es posible que se le cobre por las instantáneas, así como por cualquier base de datos que restaure a partir de instantáneas compartidas. Obtenga más información acerca de los precios de Aurora.

No es posible compartir instantáneas de base de datos automáticas. Para compartir una instantánea, debe crear una copia de la instantánea de forma manual y compartirla.

Puede compartir instantáneas manuales con hasta 20 ID de cuenta de AWS. Si desea compartir una instantánea con más de 20 cuentas, puede hacerla pública para compartirla o bien, contactar con el equipo de Soporte para incrementar esta cantidad.

Puede compartir sus instantáneas de Aurora en todas las regiones de AWS en las que se encuentra disponible Aurora.

No. Solo podrán acceder a las instantáneas de Aurora compartidas cuentas ubicadas en la misma región que la cuenta que los comparte.

Sí, puede compartir instantáneas de Aurora cifradas.

Amazon Aurora divide de manera automática el volumen de la base de datos en segmentos de 10 GB distribuidos en varios discos. Cada segmento de 10 GB del volumen de la base de datos se replica de seis formas en tres zonas de disponibilidad (AZ). Amazon Aurora es un servicio diseñado para administrar de manera transparente la pérdida de hasta dos copias de datos sin que ello afecte a la disponibilidad de escritura de la base de datos y hasta tres copias sin que incida en la disponibilidad de lectura.

El almacenamiento de Amazon Aurora también ofrece recuperación automática. Los bloques de datos y los discos se someten a análisis constantes para buscar errores, que se reparan automáticamente.

A diferencia de lo que ocurre con otras bases de datos, después de un bloqueo, Amazon Aurora no necesita reproducir el registro de rehacer a partir del último punto de comprobación de la base de datos (que suele ser cinco minutos) y confirmar que todos los cambios se hayan aplicado antes de habilitar la base de datos para las operaciones. Esto reduce el tiempo de reinicio de la base de datos a menos de 60 segundos en la mayoría de los casos.

Amazon Aurora extrae la caché del búfer del proceso de la base de datos y la habilita inmediatamente en el momento de realizar el reinicio. Esto evita la necesidad de limitar el acceso hasta que la caché se vuelva a llenar a fin de evitar interrupciones.

La edición compatible con MySQL de Amazon Aurora y la edición compatible con PostgreSQL de Amazon Aurora admiten las réplicas de Amazon Aurora, que comparten el mismo volumen subyacente que la instancia principal en la misma región de AWS. Las actualizaciones realizadas por la instancia principal son visibles en todas las réplicas de Amazon Aurora.

Gracias a la edición compatible con MySQL de Amazon Aurora también puede crear réplicas de lectura de MySQL entre regiones basadas en el motor de replicación binlog de MySQL. En las réplicas de lectura de MySQL, los datos de la instancia principal se reproducen en su réplica como transacciones. En la mayoría de los casos de uso, entre otros, el escalado de lectura y la alta disponibilidad, recomendamos utilizar réplicas de Amazon Aurora.

Tiene la flexibilidad de combinar y asociar estos dos tipos de réplicas en función de las necesidades de la aplicación:

Además de las opciones de replicación anteriores, cuenta con dos más. Puede usar la Base de datos global de Amazon para lograr una replicación física mucho más rápida entre clústeres de Aurora que se encuentren en diferentes regiones. Además, para la replicación entre bases de datos de Aurora y bases de datos que no sean de la edición compatible con MySQL de Aurora (inclusive fuera de AWS), puede configurar su propia replicación binlog autoadministrada.

Sí, puede configurar las réplicas de Aurora entre regiones por medio de la replicación física o lógica. La replicación física, llamada Amazon Aurora Global Database, utiliza una infraestructura dedicada que deja las bases de datos completamente disponibles para servir a la aplicación. Además, puede replicarse hasta en cinco regiones secundarias con una latencia típica de menos de un segundo. Está disponible para la edición compatible con MySQL de Aurora y la edición compatible con PostgreSQL de Aurora.

Para las lecturas globales de baja latencia y la recuperación de desastres, recomendamos utilizar Amazon Aurora Global Database.
Aurora es compatible con la replicación lógica nativa en cada motor de base de datos (binlog para MySQL y slot de replicación de PostgreSQL para PostgreSQL), lo que permite la replicación en bases de datos Aurora y en bases de datos que no son Aurora, incluso entre regiones.

La edición compatible con MySQL de Aurora también ofrece una característica de réplica de lectura lógica entre regiones y fácil de utilizar que admite hasta cinco regiones secundarias de AWS. Se basa en una única replicación binlog MySQL encadenada. Por lo tanto, el retraso de la replicación se verá afectado por la tasa de cambio/aplicación, así como cualquier retraso en la comunicación por red entre las regiones específicas seleccionadas.

Sí, puede agregar hasta 15 réplicas de Aurora en cada clúster entre regiones, y estas compartirán el mismo almacenamiento subyacente que la réplica entre regiones. La réplica entre regiones funcionará como la instancia principal del clúster y las réplicas de Aurora en el clúster presentarán un retraso de décimas de milisegundos en comparación con la instancia principal.

Sí, puede convertir su réplica entre regiones en la nueva instancia principal a través de la consola de Amazon RDS. Para la replicación lógica (binlog), el proceso de conversión suele tardar unos minutos, en función de la carga de trabajo. La replicación entre regiones se detendrá una vez que inicie el proceso de conversión.

Con la Base de datos global de Amazon Aurora, puede convertir una región secundaria para que tome cargas de trabajo de lectura/escritura completas en menos de un minuto.

Sí. Puede asignar un nivel de prioridad de conversión a cada instancia del clúster. Cuando la instancia principal falle, Amazon RDS convertirá en instancia principal la réplica que tenga mayor prioridad. Si dos o más réplicas de Aurora comparten la misma prioridad, Amazon RDS convertirá en instancia principal a la réplica de mayor tamaño. Si dos o más réplicas de Aurora comparten prioridad y tamaño, Amazon RDS convertirá en instancia principal a una réplica cualquiera del mismo nivel de prioridad.

Para obtener más información sobre la lógica de conmutación por error, lea la guía del usuario de Amazon Aurora.

Sí, puede modificar el nivel de prioridad de una instancia en cualquier momento. Modificar los niveles de prioridad no activará una conmutación por error.

Puede asignar niveles de prioridad inferiores a las réplicas que no quiera que se conviertan en instancia principal. No obstante, si las réplicas de prioridad superior del clúster están en mal estado o no están disponibles por el motivo que sea, Amazon RDS convertirá la réplica de menor prioridad.

Puede agregar réplicas de Amazon Aurora. Las réplicas de Aurora en la misma región de AWS comparten el mismo almacenamiento subyacente que la instancia principal. Puede convertir cualquier réplica de Aurora en instancia principal sin que se produzcan pérdidas de datos, por lo que puede utilizarla para mejorar la tolerancia a errores en caso de que se produzca algún error en la instancia de base de datos primaria.

Para aumentar la disponibilidad de la base de datos, solo tiene que crear de 1 a 15 réplicas en cualquiera de las tres zonas de disponibilidad, y Amazon RDS las incluirá de forma automática en la selección de instancias principales para la conmutación por error en el caso de que se produzca una interrupción de la base de datos. Puede utilizar Amazon Aurora Global Database si desea que su base de datos abarque varias regiones de AWS. Esto replicará sus datos sin afectar el rendimiento de la base de datos y proporcionará una recuperación de desastres de interrupciones en toda la región.

Amazon Aurora administra de manera automática la conmutación por error para que las aplicaciones puedan reanudar las operaciones de la base de datos a la mayor brevedad posible sin intervención administrativa manual.

• Si dispone de una réplica de Aurora en la misma zona de disponibilidad o en otra distinta, al realizar la conmutación por error, Aurora cambia el registro de nombre canónico (CNAME) de la instancia de base de datos para apuntar a la réplica en buen estado, que se convierte en la nueva instancia principal. La conmutación por error completa normalmente finaliza en 30 segundos o menos. Para mejorar la resiliencia y acelerar las conmutaciones por error, considere la posibilidad de utilizar Amazon RDS Proxy, que se conecta automáticamente a la instancia de base de datos de conmutación por error y, al mismo tiempo, conserva las conexiones de las aplicaciones. El proxy hace que las conmutaciones por error sean transparentes para sus aplicaciones y reduce los tiempos de conmutación por error hasta en un 66 %.
• Si está ejecutando Aurora sin servidor v1 y la instancia de base de datos o la zona de disponibilidad dejan de estar disponibles, Aurora volverá a crear la instancia de base de datos automáticamente en una zona de disponibilidad diferente. Aurora Serverless v2 funciona como aprovisionado para conmutación por error y otras características de alta disponibilidad. Para obtener más información, consulte Aurora sin servidor v2 y alta disponibilidad. 
• Si no dispone de una réplica de Aurora (es decir, una instancia única) y no está ejecutando Aurora sin servidor, Aurora intentará crear una nueva instancia de base de datos en la misma zona de disponibilidad en la que se encuentra la instancia original. Este reemplazo de la instancia original se lleva a cabo con el mayor esfuerzo, pero puede fallar, por ejemplo, si existe un problema que esté afectando a la zona de disponibilidad de manera generalizada.
  

La aplicación debe reintentar establecer las conexiones de la base de datos en caso de que se pierda la conexión. La recuperación de desastres en todas las regiones es un proceso manual, en el cual se convierte una región secundaria para que tome cargas de trabajo de lectura/escritura.

Amazon Aurora detectará de forma automática un problema en su instancia principal y activará una conmutación por error. Si está utilizando el punto de enlace del clúster, sus conexiones de lectura y escritura se redireccionarán de manera automática a una réplica de Amazon Aurora que se convertirá en principal.

Además, se interrumpirá momentáneamente el tráfico de lectura que atendían las réplicas de Aurora. Si está utilizando el punto de conexión del lector del clúster para direccionar su tráfico de lectura a la réplica de Aurora, las conexiones de solo lectura se direccionarán a la réplica de Aurora recientemente convertida en principal hasta que el nodo principal anterior se recupere como una réplica.

Dado que las réplicas de Amazon Aurora comparten el mismo volumen de datos que la instancia principal en la misma región de AWS, no se produce prácticamente ningún retraso de replicación. Por lo general, observamos retrasos en decenas de milisegundos.

Para las replicación entre regiones, el retraso de replicación lógica con base en binlog puede aumentar indefinidamente en función de la tasa de cambio/aplicación, así como de los retrasos en la comunicación de red. No obstante, en condiciones normales, lo habitual es que el retraso de replicación sea inferior a un minuto. Las réplicas entre regiones que utilicen una replicación física de la Base de datos global de Amazon Aurora tendrán un retraso típico inferior a un segundo.

Sí, puede configurar una replicación binlog entre una instancia con la edición compatible con MySQL de Aurora y una base de datos MySQL externa. La otra base de datos se puede ejecutar en Amazon RDS o como una base de datos autoadministrada en AWS o completamente fuera de AWS.

Si ejecuta la edición compatible con MySQL 5.7 de Aurora, considere configurar una replicación binlog basada en identificadores de transacciones globales (GTID). De esta manera, se logra una coherencia completa para que su replicación no omita transacciones ni genere problemas, inclusive después de una conmutación por error o una interrupción del servicio.

Base de datos global de Amazon Aurora es una característica que permite que una sola base de datos de Amazon Aurora abarque varias regiones de AWS. Replica sus datos sin afectar el rendimiento de la base de datos, permite lecturas locales rápidas en cada región con la latencia típica o de menos de un segundo y proporciona recuperación de desastres ante interrupciones en toda la región. En el caso improbable de una degradación o interrupción regional, una región secundaria se puede ascender para que tenga la capacidad completa de lectura/escritura en menos de un minuto. Esta característica está disponible para la edición compatible con MySQL de Aurora y la edición compatible con PostgreSQL de Aurora.

Puede crear una Base de datos global de Aurora con tan solo unos clics en la consola de Amazon RDS. Como alternativa, puede utilizar el Kit de desarrollo de software (SDK) de AWS o la AWS Command Line Interface (CLI). Debe aprovisionar al menos una instancia por región en su Base de datos global de Amazon Aurora.

Para una Base de datos global de Amazon Aurora, puede crear hasta cinco regiones secundarias.

Sí. Si su objetivo es analizar la actividad de la base de datos, considere utilizar en su lugar la función de auditoría avanzada de Aurora, los registros generales y los registros de consultas lentas, para evitar afectar el rendimiento de su base de datos.

No. Si su región principal no está disponible, puede eliminar de manera manual una región secundaria de una Base de datos global de Amazon Aurora y promoverla para que realice lecturas y escrituras completas. También deberá dirigir su aplicación a la región recientemente convertida.

Sí, todas las instancias de base de datos de Amazon Aurora deben crearse en una VPC. Con Amazon VPC, puede definir una topología de red virtual que refleje de forma detallada una red tradicional que tenga instaurada en su propio centro de datos. Esto le permite ejercer un control total sobre quién puede obtener acceso a las bases de datos de Amazon Aurora.

Sí. Amazon Aurora utiliza SSL (AES-256) para proteger la conexión entre la instancia de base de datos y la aplicación. Amazon Aurora le permite cifrar sus bases de datos mediante las claves que administra a través de AWS Key Management Service (AWS KMS).

En una instancia de base de datos que se ejecute con cifrado de Amazon Aurora, los datos almacenados en reposo en el almacenamiento subyacente están cifrados, al igual que las copias de seguridad automatizadas, las réplicas y las instantáneas en el mismo clúster. El cifrado y el descifrado se administran de forma ininterrumpida. Para obtener más información acerca del uso de AWS KMS con Amazon Aurora, consulte la guía del usuario de Amazon RDS.

Actualmente, no se puede cifrar una instancia de Aurora que no esté cifrada. Para utilizar el cifrado de Amazon Aurora para una base de datos existente no cifrada, cree una nueva instancia de base de datos con cifrado habilitado y migre sus datos a ella.

Se debe acceder a las bases de datos de Aurora a través del puerto de la base de datos ingresado en la creación de la base de datos. Esto ofrece a los datos una capa adicional de seguridad. En la Guía de conectividad de Amazon Aurora, se proporcionan instrucciones paso a paso sobre cómo conectarse a su base de datos de Amazon Aurora.

Sí, las ediciones de Aurora compatibles con MySQL y PostgreSQL son elegibles para HIPAA. Puede usarlas para crear aplicaciones compatibles con HIPAA y almacenar información relacionada con la atención médica, incluida la información de salud protegida (PHI), mediante un anexo comercial (BAA) ejecutado con AWS. Si ya cuenta con un BAA con AWS, no es necesario realizar ninguna otra acción para comenzar a utilizar estos servicios en las cuentas cubiertas por su BAA. Para obtener más información sobre el uso de AWS para crear aplicaciones compatibles, consulte Proveedores de atención médica.

Actualmente puede encontrar una lista de CVE en Actualizaciones de seguridad de Amazon Aurora.

Aurora está integrado con Amazon GuardDuty para ayudarlo a identificar posibles amenazas a los datos almacenados en las bases de datos de Aurora. La protección de RDS de GuardDuty perfila y supervisa la actividad de inicio de sesión en las bases de datos nuevas y existentes de su cuenta, y utiliza modelos de ML personalizados para detectar inicios de sesión sospechosos en las bases de datos de Aurora. Para obtener más información, consulteSupervisión de amenazas con la protección de RDS de GuardDuty y la guía del usuario de la protección de RDS de GuardDuty.

Aurora sin servidor es una configuración de escalado automático bajo demanda para Amazon Aurora. Con Aurora sin servidor, puede ejecutar su base de datos en la nube sin administrar la capacidad de la base de datos. Administrar manualmente la capacidad de la base de datos puede llevar mucho tiempo y llevar a un uso ineficiente de los recursos de la base de datos. Con Aurora sin servidor, tan solo debe crear una base de datos, especificar el rango de capacidad de la base de datos deseado y conectar la aplicación. Aurora ajusta de manera automática la capacidad dentro del rango que especificó en función de las necesidades de la aplicación.

Se facturará por segundo por la capacidad de base de datos que utilice cuando la base de datos esté activa. Obtenga más información acerca de Aurora sin servidor y comience a utilizarlo con tan solo unos pasos desde la consola de administración de Amazon RDS.

Aurora sin servidor v2 es compatible con todo tipo de cargas de trabajo de base de datos, desde desarrollo y entornos de prueba, sitios web y aplicaciones con cargas de trabajo poco frecuentes, intermitentes o impredecibles, hasta aquellas aplicaciones empresariales críticas más exigentes que requieren alta escalabilidad y disponibilidad. Aurora Serverless escala in situ al agregar más CPU y memoria sin tener que conmutar por error la base de datos a una instancia de base de datos más pequeña. Como resultado, es capaz de escalar incluso cuando hay transacciones de larga duración, bloqueos de tablas, etc.

Además, el servicio escala la capacidad de la base de datos en incrementos tan pequeños como media unidad de capacidad Aurora (ACU), de modo que la capacidad de base de datos coincida lo máximo posible con las necesidades de la aplicación.

Aurora sin servidor v1 es una opción rentable y sencilla para las cargas de trabajo poco frecuentes, intermitentes o impredecibles. Es capaz de iniciarse automáticamente, escalar la capacidad de computación para coincidir con el uso que hace la aplicación y dejar de funcionar cuando no está en uso. Para obtener más información, visite la guía del usuario de Aurora.

Aurora sin servidor v2 es compatible con todas las características de Aurora aprovisionado, incluidas la réplica de lectura, la configuración Multi-AZ, la Base de datos global de Aurora, RDS Proxy e Información de rendimiento.

Sí, puede comenzar a utilizar Aurora sin servidor v2 para administrar la capacidad de cálculo de la base de datos en su clúster de bases de datos de Aurora existente. Un clúster que contiene ambas instancias aprovisionadas además de Aurora Serverless v2 es un clúster de configuración combinada. Puede elegir cualquier combinación de instancias aprovisionadas y Aurora Serverless v2 en su clúster.

Para probar Aurora Serverless v2, debe agregar un lector a su clúster de base de datos de Aurora y seleccionar Serverless v2 como el tipo de instancia. Una vez que el lector ha sido creado y está disponible, puede comenzar a utilizar para cargas de trabajo de solo lectura. Tras confirmar que el lector funciona como se esperaba, puede iniciar una conmutación por error para comenzar a utilizar Aurora Serverless v2 para lectura y escritura. Esta opción brinda una experiencia de tiempo de inactividad mínimo para comenzar con Aurora sin servidor v2.

Sí, puedo migrar desde Aurora sin servidor v1 a Aurora sin servidor v2. Para obtener más información, consulte la guía del usuario de Aurora.

La información de compatibilidad de Aurora sin servidor v1 puede verse aquí. La información de compatibilidad de Aurora sin servidor v2 puede verse aquí.

Sí, puede restaurar una instantánea tomada de un clúster aprovisionado de Aurora existente en un clúster de bases de datos de Aurora sin servidor y viceversa.

Puede acceder a un clúster de bases de datos de Aurora sin servidor a partir de una aplicación cliente que se ejecute en la misma VPC. No puede asignarle una dirección IP pública a una bases de datos de Aurora sin servidor .

Si bien Aurora sin servidor ajusta la escala automáticamente en función de la carga de la base de datos activa, en algunos casos, es posible que la capacidad no se ajuste con la suficiente rapidez como para respaldar una modificación repentina de la carga de trabajo, como un número elevado de transacciones nuevas. En estos casos, puede definir de manera explícita la capacidad en un valor específico con la consola de administración de AWS, AWS CLI o la API de Amazon RDS.

Una vez que se inicia una operación de escalado, Aurora sin servidor intenta encontrar un punto de escalado, que es el punto temporal en el cual la base de datos puede completar el escalado de manera segura. Es posible que Aurora sin servidor no pueda encontrar un punto de escalado si existen transacciones o consultas de ejecución prolongada en progreso o bien tablas temporales o bloqueos de tablas en uso.

En Aurora sin servidor, la capacidad de la base de datos se mide en ACU. Paga una tarifa fija por segundo de uso de ACU. Los costos de procesamiento para ejecutar las cargas de trabajo en Aurora sin servidor dependerán de la configuración del clúster de bases de datos que elija: Aurora estándar o Aurora optimizado para E/S. Visite la página de precios de Aurora para obtener información sobre precios y disponibilidad regional.

Amazon Aurora Optimized Reads, disponible para Aurora PostgreSQL, es una nueva opción de precio y rendimiento que ofrece una latencia de consultas hasta 8 veces mejor y un ahorro de costos de hasta un 30 % en comparación con las instancias que no la tienen. Es ideal para aplicaciones con grandes conjuntos de datos que superan la capacidad de memoria de una instancia de base de datos.

Las instancias de Amazon Aurora Optimized Reads utilizan almacenamiento local a nivel de bloques SSD con tecnología de NVMe (disponible en las instancias r6gd con tecnología de Graviton y r6id con tecnología de Intel) para mejorar la latencia de consultas de las aplicaciones con conjuntos de datos que superan la capacidad de memoria de una instancia de base de datos. Optimized Reads incluye mejoras de rendimiento, como el almacenamiento en caché por niveles y los objetos temporales.

El almacenamiento en caché por niveles ofrece una latencia de consultas hasta 8 veces mejor y un ahorro de costos de hasta un 30 % para aplicaciones con uso intensivo de E/S y lectura, como paneles operativos, detección de anomalías y búsquedas de similitudes basadas en vectores. Estas ventajas se obtienen al almacenar automáticamente en caché los datos expulsados de la memoria caché del búfer de la base de datos en memoria en el almacenamiento local para acelerar los accesos posteriores a esos datos. El almacenamiento en caché por niveles solo está disponible para la edición de Amazon Aurora compatible con PostgreSQL con la configuración de Aurora optimizado para E/S.

Los objetos temporales logran un procesamiento de consultas más rápido al colocar tablas temporales generadas mediante Aurora PostgreSQL en el almacenamiento local, lo que mejora el rendimiento de las consultas que implican ordenaciones, agregaciones de hash, uniones de alta carga y otras operaciones con uso intensivo de datos.

Amazon Aurora Optimized Reads para Aurora PostgreSQL ofrece a los clientes que tienen aplicaciones sensibles a la latencia y grandes conjuntos de trabajo una alternativa atractiva de precio y rendimiento para cumplir sus SLA empresariales y lograr aún más con sus instancias.

Amazon Aurora Optimized Reads está disponible en instancias R6gd con tecnología de Intel y R6gd con tecnología de Graviton. Puede ver la disponibilidad de la región de Aurora aquí.

Amazon Aurora Optimized Reads está disponible para la edición de Aurora compatible con PostgreSQL en instancias R6id y R6gd. Las versiones de motor compatibles son la 15.4 y posterior y la 14.9 o posterior en Aurora PostgreSQL.

Amazon Aurora Optimized Reads no está disponible en Aurora sin servidor v2 (ASv2).

Sí, Amazon Aurora Optimized Reads está disponible con ambas configuraciones. En ambas configuraciones, las instancias habilitadas para Optimized-Reads asignan automáticamente tablas temporales al almacenamiento local con tecnología de NVMe para mejorar el rendimiento de las consultas analíticas y las actualizaciones de índices.

Para cargas de trabajo intensivas de E/S con un uso intensivo de lectura, las instancias habilitadas para Optimized Reads en Aurora PostgreSQL configuradas para usar Aurora optimizado para E/S almacenan en caché automáticamente los datos expulsados de la memoria en el almacenamiento local con tecnología de NVMe para ofrecer una latencia de consultas hasta 8 veces mejor y hasta un 30 % de ahorro de costos en comparación con las instancias que no la tienen, para aplicaciones con grandes conjuntos de datos que superan la capacidad de memoria de una instancia de base de datos.

Los clientes pueden comenzar a utilizar Amazon Aurora Optimized Reads mediante la consola de administración de AWS, la CLI y el SDK. Optimized Reads está disponible en todas las instancias de R6id y R6gd de forma predeterminada. Para utilizar esta funcionalidad, los clientes pueden simplemente modificar sus clústeres de bases de datos de Aurora existentes para incluir instancias R6id y R6gd, o crear nuevos clústeres de bases de datos con estas instancias. Consulte la documentación de Amazon Aurora Optimized Reads para comenzar.

Aproximadamente el 90 % del almacenamiento local disponible en las instancias R6id y R6gd está disponible para Optimized Reads. Aurora reserva el 10 % del almacenamiento de NVMe para reducir el impacto de la amplificación de escritura en SSD. La asignación del almacenamiento disponible varía en función de las características de Optimized Reads que estén habilitadas.

Cuando se utiliza Optimized Reads con las características de objetos temporales y almacenamiento en caché por niveles, el espacio disponible para los objetos temporales en el almacenamiento local equivale al doble del tamaño de la memoria disponible en estas instancias de base de datos. Esto coincide con el tamaño actual del almacenamiento de objetos temporales en Aurora PostgreSQL. El espacio restante en el disco de almacenamiento local está disponible para almacenar datos en caché.

Cuando se utiliza Optimized Reads solo con la característica de objetos temporales, todo el espacio en el disco de almacenamiento local disponible está disponible para los objetos temporales. Por ejemplo, cuando se usa una instancia r6gd.8xlarge con las características de objetos temporales y almacenamiento en caché por niveles, se reservan 534 GiB (el doble de la capacidad de memoria) para los objetos temporales y 1054 GiB para la memoria caché por niveles.

Si se produce un error en el almacenamiento local, Aurora hace automáticamente un reemplazo del host. En un clúster de base de datos de varios nodos, esto desencadena una conmutación por error en la región.

En caso de una conmutación por error de la base de datos, la latencia de las consultas aumentará temporalmente tras la conmutación por error. Este aumento de latencia se reducirá con el tiempo y, finalmente, recuperará la latencia de consulta anterior a la conmutación por error. Esta duración de recuperación se puede acelerar si se habilita la administración de caché de clústeres (CCM). Con CCM, los clientes pueden designar una instancia de base de datos de Aurora PostgreSQL específica como destino de conmutación por error.

Cuando se habilita CCM, la caché de almacenamiento local del destino de conmutación por error designado refleja fielmente la caché de almacenamiento local de la instancia principal, lo que reduce el tiempo de recuperación tras la conmutación por error. Sin embargo, la habilitación de CCM podría afectar a la eficacia de la memoria caché de almacenamiento local a largo plazo si el destino de conmutación por error designado también se utiliza para atender una carga de trabajo de lectura independiente de la carga de trabajo de la instancia de escritura.

Por lo tanto, los clientes que ejecutan cargas de trabajo que requieren la designación de un lector como conmutación por error en espera deben permitir que CCM aumente sus probabilidades de recuperar rápidamente la latencia de consultas tras la conmutación por error. Es posible que los clientes que ejecutan cargas de trabajo independientes en sus objetivos de conmutación por error designados quieran equilibrar sus necesidades de recuperación inmediata de la latencia tras la conmutación por error con la eficacia a largo plazo del rendimiento de la caché, antes de habilitar la CCM.

pgvector es una extensión de código abierto para PostgreSQL compatible con Amazon Aurora PostgreSQL Edition.

Sí. El machine learning (ML) de Aurora expone los modelos de ML como funciones SQL, lo que le permite usar SQL estándar para llamar a los modelos de ML, pasarles datos y devolver predicciones como resultados de consultas. pgvector requiere que las incrustaciones vectoriales se almacenen en la base de datos, lo que requiere ejecutar el modelo de ML en el texto de origen o los datos de imagen para generar incrustaciones y, a continuación, mover las incrustaciones por lotes a Aurora PostgreSQL.

El ML de Aurora puede hacer que este proceso se haga en tiempo real, lo que permite que las incrustaciones se mantengan actualizadas en Aurora PostgreSQL mediante llamadas periódicas a Amazon Bedrock o Amazon SageMaker, que devuelve las incrustaciones más recientes de su modelo.

Amazon Aurora PostgreSQL Optimized Reads con pgvector aumentan hasta 9 veces las consultas por segundo para la búsqueda vectorial en las cargas de trabajo que superan la memoria de instancias disponible. Esto es posible gracias a la capacidad de almacenamiento en caché por niveles que se encuentra disponible en Optimized Reads, que almacena automáticamente en caché los datos expulsados de la memoria caché del búfer de la base de datos en memoria en el almacenamiento local para acelerar los accesos posteriores a esos datos.

Debe utilizar la integración sin ETL de Amazon Aurora con Amazon Redshift cuando necesite acceso casi en tiempo real a los datos transaccionales. Esta integración le permite aprovechar el ML de Amazon Redshift con comandos SQL sencillos.

La integración sin ETL de Aurora con Amazon Redshift está disponible en la edición Aurora compatible con MySQL para Aurora MySQL 3.05 (compatible con MySQL 8.0.32) y versiones posteriores en las regiones Este de EE. UU. (Ohio), Este de EE. UU. (Norte de Virginia), Oeste de EE. UU. (Oregón), Asia-Pacífico (Singapur), Asia-Pacífico (Sídney), Asia-Pacífico (Tokio), Europa (Fráncfort), Europa (Irlanda) y Europa (Estocolmo). La integración sin ETL de Aurora con Amazon Redshift está disponible en la edición compatible con Aurora PostgreSQL para Aurora PostgreSQL 15.4 en la región Este de EE. UU. (Ohio).

La integración sin ETL de Aurora con Amazon Redshift elimina la necesidad de crear y mantener canalizaciones de datos complejas. Puede consolidar los datos de uno o varios clústeres de bases de datos de Aurora en un único clúster de base de datos de Amazon Redshift y ejecutar análisis y ML casi en tiempo real con Amazon Redshift en petabytes de datos transaccionales de Aurora. 

La integración sin ETL de Aurora con Amazon Redshift es compatible con Aurora sin servidor v2. Al utilizar tanto Aurora sin servidor v2 como Amazon Redshift sin servidor, puede generar análisis casi en tiempo real de los datos transaccionales sin tener que administrar ninguna infraestructura para canalizaciones de datos.

Para empezar, utilice la consola de Amazon RDS para crear la integración sin ETL especificando el origen de Aurora y el destino de Amazon Redshift. Una vez creada la integración, la base de datos de Aurora se replicará en Amazon Redshift y podrá empezar a consultar los datos una vez que se complete la fase inicial. Para obtener más información, lea la guía de introducción a las integraciones sin ETL de Aurora con Amazon Redshift.

La integración sin ETL y el procesamiento continuo de los cambios de datos se ofrecen sin cargos adicionales. Usted paga por los recursos existentes de Amazon RDS y Amazon Redshift que se utilizan para crear y procesar los datos de cambios generados como parte de una integración sin ETL. Estos recursos podrían incluir:

• E/S y almacenamiento adicionales que se utilizan al habilitar un binlog mejorado
• Costos de exportación de instantáneas para la exportación inicial de datos para crear bases de datos de Amazon Redshift
• Almacenamiento adicional en Amazon Redshift para almacenar datos replicados
• Costos de transferencia de datos entre zonas de disponibilidad para mover datos del origen al destino

Para obtener más información, visite la página de precios de Aurora.

Amazon DevOps Guru para RDS es una nueva capacidad basada en machine learning (ML) para Amazon RDS (que incluye a Amazon Aurora), que está diseñada para detectar y diagnosticar de forma automática el rendimiento de la base de datos y los problemas operativos, lo que permite resolver problemas en minutos en lugar de días.

Amazon DevOps Guru para RDS es una característica de Amazon DevOps Guru, que está diseñada para detectar problemas operativos y de rendimiento para todos los motores de Amazon RDS y docenas de otros tipos de recursos. DevOps Guru para RDS amplía las capacidades existentes de DevOps Guru para detectar, diagnosticar y remediar una amplia variedad de problemas relacionados con la base de datos en Amazon RDS (como el uso excesivo de recursos y el mal comportamiento de determinadas consultas de SQL).

Cuando surge un problema, Amazon DevOps Guru para RDS está diseñado para notificar de manera inmediata a los desarrolladores y los ingenieros de DevOps y proporciona información de diagnóstico, detalles sobre el alcance del problema y recomendaciones de corrección inteligente para ayudar a los clientes a resolver rápidamente cuellos de botella de rendimiento relacionados con la base de datos y problemas operativos.

Amazon DevOps Guru para RDS está diseñado para eliminar el esfuerzo manual y ahorrar tiempo (de horas a días y luego a minutos) para detectar y resolver cuellos de botella de rendimiento difíciles de encontrar en la carga de trabajo de la base de datos relacional.

Puede habilitar DevOps Guru para RDS para cada base de datos de Amazon Aurora, el cual detectará de forma automática problemas de rendimiento de sus cargas de trabajo, enviará alertas sobre cada problema, explicará los hallazgos y recomendará acciones para resolver los problemas.
DevOps Guru para RDS ayuda a que la administración de bases de datos sea más accesible para quienes no son expertos y ayuda a los expertos de bases de datos para que puedan administrar aún más bases de datos.

Amazon DevOps Guru para RDS utiliza ML para analizar los datos de telemetría recopilados por la Información de rendimiento de Amazon RDS. DevOps Guru para RDS no utiliza ninguno de los datos almacenados en la base de datos durante su análisis. La información sobre rendimiento mide la carga de la base de datos, una métrica que caracteriza cómo una aplicación pasa tiempo en la base de datos y las métricas seleccionadas generadas por la base de datos, como las variables de estado del servidor en MySQL y las tablas pg_stat en PostgreSQL.

Para comenzar a utilizar DevOps Guru para RDS, asegúrese de que la información sobre rendimiento esté habilitada a través de la consola de RDS y, luego, simplemente habilite DevOps Guru para las bases de datos de Amazon Aurora. Con DevOps Guru, puede elegir que el límite de cobertura de análisis sea toda su cuenta de AWS, prescribir las pilas de AWS CloudFormation específicas que desea que DevOps Guru analice, o utilizar etiquetas de AWS para crear la agrupación de recursos que desea que DevOps Guru analice.

Amazon DevOps Guru para RDS ayuda a identificar una amplia variedad de problemas de rendimiento que pueden afectar la calidad del servicio de la aplicación, como bloqueos acumulados, tormentas de conexión, regresiones SQL, contención de CPU y E/S y problemas de memoria.

La Información de rendimiento de Amazon RDS es una característica de ajuste y supervisión del rendimiento de las bases de datos que recopila y visualiza las métricas de rendimiento de la base de datos de Amazon RDS, lo que ayuda a evaluar de forma rápida la carga en las bases de datos y determinar cuándo y dónde tomar las medidas oportunas. Amazon DevOps Guru para RDS está diseñado para supervisar esas métricas, detectar cuándo la base de datos está experimentando problemas de rendimiento, analizar las métricas y, luego, decirle qué está mal y qué puede hacer al respecto.

Debe usar la API de datos para nuevas aplicaciones modernas, en particular aquellas creadas con AWS Lambda que necesitan acceder a Aurora en un modelo de solicitud/respuesta. Debe usar controladores de base de datos en lugar de la API de datos y administrar las conexiones de base de datos persistentes cuando una aplicación existente esté muy acoplada a los controladores de base de datos, cuando existen consultas de ejecución prolongada o cuando el desarrollador quiera aprovechar las características de la base de datos, como las tablas temporales, o usar variables de sesión.

En nuestra documentación encontrará la disponibilidad de la región de AWS y de la versión de la base de datos de la API de datos para las instancias aprovisionadas de Aurora sin servidor v2 y Aurora. Se recomienda a los clientes que actualmente utilizan la API de datos para Aurora sin servidor v1 que migren a Aurora sin servidor v2 para aprovechar la API de datos rediseñada y el escalado más granular de Aurora sin servidor v2.

La API de datos le permitirá simplificar y acelerar el desarrollo de aplicaciones modernas. La API de datos es una API segura y fácil de usar basada en HTTP que elimina la necesidad de desplegar controladores de bases de datos, administrar grupos de conexiones del lado del cliente o configurar redes de VPC complejas entre la aplicación y la base de datos. La API de datos también mejora la escalabilidad al agrupar y compartir automáticamente las conexiones de bases de datos, lo que reduce la sobrecarga computacional de las aplicaciones que abren y cierran conexiones con frecuencia. 

La API de datos existente para Aurora sin servidor v1 seguirá siendo una característica de Aurora sin servidor v1 tanto para la edición compatible con PostgreSQL como para la edición compatible con MySQL de Aurora. La API de datos para las instancias aprovisionadas de Aurora sin servidor v2 y Aurora no es compatible con Aurora sin servidor v1. La API de datos para Aurora sin servidor v2 y las instancias aprovisionadas de Aurora son compatibles con las instancias de escritor de la base de datos global de Aurora.

Los usuarios pueden invocar las operaciones de la API de datos solo si están autorizados a hacerlo. Los administradores pueden conceder a un usuario permiso para usar la API de datos adjuntando una política de AWS Identity and Access Management (IAM) que defina sus privilegios. También puede adjuntar la política a un rol si utiliza roles de IAM. Al llamar a la API de datos, puede transferir las credenciales del clúster de base de datos Aurora mediante un secreto en AWS Secrets Manager. 

El uso de la API de datos con Aurora sin servidor v1 sigue disponible sin cargo adicional. La API de datos para las instancias aprovisionadas de Aurora sin servidor v2 y Aurora tiene un precio por volumen de solicitudes de API, tal como se describe en la página de precios de Aurora. La API de datos para las instancias aprovisionadas de Aurora sin servidor v2 y Aurora usa eventos del plano de datos de AWS CloudTrail para registrar la actividad en lugar de eventos de administración, como ocurría con la API de datos para Aurora sin servidor v1.

Puede habilitar el registro de eventos de datos a través de la consola, la CLI o el SDK de CloudTrail si desea realizar un seguimiento de esta actividad. Esto generará cargos según lo establecido en la página de precios de CloudTrail. Además, el uso de AWS Secrets Manager generará cargos según lo establecido en la página de precios de AWS Secrets Manager. 

AWS CloudTrail captura la actividad de la API de AWS como eventos de administración o eventos de datos. Los eventos de administración de CloudTrail (también conocidos como “operaciones de plano de control”) muestran las operaciones de administración que se realizan en los recursos de su cuenta de AWS, como crear, actualizar y eliminar un recurso. Los eventos de datos de CloudTrail (también conocidos como “operaciones de plano de datos”) muestran las operaciones de recursos realizadas en o dentro de un recurso de su cuenta de AWS.

La API de datos realiza operaciones de plano de datos, ya que realiza consultas en los datos de la base de datos Aurora. Por lo tanto, registraremos la actividad de la API de datos como eventos de datos, ya que esta es la categorización correcta de los eventos. Solo se cobrarán cargos por los eventos de datos de CloudTrail si habilita el registro de eventos de datos.

Sí, la capa gratuita de la API de datos incluye un millón de solicitudes al mes, agregadas en todas las regiones de AWS, durante el primer año de uso. Transcurrido un año, los clientes comenzarán a pagar por la API de datos tal y como se describe en la página de precios de Aurora.

Las implementaciones azul-verde de Amazon RDS están disponibles en las versiones 5.6 y posteriores de la edición compatible con PostgreSQL de Amazon Aurora y en las versiones 11.21 y posteriores, 12.16 y posteriores, 13.12 y posteriores, 14.9 y posteriores y 15.4 y posteriores. Obtenga más información sobre las versiones disponibles en la documentación de Aurora.

Las implementaciones azul-verde de Amazon RDS están disponibles en todas las regiones de AWS y las regiones de AWS GovCloud.

Las implementaciones azul-verde de Amazon RDS le permiten realizar cambios de bases de datos con mayor seguridad, sencillez y rapidez. Las implementaciones azul-verde son ideales para casos de uso como actualizaciones del motor de bases de datos de versiones principales o secundarias, actualizaciones del sistema operativo, cambios de esquema en entornos verdes que no interrumpen la replicación lógica, como agregar una nueva columna al final de una tabla o cambios en la configuración de los parámetros de la base de datos.

Puede utilizar las implementaciones azul-verde para realizar varias actualizaciones de bases de datos al mismo tiempo mediante una sola conmutación. Esto le permite mantenerse al día con las revisiones de seguridad, mejorar el rendimiento de la base de datos y acceder a las características más recientes de la base de datos con un tiempo de inactividad breve y predecible. Si solo desea realizar una actualización menor de la versión de Aurora, le recomendamos que utilice la aplicación de parches con tiempo de inactividad cero (ZDP, Zero Downtime Patching).

El precio por ejecutar sus cargas de trabajo en las instancias verdes será el mismo que el de las instancias azules. El costo de ejecución en instancias azules y verdes incluye nuestro precio estándar actual para db.instances, costo de almacenamiento, costo de E/S de lectura/escritura y cualquier característica habilitada, como costo de copias de seguridad e Información de rendimiento de Amazon RDS. De hecho, paga aproximadamente el doble del costo para ejecutar cargas de trabajo en db.instance durante la vida útil de la implementación azul-verde.

Por ejemplo: tiene un clúster de la edición compatible con MySQL de Aurora 5.7 que se ejecuta en dos db.instances r5.2xlarge, una instancia de escritura principal y una instancia de lectura, en la región us-east-1 de AWS. Cada una de las db.instances r5.2xlarge está configurada para almacenamiento de 40 GiB y tiene 25 millones de E/S por mes. Crea un clon de la topología de la instancia azul con las implementaciones azul-verde de Amazon RDS, lo ejecuta durante 15 días (360 horas) y cada instancia verde tiene 3 millones de lecturas de E/S durante ese tiempo. Luego, elimina las instancias azules después de una conmutación exitosa. Las instancias azules (escritor y lector) cuestan 849,2 USD por 15 días a una tarifa bajo demanda de 1,179 USD/h (instancia + almacenamiento + E/S). Las instancias verdes (escritor y lector) cuestan 840,40 USD por 15 días a una tarifa bajo demanda de 1,167 USD/h (instancia + almacenamiento + E/S). El costo total por usar despliegues azul-verde durante esos 15 días es de 1689,60 USD, que es aproximadamente el doble del costo de ejecutar instancias azules durante ese periodo.

Las implementaciones azul-verde de Amazon RDS lo ayudan a realizar cambios de bases de datos más seguros, simples y rápidos, como actualizaciones de versiones principales o secundarias, cambios de esquema, escalado de instancias, cambios de parámetros del motor y actualizaciones de mantenimiento.

En las implementaciones azul-verde de Amazon RDS, el entorno azul es el entorno de producción actual. El entorno verde es el entorno de ensayo, que será el nuevo entorno de producción después de la conmutación.

Cuando las implementaciones azul-verde de Amazon RDS inician una conmutación, se bloquean las escrituras en los entornos azul y verde hasta que se completa la conmutación. Durante la conmutación, el entorno de ensayo, o entorno verde, se actualiza con el sistema de producción, lo que garantiza que los datos sean coherentes entre el entorno de ensayo y el de producción. Una vez que los entornos de producción y ensayo están completamente sincronizados, las implementaciones azul-verde promocionan el entorno de ensayo como nuevo entorno de producción al redirigir el tráfico al entorno de producción recién promocionado.

Las implementaciones azul-verde de Amazon RDS están diseñadas para permitir escrituras en el entorno verde después de que se completa la conmutación, lo que garantiza que no se pierdan datos durante el proceso de conmutación.

Las implementaciones azul-verde de Amazon RDS no eliminan su antiguo entorno de producción. Si es necesario, puede acceder a él para validaciones adicionales y pruebas de rendimiento o regresión. Si ya no necesita el antiguo entorno de producción, puede eliminarlo. Los cargos de facturación estándar se aplican a las instancias de producción antiguas hasta que las elimine.

Si su entorno azul es una réplica lógica autoadministrada o un suscriptor, bloquearemos la conmutación. Se recomienda detener primero la replicación en el entorno azul, continuar con la conmutación y, a continuación, reanudar la replicación. Por el contrario, si su entorno azul es el origen de una réplica lógica autoadministrada o un editor, puede continuar con la conmutación. Sin embargo, tendrá que actualizar la réplica autoadministrada para replicarla desde el entorno verde después de la conmutación.

No, las implementaciones azul-verde de Amazon RDS no admiten bases de datos globales de Amazon Aurora, Amazon RDS Proxy o réplicas de lectura entre regiones.

No, en este momento no puede utilizar las implementaciones azul-verde de Amazon RDS para revertir los cambios.

Las extensiones de lenguaje de confianza (TLE) para PostgreSQL permiten a los desarrolladores crear extensiones de PostgreSQL de alto rendimiento y ejecutarlas de forma segura en Amazon Aurora. Al hacerlo, las TLE mejoran su tiempo de comercialización y eliminan la carga impuesta a los administradores de bases de datos para certificar el código personalizado y de terceros para su uso en cargas de trabajo de bases de datos de producción. Puede avanzar tan pronto como decida que una extensión satisface sus necesidades. Con las LTE, los proveedores de software independientes (ISV) pueden proporcionar a los clientes nuevas extensiones de PostgreSQL que se ejecutan en Aurora.

Las TLE para PostgreSQL están disponibles para la edición compatible con PostgreSQL de Amazon Aurora en las versiones 14.5 y superiores. Las TLE se implementan como una extensión de PostgreSQL y puede activarlas desde el rol rds_superuser de forma similar a otras extensiones admitidas en Aurora.

Puede ejecutar TLE para PostgreSQL en PostgreSQL 14.5 o superiores en Amazon Aurora.

Las TLE para PostgreSQL están disponibles actualmente en todas las regiones de AWS (excepto las regiones de China de AWS) y las regiones de AWS GovCloud.

Las TLE para PostgreSQL están disponibles para los clientes de Aurora sin costo adicional.

Aurora y Amazon RDS admiten un conjunto seleccionado de más de 85 extensiones de PostgreSQL. AWS administra los riesgos de seguridad para cada una de estas extensiones bajo el modelo de responsabilidad compartida de AWS. La extensión que implementa TLE para PostgreSQL se incluye en este conjunto. Las extensiones que escribe o que obtiene de fuentes de terceros e instala en TLE se consideran parte del código de su aplicación. Usted es responsable de la seguridad de sus aplicaciones que usan extensiones de TLE.

Puede crear funciones de desarrollador, como compresión de mapa de bits y privacidad diferencial (como consultas estadísticas de acceso público que protegen la privacidad de las personas).

Las TLE para PostgreSQL actualmente son compatibles con JavaScript, PL/pgSQL, Perl y SQL.

Una vez que el rol rds_superuser activa TLE para PostgreSQL, puede implementar extensiones de TLE mediante el comando SQL CREATE EXTENSION desde cualquier cliente de PostgreSQL, como psql. Esto es similar a cómo crearía una función definida por el usuario escrita en un lenguaje de procedimiento, como PL/pgSQL o PL/Perl. Puede controlar qué usuarios tienen permiso para implementar extensiones de TLE y usar extensiones específicas.

Las TLE para PostgreSQL acceden a su base de datos de PostgreSQL exclusivamente a través de la API de TLE. Los lenguajes de confianza admitidos por TLE incluyen todas las funciones de la interfaz de programación del servidor (SPI) de PostgreSQL y compatibilidad con enlaces de PostgreSQL, incluido el enlace de verificación de contraseña.

Puede obtener más información sobre el proyecto TLE para PostgreSQL en la página oficial de TLE en GitHub.