FAQ Amazon RDS

Vous pouvez considérer une instance de base de données comme un environnement de base de données dans le cloud comprenant les ressources de calcul et de stockage que vous spécifiez. Vous pouvez créer et supprimer des instances de base de données, définir/affiner des attributs d'infrastructure de vos instances de base de données et contrôler l'accès et la sécurité via la console de gestion AWS, les API Amazon RDS et l'interface de ligne de commande AWS. Vous pouvez exécuter une ou plusieurs instances de base de données, et chacune de ces instances peut prendre en charge une ou plusieurs bases de données, ou différents schémas de bases de données, selon le type de moteur.

Pour créer des instances de base de données, il suffit d'utiliser le Console de gestion AWS, les API Amazon RDS ou l'interface de ligne de commande AWS. Pour lancer une instance de base de données à l'aide de la Console de gestion AWS, cliquez sur « RDS », puis sur le bouton « Launch DB Instance » (Lancer une instance de base de données) dans l'onglet Instances (Instances). De là, vous pouvez préciser les paramètres de votre instance de base de données, notamment le moteur et la version de la DB, le modèle de licence, le type d'instance, le type et la quantité de stockage et les informations d'identification de l'utilisateur principal.

Vous pouvez également modifier la politique de rétention de sauvegarde, le créneau de sauvegarde préféré et le créneau de maintenance planifié de votre instance de base de données. Vous pouvez également créer votre instance de base de données à l'aide de l'API CreateDBInstance ou de la commande create-db-instance.

Une fois que votre instance de base de données est disponible, vous pouvez récupérer son point de terminaison via la description d'instance de base de données dans la console de gestion AWS, l'API DescribeDBInstances ou la commande describe-db-instances. En utilisant ce point de terminaison, vous pouvez construire la chaîne de connexion requise pour vous connecter directement à votre instance de base de données en utilisant votre outil de base de données ou langage de programmation préféré. Afin d'autoriser les demandes de réseau vers votre instance de base de données en cours d'exécution, vous devez autoriser l'accès. Pour une explication détaillée sur la construction de votre chaîne de connexion et sur le démarrage, consultez notre guide de démarrage.

Par défaut, les clients sont autorisés à avoir jusqu'à 40 instances DB Amazon RDS au total. Sur ces 40 instances, jusqu'à 10 peuvent être des instances de base de données RDS for Oracle ou RDS for SQL Server exécutées sous le modèle « License Included » (licence incluse). Les 40 instances peuvent être utilisées pour Amazon Aurora, RDS for PostgreSQL, RDS for MySQL, RDS for MariaDB, and RDS for Oracle dans le cadre du modèle Apportez votre propre licence (BYOL). Veuillez noter qu'Amazon RDS pour SQL Server est limité à 100 bases de données par instance de base de données. Pour en savoir plus, consultez le Guide de l'utilisateur Amazon RDS for SQL Server.

• RDS pour Amazon Aurora : pas de limite imposée par le logiciel
• RDS pour MySQL : Pas de limite imposée par le logiciel
• RDS pour MariaDB : pas de limite imposée par le logiciel
• RDS pour Oracle : une base de données par instance ; pas de limite imposée par le logiciel quant au nombre de schémas par base de données
• RDS pour SQL Server : jusqu'à 100 bases de données par instance
• RDS pour PostgreSQL : Pas de limite imposée par le logiciel
• RDS pour Db2 : jusqu’à 1 base de données par instance

Vous trouverez ci-dessous plusieurs façons d'importer des données dans Amazon RDS :

• MySQL : utilitaires mysqldump ou mysqlimport
• Oracle : Data Pump, import/export, ou SQL Loader
• SQL Server : assistant Import/Export, fichiers de sauvegarde complets (.bak) ou Bulk Copy Program (BCP)
• PostgreSQL : pg_dump

Pour en savoir plus sur l'importation et l'exportation des données, consultez les guides suivants : Guide pour l'importation des données pour MySQL, Guide pour l'importation des données pour Oracle, Guide pour l'importation des données pour SQL Server, Guide pour l'importation des données pour PostgreSQL ou Guide pour l'importation des données pour Db2.

Par ailleurs, AWS Database Migration Service peut vous aider à migrer des bases de données vers AWS en toute sécurité.

La fenêtre de maintenance d'Amazon RDS vous offre la possibilité de contrôler le moment auquel les modifications d'instance de base de données, les mises à niveau de version de moteur de base de données et la correction de logiciel ont lieu, dans le cas où celles-ci seraient demandées ou nécessaires. Si un événement de maintenance est planifié pour une semaine donnée, il sera déclenché au cours de la fenêtre de maintenance que vous identifiez.

