Tarification d'Amazon Aurora

Avec Aurora, vous pouvez configurer vos clusters de bases de données pour qu'ils fonctionnent de manière rentable, quels que soient les besoins de mise à l'échelle ou l'évolution des modèles d'accès aux données de vos applications. Vous avez la possibilité de choisir entre les options de configuration Amazon Aurora Standard et Amazon Aurora I/O-Optimized pour répondre au mieux aux exigences en matière du rapport prix/performance et prix/prévisibilité des caractéristiques de votre charge de travail unique. Les frais d'instance de base de données, de stockage et d'E/S varient en fonction de l'option choisie. Pour en savoir plus, consultez Stockage et fiabilité d'Amazon Aurora.

Aurora Standard offre une tarification rentable pour la grande majorité des applications exécutées sur Aurora avec des modèles d'accès aux données typiques et une utilisation d'E/S faible à modérée. Avec Aurora Standard, vous payez les instances de vos bases de données, votre stockage et vos E/S à la demande.

Aurora I/O Optimized permet d'améliorer les performances en termes de prix pour les applications gourmandes en E/S. Si vos dépenses en E/S dépassent 25 % de vos dépenses totales en bases de données Aurora, vous pouvez économiser jusqu'à 40 % sur les coûts des charges de travail intensives en E/S grâce à Aurora I/O-Optimized. Avec Aurora I/O-Optimized, vous ne payez que les instances de vos bases de données et l'utilisation du stockage, et il n'y a pas de frais pour les opérations d'E/S de lecture et d'écriture. Aurora I/O-Optimized offre une tarification prévisible pour toutes les applications, quelle que soit l'évolution des modèles d'accès aux données ou de l'utilisation des E/S. Aurora I/O Optimized élimine la variabilité des dépenses en E/S.

Avec Aurora, vous n'avez pas besoin de provisionner à l'avance les opérations de stockage ou d'E/S, et les deux sont automatiquement mis à l'échelle. Le stockage distribué à tolérance de pannes d'Aurora assure automatiquement la pérennité de vos données sur trois zones de disponibilité. Vous ne payez qu'une seule copie des données.

Le stockage Aurora est facturé par incréments d'un gigaoctet par mois aux tarifs indiqués dans le tableau suivant pour les configurations Aurora Standard et Aurora I/O-Optimized. Avec Aurora Standard, vous payez le stockage et les opérations d'E/S que votre base de données Aurora consomme. Les frais d'E/S peuvent varier considérablement en fonction de la charge de travail et du moteur de la base de données. Pour en savoir plus sur les opérations d'E/S, consultez la FAQ d'Aurora, « Q : Que sont les opérations d'E/S dans Aurora et comment sont-elles calculées ? ». Avec Aurora I/O-Optimized, vous n'êtes pas facturé pour les opérations d'E/S de lecture et d'écriture.

Lisez l'exemple détaillé de tarification du stockage des bases de données et des opérations d'E/S.

Le stockage de sauvegarde pour Aurora est le stockage associé à vos sauvegardes de bases de données automatisées et à n'importe quel instantané de cluster de bases de données initié par le client.

Vous n'êtes pas facturé pour le stockage de sauvegarde jusqu'à 100 % de la taille de votre cluster de base de données. Il n'y a pas non plus de frais pour les instantanés de base de données créés pendant la période de conservation des sauvegardes. Pour toutes les autres sauvegardes et instantanés (y compris ceux provenant de clusters supprimés), l'utilisation est mesurée par Go-mois aux tarifs suivants :

Le retour sur trace vous permet de ramener rapidement une base de données Aurora à un point précédent dans le temps sans devoir restaurer des données à partir d'une sauvegarde. Il vous permet de récupérer rapidement d'erreurs des utilisateurs, comme la suppression du mauvais tableau ou de la mauvaise ligne. Cette fonction est actuellement disponible pour l'édition compatible avec MySQL Aurora.

Indiquez jusqu'à quand vous voulez pouvoir revenir en arrière (par exemple, jusqu'à 24 heures). Aurora conservera les journaux, appelés enregistrements de modification, pour la durée du retour sur trace spécifiée. Vous payez un prix à l'heure pour le stockage des enregistrements de modification.

Lisez l'exemple détaillé de tarification du retour sur trace.

