Facturation pour Amazon Redshift sans serveur

Facturation de la capacité de calcul

Vous pouvez acheter de la capacité pour Amazon Redshift Serverless de deux manières :

• Vous pouvez acheter de la capacité à la demande : lorsque vous optez pour une capacité de calcul à la demande, vous payez les ressources au fur et à mesure. C'est le meilleur choix si vous commencez tout juste à utiliser Amazon Redshift Serverless ou si vous n'avez pas encore une idée précise de vos habitudes d'utilisation régulières. La solution à la demande offre la plus grande flexibilité. Pour de plus amples informations, veuillez consulter Facturation de la capacité de calcul à la demande.

• Vous pouvez acheter des réservations : une réservation offre un discount lorsque vous achetez une quantité prédéfinie de ressources informatiques pour une durée spécifique, par exemple pendant un an. C'est une bonne idée si vous savez que vous allez utiliser régulièrement une certaine quantité de capacité. Il est utile d'économiser de l'argent lorsque vous pouvez prévoir certains de vos besoins en matière de capacité. Pour de plus amples informations, veuillez consulter Facturation pour les réservations sans serveur.

Vous pouvez utiliser à la fois les réservations et les ressources à la demande. Il n'est pas nécessaire d'utiliser l'un ou l'autre.

Pour obtenir des informations détaillées sur les tarifs, consultez les tarifs d'Amazon Redshift.

Facturation pour stockage

La capacité de stockage principale est facturée en tant que stockage géré Redshift (RMS). Le stockage est facturé par Go / mois. Le stockage et la capacité de calcul font l’objet d’une facturation distincte. Le stockage utilisé pour les instantanés d’utilisateurs est facturé au taux standard des sauvegardes, en fonction de votre niveau d’utilisation.

Les coûts de transfert de données et de machine learning (ML) s’appliquent séparément, de la même manière que les clusters alloués. La réplication de snapshots et le partage de données entre les AWS régions sont facturés aux taux de transfert indiqués sur la page de tarification. Pour plus d’informations, consultez Tarification d’Amazon Redshift.

Visualisation de l'utilisation de la facturation avec CloudWatch

La métriqueSnapshotStorage, qui suit l'utilisation du stockage des instantanés, est générée et envoyée à CloudWatch. Pour plus d'informations CloudWatch, consultez Qu'est-ce qu'Amazon CloudWatch ?

Utilisation de l’essai gratuit d’Amazon Redshift sans serveur

Amazon Redshift sans serveur propose un essai gratuit. Si vous participez à l’essai gratuit, vous pouvez voir le solde du crédit de l’essai gratuit dans la console Redshift et vérifier l’utilisation de l’essai gratuit dans la vue système SYS_SERVERLESS_USAGE. Notez que les détails de facturation pour l’utilisation de l’essai gratuit n’apparaissent pas dans la console de facturation. Vous ne pouvez visualiser l’utilisation dans la console de facturation qu’après la fin de la période d’essai gratuite. Pour en savoir plus sur l’essai gratuit d’Amazon Redshift sans serveur, consultez Essai gratuit d’Amazon Redshift sans serveur.

Notes d’utilisation de facturation

• Utilisation de l’enregistrement : une requête ou une transaction n’est mesurée et enregistrée qu’une fois la transaction terminée, annulée ou arrêtée. Par exemple, si une transaction s’exécute pendant deux jours, l’utilisation des RPU est enregistrée une fois que cette transaction est terminée. Vous pouvez surveiller l’utilisation continue en temps réel en interrogeant sys_serverless_usage. L’enregistrement des transactions peut refléter une variation d’utilisation des RPU et affecter les coûts pour des heures spécifiques et pour une utilisation quotidienne.

• Rédaction de transactions explicites : il est important de respecter la bonne pratique consistant à mettre fin aux transactions. Si vous ne terminez pas ou n'annulez pas une transaction en cours, Amazon Redshift Serverless continue de l'utiliser. RPUs Par exemple, si vous écrivez un texte BEGIN TRAN explicite, il est important d’avoir des instructions COMMIT et ROLLBACKcorrespondantes.

• Requêtes annulées : si vous exécutez une requête et que vous l’annulez avant la fin de son exécution, vous êtes toujours facturé pour la durée de l’exécution de la requête.

