Preguntas frecuentes de Amazon RDS

Se puede concebir una instancia de base de datos como un entorno de base de datos en la nube con los recursos de computación y almacenamiento que usted especifique. Puede crear instancias de bases de datos y eliminarlas, definir los atributos de infraestructura de las instancias, ajustarlos y controlar el acceso y la seguridad a través de la Consola de administración de AWS, las API de Amazon RDS y la Interfaz de línea de comandos de AWS. Puede ejecutar una o más instancias de bases de datos y cada una de ellas puede admitir una o más bases de datos o esquemas de bases de datos, según el tipo de motor.

Las instancias de bases de datos son fáciles de crear a través de la consola de administración de AWS, las API de Amazon RDS o la Interfaz de la línea de comandos de AWS. Para lanzar una instancia de base de datos con la consola de administración de AWS, haga clic en “RDS” y, a continuación, en el botón “Launch DB Instance” (Lanzar instancia de base de datos) de la pestaña “Instances” (Instancias). Desde allí, puede especificar los parámetros de su instancia de base de datos, incluidos el motor y la versión de la base de datos, el modelo de licencia, el tipo de instancia, el tipo y el volumen de almacenamiento, y las credenciales del usuario principal.

También tendrá la posibilidad de modificar la política de retención de copias de seguridad, el periodo de respaldo preferido y el periodo de mantenimiento programado de su instancia de base de datos. Si lo prefiere, puede crear la instancia de base de datos mediante la API CreateDBInstance o el comando create-db-instance.

Una vez que su instancia de base de datos está disponible, puede recuperar su punto de conexión a través de la descripción de la instancia de base de datos en la Consola de administración de AWS, la API DescribeDBInstances o el comando describe-db-instances. Con este punto de conexión puede construir la cadena de conexión necesaria para conectar directamente con su instancia de base de datos mediante su herramienta de base de datos o lenguaje de programación favoritos. Para permitir solicitudes de red en la instancia de base de datos en ejecución, deberá autorizar el acceso. Si quiere obtener una explicación detallada para construir la cadena de conexión y comenzar, consulte nuestra Guía de introducción.

De manera predeterminada, los clientes pueden acceder hasta un total de 40 instancias de base de datos en Amazon RDS. De las 40, hasta 10 pueden ser instancias de bases de datos de RDS para Oracle o RDS para SQL Server con el modelo de licencia incluida. Los 40 se pueden usar para Amazon Aurora, RDS para PostgreSQL, RDS para MySQL, RDS para MariaDB y RDS para Oracle bajo el modelo de uso de su propia licencia (BYOL). Tenga en cuenta que RDS para SQL Server tiene un límite de 100 bases de datos en una única instancia de base de datos. Para obtener más información, consulte la Guía del usuario de Amazon RDS para SQL Server.

• RDS para Amazon Aurora: ningún límite impuesto por el software
• RDS para MySQL: ningún límite impuesto por el software
• RDS para MariaDB: ningún límite impuesto por el software
• RDS para Oracle: una base de datos por instancia; no hay límite en el número de esquemas por base de datos impuesto por el software
• RDS para SQL Server: hasta 100 bases de datos por instancia
• RDS para PostgreSQL: ningún límite impuesto por el software
• RDS para Db2: hasta 1 base de datos por instancia

Las siguientes son varias formas de importar datos a Amazon RDS:

• MySQL: utilidades mysqldump o mysqlimport
• Oracle: bomba de datos, importación/exportación o SQL Loader
• SQL Server: asistente de importación/exportación, archivos de respaldo completos (.bak) o programa de copia masiva (BCP)
• PostgreSQL: pg_dump

Para obtener más información sobre la importación y exportación de datos, consulte la Guía de importación de datos para MySQL, la Guía de importación de datos para Oracle, la Guía de importación de datos para SQL Server, la Guía de importación de datos para PostgreSQL o la Guía de importación de datos para Db2.

Además, AWS Database Migration Service le ayuda a migrar bases de datos a AWS de forma fácil y segura.

El periodo de mantenimiento de Amazon RDS le permite controlar cuándo tendrán lugar las modificaciones en las instancias de bases de datos, las actualizaciones de versiones en los motores de bases de datos y las revisiones del software, en caso de que se solicite alguna de ellas o sean necesarias. Si hay un evento de mantenimiento programado para una determinada semana, se iniciará durante el periodo de mantenimiento que usted haya definido.

Los eventos de mantenimiento que necesitan que Amazon RDS desconecte su instancia de base de datos son las operaciones informáticas de escala (que se suelen realizar en cuestión de minutos), las actualizaciones de versiones en motores de bases de datos y la implementación de parches necesarios en el software. Los parches de software necesarios relacionados con seguridad o durabilidad son los únicos que se programan automáticamente. El despliegue de estas revisiones tiene lugar con poca frecuencia (normalmente, una vez cada varios meses) y raramente necesitará más de una fracción del periodo de mantenimiento.

Si no establece un periodo de mantenimiento semanal preferido al momento de crear la instancia de base de datos, se asignará un valor predeterminado de 30 minutos. Si quiere modificar el momento en el que se lleva a cabo el mantenimiento en su nombre, modifique la instancia de base de datos en la Consola de administración de AWS, la API ModifyDBInstance o el comando modify-db-instance para hacerlo. Puede configurar varios periodos de mantenimiento preferidos para cada una de sus instancias de base de datos.

La ejecución de su instancia de base de datos como implementación Multi-AZ puede reducir aún más el impacto de un evento de mantenimiento. Consulte la Guía del usuario de Amazon RDS para obtener más información sobre las operaciones de mantenimiento.

Para las bases de datos de producción, le recomendamos habilitar Enhanced Monitoring, que proporciona acceso a más de 50 métricas de CPU, memoria, sistema de archivos y E/S de disco. Puede activar estas características por instancia y puede elegir un análisis minucioso (de hasta 1 segundo). El uso intensivo del procesador puede reducir el rendimiento de las consultas, en cuyo caso puede barajar la posibilidad de ajustar la escala de la clase de instancia de base de datos. Si quiere obtener más información para monitorizar la instancia de base de datos, consulte la Guía del usuario de Amazon RDS.

Si usa RDS para MySQL o MariaDB, puede obtener acceso a los registros de consultas lentas en la base de datos para determinar si existen consultas SQL que se están ejecutando a menor velocidad y, en ese caso, observar las características de rendimiento de cada una. Podría definir el parámetro de base de datos “slow_query_log” y consultar la tabla mysql.slow_log para revisar las consultas SQL que se están ejecutando a menor velocidad. Consulte la Guía del usuario de Amazon RDS para obtener más información.

Si utiliza RDS para Oracle, puede usar los datos del archivo de rastreo de Oracle para identificar las consultas lentas. Para obtener más información sobre el acceso a los datos del archivo de rastreo, consulte la Guía del usuario de Amazon RDS. 

Si utiliza RDS para SQL Server, puede utilizar el rastreo de SQL Server del lado cliente para identificar las consultas lentas. Para obtener información sobre el acceso a los datos del archivo de rastreo del servidor, consulte la Guía del usuario de Amazon RDS.

Si desea obtener una lista de las versiones de los motores de bases de datos admitidas, consulte la documentación de cada motor:

• Amazon Aurora
• Amazon RDS for PostgreSQL
• Amazon RDS para MySQL
• Amazon RDS for MariaDB
• Amazon RDS para SQL Server
• Amazon RDS para Oracle
• Amazon RDS para Db2

Consulte la página de preguntas frecuentes de cada motor de base de datos de Amazon RDS para obtener información específica sobre la numeración de versiones:

• Amazon RDS para MySQL
• Amazon RDS for MariaDB
• Amazon RDS for PostgreSQL
• Amazon RDS for Oracle
• Amazon RDS for SQL Server
• Amazon Aurora
• Amazon RDS para Db2

Con el tiempo, Amazon RDS admite nuevas versiones principales y secundarias de los motores de bases de datos. El número de nuevas versiones admitidas variará en función de la frecuencia y el contenido de los lanzamientos y las revisiones del proveedor del motor o de la organización que lo desarrolla y del resultado de un examen minucioso de estos lanzamientos y estas revisiones realizados por nuestro equipo de ingeniería de bases de datos. Sin embargo, por lo general, nuestro objetivo es admitir nuevas versiones de los motores transcurridos 5 meses de su lanzamiento.

Puede especificar cualquier versión admitida actualmente (principal y secundaria) al crear una nueva instancia de base de datos mediante la operación Launch DB Instance (Lanzar instancia de base de datos) en la Consola de administración de AWS o la API CreateDBInstance. Tenga en cuenta que no todas las versiones de motor de base de datos están disponibles en todas las regiones de AWS.

Amazon RDS se esfuerza por mantener su instancia de base de datos actualizada proporcionándole versiones más nuevas de los motores de base de datos compatibles. Tras el lanzamiento de la nueva versión de un motor de base de datos por parte del proveedor o de la organización que lo desarrolla, nuestro equipo de ingeniería de base de datos la prueba a fondo antes de que esté disponible en Amazon RDS.

Le recomendamos que la instancia de base de datos esté actualizada con la versión secundaria más reciente, ya que incluirá las últimas correcciones de seguridad y funcionalidad. A diferencia de las actualizaciones de versiones principales, cuando se actualiza una versión secundaria, solo se incluyen en la base de datos cambios compatibles con versiones secundarias previas del motor de base de datos, dentro de una misma versión principal. 

Si una nueva versión secundaria no incluye correcciones que beneficiarían a los clientes de Amazon RDS, es posible que decidamos no habilitarla en Amazon RDS. Poco después de que una nueva versión secundaria esté disponible en Amazon RDS, se establecerá como la versión secundaria preferida para las nuevas instancias de bases de datos. 

Para actualizar de forma manual una instancia de base de datos a una versión de motor compatible, utilice el comando “Modify DB Instance” (Modificar instancia de base de datos) en la consola de administración de AWS o la API ModifyDBInstance y establezca el parámetro “DB Engine Version” (Versión del motor de base de datos) en la versión deseada. De forma predeterminada, la actualización se aplicará durante el próximo periodo de mantenimiento. También puede actualizar la instancia inmediatamente si selecciona la opción “Apply Immediately” (Aplicar de inmediato) en la API de la consola.

Si determinamos que una nueva versión secundaria del motor incluye correcciones de errores significativas en comparación con una versión secundaria previa, se programarán actualizaciones automáticas para las instancias de bases de datos cuya configuración de Auto Minor Version Upgrade (Actualización automática de versiones secundarias) sea Yes (Sí). Estas actualizaciones se producirá durante el periodo de mantenimiento determinado por el cliente.

Programamos dichas actualizaciones para que pueda planificar en función de ellas, ya que se necesita tiempo de inactividad para actualizar una versión del motor de base de datos, incluso para instancias Multi-AZ. Para desactivar las actualizaciones automáticas de versiones secundarias, puede establecer la configuración de Auto Minor Version Upgrade (Actualización automática de versiones secundarias) en No (No).

En el caso de servidores RDS para Oracle y RDS para SQL, si la actualización a la siguiente versión secundaria requiere cambiar a una edición distinta, no programaremos actualizaciones automáticas, aunque se haya habilitado la configuración Auto Minor Version Upgrade (Actualización automática de versiones secundarias). Cuando se dé esta situación, se decidirá si tendrá lugar la actualización automática programada en cada caso particular.

Si existen riesgos para la compatibilidad al actualizar una versión principal, la actualización no se producirá automáticamente y deberá iniciarla personalmente, salvo si se descarta la versión principal en uso (véase más adelante). Para obtener más información sobre la actualización de una instancia de base de datos a una nueva versión del motor de base de datos, consulte la Guía del usuario de Amazon RDS.

Sí. Para probarla, cree una instantánea de base de datos para su instancia de base de datos existente, restaure la instancia a partir de la instantánea para crear una nueva instancia de base de datos y, a continuación, inicie una actualización de versión para la nueva instancia de base de datos. Podrá experimentar con seguridad en la copia actualizada de su instancia de base de datos antes de decidir si desea actualizar su instancia de base de datos original o no.

Si quiere obtener más información para restaurar una instantánea de base de datos, consulte la Guía del usuario de Amazon RDS.

• Nuestra intención es dar compatibilidad a las versiones principales (p. ej. MySQL 5.6 o PostgreSQL 9.6) durante, al menos, 3 años después de que sean compatibles por primera vez con Amazon RDS.
• Asimismo, nuestra intención es ofrecer compatibilidad con las versiones secundarias (p. ej. MySQL 5.6.37 o PostgreSQL 9.6.1) durante, al menos, 1 año después de que sean compatibles por primera vez con Amazon RDS.

De forma periódica, descartaremos versiones de un motor de base de datos, ya sean principales o secundarias. Las versiones principales están disponibles al menos hasta el final de la vida útil de la versión comunitaria correspondiente o hasta que la versión deje de recibir correcciones de software o actualizaciones de seguridad. En las versiones secundarias, se suele descartar una versión cuando se han corregido la mayoría de errores y de problemas de seguridad en una versión secundaria posterior.

