FAQ sur Amazon Aurora

Amazon Aurora est un service de base de données relationnelle moderne offrant des performances et une haute disponibilité à grande échelle. Il propose également des éditions entièrement compatibles avec MySQL et PostgreSQL en open source ainsi qu’une gamme d’outils de développement pour créer des applications sans serveur et axées sur le machine learning (ML).

Aurora comprend un système de stockage distribué, tolérant aux pannes et autoréparateur, qui est découplé à partir des ressources de calcul et qui augmente verticalement de manière automatique jusqu’à atteindre 256 Tio par instance de base de données. Il affiche des performances et une disponibilité élevées avec jusqu’à 15 réplicas en lecture à faible latence, une reprise ponctuelle, une sauvegarde continue sur Amazon Simple Storage Service (Amazon S3) et une réplication sur trois zones de disponibilité (AZ).

Amazon Aurora est aussi un service entièrement géré qui automatise les tâches d’administration chronophages comme la mise en service de matériel, la configuration de base de données, l’application de correctifs et les sauvegardes, tout en fournissant la sécurité, la disponibilité et la fiabilité des bases de données commerciales à un dixième du coût.

Amazon Aurora est directement compatible avec les bases de données open source MySQL existantes et ajoute régulièrement la prise en charge des nouvelles versions. Cela signifie que vous pouvez effectuer la migration de bases de données MySQL en toute simplicité vers et depuis Aurora grâce aux outils d’importation/exportation standard ou aux instantanés. Cela signifie aussi que la plupart des codes, applications, pilotes et outils que vous utilisez déjà avec vos bases de données MySQL aujourd'hui peuvent être utilisés avec Aurora en apportant peu de modifications, voire aucune. Cela permet de facilement déplacer des applications entre deux moteurs.

Vous pouvez consulter les informations de compatibilité de la version actuelle d’Amazon Aurora MySQL dans la documentation.

Amazon prend entièrement en charge Aurora PostgreSQL et toutes les extensions disponibles avec Aurora. Si vous avez besoin d'une assistance pour Aurora PostgreSQL, veuillez contacter AWS Support. Si vous avez un compte AWS Premium Support actif, vous pouvez contacter AWS Premium Support pour les problèmes spécifiques à Amazon Aurora.

Amazon Aurora est directement compatible avec les bases de données open source PostgreSQL existantes et ajoute régulièrement la prise en charge des nouvelles versions. Ainsi, vous pouvez effectuer en toute simplicité la migration de bases de données PostgreSQL vers et à partir d’Aurora à l’aide d’outils d’importation/exportation standards ou à l’aide d’instantanés. Vous pouvez également utiliser avec Aurora la plupart des codes, applications, pilotes et outils que vous utilisez déjà avec vos bases de données PostgreSQL, en y apportant peu de modifications, voire aucune.

Vous pouvez consulter les informations de compatibilité de la version actuelle d’Amazon Aurora PostgreSQL dans la documentation.

Pour essayer Aurora, connectez‑vous à la Console de gestion AWS, sélectionnez RDS dans la catégorie Base de données, puis sélectionnez Amazon Aurora comme moteur de base de données. Pour davantage de recommandations et de ressources, consultez la section Démarrage avec Amazon Aurora.

Vous pouvez consulter la disponibilité régionale pour Aurora ici.

Si vous souhaitez migrer de PostgreSQL vers Aurora et inversement, plusieurs options s'offrent à vous :

• 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 également utiliser la fonctionnalité de migration d’instantané de base de données RDS pour procéder à la migration d’un instantané de base de données Amazon RDS pour PostgreSQL vers Aurora à l’aide de la Console de gestion AWS.

La migration vers Aurora prend moins d’une heure pour la plupart des clients, bien que la durée dépende du format et de la taille du jeu de données.

Pour procéder à la migration des bases de données SQL Server vers l’édition d’Amazon Aurora compatible avec PostgreSQL, vous pouvez utiliser Babelfish pour Aurora PostgreSQL. Vos applications fonctionneront sans aucun changement. Pour en savoir plus, consultez la documentation de Babelfish.

Si vous souhaitez migrer de MySQL vers Aurora et inversement, plusieurs options s'offrent à vous :

• 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 également utiliser la fonctionnalité de migration d’instantané de base de données Amazon RDS pour procéder à la migration d’un instantané de base de données Amazon RDS for MySQL vers Aurora à l’aide de la Console de gestion AWS.

La migration vers Aurora prend moins d’une heure pour la plupart des clients, bien que la durée dépende du format et de la taille du jeu de données. Pour plus d’informations, consultez la section Pratiques exemplaires en matière de migration de bases de données MySQL vers Amazon Aurora.

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

Amazon Aurora apporte 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 applications des bases de données, ce qui permet de réduire les opérations d'écritures dans le système de stockage, de minimaliser les conflits de verrouillage et d'é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 requêtes SELECT par seconde et 100 000 requêtes UPDATE 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 guide Amazon Aurora MySQL‑Compatible Edition Performance Benchmarking Guide.

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, les conflits de verrouillage et éliminant les délais créés par les threads de processus de la base de données.

Nos tests avec SysBench sur des instances r4.16xlarge montrent qu’Amazon Aurora offre des performances de requête SELECT par seconde et de requête UPDATE par seconde trois fois supérieures à celles de PostgreSQL exécutant le même test de performance sur 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 guide Amazon Aurora PostgreSQL‑Compatible Edition Performance Benchmarking Guide.

Amazon Aurora est conçu pour être compatible avec MySQL. Les utilisateurs peuvent ainsi exécuter leurs applications et leurs outils MySQL existants sans y apporter de modification. Cependant, Amazon Aurora améliore MySQL dans un domaine particulier : les charges de travail hautement concurrentes. 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.

Amazon Aurora est conçu pour être compatible avec PostgreSQL. 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 hautement 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.

Pour plus d’informations sur la tarification en vigueur, consultez la page de tarification d’Aurora.

Il n'existe aucune offre gratuite d'AWS pour Aurora pour le moment. Toutefois, Aurora stocke durablement vos données sur trois zones de disponibilité dans une région et ne facture qu'une seule copie des données. Les sauvegardes représentant jusqu'à 100 % de la taille de votre cluster de bases de données ne vous sont pas facturées. Les instantanés ne vous sont pas non plus facturés pendant la période de conservation des sauvegardes que vous avez configurée pour votre cluster de bases de données.

Oui, vous pouvez souscrire à un Database Savings Plan pour votre utilisation d’Amazon Aurora et réduire vos coûts jusqu’à 35 % lorsque vous vous engagez à utiliser un volume constant pendant une période d’un an. Vous trouverez des informations supplémentaires sur les utilisations éligibles sur la page de tarification des Database Savings Plans.

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

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 émet des transactions de lecture sur la couche de stockage afin de récupérer les pages de bases de données qui ne sont pas présentes dans la mémoire ou dans le cache :

• Si votre trafic de requêtes peut être entièrement servi à partir de la mémoire ou du cache, aucune récupération de page de données de la mémoire ne vous sera facturée.
• Dans le cas contraire, toutes les pages de données qui doivent être extraites du stockage vous seront facturées.
  Chaque page de base de données représente 16 Ko dans l’édition compatible avec MySQL d’Amazon Aurora et 8 Ko avec l’édition compatible avec PostgreSQL d’Amazon Aurora.

Le système 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 pour gérer le trafic de lecture/écriture. Les E/S d’écriture ne sont consommées qu’en cas de persistance d’enregistrements de journal de reprise dans l’édition compatible avec MySQL d’Aurora ou d’enregistrements de journaux d’écriture en avance dans l’édition compatible avec PostgreSQL d’Aurora vers la couche de stockage dans le but de rendre les écritures durables.

Les opérations d'E/S en écriture sont comptées en unités de 4 Ko. Par exemple, un enregistrement de journal de 1,024 octets comptera comme une opération d'E/S en écriture. Mais si l'enregistrement de journal dépasse 4 Ko, il faudra plus d'une opération d'E/S en écriture pour le rendre persistant.

Cependant, les opérations d'écriture simultanées dont le fichier journal de transactions 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 des E/S. Contrairement aux moteurs de base de données traditionnels, Aurora n'évacue jamais les pages de données imprécises vers le stockage.

Vous pouvez voir le nombre d'I/O consommées par votre instance Aurora en vérifiant la console de gestion AWS. Pour connaître votre consommation d’E/S, allez dans la section Amazon RDS de la console, regardez votre liste d’instances, sélectionnez vos instances Aurora, puis recherchez les métriques «VolumeReadIOPs» et «VolumeWriteIOPs» dans la section de surveillance.

Pour plus d’informations sur la tarification des opérations d’E/S, consultez la page de tarification d’Aurora. Les opérations d’E/S en lecture et en écriture vous sont facturées lorsque vous configurez vos clusters de bases de données selon la configuration Aurora Standard. Les opérations d’E/S en lecture et en écriture ne vous sont pas facturées lorsque vous configurez vos clusters de bases de données pour la version optimisée E/S d’Amazon Aurora.

Aurora vous offre la flexibilité nécessaire pour optimiser les dépenses liées à votre base de données en choisissant entre deux options de configuration en fonction de vos besoins en termes de performances et de prévisibilité des prix. Les deux options de configuration sont Aurora Standard et Aurora I/O Optimized. Aucune de ces options ne nécessite d'E/S ni de provisionnement du stockage en amont, et les deux options peuvent adapter les opérations d'E/S pour prendre en charge vos applications les plus exigeantes.

Aurora Standard est une configuration de cluster de base de données qui offre des tarifs abordables pour la grande majorité des applications avec une utilisation faible à modérée des E/S. Avec Aurora Standard, vous payez pour les instances de base de données, le stockage et les E/S payantes à la demande.

Aurora I/O Optimized est une configuration de cluster de bases de données qui offre un meilleur rapport prix/performances pour les applications gourmandes en E/S telles que les systèmes de traitement des paiements, les systèmes de commerce électronique et les applications financières. Aussi, si vos dépenses en E/S dépassent 25 % de vos dépenses totales en bases de données Aurora, vous pouvez économiser jusqu'à 40 % sur les coûts des charges de travail intensives en E/S grâce à Aurora I/O-Optimized. La version optimisée E/S d’Aurora offre une tarification prévisible pour toutes les applications, car les opérations d’E/S en lecture et en écriture ne sont pas facturées, ce qui rend cette configuration idéale pour les charges de travail présentant une grande variabilité en termes d’E/S.

