Uso de Amazon Aurora Serverless v1 - Amazon Aurora
Disponibilidad en regiones y versionesVentajas de Aurora Serverless v1Casos de uso de Aurora Serverless v1Limitaciones de Aurora Serverless v1Requisitos de configuración para Aurora Serverless v1Uso de TLS/SSL con Aurora Serverless v1

Uso de Amazon Aurora Serverless v1

Amazon Aurora Serverless v1 (Amazon Aurora Serverless versión 1) es una configuración de escalado automático en diferido para Amazon Aurora. Un clúster de bases de datos de Aurora Serverless v1 es un clúster de bases de datos que escala la capacidad de cómputo y la disminuye en función de las necesidades de su aplicación. Esto contrasta con los clústeres de base de datos aprovisionados de Aurora, para los que se administra la capacidad de forma manual. Aurora Serverless v1 proporciona una opción rentable y relativamente simple para las cargas de trabajo poco frecuentes, intermitentes o impredecibles. Es rentable porque se inicia automáticamente, escala la capacidad de cómputo en función del uso de la aplicación y se cierra cuando no se utiliza.

Para obtener más información sobre precios, consulte Precios sin servidor en MySQL-Compatible Edition o PostgreSQL-Compatible Edition en la página Amazon Aurora pricing.

Aurora Serverless v1Los clústeres de tienen el mismo tipo de volumen de almacenamiento distribuido de alta capacidad y disponibilidad que utilizan los clústeres de base de datos aprovisionados.

Para un clúster de Aurora Serverless v2, puede elegir si desea cifrar el volumen del clúster.

Para un clúster de Aurora Serverless v1, el volumen del clúster siempre está cifrado. Puede elegir la clave de cifrado, pero no puede desactivar el cifrado. Esto significa que puede realizar en un Aurora Serverless v1 las mismas operaciones que realiza en instantáneas cifradas. Para obtener más información, consulte Aurora Serverless v1 e instantáneas.

Temas
importante

Aurora tiene dos generaciones de tecnología sin servidor: Aurora Serverless v2 y Aurora Serverless v1. Si su aplicación puede ejecutarse en MySQL 8.0 o PostgreSQL 13, le recomendamos utilizar Aurora Serverless v2.Aurora Serverless v2 se escala más rápidamente y de forma más granular.Aurora Serverless v2 también tiene más compatibilidad con otras características de Aurora, como las instancias de base de datos de lectores. Por lo tanto, si ya está familiarizado con Aurora, no tiene que conocer tantos procedimientos nuevos o limitaciones para usar Aurora Serverless v2 como con Aurora Serverless v1.

Puede obtener más información sobre Aurora Serverless v2 en Uso de Aurora Serverless v2.

Disponibilidad en regiones y versiones

La disponibilidad de las características varía según las versiones específicas de cada motor de base de datos de Aurora y entre Regiones de AWS. Para obtener más información acerca de la versión y la disponibilidad de las regiones con Aurora y Aurora Serverless v1, consulte Aurora Serverless v1.

Ventajas de Aurora Serverless v1

Aurora Serverless v1 ofrece las siguientes ventajas:

  • Más simple que el aprovisionado: Aurora Serverless v1 elimina gran parte de la complejidad de administrar instancias de base de datos y capacidad.

  • Escalable: Aurora Serverless v1 escala sin problemas la capacidad de memoria y de cómputo en función de las necesidades, sin interrumpir las conexiones del cliente.

  • Rentable: cuando utiliza Aurora Serverless v1, solo paga los recursos de base de datos que consume, contados por segundo.

  • Almacenamiento de alta disponibilidad: Aurora Serverless v1 utiliza el mismo sistema de almacenamiento distribuido, con tolerancia a errores y reproducción de seis vías que Aurora para protegerlo de la pérdida de datos.

Casos de uso de Aurora Serverless v1

