Preguntas frecuentes sobre Amazon RDS

Amazon Relational Database Service (Amazon RDS) es un servicio administrado que facilita la configuración, el funcionamiento y el escalado de las bases de datos relacionales en la nube. Proporciona una capacidad rentable y redimensionable, a la vez que administra las arduas tareas de administración de la base de datos, con lo que podrá centrarse en las aplicaciones y el negocio.

Amazon RDS brinda acceso a las capacidades de una base de datos conocida de RDS para PostgreSQL, RDS para MySQL, RDS para MariaDB, RDS para SQL Server, RDS para Oracle o RDS para Db2. Esto significa que el código, las aplicaciones y las herramientas que utiliza actualmente con las bases de datos existentes funcionarán a la perfección con Amazon RDS. Amazon RDS puede realizar copias de seguridad automáticas de la base de datos y actualizar el software de base de datos a la versión más reciente. Podrá beneficiarse de la flexibilidad que ofrece poder ajustar fácilmente la escala de los recursos de computación o la capacidad de almacenamiento asociada con la instancia de base de datos relacional. Además, con Amazon RDS es sencillo utilizar la replicación para mejorar la disponibilidad de la base de datos y la durabilidad de los datos, o para escalar más allá de los límites de capacidad de una única instancia de base de datos para cargas de trabajo de bases de datos con un uso intensivo de las lecturas. Como en todos los servicios de AWS, no se requiere ningún tipo de inversión inicial, y usted solo pagará por los recursos que use.

Amazon Web Services ofrece a los desarrolladores diversas alternativas de bases de datos. Amazon RDS ofrece la posibilidad de ejecutar una base de datos relacional completamente administrada y equipada, y lo libera de tener que administrarla. El uso de una de nuestras muchas AMI de base de datos relacionales en Amazon EC2 permite administrar una base de datos relacional propia en la nube. Existen importantes diferencias entre estas alternativas que podrían hacer que una de ellas fuera más adecuada que otra en función del caso de uso. Consulte Bases de datos en la nube con AWS para conocer cuál es la mejor solución.

Sí, puede ejecutar Amazon RDS en las instalaciones con Amazon RDS en Outposts. Consulte las preguntas frecuentes de Amazon RDS en Outposts para obtener información adicional.

Sí, hay especialistas en Amazon RDS disponibles para responder preguntas y ofrecer asistencia. Contáctenos y recibirá una respuesta en un plazo de un día hábil, para que podamos analizar cómo AWS puede ayudar a su organización.

Puede configurar una conexión entre una instancia de computación de EC2 y una nueva base de datos de Amazon RDS mediante la consola de Amazon RDS. En la página “Create database” (Crear base de datos), seleccione “Conectarse a un recurso de cómputo de EC2” en la sección “Connectivity” (Conectividad). Al seleccionar esta opción, Amazon RDS automatiza las tareas manuales de configuración de redes, como la creación de una VPC, los grupos de seguridad, las subredes y las reglas de entrada y salida para establecer una conexión entre su aplicación y la base de datos.

Además, puede configurar una conexión entre una base de datos de Amazon RDS existente y una instancia de cómputo de EC2. Para ello, abra la consola de RDS, seleccione una base de datos RDS en la página de la lista de bases de datos y elija “Set up EC2 connection” (Configurar conexión de EC2) en la lista desplegable del menú “Action” (Acción). Amazon RDS configura automáticamente su configuración de red relacionada para permitir una conexión segura entre la instancia de EC2 seleccionada y la base de datos de RDS.

Esta automatización de la conectividad mejora la productividad de los nuevos usuarios y de los desarrolladores de aplicaciones. Ahora los usuarios pueden conectar de forma rápida y sin interrupciones una aplicación o un cliente que utilice SQL en una instancia de computación de EC2 a una base de datos de RDS en cuestión de minutos.

Puede configurar una conexión entre una función de AWS Lambda y una base de datos de Amazon RDS o Amazon Aurora desde la consola de Amazon RDS. En la consola de RDS, seleccione una base de datos RDS o Aurora en la página de la lista de bases de datos y elija Configurar la conexión Lambda en el menú Acción. Amazon RDS configura automáticamente su configuración de red relacionada para permitir una conexión segura entre la función de Lambda seleccionada y la base de datos de RDS o Aurora.

