Comment utiliser les instances ponctuelles amazon ec2?

Comprendre les différents états d'une demande de spot. Une demande de place est:

• ouvert si la demande a été faite mais qu'elle n'a pas encore été satisfaite. Une demande de place est ouverte immédiatement après avoir été faite pour la première fois. De plus, les demandes persistantes deviennent ouvertes dès que l'instance spot associée est interrompue (terminée par Amazon).
• actif après qu'il a été rempli par Amazon, c'est-à-dire après qu'une instance spot associée a été créée.
• échouait s'il était rejeté par Amazon en raison de mauvais paramètres.
• annulé s'il a été annulé par l'utilisateur ou si la demande a expiré (c'est-à-dire que le délai d'attente défini par l'utilisateur pour l'exécution de la demande est terminé).
• fermée si l'instance a été interrompue par Amazon et qu'elle n'a pas été initialement spécifiée comme persistante.

Comprenez les étapes pour qu'une demande d'instance spot soit exécutée.

• Il existe des marchés au comptant distincts pour chaque combinaison de zone de disponibilité, de type d'instance et de système d'exploitation. Dans chaque marché au comptant, il existe un prix au comptant.
• Au moment où une demande de spot est faite, la demande comprend la zone de disponibilité, le type d'instance, le système d'exploitation, un prix d'offre (que nous pouvons considérer comme le prix spot maximum que l'utilisateur est prêt à enchérir), ainsi que d'autres options discutées plus tard sur cette page. Aucun de ces éléments ne peut être modifié une fois que la demande de place a été satisfaite. La seule modification que l'utilisateur peut apporter à la demande de spot est de l'annuler (la fin de l'instance annule automatiquement la demande de spot).
• Si le prix de l'offre est inférieur au prix au comptant pour cette zone de disponibilité, ce type d'instance et ce système d'exploitation, l'offre est rejetée et l'utilisateur n'est pas facturé.
• Si le prix de l'offre est égal ou supérieur au prix spot, la demande spot est satisfaite sous réserve de la capacité disponible.
• Si le prix de l'offre dépasse le prix au comptant et que la capacité n'est pas disponible, alors, pour faire place à cette instance, d'autres instances au comptant commencent à être résiliées, à commencer par celles dont le prix de l'offre est le plus bas. Les résiliations initiées par Amazon sont également appelées interruptions d'instance ponctuelle, pour les distinguer plus facilement des résiliations initiées par l'utilisateur. Chaque résiliation se produit deux minutes après l'envoi de l'avis de résiliation à l'instance, pour donner à l'instance en cours de résiliation suffisamment de temps pour s'arrêter normalement (voir la discussion ultérieure sur les avis de résiliation d'instances ponctuelles). Pendant que les instances sont résiliées, d'autres modifications peuvent être apportées à la capacité ponctuelle (par exemple, d'autres utilisateurs peuvent résilier leurs propres instances, libérant ainsi de la capacité). Dès qu'un nombre suffisant d'instances est résilié pour permettre la création d'une nouvelle instance spot,et que le nouveau prix spot n'est toujours pas supérieur au prix acheteur de l'utilisateur, la demande de l'utilisateur est satisfaite.
• Le résultat est que si une seule nouvelle demande d'offre arrive et que le prix de l'offre est supérieur au prix spot actuel, alors, même si la capacité est pleine, une instance spot au prix spot actuel sera terminée et la demande spot de l'utilisateur sera remplie. Cependant, si une offre demande plus d'une instance spot, ou si de nombreux utilisateurs différents enchérissent pour de nouvelles instances sur le même marché, la dynamique peut devenir compliquée.
• En général, les demandes ponctuelles sont satisfaites dans les quelques minutes qui suivent la demande. Pour certains types d'instances, cela peut prendre un certain temps (des heures voire des jours) pour que les demandes d'instances ponctuelles soient satisfaites. De plus, si vous demandez un grand nombre d'instances ponctuelles, elles peuvent ne pas toutes être satisfaites en même temps, en particulier si la capacité est presque pleine.

