Sample Serverless.yml for multiple AWS accounts needed!

I need to set up deployment of production to a different AWS account. What’s the best/correct way to configure serverless.yml?

1 Like

The easiest solution is to make sure you don’t have a profile specified in your serverless.yml then set the AWS_PROFILE environment variable to the profile from your ~/.aws/credentials file that you want to use. For example: AWS_PROFILE=prod sls deploy -s prod

1 Like

Yep, profiles for the win.

You can even configure your profiles to use cross-account roles, as described in the docs.

Hey guys,

Sorry for the late post.
Is this actually working for you? We have a cross-account setup but I ended up having to resort to some other tricks to get this to work. Passing the AWS profile as environment variable works fine with regular AWS cli and other tools.

Here is sample error message I get:

AWS_PROFILE=dev-user-role serverless deploy

  Serverless Error ---------------------------------------

     AWS provider credentials not found. You can find more
     info on how to set up provider credentials in our docs

  Get Support --------------------------------------------

  Your Environment Information -----------------------------
     OS:                 darwin
     Node Version:       6.10.0
     Serverless Version: 1.9.0

My setup looks like this (redacted of course):

Sample cross-account settings for Dev vs Staging environments:


aws_access_key_id = AAAA
aws_secret_access_key = BBB
region = us-west-2


[profile dev-user-role]
role_arn = arn:aws:iam::<<ACCOUNT_ID>>:role/user-role
source_profile = mgmt
output = json
region = us-west-2

[profile stg-user-role]
role_arn = arn:aws:iam::<<ACCOUNT_ID>>:role/user-role
source_profile = mgmt
output = json
region = us-west-2



Ah, sorry about that @sdeby! I have had problems doing the cross-account role, and wrote a wrapper script to make it work - I really should’ve mentioned that.

Here’s the script I mentioned in another post:

1 Like

My understanding is that the environment variables are used by the SDK which underpins both the AWS CLI tools and the Serverless Framework. I know they work with Serverless if you’re referencing a profile in ~/.aws/credentials but I’ve never tried it with cross-across roles.

Personally we do the following:

  defaultStage: dev
    dev: dev
    prod: prod
    test: dev
  stage:  ${opt:stage, self:custom.defaultStage}
  region: us-east-1
  profile: ${self:custom.profiles.${self:provider.stage}}

Setup multiple AWS accounts as others above have mentioned and then you just need to specify the stage and it automatically will select the correct profile to use; dev and test use our dev acc, prod the prod account.

Tailor as you see fit,


Hey @rowanu,
I have been trying to deploy my serverless lambda in production account the same as I did in dev account but it failed for the past 2-3 hours. I tried the different ways described in documentation I tried (using-the-aws-profile-option) and (Per Stage Profiles) but both did not work.

But finally I sorted it out. the reason is I am accessing my prod account via roles not via user accounts.
The link you provided will add the profile associated to the prod role in this file .aws/config while serverless apparently only checking .aws/credentials (correct me if I am wrong).

The fix was simply adding the role profile in .aws/credentials file as follow:

role_arn = [role arn here]
source_profile = default

This will make both AWS CLI and serverless CLI be able to run/deploy onto the prod by specifying the role as follows:
aws cli => aws iam list-users --profile prodaccess
serverless cli => sls deploy -s prod --aws-profile prodaccess

Hope this saves someone time.

Thanks for sharing ideas and for your time.


Thanks for sharing this.

I’ve been bitten by the config vs credentials thing in the past. I think that roles are only supported in config (because they depend on a source_profile, as you’ve mentioned (i.e. it’s an SDK thing, not a Serverless thing).

Hi @menocomp ,

I just wanted to say thank you! :slight_smile:

I spent like 3 hours pulling my hair out.


I tried same steps mentioned by menocomp, but getting

Serverless: Deployment failed!
Serverless Error ---------------------------------------
An error occurred while provisioning your stack:
XXXXXXXLambdaFunction - Cross-account pass role is not allowed…

zip files are getting copied in S3 in prod account, Also noticed S3 -Server side encryption - Access denied while checking the file permissions. Which is not allowing to deploy.
Can someone please guide on this.

I’ve had to read both @menocomp answer and the AWS doc to figure it out, but here is a full working example for those interested!

This setup is to configure one profile named development, which will work whether it’s executed from aws CLI command or sls CLI command. This is assuming that you want to setup a cross-account access, by providing a role_arn to the aws configuration.


[profile development]
output = json
region = eu-west-1
role_arn = your-arn
source_profile = development


# Necessary for both AWS CLI and SLS
aws_access_key_id = your-aws_access_key_id
aws_secret_access_key = your-aws_secret_access_key

# Necessary for SLS, because SLS doesn't do a lookup in the ./config file
role_arn = your-arn
source_profile = development

With this setup:

  • sls deploy --aws-profile development will work
  • aws iam list-users --profile development will output something similar to:
  "Users": []

If you remove the role_arn and source_profile from ~/.aws/credentials, you’ll notice it may still work (depending on your permissions, doesn’t work at all in my case because my IAM user doesn’t have any permission on the root account), but you won’t hit the same account (you’ll hit the root account, not the cross-account)

Thanks for your input @menocomp, definitely saved me a lot of time! :slight_smile:


I wanted to use as environment variable instead of having to pass the profile flag each time…
So I updated ~/.bash_profile with,

alias sls=“sls --aws-profile $AWS_DEFAULT_PROFILE”

Now if I do export and run sls it’s much easier, and obviously that exported profile name needs to be in the credentials file.

1 Like

I just wanted to share that we’ve written about this pattern in detail. I know we are late to the party but hopefully somebody finds it useful!

Let me know if we should go into further detail for anything.