Aurora Serverless v1 está diseñado para los siguientes casos de uso:

  • Aplicaciones de uso no frecuente: cuando tiene una aplicación que solo se utiliza durante unos minutos varias veces al día o a la semana, como una página de blog de bajo volumen. Con Aurora Serverless v1, solo paga por los recursos de bases de datos que consume, contados por segundo.

  • Aplicaciones nuevas: si implementa una nueva aplicación y no está seguro del tamaño de instancia que necesita. Con Aurora Serverless v1, puede crear un punto de enlace de base de datos y hacer que esta última escale automáticamente según los requisitos de capacidad de la aplicación.

  • Cargas de trabajo variables: cuando tiene una aplicación que usa poco y que presenta picos de entre 30 minutos y varias horas algunas veces al día o varias veces al año. Este es el caso, por ejemplo, de las aplicaciones de recursos humanos, presupuestos y generación de informes operativos. Con Aurora Serverless v1, ya no tiene que aprovisionar la capacidad para los picos ni para la carga promedio.

  • Cargas de trabajo impredecibles: cuando ejecuta cargas de trabajo diarias que presentan aumentos de actividad repentinos e impredecibles. Un ejemplo de ello sería un sitio dedicado al tráfico, que experimenta un aumento repentino de la actividad cuando comienza a llover. Con Aurora Serverless v1, la capacidad de la base de datos escala automáticamente para satisfacer las necesidades de los picos de carga de la aplicación y vuelve a disminuir cuando termina el aumento de actividad.

  • Bases de datos de desarrollo y prueba: sus desarrolladores usan las bases de datos durante las horas de trabajo, pero no las necesitan durante las noches ni los fines de semana. Con Aurora Serverless v1, la base de datos se apaga de forma automática cuando no se utiliza.

  • Aplicaciones de varios inquilinos: con Aurora Serverless v1, no es preciso administrar individualmente la capacidad de la base de datos para cada aplicación de la flota. Aurora Serverless v1 administra la capacidad de la base de datos individual por usted.

Limitaciones de Aurora Serverless v1

