Serverless with AWS Lambda

AWS Lambda Settings

Scott Moss

Scott Moss

Superfilter AI
Serverless with AWS Lambda

Check out a free preview of the full Serverless with AWS Lambda course

The "AWS Lambda Settings" Lesson is part of the full, Serverless with AWS Lambda course featured in this preview video. Here's what you'd learn in this lesson:

Scott reviews various settings on AWS for lambda functions including memory, timeouts, environment variables and more.


Transcript from the "AWS Lambda Settings" Lesson

>> Scott Moss: Back to the lambdas, so that's execution role, and what that means. This right here, basic settings, this is literally just a description of your lambda. You give a description, it's just for us humans to read the descriptions of our lambdas, and that's basically it. Memory, this is exactly what it sounds like, this is how much memory you wanna allocate to your lambdas.

Cuz by default, you get 1024 megs, but you can go all the way to 3000 megs, which is a new limit. They actually just increased the memory, it didn't use to be this high. The thing about the memory is, from my testing and from my research, is that, yes, if you increase the memory, it actually does have a significant impact on your performance, depending on what you're doing.

But it does double, triple your cost, so the more memory you add, the more they're gonna charge you. So you might be thinking, it's just pennies. Yeah, it adds up, so that's the whole point. It's just pennies, it's easy, just throw it at it, but it will add up.

So just something to think about, I would just test your stuff and make sure you're not. I mean, if you have a memory leak, and you think, by coming here, just increasing this is gonna help you, it's not a good idea. That's basically what I'm saying. [LAUGH] Don't do that, go find your memory leak.

Some people actually don't care about memory leaks for lambda cuz it's like, it's a lambda, it's not stateful, it'll just restart. I'm like, my God, okay, so don't do that. And then timeout is how long can this lambda run before it times out. So if you have some hanging operation, like a database connection, some async thing.

How long is AWS gonna keep this lambda alive before it says, okay, that's enough. And even if there's nothing hanging, even if your process is synchronously going through code execution, but it's taking longer than the specific amount that you put here, it'll still just cut it off. So it doesn't even have to be async operation, it could be, hey, your function's just taking too long, we're gonna cut you off.

So that's what this can be, this defaults to six seconds. You can also override all these options that I just talked about inside the service YML. Every single thing that I just described, environment variables, tags, execution role, description, memory, and timeout. You can override in the service YML file, and therefore we update it.

My recommendation is, if you do something with the service YML file, always do it in there. Don't come back and change it in here, cuz then things will be out of sync. And I found out that when you do that and you try to redeploy the call formation, it errors out sometimes.

Cuz it tries to look at a previous state to figure out what's going on. And if you mess around with it, It kinda errors out. We had to get to the point where we just had to delete all of our lambdas and redeploy them. Which sounds really bad, but it's so easy to do, it's like, all right, whatever.

Just delete them and redeploy them, so we've done that a couple times.
>> Scott Moss: This next one, which is Network, specifically to VPC. Does anyone know what a VPC is in the context of AWS?
>> Scott Moss: Okay, this is very important, without this, you probably won't even really use lambdas at all.

But we're not gonna configure VPC today because that's just a whole other lesson. But basically, it's just like a private network, right? So without a VPC and an Internet gateway, IDW set up on AWS, your lambda won't be able to talk to the Internet. So by default, when you deploy a lambda to AWS, it can't talk to the Internet.

If you're trying to make a GitHub call inside your lambda, like. Inside my lambda function, I'm gonna make an API call to GitHub. You won't be able to do it, it's gonna get blocked. And the only way to get around that is to set up a VPC that is connected to an Internet gateway.

And you gotta do all that on lambda, and that's just some advanced networking stuff that I do not wanna walk through. But you would have to set that up, again, you can also do this through the service YML file. But you cannot talk to the Internet in your lambda without setting up an Internet gateway on a VPC.

