Utilisation d’Amazon Aurora Serverless v1 - Amazon Aurora
Disponibilité des régions et des versions pour Aurora Serverless v1Avantages d’Aurora Serverless v1Cas d’utilisation pour Aurora Serverless v1Limites d Aurora Serverless v1Exigences en matière de configuration pour Aurora Serverless v1Utilisation de TLS/SSL avec Aurora Serverless v1

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Utilisation d’Amazon Aurora Serverless v1

Important

AWS a annoncé la date de fin de vie d’Aurora Serverless v1, qui sera le 31 mars 2025. Tous les clusters Aurora Serverless v1 qui ne seront pas migrés avant le 31 mars 2025 seront migrés vers Aurora Serverless v2 pendant la période de maintenance. Si la mise à niveau échoue, Amazon Aurora convertira le cluster sans serveur v1 en cluster provisionné avec la version de moteur équivalente pendant la période de maintenance. Le cas échéant, Amazon Aurora inscrira le cluster provisionné converti dans Amazon RDS Extended Support. Pour plus d’informations, consultez Support étendu Amazon RDS avec Amazon Aurora.

Amazon Aurora Serverless v1 (Amazon Aurora sans serveur version 1) est une configuration de d’autoscaling à la demande pour Amazon Aurora. Un cluster de bases de données Aurora Serverless v1 est un cluster de bases de données qui permet d’augmenter ou de réduire la capacité en fonction des besoins de votre application. Cela contraste avec des clusters de bases de données approvisionnés Aurora dont vous pouvez gérer manuellement la capacité. Aurora Serverless v1 offre une option relativement simple et rentable pour les charges de travail peu fréquentes, intermittentes ou imprévisibles. Il est économique, car il démarre, augmente ou réduit la capacité de calcul en fonction de l’utilisation de votre application et s’arrête lorsqu’il n’est pas utilisé.

Pour en savoir plus sur la tarification, consultez Tarification sans serveur sous Édition compatible avec MySQL ou Édition compatible avec PostgreSQL sur la page Amazon Aurora pricing.

Les clusters Aurora Serverless v1 ont le même type de volume de stockage haute capacité, distribué et hautement disponible que celui utilisé par les clusters de bases de données alloués.

Le volume d’un cluster Aurora Serverless v1 est toujours chiffré. Vous pouvez choisir la clé de chiffrement, mais vous ne pouvez pas désactiver le chiffrement. Dès lors, vous pouvez effectuer les mêmes opérations sur Aurora Serverless v1 que sur des instantanés chiffrés. Pour plus d’informations, consultez Aurora Serverless v1 et instantanés.

Rubriques

Disponibilité des régions et des versions pour Aurora Serverless v1

La disponibilité et la prise en charge des fonctions varient selon les versions spécifiques de chaque moteur de base de données Aurora, et selon les Régions AWS. Pour en savoir plus sur les versions et la disponibilité des régions avec Aurora et Aurora Serverless v1, consultez Aurora Serverless v1.

Avantages d’Aurora Serverless v1

Aurora Serverless v1 offre les avantages suivants :

  • Simplicité – Aurora Serverless v1 élimine une grande partie de la complexité de la gestion des instances et de la capacité des bases de données.

  • Évolutivité – Aurora Serverless v1 met à l’échelle sans heurt la capacité de calcul et de mémoire en fonction des besoins, sans perturber les connexions client.

  • Rentabilité – Quand vous utilisez Aurora Serverless v1, vous payez uniquement pour les ressources de bases de données que vous consommez, à la seconde.

  • Stockage hautement disponible – Pour assurer une protection contre la perte de données, Aurora Serverless v1 utilise le même système de stockage distribué et tolérant aux pannes avec réplication à six voies qu’Aurora.

Cas d’utilisation pour Aurora Serverless v1