L'API Data est une API HTTPS sécurisée et facile à utiliser qui permet d'exécuter des requêtes SQL sur des bases de données Aurora afin d'accélérer le développement d'applications modernes. L'API Data élimine les tâches de configuration du réseau et des applications nécessaires pour se connecter en toute sécurité à une base de données Aurora, ce qui rend l'accès à Aurora aussi simple qu'un appel d'API.

Avec l'API Data, vous ne payez que lorsque votre API est utilisée. Aucuns frais minimaux ni engagement initial ne sont requis. Vous ne payez que pour l'API et les requêtes de données effectuées par vos applications. Les charges utiles des données de requête d'API Data sont mesurées à 32 Ko par requête pour les données envoyées à l'API ou reçues de l'API. Si la taille de la charge utile des données de votre requête d'API est supérieure à 32 Ko, une requête d'API supplémentaire est facturée pour chaque incrément de 32 Ko. Ainsi, si votre charge utile est de 35 Ko, deux requêtes d'API vous seront facturées.

L'offre gratuite pour l'API Data inclut un million de requêtes d'API par mois, agrégées entre les régions AWS, pendant la première année.

Les clients devront également payer des frais pour AWS Secrets Manager et peuvent également encourir des frais supplémentaires pour AWS CloudTrail, s'il est activé.

Le tarif ci-dessous est basé sur les données transférées « en entrée » et « en sortie » d'Aurora.

• Dans le cadre de l'offre gratuite d'AWS, les clients AWS bénéficient chaque mois de 100 Go de données transférées gratuitement vers l'internet, cumulées sur l'ensemble des services AWS et des régions (à l'exception des régions Chine (Beijing), Chine (Ningxia) et GovCloud (US)).
  
• Les données transférées entre Aurora et les instances Amazon Elastic Compute Cloud (Amazon EC2) dans la même zone de disponibilité sont gratuites.
  
• Le transfert de données entre différentes zones de disponibilité pour la réplication de cluster de base de données est gratuit.  
• Pour le transfert de données entre une instance Amazon EC2 et une instance de base de données Aurora se trouvant dans des zones de disponibilité différentes au sein de la même région, les frais de transfert de données régional Amazon EC2 s'appliquent.
  

Les clients AWS bénéficient de 100 Go gratuits de transfert de données sortantes vers Internet chaque mois, cumulés sur l'ensemble des services et régions AWS (à l'exception de la Chine et de GovCloud). Le transfert de 100 Go de données sortantes vers Internet au titre de l'offre gratuite est fourni à l'échelle mondiale et ne s'applique pas séparément ou individuellement aux régions AWS.

Sauf indication contraire, les 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 d'AWS est soumise à la taxe sur la consommation applicable dans ce pays.

Le support étendu d'Amazon RDS vous permet de continuer à utiliser les versions majeures de l'édition compatible avec Aurora MySQL et PostgreSQL après la fin de vie de la communauté. Pendant cette période, AWS fournit des correctifs aux problèmes de sécurité critiques et aux bogues par le biais de mises à jour, ce qui vous donne plus de temps, jusqu'à trois ans, pour effectuer une mise à niveau vers une nouvelle version majeure afin de répondre aux exigences de votre entreprise.

Pour les instances provisionnées sur Amazon Aurora, le support étendu RDS est facturé par processeur virtuel par heure. Pour Aurora sans serveur v2, RDS Extended Support est facturé par unité de capacité Aurora (ACU) par heure consommée par votre base de données. La tarification du support étendu RDS dépend également de la région AWS et de la date du calendrier. Les clients de l'édition compatible Aurora MySQL ont au moins un an pour migrer vers une version de support standard après la fin de vie de la communauté avant le début des frais de support étendu RDS. Reportez-vous à la documentation Amazon Aurora pour obtenir des informations sur le calendrier.

Si vous avez une instance sur Aurora PostgreSQL 12 compatible, cette version arrivera à la fin du support standard le 28 février 2025. Si vous déployez aux USA Est (Ohio), vous serez facturé 0,100 USD par heure de vCPU entre le 1er mars 2025 et le 28 février 2027. À compter du 1er mars 2027, vous serez facturé 0,200 USD par heure vCPU-heure.

