Le Blog Amazon Web Services
Top 5 des conseils opérationnels pour AWS Outposts
Nos clients sont enthousiastes à l’idée d’utiliser AWS Outposts pour bénéficier des services et fonctionnalités AWS on-premises, pour les applications qui nécessitent une faible latence, un traitement local des données ou un stockage local pour répondre aux exigences de résidence des données. Lorsque vous déployez AWS Outposts dans vos centres de données ou vos installations de colocation, vous assumez des responsabilités supplémentaires pour vous assurer que vos Outposts fonctionnent de manière efficace et efficiente. Dans cet article, Nous allons partager cinq conseils opérationnels qui faciliteront votre gestion d’AWS Outposts.
Que vous envisagiez (article en anglais) AWS Outposts ou que vous travailliez déjà avec, vous vous demandez sûrement :
- Comment puis-je surveiller les éventuelles défaillances matérielles d’AWS Outposts et mettre en œuvre des remédiations spécifiques ?
- Comment puis-je surveiller et optimiser l’utilisation des ressources d’AWS Outposts ?
- Je peux configurer un Outpost avec un ensemble de types d’instances au moment de la commande. Que se passe-t-il si je dois modifier la taille des instances en fonction de l’évolution de l’activité de l’entreprise ?
- AWS Outposts s’appuie sur une connexion dépendante de sa Région mère pour la gestion et la surveillance. Comment puis-je prévenir les éventuelles interruptions de réseau qui pourraient empêcher AWS Outposts de communiquer avec la Région mère via le lien de service ?
- Comment puis-je refacturer les différentes équipes de mon organisation en fonction de leur consommation réelle d’AWS Outposts ?
En tant que Technical Account Manager, j’accompagne les clients qui utilisent AWS Outposts. Ces questions m’ont été posées lors de nos discussions et j’ai pensé qu’il serait utile de les partager avec un public plus large.
Surveillance des éventuelles défaillances matérielles
Dans le cadre du modèle de responsabilité partagée AWS, AWS est responsable de la protection de l’infrastructure qui exécute tous les services proposés dans le cloud AWS. Cette infrastructure est composée du matériel, des logiciels, de la mise en réseau et des installations qui exécutent les services cloud AWS. Cela s’applique à AWS Outposts, tout comme à une région AWS. Si AWS détecte un problème irréparable avec le matériel hébergeant des instances Amazon EC2 exécutées sur votre Outpost, nous vous enverrons des alertes pour les instances concernées. Vous trouverez plus de détails sur la façon dont nous maintenons l’infrastructure d’AWS Outposts dans notre documentation.
Au-delà de ce dont AWS est responsable, nous vous recommandons de surveiller de près les éventuelles défaillances matérielles également de votre côté et en particulier celles concernant vos applications exécutées sur EC2, ceci afin de mettre en place une stratégie de remédiation.
Nous vous conseillons par exemple de surveiller l’erreur de type « System Status Check » qui se produirait sur votre AWS Outposts à l’aide d’Amazon CloudWatch. Amazon EC2 signale une erreur de type « System Status Check » en cas de problème avec l’hôte sous-jacent exécutant votre instance. L’une des raisons de cette défaillance de l’hôte peut-être un problème matériel.
Vous pouvez consulter la documentation EC2 pour une explication complète et la procédure de surveillance des erreurs « System Status Check » ainsi que cet article spécifique détaillant les options de remédiation possibles que vous pouvez implémenter.
Surveillance de la capacité d’AWS Outposts à l’aide d’Amazon CloudWatch
Dans le cadre du modèle de responsabilité partagée AWS, les clients sont responsables de la gestion et de la planification de l’utilisation de la capacité d’AWS Outposts. Vous êtes responsable de la surveillance de la consommation de capacité de calcul et de stockage ainsi que de la prévision des besoins d’extension de capacité et du délai associé. Pour surveiller la capacité d’AWS Outposts, nous vous recommandons d’utiliser Amazon CloudWatch.
Sur notre blog, nous proposons deux exemples différents pour mettre en œuvre ce type de surveillance. Un scénario simple basé sur un tableau de bord CloudWatch et une notification Amazon SNS lorsque la limite de capacité approche, et un autre scénario plus avancé (article en anglais) où, en plus de cette surveillance, nous expliquons comment appliquer une stratégie AWS Identity and Access Management (IAM) restrictive afin d’empêcher la création de nouvelles ressources sur votre AWS Outposts. Celles-ci peuvent être personnalisées pour mieux répondre à vos besoins spécifiques.
Modification des types d’instances Amazon EC2 sur AWS Outposts
Lorsqu’un AWS Outposts est commandé, il est livré avec un ensemble prédéfini de types d’instances configurées en fonction du modèle que vous avez sélectionné. Toutes nos configurations sont décrites sur notre page de tarification.
Maintenant, imaginez un Outpost ayant pour nom « OP-AWSBLOG” et qui serait configuré par défaut avec 4 m5.24xlarge. Une fois les Outposts livrés, si vous décidez que vous avez besoin de types d’instances m5.12xlarge au lieu de m5.24xlarge, vous pouvez demander à AWS de modifier votre configuration après l’installation. Pour demander un changement de configuration, il vous suffit d’ouvrir une demande de support auprès de notre support technique AWS.
Il n’y a pas de limite en termes de fréquence à laquelle vous pouvez modifier votre configuration. La logique globale de conversion est que 4 m5.24xlarge pourraient éventuellement être convertis en une variété de configurations de type d’instance au sein de la même famille m5. Cette configuration peut être modifiée en 8 m5.12xlarge, ou 24 m5.4xlarge.
Dans tous les cas, si vous souhaitez modifier votre configuration, vous devez vous adresser au support technique et collaborer avec ce dernier afin d’évaluer quel changement de configuration est possible en fonction des caractéristiques de votre Outposts.
Surveillance de la connexion AWS Outpost aux régions AWS
Lors de la mise en place d’AWS Outposts, une connexion appelée « lien de service » est créée connectant votre Outpost à la région AWS sélectionnée aussi appelée région d’accueil Outposts. Le lien de service est un ensemble chiffré de connexions VPN qui sont utilisées chaque fois que l’outpost communique avec la région choisie.
La plupart des applications s’exécutent de manière optimale sur AWS Outpost lorsque le lien de service est stable et disponible. Vous pouvez surveiller sa disponibilité et prendre des mesures en cas de perturbation.
En résumé, il est important que vous surveilliez la disponibilité de cette liaison de service et que vous soyez en mesure d’agir en cas de perturbation.
De notre côté, lorsque nous détectons qu’il y a un problème de connectivité avec le lien de service, nous effectuons les actions suivantes :
- Nous vous adressons un ticket de support
- Nous publions un événement dans le Personal Health Dashboard (PHD)
- Nous envoyons une notification par e-mail à l’adresse e-mail root du compte AWS
De votre côté, vous devez prendre en compte ces événements et agir en fonction de votre canal de communication favori. Soit en exploitant Amazon CloudWatch si vous souhaitez vous baser sur les évènements que nous publions dans le PHD, ou bien il faudra vous assurer que le ticket ou l’email qui vous seront adressés seront bien réceptionnés et traités par vos équipes.
Dans le tableau ci-dessous, vous trouverez les caractéristiques de ces événements, qui vous aideront à les identifier :
| Canal de communication | Titre ou objet de l’événement |
|---|---|
| Personal Health Dashboard (PHD) | Outpost service link down |
| Notification par e-mail | [ACTION REQUIRED] AWS Outposts Connectivity lost to AWS Region {{region}} |
Suivi de la consommation des ressources et mise en place de la refacturation
Vous pouvez acheter la capacité Outposts pour une durée de 3 ans et choisir entre trois options de paiement : « paiement de l’intégralité » ou « partiel des frais initiaux » ou « aucun paiement au départ ». Si vous choisissez l’option de paiement partiel ou aucun paiement au départ, les frais mensuels seront dus sur la période de 3 ans.
Le principe étant de déterminer les heures de calcul utilisées sur l’Outposts, puis de définir comment appliquer les coûts de l’Outposts liés à cette utilisation.
Pour ce faire il faudra utiliser le Rapport d’utilisation et de coût AWS. Pour l’activer, veuillez vous reporter au guide de l’utilisateur « Création de rapports de coûts et d’utilisation« .
Une fois que vous avez généré le rapport, vous devrez comprendre où trouver les informations relatives à votre consommation AWS Outposts.
Pour cela, nous avons élaboré une liste de requêtes spécifiquement pour Outpost disponibles dans sur notre page AWS Well-Architected Labs.
Il existe actuellement deux requêtes :
Conclusion
Cet article illustre comment vous pouvez prévenir d’éventuelles défaillances matérielles et de connectivité qui pourraient survenir sur votre AWS Outposts. Pour savoir comment prévenir d’autres types de défaillance sur AWS Outposts, lisez le livre blanc (document en anglais) « AWS Outposts High Availability Design and Architecture Considerations ». Vous pouvez également consulter la liste de contrôle de dépannage réseau et la section Entretien d’Outposts de notre documentation.
Nous avons enfin partagé des meilleures pratiques sur d’autres aspects opérationnels tels que le contrôle de la capacité, le suivi de la consommation de ressources et l’évolution des types d’instances. Pour en savoir plus, veuillez consulter la section Surveiller vos Outpost de notre documentation.
Article contribué par Benjamin Lecoq, Senior Technical Account Manager dans les équipes AWS France.