Le recomendamos que utilice RDS Proxy durante la configuración de esta conexión. Puede configurar esta conexión utilizando una instancia de RDS Proxy existente o utilizando una nueva instancia de RDS Proxy que puede crear automáticamente al realizar la conexión. Esta automatización de la configuración de la conectividad puede mejorar la productividad de los usuarios nuevos y de los desarrolladores de aplicaciones. Ahora los usuarios pueden conectar rápidamente y sin problemas una aplicación sin servidor o una función de Lambda a una base de datos de RDS o Aurora en cuestión de minutos.

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 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 la línea de comandos de AWS. Puede ejecutar una o varias instancias de base de datos, y cada instancia puede admitir una o más bases de datos o esquemas de base 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 copias de seguridad preferido y el periodo de mantenimiento programado de la 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 la 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 establecer conexión directamente con la instancia de base de datos mediante la herramienta de base de datos o lenguaje de programación que prefiera. 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 licencia propia (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 Cargador de SQL
• SQL Server: asistente de importación/exportación, archivos de copia de seguridad 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 ayuda a migrar bases de datos a AWS de forma fácil y segura.

El periodo de mantenimiento de Amazon RDS es su oportunidad para controlar cuándo se realizan modificaciones en la instancia de base de datos, actualizaciones de versión del motor de base de datos y la aplicación de parches de software, en caso de que se soliciten o se requieran. Si un evento de mantenimiento está programado para una semana determinada, se iniciará dentro del periodo de mantenimiento que 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. Este tipo de aplicación de parches ocurre con poca frecuencia (normalmente cada varios meses) y rara vez requiere más que 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 desea cambiar el momento en que se realiza el mantenimiento en su nombre, puede modificar la instancia de base de datos desde la Consola de administración de AWS, mediante la API ModifyDBInstance o con el comando modify-db-instance. Puede configurar varios periodos de mantenimiento según sus preferencias para cada una de las instancias de base de datos.

La ejecución de la 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.

En el caso de las bases de datos de producción, recomendamos habilitar la Supervisión mejorada, 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 el nivel de detalle (de hasta 1 segundo). El uso intensivo de CPU puede reducir el rendimiento de las consultas, en cuyo caso puede considerar escalar la clase de instancia de base de datos. Si quiere obtener más información para supervisar 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 de la base de datos para determinar si existen consultas SQL que se ejecutan 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 ejecutan 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 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 para PostgreSQL
• Amazon RDS para MySQL
• Amazon RDS para 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. La cantidad 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, como orientación general, nuestro objetivo es admitir las nuevas versiones de los motores dentro de los 5 meses posteriores a su disponibilidad general.

Puede especificar cualquier versión admitida actualmente (principal y secundaria) al crear una nueva instancia de base de datos mediante la operación 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 la instancia de base de datos actualizada al proporcionar versiones más nuevas de los motores de base de datos compatibles. Después de que el proveedor o la organización desarrolladora lance una nueva versión de un motor de base de datos, nuestro equipo de ingeniería la somete a pruebas exhaustivas antes de ponerla a disposición en Amazon RDS.

Recomendamos mantener la instancia de base de datos actualizada con la versión secundaria más reciente, ya que incluye las últimas correcciones de seguridad y funcionalidad. A diferencia de las actualizaciones de versión principal, las actualizaciones de versión secundaria solo incorporan cambios en la base de datos que son compatibles con versiones secundarias anteriores (de la misma versión principal) del motor de base de datos. 

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 Modificar instancia de base de datos en la Consola de administración de AWS o la API ModifyDBInstance y establezca el parámetro 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 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 programarán de manera que sucedan 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.

Dado que las actualizaciones de versión principal implican cierto riesgo de compatibilidad, no se producirán automáticamente y deberá iniciarla personalmente (excepto en el caso de la obsolescencia de una versión principal, como se indica a continuación). 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. Luego podrá experimentar de manera segura con la copia actualizada de la instancia de base de datos antes de decidir si desea o no actualizar la instancia original.

Para obtener más información sobre cómo restaurar una copia de seguridad de la instancia de base de datos, consulte la Guía del usuario de Amazon RDS.

• Nuestro propósito es admitir las versiones principales (por ejemplo, MySQL 5.6, PostgreSQL 9.6) durante al menos 3 años después de que Amazon RDS comience a ofrecer compatibilidad con ellas.
• 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 el caso de las versiones secundarias, esto ocurre cuando una versión menor tiene errores importantes o problemas de seguridad que se resolvieron en una versión menor posterior.

Aunque nos esforzamos por cumplir con estas directrices, en algunos casos podemos retirar 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 aborde.

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 base de datos queda obsoleta en Amazon RDS, proporcionamos un período mínimo de seis (6) meses desde el anuncio de la obsolescencia para que inicie la actualización a una versión principal compatible. Al finalizar este período, se aplicará una actualización automática a la siguiente versión principal en todas las instancias que continúen ejecutando la versión obsoleta, durante sus períodos de mantenimiento programadas.

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

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

Paga solo por lo que utiliza y no hay tarifas mínimas ni costos de configuración. La 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 parciales de uso de la instancia de base de datos se facturan en incrementos de un segundo, con un cargo mínimo de 10 minutos después de un cambio a un estado facturable, como crear, iniciar o modificar la clase de la 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 aprovisionado dentro del mes, la factura se prorrateará.
• 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)
• E/S por segundo aprovisionadas al mes: la tasa de E/S por segundo aprovisionadas, independientemente de las E/S por segundo que se consuman (solo para almacenamiento SSD de E/S por segundo aprovisionadas de Amazon RDS).
• Almacenamiento de copias de seguridad: corresponde al almacenamiento asociado con las copias de seguridad automatizadas de la base de datos y con cualquier instantánea de base de datos iniciada por el cliente. Aumentar el período de retención de copias de seguridad o generar instantáneas adicionales de la base de datos incrementa el almacenamiento de copias de seguridad consumido por la base de datos.
• Transferencia de datos: transferencia de datos de Internet desde la instancia de base de datos y hacia esta.

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 base de datos se termina, lo cual ocurre cuando se elimina o en caso de una falla 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 ya no desea que se cobre por la instancia de base de datos, debe detenerla o eliminarla para evitar la facturación de horas adicionales de instancia. Las horas parciales de uso de la instancia de base de datos se facturan en incrementos de un segundo, con un cargo mínimo de 10 minutos después de un cambio a un estado facturable, como crear, iniciar o modificar la clase de la instancia de base de datos.

Mientras la instancia de base de datos está detenida, se cobra por el almacenamiento aprovisionado (lo cual incluye E/S por segundo aprovisionadas) y por el almacenamiento de copias de seguridad (incluidas las instantáneas manuales y las copias de seguridad automatizadas dentro del período de retención que haya especificado), pero no por las horas de la 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 la 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 la 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 (incluidos los registros de transacciones) se replican de forma georredundante en varias zonas de disponibilidad para ofrecer niveles aún mayores de durabilidad de los datos. El precio del almacenamiento de copias de seguridad que excede la asignación gratuita refleja esta replicación adicional que se realiza para maximizar la durabilidad de las copias de seguridad críticas.

Si especifica que la instancia de base de datos debe ser una implementación multi-AZ, se 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 implementación 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 implementación entre estándar y Multi-AZ en un plazo inferior a una hora, se le cobrará la mayor de las tarifas de almacenamiento aplicables para 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. Las copias de seguridad 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 que ocurran durante la replicación de datos entre la instancia principal y la instancia en espera. La transferencia de datos por Internet hacia y desde la instancia de base de datos se cobra de la misma manera que en una implementación 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.

La oferta del nivel gratuito de AWS para Amazon RDS proporciona el uso gratuito de instancias de base de datos Micro de una sola zona de disponibilidad que ejecutan MySQL, MariaDB, PostgreSQL y SQL Server Express Edition. El nivel de uso gratuito ofrece hasta 750 horas de instancia al mes. Los clientes también reciben 20 GB de almacenamiento de base de datos de uso general (SSD) y 20 GB de almacenamiento de copias de seguridad gratuitos por 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 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 utilizar hasta 750 horas de instancia de instancias Micro que ejecuten MySQL, PostgreSQL o SQL Server Express Edition. Cualquier uso que exceda las 750 horas de instancia, considerando todas las instancias de base de datos Micro de Amazon RDS de zona única y todos los motores de base de datos y regiones aptos, se facturará según los precios estándar de Amazon RDS.

Cualquier hora de la instancia que exceda el límite del nivel gratuito 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 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 (RI): sin pago inicial, pago inicial parcial y pago inicial total, las cuales permiten equilibrar el monto que paga por adelantado con el precio efectivo por hora.

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. Esto significa que, incluso si la capacidad es limitada en una zona de disponibilidad, aún es posible comprar reservas en la región y el descuento se aplicará al uso coincidente en cualquier zona de disponibilidad dentro 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.

Simplemente adquiera una reserva de instancia de base de datos con la misma clase de instancia, el mismo motor de base de datos, la misma opción de Multi-AZ y el mismo modelo de licencia, dentro de la misma región que la instancia de base de datos que ejecuta actualmente y que desea reservar. Si la compra de la reserva se realiza correctamente, Amazon RDS aplicará automáticamente su nuevo cargo por uso por hora a la instancia de base de datos existente.

Los cambios de precios asociados con una instancia reservada se activan una vez que se recibe la solicitud, mientras se procesa la autorización de pago. Puede seguir el estado de la reserva en la página de Actividad de la cuenta de AWS o mediante la API DescribeReservedDBInstances o el comando describe-reserved-db-instances. Si el pago único no se puede autorizar correctamente para el siguiente período de facturación, el precio con descuento no entrará en vigor.

Cuando finalice el plazo de su reserva, la instancia reservada volverá a la tarifa de uso por hora correspondiente a las instancias bajo demanda para la clase de instancia de base de datos y la región.

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 el importe de la factura, nuestro sistema aplicará de forma automática las reservas de modo que todas las instancias de base de datos que cumplan los requisitos se cobren a la tarifa por hora 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 que se estén ejecutando con las opciones de implementación 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 la reserva, las tarifas de uso por hora correspondientes a esa 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 se puede modificar. No obstante, las reservas se pueden utilizar en cualquiera de las zonas de disponibilidad disponibles dentro de la región asociada.