Aurora Serverless v1 est conçu pour les cas d’utilisation suivants :

  • Applications rarement utilisées – Vous avez une application qui n’est utilisée que quelques minutes plusieurs fois par jour ou par semaine, comme un site de blog peu volumineux. Avec Aurora Serverless v1, vous payez uniquement les ressources de base de données que vous consommez, à la seconde.

  • Nouvelles applications – Vous déployez une nouvelle application et vous n’êtes pas sûr de la taille de l’instance dont vous avez besoin. Avec Aurora Serverless v1, vous pouvez créer un point de terminaison de base de données et faire en sorte que la base de données se mette à l’échelle automatiquement selon les besoins en capacité de votre application.

  • Charge de travail variables – Vous exécutez une application peu utilisée, avec des pics de 30 minutes à plusieurs heures quelques fois chaque jour, ou plusieurs fois par an. Il peut s’agir, par exemple, d’applications pour les ressources humaines, la budgétisation et le reporting opérationnel. Avec Aurora Serverless v1, vous n’avez plus besoin d’allouer de la capacité pour les pics ou la moyenne d’utilisation.

  • Charges de travail imprévisibles – Vous exécutez des charges de travail quotidiennes présentant des hausses soudaines et imprévisibles en termes d’activité. Par exemple, un site d’informations sur la circulation routière qui pourrait connaître un pic d’activité lorsqu’il commence à pleuvoir. Avec Aurora Serverless v1, la capacité de votre base de données augmente automatiquement pour répondre aux besoins de la charge de pointe de l’application et revient à la normale lorsque la hausse d’activité est terminée.

  • Bases de données de développement et de test – Vos développeurs utilisent les bases de données pendant les heures de travail, mais n’en ont pas besoin la nuit ou le week-end. Avec Aurora Serverless v1, votre base de données s’arrête automatiquement lorsqu’elle n’est pas utilisée.

  • Applications multilocataires – Avec Aurora Serverless v1, vous n’avez pas à gérer individuellement la capacité de base de données pour chaque application de votre flotte. Aurora Serverless v1 gère la capacité de base de données individuelle pour vous.

Limites d Aurora Serverless v1

