AWS Compute Fundamentals
EC2 Auto Scaling
Elastic Load Balancing
ELB & Auto Scaling Summary
EC2 Instances for SAP Workloads on AWS
The course is part of this learning path
In this section of the AWS Certified: SAP on AWS Specialty learning path, we introduce you to the various Compute services currently available in AWS that are relevant to the PAS-C01 exam.
- Identify the various Compute services available in AWS
- Define the different families within AWS Compute services
- Identify the purpose of load balancers and Elastic Load Balancing
- Understand how Auto Scaling can enable your Compute resources to scale elastically based on varying levels of demand
- Identify supported EC2 instance types for SAP on AWS
The AWS Certified: SAP on AWS Specialty certification has been designed for anyone who has experience managing and operating SAP workloads. Ideally you’ll also have some exposure to the design and implementation of SAP workloads on AWS, including migrating these workloads from on-premises environments. Many exam questions will require a solutions architect level of knowledge for many AWS services, including AWS Compute services. All of the AWS Cloud concepts introduced in this course will be explained and reinforced from the ground up.
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.