Sí. Cuando adquiere una instancia reservada, puede seleccionar la opción Multi-AZ en la configuración de la instancia de base de datos disponible para la compra. 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 se puede aplicar 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 la factura, nuestro sistema aplicará de forma automática las reservas de modo que todas las instancias de base de datos que cumplan los requisitos se cobren según la tarifa por hora reducida de las instancias reservadas.

No, no puede cancelar la instancia de base de datos reservada y el pago único (si procede) no es reembolsable. Pagará por cada hora durante el plazo de la instancia de base de datos reservada, sin importar si la utiliza o no.

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. Efectúa un pequeño pago inicial y se le facturará una tarifa horaria baja por cada hora del 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 computación, 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 computación y la capacidad de almacenamiento asignados a la 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 Modificar), la API de Amazon RDS o la Interfaz de la 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 la 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 para SQL Server más antiguas no sean aptas 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 el 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 la instancia de base de datos se puede aumentar sin afectar la disponibilidad de la instancia de base de datos. Sin embargo, cuando decida escalar o desescalar verticalmente los recursos de computación 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 se debe aplicar de forma inmediata.

Amazon RDS admite diversas clases de instancia de base de datos y asignaciones de almacenamiento para satisfacer diferentes necesidades de aplicaciones. Si la 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 los 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 E/S por segundo/GB y capacidad para cargas de trabajo variables de hasta 3 ​000 E/S por segundo, esta opción de almacenamiento ofrece un rendimiento predecible para satisfacer las necesidades de la mayoría de las aplicaciones.

La opción de almacenamiento de E/S por segundo 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 E/S por segundo aprovisionadas (SSD) de Amazon RDS, especifica una tasa de E/S por segundo 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 E/S por segundo 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 la carga de trabajo.

• Cargas de trabajo de OLTP de alto rendimiento: almacenamiento de E/S por segundo 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 E/S por segundo 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 realizar copias de seguridad y restaurar las instancias de bases de datos: copias de seguridad automáticas e instantáneas de bases de datos.

