Q : Qu'est-ce qu'Amazon Aurora ?

Amazon Aurora est un moteur de base de données relationnelle qui associe la vitesse et la fiabilité des bases de données commerciales haut de gamme à la simplicité et la rentabilité des bases de données open source. Amazon Aurora MySQL offre des performances jusqu'à cinq fois supérieures à celles de MySQL sans nécessiter de modifications de la plupart des applications MySQL. De la même manière, Amazon Aurora PostgreSQL offre des performances jusqu'à trois fois supérieures à celles de PostgreSQL. Amazon RDS gère vos bases de données Amazon Aurora en prenant en charge les tâches chronophages telles que la mise en service, l'application des correctifs, la sauvegarde, la récupération, la détection des pannes, ainsi que les réparations. Vous payez un forfait mensuel pour chaque instance de base de données Amazon Aurora utilisée. Aucun coût initial ou engagement à long terme requis.

Q : Que signifie « compatible avec MySQL » ?

Cela signifie que la plupart des codes, applications, pilotes et outils que vous utilisez déjà aujourd'hui avec vos bases de données MySQL peuvent être utilisés avec Aurora en apportant peu de modifications voire aucune. Le moteur de base de données Amazon Aurora est conçu pour être compatible avec MySQL 5.6 avec le moteur de stockage InnoDB. Certaines fonctionnalités de MySQL telles que le moteur de stockage MyISAM ne sont pas disponibles sur Amazon Aurora.

Q : Que signifie « compatible avec PostgreSQL » ?

Cela signifie que la plupart des codes, applications, pilotes et outils que vous utilisez déjà aujourd'hui avec vos bases de données PostgreSQL peuvent être utilisés avec Aurora en apportant peu de modifications, voire aucune. Le moteur de base de données Amazon Aurora est conçu pour être compatible avec PostgreSQL 9.6 et prend en charge le même ensemble d'extensions PostgreSQL pris en charge par RDS pour PostgreSQL 9.6, ce qui simplifie le déplacement d'applications entre les deux moteurs.  

Q : Comment essayer Amazon Aurora ?

Pour essayer Amazon Aurora, connectez-vous à la console AWS, sélectionnez RDS dans la catégorie Base de données, puis choisissez Amazon Aurora comme moteur de base de données.

Q : Combien coûte Amazon Aurora ?

Pour obtenir des informations sur la tarification actuelle, consultez la page des tarifs.

Q : Amazon Aurora reproduit chaque fragment du volume de ma base de données de six façons dans trois zones de disponibilité. Cela veut-il dire que le prix de stockage réel sera trois ou six fois plus élevé que le prix affiché sur la page de tarification ?

Non. La réplication d'Amazon Aurora est comprise dans le prix. Vous êtes facturé en fonction de l'espace occupé par votre base de données au niveau de la couche de la base de données, et non pas en fonction de l'espace occupé dans la couche de stockage virtualisée d'Amazon Aurora.

Q : Dans quelles régions AWS Amazon Aurora est-il disponible ?

Consultez notre page de tarification pour voir des informations à jour concernant les régions et les tarifs.

Q : Comment migrer de MySQL vers Amazon Aurora et vice-versa ?

Vous avez plusieurs options. Vous pouvez utiliser l'utilitaire standard mysqldump pour exporter des données de MySQL et l'utilitaire mysqlimport pour importer des données dans Amazon Aurora, et vice versa. Vous pouvez aussi utiliser la fonctionnalité de migration d'instantanés de DB d'Amazon RDS afin de migrer un instantané de DB de RDS MySQL vers Amazon Aurora à l'aide d'AWS Management Console. La migration dure moins d'une heure pour la plupart des clients bien que la durée dépende du format et de la taille de l'ensemble des données. Pour en savoir plus, consultez le manuel concernant l'importation et l'exportation de données dans Amazon Aurora.

Q : Comment migrer de PostgreSQL vers Amazon Aurora et vice-versa ?

Vous avez plusieurs options. Vous pouvez utiliser l'utilitaire standard pg_dump pour exporter des données de PostgreSQL et l'utilitaire pg_restore pour importer des données dans Amazon Aurora, et vice-versa. Vous pouvez aussi utiliser la fonctionnalité de migration d'instantanés de DB d'Amazon RDS afin de migrer un instantané de DB de RDS PostgreSQL 9.6 vers Amazon Aurora à l'aide d'AWS Management Console. La migration dure moins d'une heure pour la plupart des clients bien que la durée dépende du format et de la taille de l'ensemble des données. Pour en savoir plus, consultez le manuel concernant l'importation et l'exportation de données dans Amazon Aurora.

Q : Amazon Aurora fait-il partie du niveau gratuit d'AWS ?

Pas à l'heure actuelle. Le niveau gratuit d'AWS pour Amazon RDS présente des avantages pour les instances DB Micro ; actuellement, Amazon Aurora ne propose pas de prise en charge de l'instance DB Micro. Pour obtenir des informations sur la tarification actuelle, consultez la page des tarifs.