Aunque nos esforzamos por cumplir con estas directrices, en algunos casos podemos descartar versiones mayores o menores específicas con antelación, como cuando existen problemas de seguridad. En el improbable caso de que se produzca la situación mencionada anteriormente, Amazon RDS actualizará automáticamente su motor de base de datos para resolver el problema. El calendario de actualizaciones puede variar según las circunstancias específicas y el tipo de problema que se esté resolviendo.

Cuando una versión secundaria de un motor de base de datos quede obsoleta en Amazon RDS, otorgaremos un periodo de tres (3) meses a partir del anuncio antes de comenzar las actualizaciones automáticas. Cuando finalice este periodo, todas las instancias que aún ejecuten la versión secundaria obsoleta se programarán para una actualización automática a la versión secundaria admitida más reciente durante sus periodos de mantenimiento programados.

Cuando una versión principal del motor de la base de datos quede obsoleta en Amazon RDS, ofreceremos un periodo mínimo de seis (6) meses tras el anuncio de una obsoleta para que pueda iniciar una actualización a una versión principal compatible. Al finalizar este período, se implementará una actualización automática a la próxima versión principal en todas las instancias que sigan ejecutando la versión obsoleta durante los períodos de mantenimiento programados.

En algunos casos, podemos dar de baja versiones principales o secundarias específicas sin previo aviso, como cuando notamos que una versión no cumple con nuestro estándar de alta calidad, rendimiento o seguridad. En el improbable caso de que esto ocurra, Amazon RDS suspenderá la creación de nuevas instancias de base de datos y clústeres con estas versiones. Los clientes existentes pueden continuar con la ejecución de sus bases de datos. El calendario de actualizaciones puede variar según las circunstancias específicas y el tipo de problema que se esté resolviendo.

Solo tiene que pagar por lo que use; no hay tarifas mínimas ni de configuración. Su facturación se calcula de la siguiente manera:

• Horas de instancia de base de datos: se basan en la clase (p. ej. db.t2.micro, db.m4.large) de la instancia de base de datos que haya utilizado. Las horas de instancia de base de datos parciales que se utilicen se facturan en incrementos de un segundo con un cargo mínimo de 10 minutos después de un cambio de estado facturable, como la creación, el inicio o la modificación de la clase de instancia de base de datos. Para obtener más detalles, lea nuestro anuncio de novedades.
• Almacenamiento (por GB al mes): capacidad de almacenamiento que haya aprovisionado en la instancia de base de datos. Si escala la capacidad de almacenamiento aprovisionada durante el mes, se incluirá en la factura el precio prorrateado correspondiente.
• Solicitudes de E/S al mes: cantidad total de solicitudes de E/S de almacenamiento que tiene (solo para el almacenamiento magnético de Amazon RDS y Amazon Aurora)
• IOPS aprovisionadas al mes: la tasa de IOPS aprovisionadas, independientemente de las IOPS que se consuman (solo para almacenamiento SSD de IOPS aprovisionadas de Amazon RDS).
• Almacenamiento de copias de seguridad: es el almacenamiento asociado con las copias de seguridad de bases de datos automatizadas y con cualquier instantánea de base de datos iniciada por el cliente. Al aumentar el periodo de retención de backup o realizar instantáneas de base de datos adicionales, aumenta el almacenamiento de backups que consume la base de datos.
• Transferencia de datos: transferencia de datos de Internet desde la instancia de base de datos y hacia ella.

Si desea obtener información sobre los precios de Amazon RDS, visite la sección de precios en la página del producto de Amazon RDS.

La facturación de una instancia de base de datos comienza en cuanto está disponible. La facturación continúa hasta que la instancia de la base de datos termina, lo que ocurriría al eliminarla o en caso de error de la instancia.

Las horas de instancia de base de datos se facturan por cada hora en que la instancia se ejecuta en estado de disponibilidad. Si no desea que se le siga cobrando una instancia de base de datos, debe detenerla o eliminarla para que no se facturen más horas de instancia. Las horas de instancia de base de datos parciales que se utilicen se facturan en incrementos de un segundo con un cargo mínimo de 10 minutos después de un cambio de estado facturable, como la creación, el inicio o la modificación de la clase de instancia de base de datos.

Mientras su instancia de base de datos esté detenida, se le cargará el almacenamiento aprovisionado (incluido Provisioned IOPS) y el almacenamiento de respaldo (incluidas las snapshots manuales y los backups automatizados en su ventana de retención específica), pero no se le cargarán las horas de instancia de base de datos.

Se proporciona almacenamiento de copia de seguridad gratis hasta el almacenamiento de base de datos total aprovisionado de su cuenta en toda la región. Por ejemplo, si tiene una instancia de base de datos MySQL con 100 GB de almacenamiento aprovisionado durante el mes y una instancia de base de datos PostgreSQL con 150 GB de almacenamiento aprovisionado durante el mes, ambas en la misma región y la misma cuenta, le proporcionaremos 250 GB de almacenamiento de copia de seguridad en esta cuenta y región sin cargo adicional. Solo se le cobrará por el almacenamiento de copias de seguridad que supere esta cantidad.

Cada día, el total de almacenamiento de base de datos aprovisionado de su cuenta en la región se compara con el total de almacenamiento de copia de seguridad en la región, y solo se cobra el exceso de almacenamiento de copia de seguridad. Por ejemplo, si tiene exactamente 10 GB de exceso de almacenamiento de copias de seguridad cada día, se le cobrarán 10 GB/mes de almacenamiento de copias de seguridad durante el mes. O bien, si tiene 300 GB de almacenamiento aprovisionado cada día, y 500 GB de almacenamiento de copia de seguridad cada día, pero solo durante la mitad del mes, entonces solo se le cobrarán 100 GB/mes de almacenamiento de copia de seguridad (no 200 GB/mes), ya que el cargo se calcula diariamente (prorrateado) y las copias de seguridad no existieron durante todo el mes. Tenga en cuenta que el almacenamiento de copia de seguridad gratis es específico de la cuenta y de la región.

El tamaño de sus copias de seguridad es directamente proporcional a la cantidad de datos de su instancia. Por ejemplo, si tiene una instancia de base de datos con 100 GB de almacenamiento aprovisionado, pero solo almacena 5 GB de datos en ella, su primera copia de seguridad solo será de aproximadamente 5 GB (no de 100 GB). Las copias de seguridad posteriores son incrementales y solo almacenarán los datos modificados en su instancia de base de datos. Tenga en cuenta que el tamaño de almacenamiento de la copia de seguridad no se muestra en la Consola de RDS ni en la respuesta de la API DescribeDBSnapshots.

El almacenamiento aprovisionado para los datos principales de su instancia de base de datos se ubica en una única zona de disponibilidad. Cuando se realiza una copia de seguridad de la base de datos, los datos de la copia de seguridad (incluidos los registros de transacción) se reproducen en múltiples zonas de disponibilidad a fin de proporcionar una durabilidad de datos aún mayor. El precio del almacenamiento de backup por encima de la asignación gratuita refleja esta replicación adicional, que maximiza la durabilidad de los backups críticos.

Si especifica que su instancia de base de datos debe ser un despliegue multi-AZ, se le facturará en función de los precios de multi-AZ publicados en la página de precios de Amazon RDS. La facturación de Multi-AZ depende de lo siguiente:

• Horas de instancia de bases de datos Multi-AZ: se basan en la clase (por ejemplo, db.t2.micro, db.m4.large) de la instancia de base de datos consumida. Del mismo modo que con implementaciones estándar en una zona de disponibilidad individual, las horas de instancia de base de datos parciales se facturan en incrementos de un segundo con un cargo mínimo de 10 minutos después de un cambio de estado facturable, como la creación, el inicio o la modificación de la clase de instancia de la base de datos. Si convierte su despliegue de instancia de base de datos entre estándar y Multi-AZ en un plazo inferior a una hora, se le cobrarán por dicha hora las dos tarifas aplicables.
• Almacenamiento aprovisionado (para instancias de base de datos Multi-AZ) – Si convierte su despliegue entre estándar y Multi-AZ en un plazo inferior a una hora, se le cobrará la mayor de las tarifas de almacenamiento aplicables por esa hora.
• Solicitudes de E/S al mes: el número total de solicitudes de E/S de almacenamiento que tenga. Las implementaciones Multi-AZ consumen más volumen de solicitudes de E/S que las implementaciones de instancias de bases de datos estándar, en función de la relación escritura/lectura de su base de datos. El uso de E/S de escritura asociado con las actualizaciones de la base de datos se duplica a medida que Amazon RDS replica de forma sincrónica sus datos en la instancia de base de datos en espera. El uso de E/S de lectura no sufre cambios.
• Almacenamiento de respaldo: el uso que realice del almacenamiento de respaldo no cambiará, ya sea que su instancia de base de datos sea una implementación estándar o Multi-AZ. Los backups se recuperarán de su instancia en espera para evitar la suspensión de E/S en la instancia de base de datos principal.
• Transferencia de datos – No se le cobrarán las transferencias de datos en las que incurra durante la replicación de datos entre la instancia principal y la instancia en espera. Las transferencia de datos de Internet, tanto interna como externa, de su instancia de base de datos tiene el mismo precio que un despliegue estándar.

Si no se especifica lo contrario, nuestros precios no incluyen los impuestos ni gravámenes correspondientes, como el IVA y cualquier otro impuesto sobre las ventas. Para los clientes con una dirección de facturación japonesa, el uso de los servicios de AWS está sujeto al impuesto sobre el consumo japonés. Obtenga más información.

Mediante la oferta del nivel gratuito de AWS para Amazon RDS se proporciona el uso gratuito de microinstancias de base de datos Single-AZ que ejecuten MySQL, MariaDB, PostgreSQL y SQL Server Express Edition. El nivel de uso gratuito ofrece hasta 750 horas de instancia al mes. Los clientes reciben 20 GB de almacenamiento de base de datos de uso general (SSD) y 20 GB de almacenamiento de backups sin cargo al mes.

Las nuevas cuentas de AWS reciben 12 meses de acceso al nivel gratuito de AWS. Consulte las preguntas frecuentes sobre el nivel gratuito de AWS para obtener más información.

Sí. Puede ejecutar más de una microinstancia de base de datos Single-AZ a la vez y optar por su uso en el marco del nivel gratuito de AWS para Amazon RDS. Sin embargo, se facturará según los precios estándar de Amazon RDS cualquier uso que supere las 750 horas de instancia, teniendo en cuenta todas las microinstancias de bases de datos Single-AZ de Amazon RDS y todos los motores de bases de datos y las regiones que correspondan.

Por ejemplo, si ejecuta dos microinstancias de bases de datos Single-AZ durante 400 horas cada una en un mismo mes, acumulará 800 horas de uso de las instancias, de las cuales 750 serán gratuitas. Se le cobrarán las 50 horas restantes conforme a la tarifa estándar de Amazon RDS.

No. Un cliente con acceso al nivel gratuito de AWS puede usar hasta 750 horas de instancia totales para micro instancias que ejecuten MySQL, PostgreSQL, o SQL Server Express Edition. Cualquier uso que supere las 750 horas de instancia, en todas las instancias de base de datos Single-AZ Micro de Amazon RDS y en todos los motores de bases de datos y regiones elegibles, se facturará a los precios estándar de Amazon RDS.

Cualquier hora de la instancia que exceda el límite de la capa gratuita se cobrará según la tarifa estándar de Amazon RDS. Consulte la página de precios de Amazon RDS para obtener más detalles.

Las instancias reservadas de Amazon RDS le ofrecen la opción de reservar una instancia de base de datos durante un periodo de uno o tres años y obtener a cambio un descuento significativo, en comparación con los precios de las instancias bajo demanda para la instancia de base de datos. Existen tres opciones de pago para las instancias reservadas (sin pago por adelantado, con pago parcial por adelantado o con pago total por adelantado) que le permiten equilibrar el importe del pago por adelantado con el precio por hora real.

En términos funcionales, las instancias reservadas y las instancias de bases de datos bajo demanda son exactamente iguales. La única diferencia es el método de facturación de las instancias de bases de datos. Con las instancias reservadas, adquiere una reserva de uno o tres años y, a cambio, recibe una tarifa efectiva de uso por hora más baja (en comparación con las instancias de base de datos bajo demanda) durante la duración del plazo. A menos que compre instancias reservadas en una región, todas las instancias de base de datos se facturarán de acuerdo con las tarifas por hora bajo demanda.

Puede comprar una instancia reservada en la sección “Reserved Instance” (Instancia reservada) de la consola de administración de AWS para Amazon RDS. Como alternativa, puede utilizar la API de Amazon RDS o la Interfaz de línea de comandos de AWS para enumerar las reservas disponibles para la compra y, a continuación, adquirir una reserva de instancia de base de datos.

