Amazon Aurora est un service de base de données relationnelle moderne offrant performances et haute disponibilité à grande échelle, des éditions entièrement open source compatibles avec MySQL et PostgreSQL, ainsi qu'une gamme d'outils pour développeur permettant de 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 auto-réparateur, qui est découplé à partir des ressources de calcul et qui augmente automatiquement jusqu'à atteindre 128 To 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 récupération à un instant dans le passé, 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 l'approvisionnement 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 à 1/10 du coût.

Amazon Aurora est compatible avec les bases de données open source MySQL existantes, et ajoute régulièrement une prise en charge pour les 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 Aurora est compatible avec les bases de données open source PostgreSQL existantes, et ajoute régulièrement une prise en charge pour les nouvelles versions. Cela signifie que vous pouvez effectuer la migration de bases de données PostgreSQL en toute simplicité vers et depuis Aurora grâce aux outils d'importation/exportation standard ou aux instantanés. Cela signifie également que la plupart des codes, applications, pilotes et outils que vous utilisez déjà aujourd'hui avec vos bases de données PostgreSQL peuvent être utilisés avec Aurora en 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..

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.

Pour essayer Amazon Aurora, connectez-vous à la console de gestion AWS, sélectionnez RDS dans la catégorie Base de données, puis choisissez Amazon Aurora comme moteur de base de données. Pour plus de conseils et de détails, consultez notre page bien démarrer avec Aurora.

Vous pouvez voir la disponibilité des régions pour Amazon Aurora ici.

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'Amazon RDS DB Snapshot pour migrer un Amazon RDS for MySQL DB Snapshot 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 Bonnes pratiques de migration de bases de données MySQL vers Amazon Aurora.

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'un instantané de base de données RDS pour migrer un instantané de base de données Amazon RDS for 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 migrer les bases de données SQL Server vers Amazon Aurora PostgreSQL-Compatible Edition, vous pouvez utiliser Babelfish for Aurora PostgreSQL. Vos applications fonctionneront sans aucun changement. Consultez la documentation de Babelfish pour plus d'informations

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 de sélection par seconde et 100 000 mises à jour par seconde, soit un volume cinq fois supérieur à MySQL en exécutant le même test de performances avec le même matériel. Vous trouverez des instructions détaillées concernant ce test comparatif et la manière de le reproduire par vous-même dans le manuel Amazon Aurora MySQL-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 effectués sur des instances r4.16xlarge dans SysBench démontrent qu'Amazon Aurora fournit des requêtes de sélection par seconde et des mises à jour par seconde trois fois supérieures à PostgreSQL en exécutant le même test de performances avec le même matériel. Vous trouverez des instructions détaillées concernant ce test comparatif et la manière de le reproduire par vous-même dans le manuel Amazon Aurora PostgreSQL-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 les performances de MySQL 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.

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 obtenir des informations sur les tarifs actuellement 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.

La réplication d'Amazon 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 Amazon Aurora MySQL et 8 Ko avec Aurora PostgreSQL-Compatible Edition.

Aurora a été conçu pour supprimer toutes les opérations d'I/O inutiles, afin de réduire les coûts et de garantir la disponibilité des ressources dans le but de gérer le trafic de lecture/écriture. Les E/S d'écriture ne sont consommées qu'en cas de persistance d'enregistrements de journal de reprise dans l'édition compatible avec MySQL Aurora ou d'enregistrements de journaux d'écriture en avance dans l'édition compatible avec PostgreSQL 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 mesures «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 de manière à ce qu'Amazon Aurora I/O Optimized soit optimisé.

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. Aurora I/O-Optimized propose une tarification prévisible pour toutes les applications car les opérations d'E/S en lecture et en écriture sont gratuites, ce qui rend cette configuration idéale pour les charges de travail présentant une forte variabilité d'E/S.

Aurora I/O Optimized 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 à Aurora I/O Optimized.

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 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 à Aurora I/O Optimized, vous pouvez réaliser encore plus d'économies sur vos dépenses d'E/S.