Q : En quoi consistent les E/S dans Amazon Aurora et comment sont-elles calculées ?

Les E/S sont des opérations en entrée/sortie réalisées par le moteur de base de données Aurora sur sa couche de stockage virtualisée basée sur SSD. Chaque opération de lecture de page de base de données compte comme une E/S. Le moteur de base de données Aurora lit les problèmes sur la couche de stockage afin de récupérer les pages de bases de données qui ne sont pas présentes dans le cache des tampons. Chaque page de base de données fait 16 Ko dans Aurora MySQL et 8 Ko dans Aurora PostgreSQL.

Aurora a été conçu pour supprimer toutes les opérations d'E/S inutiles, afin de réduire les coûts et de garantir la disponibilité des ressources dans le but de gérer le trafic de lecture/écriture. Les E/S en écriture sont consommées uniquement lorsque vous transférez les fichiers journaux de transactions vers la couche de stockage afin d'augmenter la durabilité des écritures. Les E/S en écriture sont rassemblées en unités de 4 Ko chacune. Par exemple, un fichier journal de transaction de 1024 octets comptera comme une opération d'E/S. Cependant, les opérations d'écriture simultanées dont le fichier de transaction est inférieur à 4 Ko peuvent être traitées par lots par le moteur de base de données Aurora afin d'optimiser la consommation d'E/S. A la différence des moteurs de base de données traditionnels, Amazon Aurora ne transfère jamais des pages de bases de données modifiées vers la couche de stockage, vous permettant ainsi de réduire encore davantage votre consommation d'E/S.

Vous pouvez consulter le nombre d'E/S consommées par votre instance Aurora en accédant à la console AWS. Pour afficher votre consommation d'E/S, accédez à la section RDS de la console, consultez votre liste d'instances, sélectionnez vos instances Aurora, puis recherchez les mesures « Opérations de lecture facturées » et « Opérations d'écriture facturées » dans la section Surveillance.

Q : Faut-il changer les pilotes clients pour utiliser Amazon Aurora PostgreSQL ?

Non. Amazon Aurora fonctionne avec les pilotes de base de données PostgreSQL standard.

Q : Qu'est-ce qu'Amazon Aurora sans serveur ?

Au re:Invent 2017, nous avons annoncé la version préliminaire d'Amazon Aurora sans serveur, une nouvelle configuration de l'édition compatible avec MySQL qui peut vous faire gagner un temps précieux, vous épargner bien des efforts et réduire les coûts en dimensionnant automatiquement la capacité des bases de données pour répondre à vos besoins en matière d'application.

Q : Comment puis-je commencer à utiliser Amazon Aurora sans serveur ?

Amazon Aurora sans serveur est désormais disponible en version préliminaire pour l'édition compatible avec MySQL d'Amazon Aurora. Vous pouvez vous inscrire pour faire part de votre souhait d'y participer. Nous annoncerons la mise à disposition globale à une date ultérieure.

Q : Que signifie « une performance de MySQL jusqu'à cinq fois supérieure » ?

Amazon Aurora fournit des augmentations significatives des performances de MySQL en intégrant étroitement le moteur de base de données avec une couche de stockage virtualisée basée sur SSD conçue principalement pour les charges de travail des bases de données, réduisant les opérations d'écritures dans le système de stockage, la contention de verrouillage et éliminant les délais créés par les threads de processus de la base de données. Nos tests effectués sur des instances r3.8xlarge dans SysBench démontrent qu'Amazon Aurora fournit plus de 500 000 SELECTS par seconde et 100 000 mises à jour par seconde, soit un volume cinq fois supérieur à MySQL en exécutant le même test de performances avec le même matériel. Vous trouverez des instructions détaillées concernant ce test comparatif et la manière de le reproduire par vous-même dans le manuel Amazon Aurora Performance Benchmarking Guide.

Q : Que signifie « des performances trois fois supérieures à celles de PostgreSQL » ?

Amazon Aurora fournit des augmentations significatives des performances de PostgreSQL en intégrant étroitement le moteur de base de données avec une couche de stockage virtualisée basée sur SSD conçue principalement pour les charges de travail des bases de données, réduisant les opérations d'écritures dans le système de stockage, la contention de verrouillage et éliminant les délais créés par les threads de processus de la base de données. Nos tests effectués sur des instances r4.16xlarge dans SysBench démontrent qu'Amazon Aurora fournit des SELECTS par seconde et des mises à jour par seconde trois fois supérieurs à PostgreSQL en exécutant le même test de performances avec le même matériel. Vous trouverez des instructions détaillées concernant ce test comparatif et la manière de le reproduire par vous-même dans le manuel Amazon Aurora PostgreSQL Performance Benchmarking Guide.

Q : Comment puis-je optimiser la charge de travail de ma base de données pour Amazon Aurora ?

