Cet article a été co-écrit par plusieurs consultants : Achraf EL MAHMOUDI, Simon GUILLOCHON, Tristan MICHE, Edouard CATTEZ, Timothée AUFORT, Théo PONTHIEU & Thomas THIRIET

Nous y sommes. C’est le dernier jour de cette belle aventure qu’est l’AWS re:Invent. Alors avant d’aller danser sur les dernières sorties de Martin Garrix et de re:Faire le monde jusqu’au bout de la nuit, nous vous avons concocté un bel ensemble d’articles qui valent le détour. Pour vous guider dans tout ce contenu, référez vous au sommaire ci-dessous. Quoi qu'il en soit, nous commençons, comme toujours, par la keynote ! Allez, c'est parti !

Sommaire

1. Keynote du Dr. Werner Vogels
2. Advanced serverless workflow patterns and best practices
3. Hear from customers: private blockchain success story
4. Massive data migration with AWS DataSync
5. Deep dive : AWS Clean Rooms
6. Deep dive : AWS Graviton
7. Amazon Security Lake introduction
8. Building data mesh architectures on AWS
9. What’s new in AWS Lake Formation
10. Conclusion

Keynote du Dr. Werner Vogels

Écrit par Timothée Aufort  

Présenté par Dr. Werner Vogels, Amazon.com VP & CTO

Tout au long de cette Keynote, Werner a beaucoup insisté sur l’importance d’avoir des services faiblement couplés qui facilitent l’évolution des solutions dans le temps. C’est le cas des architectures event-driven qui permettent de scale plus facilement et aident les équipes de développement à avancer plus rapidement quand la complexité augmente. Un exemple parlant est le service S3 qui comportait une poignée de microservices à son origine contre plus de 235 aujourd’hui.

Une fois n’est pas coutume,  nous avons eu droit à quelques annonces sur de nouveaux services et sur des ajouts sur des services existants :