La version optimisée E/S d’Aurora est le choix idéal lorsque vous avez besoin de coûts prévisibles pour n’importe quelle application. Il offre un meilleur rapport prix/performances pour les applications gourmandes en E/S, qui nécessitent un débit d'écriture élevé ou qui exécutent des requêtes analytiques traitant de grandes quantités de données. Pour les clients dont les dépenses en E/S dépassent 25 % de leur facture Aurora, vous pouvez économiser jusqu’à 40 % sur les coûts liés aux charges de travail intensives en E/S grâce à la version optimisée E/S d’Aurora.

Vous pouvez utiliser l'expérience en un clic disponible dans la console de gestion AWS pour modifier le type de stockage de vos clusters de bases de données existants afin qu'il soit optimisé pour les E/S Aurora. Vous pouvez également appeler l’interface de la ligne de commande AWS (AWS CLI) ou le kit SDK AWS pour effectuer cette modification.

Vous pouvez migrer vos clusters de bases de données existants tous les 30 jours vers Aurora I/O Optimized. Vous pouvez revenir à Aurora Standard à tout moment.

Oui, Aurora I/O Optimized fonctionne avec les instances réservées Aurora existantes. Aurora prend automatiquement en compte la différence de prix entre Aurora Standard et Aurora I/O Optimized with Reserved Instances. Grâce aux remises sur les instances réservées et à la version optimisée E/S d’Aurora, vous pouvez réaliser encore plus d’économies sur vos dépenses d’E/S.

Aucun changement n’est apporté au prix du retour sur trace, des instantanés, de l’exportation ou de la sauvegarde continue avec la version optimisée E/S d’Aurora.

Oui, les frais liés aux opérations d’E/S requises pour répliquer les données entre les régions continuent de s’appliquer. La version optimisée E/S d’Aurora ne facture pas les opérations d’E/S en lecture et en écriture, ce qui est différent de la réplication de données.

Il n’y a pas de frais supplémentaires des lectures optimisées d’Amazon Aurora pour Aurora PostgreSQL en dehors du prix des instances R6id basées sur Intel et R6gd basées sur Graviton. Pour plus d’informations, consultez la page de tarification d’Aurora.

L’espace de stockage minimal est de 10 Gio. Selon l’usage que vous faites de votre base de données, votre stockage Aurora augmentera automatiquement jusqu’à 256 Tio, par paliers de 10 Gio, sans affecter les performances de la base de données. Il n’est pas nécessaire d’allouer un espace de stockage à l’avance. Aurora propose une mise à l’échelle horizontale automatisée avec la base de données illimitée Amazon Aurora PostgreSQL, qui met à l’échelle le stockage au-delà de 256 Tio. Pour en savoir plus, consultez la section Utilisation de la base de données illimitée Amazon Aurora PostgreSQL.

Il existe trois manières de mettre à l’échelle les ressources de calcul associées à votre base de données Amazon Aurora : en utilisant Amazon Aurora sans serveur, la base de données illimitée Amazon Aurora PostgreSQL ou la mise à l’échelle manuelle. Quelle que soit l’option que vous choisissez, vous ne payez que ce que vous utilisez.

Pour mettre à l’échelle les ressources de calcul de base de données en fonction de la demande de l’application, vous pouvez utiliser Aurora sans serveur, une configuration à la demande et à mise à l’échelle automatique pour Aurora. Cela vous permet d’exécuter votre base de données dans le cloud sans vous soucier de la gestion de capacité de base de données. Vous pouvez spécifier la plage de capacité de base de données souhaitée. Votre base de données se mettra à l’échelle en fonction des besoins de votre application. Apprenez-en plus dans le Guide de l’utilisateur Aurora sans serveur.

Avec la base de données illimitée Amazon Aurora PostgreSQL, vous pouvez automatiquement mettre à l’échelle vos ressources de calcul horizontalement en fonction des exigences de votre charge de travail pour prendre en charge des applications à grande échelle. Elle vous permet de mettre à l’échelle vos applications au-delà des limites de débit d’écriture et de stockage d’une seule instance de base de données tout en conservant la simplicité de fonctionnement au sein d’une base de données unique. 

Vous pouvez également mettre à l’échelle manuellementvos ressources de calcul associées à votre base de données, en sélectionnant le type d’instance de base de données souhaité dans la Console de gestion AWS. La modification requise sera appliquée lors de la fenêtre de maintenance spécifiée. Vous pouvez également utiliser l’indicateur « Appliquer immédiatement » afin de modifier le type d’instance de base de données immédiatement.

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

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

Amazon Aurora assure automatiquement la pérennité de vos données dans trois zones de disponibilité (AZ) d’une région et tente automatiquement de récupérer votre base de données dans une AZ saine sans 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é de bases de données ou effectuer une opération de restauration ponctuelle dans une nouvelle instance. Notez que la dernière heure de restauration possible pour une opération de restauration ponctuelle peut remonter jusqu’à cinq minutes dans le passé.

Vous pouvez choisir de créer un instantané de base de données final au moment de supprimer votre instance de base de données. De cette manière, vous pourrez utiliser cet instantané de base de données pour restaurer l'instance de base de données supprimée ultérieurement. Amazon Aurora conserve cet instantané de base de données final créé par l'utilisateur avec les autres instantanés de base de données créés manuellement, et ce, même après la suppression de l'instance de base de données. 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 ponctuelle ne sont pas conservées).

Oui. Aurora vous offre la possibilité de créer des instantanés 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.

Le partage d'instantanés entre les comptes ne fait pas l'objet de frais supplémentaires. Toutefois, vous pourrez être facturé pour les instantanés en eux-mêmes, ainsi que pour les bases de données restaurées à partir d’instantanés partagés. Découvrez plus en détail la tarification d’Aurora.

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

Vous pouvez partager les instantanés 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.

Vous pouvez partager vos instantanés Aurora dans toutes les Régions AWS où Aurora est disponible.

Non. Vos instantanés Aurora partagés ne seront accessibles qu’aux comptes se trouvant dans la même région que le compte qui les partage.

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

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.

Contrairement aux autres bases de données, après le plantage d'une base de données, Amazon Aurora ne doit pas relire le journal de reprise du dernier point de contrôle pour la base de données (généralement cinq minutes) et confirmer tous les changements qui y ont été apportés, avant de mettre à disposition la base de données pour effectuer des opérations. Cela permet de réduire la durée 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.

L’édition compatible avec MySQL d’Amazon Aurora et celle compatible avec PostgreSQL prennent en charge les réplicas Amazon Aurora, qui partagent le même volume sous‑jacent que l’instance primaire dans la même région AWS. Les mises à jour effectuées par l’instance primaire sont visibles sur tous les réplicas Amazon Aurora.

Avec l’édition compatible avec MySQL d’Amazon Aurora, vous pouvez aussi créer des réplicas en lecture MySQL entre régions axés sur le moteur de réplication de journaux binaires (binlog) de MySQL. Dans les réplicas en lecture MySQL, les données de votre instance primaire sont lues à nouveau sur votre réplica en tant que transactions. Dans la plupart des cas d’utilisation, y compris la mise à l’échelle 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 :

Vous avez deux options de réplications additionnelles en sus de celles ci-dessus. Vous pouvez utiliser Amazon Global Database pour accélérer davantage la réplication entre des clusters Aurora situés dans différentes régions. Pour la réplication entre des bases de données de l’édition compatible avec MySQL d’Aurora et non-Aurora (même hors d’AWS), vous pouvez configurer votre propre réplication de journaux binaires (binlog) autogérée.

Oui, vous pouvez configurer des réplicas Aurora entre régions à l’aide d’une réplication physique ou logique. La réplication physique, nommée Amazon Aurora Global Database, utilise une infrastructure dédiée permettant à vos bases de données d’être entièrement disponibles pour servir votre application. Elle peut répliquer jusqu’à cinq régions secondaires avec une latence généralement inférieure à une seconde. Elle est disponible pour l’édition compatible avec MySQL d’Aurora et l’édition compatible avec PostgreSQL d’Amazon Aurora.

Pour les lectures globales à faible temps de latence et la reprise après sinistre, nous vous recommandons d'utiliser Amazon Aurora Global Database.
Aurora prend en charge la réplication logique native dans chaque moteur de base de données (binlog pour MySQL et compartiments de réplication PostgreSQL pour PostgreSQL), de sorte que vous pouvez répliquer vers des bases de données Aurora et non-Aurora, même entre les régions.

L'édition compatible avec Aurora MySQL offre également une fonction de réplica en lecture logique inter-régions facile à utiliser qui prend en charge jusqu'à cinq régions AWS secondaires. Elle est basée sur une réplication de journal binaire MySQL à thread unique, et le délai de réplication est affecté par le taux de changement/d’application et les délais de communication réseau entre les régions sélectionnées.

Oui, vous pouvez ajouter jusqu’à 15 réplicas Aurora sur chaque cluster interrégionaux, qui partageront le même espace de stockage sous-jacent que le réplica interrégional. Un réplica interrégional fait office de réplica principal sur le cluster, et les réplicas Aurora sur le cluster auront généralement un retard de quelques dizaines de millisecondes par rapport au réplica principal.

Oui, vous pouvez promouvoir votre réplica entre régions comme réplica principal depuis la console Amazon RDS. Pour la réplication logique (journaux binaires, binlogs), le processus de promotion dure généralement quelques minutes, selon votre charge de travail. La réplication entre régions s'arrête quand le processus de promotion est lancé.

Avec Amazon Aurora Global Database, vous pouvez promouvoir une région secondaire afin qu'elle prenne en charge l'intégralité des charges de travail en lecture/écriture en moins d'une minute.

Oui. Vous pouvez attribuer un niveau de priorité à chaque instance sur votre cluster. En cas d'échec de l'instance primaire, Amazon RDS choisit le réplica dont le niveau de priorité est le plus élevé et le définit comme la nouvelle instance primaire. Si au moins deux réplicas Aurora ont la même priorité, Amazon RDS utilise le réplica de plus grande taille. Si au moins deux réplicas Aurora ont la même priorité et la même taille, Amazon RDS utilise un réplica arbitraire dans le même niveau de promotion.

