Episode 12: AWS Lambda & Serverless Architecture - Functions, API Gateway & Step Functions | SAA-C03

Hey everyone, Balu here. Welcome back to Tech Talk with Balu, your complete guide to asing the AWS Solutions Architect Associate Exam. We are now on episode 12 and today we are diving into AWS Lambda and serverless architecture. This is a fundamental shift in how we think about building applications on AWS. Here is why serverless matters. Traditional applications require you to provision service, manage capacity, pass the operating systems and handle scaling. With serverless you write code and AWS handles everything else. There is no service to manage, there is automatic scaling and you only pay for actual computer. Lambda is AWS's function as a service offering and it has revolutionized application development. Talking with other serverless services like API Gateway, DynamoDB and step functions you can build entire applications without managing a single server. So today we are going to cover what serverless really means. AWS Lambda fundamentals and its pricing, Lambda triggers and its integrations. API Gateway for building rest APIs, step functions for orchestrating different workflows, Cognito for user authentication and of course real serverless architectures and exam traps. By the end of this episode you will understand how to design even driven serverless applications that scale automatically and cost efficiently. So let's dive straight in. Let's start with the basics, what does serverless actually mean? Serverless is a paradigm where developers don't manage service anymore. You just deploy code specifically, you deploy functions. Here's the key insight. Serverless doesn't mean there are no service, of course there are service but you don't see them, manage them or even provision them. AWS handles all of that house suite. Initially serverless meant function as a service, fast, AWS Lambda pioneered this but now serverless includes anything that's fully managed where you don't manage the infrastructure. Serverless services in AWS include AWS Lambda functions, Amazon DynamoDB that's no SQL database, Amazon S3 that's object storage, API Gateway that's rest APIs, Amazon SNS and SQS that's messaging, kindness is data firehose that's data streaming, Aurora serverless that's relational databases, AWS Fargate that's containers without server management, step functions for workflow orchestration and Cognito for user authentication. All of these about services are serverless because AWS manages the infrastructure, you just configure them and use them. Now compare this to a traditional EC2 based application. On EC2 you provision virtual servers, you're limited by RAM and the CPU you choose, it's continuously running so you pay 24 by 7, scaling requires additional or removing servers manually, whereas for a Lambda serverless architecture you use virtual functions, there's no servers to manage anymore. It's limited by time that means it's a maximum of 15 minutes per execution, it runs on demand that's only when you trigger it and scaling is completely automatic. For the example, remember, serverless means you don't manage the infrastructure, you focus on code, not the service. Now let's dive into AWS Lambda. What is Lambda? Lambda is a compute service where you upload your code as a function and Lambda runs it in response to events. You don't provision service, install operating systems or manage its capacity. Some of the benefits of Lambda include first easy pricing, you pay only for the compute time you actually use, there are no charges when your code isn't running. It's free tier that includes one million requests per month and 400,000 GB seconds of compute time. That's generous, more small applications stay in this free tier. Beyond free tier, it costs 20 cents per one million requests. Now that's incredibly cheap. Secondly, Lambda is integrated with the entire AWS ecosystem. Lambda connects to S3, DynamoDB, Kinesis, SNS, SQS, API Gateway, CloudWatch and dozens more services. The third benefit of Lambda is that it supports multiple programming languages. It supports Node.js, Python, Java, C#.NET, Ruby, PowerShell and custom runtimes for Go, Rest and others. Fourth, it's easy to monitor. Lambda automatically logs to CloudWatch. You see invocations, errors, duration, everything. The fifth advantage of Lambda is that it automatically scales. If you get one request or 10,000 simultaneous requests, Lambda scales instantly. You don't configure anything at all. The sixth benefit is that you can use up to 10 GB of RAM per function and here's a tip. Increasing RAM also increases CPU and network performance. Lambda allocates CPU proportionally to the RAM. Now let's talk about Lambda limits. These are important for the exam. There are execution limits. For memory, it's 128 MB minimum, 10 GB maximum and you choose in one MB increments. There's a maximum execution time, which is 15 minutes. That's 900 seconds. If your function runs longer, Lambda terminates it. For longer tasks, you will then want to use EC2, ECS or chain multiple Lambda functions together. You can use environmental variables in Lambda functions, but there is a maximum limit of 4KB in total. From a disk capacity perspective, Lambda provides a slash temp directory with 512 MB to 10 GB of storage. Files here are available for the functions entire execution, but it doesn't persist between the invocations. Lambda functions also have a concurrency limit, which is about 1,000 concurrent executions per region by default. You can however request for increases. There is also a deployment limit. That's a function deployment package has to be 50 MB compressed. That's as a zip file, or if it's uncompressed and extracted, that would be 250 MB. For larger packages, you want to upload that to S3 and reference the Lambda or use Lambda layers for shared code and dependencies. Let me now explain how Lambda actually executes your code, because understanding this helps with performance optimization. When Lambda receives an event to process, it needs somewhere to run your code. It creates what's called an execution environment. This environment includes the runtime for your programming language, like the NodeJS runtime or Python runtime, along with your function code and any dependencies you have packaged with it. Now, the first time your function is invoked, Lambda has to initialize everything from scratch. This is called a cold start. Lambda downloads your code, starts the runtime, initializes your dependencies and then finally runs your function code. This whole process takes time anywhere from a few hundred milliseconds to a few seconds depending on your code size and the language. During that time, your user is waiting. But here's the optimization Lambda does automatically. After your function finishes executing, Lambda doesn't immediately destroy that execution environment. It keeps it warm and ready for a little while. So when the next request comes in, maybe a few seconds or minutes later, Lambda reuses the same environment. Your code, your runtime, your dependencies are all already handled, loaded and ready. Lambda just needs to invoke your function code. This is called a warm start and it's dramatically faster, usually less than 10 milliseconds of overhead. Now, for applications where you absolutely need predictable low latency and you can't tolerate cold starts, AWS offers something called provisioned concurrency. With provisioned concurrency, you tell Lambda to keep a certain number of execution environments initialized and warm at all times. Even if no requests are coming in, those environments stay ready. The trade off is cost, by the way, you pay for those environments even when they're not processing requests, but you completely eliminate cold starts. Now, for Lambda pricing, let's say you have a function with 1GB RAM that runs 3 million times per month each execution taking about a second. That would roughly cost you about $4.73 per month. As a comparison, running the equivalent on EC2 would cost you about $30 to $50 per month for a T3.small running 24/7. Lambda is significantly cheaper for intermittent workloads. So for the exam, remember, Lambda runs functions in response to events. Maximum execution time is about 15 minutes. You pay per request and the compute time and it automatically scales to thousands of concurrent executions. You can have anywhere between 128 MB and 10GB RAM configured. Now, Lambda's power actually comes from its integrations. Lambda can be triggered by dozens of AWS services. Let's first look at the main Lambda triggers. Number one API gateway. Expose Lambda functions as HTTP APIs. Users can now call your API and Lambda executes and it returns a response. It's perfect for rest APIs and microservices use case. Number two, S3. Trigger Lambda when files are uploaded, deleted or modified in your S3 bucket. Common use cases are image uploaded to S3 then triggers Lambda to create thumbnails. Number three, Dynamo DB streams. That is when data changes in Dynamo DB trigger Lambda to react accordingly. A use case would be with you. When a user registers to your website, Lambda sends a welcome email. Number four, Kinesis. You can use Lambda to process streaming from Kinesis in real time. Lambda processes each record in the stream. Number five, SNS and SQS. Lambda can process messages from cues or notification topics. Number six, cloud watch events and event bridge. You can schedule Lambda to run periodically, like cron jobs or react to AWS events such as EC2 state changes, etc. Number seven, application load balancer. And ALB can directly invoke Lambda functions as targets. ALB translates HTTP requests to then Lambda events. Number eight, Cognito. You can trigger Lambda during user authentication flows for custom logic. Now, let me walk you through some common Lambda patterns so you can see how these pieces all fit together. Here's pattern number one, serverless thumbnail creation. Imagine you're building a photo sharing app. A user uploads an image to an S3 bucket. The moment that image lands in your S3 bucket, S3 generates an event and triggers your Lambda function. Lambda receives this event, which includes information about the file that was uploaded, the bucket name, the file key. Everything Lambda needs to locate that particular image. Lambda then downloads the image from S3. Uses an image processing library to create a thumbnail version and then uploads the thumbnail back to S3 in a different bucket of older. At the same time, Lambda writes metadata to DynamoDB, the original file name, the thumbnail file name, the image size when it was created, whatever you needed to track. This is completely serverless. No servers to manage here and it scales automatically. If one user uploads an image, Lambda processes it. If 10,000 users upload image simultaneously, also Lambda scales to 10,000 concurrent executions and processes them all. Pattern number two is serverless cron jobs. In the old days, you had run a cron daemon on an easy-to-instance. That instance runs 24 hours a day, 7 days a week, just waiting for the scheduled time. With serverless, you create an event bridge rule that triggers on a schedule, let's say, every hour. When the scheduled time arrives, event bridge invokes your Lambda function. Lambda wakes up, performs whatever task you need, maybe it's cleanup, maybe it's just generating reports, maybe it's just aggregating data, and then finally Lambda shuts down. You're not paying for an easy-to-instance running all the time here. Lambda only runs for a few seconds. It takes to complete that particular task and you only pay for those seconds. Pattern number three is real-time file processing with streaming data. Imagine that applications are constantly writing data to a kinases data stream. Maybe it's a click stream data from a website or sends a data from an IoT device or log data from service. Lambda is configured to pull that kinases stream. As records arrive in kinases, Lambda automatically pulls them in batches and processes each of those records. Maybe Lambda is filtering the data, transforming the format, enriching it with additional information from a database, and so on. Lambda then finally writes the process results to S3 via a kinases data firewalls, or directly to DynamoDB or wherever you need that data to be in. This pattern handles thousands of records per second completely automatically. Lambda scales up when there's more data and then scales down when there is less. Pattern number four is the rest API backend, and this is probably the most common serverless pattern. API gateway sits at the front receiving HTTP requests from clients. When a request comes in, API gateway invokes Lambda function. Passing the request details, Lambda contains your business logic. It reads from DynamoDB to fetch the data or writes to DynamoDB to save data or perform calculation validate inputs. Whatever again your application needs to do. Lambda finally then returns the result to the API gateway and the API gateway wraps it in a proper HTTP response to send it back to the client. This entire backend is serverless. It scales from 0 to millions of requests automatically and you're not managing any servers, load balancers or auto scaling groups here. You just write Lambda functions at the end. Okay, now let's look at Lambda execution modes. So there is synchronous execution mode and something called asynchronous execution mode. In a synchronous execution mode, the caller waits for response. It's used by API gateway, ALB, direct invocations, basically Lambda executes and the caller gets result immediately. An asynchronous execution more than the other hand is when the caller doesn't wait. Lambda cures the event and returns success immediately. Lambda then processes that event much later. If the function fails, Lambda retries automatically. It's normally used by S3, SNS and event bridge. For the exam, remember that Lambda integrates with most of the AWS services. That is S3, DynamoDB, Kinesis, SNS, SQS, API gateway, even bridge, all can trigger a Lambda function. And also remember Lambda can run synchronously. That's wait for response or asynchronously, which is also called fire and forget. Now let's talk about API gateway. This is how you expose Lambda functions as rest APIs. What is an API gateway? API gateway is a fully managed service for creating, publishing and securing rest APIs and depth socket APIs at any scale. Lambda plus API gateway equals no infrastructure to manage. You build your entire backend with functions and APIs all serverless. What are the API gateway features? Number one, you can handle API versioning. You can have version one, two, three of your API simultaneously. You can route traffic to different versions, in that case. Number two, you can handle different environments. You can create development, test and prod stages with different backends. And number three is security. API gateway handles authentication. That's IAM, Cognito, API keys, etc. And number four is request throttling. You can protect your backend from being overwhelmed. Number five, you can transform and validate requests and responses. You can convert formats, validate JSON schema before hitting Lambda. Number six, you can cache API responses. You can cache frequently requested data to reduce Lambda invocations and improve latency. And finally number seven, you can generate SDKs. API gateway can generate client SDKs for JavaScript, iOS or Android. Now, let me explain the three main ways API gateway integrates with backends. The most common integration is Lambda functions. Here's how this works. A client sends an HTTP request to API gateway. API gateway receives the request and invokes your Lambda function. Passing the request data as an event. Now Lambda executes a code, processes the request and returns the data. API gateway takes that response from Lambda, wraps it in a proper HTTP response with status codes and headers and sends it back to the client. This is the easiest way to build a REST API. Your Lambda function is just business logic. And API gateway handles all the HTTP protocol details. The second integration type is HTTP endpoints. Now, with this pattern, API gateway acts as a proxy to any HTTP endpoint use specify. This could be on an on-premises server in your data center, another AWS service that has an HTTP API or even a public HTTP API on the internet. You might wonder why you do this instead of calling the endpoint directly. The value is that API gateway adds features your endpoint it doesn't have. That's rate limiting to prevent overload, caching to reduce load on your backend, use authentication so only authorize users can access it. And for example, API key management for tracking usage. You're essentially wrapping an existing HTTP API with API gateways managed capabilities. The third integration type is direct AWS service integration. This is powerful. API gateway can invoke AWS services directly without any Lambda function in between. For example, you can configure API gateway so that when a client sends a post request, API gateway writes the data directly to a kindness's data stream. No Lambda function is needed here, or you can have API gateway put messages directly to an SQSQ. Now, why would you do this? Because you're adding authentication, you're getting request throttling, you're adding monitoring and logging all the API gateway features to AWS services that might not have those features built in. It's a way to create a managed API layer on top of AWS services. Now, let's talk about API gateway endpoint types. There are three options and choosing the right one depends on where users are located. The first type is Edge Optimized and this is the default. With Edge Optimized endpoints, when users make requests to your API, those requests are automatically routed through Cloud Front Edge locations around the world. This means if you have a user in Tokyo and your API gateway is in Virginia, their request goes to a Cloud Front Edge Location in Asia, which then routes to your API gateway in Virginia. This significantly improves latency for global users. Now, the API gateway itself still lives in only one AWS region. You're not creating multiple API gateways here, but CloudFriends glow. global network makes it feel fast for users everywhere. The second type is regional endpoints. Now with regional endpoints, your API gateway only serves traffic from within the same AWS region. There's no cloud front in front of it. Now why would you use this? If all your users are in the same region as your API, you don't need global distribution. You could also manually set up cloud front yourself later if you want more control over caching strategies and the distribution configuration itself. Regional gives you that flexibility. The third type is private endpoints. These can only be accessed from within your VPC using an interface VPC endpoint that's an elastic network interface. Private endpoints aren't exposed to the internet at all. Your users when your API should only be accessible from an easy to instance or Lambda functions running inside your VPC. You also use a resource policy to explicitly define which VPCs or VPC endpoints can access your API. This is maximum security that your API is completely internal. For the exam, remember API gateway creates a rest and web socket APIs. It integrates with Lambda, which is more common, HTTP endpoints or AWS services directly. It handles authentication, throttling, caching, transformations, etc. You can use edge optimised for global users, regional for same region users and private for VPC only. Let's now discuss AWS step functions. This is for orchestrating multiple Lambda functions into workflows. What is a step function? Step functions let you build serverless visual workflows that coordinate multiple AWS services primarily Lambda functions. Think of it as a state machine. You define states, Lambda function calls, weight states, parallel executions, conditionals, error handling, and step functions orchestrate all of these. A use case would be order fulfillment. You validate order, charge payment, reserve inventory, ship order, each step is a Lambda function. If the payment fails, step functions handles rollback. Another use case would be data processing that's extract, transform, load that data, each step runs in sequence with error handling. Basically use for any multi-step business process. Step functions give you several powerful capabilities for building workflows. Number one, you can run functions in sequence one after another. Function A completes, then function B runs, then function C runs. Each step gets the output from the previous step. Number two, you can run functions in parallel. Maybe you need to process different parts of your data simultaneously. And step functions can invoke multiple Lambda functions at the same time. Wait for all of them to complete, then move to the next step. Number three, you have conditional logic with choice state here. Based on the output of one function, you can decide which path to take next. If the order total is over $1,000, for instance, go through the premium fulfillment workflow. If it's under $1,000 on the other hand, you standard fulfillment. Just like an if then else logic, but for the entire workflow. Number four, you can add weight states. This lets you pause your workflow for a specific amount of time. Maybe you need to wait, let's say, 30 seconds for a payment processor to confirm a transaction. Step functions just process and then continues in this case. Number five, and this is really important. Step functions has got a built-in error handling mechanism. If a Lambda function fails, step function can automatically retry based on rules you define. You can catch specific errors and take corrective actions. Maybe if a payment fails, you send a notification and mark the order as failed, rather than just crushing the entire workflow. And finally, step functions doesn't just work with Lambda. It integrates with dozens of AWS services. You can invoke ECS tasks to run containers. You can call DynamoDB to read or write data directly. You can run AWS batch jobs for heavy compute tasks. You can publish messages to SNS topics. Step functions is a general purpose orchestration engine, not just a Lambda coordinator. Also remember that step functions have got a visual workflow. You see the workflow as a flow chart diagram. It's easy to understand that way and debug. For the exam, remember step functions, orchestrate multiple Lambda functions and AWS services. You can use it to build serverless workflows that go in sequence, which is parallel. You can do choice handling, waiting, and error handling. And that it's a visual workflow designer. Okay, now let's cover AWS Cognito. This is for user authentication in serverless applications. So what is this cognitive? Cognito gives users an identity so they can interact with your web or mobile application. Cognito has two main components. There is Cognito user pools or called CUP-CUP. It's a serverless database of users for your application. The features are sign up, sign in password reset, email or phone verification, multifactor authentication, federated login, that's Facebook, Google, that sort of thing. Think of user pools as your application's user directory. Users create accounts, login, and get JWT tokens. User pools integrate with API gateway and application load balances. Users authenticate with Cognito, get tokens and token with API requests and so on and so forth. And API gateway validates token automatically. Then there is Cognito identity pools that's federated identity. This provides temporary AWS credentials to users so they can access AWS resources directly. So users can authenticate, that's why user pools, Facebook, Google, etc., then identity pools exchange their identity for temporary IM credentials. With these credentials users can access S3, DynamoDB or any AWS service directly from their mobile or web app. An example would be a mobile app that uploads photo directly to S3. User authenticates with user pool, gets credentials from identity pool, uploads to S3 directly without going through your backend. So common architecture is that the user logs in, Cognito user pool validates the credentials and then returns the Java web token. User then sends requests to API, API gateway validates the Java web token and then API gateway invokes Lambda, Lambda finally processes the request. Or user can log in, Cognito user pool validates, user gets token, Cognito identity pool exchanges token for AWS credentials and then user can access now S3 or DynamoDB directly. Now let me clarify when to use Cognito versus when to use IM. This comparison by the way appears constantly on the exam, so stay focused. You want to use Cognito for end users, the people using your mobile app or web application. If you have hundreds or thousands of users or if you're building a consumer facing app, Cognito is designed for exactly this. It handles sign up, sign in password resets, email verification, all the features your real users need. Cognito also supports federated log in, so users can sign in with their Facebook account or Google account or any SAML identity provider. This is what Cognito normally excels at. You would rather use IM for AWS resources and services talking to each other. If you have an easy to instance that needs to access S3, you give it an IM role. If you have a Lambda function that needs to write to DynamoDB, that's then again an IM role. So IM is for typically machine-to-machine authentication within AWS. You could technically create IM users for people, but IM isn't designed for managing thousands of individual human users. It doesn't have cider pages, passwords or reset flows or social logging for that matter. So here is an exam tip that will save you multiple questions. If you see any of these keywords in the questions, such as mobile users, web application users, hundreds of users, thousands of users or authenticated with Facebook or Google, the answer is normally Cognito and not IM. Those keywords are dead giveaways. On the other hand, if the question is about AWS services accessing other AWS services or internal system to system authentication use cases, that's typically IM. Cognito user pools provide user directory, sign-in sign-up, JWD tokens, so on and so forth. Cognito identity pools provide temporary AWS credentials for direct AWS resource access. It integrates with API gateway and LB and you want to use Cognito for mobile or web users and you typically use IM for AWS services. Now let's look at complete serverless architectures. This is going to bring everything that we've spoken about together. Architecture number one, serverless rest API. The components are API gateway as front end lambda for business logic, DynamoDB for database and Cognito for authentication. So the flow is user authenticates with Cognito user pool and gets a Java web token, user then sends HTTP request to API gateway with this token. API gateway validates the token, API gateway then invokes the lambda function, lambda reads or writes into the DynamoDB, lambda returns the data back, API gateway returns the HTTP response. The benefits here, as you can see, is that there is no service involved and this scales automatically. You only pay for actual usage. Let's look at architecture to a serverless thumbnail service. The components used are S3 for image storage, Lambda for image processing and DynamoDB for metadata storage. The flow is user uploads image to the S3 bucket that's original images. S3 triggers the Lambda function on this upload, Lambda downloads the images and then creates thumbnails for it, and Lambda uploads the thumbnail back to the S3 bucket. Lambda can now write the metadata back into DynamoDB, that's things like file name, size, time stamp, so and so forth. The benefit here is that you can process thousands of images per second automatically without using any service and you only pay for the image that you've processed. Architecture 3, let's look at a serverless cron job. The components here in play are event bridge rule, Lambda function, SNS for notifications. The flow is that event bridge rule triggers every night at 2 a.m. Lambda function then executes, Lambda processes the data, whether it's cleaning up reports, creating reports, aggregating, publishes the results to the SNS topic and SNS sends email notification out. The benefit here as you see, there is no easy to instance running 24 by 7. It only runs on demand when scheduled. So in essence, you get the idea that for such use cases, you really don't need a server that is running 24 by 7 or a server at all. Alright, so now let's look at some common serverless exam traps. Trapped number 1, Lambda maximum execution time is 15 minutes. The question is, you need to run a batch job that takes 2 hours. Can you use Lambda function? As you guess, no Lambda maximum execution time is only 15 minutes. For longer tasks, you have to be using EC2 ECSAW's barge or if you still want to use Lambda, you could use step function with multiple Lambda's involved. Trapped number 2, Lambda has call starts. The question is, you need consistent sub 10 milliseconds response time for Lambda. Can you do it? It's difficult. The first invocation is always a call start, that means you lose about hundreds of milliseconds there, but from then on, you could use what's called provisioned concurrency to keep functions warm always, or you accept call start latency. Trapped number 3, Lambda concurrent execution limit is 1,000 region by default. Question is, if you're expecting 10,000 simultaneous requests, will Lambda handle it? The answer is maybe not without requesting limit increase. Remember that the default is 1,000 concurrent executions. You can request increases but do plan ahead. Trapped number 4, Lambda in VPC experiences slower call starts. The question is, Lambda needs to access RDS in VPC. Is there any performance concerns? Lambda in VPC has longer call starts. Remember that because Lambda creates E&I elastic network interface to access the VPC. AWS has improved this, but there is still some delay. You want to use provisioned concurrency if this matters. Trapped number 5, API gateway timeout is 29 seconds maximum. The question, Lambda function takes about 5 minutes. Can you expose that wire API gateway? Well, the answer is it won't work. API gateway times out after 29 seconds. So for long running tasks, you want to use what's called an asynchronous button. That's the API gateway starts the task and returns immediately. The task then can complete later. On to Trapped number 6, Lambda temp directory is ephemeral. The question, Lambda writes a large file into temp. Does the file persist between invocations? The answer is sometimes but it's not guaranteed. Temp only persists only when its execution environment is warm. So you do not rely it for persistency. You want to use S3 or EFS for persistent storage. Trapped number 7, Lambda deployment package size limit. The question, can you have a Lambda function with 500 MB of dependencies? The answer is it won't fit in the 250 MB uncompressed limit. You want to use Lambda less for shared dependencies or upload large dependencies to S3 and download at runtime or consider things like ECS, Fargate, Instoff Lambda. Trapped number 8, DynamoDB streams required for global tables. Can you create DynamoDB global table for multi-region? The answer is you must enable DynamoDB streams first, global tables use streams for replication. Exam often tests this prerequisite. Trapped number 9, Cognito versus IM. Question is, you want to authenticate about a thousand mobile app users. Do you use IM users? No, you use Cognito. IM is not designed for thousands of individual users. We covered this earlier, Cognito is built for justice. So if you see the keywords mobile users, web users, hundreds of thousands of users, then the answer is always Cognito. Trapped number 10, step functions for orchestration. You need to coordinate five Lambda functions in sequence with error handling. How would you do that? The answer is to use step functions. Do not try to chain Lambda functions manually. Step functions provide orchestration, error handling, retries and all that visual workflow. Trapped number 11, Lambda in ALB target group. Question is, can ALB route to Lambda functions? Yes, it can. ALB target group support Lambda functions directly. ALB invokes Lambda with HTTP requests and Lambda returns response. So there is no API gate we needed in this pattern. And finally for Trapped number 12, Lambda and Lambda variables are limited to four KB. You want to store 50 KB configuration in Lambda and Lambda variables. Can you do it? The answer is no, it won't fit. Enminement variables are limited to four KB total. Remember that. You want to use systems manager parameter store or secrets manager for larger configuration. Let's now look at some rapid fire serverless exam tips. Tip number one, Lambda is even driven. It doesn't run until triggered by an event. Tip number two, Lambda maximum execution time is 15 minutes. For longer execution time, you want to use EC2, ECS batch or multiple lambdas with step functions. Tip number three, Lambda pricing is paper request and compute time. The first one million requests are free. Tip number four, API gate we creates rest APIs backed by Lambda. It handles auth, throttling and caching. Tip number five, step functions orchestrate multiple Lambda functions with error handling and retries. Tip number six, Cognito user pools offer user authentication signup and sign in. Tip number seven, Cognito identity pools, on the other hand, allow temporary AWS credentials for direct resource access. Tip number eight, serverless means no servers to manage. It focuses on code and not the infrastructure. Tip number nine, a common pattern would be API gateway plus Lambda plus DynamoDB, which makes it a serverless rest API configuration. And finally for tip number 10, Lambda integrates with S3, DynamoDB, Kindness's, SQS, SNS, even bridge API gateway and more. So decision flow chart, I wanted to remember is if you need to run code without managing servers, think Lambda functions. If you need a rest API, then it's a combination of API gateway and Lambda. If you need to orchestrate multiple functions, think step functions. If you need to do user authentication, you want to use Cognito user pools. And if you need users to access AWS resources directly, then think Cognito identity pools. Always remember that tasks taking longer than 15 minutes should not use Lambda. You want to use EC2, ECS or patch. All right, everyone. That's episode 12 on AWS Lambda and serverless architecture. Again, we covered a lot today. We started with what serverless really means. That's no service to manage its automatic scaling and its paper use. We dove deep into AWS Lambda. That's functions as a service. It's execution model. It's pricing, limits, cold starts, integrations with dozens of AWS services and so forth. We explored API gateway for building rest APIs that front Lambda functions authentication, throttling, caching, transformations, all that can be achieved through that. We learned about step functions for orchestrating complex workflows with multiple Lambda functions. These step functions are visual workflows. It allows error handling and retries to. We covered Cognito for user authentication, user pools for signing, identity pools for AWS credentials. Then we examined real serverless architectures that's rest APIs, image processing, Chrome, job, so and so forth. And we finally finished with 12 exam traps that appear constantly on the test. The key takeaway is serverless is a paradigm shift. You write code and AWS handles the infrastructure. Lambda scales automatically and it costs nothing when idle and integrates seamlessly with other AWS services. If you were to combine it with API gateway, DynamoDB, step functions and Cognito, you can build complete applications without managing any service. If this episode helped you understand serverless architecture, please do consider to leave a 5 star rating on Spotify to appreciate that a lot and please share with anyone studying for the exam and don't forget to subscribe to this channel. So until next time, keep building, keep learning and go serverless, this is Balu signing off by.