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 end-of-life date de Aurora Serverless v1: 31 mars 2025. Nous vous recommandons vivement de mettre à jour tout Aurora Serverless v1 Clusters de bases de données pour Aurora Serverless v2 avant cette date. La mise à niveau peut impliquer une modification du numéro de version principal du moteur de base de données. Il est donc important de planifier, de tester et de mettre en œuvre cette transition avant la end-of-life date prévue. À compter du 8 janvier 2025, les clients ne seront plus en mesure de créer de nouveaux Aurora Serverless v1 clusters ou instances avec le AWS Management Console ou leCLI. Pour plus d'informations sur la procédure de mise à niveau depuis Aurora Serverless v1 to Aurora Serverless v2, voir Mise à niveau à partir d'un Aurora Serverless v1 cluster vers Aurora Serverless v2.
Aurora Serverless v2 évolue plus rapidement et de manière plus granulaire. Aurora Serverless v2 offre également une meilleure compatibilité avec les autres fonctionnalités d'Aurora, telles que les instances de base de données de lecture. Vous pouvez en apprendre davantage sur Aurora Serverless v2 dans Utilisation Aurora Serverless v2.
Amazon Aurora Serverless v1 (Amazon Aurora Serverless version 1) est une configuration de mise à l'échelle automatique à la demande pour Amazon Aurora. Un Aurora Serverless v1 Un cluster de base de données est un cluster de base de données qui augmente ou diminue la capacité de calcul en fonction des besoins de votre application. Cela contraste avec les clusters de base de données provisionnés par Aurora, pour lesquels vous gérez manuellement la capacité. Aurora Serverless v1 constitue 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
Aurora Serverless v1 les clusters 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 provisionnés.
Pour un Aurora Serverless v1 cluster, le volume du cluster est toujours chiffré. Vous pouvez choisir la clé de chiffrement, mais vous ne pouvez pas désactiver le chiffrement. Cela signifie que vous pouvez effectuer les mêmes opérations sur Aurora Serverless v1 que vous pouvez utiliser sur des instantanés chiffrés. Pour de plus amples informations, veuillez consulter Aurora Serverless v1 et instantanés.
Rubriques
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 plus d'informations sur la disponibilité des versions et des régions avec Aurora et Aurora Serverless v1, voir Aurora Serverless v1.
Avantages de Aurora Serverless v1
Aurora Serverless v1 offre les avantages suivants :
-
Plus simple que prévu : Aurora Serverless v1 élimine une grande partie de la complexité liée à la gestion des instances et des capacités de base de données.
-
Évolutif — Aurora Serverless v1 adapte facilement la capacité de calcul et de mémoire selon les besoins, sans perturber les connexions des clients.
-
Rentable — Lorsque vous utilisez Aurora Serverless v1, vous ne payez que pour les ressources de base de données que vous consommez, à la seconde.
-
Stockage à haute disponibilité : Aurora Serverless v1 utilise le même système de stockage distribué tolérant aux pannes avec réplication à six voies qu'Aurora pour se protéger contre les pertes de données.
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 ne payez que pour 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. En utilisant 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 s'adapte automatiquement aux exigences de 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 de prévoir une capacité maximale ou moyenne.
-
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 liés à la charge maximale de l'application, puis redescend à la baisse lorsque le pic d'activité est terminé.
-
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 multi-locataires — Avec Aurora Serverless v1, vous n'avez pas à gérer individuellement la capacité des bases de données pour chaque application de votre parc. Aurora Serverless v1 gère pour vous la capacité individuelle des bases de données.
Limites de Aurora Serverless v1
Les restrictions suivantes s'appliquent à Aurora Serverless v1:
-
Important
AWS a annoncé la end-of-life date de Aurora Serverless v1: 31 mars 2025. Nous vous recommandons vivement de mettre à jour tout Aurora Serverless v1 Clusters de bases de données pour Aurora Serverless v2 avant cette date. La mise à niveau peut impliquer une modification du numéro de version principal du moteur de base de données. Il est donc important de planifier, de tester et de mettre en œuvre cette transition avant la end-of-life date prévue. À compter du 8 janvier 2025, les clients ne seront plus en mesure de créer de nouveaux Aurora Serverless v1 clusters ou instances avec le AWS Management Console ou leCLI.
Vous pouvez en apprendre davantage sur Aurora Serverless v2 dans Utilisation Aurora Serverless v2. Pour plus d'informations sur la procédure de mise à niveau depuis Aurora Serverless v1 to Aurora Serverless v2, voir Mise à niveau à partir d'un Aurora Serverless v1 cluster vers Aurora Serverless v2.
-
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
-
RDS Proxy
-
Afficher les journaux dans le AWS Management Console
-
-
Connexions à un Aurora Serverless v1 Les clusters de base de données sont fermés automatiquement s'ils sont maintenus ouverts pendant plus d'un jour.
-
Tous Aurora Serverless v1 Les clusters de base de données présentent les limites suivantes :
-
Vous ne pouvez pas exporter Aurora Serverless v1 des instantanés vers des compartiments Amazon S3.
-
Vous ne pouvez pas utiliser AWS Database Migration Service ni modifier la capture de données (CDC) avec Aurora Serverless v1 Clusters de bases 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 ou charger des données de fichiers texte dans Aurora Serverless v1 à partir de S3.
-
Vous ne pouvez pas associer un IAM rôle à un Aurora Serverless v1 Cluster de bases de données. Toutefois, vous pouvez charger des données dans Aurora Serverless v1 depuis Amazon S3 en utilisant l'
aws_s3extension avec laaws_s3.table_import_from_s3fonction et lecredentialsparamètre. 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é.
-
-
Clusters de base de données SQL basés sur Aurora My en cours d'exécution 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 passer des appels à votre Aurora Serverless v1 Cluster de bases de données.
-
Restauration d'un instantané à partir d'une instance de base de données autre qu'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 soit ou non Aurora Serverless v1 est la source ou la cible de la réplication. Pour répliquer des données dans un Aurora Serverless v1 Envisagez d'utiliser un cluster de base de données provenant d'une instance My SQL DB extérieure à AuroraEC2, telle qu'une instance exécutée sur Amazon 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 (
'). C'est parce que Aurora Serverless v1 utilise un parc de routeurs entre le client et l'hôte de base de données pour une mise à l'échelle fluide. L'adresse IP que le Aurora Serverless Le cluster de base de données voit celui de l'hôte du routeur et non celui de votre client. Pour de plus amples informations, veuillez consulter Aurora Serverless v1 application.username'@'IP_address'Utilisez plutôt le caractère générique (
').username'@'%'
-
-
Clusters de bases de données SQL basés sur Aurora Postgre en cours d'exécution 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). En outre, les commandesname... CURSOR WITH HOLD FORqueryNOTIFYempêchent la mise à l'échelle et sont déconseillées.Pour de plus amples informations, veuillez consulter Autoscaling pour Aurora Serverless v1.
-
-
Vous ne pouvez pas définir la fenêtre de sauvegarde automatique préférée pour un Aurora Serverless v1 Cluster de bases de données.
-
Vous pouvez définir la fenêtre de maintenance pour un Aurora Serverless v1 Cluster de bases de données. 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 de configuration pour Aurora Serverless v1
Lorsque vous créez un Aurora Serverless v1 Cluster de base de données, faites attention 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 Dans votre cluster de base de donnéesVPC, 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 Support. Pour plus d'informations, consultez la section VPCQuotas Amazon.
-
Tu ne peux pas donner un Aurora Serverless v1 Le cluster de base de données est une adresse IP publique. Vous pouvez accéder à un Aurora Serverless v1 Cluster de base de données uniquement à partir d'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 Aurora Serverless v1 Cluster de bases de données. En d'autres termes, vous ne pouvez pas disposer de plusieurs sous-réseaux dans la même zone de disponibilité.
-
Modifications apportées à un groupe de sous-réseaux utilisé par Aurora Serverless v1 Les clusters de base de données ne sont pas appliqués au cluster.
-
Vous pouvez accéder à un Aurora Serverless v1 Cluster de base de données de AWS Lambda. Pour ce faire, vous devez configurer votre fonction Lambda pour qu'elle s'exécute de la même manière que VPC 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
Par défaut, Aurora Serverless v1 utilise le protocole Transport Layer Security/Secure Sockets Layer (TLS/SSL (couche de transport) 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 à utiliserTLS/SSL.
Cependant, les limites suivantes s'appliquent :
-
TLS/SSLsupport pour Aurora Serverless v1 Les clusters de base de données ne sont actuellement pas disponibles en Chine (Pékin) Région AWS.
-
Lorsque vous créez des utilisateurs de base de données pour une base de données basée sur Aurora SQL My Aurora Serverless v1 Cluster de base de données, n'utilisez pas la
REQUIREclause pour SSL les autorisations. 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 TLS utilisez/ SSL entre client et Aurora Serverless v1.
-
Pour le My SQL Client, lorsque vous vous connectez en
VERIFY_IDENTITYmodeTLS/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.
En fonction du client auquel vous vous connectez Aurora Serverless v1 Cluster de base de données, vous n'aurez peut-être pas besoin de spécifierTLS/SSLpour obtenir une connexion cryptée. Par exemple, pour utiliser le SQL client Postgre pour vous connecter à un Aurora Serverless v1 Cluster de base de données exécutant Aurora Postgre SQL -Compatible Edition, connectez-vous comme d'habitude.
psql -hendpoint-Uuser
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 v1 utilise la couche de transport pour Security/Secure Sockets Layer (TLS/SSL) protocol to encrypt connections by default unless SSL/TLS is disabled by the client application. The TLS/SSL se terminer sur le parc de routeurs. Communication entre le parc de routeurs et votre Aurora Serverless v1 Le cluster de base de données se trouve dans les limites du réseau interne du service.
Vous pouvez vérifier l'état de la connexion client pour déterminer si la connexion à Aurora Serverless v1 est TLS SSL chiffré/. Le Postgre, pg_stat_activity les tables SQL pg_stat_ssl et sa ssl_is_used fonction n'affichent pas l'SSLétatTLS/pour la communication entre l'application cliente et Aurora 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 My n'étaient SQL auparavant pas pris en charge require_secure_transport pour Aurora Serverless v1. Ces paramètres sont disponibles dès maintenant 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 le 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
mysql -hendpoint-P 3306 -uuser-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 v1 prend 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 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
Dans Linux, macOS, ou Unix:
psql 'host=endpointuser=usersslmode=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 à Aurora Serverless v1 Clusters de bases de données
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 v1 Les 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 de bases de données Aurora MySQL.
Aurora Serverless v1 Les clusters de base de données basés sur Aurora Postgre SQL ne prennent pas en charge les suites de chiffrement.