Les limites suivantes s’appliquent à Aurora Serverless v1 :

  • Important

    AWS a annoncé la date de fin de vie d’Aurora Serverless v1, qui sera le 31 mars 2025. Tous les clusters Aurora Serverless v1 qui ne seront pas migrés avant le 31 mars 2025 seront migrés vers Aurora Serverless v2 pendant la période de maintenance. Si la mise à niveau échoue, Amazon Aurora convertira le cluster sans serveur v1 en cluster provisionné avec la version de moteur équivalente pendant la période de maintenance. Le cas échéant, Amazon Aurora inscrira le cluster provisionné converti dans Amazon RDS Extended Support. Pour plus d’informations, consultez Support étendu Amazon RDS avec Amazon Aurora.

  • Aurora Serverless v1 ne prend pas en charge les fonctionnalités suivantes :

    • Bases de données globales Aurora

    • Réplicas Aurora

    • AWS Identity and Access ManagementAuthentification de base de données (IAM)

    • Retour sur trace dans Aurora

    • Flux d’activité de base de données.

    • Authentification Kerberos

    • Performance Insights

    • RDS Proxy (Proxy RDS)

    • Affichage des journaux dans la AWS Management Console

  • Les connexions à un cluster de bases de données Aurora Serverless v1 sont automatiquement fermées si elles restent ouvertes pendant plus d’un jour.

  • Tous les clusters de bases de données Aurora Serverless v1 présentent les limites suivantes :

    • Vous ne pouvez pas exporter d’instantanés Aurora Serverless v1 vers des compartiments Amazon S3.

    • Vous ne pouvez pas utiliser AWS Database Migration Service et la capture des données de modification (CDC) avec les clusters de bases de données Aurora Serverless v1. Seuls les clusters de bases de données Aurora alloués prennent en charge les CDC avec AWS DMS en tant que source.

    • Vous ne pouvez pas enregistrer de données dans des fichiers texte dans Amazon S3 ni charger de données de fichiers texte vers Aurora Serverless v1 depuis S3.

    • Vous ne pouvez pas attacher un rôle IAM à un cluster de bases de données Aurora Serverless v1. Cependant, vous pouvez charger des données dans Aurora Serverless v1 depuis Amazon S3 à l’aide de l’extension aws_s3 avec la fonction aws_s3.table_import_from_s3 et le paramètre credentials. Pour plus d’informations, consultez Importation de données Amazon S3 dans une d'un cluster de base de données Aurora PostgreSQL.

    • Lorsque vous utilisez l’éditeur de requêtes, un secret Secrets Manager est créé afin que les informations d’identification de la base de données puissent accéder à cette dernière. Si vous supprimez les informations d’identification de l’éditeur de requêtes, le secret associé est également supprimé de Secrets Manager. Vous ne pouvez pas récupérer ce secret une fois que vous l’avez supprimé.

  • Les clusters de bases de données basés sur Aurora MySQL exécutant Aurora Serverless v1 ne prennent pas en charge les opérations suivantes :

    • Appel de fonctions AWS Lambda à partir votre cluster de bases de données Aurora MySQL. Cependant, les fonctions AWS Lambda peuvent effectuer des appels à votre cluster de bases de données Aurora Serverless v1.

    • Restauration d’un instantané à partir d’une instance de base de données ne correspondant pas à Aurora MySQL ou RDS for MySQL.

    • Réplication de données à l’aide de la réplication basée sur des journaux binaires (binlogs). Cette limitation est vraie, que votre cluster de bases de données Aurora Serverless v1 basé sur Aurora MySQL soit la source ou la cible de la réplication. Pour répliquer des données dans un cluster de bases de données Aurora Serverless v1 à partir d’une instance de base de données MySQL hors d’Aurora, telle qu’une instance s’exécutant sur Amazon EC2, envisagez d’utiliser AWS Database Migration Service. Pour plus d’informations, consultez le Guide de l’utilisateur AWS Database Migration Service.

    • Création d’utilisateurs avec un accès basé sur l’hôte ('username'@'IP_address'). En effet, Aurora Serverless v1 utilise une flotte de routeurs entre le client et l’hôte de la base de données pour une mise à l’échelle transparente. L’adresse IP que le cluster de bases de données Aurora Serverless voit est celle de l’hôte du routeur et non celle de votre client. Pour plus d’informations, consultez Architecture d’Aurora Serverless v1.

      Utilisez plutôt le caractère générique ('username'@'%').

  • Les clusters de bases de données basés sur Aurora PostgreSQL exécutant Aurora Serverless v1 présentent les limitations suivantes :

    • La gestion du plan de requête Aurora PostgreSQL (extension apg_plan_management) n’est pas prise en charge.

    • La fonction de réplication logique disponible dans Amazon RDS PostgreSQL et Aurora PostgreSQL n’est pas prise en charge.

    • Les communications sortantes telles que celles activées par les extensions Amazon RDS pour PostgreSQL ne sont pas prises en charge. Par exemple, vous ne pouvez pas accéder aux données externes avec l’extension postgres_fdw/dblink. Pour plus d’informations sur les extensions RDS PostgreSQL, consultez PostgreSQL sur Amazon RDS dans le Guide de l’utilisateur Amazon RDS.

    • Certaines requêtes et commandes SQL sont actuellement déconseillées. Il s’agit notamment des verrous consultatifs au niveau de la session, des relations temporaires, des notifications asynchrones (LISTEN) et des curseurs avec maintien (DECLARE name ... CURSOR WITH HOLD FOR query). En outre, les commandes NOTIFY empêchent la mise à l’échelle et sont déconseillées.

      Pour plus d’informations, consultez Mise à l’échelle automatique pour Aurora Serverless v1.

  • Vous ne pouvez pas définir la fenêtre de sauvegarde automatisée préférée pour un cluster de bases de données Aurora Serverless v1.

  • Vous pouvez définir la fenêtre de maintenance pour un cluster de bases de données Aurora Serverless v1. Pour plus d’informations, consultez Ajustement du créneau de maintenance préféré pour un cluster de bases de données.

Exigences en matière de configuration pour Aurora Serverless v1