Amazon RDS doit déconnecter votre instance DB durant les opérations de calcul de dimensionnement (qui ne prennent généralement que quelques minutes en tout), les mises à niveau de version de moteur de base de données et la correction de logiciel requise. La correction logiciel requise est planifiée automatiquement et uniquement pour les correctifs en rapport avec la sécurité et la durabilité. Ce type de correction a lieu peu fréquemment (en général une fois à quelques mois d'intervalle) et devrait rarement nécessiter plus d'une fraction de votre fenêtre de maintenance.

Si vous ne spécifiez pas une fenêtre de maintenance hebdomadaire préférée lors de la création de votre instance de base de données, une valeur par défaut de 30 minutes est assignée. Si vous souhaitez modifier la planification automatique de la maintenance, vous pouvez le faire en modifiant votre instance de base de données via la console de gestion AWS, l'API ModifyDBInstance ou la commande modify-db-instance. Si vous le souhaitez, vous pouvez attribuer un créneau de maintenance préféré différent à chacune de vos instances DB.

L'exécution de votre instance DB comme déploiement multi-AZ peut réduire davantage l'impact d'un événement de maintenance. Pour plus d'informations sur les opérations de maintenance, consultez le Guide de l'utilisateur Amazon RDS.

Pour les bases de données de production, nous vous conseillons d'activer la surveillance améliorée qui permet d'accéder à plus de 50 métriques, comme le processeur, la mémoire, le système de fichiers et les entrées/sorties de disque. Vous pouvez activer ces fonctionnalités par instance et choisir la granularité (jusqu'à 1 seconde). Les niveaux élevés d'utilisation de CPU peuvent réduire les performances des requêtes et dans ce cas, vous devrez peut-être envisager le dimensionnement de votre classe d'instance DB. Pour en savoir plus sur la surveillance de votre instance de base de données, consultez le Guide de l'utilisateur Amazon RDS.

Si vous utilisez RDS pour MySQL ou MariaDB, vous pouvez accéder aux journaux de requêtes lentes pour votre base de données, afin de déterminer si des requêtes SQL s'exécutent lentement et, le cas échéant, les caractéristiques de performance de chacune d'entre elles. Vous pouvez définir le paramètre DB slow_query_log et interroger la table mysql.slow_log pour vérifier les requêtes SQL qui s'exécutent lentement. Pour en savoir plus, consultez le Guide de l'utilisateur Amazon RDS.

Si vous utilisez RDS pour Oracle, vous pouvez utiliser les données du fichier trace Oracle pour identifier les requêtes lentes. Pour plus d'informations sur l'accès aux données du fichier trace, reportez-vous au Guide de l'utilisateur Amazon RDS. 

Si vous utilisez RDS pour SQL Server, vous pouvez exploiter les fichiers trace SQL Server côté client pour identifier les requêtes lentes. Pour plus d'informations sur l'accès aux données des fichiers de trace, reportez-vous au Guide de l'utilisateur Amazon RDS.

Pour obtenir la liste des versions de moteur de base de données prises en charge, consultez la documentation de chaque moteur :

• Amazon Aurora
• Amazon RDS pour PostgreSQL
• Amazon RDS for MySQL
• Amazon RDS for MariaDB
• Amazon RDS pour SQL Server
• Amazon RDS pour Oracle
• Amazon RDS pour Db2

Consultez la page des questions fréquentes pour chaque moteur de base de données Amazon RDS afin d'en savoir plus sur la numérotation des versions.

• Amazon RDS for MySQL
• Amazon RDS for MariaDB
• Amazon RDS pour PostgreSQL
• Amazon RDS pour Oracle
• Amazon RDS pour SQL Server
• Amazon Aurora
• Amazon RDS pour Db2

À mesure que le temps passe, Amazon RDS inclut la prise en charge des nouvelles versions de moteurs de bases de données majeures et mineures. Le nombre de nouvelles versions prises en charge varie en fonction de la fréquence et du contenu des versions et des correctifs fournis par le fournisseur du moteur ou par l'organisation en charge de son développement, ainsi qu'en fonction du résultat d'un examen approfondi de ces versions et correctifs par notre équipe d'ingénierie de bases de données. Toutefois, en règle générale, nous souhaitons prendre en charge de nouvelles versions de moteur dans les 5 mois après leur disponibilité générale.

Vous pouvez spécifier n'importe quelle version (majeure ou mineure) actuellement prise en charge lors de la création d'une nouvelle instance de base de données via l'opération de lancement d'une instance de base de données dans la console de gestion AWS ou l'API CreateDBInstance. Veuillez noter que toutes les versions de moteur de base de données ne sont pas disponibles dans toutes les régions AWS.

Amazon RDS s'efforce de faire en sorte que votre instance de base de données reste à jour en vous fournissant les nouvelles versions des moteurs de base de données pris en charge. Après la publication d'une nouvelle version d'un moteur de base de données par le fournisseur ou par l'organisation en charge du développement, celle-ci doit être testée minutieusement par notre équipe d'ingénieurs spécialisés en bases de données avant d'être mise à disposition dans Amazon RDS.

Nous vous recommandons de veiller à ce que votre instance de base de données soit toujours mise à niveau vers la version mineure la plus récente, car celle-ci inclura les dernières corrections liées à la sécurité et aux fonctionnalités. Contrairement aux mises à niveau des versions majeures, Les mises à niveau des versions mineures comprennent uniquement les changements rétrocompatibles avec les versions mineures antérieures (de la même version majeure) du moteur de base de données. 

Si une nouvelle version mineure ne contient pas des corrections qui pourraient être utiles aux clients Amazon RDS, nous pourrions choisir de ne pas la mettre à disposition dans Amazon RDS. Dès qu'une nouvelle version mineure est disponible dans Amazon RDS, nous faisons en sorte qu'elle soit la version mineure préférée pour les nouvelles instances de base de données. 

Pour mettre à niveau manuellement une instance de base de données vers une version de moteur prise en charge, utilisez la commande Modify DB Instance (Modifier l'instance de base de données) dans la console de gestion AWS ou l'API ModifyDBInstance et réglez le paramètre DB Engine Version (Version de moteur de base de données) sur la version souhaitée. La mise à niveau sera effectuée par défaut lors de votre prochaine fenêtre de maintenance. Vous pouvez également choisir d'effectuer la mise à niveau immédiatement en cochant l'option Apply Immediately (Appliquer immédiatement) dans l'API de la console.

Si nous déterminons qu'une nouvelle version de moteur mineure contient des corrections de bugs importantes par rapport à une ancienne version mineure précédente, nous programmerons des mises à niveau automatiques pour les instances de base de données pour lesquelles le réglage « Auto Minor Version Upgrade » (Mise à niveau automatique de la version mineure) indique « Yes » (Oui). L'exécution de ces mises à niveau sera prévue pour les fenêtres de maintenance indiquées par le client.

Nous les planifions ainsi afin que vous puissiez vous y adapter, car une période d'indisponibilité est nécessaire pour mettre à niveau une version de moteur de base de données, même en cas d'instances multi-AZ. Si vous souhaitez désactiver les mises à niveau automatiques de versions mineures, vous pouvez le faire en définissant le réglage Auto Minor Version Upgrade (Mise à niveau automatique de version mineure) sur « No » (Non).

Dans le cas de RDS pour Oracle et RDS pour SQL Server, si la mise à niveau vers la prochaine version mineure nécessite de changer d'édition, il se peut que nous ne puissions pas programmer de mises à niveau automatiques, même si vous avez activé le réglage Auto Minor Version Upgrade (Mise à niveau automatique de version mineure). Dans une telle situation, nous déterminons au cas par cas si les mises à niveau doivent être programmées.

Etant donné que les mises à niveau de version majeure impliquent quelques risques de compatibilité, elles ne se produiront pas automatiquement et doivent être lancées par vous (sauf en cas de dépréciation de version majeure, voir ci-dessous). Pour plus d'informations sur la mise à niveau d'une instance de base de données vers une nouvelle version du moteur de base de données, consultez le Guide de l'utilisateur Amazon RDS.

Oui. Vous pouvez le faire en créant un snapshot DB de votre instance DB existante, en restaurant depuis le snapshot pour créer une nouvelle instance DB, puis en lançant une mise à niveau de version pour la nouvelle instance DB. Vous pouvez expérimenter ensuite en toute sécurité sur le clone mis à niveau de votre instance DB avant de décider si vous voulez mettre à niveau votre instance DB d'origine.

Pour en savoir plus sur la restauration d'un instantané de base de données, consultez le Guide de l'utilisateur Amazon RDS.

• Nous avons l'intention de prendre en charge des versions MySQL majeures (ex. : MySQL 5.6, PostgreSQL 9.6) pendant au moins 3 ans après leur prise en charge initiale par Amazon RDS.
• Nous avons l'intention de prendre en charge des versions MySQL mineures (ex. : MySQL 5.6.37, PostgreSQL 9.6.1) pendant au moins 1 an après leur prise en charge initiale par Amazon RDS.

Nous arrêterons de mettre à jour les versions de moteur majeures et mineures de façon périodique. Les versions majeures sont mises à disposition au moins jusqu'à la fin de vie de la version communautaire correspondante ou jusqu'à ce que la version ne reçoive plus de correctifs logiciels ou de mises à jour de sécurité. Pour les versions mineures, on envisage la dépréciation lorsqu'elles rencontrent des bugs ou des problèmes de sécurité importants, qui ont été résolus dans une version mineure ultérieure.

Alors que nous nous efforçons de satisfaire à ces directives, nous sommes susceptibles, dans certains cas, de rendre obsolètes des versions mineures ou majeures spécifiques plus tôt que prévu, notamment en cas de problèmes de sécurité. Dans l'éventualité peu probable où cela se produit, Amazon RDS mettra automatiquement votre moteur de base de données à niveau pour résoudre ce problème. Des conditions particulières peuvent exiger des calendriers différents, selon le problème à résoudre.

Lorsqu'une version mineure d'un moteur de base de données devient obsolète dans Amazon RDS, nous attendons trois (3) mois après l'annonce avant de procéder aux mises à niveau automatiques. Au terme de ce délai, nous programmons la mise à niveau automatique de toutes les instances qui exécutent encore la version mineure obsolète vers la version mineure la plus récente prise en charge pour qu'elle ait lieu lors de leur fenêtre de maintenance planifiée.

Si une version majeure d'un moteur de base de données devient obsolète dans Amazon RDS, nous accordons un délai minimum de six (6) mois suivant l'annonce de l'obsolescence avant la fin duquel vous devrez avoir mis à niveau la version concernée vers une version majeure prise en charge. Au terme de ce délai, une mise à niveau automatique vers la dernière version majeure sera appliquée à toutes les instances exécutant toujours la version obsolète lors de leur fenêtre de maintenance programmée.

Dans certains cas, nous pouvons déprécier certaines versions majeures ou mineures sans préavis, par exemple lorsque nous découvrons qu'une version ne répond pas à nos critères de qualité, de performance ou de sécurité. Dans le cas peu probable où de tels événements se produiraient, Amazon RDS interrompra la création de nouvelles instances de base de données et de clusters avec ces versions. Les clients existants pourront continuer à exploiter leurs bases de données. Des conditions particulières peuvent exiger des calendriers différents, selon le problème à résoudre.

Vous ne payez que ce que vous utilisez et il n'y a pas de frais minimums ou d'installation. Vous êtes facturé sur la base des éléments suivants :

• Heures d'instance DB – selon la classe (par ex. db.t2.micro, db.m4.large) de l'instance DB consommée. Les heures d'instance de base de données partielles effectuées sont facturées par incréments d'une seconde, avec un minimum facturable de 10 minutes, après un changement de statut facturable, tel que la création, le démarrage ou la modification de la classe d'instance de base de données. Pour en savoir plus, lisez notre annonce sur les nouveautés.
• Stockage (par Go par mois) : capacité de stockage que vous avez réservée à votre instance de base de données. Si vous dimensionnez votre capacité de stockage au cours du mois, votre facture sera ajustée au prorata.
• Demandes d'E/S par mois : nombre total de demandes d'E/S de stockage dont vous disposez (pour le stockage de type magnétique Amazon RDS et Amazon Aurora uniquement)
• IOPS provisionnés par mois : taux d'IOPS provisionnés, indépendamment des IOPS consommés (pour le stockage IOPS provisionnés Amazon RDS (SSD) uniquement).
• Stockage de sauvegarde – le stockage de sauvegarde est le stockage associé à vos sauvegardes de base de données automatisées et à tout instantané de base de données généré par le client. L'allongement de votre période de rétention de sauvegarde ou la création d'instantanés de base de données supplémentaires augmente le stockage de sauvegarde consommé par votre base de données.
• Transfert de données : transfert de données sur Internet entrant et sortant de votre instance de base de données.

Pour des informations sur les tarifs d'Amazon RDS, consultez la section des tarifs sur la page des produits d'Amazon RDS.

La facturation commence dès que l'instance de base de données est disponible. La facturation continue jusqu'à ce que l'instance de base de données se termine, ce qui se produira au moment de la suppression ou dans le cas d'une défaillance d'instance.

Les heures d'instance de base de données sont facturées pour chaque heure d'exécution de votre instance DB en état de disponibilité. Si vous ne souhaitez plus être facturé pour votre instance DB, vous devez l'arrêter ou la supprimer afin que des heures d'instance supplémentaires ne vous soient pas facturées. Les heures d'instance de base de données partielles effectuées sont facturées par incréments d'une seconde, avec un minimum facturable de 10 minutes, après un changement de statut facturable, tel que la création, le démarrage ou la modification de la classe d'instance de base de données.

Pendant l'arrêt de votre instance de base de données, vous êtes facturé pour le stockage provisionné (y compris les IOPS provisionnés) et le stockage de sauvegardes (y compris les clichés manuels et les sauvegardes automatiques avec fenêtre de conservation spécifiée), mais pas pour les heures d'instance de base de données.

Le stockage de sauvegarde gratuit est fourni jusqu'à concurrence du stockage total de la base de données provisionnée de votre compte dans toute la région. Par exemple, si vous avez une instance de base de données MySQL avec 100 Go de stockage provisionné sur le mois, et une instance de base de données PostgreSQL avec 150 Go de stockage provisionné sur le mois, toutes deux dans la même région et le même compte, nous fournirons 250 Go de stockage de sauvegarde dans ce compte et cette région sans frais supplémentaires. Vous ne serez facturé que pour le stockage de sauvegarde qui dépasse ce montant.

Chaque jour, le stockage total de la base de données provisionnée de votre compte dans la région est comparé à votre stockage total de sauvegarde dans la région, et seul le stockage de sauvegarde excédentaire est facturé. Par exemple, si vous avez exactement 10 Go de stockage de sauvegarde excédentaire chaque jour, vous serez facturé pour 10 Go par mois de stockage de sauvegarde pour le mois. Par ailleurs, si vous disposez de 300 Go de stockage provisionné chaque jour et de 500 Go de stockage de sauvegarde chaque jour, mais seulement pour la moitié du mois, vous ne serez facturé que pour 100 Go par mois de stockage de sauvegarde (et non 200 Go par mois), puisque la charge est calculée quotidiennement (au prorata) et que les sauvegardes n'ont pas existé pendant tout le mois. Veuillez noter que le stockage de sauvegarde gratuit est spécifique au compte et à la région.

La taille de vos sauvegardes est directement proportionnelle à la quantité de données sur votre instance. Par exemple, si vous avez une instance de base de données avec 100 Go de stockage provisionné, mais que vous n'y stockez que 5 Go de données, votre première sauvegarde ne sera que d'environ 5 Go (et non 100 Go). Les sauvegardes ultérieures sont incrémentielles et ne stockent que les données modifiées sur votre instance de base de données. Veuillez noter que la taille du stockage de sauvegarde n'est pas affichée dans la console RDS ni dans la réponse de l'API DescribeDBSnapshots.

Le stockage mis en service sur votre instance DB pour vos données principales est situé dans une seule zone de disponibilité. Lorsque votre base de données est sauvegardée, les données sauvegardées (y compris les journaux de transactions) sont répliquées de manière géo-redondante sur plusieurs zones de disponibilité pour fournir des niveaux encore plus élevés de durabilité des données. Le prix du stockage de sauvegarde au-delà de votre attribution gratuite reflète cette réplication supplémentaire, qui a lieu pour maximiser la durabilité de vos sauvegardes vitales.

Si vous spécifiez que votre instance DB doit être un déploiement multi-AZ, vous serez facturé en fonction du prix multi-AZ posté sur la page des tarifs d'Amazon RDS. La facturation multi-AZ est basée sur :

• Heures d'instance de base de données multi-AZ, selon la classe (par ex. db.t2.micro, db.m4.large) de l'instance de base de données consommée. Comme pour les déploiements standard dans une seule zone de disponibilité, les heures d'instance de base de données partielles effectuées sont facturées par incréments d'une seconde, avec un minimum facturable de 10 minutes, après un changement de statut facturable, tel que la création, le démarrage ou la modification de la classe d'instance de base de données. Si vous convertissez votre déploiement d'instance DB entre le mode standard et Multi-AZ dans une heure donnée, les deux tarifs s'appliqueront pour cette heure.
• Stockage réservé (pour les instances DB Multi-AZ) – si vous convertissez votre déploiement d'instance DB entre le mode standard et Multi-AZ dans une heure donnée, le tarif de stockage le plus élevé s'appliquera pour cette heure.
• Demandes E/S par mois – nombre total de demandes E/S de stockage que vous avez. Les déploiements Multi-AZ consomment un plus grand volume de demandes I/O que les déploiements d'instance DB standards, en fonction de votre ratio écriture/lecture de base de données. Écrire l'utilisation E/S associée aux mises à jour de base de données doublera, car Amazon RDS réplique de manière synchrone vos données vers l'instance DB de secours. L'utilisation en lecture E/S restera la même.
• Stockage de sauvegarde – votre utilisation de stockage de sauvegarde ne changera pas, que votre instance DB soit un déploiement standard ou multi-AZ. Les sauvegardes seront simplement prises de votre base de données de secours, afin d'éviter la suspension I/O sur l'instance DB principale.
• Transfert de données – le transfert de données durant la réplication des données entre vos bases de données principale et de secours ne vous est pas facturé. Le transfert de données sur Internet entrant et sortant de votre instance DB est facturé de la même façon qu'avec un déploiement standard.

Sauf indication contraire, nos prix n'incluent pas les taxes et redevances applicables, y compris la TVA et les taxes sur les ventes applicables. Pour les clients dont l'adresse de facturation est située au Japon, l'utilisation de services AWS est soumise à la taxe sur la consommation applicable dans ce pays. En savoir plus.

L'offre gratuite d'AWS pour Amazon RDS permet d'utiliser gratuitement des instances de base de données mono-AZ de type Micro exécutant MySQL, MariaDB, PostgreSQL et SQL Server Express Edition. Le niveau d'offre gratuite est limité à 750 heures d'utilisation d'instances par mois. De plus, les clients bénéficient gratuitement de 20 Go de stockage de base de données à usage général (SSD) et de 20 Go de stockage de sauvegarde par mois.

Les nouveaux comptes AWS bénéficient d'un an d'accès à l'offre gratuite d'AWS. Pour en savoir plus, consultez la page Questions fréquentes (FAQ) de l'offre gratuite d'AWS.

Oui. Vous pouvez exécuter plusieurs instances de base de données mono-AZ de type Micro simultanément et remplir les conditions pour que leur utilisation soit comptabilisée dans le cadre de l'offre gratuite AWS pour Amazon RDS. Toutefois, toute utilisation au-delà de ces 750 heures, sur l'ensemble des instances de base de données Amazon RDS de type Micro mono-AZ, et dans toutes les régions et tous les moteurs de base de données éligibles, est facturée en fonction des tarifs standard d'Amazon RDS.

Exemple : si vous exécutez deux instances de base de données mono-AZ de type Micro pendant 400 heures chacune au cours d'un même mois, vous totalisez 800 heures d'utilisation d'instances, sur lesquelles 750 heures sont gratuites. Vous serez facturé pour les 50 heures restantes en fonction des tarifs standard d'Amazon RDS.

Non. Un client bénéficiant de l'offre gratuite d'AWS peut profiter de 750 heures d'utilisation gratuite au maximum sur l'ensemble des instances Micro exécutant MySQL, PostgreSQL ou SQL Server Express Edition. Toutefois, toute utilisation au-delà de ces 750 heures, sur l'ensemble des instances de base de données Amazon RDS de type Micro Mono-AZ, et dans toutes les régions et tous les moteurs de base de données éligibles, est facturée en fonction des tarifs standard d'Amazon RDS.

Vous êtes facturé selon les tarifs standard d'Amazon RDS pour les heures d'instance dépassant celles offertes par le Niveau gratuit. Pour en savoir plus, consultez la page relative à la tarification d'Amazon RDS.

Les instances réservées Amazon RDS vous permettent de réserver une instance de base de données pour une durée d'un ou trois ans. En retour, vous bénéficiez d'une remise conséquente sur les tarifs de l'instance de base de données par rapport à la tarification des instances à la demande. Il existe trois options de paiement pour les instances réservées : Aucuns frais initiaux, Frais initiaux partiels et Paiement total anticipé. Celles-ci vous permettent de trouver le juste équilibre entre le montant initial payé et le tarif horaire effectif.

D'un point de vue fonctionnel, les instances de base de données réservées et celles à la demande sont exactement identiques. La seule différence réside dans leur facturation. Avec des instances réservées, vous effectuez une réservation pour un ou trois ans, et profitez en retour d'un tarif à l'utilisation horaire préférentiel (par rapport aux instances à la demande) jusqu'au terme de la réservation. A moins que vous n'achetiez des instances réservées dans une région, toutes les instances de base de données seront facturées aux tarifs horaires à la demande.

Vous pouvez acheter une instance réservée dans la section « Reserved Instance » de la console de gestion AWS pour Amazon RDS. Vous pouvez également utiliser l'API Amazon RDS ou l'interface de ligne de commande AWS pour afficher la liste des réservations disponibles à l'achat, puis acheter une réservation d'instance de base de données.

Lorsque vous avez acheté une réservation, l'utilisation d'une instance de base de données réservée est semblable à celle d'une instance de base de données à la demande. Lancez une instance de base de données en utilisant la même classe d'instance, le même moteur et la même région que ceux pour lesquels vous avez effectué la réservation. Tant que votre achat de réservation est actif, Amazon RDS appliquera un tarif horaire réduit à la nouvelle instance DB.

Les instances réservées Amazon RDS sont achetées pour une région plutôt que pour une zone de disponibilité spécifique. Les instances réservées n'étant pas spécifiques à une zone de disponibilité, elles ne fournissent pas de réservations de capacité. Ainsi, même si la capacité est limitée dans une zone de disponibilité, les réservations peuvent toujours être achetées dans la région et la remise s'appliquera à l'utilisation correspondante dans une zone de disponibilité de cette région.

Vous pouvez acheter jusqu'à 40 instances DB réservées. Si vous souhaitez exécuter plus de 40 instances de base de données, veuillez remplir le formulaire de demande d'instance de base de données Amazon RDS.

Il suffit d'acheter une réservation d'instance de base de données avec la même classe d'instance de base de données, le même moteur de base de données, la même option Multi-AZ et le même modèle de licence dans la même région que l'instance de base de données que vous exécutez actuellement et que vous aimeriez réserver. Lorsque la réservation est terminée, Amazon RDS appliquera automatiquement le nouveau coût d'utilisation horaire à votre instance DB existante.

Les changements de tarif associés à une instance réservée sont activés une fois que votre demande a été reçue, alors que l'autorisation de paiement est traitée. Vous pouvez suivre le statut de votre réservation sur la page d'activité du compte AWS ou en utilisant l'API DescribeReservedDBInstances ou la commande describe-reserved-db-instances. Si le paiement unique ne peut pas être autorisé avant la période de facturation suivante, le tarif réduit ne sera pas appliqué.

Lorsque votre période de réservation expire, votre instance réservée reviendra au tarif d'utilisation horaire à la demande pour votre classe et région d'instance DB.

Les opérations de création, de modification et de suppression d'instances de base de données réalisées à l'aide d'Amazon RDS ne font pas la distinction entre les instances à la demande et les instances réservées. Lors du calcul de votre facture, notre système applique automatiquement votre/vos réservations, afin que toutes les instances DB éligibles soient facturées à un tarif horaire inférieur, conformément à la tarification des instances DB réservées.

Chaque réservation est associée aux attributs suivants : moteur de base de données, classe d'instance de base de données, option de déploiement Multi-AZ, modèle de licence et région.

Une réservation pour un moteur DB et un modèle de licence éligible pour la taille flexible (MySQL, MariaDB, PostgreSQL, Amazon Aurora ou « BYOL » d'Oracle) s'applique automatiquement à une instance de base de données en cours d'exécution, quelle qu'en soit la taille, dans la même famille d'instances (par exemple, M4, T2 ou R3) pour le même moteur de base de données et la même région. En outre, la réservation s'appliquera également aux instances DB s'exécutant dans leurs options de déploiement soit mono-AZ, soit multi-AZ.

Par exemple, disons que vous avez acheté une réservation MySQL db.m4.2xlarge. Si vous décidez de dimensionner l'instance DB en cours d'exécution selon une réservation db.m4.4xlarge, le tarif décompté de cette instance réservée couvrira la moitié de l'utilisation de la plus grande instance DB.

Si vous exécutez un moteur DB ou un modèle de licence non éligible pour la taille flexible (Microsoft SQL Server ou « License Included » d'Oracle), chaque réservation ne peut s'appliquer qu'à une instance DB avec les mêmes attributs pour la période de réservation. Si vous décidez de modifier l'un des attributs de votre classe d'instance DB en cours avant la fin de la période de réservation, vos tarifs d'utilisation horaire pour cette instance DB repasseront aux tarifs horaires à la demande.

Pour en savoir plus sur la flexibilité de la taille, consultez le Guide de l'utilisateur Amazon RDS.

Chaque instance réservée est associée à une région spécifique, qui est fixée pendant la durée de la réservation et ne peut pas être modifiée. Toutefois, chaque réservation peut être utilisée dans n'importe laquelle des zones de disponibilité au sein de la région associée.

Oui. Lorsque vous achetez une instance réservée, vous pouvez sélectionner l'option Multi-AZ parmi les configurations d'instance de base de données disponibles. De plus, si vous utilisez un modèle de moteur et de licence de base de données qui prend en charge les instances réservées de taille flexible, une instance réservée multi-AZ couvrira l'utilisation de deux instances de base de données mono-AZ.

Une réservation d'instance DB peut être appliquée à un réplica en lecture, à condition que la classe d'instance DB et la région soient les mêmes. Lors du calcul de votre facture, notre système applique automatiquement votre/vos réservations, afin que toutes les instances DB éligibles soient facturées à un tarif horaire inférieur, conformément à la tarification des instances DB réservées.

Non, vous ne pouvez pas annuler votre instance DB réservée, et le paiement initial (le cas échéant) n'est pas remboursable. Vous continuerez de payer chaque heure de la période définie pour votre instance DB réservée, quelle que soit son utilisation.

Lorsque vous achetez une instance réservée avec l'option de paiement Tous les frais initiaux, vous réglez toute la durée de réservation de l'instance en un seul paiement initial. Vous avez aussi la possibilité de ne pas payer de frais initiaux, en choisissant l'option Aucuns frais initiaux. La valeur totale de l'instance réservée avec l'option de paiement Aucuns frais initiaux est répartie sur chaque heure de la durée de réservation. Vous serez donc facturé pour chaque heure, quelle que soit votre utilisation. L'option de paiement Frais initiaux partiels se situe à mi-chemin entre les options Tous les frais initiaux et Aucuns frais initiaux. Vous payez une faible somme initiale et êtes ensuite facturé selon un tarif horaire réduit pour chaque heure de réservation de l'instance, quelle que soit votre utilisation.

Pour sélectionner votre classe d'instance de base de données et votre capacité de stockage initiale, vous devez évaluer les besoins de calcul, de mémoire et de stockage de votre application. Pour plus d'informations sur les classes d'instances de base de données disponibles, consultez le Guide de l'utilisateur Amazon RDS.

Vous pouvez mettre à l'échelle les ressources de calcul et les capacités de stockage allouées à votre instance de base de données à l'aide de la console de gestion AWS (en sélectionnant l'instance de base de données souhaitée et en cliquant sur le bouton Modifier), de l'API Amazon RDS ou de l'interface de ligne de commande AWS. Les ressources de mémoire et de CPU sont modifiées en changeant votre classe d'instance de base de données, et le stockage disponible est changé lorsque vous modifiez votre allocation de stockage. 

Veuillez noter que lorsque vous modifiez votre classe d'instance DB ou stockage attribué, les changements demandés seront appliqués pendant la fenêtre de maintenance spécifiée. Vous pouvez aussi utiliser l'indicateur « appliquer-immédiatement » pour appliquer immédiatement vos demandes de dimensionnement. N'oubliez pas que tout changement de système en attente sera également appliqué.

Certaines instances RDS pour SQL Server plus anciennes risquent de ne pas être admissibles à la mise à niveau de stockage. Consultez les Questions fréquentes (FAQ) sur RDS SQL Server pour plus d'informations.

Amazon RDS utilise les volumes EBS pour la base de données et le stockage de journal. En fonction de la taille de stockage demandée, Amazon RDS ajuste automatiquement sur plusieurs volumes EBS pour améliorer la performance IOPS. Pour MySQL et Oracle, sur une instance de base de données existante, vous pouvez observer une amélioration de la capacité en I/O si vous augmentez votre volume de stockage. Vous pouvez mettre à l'échelle la capacité de stockage allouée à votre instance de base de données en utilisant la console de gestion AWS, l'API ModifyDBInstance ou la commande rds-modify-db-instance.

Pour en savoir plus, consultez Stockage Amazon RDS.

La capacité de stockage de votre instance DB peut être augmentée tout en maintenant la disponibilité de l'instance DB. Toutefois, lorsque vous décidez d'augmenter ou de diminuer les ressources de calcul disponibles vers votre instance de base de données, votre base de données sera temporairement indisponible pendant la modification de la classe d'instance de base de données. Cette période d'indisponibilité ne dure généralement que quelques minutes et aura lieu pendant la fenêtre de maintenance pour votre instance DB, sauf si vous indiquez que la modification doit être appliquée immédiatement.

Amazon RDS prend en charge un éventail de classes d'instance DB et d'attributions de stockage pour répondre aux différents besoins des applications. Si votre application a besoin de plus de ressources de calcul que la classe d'instance DB la plus importante ou plus de stockage que l'attribution maximale, vous pouvez implémenter le partitionnement, diffusant ainsi vos données dans des instances DB multiples.

Le stockage à usage général (SSD) Amazon RDS convient à un large éventail de charges de travail de base de données dont les besoins en matière d'E/S sont modérés. Présentant une ligne de base de 3 IOPS/Go, avec la possibilité d'atteindre des pics de 3 000 IOPS, cette option de stockage offre des performances prévisibles qui répondent aux besoins de la plupart des applications.

Le stockage IOPS provisionnés (SSD) Amazon RDS est une option de stockage SSD conçue pour fournir des performances E/S rapides, prévisibles et constantes. Avec ce type de stockage, vous pouvez définir un taux d'E/S par seconde lors de la création d'une instance DB. Amazon RDS prévoit ce taux d'E/S par seconde pour toute la durée de vie de l'instance DB. Le stockage IOPS provisionnés (SSD) Amazon RDS est optimisé pour les charges de travail de base de données transactionnelles (OLTP) à fort taux d'E/S. Pour plus d'informations, consultez le Guide de l'utilisateur Amazon RDS.

Le stockage de type magnétique Amazon RDS s'avère utile pour les petites charges de travail de base de données où l'accès aux données est plus rare. Le stockage de type magnétique n'est pas recommandé pour les instances de base de données de production.

Choisissez le type de stockage le plus adapté à votre charge de travail.

• Charges de travail de base de données transactionnelles (OLTP) à hautes performances: Stockage IOPS provisionnés (SSD) Amazon RDS
• Charges de travail de base de données ayant des besoins modérés en matière d'E/S : Stockage à usage général (SSD) Amazon RDS

Les volumes IOPS pris en charge par Amazon RDS varient en fonction du moteur de base de données. Pour plus d'informations, consultez le Guide de l'utilisateur Amazon RDS.

Amazon RDS fournit deux méthodes différentes de sauvegarde et de restauration de vos sauvegardes automatisées et instantanés de base de données (DB Snapshots) de votre/vos instances DB.

La fonctionnalité de sauvegarde automatisée d'Amazon RDS permet la restauration à un instant dans le passé de votre instance de base de données. Lorsque les sauvegardes automatisées sont activées pour votre instance de base de données, Amazon RDS réalise automatiquement un instantané quotidien complet de vos données (pendant votre fenêtre de sauvegarde préférée) et capture les journaux de transaction (au fur et à mesure des mises à jour de votre instance de base de données). Lorsque vous effectuez une restauration à un instant dans le passé, les journaux de transaction sont appliqués à la sauvegarde quotidienne la plus appropriée, afin de restaurer votre instance DB à l'instant précis souhaité. 

Amazon RDS conserve les sauvegardes d'une instance de base de données pendant une période de temps limitée et spécifiée par l'utilisateur, la période de rétention, qui est de 7 jours par défaut, mais qui peut être définie jusqu'à 35 jours. Vous pouvez lancer une restauration à un moment donné et spécifier n'importe quelle seconde pendant votre période de rétention, jusqu'au point du dernier moment restaurable. Vous pouvez utiliser l'API DescribeDBInstances pour revenir au dernier moment restaurable pour votre instance de base de données, qui est généralement situé dans les cinq dernières minutes. 

Alternativement, vous pouvez trouver le Dernier moment restaurable pour une instance de base de données en le sélectionnant dans la Console de gestion AWS et en cherchant dans l'onglet « Description » dans le panneau inférieur de la Console.

Les snapshots DB sont lancés par l'utilisateur et vous permettent de sauvegarder votre instance de base de données dans un état connu aussi fréquemment que vous le souhaitez, puis de la restaurer à cet état spécifique à tout moment. Les snapshots DB peuvent être créés à l'aide de la Console de gestion AWS, de l'API CreateDBSnapshot ou de la commande create-db-snapshot, et sont conservés jusqu'à ce que vous les supprimiez explicitement.

Les instantanés effectués par Amazon RDS pour l'activation des sauvegardes automatisées sont à votre disposition pour copie (à l'aide de la console AWS ou de la commande copy-db-snapshot) ou pour la fonctionnalité de restauration d'instantané. Vous pouvez les identifier à l'aide du type d'instantané « automatisé ». De plus, vous pouvez identifier l'heure à laquelle l'instantané a été pris en consultant le champ Heure de création de l'instantané. 

Sachez que l'identifiant des instantanés « automatisés » contient également l'heure (temps universel coordonné) à laquelle l'instantané a été pris.

Remarque : lorsque vous réalisez une opération de restauration vers un moment donné ou depuis un snapshot DB, une nouvelle instance DB est créée avec un nouveau point de terminaison (l'ancienne instance DB peut être supprimée si vous le souhaitez). Vous pouvez ainsi créer des instances DB multiples à partir d'un snapshot DB spécifique ou d'un moment donné.

Par défaut, Amazon RDS active la sauvegarde automatique de votre instance de base de données avec une période de rétention de 7 jours. Si vous souhaitez modifier votre période de rétention des sauvegardes, vous pouvez le faire en utilisant la console RDS, l'API CreateDBInstance (pour la création d'une instance de base de données) ou l'API ModifyDBInstance (pour les instances existantes). Vous pouvez utiliser ces méthodes pour définir le paramètre RetentionPeriod sur n'importe quel nombre compris entre 0 jour (ce qui désactive les sauvegardes automatiques) et le nombre de jours de sauvegarde désiré, jusqu'à 35. La valeur ne peut pas être définie sur 0 si l'instance de base de données est une source pour les réplicas en lecture. Pour plus d'informations sur les sauvegardes automatisées, consultez le Guide de l'utilisateur Amazon RDS.

La fenêtre de sauvegarde préférée est la période de temps définie par l'utilisateur pendant laquelle votre instance DB est sauvegardée. Amazon RDS utilise ces sauvegardes de données périodiques avec vos journaux de transactions pour vous permettre de restaurer votre instance DB à n'importe quelle seconde pendant votre période de rétention, jusqu'au LatestRestorableTime (en général jusqu'aux cinq dernières minutes). Pendant la période de sauvegarde, les E/S de stockage peuvent être brièvement interrompues lors de l'initialisation du processus de sauvegarde (généralement pendant quelques secondes), et il est possible qu'une latence plus élevée se fasse brièvement ressentir. Les déploiements DB Multi-AZ ne subissent aucune période de suspension d'E/S, car la sauvegarde est réalisée à partir de l'instance de secours.

Les instantanés de base de données et sauvegardes automatiques Amazon RDS sont stockés dans S3.

Vous pouvez utiliser la Console de gestion AWS, l'API ModifyDBInstance ou la commande modify-db-instance pour gérer la période pendant laquelle vos sauvegardes automatisées sont conservées en modifiant le paramètre RetentionPeriod. Si vous souhaitez désactiver complètement les sauvegardes automatiques, vous pouvez définir la période de rétention sur 0 (bien que cette option ne soit pas recommandée). Vous pouvez gérer vos snapshots DB crées par l'utilisateur via la section « Snapshots » de la console Amazon RDS. Vous pouvez également consulter la liste des instantanés de base de données créés par l'utilisateur pour une instance de base de données particulière en utilisant l'API DescribeDBSnapshots ou la commande describe-db-snapshots et supprimer les instantanés avec l'API DeleteDBSnapshot ou la commande delete-db-snapshot.

Il est normal d'avoir 1 ou 2 snapshots de base de données automatisés supplémentaires par rapport au nombre de jours de votre période de rétention. Un snapshot automatique supplémentaire est conservé pour garantir la possibilité d'effectuer une restauration ponctuelle à tout moment pendant la période de rétention.

Par exemple, si votre fenêtre de sauvegarde est définie sur un jour, vous aurez besoin de deux snapshots automatisés pour prendre en charge les restaurations dans les 24 heures précédentes. Vous pouvez également voir un snapshot automatisé supplémentaire car un nouvel instantané automatisé est toujours créé avant la suppression de l'instantané automatisé le plus ancien.

Lorsque vous supprimez une instance DB, vous pouvez créer un instantané DB final au moment de la suppression ; de cette manière, vous pourrez utiliser cet instantané DB pour restaurer ultérieurement l'instance DB supprimée. Amazon RDS conserve cet instantané DB final créé par l'utilisateur avec les autres instantanés DB créés manuellement et ce, même après la suppression de l'instance DB. Consultez la page de tarification pour en savoir plus sur les coûts de stockage des sauvegardes.

Lorsque vous supprimez une instance de base de données, vous pouvez conserver les sauvegardes automatisées jusqu'à la période de rétention des sauvegardes. Pour plus d'informations, consultez la section Conservation des sauvegardes automatisées.

Amazon VPC vous permet de créer un environnement de réseau virtuel dans une section privée et isolée du Cloud AWS, où vous pouvez exercer un contrôle total sur les aspects tels que les plages d'adresses IP privées, les sous-réseaux, les tables de routage et les passerelles réseau. Avec Amazon VPC, vous pouvez définir une topologie de réseau virtuel et personnaliser la configuration réseau afin qu'elle ressemble étroitement à un réseau IP classique que vous pourriez exploiter dans votre propre centre de données.

Les avantages du VPC peuvent vous profiter lorsque vous souhaitez exécuter une application web destinée au grand public tout en conservant des serveurs backend non accessibles au public dans un sous-réseau privé. Vous pouvez créer un sous-réseau destiné au grand public pour vos serveurs web avec accès à Internet et placer vos instances de base de données Amazon RDS backend dans un sous-réseau privé sans accès Internet. Pour plus d'informations sur Amazon VPC, consultez le Guide de l'utilisateur du cloud privé virtuel Amazon.

Si vous avez créé votre compte AWS avant le 04/12/2013, il se peut que vous puissiez exécuter Amazon RDS dans un environnement Amazon Elastic Compute Cloud (EC2)-Classic. La fonctionnalité de base d'Amazon RDS est la même, que VPC EC2–Classic ou EC2 soit ou non utilisé. Amazon RDS gère les sauvegardes, l'application des correctifs logiciels, la détection automatique des pannes, les réplicas en lecture et la restauration, que vos instances de base de données soient déployées à l'intérieur ou à l'extérieur d'un VPC. Pour plus d'informations sur les différences entre EC2-Classic et EC2-VPC, consultez la documentation d'EC2.

Un groupe de sous-réseaux de base de données est un ensemble de sous-réseaux que vous pouvez désigner pour vos instances de base de données Amazon RDS dans un VPC. Chaque groupe de sous-réseaux de base de données doit posséder au minimum un sous-réseau pour chaque zone de disponibilité d'une région donnée. Lors de la création d'une instance de base de données dans VPC, vous devez sélectionner un groupe de sous-réseau de base de données. Amazon RDS utilise ensuite le groupe de sous-réseau de base de données et votre zone de disponibilité préférée pour sélectionner un sous-réseau et une adresse IP dans ce sous-réseau. Amazon RDS crée et associe une interface Elastic Network Interface à votre instance de base de données avec cette adresse IP.

Nous vous recommandons vivement d'utiliser le nom du DNS pour la connexion à votre instance de base de données, car l'adresse IP sous-jacente peut être modifiée (par exemple pendant un basculement).

Pour les déploiements Multi-AZ, la définition d'un sous-réseau pour toutes les zones de disponibilité d'une région permet à Amazon RDS de créer une instance de secours dans une autre zone de disponibilité en cas de besoin. Vous devez procéder de la sorte même pour les déploiements Single-AZ, au cas où vous souhaitiez les convertir en déploiements Multi-AZ par la suite.

Pour voir la procédure explicative de ce processus, consultez la section Création d'une instance DB dans un VPC du Guide de l'utilisateur Amazon RDS.

Consultez la section Groupes de sécurité du Guide de l'utilisateur Amazon RDS afin d'en savoir plus sur les différentes façons de contrôler l'accès à vos instances de base de données.

Les instances de base de données déployées dans un VPC sont accessibles par les instances EC2 déployées dans le même VPC. Si ces instances EC2 sont déployées dans un sous-réseau public avec des adresses IP Elastic associées, vous pouvez accéder aux instances EC2 sur Internet. Les instances de base de données déployées dans un VPC sont accessibles depuis Internet ou depuis les instances EC2 en dehors du VPC via un VPN ou des hôtes bastion que vous pouvez lancer dans votre sous-réseau public, ou encore en utilisant l'option d'accès public d'Amazon RDS :

• Pour utiliser un hôte bastion, vous devez configurer un sous-réseau public dans une instance EC2 faisant office de bastion SSH. Ce sous-réseau public doit disposer d'une passerelle Internet et de règles de routage autorisant l'acheminement du trafic via l'hôte SSH, qui doit à son tour transférer les requêtes vers l'adresse IP privée de votre instance de base de données Amazon RDS.
• Pour utiliser une connexion publique, il vous suffit de créer vos instances de base de données en activant l'option d'accès public. Lorsque l'option d'accès public est activée, vos instances DB se trouvant dans un VPC sont entièrement accessibles en dehors de votre VPC par défaut. Autrement dit, vous n'avez pas à configurer de VPN ou de bastion Internet pour pouvoir accéder à vos instances.

Vous pouvez également configurer une passerelle VPC en extension de votre réseau d'entreprise vers votre VPC et autoriser l'accès à l'instance de base de données Amazon RDS dans ce VPC. Pour en savoir plus, consultez le Guide de l'utilisateur Amazon VPC.

Nous vous recommandons vivement d'utiliser le nom DNS pour la connexion à votre instance de base de données, car l'adresse IP sous-jacente peut être modifiée (par exemple pendant un basculement).

Si votre instance DB n'est pas dans un VPC, vous pouvez utiliser la Console de gestion AWS pour déplacer facilement votre instance DB vers un VPC. Pour en savoir plus, consultez le Guide de l'utilisateur Amazon RDS. Vous pouvez également prendre un instantané de votre instance DB en dehors de VPC et le restaurer dans VPC en spécifiant le groupe de sous-réseaux DB que vous souhaitez utiliser. Vous pouvez également effectuer une opération Restore to Point in Time (Restaurer à un instant précis).

La migration des instances de base de données depuis un VPC interne vers un VPC externe n'est pas prise en charge. Pour des raisons de sécurité, un instantané DB d'une instance DB dans VPC ne peut pas être restauré en dehors de VPC. Il en va de même pour la fonctionnalité Restore to Point in Time (Restaurer à un instant précis). 

Vous êtes responsable de la modification des tables de routage et des ACL réseau dans votre VPC afin de vous assurer que votre instance de base de données peut être atteinte depuis vos instances clientes du VPC. Pour les déploiements Multi-AZ, après un basculement, il est possible que votre instance EC2 cliente et l'instance de base de données Amazon RDS se trouvent dans des zones de disponibilité différentes. Vous devez configurer vos ACL réseau afin de vous assurer que la communication entre zones de disponibilité est possible.

Un groupe de sous-réseaux de base de données existant peut être mis à jour afin d'ajouter des sous-réseaux supplémentaires, soit pour les zones de disponibilité existantes, soit pour les zones de disponibilité ajoutées depuis la création de l'instance DB. En retirant des sous-réseaux d'un groupe de sous-réseaux DB existant, vous risquez de rendre indisponibles les instances s'exécutant dans une zone de disponibilité supprimée du groupe de sous-réseaux. Pour en savoir plus, consultez le Guide de l'utilisateur Amazon RDS.

Pour commencer à utiliser Amazon RDS, vous avez besoin d'un compte de développeur AWS. Si vous n'en aviez pas avant de vous inscrire à Amazon RDS, vous serez invité à en créer un au début de la procédure d'inscription. Un compte d'utilisateur principal est différent d'un compte de développeur AWS, et il n'est utilisé que dans le contexte d'Amazon RDS pour contrôler l'accès à votre/vos instances de base de données. Le compte d'utilisateur principal est un compte d'utilisateur de base de données native que vous pouvez utiliser pour vous connecter à votre instance de base de données. 

Vous pouvez spécifier le nom de l'utilisateur principal et le mot de passe que vous voulez associer à chaque instance de base de données lorsque vous créez l'instance de base de données. Une fois que vous avez créé votre instance de base de données, vous pouvez vous connecter à la base de données en utilisant les informations d'identification de l'utilisateur principal. Par la suite, vous pourriez également vouloir créer des comptes d'utilisateur supplémentaires, afin de pouvoir limiter l'accès des personnes à votre instance DB.

Pour MySQL, les privilèges par défaut de l'utilisateur principal incluent : créer, abandonner, références, évènement, modifier, supprimer, indexer, insérer, sélectionner, mettre à jour, créer des tables temporaires, verrouiller des tables, déclencher, créer un affichage, afficher une vue, modifier une routine, créer une routine, exécuter, créer un utilisateur, traiter, afficher des bases de données, accorder une option.

Pour Oracle, l'utilisateur principal reçoit le rôle « dba ». L'utilisateur principal hérite de la plupart des privilèges associés au rôle. Reportez-vous au Guide de l'utilisateur Amazon RDS afin de consulter la liste des privilèges restreints et les alternatives correspondantes pour effectuer les tâches administratives pouvant nécessiter de tels privilèges.

Avec SQL Server, un utilisateur qui crée une base de données reçoit le rôle « db_owner ». Reportez-vous au Guide de l'utilisateur Amazon RDS afin de consulter la liste des privilèges restreints et les alternatives correspondantes pour effectuer les tâches administratives pouvant nécessiter de tels privilèges.

Non, tout fonctionne comme vous en avez l'habitude avec une base de données relationnelle que vous gérez par vous-même.

Oui. Vous devez explicitement activer l'accès à votre base de données via Internet en configurant des groupes de sécurité. Vous pouvez autoriser l'accès uniquement pour des adresses IP spécifiques, des plages d'adresses IP ou des sous-réseaux correspondant aux serveurs de votre propre centre de données.

Oui, cette option est prise en charge par tous les moteurs RDS Amazon. Amazon RDS génère un certificat SSL/TLS pour chaque instance de base de données. Une fois qu'une connexion chiffrée est établie, les données transférées entre l'instance DB et votre application seront chiffrées pendant le transfert.

Bien que SSL offre des avantages en termes de sécurité, il convient de souligner que le chiffrement SSL/TLS est une opération de calcul intensive, qui augmentera les temps de latence de la connexion de votre base de données. La prise en charge de SSL/TLS dans Amazon RDS est destinée au chiffrement de la connexion entre votre application et votre instance de base de données ; vous ne devez pas vous reposer sur elle pour authentifier l'instance de base de données.

Pour en savoir plus sur la mise en place d'une connexion chiffrée à Amazon RDS, consultez les Guides Amazon RDS ci-dessous : Guide de l'utilisateur MySQL, Guide de l'utilisateur MariaDB, Guide de l'utilisateur PostgreSQL ou Guide de l'utilisateur Oracle. Pour plus d'informations sur le fonctionnement de SSL/TLS avec ces différents moteurs, vous pouvez consulter directement la documentation MySQL, la documentation MariaDB, la documentation MSDN SQL Server, la documentation PostgreSQL ou la documentation Oracle.

Amazon RDS prend en charge le chiffrement au repos pour tous les moteurs de base de données, à l'aide des clés que vous gérez via AWS Key Management Service (KMS). Sur une instance de base de données s'exécutant avec le chiffrement Amazon RDS, les données au repos dans le stockage sous-jacent sont chiffrées, de même que les sauvegardes automatisées, les réplicas en lecture et les instantanés. Le chiffrement et le déchiffrement sont gérés de manière transparente. Pour plus d'informations concernant l'utilisation de KMS avec Amazon RDS, consultez le Guide de l'utilisateur Amazon RDS.

Il est également possible d'ajouter un chiffrement à une instance ou un cluster DB non chiffré en capturant un instantané de base de données, puis en créant une copie de cet instantané et en spécifiant une clé de chiffrement KMS. Vous pouvez ensuite restaurer une instance ou un cluster DB chiffré à partir de l'instantané chiffré.

Amazon RDS for Oracle et SQL Server prennent en charge les technologies de chiffrement transparent des données (TDE, Transparent Data Encryption) de ces moteurs. Pour plus d'informations, consultez les sections du Guide de l'utilisateur Amazon RDS consacrées à Oracle et à SQL Server.

Vous pouvez contrôler les actions que vos groupes et utilisateurs AWS IAM sont autorisés à effectuer sur les ressources Amazon RDS. Pour ce faire, vous devez référencer les ressources Amazon RDS en question dans les politiques AWS IAM appliquées à vos groupes et utilisateurs. Les ressources Amazon RDS pouvant être référencées dans une politique IAM d'AWS incluent les instances de bases de données, les instantanés de bases de données, les réplicas en lecture, les groupes de sécurité de bases de données, les groupes d'options de bases de données, les groupes de paramètres de bases de données, les abonnements à des événements et les groupes de sous-réseaux de bases de données. 

En outre, vous pouvez associer des identifications à ces ressources pour ajouter des métadonnées supplémentaires à ces dernières. Les mots-clés vous permettent de classer vos ressources (par exemple : Instances DB de « développement », de « production », de « test »...) et de créer des politiques AWS IAM répertoriant des autorisations (actions pouvant être effectuées) pour toutes les ressources comportant les mêmes mots-clés. Pour plus d'informations, consultez Balisage des ressources Amazon RDS.

Oui. AWS CloudTrail est un service Web qui enregistre les appels d'API AWS pour votre compte et vous les présente sous forme de fichier journal. L'historique des appels d'API AWS généré par CloudTrail permet de réaliser une analyse de sécurité, le suivi des modifications au niveau des ressources, ainsi que l'audit de conformité. 

Oui, tous les moteurs de base de données Amazon RDS sont éligibles HIPAA. Vous pouvez donc les utiliser pour créer des applications compatibles HIPAA et stocker des données de santé, notamment les informations médicales protégées (PHI), dans le cadre d'un accord d'association commerciale (BAA) signé avec AWS.

Si vous avez déjà un BAA exécuté, aucune action n'est nécessaire pour commencer à utiliser ces services dans le ou les comptes couverts par votre BAA. Si vous n'avez pas de BAA exécutée avec AWS ou si vous avez d'autres questions concernant les applications compatibles HIPAA sur AWS, contactez-nous.

Par défaut, Amazon RDS choisit les paramètres de configuration optimaux pour votre instance DB en prenant en compte la classe d'instance et la capacité de stockage. Cependant, si vous souhaitez les modifier, vous pouvez le faire en utilisant AWS Management Console, les API Amazon RDS ou l'interface de ligne de commande AWS. Veuillez noter que changer les paramètres de configuration à partir des valeurs recommandées peut avoir des effets inattendus, allant d'une performance dégradée aux plantages de système ; ce changement ne doit être effectué que par des utilisateurs avancés qui sont disposés à assumer ces risques.

Un groupe de paramètres de base de données (Groupe de paramètre DB) agit en tant que « conteneur » pour les valeurs de configuration de moteur qui peuvent être appliquées à une ou plusieurs instances DB. Si vous créez une instance DB sans spécifier un groupe de paramètre DB, un groupe de paramètre DB par défaut est utilisé. Ce groupe par défaut contient le moteur par défaut et le système Amazon RDS par défaut optimisés pour l'instance DB que vous exécutez.

Toutefois, si vous voulez que votre instance DB soit exécutée avec vos valeurs de configuration de moteur sur mesure, il vous suffit de créer un nouveau groupe de paramètres DB, modifier les paramètres souhaités et l'instance DB pour utiliser le nouveau groupe de paramètres DB. Une fois associées, toutes les instances DB qui utilisent un Parameter Group DB particulier peuvent obtenir toutes les mises à niveau de paramètre vers ce Parameter Group DB.

Pour plus d'informations sur la configuration des groupes de paramètres de base de données, veuillez lire le Guide de l'utilisateur Amazon RDS.

Vous pouvez utiliser AWS Config pour enregistrer en continu les changements de configuration apportés aux instances de bases de données Amazon RDS, aux groupes de sous-réseaux de bases de données, aux instantanés de bases de données, aux groupes de sécurité de bases de données et aux abonnements aux événements, et recevoir une notification de changement via Amazon Simple Notification Service (SNS). Vous pouvez également créer des règles AWS Config pour déterminer si ces ressources Amazon RDS présentent les configurations souhaitées.

Lorsque vous créez ou modifiez votre instance de base de données afin qu'elle soit exécutée en tant que déploiement multi-AZ, Amazon RDS met en service et maintient automatiquement un réplica « de secours » synchrone dans une zone de disponibilité différente. Les mises à jour vers votre instance DB sont répliquées de manière synchrone sur les zones de disponibilité vers l'instance de secours, afin qu'elles restent toutes deux synchronisées et qu'elles protègent vos dernières mises à jour de base de données contre une défaillance d'instance DB. 

Pendant certains types de maintenance planifiée ou dans le cas improbable d'une défaillance d'instance DB ou de zone de disponibilité, Amazon RDS basculera automatiquement vers l'instance de secours, afin que vous puissiez continuer les écritures et lectures vers la base de données dès que l'instance de secours est activée. Étant donné que l'enregistrement de nom pour votre instance de base de données reste le même, votre application peut reprendre les opérations de base de données sans qu'une intervention manuelle d'administration soit nécessaire. Dans le cas des déploiements multi-AZ, la réplication est transparente. Vous n'interagissez pas directement avec l'instance de secours, et elle ne prend pas en charge le trafic de lecture. Pour en savoir plus sur les déploiements multi-AZ, consultez le Guide de l'utilisateur Amazon RDS.

Les zones de disponibilité sont des emplacements distincts dans une région, conçues pour être isolées des défaillances dans d'autres zones de disponibilité. Chaque zone de disponibilité exécute sa propre infrastructure indépendante et physiquement distincte et est conçue pour être hautement fiable. Les points de défaillance uniques, tels que les générateurs et les équipements de refroidissement, ne sont pas partagés entre les zones de disponibilité. En outre, ils sont physiquement séparés. Ainsi même un sinistre extrêmement rare, comme un incendie, une tempête ou une inondation, n'affecterait qu'une seule zone de disponibilité. Les zones de disponibilité dans la même région bénéficient d'une connectivité de réseau avec une faible latence.

Lorsque vous exécutez une instance DB en tant que déploiement Multi-AZ, l'instance « principale » sert les écritures et lectures de base de données. En outre, Amazon RDS prévoit et maintient une instance de « secours » en arrière-plan, qui est un réplica à jour de l'instance principale. L'instance de secours est « promue » en cas de scénario de basculement. Après le basculement, l'instance secours devient l'instance principale et accepte vos opérations de base de données. Vous n'interagissez pas directement avec l'instance de secours (par ex. pour les opérations en lecture) à un moment quelconque avant la promotion. Si vous souhaitez mettre à l'échelle vos capacités de trafic en lecture au-delà des contraintes liées à une instance de base de données unique, consultez les questions fréquentes (FAQ) sur les réplicas en lecture.

Les avantages principaux de l'exécution de votre instance DB en tant que déploiement Multi-AZ sont une durabilité et une disponibilité de la base de données améliorées. La disponibilité améliorée et la tolérance de panne offertes par les déploiements Multi-AZ en font le choix naturel pour les environnements de production.
 

En exécutant votre instance DB sous forme de déploiement Multi-AZ, vos données sont protégées dans le cas, peu probable, d'une défaillance d'un composant d'une instance DB ou d'une perte de disponibilité dans une zone de disponibilité. Par exemple, si un volume de stockage sur l'instance principale connaît une défaillance, Amazon RDS déclenche automatiquement un basculement vers l'instance de secours, où toutes vos mises à jour de base de données sont intactes. Ceci fournit une durabilité des données supplémentaire relativement aux déploiements standards dans une seule AZ, où une opération de restauration lancée par un utilisateur serait requise et les mises à jour qui ont eu lieu après le dernier moment restaurable (en général dans les cinq dernières minutes) ne seraient pas disponibles.

Vous profitez également d'une disponibilité de base de données améliorée lorsque votre instance DB est exécutée en tant que déploiement Multi-AZ. Si une défaillance de zone de disponibilité ou d'instance DB se produit, l'impact sur votre disponibilité est limité à la durée de mise en place du basculement. Les avantages de la disponibilité Multi-AZ s'étendent également jusqu'à la maintenance planifiée.

Par exemple, avec les sauvegardes automatisées, l'activité I/O n'est plus suspendue sur votre instance principale pendant votre fenêtre de sauvegarde préférée, car les sauvegardes sont effectuées depuis l'instance de secours. Dans le cas d'une application de correctifs ou d'une mise à l'échelle de classe d'instance de base de données, ces opérations ont lieu tout d'abord sur l'instance de secours, avant le basculement automatique. En conséquence, l'impact sur votre disponibilité est limité à la durée de mise en place du basculement.

Un autre avantage implicite d'exécuter votre instance DB en tant que déploiement Multi-AZ est le fait que le basculement d'instance DB est automatique et ne nécessite pas d'administration. Dans un contexte Amazon RDS, ceci signifie que vous n'avez pas besoin de surveiller les événements d'instance DB et de lancer une récupération d'instance DB manuelle (via les API RestoreDBInstanceToPointInTime ou RestoreDBInstanceFromSnapshot) en cas de défaillance de zone de disponibilité ou d'instance DB.

Vous pouvez observer des temps de latence élevés par rapport à un déploiement d'instance DB standard dans une seule zone de disponibilité, du fait de la réplication synchrone des données qui est réalisée.

Non, l'instance de secours ne peut pas servir les demandes de lecture. Les déploiements multi-AZ sont conçus pour fournir une disponibilité et durabilité de base de données améliorées, plutôt que des avantages de dimensionnement en lecture. À ce titre, la fonction utilise la réplication synchrone entre les instances principales et de secours. Notre implémentation veille à ce que les instances principales et de secours soient constamment synchronisés, mais exclut l'utilisation de l'instance de secours pour les opérations en lecture ou écriture. Si une solution de dimensionnement en lecture vous intéresse, consultez les questions fréquentes (FAQ) sur les réplicas en lecture.

Afin de créer un déploiement d'instance de base de données multi-AZ, il suffit de cliquer sur l'option « Oui » pour un « déploiement multi-AZ » lors du lancement d'une instance de base de données avec la console de gestion AWS.

De manière alternative, si vous utilisez les API Amazon RDS, vous appelez l'API CreateDBInstance et définissez le paramètre « Multi-AZ » sur la valeur « true ». Pour convertir une instance de base de données standard existante (Mono-AZ) en Multi-AZ, modifiez l'instance de base de données dans la console de gestion AWS ou utilisez l'API ModifyDBInstance et définissez le paramètre Multi-AZ sur « true ».

Pour les moteurs de base de données RDS for PostgreSQL, RDS for MySQL, RDS for MariaDB, RDS for SQL Server, RDS for Oracle, et RDS for Db2, lorsque vous décidez de convertir votre instance Amazon RDS de mono-AZ en instance multi-AZ, voici ce qui se passe :

• Création d'un instantané de votre instance principale.
• Une nouvelle instance de secours est créée dans une autre zone de disponibilité (AZ) à partir de l'instantané.
• Une réplication synchronisée est configurée entre l'instance principale et l'instance de secours.

Ainsi, la conversion d'une instance du Mono-AZ vers le Multi-AZ ne devrait pas provoquer de perturbations. Vous pouvez toutefois constater une latence accrue tandis que les données en attente sont interceptées pour la correspondance avec le serveur principal.

Pour les déploiements multi-AZ, Amazon RDS assure une détection et une récupération automatique dans la plupart des scénarios de défaillance courants afin que vous puissiez reprendre les opérations de base de données aussi rapidement que possible et sans intervention d'un administrateur. Amazon RDS procède automatiquement au basculement dès lors qu'un des événements suivants se produit :

• Perte de disponibilité dans la zone de disponibilité principale
• Perte de connectivité réseau avec le serveur principal
• Échec d'unité de calcul sur le serveur principal
• Échec de stockage sur le serveur principal

Remarque : pour une meilleure disponibilité, lorsque des opérations telles que la mise à l'échelle d'une instance de base de données ou la réalisation de mises à niveau système (application de correctifs sur le système d'exploitation, par exemple) sont lancées pour des déploiements multi-AZ, elles sont d'abord appliquées au niveau de l'instance de secours avant tout basculement automatique. En conséquence, l'impact sur votre disponibilité est uniquement limité à la durée de mise en place du basculement. Notez que les déploiements multi-AZ d'Amazon RDS ne basculent pas automatiquement en cas d'opérations de bases de données, telles que les requêtes à exécution prolongée, les verrous bloquants ou les erreurs de corruption de la base de données.

Oui, Amazon RDS émettra un événement d'instance DB vous informant qu'un basculement automatique a eu lieu. Vous pouvez cliquer sur la section « Events » d'Amazon RDS Console ou utiliser l'API DescribeEvents pour renvoyer des informations sur des événements liés à votre instance DB. Vous pouvez également utiliser la notification d'événement Amazon RDS pour être informé quand des événements de base de données particuliers se produisent.

Le basculement est automatiquement traité par Amazon RDS afin que vous puissiez reprendre vos opérations de base de données aussi vite que possible sans intervention administrative. Lors du basculement, Amazon RDS retourne simplement l'enregistrement de nom canonique (CNAME) de votre instance DB pour pointer vers l'instance de secours, qui est promue à son tour pour devenir la nouvelle instance principale. Nous vous encourageons à suivre les bonnes pratiques et à implémenter une nouvelle tentative de connexion de base de données au niveau de la couche d'application.

Les basculements, tels que définis par l'intervalle entre la détection de la défaillance dans l'instance primaire et la reprise des transactions dans l'instance de secours, s'effectuent généralement en une ou deux minutes. La durée du basculement peut également être affectée par la nécessité de restaurer de grandes transactions non validées. Il est recommandé d'utiliser des types d'instances au volume approprié avec multi-AZ pour obtenir les meilleurs résultats. AWS recommande également d'utiliser les volumes IOPS dimensionnés avec les instances multi-AZ pour obtenir des performances de débit rapides, prévisibles et homogènes.

Amazon RDS procède au basculement automatique, sans aucune intervention de l'utilisateur, dans diverses conditions de pannes. En outre, Amazon RDS offre une option permettant de lancer un basculement lors du redémarrage de votre instance. Vous pouvez accéder à cette fonctionnalité via AWS Management Console ou en appelant l'API RebootDBInstance.

Avec les déploiements Multi-AZ, vous définissez simplement le paramètre « Multi-AZ » sur vrai. La création de l'instance de secours, de la réplication synchrone et du basculement est traitée automatiquement. Ceci signifie que vous ne pouvez pas sélectionner la zone de disponibilité lorsque votre instance de secours est déployée ou modifier le nombre d'instances de secours disponibles (Amazon RDS met en service une instance de secours dédiée par instance DB principale). Par ailleurs, le réplica de secours ne peut pas être configuré pour accepter des activités en lecture de base de données. En savoir plus sur les configurations multi-AZ.

Oui. Votre instance de secours est mise automatiquement en service dans une zone de disponibilité différente de la même région comme votre instance DB principale.

Oui, vous pouvez avoir accès à l'emplacement de l'instance principale actuelle en utilisant la console de gestion AWS ou l'API DescribeDBInstances.

Les zones de disponibilité sont conçues pour fournir une connectivité réseau à faible latence vers les autres zones de disponibilité de la même région. En outre, vous pourriez envisager d'avoir une architecture avec redondance pour votre application et d'autres ressources AWS parmi des zones de disponibilité multiples, afin que votre application soit résiliente en cas de défaillance d'une zone de disponibilité. Les déploiements Multi-AZ répondent à ce besoin pour le niveau de base de données sans administration de votre part.

Vous interagissez avec la fonctionnalité de sauvegarde automatisée et les instantanés DB de la même manière, que vous exécutiez un déploiement standard mono-AZ ou un déploiement multi-AZ. Si vous exécutez un déploiement Multi-AZ, les sauvegardes automatisées et les instantanés DB sont simplement pris à partir de l'instance de secours, afin d'éviter la suspension d'E/S sur l'instance principale. Notez qu'il est possible de constater un temps de latence accru en E/S (généralement quelques minutes) lors des sauvegardes, à la fois pour les déploiements mono-AZ et multi-AZ.

Dans les déploiements multi-AZ, les opérations de restauration (restauration à un moment donné ou restauration à partir d'un instantané DB) fonctionnent de la même manière que dans les déploiements mono-AZ standard. Les nouveaux déploiements d'instance DB peuvent être créés avec l'API RestoreDBInstanceFromSnapshot ou RestoreDBInstanceToPointInTime. Ces nouveaux déploiements d'instance DB peuvent être standards ou multi-AZ, que la sauvegarde source ait été lancée sur un déploiement standard ou multi-AZ.

Les réplicas en lecture exploitent la fonctionnalité de réplication intégrée des moteurs pris en charge afin de monter en puissance de manière extensible au-delà des contraintes de capacités d'une seule instance de base de données pour les charges de travail de base de données à lecture importante.

Vous pouvez créer un réplica en lecture en quelques clics sur la console de gestion AWS ou en utilisant l'API CreateDBInstanceReadReplica. Une fois que le réplica en lecture est créé, les mises à jour de base de données sur l'instance DB source seront répliquées en utilisant la réplication native et asynchrone du moteur pris en charge. Vous pouvez créer plusieurs réplicas en lecture (read replica) pour une instance DB source donnée et répartir le trafic en lecture de l'application entre eux.

Étant donné que les réplicas en lecture utilisent la réplication intégrée des moteurs pris en charge, ils exploitent ses avantages et sont soumis à ses limitations. En particulier, les mises à jour sont appliquées à votre ou vos réplicas en lecture après qu'elles ont eu lieu sur l'instance de base de données source et le retard de réplication peut varier de manière importante. Les réplicas en lecture peuvent être associés à des déploiements multi-AZ pour bénéficier d'avantages de dimensionnement en lecture en plus de l'amélioration de la disponibilité en écriture de la base de données et de la durabilité des données fournies par les déploiements Multi-AZ.

Il existe divers scénarios où le déploiement d'un ou plusieurs réplicas en lecture pour une instance DB source donnée est recommandé. Les principales raisons d'un déploiement de réplica en lecture sont les suivantes :

• Dimensionnement au-delà de la capacité de calcul ou d'E/S d'une instance de bases de données individuelle pour des charges de travail de base de données à lecture intensive. Ce trafic en lecture excessif peut alors être dirigé vers un ou plusieurs réplicas en lecture.
• Service du trafic en lecture alors que l'instance de bases de données source est indisponible. Si votre instance DB source ne peut pas prendre en charge les demandes E/S (par ex. en raison de la suspension d'E/S pour les sauvegardes ou la maintenance planifiée), vous pouvez diriger le trafic en lecture vers votre/vos réplicas en lecture. Pour ce cas d'utilisation, gardez à l'esprit que les données sur le réplica en lecture peuvent être « obsolètes », étant donné que l'instance de base de données source est indisponible.
• Scénarios de rapports d'entreprise ou d'entreposage de données. Vous pourriez souhaiter que les requêtes de rapports commerciaux soient exécutées sur un réplica en lecture, plutôt que sur votre instance de base de données principale de production.
• Vous pouvez utiliser un réplica en lecture pour la reprise après sinistre de l'instance de base de données source, dans la même région AWS ou dans une région différente.

Oui. Activez les sauvegardes automatiques sur votre instance de base de données source avant d'ajouter des réplicas en lecture, en définissant la période de rétention des sauvegardes sur une valeur autre que 0. Les sauvegardes doivent rester activées pour que les réplicas en lecture fonctionnent.

Amazon Aurora : tous les clusters de base de données.

Amazon RDS for MySQL : toutes les instances de base de données prennent en charge la création de réplicas en lecture. Les sauvegardes automatiques doivent rester activées sur l'instance de base de données source pour les opérations de réplicas en lecture. Les sauvegardes automatiques sont prises en charge uniquement pour les réplicas en lecture Amazon RDS exécutant MySQL 5.6 et plus, et non la version 5.5.

Amazon RDS for PostgreSQL : les instances DB dotées de PostgreSQL 9.3.5 ou version ultérieure prennent en charge la création de réplicas en lecture. Les instances PostgreSQL existantes dotées d'une version antérieure à 9.3.5 doivent être mises à niveau vers la version 9.3.5 de PostgreSQL pour exploiter les réplicas en lecture Amazon RDS.

Amazon RDS for MariaDB : toutes les instances de base de données prennent en charge la création de réplicas en lecture. Les sauvegardes automatiques doivent rester activées sur l'instance de base de données source pour les opérations de réplicas en lecture.

Amazon RDS for Oracle : pris en charge par la version 12.1.0.2.v12 d'Oracle et les versions ultérieures, ainsi que toutes les versions 12.2 qui utilisent le modèle BYOL (Licence à fournir) avec Oracle Database Enterprise Edition et disposent de l'option Active Data Guard.

Amazon RDS for SQL Server : les réplicas en lecture sont pris en charge sur Enterprise Edition dans la configuration multi-AZ lorsque la technologie de réplication sous-jacente utilise les versions 2016 et 2017 des groupes de disponibilité Always On pour SQL Server.

Vous pouvez créer un réplica en lecture en quelques minutes au moyen de l'API CreateDBInstanceReadReplica standard ou en quelques étapes dans la console de gestion AWS. Lorsque vous créez un réplica en lecture, vous pouvez l'identifier en tant que tel en spécifiant un identifiant SourceDBInstanceIdentifier. SourceDBInstanceIdentifier est l'identifiant d'instance DB de l'instance DB « source » à partir de laquelle vous souhaitez effectuer le réplica. Comme pour l'instance DB standard, vous pouvez également spécifier la zone de disponibilité, la classe d'instance DB et la fenêtre de maintenance préférée. La version du moteur (par ex. PostgreSQL 9.3.5) et l'attribution de stockage d'un réplica en lecture sont héritées de l'instance DB source. 

Lorsque vous lancez la création d'un réplica en lecture, Amazon RDS prend un instantané de votre instance DB source et commence la réplication. En conséquence, vous rencontrerez une brève interruption d'I/O sur votre instance de base de données source au moment où l'instantané a lieu. L'interruption d'I/O dure généralement environ une minute, et est évitée si l'instance de base de données source est un déploiement Multi-AZ (dans le cas des déploiements Multi-AZ, les instantanés sont pris depuis l'instance de secours).

Amazon RDS travaille aussi actuellement sur une optimisation (disponible prochainement), de sorte que si vous créez plusieurs réplicas en lecture dans une fenêtre de 30 minutes, tous utiliseront le même instantané source, afin de minimiser l'impact E/S (une réplication de « rattrapage » pour chaque réplica en lecture démarrera après la création).

Vous pouvez vous connecter à un réplica en lecture de la même manière qu'à une instance de base données standard, en utilisant l'API DescribeDBInstance ou AWS Management Console pour récupérer votre/vos points de terminaison vers votre/vos réplicas en lecture. Si vous avez plusieurs réplicas en lecture, c'est votre application qui détermine comment le trafic en lecture sera distribué entre eux.

Amazon RDS for MySQL, MariaDB et PostgreSQL vous permettent de créer jusqu'à 15 réplicas en lecture pour une même instance de base de données source. Amazon RDS for Oracle et SQL Server vous permettent de créer jusqu'à 5 réplicas en lecture pour une même instance de base de données source.

Oui, Amazon RDS (à l'exception de RDS for SQL Server) prend en charge les réplicas en lecture entre régions. La durée entre l'écriture des données dans l'instance DB source et leur disponibilité dans le réplica en lecture dépend de la latence du réseau entre les deux régions.

Non. Les réplicas en lecture dans Amazon RDS for MySQL, MariaDB, PostgreSQL, Oracle et SQL Server sont créés à l'aide de la réplication asynchrone native de ces moteurs. Amazon Aurora utilise un autre mécanisme de réplication asynchrone.

Si vous cherchez à utiliser la réplication pour augmenter la disponibilité en écriture de la base de données et protéger les mises à jour de base de données récentes contre diverses possibilités de défaillance, nous vous recommandons d'exécuter votre instance DB en tant que déploiement Multi-AZ. Avec les réplicas en lecture Amazon RDS, qui ont recours à la réplication asynchrone native des moteurs pris en charge, les écritures de base de données se produisent sur un réplica en lecture après qu'elles se sont déjà produites sur l'instance DB source, et ce « retard » de réplication peut considérablement varier. 

Au contraire, la réplication utilisée par les déploiements Multi-AZ est synchrone, ce qui signifie que toutes les écritures de base de données sont simultanées sur les instances principales et de secours. Ceci protège vos dernières mises à jour de base de données, car elles doivent être disponibles sur l'instance de secours au cas où un basculement serait nécessaire. 

En outre, avec les déploiements Multi-AZ, la réplication est totalement gérée. Amazon RDS détecte automatiquement les dysfonctionnements des instances de base de données et des zones de disponibilité et exécute un basculement automatique vers l'instance de secours (ou, pour Amazon Aurora, vers un réplica en lecture) en cas de panne.

Oui. Comme les instances DB Multi-AZ répondent à un besoin différent de celui des réplicas en lecture, il est logique d'utiliser les deux conjointement pour les déploiements de production et d'associer un réplica en lecture avec un déploiement d'instance DB Multi-AZ. L'instance DB Multi AZ « source » fournit une disponibilité en écriture et une durabilité des données améliorées et le réplica en lecture associé améliore le dimensionnement du trafic en lecture.

Oui. Amazon RDS for MySQL, MariaDB, PostgreSQL et Oracle permettent d'activer la configuration multi-AZ sur les réplicas en lecture pour prendre en charge la reprise après sinistre et réduire les temps d'arrêt lors des mises à niveau de moteur.

En cas de basculement Multi-AZ, tout réplica en lecture associé et disponible doit reprendre la réplication automatique une fois le basculement terminé (acquisition des mises à jour depuis l'instance qui vient de devenir principale).

Amazon Aurora, Amazon RDS for MySQL et MariaDB : vous pouvez créer trois niveaux de réplicas en lecture. Un réplica en lecture de deuxième niveau à partir d'un réplica en lecture de premier niveau existant et un réplica de troisième niveau à partir de réplicas en lecture de deuxième niveau. En créant un réplica en lecture de deuxième et troisième niveau, vous pouvez déplacer une partie de la charge de réplication de l'instance de base de données primaire vers différents niveaux de réplica en lecture en fonction des besoins de votre application.

Il est possible que le réplica en lecture de second niveau présente un délai d'actualisation plus long par rapport à l'instance principale, car cette réplication implique un temps de latence supplémentaire dans la mesure où les transactions sont d'abord répliquées de l'instance principale vers le réplica de premier niveau, puis de celui-ci vers le réplica de second niveau. De même, le réplica de troisième niveau peut être en retard sur le réplica en lecture de deuxième niveau.

Amazon RDS for Oracle et Amazon RDS for SQL Server : les réplicas en lecture créés à partir de réplicas en lecture ne sont pas actuellement pris en charge.

Les réplicas en lecture sont conçus pour servir le trafic en lecture. Toutefois, il peut y avoir des cas d'utilisation où les utilisateurs avancés souhaitent remplir des instructions SQL DDL (Data Definition Language) sur un réplica en lecture. Les exemples peuvent inclure l'ajout d'un index de base de données à un réplica en lecture utilisé pour les rapports commerciaux, sans l'ajout du même index à l'instance de base de données source correspondante.

Amazon RDS for MySQL peut être configuré de sorte à permettre les instructions SQL DDL sur un réplica en lecture. Si vous souhaitez activer des opérations autres que celles en lecture pour un réplica en lecture donné, vous devez modifier le groupe de paramètres de base de données actif pour le réplica en lecture, en définissant le paramètre « read_only » sur « 0 ».

Pour le moment, Amazon RDS for PostgreSQL ne prend pas en charge l'exécution d'instructions SQL DDL sur un réplica en lecture.

Oui. Pour en savoir plus, consultez le Guide de l'utilisateur Amazon RDS.

Les mises à jour vers une instance DB source seront immédiatement répliquées vers tous les réplicas en lecture associés. Toutefois, avec la technologie de réplication asynchrone des moteurs pris en charge, un réplica en lecture peut prendre du retard par rapport à son instance DB source pour diverses raisons. Les raisons typiques incluent :

• Le volume d'écriture E/S vers l'instance DB source dépasse la vitesse à laquelle les modifications peuvent être appliquées au réplica en lecture (ce problème est particulièrement susceptible de se présenter si la capacité d'un réplica en lecture est inférieure à l'instance DB source)
• Les transactions complexes ou longues vers l'instance DB source retardent la réplication vers le réplica en lecture
• Des partitions ou de la latence réseau entre l'instance DB source et un réplica en lecture

Les réplicas en lecture sont sujets aux forces et aux faiblesses de la réplication native des moteurs pris en charge. Si vous utilisez des réplicas en lecture, vous devez connaître le potentiel d'un décalage entre un réplica en lecture et son instance de base de données source ou « incohérence ».

Vous pouvez utiliser l'API DescribeDBInstances standard pour renvoyer une liste de toutes les instances de base de données que vous avez déployées (notamment les réplicas en lecture), ou cliquez simplement sur l'onglet « Instances » de la console Amazon RDS.

Amazon RDS vous permet de voir à quel point un réplica en lecture a pris du retard par rapport à son instance de base de données source. Le nombre de secondes de retard du réplica en lecture par rapport à l'instance principale est publié sous la forme d'une métrique Amazon CloudWatch (« Replica Lag », Retard de réplica) accessible via la console de gestion AWS ou les API Amazon CloudWatch.

Pour Amazon RDS for MySQL, la source de cette information est identique à celle affichée en émettant une commande MySQL « Show Replica Status » (Afficher le statut du réplica) standard pour le réplica en lecture. Pour Amazon RDS for PostgreSQL, vous pouvez utiliser l'affichage pg_stat_replication sur l'instance de base de données source pour découvrir les métriques de réplication.

Amazon RDS surveille le statut de réplication de vos réplicas en lecture et met à jour le champ Replication State (Statut de la réplication) sur Error (Erreur) dans la console de gestion AWS si la réplication est interrompue pour une raison quelconque (par exemple, l'exécution sur votre réplica de requêtes DML incompatibles avec les mises à jour effectuées sur l'instance de base de données primaire peut occasionner une erreur de réplication). Vous pouvez consulter les détails de l'erreur en question, signalée par le moteur MySQL, dans le champ « Replication Error » (Erreur de réplication), et ainsi effectuer l'action de récupération appropriée. Pour en savoir plus sur le dépannage des problèmes de réplication, consultez la section Dépannage d'un problème lié aux réplicas en lecture du Guide de l'utilisateur Amazon RDS for MySQL ou PostgreSQL. 

Lorsqu'une erreur de réplication est résolue, le champ Replication State présente la valeur Replicating.

Pour que la réplication fonctionne efficacement, nous recommandons que les réplicas en lecture disposent d'autant ou de plus de ressources de calcul et de stockage que leurs instances DB sources respectives. Autrement, il est probable que le retard de réplication augmentera ou que votre réplica en lecture pourrait ne plus avoir d'espace pour stocker les mises à jour répliquées.

Vous pouvez supprimer un réplica en lecture en quelques étapes dans la console de gestion AWS ou en passant son identifiant d'instance de base de données vers l'API DeleteDBInstance. 

Un réplica en lecture Amazon Aurora reste actif et continue d'accepter le trafic en lecture, même après la suppression de l'instance de base de données source correspondante. Un des réplicas dans le cluster est automatiquement promu comme la nouvelle instance principale et commence à accepter le trafic en écriture.

Un réplica en lecture Amazon RDS for MySQL ou MariaDB reste actif et continue d'accepter le trafic en lecture même après que son instance de base de données source correspondante a été supprimée. Si vous souhaitez supprimer le réplica en lecture en plus de l'instance DB source, vous devez le faire explicitement au moyen de l'API DeleteDBInstance ou d'AWS Management Console.

Si vous supprimez une instance DB Amazon RDS pour PostgreSQL qui dispose de réplicas en lecture, tous les réplicas en lecture seront promus vers les instances DB autonomes et seront en mesure d'accepter le trafic en lecture et celui en écriture. Les instances DB nouvellement promues fonctionneront indépendamment les unes des autres. Si vous souhaitez supprimer ces instances DB en plus de l'instance DB source, vous devez le faire explicitement au moyen de l'API DeleteDBInstance ou d'AWS Management Console.

Un réplica en lecture est facturé comme une instance DB standard et aux mêmes tarifs. Comme pour une instance DB standard, le tarif par « heure d'instance DB » pour un réplica en lecture est déterminé par la classe d'instance DB du réplica en lecture. Consultez la page de tarification pour connaître les tarifs les plus récents. Les frais de transfert de données lors de la réplication des données entre votre instance DB source et le réplica en lecture dans la même région AWS.

La facturation du réplica débute dès sa création, c'est-à-dire lorsque le statut indiqué est « active » (actif). Le réplica en lecture continuera d'être facturé aux tarifs horaires d'instance de base de données standard d'Amazon RDS jusqu'à ce que vous émettiez une commande pour le supprimer.

La surveillance améliorée pour Amazon RDS vous permet de suivre plus précisément l'état de vos instances Amazon RDS. Pour en profiter, activez l'option « Surveillance améliorée » pour votre instance de base de données Amazon RDS et indiquez une granularité. La fonction de surveillance améliorée se charge alors de collecter les métriques de système d'exploitation et les informations de processus essentielles, à la granularité définie.

Pour un niveau de diagnostic et de visualisation encore plus approfondi de la charge de votre base de données et une période de conservation des données plus longues, vous pouvez essayer la fonction Analyse des performances.

La fonction de surveillance améliorée collecte les métriques au niveau du système de votre instance Amazon RDS, comme le CPU, la mémoire, le système de fichiers et les I/O de disque, et plus encore. La liste complète des métriques est disponible dans la documentation.

La fonction de surveillance améliorée prend en charge tous les moteurs de base de données Amazon RDS.

La fonction de surveillance améliorée prend en charge tous les types d'instances, sauf t1.micro et m1.small. Ce logiciel utilise peu de ressources CPU, mémoire et I/O. Pour les applications de surveillance polyvalentes, nous conseillons d'utiliser des granularités élevées pour les instances de taille moyenne ou supérieure. Pour les instances de base de données hors production, la fonction de surveillance améliorée est désactivée par défaut, et vous avez la possibilité de la laisser dans cet état ou d'en modifier la granularité lorsqu'elle est activée.

Vous pouvez afficher toutes les métriques système et informations de processus de vos instances de base de données Amazon RDS sous forme graphique sur la console. Il est possible de gérer les métriques à surveiller pour chaque instance et de personnaliser le tableau de bord en fonction des besoins.

Non. Vous pouvez configurer différentes granularités pour chaque instance de base de données dans votre compte Amazon RDS. Vous pouvez également choisir les instances pour lesquelles vous désirez activer Enhanced Monitoring, et modifier la granularité de n'importe quelle instance à tout moment.

Vous pouvez afficher les valeurs de performances de toutes les métriques jusqu'à 1 heure dans le passé, avec une granularité pouvant atteindre 1 seconde, en fonction de vos paramètres.

Les métriques générées par la fonction de surveillance améliorée d'Amazon RDS sont envoyées à votre compte CloudWatch Logs. Vous pouvez créer des filtres de métriques dans CloudWatch à partir de CloudWatch Logs et afficher les graphiques sur le tableau de bord CloudWatch. Pour plus d'informations, consultez la page Amazon CloudWatch.

Il est conseillé d'utiliser CloudWatch si vous désirez consulter un historique de données plus étendu que ce que propose le tableau de bord de la console Amazon RDS. Vous pouvez surveiller vos instances Amazon RDS dans CloudWatch pour vérifier l'état de votre pile AWS tout entière depuis le même endroit. A l'heure actuelle, CloudWatch prend en charge des granularités pouvant atteindre 1 minute, et la moyenne des valeurs sera affichée pour les granularités inférieures.

Oui. Vous pouvez créer une alarme dans CloudWatch de sorte à envoyer une notification quand ladite alarme change d'état. Cette alarme surveille une métrique unique pendant une période que vous définissez, et réalise une ou plusieurs actions selon la valeur de la métrique par rapport au seuil défini sur différentes périodes. Pour plus d'informations sur les alarmes CloudWatch, veuillez consulter le Guide du développeur Amazon CloudWatch.

La fonction de surveillance améliorée d'Amazon RDS fournit un ensemble de métriques sous la forme de charges utiles JSON qui sont envoyées à votre compte CloudWatch Logs. Les charges utiles JSON sont envoyées à la granularité la plus récente définie pour l'instance Amazon RDS.

Vous pouvez consulter les métriques de deux façons : à l'aide d'une application ou d'un tableau de bord tiers. Les outils de surveillance peuvent utiliser un abonnement à CloudWatch Logs pour configurer un flux de métriques en quasi-temps réel. Vous pouvez aussi utiliser des filtres dans CloudWatch Logs pour transférer les métriques à CloudWatch et intégrer votre application à CloudWatch. Consultez la page Documentation Amazon CloudWatch pour en savoir plus.

Etant donné qu'Enhanced Monitoring envoie des unités de charge JSON à un journal dans votre compte CloudWatch Logs, vous pouvez en contrôler la période de rétention comme n'importe quel autre flux CloudWatch Logs. La période de rétention par défaut d'Enhanced Monitoring dans CloudWatch Logs est de 30 jours. Pour apprendre à modifier les paramètres de rétention, consultez le Guide du développeur Amazon CloudWatch.

Puisque les métriques sont envoyées à CloudWatch Logs, vos frais seront basés sur les tarifs de stockage et de transfert de données de CloudWatch Logs une fois l'offre gratuite dépassée. Pour connaître les informations de tarification, cliquez ici. La quantité d'informations transférée pour une instance Amazon RDS est directement proportionnelle à la granularité définie pour la fonction de surveillance améliorée. Les administrateurs peuvent configurer différentes granularités pour chaque instance de leur compte pour limiter les frais.

Le volume approximatif de données envoyées à CloudWatch Logs par Enhanced Monitoring pour une instance donnée est indiqué ci-dessous :

Proxy Amazon RDS est une fonctionnalité de proxy de base de données entièrement gérée et hautement disponible pour Amazon RDS. RDS Proxy rend les applications plus évolutives, plus résistantes aux défaillances des bases de données et plus sécurisées.

Le Proxy Amazon RDS est une fonction de proxy de base de données entièrement gérée, hautement disponible et facile à utiliser d'Amazon RDS. Elle vous permet d'améliorer les points suivants de vos applications : 1) leur capacité de mise à l'échelle, en regroupant et en partageant les connexions de base de données ; 2) leur disponibilité, en réduisant jusqu'à 66 % les temps de basculement de la base de données et en préservant les connexions d'application pendant les basculements ; et 3) leur sécurité, en appliquant éventuellement l'authentification IAM AWS aux bases de données et en stockant en toute sécurité les informations d'identification sur AWS Secrets Manager.

En fonction de votre charge de travail, Amazon RDS Proxy peut ajouter en moyenne 5 millisecondes de latence réseau au temps de réponse des requêtes ou des transactions. Si votre application ne peut pas tolérer 5 millisecondes de latence ou n'a pas besoin de gestion de connexion et d'autres fonctionnalités disponibles grâce à RDS Proxy, il est préférable de vous connecter directement au point de terminaison de la base de données.

Avec le Proxy Amazon RDS, vous avez des applications sans serveur modernes qui exploitent la puissance et la simplicité des bases de données relationnelles. Premièrement, Proxy Amazon RDS permet aux applications sans serveur de se développer efficacement en regroupant et en réutilisant les connexions de base de données. Ensuite, grâce à Amazon RDS Proxy, vous n'avez plus besoin de gérer les informations d'identification de la base de données dans votre code Lambda. Vous pouvez utiliser le rôle d'exécution IAM associé à votre fonction Lambda pour vous authentifier auprès de RDS Proxy et de votre base de données. Enfin, vous n'avez pas besoin de gérer une nouvelle infrastructure ou un nouveau code pour exploiter le plein potentiel des applications sans serveur soutenues par des bases de données relationnelles. RDS Proxy est entièrement géré et sa capacité évolue automatiquement en fonction des demandes de votre application.

Le proxy RDS est disponible pour Amazon Aurora avec la compatibilité MySQL, Amazon Aurora avec la compatibilité PostgreSQL, Amazon RDS for MariaDB, Amazon RDS for MySQL, Amazon RDS for PostgreSQL et Amazon RDS for SQL Server. Pour obtenir une liste des versions du moteur prises en charge, consultez le Guide de l'utilisateur Amazon Aurora ou le Guide de l'utilisateur Amazon RDS.

Vous pouvez activer Amazon RDS Proxy pour votre base de données Amazon RDS en quelques clics dans la console Amazon RDS. Lors de l'activation de RDS Proxy, vous pouvez spécifier le VPC et les sous-réseaux à partir desquels vous souhaitez accéder à RDS Proxy. En tant qu'utilisateur Lambda, vous pouvez activer Proxy Amazon RDS pour votre base de données Amazon RDS et configurer une fonction Lambda pour accéder à Proxy Amazon RDS en quelques clics depuis la console Lambda.

Oui. Vous pouvez utiliser les API Amazon RDS Proxy pour créer un proxy, puis définir des groupes cibles afin d'associer le proxy à des instances ou des clusters de base de données spécifiques. Exemples :

aws rds create-db-proxy 
        --db-proxy-name '…' 
        --engine-family <mysql|postgresql>       
        --auth [{}, {}] 
        --role-arn '…'
        --subnet-ids {}
        --require-tls <true|false>
        --tags {}
aws rds register-db-proxy-targets 
        --target-group-name '…'
        --db-cluster-identifier  '…'
        --db-instance-identifier '…'

Trusted Language Extensions (TLE) pour PostgreSQL (langue française non garantie) permet aux développeurs de créer des extensions PostgreSQL hautes performances et de les exécuter en toute sécurité sur Amazon Aurora et Amazon RDS. 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. Avec TLE, les fournisseurs indépendants de logiciels (ISV) peuvent fournir de nouvelles extensions PostgreSQL aux clients qui s'exécutent sur Aurora et Amazon RDS.

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 (langue française non garantie) offre plusieurs couches de protection pour atténuer 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 pourront exécuter et créer à l'aide de la commande « CREATE EXTENSION » (CRÉER UNE EXTENSION) 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 (langue française non garantie) est disponible pour l'édition compatible avec Amazon Aurora PostgreSQL et Amazon RDS sur PostgreSQL à partir des versions 14.5. TLE est implémenté comme une extension PostgreSQL proprement dite et vous pouvez l'activer à partir du rôle rds_superuser de manière similaire aux autres extensions prises en charge par Aurora et Amazon RDS.

Vous pouvez exécuter TLE pour PostgreSQL (langue française non garantie) dans PostgreSQL 14.5 ou versions ultérieures dans Amazon Aurora et Amazon RDS.  

TLE pour PostgreSQL (langue française non garantie) 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 (langue française non garantie) est disponible pour les clients Aurora et Amazon RDS 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 (langue française non garantie) 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 (langue française non garantie) prend 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.

TLE pour PostgreSQL (langue française non garantie) 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 PostgreSQL sur la page GitHub de TLE officielle.

Les déploiements bleus/verts Amazon RDS sont disponibles dansAmazon Aurora MySQL-Compatible Edition, Amazon Aurora PostgreSQL-Compatible Edition, Amazon RDS for MySQL, Amazon RDS for MariaDB, et Amazon RDS for PostgreSQL. 

Les déploiements bleus/verts d'Amazon RDS sont disponibles dans l'édition compatible avec Amazon Aurora MySQL versions 5.6 et ultérieures, RDS for MySQL versions 5.7 et ultérieures et RDS for MariaDB versions 10.2 et ultérieures. Les déploiements bleus/verts sont également pris en charge pour l'édition compatible avec Amazon Aurora PostgreSQL et Amazon RDS for PostgreSQL pour 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. Pour en savoir plus sur les versions disponibles dans Amazon Aurora, consultez la documentation relative à Amazon RDS. 

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.

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 du stockage, le coût des E/S en lecture/écriture et toutes les fonctionnalités 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 instance db.instance pendant la durée de vie du déploiement bleu/vert.

Par exemple : Vous avez une base de données RDS for MySQL 5.7 exécutée sur deux db.instances r5.2xlarge, une instance de base de données principale et un réplica en lecture, dans la région AWS us-east-1 avec une configuration Multi-AZ (MAZ). Chacune des instances db.instance r5.2xlarge est configurée pour un système Amazon Elastic Block Storge (EBS) de 20 Gio à usage général. Vous créez un clone de la topologie de l'instance bleue en utilisant les déploiements bleus/verts d'Amazon RDS, vous l'exécutez pendant 15 jours (360 heures), puis vous supprimez les instances bleues après un basculement réussi. Les instances bleues coûtent 1 387 USD pour 15 jours à un tarif à la demande de 1,926 USD/h (coût de l'instance + EBS). Le coût total de l'utilisation des déploiements bleus/verts pour ces 15 jours est de 2 774 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 permettent d'effectuer des modifications plus sûres, plus simples et plus rapides des bases de données, 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 transforment l'environnement de préproduction en environnement de production en redirigeant le trafic vers l'environnement de production nouvellement créé. 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.

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.

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.

Non, les déploiements bleus/verts d'Amazon RDS ne prennent pas en charge les bases de données mondiales, Proxy Amazon RDS, les réplicas en lecture inter-régions ou les réplicas en lecture en cascade.

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

MySQL protège les utilisateurs contre la perte de données en écrivant les données par pages de 16 Kio en mémoire deux fois dans un stockage durable ; d'abord dans le « tampon de double écriture », puis dans le stockage des tables. Les écritures optimisées pour Amazon RDS écrivent vos pages de données de 16 Kio directement dans vos fichiers de données de manière fiable et durable en une seule étape grâce à la fonctionnalité de prévention des écritures déchirées d'AWS Nitro System.

Écritures optimisées pour Amazon RDS est disponible pour la version majeure MySQL 8.0.30 et plus.

Amazon RDS Optimized Writes (français non garanti) est disponible dans les instances db.r6i et db.r5b. Cette option est disponible dans toutes les régions où ces instances sont disponibles, à l'exception des régions AWS Chine.

Non. L'édition compatible avec Amazon Aurora MySQL permet déjà d'éviter l'utilisation du « tampon de double écriture ». À la place, Amazon Aurora réplique les données de six façons à travers trois zones de disponibilité (AZ) et utilise une approche basée sur le quorum pour écrire durablement les données et les lire correctement par la suite.

Actuellement, cette version initiale ne prend pas en charge les écritures optimisées pour Amazon RDS pour vos instances de bases de données existantes, et ce, même si la classe d'instance prend en charge les écritures optimisées.

Les écritures optimisées pour Amazon RDS sont disponibles pour les clients RDS for MySQL sans frais supplémentaires.

Les charges de travail qui utilisent des objets temporaires dans MySQL et MariaDB pour le traitement des requêtes bénéficient d'Amazon RDS Optimized Reads. Optimized Reads place les objets temporaires sur le stockage d'instance NVMe de l'instance de base de données, au lieu du volume Amazon Elastic Block Store. Cela permet de doubler la vitesse de traitement des requêtes complexes.

Les lectures optimisées pour Amazon RDS est disponible pour RDS for MySQL sur les versions 8.0.28 et ultérieures et pour RDS for MariaDB sur les versions 10.4.25, 10.5.16, 10.6.7 et ultérieures.

Les lectures optimisées pour Amazon RDS sont disponibles dans toutes les régions où les instances db.r5d, db.m5d, db.r6gd, et db.m6gd, X2idn, et X2iedn sont disponibles. Pour plus d'informations, consultez la documentation sur les classes d'instances de bases de données Amazon RDS.

Les clients devraient utiliser les lectures optimisées pour Amazon RDS dans les cas suivants : les charges de travail nécessitant des requêtes complexes, l'analytique à usage général ou les charges de travail nécessitant des groupes complexes, des tris, des agrégations de hachage, des jointures à forte charge et des expressions de tables communes (CTE). Ces cas d'utilisation entraînent la création de tables temporaires, ce qui permet à Optimized Reads d'accélérer le traitement des requêtes de votre charge de travail.

Oui, les clients peuvent convertir leur base de données Amazon RDS existante pour utiliser les lectures optimisées pour Amazon RDS en déplaçant la charge de travail vers une instance optimisée pour la lecture. Optimized Reads est également disponible par défaut sur toutes les classes d'instance prises en charge. Si vous exécutez votre charge de travail sur des instances db.r5d, db.m5d, db.r6gd, db.m6gd, X2idn et X2iedn, vous bénéficiez déjà d'Optimized Reads.