Aymen et Benoit vous racontent leur Re:Invent 2019

Deux de nos Wewes, Aymen et Benoît, étaient présents au Re:Invent à Las Vegas le mois dernier.

L’événement connaît de plus en plus de succès, avec un nombre de participants atteignant plus de 60 000 personnes cette année. Bien que l’actualité ait beaucoup parlé des Keynotes et des différentes annonces, nous avons choisi d’aborder l’événement sous un autre angle.

De nombreuses sessions de différentes natures de tous niveaux se sont enchaînées, la plupart du temps en parallèle, pendant toute la semaine et bien qu’un grand nombre des conférences données lors de l’événement soient aujourd’hui disponible sur la chaîne Youtube AWS Events, beaucoup de choses présentées n’ont pas pu être partagées. Une cinquantaine d’entreprises avaient en plus marqué leur présence par des stands et des workshops lors de l’événement, comme Hashicorp, VMware, MongoDB, Datadog, Snowflake, Matillon, et bien d’autres…

Donnons donc la parole à Aymen et Benoît pour qu’ils vous exposent leur sélection :

Conférences et workshops

Hybrid architectures for database backups & file migrations (STG313)

Dans ce workshop, Petter Levett et Jeff Bartley ont commencé par une présentation du service AWS storage gateway, avec les différentes options possibles. Après deux travaux à réaliser, le premier scénario a été proposé. Il consiste à créer un backup de base de données MySQL sur du on-premise, et mettre le backup sur un bucket S3 via la storage Gateway, et ensuite créer une instance RDS à partir du backup sur le S3.

Le deuxième consiste à migrer le partage NFS on-premise vers un AWS bucket S3, qui remplace le NFS, via la storage Gateway.

Provable access controls: Know who can access your AWS resources (SEC343)

Cette conférence présentée par deux membres des équipes de recherche d’AWS a commencé par exposer la difficulté aujourd'hui d'avoir une garantie de sécurité quand l'architecture Cloud est par nature capable d'évoluer régulièrement. En effet cette architecture contient potentiellement plusieurs comptes, VPCs, subnets, peering, assume role, le tout dynamique, il est difficile de maintenir cette assurance de sécurité.

La validation manuelle est difficile et peut facilement inclure des présomptions non fondées que l’on aurait prises lors de l’édification de l’architecture. Les normes avioniques et médicales apportent un élément de réponses à ces problématiques en incluant l’utilisation d’outils SMT de résolution de modèles équationnels.

Il fallait pouvoir utiliser ces outils pour prendre en charge la réalité des environnements AWS. La représentation complète des configurations de tous les services AWS via API et la modélisation simplifiée permettent de présenter la topologie de façon compréhensible pour ces outils.

AWS a donc construit deux moteurs de détection pour les topologies réseau comme pour les permissions IAM qui alimentent Amazon Inspector et AWS Config, dans lesquels on peut injecter des règles humainement compréhensibles de détection de faille.

Reste qu'il faut encore aujourd'hui des humains pour sélectionner les règles à appliquer (parmi celles managées et/ou créer des nouvelles) et la remédiation lors de la détection de faille. De même, Il faut encore trouver les bonnes règles logiques à mettre en place pour prévenir les failles.

Architect governance at enterprise scale with Goldman Sachs (MGT313)

Quand on commence notre voyage dans le cloud d’AWS, la première question qu’on se pose est comment assurer la gouvernance des comptes ? Dans cette conférence, nous est présenté les septs points clés nommés Best Practice à prendre en compte pour mieux gérer votre organisation AWS, ainsi que le service AWS “Starter AWS multi-account framework” qui vous permet d’avoir toutes ces recommandations sous forme d’un modèle proposé par AWS que vous pouvez adapter selon votre besoin.

C’est le cas de Goldman Sachs, qui a présenté son implémentation par Ming Ng et Tate Wrage. Leur modèle gère aujourd’hui plus de 1200 comptes attachés à deux organisations (developer, application). Je vous invite à regarder cette présentation pour en savoir plus.

Threat management in the cloud: Amazon GuardDuty & AWS Security Hub (SEC206)

Vu en diffusion Content Hub, cette conférence introduit les deux services et leurs fonctions.

Guard Duty est un service de détection de menace basé sur des listes de failles exploitables/comportements anormaux fournies par AWS et ses partenaires.

