Utilisation d'Amazon Aurora Serverless v1 - Amazon Aurora
Disponibilité de la région et de la version 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 v1TLSSSLUtiliser/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

Amazon Aurora Serverless v1 (Amazon Aurora Serverless version 1) est une configuration de scalabilité automatique et à la demande pour Amazon Aurora. Un cluster de base de données Aurora Serverless v1 est un cluster de base 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 base 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 les tarifs, consultez la section Tarification sans serveur sous My SQL -Compatible Edition ou Postgre SQL -Compatible Edition 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 base de données alloués.

Pour un cluster Aurora Serverless v2, vous pouvez choisir de chiffrer le volume du cluster.

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 de plus amples informations, veuillez consulter Aurora Serverless v1 et instantanés.

Rubriques
Important

Aurora dispose de deux générations de technologie sans serveur, Aurora Serverless v2 et Aurora Serverless v1. Si votre application peut s'exécuter sur My SQL 8.0 ou Postgre SQL 13, nous vous recommandons d'utiliserAurora Serverless v2. Aurora Serverless v2évolue plus rapidement et de manière plus granulaire. Aurora Serverless v2offre également une meilleure compatibilité avec les autres fonctionnalités d'Aurora, telles que les instances de base de données de lecture. Ainsi, si vous connaissez déjà Aurora, vous n'avez pas besoin d'apprendre autant de nouvelles procédures ou limites pour utiliser Aurora Serverless v2 comme avec Aurora Serverless v1.

Pour en savoir plus sur Aurora Serverless v2, consultez Utiliser Aurora Serverless v2.

Disponibilité de la région et de la version 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 Régions et moteurs de base de données Aurora pris en charge pour 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 :

  • 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 Management (IAM) authentification de base de données

    • Retour sur trace dans Aurora

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

    • Authentification Kerberos

    • Performance Insights

    • RDSProxy

    • Afficher les journaux dans le AWS Management Console

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

  • Tous les clusters de base 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 ni modifier AWS Database Migration Service la capture de données (CDC) avec des clusters de Aurora Serverless v1 base de données. Seuls les clusters de base de données Aurora provisionnés sont pris CDC en charge 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 associer de IAM rôle à un cluster de Aurora Serverless v1 bases de données. 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 de plus amples informations, veuillez consulter Importation de données depuis Amazon S3 dans un cluster de SQL base de données Aurora Postgre RDS.

    • 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 base SQL de données basés sur Aurora My exécutés Aurora Serverless v1 ne prennent pas en charge les éléments suivants :

    • Invocation de AWS Lambda fonctions depuis votre cluster Aurora My SQL DB. Cependant, AWS Lambda les fonctions peuvent appeler votre Aurora Serverless v1 cluster de base de données.

    • Restauration d'un instantané à partir d'une instance de base de données qui n'est pas Aurora My SQL 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 base de données SQL basé sur Aurora My Aurora Serverless v1 soit la source ou la cible de la réplication. Pour répliquer des données dans un cluster de Aurora Serverless v1 bases de données à partir d'une instance My SQL DB externe à Aurora, telle qu'une instance exécutée sur AmazonEC2, pensez à utiliser AWS Database Migration Service. Pour plus d’informations, consultez le AWS Database Migration Service Guide de l’utilisateur .

    • 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 base de données Aurora Serverless voit est celle de l'hôte du routeur et non celle de votre client. Pour de plus amples informations, veuillez consulter Architecture d'Aurora Serverless v1.

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

  • Les clusters de base de SQL données basés sur Aurora Postgre exécutés Aurora Serverless v1 présentent les limites suivantes :

    • La gestion du plan de SQL requêtes Aurora Postgre (apg_plan_managementextension) n'est pas prise en charge.

    • La fonctionnalité de réplication logique disponible dans Amazon RDS Postgre SQL et Aurora Postgre SQL n'est pas prise en charge.

    • Les communications sortantes telles que celles activées par Amazon RDS pour les SQL extensions Postgre 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 SQL extensions RDS Postgre, consultez Postgre sur SQL Amazon RDS dans le guide de l'RDSutilisateur.

    • À l'heure actuelle, certaines SQL requêtes et commandes ne sont pas recommandé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 de plus amples informations, veuillez consulter 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 base de données Aurora Serverless v1.

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

Exigences en matière de configuration pour Aurora Serverless v1

Lorsque vous créez un cluster de base 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 My SQL — 3306

    • Poster Aurora — SQL 5432

  • Créez votre Aurora Serverless v1 cluster de base de données dans un cloud privé virtuel (VPC) basé sur le VPC service Amazon. Lorsque vous créez un Aurora Serverless v1 cluster de base de données dans votreVPC, vous consommez deux (2) des cinquante (50) points de terminaison Interface et Gateway Load Balancer alloués à votre. VPC Ces points de terminaison sont créés automatiquement pour vous. Pour augmenter votre quota, vous pouvez contacter AWS Support. Pour plus d'informations, consultez la section VPCQuotas Amazon.

  • Vous ne pouvez pas donner d'adresse IP publique à un cluster de base de données Aurora Serverless v1. Vous pouvez accéder à un Aurora Serverless v1 cluster de bases de données uniquement depuis unVPC.

  • 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 base 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 base de données Aurora Serverless v1 ne sont pas appliquées au cluster.

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

TLSSSLUtiliser/avec Aurora Serverless v1

Aurora Serverless v1Utilise par défaut le protocole Transport Layer Security/Secure Sockets Layer (TLS/SSL) pour chiffrer les communications entre les clients et votre Aurora Serverless v1 cluster de bases de données. Il prend TLS en charge SSL les versions 1.0, 1.1 et 1.2. Vous n'avez pas besoin de configurer votre Aurora Serverless v1 cluster de base de données pour utiliserTLS/SSL.

