How to Configure Local Resource Access Using the AWS Management Console

This feature is available for AWS Greengrass Core v1.3.0 only.

You can configure Lambda functions to securely access local resources on the host
Greengrass core device.
Local resources refer to buses and peripherals that are physically on the host, or file system
volumes on the host OS. For more information, including requirements and constraints,
see Access Local Resources with Lambda
Functions.

This tutorial describes how to use the AWS Management Console to configure access
to local resources that are present on an AWS Greengrass core device. It
contains the following high-level steps:

Step 1: Add a Local Resource to a Greengrass Group

In this step, you use the AWS IoT console to add a local volume resource to a Greengrass
group. A local resource has a
group-level scope, which makes it accessible by all Lambda functions in the group.

Choose the Greengrass group where you want to add the local resource. This opens the
group's configuration
page.

In the left pane, choose Resources, and then choose Add
Resource.

On the Create a local resource page, use the following values:

Property

Value

Name

testDirectory

Local resource type

Volume

Source path

(This
path must exist on the host OS.)

/src/LRAtest

Destination path

(This
path must exist on the host OS.)

/dest/LRAtest

OS group used to access this resource

Automatically add OS group

For volume resources, the Source path is the local absolute path of
the resource on the file system of the core device. This path can't start with /proc
or /sys.

The Destination path is the absolute path
of the resource in the Lambda namespace.

The Specify the OS group used to access this resource option lets you grant additional
file access permissions to the Lambda process. For more information, see Group Owner File Access Permission.

At the bottom of the page, choose Save.

The Resources page displays the new testDirectory resource.

Step 2: Create a Lambda Function Deployment Package

In this step, you create a Lambda function deployment package, which is a ZIP file
that contains the
function's code and dependencies. You also download the AWS Greengrass Core SDK to
include in the package as a dependency.

Greengrass groups can reference a Lambda function by version or by alias. Using an
alias makes it easier to manage code updates
because you don't have to change your group definition. When the function is updated,
you can just point the alias to the new version.

From the Actions menu, choose Publish new version.

For Version description, type First version, and then choose
Publish.

On the TestLRA: 1 configuration page, from the Actions menu, choose
Create alias.

On the Create a new alias page, use the following values:

Property

Value

Name

test

Version

1

Note

AWS Greengrass doesn't support Lambda aliases for $LATEST versions.

Choose Create.

You can now add the Lambda function to your Greengrass group.

Step 4: Add the Lambda Function to the Greengrass Group

In this step, you add the TestLRA function to your group, configure the function's
lifecycle, and grant the
function read and write access to the local resource.

First, add the Lambda function to your Greengrass group.

In the AWS IoT console, open AWS Greengrass, and choose your group.

On the group's configuration page, in the left pane, choose Lambdas, and then choose
Add Lambda.

On the Add a Lambda to your Greengrass Group page, choose Use existing
Lambda.

On the Use existing Lambda page, choose TestLRA, and then choose
Next.

On the Select a Lambda version page, choose Alias:test, and then
choose Finish.

Next, configure the lifecycle of the Lambda function.

On the Lambdas page, choose the TestLRA Lambda function.

On the TestLRA configuration page, choose Edit.

On the Group-specific Lambda configuration page, use the following values:

Property

Value

Timeout

30 seconds

Lambda lifecycle

Make this function long-lived and keep it running indefinitely

Note

A long-lived Lambda function starts automatically after AWS Greengrass starts and keeps running
in
its own container (or sandbox). This is in contrast to an on-demand Lambda function, which
starts only when invoked and stops when there are no tasks left to execute. When possible,
you should use
on-demand Lambda functions because they are less resource-intensive than long-lived
functions.

At the bottom of the page, choose Update.

Now, configure access to the local resource for the Lambda function.

On the TestLRA configuration page, in the left pane, choose Resources, and then
choose Add Resource.

On the Add a resource page, in Attach an existing resource, choose
Select resource.

On the Attach an existing resource page, choose Select.

Choose testDirectory.

Select Read and write access to allow the function to read and write to testDirectory,
choose Done, and then choose Save.

Step 5: Add Subscriptions to the Greengrass Group

In this step, you add two subscriptions to the Greengrass group. These subscriptions
enable bidirectional
communication between the Lambda function and AWS IoT.

First, create a subscription for the Lambda function to send messages to AWS Greengrass.

On the group's configuration page, in the left pane, choose Subscriptions, and then
choose Add Subscription.

On the Select your source and target page, configure the source and target, as
follows:

In the Select a source section, choose Lambdas, and then choose
TestLRA.

In the Select a target section, choose Services, and then choose
IoT Cloud.

Choose Next.

On the Filter your data with a topic page, in the Optional topic
filter field, type LRA/test, and then choose Next.

Choose Finish. The Subscriptions page displays the new subscription.

Next, configure a subscription that invokes the function from AWS IoT.

On the Subscriptions page, choose Add Subscription.

On the Select your source and target page, configure the source and target, as
follows:

In Select a source, choose Services, and then choose IoT
Cloud.

In Select a target, choose Lambdas, and then choose
TestLRA.

Choose Next.

On the Filter your data with a topic page, in Optional topic filter,
type invoke/LRAFunction, and then choose Next.

Choose Finish. The Subscriptions page displays both subscriptions.

Step 6: Deploy the AWS Greengrass Group

In this step, you deploy the current version of the group definition.

On the group's configuration page, in the left pane, choose Deployments, and from the
Actions menu, choose Deploy.

This enables devices to automatically acquire connectivity information for the core,
such as IP address, DNS,
and port number. Automatic detection is recommended, but AWS Greengrass also supports
manually specified endpoints. You're
only prompted for the discovery method the first time that the group is deployed.

Note

If prompted, grant permissions to AWS Greengrass that allow the service to access
other AWS services. These permissions
are defined using a managed policy, which you need to grant only once per account.

The Deployments page shows the deployment timestamp, version ID, and status. When
completed, the deployment should show a Successfully completed status.

Test Local Resource Access

Now you can verify whether the local resource access is configured correctly. To test,
you subscribe to the
LRA/test topic and publish to the invoke/LRAFunction topic. The test is
successful if the Lambda function sends the expected payload to AWS IoT.

On the AWS IoT console home page, in the left pane, choose Test.

In the Subscriptions section, use the following values:

Property

Value

Subscription topic

LRA/test

MQTT payload display

Display payloads as strings

Choose Subscribe to topic. This is the topic that your Lambda function publishes to.

In the Publish section, type invoke/LRAFunction, and then choose
Publish to topic to invoke your Lambda function. The test is successful if the page displays
the function's three message payloads.

You can see the test file that the Lambda creates by looking in the /src/LRAtest directory
on the Greengrass core device.
Although the Lambda writes to a file in the /dest/LRAtest directory, that file is
visible in the Lambda namespace only—you
cant' see it in a regular Linux namespace. However, any changes to the destination
path are reflected in the source path
on the actual file system.