Preguntas frecuentes de Amazon Aurora

Amazon Aurora es un servicio de base de datos relacional moderno que ofrece rendimiento y alta disponibilidad a escala; ediciones de código abierto totalmente compatibles con MySQL y PostgreSQL; y una amplia gama de herramientas para desarrolladores destinadas a la creación de aplicaciones sin servidor y con tecnología de 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 256 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 manera 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 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 a AWS Premium Support para tratar cuestiones específicas de Aurora.

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 casi ninguna modificación.

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

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

Puede consultar la disponibilidad por región de Aurora aquí.

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 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.

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

• Puede emplear la utilidad mysqldump estándar para exportar datos desde MySQL, así como 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 por medio de 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 las prácticas recomendadas para migrar bases de datos MySQL a Amazon Aurora.

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 se puedan ejecutar 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, aconsejamos que cree las 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 se puedan ejecutar 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 las 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.

Sí. Puede adquirir un Savings Plan para bases de datos para su uso de Amazon Aurora y reducir los costos hasta en un 35 % al comprometerse a un nivel de uso constante durante un período de un año. Puede encontrar información adicional sobre el uso que califica en la página de precios de Savings Plans para bases de datos.

No, la replicación de Aurora está incluida en el precio. Los cargos se aplican 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 con el fin de 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 estándar. No se aplican cargos por las operaciones de E/S de lectura y escritura cuando los clústeres de base de datos están configurados con Amazon Aurora optimizado para E/S.

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 optimizado para operaciones de E/S 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 estándar 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 optimizado para E/S, puede ahorrar aún más en los 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 optimizado para E/S.

Sí, los cargos por las operaciones de E/S necesarias para replicar los datos en las regiones continúan aplicándose. Aurora optimizado para E/S no cobra por las operaciones de E/S de lectura y escritura, lo cual es distinto de los cargos asociados a la replicación de datos.

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

El almacenamiento mínimo es de 10 GiB. El almacenamiento de Aurora aumentará de forma automática en función del uso de la base de datos, hasta 256 TiB, en incrementos de 10 GiB, sin que ello incida en el rendimiento de la base de datos. No es necesario aprovisionar el almacenamiento por adelantado. Aurora ofrece un escalado horizontal automatizado con la base de datos ilimitada de Amazon Aurora PostgreSQL, que amplía el almacenamiento a más de 256 TiB. Para obtener más información, consulte Uso de la base de datos ilimitada de Aurora PostgreSQL.

Hay tres maneras de escalar los recursos de computación asociados a la base de datos de Amazon Aurora: mediante Amazon Aurora sin servidor; la base de datos ilimitada de Aurora PostgreSQL; o mediante el escalado manual. Independientemente de la opción que elija, solo paga por lo que utilice.

Puede utilizar Aurora sin servidor, una configuración bajo demanda de escalado automático para Aurora cuyo objetivo es escalar recursos de computación de bases de datos según la demanda de las aplicaciones. Esta configuración permite ejecutar la 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 la 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.

Con la base de datos ilimitada de Aurora PostgreSQL, puede escalar automáticamente los recursos de computación de forma horizontal en función de los requisitos de carga de trabajo para admitir aplicaciones de gran escala. Le ayuda a escalar las aplicaciones más allá de los límites de almacenamiento y rendimiento de escritura de una única instancia de base de datos, a la vez que mantiene la simplicidad de operar dentro de una sola base de datos. 

También puede escalar de manera manual los recursos de computación asociados a la 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 “Aplicar de inmediato” para cambiar el tipo de instancia de base de datos de manera inmediata.

Las copias de seguridad continuas automatizadas 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, crear 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 los datos sean duraderos de forma automática en tres zonas de disponibilidad dentro de una región y, además, intenta recuperar su base de datos en una zona de disponibilidad 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 a un momento dado en una instancia nueva. Tenga en cuenta que el último momento restaurable para una operación de restauración a un punto en el tiempo puede encontrarse hasta cinco minutos en el pasado.

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 conserva 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. Solo las instantáneas de la base de datos se retienen después de eliminar la instancia de base de datos; es decir, no se mantienen las copias de seguridad automáticas creadas para la restauración a un punto en el tiempo.

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 los distintos entornos (producción, desarrollo/pruebas, preparación, etc.) que utilicen cuentas de AWS diferentes, además de mantener copias de seguridad de todos los datos en una cuenta independiente para garantizar la seguridad en caso de que la cuenta principal de AWS llegue a verse comprometida.

Compartir instantáneas entre cuentas no conlleva ningún cargo. Sin embargo, es posible que se cobre por las instantáneas en sí, así como por cualquier base de datos que restaure a partir de instantáneas compartidas. Obtenga más información sobre 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 o contactar a soporte para incrementar la cuota.

Puede compartir las 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 las 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 están sujetos a un análisis constante en busca de errores y 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 vuelve 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, las cuales 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 para todas las réplicas de Amazon Aurora.

