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 AWS Lambda. Before we can understand how this service can be used to run and scale your code, we first need to understand what the service is exactly. AWS Lambda is a serverless compute service which has been designed to allow you to run your application code without having to manage and provision your own EC2 instances. This saves you having to maintain and administer an additional layer of technical responsibility within your solution. Instead, that responsibility is passed over AWS to manage for you. If you don't need to spend time operating, managing, patching, and securing an EC2 instance, then you have more time to focus on the code of your application and its business logic, while at the same time optimizing costs. With AWS Lambda, you only ever have to pay for the compute power when Lambda is in use via Lambda functions. And I shall explain more on these later. AWS Lambda charges compute power per hundred milliseconds of use only when your code is running, in addition to the number of times your code runs. With subsecond metering, AWS Lambda offers a truly cost-optimized solution for your serverless environment. So how does it work? Well, there are essentially four steps to its operations. Firstly, AWS Lambda needs to be aware of your code that you need to run.
So you can either upload this code to AWS Lambda or write it within the code editors that Lambda provides. Currently, AWS Lambda supports Node.js, Python, Java, C#, Go, and also Ruby. It's worth mentioning that the code that you write or upload can also include other libraries. Once your code is within Lambda, you then need to configure Lambda functions to execute your code upon specific triggers from supported event sources such as S3. As an example, a Lambda function could be triggered when an S3 event occurs, such as an object being uploaded to an S3 bucket. Once the specific trigger is initiated during your normal operations of AWS, AWS Lambda will run your code, as per your Lambda function, using only the required compute power as defined. Later in this course, I will cover more on when and how this compute power is specified. AWS records the compute time in milliseconds and the quantity of Lambda functions run to ascertain the cost of the service. The Lambda service itself can be found within the AWS Management Console under the Compute category. As remember, Lambda is providing a compute function for your code to run on. For an AWS Lambda application to operate, it requires a number of different elements, so I just want to take a few minutes to explain what each of these are. The following form the key constructs of a Lambda application.
The Lambda function. The Lambda function is compiled of your own code that you want Lambda to invoke as per the defined triggers. Event sources. Event sources are AWS services that can be used to trigger your Lambda functions. Or put another way, they produce the events that your Lambda function essentially responds to by invoking it. For a comprehensive list of these event sources, please see the following link. Downstream resources. These are the resources that are required during the execution of your Lambda function. For example, your function might call upon accessing a specific SNS topic or a particular SQS cue, so they're not used as the source of the trigger, but instead they are the resources to be used to execute the code within the function upon invocation.
Log streams. In an effort to help you identify issues and troubleshoot issues with your Lambda function, you can add logging statements to help you identify if your code is operating as expected into a log stream. These log streams will essentially be a sequence of events that all come from the same function and are recorded in CloudWatch. In addition to log streams, Lambda also sends common metrics of your functions to CloudWatch for monitoring and alerting. Now we have a high level understanding of AWS Lambda is, let me dive deeper into each of these components that I've just mentioned so you can understand how they're linked together to enable AWS Lambda to be used as an event-driven method of executing code within AWS across a serverless architecture. Join me in the next lecture where I shall be looking at the Lambda function in greater detail.
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.