Comment optimiser vos coûts Amazon EC2?

Vous pouvez obtenir des rapports sur les coûts amazon ec2 — 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.

Elastic Cloud Computing (EC2) d'Amazon est la pièce maîtresse d'Amazon Web Services, la solution d'infrastructure en tant que service basée sur le cloud la plus utilisée au monde. EC2 offre un large éventail d'options qui, prises ensemble, sont très puissantes. D'un autre côté, c'est aussi extrêmement compliqué pour les débutants, et ne pas le comprendre correctement peut signifier dépenser beaucoup plus en infrastructure. Cette page décrit en détail comment faire un meilleur travail de gestion de vos instances EC2 pour garder les coûts gérables. Le public cible de cette page est constitué de particuliers ou d'entreprises dont les coûts annuels EC2 attendus sont dans la fourchette 7460€-149000€. Compte tenu de la complexité du matériel ici, il n'est peut-être pas judicieux d'investir du temps et de l'énergie dans l'optimisation des coûts à un coût annuel inférieur à 7460€ Si vos coûts annuels dépassent 149000€, il est probablement judicieux d'embaucher l'équivalent d'un ingénieur des opérations de développement à temps plein pour gérer vos instances et vos coûts Amazon EC2.

Partie 1 sur 9: comprendre si ec2 est fait pour vous

1
Comprenez que ec2 n'est pas le moins cher. En termes de rapport qualité-prix pour le matériel seul, EC2 est loin d'être l'alternative la moins chère du marché. Même la prise en compte de la fiabilité du service ne le rend pas le plus compétitif en termes de coûts.
- Si vous vous attendez à avoir beaucoup de transfert de données (sortant de votre serveur), les services Web Amazon peuvent être assez 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, ce qui correspond à environ 67€/To, un montant que la plupart des fournisseurs de VPS offrent gratuitement avec leurs forfaits mensuels minimalistes (environ 3,70€ ou 7,50€ par mois). En d'autres termes, si vous avez 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 des serveurs de même prix et de spécifications matérielles similaires (en termes de processeurs virtuels et de mémoire). Cela est dû en partie à des différences dans l'architecture sous-jacente.
2
Découvrez certains des principaux avantages d'ec2 et des solutions d'infrastructure en tant que service (iaas) en général.
- Une infrastructure flexible et évolutive que vous pouvez adapter à vos besoins changeants.
- Capacité à déployer des instances et à apporter des modifications à l'architecture par programmation.
- La disponibilité des instances ponctuelles.
- Un grand nombre de services gérés qui, s'ils sont utilisés ensemble dans la même région, ne coûtent rien (ou très peu) en transfert de données.
3

Gardez à l'esprit que vous n'êtes pas obligé d'utiliser ec2 simplement parce que vous utilisez d'autres services amazon. Par exemple, un certain nombre de personnes utilisent Amazon S3 pour un stockage en masse bon marché, flexible et redondant, mais n'exécutent pas leurs machines sur EC2.

Partie 2 sur 9: comprendre les types d'instances

