Why use different AWS accounts for stages

I’m new to serverless.com but really excited to learn more and start using it. Great job, it looks great.

I found the following recommendations here: https://serverless.com/framework/docs/providers/aws/guide/workflow/.

  • Use different AWS accounts for stages.
  • In larger teams, each member should use a separate AWS account and their own stage for development.

I was just wondering why you recommend using different AWS accounts for stages? I was planning to use variables to deploy a dev and prod stage.

The main reason for using separate accounts is to protect Production from the other environments/stages.

Having separate accounts for your environments is the recommended (by AWS) way to limit the “blast radius” of your applications and users. It means you can give your developers full access to a development account, and not have to worry about your production application(s) be impacted unintentionally. While you could theoretically limit access to stages/environments in the same account using IAM permissions, it would be very fiddly, error-prone, frustrating, and basically not worth the effort.

This separation is a must-have in most larger organisations. If you’re working in a smaller organisation, maybe you can get away with one account for everything, but in the long-run you’ll be much better off using multiple accounts - there’s not additional cost from the AWS side of things, and it will make you’re life much simpler (i.e. troubleshooting, reporting, etc).

2 Likes

I created different profiles in the config and credentials files, but when I deployed using a profile which I thought referred to a different account, it still deployed to the same account as my original profile. Where / how in serverless.yml do you specify the account that it should deploy to?

You can specify the profile inside the provider block, ie.

provider:
  name: aws
  runtime: nodejs6.10
  region: us-east-1
  profile: foo

Make sure foo matches the profile name in your ~/.aws/credentials

Thank you! However, I’m way beyond that point.

I’ve got multiple profiles configured and I can successfully use them as you stated (I’ve also got them configured to accept the command line option variable). The problem is that we use different AWS accounts for different stages – but even when I use the profile and credentials for the new account, when I run SLS deploy --profile it still ends up creating the project in the original account (even though the credentials for the devApd profile are in the new account…

provider:
name: aws
runtime: nodejs6.10
stage: devAws

stage: ${opt:stage, self:custom.defaultStage}

profile: ${self:custom.profiles.${self:provider.stage}}
region: us-west-2
custom:
defaultStage: devAws
myStage: ${opt:stage, self:custom.defaultStage}
myRegion: ${opt:region, self:provider.region}
profiles:
devAws: devAws # Original shared dev env
devApd: devApd
prodAws: prodAws

C:\TFS\APD-RepairSolutions\Main\Source\OEC-AWS-Components\oec-order-update-app>SLS deploy --stage devApd --AWS-profile devApd
Serverless: Packaging service…
Serverless: Excluding development dependencies…
Serverless: Uploading CloudFormation file to S3…
Serverless: Uploading artifacts…
Serverless: Uploading service .zip file to S3 (5.31 MB)…
Serverless: Validating template…
Serverless: Updating Stack…
Serverless: Checking Stack update progress…

Serverless: Stack update finished…
Service Information
service: oecOrderUpdate
stage: devApd
region: us-west-2
api keys:
None
endpoints:
POST - https://##########.execute-api.us-west-2.amazonaws.com/devApd/OrderCreated
POST - https://##########.execute-api.us-west-2.amazonaws.com/devApd/OrderUpdated
POST - https://##########.execute-api.us-west-2.amazonaws.com/devApd/AttachmentCreated
GET - https://##########.execute-api.us-west-2.amazonaws.com/devApd/ApiHealthCheck
functions:
orderCreated: oecOrderUpdate-devApd-orderCreated
orderUpdated: oecOrderUpdate-devApd-orderUpdated
attachmentCreated: oecOrderUpdate-devApd-attachmentCreated
apiHealthCheck: oecOrderUpdate-devApd-apiHealthCheck

1 Like

Last time I checked there wasn’t a --profile option for sls deploy. You need to set the AWS_PROFILE environment variable. If you don’t then it uses the default profile.

Try using

AWS_PROFILE=xxx sls deploy

@mitchellLisa Sorry for the late response. Did you get it to work?

I see you are using --aws-profile. Does devApd match the profile name in your aws credentials file? @buggy is right, --profile will not work.

Yes – I was fortunate enough to have already been helped. I had a variable in the wrong place. Thank you for replying though!