Une nouvelle région neutre au niveau carbone à Montréal
Une semaine après l'ouverture de la région Séoul, l'infrastructure Amazon Web Services continue de grandir avec l'annonce de la nouvelle région AWS à Montréal, Québec, au Canada, dans l’année à venir.
Cette région sera carbo-neutre et alimentée presque entièrement par de l’énergie hydro-électrique propre et renouvelable. La future région de Montréal (Canada) offrira aux partenaires et aux clients d’AWS la possibilité d’exécuter leurs activités et de stocker leurs données au Canada.
La liste des régions AWS ne fait que commencer à s'agrandir, puisque qu'au moins 3 nouvelles régions sont attendues sur 2016.
- USA Est – Virginie du Nord (2006)
- USA Ouest – Californie du Nord (2009)
- USA Ouest – Oregon (2011)
- GovCloud – USA (2011, région réservée aux institutions, principalement américaines)
- Amérique du Sud – São Paulo (2011)
- Europe – Irlande (2007)
- Europe – Francfort (2014)
- Asie-Pacifique – Singapour (2010)
- Asie-Pacifique – Tokyo (2011)
- Asie-Pacifique – Sydney (2012)
- Chine - Beijing (2013, région nécessitant un compte dédié)
- Asie-Pacifique – Pékin (2014)
- Asie-Pacifique – Séoul (janvier 2016)
- Inde (2016)
- Ohio (2016)
- Canada (2016, région neutre au niveau carbone)
- Angleterre (2017)
Retrouvez l'article original sur le blog AWS (en) et sur notre focus sur l'infrastructure Amazon Web Services.
Découvrez Slack Integration Blueprint pour AWS Lambda.
Vous avez certainement déjà entendu parler de Slack, le service de messagerie professionnelle entrée depuis peu dans le cercle très fermé des "licornes", ces startups valorisées plus d'un milliard d'euros. Un des avantages de Slack réside dans sa capacité de s'intégrer avec de nombreux outils en ligne, comme GitHub, DropBox, Google Drive ou encore Heroku.
Amazon Web Services n'est bien entendu pas en reste, puisque il existe depuis le mois de décembre 2015 une collection de modèles d'intégrations entre Slack et AWS Lambda. Ce dernier vous permettra de créer des bots qui répondront à vos commandes et pousseront des notifications depuis Amazon CloudWatch.
Dans le cas par exemple où votre team ChatOps (dans un channel Slack) souhaite monitorer un groupe d’Auto Scaling via Amazon CloudWatch et prendre la décision d'ajouter une instance EC2 directement via Slack, l'information suivra ce schéma :
Retrouvez l'article original sur le blog AWS (en) et plus d'infos dans notre dossier sur AWS Lambda.
Réservez des instances Amazon Web Services sur des tranches horaires
Il est possible de réduire les coûts associés à vos architectures Amazon Web Services en "réservant" des instances. Ces réservations d'instances se traduisent par un engagement de durée de votre part pouvant aller de 1 an à 3 ans. En contrepartie, et en fonction du mode de paiement retenu, Amazon Web Services vous propose des réductions pouvant aller jusqu'à 70% du prix On-Demand de vos instances EC2 ou de vos bases de données RDS.
Cette semaine, le système de réservation d'instances se complexifie encore un peu et propose de réserver des instances sur des planches horaires bien précises.
Cette option se justifie dans le cas de besoins ponctuels se produisant de manière récurrente: des générations de rapports tous les premiers lundi du mois, des exports PDF tous les soirs à 22H, des pics de trafic tous les mercredis après-midi etc.
Dans ce modèle, l'engagement est par défaut de 12 mois, et permet de réduire les coûts de 5 à 10 % par rapport à une tarification On-Demand.
Retrouvez l'article original sur le blog AWS (en) et plus d'infos dans notre dossier sur les réservations d'instances
Les ID de ressource EC2 sont maintenant plus longs
Amazon Web Services héberge de très nombreux clients à travers le monde. Tellement que les instances EC2 et les EBS arrivent en pénurie d'ID ! Pas de panique, la transition vers un nouveau format d'ID plus long est enclenché : le nouveau format d'identifiant suivra le modèle du format actuel, mais il sera plus long -<17 caractères>, p. ex. « i-1234567890abcdef0 » pour les instances EC2 ou « vol-1234567890abcdef0 » pour les volumes EBS.
Si les instances EC2 peuvent désormais proposer des ID plus long, les EBS eux devront attendre avril. Il est donc recommandé de demander des ID longs dès à présent dans la console (EC2 > Resource ID length management) afin de vérifier que cela ne pose pas de soucis particuliers à votre infrastructure avant décembre 2016, date à laquelle les instances EC2 prendront pas défaut les ID de 17 caractères.
A noter cependant qu'après cette date, il sera possible de conserver un ID plus court sur demande. Ces changements ne s'appliquent par ailleurs qu'aux nouvelles ressources : Une fois qu'un ID (long ou court) a été attribué à une ressource, cet ID ne change jamais. Une ressource créée avec l'ancien format d'ID gardera toujours son ID plus court, et une ressource créée avec le nouveau format gardera toujours son ID plus long, même si vous décidez de revenir au format court.
Nous aurons l'occasion de revenir plus en détail sur ce changement d'ID ainsi que ses conséquences possibles sur vos infras.
Retrouvez l'article original sur le blog AWS (en) et plus d'infos dans notre dossier sur les réservations d'instances
Rejoignez vous aussi la conversation !
Questions, remarques, suggestions... Contactez-nous directement sur Twitter sur @osones !
Pour discuter avec nous de vos projets, nous restons disponibles directement via contact@osones.com !
Rejoignez VOTRE groupe LinkedIn dès maintenant : Utilisateurs Francophones d'Amazon Web Services (AWS).
Kevin MESSY
Découvrez les derniers articles d'alter way
- kubevpn
- Kubernetes 1.32
- re:Invent 2024 : AWS mise tout sur l'IA pour son Cloud
- OVHcloud Summit 2024 : L’innovation au cœur d’un cloud souverain et performant
- Big Data & AI Paris 2024 : L'IA au cœur de toutes les transformations.
- Un retour vers l'open-source ? Vos outils DevOps préférés et leurs equivalents open-source.