La característica de copias de seguridad automáticas de Amazon RDS permite la recuperación a un momento dado de la instancia de base de datos. Cuando las copias de seguridad automáticas están activadas en la instancia de base de datos, Amazon RDS realiza automáticamente una instantánea diaria completa de los datos (durante el periodo de copia de seguridad que prefiera) y captura registros de transacción (a medida que se realizan actualizaciones de la 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 dentro del 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 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 se pueden crear 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 “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 las instantáneas "automated" (automáticas) también incluye la hora (en UTC) a la que se realizó la instantánea.

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 se hace para permitir crear varias instancias de base de datos a partir de una copia de seguridad específica o de un momento determinado.

De forma predeterminada, Amazon RDS permite las copias de seguridad automáticas de la 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 se puede establecer en 0 si la instancia de base de datos es un origen 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 periodo de copia de seguridad preferido es aquel que define el usuario y durante el cual se realiza la copia de seguridad de la 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. Las operaciones de E/S no se interrumpen en el caso de implementaciones de bases de datos Multi-AZ, ya que la copia de seguridad se realiza a partir la instancia en espera.

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 en que se retienen las copias de seguridad automatizadas al modificar el parámetro RetentionPeriod. Si desea desactivar de forma conjunta las copias de seguridad automáticas, puede definir el periodo de retención en cero (no se recomienda). Puede administrar las instantáneas de base de datos que crea desde la sección “Instantáneas” de la consola de Amazon RDS. De manera alternativa, puede ver una lista de las instantáneas creadas por el usuario para una instancia de base de datos mediante la API DescribeDBSnapshots o con el comando describe-db-snapshots, y puede eliminar instantáneas con la API DeleteDBSnapshot o con el comando delete-db-snapshot.

Es normal que la cantidad de instantáneas automatizadas de la base de datos supere en una o dos el número de días del período de retención. Se retiene una copia de seguridad automatizada adicional para garantizar la posibilidad de realizar una restauración a un momento específico dentro de cualquier punto del período de retención.

Por ejemplo, si el periodo de copias de seguridad está configurado en 1 día, necesitará dos instantáneas automatizadas para permitir restauraciones a cualquier momento dentro de las 24 horas anteriores. También puede ver una instantánea automatizada adicional, ya que siempre se crea una nueva instantánea automatizada antes de que se elimine la más antigua.

Cuando elimina una instancia de base de datos, puede crear una instantánea final al momento de la eliminación; si lo hace, podrá usar esa instantánea para restaurar la instancia eliminada en una fecha posterior. Amazon RDS retiene esta última instantánea creada por el usuario junto con todas las demás instantáneas creadas manualmente después de la eliminación de la instancia de base de datos. Consulte la página de precios para obtener detalles sobre los costos del almacenamiento de copias de seguridad.

Las copias de seguridad automatizadas se eliminan cuando se elimina la instancia de base de datos. Solo se retienen las instantáneas de bases de datos creadas manualmente después de la eliminación de la instancia de base de datos.

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 red para que se asemeje de forma muy cercana 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 orientada al público para los servidores web, con acceso a Internet, y ubicar las instancias de base de datos de Amazon RDS del backend en una subred orientada al uso privado, 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 la 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 aplicación de parches de 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 base de datos es un conjunto de subredes que puede designar para las instancias de base de datos de Amazon RDS dentro de 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 la 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 las implementaciones 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 las implementaciones Single-AZ, en caso de que desee convertirlas en implementaciones 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 las 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 de EC2 se implementan en una subred pública con direcciones IP elásticas asociadas, puede obtener acceso a las instancias de EC2 a través de Internet. Es posible acceder a las instancias de bases de datos implementadas 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 la 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 alojamiento bastión para permitir el acceso a las instancias.

También puede configurar una puerta de enlace de VPN que extienda la red corporativa a la 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 la instancia de base de datos no está en la VPC, puede usar la Consola de administración de AWS para trasladar la instancia de base de datos a una VPC con facilidad. Para obtener más información, 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. Para ello, especifique el grupo de subred de base de datos que desea utilizar. Otra opción es realizar también una operación de restauración a un momento dado.

No se admite la migración de instancias de base de datos desde una VPC 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 de restauración a un momento dado. 

Su responsabilidad consiste en modificar las tablas de enrutamiento y las ACL de red de la VPC para garantizar que se pueda acceder a la instancia de base de datos desde las instancias de cliente en la VPC. En el caso de las implementaciones multi-AZ, es posible que, después de una conmutación por error, la instancia de EC2 cliente y la instancia de base de datos de Amazon RDS estén en diferentes zonas de disponibilidad. Debe configurar las ACL de redes para garantizar que sea posible la comunicación entre las zonas de disponibilidad.

Un grupo de subredes de base de datos existente se puede actualizar para agregar más subredes, ya sea para zonas de disponibilidad existentes o para zonas de disponibilidad nuevas incorporadas después de la creación de la instancia de base de datos. La eliminación de subredes de un grupo de subredes de base de datos existente puede provocar falta de disponibilidad para las instancias si estas se ejecutan en una zona de disponibilidad que se elimine 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 la instancia de base de datos.

Para MySQL, los privilegios predeterminados para el usuario principal incluyen: crear, descartar, referencias, evento, alterar, borrar, índice, insertar, seleccionar, actualizar, crear tablas temporales, bloquear tablas, desencadenador, crear vista, mostrar vista, alterar rutina, crear rutina, ejecutar, desencadenador, crear usuario, proceso, mostrar bases de datos y opción de concesión.

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.

En el caso de SQL Server, a un usuario que crea una base de datos se le otorga el rol “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 administre por su cuenta.

Sí. Debe activar deliberadamente la capacidad para obtener acceso a la base de datos a través de Internet mediante la configuración de grupos de seguridad. Puede autorizar el acceso solo para las direcciones IP, los rangos de IP o las subredes que correspondan a 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 la 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. La compatibilidad con SSL/TLS en Amazon RDS sirve para cifrar la conexión entre la aplicación y la instancia de base de datos; no se debe utilizar como mecanismo para autenticar la instancia de base de datos.

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

Amazon RDS admite el cifrado en reposo para todos los motores de base de datos, mediante claves administradas por usted a través de AWS Key Management Service (KMS). En una instancia de base de datos que se ejecuta con el cifrado de Amazon RDS, los datos almacenados en reposo en el almacenamiento subyacente están cifrados, al igual que sus copias de seguridad automatizadas, las réplicas de lectura y las instantáneas. El cifrado y el descifrado se realizan 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 agregar cifrado a una instancia de base de datos o a un clúster de base de datos que no tuvieran cifrado previamente mediante la creación de una instantánea de la base de datos y, después, la creación de una copia de esa instantánea y especificación de una clave de cifrado de KMS. Luego puede restaurar una instancia o un 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 realizar 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 realizar 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 la cuenta y entrega los archivos de registro. El historial de llamadas a la API de AWS creado por CloudTrail permite realizar un análisis de seguridad, un seguimiento de los cambios en los recursos y auditorías de cumplimiento. 

Sí, todos los motores de bases de datos de Amazon RDS cumplen 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 médica, incluida la información de salud protegida (PHI), en virtud de un acuerdo de asociación empresarial (BAA) suscrito con AWS.

Si ya ha suscrito 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 suscrito con AWS, o si tiene preguntas acerca de las aplicaciones que cumplen con HIPAA en AWS, contacte al administrador de la cuenta.

De forma predeterminada, Amazon RDS elige los parámetros de configuración óptimos para la 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 la línea de comandos de AWS. Tenga en cuenta que modificar los parámetros de configuración respecto a los valores recomendados puede generar efectos no deseados, que van desde una disminución del rendimiento hasta fallos del sistema. Solo debe hacerlo si es un usuario avanzado dispuesto a asumir estos riesgos.

Un grupo de parámetros de base de datos actúa como un “contenedor” de configuración del motor que se puede aplicar a una o varias instancias de base 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 recibirán todas las actualizaciones de parámetros que se apliquen a ese grupo.

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 crea o modifica la instancia de base de datos para que se ejecute como una implementación Multi-AZ, Amazon RDS aprovisiona y mantiene de forma automática una réplica en espera sincrónica en una zona de disponibilidad diferente. Las actualizaciones de la instancia de base de datos se replican de manera síncrona entre las zonas de disponibilidad hacia la instancia en espera, con el fin de mantener ambas sincronizadas y proteger las actualizaciones más recientes frente a una falla de la instancia de base de datos. 

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 se puede utilizar para atender tráfico de lectura. Puede obtener más información sobre las implementaciones 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 un despliegue 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. No interactúa directamente con la instancia en espera (por ejemplo, para operaciones de lectura) en ningún momento antes de que se conviertan 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 un despliegue Multi-AZ son la mejora de la durabilidad y la disponibilidad de la base de datos. El mayor nivel de disponibilidad y tolerancia a errores que ofrecen las implementaciones Multi-AZ las 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 en una única zona de disponibilidad, donde 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 en la 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 el contexto de Amazon RDS, esto significa que no se requiere que supervise los eventos de la instancia de base de datos ni que inicie una recuperación manual de la instancia (mediante las API RestoreDBInstanceToPointInTime o RestoreDBInstanceFromSnapshot) en caso de una falla de la zona de disponibilidad o de la instancia de base de datos.

Es posible que observe latencias más altas en comparación con una implementación estándar de instancia de base de datos en una sola zona de disponibilidad, como resultado de la replicación síncrona de datos que se realiza en su nombre.

No. Una instancia en espera de 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 instancia principal y la instancia en espera se mantengan constantemente sincronizadas, pero no permite usar la instancia en espera para operaciones de lectura ni escritura. Si le interesa una solución para escalar lecturas, consulte las preguntas frecuentes sobre Réplicas de lectura.

Para crear una implementación Multi-AZ para una instancia de base de datos, simplemente seleccione la opción “Sí” para “Implementación Multi-AZ” al lanzar una instancia de base de datos desde la Consola de administración de AWS.

De forma alternativa, si utiliza las API de Amazon RDS, puede llamar a la operación CreateDBInstance y establecer el parámetro “MultiAZ” en “verdadero”. Para convertir una instancia de base de datos estándar existente (de una sola zona de disponibilidad) en Multi-AZ, modifique la instancia en la Consola de administración de AWS o utilice la operación ModifyDBInstance y establezca el parámetro MultiAZ en verdadero.

Para los motores de base 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 la instancia de Amazon RDS de una implementación Single-AZ a Multi-AZ, ocurre lo siguiente:

• Se genera una instantánea de la 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, es posible que observe un aumento en la latencia mientras los datos de la instancia en espera se sincronizan para igualarse con la principal.

Los despliegues 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 con la instancia principal
• Error de unidad informática en la instancia
• Error de almacenamiento en la instancia primaria

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, el impacto en la disponibilidad se ve limitada solo al tiempo necesario para que se complete la conmutación por error automática. Tenga en cuenta que las implementaciones Multi-AZ de Amazon RDS no realizan conmutación por error de manera automática en respuesta a operaciones de base de datos, como consultas de larga duración, bloqueos o errores de corrupción de la base de datos.

Sí. Amazon RDS emitirá un evento de instancia de base de datos para informarle que se produjo una conmutación por error automática. Puede hacer clic en la sección “Eventos” de la consola de Amazon RDS o usar la API DescribeEvents para obtener información sobre eventos relacionados con la instancia de base de datos. También puede utilizar Notificaciones de eventos de Amazon RDS para recibir avisos cuando ocurran eventos específicos de instancias de 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 sugerimos 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 también recomienda utilizar E/S por segundo aprovisionadas con instancias Multi-AZ, para lograr un rendimiento de E/S rápido, predecible y uniforme.

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 acceder a esta característica desde la Consola de administración de AWS o mediante la llamada a la API RebootDBInstance.

En los despliegues 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 instancia en espera se aprovisiona automáticamente en una zona de disponibilidad distinta, pero dentro de la misma región que la instancia de base de datos principal.

Sí, puede obtener visibilidad sobre la ubicación de la instancia principal actual mediante 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 dentro de la misma región. Además, es posible que desee considerar 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 resiliente en caso de producirse un error en una zona de disponibilidad. Las implementaciones Multi-AZ satisfacen esta necesidad para la capa de base de datos sin requerir administración de su parte.

Usted interactúa con la copia de seguridad automatizada y la funcionalidad DB Snapshot de la misma manera si está ejecutando un despliegue estándar en un despliegue Single-AZ o 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 procesos de respaldo tanto para las implementaciones Single-AZ como 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". Estas nuevas implementaciones de instancias de base de datos pueden ser estándar o Multi-AZ, independientemente de si la copia de seguridad de origen se inició en una implementación estándar o en una implementación Multi-AZ.

Las réplicas de lectura hacen más sencillo aprovechar la funcionalidad de replicación integrada de los motores compatibles para escalar horizontalmente y superar las limitaciones de capacidad de una única instancia de base de datos en cargas de trabajo con un volumen alto de lecturas.

Puede crear una réplica de lectura con unos pocos clics en la Consola de administración de AWS o mediante la API CreateDBInstanceReadReplica. Una vez que la réplica de lectura está creada, las actualizaciones en la instancia de base de datos de origen se replican mediante la replicación asincrónica nativa del motor compatible. 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 se pueden asociar con implementaciones Multi-AZ para obtener beneficios de escalado de lectura, además de la mayor disponibilidad de escritura y la durabilidad que proporcionan las implementaciones Multi-AZ.

Existen diversos casos en los que implementar una o más réplicas de lectura para una instancia de base de datos de origen puede resultar adecuado. 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.
• También puede usar una réplica de lectura para la recuperación ante desastres de la instancia de base de datos de origen, ya sea en la misma región de AWS o en otra región.

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. Las copias de seguridad deben permanecer habilitadas para que las réplicas de lectura funcionen.

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 la edición Enterprise en configuraciones Multi-AZ cuando la tecnología de replicación subyacente usa grupos de disponibilidad Always On, para las versiones 2016 y 2017 de SQL Server.

Puede crear una réplica de lectura en cuestión de minutos mediante la API estándar CreateDBInstanceReadReplica o unos pocos 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 también trabaja actualmente en una optimización (que se publicará en breve) para que, si crea varias réplicas de lectura dentro de un periodo de 30 minutos, todas utilicen la misma instantánea de origen a fin de minimizar el impacto de E/S. La replicación de “puesta al día” para cada réplica de lectura comenzará después de la creación.

Se puede conectar a una réplica de lectura igual que a una instancia estándar de base de datos, con la API DescribeDBInstance o la Consola de administración de AWS para obtener los puntos de conexión de la réplica de lectura. Si tiene varias réplicas de lectura, la aplicación es la responsable de determinar cómo se distribuye el tráfico de lectura 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 cinco réplicas de lectura para 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 para 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, recomendamos que ejecute la 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 supervisa 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 proporciona mayor disponibilidad para las escrituras y una mayor durabilidad de los datos, y la réplica de lectura asociada mejoraría la capacidad de escalar el tráfico de lectura.

Sí. Amazon RDS para MySQL, MariaDB, PostgreSQL y Oracle permiten habilitar la configuración Multi-AZ en las réplicas de lectura para admitir la recuperación ante desastres y minimizar el tiempo de inactividad durante las actualizaciones del motor.

En caso de una conmutación por error Multi-AZ, cualquier réplica de lectura asociada y disponible reanudará automáticamente la replicación una vez completada la conmutación, obteniendo las actualizaciones de la nueva instancia convertida en 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 atender 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 en una instancia de base de datos de origen se replicarán automáticamente en cualquier réplica de lectura asociada. 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 desfase entre una réplica de lectura y su instancia de base de datos de origen o "inconsistencia".

Usted puede usar la API estándar DescribeDBInstances para obtener una lista de todas las instancias de base de datos que haya implementado (incluidas las réplicas de lectura) o simplemente hacer clic en la pestaña “Instancias” de la consola de Amazon RDS.

Amazon RDS permite obtener visibilidad sobre cuánto se ha retrasado una réplica de lectura con respecto a la 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). Para revisar los detalles del error asociado generado por el motor de MySQL, consulte el campo Error de replicación. Tome las medidas correspondientes para recuperarse de dicho error. Puede obtener más información sobre la resolución de problemas de replicación en la sección 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 corrige un error de replicación, el estado de replicación cambia a Replicación en curso.