So just remember that, it took me two weeks to figure out. We almost abandoned lambda, cuz we were like, you can't even make an API call. This is stupid, I don't know how people use this. And I was like, my God, Internet gateway, VPCs, gotta allow all that stuff.

So yeah, that's that, debugging, error handling, this is some new stuff that they have, that they actually just added. This basically means, if your lambdas are dying, what do you want AWS to automatically do for you, if anything? They can send that error to an SNS topic or SQS, which then you can have another lambda or something subscribe to it.

And then you can keep retrying it, so it's like a retry queue or error queue. And you can do things depending on what is happening in your lambda. It's really cool, then they have active tracing, which goes all the way down to figure out what's happening in your lambdas.

It looks like they're trying to compete with a lot of third-party tools out there that already offer some of this for lambdas, so good for them. But it's AWS, I mean, you're gonna get a really bad dashboard. So [LAUGH] concurrency, that's exactly what it sounds like. How many parallel invocations of this function can you run at one time?

So right now, it says, use unreserved account currency, which is 1,000. You can put something else there if you wanted to, but it's not gonna let you go over 1,000. So that's the max that you're gonna get, so that's something to think about. You can actually call them and they can increase a lot of this stuff.

So things like memory, timeout, concurrency, you can call them and request for this stuff. And then they'll be like, it's gonna take a couple days. And most of the time they'll do it, but what they'll do instead is try to look at your stack to figure out if there's a better way to do it instead.

But they can increase all this stuff, don't let them tell you that they can't. But if you do need increase in this stuff, you code's probably messed up. So they have these limits for a reason, but just to let you know. And then this auditing and compliance is, actually, I have no idea what this is.

It's my first time seeing this, so this is new. So I'm not even gonna pretend that I know what that is. So I'm guessing it's auditing and compliance, [LAUGH] so I'm not even gonna talk about it, that's a new thing. So I'm not sure what that is, I mean, it looks like it's just telling to go somewhere else anyway.

So we'll just forget about that, any questions on this lambda dashboard so far? I went over a lot, whole bunch, again, all that is in the serivce YML, you do all this in that file, it's pretty crazy, yes.
>> Marc Grabanski: For the VPC part, without setting that up, are you still able to access other things?

Like if I had a DynamoDB set up on my own-
>> Scott Moss: If that dynamo DB was not in the VPC, yeah, but it probably is. Yeah, you can access anything on your AWS account that's not in the VPC with the lambda. But you cannot access anything that's in the VPC or anything that's on the Internet without setting up a VPC and an IGW.

>> Scott Moss: Cool, okay, so coming back all the way to the top, I don't recommend doing this stuff. But I'm gonna show you, so when we set up those events in the service YML, you can also just do them here too. Because the service framework is not made by AWS, I don't know if I mentioned that.

AWS didn't make the service framework, it's just a company called Serverless. So that means AWS has to have their own way for you to attach events and things, and this is how they want you to do it. So you can come in here, and you can attach your own events.

So if I wanted to add a CloudWatch event, I can add one here. If I wanted to add a CodeCommit event, I could add one here. And it just adds the event, that simple. Then I would come down here and configure that event, as you can see. But the serverless YML does the exact same thing, so it's kinda up to you.

Like I said, if you're gonna do one one way, keep it, don't mix and match. Don't add events here and then some events in the YML file. Just wherever you're gonna do it, just do it there and that's it. The reason I prefer the YML file is cuz it's in git.

It's history, I can reversion them, I can check them into Git, I can go back. This is just a dashboard that anybody can come in here and just click on x and it's done. So I'd rather not do that, so I'd rather have my stuff in Git. And let me get rid of that one, there we go.

So again, yeah, you can come in here and you can add all these events and do all your stuff.

Learn Straight from the Experts Who Shape the Modern Web

  • In-depth Courses
  • Industry Leading Experts
  • Learning Paths
  • Live Interactive Workshops
Get Unlimited Access Now