Cependant, les limites suivantes s'appliquent :

  • TLS/le SSL support pour les clusters de Aurora Serverless v1 bases de données n'est actuellement pas disponible en Chine (Pékin) Région AWS.

  • Lorsque vous créez des utilisateurs de base de données pour un cluster de SQL base de Aurora Serverless v1 données basé sur Aurora My, n'utilisez pas la REQUIRE clause d'SSLautorisation. Cela empêche les utilisateurs de se connecter à l'instance de base de données Aurora.

  • Pour les utilitaires My SQL Client et Postgre SQL Client, les variables de session que vous pouvez utiliser dans d'autres environnements n'ont aucun effet lorsque vous utilisezTLS/SSLentre le client etAurora Serverless v1.

  • Pour le My SQL Client, lorsque vous vous connectez en VERIFY_IDENTITY modeTLS/SSL, vous devez actuellement utiliser la commande SQL compatible My 8.0mysql. Pour plus d'informations, consultez Connexion à une instance de base de données exécutant le moteur My SQL database.

Selon le client que vous utilisez pour vous connecter au Aurora Serverless v1 cluster de base de données, il se peut que vous n'ayez pas besoin de spécifierTLS/SSLpour obtenir une connexion cryptée. Par exemple, pour utiliser le SQL client Postgre pour vous connecter à un cluster de Aurora Serverless v1 base de données exécutant Aurora Postgre SQL -Compatible Edition, connectez-vous comme vous le faites normalement. 

psql -h endpoint -U user

Après avoir saisi votre mot de passe, le SQL client Postgre vous montre les détails de connexion, y compris la SSL versionTLS/et le code. 

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 v1utilise le protocole Transport Layer Security/Secure Sockets Layer (TLS/SSL) pour chiffrer les connexions par défaut, sauf siSSL/TLSest désactivé par l'application cliente. La SSL connexionTLS/se termine au niveau du parc de routeurs. La communication entre la flotte de routeurs et votre cluster de base de données Aurora Serverless v1 s'effectue dans la limite du réseau interne du service.

Vous pouvez vérifier l'état de la connexion client pour vérifier si la connexion à Aurora Serverless v1 est TLS SSL chiffrée/cryptée. Le Postgre, pg_stat_activity les tables SQL pg_stat_ssl et leur ssl_is_used fonction n'affichent pas l'SSLétatTLS/pour la communication entre l'application cliente etAurora Serverless v1. De même, l'SSLétatTLS/ne peut pas être dérivé de l'SQLstatusinstruction My.

Les paramètres du cluster Aurora force_ssl pour Postgre SQL et require_secure_transport My n'étaient SQL auparavant pas pris en charge pour la version Aurora Serverless 1. Ces paramètres sont maintenant disponibles pour Aurora Serverless v1. Pour obtenir la liste complète des paramètres pris en charge par Aurora Serverless v1, appelez l'DescribeEngineDefaultClusterParametersAPIopération. Pour plus d'informations sur les groupes de paramètres et Aurora sans serveur version 1, veuillez consulter Groupes de paramètres pour Aurora Serverless v1.

Pour utiliser My SQL Client pour vous connecter à un Aurora Serverless v1 cluster de base de données exécutant Aurora My SQL -Compatible Edition, vous spécifiezTLS/SSLdans votre demande. 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. Bientôt, l'SQLécran Mon moniteur 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 à Aurora My SQL Database avec My SQL Client, voir Connexion à une instance de base de données exécutant le moteur My SQL database.

Aurora Serverless v1prend en charge tous les SSL modesTLS/disponibles pour My SQL Client (mysql) et Postgre SQL Client (psql), y compris ceux répertoriés dans le tableau suivant.

Description du SSL modeTLS/ mysql psql

Connectez-vous sans utiliserTLS/SSL.

DISABLED

désactiver

Essayez d'SSLabord la connexion en utilisantTLS/, mais revenez à non- SSL si nécessaire.

PREFERRED

prefer (par défaut)

Appliquer à l'aide deTLS/SSL.

REQUIRED

require

AppliquezTLS/SSLet vérifiez l'autorité de certification.

VERIFY_CA

verify-ca

AppliquezTLS/SSL, vérifiez l'autorité de certification et vérifiez le nom d'hôte de l'autorité de certification.

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 le nom d'hôte de l'autorité de certification » lorsque vous utilisezTLS/SSL, téléchargez d'abord le magasin racine Amazon CA 1 trust depuis Amazon Trust Services. Ensuite, vous pouvez identifier ce fichier PEM formaté dans votre commande client. Pour ce faire, utilisez le SQL client Postgre :

Pour LinuxmacOS, 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 SQL base de données Aurora Postgre à l'aide du client Postgres, consultez Connexion à une instance de base de données exécutant le moteur de base de données Postgre SQL.

Pour plus d'informations sur la connexion aux clusters de base 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 sécuriser les SSL connexions client-client TLS à 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.

Aurora Serverless v1Les clusters de base de données basés sur Aurora My SQL prennent en charge les mêmes suites de chiffrement que les clusters de base de données SQL provisionnés par Aurora My. Pour plus d'informations sur ces suites de chiffrement, consultez Configuration de suites de chiffrement pour les connexions aux clusters Aurora My SQL DB.

Aurora Serverless v1Les clusters de base de données basés sur Aurora Postgre SQL ne prennent pas en charge les suites de chiffrement.