Elastic Cloud Computing (EC2) d'Amazon est la pièce maîtresse d'Amazon Web Services, la solution d'infrastructure basée sur le cloud la plus utilisée au monde.[1][2] EC2 offre un large éventail d'options qui, prises ensemble, sont très puissantes. D'un autre côté, il est extrêmement compliqué pour les débutants, et ne pas bien le comprendre peut signifier dépenser beaucoup plus pour l'infrastructure. Cette page décrit en détail comment mieux gérer vos instances EC2 pour gérer les coûts. Le public cible de cette page est constitué d’individus ou d’entreprises dont les coûts annuels d’EC2 sont compris entre 10 000 et 200 000 dollars. Compte tenu de la complexité du matériel, il ne serait pas logique d'investir du temps et de l'énergie dans l'optimisation des coûts à un coût annuel inférieur à 10 000 dollars. Si vos coûts annuels dépassent 200 000 dollars, il est probablement judicieux d’engager l’équivalent d’un ingénieur de développement à plein temps pour gérer vos coûts et vos instances Amazon EC2.

Première partie de neuf:
Comprendre si EC2 est fait pour vous

  1. 1 Comprenez que EC2 n'est pas le moins cher. En termes de rapport qualité / prix pour le seul matériel, EC2 est loin d'être l'alternative la moins chère du marché. Même la comptabilisation de la fiabilité du service ne la rend pas la plus compétitive.[3][4][5][6]
    • Si vous prévoyez d'importants transferts de données (sortants de votre serveur), Amazon Web Services peut s'avérer très coûteux par rapport à divers fournisseurs de serveurs privés virtuels (VPS) tels que Linode et Digital Ocean. En effet, AWS facture environ 9 cents par Go, soit environ 90 $ / To, un montant que la plupart des fournisseurs de VPS offrent gratuitement avec leurs plans mensuels minimalistes (environ 5 $ ou 10 $ par mois).[7][8][9] En d'autres termes, si vous disposez d'un site Web simple qui génère beaucoup de trafic, il est peu probable qu'AWS soit le bon choix pour vous.
    • En termes de performances matérielles, Amazon EC2 a historiquement offert des performances inférieures à celles de Linode et Digital Ocean pour les serveurs de même prix et de spécifications matérielles similaires (en termes de vCPU et de mémoire). En partie, cela est dû aux différences dans l'architecture sous-jacente.[10][11]
  2. 2 Comprendre certains des principaux avantages des solutions EC2 et des solutions d'infrastructure en tant que service (IaaS) en général.[12][11][13]
    • Une infrastructure flexible et évolutive que vous pouvez adapter à vos besoins changeants.
    • Possibilité de déployer des instances et d'apporter des modifications à l'architecture par programmation.
    • La disponibilité des instances ponctuelles.
    • Un grand nombre de services gérés qui, utilisés ensemble dans la même région, ne coûtent rien (ou très peu) dans le transfert de données.
  3. 3 Gardez à l'esprit que vous n'avez pas à utiliser EC2 simplement parce que vous utilisez d'autres services Amazon. Par exemple, un certain nombre de personnes utilisent Amazon S3 pour un stockage de masse bon marché, flexible et redondant, mais ne font pas fonctionner leurs machines sur EC2.

