AWS Compute Fundamentals
AWS Elastic Beanstalk
The course is part of this learning path
This course provides detail on the AWS Compute services relevant to the Developer - Associate exam. We shall be looking at Amazon EC2, AWS Elastic Beanstalk, and AWS Lambda.
- Understand when you use Amazon EC2
- Learn about the components of Amazon EC2
- How to create and deploy EC2 services
- Understand what EC2 auto scaling is
- Be able to configure auto-scaling launch configurations, launch templates, and auto-scaling groups
- The ability to explain what AWS Elastic Beanstalk is and what it is used for
- The knowledge of the different environments that Elastic Beanstalk provides, allowing you to select the most appropriate option for your needs
- An explanation of how to configure the service and some of the parameters that you can alter to meet your application requirements
- The knowledge of the different monitoring options available for assessing your environment and resources health
- Be able to explain what AWS Lambda is and what its uses are
- Define the components used within Lambda
- Explain the different elements of a Lambda function through its creation
- Understand the key differences between policies used within Lambda
- Recognize how event sources and event mappings are managed for both synchronous and asynchronous invocations
- Discover how Amazon CloudWatch can monitor metrics and logs to isolate issues with your functions
- Learn how to check for common errors that might be causing your functions to fail
Hello, and welcome to this lecture on event sources. I covered event sources and event source mappings in the previous lecture, but now I want to expand a little further on these elements. So let me clarify what an event source is and what an event source mapping is. An event source is an AWS service that produce the events that your Lambda function responds to by invoking it. For a comprehensive list of these event sources, please see the following URL. Event sources can either be poll or push-based. At the time of writing this course, the current poll-based event sources are Amazon Kinesis, Amazon SQS, and DynamoDB. When using these services as an event source, Lambda actually polls the service looking for particular events. For example, Lambda will poll the message queue for SQS and then Lambda will synchronously invoke the associative function when a matching event is found. Push-based event sources cover all the remaining supported event sources. Services using this push model publish events in addition to actually invoking your Lambda function. That's one of the key differences.
The event source service invokes the function instead of Lambda, which is what happens for poll-based event sources. Event source mappings. Simply put, an event source mapping is the configuration that links your event source to your Lambda function. It's what links the events generated from your event source to invoke your Lambda function. However, depending on if the event source is push or poll-based, determines where this event source mapping is configured and stored. For push-based event sources, the mapping is maintained within the event source. Using the appropriate API calls for the event source service, you are able to create and configure the relevant mappings. For example, using the API for S3 bucket notifications, you can specify which events to publish within that bucket and which of your Lambda function to invoke based on those notifications. This will require specific access to allow your event source to invoke the function. And this access is granted through the Lambda function policy, which we discussed in the previous lecture. Poll-based event source mappings are sightly different in that the configuration of the mappings are held within your Lambda function instead. Using the CreateEventSourceMapping API, you can set up the relevant event source mapping for your poll-based service.
Again, permissions will be required, but this time, instead of the permissions being modified within the function policy, permission is required in the Execution role policy, as it will be the function that will be polled in the service, looking for a match relating to the mapping. For more information regarding the CreateEventSourceMapping API, please visit the following URL. When I explained what event sources were, I mentioned synchronous invocation. But what's the difference between a synchronous and asynchronous invocation, and what controls which option? When you manually invoke a Lambda function or when your custom-built application invokes it, you have the ability to use the invoke option, which allows you to specify if the function should be invoked synchronously or asynchronously. More information on this option can be found here. When a function is invoked synchronously, it enables you to assess the result before moving onto the next operation required. You may need to know the outcome of one function before using the value or result within another function.
If you want to control the flow of your functions, then synchronous invocations can help you maintain an order. If these points are not of concern to you or your function, then invoking functions asynchronously would be the preferable option. When using event sources to call and invoke your function, then the ability to select an invocation type is removed. In this case, the invocation type is very dependent on the actual service itself. For poll-based event sources, the invocation type is always synchronous. For push-based event sources, it varies on the service. As you can see from this table, AWS CloudFormation always invokes functions synchronously and AWS Config asynchronously. That now brings me to the end of this lecture covering event sources and event source mappings. Coming up in the next lecture, I shall be covering techniques to help you troubleshoot your Lambda functions.
Stuart has been working within the IT industry for two decades covering a huge range of topic areas and technologies, from data center and network infrastructure design, to cloud architecture and implementation.
To date, Stuart has created 150+ courses relating to Cloud reaching over 180,000 students, mostly within the AWS category and with a heavy focus on security and compliance.
Stuart is a member of the AWS Community Builders Program for his contributions towards AWS.
He is AWS certified and accredited in addition to being a published author covering topics across the AWS landscape.
In January 2016 Stuart was awarded ‘Expert of the Year Award 2015’ from Experts Exchange for his knowledge share within cloud services to the community.
Stuart enjoys writing about cloud technologies and you will find many of his articles within our blog pages.