Amazon Aurora est conçu pour être compatible avec MySQL 5.6. Les utilisateurs peuvent ainsi exécuter leurs applications et leurs outils MySQL existants sans y apporter de modification. Cependant, Amazon Aurora améliore les performances de MySQL en ce qui concerne les charges de travail simultanées. Afin de maximiser le débit de votre charge de travail sur Amazon Aurora, nous vous conseillons de concevoir vos applications de façon à gérer un grand nombre de requêtes et de transactions simultanées.

Q : Comment puis-je optimiser la charge de travail de ma base de données pour Amazon Aurora PostgreSQL ?

Amazon Aurora est conçu pour être compatible avec PostgreSQL 9.6. Les applications et outils PostgreSQL existants peuvent ainsi s'exécuter sans y apporter de modification. Cependant, Amazon Aurora améliore les performances de PostgreSQL en ce qui concerne les charges de travail simultanées. Afin de maximiser le débit de votre charge de travail sur Amazon Aurora, nous vous conseillons de concevoir vos applications de façon à gérer un grand nombre de requêtes et de transactions simultanées.

Q : Quelles sont les limites de stockage minimales et maximales d'une base de données Amazon Aurora ?

L'espace de stockage minimal est de 10 Go. Selon l'usage que vous faites de votre base de données, votre stockage Amazon Aurora augmentera automatiquement jusqu'à 64 To, par paliers de 10 Go sans affecter la performance de la base de données. Il n'est pas nécessaire de prévoir un espace de stockage à l'avance.

Q : Comment mettre à l'échelle les ressources de calcul associées à mon instance DB Amazon Aurora ?

Vous pouvez dimensionner les ressources de calcul attribuées à votre instance DB dans l'AWS Management Console en sélectionnant les instances DB souhaitées et en cliquant sur le bouton Modifier. Les ressources de mémoire et de CPU peuvent être modifiées en changeant votre classe d'instance DB.

Lorsque vous modifiez votre classe d'instance DB, les changements requis sont appliqués au cours de la fenêtre de maintenance que vous avez définie. Vous pouvez aussi utiliser l'indicateur « Appliquer immédiatement » pour appliquer immédiatement vos demandes de dimensionnement. Ces deux options affecteront la disponibilité pendant quelques minutes, le temps de l'opération de dimensionnement. N'oubliez pas que toutes les modifications système en attente seront également appliquées.

Q : Comment activer les sauvegardes pour mon instance DB ?

Les sauvegardes automatisées sont toujours activées sur les instances DB d'Amazon Aurora. Les sauvegardes n'affectent pas la performance de la base de données.

Q : Puis-je faire des instantanés DB et les conserver aussi longtemps que je le souhaite ?

Oui, et prendre des instantanés n'affecte pas la performance. Veuillez noter que la restauration de données à partir des instantanés DB requiert la création d'une nouvelle instance DB.

Q : Si ma base de données connaît une défaillance, quel est mon chemin de récupération ?

Amazon Aurora conserve automatiquement six copies de vos données dans trois zones de disponibilité et tentera de récupérer automatiquement votre base de données dans une zone de disponibilité saine sans aucune perte de données. Dans le cas improbable où vos données ne sont pas disponibles dans l'espace de stockage d'Amazon Aurora, vous pouvez les restaurer à partir d'un instantané DB ou effectuer une opération de restauration à un moment donné dans une nouvelle instance. Veuillez noter que la sauvegarde à des fins de restauration la plus récente possible remonte à cinq minutes en arrière.

Q : Qu'arrive-t-il à mes sauvegardes et instantanés DB automatisés si je supprime mon instance DB ?

Vous pouvez choisir de créer un instantané DB final au moment de supprimer votre instance DB. De cette manière, vous pourrez utiliser cet instantané DB pour restaurer l'instance DB supprimée ultérieurement. Amazon Aurora conserve cet instantané DB final créé par l'utilisateur avec les autres instantanés DB créés manuellement, et ce, même après la suppression de l'instance DB. Seuls les instantanés DB sont conservés après la suppression de l'instance DB (c.-à-d. les sauvegardes automatisées créées pour la restauration à un moment donné ne sont pas conservées).

Q : Puis-je partager mes instantanés avec un autre compte AWS ?

Oui. Aurora vous offre la possibilité de créer des instantanés (snapshots) de vos bases de données, afin de les utiliser ultérieurement pour restaurer une base de données. Vous pouvez partager un instantané avec un autre compte AWS, et le propriétaire du compte destinataire pourra utiliser votre instantané pour restaurer une base de données contenant vos données. Il est même possible de créer des instantanés publics, qui pourront être utilisés par n'importe qui pour restaurer une base de données contenant vos données (publiques). Cette fonctionnalité peut être utilisée pour partager des données entre des environnements (production, dev/test, transfert, etc.) liés à des comptes AWS différents, ainsi que pour garder des sauvegardes de toutes vos données dans un compte à part au cas où votre compte AWS principal serait compromis.

Q : Les instantanés partagés me seront-ils facturés ?