Lorsque vous créez un cluster de bases de données Aurora Serverless v1, prêtez une attention particulière aux exigences suivantes :

  • Utilisez ces numéros de ports spécifiques pour chaque moteur de base de données :

    • Aurora MySQL – 3306

    • Aurora PostgreSQL – 5432

  • Créez votre cluster de bases de données Aurora Serverless v1 dans un cloud privé virtuel (VPC) basé sur le service Amazon VPC. Lorsque vous créez un cluster de bases de données Aurora Serverless v1 dans votre VPC, vous consommez deux (2) des cinquante (50) points de terminaison d’interface et d’équilibrage de charge de passerelle alloués à votre VPC. Ces points de terminaison sont créés automatiquement pour vous. Pour augmenter votre quota, vous pouvez contacter Support. Pour plus d’informations, consultez Amazon VPC quotas (Quotas Amazon VPC).

  • Vous ne pouvez pas donner d’adresse IP publique à un cluster de bases de données Aurora Serverless v1. Vous pouvez accéder à un cluster de bases de données Aurora Serverless v1 uniquement à partir d’un VPC.

  • Créez des sous-réseaux dans différentes zones de disponibilité pour le groupe de sous-réseaux de base de données que vous utilisez pour votre cluster de bases de données Aurora Serverless v1. En d’autres termes, vous ne pouvez pas disposer de plusieurs sous-réseaux dans la même zone de disponibilité.

  • Les modifications apportées à un groupe de sous-réseaux utilisé par un cluster de bases de données Aurora Serverless v1 ne sont pas appliquées au cluster.

  • Vous pouvez accéder à un cluster de bases de données Aurora Serverless v1 à partir d’AWS Lambda. Pour ce faire, vous devez configurer votre fonction Lambda pour qu’elle s’exécute dans le même VPC que votre cluster de bases de données Aurora Serverless v1. Pour plus d’informations sur l’utilisation de AWS Lambda, consultez Configuration d’une fonction Lambda pour accéder aux ressources d’un VPC Amazon dans le Manuel du développeur AWS Lambda.

Utilisation de TLS/SSL avec Aurora Serverless v1

Par défaut, Aurora Serverless v1 utilise le protocole TLS/SSL (Transport Layer Security/Secure Sockets Layer) pour chiffrer les communications entre les clients et votre cluster de bases de données Aurora Serverless v1. Il prend en charge les versions TLS/SSL 1.0, 1.1 et 1.2. Vous n’êtes pas tenu de configurer votre cluster de bases de données Aurora Serverless v1 pour utiliser TLS/SSL.

Cependant, les limites suivantes s’appliquent :

  • La prise en charge de TLS/SSL pour les clusters de bases de données Aurora Serverless v1 n’est actuellement pas disponible dans la Région AWS Chine (Pékin).

  • Lorsque vous créez des utilisateurs de base de données pour un cluster de bases de données Aurora Serverless v1 basé sur Aurora MySQL, n’utilisez pas la clause REQUIRE pour les autorisations SSL. Cela empêche les utilisateurs de se connecter à l’instance de base de données Aurora.

  • Pour les utilitaires de client MySQL et de client PostgreSQL, les variables de session que vous pouvez utiliser dans d’autres environnements n’ont aucun effet sur l’utilisation de TLS/SSL entre le client et Aurora Serverless v1.

  • Pour le client MySQL, en cas de connexion avec le mode VERIFY_IDENTITY TLS/SSL, vous devez actuellement utiliser la commande mysql compatible MySQL 8.0. Pour plus d’informations, consultez Connexion à une instance de base de données exécutant le moteur de base de données MySQL.

Selon le client que vous utilisez pour vous connecter au cluster de bases de données Aurora Serverless v1, vous n’êtes pas nécessairement tenu de spécifier TLS/SSL pour obtenir une connexion chiffrée. Par exemple, pour utiliser le client PostgreSQL pour vous connecter à un cluster de bases de données Aurora Serverless v1 exécutant Aurora Édition compatible avec PostgreSQL, connectez-vous comme d’habitude. 

psql -h endpoint -U user

Après avoir entré votre mot de passe, le client PostgreSQL affiche les détails de la connexion, notamment la version TLS/SSL et le chiffrement. 

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

Aurora Serverless v1 utilise le protocole TLS/SSL (Transport Layer Security/Secure Sockets Layer) pour chiffrer les connexions par défaut, à moins que SSL/TLS ne soit désactivé par l’application cliente. La connexion TLS/SSL se termine au niveau de la flotte de routeurs. La communication entre la flotte de routeurs et votre cluster de bases de données Aurora Serverless v1 s’effectue dans la limite du réseau interne du service.

Vous pouvez consulter le statut de la connexion client pour vérifier si la connexion à Aurora Serverless v1 est chiffrée via TLS/SSL. Les tables PostgreSQL pg_stat_ssl et pg_stat_activity, ainsi que la fonction ssl_is_used n’affichent pas l’état TLS/SSL pour la communication entre l’application cliente et Aurora Serverless v1. De même, l’état TLS/SSL ne peut pas provenir de l’instruction status MySQL.