Una vez que haya efectuado una compra de reserva, el uso de la instancia de base de datos reservada es lo mismo que usar una instancia de base de datos bajo demanda. Lance una instancia de base de datos con la misma clase de instancia, motor y región con los cuales hizo la reserva. Siempre y cuando la compra de la reserva esté activa, Amazon RDS aplicará a la nueva instancia de base de datos la tarifa por hora reducida a la que tenga derecho.

Las instancias reservadas de Amazon RDS se compran para una región en lugar de para una zona de disponibilidad específica. Como las instancias reservadas no son específicas de una zona de disponibilidad, no suponen reservas de capacidad. Eso significa que, aunque la capacidad esté limitada en una zona de disponibilidad, se pueden seguir comprando reservas en la región y se aplicará el descuento de acuerdo con el uso en cualquier zona de disponibilidad de esa región.

Puede comprar hasta 40 instancias de base de datos reservadas. Si desea ejecutar más de 40 instancias de base de datos, complete el formulario de solicitud de instancias de bases de datos de Amazon RDS.

Basta con que compre una reserva de instancia de base de datos con la misma clase de instancia y motor de base de datos, la misma opción Multi-AZ y el mismo modelo de licencia dentro de la misma región en la que se encuentra la instancia de base de datos que ejecuta actualmente y que desea reservar. Si compra la reserva correctamente, Amazon RDS aplica automáticamente el nuevo cargo por uso horario a la instancia de base de datos existente.

Los cambios de precio asociados con una instancia reservada se activan cuando la solicitud se recibe, mientras se procesa la autorización del pago. Puede seguir el estado de la reserva en la página AWS Account Activity (Actividad de la cuenta de AWS) o mediante la API DescribeReservedDBInstances o el comando describe-reserved-db-instances. Si el pago único no puede autorizarse correctamente antes del siguiente periodo de facturación, no se aplicará el precio con descuento.

Cuando vence el plazo de reserva, a la instancia reservada se le vuelve a aplicar la tarifa de uso por horas bajo demanda correspondiente a la clase y región de su instancia de base de datos.

Las operaciones de Amazon RDS para la creación, la modificación y la eliminación de instancias de bases de datos no distinguen entre instancias reservadas e instancias bajo demanda. A la hora de calcular su factura, nuestro sistema aplicará de forma automática sus reservas para que todas las instancias de base de datos que cumplan los requisitos se le cobren a la tarifa horaria reducida de las instancias de base de datos reservadas.

Cada reserva está asociada al siguiente conjunto de atributos: motor de base de datos, clase de instancia de base de datos, opción de implementación Multi-AZ, modelo de licencia y región.

Una reserva para un motor de base de datos y un modelo de licencia elegible para la flexibilidad de tamaño (MySQL, MariaDB, PostgreSQL, Amazon Aurora o “Bring Your Own License” [BYOL] de Oracle) se aplicarán automáticamente a una instancia de base de datos en ejecución de cualquier tamaño dentro de la misma familia de instancias (por ejemplo, M4, T2 o R3) para la misma región y el mismo motor de base de datos. Además, la reserva también se aplicará a instancias de bases de datos en ejecución en opciones de despliegue multi-AZ o single-AZ.

Por ejemplo, supongamos que compró una reserva de MySQL de una instancia db.m4.2xlarge. Si decide aumentar el tamaño de la instancia de base de datos en ejecución a una instancia db.m4.4xlarge, la tarifa con descuento de esta instancia reservada cubrirá la mitad del uso de la instancia de base de datos mayor.

Si está ejecutando un modelo de licencia o motor de base de datos que no sea elegible para la flexibilidad de tamaño (“licencia incluida” de Oracle o Microsoft SQL Server), cada reserva solo puede aplicarse a una instancia de base de datos con los mismos atributos durante la duración del plazo. Si decide modificar cualquiera de estos atributos de la instancia de base de datos en ejecución antes de que finalice el plazo de reserva, las tarifas de uso por hora para dicha instancia volverán a las tarifas por hora bajo demanda.

Para obtener más detalles sobre la flexibilidad de tamaño, consulte la Guía del usuario de Amazon RDS.

Cada instancia reservada está asociada a una región concreta, que es fija durante el período que dura la reserva y no puede modificarse. No obstante, las reservas pueden utilizarse en cualquiera de las zonas de disponibilidad disponibles dentro de la región asociada.

Sí. Al momento de la compra de una instancia reservada, se puede seleccionar la opción Multi-AZ en la configuración de la instancia de base de datos que se encuentra disponible para la venta. Además, si utiliza un motor de base de datos y un modelo de licencia compatible con la flexibilidad de tamaño de la instancia reservada, una instancia reservada multi-AZ cubrirá el uso de dos instancias de bases de datos Single-AZ.

Una reserva de instancia de base de datos puede aplicarse a una réplica de lectura, siempre que la clase de la instancia y la región sean las mismas. A la hora de calcular su factura, nuestro sistema aplicará de forma automática sus reservas para que todas las instancias de base de datos que cumplan los requisitos se le cobren según la tarifa horaria reducida de las instancias reservadas.

No, no puede cancelar la instancia de base de datos reservada y el pago único (si procede) tampoco es reembolsable. Seguirá pagando por cada hora durante el peridoo del acuerdo para las instancias de base de datos reservadas, independientemente del uso que haga.

Cuando adquiere una instancia reservada con la opción Pago inicial total, el plazo completo de la instancia reservada se abona en un solo pago inicial. Elija la opción Sin pago inicial si no desea realizar ningún pago inicial. El valor total de la instancia reservada sin pago inicial se distribuye en cada hora del período de vigencia y se le facturará por cada hora durante todo el plazo de la instancia reservada, independientemente del uso. La opción Pago inicial parcial es una combinación de las opciones Pago inicial total y Sin pago inicial. Se efectúa un pequeño pago inicial y se le facturará una tarifa por hora baja por cada hora durante todo el plazo, independientemente del uso.

Para seleccionar la clase de instancia de base de datos y la capacidad de almacenamiento iniciales, debe evaluar las necesidades de cómputo, memoria y almacenamiento de la aplicación. Para obtener información sobre las clases de instancias de bases de datos disponibles, consulte la Guía del usuario de Amazon RDS.

Puede escalar los recursos de cómputo y la capacidad de almacenamiento asignados a su instancia de base de datos con la Consola de administración de AWS (para ello, seleccione la instancia de base de datos deseada y haga clic en el botón Modify [Modificar]), la API de Amazon RDS o la Interfaz de línea de comandos de AWS. Los recursos de memoria y CPU se modifican cuando se cambia la clase de instancia de base de datos y el almacenamiento disponible cambia cuando modifica su asignación de almacenamiento. 

Tenga en cuenta que, cuando modifica su clase de instancia de base de datos o el almacenamiento asignado, los cambios solicitados se aplicarán durante el período de mantenimiento que especifique. También puede utilizar el marcador "apply-immediately" para aplicar sus solicitudes de escalado de forma inmediata. Tenga en cuenta que también se aplicarán los demás cambios pendientes en el sistema.

Es posible que algunas instancias de RDS for SQL Server más antiguas no sean válidas para el almacenamiento escalado. Para obtener más información, consulte las preguntas frecuentes sobre RDS para SQL Server.

Amazon RDS utiliza volúmenes de EBS para almacenar el registro y la base de datos. En función del tamaño del almacenamiento solicitado, Amazon RDS se distribuye automáticamente en varios volúmenes de EBS para mejorar el rendimiento de IOPS. En el caso de MySQL y Oracle en una instancia de base de datos existente, podría observar mejoras en la capacidad de E/S si escala verticalmente la capacidad de almacenamiento. Puede escalar la capacidad de almacenamiento asignada a la instancia de base de datos mediante la Consola de administración de AWS, la API ModifyDBInstance o el comando modify-db-instance.

Para obtener más información, consulte Almacenamiento para Amazon RDS.

La capacidad de almacenamiento asignada a su instancia de base de datos puede aumentarse sin afectar la disponibilidad de la instancia de base de datos. Sin embargo, cuando decida escalar o reducir los recursos de cómputo disponibles en la instancia de base de datos, la base de datos dejará de estar disponible temporalmente mientras se modifica la clase de la instancia. Este periodo de disponibilidad suele durar solo unos minutos y tendrá lugar durante el periodo de mantenimiento de la instancia de base de datos, a menos que especifique que la modificación debe aplicarse de forma inmediata.

Amazon RDS admite diversas clases de instancia de base de datos y asignaciones de almacenamiento para admitir diferentes necesidades de aplicaciones. Si su aplicación necesita más recursos de computación que la clase de instancia de base de datos más grande, o más almacenamiento que la asignación máxima, puede implementar la función de particionado, para dispersar de este modo sus datos entre varias instancias de base de datos.

El almacenamiento de uso general (SSD) de Amazon RDS está indicado para una amplia gama de cargas de trabajo de bases de datos que tienen requisitos de E/S moderados. Con una línea de base de 3 IOPS/GB y capacidad para cargas de trabajo variables de hasta 3 ​000 IOPS, esta opción de almacenamiento ofrece un desempeño predecible para satisfacer las necesidades de la mayoría de las aplicaciones.

La opción de almacenamiento de IOPS aprovisionadas (SSD) con respaldo SSD de Amazon RDS está diseñada para proporcionar un rendimiento de E/S rápido, predecible y constante. Con el almacenamiento de IOPS aprovisionadas (SSD) de Amazon RDS, especifica una tasa de IOPS en el momento de crear una instancia de base de datos y Amazon RDS aprovisiona dicha tasa durante toda la vigencia de la instancia de base de datos. El almacenamiento de IOPS aprovisionadas (SSD) de Amazon RDS está optimizado para cargas de trabajo de base de datos transaccionales (OLTP) y con un uso intensivo de E/S. Para obtener más detalles, consulte la Guía del usuario de Amazon RDS.

El almacenamiento magnético de Amazon RDS resulta útil para cargas de trabajo de base de datos pequeñas a las que se obtiene acceso con menor frecuencia. El almacenamiento magnético no se recomienda para instancias de bases de datos de producción.

Elija el tipo de almacenamiento que mejor se ajuste a su carga de trabajo.

• Cargas de trabajo de OLTP de alto rendimiento: almacenamiento de IOPS aprovisionadas (SSD) de Amazon RDS
• Cargas de trabajo de base de datos con requisitos de E/S moderados: Almacenamiento de uso general (SSD) de Amazon RDS

La cantidad de IOPS que Amazon RDS admite varía conforme al motor de base de datos. Para obtener más detalles, consulte la Guía del usuario de Amazon RDS.

Amazon RDS ofrece dos métodos diferentes para respaldar y restaurar sus instancias de bases de datos: copias de seguridad automáticas e instantáneas de bases de datos.

La característica de copias de seguridad automatizadas de Amazon RDS permite la recuperación a un momento dado de su instancia de base de datos. Cuando las copias de seguridad automáticas están activadas en su instancia de base de datos, Amazon RDS realiza automáticamente una instantánea diaria completa de sus datos (durante el periodo de respaldo que prefiera) y captura registros de transacción (a medida que se realizan actualizaciones de su instancia de base de datos). Cuando inicia una recuperación a un momento dado, los registros de transacción se aplican a la copia de seguridad diaria más adecuada para restaurar su instancia de base de datos al momento que solicitó. 

Amazon RDS conserva copias de seguridad de una instancia de base de datos durante un tiempo limitado y especificado por el usuario, que recibe el nombre de período de retención, que de manera predeterminada es de 7 días pero se puede definir en hasta 35 días. Puede iniciar el restablecimiento a un momento dado y especificar cualquier segundo durante su período de retención, hasta el tiempo restaurable más reciente. Puede utilizar la API DescribeDBInstances para obtener el tiempo restaurable más reciente de la instancia de base de datos, que suele ser de cinco minutos. 

Como alternativa, puede encontrar la “Última hora de restauración” de una instancia de base de datos al seleccionarla en la consola de administración de AWS y buscar en la pestaña “Description” (Descripción) del panel inferior de la consola.

Las instantáneas de bases de datos las inicia un usuario, que puede hacer una copia de seguridad de la instancia de base de datos en un estado conocido, con la frecuencia que desee, para posteriormente restablecerlas al estado especificado en cualquier momento. Las instantáneas de base de datos pueden crearse con la consola de administración de AWS, la API CreateDBSnapshot o el comando create-db-snapshot y se conservan hasta que las elimine explícitamente.

Puede copiar las instantáneas que hace Amazon RDS para habilitar las copias de seguridad automáticas (con la Consola de AWS o el comando copy-db-snapshot), o bien para que pueda utilizar la funcionalidad de restablecimiento de instantáneas. Puede identificarlas con el tipo de instantánea "automated" (automática). Además, puede identificar la hora a la que se realizó la instantánea si consulta el campo "Snapshot Created Time" (Momento de creación de la instantánea). 

Del mismo modo, el identificador de los snapshots "automatizados" también contiene la hora (en UTC) a la que se ha capturado el snapshot.