Security Hub est un service de centralisation des retours de sécurité d'autres services AWS ou non (ex Macie, Guard Duty…), il propose un format de payload pour intégrer des retours d'outils tiers.

Security Hub propose des fonctions de temporisation/agrégation/résumé d'alertes, programmation de vérification (nombreuses règles par défaut disponibles), le tout pour fournir des événements sur lesquels brancher des réponse automatiques, alerting humain, isolation automatique, suppression…

Nouvelle fonctionnalité prochaine, le regroupement au niveau du compte racine d'une Organisation des données des Severity Hub des sous-comptes avec possibilité de créer des règles pour filtrer des événements dans les sous-comptes.

Reducing blast radius with cell-based architectures (ARC411)

Diffusion en Content Hub, cette fois aussi. L’architecture cell-based est encore très récente, je ne connaissais que de nom aussi ce sujet m’a attiré. La présentation s’est passée en deux parties, tout d’abord une présentation de la logique derrière cette architecture et de ses avantages. Plusieurs notions fondamentales ont été abordées :

• la séparation des Data et Control plane, le tout pour réduire les effets de bord aussi appelé le blast radius
• la présence d’un routeur pour suivre et choisir les cellules traitant les données
• une comparaison des caractéristiques de différentes tailles de cellule pour aider au choix selon les besoins
• les propriétés que le routeur doit avoir pour être le plus pratique à manipuler
• la notion de statut de la cellule et tout ce qui peut l’affecter
• le fait que les cellules étaient AZ agnostiques
• le tout rentrant dans les caractéristiques attendues par le Well Architected Framework d’AWS.

Un ingénieur sécurité du site Amazon.com nous a ensuite parlé de plusieurs de leurs projets utilisant ce genre d’architecture et surtout le système de gestion des événements de sécurité.

Ce système traite déjà un volume impressionnant de données aujourd’hui et a des perspectives d’évolution importantes car il suit la taille de l’infrastructure du site.

D’un point de vue macro, il s’agit d’un chaînage du routeur desservant plusieurs cellules analytics qui envoie ensuite les données dans Kinesis pour remplir un Bucket S3 sur lequel sont branchés différents systèmes de détection. Un des systèmes de détection est lui-même construit sur le même modèle de routeur avec des cellules de traitement écrivant dans un repository les détections.

Le routeur est constitué d’un SNS recevant les créations d’objets dans le premier bucket S3 du service qui écrit dans une file SQS servant des lambdas qui choisissent la destination à partir de deux tables DynamoDB de règles par défaut et de surcharge. Les règles portent principalement sur le load balancing.

Breaking the monolith with style and speed (DOP206)

Le passage en micro-services consiste à écrire une nouvelle application, qui doit assurer la continuité de votre service, et répondre au mieux aux exigences d’une application moderne.

Si vous vous interrogez : comment migrer les workloads de votre monolithe vers une nouvelle application basée en micro-services, sans interruption de service, et sans perte d’intégrité des données, cette conférence répond à votre question.

Les speakers Bruce Wrong et Nikita Daga nous ont présenté leur expérience chez Stitch Fix en huit étapes de migration figurant sur l’image. L'observabilité est la clef de la réussite de cette migration. Pour chaque étape, ils mesuraient l’intégrité des données entre les deux applications. Cela a permis de détecter les problèmes potentiels et les réparer avant la mise en production de la nouvelle version. Une fois qu’ils avaient suffisamment foi en la préparation de la migration, la nouvelle application est mise en production, et un DROP sur les anciennes bases de données est appliqué en toute confiance.

Architecture patterns for multi-region active-active (ARC213)

Comme souvent dans le design d’une architecture sur AWS, on suit le modèle multi-AZ. Ce modèle est pratique et simple à mettre en place. Il reste parfois critiqué, car il ne répond pas à certaines problématiques comme :

• La perte d’un service dans une région AWS.
• L’amélioration de l'expérience utilisateur par le service de la région la plus proche.
• L'environnement de reprise après sinistre peut être désynchronisé, et causer un gaspillage d'argent.

Cette conférence abordera les différents points-clés à considérer, afin de concevoir une architecture multi-région active-active :