Las limitaciones siguientes se aplican a Aurora Serverless v1:

  • Aurora Serverless v1 no admite las siguientes características de :

    • Bases de datos globales de Aurora

    • Réplicas de Aurora

    • AWS Identity and Access ManagementAutenticación de base de datos de (IAM)

    • Búsqueda de datos anteriores en Aurora.

    • Secuencias de actividades de la base de datos

    • Autenticación de Kerberos

    • Performance Insights

    • RDS Proxy

    • Visualización de registros en la AWS Management Console

  • Las conexiones a un clúster de bases de datos de Aurora Serverless v1 se cierran automáticamente si se mantienen abiertas durante más de un día.

  • Todos los clústeres de base de datos de Aurora Serverless v1 tienen las siguientes limitaciones:

    • No se pueden exportar las instantáneas de Aurora Serverless v1 a los buckets de Amazon S3.

    • No puede usar ni cambiar AWS Database Migration Service la captura de datos (CDC) con clústeres de base de datos de Aurora Serverless v1. Sólo los clústeres de Aurora base de datos aprovisionados admiten CDC con AWS DMS como fuente.

    • No se pueden guardar datos en archivos de texto en Amazon S3 ni cargar datos de archivos de texto en Aurora Serverless v1 desde S3.

    • No se puede adjuntar un rol de IAM a un clúster de base de datos de Aurora Serverless v1. Sin embargo, puede cargar datos en Aurora Serverless v1 desde Amazon S3 utilizando la extensión de aws_s3 con la función de aws_s3.table_import_from_s3 y el parámetro de credentials. Para obtener más información, consulte Importación de datos de Amazon S3 en un clúster de base de datos Aurora PostgreSQL.

    • Cuando se utiliza el editor de consultas, se crea un secreto de Secrets Manager para que las credenciales de la base de datos accedan a la base de datos. Si elimina las credenciales del editor de consultas, el secreto asociado también se elimina de Secrets Manager. Este secreto no se puede recuperar después de eliminarlo.

  • Los clústeres de base de datos basados en Aurora MySQL que ejecutan Aurora Serverless v1 no admiten lo siguiente:

    • Invocación de funciones de AWS Lambda desde el clúster de bases de datos de Aurora MySQL. Sin embargo, las funciones de AWS Lambda pueden realizar llamadas a su clúster de bases de datos de Aurora Serverless v1.

    • Restauración de una instantánea desde una instancia de base de datos que no sea de Aurora MySQL ni de RDS for MySQL.

    • Replicación de datos mediante la replicación basada en registros binarios (binlogs). Esta limitación se cumple independientemente de si el clúster de bases de datos basado en Aurora MySQL, Aurora Serverless v1 es la fuente o el destino de la reproducción. Para replicar datos en un clúster de bases de datos de Aurora Serverless v1 desde una instancia de base de datos de MySQL fuera de Aurora, como una que se ejecuta en Amazon EC2, considere utilizar AWS Database Migration Service. Para obtener más información, consulte la Guía del usuario de AWS Database Migration Service.

    • Creación de usuarios con acceso basado en host ('username'@'IP_address'). Esto se debe a que Aurora Serverless v1 utiliza una flota de enrutadores entre el cliente y el host de la base de datos para lograr un escalado fluido. La dirección IP que el clúster de base de datos de Aurora Serverless ve es la del host del router y no la de su cliente. Para obtener más información, consulte Aurora Serverless v1 architecture.

      En su lugar, utilice el carácter comodín ('username'@'%').

  • Los clústeres de base de datos basados en Aurora PostgreSQL que ejecutan Aurora Serverless v1 tienen las siguientes limitaciones:

    • La administración de planes de consultas de Aurora PostgreSQL (extensión apg_plan_management) no es compatible.

    • La característica de replicación lógica disponible en Amazon RDS PostgreSQL y en Aurora PostgreSQL no es compatible.

    • Las comunicaciones salientes, como aquellas habilitadas por las extensiones de Amazon RDS for PostgreSQL no son compatibles. Por ejemplo, no se puede acceder a datos externos con la extensión postgres_fdw/dblink. Para obtener más información acerca de las extensiones de RDS PostgreSQL, consulte PostgreSQL en Amazon RDS en la Guía del usuario de RDS.

    • Actualmente, no se recomiendan ciertas consultas y comandos de SQL. Estos incluyen los bloqueos de asesoramiento a nivel de sesión, las relaciones temporales, las notificaciones asíncronas (LISTEN) y los cursores con retención (DECLARE name ... CURSOR WITH HOLD FOR query). Además, los comandos de NOTIFY evitan el escalado y no se recomiendan.

      Para obtener más información, consulte Escalado automático para Aurora Serverless v1.

  • No puede establecer el periodo de copia de seguridad automático preferido para un clúster de base de datos de Aurora Serverless v1.

  • Puede configurar el periodo de mantenimiento de un clúster de base de datos de Aurora Serverless v1. Para obtener más información, consulte Ajuste de la ventana de mantenimiento preferida para un clúster de base de datos.

Requisitos de configuración para Aurora Serverless v1

Cuando cree un clúster de bases de datos de Aurora Serverless v1, preste atención a los siguientes requisitos:

  • Utilice estos números de puerto específicos para cada motor de base de datos:

    • Aurora MySQL: – 3306

    • Aurora PostgreSQL – 5432

  • Cree sus clústeres de bases de datos de Aurora Serverless v1 en una nube virtual privada (VPC) basada en el servicio de Amazon VPC. Al crear un clúster de bases de datos de Aurora Serverless v1 en la VPC, se consumen dos (2) de los cincuenta (50) puntos de enlace de interfaz y balanceadores de carga de gateway asignados a la VPC. Estos extremos se crean automáticamente para usted. Para aumentar su cuota, puede ponerse en contacto con AWS Support. Para obtener más información, consulte Amazon VPC Cupos.

  • No se puede asignar una dirección IP pública a un clúster de bases de datos de Aurora Serverless v1. Sólo puede acceder a un clúster de bases de datos de Aurora Serverless v1 desde una VPC.

  • Cree subredes en diferentes zonas de disponibilidad para el grupo de subredes de base de datos que utilice para el clúster de bases de datos de Aurora Serverless v1. En otras palabras, no puede tener más de una subred en la misma zona de disponibilidad.

  • Los cambios realizados en un grupo de subredes utilizado por un clúster de bases de datos de Aurora Serverless v1 no se aplican al clúster.

  • Puede acceder a un clúster de bases de datos de Aurora Serverless v1 desde AWS Lambda. Para hacerlo, debe configurar la función de Lambda para que se ejecute en la misma VPC que su clúster de bases de datos de Aurora Serverless v1. Para obtener más información sobre el uso de AWS Lambda, consulte Configuración de una función de Lambda para acceder a los recursos de una Amazon VPC en la Guía para desarrolladores deAWS Lambda.