Comprenez les contraintes imposées par amazon sur les prix spot.

• Les prix des offres ne peuvent pas être supérieurs à dix fois le prix à la demande. Ceci afin d'éviter les pics extrêmes. Auparavant, lorsque les prix des offres n'avaient pas cette limite, les prix des instances au comptant montaient jusqu'à 750€/heure dans une région.
• Bien qu'Amazon n'annonce pas officiellement de prix spot minimum, il est probable qu'il fixe un plancher sur les prix spot par type d'instance, qui reflète avec précision le coût marginal de maintien de l'instance. Même si ce n'est pas le cas, il existe bel et bien des planchers en pratique sur le prix spot, peut-être à cause de certains utilisateurs qui ont toujours besoin d'instances à un prix suffisamment bas.

Notez que certains types d'instances ne sont pas disponibles sur le marché spot. En particulier, l'instance t2.micro, un petit type d'instance idéal si vous souhaitez simplement une instance pour des tests de base, n'est pas disponible en tant qu'instance ponctuelle. Cependant, cette instance est disponible gratuitement dans l'offre gratuite AWS.

Comprendre le compromis clé dans les stratégies d'enchères.

• Des offres plus élevées vous protègent contre l'interruption de vos instances et réduisent la pression sur vous pour développer de meilleures stratégies de gestion des interruptions.
• Les offres inférieures vous aident à plafonner le montant maximum que vous êtes prêt à payer pour les instances, offrant ainsi une meilleure limite supérieure sur vos coûts d'instance.
• Si toutes les flambées de prix étaient brèves, alors les enchères élevées seraient la meilleure stratégie, car l'enchère la plus élevée vous aiderait à survivre à la flambée des prix sans avoir à payer plus en moyenne. En fait, si le pic est très bref, vous n'aurez peut-être rien à payer car vous ne payez que le prix qui est facturé à l'issue d'un nombre entier d'heures après que votre demande de spot ait été satisfaite.
• Si, d'un autre côté, les pics de prix ont généralement tendance à persister, il serait logique de n'enchérir qu'aussi haut que vous êtes prêt à payer de manière persistante.
• En pratique, la situation est mitigée: la plupart des pics de prix sont brefs, mais parfois les pics de prix peuvent durer plusieurs heures. C'est ce qui rend difficile l'élaboration d'une stratégie d'enchères optimale.
• Ce que vous aimeriez idéalement faire, c'est décrire votre offre non seulement en termes de prix maximum que vous paierez, mais également en termes de durée pendant laquelle vous serez prêt à maintenir une offre au prix maximum. Cela peut aider à tirer le meilleur parti des deux mondes: enchérissez suffisamment haut pour que vos instances ne soient pas interrompues, mais si le prix reste aussi élevé pendant une durée non négligeable, enregistrez gracieusement votre travail, mettez fin à l'instance et passez à un manière différente d'exécuter la charge de travail. Malheureusement, Amazon ne prend pas lui-même en charge de telles stratégies, vous devrez donc utiliser l'API pour écrire du code pour exécuter ce type de stratégie, ou utiliser un service tiers qui gère la transition de charge de travail gracieuse.

Comprendre les différents types de stratégies d'enchères. Amazon définit quatre types de stratégies d'enchères.