Pour en savoir plus sur la logique de basculement, consultez le Guide de l’utilisateur Amazon Aurora.

Oui, 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 basculement.

Vous pouvez attribuer des niveaux de priorité inférieurs aux réplicas que vous ne souhaitez pas voir promus 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.

Vous pouvez ajouter des réplicas Amazon Aurora. Les réplicas Aurora de la même région AWS partagent le même espace de stockage sous-jacent en tant qu'instance primaire. Tout réplica Aurora peut être choisi comme 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 d'échec de l'instance de base de données primaire.

Pour augmenter la disponibilité de la base de données, il suffit de créer un à 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. Vous pouvez utiliser Amazon Aurora Global Database si vous souhaitez que votre base de données couvre plusieurs régions AWS. Cela répliquera vos données sans incidence sur les performances de la base de données et assurera une reprise après sinistre à la suite de pannes survenues dans la région.

Le basculement est automatiquement géré par Amazon Aurora afin que vos applications puissent reprendre vos opérations de base de données aussi vite que possible, sans intervention manuelle d’un administrateur.

• Si vous disposez d’une réplique Aurora dans la même zone de référence ou dans une zone différente lors du basculement, Aurora inverse l’enregistrement de nom canonique (CNAME) de votre instance de base de données afin de pointer vers la réplique saine, qui est promue au rang de nouvelle réplique principale. Du début à la fin, le basculement s’effectue généralement en 30 secondes. Pour améliorer la résilience et accélérer les basculements, vous pouvez utiliser le Proxy Amazon RDS qui se connecte automatiquement à l’instance de base de données de basculement, tout en préservant les connexions des applications. Le proxy rend les basculements transparents pour vos applications et réduit les temps de basculement jusqu’à 66 %. 
• Aurora Serverless v2 fonctionne selon le provisionnement pour le basculement et d’autres fonctions de haute disponibilité. Pour plus d’informations, consultez la section Aurora Serverless v2 and high availability.
  
• Si vous ne disposez pas d’une réplique Aurora (c’est-à-dire d’une instance unique) et que vous n’exécutez pas Aurora sans serveur, Aurora tentera de créer une nouvelle instance de base de données dans la même zone de disponibilité que l’instance d’origine. Ce remplacement de l'instance d'origine s'effectue de manière optimale et peut échouer, par exemple s'il existe un problème qui affecte de manière générale la zone de disponibilité.

Votre application doit tenter une nouvelle connexion à la base de données dans le cas d'une perte de connexion. La reprise après sinistre entre les régions est un processus manuel, qui consiste à promouvoir une région secondaire pour prendre en charge les charges de travail en lecture/écriture.

Amazon Aurora détectera automatiquement un problème dans votre instance primaire et déclenchera un basculement. Si vous utilisez le point de terminaison d'un cluster, vos connexions en lecture/écriture sont automatiquement redirigées vers un réplica Amazon Aurora qui devient l'instance primaire.

En outre, le trafic en lecture traité par vos réplicas Aurora sera interrompu momentanément. Si vous utilisez le point de terminaison du lecteur du cluster pour diriger votre trafic en lecture vers le réplica Aurora, les connexions en lecture seule sont dirigées vers le réplica Aurora récemment promu jusqu’à ce que l’ancien nœud primaire soit récupéré en tant que réplica.

Oui, vous pouvez configurer une réplication de journaux binaires (binlog) entre une instance de l’édition compatible avec MySQL Aurora et une base de données MySQL externe. L'autre base de données peut s'exécuter sur Amazon RDS ou comme une base de données autogérée sur AWS ou encore entièrement en dehors d'AWS.

Si vous utilisez l'édition compatible avec MySQL Aurora 5.7, vous devrez configurer une réplication binlog basée sur GTID. Vous bénéficierez ainsi d’une cohérence totale, et votre réplication ne manquera aucune transaction ou ne générera pas de conflits, même après un basculement ou un temps d’arrêt.

Comme les réplicas Amazon Aurora partagent le même volume de données que l'instance primaire dans la même région AWS, il n'y a quasiment pas de retard de réplication. Nous constatons généralement des périodes de retard de l'ordre de dizaines de millisecondes.

Pour la réplication entre les régions, le retard de réplication logique basé sur le binlog peut croître indéfiniment en fonction du taux de changement/application ainsi que des retards dans la communication réseau. Cependant, dans des conditions normales, le retard de réplication est généralement inférieur à une minute. Les réplicas entre régions utilisant Amazon Aurora Global Database auront généralement un délai inférieur à une seconde.

Amazon Aurora Global Database est une fonctionnalité qui permet à une seule base de données Amazon Aurora de couvrir plusieurs Régions AWS. Elle réplique vos données sans impact sur les performances de la base de données, permet des lectures locales rapides dans chaque région avec une latence en général de moins d’une seconde et assure une reprise après sinistre à la suite de pannes survenues dans la région. Dans l'éventualité peu probable d'une dégradation ou d'une panne régionale, une région secondaire peut être choisie pour des fonctionnalités de lecture et d'écriture complètes en moins d'une minute. Cette fonction est disponible pour Aurora MySQL-Compatible Edition et Aurora PostgreSQL-Compatible Edition.

Vous pouvez créer une base de données globale Aurora en quelques clics dans la console Amazon RDS. De même, vous pouvez utiliser le kit de développement logiciel (SDK) AWS ou l’interface de ligne de commande AWS (CLI). Vous pouvez utiliser une configuration mixte de types de classes d’instance provisionnées ou sans serveur entre vos régions principale et secondaire. Vous pouvez également configurer votre région principale en tant que configuration de cluster optimisée pour les E/S Amazon Aurora, et vos régions secondaires en tant que configuration Aurora Standard ou l’inverse. Pour en savoir plus, consultez la section Création d’une Amazon Aurora Global Database.

Vous pouvez créer jusqu’à cinq régions secondaires pour une base de données Amazon Aurora Global Database.

Oui. Si votre objectif est d’analyser l’activité de la base de données, envisagez plutôt d’utiliser l’audit avancé, les journaux généraux et les journaux de requêtes lentes Aurora, afin d’éviter toute incidence sur les performances de votre base de données.

Non. Si votre région principale devient indisponible, vous pouvez utiliser l’opération de basculement global de la base de données Aurora interrégionale gérée pour promouvoir une région secondaire afin qu’elle prenne en charge l’intégralité des capacités de lecture et d’écriture. Vous pouvez également utiliser le point de terminaison rédacteur Aurora Global Database pour éviter d’avoir à modifier le code de l’application pour vous connecter à la région nouvellement promue. Pour en savoir plus, consultez la rubrique Connexion à Amazon Aurora Global Database.