Uso de TLS/SSL con Aurora Serverless v1

De forma predeterminada, Aurora Serverless v1 utiliza el protocolo de Transport Layer Security/Secure Sockets Layer (TLS/SSL) para cifrar las comunicaciones entre los clientes y el clúster de bases de datos de Aurora Serverless v1. Admite TLS/SSL versiones 1.0, 1.1 y 1.2. No necesita configurar su clúster de bases de datos de Aurora Serverless v1 para que use TLS/SSL.

Sin embargo, se aplican las siguientes limitaciones:

  • Actualmente, la compatibilidad con TLS/SSL de los clústeres de base de datos de Aurora Serverless v1 no está disponible en la Región de AWS de China (Pekín).

  • Cuando cree usuarios de bases de datos para un clúster de bases de datos de Aurora Serverless v1 basado en Aurora MySQL, no utilice la cláusula REQUIRE para los permisos SSL. Esto impide que los usuarios se conecten a la instancia de base de datos de Aurora.

  • Para las utilidades de clientes MySQL y PostgreSQL, las variables de sesión que se pueden utilizar en otros entornos no tienen ningún efecto cuando se utiliza TLS/SSL entre el cliente y Aurora Serverless v1.

  • Para el cliente MySQL, cuando se conecta con el modo VERIFY_IDENTITY de TLS/SSL, actualmente se necesita usar el comando de mysql compatible con MySQL 8.0. Para obtener más información, consulte Conexión a una instancia de base de datos que ejecuta el motor de base de datos MySQL.

Dependiendo del cliente que utilice para conectarse al clúster de bases de datos de Aurora Serverless v1, es posible que no necesite especificar TLS/SSL para obtener una conexión cifrada. Por ejemplo, para utilizar el cliente PostgreSQL para conectarse a un clúster de bases de datos de Aurora Serverless v1 que ejecuta la Edición ccompatible con Aurora PostgreSQL, conéctese como lo hace normalmente. 

psql -h endpoint -U user

Después de escribir la contraseña, el cliente PostgreSQL le muestra los detalles de la conexión, incluida la versión de TLS/SSL y el cifrado. 

psql (12.5 (Ubuntu 12.5-0ubuntu0.20.04.1), server 10.12)
SSL connection (protocol: TLSv1.2, cipher: ECDHE-RSA-AES256-GCM-SHA384, bits: 256, compression: off)
Type "help" for help.
importante

Aurora Serverless v1 utiliza el protocolo Transport Layer Security/Secure Sockets Layer (TLS/SSL) para cifrar las conexiones de forma predeterminada, a menos que la aplicación del cliente deshabilite SSL/TLS. La conexión TLS/SSL termina en la flota de enrutadores. La comunicación entre la flota de enrutadores y el clúster de bases de datos de Aurora Serverless v1 se produce dentro del límite de la red interna del servicio.

Puede verificar el estado de la conexión del cliente para verificar si la conexión a Aurora Serverless v1 está cifrada con TLS/SSL. Las tablas pg_stat_ssl y pg_stat_activity de PostgreSQL y su función ssl_is_used no muestran el estado TLS/SSL de la comunicación entre la aplicación del cliente y Aurora Serverless v1. Del mismo modo, el estado TLS/SSL no se puede derivar de la instrucción status de MySQL.

Los parámetros de clúster de Aurora force_ssl para PostgreSQL y require_secure_transport para MySQL no son compatibles con Aurora Serverless v1. Estos parámetros están disponibles ahora para Aurora Serverless v1. Para obtener una lista completa de los parámetros compatibles con Aurora Serverless v1, llame a la operación de API DescribeEngineDefaultClusterParameters. Para obtener más información sobre los grupos de parámetros y Aurora Serverless v1, consulte Grupos de parámetros de Aurora Serverless v1.