• Stratégie d'enchère basse: Ici, le prix de l'offre se situe quelque part entre le prix spot et le prix horaire effectif pour les réservations (c'est-à-dire entre 10% et 66% du prix à la demande). Les stratégies d'enchères basses garantissent des dépenses globales faibles sans nécessiter de surveillance supplémentaire. Cependant, ils exposent vos cas à une interruption fréquente, ils ont donc besoin de plus de surveillance pour assurer que les charges de travail ne sont exécutées. Lorsque vous utilisez une stratégie d'enchères faibles pour les charges de travail critiques, il est particulièrement important de la compléter par une bonne stratégie de gestion des interruptions.
• Stratégie d'enchère milieu de gamme: Ici, le prix d'enchère se situe quelque part entre le prix horaire effectif pour les réservations et le prix à la demande. Contrairement aux stratégies d'enchères basses, où vous êtes assuré qu'à aucun moment vous ne payez un prix déraisonnable, les stratégies d'enchères de milieu de gamme peuvent signifier que vous payez parfois un prix plus élevé que ce que vous pourriez être prêt à payer de manière durable. En échange, vous faites face à moins d'interruptions. Les stratégies d'enchères de milieu de gamme ont du sens pour les instances ponctuelles de longue durée.
• Stratégie d'enchères à la demande: Ici, le prix de l'offre est proche du prix à la demande de l'instance. Cette stratégie est souvent associée à la stratégie de gestion des interruptions où, si le prix de l'instance spot se rapproche du prix à la demande, l'utilisateur passe à une instance à la demande pour exécuter la même charge de travail, puis revient une fois à une instance spot le prix est encore bas. Les stratégies d'enchères à la demande sont garanties d'être au plus aussi chères que les instances à la demande à un moment donné, tout en étant en moyenne nettement moins chères.
• Stratégie d'enchère élevée (également connue sous le nom d'enchère de commodité): ici, le prix de l'enchère est nettement supérieur au prix à la demande. Les stratégies d'enchères élevées sont logiques pour les instances ponctuelles de longue durée desservant des frontaux ou pour les instances de courte durée exécutant des charges de travail critiques qui doivent être exécutées rapidement, même au prix d'un éventuel prix plus élevé. Les stratégies d'enchères élevées peuvent également permettre d'obtenir une capacité spot lorsque la capacité à la demande n'est pas disponible. Les stratégies d'enchères élevées pour les instances à longue durée de vie doivent être associées à une certaine surveillance afin que des prix constamment élevés puissent être détectés et traités.

Envisagez des stratégies d'enchères composites. Vous pouvez mélanger et assortir des stratégies d'enchères même pour différentes instances effectuant le même travail. Par exemple, si vous avez généralement besoin de trois instances pour servir une charge frontale, mais que vous pouvez en utiliser deux (au prix d'une latence plus élevée), vous pouvez choisir un mélange avec une instance réservée, une instance spot avec un prix d'offre élevé et un spot exemple avec un prix d'offre inférieur. De cette façon, si les prix au comptant augmentent, vous vous retrouvez avec moins de capacité, mais vous en avez toujours assez pour maintenir la disponibilité. En termes de concepts économiques, votre distribution des prix d'offre est déterminée par votre courbe de demande individuelle en tant que consommateur d'instances au comptant.

Comprenez la distinction entre les demandes ponctuelles ponctuelles et persistantes.

• Une demande ponctuelle ponctuelle est une demande qui est annulée une fois l'instance résiliée par l'utilisateur ou interrompue par Amazon. Pour recréer l'instance, une nouvelle demande de place doit être soumise.
• Une demande ponctuelle persistante est une demande ponctuelle qui est automatiquement soumise à nouveau une fois l'instance terminée.

Comprenez comment votre plate-forme ec2 affecte la façon dont vous pouvez lancer des instances ponctuelles.

• EC2 Classic (non disponible pour les nouveaux clients, uniquement pris en charge pour les clients hérités): vous ne pouvez pas spécifier de zone de disponibilité lors du lancement d'une instance spot. Au contraire, le service spot trouve la zone de disponibilité avec le prix le plus bas pour la configuration demandée, à condition qu'il soit inférieur au prix de l'offre. Notez que la zone de disponibilité actuellement la moins chère peut ne pas rester la moins chère pendant toute la durée de vie de l'instance spot. Le reste de cette page ne traite pas d'EC2 Classic car il s'agit d'une plate-forme obsolète.
• VPC par défaut: le service spot utilise la zone de disponibilité pour le sous-réseau spécifié. Si aucun sous-réseau n'est spécifié, une zone de disponibilité est sélectionnée, mais il se peut qu'il ne s'agisse pas de la zone de disponibilité la moins chère.
• VPC autre que celui par défaut: les services spot utilisent la zone de disponibilité pour le sous-réseau spécifié.

Découvrez comment vous pouvez utiliser des groupes de lancement pour lancer plusieurs instances ponctuelles ensemble (utile pour les clusters informatiques distribués).

• Les instances du groupe de lancement ne sont créés que si tous d'entre eux peuvent être créés. Si le prix ou la capacité ne sont pas suffisants pour créer toutes les instances, aucune des instances n'est créée et l'utilisateur n'est pas facturé.
• Si l'une des instances ponctuelles est interrompue (c'est-à-dire résiliée par Amazon), Amazon déclenche automatiquement la résiliation de toutes les instances du groupe de lancement. Cependant, la résiliation d'une instance par l'utilisateur n'entraîne pas la résiliation des instances restantes.
• Notez que les groupes de lancement diffèrent des groupes de zones de disponibilité. Pour les groupes de zones de disponibilité, plusieurs instances ponctuelles sont demandées ensemble, mais l'interruption de l'une d'entre elles ne déclenche pas la résiliation des autres.