Oui, toutes les instances de base de données 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.

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 (AWS 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 d’AWS KMS avec Amazon Aurora, consultez le Guide de l’utilisateur Amazon RDS.

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.

Vous devez accéder à vos bases de données Aurora via le port de base de données saisi lors de la création de celle‑ci. Cela permet d’ajouter une couche de sécurité supplémentaire pour vos données. Vous trouverez des instructions détaillées pour vous connecter à votre base de données Amazon Aurora dans le guide Amazon Aurora Connectivity Guide.

Oui, l’édition d’Amazon Aurora compatible avec MySQL et celle compatible avec PostgreSQL sont compatibles avec les exigences de la loi HIPAA. Vous pouvez les utiliser pour créer des applications conformes à la loi HIPAA et stocker des informations relatives aux soins de santé, y compris des informations sanitaires protégées (PHI), dans le cadre d’un addendum d’associé commercial (BAA) signé avec AWS. Si vous avez déjà conclu un BAA avec AWS, aucune autre action n’est nécessaire pour commencer à utiliser ces services dans le ou les comptes couverts par votre BAA. Pour plus d’informations sur l’utilisation d’AWS pour créer des applications conformes, consultez la section Prestataires de soins de santé.

Actuellement, vous pouvez consulter la liste des vulnérabilités de sécurité CVE dans la section Amazon Aurora Security Updates.

Le système Aurora est intégré à Amazon GuardDuty afin de faciliter l’identification des menaces potentielles pour les données stockées dans les bases de données Aurora. GuardDuty RDS Protection profile et surveille l’activité de connexion et les nouvelles bases de données de votre compte, et utilise des modèles ML adaptés pour détecter les connexions suspectes aux bases de données Aurora. Pour plus d’informations, consultez la section Monitoring threats with GuardDuty RDS Protection et le Guide de l’utilisateur de la Protection RDS GuardDuty.

Aurora sans serveur est une configuration à la demande avec une mise à l’échelle automatique pour Amazon Aurora. Avec Aurora sans serveur, vous pouvez exécuter votre base de données dans le cloud sans gérer la capacité de la base de données. La gestion manuelle de la capacité de la base de données peut prendre du temps et entraîner une utilisation inefficace des ressources de base de données. Avec Aurora sans serveur, vous créez une base de données, spécifiez sa plage de capacité en fonction de vos besoins et connectez vos applications. Aurora règle automatiquement la capacité dans la plage spécifiée en fonction des besoins de votre application.

Vous êtes facturé à la seconde pour la capacité de base de données que vous utilisez lorsque la base de données est active. Apprenez‑en davantage sur Aurora sans serveur et démarrez en quelques clics dans la console de gestion Amazon RDS.

Les informations sur la compatibilité avec Aurora sans serveur v2 sont disponibles ici.

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

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. Vous ne pouvez pas attribuer une adresse IP publique à une base de données d’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 mette pas à l’échelle 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 de la console de gestion AWS, de l’AWS CLI ou de l’API Amazon RDS.

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

Oui, vous pouvez commencer à utiliser Aurora sans serveur v2 afin de gérer la capacité de calcul de base de données de votre cluster de base de données Aurora existant. Un cluster contenant des instances allouées ainsi qu'Aurora sans serveur v2 est appelé cluster à configuration mixte. Vous pouvez décider d'avoir n'importe quelle combinaison d'instances allouées et d'Aurora sans serveur v2 dans votre cluster.

Afin de tester Aurora sans serveur v2, ajoutez un lecteur à votre cluster de base de données Aurora, puis sélectionnez « Serverless v2 » (Sans serveur v2) comme type d'instance. Une fois le lecteur créé et disponible, vous pouvez commencer à l'utiliser pour les charges de travail en lecture seule. Une fois que vous avez confirmé que le lecteur fonctionne correctement, vous pouvez lancer un basculement, afin de commencer à utiliser Aurora sans serveur v2 pour les lectures et les écritures. Cette option fournit une expérience à interruption minimale pour démarrer avec Aurora sans serveur v2.

Aurora sans serveur v2 prend en charge toutes les fonctionnalités d’Aurora provisionné, y compris les réplicas en lecture, la configuration multi‑AZ, Aurora Global Database, le Proxy RDS et l’Analyse des performances.

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 êtes facturé à un tarif fixe par seconde d’utilisation d’ACU. Les coûts de calcul liés à l’exécution de vos charges de travail sur Aurora sans serveur dépendent de la configuration du cluster de bases de données que vous choisissez : Aurora Standard ou la version optimisée E/S d’Aurora. Consultez la page de tarification Aurora pour obtenir des informations sur la tarification et la disponibilité régionale.

La base de données Aurora PostgreSQL Limitless fournit une mise à l’échelle horizontale automatisée pour traiter des millions de transactions d’écriture par seconde et gère des pétaoctets de données tout en conservant la simplicité de fonctionnement d’une base de données unique. Vous pouvez vous concentrer sur la création d’applications à grande échelle sans avoir à créer et à gérer des solutions complexes pour mettre à l’échelle vos données sur plusieurs instances de base de données afin de prendre en charge vos charges de travail. La base de données Aurora PostgreSQL Limitless se met à l’échelle en fonction de la charge de travail de votre application et vous ne payez que pour ce que consomme votre application. Pour en savoir plus, consultez le Guide de l’utilisateur de la base de données Aurora PostgreSQL Limitless.

Vous devez utiliser la base de données Aurora PostgreSQL Limitless pour les applications qui doivent être mises à l’échelle horizontalement et qui nécessitent un débit d’écriture ou une capacité de stockage de données supérieurs à ceux pris en charge par une seule instance de base de données Aurora. Par exemple, une application de comptabilité peut être partitionnée horizontalement par un utilisateur puisque les données comptables de chaque utilisateur sont indépendantes des autres. La base de données Aurora PostgreSQL Limitless se met automatiquement à l’échelle pour prendre en charge vos applications les plus importantes et les plus dynamiques. 

Il existe deux fonctionnalités de mise à l’échelle : Amazon Aurora autoscaling avec réplicas Aurora et Aurora sans serveur v2.

Les réplicas Aurora vous permettent d’augmenter la capacité de lecture de votre cluster Aurora au-delà des limites qu’une seule instance de base de données peut proposer. Les applications qui peuvent séparer leur charge de travail de lecture de leur charge de travail d’écriture peuvent bénéficier de jusqu’à 15 réplicas en lecture pour atteindre un débit de lecture global plus élevé. Les réplicas Aurora ne nécessitent pas que l’application divise horizontalement leurs données. Toutes les données sont disponibles dans chaque réplica. Les réplicas Aurora n’augmentent pas la capacité de stockage d’un cluster Aurora ni le débit d’écriture.

Aurora sans serveur v2 est une configuration de mise à l’échelle verticale à la demande pour Aurora qui propose une mise à l’échelle automatique du calcul et de la mémoire de la base de données en fonction des besoins de l’application dans les limites de capacité d’une seule instance de calcul. Aurora sans serveur v2 est pris en charge à la fois pour les instances du scripteur et du lecteur. Cependant, cela n’augmente pas la capacité de stockage d’un cluster Aurora. Si votre application est conçue pour être mise à l’échelle horizontalement, la base de données Aurora PostgreSQL Limitless vous permet de mettre à l’échelle le débit d’écriture et la capacité de stockage de votre base de données au-delà des limites d’une seule instance du scripteur Aurora.

La base de données Aurora PostgreSQL Limitless divise les données entre les instances de base de données en utilisant les valeurs spécifiées par le client dans une colonne de table, également appelée clé de partition. Par exemple, une table contenant des informations utilisateur peut être divisée en utilisant la colonne ID utilisateur comme clé de partition. Sous le capot, la base de données Aurora PostgreSQL Limitless est un déploiement distribué de nœuds sans serveur. Les nœuds sont soit des routeurs, soit des partitions. Les routeurs gèrent la nature distribuée de la base de données. Chaque partition stocke un sous-ensemble de vos données, ce qui permet un traitement parallèle pour atteindre un débit d’écriture élevé.

À mesure que les besoins de calcul ou de stockage augmentent, Aurora commence par automatiquement augmenter verticalement chaque instance et le stockage associé, puis l’augmente horizontalement afin de répondre à la charge de travail de la base de données pour différentes valeurs de clé de partition. À tout moment, une valeur de clé de partition est détenue et servie par une seule instance sans serveur. Lorsque les applications se connectent à la base de données Aurora PostgreSQL Limitless et émettent une demande, celle-ci est d’abord analysée. Ensuite, elle est soit envoyée à l’instance de calcul qui possède la valeur de clé de partition spécifiée par la demande, soit une requête sur plusieurs instances est orchestrée.

Plusieurs instances de calcul, chacune fournissant des valeurs de clé de partition distinctes, peuvent traiter simultanément des demandes d’application pour la même base de données Aurora PostgreSQL Limitless. La base de données Aurora PostgreSQL Limitless fournit la même sémantique de transaction que les systèmes Aurora PostgreSQL à un seul scripteur, ce qui simplifie la gestion des différents domaines de transaction dans votre application.

La base de données Aurora PostgreSQL Limitless prend en charge trois types de table contenant vos données : partitionnée, de référence et standard.

Tables partitionnées : ces tables sont réparties sur plusieurs partitions. Les données sont réparties entre les partitions en fonction des valeurs des colonnes désignées de la table, appelées clés de partition. Elles sont utiles pour mettre à l’échelle les tables les plus volumineuses et les plus gourmandes en E/S de votre application.

Tables de référence : ces tables copient les données dans leur intégralité sur chaque partition afin que les requêtes conjointes puissent fonctionner plus rapidement en supprimant les mouvements de données inutiles. Elles sont couramment utilisées pour les données de référence rarement modifiées, telles que les catalogues de produits et les codes postaux.

Tables standard : ces tables ressemblent à des tables Aurora PostgreSQL classiques. Les tables standard sont toutes placées ensemble sur une seule partition afin que les requêtes conjointes puissent fonctionner plus rapidement en supprimant les mouvements de données inutiles. Vous pouvez créer des tables partitionnées et des tables de référence à partir de tables standard.

Pour en savoir plus sur les considérations relatives à la compatibilité avec PostgreSQL, consultez Aurora PostgreSQL Limitless Database requirements and considerations.

Vous pouvez commencer à utiliser la base de données Aurora PostgreSQL Limitless dans la console Amazon RDS ou les API Amazon pour créer un cluster Aurora PostgreSQL avec la version du moteur prise en charge. Pour en savoir plus sur la mise en route, consultez le Guide de l’utilisateur de la base de données Aurora PostgreSQL Limitless.

Votre application se connecte à la base de données Aurora PostgreSQL Limitless de la même manière qu’elle se connecterait à un cluster Aurora PostgreSQL standard. Il vous suffit de vous connecter au point de terminaison du cluster. Pour en savoir plus, consultez Utilisation d’Aurora PostgreSQL Limitless Database.

Oui, vous devrez peut-être ajuster le schéma de votre base de données pour utiliser la base de données Aurora PostgreSQL Limitless. Toutes les tables partitionnées devant contenir la clé de partition, il peut donc être nécessaire de renseigner ces données. Par exemple, une application de comptabilité peut fractionner ses données par utilisateur, à l’aide de la colonne ID utilisateur, chaque utilisateur étant indépendant des autres. Bien que la table d’utilisateurs elle-même contienne naturellement cette
colonne, il n’en va pas de même pour d’autres tables, comme une table contenant les rubriques des factures. Étant donné que ces tables doivent également être divisées par utilisateur pour rassembler les tables afin d’optimiser les performances de requête, la colonne ID utilisateur doit y être ajoutée.

Il n’existe aucune contrainte de dénomination pour la colonne utilisée en vue de fractionner les données, mais la définition de la colonne doit correspondre. Vous devrez ajouter la clé de partition aux requêtes de l’application et vous devrez peut-être également ajuster vos requêtes et vos transactions pour atteindre des performances optimales. Par exemple, la recherche d’une facture à l’aide de l’ID de facture lorsque la table est divisée uniquement par ID utilisateur serait lente, car la requête devrait être exécutée sur toutes les instances de base de données. Toutefois, si la requête spécifie également l’ID utilisateur, elle sera acheminée vers l’instance de base de données unique qui contient toutes les commandes pour cet ID utilisateur, réduisant ainsi la latence de la requête.

Oui. Vous pouvez choisir une option de haute disponibilité lorsque vous définissez la redondance de calcul sur une valeur supérieure à zéro pour votre base de données Aurora PostgreSQL Limitless, avec une disponibilité de 99,99 %. Chaque instance de calcul qui stocke et accède aux données de votre base de données Aurora PostgreSQL Limitless peut disposer d’une ou de deux instances de secours qui peuvent prendre en charge les demandes si l’instance principale n’est pas disponible. Les routeurs redirigeront automatiquement le trafic pour minimiser l’impact sur votre application.

La base de données Aurora PostgreSQL Limitless est disponible pour la configuration de cluster optimisée pour les E/S Aurora compatibles avec PostgreSQL 16.4. Des informations supplémentaires concernant la disponibilité régionale d’AWS pour la base de données Aurora PostgreSQL Limitless ont disponibles sur la page de tarification Aurora.

Dans la base de données Aurora PostgreSQL Limitless, la capacité de la base de données est mesurée en ACU. Vous êtes facturé à un tarif fixe par seconde d’utilisation d’ACU. Des taux de stockage de configuration de la version optimisée E/S d’Aurora s’appliquent. Pour plus d’informations, consultez la page de tarification Aurora.

Amazon Aurora Parallel Query permet de réduire et de distribuer la charge de calcul d’une requête unique sur des milliers de CPU dans la couche de stockage d’Aurora. Sans Parallel Query, une requête émise sur une base de données Amazon Aurora serait exécutée entièrement dans une instance du cluster de base de données ; cela serait similaire à la façon dont fonctionnent la plupart des bases de données.

Parallel Query convient parfaitement aux charges de travail analytiques nécessitant de nouvelles données et de bonnes performances de requête, même sur de grandes tables. Les charges de travail de ce type sont souvent de nature opérationnelle.

Parallel Query entraîne des performances plus rapides, accélérant les requêtes analytiques jusqu’à 2 ordres de grandeur. Cette fonctionnalité offre aussi une simplicité opérationnelle et l'actualisation des données comme vous émettez une requête directement sur les données transactionnelles actuelles de votre cluster Aurora. Et Parallel Query permet des charges de travail transactionnelles et analytiques sur la même base de données en autorisant Aurora à maintenir un débit de transactions élevé parallèlement aux requêtes analytiques simultanées.

La plupart des requêtes sur des ensembles de données volumineux qui ne figurent pas déjà dans le pool de mémoire tampon peuvent en bénéficier. La version initiale de Parallel Query peut accélérer et réduire le traitement de plus de 200 fonctions SQL, équijointures et projections.

L’amélioration des performances d’une requête spécifique dépend de la quantité de plan de requête pouvant être transmise à la couche de stockage Aurora. Les clients ont signalé une amélioration supérieure à un ordre de grandeur de la latence des requêtes.

Oui, mais nous nous attendons à ce que ces cas soient rares.

Aucune modification de la syntaxe de requête n'est requise. L'optimiseur de requêtes décidera automatiquement s'il convient d'utiliser Parallel Query pour votre requête spécifique. Pour vérifier si une requête utilise Parallel Query, vous pouvez afficher le plan d'exécution des requêtes en exécutant la commande EXPLAIN. Si vous souhaitez contourner l’heuristique et forcer Parallel Query à des fins de test, utilisez la variable de session aurora_pq_force.

Parallel Query peut être activé et désactivé dynamiquement au niveau global et au niveau de la session à l’aide du paramètre aurora_pq.

Non. Vous n’êtes pas facturé pour autre chose que ce que vous payez déjà pour les instances, les I/O et le stockage.

Non, les coûts E/S Parallel Query pour vos requêtes sont mesurés au niveau de la couche de stockage et seront identiques ou supérieurs avec l'activation de Parallel Query. Votre avantage réside dans l'amélioration des performances des requêtes.

Il y a deux raisons aux coûts d'I/O potentiellement plus élevés avec Parallel Query. Premièrement, même si certaines des données d'une table se trouvent dans le pool de mémoire tampon, Parallel Query requiert que toutes les données soient analysées sur la couche de stockage, ce qui entraîne des I/O. Deuxièmement, éviter la contention dans le pool de mémoire tampon a pour effet secondaire que l'exécution de la fonction Parallel Query ne réchauffe pas le pool de mémoire tampon. En conséquence, les exécutions consécutives de la même requête Parallel Query entraîneront le coût d’I/O complet.

Pour en savoir plus sur Parallel Query, consultez la documentation.

Non. Pour le moment, vous pouvez utiliser Parallel Query avec les instances de la famille R*.

Parallel Query est disponible pour la version compatible MySQL 5.7 et MySQL8.0 d’Amazon Aurora.

Parallel Query est compatible avec Aurora Serverless v2 et Backtrack.

Non. Bien que nous nous attendions à ce que Parallel Query améliore la latence des requêtes dans la plupart des cas, il se peut que vous ayez à payer des coûts d’I/O plus élevés. Nous vous recommandons de tester soigneusement votre charge de travail avec la fonction activée et désactivée. Une fois que vous êtes convaincu que Parallel Query est le bon choix, vous pouvez compter sur l'optimiseur de requêtes pour décider automatiquement des requêtes spécifiques qui utiliseront Parallel Query. Dans les rares cas où l’optimiseur ne prend pas la décision optimale, vous pouvez remplacer le paramètre.

Aurora Parallel Query n'est pas un entrepôt des données et ne fournit pas les fonctionnalités généralement présentes dans ces produits. Elle est conçue pour accélérer les performances des requêtes dans votre base de données relationnelle et convient aux cas d’utilisation tels que les analyses opérationnelles, lorsque vous devez effectuer des requêtes analytiques rapides sur de nouvelles données de votre base de données.

Pour un entrepôt des données dans le Cloud à l’échelle de l’exaoctet, utilisez Amazon Redshift.

Les lectures optimisées d’Amazon Aurora disponibles pour Aurora PostgreSQL offrent un rapport prix/performances idéal, notamment des latences de requête divisées par huit et jusqu’à 30 % d’économies de coûts par rapport aux instances non dotées de cette fonctionnalité. Elle est idéale pour les applications dont les jeux de données volumineux dépassent la capacité de mémoire d’une instance de base de données.

Les instances de lectures optimisées d'Amazon Aurora utilisent un stockage SSD local basé sur NVMe au niveau des blocs (disponible sur les instances r6gd basées sur Graviton et r6id basées sur Intel) pour améliorer la latence des requêtes des applications dont les ensembles de données dépassent la capacité mémoire d'une instance de base de données. Les lectures optimisées incluent des améliorations de performances telles que la mise en cache hiérarchisée et les objets temporaires.

La mise en cache hiérarchisée permet d'améliorer la latence des requêtes jusqu'à 8 fois et de réaliser jusqu'à 30 % d'économies pour les applications gourmandes en lecture et gourmandes en E/S, telles que les tableaux de bord opérationnels, la détection des anomalies et les recherches de similarité vectorielles. Ces avantages sont obtenus en mettant automatiquement en cache les données expulsées du cache tampon de la base de données en mémoire sur le stockage local afin d'accélérer les accès ultérieurs à ces données. La mise en cache hiérarchisée est uniquement disponible pour Amazon Aurora PostgreSQL Edition avec la configuration de la version E/S d'Amazon Aurora.

Les objets temporaires accélèrent le traitement des requêtes en plaçant les tables temporaires générées par Aurora PostgreSQL sur le stockage local, améliorant ainsi les performances des requêtes impliquant des tris, des agrégations de hachage, des jointures à charge élevée et d’autres opérations gourmandes en données.

Les lectures optimisées d’Amazon Aurora pour Aurora PostgreSQL offrent aux clients disposant d’applications nécessitant une latence faible et de grands ensembles de travail une alternative convaincante en termes de prix et de performance pour respecter leurs SLA professionnels et tirer davantage parti de leurs instances.

Lectures optimisées d’Amazon Aurora disponible sur les instances R6id basées sur Intel et R6gd basées sur Graviton. Vous pouvez consulter la disponibilité régionale pour Aurora ici.

Les lectures optimisées d'Amazon Aurora sont disponibles pour l'édition compatible avec PostgreSQL d'Aurora sur les instances R6id et R6gd. Les versions du moteur prises en charge sont les versions 15.4 et ultérieures et 14.9 et ultérieures sur Aurora PostgreSQL.

Les lectures optimisées d’Amazon Aurora ne sont pas disponibles sur Aurora sans serveur v2 (ASv2).

Oui, les lectures optimisées d’Amazon Aurora sont disponibles avec les deux configurations. Dans les deux configurations, les instances compatibles avec les lectures optimisées mappent automatiquement les tables temporaires au stockage local basé sur NVMe afin d'améliorer les performances des requêtes analytiques et des reconstructions d'index.

Pour les charges de travail gourmandes en E/S impliquant de nombreuses lectures, les instances compatibles avec les lectures optimisées sur Aurora PostgreSQL sont configurées pour utiliser la version optimisée E/S d’Aurora mettent automatiquement en cache les données expulsées de la mémoire sur un stockage local basé sur NVMe afin de fournir une latence de requête jusqu’à 8 fois supérieure et jusqu’à 30 % d’économies par rapport aux instances sans cette technologie, pour les applications dont les jeux de données volumineux dépassent la capacité mémoire d’une instance de base de données.

Les clients peuvent commencer à utiliser les lectures optimisées d'Amazon Aurora via la console de gestion AWS, l'interface de ligne de commande et le kit SDK. Les lectures optimisées sont disponibles par défaut sur toutes les instances R6id et R6gd. Pour utiliser cette fonctionnalité, les clients peuvent simplement modifier leurs clusters de bases de données Aurora existants pour inclure des instances R6id et R6gd, ou créer de nouveaux clusters de bases de données à l’aide de ces instances. Pour démarrer, consultez la documentation concernant les lectures optimisées d’Amazon Aurora.

Environ 90 % du stockage local disponible sur les instances R6id et R6gd est disponible pour des lectures optimisées, Aurora réserve 10 % du stockage NVMe afin de réduire l’impact de l’amplification de l’écriture sur SSD. L'allocation de l'espace de stockage disponible dépend des fonctionnalités de lecture optimisées activées.

Lorsque vous utilisez des lectures optimisées avec les fonctionnalités d'objets temporaires et de mise en cache hiérarchisée, l'espace disponible pour les objets temporaires dans le stockage local équivaut à deux fois la taille de la mémoire disponible sur ces instances de base de données. Cela correspond à la taille actuelle du stockage d'objets temporaires sur Aurora PostgreSQL. L'espace disque de stockage local restant est disponible pour la mise en cache des données.

Lorsque vous utilisez des lectures optimisées uniquement avec la fonctionnalité Objets temporaires, tout l'espace disque de stockage local disponible est disponible pour les objets temporaires. Par exemple, lorsque vous utilisez une instance r6gd.8xlarge avec les fonctionnalités d’objets temporaires et de mise en cache hiérarchisée, 534 Go (2 fois la capacité de mémoire) sont réservés aux objets temporaires et 1 054 Go pour le cache hiérarchisé.

En cas de défaillance du stockage local, Aurora procède automatiquement au remplacement de l'hôte. Dans un cluster de bases de données à plusieurs nœuds, cela déclenche un basculement au niveau de la région.

En cas de basculement d’une base de données, la latence des requêtes augmentera temporairement après le basculement. Cette augmentation de la latence diminuera au fil du temps et finira par rattraper la latence des requêtes avant le basculement. Vous pouvez réduire cette durée de rattrapage en activant la gestion de cache de cluster (CCM). Avec CCM, les clients peuvent désigner une instance de base de données Aurora PostgreSQL spécifique comme cible de basculement.

Lorsque la CCM est activée, le cache de stockage local de la cible de basculement désignée reflète étroitement le cache de stockage local de l'instance principale, ce qui réduit le temps de rattrapage après le basculement. Toutefois, l'activation de la CCM peut avoir un impact sur l'efficacité à long terme du cache de stockage local si la cible de basculement désignée est également utilisée pour traiter une charge de travail de lecture distincte de celle de l'instance d'écriture.

Par conséquent, les clients qui exécutent des charges de travail nécessitant la désignation d'un lecteur pour le basculement de secours doivent permettre à CCM d'augmenter leurs chances de retrouver rapidement la latence de leurs requêtes après le basculement. Les clients qui exécutent des charges de travail distinctes sur leurs cibles de basculement désignées peuvent souhaiter trouver un équilibre entre leurs besoins de restauration immédiate de la latence après le basculement et l’efficacité à long terme des performances du cache, avant d’activer la CCM.

pgvector est une extension open source pour PostgreSQL prise en charge par l’édition d’Amazon Aurora compatible avec PostgreSQL.

Vous pouvez utiliser pgvector pour stocker, rechercher, indexer et interroger des milliards de vectorisations générées à partir de modèles de machine learning (ML) et d’intelligence artificielle (IA) dans votre base de données, tels que ceux d’Amazon Bedrock ou d’Amazon SageMaker. Une intégration vectorielle est une représentation numérique qui représente la signification sémantique d’un contenu tel que du texte, des images et des vidéos.

Avec pgvector, vous pouvez interroger les intégrations dans votre base de données PostgreSQL Aurora pour effectuer des recherches de similarité sémantique efficaces de ces types de données, représentées sous forme de vecteurs, combinées avec d'autres données tabulaires dans Aurora. Cela permet d’utiliser l’IA générative et d’autres systèmes AI/ML pour de nouveaux types d’applications, tels que des recommandations personnalisées basées sur des descriptions textuelles ou des images similaires, la mise en correspondance des candidats sur la base de notes d’entretien, des chatbots et les recommandations de la meilleure prochaine action du service client sur la base de transcriptions réussies ou de dialogues de sessions de chat, etc. 

Consultez notre blog sur les fonctionnalités de bases de données vectorielles et découvrez comment stocker des vectorisations à l’aide de l’extension pgvector dans une base de données Aurora PostgreSQL, créer un chatbot interactif répondant aux questions et utiliser l’intégration native entre pgvector et le machine learning d’Aurora pour l’analyse des sentiments.

Oui. Le machine learning (ML) Aurora expose les modèles de ML en tant que fonctions SQL. Ainsi, vous pouvez utiliser le langage SQL standard pour appeler les modèles de ML, leur transmettre des données et renvoyer les prédictions sous forme de résultats de requêtes. L’extension pgvector nécessite que les vectorisations soient stockées dans la base de données, il est donc nécessaire d’exécuter le modèle de ML sur des données textuelles ou d’image sources pour générer des vectorisations, puis de les déplacer en lot dans Aurora PostgreSQL.

Grâce au ML Aurora, ce processus peut s’effectuer en temps réel pour permettre aux vectorisations d’être maintenues à jour dans Aurora PostgreSQL via des appels périodiques à Amazon Bedrock ou Amazon SageMaker, qui renvoie les vectorisations les plus récentes de votre modèle.

Oui. Il existe deux méthodes pour intégrer les bases de données Amazon Aurora à Amazon Bedrock et alimenter des applications d’IA générative. Tout d’abord, le ML Amazon Aurora offre un accès aux modèles de fondation disponibles dans Amazon Bedrock directement via SQL pour Aurora MySQL et Aurora PostgreSQL. Ensuite, vous pouvez configurer Aurora comme boutique vectorielle dans les bases de connaissances Amazon Bedrock en un seul clic et stocker les intégrations générées à partir de Bedrock sur Aurora. Les bases de connaissances Amazon Bedrock prennent en charge Aurora PostgreSQL en tant que base de données vectorielle pour des cas d’utilisation tels que la génération à enrichissement contextuel (RAG). Consultez notre blog ainsi que la documentation sur l’utilisation d’Aurora PostgreSQL comme base de connaissances pour Amazon Bedrock.

Les lectures optimisées d’Amazon Aurora PostgreSQL avec pgvector multiplient par neuf le nombre de requêtes par seconde pour la recherche vectorielle dans les charges de travail qui dépassent la mémoire d’instance disponible. Cela est possible grâce à la capacité de mise en cache hiérarchisée disponible dans les lectures optimisées, qui met automatiquement en cache les données expulsées du cache tampon de la base de données en mémoire sur le stockage local afin d’accélérer les accès ultérieurs à ces données.

Consultez notre blog et notre documentation et découvrez comment améliorer les performances des requêtes pour Aurora PostgreSQL grâce aux lectures optimisées d’Aurora.

Il est recommandé d’utiliser l’intégration zéro ETL d’Amazon Aurora à Amazon Redshift lorsque vous avez besoin d’un accès en temps quasi réel aux données transactionnelles. Cette intégration vous permet de tirer parti du ML d’Amazon Redshift à l’aide de simples commandes SQL.

L’intégration zéro ETL Amazon Aurora avec Amazon SageMaker permet d’importer les données de vos bases de données opérationnelles et applications dans votre lakehouse en temps quasi réel. Grâce à l’architecture Lakehouse de SageMaker, vous pouvez créer un Lakehouse ouvert à partir de vos investissements existants en matière de données, sans modifier votre architecture de données, et utiliser vos outils d’analyse et moteurs de requête préférés, tels que SQL, Apache Spark, BI et les outils d’IA/ML.

L’intégration zéro ETL d’Aurora à Amazon Redshift est disponible dans Amazon Aurora – Édition compatible MySQL pour Aurora MySQL version 3.05.2 (compatible avec MySQL 8.0.32). L’intégration zéro ETL d’Aurora à Amazon Redshift est disponible sur l’édition compatible avec Aurora PostgreSQL pour Aurora PostgreSQL 16.4 et versions supérieures.

L’intégration zéro ETL d’Aurora à Amazon SageMaker est disponible dans Amazon Aurora – Édition compatible MySQL pour Aurora MySQL version 3.05.0 (compatible avec MySQL 8.0.32). L’intégration zéro ETL d’Aurora avec Amazon SageMaker est disponible sur Aurora PostgreSQL-Compatible Edition pour Aurora PostgreSQL version 16.4 et versions supérieures, ainsi que pour Aurora PostgreSQL version 17.4 et versions supérieures.

Consultez Supported features in Aurora by AWS Region and Aurora DB engine pour en savoir plus sur la disponibilité des Régions AWS pour les intégrations zéro ETL d’Aurora.

L’intégration zéro ETL d’Aurora avec Amazon Redshift et Amazon SageMaker vous évite de créer et de gérer des pipelines de données complexes. Vous pouvez consolider les données provenant de plusieurs tables de divers clusters de bases de données Aurora dans un seul cluster de bases de données Amazon Redshift ou dans l’architecture lakehouse de SageMaker, puis exécuter des analyses et du ML en temps quasi réel sur les données opérationnelles provenant d’Aurora.

L’intégration zéro ETL d’Aurora à Amazon Redshift est compatible avec Aurora sans serveur v2. Lorsque vous utilisez Aurora sans serveur v2 et Amazon Redshift sans serveur, vous pouvez générer une analytique en temps quasi réel sur les données transactionnelles sans avoir à gérer d’infrastructure pour les pipelines de données. 

L’intégration zéro ETL d’Aurora à Amazon SageMaker est compatible avec Aurora sans serveur v2.

Vous pouvez commencer par utiliser la console Amazon RDS pour créer l’intégration zéro ETL en spécifiant la source Aurora et la destination de la cible. Une fois l’intégration créée, la base de données Aurora sera répliquée sur la cible et vous pourrez commencer à interroger les données une fois l’amorçage initial terminé. Pour plus d’informations, consultez le guide de démarrage relatif aux intégrations zéro ETL d’Aurora avec Amazon Redshift et aux intégrations zéro ETL Aurora avec Amazon SageMaker.

Le traitement continu des modifications de données par intégration zéro ETL est proposé sans frais supplémentaires. Vous payez pour les ressources existantes utilisées pour créer et traiter les données de modification générées dans le cadre d’une intégration zéro ETL. Ces ressources peuvent inclure :

• E/S et stockage supplémentaires utilisés en activant les journaux binaires (binlog) améliorés
• Frais d’exportation d’instantanés pour l’exportation initiale des données afin d’alimenter vos bases de données
• Stockage supplémentaire pour le stockage des données répliquées
• Calcul supplémentaire pour le traitement de la réplication des données
• Frais de transfert de données entre zones de disponibilité pour le déplacement de données d’une source vers une cible

Pour plus d’informations, consultez la page de tarification Aurora.

Oui, vous pouvez gérer et automatiser la configuration et le déploiement des ressources nécessaires à une intégration zéro ETL d’Aurora à l’aide d’AWS CloudFormation. Pour plus d’informations, consultez la section Modèles CloudFormation avec intégration zéro ETL.

CloudWatch Database Insights est une solution de surveillance et de mesures qui simplifie et améliore le dépannage des bases de données. Il automatise la collecte de données télémétriques, y compris les métriques, les journaux et les traces, éliminant ainsi la nécessité d’une configuration et d’une configuration manuelles. En consolidant cette télémétrie dans Amazon CloudWatch, CloudWatch Database Insights fournit une vue unifiée des performances et de l’état des bases de données.

Les principaux avantages de CloudWatch Database Insights sont les suivants :

1. Collecte de télémétrie sans effort : collecte automatiquement les métriques, journaux et traces de la base de données, réduisant ainsi le temps de configuration.
2. Informations sélectionnées : fournit des tableaux de bord, des alarmes et des informations prédéfinis pour surveiller et optimiser les performances des bases de données, avec une configuration minimale requise pour démarrer.
3. Vue CloudWatch unifiée : combine la télémétrie de plusieurs bases de données en une seule vue pour une surveillance simplifiée.
4. Capacités AI/ML : utilise l’IA/ML pour détecter les anomalies, réduisant ainsi les efforts de dépannage manuel.
5. Surveillance du contexte des applications : permet aux utilisateurs de corréler les performances de la base de données aux performances des applications.
6. Vues au niveau de la flotte et de l’instance : offre à la fois une surveillance de haut niveau de la flotte et des vues détaillées des instances pour l’analyse de la cause racine.
7. Intégration fluide avec AWS : s’intègre à la vigie applicative Amazon CloudWatch et à AWS X-Ray, offrant une expérience d’observabilité complète.

Amazon DevOps Guru pour RDS est une fonctionnalité basée sur le ML pour Amazon RDS (qui inclut Amazon Aurora) conçue pour détecter et diagnostiquer automatiquement les problèmes opérationnels et de performance des bases de données, vous permettant ainsi de traiter les problèmes en quelques minutes plutôt qu’en quelques jours.

Amazon DevOps Guru pour RDS est une fonctionnalité d’Amazon DevOps Guru conçue pour détecter les problèmes opérationnels et de performance pour tous les moteurs Amazon RDS ainsi que des dizaines d’autres types de ressources. DevOps Guru pour RDS renforce les capacités de DevOps Guru pour détecter, diagnostiquer et résoudre divers problèmes liés aux bases de données dans Amazon RDS (par exemple, la surexploitation des ressources et les comportements défectueux des requêtes SQL).

Lorsqu’un problème survient, Amazon DevOps Guru pour RDS est conçu pour informer immédiatement les développeurs et ingénieurs DevOps et fournit des informations de diagnostic, des détails sur l’étendue du problème et des recommandations intelligentes de correction pour aider les clients à résoudre rapidement les goulots d’étranglement des performances de bases de données et les problèmes opérationnels.

Amazon DevOps Guru pour RDS est conçu pour supprimer les efforts manuels et réduire le temps (de plusieurs heures et jours à quelques minutes) pour détecter et résoudre les goulots d'étranglement de performance difficiles à trouver dans votre charge de travail de base de données relationnelle.

Vous pouvez activer le service DevOps Guru pour RDS pour chaque base de données Amazon Aurora. Il détecte alors automatiquement les problèmes de performances de vos charges de travail, vous envoie des alertes sur chaque problème, explique les résultats et recommande des actions pour les résoudre.
DevOps Guru pour RDS contribue à rendre l’administration des bases de données plus accessible aux non-experts et aide les experts en bases de données afin qu’ils puissent gérer encore davantage de bases de données.

Amazon DevOps Guru pour RDS utilise le ML pour analyser les données de télémétrie collectées par l’Analyse des performances d’Amazon RDS. DevOps Guru pour RDS n’utilise aucune de vos données stockées dans la base de données lors de l’analyse. L’Analyse des performances d’Amazon RDS mesure la charge de la base de données (une métrique qui caractérise le comportement d’une application dans la base de données) et certaines métriques générées par la base de données, comme les variables d’état du serveur dans MySQL et les tables pg_stat dans PostgreSQL.

Pour démarrer l’utilisation de DevOps Guru pour RDS, assurez‑vous que l’Analyse des performances est activée via la console RDS, puis activez DevOps Guru pour vos bases de données Amazon Aurora. Avec DevOps Guru, vous pouvez choisir la portée de votre analyse pour qu’elle couvre l’ensemble de votre compte AWS, spécifier les piles AWS CloudFormation à faire analyser par DevOps Guru, ou utiliser les balises AWS pour créer le groupement de ressources que vous souhaitez que DevOps Guru analyse.

Amazon DevOps Guru pour RDS permet d’identifier un large éventail de problèmes de performance susceptibles d’affecter la qualité de service des applications, tels que les empilements de verrous, les tempêtes de connexion, les régressions SQL, la contention du processeur et des I/O, ainsi que les problèmes de mémoire.

L’Analyse des performances d’Amazon RDS est une fonctionnalité d’ajustement et de surveillance des performances de bases de données qui collecte et affiche les métriques de performances des bases de données Amazon RDS. Ainsi, vous pouvez évaluer rapidement la charge de votre base de données et déterminer quand et où agir. Amazon DevOps Guru pour RDS est conçu pour contrôler ces métriques, détecter les problèmes de performance de votre base de données, analyser les métriques, puis vous indique ce qui ne va pas et ce que vous pouvez faire.

CloudWatch Database Insights surveille les ressources et les applications Aurora en temps réel et présente les données via des tableaux de bord personnalisables. En revanche, Amazon DevOps Guru est un service de machine learning (ML) qui analyse les métriques CloudWatch pour comprendre le comportement d’une application au fil du temps, détecter les anomalies et proposer des informations et des recommandations pour la résolution des problèmes. De plus, DevOps Guru analyse les données provenant de plusieurs sources, notamment AWS Config, AWS CloudFormation et AWS X-Ray. Vous pouvez utiliser les tableaux de bord CloudWatch pour suivre vos informations sur DevOps Guru via les métriques publiées dans l’espace de noms AWS/DevOps Guru. Cela vous permet de visualiser toutes les informations et anomalies sous un seul écran dans la console CloudWatch.

L’analyse des performances RDS est une fonctionnalité d’optimisation et de surveillance des performances des bases de données qui permet aux clients d’évaluer la charge sur leur base de données et de déterminer quand et où intervenir. CloudWatch Database Insights est une nouvelle fonctionnalité d’observabilité des bases de données qui hérite de toutes les fonctionnalités de Performance Insights, ainsi que de la surveillance au niveau de la flotte, de l’intégration à la surveillance des performances des applications et de la corrélation des mesures de base de données avec les journaux et les événements.

Vous devez utiliser l’API Data pour les nouvelles applications modernes, en particulier celles créées avec AWS Lambda qui ont besoin d’accéder à Aurora dans le cadre d’un modèle de requête/réponse. Vous devez utiliser des pilotes de base de données au lieu de l’API Data et gérer des connexions de base de données persistantes lorsqu’une application existante est fortement couplée à des pilotes de base de données, pour des requêtes de longue durée ou lorsque le développeur souhaite tirer parti des fonctionnalités de base de données telles que les tables temporaires ou l’utilisation de variables de session.

La disponibilité de l’API Data dans les régions AWS et versions de base de données pour Aurora sans serveur v2 et les instances provisionnées Aurora est indiquée dans notre documentation.

L'API Data vous permettra de simplifier et d'accélérer le développement d'applications modernes. L'API Data est une API HTTP sécurisée et facile à utiliser, qui élimine le besoin de déployer des pilotes de base de données, de gérer des pools de connexions côté client ou de configurer un réseau VPC complexe entre l'application et la base de données. L’API Data améliore également la capacité de mise à l’échelle en regroupant et partageant automatiquement les connexions aux bases de données, ce qui réduit la charge de calcul des applications qui ouvrent et ferment fréquemment des connexions. 

L’API Data pour les instances provisionnées Aurora sans serveur v2 et Aurora prend en charge les instances d’écriture Aurora Global Database.

Les utilisateurs ne peuvent invoquer les opérations de l’API Data que s’ils y sont autorisés. Les administrateurs peuvent autoriser un utilisateur à utiliser l’API Data en attachant une politique Gestion des identités et des accès AWS (AWS IAM) qui définit ses privilèges. Vous pouvez également attacher la politique à un rôle si vous utilisez des rôles IAM. Lorsque vous appelez l’API Data, vous pouvez transmettre les informations d’identification pour le cluster de base de données Aurora à l’aide d’un secret dans AWS Secrets Manager. 

L’API Data pour les instances provisionnées Aurora sans serveur v2 et Aurora est facturée en fonction du volume de requêtes d’API, comme indiqué sur la page de tarification Aurora. L’API Data pour les instances provisionnées Aurora sans serveur v2 et Aurora utilise les événements du plan de données AWS CloudTrail pour enregistrer l’activité au lieu des événements de gestion.

Vous pouvez activer la journalisation des événements de données via la console CloudTrail, l’interface de ligne de commande ou le SDK si vous souhaitez suivre cette activité. Cela entraînera des frais, comme indiqué sur la page de tarification CloudTrail. En outre, l’utilisation d’AWS Secrets Manager entraînera des frais, comme indiqué sur la page de tarification AWS Secrets Manager. 

AWS CloudTrail capture l’activité des API AWS sous forme d’événements de gestion ou d’événements de données. Les événements de gestion CloudTrail (également appelés « opérations du plan de contrôle ») affichent les opérations de gestion effectuées sur les ressources de votre compte AWS, telles que créer, mettre à jour et supprimer une ressource. Les événements de données CloudTrail (également appelés « opérations de plan de données ») indiquent les opérations sur les ressources effectuées sur une ressource de votre compte AWS ou au sein de celle-ci.

L'API Data effectue des opérations sur le plan de données, puisqu'elle exécute des requêtes sur les données de votre base de données Aurora. Par conséquent, nous enregistrerons l'activité de l'API Data en tant qu'événements de données, car il s'agit de la bonne catégorisation des événements. Des frais seront facturés pour les événements de données CloudTrail uniquement si vous activez l’enregistrement des événements de données.

Oui, l’offre gratuite de l’API Data inclut un million de requêtes par mois, agrégées dans toutes les Régions AWS, pendant la première année d’utilisation. Une fois l’année écoulée, les clients commencent à payer pour l’API Data comme indiqué sur la page de tarification Aurora.

Les déploiements bleus/verts d’Amazon RDS sont disponibles dans les versions 5.6 et ultérieures de l’édition d’Amazon Aurora compatible avec MySQL ainsi que dans les versions 11.21 (et ultérieures), 12.16 (et ultérieures), 13.12 (et ultérieures), 14.9 (et ultérieures) et 15.4 (et ultérieures) de l’édition d’Amazon Aurora compatible avec PostgreSQL. Pour en savoir plus sur les versions disponibles, consultez la documentation Aurora.

Les déploiements bleus/verts d’Amazon RDS sont disponibles dans toutes les Régions AWS applicables ainsi que dans les Régions AWS GovCloud.

Les déploiements bleus/verts d'Amazon RDS vous permettent d'effectuer des modifications de bases de données plus sûres, plus simples et plus rapides. Les déploiements bleus/verts conviennent parfaitement aux cas d'utilisation tels que les mises à niveau majeures ou mineures de moteurs de bases de données, les mises à jour de systèmes d'exploitation, les modifications de schémas dans des environnements verts qui n'interrompent pas la réplication logique (comme l'ajout d'une nouvelle colonne à la fin d'une table) ou les modifications des paramètres de bases de données.