Para que la replicación funcione de manera eficaz, recomendamos que las réplicas de lectura cuenten con tantos o más recursos de computación y almacenamiento que sus respectivas instancias de base de datos de origen. De lo contrario, es probable que aumente el desfase de replicación o que la réplica de lectura se quede sin espacio para almacenar las actualizaciones replicadas.

Puede eliminar una réplica de lectura en unos pocos pasos desde la Consola de administración de AWS o si envía el identificador de instancia de base de datos a la API DeleteDBInstance. 

Una réplica de Amazon Aurora permanece activa y sigue aceptando tráfico de lectura incluso después de que la instancia de base de datos de origen haya sido eliminada. 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 de origen, debe hacerlo explícitamente mediante la API DeleteDBInstance o la Consola de administración de AWS.

Las réplicas de lectura se facturan igual que una instancia estándar de base de datos, con las mismas tarifas. La tarifa por “hora de instancia de base de datos” para una réplica de lectura se determina según la clase de instancia de la propia réplica. Consulte la página de precios para obtener la información más reciente. No se cobra por la transferencia de datos generada durante la replicación entre la instancia de base de datos de origen y la réplica de lectura cuando ambas se encuentran en la misma región de AWS.

La facturación de una réplica de lectura comienza en cuanto la réplica se ha creado correctamente (es decir, cuando su estado aparece como “activa”). La réplica de lectura seguirá generando cargos según las tarifas estándar por hora de instancia de base de datos de Amazon RDS hasta que emita la orden de eliminarla.

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

La Supervisión mejorada para Amazon RDS ofrece una visibilidad más profunda del estado de las instancias de Amazon RDS. Solo necesita activar la opción Supervisión mejorada para la instancia de base de datos de Amazon RDS y establecer un nivel de detalle; a partir de ello, la Supervisión mejorada recopilará métricas esenciales del sistema operativo e información de procesos con el nivel de detalle definido.

Si necesita un análisis más detallado, una mejor visualización de la carga de la base de datos y un periodo de retención más amplio, puede recurrir a Información de rendimiento.

Las principales ventajas de Información de CloudWatch Database Insights incluyen:

1. Recopilación de telemetría sin esfuerzo: recopila automáticamente las métricas, los registros y los seguimientos de la base de datos, lo que minimiza el tiempo de configuración

2. Información selecta: proporciona paneles, alarmas e información prediseñados para supervisar y optimizar el rendimiento de la base de datos, con una configuración mínima necesaria para comenzar.

3. Vista unificada de CloudWatch: combina la telemetría de varias bases de datos en una sola vista para simplificar la supervisión

4. Capacidades de IA y ML: utiliza IA y ML para detectar anomalías, lo que reduce los esfuerzos manuales de solución de problemas

