graviton pour tes lambdas c'est la base si ton code le permet. gain de perf et cout immédiat
provisioned concurrency pour les lambdas critiques si tu as des cold starts qui te coûtent cher en latency et retries
souvent les lambdas sont over-provisioned en ram. réduis la mémoire au strict nécessaire ça réduit le cpu et le cout
regardez vos logs aussi cloudwatch c'est un gouffre. sampling ou export vers un s3 puis athena
et step functions si t'en utilises vérifie les transitions inutiles ou les long-running flows. finops c'est aussi savoir ce qui tourne
api gateway c'est aussi cher. si t'as des endpoints internes regarde vpc endpoint avec lambda url ou un internal load balancer
des lambdas qui font du polling sur sqs ou dynamodb streams ? change ça en event-driven direct c'est moins cher
data transfer entre regions ou az ? ça coûte un bras. colocate tes services
le storage de dynamodb et les read/write capacity units tu as ondemand ou provisioned ? provisioned si tu as un baseline stable peut être moins cher
j'aime pas trop provisioned concurrency ça te fait payer même quand la lambda dort c'est comme payer un k8s pod always-on c'est overkill
oui mais si tes cold starts sont une catastrophe pour le user experience c'est un compromis. faut calculer le tco pas juste le cout de la lambda
vous utilisez des vpc pour vos lambdas ? ça rajoute de la latency et des coûts eni. si pas besoin virer le vpc
ouais enfin la secops si tu es public avec lambda sans vpc c'est une horreur
exact. sécurité avant tout. mais un private subnet avec nat gateway c'est la mort en coût. vpc endpoints pour les aws services c'est vital
et si vous avez des containers dans lambda image size c'est important le pull coute du temps et des gigabytes
sinon la solution radicale c'est de migrer les hot paths vers des ecs fargate ou eks spot instances. bcp plus de gestion mais cout divisé par 5
fargate spot c'est le rêve pour certains batch jobs mais la résilience faut la construire autour des interruptions ça scale pas bien pour de l'interactif
c'est clair serverless c'est pas toujours la panacée niveau finops. faut juste savoir où sont les goulots d'étranglement de cout
le monitoring des couts c'est primordial. aws cost explorer avec tagging rigoureux sinon tu navigues a l'aveugle
lambda layer aussi si tu as des deps communes. reduire la taille du package
Vous devez être connecté pour poster un message !
Recevoir les derniers articles gratuitement en créant un compte !
S'inscrire
shuet
Membre depuis le 30/05/2020actif
On a une appli full serverless sur aws bcp de lambda pas mal de api gateway et dynamodb. les coûts explosent et la facture lambda fait mal. vous avez des astuces pour réduire ça sans tout rearchitecturer sur k8s ?