Tenga en cuenta que, cuando realiza una operación de restablecimiento a un momento dado o desde una instantánea de base de datos, se crea una nueva instancia de base de datos con un nuevo punto de enlace (la antigua instancia de base de datos puede eliminarse si así lo desea). Esto permite crear varias instancias de base de datos a partir de una instantánea de base de datos o de un momento dado.

De forma predeterminada, Amazon RDS permite las copias de seguridad automáticas de su instancia de base de datos con un período de retención de 7 días. Si desea modificar el período de retención de la copia de seguridad, puede hacerlo mediante la Consola de RDS, la API CreateDBInstance (al crear una nueva instancia de base de datos) o la API ModifyDBInstance (para las instancias existentes). Puede usar estos métodos para cambiar el parámetro RetentionPeriod a cualquier número a partir de 0 (que desactivará las copias de seguridad automáticas) a la cantidad de días que desee, hasta 35. El valor no puede establecerse en 0 si la instancia de base de datos es una fuente de réplicas de lectura. Para obtener más información sobre las copias de seguridad automáticas, consulte la Guía del usuario de Amazon RDS.

El período de respaldo preferido es el período definido por el usuario durante el que se realiza el respaldo de su instancia de base de datos. Amazon RDS utiliza estos respaldos periódicos de los datos y sus registros de transacción para permitirle restablecer la instancia de base de datos a cualquier instante del período de retención, hasta el LatestRestorableTime (normalmente hasta los últimos minutos). Durante el período de respaldo, la E/S de almacenamiento podría interrumpirse durante unos instantes mientras se inicia el proceso de respaldo (por lo general, menos de segundos). También podría experimentar un breve período con incremento de la latencia. No hay periodo de interrupción de la E/S en el caso de implementaciones de bases de datos Multi-AZ, ya que la backup se realiza de la copia en reposo.

Las instantáneas de bases de datos de Amazon RDS y las copias de seguridad automáticas se almacenan en S3.

Puede utilizar la consola de administración de AWS, la API ModifyDBInstance o el comando modify-db-instance para administrar el periodo de tiempo en que se conservan sus copias de seguridad automatizadas al modificar el parámetro RetentionPeriod. Si desea desactivar de forma conjunta las copias de seguridad automatizadas, puede definir el período de retención en 0 (no se recomienda). Puede administrar las instantáneas de bases de datos creadas por el usuario mediante la sección “Snapshots” (Instantáneas) de la consola de Amazon RDS. Si lo desea, también puede ver una lista de instantáneas de bases de datos creadas por el usuario de una instancia de base de datos determinada mediante la API DescribeDBSnapshots o el comando describe-db-snapshots y eliminar instantáneas con la API DeleteDBSnapshot o el comando delete-db-snapshot.

Es normal tener una o dos instantáneas de bases de datos automáticas más que el número de días del período de retención. Se retiene una instantánea automática adicional con el objetivo de garantizar la capacidad para realizar una restauración a un punto en el tiempo a cualquier momento del período de retención.

Por ejemplo, si su periodo de copia de seguridad se establece en un día, necesitará dos instantáneas automatizadas para poder restaurar cualquiera de las últimas 24 horas. También es posible que vea una instantánea automática adicional porque se crea una nueva instantánea automática antes de eliminar la instantánea automática de mayor antigüedad.

Al eliminar una instancia de base de datos, puede crear una instantánea de base de datos definitiva cuando realice la eliminación; si lo hace, puede utilizar dicha instantánea para restaurar en otro momento la instancia de base de datos eliminada. Amazon RDS conserva la 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. Consulte la página de precios para obtener información detallada sobre los costos de almacenamiento de copias de seguridad.

Al eliminar una instancia de base de datos, puede conservar las copias de seguridad automatizadas hasta que se cumpla el periodo de retención de las copias de seguridad. Para más información, consulte Conservar copias de seguridad automatizadas.

Amazon VPC le permite crear un entorno de red virtual en una sección privada y aislada de la nube de AWS en la que puede ejercer un control total sobre aspectos como los rangos de direcciones IP privadas, las subredes, las tablas de enrutamiento y las puertas de enlace de red. Con Amazon VPC, puede definir una topología de red virtual y personalizar la configuración de la red para que se parezca a una red IP tradicional que podría operar en su propio centro de datos.

Una manera en la que puede aprovechar VPC es cuando desea ejecutar una aplicación web orientada al público, a la vez que mantiene servidores de backend no accesibles públicamente en una subred privada. Puede crear una subred pública que tenga acceso a Internet para los servidores web y colocar sus instancias de bases de datos de backend de Amazon RDS en una subred privada sin acceso a Internet. Para obtener más información sobre Amazon VPC, consulte la Guía del usuario de Amazon Virtual Private Cloud.

Si su cuenta de AWS se creó antes del 4 de diciembre de 2013, es posible que pueda ejecutar Amazon RDS en un entorno Amazon Elastic Compute Cloud (EC2)-Classic. La funcionalidad básica de Amazon RDS es la misma, independientemente de que se utilice EC2-Classic o EC2-VPC. Amazon RDS administra las copias de seguridad, la realización de revisiones del software, la detección automática de errores, las réplicas de lectura y la recuperación, independientemente de que las instancias de bases de datos se hayan implementado dentro o fuera de una VPC. Para obtener más información sobre las diferencias entre EC2-Classic y EC2-VPC, consulte la documentación de EC2.

Un grupo de subredes de bases de datos es un conjunto de subredes que usted puede designar para las instancias de bases de datos de Amazon RDS en una VPC. Cada grupo de subredes de bases de datos debe tener al menos una subred para cada zona de disponibilidad en una región determinada. Al crear una instancia de base de datos en una VPC, tendrá que seleccionar un grupo de subred de base de datos. A continuación, Amazon RDS utilizará dicho grupo y su zona de disponibilidad preferida para seleccionar una subred y una dirección IP dentro de dicha subred. Amazon RDS crea y asocia una interfaz de red elástica a su instancia de base de datos con dicha dirección IP.

Tenga en cuenta que se recomienda utilizar el nombre de DNS para conectarse a la instancia de base de datos, ya que la dirección IP subyacente puede cambiar (por ejemplo, durante una conmutación por error).

Para los despliegues multi-AZ, definir una subred para todas las zonas de disponibilidad en una región permite a Amazon RDS crear una nueva instancia en espera en otra zona de disponibilidad, en caso de que surja la necesidad. Hacer esto es necesario incluso para los despliegues Single-AZ, en caso de que desee convertirlos en despliegues Multi-AZ en algún punto.

Para ver un procedimiento que lo guíe a lo largo del proceso, consulte Creación de una instancia de base de datos en una VPC en la Guía del usuario de Amazon RDS.

Visite la sección sobre grupos de seguridad de la Guía del usuario de Amazon RDS para obtener información sobre las diferentes maneras en que se puede controlar el acceso a sus instancias de bases de datos.

Se puede obtener acceso a las instancias de bases de datos dentro de una VPC mediante las instancias de EC2 implementadas en la misma VPC. Si estas instancias EC2 se implementan en una subred pública con direcciones IP elásticas asociadas, puede obtener acceso a las instancias EC2 a través de Internet. Es posible acceder a las instancias de bases de datos desplegadas en una VPC desde Internet o desde las instancias de EC2 que se encuentran afuera de la VPC a través de una VPN o de un host bastión que se pueden lanzar en una subred pública o mediante la opción de acceso público de Amazon RDS:

• Para usar un host bastión, tiene que configurar una subred pública con una instancia de EC2 que actúa como bastión SSH. Esta subred pública debe tener una puerta de enlace de Internet y reglas de enrutamiento que permitan que el tráfico se dirija a través del host SSH, que debe luego reenviar las solicitudes a la dirección IP privada de su instancia de base de datos de Amazon RDS.
• Para utilizar la conectividad pública, solo tiene que crear las instancias de bases de datos con la opción de acceso público habilitada. Con la opción de acceso público habilitada, será posible obtener acceso sin restricciones a las instancias de base de datos de una VPC desde fuera de la VPC de manera predeterminada. Esto significa que no es necesario configurar una VPN o un host de protección para permitir el acceso a las instancias.

También puede configurar una puerta de enlace de VPN que extienda su red corporativa a su VPC y que permita el acceso a la instancia de base de datos de Amazon RDS en dicha VPC. Consulte la Guía del usuario de Amazon VPC para obtener más detalles.

Recomendamos encarecidamente que use el nombre DNS para conectarse a la instancia de base de datos, ya que la dirección IP subyacente puede cambiar (por ejemplo, durante una conmutación por error).

Si su instancia de base de datos no es una VPC, puede usar la consola de administración de AWS para trasladar su instancia de base de datos a una VPC con facilidad. Para obtener más detalles, consulte la Guía del usuario de Amazon RDS. También puede realizar una instantánea de la instancia de base de datos fuera de la VPC y restablecerla en la VPC si especifica el grupo de subred de base de datos que desea utilizar. Otra opción es realizar también una operación "Restore to Point in Time".

No se admite la migración directa de instancias de bases de datos desde adentro hacia fuera de la VPC. Por cuestiones de seguridad, una instantánea de base de datos de una instancia de base de datos dentro de una VPC no se puede restablecer fuera de la VPC. Sucede lo mismo con la funcionalidad "Restore to Point in Time". 

Usted se encarga de modificar las tablas de enrutamiento y las ACL de redes en la VPC para asegurarse de que se pueda acceder a las instancias de bases de datos desde sus instancias cliente en la VPC. Para los despliegues multi-AZ, después de una conmutación por error, la instancia de EC2 cliente y la instancia de base de datos de Amazon RDS pueden estar en diferentes zonas de disponibilidad. Debe configurar las ACL de redes para garantizar que sea posible la comunicación entre las zonas de disponibilidad.

Se puede actualizar un grupo de subredes de base de datos existente para agregar más subredes para las zonas de disponibilidad existentes o para nuevas zonas de disponibilidad agregadas desde la creación de la instancia de base de datos. La eliminación de subredes de un grupo de subred de base de datos puede provocar que las instancias no estén disponibles si se están ejecutando en una zona de disponibilidad en particular que se elimina del grupo de subredes. Consulte la Guía del usuario de Amazon RDS para obtener más información.

Para empezar a utilizar Amazon RDS, necesitará una cuenta de desarrollador de AWS. Si no cuenta con una antes de registrarse en Amazon RDS, se le pedirá que cree una cuando comience el proceso de registro. La cuenta de usuario principal es diferente de la cuenta de desarrollador de AWS y se utiliza solo en el contexto de Amazon RDS para controlar el acceso a sus instancias de bases de datos. La cuenta de usuario principal es una cuenta de usuario de base de datos nativa que puede utilizar para conectarse a su instancia de base de datos. 

Cuando cree la instancia de base de datos, puede especificar el nombre del usuario principal y la contraseña que desea asociarle. Una vez que haya creado su instancia de base de datos, podrá conectarse a la base de datos mediante las credenciales del usuario principal. Es posible que posteriormente desee crear cuentas de usuario adicionales, de forma que pueda restringir quién obtiene acceso a su instancia de base de datos.

Para MySQL, los privilegios predeterminados del usuario principal son los siguientes: create, drop, references, event, alter, delete, index, insert, select, update, create temporary tables, lock tables, trigger, create view, show view, alter routine, create routine, execute, trigger, create user, process, show databases, grant option.

Para Oracle, al usuario principal se le otorga el rol “dba”. El usuario principal hereda la mayoría de los privilegios asociados al rol. Consulte la Guía del usuario de Amazon RDS para obtener la lista de privilegios restringidos y las alternativas correspondientes para llevar a cabo tareas administrativas que puedan requerir estos privilegios.

Para SQL Server, a un usuario que crea una base de datos se le otorga la función "db_owner". Consulte la Guía del usuario de Amazon RDS para obtener la lista de privilegios restringidos y las alternativas correspondientes para llevar a cabo tareas administrativas que puedan requerir estos privilegios.

No, todo funciona de la misma forma a la que está acostumbrado al utilizar una base de datos relacional que usted mismo administra.

Sí. Debe activar la capacidad para obtener acceso a su base de datos a través de Internet mediante la configuración de grupos de seguridad. Puede autorizar el acceso únicamente a las direcciones IP, los intervalos de direcciones IP o las subredes de los servidores de su propio centro de datos.

Sí, esta opción es compatible con todos los motores de Amazon RDS. Amazon RDS genera un certificado SSL/TLS para cada instancia de base de datos. En cuanto se establece una conexión cifrada, los datos transferidos entre la Instancia de base de datos y su aplicación se cifrarán durante el proceso de transferencia.

Aunque SSL ofrece beneficios de seguridad, debe ser consciente de que el cifrado SSL/TLS es una operación que realiza un uso intensivo de la infraestructura informática y que, por lo tanto, aumentará la latencia de su conexión a la base de datos. Debe tener en cuenta que la compatibilidad con SSL/TLS de Amazon RDS se restringe al cifrado de la conexión entre la aplicación y la instancia de base de datos. No se debe depender de ella para la autenticación de la propia instancia de base de datos.