Le partage d'instantanés (snapshots) entre des comptes ne fait pas l'objet de frais supplémentaires. Toutefois, vous pourrez être facturé pour les instantanés en eux-même, ainsi que pour les bases de données restaurées à partir d'instantanés partagés. Pour en savoir plus, consultez la page sur la tarification d'Aurora.

Q : Puis-je partager automatiquement des instantanés ?

Nous ne prenons pas en charge le partage automatique d'instantanés (snapshots) de bases de données. Pour partager un instantané automatique, vous devez créer manuellement une copie de celui-ci, puis partager cette copie.

Q : Avec combien de comptes puis-je partager des instantanés ?

Vous pouvez partager des instantanés (snapshots) manuels avec un maximum de 20 ID de compte AWS. Si vous souhaitez partager un instantané avec plus de 20 comptes, partagez-le publiquement ou contactez le service d'assistance pour augmenter votre quota.

Q : Dans quelles régions puis-je partager mes instantanés Aurora ?

Vous pouvez partager vos instantanés (snapshots) Aurora dans toutes les régions AWS où Aurora est disponible.

Q : Puis-je partager mes instantanés AWS entre les régions ?

Non. Vos instantanés (snapshots) Aurora partagés ne seront accessibles que par les comptes de la même région que le compte qui les partage.

Q : Puis-je partager un instantané Aurora chiffré ?

Oui. Vous pouvez partager des instantanés Aurora chiffrés.

Q : De quelle façon Amazon Aurora améliore-t-il la tolérance aux pannes de disque dur de ma base de données ?

Amazon Aurora divise automatiquement le volume de votre base de données en segments de 10 Go répartis sur plusieurs disques. Chaque lot de 10 Go du volume de votre base de données est répliqué six fois dans trois zones de disponibilité. Amazon Aurora est conçu pour prendre en charge de manière transparente la perte de jusqu'à deux copies de données sans compromettre la disponibilité en écriture de la base de données et jusqu'à trois copies sans compromettre la disponibilité en lecture. Le stockage Amazon Aurora est également doté d'un mécanisme d'autoréparation. Les blocs de données et les disques sont continuellement analysés pour trouver des erreurs et sont réparés automatiquement.

Q : Comment Aurora améliore-t-il les temps de reprise après le plantage d'une base de données ?

Contrairement aux autres bases de données, après le plantage d'une base de données, Amazon Aurora ne doit pas relire le fichier journal du dernier point de reprise pour la base de données (généralement cinq minutes) et confirmer tous les changements qui ont été apportés, avant de mettre à disposition la base de données pour effectuer des opérations. Cela réduit les durées de redémarrage de la base de données à moins de 60 secondes dans la plupart des cas. Amazon Aurora supprime le cache des tampons du processus de la base de données et la met immédiatement à votre disposition au moment du redémarrage. Cela vous évite de limiter l'accès jusqu'à ce que le cache soit rempli à nouveau afin d'éviter les baisses de tension.

Q : Quels types de réplicas Aurora prend-il en charge ?

Amazon Aurora MySQL et Amazon Aurora PostgreSQL prennent en charge les réplicas Amazon Aurora qui partagent le même volume sous-jacent comme instance primaire. Les mises à jour effectuées par l'instance principale sont visibles sur tous les réplicas Amazon Aurora. Avec Amazon Aurora MySQL, vous pouvez aussi créer des réplicas en lecture MySQL axés sur le moteur de réplication binlog de MySQL. Dans les réplicas en lecture MySQL, les données de votre instance principale sont lues à nouveau sur votre réplica en tant que transactions. Dans la plupart des cas d'utilisation, y compris le dimensionnement en lecture ainsi que la haute disponibilité, nous recommandons l'utilisation de réplicas Amazon Aurora.

Vous avez la possibilité de combiner ces deux types de réplicas en fonction des besoins de votre application :

Fonctionnalité Réplicas Amazon Aurora Réplicas MySQL
Nombre de réplicas Jusqu'à 15 Jusqu'à 5
Type de réplication Asynchrone (millièmes de seconde) Asynchrone (secondes)
Impact sur la performance de l'instance principale Faibles Elevées
Agit en tant que cible du basculement Oui (aucune perte de données) Oui (perte de données de quelques minutes possible)
Basculement automatisé Oui Non
Prise en charge du délai de réplication défini par l'utilisateur Non Oui
Prise en charge des données distinctes ou du schéma par rapport à l'instance principale Non Oui

Q : Puis-je profiter des réplicas sur plusieurs régions avec Amazon Aurora ?

Oui, avec Amazon Aurora MySQL vous pouvez configurer un réplica Aurora sur plusieurs régions à l'aide de la console RDS. La réplication sur plusieurs régions est basée sur une réplication de binlog MySQL à thread unique et le délai de réplication est affecté par le taux de changement/application et les délais de communication réseau entre les régions sélectionnées. Aurora PostgreSQL ne prend actuellement pas en charge les réplicas entre régions.

