Un article inspiré de problèmes de production réels.

Des problèmes historiques

Si comme moi vous avez pu faire des lambda ces dernières années, vous avez très probablement dû passer chez un client qui demandait des lambda VPC, pour de bonnes ou mauvaises raisons. Je ne m’étendrai pas sur les détails des bonnes ou mauvaises raisons ici, mais sachez que cela arrive de devoir en faire.

Historiquement, les lamba-VPC souffraient d’un certain délai lors du démarrage à froid, les rendant très compliquées à utiliser en production. Les systèmes de réchauffage maison qui maintenaient la lambda “active” contre vents et marées étaient alors monnaie courante.

En outre, là où la limite d’exécution concurrente des lambda par défaut est de 1000 par comptes, les lamba nécessitaient une ENI (Elastic Network Interface) par instance, ce qui très rapidement pouvait atteindre la limite d’ENI qui étaient de 350 par défaut. Il fallait alors faire une demande au support et c’était relou.

En bref, quand j’arrivais sur une infra et qu’il fallait monter des lambda VPC (souvent à cause de besoin d’accéder au réseau interne), mon envie de m’ouvrir les veines avec l’antivol du PC était difficile à réfréner.

Heureusement souvent l’antivol était branché sur le PC, ce qui m’empêchait de le faire.

Et puis le Graal

En septembre 2019, une fonctionnalité dont la rumeur qui se murmurait de bouche de solution architect à oreille de solution architect depuis plusieurs mois déjà est enfin annoncée en grande pompe (via un article de blog quoi). Les lambda VPC ne souffriront plus de délais importants de cold start (sauf la toute première exécution de la lamba juste après création) et surtout elles vont pouvoir partager les ENI ! Enfin on va pouvoir envoyer du lambda VPC à 1000 en parallèle sans demande d’augmentation de limite et sans consommer davantage d’IP dans les minuscules VPC des clients.

Minute papillon

Immédiatement, les clients à l’anglais approximatif qui pensaient comprendre des trucs ont commencé à venir râler que c’était pas plus rapide et puis que mon code c’est de la merde et puis que AWS ils ont dit que ils avaient amélioré et gna gna gna.

En fait une fois l’effet d’annonce passé on s’est vite rendu compte que ce n’était pas déployé dans les régions que nous utilisions, et que le plan de déploiement n’était de toute manière pas publique. C’était écrit, mais en tout petit et de toute manière les clients ne lisent jamais les détails.

Bref, comme d’habitude, les informations importantes sur les limitations sont indiquées, mais au lieu d’en faire un étendard « danger », c’était écrit en tout petit ou sous forme détournée comme si c’était une plaquette commerciale alors que c’est une documentation technique qu’il nous faut. En outre, AWS surestime souvent la capacité à lire l’anglais par les clients français qui ne comprennent que ce qui les arrangent, mais bon ça c’est notre boulot de leur expliquer.

Allez, maintenant ça marche

Je râle, je râle mais elle a fini par arriver cette fonctionnalité dans les comptes que j’administre. Heureux Nicolas ? Lol.

Cloudformation…

Un truc a savoir avec le nouveau fonctionnement est qu’il se base sur ce que AWS appelle Hyperplane. Il existe tout plein de vidéos très cool dessus.

Néanmoins, le revers c’est que vous ne maîtrisez plus vos ENI et en particulier leur suppression. Et CloudFormation devient un enfer (enfin pire que d’habitude) parce que vous allez devoir attendre 40 minutes par stack lorsque la suppression de l’ENI Hyperplane est nécessaire. Lol.

Terraform…

C’était la première fois que je recevait un mail d’AWS à propos d’un autre outil, mais il faut reconnaître que vous avez pris vos balls comme on dit aux US pour nous dire que vous avez cassé des trucs chez les autres. Terraform a eu le même problème avec les ENI Hyperplane et vous avez même fait un article sur le blog d’AWS pour l’expliquer. Ça a dû considérablement ruer dans les chaumières pour que vous soyez obligés de faire ça (french expression), mais vu le désarroi des clients que j’ai dû gérer cette semaine là ça m’étonne pas trop. Certains ont même failli envisager faire de l’Azure c’est vous dire.

Anything else ? Hold my sparkling water…

(ouais, je bois moins de bières qu’avant)
Vous vous en doutez, j’ai pas fini de râler. Il nous a aussi manqué une documentation correcte sur les petites subtilités de ce nouveau comportement.

Voici ce qui est écrit dans l’article de blog :

Every unique security group:subnet combination across functions in your account requires a distinct network interface. If a combination is shared across multiple functions in your account, we reuse the same network interface across functions.

https://aws.amazon.com/fr/blogs/compute/announcing-improved-vpc-networking-for-aws-lambda-functions/

Qui peut se traduire en : Chaque combinaison unique [groupe de sécurité:sous-réseau] parmi toutes les fonctions lambda du compte nécessite une interface distincte. Si une combinaison est partagée par plusieurs fonctions d’un même compte, nous réutiliserons l’interface existante.

Oui, il y a l’information mais la formulation est trompeuse, car chez AWS on préfère dire ce qui marche plutôt que ce qui risque de pas marcher. En substance, ce qu’il fallait retenir de ce paragraphe c’était:

Attention petit lapin, si tu as mis un security group différent pour chaque lambda, tu vas atteindre la limite des ENI quand même. Bisous.

Et pour les anglophones:

Be careful my friend, if you put a different security group for each lambda, you will reach the ENI limit anyway. xoxo.

Parce que oui en fait avant peu importait d’avoir un security group différent par lambda et on avait tendance à faire des composants les plus séparés possibles. Sauf que maintenant, 100 lambda avec un security group différent chacun sur 3 subnets chacune ben ça fait 300 ENI Hyperplane. Et on est limités à 250 par VPC.

Bref

Bref, le nouveau fonctionnement des ENI Lambda c’est cool, on va pas se le cacher. J’attendais ça depuis très longtemps. Mais j’aurais vraiment préféré :

• Etre au courant avant qu’une telle fonction allait arriver au lieu de le découvrir en même temps que mes clients
• Pouvoir tester en avance pour vérifier que je n’avais pas de problème
• Avoir le calendrier de mise à jour pour s’y préparer
• Avoir une documentation un peu plus complète qu’un article de blog

Allez, bisous.