Para utilizar el cliente MySQL para conectarse a un clúster de bases de datos de Aurora Serverless v1 que ejecuta la Edición compatible con Aurora MySQL, especifique TLS/SSL en su solicitud. En el ejemplo siguiente se incluye el almacén de confianza Amazon Root CA 1 descargado de Amazon Trust Services, que es necesario para que esta conexión se realice de manera correcta. 

mysql -h endpoint -P 3306 -u user -p --ssl-ca=amazon-root-CA-1.pem --ssl-mode=REQUIRED

Escriba la contraseña cuando se le solicite. Pronto, se abrirá el monitor MySQL. Puede confirmar que la sesión está cifrada usando el comando status. 

mysql> status
--------------
mysql  Ver 14.14 Distrib 5.5.62, for Linux (x86_64) using readline 5.1
Connection id:          19
Current database:
Current user:           ***@*******
SSL:                    Cipher in use is ECDHE-RSA-AES256-SHA
...

Para obtener más información acerca de cómo conectarse a la base de datos de Aurora MySQL con el cliente MySQL, consulte Conexión a una instancia de base de datos que ejecuta el motor de base de datos MySQL.

Aurora Serverless v1 admite todos los modos de TLS/SSL disponibles para el cliente MySQL (mysql) y el cliente PostgreSQL (psql), incluidos los enumerados en la tabla siguiente.

Descripción del modo TLS/SSL mysql psql

Conéctese sin utilizar TLS/SSL.

DISABLED

disable

Intente conectarse usando TLS/SSL primero, pero vuelva a no SSL si es necesario.

PREFERRED

preferir (predeterminado)

Aplicar mediante TLS/SSL.

REQUIRED

require

Aplique TLS/SSL y verifique la CA.

VERIFY_CA

verify-ca

Aplique TLS/SSL, verifique la CA y compruebe el nombre de alojamiento de la CA.

VERIFY_IDENTITY

verify-full

Aurora Serverless v1 utiliza certificados comodín. Si especifica la opción “verify CA (verificar CA)” o “verify CA and CA hostname (verificar CA y nombre de alojamiento de CA)” al utilizar TLS/SSL, descargue primero el almacén de confianza Amazon Root CA 1 de Amazon Trust Services. Después de hacerlo, puede identificar este archivo con formato PEM en el comando del cliente. Para hacerlo utilizando el cliente PostgreSQL:

Para Linux, macOS, o Unix:

psql 'host=endpoint user=user sslmode=require sslrootcert=amazon-root-CA-1.pem dbname=db-name'

Para obtener más información acerca de cómo trabajar con la base de datos de Aurora PostgreSQL usando el cliente PostgreSQL, consulte Conexión a una instancia de base de datos que ejecuta el motor de base de datos PostgreSQL.

Para obtener más información acerca de cómo conectarse a los clústeres de base de datos de Aurora en general, consulte Conexión a un clúster de base de datos Amazon Aurora.

Conjuntos de cifrado compatibles para conexiones a clústeres de base de datos de Aurora Serverless v1

Mediante el uso de conjuntos de cifrado configurables, puede tener más control sobre la seguridad de las conexiones de su base de datos. Puede especificar una lista de conjuntos de cifrado que desea permitir para proteger las conexiones TLS/SSL del cliente a su base de datos. Con conjuntos de cifrado configurables, puede controlar el cifrado de conexión que acepta el servidor de base de datos. Esto evita el uso de cifrados que no son seguros o que ya no se utilizan.

Los clústeres de base de datos de Aurora Serverless v1 basados en Aurora MySQL admiten los mismos conjuntos de cifrado que los clústeres de base de datos aprovisionados de Aurora MySQL. Para obtener información sobre estos conjuntos de cifrado, consulte Configuración de conjuntos de cifrado para conexiones a clústeres de base de datos de Aurora MySQL.

Los clústeres de base de datos de Aurora Serverless v1 basados en Aurora PostgreSQL no admiten conjuntos de cifrado.