Para obtener detalles sobre el establecimiento de una conexión cifrada con Amazon RDS, consulte la Guía del usuario de MySQL de Amazon RDS, la Guía del usuario de MariaDB, la Guía del usuario de PostgreSQL o la Guía del usuario de Oracle. Para obtener más información sobre cómo funciona SSL/TLS con estos motores, consulte directamente la documentación de MySQL, MariaDB, MSDN SQL Server, PostgreSQL u Oracle.

Amazon RDS es compatible con el cifrado en reposo para todos los motores de bases de datos mediante el uso de claves que usted administre con AWS Key Management Service (KMS). En una instancia de base de datos que se ejecute con cifrado de Amazon RDS, los datos almacenados en reposo en el almacenamiento subyacente están cifrados, al igual que sus backups automatizados, las réplicas de lectura y los snapshots. El cifrado y el descifrado se administran de forma transparente. Para obtener más información sobre el uso de KMS con Amazon RDS, consulte la Guía del usuario de Amazon RDS.

También puede añadir cifrado a una instancia o clúster de base de datos descifrado con anterioridad mediante la creación de una instantánea de base de datos y, a continuación, una copia de esa instantánea, para posteriormente especificar una clave de cifrado de KMS. Después, puede restaurar una instancia de base de datos o clúster de base de datos cifrados a partir de la instantánea cifrada.

Amazon RDS para Oracle y SQL Server admiten las tecnologías de cifrado de datos transparente (TDE) de esos motores. Para obtener más información, consulte las secciones de la Guía del usuario de Amazon RDS sobre Oracle y SQL Server.

Puede controlar las acciones que los usuarios y los grupos de AWS IAM pueden ejecutar en los recursos de Amazon RDS. Para ello, consulte los recursos de Amazon RDS en las políticas de IAM de AWS que aplica a los usuarios y los grupos. Los recursos de Amazon RDS a los que se puede hacer referencia en una política de IAM de AWS incluyen instancias de base de datos, instantáneas de base de datos, réplicas de lectura, grupos de seguridad de base de datos, grupos de opciones de base de datos, grupos de parámetros de base de datos, suscripciones a eventos y grupos de subred de base de datos. 

Además, puede etiquetar tales recursos para agregarles más metadatos. Mediante el uso de etiquetas, puede categorizar sus recursos (por ejemplo, instancias de base de datos de “Desarrollo”, “Producción” o “Prueba”), así como escribir políticas de AWS IAM en las que consten los permisos (es decir, las acciones) que se pueden adoptar en los recursos con las mismas etiquetas. Para obtener más información, consulte Etiquetado de recursos de Amazon RDS.

Sí. AWS CloudTrail es un servicio web que registra las llamadas a la API de AWS de su cuenta y le entrega registros. El historial de llamadas a las API de AWS creado por CloudTrail permite realizar un análisis de seguridad, un seguimiento de los cambios en los recursos y auditorías sobre la conformidad. 

Sí, todos los motores de bases de datos de Amazon RDS cumplen con los requisitos de la HIPAA, por lo que puede utilizarlos para crear aplicaciones conformes con HIPAA y almacenar información relacionada con la atención sanitaria, incluida la información sanitaria protegida (PHI), en virtud de un acuerdo de asociación empresarial (BAA) firmado con AWS.

Si ya cuenta con un BAA, no es necesario realizar ninguna acción para empezar a utilizar los servicios en las cuentas cubiertas por dicho contrato. Si no cuenta con un BAA vigente con AWS, o si tiene preguntas acerca de las aplicaciones que cumplen con HIPAA en AWS, contacte con nosotros.

Por defecto, Amazon RDS elige los parámetros de configuración óptimos para su instancia de base de datos. Para ello, tiene en cuenta la clase de instancia y la capacidad de almacenamiento. Sin embargo, si lo desea, puede cambiarlos mediante la consola de administración de AWS, las API de Amazon RDS o la interfaz de línea de comandos de AWS. Recuerde que modificar los parámetros de configuración recomendados puede tener efectos no deseados, como la reducción del rendimiento y bloqueos del sistema, y solo los usuarios avanzados que deseen asumir estos riesgos podrán hacerlo.

Un grupo de parámetros de bases de datos realiza las funciones de "contenedor" de valores de configuración del motor que pueden aplicarse a una o más instancias de bases de datos. Si crea una instancia de base de datos sin especificar un Grupo de parámetros de bases de datos, se utilizará un grupo de parámetros predeterminado. Este grupo predeterminado contiene valores predeterminados del motor y del sistema Amazon RDS que están optimizados para la instancia de base de datos que está ejecutando.

Sin embargo, si desea que su instancia de base de datos funcione con valores de configuración de motor personalizados, basta con que cree un nuevo Grupo de parámetros de bases de datos, modifique los parámetros que desee y modifique la instancia de base de datos para que utilice el nuevo Grupo de parámetros de bases de datos. Una vez asociadas, todas las instancias de base de datos que utilicen un Grupo de parámetros de base de datos determinado obtendrán todas las actualizaciones de parámetro correspondientes a dicho Grupo de parámetros de base de datos.

Si desea obtener más información sobre la configuración de grupos de parámetros de bases de datos, consulte la Guía del usuario de Amazon RDS.

Puede usar AWS Config para registrar continuamente los cambios de configuración de las instancias de base de datos de Amazon RDS, los grupos de subred de la base de datos, las instantáneas de la base de datos, los grupos de seguridad de la base de datos y las suscripciones a eventos, y recibir notificaciones de los cambios a través de Amazon Simple Notification Service (SNS). También puede crear reglas de AWS Config para evaluar si estos recursos de Amazon RDS tienen las configuraciones deseadas.

Cuando cree su instancia de la base de datos para que se ejecute como un despliegue multi-AZ o la modifique con ese fin, Amazon RDS aprovisionará de forma automática una réplica “en espera” sincrónica dentro de una zona de disponibilidad diferente y la administrará. Las actualizaciones de su instancia de base de datos se replican de forma sincrónica en las zonas de disponibilidad en espera, con el fin de mantener ambas bases de datos sincronizadas y proteger las actualizaciones más recientes de su base de datos de errores de la instancia. 

Durante determinados tipos de mantenimiento planificado, o en el improbable caso de que se produzca un error en la instancia de base de datos o la zona de disponibilidad, Amazon RDS conmutará por error automáticamente a la instancia en espera para que pueda reanudar las escrituras y lecturas en la base de datos en cuanto se comience a usar la instancia en espera. Dado que el registro de nombre de su instancia de base de datos no se verá modificado, su aplicación podrá reanudar la operación de la base de datos sin necesidad de intervención administrativa manual. Además, en las implementaciones Multi-AZ, la replicación es transparente. No se interactúa directamente con la instancia en espera, y esta no puede utilizarse para atender tráfico de lectura. Puede obtener más información sobre los despliegues multi-AZ en la Guía del usuario de Amazon RDS.

Las zonas de disponibilidad son ubicaciones concretas dentro de una región que están diseñadas para estar aisladas de errores que se produzcan en otras zonas de disponibilidad. Cada zona de disponibilidad se ejecuta en su propia infraestructura, independiente y físicamente distinta, y está diseñada para ofrecer un nivel de fiabilidad alto. Los puntos comunes de error, como los generadores y el equipo de enfriamiento, no se comparten entre zonas de disponibilidad. Además, se encuentran en ubicaciones físicas diferentes, de forma que, incluso los desastres extremadamente poco frecuentes, como incendios, tornados o inundaciones, solo afecten a una sola zona de disponibilidad. Las zonas de disponibilidad que se encuentran dentro de la misma región disfrutan de conectividad a red de baja latencia.

Cuando ejecuta una instancia de base de datos como una implementación Multi-AZ, la instancia "principal" atiende las escrituras y lecturas de la base de datos. Además, Amazon RDS aprovisiona y mantiene una instancia "en espera" en segundo plano, que es una réplica actualizada de la instancia principal. En situaciones de conmutación por error, la instancia en espera se transforma en principal. Tras la conmutación por error, la réplica en espera pasa a ser la principal y acepta las operaciones de base de datos. Usted no interactuará directamente con la instancia en espera (por ejemplo, para operaciones de lectura) antes de que se transforme en principal. Si le interesa escalar el tráfico de lectura más allá de las limitaciones de capacidad de una sola instancia de base de datos, consulte las preguntas frecuentes sobre las réplicas de lectura.

Los principales beneficios de ejecutar su instancia de base de datos como una implementación Multi-AZ son la mejora de la durabilidad y la disponibilidad de la base de datos. La mayor disponibilidad y la tolerancia a errores que ofrecen los despliegues Multi-AZ los convierten en una opción ideal para los entornos de producción.
 

La ejecución de su instancia de base de datos como una implementación Multi-AZ protege sus datos en el improbable caso de que se produzca un error en un componente de la instancia de base de datos o una pérdida de disponibilidad en una zona de disponibilidad. Por ejemplo, si uno de los volúmenes de almacenamiento de su instancia principal falla, Amazon RDS inicia automáticamente un proceso de conmutación por error hacia la instancia en espera, en la que todas las actualizaciones de la base de datos están intactas. Esta función proporciona durabilidad de datos adicional respecto a las implementaciones estándar de una única zona de disponibilidad. Se necesitaría una operación de restauración iniciada por el usuario y no estarían disponibles las actualizaciones producidas tras el tiempo restaurable más reciente (normalmente dentro de los últimos cinco minutos).

También se beneficia de un mayor nivel de disponibilidad de la base de datos cuando ejecuta su instancia de base de datos como una implementación Multi-AZ. Si se produce un error en la zona de disponibilidad o falla una instancia de base de datos, la repercusión en la disponibilidad estará limitada al tiempo que tarda en completarse la conmutación por error automática. Los beneficios de disponibilidad de Multi-AZ también se trasladan a las tareas de mantenimiento planificadas.

Por ejemplo, con las copias de seguridad automáticas, la actividad de E/S ya no se suspende en su instancia principal durante el periodo de respaldo preferido, dado que las copias de seguridad se recuperan a partir de la instancia en espera. En el caso de la realización de revisiones o del escalado de la clase de instancia de base de datos, estas operaciones tienen lugar primero en la instancia en espera, antes de realizar la conmutación por error automática. De esta forma, el impacto de disponibilidad se ve limitado al tiempo necesario para que se complete la conmutación por error.

Otro de los beneficios implícitos de la ejecución de su instancia de base de datos como una implementación Multi-AZ es que la conmutación por error de la instancia de base de datos es automática y no necesita ningún tipo de administración. En un contexto de Amazon RDS, esto supone que no tendrá que supervisar los eventos de la instancia de base de datos ni iniciar la recuperación manual de la instancia de base de datos (a través de las API “RestoreDBInstanceToPointInTime” o “RestoreDBInstanceFromSnapshot”) en caso de que se produzca un error de una zona de disponibilidad o de una instancia de base de datos.

Es posible que observe latencias elevadas en relación con los despliegues de instancias de base de datos estándar en una zona de disponibilidad única, como consecuencia de la replicación de datos sincrónica que se realiza por usted.

No, una instancia de espera Multi-AZ no puede atender solicitudes de lectura. Las implementaciones Multi-AZ están diseñadas para ofrecer mayores niveles de disponibilidad y durabilidad de la base de datos, en lugar de beneficios de escalado de lectura. Por ello, la función utiliza replicación sincrónica entre la versión principal y la versión en espera. Nuestra implementación garantiza que la versión principal y la versión en espera estén constantemente sincronizadas, pero impide utilizar la versión en espera para operaciones de lectura o escritura. Si le interesa una solución de escalamiento de lectura, consulte las preguntas frecuentes sobre réplicas de lectura.

Para crear un despliegue de instancia de base de datos multi-AZ, solo tiene que hacer clic en la opción “Yes” (Sí) de “Multi-AZ Deployment” (Despliegue multi-AZ) al lanzar una instancia de base de datos con la Consola de administración de AWS.

Si utiliza las API de Amazon RDS, también puede realizar una llamada a la API CreateDBInstance y configurar el parámetro “Multi-AZ” con el valor “true”. Para convertir una instancia de base de datos estándar existente (Single-AZ) a Multi-AZ, modifique la instancia de base de datos desde la consola de administración de AWS o utilice la API ModifyDBInstance y configure el parámetro “Multi-AZ” con el valor “true”.

En el caso de los motores de bases de datos RDS para PostgreSQL, RDS para MySQL, RDS para MariaDB, RDS para SQL Server, RDS para Oracle y RDS para Db2, cuando decide convertir su instancia de Amazon RDS de Single-AZ a Multi-AZ, ocurre lo siguiente:

• Se genera una instantánea de su instancia principal.
• Se crea una nueva instancia en espera en una zona de disponibilidad distinta a la de la instantánea.
• Se configura la reproducción sincrónica entre las instancias principal y en espera.

No debería haber tiempo de inactividad cuando se convierte una instancia de Single-AZ a Multi-AZ. Sin embargo, puede observar un incremento de la latencia mientras los datos de la instancia en espera se actualizan para coincidir con la instancia principal.