Vous pouvez utiliser les déploiements bleus/verts pour effectuer plusieurs mises à jour de bases de données en même temps à l'aide d'un seul basculement. Cela vous permet de rester à jour en ce qui concerne les correctifs de sécurité, d’améliorer les performances des bases de données et d’accéder aux nouvelles fonctionnalités de bases de données avec des temps d’arrêt courts et prévisibles. Si vous ne souhaitez effectuer qu’une mise à niveau de version mineure sur Aurora, nous vous recommandons d’utiliser l’application de correctifs sans interruption (ZDP) Aurora.

L’exécution de vos charges de travail sur des instances vertes vous coûte le même prix que sur les instances bleues. Le coût d’utilisation des instances bleues et vertes comprend notre tarification standard actuelle pour les db.instances, le coût de stockage, le coût des E/S en lecture/écriture et le coût de l’ensemble des fonctionnalités activées, telles que les sauvegardes et l’Analyse des performances d’Amazon RDS. En fait, vous payez environ deux fois le coût d’exécution des charges de travail sur une instance db.instance pendant la durée de vie du déploiement bleu/vert.

Par exemple : vous avez un cluster d'édition compatible avec Aurora MySQL 5.7 s'exécutant sur deux db.instances r5.2xlarge, une instance d'écriture principale et une instance de lecture, dans la région AWS us-east-1. Chacune des instances db.instances r5.2xlarge est configurée pour offrir un stockage de 40 Gio et 25 millions d'E/S par mois. Vous créez un clone de la topologie de l'instance bleue en utilisant les déploiements bleus/verts d'Amazon RDS et l'exécutez pendant 15 jours (360 heures). Chaque instance verte effectue 3 millions de lectures d'E/S pendant cette période. Vous supprimez ensuite les instances bleues après un basculement réussi. Les instances bleues (d'écriture et de lecture) coûtent 849,2 USD pour 15 jours à un tarif à la demande de 1,179 USD/h (instance + stockage+ E/S). Les instances vertes (d'écriture et de lecture) coûtent 840,40 USD pour 15 jours à un tarif à la demande de 1,167 USD/h (instance + stockage+ E/S). Le coût total de l’utilisation des déploiements bleus/verts pour ces 15 jours s’élève à 1 689,60 USD, soit environ deux fois le coût de l’exécution des instances bleues pour cette période.