5. Supervisión del contexto de la aplicación: permite a los usuarios establecer correlaciones entre el rendimiento de la base de datos y el rendimiento de la aplicación.

6. Vistas a nivel de flota e instancia: ofrece tanto supervisión de flota de alto nivel como vistas detalladas de instancias para realizar análisis de la causa raíz

7. Integración sin problemas con AWS: se integra con Amazon CloudWatch Application Signals y AWS X-Ray, lo que permite una experiencia de observabilidad integral

Supervisión mejorada recopila las métricas de sistema de las instancias de Amazon RDS, como la CPU, la memoria, el sistema de archivos y la E/S de disco, entre otras. La lista completa de métricas está disponible en la documentación.

Supervisión mejorada es compatible con todos los motores de base de datos de Amazon RDS.

Supervisión mejorada es compatible con 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. En el caso de las instancias de base de datos que no son de producción, el valor predeterminado de Supervisión mejorada es desactivado, y puede optar por dejarla desactivada o ajustar el nivel de detalle cuando esté habilitada.

En la consola puede ver todas las métricas del sistema y la información de procesos de las instancias de base de datos de Amazon RDS en formato gráfico. Puede administrar qué métricas desea supervisar para cada instancia y personalizar el panel según sus necesidades.

No. Puede definir diferentes niveles de detalle para cada instancia de base de datos en la cuenta de Amazon RDS. También puede elegir en qué instancias desea habilitar Supervisión mejorada, así como modificar el nivel de detalle de cualquier instancia en el momento que lo necesite.

Puede ver los valores de rendimiento de todas las métricas hasta una hora hacia atrás, con un nivel de detalle de hasta un segundo según la configuración que haya definido.

Las métricas generadas por la Supervisión mejorada de Amazon RDS se entregan en la cuenta de Registros de CloudWatch. Puede crear filtros de métricas en CloudWatch a partir de Registros de CloudWatch y mostrar los gráficos en el panel de CloudWatch. Para obtener más información, visite la página de Amazon CloudWatch.

Debe usar CloudWatch si desea ver datos históricos más allá de lo que está disponible 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. Actualmente, CloudWatch admite niveles de detalle de hasta 1 minuto, y los valores se promedian cuando el nivel de detalle es inferior a ese intervalo.

Sí. Puede crear una alarma en CloudWatch que envíe una notificación cuando cambie el estado de la alarma. La alarma supervisa una única métrica durante un periodo de tiempo que especifique y ejecuta una o más acciones en función del valor de la métrica en relación con el umbral definido durante varios periodos. Para obtener más detalles sobre las alarmas de CloudWatch, visite la Guía para desarrolladores de Amazon CloudWatch.

Supervisión mejorada de Amazon RDS proporciona un conjunto de métricas en formato de cargas útiles JSON que se entregan en la cuenta de Registros de CloudWatch. Estas cargas JSON se entregan con el último nivel de pormenorización configurado para la instancia de Amazon RDS.

Hay dos formas de consumir estas métricas a través de un panel o aplicación de terceros. Las herramientas de supervisión pueden usar las suscripciones de Registros de CloudWatch para configurar una fuente de métricas casi en tiempo real. Como alternativa, puede usar filtros en Registros de CloudWatch para transferir las métricas hacia CloudWatch e integrar la aplicación con CloudWatch. Para obtener más información, visite la documentación de Amazon CloudWatch.

Dado que Supervisión mejorada entrega cargas útiles JSON en un registro de la cuenta de Registros de CloudWatch, puede controlar su periodo de retención igual que con cualquier otra secuencia de Registros de CloudWatch. El periodo de retención predeterminado configurado para Supervisión mejorada en Registros de CloudWatch es de 30 días. Para obtener detalles sobre cómo cambiar la configuración de retención, visite la Guía para desarrolladores de Amazon CloudWatch.

Dado que las métricas se ingieren en Registros de CloudWatch, los cargos se basarán en las tarifas de transferencia de datos y almacenamiento de Registros de CloudWatch una vez que supere el nivel gratuito de Registros de CloudWatch. Los detalles de precios están disponibles aquí. La cantidad de información transferida para una instancia de Amazon RDS es directamente proporcional al nivel de detalle definido para la característica de Supervisión mejorada. Los administradores pueden establecer distintos niveles de pormenorización para diferentes instancias en sus cuentas y así administrar los costos.

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

Información de rendimiento de Amazon RDS es una característica de ajuste y supervisión del rendimiento de las bases de datos que le permite a los clientes acceder a la carga de las bases de datos y determinar cuándo y dónde tomar las medidas oportunas.

CloudWatch Database Insights es una nueva característica de observabilidad para bases de datos que incorpora todas las capacidades de Información de rendimiento, junto con la supervisión a nivel de flota, la integración con la supervisión del rendimiento de aplicaciones y la correlación de métricas de bases de datos con registros y eventos.

Amazon RDS Proxy es una característica completamente administrada y de alta disponibilidad que actúa como un proxy de base de datos para Amazon RDS. RDS Proxy hace que las aplicaciones sean más escalables, más resilientes ante fallos de base de datos y más seguras.

Amazon RDS Proxy es una característica de proxy de base de datos completamente administrada, altamente disponible y fácil de usar para Amazon RDS, que permite a las aplicaciones: 1) mejorar la escalabilidad mediante la agrupación y el uso compartido de las conexiones a la base de datos; 2) mejorar la disponibilidad al reducir los tiempos de conmutación por error hasta un 66 % y preservar las conexiones de la aplicación durante las conmutaciones por error; y 3) mejorar la seguridad al aplicar opcionalmente la autenticación de AWS IAM a las bases de datos y almacenar de forma segura las credenciales en AWS Secrets Manager.

Amazon RDS Proxy cubre varios casos de uso relacionados con la escalabilidad, la disponibilidad y la seguridad de las aplicaciones, entre ellos:

Aplicaciones con cargas de trabajo impredecibles: las aplicaciones que manejan cargas muy variables pueden intentar abrir ráfagas de nuevas conexiones a la base de datos. La gobernanza de la conexión de Amazon RDS Proxy le permite escalar con facilidad las aplicaciones que se ocupan de cargas de trabajo impredecibles mediante la reutilización eficiente de las conexiones de la base de datos. Primero, el proxy de RDS permite que múltiples conexiones de aplicaciones compartan una conexión de base de datos para un uso eficiente de los recursos de la base de datos. En segundo lugar, el proxy de RDS permite mantener un rendimiento predecible de la base de datos por medio de la regulación de la cantidad de conexiones de base de datos que se abren. En tercer lugar, el proxy RDS elimina las solicitudes que no se pueden atender para preservar el rendimiento y la disponibilidad general de la aplicación.

Aplicaciones que abren y cierran conexiones de bases de datos con frecuencia: las aplicaciones creadas con tecnologías como sin servidor, PHP o Ruby on Rails pueden abrir y cerrar conexiones de bases de datos con frecuencia para atender solicitudes de aplicaciones. Amazon RDS Proxy mantiene un conjunto de conexiones de base de datos para evitar un estrés innecesario en el cálculo de la base de datos y la memoria para establecer nuevas conexiones.