Aucun changement n'est apporté au prix du backtrack, de la capture instantanée, de l'exportation ou de la sauvegarde continue avec Aurora I/O Optimized.

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. 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 for Aurora PostgreSQL, en plus du prix des instances R6id basées sur Intel et R6gd basées sur Graviton. Pour plus d'informations, consultez la page de tarification Aurora.

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

Il existe deux façons de mettre à l'échelle les ressources de calcul associées à mon instance de base de données Amazon Aurora - via Aurora sans serveur et via un ajustement manuel.

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 à la mise à l'échelle automatique pour Amazon Aurora. Elle 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.

Vous pouvez également mettre à l'échelle vos ressources de calcul associées à votre base de données de manière manuelle, 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 « Apply Immediately » (Appliquer immédiatement) afin de modifier le type d'instance de base de données immédiatement.

Ces deux options affecteront la disponibilité pendant quelques minutes, le temps de l'opération de mise à l'échelle. Veuillez noter que toutes les modifications système en attente seront également appliquées.

Les sauvegardes automatisées sont toujours activées sur les instances de base de données d'Amazon Aurora. Les sauvegardes n'affectent pas les performances 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 des instantanés de base de données requiert la création d'une 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 seraient pas disponibles dans le stockage Amazon Aurora, vous pouvez les restaurer à partir d'un instantané de la base de données ou effectuer une opération de restauration ponctuelle vers une nouvelle instance. Notez que la fenêtre la plus récente possible pour une opération de restauration à un instant dans le passé possible remonte à cinq minutes.

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 à un moment donné 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 fonction pour partager les données entre vos divers environnements (production, dev/test, transfert, etc.) liés à des comptes AWS différents, ainsi que pour conserver les sauvegardes de toutes vos données en sécurité dans un compte séparé au cas où votre compte AWS principal serait compromis.

Le partage d'instantanés entre des 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. En savoir plus sur 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é automatique, vous devez créer manuellement une copie de celui-ci, puis partager la 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 à la recherche d'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.

Amazon Aurora MySQL-Compatible Edition et Amazon Aurora PostgreSQL-Compatible Edition prennent en charge les répliques 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 Amazon Aurora MySQL, 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 le dimensionnement en lecture ainsi que la haute disponibilité, nous recommandons l'utilisation de réplicas Amazon Aurora.

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

Vous avez deux options de réplications additionnelles en sus de celles ci-dessus. Vous pouvez utiliser Aurora 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 MySQL Aurora et MySQL 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, appelée Amazon Aurora Global Database, utilise une infrastructure dédiée qui laisse vos bases entièrement disponibles pour servir votre application et peut s'appliquer dans cinq régions secondaires maximum avec une latence inférieure à une seconde en règle générale. Elle est disponible pour Aurora MySQL-Compatible Edition et Aurora PostgreSQL-Compatible Edition.

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 binlog 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 entre régions, qui partageront le même espace de stockage sous-jacent que le réplica entre régions. Un réplica entre régions 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 choisir une région secondaire pour prendre des applications en lecture/écriture complètes 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épliques que vous ne souhaitez pas promouvoir auprès de l'instance primaire. Cependant, si les réplicas de niveau supérieur du cluster sont défectueux ou indisponibles pour quelque raison que ce soit, Amazon RDS choisit un réplica de niveau inférieur.

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. Le basculement complet s'effectue généralement en 30 secondes. Pour améliorer la résilience et accélérer les basculements, pensez à 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 %.
• Si vous exécutez Aurora Serverless v1 et que l'instance de base de données ou la zone de disponibilité n'est pas disponible, Aurora recrée automatiquement l'instance de base de données dans une zone de disponibilité différente. Aurora Serverless v2 fonctionne selon le provisionnement pour le basculement et d'autres fonctions de haute disponibilité. Pour plus d'informations, voir Aurora Serverless v2 et la haute disponibilité. 
• 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 Serverless, 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.

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.

Oui, vous pouvez configurer une réplication de journaux binaires (binlog) entre une instance Aurora MySQL-Compatible Edition 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 Aurora MySQL-Compatible Edition 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.

