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 n’est 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 à l’aide du 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 que ceux 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 de tarification.

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 ?

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 obtenir 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 prend 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 plus d'informations, consultez la section Bonnes pratiques de migration de bases de données MySQL vers 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 prend 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.

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 de tarification.

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 : 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 au moteur de base de données une couche de stockage virtualisée basée sur SSD, conçue principalement pour les charges de travail des bases de données, ce qui permet de réduire les opérations d'écritures dans le système de stockage, minimiser la contention de verrouillage et éliminer les retards 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 MySQL 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 au moteur de base de données une couche de stockage virtualisée basée sur SSD, conçue principalement pour les charges de travail des bases de données, ce qui permet de réduire les opérations d'écritures dans le système de stockage, minimiser la contention de verrouillage et éliminer les retards 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 MySQL ?

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.

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 de base de données ?

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 de bases de données 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 6 copies de vos données dans 3 zones de disponibilité et tentera automatiquement de récupérer 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 de bases de données automatisés si je supprime mon instance de base de données ?

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 de bases de données sont conservés après la suppression de l'instance de base de données (c'est-à-dire que 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). Vous pouvez utiliser cette fonctionnalité pour partager des données entre vos différents environnements (production, dev/test, transfert, etc.) liés à des comptes AWS différents, ainsi que pour conserver des sauvegardes de toutes vos données dans un compte séparé 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 la 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 différentes régions ?

Vos instantanés (snapshots) Aurora partagés ne seront accessibles que par les comptes se trouvant dans 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 à la recherche d’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 le réplica sur plusieurs régions. Le réplica sur plusieurs régions fait office de réplica principal sur le cluster, et les réplicas Aurora auront généralement un retard de quelques dizaines de millisecondes par rapport à celui-ci.

Q : Puis-je faire basculer mon application du réplica principal vers le réplica sur plusieurs régions ?
Oui, vous pouvez définir votre réplica sur plusieurs régions comme étant le nouveau réplica principal 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é à certains réplicas en tant que cibles de basculement ?

Oui. Vous pouvez attribuer un niveau de priorité à chaque instance sur votre cluster. En cas d'échec de l'instance principale, Amazon RDS choisit le réplica dont le niveau de priorité est le plus élevé et le définit comme la nouvelle instance principale. En cas de conflit entre deux réplicas ou plus du même niveau de priorité, Amazon RDS choisit le 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 ?

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 certains réplicas d'être définis comme l'instance principale ?

Vous pouvez attribuer des niveaux de priorité inférieurs aux réplicas que vous ne souhaitez pas voir définis comme l'instance principale. Cependant, si les réplicas de niveau supérieur du cluster sont défectueux ou indisponibles pour quelque raison que ce soit, Amazon RDS choisit un 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 : À 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 ?

Los du 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é, permettant ainsi 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 démarrer avec 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 faire fonctionner 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 d’offrir un niveau de sécurité supplémentaire concernant 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: Puis-je utiliser Amazon Aurora avec des applications nécessitant une conformité HIPAA?

Oui, toutes les éditions de MySQL et de PostgreSQL d'Aurora sont conformes à la législation HIPAA. Vous pouvez donc les utiliser pour créer des applications compatibles HIPAA et stocker des informations relatives aux soins, y compris des informations médicales protégées (PHI) dans le cadre d'un Business Associate Agreement (BAA) signé avec AWS. Si vous avez déjà une BAA exécutée, aucune action n'est nécessaire pour commencer à utiliser ces services dans les comptes couverts par votre BAA. Si vous n'avez pas de BAA exécutée avec AWS ou si vous avez d'autres questions concernant les applications compatibles HIPAA sur AWS, contactez-nous.

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

Amazon Aurora sans serveur est une configuration à dimensionnement automatique et à la demande pour l'édition d'Amazon Aurora compatible avec MySQL. Un cluster de base de données Aurora sans serveur démarre, s’arrête et augmente ou réduit la capacité en fonction des besoins de votre application, le tout de manière automatique. Aurora sans serveur offre une option relativement simple et économique pour les charges de travail peu fréquentes, intermittentes ou imprévisibles. Vous pouvez en apprendre davantage sur le sujet dans le Guide de l’utilisateur d’Amazon Aurora.

Q : Quelles versions d’Amazon Aurora sont compatibles avec Aurora sans serveur ?

Aurora sans serveur est actuellement disponible pour Aurora avec compatibilité MySQL 5.6.

Q : Puis-je migrer un cluster de base de données Aurora existant vers Aurora sans serveur ?

Oui, vous pouvez restaurer un instantané capturé à partir d’un cluster existant mis en service dans Aurora au sein d’un cluster de base de données Aurora sans serveur (et vice-versa).

Q : Comment puis-je me connecter à un cluster de base de données Aurora sans serveur ?

Vous devez accéder à un cluster de base de données Aurora sans serveur depuis une application cliente s’exécutant dans le même VPC (Amazon Virtual Private Cloud). Vous ne pouvez pas attribuer une adresse IP publique à un cluster de base de données Aurora sans serveur.

Q : Puis-je définir explicitement la capacité d’un cluster Aurora sans serveur ?

Bien qu’Aurora sans serveur se mette à l’échelle automatiquement en fonction de la charge de travail active de la base de données, il arrive, dans certains cas, que la capacité ne se dimensionne pas assez vite pour répondre à une modification soudaine de la charge de travail, telle qu’un grand nombre de nouvelles transactions. Dans ce cas, vous pouvez définir explicitement la capacité sur une valeur spécifique à l’aide d’AWS Management Console, de l’interface de ligne de commande AWS ou de l’API RDS.

Q : Pourquoi mon cluster de base de données Aurora sans serveur ne se met-il pas à l’échelle automatiquement ?

Une fois qu’une opération de mise à l’échelle est lancée, Aurora sans serveur essaie de trouver un point de dimensionnement, c’est-à-dire un instant auquel la base de données peut effectuer la mise à l’échelle en toute sécurité. Si vous avez des transactions ou des requêtes de longue durée en cours, ou si des verrouillages de tableaux ou des tableaux temporaires sont en cours d’utilisation, il est possible qu’Aurora sans serveur ne parvienne pas à trouver un point de dimensionnement.

Q : Comment Aurora sans serveur est-il facturé ?

Dans Aurora sans serveur, la capacité de base de données est mesurée en Unités de capacité Aurora (Aurora Capacity Unit ou ACU). Vous payez un prix fixe d'utilisation d'ACU par seconde, avec un minimum de cinq minutes d'utilisation à chaque fois que la base de données est activée. Les prix du stockage et des E/S sont identiques pour la configuration standard et la configuration sans serveur. Découvrez un exemple de tarification d’Aurora sans serveur.