• Scaling (Mise à l’échelle) : l’instance Amazon Redshift sans serveur peut initier une mise à l’échelle pour gérer les périodes de charge plus élevée, afin de maintenir des performances cohérentes. Votre facturation Amazon Redshift sans serveur comprend à la fois le calcul de base et la capacité mise à l’échelle au même taux de RPU.

• Scaling down (Réduction de l’échelle) : Amazon Redshift sans serveur augmente sa capacité RPU de base pour gérer les périodes de charge plus élevée. Dans certains cas, la capacité du RPU peut rester à un niveau supérieur pendant un certain temps après la baisse de la charge des requêtes. Nous vous recommandons de définir le nombre maximum d’heures RPU dans la console afin de vous prémunir contre les coûts inattendus.

• Tables système : lorsque vous interrogez une table système, la durée de requête est facturée.

• Redshift Spectrum : lorsque vous utilisez Amazon Redshift sans serveur et que vous exécutez des requêtes, il n’y a pas de frais distincts pour les requêtes liées à un lac de données. Pour les requêtes sur des données stockées dans Amazon S3, les frais sont identiques, par temps de transaction, comme les requêtes sur des données locales.

• Requêtes fédérées - Les requêtes fédérées sont facturées en termes d' RPUs utilisation sur un intervalle de temps spécifique, de la même manière que les requêtes sur l'entrepôt de données ou le lac de données.

• Stockage : le stockage est facturé séparément, par Go / mois.

• Forfait minimum : le tarif minimum est fixé à 60 secondes d’utilisation des ressources, facturées à la seconde.

• Facturation d’instantané : la facturation d’instantané ne change pas. Il est facturé en fonction du stockage, sur la base d’un tarif de Go / mois. Vous pouvez restaurer gratuitement votre entrepôt des données à des points spécifiques au cours des dernières 24 heures à une granularité de 30 minutes. Pour plus d’informations, consultez Tarification d’Amazon Redshift.

Les bonnes pratiques d’Amazon Redshift sans serveur pour une facturation prévisible

Vous trouverez ci-dessous les meilleures pratiques et les paramètres intégrés qui vous aideront à garantir la cohérence de votre facturation.

• Veillez à mettre fin à chaque transaction. Lorsque vous utilisez BEGIN pour commencer une transaction, il est important d’y mettre fin (END) également.

• Suivez les bonnes pratiques en matière de gestion des erreurs pour répondre convenablement aux erreurs et mettre fin à chaque transaction. Le fait de minimiser le nombre de transactions ouvertes permet d’éviter l’utilisation inutile de RPU.

• Utilisez SESSION TIMEOUT pour mettre fin aux transactions ouvertes et aux sessions inactives. Ce paramètre fait expirer toute session restée inactive pendant plus de 3 600 secondes (1 heure). Il fait expirer toute transaction restée ouverte et inactive pendant plus de 21 600 secondes (6 heures). Ce paramètre de délai peut être modifié explicitement pour un utilisateur spécifique, par exemple lorsque vous souhaitez maintenir une session ouverte pour une requête de longue durée. La rubrique CREATE USER (CRÉER UN UTILISATEUR) montre comment adapter SESSION TIMEOUT à un utilisateur.

  • Dans la plupart des cas, nous vous recommandons de ne pas allonger la valeur SESSION TIMEOUT, sauf si vous avez un cas d’utilisation qui le requiert spécifiquement. Si la session reste inactive, avec une transaction ouverte, cela peut entraîner une utilisation jusqu'à la fermeture de la session. RPUs Cela entraînera des coûts inutiles.

  • Amazon Redshift sans serveur dispose d’une durée maximale de 86 399 secondes (24 heures) pour une requête en cours d’exécution. La période maximale d’inactivité pour une transaction ouverte est de six heures avant qu’Amazon Redshift sans serveur ne mette fin à la session associée à la transaction. Pour de plus amples informations, veuillez consulter Quotas pour les objets Amazon Redshift sans serveur.

Facturation sans serveur Amazon Redshift avec mise en commun des connexions