• Le réseau : quels réseaux choisir, un VPN qui dépend des fournisseurs accès internet ou VPC peering pour rester dans le réseau AWS, et encore transit Gateway across regions annoncé récemment.
• Réplication de données : réduire le nombre de données répliquées pour plus d'efficacité, classifier ces données du plus au moins critique et choisir son mode de réplication, synchrone ou asynchrone.
• Routage de trafic : un élément important pour la continuité de service, en cas de panne, l'idéal est que l’utilisateur ne soit pas impacté. La solution présentée est un Cloudfront pour rester dans le réseau AWS avec une Lambda@Edge qui modifie l’origine des requêtes en fonction des headers, afin de rediriger les requêtes vers la bonne région de destination.
• Management de la configuration : assurer l’application des règles de conformité entre les différentes régions via les services AWS Config, SSM, AWS Cloudwatch (Cross Region dashboard) et AWS CloudFormation StackSets, qui vous permet de déployer des ressources dans des régions différentes.

Deep dive and best practices for Amazon Redshift (ANT418)

Ce talk s’adresse aux experts Redshift. Il expose les bonnes pratiques et les recommandations AWS afin de tirer un maximum de bénéfices du service. Il traite différent points comme : l’encodage, la compression, le tri de données, la distribution de données, la structure des tables, la redondance, l’ingestion de données, l’ETL, le vacuum, le sizing et le resizing du cluster Redshift etc …

En conclusion, Tony Gibbs et Harshida Patel nous invite à consulter Redshift Advisor pour avoir des recommandations proposées par l’outil en se basant sur notre utilisation quotidienne du service. Il existe aussi le blog Amazon Redshift, et des labs afin de tester les différentes configurations.

HashiCorp Enterprise on AWS best practices (GPSTEC344)

La conférence a commencé par la présentation du Cloud Operating Model de HashiCorp avant d’introduire Terraform. Terraform est un outil capable de provisionner n’importe quelle ressource grâce à sa multitude de providers interfaçant de très nombreux services pouvant composer l’architecture.

Terraform seul fonctionne très bien dans un contexte relativement petit, avec peu de pièces mouvantes, mais gérer de multiples projets, avec plusieurs équipes et la concurrence que ça amène devient vite complexe.

Pour garantir la sécurité, le cloisonnement des applications tout en intégrant les choix d’architecture, le découpage multi-comptes, le tout en conservant la gouvernance, AWS développe en ce moment le service AWS Terraform Landing Zone Accelerator (disponible uniquement en preview privée pour le moment).

Ce service prévoit un déploiement en plusieurs étapes, tout d’abord les comptes centraux, ensuite un distributeur de comptes AWS dans lesquels seront appliquées les bases de sécurité (détection, prévention), et la configuration des services support et réseau.

L’approche prônée pour la création des modules consiste à enrichir les services AWS dans des modules Terraform réutilisables.

Le but est d’automatiser, agrandir l'organisation selon les besoins, permettre la création self service de comptes dans le cadre de garde-fous établis, préserver l’auditabilité des nouveaux comptes créés, tout en conservant une configuration flexible selon les besoins.

Nous avons aussi assisté aux présentations des logiciels Vault et Consul de Hashicorp.

Finalement, on nous a introduit la plateforme Terraform Cloud qui est le service SaaS d’intégration de Terraform accessible aux particuliers et aux entreprises (plus abordable que Terraform Enterprise).

Terraform Cloud peut inclure, là où Terraform Enterprise l’inclut automatiquement, le logiciel Sentinel (propriétaire Hashicorp) qui s’applique entre le plan et son apply. Le but de ce logiciel est d’analyser le plan pour vérifier sa conformité avec les règles que nous aurons établies, mais aussi de pouvoir faire de l’estimation de coût pour pouvoir rejeter des plans qui manipuleraient de manière invalide des ressources protégées par exemple, ou tenteraient de déployer des services trop coûteux.

Build data-driven mobile and web apps with AWS AppSync (MOB402)

Aujourd’hui, les applications utilisent de plus en plus leur référentiel de données et ont de plus en plus besoin de temps réel malgré les différentes couches de cache que présentent le réseau et les solutions. Selon la qualité du réseau, les passages hors connexion etc, les problématiques de synchronisation et les conflits peuvent se multiplier.

Amplify DataStore est une librairie multi-plateformes utilisant GraphQL pour synchroniser les données automatiquement avec un modèle de données distant.