Q : Puis-je créer des réplicas en lecture Aurora sur le cluster de réplicas sur plusieurs régions ?
Oui, vous pouvez ajouter des réplicas Aurora sur le cluster qui partagera le même espace de stockage sous-jacent que la réplica sur plusieurs régions. La réplica sur plusieurs régions fait office de réplica principale sur le cluster, et les réplicas Aurora auront généralement un retard de quelques dizaines de millisecondes par rapport à celle-ci.

Q : Puis-je faire basculer mon application de la réplica principale vers la réplica sur plusieurs régions ?
Oui, vous pouvez définir votre réplica sur plusieurs régions comme étant la nouvelle réplica principale depuis la console RDS. Le processus de promotion dure généralement quelques minutes, selon votre charge de travail. La réplication sur plusieurs régions s'arrête quand le processus de promotion est lancé.

Q : Puis-je accorder la priorité à certaines réplicas en tant que cibles de failover (basculement) ?

R : Oui. Vous pouvez attribuer un niveau de priorité à chaque instance sur votre cluster. En cas d'échec de l'instance principale, Amazon RDS choisit la réplica dont le niveau de priorité est le plus élevé et la définit comme la nouvelle instance principale. En cas de conflit entre 2 réplicas ou plus du même niveau de priorité, Amazon RDS choisit la réplica dont la taille est identique à celle de l'instance principale. Pour en savoir plus sur la logique de failover (basculement), consultez le Guide de l'Utilisateur Amazon Aurora.

Q : Puis-je modifier les niveaux de priorité des instances après leur création ?

A : Vous pouvez modifier le niveau de priorité d'une instance à tout moment. Le simple fait de modifier les niveaux de priorité ne déclenchera pas de failover (basculement).

Q : Puis-je empêcher certaines réplicas d'être définies comme l'instance principale ?

A : Vous pouvez attribuer des niveaux de priorité inférieurs aux réplicas que vous ne souhaitez pas voir définies comme l'instance principale. Cependant, si les réplicas de niveau supérieur du cluster sont défectueuses ou indisponibles pour quelque raison que ce soit, Amazon RDS choisit une réplica de niveau inférieur.

Q : Comment améliorer la disponibilité d'une seule base de données Amazon Aurora ?

Vous pouvez ajouter des réplicas Amazon Aurora. Les réplicas Amazon Aurora partagent le même stockage sous-jacent en tant qu'instance principale. Tout réplica Amazon Aurora peut être promu pour devenir un réplica principal sans aucune perte de données et de ce fait peut être utilisé pour améliorer la tolérance aux pannes en cas de défaillance de l'instance DB principale. Pour augmenter la disponibilité, il suffit de créer 1 à 15 réplicas, dans n'importe laquelle des trois zones de disponibilité, et Amazon RDS les inclura automatiquement dans la sélection principale de basculement en cas de panne d'une base de données.

Q : Que se passe-t-il au cours du basculement et combien de temps cela dure-t-il ?

Le basculement est automatiquement traité par Amazon Aurora afin que vos applications puissent reprendre vos opérations de base de données aussi vite que possible, sans intervention administrative manuelle.

  • Si vous disposez d'un réplica Amazon Aurora dans la même zone de disponibilité ou dans une autre zone de disponibilité, lors du basculement, Amazon Aurora retourne simplement l'enregistrement de nom canonique (CNAME) de votre instance DB pour pointer vers le réplica sain, qui est promu à son tour afin de devenir la nouvelle instance principale. Du début à la fin, le basculement s'effectue généralement en 30 secondes.
  • Si vous ne disposez d'aucun réplica Amazon Aurora (c.-à-d. une instance unique), Aurora tentera d'abord de créer une nouvelle instance DB dans la même zone de disponibilité que l'instance d'origine. Si vous ne pouvez pas le faire, Aurora tentera de créer une nouvelle instance DB dans une autre zone de disponibilité. Du début à la fin, le basculement dure en général moins de 15 minutes.

Votre application devrait tenter une nouvelle connexion à la base de données dans le cas d'une perte de connexion.

Q : Si je dispose d'une base de données principale et d'un réplica Amazon Aurora enregistrant activement le trafic en lecture et qu'un basculement se produit, que se passe-t-il ?

Amazon RDS détectera automatiquement un problème dans votre instance principale et commencera l'acheminement du trafic en lecture/écriture vers le réplica Amazon Aurora. En moyenne, ce basculement se fait en 30 secondes. En outre, le trafic en lecture servi par vos réplicas Amazon Aurora sera interrompu momentanément.

Q : A quel point mes réplicas seront-ils en retard sur l'instance principale ?

Comme les réplicas Amazon Aurora partagent le même volume de données que l'instance principale, il n'y a quasiment pas de retard de réplication. Nous constatons généralement des périodes de retard de l'ordre d'une dizaine de millisecondes. Pour les réplicas en lecture MySQL, le retard de réplication peut augmenter indéfiniment en fonction du tarif modifié/appliqué ainsi que des délais du réseau de communication. Cependant, dans des conditions normales, le retard de réplication est généralement inférieur à une minute.

