AWS Summit 2019 à Paris

J’ai participé à la grande messe Française d’AWS à Paris : plus de 6000 participants, 80 talks, 70 exposants, les 3 étages du palais des congrès et pleins de sujets différents. Je me suis intéressés aux sujets bas niveaux (EC2, sécurité, coûts…) mais il y avait du machine learning, blockchain, kubernetes, bref tous les buzzwords actuels.
Les présentations réalisées par AWS sont en ligne.

23+ familles d’instances EC2, mais comment choisir ?

Par Arthur Petitpierre Slides
L’orateur commence la présentation avec un petit peu d’histoire sur l’évolution des services AWS : le nombre de type d’instance des EC2 entre 2007 et 2018 est passé de 1 à 175…
Au commencement, l’hyperviseur Xen était utilisé puis petit à petit, il a été modifié pour finalement être remplacé par un couple logiciel / matériel baptisé Nitro.
Cette architecture est utilisée depuis quelques années et est basée sur 3 composants principaux :

• Carte matérielle d’accélération des Entrées / Sorties à base de puces ASIC permettant, par exemple, le chiffrement des données à la volée des volumes EBS ;
• Puce de sécurité interdisant l’accès au BIOS depuis les EC2 et gérant les mises à jour des firmwares des différentes cartes ;
• Hyperviseur externalisé sur une puce dédiée pour allouer l’intégralité des processeurs aux clients.

Ensuite, la présentation s’est articulée autour des règles de nommages des types d’instances et comment les choisir.
Les dénominations suivent le pattern suivant :

avec :

• Famille : le type d’instance : M (Multi purpose, utilisation générale), C (Compute, calcul intensif), T (location de temps VCPU, voir ci dessous)
• Génération : version de la famille sélectionnée
• Capacité additionnelle :
  • “d” : stockage local ssd
  • “n” : carte graphique dédiée
• Taille : nombre de VCPU + RAM. Exemple xlarge : machine avec 4 vcpu et 16 Go de Ram

Les instances de type T ont la particularité d’être “volante” à la différence des autres : la VM allouée n’est pas figée sur un ou plusieurs processeur(s) d’un serveur mais peut changer de processeurs en fonction de la charge de la machine physique. Ainsi, c’est du temps VCPU qui est vendu et non un ou plusieurs coeurs dédiés : cela s’appelle de l’”over provisionning” et permet à AWS d’améliorer le taux d’utilisation des machines tout en offrant des VMs de faible performance idéal pour faire des POCs.
Il est possible d’utiliser des CPU de la marque AMD en choisissant des instances contenant la lettre “a” dans la spécificité : elles sont 10% moins chers et semblent un peu moins performante : exemple : M5a.12xlarge
Une autre architecture est également disponible : arm64 (le type de processeur généralement utilisé dans les smartphones, raspberry pi…) : A1.large.
NDLR : j’utilise souvent le site https://www.ec2instances.info/ pour connaitre les caractéristiques d’un type d’instance.
Plusieurs types d’achat de VM sont disponibles :

• On demand : le plus répandu, facturation à la seconde, le plus coûteux;
• Reserved instance : le client s’engage sur 1 an minimum et bénéficie de remise. Le paiement est effectué à l’achat;
• Spot : les VMs achetées peuvent être arrêtées par AWS à tout instant avec un délai de prévenance de 2 min (!!!) pour prioriser les demandes d’allocation des VM on demand. La contrepartie est une diminution du tarif jusqu’à 90%. Ce mode de fonctionnement n’est pas adapté à toute les architectures mais peut être utilisé sur des applications fortement résistantes aux pannes.

Pour terminer, comment choisir la bonne instance. Ici, pas de solutions miracles mais plusieurs bonnes pratiques : dans un premier temps, il faut mesurer l’utilisation actuelle des ressources puis choisir une instance plus grosse si les machines sont sous l’eau ou diminuer la capacité si elles sont sous utilisées. Ensuite, en fonction du cas d’utilisation (forte utilisation du stockage, calcul intensif, besoin d’une carte graphique…), voici un arbre d’aide à la décision : (désolé pour la qualité de la photo)