Si vous utilisez des instances ponctuelles pour les frontaux avec des charges de trafic variables, comprenez comment créer des groupes d'instances ponctuelles à autoscaling. Une configuration typique pour gérer des charges de trafic variables consiste à disposer d'un petit nombre d'instances à la demande (réservées) (soit autonomes, soit dans leur propre groupe d'autoscaling) pour la capacité de base, puis d'avoir un groupe d'instances ponctuelles d'autoscaling pour gérer la variable supplémentaire. capacité.

• Le groupe d'autoscaling peut inclure des instances dans plusieurs zones de disponibilité. Cela permet de se prémunir non seulement contre les pannes matérielles et réseau, mais également contre les fluctuations des prix du marché au comptant dans une zone de disponibilité.
• Un seul groupe d'autoscaling peut être composé entièrement d'instances ponctuelles ou entièrement composé d'instances à la demande. Cependant, plusieurs groupes d'autoscaling (ainsi que des instances en dehors des groupes d'autoscaling) peuvent être attachés au même équilibreur de charge, il est donc possible de mélanger et de faire correspondre des instances ponctuelles et des instances à la demande pour gérer la même charge de travail de production.
• La sagesse générale avec les groupes d'autoscaling consiste à augmenter rapidement (également appelé «scale out» dans le jargon AWS) et à réduire (également appelé «scale in» dans le jargon AWS) lentement. Ceci pour plusieurs raisons. Premièrement, étant donné que la facturation se fait à l'heure, la suppression et le redémarrage fréquents d'instances ponctuelles représentent un gaspillage financier. Étant donné que plusieurs pics se produisent souvent dans le temps, il est préférable d'attendre un peu avant de réduire la capacité. Deuxièmement, non seulement c'est un gaspillage financier, mais cela signifie également plus de temps d'arrêt possibles ou de mauvaises performances si la capacité n'est pas suffisante au moment où la charge commence à augmenter.
• Une légère variante de l'idée ci-dessus d'avoir quelques instances à la demande et un groupe d'instances ponctuelles d'autoscaling consiste à avoir deux groupes d'autoscaling: un pour les instances à la demande et un pour les instances ponctuelles. Le groupe d'instances à la demande d'autoscaling a un nombre minimum d'instances égal au nombre de réservations, et le groupe d'instances spot d'autoscaling est destiné à gérer la variabilité du trafic. De plus, le groupe d'instances à la demande d'autoscaling a une politique de montée en charge très difficile à déclencher: il peut évoluer, mais uniquement dans des circonstances extrêmes (c'est-à-dire lorsque la charge devient très élevée, ce qui se produit généralement si le market n'a pas d'instances supplémentaires disponibles pour gérer la charge). Les instances supplémentaires créées dans les groupes d'autoscaling à la demande ne seraient pas couvertes par les réservations et coûteraient donc plus cher.
• La politique de résiliation d'Amazon pour les groupes d'autoscaling est conçue pour vous offrir le maximum d'économies tout en tenant compte de la disponibilité: elle met fin à l'instance spot dans la zone de disponibilité avec la capacité maximale, avec la configuration de lancement la plus ancienne et qui est la plus proche de l'achèvement de son heure facturable. Les économies peuvent être importantes si des instances sont fréquemment créées et arrêtées. Il est également possible de personnaliser la politique de résiliation.

Envisagez d'utiliser des flottes ponctuelles. Il s'agit d'une nouvelle offre d'Amazon (annoncée en mai 2015) où vous pouvez demander une flotte ponctuelle avec plusieurs types d'instances.

• Lors de la demande d'une flotte ponctuelle, vous spécifiez une configuration où vous décrivez les différentes configurations (type d'instance, système d'exploitation, etc.) qui vous intéressent, ainsi qu'un poids numérique associé à chacune. Par exemple, vous pouvez utiliser le type d'instance m4,2xlarge ou le type d'instance m4,4xlarge, mais vous considérez qu'un m4,4xlarge équivaut à deux m4,2xlarge. Vous pouvez le spécifier en définissant un poids de 1 pour m4,2xlarge et 2 pour m4,4xlarge. Notez que les poids sont définis par vous et ne sont donc pas nécessairement conformes aux ratios des spécifications matérielles, bien qu'en pratique ils soient souvent assez similaires. Vous spécifiez également une capacité que vous souhaitez et un prix d'offre maximum global par unité.
• Amazon propose deux stratégies d'allocation de flotte ponctuelle. La stratégie lowPrice sélectionne une seule configuration et autant d'instances de celle-ci que nécessaire, et elle sélectionne la configuration avec le prix le plus bas. Par exemple, supposons que vous ayez besoin de 11 unités de capacité et que vous ayez défini un poids de 1 pour m4,2xlarge et 2 pour m4,4xlarge. La stratégie de prix le plus bas vous donnera soit 11 instances m4,2xlarge, soit 6 instances m4,4xlarge, selon la valeur la moins chère. L'autre stratégie, appelée stratégie diversifiée, alloue des parts égales de la capacité globale aux différents types d'instances, ce qui signifierait dans ce cas 6 m4,2xlarge instances et 3 m4,4xlarge instances. Notez que dans les deux cas, Amazon limite le montant maximum que vous payez par unité à votre grand prix global maximum.
• La flotte ponctuelle lance également des instances de remplacement si une instance particulière est résiliée, le type d'instance de remplacement lancé dépendant de la stratégie utilisée.

Envisagez d'utiliser des groupes d'autoscaling pour les instances ponctuelles de longue durée exécutant des charges de travail prédéfinies.

• Bien que les groupes d'autoscaling aient été conçus à l'origine pour gérer une capacité de trafic variable, il est possible d'avoir un groupe d'autoscaling de taille fixe un. L'avantage de placer votre instance spot dans un tel groupe d'autoscaling est qu'Amazon relancera automatiquement l'instance si elle est interrompue pour des raisons de prix, de capacité ou pour d'autres raisons.
• Il est possible d'avoir un stockage persistant de sorte que, lorsque la nouvelle instance spot est lancée, elle récupère les données à partir de l'endroit où l'instance spot précédente l'a vérifiée.
• L'un des principaux défis liés à l'utilisation de groupes d'autoscaling de cette manière est que toutes les actions personnalisées que vous effectuez lors du lancement (ou de la relance) doivent être placées dans les données utilisateur du script et ne peuvent pas être exécutées via des scripts distincts. Cette automatisation supplémentaire nécessite généralement un investissement supplémentaire et peut n'être utile qu'une fois que vous avez réglé les autres détails du processus.
• L'utilisation de groupes de mise à l'échelle automatique conjointement avec CloudFormation peut être utile pour gérer les mises à niveau ou les modifications apportées à votre configuration.

Gardez à l'esprit que les marchés au comptant sont très difficiles à prévoir. Le but de l'examen de l'historique des prix des instances au comptant n'est pas de pouvoir prédire avec précision les prix futurs, mais d'avoir une idée de l'incertitude, de la variabilité et de la comparaison des prix.

Comprendre comment interpréter l'historique des prix des instances au comptant.

• Une mesure utile est le prix moyen de l'instance sur un horizon de temps raisonnablement long. Il s'agit du tarif que vous payez pour les instances ponctuelles de longue durée pour lesquelles vous enchérissez suffisamment haut pour que votre instance ne soit pas interrompue. Cependant, gardez également à l'esprit que de nouveaux pics peuvent se produire sur des marchés au comptant qui n'ont jusqu'à présent pas connu de pics.
• Une autre mesure utile est la valeur maximale du prix au comptant. Il s'agit du prix au-dessus duquel vous auriez besoin d'avoir une enchère pour qu'une instance spot de longue durée s'exécute en continu.
• Pour les instances ponctuelles utilisées pour exécuter des charges de travail temporaires avec un calendrier flexible, identifiez d'abord le temps nécessaire pour exécuter la charge de travail. Identifiez ensuite le minimum, la moyenne et le maximum du prix total que vous paieriez pour l'instance spot sur des périodes de cette durée. Le maximum représente le pire des cas (c'est-à-dire le scénario si vous enchérissez pour l'instance au pire moment possible) tandis que le minimum représente le meilleur scénario.
• Dans la console Amazon EC2, vous pouvez accéder à l'historique de tarification des instances Spot pendant une période variable, allant de 1 jour à 3 mois. Assurez-vous de consulter l'historique sur 3 mois afin d'avoir une idée plus claire des tendances des prix à plus long terme.

Comparez l'historique des prix des instances ponctuelles par zone de disponibilité au sein d'une région.

• Le graphique d'historique de tarification des instances ponctuelles d'Amazon vous permet d'examiner les historiques de tarification des instances ponctuelles pour la même configuration dans toutes les zones de disponibilité d'une région.
• Vous pouvez trouver des zones de disponibilité «voyous», où les prix des instances au comptant sont soit systématiquement plus élevés, soit soumis à des variations de prix beaucoup plus soutenues.
• Une autre information utile que vous pouvez obtenir en examinant plusieurs zones de disponibilité est de voir comment les pics de prix sont corrélés entre les zones de disponibilité. Si les pics de prix se produisent généralement à des moments différents dans différentes zones de disponibilité, vous pouvez obtenir une architecture assez robuste en répartissant vos instances ponctuelles entre les zones de disponibilité. Si, en revanche, les pics de prix dans différentes zones de disponibilité se produisent en même temps, alors toutes vos instances spot peuvent baisser ensemble.

Comparez les prix des instances au comptant par type d'instance (classe d'instance, taille et génération).

• Pour les instances réservées et à la demande, le prix évolue de manière linéaire en fonction de la taille au sein d'une classe d'instances. Ce n'est pas nécessairement vrai pour les instances au comptant, bien que cela se rapproche souvent de la vérité pour les petites instances avec des prix stables.
• Les ratios des prix au comptant entre les différentes classes d'instances peuvent également être différents des ratios des prix à la demande.
• En général, les prix sont plus volatils pour les instances plus importantes, car le plus petit nombre d'instances rend les prix plus sensibles aux offres individuelles. De plus, pour les types d'instances plus grands, les fluctuations de prix ont tendance à durer plus longtemps que les petits spots. Notez que cela inverse une tendance observée dans les premières années d'AWS, où les instances plus grandes avaient des prix très stables (principalement parce que très peu de gens étaient au courant de leur existence) et les instances plus petites avaient plus de fluctuations de prix.
• Les prix ont tendance à être les plus stables pour la classe d'instances M, un peu moins stables pour la classe d'instances C et les moins stables pour la classe d'instances R.
• Les instances d'ancienne génération, telles que les instances m2, ont tendance à être assez bon marché et moins volatiles si elles sont toujours disponibles sur le marché au comptant. Le type d'instance m2 est difficile à migrer rapidement car il ne prend pas en charge la nouvelle virtualisation utilisée par EC2 (appelée hvm) mais ne prend en charge que l'ancienne virtualisation (pv). Par conséquent, les personnes qui utilisent des AMI hvm ne peuvent pas passer aux instances m2 lorsque les prix spot augmentent pour leurs types d'instances préférés. Si votre architecture peut gérer le passage aux instances m2, envisagez de les utiliser car elles peuvent vous faire économiser beaucoup d'argent et réduire la volatilité de vos instances.
• Spot Bid Advisor d'Amazon fournit des conseils sur les économies de prix moyennes et la probabilité d'être surenchéri, ventilés par classe d'instance et séparément pour chaque région. Cela peut être une référence utile à consulter en plus d'examiner manuellement l'historique et les tendances des prix des instances au comptant.

Comprenez comment votre propre demande peut affecter les prix au comptant.

• Amazon limite généralement le nombre de demandes d'instances ponctuelles pour chaque classe d'instances qu'un utilisateur donné peut effectuer, afin d'éviter que de nouveaux utilisateurs ne perturbent par inadvertance le marché au comptant en exigeant un grand nombre d'instances. Malgré cela, il est possible pour un seul utilisateur de perturber les marchés au comptant.
• En général, plus le nombre d'instances que vous demandez est élevé, plus vous devez vous préoccuper de votre propre effet sur le marché au comptant.
• Pour les types d'instances plus volumineux, le nombre total d'instances sur le marché a tendance à être plus petit. Par conséquent, il est plus facile de perturber le marché en plaçant quelques offres. En fait, même la capacité totale est souvent plus petite. Par exemple, l'instance m4,10xlarge fait 20 fois la taille de l'instance m4.large, mais le nombre d'instances de ce type disponibles sur le marché spot est inférieur à 0,50 du nombre d'instances de type m4.large.
• Si toutes les instances que vous demandez sont du même type d'instance et dans la même zone de disponibilité, vous êtes plus susceptible d'affecter le prix que si vos demandes d'instance sont réparties sur plusieurs zones de disponibilité.

Prenez des mesures pour rendre le lancement d'instances ponctuelles plus rapide et plus efficace.

• Créez des scripts qui combinent la création de l'instance spot avec l'installation des applications pertinentes sur celles-ci afin qu'elles puissent être prêtes à exécuter votre charge de travail ou à se connecter à votre frontend dès le lancement. Ceci est particulièrement important pour les instances ponctuelles de courte durée, mais peut également être important pour les instances ponctuelles de longue durée, car une instance ponctuelle peut être interrompue à tout moment et peut donc devoir être recréée.
• Si les instances ponctuelles servent une interface, ajoutez l'étape les connectant à l'équilibreur de charge frontal dans le script de lancement. Effectuez des vérifications d'état et des tests de charge avant de vous connecter à l'équilibreur de charge.

Découvrez comment accélérer le processus de lancement.

• Si vous utilisez vos applications personnalisées, envisagez de créer une AMI personnalisée sur laquelle votre application est préinstallée. Le principal inconvénient est que cette AMI doit être tenue à jour chaque fois que vous mettez à jour votre application, et également mise à jour pour les corrections de bogues d'autres packages.
• Au lieu d'installer des packages à partir de leurs référentiels sources, envisagez de stocker les packages dans un emplacement S3 dans la région où vous créez vos instances, afin que votre processus de téléchargement soit plus rapide. Envisagez également de pré-construire tous les jars ou exécutables et de télécharger directement ces jars pré-construits sur vos instances ponctuelles.

Pour les instances ponctuelles de courte durée qui exécutent périodiquement des charges de travail prédéfinies, incluez la résiliation automatique.

• Exécutez ces scripts à partir d'une instance EC2 dans la même région pour minimiser les problèmes de connectivité. Si le script est exécuté quotidiennement, placez-le dans la tâche cron pour ce jour-là.
• Mettez fin aux instances ponctuelles une fois la charge de travail terminée et une fois que tous les journaux et enregistrements ont été enregistrés en dehors des instances ponctuelles.
• Mettez fin aux instances ponctuelles si elles ne répondent plus.
• Si le processus devrait être de courte durée, arrêtez les instances ponctuelles après un certain délai, même si le processus n'est pas terminé. Vous pouvez également envoyer une notification à un humain pour savoir pourquoi le processus prend si longtemps.
• Disposez d'une notification ou d'un plan de secours pour les autres erreurs associées aux instances ponctuelles, par exemple, l'échec du lancement ou l'arrêt prématuré des instances ponctuelles.

Surveillez les avis de résiliation et agissez en conséquence. Amazon propose des avis de résiliation d'instance spot de deux minutes. Ces notifications peuvent être détectées en surveillant un point de terminaison sur l'instance ponctuelle elle-même. Vous pouvez utiliser ces informations pour déconnecter normalement l'instance de l'équilibreur de charge, puis arrêter et contrôler l'instance en douceur.

Assurez-vous que lorsque vous utilisez fréquemment des scripts qui lancent des instances ponctuelles, vous utilisez une AMI et un paramètre de lancement où le volume EBS associé est défini pour être supprimé à la fin de l'instance.

Passez à une architecture plus définie avec AWS lorsque cela est possible et où l'investissement en vaut la peine.

• Plutôt que d'exécuter des scripts personnalisés à partir de votre propre instance pour le lancement et l'arrêt, utilisez les groupes d'autoscaling AWS, les configurations de lancement, les scripts de données utilisateur et CloudFormation.

Surveillez vos coûts d'instances ponctuelles.

• Dans votre console EC2 en ligne, vous pouvez obtenir une ventilation des coûts d'instance par région, zone de disponibilité, type d'instance et option d'achat. En particulier, vous pouvez filtrer pour n'afficher que les coûts des instances ponctuelles et regrouper par type d'instance et région pour voir combien coûtent vos instances ponctuelles.
• Configurez une alerte de facturation dans votre compte racine pour commencer à envoyer vos données à Amazon CloudWatch. Configurez ensuite des alertes de facturation pour vous alerter des énormes pics de coûts. Notez que CloudWatch ne ventile pas les coûts par option d'achat (il ne rapporte que les coûts EC2 globaux), mais il peut quand même aider à détecter d'énormes pics de coûts dus aux pics de prix dans les instances ponctuelles.

Vérifiez régulièrement votre console ec2.

• Vérifiez si vous avez des demandes ouvertes ou actives dont vous n'êtes pas au courant ou que vous n'aviez pas l'intention d'avoir.
• Vérifiez si vous avez des instances EC2 que vous ne pensez pas devoir avoir.
• Vérifiez si vous avez un excès de volumes EBS non associés à une instance EC2.
• Vérifiez l'historique de tarification des instances ponctuelles pour les types d'instances EC2 où vous utilisez régulièrement des instances ponctuelles.

Accédez par programmation aux informations sur l'utilisation des instances ponctuelles.

• Vous pouvez avoir les informations d'instance spot écrites sur S3 et installer des scripts Python dans AWS Lambda pour détecter automatiquement les nouveaux fichiers S3, comparer avec les anciens fichiers S3 et détecter si les instances ont été résiliées et si leurs prix dépassent des seuils spécifiques ou ont augmenté nettement.
• Amazon est en retard d'environ 3 heures lors de l'écriture des données sur S3, vous ne serez donc pas immédiatement informé des événements de cette façon. Il est particulièrement utile pour identifier une augmentation soutenue des prix au comptant sur lesquels vous pouvez ensuite agir à loisir en changeant le type d'instance. Il est idéal dans les cas où vous avez des instances de longue durée pour lesquelles vous avez fixé un prix d'offre élevé parce que vous êtes opposé à une interruption, mais vous souhaitez toujours être averti si le prix a été constamment élevé pendant un certain temps afin que vous puissiez effectuer la transition. vers un type d'instance ou une zone de disponibilité différent

Pensez à utiliser cloudyn. C'est une startup qui aide les entreprises à surveiller leurs coûts de cloud.