Q : Qu'est-ce qu'Amazon Aurora Multi Master ?

Au re:Invent 2017, nous avons annoncé la version préliminaire d'Amazon Aurora Multi-Master, une nouvelle fonctionnalité de l'édition d'Aurora compatible avec MySQL qui ajoute la possibilité de dimensionner les performances en écriture sur plusieurs zones de disponibilité, ce qui permet aux applications de diriger les charges de travail en écriture/lecture vers plusieurs instances d'un cluster de base de données et de fonctionner à un niveau plus élevé de disponibilité.

Q : Comment puis-je commencer à utiliser Amazon Aurora Multi-Master ?

Amazon Aurora Multi-Master est désormais disponible en version préliminaire pour l'édition compatible avec MySQL d'Amazon Aurora. Vous pouvez vous inscrire pour faire part de votre souhait d'y participer. Nous annoncerons la mise à disposition globale à une date ultérieure.

Q : Puis-je utiliser Amazon Aurora dans Amazon Virtual Private Cloud (Amazon VPC) ?

Oui, toutes les instances DB d'Amazon Aurora doivent être créées dans un VPC. Avec Amazon VPC, vous pouvez définir une topologie virtuelle de réseau qui ressemble étroitement à un réseau traditionnel que vous pourriez exploiter dans votre propre centre de données. Vous disposez d'un contrôle total sur les utilisateurs pouvant accéder à votre base de données Amazon Aurora.

Q : Amazon Aurora chiffre-t-il mes données en transit et au repos ?

Oui. Amazon Aurora utilise SSL (AES-256) pour sécuriser la connexion entre l'instance de base de données et l'application. Amazon Aurora vous permet de chiffrer vos bases de données à l'aide de clés que vous gérez par l'intermédiaire d'AWS Key Management Service (KMS). Sur une instance de base de données en cours d'exécution utilisant le chiffrement Amazon Aurora, les données stockées au repos dans le stockage sous-jacent sont chiffrées, tout comme leurs sauvegardes automatisées, leurs instantanés et leurs réplicas dans le même cluster. Le chiffrement et le déchiffrement sont gérés de manière transparente. Pour plus d'informations concernant l'utilisation de KMS avec Amazon Aurora, consultez le manuel Amazon RDS User's Guide.

Q : Puis-je chiffrer une base de données non chiffrée existante ?

Le chiffrement des instances Aurora non chiffrées existantes n'est actuellement pas pris en charge. Pour utiliser le chiffrement Amazon Aurora pour une base de données non chiffrées existante, créez une nouvelle instance DB avec chiffrement activé, puis migrez vos données vers celle-ci.

Q : Comment puis-je accéder à ma base de données Amazon Aurora ?

L'accès aux bases de données Amazon Aurora doit se faire grâce au port de base de données saisi lors de la création de la base de données. Cette mesure a été prise afin de fournir un niveau de sécurité supplémentaire pour vos données. Vous trouverez des instructions étape par étape concernant la manière de vous connecter à votre base de données Amazon Aurora dans le manuel Amazon Aurora Connectivity Guide.

Q : Sur quelles tailles d'instance Performance Insights sera-t-il disponible ?

Sur toutes les tailles d'instances non micro. Comme RDS apporte de nouvelles tailles d'instances, Performance Insights sera disponible sur celles présentant des performances suffisantes.

Q : Quand Performance Insights sera-t-il disponible pour RDS pour PostgreSQL, Aurora MySQL, RDS pour MySQL, RDS pour Oracle, RDS pour SQL Server et RDS pour MariaDB ?

Performance Insights sera initialement disponible sur Aurora PostgreSQL, puis peu après sur Aurora MySQL. Des moteurs supplémentaires seront ajoutés au fil du temps.

Q : Comment Performance Insights montre-t-il la cause des problèmes de performances ?

Un problème de performances apparaît dans la section Performance Insights de la console RDS sous la forme de pics dans le graphique de charge de la base de données. Un coup d'œil à ce graphique peut rapidement vous indiquer à quels types de ressources votre application a consacré du temps et des ressources dans la base de données. A l'aide de la console, vous pouvez faire un zoom avant sur n'importe quelle période au sein de la durée de conservation. En sélectionnant les périodes de charge élevée, les clients peuvent afficher une liste d'instructions SQL, classées selon leur contribution globale à la charge.

Q : Comment Performance Insights détermine-t-il la charge de mon instance de base de données RDS ?

Performance Insights échantillonne l'état de toutes les sessions connectées dans votre instance de base de données toutes les secondes. Si une session consacre du temps à une opération liée à la base de données, Performance Insights enregistre la durée de l'échantillon, le type d'opération (E/S, UC, verrouillage, etc.), l'instruction SQL actuelle et plusieurs autres attributs de session. Sur des périodes, ces données échantillonnées sont utilisées pour caractériser comment les sessions contribuent à la charge dans votre instance de base de données.

