Comment by runamok | Hacker News Reader

Comment by runamok | Hacker News Reader

Parent Full thread

I am on a devops team trying to implement lambda by splitting pieces off from a monolithic Java app where applicable.

The biggest pain point I have is because we have multiple "environments" (such as dev, da, staging) in the same amazon account and because lambdas are global I can't limit access to resources via IAM easily without hacks.

Aka, because the same lambda will be used (but different versions and/or aliases) on all environments I can't marry the code and configuration to limit access to say RDS or elasticache or an S3 bucket per lambda.

I feel like I need a higher order primitive (a lambda group that is role + configuration can live in that includes the lambdas) to achieve this. I realize api gateway has the concepts of stages but currently the idea is for some lambdas to be invoked directly by the monolithic app or via SNS/SQS async.

Otherwise I could namespace my lambda functions which is hacky and make DevFooBar, StageFooBar, etc.

Currently we plan to split off our environments into separate AWS accounts.

Hi Runamok,

Today given that aliases/versions do not have any sort of different permissions you are probably best to either run completely different stacks of resources or the multiple account model. With AWS Organizations these days its not that hard to run multiple environments across accounts.

We did a webinar on some of this a few months back, the slides here might be useful to you: https://www.slideshare.net/AmazonWebServices/building-a-deve...

It heavily leverages AWS's tools, but you could create similar practices using 3rd party frameworks and CI/CD tools as well.

Thanks,

-munns

To get around the IAM issue we deployed the lambda's with a naming convention like:

prod_lambda_name staging_lambda_name dev_lambda_name

Then the IAM's are written with resource access to prod_* staging_* etc.

It allows to give full permissions to the developer to create dev ones, modify the other ones, but the prod_ are all controlled by a smaller group of people.

It's a bit hacky but it works well enough.

Would be nicer to grant access by stages.

I know we're discussing AWS here, but I find Azure handles this nicely. It has a 'slots' concept, so you can have a slot for production, another for QA, and any more you need. The really great thing is the ability to swap slots - so once you've finished testing a new QA build, you swap the QA and production slots, so what was running in QA is now running in production.

Reply on news.ycombinator.com