Rust + AWS Lambda + Windows Part 3
Once we’ve coded, uploaded, and tested our Lambda function from within the AWS Lambda environment, it’s time to take our tests external. For this, we’ll need to install the AWS Command Line Interface. While this will install binaries into C:\Program Files\Amazon\AWSCLIV2\, it’s meant to be run from within a terminal such as cmd.exe or PowerShell. We could also install AWS CLI into the WSL Debian environment we set up in Part 1, but maybe that’s best saved for Part 4. An online version of the AWS Console is available at All Services > Developer Tools > CloudShell.
AWS IAM dashboard
Before we can call our function from the outside, we need to create at least one user with the proper credentials to execute Lambda functions. In the AWS Management Console, let’s navigate to All Services > Security, Identity, & Compliance > IAM. You may have already have User Groups, Users, and a few others, but you’ll definitely have at least one Role since AWS created one for us when we set up the Lambda originally.
Investigating rustTest-role-something, we find the role name: AWSLambdaBasicExecutionRole-somenumbers. That’s probably the minimum permission level we need for our user. Let’s click the number below Users and hit the Add users button.
- User name: rustTestUser
- Select AWS credential type: Access key – Programmatic access
You’ll notice that the description for the credential type we’re going with describes itself as Enables an access key ID and secret access key for the AWS API, CLI, SDK, and other development tools. Click the Next: Permissions button. Under Set permissions, select Attach existing policies directly. Let’s narrow down the options by typing lambda into the Filter policies search box. For now, we want to find that basic execution role we created when we initially created the Lambda:
- Policy name: AWSLambdaBasicExecutionRole-some-long-hex-number
Another way to do this is to simply grant full access to our user.
- Policy name: AWSLambda_FullAccess
That’s a bit risky and NOT RECOMMENDED FOR PRODUCTION CODE. IAM policies are a bit outside the scope of this tutorial, but you can glean significant information from just looking through the one AWS already made for us and reading up on them.
Click Next: Tags. Skip the next section by clicking Next: Review. Click Create user.
Upon success, click Download .csv or copy the Access key ID and Secret access key to store them for later. Now will be your only opportunity to do so for this user.
cmd.exe or PowerShell / Windows Terminal
It works, but we need to configure it for our user and region.
Fire up your terminal of choice and let’s run aws.exe inside C:\aws-lambda-rust-runtime\. Your Default region may be different, but this is mine which I noted way back in Part 1.
C:\aws-lambda-rust-runtime>aws configure
AWS Access Key ID [**MAYBE*SOME*OLD*KEY]: Access key ID we saved
AWS Secret Access Key [**MAYBE*SOME*OLD*KEY]: Secret access key we saved
Default region name [us-east-1]: us-east-1
Default output format [json]: json
Let’s send some data! However, depending on which terminal you’re using, the syntax is slightly different in regards to quotation marks (‘ and “) and escape characters (\).
cmd.exe
C:\aws-lambda-rust-runtime>aws lambda invoke --cli-binary-format raw-in-base64-out --function-name rustTest --payload "{\"test_name\": \"Macsimum\"}" outfile.json
PowerShell / Windows Terminal
C:\aws-lambda-rust-runtime>aws lambda invoke --cli-binary-format raw-in-base64-out --function-name rustTest --payload '{\"test_name\": \"Macsimum\"}' "outfile.json"
We are looking for the following output:
{
"StatusCode": 200,
"ExecutedVersion": "$LATEST"
}
If all went well, there should now be a file named outfile.json inside your working directory. It should contain:
{"req_id":"some-request-id-number","msg":"Hello Macsimum!"}
Cleanup
If you’re satisfied, it’s time to head over to the cleanup section of the previous lesson. We have a lambda, some logs, users, and policies to delete lest they be abused or confuse a later administrator of our AWS account.