Q : Les données de performance peuvent-elles être interrogées au sein de l'instance RDS ?

Non. Le processus d'échantillonnage de Performance Insights ne remplit pas des tables dans la base de données et ne présente pas non plus les données à extraire depuis la base de données via SQL.

Q : Puis-je voir ce qui se passe sur mon instance en temps réel ?

Oui. Par défaut, Performance Insights affiche une fenêtre mobile d'une heure de données de performance. La fonction est conçue pour présenter les dernières informations de performance à quelques secondes du temps réel.

Q : Combien coûte Performance Insights ?

Performance Insights comprend 24 heures de conservation de données et d'accès à la console. Performance Insights en version préliminaire fournit une offre gratuite qui inclut 24 heures de conservation des données de performance. La tarification pour la conservation de données à plus long terme sera annoncée.

Q : Jusqu'à quand puis-je remonter pour afficher les données de performances stockées dans Performance Insights ?

Vous pouvez afficher 24 heures d'historique de performances. Les options de conservation plus longue seront annoncées à une date ultérieure.

Q : Puis-je désactiver Performance Insights sur de nouvelles instances, même s'il est activé par défaut ?

Oui. L'option pour Performance Insights est sélectionnée par défaut dans la console AWS lorsque vous utilisez l'assistant de création d'instance. Vous pouvez désélectionner l'option dans l'assistant pour éviter que Performance Insights ne soit activé. Sinon vous pouvez désactiver Performance Insights dans une instance activée en modifiant l'instance.

Q : Performance Insights fonctionne-t-il sur les instances de base de données RDS utilisant le stockage chiffré ?

Oui. Performance Insights ne lit pas les données que vous stockez dans votre base de données.

Q : Qu'est-ce que la charge de la base de données et pourquoi est-ce la mesure principale utilisée dans Performance Insights pour détecter les problèmes de performance ?

La charge de la base de données est une série chronologique montrant combien de temps les applications d'un client passent dans la base de données et à quoi elles consacrent ce temps. La charge de la base de données est mesurée en unités de sessions actives moyennes (Average Active Sessions, AAS). Une session active est une connexion (session) qui a envoyé du travail au moteur de base de données et qui attend une réponse de ce dernier. Par exemple, si vous envoyez une instruction SQL à une instance de base de données, cette session est considérée comme « active » pendant le temps que l'instance traite cette requête. En comptant le nombre de sessions actives dans une instance à un moment donné, nous pouvons fournir des mesures qui, mises en moyenne sur certaines périodes, peuvent montrer à quel point une instance peut être occupée et combien de temps les sessions passent à attendre une réponse de l'instance. C'est la charge de base de données. Performance Insights compte les sessions actives et enregistre les attributs de chaque session toutes les secondes à l'aide d'un mécanisme léger d'échantillonnage. Les données échantillonnées sont chiffrées et regroupées selon différentes granularités et insérées dans le graphique DB Load (charge de la base de données). Les utilisateurs de la console peuvent sélectionner la période qu'ils veulent visualiser.

Q : Dois-je effectuer des actions spéciales sur ma base de données pour activer Performance Insights ?

Non. Cependant, Performance Insights fonctionnera encore mieux sur certains moteurs de base de données quand un suivi de performances supplémentaire est activé. Par exemple, lorsque l'extension pg_stat_statement est activée sur RDS PostgreSQL ou Aurora PostgreSQL, Performance Insights utilisera l'identificateur SQL natif PostgreSQL pour identifier l'instruction et pourra collecter le texte complet d'instructions plus longues. Dans MySQL, l'activation du schéma de performance autorisera Performance Insights à collecter des détails biens plus riches et approfondis sur les événements d'attente affectant la base de données.

Q : L'activation de Performance Insights affectera-t-elle les performances de ma base de données ?

L'agent Performance Insights est conçu pour rester à l'écart des charges de travail de base de données. Performance Insights s'exécute avec une priorité la plus basse que celle des autres processus sur votre instance, et surveille l'état de l'hôte et de la base de données. Lorsque Performance Insights détecte une charge lourde ou des ressources réduites, il se retire de la fréquence habituelle de regroupement de données, tout en continuant la collecte, mais seulement si ça n'affecte rien. Des options de base de données, comme pg_stat_statement dans RDS PostgreSQL et Aurora PostgreSQL, et le schéma de performances (Performance Schema) dans MySQL peuvent utiliser certaines ressources de base de données et avoir potentiellement un impact sur les performances. L'effet de l'activation de ces options sur un système particulier affectera la charge de travail de l'application. AWS recommande de tester les options de base de données sur votre charge de travail avant de les activer sur un système de production.

Q : Dois-je continuer à utiliser Enhanced Monitoring ou utiliser seulement Performance Insights ?