Amazon Aurora Global Database 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 SDK AWS ou l'interface de ligne de commande AWS (CLI). Vous devez allouer au moins une instance par région dans votre 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 primaire devient indisponible, vous pouvez supprimer manuellement une région secondaire d'Amazon Aurora Global Database et la promouvoir pour qu'elle prenne en charge toutes les lectures et écritures. Vous devrez également pointer votre application vers la région que vous venez de choisir.

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 à vos bases 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 de 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 de base de données avec chiffrement activé, puis migrez vos données vers celle-ci.

Vous devez accéder à votre base de données Aurora via le port de base de données saisi lors de la création de la base de données. Cela permet d'ajouter une couche de sécurité supplémentaire pour vos données. Vous trouverez des instructions étape par étape concernant la manière de vous connecter à votre base de données Amazon Aurora dans le manuel Amazon Aurora Connectivity Guide (français non disponible).

Oui, les éditions d'Aurora compatibles avec MySQL et PostgreSQL sont éligibles 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 Prestataires de soins de santé.

Actuellement, vous pouvez accéder à cette liste dans Mises à jour de sécurité d'Amazon Aurora (français non garanti).

Aurora est intégrée à Amazon GuardDuty pour vous aider à identifier les 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, voir Surveillance des menaces avec GuardDuty RDS Protection et le Guide de l'utilisateur de GuardDuty RDS Protection.

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 plus sur Aurora sans serveuret démarrez en quelques clics dans la console de gestion Amazon RDS.

Aurora sans serveur v2 prend en charge toutes sortes de charges de travail de bases de données, depuis les environnements de développement et de test, les sites web et les applications qui ont des charges de travail peu fréquentes, intermittentes ou imprévisibles jusqu'aux applications critiques les plus exigeantes qui nécessitent une mise à l'échelle et une disponibilité élevées. Le service procède à une mise à l'échelle horizontale sur place, en ajoutant plus de CPU et de mémoire sans avoir à basculer la base de données vers une instance de base de données plus grande ou plus petite. Par conséquent, il peut mettre à l'échelle même en cas de transactions à long terme, de verrous de tables, etc.

De plus, il met à l'échelle la capacité de base de données par incréments de seulement 0,5 ACU (unité de capacité Aurora) afin que celle-ci corresponde étroitement aux besoins de votre application.

Aurora sans serveur v1 est une option simple et économique pour les charges de travail peu fréquentes, intermittentes ou imprévisibles. Elle démarre automatiquement, met à l'échelle la capacité de calcul afin qu'elle corresponde à l'utilisation de votre application, et s'arrête lorsqu'elle n'est pas utilisée. Consultez le guide de l'utilisateur Aurora pour en savoir plus.

Aurora sans serveur v2prend en charge toutes les fonctions d'Aurora alloué, y compris lesréplicas en lecture, la configuration multi-AZ, Global Database, RDS proxy, et Performance Insights.

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.

Oui, vous pouvez migrer depuis Aurora sans serveur v1 vers Aurora sans serveur v2. Référez-vous au guide de l'utilisateur Aurora pour en savoir plus.

Les informations sur la compatibilité avec Aurora sans serveur v1 sont disponibles ici. 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.

Dans Aurora sans serveur, 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. 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 Aurora I/O Optimized. Consultez la page de tarification d'Aurora pour obtenir des informations sur les tarifs et la disponibilité régionale.

lectures optimisées d'Amazon Aurora disponible pour Aurora PostgreSQL est une nouvelle option de rapport prix/performances qui permet d'améliorer la latence des requêtes jusqu'à 8 fois et de réaliser jusqu'à 30 % d'économies par rapport aux instances qui n'en sont pas dotées. 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.

Lectures optimisées d'Amazon Aurora for Aurora PostgreSQL offre aux clients disposant d'applications sensibles à la latence et de grands ensembles de travail une alternative intéressante en termes de rapport prix/performances pour respecter leurs SLA professionnels et tirer encore plus 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 voir la disponibilité des régions 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. Consultez la documentation Lectures optimisées d'Amazon Aurora pour commencer.

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. Cette durée de rattrapage peut être accélérée en activant la gestion du 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 Amazon Aurora compatible avec PostgreSQL.

