assume-role takes as inputs the arn (--role-arn) of the role and a user defined session name (-role-session-name), in this instance 'paws_session', to be used for identification purposes. This gives back an access key ID, a secret access key, and a security token:
We'll now use those to fill the corresponding environmental variables from which Paws is going to draw in order to make the call:
use Paws; use Data::Dumper; use JSON::MaybeXS; use strict;
my $lambda = Paws->service('Lambda', region => 'eu-west-1' );
my $json_text = encode_json($data_structure);
my $response=$lambda->Invoke( FunctionName => 'helloWorldNodeJsAuth', Payload=>$json_text, InvocationType => 'RequestResponse');
print Dumper $response;
Hence, Paws does not just render the calling of an AWS Lambda function easy, but dies it for any AWS service in general. It is just a matter of pinpointing the same named as the service module and go through its documentation to find out how it is called.
Of course, to get to the step of making the actual call, a lot of initial background work has to be done.
It's what we set out to do in this three-part tutorial series, aiming not just at an overview of AWS Lambda's infrastructure, but rather going through the whole set of steps necessary, before we even attempted to make the function's call.
Therefore, we started our exploration with setting up users and roles, policies and permissions, role-based as well as user-based authentication, accessing the lambda through public HTTP endpoints and finally accessing the lambda programmatically by leveraging NodeJs on the server and Perl on the client.
Given AWS's high prevalence and ever growing expansion in powering up applications of any kind, ranging from databases to artificial intelligence, acquiring expertise on the platform is knowledge that is certain to prove extremely valued.
What's more, the AWS free tier makes it pretty easy to get started, so why don't you give it a try?