Aplicaciones que mantienen las conexiones abiertas pero inactivas: las aplicaciones en industrias como SaaS o eCommerce pueden mantener las conexiones de la base de datos inactivas para minimizar el tiempo de respuesta cuando un cliente vuelve a participar. En lugar de sobre aprovisionar bases de datos para admitir principalmente conexiones inactivas, puede usar Amazon RDS Proxy para mantener las conexiones inactivas mientras solo establece conexiones de base de datos según sea necesario para atender de manera óptima las solicitudes activas.

Aplicaciones que requieren disponibilidad a través de fallas transitorias: con Amazon RDS Proxy, puede crear aplicaciones que puedan tolerar de manera transparente las fallas de la base de datos sin necesidad de escribir código complejo de manejo de fallas. El proxy de RDS dirige automáticamente el tráfico a una nueva instancia de base de datos a la vez que se preservan las conexiones de la aplicación. El proxy de RDS también evita las cachés del sistema de nombres de dominio (DNS) para reducir los tiempos de conmutación por error hasta un 66 % para las bases de datos Multi-AZ de Amazon RDS y Aurora. Durante la conmutación por error de la base de datos, la aplicación puede experimentar latencias más altas y es posible que las transacciones en curso deban repetirse.

Seguridad mejorada y administración centralizada de credenciales: Amazon RDS Proxy lo ayuda a crear aplicaciones más seguras, ya que brinda la opción de aplicar la autenticación basada en IAM con bases de datos relacionales. RDS Proxy también permite administrar de manera centralizada las credenciales de la base de datos a través de 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 la aplicación no puede tolerar 5 milisegundos de latencia o no necesita la administración de conexiones ni otras características que ofrece RDS Proxy, puede preferir que la aplicación se conecte directamente al punto de conexión de la base de datos.

Amazon RDS Proxy transforma la forma en que crea aplicaciones sin servidor modernas que aprovechan la potencia y la simplicidad de las bases de datos relacionales. En primer lugar, RDS Proxy permite que las aplicaciones sin servidor escalen de forma eficiente mediante la agrupación y reutilización de conexiones a 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. RDS Proxy está completamente administrado y escala su capacidad automáticamente en función de las demandas de la aplicación.

RDS Proxy está disponible para Amazon Aurora con compatibilidad con MySQL, Amazon Aurora con compatibilidad con PostgreSQL, Amazon RDS para MariaDB, Amazon RDS para MySQL, Amazon RDS para PostgreSQL y Amazon RDS para SQL Server. Para consultar la lista de versiones de motor compatibles, vea 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 la base de datos de Amazon RDS y configurar una función de Lambda para acceder a esta 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 '…'

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

Las extensiones de PostgreSQL se ejecutan en el mismo espacio de procesos para lograr un alto rendimiento. Sin embargo, las extensiones pueden tener defectos de software que pueden provocar fallos en la base de datos.

Las extensiones de lenguaje de confianza para PostgreSQL ofrecen varias capas de protección para mitigar este riesgo. Las extensiones de lenguaje de confianza están diseñadas para limitar el acceso a los recursos del sistema. El rol rds_superuser puede determinar quién tiene permiso para instalar extensiones específicas. Sin embargo, estos cambios solo se pueden realizar a través de la API de extensiones de lenguaje de confianza. Las extensiones de lenguaje de confianza están diseñadas para limitar el impacto de un defecto de una extensión a una única conexión de base de datos. Además de estas barreras de protección, las extensiones de lenguaje de confianza están diseñadas para proporcionar a los administradores de bases de datos con el rol rds_superuser un control en línea y detallado sobre quién puede instalar extensiones, y les permiten crear un modelo de permisos para su ejecución.

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

Las extensiones de lenguaje de confianza para PostgreSQL están disponibles para Amazon Aurora, edición compatible con PostgreSQL, y para Amazon RDS en PostgreSQL en las versiones 14.5 y superiores. Las extensiones de lenguaje de confianza están implementadas como una extensión de PostgreSQL en sí misma, y puede activarlas desde el rol rds_superuser, de forma similar a otras extensiones compatibles en Aurora y Amazon RDS.

Puede ejecutar extensiones de lenguaje de confianza para PostgreSQL en PostgreSQL 14.5 o superior en Amazon Aurora y Amazon RDS.  

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

Las extensiones de lenguaje de confianza para PostgreSQL están disponibles para los clientes de Aurora y Amazon RDS sin costo adicional.

Aurora y Amazon RDS admiten un conjunto selecto 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 la aplicación. Es responsable de la seguridad de las aplicaciones que utilizan extensiones de lenguaje de confianza.

Puede crear funciones para desarrolladores, como compresión de mapas de bits y protección diferencial de la privacidad (por ejemplo, consultas estadísticas accesibles públicamente que protegen la privacidad de los individuos).

Las extensiones de lenguaje de confianza 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 lenguaje de confianza y utilizar extensiones específicas.

Las extensiones de lenguaje de confianza para PostgreSQL acceden a la base de datos PostgreSQL exclusivamente mediante la API de extensiones de lenguaje de confianza. Los lenguajes de confianza compatibles incluyen todas las funciones de la interfaz de programación del servidor de PostgreSQL (SPI), así como compatibilidad con los enlaces de PostgreSQL, incluido el enlace de verificación de contraseñas.

Puede obtener más información sobre el proyecto de extensiones de lenguaje de confianza para PostgreSQL en la página oficial del proyecto en 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. 

Las implementaciones azul-verde de Amazon RDS están disponibles para Amazon Aurora, edición compatible con MySQL, en las versiones 5.6 y superiores; para Amazon RDS para MySQL, en las versiones 5.7 y superiores; y para Amazon RDS para MariaDB, en las versiones 10.2 y superiores. Las implementaciones azul-verde también son compatibles con Amazon Aurora, edición compatible con PostgreSQL, y con Amazon RDS para PostgreSQL, en las versiones 11.21 y superiores, 12.16 y superiores, 13.12 y superiores, 14.9 y superiores y 15.4 y superiores. Puede obtener más información sobre las versiones disponibles en la documentación de Amazon Aurora y Amazon RDS. 

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

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

Incurrirá en el mismo precio por ejecutar las cargas de trabajo en las instancias verdes que en las instancias azules. El costo de ejecutar instancias azules y verdes incluye nuestra tarifa estándar actual para instancias de base de datos, el costo de almacenamiento, el costo de operaciones de lectura/escritura, y cualquier característica habilitada, como el costo de las copias de seguridad e Información de rendimiento de Amazon RDS. En términos prácticos, paga aproximadamente 2 veces el costo de ejecutar cargas de trabajo en una instancia de base de datos durante el periodo de vida de la implementación azul-verde.

Por ejemplo: tiene una base de datos RDS para MySQL 5.7 en ejecución en dos instancias r5.2xlarge, una instancia principal de base de datos y una réplica de lectura, en la región us-east-1 de AWS, con una configuración Multi-AZ (MAZ). Cada una de las instancias r5.2xlarge está configurada con 20 GiB de Amazon Elastic Block Store (EBS). Crea un clon de la topología de la instancia azul con las implementaciones azul-verde de Amazon RDS, lo ejecuta durante 15 días (360 horas) y luego elimina las instancias azules después de una conmutación por error exitosa. 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 de usar implementaciones azul-verde durante esos 15 días es de 2774 USD, que es 2 veces el costo de ejecutar las instancias azules durante ese mismo 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 las implementaciones azul-verde de Amazon RDS, el entorno azul su actual entorno de producción. El entorno verde es el entorno de ensayo, que será el nuevo entorno de producción después de la conmutación.