Oui. Le machine learning (ML) Aurora expose les modèles ML en tant que fonctions SQL, ce qui vous permet d'utiliser le SQL standard pour appeler les modèles ML, leur transmettre des données et renvoyer les prévisions sous forme de résultats de requête. pgvector exige que les intégrations vectorielles soient stockées dans la base de données, ce qui nécessite d'exécuter le modèle ML sur le texte source ou les données d'image pour générer des intégrations, puis de les déplacer par lots dans Aurora PostgreSQL.

Aurora ML peut faire de ce processus un processus en temps réel permettant aux intégrations d'être maintenues à jour dans Aurora PostgreSQL en faisant des appels périodiques à Amazon Bedrock ou Amazon SageMaker qui renvoie les intégrations les plus récentes de votre modèle.

Les lectures optimisées pour Amazon Aurora PostgreSQL avec pgvector augmentent le nombre de requêtes par seconde pour la recherche vectorielle jusqu'à 9 fois 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.

Vous devez utiliser l'intégration zéro ETL d'Amazon Aurora avec 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 d'Aurora avec Amazon Redshift est disponible sur l'édition compatible avec Aurora MySQL pour la version 3.05 d'Aurora MySQL (compatible avec MySQL 8.0.32) et les versions ultérieures dans les régions USA Est (Ohio), USA Est (Virginie du Nord), USA Ouest (Oregon), Asie-Pacifique (Singapour), Asie-Pacifique (Sydney), Asie-Pacifique (Tokyo), Europe (Francfort), Europe (Irlande) et Europe (Stockholm). L'intégration zéro ETL d'Aurora avec Amazon Redshift est disponible dans l'édition compatible avec Aurora PostgreSQL pour Aurora PostgreSQL 15.4 dans la région USA Est (Ohio).

L'intégration zéro ETL d'Aurora avec Amazon Redshift vous évite de créer et de gérer des pipelines de données complexes. Vous pouvez consolider les données d'un ou de plusieurs clusters de bases de données Aurora vers un cluster de base de données Amazon Redshift unique et d'exécuter des analyses et un machine learning en temps quasi réel à l'aide d'Amazon Redshift sur des pétaoctets de données transactionnelles provenant d'Aurora. 

L'intégration zéro ETL d'Aurora avec 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 des analyses en temps quasi réel sur les données transactionnelles sans avoir à gérer d'infrastructure pour les pipelines de données.

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 Amazon Redshift. Une fois l'intégration créée, la base de données Aurora sera répliquée sur Amazon Redshift 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.

Zéro ETL et le traitement continu des modifications de données sont proposés sans frais supplémentaires. Vous payez pour les ressources Amazon RDS et Amazon Redshift 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 améliorés
• Coûts d'exportation d'instantanés pour l'exportation initiale des données afin d'alimenter vos bases de données Amazon Redshift
• Stockage Amazon Redshift supplémentaire pour le stockage des données répliquées
• Coûts de transfert de données entre plusieurs AZ pour déplacer les données de la source vers la cible

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

Amazon DevOps Guru pour RDS est une nouvelle fonction à technologie ML pourAmazon RDS (qui inclu Amazon Aurora) qui est conçue pour détecter et diagnostiquer automatiquement les problèmes de performances et les problèmes opérationnels dans une base de données, vous permettant de traiter les problèmes en quelques minutes plutôt qu'en quelques jours.

Amazon DevOps Guru pour RDS est une fonction d'Amazon DevOps Guru qui est conçue pour détecter les problèmes opérationnels et de performance pour tous les moteurs Amazon RDS et 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 ex. 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 ML pour analyser les données de télémétrie collectées parAmazon RDS Performance Insights (PI). DevOps Guru pour RDS n'utilise aucune de vos données stockées dans la base de données lors de l'analyse. PI 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 commencer avec DevOps Guru pour RDS, assurez-vous que Performance Insights est activé via la console RDS, puis activez simplement DevOps Guru pour vos bases de données Amazon Aurora. Avec DevOps Guru, vous pouvez définir l'ensemble de votre compte AWS comme votre périmètre de couverture d'analyse, spécifier les piles AWS CloudFormation que DevOps Guru doit analyser ou utiliser les identifications AWS pour créer le regroupement de ressources que vous souhaitez faire analyser par DevOps Guru.

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.

