CODEWITHSUNDEEP
python-3.xamazon-web-servicesaws-lambdaboto3localstack
Ciaran Evans
Ciaran Evans

Reputation: 157

boto3 resource requires more parameters when running on localstack vs when on AWS Lambda

Problem

My Lambdas deployed on AWS have used boto3 clients/resources before with only the service name, however Lambdas deployed inside Localstack only work when region_name, aws_access_key_id, aws_secret_key_id, and endpoint_url.

How do I remove the need for this?

What I've tried

I've tried deploying the Lambda inside Localstack without the extra parameters but I get errors such as:

Exception: ('Unable to get handler function from lambda code.', NoRegionError('You must specify a region.',))

and

botocore.exceptions.ClientError: An error occurred (UnrecognizedClientException) when calling the Scan operation: The security token included in the request is invalid.

What I want

Ideal situation (as it is in my current Lambdas on AWS):

dynamodb = boto3.client('dynamodb')

The current work-around (when deploying to Localstack):

dynamodb = boto3.client('dynamodb', region_name='eu-west-2', 
                        aws_access_key_id="", aws_secret_access_key="",
                        endpoint_url='http://localhost:4569')

Upvotes: 2

Views: 1987

Answers (1)

congbaoguier
congbaoguier

Reputation: 1045

No you cannot prevent using them in localstack.

The region, aws_access_key_id, endpoint and etc are always needed -- it seems like it doesn't on Lambda console just because when you run on Lambda, the Lambda environment is injected with many default values, so even if you don't provide those variables, it still works.

However, if you don't want to specify those values in your code, you can still specify them in the environment variables when you run your localstack:

https://github.com/localstack/localstack#configurations

You need to pass in the following env vars:

SERVICES=lambda:4569
DEFAULT_REGION=eu-west-2

To put in the IAM access key related env vars, use this nice lil utility:https://github.com/jaymecd/aws-profile/blob/master/aws-profile

With all these efforts(not a ton but still some), you can "remove the need of specifying those in your code" -- but still, you are just moving them to environment variables.

One benefit is that, this way the local looks more consistent with the code in your production.

Upvotes: 2

Related Questions