Les déploiements bleus/verts d’Amazon RDS vous aident à effectuer des modifications de base de données plus sûres, plus simples et plus rapides, telles que des mises à niveau de versions majeures ou mineures, des modifications de schémas, des mises à l’échelle d’instances, des modifications de paramètres de moteurs et des mises à jour de maintenance.

Dans le cadre des déploiements bleus/verts d’Amazon RDS, l’environnement bleu est votre environnement de production actuel. L’environnement vert est votre environnement de préproduction qui deviendra votre nouvel environnement de production après le basculement.

Lorsque les déploiements bleus/verts d’Amazon RDS lancent un basculement, ils bloquent les écritures dans les environnements bleu et vert, jusqu’à ce que le basculement soit terminé. Pendant le basculement, l’environnement de transfert, ou environnement vert, rattrape le système de production, ce qui garantit la cohérence des données entre l’environnement de préproduction et celui de production. Une fois que les environnements de production et de préproduction sont parfaitement synchronisés, les déploiements bleus/verts font de l’environnement de préproduction le nouvel environnement de production en redirigeant le trafic vers l’environnement de production nouvellement promu.

Les déploiements bleus/verts d’Amazon RDS sont conçus pour permettre les écritures sur l’environnement vert une fois le basculement terminé, ce qui élimine toute perte de données pendant le processus de basculement.