Cuando las implementaciones azul-verde de Amazon RDS inician una conmutación, bloquean las escrituras en los entornos azul y verde hasta que se completa la conmutación. Durante la conmutación, el entorno de ensayo, o entorno verde, se actualiza con el sistema de producción, lo que garantiza que los datos sean coherentes entre el entorno de ensayo y el de producción. Una vez que los entornos de producción y ensayo están completamente sincronizados, las implementaciones azul/verde 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 el entorno azul es una réplica lógica autoadministrada o un editor, bloquearemos la conmutación. Se recomienda detener primero la replicación en el entorno azul, continuar con la conmutación y, a continuación, reanudar la replicación. Por el contrario, si su entorno azul es el origen de una réplica lógica autoadministrada o un editor, puede continuar con la conmutación. Sin embargo, tendrá que actualizar la réplica autoadministrada para replicarla desde el entorno verde después de la conmutación.

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

Las barreras de protección de conmutación en las implementaciones azul-verde de Amazon RDS bloquean las escrituras tanto en el entorno azul como en el verde hasta que el entorno verde se ha actualizado por completo, antes de realizar el cambio. Las implementaciones azul/verde también realizan comprobaciones de estado del entorno principal y las réplicas en los entornos azul y verde. Además, realizan comprobaciones del estado de la replicación, por ejemplo, para ver si la replicación se ha detenido o si hay errores. Detectan transacciones de ejecución prolongada entre los entornos azul y verde. Puede especificar 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, las implementaciones azul-verde de Amazon RDS no admiten las 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 contra la pérdida de datos al escribir los datos en páginas de 16 KiB en memoria dos veces en el almacenamiento duradero: primero en el búfer de doble escritura y luego en el almacenamiento de las 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 es compatible con 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, ordenaciones, agregaciones de hash, uniones de carga elevada y expresiones de tabla comunes (CTE). Estos casos de uso generan la creación de tablas temporales, lo que permite que las lecturas optimizadas aceleren el procesamiento de las consultas de la carga de trabajo.

Sí, los clientes pueden convertir la base de datos existente en Amazon RDS para utilizar las lecturas optimizadas de Amazon RDS trasladando la 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 ejecuta la carga de trabajo en instancias db.r5d, db.m5d, db.r6gd, db.m6gd, X2idn y X2iedn ya se beneficia de las lecturas optimizadas.

La integración sin ETL de Amazon RDS permite el análisis y el machine learning (ML) casi en tiempo real de petabytes de datos transaccionales y elimina la necesidad de crear y administrar canalizaciones de datos complejas. En cuestión de segundos después de que los datos se escriben en Amazon RDS, se pueden replicar en el almacén de lago en Amazon Redshift o Amazon SageMaker.

Puede consolidar datos de varias bases de datos y tablas de Amazon RDS en Amazon Redshift o en el almacén de lago de Amazon SageMaker. Según sus necesidades de análisis, el filtrado de datos de bases de datos y tablas específicas ayuda a trasladar selectivamente los datos al destino.

Debe usar la integración sin ETL de Amazon RDS con Amazon Redshift cuando desee eliminar la necesidad de crear y administrar canalizaciones de datos complejas. Una vez que los datos están en el almacén de datos en Amazon SageMaker o Amazon Redshift, tiene acceso a capacidades de análisis y de machine learning (ML) sobre los datos transaccionales.

Paga por Amazon RDS y por los recursos del destino sin ETL utilizados para crear y procesar los datos de cambio generados como parte de una integración sin ETL.

Estos recursos incluyen los costos de exportación de instantáneas de Amazon RDS para inicializar y resincronizar los almacenes de datos de Amazon Redshift o el almacén de lago en Amazon SageMaker, los costos de transferencia de datos de captura de datos de cambio (CDC) para la replicación continua de los cambios de datos desde el origen en el destino, y el uso regular de E/S y almacenamiento de RDS necesario para procesar los datos de cambio.

Para Amazon Redshift, también debe considerar los costos de almacenamiento y computación para los datos replicados. Para SageMaker, debe tener en cuenta el almacenamiento de AWS Glue para almacenar los datos replicados y la computación de SageMaker en el destino. Para obtener más información, consulte las páginas de precios de Amazon RDS. 

Sí, para reducir el consumo de recursos en la instancia principal, puede usar una réplica de lectura de Amazon RDS como la instancia de origen de Amazon RDS para una integración sin ETL.

Sí, puede usar AWS CloudFormation para administrar y automatizar la configuración y la implementación de los recursos necesarios para una integración sin ETL de Amazon RDS. Para obtener más información, visite la guía del usuario de AWS CloudFormation.

Las integraciones sin ETL de Amazon RDS replican transacciones de manera atómica para garantizar la coherencia de datos entre la base de datos de origen en Amazon RDS y el clúster de Amazon Redshift o el almacén de lago en Amazon SageMaker como destino.

A continuación, se presentan algunos puntos clave sobre la atomicidad de las transacciones en esta integración:

• Solo las transacciones confirmadas en Amazon RDS se replican en Amazon Redshift o al almacén de lago en SageMaker; las transacciones no confirmadas o revertidas no se aplican.
• La integración utiliza un proceso de confirmación en dos fases para aplicar cada transacción de forma atómica en Amazon Redshift o en el almacén de lago de SageMaker. Todos los cambios de datos de la transacción se aplican o, si ocurre un error, no se aplica ninguno.
• La coherencia de las transacciones se mantiene entre el origen y el destino. Después de la replicación, los datos de una transacción determinada serán coherentes tanto en Amazon RDS como en el destino.
• Los cambios de esquema mediante DDL o DML también se aplican de forma atómica para mantener la integridad.
• La aplicación atómica de las transacciones garantiza que no se produzcan transacciones parciales ni estados de datos inconsistentes entre las bases de datos.

Las integraciones sin ETL de Amazon RDS mantienen la coherencia transaccional total entre la base de datos de origen en Amazon RDS y el clúster de Amazon Redshift o el almacén de lago en Amazon SageMaker como destino.

A continuación, se presentan algunos puntos clave sobre cómo se manejan los cambios de esquema:

• Las instrucciones DDL como CREAR TABLA, ALTERAR TABLA, DESCARTAR TABLA, etc., se replican automáticamente a partir de Amazon RDS en Amazon Redshift.
• La integración lleva a cabo las comprobaciones y ajustes necesarios en las tablas de Amazon Redshift para los cambios de esquema replicados. Por ejemplo, si se agrega una columna en RDS para MySQL, se agregará la columna en Amazon Redshift.
• La replicación y la sincronización del esquema se realizan automáticamente con un desfase mínimo entre las bases de datos de origen y de destino.

La coherencia del esquema se mantiene incluso cuando los cambios de DML se producen en paralelo con los cambios de DDL.