Con la edición de Amazon Aurora compatible con MySQL también puede crear réplicas de lectura de MySQL entre regiones con el motor de replicación basado en binlog de MySQL. En las réplicas de lectura de MySQL, los datos de la instancia principal se reproducen en la 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. Con la base de datos global de Amazon puede lograr una replicación física mucho más rápida entre clústeres de Aurora que se encuentren en regiones distintas. 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 réplicas de Aurora entre regiones por medio de la replicación física o lógica. La replicación física, llamada Base de datos global de Amazon Aurora, utiliza una infraestructura dedicada que deja las bases de datos completamente disponibles para atender a la aplicación. Además, se puede replicar 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 la replicación de binlog de MySQL, que es de un solo subproceso; por ello, el desfase de replicación dependerá tanto del ritmo al que se aplican los cambios como de los retrasos en la comunicación de red entre las regiones seleccionadas.

Sí. Puede agregar hasta 15 réplicas de Aurora en cada clúster entre regiones, y todas compartirán el mismo almacenamiento subyacente que la réplica entre regiones. Una réplica entre regiones actúa como principal dentro del clúster, y las réplicas de Aurora en ese clúster suelen presentar una latencia con respecto a la principal de varias decenas de milisegundos.

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 desencadenará 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á los datos sin afectar el rendimiento de la base de datos y proporcionará una recuperación ante desastres por interrupciones en toda la región.

Amazon Aurora gestiona 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, el cual 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 las aplicaciones y reduce los tiempos de conmutación por error hasta en un 66 %. 
• 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 ejecuta 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 ante desastres en todas las regiones es un proceso manual, en el cual se convierte una región secundaria en principal para que tome cargas de trabajo de lectura/escritura.

Amazon Aurora detectará de forma automática un problema en la instancia principal y desencadenará 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á utiliza el punto de conexión del lector del clúster para direccionar el 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.

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 la replicación no omita transacciones ni genere conflictos, inclusive después de una conmutación por error o tiempo de inactividad.

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.

La 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 los 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 Amazon 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 Interfaz de la línea de comandos de AWS (CLI). Puede usar una configuración mixta de clases de instancias aprovisionadas o sin servidor entre la región principal y las regiones secundarias. También puede configurar la región principal con la configuración de clúster Aurora optimizado para E/S y las regiones secundarias con Aurora estándar, o bien hacerlo a la inversa. Para obtener más información, visite Creación de Base de datos global de Amazon Aurora.

Puede crear hasta cinco regiones secundarias para una Base de datos global de Amazon Aurora.

Sí. Si el 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 la base de datos.

No. Si la región principal deja de estar disponible, puede utilizar la operación de conmutación por error de base de datos global de Aurora administrada entre regiones para convertir una región secundaria en principal y así tener capacidad completa de lectura y escritura. También puede usar el punto de conexión del escritor de la base de datos global de Aurora para evitar la necesidad de modificar el código de la aplicación cuando una región pasa a ser la principal. Para obtener más información, visite Conexión a una Base de datos global de Amazon Aurora.

Sí, todas las instancias de base de datos de Amazon Aurora se deben crear 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 permite ejercer 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 permite cifrar bases de datos con claves que se administran 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 sobre el 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 los datos a la esta.

Para acceder a las bases de datos Aurora, se debe utilizar el puerto de la base de datos ingresado durante su creación. Esto ofrece a los datos una capa adicional de seguridad. En la Guía de conectividad de Amazon Aurora, se detallan instrucciones paso a paso sobre cómo conectarse a la base de datos de Amazon Aurora.

Sí, las ediciones de Aurora compatibles con MySQL y PostgreSQL cumplen con los requisitos de 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) suscrito 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 el anexo. Para obtener más información sobre el uso de AWS para crear aplicaciones conformes, consulte Proveedores de atención médica.

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

Aurora está integrado en Amazon GuardDuty para ayudar 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 la 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, consulte Supervisión de amenazas con la protección de RDS de GuardDuty y la Guía del usuario de la protección de RDS para GuardDuty.

Aurora sin servidor es una configuración de escalado automático bajo demanda para Amazon Aurora. Con Aurora sin servidor, puede ejecutar la 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 sobre Aurora sin servidor y comience a utilizarlo con tan solo unos pasos desde la Consola de administración de Amazon RDS.

Puede ver la información de compatibilidad de Aurora sin servidor v2 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 en el tiempo 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.

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.

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.

