Interesting solution.. I also "inject" env variables for my Lambda@Edge with CloudFront headers.
One thing you need to watch out for is the low limit on iam:GetRole AWS will throttle that call if it is made to often, the limit is quite low.
We actually create a Cloudfront per client as they need a custom domain anyway. So maybe the better way to do it is to create a cloudfront per client and then inject the table name in the headers. Then Lambda@Edge just uses that?
@rehanvdm
I would also say to stick with injecting values via custom headers when possible, but that only applies to Lambda@Edge functions that are attached to the origin-request - you can't do if you're in a scenario where you need to use viewer-request.
Rolling a distro per client is something I think breaks down at large scale. The default quota is 200 per account (that can of course be raised - I'm curious how high it really goes). When you have thousands of customers, if you're issuing a unique domain for all of them you're either possible hitting an upper limit AWS allows, or juggling a multi-account strategy for your service.
The limit on iam and sts calls - very real. Keeping it in the init of the function is about all that can be done to minimize those calls to once per execution environment, but you're right that it's probably going to get hit pretty soon on a traffic spike. I couldn't find any published docs on what that rate limit is, though.
Agree. So it only breaks down for B2C companies and if you didn't plan to go multi account from the begining. That is the only way to avoid AWS imposed limits, if I recal correctly, I read somewhere that a company could easily get a raise to 1000 CloudFronts per account but please don't hold me on that.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Interesting solution.. I also "inject" env variables for my Lambda@Edge with CloudFront headers.
One thing you need to watch out for is the low limit on
iam:GetRoleAWS will throttle that call if it is made to often, the limit is quite low.We actually create a Cloudfront per client as they need a custom domain anyway. So maybe the better way to do it is to create a cloudfront per client and then inject the table name in the headers. Then Lambda@Edge just uses that?
@rehanvdm I would also say to stick with injecting values via custom headers when possible, but that only applies to Lambda@Edge functions that are attached to the
origin-request- you can't do if you're in a scenario where you need to useviewer-request.Rolling a distro per client is something I think breaks down at large scale. The default quota is 200 per account (that can of course be raised - I'm curious how high it really goes). When you have thousands of customers, if you're issuing a unique domain for all of them you're either possible hitting an upper limit AWS allows, or juggling a multi-account strategy for your service.
The limit on
iamandstscalls - very real. Keeping it in the init of the function is about all that can be done to minimize those calls to once per execution environment, but you're right that it's probably going to get hit pretty soon on a traffic spike. I couldn't find any published docs on what that rate limit is, though.Agree. So it only breaks down for B2C companies and if you didn't plan to go multi account from the begining. That is the only way to avoid AWS imposed limits, if I recal correctly, I read somewhere that a company could easily get a raise to 1000 CloudFronts per account but please don't hold me on that.