Les clients qui utilisent Enhanced Monitoring pour surveiller les métriques d'entrée/sortie doivent continuer d'obtenir ces données via Enhanced Monitoring. Au cours des mois à venir, ces données, ainsi qu'un ensemble étendu de métriques de base de données, seront mis à disposition via la console Performance Insights et une API. Les clients pourront alors obtenir toutes les données de performances à partir de Performance Insights. Enhanced Monitoring restera disponible pour les clients qui préfèrent l'utiliser, mais nous encouragerons nos clients à standardiser la surveillance de leur base de données sur Performance Insights.

Q : Les données sont-elle stockées chiffrées dans Performance Insights ?

Oui. Performance Insights chiffre toutes les données potentiellement sensibles à l'aide votre propre clé KMS. Les données sont chiffrées en transit et au repos. Le personnel AWS ne peut pas accéder à des données de performances potentiellement sensibles ou les consulter. Seuls les utilisateurs de votre compte AWS avec un accès complet à RDS peuvent afficher Performance Insights. Vous pouvez révoquer l'octroi de RDS pour votre clé KMS, ce qui nous permet de traiter et afficher vos données de performances à tout moment.

Q : Si je désactive Performance Insights, les données sont-elles conservées par AWS ou supprimées ?

L'offre gratuite de conservation des données de performance est limitée à un jour. Si vous désactivez Performance Insights sur une instance, vos données de performances pour cette instance sont supprimées.

Q : Que se passe-t-il pour la conservation des données de Performance Insights lorsque j'arrête mon instance de base de données RDS ?

L'arrêt d'une instance RDS pour laquelle Performance Insights est activé n'a aucun effet sur la conservation ou la visibilité de données historiques pour cette instance. La période pendant laquelle l'instance a été arrêtée ne contiendra simplement aucune donnée.

Q : Comment vais-je faire interagir Performance Insights avec mes outils de performances existants ?

Au cours des mois à venir, Performance Insights exposera une API disponible publiquement, conçue pour permettre aux clients et aux tiers de tirer parti des précieuses données de Performance Insights.

Q : Existe-t-il un moyen pour que des outils de performances tiers s'intègrent à Performance Insights ?

Au cours des mois à venir, Performance Insights exposera une API disponible publiquement, conçue pour permettre aux clients et aux tiers de tirer parti des précieuses données de Performance Insights.

Q : Performance Insights sera-t-il disponible dans la région AWS où se trouve RDS ?

Oui. Performance Insights sera initialement disponible dans quatre régions : USA Est (Virginie du Nord, Ohio), USA Ouest (Oregon) et UE (Irlande). Avec le temps, la fonction sera mise à disposition dans toutes les régions où RDS est pris en charge.

Q : Puis-je activer Performance Insights sur des instances existantes, ou seulement sur des nouvelles ?

Oui, Performance Insights peut être activé sur des instances existantes en modifiant l'instance pour activer Performance Insights. Performance Insights peut être activé sur de nouvelles instances en spécifiant que Performance Insights doit être activé lors de la création de l'instance.

Q : Performance Insights utilise-t-il du stockage sur mon instance de base de données ?

Non. Performance Insights ne consomme pas d'espace de stockage sur vos instances RDS.

Q : Performance Insights présentera-t-il des différences en s'exécutant sur des moteurs de bases de données différents et si oui, lesquelles ?

Performance Insights est conçu pour offrir une approche et une présentation communes pour son réglage sur tous les moteurs de bases de données dans RDS. Comme certains attributs comme les événements d'attente et les identificateurs SQL varient selon le type de moteur, ils varieront naturellement dans Performance Insights lorsqu'ils seront utilisés sur des moteurs de bases de données différents. L'un des principes de base de Performance Insights est de laisser intacts les concepts, les identificateurs et les attributs d'un moteur de bases de données. Performance Insights réinterceptera ou renommera rarement les événements d'attente sur d'autres attributs spécifiques des moteurs, mais les présentera fidèlement tels que reportés dans le moteur de base de données.

Q : Performance Insights fonctionne-t-il sur les instances Multi-AZ et les instances de réplica en lecture ?

Oui. Si une base de données RDS est Multi-AZ (utilise plusieurs zones de disponibilité) et que Performance Insights est activé pour celle-ci, Performance Insights restera activé quand et si cette instance bascule vers une autre zone de disponibilité. Comme les réplicas en lecture sont des instances indépendantes, les clients peuvent activer ou désactiver Performance Insights sur ces instances.

Q : Puis-je exporter mes données à partir de Performance Insights ?

Au cours des mois à venir, Performance Insights ajoutera une fonctionnalité permettant d'exporter les données.

Q : Puis-je réimporter mes données dans Performance Insights ultérieurement pour effectuer une analyse de performance ?

Non. Performance Insights affiche uniquement les données qui ont été collectées directement depuis une instance. Les données obtenues via Performance Insights seront disponibles dans les mois à venir par une API. Ensuite, l'analyse peut être effectuée avec l'un des services d'analyse dans AWS, comme Amazon Athena, Amazon Redshift, Amazon Redshift Spectrum et Amazon Quicksight.