Deploy Lambda Function Into new region

Serverless Framework
1

I have a service I deployed into us-east-1, I would also like to deploy it to ca-central-1. It fails to deploy stating

~/p/amibackup ❯❯❯ sls deploy -v --region ca-central-1 --stage prod --aws-profile profilename                                                                                                    master ✱
 
  Serverless Error ---------------------------------------
 
  Deployment bucket is not in the same region as the lambda function
 
  Get Support --------------------------------------------
     Docs:          docs.serverless.com
     Bugs:          github.com/serverless/serverless/issues
     Forums:        forum.serverless.com
     Chat:          gitter.im/serverless/serverless
 
  Your Environment Information -----------------------------
     OS:                     linux
     Node Version:           6.11.3
     Serverless Version:     1.23.0
 
~/p/amibackup ❯❯❯

serverless.yml contains

  deploymentBucket:
    name: 8675309-${self:provider.region}-${ssm:accountID}-serverless

Where in S3, both 8675309-us-east-1-55555-serverless and 8675309-ca-central-1-55555-serverless exist in their respective regions.

How can I deploy the same service, to multiple regions?

2

Have you tried making the service name dynamic? I’m guessing that the deployment bucket for Serverless is still in the same region, but if you change the service name it should treat it as a completely new service and you won’t have that issue.

3

Try using

deploymentBucket:
  name: 8675309-${opt:region, self:provider.region}-${ssm:accountID}-serverless

or just remove the deploymentBucket.

1 Like
4

I can not remove the deployment bucket for policy reasons, but your first suggestion worked.

Can you explain the difference between ${self:provider.region} and ${opt:region, self:provider.region} ? I read it as self:provider.region is the value I specify with --region. not sure what the opt:region part is.

5

Using --region doesn’t change the value of ${self:provider.region}. It’s always the value of region set in the provider section of serverless.yml. By using ${opt:region, self:provider.region} you’re telling it to use the value from the --region command line option if provided then the value for region from the provider section in your serverless.yml if it isn’t.

6

regarding your sample about region to be defined.

I have another question. Can we defaultly set the order in sls on how to read the variables.

`--region`  :  ${opt:region}
system environment variable:  ${env:AWS_DEFAULT_REGION} or  ${env:AWS_REGION}
self: ${self:provider.region}
custom: ${self:custom:region}
and more.
7

The easiest solution is probably to set it as:

provider:
  region: ${opt:region, env:AWS_DEFAULT_REGION, 'us-east-1'}

Then just use ${self:provider.region}

If you want others then add them into the list.

2 Likes
8

Thanks.

How can we let sls know this order without add them as a long list in serverless.yml?

looks sls doesn’t support this feature currently. Refer AWS Cli (http://docs.aws.amazon.com/cli/latest/userguide/cli-chap-getting-started.html#config-settings-and-precedence), could we have the similar feature in SLS?

The AWS CLI looks for credentials and configuration settings in the following order:

  1. Command line options – region, output format and profile can be specified as command options to override default settings.

  2. Environment variables – AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, and AWS_SESSION_TOKEN.

  3. The AWS credentials file – located at ~/.aws/credentials on Linux, macOS, or Unix, or at C:\Users\USERNAME .aws\credentials on Windows. This file can contain multiple named profiles in addition to a default profile.

  4. The CLI configuration file – typically located at ~/.aws/config on Linux, macOS, or Unix, or at C:\Users\USERNAME .aws\config on Windows. This file can contain a default profile, named profiles, and CLI specific configuration parameters for each.

  5. Container credentials – provided by Amazon EC2 Container Service on container instances when you assign a role to your task.

  6. Instance profile credentials – these credentials can be used on EC2 instances with an assigned instance role, and are delivered through the Amazon EC2 metadata service.

I prefer order #1, #2, #3

9

If you want to request a feature you’ll need to submit an issue on the Github project page.

1 Like