L'export d'instantané fournit une méthode automatisée pour exporter les données d'un instantané Aurora vers Amazon Simple Storage Service (Amazon S3) au format Parquet. L'export de cluster fournit une méthode automatisée pour exporter les données d'un cluster de base de données Aurora vers Amazon S3 au format Parquet. Le format Parquet est jusqu'à deux fois plus rapide à décharger et consomme jusqu'à six fois moins de stockage dans Amazon S3 par rapport aux formats texte. Vous pouvez analyser les données exportées à l'aide des services AWS tels qu'Amazon Athena, Amazon EMR et Amazon SageMaker.

Pour tous les exports d'instantanés et de clusters, l'utilisation est mesurée par gigaoctet de données d'instantanés. Les exports de données subséquents issus du même instantané ne fonctionnent pas de manière incrémentielle. Lisez l'exemple détaillé de tarification de l'export d'un instantané ou d'un cluster.

Des frais supplémentaires s'appliquent pour le chiffrement ou le déchiffrement des données à l'aide d'AWS Key Management Service (AWS KMS). Pour en savoir plus sur ces frais, consultez la page de tarification AWS KMS. Des frais s'appliquent également pour le stockage des données exportées dans Amazon S3 et pour les demandes PUT effectuées dans votre compartiment S3. Pour en savoir plus sur ces frais, consultez la page de tarification Amazon S3.

La disponibilité et la prise en charge de la fonction varient selon les versions spécifiques de chaque moteur de base de données et selon les régions AWS. Pour plus d'informations sur la disponibilité par version et par région de l'exportation des données instantanées des clusters de bases de données vers S3, consultezExportation des données instantanées vers Amazon S3.

L'intégration zéro ETL d'Amazon Aurora à Amazon Redshift rend possibles l'analytique et le ML en temps quasi réel à l'aide d'Amazon Redshift sur des pétaoctets de données transactionnelles provenant d'Aurora. L'intégration zéro ETL élimine le besoin de créer et de gérer des pipelines de données complexes qui effectuent des opérations d'extraction, transformation et chargement (ETL).

AWS ne facture aucuns frais supplémentaires pour l'intégration zéro ETL. Vous payez pour les ressources Amazon Aurora et Amazon Redshift existantes utilisées pour créer et traiter les données de modification créées dans le cadre d'une intégration zéro ETL. Ces ressources peuvent inclure des E/S et du stockage supplémentaires utilisés en activant un binlog amélioré, des coûts d’exportation d’instantanéspour l’exportation initiale des données afin d’accélérer vos bases de données Amazon Redshift, un stockage Amazon Redshift supplémentaire pour stocker des données répliquées, le calcul pour le traitement de la réplication des données, et les coûts de transfert de données inter-AZ pour déplacer les données de la source vers la cible. Le traitement continu des modifications de données par intégration zéro ETL est proposé sans frais supplémentaires. 

Les exemples suivants montrent comment les coûts Aurora sont calculés pour les ressources et les fonctions disponibles pour Aurora.

Exemples d'utilisation d'Aurora sans serveur :

Prenons l'exemple d'une charge de travail qui nécessite 5 ACU et s'exécute pendant 30 minutes. Nous voulons calculer les coûts de calcul de l'exécution de cette charge de travail sur Aurora sans serveur v1 et v2 avec le cluster de base de données configuré comme Aurora Standard et Aurora I/O-Optimized aux USA Est (Virginie du Nord).

Avec Aurora sans serveur v2, la capacité minimale de la base de données que vous pouvez définir est de 0,5 ACU. La base de données passe instantanément de 0,5 ACU à 5 ACU, s'exécute pendant 30 minutes et réduit la capacité jusqu'à la capacité minimale de 0,5 ACU. Comme la réduction de la v2 est jusqu'à 15 fois plus rapide, la base de données passe de 5 ACU à 0,5 ACU en 3 minutes environ. Par conséquent, voici le coût de calcul pour l'exécution de cette charge de travail.

Avec Aurora sans serveur v1, la capacité minimale que vous pouvez définir est de 1 ACU. Le temps nécessaire à Aurora sans serveur v1 pour mettre à l'échelle la capacité dépend de la charge de travail. En supposant qu'Aurora sans serveur v1 soit capable de doubler la capacité toutes les minutes, la base de données passerait à 8 ACU en 3 minutes. La base de données s'exécute ensuite pendant 30 minutes à 8 ACU. Enfin, la base de données réduit les ACU de 8 à 1 ACU en diminuant la capacité de moitié toutes les 15 minutes. Par conséquent, voici le coût de calcul pour l'exécution de cette charge de travail.