Les déploiements bleus/verts d’Amazon RDS ne suppriment pas votre ancien environnement de production. Si nécessaire, vous pouvez y accéder pour des validations supplémentaires et des tests de performance/régression. Si vous n'avez plus besoin de l'ancien environnement de production, vous pouvez le supprimer. Les frais de facturation standard s’appliquent aux anciennes instances de production jusqu’à ce que vous les supprimiez.

Lors de la transition, les barrières de protection des déploiements bleus/verts d’Amazon RDS bloquent les écritures sur vos environnements bleus et verts jusqu’à ce que votre environnement vert se rattrape avant de basculer. Les déploiements bleus/verts effectuent également des surveillances de l'état de votre principal et de vos réplicas dans vos environnements bleus et verts. Ils effectuent également des surveillances de l'état de la réplication, par exemple, pour vérifier si la réplication s'est arrêtée ou s'il y a des erreurs. Ils détectent les transactions de longue durée entre vos environnements bleu et vert. Vous pouvez spécifier votre temps d’arrêt maximum tolérable, jusqu’à 30 secondes. Ainsi, le basculement est interrompu lorsqu’une transaction en cours dépasse ce temps.

Si votre environnement bleu est un réplica logique autogéré ou un abonné, nous bloquons le basculement. Nous vous recommandons d'arrêter d'abord la réplication vers l'environnement bleu, d'effectuer le basculement, puis de reprendre la réplication. En revanche, si votre environnement bleu est la source d'un réplica logique autogéré ou d'un diffuseur de publication, vous pouvez continuer vers le basculement. Cependant, vous devrez mettre à jour le réplica autogéré afin de le répliquer à partir de l’environnement vert après le basculement.