Les paramètres de cluster Aurora force_ssl pour PostgreSQL et require_secure_transport pour MySQL n’étaient pas pris en charge pour Aurora Serverless v1. Ces paramètres sont maintenant disponibles pour Aurora Serverless v1. Pour obtenir la liste complète des paramètres pris en charge par Aurora sans serveur v1, appelez l’opération d’API DescribeEngineDefaultClusterParameters. Pour plus d’informations sur les groupes de paramètres et Aurora sans serveur version 1, consultez Groupes de paramètres pour Aurora Serverless v1.

Pour utiliser le client MySQL pour vous connecter à un cluster de bases de données Aurora Serverless v1 exécutant Aurora Édition compatible avec MySQL, spécifiez TLS/SSL dans votre requête. L’exemple suivant inclut le référentiel d’approbations Amazon Root CA 1 téléchargé à partir d’Amazon Trust Services et nécessaire pour que cette connexion aboutisse. 

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

Lorsque vous y êtes invité, entrez votre mot de passe. Après quoi, la surveillance MySQL s’ouvre. Vous pouvez vérifier que la session est chiffrée à l’aide de la commande 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
...

Pour en savoir plus sur la connexion à la base de données Aurora MySQL avec le client MySQL, consultez Connexion à une instance de base de données exécutant le moteur de base de données MySQL.

Aurora Serverless v1 prend en charge tous les modes TLS/SSL disponibles pour le client MySQL (mysql) et le client PostgreSQL (psql), y compris les modes répertoriés dans le tableau suivant.

Description du mode TLS/SSL mysql psql

Se connecte sans utiliser TLS/SSL.

DISABLED

désactiver

Essaie de se connecter à l’aide de TLS/SSL, mais revient à non-SSL, si nécessaire.

PREFERRED

prefer (par défaut)

Imposer à l’aide de TLS/SSL.

REQUIRED

require

Impose TLS/SSL et vérifie l’autorité de certification.

VERIFY_CA

verify-ca

Impose TLS/SSL, vérifie l’autorité de certification et son nom d’hôte.

VERIFY_IDENTITY

verify-full

Aurora Serverless v1 utilise des certificats à caractères génériques. Si vous spécifiez l’option « Vérifier l’autorité de certification » ou « Vérifier l’autorité de certification et son nom d’hôte » lors de l’utilisation de TLS/SSL, commencez par télécharger le référentiel d’approbations Amazon Root CA 1 à partir d’Amazon Trust Services. Vous pouvez ensuite identifier ce fichier au format PEM dans votre commande client. Pour ce faire, utilisez le client PostgreSQL :

Pour Linux, macOS ou Unix :

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

Pour en savoir plus sur l’utilisation de la base de données Aurora PostgreSQL à l’aide du client Postgres, consultez Connexion à une instance de base de données exécutant le moteur de base de données PostgreSQL.

Pour plus d’informations sur la connexion aux clusters de bases de données Aurora, consultez Connexion à un cluster de bases de données Amazon Aurora.

Suites de chiffrement prises en charge pour les connexions aux clusters de bases de données Aurora Serverless v1

L’utilisation de suites de chiffrement configurables vous permet d’avoir plus de contrôle sur la sécurité des connexions de vos bases de données. Vous pouvez spécifier une liste de suites de chiffrement que vous souhaitez autoriser pour la sécurisation des connexions TLS/SSL client à votre base de données. Avec les suites de chiffrement configurables, vous pouvez contrôler le chiffrement de connexion accepté par votre serveur de base de données. Cela évite d’utiliser des chiffrements qui ne sont pas sécurisés ou qui ne sont plus utilisés.

Les clusters de bases de données Aurora Serverless v1 basés sur Aurora MySQL prennent en charge les mêmes suites de chiffrement que les clusters de bases de données provisionnés Aurora MySQL. Pour plus d’informations sur ces suites de chiffrement, consultez Configuration de suites de chiffrement pour les connexions aux clusters de bases de données Aurora MySQL.

Les clusters de bases de données Aurora Serverless v1 basés sur Aurora PostgreSQL ne prennent pas en charge les suites de chiffrement.