Vous pouvez réutiliser vos instances réservées (RI) standard Aurora existantes avec Aurora I/O-Optimized. Pour utiliser pleinement les avantages de vos remises sur les RI avec Aurora I/O-Optimized, vous pouvez acheter 30 % de RI supplémentaires similaires à vos RI actuelles. Le tableau ci-dessous montre des exemples de la manière d'estimer les RI supplémentaires lorsque vous utilisez Aurora I/O-Optimized. Si les RI nécessaires sont une fraction, vous pouvez profiter de la flexibilité de taille disponible avec les RI pour obtenir un nombre entier, comme indiqué ci-dessous. Dans les exemples ci-dessous, les RI actuelles font référence aux RI standard Aurora dont vous disposez aujourd'hui et les RI supplémentaires font référence au nombre de RI standard Aurora que vous devez acheter pour maintenir vos remises sur les RI actuelles lorsque vous utilisez Aurora I/O-Optimized. Si vous choisissez de ne pas acheter de RI supplémentaires, les tarifs à la demande s'appliqueront.

Supposons que vous disposez d'une base de données Aurora et que vous démarrez avec une base de données de 1 000 Go au début du mois (période de 30 jours) qui augmente de 2 % (ou 20 Go) par jour. Supposons également que la même base de données lise 350 pages de données à partir du stockage par seconde pour satisfaire les requêtes qui y sont exécutées. Enfin, supposons que votre application apporte des modifications à la base de données affectant en moyenne 100 pages de données par seconde. Nous voulons calculer les coûts de stockage et d'E/S liés à l'exécution de cette charge de travail avec Aurora Standard et Aurora I/O-Optimized aux USA Est (Virginie du Nord).

Pour cette charge de travail, vous obtiendrez 19,8 % d'économies sur les coûts de stockage avec Aurora I/O-Optimized.

Supposons que vous disposiez d'une base de données Aurora Global Database dans laquelle la région principale dispose de deux instances, consommant 80 Go de stockage et effectuant 45 millions d'opérations d'E/S en écriture et 5 millions d'opérations d'E/S en lecture par mois. Supposons que la région secondaire dispose d'une instance effectuant 5 millions d'opérations d'E/S en lecture par mois. Nous voulons calculer le coût d'exploitation d'une Global Database avec la région USA Est (Virginie du Nord) comme région principale et la région USA Ouest (Oregon) comme région secondaire.

Supposons que votre base de données Aurora génère 10 000 000 enregistrements de modifications par heure et que vous vouliez revenir jusqu'à 10 heures en arrière. Nous voulons calculer le coût du retour sur trace pour ce scénario dans la région USA Est (Virginie du Nord).

L'API Data est appelée pour interroger une base Aurora compatible PostgreSQL avec l'appel d'API ExecuteStatement. Il y a 4,1 millions de requêtes d'API par mois au total. Sur les 4,1 millions de requêtes, 2,1 millions sont des Insert dans Aurora. Chacune contient des données d'une taille de charge utile d'API de 64 Ko/requête. Sur un total de 4,1 millions de requêtes, 2 millions concernent des lectures de données Aurora. Parmi celles-ci, 1 million avaient une charge utile renvoyée inférieure à 32 Ko et 1 million avaient une taille de charge utile comprise entre 32,01 Ko et 64 Ko.

L'API Data est appelée pour interroger une base Aurora compatible PostgreSQL avec l'appel d'API ExecuteStatement. Il y a 300 000 requêtes d'API par mois. Toutes les requêtes d'API renvoient 64 Ko de charge utile de données ; chaque requête sera donc facturée comme suit : 64 Ko/32 Ko = 2 requêtes. 

L'API Data est appelée pour interroger une base Aurora compatible PostgreSQL en utilisant les cinq appels d'API (BeginTransaction, CommitTransaction, RollbackTransaction, ExecuteStatement, BatchExecuteStatement. Il y a 1,2 milliard de requêtes d'API par mois. Aucune des requêtes ne renvoie ou n'envoie plus de 32 Ko de charge utile de données. 

Supposons que vous disposez d'un instantané de 100 Go et que vous utilisez le filtrage pour sélectionner une table de 10 Go dans cet instantané, afin de l'exporter vers Amazon S3.