Amazon Redshift Serverless traite toutes les requêtes entrantes comme des activités facturables des utilisateurs, y compris les requêtes légères de vérification de l'état envoyées par des pools de connexions. Ce comportement s'applique indépendamment du fait que la requête provient d'une application, d'un JDBC/ODBC pilote ou d'un framework de regroupement de connexions. Chaque requête de vérification de l'état déclenche l'utilisation du calcul, et des frais sont facturés quel que soit le but ou l'origine de la requête. Par conséquent, le maintien de pools de connexions ouverts peut générer des coûts même lorsqu'aucune charge de travail utilisateur réelle n'est en cours d'exécution.

Le regroupement de connexions gère un pool de connexions persistantes entre les applications et le point de terminaison Amazon Redshift Serverless. Pour garantir que ces connexions restent saines et disponibles, les mécanismes de regroupement envoient souvent des requêtes légères ou vides (par exempleSELECT 1) à intervalles réguliers. Ces requêtes automatisées vérifient l'état de la connexion.

Lorsque vous utilisez le regroupement de connexions, tenez compte des meilleures pratiques suivantes afin de minimiser les frais imprévus :

• Ajustez la fréquence des vérifications de santé en passant en revue et en optimisant la fréquence des requêtes de vérification de l'état ou de maintien en vie dans votre configuration de regroupement de connexions.

• Optimisez les paramètres du système inactif en configurant le regroupement des connexions afin de minimiser les pertes de connexion inutiles ou les requêtes en arrière-plan pendant les périodes d'inactivité du système.

• Mettez en œuvre le regroupement au niveau des applications ou une meilleure gestion du cycle de vie des connexions si cela peut réduire les frais généraux.

• Désactivez les requêtes de pulsation ou de validation si votre configuration de regroupement de connexions le permet. Vérifiez les paramètres de votre chaîne de connexion ou vos fichiers de configuration spécifiques pour ajuster ces paramètres.

• Ajustez les paramètres TCP keepalive : si vous ne parvenez pas à désactiver les mécanismes internes du rythme cardiaque du pilote, ajustez les paramètres TCP (Transmission Control Protocol) keepalive au niveau du système d'exploitation ou de l'application pour résoudre les problèmes de délai de connexion. Reportez-vous à la documentation de votre système d'exploitation, de votre JDBC/ODBC pilote ou de votre pool de connexions pour plus de détails.

• Optimisez le regroupement des connexions aux bases de données : configurez votre pool de connexions (HikariCP, Apache Database Connection Pool) pour gérer les connexions et minimiser les frais de connexion. Concentrez-vous sur des paramètres tels que le nombre maximal de connexions, le délai d'inactivité et les requêtes de validation (si nécessaire). Cette optimisation permet d'aligner l'utilisation du calcul sans serveur Amazon Redshift sur la demande de charge de travail réelle, ce qui peut réduire les coûts.

Optimisation des coûts pour Amazon Redshift Serverless avec Zero-ETL

Pour optimiser les coûts lors de l'exécution d'intégrations sans ETL sur Amazon Redshift Serverless, vous pouvez dimensionner correctement vos environnements et ajuster vos paramètres d'actualisation en fonction des besoins de charge de travail. Pensez à effectuer les ajustements suivants :

• Utilisez la capacité RPU de base inférieure de 8 RPU lorsqu'elle est disponible pour les charges de travail.

• Configurez le REFRESH_INTERVAL de votre instance Redshift cible pour équilibrer fraîcheur et coût. Des intervalles plus courts garantissent des mises à jour quasiment en temps réel, mais augmentent les coûts de calcul. Des intervalles plus longs (5 minutes ou plus) réduisent les frais liés aux charges de travail pour lesquelles la fraîcheur immédiate n'est pas essentielle, comme les rapports ou les analyses historiques. Pour modifier votre cible Redshift REFRESH_INTERVAL, consultez la clause d'intervalle d'actualisation dans la description d'ALTER DATABASE.

• Optimisez l'utilisation de votre environnement Amazon Redshift Serverless en exécutant simultanément des charges de travail d'analyse alors que des données sans ETL sont ingérées. Cela garantit que la capacité de calcul répond activement à de multiples objectifs commerciaux.

• Pour minimiser les temps de calcul inactifs et optimiser le coût total de possession, passez en revue vos intégrations zéro ETL actuelles et augmentez le REFRESH_INTERVAL lorsque la fraîcheur des données n'est pas essentielle pour l'entreprise, tout en alignant la capacité du RPU sur la demande de charge de travail.