Top 5 Security Errors and How to Avoid Them.

Christophe Estebanez

Voici les erreurs les plus fréquentes :

• Pas de chiffrage des données : en cas de vol de base de données ou de volume EBS, tout le contenu est très facilement exploitable. En chiffrant, cela retarde beaucoup leurs utilisations. Il est très simple d’activer le chiffrement à la volée des données dans la console AWS;
• Pas de rotation des clés d’accès : en cas de vol d’une clé d’API, celle ci va pouvoir être utilisée pendant un moment pour instancier des VMs à l’insu du propriétaire pour miner du Bitcoin par exemple;
• Il y a au moins une bucket S3 exposée publiquement : la vigilance doit être accentuée afin de ne pas avoir de secrets stockés sur cet espace publique;
• Le compte root AWS est toujours actif : désactiver ce compte et créer des comptes administrateurs afin de limiter l’exploitation des ressources en cas de vol de compte;
• Le réseau par défaut n’est pas sécurisé et il n’est pas désactivé : la règle de manière générale est d’abord configurer les règles de security group (firewall AWS) puis de configurer l’applicatif et non l’inverse. En effet, le temps de changer le mot de passe par défaut de l’outil fraîchement instancié peut être suffisant à un attaquant pour en prendre le contrôle…

FinOps: Qu’attendez-vous pour optimiser vos coûts ?

Raphaël Haïk
FinOps est le nom de la discipline consistant à maîtriser puis optimiser les coûts sur les plateformes Cloud. L’idée est de connaître la répartition exacte selon les services utilisés et de se projeter dans l’avenir pour évaluer la variation du prix. A la différence d’une plateforme OnPrem dont les coûts sont plus facilement maîtrisable et surtout qui n’augmentent pas sans préavis, les dépenses sur une plateforme de type Cloud sont élastiques.
L’architecture mise en oeuvre définie bien sûr le tarif : instancier une EC2 pour héberger un traefik n’aura pas le même coût qu’un ALB (Load Balancer de niveau applicatif).
La démarche FinOps se traduit par 4 actions principales :

• “Track” : identifier le coût d’un service : dans AWS, toutes les ressources peuvent être taguées afin de les identifier plus facilement qu’un ARN (ID technique AWS). Ces tags peuvent porter le nom du projet, l’environnement, le propriétaire… tout ce qui peut permettre de les identifier.
• “Monitor” : plusieurs services AWS permettent de surveiller la consommation de ressources :
  • AWS Cloudwatch pour les métriques CPU, disque, requêtes/s…
  • AWS Budget : permet de fixer un budget d’envoyer des alertes lorsqu’un dépassement est constaté
  • AWS Trusted Advisor : suggère des optimisations sur les ressources instanciées
• “Forecast” : prévoir l’évolution du budget dans les temps à venir. L’exercice n’est apparement pas simple et se maîtrise avec le temps
• “Optimize” : de nombreux axes existent pour diminuer la facture en fin de mois :
  • 65% du temps est le soir et week end : éteindre les environnements de tests lors de ces périodes. Le service AWS Instance Scheduler facilite ces actions;
  • Bien choisir le type des instances EC2 et le modèle d’achat (voir plus haut);
  • Vérifier le coût des licences et OS utilisés;
  • Gérer le cycle de vie des données dans les buckets S3 : en fonction de la fréquence d’accès aux données, il est possible de mettre de changer l’état des fichiers pour diminuer le prix;
  • S’assurer que tous les volumes EBS sont bien utilisés et montés (selon le type de volume et d’EC2, il faut les monter explicitement dans la VM). Si les volumes ne sont plus utilisés, il faut les supprimer car ils sont tout de même facturés.