Oui, les déploiements bleus/verts d’Amazon RDS prennent en charge les bases de données Aurora Global Database. Pour en savoir plus, consultez le Guide de l’utilisateur des déploiements bleus/verts pour Amazon Aurora Global Database.

Non, les déploiements Amazon RDS Blue/Green ne prennent pas en charge le proxy Amazon RDS ou les réplicas en lecture inter-régions. 

Non, pour le moment, vous ne pouvez pas utiliser les déploiements bleus/verts d’Amazon RDS pour annuler des modifications.

Trusted Language Extensions (TLE) pour PostgreSQL permet aux développeurs de créer des extensions PostgreSQL hautes performances et de les exécuter en toute sécurité sur Amazon Aurora. Ce faisant, TLE améliore vos délais de mise sur le marché et supprime la charge imposée aux administrateurs de bases de données, qui consiste à certifier le code personnalisé et tiers pour une utilisation dans des charges de travail de bases de données de production. Vous pouvez aller de l'avant dès que vous décidez qu'une extension répond à vos besoins. Grâce à TLE, les fournisseurs indépendants de logiciels (ISV) peuvent fournir de nouvelles extensions PostgreSQL aux clients fonctionnant sur Aurora.

Les extensions PostgreSQL sont exécutées dans le même espace de processus afin d’obtenir des performances élevées. Cependant, les extensions peuvent avoir des défauts logiciels qui peuvent faire planter la base de données.

TLE pour PostgreSQL offre plusieurs couches de protection pour limiter ce risque. TLE est conçu pour limiter l’accès aux ressources du système. Le rôle rds_superuser peut déterminer qui est autorisé à installer des extensions spécifiques. Toutefois, ces modifications ne peuvent être effectuées que via l’API TLE. TLE est conçu pour limiter l’impact d’un défaut d’extension à une seule connexion de base de données. En plus de ces mesures de protection, TLE est conçu pour fournir aux DBA ayant le rôle rds_superuser un contrôle précis et direct sur les personnes autorisées à installer des extensions et ils peuvent créer un modèle d’autorisations pour les exécuter. Seuls les utilisateurs disposant de privilèges suffisants peuvent exécuter et créer à l’aide de la commande « CREATE EXTENSION » (CRÉER UNE EXTENSION) sur une extension TLE. Les DBA peuvent également autoriser les « hooks PostgreSQL » requis pour des extensions plus sophistiquées qui modifient le comportement interne de la base de données et nécessitent généralement des privilèges élevés.

TLE pour PostgreSQL est disponible pour l’édition d’Amazon Aurora compatible avec PostgreSQL sur les versions 14.5 et ultérieures. TLE est mis en œuvre en tant qu’extension PostgreSQL elle-même et vous pouvez l’activer à partir du rôle rds_superuser, de la même manière que les autres extensions prises en charge par Aurora.

Vous pouvez exécuter TLE pour PostgreSQL dans PostgreSQL 14.5 (ou version ultérieure) dans Amazon Aurora.

TLE pour PostgreSQL est actuellement disponible dans toutes les Régions AWS (à l’exception des régions AWS Chine) et les Régions AWS GovCloud.

TLE pour PostgreSQL est disponible pour les clients Aurora sans frais supplémentaires.

Aurora et Amazon RDS prennent en charge un ensemble sélectionné de plus de 85 extensions PostgreSQL. AWS gère les risques de sécurité pour chacune de ces extensions selon le modèle de responsabilité partagée d’AWS. L’extension qui implémente TLE pour PostgreSQL est incluse dans cet ensemble. Les extensions que vous écrivez ou que vous obtenez de sources tierces et que vous installez dans TLE sont considérées comme faisant partie du code de votre application. Vous êtes responsable de la sécurité de vos applications qui utilisent les extensions TLE.

Vous pouvez créer des fonctions de développement, telles que la compression de bitmaps et la confidentialité différentielle (comme les requêtes statistiques accessibles au public qui protègent la confidentialité des individus).

Les extensions TLE pour PostgreSQL prennent actuellement en charge JavaScript, PL/pgSQL, Perl et SQL.

Une fois que le rôle rds_superuser active TLE pour PostgreSQL, vous pouvez déployer les extensions TLE en utilisant la commande SQL CREATE EXTENSION à partir de n’importe quel client PostgreSQL, tel que psql. Ceci est similaire à la façon dont vous créeriez une fonction définie par l’utilisateur écrite dans un langage procédural, tel que PL/pgSQL ou PL/Perl. Vous pouvez contrôler quels utilisateurs ont l’autorisation de déployer des extensions TLE et d’utiliser des extensions spécifiques.

Les extensions TLE pour PostgreSQL accèdent à votre base de données PostgreSQL exclusivement via l’API TLE. Les langages de confiance pris en charge par TLE comprennent toutes les fonctions de l’interface de programmation du serveur (SPI) PostgreSQL et la prise en charge des hooks PostgreSQL, notamment le hook de vérification du mot de passe.

Pour en savoir plus sur le projet TLE pour PostgreSQL, consultez la page GitHub de TLE officielle.