Les classes DataStore fournissent une abstraction construite à partir des champs des déclarations GraphQL, il est possible de choisir le modèle (relationnel ou non) selon lequel les données seront mises à disposition par la librairie pour écriture dans le stockage local. Les modifications sont réduites à des opérations unitaires pour permettre plus facilement la réintégration des opérations dans l’ordre.

Le moteur de synchronisation interagit directement (caché en interne dans la librairie) avec le moteur de stockage qui traduit selon le format demandé, aussi c’est transparent pour les développeurs.

Le service AppSync intervient du côté serveur pour aider à la synchronisation des données en fournissant des resolvers de synchronisation avec détection et résolution de conflits.

Leur approche utilise les algorithmes de fusion de travail collaboratif (type VCS) du type 3-way merge notamment. En utilisant l’historique des modifications, le service peut fusionner facilement les opérations unitaires en les traitant champ par champ.

Le transfert des modifications auprès d’AppSync inclut nativement du multiplexage et de la pagination pour réduire la charge sur le réseau et la consommation cliente, tout en réduisant l’impact des coupures réseau.

Il est possible de choisir différents comportements lors de la résolution automatique de conflit, l’acceptation de la dernière version écrite selon différents critères, forcer une résolution manuelle, ou déclencher une Lambda que le compte fournira lui-même pour des traitement customisés.

Governance at scale: AWS Control Tower, AWS Organizations, and more (MGT307)

Les principes de mise en action d’une gouvernance dans un cycle continu de création d’environnements incluent la mise en place de garde-fous, la centralisation d’IAM, l’automatisation de la détection de compliance des comptes.

Pour la partie gestion de multiple comptes, AWS Organizations apporte l’accès aux informations de gouvernance en un point central, Control Tower et Landing Zone servent à déployer les comptes.

Aujourd’hui, Control Tower ne couvre pas encore tous les cas que couvre Landing Zone, une approche hybride est présentée dans le blog AWS (Landing Zone va progressivement devenir obsolète).

La problématique de Landing Zone était qu’il était trop permissif par rapport à certaines bonnes pratiques AWS, Control Tower impose un certain nombre de règles (impossible à changer) de bonnes pratiques en plus de pouvoir ajouter des règles customisées ensuite.

Aujourd’hui, il ne prend en charge que la création de nouveaux comptes (pas d’import mais ça viendra).

Il permet de (en paramétrant les Organizational Units) :

• Créer des sandbox (séparées, sous quotas)
• Créer des comptes de workloads pour du développement
• Créer des comptes de tests (SCP)
• Clôturer des comptes (ne peuvent pas être supprimés)
• Gérer des cas particuliers de users
• Gérer des exceptions (cas particuliers sous plus grande surveillance)
• Créer des comptes de déploiement.

Management and operations for Amazon EKS (CON206)

Ce workshop été l’occasion pour découvrir le service EKS (Kubernetes managé par AWS) avec les spécialités. Plusieurs exercices ont été proposés pour différents niveaux (intermediate, advanced et expert), allant du simple déploiement d’une application sur EKS, jusqu’au monitoring, sécurisation des microservices, contrôle de trafic réseau etc … Ça a été aussi l’occasion d’échanger avec les participants autour de la table,  et les animateurs du workshop.

Parmis les questions qui ont été posées, pourquoi quand on lance un pod, une interface réseau (ENI) est attachée à lui directement avec une IP privée? La réponse est : pour supporter le routage dans le VPC, en plus supporter les features VPC comme un security groupe qu’on peut attacher à cette interface.

Actionable threat hunting in AWS (SEC339)

Cette conférence était présentée par Chris Farris, Cloud Security Lead chez WarnerMedia, qui nous a parlé du traitement de la sécurité dans son périmètre.

Tout d’abord il a explicité les différentes étapes de gestion des incidents :

• préparation
• identification
• contention
• éradication
• récupération
• leçons à conserver

Il a introduit les différents sujets sur lesquels selon lui la sécurité doit passer du temps :

• s’assurer d’avoir des informations précises et représentant ce qu’il se passe dans les comptes
• assurer l’utilisation généralisée du MFA
• qu’aucun secret n’est hard codé
• s’assurer que les security groups soient assez fins
• contrôler les politiques d’accès aux données
• centraliser les logs CloudTrail
• valider les rôles IAM
• analyser et répondre aux découvertes de GuardDuty
• gérer la rotation des différentes clés d’accès
• participer aux cycles de développement