1
Comprendre les différents aspects de la description d'un type d'instance amazon.
- 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 d'instance et de cette génération (small, medium, large, xlarge, 2xlarge, 4xlarge, 8xlarge, 10xlarge, 16xlarge, 32xlarge). Par exemple, "r3,4xlarge" correspond au type d'instance R, à la génération 3 et à la taille 4xlarge.
- Un moyen simple de se rappeler ce que signifie la taille est: "large" signifie 2 vCPU, "xlarge" signifie 4 vCPU et n xlarge signifie 4n vCPU. Un vCPU est un «hyperthread» dans le jargon d'Intel, le fabricant de puces. Il peut naïvement être considéré comme correspondant à un cœur sur un ordinateur portable ou de bureau grand public; cependant, physiquement parlant, les puces Intel utilisées par les dernières générations d'instances EC2 ont deux vCPU (ou deux threads) par cœur. Si vous comparez avec des serveurs physiques existants, vous devez multiplier le nombre de cœurs de serveurs physiques par deux pour obtenir le bon nombre de vCPU.
- La classe d'instance donne le rapport entre les différentes parties des spécifications d'instance. Le ratio le plus pertinent est le ratio vCPU/RAM. Par exemple, la classe d'instance C (où C signifie optimisé pour le calcul) offre 1 vCPU pour chaque (environ) 2 gigaoctets 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 par 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 d'instance et une génération données, les différences de taille signifient simplement des quantités différentes de chaque ressource, mais dans la même proportion (notez que certains aspects périphériques des spécifications, tels que le stockage SSD et le débit, ne sont pas mis à l'échelle de manière linéaire). Pour les instances à la demande et réservées, les coûts évoluent de manière linéaire avec la taille au sein d'un type d'instance et d'une génération donnés. Pour les instances ponctuelles, les coûts peuvent ne pas évoluer de manière linéaire car ils sont déterminés par l'offre et la demande, mais pour les types d'instances les plus courants, l'échelle est proche de la linéaire.
- Pour un type d'instance et une génération donnés, il est généralement possible de changer de type de réservation (une fois la réservation déjà effectuée) pour réallouer de la capacité entre différentes tailles. Par exemple, c3,2xlarge est le double de 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.
- Gardez à l'esprit que les noms des types d'instances n'ont pas de signification plus profonde que de simplement fournir une description intuitive des spécifications. Ainsi, par exemple, C est "optimisé pour le calcul" mais tout cela signifie que le rapport des vCPU à la mémoire est plus en faveur des vCPU qu'en mémoire. Il n'y a pas d'optimisation spécifique au calcul au-delà de ce que les spécifications révèlent déjà.
- Le débit du réseau n'évolue pas tout à fait de manière linéaire.
2
Comprendre les ratios des trois classes d'instances principales. Notez que les ratios précis varient un peu d'une génération à l'autre.
- 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 processeur virtuel (c'est-à-dire le plus grand nombre de processeurs virtuels par unité de mémoire). Le ratio est d'environ 1 875 Go/vCPU.
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 va jusqu'à seulement m3,2xlarge (30 Go, 8 vCPU). M4 va jusqu'à 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 va jusqu'à 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
Comprenez les contraintes supplémentaires auxquelles vous pouvez être confronté en fonction du système d'exploitation et de l'AMI que vous avez l'intention d'utiliser.
- La plupart des remarques de cet article, ainsi que la plupart des discussions en ligne sur EC2, se concentrent sur le cas d'utilisation des instances Linux/Unix qui n'ont pas de coûts 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 maintenant le type d'instance et l'option d'achat constants). Ils offrent également moins de flexibilité avec les réservations changeantes. Il n'y a pas de frais de licence distincts; Amazon paie les licences et les inclut dans les coûts de l'instance.

Les coûts EBS sont assez faibles par rapport aux coûts d'instance — Pour les instances de longue durée, les coûts EBS sont assez faibles par rapport aux coûts d'instance.

Partie 3 sur 9: comprendre les exigences de l'application

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 les métriques d'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 n'est 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 journalisation de la mémoire que vous installez sur votre instance. L'un de ces processus recommandé par Amazon (et pouvant être exporté vers CloudWatch) est collectd.
- Gardez à l'esprit que les données d'utilisation du processeur et du réseau ne sont plus disponibles dans la console EC2 une fois vos instances terminées. 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 est plus répertoriée).
- Les métriques CloudWatch sur l'utilisation du processeur et du réseau (ainsi que toute autre métrique personnalisée que vous exportez) sont conservées pendant une fenêtre mobile de 15 mois, contre une fenêtre mobile de 2 semaines plus tôt. Étant donné que le changement a été introduit récemment, pour l'instant, vous ne pouvez obtenir que les métriques des trois derniers mois.
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 l'utilisation de vos ressources (mémoire et ressources de calcul) varie en fonction des différents niveaux de trafic. Les niveaux de trafic peuvent fluctuer quotidiennement et saisonnièrement et avoir des tendances séculaires (c'est-à-dire des tendances à long terme). Vous souhaiterez peut-être simuler artificiellement des charges de trafic plus élevées à l'aide d'outils tels que Gatling ou de services tels que Blitz.io.
- La taille des données utilisées par votre application peut également changer, indépendamment des niveaux de trafic. Par exemple, si votre application sert un site Web, les métriques liées à 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 grande ou plus de comptes d'utilisateurs.
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 votre mémoire est proche de sa pleine utilisation, plus le temps et les ressources sont consacrés au ramasse-miettes. 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 qui s'exécutent dans d'autres environnements.
- Par conséquent, il est particulièrement important de suivre et de comprendre quelle est 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 était dû à un processeur trop faible. Le problème peut provenir d'un manque de mémoire, ce qui force les ressources du processeur à passer au ramasse-miettes.
4
Si vous envisagez d'exécuter des applications identiques sur plusieurs instances (typique pour les frontaux servant des charges élevées), explorez les compromis entre la mise à l'échelle horizontale (en utilisant plus d'instances) et la mise à l'échelle verticale (en utilisant des instances plus grandes). Par exemple, déterminez s'il est préférable d'utiliser quelques instances xlarge ou deux fois plus d'instances volumineuses.
- Limites (en faveur de la mise à l'échelle horizontale): la mise à l'échelle verticale a des limites assez strictes: il existe une limite supérieure assez faible sur la taille des instances EC2 que vous pouvez utiliser (voir Partie 2, étape 3). Avec 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 limite). Si vous avez besoin de 1000 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 une meilleure précision de capacité (en faveur de la mise à l'échelle horizontale): l'utilisation de types d'instances plus petits vous permet d'ajuster plus finement le nombre d'instances à la capacité de trafic. Par exemple, supposons que vous sachiez que votre besoin de trafic aurait besoin de 9 instances c3.large pour servir. En supposant qu'il n'y ait pas de problèmes de mémoire partagée ou d'autres ressources partagées, si vous vouliez utiliser des instances c3.xlarge, vous en auriez besoin de 5, car vous ne pouvez pas obtenir 4,5 instances, gaspillant donc effectivement l'équivalent d'un c3.large dans ressources de calcul. Si vous utilisiez des instances c3,2xlarge, vous en auriez besoin de 3, gaspillant ainsi l'équivalent de trois c3.large en ressources de calcul. Si vous utilisiez des c3,4xlarge, vous en auriez besoin de 2, 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 que vous disposez d'un bon système d'autoscaling.
- 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é n'est temporairement réduite que légèrement. En revanche, avec la mise à l'échelle verticale, toute instance unique en baisse nuit beaucoup à la capacité. D'un autre côté, la mise à l'échelle horizontale peut réduire la disponibilité si les instances, étant petites, ont moins de mémoire tampon pour gérer une seule requête gourmande en calculs et diminuent temporairement lors de la réception d'une telle requête.
- Stabilité des coûts (mixte, mais généralement en faveur d'une mise à l'échelle horizontale): pour les instances ponctuelles en particulier, 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 de nombreuses données en mémoire courantes pour traiter les demandes, la mise à l'échelle verticale est préférable 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 jusqu'à 6 Go de données. Si vous utilisez deux instances m3.large, vous dupliquez les 6 Go sur les deux machines et il ne vous reste que 1,5 Go (= 7,5 - 6) pour effectuer le calcul sur chaque instance. En revanche, si vous utilisez un m3,2xlarge, il vous reste 9 Go de mémoire effective pour faire le calcul. Même si vous ne stockez pas toutes les données en mémoire, mais que vous les interrogez à partir d'un magasin de données, la mémoire partagée peut toujours vous aider en vous permettant de mettre en cache les ressources. Notez que la considération de la mémoire partagée est également pertinente pour décider entre les classes d'instances, par exemple,déterminer si M ou C a plus de sens.

Partie 4 sur 9: comprendre les régions AWS et les zones de disponibilité

1
Comprendre le concept d'une région AWS. Les régions AWS sont des noms donnés à des clusters de centres de données Amazon Web Services géographiquement proches. En avril 2020, il y avait douze régions AWS (hors AWS GovCloud): quatre en Europe, une au Canada, sept en Asie-Pacifique, cinq en Europe, une au Moyen-Orient et une en Europe du Sud. Des régions AWS supplémentaires devraient bientôt être ajoutées en Europe.
- Les temps d'aller-retour au sein d'une région AWS sont 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 nettement moins cher que le transfert de données entre 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
Comprendre le concept d'une zone de disponibilité AWS (AZ).
- Les zones de disponibilité sont des subdivisions au sein des régions AWS. Le nombre de AZ par région varie de 2 à 4.
- Les zones de disponibilité sont toutes isolées les unes des autres, de sorte que les pannes dans une zone de disponibilité (telles que les incendies ou les pannes d'électricité) ne devraient pas nuire au fonctionnement de l'autre zone de disponibilité.
- La zone de disponibilité d'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 réservées sont les mêmes dans les différentes zones de disponibilité d'une région, les marchés d'instances spot sont différents pour les différentes zones de disponibilité.
- Les réservations étaient auparavant liées à une zone de disponibilité particulière. À partir de septembre 2016, les réservations peuvent se voir attribuer une étendue de zone de disponibilité ou une étendue de région. Si l'étendue de la région est donnée, la réservation n'est pas liée à une zone de disponibilité. Les instances réservées auparavant ont une étendue de zone de disponibilité mais peuvent être modifiées en étendue de région.

Gardez à l'esprit que vous n'êtes pas obligé d'utiliser ec2 simplement parce que vous utilisez d'autres services amazon.

Partie 5 sur 9: comprendre comment le stockage par blocs élastiques (EBS) affecte les coûts

1
Comprenez les deux types différents de stockage sur disque qu'Amazon propose pour ses instances ec2.
- Elastic Block Storage (EBS) est un volume de stockage à haut débit répliqué dans la zone de disponibilité. Un EBS donné peut être attaché à 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 l'arrêt 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 aucune redondance et aucune persistance.
- Selon l'Amazon Machine Image (AMI) utilisée lors du lancement d'une instance, le volume racine de l'instance peut être soit un magasin EBS, soit un magasin d'instance. Les anciens types d'instances sont appelés instances de démarrage EBS ou instances basées sur EBS.
- Les instances de nouvelle génération (C4, M4, R4 et C5) n'offrent pas de stockage d'instance. Ils ne prennent en charge que l'EBS.
2
Comprenez les implications financières de l'utilisation d'instances basées sur ebs.
- 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 différents types d'EBS avec différents modèles de tarification. Pour l'EBS habituel, les frais d'E/S se produisent chaque fois que les E/S se produisent. Pour gp2, qui est 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 roulements de crédit.
- 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 assez faibles par rapport aux coûts d'instance. Cependant, pour les instances qui ne sont exécutées que 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 persister ou non une fois l'instance terminée. Si le volume persiste, cela peut entraîner des pertes de coûts importantes si les volumes EBS ne sont pas effacés.
- Si vous provisionnez fréquemment de nouvelles instances et que vous ne résiliez pas automatiquement l'EBS lors de la résiliation de l'instance, EBS peut entraîner des pertes de coûts importantes.
3
Comprendre le fonctionnement des instantanés EBS. Un instantané EBS stocke un instantané du contenu actuel de l'EBS dans S3.
- Alors qu'un EBS est lié à une zone de disponibilité, l'instantané EBS est disponible dans toute la région, il peut donc être récupéré dans n'importe quelle zone de disponibilité de la région. Il peut également être transféré d'une région à l'autre.
- Bien que les instantanés EBS soient stockés dans S3, les métadonnées permettant de 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 hautement redondante, les instantanés ne bénéficient que d'une fiabilité de 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.
- Le stockage des instantanés EBS est incrémentiel, de sorte que si un EBS est instantané 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.

Partie 6 sur 9: comprendre les options d'achat

1
Les instances à la demande sont les plus chères mais les plus faciles à utiliser.
- Les instances à la demande peuvent être lancé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 IP publique associée à l'instance est libérée (sauf s'il s'agissait d'une IP élastique). Cependant, l'Elastic Block Storage (EBS) associé à l'instance est conservé et AWS le facture toujours.
- Les instances à la demande peuvent être résiliées par l'utilisateur à tout moment. Une fois l'instance à la demande terminée, l'Elastic Block Storage correspondant peut ou non être supprimé. Cela dépend des paramètres spécifiés au lancement.
- AWS n'arrêtera ni ne mettra fin aux instances à la demande, bien que les instances puissent parfois devenir indisponibles en raison d'une dégradation du matériel ou d'autres problèmes de centre de données.
- Les instances à la demande sont également éligibles à la protection contre la résiliation, ce qui rend un peu plus difficile pour l'utilisateur la résiliation accidentelle de l'instance.
2
Les instances Spot sont nettement moins chères que les instances à la demande.
- Au moment de la création, l'utilisateur créant l'instance spécifie le prix spot maximum en plus de spécifier la zone de disponibilité et le type d'instance.
- Tant que le prix spot actuel pour cette zone de disponibilité et le type d'instance sont inférieurs au prix spot maximum, l'instance peut être créée et ne sera pas résiliée. Cependant, dès que le prix actuel dépasse le prix de l'instance spot, l'instance est résiliée.
- Le prix réellement facturé par unité de temps est le prix spot actuel plutôt que le prix spot maximum.
- Les instances Spot 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 spot d'une instance spot ne peut pas être modifié une fois l'instance créée.
- L'historique des prix des instances Spot par région, zone de disponibilité et type d'instance est disponible sur Amazon et peut être utilisé pour prendre des décisions d'enchères intelligentes.
- Il existe des limites au nombre d'instances ponctuelles pouvant être créées par un utilisateur donné pour un type d'instance et une zone de disponibilité donnés. 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 instances ponctuelles avec des prix au comptant élevés (et provoquant une flambée des prix globaux). Cependant, ces limites peuvent généralement être augmentées sur demande sous réserve de la capacité disponible.
- Pour certains types d'instances et zones de disponibilité, en particulier le type d'instance I, le lancement d'instances spot peut prendre beaucoup de temps en raison de la faible capacité spot globale, malgré un prix spot nominalement bas.
3
Les réservations peuvent être effectuées pour 1 ou 3 ans, avec trois types de plans de paiement: aucun paiement initial, partiel initial et tout initial.
- Certains aspects d'une réservation ne peuvent pas être modifiés une fois la réservation effectuée. 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é ou par défaut) et de la région.
- Pour les instances réservées standard (RI standard), la classe d'instance et la génération (telle que R3, C3, M3, M4) ne peuvent pas être modifiées.
- Pour les instances réservées standard, vous pouvez modifier 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 m3.xlarge peut être remplacée par une réservation pour une instance m3,2xlarge et une instance m3.xlarge.
- Si vos réservations ont une étendue de zone de disponibilité, vous devez changer de zone de disponibilité ou changer d'étendue de région pour utiliser la réservation dans une zone de disponibilité différente.
- Notez que le redimensionnement des instances, l'obtention de l'étendue de la région ou la modification de la zone de disponibilité n'est pas possible pour les réservations liées aux systèmes d'exploitation qui ont 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 effet, les instances auxquelles s'appliquent les réservations sont créées de la même manière que les instances à la demande. Le fonctionnement des réservations 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. Dans le cas contraire, le plein tarif à 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 elle coûte moins cher, AWS ne vous rembourse pas la différence, mais vous pouvez vendre la capacité excédentaire sur la place de marché des instances réservées.

Les coûts évoluent de manière linéaire avec la taille au sein d'un type d'instance — Pour les instances à la demande et réservées, les coûts évoluent de manière linéaire avec la taille au sein d'un type d'instance et d'une génération donnés.

Partie 7 sur 9: travailler sur une architecture robuste indépendante des instances

1

Évitez la mentalité de serveur de flocon de neige. 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 à la fois des instances à la demande et ponctuelles avec le même script.
2

Si 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

Étudiez l'autoscaling et utilisez-le si possible. L'autoscaling vous permet d'augmenter la capacité de l'instance en temps réel en réponse aux augmentations de charge. C'est un peu de travail supplémentaire à mettre en place.
4

Conservez toutes les données critiques de longue durée en dehors des instances ec2 individuelles (à l'exception potentielle des instances spéciales dédiées aux magasins de données, que vous sauvegardez périodiquement). Dans la mesure du possible, utilisez S3 ou des bases de données pour toutes les données de longue durée.
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 besoin de mettre cette instance hors ligne. Bien que cela puisse être vrai pour certains types de mises à jour, vous ne devez pas vous en remettre à la seule façon dont l'application peut être mise à jour.
- De nouvelles instances avec le code d'application mis à jour sont déployées et connectées à l'équilibreur de charge, et les anciennes instances sont ensuite déconnectées de l'équilibreur de charge et arrêtées. Pour ce type de mise à jour, la capacité est temporairement plus importante lors de la mise à jour. Notez que la capacité d'instance excédentaire tombera en dehors de la capacité réservée, et donc les nouvelles instances, si elles sont à la demande, seront facturées au plein tarif à la demande 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 réduite lors de 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

Définissez des alarmes pour que les équilibreurs de charge puissent détecter trop peu d'hôtes sains, des modèles de trafic inhabituels ou un grand nombre d'erreurs.
7

Répartissez les instances sur plusieurs zones de disponibilité au sein d'une région pour plus de robustesse contre les dommages causés à 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

Utilisez les vérifications d'état et les basculements de l'itinéraire 53 pour la redondance interrégionale dans la diffusion en direct.

Lisez aussi: Comment faire sauter les épinards?

Partie 8 sur 9: mise en place du suivi et de la surveillance

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 ventiler 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 n'arrivent pas immédiatement et peuvent être retardées de 24 à 48 heures.
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 afin que les données commencent à être envoyées à Amazon CloudWatch. Vous pouvez ensuite configurer plus d'alertes à l'aide de CloudWatch. Les données CloudWatch arrivent sous forme de points de données toutes les quelques heures, mais n'incluent pas de ventilation détaillée.
3

À tout moment, vous pouvez télécharger la répartition 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 retardées pour certains services.

Votre compte AWS a accès aux données de facturation qui fournissent la ventilation complète des coûts.

Partie 9 sur 9: prendre et améliorer vos décisions d'achat

1

Mettez tous les facteurs ensemble 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
Idéalement, visez à ce que toutes vos instances soient réservées ou ponctuelles. Il ne devrait y avoir aucune capacité à la demande non réservée, sauf très temporairement lors de la rotation de nouvelles instances pour remplacer celles existantes.
- Cependant, étant donné que les réservations impliquent un engagement à long terme, il peut être judicieux d'utiliser des instances à la demande à la place pour les applications critiques où les détails des types d'instances et de la capacité nécessaires ne sont toujours pas clairs.
- En général, les réservations offrent le plus d'économies pour les instances plus exotiques (telles que les instances D, I ou P) mais sont également les plus risquées pour celles-ci car ces instances ont des cas d'utilisation très spécifiques où elles sont précieuses.
3

Continuez à surveiller les coûts au-dessus de toutes les autres choses que vous surveillez. Assurez-vous que les coûts font partie des données que vous consultez régulièrement. Revoyez vos décisions de capacité en fonction de ce que vous continuez à découvrir.