Las implementaciones multi-AZ de Amazon RDS detectan las situaciones de error más comunes y se recuperan automáticamente, por lo que puede restablecer las operaciones de base de datos de la manera más rápida posible sin necesidad de intervención administrativa alguna. Amazon RDS realiza automáticamente una conmutación por error en los siguientes casos:

• Pérdida de disponibilidad en la zona de disponibilidad principal
• Pérdida de conectividad de red a principal
• Error de unidad informática en principal
• Error de almacenamiento en principal

Nota: Cuando se inician operaciones, como el escalado de instancias de bases de datos o las actualizaciones del sistema (por ejemplo, la realización de revisiones en el sistema operativo), para las implementaciones Multi-AZ a fin de mejorar la disponibilidad, se aplican primero en la instancia en espera antes de que se realice la conmutación por error automática. De esta forma, la repercusión en la disponibilidad se verá limitada al tiempo necesario para que se complete la conmutación por error automática. Tenga en cuenta que las implementaciones de Amazon RDS Multi-AZ no realizan una conmutación por error automática en respuesta a las operaciones de la base de datos, como las consultas de larga duración, los bloqueos o los errores de corrupción de la base de datos.

Sí, Amazon RDS emitirá un evento de instancia de base de datos para informarle que ha tenido lugar la conmutación por error automática. Puede hacer clic en la sección "Events" de la consola de Amazon RDS o utilizar la API "DescribeEvents" para obtener información acerca de eventos relacionados con la instancia de base de datos. También puede usar las notificaciones de eventos de Amazon RDS para que se le notifique cuando se produzcan determinados eventos en la base de datos.

Amazon RDS administra automáticamente la conmutación por error para que pueda reanudar las operaciones de la base de datos a la mayor brevedad posible y sin intervención administrativa Durante la conmutación por error, Amazon RDS simplemente cambia el registro de nombre canónico (CNAME) de su instancia de base de datos para que apunte a la versión en espera, que se convierte en la nueva versión principal. Le instamos a que siga las prácticas recomendadas e implemente el reintento de conexión de la base de datos en la capa de la aplicación.

Las conmutaciones por error, definidas por el intervalo que transcurre entre la detección del error en la instancia principal y la reanudación de las transacciones en la instancia en espera, suelen tardar entre uno y dos minutos. El tiempo de la conmutación por error también puede verse afectado por el volumen de transacciones que sea necesario recuperar. Para obtener los mejores resultados, se recomienda utilizar tipos de instancia de un tamaño adecuado en las implementaciones Multi-AZ. AWS recomienda asimismo el uso de IOPS provisionadas con las instancias Multi-AZ para que el procesamiento sea rápido, predecible y constante.

Amazon RDS realiza conmutaciones por error automáticas sin necesidad de que intervenga el usuario bajo determinadas condiciones de error. Además, Amazon RDS cuenta con una opción que permite iniciar la conmutación por error al momento de reiniciar la instancia. Puede obtener acceso a esta característica a través de la consola de administración de AWS o al utilizar la llamada a la API RebootDBInstance.

En las implementaciones Multi-AZ, únicamente tiene que establecer el parámetro "Multi-AZ" en "true". La creación de la versión en espera, la replicación sincrónica y la conmutación por error se administran de forma automática. Esto implica que no podrá seleccionar la zona de disponibilidad en la que se encuentra situada su versión en espera, ni tampoco alterar el número de versiones en espera disponibles (Amazon RDS aprovisiona una versión en espera dedicada por cada versión principal de instancia de base de datos). Además, la versión en espera no puede configurarse para que acepte actividad de lectura de base de datos. Más información sobre las configuraciones Multi-AZ.

Sí. La versión en espera se aprovisionará de forma automática en una zona de disponibilidad diferente dentro de la misma región que la instancia de base de datos principal.

Sí, puede ver la ubicación de la instancia principal actual con la Consola de administración de AWS o la API DescribeDBInstances.

Las zonas de disponibilidad están diseñadas para ofrecer conectividad de red de baja latencia con otras zonas de disponibilidad que se encuentren dentro de la misma región. Además, es posible que desee barajar la posibilidad de diseñar su aplicación y otros recursos de AWS con redundancia entre varias zonas de disponibilidad, de forma que su aplicación sea robusta en caso de producirse un error en una zona de disponibilidad. Los despliegues Multi-AZ afrontan esta necesidad de la capa de la base de datos sin administración por su parte.

El usuario interactúa con la función de copias de seguridad automáticas y con la funcionalidad de instantáneas de bases de datos de la misma forma tanto si ejecuta una implementación estándar en una zona de disponibilidad única (Single-AZ) como una implementación en zonas de disponibilidad múltiples (Multi-AZ). Si ejecuta una implementación Multi-AZ, las copias de seguridad automáticas y las instantáneas de bases de datos simplemente se recuperan a partir de la copia en espera para evitar la suspensión de E/S en la versión principal. Tenga en cuenta que puede experimentar una mayor latencia de E/S (normalmente dura unos minutos) durante los backups tanto para los despliegues de zona de disponibilidad única como para los despliegues Multi-AZ.

El inicio de una operación de restablecimiento (restablecimiento en un punto del tiempo o restablecimiento a partir de una instantánea de base de datos) funciona igual en implementaciones multi-AZ que en implementaciones estándar Single-AZ. Las nuevas implementaciones para instancias de base de datos pueden crearse con las API "RestoreDBInstanceFromSnapshot" o "RestoreDBInstanceToPointInTime". Pueden ser estándar o Multi-AZ, independientemente de si el backup de origen se inició en un despliegue estándar o Multi-AZ.

Las réplicas de lectura facilitan el aprovechamiento de la funcionalidad de reproducción integrada en los motores compatibles para escalar horizontalmente de forma elástica más allá de las limitaciones de capacidad de una única instancia de base de datos para las cargas de trabajo de bases de datos con operaciones intensivas de lectura.

Puede crear una réplica de lectura con tan solo unos clics en la Consola de administración de AWS o mediante la API CreateDBInstanceReadReplica. Una vez creada dicha réplica, las actualizaciones de base de datos que se realicen en la instancia de base de datos de origen se replicarán mediante la replicación asincrónica nativa del motor admitido. Puede crear varias réplicas de lectura para una instancia de base de datos de origen determinada y distribuir entre ellas el tráfico de lectura de su aplicación.

Dado que utilizan la replicación integrada en los motores admitidos, las réplicas de lectura están sujetas tanto a sus ventajas como a sus limitaciones. En concreto, las actualizaciones se aplican a sus réplicas de lectura después de tener lugar en la instancia de base de datos de origen y el retardo de la replicación puede variar de forma significativa. Las réplicas de lectura pueden asociarse a implementaciones multi-AZ para obtener ventajas de escalado de lectura, además de los niveles de disponibilidad de escritura en la base de datos y de durabilidad de los datos que proporcionan las implementaciones multi-AZ.

La implementación de una o varias réplicas de lectura para una instancia de base de datos de origen dada puede tener sentido en diversas situaciones. Entre los motivos habituales para implementar una réplica de lectura están:

• Aumentar el escalado por encima de la capacidad de E/S o de cómputo de una única instancia de base de datos para las cargas de trabajo de las bases de datos con operaciones intensivas de lectura. Este exceso de tráfico de lectura puede dirigirse hacia una o más réplicas de lectura.
• Servir tráfico de lectura cuando la instancia de base de datos de origen no está disponible. Si su instancia de base de datos de origen no puede aceptar solicitudes de E/S (por ejemplo, debido a la suspensión de E/S para las copias de seguridad o por un mantenimiento programado), puede dirigir el tráfico de lectura a las réplicas de lectura. Para este caso de uso, tenga en cuenta que los datos de la réplica de lectura pueden estar “obsoletos” porque la instancia de base de datos de origen no está disponible.
• Escenarios de informes empresariales o almacenamiento de datos. Tal vez desea que las consultas de informes empresariales se ejecuten sobre una réplica de lectura, en lugar de realizarse en su instancia de base de datos principal de producción.
• Puede utilizar una réplica de lectura para la recuperación de desastres de la instancia de base de datos de origen, ya sea en la misma región de AWS o en una distinta.

Sí. Establezca el periodo de retención de copia de seguridad en un valor distinto de 0 para habilitar las copias de seguridad automáticas en la instancia de base de datos de origen antes de agregar réplicas de lectura. Para que funcionen las réplicas de lectura, las copias de seguridad deben permanecer habilitadas.

Amazon Aurora: todos los clústeres de bases de datos.

Amazon RDS para MySQL: todas las instancias de base de datos admiten la creación de réplicas de lectura. Las copias de seguridad automáticas deben estar y permanecer habilitadas en la instancia de base de datos de origen para las operaciones de la réplica de lectura. Las copias de seguridad automáticas de la réplica solo se admiten para las réplicas de lectura de Amazon RDS que ejecutan MySQL 5.6 o versiones posteriores, no 5.5.

Amazon RDS para PostgreSQL: las instancias de base de datos con la versión 9.3.5 o posterior de PostgreSQL admiten la creación de réplicas de lectura. Las instancias de PostgreSQL ya existentes, anteriores a la versión 9.3.5, tendrán que actualizarse a la versión 9.3.5 de PostgreSQL para poder beneficiarse de las réplicas de lectura de Amazon RDS.

Amazon RDS para MariaDB: todas las instancias de base de datos admiten la creación de réplicas de lectura. Las copias de seguridad automáticas deben estar y permanecer habilitadas en la instancia de base de datos de origen para las operaciones de la réplica de lectura.

Amazon RDS para Oracle: compatible con la versión 12.1.0.2.v12 y posteriores de Oracle, y con todas las versiones 12.2 que utilizan el modelo de licencia Bring Your Own License (BYOL) para Oracle Database Enterprise Edition y que cuentan con la licencia de la opción Active Data Guard.

Amazon RDS para SQL Server: las réplicas de lectura son compatibles con Enterprise Edition en la configuración multi-AZ cuando la tecnología de reproducción subyacente utiliza grupos de disponibilidad Always On (Siempre disponible) para las versiones de SQL Server 2016 y 2017.

Puede crear una réplica de lectura en cuestión de minutos mediante la API estándar CreateDBInstanceReadReplica o en solo unos pasos en la Consola de administración de AWS. Al crear una réplica de lectura, especifique SourceDBInstanceIdentifier para identificarla como réplica de lectura. SourceDBInstanceIdentifier es el identificador de instancias de bases de datos de "origen" desde la que desea realizar la replicación. De la misma forma que en las instancias de base de datos estándar, también puede especificar la zona de disponibilidad, la clase de instancia de base de datos y el período de mantenimiento preferido. La versión del motor (por ejemplo, PostgreSQL 9.3.5) y la asignación de almacenamiento de una réplica de lectura se heredan de la instancia de base de datos de origen. 

Cuando inicia la creación de una réplica de lectura, Amazon RDS realiza una instantánea de la instancia de base de datos de origen y comienza el proceso de replicación. Por ello, experimentará una breve suspensión de las operaciones de E/S en la instancia de base de datos de origen durante la creación de la instantánea. La suspensión de las operaciones de E/S suele durar alrededor de un minuto y se evita si la instancia de base de datos de origen es una implementación Multi-AZ, en cuyo caso, las instantáneas se generan a partir de la instancia en espera.

Amazon RDS está trabajando en estos momentos en una optimización (disponible en breve) por la que, si se crean varias réplicas de lectura dentro de una ventana de 30 minutos, todas ellas utilizan el mismo snapshot de origen para minimizar el impacto de E/S (la replicación de "puesta al día" de cada réplica de lectura comenzará tras su creación).

Puede conectarse a una réplica de lectura del mismo modo que se conectaría a una instancia de base de datos estándar, mediante la API DescribeDBInstance o la consola de administración de AWS para recuperar los puntos de conexión de su(s) réplica(s) de lectura. Si cuenta con varias réplicas de lectura es decisión de su aplicación determinar la cantidad de tráfico que se distribuirá entre ellas.

Actualmente, Amazon RDS para MySQL, MariaDB y PostgreSQL permiten crear hasta 15 réplicas de lectura de una instancia de base de datos de origen determinada. Amazon RDS para Oracle y SQL Server permiten crear hasta 5 réplicas de lectura de una instancia de base de datos de origen determinada.

Sí, Amazon RDS (excepto RDS para SQL Server) admite réplicas de lectura entre regiones. La cantidad de tiempo que transcurre entre la escritura de los datos en la instancia de base de datos de origen y el momento en que están disponibles en la réplica de lectura dependerá de la latencia de red entre ambas regiones.

No. Las réplicas de lectura en Amazon RDS for MySQL, MariaDB, PostgreSQL, Oracle y SQL Server se implementan mediante la replicación asincrónica nativa de esos motores. Amazon Aurora usa un mecanismo de replicación diferente, pero que también es asíncrono.