Son expérience provient de la gestion des plus de 800 comptes AWS (regroupés dans 12 Organizations de paiement) générant 8,1 millions d’événements CloudTrail par heure (environ 18% d’assume role et 10% de decrypt) et cette structure grandit encore (d’où le besoin d’élasticité).

La stratégie d’identification centralisée repose sur CloudTrail pour la première détection de danger effectif, GuardDuty pour faire des correspondances et trouver les événements dans les logs VPC et DNS, CloudSploit pour repérer les configurations avec des failles et Antiope en tant qu’inventaire pour retrouver les ressources (quel compte etc). Ils ont construit et complété un catalogue d’actions menaçantes à détecter pour investigation. L’investigation se fait avec Amazon Detective pour identifier ce qu’il s’est passé en vue de couper les accès en déclenchant des rotations des clés d’accès et de réparer les dégâts des opérations des intrus. Les ressources atteintes qui peuvent être isolées le sont avec prise d’empreintes en vue d’analyses futures dans un périmètre restreint.

Chalk talks

From one to many: Diving deeper into evolving VPC design (ARC304)

La discussion est partie d’un cas d’un applicatif POC évoluant progressivement au fur et à mesure de son utilisation en tant que vraie plateforme de production en ajoutant de la complexité :

• application 3 tiers simple
• évolutions :
• inclusion d’une partie on-premise (hybrid cloud), connexion VPN, customer gateway -> transit gateway (ECMP)
• DNS : route53 resolver
• accès aux services AWS en full privé (VPC endpoint)
• ouverture à plusieurs types d’environnements pour 30 différentes équipes (90 VPCs)
• comptes de dev en VPC sharing (network and VPC configuration dans un compte dédié géré par l’équipe réseau, subnets partagés dans des comptes de dev (split des quotas API)
• transit VPC pour partager les connexions VPN et les endpoints (partage des endpoints via partage de zone route53).

Monitoring and observability of serverless apps using AWS X-Ray (DOP327)

AWS X-Ray intervient pour répondre à la problématique de l’observabilité et du debugging des architectures serverless.

Il supporte aujourd’hui les langages .Net, Go (beta), Java, Python, Ruby (beta) et Node.js.

X-Ray est supporté par de nombreux services AWS (qui utilisent le daemon X-Ray pour ajouter des headers ou uploader des segments directement dans le service), il suffit souvent de cocher une case pour activer les captures. Le service X-Ray peut aussi être utilisé dans des infrastructures extérieures à AWS, on peut alors profiter de l’interface et des outils de X-Ray pour analyser ce qu’il se passe dans son propre contexte applicatif interne.

X-Ray apporte :

• Une cartographie des échanges entre services.
• De l'échantillonnage des requêtes.
• des headers de suivi.
• La possibilité de filtrer la vue produite.
• De regrouper des éléments.
• Des annotations et metadata.
• Des relevés d’erreurs (50x), fautes (40x) et exceptions.

Un nouvel agent est disponible dans Github pour le support du langage Java.

Amazon ES sizing and capacity planning (ANT408)

Pour ceux qui cherche l’optimisation d’AWS ElasticSearch sur AWS. On se retrouve souvent avec un cluster exagéré en terme de capacité, et étant donné le prix qu’on paie pour ce service, il peut être intéressant d’en faire une optimisation.

Ce chalk talk, essaie de répondre à la question. Patrick Schnell et Jon Handler abordent les points-clés d’optimisation : les indexes, le nombre de shards à choisir et la taille de chacune, nombre de partitions, RAM et CPU à choisir. Ils traduisent cette optimisation par des exemples de scénarios que vous pouvez avoir sur la présentation, et aussi des formules d’estimation formalisées sur des années d’expériences.

En conclusion, les speakers nous invite à utiliser Opendistro pour avoir de la visibilité sur les opérations dans le cluster.

Conclusion

Assister au Re:Invent est un événement à faire au moins une fois dans sa vie. Que ce soit l’événement ou le cadre de Las Vegas, l’expérience ne laisse pas indifférent et on revient forcément avec plein de sujets de réflexion en tête. Les sessions étaient si nombreuses et souvent pleines, il était difficile d’assister à tout le contenu aussi nous espérons que ce retour de nos parcours respectifs au sein de l’événement pourra vous apporter des éléments de réponse ou simplement vous aiguiller dans vos recherches.