• AWS Step Functions Distributed Map est GA : cette fonctionnalité va permettre de faire des opérations de Map Reduce dans une Step Function à grande échelle (jusqu’à 10 000 flux en // pour traiter des données) ;

• Un nouveau service nommé AWS Application Composer est disponible en preview : ce service va aider les développeurs à simplifier et à accélérer l'architecture, la création et la configuration d'applications serverless. On disposera d’une interface graphique pour glisser, déposer et orchestrer les différents services. Le design d’architecture d’un projet sera donc plus facile à partager entre collègues ;
• Amazon EventBridge Pipes est GA : cette fonctionnalité va aider à la création d’applications de type event-driven en facilitant l’intégration entre consommateurs et producteurs d'événements ;

• Amazon CodeCatalyst est disponible en preview : c’est un service de développement logiciel unifié pour créer et déployer un projet en quelques minutes. On pourra créer des pipelines CI/CD, le service pourra s’intégrer facilement avec des outils comme Jira ou Confluence.

Le Dr. Werner Vogels ferme le bal des keynotes pour cet AWS re:Invent 2022. Ce fut un format que j'ai beaucoup apprécié avec des speakers éloquents, des introductions vidéos très réussies et quelques interventions de grandes entreprises utilisant AWS.

Advanced serverless workflow patterns and best practices

Écrit par Edouard CATTEZ

Présenté par Ben Smith, Sr. Developer Advocate at AWS

Dans cette breakout session, Ben Smith nous présente quelques pratiques qui peuvent être utilisées dans le monde du serverless, et bien évidemment, dans l’écosystème AWS. Après un rapide récapitulatif d’AWS et notamment de son architecture event-driven, nous nous sommes penchés sur les Step Functions, qui sont, toujours d’après Ben Smith, la pierre angulaire du serverless chez AWS.  

Les Step Functions permettent effectivement d’orchestrer des systèmes distribués, d’automatiser des processus et d’orchestrer des micro-services. Avec une interface dédiée, l’utilisateur peut construire des diagrammes exécutables (diagrammes qui peuvent aussi être créés programmatiquement avec l’Amazon State Language a.k.a ASL). Ceci pour répondre à des problématiques clients récurrentes :  

• Ajout constant de valeur métier
• Fiabilité
• Résilience
• Scalabilité
• Simplicité

On distingue deux Step Functions différentes: la fonction standard et la fonction express. Vous pouvez retrouver la comparaison entre les deux dans la documentation officielle d’AWS.  

Ben Smith nous invite à, non pas choisir l’une plus que l’autre, mais bien à trouver la bonne combinaison des deux types de fonction pour d’une part, baisser les coûts d’utilisation des services, et d’autre part pour structurer des diagrammes simples et lisibles.  

Une autre bonne pratique est de ne pas réinventer la roue en utilisant un ensemble de fonctions utilitaires mises à disposition par AWS. Ce sont les intrinsic functions. On y retrouve par exemple la manipulation des tableaux et d’objets json, des fonctions d’encodage et de décodage, des opérations mathématiques… Toutes ces fonctions permettent de réduire le coût des workflows en diminuant le nombre d’états, le nombre de transitions et donc la durée totale des workflows eux-mêmes.  

Par ailleurs, AWS a annoncé pendant ce re:Invent, une mise à jour de la fonction Map qui peut dorénavant être exécutée 10 000 fois en parallèle, itérer sur des millions d’objets Amazon S3 et qui peut être jouée en mode inline ou distributed (le second cas génère des worfklows enfants qui se voudront express car plus performants pour l’usage).  

L’inversion de responsabilités peut également s’avérer bénéfique. Le polling, c’est-à-dire la demande régulière d’une réponse jusqu’à ce que celle-ci soit disponible, peut être remplacé par une callback. En pratique, chaque tâche bénéficie d’un token qui sera retourné aux tâches qui la suivent. Chaque tâche suivante peut alors démarrer quand la précédente se termine.  

Enfin, Ben Smith nous invite à utiliser des patterns reconnus dans l’architecture event-driven pour la gestion des erreurs, notamment le pattern Saga et le Circuit Breaker. Pour en apprendre davantage sur les pratiques du serverless, je vous invite à découvrir ces quelques ressources complémentaires.  

De mon point de vue, les astuces et bonnes pratiques que nous donne Ben Smith sont pertinentes. En revanche, j’ai du mal à voir comment s’inscrivent les tests dans l’architecture serverless. Comment tester automatiquement un workflow dans l’intégration continue ? Quelle charge pour les maintenir ? Est-il possible d’itérer sur la création d’un workflow au travers de boucles de TDD ? Des questions qui méritent de creuser davantage le sujet !

Hear from customers: private blockchain success story

Écrit par Simon Guillochon

Présenté par John Liu, Head of Products @ AWS Web3 Services et Deepak Elias, VP Enterprise Architecture @ Broadridge Financial Solutions

Lors de cette conférence, John Liu nous présente la blockchain privée et une success story d’utilisation de cette technologie avec AWS par la première compagnie aérienne de Corée du sud.

Pourquoi faire des blockchains privées ?  

Avant toute chose, il est important de comprendre pourquoi la blockchain privée peut avoir un intérêt. En fait, elle a du sens dans le cadre d’une entreprise avec un besoin de conformité légale claire et d’adoption de masse. Ces entreprises ne peuvent pas se baser sur des blockchains publiques à cause de plusieurs paramètres :

• leur accès contrôlé ;
• le système de token ;
• la confidentialité de leurs données (e.g. qui vont à l’encontre du RGPD) ;
• leur scalabilité (seules, les blockchains publiques les plus célèbres gèrent un nombre de transaction par seconde (tps) limité.

Bien, maintenant que l’on connaît leur intérêt, il devient pertinent de leur donner un cas d’usage :

• La supply chain management, gestion de chaîne logistique dans la langue de Molière, peut être, entre autres, sécurisée, suivie et automatisée grâce à la blockchain comme l’explique d’ailleurs très justement cet article sur le blog AWS
• La finance est disruptée par ses transactions interbancaires, les stable coins des banques, la sécurisation des décisions (pour un prêt par exemple), le tracking, … La liste est longue tant le cas d’usage est le plus évident.
• Les services gouvernementaux sont aidés par la blockchain au niveau de la gestion des identités, de la délivrance des passeports ou plus globalement, des Central Bank Digital Currencies ou CDBCs.  

Une fois les cas d’usage établis, John Liu nous précise que l’utilisation d’outils tels que Hyperledger Fabric, Hyperledger Besu ou R3 permettent l’implémentation de blockchain privées. Ensuite, nous avons bien évidemment droit à une rapide présentation des fondations qu’AWS propose pour de telles implémentations.

Tableau présentant les différents services AWS utiles à l’implémentation d’une blockchain privée

Attardons nous un court instant sur le tableau ci-dessus et plus précisément sur la mention d’Amazon Managed Blockchain (AMB). Ce service permet la création et la gestion de réseaux privés évolutifs en se basant sur Hyperledger Fabric, mentionné plus haut, et Ethereum. John Liu qualifie l’outil de fiable, évolutif et à bas coûts. Ce n’est qu’une fois la présentation de cet outil terminé qu’il passe à la présentation de la première success story de cette conférence.

Korean Air & le transport du premier vaccin contre la Covid 19

Nous savons tous que briser la chaîne du froid d’un aliment congelé le rend non comestible. Vous apprendrez peut-être que cette notion s’applique aussi aux vaccins. En effet, pour conserver leur intégrité, il est indispensable que les vaccins soient contrôlés, de leur production à leur inoculation, la température n’étant qu’une composante de ces contrôles. Ainsi, de nombreuses informations sont échangées en temps réel par les différentes parties prenantes de cette chaîne logistique sanitaire, et notamment via la compagnie aérienne Korean Air. Mais quelle est l’utilité de la blockchain dans ce cas ?  

En fait, elle se résume en trois mots-clés : donnée, membre et bloc. Dans notre cas d’usage, la donnée désigne les informations qui doivent avoir valeur et fiabilité puisqu’on a besoin de les partager avec les membres, sélectionnés pour rejoindre le réseau privé. Ici, les membres sont :

• les producteurs qui envoient le vaccin ;
• la compagnie aérienne Korean Air qui s’occupe du transport ;
• les services médico-légaux qui contrôlent le produit.

Schéma d’architecture présentant le flux de service blockchain du cas d’usage

Conclusion

L’utilisation d’Amazon Managed Blockchain simplifie grandement l’implémentation de solutions basées sur de la blockchain privée, notamment en exploitant la force du réseau d’Ethereum et la force des outils de la Hyperledger Foundation. Le faible coût de la solution est bien entendu à vérifier cependant.  

Par ailleurs, si la décentralisation est sûrement volontairement absente de cette présentation, elle n’en demeure pas moins une des trois grandes forces de la blockchain telles que formalisées par Vitalik Buterin (décentralisation, sécurité et scalabilité). Je partage néanmoins sincèrement le point de vue de John Liu qui prône une adoption de la blockchain par l’utilisation du privé, avant peut-être de déterminer d’autres cas d’usage sur des blockchain publiques.

Massive data migration with AWS DataSync

Écrit par Tristan Miche

Présenté par Carlos Landaeta, Storage Solutions Architect, AWS et Darryl Diosomito, Senior Solutions Architect, AWS

Lors d’une migration nécessitant le transfert d’une grande quantité de données sous forme de fichiers, se posent généralement les problématiques suivantes :

• développement d’outillage permettant l’analyse des fichiers à transférer, la copie, l'analyse, la vérification après transfert
• la gestion des erreurs et les reprises à effectuer
• la sécurisation du transfert avec du chiffrement en transit
• l’utilisation des liens réseaux existants
• l’obtention des meilleures performances possibles sans pour autant congestionner le réseau d’interconnexion.  

Que peut faire Datasync ?

C’est un service managé qui va en premier lieu optimiser le transfert entre une source hors AWS et des service de stockage (S3, fsx, EFS, …) en optimisant à la fois le débit jusqu’à 100TB/Jour (Il est possible aussi de faire du throttling sur la bande passante) et la quantité de données à transférer (par exemple en détectant uniquement les changements par rapport à la dernière synchronisation).  

Il permet d’effectuer des transferts de façon sécurisée grâce au chiffrement de bout en bout et à la vérification d’intégrité post transfert.  

Enfin il est bien sûr intégré avec CloudWatch pour faciliter le monitoring. Son fonctionnement :

• Déploiement des agents au plus proche de la source de données on-premise ( NFS, SMB, HDFS).
• Création des « locations » source et destination
• Création des tâches: 1 source + 1 destination + 1 configuration ( Filtres, options de reprise,…)
• Lancement du transfert (planification intégrée possible) :  Datasync va coordonner le transfert, gérer les connexions réseaux ( il est bien sur possible de transférer à travers un lien directconnect, un VPN ou internet directement)  

Exemple d’architecture :

AWS Datasync, de part sa facilité de mise en place et sa robustesse, est un incontournable des migrations nécessitant le déplacement de forte volumétrie de façon one-shot ou sur une période plus longue grâce à sa capacité de faire de l’incrémental. A noter qu’il permet également d’adresser d’autres patterns  comme le transfert de données depuis Azure ( Azure Files) ou GCP ( Google Cloud Storage ).

Deep dive : AWS Clean Rooms

Écrit par Achraf EL MAHMOUDI

Parmi les nouveautés annoncées lors de ce re:invent, celle de la sortie du service AWS Clean Rooms a piqué ma curiosité ! Je me suis donc rendu à la breakout session présentant cet outil qui permet de collaborer et de partager finement ses données auprès d’entités tierces.  

Le service propose notamment de répondre aux questions de :

• Comment facilement partager des datasets  ?
• Comment combiner des données de différents clients sans les déplacer ?
• Comment donner un accès à ses données qui soit limité en fonction des personas ?    

Concrètement, AWS Clean Rooms permet de partager ses datasets issues de son Glue Catalog auprès de différents comptes AWS, avec la possibilité de limiter le scope des données partagées.  

La breakout session prend l’exemple d’une société aérienne X et d’une société de média Y, la première a besoin de croiser les données utilisateurs fournies par la seconde.  

1. X se charge de créer une nouvelle collaboration sur Clean Rooms en précisant le numéro de compte de Y.  A noter que X peut choisir jusqu’à 5 collaborateurs.
2. Y peut ensuite créer un dataset partagé (_configured table_) en sélectionnant une table depuis son catalogue Glue. Il a la possibilité d’ajouter des filtres sur des colonnes, sur des valeurs, et même ajouter des _analyses rules_ : limiter les fonctions d'agrégations possible sur ses données.
   Il répète ce processus pour tous les datasets qu'il veut partager et les ajoute à la collaboration.
3. X sera alors en mesure d'accéder aux tables partagées sur Clean Rooms. Toujours sur cette interface, il peut lancer ses requêtes sur les scopes autorisés et enregistrer les résultats sur son propre bucket S3.
4. À partir du bucket, X peut alors exploiter la donnée de son côté (Glue, Athena, Quicksight,…)  

Le service ouvre ainsi la possibilité de partager facilement son datalake à des tiers en ayant la main sur le périmètre visible par ces derniers.  Il permet d'accélérer la collaboration entre des entités en évitant le transfert de données d’un compte à un autre, d’isoler des données seulement pour leur usage, ou encore de configurer de complexes policies d’accès dans son datalake.  

A noter que les données en sortie de room ne sont pour l’instant accessibles que par un export des résultats sur S3. Il n’y pas encore de connectivité avec les autres services à l’instar de Quicksight pour produire ses rapports à partir des datasets de la room.  

AWS Clean Rooms répond à un besoin courant et s’ajoute à la panoplie des nouveautés (S3, Glue, Athena) pour outiller son datalake AWS.

Deep dive : AWS Graviton

Écrit par Timothée Aufort

Présenté par Sudhir Raman, Senior Manager, EC2 Core Compute @ AWS et Oran Barak, Head of Core Compute Engineering @ Stripe.

Pourquoi faire ses propres puces ? Les réponses sont diverses : spécialisation, efficacité, vitesse, innovation et sécurité. La puce Graviton est arrivée en 2018, Graviton 2 en 2019, et Graviton 3 en 2021. Beaucoup d'innovations en moins de 4 ans !    

Graviton 2 délivre un meilleur prix à hauteur de 40% par rapport à Graviton 1 et améliore grandement les performances sur de nombreuses instances EC2. L’entreprise Splunk a constaté une amélioration de 50% sur les performances de leur moteur de recherche.  

Graviton 3 repousse encore plus loin les performances : 25% de plus comparé à Graviton 2, 60% d’efficacité énergétique en plus, jusqu’à 2x plus rapide sur les opérations de cryptographie…

Les puces Graviton 3 contiennent plus de 55 millions de transistors. AWS utilise un concept de chiplet avec 7 matrices différentes dans un emballage avancé. A la sortie de Graviton 3, la taille des micro-bosses reliant chaque puce était inférieure à celles d’Intel et AMD (<=55um pour Graviton et >=100um pour AMD et Intel). Graviton 3 possède un meilleur IPC (instructions per cycle) que Graviton 2. Chaque vCPU est un core physique, il n’y a pas de multithreading simultané (SMT).

Traditionnellement, les interruptions microprocesseur vont des cartes IO à la VM cliente via un hyperviseur. Avec Graviton 2 et 3, la carte Nitro injecte directement les requêtes dans la VM.  

Spark SQL est presque 30% plus performant sur des instances Graviton 3 c7g par rapport à des instances Graviton 2 c6g (benchmark réalisé avec Spark SQL 3.3 et Amazon Corretto 17, un cluster de 8 noeuds et 1TB de données). AWS et la communauté open-source ont amélioré les performances de l’encoding vidéo FFmpeg sur arm64 de plus de 60%. L’amélioration des performances avec Graviton 3 se constate également pour du Machine Learning.

Graviton supporte plusieurs OS (Amazon Linux 2, Red Hat Enterprise Linux 8.2+, Ubuntu…) ainsi que plusieurs orchestrateurs de containers (ECS, EKS, Kubernetes…). Attention, les images docker doivent être en arm64. Il est également supporté par de nombreux services managés : RDS, Aurora, Elasticache, Opensearch, Lambda, Fargate…  

En ce qui concerne les langages de programmation, de nombreux langages sont déjà compatibles arm64 comme Java, Python, Go, PHP, .NET, Rust…  

Stripe, une start-up finops en pleine croissance (workloads multiplié par 5 en 2 ans), est passé sur Graviton sur les recommandations d’AWS. Après sa migration, Stripe a constaté 40% d'amélioration sur la performance et 20-30% d'économies directes sur les coûts. Stripe utilise également Airflow Spark et a constaté des réductions de temps d’exécution allant de 38% à 67%. Le principal obstacle a été la gestion multi-architecture arm64 et x86 pour ses builds et ses déploiements.  

Les gains de performance avec Graviton sont impressionnants, nous considérons toujours ce type de processeur lors de nos conceptions pour nos clients et en interne, c’est en en particulier très simple à mettre en place sur les services managés ne portant pas de code (RDS, Aurora, OpenSearch, ...).

Amazon Security Lake introduction

Écrit par Timothée Aufort

Présenté par Rod Wallace, General Manager @ AWS et Jonathan Garzon, Product Manager @ AWS

Les volumes de données de sécurité sont constamment en train de grossir. Imaginez s’il existait un service qui pourrait automatiquement construire un security lake en centralisant et normalisant la collecte de logs de toute une entreprise tout en fournissant une rétention sur le long terme. C’est là qu’intervient Amazon Security Lake.  

Security Lake repose sur un standard ouvert qui se prénomme Open Cybersecurity Schema Framework (OCSF) qui a été mis en place par Splunk. Security Lake centralise automatiquement la donnée dans un Data Lake. Les sources de données qui alimentent Security Lake sont multiples : les logs AWS, les résultats de sécurité de nombreux services AWS (VPC, CloudTrail, WAF, Route 53 ou encore Security Hub) ou de solutions de sécurité de partenaires AWS et des données personnalisées.

Pour commencer à utiliser Security Lake, il est activable depuis le compte de gestion d’une organisation AWS et on peut choisir un compte administrateur responsable de la gestion des données de sécurité. Ce service est multi-région et peut être activé pour tous les comptes AWS d’une organisation.  

Comment ça marche derrière les rideaux ? La donnée est stockée sur S3 et il est possible de choisir la rétention ainsi que la classe de stockage. Les données ingérées  sont transformées et partitionnées vers le standard OCSF et Apache Parquet grâce au service AWS Glue. Ce service est managé et l’infrastructure est donc totalement gérée par AWS.  

Il est possible d’autoriser l’accès à l’ensemble ou à un sous-ensemble de données du Lake à des abonnées (via S3 ou bien via Lake Formation). Pour analyser et visualiser les données, il ne reste plus qu’à choisir un outil d’analytics : Splunk, Datadog, SageMaker, OpenSearch, Athena… En ce qui concerne le pricing, on paye par GB de logs AWS ingérés et on paye également la normalisation des données au format OCSF.
Security Lake est disponible en preview dans 7 régions, il va falloir maintenant l’essayer pour savoir si ce service est pertinent pour améliorer la sécurité chez nos clients.  

Building data mesh architectures on AWS

Écrit par Thomas Thiriet

Présenté par Ian Meyers (Director, Product Management AWS Analytics Service), Nivas Shankar Principal (Product Manager AWS Lake Formation), Travis Muhlestein (Chief Data & Analytics Officer GoDaddy)

Data Mesh est un terme à la mode. Cette conférence m’a permis de découvrir ce paradigme d’architecture que je ne connaissais pas auparavant.  

Quand on souhaite construire une “Modern Data Strategy”, on doit travailler sur de nombreux domaines clés : “Comment construire mon Data Lake ?”, “Qu’ai-je besoin d’analyser ?”, “Quelles solutions de stockage ?”, “Que dois-je prédire (Machine Learning) ?” ou encore “Qui a besoin de quoi ?”.  

Malgré un travail important, les clients d’AWS, tout comme les clients d’Ippon d’ailleurs, rencontrent encore un certains nombre de problèmes :

A la lecture de ceux-ci, un data lake centralisé semble être, à première vue, la seule solution pour y répondre. Toutes les données sont au même endroit, c’est donc facile pour aller les consulter. Peut-être, mais cela crée bien d’autres problèmes d’un point de vue organisationnel.  

Ma propre interprétation, avec une métaphore technique, serait la suivante. En tant que développeur data, je sais très bien que lorsqu’on essaie d’écrire toutes ses données sur 1 seul nœud, la base de données finit par ne plus être accessible. La quantité de données à écrire et à requêter augmentant au fur et à mesure, cette solution n’est pas recommandée, ni adaptée. On se retrouve clairement avec un problème de scalabilité.  

Finalement, le paradigme du Data Mesh est similaire. Au départ, une entreprise est juste une petite startup où tout le monde est proche donc dans le même silo. Ce qui fonctionne parfaitement dans un premier temps. Néanmoins, l'entreprise grandissant, ce silo devient de plus en plus incapable de transmettre correctement la donnée, ni de la recevoir.  

Il faut donc trouver une solution plus scalable même si partager des données dans une entreprise peut être challengeant : “Tout le monde veut être un consommateur (consumer), mais personne veut être un producteur (producer)”.  

Comment l’architecture Data Mesh fait une différence ? Elle repose sur 4 groupes clés :

• Data owner (Garant de la donnée créée et transformée, du stockage, et du partage au sein de son organisation)
• Data Engineer (Organise la data comme un produit)
• Data consumer (Permet aux personas (personnes ou systèmes) de découvrir, apprendre, comprendre, consommer, et maintenir les produits data)
• Data steward (Est un guide, gère cette gouvernance, impulse une standardisation).  

Les objectifs de Data Mesh sont nombreux mais celui qui m’a le plus interpellé est son caractère scalable. Il y a une bien une organisation centrale, mais celle-ci ne contient pas de données physiques. Elle n’est qu’un intermédiaire entre les producteurs de données et les consommateurs. Les producteurs partagent leur catalogue et les consommateurs le consultent.  

Pour terminer mon résumé, je vous partage un exemple d’architecture matérialisée avec des ressources AWS. A gauche se trouvent les producteurs et à droite les consommateurs.

What’s new in AWS Lake Formation

Écrit par Théo Ponthieu

AWS a continué de développer de nouvelles fonctionnalités pour Lake Formation. Voyons ensemble lesquelles.

EMR Runtime rôles

Le support de Lake Formation est étendu aux EMR Runtime Roles.

Data Exchange for Lake Formation

Ce service permet la mise à disposition de données à des clients via l'intermédiaire de Lake Formation. Les LF-tags indiquent quelles données les clients peuvent accéder. Lorsque les clients ont souscrit, ils peuvent consulter ou transformer la donnée depuis leur compte AWS. Les souscriptions et paiements sont gérés par AWS marketplace.

Les accès à Redshift “Data share” sont centralisés dans Lake Formation

Lake Formation gère les accès de manière centralisée pour tous les services qui vont consommer la donnée dans Redshift. La granularité de la configuration des accès aux données est maintenant au niveau des colonnes et des lignes.

Gestion des permissions dans Redshift Spectrum

La gestion classique des accès via rôles à la donnée en passant par des rôles assumés par des clusters Redshift est remplacée par une intégration basée sur IAM. Redshift Spectrum passe directement un user IAM à Lake Formation pour la gestion des accès.

Centralisation des accès cross-account

Lake Formation autorise directement des utilisateurs d’autres comptes AWS à accéder à certaines données ou non.  

Voici de bonnes nouvelles pour les utilisateurs de Lake Formation.

Conclusion

Mélanger la jeunesse et l'expérience. Telle fût l'intention d'Ippon Technologies en envoyant pas moins de quatorze collaborateurs français à l'édition 2022 du re:Invent. Tantôt retentissantes, tantôt attisant la curiosité, les nouveautés annoncées n'ont, pour la plupart, pas laissé indifférents les vieux briscards comme les jeunes pousses.

Quatre articles ne sauraient rapporter la quantité d'informations appréciées en quatre jours. Si l'équipe d'Ippon présente sur place a tout donné pour délivrer un maximum d'informations, elle continuera à distiller le contenu le plus intéressant dans les semaines à venir. Alors pour ne rien rater des nouveautés de l'AWS re:Invent 2022, suivez nous sur Linkedin et Twitter.