Si desea utilizar la replicación para incrementar la disponibilidad de escritura de la base de datos y proteger las actualizaciones más recientes de la base de datos frente a diversas situaciones de error, le recomendamos que ejecute su instancia de base de datos como implementación Multi-AZ. Con las réplicas de lectura de Amazon RDS, que utilizan la replicación asincrónica nativa de los motores admitidos, las escrituras en la base de datos se realizan en la réplica de lectura después de haberse llevado a cabo en la instancia de base de datos de origen. El "retardo" de esta replicación puede variar considerablemente. 

Por su parte, la replicación que utilizan las implementaciones Multi-AZ es sincrónica, lo que significa que todas las escrituras en la base de datos son simultáneas en la versión principal y en la versión en espera. De esta forma se protegen las actualizaciones más recientes de la base de datos, ya que deben estar disponibles en la instancia en espera en caso de que sea necesaria una conmutación por error. 

Además, con las implementaciones Multi-AZ, la replicación está totalmente administrada. Amazon RDS monitoriza automáticamente la existencia de errores en las zonas de disponibilidad o las condiciones de error en instancias de base de datos e inicia la conmutación por error automática en la instancia en espera (o en una réplica de lectura, en el caso de Amazon Aurora) si se produce una interrupción.

Sí. Dado que las instancias de base de datos Multi-AZ abordan necesidades distintas a las réplicas de lectura, es razonable utilizarlas de forma conjunta en implementaciones de producción y asociar una réplica de lectura a una implementación de instancia de base de datos Multi-AZ. La instancia de base de datos Multi-AZ de "origen" ofrece disponibilidad de escritura y durabilidad de datos mejoradas y la réplica de lectura asociada mejorará la escalabilidad del tráfico de lectura.

Sí. Con Amazon RDS for MySQL, MariaDB, PostgreSQL y Oracle, se puede habilitar la configuración Multi-AZ en las réplicas de lectura para permitir la recuperación de desastres y minimizar el tiempo de inactividad provocado por las actualizaciones de motores.

En caso de producirse una conmutación por error Multi-AZ, las réplicas de lectura asociadas y disponibles reanudarán automáticamente la replicación una vez completada la conmutación por error (mediante la adquisición de las actualizaciones de la nueva versión principal).

Amazon Aurora, Amazon RDS para MySQL y MariaDB: puede crear tres niveles de réplicas de lectura. Una réplica de lectura de segundo nivel de una réplica de lectura de primer nivel existente y una réplica de tercer nivel de réplicas de lectura de segundo nivel. Al crear una réplica de lectura de segundo nivel, puede mover parte de la carga de replicación de la instancia de base de datos principal a réplicas de lectura de diferentes niveles en función de lo que necesite para su aplicación.

Tenga en cuenta que una réplica de lectura de segundo nivel puede retrasarse más respecto de la instancia principal debido a la latencia de replicación adicional introducida a medida que se replican las transacciones de la instancia principal en la réplica de primer nivel y, a continuación, en la réplica de segundo nivel. Del mismo modo, la réplica de tercer nivel puede retrasarse con respecto a la réplica de lectura de segundo nivel.

Amazon RDS para Oracle y Amazon RDS para SQL Server: actualmente, no se admiten las réplicas de lectura de otras réplicas de lectura.

Las réplicas de lectura están diseñadas para servir tráfico de lectura. Sin embargo, puede haber casos de uso en los que usuarios avanzados deseen completar instrucciones SQL del lenguaje de definición de datos (DDL) en una réplica de lectura. Entre los ejemplos, pueden incluirse la adición de un índice de base de datos a una réplica de lectura que se utiliza para generar informes empresariales, sin agregar el mismo índice a la instancia de base de datos de origen correspondiente.

Amazon RDS for MySQL puede configurarse de manera que permita aplicar las instrucciones SQL de DDL en una réplica de lectura. Si desea habilitar operaciones distintas a la lectura en una réplica de lectura determinada, modifique el grupo de parámetros de base de datos activo en la réplica de lectura estableciendo el parámetro “read_only” como “0”.

Amazon RDS para PostgreSQL actualmente no admite la ejecución de instrucciones SQL de DDL en una réplica de lectura.

Sí. Consulte la Guía del usuario de Amazon RDS para obtener más detalles.

Las actualizaciones realizadas en una instancia de base de datos de origen se replicarán automáticamente en las réplicas de lectura asociadas. Sin embargo, con la tecnología de replicación asincrónica de los motores compatibles, una réplica de lectura puede quedar retrasada respecto a su instancia de base de datos de origen por diversas razones. Algunos motivos habituales son:

• El volumen de E/S de escritura en la instancia de base de datos supera la velocidad a la que se pueden aplicar los cambios en la réplica de lectura (este problema ocurre especialmente si la capacidad de cómputo de la réplica de lectura es inferior a la de la instancia de base de datos de origen)
• Las transacciones complejas o de ejecución prolongada en la instancia de base de datos de origen retienen la replicación en la réplica de lectura
• La latencia o las particiones de red entre la instancia de base de datos de origen y una réplica de lectura

Las réplicas de lectura están sujetas a los puntos fuertes y débiles de la replicación nativa de los motores admitidos. Si utiliza réplicas de lectura, debe tener en cuenta la posibilidad de que se produzca un retardo entre una réplica de lectura y su instancia de base de datos de origen o “incoherencia”.

Puede utilizar la API estándar DescribeDBInstances para devolver una lista de todas las instancias de bases de datos que ha implementado (incluidas las réplicas de lectura) o simplemente hacer clic en la pestaña Instances (Instancias) de la consola de Amazon RDS.

Amazon RDS le permite obtener información sobre el retraso que lleva una réplica de lectura respecto de su instancia de base de datos de origen. La cantidad de segundos de retraso de la réplica de lectura en relación con la instancia principal se publica como métrica de Amazon CloudWatch (“Replica Lag” [Retraso de réplica]) disponible a través de la consola de administración de AWS o las API de Amazon CloudWatch.

En Amazon RDS para MySQL, el origen de esta información es el mismo que se muestra al aplicar el comando estándar Show Replica Status (Mostrar estado de réplica) de MySQL en la réplica de lectura. En Amazon RDS for PostgreSQL, puede utilizar la vista pg_stat_replication en la instancia de base de datos de origen para explorar las métricas de la replicación.

Amazon RDS supervisa el estado de replicación de las réplicas de lectura y actualiza el campo Replication State (Estado de replicación) de la consola de administración de AWS a Error si la replicación se detiene por cualquier motivo (por ejemplo, si intenta ejecutar en su réplica consultas DML que entren en conflicto con las actualizaciones hechas en la instancia de base de datos principal, se podría producir un error de replicación). Puede revisar los detalles del error que devuelve el motor de MySQL al ver el campo Replication Error (Error de replicación) y tomar las medidas adecuadas para recuperarse. Puede obtener más información sobre la resolución de problemas de replicación en la sección de resolución de un problema de réplica de lectura de la Guía del usuario de Amazon RDS para MySQL o PostgreSQL. 

Si se soluciona un problema de replicación, el Replication State cambia a Replicating.

Para que la replicación funcione con eficacia, se recomienda que las réplicas de lectura tengan los mismos recursos de cómputo y almacenamiento o más que sus instancias de bases de datos de origen correspondientes. De lo contrario, es posible que el retardo de replicación aumente o que su réplica de lectura se quede sin espacio para almacenar las actualizaciones replicadas.

Puede eliminar fácilmente una réplica de lectura si sigue algunos pasos en la Consola de administración de AWS o al pasar su identificador de instancia de base de datos a la API DeleteDBInstance. 

Una réplica de Amazon Aurora permanecerá activa y seguirá aceptando tráfico de lectura incluso después de haber eliminado su instancia de base de datos de origen correspondiente. Una de las réplicas del clúster se transformará automáticamente en la nueva réplica principal y comenzará a aceptar tráfico de escritura.

La réplica de lectura de Amazon RDS for MySQL o MariaDB permanecerá activa y seguirá aceptando tráfico de lectura incluso después de haber eliminado su instancia de base de datos de origen correspondiente. Si desea eliminar la réplica de lectura, además de la instancia de base de datos de origen, debe eliminarla de forma explícita con la API DeleteDBInstance o con la consola de administración de AWS.

Si elimina una instancia de base de datos de Amazon RDS for PostgreSQL que tenga réplicas de lectura, todas las réplicas de lectura se transformarán para convertirse en instancias de base de datos independientes y aceptarán tráfico tanto de lectura como de escritura. Las instancias de bases de datos que se transformaron recientemente operarán de forma independiente entre sí. Si desea eliminar estas instancias de base de datos, además de la instancia original de base de datos de origen, debe eliminarlas de forma explícita con el API DeleteDBInstance o la consola de administración de AWS.

Las réplicas de lectura se facturan como una instancia de base de datos estándar y con las mismas tarifas. De la misma forma que en una instancia de base de datos estándar, la tarifa de "instancia de base de datos por hora" se determina en función de la clase de instancia de base de datos de la réplica de lectura. Consulte la página de precios para ver los precios actualizados. No se le cobrarán las transferencias de datos en las que incurra durante la replicación de datos entre su instancia de base de datos de origen y la réplica de lectura en una misma región de AWS.

La facturación de una réplica de lectura comienza en cuanto la réplica se creó con éxito (es decir, cuando el estado aparece como “active” [activo]). La réplica de lectura se seguirá facturando según las tarifas estándar por hora de instancia de base de datos de Amazon RDS hasta que emita un comando para eliminarla.

Enhanced Monitoring de Amazon RDS le ofrece mayor visibilidad sobre el estado de sus instancias de Amazon RDS. Solo tiene que activar la opción “Enhanced Monitoring” para su instancia de base de datos de Amazon RDS y establecer un nivel de detalle. Enhanced Monitoring obtendrá métricas esenciales del sistema operativo y procesará la información con el nivel de detalle indicado.

Para obtener un diagnóstico y una visualización más profundos de la carga de su base de datos, así como un periodo de retención de datos más largo, pruebe la información de rendimiento.

Enhanced Monitoring registra las métricas de la instancia de Amazon RDS a nivel del sistema, como las de la CPU, la memoria, el sistema de archivos y las operaciones de E/S del disco, entre otras. Encuentre la lista completa de métricas en la documentación.

Enhanced Monitoring es compatible con todos los motores de bases de datos de Amazon RDS.

Enhanced Monitoring admite todos los tipos de instancia excepto t1.micro y m1.small. El software utiliza una pequeña parte de la CPU, la memoria y la capacidad de E/S. Para un monitoreo general, recomendamos establecer mayores niveles de pormenorización en las instancias medianas o más grandes. Para las instancias de bases de datos que no son de producción, la configuración predeterminada del Enhanced Monitoring es “off” (desactivado). Puede dejarlo así o modificar la pormenorización una vez activado.

Puede ver en la consola todas las métricas del sistema y la información de los procesos de sus instancias de bases de datos de Amazon RDS en un formato gráfico. Tiene la opción de indicar qué métricas quiere monitorizar para cada instancia y personalizar el panel según sus requisitos.

No. Puede establecer distintos niveles de pormenorización para cada instancia de base de datos de su cuenta de Amazon RDS. También puede elegir en qué instancias desea habilitar Enhanced Monitoring y modificar la granularidad de cualquier instancia cuando lo desee.

Puede ver los valores de rendimiento de todas las métricas de hasta hace 1 hora, con un nivel de pormenorización máximo de 1 segundo, en función de la configuración.

Las métricas de Enhanced Monitoring de Amazon RDS se entregan en su cuenta de CloudWatch Logs. Puede crear filtros para estas métricas en CloudWatch desde CloudWatch Logs y mostrar los gráficos en el panel de CloudWatch. Para obtener más detalles, visite la página de Amazon CloudWatch.

Debe utilizar CloudWatch si desea ver datos históricos más allá de los que se encuentran disponibles en el panel de la consola de Amazon RDS. Puede monitorear sus instancias de Amazon RDS en CloudWatch para diagnosticar el estado de toda su pila de AWS en una única ubicación. En este momento, CloudWatch admite granularidades de hasta 1 minuto; los valores se promediarán en el caso de granularidades menores.

Sí. Puede crear una alarma en CloudWatch que envíe una notificación cuando cambie el estado de la alarma. Esta alarma vigila una única métrica durante el periodo que usted especifique y realiza una o más acciones en función del valor de la métrica respecto del límite especificado después de distintos periodos. Para obtener más detalles sobre las alarmas en CloudWatch, consulte la Guía para desarrolladores de Amazon CloudWatch.

Enhanced Monitoring de Amazon RDS proporciona un conjunto de métricas formadas como cargas JSON que se entregan a su cuenta de CloudWatch Logs. Estas cargas JSON se entregan con el último nivel de pormenorización configurado para la instancia de Amazon RDS.

Existen dos modos de consumir las métricas mediante un panel o aplicación de terceros. Las herramientas de monitoreo pueden usar suscripciones a registros de CloudWatch para configurar un feed de métricas que funciona casi en tiempo real. También puede utilizar filtros en CloudWatch Logs para llevar las métricas a CloudWatch e integrar la aplicación a CloudWatch. Consulte la documentación de Amazon CloudWatch para obtener más detalles.