Deuxième partie de neuf:
Comprendre les types d'instance

  1. 1 Comprendre les différents aspects de la description d'un type d'instance Amazon.[14][15]
    • Un nom typique comporte trois parties: une lettre décrivant la classe d’instance (R, M, C, T, G, D, I, P, X), un nombre décrivant la génération (1, 2, 3, 4, 5), et une chaîne décrivant la taille au sein de cette classe et génération d'instance (petit, moyen, grand, xlarge, 2x grand, 4x, grand, 8x, 10, grand, 16, grand). Par exemple, "r3.4xlarge" est le type d'instance R, génération 3 et taille 4xlarge.
    • Une manière simple de se souvenir de la taille est la suivante: "large" signifie 2 vCPU, "xlarge" signifie 4 vCPU et nxlarge signifie 4n vCPUs. Un vCPU est un "hyperthread" dans le jargon d'Intel, le fabricant de puces.[16] On peut naïvement penser qu’elle correspond à un cœur sur un ordinateur portable ou de bureau grand public; Cependant, physiquement parlant, les puces Intel utilisées par les générations récentes d’instances EC2 ont deux vCPU (ou deux threads) par cœur. Si vous comparez aux serveurs physiques existants, vous devez multiplier par deux le nombre de cœurs de serveurs physiques pour obtenir le numéro de vCPU approprié.[17][18][19]
    • La classe d'instance donne le rapport entre les différentes parties des spécifications d'instance. Le rapport le plus pertinent est le rapport entre les vCPU et la RAM. Par exemple, la classe d'instance C (où C signifie optimisé pour le calcul) offre 1 vCPU pour chaque (environ) 2 Go de RAM. Les ratios exacts diffèrent légèrement entre les différentes générations, car les instances ultérieures font un meilleur travail en extrayant plus de valeur du matériel.
    • Les générations diffèrent également dans certaines des fonctionnalités supplémentaires qu'elles offrent. Par exemple, les classes C, M et R de troisième génération (C3, M3 et R3) ont toutes des SSD locaux, mais pas la quatrième génération (C4, M4 et R4).
    • Pour une classe et une génération d'instances données, les différences de taille signifient différentes quantités de chaque ressource, mais dans la même proportion (notez que certains aspects périphériques des spécifications, tels que le stockage et le débit SSD, ne sont pas linéairement modifiés). Pour les instances à la demande et réservées, les coûts sont linéairement ajustés à la taille dans un type et une génération d'instance donnés. Pour les instances ponctuelles, les coûts peuvent ne pas être linéairement ajustés car ils sont déterminés par l'offre et la demande, mais pour les types d'instances les plus courants, la mise à l'échelle est proche de linéaire.
    • Pour un type et une génération d'instance donnés, il est généralement possible de modifier un type de réservation (une fois la réservation déjà effectuée) pour réaffecter la capacité entre différentes tailles. Par exemple, c3.2xlarge représente deux fois la capacité de c3.xlarge, il est donc possible de changer une réservation de 5 c3.2xlarge en 10 c3.xlarge, ou en 3 c3.2xlarge et 4 c3.xlarge.
    • N'oubliez pas que les noms des types d'instance n'ont pas de sens plus profond que la simple description intuitive des spécifications. Ainsi, par exemple, C est "optimisé pour le calcul", mais tout cela signifie que le rapport entre les vCPU et la mémoire est plus en faveur des vCPU qu'en mémoire.Il n'y a pas d'optimisation spécifique au calcul spécifique au-delà de ce que les spécifications révèlent déjà.
    • Le débit du réseau n'est pas assez linéaire.
  2. 2 Comprendre les ratios des trois classes d'instance principales. Notez que les ratios précis varient légèrement selon les générations.
    • La classe d'instance R est optimisée en mémoire et offre le plus de mémoire par vCPU (c'est-à-dire le moins de vCPU par unité de mémoire). Le ratio est d'environ 7,5 Go / vCPU.
    • La classe d'instance M est intermédiaire. Il offre 3,75 Go / vCPU.
    • La classe d'instance C est optimisée pour le calcul et offre le moins de mémoire par vCPU (c'est-à-dire le plus grand nombre de vCPU par unité de mémoire). Le ratio est d'environ 1,875 Go / vCPU.
  3. 3 Comprendre les capacités maximales disponibles des instances, afin d'identifier les limites de la mise à l'échelle verticale.
    • Classe d'instance M: M3 n'atteint que m3.2xlarge (30 Go, 8 vCPU). M4 monte à m4.16xlarge (256 Go, 64 vCPU) mais manque de SSD.
    • Classe d'instance R: R3 passe à R3.8xlarge (244 Go, 32 vCPU). R4 monte à r4.16xlarge (488 Go, 64 vCPU) mais manque de SSD.
    • Classe d'instance C: C3 atteint c3.8xlarge (60 Go, 32 vCPU). C4 monte à c4.8xlarge (60 Go, 36 vCPU) mais manque de SSD. C5 (qui sera déployé à partir de décembre 2016) passera à c5.18xlarge (144 Go, 72 vCPU) et manquera également de SSD.
  4. 4 Comprenez les contraintes supplémentaires que vous pouvez rencontrer en fonction du système d'exploitation et de l'AMI que vous souhaitez utiliser.
    • La plupart des remarques de cet article, ainsi que la plupart des discussions en ligne sur EC2, portent sur le cas d’utilisation des instances Linux / Unix sans coût de licence.
    • Vous pouvez également déployer des instances EC2 avec d'autres systèmes d'exploitation tels que Windows. Ces instances coûtent plus cher (en conservant le type d'instance et l'option d'achat constante). Ils offrent également moins de flexibilité en changeant de réservation. Il n'y a pas de frais de licence distincts; Amazon paie les licences et les inclut dans les coûts de l'instance.[20]

Troisième partie de neuf:
Comprendre les exigences de l'application

  1. 1 Exécutez votre application sur certaines instances pour voir comment elle utilise diverses ressources (informatique, mémoire, stockage local, réseau) et quels sont les goulots d’étranglement.
    • L'utilisation du processeur et du réseau est stockée dans des métriques dans Amazon CloudWatch, le système d'Amazon pour l'enregistrement des métriques. Ils sont également accessibles dans la console EC2.
    • L'utilisation de la mémoire est ne pas traçable à l'aide de la console Amazon EC2. Par conséquent, vous devrez suivre l'utilisation de la mémoire dans votre application ou via un autre processus de consignation de la mémoire que vous installez sur votre instance. Un tel processus recommandé par Amazon (et pouvant exporter vers CloudWatch) est collectd.[21]
    • Gardez à l'esprit que les données d'utilisation du processeur et du réseau ne sont plus disponibles dans la console EC2 après la fin de vos instances. Cependant, ils peuvent être affichés dans les métriques CloudWatch (essentiellement, la raison pour laquelle vous ne pouvez pas les voir dans la console EC2 est que l'instance n'y figure plus).
    • Les métriques CloudWatch sur l'utilisation du processeur et du réseau (ainsi que toute autre mesure personnalisée que vous exportez) sont conservées pendant une période de 15 mois, à partir d'une fenêtre mobile de 2 semaines auparavant. Depuis que le changement a été introduit récemment, vous ne pouvez obtenir les métriques que pour les trois derniers mois.[22]
  2. 2 Identifiez les variables clés affectant l'utilisation des ressources de vos applications.
    • Pour les applications frontales, une variable clé affectant l'utilisation des ressources est le niveau de trafic. Identifiez comment votre utilisation des ressources (mémoire et ressources informatiques) varie avec les différents niveaux de trafic. Les niveaux de trafic peuvent fluctuer de façon quotidienne et saisonnière et présenter des tendances séculaires (tendances à long terme). Vous pouvez souhaiter simuler artificiellement des charges de trafic plus élevées en utilisant des outils tels que Gatling[23] ou des services tels que Blitz.io.
    • La taille des données utilisées par votre application peut également varier, indépendamment des niveaux de trafic. Par exemple, si votre application sert un site Web, les mesures relatives à la taille du site Web (nombre de pages, nombre de comptes d'utilisateurs distincts) peuvent affecter l'utilisation des ressources. Ces métriques ne varient pas beaucoup à court terme, mais ont tendance à augmenter avec le temps. Vous devrez donc extrapoler à partir de l'utilisation actuelle ou simuler artificiellement une taille de site Web plus importante ou davantage de comptes d'utilisateurs.
  3. 3 Identifiez les interactions et les compromis entre l'utilisation des ressources dans votre code.
    • Pour les applications qui s'exécutent sur la machine virtuelle Java (JVM), plus la mémoire est proche de la pleine utilisation, plus le temps et les ressources consacrés au nettoyage de la mémoire sont importants.[24] Cela peut entraîner une montée en flèche de l’utilisation du processeur et une augmentation de la latence. Des phénomènes similaires peuvent se produire pour les applications exécutées dans d'autres environnements.
    • Il est donc particulièrement important de suivre et de comprendre la cause initiale des goulots d’étranglement. Le simple fait de voir l'utilisation du processeur monter en flèche à 100% n'implique pas que le problème soit dû à un processeur insuffisant. Le problème pourrait être dû à une mémoire insuffisante, ce qui obligerait les ressources du processeur à être récupérées.
  4. 4 Si vous envisagez d'exécuter des applications identiques sur plusieurs instances (généralement pour les serveurs frontaux desservant des charges élevées), explorez les compromis entre la mise à l'échelle horizontale (en utilisant plusieurs instances) et la mise à l'échelle verticale (en utilisant des instances plus importantes). [25] Par exemple, déterminez s'il est préférable d'utiliser quelques instances xlarge, ou deux fois plus de grandes instances.[26]
    • Limites (en faveur de la mise à l'échelle horizontale): la mise à l'échelle verticale a des limites assez strictes: vous pouvez utiliser une limite supérieure assez faible pour la taille des instances EC2 (voir la partie 2, étape 3). À l'échelle de l'infrastructure d'AWS, les limites de la mise à l'échelle horizontale sont beaucoup plus importantes (bien que votre compte puisse avoir ses propres limites définies par AWS, vous pouvez demander une augmentation de la limite). Si vous avez besoin de 1 000 vCPU de calcul, vous devez utiliser au moins une mise à l'échelle horizontale, car même les limites de la mise à l'échelle verticale ne vous permettent d'atteindre que 64 vCPU.
    • Plus de divisibilité et donc plus de précision dans la capacité (en faveur de la mise à l'échelle horizontale): L'utilisation de types d'instances plus petits vous permet d'affiner le nombre d'instances par rapport à la capacité de trafic. Par exemple, supposons que vous sachiez que votre besoin de trafic nécessite 9 instances c3.large pour servir. En supposant qu'il n'y ait pas de mémoire partagée ou d'autres problèmes de ressources partagées, si vous souhaitez utiliser des instances de c3.xlarge, vous en aurez besoin de cinq, car vous ne pouvez pas obtenir 4,5 instances. . Si vous utilisiez des instances de c3.2xlarge, vous en auriez besoin de trois, gaspillant ainsi l'équivalent de trois c3.large dans les ressources de calcul. Si vous utilisiez des c3.4xlarge, vous en auriez besoin de deux, gaspillant ainsi l'équivalent de sept c3.large. Notez que cela s'applique à la fois si vous avez des besoins de trafic très fixes et si vous avez des besoins de trafic variables, mais un bon système de mise à l'échelle automatique.
    • Disponibilité améliorée (mixte, mais généralement en faveur de la mise à l'échelle horizontale): la mise à l'échelle horizontale permet une plus grande disponibilité, car si une instance tombe en panne, votre capacité est temporairement réduite. En revanche, avec la mise à l'échelle verticale, toute instance descendante nuit grandement à la capacité. D'un autre côté, la mise à l'échelle horizontale peut réduire la disponibilité si les instances, de petite taille, ont moins de mémoire tampon pour gérer une seule demande intensive en termes de calcul et s'arrêtent temporairement lors de la réception d'une telle demande.
    • Stabilité des coûts (mixte, mais généralement en faveur de la mise à l'échelle horizontale): en particulier pour les instances ponctuelles, les coûts sont plus stables pour les petites instances en raison du plus grand nombre de personnes qui les utilisent. Cependant, ce n'est pas uniformément vrai.
    • La memoire partagée (en faveur de la mise à l'échelle verticale): si votre application utilise beaucoup de données en mémoire communes pour traiter les requêtes, la mise à l'échelle verticale est meilleure car elle permet de partager les données en mémoire. Par exemple, si vous fournissez un moteur de recherche et que vous stockez tous les index dans la RAM, et que les index utilisent 6 Go de données. Si vous utilisez deux instances de m3.large, vous dupliquez les 6 Go sur les deux ordinateurs et vous ne disposez que de 1,5 Go (= 7,5 à 6) pour effectuer des calculs sur chaque instance. Par contre, si vous utilisez un m3.2xlarge, il vous reste 9 Go de mémoire pour effectuer le calcul. Même si vous ne stockez pas toutes les données en mémoire, mais les interrogez depuis un magasin de données, la mémoire partagée peut toujours vous aider en vous permettant de mettre en cache des ressources. Notez que la considération de la mémoire partagée est également pertinente pour décider entre les classes d'instance, par exemple, déterminer si M ou C est plus logique.

Partie quatre de neuf:
Comprendre les régions AWS et les zones de disponibilité

  1. 1 Comprendre le concept d'une région AWS. Les régions AWS sont des noms donnés aux clusters de centres de données Amazon Web Services situés à proximité. En décembre 2016, il existe douze régions AWS (à l'exception d'AWS GovCloud):[27] quatre aux États-Unis, cinq en Asie-Pacifique, deux en Europe et un en Amérique du Sud. D'autres régions AWS devraient être ajoutées prochainement en Europe.[28]
    • Le temps d'aller-retour dans une région AWS est d'environ 2 millisecondes.
    • Le transfert de données entre différents services AWS au sein d'une région, y compris vers et depuis des instances EC2, est sensiblement moins cher que le transfert de données inter-régions, mais pas totalement gratuit.
    • Les prix diffèrent selon la région AWS, mais sont les mêmes dans une région AWS donnée.
  2. 2 Comprendre le concept d'une zone de disponibilité AWS (AZ).[29]
    • Les AZ sont des subdivisions dans les régions AWS. Le nombre d'AZ par région varie de 2 à 4.
    • Les zones de disponibilité sont toutes isolées les unes des autres, de sorte que les défaillances d’une zone de disponibilité (comme les incendies ou les pannes d’électricité) ne devraient pas nuire au fonctionnement de l’autre AZ.
    • L'AZ pour une instance EC2 est spécifiée au moment de la création de l'instance.
    • Alors que les prix des instances à la demande et des instances réservées sont les mêmes dans les différentes zones de disponibilité d’une région, les marchés des instances ponctuelles sont différents pour les différentes zones de disponibilité.
    • Les réservations étaient auparavant liées à une zone de disponibilité particulière. A partir de septembre 2016, les réservations peuvent être étendues à la zone de disponibilité ou à la portée de la région. Si la portée de la région est donnée, la réservation n'est pas liée à une zone de disponibilité.[30] Les instances réservées avant celle-ci ont une étendue de zone de disponibilité mais peuvent être modifiées en étendue de région.

Partie cinq de neuf:
Comprendre comment Elastic Block Storage (EBS) affecte les coûts

  1. 1 Comprenez les deux types de stockage sur disque offerts par Amazon pour ses instances EC2.[31][32][33]
    • Elastic Block Storage (EBS) est un volume de stockage à haut débit répliqué dans la zone de disponibilité. Un EBS donné peut être associé à au plus une instance EC2 à la fois, mais l'instance à laquelle il est attaché peut être modifiée. EBS peut persister même lorsque l'instance est arrêtée et (si spécifié au lancement) même après la fin de l'instance.
    • Le stockage d'instance est un stockage local associé à une instance particulière. Il offre une entrée / sortie plus rapide mais sans redondance et sans persistance.
    • Selon l'Amazon Machine Image (AMI) utilisé lors du lancement d'une instance, le volume racine de l'instance peut être un magasin EBS ou un magasin d'instances. Les anciens types d'instances sont appelés instances de démarrage EBS ou instances sauvegardées par EBS.
    • Les nouvelles instances de génération (C4, M4, R4 et C5) n'offrent pas de stockage d'instance. Ils ne supportent qu'EBS.
  2. 2 Comprendre les implications financières de l'utilisation d'instances sauvegardées par EBS.[34]
    • Le coût d'une instance EBS dépend de sa taille, comme spécifié lors de la création du volume.
    • EBS facture également les E / S. Il existe plusieurs types d'EBS avec différents modèles de tarification. Pour l'EBS habituel, des frais d'E / S se produisent chaque fois qu'une E / S se produit.Pour gp2, conçu pour un débit élevé, vous êtes facturé pour le débit provisionné, plutôt que pour l'utilisation réelle, mais avec un système de roulement de crédits.
    • Pour les instances basées sur EBS, les volumes EBS persistent même lorsque l'instance est arrêtée. Pour les instances de longue durée, les coûts EBS sont relativement faibles comparés aux coûts d'instance. Toutefois, pour les instances exécutées quelques heures par jour et arrêtées le reste du temps, les volumes EBS peuvent représenter une fraction significative des coûts globaux.
    • Selon les paramètres utilisés lors du lancement de l'EBS, le volume EBS peut ou non persister une fois l'instance terminée. Si le volume persiste, cela peut entraîner des fuites de coûts importantes si les volumes EBS ne sont pas effacés.
    • Si vous configurez fréquemment de nouvelles instances et que vous ne mettez pas automatiquement fin à l'EBS à la fin de l'instance, EBS peut entraîner des fuites de coûts importantes.
  3. 3 Comprendre le fonctionnement des instantanés EBS. Un instantané EBS stocke un instantané du contenu actuel de l'EBS vers S3.[35][36]
    • Alors qu'un EBS est lié à une zone de disponibilité, l'instantané EBS est disponible dans toute la région, de sorte qu'il peut être récupéré dans n'importe quelle zone de disponibilité de la région. Il peut également être transféré entre les régions.
    • Bien que les instantanés EBS soient stockés dans S3, les métadonnées pour les récupérer sont stockées dans le système EBS. Ils ne sont pas accessibles directement en tant qu'objets S3. Ainsi, même si les données sous-jacentes sont stockées de manière très redondante, les instantanés ne sont fiables qu'à 99,9% (contre 99,99% + pour S3).
    • Les instantanés EBS peuvent être transférés entre les régions. Les frais habituels pour le transfert de données entre régions s'appliquent.[37]
    • Le stockage pour les instantanés EBS est incrémentiel, de sorte que si un EBS est cliché plusieurs fois, seul le contenu modifié entre les instantanés est stocké. Le processus de suppression, cependant, est intelligent et reconstruit les instantanés ultérieurs avant de supprimer les précédents.[32]

Partie six des neuf:
Comprendre les options d'achat

  1. 1 Les instances à la demande sont les plus coûteuses mais les plus faciles à utiliser.[38]
    • Les instances à la demande peuvent être accélérées à tout moment et sont facturées en fonction du type d'instance et de la durée d'exécution de l'instance.
    • Les instances à la demande peuvent être arrêtées et redémarrées à tout moment. L'instance n'est pas facturée tant qu'elle est arrêtée. Le stockage local (le cas échéant) de l'instance est détruit et toute adresse IP publique associée à l'instance est libérée (sauf s'il s'agit d'une adresse IP élastique). Cependant, le stockage de blocs Elastic Block Storage (EBS) associé à l'instance est conservé et AWS continue de le facturer.
    • Les instances à la demande peuvent être résiliées par l'utilisateur à tout moment. Une fois l'instance à la demande terminée, le Elastic Block Storage correspondant peut ou non être supprimé. Cela dépend des paramètres spécifiés au lancement.
    • AWS n'arrêtera pas ou ne terminera pas les instances à la demande, bien que les instances puissent parfois être indisponibles en raison d'une dégradation du matériel ou d'autres problèmes liés au centre de données.
    • Les instances à la demande sont également éligibles pour la protection de la terminaison, ce qui rend un peu plus difficile la suppression accidentelle de l'instance.
  2. 2 Les instances ponctuelles sont sensiblement moins chères que les instances à la demande.
    • Au moment de la création, l'utilisateur qui crée l'instance spécifie le prix spot maximal en plus de la spécification de la zone de disponibilité et du type d'instance.
    • Tant que le prix au comptant actuel pour cette zone de disponibilité et le type d'instance sont inférieurs au prix spot maximal, l'instance peut être créée et ne sera pas terminée. Cependant, dès que le prix actuel dépasse le prix de l'instance ponctuelle, l'instance est terminée.
    • Le prix effectivement facturé par unité de temps est le prix au comptant actuel plutôt que le prix au comptant maximal.
    • Les instances ponctuelles ne peuvent pas être arrêtées. Ils ne peuvent être résiliés que par l'utilisateur ou par AWS pour des raisons de prix.
    • Le prix au comptant d’une instance ponctuelle ne peut pas être modifié après la création de l’instance.
    • L'historique des prix des instances ponctuelles par région, zone de disponibilité et type d'instance est disponible sur Amazon et peut être utilisé pour prendre des décisions en matière d'enchères intelligentes.
    • Le nombre d'instances ponctuelles pouvant être créées par un utilisateur donné pour un type d'instance et une zone de disponibilité donnés est limité. Ces limites sont généralement beaucoup plus strictes que les limites associées au nombre total d'instances, en raison des ravages que les gens peuvent créer en créant de manière irresponsable des cas ponctuels avec des prix au comptant élevés (et en faisant monter les prix globaux). Cependant, ces limites peuvent généralement être augmentées sur demande, sous réserve de la disponibilité des capacités.[39]
    • Pour certains types d'instances et certaines zones de disponibilité, en particulier le type d'instance I, la mise en place de instances ponctuelles peut prendre beaucoup de temps en raison de la faible capacité globale, malgré un prix au comptant généralement faible.
  3. 3 Les réservations peuvent être effectuées pour 1 ou 3 ans, avec trois types de plans de paiement: pas d'avance, partielle de départ, et tout en avant.[40]
    • Certains aspects d'une réservation ne peuvent pas être modifiés après la réservation. Il s'agit notamment de la période de réservation, du type de plan de paiement, du système d'exploitation, du type de location (dédié par rapport à la valeur par défaut) et de la région.
    • Pour les instances réservées standard (RI standard), la classe et la génération d'instance (telles que R3, C3, M3, M4) ne peuvent pas être modifiées.
    • Pour les RI standard, vous pouvez changer la taille de l'instance au sein de la même classe d'instance et de la même génération. La taille de l'instance peut être modifiée tout en conservant la même capacité globale. Par exemple, une réservation pour trois instances de m3.xlarge peut être modifiée en une réservation pour une instance de m3.2xlarge et une instance de m3.xlarge.
    • Si vos réservations ont une portée de zone de disponibilité, vous devez modifier la zone de disponibilité ou passer à la portée de la région pour utiliser la réservation dans une autre zone de disponibilité.
    • Notez que le redimensionnement des instances, l'obtention de la portée de la région ou la modification de la zone de disponibilité n'est pas possible pour les réservations liées à des systèmes d'exploitation ayant des coûts de licence, tels que les systèmes d'exploitation Windows.
    • La réservation n'est liée à aucune instance particulière. En fait, les instances auxquelles s'appliquent les réservations sont créées de la même manière que les instances à la demande. La façon dont les réservations fonctionnent est qu’à chaque heure où la facturation est calculée, les instances à la demande existantes utilisées sont comparées aux réservations actuellement actives. Si l'une des réservations s'applique, les prix réduits basés sur les réservations s'appliquent aux instances. Sinon, le prix total à la demande s'applique.
    • Pour les instances réservées convertibles (RI convertibles), la classe d'instance et la génération peuvent être modifiées. Si la nouvelle configuration coûte plus cher que l'ancienne, vous payez la différence, si cela coûte moins cher, AWS ne vous rembourse pas la différence, mais vous pouvez vendre la capacité excédentaire sur le marché des instances réservées.

Partie sept de neuf:
Travailler sur une architecture robuste, indépendante de l'instance

  1. 1 Évitez la mentalité de serveur de flocon de neige.[41] Investissez du temps et des efforts supplémentaires dans l'écriture de scripts (à l'aide d'outils tels qu'Ansible ou Chef) qui vous permettent, avec une seule commande, de déployer de nouvelles instances pour vos applications. Rendez ce script suffisamment flexible pour pouvoir déployer des instances à la demande et ponctuelles avec le même script.
  2. 2Si votre application gère des charges variables à partir du trafic Web en temps réel, placez les instances derrière un équilibreur de charge élastique (ELB).
  3. 3 Examinez la mise à l'échelle automatique et utilisez-la si possible. La mise à l'échelle automatique vous permet d'augmenter la capacité de l'instance en temps réel en réponse aux augmentations de charge. C'est un petit travail supplémentaire à mettre en place.
  4. 4 Conservez toutes les données critiques à long terme en dehors des instances EC2 individuelles (avec l'exception possible des instances spéciales dédiées aux magasins de données, que vous sauvegardez régulièrement). Dans la mesure du possible, utilisez S3 ou des bases de données pour toute donnée à long terme.
  5. 5 Vos scripts doivent pouvoir gérer les mises à jour de votre application en douceur. Ils peuvent gérer les mises à jour de l'une des manières suivantes:
    • Les applications elles-mêmes peuvent être mises à jour sur une instance de production en direct sans avoir à mettre cette instance hors ligne. Bien que cela puisse être vrai pour certains types de mises à jour, vous ne devriez pas vous fier uniquement à cela pour que l'application puisse être mise à jour.
    • De nouvelles instances avec le code d'application mis à jour sont déployées et connectées à l'équilibreur de charge, puis les anciennes instances sont déconnectées de l'équilibreur de charge et terminées. Pour ce type de mise à jour, la capacité est temporairement plus grand pendant la mise à jour. Notez que la capacité d'instance en excès sera hors de la capacité réservée et, par conséquent, les nouvelles instances, si elles sont à la demande, seront facturées à des taux de demande complets pendant la transition.
    • Chacune des instances existantes est mise à jour. Si la charge de production actuelle peut être gérée par moins que l'ensemble complet d'instances, les instances peuvent être mises à jour une par une: chaque instance est déconnectée de l'équilibreur de charge, mise à jour, puis reconnectée à l'équilibreur de charge. Pour ce type de mise à jour, la capacité est temporairement plus petit pendant la mise à jour. Si les charges de production varient selon l'heure de la journée, ce type de mise à jour peut être effectué à un moment où la charge de production est faible.
  6. 6Définissez des alarmes pour que les équilibreurs de charge puissent détecter trop peu d’hôtes en bonne santé, des modèles de trafic inhabituels ou un grand nombre d’erreurs.
  7. 7 Répartissez les instances sur plusieurs zones de disponibilité dans une région pour plus de robustesse contre les dommages à une zone de disponibilité particulière. Toute zone de disponibilité dans une région donnée peut être activée pour un ELB lié à cette région.
  8. 8Utilisez les vérifications de l'état de la route 53 et les basculements pour la redondance inter-régions dans la distribution en direct.

Partie huit des neuf:
Mise en place du suivi et de la surveillance

  1. 1 Dans la console Amazon EC2 (section "Rapports"), vous pouvez obtenir des rapports sur les coûts Amazon EC2 (cela n'inclut pas certains coûts de transfert de données) et l'utilisation de l'instance réservée. Vous pouvez répartir les informations par région, zone de disponibilité, classe d'instance, type d'instance et option d'achat et examiner l'utilisation sur une base horaire ou quotidienne. Les données ne circulent pas immédiatement et peuvent être retardées de 24 à 48 heures.
  2. 2 Votre compte AWS a accès aux données de facturation qui fournissent la ventilation complète des coûts. Configurez une alerte de facturation pour que les données commencent à être envoyées à Amazon CloudWatch. Vous pouvez ensuite configurer d'autres alertes à l'aide de CloudWatch.[42] Les données CloudWatch sont fournies sous forme de points de données toutes les quelques heures, mais ne comprennent pas de ventilation détaillée.
  3. 3 A tout moment, vous pouvez télécharger une ventilation détaillée par heure et par type de service depuis votre compte AWS. Ces données ont généralement jusqu’à 6 heures de retard, bien qu’elles puissent être encore plus tardives pour certains services.

Partie neuf des neuf:
Faire et améliorer vos décisions d'achat

  1. 1 Rassemblez tous les facteurs et commencez à décider. Vous devez déterminer la combinaison d'instances que vous utiliserez par classe d'instance, type d'instance, région, zone de disponibilité et option d'achat.
  2. 2 Idéalement, visez à ce que toutes vos instances soient des instances réservées ou ponctuelles. Il ne devrait y avoir aucune capacité à la demande sans réserve, sauf de manière très temporaire, lors du lancement de nouvelles instances pour remplacer celles qui existent déjà.
    • Cependant, comme les réservations impliquent un engagement à long terme, il peut être judicieux d'utiliser des instances à la demande pour les applications critiques où les détails des types d'instance et de la capacité requis ne sont pas encore clairs.
    • En général, les réservations sont les plus rentables pour des instances plus exotiques (telles que les instances D, I ou P), mais sont également les plus risquées pour ces instances, car elles ont des cas d'utilisation très spécifiques.
  3. 3 Continuez à surveiller les coûts au-delà de tout ce que vous surveillez. Assurez-vous que les coûts font partie des données que vous consultez régulièrement. Revoyez vos décisions en matière de capacité en fonction de ce que vous continuez de découvrir.