R : Amazon RDS Performance Insights est une fonction de réglage et de surveillance des performances de bases de données qui collecte et visualise les métriques de performances des bases de données Amazon RDS, vous aidant ainsi à é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.

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 pour les versions de base de données pour Aurora sans serveur v2 et les instances provisionnées Aurora est disponible dans notre documentation. Les clients qui utilisent actuellement l'API Data pour Aurora sans serveur v1 sont invités à migrer vers Aurora sans serveur v2 afin de tirer parti de la nouvelle API Data et de la mise à l'échelle plus granulaire d'Aurora sans serveur v2.

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 existante pour Aurora sans serveur v1 restera une fonctionnalité d'Aurora sans serveur v1 à la fois pour l'édition compatible PostgreSQL et l'édition compatible MySQL d'Aurora. L'API Data pour Aurora sans serveur v2 et les instances provisionnées Aurora ne prend pas en charge Aurora sans serveur v1. 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 AWS Identity and Access Management (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 du cluster de base de données Aurora à l'aide d'un secret dans AWS Secrets Manager. 

L'utilisation de l'API Data avec Aurora sans serveur v1 reste disponible sans frais supplémentaires. 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 décrit sur la page de tarification d'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, comme c'était le cas avec l'API Data pour Aurora sans serveur v1.

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 de CloudTrail. En outre, l'utilisation d'AWS Secrets Manager entraînera des frais, comme indiqué sur la page de tarification d'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. Au bout d'un an, les clients commenceront à payer pour l'API Data comme décrit sur la page de tarification d'Aurora.

Les déploiements bleus/verts Amazon RDS sont disponibles dans les versions 5.6 et supérieures de l'édition compatible avec Amazon Aurora MySQL ainsi que dans les versions 11.21, 12.16, 13.12, 14.9, 15.4 et supérieures de l'édition compatible avec Amazon Aurora 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) d'Aurora.

L'exécution de vos charges de travail sur des instances vertes vous coûtera le même prix que pour 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 du stockage, le coût des E/S en lecture/écriture et toutes les fonctions activées, telles que le coût des 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 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 bases 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 à la fois dans les environnements bleus et ceux verts, jusqu'à ce que l'opération soit terminée. 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 transfert et celui de production. Une fois que les environnements de production et de transfert sont parfaitement synchronisés, les déploiements bleus/verts font de l'environnement de transfert le nouvel environnement de production, et ce, 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 performances/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.

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.

Non, les déploiements bleus/verts d'Amazon RDS ne prennent pas en charge Amazon Aurora Global Databases, le proxy Amazon RDS ni 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 très performantes et de les exécuter en toute sécurité sur Amazon Aurora. Ce faisant, TLE améliore votre temps de mise sur le marché et supprime la charge imposée aux administrateurs de bases de données pour 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.

TLE pour PostgreSQL (français non garanti) est disponible pour Amazon Aurora PostgreSQL-Compatible Edition sur les versions 14.5 et supé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 (français non garanti) dans PostgreSQL en version 14.5 ou supérieure dans Amazon Aurora.

TLE pour PostgreSQL (français non garanti) 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 (français non garanti) est disponible pour les clients de Aurora sans coût supplémentaire.

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 met en œuvre 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).

TLE pour PostgreSQL (français non garanti) prend actuellement en charge JavaScript, PL/pgSQL, Perl et SQL.

Une fois que le rôle rds_superuser active TLE pour PostgreSQL (français non garanti), vous pouvez déployer les extensions TLE à l'aide de 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.

TLE pour PostgreSQL (français non garanti) accède à 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.

Vous pouvez en savoir plus sur le projet TLE pour PostgreSQLsur la page GitHub de TLE officielle.