Como Enhanced Monitoring entrega cargas JSON en un registro de su cuenta de CloudWatch Logs, puede controlar el período de retención como haría con cualquier otra transmisión de CloudWatch Logs. El período de retención predeterminado configurado para Enhanced Monitoring en CloudWatch Logs es de 30 días. Si quiere obtener más información para cambiar la configuración de retención, visite la Guía para desarrolladores de Amazon CloudWatch.

Como las métricas se entregan en CloudWatch Logs, una vez que se exceda la capa gratuita, el costo se basará en las tarifas de transferencia de datos de CloudWatch Logs y las tarifas de almacenamiento. Puede encontrar detalles al respecto aquí. La cantidad de información transferida para una instancia de Amazon RDS es directamente proporcional al nivel de pormenorización definido para la característica Enhanced Monitoring. Los administradores pueden configurar distintas granularidades para distintas instancias de sus cuentas, y así administrar los costos.

A continuación se muestra el volumen aproximado de datos entregados por Enhanced Monitoring a CloudWatch Logs para una instancia:

Amazon RDS Proxy es una característica de proxy de base de datos de alta disponibilidad y completamente administrada para Amazon RDS. El proxy de RDS hace que las aplicaciones sean más escalables, más resistentes a las fallas de la base de datos y más seguras.

Amazon RDS Proxy es una característica de proxy de base de datos completamente administrada, de alta disponibilidad y fácil de usar de Amazon RDS que permite a sus aplicaciones realizar lo siguiente: 1) mejorar la escalabilidad al agrupar y compartir conexiones de bases de datos; 2) mejorar la disponibilidad al reducir los tiempos de conmutación por error de la base de datos hasta un 66 % y preservar las conexiones de la aplicación durante las conmutaciones por error; y 3) mejorar la seguridad mediante la aplicación opcional de la autenticación de AWS IAM en las bases de datos y el almacenamiento de credenciales de forma segura en AWS Secrets Manager.

En función de su carga de trabajo, el proxy de Amazon RDS puede agregar un promedio de 5 milisegundos de latencia de red al tiempo de respuesta de consulta o transacción. Si su aplicación no puede tolerar 5 milisegundos de latencia o no necesita administración de conexión y otras características habilitadas por el proxy de RDS, es posible que desee que su aplicación se conecte directamente al punto de conexión de la base de datos.

Amazon RDS Proxy transforma su enfoque para crear modernas aplicaciones sin servidor que aprovechen el poder y la simplicidad de las bases de datos relacionales. Primero, el proxy de RDS permite que las aplicaciones sin servidor se escalen de manera eficiente con la agrupación y reutilización de las conexiones de la base de datos. En segundo lugar, con el proxy de RDS, ya no necesita manejar las credenciales de la base de datos en su código de Lambda. Puede usar el rol de ejecución de IAM asociado con su función de Lambda para autenticarse con el proxy de RDS y su base de datos. En tercer lugar, no necesita administrar ninguna infraestructura o código nuevo para utilizar todo el potencial de las aplicaciones sin servidor respaldadas por bases de datos relacionales. El proxy de RDS se administra totalmente y escala su capacidad automáticamente en función de las demandas de su aplicación.

RDS Proxy está disponible para Amazon Aurora con compatibilidad con MySQL, Amazon Aurora con compatibilidad con PostgreSQL, Amazon RDS for MariaDB, Amazon RDS para MySQL, Amazon RDS for PostgreSQL y Amazon RDS for SQL Server. Para obtener una lista de las versiones de motor compatibles, consulte la Guía del usuario de Amazon Aurora o la Guía del usuario de Amazon RDS.

Habilita el proxy de Amazon RDS para su base de datos de dicho servicio con solo unos pocos clics en la consola de Amazon RDS. Cuando habilita el proxy de RDS, especifica la VPC y las subredes desde las que desea acceder al proxy de RDS. Como usuario de Lambda, puede habilitar Amazon RDS Proxy para su base de datos de Amazon RDS y configurar una función de Lambda para acceder a ella con solo unos pocos clics en la consola de Lambda.

Sí. Puede usar las API del proxy de Amazon RDS para crear un proxy y luego definir grupos de destino para asociar el proxy con instancias o clústeres de bases de datos específicos. Por ejemplo:

aws rds create-db-proxy 
        --db-proxy-name '...' 
        --engine-family <mysql|postgresql>       
        --auth [{}, {}] 
        --role-arn '…'
        --subnet-ids {}
        --require-tls <true|false>
        --tags {}
aws rds register-db-proxy-targets 
        --target-group-name '…'
        --db-cluster-identifier  '…'
        --db-instance-identifier '…'

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

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

Las TLE para PostgreSQL ofrecen múltiples capas de protección para mitigar este riesgo. TLE está diseñado 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. TLE está diseñado para limitar el impacto de un defecto de extensión a una única conexión de base de datos. Además de estas medidas de seguridad, TLE está diseñado para proporcionar a los administradores de bases de datos (DBA) en el rol rds_superuser un control en línea detallado sobre quién puede instalar extensiones y pueden crear un modelo de permisos para ejecutarlas.

Solo los usuarios con suficientes privilegios podrán ejecutar y crear con el comando “CREATE EXTENSION” en una extensión de TLE. Los administradores de bases de datos también pueden incluir en la lista de permitidos los “enlaces de PostgreSQL” necesarios para extensiones más sofisticadas que modifican el comportamiento interno de la base de datos y, por lo general, requieren privilegios elevados.

TLE para PostgreSQL está disponible para la edición compatible con PostgreSQL de Amazon Aurora y Amazon RDS en PostgreSQL, en las versiones 14.5 y posteriores. TLE se implementa como una extensión de PostgreSQL y puede activarlo desde el rol rds_superuser de forma similar a otras extensiones compatibles con Aurora y Amazon RDS.

Puede ejecutar TLE para PostgreSQL en PostgreSQL 14.5 o versiones posteriores en Amazon Aurora y Amazon RDS.  

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

TLE para PostgreSQL está disponible para los clientes de Aurora y Amazon RDS sin costo adicional.

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

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

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

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

Las TLE para PostgreSQL acceden a su base de datos de PostgreSQL exclusivamente a través de la API de TLE. Los lenguajes de confianza admitidos por 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.

Los despliegues azul-verde de Amazon RDS están disponibles en la edición compatible con MySQL de Amazon Aurora, edición compatible con PostgreSQL de Amazon Aurora, Amazon RDS para MySQL, Amazon RDS para MariaDB y Amazon RDS para PostgreSQL. 

Los despliegues azul-verde de Amazon RDS están disponibles en la edición compatible con MySQL de Amazon Aurora versión 5.6 y posteriores, RDS para MySQL versión 5.7 y posteriores, y RDS para MariaDB versión 10.2 y posteriores. Los despliegues azul-verde también se encuentran en la edición compatible con PostgreSQL de Amazon Aurora y Amazon RDS para PostgreSQL para las versiones 11.21 y posteriores, 12.16 y posteriores, 13.12 y posteriores, 14.9 y posteriores, y 15.4 y posteriores. Obtenga más información sobre las versiones disponibles en la documentación de Amazon Aurora y Amazon RDS. 

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

Las implementaciones azul-verde de Amazon RDS le permiten realizar cambios de bases de datos con mayor seguridad, sencillez y rapidez. Las implementaciones azul-verde son ideales para casos de uso como actualizaciones del motor de bases de datos de versiones principales o secundarias, actualizaciones del sistema operativo, cambios de esquema en entornos verdes que no interrumpen la replicación lógica, como agregar una nueva columna al final de una tabla o cambios en la configuración de los parámetros de la base de datos. Puede utilizar las implementaciones azul-verde para realizar varias actualizaciones de bases de datos al mismo tiempo mediante una sola conmutación. Esto le permite mantenerse al día con las revisiones de seguridad, mejorar el rendimiento de la base de datos y acceder a las características más recientes de la base de datos con un tiempo de inactividad breve y predecible.

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

Por ejemplo, tiene una base de datos de RDS para MySQL 5.7 que se ejecuta en dos db.instances r5.2xlarge, una instancia de base de datos primaria y una réplica de lectura, en la región de AWS us-east-1 con una configuración Multi-AZ (MAZ). Cada una de las db.instances r5.2xlarge está configurada para 20 GiB de uso general de Amazon Elastic Block Store (EBS). Crea un clon de la topología de la instancia azul con los despliegues azul-verde de Amazon RDS, lo ejecuta durante 15 días (360 horas) y luego borra las instancias azules después de un cambio exitoso. Las instancias azules cuestan 1387 USD por 15 días a una tarifa bajo demanda de 1,926 USD por hora (instancia + costo de EBS). El costo total por usar despliegues azules-verdes durante esos 15 días es de 2774 USD, que es el doble del costo de ejecutar instancias azules durante ese periodo.

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

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

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

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

Las barreras de protección de cambio de las implementaciones azul/verde de Amazon RDS bloquean las escrituras en los entornos azul y verde hasta que el entorno verde se actualiza antes de cambiar. 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 un tiempo de inactividad máximo tolerable, a partir de 30 segundos, y si tiene una transacción en curso que lo excede, la conmutación se interrumpirá.

No, los despliegues azul-verde de Amazon RDS no admiten bases de datos globales, Amazon RDS Proxy, réplicas de lectura entre regiones ni réplicas de lectura en cascada.

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

MySQL protege a los usuarios de la pérdida de datos al escribir datos en páginas de 16 KiB en la memoria dos veces para que duren en el almacenamiento: primero en el “búfer de doble escritura” y luego en el almacenamiento de tablas. Las escrituras optimizadas de Amazon RDS escriben las páginas de datos de 16 KiB directamente en los archivos de datos de forma fiable y duradera en un solo paso mediante la característica de prevención de errores de escritura de AWS Nitro System.

Las escrituras optimizadas de Amazon RDS están disponibles a partir de la versión principal 8.0.30 de MySQL en adelante.

Las escrituras optimizadas de Amazon RDS están disponibles en las instancias db.r6i y db.r5b. Se encuentran disponibles en todas las regiones donde estén disponibles estas instancias, excepto en las regiones de China de AWS.

Todos los usuarios de Amazon RDS para MySQL deben implementar las escrituras optimizadas de Amazon RDS para duplicar el rendimiento de las transacciones de escritura. Esta característica es especialmente útil para las aplicaciones con cargas de trabajo de escritura intensiva, como pagos digitales, comercio financiero y aplicaciones de juegos en línea.

No. La edición compatible con MySQL de Amazon Aurora ya evita el uso del “búfer de doble escritura”. En cambio, Amazon Aurora reproduce datos de seis maneras en tres zonas de disponibilidad (AZ) y utiliza un enfoque basado en un quórum para escribir datos de manera duradera y luego leerlos correctamente.

En este momento, la versión inicial no es compatible con la habilitación de las escrituras optimizadas de Amazon RDS para las instancias de bases de datos existentes, incluso si la clase de instancia admite las escrituras optimizadas.

Las escrituras optimizadas de Amazon RDS están disponibles para los clientes de RDS para MySQL sin ningún costo adicional.

Las cargas de trabajo que usan objetos temporales en MySQL y MariaDB para el procesamiento de consultas se benefician de las lecturas optimizadas de Amazon RDS. Las lecturas optimizadas ubican los objetos temporales en el almacenamiento de instancias basado en NVMe de la instancia de base de datos y no en el volumen de Amazon Elastic Block Store. Esto ayuda a acelerar hasta doble el procesamiento de consultas complejas.

Las lecturas optimizadas de Amazon RDS están disponibles para RDS para MySQL en MySQL, versiones 8.0.28 y posteriores, y para RDS para MariaDB en MariaDB, versiones 10.4.25, 10.5.16, 10.6.7 y posteriores.

Las lecturas optimizadas de Amazon RDS están disponibles en todas las regiones donde las instancias db.r5d, db.m5d, db.r6gd, db.m6gd, X2idn y X2iedn están disponibles. Para obtener más información, consulte la documentación de clases de instancia de base de datos de Amazon RDS.

Los clientes deben usar las lecturas optimizadas de Amazon RDS cuando tienen cargas de trabajo que requieren consultas complejas; análisis de uso general; o grupos complejos, clasificaciones, agregaciones de hash, uniones de carga elevada y expresiones comunes de tabla (CTE). Estos casos de uso tienen como resultado la creación de tablas temporales, lo que permite a las lecturas optimizadas acelerar el procesamiento de consultas de su carga de trabajo.

Sí, los clientes pueden convertir su base de datos existente en Amazon RDS para usar las lecturas optimizadas de Amazon RDS mediante el traslado de su carga de trabajo a una instancia habilitada para lecturas optimizadas. Las lecturas optimizadas también están disponibles de forma predeterminada en todas las clases de instancias admitidas. Si está ejecutando una carga de trabajo en instancias db.r5d, db.m5d, db.r6gd, db.m6gd, X2idn y X2iedn ya se beneficia de las lecturas optimizadas.