En Aurora sin servidor, la capacidad de la base de datos se mide en unidades de capacidad de Aurora (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 los precios y la disponibilidad por región.

La base de datos ilimitada de Aurora PostgreSQL proporciona un escalado horizontal automatizado para procesar millones de transacciones de escritura por segundo y administra petabytes de datos a la vez que mantiene la simplicidad que supone operar dentro de una sola base de datos. Puede concentrarse en crear aplicaciones de alta escala sin tener que diseñar ni mantener soluciones complejas para escalar los datos en múltiples instancias de base de datos a fin de admitir las cargas de trabajo. La base de datos ilimitada de Aurora PostgreSQL se escala en función de la carga de trabajo de la aplicación y solo se paga por lo que consume la aplicación. Para obtener más información, consulte la Guía del usuario de la base de datos ilimitada de Aurora PostgreSQL.

Debe usar la base de datos ilimitada de Aurora PostgreSQL para las aplicaciones que necesitan escalar horizontalmente y requieren más rendimiento de escritura o capacidad de almacenamiento de datos de lo que admite una sola instancia de base de datos de Aurora. Por ejemplo, un usuario puede particionar horizontalmente una aplicación de contabilidad, ya que los datos de contabilidad de cada usuario son independientes de los demás. La base de datos ilimitada de Aurora PostgreSQL se escala automáticamente para admitir las aplicaciones más grandes y de mayor crecimiento. 

Existen dos características de escalado: escalado automático de Amazon Aurora con las replicas de Aurora y Aurora sin servidor v2.

Las replicas de Aurora permiten aumentar la capacidad de lectura del clúster de Aurora más allá de los límites de lo que puede proporcionar una sola instancia de base de datos. Las aplicaciones que separan su carga de trabajo de lectura de la de escritura pueden aprovechar hasta 15 réplicas de lectura para alcanzar un rendimiento de lectura más alto. Las réplicas de Aurora no requieren que la aplicación divida horizontalmente sus datos. Todos los datos están disponibles en todas las réplicas. Las réplicas de Aurora no aumentan la capacidad de almacenamiento de un clúster de Aurora ni el rendimiento de escritura.

Aurora sin servidor v2 es una configuración de escalado vertical bajo demanda para Aurora que proporciona escalado automático del procesamiento y la memoria de la base de datos en función de las necesidades de las aplicaciones dentro de las restricciones de capacidad de una sola instancia de computación. Aurora sin servidor v2 es compatible tanto con las instancias de escritura como con las de lectura. Sin embargo, no aumenta la capacidad de almacenamiento de un clúster de Aurora. Si la aplicación está diseñada para escalar horizontalmente, la base de datos ilimitada de Aurora PostgreSQL permite escalar el rendimiento de escritura y la capacidad de almacenamiento de la base de datos más allá de los límites de una sola instancia de escritura de Aurora

La base de datos ilimitada de Aurora PostgreSQL divide los datos entre instancias de base de datos mediante valores que el cliente define en una columna de la tabla, denominados clave de partición. Por ejemplo, una tabla que almacena información de usuario puede dividirse con la columna ID de usuario como clave de partición. Detrás de bastidores, la base de datos ilimitada de Aurora PostgreSQL es una implementación distribuida de nodos sin servidor. Los nodos son enrutadores o particiones. Los enrutadores administran la naturaleza distribuida de la base de datos. Cada partición almacena un subconjunto de los datos, lo que permite el procesamiento en paralelo para lograr un alto rendimiento de escritura.

A medida que aumentan los requisitos de computación o almacenamiento, Aurora primero escala verticalmente cada instancia y su almacenamiento asociado y, a continuación, escala horizontalmente para atender la carga de trabajo de la base de datos para diferentes valores clave de partición. En todo momento, un valor de clave de partición es controlado y atendido por una única instancia sin servidor. Cuando las aplicaciones se conectan a la base de datos ilimitada de Aurora PostgreSQL y emiten una solicitud, la solicitud se analiza primero. A continuación, se envía a la instancia de computación que posee el valor de la clave de partición especificado en la solicitud o se orquesta una consulta en varias instancias.

Varias instancias de computación, cada una con valores de clave de partición distintos, pueden atender simultáneamente solicitudes de aplicaciones para la misma base de datos ilimitada de Aurora PostgreSQL. La base de datos ilimitada de Aurora PostgreSQL proporciona la misma semántica de transacciones que los sistemas Aurora PostgreSQL de un solo escritor, lo que elimina la complejidad de administrar diferentes dominios de transacciones en la aplicación.

La base de datos ilimitada de Aurora PostgreSQL admite tres tipos de tablas que contienen los datos: particionada, de referencia y estándar.

Tablas particionada: estas tablas se distribuyen en varias particiones. Los datos se dividen entre las particiones en función de los valores de las columnas designadas de la tabla, que se llaman claves de partición. Son útiles para escalar las tablas más grandes y con mayor uso de E/S de la aplicación.

Tablas de referencia: estas tablas copian los datos en su totalidad en cada partición para que las consultas de unión puedan funcionar más rápido al eliminar el movimiento de datos innecesario. Por lo general, se utilizan para datos de referencia que se modifican con poca frecuencia, como catálogos de productos y códigos postales.

Tablas estándar: estas tablas son como las tablas normales de Aurora PostgreSQL. Todas las tablas estándar se colocan juntas en una única partición para que las consultas de unión puedan funcionar más rápido al eliminar el movimiento innecesario de datos. Puede crear tablas particionadas y de referencia a partir de tablas estándar.

Para obtener más información sobre las consideraciones de compatibilidad con PostgreSQL, consulte los requisitos y consideraciones de la base de datos ilimitada de Aurora PostgreSQL.

Puede empezar a utilizar la base de datos ilimitada de Aurora PostgreSQL en la consola de Amazon RDS o las API de Amazon para crear un nuevo clúster de Aurora PostgreSQL con la versión de motor compatible. Para obtener más información sobre cómo empezar, visite la guía del usuario de la base de datos ilimitada de Aurora PostgreSQL.

La aplicación se conecta a la base de datos ilimitada de Aurora PostgreSQL del mismo modo que se conectaría a un clúster de Aurora PostgreSQL estándar. Solo se tiene que conectar al punto de conexión del clúster. Para obtener más información, consulte Uso de la base de datos ilimitada de Aurora PostgreSQL.

Sí, es posible que necesite ajustar el esquema de la base de datos para usar la base de datos ilimitada de Aurora PostgreSQL. Todas las tablas particionadas deben contener la clave de partición; en consecuencia, es posible que sea necesario completar esos datos de manera retroactiva. Por ejemplo, una aplicación de contabilidad puede dividir sus datos por usuario mediante la columna ID de usuario, ya que cada usuario es independiente de los demás. Si bien la propia tabla de usuarios contiene esta columna de manera natural,
es posible que otras tablas no, como una tabla que contenga las partidas de las facturas. Dado que estas tablas también se deben dividir por usuario para colocarlas y lograr un rendimiento óptimo de las consultas, es necesario agregar la columna ID de usuario a la tabla.

No hay restricciones de nombre en la columna que se usa para dividir los datos, pero la definición de la columna debe coincidir. Tendrá que agregar la clave de partición a las consultas de la aplicación y es posible que también necesite ajustar las consultas y transacciones para obtener un rendimiento óptimo. Por ejemplo, buscar una factura con el identificador de factura cuando la tabla solo está dividida por el identificador de usuario sería lento porque la consulta tendría que ejecutarse en todas las instancias de la base de datos. Sin embargo, si la consulta también especifica el ID de usuario, la consulta se dirigirá a la única instancia de base de datos que contiene todos los pedidos de ese ID de usuario, lo que reduce la latencia de la consulta.

Sí. Puede elegir una opción de alta disponibilidad al configurar la redundancia de computación para que sea superior a cero para la base de datos ilimitada de Aurora PostgreSQL, lo que proporciona una disponibilidad del 99,99 %. Cada instancia de computación que almacena y accede a los datos de la base de datos ilimitada de Aurora PostgreSQL puede tener una o dos instancias en espera que pueden hacerse cargo de las solicitudes si la principal no está disponible. Los enrutadores redirigirán automáticamente el tráfico para reducir al mínimo el impacto en la aplicación.

La base de datos ilimitada Aurora PostgreSQL está disponible para la configuración de clústeres optimizados para E/S de Aurora con compatibilidad con PostgreSQL 16.4. Encontrará información adicional sobre la disponibilidad regional de AWS para la base de datos ilimitada de Aurora PostgreSQL en la página de precios de Aurora.

En la base de datos ilimitada de Aurora PostgreSQL, la capacidad de la base de datos se mide en ACU. Paga una tarifa fija por segundo de uso de ACU. Se aplican las tarifas de almacenamiento de configuración optimizada para E/S de Aurora. Para obtener más información, visite la página de precios de Aurora.

Las consultas en paralelo de Amazon Aurora hacen referencia a la capacidad de reducir y distribuir la carga computacional de una sola consulta en miles de CPU en la capa de almacenamiento de Aurora. Sin la consulta paralela, una consulta ejecutada en una base de datos de Amazon Aurora se procesaría por completo dentro de una sola instancia del clúster de bases de datos, de forma similar al funcionamiento de la mayoría de las bases de datos.

La consulta paralela es una excelente opción para cargas de trabajo de análisis que necesitan datos actualizados y un buen rendimiento de consultas, inclusive en tablas de gran tamaño. A menudo, las cargas de trabajo de este tipo son de naturaleza operativa.

La consulta en paralelo ofrece un rendimiento más rápido, lo que agiliza las consultas analíticas hasta en dos órdenes de magnitud. También ofrece simplicidad operativa y actualización de datos, ya que puede enviar una consulta de forma directa a los datos transaccionales actuales en su clúster de Aurora. Además, la consulta en paralelo habilita las cargas de trabajo transaccionales y de análisis en la misma base de datos al permitir a Aurora mantener un alto rendimiento de transacciones junto con consultas analíticas simultáneas.

La mayoría de las consultas que operan sobre conjuntos de datos grandes que aún no están en el búfer suelen obtener mejoras. La versión inicial de consulta paralela puede trasladar, y escalar horizontalmente, el procesamiento de más de 200 funciones SQL, uniones de igualdad y proyecciones.

La mejora de rendimiento en una consulta específica depende de cuánto del plan de consulta se puede enviar a la capa de almacenamiento de Aurora. Los clientes informaron mejoras de una orden de magnitud en relación con la latencia de las consultas.

Sí, pero esperamos que dichos casos no sean frecuentes.

No se necesita hacer ninguna modificación en la sintaxis de la consulta. El optimizador de consultas decidirá de manera automática si se utilizará la consulta en paralelo para su consulta específica. Para averiguar si una consulta está utilizando la consulta en paralelo, ejecute el comando EXPLAIN para ver el plan de ejecución de la consulta. Si desea omitir la heurística y forzar la consulta en paralelo para hacer pruebas, utilice la variable de sesión aurora_pq_force.

La consulta en paralelo se puede activar y desactivar de manera dinámica a nivel de sesión y global con el parámetro aurora_pq.

No. No se cobran cargos adicionales además de lo que ya paga por las instancias, las operaciones de E/S y el almacenamiento.

No, los costos de E/S de la consulta se calculan en la capa de almacenamiento y serán los mismos o mayores con la consulta en paralelo activada. El beneficio es la mejora en el nivel de rendimiento de las consultas.

Existen dos razones por las cuales se podrían generar costos de E/S más altos con la consulta en paralelo. En primer lugar, aunque algunos de los datos en una tabla estén en el grupo de búferes, la consulta en paralelo necesita que todos los datos se escaneen en la capa de almacenamiento, lo que genera E/S. En segundo lugar, un efecto secundario de evitar la contención en el grupo de búferes es que ejecutar una consulta en paralelo no prepara al grupo de búferes. Como resultado, las ejecuciones consecutivas de la misma consulta en paralelo generarán el costo pleno de E/S.

Obtenga más información sobre las consultas en paralelo en la documentación.

No. En este momento, puede utilizar la consulta en paralelo con instancias en la familia de instancias R*.

La consulta en paralelo está disponible para la versión compatible con MySQL 5.7 y MySQL 8.0 de Amazon Aurora.

La consulta en paralelo es compatible con Aurora sin servidor v2 y Backtrack.

No. Si bien esperamos que la consulta en paralelo mejore la latencia de las consultas en la mayoría de los casos, podrían generarse costos de E/S elevados. Recomendamos que pruebe minuciosamente su carga de trabajo con la característica habilitada y deshabilitada. Una vez que esté convencido de que la consulta en paralelo es la opción correcta, podrá confiar en el optimizador de consultas para decidir de manera automática qué consultas utilizarán la consulta en paralelo. En el excepcional caso de que el optimizador no tome la decisión óptima, podrá anular la configuración.

La consulta en paralelo de Aurora no es un almacenamiento de datos y, por lo tanto, no suministra la funcionalidad que normalmente ofrecen dichos productos. Está diseñado para acelerar el rendimiento de las consultas en la base de datos relacional y resulta adecuado para casos de uso como los análisis de las operaciones, cuando necesita ejecutar consultas de análisis rápidas sobre datos recientes en la base de datos.

Para acceder a un almacén de datos en la nube a escala de exabytes, considere utilizar Amazon Redshift.

Las lecturas optimizadas de Amazon Aurora, disponibles para Aurora PostgreSQL, ofrecen una nueva opción de precio y rendimiento con 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.

Con las lecturas optimizadas de Amazon Aurora para Aurora PostgreSQL, los clientes con aplicaciones sensibles a la latencia y grandes conjuntos de trabajo acceden a una alternativa convincente en relación precio-calidad para cumplir sus SLA empresariales y obtener aún más rendimiento de las instancias.

Las lecturas optimizadas de Amazon Aurora están disponibles en instancias R6gd con tecnología de Intel y R6gd con tecnología de Graviton. Puede consultar la disponibilidad por 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 posteriores y la 14.9 o posteriores en Aurora PostgreSQL.

Las lecturas optimizadas de Amazon Aurora no están disponibles en Aurora sin servidor v2 (ASv2).

Sí, las lecturas optimizadas de Amazon Aurora están disponibles 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 en E/S con predominio de lecturas, las instancias con la función de lecturas optimizadas habilitada en Aurora PostgreSQL y configuradas con Aurora optimizado para E/S almacenan automáticamente en caché, en el almacenamiento local basado en NVMe, los datos que salen de la memoria. Esto permite obtener hasta 8 veces menos latencia en consultas y hasta un 30 % de ahorro en costos en comparación con instancias que no cuentan con esta optimización, especialmente en aplicaciones con conjuntos de datos grandes 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 los 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 las lecturas optimizadas de Amazon Aurora para comenzar.

Aproximadamente el 90 % del almacenamiento local disponible en las instancias R6id y R6gd está disponible para las lecturas optimizadas. 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, al utilizar una instancia r6gd.8xlarge con las características Objetos temporales y Almacenamiento en caché por niveles habilitadas, se reservan 534 GiB (el doble de la capacidad de memoria) para objetos temporales y 1054 GiB para la 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. Los clientes que ejecutan cargas de trabajo independientes en sus destinos designados para conmutación por error pueden evaluar si prefieren una recuperación de latencia inmediata después de la conmutación por error o maximizar la eficacia a largo plazo del rendimiento de la caché, antes de habilitar CCM.

pgvector es una extensión de código abierto para PostgreSQL que la edición compatible con PostgreSQL de Amazon Aurora admite.

Puede utilizar pgvector para almacenar, buscar, indexar y consultar miles de millones de incrustaciones generadas a partir de modelos de machine learning (ML) e inteligencia artificial (IA) en la base de datos, como las de Amazon Bedrock o Amazon SageMaker. Una incrustación vectorial es una representación numérica que representa el significado semántico del contenido, como texto, imágenes y video.

Con pgvector, puede consultar incrustaciones en su base de datos de Aurora PostgreSQL para hacer búsquedas de similitud semántica eficientes de estos tipos de datos, representados como vectores, combinados con otros datos tabulares en Aurora. Esto permite el uso de la IA generativa y otros sistemas de IA y ML para nuevos tipos de aplicaciones, como recomendaciones personalizadas basadas en descripciones de texto o imágenes similares, la búsqueda de candidatos en función de las notas de la entrevista, los chatbots, las recomendaciones del servicio de atención al cliente sobre la siguiente acción recomendada en función de transcripciones satisfactorias o diálogos de sesiones de chat, etc. 

Lea nuestro blog sobre las capacidades de las bases de datos vectoriales y aprenda a almacenar incrustaciones con la extensión pgvector en una base de datos de Aurora PostgreSQL, a crear un chatbot interactivo para responder a preguntas y a utilizar la integración nativa entre pgvector y el machine learning de Aurora para el análisis de opiniones.

Sí. El machine learning (ML) de Aurora expone los modelos de ML como funciones SQL, lo que permite usar SQL estándar para llamar a los modelos de ML, transferirles 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, trasladar las incrustaciones por lotes a Aurora PostgreSQL.

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

Sí. Existen dos métodos para integrar las bases de datos de Amazon Aurora en Amazon Bedrock como tecnología para las aplicaciones de IA generativa. Primero, el ML de Amazon Aurora brinda acceso a los modelos fundacionales disponibles en Amazon Bedrock directamente a través de SQL para Aurora MySQL y Aurora PostgreSQL. Segundo, puede configurar Aurora como almacén de vectores en las bases de conocimiento de Amazon Bedrock con un solo clic y almacenar las incrustaciones generadas desde Bedrock en Aurora. Las bases de conocimiento de Amazon Bedrock son compatibles con Aurora PostgreSQL como almacén de vectores para casos de uso como generación aumentada por recuperación (RAG). Lea nuestro blog y documentación sobre Uso de Aurora PostgreSQL como base de conocimientos para Amazon Bedrock.

Las lecturas optimizadas de Amazon Aurora PostgreSQL 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 funcionalidad de almacenamiento en caché por niveles disponible en las lecturas optimizadas, la cual almacena automáticamente en el almacenamiento local los datos que salen de la caché en memoria del búfer de la base de datos. Esto permite acelerar los accesos posteriores a esos datos.

Lea nuestro blog y documentación sobre cómo mejorar el rendimiento de consultas de Aurora PostgreSQL con las lecturas optimizadas de Aurora.

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 permite aprovechar Amazon Redshift ML con comandos SQL sencillos.

La integración sin ETL de Amazon Aurora con Amazon SageMaker permite trasladar los datos de las bases de datos operativas y aplicaciones al almacén de lago casi en tiempo real. Con la arquitectura de almacén de lago de SageMaker, puede crear un almacén de lago abierto a partir de sus inversiones actuales en datos, sin modificar la arquitectura de datos, y utilizar las herramientas de análisis que prefiera y motores de consultas, como SQL, Apache Spark, BI y herramientas de IA/ML.

La integración sin ETL de Aurora con Amazon Redshift está disponible en la edición de Aurora compatible con MySQL para Aurora MySQL versión 3.05.2 (compatible con MySQL 8.0.32) y en las versiones posteriores. La integración sin ETL de Aurora en Amazon Redshift está disponible en la edición compatible con Aurora PostgreSQL para Aurora PostgreSQL 16.4 y en las versiones posteriores.

La integración sin ETL de Aurora con Amazon SageMaker está disponible en la edición de Aurora compatible con MySQL para Aurora MySQL versión 3.05.0 (compatible con MySQL 8.0.32) y en las versiones posteriores. La integración sin ETL de Aurora con Amazon SageMaker está disponible en la edición compatible con PostgreSQL de Aurora para las versiones Aurora PostgreSQL 16.4 y posteriores, así como Aurora PostgreSQL 17.4 y posteriores.

Visite características compatibles en Aurora por región de AWS y motor de base de datos de Aurora para obtener más información sobre la disponibilidad por región de AWS para la integración sin ETL.

La integración sin ETL de Aurora con Amazon Redshift y Amazon SageMaker elimina la necesidad de crear y mantener canalizaciones de datos complejas. Puede unificar datos de varias tablas procedentes de distintos clústeres de bases de datos de Aurora en un único clúster de base de datos de Amazon Redshift o en la arquitectura de almacén de lago de SageMaker, y ejecutar análisis casi en tiempo real y modelos de machine learning sobre los datos operativos 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 administrar ninguna infraestructura para canalizaciones de datos. 

La integración sin ETL de Aurora con Amazon SageMaker es compatible con Aurora sin servidor v2.

Para empezar, utilice la consola de Amazon RDS para crear la integración sin ETL. Al hacerlo, especifique tanto el origen de Aurora como el destino. Una vez que la integración se haya creado, la base de datos de Aurora se replicará en el destino y podrá comenzar a consultar los datos cuando finalice la carga inicial. Para obtener más información, consulte la guía de introducción sobre las Integraciones sin ETL de Aurora con Amazon Redshift y la Integración sin ETL de Aurora con Amazon SageMaker.

El procesamiento continuo de los cambios en los datos mediante la integración sin ETL se ofrece sin costo adicional. Paga por los recursos existentes que se utilizan para crear y procesar los datos de cambio 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 que carga inicialmente las bases de datos
• Almacenamiento adicional para almacenar datos replicados
• Computación adicional para el procesamiento de la replicación de datos
• Costos de transferencia de datos entre zonas de disponibilidad para trasladar datos del origen al destino

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

Sí. Puede administrar y automatizar la configuración y la implementación de los recursos necesarios para una integración sin ETL de Aurora mediante AWS CloudFormation. Para obtener más información, visite Plantillas de CloudFormation con la integración sin ETL.

CloudWatch Database Insights es una solución de supervisión y métricas que simplifica y mejora la resolución de problemas de bases de datos. Automatiza la recopilación de telemetría, incluidos métricas, registros y seguimientos, y elimina la necesidad de realizar configuraciones o ajustes manuales. Al consolidar esta telemetría en Amazon CloudWatch, CloudWatch Database Insights proporciona una visión unificada del rendimiento y el estado de las bases de datos.

Estas son algunas ventajas que ofrece CloudWatch Database Insights:

1. Recopilación telemétrica sin esfuerzo: recopila automáticamente las métricas, los registros y los seguimientos de la base de datos, lo que minimiza el tiempo de configuración.
2. Información selecta: proporciona paneles, alarmas e información prediseñados para supervisar y optimizar el rendimiento de la base de datos, con una configuración mínima necesaria para comenzar.
3. Vista unificada de CloudWatch: combina la telemetría de varias bases de datos en una sola vista para simplificar la supervisión.
4. Capacidades de IA/ML: utiliza IA/ML para detectar anomalías, lo que reduce los esfuerzos manuales de solución de problemas.
5. Supervisión del contexto de la aplicación: permite a los usuarios establecer correlaciones entre el rendimiento de la base de datos y el rendimiento de la aplicación.
6. Vistas a nivel de flota e instancia: ofrece supervisión de flota de alto nivel y vistas detalladas de instancias para el análisis de la causa raíz.
7. Integración perfecta con AWS: se integra con Amazon CloudWatch Application Signals y AWS X-Ray, lo que permite una experiencia de observabilidad integral.

Amazon DevOps Guru para RDS es una capacidad basada en el ML para Amazon RDS (que incluye a Amazon Aurora), la cual 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, diseñada para detectar problemas operativos y de rendimiento en 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 inmediato a los desarrolladores y a los ingenieros de DevOps, y ofrecer información de diagnóstico, detalles sobre el alcance del problema y recomendaciones de remediación inteligente que ayudan a los clientes a resolver con rapidez los cuellos de botella de rendimiento y los problemas operativos relacionados con la base de datos.

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 facilita la administración de bases de datos para quienes no son expertos y, al mismo tiempo, ayuda a los especialistas en bases de datos a administrar una cantidad aún mayor de 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 (PI). DevOps Guru para RDS no utiliza ninguno de los datos almacenados en la base de datos durante su análisis. Información de rendimiento mide la carga de la base de datos, una métrica que caracteriza cómo una aplicación utiliza el tiempo dentro de la base de datos, junto con métricas seleccionadas generadas por la propia 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 habilitar Información de rendimiento desde la consola de RDS y, después, simplemente habilite DevOps Guru para las bases de datos de Amazon Aurora. Con DevOps Guru, puede elegir que el alcance del análisis abarque toda la cuenta de AWS, especificar las pilas de AWS CloudFormation que desea que DevOps Guru analice o utilizar etiquetas de AWS para definir el conjunto de recursos que desea que DevOps Guru evalúe.

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.

Información de rendimiento de Amazon RDS es una característica de ajuste y supervisión del rendimiento que recopila y visualiza métricas de rendimiento de las bases de datos en Amazon RDS. Esta información permite evaluar con rapidez la carga de las bases de datos y determinar cuándo y dónde es necesario tomar medidas. Amazon DevOps Guru para RDS está diseñado para supervisar esas métricas, detectar cuando la base de datos enfrenta problemas de rendimiento, analizarlas y, posteriormente, indicarle qué falla y qué acciones puede tomar para resolverlo.

CloudWatch Database Insights supervisa en tiempo real los recursos y las aplicaciones de Aurora, y presenta los datos mediante paneles personalizables. Por el contrario, Amazon DevOps Guru es un servicio de machine learning (ML) que analiza las métricas de CloudWatch para comprender el comportamiento de una aplicación a lo largo del tiempo, detectar anomalías y ofrecer información y recomendaciones para la resolución de problemas. Además, DevOps Guru analiza datos de varios orígenes, incluidos AWS Config, AWS CloudFormation y AWS X-Ray. Puede usar los paneles de CloudWatch para supervisar la información de DevOps Guru mediante las métricas publicadas en el espacio de nombres AWS/DevOps-Guru. Esto ayuda a ver toda la información y las anomalías en un único panel de visualización en la consola de CloudWatch.

Información de rendimiento de RDS es una característica de ajuste y supervisión del rendimiento que permite a los clientes evaluar la carga de las bases de datos y determinar cuándo y dónde deben tomar medidas. CloudWatch Database Insights es una nueva característica de observabilidad para bases de datos que incorpora todas las capacidades de Información de rendimiento, junto con la supervisión a nivel de flota, la integración con la supervisión del rendimiento de aplicaciones y la correlación de métricas de bases de datos con registros y eventos.

Debe usar la API de datos para nuevas aplicaciones modernas, en particular aquellas creadas con AWS Lambda, las cuales 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 conexiones persistentes cuando una aplicación existente esté estrechamente acoplada a los controladores de base de datos, cuando existan consultas de larga duración o cuando se desee aprovechar características de la base de datos, como las tablas temporales, o utilizar variables de sesión.

La disponibilidad de la API de datos por región de AWS y por versión de base de datos para Aurora sin servidor v2 y para las instancias aprovisionadas de Aurora se encuentra disponible en nuestra documentación.

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 de forma automática las conexiones de base de datos, lo que reduce la sobrecarga computacional de las aplicaciones que abren y cierran conexiones con frecuencia. 

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 mediante la asociación de una política de AWS Identity and Access Management (IAM) que defina sus privilegios. Si utiliza roles de IAM, también puede asociar la política a un rol. Cuando invoca la API de datos, puede proporcionar las credenciales del clúster de bases de datos de Aurora mediante un secreto en AWS Secrets Manager. 

La API de datos para las instancias aprovisionadas de Aurora y Aurora sin servidor v2 se factura según el volumen de solicitudes de la API, tal como se describe en la página de precios de Aurora. La API de datos para Aurora sin servidor v2 y las instancias aprovisionadas de Aurora utiliza eventos del plano de datos de AWS CloudTrail para registrar la actividad, en lugar de usar eventos de administración.

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 la 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í. El nivel gratuito de la API de datos incluye un millón de solicitudes al mes, sumadas entre todas las regiones de AWS, durante el primer año de uso. Luego de 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 disponible en la edición de Amazon Aurora compatible con MySQL a partir de la versión 5.6 y en la edición de Amazon Aurora compatible con PostgreSQL a partir de las versiones 11.21 y superiores, 12.16 y superiores, 13.12 y superiores, 14.9 y superiores, y 15.4 y superiores. 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 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, todo con un tiempo de inactividad breve y predecible. Si solo desea realizar una actualización de versión secundaria en Aurora, recomendamos utilizar Aplicación de parches sin tiempo de inactividad de Aurora (ZDP).

Incurrirá en el mismo costo por ejecutar las cargas de trabajo en las instancias verdes que en 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. En la práctica, paga aproximadamente el doble del costo de ejecutar las cargas de trabajo en una instancia de base de datos durante todo el período de vida 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 implementaciones 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 facilitan la realización de cambios en bases de datos de forma más segura, sencilla y rápida, incluidos las actualizaciones de versiones principales o secundarias, las modificaciones de esquema, el escalado de instancias, los cambios en los parámetros del motor y las 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, 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 convierten el entorno de ensayo en el nuevo entorno de producción mediante la redirección del tráfico hacia ese entorno ya convertido.

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 el antiguo entorno de producción. Si es necesario, puede acceder a este 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.

Las barreras de protección de conmutación en las implementaciones azul-verde de Amazon RDS bloquean las escrituras tanto en el entorno azul como en el verde hasta que el entorno verde se ha actualizado por completo, antes de realizar el cambio. Las implementaciones azul/verde también realizan comprobaciones de estado del entorno principal y las réplicas en los entornos azul y verde. Además, realizan comprobaciones del estado de la replicación, por ejemplo, para ver si la replicación se ha detenido o si hay errores. Detectan transacciones de ejecución prolongada entre los entornos azul y verde. Puede especificar el tiempo máximo de inactividad que considera tolerable (tan bajo como 30 segundos) y, si existe una transacción en curso que excede ese límite, la conmutación vencerá por tiempo excedido.

Si el entorno azul es una réplica lógica autoadministrada o un editor, 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.

Sí. Las implementaciones azul-verde de Amazon RDS son compatibles con la Base de datos global de Aurora. Para obtener más información, consulte la Guía del usuario de implementaciones azul-verde para la Base de datos global de Amazon Aurora.

No. Las implementaciones azul-verde de Amazon RDS no son compatibles con Amazon RDS Proxy ni con réplicas de lectura entre regiones. 

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

Con las extensiones de lenguaje de confianza (TLE) para PostgreSQL, los desarrolladores crean extensiones de PostgreSQL de alto rendimiento y las ejecutan de forma segura en Amazon Aurora. Al hacerlo, las TLE aceleran el tiempo de comercialización y eliminan la carga para los administradores de bases datos que supone tener que certificar código personalizado o 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 TLE, los proveedores de software independientes (ISV) pueden proporcionar a los clientes nuevas extensiones de PostgreSQL que se ejecutan en Aurora.

Las extensiones de PostgreSQL se ejecutan en el mismo espacio de proceso para conseguir un alto rendimiento. Sin embargo, las extensiones pueden tener defectos de software que pueden bloquear la base de datos.

Las TLE para PostgreSQL ofrecen distintas capas de protección para mitigar este riesgo. Las TLE están diseñadas para limitar el acceso a los recursos del sistema. El rol rds_superuser puede determinar quién tiene permiso para instalar extensiones específicas. Sin embargo, estos cambios solo se pueden realizar a través de la API de TLE. Las TLE están diseñadas para limitar el impacto de un defecto de extensión a una única conexión de base de datos. Además de estas barreras de protección, las TLE están diseñadas para brindar a los administradores de bases de datos (DBA) con el rol rds_superuser un control detallado y en línea sobre quién puede instalar extensiones, así como la capacidad de definir un modelo de permisos para su ejecución. Solo los usuarios con privilegios suficientes podrán ejecutar y crear extensiones mediante el comando CREATE EXTENSION en una extensión de TLE. Los administradores de bases de datos también pueden incluir en una lista de permisos los enlaces de PostgreSQL necesarios para extensiones más sofisticadas que modifican el comportamiento interno de la base de datos y que, por lo general, requieren privilegios elevados.

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 las TLE para PostgreSQL en PostgreSQL 14.5 o superiores en Amazon Aurora.

Actualmente, las TLE para PostgreSQL están disponibles 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 sin costo adicional para los clientes de Aurora.

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 las 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 la 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).

Actualmente, las TLE para PostgreSQL son compatibles con JavaScript, PL/pgSQL, Perl y SQL.

Una vez que el rol rds_superuser activa las TLE para PostgreSQL, puede implementar extensiones de TLE con 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 la base de datos de PostgreSQL exclusivamente a través de la API de TLE. Los lenguajes de confianza admitidos por las 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.

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